[PATCH v3 1/7] extcon: usb-gpio: add device binding for platform device

This is needed to handle the GPIO connected USB ID pin found on Intel Baytrail devices. Signed-off-by: Lu Baolu Reviewed-by: Felipe Balbi Acked-by: Chanwoo Choi --- drivers/extcon/extcon-usb-gpio.c | 7 +++ 1 file changed,

[PATCH v3 5/7] usb: mux: add driver for Intel drcfg controlled port mux

Several Intel PCHs and SOCs have an internal mux that is used to share one USB port between device controller and host controller. The mux is handled through the Dual Role Configuration Register. Signed-off-by: Heikki Krogerus Signed-off-by: Lu Baolu

[PATCH v3 4/7] usb: mux: add driver for Intel gpio controlled port mux

In some Intel platforms, a single usb port is shared between USB host and device controller. The shared port is under control of GPIO pins. This patch adds the support for USB GPIO controlled port mux. Signed-off-by: David Cohen Signed-off-by: Lu Baolu

[PATCH v3 6/7] usb: pci-quirks: add Intel USB drcfg mux device

In some Intel platforms, a single usb port is shared between USB host and device controllers. The shared port is under control of a switch which is defined in the Intel vendor defined extended capability for xHCI. This patch adds the support to detect and create the platform device for the port

[PATCH v3 7/7] mfd: intel_vuport: Add Intel virtual USB port MFD Driver

Some Intel platforms have an USB port mux controlled by GPIOs. There's a single ACPI platform device that provides both USB ID extcon device and a USB port mux device. This MFD driver will split the 2 devices for their respective drivers. Signed-off-by: Lu Baolu

[PATCH v3 3/7] usb: mux: add common code for Intel dual role port mux

Several Intel PCHs and SOCs have an internal mux that is used to share one USB port between device controller and host controller. A usb port mux could be abstracted as the following elements: 1) mux state: HOST or PERIPHERAL; 2) an extcon cable which triggers the change of mux state between

[PATCH v3 0/7] usb: add support for Intel dual role port mux

Intel SOC chips are featured with USB dual role. The host role is provided by Intel xHCI IP, and the gadget role is provided by IP from designware. Tablet platform designs always share a single port for both host and gadget controllers. There is a mux to switch the port to the right controller

Re: [PATCH v2 7/7] mfd: intel_vuport: Add Intel virtual USB port MFD Driver

On 03/08/2016 12:40 PM, Lee Jones wrote: > On Mon, 07 Mar 2016, Lu Baolu wrote: > >> Some Intel platforms have an USB port mux controlled by GPIOs. >> There's a single ACPI platform device that provides both USB ID >> extcon device and a USB port mux device. This MFD driver will >> split the 2

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

Hi, Felipe Ferreri Tonello writes: >>> On March 5, 2016 4:28:45 PM GMT+00:00, Michal Nazarewicz >>> wrote: >> On Wed, Mar 02 2016, Felipe F. Tonello wrote: >>> @@ -16,7 +16,7 @@ >>> * Copyright (C) 2006 Thumtronics Pty Ltd. >>>

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

Hi, Felipe Ferreri Tonello writes: >>> @@ -63,6 +63,14 @@ static unsigned int out_ports = 1; >>> module_param(out_ports, uint, S_IRUGO); >>> MODULE_PARM_DESC(out_ports, "Number of MIDI output ports"); >>> >>> +static unsigned int bmAttributes =

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

Hi, Felipe Ferreri Tonello writes: > Since f_midi_transmit is called by both ALSA and USB frameworks, it can > potentially cause a race condition between both calls. This is bad because the > way f_midi_transmit is implemented can't handle

Re: USB host port {,performance} issues with Beaglebone

Hi, Victor Dodon writes: > [ text/plain ] > Sorry, I accidentally pressed Send > > On Mon, Mar 7, 2016 at 7:35 PM, Victor Dodon wrote: >> Hi all, >> >> I have some performance issues with the host port on a Beaglebone >> board. I tested with

