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

[Nicholas A. Bellinger]

Hi Felipe + usb-gadget folks,

On Wed, 2016-03-02 at 13:55 +0200, Felipe Balbi wrote:
> Dan Carpenter  writes:
> > We need to move the kfree() down a line so we don't dereference a freed
> > variable.
> >
> > Fixes: 1b418a8fcbc0 ('target: Convert demo-mode only drivers to 
> > target_alloc_session')
> > Signed-off-by: Dan Carpenter 
> 
> It's okay to take this via target:
> 
> Signed-off-by: Felipe Balbi 
> 

Note this specific patch is only a mechanical change, and we still need
reviews for the more interesting conversions:

usb-gadget/tcm: Conversion to percpu_ida tag pre-allocation
http://www.spinics.net/lists/target-devel/msg11777.html

usb-gadget/tcm: Convert to TARGET_SCF_ACK_KREF I/O krefs
http://www.spinics.net/lists/target-devel/msg11782.html

Felipe, Sebastian, & Andrezj, would you be so kind to review and test
usb-gadget using target-pending/for-next code..?

--
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 -target tree] usb: gadget: f_tcm: use after free

[Nicholas A. Bellinger]

On Wed, 2016-03-02 at 13:08 +0300, Dan Carpenter wrote:
> We need to move the kfree() down a line so we don't dereference a freed
> variable.
> 
> Fixes: 1b418a8fcbc0 ('target: Convert demo-mode only drivers to 
> target_alloc_session')
> Signed-off-by: Dan Carpenter 
> 
> diff --git a/drivers/usb/gadget/function/f_tcm.c 
> b/drivers/usb/gadget/function/f_tcm.c
> index 7276a73..e352a31 100644
> --- a/drivers/usb/gadget/function/f_tcm.c
> +++ b/drivers/usb/gadget/function/f_tcm.c
> @@ -1596,8 +1596,8 @@ static int tcm_usbg_make_nexus(struct usbg_tpg *tpg, 
> char *name)
>  #define MAKE_NEXUS_MSG "core_tpg_check_initiator_node_acl() failed for %s\n"
>   pr_debug(MAKE_NEXUS_MSG, name);
>  #undef MAKE_NEXUS_MSG
> - kfree(tv_nexus);
>   ret = PTR_ERR(tv_nexus->tvn_se_sess);
> + kfree(tv_nexus);
>   }
>  
>  out_unlock:

Fixed + squashed into the original patch.

Thanks Dan.

--
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 v10 1/9] dt-bindings: phy: Add NVIDIA Tegra XUSB pad controller binding

[Rob Herring]

On Fri, Mar 04, 2016 at 05:19:31PM +0100, Thierry Reding wrote:
> From: Thierry Reding 
> 
> The NVIDIA Tegra XUSB pad controller provides a set of pads, each with a
> set of lanes that are used for PCIe, SATA and USB.
> 
> Signed-off-by: Thierry Reding 
> ---
> Changes in v10:
> - clarify that the hardware documentation means something different when
>   referring to a "port" (intra-SoC connectivity)
> 
> Changes in v9:
> - rename UTMI -> USB2 to match hardware documentation
> - reword according to suggestions by Stephen Warren
> - make Tegra132 compatible string list consistent
> - remove mailbox support
> 
>  .../bindings/phy/nvidia,tegra124-xusb-padctl.txt   | 376 
> +
>  .../pinctrl/nvidia,tegra124-xusb-padctl.txt|   5 +
>  2 files changed, 381 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/phy/nvidia,tegra124-xusb-padctl.txt

Without really understanding the h/w here, looks okay to me.

Acked-by: Rob Herring 

> +SoC include:
> +
> + padctl@0,7009f000 {

Drop the comma. Commas should only be used if there are distinct fields.

If I get my dtc patch done, these are going to start warning, so you 
might want to go fix dts files (assuming that's where this is coming 
from).

Rob
--
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 v10 2/9] dt-bindings: pinctrl: Deprecate Tegra XUSB pad controller binding

[Rob Herring]

On Fri, Mar 04, 2016 at 05:19:32PM +0100, Thierry Reding wrote:
> From: Thierry Reding 
> 
> This is an old version of the binding that isn't flexible enough to
> describe all aspects of the XUSB pad controller. Specifically with the
> addition of XUSB support (for SuperSpeed USB) the existing binding is
> no longer suitable.
> 
> Signed-off-by: Thierry Reding 
> ---
>  .../devicetree/bindings/pinctrl/nvidia,tegra124-xusb-padctl.txt  | 1 
> +
>  1 file changed, 1 insertion(+)

Acked-by: Rob Herring 
--
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 v10 3/9] dt-bindings: phy: tegra-xusb-padctl: Add Tegra210 support

[Rob Herring]

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

Acked-by: Rob Herring 

> +Tegra210:
> +-
> +
> +SoC include:
> +
> + padctl@0,7009f000 {

Drop the comma.
--
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/3] usb: core: add power sequence for USB devices

[Rob Herring]

On Fri, Mar 04, 2016 at 10:37:50AM +0800, Peter Chen wrote:
> On Fri, Mar 04, 2016 at 03:23:05AM +0100, Andrew Lunn wrote:
> > On Fri, Mar 04, 2016 at 10:02:42AM +0800, Peter Chen wrote:
> > > On Thu, Mar 03, 2016 at 02:54:55PM -0600, Rob Herring wrote:
> > > > On Thu, Mar 3, 2016 at 4:01 AM, Peter Chen  wrote:
> > > > > Some hard-wired USB devices need to do power sequence to let the
> > > > > device work normally, the typical power sequence like: enable USB
> > > > > PHY clock, toggle reset pin, etc. But current Linux USB driver
> > > > > lacks of such code to do it, it may cause some hard-wired USB devices
> > > > > works abnormal or can't be recognized by controller at all.
> > > > >
> > > > > In this patch, it will do power on sequence at hub's probe for all
> > > > > devices under this hub (includes root hub) if this device is described
> > > > > at dts and there is a phandle "usb-pwrseq" for it. At hub_disconnect,
> > > > > it will do power off sequence.
> > > > >
> > > > > Signed-off-by: Peter Chen 
> > > > > ---
> > > > >  .../devicetree/bindings/usb/usb-device.txt |  41 +-
> > > > >  drivers/usb/core/Makefile  |   2 +-
> > > > >  drivers/usb/core/hub.c |  32 +
> > > > >  drivers/usb/core/pwrseq.c  | 149 
> > > > > +
> > > > >  include/linux/usb/of.h |  10 ++
> > > > >  5 files changed, 232 insertions(+), 2 deletions(-)
> > > > >  create mode 100644 drivers/usb/core/pwrseq.c
> > > > >
> > > > > diff --git a/Documentation/devicetree/bindings/usb/usb-device.txt 
> > > > > b/Documentation/devicetree/bindings/usb/usb-device.txt
> > > > > index 1c35e7b..c7a298c 100644
> > > > > --- a/Documentation/devicetree/bindings/usb/usb-device.txt
> > > > > +++ b/Documentation/devicetree/bindings/usb/usb-device.txt
> > > > > @@ -13,8 +13,37 @@ Required properties:
> > > > >  - reg: the port number which this device is connecting to, the range
> > > > >is 1-31.
> > > > >
> > > > > +Optional properties:
> > > > > +- usb-pwrseq: the power sequence handler which need to do before 
> > > > > this USB
> > > > > +  device can work.
> > > > > +- clocks: the input clock for USB device.
> > > > > +- clock-frequency: the frequency for device's clock.
> > > > > +- reset-gpios: Should specify the GPIO for reset.
> > > > > +- reset-duration-us: the duration in microsecond for assert reset 
> > > > > signal.
> > > > 
> > > > So we sorted out how to describe USB devices in DT, but now we don't
> > > > use it?
> > > 
> > > We only know USB device after USB bus finds it, but without power
> > > on sequence, the USB bus can't find it.
> > 
> > Not really true. Device tree says it exists, you just cannot see it
> > yet. The fact it is in device tree means it is soldered on the board
> > and really is there. So when the host controller enumerates the bus,
> > it should run the power sequence of all child nodes to make them
> > appear.
> > 

Exactly.

> Yes, it is my patch doing. My words "We only know USB device after USB
> bus finds it" means the USB common code only create the USB device, and
> assign its .of_node after USB bus finds it.

I understand the problem. It is just as easy for you to search power 
sequence child nodes as searching the *actual* child nodes for devices. 
The main difference is that a power sequence node indicates that power 
sequencing can be handled generically. With the device nodes, you have 
to assume that the presence of standard properties like reset-gpios 
means you can handle it generically. 

Either solution suffers from not handling cases that can't be handled 
generically. No doubt, we'll just see continued extensions to keep 
things generic when they really shouldn't be.

Rob
--
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: [GIT PULL] USB changes for v4.6

[Greg Kroah-Hartman]

On Fri, Mar 04, 2016 at 03:19:11PM +0200, Felipe Balbi wrote:
> 
> Hi Greg,
> 
> here's the gadget pull request for v4.6. This time I had to based it on
> top of your greg/usb-next to avoid duplicated commits for the USB 3.1
> work which some dwc3 changes depended on. Another benefit of the rebase
> is that I don't have a merge commit of v4.5-rc6 anymore :-)
> 
> Let me know if you want anything to be changed
> 
> cheers
> 
> The following changes since commit 7b05d3b37437f8d50a75545a0fd56ee585c58821:
> 
>   Merge tag 'usb-ci-v4.6-rc1' of 
> git://git.kernel.org/pub/scm/linux/kernel/git/peter.chen/usb into usb-next 
> (2016-03-01 16:33:53 -0800)
> 
> are available in the git repository at:
> 
>   http://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git 
> tags/usb-for-v4.6

Looks good, all now pulled and pushed out.

greg k-h
--
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: Odd merge 3b30be3b6487 ("Merge tag 'v4.5-rc6' into next")

[John Youn]

On 3/4/2016 6:14 PM, Doug Anderson wrote:
> Hi,
> 
> On Fri, Mar 4, 2016 at 5:56 PM, John Youn <john.y...@synopsys.com> wrote:
>> On 3/4/2016 5:04 PM, Doug Anderson wrote:
>>> Felipe,
>>>
>>> Michael pointed out that there's an odd merge that happened.
>>> Specifically it looks like commit bd84f4ae9986 ("usb: dwc2: Add extra
>>> delay when forcing dr_mode") got lost somehow in the merge commit
>>> 3b30be3b6487 ("Merge tag 'v4.5-rc6' into next")
>>>
>>> Specifically:
>>>
>>> $ git blame 3b30be3b6487 -- drivers/usb/dwc2/core.c | grep "This is 
>>> required"
>>> $ git blame 3b30be3b6487^2 -- drivers/usb/dwc2/core.c | grep "This is 
>>> required"
>>> bd84f4ae9986a drivers/usb/dwc2/core.c (John Youn
>>> 2016-02-15 15:30:20 -0800  624)   * NOTE: This is required for some
>>> rockchip soc based
>>>
>>>
>>> I think I'm about at the limit of my git-fu, so I'm a bit baffled.
>>> Any idea what happened?  Was anything else lost?
>>>
>>
>>
>> Felipe recently rebased his next branch without the merge commit
>> referenced above. So maybe that's causing some issues.
>>
>> But everything seems ok to me. I see the commit and correct code on
>> 4.5-rc6, Felipe's next branch, and Greg's usb-next.
> 
> They are missing from from next-20160304 and next-20160303 (though in
> next-20160302) as found by Michael.
> 
> -Doug
> 

Ah okay I do see that too. Could be because of the rebase...

Maybe it'll all be sorted by the next next tree :)

John



--
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: [RFT PATCH 1/2] usb: dwc2: Add a 10 ms delay to dwc2_core_reset()

[John Youn]

On 3/4/2016 10:23 AM, Douglas Anderson wrote:
> From testing and trying to make sense of the documentation, it appears
> that a 10 ms delay is needed after resetting the core to make sure that
> everything is stable and consistent.  Let's add it.
> 
> In my testing (on rk3288) this allows us to revert commit
> 192cb07f7928 ("usb: dwc2: Fix probe problem on bcm2835").  Though I
> could never reproduce the problems on my board, this might also allow us
> to revert commit bd84f4ae9986 ("usb: dwc2: Add extra delay when forcing
> dr_mode").
> 
> Signed-off-by: Douglas Anderson 
> ---
>  drivers/usb/dwc2/core.c | 20 
>  1 file changed, 20 insertions(+)
> 
> diff --git a/drivers/usb/dwc2/core.c b/drivers/usb/dwc2/core.c
> index 5e5a0f135b5a..8710b2d3e770 100644
> --- a/drivers/usb/dwc2/core.c
> +++ b/drivers/usb/dwc2/core.c
> @@ -277,6 +277,26 @@ int dwc2_core_reset(struct dwc2_hsotg *hsotg)
>   }
>   } while (!(greset & GRSTCTL_AHBIDLE));
>  
> + /*
> +  * Sleep for 10-15 ms after the reset to let it finish.
> +  *
> +  * It's been confirmed on at least one version of the controller
> +  * that this is a requirement that this is a requirement in order for
> +  * everything to settle.  Specifically if you:
> +  * - change GNPTXFSIZ or HPTXFSIZ before the reset
> +  * - do the reset
> +  * - read GNPTXFSIZ or HPTXFSIZ in a loop
> +  * ...you'll find that it takes almost exactly 10 ms for the registers
> +  * to return to their reset defaults.
> +  *
> +  * Note that it's possible that this 10 ms is the time referred to
> +  * in "Host Initialization" where it says to "Wait at least 10 ms for
> +  * the reset process to complete".  In "Device Initialization" there
> +  * is also talk of a reset lasting 10 ms.  That may be the source of
> +  * this delay.
> +  */
> + usleep_range(1, 15000);
> +
>   return 0;
>  }
>  
> 

Hi Doug,

Thanks for tracking this down.

Caesar,

Could you test these two commits on your rk3066 platform? And also see
if it works after reverting bd84f4ae9986?

Thanks,
John
--
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: Odd merge 3b30be3b6487 ("Merge tag 'v4.5-rc6' into next")

[Doug Anderson]

Hi,

On Fri, Mar 4, 2016 at 5:56 PM, John Youn <john.y...@synopsys.com> wrote:
> On 3/4/2016 5:04 PM, Doug Anderson wrote:
>> Felipe,
>>
>> Michael pointed out that there's an odd merge that happened.
>> Specifically it looks like commit bd84f4ae9986 ("usb: dwc2: Add extra
>> delay when forcing dr_mode") got lost somehow in the merge commit
>> 3b30be3b6487 ("Merge tag 'v4.5-rc6' into next")
>>
>> Specifically:
>>
>> $ git blame 3b30be3b6487 -- drivers/usb/dwc2/core.c | grep "This is required"
>> $ git blame 3b30be3b6487^2 -- drivers/usb/dwc2/core.c | grep "This is 
>> required"
>> bd84f4ae9986a drivers/usb/dwc2/core.c (John Youn
>> 2016-02-15 15:30:20 -0800  624)   * NOTE: This is required for some
>> rockchip soc based
>>
>>
>> I think I'm about at the limit of my git-fu, so I'm a bit baffled.
>> Any idea what happened?  Was anything else lost?
>>
>
>
> Felipe recently rebased his next branch without the merge commit
> referenced above. So maybe that's causing some issues.
>
> But everything seems ok to me. I see the commit and correct code on
> 4.5-rc6, Felipe's next branch, and Greg's usb-next.

They are missing from from next-20160304 and next-20160303 (though in
next-20160302) as found by Michael.

-Doug
--
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: Odd merge 3b30be3b6487 ("Merge tag 'v4.5-rc6' into next")

[John Youn]

On 3/4/2016 5:04 PM, Doug Anderson wrote:
> Felipe,
> 
> Michael pointed out that there's an odd merge that happened.
> Specifically it looks like commit bd84f4ae9986 ("usb: dwc2: Add extra
> delay when forcing dr_mode") got lost somehow in the merge commit
> 3b30be3b6487 ("Merge tag 'v4.5-rc6' into next")
> 
> Specifically:
> 
> $ git blame 3b30be3b6487 -- drivers/usb/dwc2/core.c | grep "This is required"
> $ git blame 3b30be3b6487^2 -- drivers/usb/dwc2/core.c | grep "This is 
> required"
> bd84f4ae9986a drivers/usb/dwc2/core.c (John Youn
> 2016-02-15 15:30:20 -0800  624)   * NOTE: This is required for some
> rockchip soc based
> 
> 
> I think I'm about at the limit of my git-fu, so I'm a bit baffled.
> Any idea what happened?  Was anything else lost?
> 


Felipe recently rebased his next branch without the merge commit
referenced above. So maybe that's causing some issues.

But everything seems ok to me. I see the commit and correct code on
4.5-rc6, Felipe's next branch, and Greg's usb-next.

John
--
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: [RFT PATCH 1/2] usb: dwc2: Add a 10 ms delay to dwc2_core_reset()

[Doug Anderson]

Hi,

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

 In my testing (on rk3288) this allows us to revert commit
 192cb07f7928 ("usb: dwc2: Fix probe problem on bcm2835").  Though I
 could never reproduce the problems on my board, this might also allow us
 to revert commit bd84f4ae9986 ("usb: dwc2: Add extra delay when forcing
 dr_mode").

 Signed-off-by: Douglas Anderson 
>>>
>>> Tested-by: Michael Niewoehner 
>
> Thanks!  That's great news!
>
>
>>> I’m a bit confused since git log says bd84f4ae9986 has been merged in 
>>> 62718e304aa6 but looking at drivers/usb/dwc2/core.c it seems the patch has 
>>> not been applied anyways ...
>>> However, I tested you your two patches with „magically reverted“ 
>>> bd84f4ae9986 (msleep 50) on rk3188.
>>> The sdcard keeps being detected and boots just fine.
>> I meant usb stick of course… too much sdcards in my head today \o/.
>
> Odd.  It looks to be there for me...
>
> $ git checkout 62718e304aa6
> HEAD is now at 62718e304aa6... Merge tag 'usb-4.5-rc6' of
> git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb
>
> $ git grep -C3 "NOTE: This is required" -- drivers/usb/dwc2/core.c
> drivers/usb/dwc2/core.c-}
> drivers/usb/dwc2/core.c-
> drivers/usb/dwc2/core.c-/*
> drivers/usb/dwc2/core.c: * NOTE: This is required for some
> rockchip soc based
> drivers/usb/dwc2/core.c- * platforms.
> drivers/usb/dwc2/core.c- */
> drivers/usb/dwc2/core.c-msleep(50);

For anyone playing along at home, please see
.

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

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

[Doug Anderson]

Felipe,

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

Specifically:

$ git blame 3b30be3b6487 -- drivers/usb/dwc2/core.c | grep "This is required"
$ git blame 3b30be3b6487^2 -- drivers/usb/dwc2/core.c | grep "This is required"
bd84f4ae9986a drivers/usb/dwc2/core.c (John Youn
2016-02-15 15:30:20 -0800  624)   * NOTE: This is required for some
rockchip soc based


I think I'm about at the limit of my git-fu, so I'm a bit baffled.
Any idea what happened?  Was anything else lost?

-Doug
--
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: [RFT PATCH 1/2] usb: dwc2: Add a 10 ms delay to dwc2_core_reset()

[Doug Anderson]

Hi,

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

Thanks for catching.  I'm happy to re-post with fixed wording or have
a maintainer adjust it to this if/when it is applied:

* It's been confirmed on at least one version of the
* controller that this is a requirement in order for
* everything to settle.  Specifically if you:

Please let me know if you'd like it re-posted.


-Doug
--
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: [RFT PATCH 1/2] usb: dwc2: Add a 10 ms delay to dwc2_core_reset()

[Doug Anderson]

Michael,

On Fri, Mar 4, 2016 at 4:09 PM, Michael Niewoehner  wrote:
>>> From testing and trying to make sense of the documentation, it appears
>>> that a 10 ms delay is needed after resetting the core to make sure that
>>> everything is stable and consistent.  Let's add it.
>>>
>>> In my testing (on rk3288) this allows us to revert commit
>>> 192cb07f7928 ("usb: dwc2: Fix probe problem on bcm2835").  Though I
>>> could never reproduce the problems on my board, this might also allow us
>>> to revert commit bd84f4ae9986 ("usb: dwc2: Add extra delay when forcing
>>> dr_mode").
>>>
>>> Signed-off-by: Douglas Anderson 
>>
>> Tested-by: Michael Niewoehner 

Thanks!  That's great news!


>> I’m a bit confused since git log says bd84f4ae9986 has been merged in 
>> 62718e304aa6 but looking at drivers/usb/dwc2/core.c it seems the patch has 
>> not been applied anyways ...
>> However, I tested you your two patches with „magically reverted“ 
>> bd84f4ae9986 (msleep 50) on rk3188.
>> The sdcard keeps being detected and boots just fine.
> I meant usb stick of course… too much sdcards in my head today \o/.

Odd.  It looks to be there for me...

$ git checkout 62718e304aa6
HEAD is now at 62718e304aa6... Merge tag 'usb-4.5-rc6' of
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb

$ git grep -C3 "NOTE: This is required" -- drivers/usb/dwc2/core.c
drivers/usb/dwc2/core.c-}
drivers/usb/dwc2/core.c-
drivers/usb/dwc2/core.c-/*
drivers/usb/dwc2/core.c: * NOTE: This is required for some
rockchip soc based
drivers/usb/dwc2/core.c- * platforms.
drivers/usb/dwc2/core.c- */
drivers/usb/dwc2/core.c-msleep(50);
--
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: [RFT PATCH 1/2] usb: dwc2: Add a 10 ms delay to dwc2_core_reset()

[Michael Niewoehner]

Hi Douglas,

Am 04.03.2016 um 23:54 schrieb Michael Niewoehner :

> Hi Douglas,
> 
> Am 04.03.2016 um 19:23 schrieb Douglas Anderson :
> 
>> From testing and trying to make sense of the documentation, it appears
>> that a 10 ms delay is needed after resetting the core to make sure that
>> everything is stable and consistent.  Let's add it.
>> 
>> In my testing (on rk3288) this allows us to revert commit
>> 192cb07f7928 ("usb: dwc2: Fix probe problem on bcm2835").  Though I
>> could never reproduce the problems on my board, this might also allow us
>> to revert commit bd84f4ae9986 ("usb: dwc2: Add extra delay when forcing
>> dr_mode").
>> 
>> Signed-off-by: Douglas Anderson 
> 
> Tested-by: Michael Niewoehner 
> 
>> ---
>> drivers/usb/dwc2/core.c | 20 
>> 1 file changed, 20 insertions(+)
>> 
>> diff --git a/drivers/usb/dwc2/core.c b/drivers/usb/dwc2/core.c
>> index 5e5a0f135b5a..8710b2d3e770 100644
>> --- a/drivers/usb/dwc2/core.c
>> +++ b/drivers/usb/dwc2/core.c
>> @@ -277,6 +277,26 @@ int dwc2_core_reset(struct dwc2_hsotg *hsotg)
>>  }
>>  } while (!(greset & GRSTCTL_AHBIDLE));
>> 
>> +/*
>> + * Sleep for 10-15 ms after the reset to let it finish.
>> + *
>> + * It's been confirmed on at least one version of the controller
>> + * that this is a requirement that this is a requirement in order for
>> + * everything to settle.  Specifically if you:
>> + * - change GNPTXFSIZ or HPTXFSIZ before the reset
>> + * - do the reset
>> + * - read GNPTXFSIZ or HPTXFSIZ in a loop
>> + * ...you'll find that it takes almost exactly 10 ms for the registers
>> + * to return to their reset defaults.
>> + *
>> + * Note that it's possible that this 10 ms is the time referred to
>> + * in "Host Initialization" where it says to "Wait at least 10 ms for
>> + * the reset process to complete".  In "Device Initialization" there
>> + * is also talk of a reset lasting 10 ms.  That may be the source of
>> + * this delay.
>> + */
>> +usleep_range(1, 15000);
>> +
>>  return 0;
>> }
>> 
>> -- 
>> 2.7.0.rc3.207.g0ac5344
>> 
> 
> I’m a bit confused since git log says bd84f4ae9986 has been merged in 
> 62718e304aa6 but looking at drivers/usb/dwc2/core.c it seems the patch has 
> not been applied anyways ...
> However, I tested you your two patches with „magically reverted“ bd84f4ae9986 
> (msleep 50) on rk3188.
> The sdcard keeps being detected and boots just fine.
> 
> Best regards
> Michael

I meant usb stick of course… too much sdcards in my head today \o/.

