Re: [PATCH 1/3] usb: dwc3: gadget: Prevent losing events in event cache

Hi Felipe, On 4/11/2017 11:31 PM, Felipe Balbi wrote: Hi, (Thinh, for whatever I didn't receive your email via the list, replying to myself) Could it be because of the attached file? Felipe Balbi writes: Hmm, can you apply this patch and provide output when the

RE: [PATCH v3] smsc95xx: Add comments to the registers definition

> I based my comments on the datasheet. For the LED_GPIO_CFG register, the > datasheet says: > > This register configures the external GPIO[2:0] pins. > > QFN package description also indicates GPIOs 0, 1 & 2. > As an example for the LAN9514, pin 22 of the QFN indicates: > > nSPD_LED/GPIO2 > >

[PATCH] xhci: switch to pci_alloc_irq_vectors

Use the modern API to request MSI or MSI-X interrupts, which allows us to get rid of the msix_entries array, as well as cleaning up the cleanup code. Signed-off-by: Christoph Hellwig --- drivers/usb/host/xhci.c | 99 ++---

Re: [PATCH v3] smsc95xx: Add comments to the registers definition

On 12/04/17 14:25, woojung@microchip.com wrote: > > +/* LED General Purpose IO Configuration Register */ > > +#define LED_GPIO_CFG (0x24) > > +#define LED_GPIO_CFG_SPD_LED (0x0100)/* GPIO2 as SPD LED > > */ > > +#define LED_GPIO_CFG_LNK_LED (0x0010)/*

Re: v4.10-rc8 (-rc6) boot regression on Intel desktop, does not boot after cold boots, boots after reboot

On Mon, Apr 03, 2017 at 08:20:50PM +0200, Pavel Machek wrote: > > > > > > ...1d.7: PCI fixup... pass 2 > > > > > > ...1d.7: PCI fixup... pass 3 > > > > > > ...1d.7: PCI fixup... pass 3 done > > > > > > > > > > > > ...followed by hang. So yes, it looks USB related. > > > > > > > > > > > >

Re: [PATCH 1/3] usb: dwc3: gadget: Prevent losing events in event cache

On Wed, Apr 12, 2017 at 1:13 AM, Felipe Balbi wrote: > > Hi, > > John Youn writes: John Youn writes: >> Thinh Nguyen writes: >>> The dwc3 driver can overwite its previous events if its top

Re: [PATCH v3] smsc95xx: Add comments to the registers definition

From: Martin Wetterwald Date: Wed, 12 Apr 2017 11:24:05 +0200 > This chip is used by a lot of embedded devices and also by the Raspberry > Pi 1, 2 & 3 which were created to promote the study of computer > sciences. Students wanting to learn kernel / network device driver >

Re: [PATCH v3 1/3] usb: udc: allow adding and removing the same gadget device

On Wed, 12 Apr 2017, Felipe Balbi wrote: > >> Maybe... But I can't shake the feeling that Greg KH would strongly > >> disagree. Hasn't he said, many times in the past, that any dynamically > >> allocated device structure _must_ have a real release routine? > >> usb_udc_nop_release() doesn't

RE: [PATCH v3] smsc95xx: Add comments to the registers definition

> +/* LED General Purpose IO Configuration Register */ > +#define LED_GPIO_CFG (0x24) > +#define LED_GPIO_CFG_SPD_LED (0x0100)/* GPIO2 as SPD LED > */ > +#define LED_GPIO_CFG_LNK_LED (0x0010)/* GPIO1 as LNK LED > */ > +#define LED_GPIO_CFG_FDX_LED (0x0001)/* GPIO0

Re: [PATCH] chipidea: Fix issue in reconnecing gadget without insmod/rmmod

On Wed, Apr 12, 2017 at 5:21 PM, Peter Chen wrote: > On Tue, Apr 11, 2017 at 08:46:24PM +0530, Niranjan Dighe wrote: >> Currently usb_gadget_connect() is called only through gadget >> registration via composite_driver_probe(). As a result, after a >> disconnection, if the

Re: [PATCH v3] smsc95xx: Add comments to the registers definition

On Wed, Apr 12, 2017 at 11:24:05AM +0200, Martin Wetterwald wrote: > This chip is used by a lot of embedded devices and also by the Raspberry > Pi 1, 2 & 3 which were created to promote the study of computer > sciences. Students wanting to learn kernel / network device driver > programming through

Re: [PATCH] chipidea: Fix issue in reconnecing gadget without insmod/rmmod

On Tue, Apr 11, 2017 at 08:46:24PM +0530, Niranjan Dighe wrote: > Currently usb_gadget_connect() is called only through gadget > registration via composite_driver_probe(). As a result, after a > disconnection, if the role transitions to host and back to gadget, > the gadget is not recognized by

Re: [PATCH v2] ARM: davinci: Add the clock for the CPPI 4.1 DMA engine

On Friday 07 April 2017 11:01 PM, Alexandre Bailon wrote: > > > On 04/07/2017 06:15 PM, Alexandre Bailon wrote: >> >> >> On 04/07/2017 04:36 PM, Sekhar Nori wrote: >>> On Wednesday 05 April 2017 10:47 PM, Alexandre Bailon wrote: The CPPI 4.1 DMA is sharing its clock with the USB OTG,

RE: [PATCH 3/3] usb: dwc3: ep0: improve handling of unaligned OUT requests

Hi, David Laight writes: > From: Felipe Balbi >> David Laight writes: >> >> > From: Felipe Balbi >> >> >> Sent: 07 April 2017 12:37 >> >> >> Just like we did for all other endpoint types, let's rely on a chained >> >> >> TRB pointing to

RE: [PATCH 3/3] usb: dwc3: ep0: improve handling of unaligned OUT requests

From: Felipe Balbi > David Laight writes: > >> > From: Felipe Balbi > >> >> Sent: 07 April 2017 12:37 > >> >> Just like we did for all other endpoint types, let's rely on a chained > >> >> TRB pointing to ep0_bounce_addr in order to align transfer size. This > >> >> will

RE: [PATCH 3/3] usb: dwc3: ep0: improve handling of unaligned OUT requests

Hi, David Laight writes: >> > From: Felipe Balbi >> >> Sent: 07 April 2017 12:37 >> >> Just like we did for all other endpoint types, let's rely on a chained >> >> TRB pointing to ep0_bounce_addr in order to align transfer size. This >> >> will make the code simpler. >>

RE: [PATCH 3/3] usb: dwc3: ep0: improve handling of unaligned OUT requests

Hi, David Laight writes: > From: Felipe >> Sent: 12 April 2017 06:57 >> Felipe Balbi writes: >> >> From: Felipe Balbi >> >>> Sent: 07 April 2017 12:37 >> >>> Just like we did for all other endpoint types, let's rely on a chained >> >>>

RE: [PATCH 3/3] usb: dwc3: ep0: improve handling of unaligned OUT requests

From: Felipe > Sent: 12 April 2017 06:57 > Felipe Balbi writes: > >> From: Felipe Balbi > >>> Sent: 07 April 2017 12:37 > >>> Just like we did for all other endpoint types, let's rely on a chained > >>> TRB pointing to ep0_bounce_addr in order to align transfer

RE: [PATCH 3/3] usb: dwc3: ep0: improve handling of unaligned OUT requests

From: Felipe Balbi > Sent: 12 April 2017 06:55 > David Laight writes: > > > From: Felipe Balbi > >> Sent: 07 April 2017 12:37 > >> Just like we did for all other endpoint types, let's rely on a chained > >> TRB pointing to ep0_bounce_addr in order to align transfer size.

Re: [PATCH v3] smsc95xx: Add comments to the registers definition

On 12 April 2017 at 10:24, Martin Wetterwald wrote: > This chip is used by a lot of embedded devices and also by the Raspberry > Pi 1, 2 & 3 which were created to promote the study of computer > sciences. Students wanting to learn kernel / network device driver > programming

[PATCH v3] smsc95xx: Add comments to the registers definition

This chip is used by a lot of embedded devices and also by the Raspberry Pi 1, 2 & 3 which were created to promote the study of computer sciences. Students wanting to learn kernel / network device driver programming through those devices can only rely on the Linux kernel driver source to make

Re: [PATCH 7/9] usbip: Add USB_SPEED_SUPER as valid arg

Am Mittwoch, den 12.04.2017, 07:13 +0800 schrieb Yuyang Du: > With this patch, USB_SPEED_SUPER is a valid speed when attaching > a USB3 SuperSpeed device. > Hi, sorry this is just short sighted. If you do this, also add SS+ Regards Oliver -- To unsubscribe from this

Re: [PATCH 2/9] usbip: vhci-hcd: Add vhci struct

Am Mittwoch, den 12.04.2017, 07:13 +0800 schrieb Yuyang Du: > In order to support SuperSpeed devices, a USB3 HCD is added to > share the USB2 HCD. As a result, a "VHCI" is composed of two > vhci_hcds associated with the two HCDs respectively. So we add > another level of abstraction, vhci, and

[REGRESSION next-20170410] Commit a6ff6cbf1fab ("usb: xhci: Add helper function xhci_set_power_on().") breaks armada-385

Hi Guoqing Zhang, Commit a6ff6cbf1fabe7500d8ac25e133e3346db0a0fca ("usb: xhci: Add helper function xhci_set_power_on().") causes a null pointer dereference on an armada-385. Below the kernel as well as the bisect log. Regards Ralph [2.481636] Unable to handle kernel NULL pointer

Re: [PATCH v3 1/3] usb: udc: allow adding and removing the same gadget device

Hi, Greg KH writes: >> Here's what we have for most UDCs (net2280.c included): >> >> struct my_udc { >> struct gadget gadget; >> [...] >> }; >> >> probe() >> { >> struct my_udc *u; >> >> u =

Re: [PATCH 1/3] usb: dwc3: gadget: Prevent losing events in event cache

On 04/11/2017 11:14 PM, Felipe Balbi wrote: > > Hi, > > John Youn writes: John Youn writes: >> Thinh Nguyen writes: >>> The dwc3 driver can overwite its previous events if its top half IRQ >>> handler

[PATCH 9/9] usbip: vhci-hcd: Clean up the code by adding a new macro

Each vhci has 2*VHCI_HC_PORTS ports, in which VHCI_HC_PORTS ports are HighSpeed (or below), and VHCI_HC_PORTS are SuperSpeed. This new macro VHCI_PORTS reflects this configuration. Signed-off-by: Yuyang Du --- drivers/usb/usbip/vhci.h | 5 -

[PATCH 8/9] usbip: vhci-hcd: Add USB3 port status bits

As USB3 has (slightly) different bit meanings in the port status. Add a new status bit array for USB3. Signed-off-by: Yuyang Du --- drivers/usb/usbip/vhci_hcd.c | 56 +++- 1 file changed, 50 insertions(+), 6 deletions(-) diff --git

[PATCH 0/9] usbip: Enable USB3 SuperSpeed

Hi Shuah, SuperSpeed (only) USB devices cannot be shared via usbip. This patch series attempts to fix it. The first 5 patches refactors the existing code to prepare for the SuperSpeed addition. With this series, our SuperSpeed device works fine. Many thanks to Greg and Krzysztof for their

[PATCH 6/9] usbip: vhci-hcd: Add USB3 SuperSpeed support

This patch adds a USB3 HCD to an existing USB2 HCD and provides the support of SuperSpeed, in case the device can only be enumerated with SuperSpeed. The bulk of the added code in usb3_bos_desc and hub_control to support SuperSpeed is borrowed from the commit 1cd8fd2887e162ad ("usb: gadget:

[PATCH 7/9] usbip: Add USB_SPEED_SUPER as valid arg

With this patch, USB_SPEED_SUPER is a valid speed when attaching a USB3 SuperSpeed device. Signed-off-by: Yuyang Du --- drivers/usb/usbip/vhci_sysfs.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/usb/usbip/vhci_sysfs.c b/drivers/usb/usbip/vhci_sysfs.c index

[PATCH 5/9] usbip: vhci-hcd: Set the vhci structure up to work

This patch enables the new vhci structure. Its lock protects both the USB2 hub and the shared USB3 hub. Signed-off-by: Yuyang Du --- drivers/usb/usbip/vhci.h | 2 - drivers/usb/usbip/vhci_hcd.c | 206 -

[PATCH 1/9] usbip: vhci-hcd: Rename function names to reflect their struct names

These helper function names are renamed to have their full struct names to avoid confusion: - hcd_to_vhci() -> hcd_to_vhci_hcd() - vhci_to_hcd() -> vhci_hcd_to_hcd() - vdev_to_vhci() -> vdev_to_vhci_hcd() Signed-off-by: Yuyang Du --- drivers/usb/usbip/vhci.h | 11

[PATCH 2/9] usbip: vhci-hcd: Add vhci struct

In order to support SuperSpeed devices, a USB3 HCD is added to share the USB2 HCD. As a result, a "VHCI" is composed of two vhci_hcds associated with the two HCDs respectively. So we add another level of abstraction, vhci, and thus this vhci structure. Signed-off-by: Yuyang Du

[PATCH 3/9] usbip: vhci-hcd: Move VHCI platform device into vhci struct

Every VHCI is a platform device, so move the platform_device struct into the VHCI struct. Signed-off-by: Yuyang Du --- drivers/usb/usbip/vhci.h | 3 ++- drivers/usb/usbip/vhci_hcd.c | 17 - drivers/usb/usbip/vhci_sysfs.c | 6 +++--- 3 files

[PATCH 4/9] usbip: vhci-hcd: Rework vhci_hcd_init

A vhci struct is added as the platform-specific data to the vhci platform device, in order to get the vhci by its platform device. This is done in vhci_hcd_init(). Signed-off-by: Yuyang Du --- drivers/usb/usbip/vhci_hcd.c | 51

Re: [PATCH v3 1/3] usb: udc: allow adding and removing the same gadget device

On Wed, Apr 12, 2017 at 09:01:44AM +0300, Felipe Balbi wrote: > > Hi, > > Greg KH writes: > > On Tue, Apr 11, 2017 at 10:12:01AM -0400, Alan Stern wrote: > >> On Tue, 11 Apr 2017, Felipe Balbi wrote: > >> > >> > > Oddly enough, yes. But it doesn't explain why this code doesn't

Re: [PATCH 1/3] usb: dwc3: gadget: Prevent losing events in event cache

Hi, (Thinh, for whatever I didn't receive your email via the list, replying to myself) Felipe Balbi writes: >> Hmm, can you apply this patch and provide output when the failure >> happens? I suggest setting up a 100MiB trace buffer. You don't need to >> enable any tracers nor

Re: [PATCH 1/3] usb: dwc3: gadget: Prevent losing events in event cache

Hi, John Youn writes: >>> John Youn writes: > Thinh Nguyen writes: >> The dwc3 driver can overwite its previous events if its top half IRQ >> handler gets invoked again before processing the events in the

Re: [PATCH 1/3] usb: dwc3: gadget: Prevent losing events in event cache

Hi, John Youn writes: >> John Youn writes: Thinh Nguyen writes: > The dwc3 driver can overwite its previous events if its top half IRQ > handler gets invoked again before processing the events in the

Re: [PATCH 1/3] usb: dwc3: gadget: Prevent losing events in event cache

Hi, John Youn writes: Do you think we introduce this when adding evt->cache in TH? Even without evt->cache we still could overwrite evt->count - so, was that seen before evt->cache? >>> >>> The multiple TH calls could have happened even before we

Re: [PATCH 2/3] usb: dwc3: gadget: Fix early exit in set/clear ep halt

Hi, Thinh Nguyen writes: Felipe Balbi writes: > Thinh Nguyen writes: >> This patch fixes a commit that causes a hang from device waiting for >> data with the wrong sequence number. The commit ffb80fc672c3

Re: [PATCH v3 1/3] usb: udc: allow adding and removing the same gadget device

Hi, Greg KH writes: > On Tue, Apr 11, 2017 at 10:12:01AM -0400, Alan Stern wrote: >> On Tue, 11 Apr 2017, Felipe Balbi wrote: >> >> > > Oddly enough, yes. But it doesn't explain why this code doesn't blow >> > > up every time it gets called, in its current form. >> > >> >