[PATCH 0/2] usb: renesas_usbhs: fix to avoid unexpected condition

This patch set is based on the latest Felipe's usb.git / testing/next branch. (commit id = ac5706631325ae3695bfa1527101ab2b2f64859f) Yoshihiro Shimoda (2): usb: renesas_usbhs: avoid NULL pointer derefernce in usbhsf_pkt_handler() usb: renesas_usbhs: disable tx irq before starting TX DMAC

[PATCH 2/2] usb: renesas_usbhs: disable tx irq before starting TX DMAC transfer

This patch adds a code to surely disable tx irq of the pipe before starting TX DMAC transfer. Otherwise, a lot of unnecessary tx irqs may heppen in rare cases when DMAC is used. Signed-off-by: Yoshihiro Shimoda --- drivers/usb/renesas_usbhs/fifo.c | 1 + 1 file

[PATCH 1/2] usb: renesas_usbhs: avoid NULL pointer derefernce in usbhsf_pkt_handler()

When unexpected situation happened (e.g. tx/rx irq happened while DMAC is used), the usbhsf_pkt_handler() was possible to cause NULL pointer dereference like the followings: Unable to handle kernel NULL pointer dereference at virtual address pgd = c0004000 [] *pgd=

Re: [PATCH v2 7/7] mfd: intel_vuport: Add Intel virtual USB port MFD Driver

On Mon, 07 Mar 2016, Lu Baolu wrote: > Some Intel platforms have an USB port mux controlled by GPIOs. > There's a single ACPI platform device that provides both USB ID > extcon device and a USB port mux device. This MFD driver will > split the 2 devices for their respective drivers. > >

Re: USB host port {,performance} issues with Beaglebone

Victor On Tue, Mar 8, 2016 at 9:05 AM, Victor Dodon wrote: > > Hi all, > > I have some performance issues with the host port on a Beaglebone > board. I tested with kernel 3.8.13, 3.14.55 and 4.1.18 and the issue > still persists. Running a fio test with 64k random reads

Re: USB host port {,performance} issues with Beaglebone

Sorry, I accidentally pressed Send On Mon, Mar 7, 2016 at 7:35 PM, Victor Dodon wrote: > Hi all, > > I have some performance issues with the host port on a Beaglebone > board. I tested with kernel 3.8.13, 3.14.55 and 4.1.18 and the issue > still persists. Running a fio

USB host port {,performance} issues with Beaglebone

Hi all, I have some performance issues with the host port on a Beaglebone board. I tested with kernel 3.8.13, 3.14.55 and 4.1.18 and the issue still persists. Running a fio test with 64k random reads from a USB flash drive yields a maximum of 14402.01 KiB/s (115216.08 Kb/s). The 3.14 and 4.1

Re: high interrupt latency due to usb_sg_wait()

On Mon, 7 Mar 2016, David Mosberger wrote: > We are seeing relatively high interrupt latencies due to usb_sg_wait() > calling usb_submit_urb() with interrupts disabled (as a result of its > spin_lock_irq() call). > > As far as I can see, io->lock protects io->status and it's not really >

Re: Possible double-free in the usbnet driver

On Mon, 2016-03-07 at 22:50 +0300, Andrey Konovalov wrote: > Could you also add: > Reported-by: Andrey Konovalov Well, the exact bug you reported is fixed in Bjorn's patch the way Linus suggested. I'm fixing just a further race that would require an error condition on top

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

On Mon, 7 Mar 2016, Devon Ash wrote: > Attached is dmesg.txt and usbmon.txt. For what kernel version? And what's with all those netconsole error messages popping up every 5 minutes? > This is the only usbmon I could > capture, from 0u, 5u and 6u don't give anything, I've tried to plug > them

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

Stefan, On Mon, Mar 7, 2016 at 10:40 AM, Stefan Wahren wrote: > Hi Doug, > >> Douglas Anderson hat am 4. März 2016 um 19:23 >> geschrieben: >> >> >> This reverts commit 192cb07f7928 ("usb: dwc2: Fix probe problem on >> bcm2835") now that we've

