Re: [PATCH lora-next 3/5] net: lora: sx130x: Add PicoCell serdev driver

On Fr, 2019-01-04 at 12:21 +0100, Andreas Färber wrote: > > +struct picogw_device { > + struct serdev_device *serdev; > + > + u8 rx_buf[1024]; No, you cannot do that. AFAICT this buffer can be used for DMA. Thus putting it into another data structure violates the rules of DMA coherency.

Re: [PATCH v2] usb: hub: add retry routine after intr URB sumbit error

On Mo, 2018-11-19 at 15:02 +0100, Nicolas Saenz Julienne wrote: > > +static void hub_retry_irq_urb(struct timer_list *t) > +{ > + struct usb_hub *hub = from_timer(hub, t, irq_urb_retry); > + int status; > + > + if (hub->disconnected || hub->quiescing) > + return; > + > +

Re: [PATCH v2] usb: hub: add retry routine after intr URB sumbit error

On Mo, 2018-11-19 at 15:02 +0100, Nicolas Saenz Julienne wrote: > > +static void hub_retry_irq_urb(struct timer_list *t) > +{ > + struct usb_hub *hub = from_timer(hub, t, irq_urb_retry); > + int status; > + > + if (hub->disconnected || hub->quiescing) > + return; > + > +

Re: [PATCH] usbnet: use tasklet_init() for usbnet_bh handler

On Fr, 2018-11-16 at 15:50 +, Ben Dooks wrote: > The tasklet initialisation would be better done by tasklet_init() > instead of assuming all the fields are in an ok state by default. > > Note, this does not fix any known bug. > > Signed-off-by: Ben Dooks Acked-by: Oliver Neukum

Re: [PATCH] usbnet: use tasklet_init() for usbnet_bh handler

On Fr, 2018-11-16 at 15:50 +, Ben Dooks wrote: > The tasklet initialisation would be better done by tasklet_init() > instead of assuming all the fields are in an ok state by default. > > Note, this does not fix any known bug. > > Signed-off-by: Ben Dooks Acked-by: Oliver Neukum

Re: [PATCH] usb: hub: add I/O error retry & reset routine

On Do, 2018-11-15 at 18:14 +0100, Nicolas Saenz Julienne wrote: Hi, what Alan said, in addition you need to stop the error handling when the device is suspended or reset. > @@ -713,8 +751,10 @@ static void hub_irq(struct urb *urb) > return; > > status =

Re: [PATCH] usb: hub: add I/O error retry & reset routine

On Do, 2018-11-15 at 18:14 +0100, Nicolas Saenz Julienne wrote: Hi, what Alan said, in addition you need to stop the error handling when the device is suspended or reset. > @@ -713,8 +751,10 @@ static void hub_irq(struct urb *urb) > return; > > status =

Re: [PATCH 0/4][RFC v2] Introduce the in-kernel hibernation encryption

On Di, 2018-07-24 at 00:23 +0800, Yu Chen wrote: > Hi, > On Mon, Jul 23, 2018 at 01:42:36PM +0200, Oliver Neukum wrote: > > On Fr, 2018-07-20 at 12:25 +0200, Pavel Machek wrote: > > > So your goal is to make hibernation compatible with kernel > > > lockdown? Do y

Re: [PATCH 0/4][RFC v2] Introduce the in-kernel hibernation encryption

On Di, 2018-07-24 at 00:23 +0800, Yu Chen wrote: > Hi, > On Mon, Jul 23, 2018 at 01:42:36PM +0200, Oliver Neukum wrote: > > On Fr, 2018-07-20 at 12:25 +0200, Pavel Machek wrote: > > > So your goal is to make hibernation compatible with kernel > > > lockdown? Do y

Re: [PATCH] usb: cdc_acm: Add quirk for Uniden UBC125 scanner

7 > bDescriptorType 5 > bEndpointAddress 0x02 EP 2 OUT > bmAttributes2 > Transfer TypeBulk > Synch Type None > Usage Type Data > wMaxPacketSize 0x0040 1x 64 bytes > bInterval 0 > Device Status: 0x > (Bus Powered) > > Signed-off-by: Houston Yaroschoff Acked-by: Oliver Neukum

Re: [PATCH] usb: cdc_acm: Add quirk for Uniden UBC125 scanner

7 > bDescriptorType 5 > bEndpointAddress 0x02 EP 2 OUT > bmAttributes2 > Transfer TypeBulk > Synch Type None > Usage Type Data > wMaxPacketSize 0x0040 1x 64 bytes > bInterval 0 > Device Status: 0x > (Bus Powered) > > Signed-off-by: Houston Yaroschoff Acked-by: Oliver Neukum

Re: [PATCH v2 1/2] [usb-storage] Add support for FL_ALWAYS_SYNC flag in the UAS driver

gt; drivers/usb/storage/scsiglue.c:284 > > Signed-off-by: Alexander Kappner <a...@godking.net> Acked-by: Oliver Neukum <oneu...@suse.com>

Re: [PATCH v2 1/2] [usb-storage] Add support for FL_ALWAYS_SYNC flag in the UAS driver

gt; drivers/usb/storage/scsiglue.c:284 > > Signed-off-by: Alexander Kappner Acked-by: Oliver Neukum

Re: [usb-storage] Re: [PATCH v2 0/2] Re: usb-storage: Add quirks to make G-Technology "G-Drive" work

Am Montag, den 21.05.2018, 13:47 -0400 schrieb Alan Stern: > On Fri, 18 May 2018, Alexander Kappner wrote: > > > v2 of this patch implements the FL_ALWAYS_SYNC flag in the UAS driver, and > > then > > adds the flag as quirks for the device at issue. This allows the G-Drive to > > work > > under

Re: [usb-storage] Re: [PATCH v2 0/2] Re: usb-storage: Add quirks to make G-Technology "G-Drive" work

Am Montag, den 21.05.2018, 13:47 -0400 schrieb Alan Stern: > On Fri, 18 May 2018, Alexander Kappner wrote: > > > v2 of this patch implements the FL_ALWAYS_SYNC flag in the UAS driver, and > > then > > adds the flag as quirks for the device at issue. This allows the G-Drive to > > work > > under

Re: [PATCH] usb-storage: Add quirks to make G-Technology "G-Drive" work

actually whether US_FL_NO_WP_DETECT by itself would make the device work. Can you please test that? You will need the attached patch for the quirk to be supported. Regards Oliver From 1ff6c9c9cc66ddb4cf7ca95bea589d6a30c63623 Mon Sep 17 00:00:00 2001 From: Oliver Neukum <oneu

Re: [PATCH] usb-storage: Add quirks to make G-Technology "G-Drive" work

actually whether US_FL_NO_WP_DETECT by itself would make the device work. Can you please test that? You will need the attached patch for the quirk to be supported. Regards Oliver From 1ff6c9c9cc66ddb4cf7ca95bea589d6a30c63623 Mon Sep 17 00:00:00 2001 From: Oliver Neukum Date

Re: [PATCH 4.4 49/72] media: usbtv: prevent double free in error case

Am Montag, den 14.05.2018, 18:41 +0100 schrieb Ben Hutchings: > > Shouldn't this bump the V4L2 device's reference count, i.e.: > > v4l2_device_get(>v4l2_dev); > You are right. Mixing refcounting sucks. I am preparing a patch. Regards Oliver

Re: [PATCH 4.4 49/72] media: usbtv: prevent double free in error case

Am Montag, den 14.05.2018, 18:41 +0100 schrieb Ben Hutchings: > > Shouldn't this bump the V4L2 device's reference count, i.e.: > > v4l2_device_get(>v4l2_dev); > You are right. Mixing refcounting sucks. I am preparing a patch. Regards Oliver

Re: [usb-storage] [PATCH] usb: storage: Fix a possible data race in uas_queuecommand_lck

t to protect dev->resetting. I don't see why the scope of the lock would need to be enlarged. Regards Oliver > To fix this data race, the write operations on line 634-635 > should be also protected by the lock. > > Signed-off-by: Jia-Ju Bai <baijiaju1...@gmail.com> Nacked-by: Oliver Neukum <oneu...@suse.com>

Re: [usb-storage] [PATCH] usb: storage: Fix a possible data race in uas_queuecommand_lck

t to protect dev->resetting. I don't see why the scope of the lock would need to be enlarged. Regards Oliver > To fix this data race, the write operations on line 634-635 > should be also protected by the lock. > > Signed-off-by: Jia-Ju Bai Nacked-by: Oliver Neukum

Re: [PATCH] cdc_ether: flag the Cinterion AHS8 modem by gemalto as WWAN

ommand can be used to activate or deactivate a WWAN >     connection for a PDP context defined with the same command. UE supports >     one WWAN adapter. > > Signed-off-by: Bassem Boubaker <bassem.bouba...@actia.fr> Acked-by: Oliver Neukum <oneu...@suse.com>

Re: [PATCH] cdc_ether: flag the Cinterion AHS8 modem by gemalto as WWAN

ommand can be used to activate or deactivate a WWAN >     connection for a PDP context defined with the same command. UE supports >     one WWAN adapter. > > Signed-off-by: Bassem Boubaker Acked-by: Oliver Neukum

Re: [PATCH] usbip: vhc_hcd: prevent module being removed while device are attached

Am Dienstag, den 03.04.2018, 09:56 -0600 schrieb Shuah Khan: > This is a virtual device associated to a real physical device on a different > system. My concern is that if the module gets removed accidentally then it > could disrupt access to the remote device. The remote nature of the device >

Re: [PATCH] usbip: vhc_hcd: prevent module being removed while device are attached

Am Dienstag, den 03.04.2018, 09:56 -0600 schrieb Shuah Khan: > This is a virtual device associated to a real physical device on a different > system. My concern is that if the module gets removed accidentally then it > could disrupt access to the remote device. The remote nature of the device >

Re: [PATCH 2/3] usb: host: pci: introduce PCI vendor ID for Netlogic

Am Mittwoch, den 14.03.2018, 16:44 +0100 schrieb Richard Leitner: > On 03/14/2018 04:27 PM, Oliver Neukum wrote: > > Am Mittwoch, den 14.03.2018, 14:31 +0100 schrieb Richard Leitner: > > > > > Well, but it does not. Removing a redundant definition is a clear > > ben

Re: [PATCH 2/3] usb: host: pci: introduce PCI vendor ID for Netlogic

Am Mittwoch, den 14.03.2018, 16:44 +0100 schrieb Richard Leitner: > On 03/14/2018 04:27 PM, Oliver Neukum wrote: > > Am Mittwoch, den 14.03.2018, 14:31 +0100 schrieb Richard Leitner: > > > > > Well, but it does not. Removing a redundant definition is a clear > > ben

Re: [PATCH 2/3] usb: host: pci: introduce PCI vendor ID for Netlogic

Am Mittwoch, den 14.03.2018, 14:31 +0100 schrieb Richard Leitner: > Hi Oliver, > thank you for your feedback! > > On 03/14/2018 01:17 PM, Oliver Neukum wrote: > > Am Mittwoch, den 14.03.2018, 11:29 +0100 schrieb Richard Leitner: > > > From: Richard Leitner &

Re: [PATCH 2/3] usb: host: pci: introduce PCI vendor ID for Netlogic

Am Mittwoch, den 14.03.2018, 14:31 +0100 schrieb Richard Leitner: > Hi Oliver, > thank you for your feedback! > > On 03/14/2018 01:17 PM, Oliver Neukum wrote: > > Am Mittwoch, den 14.03.2018, 11:29 +0100 schrieb Richard Leitner: > > > From: Richard Leitner > > &

Re: [PATCH 2/3] usb: host: pci: introduce PCI vendor ID for Netlogic

Am Mittwoch, den 14.03.2018, 11:29 +0100 schrieb Richard Leitner: > From: Richard Leitner > > Replace the hardcoded PCI vendor ID of Netlogic with a definition in > pci_ids.h Hi, in general, why? Does this patch generate any benefit for any developer reading the

Re: [PATCH 2/3] usb: host: pci: introduce PCI vendor ID for Netlogic

Am Mittwoch, den 14.03.2018, 11:29 +0100 schrieb Richard Leitner: > From: Richard Leitner > > Replace the hardcoded PCI vendor ID of Netlogic with a definition in > pci_ids.h Hi, in general, why? Does this patch generate any benefit for any developer reading the source? I don't see it. Does it

Re: [2/2] net/usb/ax88179_178a: Delete three unnecessary variables in ax88179_chk_eee()

Am Dienstag, den 13.03.2018, 08:24 +0100 schrieb SF Markus Elfring: > > > > > > > > Use three values directly for a condition check without assigning them > > > to intermediate variables. > > > > Hi, > > > > what is the benefit of this? > > I proposed a small source code reduction. > > Other

Re: [2/2] net/usb/ax88179_178a: Delete three unnecessary variables in ax88179_chk_eee()

Am Dienstag, den 13.03.2018, 08:24 +0100 schrieb SF Markus Elfring: > > > > > > > > Use three values directly for a condition check without assigning them > > > to intermediate variables. > > > > Hi, > > > > what is the benefit of this? > > I proposed a small source code reduction. > > Other

Re: [PATCH 2/2] net/usb/ax88179_178a: Delete three unnecessary variables in ax88179_chk_eee()

Am Samstag, den 10.03.2018, 19:26 +0100 schrieb SF Markus Elfring: > From: Markus Elfring > Date: Sat, 10 Mar 2018 18:53:28 +0100 > > Use three values directly for a condition check without assigning them > to intermediate variables. Hi, what is the benefit of

Re: [PATCH 2/2] net/usb/ax88179_178a: Delete three unnecessary variables in ax88179_chk_eee()

Am Samstag, den 10.03.2018, 19:26 +0100 schrieb SF Markus Elfring: > From: Markus Elfring > Date: Sat, 10 Mar 2018 18:53:28 +0100 > > Use three values directly for a condition check without assigning them > to intermediate variables. Hi, what is the benefit of this? It looks like needless code

Re: [PATCH v1 1/1] USB: serial: Add boundry check for read_urbs array access

Am Mittwoch, den 07.03.2018, 13:41 -0800 schrieb sathyanarayanan kuppuswamy : > > On 03/07/2018 12:58 PM, Greg KH wrote: > > So I don't see why your check is needed, what other code path would ever > > call this function in a way that the bounds check would be needed? > void

Re: [PATCH v1 1/1] USB: serial: Add boundry check for read_urbs array access

Am Mittwoch, den 07.03.2018, 13:41 -0800 schrieb sathyanarayanan kuppuswamy : > > On 03/07/2018 12:58 PM, Greg KH wrote: > > So I don't see why your check is needed, what other code path would ever > > call this function in a way that the bounds check would be needed? > void

Re: [RFC PATCH] cdc-acm: do not drop data from fast devices

On Mon, 2018-03-05 at 10:55 +0100, Romain Izard wrote: > The TTY buffer is 4096 bytes large, throttling when there are only 128 > free bytes left, and unthrottling when there are only 128 bytes available. > But the TTY buffer is filled from an intermediate flip buffer that > contains up to 64 KiB

Re: [RFC PATCH] cdc-acm: do not drop data from fast devices

On Mon, 2018-03-05 at 10:55 +0100, Romain Izard wrote: > The TTY buffer is 4096 bytes large, throttling when there are only 128 > free bytes left, and unthrottling when there are only 128 bytes available. > But the TTY buffer is filled from an intermediate flip buffer that > contains up to 64 KiB

Re: inconsistent lock state with usbnet/asix usb ethernet and xhci

On Mon, 2018-03-05 at 08:45 +0100, Marek Szyprowski wrote: > Hi Oliver, > > On 2018-02-27 17:07, Oliver Neukum wrote: > > Am Dienstag, den 27.02.2018, 07:13 -0800 schrieb Eric Dumazet: > >> On Tue, 2018-02-27 at 07:09 -0800, Eric Dumazet wrote: > >>> > >&

Re: inconsistent lock state with usbnet/asix usb ethernet and xhci

On Mon, 2018-03-05 at 08:45 +0100, Marek Szyprowski wrote: > Hi Oliver, > > On 2018-02-27 17:07, Oliver Neukum wrote: > > Am Dienstag, den 27.02.2018, 07:13 -0800 schrieb Eric Dumazet: > >> On Tue, 2018-02-27 at 07:09 -0800, Eric Dumazet wrote: > >>> > >&

Re: inconsistent lock state with usbnet/asix usb ethernet and xhci

Am Dienstag, den 27.02.2018, 07:13 -0800 schrieb Eric Dumazet: > On Tue, 2018-02-27 at 07:09 -0800, Eric Dumazet wrote: > > > > > > Note that for this one, it seems we also could perform stats updates in > > BH context, since skb is queued via defer_bh() > > > > But simplicity wins I guess. >

Re: inconsistent lock state with usbnet/asix usb ethernet and xhci

Am Dienstag, den 27.02.2018, 07:13 -0800 schrieb Eric Dumazet: > On Tue, 2018-02-27 at 07:09 -0800, Eric Dumazet wrote: > > > > > > Note that for this one, it seems we also could perform stats updates in > > BH context, since skb is queued via defer_bh() > > > > But simplicity wins I guess. >

Re: [PATCH] cdc_ether: flag the Cinterion PLS8 modem by gemalto as WWAN

activate a WWAN >     connection for a PDP context defined with AT+CGDCONT. UE supports >     two WWAN adapter. Both WWAN adapters can be activated a the same time > > Signed-off-by: Bassem Boubaker <bassem.bouba...@actia.fr> Acked-by: Oliver Neukum <oneu...@suse.com>

Re: [PATCH] cdc_ether: flag the Cinterion PLS8 modem by gemalto as WWAN

activate a WWAN >     connection for a PDP context defined with AT+CGDCONT. UE supports >     two WWAN adapter. Both WWAN adapters can be activated a the same time > > Signed-off-by: Bassem Boubaker Acked-by: Oliver Neukum

Re: [PATCH] cdc_ether: flag the Cinterion PLS8 modem by gemalto as WWAN

Am Dienstag, den 27.02.2018, 13:29 +0100 schrieb Bjørn Mork : > Bassem Boubaker writes: > > > > > +#define GEMALTO_VENDOR_ID 0x1e2d > > This is defined as CINTERION_VENDOR_ID in drivers/usb/serial/option.c. > > I have no idea which defintion is most correct, but I

Re: [PATCH] cdc_ether: flag the Cinterion PLS8 modem by gemalto as WWAN

Am Dienstag, den 27.02.2018, 13:29 +0100 schrieb Bjørn Mork : > Bassem Boubaker writes: > > > > > +#define GEMALTO_VENDOR_ID 0x1e2d > > This is defined as CINTERION_VENDOR_ID in drivers/usb/serial/option.c. > > I have no idea which defintion is most correct, but I believe the macros > should

Re: inconsistent lock state with usbnet/asix usb ethernet and xhci

Am Dienstag, den 27.02.2018, 08:26 +0100 schrieb Marek Szyprowski: Hi, > I've noticed that USBnet/ASIX AX88772B USB driver produces deplock kernel > warning ("inconsistent lock state") on Chromebook2 Peach-PIT board. No Is that 32 bit? > special activity is needed to reproduce this issue, it

Re: inconsistent lock state with usbnet/asix usb ethernet and xhci

Am Dienstag, den 27.02.2018, 08:26 +0100 schrieb Marek Szyprowski: Hi, > I've noticed that USBnet/ASIX AX88772B USB driver produces deplock kernel > warning ("inconsistent lock state") on Chromebook2 Peach-PIT board. No Is that 32 bit? > special activity is needed to reproduce this issue, it

Re: [PATCH v1 1/1] usb: cdc_acm: prevent race at write to acm while system resumes

et_from_fork+0x27/0x40 > [ 46.884566] ---[ end trace 3bd599058b8a9eb3 ]--- > > Signed-off-by: Sathyanarayanan Kuppuswamy > <sathyanarayanan.kuppusw...@intel.com> Acked-by: Oliver Neukum <oneu...@suse.com>

Re: [PATCH v1 1/1] usb: cdc_acm: prevent race at write to acm while system resumes

0 > [ 46.884549] [] process_one_work+0x148/0x440 > [ 46.884551] [] worker_thread+0x69/0x4a0 > [ 46.884554] [] ? max_active_store+0x80/0x80 > [ 46.884556] [] kthread+0x110/0x130 > [ 46.884559] [] ? kthread_park+0x60/0x60 > [ 46.884563] [] ret_from_fork+0x27/0x40 > [ 46.884566] ---[ end trace 3bd599058b8a9eb3 ]--- > > Signed-off-by: Sathyanarayanan Kuppuswamy > Acked-by: Oliver Neukum

Re: [PATCH 1/5] USB: serial: f81232: clear overrun flag

Am Montag, den 22.01.2018, 15:58 +0800 schrieb Ji-Ze Hong (Peter Hong) : > The F81232 will report data and LSR with bulk like following format: > bulk-in data: [LSR(1Byte)+DATA(1Byte)][LSR(1Byte)+DATA(1Byte)]... > > LSR will auto clear frame/parity/break error flag when reading by H/W, > but

Re: [PATCH 1/5] USB: serial: f81232: clear overrun flag

Am Montag, den 22.01.2018, 15:58 +0800 schrieb Ji-Ze Hong (Peter Hong) : > The F81232 will report data and LSR with bulk like following format: > bulk-in data: [LSR(1Byte)+DATA(1Byte)][LSR(1Byte)+DATA(1Byte)]... > > LSR will auto clear frame/parity/break error flag when reading by H/W, > but

[PATCH] media: usbtv: prevent double free in error case

gt; kfree(usbtv) (1st time) usbtv_video_fail: usb_set_intfdata(intf, NULL); usb_put_dev(usbtv->udev); kfree(usbtv); (2nd time) So, as we have refcounting, use it Reported-by: Yavuz, Tuba <t...@ece.ufl.edu> Signed-off-by: Oliver Neukum <oneu...@suse.com> CC:

[PATCH] media: usbtv: prevent double free in error case

gt; kfree(usbtv) (1st time) usbtv_video_fail: usb_set_intfdata(intf, NULL); usb_put_dev(usbtv->udev); kfree(usbtv); (2nd time) So, as we have refcounting, use it Reported-by: Yavuz, Tuba Signed-off-by: Oliver Neukum CC: sta...@vger.kernel.org --- drivers/media/us

Re: [PATCH v2 1/2] USB: serial: ark3116: Remove unused TIOCSSERIAL ioctl case.

Am Samstag, den 06.01.2018, 20:14 +0300 schrieb Mikhail Zaytsev: > The patch removes unused TIOCSSERIAL ioctl case and adds the default block > to the switch. This will make the ioctl return -ENOTTY to user space (e.g. > setserial), because TIOCSSERIAL really isn't supported for these devices >

Re: [PATCH v2 1/2] USB: serial: ark3116: Remove unused TIOCSSERIAL ioctl case.

Am Samstag, den 06.01.2018, 20:14 +0300 schrieb Mikhail Zaytsev: > The patch removes unused TIOCSSERIAL ioctl case and adds the default block > to the switch. This will make the ioctl return -ENOTTY to user space (e.g. > setserial), because TIOCSSERIAL really isn't supported for these devices >

Re: [RFC PATCH v2 03/13] bootsplash: Flush framebuffer after drawing

Am Dienstag, den 19.12.2017, 14:57 +0100 schrieb Daniel Vetter: > > Would you like me to extend the FB API or not? > > Yes. Well for real I'd like you to do kms, so maybe you need to explain > why exactly you absolutely have to use fbdev (aka which driver isn't > supported by drm that you want to

Re: [RFC PATCH v2 03/13] bootsplash: Flush framebuffer after drawing

Am Dienstag, den 19.12.2017, 14:57 +0100 schrieb Daniel Vetter: > > Would you like me to extend the FB API or not? > > Yes. Well for real I'd like you to do kms, so maybe you need to explain > why exactly you absolutely have to use fbdev (aka which driver isn't > supported by drm that you want to

Re: [PATCH] USB: serial: ark3116.c: Remove unused TIOCSSERIAL case from ioctl

Am Mittwoch, den 13.12.2017, 15:30 +0300 schrieb Mikhail Zaytsev: > On Wed, 13 Dec 2017 12:40:48 +0100 Oliver Neukum <oneu...@suse.com> wrote: > > > > > They give you nothing. If you are looking at a vendor ID nothing but the > > bare number makes sense. You are ju

Re: [PATCH] USB: serial: ark3116.c: Remove unused TIOCSSERIAL case from ioctl

Am Mittwoch, den 13.12.2017, 15:30 +0300 schrieb Mikhail Zaytsev: > On Wed, 13 Dec 2017 12:40:48 +0100 Oliver Neukum wrote: > > > > > They give you nothing. If you are looking at a vendor ID nothing but the > > bare number makes sense. You are just making peoples' life h

Re: [PATCH] USB: serial: ark3116.c: Remove unused TIOCSSERIAL case from ioctl

Am Mittwoch, den 13.12.2017, 14:31 +0300 schrieb Mikhail Zaytsev: > On Wed, 13 Dec 2017 11:17:28 +0100 Oliver Neukum <oneu...@suse.com> wrote: > > > > > Am Mittwoch, den 13.12.2017, 12:30 +0300 schrieb Mikhail Zaytsev: > > > > > > +#define RS232_VENDOR

Re: [PATCH] USB: serial: ark3116.c: Remove unused TIOCSSERIAL case from ioctl

Am Mittwoch, den 13.12.2017, 14:31 +0300 schrieb Mikhail Zaytsev: > On Wed, 13 Dec 2017 11:17:28 +0100 Oliver Neukum wrote: > > > > > Am Mittwoch, den 13.12.2017, 12:30 +0300 schrieb Mikhail Zaytsev: > > > > > > +#define RS232_VENDOR 0x6547 > > >

Re: [PATCH] USB: serial: ark3116.c: Remove unused TIOCSSERIAL case from ioctl

Am Mittwoch, den 13.12.2017, 12:30 +0300 schrieb Mikhail Zaytsev: > +#define RS232_VENDOR 0x6547 > +#define RS232_PRODUCT 0x0232 > +#define IRDA_VENDOR 0x18ec > +#define IRDA_PRODUCT 0x3118 >   >  /* usb timeout of 1 second */ >  #define ARK_TIMEOUT 1000 >   >  static const struct usb_device_id

Re: [PATCH] USB: serial: ark3116.c: Remove unused TIOCSSERIAL case from ioctl

Am Mittwoch, den 13.12.2017, 12:30 +0300 schrieb Mikhail Zaytsev: > +#define RS232_VENDOR 0x6547 > +#define RS232_PRODUCT 0x0232 > +#define IRDA_VENDOR 0x18ec > +#define IRDA_PRODUCT 0x3118 >   >  /* usb timeout of 1 second */ >  #define ARK_TIMEOUT 1000 >   >  static const struct usb_device_id

Re: [BUG] kaweth: a possible sleep-in-atomic bug in kaweth_start_xmit

Am Mittwoch, den 13.12.2017, 16:57 +0800 schrieb Jia-Ju Bai: > According to drivers/net/usb/kaweth.c, the driver may sleep under a > spinlock. > The function call path is: > kaweth_start_xmit (acquire the spinlock) >kaweth_async_set_rx_mode > kaweth_control >

Re: [BUG] kaweth: a possible sleep-in-atomic bug in kaweth_start_xmit

Am Mittwoch, den 13.12.2017, 16:57 +0800 schrieb Jia-Ju Bai: > According to drivers/net/usb/kaweth.c, the driver may sleep under a > spinlock. > The function call path is: > kaweth_start_xmit (acquire the spinlock) >kaweth_async_set_rx_mode > kaweth_control >

Re: USB: hub: Delete an error message for a failed memory allocation in usb_hub_clear_tt_buffer()

Am Donnerstag, den 07.12.2017, 09:56 +0100 schrieb Greg Kroah-Hartman: > On Thu, Dec 07, 2017 at 09:45:38AM +0100, Geert Uytterhoeven wrote: > > > > A few comments (this is in response to a patch from Markus, so there have > > to be lots of questions and uncertainties ;-) > > Note, because of

Re: USB: hub: Delete an error message for a failed memory allocation in usb_hub_clear_tt_buffer()

Am Donnerstag, den 07.12.2017, 09:56 +0100 schrieb Greg Kroah-Hartman: > On Thu, Dec 07, 2017 at 09:45:38AM +0100, Geert Uytterhoeven wrote: > > > > A few comments (this is in response to a patch from Markus, so there have > > to be lots of questions and uncertainties ;-) > > Note, because of

Re: [PATCH] usb: core: Add "quirks" parameter for usbcore

Am Mittwoch, den 06.12.2017, 17:09 +0800 schrieb Kai-Heng Feng: > Now users can use "usbcore.quirks=" as short term workaround before the > next kernel release. > > This is inspired by usbhid and usb-storage. Hi, if you include this for debugging purposes, it would be interesting to be able to

Re: [PATCH] usb: core: Add "quirks" parameter for usbcore

Am Mittwoch, den 06.12.2017, 17:09 +0800 schrieb Kai-Heng Feng: > Now users can use "usbcore.quirks=" as short term workaround before the > next kernel release. > > This is inspired by usbhid and usb-storage. Hi, if you include this for debugging purposes, it would be interesting to be able to

Re: question about usb_rebind_intf

Am Freitag, den 17.11.2017, 13:21 -0500 schrieb Alan Stern: > > The real fix would be to change the interface drivers by adding proper > support for reset-resume.  Otherwise there will always be a time window > following resume during which the interface is non-functional. Very hard to do with

Re: question about usb_rebind_intf

Am Freitag, den 17.11.2017, 13:21 -0500 schrieb Alan Stern: > > The real fix would be to change the interface drivers by adding proper > support for reset-resume.  Otherwise there will always be a time window > following resume during which the interface is non-functional. Very hard to do with

Re: WARNING in usb_submit_urb

, it gets set because uurb > (which is passed from user space) has USBDEVFS_URB_ISO_ASAP flag set > when passed to proc_do_submiturb(). Hi, yes we should filter better. Could you test? Regards Oliver From 6026435970e0d34def0abc71879bbd6fea6e8ec1 Mon Sep 17 00:00:00 2

Re: WARNING in usb_submit_urb

, it gets set because uurb > (which is passed from user space) has USBDEVFS_URB_ISO_ASAP flag set > when passed to proc_do_submiturb(). Hi, yes we should filter better. Could you test? Regards Oliver From 6026435970e0d34def0abc71879bbd6fea6e8ec1 Mon Sep 17 00:00:00 2

Re: [RFC 00/14] Kernel based bootsplash

Am Donnerstag, den 09.11.2017, 12:56 +0100 schrieb Pavel Machek: > > "More reliable bootsplash" seems like an anti-goal. More reliable boot > should be the goal... > > You should be able to display nice splash screen from initrd... > > We may want to fix the blinking cursor. > > But if there

Re: [RFC 00/14] Kernel based bootsplash

Am Donnerstag, den 09.11.2017, 12:56 +0100 schrieb Pavel Machek: > > "More reliable bootsplash" seems like an anti-goal. More reliable boot > should be the goal... > > You should be able to display nice splash screen from initrd... > > We may want to fix the blinking cursor. > > But if there

Re: [PATCH] net: usb: asix: fill null-ptr-deref in asix_suspend

Am Montag, den 06.11.2017, 17:05 +0100 schrieb Andrey Konovalov: > On Mon, Nov 6, 2017 at 4:20 PM, Oliver Neukum <oneu...@suse.com> wrote: > > > I do have a way to reproduce this. > > As far as I understand, for this particular device ax88172_bind() is > called, wh

Re: [PATCH] net: usb: asix: fill null-ptr-deref in asix_suspend

Am Montag, den 06.11.2017, 17:05 +0100 schrieb Andrey Konovalov: > On Mon, Nov 6, 2017 at 4:20 PM, Oliver Neukum wrote: > > > I do have a way to reproduce this. > > As far as I understand, for this particular device ax88172_bind() is > called, which doesn't assign anythin

Re: [PATCH] net: usb: asix: fill null-ptr-deref in asix_suspend

Am Montag, den 06.11.2017, 13:30 +0100 schrieb Andrey Konovalov: > On Mon, Nov 6, 2017 at 10:49 AM, Oliver Neukum <oneu...@suse.com> wrote: > > > > > > 2. Will a device work after that? The appropriate fix may be to wait > > until the device is properly initia

Re: [PATCH] net: usb: asix: fill null-ptr-deref in asix_suspend

Am Montag, den 06.11.2017, 13:30 +0100 schrieb Andrey Konovalov: > On Mon, Nov 6, 2017 at 10:49 AM, Oliver Neukum wrote: > > > > > > 2. Will a device work after that? The appropriate fix may be to wait > > until the device is properly initialized. > > This sho

Re: [PATCH] net: usb: asix: fill null-ptr-deref in asix_suspend

Am Donnerstag, den 02.11.2017, 21:26 +0100 schrieb Andrey Konovalov: > When asix_suspend() is called dev->driver_priv might not have been > assigned a value, so we need to check that it's not NULL. > > Found by syzkaller. Hi, 1. if that happens on suspend, it will also happen on resume 2. Will

Re: [PATCH] net: usb: asix: fill null-ptr-deref in asix_suspend

Am Donnerstag, den 02.11.2017, 21:26 +0100 schrieb Andrey Konovalov: > When asix_suspend() is called dev->driver_priv might not have been > assigned a value, so we need to check that it's not NULL. > > Found by syzkaller. Hi, 1. if that happens on suspend, it will also happen on resume 2. Will

Re: [PATCH] drivers/net/usb: add device id for TP-LINK UE300 USB 3.0 Ethernet

Am Montag, den 23.10.2017, 18:10 +0800 schrieb Ran Wang: > This product is named 'TP-LINK USB 3.0 Gigabit Ethernet Network > Adapter (Model No.is UE300)'. It uses chip RTL8153 and works with > driver drivers/net/usb/r8152.c > Hi, just for the record, have you confirm that it fails with

Re: [PATCH] drivers/net/usb: add device id for TP-LINK UE300 USB 3.0 Ethernet

Am Montag, den 23.10.2017, 18:10 +0800 schrieb Ran Wang: > This product is named 'TP-LINK USB 3.0 Gigabit Ethernet Network > Adapter (Model No.is UE300)'. It uses chip RTL8153 and works with > driver drivers/net/usb/r8152.c > Hi, just for the record, have you confirm that it fails with

Re: [PATCH 07/58] net/usb/usbnet: Convert timers to use timer_setup()

om > both a timer and a tasklet, adjust the tasklet to pass the timer address > too. When tasklets have their .data field removed, this can be refactored > to call a central function after resolving the correct container_of() for a > separate callback function for timer and tasklet. > &

Re: [PATCH 07/58] net/usb/usbnet: Convert timers to use timer_setup()

om > both a timer and a tasklet, adjust the tasklet to pass the timer address > too. When tasklets have their .data field removed, this can be refactored > to call a central function after resolving the correct container_of() for a > separate callback function for timer and tasklet. > &

Re: [PATCH] usb: cdc_acm: Add quirk for Elatec TWN3

: probe of 1-1.2:1.0 failed with error -22 > > Adding the NO_UNION_NORMAL quirk for the device fixes the issue. > > Signed-off-by: Maksim Salau <msa...@iotecha.com> Acked-by: Oliver Neukum <oneu...@suse.com>

Re: [PATCH] usb: cdc_acm: Add quirk for Elatec TWN3

: probe of 1-1.2:1.0 failed with error -22 > > Adding the NO_UNION_NORMAL quirk for the device fixes the issue. > > Signed-off-by: Maksim Salau Acked-by: Oliver Neukum

Re: [PATCH V2] r8152: add Linksys USB3GIGV1 id

Am Dienstag, den 26.09.2017, 08:19 -0700 schrieb Doug Anderson: > > I know that for at least some of the adapters in the CDC Ethernet > blacklist it was claimed that the CDC Ethernet support in the adapter > was kinda broken anyway so the blacklist made sense. ...but for the > Linksys Gigabit

Re: [PATCH V2] r8152: add Linksys USB3GIGV1 id

Am Dienstag, den 26.09.2017, 08:19 -0700 schrieb Doug Anderson: > > I know that for at least some of the adapters in the CDC Ethernet > blacklist it was claimed that the CDC Ethernet support in the adapter > was kinda broken anyway so the blacklist made sense. ...but for the > Linksys Gigabit

Re: [PATCH] r8152: add Linksys USB3GIGV1 id

Am Freitag, den 22.09.2017, 12:06 -0700 schrieb Grant Grundler: > This Linksys dongle by default comes up in cdc_ether mode. > This patch allows r8152 to claim the device: >    Bus 002 Device 002: ID 13b1:0041 Linksys Hi, have you tested this in case cdc_ether is for some reason already loaded?

Re: [PATCH] r8152: add Linksys USB3GIGV1 id

Am Freitag, den 22.09.2017, 12:06 -0700 schrieb Grant Grundler: > This Linksys dongle by default comes up in cdc_ether mode. > This patch allows r8152 to claim the device: >    Bus 002 Device 002: ID 13b1:0041 Linksys Hi, have you tested this in case cdc_ether is for some reason already loaded?

Re: [RFC PATCH 2/3] usbnet: Avoid potential races in usbnet_deferred_kevent()

Am Dienstag, den 19.09.2017, 13:53 -0700 schrieb Doug Anderson: > Hi, > > On Tue, Sep 19, 2017 at 1:37 PM, Oliver Neukum <oneu...@suse.com> wrote: > > > > Am Dienstag, den 19.09.2017, 09:15 -0700 schrieb Douglas Anderson: > > > > > > In

Re: [RFC PATCH 2/3] usbnet: Avoid potential races in usbnet_deferred_kevent()

Am Dienstag, den 19.09.2017, 13:53 -0700 schrieb Doug Anderson: > Hi, > > On Tue, Sep 19, 2017 at 1:37 PM, Oliver Neukum wrote: > > > > Am Dienstag, den 19.09.2017, 09:15 -0700 schrieb Douglas Anderson: > > > > > > In general when you've got a f

Re: [RFC PATCH 2/3] usbnet: Avoid potential races in usbnet_deferred_kevent()

Am Dienstag, den 19.09.2017, 13:51 -0700 schrieb Guenter Roeck: > On Tue, Sep 19, 2017 at 1:37 PM, Oliver Neukum <oneu...@suse.com> wrote: > > > > Am Dienstag, den 19.09.2017, 09:15 -0700 schrieb Douglas Anderson: > > > [..] > > > NOTES: > > > -

Re: [RFC PATCH 2/3] usbnet: Avoid potential races in usbnet_deferred_kevent()

Am Dienstag, den 19.09.2017, 13:51 -0700 schrieb Guenter Roeck: > On Tue, Sep 19, 2017 at 1:37 PM, Oliver Neukum wrote: > > > > Am Dienstag, den 19.09.2017, 09:15 -0700 schrieb Douglas Anderson: > > > [..] > > > NOTES: > > > - No known bugs are fixed b

Re: [RFC PATCH 2/3] usbnet: Avoid potential races in usbnet_deferred_kevent()

Am Dienstag, den 19.09.2017, 09:15 -0700 schrieb Douglas Anderson: > In general when you've got a flag communicating that "something needs > to be done" you want to clear that flag _before_ doing the task. If > you clear the flag _after_ doing the task you end up with the risk > that this will

Re: [RFC PATCH 2/3] usbnet: Avoid potential races in usbnet_deferred_kevent()

Am Dienstag, den 19.09.2017, 09:15 -0700 schrieb Douglas Anderson: > In general when you've got a flag communicating that "something needs > to be done" you want to clear that flag _before_ doing the task. If > you clear the flag _after_ doing the task you end up with the risk > that this will

Re: [RFC PATCH 1/3] usbnet: Get rid of spammy usbnet "kevent X may have been dropped"

; can just keep an atomic count for that type of work and add a loop > into usbnet_deferred_kevent(). Thanks for doing this, it is overdue. Regards Oliver > Signed-off-by: Douglas Anderson <diand...@chromium.org> Acked-by: Oliver Neukum <oneu...@suse.com>

<    1   2   3   4   5   6   7   8   9   10   >