Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Include hso driver (Option-branded GSM modem) in default Raspbian kernel configuration? #580

Closed
ghost opened this issue Apr 30, 2014 · 6 comments
Closed

Include hso driver (Option-branded GSM modem) in default Raspbian kernel configuration? #580

ghost opened this issue Apr 30, 2014 · 6 comments

Comments

@ghost
Copy link

ghost commented Apr 30, 2014

Hi,

(Apologies in advance if this is the wrong place to file this; there are a couple Raspbian threads that seem to indicate that the Raspberry Pi foundation is building the distribution's kernel.)

The 2004-01 Raspbian image currently ships a kernel configuration in which the hso kernel driver is disabled (both in-kernel and as a module). A number of other GSM modem drivers for other manufacturers' devices (e.g. option.ko) are included as modules, but using hso currently seems to require that I download and rebuild the kernel with a modified .config file.

Is there some specific reason this driver isn't shipped? It's in the mainline kernel and appears to work well now that I've rebuilt the kernel.
@popcornmix
Copy link
Collaborator

To confirm, you would like CONFIG_USB_HSO=m added to default kernel config?

@ghost
Copy link
Author

ghost commented Apr 30, 2014

Correct; we've been using the serial interface exposed by the driver (/dev/ttyHS0) and AT commands to programmatically send SMS/text messages using the USB-connected HSDPA adapter. I haven't tested the network interface, but can confirm that the serial interface (major 248, minor 0) is functional. Thanks so much for the quick reply.

@popcornmix
Copy link
Collaborator

Okay, no objections to adding that - will be in next firmware update.

popcornmix added a commit that referenced this issue Apr 30, 2014
@popcornmix
config: add CONFIG_USB_HSO module (option-branded GSM moded)
b60abae 
See: #580
@ghost
Copy link
Author

ghost commented Apr 30, 2014

Fantastic, thank you.

popcornmix pushed a commit to raspberrypi/firmware that referenced this issue May 1, 2014
kernel: config: Enable CONFIG_DMA_CMA which may fix fiq dsm cache coh…
680ac93 
…erency issues

See: raspberrypi/linux#575

kernel: config: Add CONFIG_USB_HOS module (option branded GSM modem)
See: raspberrypi/linux#580

tvservice: Allow requesting NTSC frequency variants of hdmi modes
See: http://www.raspberrypi.org/forums/viewtopic.php?f=91&t=75589
popcornmix pushed a commit to Hexxeh/rpi-firmware that referenced this issue May 1, 2014
kernel: config: Enable CONFIG_DMA_CMA which may fix fiq dsm cache coh…
1e98ba5 
…erency issues

See: raspberrypi/linux#575

kernel: config: Add CONFIG_USB_HOS module (option branded GSM modem)
See: raspberrypi/linux#580

tvservice: Allow requesting NTSC frequency variants of hdmi modes
See: http://www.raspberrypi.org/forums/viewtopic.php?f=91&t=75589
@popcornmix
Copy link
Collaborator

Firmware is updated. Please run rpi-update and confirm module is as expected.

@ghost
Copy link
Author

ghost commented May 1, 2014

Updated to 1e98ba5db72d5edceebd05c5e264945ca190b0ec (3.12.18+) and everything works as expected. Thanks again!

@ghost ghost closed this as completed May 1, 2014
neuschaefer pushed a commit to neuschaefer/raspi-binary-firmware that referenced this issue Feb 27, 2017
kernel: config: Enable CONFIG_DMA_CMA which may fix fiq dsm cache coh…
908f28e 
…erency issues

See: raspberrypi/linux#575

kernel: config: Add CONFIG_USB_HOS module (option branded GSM modem)
See: raspberrypi/linux#580

tvservice: Allow requesting NTSC frequency variants of hdmi modes
See: http://www.raspberrypi.org/forums/viewtopic.php?f=91&t=75589
popcornmix pushed a commit that referenced this issue Jan 22, 2018
ARM: net: bpf: fix tail call jumps
f4483f2 
When a tail call fails, it is documented that the tail call should
continue execution at the following instruction.  An example tail call
sequence is:

  12: (85) call bpf_tail_call#12
  13: (b7) r0 = 0
  14: (95) exit

The ARM assembler for the tail call in this case ends up branching to
instruction 14 instead of instruction 13, resulting in the BPF filter
returning a non-zero value:

  178:	ldr	r8, [sp, #588]	; insn 12
  17c:	ldr	r6, [r8, r6]
  180:	ldr	r8, [sp, #580]
  184:	cmp	r8, r6
  188:	bcs	0x1e8
  18c:	ldr	r6, [sp, #524]
  190:	ldr	r7, [sp, #528]
  194:	cmp	r7, #0
  198:	cmpeq	r6, #32
  19c:	bhi	0x1e8
  1a0:	adds	r6, r6, #1
  1a4:	adc	r7, r7, #0
  1a8:	str	r6, [sp, #524]
  1ac:	str	r7, [sp, #528]
  1b0:	mov	r6, #104
  1b4:	ldr	r8, [sp, #588]
  1b8:	add	r6, r8, r6
  1bc:	ldr	r8, [sp, #580]
  1c0:	lsl	r7, r8, #2
  1c4:	ldr	r6, [r6, r7]
  1c8:	cmp	r6, #0
  1cc:	beq	0x1e8
  1d0:	mov	r8, #32
  1d4:	ldr	r6, [r6, r8]
  1d8:	add	r6, r6, #44
  1dc:	bx	r6
  1e0:	mov	r0, #0		; insn 13
  1e4:	mov	r1, #0
  1e8:	add	sp, sp, #596	; insn 14
  1ec:	pop	{r4, r5, r6, r7, r8, sl, pc}

For other sequences, the tail call could end up branching midway through
the following BPF instructions, or maybe off the end of the function,
leading to unknown behaviours.

Fixes: 39c13c2 ("arm: eBPF JIT compiler")
Signed-off-by: Russell King <[email protected]>
popcornmix pushed a commit that referenced this issue Jan 31, 2018
@gregkh
ARM: net: bpf: fix tail call jumps
e7119ca 
commit f4483f2 upstream.

When a tail call fails, it is documented that the tail call should
continue execution at the following instruction.  An example tail call
sequence is:

  12: (85) call bpf_tail_call#12
  13: (b7) r0 = 0
  14: (95) exit

The ARM assembler for the tail call in this case ends up branching to
instruction 14 instead of instruction 13, resulting in the BPF filter
returning a non-zero value:

  178:	ldr	r8, [sp, #588]	; insn 12
  17c:	ldr	r6, [r8, r6]
  180:	ldr	r8, [sp, #580]
  184:	cmp	r8, r6
  188:	bcs	0x1e8
  18c:	ldr	r6, [sp, #524]
  190:	ldr	r7, [sp, #528]
  194:	cmp	r7, #0
  198:	cmpeq	r6, #32
  19c:	bhi	0x1e8
  1a0:	adds	r6, r6, #1
  1a4:	adc	r7, r7, #0
  1a8:	str	r6, [sp, #524]
  1ac:	str	r7, [sp, #528]
  1b0:	mov	r6, #104
  1b4:	ldr	r8, [sp, #588]
  1b8:	add	r6, r8, r6
  1bc:	ldr	r8, [sp, #580]
  1c0:	lsl	r7, r8, #2
  1c4:	ldr	r6, [r6, r7]
  1c8:	cmp	r6, #0
  1cc:	beq	0x1e8
  1d0:	mov	r8, #32
  1d4:	ldr	r6, [r6, r8]
  1d8:	add	r6, r6, #44
  1dc:	bx	r6
  1e0:	mov	r0, #0		; insn 13
  1e4:	mov	r1, #0
  1e8:	add	sp, sp, #596	; insn 14
  1ec:	pop	{r4, r5, r6, r7, r8, sl, pc}

For other sequences, the tail call could end up branching midway through
the following BPF instructions, or maybe off the end of the function,
leading to unknown behaviours.

Fixes: 39c13c2 ("arm: eBPF JIT compiler")
Signed-off-by: Russell King <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
herrnst pushed a commit to herrnst/linux-raspberrypi that referenced this issue Jan 2, 2023
@kuba-moo @gregkh
devlink: hold region lock when flushing snapshots
49383d4 
[ Upstream commit b4cafb3 ]

Netdevsim triggers a splat on reload, when it destroys regions
with snapshots pending:

  WARNING: CPU: 1 PID: 787 at net/core/devlink.c:6291 devlink_region_snapshot_del+0x12e/0x140
  CPU: 1 PID: 787 Comm: devlink Not tainted 6.1.0-07460-g7ae9888d6e1c raspberrypi#580
  RIP: 0010:devlink_region_snapshot_del+0x12e/0x140
  Call Trace:
   <TASK>
   devl_region_destroy+0x70/0x140
   nsim_dev_reload_down+0x2f/0x60 [netdevsim]
   devlink_reload+0x1f7/0x360
   devlink_nl_cmd_reload+0x6ce/0x860
   genl_family_rcv_msg_doit.isra.0+0x145/0x1c0

This is the locking assert in devlink_region_snapshot_del(),
we're supposed to be holding the region->snapshot_lock here.

Fixes: 2dec18a ("net: devlink: remove region snapshots list dependency on devlink->lock")
Signed-off-by: Jakub Kicinski <[email protected]>
Reviewed-by: Jiri Pirko <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
popcornmix pushed a commit that referenced this issue Jan 3, 2023
@kuba-moo @gregkh
devlink: hold region lock when flushing snapshots
6298cab 
[ Upstream commit b4cafb3 ]

Netdevsim triggers a splat on reload, when it destroys regions
with snapshots pending:

  WARNING: CPU: 1 PID: 787 at net/core/devlink.c:6291 devlink_region_snapshot_del+0x12e/0x140
  CPU: 1 PID: 787 Comm: devlink Not tainted 6.1.0-07460-g7ae9888d6e1c #580
  RIP: 0010:devlink_region_snapshot_del+0x12e/0x140
  Call Trace:
   <TASK>
   devl_region_destroy+0x70/0x140
   nsim_dev_reload_down+0x2f/0x60 [netdevsim]
   devlink_reload+0x1f7/0x360
   devlink_nl_cmd_reload+0x6ce/0x860
   genl_family_rcv_msg_doit.isra.0+0x145/0x1c0

This is the locking assert in devlink_region_snapshot_del(),
we're supposed to be holding the region->snapshot_lock here.

Fixes: 2dec18a ("net: devlink: remove region snapshots list dependency on devlink->lock")
Signed-off-by: Jakub Kicinski <[email protected]>
Reviewed-by: Jiri Pirko <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@popcornmix