Re: g_mass_storage not queueing requests

Hi, Felipe Balbi writes: >>> get_next_command() still sees bh->state != BUF_STATE_FULL. >>> [ 34.123286] ===> sleep_thread 634: caller fsg_main_thread+0xaa1/0xb00 [usb_f_mass_storage]: going to sleep [ 34.123289] ===> sleep_thread 634: caller

Re: [PATCH v2] usb: gadget: Add per-lun inquiry string

Hi, On 08/15/2016 10:37 AM, Philipp Gesang wrote: > Ping. > > @Krzysztof The resubmitted patch bounced from the Cc: to you due > to your MX blocking one of our hosters. I can resend in case you > didn’t receive the mail from the list. Sorry for my late response but I have been out of office for

Re: g_mass_storage not queueing requests

Hi Alan, Felipe Balbi writes: > Hi, > > Alan Stern writes: >> On Sat, 3 Sep 2016, Felipe Balbi wrote: >> >>> Hi, >>> >>> Alan Stern writes: >>> > On Fri, 2 Sep 2016, Felipe Balbi wrote: >>> > >>> >> >>> >>

Re: Memory barrier needed with wake_up_process()?

On Sat, Sep 03, 2016 at 12:16:29AM +0200, Peter Zijlstra wrote: > On Sat, Sep 03, 2016 at 12:14:13AM +0200, Peter Zijlstra wrote: > > On Fri, Sep 02, 2016 at 04:16:54PM -0400, Alan Stern wrote: > > > > > > Actually, that's not entirely true (although presumably it works okay > > > for most

Re: g_mass_storage not queueing requests

Hi, Felipe Balbi writes: [...] >> get_next_command() still sees bh->state != BUF_STATE_FULL. >> >>> [ 34.123286] ===> sleep_thread 634: caller fsg_main_thread+0xaa1/0xb00 >>> [usb_f_mass_storage]: going to sleep >>> [ 34.123289] ===> sleep_thread 634: caller

Re: g_mass_storage not queueing requests

Hi, Felipe Balbi writes: [..] > okay, I found the one place where changing smp_wmb() to smp_mb() solves > the problem > > @@ -395,7 +395,7 @@ static int fsg_set_halt(struct fsg_dev *fsg, struct > usb_ep *ep) > /* Caller must hold fsg->lock */ > static void

Re: [uas] ORICO 2588US3 USB HDD enclosure goes offline after idle

On 05.09.2016 14:19, Oliver Neukum wrote: You add the device to the kernel quirks list. But if you don't use autosuspend, the point is moot. The device does get spinned down (after not using it for a while, I have to wait before it responds for the first time), but not sure which method is

Re: [uas] ORICO 2588US3 USB HDD enclosure goes offline after idle

On 05.09.2016 13:42, Oliver Neukum wrote: This very much looks like power saving misbehaving. It does. But it doesn't seem like my distro enables autosuspend there by default. Are you using autosuspend on this device? $ lsusb ... Bus 002 Device 002: ID 357d:7788 Sharkoon QuickPort XT

Re: [uas] ORICO 2588US3 USB HDD enclosure goes offline after idle

On Sun, 2016-09-04 at 01:40 +0300, Dmitry Gutov wrote: > Hi all, > > The external HDD enclosure I've bought recently stops responding after > it's been idle for ~5 minutes. Excerpt from typical dmesg output > attached (the "Valid eCryptfs headers" are irrelevant, and there for > completeness).

Re: [PATCH 17/44] usb: host: xhci-tegra: don't print on ENOMEM

On Thu, Aug 25, 2016 at 07:39:09PM +0200, Wolfram Sang wrote: > All kmalloc-based functions print enough information on failures. > > Signed-off-by: Wolfram Sang > --- > drivers/usb/host/xhci-tegra.c | 1 - > 1 file changed, 1 deletion(-) Acked-by: Thierry Reding

Re: [PATCH V4] leds: trigger: Introduce an USB port trigger

On 4 September 2016 at 02:24, Alan Stern wrote: > On Sat, 3 Sep 2016, Jacek Anaszewski wrote: > >> >> The remaining issue is the sysfs interface design for defining and >> >> presenting multiple USB ports. I'm still in favour of a single >> >> attribute with space

Re: [uas] ORICO 2588US3 USB HDD enclosure goes offline after idle

On Mon, 2016-09-05 at 14:01 +0300, Dmitry Gutov wrote: > On 05.09.2016 13:42, Oliver Neukum wrote: > > > This very much looks like power saving misbehaving. > > It does. But it doesn't seem like my distro enables autosuspend there by > default. > > > Are you using autosuspend on this device? >

Re: xHCI problem? [was Re: Erratic USB device behavior and device loss]

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Sun, 2016-09-04 at 15:46 -0400, Alan Stern wrote: > > This is not the problem I was discussing with Ulf.  The problem was why > the device kept going into and out of runtime suspend every three > seconds.  The kernel log above does not say

[Bug] System reboots instead of shutting down if xhci is enabled in BIOS and USB hub is connected