Regards
Michael
--
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: [RFT PATCH 1/2] usb: dwc2: Add a 10 ms delay to dwc2_core_reset()

[Sergei Shtylyov]

Hello.

On 03/04/2016 09:23 PM, Douglas Anderson wrote:


 From testing and trying to make sense of the documentation, it appears
that a 10 ms delay is needed after resetting the core to make sure that
everything is stable and consistent.  Let's add it.

In my testing (on rk3288) this allows us to revert commit
192cb07f7928 ("usb: dwc2: Fix probe problem on bcm2835").  Though I
could never reproduce the problems on my board, this might also allow us
to revert commit bd84f4ae9986 ("usb: dwc2: Add extra delay when forcing
dr_mode").

Signed-off-by: Douglas Anderson 
---
  drivers/usb/dwc2/core.c | 20 
  1 file changed, 20 insertions(+)

diff --git a/drivers/usb/dwc2/core.c b/drivers/usb/dwc2/core.c
index 5e5a0f135b5a..8710b2d3e770 100644
--- a/drivers/usb/dwc2/core.c
+++ b/drivers/usb/dwc2/core.c
@@ -277,6 +277,26 @@ int dwc2_core_reset(struct dwc2_hsotg *hsotg)
}
} while (!(greset & GRSTCTL_AHBIDLE));

+   /*
+* Sleep for 10-15 ms after the reset to let it finish.
+*
+* It's been confirmed on at least one version of the controller
+* that this is a requirement that this is a requirement in order for


   Saying it once is enough. :-)

[...]

MBR, Sergei

--
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: [RFT PATCH 1/2] usb: dwc2: Add a 10 ms delay to dwc2_core_reset()

[Karl Palsson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

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

^^ duplicate wording here.


Cheers,
Karl P

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBAgAGBQJW2h5AAAoJEBmotQ/U1cr2izQQAJ26Rnz1arSPnccUXyOilD9g
vkf6wEEZNHsQUsnrzLbY9+x7rUAWgK6Wq+LYFv7vsOL63ogKpf6O52bZVE0/KQkT
IABKZB312AecotpbSdsZBXaK1SYFUXSRd0CDHqnL9o7SBE2sNRVVd+e/h2z45hUg
H2KkHZbzJA5btZveR+kkYX8PzV3QTBAmgqZ4YjI3uFllQtcRyJflYg9lJNm/GzpG
+ckG/JDlfSfv8Y4C7CrvCot0iTktLXFgzYO8ftI2z8ZAbV2IP3kOf2sc+8b+TX34
yI3odnpf+N0lNQhJESQaYAbOLF45SLGbFK5cqi1zi0AuHJA2eTISOOZWo5Zl/nhE
vneDG6zkS2q0YQRJlBIq23KxTdT9WJjW6qNs+OhVFo5k1900GWtuibfKr43g7JeF
l2d5uVeL9trwDUNmMvyGelSRXL12DhJ/k3IX1TgVMPsfACbGFWS74nzWfdHYjTUS
48ou5a9QED632Na1ZsxhSa1Ce4IOn7Uhaa13WIjKqo8IZM5TXEWwTAczF/9lLpBM
kz4Gb1tII5lQt0KpTOMHs/rXs0/k9iq0x0zuSUVNQEYJrAPhcJ/r+SBRJMqQb5Zy
jzsMzWiuYrL7hpAjQv9s9vyJdQT+/IlIhgM3g+MiQat+LO3uUO10xIspK1+hIglJ
A9VTP1o6Il8hRlQGrqLl
=p21r
-END PGP SIGNATURE-

Re: Possible double-free in the usbnet driver

[Andrey Konovalov]

On Sat, Mar 5, 2016 at 2:00 AM, Andrey Konovalov  wrote:
> On Sat, Mar 5, 2016 at 1:42 AM, Oliver Neukum  wrote:
>> On Sat, 2016-03-05 at 01:26 +0300, Andrey Konovalov wrote:
>>> and when I run the vm and connect the device I get:
>>>
>>> [   23.672662] cdc_ncm 1-1:1.6: bind() failure
>>> [   23.673447] usbnet_probe(): freeing netdev: 88006ab48000
>>> [   23.675822] usbnet_probe(): freeing netdev: 88006ab48000
>>>
>>> So this seems to be a double-free (or at least a double free_netdev()
>>> call), but the object gets freed twice from usbnet_probe() and not
>>> from usbnet_disconnect(), so you're right that the latter doesn't get
>>> called. I'm not sure how usbnet_probe() ends up being called twice.
>>
>> Do you have lsusb?
>
> You mean inside the vm?
> I do.

Or did you want the faulty device descriptor itself?

I used this:

Speed High
Bus 004 Device 003: ID 0bdb:1911
Device Descriptor:
  bLength 18
  bDescriptorType  1
  bcdUSB2.00
  bDeviceClass 2 Communications
  bDeviceSubClass  0
  bDeviceProtocol  0
  bMaxPacketSize0 64
  idVendor0x
  idProduct   0x
  bcdDevice 0.00
  iManufacturer1
  iProduct 2
  iSerial  3
  bNumConfigurations   1
Configuration Descriptor:
  bLength  9
  bDescriptorType  2
  wTotalLength   371
  bNumInterfaces  11
  bConfigurationValue  1
  iConfiguration   4
  bmAttributes  0xe0
Self Powered
Remote Wakeup
  bMaxPower0mA
Interface Descriptor:
  bLength  9
  bDescriptorType  4
  bInterfaceNumber 6
  bAlternateSetting0
  bNumEndpoints1
  bInterfaceClass  2 Communications
  bInterfaceSubClass  13
  bInterfaceProtocol   0
  iInterface  11

>
>>
>> Regards
>> Oliver
>>
>>
--
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: Possible double-free in the usbnet driver

[Andrey Konovalov]

On Sat, Mar 5, 2016 at 1:42 AM, Oliver Neukum  wrote:
> On Sat, 2016-03-05 at 01:26 +0300, Andrey Konovalov wrote:
>> and when I run the vm and connect the device I get:
>>
>> [   23.672662] cdc_ncm 1-1:1.6: bind() failure
>> [   23.673447] usbnet_probe(): freeing netdev: 88006ab48000
>> [   23.675822] usbnet_probe(): freeing netdev: 88006ab48000
>>
>> So this seems to be a double-free (or at least a double free_netdev()
>> call), but the object gets freed twice from usbnet_probe() and not
>> from usbnet_disconnect(), so you're right that the latter doesn't get
>> called. I'm not sure how usbnet_probe() ends up being called twice.
>
> Do you have lsusb?

You mean inside the vm?
I do.

>
> Regards
> Oliver
>
>
--
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: Possible double-free in the usbnet driver

[Andrey Konovalov]

On Sat, Mar 5, 2016 at 1:43 AM, Linus Torvalds
 wrote:
> On Fri, Mar 4, 2016 at 2:26 PM, Andrey Konovalov  wrote:
>>
>> and when I run the vm and connect the device I get:
>>
>> [   23.672662] cdc_ncm 1-1:1.6: bind() failure
>> [   23.673447] usbnet_probe(): freeing netdev: 88006ab48000
>> [   23.675822] usbnet_probe(): freeing netdev: 88006ab48000
>>
>> So this seems to be a double-free (or at least a double free_netdev()
>> call), but the object gets freed twice from usbnet_probe() and not
>> from usbnet_disconnect(), so you're right that the latter doesn't get
>> called. I'm not sure how usbnet_probe() ends up being called twice.
>
> I still don't think it's a double free. I think the probe thing is
> called twice, and that's why to different allocations get free'd twice
> (and the reason it's the same pointer is that the same allocation got
> reused)
>
> But I don't know that driver, really.
>
>>> Which particular usbnet bind routine is this? There are multiple
>>> sub-drivers for usbnet that all do different things.
>>
>> cdc_ncm_bind()
>
> Ok, so that matches my theory.
>
> Does this attached stupid patch make the warning go away? Because from
> what I can tell, usbnet_link_change() really will start using that
> "dev" that simply isn't valid - and will be free'd - if the bind
> fails.

Yes, KASAN doesn't report anything with your patch.

>
> So you have usbnet_defer_kevent() getting triggered, which in turn
> ends up using "usbnet->kevent"
>
> But somebody like Oliver is really the right person to check this. For
> example, it's entirely possible that we should just instead do
>
> cancel_work_sync(>kevent);
>
> before the "free_netdev(net)" in the "out1" label.
>
> And there might be other things that bind() can have touched than the
> kevent workqueue.
>
>Linus
--
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: [RFT PATCH 1/2] usb: dwc2: Add a 10 ms delay to dwc2_core_reset()

[Michael Niewoehner]

Hi Douglas,

Am 04.03.2016 um 19:23 schrieb Douglas Anderson :

> From testing and trying to make sense of the documentation, it appears
> that a 10 ms delay is needed after resetting the core to make sure that
> everything is stable and consistent.  Let's add it.
> 
> In my testing (on rk3288) this allows us to revert commit
> 192cb07f7928 ("usb: dwc2: Fix probe problem on bcm2835").  Though I
> could never reproduce the problems on my board, this might also allow us
> to revert commit bd84f4ae9986 ("usb: dwc2: Add extra delay when forcing
> dr_mode").
> 
> Signed-off-by: Douglas Anderson 

Tested-by: Michael Niewoehner 

> ---
> drivers/usb/dwc2/core.c | 20 
> 1 file changed, 20 insertions(+)
> 
> diff --git a/drivers/usb/dwc2/core.c b/drivers/usb/dwc2/core.c
> index 5e5a0f135b5a..8710b2d3e770 100644
> --- a/drivers/usb/dwc2/core.c
> +++ b/drivers/usb/dwc2/core.c
> @@ -277,6 +277,26 @@ int dwc2_core_reset(struct dwc2_hsotg *hsotg)
>   }
>   } while (!(greset & GRSTCTL_AHBIDLE));
> 
> + /*
> +  * Sleep for 10-15 ms after the reset to let it finish.
> +  *
> +  * It's been confirmed on at least one version of the controller
> +  * that this is a requirement that this is a requirement in order for
> +  * everything to settle.  Specifically if you:
> +  * - change GNPTXFSIZ or HPTXFSIZ before the reset
> +  * - do the reset
> +  * - read GNPTXFSIZ or HPTXFSIZ in a loop
> +  * ...you'll find that it takes almost exactly 10 ms for the registers
> +  * to return to their reset defaults.
> +  *
> +  * Note that it's possible that this 10 ms is the time referred to
> +  * in "Host Initialization" where it says to "Wait at least 10 ms for
> +  * the reset process to complete".  In "Device Initialization" there
> +  * is also talk of a reset lasting 10 ms.  That may be the source of
> +  * this delay.
> +  */
> + usleep_range(1, 15000);
> +
>   return 0;
> }
> 
> -- 
> 2.7.0.rc3.207.g0ac5344
> 

I’m a bit confused since git log says bd84f4ae9986 has been merged in 
62718e304aa6 but looking at drivers/usb/dwc2/core.c it seems the patch has not 
been applied anyways ...
However, I tested you your two patches with „magically reverted“ bd84f4ae9986 
(msleep 50) on rk3188.
The sdcard keeps being detected and boots just fine.

Best regards
Michael
--
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: [RFT PATCH 2/2] Revert "usb: dwc2: Fix probe problem on bcm2835"

[Michael Niewoehner]

Am 04.03.2016 um 19:23 schrieb Douglas Anderson :

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

Tested-by: Michael Niewoehner 

> ---
> drivers/usb/dwc2/core.c | 6 ++
> 1 file changed, 6 insertions(+)
> 
> diff --git a/drivers/usb/dwc2/core.c b/drivers/usb/dwc2/core.c
> index 8710b2d3e770..7c4a6cf4c73a 100644
> --- a/drivers/usb/dwc2/core.c
> +++ b/drivers/usb/dwc2/core.c
> @@ -353,6 +353,12 @@ static bool dwc2_force_mode(struct dwc2_hsotg *hsotg, 
> bool host)
>   set = host ? GUSBCFG_FORCEHOSTMODE : GUSBCFG_FORCEDEVMODE;
>   clear = host ? GUSBCFG_FORCEDEVMODE : GUSBCFG_FORCEHOSTMODE;
> 
> + /*
> + * If the force mode bit is already set, don't set it.
> + */
> + if ((gusbcfg & set) && !(gusbcfg & clear))
> + return false;
> +
>   gusbcfg &= ~clear;
>   gusbcfg |= set;
>   dwc2_writel(gusbcfg, hsotg->regs + GUSBCFG);
> -- 
> 2.7.0.rc3.207.g0ac5344
> 

--
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: Possible double-free in the usbnet driver

[Oliver Neukum]

On Sat, 2016-03-05 at 01:26 +0300, Andrey Konovalov wrote:
> and when I run the vm and connect the device I get:
> 
> [   23.672662] cdc_ncm 1-1:1.6: bind() failure
> [   23.673447] usbnet_probe(): freeing netdev: 88006ab48000
> [   23.675822] usbnet_probe(): freeing netdev: 88006ab48000
> 
> So this seems to be a double-free (or at least a double free_netdev()
> call), but the object gets freed twice from usbnet_probe() and not
> from usbnet_disconnect(), so you're right that the latter doesn't get
> called. I'm not sure how usbnet_probe() ends up being called twice.

Do you have lsusb?

Regards
Oliver


--
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: Possible double-free in the usbnet driver

[Linus Torvalds]

On Fri, Mar 4, 2016 at 2:26 PM, Andrey Konovalov  wrote:
>
> and when I run the vm and connect the device I get:
>
> [   23.672662] cdc_ncm 1-1:1.6: bind() failure
> [   23.673447] usbnet_probe(): freeing netdev: 88006ab48000
> [   23.675822] usbnet_probe(): freeing netdev: 88006ab48000
>
> So this seems to be a double-free (or at least a double free_netdev()
> call), but the object gets freed twice from usbnet_probe() and not
> from usbnet_disconnect(), so you're right that the latter doesn't get
> called. I'm not sure how usbnet_probe() ends up being called twice.

I still don't think it's a double free. I think the probe thing is
called twice, and that's why to different allocations get free'd twice
(and the reason it's the same pointer is that the same allocation got
reused)

But I don't know that driver, really.

>> Which particular usbnet bind routine is this? There are multiple
>> sub-drivers for usbnet that all do different things.
>
> cdc_ncm_bind()

Ok, so that matches my theory.

Does this attached stupid patch make the warning go away? Because from
what I can tell, usbnet_link_change() really will start using that
"dev" that simply isn't valid - and will be free'd - if the bind
fails.

So you have usbnet_defer_kevent() getting triggered, which in turn
ends up using "usbnet->kevent"

But somebody like Oliver is really the right person to check this. For
example, it's entirely possible that we should just instead do

cancel_work_sync(>kevent);

before the "free_netdev(net)" in the "out1" label.

And there might be other things that bind() can have touched than the
kevent workqueue.

   Linus
 drivers/net/usb/cdc_ncm.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c
index dc0212c3cc28..5878b54cc563 100644
--- a/drivers/net/usb/cdc_ncm.c
+++ b/drivers/net/usb/cdc_ncm.c
@@ -995,6 +995,8 @@ static int cdc_ncm_bind(struct usbnet *dev, struct 
usb_interface *intf)
 * placed NDP.
 */
ret = cdc_ncm_bind_common(dev, intf, CDC_NCM_DATA_ALTSETTING_NCM, 0);
+   if (ret < 0)
+   return ret;
 
/*
 * We should get an event when network connection is "connected" or
@@ -1003,7 +1005,7 @@ static int cdc_ncm_bind(struct usbnet *dev, struct 
usb_interface *intf)
 * start IPv6 negotiation and more.
 */
usbnet_link_change(dev, 0, 0);
-   return ret;
+   return 0;
 }
 
 static void cdc_ncm_align_tail(struct sk_buff *skb, size_t modulus, size_t 
remainder, size_t max)

Re: Possible double-free in the usbnet driver

[Andrey Konovalov]

On Sat, Mar 5, 2016 at 12:26 AM, Linus Torvalds
 wrote:
> [ Moving this to proper lists ]
>
> On Thu, Mar 3, 2016 at 4:19 PM, Andrey Konovalov  wrote:
>>
>> I found another double-free, this time in the usbnet driver.
>
> Hmm. It doesn't look like a double free to me, at least from the logs
> you attached.
>
>> Whenever the `bind()` function fails (drivers/net/usb/usbnet.c:1676) when
>> called from `usbnet_probe()` (and it can fail due to a invalid usb 
>> descriptor),
>> `free_netdev()` is called for the `net` device 
>> (drivers/net/usb/usbnet.c:1772).
>> Then, `free_netdev(net)` is called again in `usbnet_disconnect()`
>> (drivers/net/usb/usbnet.c:1570) causing a double-free.
>
> The KASAN report says that it's a use-after-free in the kworker
> thread: the net device got free'd at the end of usbnet_probe(), but
> some work-struct was apparently active at the time.
>
> There might be a double free later that isn't in your report, though.
> Do you have the data for that?

I uploaded full kernel log here:
https://gist.github.com/xairy/6a244871959187209fdb

My initial idea was that an object is freed by free_netdev(), then
allocated somewhere during execution of kworker-related code and then
this object gets freed by free_netdev() again and that's why we have
such use-after-free reports. That didn't explain the deallocation
stack trace in the report, but I thought this was due to a
racy-use-after-free.

I just added the following debug output:

diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c
index 0b0ba7e..f7e1415 100644
--- a/drivers/net/usb/usbnet.c
+++ b/drivers/net/usb/usbnet.c
@@ -1567,6 +1567,7 @@ void usbnet_disconnect (struct usb_interface *intf)
usb_free_urb(dev->interrupt);
kfree(dev->padding_pkt);

+   pr_err("usbnet_disconnect(): freeing netdev: %p\n", net);
free_netdev(net);
 }
 EXPORT_SYMBOL_GPL(usbnet_disconnect);
@@ -1769,6 +1770,7 @@ out3:
if (info->unbind)
info->unbind (dev, udev);
 out1:
+   pr_err("usbnet_probe(): freeing netdev: %p\n", net);
free_netdev(net);
 out:
return status;

and when I run the vm and connect the device I get:

[   23.672662] cdc_ncm 1-1:1.6: bind() failure
[   23.673447] usbnet_probe(): freeing netdev: 88006ab48000
[   23.675822] usbnet_probe(): freeing netdev: 88006ab48000

So this seems to be a double-free (or at least a double free_netdev()
call), but the object gets freed twice from usbnet_probe() and not
from usbnet_disconnect(), so you're right that the latter doesn't get
called. I'm not sure how usbnet_probe() ends up being called twice.

>
> But I didn't think we even called the disconnect() function if the
> "bind()" failed, so I don't think that one should free it. Greg?
>
> So it *sounds* to me like the usbnet "bind()" routine ended up
> returning an error, but doing so *after* it had already activated the
> structure somehow.
>
> Which particular usbnet bind routine is this? There are multiple
> sub-drivers for usbnet that all do different things.

cdc_ncm_bind()

>
> For example, it *looks* like the cdc_ncm_bind() will have done a
> usbnet_link_change() even if the bind fails. So now we've done a
> usbnet_defer_kevent() even though we're failing, and then that sets
> the ball rolling to later touch the netdev that we're freeing due to
> the failure.
>
> But I may be *entirely* misreading this thing.
>
> Anyway, I'm cc'ing the usbnet people who actually know the code (and netdev).
>
> The proper fix may be to just cancel any work that might have been set
> up before freeing. Or maybe that netdev *does* get free'd later some
> other way properly. Let's see what the experts on the usbnet driver
> say.
>
>   Linus
--
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: Spurious Mass Storage Device Resets

[Alan Stern]

On Fri, 4 Mar 2016, Rian Hunter wrote:

> Thanks for the great tip. I used tcpdump on the bus of my device and
> waited for a couple days for the effect to happen again.
> 
> I found that whenever I would get the "usb 2-3: reset SuperSpeed USB
> device number 2 using xhci_hcd" what was happening at the protocol
> level was:
> 
> HOST: DO READ
> DEVICE: CONFIRMED
> HOST: SEND ME DATA
> DEVICE: 
> HOST: SEND ME STATUS
> DEVICE: SCSI CHECK CONDITION
> 
> After the "Check Condition" the stack would initial a USB reset.

More details would help, such as the actual usbmon output for one of 
those failed commands (plus the following data).

> Now that was all well and fine, no interruptions in service. What
> eventually caused the entire device to disconnect was this sequence:
> 
> HOST: DO READ
> DEVICE: CONFIRMED
> HOST: SEND ME DATA
> DEVICE: 
> HOST: SEND ME STATUS
> (300 seconds pass...)
> DEVICE: USB URB ECONNRESET
> 
> I believe what is happening here is that the firmware of the bridge
> device timed out waiting for the SCSI status coming from the actual
> HDD (after enough "check condition" return codes the device decided to
> die). The bridge firmware sends a final ECONNRESET then it decides to
> disconnect completely.

No, that doesn't sound right.  SCSI commands typically have a 30-second 
timeout, so there should have been a reset after 30 seconds, not a 
disconnect after 300.

> None of this surprises me. The theory that the drives are bad seems
> to have more data behind it.
> 
> From "https://en.wikipedia.org/wiki/SCSI_check_condition; it says that
> when a "check condition" status is returned, the device goes into
> a special "contigent allegiance condition" state and the host *should*
> retrieve more information using a "Request Sense" command. The Linux
> stack does not seem to be doing this.

Not true.  It does do this, very faithfully.

>  While it probably couldn't save
> the device, it would be extremely valuable information to see in the
> logs, especially when the HDDs are operating normally otherwise. Probably
> would be worth it to add a special case in usb_stor_invoke_transport()
> to handle the "check condition" error more gracefully.

That code is already in there.

> At this point I'd really like to see what information is contained the
> "Request sense" response. Going to hunt for a user-space solution to pull
> that for now before I order new drives :)

It should all be in your usbmon output.  If you would post that here 
(just the relevant portions, not the whole several-day-long trace), I 
could tell you more.

Alan Stern

--
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 v10 1/9] dt-bindings: phy: Add NVIDIA Tegra XUSB pad controller binding

[Andrew Bresticker]

> +Required properties:
> +
> +- compatible: Must be:
> +  - Tegra124: "nvidia,tegra124-xusb-padctl"
> +  - Tegra132: "nvidia,tegra132-xusb-padctl", "nvidia,tegra124-xusb-padctl"
> +- reg: Physical base address and length of the controller's registers.
> +- resets: Must contain an entry for each entry in reset-names.
> +- reset-names: Must include the following entries:
> +  - "padctl"

Also... there's a padctl interrupt that'll be necessary for LP0
suspend/resume and runtime power-gating of the xHC.  We should
probably include that here too.
--
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: Unable to enumerate USB Device, error -110 Kernel 3.19-0.49-lowlatency netboot

[Alan Stern]

On Fri, 4 Mar 2016, Devon Ash wrote:

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

Is CONFIG_USB_MON set?  If it is set to M, have you loaded the usbmon 
module?

> And also a
> dmesg log with USB debugging enabled?
> 
> dmesg shows nothing. I htink I'm missing something - to enable USB
> debugging all that needs to be done is mount the debugfs right?

No, that's not enough.  I don't remember how 3.19 does it, but with
more modern kernels you have to enable dynamic debugging by doing:

echo 'module usbcore =p' >/sys/kernel/debug/dynamic_debug/control

That's assuming CONFIG_DYNAMIC_DEBUG is set, which it should be in a 
typical distribution kernel.

> Regarding Kernel 4.2.0-30-lowlatency,
>
> system-udevd is now giving me the outputs on boot:
>
> seq 1106 '/devices/pci:00/:00:1a.0/usb5 killed (same for usb6)
> reason being ; a timeout
>
> Then I start to get
>
> usb 5-1: device not accepting address 5, error -110
> usb usb5-port1; unable to enumerate USB device
>
> and the same for usb6.
>
> There is also:
>
> system-udevd: worker terminated by signal 9, and then the system waits
> for 2-5 minutes, finishing with a kernel hang and a stack trace "not
> tainted, blocked for more than 120 seconds"

Can you post the actual dmesg log?

> here is the output of:
>
> sudo mount -t usbfs none /proc/bus/usb
>
> mount: mounting none on /proc/bus/usb failed: no such file or directory

There no longer is any such thing as a usbfs filesystem.  Instead 
there are USB device nodes under /dev/bus/usb.

> cat /proc/bus/usb/devices: no such file or directory
>
> sudo mount -t debugfs none /sys/kernel/debug
>
> mount: muonting none on /sys/kernel/debug failed: Device or resource busy

Probably because it's already mounted there.