Re: [PATCH] cdc_ncm: do not call usbnet_link_change from cdc_ncm_bind

From: Bjørn Mork Date: Mon, 7 Mar 2016 21:15:36 +0100 > usbnet_link_change will call schedule_work and should be > avoided if bind is failing. Otherwise we will end up with > scheduled work referring to a netdev which has gone away. > > Instead of making the call conditional, we

[PATCH] cdc_ncm: do not call usbnet_link_change from cdc_ncm_bind

usbnet_link_change will call schedule_work and should be avoided if bind is failing. Otherwise we will end up with scheduled work referring to a netdev which has gone away. Instead of making the call conditional, we can just defer it to usbnet_probe, using the driver_info flag made for this

Re: Minor xhci issues (failed to peer) on Dell XPS 13 9350 (Skylake)

On Mon, Mar 7, 2016 at 12:13 PM, Greg Kroah-Hartman wrote: > On Mon, Mar 07, 2016 at 11:09:36AM -0800, Andy Lutomirski wrote: >> Quick ping here: this is still busted on 4.5-rc6. >> >> On Wed, Feb 17, 2016 at 9:40 AM, Andy Lutomirski wrote: >> > On

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

Running kernel 4.4.4 is no good.. with the same setup as above but only changing out vmlinuz and initrd.img, I run into a kernel panic. "Kernel panic - not syncing: attempted to kill init!" There was an error that I hadn't seen before about "systemd-udevd: could not open builtin file

Re: Minor xhci issues (failed to peer) on Dell XPS 13 9350 (Skylake)

On Mon, Mar 07, 2016 at 11:09:36AM -0800, Andy Lutomirski wrote: > Quick ping here: this is still busted on 4.5-rc6. > > On Wed, Feb 17, 2016 at 9:40 AM, Andy Lutomirski wrote: > > On Wed, Feb 17, 2016 at 8:18 AM, Mathias Nyman > > wrote: > >> On

Re: [PATCH RESEND] xhci:Remove unused marco definitions from the file xhci-hub.c

On Mon, Mar 07, 2016 at 02:20:03PM -0500, Nicholas Krause wrote: > This removes the unneeded marco definitions for the marcos > of XHCI_PORT_RW1S, XHCI_PORT_RW1C, XHCI_PORT_RWand > XHCI_PORT_RZ due to no uses of these marcos in the file > xhci-hub.c or any other related kernel source code

high interrupt latency due to usb_sg_wait()

We are seeing relatively high interrupt latencies due to usb_sg_wait() calling usb_submit_urb() with interrupts disabled (as a result of its spin_lock_irq() call). As far as I can see, io->lock protects io->status and it's not really necessary to hold the lock (or disable interrupts) during the

Re: Possible double-free in the usbnet driver

From: Andrey Konovalov Date: Mon, 7 Mar 2016 22:50:41 +0300 > On Mon, Mar 7, 2016 at 10:11 PM, David Miller wrote: >> From: Linus Torvalds >> Date: Mon, 7 Mar 2016 10:13:09 -0800 >> >>> On Sat, Mar 5, 2016 at 11:53 AM,

Re: Possible double-free in the usbnet driver

On Mon, Mar 7, 2016 at 10:11 PM, David Miller wrote: > From: Linus Torvalds > Date: Mon, 7 Mar 2016 10:13:09 -0800 > >> On Sat, Mar 5, 2016 at 11:53 AM, Bjørn Mork wrote: >>> >>> >>> Definitely. The patch is so obviously

Re: [PATCH net,stable] cdc_ncm: toggle altsetting to force reset before setup

From: Bjørn Mork Date: Thu, 3 Mar 2016 22:20:53 +0100 > Some devices will silently fail setup unless they are reset first. > This is necessary even if the data interface is already in > altsetting 0, which it will be when the device is probed for the > first time. Briefly

[PATCH] uas: Reduce can_queue to MAX_CMNDS

