[patch] usb: gadget: f_midi: unlock on error

We added some new locking here, but missed an error path where we need to unlock. Fixes: 9acdf4df2fc4 ('usb: gadget: f_midi: added spinlock on transmit function') Signed-off-by: Dan Carpenter diff --git a/drivers/usb/gadget/function/f_midi.c

Re: function ehci_hub_control in ehci-hub.c

On Fri, Apr 1, 2016 at 9:19 PM, Alan Stern wrote: > On Fri, 1 Apr 2016, Navin P.S wrote: > >> On Fri, Apr 1, 2016 at 8:00 PM, Alan Stern wrote: >> > On Fri, 1 Apr 2016, Navin P.S wrote: >> > >> >> Hi, >> >> >> >> I was looking at the bug >>

Re: usb 3.0 stopped working with 4.6.0 rc1

Would you mind sending me the patches , so i could test with my external HD? even with today git build im getting all but errors with this controller and the driver. with today build i even have one shutdown usb 3.0 port! best | Paulo Dias | paulo.miguel.d...@gmail.com Tempora mutantur, nos et

Re: USB gadgets with configfs hang reboot

> On Fri, 1 Apr 2016, Michal Nazarewicz wrote: >> @@ -3050,9 +3053,11 @@ static int fsg_bind(struct usb_configuration *c, >> struct usb_function *f) >> if (ret) >> return ret; >> fsg_common_set_inquiry_string(fsg->common, NULL, NULL); >> -

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

Hi! > >>It would have the same downsides as in case of having r, g and b in > >>separate attributes, i.e. - problems with setting LED colour in > >>a consistent way. This way LED blinking in whatever colour couldn't > >>be supported reliably. It was one of your primary rationale standing >

Re: [PATCH v2 06/11] phy: da8xx-usb: new driver for DA8XX SoC USB PHY

Hi, On Fri, Apr 01, 2016 at 10:45:47PM +0300, Sergei Shtylyov wrote: > On 04/01/2016 07:02 PM, David Lechner wrote: > > +EXPORT_SYMBOL_GPL(da8xx_usb20_phy_set_mode); > >>> > >>>Don't prefer export symbols from PHY driver. That'll create unnecessary > >>>dependencies between the controller

Re: [PATCH v2 06/11] phy: da8xx-usb: new driver for DA8XX SoC USB PHY

On 04/01/2016 07:19 PM, Bin Liu wrote: +EXPORT_SYMBOL_GPL(da8xx_usb20_phy_set_mode); Don't prefer export symbols from PHY driver. That'll create unnecessary dependencies between the controller and the PHY. Agreed. I think it'll be better to create a new attribute and use it? Another

Re: [PATCH v2 06/11] phy: da8xx-usb: new driver for DA8XX SoC USB PHY

On 04/01/2016 07:02 PM, David Lechner wrote: +EXPORT_SYMBOL_GPL(da8xx_usb20_phy_set_mode); Don't prefer export symbols from PHY driver. That'll create unnecessary dependencies between the controller and the PHY. Agreed. I think it'll be better to create a new attribute and use it?

Re: USB gadgets with configfs hang reboot

On Fri, 1 Apr 2016, Michal Nazarewicz wrote: > On Thu, Mar 31 2016, Alan Stern wrote: > > Michal, I'm not sure how you intended to handle this. > > For legacy/nokia setting no_configfs should be a valid solution: > > >8 >

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

On 04/01/2016 03:57 PM, Pavel Machek wrote: Hi! On Wed 2016-03-30 09:57:38, Jacek Anaszewski wrote: Hi Heiner and Pavel, On 03/29/2016 10:38 PM, Heiner Kallweit wrote: Am 29.03.2016 um 12:02 schrieb Pavel Machek: Hi! First, please Cc me on RGB color support. Add generic support for RGB

Re: [PATCH v3 2/2] usb:dwc3: pass arch data to xhci-hcd child