> As well, all usbmon outputs are returning me nothing when plugging
> in/out the broken USB ports that are in question

What is the full path of the files you are watching for usbmon?  They 
should be things like /sys/kernel/debug/usb/usbmon/5u -- which of 
course won't exist unless debugfs is properly mounted and usbmon is 
properly loaded.

Alan Stern

--
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 v10 3/9] dt-bindings: phy: tegra-xusb-padctl: Add Tegra210 support

[Andrew Bresticker]

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

> +PCIe pad:
> +-
> +
> +Required properties:
> +- clocks: Must contain an entry for each entry in clock-names.
> +- clock-names: Must contain the following entries:
> +  - "pll": phandle and specifier referring to the PLLE
> +- resets: Must contain an entry for each entry in reset-names.
> +- reset-names: Must contain the following entries:
> +  - "phy": reset for the PCIe UPHY block
> +
> +SATA pad:
> +-
> +
> +Required properties:
> +- resets: Must contain an entry for each entry in reset-names.
> +- reset-names: Must contain the following entries:
> +  - "phy": reset for the SATA UPHY block

Doesn't the SATA pad require PLLE as well?  You've included it in the
example DT fragment, but it's absent here.
--
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 v10 1/9] dt-bindings: phy: Add NVIDIA Tegra XUSB pad controller binding

[Andrew Bresticker]

Hi Thierry,

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

Thanks, this binding looks much better, IMO.  A couple small comments below...

> +Port nodes:
> +===
> +
> +A required child node named "ports" contains a list of all the ports exposed
> +by the XUSB pad controller. Per-port configuration is only required for USB.
> +
> +USB2 ports:
> +---
> +
> +Required properties:
> +- status: Defines the operation status of the port. Valid values are:
> +  - "disabled": the port is disabled
> +  - "okay": the port is enabled
> +- mode: A string that determines the mode in which to run the port. Valid
> +  values are:
> +  - "host": for USB host mode
> +  - "device": for USB device mode
> +  - "otg": for USB OTG mode
> +
> +Optional properties:
> +- nvidia,internal: A boolean property whose presence determines that a port
> +  is internal. In the absence of this property the port is considered to be
> +  external.
> +- vbus-supply: phandle to a regulator supplying the VBUS voltage.

Both Blaze and Smaug require an offset to be applied to the fused
HS_CURR_LEVEL value, so I think we need another property here for
that.

> +ULPI ports:
> +---
> +
> +Optional properties:
> +- status: Defines the operation status of the port. Valid values are:
> +  - "disabled": the port is disabled
> +  - "okay": the port is enabled
> +- nvidia,internal: A boolean property whose presence determines that a port
> +  is internal. In the absence of this property the port is considered to be
> +  external.
> +- vbus-supply: phandle to a regulator supplying the VBUS voltage.
> +
> +HSIC ports:
> +---
> +
> +Required properties:
> +- status: Defines the operation status of the port. Valid values are:
> +  - "disabled": the port is disabled
> +  - "okay": the port is enabled
> +
> +Optional properties:
> +- vbus-supply: phandle to a regulator supplying the VBUS voltage.

I believe this pin is named VDDIO_HSIC?

Also there are several other HSIC pad parameters (STROBE_TRIM,
DATA_TRIM, etc.) which probably should be supplied via DT.
--
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: Possible double-free in the usbnet driver

[Linus Torvalds]

[ Moving this to proper lists ]

On Thu, Mar 3, 2016 at 4:19 PM, Andrey Konovalov  wrote:
>
> I found another double-free, this time in the usbnet driver.

Hmm. It doesn't look like a double free to me, at least from the logs
you attached.

> Whenever the `bind()` function fails (drivers/net/usb/usbnet.c:1676) when
> called from `usbnet_probe()` (and it can fail due to a invalid usb 
> descriptor),
> `free_netdev()` is called for the `net` device 
> (drivers/net/usb/usbnet.c:1772).
> Then, `free_netdev(net)` is called again in `usbnet_disconnect()`
> (drivers/net/usb/usbnet.c:1570) causing a double-free.

The KASAN report says that it's a use-after-free in the kworker
thread: the net device got free'd at the end of usbnet_probe(), but
some work-struct was apparently active at the time.

There might be a double free later that isn't in your report, though.
Do you have the data for that?

But I didn't think we even called the disconnect() function if the
"bind()" failed, so I don't think that one should free it. Greg?

So it *sounds* to me like the usbnet "bind()" routine ended up
returning an error, but doing so *after* it had already activated the
structure somehow.

Which particular usbnet bind routine is this? There are multiple
sub-drivers for usbnet that all do different things.

For example, it *looks* like the cdc_ncm_bind() will have done a
usbnet_link_change() even if the bind fails. So now we've done a
usbnet_defer_kevent() even though we're failing, and then that sets
the ball rolling to later touch the netdev that we're freeing due to
the failure.

But I may be *entirely* misreading this thing.

Anyway, I'm cc'ing the usbnet people who actually know the code (and netdev).

The proper fix may be to just cancel any work that might have been set
up before freeing. Or maybe that netdev *does* get free'd later some
other way properly. Let's see what the experts on the usbnet driver
say.

  Linus
--
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 v7 1/5] leds: core: add generic support for RGB LED's

[Heiner Kallweit]

Add generic support for RGB LED's.

Basic idea is to use enum led_brightness also for the hue and saturation
color components.This allows to implement the color extension w/o
changes to struct led_classdev.

Select LEDS_RGB to enable building drivers using the RGB extension.

Flag LED_SET_HUE_SAT allows to specify that hue / saturation
should be overridden even if the provided values are zero.

Some examples for writing values to /sys/class/leds//brightness:
(now also hex notation can be used)

255 -> set full brightness and keep existing color if set
0 -> switch LED off but keep existing color so that it can be restored
 if the LED is switched on again later
0x100 -> switch LED off and set also hue and saturation to 0
0x00 -> set full brightness, full saturation and set hue to 0 (red)

Signed-off-by: Heiner Kallweit 
---
v2:
- move extension-specific code into a separate source file and
  introduce config symbol LEDS_HSV for it
- create separate patch for the extension to sysfs
- use variable name led_cdev as in the rest if the core
- rename to_hsv to led_validate_brightness
- rename LED_BRIGHTNESS_SET_COLOR to LED_SET_HSV
- introduce helper is_off for checking whether V part
  of a HSV value is zero
v3:
- change Kconfig to use depend instead of select, add help message,
  and change config symbol to LEDS_COLOR
- change LED core object file name in Makefile
- rename flag LED_SET_HSV to LED_SET_COLOR
- rename is_off to led_is_off
- rename led_validate-brightness to led_confine_brightness
- rename variable in led_confine_brightness
- add dummy enum led_brightness value to enforce 32bit enum
- rename led-hsv-core.c to led-color-core.c
- move check of provided brightness value to led_confine_brightness
v4:
- change config symbol name to LEDS_RGB
- change name of new file to led-rgb-core.c
- factor out part of led_confine_brightness
- change led_is_off to __is_set_brightness
- in led_set_software_blink pass led_cdev->max_brightness instead of LED_FULL
- rename LED_SET_COLOR to LED_SET_HUE_SAT
v5:
- change "RGB Color LED" to "RGB LED" in Kconfig
- move definition of LED_HUE_SAT_MASK to drivers/leds/leds.h
- rename LED_DEV_CAP_HSV to LED_DEV_CAP_RGB
v6:
- no change
v7:
- removed "Color" from RGB Color LED in commit message and title
- don't include linux/kernel.h in led-rgb-core.c
- keep definition of LED_DEV_CAP_[] flags together
---
 drivers/leds/Kconfig| 11 +++
 drivers/leds/Makefile   |  4 +++-
 drivers/leds/led-class.c|  2 +-
 drivers/leds/led-core.c | 16 +---
 drivers/leds/led-rgb-core.c | 39 +++
 drivers/leds/leds.h | 18 ++
 include/linux/leds.h| 11 ++-
 7 files changed, 91 insertions(+), 10 deletions(-)
 create mode 100644 drivers/leds/led-rgb-core.c

diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index 7f940c2..5b1c852 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -13,6 +13,13 @@ menuconfig NEW_LEDS
 
 if NEW_LEDS
 
+config LEDS_RGB
+   bool "RGB LED Support"
+   help
+This option enables support for RGB Color LED devices.
+Sysfs attribute brightness is interpreted as a HSV color value.
+For details see Documentation/leds/leds-class.txt.
+
 config LEDS_CLASS
tristate "LED Class Support"
help
@@ -29,6 +36,10 @@ config LEDS_CLASS_FLASH
  for the flash related features of a LED device. It can be built
  as a module.
 
+if LEDS_RGB
+comment "RGB LED drivers"
+endif # LEDS_RGB
+
 comment "LED drivers"
 
 config LEDS_88PM860X
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index e9d5309..cc3676f 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -1,6 +1,8 @@
 
 # LED Core
-obj-$(CONFIG_NEW_LEDS) += led-core.o
+obj-$(CONFIG_NEW_LEDS) += led-core-objs.o
+led-core-objs-y:= led-core.o
+led-core-objs-$(CONFIG_LEDS_RGB)   += led-rgb-core.o
 obj-$(CONFIG_LEDS_CLASS)   += led-class.o
 obj-$(CONFIG_LEDS_CLASS_FLASH) += led-class-flash.o
 obj-$(CONFIG_LEDS_TRIGGERS)+= led-triggers.o
diff --git a/drivers/leds/led-class.c b/drivers/leds/led-class.c
index aa84e5b..007a5b3 100644
--- a/drivers/leds/led-class.c
+++ b/drivers/leds/led-class.c
@@ -53,7 +53,7 @@ static ssize_t brightness_store(struct device *dev,
if (ret)
goto unlock;
 
-   if (state == LED_OFF)
+   if (!__is_brightness_set(state))
led_trigger_remove(led_cdev);
led_set_brightness(led_cdev, state);
 
diff --git a/drivers/leds/led-core.c b/drivers/leds/led-core.c
index 3495d5d..e75b0c8 100644
--- a/drivers/leds/led-core.c
+++ b/drivers/leds/led-core.c
@@ -62,7 +62,7 @@ static void led_timer_function(unsigned long data)
}
 
brightness = led_get_brightness(led_cdev);
-   if (!brightness) {
+   if 

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

[Heiner Kallweit]

Am 04.03.2016 um 10:05 schrieb Jacek Anaszewski:
> On 03/01/2016 10:36 PM, Heiner Kallweit wrote:
>> Export a function to convert HSV color values to RGB.
>> It's intended to be called by drivers for RGB LEDs.
>>
>> Signed-off-by: Heiner Kallweit 
>> ---
>> v2:
>> - move hsv -> rgb conversion to separate file
>> - remove flag LED_DEV_CAP_RGB
>> v3:
>> - call led_hsv_to_rgb only if LED_DEV_CAP_HSV is set
>>This is needed in cases when we have monochrome and color LEDs
>>as well in a system.
>> v4:
>> - Export led_hsv_to_rgb and let the device driver call it instead
>>of doing the conversion in the core
>> v5:
>> - don't ignore led_cdev->brightness_get silently if LED_DEV_CAP_RGB
>>is set but warn
>> ---
>>   drivers/leds/led-class.c|  7 +++
>>   drivers/leds/led-rgb-core.c | 36 
>>   include/linux/leds.h|  8 
>>   3 files changed, 51 insertions(+)
>>
>> diff --git a/drivers/leds/led-class.c b/drivers/leds/led-class.c
>> index 8a3748a..a4b144e 100644
>> --- a/drivers/leds/led-class.c
>> +++ b/drivers/leds/led-class.c
>> @@ -193,6 +193,13 @@ int led_classdev_register(struct device *parent, struct 
>> led_classdev *led_cdev)
>>   char name[64];
>>   int ret;
>>
>> +/*
>> + * for now reading back the color is not supported as multiple
>> + * HSV -> RGB -> HSV conversions may distort the color due to
>> + * rounding issues in the conversion algorithm
>> + */
> 
> Does the "for now" mean that you plan on supporting it in the future?
> 
It was meant as "until somebody has an idea how to implement the conversion
HSV -> RGB -> HSV in a way that always results in the original values".
I'll remove the "for now".

>> +WARN_ON(led_cdev->flags & LED_DEV_CAP_RGB && led_cdev->brightness_get);
>> +
> 
> Could you move this warning to the line 216?
> 
>>   ret = led_classdev_next_name(led_cdev->name, name, sizeof(name));
>>   if (ret < 0)
>>   return ret;
>> diff --git a/drivers/leds/led-rgb-core.c b/drivers/leds/led-rgb-core.c
>> index f6591f1..2b18d4c 100644
>> --- a/drivers/leds/led-rgb-core.c
>> +++ b/drivers/leds/led-rgb-core.c
>> @@ -38,3 +38,39 @@ enum led_brightness led_confine_brightness(struct 
>> led_classdev *led_cdev,
>>   return brightness |
>>  min(value & LED_BRIGHTNESS_MASK, led_cdev->max_brightness);
>>   }
>> +
>> +enum led_brightness led_hsv_to_rgb(enum led_brightness hsv)
>> +{
>> +int h = min_t(int, (hsv >> 16) & 0xff, 251);
>> +int s = (hsv >> 8) & 0xff;
>> +int v = hsv & 0xff;
>> +int f, p, q, t, r, g, b;
>> +
>> +if (!v)
>> +return 0;
>> +if (!s)
>> +return (v << 16) + (v << 8) + v;
>> +
>> +f = DIV_ROUND_CLOSEST((h % 42) * 255, 42);
>> +p = v - DIV_ROUND_CLOSEST(s * v, 255);
>> +q = v - DIV_ROUND_CLOSEST(f * s * v, 255 * 255);
>> +t = v - DIV_ROUND_CLOSEST((255 - f) * s * v, 255 * 255);
>> +
>> +switch (h / 42) {
>> +case 0:
>> +r = v; g = t; b = p; break;
>> +case 1:
>> +r = q; g = v; b = p; break;
>> +case 2:
>> +r = p; g = v; b = t; break;
>> +case 3:
>> +r = p; g = q; b = v; break;
>> +case 4:
>> +r = t; g = p; b = v; break;
>> +case 5:
>> +r = v; g = p; b = q; break;
>> +}
>> +
>> +return (r << 16) + (g << 8) + b;
>> +}
>> +EXPORT_SYMBOL_GPL(led_hsv_to_rgb);
>> diff --git a/include/linux/leds.h b/include/linux/leds.h
>> index bbf24bb..82b3477 100644
>> --- a/include/linux/leds.h
>> +++ b/include/linux/leds.h
>> @@ -226,6 +226,14 @@ static inline bool led_sysfs_is_disabled(struct 
>> led_classdev *led_cdev)
>>   return led_cdev->flags & LED_SYSFS_DISABLE;
>>   }
>>
>> +/**
>> + * led_hsv_to_rgb - convert a hsv color value to rgb color model
>> + * @hsv: the hsv value to convert
>> + *
>> + * Returns: the resulting rgb value
>> + */
>> +enum led_brightness led_hsv_to_rgb(enum led_brightness hsv);
>> +
>>   /*
>>* LED Triggers
>>*/
>>
> 
> 

--
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 v7 3/5] leds: core: add documentation for RGB extension

[Heiner Kallweit]

Document the RGB extension in Documentation/leds/leds-class.txt

Signed-off-by: Heiner Kallweit 
---
v2:
- introduced to patch series
v3:
- document extension in more detail
v4:
- Better explain why flag LED_SET_HUE_SAT is needed
v5:
- no changes
v6:
- no changes
v7:
- move Documentation/ABI change into separate patch
- change "colour" to "RGB" in more places
---
 Documentation/leds/leds-class.txt | 27 ++-
 1 file changed, 22 insertions(+), 5 deletions(-)

diff --git a/Documentation/leds/leds-class.txt 
b/Documentation/leds/leds-class.txt
index d406d98..003c098 100644
--- a/Documentation/leds/leds-class.txt
+++ b/Documentation/leds/leds-class.txt
@@ -8,6 +8,22 @@ LED is defined in max_brightness file. The brightness file 
will set the brightne
 of the LED (taking a value 0-max_brightness). Most LEDs don't have hardware
 brightness support so will just be turned on for non-zero brightness settings.
 
+If a driver uses the RGB extension of the LED core then the brightness
+file can be used to set hue / saturation / value. The brightness value is
+interpreted as: <000F>
+Usage of the least byte is identical to monochrome mode. Saturation can be
+0-255 and hue 0-251 (Colour circle is mapped to 0-252).
+If hue and saturation both are 0 the current colour is preserved and only
+the brightness is set. This ensures backwards compatibility with monochrome
+mode, e.g. for led_set_brightness() calls from triggers.
+However we might want to have the option to set all HSV components, even
+if hue and saturation both are 0 (e.g. via brightness sysfs attribute).
+Use case: Set color to white (hue = 0 and saturation = 0).
+Therefore the default behaviour can be overridden with flag F 
(LED_SET_HUE_SAT).
+If this flag is set then hue and saturation are not checked for being 0 and
+the color components are set unconditionally. Example:
+0x01ff sets the LED to white color with full brightness.
+
 The class also introduces the optional concept of an LED trigger. A trigger
 is a kernel based source of led events. Triggers can either be simple or
 complex. A simple trigger isn't configurable and is designed to slot into
@@ -45,11 +61,12 @@ Is currently of the form:
 
 "devicename:colour:function"
 
-There have been calls for LED properties such as colour to be exported as
-individual led class attributes. As a solution which doesn't incur as much
-overhead, I suggest these become part of the device name. The naming scheme
-above leaves scope for further attributes should they be needed. If sections
-of the name don't apply, just leave that section blank.
+If the RGB extension is used hsv / rgb can be used instead of a specific
+colour.  There have been calls for LED properties such as colour to be
+exported as individual led class attributes. As a solution which doesn't
+incur as much overhead, I suggest these become part of the device name.
+The naming scheme above leaves scope for further attributes should they be
+needed. If sections of the name don't apply, just leave that section blank.
 
 
 Brightness setting API
-- 
2.7.1


--
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 v7 2/5] leds: core: add color LED sysfs extension

[Heiner Kallweit]

Extend brightness sysfs property handling to deal with monochrome
and color mode as well.

Signed-off-by: Heiner Kallweit 
---
v2:
- split from patch 1
v3:
- moved one change (led_is_off) to patch 1
v4:
- changed printf format string to %#.6x
v5:
- no changes
v6:
- no changes
v7:
- no changes
---
 drivers/leds/led-class.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/leds/led-class.c b/drivers/leds/led-class.c
index 007a5b3..8a3748a 100644
--- a/drivers/leds/led-class.c
+++ b/drivers/leds/led-class.c
@@ -32,7 +32,10 @@ static ssize_t brightness_show(struct device *dev,
/* no lock needed for this */
led_update_brightness(led_cdev);
 
-   return sprintf(buf, "%u\n", led_cdev->brightness);
+   if (led_cdev->brightness > LED_FULL)
+   return sprintf(buf, "%#.6x\n", led_cdev->brightness);
+   else
+   return sprintf(buf, "%u\n", led_cdev->brightness);
 }
 
 static ssize_t brightness_store(struct device *dev,
@@ -49,7 +52,7 @@ static ssize_t brightness_store(struct device *dev,
goto unlock;
}
 
-   ret = kstrtoul(buf, 10, );
+   ret = kstrtoul(buf, 0, );
if (ret)
goto unlock;
 
-- 
2.7.1


--
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 v7 4/5] leds: core: document ABI change for RGB extension

[Heiner Kallweit]

Document the ABI change in Documentation/ABI/testing/sysfs-class-led.

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

diff --git a/Documentation/ABI/testing/sysfs-class-led 
b/Documentation/ABI/testing/sysfs-class-led
index 3646ec8..20357d5 100644
--- a/Documentation/ABI/testing/sysfs-class-led
+++ b/Documentation/ABI/testing/sysfs-class-led
@@ -7,6 +7,17 @@ Description:
have hardware brightness support so will just be turned on for
non-zero brightness settings. The value is between 0 and
/sys/class/leds//max_brightness.
+   If a driver uses the RGB LED feature then this attribute is
+   interpreted as a HSV color model value:
+   <000F>
+   Usage of the least byte is identical to monochrome mode.
+   Saturation can be 0-255 and hue 0-251 (Colour circle is mapped
+   to 0-252). If hue and saturation both are 0 the current colour
+   is preserved and only the brightness is set. This ensures
+   backwards compatibility with monochrome mode, e.g. for
+   led_set_brightness() calls from triggers.
+   Flag F enables setting hue and saturation even if both are 0.
+   For details and examples see Documentation/leds/leds-class.txt
 
 What:  /sys/class/leds//max_brightness
 Date:  March 2006
-- 
2.7.1


--
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 v7 5/5] leds: core: add support for RGB LED's

[Heiner Kallweit]

Export a function to convert HSV color values to RGB.
It's intended to be called by drivers for RGB LEDs.

Signed-off-by: Heiner Kallweit 
---
v2:
- move hsv -> rgb conversion to separate file
- remove flag LED_DEV_CAP_RGB
v3:
- call led_hsv_to_rgb only if LED_DEV_CAP_HSV is set
  This is needed in cases when we have monochrome and color LEDs
  as well in a system.
v4:
- Export led_hsv_to_rgb and let the device driver call it instead
  of doing the conversion in the core
v5:
- don't ignore led_cdev->brightness_get silently if LED_DEV_CAP_RGB
  is set but warn
v6:
- no changes
v7:
- remove "for now" in WARN_ON comment
- move position of WARN_ON
---
 drivers/leds/led-class.c|  6 ++
 drivers/leds/led-rgb-core.c | 36 
 include/linux/leds.h|  8 
 3 files changed, 50 insertions(+)

diff --git a/drivers/leds/led-class.c b/drivers/leds/led-class.c
index 8a3748a..adcd8f6 100644
--- a/drivers/leds/led-class.c
+++ b/drivers/leds/led-class.c
@@ -205,6 +205,12 @@ int led_classdev_register(struct device *parent, struct 
led_classdev *led_cdev)
if (ret)
dev_warn(parent, "Led %s renamed to %s due to name collision",
led_cdev->name, dev_name(led_cdev->dev));
+   /*
+* Reading back the color is not supported as multiple
+* HSV -> RGB -> HSV conversions may distort the color due to
+* rounding issues in the conversion algorithm
+*/
+   WARN_ON(led_cdev->flags & LED_DEV_CAP_RGB && led_cdev->brightness_get);
 
 #ifdef CONFIG_LEDS_TRIGGERS
init_rwsem(_cdev->trigger_lock);
diff --git a/drivers/leds/led-rgb-core.c b/drivers/leds/led-rgb-core.c
index cbd8b35..cdb7ba6 100644
--- a/drivers/leds/led-rgb-core.c
+++ b/drivers/leds/led-rgb-core.c
@@ -37,3 +37,39 @@ enum led_brightness led_confine_brightness(struct 
led_classdev *led_cdev,
return brightness |
   min(value & LED_BRIGHTNESS_MASK, led_cdev->max_brightness);
 }
+
+enum led_brightness led_hsv_to_rgb(enum led_brightness hsv)
+{
+   int h = min_t(int, (hsv >> 16) & 0xff, 251);
+   int s = (hsv >> 8) & 0xff;
+   int v = hsv & 0xff;
+   int f, p, q, t, r, g, b;
+
+   if (!v)
+   return 0;
+   if (!s)
+   return (v << 16) + (v << 8) + v;
+
+   f = DIV_ROUND_CLOSEST((h % 42) * 255, 42);
+   p = v - DIV_ROUND_CLOSEST(s * v, 255);
+   q = v - DIV_ROUND_CLOSEST(f * s * v, 255 * 255);
+   t = v - DIV_ROUND_CLOSEST((255 - f) * s * v, 255 * 255);
+
+   switch (h / 42) {
+   case 0:
+   r = v; g = t; b = p; break;
+   case 1:
+   r = q; g = v; b = p; break;
+   case 2:
+   r = p; g = v; b = t; break;
+   case 3:
+   r = p; g = q; b = v; break;
+   case 4:
+   r = t; g = p; b = v; break;
+   case 5:
+   r = v; g = p; b = q; break;
+   }
+
+   return (r << 16) + (g << 8) + b;
+}
+EXPORT_SYMBOL_GPL(led_hsv_to_rgb);
diff --git a/include/linux/leds.h b/include/linux/leds.h
index 58e8299..58e22e6 100644
--- a/include/linux/leds.h
+++ b/include/linux/leds.h
@@ -226,6 +226,14 @@ static inline bool led_sysfs_is_disabled(struct 
led_classdev *led_cdev)
return led_cdev->flags & LED_SYSFS_DISABLE;
 }
 