System reboots instead of shutting down if xhci is enabled in BIOS and USB hub is connected When I connect the usb hub built into my monitor (http://www.samsung.com/uk/support/model/LS27D85KTSN/XU), the system will reboot instead of shutting down when I do a shut down. If I disable XCHI in the

Re: Memory barrier needed with wake_up_process()?

On Mon, 5 Sep 2016, Peter Zijlstra wrote: > > You know, I never went through and verified that _all_ the invocations > > of sleep_thread() are like that. > > Well, thing is, they're all inside a loop which checks other conditions > for forward progress. Therefore the loop inside sleep_thread()

Re: g_mass_storage not queueing requests

On Mon, 5 Sep 2016, Felipe Balbi wrote: > >> [ 34.123281] ==> bulk_out_complete 484 > > > > received CBW. Now, bh->state is set to BUF_STATE_FULL, and ... > > > >> [ 34.123283] ==> wakeup_thread 403: caller > >> usb_gadget_giveback_request+0x7/0x10: thread_wakeup_needed = 1 > > > >

Re: Memory barrier needed with wake_up_process()?

On Mon, 5 Sep 2016, Peter Zijlstra wrote: > > Actually, seeing it written out like this, one realizes that it really > > ought to be: > > > > CPU 0 CPU 1 > > - - > > Start DMA Handle

Re: xHCI problem? [was Re: Erratic USB device behavior and device loss]

On Mon, 5 Sep 2016, Ritesh Raj Sarraf wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > On Sun, 2016-09-04 at 15:46 -0400, Alan Stern wrote: > > > > This is not the problem I was discussing with Ulf.  The problem was why > > the device kept going into and out of runtime suspend

[PATCH] usb: chipidea: udc: fix NULL ptr dereference in isr_setup_status_phase

Problems with the signal integrity of the high speed USB data lines or noise on reference ground lines can cause the i.MX6 USB controller to violate USB specs and exhibit unexpected behavior. It was observed that USBi_UI interrupts were triggered first and when isr_setup_status_phase was called,

Re: chipidea: udc: kernel panic in isr_setup_status_phase

On Mon, Sep 05, 2016 at 11:10:22AM +0800, Peter Chen wrote: > How about below, it will set halt for device, and host will get stall > from the device. > > diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c > index 0f692fc..3c46ccb 100644 > --- a/drivers/usb/chipidea/udc.c > +++

Re: g_mass_storage not queueing requests

Hi, Alan Stern writes: > On Mon, 5 Sep 2016, Felipe Balbi wrote: > >> okay, I'm thinking that's a plausible explanation, please correct me if >> I'm wrong. What I'm speculating now is that inside a locked region, >> reordering can happen (can it?) > > Yes, it can.

[PATCH] usb: gadget: prevent potenial null pointer dereference on skb->len

From: Colin Ian King An earlier fix partially fixed the null pointer dereference on skb->len by moving the assignment of len after the check on skb being non-null, however it failed to remove the erroneous dereference when assigning len. Correctly fix this by removing

Re: g_mass_storage not queueing requests

On Mon, 5 Sep 2016, Felipe Balbi wrote: > Hi, > > Alan Stern writes: > > On Mon, 5 Sep 2016, Felipe Balbi wrote: > > > >> okay, I'm thinking that's a plausible explanation, please correct me if > >> I'm wrong. What I'm speculating now is that inside a locked region, >

Re: g_mass_storage not queueing requests

On Mon, 5 Sep 2016, Felipe Balbi wrote: > okay, I'm thinking that's a plausible explanation, please correct me if > I'm wrong. What I'm speculating now is that inside a locked region, > reordering can happen (can it?) Yes, it can. > which means that our: > > spin_lock(>lock); >

Re: [PATCH] usb: dwc3: host: inherit dma configuration from parent dev

On Friday, September 2, 2016 5:16:31 PM CEST Leo Li wrote: > > Can we use the firmware or bootloader information to provide the > default dma-mapping attributes for devices that doesn't have an > of_node pointer or ACPI data? This will at least restore what we had > previously provided . I'm

Great Offer

You are a recipient to Mrs Julie Leach Donation of $2 million USD. Contact (julieleach...@hotmail.com) for claims. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at

Great Offer

You are a recipient to Mrs Julie Leach Donation of $2 million USD. Contact (julieleach...@hotmail.com) for claims. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at

Great Offer

You are a recipient to Mrs Julie Leach Donation of $2 million USD. Contact (julieleach...@hotmail.com) for claims. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at

[PATCH v6 2/3] usb: musb: da8xx: Use devm in probe

Simplify things a bit by using devm functions where possible. Signed-off-by: David Lechner --- drivers/usb/musb/da8xx.c | 19 +-- 1 file changed, 5 insertions(+), 14 deletions(-) diff --git a/drivers/usb/musb/da8xx.c b/drivers/usb/musb/da8xx.c index

[PATCH v6 3/3] usb: musb: da8xx: Remove mach code

Use the new phy-da8xx-usb driver to take the place of the mach code that pokes CFGCHIP2 in the da8xx musb glue driver. This unbreaks the driver. Signed-off-by: David Lechner --- drivers/usb/musb/Kconfig | 2 +- drivers/usb/musb/da8xx.c | 135

[PATCH v6 0/3] da8xx USB PHY platform devices and clocks

Just resending to get these merged into usb. The phy parts of this patch series have already been merged into Linus' tree. I have rebased on 4.8-rc5 but there have not been any changes to these since the last time I submitted. David Lechner (3): usb: ohci-da8xx: Remove code that references

[PATCH v6 1/3] usb: ohci-da8xx: Remove code that references mach

Including mach/* is frowned upon in device drivers, so get rid of it. This replaces usb20_clk and code that pokes CFGCHIP2 with a proper phy driver. Signed-off-by: David Lechner Acked-by: Alan Stern --- drivers/usb/host/Kconfig | 1 +

Re: [PATCH v7 3/4] usb: dwc2: assert phy reset when waking up in rk3288 platform

從我的 iPad 傳送 > David Laight 於 2016年9月5日 下午9:35 寫道： > > From: Randy Li >> Sent: 03 September 2016 22:55 > ... >> +if (of_device_is_compatible(np, "rockchip,rk3288-usb") >> +&& (NULL != hsotg->phy->ops->reset)) >> +

Re: [PATCH] usb: chipidea: udc: fix NULL ptr dereference in isr_setup_status_phase

On Mon, Sep 05, 2016 at 07:29:58PM +0200, Clemens Gruber wrote: > Problems with the signal integrity of the high speed USB data lines or > noise on reference ground lines can cause the i.MX6 USB controller to > violate USB specs and exhibit unexpected behavior. > > It was observed that USBi_UI

RE: [PATCH] usb: gadget: prevent potenial null pointer dereference on skb->len

> >From: Colin Ian King > >An earlier fix partially fixed the null pointer dereference on skb->len by >moving the >assignment of len after the check on skb being non-null, however it failed to >remove >the erroneous dereference when assigning len. >Correctly fix this

RE: [PATCH v7 3/4] usb: dwc2: assert phy reset when waking up in rk3288 platform

From: Randy Li > Sent: 03 September 2016 22:55 ... > + if (of_device_is_compatible(np, "rockchip,rk3288-usb") > + && (NULL != hsotg->phy->ops->reset)) > + hsotg->phy->ops->reset(hsotg->phy); > + Is this the only

Re: Memory barrier needed with wake_up_process()?

On Sat, Sep 03, 2016 at 10:16:31AM -0400, Alan Stern wrote: > > Sorry, but that is horrible code. A barrier cannot ensure writes are > > 'complete', at best they can ensure order between writes (or reads > > etc..). > > The code is better than the comment. What I really meant was that the >

Re: Memory barrier needed with wake_up_process()?

On Sat, Sep 03, 2016 at 04:51:07PM +0300, Felipe Balbi wrote: > > That said, I cannot spot an obvious fail, > > okay, but a fail does exist. Any hints on what extra information I could > capture to help figuring this one out? More information on which sleep is not waking woudl help I suppose.

Re: g_mass_storage not queueing requests

Hi, Alan Stern writes: > On Sat, 3 Sep 2016, Felipe Balbi wrote: > >> Hi, >> >> Alan Stern writes: >> > On Fri, 2 Sep 2016, Felipe Balbi wrote: >> > >> >> >> >> Hi, >> >> >> >> Alan Stern writes: >> >> >> >>

Re: Memory barrier needed with wake_up_process()?

On Sat, Sep 03, 2016 at 10:49:39AM -0400, Alan Stern wrote: > On Sat, 3 Sep 2016, Alan Stern wrote: > > > In other words, we have: > > > > CPU 0 CPU 1 > > - - > > Start DMA Handle DMA-complete irq > >

Re: [PATCH v7 3/4] usb: dwc2: assert phy reset when waking up in rk3288 platform

Hi, On Sunday 04 September 2016 03:25 AM, Randy Li wrote: > On the rk3288 USB host-only port (the one that's not the OTG-enabled > port) the PHY can get into a bad state when a wakeup is asserted (not > just a wakeup from full system suspend but also a wakeup from > autosuspend). > > We can get

Re: [PATCH v16 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

On Mon, Aug 29 2016, Baolin Wang wrote: > Hi Felipe, > > On 11 August 2016 at 11:14, Baolin Wang wrote: >> Hi Felipe, >> >> On 1 August 2016 at 15:09, Baolin Wang wrote: >>> Currently the Linux kernel does not provide any standard integration of

Re: [PATCH v2] usb: gadget: Add per-lun inquiry string

-<| Quoting Philipp Gesang , on Monday, 2016-08-01 17:04:19 |>- > Introduce an attribute "inquiry_string" to the lun. > > In some environments, e. g. BIOS boot menus, the inquiry string > is the only information about devices presented to the user. The > default