Re: JMicron based usb 3.0 to sata enclosure, hangs, numerous errors

That is very strange My device has same vid:pid of your one, but it goes blacklisted... I am running kernel 4.15.1, I will try to upgrade What kind of enclosure is yours? Mine is an Orico 9553RU3 5 bay enclosure with RAID Bye 2018-02-13 23:41 GMT+01:00 Chris Murphy : > On

Re: [PATCH v2] usb: phy: mxs: Fix NULL pointer dereference on i.MX23/28

Hi Felipe, On Mon, Jan 22, 2018 at 10:28 AM, Fabio Estevam wrote: > Hi Felipe, > > On Thu, Jan 18, 2018 at 12:22 AM, Fabio Estevam wrote: >> From: Fabio Estevam >> >> Commit e93650994a95 ("usb: phy: mxs: add usb charger type

Re: JMicron based usb 3.0 to sata enclosure, hangs, numerous errors

On Mon, Feb 12, 2018 at 12:57 AM, Menion wrote: > > I wanted to test my enclosure with an hub, but I have just realized > that now the JMS567 is UAS blacklisted by default in kernel > 4.15.x. > Can you check if it still works removing the dedicated hub external > power

Fwd: Re: Bug 198731 "USB devices not seen with newest kernel"

On 02/13/2018 12:46 AM, Greg KH wrote: On Mon, Feb 12, 2018 at 10:16:56AM -0800, The Real Bev wrote: On 02/11/2018 09:50 PM, Greg KH wrote: > On Fri, Feb 09, 2018 at 12:25:44PM -0800, The Real Bev wrote: > > On 02/09/2018 05:13 AM, Greg KH wrote: > > > On Thu, Feb 08, 2018 at 01:00:02PM -0800,

Re: [BUG] SD card reader disappears after suspend

On 12.02.2018 16:03, Mathias Nyman wrote: On 10.02.2018 02:01, Samuel Sadok wrote: Thanks Mathias for looking into this. 2018-02-06 18:32 GMT+01:00 Mathias Nyman : Does reverting 37be6676 usb: hub: Fix auto-remount of safely removed or ejected USB-3 devices

Re: [PATCH 3.18 0/9] Backports for security and critical bug fixes

On Wed, Feb 07, 2018 at 02:20:23PM -0700, Shuah Khan wrote: > As I started backporting security fixes, found a few problems > that prevent tools to build on newer gcc releases, deadlock bug, > and another bug that prevents client from being able to use > imported devices. > > This patch series

Re: [PATCH v6 4/4] soc/tegra: pmc: Use the new reset APIs to manage reset controllers

On 19/06/17 15:34, Philipp Zabel wrote: > From: Vivek Gautam > > Make use of of_reset_control_array_get_exclusive() to manage > an array of reset controllers available with the device. > > Cc: Jon Hunter > Cc: Thierry Reding

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

Am Montag, den 12.02.2018, 12:15 -0800 schrieb sathyanarayan.kuppusw...@linux.intel.com: > From: Dominik Bozek > > ACM driver may accept data to transmit while system is not fully > resumed. In this case ACM driver buffers data and prepare URBs > on usb anchor list. >

RE: [PATCH 2/6] xhci: Don't print a warning when setting link state for disabled ports

Hi, > From: Mathias Nyman, Sent: Monday, February 12, 2018 9:25 PM > > When disabling a USB3 port the hub driver will set the port link state to > U3 to prevent "ejected" or "safely removed" devices that are still > physically connected from immediately re-enumerating. > > If the device was

[PATCH] usb: host: xhci-plat: revert "usb: host: xhci-plat: enable clk in resume timing"

This patch reverts the commit 835e4241e714 ("usb: host: xhci-plat: enable clk in resume timing") because this driver also has runtime PM and the commit 560869100b99 ("clk: renesas: cpg-mssr: Restore module clocks during resume") will restore the clock on R-Car H3 environment. If the

RE: UAC2 gadget not recognized on Windows 10

> Enabling SOF interrupts will be a big pain :-) Well, enabling the > interrupt itself is a no-brainer, but it'll cause terrible CPU overload. Oh, I see. Hmm... would it be possible to allow upper levels to config this dynamically ? I.e. for the ALSA subsystem there is no need for the SOF

RE: UAC2 gadget not recognized on Windows 10

Hi, Robert Bielik writes: >> >> I guess UAC1 doesn't need feedback endpoints, right? Seems like that >> >> should be something specific to UAC2. At least for now. >> > >> > It seems like it is needed there aswell, see >> >

RE: UAC2 gadget not recognized on Windows 10

> >> I guess UAC1 doesn't need feedback endpoints, right? Seems like that > >> should be something specific to UAC2. At least for now. > > > > It seems like it is needed there aswell, see > > http://www.usb.org/developers/docs/devclass_docs/audio10.pdf (3.7.2.2) > > (Feedback endpoint == Synch

RE: UAC2 gadget not recognized on Windows 10

Hi, Robert Bielik writes: >> I guess UAC1 doesn't need feedback endpoints, right? Seems like that >> should be something specific to UAC2. At least for now. > > It seems like it is needed there aswell, see > http://www.usb.org/developers/docs/devclass_docs/audio10.pdf

RE: UAC2 gadget not recognized on Windows 10

> I guess UAC1 doesn't need feedback endpoints, right? Seems like that > should be something specific to UAC2. At least for now. It seems like it is needed there aswell, see http://www.usb.org/developers/docs/devclass_docs/audio10.pdf (3.7.2.2) (Feedback endpoint == Synch Endpoint) Regards /R

Re: Bug 198731 "USB devices not seen with newest kernel"

On Mon, Feb 12, 2018 at 10:16:56AM -0800, The Real Bev wrote: > On 02/11/2018 09:50 PM, Greg KH wrote: > > On Fri, Feb 09, 2018 at 12:25:44PM -0800, The Real Bev wrote: > > > On 02/09/2018 05:13 AM, Greg KH wrote: > > > > On Thu, Feb 08, 2018 at 01:00:02PM -0800, The Real Bev wrote: > > > > > I

[PATCH] usb: dwc2: add support for host mode external vbus supply

This patch adds a way to enable an external vbus supply in host mode, when dwc2 drvvbus signal is not used. This patch is very similar to the one done in U-Boot dwc2 driver [1]. It also adds dynamic vbus supply management depending on the role and state of the core. [1]

RE: UAC2 gadget not recognized on Windows 10

Hi, Robert Bielik writes: >> >> Indeed, that's also mandated by USB spec. Seems like we need to patch >> >> f_uac2.c. Can you check if setting the IN endpoint as implicit feedback >> >> data is enough? >> > >> > Just tried your proposed patches on 4.15.1 (with an RPi

RE: UAC2 gadget not recognized on Windows 10

> >> Indeed, that's also mandated by USB spec. Seems like we need to patch > >> f_uac2.c. Can you check if setting the IN endpoint as implicit feedback > >> data is enough? > > > > Just tried your proposed patches on 4.15.1 (with an RPi Zero) and with > > g_audio, unfortunately there is no change.