+/**
+ * led_hsv_to_rgb - convert a hsv color value to rgb color model
+ * @hsv: the hsv value to convert
+ *
+ * Returns: the resulting rgb value
+ */
+enum led_brightness led_hsv_to_rgb(enum led_brightness hsv);
+
 /*
  * LED Triggers
  */
-- 
2.7.1


--
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: Unable to enumerate USB Device, error -110 Kernel 3.19-0.49-lowlatency netboot

[Peter Hurley]

On 03/04/2016 12:24 PM, Greg KH wrote:
> On Fri, Mar 04, 2016 at 02:53:59PM -0500, Devon Ash wrote:
>> Regarding Kernel 4.2.0-30-lowlatency,
> 
> What is "lowlatency"?

-lowlatency is Ubuntu's optional kernel config.

A stock Ubuntu kernel is CONFIG_PREEMPT_VOLUNTARY=y && CONFIG_HZ=250
The -lowlatency kernel is CONFIG_PREEMPT=y && CONFIG_HZ=1000

That is the only difference.

Regards,
Peter Hurley


--
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: Spurious Mass Storage Device Resets

[Rian Hunter]

On Tue, 1 Mar 2016, Alan Stern wrote:

On Mon, 29 Feb 2016, Rian Hunter wrote:


Hello,

I own a JBOD SATA<->USB 3.0 bridge. All information about this device
and my kernel version is below.

My trouble is that every so often this device will undergo a virtual
USB disconnect and then be reconnected. This will cause all drives to
disappear and reappear on the system. All previously mounted file
systems will have to be remounted.


Anyway, you can get more information about the resets and their causes
if you collect a usbmon trace.  See Documentation/usb/usbmon.txt for
instructions.



Thanks for the great tip. I used tcpdump on the bus of my device and
waited for a couple days for the effect to happen again.

I found that whenever I would get the "usb 2-3: reset SuperSpeed USB
device number 2 using xhci_hcd" what was happening at the protocol
level was:

HOST: DO READ
DEVICE: CONFIRMED
HOST: SEND ME DATA
DEVICE: 
HOST: SEND ME STATUS
DEVICE: SCSI CHECK CONDITION

After the "Check Condition" the stack would initial a USB reset.

Now that was all well and fine, no interruptions in service. What
eventually caused the entire device to disconnect was this sequence:

HOST: DO READ
DEVICE: CONFIRMED
HOST: SEND ME DATA
DEVICE: 
HOST: SEND ME STATUS
(300 seconds pass...)
DEVICE: USB URB ECONNRESET

I believe what is happening here is that the firmware of the bridge
device timed out waiting for the SCSI status coming from the actual
HDD (after enough "check condition" return codes the device decided to
die). The bridge firmware sends a final ECONNRESET then it decides to
disconnect completely.

None of this surprises me. The theory that the drives are bad seems
to have more data behind it.


From "https://en.wikipedia.org/wiki/SCSI_check_condition; it says that

when a "check condition" status is returned, the device goes into
a special "contigent allegiance condition" state and the host *should*
retrieve more information using a "Request Sense" command. The Linux
stack does not seem to be doing this. While it probably couldn't save
the device, it would be extremely valuable information to see in the
logs, especially when the HDDs are operating normally otherwise. Probably
would be worth it to add a special case in usb_stor_invoke_transport()
to handle the "check condition" error more gracefully.

At this point I'd really like to see what information is contained the
"Request sense" response. Going to hunt for a user-space solution to pull
that for now before I order new drives :)

Rian
--
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: Unable to enumerate USB Device, error -110 Kernel 3.19-0.49-lowlatency netboot

[Devon Ash]

My deepest apologies.. I ran those commands on another computer (I'm
ssh tunnelling)...

here is the output of:

sudo mount -t usbfs none /proc/bus/usb

mount: mounting none on /proc/bus/usb failed: no such file or directory

cat /proc/bus/usb/devices: no such file or directory

sudo mount -t debugfs none /sys/kernel/debug

mount: muonting none on /sys/kernel/debug failed: Device or resource busy

As well, all usbmon outputs are returning me nothing when plugging
in/out the broken USB ports that are in question



On Fri, Mar 4, 2016 at 2:53 PM, Devon Ash  wrote:
> Regarding Kernel 4.2.0-30-lowlatency,
>
> system-udevd is now giving me the outputs on boot:
>
> seq 1106 '/devices/pci:00/:00:1a.0/usb5 killed (same for usb6)
> reason being ; a timeout
>
> Then I start to get
>
> usb 5-1: device not accepting address 5, error -110
> usb usb5-port1; unable to enumerate USB device
>
> and the same for usb6.
>
> There is also:
>
> system-udevd: worker terminated by signal 9, and then the system waits
> for 2-5 minutes, finishing with a kernel hang and a stack trace "not
> tainted, blocked for more than 120 seconds"
>
>
>
> On Fri, Mar 4, 2016 at 2:34 PM, Devon Ash  wrote:
>> If they are completely unresponsive, why do you get the -110 errors?  I
>> would expect you wouldn't get anything at all.
>>
>> They become unresponsive after the -110 errors. Dmesg will show
>> nothing after those errors come up during boot.
>>
>> Failing that, can you at least provide a usbmon trace showing what
>> happens when you plug a device into one of the bad ports?
>>
>> usbmon trace:
>>
>> I'm unable to get anything from doing "cat 0u && cat 5u && cat 6u"
>> (which are all of the offending devices locations)
>>
>>
>> And also a
>> dmesg log with USB debugging enabled?
>>
>> dmesg shows nothing. I htink I'm missing something - to enable USB
>> debugging all that needs to be done is mount the debugfs right?
>>
>>
>> What type of motherboard or system is this?
>>
>> Mini ITX from ASRock.
>>
>> Can you try using a more up-to-date kernel, such as 4.4?
>>
>> I'll try, and get back to you.
>>
>> On Fri, Mar 4, 2016 at 1:59 PM, Alan Stern  wrote:
>>> On Fri, 4 Mar 2016, Devon Ash wrote:
>>>
 I'm unable to use 8 of the 10 USB devices I have on a motherboard. Two
 USB 3.0 ports work, and all of the devices, if plugged into a hub, can
 be recognized and used if plugged through those 2 ports. However, the
 other ports are completely unresponsive.
>>>
>>> If they are completely unresponsive, why do you get the -110 errors?  I
>>> would expect you wouldn't get anything at all.
>>>
 Thoughts/Ideas? The broken drivers are ehci-pci. xhci-hcd works on the
 usb 3.0 ports, but for 2 other usb 3.0 ports it does not work.

  The machine is being netbooted and running kernel 3.19-49-lowlatency
 (i've tried with generic as well). This same identical setup running
 off of a hard disk boot does not have this problem for any USB ports.
 Im lead to believe there may be a bug in the ehci-pci driver while
 using netboot.
>>>
>>> What type of motherboard or system is this?
>>>
>>> Can you try using a more up-to-date kernel, such as 4.4?
>>>
>>> Failing that, can you at least provide a usbmon trace showing what
>>> happens when you plug a device into one of the bad ports?  And also a
>>> dmesg log with USB debugging enabled?
>>>
>>> Alan Stern
>>>
>>
>>
>>
>> --
>>
>> Devon Ash
>> http://ca.linkedin.com/pub/devon-ash/48/478/981;
>> style="text-decoration:none;">> src="https://static.licdn.com/scds/common/u/img/webpromo/btn_in_20x15.png;
>> width="20" height="15" alt="View Devon Ash's LinkedIn profile"
>> style="vertical-align:middle" border="0">View Devon Ash's
>> profile
>
>
>
> --
>
> Devon Ash
> http://ca.linkedin.com/pub/devon-ash/48/478/981;
> style="text-decoration:none;"> src="https://static.licdn.com/scds/common/u/img/webpromo/btn_in_20x15.png;
> width="20" height="15" alt="View Devon Ash's LinkedIn profile"
> style="vertical-align:middle" border="0">View Devon Ash's
> profile



-- 

Devon Ash
http://ca.linkedin.com/pub/devon-ash/48/478/981;
style="text-decoration:none;">https://static.licdn.com/scds/common/u/img/webpromo/btn_in_20x15.png;
width="20" height="15" alt="View Devon Ash's LinkedIn profile"
style="vertical-align:middle" border="0">View Devon Ash's
profile
--
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: Unable to enumerate USB Device, error -110 Kernel 3.19-0.49-lowlatency netboot

[Greg KH]

On Fri, Mar 04, 2016 at 02:53:59PM -0500, Devon Ash wrote:
> Regarding Kernel 4.2.0-30-lowlatency,

What is "lowlatency"?  Try 4.4.4 please, 4.2 is now old and obsolete :(

And can you test this without any -rt patches, we have no idea how those
interact with the USB subsystem, sorry.

thanks,

greg k-h
--
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/5] usb: gadget: f_midi: cleanups and typos fixes

[Felipe Ferreri Tonello]

Hi Michal, 

On March 4, 2016 7:17:31 PM GMT+00:00, Michal Nazarewicz  
wrote:
>On Wed, Mar 02 2016, Felipe F. Tonello wrote:
>> Signed-off-by: Felipe F. Tonello 
>> ---
>>  drivers/usb/gadget/function/f_midi.c | 77
>+++-
>>  1 file changed, 40 insertions(+), 37 deletions(-)
>>
>> diff --git a/drivers/usb/gadget/function/f_midi.c
>b/drivers/usb/gadget/function/f_midi.c
>> index 8475e3dc82d4..9a9e6112e224 100644
>> --- a/drivers/usb/gadget/function/f_midi.c
>> +++ b/drivers/usb/gadget/function/f_midi.c
>> @@ -1,5 +1,5 @@
>>  /*
>> - * f_midi.c -- USB MIDI class function driver
>> + * f_midi.c -- USB-MIDI class function driver
>>   *
>>   * Copyright (C) 2006 Thumtronics Pty Ltd.
>>   * Developed for Thumtronics by Grey Innovation
>> @@ -16,7 +16,7 @@
>>   *   Copyright (C) 2006 Thumtronics Pty Ltd.
>>   *   Ben Williamson 
>>   *
>> - * Licensed under the GPL-2 or later.
>> + * Licensed under the GPLv2.
>
>Any particular reason to do that?

Because the kernel is v2 only and not later. 

>
>>   */
>>  
>>  #include 
>> @@ -41,8 +41,8 @@
>>  MODULE_AUTHOR("Ben Williamson");
>>  MODULE_LICENSE("GPL v2");
>>  
>> -static const char f_midi_shortname[] = "f_midi";
>> -static const char f_midi_longname[] = "MIDI Gadget";
>> +static const char f_midi_shortname[] =  "f_midi";
>> +static const char f_midi_longname[] =   "MIDI Gadget";
>>  
>>  /*
>>   * We can only handle 16 cables on one single endpoint, as cable
>numbers are
>> @@ -78,28 +78,31 @@ struct gmidi_in_port {
>>  };
>>  
>>  struct f_midi {
>> -struct usb_function func;
>> -struct usb_gadget   *gadget;
>> -struct usb_ep   *in_ep, *out_ep;
>> -struct snd_card *card;
>> -struct snd_rawmidi  *rmidi;
>> -u8  ms_id;
>> -
>> -struct snd_rawmidi_substream *out_substream[MAX_PORTS];
>> -
>> -unsigned long   out_triggered;
>> -struct tasklet_struct   tasklet;
>> +struct usb_function func;
>> +struct usb_gadget *gadget;
>> +struct usb_ep *in_ep, *out_ep;
>> +u8 ms_id;
>> +unsigned long out_triggered;
>>  unsigned int in_ports;
>>  unsigned int out_ports;
>> -int index;
>> -char *id;
>> -unsigned int buflen, qlen;
>> +unsigned int buflen;
>> +unsigned int qlen;
>> +unsigned int len;
>> +
>>  /* This fifo is used as a buffer ring for pre-allocated IN
>usb_requests */
>>  DECLARE_KFIFO_PTR(in_req_fifo, struct usb_request *);
>>  spinlock_t transmit_lock;
>> +
>> +/* ALSA stuff */
>> +struct snd_card *card;
>> +struct snd_rawmidi *rmidi;
>> +struct snd_rawmidi_substream *out_substream[MAX_PORTS];
>> +struct tasklet_struct tasklet;
>>  unsigned int in_last_port;
>> +int index;
>> +char *id;
>>  
>> -struct gmidi_in_portin_ports_array[/* in_ports */];
>> +struct gmidi_in_port in_ports_array[/* in_ports */];
>>  };
>>  
>>  static inline struct f_midi *func_to_midi(struct usb_function *f)
>> @@ -191,7 +194,7 @@ static struct usb_ms_endpoint_descriptor_16
>ms_in_desc = {
>>  
>>  /* string IDs are assigned dynamically */
>>  
>> -#define STRING_FUNC_IDX 0
>> +#define STRING_FUNC_IDX 0
>>  
>>  static struct usb_string midi_string_defs[] = {
>>  [STRING_FUNC_IDX].s = "MIDI function",
>> @@ -199,7 +202,7 @@ static struct usb_string midi_string_defs[] = {
>>  };
>>  
>>  static struct usb_gadget_strings midi_stringtab = {
>> -.language   = 0x0409,   /* en-us */
>> +.language   = 0x0409, /* en-us */
>>  .strings= midi_string_defs,
>>  };
>>  
>> @@ -409,7 +412,7 @@ static int f_midi_snd_free(struct snd_device
>*device)
>>  }
>>  
>>  /*
>> - * Converts MIDI commands to USB MIDI packets.
>> + * Converts MIDI commands to USB-MIDI packets.
>>   */
>>  static void f_midi_transmit_byte(struct usb_request *req,
>>   struct gmidi_in_port *port, uint8_t b)
>> @@ -956,15 +959,15 @@ static int f_midi_bind(struct usb_configuration
>*c, struct usb_function *f)
>>  in_emb->iJack   = 0;
>>  midi_function[i++] = (struct usb_descriptor_header *) in_emb;
>>  
>> -out_ext->bLength =  USB_DT_MIDI_OUT_SIZE(1);
>> -out_ext->bDescriptorType =  USB_DT_CS_INTERFACE;
>> -out_ext->bDescriptorSubtype =   USB_MS_MIDI_OUT_JACK;
>> -out_ext->bJackType =USB_MS_EXTERNAL;
>> -out_ext->bJackID =  jack++;
>> -out_ext->bNrInputPins = 1;
>> -out_ext->iJack =0;
>> -out_ext->pins[0].baSourceID =   in_emb->bJackID;
>> -out_ext->pins[0].baSourcePin =  1;
>> +out_ext->bLength= USB_DT_MIDI_OUT_SIZE(1);
>> +out_ext->bDescriptorType= USB_DT_CS_INTERFACE;
>> +

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

[Devon Ash]

Regarding Kernel 4.2.0-30-lowlatency,

system-udevd is now giving me the outputs on boot:

seq 1106 '/devices/pci:00/:00:1a.0/usb5 killed (same for usb6)
reason being ; a timeout

Then I start to get

usb 5-1: device not accepting address 5, error -110
usb usb5-port1; unable to enumerate USB device

and the same for usb6.

There is also:

system-udevd: worker terminated by signal 9, and then the system waits
for 2-5 minutes, finishing with a kernel hang and a stack trace "not
tainted, blocked for more than 120 seconds"



On Fri, Mar 4, 2016 at 2:34 PM, Devon Ash  wrote:
> If they are completely unresponsive, why do you get the -110 errors?  I
> would expect you wouldn't get anything at all.
>
> They become unresponsive after the -110 errors. Dmesg will show
> nothing after those errors come up during boot.
>
> Failing that, can you at least provide a usbmon trace showing what
> happens when you plug a device into one of the bad ports?
>
> usbmon trace:
>
> I'm unable to get anything from doing "cat 0u && cat 5u && cat 6u"
> (which are all of the offending devices locations)
>
>
> And also a
> dmesg log with USB debugging enabled?
>
> dmesg shows nothing. I htink I'm missing something - to enable USB
> debugging all that needs to be done is mount the debugfs right?
>
>
> What type of motherboard or system is this?
>
> Mini ITX from ASRock.
>
> Can you try using a more up-to-date kernel, such as 4.4?
>
> I'll try, and get back to you.
>
> On Fri, Mar 4, 2016 at 1:59 PM, Alan Stern  wrote:
>> On Fri, 4 Mar 2016, Devon Ash wrote:
>>
>>> I'm unable to use 8 of the 10 USB devices I have on a motherboard. Two
>>> USB 3.0 ports work, and all of the devices, if plugged into a hub, can
>>> be recognized and used if plugged through those 2 ports. However, the
>>> other ports are completely unresponsive.
>>
>> If they are completely unresponsive, why do you get the -110 errors?  I
>> would expect you wouldn't get anything at all.
>>
>>> Thoughts/Ideas? The broken drivers are ehci-pci. xhci-hcd works on the
>>> usb 3.0 ports, but for 2 other usb 3.0 ports it does not work.
>>>
>>>  The machine is being netbooted and running kernel 3.19-49-lowlatency
>>> (i've tried with generic as well). This same identical setup running
>>> off of a hard disk boot does not have this problem for any USB ports.
>>> Im lead to believe there may be a bug in the ehci-pci driver while
>>> using netboot.
>>
>> What type of motherboard or system is this?
>>
>> Can you try using a more up-to-date kernel, such as 4.4?
>>
>> Failing that, can you at least provide a usbmon trace showing what
>> happens when you plug a device into one of the bad ports?  And also a
>> dmesg log with USB debugging enabled?
>>
>> Alan Stern
>>
>
>
>
> --
>
> Devon Ash
> http://ca.linkedin.com/pub/devon-ash/48/478/981;
> style="text-decoration:none;"> src="https://static.licdn.com/scds/common/u/img/webpromo/btn_in_20x15.png;
> width="20" height="15" alt="View Devon Ash's LinkedIn profile"
> style="vertical-align:middle" border="0">View Devon Ash's
> profile



-- 

Devon Ash
http://ca.linkedin.com/pub/devon-ash/48/478/981;
style="text-decoration:none;">https://static.licdn.com/scds/common/u/img/webpromo/btn_in_20x15.png;
width="20" height="15" alt="View Devon Ash's LinkedIn profile"
style="vertical-align:middle" border="0">View Devon Ash's
profile
--
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: Unable to enumerate USB Device, error -110 Kernel 3.19-0.49-lowlatency netboot

[Devon Ash]

If they are completely unresponsive, why do you get the -110 errors?  I
would expect you wouldn't get anything at all.

They become unresponsive after the -110 errors. Dmesg will show
nothing after those errors come up during boot.

Failing that, can you at least provide a usbmon trace showing what
happens when you plug a device into one of the bad ports?

usbmon trace:

I'm unable to get anything from doing "cat 0u && cat 5u && cat 6u"
(which are all of the offending devices locations)


And also a
dmesg log with USB debugging enabled?

dmesg shows nothing. I htink I'm missing something - to enable USB
debugging all that needs to be done is mount the debugfs right?


What type of motherboard or system is this?

Mini ITX from ASRock.

Can you try using a more up-to-date kernel, such as 4.4?

I'll try, and get back to you.

On Fri, Mar 4, 2016 at 1:59 PM, Alan Stern  wrote:
> On Fri, 4 Mar 2016, Devon Ash wrote:
>
>> I'm unable to use 8 of the 10 USB devices I have on a motherboard. Two
>> USB 3.0 ports work, and all of the devices, if plugged into a hub, can
>> be recognized and used if plugged through those 2 ports. However, the
>> other ports are completely unresponsive.
>
> If they are completely unresponsive, why do you get the -110 errors?  I
> would expect you wouldn't get anything at all.
>
>> Thoughts/Ideas? The broken drivers are ehci-pci. xhci-hcd works on the
>> usb 3.0 ports, but for 2 other usb 3.0 ports it does not work.
>>
>>  The machine is being netbooted and running kernel 3.19-49-lowlatency
>> (i've tried with generic as well). This same identical setup running
>> off of a hard disk boot does not have this problem for any USB ports.
>> Im lead to believe there may be a bug in the ehci-pci driver while
>> using netboot.
>
> What type of motherboard or system is this?
>
> Can you try using a more up-to-date kernel, such as 4.4?
>
> Failing that, can you at least provide a usbmon trace showing what
> happens when you plug a device into one of the bad ports?  And also a
> dmesg log with USB debugging enabled?
>
> Alan Stern
>



-- 

Devon Ash
http://ca.linkedin.com/pub/devon-ash/48/478/981;
style="text-decoration:none;">https://static.licdn.com/scds/common/u/img/webpromo/btn_in_20x15.png;
width="20" height="15" alt="View Devon Ash's LinkedIn profile"
style="vertical-align:middle" border="0">View Devon Ash's
profile
--
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/5] usb: gadget: f_midi: cleanups and typos fixes

[Michal Nazarewicz]

On Wed, Mar 02 2016, Felipe F. Tonello wrote:
> Signed-off-by: Felipe F. Tonello 
> ---
>  drivers/usb/gadget/function/f_midi.c | 77 
> +++-
>  1 file changed, 40 insertions(+), 37 deletions(-)
>
> diff --git a/drivers/usb/gadget/function/f_midi.c 
> b/drivers/usb/gadget/function/f_midi.c
> index 8475e3dc82d4..9a9e6112e224 100644
> --- a/drivers/usb/gadget/function/f_midi.c
> +++ b/drivers/usb/gadget/function/f_midi.c
> @@ -1,5 +1,5 @@
>  /*
> - * f_midi.c -- USB MIDI class function driver
> + * f_midi.c -- USB-MIDI class function driver
>   *
>   * Copyright (C) 2006 Thumtronics Pty Ltd.
>   * Developed for Thumtronics by Grey Innovation
> @@ -16,7 +16,7 @@
>   *   Copyright (C) 2006 Thumtronics Pty Ltd.
>   *   Ben Williamson 
>   *
> - * Licensed under the GPL-2 or later.
> + * Licensed under the GPLv2.

Any particular reason to do that?

>   */
>  
>  #include 
> @@ -41,8 +41,8 @@
>  MODULE_AUTHOR("Ben Williamson");
>  MODULE_LICENSE("GPL v2");
>  
> -static const char f_midi_shortname[] = "f_midi";
> -static const char f_midi_longname[] = "MIDI Gadget";
> +static const char f_midi_shortname[] =   "f_midi";
> +static const char f_midi_longname[] ="MIDI Gadget";
>  
>  /*
>   * We can only handle 16 cables on one single endpoint, as cable numbers are
> @@ -78,28 +78,31 @@ struct gmidi_in_port {
>  };
>  
>  struct f_midi {
> - struct usb_function func;
> - struct usb_gadget   *gadget;
> - struct usb_ep   *in_ep, *out_ep;
> - struct snd_card *card;
> - struct snd_rawmidi  *rmidi;
> - u8  ms_id;
> -
> - struct snd_rawmidi_substream *out_substream[MAX_PORTS];
> -
> - unsigned long   out_triggered;
> - struct tasklet_struct   tasklet;
> + struct usb_function func;
> + struct usb_gadget *gadget;
> + struct usb_ep *in_ep, *out_ep;
> + u8 ms_id;
> + unsigned long out_triggered;
>   unsigned int in_ports;
>   unsigned int out_ports;
> - int index;
> - char *id;
> - unsigned int buflen, qlen;
> + unsigned int buflen;
> + unsigned int qlen;
> + unsigned int len;
> +
>   /* This fifo is used as a buffer ring for pre-allocated IN usb_requests 
> */
>   DECLARE_KFIFO_PTR(in_req_fifo, struct usb_request *);
>   spinlock_t transmit_lock;
> +
> + /* ALSA stuff */
> + struct snd_card *card;
> + struct snd_rawmidi *rmidi;
> + struct snd_rawmidi_substream *out_substream[MAX_PORTS];
> + struct tasklet_struct tasklet;
>   unsigned int in_last_port;
> + int index;
> + char *id;
>  
> - struct gmidi_in_portin_ports_array[/* in_ports */];
> + struct gmidi_in_port in_ports_array[/* in_ports */];
>  };
>  
>  static inline struct f_midi *func_to_midi(struct usb_function *f)
> @@ -191,7 +194,7 @@ static struct usb_ms_endpoint_descriptor_16 ms_in_desc = {
>  
>  /* string IDs are assigned dynamically */
>  
> -#define STRING_FUNC_IDX  0
> +#define STRING_FUNC_IDX 0
>  
>  static struct usb_string midi_string_defs[] = {
>   [STRING_FUNC_IDX].s = "MIDI function",
> @@ -199,7 +202,7 @@ static struct usb_string midi_string_defs[] = {
>  };
>  
>  static struct usb_gadget_strings midi_stringtab = {
> - .language   = 0x0409,   /* en-us */
> + .language   = 0x0409, /* en-us */
>   .strings= midi_string_defs,
>  };
>  
> @@ -409,7 +412,7 @@ static int f_midi_snd_free(struct snd_device *device)
>  }
>  
>  /*
> - * Converts MIDI commands to USB MIDI packets.
> + * Converts MIDI commands to USB-MIDI packets.
>   */
>  static void f_midi_transmit_byte(struct usb_request *req,
>struct gmidi_in_port *port, uint8_t b)
> @@ -956,15 +959,15 @@ static int f_midi_bind(struct usb_configuration *c, 
> struct usb_function *f)
>   in_emb->iJack   = 0;
>   midi_function[i++] = (struct usb_descriptor_header *) in_emb;
>  
> - out_ext->bLength =  USB_DT_MIDI_OUT_SIZE(1);
> - out_ext->bDescriptorType =  USB_DT_CS_INTERFACE;
> - out_ext->bDescriptorSubtype =   USB_MS_MIDI_OUT_JACK;
> - out_ext->bJackType =USB_MS_EXTERNAL;
> - out_ext->bJackID =  jack++;
> - out_ext->bNrInputPins = 1;
> - out_ext->iJack =0;
> - out_ext->pins[0].baSourceID =   in_emb->bJackID;
> - out_ext->pins[0].baSourcePin =  1;
> + out_ext->bLength= USB_DT_MIDI_OUT_SIZE(1);
> + out_ext->bDescriptorType= USB_DT_CS_INTERFACE;
> + out_ext->bDescriptorSubtype = USB_MS_MIDI_OUT_JACK;
> + out_ext->bJackType  = USB_MS_EXTERNAL;
> + out_ext->bJackID= jack++;
> + 

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

[Alan Stern]

On Fri, 4 Mar 2016, Devon Ash wrote:

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

If they are completely unresponsive, why do you get the -110 errors?  I 
would expect you wouldn't get anything at all.

> Thoughts/Ideas? The broken drivers are ehci-pci. xhci-hcd works on the
> usb 3.0 ports, but for 2 other usb 3.0 ports it does not work.
> 
>  The machine is being netbooted and running kernel 3.19-49-lowlatency
> (i've tried with generic as well). This same identical setup running
> off of a hard disk boot does not have this problem for any USB ports.
> Im lead to believe there may be a bug in the ehci-pci driver while
> using netboot.

What type of motherboard or system is this?

Can you try using a more up-to-date kernel, such as 4.4?

Failing that, can you at least provide a usbmon trace showing what 
happens when you plug a device into one of the bad ports?  And also a 
dmesg log with USB debugging enabled?

Alan Stern

--
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/5] usb: gadget: f_midi: added spinlock on transmit function

[Felipe Ferreri Tonello]

Hi Balbi, 

On March 4, 2016 7:20:10 AM GMT+00:00, Felipe Balbi  wrote:
>
>Hi,
>
>"Felipe F. Tonello"  writes:
>> [ text/plain ]
>> Since f_midi_transmit is called by both ALSA and USB frameworks, it
>can
>> potentially cause a race condition between both calls. This is bad
>because the
>> way f_midi_transmit is implemented can't handle concurrent calls.
>This is due
>> to the fact that the usb request fifo looks for the next element and
>only if
>> it has data to process it enqueues the request, otherwise re-uses it.
>If both
>> (ALSA and USB) frameworks calls this function at the same time, the
>> kfifo_seek() will return the same usb_request, which will cause a
>race
>> condition.
>>
>> To solve this problem a syncronization mechanism is necessary. In
>this case it
>> is used a spinlock since f_midi_transmit is also called by
>usb_request->complete
>> callback in interrupt context.
>>
>> On benchmarks realized by me, spinlocks were more efficient then
>scheduling
>> the f_midi_transmit tasklet in process context and using a mutex to
>> synchronize. Also it performs better then previous implementation
>that
>> allocated a usb_request for every new transmit made.
>
>behaves better in what way ? Also, previous implementation would not
>suffer from this concurrency problem, right ?

The spin lock is faster than allocating usb requests all the time, even if the 
udc uses da for it. 

That's true it wasn't necessary to put a spin lock in the gadget driver because 
the udc driver does it when allocating a new request. 

Felipe 

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
--
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/5] usb: gadget: gmidi: remove bus powered requirement on bmAttributes

[Felipe Ferreri Tonello]

Hi Balbi, 

On March 4, 2016 7:16:42 AM GMT+00:00, Felipe Balbi  wrote:
>
>Hi,
>
>"Felipe F. Tonello"  writes:
>> [ text/plain ]
>> This gadget uses a bmAttributes and MaxPower that requires the USB
>bus to be
>> powered from the host, which is not correct because this
>configuration is device
>> specific, not a USB-MIDI requirement.
>>
>> This patch adds two modules parameters, bmAttributes and MaxPower,
>that allows
>> the user to set those flags. The default values are what the gadget
>used to use
>> for backward compatibility.
>>
>> Signed-off-by: Felipe F. Tonello 
>> ---
>>  drivers/usb/gadget/legacy/gmidi.c | 14 --
>>  1 file changed, 12 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/usb/gadget/legacy/gmidi.c
>b/drivers/usb/gadget/legacy/gmidi.c
>> index fc2ac150f5ff..0553435cc360 100644
>> --- a/drivers/usb/gadget/legacy/gmidi.c
>> +++ b/drivers/usb/gadget/legacy/gmidi.c
>> @@ -63,6 +63,14 @@ static unsigned int out_ports = 1;
>>  module_param(out_ports, uint, S_IRUGO);
>>  MODULE_PARM_DESC(out_ports, "Number of MIDI output ports");
>>  
>> +static unsigned int bmAttributes = USB_CONFIG_ATT_ONE;
>> +module_param(bmAttributes, uint, S_IRUGO);
>> +MODULE_PARM_DESC(bmAttributes, "Configuration Descriptor's
>bmAttributes parameter");
>> +
>> +static unsigned int MaxPower = CONFIG_USB_GADGET_VBUS_DRAW;
>> +module_param(MaxPower, uint, S_IRUGO);
>> +MODULE_PARM_DESC(MaxPower, "Used to calculate Configuration
>Descriptor's bMaxPower parameter");
>
>you didn't run checkpatch, did you ? Also, are you sure you will need
>to
>change this by simply reloading the module ? I'm not convinced.

Yes I always run checkpatch :) 

What do you mean by reloading the module? 

>
>> @@ -119,8 +127,8 @@ static struct usb_configuration midi_config = {
>>  .label  = "MIDI Gadget",
>>  .bConfigurationValue = 1,
>>  /* .iConfiguration = DYNAMIC */
>> -.bmAttributes   = USB_CONFIG_ATT_ONE,
>
>nack, nackety nack nack nack :-)
>
>USB_CONFIG_ATT_ONE *must* always be set. With your module parameter you
>give users the oportunity to violate USB spec.

You are right. It needs to check the value before it assigns to bmAttributes. 

Felipe 

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
--
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/5] usb: gadget: f_midi: refactor state machine

[Clemens Ladisch]

Felipe Ferreri Tonello wrote:
> On March 4, 2016 8:07:40 AM GMT+00:00, Clemens Ladisch  
> wrote:
>> Felipe Ferreri Tonello wrote:
>>> On 03/03/16 11:38, Clemens Ladisch wrote:
 But in what way was the old state machine not "proper"?
>>>
>>> Because it didn't reflect all the correct and possible MIDI states
>>
>> The whole point of the one-byte real-time messages is that they do not
>> affect the parsing of the surrounding MIDI stream.  So not making them
>> part of the state machine is the proper way of handling them.  (Also
>> see the flowchart in appendix A of the spec.)
>
> I really don't get your point. So why do we have a state machine at all?

To parse all the other messages.


Regards,
Clemens
--
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 0/5] MIDI USB Gadget improvements