The uas driver can never queue more then MAX_CMNDS (- 1) tags and tags are shared between luns, so there is no need to claim that we can_queue some random large number. Not claiming that we can_queue 65536 commands, fixes the uas driver failing to initialize while allocating the tag map with a

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

On Mon, 7 Mar 2016 10:04:21 -0800 Andy Lutomirski wrote: > > Exactly. The compiler may get away with this in userspace (maybe), but > > for the kernel, it is definitely a show stopper. Especially if it knows > > that an asm() may be called. > > It's broken for user code

Re: Possible double-free in the usbnet driver

From: Linus Torvalds Date: Mon, 7 Mar 2016 10:13:09 -0800 > On Sat, Mar 5, 2016 at 11:53 AM, Bjørn Mork wrote: >> >> >> Definitely. The patch is so obviously correct that we can only wonder how >> it was possible to miss it it the first place :)

Re: Minor xhci issues (failed to peer) on Dell XPS 13 9350 (Skylake)

Quick ping here: this is still busted on 4.5-rc6. On Wed, Feb 17, 2016 at 9:40 AM, Andy Lutomirski wrote: > On Wed, Feb 17, 2016 at 8:18 AM, Mathias Nyman > wrote: >> On 17.02.2016 07:19, Andy Lutomirski wrote: >>> >>> On Tue, Feb 16, 2016 at 6:33

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

Hi Doug, > Douglas Anderson hat am 4. März 2016 um 19:23 > geschrieben: > > > 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()").

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

On Mon, Mar 7, 2016 at 10:07 AM, Alan Stern wrote: > > Of course, there are other ways to save a single flag value (such as > setz). It's up to the compiler developers to decide what they think is > best. Using 'setcc' to save eflags somewhere is definitely the right

Re: Possible double-free in the usbnet driver

On Sat, Mar 5, 2016 at 11:53 AM, Bjørn Mork wrote: > > > Definitely. The patch is so obviously correct that we can only wonder how it > was possible to miss it it the first place :) > > Will take a look to see if we could do a better job cleaning up in other > places. What

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

On Mon, 7 Mar 2016, David Laight wrote: > From: Sedat Dilek > ... > > Did someone look at the next/follow-ups in this thread? > > For example: D6629 "x86: Emit LAHF/SAHF instead of PUSHF/POPF" [2]? > > LAHF and SAHF come with the following note: > > This instruction executes as described above

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

On Mon, Mar 7, 2016 at 9:30 AM, Steven Rostedt wrote: > On Mon, 7 Mar 2016 18:24:12 +0100 (CET) > Jiri Kosina wrote: > >> > So, if Clang is producing wrong X86 code here, is it possible to turn >> > interrupts on/off manually? But, hmm that affects other

Re: [PATCH 5/5 v8] usb: musb: da8xx: Add DT support for the DA8xx driver

On 03/07/2016 07:08 PM, Petr Kulhavy wrote: Hello On 07.03.2016 14:29, Sergei Shtylyov wrote: Hello. On 3/7/2016 2:20 PM, Petr Kulhavy wrote: @@ -544,17 +643,25 @@ static int da8xx_probe(struct platform_device *pdev) pinfo.data = pdata; pinfo.size_data = sizeof(*pdata); +

Re: [PATCH] usbnet: cleanup after bind() in probe()

On Mon, 2016-03-07 at 11:41 -0500, David Miller wrote: > From: Oliver Neukum > Date: Mon, 7 Mar 2016 11:31:10 +0100 > > > In case bind() works, but a later error forces bailing > > in probe() in error cases work and a timer may be scheduled. > > They must be killed. This fixes

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

From: Sedat Dilek ... > Did someone look at the next/follow-ups in this thread? > For example: D6629 "x86: Emit LAHF/SAHF instead of PUSHF/POPF" [2]? LAHF and SAHF come with the following note: This instruction executes as described above in compatibility mode and legacy mode. It is valid in

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

