Re: [PATCH] usb: Make use of ktime_* comparison functions
On Fri, May 26, 2017 at 12:15:59PM +0200, Mariusz Skamra wrote: > Start using ktime_* compare functions to make the code backportable. > Now that may be a bit tricky due to recent change of ktime_t. > > Signed-off-by: Mariusz Skamra > Acked-by: Kuppuswamy Sathyanarayanan > --- > drivers/usb/chipidea/otg_fsm.c | 8 > drivers/usb/host/ehci-timer.c | 2 +- > drivers/usb/host/fotg210-hcd.c | 2 +- > 3 files changed, 6 insertions(+), 6 deletions(-) > > diff --git a/drivers/usb/chipidea/otg_fsm.c b/drivers/usb/chipidea/otg_fsm.c > index 93e24ce..949183e 100644 > --- a/drivers/usb/chipidea/otg_fsm.c > +++ b/drivers/usb/chipidea/otg_fsm.c > @@ -234,7 +234,7 @@ static void ci_otg_add_timer(struct ci_hdrc *ci, enum > otg_fsm_timer t) > ktime_set(timer_sec, timer_nsec)); > ci->enabled_otg_timer_bits |= (1 << t); > if ((ci->next_otg_timer == NUM_OTG_FSM_TIMERS) || > - (ci->hr_timeouts[ci->next_otg_timer] > > + ktime_after(ci->hr_timeouts[ci->next_otg_timer], > ci->hr_timeouts[t])) { > ci->next_otg_timer = t; > hrtimer_start_range_ns(&ci->otg_fsm_hrtimer, > @@ -269,7 +269,7 @@ static void ci_otg_del_timer(struct ci_hdrc *ci, enum > otg_fsm_timer t) > for_each_set_bit(cur_timer, &enabled_timer_bits, > NUM_OTG_FSM_TIMERS) { > if ((next_timer == NUM_OTG_FSM_TIMERS) || > - (ci->hr_timeouts[next_timer] < > + > ktime_before(ci->hr_timeouts[next_timer], >ci->hr_timeouts[cur_timer])) > next_timer = cur_timer; > } > @@ -397,13 +397,13 @@ static enum hrtimer_restart ci_otg_hrtimer_func(struct > hrtimer *t) > > now = ktime_get(); > for_each_set_bit(cur_timer, &enabled_timer_bits, NUM_OTG_FSM_TIMERS) { > - if (now >= ci->hr_timeouts[cur_timer]) { > + if (ktime_compare(now, ci->hr_timeouts[cur_timer]) >= 0) { > ci->enabled_otg_timer_bits &= ~(1 << cur_timer); > if (otg_timer_handlers[cur_timer]) > ret = otg_timer_handlers[cur_timer](ci); > } else { > if ((next_timer == NUM_OTG_FSM_TIMERS) || > - (ci->hr_timeouts[cur_timer] < > + ktime_before(ci->hr_timeouts[cur_timer], > ci->hr_timeouts[next_timer])) > next_timer = cur_timer; > } For chipidea part: Acked-by: Peter Chen -- Best Regards, Peter Chen -- 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 http://vger.kernel.org/majordomo-info.html
Re: Gadget driver & virtual hub
Hi, Benjamin Herrenschmidt writes: >> Benjamin Herrenschmidt writes: >> > So another question :-) >> > >> > Is it legal to break down a bulk (or ISO) IN request into packets that >> > are *smaller* than the Max EP size ? >> >> it depends if they are *supposed* to be two smaller packets or should be >> two parts of a single one. >> >> > For example, I have a max EP size of 512 bytes and the gadget gives me >> > an SG list where that's broken up into two segments (for example 2x256 >> > bytes). >> > >> > Now, I'm still trying to confirm with the vendor what happens here, but >> > I *suspect* that if I create 2 descriptors, the HW will break it down >> > into 2 packets smaller than the max EP size on the wire. >> >> If that's the case, then your HW can't handle SG lists. I suspect there >> will be some "chain" bit somewhere in the DMA descriptor which you can >> use to tell DMA that these two segments are part of a single transfer. > > No, there isn't, sadly. I've confirmed with the HW vendor. I might > still enable SG with a fallback to bounce buffering to a pre-allocated > packet buffer if I hit such a situation... It shouldn't be common for > mass storage (though do we use sglists for the mass storage gadget ?), UASP does use it ;-) > it might be more with networking if our network function does > fragmented sends, I haven't checked. Well, even networking gadget is using a linear buffer. Nobody implemented support for sg lists yet. >> > I do have vague memories of seeing "client" drivers in the past with >> > make assumptions that some "replies" are fully contained in a single >> > packet, so I'm tempted to say that this won't work, and thus should >> > bounce such packets through a linear buffer but I'd like confirmation. >> >> yeah, USB makes that assumption. If host side requests 512 bytes and you >> end up breaking that into two packets, host will receive only the first >> 256 bytes, as short packets terminate transfers. > > Yup, that was indeed my assumption. Thanks for confirming. np -- balbi signature.asc Description: PGP signature
Re: XHCI is slow during boot (bios/efi) and leaves many dmesg messages
On Tue, 2017-05-16 at 13:25 +0300, Mathias Nyman wrote: > On 16.05.2017 13:00, Maël Lavault wrote: > > On Wed, 2017-05-10 at 16:04 +0300, Mathias Nyman wrote: > > > On 09.05.2017 16:50, Maël Lavault wrote: > > > > On Tue, 2017-05-09 at 11:34 +0300, Felipe Balbi wrote: > > > > > Hi, > > > > > > > > > > Maël Lavault writes: > > > > > > Le 28 avr. 2017 15:57, "Maël Lavault" > > > > > alav > > > > > > enue > > > > > > .com > > > > > > > a écrit : > > > > > > > > > > > > On Fri, 2017-04-28 at 16:58 +0300, Mathias Nyman wrote: > > > > > > > On 21.04.2017 11:08, Maël Lavault wrote: > > > > > > > > On Tue, 2017-04-18 at 16:58 +0200, Maël Lavault wrote: > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > I can't find how to reply to an old thread with > > > > > > > > > majordomo, > > > > > > > > > sorry > > > > > > > > > for > > > > > > > > > the inconvenience it might cause. > > > > > > > > > > > > > > > > > > I'm reposting an issue [0] that has been inactive for > > > > > > > > > a > > > > > > > > > few > > > > > > > > > month > > > > > > > > > but > > > > > > > > > still present in kernel 4.10.10 on a Macbook pro > > > > > > > > > 12,1. > > > > > > > > > > > > > > > > > > I can provide more informations if needed but the > > > > > > > > > issue > > > > > > > > > is > > > > > > > > > explained > > > > > > > > > in > > > > > > > > > details in the bugzilla issue. > > > > > > > > > > > > > > > > > > Thanks. > > > > > > > > > > > > > > > > > > --- > > > > > > > > > Hi list, > > > > > > > > > > > > > > > > > > I have a Apple Inc. MacBookPro11,1 (with the most > > > > > > > > > recent > > > > > > > > > 'bios': > > > > > > > > > BIOS > > > > > > > > > MBP111.88Z.0138.B16.1509081438 09/08/2015). > > > > > > > > > > > > > > > > > > At the beginning, USB worked normally. After a while > > > > > > > > > (and > > > > > > > > > after > > > > > > > > > newer > > > > > > > > > kernel versions released by debian?) things started > > > > > > > > > to > > > > > > > > > act > > > > > > > > > strangely. > > > > > > > > > For > > > > > > > > > one, the bios/efi boot takes a very long time > > > > > > > > > (probably > > > > > > > > > due > > > > > > > > > to > > > > > > > > > the > > > > > > > > > same > > > > > > > > > reason I describe later) just to get to the > > > > > > > > > bootloader/grub. > > > > > > > > > Likley > > > > > > > > > resetting and probing for USB ports/mass storage. > > > > > > > > > When > > > > > > > > > grub > > > > > > > > > finally > > > > > > > > > pops > > > > > > > > > up, I can use the (internal USB based keyboard) > > > > > > > > > normally > > > > > > > > > to > > > > > > > > > select a > > > > > > > > > grub > > > > > > > > > entry etc. > > > > > > > > > > > > > > > > > > Booting the kernel then works reasonably fine, until > > > > > > > > > it > > > > > > > > > loads > > > > > > > > > the > > > > > > > > > xhci > > > > > > > > > module. > > > > > > > > > It spews some messages in dmesg (taking some 15 > > > > > > > > > seconds) > > > > > > > > > and > > > > > > > > > only > > > > > > > > > then, > > > > > > > > > the > > > > > > > > > keyboard starts to work again. > > > > > > > > > > > > > > > > > > The log is filled with messages like: > > > > > > > > > [7.248479] xhci_hcd :00:14.0: Command > > > > > > > > > completion > > > > > > > > > event > > > > > > > > > does > > > > > > > > > not > > > > > > > > > match command > > > > > > > > > [7.248495] xhci_hcd :00:14.0: Timeout while > > > > > > > > > waiting > > > > > > > > > for > > > > > > > > > setup > > > > > > > > > device command > > > > > > > > > [ 12.256347] xhci_hcd :00:14.0: Timeout while > > > > > > > > > waiting > > > > > > > > > for > > > > > > > > > setup > > > > > > > > > device command > > > > > > > > > [ 12.256363] usb 1-2: hub failed to enable device, > > > > > > > > > error > > > > > > > > > -62 > > > > > > > > > [ 17.264166] xhci_hcd :00:14.0: Timeout while > > > > > > > > > waiting > > > > > > > > > for > > > > > > > > > setup > > > > > > > > > device command > > > > > > > > > (followed by USB hub/device enumeration) > > > > > > > > > > > > > > > > > > I've tried several combinations and quirks, updating > > > > > > > > > to > > > > > > > > > the > > > > > > > > > latest rc > > > > > > > > > kernels since 3.16 (am on 4.5.0 right now) and it > > > > > > > > > only > > > > > > > > > seems > > > > > > > > > to > > > > > > > > > get > > > > > > > > > worse. > > > > > > > > > > > > > > > > > > Last year, on the 3.x series of kernels occasionally > > > > > > > > > after a > > > > > > > > > reboot > > > > > > > > > the > > > > > > > > > 'bios' would go through quickly and fine and also no > > > > > > > > > problems > > > > > > > > > loading > > > > > > > > > the > > > > > > > > > module and logging in. But now it always fails. > > > > > > > > > > > > > > > > > > Additionally it (may or may not) seems to cause the > > > > > > > > > internal > > > > > > > > > usb > > > > > >
RE: [PATCH] xhci: remove endpoint ring cache
Hi Mathias, I have tested this patch with my platform and it works fine Thanks, Anurag Kumar Vulisha >-Original Message- >From: Mathias Nyman [mailto:mathias.ny...@linux.intel.com] >Sent: Friday, June 02, 2017 4:51 PM >To: Anurag Kumar Vulisha >Cc: gre...@linuxfoundation.org; Anirudha Sarangi ; >Anurag Kumar Vulisha ; linux-usb@vger.kernel.org; >Mathias Nyman >Subject: [PATCH] xhci: remove endpoint ring cache > >Having a properly working ring cache could ease a bit the memory >reallocation, but this current implemetation isn't the correct way. >It's faulty and hogs a lot of memory. > >A pool of cached rings that any device could use would be more useful, >but xhci driver isn't there yet, just keeping the basic functionality >working is already a handful. > >How about your case, does removing the cache work instead with your setup? > >8<--- > >Anurag Kumar Vulisha reported several issues with xhci endpoint >ring caching. > >31 Rings are cached per device before a ring is freed. >These cached rings are not used as default if a new ring is needed. >They are only used if the drive fails to allocate memory for a ring. > >The current ring cache is more a reason to why we run out memry than a >help when we actually do so. > >Anurag Kumar Vulisha tried to use cached rings as a first option and >found new issues with cached ring initialization. >Cached rings were first zeroed and then manually reinitialized with link >rbs etc, but forgetting to set some important bits like cycle toggle bit. > >Remove the ring cache completely as it's a faulty premature optimization >eating memory > >Reported-by: Anurag Kumar Vulisha >Signed-off-by: Mathias Nyman >--- > drivers/usb/host/xhci-mem.c | 81 - > drivers/usb/host/xhci.c | 17 +- > drivers/usb/host/xhci.h | 6 +--- > 3 files changed, 15 insertions(+), 89 deletions(-) > >diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c >index 1f1687e..7c2501a 100644 >--- a/drivers/usb/host/xhci-mem.c >+++ b/drivers/usb/host/xhci-mem.c >@@ -407,64 +407,17 @@ static struct xhci_ring *xhci_ring_alloc(struct xhci_hcd >*xhci, > return NULL; > } > >-void xhci_free_or_cache_endpoint_ring(struct xhci_hcd *xhci, >+void xhci_free_endpoint_ring(struct xhci_hcd *xhci, > struct xhci_virt_device *virt_dev, > unsigned int ep_index) > { >- int rings_cached; >- >- rings_cached = virt_dev->num_rings_cached; >- if (rings_cached < XHCI_MAX_RINGS_CACHED) { >- virt_dev->ring_cache[rings_cached] = >- virt_dev->eps[ep_index].ring; >- virt_dev->num_rings_cached++; >- xhci_dbg(xhci, "Cached old ring, " >- "%d ring%s cached\n", >- virt_dev->num_rings_cached, >- (virt_dev->num_rings_cached > 1) ? "s" : ""); >- } else { >- xhci_ring_free(xhci, virt_dev->eps[ep_index].ring); >- xhci_dbg(xhci, "Ring cache full (%d rings), " >- "freeing ring\n", >- virt_dev->num_rings_cached); >- } >+ xhci_ring_free(xhci, virt_dev->eps[ep_index].ring); > virt_dev->eps[ep_index].ring = NULL; > } > >-/* Zero an endpoint ring (except for link TRBs) and move the enqueue and >dequeue >- * pointers to the beginning of the ring. >- */ >-static void xhci_reinit_cached_ring(struct xhci_hcd *xhci, >- struct xhci_ring *ring, unsigned int cycle_state, >- enum xhci_ring_type type) >-{ >- struct xhci_segment *seg = ring->first_seg; >- int i; >- >- do { >- memset(seg->trbs, 0, >- sizeof(union xhci_trb)*TRBS_PER_SEGMENT); >- if (cycle_state == 0) { >- for (i = 0; i < TRBS_PER_SEGMENT; i++) >- seg->trbs[i].link.control |= >- cpu_to_le32(TRB_CYCLE); >- } >- /* All endpoint rings have link TRBs */ >- xhci_link_segments(xhci, seg, seg->next, type); >- seg = seg->next; >- } while (seg != ring->first_seg); >- ring->type = type; >- xhci_initialize_ring_info(ring, cycle_state); >- /* td list should be empty since all URBs have been cancelled, >- * but just in case... >- */ >- INIT_LIST_HEAD(&ring->td_list); >-} >- > /* > * Expand an existing ring. >- * Look for a cached ring or allocate a new ring which has same segment >numbers >- * and link the two rings. >+ * Allocate a new ring which has same segment numbers and link the two rings. > */ > int xhci_ring_expansion(struct xhci_hcd *xhci, struct xhci_ring *ring, > unsigned int num_trbs, gfp_t flags) >@@ -968,12 +921,6 @@ void xhci_free_virt_device(struct xhci_hcd *xhci, int >slot_id) > /* If nece
Re: [RFC] usb-phy-generic: Add support to SMSC USB3315
On Fri, 2017-06-02 at 15:00 -0700, Stephen Boyd wrote: > On 05/26, Fabien Lahoudere wrote: > > Hello > > > > I modify ci_hrdc_imx_probe to bypass "data->phy = > > devm_usb_get_phy_by_phandle(&pdev->dev, > > "fsl,usbphy", 0);". Everything works as expected and call ci_ulpi_init. > > > > The problem is that in ci_ulpi_init, before calling "ci->ulpi = > > ulpi_register_interface(ci->dev, > > &ci->ulpi_ops);" (to initialize our phy), "hw_phymode_configure(ci);" is > > called which is the > > original function that make our system to hang. > > > > Our phy is not initialised before calling ulpi_register_interface so I > > don't understand how the > > phy > > can reply if it is not out of reset state. > > I haven't see any problem in hw_phymode_configure(). What's the > value of ci->platdata->phy_mode? USBPHY_INTERFACE_MODE_ULPI? If > you phy needs to be taken out of reset to reply to the ulpi reads > of the vendor/product ids, then it sounds like you have a similar > situation to what I had. I needed to turn on some regulators to > get those reads to work, otherwise they would fail, but knowing > what needed to be turned on basically meant I needed to probe the > ulpi driver so probing the ids wasn't going to be useful. So on > my device the reads for the ids go through, but they get all > zeroes back, which is actually ok because there aren't any bits > set on my devices anyway. After the reads see 0, we fallback to > DT matching, which avoids the "bring it out of reset/power it on" > sorts of problems entirely. > Yes the phy mode is configured to USBPHY_INTERFACE_MODE_ULPI. Indeed, this phy need to be out of reset to work. For example everything works fine if I call "_ci_usb_phy_init(ci);" before calling "hw_phymode_configure(ci);" This function only init reset GPIO and clock. For information, the original patch I have to fix the issue: diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c index 79ad8e9..21aaff1 100644 --- a/drivers/usb/chipidea/core.c +++ b/drivers/usb/chipidea/core.c @@ -391,6 +391,7 @@ static int ci_usb_phy_init(struct ci_hdrc *ci) case USBPHY_INTERFACE_MODE_UTMI: case USBPHY_INTERFACE_MODE_UTMIW: case USBPHY_INTERFACE_MODE_HSIC: + case USBPHY_INTERFACE_MODE_ULPI: ret = _ci_usb_phy_init(ci); if (!ret) hw_wait_phy_stable(); @@ -398,7 +399,6 @@ static int ci_usb_phy_init(struct ci_hdrc *ci) return ret; hw_phymode_configure(ci); break; - case USBPHY_INTERFACE_MODE_ULPI: case USBPHY_INTERFACE_MODE_SERIAL: hw_phymode_configure(ci); ret = _ci_usb_phy_init(ci); -- So if some ULPI phys need to be initialised before calling "hw_phymode_configure", is it acceptable if I separate "case USBPHY_INTERFACE_MODE_ULPI:" and add a DT binding ("init_phy_first") to define the order to call both functions? Something like: case USBPHY_INTERFACE_MODE_ULPI: if (ci->platdata->init_phy_first) { ret = _ci_usb_phy_init(ci); if (!ret) hw_wait_phy_stable(); else return ret; } hw_phymode_configure(ci); if (!ci->platdata->init_phy_first) { ret = _ci_usb_phy_init(ci); if (ret) return ret; } break; This approach will not modify current behaviour but allow to initialize phy first on demand. -- 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 http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 0/3] USB Audio Gadget refactoring
Hi, Ruslan Bilovol writes: >> Ruslan Bilovol writes: >>> I came to this patch series when wanted to do two things: >>> - use UAC1 as virtual ALSA sound card on gadget side, >>>just like UAC2 is used so it's possible to do rate >>>resampling >>> - have both playback/capture support in UAC1 >>> >>> Since I wanted to have same behavior for both UAC1/UAC2, >>> obviously I've got an utility part (u_audio.c) for >>> virtual ALSA sound card handling like we have >>> for ethernet(u_ether) or serial(u_serial) functions. >>> Function-specific parts (f_uac1/f_uac2) became almost >>> as storage for class-specific USB descriptors, some >>> boilerplate for configfs, binding and few USB >>> config request handling. >>> >>> Originally in RFC [1] I've posted before, there was >>> major change to f_uac1 after that it couldn't do >>> direct play to existing ALSA sound card anymore, >>> representing audio on gadget side as virtual >>> ALSA sound card where audio streams are simply >>> sinked to and sourced from it, so it may break >>> current usecase for some people (and that's why >>> it was RFC). >>> >>> During RFC discussion, it was agreed to not touch >>> existing f_uac1 implementation and create new one >>> instead. This patchset (v4) introduced new function >>> named f_uac1_acard and doesn't touch current f_uac1 >>> implementation, so people still can use old behavior >> >> Do you have a pointer to the original RFC discussion where this was >> discussed? If we really *must* keep the old implementation, I would >> rather rename that to f_uac1_legacy. Still, I find it unlikely that >> anybody will care about the old implementation. > > It is on LKML (which is down for me) [1] or alternative archive [2] > >> >>> Now, it's possible to use existing user-space >>> applications for audio routing between Audio Gadget >>> and real sound card. I personally use alsaloop tool >>> from alsautils and have ability to create PCM >>> loopback between two different ALSA cards using >>> rate resampling, which was not possible with previous >>> "direct play to ALSA card" approach in f_uac1. >> >> this is really good result and will actually make it a lot easier for >> testing things out. >> >>> While here, also dropped redundant platform >>> driver/device creation in f_uac2 driver (as well as >>> didn't add "never implemented" volume/mute functionality >>> in f_uac1 to f_uac1_acard) that made this work even >>> easier to do. >>> >>> This series is tested with both legacy g_audio.ko and >>> modern configfs approaches under Ubuntu 14.04 (UAC1 and >>> UAC2) and under Windows7 x64 (UAC1 only) having >>> perfect results in all cases. >>> >>> Comments, testing are welcome. >>> >>> v4 changes: >>> - renamed f_uac1_newapi to f_uac1_acard that is >>>more meaningful >> >> I really don't get why you wanna keep both f_uac1 and f_uac1_acard. Why >> do we need to maintain the old uac1 implementation? Why two separate >> files? > > In first RFC ([1],[2]) I did exactly what you wrote here (removed > old uac1 implementation and replaced it by new one) but got feedback > that it will break things for existing f_uac1 legacy users and it's better to > have separate implementation. > > I'm OK with dropping legacy f_uac1 implementation. > > Another idea I was thinking about is to implement simple in-kernel > driver which will do the same as existing alsaloop tool userspace > tool does (so legacy users will need to load two kernel modules > and get same functionality). But this seems to be a wrong way, > since It known that Linux kernel community doesn't like to take drivers > with same functionality as existing userspace tools already have. > > So bottom line: since I'm not a legacy f_uac1 user, there is no > difference for me how to handle it - remove legacy f_uac1 completely, > rename it to f_uac1_legacy or add separate f_uac1_acard function. > > So if dropping of legacy f_uac1 implementation is OK for you, > I can do it quickly in next patchset. Personally, I don't want duplicated functionality and I think the virtual sound card approach is much better. Then again, removing functionality we already support is kind of odd. Greg, Alan, what do you guys think? Do we keep a duplicated function around or do we just tell people to rely on alsaloop? Personally, I think we're better off with the flexibility of the virtual sound card, what's your take? -- balbi signature.asc Description: PGP signature
Re: [PATCH v3] xhci: AMD Promontory USB disable port support
On 31.05.2017 10:41, Jiahau Chang wrote: v3: Fix some checkpatch.pl warnings For AMD Promontory xHCI host, although you can disable USB 2.0 ports in BIOS settings, those ports will be enabled anyway after you remove a device on that port and re-plug it in again. It's a known limitation of the chip. As a workaround we can clear the PORT_WAKE_BITS. Signed-off-by: Jiahau Chang --- drivers/usb/host/xhci-hub.c | 19 ++- drivers/usb/host/xhci-pci.c | 13 + drivers/usb/host/xhci.h | 2 ++ 3 files changed, 29 insertions(+), 5 deletions(-) diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c index 0dde49c..aad32c6 100644 --- a/drivers/usb/host/xhci-hub.c +++ b/drivers/usb/host/xhci-hub.c @@ -1218,12 +1218,19 @@ int xhci_hub_control(struct usb_hcd *hcd, u16 typeReq, u16 wValue, xhci_dbg(xhci, "set port reset, actual port %d status = 0x%x\n", wIndex, temp); break; case USB_PORT_FEAT_REMOTE_WAKE_MASK: - xhci_set_remote_wake_mask(xhci, port_array, + if ((xhci->quirks & XHCI_U2_DISABLE_WAKE) && (hcd->speed < HCD_USB3)) { + temp = readl(port_array[wIndex]); + xhci_dbg(xhci, "skip set port remote wake mask, " + "actual port %d status = 0x%x\n", + wIndex, temp); Does this work? If I remember correctly USB_PORT_FEAT_REMOTE_WAKE_MASK is a USB3 only feature. The (hcd->speed < HCD_USB3) condition should never be true here. -Mathias -- 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 http://vger.kernel.org/majordomo-info.html
Re: [RFC] usb-phy-generic: Add support to SMSC USB3315
On Mon, Jun 05, 2017 at 10:57:00AM +0200, Fabien Lahoudere wrote: > On Fri, 2017-06-02 at 15:00 -0700, Stephen Boyd wrote: > > On 05/26, Fabien Lahoudere wrote: > > > Hello > > > > > > I modify ci_hrdc_imx_probe to bypass "data->phy = > > > devm_usb_get_phy_by_phandle(&pdev->dev, > > > "fsl,usbphy", 0);". Everything works as expected and call ci_ulpi_init. > > > > > > The problem is that in ci_ulpi_init, before calling "ci->ulpi = > > > ulpi_register_interface(ci->dev, > > > &ci->ulpi_ops);" (to initialize our phy), "hw_phymode_configure(ci);" is > > > called which is the > > > original function that make our system to hang. > > > > > > Our phy is not initialised before calling ulpi_register_interface so I > > > don't understand how the > > > phy > > > can reply if it is not out of reset state. > > > > I haven't see any problem in hw_phymode_configure(). What's the > > value of ci->platdata->phy_mode? USBPHY_INTERFACE_MODE_ULPI? If > > you phy needs to be taken out of reset to reply to the ulpi reads > > of the vendor/product ids, then it sounds like you have a similar > > situation to what I had. I needed to turn on some regulators to > > get those reads to work, otherwise they would fail, but knowing > > what needed to be turned on basically meant I needed to probe the > > ulpi driver so probing the ids wasn't going to be useful. So on > > my device the reads for the ids go through, but they get all > > zeroes back, which is actually ok because there aren't any bits > > set on my devices anyway. After the reads see 0, we fallback to > > DT matching, which avoids the "bring it out of reset/power it on" > > sorts of problems entirely. > > > > Yes the phy mode is configured to USBPHY_INTERFACE_MODE_ULPI. > Indeed, this phy need to be out of reset to work. For example everything > works fine if I call > "_ci_usb_phy_init(ci);" before calling "hw_phymode_configure(ci);" > This function only init reset GPIO and clock. > > For information, the original patch I have to fix the issue: > > diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c > index 79ad8e9..21aaff1 100644 > --- a/drivers/usb/chipidea/core.c > +++ b/drivers/usb/chipidea/core.c > @@ -391,6 +391,7 @@ static int ci_usb_phy_init(struct ci_hdrc *ci) > case USBPHY_INTERFACE_MODE_UTMI: > case USBPHY_INTERFACE_MODE_UTMIW: > case USBPHY_INTERFACE_MODE_HSIC: > + case USBPHY_INTERFACE_MODE_ULPI: > ret = _ci_usb_phy_init(ci); > if (!ret) > hw_wait_phy_stable(); > @@ -398,7 +399,6 @@ static int ci_usb_phy_init(struct ci_hdrc *ci) > return ret; > hw_phymode_configure(ci); > break; > - case USBPHY_INTERFACE_MODE_ULPI: > case USBPHY_INTERFACE_MODE_SERIAL: > hw_phymode_configure(ci); > ret = _ci_usb_phy_init(ci); > -- Currently, the hw_phymode_configure is called twice for ULPI PHY, the two execution are between _ci_usb_phy_init, would you test which one causes hang? If the second causes hang, you can make a patch for hw_phymode_configure that if the required PORTSC_PTS is the same the value in register, do noop. -- Best Regards, Peter Chen -- 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 http://vger.kernel.org/majordomo-info.html
Re: [RFC] usb-phy-generic: Add support to SMSC USB3315
On Mon, 2017-06-05 at 17:43 +0800, Peter Chen wrote: > On Mon, Jun 05, 2017 at 10:57:00AM +0200, Fabien Lahoudere wrote: > > On Fri, 2017-06-02 at 15:00 -0700, Stephen Boyd wrote: > > > On 05/26, Fabien Lahoudere wrote: > > > > Hello > > > > > > > > I modify ci_hrdc_imx_probe to bypass "data->phy = > > > > devm_usb_get_phy_by_phandle(&pdev->dev, > > > > "fsl,usbphy", 0);". Everything works as expected and call ci_ulpi_init. > > > > > > > > The problem is that in ci_ulpi_init, before calling "ci->ulpi = > > > > ulpi_register_interface(ci- > > > > >dev, > > > > &ci->ulpi_ops);" (to initialize our phy), "hw_phymode_configure(ci);" > > > > is called which is the > > > > original function that make our system to hang. > > > > > > > > Our phy is not initialised before calling ulpi_register_interface so I > > > > don't understand how > > > > the > > > > phy > > > > can reply if it is not out of reset state. > > > > > > I haven't see any problem in hw_phymode_configure(). What's the > > > value of ci->platdata->phy_mode? USBPHY_INTERFACE_MODE_ULPI? If > > > you phy needs to be taken out of reset to reply to the ulpi reads > > > of the vendor/product ids, then it sounds like you have a similar > > > situation to what I had. I needed to turn on some regulators to > > > get those reads to work, otherwise they would fail, but knowing > > > what needed to be turned on basically meant I needed to probe the > > > ulpi driver so probing the ids wasn't going to be useful. So on > > > my device the reads for the ids go through, but they get all > > > zeroes back, which is actually ok because there aren't any bits > > > set on my devices anyway. After the reads see 0, we fallback to > > > DT matching, which avoids the "bring it out of reset/power it on" > > > sorts of problems entirely. > > > > > > > Yes the phy mode is configured to USBPHY_INTERFACE_MODE_ULPI. > > Indeed, this phy need to be out of reset to work. For example everything > > works fine if I call > > "_ci_usb_phy_init(ci);" before calling "hw_phymode_configure(ci);" > > This function only init reset GPIO and clock. > > > > For information, the original patch I have to fix the issue: > > > > diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c > > index 79ad8e9..21aaff1 100644 > > --- a/drivers/usb/chipidea/core.c > > +++ b/drivers/usb/chipidea/core.c > > @@ -391,6 +391,7 @@ static int ci_usb_phy_init(struct ci_hdrc *ci) > > case USBPHY_INTERFACE_MODE_UTMI: > > case USBPHY_INTERFACE_MODE_UTMIW: > > case USBPHY_INTERFACE_MODE_HSIC: > > + case USBPHY_INTERFACE_MODE_ULPI: > > ret = _ci_usb_phy_init(ci); > > if (!ret) > > hw_wait_phy_stable(); > > @@ -398,7 +399,6 @@ static int ci_usb_phy_init(struct ci_hdrc *ci) > > return ret; > > hw_phymode_configure(ci); > > break; > > - case USBPHY_INTERFACE_MODE_ULPI: > > case USBPHY_INTERFACE_MODE_SERIAL: > > hw_phymode_configure(ci); > > ret = _ci_usb_phy_init(ci); > > -- > > Currently, the hw_phymode_configure is called twice for ULPI PHY, the > two execution are between _ci_usb_phy_init, would you test which one > causes hang? If the second causes hang, you can make a patch for > hw_phymode_configure that if the required PORTSC_PTS is the same > the value in register, do noop. The first one hangs, _ci_usb_phy_init is not called due to hang. -- 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 http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6] usb: typec: Add a sysfs node to manage port type
Hi, Sorry for the late reply. I was unable to follow my email last week. On Tue, May 30, 2017 at 12:39:53PM -0700, Badhri Jagan Sridharan wrote: > User space applications in some cases have the need to enforce a > specific port type(DFP/UFP/DRP). This change allows userspace to > attempt setting the desired port type. Low level drivers can > however reject the request if the specific port type is not supported. > > Signed-off-by: Badhri Jagan Sridharan > Reviewed-by: Guenter Roeck It looks good to me. In case Greg has not yet picked this: Acked-by: Heikki Krogerus Thanks, -- heikki -- 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 http://vger.kernel.org/majordomo-info.html
Re: [v2 1/1] usb:host:xhci support option to disable xHCI 1.0 USB2 HW LPM
On 20.05.2017 10:24, Thang Q. Nguyen wrote: XHCI specification 1.1 does not require xHCI 1.0 compliant controllers to always enable hardware USB2 LPM. However, the current xHCI driver always enable it by setting HLE=1 when seeing HLC=1. This makes certain xHCI controllers that have broken USB2 HW LPM fail to work as there is no way to disable this feature. This patch adds support to control disabling USB2 Hardware LPM via DT/ACPI attribute. Signed-off-by: Tung Nguyen Signed-off-by: Thang Q. Nguyen --- Changes since v1: - Update DT/ACPI attribute and corresponding codes from HLE to LPM to be consistent with other attribute names. --- Documentation/devicetree/bindings/usb/usb-xhci.txt |1 + drivers/usb/host/xhci-plat.c |3 +++ drivers/usb/host/xhci.c|7 ++- drivers/usb/host/xhci.h|1 + 4 files changed, 11 insertions(+), 1 deletions(-) diff --git a/Documentation/devicetree/bindings/usb/usb-xhci.txt b/Documentation/devicetree/bindings/usb/usb-xhci.txt index 2d80b60..96f1ac0 100644 --- a/Documentation/devicetree/bindings/usb/usb-xhci.txt +++ b/Documentation/devicetree/bindings/usb/usb-xhci.txt @@ -26,6 +26,7 @@ Required properties: Optional properties: - clocks: reference to a clock + - usb2-lpm-disable: disable USB2 LPM for hardware does not support it - usb3-lpm-capable: determines if platform is USB3 LPM capable - quirk-broken-port-ped: set if the controller has broken port disable mechanism diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c index 7c2a9e7..950eaf0 100644 --- a/drivers/usb/host/xhci-plat.c +++ b/drivers/usb/host/xhci-plat.c @@ -267,6 +267,9 @@ static int xhci_plat_probe(struct platform_device *pdev) goto disable_clk; } + if (device_property_read_bool(&pdev->dev, "usb2-lpm-disable")) + xhci->quirks |= XHCI_USB2_LPM_DISABLE; + if (device_property_read_bool(sysdev, "usb3-lpm-capable")) xhci->quirks |= XHCI_LPM_SUPPORT; diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c index 2d13102..47d51d4 100644 --- a/drivers/usb/host/xhci.c +++ b/drivers/usb/host/xhci.c @@ -4055,6 +4055,7 @@ static int xhci_set_usb2_hardware_lpm(struct usb_hcd *hcd, unsigned long flags; int hird, exit_latency; int ret; + int usb2_lpm_disable = 0; if (hcd->speed >= HCD_USB3 || !xhci->hw_lpm_support || !udev->lpm_capable) @@ -4079,7 +4080,11 @@ static int xhci_set_usb2_hardware_lpm(struct usb_hcd *hcd, xhci_dbg(xhci, "%s port %d USB2 hardware LPM\n", enable ? "enable" : "disable", port_num + 1); - if (enable) { + /* Check for optional disable USB2 LPM if XHCI 1.0 */ + if ((xhci->quirks & XHCI_USB2_LPM_DISABLE) && (xhci->hci_version == 0x100)) + usb2_lpm_disable = 1; + + if (enable && !usb2_lpm_disable) { Wouldn't it be better to just keep xhci->hw_lpm_support = 0 if the host doesn't support Hardware LPM Capability, (HLC)? This should prevent all those extra steps getting here just to do nothing. the quirk check could be done in xhci-mem.c in xhci_add_in_port() if (temp & XHCI_HLC &&) { xhci_dbg_trace(xhci, trace_xhci_dbg_init, "xHCI 1.0: support USB2 hardware lpm"); xhci->hw_lpm_support = 1; } Sidenote, the only purpose of the HLC bit is to inform the driver that the host port is HLC (Hardware LPM Capable). No wonder driver sets HW LPM if HLC is set. The HW LPM can also be disabled (per device) in sysfs if needed. -Mathias -- 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 http://vger.kernel.org/majordomo-info.html
Re: [PATCH] xhci: remove endpoint ring cache
On 05.06.2017 11:46, Anurag Kumar Vulisha wrote: Hi Mathias, I have tested this patch with my platform and it works fine Thanks, Anurag Kumar Vulisha Thanks, I'll add your tested-by tag to it as well, and add it to my tree -Mathias -- 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 http://vger.kernel.org/majordomo-info.html
Re: [v2 1/1] usb:host:xhci support option to disable xHCI 1.0 USB2 HW LPM
On Mon, Jun 5, 2017 at 6:14 PM, Mathias Nyman wrote: > On 20.05.2017 10:24, Thang Q. Nguyen wrote: >> >> XHCI specification 1.1 does not require xHCI 1.0 compliant controllers >> to always enable hardware USB2 LPM. >> However, the current xHCI driver always enable it by setting HLE=1 when >> seeing HLC=1. This makes certain xHCI controllers that have broken USB2 >> HW LPM fail to work as there is no way to disable this feature. >> This patch adds support to control disabling USB2 Hardware LPM via >> DT/ACPI attribute. >> >> Signed-off-by: Tung Nguyen >> Signed-off-by: Thang Q. Nguyen >> --- >> Changes since v1: >> - Update DT/ACPI attribute and corresponding codes from HLE to LPM to >>be consistent with other attribute names. >> --- >> Documentation/devicetree/bindings/usb/usb-xhci.txt |1 + >> drivers/usb/host/xhci-plat.c |3 +++ >> drivers/usb/host/xhci.c|7 ++- >> drivers/usb/host/xhci.h|1 + >> 4 files changed, 11 insertions(+), 1 deletions(-) >> >> diff --git a/Documentation/devicetree/bindings/usb/usb-xhci.txt >> b/Documentation/devicetree/bindings/usb/usb-xhci.txt >> index 2d80b60..96f1ac0 100644 >> --- a/Documentation/devicetree/bindings/usb/usb-xhci.txt >> +++ b/Documentation/devicetree/bindings/usb/usb-xhci.txt >> @@ -26,6 +26,7 @@ Required properties: >> >> Optional properties: >> - clocks: reference to a clock >> + - usb2-lpm-disable: disable USB2 LPM for hardware does not support it >> - usb3-lpm-capable: determines if platform is USB3 LPM capable >> - quirk-broken-port-ped: set if the controller has broken port disable >> mechanism >> >> diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c >> index 7c2a9e7..950eaf0 100644 >> --- a/drivers/usb/host/xhci-plat.c >> +++ b/drivers/usb/host/xhci-plat.c >> @@ -267,6 +267,9 @@ static int xhci_plat_probe(struct platform_device >> *pdev) >> goto disable_clk; >> } >> >> + if (device_property_read_bool(&pdev->dev, "usb2-lpm-disable")) >> + xhci->quirks |= XHCI_USB2_LPM_DISABLE; >> + >> if (device_property_read_bool(sysdev, "usb3-lpm-capable")) >> xhci->quirks |= XHCI_LPM_SUPPORT; >> >> diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c >> index 2d13102..47d51d4 100644 >> --- a/drivers/usb/host/xhci.c >> +++ b/drivers/usb/host/xhci.c >> @@ -4055,6 +4055,7 @@ static int xhci_set_usb2_hardware_lpm(struct usb_hcd >> *hcd, >> unsigned long flags; >> int hird, exit_latency; >> int ret; >> + int usb2_lpm_disable = 0; >> >> if (hcd->speed >= HCD_USB3 || !xhci->hw_lpm_support || >> !udev->lpm_capable) >> @@ -4079,7 +4080,11 @@ static int xhci_set_usb2_hardware_lpm(struct >> usb_hcd *hcd, >> xhci_dbg(xhci, "%s port %d USB2 hardware LPM\n", >> enable ? "enable" : "disable", port_num + 1); >> >> - if (enable) { >> + /* Check for optional disable USB2 LPM if XHCI 1.0 */ >> + if ((xhci->quirks & XHCI_USB2_LPM_DISABLE) && (xhci->hci_version >> == 0x100)) >> + usb2_lpm_disable = 1; >> + >> + if (enable && !usb2_lpm_disable) { > > Wouldn't it be better to just keep xhci->hw_lpm_support = 0 if the host > doesn't support Hardware LPM Capability, (HLC)? > > This should prevent all those extra steps getting here just to do nothing. No, HLC = 0 means the host doesn't support Hardware LPM. The problem here is the host support Hardware LPM but there is a bug in host controller that make the LPM fail to work. When debugging the host controller, we detect there are some holes in the current usb specifications which can can result in inter-operating problems between USB Host Controller and USB PHY. To be more specific, the specs have not clarified the resume recovery timing after the port has just waken up from L1. This can lead to different interpretations of the specs by Host Controller and PHY. What happened in our case is that a Host controller cannot work with a PHY right after resuming from L1 because these two Vendors have different views of the specs regarding LPM timing after L1. These views are contradictory and cannot work together. If Host Controller and PHY are from the same vendor, they might have some "internal handshake mechanisms" to avoid these holes of the USB specs. However, these mechanisms are not standardized in USB specs; and not all vendors follow these mechanisms. In fact, we have observed this kind of "internal handshake mechanism" in HOST Controller and PHY from SYNOPSYS DWC. So, we can say that if users use Host Controller and PHY from different Vendors, the inteopering problems after waking up from L1 are more likely to occur. > > the quirk check could be done in xhci-mem.c in xhci_add_in_port() > > if (temp & XHCI_HLC &&) { > xhci_dbg_trace(xhci, t
Re: g_mass_storage emulation of flash drive - difficulties with passing vendor/product ID
On Sun, 4 Jun 2017, Alan Robertson wrote: > Hi > > Apologies for my first post here being a request for help, but after > extensive searching online I've not yet been able to find and answer > and am hopeful the expertise here may be able to help! > > I have a Raspberry Pi Zero W that I'm using in OTG/gadget mode. I've > activated dwc2 USB, partitioned and formatted the file that is to be > used as filesystem and loaded g_mass_storage. > > It is working fine in Windows - I can connect and see the contents, > add/delete files, eject and reconnect seeing changes fine. I can mount > it in Raspbian to check contents and can also attach it to other > devices and interact with it fine. > > However, I've got some devices that are very picky about what USB > devices they will connect to (solely flash drives). The problem is the > OTG mass storage gadget is being identified as "File-Stor Gadget (Rev: > 0404)" for device type, which is causing it to be rejected. > > I can successfully use a USB flash drive in the target devices and > have scraped the vendor/product ID, etc from this flash drive to see > if I can mimic them via g_mass_storage. > > I have adjusted modprobe to the following: > > $ sudo modprobe g_mass_storage file=/home/pi/piusb.bin stall=0 > removable=1 idVendor=0x0781 idProduct=0x5572 bcdDevice=0x011a > iManufacturer="SanDisk" iProduct="Cruzer Switch" > iSerialNumber="123456789012" > > Unfortunately this doesn't seem to have made any difference and it is > still rejected by the target devices. > > As far as I can tell the above parameters are getting passed through correctly > $ ls /sys/module/g_mass_storage/parameters/* > /sys/module/g_mass_storage/parameters/bcdDevice > /sys/module/g_mass_storage/parameters/cdrom > /sys/module/g_mass_storage/parameters/file > /sys/module/g_mass_storage/parameters/idProduct > /sys/module/g_mass_storage/parameters/idVendor > /sys/module/g_mass_storage/parameters/iManufacturer > /sys/module/g_mass_storage/parameters/iProduct > /sys/module/g_mass_storage/parameters/iSerialNumber > /sys/module/g_mass_storage/parameters/luns > /sys/module/g_mass_storage/parameters/nofua > /sys/module/g_mass_storage/parameters/removable > /sys/module/g_mass_storage/parameters/ro > /sys/module/g_mass_storage/parameters/stall > > $ cat /sys/module/g_mass_storage/parameters/* > 282 > /home/pi/piusb.bin > 21874 > 1921 > SanDisk > Cruzer_Switch > 123456789012 > 0 > Y > N > > However when connecting to Windows, here's what the USB mass storage > displays - it appears that the iSerialNumber is making it through, but > nothing else is being altered. My router shows similar issues, > identifying it as "File-Stor Gadget (Rev: 0404)" > > USBSTOR\DISK&VEN_LINUX&PROD_FILE-STOR_GADGET&REV_0404\123456789012&0 > USBSTOR\DiskLinux___File-Stor_Gadget0404 > USBSTOR\DiskLinux___File-Stor_Gadget > USBSTOR\DiskLinux___ > USBSTOR\Linux___File-Stor_Gadget0 > Linux___File-Stor_Gadget0 > USBSTOR\GenDisk > GenDisk > > By comparison, here's what SanDisk shows: > > USBSTOR\DISK&VEN_SANDISK&PROD_CRUZER_SWITCH&REV_1.26\4C532015741508522393&0 > USBSTOR\DiskSanDisk_Cruzer_Switch___1.26 > USBSTOR\DiskSanDisk_Cruzer_Switch___ > USBSTOR\DiskSanDisk_ > USBSTOR\SanDisk_Cruzer_Switch___1 > SanDisk_Cruzer_Switch___1 > USBSTOR\GenDisk > GenDisk Never mind Windows -- if you connect your gadget to a computer running Linux, what does "lsusb -v" show? Alan Stern -- 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 http://vger.kernel.org/majordomo-info.html
Re: [PATCH v14 4/7] usb: core: add power sequence handling for USB devices
On Mon, 5 Jun 2017, Peter Chen wrote: > On Thu, May 18, 2017 at 08:49:00AM +0800, Peter Chen wrote: > > Some hard-wired USB devices need to do power sequence to let the > > device work normally, the typical power sequence like: enable USB > > PHY clock, toggle reset pin, etc. But current Linux USB driver > > lacks of such code to do it, it may cause some hard-wired USB devices > > works abnormal or can't be recognized by controller at all. > > > > In this patch, it calls power sequence library APIs to finish > > the power sequence events. It will do power on sequence at hub's > > probe for all devices under this hub (includes root hub). > > At hub_disconnect, it will do power off sequence which is at powered > > on list. > > > > Greg, Alan, would you please help on reviewing it? It seems Rafael > is waiting for USB MAINTAINERS's comments or ack. It resolves some > USB HUB issues for several persons. > > Peter > > > Signed-off-by: Peter Chen > > Tested-by Joshua Clayton > > Tested-by: Maciej S. Szmigiero > > Reviewed-by: Vaibhav Hiremath Acked-by: Alan Stern > > --- > > drivers/usb/Kconfig| 1 + > > drivers/usb/core/hub.c | 49 > > + > > drivers/usb/core/hub.h | 1 + > > 3 files changed, 47 insertions(+), 4 deletions(-) > > > > diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig > > index 939a63b..b6f626e 100644 > > --- a/drivers/usb/Kconfig > > +++ b/drivers/usb/Kconfig > > @@ -39,6 +39,7 @@ config USB > > tristate "Support for Host-side USB" > > depends on USB_ARCH_HAS_HCD > > select USB_COMMON > > + select POWER_SEQUENCE > > select NLS # for UTF-8 strings > > ---help--- > > Universal Serial Bus (USB) is a specification for a serial bus > > diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c > > index 9dca59e..7a67296 100644 > > --- a/drivers/usb/core/hub.c > > +++ b/drivers/usb/core/hub.c > > @@ -28,6 +28,7 @@ > > #include > > #include > > #include > > +#include > > > > #include > > #include > > @@ -1619,6 +1620,7 @@ static void hub_disconnect(struct usb_interface *intf) > > hub->error = 0; > > hub_quiesce(hub, HUB_DISCONNECT); > > > > + of_pwrseq_off_list(&hub->pwrseq_on_list); Things like this look a little peculiar -- you are passing an "on_list" to a function named "...off_list". How about naming the new field hub->pwrseq_list instead? Alan Stern -- 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 http://vger.kernel.org/majordomo-info.html
[PATCH v2] USB: add usbfs ioctl to retrieve the connection speed
The usbfs interface does not provide any way for the user to learn the speed at which a device is connected. The current API includes a USBDEVFS_CONNECTINFO ioctl, but all it provides is the device's address and a one-bit value indicating whether the connection is low speed. That may have sufficed in the era of USB-1.1, but it isn't good enough today. This patch introduces a new ioctl, USBDEVFS_GET_SPEED, which returns a numeric value indicating the speed of the connection: unknown, low, full, high, wireless, super, or super-plus. Similar information (not exactly the same) is available through sysfs, but it seems reasonable to provide the actual value in usbfs. Signed-off-by: Alan Stern Reported-by: Reinhard Huck --- v2: Use the USB_SPEED_* values already defined in include/uapi/linux/usb/ch9.h instead of inventing new constants. [as1832b] drivers/usb/core/devio.c |3 +++ include/uapi/linux/usbdevice_fs.h |6 ++ 2 files changed, 9 insertions(+) Index: usb-4.x/drivers/usb/core/devio.c === --- usb-4.x.orig/drivers/usb/core/devio.c +++ usb-4.x/drivers/usb/core/devio.c @@ -2537,6 +2537,9 @@ static long usbdev_do_ioctl(struct file case USBDEVFS_DROP_PRIVILEGES: ret = proc_drop_privileges(ps, p); break; + case USBDEVFS_GET_SPEED: + ret = ps->dev->speed; + break; } done: Index: usb-4.x/include/uapi/linux/usbdevice_fs.h === --- usb-4.x.orig/include/uapi/linux/usbdevice_fs.h +++ usb-4.x/include/uapi/linux/usbdevice_fs.h @@ -156,6 +156,11 @@ struct usbdevfs_streams { unsigned char eps[0]; }; +/* + * USB_SPEED_* values returned by USBDEVFS_GET_SPEED are defined in + * linux/usb/ch9.h + */ + #define USBDEVFS_CONTROL _IOWR('U', 0, struct usbdevfs_ctrltransfer) #define USBDEVFS_CONTROL32 _IOWR('U', 0, struct usbdevfs_ctrltransfer32) #define USBDEVFS_BULK _IOWR('U', 2, struct usbdevfs_bulktransfer) @@ -190,5 +195,6 @@ struct usbdevfs_streams { #define USBDEVFS_ALLOC_STREAMS _IOR('U', 28, struct usbdevfs_streams) #define USBDEVFS_FREE_STREAMS _IOR('U', 29, struct usbdevfs_streams) #define USBDEVFS_DROP_PRIVILEGES _IOW('U', 30, __u32) +#define USBDEVFS_GET_SPEED _IO('U', 31) #endif /* _UAPI_LINUX_USBDEVICE_FS_H */ -- 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 http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/2] usb: typec: Add support for UCSI interface
UCSI - USB Type-C Connector System Software Interface - is a specification that defines set of registers and data structures for controlling the USB Type-C ports. It's designed for systems where an embedded controller (EC) is in charge of the USB Type-C PHY or USB Power Delivery controller. It is designed for systems with EC, but it is not limited to them, and for example some USB Power Delivery controllers will use it as their direct control interface. With UCSI the EC (or USB PD controller) acts as the port manager, implementing all USB Type-C and Power Delivery state machines. The OS can use the interfaces for reading the status of the ports and controlling basic operations like role swapping. The UCSI specification highlights the fact that it does not define the interface method (PCI/I2C/ACPI/etc.). Therefore the driver is implemented as library and every supported interface method needs its own driver. Driver for ACPI is provided in separate patch following this one. The initial driver includes support for all required features from UCSI specification version 1.0 (getting connector capabilities and status, and support for power and data role swapping), but none of the optional UCSI features (alternate modes, power source capabilities, and cable capabilities). Signed-off-by: Heikki Krogerus --- drivers/usb/typec/Kconfig | 2 + drivers/usb/typec/Makefile | 1 + drivers/usb/typec/ucsi/Kconfig | 22 ++ drivers/usb/typec/ucsi/Makefile | 7 + drivers/usb/typec/ucsi/debug.h | 64 drivers/usb/typec/ucsi/trace.c | 2 + drivers/usb/typec/ucsi/trace.h | 143 drivers/usb/typec/ucsi/ucsi.c | 790 drivers/usb/typec/ucsi/ucsi.h | 330 + 9 files changed, 1361 insertions(+) create mode 100644 drivers/usb/typec/ucsi/Kconfig create mode 100644 drivers/usb/typec/ucsi/Makefile create mode 100644 drivers/usb/typec/ucsi/debug.h create mode 100644 drivers/usb/typec/ucsi/trace.c create mode 100644 drivers/usb/typec/ucsi/trace.h create mode 100644 drivers/usb/typec/ucsi/ucsi.c create mode 100644 drivers/usb/typec/ucsi/ucsi.h diff --git a/drivers/usb/typec/Kconfig b/drivers/usb/typec/Kconfig index dfcfe459b7cf..bc1b7745f1d4 100644 --- a/drivers/usb/typec/Kconfig +++ b/drivers/usb/typec/Kconfig @@ -19,4 +19,6 @@ config TYPEC_WCOVE To compile this driver as module, choose M here: the module will be called typec_wcove +source "drivers/usb/typec/ucsi/Kconfig" + endmenu diff --git a/drivers/usb/typec/Makefile b/drivers/usb/typec/Makefile index b9cb862221af..bc214f15f1b5 100644 --- a/drivers/usb/typec/Makefile +++ b/drivers/usb/typec/Makefile @@ -1,2 +1,3 @@ obj-$(CONFIG_TYPEC)+= typec.o obj-$(CONFIG_TYPEC_WCOVE) += typec_wcove.o +obj-$(CONFIG_TYPEC_UCSI) += ucsi/ diff --git a/drivers/usb/typec/ucsi/Kconfig b/drivers/usb/typec/ucsi/Kconfig new file mode 100644 index ..679ba6648396 --- /dev/null +++ b/drivers/usb/typec/ucsi/Kconfig @@ -0,0 +1,22 @@ +config TYPEC_UCSI + tristate "USB Type-C Connector System Software Interface driver" + select TYPEC + help + USB Type-C Connector System Software Interface (UCSI) is a + specification for an interface that allows the operating system to + control the USB Type-C ports. On UCSI system the USB Type-C ports + function autonomously by default, but in order to get the status of + the ports and support basic operations like role swapping, the driver + is required. UCSI is available on most of the new Intel based systems + that are equipped with Embedded Controller and USB Type-C ports. + + UCSI specification does not define the interface method, so depending + on the platform, ACPI, PCI, I2C, etc. may be used. Therefore this + driver only provides the core part, and separate drivers are needed + for every supported interface method. + + The UCSI specification can be downloaded from: + http://www.intel.com/content/www/us/en/io/universal-serial-bus/usb-type-c-ucsi-spec.html + + To compile the driver as a module, choose M here: the module will be + called typec_ucsi. diff --git a/drivers/usb/typec/ucsi/Makefile b/drivers/usb/typec/ucsi/Makefile new file mode 100644 index ..87dd6ee6c9f3 --- /dev/null +++ b/drivers/usb/typec/ucsi/Makefile @@ -0,0 +1,7 @@ +CFLAGS_trace.o := -I$(src) + +obj-$(CONFIG_TYPEC_UCSI) += typec_ucsi.o + +typec_ucsi-y := ucsi.o + +typec_ucsi-$(CONFIG_FTRACE)+= trace.o diff --git a/drivers/usb/typec/ucsi/debug.h b/drivers/usb/typec/ucsi/debug.h new file mode 100644 index ..87d0cd20597a --- /dev/null +++ b/drivers/usb/typec/ucsi/debug.h @@ -0,0 +1,64 @@ +#ifndef __UCSI_DEBUG_H +#define __UCSI_DEBUG_H + +#include "ucsi.h" + +static const char * const ucsi_cmd_strs[] = { + [0]
[PATCH v2 0/3] New driver for UCSI (USB Type-C)
Hi, This moves the current ucsi driver from drivers/usb/misc/ucsi.c to the new USB Type-C class (drivers/usb/typec/). That allows us to finally do role swapping. The driver is now split into core library part, and ACPI driver. That should make it easy to add support for other interface methods (first most likely being I2C) later if needed. Changes since v1: - Added separate flag from pending ACK. Some new platforms generate "command complete" event on top of the normal "ACK complete" event with ACK commands. In such cases the driver has to be able to basically ignore the command completion in case of ACK and only finish acknowledge routine when the actual ACK complete event is received. Otherwise a new command may be queued to the PPM before the previous has fully completed. - Added an explanation why we are handling the PPM initialization in a work as suggested by Guenter. - Fixed ucsi_reset_ppm() by removing possibility of returning -ETIMEDOUT in case of success right before the time expires. Suggested by Guenter. - Replaced useless "goto err;" with "break;" in ucsi_run_command() as suggested by Guenter. - Removed traceback in case of failure from ucsi_run_command() which is not necessary as suggested by Guenter. - Highlighting the fact that the timeouts are in milliseconds by using _MS ending with the definition (UCSI_TIMEOUT_MS and UCSI_SWAP_TIMEOUT_MS) as suggested by Guenter. - Including also in ucsi.h as suggested by Guenter. - In ucsi_acpi.c, explicitly pointing out in the comment that we can not use devm_ioremap_resource() as suggested by Guenter. Heikki Krogerus (2): usb: typec: Add support for UCSI interface usb: typec: ucsi: Add ACPI driver drivers/usb/misc/Kconfig| 26 -- drivers/usb/misc/Makefile | 1 - drivers/usb/misc/ucsi.c | 478 --- drivers/usb/typec/Kconfig | 2 + drivers/usb/typec/Makefile | 1 + drivers/usb/typec/ucsi/Kconfig | 38 ++ drivers/usb/typec/ucsi/Makefile | 9 + drivers/usb/typec/ucsi/debug.h | 64 +++ drivers/usb/typec/ucsi/trace.c | 2 + drivers/usb/typec/ucsi/trace.h | 143 ++ drivers/usb/typec/ucsi/ucsi.c | 790 drivers/usb/{misc => typec/ucsi}/ucsi.h | 187 ++-- drivers/usb/typec/ucsi/ucsi_acpi.c | 158 +++ 13 files changed, 1358 insertions(+), 541 deletions(-) delete mode 100644 drivers/usb/misc/ucsi.c create mode 100644 drivers/usb/typec/ucsi/Kconfig create mode 100644 drivers/usb/typec/ucsi/Makefile create mode 100644 drivers/usb/typec/ucsi/debug.h create mode 100644 drivers/usb/typec/ucsi/trace.c create mode 100644 drivers/usb/typec/ucsi/trace.h create mode 100644 drivers/usb/typec/ucsi/ucsi.c rename drivers/usb/{misc => typec/ucsi}/ucsi.h (60%) create mode 100644 drivers/usb/typec/ucsi/ucsi_acpi.c -- 2.11.0 -- 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 http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/2] usb: typec: ucsi: Add ACPI driver
Driver for ACPI UCSI interface method. This driver replaces the previous UCSI driver drivers/usb/misc/ucsi.c. Signed-off-by: Heikki Krogerus --- drivers/usb/misc/Kconfig | 26 -- drivers/usb/misc/Makefile | 1 - drivers/usb/misc/ucsi.c| 478 - drivers/usb/misc/ucsi.h| 215 - drivers/usb/typec/ucsi/Kconfig | 16 ++ drivers/usb/typec/ucsi/Makefile| 2 + drivers/usb/typec/ucsi/ucsi_acpi.c | 158 7 files changed, 176 insertions(+), 720 deletions(-) delete mode 100644 drivers/usb/misc/ucsi.c delete mode 100644 drivers/usb/misc/ucsi.h create mode 100644 drivers/usb/typec/ucsi/ucsi_acpi.c diff --git a/drivers/usb/misc/Kconfig b/drivers/usb/misc/Kconfig index 1d1d70d62a19..0f9f25db9163 100644 --- a/drivers/usb/misc/Kconfig +++ b/drivers/usb/misc/Kconfig @@ -275,29 +275,3 @@ config USB_CHAOSKEY To compile this driver as a module, choose M here: the module will be called chaoskey. - -config UCSI - tristate "USB Type-C Connector System Software Interface driver" - depends on ACPI - help - UCSI driver is meant to be used as a convenience tool for desktop and - server systems that are not equipped to handle USB in device mode. It - will always select USB host role for the USB Type-C ports on systems - that provide UCSI interface. - - USB Type-C Connector System Software Interface (UCSI) is a - specification for an interface that allows the Operating System to - control the USB Type-C ports on a system. Things the need controlling - include the USB Data Role (host or device), and when USB Power - Delivery is supported, the Power Role (source or sink). With USB - Type-C connectors, when two dual role capable devices are attached - together, the data role is selected randomly. Therefore it is - important to give the OS a way to select the role. Otherwise the user - would have to unplug and replug in order in order to attempt to swap - the data and power roles. - - The UCSI specification can be downloaded from: - http://www.intel.com/content/www/us/en/io/universal-serial-bus/usb-type-c-ucsi-spec.html - - To compile the driver as a module, choose M here: the module will be - called ucsi. diff --git a/drivers/usb/misc/Makefile b/drivers/usb/misc/Makefile index f6ac6c99a6e6..7fdb45fc976f 100644 --- a/drivers/usb/misc/Makefile +++ b/drivers/usb/misc/Makefile @@ -27,7 +27,6 @@ obj-$(CONFIG_USB_HUB_USB251XB)+= usb251xb.o obj-$(CONFIG_USB_HSIC_USB3503) += usb3503.o obj-$(CONFIG_USB_HSIC_USB4604) += usb4604.o obj-$(CONFIG_USB_CHAOSKEY) += chaoskey.o -obj-$(CONFIG_UCSI) += ucsi.o obj-$(CONFIG_USB_SISUSBVGA)+= sisusbvga/ obj-$(CONFIG_USB_LINK_LAYER_TEST) += lvstest.o diff --git a/drivers/usb/misc/ucsi.c b/drivers/usb/misc/ucsi.c deleted file mode 100644 index 07397bddefa3.. --- a/drivers/usb/misc/ucsi.c +++ /dev/null @@ -1,478 +0,0 @@ -/* - * USB Type-C Connector System Software Interface driver - * - * Copyright (C) 2016, Intel Corporation - * Author: Heikki Krogerus - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License version 2 as - * published by the Free Software Foundation. - */ - -#include -#include -#include -#include - -#include "ucsi.h" - -/* Double the time defined by MIN_TIME_TO_RESPOND_WITH_BUSY */ -#define UCSI_TIMEOUT_MS 20 - -enum ucsi_status { - UCSI_IDLE = 0, - UCSI_BUSY, - UCSI_ERROR, -}; - -struct ucsi_connector { - int num; - struct ucsi *ucsi; - struct work_struct work; - struct ucsi_connector_capability cap; -}; - -struct ucsi { - struct device *dev; - struct ucsi_data __iomem *data; - - enum ucsi_status status; - struct completion complete; - struct ucsi_capability cap; - struct ucsi_connector *connector; - - /* device lock */ - spinlock_t dev_lock; - - /* PPM Communication lock */ - struct mutex ppm_lock; - - /* PPM communication flags */ - unsigned long flags; -#define EVENT_PENDING 0 -#define COMMAND_PENDING1 -}; - -static int ucsi_acpi_cmd(struct ucsi *ucsi, struct ucsi_control *ctrl) -{ - uuid_le uuid = UUID_LE(0x6f8398c2, 0x7ca4, 0x11e4, - 0xad, 0x36, 0x63, 0x10, 0x42, 0xb5, 0x00, 0x8f); - union acpi_object *obj; - - ucsi->data->ctrl.raw_cmd = ctrl->raw_cmd; - - obj = acpi_evaluate_dsm(ACPI_HANDLE(ucsi->dev), uuid.b, 1, 1, NULL); - if (!obj) { - dev_err(ucsi->dev, "%s: failed to evaluate _DSM\n", __func__); - return -EIO; - } - - ACPI_FREE(obj); - return 0; -} - -static void ucsi_acpi_notif
Re: [v2 1/1] usb:host:xhci support option to disable xHCI 1.0 USB2 HW LPM
On 05.06.2017 15:57, Thang Q. Nguyen wrote: On Mon, Jun 5, 2017 at 6:14 PM, Mathias Nyman wrote: On 20.05.2017 10:24, Thang Q. Nguyen wrote: XHCI specification 1.1 does not require xHCI 1.0 compliant controllers to always enable hardware USB2 LPM. However, the current xHCI driver always enable it by setting HLE=1 when seeing HLC=1. This makes certain xHCI controllers that have broken USB2 HW LPM fail to work as there is no way to disable this feature. This patch adds support to control disabling USB2 Hardware LPM via DT/ACPI attribute. Wouldn't it be better to just keep xhci->hw_lpm_support = 0 if the host doesn't support Hardware LPM Capability, (HLC)? This should prevent all those extra steps getting here just to do nothing. No, HLC = 0 means the host doesn't support Hardware LPM. The problem here is the host support Hardware LPM but there is a bug in host controller that make the LPM fail to work. So the host support hw LPM, and has its HLC capability bit set, but in the end it just doesn't work at all, and should be prevented. When debugging the host controller, we detect there are some holes in the current usb specifications which can can result in inter-operating problems between USB Host Controller and USB PHY. To be more specific, the specs have not clarified the resume recovery timing after the port has just waken up from L1. This can lead to different interpretations of the specs by Host Controller and PHY. What happened in our case is that a Host controller cannot work with a PHY right after resuming from L1 because these two Vendors have different views of the specs regarding LPM timing after L1. These views are contradictory and cannot work together. If Host Controller and PHY are from the same vendor, they might have some "internal handshake mechanisms" to avoid these holes of the USB specs. However, these mechanisms are not standardized in USB specs; and not all vendors follow these mechanisms. In fact, we have observed this kind of "internal handshake mechanism" in HOST Controller and PHY from SYNOPSYS DWC. So, we can say that if users use Host Controller and PHY from different Vendors, the inteopering problems after waking up from L1 are more likely to occur. Can you explain the reason why you prefer preventing hw lpm inside the xhci_set_usb2_hardware_lpm() function instead of preventing hw lpm usage all together for this platform -i.e. by not setting xhci->hw_lpm_support Again, something like: if (temp & XHCI_HLC && !(xhci->quirks & XHCI_HW_LPM_BROKEN)) xhci->hw_lpm_support = 1; The HW LPM can also be disabled (per device) in sysfs if needed. This does not work. When the issue happens, the USB device is fail to probe so no /sys interface created. Messages displayed when issue happen is similar to: [ 2846.677903] usb 1-1: reset high-speed USB device number 2 using xhci-hcd [ 2882.037125] usb usb1-port1: Cannot enable. Maybe the USB cable is bad? or usb usb3-port1: disabled by hub (EMI?), re-enabling... [ 57.840237] usb 3-1: USB disconnect, device number 5 Ok, the sysfs entry is not useful in this case. -Mathias -- 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 http://vger.kernel.org/majordomo-info.html
Re: [PATCH] net/{mii,smsc}: Make mii_ethtool_get_link_ksettings and smc_netdev_get_ecmd return void
From: Yuval Shaia Date: Sun, 4 Jun 2017 20:22:00 +0300 > Make return value void since functions never returns meaningfull value. > > Signed-off-by: Yuval Shaia Applied to net-next. -- 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 http://vger.kernel.org/majordomo-info.html
Re: XHCI is slow during boot (bios/efi) and leaves many dmesg messages
2017-06-05 2:08 GMT-06:00 Maël Lavault : > Anything I can do to help ? It is a very annoying issue for me, to > boot, I have to select an old 4.10 kernel (which takes ages since usb > is extremely slow on first boot), then reboot into a 4.11 kernel (usb > works again as it should after a reboot) with a special drm fix > (otherwise my computer freeze). Run `dmesg | grep 'DMI:'` and if the BIOS version is older than February 2017, reinstall Mac OS X and install the Sierra 10.12.5 update. That finally fixed the problem for me. -Alex -- 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 http://vger.kernel.org/majordomo-info.html
[PATCH v6 5/6] mfd: intel_soc_pmic_bxtwc: Use chained IRQs for second level IRQ chips
From: Kuppuswamy Sathyanarayanan Whishkey cove PMIC has support to mask/unmask interrupts at two levels. At first level we can mask/unmask interrupt domains like TMU, GPIO, ADC, CHGR, BCU THERMAL and PWRBTN and at second level, it provides facility to mask/unmask individual interrupts belong each of this domain. For example, in case of TMU, at first level we have TMU interrupt domain, and at second level we have two interrupts, wake alarm, system alarm that belong to the TMU interrupt domain. Currently, in this driver all first level IRQs are registered as part of IRQ chip(bxtwc_regmap_irq_chip). By default, after you register the IRQ chip from your driver, all IRQs in that chip will masked and can only be enabled if that IRQ is requested using request_irq() call. This is the default Linux IRQ behavior model. And whenever a dependent device that belongs to PMIC requests only the second level IRQ and not explicitly unmask the first level IRQ, then in essence the second level IRQ will still be disabled. For example, if TMU device driver request wake_alarm IRQ and not explicitly unmask TMU level 1 IRQ then according to the default Linux IRQ model, wake_alarm IRQ will still be disabled. So the proper solution to fix this issue is to use the chained IRQ chip concept. We should chain all the second level chip IRQs to the corresponding first level IRQ. To do this, we need to create separate IRQ chips for every group of second level IRQs. In case of TMU, when adding second level IRQ chip, instead of using PMIC IRQ we should use the corresponding first level IRQ. So the following code will change from ret = regmap_add_irq_chip(pmic->regmap, pmic->irq, ...) to, virq = regmap_irq_get_virq(&pmic->irq_chip_data, BXTWC_TMU_LVL1_IRQ); ret = regmap_add_irq_chip(pmic->regmap, virq, ...) In case of Whiskey Cove Type-C driver, Since USBC IRQ is moved under charger level2 IRQ chip. We should use charger IRQ chip(irq_chip_data_chgr) to get the USBC virtual IRQ number. Signed-off-by: Kuppuswamy Sathyanarayanan Acked-for-MFD-by: Lee Jones --- drivers/mfd/intel_soc_pmic_bxtwc.c | 168 ++--- drivers/usb/typec/typec_wcove.c| 2 +- include/linux/mfd/intel_soc_pmic.h | 5 +- 3 files changed, 143 insertions(+), 32 deletions(-) Changes since v1: * Rebased on top of dev_* cleanup patch. * Fixed style & grammer issues reported by Lee Jones Changes since v2: * Rebased on top of latest release. Changes since v3: * None Changes since v4: * Merged typec driver fix to this patch to prevent branch bisect issue. Changes since v5: * Changed irq->IRQ and pmic -> PMIC. * Rearranged tmu related changes to make the patch more readable. * Modfied the virq request failure message to include chip name and pirq. diff --git a/drivers/mfd/intel_soc_pmic_bxtwc.c b/drivers/mfd/intel_soc_pmic_bxtwc.c index feeda6e..15bc052 100644 --- a/drivers/mfd/intel_soc_pmic_bxtwc.c +++ b/drivers/mfd/intel_soc_pmic_bxtwc.c @@ -82,20 +82,28 @@ enum bxtwc_irqs { BXTWC_PWRBTN_IRQ, }; -enum bxtwc_irqs_level2 { - /* Level 2 */ +enum bxtwc_irqs_bcu { BXTWC_BCU_IRQ = 0, - BXTWC_ADC_IRQ, - BXTWC_USBC_IRQ, +}; + +enum bxtwc_irqs_adc { + BXTWC_ADC_IRQ = 0, +}; + +enum bxtwc_irqs_chgr { + BXTWC_USBC_IRQ = 0, BXTWC_CHGR0_IRQ, BXTWC_CHGR1_IRQ, - BXTWC_CRIT_IRQ, }; enum bxtwc_irqs_tmu { BXTWC_TMU_IRQ = 0, }; +enum bxtwc_irqs_crit { + BXTWC_CRIT_IRQ = 0, +}; + static const struct regmap_irq bxtwc_regmap_irqs[] = { REGMAP_IRQ_REG(BXTWC_PWRBTN_LVL1_IRQ, 0, BIT(0)), REGMAP_IRQ_REG(BXTWC_TMU_LVL1_IRQ, 0, BIT(1)), @@ -108,19 +116,28 @@ static const struct regmap_irq bxtwc_regmap_irqs[] = { REGMAP_IRQ_REG(BXTWC_PWRBTN_IRQ, 1, 0x03), }; -static const struct regmap_irq bxtwc_regmap_irqs_level2[] = { +static const struct regmap_irq bxtwc_regmap_irqs_bcu[] = { REGMAP_IRQ_REG(BXTWC_BCU_IRQ, 0, 0x1f), - REGMAP_IRQ_REG(BXTWC_ADC_IRQ, 1, 0xff), - REGMAP_IRQ_REG(BXTWC_USBC_IRQ, 2, BIT(5)), - REGMAP_IRQ_REG(BXTWC_CHGR0_IRQ, 2, 0x1f), - REGMAP_IRQ_REG(BXTWC_CHGR1_IRQ, 3, 0x1f), - REGMAP_IRQ_REG(BXTWC_CRIT_IRQ, 6, 0x03), +}; + +static const struct regmap_irq bxtwc_regmap_irqs_adc[] = { + REGMAP_IRQ_REG(BXTWC_ADC_IRQ, 0, 0xff), +}; + +static const struct regmap_irq bxtwc_regmap_irqs_chgr[] = { + REGMAP_IRQ_REG(BXTWC_USBC_IRQ, 0, BIT(5)), + REGMAP_IRQ_REG(BXTWC_CHGR0_IRQ, 0, 0x1f), + REGMAP_IRQ_REG(BXTWC_CHGR1_IRQ, 1, 0x1f), }; static const struct regmap_irq bxtwc_regmap_irqs_tmu[] = { REGMAP_IRQ_REG(BXTWC_TMU_IRQ, 0, 0x06), }; +static const struct regmap_irq bxtwc_regmap_irqs_crit[] = { + REGMAP_IRQ_REG(BXTWC_CRIT_IRQ, 0, 0x03), +}; + static struct regmap_irq_chip bxtwc_regmap_irq_chip = { .name = "bxtwc_irq_chip", .status_base = BXTWC_IRQLVL1, @@ -130,15 +147,6 @@ static struct regmap_irq_chip bxtwc_regmap_irq_chip = {
[PATCH v6 0/6] mfd: intel_soc_pmic_bxtwc: Add chained IRQ support
From: Kuppuswamy Sathyanarayanan Following patch set adds chained IRQ support to WCOVE PMIC driver. Changes since v3: * Added fix for typec wcove driver. Changes since v4: * Squashed following two commits, to keep the patch set bisectable. usb: typec: typec_wcove: Use charger irq chip to get usbc virq mfd: intel_soc_pmic_bxtwc: use chained irqs for second level irq chips Changes since v5: * Changed irq->IRQ, pmic->PMIC in all commit messages. * Squashed following two thermal driver related commits. mfd: intel_soc_pmic_bxtwc: Remove thermal second level irqs thermal: intel_bxt_pmic_thermal: Use first level PMIC thermal irq * Squashed following two GPIO driver related commits. mfd: intel_soc_pmic_bxtwc: Remove second level irq for gpio device gpio: gpio-wcove: Use first level PMIC GPIO irq Kuppuswamy Sathyanarayanan (6): mfd: intel_soc_pmic_bxtwc: Fix TMU interrupt index mfd: intel_soc_pmic_bxtwc: Remove thermal second level IRQs mfd: intel_soc_pmic_bxtwc: Remove second level IRQ for gpio device mfd: intel_soc_pmic_bxtwc: Utilize devm_* functions in driver probe mfd: intel_soc_pmic_bxtwc: Use chained IRQs for second level IRQ chips platform/x86: intel_bxtwc_tmu: Remove first level IRQ unmask drivers/gpio/gpio-wcove.c| 14 +- drivers/mfd/intel_soc_pmic_bxtwc.c | 232 +-- drivers/platform/x86/intel_bxtwc_tmu.c | 4 - drivers/thermal/intel_bxt_pmic_thermal.c | 2 +- drivers/usb/typec/typec_wcove.c | 2 +- include/linux/mfd/intel_soc_pmic.h | 5 +- 6 files changed, 175 insertions(+), 84 deletions(-) -- 2.7.4 -- 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 http://vger.kernel.org/majordomo-info.html
[PATCH v6 4/6] mfd: intel_soc_pmic_bxtwc: Utilize devm_* functions in driver probe
From: Kuppuswamy Sathyanarayanan Cleanup the resource allocation/free code in probe function by using devm_* calls. Signed-off-by: Kuppuswamy Sathyanarayanan Acked-for-MFD-by: Lee Jones Reviewed-by: Andy Shevchenko --- drivers/mfd/intel_soc_pmic_bxtwc.c | 54 +- 1 file changed, 18 insertions(+), 36 deletions(-) Changes since v1: * None Changes since v2: * Rebased on top of latest release. Changes since v3: * None Changes since v5: * None diff --git a/drivers/mfd/intel_soc_pmic_bxtwc.c b/drivers/mfd/intel_soc_pmic_bxtwc.c index af11c43..feeda6e 100644 --- a/drivers/mfd/intel_soc_pmic_bxtwc.c +++ b/drivers/mfd/intel_soc_pmic_bxtwc.c @@ -399,45 +399,44 @@ static int bxtwc_probe(struct platform_device *pdev) return ret; } - ret = regmap_add_irq_chip(pmic->regmap, pmic->irq, - IRQF_ONESHOT | IRQF_SHARED, - 0, &bxtwc_regmap_irq_chip, - &pmic->irq_chip_data); + ret = devm_regmap_add_irq_chip(&pdev->dev, pmic->regmap, pmic->irq, + IRQF_ONESHOT | IRQF_SHARED, + 0, &bxtwc_regmap_irq_chip, + &pmic->irq_chip_data); if (ret) { dev_err(&pdev->dev, "Failed to add IRQ chip\n"); return ret; } - ret = regmap_add_irq_chip(pmic->regmap, pmic->irq, - IRQF_ONESHOT | IRQF_SHARED, - 0, &bxtwc_regmap_irq_chip_level2, - &pmic->irq_chip_data_level2); + ret = devm_regmap_add_irq_chip(&pdev->dev, pmic->regmap, pmic->irq, + IRQF_ONESHOT | IRQF_SHARED, + 0, &bxtwc_regmap_irq_chip_level2, + &pmic->irq_chip_data_level2); if (ret) { dev_err(&pdev->dev, "Failed to add secondary IRQ chip\n"); - goto err_irq_chip_level2; + return ret; } - ret = regmap_add_irq_chip(pmic->regmap, pmic->irq, - IRQF_ONESHOT | IRQF_SHARED, - 0, &bxtwc_regmap_irq_chip_tmu, - &pmic->irq_chip_data_tmu); + ret = devm_regmap_add_irq_chip(&pdev->dev, pmic->regmap, pmic->irq, + IRQF_ONESHOT | IRQF_SHARED, + 0, &bxtwc_regmap_irq_chip_tmu, + &pmic->irq_chip_data_tmu); if (ret) { dev_err(&pdev->dev, "Failed to add TMU IRQ chip\n"); - goto err_irq_chip_tmu; + return ret; } - ret = mfd_add_devices(&pdev->dev, PLATFORM_DEVID_NONE, bxt_wc_dev, - ARRAY_SIZE(bxt_wc_dev), NULL, 0, - NULL); + ret = devm_mfd_add_devices(&pdev->dev, PLATFORM_DEVID_NONE, bxt_wc_dev, + ARRAY_SIZE(bxt_wc_dev), NULL, 0, NULL); if (ret) { dev_err(&pdev->dev, "Failed to add devices\n"); - goto err_mfd; + return ret; } ret = sysfs_create_group(&pdev->dev.kobj, &bxtwc_group); if (ret) { dev_err(&pdev->dev, "Failed to create sysfs group %d\n", ret); - goto err_sysfs; + return ret; } /* @@ -451,28 +450,11 @@ static int bxtwc_probe(struct platform_device *pdev) BXTWC_MIRQLVL1_MCHGR, 0); return 0; - -err_sysfs: - mfd_remove_devices(&pdev->dev); -err_mfd: - regmap_del_irq_chip(pmic->irq, pmic->irq_chip_data_tmu); -err_irq_chip_tmu: - regmap_del_irq_chip(pmic->irq, pmic->irq_chip_data_level2); -err_irq_chip_level2: - regmap_del_irq_chip(pmic->irq, pmic->irq_chip_data); - - return ret; } static int bxtwc_remove(struct platform_device *pdev) { - struct intel_soc_pmic *pmic = dev_get_drvdata(&pdev->dev); - sysfs_remove_group(&pdev->dev.kobj, &bxtwc_group); - mfd_remove_devices(&pdev->dev); - regmap_del_irq_chip(pmic->irq, pmic->irq_chip_data); - regmap_del_irq_chip(pmic->irq, pmic->irq_chip_data_level2); - regmap_del_irq_chip(pmic->irq, pmic->irq_chip_data_tmu); return 0; } -- 2.7.4 -- 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 http://vger.kernel.org/majordomo-info.html
[PATCH v6 2/6] mfd: intel_soc_pmic_bxtwc: Remove thermal second level IRQs
From: Kuppuswamy Sathyanarayanan Since all second level thermal IRQs are consumed by the same device(bxt_wcove_thermal), there is no need to expose them as separate interrupts. We can just export only the first level IRQs for thermal and let the device(bxt_wcove_thermal) driver handle the second level IRQs based on thermal interrupt status register. Also, just using only the first level IRQ will eliminate the bug involved in requesting only the second level IRQ and not explicitly enable the first level IRQ. For more info on this issue please read the details at, https://lkml.org/lkml/2017/2/27/148 This patch also makes relevant change in bxt_wcove_thermal driver to use only first level PMIC thermal IRQ. Signed-off-by: Kuppuswamy Sathyanarayanan Acked-for-MFD-by: Lee Jones Acked-by: Zhang Rui --- drivers/mfd/intel_soc_pmic_bxtwc.c | 32 drivers/thermal/intel_bxt_pmic_thermal.c | 2 +- 2 files changed, 13 insertions(+), 21 deletions(-) Changes since v1: * None Changes since v2: * Rebased on top of latest release. Changes since v3: * Rebased on top of latest release. Changes since v5: * Squashed intel_bxt_pmic_thermal driver patch. * Changed irq -> IRQ diff --git a/drivers/mfd/intel_soc_pmic_bxtwc.c b/drivers/mfd/intel_soc_pmic_bxtwc.c index 7cbaf1e..7c1ed27 100644 --- a/drivers/mfd/intel_soc_pmic_bxtwc.c +++ b/drivers/mfd/intel_soc_pmic_bxtwc.c @@ -84,10 +84,7 @@ enum bxtwc_irqs { enum bxtwc_irqs_level2 { /* Level 2 */ - BXTWC_THRM0_IRQ = 0, - BXTWC_THRM1_IRQ, - BXTWC_THRM2_IRQ, - BXTWC_BCU_IRQ, + BXTWC_BCU_IRQ = 0, BXTWC_ADC_IRQ, BXTWC_USBC_IRQ, BXTWC_CHGR0_IRQ, @@ -114,17 +111,14 @@ static const struct regmap_irq bxtwc_regmap_irqs[] = { }; static const struct regmap_irq bxtwc_regmap_irqs_level2[] = { - REGMAP_IRQ_REG(BXTWC_THRM0_IRQ, 0, 0xff), - REGMAP_IRQ_REG(BXTWC_THRM1_IRQ, 1, 0xbf), - REGMAP_IRQ_REG(BXTWC_THRM2_IRQ, 2, 0xff), - REGMAP_IRQ_REG(BXTWC_BCU_IRQ, 3, 0x1f), - REGMAP_IRQ_REG(BXTWC_ADC_IRQ, 4, 0xff), - REGMAP_IRQ_REG(BXTWC_USBC_IRQ, 5, BIT(5)), - REGMAP_IRQ_REG(BXTWC_CHGR0_IRQ, 5, 0x1f), - REGMAP_IRQ_REG(BXTWC_CHGR1_IRQ, 6, 0x1f), - REGMAP_IRQ_REG(BXTWC_GPIO0_IRQ, 7, 0xff), - REGMAP_IRQ_REG(BXTWC_GPIO1_IRQ, 8, 0x3f), - REGMAP_IRQ_REG(BXTWC_CRIT_IRQ, 9, 0x03), + REGMAP_IRQ_REG(BXTWC_BCU_IRQ, 0, 0x1f), + REGMAP_IRQ_REG(BXTWC_ADC_IRQ, 1, 0xff), + REGMAP_IRQ_REG(BXTWC_USBC_IRQ, 2, BIT(5)), + REGMAP_IRQ_REG(BXTWC_CHGR0_IRQ, 2, 0x1f), + REGMAP_IRQ_REG(BXTWC_CHGR1_IRQ, 3, 0x1f), + REGMAP_IRQ_REG(BXTWC_GPIO0_IRQ, 4, 0xff), + REGMAP_IRQ_REG(BXTWC_GPIO1_IRQ, 5, 0x3f), + REGMAP_IRQ_REG(BXTWC_CRIT_IRQ, 6, 0x03), }; static const struct regmap_irq bxtwc_regmap_irqs_tmu[] = { @@ -142,8 +136,8 @@ static struct regmap_irq_chip bxtwc_regmap_irq_chip = { static struct regmap_irq_chip bxtwc_regmap_irq_chip_level2 = { .name = "bxtwc_irq_chip_level2", - .status_base = BXTWC_THRM0IRQ, - .mask_base = BXTWC_MTHRM0IRQ, + .status_base = BXTWC_BCUIRQ, + .mask_base = BXTWC_MBCUIRQ, .irqs = bxtwc_regmap_irqs_level2, .num_irqs = ARRAY_SIZE(bxtwc_regmap_irqs_level2), .num_regs = 10, @@ -177,9 +171,7 @@ static struct resource charger_resources[] = { }; static struct resource thermal_resources[] = { - DEFINE_RES_IRQ(BXTWC_THRM0_IRQ), - DEFINE_RES_IRQ(BXTWC_THRM1_IRQ), - DEFINE_RES_IRQ(BXTWC_THRM2_IRQ), + DEFINE_RES_IRQ(BXTWC_THRM_LVL1_IRQ), }; static struct resource bcu_resources[] = { diff --git a/drivers/thermal/intel_bxt_pmic_thermal.c b/drivers/thermal/intel_bxt_pmic_thermal.c index 0f19a39..ef6b322 100644 --- a/drivers/thermal/intel_bxt_pmic_thermal.c +++ b/drivers/thermal/intel_bxt_pmic_thermal.c @@ -241,7 +241,7 @@ static int pmic_thermal_probe(struct platform_device *pdev) } regmap = pmic->regmap; - regmap_irq_chip = pmic->irq_chip_data_level2; + regmap_irq_chip = pmic->irq_chip_data; pmic_irq_count = 0; while ((irq = platform_get_irq(pdev, pmic_irq_count)) != -ENXIO) { -- 2.7.4 -- 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 http://vger.kernel.org/majordomo-info.html
[PATCH v6 3/6] mfd: intel_soc_pmic_bxtwc: Remove second level IRQ for gpio device
From: Kuppuswamy Sathyanarayanan Currently all PMIC GPIO domain IRQs are consumed by the same device(bxt_wcove_gpio), so there is no need to export them as separate interrupts. We can just export only the first level GPIO IRQ(BXTWC_GPIO_LVL1_IRQ) as an IRQ resource and let the GPIO device driver(bxt_wcove_gpio) handle the GPIO sub domain IRQs based on status value of GPIO level2 interrupt status register. Also, just using only the first level IRQ will eliminate the bug involved in requesting only the second level IRQ and not explicitly enable the first level IRQ. For more info on this issue please read the details at, https://lkml.org/lkml/2017/2/27/148 This patch also makes relevant change in Whiskey cove GPIO driver to use only first level PMIC GPIO IRQ. Signed-off-by: Kuppuswamy Sathyanarayanan Acked-for-MFD-by: Lee Jones Acked-by: Linus Walleij --- drivers/gpio/gpio-wcove.c | 14 +- drivers/mfd/intel_soc_pmic_bxtwc.c | 7 +-- 2 files changed, 14 insertions(+), 7 deletions(-) Changes since v1: * None Changes since v2: * Rebased on top of latest release. Changes since v3: * None Changes since v5: * Squashed gpio driver patch. * Changes irq -> IRQ. diff --git a/drivers/gpio/gpio-wcove.c b/drivers/gpio/gpio-wcove.c index 7b1bc20..bba7704 100644 --- a/drivers/gpio/gpio-wcove.c +++ b/drivers/gpio/gpio-wcove.c @@ -401,7 +401,7 @@ static int wcove_gpio_probe(struct platform_device *pdev) if (!wg) return -ENOMEM; - wg->regmap_irq_chip = pmic->irq_chip_data_level2; + wg->regmap_irq_chip = pmic->irq_chip_data; platform_set_drvdata(pdev, wg); @@ -449,6 +449,18 @@ static int wcove_gpio_probe(struct platform_device *pdev) gpiochip_set_nested_irqchip(&wg->chip, &wcove_irqchip, virq); + /* Enable GPIO0 interrupts */ + ret = regmap_update_bits(wg->regmap, IRQ_MASK_BASE, GPIO_IRQ0_MASK, +0x00); + if (ret) + return ret; + + /* Enable GPIO1 interrupts */ + ret = regmap_update_bits(wg->regmap, IRQ_MASK_BASE + 1, GPIO_IRQ1_MASK, +0x00); + if (ret) + return ret; + return 0; } diff --git a/drivers/mfd/intel_soc_pmic_bxtwc.c b/drivers/mfd/intel_soc_pmic_bxtwc.c index 7c1ed27..af11c43 100644 --- a/drivers/mfd/intel_soc_pmic_bxtwc.c +++ b/drivers/mfd/intel_soc_pmic_bxtwc.c @@ -89,8 +89,6 @@ enum bxtwc_irqs_level2 { BXTWC_USBC_IRQ, BXTWC_CHGR0_IRQ, BXTWC_CHGR1_IRQ, - BXTWC_GPIO0_IRQ, - BXTWC_GPIO1_IRQ, BXTWC_CRIT_IRQ, }; @@ -116,8 +114,6 @@ static const struct regmap_irq bxtwc_regmap_irqs_level2[] = { REGMAP_IRQ_REG(BXTWC_USBC_IRQ, 2, BIT(5)), REGMAP_IRQ_REG(BXTWC_CHGR0_IRQ, 2, 0x1f), REGMAP_IRQ_REG(BXTWC_CHGR1_IRQ, 3, 0x1f), - REGMAP_IRQ_REG(BXTWC_GPIO0_IRQ, 4, 0xff), - REGMAP_IRQ_REG(BXTWC_GPIO1_IRQ, 5, 0x3f), REGMAP_IRQ_REG(BXTWC_CRIT_IRQ, 6, 0x03), }; @@ -153,8 +149,7 @@ static struct regmap_irq_chip bxtwc_regmap_irq_chip_tmu = { }; static struct resource gpio_resources[] = { - DEFINE_RES_IRQ_NAMED(BXTWC_GPIO0_IRQ, "GPIO0"), - DEFINE_RES_IRQ_NAMED(BXTWC_GPIO1_IRQ, "GPIO1"), + DEFINE_RES_IRQ_NAMED(BXTWC_GPIO_LVL1_IRQ, "GPIO"), }; static struct resource adc_resources[] = { -- 2.7.4 -- 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 http://vger.kernel.org/majordomo-info.html
[PATCH v6 1/6] mfd: intel_soc_pmic_bxtwc: Fix TMU interrupt index
From: Kuppuswamy Sathyanarayanan TMU interrupts are registered as a separate interrupt chip, and hence it should start its interrupt index(BXTWC_TMU_IRQ) number from 0. But currently, BXTWC_TMU_IRQ is defined as part of enum bxtwc_irqs_level2 and its index value is 11. Since this index value is used when calculating .num_irqs of regmap_irq_chip_tmu, it incorrectly reports number of IRQs as 12 instead of actual value of 1. This patch fixes this issue by creating new enum of tmu IRQs and resetting its starting index to 0. Signed-off-by: Kuppuswamy Sathyanarayanan Acked-for-MFD-by: Lee Jones --- drivers/mfd/intel_soc_pmic_bxtwc.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) Changes since v1: * Removed code from commit message. Changes since v2: * Rebased on top of latest release. Changes sinve v3: * Rebased on top of latest release. Changes sinve v5: * Changed irq to IRQ. diff --git a/drivers/mfd/intel_soc_pmic_bxtwc.c b/drivers/mfd/intel_soc_pmic_bxtwc.c index 8c3cbf6..7cbaf1e 100644 --- a/drivers/mfd/intel_soc_pmic_bxtwc.c +++ b/drivers/mfd/intel_soc_pmic_bxtwc.c @@ -95,7 +95,10 @@ enum bxtwc_irqs_level2 { BXTWC_GPIO0_IRQ, BXTWC_GPIO1_IRQ, BXTWC_CRIT_IRQ, - BXTWC_TMU_IRQ, +}; + +enum bxtwc_irqs_tmu { + BXTWC_TMU_IRQ = 0, }; static const struct regmap_irq bxtwc_regmap_irqs[] = { -- 2.7.4 -- 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 http://vger.kernel.org/majordomo-info.html
[PATCH v6 6/6] platform/x86: intel_bxtwc_tmu: Remove first level IRQ unmask
From: Kuppuswamy Sathyanarayanan Currently in WCOVE PMIC MFD driver, all second level IRQ chips are chained to the respective first level IRQs. So there is no need for explicitly unmasking the first level IRQ in this driver. This patches removes this level 1 IRQ unmask support. Signed-off-by: Kuppuswamy Sathyanarayanan Reviewed-by: Darren Hart (VMware) Reviewed-by: Andy Shevchenko --- drivers/platform/x86/intel_bxtwc_tmu.c | 4 1 file changed, 4 deletions(-) Changes since v1: * None Changes since v2: * Rebased on top of latest release. Changes since v3: * None Changes since v4: * Changed commit subject from "platform: x86:" "to platform/x86:" Changes since v5: * Changed irq->IRQ, mfd->MFD. diff --git a/drivers/platform/x86/intel_bxtwc_tmu.c b/drivers/platform/x86/intel_bxtwc_tmu.c index e202abd..ea865d4 100644 --- a/drivers/platform/x86/intel_bxtwc_tmu.c +++ b/drivers/platform/x86/intel_bxtwc_tmu.c @@ -92,10 +92,6 @@ static int bxt_wcove_tmu_probe(struct platform_device *pdev) } wctmu->irq = virq; - /* Enable TMU interrupts */ - regmap_update_bits(wctmu->regmap, BXTWC_MIRQLVL1, - BXTWC_MIRQLVL1_MTMU, 0); - /* Unmask TMU second level Wake & System alarm */ regmap_update_bits(wctmu->regmap, BXTWC_MTMUIRQ_REG, BXTWC_TMU_ALRM_MASK, 0); -- 2.7.4 -- 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 http://vger.kernel.org/majordomo-info.html
Re: g_mass_storage emulation of flash drive - difficulties with passing vendor/product ID
[Please use Reply-To-All so that your message gets sent to the mailing list as well as to me.] On Mon, 5 Jun 2017, Alan Robertson wrote: > On Mon, Jun 5, 2017 at 3:02 PM, Alan Stern wrote: > > On Sun, 4 Jun 2017, Alan Robertson wrote: > > > >> Hi > >> > >> Apologies for my first post here being a request for help, but after > >> extensive searching online I've not yet been able to find and answer > >> and am hopeful the expertise here may be able to help! > >> > >> I have a Raspberry Pi Zero W that I'm using in OTG/gadget mode. I've > >> activated dwc2 USB, partitioned and formatted the file that is to be > >> used as filesystem and loaded g_mass_storage. > >> > >> It is working fine in Windows - I can connect and see the contents, > >> add/delete files, eject and reconnect seeing changes fine. I can mount > >> it in Raspbian to check contents and can also attach it to other > >> devices and interact with it fine. > >> > >> However, I've got some devices that are very picky about what USB > >> devices they will connect to (solely flash drives). The problem is the > >> OTG mass storage gadget is being identified as "File-Stor Gadget (Rev: > >> 0404)" for device type, which is causing it to be rejected. > >> > >> I can successfully use a USB flash drive in the target devices and > >> have scraped the vendor/product ID, etc from this flash drive to see > >> if I can mimic them via g_mass_storage. > >> > >> I have adjusted modprobe to the following: > >> > >> $ sudo modprobe g_mass_storage file=/home/pi/piusb.bin stall=0 > >> removable=1 idVendor=0x0781 idProduct=0x5572 bcdDevice=0x011a I should point out that this bcdDevice value is not valid (it isn't a binary-coded-decimal value). > >> iManufacturer="SanDisk" iProduct="Cruzer Switch" > >> iSerialNumber="123456789012" > >> > >> Unfortunately this doesn't seem to have made any difference and it is > >> still rejected by the target devices. > >> > >> As far as I can tell the above parameters are getting passed through > >> correctly > >> $ ls /sys/module/g_mass_storage/parameters/* > >> /sys/module/g_mass_storage/parameters/bcdDevice > >> /sys/module/g_mass_storage/parameters/cdrom > >> /sys/module/g_mass_storage/parameters/file > >> /sys/module/g_mass_storage/parameters/idProduct > >> /sys/module/g_mass_storage/parameters/idVendor > >> /sys/module/g_mass_storage/parameters/iManufacturer > >> /sys/module/g_mass_storage/parameters/iProduct > >> /sys/module/g_mass_storage/parameters/iSerialNumber > >> /sys/module/g_mass_storage/parameters/luns > >> /sys/module/g_mass_storage/parameters/nofua > >> /sys/module/g_mass_storage/parameters/removable > >> /sys/module/g_mass_storage/parameters/ro > >> /sys/module/g_mass_storage/parameters/stall > >> > >> $ cat /sys/module/g_mass_storage/parameters/* > >> 282 > >> /home/pi/piusb.bin > >> 21874 > >> 1921 > >> SanDisk > >> Cruzer_Switch > >> 123456789012 > >> 0 > >> Y > >> N > >> > >> However when connecting to Windows, here's what the USB mass storage > >> displays - it appears that the iSerialNumber is making it through, but > >> nothing else is being altered. My router shows similar issues, > >> identifying it as "File-Stor Gadget (Rev: 0404)" > >> > >> USBSTOR\DISK&VEN_LINUX&PROD_FILE-STOR_GADGET&REV_0404\123456789012&0 It looks like Windows is remembering an earlier version of your gadget and matching it with the current version based on the serial number string. > >> USBSTOR\DiskLinux___File-Stor_Gadget0404 > >> USBSTOR\DiskLinux___File-Stor_Gadget > >> USBSTOR\DiskLinux___ > >> USBSTOR\Linux___File-Stor_Gadget0 > >> Linux___File-Stor_Gadget0 > >> USBSTOR\GenDisk > >> GenDisk > >> > >> By comparison, here's what SanDisk shows: > >> > >> USBSTOR\DISK&VEN_SANDISK&PROD_CRUZER_SWITCH&REV_1.26\4C532015741508522393&0 > >> USBSTOR\DiskSanDisk_Cruzer_Switch___1.26 > >> USBSTOR\DiskSanDisk_Cruzer_Switch___ > >> USBSTOR\DiskSanDisk_ > >> USBSTOR\SanDisk_Cruzer_Switch___1 > >> SanDisk_Cruzer_Switch___1 > >> USBSTOR\GenDisk > >> GenDisk > > > > Never mind Windows -- if you connect your gadget to a computer running > > Linux, what does "lsusb -v" show? > > > > Alan Stern > > > Thanks for the reply, Alan. > > Can provide the full output if it would help, but relevant part seems > to be the below: > > Bus 001 Device 004: ID 0781:5572 SanDisk Corp. > Device Descriptor: > bLength18 > bDescriptorType 1 > bcdUSB 2.00 > bDeviceClass0 (Defined at Interface level) > bDeviceSubClass 0 > bDeviceProtocol 0 > bMaxPacketSize064 > idVendor 0x0781 SanDisk Corp. > idProduct 0x5572 > bcdDevice1.1a > iManufacturer 3 SanDisk > iProduct4 Cruzer_Switch > iSerial 5 123456789012 > bNumConfigurations 1 > Configuration Descriptor: > bLength 9 > bDescriptorType 2 > wTotalLength 32 > bNumInterfaces 1 > b
Re: g_mass_storage emulation of flash drive - difficulties with passing vendor/product ID
On Mon, Jun 5, 2017 at 9:52 PM, Alan Stern wrote: > [Please use Reply-To-All so that your message gets sent to the mailing > list as well as to me.] Oops, apologies - now done! > On Mon, 5 Jun 2017, Alan Robertson wrote: > >> On Mon, Jun 5, 2017 at 3:02 PM, Alan Stern wrote: >> > On Sun, 4 Jun 2017, Alan Robertson wrote: >> > >> >> Hi >> >> >> >> Apologies for my first post here being a request for help, but after >> >> extensive searching online I've not yet been able to find and answer >> >> and am hopeful the expertise here may be able to help! >> >> >> >> I have a Raspberry Pi Zero W that I'm using in OTG/gadget mode. I've >> >> activated dwc2 USB, partitioned and formatted the file that is to be >> >> used as filesystem and loaded g_mass_storage. >> >> >> >> It is working fine in Windows - I can connect and see the contents, >> >> add/delete files, eject and reconnect seeing changes fine. I can mount >> >> it in Raspbian to check contents and can also attach it to other >> >> devices and interact with it fine. >> >> >> >> However, I've got some devices that are very picky about what USB >> >> devices they will connect to (solely flash drives). The problem is the >> >> OTG mass storage gadget is being identified as "File-Stor Gadget (Rev: >> >> 0404)" for device type, which is causing it to be rejected. >> >> >> >> I can successfully use a USB flash drive in the target devices and >> >> have scraped the vendor/product ID, etc from this flash drive to see >> >> if I can mimic them via g_mass_storage. >> >> >> >> I have adjusted modprobe to the following: >> >> >> >> $ sudo modprobe g_mass_storage file=/home/pi/piusb.bin stall=0 >> >> removable=1 idVendor=0x0781 idProduct=0x5572 bcdDevice=0x011a > > I should point out that this bcdDevice value is not valid (it isn't a > binary-coded-decimal value). Thanks, now corrected to 0x0126 - this seems to show up OK in lsusb as 1.26 now >> >> iManufacturer="SanDisk" iProduct="Cruzer Switch" >> >> iSerialNumber="123456789012" >> >> >> >> Unfortunately this doesn't seem to have made any difference and it is >> >> still rejected by the target devices. >> >> >> >> As far as I can tell the above parameters are getting passed through >> >> correctly >> >> $ ls /sys/module/g_mass_storage/parameters/* >> >> /sys/module/g_mass_storage/parameters/bcdDevice >> >> /sys/module/g_mass_storage/parameters/cdrom >> >> /sys/module/g_mass_storage/parameters/file >> >> /sys/module/g_mass_storage/parameters/idProduct >> >> /sys/module/g_mass_storage/parameters/idVendor >> >> /sys/module/g_mass_storage/parameters/iManufacturer >> >> /sys/module/g_mass_storage/parameters/iProduct >> >> /sys/module/g_mass_storage/parameters/iSerialNumber >> >> /sys/module/g_mass_storage/parameters/luns >> >> /sys/module/g_mass_storage/parameters/nofua >> >> /sys/module/g_mass_storage/parameters/removable >> >> /sys/module/g_mass_storage/parameters/ro >> >> /sys/module/g_mass_storage/parameters/stall >> >> >> >> $ cat /sys/module/g_mass_storage/parameters/* >> >> 282 >> >> /home/pi/piusb.bin >> >> 21874 >> >> 1921 >> >> SanDisk >> >> Cruzer_Switch >> >> 123456789012 >> >> 0 >> >> Y >> >> N >> >> >> >> However when connecting to Windows, here's what the USB mass storage >> >> displays - it appears that the iSerialNumber is making it through, but >> >> nothing else is being altered. My router shows similar issues, >> >> identifying it as "File-Stor Gadget (Rev: 0404)" >> >> >> >> USBSTOR\DISK&VEN_LINUX&PROD_FILE-STOR_GADGET&REV_0404\123456789012&0 > > It looks like Windows is remembering an earlier version of your gadget > and matching it with the current version based on the serial number > string. I've changed the SN and still getting it showing as 'File-Stor Gadget' on Linux, Windows, router >> >> USBSTOR\DiskLinux___File-Stor_Gadget0404 >> >> USBSTOR\DiskLinux___File-Stor_Gadget >> >> USBSTOR\DiskLinux___ >> >> USBSTOR\Linux___File-Stor_Gadget0 >> >> Linux___File-Stor_Gadget0 >> >> USBSTOR\GenDisk >> >> GenDisk >> >> >> >> By comparison, here's what SanDisk shows: >> >> >> >> USBSTOR\DISK&VEN_SANDISK&PROD_CRUZER_SWITCH&REV_1.26\4C532015741508522393&0 >> >> USBSTOR\DiskSanDisk_Cruzer_Switch___1.26 >> >> USBSTOR\DiskSanDisk_Cruzer_Switch___ >> >> USBSTOR\DiskSanDisk_ >> >> USBSTOR\SanDisk_Cruzer_Switch___1 >> >> SanDisk_Cruzer_Switch___1 >> >> USBSTOR\GenDisk >> >> GenDisk >> > >> > Never mind Windows -- if you connect your gadget to a computer running >> > Linux, what does "lsusb -v" show? >> > >> > Alan Stern >> > >> Thanks for the reply, Alan. >> >> Can provide the full output if it would help, but relevant part seems >> to be the below: >> >> Bus 001 Device 004: ID 0781:5572 SanDisk Corp. >> Device Descriptor: >> bLength18 >> bDescriptorType 1 >> bcdUSB 2.00 >> bDeviceClass0 (Defined at Interface level) >> bDeviceSubClass 0 >> bDeviceProtocol 0 >> bMaxPacketSize064 >> idVendor 0x0781 SanDisk C
Re: [PATCH v14 4/7] usb: core: add power sequence handling for USB devices
On Mon, Jun 05, 2017 at 10:16:34AM -0400, Alan Stern wrote: > On Mon, 5 Jun 2017, Peter Chen wrote: > > > On Thu, May 18, 2017 at 08:49:00AM +0800, Peter Chen wrote: > > > Some hard-wired USB devices need to do power sequence to let the > > > device work normally, the typical power sequence like: enable USB > > > PHY clock, toggle reset pin, etc. But current Linux USB driver > > > lacks of such code to do it, it may cause some hard-wired USB devices > > > works abnormal or can't be recognized by controller at all. > > > > > > In this patch, it calls power sequence library APIs to finish > > > the power sequence events. It will do power on sequence at hub's > > > probe for all devices under this hub (includes root hub). > > > At hub_disconnect, it will do power off sequence which is at powered > > > on list. > > > > > > > Greg, Alan, would you please help on reviewing it? It seems Rafael > > is waiting for USB MAINTAINERS's comments or ack. It resolves some > > USB HUB issues for several persons. > > > > Peter > > > > > Signed-off-by: Peter Chen > > > Tested-by Joshua Clayton > > > Tested-by: Maciej S. Szmigiero > > > Reviewed-by: Vaibhav Hiremath > > Acked-by: Alan Stern > > > > --- > > > drivers/usb/Kconfig| 1 + > > > drivers/usb/core/hub.c | 49 > > > + > > > drivers/usb/core/hub.h | 1 + > > > 3 files changed, 47 insertions(+), 4 deletions(-) > > > > > > diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig > > > index 939a63b..b6f626e 100644 > > > --- a/drivers/usb/Kconfig > > > +++ b/drivers/usb/Kconfig > > > @@ -39,6 +39,7 @@ config USB > > > tristate "Support for Host-side USB" > > > depends on USB_ARCH_HAS_HCD > > > select USB_COMMON > > > + select POWER_SEQUENCE > > > select NLS # for UTF-8 strings > > > ---help--- > > > Universal Serial Bus (USB) is a specification for a serial bus > > > diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c > > > index 9dca59e..7a67296 100644 > > > --- a/drivers/usb/core/hub.c > > > +++ b/drivers/usb/core/hub.c > > > @@ -28,6 +28,7 @@ > > > #include > > > #include > > > #include > > > +#include > > > > > > #include > > > #include > > > @@ -1619,6 +1620,7 @@ static void hub_disconnect(struct usb_interface > > > *intf) > > > hub->error = 0; > > > hub_quiesce(hub, HUB_DISCONNECT); > > > > > > + of_pwrseq_off_list(&hub->pwrseq_on_list); > > Things like this look a little peculiar -- you are passing an "on_list" > to a function named "...off_list". > > How about naming the new field hub->pwrseq_list instead? > Thanks, Alan. I will change it at next revision. -- Best Regards, Peter Chen -- 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 http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: dwc2: add support for the DWC2 controller on Meson8 SoCs
On 5/25/2017 10:39 AM, Martin Blumenstingl wrote: > Hi John, > > On Sat, May 6, 2017 at 7:37 PM, Martin Blumenstingl > wrote: >> USB support in the Meson8 SoCs is provided by a DWC2 controller which >> works with the same settings as Meson8b and GXBB. Using the generic >> "snps,dwc2" binding results in an endless stream of "Overcurrent change >> detected" messages. >> >> Signed-off-by: Martin Blumenstingl > do you want me to re-send this with Rob's ACK? > also please let me know if something is still missing in this patch > >> --- >> Documentation/devicetree/bindings/usb/dwc2.txt | 1 + >> drivers/usb/dwc2/params.c | 2 ++ >> 2 files changed, 3 insertions(+) >> >> diff --git a/Documentation/devicetree/bindings/usb/dwc2.txt >> b/Documentation/devicetree/bindings/usb/dwc2.txt >> index 6c7c2bce6d0c..b55be381ae85 100644 >> --- a/Documentation/devicetree/bindings/usb/dwc2.txt >> +++ b/Documentation/devicetree/bindings/usb/dwc2.txt >> @@ -10,6 +10,7 @@ Required properties: >>- "rockchip,rk3288-usb", "rockchip,rk3066-usb", "snps,dwc2": for rk3288 >> Soc; >>- "lantiq,arx100-usb": The DWC2 USB controller instance in Lantiq ARX >> SoCs; >>- "lantiq,xrx200-usb": The DWC2 USB controller instance in Lantiq XRX >> SoCs; >> + - "amlogic,meson8-usb": The DWC2 USB controller instance in Amlogic >> Meson8 SoCs; >>- "amlogic,meson8b-usb": The DWC2 USB controller instance in Amlogic >> Meson8b SoCs; >>- "amlogic,meson-gxbb-usb": The DWC2 USB controller instance in Amlogic >> S905 SoCs; >>- "amcc,dwc-otg": The DWC2 USB controller instance in AMCC Canyonlands >> 460EX SoCs; >> diff --git a/drivers/usb/dwc2/params.c b/drivers/usb/dwc2/params.c >> index 2990c347289f..0d6290ed66ea 100644 >> --- a/drivers/usb/dwc2/params.c >> +++ b/drivers/usb/dwc2/params.c >> @@ -128,6 +128,8 @@ const struct of_device_id dwc2_of_match_table[] = { >> { .compatible = "lantiq,xrx200-usb", .data = dwc2_set_ltq_params }, >> { .compatible = "snps,dwc2" }, >> { .compatible = "samsung,s3c6400-hsotg" }, >> + { .compatible = "amlogic,meson8-usb", >> + .data = dwc2_set_amlogic_params }, >> { .compatible = "amlogic,meson8b-usb", >> .data = dwc2_set_amlogic_params }, >> { .compatible = "amlogic,meson-gxbb-usb", >> -- >> 2.12.2 >> > Adding Felipe Acked-by: John Youn John -- 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 http://vger.kernel.org/majordomo-info.html
Re: [RFC] usb-phy-generic: Add support to SMSC USB3315
On Mon, Jun 05, 2017 at 11:52:26AM +0200, Fabien Lahoudere wrote: > On Mon, 2017-06-05 at 17:43 +0800, Peter Chen wrote: > > On Mon, Jun 05, 2017 at 10:57:00AM +0200, Fabien Lahoudere wrote: > > > On Fri, 2017-06-02 at 15:00 -0700, Stephen Boyd wrote: > > > > On 05/26, Fabien Lahoudere wrote: > > > > > Hello > > > > > > > > > > I modify ci_hrdc_imx_probe to bypass "data->phy = > > > > > devm_usb_get_phy_by_phandle(&pdev->dev, > > > > > "fsl,usbphy", 0);". Everything works as expected and call > > > > > ci_ulpi_init. > > > > > > > > > > The problem is that in ci_ulpi_init, before calling "ci->ulpi = > > > > > ulpi_register_interface(ci- > > > > > >dev, > > > > > &ci->ulpi_ops);" (to initialize our phy), "hw_phymode_configure(ci);" > > > > > is called which is the > > > > > original function that make our system to hang. > > > > > > > > > > Our phy is not initialised before calling ulpi_register_interface so > > > > > I don't understand how > > > > > the > > > > > phy > > > > > can reply if it is not out of reset state. > > > > > > > > I haven't see any problem in hw_phymode_configure(). What's the > > > > value of ci->platdata->phy_mode? USBPHY_INTERFACE_MODE_ULPI? If > > > > you phy needs to be taken out of reset to reply to the ulpi reads > > > > of the vendor/product ids, then it sounds like you have a similar > > > > situation to what I had. I needed to turn on some regulators to > > > > get those reads to work, otherwise they would fail, but knowing > > > > what needed to be turned on basically meant I needed to probe the > > > > ulpi driver so probing the ids wasn't going to be useful. So on > > > > my device the reads for the ids go through, but they get all > > > > zeroes back, which is actually ok because there aren't any bits > > > > set on my devices anyway. After the reads see 0, we fallback to > > > > DT matching, which avoids the "bring it out of reset/power it on" > > > > sorts of problems entirely. > > > > > > > > > > Yes the phy mode is configured to USBPHY_INTERFACE_MODE_ULPI. > > > Indeed, this phy need to be out of reset to work. For example everything > > > works fine if I call > > > "_ci_usb_phy_init(ci);" before calling "hw_phymode_configure(ci);" > > > This function only init reset GPIO and clock. > > > > > > For information, the original patch I have to fix the issue: > > > > > > diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c > > > index 79ad8e9..21aaff1 100644 > > > --- a/drivers/usb/chipidea/core.c > > > +++ b/drivers/usb/chipidea/core.c > > > @@ -391,6 +391,7 @@ static int ci_usb_phy_init(struct ci_hdrc *ci) > > > case USBPHY_INTERFACE_MODE_UTMI: > > > case USBPHY_INTERFACE_MODE_UTMIW: > > > case USBPHY_INTERFACE_MODE_HSIC: > > > + case USBPHY_INTERFACE_MODE_ULPI: > > > ret = _ci_usb_phy_init(ci); > > > if (!ret) > > > hw_wait_phy_stable(); > > > @@ -398,7 +399,6 @@ static int ci_usb_phy_init(struct ci_hdrc *ci) > > > return ret; > > > hw_phymode_configure(ci); > > > break; > > > - case USBPHY_INTERFACE_MODE_ULPI: > > > case USBPHY_INTERFACE_MODE_SERIAL: > > > hw_phymode_configure(ci); > > > ret = _ci_usb_phy_init(ci); > > > -- > > > > Currently, the hw_phymode_configure is called twice for ULPI PHY, the > > two execution are between _ci_usb_phy_init, would you test which one > > causes hang? If the second causes hang, you can make a patch for > > hw_phymode_configure that if the required PORTSC_PTS is the same > > the value in register, do noop. > > The first one hangs, _ci_usb_phy_init is not called due to hang. > So, you need to comment out hw_phymode_configure at ci_ulpi_init, and you can't get vid/pid correctly, right? If it is, we may need to add power on sequence at chipidea core driver (ci_hdrc_probe) for clock and reset things. http://www.spinics.net/lists/linux-usb/msg157134.html I am wondering if we can call ci_usb_phy_init before calling ci_ulpi_init, since we need to let hardware be ready before reading vid/pid. Stephen & Fabien, does that work for you? -- Best Regards, Peter Chen -- 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 http://vger.kernel.org/majordomo-info.html
Re: [v2 1/1] usb:host:xhci support option to disable xHCI 1.0 USB2 HW LPM
On Mon, Jun 5, 2017 at 9:33 PM, Mathias Nyman wrote: > On 05.06.2017 15:57, Thang Q. Nguyen wrote: >> >> On Mon, Jun 5, 2017 at 6:14 PM, Mathias Nyman >> wrote: >>> >>> On 20.05.2017 10:24, Thang Q. Nguyen wrote: XHCI specification 1.1 does not require xHCI 1.0 compliant controllers to always enable hardware USB2 LPM. However, the current xHCI driver always enable it by setting HLE=1 when seeing HLC=1. This makes certain xHCI controllers that have broken USB2 HW LPM fail to work as there is no way to disable this feature. This patch adds support to control disabling USB2 Hardware LPM via DT/ACPI attribute. >>> >>> Wouldn't it be better to just keep xhci->hw_lpm_support = 0 if the >>> host >>> doesn't support Hardware LPM Capability, (HLC)? >>> >>> This should prevent all those extra steps getting here just to do >>> nothing. >> >> No, HLC = 0 means the host doesn't support Hardware LPM. >> The problem here is the host support Hardware LPM but there is a bug >> in host controller that make the LPM fail to work. >> > > So the host support hw LPM, and has its HLC capability bit set, > but in the end it just doesn't work at all, and should be prevented. > >> When debugging the host controller, we detect there are some holes in >> the current usb specifications which can can result in inter-operating >> problems between USB Host Controller and USB PHY. To be more specific, >> the specs have not clarified the resume recovery timing after the port >> has just waken up from L1. This can lead to different interpretations >> of the specs by Host Controller and PHY. What happened in our case is >> that a Host controller cannot work with a PHY right after resuming >> from L1 because these two Vendors have different views of the specs >> regarding LPM timing after L1. These views are contradictory and >> cannot work together. >> >> If Host Controller and PHY are from the same vendor, they might have >> some "internal handshake mechanisms" to avoid these holes of the USB >> specs. However, these mechanisms are not standardized in USB specs; >> and not all vendors follow these mechanisms. In fact, we have observed >> this kind of "internal handshake mechanism" in HOST Controller and PHY >> from SYNOPSYS DWC. So, we can say that if users use Host Controller >> and PHY from different Vendors, the inteopering problems after waking >> up from L1 are more likely to occur. > > > Can you explain the reason why you prefer preventing hw lpm inside the > xhci_set_usb2_hardware_lpm() function instead of preventing hw lpm usage > all together for this platform -i.e. by not setting xhci->hw_lpm_support The reason I don't change in the xhci_add_in_port() function inside xhci-mem.c is because of the description for xhci->hw_lpm_support in the drivers/usb/host/xhci.h header file: support xHCI 1.0 spec USB2 hardware LPM. Per my understanding, this attribute is used to indicate if the host supports HW LPM and this can be checked via HLC. My intension is to support an option for user to disable the HW LPM because of some reasons (in my case because HW LPM is broken). > > > Again, something like: > if (temp & XHCI_HLC && !(xhci->quirks & XHCI_HW_LPM_BROKEN)) > xhci->hw_lpm_support = 1; This should work too. But the DT/ACPI attribute should change to "usb2-lpm-broken". > >>> The HW LPM can also be disabled (per device) in sysfs if needed. >> >> This does not work. When the issue happens, the USB device is fail to >> probe so no /sys interface created. Messages displayed when issue >> happen is similar to: >> >> [ 2846.677903] usb 1-1: reset high-speed USB device number 2 using >> xhci-hcd >> [ 2882.037125] usb usb1-port1: Cannot enable. Maybe the USB cable is bad? >> or >> usb usb3-port1: disabled by hub (EMI?), re-enabling... >> [ 57.840237] usb 3-1: USB disconnect, device number 5 > > > Ok, the sysfs entry is not useful in this case. > > -Mathias > > -- 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 http://vger.kernel.org/majordomo-info.html