[Felipe Ferreri Tonello]

Hi Balbi, 

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

Right. I didn't in this case because I sent this patch previously a while ago 
right before you changed employer. 

>
>I guess it's too late to get this in v4.6 merge window as I'm already
>applying the last few patches and plan to send a pull request in a few
>minutes.

That's fine I won't be able to rework the comments before Monday anyway. 

Thanks, 
Felipe 

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
--
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 5/5] usb: gadget: f_midi: updated copyright

[Felipe Ferreri Tonello]

Hi Balbi, 

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

Got it. 

>
>> ---
>>  drivers/usb/gadget/function/f_midi.c | 3 +++
>>  1 file changed, 3 insertions(+)
>>
>> diff --git a/drivers/usb/gadget/function/f_midi.c
>b/drivers/usb/gadget/function/f_midi.c
>> index 9a9e6112e224..5c7f5c780fda 100644
>> --- a/drivers/usb/gadget/function/f_midi.c
>> +++ b/drivers/usb/gadget/function/f_midi.c
>> @@ -5,6 +5,9 @@
>>   * Developed for Thumtronics by Grey Innovation
>>   * Ben Williamson 
>>   *
>> + * Copyright (C) 2015,2016 ROLI Ltd.
>> + * Felipe F. Tonello 
>
>Did you check with your company's lawyer that your changes are enough
>to
>justify a copyright ?

Yes. Specially if that state machine refractor gets approved. TBH I can't see 
it won't. 

Thanks, 

Felipe 

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
--
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/5] usb: gadget: f_midi: refactor state machine

[Felipe Ferreri Tonello]

Hi Clemens, 

On March 4, 2016 8:07:40 AM GMT+00:00, Clemens Ladisch  
wrote:
>Felipe Ferreri Tonello wrote:
>> On 03/03/16 11:38, Clemens Ladisch wrote:
>>> But in what way was the old state machine not "proper"?
>>
>> Because it didn't reflect all the correct and possible MIDI states
>
>The whole point of the one-byte real-time messages is that they do not
>affect the parsing of the surrounding MIDI stream.  So not making them
>part of the state machine is the proper way of handling them.  (Also
>see the flowchart in appendix A of the spec.)

I really don't get your point. So why do we have a state machine at all? 

>
>> This patch doesn't change any functionality. But the important thing
>> here is that it improves the driver maintainability [...]
>
>Then I won't get in the way of this driver's maintainer.


Clemens, I really value your feedback. I just want to understand what's the 
problem of this patch. 

Felipe 

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
--
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/6] usb: make xhci platform driver use 64 bit or 32 bit DMA

[Timur Tabi]

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

I know this patch is a few months old and has already been merged, but
I have a question about how it works, because we're thinking about
doing something similar for another driver.

> +   /* Try to set 64-bit DMA first */
> +   if (WARN_ON(!pdev->dev.dma_mask))
> +   /* Platform did not initialize dma_mask */
> +   ret = dma_coerce_mask_and_coherent(>dev,
> +  DMA_BIT_MASK(64));
> else
> -   dma_set_mask(>dev, DMA_BIT_MASK(32));
> +   ret = dma_set_mask_and_coherent(>dev, DMA_BIT_MASK(64));
> +
> +   /* If seting 64-bit DMA mask fails, fall back to 32-bit DMA mask */
> +   if (ret) {
> +   ret = dma_set_mask_and_coherent(>dev, DMA_BIT_MASK(32));
> +   if (ret)
> +   return ret;
> +   }

I don't understand why this is necessary.  I was under the impression
that when a driver calls dma_set_mask_xxx, all it's doing is telling
the kernel what DMA ranges the device is capable of. If a device is
physically capable of DMA'ing to all of RAM (let's assume everything
is coherent), then it should set the mask to 64 and leave it at that.
If the platform has some other DMA address range limitation, the
driver shouldn't have to worry about that.  It should still set the
mask to 64, and something else will figure out that the *real* mask is
less than that.  Then when the driver calls dma_alloc_coherent(), it
will always get a DMA buffer from low memory, but that's okay.

But apparently, that's not how it really works, which is why this
patch exists.  And that's why I'm confused.

I have a few other related questions.  Let's say that we have a device
that is normally capable of 64-bit DMA.  But on one particular
platform, only 32 bits of the address bus is wired up, so effectively
the device is only capable of 32-bit DMA.  This information is hidden
from the device, so the driver cannot query the device itself to
discover this.  What is the proper way to handle this?  We probably
don't want to add platform-specific code to the driver (like an MIDR
check on ARM systems).

Thanks in advance for any answers.  DMA-API-HOWTO.txt says this:

"Rather, it may fail in this case simply because 32-bit
addressing is done more efficiently than 64-bit addressing."

But that doesn't apply in our situation.  And even then, this seems
like an odd reason to fail.  Wouldn't it make more sense for the
dma_set_mask_xxx() API to just automatically adjust the mask to a
smaller value, and return success?
--
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

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

[Devon Ash]

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

Thoughts/Ideas? The broken drivers are ehci-pci. xhci-hcd works on the
usb 3.0 ports, but for 2 other usb 3.0 ports it does not work.

 The machine is being netbooted and running kernel 3.19-49-lowlatency
(i've tried with generic as well). This same identical setup running
off of a hard disk boot does not have this problem for any USB ports.
Im lead to believe there may be a bug in the ehci-pci driver while
using netboot.


Thank you. Devon
--
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

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

[Douglas Anderson]

This reverts commit 192cb07f7928 ("usb: dwc2: Fix probe problem on
bcm2835") now that we've found the root cause.  See the change
titled ("usb: dwc2: Add a 10 ms delay to dwc2_core_reset()").

Signed-off-by: Douglas Anderson 
---
 drivers/usb/dwc2/core.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/usb/dwc2/core.c b/drivers/usb/dwc2/core.c
index 8710b2d3e770..7c4a6cf4c73a 100644
--- a/drivers/usb/dwc2/core.c
+++ b/drivers/usb/dwc2/core.c
@@ -353,6 +353,12 @@ static bool dwc2_force_mode(struct dwc2_hsotg *hsotg, bool 
host)
set = host ? GUSBCFG_FORCEHOSTMODE : GUSBCFG_FORCEDEVMODE;
clear = host ? GUSBCFG_FORCEDEVMODE : GUSBCFG_FORCEHOSTMODE;
 
+   /*
+   * If the force mode bit is already set, don't set it.
+   */
+   if ((gusbcfg & set) && !(gusbcfg & clear))
+   return false;
+
gusbcfg &= ~clear;
gusbcfg |= set;
dwc2_writel(gusbcfg, hsotg->regs + GUSBCFG);
-- 
2.7.0.rc3.207.g0ac5344

--
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/6] usb: xhci-mtk: use __maybe_unused to hide pm functions

[Matthias Brugger]

On 02/03/16 16:24, Arnd Bergmann wrote:

The mediatek XHCI glue driver uses SET_SYSTEM_SLEEP_PM_OPS() to
conditionally set the correct suspend/resume options, and
also puts both the dev_pm_ops and the functions inside of
an #ifdef testing for CONFIG_PM_SLEEP, but those functions
then call other code that becomes unused:

drivers/usb/host/xhci-mtk.c:135:12: error: 'xhci_mtk_host_disable' defined but 
not used [-Werror=unused-function]
drivers/usb/host/xhci-mtk.c:313:13: error: 'usb_wakeup_enable' defined but not 
used [-Werror=unused-function]
drivers/usb/host/xhci-mtk.c:321:13: error: 'usb_wakeup_disable' defined but not 
used [-Werror=unused-function]

This replaces the #ifdef with __maybe_unused annotations so the
compiler knows it can silently drop them instead of warning.

For the DEV_PM_OPS definition, we can use an IS_ENABLED() check
to avoid defining the structure when CONFIG_PM is not set without
the #ifdef.

Signed-off-by: Arnd Bergmann 
---


Reviewed-by: Matthias Brugger 


  drivers/usb/host/xhci-mtk.c | 10 +++---
  1 file changed, 3 insertions(+), 7 deletions(-)

diff --git a/drivers/usb/host/xhci-mtk.c b/drivers/usb/host/xhci-mtk.c
index 9532f5aef71b..79959f17c38c 100644
--- a/drivers/usb/host/xhci-mtk.c
+++ b/drivers/usb/host/xhci-mtk.c
@@ -695,7 +695,6 @@ static int xhci_mtk_remove(struct platform_device *dev)
return 0;
  }

-#ifdef CONFIG_PM_SLEEP
  /*
   * if ip sleep fails, and all clocks are disabled, access register will hang
   * AHB bus, so stop polling roothubs to avoid regs access on bus suspend.
@@ -703,7 +702,7 @@ static int xhci_mtk_remove(struct platform_device *dev)
   * to wake up system immediately after system suspend complete if ip sleep
   * fails, it is what we wanted.
   */
-static int xhci_mtk_suspend(struct device *dev)
+static int __maybe_unused xhci_mtk_suspend(struct device *dev)
  {
struct xhci_hcd_mtk *mtk = dev_get_drvdata(dev);
struct usb_hcd *hcd = mtk->hcd;
@@ -722,7 +721,7 @@ static int xhci_mtk_suspend(struct device *dev)
return 0;
  }

-static int xhci_mtk_resume(struct device *dev)
+static int __maybe_unused xhci_mtk_resume(struct device *dev)
  {
struct xhci_hcd_mtk *mtk = dev_get_drvdata(dev);
struct usb_hcd *hcd = mtk->hcd;
@@ -744,10 +743,7 @@ static int xhci_mtk_resume(struct device *dev)
  static const struct dev_pm_ops xhci_mtk_pm_ops = {
SET_SYSTEM_SLEEP_PM_OPS(xhci_mtk_suspend, xhci_mtk_resume)
  };
-#define DEV_PM_OPS (_mtk_pm_ops)
-#else
-#define DEV_PM_OPS NULL
-#endif /* CONFIG_PM */
+#define DEV_PM_OPS IS_ENABLED(CONFIG_PM) ? _mtk_pm_ops : NULL

  #ifdef CONFIG_OF
  static const struct of_device_id mtk_xhci_of_match[] = {


--
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 v10 2/9] dt-bindings: pinctrl: Deprecate Tegra XUSB pad controller binding

[Thierry Reding]

From: Thierry Reding 

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

Signed-off-by: Thierry Reding 
---
 .../devicetree/bindings/pinctrl/nvidia,tegra124-xusb-padctl.txt  | 1 +
 1 file changed, 1 insertion(+)

diff --git 
a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra124-xusb-padctl.txt 
b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra124-xusb-padctl.txt
index 77dfba05ccfd..8a6223dbc143 100644
--- a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra124-xusb-padctl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra124-xusb-padctl.txt
@@ -5,6 +5,7 @@ NOTE: It turns out that this binding isn't an accurate 
description of the XUSB
 pad controller. While the description is good enough for the functional subset
 required for PCIe and SATA, it lacks the flexibility to represent the features
 needed for USB. For the new binding, see ../phy/nvidia,tegra-xusb-padctl.txt.
+The binding described in this file is deprecated and should not be used.
 
 The Tegra XUSB pad controller manages a set of lanes, each of which can be
 assigned to one out of a set of different pads. Some of these pads have an
-- 
2.7.1

--
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 v10 1/9] dt-bindings: phy: Add NVIDIA Tegra XUSB pad controller binding

[Thierry Reding]

From: Thierry Reding 

The NVIDIA Tegra XUSB pad controller provides a set of pads, each with a
set of lanes that are used for PCIe, SATA and USB.

Signed-off-by: Thierry Reding 
---
Changes in v10:
- clarify that the hardware documentation means something different when
  referring to a "port" (intra-SoC connectivity)

Changes in v9:
- rename UTMI -> USB2 to match hardware documentation
- reword according to suggestions by Stephen Warren
- make Tegra132 compatible string list consistent
- remove mailbox support

 .../bindings/phy/nvidia,tegra124-xusb-padctl.txt   | 376 +
 .../pinctrl/nvidia,tegra124-xusb-padctl.txt|   5 +
 2 files changed, 381 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/phy/nvidia,tegra124-xusb-padctl.txt

diff --git 
a/Documentation/devicetree/bindings/phy/nvidia,tegra124-xusb-padctl.txt 
b/Documentation/devicetree/bindings/phy/nvidia,tegra124-xusb-padctl.txt
new file mode 100644
index ..8b642d9e3433
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/nvidia,tegra124-xusb-padctl.txt
@@ -0,0 +1,376 @@
+Device tree binding for NVIDIA Tegra XUSB pad controller
+
+
+The Tegra XUSB pad controller manages a set of I/O lanes (with differential
+signals) which connect directly to pins/pads on the SoC package. Each lane
+is controlled by a HW block referred to as a "pad" in the Tegra hardware
+documentation. Each such "pad" may control either one or multiple lanes,
+and thus contains any logic common to all its lanes. Each lane can be
+separately configured and powered up.
+
+Some of the lanes are high-speed lanes, which can be used for PCIe, SATA or
+super-speed USB. Other lanes are for various types of low-speed, full-speed
+or high-speed USB (such as UTMI, ULPI and HSIC). The XUSB pad controller
+contains a software-configurable mux that sits between the I/O controller
+ports (e.g. PCIe) and the lanes.
+
+In addition to per-lane configuration, USB 3.0 ports may require additional
+settings on a per-board basis.
+
+Pads will be represented as children of the top-level XUSB pad controller
+device tree node. Each lane exposed by the pad will be represented by its
+own subnode and can be referenced by users of the lane using the standard
+PHY bindings, as described by the phy-bindings.txt file in this directory.
+
+The Tegra hardware documentation refers to the connection between the XUSB
+pad controller and the XUSB controller as "ports". This is confusing since
+"port" is typically used to denote the physical USB receptacle. The device
+tree binding in this document uses the term "port" to refer to the logical
+abstraction of the signals that are routed to a USB receptacle (i.e. a PHY
+for the USB signal, the VBUS power supply, the USB 2.0 companion port for
+USB 3.0 receptacles, ...).
+
+Required properties:
+
+- compatible: Must be:
+  - Tegra124: "nvidia,tegra124-xusb-padctl"
+  - Tegra132: "nvidia,tegra132-xusb-padctl", "nvidia,tegra124-xusb-padctl"
+- reg: Physical base address and length of the controller's registers.
+- resets: Must contain an entry for each entry in reset-names.
+- reset-names: Must include the following entries:
+  - "padctl"
+
+
+Pad nodes:
+==
+
+A required child node named "pads" contains a list of subnodes, one for each
+of the pads exposed by the XUSB pad controller. Each pad may need additional
+resources that can be referenced in its pad node.
+
+The "status" property is used to enable or disable the use of a pad. If set
+to "disabled", the pad will not be used on the given board. In order to use
+the pad and any of its lanes, this property must be set to "okay".
+
+For Tegra124 and Tegra132, the following pads exist: usb2, ulpi, hsic, pcie
+and sata. No extra resources are required for operation of these pads.
+
+
+PHY nodes:
+==
+
+Each pad node has one or more children, each representing one of the lanes
+controlled by the pad.
+
+Required properties:
+
+- status: Defines the operation status of the PHY. Valid values are:
+  - "disabled": the PHY is disabled
+  - "okay": the PHY is enabled
+- #phy-cells: Should be 0. Since each lane represents a single PHY, there is
+  no need for an additional specifier.
+- nvidia,function: The output function of the PHY. See below for a list of
+  valid functions per SoC generation.
+
+For Tegra124 and Tegra132, the list of valid PHY nodes is given below:
+- usb2: usb2-0, usb2-1, usb2-2
+  - functions: "snps", "xusb", "uart"
+- ulpi: ulpi-0
+  - functions: "snps", "xusb"
+- hsic: hsic-0, hsic-1
+  - functions: "snps", "xusb"
+- pcie: pcie-0, pcie-1, pcie-2, pcie-3, pcie-4
+  - functions: "pcie", "usb3-ss"
+- sata: sata-0
+  - functions: "usb3-ss", "sata"
+
+
+Port nodes:
+===
+
+A required child node named "ports" contains a list of all the ports exposed
+by the XUSB pad controller. Per-port 

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

[Thierry Reding]

From: Thierry Reding 

Extend the binding to cover the set of feature found in Tegra210.

Signed-off-by: Thierry Reding 
---
 .../bindings/phy/nvidia,tegra124-xusb-padctl.txt   | 327 +
 1 file changed, 327 insertions(+)

diff --git 
a/Documentation/devicetree/bindings/phy/nvidia,tegra124-xusb-padctl.txt 
b/Documentation/devicetree/bindings/phy/nvidia,tegra124-xusb-padctl.txt
index 8b642d9e3433..8cbfeb60f864 100644
--- a/Documentation/devicetree/bindings/phy/nvidia,tegra124-xusb-padctl.txt
+++ b/Documentation/devicetree/bindings/phy/nvidia,tegra124-xusb-padctl.txt
@@ -35,6 +35,7 @@ Required properties:
 - compatible: Must be:
   - Tegra124: "nvidia,tegra124-xusb-padctl"
   - Tegra132: "nvidia,tegra132-xusb-padctl", "nvidia,tegra124-xusb-padctl"