On Mon, 7 Mar 2016 18:24:12 +0100 (CET) Jiri Kosina wrote: > > So, if Clang is producing wrong X86 code here, is it possible to turn > > interrupts on/off manually? But, hmm that affects other places as well > > in the Linux sources, so. > > This issue needs to be handled

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

On Mon, 7 Mar 2016, Sedat Dilek wrote: > Did someone look at the next/follow-ups in this thread? > For example: D6629 "x86: Emit LAHF/SAHF instead of PUSHF/POPF" [2]? Using LAHF/SAHF would "solve" it, as IF is at bit #9. The question is whether they need to play with flags here at all. On Mon,

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

On Mon, Mar 7, 2016 at 5:41 PM, Alan Stern wrote: > On Mon, 7 Mar 2016, Sedat Dilek wrote: > >> Hmm, we are there where I was looking at... >> >> Please, read the reply of Jiri [1], we did some tweaking. >> With CONFIG_FTRACE=n and CONFIG_PROVE_LOCKING=n ! > > Yes, Jiri

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

On Mon, Mar 7, 2016 at 6:05 PM, Jiri Kosina wrote: > On Mon, 7 Mar 2016, Alan Stern wrote: > >> > 319: 9c pushfq >> > 31a: 41 5c pop%r12 >> > 31c: 48 89 dfmov%rbx,%rdi >> > 31f:

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

On Mon, 7 Mar 2016 11:41:37 -0500 (EST) Alan Stern wrote: > It's hard to call this a compiler bug, but perhaps it is -- I don't > know how programmers are supposed to tell CLANG that a subroutine > modifies the Interrupt Flag in a way that the compiler shouldn't mess

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

On Mon, 7 Mar 2016, Alan Stern wrote: > > 319: 9c pushfq > > 31a: 41 5c pop%r12 > > 31c: 48 89 dfmov%rbx,%rdi > > 31f: e8 00 00 00 00 callq 324 > > 324:

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

On Mon, 7 Mar 2016 11:41:37 -0500 (EST) Alan Stern wrote: > It's hard to call this a compiler bug, but perhaps it is -- I don't > know how programmers are supposed to tell CLANG that a subroutine > modifies the Interrupt Flag in a way that the compiler shouldn't mess >

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

On Mon, 7 Mar 2016, Sedat Dilek wrote: > Hmm, we are there where I was looking at... > > Please, read the reply of Jiri [1], we did some tweaking. > With CONFIG_FTRACE=n and CONFIG_PROVE_LOCKING=n ! Yes, Jiri was looking more or less at the right place but his conclusions were wrong. > ***

Re: [PATCH] usbnet: cleanup after bind() in probe()

From: Oliver Neukum Date: Mon, 7 Mar 2016 11:31:10 +0100 > In case bind() works, but a later error forces bailing > in probe() in error cases work and a timer may be scheduled. > They must be killed. This fixes an error case related to > the double free reported in >

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

On Mon, Mar 7, 2016 at 4:59 PM, Sedat Dilek wrote: > On Sun, Mar 6, 2016 at 6:23 PM, Alan Stern wrote: >> On Sat, 5 Mar 2016, Sedat Dilek wrote: >> >>> On Fri, Mar 4, 2016 at 5:04 PM, Alan Stern >>> wrote: >>> > On

Re: [PATCH 5/5 v8] usb: musb: da8xx: Add DT support for the DA8xx driver

Hello On 07.03.2016 14:29, Sergei Shtylyov wrote: Hello. On 3/7/2016 2:20 PM, Petr Kulhavy wrote: @@ -544,17 +643,25 @@ static int da8xx_probe(struct platform_device *pdev) pinfo.data = pdata; pinfo.size_data = sizeof(*pdata); +ret = regulator_enable(glue->vbus_supply);

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

On Sun, Mar 6, 2016 at 6:23 PM, Alan Stern wrote: > On Sat, 5 Mar 2016, Sedat Dilek wrote: > >> On Fri, Mar 4, 2016 at 5:04 PM, Alan Stern wrote: >> > On Wed, 2 Mar 2016, Sedat Dilek wrote: >> > >> >> On 3/1/16, Alan Stern

