Re: [patch -target tree] usb: gadget: f_tcm: use after free

Hi Felipe + usb-gadget folks, On Wed, 2016-03-02 at 13:55 +0200, Felipe Balbi wrote: > Dan Carpenter writes: > > We need to move the kfree() down a line so we don't dereference a freed > > variable. > > > > Fixes: 1b418a8fcbc0 ('target: Convert demo-mode only drivers to

Re: [patch -target tree] usb: gadget: f_tcm: use after free

On Wed, 2016-03-02 at 13:08 +0300, Dan Carpenter wrote: > We need to move the kfree() down a line so we don't dereference a freed > variable. > > Fixes: 1b418a8fcbc0 ('target: Convert demo-mode only drivers to > target_alloc_session') > Signed-off-by: Dan Carpenter >

Re: [PATCH v10 1/9] dt-bindings: phy: Add NVIDIA Tegra XUSB pad controller binding

On Fri, Mar 04, 2016 at 05:19:31PM +0100, Thierry Reding wrote: > From: Thierry Reding > > The NVIDIA Tegra XUSB pad controller provides a set of pads, each with a > set of lanes that are used for PCIe, SATA and USB. > > Signed-off-by: Thierry Reding >

Re: [PATCH v10 2/9] dt-bindings: pinctrl: Deprecate Tegra XUSB pad controller binding

On Fri, Mar 04, 2016 at 05:19:32PM +0100, Thierry Reding wrote: > From: Thierry Reding > > This is an old version of the binding that isn't flexible enough to > describe all aspects of the XUSB pad controller. Specifically with the > addition of XUSB support (for SuperSpeed

Re: [PATCH v10 3/9] dt-bindings: phy: tegra-xusb-padctl: Add Tegra210 support

On Fri, Mar 04, 2016 at 05:19:33PM +0100, Thierry Reding wrote: > From: Thierry Reding > > Extend the binding to cover the set of feature found in Tegra210. > > Signed-off-by: Thierry Reding > --- > .../bindings/phy/nvidia,tegra124-xusb-padctl.txt |

Re: [PATCH 1/3] usb: core: add power sequence for USB devices

On Fri, Mar 04, 2016 at 10:37:50AM +0800, Peter Chen wrote: > On Fri, Mar 04, 2016 at 03:23:05AM +0100, Andrew Lunn wrote: > > On Fri, Mar 04, 2016 at 10:02:42AM +0800, Peter Chen wrote: > > > On Thu, Mar 03, 2016 at 02:54:55PM -0600, Rob Herring wrote: > > > > On Thu, Mar 3, 2016 at 4:01 AM,

Re: [GIT PULL] USB changes for v4.6

On Fri, Mar 04, 2016 at 03:19:11PM +0200, Felipe Balbi wrote: > > Hi Greg, > > here's the gadget pull request for v4.6. This time I had to based it on > top of your greg/usb-next to avoid duplicated commits for the USB 3.1 > work which some dwc3 changes depended on. Another benefit of the rebase

Re: Odd merge 3b30be3b6487 ("Merge tag 'v4.5-rc6' into next")

>> >> Felipe recently rebased his next branch without the merge commit >> referenced above. So maybe that's causing some issues. >> >> But everything seems ok to me. I see the commit and correct code on >> 4.5-rc6, Felipe's next branch, and Greg's usb-next. >

Re: [RFT PATCH 1/2] usb: dwc2: Add a 10 ms delay to dwc2_core_reset()

On 3/4/2016 10:23 AM, Douglas Anderson wrote: > From testing and trying to make sense of the documentation, it appears > that a 10 ms delay is needed after resetting the core to make sure that > everything is stable and consistent. Let's add it. > > In my testing (on rk3288) this allows us to

Re: Odd merge 3b30be3b6487 ("Merge tag 'v4.5-rc6' into next")

; I think I'm about at the limit of my git-fu, so I'm a bit baffled. >> Any idea what happened? Was anything else lost? >> > > > Felipe recently rebased his next branch without the merge commit > referenced above. So maybe that's causing some issues. > > But everyt