+  - Tegra210: "nvidia,tegra210-xusb-padctl"
 - reg: Physical base address and length of the controller's registers.
 - resets: Must contain an entry for each entry in reset-names.
 - reset-names: Must include the following entries:
@@ -55,6 +56,44 @@ the pad and any of its lanes, this property must be set to 
"okay".
 For Tegra124 and Tegra132, the following pads exist: usb2, ulpi, hsic, pcie
 and sata. No extra resources are required for operation of these pads.
 
+For Tegra210, the following pads exist: usb2, hsic, pcie and sata. Below is
+a description of the properties of each pad.
+
+UTMI pad:
+-
+
+Required properties:
+- clocks: Must contain an entry for each entry in clock-names.
+- clock-names: Must contain the following entries:
+  - "trk": phandle and specifier referring to the USB2 tracking clock
+
+HSIC pad:
+-
+
+Required properties:
+- clocks: Must contain an entry for each entry in clock-names.
+- clock-names: Must contain the following entries:
+  - "trk": phandle and specifier referring to the HSIC tracking clock
+
+PCIe pad:
+-
+
+Required properties:
+- clocks: Must contain an entry for each entry in clock-names.
+- clock-names: Must contain the following entries:
+  - "pll": phandle and specifier referring to the PLLE
+- resets: Must contain an entry for each entry in reset-names.
+- reset-names: Must contain the following entries:
+  - "phy": reset for the PCIe UPHY block
+
+SATA pad:
+-
+
+Required properties:
+- resets: Must contain an entry for each entry in reset-names.
+- reset-names: Must contain the following entries:
+  - "phy": reset for the SATA UPHY block
+
 
 PHY nodes:
 ==
@@ -84,6 +123,16 @@ For Tegra124 and Tegra132, the list of valid PHY nodes is 
given below:
 - sata: sata-0
   - functions: "usb3-ss", "sata"
 
+For Tegra210, the list of valid PHY nodes is given below:
+- utmi: utmi-0, utmi-1, utmi-2, utmi-3
+  - functions: "snps", "xusb", "uart"
+- hsic: hsic-0, hsic-1
+  - functions: "snps", "xusb"
+- pcie: pcie-0, pcie-1, pcie-2, pcie-3, pcie-4, pcie-5, pcie-6
+  - functions: "pcie-x1", "usb3-ss", "pcie-x4"
+- sata: sata-0
+  - functions: "usb3-ss", "sata"
+
 
 Port nodes:
 ===
@@ -144,6 +193,7 @@ Required properties:
   to map this super-speed USB port to. The range of valid port numbers varies
   with the SoC generation:
   - 0-2: for Tegra124 and Tegra132
+  - 0-3: for Tegra210
 
 Optional properties:
 - nvidia,internal: A boolean property whose presence determines that a port
@@ -157,6 +207,11 @@ ports:
 - 2x HSIC: hsic-0, hsic-1
 - 2x super-speed USB: usb3-0, usb3-1
 
+For Tegra210, the XUSB pad controller exposes the following ports:
+- 4x USB2: usb2-0, usb2-1, usb2-2, usb2-3
+- 2x HSIC: hsic-0, hsic-1
+- 4x super-speed USB: usb3-0, usb3-1, usb3-2, usb3-3
+
 
 Examples:
 =
