Re: [PATCH 0/3] Fix OMAP EHCI probe & assorted cleanups

[Lee Jones]

On Sun, 23 Sep 2018, Lee Jones wrote:

> On Sun, 23 Sep 2018, Laurent Pinchart wrote:
> 
> > Hi Tony,
> > 
> > On Tuesday, 11 September 2018 19:25:38 EEST Tony Lindgren wrote:
> > > * Laurent Pinchart  [180911 16:12]:
> > > > On Tuesday, 11 September 2018 18:16:41 EEST Tony Lindgren wrote:
> > > >> * Laurent Pinchart  [180911 15:10]:
> > > >>> Hello,
> > > >>> 
> > > >>> This series fixes a v4.19-rc1 regression that results in OMAP EHCI
> > > >>> failing to probe (patch 1/3) and then moves on to cleaning up related
> > > >>> code (patches 2/3 and 3/3).
> > > >>> 
> > > >>> The first patch is a regression fix and should thus be merged before
> > > >>> v4.19. The other two patches can wait until v4.20.
> > > >> 
> > > >> Hmm can you please check again with this patch applied:
> > > >> 
> > > >> "[PATCH] mfd: omap-usb-host: Fix dts probe of children"
> > > > 
> > > > This fixes the issue for me.
> > > > 
> > > > Tested-by: Laurent Pinchart 
> > > 
> > > OK good to hear.
> > 
> > The fix is still not in v4.19-rc4 :-S Could you make sure it doesn't miss 
> > v4.19 ?
> 
> I'm going to send these today:
> 
>   mfd: omap-usb-host: Fix dts probe of children
>   mfd: da9063: Fix DT probing with constraints

Greg just pulled.

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH 0/3] Fix OMAP EHCI probe & assorted cleanups

[Lee Jones]

On Sun, 23 Sep 2018, Laurent Pinchart wrote:

> Hi Tony,
> 
> On Tuesday, 11 September 2018 19:25:38 EEST Tony Lindgren wrote:
> > * Laurent Pinchart  [180911 16:12]:
> > > On Tuesday, 11 September 2018 18:16:41 EEST Tony Lindgren wrote:
> > >> * Laurent Pinchart  [180911 15:10]:
> > >>> Hello,
> > >>> 
> > >>> This series fixes a v4.19-rc1 regression that results in OMAP EHCI
> > >>> failing to probe (patch 1/3) and then moves on to cleaning up related
> > >>> code (patches 2/3 and 3/3).
> > >>> 
> > >>> The first patch is a regression fix and should thus be merged before
> > >>> v4.19. The other two patches can wait until v4.20.
> > >> 
> > >> Hmm can you please check again with this patch applied:
> > >> 
> > >> "[PATCH] mfd: omap-usb-host: Fix dts probe of children"
> > > 
> > > This fixes the issue for me.
> > > 
> > > Tested-by: Laurent Pinchart 
> > 
> > OK good to hear.
> 
> The fix is still not in v4.19-rc4 :-S Could you make sure it doesn't miss 
> v4.19 ?

I'm going to send these today:

  mfd: omap-usb-host: Fix dts probe of children
  mfd: da9063: Fix DT probing with constraints

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [Question] MFD driver that handles clocks/resets and populates child nodes

[Lee Jones]

On Tue, 03 Apr 2018, Masahiro Yamada wrote:

> 2018-04-03 17:03 GMT+09:00 Lee Jones <lee.jo...@linaro.org>:
> > On Mon, 02 Apr 2018, Andrew Lunn wrote:
> >
> >> On Mon, Apr 02, 2018 at 10:21:01PM +0900, Masahiro Yamada wrote:
> >> > 2018-04-02 21:04 GMT+09:00 Andrew Lunn <and...@lunn.ch>:
> >> > >> The maintainer of DWC3, Felipe Balbi, requested to
> >> > >> split the glue layer driver into small parts such as
> >> > >> reset, regulator, phy, etc.
> >> > >
> >> > > What exactly did Felipe ask for? Did he ask that the patch be split
> >> > > up, one patch per reset, regulator, phy etc?
> >> >
> >> >
> >> > Yeah.  That is what we understood from his comments.
> >> >
> >> >
> >> > These are the feed-backs from him.
> >> >
> >> > https://lkml.org/lkml/2018/1/23/298
> >> > https://lkml.org/lkml/2018/1/24/352
> >>
> >> > > Are all these resources used just by the DWC3? Or is it a true MFD,
> >> > > multiple functions?
> >> >
> >> > I do not think this is a real MFD.
> >> >
> >> > This is a DWC3 glue layer, i.e.
> >> > a collection of misc registers that control
> >> > the DWC3 IP.
> >> >
> >> >
> >> > Just splitting it into small pieces
> >> > to use PHY, reset, regulator framework in Linux.
> >> >
> >> > Of course, the price of this approach
> >> > is so cluttered Device Tree,
> >> > honestly I do not like it much.
> >>
> >> This however the correct way to do this. You should have a phy driver,
> >> and a regulator driver, and a reset driver. The DWC3 then uses
> >> phandles to these drivers.
> >>
> >> How is the IO map area 65b0 split up. Can you cleanly separate it
> >> into sub areas, which do not overlap, so you have a sub-area for the
> >> PHY driver, a sub-area for the regulator driver and a sub-area for the
> >> reset area? If you can cleanly split it up, you don't need an MFD. If
> >> however the registers are in overlapping areas, you do need an
> >> MFD. The MFD core provides access to the registers, while its children
> >> implement PHY, reset, regulator etc.
> >
> > This device certainly sounds like an MFD to me.
> >
> > Can you share the DT you've written please?
> 
> 
> This is still under the internal review in Socionext,
> but I attached it below FWIW.
> 
> (I am not the author of this DT.
>  Written by Kunihiko Hayashi,
> 
> Just skimming the driver, I guess it will be possible to flatten
> the node structure by separating the register space into sub-areas.
> If this is success, we do not the MFD driver.

Sounds like a plan.  Pretty sure this isn't really an MFD.

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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: [Question] MFD driver that handles clocks/resets and populates child nodes

[Lee Jones]

On Mon, 02 Apr 2018, Andrew Lunn wrote:

> On Mon, Apr 02, 2018 at 10:21:01PM +0900, Masahiro Yamada wrote:
> > 2018-04-02 21:04 GMT+09:00 Andrew Lunn <and...@lunn.ch>:
> > >> The maintainer of DWC3, Felipe Balbi, requested to
> > >> split the glue layer driver into small parts such as
> > >> reset, regulator, phy, etc.
> > >
> > > What exactly did Felipe ask for? Did he ask that the patch be split
> > > up, one patch per reset, regulator, phy etc?
> > 
> > 
> > Yeah.  That is what we understood from his comments.
> > 
> > 
> > These are the feed-backs from him.
> > 
> > https://lkml.org/lkml/2018/1/23/298
> > https://lkml.org/lkml/2018/1/24/352
> 
> > > Are all these resources used just by the DWC3? Or is it a true MFD,
> > > multiple functions?
> > 
> > I do not think this is a real MFD.
> > 
> > This is a DWC3 glue layer, i.e.
> > a collection of misc registers that control
> > the DWC3 IP.
> > 
> > 
> > Just splitting it into small pieces
> > to use PHY, reset, regulator framework in Linux.
> > 
> > Of course, the price of this approach
> > is so cluttered Device Tree,
> > honestly I do not like it much.
> 
> This however the correct way to do this. You should have a phy driver,
> and a regulator driver, and a reset driver. The DWC3 then uses
> phandles to these drivers.
> 
> How is the IO map area 65b0 split up. Can you cleanly separate it
> into sub areas, which do not overlap, so you have a sub-area for the
> PHY driver, a sub-area for the regulator driver and a sub-area for the
> reset area? If you can cleanly split it up, you don't need an MFD. If
> however the registers are in overlapping areas, you do need an
> MFD. The MFD core provides access to the registers, while its children
> implement PHY, reset, regulator etc.

This device certainly sounds like an MFD to me.

Can you share the DT you've written please?

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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

[no subject]

[Jones]

This is in regards to an inheritance on your surname, reply back using your 
email address, stating your full name for more details. Reply to email for 
info. Email me here ( ger...@dr.com )
--
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] extcon: Split out extcon header file for consumer and provider device

[Lee Jones]

On Fri, 29 Sep 2017, Chanwoo Choi wrote:

> The extcon has two type of extcon devices as following.
> - 'extcon provider deivce' adds new extcon device and detect the
>state/properties of external connector. Also, it notifies the
>state/properties to the extcon consumer device.
> - 'extcon consumer device' gets the change state/properties
>from extcon provider device.
> Prior to that, include/linux/extcon.h contains all exported API for
> both provider and consumer device driver. To clarify the meaning of
> header file and to remove the wrong use-case on consumer device,
> this patch separates into extcon.h and extcon-provider.h.
> 
> [Description for include/linux/{extcon.h|extcon-provider.h}]
> - extcon.h includes the extcon API and data structure for extcon consumer
>   device driver. This header file contains the following APIs:
>   : Register/unregister the notifier to catch the change of extcon device
>   : Get the extcon device instance
>   : Get the extcon device name
>   : Get the state of each external connector
>   : Get the property value of each external connector
>   : Get the property capability of each external connector
> 
> - extcon-provider.h includes the extcon API and data structure for extcon
>   provider device driver. This header file contains the following APIs:
>   : Include 'include/linux/extcon.h'
>   : Allocate the memory for extcon device instance
>   : Register/unregister extcon device
>   : Set the state of each external connector
>   : Set the property value of each external connector
>   : Set the property capability of each external connector
> 
> Cc: Felipe Balbi <ba...@kernel.org>
> Cc: Kishon Vijay Abraham I <kis...@ti.com>
> Cc: Greg Kroah-Hartman <gre...@linuxfoundation.org>
> Cc: Sebastian Reichel <s...@kernel.org>
> Cc: Lee Jones <lee.jo...@linaro.org>
> Signed-off-by: Chanwoo Choi <cw00.c...@samsung.com>
> ---
>  drivers/extcon/extcon-adc-jack.c  |   2 +-
>  drivers/extcon/extcon-arizona.c   |   2 +-
>  drivers/extcon/extcon-axp288.c|   2 +-
>  drivers/extcon/extcon-gpio.c  |   2 +-
>  drivers/extcon/extcon-intel-cht-wc.c  |   2 +-
>  drivers/extcon/extcon-intel-int3496.c |   2 +-
>  drivers/extcon/extcon-max14577.c  |   2 +-
>  drivers/extcon/extcon-max3355.c   |   2 +-
>  drivers/extcon/extcon-max77693.c  |   2 +-
>  drivers/extcon/extcon-max77843.c  |   2 +-
>  drivers/extcon/extcon-max8997.c   |   2 +-
>  drivers/extcon/extcon-qcom-spmi-misc.c|   2 +-
>  drivers/extcon/extcon-rt8973a.c   |   2 +-
>  drivers/extcon/extcon-sm5502.c|   2 +-
>  drivers/extcon/extcon-usb-gpio.c  |   2 +-
>  drivers/extcon/extcon-usbc-cros-ec.c  |   2 +-
>  drivers/extcon/extcon.h   |   2 +-
>  drivers/phy/allwinner/phy-sun4i-usb.c |   2 +-
>  drivers/phy/broadcom/phy-bcm-ns2-usbdrd.c |   2 +-
>  drivers/phy/renesas/phy-rcar-gen3-usb2.c  |   2 +-
>  drivers/phy/rockchip/phy-rockchip-inno-usb2.c |   2 +-
>  drivers/power/supply/qcom_smbb.c  |   2 +-
>  drivers/usb/gadget/udc/renesas_usb3.c |   2 +-
>  drivers/usb/phy/phy-tahvo.c   |   2 +-
>  drivers/usb/renesas_usbhs/common.h|   2 +-
>  include/linux/extcon-provider.h   | 142 
> ++
>  include/linux/extcon.h| 109 +---

>  include/linux/mfd/palmas.h|   2 +-

Acked-by: Lee Jones <lee.jo...@linaro.org>

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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 v2 8/9] atmel_flexcom: Support backup mode

[Lee Jones]

On Tue, 19 Sep 2017, Nicolas Ferre wrote:

> On 15/09/2017 at 16:04, Romain Izard wrote:
> > The controller used by a flexcom module is configured at boot, and left
> > alone after this. As the configuration will be lost after backup mode,
> > restore the state of the flexcom driver on resume.
> > 
> > Signed-off-by: Romain Izard <romain.izard@gmail.com>
> 
> Tested-by: Nicolas Ferre <nicolas.fe...@microchip.com>
> On sama5d2 Xplained board (i2c0 from flexcom 4).
> and obviously:
> Acked-by: Nicolas Ferre <nicolas.fe...@microchip.com>
> 
> Thanks Romain!
> 
> Regards,
> 
> > ---
> >  drivers/mfd/atmel-flexcom.c | 65 
> > ++---
> >  1 file changed, 50 insertions(+), 15 deletions(-)

This is the first time I've seen this patch.  Why's that?

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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 2/3] mfd: tps65010: move header file out of I2C realm

[Lee Jones]

On Mon, 14 Aug 2017, Lee Jones wrote:

> On Sun, 13 Aug 2017, Wolfram Sang wrote:
> 
> > On Tue, May 23, 2017 at 08:18:19AM +0100, Lee Jones wrote:
> > > On Mon, 22 May 2017, Wolfram Sang wrote:
> > > 
> > > > include/linux/i2c is not for client devices. Move the header file to a
> > > > more appropriate location.
> > > > 
> > > > Signed-off-by: Wolfram Sang <w...@the-dreams.de>
> > > > ---
> > > >  arch/arm/mach-omap1/board-h2-mmc.c  | 2 +-
> > > >  arch/arm/mach-omap1/board-h2.c  | 2 +-
> > > >  arch/arm/mach-omap1/board-h3-mmc.c  | 2 +-
> > > >  arch/arm/mach-omap1/board-h3.c  | 2 +-
> > > >  arch/arm/mach-omap1/board-osk.c | 2 +-
> > > >  arch/arm/mach-s3c24xx/mach-osiris-dvs.c | 2 +-
> > > >  arch/arm/mach-s3c24xx/mach-osiris.c | 2 +-
> > > 
> > > >  drivers/mfd/tps65010.c  | 2 +-
> > > 
> > > For my own reference:
> > >   Acked-for-MFD-by: Lee Jones <lee.jo...@linaro.org>
> > 
> > Same here: ok for 4.14 or something needed?
> 
> Can this patch be applied on its own, or does it have dependencies?

Even if it doesn't, it still requires Acks.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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 2/3] mfd: tps65010: move header file out of I2C realm

[Lee Jones]

On Sun, 13 Aug 2017, Wolfram Sang wrote:

> On Tue, May 23, 2017 at 08:18:19AM +0100, Lee Jones wrote:
> > On Mon, 22 May 2017, Wolfram Sang wrote:
> > 
> > > include/linux/i2c is not for client devices. Move the header file to a
> > > more appropriate location.
> > > 
> > > Signed-off-by: Wolfram Sang <w...@the-dreams.de>
> > > ---
> > >  arch/arm/mach-omap1/board-h2-mmc.c  | 2 +-
> > >  arch/arm/mach-omap1/board-h2.c  | 2 +-
> > >  arch/arm/mach-omap1/board-h3-mmc.c  | 2 +-
> > >  arch/arm/mach-omap1/board-h3.c  | 2 +-
> > >  arch/arm/mach-omap1/board-osk.c | 2 +-
> > >  arch/arm/mach-s3c24xx/mach-osiris-dvs.c | 2 +-
> > >  arch/arm/mach-s3c24xx/mach-osiris.c | 2 +-
> > 
> > >  drivers/mfd/tps65010.c  | 2 +-
> > 
> > For my own reference:
> >   Acked-for-MFD-by: Lee Jones <lee.jo...@linaro.org>
> 
> Same here: ok for 4.14 or something needed?

Can this patch be applied on its own, or does it have dependencies?

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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 3/3] mfd: twl: move header file out of I2C realm

[Lee Jones]

On Sun, 13 Aug 2017, Wolfram Sang wrote:

> On Thu, Jul 06, 2017 at 08:03:52AM +0100, Lee Jones wrote:
> > On Thu, 06 Jul 2017, Thierry Reding wrote:
> > 
> > > On Mon, May 22, 2017 at 12:02:10AM +0200, Wolfram Sang wrote:
> > > > include/linux/i2c is not for client devices. Move the header file to a
> > > > more appropriate location.
> > > > 
> > > > Signed-off-by: Wolfram Sang <w...@the-dreams.de>
> > > > ---
> > > >  arch/arm/mach-omap2/common.h| 2 +-
> > > >  arch/arm/mach-omap2/omap_twl.c  | 2 +-
> > > >  drivers/gpio/gpio-twl4030.c | 2 +-
> > > >  drivers/iio/adc/twl4030-madc.c  | 2 +-
> > > >  drivers/iio/adc/twl6030-gpadc.c | 2 +-
> > > >  drivers/input/keyboard/twl4030_keypad.c | 2 +-
> > > >  drivers/input/misc/twl4030-pwrbutton.c  | 2 +-
> > > >  drivers/input/misc/twl4030-vibra.c  | 2 +-
> > > >  drivers/mfd/twl-core.c  | 6 +++---
> > > >  drivers/mfd/twl4030-audio.c | 2 +-
> > > >  drivers/mfd/twl4030-irq.c   | 2 +-
> > > >  drivers/mfd/twl4030-power.c | 2 +-
> > > >  drivers/mfd/twl6030-irq.c   | 2 +-
> > > >  drivers/phy/phy-twl4030-usb.c   | 2 +-
> > > >  drivers/power/supply/twl4030_charger.c  | 2 +-
> > > >  drivers/pwm/pwm-twl-led.c   | 2 +-
> > > >  drivers/pwm/pwm-twl.c   | 2 +-
> > > >  drivers/regulator/twl-regulator.c   | 2 +-
> > > >  drivers/regulator/twl6030-regulator.c   | 2 +-
> > > >  drivers/rtc/rtc-twl.c   | 2 +-
> > > >  drivers/usb/phy/phy-twl6030-usb.c   | 2 +-
> > > >  drivers/video/backlight/pandora_bl.c| 2 +-
> > > >  drivers/watchdog/twl4030_wdt.c  | 2 +-
> > > >  include/linux/{i2c => mfd}/twl.h| 0
> > > >  sound/soc/codecs/twl4030.c  | 2 +-
> > > >  25 files changed, 26 insertions(+), 26 deletions(-)
> > > >  rename include/linux/{i2c => mfd}/twl.h (100%)
> > > 
> > > I didn't see this get applied yet, so just in case anyone was waiting
> > > for me (this is trivial, so I don't think there's a need):
> > 
> > You're not the last. :)
> 
> Given the triviality of the change for non-MFD subsystems, can we apply
> this for 4.14?

I can't apply anything without Acks for *all* of the subsystems above.

As you well know, it is the submitters responsibility to obtain them.

My suggestion would be to collect the Acks you've received up until
this point and identify which SS's are still lacking in change log
section of a RESEND.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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 v3 3/3] power: wm831x_power: Support USB charger current limit management

[Lee Jones]

On Tue, 25 Jul 2017, Baolin Wang wrote:

> 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.
> 
> Signed-off-by: Mark Brown <broo...@kernel.org>
> Signed-off-by: Baolin Wang <baolin.w...@linaro.org>
> ---
>  Documentation/devicetree/bindings/mfd/wm831x.txt |1 +

Acked-by: Lee Jones <lee.jo...@linaro.org>

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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 3/3] mfd: twl: move header file out of I2C realm

[Lee Jones]

On Thu, 06 Jul 2017, Thierry Reding wrote:

> On Mon, May 22, 2017 at 12:02:10AM +0200, Wolfram Sang wrote:
> > include/linux/i2c is not for client devices. Move the header file to a
> > more appropriate location.
> > 
> > Signed-off-by: Wolfram Sang <w...@the-dreams.de>
> > ---
> >  arch/arm/mach-omap2/common.h| 2 +-
> >  arch/arm/mach-omap2/omap_twl.c  | 2 +-
> >  drivers/gpio/gpio-twl4030.c | 2 +-
> >  drivers/iio/adc/twl4030-madc.c  | 2 +-
> >  drivers/iio/adc/twl6030-gpadc.c | 2 +-
> >  drivers/input/keyboard/twl4030_keypad.c | 2 +-
> >  drivers/input/misc/twl4030-pwrbutton.c  | 2 +-
> >  drivers/input/misc/twl4030-vibra.c  | 2 +-
> >  drivers/mfd/twl-core.c  | 6 +++---
> >  drivers/mfd/twl4030-audio.c | 2 +-
> >  drivers/mfd/twl4030-irq.c   | 2 +-
> >  drivers/mfd/twl4030-power.c | 2 +-
> >  drivers/mfd/twl6030-irq.c   | 2 +-
> >  drivers/phy/phy-twl4030-usb.c   | 2 +-
> >  drivers/power/supply/twl4030_charger.c  | 2 +-
> >  drivers/pwm/pwm-twl-led.c   | 2 +-
> >  drivers/pwm/pwm-twl.c   | 2 +-
> >  drivers/regulator/twl-regulator.c   | 2 +-
> >  drivers/regulator/twl6030-regulator.c   | 2 +-
> >  drivers/rtc/rtc-twl.c   | 2 +-
> >  drivers/usb/phy/phy-twl6030-usb.c   | 2 +-
> >  drivers/video/backlight/pandora_bl.c| 2 +-
> >  drivers/watchdog/twl4030_wdt.c  | 2 +-
> >  include/linux/{i2c => mfd}/twl.h| 0
> >  sound/soc/codecs/twl4030.c  | 2 +-
> >  25 files changed, 26 insertions(+), 26 deletions(-)
> >  rename include/linux/{i2c => mfd}/twl.h (100%)
> 
> I didn't see this get applied yet, so just in case anyone was waiting
> for me (this is trivial, so I don't think there's a need):

You're not the last. :)

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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

[GIT PULL] Immutable branch between MFD and X86 due for the v4.13 merge window

[Lee Jones]

Enjoy!

The following changes since commit 2ea659a9ef488125eb46da6eb571de5eae5c43f6:

  Linux 4.12-rc1 (2017-05-13 13:19:49 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git ib-mfd-x86-v4.13

for you to fetch changes up to 94d68594a7b4fd2eec457f22110de644e1c4ee57:

  platform/x86: intel_bxtwc_tmu: Remove first level IRQ unmask (2017-06-19 
15:45:30 +0100)


Immutable branch between MFD and X86 due for the v4.13 merge window


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(-)

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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 2/3] mfd: tps65010: move header file out of I2C realm

[Lee Jones]

On Mon, 22 May 2017, Wolfram Sang wrote:

> include/linux/i2c is not for client devices. Move the header file to a
> more appropriate location.
> 
> Signed-off-by: Wolfram Sang <w...@the-dreams.de>
> ---
>  arch/arm/mach-omap1/board-h2-mmc.c  | 2 +-
>  arch/arm/mach-omap1/board-h2.c  | 2 +-
>  arch/arm/mach-omap1/board-h3-mmc.c  | 2 +-
>  arch/arm/mach-omap1/board-h3.c  | 2 +-
>  arch/arm/mach-omap1/board-osk.c | 2 +-
>  arch/arm/mach-s3c24xx/mach-osiris-dvs.c | 2 +-
>  arch/arm/mach-s3c24xx/mach-osiris.c | 2 +-

>  drivers/mfd/tps65010.c  | 2 +-

For my own reference:
  Acked-for-MFD-by: Lee Jones <lee.jo...@linaro.org>
  
>  drivers/usb/host/ohci-omap.c| 2 +-
>  drivers/usb/phy/phy-isp1301-omap.c  | 2 +-
>  drivers/video/fbdev/omap/lcd_h3.c   | 2 +-
>  include/linux/{i2c => mfd}/tps65010.h   | 2 +-
>  12 files changed, 12 insertions(+), 12 deletions(-)
>  rename include/linux/{i2c => mfd}/tps65010.h (99%)
> 
> diff --git a/arch/arm/mach-omap1/board-h2-mmc.c 
> b/arch/arm/mach-omap1/board-h2-mmc.c
> index 357be2debc9da8..91bda9c802ff38 100644
> --- a/arch/arm/mach-omap1/board-h2-mmc.c
> +++ b/arch/arm/mach-omap1/board-h2-mmc.c
> @@ -14,7 +14,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>  
>  #include "board-h2.h"
>  #include "mmc.h"
> diff --git a/arch/arm/mach-omap1/board-h2.c b/arch/arm/mach-omap1/board-h2.c
> index 675254ee4b1e93..dece47d76282ac 100644
> --- a/arch/arm/mach-omap1/board-h2.c
> +++ b/arch/arm/mach-omap1/board-h2.c
> @@ -28,7 +28,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>  #include 
>  #include 
>  #include 
> diff --git a/arch/arm/mach-omap1/board-h3-mmc.c 
> b/arch/arm/mach-omap1/board-h3-mmc.c
> index 4f58bfa5e7549e..692c267a9a9052 100644
> --- a/arch/arm/mach-omap1/board-h3-mmc.c
> +++ b/arch/arm/mach-omap1/board-h3-mmc.c
> @@ -14,7 +14,7 @@
>  #include 
>  #include 
>  
> -#include 
> +#include 
>  
>  #include "common.h"
>  #include "board-h3.h"
> diff --git a/arch/arm/mach-omap1/board-h3.c b/arch/arm/mach-omap1/board-h3.c
> index e62f9d454f1005..6d32beeb2d8857 100644
> --- a/arch/arm/mach-omap1/board-h3.c
> +++ b/arch/arm/mach-omap1/board-h3.c
> @@ -28,7 +28,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>  #include 
>  #include 
>  #include 
> diff --git a/arch/arm/mach-omap1/board-osk.c b/arch/arm/mach-omap1/board-osk.c
> index 4dfb995048103b..f20361b8ffb6e0 100644
> --- a/arch/arm/mach-omap1/board-osk.c
> +++ b/arch/arm/mach-omap1/board-osk.c
> @@ -38,7 +38,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>  #include 
>  #include 
>  
> diff --git a/arch/arm/mach-s3c24xx/mach-osiris-dvs.c 
> b/arch/arm/mach-s3c24xx/mach-osiris-dvs.c
> index 262ab07447483a..6cac7da15e2b0d 100644
> --- a/arch/arm/mach-s3c24xx/mach-osiris-dvs.c
> +++ b/arch/arm/mach-s3c24xx/mach-osiris-dvs.c
> @@ -17,7 +17,7 @@
>  #include 
>  #include 
>  
> -#include 
> +#include 
>  
>  #include 
>  #include 
> diff --git a/arch/arm/mach-s3c24xx/mach-osiris.c 
> b/arch/arm/mach-s3c24xx/mach-osiris.c
> index 70b0eb7d31347f..64b1a0b7b803a1 100644
> --- a/arch/arm/mach-s3c24xx/mach-osiris.c
> +++ b/arch/arm/mach-s3c24xx/mach-osiris.c
> @@ -24,7 +24,7 @@
>  #include 
>  #include 
>  
> -#include 
> +#include 
>  
>  #include 
>  #include 
> diff --git a/drivers/mfd/tps65010.c b/drivers/mfd/tps65010.c
> index d829a6131f09e5..2ab67386b4ef1e 100644
> --- a/drivers/mfd/tps65010.c
> +++ b/drivers/mfd/tps65010.c
> @@ -32,7 +32,7 @@
>  #include 
>  #include 
>  
> -#include 
> +#include 
>  
>  #include 
>  
> diff --git a/drivers/usb/host/ohci-omap.c b/drivers/usb/host/ohci-omap.c
> index a4d814b7f38066..91393ec7d8503c 100644
> --- a/drivers/usb/host/ohci-omap.c
> +++ b/drivers/usb/host/ohci-omap.c
> @@ -53,7 +53,7 @@
>  #define DRIVER_DESC "OHCI OMAP driver"
>  
>  #ifdef CONFIG_TPS65010
> -#include 
> +#include 
>  #else
>  
>  #define LOW  0
> diff --git a/drivers/usb/phy/phy-isp1301-omap.c 
> b/drivers/usb/phy/phy-isp1301-omap.c
> index 042c5a8fd423d8..c6052c814bcc24 100644
> --- a/drivers/usb/phy/phy-isp1301-omap.c
> +++ b/drivers/usb/phy/phy-isp1301-omap.c
> @@ -96,7 +96,7 @@ struct isp1301 {
>  
>  #if IS_REACHABLE(CONFIG_TPS65010)
>  
> -#include 
> +#include 
>  
>  #else
>  
> diff --git a/drivers/video/fbdev/omap/lcd_h3.c 
> b/drivers/video/fbdev/omap/lcd_h3.c
> index 9d2da146813ef0..796f4634c4c6f1 100644
>

Re: [PATCH 3/3] mfd: twl: move header file out of I2C realm

[Lee Jones]

On Mon, 22 May 2017, Wolfram Sang wrote:

> include/linux/i2c is not for client devices. Move the header file to a
> more appropriate location.
> 
> Signed-off-by: Wolfram Sang <w...@the-dreams.de>
> ---
>  arch/arm/mach-omap2/common.h| 2 +-
>  arch/arm/mach-omap2/omap_twl.c  | 2 +-
>  drivers/gpio/gpio-twl4030.c | 2 +-
>  drivers/iio/adc/twl4030-madc.c  | 2 +-
>  drivers/iio/adc/twl6030-gpadc.c | 2 +-
>  drivers/input/keyboard/twl4030_keypad.c | 2 +-
>  drivers/input/misc/twl4030-pwrbutton.c  | 2 +-
>  drivers/input/misc/twl4030-vibra.c  | 2 +-

>  drivers/mfd/twl-core.c  | 6 +++---
>  drivers/mfd/twl4030-audio.c | 2 +-
>  drivers/mfd/twl4030-irq.c   | 2 +-
>  drivers/mfd/twl4030-power.c | 2 +-
>  drivers/mfd/twl6030-irq.c   | 2 +-

For my own reference:
  Acked-for-MFD-by: Lee Jones <lee.jo...@linaro.org>

I guess this will be going through the MFD tree?

>  drivers/phy/phy-twl4030-usb.c   | 2 +-
>  drivers/power/supply/twl4030_charger.c  | 2 +-
>  drivers/pwm/pwm-twl-led.c   | 2 +-
>  drivers/pwm/pwm-twl.c   | 2 +-
>  drivers/regulator/twl-regulator.c   | 2 +-
>  drivers/regulator/twl6030-regulator.c   | 2 +-
>  drivers/rtc/rtc-twl.c   | 2 +-
>  drivers/usb/phy/phy-twl6030-usb.c   | 2 +-
>  drivers/video/backlight/pandora_bl.c| 2 +-
>  drivers/watchdog/twl4030_wdt.c  | 2 +-
>  include/linux/{i2c => mfd}/twl.h| 0
>  sound/soc/codecs/twl4030.c  | 2 +-
>  25 files changed, 26 insertions(+), 26 deletions(-)
>  rename include/linux/{i2c => mfd}/twl.h (100%)
> 
> diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
> index 8cc6338fcb1288..b5ad7fcb80ed24 100644
> --- a/arch/arm/mach-omap2/common.h
> +++ b/arch/arm/mach-omap2/common.h
> @@ -29,7 +29,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>  #include 
>  #include 
>  #include 
> diff --git a/arch/arm/mach-omap2/omap_twl.c b/arch/arm/mach-omap2/omap_twl.c
> index 1346b3ab34a5e3..295124b248ae3f 100644
> --- a/arch/arm/mach-omap2/omap_twl.c
> +++ b/arch/arm/mach-omap2/omap_twl.c
> @@ -16,7 +16,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>  
>  #include "soc.h"
>  #include "voltage.h"
> diff --git a/drivers/gpio/gpio-twl4030.c b/drivers/gpio/gpio-twl4030.c
> index 24f388ed46d4c4..9b511df5450eb6 100644
> --- a/drivers/gpio/gpio-twl4030.c
> +++ b/drivers/gpio/gpio-twl4030.c
> @@ -35,7 +35,7 @@
>  #include 
>  #include 
>  
> -#include 
> +#include 
>  
>  /*
>   * The GPIO "subchip" supports 18 GPIOs which can be configured as
> diff --git a/drivers/iio/adc/twl4030-madc.c b/drivers/iio/adc/twl4030-madc.c
> index 0c74869a540ad3..5a64eda1652061 100644
> --- a/drivers/iio/adc/twl4030-madc.c
> +++ b/drivers/iio/adc/twl4030-madc.c
> @@ -35,7 +35,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>  #include 
>  #include 
>  #include 
> diff --git a/drivers/iio/adc/twl6030-gpadc.c b/drivers/iio/adc/twl6030-gpadc.c
> index becbb0aef232b9..bc0e60b9da452e 100644
> --- a/drivers/iio/adc/twl6030-gpadc.c
> +++ b/drivers/iio/adc/twl6030-gpadc.c
> @@ -33,7 +33,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>  #include 
>  #include 
>  
> diff --git a/drivers/input/keyboard/twl4030_keypad.c 
> b/drivers/input/keyboard/twl4030_keypad.c
> index 39e72b3219d8a4..f9f98ef1d98e3f 100644
> --- a/drivers/input/keyboard/twl4030_keypad.c
> +++ b/drivers/input/keyboard/twl4030_keypad.c
> @@ -30,7 +30,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>  #include 
>  #include 
>  
> diff --git a/drivers/input/misc/twl4030-pwrbutton.c 
> b/drivers/input/misc/twl4030-pwrbutton.c
> index 1c13005b228fa7..b307cca1702226 100644
> --- a/drivers/input/misc/twl4030-pwrbutton.c
> +++ b/drivers/input/misc/twl4030-pwrbutton.c
> @@ -27,7 +27,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>  
>  #define PWR_PWRON_IRQ (1 << 0)
>  
> diff --git a/drivers/input/misc/twl4030-vibra.c 
> b/drivers/input/misc/twl4030-vibra.c
> index caa5a62c42fbe0..6c51d404874bbd 100644
> --- a/drivers/input/misc/twl4030-vibra.c
> +++ b/drivers/input/misc/twl4030-vibra.c
> @@ -28,7 +28,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>  #include 
>  #include 
>  #include 
> diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c
> index c64615dca2bd33..2a09dde4ca6ef

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

[Lee Jones]

On Tue, 14 Mar 2017, Baolin Wang wrote:

> Hi,
> 
> On 14 March 2017 at 17:57, Lee Jones <lee.jo...@linaro.org> wrote:
> > On Mon, 20 Feb 2017, Baolin Wang wrote:
> >
> > [...]
> >
> >>  drivers/power/supply/wm831x_power.c |   63 +++
> >>  drivers/usb/gadget/Kconfig  |8 +
> >>  drivers/usb/gadget/udc/Makefile |1 +
> >>  drivers/usb/gadget/udc/charger.c|  865 
> >> +++
> >>  drivers/usb/gadget/udc/core.c   |   19 +-
> >>  include/linux/usb/charger.h |  176 +++
> >>  include/linux/usb/gadget.h  |3 +
> >>  include/uapi/linux/usb/charger.h|   31 ++
> >>  8 files changed, 1165 insertions(+), 1 deletion(-)
> >>  create mode 100644 drivers/usb/gadget/udc/charger.c
> >>  create mode 100644 include/linux/usb/charger.h
> >>  create mode 100644 include/uapi/linux/usb/charger.h
> >
> > Why have you sent this set to me?
> 
> Since you have one ack on patch 4, I think I need CC you. But If you
> are not interested in this patchset, I will not CC you next time.
> Sorry.

I Acked one of the patches 9 months ago since it contained an MFD
change.

Yes, if you could drop me from any new submissions, that'd be great,
thanks.

> [PATCH v19 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.
> 
> Signed-off-by: Mark Brown <broo...@kernel.org>
> Signed-off-by: Baolin Wang <baolin.w...@linaro.org>
> Acked-by: Lee Jones <lee.jo...@linaro.org>
> Acked-by: Charles Keepax <ckee...@opensource.wolfsonmicro.com>
> Acked-by: Peter Chen <peter.c...@freescale.com>
> Acked-by: Sebastian Reichel <s...@kernel.org>
> ...
> 

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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 v19 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

[Lee Jones]

On Mon, 20 Feb 2017, Baolin Wang wrote:

[...]

>  drivers/power/supply/wm831x_power.c |   63 +++
>  drivers/usb/gadget/Kconfig  |8 +
>  drivers/usb/gadget/udc/Makefile |1 +
>  drivers/usb/gadget/udc/charger.c|  865 
> +++
>  drivers/usb/gadget/udc/core.c   |   19 +-
>  include/linux/usb/charger.h |  176 +++
>  include/linux/usb/gadget.h  |3 +
>  include/uapi/linux/usb/charger.h|   31 ++
>  8 files changed, 1165 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/usb/gadget/udc/charger.c
>  create mode 100644 include/linux/usb/charger.h
>  create mode 100644 include/uapi/linux/usb/charger.h

Why have you sent this set to me?

Please be careful when submitting patches, since a lot of us have
enough mail to contend with already.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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] USB: serial: cp210x: Add ID for a Juniper console

[Kyle Jones]

Signed-off-by: Kyle Jones <k...@kf5jwc.us>
---
Bus 004 Device 002: ID 10c4:8470 Cygnal Integrated Products, Inc.
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   1.10
  bDeviceClass0
  bDeviceSubClass 0
  bDeviceProtocol 0
  bMaxPacketSize064
  idVendor   0x10c4 Cygnal Integrated Products, Inc.
  idProduct  0x8470
  bcdDevice1.01
  iManufacturer   1 Silicon Labs
  iProduct2 Juniper Networks BX Series System Console
  iSerial 3
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength   32
bNumInterfaces  1
bConfigurationValue 1
iConfiguration  0
bmAttributes 0xc0
  Self Powered
MaxPower   50mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   2
  bInterfaceClass   255 Vendor Specific Class
  bInterfaceSubClass  0
  bInterfaceProtocol  0
  iInterface  2 Juniper Networks BX Series System Console
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81  EP 1 IN
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0040  1x 64 bytes
bInterval   0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01  EP 1 OUT
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0040  1x 64 bytes
bInterval   0
---
 drivers/usb/serial/cp210x.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/usb/serial/cp210x.c b/drivers/usb/serial/cp210x.c
index 4d6a5c6..54a4de0 100644
--- a/drivers/usb/serial/cp210x.c
+++ b/drivers/usb/serial/cp210x.c
@@ -118,6 +118,7 @@ static const struct usb_device_id id_table[] = {
{ USB_DEVICE(0x10C4, 0x8411) }, /* Kyocera GPS Module */
{ USB_DEVICE(0x10C4, 0x8418) }, /* IRZ Automation Teleport SG-10 
GSM/GPRS Modem */
{ USB_DEVICE(0x10C4, 0x846E) }, /* BEI USB Sensor Interface (VCP) */
+   { USB_DEVICE(0x10C4, 0x8470) }, /* Juniper Networks BX Series System 
Console */
{ USB_DEVICE(0x10C4, 0x8477) }, /* Balluff RFID */
{ USB_DEVICE(0x10C4, 0x84B6) }, /* Starizona Hyperion */
{ USB_DEVICE(0x10C4, 0x85EA) }, /* AC-Services IBUS-IF */
-- 
2.10.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

Re: [PATCH 1/1] mfd: rtsx_usb: avoid setting ucr->current_sg.status

[Lee Jones]

On Thu, 11 Aug 2016, Lu Baolu wrote:

> Member "status" of struct usb_sg_request is managed by usb core. A
> spin lock is used to serialize the change of it. The driver could
> check the value of req->status, but should avoid changing it without
> the hold of the spinlock. Otherwise, it could cause race or error
> in usb core.
> 
> This patch could be backported to stable kernels with version later
> than v3.14.
> 
> Cc: sta...@vger.kernel.org # 3.14+
> Cc: Alan Stern <st...@rowland.harvard.edu>
> Cc: Roger Tseng <rogera...@realtek.com>
> Signed-off-by: Lu Baolu <baolu...@linux.intel.com>
> ---
>  drivers/mfd/rtsx_usb.c | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)

Applied, thanks.

> diff --git a/drivers/mfd/rtsx_usb.c b/drivers/mfd/rtsx_usb.c
> index dbd907d..691dab7 100644
> --- a/drivers/mfd/rtsx_usb.c
> +++ b/drivers/mfd/rtsx_usb.c
> @@ -46,9 +46,6 @@ static void rtsx_usb_sg_timed_out(unsigned long data)
>  
>   dev_dbg(>pusb_intf->dev, "%s: sg transfer timed out", __func__);
>   usb_sg_cancel(>current_sg);
> -
> - /* we know the cancellation is caused by time-out */
> - ucr->current_sg.status = -ETIMEDOUT;
>  }
>  
>  static int rtsx_usb_bulk_transfer_sglist(struct rtsx_ucr *ucr,
> @@ -67,12 +64,15 @@ static int rtsx_usb_bulk_transfer_sglist(struct rtsx_ucr 
> *ucr,
>   ucr->sg_timer.expires = jiffies + msecs_to_jiffies(timeout);
>   add_timer(>sg_timer);
>   usb_sg_wait(>current_sg);
> - del_timer_sync(>sg_timer);
> + if (!del_timer_sync(>sg_timer))
> + ret = -ETIMEDOUT;
> + else
> + ret = ucr->current_sg.status;
>  
>   if (act_len)
>   *act_len = ucr->current_sg.bytes;
>  
> - return ucr->current_sg.status;
> + return ret;
>  }
>  
>  int rtsx_usb_transfer_data(struct rtsx_ucr *ucr, unsigned int pipe,

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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: [PATCHv6 3/3] mfd: intel_soc_pmic_bxtwc: add support for USB Type-C PHY on WhiskeyCove

[Lee Jones]

On Tue, 30 Aug 2016, Lee Jones wrote:

> On Mon, 29 Aug 2016, Heikki Krogerus wrote:
> 
> > Intel WhiskeyCove PMIC has also a USB Type-C PHY, so let's
> > create a device for it.
> > 
> > Signed-off-by: Heikki Krogerus <heikki.kroge...@linux.intel.com>
> > Cc: Lee Jones <lee.jo...@linaro.org>
> > ---
> >  drivers/mfd/intel_soc_pmic_bxtwc.c | 11 +++
> >  1 file changed, 11 insertions(+)
> 
> Applied, thanks.

This patch conflicts with ...

 "mfd: intel_soc_pmic_bxtwc: Add bxt_wcove_usbc device"

Please re-base your changes on my tree (or -next) and resubmit if this
change is still relevant.

> > diff --git a/drivers/mfd/intel_soc_pmic_bxtwc.c 
> > b/drivers/mfd/intel_soc_pmic_bxtwc.c
> > index b942876..0e61dde 100644
> > --- a/drivers/mfd/intel_soc_pmic_bxtwc.c
> > +++ b/drivers/mfd/intel_soc_pmic_bxtwc.c
> > @@ -84,6 +84,7 @@ enum bxtwc_irqs_level2 {
> > BXTWC_THRM2_IRQ,
> > BXTWC_BCU_IRQ,
> > BXTWC_ADC_IRQ,
> > +   BXTWC_USBC_IRQ,
> > BXTWC_CHGR0_IRQ,
> > BXTWC_CHGR1_IRQ,
> > BXTWC_GPIO0_IRQ,
> > @@ -109,6 +110,7 @@ static const struct regmap_irq 
> > bxtwc_regmap_irqs_level2[] = {
> > 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),
> > @@ -143,6 +145,10 @@ static struct resource adc_resources[] = {
> > DEFINE_RES_IRQ_NAMED(BXTWC_ADC_IRQ, "ADC"),
> >  };
> >  
> > +static struct resource usbc_resources[] = {
> > +   DEFINE_RES_IRQ(BXTWC_USBC_IRQ),
> > +};
> > +
> >  static struct resource charger_resources[] = {
> > DEFINE_RES_IRQ_NAMED(BXTWC_CHGR0_IRQ, "CHARGER"),
> > DEFINE_RES_IRQ_NAMED(BXTWC_CHGR1_IRQ, "CHARGER1"),
> > @@ -170,6 +176,11 @@ static struct mfd_cell bxt_wc_dev[] = {
> > .resources = thermal_resources,
> > },
> > {
> > +   .name = "bxt_wcove_usbc",
> > +   .num_resources = ARRAY_SIZE(usbc_resources),
> > +   .resources = usbc_resources,
> > +   },
> > +   {
> > .name = "bxt_wcove_ext_charger",
> > .num_resources = ARRAY_SIZE(charger_resources),
> > .resources = charger_resources,
> 

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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: [PATCHv6 3/3] mfd: intel_soc_pmic_bxtwc: add support for USB Type-C PHY on WhiskeyCove

[Lee Jones]

On Mon, 29 Aug 2016, Heikki Krogerus wrote:

> Intel WhiskeyCove PMIC has also a USB Type-C PHY, so let's
> create a device for it.
> 
> Signed-off-by: Heikki Krogerus <heikki.kroge...@linux.intel.com>
> Cc: Lee Jones <lee.jo...@linaro.org>
> ---
>  drivers/mfd/intel_soc_pmic_bxtwc.c | 11 +++
>  1 file changed, 11 insertions(+)

Applied, thanks.

> diff --git a/drivers/mfd/intel_soc_pmic_bxtwc.c 
> b/drivers/mfd/intel_soc_pmic_bxtwc.c
> index b942876..0e61dde 100644
> --- a/drivers/mfd/intel_soc_pmic_bxtwc.c
> +++ b/drivers/mfd/intel_soc_pmic_bxtwc.c
> @@ -84,6 +84,7 @@ enum bxtwc_irqs_level2 {
>   BXTWC_THRM2_IRQ,
>   BXTWC_BCU_IRQ,
>   BXTWC_ADC_IRQ,
> + BXTWC_USBC_IRQ,
>   BXTWC_CHGR0_IRQ,
>   BXTWC_CHGR1_IRQ,
>   BXTWC_GPIO0_IRQ,
> @@ -109,6 +110,7 @@ static const struct regmap_irq bxtwc_regmap_irqs_level2[] 
> = {
>   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),
> @@ -143,6 +145,10 @@ static struct resource adc_resources[] = {
>   DEFINE_RES_IRQ_NAMED(BXTWC_ADC_IRQ, "ADC"),
>  };
>  
> +static struct resource usbc_resources[] = {
> + DEFINE_RES_IRQ(BXTWC_USBC_IRQ),
> +};
> +
>  static struct resource charger_resources[] = {
>   DEFINE_RES_IRQ_NAMED(BXTWC_CHGR0_IRQ, "CHARGER"),
>   DEFINE_RES_IRQ_NAMED(BXTWC_CHGR1_IRQ, "CHARGER1"),
> @@ -170,6 +176,11 @@ static struct mfd_cell bxt_wc_dev[] = {
>   .resources = thermal_resources,
>   },
>   {
> + .name = "bxt_wcove_usbc",
> + .num_resources = ARRAY_SIZE(usbc_resources),
> + .resources = usbc_resources,
> + },
> + {
>   .name = "bxt_wcove_ext_charger",
>   .num_resources = ARRAY_SIZE(charger_resources),
>   .resources = charger_resources,

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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 1/2] mfd: ti-smusbdig: Add support for the TI SM-USB-DIG

[Lee Jones]

On Tue, 16 Aug 2016, Andrew F. Davis wrote:

> On 08/09/2016 10:27 AM, Lee Jones wrote:
> > On Tue, 09 Aug 2016, Andrew F. Davis wrote:
> > 
> >> The TI SM-USB-DIG is a USB to SPI/I2C/1Wire/GPIO adapter.
> >> Add MFD core support.
> >>
> >> Signed-off-by: Andrew F. Davis <a...@ti.com>
> >> ---
> >>  drivers/mfd/Kconfig |   9 +++
> >>  drivers/mfd/Makefile|   2 +
> >>  drivers/mfd/ti-smusbdig.c   | 138 
> >> 
> >>  include/linux/mfd/ti-smusbdig.h |  75 ++
> >>  4 files changed, 224 insertions(+)
> >>  create mode 100644 drivers/mfd/ti-smusbdig.c
> >>  create mode 100644 include/linux/mfd/ti-smusbdig.h
> > 
> > Still requires a DT Ack.
> > 
> > Please ping the relevant guys.
> > 
> 
> This driver doesn't touch DT.
> 
> If you meant USB, could you give me a hint as to who needs to ack
> drivers that communicate over USB?

Ah yes, my bad.  I was on auto-pilot, since that's what I usually find
myself asking for.

W.R.T. the USB Ack, Johan (now CC'ed) has been pretty helpful in the
past.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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 1/2] mfd: ti-smusbdig: Add support for the TI SM-USB-DIG

[Lee Jones]

On Tue, 09 Aug 2016, Andrew F. Davis wrote:

> The TI SM-USB-DIG is a USB to SPI/I2C/1Wire/GPIO adapter.
> Add MFD core support.
> 
> Signed-off-by: Andrew F. Davis <a...@ti.com>
> ---
>  drivers/mfd/Kconfig |   9 +++
>  drivers/mfd/Makefile|   2 +
>  drivers/mfd/ti-smusbdig.c   | 138 
> 
>  include/linux/mfd/ti-smusbdig.h |  75 ++
>  4 files changed, 224 insertions(+)
>  create mode 100644 drivers/mfd/ti-smusbdig.c
>  create mode 100644 include/linux/mfd/ti-smusbdig.h

Still requires a DT Ack.

Please ping the relevant guys.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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 4/7] reset: Supply *_shared variant calls when using *_optional APIs

[Lee Jones]

On Wed, 29 Jun 2016, Philipp Zabel wrote:

> Am Mittwoch, den 29.06.2016, 09:06 +0100 schrieb Lee Jones:
> > On Wed, 29 Jun 2016, Philipp Zabel wrote:
> > > Am Dienstag, den 28.06.2016, 09:56 +0100 schrieb Lee Jones:
> > > > Philipp,
> > > > 
> > > > I need this to go into the -rcs too.
> > > > 
> > > > Can I add it with your Ack please?
> > > 
> > > I have already added your patches to my branch, and I intend to send a
> > > pull request for it tomorrow. I am afraid applying this patch in another
> > > branch would create a merge conflict with
> > > git://git.pengutronix.de/git/pza/linux.git reset/next
> > > in arm-soc. If that is not the case, go ahead. Otherwise I could provide
> > > a tag at commit 2485394d9e0b ("reset: TRIVIAL: Add line break at same
> > > place for similar APIs") for you to merge.
> > 
> > Yes please.  If you could tag a branch containing commit:
> > 
> >   reset: Supply *_shared variant calls when using *_optional APIs
> > 
> > ... that would be perfect.  Would you mind sending me the tag name
> > ASAP please, since I am ready to send my pull-request to Linus.
> 
> git://git.pengutronix.de/git/pza/linux.git tags/reset-shared-optional

Ah!  If I rebase on that tag, I will also take in all of the patches
between it and v4.7-rc1, which is 14 commits.  Is there any way you
can place it onto it's own branch, then we both merge it into our
respective trees?

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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 4/7] reset: Supply *_shared variant calls when using *_optional APIs

[Lee Jones]

On Wed, 29 Jun 2016, Philipp Zabel wrote:
> Am Dienstag, den 28.06.2016, 09:56 +0100 schrieb Lee Jones:
> > Philipp,
> > 
> > I need this to go into the -rcs too.
> > 
> > Can I add it with your Ack please?
> 
> I have already added your patches to my branch, and I intend to send a
> pull request for it tomorrow. I am afraid applying this patch in another
> branch would create a merge conflict with
> git://git.pengutronix.de/git/pza/linux.git reset/next
> in arm-soc. If that is not the case, go ahead. Otherwise I could provide
> a tag at commit 2485394d9e0b ("reset: TRIVIAL: Add line break at same
> place for similar APIs") for you to merge.

Yes please.  If you could tag a branch containing commit:

  reset: Supply *_shared variant calls when using *_optional APIs

... that would be perfect.  Would you mind sending me the tag name
ASAP please, since I am ready to send my pull-request to Linus.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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 1/1] usb: dwc3: st: Inform the reset framework that our reset line may be shared

[Lee Jones]

On the STiH410 B2120 development board the MiPHY28lp shares its reset
line with the Synopsys DWC3 SuperSpeed (SS) USB 3.0 Dual-Role-Device
(DRD).  New functionality in the reset subsystems forces consumers to
be explicit when requesting shared/exclusive reset lines.

Signed-off-by: Lee Jones <lee.jo...@linaro.org>
---
Felipe,

I'd like to send this patch (amonst others) to the -rcs today if possible.

Would you be kind enough to Ack it, so I can do so please?

drivers/usb/dwc3/dwc3-st.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/dwc3/dwc3-st.c b/drivers/usb/dwc3/dwc3-st.c
index 5c0adb9..b204617 100644
--- a/drivers/usb/dwc3/dwc3-st.c
+++ b/drivers/usb/dwc3/dwc3-st.c
@@ -237,7 +237,8 @@ static int st_dwc3_probe(struct platform_device *pdev)
/* Manage PowerDown */
reset_control_deassert(dwc3_data->rstc_pwrdn);
 
-   dwc3_data->rstc_rst = devm_reset_control_get(dev, "softreset");
+   dwc3_data->rstc_rst =
+   devm_reset_control_get_shared(dev, "softreset");
if (IS_ERR(dwc3_data->rstc_rst)) {
dev_err(>dev, "could not get reset controller\n");
ret = PTR_ERR(dwc3_data->rstc_rst);
-- 
2.9.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

Re: [PATCH 4/7] reset: Supply *_shared variant calls when using *_optional APIs

[Lee Jones]

Philipp,

I need this to go into the -rcs too.

Can I add it with your Ack please?

> Consumers need to be able to specify whether they are requesting an
> 'exclusive' or 'shared' reset line no matter which API (of_*, devm_*,
> etc) they are using.  This change allows users of the optional_* API
> in particular to specify that their request is for a 'shared' line.
> 
> Signed-off-by: Lee Jones <lee.jo...@linaro.org>
> ---
>  include/linux/reset.h | 12 
>  1 file changed, 12 insertions(+)
> 
> diff --git a/include/linux/reset.h b/include/linux/reset.h
> index fd69240..c358106 100644
> --- a/include/linux/reset.h
> +++ b/include/linux/reset.h
> @@ -141,6 +141,12 @@ static inline struct reset_control 
> *reset_control_get_optional_exclusive(
>   return __of_reset_control_get(dev ? dev->of_node : NULL, id, 0, 0);
>  }
>  
> +static inline struct reset_control *reset_control_get_optional_shared(
> + struct device *dev, const char *id)
> +{
> + return __of_reset_control_get(dev ? dev->of_node : NULL, id, 0, 1);
> +}
> +
>  /**
>   * of_reset_control_get_exclusive - Lookup and obtain an exclusive reference
>   *  to a reset controller.
> @@ -270,6 +276,12 @@ static inline struct reset_control 
> *devm_reset_control_get_optional_exclusive(
>   return __devm_reset_control_get(dev, id, 0, 0);
>  }
>  
> +static inline struct reset_control *devm_reset_control_get_optional_shared(
> + struct device *dev, const char *id)
> +{
> + return __devm_reset_control_get(dev, id, 0, 1);
> +}
> +
>  /**
>   * devm_reset_control_get_exclusive_by_index - resource managed
>   * reset_control_get_exclusive()

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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 9/10] usb: host: ehci-st: Inform the reset framework that our reset line may be shared

[Lee Jones]

On Tue, 28 Jun 2016, Lee Jones wrote:

> On Mon, 06 Jun 2016, Alan Stern wrote:
> 
> > On Mon, 6 Jun 2016, Lee Jones wrote:
> > 
> > > On the STiH410 B2120 development board the ST EHCI IP shares its reset
> > > line with the OHCI IP.  New functionality in the reset subsystems forces
> > > consumers to be explicit when requesting shared/exclusive reset lines.
> > > 
> > > Signed-off-by: Lee Jones <lee.jo...@linaro.org>
> > 
> > For this andd the 10/10 patch:
> > 
> > Acked-by: Alan Stern <st...@rowland.harvard.edu>
> 
> Thanks Alan.
> 
> I'm going to take this (actually half of this patch -- the other half
> which is due for -next I will resubmit with your Ack) along with the
> other patches due for the -rcs though my MFD -next branch.

Sorry, ignore that.  I'm going to take the whole thing.  Just realised
that both APIs are the *_shared() variant in this patch.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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 6/7] phy: miphy28lp: Inform the reset framework that our reset line may be shared

[Lee Jones]

On Tue, 07 Jun 2016, Kishon Vijay Abraham I wrote:

> 
> 
> On Monday 06 June 2016 09:26 PM, Lee Jones wrote:
> > On the STiH410 B2120 development board the MiPHY28lp shares its reset
> > line with the Synopsys DWC3 SuperSpeed (SS) USB 3.0 Dual-Role-Device
> > (DRD).  New functionality in the reset subsystems forces consumers to
> > be explicit when requesting shared/exclusive reset lines.
> > 
> > Signed-off-by: Lee Jones <lee.jo...@linaro.org>
> 
> Acked-by: Kishon Vijay Abraham I <kis...@ti.com>

Thanks Kishon.  I'm going to add this to my MFD -fixes submission.

> > ---
> >  drivers/phy/phy-miphy28lp.c | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/phy/phy-miphy28lp.c b/drivers/phy/phy-miphy28lp.c
> > index 3acd2a1..213e2e1 100644
> > --- a/drivers/phy/phy-miphy28lp.c
> > +++ b/drivers/phy/phy-miphy28lp.c
> > @@ -1143,7 +1143,8 @@ static int miphy28lp_probe_resets(struct device_node 
> > *node,
> > struct miphy28lp_dev *miphy_dev = miphy_phy->phydev;
> > int err;
> >  
> > -   miphy_phy->miphy_rst = of_reset_control_get(node, "miphy-sw-rst");
> > +   miphy_phy->miphy_rst =
> > +   of_reset_control_get_shared(node, "miphy-sw-rst");
> >  
> > if (IS_ERR(miphy_phy->miphy_rst)) {
> > dev_err(miphy_dev->dev,
> > 

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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 v3 1/2] mfd: ti-smusbdig: Add support for the TI SM-USB-DIG

[Lee Jones]

On Wed, 15 Jun 2016, Andrew F. Davis wrote:

> On 06/15/2016 10:43 AM, Lee Jones wrote:
> > This requires a USB Ack.
> > 
> >> The TI SM-USB-DIG is a USB to SPI/I2C/1Wire/GPIO adapter.
> >> Add MFD core support.
> >>
> >> Signed-off-by: Andrew F. Davis <a...@ti.com>
> >> ---
> > 
> > Where is the change log from v1 => v2?
> > 
> 
> Looking at a diff of the two it looks like all the changes are related
> to your v1 feedback:
> 
>  - Rename sm-usb-dig -> ti-smusbdig
>  - Inline helper functions in header
>  - Alphabetize includes

Please ensure this is added when you submit subsequent sets.  It
really does help with the review and saves a great deal of time.

> >> Changes from v2:
> >>  - Add missing dependency on USB, thanks kbuild test robot
> >>
> >>  drivers/mfd/Kconfig |   9 +++
> >>  drivers/mfd/Makefile|   2 +
> >>  drivers/mfd/ti-smusbdig.c   | 138 
> >> 
> >>  include/linux/mfd/ti-smusbdig.h |  75 ++++++
> >>  4 files changed, 224 insertions(+)
> >>  create mode 100644 drivers/mfd/ti-smusbdig.c
> >>  create mode 100644 include/linux/mfd/ti-smusbdig.h
> > 

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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 v3 1/2] mfd: ti-smusbdig: Add support for the TI SM-USB-DIG

[Lee Jones]

This requires a USB Ack.

> The TI SM-USB-DIG is a USB to SPI/I2C/1Wire/GPIO adapter.
> Add MFD core support.
> 
> Signed-off-by: Andrew F. Davis <a...@ti.com>
> ---

Where is the change log from v1 => v2?

> Changes from v2:
>  - Add missing dependency on USB, thanks kbuild test robot
> 
>  drivers/mfd/Kconfig |   9 +++
>  drivers/mfd/Makefile|   2 +
>  drivers/mfd/ti-smusbdig.c   | 138 
> 
>  include/linux/mfd/ti-smusbdig.h |  75 ++
>  4 files changed, 224 insertions(+)
>  create mode 100644 drivers/mfd/ti-smusbdig.c
>  create mode 100644 include/linux/mfd/ti-smusbdig.h

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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: [RESEND PATCH v11 4/4] power: wm831x_power: Support USB charger current limit management

[Lee Jones]

On Mon, 13 Jun 2016, Baolin Wang wrote:

> 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.
> 
> Signed-off-by: Mark Brown <broo...@kernel.org>
> Signed-off-by: Baolin Wang <baolin.w...@linaro.org>
> Acked-by: Lee Jones <lee.jo...@linaro.org>
> Acked-by: Charles Keepax <ckee...@opensource.wolfsonmicro.com>
> Acked-by: Peter Chen <peter.c...@freescale.com>
> Acked-by: Sebastian Reichel <s...@kernel.org>
> ---
>  drivers/power/wm831x_power.c |   69 
> ++
>  include/linux/mfd/wm831x/pdata.h |3 ++

For the MFD change:
  Acked-by: Lee Jones <lee.jo...@linaro.org>
  
>  2 files changed, 72 insertions(+)
> 
> diff --git a/drivers/power/wm831x_power.c b/drivers/power/wm831x_power.c
> index 7082301..cef1812 100644
> --- a/drivers/power/wm831x_power.c
> +++ b/drivers/power/wm831x_power.c
> @@ -13,6 +13,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
> @@ -31,6 +32,8 @@ struct wm831x_power {
>   char usb_name[20];
>   char battery_name[20];
>   bool have_battery;
> + struct usb_charger *usb_charger;
> + struct notifier_block usb_notify;
>  };
>  
>  static int wm831x_power_check_online(struct wm831x *wm831x, int supply,
> @@ -125,6 +128,43 @@ static enum power_supply_property wm831x_usb_props[] = {
>   POWER_SUPPLY_PROP_VOLTAGE_NOW,
>  };
>  
> +/* In milliamps */
> +static const unsigned int wm831x_usb_limits[] = {
> + 0,
> + 2,
> + 100,
> + 500,
> + 900,
> + 1500,
> + 1800,
> + 550,
> +};
> +
> +static int wm831x_usb_limit_change(struct notifier_block *nb,
> +unsigned long limit, void *data)
> +{
> + struct wm831x_power *wm831x_power = container_of(nb,
> +  struct wm831x_power,
> +  usb_notify);
> + unsigned int i, best;
> +
> + /* Find the highest supported limit */
> + best = 0;
> + for (i = 0; i < ARRAY_SIZE(wm831x_usb_limits); i++) {
> + if (limit >= wm831x_usb_limits[i] &&
> + wm831x_usb_limits[best] < wm831x_usb_limits[i])
> + best = i;
> + }
> +
> + dev_dbg(wm831x_power->wm831x->dev,
> + "Limiting USB current to %umA", wm831x_usb_limits[best]);
> +
> + wm831x_set_bits(wm831x_power->wm831x, WM831X_POWER_STATE,
> + WM831X_USB_ILIM_MASK, best);
> +
> + return 0;
> +}
> +
>  /*
>   *   Battery properties
>   */
> @@ -607,8 +647,31 @@ static int wm831x_power_probe(struct platform_device 
> *pdev)
>   }
>   }
>  
> + if (wm831x_pdata && wm831x_pdata->usb_gadget) {
> + power->usb_charger =
> + usb_charger_find_by_name(wm831x_pdata->usb_gadget);
> + if (IS_ERR(power->usb_charger)) {
> + ret = PTR_ERR(power->usb_charger);
> + dev_err(>dev,
> + "Failed to find USB gadget: %d\n", ret);
> + goto err_bat_irq;
> + }
> +
> + power->usb_notify.notifier_call = wm831x_usb_limit_change;
> +
> + ret = usb_charger_register_notify(power->usb_charger,
> +   >usb_notify);
> + if (ret != 0) {
> + dev_err(>dev,
> + "Failed to register notifier: %d\n", ret);
> + goto err_usb_charger;
> + }
> + }
> +
>   return ret;
>  
> +err_usb_charger:
> + /* put_device on charger */
>  err_bat_irq:
>   --i;
>   for (; i >= 0; i--) {
> @@ -637,6 +700,12 @@ static int wm831x_power_remove(struct platform_device 
> *pdev)
>   struct wm831x *wm831x = wm831x_power->wm831x;
>   int irq, i;
>  
> + if (wm831x_power->usb_charger) {
> + usb_charger_unregister_notify(wm831x_power->usb_charger,
> +   _power->usb_notify);
> + /* Free charger */
> 

Re: [STLinux Kernel] [PATCH 0/7] reset: Consumers to explicitly request 'exclusive' or 'shared' lines

[Lee Jones]

On Tue, 07 Jun 2016, Lee Jones wrote:

> On Tue, 07 Jun 2016, Peter Griffin wrote:
> 
> > Hi,
> > 
> > On Mon, 06 Jun 2016, Lee Jones wrote:
> > 
> > > Phasing out generic reset line requests enables us to make some better
> > > decisions on when and how to (de)assert said lines.  If an 'exclusive'
> > > line is requested, we know a device *requires* a reset and that it's
> > > preferable to act upon a request right away.  However, if a 'shared'
> > > reset line is requested, we can reasonably assume sure that placing a
> > > device into reset isn't a hard requirement, but probably a measure to
> > > save power and is thus able to cope with not being asserted if another
> > > device is still in use.
> > > 
> > > In order allow gentle adoption and not to forcing all consumers to
> > > move to the API immediately, causing administration headache between
> > > subsystems, this patch adds some temporary stand-in shim-calls.  This
> > > will ease the burden at merge time and allow subsystems to migrate over
> > > to the new API in a more realistic time-frame.
> > 
> > Is the intention that this series will be taken into the next -rc?
> > 
> > As the introduction of shared resets in reset subsystem has caused 
> > regressions
> > on STi platforms.
> 
> Yes, which is why it has a Fixes: tag.

Ah wait.  I thought this was the shared-memory patch.

More haste, less speed and all that.

I guess it should really go into the -rcs, yes.  Since Hans' patch
actually breaks a lot of devices.  I'm pretty surprised a patch
capable of this much damage was actually accepted to be honest.  A
better approach would have been to issue a warning, but keep the
semantics the same for at least a couple of releases.  However, I
guess the damage has been done now, so let's do what we can do fix
it.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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: [STLinux Kernel] [PATCH 0/7] reset: Consumers to explicitly request 'exclusive' or 'shared' lines

[Lee Jones]

On Tue, 07 Jun 2016, Peter Griffin wrote:

> Hi,
> 
> On Mon, 06 Jun 2016, Lee Jones wrote:
> 
> > Phasing out generic reset line requests enables us to make some better
> > decisions on when and how to (de)assert said lines.  If an 'exclusive'
> > line is requested, we know a device *requires* a reset and that it's
> > preferable to act upon a request right away.  However, if a 'shared'
> > reset line is requested, we can reasonably assume sure that placing a
> > device into reset isn't a hard requirement, but probably a measure to
> > save power and is thus able to cope with not being asserted if another
> > device is still in use.
> > 
> > In order allow gentle adoption and not to forcing all consumers to
> > move to the API immediately, causing administration headache between
> > subsystems, this patch adds some temporary stand-in shim-calls.  This
> > will ease the burden at merge time and allow subsystems to migrate over
> > to the new API in a more realistic time-frame.
> 
> Is the intention that this series will be taken into the next -rc?
> 
> As the introduction of shared resets in reset subsystem has caused regressions
> on STi platforms.

Yes, which is why it has a Fixes: tag.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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 8/10] phy: phy-stih407-usb: Inform the reset framework that our reset line may be shared

[Lee Jones]

On the STiH410 B2120 development board the ports on the Generic PHY
share their reset lines with each other.  New functionality in the
reset subsystems forces consumers to be explicit when requesting
shared/exclusive reset lines.

Signed-off-by: Lee Jones <lee.jo...@linaro.org>
---
 drivers/phy/phy-stih407-usb.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/phy/phy-stih407-usb.c b/drivers/phy/phy-stih407-usb.c
index 1d5ae5f..b1f44ab 100644
--- a/drivers/phy/phy-stih407-usb.c
+++ b/drivers/phy/phy-stih407-usb.c
@@ -105,13 +105,13 @@ static int stih407_usb2_picophy_probe(struct 
platform_device *pdev)
phy_dev->dev = dev;
dev_set_drvdata(dev, phy_dev);
 
-   phy_dev->rstc = devm_reset_control_get(dev, "global");
+   phy_dev->rstc = devm_reset_control_get_shared(dev, "global");
if (IS_ERR(phy_dev->rstc)) {
dev_err(dev, "failed to ctrl picoPHY reset\n");
return PTR_ERR(phy_dev->rstc);
}
 
-   phy_dev->rstport = devm_reset_control_get(dev, "port");
+   phy_dev->rstport = devm_reset_control_get_exclusive(dev, "port");
if (IS_ERR(phy_dev->rstport)) {
dev_err(dev, "failed to ctrl picoPHY reset\n");
return PTR_ERR(phy_dev->rstport);
-- 
2.8.3

--
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 9/10] usb: host: ehci-st: Inform the reset framework that our reset line may be shared

[Lee Jones]

On the STiH410 B2120 development board the ST EHCI IP shares its reset
line with the OHCI IP.  New functionality in the reset subsystems forces
consumers to be explicit when requesting shared/exclusive reset lines.

Signed-off-by: Lee Jones <lee.jo...@linaro.org>
---
 drivers/usb/host/ehci-st.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/host/ehci-st.c b/drivers/usb/host/ehci-st.c
index a94ed67..6cfce6f 100644
--- a/drivers/usb/host/ehci-st.c
+++ b/drivers/usb/host/ehci-st.c
@@ -206,7 +206,7 @@ static int st_ehci_platform_probe(struct platform_device 
*dev)
priv->clk48 = NULL;
}
 
-   priv->pwr = devm_reset_control_get_optional(>dev, "power");
+   priv->pwr = devm_reset_control_get_optional_shared(>dev, "power");
if (IS_ERR(priv->pwr)) {
err = PTR_ERR(priv->pwr);
if (err == -EPROBE_DEFER)
@@ -214,7 +214,7 @@ static int st_ehci_platform_probe(struct platform_device 
*dev)
priv->pwr = NULL;
}
 
-   priv->rst = devm_reset_control_get_optional(>dev, "softreset");
+   priv->rst = devm_reset_control_get_optional_shared(>dev, 
"softreset");
if (IS_ERR(priv->rst)) {
err = PTR_ERR(priv->rst);
if (err == -EPROBE_DEFER)
-- 
2.8.3

--
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 10/10] usb: host: ohci-st: Inform the reset framework that our reset line may be shared

[Lee Jones]

On the STiH410 B2120 development board the ST EHCI IP shares its reset
line with the OHCI IP.  New functionality in the reset subsystems forces
consumers to be explicit when requesting shared/exclusive reset lines.

Signed-off-by: Lee Jones <lee.jo...@linaro.org>
---
 drivers/usb/host/ohci-st.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/host/ohci-st.c b/drivers/usb/host/ohci-st.c
index acf2eb2..1f1f23c 100644
--- a/drivers/usb/host/ohci-st.c
+++ b/drivers/usb/host/ohci-st.c
@@ -188,13 +188,13 @@ static int st_ohci_platform_probe(struct platform_device 
*dev)
priv->clk48 = NULL;
}
 
-   priv->pwr = devm_reset_control_get_optional(>dev, "power");
+   priv->pwr = devm_reset_control_get_optional_shared(>dev, "power");
if (IS_ERR(priv->pwr)) {
err = PTR_ERR(priv->pwr);
goto err_put_clks;
}
 
-   priv->rst = devm_reset_control_get_optional(>dev, "softreset");
+   priv->rst = devm_reset_control_get_optional_shared(>dev, 
"softreset");
if (IS_ERR(priv->rst)) {
err = PTR_ERR(priv->rst);
goto err_put_clks;
-- 
2.8.3

--
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 3/7] reset: Supply *_shared variant calls when using of_* API

[Lee Jones]

Consumers need to be able to specify whether they are requesting an
'exclusive' or 'shared' reset line no matter which API (of_*, devm_*,
etc) they are using.  This change allows users of the of_* API in
particular to specify that their request is for a 'shared' line.

Signed-off-by: Lee Jones <lee.jo...@linaro.org>
---
 include/linux/reset.h | 53 +++
 1 file changed, 53 insertions(+)

diff --git a/include/linux/reset.h b/include/linux/reset.h
index 9cf4cf3..fd69240 100644
--- a/include/linux/reset.h
+++ b/include/linux/reset.h
@@ -158,6 +158,31 @@ static inline struct reset_control 
*of_reset_control_get_exclusive(
 }
 
 /**
+ * of_reset_control_get_shared - Lookup and obtain an shared reference
+ *   to a reset controller.
+ * @node: device to be reset by the controller
+ * @id: reset line name
+ *
+ * When a reset-control is shared, the behavior of reset_control_assert /
+ * deassert is changed, the reset-core will keep track of a deassert_count
+ * and only (re-)assert the reset after reset_control_assert has been called
+ * as many times as reset_control_deassert was called. Also see the remark
+ * about shared reset-controls in the reset_control_assert docs.
+ *
+ * Calling reset_control_assert without first calling reset_control_deassert
+ * is not allowed on a shared reset control. Calling reset_control_reset is
+ * also not allowed on a shared reset control.
+ * Returns a struct reset_control or IS_ERR() condition containing errno.
+ *
+ * Use of id names is optional.
+ */
+static inline struct reset_control *of_reset_control_get_shared(
+   struct device_node *node, const char *id)
+{
+   return __of_reset_control_get(node, id, 0, 1);
+}
+
+/**
  * of_reset_control_get_exclusive_by_index - Lookup and obtain an exclusive
  *   reference to a reset controller
  *   by index.
@@ -175,6 +200,34 @@ static inline struct reset_control 
*of_reset_control_get_exclusive_by_index(
 }
 
 /**
+ * of_reset_control_get_shared_by_index - Lookup and obtain an shared
+ *reference to a reset controller
+ *by index.
+ * @node: device to be reset by the controller
+ * @index: index of the reset controller
+ *
+ * When a reset-control is shared, the behavior of reset_control_assert /
+ * deassert is changed, the reset-core will keep track of a deassert_count
+ * and only (re-)assert the reset after reset_control_assert has been called
+ * as many times as reset_control_deassert was called. Also see the remark
+ * about shared reset-controls in the reset_control_assert docs.
+ *
+ * Calling reset_control_assert without first calling reset_control_deassert
+ * is not allowed on a shared reset control. Calling reset_control_reset is
+ * also not allowed on a shared reset control.
+ * Returns a struct reset_control or IS_ERR() condition containing errno.
+ *
+ * This is to be used to perform a list of resets for a device or power domain
+ * in whatever order. Returns a struct reset_control or IS_ERR() condition
+ * containing errno.
+ */
+static inline struct reset_control *of_reset_control_get_shared_by_index(
+   struct device_node *node, int index)
+{
+   return __of_reset_control_get(node, NULL, index, 1);
+}
+
+/**
  * devm_reset_control_get_exclusive - resource managed
  *reset_control_get_exclusive()
  * @dev: device to be reset by the controller
-- 
2.8.3

--
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 1/7] reset: Reorder inline reset_control_get*() wrappers

[Lee Jones]

We're about to split the current API into two, where consumers will
be forced to be explicit when requesting reset lines.  The choice
will be to either the call the *_exclusive or *_shared variant
depending on whether they can actually tolorate not being asserted
when that request is made.

The new API will look like this once reorded and complete:

  reset_control_get_exclusive()
  reset_control_get_shared()
  reset_control_get_optional_exclusive()
  reset_control_get_optional_shared()
  of_reset_control_get_exclusive()
  of_reset_control_get_shared()
  of_reset_control_get_exclusive_by_index()
  of_reset_control_get_shared_by_index()
  devm_reset_control_get_exclusive()
  devm_reset_control_get_shared()
  devm_reset_control_get_optional_exclusive()
  devm_reset_control_get_optional_shared()
  devm_reset_control_get_exclusive_by_index()
  devm_reset_control_get_shared_by_index()

Signed-off-by: Lee Jones <lee.jo...@linaro.org>
---
 include/linux/reset.h | 42 +-
 1 file changed, 21 insertions(+), 21 deletions(-)

diff --git a/include/linux/reset.h b/include/linux/reset.h
index ec0306ce..33eaf11 100644
--- a/include/linux/reset.h
+++ b/include/linux/reset.h
@@ -107,12 +107,6 @@ static inline struct reset_control *__must_check 
reset_control_get(
return __of_reset_control_get(dev ? dev->of_node : NULL, id, 0, 0);
 }
 
-static inline struct reset_control *reset_control_get_optional(
-   struct device *dev, const char *id)
-{
-   return __of_reset_control_get(dev ? dev->of_node : NULL, id, 0, 0);
-}
-
 /**
  * reset_control_get_shared - Lookup and obtain a shared reference to a
  *reset controller.
@@ -141,6 +135,12 @@ static inline struct reset_control 
*reset_control_get_shared(
return __of_reset_control_get(dev ? dev->of_node : NULL, id, 0, 1);
 }
 
+static inline struct reset_control *reset_control_get_optional(
+   struct device *dev, const char *id)
+{
+   return __of_reset_control_get(dev ? dev->of_node : NULL, id, 0, 0);
+}
+
 /**
  * of_reset_control_get - Lookup and obtain an exclusive reference to a
  *reset controller.
@@ -191,6 +191,21 @@ static inline struct reset_control *__must_check 
devm_reset_control_get(
return __devm_reset_control_get(dev, id, 0, 0);
 }
 
+/**
+ * devm_reset_control_get_shared - resource managed reset_control_get_shared()
+ * @dev: device to be reset by the controller
+ * @id: reset line name
+ *
+ * Managed reset_control_get_shared(). For reset controllers returned from
+ * this function, reset_control_put() is called automatically on driver detach.
+ * See reset_control_get_shared() for more information.
+ */
+static inline struct reset_control *devm_reset_control_get_shared(
+   struct device *dev, const char *id)
+{
+   return __devm_reset_control_get(dev, id, 0, 1);
+}
+
 static inline struct reset_control *devm_reset_control_get_optional(
struct device *dev, const char *id)
 {
@@ -213,21 +228,6 @@ static inline struct reset_control 
*devm_reset_control_get_by_index(
 }
 
 /**
- * devm_reset_control_get_shared - resource managed reset_control_get_shared()
- * @dev: device to be reset by the controller
- * @id: reset line name
- *
- * Managed reset_control_get_shared(). For reset controllers returned from
- * this function, reset_control_put() is called automatically on driver detach.
- * See reset_control_get_shared() for more information.
- */
-static inline struct reset_control *devm_reset_control_get_shared(
-   struct device *dev, const char *id)
-{
-   return __devm_reset_control_get(dev, id, 0, 1);
-}
-
-/**
  * devm_reset_control_get_shared_by_index - resource managed
  * reset_control_get_shared
  * @dev: device to be reset by the controller
-- 
2.8.3

--
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 2/7] reset: Ensure drivers are explicit when requesting reset lines

[Lee Jones]

Phasing out generic reset line requests enables us to make some better
decisions on when and how to (de)assert said lines.  If an 'exclusive'
line is requested, we know a device *requires* a reset and that it's
preferable to act upon a request right away.  However, if a 'shared'
reset line is requested, we can reasonably assume sure that placing a
device into reset isn't a hard requirement, but probably a measure to
save power and is thus able to cope with not being asserted if another
device is still in use.

In order allow gentle adoption and not to forcing all consumers to
move to the API immediately, causing administration headache between
subsystems, this patch adds some temporary stand-in shim-calls.  This
will ease the burden at merge time and allow subsystems to migrate over
to the new API in a more realistic time-frame.

Signed-off-by: Lee Jones <lee.jo...@linaro.org>
---
 include/linux/reset.h | 106 ++
 1 file changed, 82 insertions(+), 24 deletions(-)

diff --git a/include/linux/reset.h b/include/linux/reset.h
index 33eaf11..9cf4cf3 100644
--- a/include/linux/reset.h
+++ b/include/linux/reset.h
@@ -84,8 +84,8 @@ static inline struct reset_control *__devm_reset_control_get(
 #endif /* CONFIG_RESET_CONTROLLER */
 
 /**
- * reset_control_get - Lookup and obtain an exclusive reference to a
- * reset controller.
+ * reset_control_get_exclusive - Lookup and obtain an exclusive reference
+ *   to a reset controller.
  * @dev: device to be reset by the controller
  * @id: reset line name
  *
@@ -98,8 +98,8 @@ static inline struct reset_control *__devm_reset_control_get(
  *
  * Use of id names is optional.
  */
-static inline struct reset_control *__must_check reset_control_get(
-   struct device *dev, const char *id)
+static inline struct reset_control *
+__must_check reset_control_get_exclusive(struct device *dev, const char *id)
 {
 #ifndef CONFIG_RESET_CONTROLLER
WARN_ON(1);
@@ -135,15 +135,15 @@ static inline struct reset_control 
*reset_control_get_shared(
return __of_reset_control_get(dev ? dev->of_node : NULL, id, 0, 1);
 }
 
-static inline struct reset_control *reset_control_get_optional(
+static inline struct reset_control *reset_control_get_optional_exclusive(
struct device *dev, const char *id)
 {
return __of_reset_control_get(dev ? dev->of_node : NULL, id, 0, 0);
 }
 
 /**
- * of_reset_control_get - Lookup and obtain an exclusive reference to a
- *reset controller.
+ * of_reset_control_get_exclusive - Lookup and obtain an exclusive reference
+ *  to a reset controller.
  * @node: device to be reset by the controller
  * @id: reset line name
  *
@@ -151,15 +151,16 @@ static inline struct reset_control 
*reset_control_get_optional(
  *
  * Use of id names is optional.
  */
-static inline struct reset_control *of_reset_control_get(
+static inline struct reset_control *of_reset_control_get_exclusive(
struct device_node *node, const char *id)
 {
return __of_reset_control_get(node, id, 0, 0);
 }
 
 /**
- * of_reset_control_get_by_index - Lookup and obtain an exclusive reference to
- * a reset controller by index.
+ * of_reset_control_get_exclusive_by_index - Lookup and obtain an exclusive
+ *   reference to a reset controller
+ *   by index.
  * @node: device to be reset by the controller
  * @index: index of the reset controller
  *
@@ -167,23 +168,27 @@ static inline struct reset_control *of_reset_control_get(
  * in whatever order. Returns a struct reset_control or IS_ERR() condition
  * containing errno.
  */
-static inline struct reset_control *of_reset_control_get_by_index(
+static inline struct reset_control *of_reset_control_get_exclusive_by_index(
struct device_node *node, int index)
 {
return __of_reset_control_get(node, NULL, index, 0);
 }
 
 /**
- * devm_reset_control_get - resource managed reset_control_get()
+ * devm_reset_control_get_exclusive - resource managed
+ *reset_control_get_exclusive()
  * @dev: device to be reset by the controller
  * @id: reset line name
  *
- * Managed reset_control_get(). For reset controllers returned from this
- * function, reset_control_put() is called automatically on driver detach.
- * See reset_control_get() for more information.
+ * Managed reset_control_get_exclusive(). For reset controllers returned
+ * from this function, reset_control_put() is called automatically on driver
+ * detach.
+ *
+ * See reset_control_get_exclusive() for more information.
  */
-static inline struct reset_control *__must_check devm_reset

[PATCH 7/7] usb: dwc3: st: Inform the reset framework that our reset line may be shared

[Lee Jones]

On the STiH410 B2120 development board the MiPHY28lp shares its reset
line with the Synopsys DWC3 SuperSpeed (SS) USB 3.0 Dual-Role-Device
(DRD).  New functionality in the reset subsystems forces consumers to
be explicit when requesting shared/exclusive reset lines.

Signed-off-by: Lee Jones <lee.jo...@linaro.org>
---
 drivers/usb/dwc3/dwc3-st.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/dwc3/dwc3-st.c b/drivers/usb/dwc3/dwc3-st.c
index 5c0adb9..e77bacb 100644
--- a/drivers/usb/dwc3/dwc3-st.c
+++ b/drivers/usb/dwc3/dwc3-st.c
@@ -227,7 +227,8 @@ static int st_dwc3_probe(struct platform_device *pdev)
dev_vdbg(>dev, "glue-logic addr 0x%p, syscfg-reg offset 0x%x\n",
 dwc3_data->glue_base, dwc3_data->syscfg_reg_off);
 
-   dwc3_data->rstc_pwrdn = devm_reset_control_get(dev, "powerdown");
+   dwc3_data->rstc_pwrdn =
+   devm_reset_control_get_exclusive(dev, "powerdown");
if (IS_ERR(dwc3_data->rstc_pwrdn)) {
dev_err(>dev, "could not get power controller\n");
ret = PTR_ERR(dwc3_data->rstc_pwrdn);
@@ -237,7 +238,8 @@ static int st_dwc3_probe(struct platform_device *pdev)
/* Manage PowerDown */
reset_control_deassert(dwc3_data->rstc_pwrdn);
 
-   dwc3_data->rstc_rst = devm_reset_control_get(dev, "softreset");
+   dwc3_data->rstc_rst =
+   devm_reset_control_get_shared(dev, "softreset");
if (IS_ERR(dwc3_data->rstc_rst)) {
dev_err(>dev, "could not get reset controller\n");
ret = PTR_ERR(dwc3_data->rstc_rst);
-- 
2.8.3

--
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 4/7] reset: Supply *_shared variant calls when using *_optional APIs

[Lee Jones]

Consumers need to be able to specify whether they are requesting an
'exclusive' or 'shared' reset line no matter which API (of_*, devm_*,
etc) they are using.  This change allows users of the optional_* API
in particular to specify that their request is for a 'shared' line.

Signed-off-by: Lee Jones <lee.jo...@linaro.org>
---
 include/linux/reset.h | 12 
 1 file changed, 12 insertions(+)

diff --git a/include/linux/reset.h b/include/linux/reset.h
index fd69240..c358106 100644
--- a/include/linux/reset.h
+++ b/include/linux/reset.h
@@ -141,6 +141,12 @@ static inline struct reset_control 
*reset_control_get_optional_exclusive(
return __of_reset_control_get(dev ? dev->of_node : NULL, id, 0, 0);
 }
 
+static inline struct reset_control *reset_control_get_optional_shared(
+   struct device *dev, const char *id)
+{
+   return __of_reset_control_get(dev ? dev->of_node : NULL, id, 0, 1);
+}
+
 /**
  * of_reset_control_get_exclusive - Lookup and obtain an exclusive reference
  *  to a reset controller.
@@ -270,6 +276,12 @@ static inline struct reset_control 
*devm_reset_control_get_optional_exclusive(
return __devm_reset_control_get(dev, id, 0, 0);
 }
 
+static inline struct reset_control *devm_reset_control_get_optional_shared(
+   struct device *dev, const char *id)
+{
+   return __devm_reset_control_get(dev, id, 0, 1);
+}
+
 /**
  * devm_reset_control_get_exclusive_by_index - resource managed
  * reset_control_get_exclusive()
-- 
2.8.3

--
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 5/7] reset: TRIVIAL: Add line break at same place for similar APIs

[Lee Jones]

Standardise the way inline functions:

  devm_reset_control_get_shared_by_index
  devm_reset_control_get_exclusive_by_index

... are formatted.

Signed-off-by: Lee Jones <lee.jo...@linaro.org>
---
 include/linux/reset.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/linux/reset.h b/include/linux/reset.h
index c358106..45a4abe 100644
--- a/include/linux/reset.h
+++ b/include/linux/reset.h
@@ -310,8 +310,8 @@ devm_reset_control_get_exclusive_by_index(struct device 
*dev, int index)
  * this function, reset_control_put() is called automatically on driver detach.
  * See reset_control_get_shared() for more information.
  */
-static inline struct reset_control *devm_reset_control_get_shared_by_index(
-   struct device *dev, int index)
+static inline struct reset_control *
+devm_reset_control_get_shared_by_index(struct device *dev, int index)
 {
return __devm_reset_control_get(dev, NULL, index, 1);
 }
-- 
2.8.3

--
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 6/7] phy: miphy28lp: Inform the reset framework that our reset line may be shared

[Lee Jones]

On the STiH410 B2120 development board the MiPHY28lp shares its reset
line with the Synopsys DWC3 SuperSpeed (SS) USB 3.0 Dual-Role-Device
(DRD).  New functionality in the reset subsystems forces consumers to
be explicit when requesting shared/exclusive reset lines.

Signed-off-by: Lee Jones <lee.jo...@linaro.org>
---
 drivers/phy/phy-miphy28lp.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/phy/phy-miphy28lp.c b/drivers/phy/phy-miphy28lp.c
index 3acd2a1..213e2e1 100644
--- a/drivers/phy/phy-miphy28lp.c
+++ b/drivers/phy/phy-miphy28lp.c
@@ -1143,7 +1143,8 @@ static int miphy28lp_probe_resets(struct device_node 
*node,
struct miphy28lp_dev *miphy_dev = miphy_phy->phydev;
int err;
 
-   miphy_phy->miphy_rst = of_reset_control_get(node, "miphy-sw-rst");
+   miphy_phy->miphy_rst =
+   of_reset_control_get_shared(node, "miphy-sw-rst");
 
if (IS_ERR(miphy_phy->miphy_rst)) {
dev_err(miphy_dev->dev,
-- 
2.8.3

--
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 0/7] reset: Consumers to explicitly request 'exclusive' or 'shared' lines

[Lee Jones]

Phasing out generic reset line requests enables us to make some better
decisions on when and how to (de)assert said lines.  If an 'exclusive'
line is requested, we know a device *requires* a reset and that it's
preferable to act upon a request right away.  However, if a 'shared'
reset line is requested, we can reasonably assume sure that placing a
device into reset isn't a hard requirement, but probably a measure to
save power and is thus able to cope with not being asserted if another
device is still in use.

In order allow gentle adoption and not to forcing all consumers to
move to the API immediately, causing administration headache between
subsystems, this patch adds some temporary stand-in shim-calls.  This
will ease the burden at merge time and allow subsystems to migrate over
to the new API in a more realistic time-frame.

Lee Jones (7):
  reset: Reorder inline reset_control_get*() wrappers
  reset: Ensure drivers are explicit when requesting reset lines
  reset: Supply *_shared variant calls when using of_* API
  reset: Supply *_shared variant calls when using *_optional APIs
  reset: TRIVIAL: Add line break at same place for similar APIs
  phy: miphy28lp: Inform the reset framework that our reset line may be
shared
  usb: dwc3: st: Inform the reset framework that our reset line may be
shared

 drivers/phy/phy-miphy28lp.c |   3 +-
 drivers/usb/dwc3/dwc3-st.c  |   6 +-
 include/linux/reset.h   | 211 +++-
 3 files changed, 173 insertions(+), 47 deletions(-)

-- 
2.8.3

--
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 v8 5/7] mfd: intel_vuport: Add Intel virtual USB port MFD Driver

[Lee Jones]

On Thu, 05 May 2016, Lu Baolu wrote:

> Some Intel platforms have an USB port mux controlled by GPIOs.
> There's a single ACPI platform device that provides 1) USB ID
> extcon device; 2) USB vbus regulator device; and 3) USB port
> switch device. This MFD driver will split these 3 devices for
> their respective drivers.
> 
> [baolu: removed .owner per platform_no_drv_owner.cocci]
> Suggested-by: David Cohen <david.a.co...@linux.intel.com>
> Signed-off-by: Lu Baolu <baolu...@linux.intel.com>
> Reviewed-by: Felipe Balbi <ba...@kernel.org>
> ---
>  drivers/mfd/Kconfig|  8 +
>  drivers/mfd/Makefile   |  1 +
>  drivers/mfd/intel-vuport.c | 89 
> ++
>  3 files changed, 98 insertions(+)
>  create mode 100644 drivers/mfd/intel-vuport.c

Acked-by: Lee Jones <lee.jo...@linaro.org>

> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index eea61e3..7e115ab 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -1578,5 +1578,13 @@ config MFD_VEXPRESS_SYSREG
> System Registers are the platform configuration block
> on the ARM Ltd. Versatile Express board.
>  
> +config MFD_INTEL_VUPORT
> + tristate "Intel virtual USB port controller"
> + select MFD_CORE
> + depends on X86 && ACPI
> + help
> +   Say Y here to enable support for Intel's dual role port mux
> +   controlled by GPIOs.
> +
>  endmenu
>  endif
> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> index 5eaa6465d..65b0518 100644
> --- a/drivers/mfd/Makefile
> +++ b/drivers/mfd/Makefile
> @@ -203,3 +203,4 @@ intel-soc-pmic-objs   := 
> intel_soc_pmic_core.o intel_soc_pmic_crc.o
>  intel-soc-pmic-$(CONFIG_INTEL_PMC_IPC)   += intel_soc_pmic_bxtwc.o
>  obj-$(CONFIG_INTEL_SOC_PMIC) += intel-soc-pmic.o
>  obj-$(CONFIG_MFD_MT6397) += mt6397-core.o
> +obj-$(CONFIG_MFD_INTEL_VUPORT)   += intel-vuport.o
> diff --git a/drivers/mfd/intel-vuport.c b/drivers/mfd/intel-vuport.c
> new file mode 100644
> index 000..fa84ed7
> --- /dev/null
> +++ b/drivers/mfd/intel-vuport.c
> @@ -0,0 +1,89 @@
> +/*
> + * MFD driver for Intel virtual USB port
> + *
> + * Copyright(c) 2016 Intel Corporation.
> + * Author: Lu Baolu <baolu...@linux.intel.com>
> + *
> + * 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 
> +
> +/* ACPI GPIO Mappings */
> +static const struct acpi_gpio_params id_gpio = { 0, 0, false };
> +static const struct acpi_gpio_params vbus_gpio = { 1, 0, false };
> +static const struct acpi_gpio_params mux_gpio = { 2, 0, false };
> +static const struct acpi_gpio_mapping acpi_usb_gpios[] = {
> + { "id-gpios", _gpio, 1 },
> + { "gpio-gpios", _gpio, 1 },
> + { "usb_mux-gpios", _gpio, 1 },
> + { },
> +};
> +
> +static struct property_entry reg_properties[] = {
> + PROPERTY_ENTRY_STRING("supply-name", "regulator-usb-gpio"),
> + { },
> +};
> +
> +static const struct property_set reg_properties_pset = {
> + .properties = reg_properties,
> +};
> +
> +static const struct mfd_cell intel_vuport_mfd_cells[] = {
> + { .name = "extcon-usb-gpio", },
> + {
> + .name = "reg-fixed-voltage",
> + .pset = _properties_pset,
> + },
> + { .name = "intel-mux-gpio", },
> +};
> +
> +static int vuport_probe(struct platform_device *pdev)
> +{
> + struct device *dev = >dev;
> + int ret;
> +
> + ret = acpi_dev_add_driver_gpios(ACPI_COMPANION(dev), acpi_usb_gpios);
> + if (ret)
> + return ret;
> +
> + return mfd_add_devices(>dev, PLATFORM_DEVID_NONE,
> + intel_vuport_mfd_cells,
> + ARRAY_SIZE(intel_vuport_mfd_cells), NULL, 0,
> + NULL);
> +}
> +
> +static int vuport_remove(struct platform_device *pdev)
> +{
> + mfd_remove_devices(>dev);
> + acpi_dev_remove_driver_gpios(ACPI_COMPANION(>dev));
> +
> + return 0;
> +}
> +
> +static struct acpi_device_id vuport_acpi_match[] = {
> + { "INT3496" },
> + { }
> +};
> +MODULE_DEVICE_TABLE(acpi, vuport_acpi_match);
> +
> +static struct platform_driver vuport_driver = {
> + .driver = {
> + .name = "intel-vuport",
> + .acpi_match_table 

Re: [PATCH v4 1/7] mfd: da8xx-cfgchip: New header file for CFGCHIP registers.

[Lee Jones]

On Thu, 14 Apr 2016, David Lechner wrote:

> We will be using a generic syscon device for the TI DA8XX SoC CFGCHIPx
> retisters. This will be used by a number of planned drivers including a
> new USB PHY driver and common clock framework drivers.
> 
> The same defines are removed from the platform_data header file since they
> are now redundant and they didn't really belong there anyway.
> 
> Signed-off-by: David Lechner <da...@lechnology.com>
> ---
> 
> v4 changes:
> 
> * dropped individual CFGCHIPn_REG defines in favor of CFGCHIP(n)
> 
> 
>  include/linux/mfd/da8xx-cfgchip.h | 153 
> ++
>  include/linux/platform_data/usb-davinci.h |  22 -

Works for me.

Acked-by: Lee Jones <lee.jo...@linaro.org>

Since this is a new file, I'm happy for it to be taken in via another
tree.

>  2 files changed, 153 insertions(+), 22 deletions(-)
>  create mode 100644 include/linux/mfd/da8xx-cfgchip.h
> 
> diff --git a/include/linux/mfd/da8xx-cfgchip.h 
> b/include/linux/mfd/da8xx-cfgchip.h
> new file mode 100644
> index 000..799e575
> --- /dev/null
> +++ b/include/linux/mfd/da8xx-cfgchip.h
> @@ -0,0 +1,153 @@
> +/*
> + * TI DaVinci DA8xx CHIPCFGx registers for syscon consumers.
> + *
> + * Copyright (C) 2016 David Lechner <da...@lechnology.com>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#ifndef __LINUX_MFD_DA8XX_CFGCHIP_H
> +#define __LINUX_MFD_DA8XX_CFGCHIP_H
> +
> +#include 
> +
> +/* register offset (32-bit registers) */
> +#define CFGCHIP(n)   (n * 4)
> +
> +/* CFGCHIP0 (PLL0/EDMA3_0) register bits */
> +#define CFGCHIP0_PLL_MASTER_LOCK BIT(4)
> +#define CFGCHIP0_EDMA30TC1DBS(n) (n << 2)
> +#define CFGCHIP0_EDMA30TC1DBS_MASK   CFGCHIP0_EDMA30TC1DBS(0x3)
> +#define CFGCHIP0_EDMA30TC1DBS_16 CFGCHIP0_EDMA30TC1DBS(0x0)
> +#define CFGCHIP0_EDMA30TC1DBS_32 CFGCHIP0_EDMA30TC1DBS(0x1)
> +#define CFGCHIP0_EDMA30TC1DBS_64 CFGCHIP0_EDMA30TC1DBS(0x2)
> +#define CFGCHIP0_EDMA30TC0DBS(n) (n << 0)
> +#define CFGCHIP0_EDMA30TC0DBS_MASK   CFGCHIP0_EDMA30TC0DBS(0x3)
> +#define CFGCHIP0_EDMA30TC0DBS_16 CFGCHIP0_EDMA30TC0DBS(0x0)
> +#define CFGCHIP0_EDMA30TC0DBS_32 CFGCHIP0_EDMA30TC0DBS(0x1)
> +#define CFGCHIP0_EDMA30TC0DBS_64 CFGCHIP0_EDMA30TC0DBS(0x2)
> +
> +/* CFGCHIP1 (eCAP/HPI/EDMA3_1/eHRPWM TBCLK/McASP0 AMUTEIN) register bits */
> +#define CFGCHIP1_CAP2SRC(n)  (n << 27)
> +#define CFGCHIP1_CAP2SRC_MASKCFGCHIP1_CAP2SRC(0x1f)
> +#define CFGCHIP1_CAP2SRC_ECAP_PINCFGCHIP1_CAP2SRC(0x0)
> +#define CFGCHIP1_CAP2SRC_MCASP0_TX   CFGCHIP1_CAP2SRC(0x1)
> +#define CFGCHIP1_CAP2SRC_MCASP0_RX   CFGCHIP1_CAP2SRC(0x2)
> +#define CFGCHIP1_CAP2SRC_EMAC_C0_RX_THRESHOLDCFGCHIP1_CAP2SRC(0x7)
> +#define CFGCHIP1_CAP2SRC_EMAC_C0_RX  CFGCHIP1_CAP2SRC(0x8)
> +#define CFGCHIP1_CAP2SRC_EMAC_C0_TX  CFGCHIP1_CAP2SRC(0x9)
> +#define CFGCHIP1_CAP2SRC_EMAC_C0_MISCCFGCHIP1_CAP2SRC(0xa)
> +#define CFGCHIP1_CAP2SRC_EMAC_C1_RX_THRESHOLDCFGCHIP1_CAP2SRC(0xb)
> +#define CFGCHIP1_CAP2SRC_EMAC_C1_RX  CFGCHIP1_CAP2SRC(0xc)
> +#define CFGCHIP1_CAP2SRC_EMAC_C1_TX  CFGCHIP1_CAP2SRC(0xd)
> +#define CFGCHIP1_CAP2SRC_EMAC_C1_MISCCFGCHIP1_CAP2SRC(0xe)
> +#define CFGCHIP1_CAP2SRC_EMAC_C2_RX_THRESHOLDCFGCHIP1_CAP2SRC(0xf)
> +#define CFGCHIP1_CAP2SRC_EMAC_C2_RX  CFGCHIP1_CAP2SRC(0x10)
> +#define CFGCHIP1_CAP2SRC_EMAC_C2_TX  CFGCHIP1_CAP2SRC(0x11)
> +#define CFGCHIP1_CAP2SRC_EMAC_C2_MISCCFGCHIP1_CAP2SRC(0x12)
> +#define CFGCHIP1_CAP1SRC(n)  (n << 22)
> +#define CFGCHIP1_CAP1SRC_MASKCFGCHIP1_CAP1SRC(0x1f)
> +#define CFGCHIP1_CAP1SRC_ECAP_PINCFGCHIP1_CAP1SRC(0x0)
> +#define CFGCHIP1_CAP1SRC_MCASP0_TX   CFGCHIP1_CAP1SRC(0x1)
> +#define CFGCHIP1_CAP1SRC_MCASP0_RX   CFGCHIP1_CAP1SRC(0x2)
> +#define CFGCHIP1_CAP1SRC_EMAC_C0_RX_THRESHOLDCFGCHIP1_CAP1SRC(0x7)
> +#define CFGCHIP1_CAP1SRC_EMAC_C0_RX  CFGCHIP1_CAP1SRC

Re: [PATCH] usb: host: xhci-plat: Make enum xhci_plat_type start at a non zero value

[Lee Jones]

On Sat, 26 Mar 2016, Felipe Balbi wrote:
> Peter Griffin <peter.grif...@linaro.org> writes:
> > On Fri, 25 Mar 2016, Felipe Balbi wrote:
> >> Gregory CLEMENT <gregory.clem...@free-electrons.com> writes:
> >> >> Peter Griffin <peter.grif...@linaro.org> writes:
> >> >>> Otherwise generic-xhci and xhci-platform which have no data get wrongly
> >> >>> detected as XHCI_PLAT_TYPE_MARVELL_ARMADA by xhci_plat_type_is().
> >> >>>
> >> >>> This fixes a regression in v4.5 for STiH407 family SoC's which use the
> >> >>> synopsis dwc3 IP, whereby the disable_clk error path gets taken due to
> >> >>> wrongly being detected as XHCI_PLAT_TYPE_MARVELL_ARMADA and the hcd 
> >> >>> never
> >> >>> gets added.
> >> >>>
> >> >>> I suspect this will also fix other dwc3 DT platforms such as Exynos,
> >> >>> although I've only tested on STih410 SoC.
> >> >>>
> >> >>> Fixes: 4efb2f694114 ("usb: host: xhci-plat: add struct xhci_plat_priv")
> >> >>> Cc: sta...@vger.kernel.org
> >> >>> Cc: gregory.clem...@free-electrons.com
> >> >>> Cc: yoshihiro.shimoda...@renesas.com
> >> >>> Signed-off-by: Peter Griffin <peter.grif...@linaro.org>
> >> >>> ---
> >> >>>  drivers/usb/host/xhci-plat.h | 2 +-
> >> >>>  1 file changed, 1 insertion(+), 1 deletion(-)
> >> >>>
> >> >>> diff --git a/drivers/usb/host/xhci-plat.h 
> >> >>> b/drivers/usb/host/xhci-plat.h
> >> >>> index 5a2e2e3..529c3c4 100644
> >> >>> --- a/drivers/usb/host/xhci-plat.h
> >> >>> +++ b/drivers/usb/host/xhci-plat.h
> >> >>> @@ -14,7 +14,7 @@
> >> >>>  #include "xhci.h" /* for hcd_to_xhci() */
> >> >>>  
> >> >>>  enum xhci_plat_type {
> >> >>> -  XHCI_PLAT_TYPE_MARVELL_ARMADA,
> >> >>> +  XHCI_PLAT_TYPE_MARVELL_ARMADA = 1,
> >> >>>XHCI_PLAT_TYPE_RENESAS_RCAR_GEN2,
> >> >>>XHCI_PLAT_TYPE_RENESAS_RCAR_GEN3,
> >> >>
> >> >> aren't these platforms using device tree ? Why aren't these just
> >> >> different compatible strings ?
> >> >
> >> > According to 4efb2f69411456d35051e9047c15157c9a5ba217 "usb: host:
> >> > xhci-plat: add struct xhci_plat_priv" :
> >> >
> >> > This patch adds struct xhci_plat_priv to simplify the code to match
> >> > platform specific variables. For now, this patch adds a member "type" in
> >> > the structure
> >> 
> >> that's fine but the answer doesn't exactly match my question ;-)
> >> 
> >> My point is that this enum shouldn't be necessary at all. We have
> >> compatible flags to make these checks instead. How about below ?
> >> (untested, uncompiled, yada yada yada). Note that we DON'T need this
> >> xhci_plat_type trickery, just need to be a little bit smarter about how
> >> we use driver_data:
> >
> > Your solution certainly looks more elegant.
> 
> cool thanks. Now that I think about this more carefully, we might wanna
> take $subject anyway for the -rc and get my version applied for v4.7
> merge window. What do you think ?

+1 for a simple/quick fix.

Acked-by: Lee Jones <lee.jo...@linaro.org>

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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 v5 6/6] mfd: intel_vuport: Add Intel virtual USB port MFD Driver

[Lee Jones]

On Fri, 18 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.
> 
> Signed-off-by: Lu Baolu <baolu...@linux.intel.com>
> Suggested-by: David Cohen <david.a.co...@linux.intel.com>

This should be at the top.

You couldn't have written the patch before it was suggested.

> Reviewed-by: Felipe Balbi <ba...@kernel.org>
> Signed-off-by: Fengguang Wu <fengguang...@intel.com>

What is this sign-off meant to indicate?

> Reviewed-by: Lee Jones <lee.jo...@linaro.org>

Why is this here?

a) I don't provide "Reviewed-by:" tags #alarmbells
b) I have never signed this patch off

> ---
>  MAINTAINERS|  6 

Seperate patch.

>  drivers/mfd/Kconfig|  8 +
>  drivers/mfd/Makefile   |  1 +
>  drivers/mfd/intel-vuport.c | 74 
> ++
>  4 files changed, 89 insertions(+)
>  create mode 100644 drivers/mfd/intel-vuport.c

[...]

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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 v2 7/7] mfd: intel_vuport: Add Intel virtual USB port MFD Driver

[Lee Jones]

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.
> 
> Signed-off-by: Lu Baolu <baolu...@linux.intel.com>
> Suggested-by: David Cohen <david.a.co...@linux.intel.com>
> Reviewed-by: Felipe Balbi <ba...@kernel.org>
> Signed-off-by: Fengguang Wu <fengguang...@intel.com>
> ---
>  MAINTAINERS|  1 +
>  drivers/mfd/Kconfig|  8 +
>  drivers/mfd/Makefile   |  1 +
>  drivers/mfd/intel-vuport.c | 78 
> ++
>  4 files changed, 88 insertions(+)
>  create mode 100644 drivers/mfd/intel-vuport.c
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 399cefe..1671a4d 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -11408,6 +11408,7 @@ F:drivers/usb/mux/intel-mux.c
>  F:   include/linux/usb/intel-mux.h
>  F:   drivers/usb/mux/intel-mux-gpio.c
>  F:   drivers/usb/mux/intel-mux-drcfg.c
> +F:   drivers/mfd/intel-vuport.c

Separate patch please.

>  USB PRINTER DRIVER (usblp)
>  M:   Pete Zaitcev <zait...@redhat.com>
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index 9ca66de..8dd1bf3 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -1534,5 +1534,13 @@ config MFD_VEXPRESS_SYSREG
> System Registers are the platform configuration block
> on the ARM Ltd. Versatile Express board.
>  
> +config MFD_INTEL_VUPORT
> + tristate "Intel virtual USB port controller"
> + select MFD_CORE
> + depends on X86 && ACPI
> + help
> +   Say Y here to enable support for Intel dual role port mux

Either "Intel's" or "the Intel".

> +   controlled by 3 GPIOs.
> +
>  endmenu
>  endif
> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> index 0f230a6..0ccd107 100644
> --- a/drivers/mfd/Makefile
> +++ b/drivers/mfd/Makefile
> @@ -198,3 +198,4 @@ intel-soc-pmic-objs   := 
> intel_soc_pmic_core.o intel_soc_pmic_crc.o
>  intel-soc-pmic-$(CONFIG_INTEL_PMC_IPC)   += intel_soc_pmic_bxtwc.o
>  obj-$(CONFIG_INTEL_SOC_PMIC) += intel-soc-pmic.o
>  obj-$(CONFIG_MFD_MT6397) += mt6397-core.o
> +obj-$(CONFIG_MFD_INTEL_VUPORT)   += intel-vuport.o
> diff --git a/drivers/mfd/intel-vuport.c b/drivers/mfd/intel-vuport.c
> new file mode 100644
> index 000..1371099
> --- /dev/null
> +++ b/drivers/mfd/intel-vuport.c
> @@ -0,0 +1,78 @@
> +/*
> + * MFD driver for Intel virtual USB port
> + *
> + * Copyright(c) 2016 Intel Corporation.
> + * Author: Lu Baolu <baolu...@linux.intel.com>
> + *
> + * 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 
> +
> +/* ACPI GPIO Mappings */
> +static const struct acpi_gpio_params id_gpio = { 0, 0, false };
> +static const struct acpi_gpio_params vbus_gpio = { 1, 0, false };
> +static const struct acpi_gpio_params mux_gpio = { 2, 0, false };
> +static const struct acpi_gpio_mapping acpi_usb_gpios[] = {
> + { "id-gpios", _gpio, 1 },
> + { "vbus_en-gpios", _gpio, 1 },
> + { "usb_mux-gpios", _gpio, 1 },
> + { },
> +};
> +
> +static const struct mfd_cell intel_vuport_mfd_cells[] = {
> + {
> + .name = "extcon-usb-gpio",
> + },
> + {
> + .name = "intel-mux-gpio",
> + },
> +};

Please place single line entries on the same line as the '{' and '}'.

As you have above.

> +static int vuport_probe(struct platform_device *pdev)
> +{
> + struct device *dev = >dev;
> + int ret;
> +
> + ret = acpi_dev_add_driver_gpios(ACPI_COMPANION(dev), acpi_usb_gpios);
> + if (ret)
> + return ret;
> +
> + return mfd_add_devices(>dev, 0, intel_vuport_mfd_cells,
> + ARRAY_SIZE(intel_vuport_mfd_cells), NULL, 0,
> + NULL);
> +}
> +
> +static int vuport_remove(struct platform_device *pdev)
> +{
> + mfd_remove_devices(>dev);
> + acpi_dev_remove_driver_gpios(ACPI_COMPANION(>dev));
> +
> + return 0;
> +}
> +
> +static struct acpi_device_id vuport_acpi_match[] = {
> + { "INT3496" },
> + { }
> +};
> +MODULE_DEVICE_TABLE(acpi, vuport_acpi_match);
> +
> +static struct platform_driver vuport_driver = {
>

Re: mass storage behaviour

[Paul Jones]

On 17 Oct 2015, at 12:30, Alan Stern  wrote:

> Paul, can you tell your email client to wrap lines after 72 columns or 
> so?  It would make replying a lot easier…
Mac Mail is not very friendly in this respect, but I can pay attention to 
not make long lines :)

> ...
>>> One thing you did not show here was the delay between sending the last
>>> data buffer of one command and sending the first data buffer of the
>>> next command.  That overhead could significantly affect the overall
>>> throughput.
>> The next read command is generally handled within 20us after the previous 
>> one. 
>> Switched over to ftrace to include the net2280 irq/dma handling, logging of 
>> the
>> spin locks and thread handling in bulk_in_complete:
> 
> Why are you still using 8 buffers?  I think 2 buffers (the default)
> would give the same performance.  It's worth checking.
It doesn’t make much difference end-to-end (135MB/s vs 132 MB/s).

> 
>> - FIRST REQUEST-
>>file-storage-1333  [002] 59.898705: do_read: READ: 122880 @ 0
>>file-storage-1333  [002] 59.898706: do_read: file read 16384 @ 0
>>file-storage-1333  [002] 59.898709: do_read: file read 16384 @ 0 
>> -> 16384
>>file-storage-1333  [002] 59.898709: start_transfer: bulk-in start
>>file-storage-1333  [002] 59.898710: net2280_queue: received 
>> request
>>file-storage-1333  [002] d...59.898711: net2280_queue: starting 
>> request
>> - FIRST DMA --
>>file-storage-1333  [002] d...59.898712: start_dma: start
>>file-storage-1333  [002] d...59.898713: start_dma: start queue
>>file-storage-1333  [002] d...59.898717: start_dma: end
>>file-storage-1333  [002] d...59.898717: net2280_queue: finished
>>file-storage-1333  [002] 59.898717: start_transfer: bulk-in queued
> 
> ...
> 
>> - FIRST IRQ -
>>  -0 [002] d.h.59.898828: net2280_irq: start
> 
> ...
> 
>> - SECOND IRQ -
>>  -0 [002] d.h.59.898945: net2280_irq: start
> 
> ...
> 
>> - SECOND REQUEST -
>>file-storage-1333  [002] 59.899702: do_read: READ: 8192 @ 122880
>>file-storage-1333  [002] 59.899702: do_read: file read 8192 @ 
>> 122880
>>file-storage-1333  [002] 59.899703: do_read: file read 8192 @ 
>> 122880 -> 8192
>>file-storage-1333  [002] 59.899704: start_transfer: bulk-in start
>>file-storage-1333  [002] 59.899704: net2280_queue: received 
>> request
>>file-storage-1333  [002] d...59.899704: net2280_queue: starting 
>> request
>>file-storage-1333  [002] d...59.899706: start_dma: start
>>file-storage-1333  [002] d...59.899707: start_dma: start queue
>>file-storage-1333  [002] d...59.899710: start_dma: end
>>file-storage-1333  [002] d...59.899710: net2280_queue: finished
>>file-storage-1333  [002] 59.899710: start_transfer: bulk-in queued
> 
> Why did you cut the log short?  The figure I wanted to see here was the
> time from the IRQ preceding the 8th bulk-in completion to the IRQ
> preceding the 10th bulk-in completion, which hasn't occurred yet.
Trying not to send longer emails than necessary.

I’ve included a new log showing two full requests:
--- FIRST REQUEST ---
file-storage-1345  [002]    214.987721: do_read: READ: 122880 @ 0
file-storage-1345  [002]    214.987722: do_read: file read 16384 @ 0
file-storage-1345  [002]    214.987731: do_read: file read 16384 @ 0 -> 
16384
file-storage-1345  [002]    214.987731: start_transfer: bulk-in start
file-storage-1345  [002]    214.987732: net2280_queue: received request
file-storage-1345  [002] d...   214.987736: net2280_queue: starting request
file-storage-1345  [002] d...   214.987738: start_dma: start
file-storage-1345  [002] d...   214.987739: start_dma: start queue
file-storage-1345  [002] d...   214.987743: start_dma: end
file-storage-1345  [002] d...   214.987743: net2280_queue: finished
file-storage-1345  [002]    214.987743: start_transfer: bulk-in queued
file-storage-1345  [002]    214.987744: do_read: file read 16384 @ 16384
file-storage-1345  [002]    214.987750: do_read: file read 16384 @ 
16384 -> 16384
file-storage-1345  [002]    214.987751: start_transfer: bulk-in start
file-storage-1345  [002]    214.987751: net2280_queue: received request
file-storage-1345  [002] d...   214.987754: net2280_queue: starting request
file-storage-1345  [002] d...   214.987755: net2280_queue: finished
file-storage-1345  [002]    214.987755: start_transfer: bulk-in queued
  -0 [002] d.h.   214.987838: net2280_irq: start
  -0 [002] d.h.   214.987846: done: start
  -0 [002] d.h.   214.987847: done: calling complete callback
  -0 [002] d.h.   214.987847: bulk_in_complete: start
  -0 [002] d.h.   

Re: mass storage behaviour

[Paul Jones]

On 17 Oct 2015, at 16:06, Alan Stern <st...@rowland.harvard.edu> wrote:

> On Sat, 17 Oct 2015, Paul Jones wrote:
> 
>> On 17 Oct 2015, at 12:30, Alan Stern <st...@rowland.harvard.edu> wrote:
>> 
>>> Paul, can you tell your email client to wrap lines after 72 columns or 
>>> so?  It would make replying a lot easier…
>> Mac Mail is not very friendly in this respect, but I can pay attention to 
>> not make long lines :)
> 
> Thanks.
> 
>>>>> One thing you did not show here was the delay between sending the last
>>>>> data buffer of one command and sending the first data buffer of the
>>>>> next command.  That overhead could significantly affect the overall
>>>>> throughput.
>>>> The next read command is generally handled within 20us after the previous 
>>>> one. 
> 
> What counts is not the time between the commands, but rather the time
> spent finishing up one command and then waiting for and starting the
> next.  See below.
> 
>> I’ve included a new log showing two full requests:
> 
> ...
> 
> I cut out the log.  The interesting part is delay between the
> start_dma call for the CSW and the start_dma for the first data
> transfer in the second READ command.  If max_sectors were larger then
> this delay would not be present at all.
> 
> In the log, the two start_dma lines occur at timestamps 214.988590 and
> 214.988767.  This is a 177-us delay -- not 20 us -- and it starts after
> about 850 us have elapsed.  That's a noticeable amount of overhead; it
> means that increasing max_sectors can raise the overall throughput by
> up to 20%.
> 
>> I did some testing using gadget zero and max out at 166 MB/s.
>> The big question is why the hardware won’t go any faster than that.
>> I am wondering whether it has something to do with the fact that the 
>> internal FIFO size for each endpoint is currently set to 1k.
> 
> The FIFO size is 1024 because that is the length of a bulk packet in
> USB-3.
> 
> To find out what the hardware is doing, you really need to use a bus
> analyzer.  On the other hand, I think we have adequately answered the
> questiona you originally raised at the start of this email thread.
Thank for all the help. It’s clear that the problem is not in the mass
storage function, but in the usb3380 hardware or the way the hardware is
configured/used by the net2280 driver.

Paul.


--
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: mass storage behaviour

[Paul Jones]

On 06 Oct 2015, at 12:34, Paul Jones <p.jo...@teclyn.com> wrote:

> On 06 Oct 2015, at 16:44, Alan Stern <st...@rowland.harvard.edu> wrote:
> 
>> On Tue, 6 Oct 2015, Paul Jones wrote:
>> 
>>> On 05 Oct 2015, at 23:09, Alan Stern <st...@rowland.harvard.edu> wrote:
>>> 
>>>> On Mon, 5 Oct 2015, Paul Jones wrote:
>>>> 
>>>>>> Increasing the max_sectors_kb value, on the other hand, might remove
>>>>>> overhead by allowing a higher percentage of the transfer to consist of
>>>>>> real data as opposed to CBW and CSW packets.  This depends to some
>>>>>> extent on other factors (such as whether the memory pages are
>>>>>> contiguous, allowing for larger transfers), but it can't hurt.
>>>>> 
>>>>> I tried changing the max_sectors_kb to 64 with 64k block size in dd and 
>>>>> it�s transferring at the same speed.
>>>> 
>>>> That's a decrease, not an increase.  Try changing it to 1024 or more.
>>> I can�t increase the value, any value over 120 is rejected.
>>> I therefore decided to see if the speed would decrease by decreasing the 
>>> block size, which doesn�t seem to be the case.
>>> Is there a setting somewhere that limits the max_sectors_kb value?
>> 
>> Yes, there is.  I forgot about this hard limit.  I think you can change
>> it by writing to /sys/bus/usb/devices/.../max_sectors, where ... is the
>> path for the mass-storage interface of your device.
> I changed /sys/block//device/max_sectors to 4096 and 
> /sys/block//queue/max_sectors_kb to 2048
> That improves matters slightly from 140MB/s to 160MB/s.
> 
> Using Paul Zimmerman’s suggestion I can increase that to 174MB/s using a 160k 
> buffer. 
> However changing to a tmpfs backing file for my gadget makes no difference in 
> speed at all.
> I guess that means that the delays are actually part of the gadget and/or 
> f_mass_storage implementation.
> 
>>> In my current setup I have 35us overhead for responding to the CBW
>>> and CSW requests (70 us total) and there seems to be some delay in
>>> the bulk transmission of the data as well as the transmission time
>>> for the data is much slower than 5Gb/s.
>> 
>> All those things take time.  No doubt some of the delay is the time 
>> required to read the data from the backing file.  Most of the rest is 
>> transmission time.
>> 
>> Note that you can never actually attain 5 Gb/s, even under the best 
>> circumstances.  For one thing, data on the USB bus is encoded in a way 
>> that uses 10 bits on the bus to send 8 bits of data.  So you could 
>> never achieve more than 500 MB/s even if there were no packet headers, 
>> breaks between packets, and so on.
> I would be happy with anything over 300MB/s for sequential transfers.
> 
>> 
>>> Is there a way to trace the USB frames to see where the delays are
>>> occurring during the actual data transfer?
>> 
>> Sure, if you have a USB bus analyzer.  There's no way to do it in 
>> software alone.
> Couldn’t we at least use interrupts to timestamp when individual frames are 
> sent/received or when DMA starts/completes?
Added some debugging statements in f_mass_storage/net2280 to get an idea of 
what is going on on the wire (as I unfortunately don’t have any tools to figure 
it out any other way).
Additional debug statement locations:
- net2280_queue: received request is at the beginning of the function
- net2280_queue: starting request is right after the spin lock is acquired
- net2280_queue: finished is just before the spin lock is released
- mass_storage.1/lun.0: file read  size @ offset is just before vfs_read
- mass_storage.1/lun.0: file read  size @ offset -> read is just after the 
vfs_read
- configfs-gadget gadget: bulk-in/bulk-out wait is just before the spin lock in 
start_transfer
- configfs-gadget gadget: bulk-in/bulk-out start is right after the spin lock 
is acquired in start_transfer
- configfs-gadget gadget: bulk-in/bulk-out queued is right after the call to 
usb_ep_queue in start_transfer
- configfs-gadget gadget: bulk-in/bulk-out completed is at the beginning of 
bulk_in_completed/bulk_out_completed

Log for a single large read request:
Oct 16 13:10:27 usbserver kernel: [  176.372445] configfs-gadget gadget: SCSI 
command: READ(10);  Dc=10, Di=122880;  Hc=10, Hi=122880
Oct 16 13:10:27 usbserver kernel: [  176.372446] mass_storage.1/lun.0: file 
read 16384 @ 268435456
Oct 16 13:10:27 usbserver kernel: [  176.372448] mass_storage.1/lun.0: file 
read 16384 @ 268435456 -> 16384
Oct 16 13:10:27 usbserver kernel: [  176.372448] configfs-gadget gadget: 
bulk-in wait
Oct 16 13:10:

Re: mass storage behaviour

[Paul Jones]

On 16 Oct 2015, at 15:59, Alan Stern <st...@rowland.harvard.edu> wrote:

> On Fri, 16 Oct 2015, Paul Jones wrote:
> 
>> Added some debugging statements in f_mass_storage/net2280 to get an idea of 
>> what is going on on the wire (as I unfortunately don’t have any tools to 
>> figure it out any other way).
>> Additional debug statement locations:
> ...
> 
>> Log for a single large read request:
> ...
> 
>> The above is using the standard buffer size of 16k with 8 buffers. 
>> 
>> f_mass_storage performs a vfs_read and waits for it’s result before 
>> performing a start_in_transfer.
>> The start_in_transfer doesn’t return until the transfer is queued.
>> If the read request is large enough to require multiple buffers then the 
>> next vfs_read is only issued after the transfer is queued.
>> 
>> Occasionally a vfs_read requests is slow (20+us) but the other calls are 
>> relatively fast (2-3us) for the same transfer size, which is presumably due 
>> to read ahead in the vfs layer.
>> Similarly queuing some of the bulk transfers is very slow (4-15us), but 
>> others are fast (1-2us).
> 
> Some of these delays you see may be due to interrupts coming from other 
> devices.  There's not much you can do about those.
> 
>> The slow queuing of transfers seems to be due to waiting in a spin lock on 
>> ep->dev->lock (4+ us).
>> I’m guessing this is caused by the fact that there sometimes seems to be 
>> significant time between when the spin lock is acquired in net2280_queue and 
>> when it is released.
>> Any idea why that may be?
> 
> There shouldn't be any contention on that spinlock -- at least, not
> until the driver's interrupt handler needs to run.  Everything else in 
> the mass-storage gadget is single-threaded.  I don't know why it should 
> take so long to acquire the spinlock when nothing else is happening, 
> unless once again you're seeing interrupts from other devices.
I am talking about the net2280 lock and not the mass_storage lock.

> 
>> It seems to take about 95-100us from the first usb_ep_queue to 
>> bulk_in_complete for 16384 bytes of payload. 
>> Subsequent bulk_in_complete events are returned at a 95-100us between them.
>> Any ideas why that may be?
> 
> That's the time it takes to actually send the data across the USB bus.  
> You appear to be getting about 1/3 the maximum possible throughput,
> since the maximum data rate is 500 MB/s and you're getting 16384 B in
> about 100 us.
> 
>> Given that most of the bulk-in requests are overlapping, the underlying 
>> hardware shouldn’t have to wait for anything except for the host stalling 
>> the data reception (which I think is unlikely).
> 
> Don't be so sure.  The fact is, either the host's or the gadget's 
> hardware could easily be running at a sub-optimal speed.  Hardware 
> implementations are rarely ideal.
> 
>> I noticed that the done function in net2280 releases and requires the 
>> ep->dev->lock around the call to the completion callback.
>> Given that sometimes acquiring the lock takes a long time, we could be 
>> stalling interrupts for a significant amount of time as well.
>> I’ll try to add some logging in the irq handler to see how long this are 
>> taking...
> 
> One thing you did not show here was the delay between sending the last
> data buffer of one command and sending the first data buffer of the
> next command.  That overhead could significantly affect the overall
> throughput.
The next read command is generally handled within 20us after the previous one. 
Switched over to ftrace to include the net2280 irq/dma handling, logging of the 
spin locks and thread handling in bulk_in_complete:
- FIRST REQUEST-
file-storage-1333  [002] 59.898705: do_read: READ: 122880 @ 0
file-storage-1333  [002] 59.898706: do_read: file read 16384 @ 0
file-storage-1333  [002] 59.898709: do_read: file read 16384 @ 0 -> 
16384
file-storage-1333  [002] 59.898709: start_transfer: bulk-in start
file-storage-1333  [002] 59.898710: net2280_queue: received request
file-storage-1333  [002] d...59.898711: net2280_queue: starting request
- FIRST DMA --
file-storage-1333  [002] d...59.898712: start_dma: start
file-storage-1333  [002] d...59.898713: start_dma: start queue
file-storage-1333  [002] d...59.898717: start_dma: end
file-storage-1333  [002] d...59.898717: net2280_queue: finished
file-storage-1333  [002] 59.898717: start_transfer: bulk-in queued
file-storage-1333  [002] 59.898717: do_read: file read 16384 @ 16384
file-storage-1333  [002] 59.898720: do_read: f

Re: Crash in usb_f_mass_storage

[Paul Jones]

On 16 Oct 2015, at 05:55, Kaukab, Yousaf <yousaf.kau...@intel.com> wrote:

>> -Original Message-
>> From: Paul Jones [mailto:p.jo...@teclyn.com]
>> Sent: Friday, October 16, 2015 3:40 AM
>> To: Kaukab, Yousaf
>> Cc: Alan Stern; Felipe Balbi; Linux USB Mailing List
>> Subject: Re: Crash in usb_f_mass_storage
>> 
>> 
>> On 15 Oct 2015, at 04:12, Kaukab, Yousaf <yousaf.kau...@intel.com> wrote:
>> 
>>>> -Original Message-
>>>> From: Paul Jones [mailto:p.jo...@teclyn.com]
>>>> Sent: Thursday, October 15, 2015 12:30 AM
>>>> To: Alan Stern
>>>> Cc: Kaukab, Yousaf; Felipe Balbi; Linux USB Mailing List
>>>> Subject: Re: Crash in usb_f_mass_storage
>>>> 
>>>> 
>>>> On 14 Oct 2015, at 15:37, Alan Stern <st...@rowland.harvard.edu> wrote:
>>>> 
>>>>> On Wed, 14 Oct 2015, Paul Jones wrote:
>>>>> 
>>>>>> On 12 Oct 2015, at 14:16, Felipe Balbi <ba...@ti.com> wrote:
>>>>>> 
>>>>>>> 
>>>>>>> Hi,
>>>>>>> 
>>>>>>> Paul Jones <p.jo...@teclyn.com> writes:
>>>>>>>> On 10 Oct 2015, at 16:32, Paul Jones <p.jo...@teclyn.com> wrote:
>>>>>>>> 
>>>>>>>>> I came across the following kernel message on the latest 4.3-rc4
>>>>>>>>> whilst
>>>> performance testing on a USB3380 device connected to a Mac (10.9.5):
>>>>>>>>> 
>>>>>>>>> [   51.613838] WARNING: CPU: 2 PID: 0 at
>>>> drivers/usb/gadget/function/f_mass_storage.c:346
>>>> fsg_setup+0x12a/0x170
>>>> [usb_f_mass_storage]()
>>>>>>>>> [   51.613838] Modules linked in: usb_f_mass_storage libcomposite
>>>> configfs drbg ansi_cprng ctr ccm arc4 snd_hda_codec_hdmi iwlmvm i915
>>>> mac80211 snd_hda_codec_realtek snd_hda_codec_generic hid_generic
>>>> intel_rapl iosf_mbi x86_pkg_temp_thermal intel_powerclamp coretemp
>>>> iwlwifi kvm_intel cfg80211 kvm drm_kms_helper drm snd_hda_intel
>>>> snd_hda_codec btusb btrtl crct10dif_pclmul crc32_pclmul btbcm
>>>> snd_hda_core ghash_clmulni_intel btintel bluetooth snd_hwdep e1000e
>>>> aesni_intel
>>>> aes_x86_64 lrw snd_pcm gf128mul glue_helper ablk_helper cryptd
>>>> serio_raw alx mei_me lpc_ich usbhid mei snd_timer snd net2280
>>>> i2c_algo_bit ptp udc_core fb_sys_fops mdio syscopyarea pps_core
>>>> sysfillrect soundcore sysimgblt i2c_hid hid video dw_dmac sdhci_acpi
>>>> shpchp i2c_designware_platform dw_dmac_core spi_pxa2xx_platform sdhci
>>>> 8250_dw i2c_designware_core acpi_pad lp mac_hid parport
>>>>>>>>> [   51.613858] CPU: 2 PID: 0 Comm: swapper/2 Tainted: GW
>>>> 4.3.0-rc4+ #4
>>>>>>>>> [   51.613859] Hardware name: Gigabyte Technology Co., Ltd. H97N-
>>>> WIFI/H97N-WIFI, BIOS F7 04/21/2015
>>>>>>>>> [   51.613860]  a03e9e10 88021eb03d70 81393f5d
>>>> 
>>>>>>>>> [   51.613861]  88021eb03da8 81075856 880037be4400
>>>> 88020b3023c8
>>>>>>>>> [   51.613862]  880037be4400 ffa1
>> 
>>>> 88021eb03db8
>>>>>>>>> [   51.613863] Call Trace:
>>>>>>>>> [   51.613864][] dump_stack+0x44/0x57
>>>>>>>>> [   51.613867]  []
>> warn_slowpath_common+0x86/0xc0
>>>>>>>>> [   51.613868]  [] warn_slowpath_null+0x1a/0x20
>>>>>>>>> [   51.613870]  [] fsg_setup+0x12a/0x170
>>>> [usb_f_mass_storage]
>>>>>>>>> [   51.613872]  [] composite_setup+0x173/0x16b0
>>>> [libcomposite]
>>>>>>>>> [   51.613873]  [] ? ktime_get+0x3a/0x90
>>>>>>>>> [   51.613874]  [] ? lapic_next_deadline+0x29/0x30
>>>>>>>>> [   51.613875]  [] ? ktime_get+0x3a/0x90
>>>>>>>>> [   51.613877]  [] net2280_irq+0xba2/0x10db
>>>> [net2280]
>>>>>>>>> [   51.613879]  []
>>>> handle_irq_event_percpu+0x39/0x180
>>>>>>>>> [   51.613880]  [] handle_irq_event+0x45/0x70
>>>>>>>>> [   51.613881]  [] handle_edge_irq+0x99/0x150
>>>>>>>&

net2280 crash during testusb

[Paul Jones]

Youssaf,

if I run test 13 of testusb I get the following crash:
[  963.504860] WARNING: CPU: 1 PID: 0 at drivers/usb/gadget/udc/net2280.c:893 
start_dma+0x218/0x220 [net2280]()
[  963.504861] Modules linked in: g_zero usbtest usb_f_ss_lb libcomposite 
configfs ccm arc4 iwlmvm i915 mac80211 iwlwifi i2c_algo_bit drm_kms_helper 
syscopyarea sysfillrect sysimgblt fb_sys_fops drm intel_rapl iosf_mbi 
x86_pkg_temp_thermal intel_powerclamp cfg80211 coretemp crct10dif_pclmul 
crc32_pclmul aesni_intel aes_x86_64 glue_helper lrw gf128mul hid_generic 
ablk_helper cryptd mei_me mei usbhid net2280 udc_core hid lpc_ich dw_dmac 
shpchp dw_dmac_core i2c_designware_platform video 8250_dw i2c_designware_core 
acpi_pad e1000e ptp pps_core [last unloaded: g_zero]
[  963.504878] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.3.0-rc4+ #40
[  963.504879] Hardware name: Gigabyte Technology Co., Ltd. 
H97N-WIFI/H97N-WIFI, BIOS F7 04/21/2015
[  963.504880]  a011a078 88021ea83de8 8137e12d 

[  963.504882]  88021ea83e20 81075856 88020bce73f8 
880214e6c280
[  963.504883]  c9e5c180  88020bce73d8 
88021ea83e30
[  963.504884] Call Trace:
[  963.504885][] dump_stack+0x44/0x57
[  963.504890]  [] warn_slowpath_common+0x86/0xc0
[  963.504892]  [] warn_slowpath_null+0x1a/0x20
[  963.504893]  [] start_dma+0x218/0x220 [net2280]
[  963.504894]  [] restart_dma.part.17+0x19/0x20 [net2280]
[  963.504896]  [] net2280_irq+0xa69/0x11e9 [net2280]
[  963.504899]  [] handle_irq_event_percpu+0x39/0x180
[  963.504900]  [] handle_irq_event+0x45/0x70
[  963.504902]  [] handle_edge_irq+0x99/0x150
[  963.504904]  [] handle_irq+0x1d/0x30
[  963.504906]  [] do_IRQ+0x4d/0xd0
[  963.504908]  [] common_interrupt+0x87/0x87
[  963.504908][] ? cpuidle_enter_state+0xb8/0x220
[  963.504912]  [] cpuidle_enter+0x17/0x20
[  963.504913]  [] call_cpuidle+0x32/0x60
[  963.504915]  [] ? cpuidle_select+0x13/0x20
[  963.504916]  [] cpu_startup_entry+0x21c/0x2e0
[  963.504917]  [] start_secondary+0x104/0x130
[  963.504918] ---[ end trace a487b66d2eedaafe ]—

The basic steps to reproduce (looping back the net2280 card to a port on the 
same host):
modprobe g_zero buflen=131072
testusb -a -t 13 -s 131072 -c 512

Any ideas?

I (only) get a maximum throughput of 166MB/s. when using:
  testusb -a -t 2 -s 131072 -c 1000 

Paul.

--
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: mass storage behaviour

[Paul Jones]

On 16 Oct 2015, at 18:06, Felipe Balbi <ba...@ti.com> wrote:

> 
> Hi,
> 
> Paul Jones <p.jo...@teclyn.com> writes:
>> First DMA to first IRQ = 116us.
>> 
>> Second DMA to second IRQ = 107us.
>> 
>> These seem fairly stable as the last request in a 500+MB transfer had
>> exactly the same timings.
>> 
>> Each IRQ is taking around 14us to handle, during which most of the
>> time the ep->dev->lock is locked (only released in the done function
>> whilst calling the callback).
>> 
>> Setting up DMA is taking around 5us to handle.
>> 
>> Measured end-to-end performance: 135MB/s (145MB/s with tweaked
>> max_sector).  That’s not bad given that the DMA is only managing
>> 153MB/s.
>> 
>> Yousaf: is there a way to get an IRQ on a stall/fifo full/etc. to see
>> if some throttling is going on? Any other parts of the code that would
>> be useful to have timing on?
>> 
>> Are there any tools to measure host to device raw performance (max
>> bulk throughput)?
> 
> max bulk or max MSC BOT ? For MSC you can use dd. For max bulk, you'd
> have to write something up with libusb and probably hack f_sourcesink.c
> a bit to always requeue a completed usb_request and never process anything.
All my measurements so far are using dd to establish max MSC BOT.

I am looking for max bulk to see the limits of the hardware, before I start 
complaining too much about max MSC BOT :)
It looks like f_sourcesink will just “swallow” any bulk packets sent to the 
gadget and will generate simple packet content when read from?
Do you know of any libusb sample code that can do reading/writing from an 
f_sourcesink gadget?

Paul.

--
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: Crash in usb_f_mass_storage

[Paul Jones]

On 15 Oct 2015, at 17:18, Paul Jones <p.jo...@teclyn.com> wrote:

> On 15 Oct 2015, at 04:12, Kaukab, Yousaf <yousaf.kau...@intel.com> wrote:
> 
>>> -Original Message-
>>> From: Paul Jones [mailto:p.jo...@teclyn.com]
>>> Sent: Thursday, October 15, 2015 12:30 AM
>>> To: Alan Stern
>>> Cc: Kaukab, Yousaf; Felipe Balbi; Linux USB Mailing List
>>> Subject: Re: Crash in usb_f_mass_storage
>>> 
>>> 
>>> On 14 Oct 2015, at 15:37, Alan Stern <st...@rowland.harvard.edu> wrote:
>>> 
>>>> On Wed, 14 Oct 2015, Paul Jones wrote:
>>>> 
>>>>> On 12 Oct 2015, at 14:16, Felipe Balbi <ba...@ti.com> wrote:
>>>>> 
>>>>>> 
>>>>>> Hi,
>>>>>> 
>>>>>> Paul Jones <p.jo...@teclyn.com> writes:
>>>>>>> On 10 Oct 2015, at 16:32, Paul Jones <p.jo...@teclyn.com> wrote:
>>>>>>> 
>>>>>>>> I came across the following kernel message on the latest 4.3-rc4 whilst
>>> performance testing on a USB3380 device connected to a Mac (10.9.5):
>>>>>>>> 
>>>>>>>> [   51.613838] WARNING: CPU: 2 PID: 0 at
>>> drivers/usb/gadget/function/f_mass_storage.c:346 fsg_setup+0x12a/0x170
>>> [usb_f_mass_storage]()
>>>>>>>> [   51.613838] Modules linked in: usb_f_mass_storage libcomposite
>>> configfs drbg ansi_cprng ctr ccm arc4 snd_hda_codec_hdmi iwlmvm i915
>>> mac80211 snd_hda_codec_realtek snd_hda_codec_generic hid_generic
>>> intel_rapl iosf_mbi x86_pkg_temp_thermal intel_powerclamp coretemp iwlwifi
>>> kvm_intel cfg80211 kvm drm_kms_helper drm snd_hda_intel snd_hda_codec
>>> btusb btrtl crct10dif_pclmul crc32_pclmul btbcm snd_hda_core
>>> ghash_clmulni_intel btintel bluetooth snd_hwdep e1000e aesni_intel
>>> aes_x86_64 lrw snd_pcm gf128mul glue_helper ablk_helper cryptd serio_raw
>>> alx mei_me lpc_ich usbhid mei snd_timer snd net2280 i2c_algo_bit ptp
>>> udc_core fb_sys_fops mdio syscopyarea pps_core sysfillrect soundcore
>>> sysimgblt i2c_hid hid video dw_dmac sdhci_acpi shpchp
>>> i2c_designware_platform dw_dmac_core spi_pxa2xx_platform sdhci 8250_dw
>>> i2c_designware_core acpi_pad lp mac_hid parport
>>>>>>>> [   51.613858] CPU: 2 PID: 0 Comm: swapper/2 Tainted: GW
>>> 4.3.0-rc4+ #4
>>>>>>>> [   51.613859] Hardware name: Gigabyte Technology Co., Ltd. H97N-
>>> WIFI/H97N-WIFI, BIOS F7 04/21/2015
>>>>>>>> [   51.613860]  a03e9e10 88021eb03d70 81393f5d
>>> 
>>>>>>>> [   51.613861]  88021eb03da8 81075856 880037be4400
>>> 88020b3023c8
>>>>>>>> [   51.613862]  880037be4400 ffa1 
>>> 88021eb03db8
>>>>>>>> [   51.613863] Call Trace:
>>>>>>>> [   51.613864][] dump_stack+0x44/0x57
>>>>>>>> [   51.613867]  [] warn_slowpath_common+0x86/0xc0
>>>>>>>> [   51.613868]  [] warn_slowpath_null+0x1a/0x20
>>>>>>>> [   51.613870]  [] fsg_setup+0x12a/0x170
>>> [usb_f_mass_storage]
>>>>>>>> [   51.613872]  [] composite_setup+0x173/0x16b0
>>> [libcomposite]
>>>>>>>> [   51.613873]  [] ? ktime_get+0x3a/0x90
>>>>>>>> [   51.613874]  [] ? lapic_next_deadline+0x29/0x30
>>>>>>>> [   51.613875]  [] ? ktime_get+0x3a/0x90
>>>>>>>> [   51.613877]  [] net2280_irq+0xba2/0x10db
>>> [net2280]
>>>>>>>> [   51.613879]  []
>>> handle_irq_event_percpu+0x39/0x180
>>>>>>>> [   51.613880]  [] handle_irq_event+0x45/0x70
>>>>>>>> [   51.613881]  [] handle_edge_irq+0x99/0x150
>>>>>>>> [   51.613883]  [] handle_irq+0x1d/0x30
>>>>>>>> [   51.613883]  [] do_IRQ+0x4d/0xd0
>>>>>>>> [   51.613885]  [] common_interrupt+0x87/0x87
>>>>>>>> [   51.613885][] ?
>>> cpuidle_enter_state+0xb8/0x220
>>>>>>>> [   51.613888]  [] cpuidle_enter+0x17/0x20
>>>>>>>> [   51.613889]  [] call_cpuidle+0x32/0x60
>>>>>>>> [   51.613890]  [] ? cpuidle_select+0x13/0x20
>>>>>>>> [   51.613891]  [] cpu_startup_entry+0x21c/0x2e0
>>>>>>>> [   51.613891]  [] start_secon

Re: Crash in usb_f_mass_storage

[Paul Jones]

On 15 Oct 2015, at 04:12, Kaukab, Yousaf <yousaf.kau...@intel.com> wrote:

>> -Original Message-
>> From: Paul Jones [mailto:p.jo...@teclyn.com]
>> Sent: Thursday, October 15, 2015 12:30 AM
>> To: Alan Stern
>> Cc: Kaukab, Yousaf; Felipe Balbi; Linux USB Mailing List
>> Subject: Re: Crash in usb_f_mass_storage
>> 
>> 
>> On 14 Oct 2015, at 15:37, Alan Stern <st...@rowland.harvard.edu> wrote:
>> 
>>> On Wed, 14 Oct 2015, Paul Jones wrote:
>>> 
>>>> On 12 Oct 2015, at 14:16, Felipe Balbi <ba...@ti.com> wrote:
>>>> 
>>>>> 
>>>>> Hi,
>>>>> 
>>>>> Paul Jones <p.jo...@teclyn.com> writes:
>>>>>> On 10 Oct 2015, at 16:32, Paul Jones <p.jo...@teclyn.com> wrote:
>>>>>> 
>>>>>>> I came across the following kernel message on the latest 4.3-rc4 whilst
>> performance testing on a USB3380 device connected to a Mac (10.9.5):
>>>>>>> 
>>>>>>> [   51.613838] WARNING: CPU: 2 PID: 0 at
>> drivers/usb/gadget/function/f_mass_storage.c:346 fsg_setup+0x12a/0x170
>> [usb_f_mass_storage]()
>>>>>>> [   51.613838] Modules linked in: usb_f_mass_storage libcomposite
>> configfs drbg ansi_cprng ctr ccm arc4 snd_hda_codec_hdmi iwlmvm i915
>> mac80211 snd_hda_codec_realtek snd_hda_codec_generic hid_generic
>> intel_rapl iosf_mbi x86_pkg_temp_thermal intel_powerclamp coretemp iwlwifi
>> kvm_intel cfg80211 kvm drm_kms_helper drm snd_hda_intel snd_hda_codec
>> btusb btrtl crct10dif_pclmul crc32_pclmul btbcm snd_hda_core
>> ghash_clmulni_intel btintel bluetooth snd_hwdep e1000e aesni_intel
>> aes_x86_64 lrw snd_pcm gf128mul glue_helper ablk_helper cryptd serio_raw
>> alx mei_me lpc_ich usbhid mei snd_timer snd net2280 i2c_algo_bit ptp
>> udc_core fb_sys_fops mdio syscopyarea pps_core sysfillrect soundcore
>> sysimgblt i2c_hid hid video dw_dmac sdhci_acpi shpchp
>> i2c_designware_platform dw_dmac_core spi_pxa2xx_platform sdhci 8250_dw
>> i2c_designware_core acpi_pad lp mac_hid parport
>>>>>>> [   51.613858] CPU: 2 PID: 0 Comm: swapper/2 Tainted: GW
>> 4.3.0-rc4+ #4
>>>>>>> [   51.613859] Hardware name: Gigabyte Technology Co., Ltd. H97N-
>> WIFI/H97N-WIFI, BIOS F7 04/21/2015
>>>>>>> [   51.613860]  a03e9e10 88021eb03d70 81393f5d
>> 
>>>>>>> [   51.613861]  88021eb03da8 81075856 880037be4400
>> 88020b3023c8
>>>>>>> [   51.613862]  880037be4400 ffa1 
>> 88021eb03db8
>>>>>>> [   51.613863] Call Trace:
>>>>>>> [   51.613864][] dump_stack+0x44/0x57
>>>>>>> [   51.613867]  [] warn_slowpath_common+0x86/0xc0
>>>>>>> [   51.613868]  [] warn_slowpath_null+0x1a/0x20
>>>>>>> [   51.613870]  [] fsg_setup+0x12a/0x170
>> [usb_f_mass_storage]
>>>>>>> [   51.613872]  [] composite_setup+0x173/0x16b0
>> [libcomposite]
>>>>>>> [   51.613873]  [] ? ktime_get+0x3a/0x90
>>>>>>> [   51.613874]  [] ? lapic_next_deadline+0x29/0x30
>>>>>>> [   51.613875]  [] ? ktime_get+0x3a/0x90
>>>>>>> [   51.613877]  [] net2280_irq+0xba2/0x10db
>> [net2280]
>>>>>>> [   51.613879]  []
>> handle_irq_event_percpu+0x39/0x180
>>>>>>> [   51.613880]  [] handle_irq_event+0x45/0x70
>>>>>>> [   51.613881]  [] handle_edge_irq+0x99/0x150
>>>>>>> [   51.613883]  [] handle_irq+0x1d/0x30
>>>>>>> [   51.613883]  [] do_IRQ+0x4d/0xd0
>>>>>>> [   51.613885]  [] common_interrupt+0x87/0x87
>>>>>>> [   51.613885][] ?
>> cpuidle_enter_state+0xb8/0x220
>>>>>>> [   51.613888]  [] cpuidle_enter+0x17/0x20
>>>>>>> [   51.613889]  [] call_cpuidle+0x32/0x60
>>>>>>> [   51.613890]  [] ? cpuidle_select+0x13/0x20
>>>>>>> [   51.613891]  [] cpu_startup_entry+0x21c/0x2e0
>>>>>>> [   51.613891]  [] start_secondary+0x104/0x130
>>>>>>> [   51.613892] ---[ end trace bda1c37ade46c57d ]
>>>>>>> 
>>>>>>> I can also reliable reproduce this by connecting the USB3380 to a USB
>> port on the same Linux machine.
>>>>>>> In that case I also see an error:
>>>>>>> net2280 : net2280_enable: error=-

Re: Crash in usb_f_mass_storage

[Paul Jones]

On 15 Oct 2015, at 04:12, Kaukab, Yousaf <yousaf.kau...@intel.com> wrote:

>> -Original Message-
>> From: Paul Jones [mailto:p.jo...@teclyn.com]
>> Sent: Thursday, October 15, 2015 12:30 AM
>> To: Alan Stern
>> Cc: Kaukab, Yousaf; Felipe Balbi; Linux USB Mailing List
>> Subject: Re: Crash in usb_f_mass_storage
>> 
>> 
>> On 14 Oct 2015, at 15:37, Alan Stern <st...@rowland.harvard.edu> wrote:
>> 
>>> On Wed, 14 Oct 2015, Paul Jones wrote:
>>> 
>>>> On 12 Oct 2015, at 14:16, Felipe Balbi <ba...@ti.com> wrote:
>>>> 
>>>>> 
>>>>> Hi,
>>>>> 
>>>>> Paul Jones <p.jo...@teclyn.com> writes:
>>>>>> On 10 Oct 2015, at 16:32, Paul Jones <p.jo...@teclyn.com> wrote:
>>>>>> 
>>>>>>> I came across the following kernel message on the latest 4.3-rc4 whilst
>> performance testing on a USB3380 device connected to a Mac (10.9.5):
>>>>>>> 
>>>>>>> [   51.613838] WARNING: CPU: 2 PID: 0 at
>> drivers/usb/gadget/function/f_mass_storage.c:346 fsg_setup+0x12a/0x170
>> [usb_f_mass_storage]()
>>>>>>> [   51.613838] Modules linked in: usb_f_mass_storage libcomposite
>> configfs drbg ansi_cprng ctr ccm arc4 snd_hda_codec_hdmi iwlmvm i915
>> mac80211 snd_hda_codec_realtek snd_hda_codec_generic hid_generic
>> intel_rapl iosf_mbi x86_pkg_temp_thermal intel_powerclamp coretemp iwlwifi
>> kvm_intel cfg80211 kvm drm_kms_helper drm snd_hda_intel snd_hda_codec
>> btusb btrtl crct10dif_pclmul crc32_pclmul btbcm snd_hda_core
>> ghash_clmulni_intel btintel bluetooth snd_hwdep e1000e aesni_intel
>> aes_x86_64 lrw snd_pcm gf128mul glue_helper ablk_helper cryptd serio_raw
>> alx mei_me lpc_ich usbhid mei snd_timer snd net2280 i2c_algo_bit ptp
>> udc_core fb_sys_fops mdio syscopyarea pps_core sysfillrect soundcore
>> sysimgblt i2c_hid hid video dw_dmac sdhci_acpi shpchp
>> i2c_designware_platform dw_dmac_core spi_pxa2xx_platform sdhci 8250_dw
>> i2c_designware_core acpi_pad lp mac_hid parport
>>>>>>> [   51.613858] CPU: 2 PID: 0 Comm: swapper/2 Tainted: GW
>> 4.3.0-rc4+ #4
>>>>>>> [   51.613859] Hardware name: Gigabyte Technology Co., Ltd. H97N-
>> WIFI/H97N-WIFI, BIOS F7 04/21/2015
>>>>>>> [   51.613860]  a03e9e10 88021eb03d70 81393f5d
>> 
>>>>>>> [   51.613861]  88021eb03da8 81075856 880037be4400
>> 88020b3023c8
>>>>>>> [   51.613862]  880037be4400 ffa1 
>> 88021eb03db8
>>>>>>> [   51.613863] Call Trace:
>>>>>>> [   51.613864][] dump_stack+0x44/0x57
>>>>>>> [   51.613867]  [] warn_slowpath_common+0x86/0xc0
>>>>>>> [   51.613868]  [] warn_slowpath_null+0x1a/0x20
>>>>>>> [   51.613870]  [] fsg_setup+0x12a/0x170
>> [usb_f_mass_storage]
>>>>>>> [   51.613872]  [] composite_setup+0x173/0x16b0
>> [libcomposite]
>>>>>>> [   51.613873]  [] ? ktime_get+0x3a/0x90
>>>>>>> [   51.613874]  [] ? lapic_next_deadline+0x29/0x30
>>>>>>> [   51.613875]  [] ? ktime_get+0x3a/0x90
>>>>>>> [   51.613877]  [] net2280_irq+0xba2/0x10db
>> [net2280]
>>>>>>> [   51.613879]  []
>> handle_irq_event_percpu+0x39/0x180
>>>>>>> [   51.613880]  [] handle_irq_event+0x45/0x70
>>>>>>> [   51.613881]  [] handle_edge_irq+0x99/0x150
>>>>>>> [   51.613883]  [] handle_irq+0x1d/0x30
>>>>>>> [   51.613883]  [] do_IRQ+0x4d/0xd0
>>>>>>> [   51.613885]  [] common_interrupt+0x87/0x87
>>>>>>> [   51.613885][] ?
>> cpuidle_enter_state+0xb8/0x220
>>>>>>> [   51.613888]  [] cpuidle_enter+0x17/0x20
>>>>>>> [   51.613889]  [] call_cpuidle+0x32/0x60
>>>>>>> [   51.613890]  [] ? cpuidle_select+0x13/0x20
>>>>>>> [   51.613891]  [] cpu_startup_entry+0x21c/0x2e0
>>>>>>> [   51.613891]  [] start_secondary+0x104/0x130
>>>>>>> [   51.613892] ---[ end trace bda1c37ade46c57d ]
>>>>>>> 
>>>>>>> I can also reliable reproduce this by connecting the USB3380 to a USB
>> port on the same Linux machine.
>>>>>>> In that case I also see an error:
>>>>>>> net2280 : net2280_enable: error=-

Re: Crash in usb_f_mass_storage

[Paul Jones]

On 14 Oct 2015, at 14:57, Felipe Balbi <ba...@ti.com> wrote:

> 
> Hi,
> 
> Paul Jones <p.jo...@teclyn.com> writes:
>> Hi,
>> 
>> On 12 Oct 2015, at 14:16, Felipe Balbi <ba...@ti.com> wrote:
>> 
>>> 
>>> Hi,
>>> 
>>> Paul Jones <p.jo...@teclyn.com> writes:
>>>> On 10 Oct 2015, at 16:32, Paul Jones <p.jo...@teclyn.com> wrote:
>>>> 
>>>>> I came across the following kernel message on the latest 4.3-rc4 whilst 
>>>>> performance testing on a USB3380 device connected to a Mac (10.9.5):
>>>>> 
>>>>> [   51.613838] WARNING: CPU: 2 PID: 0 at 
>>>>> drivers/usb/gadget/function/f_mass_storage.c:346 fsg_setup+0x12a/0x170 
>>>>> [usb_f_mass_storage]()
>>>>> [   51.613838] Modules linked in: usb_f_mass_storage libcomposite 
>>>>> configfs drbg ansi_cprng ctr ccm arc4 snd_hda_codec_hdmi iwlmvm i915 
>>>>> mac80211 snd_hda_codec_realtek snd_hda_codec_generic hid_generic 
>>>>> intel_rapl iosf_mbi x86_pkg_temp_thermal intel_powerclamp coretemp 
>>>>> iwlwifi kvm_intel cfg80211 kvm drm_kms_helper drm snd_hda_intel 
>>>>> snd_hda_codec btusb btrtl crct10dif_pclmul crc32_pclmul btbcm 
>>>>> snd_hda_core ghash_clmulni_intel btintel bluetooth snd_hwdep e1000e 
>>>>> aesni_intel aes_x86_64 lrw snd_pcm gf128mul glue_helper ablk_helper 
>>>>> cryptd serio_raw alx mei_me lpc_ich usbhid mei snd_timer snd net2280 
>>>>> i2c_algo_bit ptp udc_core fb_sys_fops mdio syscopyarea pps_core 
>>>>> sysfillrect soundcore sysimgblt i2c_hid hid video dw_dmac sdhci_acpi 
>>>>> shpchp i2c_designware_platform dw_dmac_core spi_pxa2xx_platform sdhci 
>>>>> 8250_dw i2c_designware_core acpi_pad lp mac_hid parport
>>>>> [   51.613858] CPU: 2 PID: 0 Comm: swapper/2 Tainted: GW   
>>>>> 4.3.0-rc4+ #4
>>>>> [   51.613859] Hardware name: Gigabyte Technology Co., Ltd. 
>>>>> H97N-WIFI/H97N-WIFI, BIOS F7 04/21/2015
>>>>> [   51.613860]  a03e9e10 88021eb03d70 81393f5d 
>>>>> 
>>>>> [   51.613861]  88021eb03da8 81075856 880037be4400 
>>>>> 88020b3023c8
>>>>> [   51.613862]  880037be4400 ffa1  
>>>>> 88021eb03db8
>>>>> [   51.613863] Call Trace:
>>>>> [   51.613864][] dump_stack+0x44/0x57
>>>>> [   51.613867]  [] warn_slowpath_common+0x86/0xc0
>>>>> [   51.613868]  [] warn_slowpath_null+0x1a/0x20
>>>>> [   51.613870]  [] fsg_setup+0x12a/0x170 
>>>>> [usb_f_mass_storage]
>>>>> [   51.613872]  [] composite_setup+0x173/0x16b0 
>>>>> [libcomposite]
>>>>> [   51.613873]  [] ? ktime_get+0x3a/0x90
>>>>> [   51.613874]  [] ? lapic_next_deadline+0x29/0x30
>>>>> [   51.613875]  [] ? ktime_get+0x3a/0x90
>>>>> [   51.613877]  [] net2280_irq+0xba2/0x10db [net2280]
>>>>> [   51.613879]  [] handle_irq_event_percpu+0x39/0x180
>>>>> [   51.613880]  [] handle_irq_event+0x45/0x70
>>>>> [   51.613881]  [] handle_edge_irq+0x99/0x150
>>>>> [   51.613883]  [] handle_irq+0x1d/0x30
>>>>> [   51.613883]  [] do_IRQ+0x4d/0xd0
>>>>> [   51.613885]  [] common_interrupt+0x87/0x87
>>>>> [   51.613885][] ? 
>>>>> cpuidle_enter_state+0xb8/0x220
>>>>> [   51.613888]  [] cpuidle_enter+0x17/0x20
>>>>> [   51.613889]  [] call_cpuidle+0x32/0x60
>>>>> [   51.613890]  [] ? cpuidle_select+0x13/0x20
>>>>> [   51.613891]  [] cpu_startup_entry+0x21c/0x2e0
>>>>> [   51.613891]  [] start_secondary+0x104/0x130
>>>>> [   51.613892] ---[ end trace bda1c37ade46c57d ]—
>>>>> 
>>>>> I can also reliable reproduce this by connecting the USB3380 to a USB 
>>>>> port on the same Linux machine.
>>>>> In that case I also see an error:
>>>>> net2280 : net2280_enable: error=-22
>>>>> 
>>>>> Perhaps unrelated, but there is also a message:
>>>>> configfs-gadget gadget: common->fsg is NULL in fsg_setup at 511
>>>> The same crash happens in 4.2 as well but not in 4.1.
>>> 
>>> care to run a git bisect and find offending commit ?
>> Unfortunately I encountered many kernels that hung my machine during a
>> git bisect, so I had to git bisect skip many a time.
>> 
>> Here’s the git bisect result (between v4.1 and v4.2):
>> There are only 'skip'ped commits left to test.
>> The first bad commit could be any of:
>> 4117a60c8e4c8d5f9fc05578e359d09d0fdf9d07
>> 4ae82e5d23961515796d76850499db3866c5e73b
>> We cannot bisect more!
>> 
>> Oddly neither of those commits seem very relevant to the problem. Not
>> sure if this helps…
> 
> Likely a problematic bisect, unfortunately this isn't helpful at all.
I’ll try again and see if I can find a way to avoid the hangs that I had before.

Paul.

--
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: Crash in usb_f_mass_storage

[Paul Jones]

On 12 Oct 2015, at 14:16, Felipe Balbi <ba...@ti.com> wrote:

> 
> Hi,
> 
> Paul Jones <p.jo...@teclyn.com> writes:
>> On 10 Oct 2015, at 16:32, Paul Jones <p.jo...@teclyn.com> wrote:
>> 
>>> I came across the following kernel message on the latest 4.3-rc4 whilst 
>>> performance testing on a USB3380 device connected to a Mac (10.9.5):
>>> 
>>> [   51.613838] WARNING: CPU: 2 PID: 0 at 
>>> drivers/usb/gadget/function/f_mass_storage.c:346 fsg_setup+0x12a/0x170 
>>> [usb_f_mass_storage]()
>>> [   51.613838] Modules linked in: usb_f_mass_storage libcomposite configfs 
>>> drbg ansi_cprng ctr ccm arc4 snd_hda_codec_hdmi iwlmvm i915 mac80211 
>>> snd_hda_codec_realtek snd_hda_codec_generic hid_generic intel_rapl iosf_mbi 
>>> x86_pkg_temp_thermal intel_powerclamp coretemp iwlwifi kvm_intel cfg80211 
>>> kvm drm_kms_helper drm snd_hda_intel snd_hda_codec btusb btrtl 
>>> crct10dif_pclmul crc32_pclmul btbcm snd_hda_core ghash_clmulni_intel 
>>> btintel bluetooth snd_hwdep e1000e aesni_intel aes_x86_64 lrw snd_pcm 
>>> gf128mul glue_helper ablk_helper cryptd serio_raw alx mei_me lpc_ich usbhid 
>>> mei snd_timer snd net2280 i2c_algo_bit ptp udc_core fb_sys_fops mdio 
>>> syscopyarea pps_core sysfillrect soundcore sysimgblt i2c_hid hid video 
>>> dw_dmac sdhci_acpi shpchp i2c_designware_platform dw_dmac_core 
>>> spi_pxa2xx_platform sdhci 8250_dw i2c_designware_core acpi_pad lp mac_hid 
>>> parport
>>> [   51.613858] CPU: 2 PID: 0 Comm: swapper/2 Tainted: GW   
>>> 4.3.0-rc4+ #4
>>> [   51.613859] Hardware name: Gigabyte Technology Co., Ltd. 
>>> H97N-WIFI/H97N-WIFI, BIOS F7 04/21/2015
>>> [   51.613860]  a03e9e10 88021eb03d70 81393f5d 
>>> 
>>> [   51.613861]  88021eb03da8 81075856 880037be4400 
>>> 88020b3023c8
>>> [   51.613862]  880037be4400 ffa1  
>>> 88021eb03db8
>>> [   51.613863] Call Trace:
>>> [   51.613864][] dump_stack+0x44/0x57
>>> [   51.613867]  [] warn_slowpath_common+0x86/0xc0
>>> [   51.613868]  [] warn_slowpath_null+0x1a/0x20
>>> [   51.613870]  [] fsg_setup+0x12a/0x170 
>>> [usb_f_mass_storage]
>>> [   51.613872]  [] composite_setup+0x173/0x16b0 
>>> [libcomposite]
>>> [   51.613873]  [] ? ktime_get+0x3a/0x90
>>> [   51.613874]  [] ? lapic_next_deadline+0x29/0x30
>>> [   51.613875]  [] ? ktime_get+0x3a/0x90
>>> [   51.613877]  [] net2280_irq+0xba2/0x10db [net2280]
>>> [   51.613879]  [] handle_irq_event_percpu+0x39/0x180
>>> [   51.613880]  [] handle_irq_event+0x45/0x70
>>> [   51.613881]  [] handle_edge_irq+0x99/0x150
>>> [   51.613883]  [] handle_irq+0x1d/0x30
>>> [   51.613883]  [] do_IRQ+0x4d/0xd0
>>> [   51.613885]  [] common_interrupt+0x87/0x87
>>> [   51.613885][] ? cpuidle_enter_state+0xb8/0x220
>>> [   51.613888]  [] cpuidle_enter+0x17/0x20
>>> [   51.613889]  [] call_cpuidle+0x32/0x60
>>> [   51.613890]  [] ? cpuidle_select+0x13/0x20
>>> [   51.613891]  [] cpu_startup_entry+0x21c/0x2e0
>>> [   51.613891]  [] start_secondary+0x104/0x130
>>> [   51.613892] ---[ end trace bda1c37ade46c57d ]—
>>> 
>>> I can also reliable reproduce this by connecting the USB3380 to a USB port 
>>> on the same Linux machine.
>>> In that case I also see an error:
>>> net2280 : net2280_enable: error=-22
>>> 
>>> Perhaps unrelated, but there is also a message:
>>> configfs-gadget gadget: common->fsg is NULL in fsg_setup at 511
>> The same crash happens in 4.2 as well but not in 4.1.
> 
> care to run a git bisect and find offending commit ?
Unfortunately I encountered many kernels that hung my machine during a git 
bisect, so I had to git bisect skip many a time.
Here’s the git bisect result (between v4.1 and v4.2):
  There are only 'skip'ped commits left to test.
  The first bad commit could be any of:
  4117a60c8e4c8d5f9fc05578e359d09d0fdf9d07
  4ae82e5d23961515796d76850499db3866c5e73b
  We cannot bisect more!

Oddly neither of those commits seem very relevant to the problem. Not sure if 
this helps…

Paul.

--
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: Crash in usb_f_mass_storage

[Paul Jones]

On 14 Oct 2015, at 15:37, Alan Stern <st...@rowland.harvard.edu> wrote:

> On Wed, 14 Oct 2015, Paul Jones wrote:
> 
>> On 12 Oct 2015, at 14:16, Felipe Balbi <ba...@ti.com> wrote:
>> 
>>> 
>>> Hi,
>>> 
>>> Paul Jones <p.jo...@teclyn.com> writes:
>>>> On 10 Oct 2015, at 16:32, Paul Jones <p.jo...@teclyn.com> wrote:
>>>> 
>>>>> I came across the following kernel message on the latest 4.3-rc4 whilst 
>>>>> performance testing on a USB3380 device connected to a Mac (10.9.5):
>>>>> 
>>>>> [   51.613838] WARNING: CPU: 2 PID: 0 at 
>>>>> drivers/usb/gadget/function/f_mass_storage.c:346 fsg_setup+0x12a/0x170 
>>>>> [usb_f_mass_storage]()
>>>>> [   51.613838] Modules linked in: usb_f_mass_storage libcomposite 
>>>>> configfs drbg ansi_cprng ctr ccm arc4 snd_hda_codec_hdmi iwlmvm i915 
>>>>> mac80211 snd_hda_codec_realtek snd_hda_codec_generic hid_generic 
>>>>> intel_rapl iosf_mbi x86_pkg_temp_thermal intel_powerclamp coretemp 
>>>>> iwlwifi kvm_intel cfg80211 kvm drm_kms_helper drm snd_hda_intel 
>>>>> snd_hda_codec btusb btrtl crct10dif_pclmul crc32_pclmul btbcm 
>>>>> snd_hda_core ghash_clmulni_intel btintel bluetooth snd_hwdep e1000e 
>>>>> aesni_intel aes_x86_64 lrw snd_pcm gf128mul glue_helper ablk_helper 
>>>>> cryptd serio_raw alx mei_me lpc_ich usbhid mei snd_timer snd net2280 
>>>>> i2c_algo_bit ptp udc_core fb_sys_fops mdio syscopyarea pps_core 
>>>>> sysfillrect soundcore sysimgblt i2c_hid hid video dw_dmac sdhci_acpi 
>>>>> shpchp i2c_designware_platform dw_dmac_core spi_pxa2xx_platform sdhci 
>>>>> 8250_dw i2c_designware_core acpi_pad lp mac_hid parport
>>>>> [   51.613858] CPU: 2 PID: 0 Comm: swapper/2 Tainted: GW   
>>>>> 4.3.0-rc4+ #4
>>>>> [   51.613859] Hardware name: Gigabyte Technology Co., Ltd. 
>>>>> H97N-WIFI/H97N-WIFI, BIOS F7 04/21/2015
>>>>> [   51.613860]  a03e9e10 88021eb03d70 81393f5d 
>>>>> 
>>>>> [   51.613861]  88021eb03da8 81075856 880037be4400 
>>>>> 88020b3023c8
>>>>> [   51.613862]  880037be4400 ffa1  
>>>>> 88021eb03db8
>>>>> [   51.613863] Call Trace:
>>>>> [   51.613864][] dump_stack+0x44/0x57
>>>>> [   51.613867]  [] warn_slowpath_common+0x86/0xc0
>>>>> [   51.613868]  [] warn_slowpath_null+0x1a/0x20
>>>>> [   51.613870]  [] fsg_setup+0x12a/0x170 
>>>>> [usb_f_mass_storage]
>>>>> [   51.613872]  [] composite_setup+0x173/0x16b0 
>>>>> [libcomposite]
>>>>> [   51.613873]  [] ? ktime_get+0x3a/0x90
>>>>> [   51.613874]  [] ? lapic_next_deadline+0x29/0x30
>>>>> [   51.613875]  [] ? ktime_get+0x3a/0x90
>>>>> [   51.613877]  [] net2280_irq+0xba2/0x10db [net2280]
>>>>> [   51.613879]  [] handle_irq_event_percpu+0x39/0x180
>>>>> [   51.613880]  [] handle_irq_event+0x45/0x70
>>>>> [   51.613881]  [] handle_edge_irq+0x99/0x150
>>>>> [   51.613883]  [] handle_irq+0x1d/0x30
>>>>> [   51.613883]  [] do_IRQ+0x4d/0xd0
>>>>> [   51.613885]  [] common_interrupt+0x87/0x87
>>>>> [   51.613885][] ? 
>>>>> cpuidle_enter_state+0xb8/0x220
>>>>> [   51.613888]  [] cpuidle_enter+0x17/0x20
>>>>> [   51.613889]  [] call_cpuidle+0x32/0x60
>>>>> [   51.613890]  [] ? cpuidle_select+0x13/0x20
>>>>> [   51.613891]  [] cpu_startup_entry+0x21c/0x2e0
>>>>> [   51.613891]  [] start_secondary+0x104/0x130
>>>>> [   51.613892] ---[ end trace bda1c37ade46c57d ]�
>>>>> 
>>>>> I can also reliable reproduce this by connecting the USB3380 to a USB 
>>>>> port on the same Linux machine.
>>>>> In that case I also see an error:
>>>>> net2280 : net2280_enable: error=-22
>>>>> 
>>>>> Perhaps unrelated, but there is also a message:
>>>>> configfs-gadget gadget: common->fsg is NULL in fsg_setup at 511
>>>> The same crash happens in 4.2 as well but not in 4.1.
>>> 
>>> care to run a git bisect and find offending commit ?
>> Unfortunately I encountered many kernels that hung my machine during a git 
>> bisect, so I had to git bisect skip many a time.
>> Here�s the git bisect result (between v4.1 and v4.2):
>>  There are only 'skip'ped commits left to test.
>>  The first bad commit could be any of:
>>  4117a60c8e4c8d5f9fc05578e359d09d0fdf9d07
>>  4ae82e5d23961515796d76850499db3866c5e73b
>>  We cannot bisect more!
>> 
>> Oddly neither of those commits seem very relevant to the problem. Not sure 
>> if this helps�
> 
> Mian Yousaf Kaukab added a bunch of changes to the net2280 driver 
> between 4.1 and 4.2.  Do:
> 
>   git log v4.1..v4.2 -- drivers/usb/gadget/udc/net2280.c
> 
> One of them may be responsible.
I’ll try a manual bisect based on that.

Paul.

--
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: Crash in usb_f_mass_storage

[Paul Jones]

On 14 Oct 2015, at 15:37, Alan Stern <st...@rowland.harvard.edu> wrote:

> On Wed, 14 Oct 2015, Paul Jones wrote:
> 
>> On 12 Oct 2015, at 14:16, Felipe Balbi <ba...@ti.com> wrote:
>> 
>>> 
>>> Hi,
>>> 
>>> Paul Jones <p.jo...@teclyn.com> writes:
>>>> On 10 Oct 2015, at 16:32, Paul Jones <p.jo...@teclyn.com> wrote:
>>>> 
>>>>> I came across the following kernel message on the latest 4.3-rc4 whilst 
>>>>> performance testing on a USB3380 device connected to a Mac (10.9.5):
>>>>> 
>>>>> [   51.613838] WARNING: CPU: 2 PID: 0 at 
>>>>> drivers/usb/gadget/function/f_mass_storage.c:346 fsg_setup+0x12a/0x170 
>>>>> [usb_f_mass_storage]()
>>>>> [   51.613838] Modules linked in: usb_f_mass_storage libcomposite 
>>>>> configfs drbg ansi_cprng ctr ccm arc4 snd_hda_codec_hdmi iwlmvm i915 
>>>>> mac80211 snd_hda_codec_realtek snd_hda_codec_generic hid_generic 
>>>>> intel_rapl iosf_mbi x86_pkg_temp_thermal intel_powerclamp coretemp 
>>>>> iwlwifi kvm_intel cfg80211 kvm drm_kms_helper drm snd_hda_intel 
>>>>> snd_hda_codec btusb btrtl crct10dif_pclmul crc32_pclmul btbcm 
>>>>> snd_hda_core ghash_clmulni_intel btintel bluetooth snd_hwdep e1000e 
>>>>> aesni_intel aes_x86_64 lrw snd_pcm gf128mul glue_helper ablk_helper 
>>>>> cryptd serio_raw alx mei_me lpc_ich usbhid mei snd_timer snd net2280 
>>>>> i2c_algo_bit ptp udc_core fb_sys_fops mdio syscopyarea pps_core 
>>>>> sysfillrect soundcore sysimgblt i2c_hid hid video dw_dmac sdhci_acpi 
>>>>> shpchp i2c_designware_platform dw_dmac_core spi_pxa2xx_platform sdhci 
>>>>> 8250_dw i2c_designware_core acpi_pad lp mac_hid parport
>>>>> [   51.613858] CPU: 2 PID: 0 Comm: swapper/2 Tainted: GW   
>>>>> 4.3.0-rc4+ #4
>>>>> [   51.613859] Hardware name: Gigabyte Technology Co., Ltd. 
>>>>> H97N-WIFI/H97N-WIFI, BIOS F7 04/21/2015
>>>>> [   51.613860]  a03e9e10 88021eb03d70 81393f5d 
>>>>> 
>>>>> [   51.613861]  88021eb03da8 81075856 880037be4400 
>>>>> 88020b3023c8
>>>>> [   51.613862]  880037be4400 ffa1  
>>>>> 88021eb03db8
>>>>> [   51.613863] Call Trace:
>>>>> [   51.613864][] dump_stack+0x44/0x57
>>>>> [   51.613867]  [] warn_slowpath_common+0x86/0xc0
>>>>> [   51.613868]  [] warn_slowpath_null+0x1a/0x20
>>>>> [   51.613870]  [] fsg_setup+0x12a/0x170 
>>>>> [usb_f_mass_storage]
>>>>> [   51.613872]  [] composite_setup+0x173/0x16b0 
>>>>> [libcomposite]
>>>>> [   51.613873]  [] ? ktime_get+0x3a/0x90
>>>>> [   51.613874]  [] ? lapic_next_deadline+0x29/0x30
>>>>> [   51.613875]  [] ? ktime_get+0x3a/0x90
>>>>> [   51.613877]  [] net2280_irq+0xba2/0x10db [net2280]
>>>>> [   51.613879]  [] handle_irq_event_percpu+0x39/0x180
>>>>> [   51.613880]  [] handle_irq_event+0x45/0x70
>>>>> [   51.613881]  [] handle_edge_irq+0x99/0x150
>>>>> [   51.613883]  [] handle_irq+0x1d/0x30
>>>>> [   51.613883]  [] do_IRQ+0x4d/0xd0
>>>>> [   51.613885]  [] common_interrupt+0x87/0x87
>>>>> [   51.613885][] ? 
>>>>> cpuidle_enter_state+0xb8/0x220
>>>>> [   51.613888]  [] cpuidle_enter+0x17/0x20
>>>>> [   51.613889]  [] call_cpuidle+0x32/0x60
>>>>> [   51.613890]  [] ? cpuidle_select+0x13/0x20
>>>>> [   51.613891]  [] cpu_startup_entry+0x21c/0x2e0
>>>>> [   51.613891]  [] start_secondary+0x104/0x130
>>>>> [   51.613892] ---[ end trace bda1c37ade46c57d ]�
>>>>> 
>>>>> I can also reliable reproduce this by connecting the USB3380 to a USB 
>>>>> port on the same Linux machine.
>>>>> In that case I also see an error:
>>>>> net2280 : net2280_enable: error=-22
>>>>> 
>>>>> Perhaps unrelated, but there is also a message:
>>>>> configfs-gadget gadget: common->fsg is NULL in fsg_setup at 511
>>>> The same crash happens in 4.2 as well but not in 4.1.
>>> 
>>> care to run a git bisect and find offending commit ?
>> Unfortunately I encountered many kernels that hung my machine during a git 
>> bisect, so I had to git bisect skip 

Crash in usb_f_mass_storage

[Paul Jones]

I came across the following kernel message on the latest 4.3-rc4 whilst 
performance testing on a USB3380 device connected to a Mac (10.9.5):

[   51.613838] WARNING: CPU: 2 PID: 0 at 
drivers/usb/gadget/function/f_mass_storage.c:346 fsg_setup+0x12a/0x170 
[usb_f_mass_storage]()
[   51.613838] Modules linked in: usb_f_mass_storage libcomposite configfs drbg 
ansi_cprng ctr ccm arc4 snd_hda_codec_hdmi iwlmvm i915 mac80211 
snd_hda_codec_realtek snd_hda_codec_generic hid_generic intel_rapl iosf_mbi 
x86_pkg_temp_thermal intel_powerclamp coretemp iwlwifi kvm_intel cfg80211 kvm 
drm_kms_helper drm snd_hda_intel snd_hda_codec btusb btrtl crct10dif_pclmul 
crc32_pclmul btbcm snd_hda_core ghash_clmulni_intel btintel bluetooth snd_hwdep 
e1000e aesni_intel aes_x86_64 lrw snd_pcm gf128mul glue_helper ablk_helper 
cryptd serio_raw alx mei_me lpc_ich usbhid mei snd_timer snd net2280 
i2c_algo_bit ptp udc_core fb_sys_fops mdio syscopyarea pps_core sysfillrect 
soundcore sysimgblt i2c_hid hid video dw_dmac sdhci_acpi shpchp 
i2c_designware_platform dw_dmac_core spi_pxa2xx_platform sdhci 8250_dw 
i2c_designware_core acpi_pad lp mac_hid parport
[   51.613858] CPU: 2 PID: 0 Comm: swapper/2 Tainted: GW   
4.3.0-rc4+ #4
[   51.613859] Hardware name: Gigabyte Technology Co., Ltd. 
H97N-WIFI/H97N-WIFI, BIOS F7 04/21/2015
[   51.613860]  a03e9e10 88021eb03d70 81393f5d 

[   51.613861]  88021eb03da8 81075856 880037be4400 
88020b3023c8
[   51.613862]  880037be4400 ffa1  
88021eb03db8
[   51.613863] Call Trace:
[   51.613864][] dump_stack+0x44/0x57
[   51.613867]  [] warn_slowpath_common+0x86/0xc0
[   51.613868]  [] warn_slowpath_null+0x1a/0x20
[   51.613870]  [] fsg_setup+0x12a/0x170 [usb_f_mass_storage]
[   51.613872]  [] composite_setup+0x173/0x16b0 [libcomposite]
[   51.613873]  [] ? ktime_get+0x3a/0x90
[   51.613874]  [] ? lapic_next_deadline+0x29/0x30
[   51.613875]  [] ? ktime_get+0x3a/0x90
[   51.613877]  [] net2280_irq+0xba2/0x10db [net2280]
[   51.613879]  [] handle_irq_event_percpu+0x39/0x180
[   51.613880]  [] handle_irq_event+0x45/0x70
[   51.613881]  [] handle_edge_irq+0x99/0x150
[   51.613883]  [] handle_irq+0x1d/0x30
[   51.613883]  [] do_IRQ+0x4d/0xd0
[   51.613885]  [] common_interrupt+0x87/0x87
[   51.613885][] ? cpuidle_enter_state+0xb8/0x220
[   51.613888]  [] cpuidle_enter+0x17/0x20
[   51.613889]  [] call_cpuidle+0x32/0x60
[   51.613890]  [] ? cpuidle_select+0x13/0x20
[   51.613891]  [] cpu_startup_entry+0x21c/0x2e0
[   51.613891]  [] start_secondary+0x104/0x130
[   51.613892] ---[ end trace bda1c37ade46c57d ]—

I can also reliable reproduce this by connecting the USB3380 to a USB port on 
the same Linux machine.
In that case I also see an error:
net2280 : net2280_enable: error=-22

Perhaps unrelated, but there is also a message:
configfs-gadget gadget: common->fsg is NULL in fsg_setup at 511

Paul.--
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: mass storage behaviour

[Paul Jones]

On 06 Oct 2015, at 13:26, Paul Zimmerman  wrote:

> On Tue, Oct 6, 2015 at 10:01 AM, Alan Stern  wrote:
>> On Tue, 6 Oct 2015, Felipe Balbi wrote:
>> 
> In my experience, you need to do at least the following to get max
> performance from the mass storage gadget:
> 
> - Use Windows 8 or higher on the host. It's much faster than Linux.
>> 
>> Why is Windows so much faster?  Or to put it another way, why is Linux
>> slow?  How can we improve things?
> 
> I don't know. We were doing our performance demos using Windows, so we
> never looked into why Linux was slower. But I do know the Microsoft
> engineers put some effort into tuning their stack for good performance
> at USB 3.0 speeds. I don't think anyone has done that for Linux yet.
It seems that Mac OSX is faster when using a file system on an emulated device.
dd directly to the block device on my Mac gives me around 137MB/s, whilst 
copying data onto a mounted filesystem (also with dd) runs at over 180MB/s.

Paul.--
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: mass storage behaviour

[Paul Jones]

On 10 Oct 2015, at 16:34, Alan Stern <st...@rowland.harvard.edu> wrote:

> On Sat, 10 Oct 2015, Paul Jones wrote:
> 
>>>> Why is Windows so much faster?  Or to put it another way, why is Linux
>>>> slow?  How can we improve things?
>>> 
>>> I don't know. We were doing our performance demos using Windows, so we
>>> never looked into why Linux was slower. But I do know the Microsoft
>>> engineers put some effort into tuning their stack for good performance
>>> at USB 3.0 speeds. I don't think anyone has done that for Linux yet.
>> It seems that Mac OSX is faster when using a file system on an emulated 
>> device.
>> dd directly to the block device on my Mac gives me around 137MB/s, whilst 
>> copying data onto a mounted filesystem (also with dd) runs at over 180MB/s.
> 
> I don't see how this comment is relevant to the question at hand, 
> namely, why does the mass-storage gadget run faster when attached to a 
> Windows host than when attached to a Linux host.

> 
> I also don't see how "an emulated device" fits in here.  In both tests, 
> you copied data to a block device: once directly and once through the 
> filesystem.  Nothing was emulated.
It’s emulated in the sense that I’m using a gadget to provide a RAM based 
device.

> Finally, are you sure you are seeing the actual throughput and not just
> the rate of copying into a page cache?  It would be better to test
> using reads instead of writes, because a read can't complete before
> the data is retrieved from the device.
Oops, the numbers above are for reading (not writing which is somewhat slower).

Paul.


--
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: Crash in usb_f_mass_storage

[Paul Jones]

On 10 Oct 2015, at 16:32, Paul Jones <p.jo...@teclyn.com> wrote:

> I came across the following kernel message on the latest 4.3-rc4 whilst 
> performance testing on a USB3380 device connected to a Mac (10.9.5):
> 
> [   51.613838] WARNING: CPU: 2 PID: 0 at 
> drivers/usb/gadget/function/f_mass_storage.c:346 fsg_setup+0x12a/0x170 
> [usb_f_mass_storage]()
> [   51.613838] Modules linked in: usb_f_mass_storage libcomposite configfs 
> drbg ansi_cprng ctr ccm arc4 snd_hda_codec_hdmi iwlmvm i915 mac80211 
> snd_hda_codec_realtek snd_hda_codec_generic hid_generic intel_rapl iosf_mbi 
> x86_pkg_temp_thermal intel_powerclamp coretemp iwlwifi kvm_intel cfg80211 kvm 
> drm_kms_helper drm snd_hda_intel snd_hda_codec btusb btrtl crct10dif_pclmul 
> crc32_pclmul btbcm snd_hda_core ghash_clmulni_intel btintel bluetooth 
> snd_hwdep e1000e aesni_intel aes_x86_64 lrw snd_pcm gf128mul glue_helper 
> ablk_helper cryptd serio_raw alx mei_me lpc_ich usbhid mei snd_timer snd 
> net2280 i2c_algo_bit ptp udc_core fb_sys_fops mdio syscopyarea pps_core 
> sysfillrect soundcore sysimgblt i2c_hid hid video dw_dmac sdhci_acpi shpchp 
> i2c_designware_platform dw_dmac_core spi_pxa2xx_platform sdhci 8250_dw 
> i2c_designware_core acpi_pad lp mac_hid parport
> [   51.613858] CPU: 2 PID: 0 Comm: swapper/2 Tainted: GW   
> 4.3.0-rc4+ #4
> [   51.613859] Hardware name: Gigabyte Technology Co., Ltd. 
> H97N-WIFI/H97N-WIFI, BIOS F7 04/21/2015
> [   51.613860]  a03e9e10 88021eb03d70 81393f5d 
> 
> [   51.613861]  88021eb03da8 81075856 880037be4400 
> 88020b3023c8
> [   51.613862]  880037be4400 ffa1  
> 88021eb03db8
> [   51.613863] Call Trace:
> [   51.613864][] dump_stack+0x44/0x57
> [   51.613867]  [] warn_slowpath_common+0x86/0xc0
> [   51.613868]  [] warn_slowpath_null+0x1a/0x20
> [   51.613870]  [] fsg_setup+0x12a/0x170 
> [usb_f_mass_storage]
> [   51.613872]  [] composite_setup+0x173/0x16b0 
> [libcomposite]
> [   51.613873]  [] ? ktime_get+0x3a/0x90
> [   51.613874]  [] ? lapic_next_deadline+0x29/0x30
> [   51.613875]  [] ? ktime_get+0x3a/0x90
> [   51.613877]  [] net2280_irq+0xba2/0x10db [net2280]
> [   51.613879]  [] handle_irq_event_percpu+0x39/0x180
> [   51.613880]  [] handle_irq_event+0x45/0x70
> [   51.613881]  [] handle_edge_irq+0x99/0x150
> [   51.613883]  [] handle_irq+0x1d/0x30
> [   51.613883]  [] do_IRQ+0x4d/0xd0
> [   51.613885]  [] common_interrupt+0x87/0x87
> [   51.613885][] ? cpuidle_enter_state+0xb8/0x220
> [   51.613888]  [] cpuidle_enter+0x17/0x20
> [   51.613889]  [] call_cpuidle+0x32/0x60
> [   51.613890]  [] ? cpuidle_select+0x13/0x20
> [   51.613891]  [] cpu_startup_entry+0x21c/0x2e0
> [   51.613891]  [] start_secondary+0x104/0x130
> [   51.613892] ---[ end trace bda1c37ade46c57d ]—
> 
> I can also reliable reproduce this by connecting the USB3380 to a USB port on 
> the same Linux machine.
> In that case I also see an error:
> net2280 : net2280_enable: error=-22
> 
> Perhaps unrelated, but there is also a message:
> configfs-gadget gadget: common->fsg is NULL in fsg_setup at 511
The same crash happens in 4.2 as well but not in 4.1.

Paul.


--
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: mass storage behaviour

[Paul Jones]

On 07 Oct 2015, at 10:13, Greg KH  wrote:

> On Tue, Oct 06, 2015 at 10:26:08AM -0700, Paul Zimmerman wrote:
>> On Tue, Oct 6, 2015 at 10:01 AM, Alan Stern  
>> wrote:
>>> On Tue, 6 Oct 2015, Felipe Balbi wrote:
>>> 
>> In my experience, you need to do at least the following to get max
>> performance from the mass storage gadget:
>> 
>> - Use Windows 8 or higher on the host. It's much faster than Linux.
>>> 
>>> Why is Windows so much faster?  Or to put it another way, why is Linux
>>> slow?  How can we improve things?
>> 
>> I don't know. We were doing our performance demos using Windows, so we
>> never looked into why Linux was slower. But I do know the Microsoft
>> engineers put some effort into tuning their stack for good performance
>> at USB 3.0 speeds. I don't think anyone has done that for Linux yet.
> 
> I don't believe that, it sounds like a marketing thing :)
> 
> Be aware of your mount options when mounting a device on Linux, some
> distros default to more "safe" options that are slower due to flushing
> data to the disk, it's easy to look faster if all of your data is still
> in caches before being sent to the device.
Currently I am using the raw device with dd so there is no filesystem involved.
However I’ll setup my test machine for dual boot and see if there is a real 
difference.

Paul.

--
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: mass storage behaviour

[Paul Jones]

On 05 Oct 2015, at 23:09, Alan Stern <st...@rowland.harvard.edu> wrote:

> On Mon, 5 Oct 2015, Paul Jones wrote:
> 
>>> Increasing the max_sectors_kb value, on the other hand, might remove
>>> overhead by allowing a higher percentage of the transfer to consist of
>>> real data as opposed to CBW and CSW packets.  This depends to some
>>> extent on other factors (such as whether the memory pages are
>>> contiguous, allowing for larger transfers), but it can't hurt.
>> 
>> I tried changing the max_sectors_kb to 64 with 64k block size in dd and it’s 
>> transferring at the same speed.
> 
> That's a decrease, not an increase.  Try changing it to 1024 or more.
I can’t increase the value, any value over 120 is rejected.
I therefore decided to see if the speed would decrease by decreasing the block 
size, which doesn’t seem to be the case.
Is there a setting somewhere that limits the max_sectors_kb value?

> 
>> I verified using usbmon and it then indeed requests 64k in each request.
>> Increasing the dd block size to 240k doesn’t change the transfer speed 
>> either, and it keeps using alternating 120k/8k requests.
>> Increasing the dd block size to 1M doesn’t change the transfer speed either, 
>> although I get sequences of 2x 120k followed by 1x 16k requests.
> 
> The dd block size makes no difference at all, because the kernel 
> aggregates the requests from dd.
Well given the results I am getting it seems to make some difference, although 
it does not seem to impact speed.

In my current setup I have 35us overhead for responding to the CBW and CSW 
requests (70 us total) and there seems to be some delay in the bulk 
transmission of the data as well as the transmission time for the data is much 
slower than 5Gb/s.
Is there a way to trace the USB frames to see where the delays are occurring 
during the actual data transfer?

Paul.--
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: mass storage behaviour

[Paul Jones]

On 06 Oct 2015, at 16:44, Alan Stern <st...@rowland.harvard.edu> wrote:

> On Tue, 6 Oct 2015, Paul Jones wrote:
> 
>> On 05 Oct 2015, at 23:09, Alan Stern <st...@rowland.harvard.edu> wrote:
>> 
>>> On Mon, 5 Oct 2015, Paul Jones wrote:
>>> 
>>>>> Increasing the max_sectors_kb value, on the other hand, might remove
>>>>> overhead by allowing a higher percentage of the transfer to consist of
>>>>> real data as opposed to CBW and CSW packets.  This depends to some
>>>>> extent on other factors (such as whether the memory pages are
>>>>> contiguous, allowing for larger transfers), but it can't hurt.
>>>> 
>>>> I tried changing the max_sectors_kb to 64 with 64k block size in dd and 
>>>> it�s transferring at the same speed.
>>> 
>>> That's a decrease, not an increase.  Try changing it to 1024 or more.
>> I can�t increase the value, any value over 120 is rejected.
>> I therefore decided to see if the speed would decrease by decreasing the 
>> block size, which doesn�t seem to be the case.
>> Is there a setting somewhere that limits the max_sectors_kb value?
> 
> Yes, there is.  I forgot about this hard limit.  I think you can change
> it by writing to /sys/bus/usb/devices/.../max_sectors, where ... is the
> path for the mass-storage interface of your device.
I changed /sys/block//device/max_sectors to 4096 and 
/sys/block//queue/max_sectors_kb to 2048
That improves matters slightly from 140MB/s to 160MB/s.

Using Paul Zimmerman’s suggestion I can increase that to 174MB/s using a 160k 
buffer. 
However changing to a tmpfs backing file for my gadget makes no difference in 
speed at all.
I guess that means that the delays are actually part of the gadget and/or 
f_mass_storage implementation.

>> In my current setup I have 35us overhead for responding to the CBW
>> and CSW requests (70 us total) and there seems to be some delay in
>> the bulk transmission of the data as well as the transmission time
>> for the data is much slower than 5Gb/s.
> 
> All those things take time.  No doubt some of the delay is the time 
> required to read the data from the backing file.  Most of the rest is 
> transmission time.
> 
> Note that you can never actually attain 5 Gb/s, even under the best 
> circumstances.  For one thing, data on the USB bus is encoded in a way 
> that uses 10 bits on the bus to send 8 bits of data.  So you could 
> never achieve more than 500 MB/s even if there were no packet headers, 
> breaks between packets, and so on.
I would be happy with anything over 300MB/s for sequential transfers.

> 
>> Is there a way to trace the USB frames to see where the delays are
>> occurring during the actual data transfer?
> 
> Sure, if you have a USB bus analyzer.  There's no way to do it in 
> software alone.
Couldn’t we at least use interrupts to timestamp when individual frames are 
sent/received or when DMA starts/completes?

Paul.


--
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

mass storage behaviour

[Paul Jones]

I’m investigating the (lack of) performance (around 150MB/s) of the USB3380 
gadget in mass storage mode.
Whilst tracing on a Linux 4.1 host I noticed that the Linux max storage driver 
is requesting 240 blocks, 16 blocks, 240 blocks, 16 blocks, etc. when doing a 
dd directly on the device:
dd if=/dev/sdb of=/dev/null bs=64k count=8k
where /dev/sdb is the emulated device.
The emulated device is provided from a secondary machine with a USB3380 card 
emulating the mass storage device from a local SSD (local dd of the disk file 
reads at 542 MB/s).

lsusb on the host:
/:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/3p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/8p, 480M
/:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/3p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/6p, 480M
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/6p, 5000M
|__ Port 3: Dev 3, If 0, Class=Mass Storage, Driver=usb-storage, 5000M
|__ Port 6: Dev 4, If 0, Class=Mass Storage, Driver=usb-storage, 5000M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/15p, 480M

lspci on the host:
00:00.0 Host bridge: Intel Corporation 4th Gen Core Processor DRAM Controller 
(rev 06)
00:01.0 PCI bridge: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor 
PCI Express x16 Controller (rev 06)
00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v3/4th Gen 
Core Processor Integrated Graphics Controller (rev 06)
00:03.0 Audio device: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor 
HD Audio Controller (rev 06)
00:14.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family 
USB xHCI (rev 05)
00:16.0 Communication controller: Intel Corporation 8 Series/C220 Series 
Chipset Family MEI Controller #1 (rev 04)
00:16.3 Serial controller: Intel Corporation 8 Series/C220 Series Chipset 
Family KT Controller (rev 04)
00:19.0 Ethernet controller: Intel Corporation Ethernet Connection I217-LM (rev 
05)
00:1a.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family 
USB EHCI #2 (rev 05)
00:1b.0 Audio device: Intel Corporation 8 Series/C220 Series Chipset High 
Definition Audio Controller (rev 05)
00:1c.0 PCI bridge: Intel Corporation 8 Series/C220 Series Chipset Family PCI 
Express Root Port #1 (rev d5)
00:1c.2 PCI bridge: Intel Corporation 8 Series/C220 Series Chipset Family PCI 
Express Root Port #3 (rev d5)
00:1d.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family 
USB EHCI #1 (rev 05)
00:1f.0 ISA bridge: Intel Corporation Q87 Express LPC Controller (rev 05)
00:1f.2 SATA controller: Intel Corporation 8 Series/C220 Series Chipset Family 
6-port SATA Controller 1 [AHCI mode] (rev 05)
00:1f.3 SMBus: Intel Corporation 8 Series/C220 Series Chipset Family SMBus 
Controller (rev 05)

Tracing using usbmon on the host shows:
88002ea45b40 558636438 S Bo:2:003:2 -115 31 = 55534243 63c2  
0600    00
88002ea45b40 558636455 C Bo:2:003:2 0 31 >
88002ea45b40 558636459 S Bi:2:003:1 -115 13 <
88002ea45b40 558636537 C Bi:2:003:1 0 13 = 55534253 63c2  00
88002ea45b40 558636593 S Bo:2:003:2 -115 31 = 55534243 64c2  
061e 0001   00
88002ea45b40 558636610 C Bo:2:003:2 0 31 >
88002ea45b40 558636627 S Bi:2:003:1 -115 13 <
88002ea45b40 558636669 C Bi:2:003:1 0 13 = 55534253 64c2  00
88002ea45b40 558636748 S Bo:2:003:2 -115 31 = 55534243 65c2 00e00100 
8a28  00f0  00
88002ea45b40 558636757 C Bo:2:003:2 0 31 >
880407982f00 558636765 S Bi:2:003:1 -115 122880 <
880407982f00 558637699 C Bi:2:003:1 0 122880 =    
    
88002ea45b40 558637717 S Bi:2:003:1 -115 13 <
88002ea45b40 558637728 C Bi:2:003:1 0 13 = 55534253 65c2  00
88002ea45b40 558637760 S Bo:2:003:2 -115 31 = 55534243 66c2 0020 
8a28  f010  00
88002ea45b40 558637778 C Bo:2:003:2 0 31 >
88040ca76a80 558637797 S Bi:2:003:1 -115 8192 <
88040ca76a80 558637892 C Bi:2:003:1 0 8192 =    
    
88002ea45b40 558637908 S Bi:2:003:1 -115 13 <
88002ea45b40 558637933 C Bi:2:003:1 0 13 = 55534253 66c2  00
88002ea45b40 558637959 S Bo:2:003:2 -115 31 = 55534243 67c2 00e00100 
8a28 0001 00f0  00
88002ea45b40 558637973 C Bo:2:003:2 0 31 >
880407982f00 558637976 S Bi:2:003:1 -115 122880 <
880407982f00 558638898 C Bi:2:003:1 0 122880 =    
    
88002ea45b40 558638901 S Bi:2:003:1 -115 13 <
88002ea45b40 558638938 C Bi:2:003:1 0 13 = 55534253 67c2  00
88002ea45b40 558638976 S Bo:2:003:2 -115 31 = 55534243 68c2 0020 
8a28 0001 f010  00
88002ea45b40 

Re: mass storage behaviour

[Paul Jones]

On 05 Oct 2015, at 20:29, Alan Stern <st...@rowland.harvard.edu> wrote:

> On Mon, 5 Oct 2015, Paul Jones wrote:
> 
>> I�m investigating the (lack of) performance (around 150MB/s) of the USB3380 
>> gadget in mass storage mode.
>> Whilst tracing on a Linux 4.1 host I noticed that the Linux max storage 
>> driver is requesting 240 blocks, 16 blocks, 240 blocks, 16 blocks, etc. when 
>> doing a dd directly on the device:
>>  dd if=/dev/sdb of=/dev/null bs=64k count=8k
>> where /dev/sdb is the emulated device.
>> The emulated device is provided from a secondary machine with a USB3380 card 
>> emulating the mass storage device from a local SSD (local dd of the disk 
>> file reads at 542 MB/s).
>> 
>> lsusb on the host:
>> /:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/3p, 480M
>>|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/8p, 480M
>> /:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/3p, 480M
>>|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/6p, 480M
>> /:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/6p, 5000M
>>|__ Port 3: Dev 3, If 0, Class=Mass Storage, Driver=usb-storage, 5000M
>>|__ Port 6: Dev 4, If 0, Class=Mass Storage, Driver=usb-storage, 5000M
>> /:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/15p, 480M
>> 
>> lspci on the host:
> 
> ...
> 
>> Tracing using usbmon on the host shows:
>> 88002ea45b40 558636438 S Bo:2:003:2 -115 31 = 55534243 63c2  
>> 0600    00
>> 88002ea45b40 558636455 C Bo:2:003:2 0 31 >
>> 88002ea45b40 558636459 S Bi:2:003:1 -115 13 <
>> 88002ea45b40 558636537 C Bi:2:003:1 0 13 = 55534253 63c2  00
>> 88002ea45b40 558636593 S Bo:2:003:2 -115 31 = 55534243 64c2  
>> 061e 0001   00
>> 88002ea45b40 558636610 C Bo:2:003:2 0 31 >
>> 88002ea45b40 558636627 S Bi:2:003:1 -115 13 <
>> 88002ea45b40 558636669 C Bi:2:003:1 0 13 = 55534253 64c2  00
>> 88002ea45b40 558636748 S Bo:2:003:2 -115 31 = 55534243 65c2 00e00100 
>> 8a28  00f0  00
>> 88002ea45b40 558636757 C Bo:2:003:2 0 31 >
>> 880407982f00 558636765 S Bi:2:003:1 -115 122880 <
>> 880407982f00 558637699 C Bi:2:003:1 0 122880 =   
>>      
>> 88002ea45b40 558637717 S Bi:2:003:1 -115 13 <
>> 88002ea45b40 558637728 C Bi:2:003:1 0 13 = 55534253 65c2  00
>> 88002ea45b40 558637760 S Bo:2:003:2 -115 31 = 55534243 66c2 0020 
>> 8a28  f010  00
>> 88002ea45b40 558637778 C Bo:2:003:2 0 31 >
>> 88040ca76a80 558637797 S Bi:2:003:1 -115 8192 <
>> 88040ca76a80 558637892 C Bi:2:003:1 0 8192 =    
>>     
>> 88002ea45b40 558637908 S Bi:2:003:1 -115 13 <
>> 88002ea45b40 558637933 C Bi:2:003:1 0 13 = 55534253 66c2  00
>> 88002ea45b40 558637959 S Bo:2:003:2 -115 31 = 55534243 67c2 00e00100 
>> 8a28 0001 00f0  00
>> 88002ea45b40 558637973 C Bo:2:003:2 0 31 >
>> 880407982f00 558637976 S Bi:2:003:1 -115 122880 <
>> 880407982f00 558638898 C Bi:2:003:1 0 122880 =   
>>      
>> 88002ea45b40 558638901 S Bi:2:003:1 -115 13 <
>> 88002ea45b40 558638938 C Bi:2:003:1 0 13 = 55534253 67c2  00
>> 88002ea45b40 558638976 S Bo:2:003:2 -115 31 = 55534243 68c2 0020 
>> 8a28 0001 f010  00
>> 88002ea45b40 558638984 C Bo:2:003:2 0 31 >
>> 88040ca76a80 558638992 S Bi:2:003:1 -115 8192 <
>> 88040ca76a80 558639095 C Bi:2:003:1 0 8192 =    
>>     
>> 88002ea45b40 558639110 S Bi:2:003:1 -115 13 <
>> 88002ea45b40 558639136 C Bi:2:003:1 0 13 = 55534253 68c2  00
>> 
>> Any ideas why the driver is requesting varying block sizes?
> 
> The usb-storage driver requests what the block layer tells it to
> request.
I’m running a dd with a block size of 64k, so it seems to be aggregating 2 
requests and then splits them again.

> Unless you change the settings, the maximum number of blocks allowed in
> a single transfer is 240 (i.e., 120 KB).  Consequently, 128-KB reads
> get broken up into 120 KB followed by 8 KB.  (You can alter the default
> by writing to /sys/block/sd*/queue/max_sectors_kb --

Re: mass storage behaviour

[Paul Jones]

On 05 Oct 2015, at 20:08, Felipe Balbi <ba...@ti.com> wrote:

> On Mon, Oct 05, 2015 at 07:30:05PM +0200, Paul Jones wrote:
>> I’m investigating the (lack of) performance (around 150MB/s) of the USB3380
>> gadget in mass storage mode.  Whilst tracing on a Linux 4.1 host I noticed
>> that the Linux max storage driver is requesting 240 blocks, 16 blocks, 240
>> blocks, 16 blocks, etc. when doing a dd directly on the device: dd 
>> if=/dev/sdb
>> of=/dev/null bs=64k count=8k where /dev/sdb is the emulated device.  The
>> emulated device is provided from a secondary machine with a USB3380 card
>> emulating the mass storage device from a local SSD (local dd of the disk file
>> reads at 542 MB/s).
>> 
>> lsusb on the host:
>> /:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/3p, 480M
>>|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/8p, 480M
>> /:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/3p, 480M
>>|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/6p, 480M
>> /:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/6p, 5000M
>>|__ Port 3: Dev 3, If 0, Class=Mass Storage, Driver=usb-storage, 5000M
>>|__ Port 6: Dev 4, If 0, Class=Mass Storage, Driver=usb-storage, 5000M
>> /:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/15p, 480M
>> 
>> lspci on the host:
>> 00:00.0 Host bridge: Intel Corporation 4th Gen Core Processor DRAM 
>> Controller (rev 06)
>> 00:01.0 PCI bridge: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor 
>> PCI Express x16 Controller (rev 06)
>> 00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v3/4th Gen 
>> Core Processor Integrated Graphics Controller (rev 06)
>> 00:03.0 Audio device: Intel Corporation Xeon E3-1200 v3/4th Gen Core 
>> Processor HD Audio Controller (rev 06)
>> 00:14.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset 
>> Family USB xHCI (rev 05)
>> 00:16.0 Communication controller: Intel Corporation 8 Series/C220 Series 
>> Chipset Family MEI Controller #1 (rev 04)
>> 00:16.3 Serial controller: Intel Corporation 8 Series/C220 Series Chipset 
>> Family KT Controller (rev 04)
>> 00:19.0 Ethernet controller: Intel Corporation Ethernet Connection I217-LM 
>> (rev 05)
>> 00:1a.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset 
>> Family USB EHCI #2 (rev 05)
>> 00:1b.0 Audio device: Intel Corporation 8 Series/C220 Series Chipset High 
>> Definition Audio Controller (rev 05)
>> 00:1c.0 PCI bridge: Intel Corporation 8 Series/C220 Series Chipset Family 
>> PCI Express Root Port #1 (rev d5)
>> 00:1c.2 PCI bridge: Intel Corporation 8 Series/C220 Series Chipset Family 
>> PCI Express Root Port #3 (rev d5)
>> 00:1d.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset 
>> Family USB EHCI #1 (rev 05)
>> 00:1f.0 ISA bridge: Intel Corporation Q87 Express LPC Controller (rev 05)
>> 00:1f.2 SATA controller: Intel Corporation 8 Series/C220 Series Chipset 
>> Family 6-port SATA Controller 1 [AHCI mode] (rev 05)
>> 00:1f.3 SMBus: Intel Corporation 8 Series/C220 Series Chipset Family SMBus 
>> Controller (rev 05)
>> 
>> Tracing using usbmon on the host shows:
>> 88002ea45b40 558636438 S Bo:2:003:2 -115 31 = 55534243 63c2  
>> 0600    00
>> 88002ea45b40 558636455 C Bo:2:003:2 0 31 >
>> 88002ea45b40 558636459 S Bi:2:003:1 -115 13 <
>> 88002ea45b40 558636537 C Bi:2:003:1 0 13 = 55534253 63c2  00
>> 88002ea45b40 558636593 S Bo:2:003:2 -115 31 = 55534243 64c2  
>> 061e 0001   00
>> 88002ea45b40 558636610 C Bo:2:003:2 0 31 >
>> 88002ea45b40 558636627 S Bi:2:003:1 -115 13 <
>> 88002ea45b40 558636669 C Bi:2:003:1 0 13 = 55534253 64c2  00
>> 88002ea45b40 558636748 S Bo:2:003:2 -115 31 = 55534243 65c2 00e00100 
>> 8a28  00f0  00
>> 88002ea45b40 558636757 C Bo:2:003:2 0 31 >
>> 880407982f00 558636765 S Bi:2:003:1 -115 122880 <
>> 880407982f00 558637699 C Bi:2:003:1 0 122880 =   
>>      
>> 88002ea45b40 558637717 S Bi:2:003:1 -115 13 <
>> 88002ea45b40 558637728 C Bi:2:003:1 0 13 = 55534253 65c2  00
>> 88002ea45b40 558637760 S Bo:2:003:2 -115 31 = 55534243 66c2 0020 
>> 8a28  f010  00
>> 88002ea45b40 558637778 C Bo:2:003:2 0 31 >
>> 88040ca76a80 558637797 S Bi:2:003:1 -115 8192 <
>> 88040ca76

Re: mass storage behaviour

[Paul Jones]

On 05 Oct 2015, at 20:54, Alan Stern <st...@rowland.harvard.edu> wrote:

> On Mon, 5 Oct 2015, Paul Jones wrote:
> 
>>> g_mass_storage, by default, uses 2 struct usb_request, try increasing that 
>>> to 4
>>> (can be done from make menuconfig itself) and see if anything changes.
>> If you are talking about the �number of storage pipeline buffers� I already 
>> have them at 4.
>> I had similar results in previous kernels where I hadn�t set this value to 4.
> 
> My feeling is that the number of buffers won't make a whole lot of 
> difference to the final throughput.  Increasing the number will smooth 
> out variations and remove latencies caused by other tasks.  But the two 
> fundamental limits on the throughput are the USB data transfer rate and 
> the rate at which data can be transferred to/from the backing storage.  
> Whichever is slower will be the bottleneck, and using more buffers 
> won't change that.
> 
> Increasing the max_sectors_kb value, on the other hand, might remove
> overhead by allowing a higher percentage of the transfer to consist of
> real data as opposed to CBW and CSW packets.  This depends to some
> extent on other factors (such as whether the memory pages are
> contiguous, allowing for larger transfers), but it can't hurt.

I tried changing the max_sectors_kb to 64 with 64k block size in dd and it’s 
transferring at the same speed.
I verified using usbmon and it then indeed requests 64k in each request.
Increasing the dd block size to 240k doesn’t change the transfer speed either, 
and it keeps using alternating 120k/8k requests.
Increasing the dd block size to 1M doesn’t change the transfer speed either, 
although I get sequences of 2x 120k followed by 1x 16k requests.

Paul.


--
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 v3 3/3] power: wm831x_power: Support USB charger current limit management

[Lee Jones]

On Tue, 18 Aug 2015, Baolin Wang wrote:

 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.
 
 Signed-off-by: Mark Brown broo...@kernel.org
 Signed-off-by: Baolin Wang baolin.w...@linaro.org
 ---
  drivers/power/wm831x_power.c |   69 
 ++
  include/linux/mfd/wm831x/pdata.h |3 ++

MFD:
  Acked-by: Lee Jones lee.jo...@linaro.org

  2 files changed, 72 insertions(+)
 
 diff --git a/drivers/power/wm831x_power.c b/drivers/power/wm831x_power.c
 index db11ae6..72c661f 100644
 --- a/drivers/power/wm831x_power.c
 +++ b/drivers/power/wm831x_power.c
 @@ -13,6 +13,7 @@
  #include linux/platform_device.h
  #include linux/power_supply.h
  #include linux/slab.h
 +#include linux/usb/usb_charger.h
  
  #include linux/mfd/wm831x/core.h
  #include linux/mfd/wm831x/auxadc.h
 @@ -31,6 +32,8 @@ struct wm831x_power {
   char usb_name[20];
   char battery_name[20];
   bool have_battery;
 + struct usb_charger *usb_charger;
 + struct notifier_block usb_notify;
  };
  
  static int wm831x_power_check_online(struct wm831x *wm831x, int supply,
 @@ -125,6 +128,43 @@ static enum power_supply_property wm831x_usb_props[] = {
   POWER_SUPPLY_PROP_VOLTAGE_NOW,
  };
  
 +/* In miliamps */
 +static unsigned int wm831x_usb_limits[] = {
 + 0,
 + 2,
 + 100,
 + 500,
 + 900,
 + 1500,
 + 1800,
 + 550,
 +};
 +
 +static int wm831x_usb_limit_change(struct notifier_block *nb,
 +unsigned long limit, void *data)
 +{
 + struct wm831x_power *wm831x_power = container_of(nb,
 +  struct wm831x_power,
 +  usb_notify);
 + int i, best;
 +
 + /* Find the highest supported limit */
 + best = 0;
 + for (i = 0; i  ARRAY_SIZE(wm831x_usb_limits); i++) {
 + if (limit  wm831x_usb_limits[i] 
 + wm831x_usb_limits[best]  wm831x_usb_limits[i])
 + best = i;
 + }
 +
 + dev_dbg(wm831x_power-wm831x-dev,
 + Limiting USB current to %dmA, wm831x_usb_limits[best]);
 +
 + wm831x_set_bits(wm831x_power-wm831x, WM831X_POWER_STATE,
 + WM831X_USB_ILIM_MASK, best);
 +
 + return 0;
 +}
 +
  /*
   *   Battery properties
   */
 @@ -606,8 +646,31 @@ static int wm831x_power_probe(struct platform_device 
 *pdev)
   }
   }
  
 + if (wm831x_pdata  wm831x_pdata-usb_gadget) {
 + power-usb_charger =
 + usb_charger_find_by_name(wm831x_pdata-usb_gadget);
 + if (IS_ERR(power-usb_charger)) {
 + ret = PTR_ERR(power-usb_charger);
 + dev_err(pdev-dev,
 + Failed to find USB gadget: %d\n, ret);
 + goto err_bat_irq;
 + }
 +
 + power-usb_notify.notifier_call = wm831x_usb_limit_change;
 +
 + ret = usb_charger_register_notify(power-usb_charger,
 +   power-usb_notify);
 + if (ret != 0) {
 + dev_err(pdev-dev,
 + Failed to register notifier: %d\n, ret);
 + goto err_usb_charger;
 + }
 + }
 +
   return ret;
  
 +err_usb_charger:
 + usb_charger_put(power-usb_charger);
  err_bat_irq:
   --i;
   for (; i = 0; i--) {
 @@ -637,6 +700,12 @@ static int wm831x_power_remove(struct platform_device 
 *pdev)
   struct wm831x *wm831x = wm831x_power-wm831x;
   int irq, i;
  
 + if (wm831x_power-usb_charger) {
 + usb_charger_unregister_notify(wm831x_power-usb_charger,
 +   wm831x_power-usb_notify);
 + usb_charger_put(wm831x_power-usb_charger);
 + }
 +
   for (i = 0; i  ARRAY_SIZE(wm831x_bat_irqs); i++) {
   irq = wm831x_irq(wm831x, 
platform_get_irq_byname(pdev,
 diff --git a/include/linux/mfd/wm831x/pdata.h 
 b/include/linux/mfd/wm831x/pdata.h
 index dcc9631..5af8399 100644
 --- a/include/linux/mfd/wm831x/pdata.h
 +++ b/include/linux/mfd/wm831x/pdata.h
 @@ -126,6 +126,9 @@ struct wm831x_pdata {
   /** The driver should initiate a power off sequence during shutdown */
   bool soft_shutdown;
  
 + /** dev_name of USB charger gadget to integrate with */
 + const char *usb_gadget;
 +
   int irq_base;
   int gpio_base;
   int gpio_defaults[WM831X_GPIO_NUM];

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead

Re: [PATCH v3 3/3] power: wm831x_power: Support USB charger current limit management

[Lee Jones]

On Tue, 18 Aug 2015, Charles Keepax wrote:

 On Tue, Aug 18, 2015 at 07:14:21PM +0800, Baolin Wang wrote:
  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.
  
  Signed-off-by: Mark Brown broo...@kernel.org
  Signed-off-by: Baolin Wang baolin.w...@linaro.org
  ---
 
 Acked-by: Charles Keepax ckee...@opensource.wolfsonmicro.com
 
 Sorry if you guys got a bunch of bounces, we had a bit of an
 email fiasco at this end. Hopefully all fixed now.

Yes, I sent you guys a mail about that.

Glad it's all sorted now.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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 v2 3/3] power: wm831x_power: Support USB charger current limit management

[Lee Jones]

On Fri, 14 Aug 2015, Baolin Wang wrote:

 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.
 
 Signed-off-by: Mark Brown broo...@kernel.org
 Signed-off-by: Baolin Wang baolin.w...@linaro.org
 ---
  drivers/power/wm831x_power.c |   69 
 ++
  include/linux/mfd/wm831x/pdata.h |3 ++

Acked-by: Lee Jones lee.jo...@linaro.org

  2 files changed, 72 insertions(+)
 
 diff --git a/drivers/power/wm831x_power.c b/drivers/power/wm831x_power.c
 index db11ae6..72c661f 100644
 --- a/drivers/power/wm831x_power.c
 +++ b/drivers/power/wm831x_power.c
 @@ -13,6 +13,7 @@
  #include linux/platform_device.h
  #include linux/power_supply.h
  #include linux/slab.h
 +#include linux/usb/usb_charger.h
  
  #include linux/mfd/wm831x/core.h
  #include linux/mfd/wm831x/auxadc.h
 @@ -31,6 +32,8 @@ struct wm831x_power {
   char usb_name[20];
   char battery_name[20];
   bool have_battery;
 + struct usb_charger *usb_charger;
 + struct notifier_block usb_notify;
  };
  
  static int wm831x_power_check_online(struct wm831x *wm831x, int supply,
 @@ -125,6 +128,43 @@ static enum power_supply_property wm831x_usb_props[] = {
   POWER_SUPPLY_PROP_VOLTAGE_NOW,
  };
  
 +/* In miliamps */
 +static unsigned int wm831x_usb_limits[] = {
 + 0,
 + 2,
 + 100,
 + 500,
 + 900,
 + 1500,
 + 1800,
 + 550,
 +};
 +
 +static int wm831x_usb_limit_change(struct notifier_block *nb,
 +unsigned long limit, void *data)
 +{
 + struct wm831x_power *wm831x_power = container_of(nb,
 +  struct wm831x_power,
 +  usb_notify);
 + int i, best;
 +
 + /* Find the highest supported limit */
 + best = 0;
 + for (i = 0; i  ARRAY_SIZE(wm831x_usb_limits); i++) {
 + if (limit  wm831x_usb_limits[i] 
 + wm831x_usb_limits[best]  wm831x_usb_limits[i])
 + best = i;
 + }
 +
 + dev_dbg(wm831x_power-wm831x-dev,
 + Limiting USB current to %dmA, wm831x_usb_limits[best]);
 +
 + wm831x_set_bits(wm831x_power-wm831x, WM831X_POWER_STATE,
 + WM831X_USB_ILIM_MASK, best);
 +
 + return 0;
 +}
 +
  /*
   *   Battery properties
   */
 @@ -606,8 +646,31 @@ static int wm831x_power_probe(struct platform_device 
 *pdev)
   }
   }
  
 + if (wm831x_pdata  wm831x_pdata-usb_gadget) {
 + power-usb_charger =
 + usb_charger_find_by_name(wm831x_pdata-usb_gadget);
 + if (IS_ERR(power-usb_charger)) {
 + ret = PTR_ERR(power-usb_charger);
 + dev_err(pdev-dev,
 + Failed to find USB gadget: %d\n, ret);
 + goto err_bat_irq;
 + }
 +
 + power-usb_notify.notifier_call = wm831x_usb_limit_change;
 +
 + ret = usb_charger_register_notify(power-usb_charger,
 +   power-usb_notify);
 + if (ret != 0) {
 + dev_err(pdev-dev,
 + Failed to register notifier: %d\n, ret);
 + goto err_usb_charger;
 + }
 + }
 +
   return ret;
  
 +err_usb_charger:
 + usb_charger_put(power-usb_charger);
  err_bat_irq:
   --i;
   for (; i = 0; i--) {
 @@ -637,6 +700,12 @@ static int wm831x_power_remove(struct platform_device 
 *pdev)
   struct wm831x *wm831x = wm831x_power-wm831x;
   int irq, i;
  
 + if (wm831x_power-usb_charger) {
 + usb_charger_unregister_notify(wm831x_power-usb_charger,
 +   wm831x_power-usb_notify);
 + usb_charger_put(wm831x_power-usb_charger);
 + }
 +
   for (i = 0; i  ARRAY_SIZE(wm831x_bat_irqs); i++) {
   irq = wm831x_irq(wm831x, 
platform_get_irq_byname(pdev,
 diff --git a/include/linux/mfd/wm831x/pdata.h 
 b/include/linux/mfd/wm831x/pdata.h
 index dcc9631..5af8399 100644
 --- a/include/linux/mfd/wm831x/pdata.h
 +++ b/include/linux/mfd/wm831x/pdata.h
 @@ -126,6 +126,9 @@ struct wm831x_pdata {
   /** The driver should initiate a power off sequence during shutdown */
   bool soft_shutdown;
  
 + /** dev_name of USB charger gadget to integrate with */
 + const char *usb_gadget;
 +
   int irq_base;
   int gpio_base;
   int gpio_defaults[WM831X_GPIO_NUM];

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org

Re: net2280 and UAS not working

[Paul Jones]

Hi,

On 05 Jul 2015, at 20:43, Felipe Balbi ba...@ti.com wrote:

 Hi,
 
 On Sun, Jul 05, 2015 at 06:56:29PM +0200, Paul Jones wrote:
 Ricardo,
 
 I’m trying to get the 3380 to work in UAS mode on the 4.0.1 and/or 4.1.0-rc8 
 kernels.
 I’m using the following script (derived from Sebastian’s post):
  modprobe tcm_usb_gadget 
  mount -t configfs none /sys/kernel/config
  CONFIGFS=/sys/kernel/config/
  TARGET=$CONFIGFS/target/core/
  FABRIC=$CONFIGFS/target/usb_gadget/
  
  mkdir -p $TARGET/rd_mcp_0/ramdisk
  echo -n rd_pages=32768  $TARGET/rd_mcp_0/ramdisk/control
  echo -n 1  $TARGET/rd_mcp_0/ramdisk/enable
 
  mkdir -p $FABRIC/naa.6001405c3214b06a/tpgt_1
  mkdir $FABRIC/naa.6001405c3214b06a/tpgt_1/lun/lun_0
  echo -n naa.6001405c3214b06b  $FABRIC/naa.6001405c3214b06a/tpgt_1/nexus
 
  ln -sv $TARGET/rd_mcp_0/ramdisk 
 $FABRIC/naa.6001405c3214b06a/tpgt_1/lun/lun_0/virtual_scsi_port
  echo 1  $FABRIC/naa.6001405c3214b06a/tpgt_1/enable
 
 On either of the kernels, once I setup UAS I get an error from 
 tcm_usb_gadget: Can't claim all required eps”.
 This seems to be due to the fact that max_streams = 0 on every EP for the 
 3380.
 
 yeah, that needs to be initialized.
 
 If I patch around that:
 diff --git a/drivers/usb/gadget/epautoconf.c 
 b/drivers/usb/gadget/epautoconf.c
 index 0567cca..94ade78 100644
 --- a/drivers/usb/gadget/epautoconf.c
 +++ b/drivers/usb/gadget/epautoconf.c
 @@ -117,8 +117,10 @@ ep_matches (
if (usb_endpoint_xfer_bulk(desc)) {
if (ep_comp  gadget-max_speed = USB_SPEED_SUPER) {
num_req_streams = ep_comp-bmAttributes  0x1f;
 -   if (num_req_streams  ep-max_streams)
 +   printk(%s: requested streams %d  max streams 
 %d,ep-name, num_req_streams, ep-max_streams);
 +/* if (num_req_streams  ep-max_streams)
return 0;
 +*/
 
 no, you should make sure that max_streams is initialized corrent when
 runing on 3380.

The above temporary patch was just to see if more is needed besides setting 
max_streams and to help Ricardo to reproduce the issue.

 
}
 
}
 
 then I can at least get UAS to load, but as soon as I connect a linux box to 
 the 3380 I then get errors:
 [   50.954080] ep1in: requested streams 4  max streams 0
 [   50.954089] ep2out: requested streams 4  max streams 0
 [   50.954097] ep3in: requested streams 4  max streams 0
 [   50.954105] ep4out: requested streams 0  max streams 0
 [   50.954116] g_target gadget: g_target ready
 [   50.954129] net2280 :05:00.0: Operate Defect 7374 workaround soft 
 this time
 [   50.954130] net2280 :05:00.0: It will operate on cold-reboot and SS 
 connect
 [   51.198283] net2280 :05:00.0: INFO: Defect 7374 workaround waited 
 about
 [   51.198283] 0uSec for Control Read Data Phase ACK
 [   51.199366] g_target gadget: super-speed config #1: Linux Target
 [   51.199394] Using the BOT protocol
 [   51.199903] Wrong signature on CBW
 [   51.199913] bot_cmd_complete(313): -22
 [   51.199955] Using the UAS protocol
 [   72.789041] Unsupported type 0
 [   72.789063] g_target gadget: super-speed config #1: Linux Target
 [   72.789114] Using the BOT protocol
 [   72.789406] Wrong signature on CBW
 [   72.789415] bot_cmd_complete(313): -22
 [   72.789456] Using the UAS protocol
 [   72.921156] Unsupported type 0
 [   72.921174] g_target gadget: super-speed config #1: Linux Target
 [   72.921222] Using the BOT protocol
 [   72.921514] Wrong signature on CBW
 [   72.921523] bot_cmd_complete(313): -22
 [   72.921563] Using the UAS protocol
 
 On the connected Linux box (running 4.1.0-rc8 as well), I get:
 [ 4563.476084] usb 2-3: new SuperSpeed USB device number 5 using xhci_hcd
 [ 4563.492900] usb 2-3: New USB device found, idVendor=0525, idProduct=a4a5
 [ 4563.492903] usb 2-3: New USB device strings: Mfr=1, Product=2, 
 SerialNumber=3
 [ 4563.492904] usb 2-3: Product: Target Product
 [ 4563.492906] usb 2-3: Manufacturer: Target Manufactor
 [ 4563.492907] usb 2-3: SerialNumber: 0001
 [ 4563.494193] scsi host9: uas
 [ 4563.494298] xhci_hcd :00:14.0: ERROR Transfer event for disabled 
 endpoint or incorrect stream ring
 [ 4563.494324] xhci_hcd :00:14.0: @d43e2500 d3921000  
 0a00 04078000
 [ 4563.494346] xhci_hcd :00:14.0: ERROR Transfer event for disabled 
 endpoint or incorrect stream ring
 [ 4563.494371] xhci_hcd :00:14.0: @d43e2510 d3921400  
 0a00 04038000
 [ 4584.936226] scsi 9:0:0:0: tag#0 uas_eh_abort_handler 0 uas-tag 1 
 inflight: CMD IN 
 [ 4584.936230] scsi 9:0:0:0: tag#0 CDB: Inquiry 12 00 00 00 24 00
 [ 4584.936286] scsi host9: uas_eh_bus_reset_handler start
 [ 4585.048559] usb 2-3: reset SuperSpeed USB device number 5 using xhci_hcd
 [ 4585.065687] scsi host9: uas_eh_bus_reset_handler success
 [ 4585.065707] xhci_hcd :00:14.0: ERROR Transfer event

net2280 and UAS not working

[Paul Jones]

Ricardo,

I’m trying to get the 3380 to work in UAS mode on the 4.0.1 and/or 4.1.0-rc8 
kernels.
I’m using the following script (derived from Sebastian’s post):
modprobe tcm_usb_gadget 
mount -t configfs none /sys/kernel/config
CONFIGFS=/sys/kernel/config/
TARGET=$CONFIGFS/target/core/
FABRIC=$CONFIGFS/target/usb_gadget/

mkdir -p $TARGET/rd_mcp_0/ramdisk
echo -n rd_pages=32768  $TARGET/rd_mcp_0/ramdisk/control
echo -n 1  $TARGET/rd_mcp_0/ramdisk/enable

mkdir -p $FABRIC/naa.6001405c3214b06a/tpgt_1
mkdir $FABRIC/naa.6001405c3214b06a/tpgt_1/lun/lun_0
echo -n naa.6001405c3214b06b  $FABRIC/naa.6001405c3214b06a/tpgt_1/nexus

ln -sv $TARGET/rd_mcp_0/ramdisk 
$FABRIC/naa.6001405c3214b06a/tpgt_1/lun/lun_0/virtual_scsi_port
echo 1  $FABRIC/naa.6001405c3214b06a/tpgt_1/enable

On either of the kernels, once I setup UAS I get an error from tcm_usb_gadget: 
Can't claim all required eps”.
This seems to be due to the fact that max_streams = 0 on every EP for the 3380.

If I patch around that:
diff --git a/drivers/usb/gadget/epautoconf.c b/drivers/usb/gadget/epautoconf.c
index 0567cca..94ade78 100644
--- a/drivers/usb/gadget/epautoconf.c
+++ b/drivers/usb/gadget/epautoconf.c
@@ -117,8 +117,10 @@ ep_matches (
if (usb_endpoint_xfer_bulk(desc)) {
if (ep_comp  gadget-max_speed = USB_SPEED_SUPER) {
num_req_streams = ep_comp-bmAttributes  0x1f;
-   if (num_req_streams  ep-max_streams)
+   printk(%s: requested streams %d  max streams 
%d,ep-name, num_req_streams, ep-max_streams);
+/* if (num_req_streams  ep-max_streams)
return 0;
+*/
}
 
}

then I can at least get UAS to load, but as soon as I connect a linux box to 
the 3380 I then get errors:
[   50.954080] ep1in: requested streams 4  max streams 0
[   50.954089] ep2out: requested streams 4  max streams 0
[   50.954097] ep3in: requested streams 4  max streams 0
[   50.954105] ep4out: requested streams 0  max streams 0
[   50.954116] g_target gadget: g_target ready
[   50.954129] net2280 :05:00.0: Operate Defect 7374 workaround soft this 
time
[   50.954130] net2280 :05:00.0: It will operate on cold-reboot and SS 
connect
[   51.198283] net2280 :05:00.0: INFO: Defect 7374 workaround waited about
[   51.198283] 0uSec for Control Read Data Phase ACK
[   51.199366] g_target gadget: super-speed config #1: Linux Target
[   51.199394] Using the BOT protocol
[   51.199903] Wrong signature on CBW
[   51.199913] bot_cmd_complete(313): -22
[   51.199955] Using the UAS protocol
[   72.789041] Unsupported type 0
[   72.789063] g_target gadget: super-speed config #1: Linux Target
[   72.789114] Using the BOT protocol
[   72.789406] Wrong signature on CBW
[   72.789415] bot_cmd_complete(313): -22
[   72.789456] Using the UAS protocol
[   72.921156] Unsupported type 0
[   72.921174] g_target gadget: super-speed config #1: Linux Target
[   72.921222] Using the BOT protocol
[   72.921514] Wrong signature on CBW
[   72.921523] bot_cmd_complete(313): -22
[   72.921563] Using the UAS protocol

On the connected Linux box (running 4.1.0-rc8 as well), I get:
[ 4563.476084] usb 2-3: new SuperSpeed USB device number 5 using xhci_hcd
[ 4563.492900] usb 2-3: New USB device found, idVendor=0525, idProduct=a4a5
[ 4563.492903] usb 2-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 4563.492904] usb 2-3: Product: Target Product
[ 4563.492906] usb 2-3: Manufacturer: Target Manufactor
[ 4563.492907] usb 2-3: SerialNumber: 0001
[ 4563.494193] scsi host9: uas
[ 4563.494298] xhci_hcd :00:14.0: ERROR Transfer event for disabled 
endpoint or incorrect stream ring
[ 4563.494324] xhci_hcd :00:14.0: @d43e2500 d3921000  
0a00 04078000
[ 4563.494346] xhci_hcd :00:14.0: ERROR Transfer event for disabled 
endpoint or incorrect stream ring
[ 4563.494371] xhci_hcd :00:14.0: @d43e2510 d3921400  
0a00 04038000
[ 4584.936226] scsi 9:0:0:0: tag#0 uas_eh_abort_handler 0 uas-tag 1 inflight: 
CMD IN 
[ 4584.936230] scsi 9:0:0:0: tag#0 CDB: Inquiry 12 00 00 00 24 00
[ 4584.936286] scsi host9: uas_eh_bus_reset_handler start
[ 4585.048559] usb 2-3: reset SuperSpeed USB device number 5 using xhci_hcd
[ 4585.065687] scsi host9: uas_eh_bus_reset_handler success
[ 4585.065707] xhci_hcd :00:14.0: ERROR Transfer event for disabled 
endpoint or incorrect stream ring
[ 4585.065736] xhci_hcd :00:14.0: @d43e2650 d3921800  
0a00 04078000
[ 4585.068219] scsi 9:0:0:0: tag#0 uas_eh_abort_handler 0 uas-tag 1 inflight: 
CMD 
[ 4585.068223] scsi 9:0:0:0: tag#0 CDB: Test Unit Ready 00 00 00 00 00 00
[ 4585.068224] scsi host9: uas_eh_bus_reset_handler start
[ 4585.180561] usb 2-3: reset SuperSpeed USB device number 5 using xhci_hcd
[ 4585.197711] scsi host9: 

Re: [PATCH v8 4/9] mfd: Add binding document for NVIDIA Tegra XUSB

[Lee Jones]

On Thu, 21 May 2015, Thierry Reding wrote:

 On Thu, May 21, 2015 at 09:40:01AM +0100, Lee Jones wrote:
  On Wed, 20 May 2015, Thierry Reding wrote:
   On Wed, May 20, 2015 at 07:35:51AM +0100, Lee Jones wrote:
On Tue, 19 May 2015, Andrew Bresticker wrote:
 On Thu, May 14, 2015 at 10:38 AM, Andrew Bresticker
 abres...@chromium.org wrote:
  On Thu, May 14, 2015 at 12:40 AM, Lee Jones lee.jo...@linaro.org 
  wrote:
  On Thu, 14 May 2015, Jon Hunter wrote:
  On 13/05/15 15:39, Lee Jones wrote:
   On Mon, 04 May 2015, Andrew Bresticker wrote:
  
   Add a binding document for the XUSB host complex on NVIDIA 
   Tegra124
   and later SoCs.  The XUSB host complex includes a mailbox for
   communication with the XUSB micro-controller and an xHCI 
   host-controller.
  
   Signed-off-by: Andrew Bresticker abres...@chromium.org
   Cc: Rob Herring robh...@kernel.org
   Cc: Pawel Moll pawel.m...@arm.com
   Cc: Mark Rutland mark.rutl...@arm.com
   Cc: Ian Campbell ijc+devicet...@hellion.org.uk
   Cc: Kumar Gala ga...@codeaurora.org
   Cc: Samuel Ortiz sa...@linux.intel.com
   Cc: Lee Jones lee.jo...@linaro.org
   ---
   Changes from v7:
- Move non-shared resources into child nodes.
   New for v7.
   ---
.../bindings/mfd/nvidia,tegra124-xusb.txt  | 37 
   ++
1 file changed, 37 insertions(+)
create mode 100644 
   Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
  
   diff --git 
   a/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt

   b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
   new file mode 100644
   index 000..bc50110
   --- /dev/null
   +++ 
   b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
   @@ -0,0 +1,37 @@
   +NVIDIA Tegra XUSB host copmlex
   +==
   +
   +The XUSB host complex on Tegra124 and later SoCs contains an 
   xHCI host
   +controller and a mailbox for communication with the XUSB 
   micro-controller.
   +
   +Required properties:
   +
   + - compatible: For Tegra124, must contain 
   nvidia,tegra124-xusb.
   +   Otherwise, must contain 'nvidia,chip-xusb, 
   nvidia,tegra124-xusb'
   +   where chip is tegra132.
   + - reg: Must contain the base and length of the XUSB FPCI 
   registers.
   + - ranges: Bus address mapping for the XUSB block.  Can be 
   empty since the
   +   mapping is 1:1.
   + - #address-cells: Must be 2.
   + - #size-cells: Must be 2.
   +
   +Example:
   +
   +  usb@0,70098000 {
   +  compatible = nvidia,tegra124-xusb;
   +  reg = 0x0 0x70098000 0x0 0x1000;
   +  ranges;
   +
   +  #address-cells = 2;
   +  #size-cells = 2;
   +
   +  usb-host@0,7009 {
   +  compatible = nvidia,tegra124-xhci;
   +  ...
   +  };
   +
   +  mailbox {
   +  compatible = nvidia,tegra124-xusb-mbox;
   +  ...
   +  };
  
   This doesn't appear to be a proper MFD.  I would have the USB 
   and
   Mailbox devices probe seperately and use a phandle to point the 
   USB
   device to its Mailbox.
  
   usb@xyz {
   mboxes = xusb-mailbox, [chan];
   };
  
 
  I am assuming that Andrew had laid it out like this to reflect 
  the hw
  structure. The mailbox and xhci controller are part of the xusb
  sub-system and hence appear as child nodes. My understanding is 
  that for
  device-tree we want the device-tree structure to reflect the 
  actual hw.
  Is this not the case?
 
  Yes, the DT files should reflect h/w.  I have requested to see what
  the memory map looks like, so I might provide a more appropriate
  solution to accepting a pretty pointless MFD.
 
  FWIW, the address map for XUSB looks like this:
 
  XUSB_HOST: 0x7009 - 0x7009a000
  xHCI registers: 0x7009 - 0x70098000
  FPCI configuration registers: 0x70098000 - 0x70099000
  IPFS configuration registers: 0x70099000 - 0x7009a000
 
  Two solutions spring to mind.  You can either call
  of_platform_populate() from the USB driver, as some already do:
 
drivers/usb/dwc3/dwc3-exynos.c:
  ret = of_platform_populate(node, NULL, NULL, dev);
drivers/usb/dwc3/dwc3-keystone.c:
  error = of_platform_populate(node, NULL, NULL, dev);
drivers/usb/dwc3/dwc3-omap.c:
  ret = of_platform_populate(node, NULL, NULL, dev);
drivers/usb/dwc3/dwc3-qcom.c:
  ret = of_platform_populate(node, NULL, NULL

Re: [PATCH v8 4/9] mfd: Add binding document for NVIDIA Tegra XUSB

[Lee Jones]

On Wed, 20 May 2015, Thierry Reding wrote:
 On Wed, May 20, 2015 at 07:35:51AM +0100, Lee Jones wrote:
  On Tue, 19 May 2015, Andrew Bresticker wrote:
   On Thu, May 14, 2015 at 10:38 AM, Andrew Bresticker
   abres...@chromium.org wrote:
On Thu, May 14, 2015 at 12:40 AM, Lee Jones lee.jo...@linaro.org 
wrote:
On Thu, 14 May 2015, Jon Hunter wrote:
On 13/05/15 15:39, Lee Jones wrote:
 On Mon, 04 May 2015, Andrew Bresticker wrote:

 Add a binding document for the XUSB host complex on NVIDIA Tegra124
 and later SoCs.  The XUSB host complex includes a mailbox for
 communication with the XUSB micro-controller and an xHCI 
 host-controller.

 Signed-off-by: Andrew Bresticker abres...@chromium.org
 Cc: Rob Herring robh...@kernel.org
 Cc: Pawel Moll pawel.m...@arm.com
 Cc: Mark Rutland mark.rutl...@arm.com
 Cc: Ian Campbell ijc+devicet...@hellion.org.uk
 Cc: Kumar Gala ga...@codeaurora.org
 Cc: Samuel Ortiz sa...@linux.intel.com
 Cc: Lee Jones lee.jo...@linaro.org
 ---
 Changes from v7:
  - Move non-shared resources into child nodes.
 New for v7.
 ---
  .../bindings/mfd/nvidia,tegra124-xusb.txt  | 37 
 ++
  1 file changed, 37 insertions(+)
  create mode 100644 
 Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt

 diff --git 
 a/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt 
 b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
 new file mode 100644
 index 000..bc50110
 --- /dev/null
 +++ 
 b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
 @@ -0,0 +1,37 @@
 +NVIDIA Tegra XUSB host copmlex
 +==
 +
 +The XUSB host complex on Tegra124 and later SoCs contains an xHCI 
 host
 +controller and a mailbox for communication with the XUSB 
 micro-controller.
 +
 +Required properties:
 +
 + - compatible: For Tegra124, must contain nvidia,tegra124-xusb.
 +   Otherwise, must contain 'nvidia,chip-xusb, 
 nvidia,tegra124-xusb'
 +   where chip is tegra132.
 + - reg: Must contain the base and length of the XUSB FPCI 
 registers.
 + - ranges: Bus address mapping for the XUSB block.  Can be empty 
 since the
 +   mapping is 1:1.
 + - #address-cells: Must be 2.
 + - #size-cells: Must be 2.
 +
 +Example:
 +
 +  usb@0,70098000 {
 +  compatible = nvidia,tegra124-xusb;
 +  reg = 0x0 0x70098000 0x0 0x1000;
 +  ranges;
 +
 +  #address-cells = 2;
 +  #size-cells = 2;
 +
 +  usb-host@0,7009 {
 +  compatible = nvidia,tegra124-xhci;
 +  ...
 +  };
 +
 +  mailbox {
 +  compatible = nvidia,tegra124-xusb-mbox;
 +  ...
 +  };

 This doesn't appear to be a proper MFD.  I would have the USB and
 Mailbox devices probe seperately and use a phandle to point the USB
 device to its Mailbox.

 usb@xyz {
 mboxes = xusb-mailbox, [chan];
 };

   
I am assuming that Andrew had laid it out like this to reflect the hw
structure. The mailbox and xhci controller are part of the xusb
sub-system and hence appear as child nodes. My understanding is that 
for
device-tree we want the device-tree structure to reflect the actual 
hw.
Is this not the case?
   
Yes, the DT files should reflect h/w.  I have requested to see what
the memory map looks like, so I might provide a more appropriate
solution to accepting a pretty pointless MFD.
   
FWIW, the address map for XUSB looks like this:
   
XUSB_HOST: 0x7009 - 0x7009a000
xHCI registers: 0x7009 - 0x70098000
FPCI configuration registers: 0x70098000 - 0x70099000
IPFS configuration registers: 0x70099000 - 0x7009a000
   
Two solutions spring to mind.  You can either call
of_platform_populate() from the USB driver, as some already do:
   
  drivers/usb/dwc3/dwc3-exynos.c:
ret = of_platform_populate(node, NULL, NULL, dev);
  drivers/usb/dwc3/dwc3-keystone.c:
error = of_platform_populate(node, NULL, NULL, dev);
  drivers/usb/dwc3/dwc3-omap.c:
ret = of_platform_populate(node, NULL, NULL, dev);
  drivers/usb/dwc3/dwc3-qcom.c:
ret = of_platform_populate(node, NULL, NULL, qdwc-dev);
  drivers/usb/dwc3/dwc3-st.c:
ret = of_platform_populate(node, NULL, NULL, dev);
  drivers/usb/musb/musb_am335x.c:
ret = of_platform_populate(pdev-dev.of_node, NULL, NULL, 
pdev-dev);
   
This still requires a small, separate driver to setup the regmap and
do of_platform_populate().  The only difference is it lives in
drivers/usb/ instead of drivers

Unhandled IRQ 16 from ehci_hcd makes mouse unusable

[Kynn Jones]

NB: This is an updated version of
https://bugzilla.kernel.org/show_bug.cgi?id=97131.  I'm reposting here by the
request of that bug's assignee.

In this update I've added the output of some more diagnostic commands (at the
end of the post).  The list of diagnostic commands run is now this:

$ cat /proc/version
$ /usr/lib/linux-kbuild-3.2/scripts/ver_linux
$ cat /proc/cpuinfo
$ cat /proc/modules
$ cat /proc/ioports
$ cat /proc/iomem
$ lspci -vvv
$ lspci -nn
$ cat /proc/scsi/scsi
$ lsusb -v
$ dmesg
$ cat /etc/rc.local
$ cat /proc/interrupts
$ dpkg -l | grep $(uname -r)



DESCRIPTION
===

My new computer (Dell Precision T1700) works fine until the system
goes to sleep for the first time after booting.  After waking, the
cursor on the screen lags so much behind the physical motion of the
mouse that the latter is basically unusable.  This mouse malfunction
persists until the system is rebooted.

The only new log messages I see when I bring the system back from its
first post-boot sleep is this (both in /var/log/kern.log and
/var/log/syslog, and part of it also in /var/log/messages):

Apr 22 09:21:00 capitan kernel: [   67.832836] irq 16: nobody
cared (try booting with the irqpoll option)
Apr 22 09:21:00 capitan kernel: [   67.832848] Pid: 0, comm:
swapper/0 Not tainted 3.2.0-4-amd64 #1 Debian 3.2.65-1+deb7u2
Apr 22 09:21:00 capitan kernel: [   67.832853] Call Trace:
Apr 22 09:21:00 capitan kernel: [   67.832856]  IRQ
[81092ddd] ? __report_bad_irq+0x2c/0xb5
Apr 22 09:21:00 capitan kernel: [   67.832878]
[810931e2] ? note_interrupt+0x1b8/0x23a
Apr 22 09:21:00 capitan kernel: [   67.832886]
[81091554] ? handle_irq_event_percpu+0x15f/0x17d
Apr 22 09:21:00 capitan kernel: [   67.832893]
[810915a6] ? handle_irq_event+0x34/0x52
Apr 22 09:21:00 capitan kernel: [   67.832903]
[8106c305] ? arch_local_irq_save+0x11/0x17
Apr 22 09:21:00 capitan kernel: [   67.832911]
[81093959] ? handle_fasteoi_irq+0x7c/0xaf
Apr 22 09:21:00 capitan kernel: [   67.832921]
[8100fa51] ? handle_irq+0x1d/0x21
Apr 22 09:21:00 capitan kernel: [   67.832929]
[8100f62a] ? do_IRQ+0x42/0x98
Apr 22 09:21:00 capitan kernel: [   67.832939]
[813511ae] ? common_interrupt+0x6e/0x6e
Apr 22 09:21:00 capitan kernel: [   67.832943]  EOI
[81024404] ? lapic_next_event+0xe/0x13
Apr 22 09:21:00 capitan kernel: [   67.832977]
[a01dc35b] ? arch_local_irq_enable+0x7/0x8 [processor]
Apr 22 09:21:00 capitan kernel: [   67.832991]
[a01dd0b3] ? acpi_idle_enter_c1+0x8d/0xb3 [processor]
Apr 22 09:21:00 capitan kernel: [   67.833002]
[8127180d] ? cpuidle_idle_call+0xec/0x179
Apr 22 09:21:00 capitan kernel: [   67.833010]
[8100d242] ? cpu_idle+0xa5/0xf2
Apr 22 09:21:00 capitan kernel: [   67.833020]
[816aab3b] ? start_kernel+0x3bd/0x3c8
Apr 22 09:21:00 capitan kernel: [   67.833029]
[816aa140] ? early_idt_handlers+0x140/0x140
Apr 22 09:21:00 capitan kernel: [   67.833037]
[816aa3c4] ? x86_64_start_kernel+0x104/0x111
Apr 22 09:21:00 capitan kernel: [   67.833041] handlers:
Apr 22 09:21:00 capitan kernel: [   67.833059]
[a00a9216] usb_hcd_irq
Apr 22 09:21:00 capitan kernel: [   67.833067]
[a0295cbd] azx_interrupt
Apr 22 09:21:00 capitan kernel: [   67.833072] Disabling IRQ #16


I figure that it is the disabling of IRQ #16 (last line) that is
responsible for the subsequent malfunctioning of the mouse.

The driver associated with this interrupt is

# grep '^ 16:' /proc/interrupts
 16:   1211  0  0  0
IR-IO-APIC-fasteoi   ehci_hcd:usb1

(When I first looked into this problem, the IRQ 16 line was actually
like this:

# grep '^ 16:' /proc/interrupts
 16:   1210  0  0  0
IR-IO-APIC-fasteoi   ehci_hcd:usb1, snd_hda_intel

Since snd_hda_intel was being loaded twice at boot time (e.g. it
showed up also in the line for IRQ 45), I tried to fix the problem
with the mouse by disabling this instance of snd_hda_intel.  For
details, see the content of my /etc/rc.local file further below.  As
it turned out, even though snd_hda_intel no longer appears in the IRQ
16 line, the unhandled IRQ 16 error keeps happening, and the problem
with the mouse persists.)



A few more observations, for what they're worth:

1. I don't see this problem at all if I reboot the machine into
   Windows 7 (mouse works the same before and after sleep).

2. the mouse does not seem to be the source of the problem, because the
   both the unhandled interrupt and the subsequent problems with the
   mouse occur even if I:

 1. disconnect the mouse;
 2. reboot the machine (into 

Re: [PATCH v3 2/2] mfd: dln2: add suspend/resume functionality

[Lee Jones]

On Mon, 19 Jan 2015, Octavian Purdila wrote:

 Without suspend/resume functionality in the USB driver the USB core
 will disconnect and reconnect the DLN2 port and because the GPIO
 framework does not yet support removal of an in-use controller a
 suspend/resume operation will result in a crash.
 
 This patch provides suspend and resume functions for the DLN2 driver
 so that the above scenario is avoided, if the host controller does not
 drop VBUS during suspend, since in this case the device state is
 preserved.
 
 We chose not implemented reset_resume so that if the host controller
 does drop VBUS the resume path will go through above the
 disconnect/reconnect process since it is probably better to fix the
 GPIO framework disconnect issue then to save and restore the device
 state for every driver.
 
 Signed-off-by: Octavian Purdila octavian.purd...@intel.com
 Reviewed-by: Johan Hovold jo...@kernel.org

With Johan's Ack, I'm fairly sure I can just apply this without an in
depth review from me.

After a quick glance; applied, thanks.

 ---
  drivers/mfd/dln2.c | 20 
  1 file changed, 20 insertions(+)
 
 diff --git a/drivers/mfd/dln2.c b/drivers/mfd/dln2.c
 index 8311820..1be9bd1 100644
 --- a/drivers/mfd/dln2.c
 +++ b/drivers/mfd/dln2.c
 @@ -791,6 +791,24 @@ out_free:
   return ret;
  }
  
 +static int dln2_suspend(struct usb_interface *iface, pm_message_t message)
 +{
 + struct dln2_dev *dln2 = usb_get_intfdata(iface);
 +
 + dln2_stop(dln2);
 +
 + return 0;
 +}
 +
 +static int dln2_resume(struct usb_interface *iface)
 +{
 + struct dln2_dev *dln2 = usb_get_intfdata(iface);
 +
 + dln2-disconnect = false;
 +
 + return dln2_start_rx_urbs(dln2, GFP_NOIO);
 +}
 +
  static const struct usb_device_id dln2_table[] = {
   { USB_DEVICE(0xa257, 0x2013) },
   { }
 @@ -803,6 +821,8 @@ static struct usb_driver dln2_driver = {
   .probe = dln2_probe,
   .disconnect = dln2_disconnect,
   .id_table = dln2_table,
 + .suspend = dln2_suspend,
 + .resume = dln2_resume,
  };
  
  module_usb_driver(dln2_driver);

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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 v3 1/2] mfd: dln2: add start/stop RX URBs helpers

[Lee Jones]

On Mon, 19 Jan 2015, Octavian Purdila wrote:

 This is in preparation for adding suspend / resume support.
 
 Signed-off-by: Octavian Purdila octavian.purd...@intel.com
 Reviewed-by: Johan Hovold jo...@kernel.org
 ---
  drivers/mfd/dln2.c | 51 +--
  1 file changed, 41 insertions(+), 10 deletions(-)

With Johan's Ack, I'm fairly sure I can just apply this without an in
depth review from me.

After a quick glance; applied, thanks.

 diff --git a/drivers/mfd/dln2.c b/drivers/mfd/dln2.c
 index 6d49685..8311820 100644
 --- a/drivers/mfd/dln2.c
 +++ b/drivers/mfd/dln2.c
 @@ -587,12 +587,19 @@ static void dln2_free_rx_urbs(struct dln2_dev *dln2)
   int i;
  
   for (i = 0; i  DLN2_MAX_URBS; i++) {
 - usb_kill_urb(dln2-rx_urb[i]);
   usb_free_urb(dln2-rx_urb[i]);
   kfree(dln2-rx_buf[i]);
   }
  }
  
 +static void dln2_stop_rx_urbs(struct dln2_dev *dln2)
 +{
 + int i;
 +
 + for (i = 0; i  DLN2_MAX_URBS; i++)
 + usb_kill_urb(dln2-rx_urb[i]);
 +}
 +
  static void dln2_free(struct dln2_dev *dln2)
  {
   dln2_free_rx_urbs(dln2);
 @@ -604,9 +611,7 @@ static int dln2_setup_rx_urbs(struct dln2_dev *dln2,
 struct usb_host_interface *hostif)
  {
   int i;
 - int ret;
   const int rx_max_size = DLN2_RX_BUF_SIZE;
 - struct device *dev = dln2-interface-dev;
  
   for (i = 0; i  DLN2_MAX_URBS; i++) {
   dln2-rx_buf[i] = kmalloc(rx_max_size, GFP_KERNEL);
 @@ -620,8 +625,19 @@ static int dln2_setup_rx_urbs(struct dln2_dev *dln2,
   usb_fill_bulk_urb(dln2-rx_urb[i], dln2-usb_dev,
 usb_rcvbulkpipe(dln2-usb_dev, dln2-ep_in),
 dln2-rx_buf[i], rx_max_size, dln2_rx, dln2);
 + }
 +
 + return 0;
 +}
  
 - ret = usb_submit_urb(dln2-rx_urb[i], GFP_KERNEL);
 +static int dln2_start_rx_urbs(struct dln2_dev *dln2, gfp_t gfp)
 +{
 + struct device *dev = dln2-interface-dev;
 + int ret;
 + int i;
 +
 + for (i = 0; i  DLN2_MAX_URBS; i++) {
 + ret = usb_submit_urb(dln2-rx_urb[i], gfp);
   if (ret  0) {
   dev_err(dev, failed to submit RX URB: %d\n, ret);
   return ret;
 @@ -665,9 +681,8 @@ static const struct mfd_cell dln2_devs[] = {
   },
  };
  
 -static void dln2_disconnect(struct usb_interface *interface)
 +static void dln2_stop(struct dln2_dev *dln2)
  {
 - struct dln2_dev *dln2 = usb_get_intfdata(interface);
   int i, j;
  
   /* don't allow starting new transfers */
 @@ -696,6 +711,15 @@ static void dln2_disconnect(struct usb_interface 
 *interface)
   /* wait for transfers to end */
   wait_event(dln2-disconnect_wq, !dln2-active_transfers);
  
 + dln2_stop_rx_urbs(dln2);
 +}
 +
 +static void dln2_disconnect(struct usb_interface *interface)
 +{
 + struct dln2_dev *dln2 = usb_get_intfdata(interface);
 +
 + dln2_stop(dln2);
 +
   mfd_remove_devices(interface-dev);
  
   dln2_free(dln2);
 @@ -738,23 +762,30 @@ static int dln2_probe(struct usb_interface *interface,
  
   ret = dln2_setup_rx_urbs(dln2, hostif);
   if (ret)
 - goto out_cleanup;
 + goto out_free;
 +
 + ret = dln2_start_rx_urbs(dln2, GFP_KERNEL);
 + if (ret)
 + goto out_stop_rx;
  
   ret = dln2_hw_init(dln2);
   if (ret  0) {
   dev_err(dev, failed to initialize hardware\n);
 - goto out_cleanup;
 + goto out_stop_rx;
   }
  
   ret = mfd_add_hotplug_devices(dev, dln2_devs, ARRAY_SIZE(dln2_devs));
   if (ret != 0) {
   dev_err(dev, failed to add mfd devices to core\n);
 - goto out_cleanup;
 + goto out_stop_rx;
   }
  
   return 0;
  
 -out_cleanup:
 +out_stop_rx:
 + dln2_stop_rx_urbs(dln2);
 +
 +out_free:
   dln2_free(dln2);
  
   return ret;

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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

Maximum bitrate for CDC ECM

[Paul Jones]

I am trying to use g_ether with a USB 3 gadget (PLX 3380).
During testing I noticed that the transfer speed is much lower than expected at 
42MB/s vs a 95Mb/s for a gigabit connection between the same machines.
The same gadget is capable of transferring 170MB/s via USB 3 when reading from 
a g_mass_storage provided virtual drive.

Perusing the code of f_ecm.c I noticed that the maximum theoretical bitrate for 
USB 3 gadgets is calculated as 13 * 1024 * 8 * 1000 * 8 = 851,968,000 (roughly 
850Mbit/s) and for USB 2 gadgets as 13 * 512 * 8 * 1000 * 8 = 425,984,000 
(roughly 425 Mbit/s). 
I was wondering what that calculation is based on? The 1024/512 seem to be the 
IN/OUT buffer size being used. 
Technically USB3 allows for a native bitrate (after 8/10b coding) of 4Gbit/s. 

Regards,
Paul.

On 18 Jan 2015, at 16:49, Paul Jones p.jo...@teclyn.com wrote:

 Ricardo,
 
 I think I figured out the problem: my 3380 was running in legacy adapter mode.
 I am now capable of connecting both g_mass_storage and g_ether without any 
 kernel panics after ensuring the 3380 is in enhanced adapter mode.
 
 My only concern is the speed from my Mac to Linux:
 - g_ether: scp transfer 42Mb/s 
 - g_mass_storage: dd bs=64k 116Mb/s (backed by SSD storage)
 For comparison, a direct gigabit connection allows between 90 and 95Mb/s 
 using scp between the machines.
 Local writes on the linux side using dd is around 480Mb/s (on the same SSD 
 storage).
 
 Any ideas on how to achieve a higher performance?
 
 Regards,
 Paul.

--
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 3/4] mfd: dln2: add support for ACPI

[Lee Jones]

 the ACPI table via a firmware file */
 + ret = request_firmware(ai-fw, dln2.aml, NULL);
 + if (ret)
 + goto out_unlock;
 +
 + ret = acpi_load_table((void *)ai-fw-data);
 + if (ret) {
 + dev_err(dev, invalid ACPI table\n);
 + goto out_release_fw;
 + }
 +
 + acpi_get_devices(DLN2, dln2_find_acpi_handle, NULL, h);
 + if (!h) {
 + dev_err(dev, not a DLN2 ACPI table\n);
 + goto out_leak_fw;
 + }
 +
 + ret = acpi_get_id(h, ai-table_id);
 + if (ret) {
 + dev_err(dev, acpi_get_id failed: %d\n, ret);
 + goto out_leak_fw;
 + }
 +
 + ret = acpi_bus_scan(h);
 + if (ret) {
 + dev_err(dev, acpi_bus_scan failed: %d\n, ret);
 + goto out_leak_fw;
 + }
 +
 + fw_loaded = true;
 + }
 +
 + ret = acpi_bus_get_device(h, ai-dev);
 + if (ret) {
 + dev_err(dev, failed to get ACPI device: %d\n, ret);
 + if (fw_loaded) {
 + acpi_unload_table_id(ai-table_id);
 + goto out_leak_fw;
 + }
 + goto out_unlock;
 + }
 +
 +out_success:
 + ACPI_COMPANION_SET(dev, ai-dev);
 + ai-users++;
 + mutex_unlock(dln2_acpi_lock);
 + return;
 +
 +out_release_fw:
 + release_firmware(ai-fw);
 +out_leak_fw:
 + /*
 +  * Once a table is loaded we can't release the firmware anymore because
 +  * acpi_unload_table does not actually unload the table but keeps it in
 +  * memory to speed up subsequent loads.
 +  */
 + ai-fw = NULL;
 +out_unlock:
 + mutex_unlock(dln2_acpi_lock);
 +}
 +
 +static void dln2_disconnect_acpi(struct dln2_dev *dln2)
 +{
 + struct dln2_acpi_info *ai = dln2_acpi_info;
 +
 + mutex_lock(dln2_acpi_lock);
 + if (--ai-users == 0  ai-fw) {
 + acpi_scan_lock_acquire();
 + acpi_bus_trim(ai-dev);
 + acpi_scan_lock_release();
 + acpi_unload_table_id(ai-table_id);
 + ai-dev = NULL;
 + /* we can't release firmware see comment in dln2_probe_acpi */
 + ai-fw = NULL;
 + }
 + mutex_unlock(dln2_acpi_lock);
 +}
 +#else
 +static void dln2_probe_acpi(struct dln2_dev *dln2)
 +{
 +}
 +
 +static void dln2_disconnect_acpi(struct dln2_dev *dln2)
 +{
 +}
 +#endif
 +
  static void dln2_disconnect(struct usb_interface *interface)
  {
   struct dln2_dev *dln2 = usb_get_intfdata(interface);
 @@ -722,6 +852,8 @@ static void dln2_disconnect(struct usb_interface 
 *interface)
  
   mfd_remove_devices(interface-dev);
  
 + dln2_disconnect_acpi(dln2);
 +
   dln2_free(dln2);
  }
  
 @@ -774,6 +906,8 @@ static int dln2_probe(struct usb_interface *interface,
   goto out_stop_rx;
   }
  
 + dln2_probe_acpi(dln2);
 +
   ret = mfd_add_hotplug_devices(dev, dln2_devs, ARRAY_SIZE(dln2_devs));
   if (ret != 0) {
   dev_err(dev, failed to add mfd devices to core\n);
 -- 
 1.9.1
 

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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 01/12] mfd: syscon: Add atmel-matrix registers definition

[Lee Jones]

On Sun, 18 Jan 2015, Boris Brezillon wrote:

 Hi Lee,
 
 On Sun, 18 Jan 2015 12:52:59 +
 Lee Jones lee.jo...@linaro.org wrote:
 
  On Wed, 14 Jan 2015, Alexandre Belloni wrote:
  
   From: Boris Brezillon boris.brezil...@free-electrons.com
   
   AT91 SoCs have a memory range reserved for internal bus configuration.
   Expose those registers so that drivers can make use of the matrix syscon
   declared in at91 DTs.
   
   Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
   Acked-by: Lee Jones lee.jo...@linaro.org
   ---
include/linux/mfd/syscon/atmel-matrix.h | 117 
   
1 file changed, 117 insertions(+)
create mode 100644 include/linux/mfd/syscon/atmel-matrix.h
  
  Applied, thanks.
 
 Actually Nicolas took all the patches in his tree and already sent a PR
 to the arm-soc maintainers [1].
 
 [1]https://lkml.org/lkml/2015/1/15/542

Very well.  All unapplied.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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: hard lockup with USB3380

[Paul Jones]

Ricardo,

I think I figured out the problem: my 3380 was running in legacy adapter mode.
I am now capable of connecting both g_mass_storage and g_ether without any 
kernel panics after ensuring the 3380 is in enhanced adapter mode.

My only concern is the speed from my Mac to Linux:
- g_ether: scp transfer 42Mb/s 
- g_mass_storage: dd bs=64k 116Mb/s (backed by SSD storage)
For comparison, a direct gigabit connection allows between 90 and 95Mb/s using 
scp between the machines.
Local writes on the linux side using dd is around 480Mb/s (on the same SSD 
storage).

Any ideas on how to achieve a higher performance?

Regards,
Paul.

On 25 Nov 2014, at 16:30, Paul Jones p.jo...@teclyn.com wrote:

 Ricardo,
 
 Unfortunately your latest change gives similar results, cycling errors in the 
 log:
 [  201.287706] [ cut here ]
 [  201.288328] WARNING: CPU: 3 PID: 1500 at 
 drivers/usb/gadget/udc/net2280.c:816 start_dma+0x153/0x160 [net2280]()
 [  201.288991] Modules linked in: g_mass_storage usb_f_mass_storage 
 libcomposite configfs net2280 udc_core snd_hda_codec_hdmi joydev hid_generic 
 usbhid hid i915 intel_rapl x86_pkg_temp_thermal intel_powerclamp 
 snd_hda_codec_realtek coretemp kvm_intel snd_hda_codec_generic kvm 
 snd_hda_intel eeepc_wmi asus_wmi snd_hda_controller rfcomm snd_seq_midi bnep 
 snd_seq_midi_event bluetooth sparse_keymap snd_hda_codec crct10dif_pclmul 
 snd_rawmidi snd_hwdep crc32_pclmul snd_pcm ghash_clmulni_intel aesni_intel 
 aes_x86_64 drm_kms_helper lrw gf128mul glue_helper ablk_helper cryptd snd_seq 
 mei_me mei serio_raw drm lpc_ich video mac_hid tpm_infineon wmi 
 snd_seq_device snd_timer snd parport_pc i2c_algo_bit soundcore ppdev lp 
 parport e1000e psmouse r8169 ahci libahci mii ptp pps_core
 [  201.292574] CPU: 3 PID: 1500 Comm: file-storage Tainted: GW  
 3.17.0-rc5+ #2
 [  201.293277] Hardware name: ASUS All Series/Q87T, BIOS 0215 09/06/2013
 [  201.293976]  0009 8803f1d8fd28 81746707 
 
 [  201.294689]  8803f1d8fd60 8106c93d 8803efc26478 
 8800ce317100
 [  201.295398]  c90005b9c1a0 8800ce317168 8803efc26320 
 8803f1d8fd70
 [  201.296109] Call Trace:
 [  201.296815]  [81746707] dump_stack+0x45/0x56
 [  201.297524]  [8106c93d] warn_slowpath_common+0x7d/0xa0
 [  201.298218]  [8106ca1a] warn_slowpath_null+0x1a/0x20
 [  201.298891]  [a0428103] start_dma+0x153/0x160 [net2280]
 [  201.299554]  [a0429b1b] net2280_queue+0x2db/0x480 [net2280]
 [  201.300209]  [a04724f1] start_transfer.isra.32+0x71/0xe0 
 [usb_f_mass_storage]
 [  201.300851]  [a047259e] start_out_transfer+0x3e/0x80 
 [usb_f_mass_storage]
 [  201.301474]  [a0473967] fsg_main_thread+0x207/0x17f0 
 [usb_f_mass_storage]
 [  201.302069]  [81749eda] ? __schedule+0x37a/0x830
 [  201.302607]  [a0473760] ? handle_exception+0x460/0x460 
 [usb_f_mass_storage]
 [  201.303200]  [8108a3e2] kthread+0xd2/0xf0
 [  201.303776]  [8108a310] ? kthread_create_on_node+0x180/0x180
 [  201.304328]  [8174ecbc] ret_from_fork+0x7c/0xb0
 [  201.304973]  [8108a310] ? kthread_create_on_node+0x180/0x180
 [  201.305486] ---[ end trace a7f3e86a1a37203b ]—
 Followed by:
 [  263.311338] net2280 :01:00.0: The dmastat return = 5002!!
 [  263.409818] g_mass_storage gadget: super-speed config #1: Linux 
 File-Backed Storage
 
 as long as you have ideas, I’ll be more than happy to try them :)
 
 Paul.
 
 On 25 Nov 2014, at 15:59, Ricardo Ribalda Delgado ricardo.riba...@gmail.com 
 wrote:
 
 One last try :)
 
 Instead of:
 
 if (likely(t  BIT(FIFO_EMPTY))) {
 
 have this:
 
 if ( t  BIT(NAK_OUT_PACKETS)){
  count = readl(ep-dma-dmacount);
  count = DMA_BYTE_COUNT_MASK;
  break;
 }
 
 if (likely(t  BIT(FIFO_EMPTY))) {
 
 
 
 On Tue, Nov 25, 2014 at 3:54 PM, Paul Jones p.jo...@teclyn.com wrote:
 Ricardo,
 
 it no longer locks up but if I try to write to the drive, I get cycles of:
 [ 2334.127653] [ cut here ]
 [ 2334.128318] WARNING: CPU: 0 PID: 2140 at 
 drivers/usb/gadget/udc/net2280.c:816 start_dma+0x153/0x160 [net2280]()
 [ 2334.129105] Modules linked in: g_mass_storage usb_f_mass_storage 
 libcomposite configfs net2280 udc_core snd_hda_codec_hdmi i915 rfcomm bnep 
 bluetooth snd_hda_codec_realtek snd_hda_codec_generic intel_rapl 
 x86_pkg_temp_thermal snd_hda_intel intel_powerclamp coretemp 
 snd_hda_controller kvm_intel snd_hda_codec kvm drm_kms_helper snd_hwdep 
 snd_pcm drm snd_seq_midi joydev snd_seq_midi_event snd_rawmidi hid_generic 
 snd_seq eeepc_wmi asus_wmi sparse_keymap crct10dif_pclmul usbhid 
 crc32_pclmul ghash_clmulni_intel aesni_intel snd_seq_device snd_timer 
 aes_x86_64 hid lrw gf128mul glue_helper snd ablk_helper mei_me mei cryptd 
 serio_raw lpc_ich i2c_algo_bit wmi soundcore video tpm_infineon mac_hid 
 parport_pc ppdev lp parport e1000e psmouse r8169 ahci ptp libahci mii 
 pps_core

Re: [PATCH 01/12] mfd: syscon: Add atmel-matrix registers definition

[Lee Jones]

On Wed, 14 Jan 2015, Alexandre Belloni wrote:

 From: Boris Brezillon boris.brezil...@free-electrons.com
 
 AT91 SoCs have a memory range reserved for internal bus configuration.
 Expose those registers so that drivers can make use of the matrix syscon
 declared in at91 DTs.
 
 Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
 Acked-by: Lee Jones lee.jo...@linaro.org
 ---
  include/linux/mfd/syscon/atmel-matrix.h | 117 
 
  1 file changed, 117 insertions(+)
  create mode 100644 include/linux/mfd/syscon/atmel-matrix.h

Applied, thanks.

 diff --git a/include/linux/mfd/syscon/atmel-matrix.h 
 b/include/linux/mfd/syscon/atmel-matrix.h
 new file mode 100644
 index ..8293c3e2a82a
 --- /dev/null
 +++ b/include/linux/mfd/syscon/atmel-matrix.h
 @@ -0,0 +1,117 @@
 +/*
 + *  Copyright (C) 2014 Atmel Corporation.
 + *
 + * Memory Controllers (MATRIX, EBI) - System peripherals registers.
 + *
 + * This program is free software; you can redistribute it and/or modify
 + * it under the terms of the GNU General Public License as published by
 + * the Free Software Foundation; either version 2 of the License, or
 + * (at your option) any later version.
 + */
 +
 +#ifndef _LINUX_MFD_SYSCON_ATMEL_MATRIX_H
 +#define _LINUX_MFD_SYSCON_ATMEL_MATRIX_H
 +
 +#define AT91SAM9260_MATRIX_MCFG  0x00
 +#define AT91SAM9260_MATRIX_SCFG  0x40
 +#define AT91SAM9260_MATRIX_PRS   0x80
 +#define AT91SAM9260_MATRIX_MRCR  0x100
 +#define AT91SAM9260_MATRIX_EBICSA0x11c
 +
 +#define AT91SAM9261_MATRIX_MRCR  0x0
 +#define AT91SAM9261_MATRIX_SCFG  0x4
 +#define AT91SAM9261_MATRIX_TCR   0x24
 +#define AT91SAM9261_MATRIX_EBICSA0x30
 +#define AT91SAM9261_MATRIX_USBPUCR   0x34
 +
 +#define AT91SAM9263_MATRIX_MCFG  0x00
 +#define AT91SAM9263_MATRIX_SCFG  0x40
 +#define AT91SAM9263_MATRIX_PRS   0x80
 +#define AT91SAM9263_MATRIX_MRCR  0x100
 +#define AT91SAM9263_MATRIX_TCR   0x114
 +#define AT91SAM9263_MATRIX_EBI0CSA   0x120
 +#define AT91SAM9263_MATRIX_EBI1CSA   0x124
 +
 +#define AT91SAM9RL_MATRIX_MCFG   0x00
 +#define AT91SAM9RL_MATRIX_SCFG   0x40
 +#define AT91SAM9RL_MATRIX_PRS0x80
 +#define AT91SAM9RL_MATRIX_MRCR   0x100
 +#define AT91SAM9RL_MATRIX_TCR0x114
 +#define AT91SAM9RL_MATRIX_EBICSA 0x120
 +
 +#define AT91SAM9G45_MATRIX_MCFG  0x00
 +#define AT91SAM9G45_MATRIX_SCFG  0x40
 +#define AT91SAM9G45_MATRIX_PRS   0x80
 +#define AT91SAM9G45_MATRIX_MRCR  0x100
 +#define AT91SAM9G45_MATRIX_TCR   0x110
 +#define AT91SAM9G45_MATRIX_DDRMPR0x118
 +#define AT91SAM9G45_MATRIX_EBICSA0x128
 +
 +#define AT91SAM9N12_MATRIX_MCFG  0x00
 +#define AT91SAM9N12_MATRIX_SCFG  0x40
 +#define AT91SAM9N12_MATRIX_PRS   0x80
 +#define AT91SAM9N12_MATRIX_MRCR  0x100
 +#define AT91SAM9N12_MATRIX_EBICSA0x118
 +
 +#define AT91SAM9X5_MATRIX_MCFG   0x00
 +#define AT91SAM9X5_MATRIX_SCFG   0x40
 +#define AT91SAM9X5_MATRIX_PRS0x80
 +#define AT91SAM9X5_MATRIX_MRCR   0x100
 +#define AT91SAM9X5_MATRIX_EBICSA 0x120
 +
 +#define SAMA5D3_MATRIX_MCFG  0x00
 +#define SAMA5D3_MATRIX_SCFG  0x40
 +#define SAMA5D3_MATRIX_PRS   0x80
 +#define SAMA5D3_MATRIX_MRCR  0x100
 +
 +#define AT91_MATRIX_MCFG(o, x)   ((o) + ((x) * 0x4))
 +#define AT91_MATRIX_ULBT GENMASK(2, 0)
 +#define AT91_MATRIX_ULBT_INFINITE(0  0)
 +#define AT91_MATRIX_ULBT_SINGLE  (1  0)
 +#define AT91_MATRIX_ULBT_FOUR(2  0)
 +#define AT91_MATRIX_ULBT_EIGHT   (3  0)
 +#define AT91_MATRIX_ULBT_SIXTEEN (4  0)
 +
 +#define AT91_MATRIX_SCFG(o, x)   ((o) + ((x) * 0x4))
 +#define AT91_MATRIX_SLOT_CYCLE   GENMASK(7,  0)
 +#define AT91_MATRIX_DEFMSTR_TYPE GENMASK(17, 16)
 +#define AT91_MATRIX_DEFMSTR_TYPE_NONE(0  16)
 +#define AT91_MATRIX_DEFMSTR_TYPE_LAST(1  16)
 +#define AT91_MATRIX_DEFMSTR_TYPE_FIXED   (2  16)
 +#define AT91_MATRIX_FIXED_DEFMSTRGENMASK(20, 18)
 +#define AT91_MATRIX_ARBT GENMASK(25, 24)
 +#define AT91_MATRIX_ARBT_ROUND_ROBIN (0  24)
 +#define AT91_MATRIX_ARBT_FIXED_PRIORITY  (1  24)
 +
 +#define AT91_MATRIX_ITCM_SIZE

Re: [PATCH 04/12] mfd: syscon: Add Atmel SMC binding doc

[Lee Jones]

On Wed, 14 Jan 2015, Alexandre Belloni wrote:

 From: Boris Brezillon boris.brezil...@free-electrons.com
 
 The SMC registers are used to configure Atmel EBI (External Bus Interface)
 to interface with standard memory devices (NAND, NOR, SRAM or specialized
 devices like FPGAs).
 
 Declare this memory region as a syscon, so that different drivers can
 configure the SMC interface (mostly timing configuration) according to
 their need.
 
 Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
 Acked-by: Lee Jones lee.jo...@linaro.org
 ---
  Documentation/devicetree/bindings/mfd/atmel-smc.txt | 19 +++
  1 file changed, 19 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/mfd/atmel-smc.txt

Applied, thanks.
 
 diff --git a/Documentation/devicetree/bindings/mfd/atmel-smc.txt 
 b/Documentation/devicetree/bindings/mfd/atmel-smc.txt
 new file mode 100644
 index ..26eeed373934
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/mfd/atmel-smc.txt
 @@ -0,0 +1,19 @@
 +* Device tree bindings for Atmel SMC (Static Memory Controller)
 +
 +The SMC registers are used to configure Atmel EBI (External Bus Interface)
 +to interface with standard memory devices (NAND, NOR, SRAM or specialized
 +devices like FPGAs).
 +
 +Required properties:
 +- compatible:Should be one of the following
 + atmel,at91sam9260-smc, syscon
 + atmel,sama5d3-smc, syscon
 +- reg:   Contains offset/length value of the SMC memory
 + region.
 +
 +Example:
 +
 +smc: smc@c000 {
 + compatible = atmel,sama5d3-smc, syscon;
 + reg = 0xc000 0x1000;
 +};

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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 03/12] mfd: syscon: Add atmel-smc registers definition

[Lee Jones]

On Wed, 14 Jan 2015, Alexandre Belloni wrote:

 From: Boris Brezillon boris.brezil...@free-electrons.com
 
 Atmel AT91 SoCs have a memory range reserved for SMC (Static Memory
 Controller) configuration.
 Expose those registers so that drivers can make use of the smc syscon
 declared in at91 DTs.
 
 Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
 Acked-by: Lee Jones lee.jo...@linaro.org
 ---
  include/linux/mfd/syscon/atmel-smc.h | 173 
 +++
  1 file changed, 173 insertions(+)
  create mode 100644 include/linux/mfd/syscon/atmel-smc.h

Applied, thanks.
 
 diff --git a/include/linux/mfd/syscon/atmel-smc.h 
 b/include/linux/mfd/syscon/atmel-smc.h
 new file mode 100644
 index ..be6ebe64eebe
 --- /dev/null
 +++ b/include/linux/mfd/syscon/atmel-smc.h
 @@ -0,0 +1,173 @@
 +/*
 + * Atmel SMC (Static Memory Controller) register offsets and bit definitions.
 + *
 + * Copyright (C) 2014 Atmel
 + * Copyright (C) 2014 Free Electrons
 + *
 + * Author: Boris Brezillon boris.brezil...@free-electrons.com
 + *
 + * 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.
 + */
 +
 +#ifndef _LINUX_MFD_SYSCON_ATMEL_SMC_H_
 +#define _LINUX_MFD_SYSCON_ATMEL_SMC_H_
 +
 +#include linux/kernel.h
 +#include linux/regmap.h
 +
 +#define AT91SAM9_SMC_GENERIC 0x00
 +#define AT91SAM9_SMC_GENERIC_BLK_SZ  0x10
 +
 +#define SAMA5_SMC_GENERIC0x600
 +#define SAMA5_SMC_GENERIC_BLK_SZ 0x14
 +
 +#define AT91SAM9_SMC_SETUP(o)((o) + 0x00)
 +#define AT91SAM9_SMC_NWESETUP(x) (x)
 +#define AT91SAM9_SMC_NCS_WRSETUP(x)  ((x)  8)
 +#define AT91SAM9_SMC_NRDSETUP(x) ((x)  16)
 +#define AT91SAM9_SMC_NCS_NRDSETUP(x) ((x)  24)
 +
 +#define AT91SAM9_SMC_PULSE(o)((o) + 0x04)
 +#define AT91SAM9_SMC_NWEPULSE(x) (x)
 +#define AT91SAM9_SMC_NCS_WRPULSE(x)  ((x)  8)
 +#define AT91SAM9_SMC_NRDPULSE(x) ((x)  16)
 +#define AT91SAM9_SMC_NCS_NRDPULSE(x) ((x)  24)
 +
 +#define AT91SAM9_SMC_CYCLE(o)((o) + 0x08)
 +#define AT91SAM9_SMC_NWECYCLE(x) (x)
 +#define AT91SAM9_SMC_NRDCYCLE(x) ((x)  16)
 +
 +#define AT91SAM9_SMC_MODE(o) ((o) + 0x0c)
 +#define SAMA5_SMC_MODE(o)((o) + 0x10)
 +#define AT91_SMC_READMODEBIT(0)
 +#define AT91_SMC_READMODE_NCS(0  0)
 +#define AT91_SMC_READMODE_NRD(1  0)
 +#define AT91_SMC_WRITEMODE   BIT(1)
 +#define AT91_SMC_WRITEMODE_NCS   (0  1)
 +#define AT91_SMC_WRITEMODE_NWE   (1  1)
 +#define AT91_SMC_EXNWMODEGENMASK(5, 4)
 +#define AT91_SMC_EXNWMODE_DISABLE(0  4)
 +#define AT91_SMC_EXNWMODE_FROZEN (2  4)
 +#define AT91_SMC_EXNWMODE_READY  (3  4)
 +#define AT91_SMC_BAT BIT(8)
 +#define AT91_SMC_BAT_SELECT  (0  8)
 +#define AT91_SMC_BAT_WRITE   (1  8)
 +#define AT91_SMC_DBW GENMASK(13, 12)
 +#define AT91_SMC_DBW_8   (0  12)
 +#define AT91_SMC_DBW_16  (1  12)
 +#define AT91_SMC_DBW_32  (2  12)
 +#define AT91_SMC_TDF GENMASK(19, 16)
 +#define AT91_SMC_TDF_(x) x) - 1)  16)  AT91_SMC_TDF)
 +#define AT91_SMC_TDF_MAX 16
 +#define AT91_SMC_TDFMODE_OPTIMIZED   BIT(20)
 +#define AT91_SMC_PMENBIT(24)
 +#define AT91_SMC_PS  GENMASK(29, 28)
 +#define AT91_SMC_PS_4(0  28)
 +#define AT91_SMC_PS_8(1  28)
 +#define AT91_SMC_PS_16   (2  28)
 +#define AT91_SMC_PS_32   (3  28)
 +
 +
 +/*
 + * This function converts a setup timing expressed in nanoseconds into an
 + * encoded value that can be written in the SMC_SETUP register.
 + *
 + * The following formula is described in atmel datasheets (section
 + * SMC Setup Register):
 + *
 + * setup length = (128* SETUP[5] + SETUP[4:0])
 + *
 + * where setup length is the timing expressed in cycles.
 + */
 +static inline u32 at91sam9_smc_setup_ns_to_cycles(unsigned int clk_rate,
 +   u32 timing_ns)
 +{
 + u32 clk_period = DIV_ROUND_UP(NSEC_PER_SEC, clk_rate);
 + u32 coded_cycles = 0;
 + u32 cycles;
 +
 + cycles = DIV_ROUND_UP(timing_ns, clk_period);
 + if (cycles / 32) {
 + coded_cycles |= 1  5;
 + if (cycles  128)
 + cycles = 0;
 + }
 +
 + coded_cycles |= cycles % 32;
 +
 + return coded_cycles;
 +}
 +
 +/*
 + * This function converts a pulse timing expressed in nanoseconds into an
 + * encoded value that can be written in the SMC_PULSE register.
 + *
 + * The following formula is described in atmel datasheets (section
 + * SMC Pulse Register):
 + *
 + * pulse length = (256* PULSE[6] + PULSE[5:0])
 + *
 + * where pulse

Re: [PATCH 02/12] mfd: syscon: Add Atmel Matrix bus DT binding documentation

[Lee Jones]

On Wed, 14 Jan 2015, Alexandre Belloni wrote:

 From: Boris Brezillon boris.brezil...@free-electrons.com
 
 The Matrix registers are provided to configure internal bus behavior on
 at91 SoCs.
 Some registers might be accessed by several drivers (e.g. to configure
 external memory bus timings), hence we declare this register set as a
 syscon device.
 
 Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
 Acked-by: Lee Jones lee.jo...@linaro.org
 ---
  .../devicetree/bindings/mfd/atmel-matrix.txt   | 24 
 ++
  1 file changed, 24 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/mfd/atmel-matrix.txt

Applied, thanks.
 
 diff --git a/Documentation/devicetree/bindings/mfd/atmel-matrix.txt 
 b/Documentation/devicetree/bindings/mfd/atmel-matrix.txt
 new file mode 100644
 index ..e3ef50ca02a5
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/mfd/atmel-matrix.txt
 @@ -0,0 +1,24 @@
 +* Device tree bindings for Atmel Bus Matrix
 +
 +The Bus Matrix registers are used to configure Atmel SoCs internal bus
 +behavior (master/slave priorities, undefined burst length type, ...)
 +
 +Required properties:
 +- compatible:Should be one of the following
 + atmel,at91sam9260-matrix, syscon
 + atmel,at91sam9261-matrix, syscon
 + atmel,at91sam9263-matrix, syscon
 + atmel,at91sam9rl-matrix, syscon
 + atmel,at91sam9g45-matrix, syscon
 + atmel,at91sam9n12-matrix, syscon
 + atmel,at91sam9x5-matrix, syscon
 + atmel,sama5d3-matrix, syscon
 +- reg:   Contains offset/length value of the Bus Matrix
 + memory region.
 +
 +Example:
 +
 +matrix: matrix@ec00 {
 + compatible = atmel,sama5d3-matrix, syscon;
 + reg = 0xec00 0x200;
 +};

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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 v2 3/4] mfd: dln2: add start/stop RX URBs helpers

[Lee Jones]

On Tue, 16 Dec 2014, Octavian Purdila wrote:

 This is in preparation for adding suspend / resume support.

Please re-submit this set with the Acks you have received.

Also draft a cover-letter with the current status of set, what you
need next etc.

 Signed-off-by: Octavian Purdila octavian.purd...@intel.com
 ---
  drivers/mfd/dln2.c | 51 +--
  1 file changed, 41 insertions(+), 10 deletions(-)
 
 diff --git a/drivers/mfd/dln2.c b/drivers/mfd/dln2.c
 index 6d49685..75358d2 100644
 --- a/drivers/mfd/dln2.c
 +++ b/drivers/mfd/dln2.c
 @@ -587,12 +587,19 @@ static void dln2_free_rx_urbs(struct dln2_dev *dln2)
   int i;
  
   for (i = 0; i  DLN2_MAX_URBS; i++) {
 - usb_kill_urb(dln2-rx_urb[i]);
   usb_free_urb(dln2-rx_urb[i]);
   kfree(dln2-rx_buf[i]);
   }
  }
  
 +static void dln2_stop_rx_urbs(struct dln2_dev *dln2)
 +{
 + int i;
 +
 + for (i = 0; i  DLN2_MAX_URBS; i++)
 + usb_kill_urb(dln2-rx_urb[i]);
 +}
 +
  static void dln2_free(struct dln2_dev *dln2)
  {
   dln2_free_rx_urbs(dln2);
 @@ -604,9 +611,7 @@ static int dln2_setup_rx_urbs(struct dln2_dev *dln2,
 struct usb_host_interface *hostif)
  {
   int i;
 - int ret;
   const int rx_max_size = DLN2_RX_BUF_SIZE;
 - struct device *dev = dln2-interface-dev;
  
   for (i = 0; i  DLN2_MAX_URBS; i++) {
   dln2-rx_buf[i] = kmalloc(rx_max_size, GFP_KERNEL);
 @@ -621,7 +626,19 @@ static int dln2_setup_rx_urbs(struct dln2_dev *dln2,
 usb_rcvbulkpipe(dln2-usb_dev, dln2-ep_in),
 dln2-rx_buf[i], rx_max_size, dln2_rx, dln2);
  
 - ret = usb_submit_urb(dln2-rx_urb[i], GFP_KERNEL);
 + }
 +
 + return 0;
 +}
 +
 +static int dln2_start_rx_urbs(struct dln2_dev *dln2, gfp_t gfp)
 +{
 + struct device *dev = dln2-interface-dev;
 + int ret;
 + int i;
 +
 + for (i = 0; i  DLN2_MAX_URBS; i++) {
 + ret = usb_submit_urb(dln2-rx_urb[i], gfp);
   if (ret  0) {
   dev_err(dev, failed to submit RX URB: %d\n, ret);
   return ret;
 @@ -665,9 +682,8 @@ static const struct mfd_cell dln2_devs[] = {
   },
  };
  
 -static void dln2_disconnect(struct usb_interface *interface)
 +static void dln2_stop(struct dln2_dev *dln2)
  {
 - struct dln2_dev *dln2 = usb_get_intfdata(interface);
   int i, j;
  
   /* don't allow starting new transfers */
 @@ -696,6 +712,14 @@ static void dln2_disconnect(struct usb_interface 
 *interface)
   /* wait for transfers to end */
   wait_event(dln2-disconnect_wq, !dln2-active_transfers);
  
 + dln2_stop_rx_urbs(dln2);
 +}
 +static void dln2_disconnect(struct usb_interface *interface)
 +{
 + struct dln2_dev *dln2 = usb_get_intfdata(interface);
 +
 + dln2_stop(dln2);
 +
   mfd_remove_devices(interface-dev);
  
   dln2_free(dln2);
 @@ -738,23 +762,30 @@ static int dln2_probe(struct usb_interface *interface,
  
   ret = dln2_setup_rx_urbs(dln2, hostif);
   if (ret)
 - goto out_cleanup;
 + goto out_free;
 +
 + ret = dln2_start_rx_urbs(dln2, GFP_KERNEL);
 + if (ret)
 + goto out_stop_rx;
  
   ret = dln2_hw_init(dln2);
   if (ret  0) {
   dev_err(dev, failed to initialize hardware\n);
 - goto out_cleanup;
 + goto out_stop_rx;
   }
  
   ret = mfd_add_hotplug_devices(dev, dln2_devs, ARRAY_SIZE(dln2_devs));
   if (ret != 0) {
   dev_err(dev, failed to add mfd devices to core\n);
 - goto out_cleanup;
 + goto out_stop_rx;
   }
  
   return 0;
  
 -out_cleanup:
 +out_stop_rx:
 + dln2_stop_rx_urbs(dln2);
 +
 +out_free:
   dln2_free(dln2);
  
   return ret;

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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 1/3] mfd: add support for Cypress CYUSBS234 USB Serial Bridge controller

[Lee Jones]

 bulk_out_ep_num;
 +   u8 intr_in_ep_num;
 +};
 +
 +enum cy_usbs_vendor_cmds {
 +   CY_DEV_CMD_READ_CONFIG = 0xB5,
 +   CY_I2C_GET_CONFIG_CMD  = 0xC4,
 +   CY_I2C_SET_CONFIG_CMD  = 0xC5,
 +   CY_I2C_WRITE_CMD   = 0xC6,
 +   CY_I2C_READ_CMD= 0xC7,
 +   CY_I2C_GET_STATUS_CMD  = 0xC8,
 +   CY_I2C_RESET_CMD   = 0xC9,
 +   CY_GPIO_GET_CONFIG_CMD = 0xD8,
 +   CY_GPIO_SET_CONFIG_CMD = 0xD9,
 +   CY_GPIO_GET_VALUE_CMD  = 0xDA,
 +   CY_GPIO_SET_VALUE_CMD  = 0xDB,
 +   CY_DEV_ENABLE_CONFIG_READ_CMD  = 0xE2
 +};
 +
 +/* SCB index shift */
 +#define CY_SCB_INDEX_SHIFT  15
 +
 +#define CY_USBS_CTRL_XFER_TIMEOUT  2000
 +#define CY_USBS_BULK_XFER_TIMEOUT  5000
 +#define CY_USBS_INTR_XFER_TIMEOUT  5000
 +
 +#endif /* __MFD_CYUSBS23X_H__ */

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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: hard lockup with USB3380

[Paul Jones]

Ricardo,

I added a ep_warn before and after the loop and right after connecting my Mac 
it passes through that loop many times.
Even without writing to the device I then get the lockup message while inside 
the loop (ep-dev = ep-b).

Paul.

On 25 Nov 2014, at 02:06, Ricardo Ribalda Delgado ricardo.riba...@gmail.com 
wrote:

 Hello
 
 Could you check if the code is stalled at this loop ?
 https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/usb/gadget/udc/net2280.c#n2594
 
 Regards!
 
 On Thu, Nov 13, 2014 at 3:37 PM, Paul Jones p.jo...@teclyn.com wrote:
 Hi,
 
 using the latest kernel from 
 https://git.kernel.org/cgit/linux/kernel/git/balbi/usb.git/ with a USB3380 I 
 get a kernel lockup after setting up an emulated drive and start using it.
 
 In order to reproduce:
dd if=/dev/zero of=somefile bs=64k count=102400
modprobe net2280
modprobe g_mass_storage file=somefile
 I then connect the cable to my Mac, quick format the drive (this works), 
 mount the drive (works as well) and then do write a large file:
dd if=/dev/zero of=mountpoint/file bs=64k count=10240
 I then almost immediately get:
 [  115.886330] [ cut here ]
 [  115.886335] WARNING: CPU: 3 PID: 0 at kernel/watchdog.c:267 
 watchdog_overflow_callback+0x9c/0xd0()
 [  115.886336] Watchdog detected hard LOCKUP on cpu 3
 [  115.886336] Modules linked in: g_mass_storage net2280 usb_f_mass_storage 
 libcomposite udc_core configfs snd_hda_codec_hdmi i915 snd_hda_codec_realtek 
 snd_hda_codec_generic snd_hda_intel snd_hda_controller snd_hda_codec 
 intel_rapl x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm 
 snd_hwdep snd_pcm joydev snd_seq_midi hid_generic crct10dif_pclmul 
 snd_seq_midi_event crc32_pclmul snd_rawmidi ghash_clmulni_intel eeepc_wmi 
 asus_wmi sparse_keymap aesni_intel drm_kms_helper snd_seq drm usbhid hid 
 snd_seq_device aes_x86_64 lrw gf128mul glue_helper snd_timer ablk_helper 
 cryptd snd mei_me mei serio_raw soundcore lpc_ich i2c_algo_bit wmi video 
 mac_hid tpm_infineon rfcomm bnep bluetooth parport_pc ppdev lp parport 
 e1000e psmouse r8169 ptp ahci libahci pps_core mii
 [  115.886361] CPU: 3 PID: 0 Comm: swapper/3 Not tainted 3.17.0-rc5+ #2
 [  115.886362] Hardware name: ASUS All Series/Q87T, BIOS 0215 09/06/2013
 [  115.886363]  0009 88041fb86c10 81746707 
 88041fb86c58
 [  115.886364]  88041fb86c48 8106c93d 8804097fc000 
 
 [  115.886365]  88041fb86d70  88041fb86ef8 
 88041fb86ca8
 [  115.886367] Call Trace:
 [  115.886368]  NMI  [81746707] dump_stack+0x45/0x56
 [  115.886373]  [8106c93d] warn_slowpath_common+0x7d/0xa0
 [  115.886374]  [8106c9ac] warn_slowpath_fmt+0x4c/0x50
 [  115.886376]  [8111a23c] watchdog_overflow_callback+0x9c/0xd0
 [  115.886379]  [811579ed] __perf_event_overflow+0x8d/0x230
 [  115.886381]  [81029db8] ? x86_perf_event_set_period+0xe8/0x150
 [  115.886383]  [81158454] perf_event_overflow+0x14/0x20
 [  115.886385]  [8103136d] intel_pmu_handle_irq+0x1ed/0x3e0
 [  115.886386]  [81028abb] perf_event_nmi_handler+0x2b/0x50
 [  115.886388]  [81016fd8] nmi_handle+0x88/0x120
 [  115.886389]  [810175de] default_do_nmi+0xde/0x140
 [  115.886390]  [810176c8] do_nmi+0x88/0xc0
 [  115.886392]  [81751171] end_repeat_nmi+0x1e/0x2e
 [  115.886394]  [8138099a] ? delay_tsc+0x3a/0x80
 [  115.886395]  [8138099a] ? delay_tsc+0x3a/0x80
 [  115.886396]  [8138099a] ? delay_tsc+0x3a/0x80
 [  115.886397]  EOE  IRQ  [813808dc] __const_udelay+0x2c/0x30
 [  115.886400]  [a054be3a] net2280_irq+0x76a/0x15a8 [net2280]
 [  115.886402]  [8148df1c] ? add_interrupt_randomness+0x3c/0x1f0
 [  115.886405]  [810c090e] handle_irq_event_percpu+0x3e/0x1a0
 [  115.886407]  [810c0aad] handle_irq_event+0x3d/0x60
 [  115.886408]  [810c3657] handle_edge_irq+0x77/0x130
 [  115.886410]  [810154ee] handle_irq+0x1e/0x30
 [  115.886411]  [81751b6f] do_IRQ+0x4f/0xf0
 [  115.886412]  [8174f9ed] common_interrupt+0x6d/0x6d
 [  115.886413]  EOI  [815f4490] ? cpuidle_enter_state+0x70/0x170
 [  115.886416]  [815f4647] cpuidle_enter+0x17/0x20
 [  115.886417]  [810aad9d] cpu_startup_entry+0x31d/0x340
 [  115.886419]  [810dde88] ? 
 clockevents_config_and_register+0x28/0x30
 [  115.886421]  [81045237] start_secondary+0x1a7/0x250
 [  115.886422] ---[ end trace e31adb6e2f340f5d ]—
 
 Output from lspci:
 00:00.0 Host bridge: Intel Corporation 4th Gen Core Processor DRAM 
 Controller (rev 06)
 00:01.0 PCI bridge: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor 
 PCI Express x16 Controller (rev 06)
 00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v3/4th Gen 
 Core Processor Integrated Graphics Controller (rev 06)
 00:03.0 Audio

Re: hard lockup with USB3380

[Paul Jones]

Ricardo,

count = 0, req-valid = 1,  le32_to_cpu(req-td-dmacount) =  2952791040

Paul.
 
On 25 Nov 2014, at 13:09, Ricardo Ribalda Delgado ricardo.riba...@gmail.com 
wrote:

 Could you print
 
 count, req-valid and le32_to_cpu(req-td-dmacount) just before udelay(1)
 
 Thanks!
 
 On Tue, Nov 25, 2014 at 12:05 PM, Paul Jones p.jo...@teclyn.com wrote:
 Ricardo,
 
 I added a ep_warn before and after the loop and right after connecting my 
 Mac it passes through that loop many times.
 Even without writing to the device I then get the lockup message while 
 inside the loop (ep-dev = ep-b).
 
 Paul.
 
 On 25 Nov 2014, at 02:06, Ricardo Ribalda Delgado 
 ricardo.riba...@gmail.com wrote:
 
 Hello
 
 Could you check if the code is stalled at this loop ?
 https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/usb/gadget/udc/net2280.c#n2594
 
 Regards!
 
 On Thu, Nov 13, 2014 at 3:37 PM, Paul Jones p.jo...@teclyn.com wrote:
 Hi,
 
 using the latest kernel from 
 https://git.kernel.org/cgit/linux/kernel/git/balbi/usb.git/ with a USB3380 
 I get a kernel lockup after setting up an emulated drive and start using 
 it.
 
 In order to reproduce:
   dd if=/dev/zero of=somefile bs=64k count=102400
   modprobe net2280
   modprobe g_mass_storage file=somefile
 I then connect the cable to my Mac, quick format the drive (this works), 
 mount the drive (works as well) and then do write a large file:
   dd if=/dev/zero of=mountpoint/file bs=64k count=10240
 I then almost immediately get:
 [  115.886330] [ cut here ]
 [  115.886335] WARNING: CPU: 3 PID: 0 at kernel/watchdog.c:267 
 watchdog_overflow_callback+0x9c/0xd0()
 [  115.886336] Watchdog detected hard LOCKUP on cpu 3
 [  115.886336] Modules linked in: g_mass_storage net2280 
 usb_f_mass_storage libcomposite udc_core configfs snd_hda_codec_hdmi i915 
 snd_hda_codec_realtek snd_hda_codec_generic snd_hda_intel 
 snd_hda_controller snd_hda_codec intel_rapl x86_pkg_temp_thermal 
 intel_powerclamp coretemp kvm_intel kvm snd_hwdep snd_pcm joydev 
 snd_seq_midi hid_generic crct10dif_pclmul snd_seq_midi_event crc32_pclmul 
 snd_rawmidi ghash_clmulni_intel eeepc_wmi asus_wmi sparse_keymap 
 aesni_intel drm_kms_helper snd_seq drm usbhid hid snd_seq_device 
 aes_x86_64 lrw gf128mul glue_helper snd_timer ablk_helper cryptd snd 
 mei_me mei serio_raw soundcore lpc_ich i2c_algo_bit wmi video mac_hid 
 tpm_infineon rfcomm bnep bluetooth parport_pc ppdev lp parport e1000e 
 psmouse r8169 ptp ahci libahci pps_core mii
 [  115.886361] CPU: 3 PID: 0 Comm: swapper/3 Not tainted 3.17.0-rc5+ #2
 [  115.886362] Hardware name: ASUS All Series/Q87T, BIOS 0215 09/06/2013
 [  115.886363]  0009 88041fb86c10 81746707 
 88041fb86c58
 [  115.886364]  88041fb86c48 8106c93d 8804097fc000 
 
 [  115.886365]  88041fb86d70  88041fb86ef8 
 88041fb86ca8
 [  115.886367] Call Trace:
 [  115.886368]  NMI  [81746707] dump_stack+0x45/0x56
 [  115.886373]  [8106c93d] warn_slowpath_common+0x7d/0xa0
 [  115.886374]  [8106c9ac] warn_slowpath_fmt+0x4c/0x50
 [  115.886376]  [8111a23c] watchdog_overflow_callback+0x9c/0xd0
 [  115.886379]  [811579ed] __perf_event_overflow+0x8d/0x230
 [  115.886381]  [81029db8] ? x86_perf_event_set_period+0xe8/0x150
 [  115.886383]  [81158454] perf_event_overflow+0x14/0x20
 [  115.886385]  [8103136d] intel_pmu_handle_irq+0x1ed/0x3e0
 [  115.886386]  [81028abb] perf_event_nmi_handler+0x2b/0x50
 [  115.886388]  [81016fd8] nmi_handle+0x88/0x120
 [  115.886389]  [810175de] default_do_nmi+0xde/0x140
 [  115.886390]  [810176c8] do_nmi+0x88/0xc0
 [  115.886392]  [81751171] end_repeat_nmi+0x1e/0x2e
 [  115.886394]  [8138099a] ? delay_tsc+0x3a/0x80
 [  115.886395]  [8138099a] ? delay_tsc+0x3a/0x80
 [  115.886396]  [8138099a] ? delay_tsc+0x3a/0x80
 [  115.886397]  EOE  IRQ  [813808dc] 
 __const_udelay+0x2c/0x30
 [  115.886400]  [a054be3a] net2280_irq+0x76a/0x15a8 [net2280]
 [  115.886402]  [8148df1c] ? add_interrupt_randomness+0x3c/0x1f0
 [  115.886405]  [810c090e] handle_irq_event_percpu+0x3e/0x1a0
 [  115.886407]  [810c0aad] handle_irq_event+0x3d/0x60
 [  115.886408]  [810c3657] handle_edge_irq+0x77/0x130
 [  115.886410]  [810154ee] handle_irq+0x1e/0x30
 [  115.886411]  [81751b6f] do_IRQ+0x4f/0xf0
 [  115.886412]  [8174f9ed] common_interrupt+0x6d/0x6d
 [  115.886413]  EOI  [815f4490] ? 
 cpuidle_enter_state+0x70/0x170
 [  115.886416]  [815f4647] cpuidle_enter+0x17/0x20
 [  115.886417]  [810aad9d] cpu_startup_entry+0x31d/0x340
 [  115.886419]  [810dde88] ? 
 clockevents_config_and_register+0x28/0x30
 [  115.886421]  [81045237] start_secondary+0x1a7/0x250
 [  115.886422] ---[ end trace e31adb6e2f340f5d ]—
 
 Output from

Re: hard lockup with USB3380

[Paul Jones]

dmactl=37158946, dmastat=50331648, dmacount=805306368, dmadesc=778727536, 
epstat=16528, td_dma=ce40c050

Paul.

On 25 Nov 2014, at 14:08, Ricardo Ribalda Delgado ricardo.riba...@gmail.com 
wrote:

 hmm it seems that the code is waiting for a dma to complete. Please print
 
 ep-dma-dmactl
 ep-dma-dmastat
 ep-dma-dmacount
 ep-dma-dmadesc
 req-td_dma
 ep-regs-ep_stat
 
 
 
 Thanks
 
 On Tue, Nov 25, 2014 at 1:58 PM, Paul Jones p.jo...@teclyn.com wrote:
 Ricardo,
 
 count = 0, req-valid = 1,  le32_to_cpu(req-td-dmacount) =  2952791040
 
 Paul.
 
 On 25 Nov 2014, at 13:09, Ricardo Ribalda Delgado 
 ricardo.riba...@gmail.com wrote:
 
 Could you print
 
 count, req-valid and le32_to_cpu(req-td-dmacount) just before udelay(1)
 
 Thanks!
 
 On Tue, Nov 25, 2014 at 12:05 PM, Paul Jones p.jo...@teclyn.com wrote:
 Ricardo,
 
 I added a ep_warn before and after the loop and right after connecting my 
 Mac it passes through that loop many times.
 Even without writing to the device I then get the lockup message while 
 inside the loop (ep-dev = ep-b).
 
 Paul.
 
 On 25 Nov 2014, at 02:06, Ricardo Ribalda Delgado 
 ricardo.riba...@gmail.com wrote:
 
 Hello
 
 Could you check if the code is stalled at this loop ?
 https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/usb/gadget/udc/net2280.c#n2594
 
 Regards!
 
 On Thu, Nov 13, 2014 at 3:37 PM, Paul Jones p.jo...@teclyn.com wrote:
 Hi,
 
 using the latest kernel from 
 https://git.kernel.org/cgit/linux/kernel/git/balbi/usb.git/ with a 
 USB3380 I get a kernel lockup after setting up an emulated drive and 
 start using it.
 
 In order to reproduce:
  dd if=/dev/zero of=somefile bs=64k count=102400
  modprobe net2280
  modprobe g_mass_storage file=somefile
 I then connect the cable to my Mac, quick format the drive (this works), 
 mount the drive (works as well) and then do write a large file:
  dd if=/dev/zero of=mountpoint/file bs=64k count=10240
 I then almost immediately get:
 [  115.886330] [ cut here ]
 [  115.886335] WARNING: CPU: 3 PID: 0 at kernel/watchdog.c:267 
 watchdog_overflow_callback+0x9c/0xd0()
 [  115.886336] Watchdog detected hard LOCKUP on cpu 3
 [  115.886336] Modules linked in: g_mass_storage net2280 
 usb_f_mass_storage libcomposite udc_core configfs snd_hda_codec_hdmi 
 i915 snd_hda_codec_realtek snd_hda_codec_generic snd_hda_intel 
 snd_hda_controller snd_hda_codec intel_rapl x86_pkg_temp_thermal 
 intel_powerclamp coretemp kvm_intel kvm snd_hwdep snd_pcm joydev 
 snd_seq_midi hid_generic crct10dif_pclmul snd_seq_midi_event 
 crc32_pclmul snd_rawmidi ghash_clmulni_intel eeepc_wmi asus_wmi 
 sparse_keymap aesni_intel drm_kms_helper snd_seq drm usbhid hid 
 snd_seq_device aes_x86_64 lrw gf128mul glue_helper snd_timer ablk_helper 
 cryptd snd mei_me mei serio_raw soundcore lpc_ich i2c_algo_bit wmi video 
 mac_hid tpm_infineon rfcomm bnep bluetooth parport_pc ppdev lp parport 
 e1000e psmouse r8169 ptp ahci libahci pps_core mii
 [  115.886361] CPU: 3 PID: 0 Comm: swapper/3 Not tainted 3.17.0-rc5+ #2
 [  115.886362] Hardware name: ASUS All Series/Q87T, BIOS 0215 09/06/2013
 [  115.886363]  0009 88041fb86c10 81746707 
 88041fb86c58
 [  115.886364]  88041fb86c48 8106c93d 8804097fc000 
 
 [  115.886365]  88041fb86d70  88041fb86ef8 
 88041fb86ca8
 [  115.886367] Call Trace:
 [  115.886368]  NMI  [81746707] dump_stack+0x45/0x56
 [  115.886373]  [8106c93d] warn_slowpath_common+0x7d/0xa0
 [  115.886374]  [8106c9ac] warn_slowpath_fmt+0x4c/0x50
 [  115.886376]  [8111a23c] watchdog_overflow_callback+0x9c/0xd0
 [  115.886379]  [811579ed] __perf_event_overflow+0x8d/0x230
 [  115.886381]  [81029db8] ? 
 x86_perf_event_set_period+0xe8/0x150
 [  115.886383]  [81158454] perf_event_overflow+0x14/0x20
 [  115.886385]  [8103136d] intel_pmu_handle_irq+0x1ed/0x3e0
 [  115.886386]  [81028abb] perf_event_nmi_handler+0x2b/0x50
 [  115.886388]  [81016fd8] nmi_handle+0x88/0x120
 [  115.886389]  [810175de] default_do_nmi+0xde/0x140
 [  115.886390]  [810176c8] do_nmi+0x88/0xc0
 [  115.886392]  [81751171] end_repeat_nmi+0x1e/0x2e
 [  115.886394]  [8138099a] ? delay_tsc+0x3a/0x80
 [  115.886395]  [8138099a] ? delay_tsc+0x3a/0x80
 [  115.886396]  [8138099a] ? delay_tsc+0x3a/0x80
 [  115.886397]  EOE  IRQ  [813808dc] 
 __const_udelay+0x2c/0x30
 [  115.886400]  [a054be3a] net2280_irq+0x76a/0x15a8 [net2280]
 [  115.886402]  [8148df1c] ? 
 add_interrupt_randomness+0x3c/0x1f0
 [  115.886405]  [810c090e] handle_irq_event_percpu+0x3e/0x1a0
 [  115.886407]  [810c0aad] handle_irq_event+0x3d/0x60
 [  115.886408]  [810c3657] handle_edge_irq+0x77/0x130
 [  115.886410]  [810154ee] handle_irq+0x1e/0x30
 [  115.886411]  [81751b6f] do_IRQ+0x4f/0xf0
 [  115.886412

Re: hard lockup with USB3380

[Paul Jones]

Ricardo,

it no longer locks up but if I try to write to the drive, I get cycles of:
[ 2334.127653] [ cut here ]
[ 2334.128318] WARNING: CPU: 0 PID: 2140 at 
drivers/usb/gadget/udc/net2280.c:816 start_dma+0x153/0x160 [net2280]()
[ 2334.129105] Modules linked in: g_mass_storage usb_f_mass_storage 
libcomposite configfs net2280 udc_core snd_hda_codec_hdmi i915 rfcomm bnep 
bluetooth snd_hda_codec_realtek snd_hda_codec_generic intel_rapl 
x86_pkg_temp_thermal snd_hda_intel intel_powerclamp coretemp snd_hda_controller 
kvm_intel snd_hda_codec kvm drm_kms_helper snd_hwdep snd_pcm drm snd_seq_midi 
joydev snd_seq_midi_event snd_rawmidi hid_generic snd_seq eeepc_wmi asus_wmi 
sparse_keymap crct10dif_pclmul usbhid crc32_pclmul ghash_clmulni_intel 
aesni_intel snd_seq_device snd_timer aes_x86_64 hid lrw gf128mul glue_helper 
snd ablk_helper mei_me mei cryptd serio_raw lpc_ich i2c_algo_bit wmi soundcore 
video tpm_infineon mac_hid parport_pc ppdev lp parport e1000e psmouse r8169 
ahci ptp libahci mii pps_core
[ 2334.132731] CPU: 0 PID: 2140 Comm: file-storage Tainted: GW  
3.17.0-rc5+ #2
[ 2334.133438] Hardware name: ASUS All Series/Q87T, BIOS 0215 09/06/2013
[ 2334.134146]  0009 8804087a3d28 81746707 

[ 2334.134863]  8804087a3d60 8106c93d 88002e693478 
8803efd14480
[ 2334.135583]  c900018fc1a0 8803efd144e8 88002e693320 
8804087a3d70
[ 2334.136299] Call Trace:
[ 2334.137023]  [81746707] dump_stack+0x45/0x56
[ 2334.137734]  [8106c93d] warn_slowpath_common+0x7d/0xa0
[ 2334.138433]  [8106ca1a] warn_slowpath_null+0x1a/0x20
[ 2334.139109]  [a0372103] start_dma+0x153/0x160 [net2280]
[ 2334.139795]  [a0373b1b] net2280_queue+0x2db/0x480 [net2280]
[ 2334.140449]  [a03b94f1] start_transfer.isra.32+0x71/0xe0 
[usb_f_mass_storage]
[ 2334.141128]  [a03b959e] start_out_transfer+0x3e/0x80 
[usb_f_mass_storage]
[ 2334.141772]  [a03ba967] fsg_main_thread+0x207/0x17f0 
[usb_f_mass_storage]
[ 2334.142374]  [81749eda] ? __schedule+0x37a/0x830
[ 2334.142950]  [a03ba760] ? handle_exception+0x460/0x460 
[usb_f_mass_storage]
[ 2334.143534]  [8108a3e2] kthread+0xd2/0xf0
[ 2334.144054]  [8108a310] ? kthread_create_on_node+0x180/0x180
[ 2334.144595]  [8174ecbc] ret_from_fork+0x7c/0xb0
[ 2334.145155]  [8108a310] ? kthread_create_on_node+0x180/0x180
[ 2334.145699] ---[ end trace 4ded8927b95f4eec ]---
followed by:
[ 2396.154501] net2280 :01:00.0: The dmastat return = 5002!!
[ 2396.253653] g_mass_storage gadget: super-speed config #1: Linux File-Backed 
Storage

Unplugging  and re-plugging the USB cable does allow me to remount the volume.

Paul.
On 25 Nov 2014, at 15:24, Ricardo Ribalda Delgado ricardo.riba...@gmail.com 
wrote:

 Could you try
 if (likely(t  (BIT(FIFO_EMPTY) | BIT(NAK_OUT_PACKETS{
 
 instead of
 
 if (likely(t  BIT(FIFO_EMPTY)))
 
 
 And tell if it works better

--
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: hard lockup with USB3380

[Paul Jones]

Ricardo,

Unfortunately your latest change gives similar results, cycling errors in the 
log:
[  201.287706] [ cut here ]
[  201.288328] WARNING: CPU: 3 PID: 1500 at 
drivers/usb/gadget/udc/net2280.c:816 start_dma+0x153/0x160 [net2280]()
[  201.288991] Modules linked in: g_mass_storage usb_f_mass_storage 
libcomposite configfs net2280 udc_core snd_hda_codec_hdmi joydev hid_generic 
usbhid hid i915 intel_rapl x86_pkg_temp_thermal intel_powerclamp 
snd_hda_codec_realtek coretemp kvm_intel snd_hda_codec_generic kvm 
snd_hda_intel eeepc_wmi asus_wmi snd_hda_controller rfcomm snd_seq_midi bnep 
snd_seq_midi_event bluetooth sparse_keymap snd_hda_codec crct10dif_pclmul 
snd_rawmidi snd_hwdep crc32_pclmul snd_pcm ghash_clmulni_intel aesni_intel 
aes_x86_64 drm_kms_helper lrw gf128mul glue_helper ablk_helper cryptd snd_seq 
mei_me mei serio_raw drm lpc_ich video mac_hid tpm_infineon wmi snd_seq_device 
snd_timer snd parport_pc i2c_algo_bit soundcore ppdev lp parport e1000e psmouse 
r8169 ahci libahci mii ptp pps_core
[  201.292574] CPU: 3 PID: 1500 Comm: file-storage Tainted: GW  
3.17.0-rc5+ #2
[  201.293277] Hardware name: ASUS All Series/Q87T, BIOS 0215 09/06/2013
[  201.293976]  0009 8803f1d8fd28 81746707 

[  201.294689]  8803f1d8fd60 8106c93d 8803efc26478 
8800ce317100
[  201.295398]  c90005b9c1a0 8800ce317168 8803efc26320 
8803f1d8fd70
[  201.296109] Call Trace:
[  201.296815]  [81746707] dump_stack+0x45/0x56
[  201.297524]  [8106c93d] warn_slowpath_common+0x7d/0xa0
[  201.298218]  [8106ca1a] warn_slowpath_null+0x1a/0x20
[  201.298891]  [a0428103] start_dma+0x153/0x160 [net2280]
[  201.299554]  [a0429b1b] net2280_queue+0x2db/0x480 [net2280]
[  201.300209]  [a04724f1] start_transfer.isra.32+0x71/0xe0 
[usb_f_mass_storage]
[  201.300851]  [a047259e] start_out_transfer+0x3e/0x80 
[usb_f_mass_storage]
[  201.301474]  [a0473967] fsg_main_thread+0x207/0x17f0 
[usb_f_mass_storage]
[  201.302069]  [81749eda] ? __schedule+0x37a/0x830
[  201.302607]  [a0473760] ? handle_exception+0x460/0x460 
[usb_f_mass_storage]
[  201.303200]  [8108a3e2] kthread+0xd2/0xf0
[  201.303776]  [8108a310] ? kthread_create_on_node+0x180/0x180
[  201.304328]  [8174ecbc] ret_from_fork+0x7c/0xb0
[  201.304973]  [8108a310] ? kthread_create_on_node+0x180/0x180
[  201.305486] ---[ end trace a7f3e86a1a37203b ]—
Followed by:
[  263.311338] net2280 :01:00.0: The dmastat return = 5002!!
[  263.409818] g_mass_storage gadget: super-speed config #1: Linux File-Backed 
Storage

as long as you have ideas, I’ll be more than happy to try them :)

Paul.

On 25 Nov 2014, at 15:59, Ricardo Ribalda Delgado ricardo.riba...@gmail.com 
wrote:

 One last try :)
 
 Instead of:
 
 if (likely(t  BIT(FIFO_EMPTY))) {
 
 have this:
 
 if ( t  BIT(NAK_OUT_PACKETS)){
   count = readl(ep-dma-dmacount);
   count = DMA_BYTE_COUNT_MASK;
   break;
 }
 
 if (likely(t  BIT(FIFO_EMPTY))) {
 
 
 
 On Tue, Nov 25, 2014 at 3:54 PM, Paul Jones p.jo...@teclyn.com wrote:
 Ricardo,
 
 it no longer locks up but if I try to write to the drive, I get cycles of:
 [ 2334.127653] [ cut here ]
 [ 2334.128318] WARNING: CPU: 0 PID: 2140 at 
 drivers/usb/gadget/udc/net2280.c:816 start_dma+0x153/0x160 [net2280]()
 [ 2334.129105] Modules linked in: g_mass_storage usb_f_mass_storage 
 libcomposite configfs net2280 udc_core snd_hda_codec_hdmi i915 rfcomm bnep 
 bluetooth snd_hda_codec_realtek snd_hda_codec_generic intel_rapl 
 x86_pkg_temp_thermal snd_hda_intel intel_powerclamp coretemp 
 snd_hda_controller kvm_intel snd_hda_codec kvm drm_kms_helper snd_hwdep 
 snd_pcm drm snd_seq_midi joydev snd_seq_midi_event snd_rawmidi hid_generic 
 snd_seq eeepc_wmi asus_wmi sparse_keymap crct10dif_pclmul usbhid 
 crc32_pclmul ghash_clmulni_intel aesni_intel snd_seq_device snd_timer 
 aes_x86_64 hid lrw gf128mul glue_helper snd ablk_helper mei_me mei cryptd 
 serio_raw lpc_ich i2c_algo_bit wmi soundcore video tpm_infineon mac_hid 
 parport_pc ppdev lp parport e1000e psmouse r8169 ahci ptp libahci mii 
 pps_core
 [ 2334.132731] CPU: 0 PID: 2140 Comm: file-storage Tainted: GW  
 3.17.0-rc5+ #2
 [ 2334.133438] Hardware name: ASUS All Series/Q87T, BIOS 0215 09/06/2013
 [ 2334.134146]  0009 8804087a3d28 81746707 
 
 [ 2334.134863]  8804087a3d60 8106c93d 88002e693478 
 8803efd14480
 [ 2334.135583]  c900018fc1a0 8803efd144e8 88002e693320 
 8804087a3d70
 [ 2334.136299] Call Trace:
 [ 2334.137023]  [81746707] dump_stack+0x45/0x56
 [ 2334.137734]  [8106c93d] warn_slowpath_common+0x7d/0xa0
 [ 2334.138433]  [8106ca1a] warn_slowpath_null+0x1a/0x20
 [ 2334.139109]  [a0372103] start_dma+0x153/0x160 [net2280]
 [ 2334.139795]  [a0373b1b