Re: [PATCH 5/5 v8] usb: musb: da8xx: Add DT support for the DA8xx driver

Hello. On 3/7/2016 2:20 PM, Petr Kulhavy wrote: This adds DT support for TI DA8xx/OMAP-L1x/AM17xx/AM18xx MUSB driver Signed-off-by: Petr Kulhavy Tested-by: Petr Kulhavy Acked-by: Sergei Shtylyov [...] diff --git

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

On Fri, Mar 04, 2016 at 10:31:45PM -0600, Rob Herring wrote: > 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,

[PATCH 1/5 v8] dt/bindings: Add binding for the DA8xx MUSB driver

DT binding for the TI DA8xx/OMAP-L1x/AM17xx/AM18xx MUSB driver. Signed-off-by: Petr Kulhavy --- v1: v2: - using standard properties "dr_mode", "mentor,power", "mentor,num-eps", "mentor,multipoint", "mentor,ram-bits" - using "ti," prefix instead of "da8xx," for specific

[PATCH 5/5 v8] usb: musb: da8xx: Add DT support for the DA8xx driver

This adds DT support for TI DA8xx/OMAP-L1x/AM17xx/AM18xx MUSB driver Signed-off-by: Petr Kulhavy Tested-by: Petr Kulhavy Acked-by: Sergei Shtylyov --- v1: v2: - using standard MUSB properties "dr_mode", "mentor,power",

[PATCH 2/5 v8] usb: musb: core: added helper function for parsing DT

This adds the function musb_get_mode() to get the DT property "dr_mode" Signed-off-by: Petr Kulhavy --- v4: - created musb_get_dr_mode() v5: - musb_get_dr_mode() renamed to musb_get_mode() - added musb_get_power() v6: - musb_get_power() : added missing boundary check for

[PATCH 4/5 v8] ARM: davinci: defined missing CFGCHIP2_REFFREQ_* macros for MUSB PHY

Only few MUSB PHY reference clock frequencies were defined. This patch defines macros for the missing frequencies: 19.2MHz, 38.4MHz, 13MHz, 26MHz, 20MHz, 40MHz Signed-off-by: Petr Kulhavy Acked-by: Sergei Shtylyov Signed-off-by: Bin Liu

[PATCH 3/5 v8] usb: musb: core: added missing const qualifier to musb_hdrc_platform_data::config

The musb_hdrc_platform_data::config was defined as a non-const pointer. However some drivers (e.g. the ux500) set up this pointer to point to a static structure, which is potentially dangerous. Since the musb core uses the pointer in a read-only manner the const qualifier was added to protect the

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

Hi Balbi, how are you? On 07/03/16 10:59, Felipe Balbi wrote: > > Hi, > > Felipe Ferreri Tonello writes: > "Felipe F. Tonello" writes: >> [ text/plain ] >> This gadget uses a bmAttributes and MaxPower that requires the USB > bus

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

Hi, Felipe Ferreri Tonello writes: "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 because this

[PATCH] usbnet: cleanup after bind() in probe()

In case bind() works, but a later error forces bailing in probe() in error cases work and a timer may be scheduled. They must be killed. This fixes an error case related to the double free reported in http://www.spinics.net/lists/netdev/msg367669.html and needs to go on top of Linus' fix to

RE: usb: musb: tx fifo flush warning

From: John Ogness > Sent: 04 March 2016 10:51 > 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

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

Hi Balbi, On 07/03/16 07:34, Felipe Balbi wrote: > > Hi, > > Felipe Ferreri Tonello writes: >> [ text/plain ] >> Hi Balbi, >> >> On March 4, 2016 7:16:42 AM GMT+00:00, Felipe Balbi wrote: >>> >>> Hi, >>> >>> "Felipe F. Tonello"

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

Hi Balbi, On 07/03/16 07:35, Felipe Balbi wrote: > > Hi, > > Felipe Ferreri Tonello writes: >> [ text/plain ] >> Hi Michal, >> >> On March 5, 2016 4:28:45 PM GMT+00:00, Michal Nazarewicz >> wrote: > On Wed, Mar 02 2016, Felipe F. Tonello wrote:

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