@@ -374,3 +429,275 @@ Board file:
};
};
};
+
+Tegra210:
+-
+
+SoC include:
+
+   padctl@0,7009f000 {
+   compatible = "nvidia,tegra210-xusb-padctl";
+   reg = <0x0 0x7009f000 0x0 0x1000>;
+   resets = <_car 142>;
+   reset-names = "padctl";
+
+   status = "disabled";
+
+   pads {
+   usb2 {
+   clocks = <_car TEGRA210_CLK_USB2_TRK>;
+   clock-names = "trk";
+   status = "disabled";
+
+   usb2-0 {
+   status = "disabled";
+   #phy-cells = <0>;
+   };
+
+   usb2-1 {
+   status = "disabled";
+   #phy-cells = <0>;
+   };
+
+   usb2-2 {
+   status = "disabled";
+   #phy-cells = <0>;
+   };
+
+   usb2-3 {
+   status = "disabled";
+   

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

[Thierry Reding]

From: Thierry Reding 

Add device-tree binding documentation for the XUSB controller present
on Tegra124 and later SoCs. This controller supports USB 3.0 via an xHCI
compliant interface.

Based on work by Andrew Bresticker .

Cc: Rob Herring 
Cc: Pawel Moll 
Cc: Mark Rutland 
Cc: Ian Campbell 
Cc: Kumar Gala 
Cc: Mathias Nyman 
Cc: Greg Kroah-Hartman 
Signed-off-by: Thierry Reding 
---
Changes in v9:
- rename UTMI to USB2 to match hardware documentation
- remove MFD and mailbox components from bindings
- reference XUSB pad controller via phandle

 .../bindings/usb/nvidia,tegra124-xusb.txt  | 108 +
 1 file changed, 108 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/usb/nvidia,tegra124-xusb.txt

diff --git a/Documentation/devicetree/bindings/usb/nvidia,tegra124-xusb.txt 
b/Documentation/devicetree/bindings/usb/nvidia,tegra124-xusb.txt
new file mode 100644
index ..79616f9268d8
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/nvidia,tegra124-xusb.txt
@@ -0,0 +1,108 @@
+NVIDIA Tegra xHCI controller
+
+
+The Tegra xHCI controller supports both USB2 and USB3 interfaces exposed by
+the Tegra XUSB pad controller.
+
+Required properties:
+
+- compatible: Must be:
+  - Tegra124: "nvidia,tegra124-xusb"
+  - Tegra132: "nvidia,tegra132-xusb", "nvidia,tegra124-xusb"
+- reg: Must contain the base and length of the xHCI host registers, XUSB FPCI
+  registers and XUSB IPFS registers.
+- reg-names: Must contain the following entries:
+  - "hcd"
+  - "fpci"
+  - "ipfs"
+- interrupts: Must contain the xHCI host interrupt and the mailbox interrupt.
+- clocks: Must contain an entry for each entry in clock-names.
+  See ../clock/clock-bindings.txt for details.
+- clock-names: Must include the following entries:
+   - xusb_host
+   - xusb_host_src
+   - xusb_falcon_src
+   - xusb_ss
+   - xusb_ss_src
+   - xusb_ss_div2
+   - xusb_hs_src
+   - xusb_fs_src
+   - pll_u_480m
+   - clk_m
+   - pll_e
+- resets: Must contain an entry for each entry in reset-names.
+  See ../reset/reset.txt for details.
+- reset-names: Must include the following entries:
+  - xusb_host
+  - xusb_ss
+  - xusb_src
+  Note that xusb_src is the shared reset for xusb_{ss,hs,fs,falcon,host}_src.
+- nvidia,xusb-padctl: phandle to the XUSB pad controller that is used to
+  configure the USB pads used by the XHCI controller
+
+For Tegra124 and Tegra132:
+- avddio-pex-supply: PCIe/USB3 analog logic power supply. Must supply 1.05 V.
+- dvddio-pex-supply: PCIe/USB3 digital logic power supply. Must supply 1.05 V.
+- avdd-usb-supply: USB controller power supply. Must supply 3.3 V.
+- avdd-pll-utmip-supply: UTMI PLL power supply. Must supply 1.8 V.
+- avdd-pll-erefe-supply: PLLE reference PLL power supply. Must supply 1.05 V.
+- avdd-usb-ss-pll-supply: PCIe/USB3 PLL power supply. Must supply 1.05 V.
+- hvdd-usb-ss-supply: High-voltage PCIe/USB3 power supply. Must supply 3.3 V.
+- hvdd-usb-ss-pll-e-supply: High-voltage PLLE power supply. Must supply 3.3 V.
+
+Optional properties:
+
+- phys: Must contain an entry for each entry in phy-names.
+  See ../phy/phy-bindings.txt for details.
+- phy-names: Should include an entry for each PHY used by the controller. The
+  following PHYs are available:
+  - Tegra124: usb2-0, usb2-1, usb2-2, hsic-0, hsic-1, usb3-0, usb3-1
+  - Tegra132: usb2-0, usb2-1, usb2-2, hsic-0, hsic-1, usb3-0, usb3-1
+
+Example:
+
+
+   usb@0,7009 {
+   compatible = "nvidia,tegra124-xusb";
+   reg = <0x0 0x7009 0x0 0x8000>,
+ <0x0 0x70098000 0x0 0x1000>,
+ <0x0 0x70099000 0x0 0x1000>;
+   reg-names = "hcd", "fpci", "ipfs";
+
+   interrupts = ,
+;
+
+   clocks = <_car TEGRA124_CLK_XUSB_HOST>,
+<_car TEGRA124_CLK_XUSB_HOST_SRC>,
+<_car TEGRA124_CLK_XUSB_FALCON_SRC>,
+<_car TEGRA124_CLK_XUSB_SS>,
+<_car TEGRA124_CLK_XUSB_SS_DIV2>,
+<_car TEGRA124_CLK_XUSB_SS_SRC>,
+<_car TEGRA124_CLK_XUSB_HS_SRC>,
+<_car TEGRA124_CLK_XUSB_FS_SRC>,
+<_car TEGRA124_CLK_PLL_U_480M>,
+<_car TEGRA124_CLK_CLK_M>,
+<_car TEGRA124_CLK_PLL_E>;
+   clock-names = "xusb_host", "xusb_host_src", "xusb_falcon_src",
+ "xusb_ss", "xusb_ss_div2", "xusb_ss_src",
+ "xusb_hs_src", "xusb_fs_src", "pll_u_480m",
+ "clk_m", "pll_e";
+   resets = <_car 

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

[Thierry Reding]

From: Thierry Reding 

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

Signed-off-by: Thierry Reding 
---
Changes in v9:
- export public API for direct use by the xHCI driver (replaces mailbox
  API which had introduced a nasty circular dependency)

 drivers/phy/Kconfig|2 +
 drivers/phy/Makefile   |2 +
 drivers/phy/tegra/Kconfig  |8 +
 drivers/phy/tegra/Makefile |5 +
 drivers/phy/tegra/xusb-tegra124.c  | 1747 
 drivers/phy/tegra/xusb.c   | 1017 
 drivers/phy/tegra/xusb.h   |  421 +++
 drivers/pinctrl/tegra/pinctrl-tegra-xusb.c |   20 +-
 include/linux/phy/tegra/xusb.h |   30 +
 9 files changed, 3236 insertions(+), 16 deletions(-)
 create mode 100644 drivers/phy/tegra/Kconfig
 create mode 100644 drivers/phy/tegra/Makefile
 create mode 100644 drivers/phy/tegra/xusb-tegra124.c
 create mode 100644 drivers/phy/tegra/xusb.c
 create mode 100644 drivers/phy/tegra/xusb.h
 create mode 100644 include/linux/phy/tegra/xusb.h

diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 0124d17bd9fe..4bf65ceb3250 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -407,4 +407,6 @@ config PHY_CYGNUS_PCIE
  Enable this to support the Broadcom Cygnus PCIe PHY.
  If unsure, say N.
 
+source "drivers/phy/tegra/Kconfig"
+
 endmenu
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index c80f09df3bb8..82709141d072 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -50,3 +50,5 @@ obj-$(CONFIG_PHY_TUSB1210)+= phy-tusb1210.o
 obj-$(CONFIG_PHY_BRCMSTB_SATA) += phy-brcmstb-sata.o
 obj-$(CONFIG_PHY_PISTACHIO_USB)+= phy-pistachio-usb.o
 obj-$(CONFIG_PHY_CYGNUS_PCIE)  += phy-bcm-cygnus-pcie.o
+
+obj-$(CONFIG_ARCH_TEGRA) += tegra/
diff --git a/drivers/phy/tegra/Kconfig b/drivers/phy/tegra/Kconfig
new file mode 100644
index ..a3b1de953fb7
--- /dev/null
+++ b/drivers/phy/tegra/Kconfig
@@ -0,0 +1,8 @@
+config PHY_TEGRA_XUSB
+   tristate "NVIDIA Tegra XUSB pad controller driver"
+   depends on ARCH_TEGRA
+   help
+ Choose this option if you have an NVIDIA Tegra SoC.
+
+ To compile this driver as a module, choose M here: the module will
+ be called phy-tegra-xusb.
diff --git a/drivers/phy/tegra/Makefile b/drivers/phy/tegra/Makefile
new file mode 100644
index ..31150b4337cd
--- /dev/null
+++ b/drivers/phy/tegra/Makefile
@@ -0,0 +1,5 @@
+obj-$(CONFIG_PHY_TEGRA_XUSB) += phy-tegra-xusb.o
+
+phy-tegra-xusb-y += xusb.o
+phy-tegra-xusb-$(CONFIG_ARCH_TEGRA_124_SOC) += xusb-tegra124.o
+phy-tegra-xusb-$(CONFIG_ARCH_TEGRA_132_SOC) += xusb-tegra124.o
diff --git a/drivers/phy/tegra/xusb-tegra124.c 
b/drivers/phy/tegra/xusb-tegra124.c
new file mode 100644
index ..6340d43688d3
--- /dev/null
+++ b/drivers/phy/tegra/xusb-tegra124.c
@@ -0,0 +1,1747 @@
+/*
+ * Copyright (c) 2014, NVIDIA CORPORATION.  All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope 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.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include "xusb.h"
+
+#define FUSE_SKU_CALIB_HS_CURR_LEVEL_PADX_SHIFT(x) ((x) ? 15 : 0)
+#define FUSE_SKU_CALIB_HS_CURR_LEVEL_PAD_MASK 0x3f
+#define FUSE_SKU_CALIB_HS_IREF_CAP_SHIFT 13
+#define FUSE_SKU_CALIB_HS_IREF_CAP_MASK 0x3
+#define FUSE_SKU_CALIB_HS_SQUELCH_LEVEL_SHIFT 11
+#define FUSE_SKU_CALIB_HS_SQUELCH_LEVEL_MASK 0x3
+#define FUSE_SKU_CALIB_HS_TERM_RANGE_ADJ_SHIFT 7
+#define FUSE_SKU_CALIB_HS_TERM_RANGE_ADJ_MASK 0xf
+
+#define XUSB_PADCTL_USB2_PORT_CAP 0x008
+#define XUSB_PADCTL_USB2_PORT_CAP_PORTX_CAP_SHIFT(x) ((x) * 4)
+#define XUSB_PADCTL_USB2_PORT_CAP_PORT_CAP_MASK 0x3
+#define XUSB_PADCTL_USB2_PORT_CAP_DISABLED 0x0
+#define XUSB_PADCTL_USB2_PORT_CAP_HOST 0x1
+#define XUSB_PADCTL_USB2_PORT_CAP_DEVICE 0x2
+#define XUSB_PADCTL_USB2_PORT_CAP_OTG 0x3
+
+#define XUSB_PADCTL_SS_PORT_MAP 0x014
+#define XUSB_PADCTL_SS_PORT_MAP_PORTX_INTERNAL(x) (1 << (((x) * 4) + 3))
+#define XUSB_PADCTL_SS_PORT_MAP_PORTX_MAP_SHIFT(x) ((x) * 4)
+#define XUSB_PADCTL_SS_PORT_MAP_PORTX_MAP_MASK(x) (0x7 << ((x) * 4))
+#define 

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

[Thierry Reding]

From: Thierry Reding 

Add support for the on-chip XUSB controller present on Tegra SoCs. This
controller, when loaded with external firmware, exposes an interface
compliant with xHCI. This driver loads the firmware, starts the
controller, and is able to service host-specific messages sent by the
controller's firmware.

The controller also supports USB device mode as well as powergating
of the SuperSpeed and host-controller logic when not in use, but
support for these is not yet implemented.

Based on work by:
  Ajay Gupta 
  Bharath Yadav 
  Andrew Bresticker 

Cc: Greg Kroah-Hartman 
Cc: Mathias Nyman 
Signed-off-by: Thierry Reding 
---
 drivers/usb/host/Kconfig  |9 +
 drivers/usb/host/Makefile |1 +
 drivers/usb/host/xhci-tegra.c | 1332 +
 3 files changed, 1342 insertions(+)
 create mode 100644 drivers/usb/host/xhci-tegra.c

diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 8c20ebbc049c..191fdeb8b841 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -69,6 +69,15 @@ config USB_XHCI_RCAR
  Say 'Y' to enable the support for the xHCI host controller
  found in Renesas R-Car ARM SoCs.
 
+config USB_XHCI_TEGRA
+   tristate "xHCI support for NVIDIA Tegra SoCs"
+   depends on PHY_TEGRA_XUSB
+   depends on RESET_CONTROLLER
+   select FW_LOADER
+   ---help---
+ Say 'Y' to enable the support for the xHCI host controller
+ found in NVIDIA Tegra124 and later SoCs.
+
 endif # USB_XHCI_HCD
 
 config USB_EHCI_HCD
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index a9ddd3c9ec94..6ef785b0ea8f 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -68,6 +68,7 @@ obj-$(CONFIG_USB_XHCI_HCD)+= xhci-hcd.o
 obj-$(CONFIG_USB_XHCI_PCI) += xhci-pci.o
 obj-$(CONFIG_USB_XHCI_PLATFORM) += xhci-plat-hcd.o
 obj-$(CONFIG_USB_XHCI_MTK) += xhci-mtk.o
+obj-$(CONFIG_USB_XHCI_TEGRA)   += xhci-tegra.o
 obj-$(CONFIG_USB_SL811_HCD)+= sl811-hcd.o
 obj-$(CONFIG_USB_SL811_CS) += sl811_cs.o
 obj-$(CONFIG_USB_U132_HCD) += u132-hcd.o
diff --git a/drivers/usb/host/xhci-tegra.c b/drivers/usb/host/xhci-tegra.c
new file mode 100644
index ..ab6f9856c5c4
--- /dev/null
+++ b/drivers/usb/host/xhci-tegra.c
@@ -0,0 +1,1332 @@
+/*
+ * NVIDIA Tegra xHCI host controller driver
+ *
+ * Copyright (C) 2014 NVIDIA Corporation
+ * Copyright (C) 2014 Google, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "xhci.h"
+
+#define TEGRA_XHCI_SS_HIGH_SPEED 12000
+#define TEGRA_XHCI_SS_LOW_SPEED   1200
+
+/* FPCI CFG registers */
+#define XUSB_CFG_1 0x004
+#define  XUSB_IO_SPACE_EN  BIT(0)
+#define  XUSB_MEM_SPACE_EN BIT(1)
+#define  XUSB_BUS_MASTER_ENBIT(2)
+#define XUSB_CFG_4 0x010
+#define  XUSB_BASE_ADDR_SHIFT  15
+#define  XUSB_BASE_ADDR_MASK   0x1
+#define XUSB_CFG_ARU_C11_CSBRANGE  0x41c
+#define XUSB_CFG_CSB_BASE_ADDR 0x800
+
+/* FPCI mailbox registers */
+#define XUSB_CFG_ARU_MBOX_CMD  0x0e4
+#define  MBOX_DEST_FALCBIT(27)
+#define  MBOX_DEST_PME BIT(28)
+#define  MBOX_DEST_SMI BIT(29)
+#define  MBOX_DEST_XHCIBIT(30)
+#define  MBOX_INT_EN   BIT(31)
+#define XUSB_CFG_ARU_MBOX_DATA_IN  0x0e8
+#define  CMD_DATA_SHIFT0
+#define  CMD_DATA_MASK 0xff
+#define  CMD_TYPE_SHIFT24
+#define  CMD_TYPE_MASK 0xff
+#define XUSB_CFG_ARU_MBOX_DATA_OUT 0x0ec
+#define XUSB_CFG_ARU_MBOX_OWNER0x0f0
+#define  MBOX_OWNER_NONE   0
+#define  MBOX_OWNER_FW 1
+#define  MBOX_OWNER_SW 2
+#define XUSB_CFG_ARU_SMI_INTR  0x428
+#define  MBOX_SMI_INTR_FW_HANG BIT(1)
+#define  MBOX_SMI_INTR_EN  BIT(3)
+
+/* IPFS registers */
+#define IPFS_XUSB_HOST_CONFIGURATION_0 0x180
+#define  IPFS_EN_FPCI  BIT(0)
+#define IPFS_XUSB_HOST_INTR_MASK_0 0x188
+#define  IPFS_IP_INT_MASK  BIT(16)
+#define 

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

[Thierry Reding]

From: Thierry Reding 

Parameterize more parts of the driver and add support for Tegra210.

Cc: Greg Kroah-Hartman 
Cc: Mathias Nyman 
Signed-off-by: Thierry Reding 
---
 drivers/usb/host/xhci-tegra.c | 59 +--
 1 file changed, 51 insertions(+), 8 deletions(-)

diff --git a/drivers/usb/host/xhci-tegra.c b/drivers/usb/host/xhci-tegra.c
index ab6f9856c5c4..426e8d922cf4 100644
--- a/drivers/usb/host/xhci-tegra.c
+++ b/drivers/usb/host/xhci-tegra.c
@@ -159,6 +159,8 @@ struct tegra_xusb_soc {
unsigned int count;
} usb2, ulpi, hsic, usb3;
} ports;
+
+   bool scale_ss_clock;
 };
 
 struct tegra_xusb {
@@ -495,13 +497,19 @@ static void tegra_xusb_mbox_handle(struct tegra_xusb 
*tegra,
 
case MBOX_CMD_INC_SSPI_CLOCK:
case MBOX_CMD_DEC_SSPI_CLOCK:
-   err = tegra_xusb_set_ss_clk(tegra, msg->data * 1000);
-   if (err < 0)
-   rsp.cmd = MBOX_CMD_NAK;
-   else
+   if (tegra->soc->scale_ss_clock) {
+   err = tegra_xusb_set_ss_clk(tegra, msg->data * 1000);
+   if (err < 0)
+   rsp.cmd = MBOX_CMD_NAK;
+   else
+   rsp.cmd = MBOX_CMD_ACK;
+
+   rsp.data = clk_get_rate(tegra->ss_src_clk) / 1000;
+   } else {
rsp.cmd = MBOX_CMD_ACK;
+   rsp.data = msg->data;
+   }
 
-   rsp.data = clk_get_rate(tegra->ss_src_clk) / 1000;
break;
 
case MBOX_CMD_SET_BW:
@@ -783,9 +791,11 @@ static int tegra_xusb_clk_enable(struct tegra_xusb *tegra)
if (err < 0)
goto disable_fs_src;
 
-   err = tegra_xusb_set_ss_clk(tegra, TEGRA_XHCI_SS_HIGH_SPEED);
-   if (err < 0)
-   goto disable_hs_src;
+   if (tegra->soc->scale_ss_clock) {
+   err = tegra_xusb_set_ss_clk(tegra, TEGRA_XHCI_SS_HIGH_SPEED);
+   if (err < 0)
+   goto disable_hs_src;
+   }
 
return 0;
 
@@ -890,11 +900,44 @@ static const struct tegra_xusb_soc tegra124_soc = {
.hsic = { .offset = 6, .count = 2, },
.usb3 = { .offset = 0, .count = 2, },
},
+   .scale_ss_clock = true,
 };
 MODULE_FIRMWARE("nvidia/tegra124/xusb.bin");
 
+static const char * const tegra210_supply_names[] = {
+   "dvddio-pex",
+   "hvddio-pex",
+   "avdd-usb",
+   "avdd-pll-utmip",
+   "avdd-pll-uerefe",
+   "dvdd-pex-pll",
+   "hvdd-pex-pll-e",
+};
+
+static const struct tegra_xusb_phy_type tegra210_phy_types[] = {
+   { .name = "usb3", .num = 4, },
+   { .name = "usb2", .num = 4, },
+   { .name = "hsic", .num = 1, },
+};
+
+static const struct tegra_xusb_soc tegra210_soc = {
+   .firmware_file = "nvidia/tegra210/xusb.bin",
+   .supply_names = tegra210_supply_names,
+   .num_supplies = ARRAY_SIZE(tegra210_supply_names),
+   .phy_types = tegra210_phy_types,
+   .num_types = ARRAY_SIZE(tegra210_phy_types),
+   .ports = {
+   .usb2 = { .offset = 4, .count = 4, },
+   .hsic = { .offset = 8, .count = 1, },
+   .usb3 = { .offset = 0, .count = 4, },
+   },
+   .scale_ss_clock = false,
+};
+MODULE_FIRMWARE("nvidia/tegra210/xusb.bin");
+
 static const struct of_device_id tegra_xusb_of_match[] = {
{ .compatible = "nvidia,tegra124-xusb", .data = _soc },
+   { .compatible = "nvidia,tegra210-xusb", .data = _soc },
{ },
 };
 MODULE_DEVICE_TABLE(of, tegra_xusb_of_match);
-- 
2.7.1

--
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 v10 7/9] dt-bindings: usb: xhci-tegra: Add Tegra210 XUSB controller support

[Thierry Reding]

From: Thierry Reding 

Extend the Tegra XUSB controller device tree binding with Tegra210
support.

Signed-off-by: Thierry Reding 
---
 .../devicetree/bindings/usb/nvidia,tegra124-xusb.txt | 12 
 1 file changed, 12 insertions(+)

diff --git a/Documentation/devicetree/bindings/usb/nvidia,tegra124-xusb.txt 
b/Documentation/devicetree/bindings/usb/nvidia,tegra124-xusb.txt
index 79616f9268d8..d28295a3e55f 100644
--- a/Documentation/devicetree/bindings/usb/nvidia,tegra124-xusb.txt
+++ b/Documentation/devicetree/bindings/usb/nvidia,tegra124-xusb.txt
@@ -9,6 +9,7 @@ Required properties:
 - compatible: Must be:
   - Tegra124: "nvidia,tegra124-xusb"
   - Tegra132: "nvidia,tegra132-xusb", "nvidia,tegra124-xusb"
+  - Tegra210: "nvidia,tegra210-xusb"
 - reg: Must contain the base and length of the xHCI host registers, XUSB FPCI
   registers and XUSB IPFS registers.
 - reg-names: Must contain the following entries:
@@ -50,6 +51,15 @@ For Tegra124 and Tegra132:
 - hvdd-usb-ss-supply: High-voltage PCIe/USB3 power supply. Must supply 3.3 V.
 - hvdd-usb-ss-pll-e-supply: High-voltage PLLE power supply. Must supply 3.3 V.
 
+For Tegra210:
+- dvddio-pex-supply: PCIe/USB3 analog logic power supply. Must supply 1.05 V.
+- hvddio-pex-supply: High-voltage PCIe/USB3 power supply. Must supply 1.8 V.
+- avdd-usb-supply: USB controller power supply. Must supply 3.3 V.
+- avdd-pll-utmip-supply: UTMI PLL power supply. Must supply 1.8 V.
+- avdd-pll-uerefe-supply: PLLE reference PLL power supply. Must supply 1.05 V.
+- dvdd-pex-pll-supply: PCIe/USB3 PLL power supply. Must supply 1.05 V.
+- hvdd-pex-pll-e-supply: High-voltage PLLE power supply. Must supply 1.8 V.
+
 Optional properties:
 
 - phys: Must contain an entry for each entry in phy-names.
@@ -58,6 +68,8 @@ Optional properties:
   following PHYs are available:
   - Tegra124: usb2-0, usb2-1, usb2-2, hsic-0, hsic-1, usb3-0, usb3-1
   - Tegra132: usb2-0, usb2-1, usb2-2, hsic-0, hsic-1, usb3-0, usb3-1
+  - Tegra210: usb2-0, usb2-1, usb2-2, usb2-3, hsic-0, usb3-0, usb3-1, usb3-2,
+  usb3-3
 
 Example:
 
-- 
2.7.1

--
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 v10 5/9] phy: tegra: Add Tegra210 support

[Thierry Reding]

From: Thierry Reding 

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

Signed-off-by: Thierry Reding 
---
Changes in v9:
- expose more public API for direct use by the xHCI driver

 drivers/phy/tegra/Makefile|1 +
 drivers/phy/tegra/xusb-tegra210.c | 2041 +
 include/soc/tegra/fuse.h  |1 +
 3 files changed, 2043 insertions(+)
 create mode 100644 drivers/phy/tegra/xusb-tegra210.c

diff --git a/drivers/phy/tegra/Makefile b/drivers/phy/tegra/Makefile
index 31150b4337cd..898589238fd9 100644
--- a/drivers/phy/tegra/Makefile
+++ b/drivers/phy/tegra/Makefile
@@ -3,3 +3,4 @@ obj-$(CONFIG_PHY_TEGRA_XUSB) += phy-tegra-xusb.o
 phy-tegra-xusb-y += xusb.o
 phy-tegra-xusb-$(CONFIG_ARCH_TEGRA_124_SOC) += xusb-tegra124.o
 phy-tegra-xusb-$(CONFIG_ARCH_TEGRA_132_SOC) += xusb-tegra124.o
+phy-tegra-xusb-$(CONFIG_ARCH_TEGRA_210_SOC) += xusb-tegra210.o
diff --git a/drivers/phy/tegra/xusb-tegra210.c 
b/drivers/phy/tegra/xusb-tegra210.c
new file mode 100644
index ..194ed98a5577
--- /dev/null
+++ b/drivers/phy/tegra/xusb-tegra210.c
@@ -0,0 +1,2041 @@
+/*
+ * Copyright (c) 2014, NVIDIA CORPORATION.  All rights reserved.
+ * Copyright (C) 2015 Google, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope 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.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include "xusb.h"
+
+#define FUSE_SKU_CALIB_HS_CURR_LEVEL_PADX_SHIFT(x) \
+   ((x) ? (11 + ((x) - 1) * 6) : 0)
+#define FUSE_SKU_CALIB_HS_CURR_LEVEL_PAD_MASK 0x3f
+#define FUSE_SKU_CALIB_HS_TERM_RANGE_ADJ_SHIFT 7
+#define FUSE_SKU_CALIB_HS_TERM_RANGE_ADJ_MASK 0xf
+
+#define FUSE_USB_CALIB_EXT_RPD_CTRL_SHIFT 0
+#define FUSE_USB_CALIB_EXT_RPD_CTRL_MASK 0x1f
+
+#define XUSB_PADCTL_USB2_PAD_MUX 0x004
+#define XUSB_PADCTL_USB2_PAD_MUX_HSIC_PAD_TRK_SHIFT 16
+#define XUSB_PADCTL_USB2_PAD_MUX_HSIC_PAD_TRK_MASK 0x3
+#define XUSB_PADCTL_USB2_PAD_MUX_HSIC_PAD_TRK_XUSB 0x1
+#define XUSB_PADCTL_USB2_PAD_MUX_USB2_BIAS_PAD_SHIFT 18
+#define XUSB_PADCTL_USB2_PAD_MUX_USB2_BIAS_PAD_MASK 0x3
+#define XUSB_PADCTL_USB2_PAD_MUX_USB2_BIAS_PAD_XUSB 0x1
+
+#define XUSB_PADCTL_USB2_PORT_CAP 0x008
+#define XUSB_PADCTL_USB2_PORT_CAP_PORTX_CAP_HOST(x) (0x1 << ((x) * 4))
+#define XUSB_PADCTL_USB2_PORT_CAP_PORTX_CAP_MASK(x) (0x3 << ((x) * 4))
+
+#define XUSB_PADCTL_SS_PORT_MAP 0x014
+#define XUSB_PADCTL_SS_PORT_MAP_PORTX_INTERNAL(x) (1 << (((x) * 5) + 4))
+#define XUSB_PADCTL_SS_PORT_MAP_PORTX_MAP_SHIFT(x) ((x) * 5)
+#define XUSB_PADCTL_SS_PORT_MAP_PORTX_MAP_MASK(x) (0x7 << ((x) * 5))
+#define XUSB_PADCTL_SS_PORT_MAP_PORTX_MAP(x, v) (((v) & 0x7) << ((x) * 5))
+
+#define XUSB_PADCTL_ELPG_PROGRAM1 0x024
+#define XUSB_PADCTL_ELPG_PROGRAM1_AUX_MUX_LP0_VCORE_DOWN (1 << 31)
+#define XUSB_PADCTL_ELPG_PROGRAM1_AUX_MUX_LP0_CLAMP_EN_EARLY (1 << 30)
+#define XUSB_PADCTL_ELPG_PROGRAM1_AUX_MUX_LP0_CLAMP_EN (1 << 29)
+#define XUSB_PADCTL_ELPG_PROGRAM1_SSPX_ELPG_VCORE_DOWN(x) (1 << (2 + (x) * 3))
+#define XUSB_PADCTL_ELPG_PROGRAM1_SSPX_ELPG_CLAMP_EN_EARLY(x) \
+   (1 << (1 + (x) * 3))
+#define XUSB_PADCTL_ELPG_PROGRAM1_SSPX_ELPG_CLAMP_EN(x) (1 << ((x) * 3))
+
+#define XUSB_PADCTL_USB3_PAD_MUX 0x028
+#define XUSB_PADCTL_USB3_PAD_MUX_PCIE_IDDQ_DISABLE(x) (1 << (1 + (x)))
+#define XUSB_PADCTL_USB3_PAD_MUX_SATA_IDDQ_DISABLE(x) (1 << (8 + (x)))
+
+#define XUSB_PADCTL_USB2_BATTERY_CHRG_OTGPADX_CTL1(x) (0x084 + (x) * 0x40)
+#define XUSB_PADCTL_USB2_BATTERY_CHRG_OTGPAD_CTL1_VREG_LEV_SHIFT 7
+#define XUSB_PADCTL_USB2_BATTERY_CHRG_OTGPAD_CTL1_VREG_LEV_MASK 0x3
+#define XUSB_PADCTL_USB2_BATTERY_CHRG_OTGPAD_CTL1_VREG_FIX18 (1 << 6)
+
+#define XUSB_PADCTL_USB2_OTG_PADX_CTL0(x) (0x088 + (x) * 0x40)
+#define XUSB_PADCTL_USB2_OTG_PAD_CTL0_PD_ZI (1 << 29)
+#define XUSB_PADCTL_USB2_OTG_PAD_CTL0_PD2 (1 << 27)
+#define XUSB_PADCTL_USB2_OTG_PAD_CTL0_PD (1 << 26)
+#define XUSB_PADCTL_USB2_OTG_PAD_CTL0_HS_CURR_LEVEL_SHIFT 0
+#define XUSB_PADCTL_USB2_OTG_PAD_CTL0_HS_CURR_LEVEL_MASK 0x3f
+
+#define XUSB_PADCTL_USB2_OTG_PADX_CTL1(x) (0x08c + (x) * 0x40)
+#define XUSB_PADCTL_USB2_OTG_PAD_CTL1_RPD_CTRL_SHIFT 26
+#define XUSB_PADCTL_USB2_OTG_PAD_CTL1_RPD_CTRL_MASK 0x1f
+#define XUSB_PADCTL_USB2_OTG_PAD_CTL1_TERM_RANGE_ADJ_SHIFT 3
+#define XUSB_PADCTL_USB2_OTG_PAD_CTL1_TERM_RANGE_ADJ_MASK 0xf
+#define 

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

[Alan Stern]

On Wed, 2 Mar 2016, Sedat Dilek wrote:

> On 3/1/16, Alan Stern  wrote:
> > On Tue, 1 Mar 2016, Sedat Dilek wrote:
> >
> >> On Tue, Oct 13, 2015 at 2:57 AM, Steven Rostedt 
> >> wrote:
> >> > On Sat, 3 Oct 2015 12:05:42 +0200
> >> > Sedat Dilek  wrote:
> >> >
> >> >> So, at the beginning... dunno WTF is causing the problems - no
> >> >> workaround for CLANG.
> >> >
> >> > Probably need to compile with gcc and with clang and look at the binary
> >> > differences. Or at least what objdump shows.
> >> >
> >>
> >> [ Hope to address this issue to the correct people - CCed some people
> >> I taped on their nerves ]
> >>
> >> Not sure if I should open a new thread?
> >> Please, some clear statements on this.
> >> Thanks.
> >>
> >> The issue is still visible and alive.

I think it would be worthwhile to doublecheck the time at which
interrupts get disabled.  Sedat, please try your plug/unplug the USB
mouse test with the patch below.

Alan Stern



Index: usb-4.4/drivers/hid/usbhid/hid-core.c
===
--- usb-4.4.orig/drivers/hid/usbhid/hid-core.c
+++ usb-4.4/drivers/hid/usbhid/hid-core.c
@@ -1393,8 +1393,11 @@ static void usbhid_disconnect(struct usb
 
 static void hid_cancel_delayed_stuff(struct usbhid_device *usbhid)
 {
+   if (raw_irqs_disabled())  pr_info("usbhid irqs disabled A\n");
del_timer_sync(>io_retry);
+   if (raw_irqs_disabled())  pr_info("usbhid irqs disabled B\n");
cancel_work_sync(>reset_work);
+   if (raw_irqs_disabled())  pr_info("usbhid irqs disabled C\n");
 }
 
 static void hid_cease_io(struct usbhid_device *usbhid)

--
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] usb:super speed warm reset rejudge

[Alan Stern]

On Fri, 4 Mar 2016, l00229106 wrote:

> Some super speed device, insert the u3 port, sometimes link is in the
> Compliance Mode State(0x340), and then satisfy hub_port_warm_reset_required
> conditions, the software will perform a warm reset, u3 PORTSC becomes
> 0x2a1203. In hub_port_reset function, it will clear
> USB_PORT_FEAT_C_CONNECTION by usb_clear_port_feature. Finally, the u3
> PORTSC become 0x1203 and super speed device can not be recognized.
> 
> The patch can solve it. When the software warm reset, it judge Whether
> the u3 endpoint in the enabled and connected state. if they are, we set
> connect_change = 1. We verify the patch and can correctly identify super
> speed devices.
> 
> Signed-off-by: l00229106 
> ---
>  drivers/usb/core/hub.c | 12 +++-
>  1 file changed, 11 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
> index 350dcd9..039c4e9 100644
> --- a/drivers/usb/core/hub.c
> +++ b/drivers/usb/core/hub.c
> @@ -5037,8 +5037,18 @@ static void port_event(struct usb_hub *hub, int port1)
>   usb_reset_device(udev);
>   usb_unlock_device(udev);
>   usb_lock_port(port_dev);
> - connect_change = 0;
>   }
> +
> + ret = hub_port_status(hub, i,
> + , );
> + if (ret < 0)
> + return;
> +
> + if ((portstatus & USB_PORT_STAT_CONNECTION) && !udev &&
> + portstatus & USB_PORT_STAT_ENABLE)
> + connect_change = 1;

You should only test for USB_PORT_STAT_CONNECTION.  It doesn't matter
whether USB_PORT_STAT_ENABLE is set; either way, there has been a 
connect-status change.

> + else
> + connect_change = 0;
>   }
>  
>   if (connect_change)

Aside from the compiler errors found by the kbuild robot, this patch 
was added in the wrong place.  It should come here instead:

if (hub_port_warm_reset_required(hub, port1, portstatus)) {
dev_dbg(_dev->dev, "do warm reset\n");
if (!udev || !(portstatus & USB_PORT_STAT_CONNECTION)
|| udev->state == USB_STATE_NOTATTACHED) {
if (hub_port_reset(hub, port1, NULL,
HUB_BH_RESET_TIME, true) < 0)
hub_port_disable(hub, port1, 1);
+   else {
+   ...
+   }
} else {

because the new code gets executed only when udev is NULL.

Alan Stern

--
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: some questions about PM enable with usb driver

[Alan Stern]

On Fri, 4 Mar 2016, yoma sophian wrote:

> hi Alan and Peter:
> >>
> >> Backtrace:
> >> [] (ehci_handle_start_intr_unlinks [ehci_hcd]) from
> >> [] (ehci_bus_suspend+0x388/0x464 [ehci_hcd])
> >
> > Since there aren't any devices registered on the USB bus yet,
> > ehci_handle_start_intr_unlink() should do nothing.  It iterates over
> > ehci->intr_unlink, but that list should be empty.
> Per Alan's kind reminding, I found my problem comes from improper
> initialization of intr_unlink ^^
> 
> BTW, when I disable BH support in hcd driver.
> I get below recursion of spin lock sometimes.
> Did I missing anything once disable BH?

Yes, you missed a very important fact: ehci-hcd _requires_ BH support!

Alan Stern

--
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: Page allocation failure (order 7) in UAS code

[Yves-Alexis Perez]

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

I guess it can also be CC: stable@ since it started in 4.4.

Regards,
-- 
Yves-Alexis

--
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] USB changes for v4.6

[Felipe Balbi]

Hi Greg,

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

Let me know if you want anything to be changed

cheers

The following changes since commit 7b05d3b37437f8d50a75545a0fd56ee585c58821:

  Merge tag 'usb-ci-v4.6-rc1' of 
git://git.kernel.org/pub/scm/linux/kernel/git/peter.chen/usb into usb-next 
(2016-03-01 16:33:53 -0800)

are available in the git repository at:

  http://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git tags/usb-for-v4.6

for you to fetch changes up to 0561f77e2db9e72dc32e4f82b56fca8ba6b31171:

  usb: gadget: f_acm: Fix configfs attr name (2016-03-04 15:14:50 +0200)


usb changes for v4.6 merge window

This is almost all under drivers/usb/dwc2/. Many
changes to the host side implementation of dwc2 have
been done by Douglas Anderson.

We also have USB 3.1 support added to the Gadget
Framework and, because of that work, dwc3 got
support to Synopsys new DWC_usb31 IP core.

Other than these 2 important series, we also have
the usual collection of non-critical fixes,
Documentation updates, and minor changes all over
the place.


Alexey Khoroshilov (1):
  usb: gadget: bdc_udc: fix race condition in bdc_udc_exit()

Amitoj Kaur Chawla (1):
  usb: dwc2: Use kmem_cache_free()

Antti Seppälä (1):
  usb: dwc2: Add support for Lantiq ARX and XRX SoCs

Arnd Bergmann (8):
  usb: gadget: pxa25x_udc: move register definitions from arch
  usb: gadget: pxa25x_udc cleanup
  usb: gadget: pxa25x_udc: use readl/writel for mmio
  usb: fsl: drop USB_FSL_MPH_DR_OF Kconfig symbol
  usb: isp1301-omap: mark power_up as __maybe_unused
  usb: musb: use %pad format string from dma_addr_t
  usb: musb/ux500: remove duplicate check for dma_is_compatible
  usb: gadget: pxa25x_udc: document endianess better

Bjorn Helgaas (1):
  usb: phy: phy-am335x: remove include of regulator/consumer.h

Dan Carpenter (1):
  usb: gadget: f_midi: missing unlock on error path

Douglas Anderson (21):
  usb: dwc2: rockchip: Make the max_transfer_size automatic
  usb: dwc2: host: Get aligned DMA in a more supported way
  usb: dwc2: host: Set host_rx_fifo_size to 525 for rk3066
  usb: dwc2: host: Avoid use of chan->qh after qh freed
  usb: dwc2: host: Always add to the tail of queues
  usb: dwc2: host: fix split transfer schedule sequence
  usb: dwc2: host: Add scheduler tracing
  usb: dwc2: host: Add a delay before releasing periodic bandwidth
  usb: dwc2: host: Giveback URB in tasklet context
  usb: dwc2: host: Properly set the HFIR
  usb: dwc2: host: There's not really a TT for the root hub
  usb: dwc2: host: Use periodic interrupt even with DMA
  usb: dwc2: host: Rename some fields in struct dwc2_qh
  usb: dwc2: host: Reorder things in hcd_queue.c
  usb: dwc2: host: Split code out to make dwc2_do_reserve()
  usb: dwc2: host: Add scheduler logging for missed SOFs
  usb: dwc2: host: Manage frame nums better in scheduler
  usb: dwc2: host: Add dwc2_hcd_get_future_frame_number() call
  usb: dwc2: host: Properly set even/odd frame
  usb: dwc2: host: Totally redo the microframe scheduler
  usb: dwc2: host: If using uframe scheduler, end splits better

Du, Changbin (1):
  usb: f_fs: avoid race condition with ffs_epfile_io_complete

Emilio López (1):
  usb: musb: sunxi: support module autoloading

Felipe F. Tonello (1):
  usb: gadget: f_midi: remove useless midi reference from port struct

John Youn (22):
  usb: ch9: Add size macro for SSP dev cap descriptor
  usb: gadget: Add gadget_is_superspeed_plus()
  usb: gadget: composite: Return bcdUSB 0x0310
  usb: gadget: composite: Return SSP Dev Cap descriptor
  usb: gadget: Update usb_assign_descriptors for SuperSpeedPlus
  usb: gadget: Update function for SuperSpeedPlus
  usb: gadget: Update config for SuperSpeedPlus
  usb: gadget: composite: Count configs for SuperSpeedPlus
  usb: gadget: composite: Add function to get descriptors
  usb: gadget: composite: Write SuperSpeedPlus config descriptors
  usb: gadget: composite: Configure the usb_ep for SuperSpeedPlus
  usb: gadget: composite: Update debug message for SuperSpeedPlus
  usb: gadget: f_mass_storage: Enable SuperSpeedPlus
  usb: dwc3: DWC_usb31 controller check
  usb: dwc3: Update register fields for SuperSpeedPlus
  usb: dwc3: Update speed checks for SuperSpeedPlus
  usb: dwc3: Update maximum_speed for SuperSpeedPlus
  usb: dwc3: Enable SuperSpeedPlus
  usb: dwc3: Validate the maximum_speed parameter
  usb: dwc2: Move register save and restore functions
  

Re: some questions about PM enable with usb driver

[yoma sophian]

hi Alan and Peter:
>>
>> Backtrace:
>> [] (ehci_handle_start_intr_unlinks [ehci_hcd]) from
>> [] (ehci_bus_suspend+0x388/0x464 [ehci_hcd])
>
> Since there aren't any devices registered on the USB bus yet,
> ehci_handle_start_intr_unlink() should do nothing.  It iterates over
> ehci->intr_unlink, but that list should be empty.
Per Alan's kind reminding, I found my problem comes from improper
initialization of intr_unlink ^^

BTW, when I disable BH support in hcd driver.
I get below recursion of spin lock sometimes.
Did I missing anything once disable BH?

appreciate all your kind help,


[] (_raw_spin_lock_irqsave) from []
(ehci_urb_enqueue+0x160/0xdb4 [ehci_hcd])
 r5:ede81300 r4:c06d5af0
[] (ehci_urb_enqueue [ehci_hcd]) from []
(usb_hcd_submit_urb+0x778/0x878 [usbcore])
 r10:0001 r9:0200 r8:edf84c88 r7:0020 r6: r5:ede81300
 r4:edf84c80
[] (usb_hcd_submit_urb [usbcore]) from []
(usb_submit_urb+0x460/0x4b0 [usbcore])
 r10:0001 r9:0200 r8:0020 r7:0003 r6:2000 r5:edf77900
 r4:edf84c80
[] (usb_submit_urb [usbcore]) from []
(hub_irq+0xe8/0x118 [usbcore])
 r10:edf84c80 r9: r8:ede81480 r7:edfb200c r6:edf84c80 r5:
 r4:edfdc000
[] (hub_irq [usbcore]) from []
(__usb_hcd_giveback_urb+0x80/0xfc [usbcore])
 r6: r5:6193 r4:edf84c80 r3:bf005964
[] (__usb_hcd_giveback_urb [usbcore]) from []
(usb_hcd_giveback_urb+0x4c/0xec [usbcore])
 r6:ede81300 r5:edf84c80 r4:edf84c80 r3:ede82f80
[] (usb_hcd_giveback_urb [usbcore]) from []
(ehci_urb_done+0x88/0x8c [ehci_hcd])
 r8:ede81480 r7:edfb200c r6:ede81300 r5:edf84c80 r4: r3:c06d4000
[] (ehci_urb_done [ehci_hcd]) from []
(qh_completions+0x4c0/0x558 [ehci_hcd])
 r6:ff8d r5:edfb2000 r4:f0244240 r3:edfb200c
[] (qh_completions [ehci_hcd]) from []
(ehci_work+0x168/0x844 [ehci_hcd])
 r10:00010015 r9:ede81300 r8:ede81584 r7:ede81574 r6:edfb200c r5:edfb2000
 r4:ede81480
[] (ehci_work [ehci_hcd]) from []
(ehci_irq+0x490/0x4fc [ehci_hcd])
 r10:00010015 r9:ede81300 r8:c0785e90 r7: r6:0001 r5:
 r4:4009
[] (ehci_irq [ehci_hcd]) from []
(usb_hcd_irq+0x34/0x48 [usbcore])
--
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] usb:super speed warm reset rejudge

[Sergei Shtylyov]

Hello.

On 3/4/2016 11:28 AM, l00229106 wrote:


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

The patch can solve it. When the software warm reset, it judge Whether
the u3 endpoint in the enabled and connected state. if they are, we set
connect_change = 1. We verify the patch and can correctly identify super
speed devices.

Signed-off-by: l00229106 


   True name required here.


---
  drivers/usb/core/hub.c | 12 +++-
  1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 350dcd9..039c4e9 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -5037,8 +5037,18 @@ static void port_event(struct usb_hub *hub, int port1)
usb_reset_device(udev);
usb_unlock_device(udev);
usb_lock_port(port_dev);
-   connect_change = 0;
}
+
+   ret = hub_port_status(hub, i,
+   , );
+   if (ret < 0)
+   return;
+
+   if ((portstatus & USB_PORT_STAT_CONNECTION) && !udev &&
+   portstatus & USB_PORT_STAT_ENABLE)


   You enclosed the first & in parens but not the second?

[...]

MBR, Sergei

--
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] usb:super speed warm reset rejudge

[kbuild test robot]

Hi l00229106,

[auto build test ERROR on usb/usb-testing]
[also build test ERROR on v4.5-rc6 next-20160303]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improving the system]

url:
https://github.com/0day-ci/linux/commits/l00229106/usb-super-speed-warm-reset-rejudge/20160304-163718
base:   https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git 
usb-testing
config: x86_64-lkp (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   drivers/usb/core/hub.c: In function 'port_event':
>> drivers/usb/core/hub.c:5104:3: error: 'ret' undeclared (first use in this 
>> function)
  ret = hub_port_status(hub, i,
  ^
   drivers/usb/core/hub.c:5104:3: note: each undeclared identifier is reported 
only once for each function it appears in
>> drivers/usb/core/hub.c:5104:30: error: 'i' undeclared (first use in this 
>> function)
  ret = hub_port_status(hub, i,
 ^

vim +/ret +5104 drivers/usb/core/hub.c

  5098  usb_lock_device(udev);
  5099  usb_reset_device(udev);
  5100  usb_unlock_device(udev);
  5101  usb_lock_port(port_dev);
  5102  }
  5103  
> 5104  ret = hub_port_status(hub, i,
  5105  , );
  5106  if (ret < 0)
  5107  return;

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data

Re: usb: musb: tx fifo flush warning

[John Ogness]

On 2016-03-04, John Ogness  wrote:
> Using v4.5-rc6, I modified musb_h_tx_flush_fifo() to allow infinite
> looping and kept a log of the number of loops that were executed. For
> my test I am regularly seeing 3000-3200 loops (with a max so far of
> 3289). Since there used to be an msleep() in the loop, I never hit the
> warnings before.
>
> With my board, 3200 loops takes about 950us. Perhaps the msleep()
> should be reinserted, but with a retry count of only 3 before aborting
> with the warning.

Sorry, since musb_h_tx_flush_fifo() can run in interrupt context,
obviously an msleep() cannot be used. It seems increasing the retry
count may be the only option here. Maybe 5000?

John Ogness
--
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: usb: musb: tx fifo flush warning

[John Ogness]

On 2016-03-03, John Ogness  wrote:
>>> Using next-20160302 I can very reliably hit this warning on an
>>> AM335x BeagleBone by playing a short audio file over USB-Audio:
>>> 
>>> $ aplay -Dplughw:1,0 -r 44100 -c 2 -f S16_LE 
>>> /usr/share/sounds/alsa/Front_Center.wav
>>> 
>>> $ aplay -l
>>>  List of PLAYBACK Hardware Devices 
>>> card 1: Audio [USB Audio], device 0: USB Audio [USB Audio]
>>>   Subdevices: 1/1
>>>   Subdevice #0: subdevice #0
>>> 
>>> The audio file is part of the alsa-utils package. The USB-Audio
>>> device is never disconnected. Simply playing the file triggers the
>>> warning. Any hints/suggestions how I should debug this?
>>
>> In general, it seems this tx fifo flush error has been there for
>> years, it happens when tearing down an active endpoint in some
>> unknown conditions. But I haven't seen a such case in which musb
>> stops working.
>
> Actually, I am tracking down an issue where musb _does_ stop
> working. With the above "aplay" example, I can reproduce a hang with the
> musb on v3.19 and v4.0. Sometimes it takes up to an hour to reproduce
> the hang, so I am slowly moving to newer kernels to see how far I can
> reproduce the hang.

There was a lot of great work done on musb between v4.0 and v4.1. This
seems to have fixed the musb hang. With v4.1 I am not able to reproduce
the problem. Great job!

> I have not been able to reproduce a hang with next-20160302 (yet?),
> but I do get your warning and the backtrace looks very similar to what
> I see in the hang situation on the older kernel versions.

Using v4.5-rc6, I modified musb_h_tx_flush_fifo() to allow infinite
looping and kept a log of the number of loops that were executed. For my
test I am regularly seeing 3000-3200 loops (with a max so far of
3289). Since there used to be an msleep() in the loop, I never hit the
warnings before.

With my board, 3200 loops takes about 950us. Perhaps the msleep() should
be reinserted, but with a retry count of only 3 before aborting with the
warning.

John Ogness
--
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: some questions about PM enable with usb driver

[Peter Chen]

On Thu, Mar 03, 2016 at 11:16:11PM +0800, yoma sophian wrote:
> hi all:
> When I porting my platform ehci driver on kernel v4.1,
> I get back trace like below without plug in any device and just insert
> usb-common.ko, usbcore.ko and ehci-hcd.ko.
> (and detail is show in the attachment)
> 
> It seems caused by the PM related thread that is wakened up, even
> there is no device plug in and step in null pointer.
> Is there any callback function or flag in ehci-platform.c that we
> should check that will trigger the related PM work thread?
> 
> ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
>   
> bus: 'platform': add driver Platform-ehci 
>
> bus: 'platform': driver_probe_device: matched device fc1f.ehci with 
> driver Platform-ehci 
> bus: 'platform': really_probe: probing driver Platform-ehci with device 
> fc1f.ehci
> [USB] 2015-04-16v2 pdev : fc1f.ehci   
>   
> Platform-ehci fc1f.ehci: Platform EHCI
> 
> Platform-ehci fc1f.ehci: new USB bus registered, assigned bus number 1
>
> Platform-ehci fc1f.ehci: irq 10, io mem 0xfc1f mapped f023e000
>
> Platform-ehci fc1f.ehci: USB 2.0 started, EHCI 1.00, overcurrent ignored  
>
> device: 'ep_00': device_add   
>   


> PM: Adding info for No Bus:ep_00  
>   
> driver: 'Platform-ehci': driver_bound: bound to device 'fc1f.ehci'
>
> bus: 'platform': really_probe: bound device fc1f.ehci to driver 
> Platform-ehci

Why the probe for fc1f.ehci is called twice? Do you write the same
controller address for both controller at dts?

Peter
> bus: 'usb': add driver usb-storage
>   
> usbcore: registered new interface driver usb-storage  
>   
> Unable to handle kernel NULL pointer dereference at virtual address   
>   
> pgd = c0004000
>   
> [] *pgd=  
>   
> 
> 
>  SMP Send Stop Other CPU! 
>   
> 
> 
> CPU1: stopping
>   
> Process swapper/1 (pid: 0, stack limit = 0xee934210)  
>   
> CPU: 1 PID: 0 Comm: swapper/1 Tainted: G   O4.1.10+ #4
>   
> Hardware name: Platform-Cortex A9 
>
> task: ee905a00 ti: ee934000 task.ti: ee934000 
>   
> PC is at arch_cpu_idle+0x40/0x4c  
>   
> LR is at arch_cpu_idle+0x3c/0x4c  
>   
> pc : []lr : []psr: 6113   
>   
> sp : ee935fb0  ip : ee935fb0  fp : ee935fbc   
>   
> r10: c06ea5a0  r9 : c06ea5a0  r8 : c04b7e2c   
>   
> r7 : ee935fc0  r6 : c06ce344  r5 : 0015  r4 : ee934000
>   
> r3 : c06eace8  r2 :   r1 :   r0 : 
>   
> Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel   
>   
> Control: 10c5387d  Table: 3df2404a  DAC: 0015 
>   
> CPU: 1 PID: 0 Comm: swapper/1 Tainted: G   O

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

[Peter Chen]

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

Extra whitespace before mxs_phy->tx_reg_set.

> + writel(phytx, base + HW_USBPHY_TX);
> + }
> +}
> +
>  static int mxs_phy_hw_init(struct mxs_phy *mxs_phy)
>  {
>   int ret;
> @@ -214,6 +235,8 @@ static int mxs_phy_hw_init(struct mxs_phy *mxs_phy)
>   if (mxs_phy->data->flags & MXS_PHY_NEED_IP_FIX)
>   writel(BM_USBPHY_IP_FIX, base + HW_USBPHY_IP_SET);
>  
> + mxs_phy_tx_init(mxs_phy);
> +
>   return 0;
>  }
>  
> @@ -400,6 +423,8 @@ static int mxs_phy_suspend(struct usb_phy *x, int suspend)
>   writel(BM_USBPHY_CTRL_CLKGATE,
>  x->io_priv + HW_USBPHY_CTRL_CLR);
>   writel(0, x->io_priv + HW_USBPHY_PWD);
> +
> + mxs_phy_tx_init(mxs_phy);

Afaik, the register content will not be changed during PHY
suspend/resume operation.

-- 

Best Regards,
Peter Chen
--
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 4/4] leds: core: add support for RGB LED's

[Jacek Anaszewski]

On 03/01/2016 10:36 PM, Heiner Kallweit wrote:

Export a function to convert HSV color values to RGB.
It's intended to be called by drivers for RGB LEDs.

Signed-off-by: Heiner Kallweit 
---
v2:
- move hsv -> rgb conversion to separate file
- remove flag LED_DEV_CAP_RGB
v3:
- call led_hsv_to_rgb only if LED_DEV_CAP_HSV is set
   This is needed in cases when we have monochrome and color LEDs
   as well in a system.
v4:
- Export led_hsv_to_rgb and let the device driver call it instead
   of doing the conversion in the core
v5:
- don't ignore led_cdev->brightness_get silently if LED_DEV_CAP_RGB
   is set but warn
---
  drivers/leds/led-class.c|  7 +++
  drivers/leds/led-rgb-core.c | 36 
  include/linux/leds.h|  8 
  3 files changed, 51 insertions(+)

diff --git a/drivers/leds/led-class.c b/drivers/leds/led-class.c
index 8a3748a..a4b144e 100644
--- a/drivers/leds/led-class.c
+++ b/drivers/leds/led-class.c
@@ -193,6 +193,13 @@ int led_classdev_register(struct device *parent, struct 
led_classdev *led_cdev)
char name[64];
int ret;

+   /*
+* for now reading back the color is not supported as multiple
+* HSV -> RGB -> HSV conversions may distort the color due to
+* rounding issues in the conversion algorithm
+*/


Does the "for now" mean that you plan on supporting it in the future?


+   WARN_ON(led_cdev->flags & LED_DEV_CAP_RGB && led_cdev->brightness_get);
+


Could you move this warning to the line 216?


ret = led_classdev_next_name(led_cdev->name, name, sizeof(name));
if (ret < 0)
return ret;
diff --git a/drivers/leds/led-rgb-core.c b/drivers/leds/led-rgb-core.c
index f6591f1..2b18d4c 100644
--- a/drivers/leds/led-rgb-core.c
+++ b/drivers/leds/led-rgb-core.c
@@ -38,3 +38,39 @@ enum led_brightness led_confine_brightness(struct 
led_classdev *led_cdev,
return brightness |
   min(value & LED_BRIGHTNESS_MASK, led_cdev->max_brightness);
  }
+
+enum led_brightness led_hsv_to_rgb(enum led_brightness hsv)
+{
+   int h = min_t(int, (hsv >> 16) & 0xff, 251);
+   int s = (hsv >> 8) & 0xff;
+   int v = hsv & 0xff;
+   int f, p, q, t, r, g, b;
+
+   if (!v)
+   return 0;
+   if (!s)
+   return (v << 16) + (v << 8) + v;
+
+   f = DIV_ROUND_CLOSEST((h % 42) * 255, 42);
+   p = v - DIV_ROUND_CLOSEST(s * v, 255);
+   q = v - DIV_ROUND_CLOSEST(f * s * v, 255 * 255);
+   t = v - DIV_ROUND_CLOSEST((255 - f) * s * v, 255 * 255);
+
+   switch (h / 42) {
+   case 0:
+   r = v; g = t; b = p; break;
+   case 1:
+   r = q; g = v; b = p; break;
+   case 2:
+   r = p; g = v; b = t; break;
+   case 3:
+   r = p; g = q; b = v; break;
+   case 4:
+   r = t; g = p; b = v; break;
+   case 5:
+   r = v; g = p; b = q; break;
+   }
+
+   return (r << 16) + (g << 8) + b;
+}
+EXPORT_SYMBOL_GPL(led_hsv_to_rgb);
diff --git a/include/linux/leds.h b/include/linux/leds.h
index bbf24bb..82b3477 100644
--- a/include/linux/leds.h
+++ b/include/linux/leds.h
@@ -226,6 +226,14 @@ static inline bool led_sysfs_is_disabled(struct 
led_classdev *led_cdev)
return led_cdev->flags & LED_SYSFS_DISABLE;
  }

+/**
+ * led_hsv_to_rgb - convert a hsv color value to rgb color model
+ * @hsv: the hsv value to convert
+ *
+ * Returns: the resulting rgb value
+ */
+enum led_brightness led_hsv_to_rgb(enum led_brightness hsv);
+
  /*
   * LED Triggers
   */




--
Best regards,
Jacek Anaszewski
--
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 1/4] leds: core: add generic support for RGB Color LED's