+Arnd, RMK, On 4/1/2016 4:57 AM, Felipe Balbi wrote: Hi, Grygorii Strashko writes: On 04/01/2016 01:20 PM, Felipe Balbi wrote: [...] commit 7ace8fc8219e4cbbfd5b4790390d9a01a2541cdf Author: Yoshihiro Shimoda Date: Mon Jul 13

Re: USB gadgets with configfs hang reboot

On Thu, Mar 31 2016, Alan Stern wrote: > Michal, I'm not sure how you intended to handle this. For legacy/nokia setting no_configfs should be a valid solution: >8 diff --git a/drivers/usb/gadget/legacy/nokia.c

Re: [PATCH v2 06/11] phy: da8xx-usb: new driver for DA8XX SoC USB PHY

Hi, On Fri, Apr 01, 2016 at 11:02:23AM -0500, David Lechner wrote: > On 04/01/2016 09:45 AM, Bin Liu wrote: > >>>+EXPORT_SYMBOL_GPL(da8xx_usb20_phy_set_mode); > >> > >>Don't prefer export symbols from PHY driver. That'll create unnecessary > >>dependencies between the controller and the PHY. > >

Re: [PATCH v2 06/11] phy: da8xx-usb: new driver for DA8XX SoC USB PHY

On 04/01/2016 09:45 AM, Bin Liu wrote: +EXPORT_SYMBOL_GPL(da8xx_usb20_phy_set_mode); Don't prefer export symbols from PHY driver. That'll create unnecessary dependencies between the controller and the PHY. Agreed. I think it'll be better to create a new attribute and use it? Another

Re: function ehci_hub_control in ehci-hub.c

On Fri, 1 Apr 2016, Navin P.S wrote: > On Fri, Apr 1, 2016 at 8:00 PM, Alan Stern wrote: > > On Fri, 1 Apr 2016, Navin P.S wrote: > > > >> Hi, > >> > >> I was looking at the bug https://bugzilla.kernel.org/show_bug.cgi?id=112171 > >> which says > >> > >> Feb 08

Re: [PATCH 1/2] phy: Group vendor specific phy drivers

Hi Vivek, [auto build test ERROR on rockchip/for-next] [also build test ERROR on v4.6-rc1 next-20160401] [if your patch is applied to the wrong git tree, please drop us a note to help improving the system] url: https://github.com/0day-ci/linux/commits/Vivek-Gautam/phy-Group-vendor-specific

Re: function ehci_hub_control in ehci-hub.c

On Fri, Apr 1, 2016 at 8:00 PM, Alan Stern wrote: > On Fri, 1 Apr 2016, Navin P.S wrote: > >> Hi, >> >> I was looking at the bug https://bugzilla.kernel.org/show_bug.cgi?id=112171 >> which says >> >> Feb 08 22:58:56 x kernel: UBSAN: Undefined behaviour in >>

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

Hi! > >>The main drawback is that you can't set the colour at one go, > >>but have to set brightness of each LED class device (R,G,B) > >>separately. It incurs delays between setting each colour component. > > > >Yeah. Well, on some hardware, that's just the way it is. If the leds > >are separate

Re: [PATCH v3 15/16] usb: musb: da8xx: Use devm in probe