Hi Balbi, On 07/03/16 07:32, Felipe Balbi wrote: > > Hi, > > (please break your lines at 80-characters, have a look at > Documentation/email-clients.txt if needed) > > Felipe Ferreri Tonello writes: >> [ text/plain ] >> Hi Balbi, >> >> On March 4, 2016 7:20:10 AM

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

Hi Balbi, On 07/03/16 07:36, Felipe Balbi wrote: > > Hi, > > Felipe Ferreri Tonello writes: >> [ text/plain ] >> Hi Balbi, >> >> On March 4, 2016 7:13:05 AM GMT+00:00, Felipe Balbi wrote: >>> "Felipe F. Tonello" writes:

Re: Possible double-free in the usbnet driver

On Fri, Mar 4, 2016 at 11:43 PM, 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]

[PATCH v2 0/7] usb: add support for Intel dual role port mux

Intel SOC chips are featured with USB dual role. The host role is provided by Intel xHCI IP, and the gadget role is provided by IP from designware. Tablet platform designs always share a single port for both host and gadget controllers. There is a mux to switch the port to the right controller

[PATCH v2 3/7] usb: mux: add common code for Intel dual role port mux

Several Intel PCHs and SOCs have an internal mux that is used to share one USB port between device controller and host controller. A usb port mux could be abstracted as the following elements: 1) mux state: HOST or PERIPHERAL; 2) an extcon cable which triggers the change of mux state between

[PATCH v2 6/7] usb: pci-quirks: add Intel USB drcfg mux device

In some Intel platforms, a single usb port is shared between USB host and device controllers. The shared port is under control of a switch which is defined in the Intel vendor defined extended capability for xHCI. This patch adds the support to detect and create the platform device for the port

[PATCH v2 2/7] extcon: usb-gpio: add support for ACPI gpio interface

GPIO resource could be retrieved through APCI as well. Signed-off-by: Lu Baolu Reviewed-by: Felipe Balbi Acked-by: Chanwoo Choi --- drivers/extcon/extcon-usb-gpio.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff

[PATCH v2 5/7] usb: mux: add driver for Intel drcfg controlled port mux

Several Intel PCHs and SOCs have an internal mux that is used to share one USB port between device controller and host controller. The mux is handled through the Dual Role Configuration Register. Signed-off-by: Heikki Krogerus Signed-off-by: Lu Baolu

[PATCH v2 7/7] mfd: intel_vuport: Add Intel virtual USB port MFD Driver

Some Intel platforms have an USB port mux controlled by GPIOs. There's a single ACPI platform device that provides both USB ID extcon device and a USB port mux device. This MFD driver will split the 2 devices for their respective drivers. Signed-off-by: Lu Baolu

[PATCH v2 4/7] usb: mux: add driver for Intel gpio controlled port mux

In some Intel platforms, a single usb port is shared between USB host and device controller. The shared port is under control of GPIO pins. This patch adds the support for USB GPIO controlled port mux. Signed-off-by: David Cohen Signed-off-by: Lu Baolu

[PATCH v2 1/7] extcon: usb-gpio: add device binding for platform device

This is needed to handle the GPIO connected USB ID pin found on Intel Baytrail devices. Signed-off-by: Lu Baolu Reviewed-by: Felipe Balbi Acked-by: Chanwoo Choi --- drivers/extcon/extcon-usb-gpio.c | 7 +++ 1 file changed,

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

Hi, Am 07.03.2016 um 08:26 schrieb Felipe Balbi : > > Hi, > > John Youn writes: >> [ text/plain ] >> On 3/4/2016 6:14 PM, Doug Anderson wrote: >>> Hi, >>> >>> On Fri, Mar 4, 2016 at 5:56 PM, John Youn wrote: On 3/4/2016

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

Hi Karl, On 03/06/2016 09:55 PM, Karl Palsson wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Heiner Kallweit wrote: 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