[Jacek Anaszewski]

Hi Heiner,

Thanks for the updated version. Some nitpicking below.

Please remove "Color" from the patch title.

On 03/01/2016 10:26 PM, Heiner Kallweit wrote:

Add generic support for RGB Color LED's.

   ^^^
Ditto.



Basic idea is to use enum led_brightness also for the hue and saturation
color components.This allows to implement the color extension w/o
changes to struct led_classdev.

Select LEDS_RGB to enable building drivers using the RGB extension.

Flag LED_SET_HUE_SAT allows to specify that hue / saturation
should be overridden even if the provided values are zero.

Some examples for writing values to /sys/class/leds//brightness:
(now also hex notation can be used)

255 -> set full brightness and keep existing color if set
0 -> switch LED off but keep existing color so that it can be restored
  if the LED is switched on again later
0x100 -> switch LED off and set also hue and saturation to 0
0x00 -> set full brightness, full saturation and set hue to 0 (red)

Signed-off-by: Heiner Kallweit 
---
v2:
- move extension-specific code into a separate source file and
   introduce config symbol LEDS_HSV for it
- create separate patch for the extension to sysfs
- use variable name led_cdev as in the rest if the core
- rename to_hsv to led_validate_brightness
- rename LED_BRIGHTNESS_SET_COLOR to LED_SET_HSV
- introduce helper is_off for checking whether V part
   of a HSV value is zero
v3:
- change Kconfig to use depend instead of select, add help message,
   and change config symbol to LEDS_COLOR
- change LED core object file name in Makefile
- rename flag LED_SET_HSV to LED_SET_COLOR
- rename is_off to led_is_off
- rename led_validate-brightness to led_confine_brightness
- rename variable in led_confine_brightness
- add dummy enum led_brightness value to enforce 32bit enum
- rename led-hsv-core.c to led-color-core.c
- move check of provided brightness value to led_confine_brightness
v4:
- change config symbol name to LEDS_RGB
- change name of new file to led-rgb-core.c
- factor out part of led_confine_brightness
- change led_is_off to __is_set_brightness
- in led_set_software_blink pass led_cdev->max_brightness instead of LED_FULL
- rename LED_SET_COLOR to LED_SET_HUE_SAT
v5:
- change "RGB Color LED" to "RGB LED" in Kconfig
- move definition of LED_HUE_SAT_MASK to drivers/leds/leds.h
- rename LED_DEV_CAP_HSV to LED_DEV_CAP_RGB
---
  drivers/leds/Kconfig| 11 +++
  drivers/leds/Makefile   |  4 +++-
  drivers/leds/led-class.c|  2 +-
  drivers/leds/led-core.c | 16 +---
  drivers/leds/led-rgb-core.c | 40 
  drivers/leds/leds.h | 18 ++
  include/linux/leds.h|  9 +
  7 files changed, 91 insertions(+), 9 deletions(-)
  create mode 100644 drivers/leds/led-rgb-core.c

diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index 7f940c2..5b1c852 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -13,6 +13,13 @@ menuconfig NEW_LEDS

  if NEW_LEDS

+config LEDS_RGB
+   bool "RGB LED Support"
+   help
+This option enables support for RGB LED devices.
+Sysfs attribute brightness is interpreted as a HSV color value.
+For details see Documentation/leds/leds-class.txt.
+
  config LEDS_CLASS
tristate "LED Class Support"
help
@@ -29,6 +36,10 @@ config LEDS_CLASS_FLASH
  for the flash related features of a LED device. It can be built
  as a module.

+if LEDS_RGB
+comment "RGB LED drivers"
+endif # LEDS_RGB
+
  comment "LED drivers"

  config LEDS_88PM860X
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index e9d5309..cc3676f 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -1,6 +1,8 @@

  # LED Core
-obj-$(CONFIG_NEW_LEDS) += led-core.o
+obj-$(CONFIG_NEW_LEDS) += led-core-objs.o
+led-core-objs-y:= led-core.o
+led-core-objs-$(CONFIG_LEDS_RGB)   += led-rgb-core.o
  obj-$(CONFIG_LEDS_CLASS)  += led-class.o
  obj-$(CONFIG_LEDS_CLASS_FLASH)+= led-class-flash.o
  obj-$(CONFIG_LEDS_TRIGGERS)   += led-triggers.o
diff --git a/drivers/leds/led-class.c b/drivers/leds/led-class.c
index aa84e5b..007a5b3 100644
--- a/drivers/leds/led-class.c
+++ b/drivers/leds/led-class.c
@@ -53,7 +53,7 @@ static ssize_t brightness_store(struct device *dev,
if (ret)
goto unlock;

-   if (state == LED_OFF)
+   if (!__is_brightness_set(state))
led_trigger_remove(led_cdev);
led_set_brightness(led_cdev, state);

diff --git a/drivers/leds/led-core.c b/drivers/leds/led-core.c
index 3495d5d..e75b0c8 100644
--- a/drivers/leds/led-core.c
+++ b/drivers/leds/led-core.c
@@ -62,7 +62,7 @@ static void led_timer_function(unsigned long data)
}

brightness = led_get_brightness(led_cdev);
-   if (!brightness) {

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

[Jacek Anaszewski]

Hi Heiner,

Please split the sysfs-class-led part to a separate patch.

On 03/02/2016 08:31 PM, Heiner Kallweit wrote:

Document the color extension in Documentation/leds/leds-class.txt

Signed-off-by: Heiner Kallweit 
---
v2:
- introduced to patch series
v3:
- document extension in more detail
v4:
- Better explain why flag LED_SET_HUE_SAT is needed
v5:
- no changes
v6:
- add docu for this feature to Documentation/ABI/testing/sysfs-class-led
---
  Documentation/ABI/testing/sysfs-class-led | 11 +++
  Documentation/leds/leds-class.txt | 27 ++-
  2 files changed, 33 insertions(+), 5 deletions(-)

diff --git a/Documentation/ABI/testing/sysfs-class-led 
b/Documentation/ABI/testing/sysfs-class-led
index 3646ec8..20357d5 100644
--- a/Documentation/ABI/testing/sysfs-class-led
+++ b/Documentation/ABI/testing/
@@ -7,6 +7,17 @@ Description:
have hardware brightness support so will just be turned on for
non-zero brightness settings. The value is between 0 and
/sys/class/leds//max_brightness.
+   If a driver uses the RGB LED feature then this attribute is
+   interpreted as a HSV color model value:
+   <000F>
+   Usage of the least byte is identical to monochrome mode.
+   Saturation can be 0-255 and hue 0-251 (Colour circle is mapped
+   to 0-252). If hue and saturation both are 0 the current colour
+   is preserved and only the brightness is set. This ensures
+   backwards compatibility with monochrome mode, e.g. for
+   led_set_brightness() calls from triggers.
+   Flag F enables setting hue and saturation even if both are 0.
+   For details and examples see Documentation/leds/leds-class.txt

  What: /sys/class/leds//max_brightness
  Date: March 2006
diff --git a/Documentation/leds/leds-class.txt 
b/Documentation/leds/leds-class.txt
index d406d98..b1e4cba 100644
--- a/Documentation/leds/leds-class.txt
+++ b/Documentation/leds/leds-class.txt
@@ -8,6 +8,22 @@ LED is defined in max_brightness file. The brightness file 
will set the brightne
  of the LED (taking a value 0-max_brightness). Most LEDs don't have hardware
  brightness support so will just be turned on for non-zero brightness settings.

+If a driver uses the colour extension of the LED core then the brightness


s/colour/RGB/


+file can be used to set hue / saturation / value. The brightness value is
+interpreted as: <000F>
+Usage of the least byte is identical to monochrome mode. Saturation can be
+0-255 and hue 0-251 (Colour circle is mapped to 0-252).
+If hue and saturation both are 0 the current colour is preserved and only
+the brightness is set. This ensures backwards compatibility with monochrome
+mode, e.g. for led_set_brightness() calls from triggers.
+However we might want to have the option to set all HSV components, even
+if hue and saturation both are 0 (e.g. via brightness sysfs attribute).
+Use case: Set color to white (hue = 0 and saturation = 0).
+Therefore the default behaviour can be overridden with flag F 
(LED_SET_HUE_SAT).
+If this flag is set then hue and saturation are not checked for being 0 and
+the color components are set unconditionally. Example:
+0x01ff sets the LED to white color with full brightness.
+


I had to play a bit with RGB<->HSV conversion to get the flavour of
the HSV color model, and indeed, changing the brightness byte alone
influences only the intensity of the perceived color, despite that
all RGB components are changed. Effectively I find this description
sufficient.


  The class also introduces the optional concept of an LED trigger. A trigger
  is a kernel based source of led events. Triggers can either be simple or
  complex. A simple trigger isn't configurable and is designed to slot into
@@ -45,11 +61,12 @@ Is currently of the form:

  "devicename:colour:function"

-There have been calls for LED properties such as colour to be exported as
-individual led class attributes. As a solution which doesn't incur as much
-overhead, I suggest these become part of the device name. The naming scheme
-above leaves scope for further attributes should they be needed. If sections
-of the name don't apply, just leave that section blank.
+If the colour extension is used hsv / rgb can be used instead of a specific


s/colour/RGB/


+colour.  There have been calls for LED properties such as colour to be
+exported as individual led class attributes. As a solution which doesn't
+incur as much overhead, I suggest these become part of the device name.
+The naming scheme above leaves scope for further attributes should they be
+needed. If sections of the name don't apply, just leave that section blank.


  Brightness setting API



--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More 

[PATCH] usb:super speed warm reset rejudge

[l00229106]

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

The patch can solve it. When the software warm reset, it judge Whether
the u3 endpoint in the enabled and connected state. if they are, we set
connect_change = 1. We verify the patch and can correctly identify super
speed devices.

Signed-off-by: l00229106 
---
 drivers/usb/core/hub.c | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 350dcd9..039c4e9 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -5037,8 +5037,18 @@ static void port_event(struct usb_hub *hub, int port1)
usb_reset_device(udev);
usb_unlock_device(udev);
usb_lock_port(port_dev);
-   connect_change = 0;
}
+
+   ret = hub_port_status(hub, i,
+   , );
+   if (ret < 0)
+   return;
+
+   if ((portstatus & USB_PORT_STAT_CONNECTION) && !udev &&
+   portstatus & USB_PORT_STAT_ENABLE)
+   connect_change = 1;
+   else
+   connect_change = 0;
}
 
if (connect_change)
-- 
1.9.1

--
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/5] usb: gadget: f_midi: refactor state machine

[Clemens Ladisch]

Felipe Ferreri Tonello wrote:
> On 03/03/16 11:38, Clemens Ladisch wrote:
>> But in what way was the old state machine not "proper"?
>
> Because it didn't reflect all the correct and possible MIDI states

The whole point of the one-byte real-time messages is that they do not
affect the parsing of the surrounding MIDI stream.  So not making them
part of the state machine is the proper way of handling them.  (Also
see the flowchart in appendix A of the spec.)

> This patch doesn't change any functionality. But the important thing
> here is that it improves the driver maintainability [...]

Then I won't get in the way of this driver's maintainer.


Regards,
Clemens
--
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