Re: Odd merge 3b30be3b6487 ("Merge tag 'v4.5-rc6' into next")

On 3/4/2016 5:04 PM, Doug Anderson wrote: > Felipe, > > Michael pointed out that there's an odd merge that happened. > Specifically it looks like commit bd84f4ae9986 ("usb: dwc2: Add extra > delay when forcing dr_mode") got lost somehow in the merge commit > 3b30be3b6487 ("Merge tag 'v4.5-rc6'

Re: [RFT PATCH 1/2] usb: dwc2: Add a 10 ms delay to dwc2_core_reset()

Hi, On Fri, Mar 4, 2016 at 4:33 PM, Doug Anderson wrote: > Michael, > > On Fri, Mar 4, 2016 at 4:09 PM, Michael Niewoehner > wrote: From testing and trying to make sense of the documentation, it appears that a 10 ms delay is needed after

Odd merge 3b30be3b6487 ("Merge tag 'v4.5-rc6' into next")

Felipe, Michael pointed out that there's an odd merge that happened. Specifically it looks like commit bd84f4ae9986 ("usb: dwc2: Add extra delay when forcing dr_mode") got lost somehow in the merge commit 3b30be3b6487 ("Merge tag 'v4.5-rc6' into next") Specifically: $ git blame 3b30be3b6487 --

Re: [RFT PATCH 1/2] usb: dwc2: Add a 10 ms delay to dwc2_core_reset()