Hi, On Thu, Mar 31, 2016 at 05:28:48PM -0500, David Lechner wrote: > On 03/31/2016 05:21 PM, Bin Liu wrote: > > >>- glue = kzalloc(sizeof(*glue), GFP_KERNEL); > >>+ glue = devm_kzalloc(>dev, sizeof(*glue), GFP_KERNEL); > >>if (!glue) { > >>dev_err(>dev, "failed to allocate

Re: [PATCH] usb: gadget: f_midi: Fixed a bug when buflen was smaller than wMaxPacketSize

Hi Balbi, On 01/04/16 11:22, Felipe Balbi wrote: > > Hi, > > Felipe Ferreri Tonello writes: >> Hi Balbi and Mina, >> >> On 30/03/16 13:33, Michal Nazarewicz wrote: >>> On Wed, Mar 30 2016, Felipe Balbi wrote: a USB packet, right. that's correct. But a struct

Re: [PATCH v2 06/11] phy: da8xx-usb: new driver for DA8XX SoC USB PHY

Hi, On Fri, Apr 01, 2016 at 06:46:28PM +0530, Kishon Vijay Abraham I wrote: > Hi, > > On Thursday 17 March 2016 07:56 AM, David Lechner wrote: > > This is a new phy driver for the SoC USB controllers on the TI DA8XX > > family of microcontrollers. The USB 1.1 PHY is just a simple on/off. > > The

Re: function ehci_hub_control in ehci-hub.c

On Fri, 1 Apr 2016, Navin P.S wrote: > Hi, > > I was looking at the bug https://bugzilla.kernel.org/show_bug.cgi?id=112171 > which says > > Feb 08 22:58:56 x kernel: UBSAN: Undefined behaviour in > drivers/usb/host/ehci-hub.c:873:47 > Feb 08 22:58:56 x kernel: index -1 is out of range for type

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

On 04/01/2016 04:07 PM, Pavel Machek wrote: Hi! pavel@duo:~$ ls -1 /sys/class/leds/ tpacpi:green:batt tpacpi:orange:batt This is physically 2 leds but hidden under one indicator, so you got "off", "green", "orange" and "green+orange". That's a good example. As long as you can recognize

Re: [PATCH] usb: host: focus the development community's efforts

On Fri, 1 Apr 2016, Felipe Balbi wrote: > Linux has been growing larger and adopting more and > more users. In order to streamline the development > process, I propose that we focus USB efforts on XHCI > alone, which is the HCD of the future. > > Anybody still using non-XHCI USB Host Controllers

Re: [PATCH v7 1/4] gadget: Introduce the usb charger framework

On Fri, Apr 01, 2016 at 08:43:10AM +0300, Felipe Balbi wrote: > Mark Brown writes: > > IIRC Greg didn't want new classes? > good point. Still, this doesn't seem to fit a but_type IMO. It does in this new world order. IIRC on an earlier round of review there was some code

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

Hi! > >>>pavel@duo:~$ ls -1 /sys/class/leds/ > >>>tpacpi:green:batt > >>>tpacpi:orange:batt > >>> > >>>This is physically 2 leds but hidden under one indicator, so you got > >>>"off", "green", "orange" and "green+orange". > >> > >>That's a good example. As long as you can recognize green+orange

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

Hi! On Wed 2016-03-30 09:57:38, Jacek Anaszewski wrote: > Hi Heiner and Pavel, > > On 03/29/2016 10:38 PM, Heiner Kallweit wrote: > >Am 29.03.2016 um 12:02 schrieb Pavel Machek: > >>Hi! > >> > >>First, please Cc me on RGB color support. > >> > >>>Add generic support for RGB Color LED's. > >>> >

Re: [PATCH 1/2] phy: Group vendor specific phy drivers

Hi, On Fri, Apr 1, 2016 at 6:05 AM, Kishon Vijay Abraham I wrote: > Hi, > > On Friday 01 April 2016 04:59 PM, Vivek Gautam wrote: >> Adding vendor specific directories in phy to group >> phy drivers under their respective vendor umbrella. >> >> Signed-off-by: Vivek Gautam

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

On 04/01/2016 02:55 PM, Pavel Machek wrote: Hi! pavel@duo:~$ ls -1 /sys/class/leds/ tpacpi:green:batt tpacpi:orange:batt This is physically 2 leds but hidden under one indicator, so you got "off", "green", "orange" and "green+orange". That's a good example. As long as you can recognize

Re: [PATCH v2 06/11] phy: da8xx-usb: new driver for DA8XX SoC USB PHY

Hi, On Thursday 17 March 2016 07:56 AM, David Lechner wrote: > This is a new phy driver for the SoC USB controllers on the TI DA8XX > family of microcontrollers. The USB 1.1 PHY is just a simple on/off. > The USB 2.0 PHY also allows overriding the VBUS and ID pins. > > Signed-off-by: David

Re: [PATCH 1/2] phy: Group vendor specific phy drivers

Hi, On Friday 01 April 2016 04:59 PM, Vivek Gautam wrote: > Adding vendor specific directories in phy to group > phy drivers under their respective vendor umbrella. > > Signed-off-by: Vivek Gautam > --- > > With growing number of phy drivers, it makes sense to > group

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

Hi! > > pavel@duo:~$ ls -1 /sys/class/leds/ > > tpacpi:green:batt > > tpacpi:orange:batt > > > > This is physically 2 leds but hidden under one indicator, so you got > > "off", "green", "orange" and "green+orange". > > That's a good example. As long as you can recognize green+orange as >

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

Hi! > >Ideally, I'd like to have "triggers", but different ones. As in: if > >charging, do yellow " .xX" pattern. If fully charged, do green steady > >light. If message is waiting, do blue " x x" pattern. If none of > >above, do slow white blinking. (Plus priorities of events). But that's >

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

Hi! > > To be fair... they _are_ separate LED devices. In N900 case, you can > > even see light comming from slightly different places if you look closely. > > > I mainly work with encapsulated USB HID LED devices like Thingm blink(1). > Due to the diffuse plastic cover you don't see the

Re: [PATCH 1/2] phy: Group vendor specific phy drivers

On Fri, Apr 1, 2016 at 4:39 AM, Viresh Kumar wrote: > On 01-04-16, 16:59, Vivek Gautam wrote: >> Adding vendor specific directories in phy to group >> phy drivers under their respective vendor umbrella. >> >> Signed-off-by: Vivek Gautam >> ---

Re: [PATCH 1/2] phy: Group vendor specific phy drivers

Hi, On Fri, Apr 1, 2016 at 4:42 AM, Maxime Ripard wrote: > Hi, > > On Fri, Apr 01, 2016 at 04:59:15PM +0530, Vivek Gautam wrote: >> create mode 100644 drivers/phy/sunxi/Kconfig >> create mode 100644 drivers/phy/sunxi/Makefile >> rename drivers/phy/{ =>

Re: [PATCH] phy: bcm-ns-usb2: new driver for USB 2.0 PHY on Northstar

On 1 April 2016 at 14:00, Rafał Miłecki wrote: > Northstar is a family of SoCs used in home routers. They have USB 2.0 > and 3.0 controllers with PHYs that need to be properly initialized. > This driver provides PHY init support in a generic way and can be bound > with an EHCI

Re: [PATCH v3 2/2] usb:dwc3: pass arch data to xhci-hcd child

Hi, Grygorii Strashko writes: > On 04/01/2016 01:20 PM, Felipe Balbi wrote: >> >> Hi, >> >> Grygorii Strashko writes: if of_dma_configure() does what you want, why don't you just stick it in dwc3-keystone.c and let the driver

Re: [PATCH 1/2] phy: Group vendor specific phy drivers

Hi, On Fri, Apr 01, 2016 at 04:59:15PM +0530, Vivek Gautam wrote: > create mode 100644 drivers/phy/sunxi/Kconfig > create mode 100644 drivers/phy/sunxi/Makefile > rename drivers/phy/{ => sunxi}/phy-sun4i-usb.c (100%) > rename drivers/phy/{ => sunxi}/phy-sun9i-usb.c (100%) That would be

Re: [PATCH 2/2] arm: mach-spear: Enable PHY_PLAT to meet dependency

On 01-04-16, 16:59, Vivek Gautam wrote: > mach-spear enables PHY_ST_SPEAR1310_MIPHY and > PHY_ST_SPEAR1340_MIPHY, which now fall under PHY_PLAT > config. So select CONFIG_PHY_PLAT as well to resolve > dependencies. > > Signed-off-by: Vivek Gautam > Cc: Shiraz Hashim

Re: [PATCH 1/2] phy: Group vendor specific phy drivers

On 01-04-16, 16:59, Vivek Gautam wrote: > Adding vendor specific directories in phy to group > phy drivers under their respective vendor umbrella. > > Signed-off-by: Vivek Gautam > --- > drivers/phy/{ => st}/phy-spear1310-miphy.c| 0 > drivers/phy/{ =>

[PATCH 2/2] arm: mach-spear: Enable PHY_PLAT to meet dependency

mach-spear enables PHY_ST_SPEAR1310_MIPHY and PHY_ST_SPEAR1340_MIPHY, which now fall under PHY_PLAT config. So select CONFIG_PHY_PLAT as well to resolve dependencies. Signed-off-by: Vivek Gautam Cc: Shiraz Hashim ---

[PATCH 1/2] phy: Group vendor specific phy drivers

Adding vendor specific directories in phy to group phy drivers under their respective vendor umbrella. Signed-off-by: Vivek Gautam --- With growing number of phy drivers, it makes sense to group these drivers under their respective vendor/platform umbrella directory.

Re: [PATCH v3 2/2] usb:dwc3: pass arch data to xhci-hcd child

On 04/01/2016 01:20 PM, Felipe Balbi wrote: > > Hi, > > Grygorii Strashko writes: >>> if of_dma_configure() does what you want, why don't you just stick it in >>> dwc3-keystone.c and let the driver continue to copy things for now ? >>> Something like below, perhaps ?

Re: [PATCH] usb: xhci: Fix incomplete PM resume operation due to XHCI commmand timeout

On 01.04.2016 06:55, Rajesh Bhagat wrote: Please share your opinion on other changes for patch submission as well as resume time. I think more effort should be put into investigating why this happens in the first place. What is the root cause? why doesn't xhci start properly after

Re: [PATCH v3 15/16] usb: musb: da8xx: Use devm in probe

Hello. On 4/1/2016 1:21 AM, Bin Liu wrote: Simplify things a bit by using devm functions where possible. Signed-off-by: David Lechner --- v3 changes: * Kept clk variable to minimize noise. drivers/usb/musb/da8xx.c | 19 +-- 1 file changed, 5

Re: [PATCH] usb: gadget: f_midi: Fixed a bug when buflen was smaller than wMaxPacketSize

Hi, Felipe Ferreri Tonello writes: > Hi Balbi and Mina, > > On 30/03/16 13:33, Michal Nazarewicz wrote: >> On Wed, Mar 30 2016, Felipe Balbi wrote: >>> a USB packet, right. that's correct. But a struct usb_request can >>> point to whatever size buffer it wants and UDC is

Re: [PATCH v3 2/2] usb:dwc3: pass arch data to xhci-hcd child

Hi, Grygorii Strashko writes: >> if of_dma_configure() does what you want, why don't you just stick it in >> dwc3-keystone.c and let the driver continue to copy things for now ? >> Something like below, perhaps ? >> > > I know (and i have patch to fix that which I'm

Re: [PATCH v3 2/2] usb:dwc3: pass arch data to xhci-hcd child

On 04/01/2016 10:58 AM, Felipe Balbi wrote: > > Hi, > > Grygorii Strashko writes: >> On 03/31/2016 11:04 AM, Felipe Balbi wrote: >>> "Thang Q. Nguyen" writes: [ text/plain ] Thanks Grygorii for information. I checked but do not see

Re: [PATCH] hid: thingm: change driver to use RGB LED core extension

On Wed, 2 Mar 2016, Heiner Kallweit wrote: > Based on the proposed RGB LED core extension the thingm driver was > changed to make use of this extension. It allows to simplify > the code a lot. For now primary purpose of this patch is to facilitate > testing of the RGB LED core extension. > > I

function ehci_hub_control in ehci-hub.c

Hi, I was looking at the bug https://bugzilla.kernel.org/show_bug.cgi?id=112171 which says Feb 08 22:58:56 x kernel: UBSAN: Undefined behaviour in drivers/usb/host/ehci-hub.c:873:47 Feb 08 22:58:56 x kernel: index -1 is out of range for type 'u32 [1]' I'm suspective the ehci-tegra function

Re: [PATCH] usb: gadget: f_midi: Fixed a bug when buflen was smaller than wMaxPacketSize

Hi Balbi and Mina, On 30/03/16 13:33, Michal Nazarewicz wrote: > On Wed, Mar 30 2016, Felipe Balbi wrote: >> a USB packet, right. that's correct. But a struct usb_request can >> point to whatever size buffer it wants and UDC is required to split >> that into wMaxPacketSize transfers. > > D’oh.

Re: [PATCH] usb: host: focus the development community's efforts

On 01.04.2016 08:55, Felipe Balbi wrote: Linux has been growing larger and adopting more and more users. In order to streamline the development process, I propose that we focus USB efforts on XHCI alone, which is the HCD of the future. Anybody still using non-XHCI USB Host Controllers should

Re: [PATCH v3 2/2] usb:dwc3: pass arch data to xhci-hcd child

Hi, Grygorii Strashko writes: > On 03/31/2016 11:04 AM, Felipe Balbi wrote: >> "Thang Q. Nguyen" writes: >>> [ text/plain ] >>> Thanks Grygorii for information. >>> I checked but do not see dma_init_dev_from_parent is used in >>> linux-next

Re: [PATCH] usb: host: focus the development community's efforts

Hi, Bin Liu writes: > On Fri, Apr 1, 2016 at 12:55 AM, Felipe Balbi > wrote: >> Linux has been growing larger and adopting more and >> more users. In order to streamline the development >> process, I propose that we focus USB efforts on XHCI >>

[PATCH v9 4/4] power: wm831x_power: Support USB charger current limit management

Integrate with the newly added USB charger interface to limit the current we draw from the USB input based on the input device configuration identified by the USB stack, allowing us to charge more quickly from high current inputs without drawing more current than specified from others.

[PATCH v9 2/4] gadget: Support for the usb charger framework

For supporting the usb charger, it adds the usb_charger_init() and usb_charger_exit() functions for usb charger initialization and exit. It will report to the usb charger when the gadget state is changed, then the usb charger can do the power things. Introduce a callback 'get_charger_type' which

[PATCH v9 3/4] gadget: Integrate with the usb gadget supporting for usb charger

When the usb gadget supporting for usb charger is ready, the usb charger should get the type by the 'get_charger_type' callback which is implemented by the usb gadget operations, and get the usb charger pointer from struct 'usb_gadget'. Signed-off-by: Baolin Wang ---

[PATCH v9 1/4] gadget: Introduce the usb charger framework

This patch introduces the usb charger driver based on usb gadget that makes an enhancement to a power driver. It works well in practice but that requires a system with suitable hardware. The basic conception of the usb charger is that, when one usb charger is added or removed by reporting from

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

Currently the Linux kernel does not provide any standard integration of this feature that integrates the USB subsystem with the system power regulation provided by PMICs meaning that either vendors must add this in their kernels or USB gadget devices based on Linux (such as mobile phones) may not

Re: [PATCH] usb: host: focus the development community's efforts

On Fri, Apr 1, 2016 at 12:55 AM, Felipe Balbi wrote: > Linux has been growing larger and adopting more and > more users. In order to streamline the development > process, I propose that we focus USB efforts on XHCI > alone, which is the HCD of the future. > > Anybody

Re: [PATCH] usb: host: focus the development community's efforts

Hi, Felipe Balbi writes: > Linux has been growing larger and adopting more and > more users. In order to streamline the development > process, I propose that we focus USB efforts on XHCI > alone, which is the HCD of the future. > > Anybody still using non-XHCI USB