Hi, On Fri, Mar 4, 2016 at 3:46 PM, Karl Palsson wrote: >> + /* >> + * Sleep for 10-15 ms after the reset to let it finish. >> + * >> + * It's been confirmed on at least one version of the controller >> + * that this is a requirement that this is a

Re: [RFT PATCH 1/2] usb: dwc2: Add a 10 ms delay to dwc2_core_reset()

Michael, On Fri, Mar 4, 2016 at 4:09 PM, Michael Niewoehner wrote: >>> From testing and trying to make sense of the documentation, it appears >>> that a 10 ms delay is needed after resetting the core to make sure that >>> everything is stable and consistent. Let's add it.

Re: [RFT PATCH 1/2] usb: dwc2: Add a 10 ms delay to dwc2_core_reset()

Hi Douglas, Am 04.03.2016 um 23:54 schrieb Michael Niewoehner : > Hi Douglas, > > Am 04.03.2016 um 19:23 schrieb Douglas Anderson : > >> From testing and trying to make sense of the documentation, it appears >> that a 10 ms delay is needed after

Re: [RFT PATCH 1/2] usb: dwc2: Add a 10 ms delay to dwc2_core_reset()

Hello. On 03/04/2016 09:23 PM, Douglas Anderson wrote: From testing and trying to make sense of the documentation, it appears that a 10 ms delay is needed after resetting the core to make sure that everything is stable and consistent. Let's add it. In my testing (on rk3288) this allows us

Re: [RFT PATCH 1/2] usb: dwc2: Add a 10 ms delay to dwc2_core_reset()

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Douglas Anderson wrote: > > + /* > + * Sleep for 10-15 ms after the reset to let it finish. > + * > + * It's been confirmed on at least one version of the controller > + * that this is a requirement

Re: Possible double-free in the usbnet driver

On Sat, Mar 5, 2016 at 2:00 AM, Andrey Konovalov wrote: > On Sat, Mar 5, 2016 at 1:42 AM, Oliver Neukum wrote: >> On Sat, 2016-03-05 at 01:26 +0300, Andrey Konovalov wrote: >>> and when I run the vm and connect the device I get: >>> >>> [ 23.672662]

Re: Possible double-free in the usbnet driver

On Sat, Mar 5, 2016 at 1:42 AM, Oliver Neukum wrote: > On Sat, 2016-03-05 at 01:26 +0300, Andrey Konovalov wrote: >> and when I run the vm and connect the device I get: >> >> [ 23.672662] cdc_ncm 1-1:1.6: bind() failure >> [ 23.673447] usbnet_probe(): freeing netdev:

Re: Possible double-free in the usbnet driver

On Sat, Mar 5, 2016 at 1:43 AM, Linus Torvalds wrote: > On Fri, Mar 4, 2016 at 2:26 PM, Andrey Konovalov wrote: >> >> and when I run the vm and connect the device I get: >> >> [ 23.672662] cdc_ncm 1-1:1.6: bind() failure >> [ 23.673447]

Re: [RFT PATCH 1/2] usb: dwc2: Add a 10 ms delay to dwc2_core_reset()

Hi Douglas, Am 04.03.2016 um 19:23 schrieb Douglas Anderson : > From testing and trying to make sense of the documentation, it appears > that a 10 ms delay is needed after resetting the core to make sure that > everything is stable and consistent. Let's add it. > > In my

Re: [RFT PATCH 2/2] Revert "usb: dwc2: Fix probe problem on bcm2835"

Am 04.03.2016 um 19:23 schrieb Douglas Anderson : > This reverts commit 192cb07f7928 ("usb: dwc2: Fix probe problem on > bcm2835") now that we've found the root cause. See the change > titled ("usb: dwc2: Add a 10 ms delay to dwc2_core_reset()"). > > Signed-off-by:

Re: Possible double-free in the usbnet driver

On Sat, 2016-03-05 at 01:26 +0300, Andrey Konovalov wrote: > and when I run the vm and connect the device I get: > > [ 23.672662] cdc_ncm 1-1:1.6: bind() failure > [ 23.673447] usbnet_probe(): freeing netdev: 88006ab48000 > [ 23.675822] usbnet_probe(): freeing netdev: 88006ab48000 >

Re: Possible double-free in the usbnet driver

On Fri, Mar 4, 2016 at 2:26 PM, Andrey Konovalov wrote: > > and when I run the vm and connect the device I get: > > [ 23.672662] cdc_ncm 1-1:1.6: bind() failure > [ 23.673447] usbnet_probe(): freeing netdev: 88006ab48000 > [ 23.675822] usbnet_probe(): freeing

Re: Possible double-free in the usbnet driver

On Sat, Mar 5, 2016 at 12:26 AM, Linus Torvalds wrote: > [ Moving this to proper lists ] > > On Thu, Mar 3, 2016 at 4:19 PM, Andrey Konovalov wrote: >> >> I found another double-free, this time in the usbnet driver. > > Hmm. It doesn't look

Re: Spurious Mass Storage Device Resets

On Fri, 4 Mar 2016, Rian Hunter wrote: > Thanks for the great tip. I used tcpdump on the bus of my device and > waited for a couple days for the effect to happen again. > > I found that whenever I would get the "usb 2-3: reset SuperSpeed USB > device number 2 using xhci_hcd" what was happening

Re: [PATCH v10 1/9] dt-bindings: phy: Add NVIDIA Tegra XUSB pad controller binding

> +Required properties: > + > +- compatible: Must be: > + - Tegra124: "nvidia,tegra124-xusb-padctl" > + - Tegra132: "nvidia,tegra132-xusb-padctl", "nvidia,tegra124-xusb-padctl" > +- reg: Physical base address and length of the controller's registers. > +- resets: Must contain

Re: Unable to enumerate USB Device, error -110 Kernel 3.19-0.49-lowlatency netboot

On Fri, 4 Mar 2016, Devon Ash wrote: > Failing that, can you at least provide a usbmon trace showing what > happens when you plug a device into one of the bad ports? > > usbmon trace: > > I'm unable to get anything from doing "cat 0u && cat 5u && cat 6u" > (which are all of the offending

Re: [PATCH v10 3/9] dt-bindings: phy: tegra-xusb-padctl: Add Tegra210 support

On Fri, Mar 4, 2016 at 8:19 AM, Thierry Reding wrote: > From: Thierry Reding > > Extend the binding to cover the set of feature found in Tegra210. > > Signed-off-by: Thierry Reding > +PCIe pad: > +- > + > +Required

Re: [PATCH v10 1/9] dt-bindings: phy: Add NVIDIA Tegra XUSB pad controller binding

Hi Thierry, On Fri, Mar 4, 2016 at 8:19 AM, Thierry Reding wrote: > From: Thierry Reding > > The NVIDIA Tegra XUSB pad controller provides a set of pads, each with a > set of lanes that are used for PCIe, SATA and USB. > > Signed-off-by: Thierry

Re: Possible double-free in the usbnet driver

[ Moving this to proper lists ] On Thu, Mar 3, 2016 at 4:19 PM, Andrey Konovalov wrote: > > I found another double-free, this time in the usbnet driver. Hmm. It doesn't look like a double free to me, at least from the logs you attached. > Whenever the `bind()` function

[PATCH v7 1/5] leds: core: add generic support for RGB LED's

Add generic support for RGB LED's. Basic idea is to use enum led_brightness also for the hue and saturation color components.This allows to implement the color extension w/o changes to struct led_classdev. Select LEDS_RGB to enable building drivers using the RGB extension. Flag LED_SET_HUE_SAT

Re: [PATCH v5 4/4] leds: core: add support for RGB LED's

Am 04.03.2016 um 10:05 schrieb Jacek Anaszewski: > On 03/01/2016 10:36 PM, Heiner Kallweit wrote: >> Export a function to convert HSV color values to RGB. >> It's intended to be called by drivers for RGB LEDs. >> >> Signed-off-by: Heiner Kallweit >> --- >> v2: >> - move hsv

[PATCH v7 3/5] leds: core: add documentation for RGB extension

Document the RGB extension in Documentation/leds/leds-class.txt Signed-off-by: Heiner Kallweit --- v2: - introduced to patch series v3: - document extension in more detail v4: - Better explain why flag LED_SET_HUE_SAT is needed v5: - no changes v6: - no changes v7: - move

[PATCH v7 2/5] leds: core: add color LED sysfs extension

Extend brightness sysfs property handling to deal with monochrome and color mode as well. Signed-off-by: Heiner Kallweit --- v2: - split from patch 1 v3: - moved one change (led_is_off) to patch 1 v4: - changed printf format string to %#.6x v5: - no changes v6: - no changes

[PATCH v7 4/5] leds: core: document ABI change for RGB extension

Document the ABI change in Documentation/ABI/testing/sysfs-class-led. Signed-off-by: Heiner Kallweit --- v7: - separated from patch 3 --- Documentation/ABI/testing/sysfs-class-led | 11 +++ 1 file changed, 11 insertions(+) diff --git

[PATCH v7 5/5] leds: core: add support for RGB LED's

Export a function to convert HSV color values to RGB. It's intended to be called by drivers for RGB LEDs. Signed-off-by: Heiner Kallweit --- v2: - move hsv -> rgb conversion to separate file - remove flag LED_DEV_CAP_RGB v3: - call led_hsv_to_rgb only if LED_DEV_CAP_HSV is

Re: Unable to enumerate USB Device, error -110 Kernel 3.19-0.49-lowlatency netboot

On 03/04/2016 12:24 PM, Greg KH wrote: > On Fri, Mar 04, 2016 at 02:53:59PM -0500, Devon Ash wrote: >> Regarding Kernel 4.2.0-30-lowlatency, > > What is "lowlatency"? -lowlatency is Ubuntu's optional kernel config. A stock Ubuntu kernel is CONFIG_PREEMPT_VOLUNTARY=y && CONFIG_HZ=250 The

Re: Spurious Mass Storage Device Resets

On Tue, 1 Mar 2016, Alan Stern wrote: On Mon, 29 Feb 2016, Rian Hunter wrote: Hello, I own a JBOD SATA<->USB 3.0 bridge. All information about this device and my kernel version is below. My trouble is that every so often this device will undergo a virtual USB disconnect and then be

Re: Unable to enumerate USB Device, error -110 Kernel 3.19-0.49-lowlatency netboot

My deepest apologies.. I ran those commands on another computer (I'm ssh tunnelling)... here is the output of: sudo mount -t usbfs none /proc/bus/usb mount: mounting none on /proc/bus/usb failed: no such file or directory cat /proc/bus/usb/devices: no such file or directory sudo mount -t

Re: Unable to enumerate USB Device, error -110 Kernel 3.19-0.49-lowlatency netboot

On Fri, Mar 04, 2016 at 02:53:59PM -0500, Devon Ash wrote: > Regarding Kernel 4.2.0-30-lowlatency, What is "lowlatency"? Try 4.4.4 please, 4.2 is now old and obsolete :( And can you test this without any -rt patches, we have no idea how those interact with the USB subsystem, sorry. thanks,

Re: [PATCH 4/5] usb: gadget: f_midi: cleanups and typos fixes

Hi Michal, On March 4, 2016 7:17:31 PM GMT+00:00, Michal Nazarewicz wrote: >On Wed, Mar 02 2016, Felipe F. Tonello wrote: >> Signed-off-by: Felipe F. Tonello >> --- >> drivers/usb/gadget/function/f_midi.c | 77 >+++-

Re: Unable to enumerate USB Device, error -110 Kernel 3.19-0.49-lowlatency netboot

Regarding Kernel 4.2.0-30-lowlatency, system-udevd is now giving me the outputs on boot: seq 1106 '/devices/pci:00/:00:1a.0/usb5 killed (same for usb6) reason being ; a timeout Then I start to get usb 5-1: device not accepting address 5, error -110 usb usb5-port1; unable to enumerate

Re: Unable to enumerate USB Device, error -110 Kernel 3.19-0.49-lowlatency netboot

If they are completely unresponsive, why do you get the -110 errors? I would expect you wouldn't get anything at all. They become unresponsive after the -110 errors. Dmesg will show nothing after those errors come up during boot. Failing that, can you at least provide a usbmon trace showing

Re: [PATCH 4/5] usb: gadget: f_midi: cleanups and typos fixes

On Wed, Mar 02 2016, Felipe F. Tonello wrote: > Signed-off-by: Felipe F. Tonello > --- > drivers/usb/gadget/function/f_midi.c | 77 > +++- > 1 file changed, 40 insertions(+), 37 deletions(-) > > diff --git

Re: Unable to enumerate USB Device, error -110 Kernel 3.19-0.49-lowlatency netboot

On Fri, 4 Mar 2016, Devon Ash wrote: > I'm unable to use 8 of the 10 USB devices I have on a motherboard. Two > USB 3.0 ports work, and all of the devices, if plugged into a hub, can > be recognized and used if plugged through those 2 ports. However, the > other ports are completely unresponsive.

Re: [PATCH 2/5] usb: gadget: f_midi: added spinlock on transmit function

Hi Balbi, On March 4, 2016 7:20:10 AM GMT+00:00, Felipe Balbi wrote: > >Hi, > >"Felipe F. Tonello" writes: >> [ text/plain ] >> Since f_midi_transmit is called by both ALSA and USB frameworks, it >can >> potentially cause a race condition between both

Re: [PATCH 3/5] usb: gadget: gmidi: remove bus powered requirement on bmAttributes

Hi Balbi, On March 4, 2016 7:16:42 AM GMT+00:00, Felipe Balbi wrote: > >Hi, > >"Felipe F. Tonello" writes: >> [ text/plain ] >> This gadget uses a bmAttributes and MaxPower that requires the USB >bus to be >> powered from the host, which is not correct

Re: [PATCH 1/5] usb: gadget: f_midi: refactor state machine

Felipe Ferreri Tonello wrote: > On March 4, 2016 8:07:40 AM GMT+00:00, Clemens Ladisch > wrote: >> Felipe Ferreri Tonello wrote: >>> On 03/03/16 11:38, Clemens Ladisch wrote: But in what way was the old state machine not "proper"? >>> >>> Because it didn't reflect all

Re: [PATCH 0/5] MIDI USB Gadget improvements

Hi Balbi, On March 4, 2016 7:11:30 AM GMT+00:00, Felipe Balbi wrote: > >Hi, > >"Felipe F. Tonello" writes: >> [ text/plain ] >> Patches are pretty much self-described. >> >> Patch 1 is revised from comments. > >you really need to describe what you

Re: [PATCH 5/5] usb: gadget: f_midi: updated copyright

Hi Balbi, On March 4, 2016 7:13:05 AM GMT+00:00, Felipe Balbi wrote: >"Felipe F. Tonello" writes: >> [ text/plain ] >> Signed-off-by: Felipe F. Tonello > >no commit log == no commit Got it. > >> --- >>

Re: [PATCH 1/5] usb: gadget: f_midi: refactor state machine

Hi Clemens, On March 4, 2016 8:07:40 AM GMT+00:00, Clemens Ladisch wrote: >Felipe Ferreri Tonello wrote: >> On 03/03/16 11:38, Clemens Ladisch wrote: >>> But in what way was the old state machine not "proper"? >> >> Because it didn't reflect all the correct and possible

Re: [PATCH 4/6] usb: make xhci platform driver use 64 bit or 32 bit DMA

On Fri, Oct 9, 2015 at 5:30 AM, Mathias Nyman wrote: > The xhci platform driver needs to work on systems that > either only support 64-bit DMA or only support 32-bit DMA. > Attempt to set a coherent dma mask for 64-bit DMA, and > attempt again with 32-bit DMA if

Unable to enumerate USB Device, error -110 Kernel 3.19-0.49-lowlatency netboot

I'm unable to use 8 of the 10 USB devices I have on a motherboard. Two USB 3.0 ports work, and all of the devices, if plugged into a hub, can be recognized and used if plugged through those 2 ports. However, the other ports are completely unresponsive. Thoughts/Ideas? The broken drivers are

[RFT PATCH 2/2] Revert "usb: dwc2: Fix probe problem on bcm2835"

This reverts commit 192cb07f7928 ("usb: dwc2: Fix probe problem on bcm2835") now that we've found the root cause. See the change titled ("usb: dwc2: Add a 10 ms delay to dwc2_core_reset()"). Signed-off-by: Douglas Anderson --- drivers/usb/dwc2/core.c | 6 ++ 1 file

Re: [PATCH 2/6] usb: xhci-mtk: use __maybe_unused to hide pm functions

On 02/03/16 16:24, Arnd Bergmann wrote: The mediatek XHCI glue driver uses SET_SYSTEM_SLEEP_PM_OPS() to conditionally set the correct suspend/resume options, and also puts both the dev_pm_ops and the functions inside of an #ifdef testing for CONFIG_PM_SLEEP, but those functions then call other

[PATCH v10 2/9] dt-bindings: pinctrl: Deprecate Tegra XUSB pad controller binding

From: Thierry Reding This is an old version of the binding that isn't flexible enough to describe all aspects of the XUSB pad controller. Specifically with the addition of XUSB support (for SuperSpeed USB) the existing binding is no longer suitable. Signed-off-by: Thierry

[PATCH v10 1/9] dt-bindings: phy: Add NVIDIA Tegra XUSB pad controller binding

From: Thierry Reding The NVIDIA Tegra XUSB pad controller provides a set of pads, each with a set of lanes that are used for PCIe, SATA and USB. Signed-off-by: Thierry Reding --- Changes in v10: - clarify that the hardware documentation means something

[PATCH v10 3/9] dt-bindings: phy: tegra-xusb-padctl: Add Tegra210 support

From: Thierry Reding Extend the binding to cover the set of feature found in Tegra210. Signed-off-by: Thierry Reding --- .../bindings/phy/nvidia,tegra124-xusb-padctl.txt | 327 + 1 file changed, 327 insertions(+) diff --git

[PATCH v10 6/9] dt-bindings: usb: Add NVIDIA Tegra XUSB controller binding

From: Thierry Reding Add device-tree binding documentation for the XUSB controller present on Tegra124 and later SoCs. This controller supports USB 3.0 via an xHCI compliant interface. Based on work by Andrew Bresticker . Cc: Rob Herring

[PATCH v10 4/9] phy: Add Tegra XUSB pad controller support

From: Thierry Reding Add a new driver for the XUSB pad controller found on NVIDIA Tegra SoCs. This hardware block used to be exposed as a pin controller, but it turns out that this isn't a good fit. The new driver and DT binding much more accurately describe the hardware and

[PATCH v10 8/9] usb: xhci: Add NVIDIA Tegra XUSB controller driver

From: Thierry Reding Add support for the on-chip XUSB controller present on Tegra SoCs. This controller, when loaded with external firmware, exposes an interface compliant with xHCI. This driver loads the firmware, starts the controller, and is able to service host-specific

[PATCH v10 9/9] usb: xhci: tegra: Add Tegra210 support

From: Thierry Reding Parameterize more parts of the driver and add support for Tegra210. Cc: Greg Kroah-Hartman Cc: Mathias Nyman Signed-off-by: Thierry Reding --- drivers/usb/host/xhci-tegra.c | 59

[PATCH v10 7/9] dt-bindings: usb: xhci-tegra: Add Tegra210 XUSB controller support

From: Thierry Reding Extend the Tegra XUSB controller device tree binding with Tegra210 support. Signed-off-by: Thierry Reding --- .../devicetree/bindings/usb/nvidia,tegra124-xusb.txt | 12 1 file changed, 12 insertions(+) diff

[PATCH v10 5/9] phy: tegra: Add Tegra210 support

From: Thierry Reding Add support for the XUSB pad controller found on Tegra210 SoCs. The hardware is roughly the same, but some of the registers have been moved around and the number and type of supported pads has changed. Signed-off-by: Thierry Reding

Re: [PATCH] usbhid: Fix lockdep unannotated irqs-off warning

On Wed, 2 Mar 2016, Sedat Dilek wrote: > On 3/1/16, Alan Stern wrote: > > On Tue, 1 Mar 2016, Sedat Dilek wrote: > > > >> On Tue, Oct 13, 2015 at 2:57 AM, Steven Rostedt > >> wrote: > >> > On Sat, 3 Oct 2015 12:05:42 +0200 > >> > Sedat Dilek

Re: [PATCH] usb:super speed warm reset rejudge

On Fri, 4 Mar 2016, l00229106 wrote: > Some super speed device, insert the u3 port, sometimes link is in the > Compliance Mode State(0x340), and then satisfy hub_port_warm_reset_required > conditions, the software will perform a warm reset, u3 PORTSC becomes > 0x2a1203. In hub_port_reset

Re: some questions about PM enable with usb driver

On Fri, 4 Mar 2016, yoma sophian wrote: > hi Alan and Peter: > >> > >> Backtrace: > >> [] (ehci_handle_start_intr_unlinks [ehci_hcd]) from > >> [] (ehci_bus_suspend+0x388/0x464 [ehci_hcd]) > > > > Since there aren't any devices registered on the USB bus yet, > > ehci_handle_start_intr_unlink()

Re: Page allocation failure (order 7) in UAS code

On ven., 2016-03-04 at 08:18 +0100, Hans de Goede wrote: > Thanks for testing, there shouldn't be any side-effects, I'll turn this into > a proper patch, add a: > > Reported-and-tested-by: Yves-Alexis Perez > > line to the comit msg and submit this upstream. > > Thanks, I

[GIT PULL] USB changes for v4.6

Hi Greg, here's the gadget pull request for v4.6. This time I had to based it on top of your greg/usb-next to avoid duplicated commits for the USB 3.1 work which some dwc3 changes depended on. Another benefit of the rebase is that I don't have a merge commit of v4.5-rc6 anymore :-) Let me know

Re: some questions about PM enable with usb driver

hi Alan and Peter: >> >> Backtrace: >> [] (ehci_handle_start_intr_unlinks [ehci_hcd]) from >> [] (ehci_bus_suspend+0x388/0x464 [ehci_hcd]) > > Since there aren't any devices registered on the USB bus yet, > ehci_handle_start_intr_unlink() should do nothing. It iterates over > ehci->intr_unlink,

Re: [PATCH] usb:super speed warm reset rejudge

Hello. On 3/4/2016 11:28 AM, l00229106 wrote: Some super speed device, insert the u3 port, sometimes link is in the Compliance Mode State(0x340), and then satisfy hub_port_warm_reset_required conditions, the software will perform a warm reset, u3 PORTSC becomes 0x2a1203. In hub_port_reset

Re: [PATCH] usb:super speed warm reset rejudge

-rejudge/20160304-163718 base: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-testing config: x86_64-lkp (attached as .config) reproduce: # save the attached .config to linux build tree make ARCH=x86_64 All errors (new ones prefixed by >>): drive

Re: usb: musb: tx fifo flush warning

On 2016-03-04, John Ogness wrote: > Using v4.5-rc6, I modified musb_h_tx_flush_fifo() to allow infinite > looping and kept a log of the number of loops that were executed. For > my test I am regularly seeing 3000-3200 loops (with a max so far of > 3289). Since there

Re: usb: musb: tx fifo flush warning

On 2016-03-03, John Ogness wrote: >>> Using next-20160302 I can very reliably hit this warning on an >>> AM335x BeagleBone by playing a short audio file over USB-Audio: >>> >>> $ aplay -Dplughw:1,0 -r 44100 -c 2 -f S16_LE >>> /usr/share/sounds/alsa/Front_Center.wav

Re: some questions about PM enable with usb driver

On Thu, Mar 03, 2016 at 11:16:11PM +0800, yoma sophian wrote: > hi all: > When I porting my platform ehci driver on kernel v4.1, > I get back trace like below without plug in any device and just insert > usb-common.ko, usbcore.ko and ehci-hcd.ko. > (and detail is show in the attachment) > > It

Re: [PATCH] usb: phy: mxs: Add DT bindings to configure TX settings

On Thu, Mar 03, 2016 at 04:29:31PM -0500, Jaret Cantu wrote: > +static void mxs_phy_tx_init(struct mxs_phy *mxs_phy) > +{ > + void __iomem *base = mxs_phy->phy.io_priv; > + u32 phytx; > + > + /* Update TX register if there is anything to write */ > + if (mxs_phy->tx_reg_mask) { > +

Re: [PATCH v5 4/4] leds: core: add support for RGB LED's

On 03/01/2016 10:36 PM, Heiner Kallweit wrote: Export a function to convert HSV color values to RGB. It's intended to be called by drivers for RGB LEDs. Signed-off-by: Heiner Kallweit --- v2: - move hsv -> rgb conversion to separate file - remove flag LED_DEV_CAP_RGB v3:

Re: [PATCH v5 1/4] leds: core: add generic support for RGB Color LED's

Hi Heiner, Thanks for the updated version. Some nitpicking below. Please remove "Color" from the patch title. On 03/01/2016 10:26 PM, Heiner Kallweit wrote: Add generic support for RGB Color LED's. ^^^ Ditto. Basic idea is to use enum led_brightness also for

Re: [PATCH v6 3/4] leds: core: add documentation for color extension

Hi Heiner, Please split the sysfs-class-led part to a separate patch. On 03/02/2016 08:31 PM, Heiner Kallweit wrote: Document the color extension in Documentation/leds/leds-class.txt Signed-off-by: Heiner Kallweit --- v2: - introduced to patch series v3: - document

[PATCH] usb:super speed warm reset rejudge

Some super speed device, insert the u3 port, sometimes link is in the Compliance Mode State(0x340), and then satisfy hub_port_warm_reset_required conditions, the software will perform a warm reset, u3 PORTSC becomes 0x2a1203. In hub_port_reset function, it will clear USB_PORT_FEAT_C_CONNECTION by

Re: [PATCH 1/5] usb: gadget: f_midi: refactor state machine

Felipe Ferreri Tonello wrote: > On 03/03/16 11:38, Clemens Ladisch wrote: >> But in what way was the old state machine not "proper"? > > Because it didn't reflect all the correct and possible MIDI states The whole point of the one-byte real-time messages is that they do not affect the parsing of