Re: Audio I/O parameters

[Clemens Ladisch]

Alan Stern wrote:
> On Wed, 31 Jul 2013, James Stone wrote:
>> On Wed, Jul 31, 2013 at 4:48 PM, Alan Stern  
>> wrote:
>>> James, see what happens with this patch.  It will print a warning
>>> message in the system log every time it detects an underrun, but it
>>> won't cause an URB submission failure any more.
>>
>> OK - I will try it, however, it seems a bit like papering over the
>> cracks without really understanding what's causing the error..
>
> It seems likely that the error is caused by an SMI taking too much
> time.  At least, we seem to have ruled out everything else.  Besides,
> this change has to be made eventually in any case -- underruns can
> occur at any time, in principle, and they shouldn't cause the audio
> driver to fail.

Well, the failure is a bug in snd-usb-audio: when usb_submit_urb fails,
it should report the underrun so that the stream can be stopped and
restarted cleanly.  This would be done by the snd_pcm_stop() call in
endpoint.c which is currently commented out because of locking problems.


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] USBIP:stub_dev.c fixing string splitted into multiple line issue

[Dan Carpenter]

On Wed, Jul 31, 2013 at 10:26:15PM +0200, Julia Lawall wrote:
> On Wed, 31 Jul 2013, Kumar Gaurav wrote:
> 
> > Fixed  String splitted into multiple line issue using macro
> 
> I'm not an expert on this kind of style issue, but I prefer strings that 
> look like strings.
> 

Yeah.  This patch makes the code more abstract and harder to
understand.

regards,
dan carpenter

--
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/8] pl2303: fix+improve the divsor based baud rate encoding method

[Greg KH]

On Tue, Jul 30, 2013 at 09:49:05PM +0200, Frank Schäfer wrote:
> Based on the formula in the code description, Reinhard Max and me have
> investigated the devices behavior / functional principle of the divisor based
> baud rate encoding method.
> 
> It turned out, that (although beeing a good starting point) the current code 
> has
> some flaws. It doesn't work correctly for a wide range of baud rates and the
> divisor resolution can be improved. It also doesn't report the actually set 
> baud
> rate.

Please wrap your changelog comments at 72 columns, it's just nice, and
what git asks you to do...

> This patch fixes and improves the code for the divisor based baud rate 
> encoding
> method a lot. It can now be used for the whole range of baud rates from 46 
> baud
> to 24M baud with a very good divisor resolution and userspace can read back 
> the
> resulting baud rate.
> 
> It also documents the formula used for encoding and the hardware behavior
> (including special cases).
> 
> The basic algorithm, rounding and several code comments/explanations are
> provided by Reinhard Max.
> I've added some minor fixes, the handling of the special cases and further
> code/algorithm descriptions.
> 
> Signed-off-by: Frank Schäfer 
> Signed-off-by: Reinhard Max 
> ---
>  drivers/usb/serial/pl2303.c |   59 
> +++
>  1 Datei geändert, 49 Zeilen hinzugefügt(+), 10 Zeilen entfernt(-)
> 
> diff --git a/drivers/usb/serial/pl2303.c b/drivers/usb/serial/pl2303.c
> index 2448201..323dfa6 100644
> --- a/drivers/usb/serial/pl2303.c
> +++ b/drivers/usb/serial/pl2303.c
> @@ -3,6 +3,8 @@
>   *
>   * Copyright (C) 2001-2007 Greg Kroah-Hartman (g...@kroah.com)
>   * Copyright (C) 2003 IBM Corp.
> + * Copyright (C) 2009, 2013 Frank Schäfer 
> + * Copyright (C) 2013 Reinhard max 

Interesting.

I see Frank contributed back in 2009, which is fine.

But the "rules" for copyright on an existing file are generally well
known by people, and this patch doesn't cover that type of definition as
far as I can tell[1], so I'm not allowed to add these copyright lines to
the file, sorry :(

And you forgot to upper-case the last letter of your name :)

So, can you please resend this series, starting here (I've applied your
first patch), after fixing this up, and the changelog changes as I've
pointed out above, and the other comment you got on this series?

thanks,

greg k-h

[1] You need to have "created/modified" at least 1/3 of a file to be
considered a copyright owner in almost all jurisdictions that I know
of.  If you don't do that, I have been advised by my lawyer that I
can not add a copyright notice to a file.  If you disagree with
this, that's great, please have your IP lawyer contact me and I will
be glad to discuss it with them.
--
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: lsusb doesn't handle 32 bits Usage tags.

[Greg KH]

On Sun, Jul 07, 2013 at 09:32:55PM +0200, pchavent wrote:
> On Sun, 7 Jul 2013 10:37:59 -0700, Greg KH wrote:
> >On Sun, Jul 07, 2013 at 07:17:40PM +0200, pchavent wrote:
> >>Hi.
> >>
> >>lsusb doesn't handle 32 bits Usage tags.
> >>
> >>I've tried to do a patch but i'm not confident in its
> >>implementation.
> >
> >Do you have a HID descriptor with a 32bit usage tag?  I don't think
> >anyone has seen these before, are they new?
> >
> >thanks,
> >
> >greg k-h
> 
> Hi
> 
> Sorry, i sent you a wrong patch (i join a better one).
> 
> Indeed, i build a device that convert some pwm signals for flight
> simulation purpose. I would like to give several "Usage" for each
> way (standard joystick, plane simulation, helicopter simulation). So
> i have followed the examples in the "Universal Serial Bus HID Usage
> Tables" (appendix b page 145) [1].
> 
> I know that linux doesn't care about alternative usage tags, but for
> debugging my device i would like to be able to see a good Report
> Descriptor.

Thanks, now applied.

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: [RESEND PATCH v10 1/8] drivers: phy: add generic PHY framework

[Greg KH]

On Fri, Jul 26, 2013 at 06:19:16PM +0530, Kishon Vijay Abraham I wrote:
> +static int phy_get_id(void)
> +{
> + int ret;
> + int id;
> +
> + ret = ida_pre_get(&phy_ida, GFP_KERNEL);
> + if (!ret)
> + return -ENOMEM;
> +
> + ret = ida_get_new(&phy_ida, &id);
> + if (ret < 0)
> + return ret;
> +
> + return id;
> +}

ida_simple_get() instead?  And if you do that, you can get rid of this
function entirely.

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] usb: gadget: audio file: wake up sleep thread when device unbind

[Clemens Ladisch]

Qiao Zhou wrote:
> when usb audio device removes, it doesn't notify the ALSA read /
> write thread. due to no data transmitting any more, those threads
> wait for a long timeout(10s), then detects IO error. it causes
> long time blocking in upper layer read/write.
>
> to fix this issue, wake up potential sleep thread if necessary
> when audio unbind.

> + if (substream && substream->runtime && substream->runtime->twake)
> + wake_up(&substream->runtime->tsleep);

The PCM stream should be properly stopped, which automatically takes
care of notifying userspace.  See this code for an example:



> substream & pcm may still be used after audio unbind, and we
> should only set null to it in audio_pcm_close.

What happens when the application immediately tries to restart the
stream?  Many USB audio drivers set a "disconnected" flag to prevent
this, but I don't know if the gadget driver has races that would require
such a check.


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 2/4] USB: XHCI: mark no_sg_limit

[Greg Kroah-Hartman]

On Wed, Jul 31, 2013 at 09:40:26AM -0700, Sarah Sharp wrote:
> On Wed, Jul 31, 2013 at 06:51:47PM +0800, Ming Lei wrote:
> > This patch marks all xHCI controllers as no_sg_limit since
> > xHCI supports building packet from discontinuous buffers.
> > 
> > Cc: Sarah Sharp 
> > Signed-off-by: Ming Lei 
> 
> Acked-by: Sarah Sharp 

Is it a requirement that all xhci controllers support sg?  I know we are
starting to see other controllers (the platform code?) so would they
need to support this as well?

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 v2 6/8] usb: host: ohci-s3c2410 Use clk_prepare_enable/clk_disable_unprepare

[Greg KH]

On Wed, Jul 31, 2013 at 04:44:43PM -0400, Alan Stern wrote:
> On Wed, 31 Jul 2013, Tomasz Figa wrote:
> 
> > Alan, Greg,
> > 
> > On Tuesday 23 of July 2013 01:49:23 Tomasz Figa wrote:
> > > This patch modifies the ohci-s3c2410 driver to prepare and unprepare
> > > clocks in addition to enabling and disabling, since it is required
> > > by common clock framework.
> > > 
> > > Signed-off-by: Tomasz Figa 
> > > ---
> > >  drivers/usb/host/ohci-s3c2410.c | 8 
> > >  1 file changed, 4 insertions(+), 4 deletions(-)
> > > 
> > > diff --git a/drivers/usb/host/ohci-s3c2410.c
> > > b/drivers/usb/host/ohci-s3c2410.c index e125770..db096bf 100644
> > > --- a/drivers/usb/host/ohci-s3c2410.c
> > > +++ b/drivers/usb/host/ohci-s3c2410.c
> > > @@ -47,10 +47,10 @@ static void s3c2410_start_hc(struct platform_device
> > > *dev, struct usb_hcd *hcd)
> > > 
> > >   dev_dbg(&dev->dev, "s3c2410_start_hc:\n");
> > > 
> > > - clk_enable(usb_clk);
> > > + clk_prepare_enable(usb_clk);
> > >   mdelay(2);  /* let the bus clock stabilise */
> > > 
> > > - clk_enable(clk);
> > > + clk_prepare_enable(clk);
> > > 
> > >   if (info != NULL) {
> > >   info->hcd   = hcd;
> > > @@ -75,8 +75,8 @@ static void s3c2410_stop_hc(struct platform_device
> > > *dev) (info->enable_oc)(info, 0);
> > >   }
> > > 
> > > - clk_disable(clk);
> > > - clk_disable(usb_clk);
> > > + clk_disable_unprepare(clk);
> > > + clk_disable_unprepare(usb_clk);
> > >  }
> > > 
> > >  /* ohci_s3c2410_hub_status_data
> > 
> > Any chance to get your ack on this?
> 
> Sorry, this must have slipped past.  It's fine with me.

Acked-by: Greg Kroah-Hartman 
--
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] MAINTAINERS: Add separate section for USB NETWORKING DRIVERS

[Joe Perches]

There are several drivers in drivers/net/usb/ that
do not have specific MAINTAINERS that should have
emails forwarded to the linux-usb mailing list.

Add a section for those drivers.

Signed-off-by: Joe Perches 
---
> In the future, you do not need to send drivers/net/usb/ patches to me,
> netdev and the linux-usb mailing lists should be sufficient.

I should have done this in the first patch.
Oh well...

 MAINTAINERS | 5 +
 1 file changed, 5 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index d83f70f..4af7539 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8656,6 +8656,11 @@ T:   git git://git.alsa-project.org/alsa-kernel.git
 S: Maintained
 F: sound/usb/midi.*
 
+USB NETWORKING DRIVERS
+L: linux-usb@vger.kernel.org
+S: Odd Fixes
+F: drivers/net/usb/
+
 USB OHCI DRIVER
 M: Alan Stern 
 L: linux-usb@vger.kernel.org


--
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] MAINTAINERS: Add separate section for USB NETWORKING DRIVERS

[Greg KH]

On Thu, Aug 01, 2013 at 12:48:48AM -0700, Joe Perches wrote:
> There are several drivers in drivers/net/usb/ that
> do not have specific MAINTAINERS that should have
> emails forwarded to the linux-usb mailing list.
> 
> Add a section for those drivers.
> 
> Signed-off-by: Joe Perches 
> ---
> > In the future, you do not need to send drivers/net/usb/ patches to me,
> > netdev and the linux-usb mailing lists should be sufficient.
> 
> I should have done this in the first patch.
> Oh well...
> 
>  MAINTAINERS | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index d83f70f..4af7539 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -8656,6 +8656,11 @@ T: git git://git.alsa-project.org/alsa-kernel.git
>  S:   Maintained
>  F:   sound/usb/midi.*
>  
> +USB NETWORKING DRIVERS
> +L:   linux-usb@vger.kernel.org
> +S:   Odd Fixes
> +F:   drivers/net/usb/

But netdev is the one that applies these patches, not linux-usb, so this
isn't correct either.

sorry,

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 1/6] usb: host: add has_tdi_phy_lpm capability bit

[Matthieu CASTET]

Hi,

Le Wed, 31 Jul 2013 18:41:57 +0100,
Tuomas Tynkkynen  a écrit :

> The has_hostpc capability bit indicates that the host controller has
> the HOSTPC register extensions, but at the same time enables clock
> disabling power saving features with the PHY Low Power Clock Disable
> (PHCD) bit.
> 
> However, some host controllers have the HOSTPC extensions but don't
> support the low-power feature, so the PHCD bit must not be set on
> those controllers. Add a separate capability bit for the low-power
> feature instead, and change all existing users of has_hostpc to use
> this new capability bit.
> 
> The idea for this commit is taken from an old 2012 commit that never
> got merged ("disociate chipidea PHY low power suspend control from
> hostpc")
Note that because of the different register layout (see "add phy low
power suspend for older chipidea core" commit in the same series), we
should not set has_tdi_phy_lpm if has_hostpc == 0 with the current code.

May be you should have change the ehci->has_hostpc to (ehci->has_hostpc
&& ehci->has_tdi_phy_lpm).

BTW Alan make some comment on the commit :
http://marc.info/?l=linux-usb&m=133701342028213&w=2

They may apply to your commit.

> 
> Inspired-by: Matthieu CASTET 
> Signed-off-by: Tuomas Tynkkynen 
> ---
>  drivers/usb/chipidea/host.c |  1 +
>  drivers/usb/host/ehci-hub.c | 14 +++---
>  drivers/usb/host/ehci.h |  1 +
>  3 files changed, 9 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/usb/chipidea/host.c b/drivers/usb/chipidea/host.c
> index 40d0fda..9b3aaf1 100644
> --- a/drivers/usb/chipidea/host.c
> +++ b/drivers/usb/chipidea/host.c
> @@ -63,6 +63,7 @@ static int host_start(struct ci_hdrc *ci)
>   ehci = hcd_to_ehci(hcd);
>   ehci->caps = ci->hw_bank.cap;
>   ehci->has_hostpc = ci->hw_bank.lpm;
> + ehci->has_tdi_phy_lpm = ci->hw_bank.lpm;
>  
>   ret = usb_add_hcd(hcd, 0, 0);
>   if (ret)
> diff --git a/drivers/usb/host/ehci-hub.c b/drivers/usb/host/ehci-hub.c
> index 2b70277..8044a74 100644
> --- a/drivers/usb/host/ehci-hub.c
> +++ b/drivers/usb/host/ehci-hub.c
> @@ -183,7 +183,7 @@ static void ehci_adjust_port_wakeup_flags(struct
> ehci_hcd *ehci, spin_lock_irq(&ehci->lock);
>  
>   /* clear phy low-power mode before changing wakeup flags */
> - if (ehci->has_hostpc) {
> + if (ehci->has_tdi_phy_lpm) {
>   port = HCS_N_PORTS(ehci->hcs_params);
>   while (port--) {
>   u32 __iomem *hostpc_reg =
> &ehci->regs->hostpc[port]; @@ -217,7 +217,7 @@ static void
> ehci_adjust_port_wakeup_flags(struct ehci_hcd *ehci, }
>  
>   /* enter phy low-power mode again */
> - if (ehci->has_hostpc) {
> + if (ehci->has_tdi_phy_lpm) {
>   port = HCS_N_PORTS(ehci->hcs_params);
>   while (port--) {
>   u32 __iomem *hostpc_reg =
> &ehci->regs->hostpc[port]; @@ -309,7 +309,7 @@ static int
> ehci_bus_suspend (struct usb_hcd *hcd) }
>   }
>  
> - if (changed && ehci->has_hostpc) {
> + if (changed && ehci->has_tdi_phy_lpm) {
>   spin_unlock_irq(&ehci->lock);
>   msleep(5);  /* 5 ms for HCD to enter low-power
> mode */ spin_lock_irq(&ehci->lock);
> @@ -435,7 +435,7 @@ static int ehci_bus_resume (struct usb_hcd *hcd)
>   goto shutdown;
>  
>   /* clear phy low-power mode before resume */
> - if (ehci->bus_suspended && ehci->has_hostpc) {
> + if (ehci->bus_suspended && ehci->has_tdi_phy_lpm) {
>   i = HCS_N_PORTS(ehci->hcs_params);
>   while (i--) {
>   if (test_bit(i, &ehci->bus_suspended)) {
> @@ -788,7 +788,7 @@ static int ehci_hub_control (
>   goto error;
>  
>   /* clear phy low-power mode before resume */
> - if (ehci->has_hostpc) {
> + if (ehci->has_tdi_phy_lpm) {
>   temp1 = ehci_readl(ehci, hostpc_reg);
>   ehci_writel(ehci, temp1 &
> ~HOSTPC_PHCD, hostpc_reg);
> @@ -1031,12 +1031,12 @@ static int ehci_hub_control (
>  
>   /* After above check the port must be
> connected.
>* Set appropriate bit thus could put phy
> into low power
> -  * mode if we have hostpc feature
> +  * mode if we have tdi_phy_lpm feature
>*/
>   temp &= ~PORT_WKCONN_E;
>   temp |= PORT_WKDISC_E | PORT_WKOC_E;
>   ehci_writel(ehci, temp | PORT_SUSPEND,
> status_reg);
> - if (ehci->has_hostpc) {
> + if (ehci->has_tdi_phy_lpm) {
>   spin_unlock_irqrestore(&ehci->lock,
> flags); msleep(5);/* 5ms for HCD enter low pwr mode */
>   spin_lock_irqsave(&ehci->lock,
> flags); diff --git a/drivers/usb/host/ehci.h b/drivers/usb/host/ehci.h
> index

Re: [PATCH] MAINTAINERS: Add separate section for USB NETWORKING DRIVERS

[Joe Perches]

On Thu, 2013-08-01 at 15:56 +0800, Greg KH wrote:
> On Thu, Aug 01, 2013 at 12:48:48AM -0700, Joe Perches wrote:
> > There are several drivers in drivers/net/usb/ that
> > do not have specific MAINTAINERS that should have
> > emails forwarded to the linux-usb mailing list.

> > diff --git a/MAINTAINERS b/MAINTAINERS
[]
> > +USB NETWORKING DRIVERS
> > +L: linux-usb@vger.kernel.org
> > +S: Odd Fixes
> > +F: drivers/net/usb/
> 
> But netdev is the one that applies these patches, not linux-usb, so this
> isn't correct either.
> 
> sorry,

Lots of "maintainers" don't apply patches.

This is simply a means to forward patches to
relevant lists that may have reviewers that care
about changes to certain files.

You suggested that linux-usb should get copies
of these patches.

These files are not marked as "Maintained", just
"Odd fixes".  I suppose these could be marked
"Orphan" instead.

You have a suggestion otherwise?

--
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/4] USBNET: ax88179_178a: enable tso if host supports sg dma

[Ming Lei]

On Thu, Aug 1, 2013 at 1:04 PM, Eric Dumazet  wrote:
> On Thu, 2013-08-01 at 12:41 +0800, Ming Lei wrote:
>
>> From my trace result, lots of linear SKBs are cloned or header-cloned, so
>> it needs skb copy too.
>>
>> Is it normal in xmit path to see cloned SKBs for driver? If not, I can add 
>> check
>> to avoid allocation of 8 bytes header for non-cloned skb.
>
> Existing code is not very friendly and very complex.
>
> Sure TCP stack does a clone for every skb from socket write queue,
> but header should be available for pushing 8 bytes.
>
> The !skb_cloned(skb) test should be removed if the memmove() is not
> needed.
>
> Could you try following patch ?

Tested-by: Ming Lei 

This patch does work, and it will make the patch 4/4 become very
simple, :-)

I will rewrite this one against your patch.

Thanks,
--
Ming Lei
--
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/4] USB: XHCI: mark no_sg_limit

[Oliver Neukum]

On Thu, 2013-08-01 at 15:30 +0800, Greg Kroah-Hartman wrote:
> On Wed, Jul 31, 2013 at 09:40:26AM -0700, Sarah Sharp wrote:
> > On Wed, Jul 31, 2013 at 06:51:47PM +0800, Ming Lei wrote:
> > > This patch marks all xHCI controllers as no_sg_limit since
> > > xHCI supports building packet from discontinuous buffers.
> > > 
> > > Cc: Sarah Sharp 
> > > Signed-off-by: Ming Lei 
> > 
> > Acked-by: Sarah Sharp 
> 
> Is it a requirement that all xhci controllers support sg?  I know we are
> starting to see other controllers (the platform code?) so would they
> need to support this as well?

The way XHCI describes transfers allows them to be arbitrary.

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: [PATCH 2/4] usb: chipidea: ci_hdrc_imx: remove an unsolicited module_put() call from ci_hdrc_imx_remove()

[Lothar Waßmann]

Hi,

Peter Chen writes:
> On Wed, Jul 31, 2013 at 04:21:14PM +0200, Lothar Waßmann wrote:
> > This prevents the USB PHY refcount to be decremented below zero upon
> > unloading the ci-hdrc-imx module.
> > 
> > Signed-off-by: Lothar Waßmann 
> > ---
> >  drivers/usb/chipidea/ci_hdrc_imx.c |4 +---
> >  1 files changed, 1 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/usb/chipidea/ci_hdrc_imx.c 
> > b/drivers/usb/chipidea/ci_hdrc_imx.c
> > index 14362c0..802eab1 100644
> > --- a/drivers/usb/chipidea/ci_hdrc_imx.c
> > +++ b/drivers/usb/chipidea/ci_hdrc_imx.c
> > @@ -218,10 +218,8 @@ static int ci_hdrc_imx_remove(struct platform_device 
> > *pdev)
> > if (data->reg_vbus)
> > regulator_disable(data->reg_vbus);
> >  
> > -   if (data->phy) {
> > +   if (data->phy)
> > usb_phy_shutdown(data->phy);
> > -   module_put(data->phy->dev->driver->owner);
> > -   }
> >  
> > clk_disable_unprepare(data->clk);
> 
> Have you met warning? devm_usb_get_phy_by_phandle at probe calls
> try_module_get.
> 
Since it is a 'devm_*' function I would vouch that it also takes care
of the module_put() automagically.

Just try loading and unloading the ci-hdrc-imx module and look at the
resulting refcount of the mxs_usb_phy module.

refcounting is OK without the module_put() here.


Lothar Waßmann
-- 
___

Ka-Ro electronics GmbH | Pascalstraße 22 | D - 52076 Aachen
Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
Geschäftsführer: Matthias Kaussen
Handelsregistereintrag: Amtsgericht Aachen, HRB 4996

www.karo-electronics.de | i...@karo-electronics.de
___
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/4] usb: chipidea: don't clobber return value of ci_role_start()

[Lothar Waßmann]

Hi,

Peter Chen writes:
> On Wed, Jul 31, 2013 at 04:21:15PM +0200, Lothar Waßmann wrote:
> > 
> > Signed-off-by: Lothar Waßmann 
> > ---
> >  drivers/usb/chipidea/core.c |1 -
> >  1 files changed, 0 insertions(+), 1 deletions(-)
> > 
> > diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
> > index a5df24c..38b0a7a 100644
> > --- a/drivers/usb/chipidea/core.c
> > +++ b/drivers/usb/chipidea/core.c
> > @@ -497,7 +497,6 @@ static int ci_hdrc_probe(struct platform_device *pdev)
> > ret = ci_role_start(ci, ci->role);
> > if (ret) {
> > dev_err(dev, "can't start %s role\n", ci_role(ci)->name);
> > -   ret = -ENODEV;
> > goto rm_wq;
> > }
> >  
> 
> +1, it can help get the error one time, without need to add the code
> and get the error number from ci_role_start again.
> 
I don't get what you mean.


Lothar Waßmann
-- 
___

Ka-Ro electronics GmbH | Pascalstraße 22 | D - 52076 Aachen
Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
Geschäftsführer: Matthias Kaussen
Handelsregistereintrag: Amtsgericht Aachen, HRB 4996

www.karo-electronics.de | i...@karo-electronics.de
___
--
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/4] usb: chipidea: Prevent endless loop registering platform_devices when ci_hdrc_probe() fails.

[Lothar Waßmann]

Hi,

Peter Chen writes:
> On Wed, Jul 31, 2013 at 04:21:16PM +0200, Lothar Waßmann wrote:
> > commit 40dcd0e introduced the following code to the ci_hdrc_probe()
> > function:
> > 
> > +   if (!dev->of_node && dev->parent)
> > +   dev->of_node = dev->parent->of_node;
> > 
> > This inadvertently associates the ci_hdrc device with the ci_hdrc_imx
> > driver (which created the ci_hdrc device in the first place).
> > 
> > This results in ci_hdrc_imx_probe() being run for the ci_hdrc device
> > if ci_hdrc_probe() fails for some reason.
> > ci_hdrc_imx_probe() will happily create a new ci_hdrc platform_device
> > whose probing will likewise fail and trigger a new invocation of
> > ci_hdrc_imx_probe() ... ad nauseam.
> > 
> 
> Sorry, I can't understand how it happenes?
> 
If ci_hdrc_probe() fails, the driver core will look for other drivers
that might be able to handle the device. Since the of_node has been
copied from the parent device "imx_usb" the driver responsible for
the DT match of of_node (ci_hdrc_imx) will be called.


Lothar Waßmann
-- 
___

Ka-Ro electronics GmbH | Pascalstraße 22 | D - 52076 Aachen
Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
Geschäftsführer: Matthias Kaussen
Handelsregistereintrag: Amtsgericht Aachen, HRB 4996

www.karo-electronics.de | i...@karo-electronics.de
___
--
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: gadget: audio file: wake up sleep thread when device unbind

[Qiao Zhou]

On 08/01/2013 03:33 PM, Clemens Ladisch wrote:

Qiao Zhou wrote:

when usb audio device removes, it doesn't notify the ALSA read /
write thread. due to no data transmitting any more, those threads
wait for a long timeout(10s), then detects IO error. it causes
long time blocking in upper layer read/write.

to fix this issue, wake up potential sleep thread if necessary
when audio unbind.



+   if (substream && substream->runtime && substream->runtime->twake)
+   wake_up(&substream->runtime->tsleep);


The PCM stream should be properly stopped, which automatically takes
care of notifying userspace.  See this code for an example:



It's reasonable. will update the patch accordingly. thanks.



substream & pcm may still be used after audio unbind, and we
should only set null to it in audio_pcm_close.


What happens when the application immediately tries to restart the
stream?  Many USB audio drivers set a "disconnected" flag to prevent
this, but I don't know if the gadget driver has races that would require
such a check.
I just met an issue with a SS phone + ADK2012 HW. when the ADK2012 HW 
removed from usb I/F, the flow in gadget/audio file is like this: 
android_disconnect-> android_disable-> audio_unbind -> 
audio_unbind_config -> android_enable -> audio_source_bind_config -> 
audio_bind -> android_disable-> audio_unbind -> audio_unbind_config.
the wake up in the 1st audio_unbind can't wake up the sleep thread, and 
I need to do it one more time in 2nd audio_unbind. The substream is 
still needed.


To me, I didn't see races since it only points to pcm substream and 
won't cause trouble in audio file driver. please instruct me if you have 
more comments.



Regards,
Clemens




--

Best Regards
Qiao
--
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

question: do we have any UML like design diagram for usb core and driver model?

[Chen Wang]

hello,
I'm reading code of usb core and driver model/sysfs. I believe they are
designed with OOP. So, do we have any UML design diagrams for better
understanding? I can't image newbies can ramp up quickly in front of
such tons of codes without a high-level design guidance, though I
believe I can understand them finally after days ;).

Thanks.

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

[PATCH] usb: gadget: at91_udc: add usb_clk for transition to common clk framework

[Boris BREZILLON]

The AT91 PMC (Power Management Controller) provides an USB clock used by
USB Full Speed host (ohci) and USB Full Speed device (udc).
The usb drivers (ohci and udc) must configure this clock to 48Mhz.
This configuration was formely done in mach-at91/clock.c, but this
implementation will be removed when moving to common clk framework.

This patch adds support for usb clock retrieval and configuration, and is
backward compatible with the current at91 clk implementation (if usb clk
is not found, it does not configure/enable it).

Signed-off-by: Boris BREZILLON 
---
 drivers/usb/gadget/at91_udc.c |   17 -
 drivers/usb/gadget/at91_udc.h |2 +-
 2 files changed, 17 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/gadget/at91_udc.c b/drivers/usb/gadget/at91_udc.c
index fce8e4e..ae06585 100644
--- a/drivers/usb/gadget/at91_udc.c
+++ b/drivers/usb/gadget/at91_udc.c
@@ -870,6 +870,11 @@ static void clk_on(struct at91_udc *udc)
if (udc->clocked)
return;
udc->clocked = 1;
+
+   if (!IS_ERR(udc->uclk)) {
+   clk_set_rate(udc->uclk, 4800);
+   clk_prepare_enable(udc->uclk);
+   }
clk_prepare_enable(udc->iclk);
clk_prepare_enable(udc->fclk);
 }
@@ -882,6 +887,8 @@ static void clk_off(struct at91_udc *udc)
udc->gadget.speed = USB_SPEED_UNKNOWN;
clk_disable_unprepare(udc->fclk);
clk_disable_unprepare(udc->iclk);
+   if (!IS_ERR(udc->uclk))
+   clk_disable_unprepare(udc->uclk);
 }
 
 /*
@@ -1774,10 +1781,10 @@ static int at91udc_probe(struct platform_device *pdev)
/* get interface and function clocks */
udc->iclk = clk_get(dev, "udc_clk");
udc->fclk = clk_get(dev, "udpck");
+   udc->uclk = clk_get(dev, "usb_clk");
if (IS_ERR(udc->iclk) || IS_ERR(udc->fclk)) {
DBG("clocks missing\n");
retval = -ENODEV;
-   /* NOTE: we "know" here that refcounts on these are NOPs */
goto fail1;
}
 
@@ -1851,6 +1858,12 @@ fail3:
 fail2:
free_irq(udc->udp_irq, udc);
 fail1:
+   if (!IS_ERR(udc->uclk))
+   clk_put(udc->uclk);
+   if (!IS_ERR(udc->fclk))
+   clk_put(udc->fclk);
+   if (!IS_ERR(udc->iclk))
+   clk_put(udc->iclk);
iounmap(udc->udp_baseaddr);
 fail0a:
if (cpu_is_at91rm9200())
@@ -1894,6 +1907,8 @@ static int __exit at91udc_remove(struct platform_device 
*pdev)
 
clk_put(udc->iclk);
clk_put(udc->fclk);
+   if (!IS_ERR(udc->uclk))
+   clk_put(udc->uclk);
 
return 0;
 }
diff --git a/drivers/usb/gadget/at91_udc.h b/drivers/usb/gadget/at91_udc.h
index e647d1c..0175246 100644
--- a/drivers/usb/gadget/at91_udc.h
+++ b/drivers/usb/gadget/at91_udc.h
@@ -126,7 +126,7 @@ struct at91_udc {
unsignedactive_suspend:1;
u8  addr;
struct at91_udc_databoard;
-   struct clk  *iclk, *fclk;
+   struct clk  *iclk, *fclk, *uclk;
struct platform_device  *pdev;
struct proc_dir_entry   *pde;
void __iomem*udp_baseaddr;
-- 
1.7.9.5

--
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/4] usb: chipidea: ci_hdrc_imx: remove an unsolicited module_put() call from ci_hdrc_imx_remove()

[Peter Chen]

On Thu, Aug 01, 2013 at 10:38:18AM +0200, Lothar Waßmann wrote:
> Hi,
> 
> Peter Chen writes:
> > On Wed, Jul 31, 2013 at 04:21:14PM +0200, Lothar Waßmann wrote:
> > > This prevents the USB PHY refcount to be decremented below zero upon
> > > unloading the ci-hdrc-imx module.
> > > 
> > > Signed-off-by: Lothar Waßmann 
> > > ---
> > >  drivers/usb/chipidea/ci_hdrc_imx.c |4 +---
> > >  1 files changed, 1 insertions(+), 3 deletions(-)
> > > 
> > > diff --git a/drivers/usb/chipidea/ci_hdrc_imx.c 
> > > b/drivers/usb/chipidea/ci_hdrc_imx.c
> > > index 14362c0..802eab1 100644
> > > --- a/drivers/usb/chipidea/ci_hdrc_imx.c
> > > +++ b/drivers/usb/chipidea/ci_hdrc_imx.c
> > > @@ -218,10 +218,8 @@ static int ci_hdrc_imx_remove(struct platform_device 
> > > *pdev)
> > >   if (data->reg_vbus)
> > >   regulator_disable(data->reg_vbus);
> > >  
> > > - if (data->phy) {
> > > + if (data->phy)
> > >   usb_phy_shutdown(data->phy);
> > > - module_put(data->phy->dev->driver->owner);
> > > - }
> > >  
> > >   clk_disable_unprepare(data->clk);
> > 
> > Have you met warning? devm_usb_get_phy_by_phandle at probe calls
> > try_module_get.
> > 
> Since it is a 'devm_*' function I would vouch that it also takes care
> of the module_put() automagically.
> 
> Just try loading and unloading the ci-hdrc-imx module and look at the
> resulting refcount of the mxs_usb_phy module.
> 
> refcounting is OK without the module_put() here.
> 

Oh, yes, it calls module_put at usb_put_phy when devm_xxx_release is
called.

Acked-by: Peter Chen 

-- 

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 3/4] usb: chipidea: don't clobber return value of ci_role_start()

[Peter Chen]

On Thu, Aug 01, 2013 at 10:40:42AM +0200, Lothar Waßmann wrote:
> Hi,
> 
> Peter Chen writes:
> > On Wed, Jul 31, 2013 at 04:21:15PM +0200, Lothar Waßmann wrote:
> > > 
> > > Signed-off-by: Lothar Waßmann 
> > > ---
> > >  drivers/usb/chipidea/core.c |1 -
> > >  1 files changed, 0 insertions(+), 1 deletions(-)
> > > 
> > > diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
> > > index a5df24c..38b0a7a 100644
> > > --- a/drivers/usb/chipidea/core.c
> > > +++ b/drivers/usb/chipidea/core.c
> > > @@ -497,7 +497,6 @@ static int ci_hdrc_probe(struct platform_device *pdev)
> > >   ret = ci_role_start(ci, ci->role);
> > >   if (ret) {
> > >   dev_err(dev, "can't start %s role\n", ci_role(ci)->name);
> > > - ret = -ENODEV;
> > >   goto rm_wq;
> > >   }
> > >  
> > 
> > +1, it can help get the error one time, without need to add the code
> > and get the error number from ci_role_start again.
> > 
> I don't get what you mean.
> 

For example, the ci_role_start returns error, the user can't
get error message directly, it can only get -ENODEV. If
the user wants to get what's error at ci_role_start, he
needs to add another debug message and re-compile the kernel.

-- 

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

[RFC] usb: gadget: start to drop endpoint naming conventions

[Felipe Balbi]

Hi folks,

as we all know naming conventions are fragile and easy to break. We've
had weird endpoint naming conventions for far too long in the gadget
framework.

I'm trying to come up with means to get rid of that and, one of the
ideas, was to add transfer support flags to our struct usb_ep which gets
initialized by the UDC driver. Then ep_matches() can use those flags to
check if it should return that endpoint or not.

The ***UNFINISHED*** patch below does just that and shows an example of
how to initialize such flags on dwc3. Please go over it and let me know
what you guys think.

From: Felipe Balbi 

usb: gadget: add transfer support flags for struct usb_ep

NYET-Signed-off-by: Felipe Balbi 
---

diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index f168eae..0bc3621 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -1655,6 +1655,9 @@ static int dwc3_gadget_init_hw_endpoints(struct dwc3 *dwc,
if (epnum == 0 || epnum == 1) {
dep->endpoint.maxpacket = 512;
dep->endpoint.maxburst = 1;
+
+   dep->endpoint.supports_control = true;
+
dep->endpoint.ops = &dwc3_gadget_ep0_ops;
if (!epnum)
dwc->gadget.ep0 = &dep->endpoint;
@@ -1663,6 +1666,12 @@ static int dwc3_gadget_init_hw_endpoints(struct dwc3 
*dwc,
 
dep->endpoint.maxpacket = 1024;
dep->endpoint.max_streams = 15;
+
+   dep->endpoint.supports_bulk = true;
+   dep->endpoint.supports_control = true;
+   dep->endpoint.supports_interrupt = true;
+   dep->endpoint.supports_isochronous = true;
+
dep->endpoint.ops = &dwc3_gadget_ep_ops;
list_add_tail(&dep->endpoint.ep_list,
&dwc->gadget.ep_list);
diff --git a/drivers/usb/gadget/epautoconf.c b/drivers/usb/gadget/epautoconf.c
index a777f7b..bf72538 100644
--- a/drivers/usb/gadget/epautoconf.c
+++ b/drivers/usb/gadget/epautoconf.c
@@ -57,6 +57,27 @@ ep_matches (
if (NULL != ep->driver_data)
return 0;
 
+   /* first try with transfer support flags */
+   type = desc->bmAttributes & USB_ENDPOINT_XFERTYPE_MASK;
+   switch (type) {
+   case USB_ENDPOINT_XFER_CONTROL:
+   if (ep->supports_control)
+   return 0;
+   break;
+   case USB_ENDPOINT_XFER_BULK:
+   if (ep->supports_bulk)
+   return 0;
+   break;
+   case USB_ENDPOINT_XFER_INT:
+   if (ep->supports_interrupt)
+   return 0;
+   break;
+   case USB_ENDPOINT_XFER_ISOC:
+   if (ep->supports_isochronous)
+   return 0;
+   break;
+   }
+
/* only support ep0 for portable CONTROL traffic */
type = desc->bmAttributes & USB_ENDPOINT_XFERTYPE_MASK;
if (USB_ENDPOINT_XFER_CONTROL == type)
diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
index 942ef5e..ed62527 100644
--- a/include/linux/usb/gadget.h
+++ b/include/linux/usb/gadget.h
@@ -159,6 +159,13 @@ struct usb_ep_ops {
  * enabled and remains valid until the endpoint is disabled.
  * @comp_desc: In case of SuperSpeed support, this is the endpoint companion
  * descriptor that is used to configure the endpoint
+ * @supports_isochronous: tells the framework this endpoint supports 
isochronous
+ * transfers
+ * @supports_interrupt: tells the framework this endpoint supports interrupt
+ * transfers
+ * @supports_bulk: tells the framework this endpoint supports bulk transfers
+ * @supports_control: tells the framework this endpoint supports control
+ * transfers
  *
  * the bus controller driver lists all the general purpose endpoints in
  * gadget->ep_list.  the control endpoint (gadget->ep0) is not in that list,
@@ -177,6 +184,11 @@ struct usb_ep {
u8  address;
const struct usb_endpoint_descriptor*desc;
const struct usb_ss_ep_comp_descriptor  *comp_desc;
+
+   unsignedsupports_isochronous:1;
+   unsignedsupports_interrupt:1;
+   unsignedsupports_control:1;
+   unsignedsupports_bulk:1;
 };
 
 /*-*/

-- 
balbi


signature.asc
Description: Digital signature

[PATCH 1/1] usb: samsung: Update Exynos ehci/ohci bindings documentation

[Sachin Kamat]

Updated the document as per the latest implementation.
While at it also fixed some trivial typos.

Signed-off-by: Sachin Kamat 
---
 .../devicetree/bindings/usb/exynos-usb.txt |   38 +++-
 1 file changed, 21 insertions(+), 17 deletions(-)

diff --git a/Documentation/devicetree/bindings/usb/exynos-usb.txt 
b/Documentation/devicetree/bindings/usb/exynos-usb.txt
index d967ba1..16a2c0f 100644
--- a/Documentation/devicetree/bindings/usb/exynos-usb.txt
+++ b/Documentation/devicetree/bindings/usb/exynos-usb.txt
@@ -5,13 +5,15 @@ The device node has following properties.
 
 EHCI
 Required properties:
- - compatible: should be "samsung,exynos4210-ehci" for USB 2.0
-   EHCI controller in host mode.
- - reg: physical base address of the controller and length of memory mapped
+ - compatible : should be one of the following for USB 2.0 EHCI controller
+   in host mode:
+   (a) "samsung,exynos5440-ehci" for Exynos5440 SoC
+   (b) "samsung,exynos4210-ehci" for all other Exynos4 and 5 SoCs
+ - reg : physical base address of the controller and length of memory mapped
region.
- - interrupts: interrupt number to the cpu.
- - clocks: from common clock binding: handle to usb clock.
- - clock-names: from common clock binding: Shall be "usbhost".
+ - interrupts : interrupt number to the CPU.
+ - clocks : from common clock binding: handle to USB clock.
+ - clock-names : from common clock binding: Shall be "usbhost".
 
 Optional properties:
  - samsung,vbus-gpio:  if present, specifies the GPIO that
@@ -23,7 +25,7 @@ Example:
compatible = "samsung,exynos4210-ehci";
reg = <0x1211 0x100>;
interrupts = <0 71 0>;
-   samsung,vbus-gpio = <&gpx2 6 1 3 3>;
+   samsung,vbus-gpio = <&gpx2 6 0>;
 
clocks = <&clock 285>;
clock-names = "usbhost";
@@ -31,13 +33,15 @@ Example:
 
 OHCI
 Required properties:
- - compatible: should be "samsung,exynos4210-ohci" for USB 2.0
-   OHCI companion controller in host mode.
- - reg: physical base address of the controller and length of memory mapped
+ - compatible : should be one of the following for USB 2.0 OHCI companion
+   controller in host mode:
+   (a) "samsung,exynos5440-ohci" for Exynos5440 SoC
+   (b) "samsung,exynos4210-ohci" for all other Exynos4 and 5 SoCs
+ - reg : physical base address of the controller and length of memory mapped
region.
- - interrupts: interrupt number to the cpu.
- - clocks: from common clock binding: handle to usb clock.
- - clock-names: from common clock binding: Shall be "usbhost".
+ - interrupts : interrupt number to the CPU.
+ - clocks : from common clock binding: handle to USB clock.
+ - clock-names : from common clock binding: Shall be "usbhost".
 
 Example:
usb@1212 {
@@ -51,14 +55,14 @@ Example:
 
 DWC3
 Required properties:
- - compatible: should be "samsung,exynos5250-dwusb3" for USB 3.0 DWC3
+ - compatible : should be "samsung,exynos5250-dwusb3" for USB 3.0 DWC3
   controller.
  - #address-cells, #size-cells : should be '1' if the device has sub-nodes
 with 'reg' property.
- - ranges: allows valid 1:1 translation between child's address space and
+ - ranges : allows valid 1:1 translation between child's address space and
   parent's address space
- - clocks: Clock IDs array as required by the controller.
- - clock-names: names of clocks correseponding to IDs in the clock property
+ - clocks : Clock IDs array as required by the controller.
+ - clock-names : names of clocks corresponding to IDs in the clock property
 
 Sub-nodes:
 The dwc3 core should be added as subnode to Exynos dwc3 glue.
-- 
1.7.9.5

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

Re: [PATCH 3/4] usb: chipidea: don't clobber return value of ci_role_start()

[Lothar Waßmann]

Peter Chen writes:
> On Thu, Aug 01, 2013 at 10:40:42AM +0200, Lothar Waßmann wrote:
> > Hi,
> > 
> > Peter Chen writes:
> > > On Wed, Jul 31, 2013 at 04:21:15PM +0200, Lothar Waßmann wrote:
> > > > 
> > > > Signed-off-by: Lothar Waßmann 
> > > > ---
> > > >  drivers/usb/chipidea/core.c |1 -
> > > >  1 files changed, 0 insertions(+), 1 deletions(-)
> > > > 
> > > > diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
> > > > index a5df24c..38b0a7a 100644
> > > > --- a/drivers/usb/chipidea/core.c
> > > > +++ b/drivers/usb/chipidea/core.c
> > > > @@ -497,7 +497,6 @@ static int ci_hdrc_probe(struct platform_device 
> > > > *pdev)
> > > > ret = ci_role_start(ci, ci->role);
> > > > if (ret) {
> > > > dev_err(dev, "can't start %s role\n", 
> > > > ci_role(ci)->name);
> > > > -   ret = -ENODEV;
> > > > goto rm_wq;
> > > > }
> > > >  
> > > 
> > > +1, it can help get the error one time, without need to add the code
> > > and get the error number from ci_role_start again.
> > > 
> > I don't get what you mean.
> > 
> 
> For example, the ci_role_start returns error, the user can't
> get error message directly, it can only get -ENODEV. If
> the user wants to get what's error at ci_role_start, he
> needs to add another debug message and re-compile the kernel.
> 
That's the current situation which is being changed by my patch.


Lothar Waßmann
-- 
___

Ka-Ro electronics GmbH | Pascalstraße 22 | D - 52076 Aachen
Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
Geschäftsführer: Matthias Kaussen
Handelsregistereintrag: Amtsgericht Aachen, HRB 4996

www.karo-electronics.de | i...@karo-electronics.de
___
--
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: [RFC] usb: gadget: start to drop endpoint naming conventions

[Felipe Balbi]

Hi,

On Thu, Aug 01, 2013 at 12:29:55PM +0300, Felipe Balbi wrote:
> Hi folks,
> 
> as we all know naming conventions are fragile and easy to break. We've
> had weird endpoint naming conventions for far too long in the gadget
> framework.
> 
> I'm trying to come up with means to get rid of that and, one of the
> ideas, was to add transfer support flags to our struct usb_ep which gets
> initialized by the UDC driver. Then ep_matches() can use those flags to
> check if it should return that endpoint or not.
> 
> The ***UNFINISHED*** patch below does just that and shows an example of
> how to initialize such flags on dwc3. Please go over it and let me know
> what you guys think.

there's one more positive point about this. We're starting to see some
SoC manufacturers adding trace-over-USB capabilities (e.g. OMAP5 has
such a feature) and tying the capability to specific endpoints (on OMAP5
only EP15IN has access to the trace buffer), so by using flags, rather
than names, it might be slightly easier to implement such non-standard
features. Or maybe not, who knows :-)

-- 
balbi


signature.asc
Description: Digital signature

[PATCH 1/1] usb: phy: samsung: Update usbphy documentation

[Sachin Kamat]

Updated the documentation as per the latest driver implementation.
While at it also fixed some trivial typos.

Signed-off-by: Sachin Kamat 
---
 .../devicetree/bindings/usb/samsung-usbphy.txt |   48 ++--
 1 file changed, 23 insertions(+), 25 deletions(-)

diff --git a/Documentation/devicetree/bindings/usb/samsung-usbphy.txt 
b/Documentation/devicetree/bindings/usb/samsung-usbphy.txt
index 33fd354..62e6f17 100644
--- a/Documentation/devicetree/bindings/usb/samsung-usbphy.txt
+++ b/Documentation/devicetree/bindings/usb/samsung-usbphy.txt
@@ -1,34 +1,32 @@
 SAMSUNG USB-PHY controllers
 
-** Samsung's usb 2.0 phy transceiver
+** Samsung's USB 2.0 phy transceiver
 
-The Samsung's usb 2.0 phy transceiver is used for controlling
-usb 2.0 phy for s3c-hsotg as well as ehci-s5p and ohci-exynos
-usb controllers across Samsung SOCs.
+The Samsung's USB 2.0 phy transceiver is used for controlling
+USB 2.0 phy for s3c-hsotg as well as ehci-s5p and ohci-exynos
+USB controllers across Samsung SOCs.
 TODO: Adding the PHY binding with controller(s) according to the under
 development generic PHY driver.
 
 Required properties:
 
-Exynos4210:
-- compatible : should be "samsung,exynos4210-usb2phy"
-- reg : base physical address of the phy registers and length of memory mapped
-   region.
-- clocks: Clock IDs array as required by the controller.
-- clock-names: names of clock correseponding IDs clock property as requested
-  by the controller driver.
-
-Exynos5250:
-- compatible : should be "samsung,exynos5250-usb2phy"
+- compatible : value should be one among the following:
+   (a) "samsung,s3c64xx-usb2phy" for S3C64xx SoCs
+   (b) "samsung,exynos4210-usb2phy" for Exynos4210 SoC
+   (c) "samsung,exynos4x12-usb2phy" for Exynos4x12 SoCs
+   (d) "samsung,exynos5250-usb2phy" for Exynos5250 SoC
 - reg : base physical address of the phy registers and length of memory mapped
region.
+- clocks : Clock IDs array as required by the controller.
+- clock-names : names of clocks listed in clocks property in the same order
+  as requested by the controller driver.
 
 Optional properties:
-- #address-cells: should be '1' when usbphy node has a child node with 'reg'
+- #address-cellsi : should be '1' when usbphy node has a child node with 'reg'
  property.
-- #size-cells: should be '1' when usbphy node has a child node with 'reg'
+- #size-cells : should be '1' when usbphy node has a child node with 'reg'
   property.
-- ranges: allows valid translation between child's address space and parent's
+- ranges : allows valid translation between child's address space and parent's
  address space.
 
 - The child node 'usbphy-sys' to the node 'usbphy' is for the system controller
@@ -63,10 +61,10 @@ Example:
};
 
 
-** Samsung's usb 3.0 phy transceiver
+** Samsung's USB 3.0 phy transceiver
 
-Starting exynso5250, Samsung's SoC have usb 3.0 phy transceiver
-which is used for controlling usb 3.0 phy for dwc3-exynos usb 3.0
+Starting Exynos5250, Samsung's SoC have USB 3.0 phy transceiver
+which is used for controlling USB 3.0 phy for dwc3-exynos USB 3.0
 controllers across Samsung SOCs.
 
 Required properties:
@@ -75,16 +73,16 @@ Exynos5250:
 - compatible : should be "samsung,exynos5250-usb3phy"
 - reg : base physical address of the phy registers and length of memory mapped
region.
-- clocks: Clock IDs array as required by the controller.
-- clock-names: names of clocks correseponding to IDs in the clock property
+- clocks : Clock IDs array as required by the controller.
+- clock-names : names of clocks correseponding to IDs in the clock property
   as requested by the controller driver.
 
 Optional properties:
-- #address-cells: should be '1' when usbphy node has a child node with 'reg'
+- #address-cells : should be '1' when usbphy node has a child node with 'reg'
  property.
-- #size-cells: should be '1' when usbphy node has a child node with 'reg'
+- #size-cells : should be '1' when usbphy node has a child node with 'reg'
   property.
-- ranges: allows valid translation between child's address space and parent's
+- ranges : allows valid translation between child's address space and parent's
  address space.
 
 - The child node 'usbphy-sys' to the node 'usbphy' is for the system controller
-- 
1.7.9.5

--
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: [RFC] usb: gadget: start to drop endpoint naming conventions

[Sebastian Andrzej Siewior]

On 08/01/2013 11:29 AM, Felipe Balbi wrote:
> Hi folks,

Hi felipe,

> as we all know naming conventions are fragile and easy to break.
> We've had weird endpoint naming conventions for far too long in the
> gadget framework.
> 
> I'm trying to come up with means to get rid of that and, one of
> the ideas, was to add transfer support flags to our struct usb_ep
> which gets initialized by the UDC driver. Then ep_matches() can use
> those flags to check if it should return that endpoint or not.
> 
> The ***UNFINISHED*** patch below does just that and shows an
> example of how to initialize such flags on dwc3. Please go over it
> and let me know what you guys think.

I think this is a good step forward. I remember dummy followed once two
conventions and returned endpoints twice. So I like the idea.
Are you trying to make the gadget_is_*() in usb_ep_autoconfig_ss() also
somehow generic?

Sebastian
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: question: do we have any UML like design diagram for usb core and driver model?

[Oliver Neukum]

On Thu, 2013-08-01 at 17:13 +0800, Chen Wang wrote:
> hello,
> I'm reading code of usb core and driver model/sysfs. I believe they are
> designed with OOP.

Yes, much of the code is OO. However, we usually
don't overwrite methods.

> So, do we have any UML design diagrams for better

No. The code was designed without diagrams.

> understanding? I can't image newbies can ramp up quickly in front of
> such tons of codes without a high-level design guidance, though I
> believe I can understand them finally after days ;).

You can write a USB driver without understanding driver
core. The driver core is needed only to understand
probing and power management in usbcore.

HTH
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: [PATCH 4/4] usb: chipidea: Prevent endless loop registering platform_devices when ci_hdrc_probe() fails.

[Peter Chen]

On Thu, Aug 01, 2013 at 10:43:52AM +0200, Lothar Waßmann wrote:
> Hi,
> 
> Peter Chen writes:
> > On Wed, Jul 31, 2013 at 04:21:16PM +0200, Lothar Waßmann wrote:
> > > commit 40dcd0e introduced the following code to the ci_hdrc_probe()
> > > function:
> > > 
> > > +   if (!dev->of_node && dev->parent)
> > > +   dev->of_node = dev->parent->of_node;
> > > 
> > > This inadvertently associates the ci_hdrc device with the ci_hdrc_imx
> > > driver (which created the ci_hdrc device in the first place).
> > > 
> > > This results in ci_hdrc_imx_probe() being run for the ci_hdrc device
> > > if ci_hdrc_probe() fails for some reason.
> > > ci_hdrc_imx_probe() will happily create a new ci_hdrc platform_device
> > > whose probing will likewise fail and trigger a new invocation of
> > > ci_hdrc_imx_probe() ... ad nauseam.
> > > 
> > 
> > Sorry, I can't understand how it happenes?
> > 
> If ci_hdrc_probe() fails, the driver core will look for other drivers
> that might be able to handle the device. Since the of_node has been
> copied from the parent device "imx_usb" the driver responsible for
> the DT match of of_node (ci_hdrc_imx) will be called.
> 

Good fix.

Reviewed-and-Tested-by: Peter Chen 

-- 

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: [RFC] usb: gadget: start to drop endpoint naming conventions

[Felipe Balbi]

On Thu, Aug 01, 2013 at 11:47:56AM +0200, Sebastian Andrzej Siewior wrote:
> On 08/01/2013 11:29 AM, Felipe Balbi wrote:
> > Hi folks,
> 
> Hi felipe,
> 
> > as we all know naming conventions are fragile and easy to break.
> > We've had weird endpoint naming conventions for far too long in the
> > gadget framework.
> > 
> > I'm trying to come up with means to get rid of that and, one of
> > the ideas, was to add transfer support flags to our struct usb_ep
> > which gets initialized by the UDC driver. Then ep_matches() can use
> > those flags to check if it should return that endpoint or not.
> > 
> > The ***UNFINISHED*** patch below does just that and shows an
> > example of how to initialize such flags on dwc3. Please go over it
> > and let me know what you guys think.
> 
> I think this is a good step forward. I remember dummy followed once two
> conventions and returned endpoints twice. So I like the idea.
> Are you trying to make the gadget_is_*() in usb_ep_autoconfig_ss() also
> somehow generic?

yeah, I want to drop gadget_is_*() altogether and add feature flags for
the struct usb_gadget too. I mean, gadget driver shouldn't need to know
that it's running on dwc3, it needs to know if the UDC supports
alternate settings.

-- 
balbi


signature.asc
Description: Digital signature

[PATCH] usb: gadget: audio file: wake up sleep thread when device unbind

[Qiao Zhou]

when usb audio device removes, we need to stop the current pcm
substream when detecting hw disconnects. otherwise the read /
write thread may sleep for long time before timeout, thus upper
layer is blocked for long time and can't repsond quickly to the
hw disconnection.

also substream & pcm may still be used after audio unbind, and
we should only set null to it in audio_pcm_close.

Signed-off-by: Qiao Zhou 
---
 drivers/usb/gadget/f_audio_source.c |   11 +--
 1 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/gadget/f_audio_source.c 
b/drivers/usb/gadget/f_audio_source.c
index c757409..8d4f58e 100644
--- a/drivers/usb/gadget/f_audio_source.c
+++ b/drivers/usb/gadget/f_audio_source.c
@@ -620,15 +620,21 @@ static void
 audio_unbind(struct usb_configuration *c, struct usb_function *f)
 {
struct audio_dev *audio = func_to_audio(f);
+   struct snd_pcm_substream *substream = audio->substream;
struct usb_request *req;
 
while ((req = audio_req_get(audio)))
audio_request_free(req, audio->in_ep);
 
+   /* stop pcm stream when audio unbind after hw disconnect */
+   if (substream && substream->runtime && snd_pcm_running(substream)) {
+   snd_pcm_stream_lock_irq(substream);
+   snd_pcm_stop(substream, SNDRV_PCM_STATE_DISCONNECTED);
+   snd_pcm_stream_unlock_irq(substream);
+   }
+
snd_card_free_when_closed(audio->card);
audio->card = NULL;
-   audio->pcm = NULL;
-   audio->substream = NULL;
audio->in_ep = NULL;
 }
 
@@ -670,6 +676,7 @@ static int audio_pcm_close(struct snd_pcm_substream 
*substream)
unsigned long flags;
 
spin_lock_irqsave(&audio->lock, flags);
+   audio->pcm = NULL;
audio->substream = NULL;
spin_unlock_irqrestore(&audio->lock, flags);
 
-- 
1.7.0.4

--
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 v2] usb-gadget-audio-file-wake-up-sleep-thread

[Qiao Zhou]

v2->v1:
stop pcm stream instead of wake up the sleep thread, which is more
reasonable.

Qiao Zhou (1):
  usb: gadget: audio file: wake up sleep thread when device unbind

 drivers/usb/gadget/f_audio_source.c |   11 +--
 1 files changed, 9 insertions(+), 2 deletions(-)

--
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: gadget: cdc2: convert to new interface of f_ecm' applied to my tree

[Andrzej Pietrasiewicz]

On Wednesday, June 12, 2013 5:17 PM Felipe Balbi wrote:
> Hi,
> 
> This is a note to let you know that the patch:
> 
>   usb: gadget: cdc2: convert to new interface of f_ecm
> 
> has been applied to my tree and can be found at:
> 
>   http://bit.ly/172DRHC
> 
> a snapshot of the tree can be downloaded from:
> 
>   http://bit.ly/11zcltc
> 
> Note that it might take up to 20 minutes for kernel.org to synchronize the
> changes to its frontend servers.
> 
> If you have any concerns, please let me know by replying to this mail.
> 

Hi Felipe,

During testing the gadgets I discovered a strange behavior of the cdc.ko
gadget. It turns out that what has been applied to your tree is different
from what I have submitted.

The main difference (which I suppose causes trouble) is that
usb_get_function_instance() is called from cdc_bind()
(which is good and intended) and then again its invocation is repeated
in cdc_do_config (which is bad).

Originally Sebastian's conversion of acm to new function interface did
usb_get_function_instance() only in one place, cdc_do_config().
Later on I discovered that the code is much cleaner if the following
convention is obeyed: usb_get_function_instance() is called only from
xxx_bind(), while usb_get_function() is called only from xxx_do_config().

The patch I submitted:

http://www.spinics.net/lists/linux-usb/msg86326.html

indeed follows the said convention. However, what has been applied does not.

I reverted the patch in question and applied it again after making necessary
corrections so that it is consistent with what I have submitted. After
squashing the two a simple patch results and I'm sending it - in a separate
mail.

Please see below for what looks bad to me:


> From a38a275030086d95306555e544fc7c0e65ccd00e Mon Sep 17 00:00:00 2001
> From: Andrzej Pietrasiewicz 
> Date: Thu, 23 May 2013 10:32:04 +0200
> Subject: [PATCH] usb: gadget: cdc2: convert to new interface of f_ecm
> 
> f_ecm has been converted to new configfs infrastructure, fixing cdc2
> gadget driver.
> 
> [ ba...@ti.com : fixed a bunch of errors when adding ECM function ]
> 
> Signed-off-by: Andrzej Pietrasiewicz 
> Signed-off-by: Kyungmin Park 
> Signed-off-by: Felipe Balbi 
> ---
>  drivers/usb/gadget/Kconfig |  1 +
>  drivers/usb/gadget/cdc2.c  | 86 +++--
> -
>  2 files changed, 60 insertions(+), 27 deletions(-)
> 



> diff --git a/drivers/usb/gadget/cdc2.c b/drivers/usb/gadget/cdc2.c index
> ceedaf7..5a5acf2 100644
> --- a/drivers/usb/gadget/cdc2.c
> +++ b/drivers/usb/gadget/cdc2.c
> @@ -15,6 +15,7 @@
> 



>  /*
>   * We _always_ have both CDC ECM and CDC ACM functions.
>   */
> @@ -122,13 +113,27 @@ static int __init cdc_do_config(struct
> usb_configuration *c)
>   c->bmAttributes |= USB_CONFIG_ATT_WAKEUP;
>   }
> 
> - status = ecm_bind_config(c, host_mac, the_dev);
> - if (status < 0)
> - return status;
> + fi_ecm = usb_get_function_instance("ecm");

When control reaches this point the usb_get_function_instance("ecm")
has already been called in cdc_bind

> + if (IS_ERR(fi_ecm)) {
> + status = PTR_ERR(fi_ecm);
> + goto err_func_ecm;
> + }
> +
> + f_ecm = usb_get_function(fi_ecm);
> + if (IS_ERR(f_ecm)) {
> + status = PTR_ERR(f_ecm);
> + goto err_get_ecm;
> + }
> +
> + status = usb_add_function(c, f_ecm);
> + if (status)
> + goto err_add_ecm;
> 
>   fi_serial = usb_get_function_instance("acm");

When control reaches this point the usb_get_function_instance("acm")
has already been called in cdc_bind

> - if (IS_ERR(fi_serial))
> - return PTR_ERR(fi_serial);
> + if (IS_ERR(fi_serial)) {
> + status = PTR_ERR(fi_serial);
> + goto err_get_acm;
> + }
> 
>   f_acm = usb_get_function(fi_serial);
>   if (IS_ERR(f_acm)) {
> @@ -138,12 +143,21 @@ static int __init cdc_do_config(struct
> usb_configuration *c)
> 
>   status = usb_add_function(c, f_acm);
>   if (status)
> - goto err_conf;
> + goto err_add_acm;
> +
>   return 0;
> -err_conf:
> +
> +err_add_acm:
>   usb_put_function(f_acm);
>  err_func_acm:
>   usb_put_function_instance(fi_serial);
> +err_get_acm:
> + usb_remove_function(c, f_ecm);
> +err_add_ecm:
> + usb_put_function(f_ecm);
> +err_get_ecm:
> + usb_put_function_instance(fi_ecm);
> +err_func_ecm:
>   return status;
>  }
> 
> @@ -159,6 +173,7 @@ static struct usb_configuration cdc_config_driver =
> {  static int __init cdc_bind(struct usb_composite_dev *cdev)  {
>   struct usb_gadget   *gadget = cdev->gadget;
> + struct f_ecm_opts   *ecm_opts;
>   int status;
> 
>   if (!can_support_ecm(cdev->gadget)) {
> @@ -167,11 +182,23 @@ static int __init cdc_bind(struct usb_composite_dev
> *cdev)
>   return -EINVAL;
>   }
> 
> - /* set up network link laye

Re: [RFC] usb: gadget: start to drop endpoint naming conventions

[Sebastian Andrzej Siewior]

On 08/01/2013 12:18 PM, Felipe Balbi wrote:
> yeah, I want to drop gadget_is_*() altogether and add feature flags
> for the struct usb_gadget too. I mean, gadget driver shouldn't need
> to know that it's running on dwc3, it needs to know if the UDC
> supports alternate settings.

One of them is to avoid slow PIO transfers on BULK transfers. But yes
you get the idea.

Sebastian
--
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: gadget: cdc2: convert to new interface of f_ecm' applied to my tree

[Felipe Balbi]

Hi

On Thu, Aug 01, 2013 at 12:31:55PM +0200, Andrzej Pietrasiewicz wrote:
> On Wednesday, June 12, 2013 5:17 PM Felipe Balbi wrote:
> > Hi,
> > 
> > This is a note to let you know that the patch:
> > 
> > usb: gadget: cdc2: convert to new interface of f_ecm
> > 
> > has been applied to my tree and can be found at:
> > 
> > http://bit.ly/172DRHC
> > 
> > a snapshot of the tree can be downloaded from:
> > 
> > http://bit.ly/11zcltc
> > 
> > Note that it might take up to 20 minutes for kernel.org to synchronize the
> > changes to its frontend servers.
> > 
> > If you have any concerns, please let me know by replying to this mail.
> > 
> 
> Hi Felipe,
> 
> During testing the gadgets I discovered a strange behavior of the cdc.ko
> gadget. It turns out that what has been applied to your tree is different
> from what I have submitted.
> 
> The main difference (which I suppose causes trouble) is that
> usb_get_function_instance() is called from cdc_bind()
> (which is good and intended) and then again its invocation is repeated
> in cdc_do_config (which is bad).
> 
> Originally Sebastian's conversion of acm to new function interface did
> usb_get_function_instance() only in one place, cdc_do_config().
> Later on I discovered that the code is much cleaner if the following
> convention is obeyed: usb_get_function_instance() is called only from
> xxx_bind(), while usb_get_function() is called only from xxx_do_config().
> 
> The patch I submitted:
> 
> http://www.spinics.net/lists/linux-usb/msg86326.html
> 
> indeed follows the said convention. However, what has been applied does not.
> 
> I reverted the patch in question and applied it again after making necessary
> corrections so that it is consistent with what I have submitted. After
> squashing the two a simple patch results and I'm sending it - in a separate
> mail.

Weird, I don't modify patches, just git am them. Anyway, please send me
a diff on top of my tree and I'll merge it in.

Perhaps that one failed to apply and I fixed the way I thought to be
correct. Please send a fix and I'll queue for the next -rc.

Thanks

-- 
balbi


signature.asc
Description: Digital signature

[PATCH] usb/gadget: cdc2: convert to new interface of f_ecm

[Andrzej Pietrasiewicz]

This fixes commit a38a275030086d95306555e544fc7c0e65ccd00e.
The invocation of usb_get_function_instance() is in cdc_bind()
and should not be repeated in cdc_do_config().


Signed-off-by: Andrzej Pietrasiewicz 
Signed-off-by: Kyungmin Park 
---
 drivers/usb/gadget/cdc2.c |   19 +--
 1 files changed, 1 insertions(+), 18 deletions(-)

diff --git a/drivers/usb/gadget/cdc2.c b/drivers/usb/gadget/cdc2.c
index 5a5acf2..e126b6b 100644
--- a/drivers/usb/gadget/cdc2.c
+++ b/drivers/usb/gadget/cdc2.c
@@ -113,12 +113,6 @@ static int __init cdc_do_config(struct usb_configuration 
*c)
c->bmAttributes |= USB_CONFIG_ATT_WAKEUP;
}
 
-   fi_ecm = usb_get_function_instance("ecm");
-   if (IS_ERR(fi_ecm)) {
-   status = PTR_ERR(fi_ecm);
-   goto err_func_ecm;
-   }
-
f_ecm = usb_get_function(fi_ecm);
if (IS_ERR(f_ecm)) {
status = PTR_ERR(f_ecm);
@@ -129,35 +123,24 @@ static int __init cdc_do_config(struct usb_configuration 
*c)
if (status)
goto err_add_ecm;
 
-   fi_serial = usb_get_function_instance("acm");
-   if (IS_ERR(fi_serial)) {
-   status = PTR_ERR(fi_serial);
-   goto err_get_acm;
-   }
-
f_acm = usb_get_function(fi_serial);
if (IS_ERR(f_acm)) {
status = PTR_ERR(f_acm);
-   goto err_func_acm;
+   goto err_get_acm;
}
 
status = usb_add_function(c, f_acm);
if (status)
goto err_add_acm;
-
return 0;
 
 err_add_acm:
usb_put_function(f_acm);
-err_func_acm:
-   usb_put_function_instance(fi_serial);
 err_get_acm:
usb_remove_function(c, f_ecm);
 err_add_ecm:
usb_put_function(f_ecm);
 err_get_ecm:
-   usb_put_function_instance(fi_ecm);
-err_func_ecm:
return status;
 }
 
-- 
1.7.0.4

--
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/gadget: cdc2: convert to new interface of f_ecm

[Felipe Balbi]

Hi,

On Thu, Aug 01, 2013 at 12:40:47PM +0200, Andrzej Pietrasiewicz wrote:
> This fixes commit a38a275030086d95306555e544fc7c0e65ccd00e.
> The invocation of usb_get_function_instance() is in cdc_bind()
> and should not be repeated in cdc_do_config().
> 
> 
> Signed-off-by: Andrzej Pietrasiewicz 
> Signed-off-by: Kyungmin Park 

Please add a 'fix' to the subject too. You're not converting anything
anymore, just fixing what got into mainline ;-)

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH 5/5] usb: musb: dsps: use proper child nodes

[Sebastian Andrzej Siewior]

On 08/01/2013 07:24 AM, George Cherian wrote:
>> b/arch/arm/boot/dts/am33xx.dtsi
>> index 38b446b..0f756ca 100644
>> --- a/arch/arm/boot/dts/am33xx.dtsi
>> +++ b/arch/arm/boot/dts/am33xx.dtsi
>> @@ -333,21 +337,85 @@
>>   status = "disabled";
>>   };
>>   -usb@4740 {
>> -compatible = "ti,musb-am33xx";
>> -reg = <0x4740 0x1000/* usbss */
>> -   0x47401000 0x800/* musb instance 0 */
>> -   0x47401800 0x800>;/* musb instance 1 */
>> -interrupts = <17/* usbss */
>> -  18/* musb instance 0 */
>> -  19>;/* musb instance 1 */
>> -multipoint = <1>;
>> -num-eps = <16>;
>> -ram-bits = <12>;
>> -port0-mode = <3>;
>> -port1-mode = <3>;
>> -power = <250>;
>> +usb: usb@4740 {
>> +compatible = "ti,am33xx-usb";
>> +reg = <0x4740 0x1000>;
>> +ranges;
>> +#address-cells = <1>;
>> +#size-cells = <1>;
>>   ti,hwmods = "usb_otg_hs";
>> +status = "disabled";
>> +
>> +ctrl_mod: control@44e1 {
>> +compatible = "ti,am335x-ctrl-module";
>> +reg = <0x44e1 0x650>;
> 
> Do you really need to map Control Module base to 0x650? If some other
> driver does this mapping

This is what I cam currently not sure about. Either we minimize the
register window and introduce two (the other wakeup) or we keep using
the same reset driver for other devices.

> we will always end returning -EPROBE_DEFER.
> 
> How about this
> reg = <0x44e10620 0x4> ,
this has to be 16 bytes in size

> <0x44e10648 0x1>;
this has to be 4 bytes in size.

> reg-names = "phycontrol_dev" , "phywkup_dev";
> 
> and map for power on/off and phywkup separately in the control driver.
> 
>> +reg-names = "control_dev";
>> +status = "disabled";
>> +};
>> +
> 
> 
> 
>> diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig
>> index 797e3fd..b7257ae 100644
>> --- a/drivers/usb/musb/Kconfig
>> +++ b/drivers/usb/musb/Kconfig
>> @@ -83,6 +83,7 @@ config USB_MUSB_AM35X
>> config USB_MUSB_DSPS
>>   tristate "TI DSPS platforms"
>> +select USB_MUSB_AM335X_CHILD
> 
> How about adding select AM335X_PHY_USB here?

For now maybe a good think but if we do multi platform support we
should recommend them instead of forcing users. What you think?

Sebastian
--
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: phy: Add AM335x PHY driver

[Sebastian Andrzej Siewior]

On 08/01/2013 07:36 AM, George Cherian wrote:

please keep the file here file snipping

>> +static const struct of_device_id omap_control_usb_id_table[] = {
>> +{ .compatible = "ti,am335x-ctrl-module", .data = &ctrl_am335x },
>> +{}
>> +};
>> +MODULE_DEVICE_TABLE(of, omap_control_usb_id_table);
>> +
>> +static struct platform_driver am335x_control_driver;
>> +static int match(struct device *dev, void *data)
>> +{
>> +struct device_node *node = (struct device_node *)data;
>> +return dev->of_node == node &&
>> +dev->driver == &am335x_control_driver.driver;
>> +}
>> +
>> +struct phy_control *am335x_get_phy_control(struct device *dev)
>> +{
>> +struct device_node *node;
>> +struct am335x_control_usb *ctrl_usb;
>> +
>> +node = of_parse_phandle(dev->of_node, "ti,ctrl_mod", 0);
>> +if (!node)
>> +return NULL;
>> +
>> +dev = bus_find_device(&platform_bus_type, NULL, node, match);
> 
> of_find_device_by_node doesn't work???

It would but I have here a reference to the device.

> 
>> +ctrl_usb = dev_get_drvdata(dev);
>> +if (!ctrl_usb)
>> +return NULL;
>> +return &ctrl_usb->phy_ctrl;
>> +}
>> +EXPORT_SYMBOL_GPL(am335x_get_phy_control);
>> +
>> +static int am335x_control_usb_probe(struct platform_device *pdev)
>> +{
>> +struct resource*res;
>> +struct am335x_control_usb *ctrl_usb;
>> +const struct of_device_id *of_id;
>> +const struct phy_control *phy_ctrl;
>> +
>> +of_id = of_match_node(omap_control_usb_id_table, pdev->dev.of_node);
>> +if (!of_id)
>> +return -EINVAL;
>> +
>> +phy_ctrl = of_id->data;
>> +
>> +ctrl_usb = devm_kzalloc(&pdev->dev, sizeof(*ctrl_usb), GFP_KERNEL);
>> +if (!ctrl_usb) {
>> +dev_err(&pdev->dev, "unable to alloc memory for control usb\n");
>> +return -ENOMEM;
>> +}
>> +
>> +ctrl_usb->dev = &pdev->dev;
>> +
>> +res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
>> "control_dev");
>> +ctrl_usb->reset_reg = devm_ioremap_resource(&pdev->dev, res);
> 
> As per current DTSI in patch 5 you are mapping from control module base
> till 0x650.
> Cant it be split to 2 registers one mapping for phy on/off and one for
> phy wkup?

You asked the same question in the other pathch. It could but please
refer to the other patch.

Sebastian
--
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: musb: dsps: use proper child nodes

[Sebastian Andrzej Siewior]

On 08/01/2013 12:52 PM, Sebastian Andrzej Siewior wrote:
> On 08/01/2013 07:24 AM, George Cherian wrote:
>>> b/arch/arm/boot/dts/am33xx.dtsi
>>> index 38b446b..0f756ca 100644
>>> --- a/arch/arm/boot/dts/am33xx.dtsi
>>> +++ b/arch/arm/boot/dts/am33xx.dtsi
>>> @@ -333,21 +337,85 @@
>>>   status = "disabled";
>>>   };
>>>   -usb@4740 {
>>> -compatible = "ti,musb-am33xx";
>>> -reg = <0x4740 0x1000/* usbss */
>>> -   0x47401000 0x800/* musb instance 0 */
>>> -   0x47401800 0x800>;/* musb instance 1 */
>>> -interrupts = <17/* usbss */
>>> -  18/* musb instance 0 */
>>> -  19>;/* musb instance 1 */
>>> -multipoint = <1>;
>>> -num-eps = <16>;
>>> -ram-bits = <12>;
>>> -port0-mode = <3>;
>>> -port1-mode = <3>;
>>> -power = <250>;
>>> +usb: usb@4740 {
>>> +compatible = "ti,am33xx-usb";
>>> +reg = <0x4740 0x1000>;
>>> +ranges;
>>> +#address-cells = <1>;
>>> +#size-cells = <1>;
>>>   ti,hwmods = "usb_otg_hs";
>>> +status = "disabled";
>>> +
>>> +ctrl_mod: control@44e1 {
>>> +compatible = "ti,am335x-ctrl-module";
>>> +reg = <0x44e1 0x650>;
>>
>> Do you really need to map Control Module base to 0x650? If some other
>> driver does this mapping
> 
> This is what I cam currently not sure about. Either we minimize the
> register window and introduce two (the other wakeup) or we keep using
> the same reset driver for other devices.

I mean drivers/reset or something like that.



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

Haswell C2, xHCI and S3

[Andre Heider]

Hi list,

blunt question, because I'm about to assemble a new Haswell box and I
wonder if waiting for C2 boards makes sense:

Does Linux care about the apparent C1 stepping xHCI bug [1]?
Are workarounds required for the kernel? If so, does C2 get rid of them?

[1] http://www.guru3d.com/news_story/intel_confirms_haswell_chipset_usb_bug.html

Thanks in advance,
Andre
--
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/2] ARM: dts: USB for Tegra114 Dalmore

[Sergei Shtylyov]

Hello.

On 01-08-2013 3:29, Stephen Warren wrote:


 Don't they cause numerous resource conflicts while device nodes
being
instantiated as the platform devices?



No; the driver knows that the HW is screwy and there's lots of
register-range sharing going on, so it simply maps the registers, rather
than reserving the physical address range and mapping it.


Yes, it's clear that the driver should take special measures, I was
asking about the platform device creation phase. What do you see in
/proc/iomem?



The drivers don't request the memory region since doing so would cause
conflicts. Hence, the regions don't show up in /proc/iomem.


   Regions should show up after the platform device registration. They just 
show up as subregions of those when you request them. That's why I asked for 
your /proc/iomem.


WBR, 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/gadget: cdc2: convert to new interface of f_ecm

[Sergei Shtylyov]

Hello.

   Your subject don't seem to match the patch itself.

On 01-08-2013 14:40, Andrzej Pietrasiewicz wrote:


This fixes commit a38a275030086d95306555e544fc7c0e65ccd00e.


   Please also specify that commit's summary line in parens.


The invocation of usb_get_function_instance() is in cdc_bind()
and should not be repeated in cdc_do_config().




Signed-off-by: Andrzej Pietrasiewicz 
Signed-off-by: Kyungmin Park 


WBR, 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 0/6] USB tree changes for Tegra30 and Tegra114 USB Host support

[Tuomas Tynkkynen]

On 08/01/2013 02:22 AM, Stephen Warren wrote:
> On 07/31/2013 11:41 AM, Tuomas Tynkkynen wrote:
>> Hi all,
>>
>> Here are the patches for the USB tree to enable USB Host support on Tegra30 
>> and
>> Tegra114. These are based on my and Mikko's cleanup patches that just got
>> merged to Felipe's tree.
> 
> This series works fine for me on Dalmore. However, on Beaver, I see the
> following:
> 
> [2.428480] platform 7d008000.usb: Driver tegra-ehci requests probe
> deferral
> 
> ... which never seems to be resolved. You can take a look at my
> linux-next_common branch to repro this. Does Beaver work for you?
> 

The clock driver patch is missing from your branch. Applying it should fix that.
--
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/4] USBNET: ax88179_178a: enable tso if host supports sg dma

[Eric Dumazet]

On Thu, 2013-08-01 at 16:10 +0800, Ming Lei wrote:
> On Thu, Aug 1, 2013 at 1:04 PM, Eric Dumazet  wrote:
> > On Thu, 2013-08-01 at 12:41 +0800, Ming Lei wrote:
> >
> >> From my trace result, lots of linear SKBs are cloned or header-cloned, so
> >> it needs skb copy too.
> >>
> >> Is it normal in xmit path to see cloned SKBs for driver? If not, I can add 
> >> check
> >> to avoid allocation of 8 bytes header for non-cloned skb.
> >
> > Existing code is not very friendly and very complex.
> >
> > Sure TCP stack does a clone for every skb from socket write queue,
> > but header should be available for pushing 8 bytes.
> >
> > The !skb_cloned(skb) test should be removed if the memmove() is not
> > needed.
> >
> > Could you try following patch ?
> 
> Tested-by: Ming Lei 
> 
> This patch does work, and it will make the patch 4/4 become very
> simple, :-)
> 
> I will rewrite this one against your patch.

OK I'll post an official patch then. I presume you got performance
increase, since we no longer do a copy of the TCP packets.



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

Re: question: do we have any UML like design diagram for usb core and driver model?

[Greg KH]

On Thu, Aug 01, 2013 at 11:51:07AM +0200, Oliver Neukum wrote:
> On Thu, 2013-08-01 at 17:13 +0800, Chen Wang wrote:
> > hello,
> > I'm reading code of usb core and driver model/sysfs. I believe they are
> > designed with OOP.
> 
> Yes, much of the code is OO. However, we usually
> don't overwrite methods.
> 
> > So, do we have any UML design diagrams for better
> 
> No. The code was designed without diagrams.

Well, it was a lot of diagrams, drawn on whiteboards over the course of
a year or so with me and the other driver core author.  But we never
saved them, and odds are, the existing code looks nothing like our
original drawings anyway, so they wouldn't help out much :)

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

[PATCH net-next] ax88179_178a: avoid copy of tx tcp packets

[Eric Dumazet]

From: Eric Dumazet 

ax88179_tx_fixup() has quite complex code trying to push 8 bytes
of control data (len/mss), but fails to do it properly for TCP packets,
incurring an extra copy and point of memory allocation failure.

Lets use the simple and approved way.

dev->needed_headroom being 8, all frames should have 8 bytes of
headroom, so the extra copy should be unlikely anyway.

This patch should improve performance for TCP xmits.

Reported-by: Ming Lei 
Tested-by: Ming Lei 
Signed-off-by: Eric Dumazet 
---
 drivers/net/usb/ax88179_178a.c |   21 -
 1 file changed, 4 insertions(+), 17 deletions(-)

diff --git a/drivers/net/usb/ax88179_178a.c b/drivers/net/usb/ax88179_178a.c
index 2bc87e3..e2120d6 100644
--- a/drivers/net/usb/ax88179_178a.c
+++ b/drivers/net/usb/ax88179_178a.c
@@ -1166,31 +1166,18 @@ ax88179_tx_fixup(struct usbnet *dev, struct sk_buff 
*skb, gfp_t flags)
int frame_size = dev->maxpacket;
int mss = skb_shinfo(skb)->gso_size;
int headroom;
-   int tailroom;
 
tx_hdr1 = skb->len;
tx_hdr2 = mss;
if (((skb->len + 8) % frame_size) == 0)
tx_hdr2 |= 0x80008000;  /* Enable padding */
 
-   headroom = skb_headroom(skb);
-   tailroom = skb_tailroom(skb);
+   headroom = skb_headroom(skb) - 8;
 
-   if (!skb_header_cloned(skb) &&
-   !skb_cloned(skb) &&
-   (headroom + tailroom) >= 8) {
-   if (headroom < 8) {
-   skb->data = memmove(skb->head + 8, skb->data, skb->len);
-   skb_set_tail_pointer(skb, skb->len);
-   }
-   } else {
-   struct sk_buff *skb2;
-
-   skb2 = skb_copy_expand(skb, 8, 0, flags);
+   if ((skb_header_cloned(skb) || headroom < 0) &&
+   pskb_expand_head(skb, headroom < 0 ? 8 : 0, 0, GFP_ATOMIC)) {
dev_kfree_skb_any(skb);
-   skb = skb2;
-   if (!skb)
-   return NULL;
+   return NULL;
}
 
skb_push(skb, 4);


--
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 net-next] ax88179_178a: avoid copy of tx tcp packets

[Eric Dumazet]

On Thu, 2013-08-01 at 06:49 -0700, Eric Dumazet wrote:
> From: Eric Dumazet 
> 
> ax88179_tx_fixup() has quite complex code trying to push 8 bytes
> of control data (len/mss), but fails to do it properly for TCP packets,
> incurring an extra copy and point of memory allocation failure.

I forgot to say this patch is for net-next, but depends on following fix
from net tree being applied.

commit 20f0170377264e8449b6987041f0bcc4d746d3ed
("usbnet: do not pretend to support SG/TSO")



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

[PATCH 3/7] usb: phy: omap-usb3: Don't use omap_get_control_dev()

[Roger Quadros]

omap_get_control_dev() is being deprecated as it doesn't support
multiple instances. As control device is present only from OMAP4
onwards which supports DT only, we use phandles to get the
reference to the control device.

As we don't support non-DT boot, we just bail out on probe
if device node is not present.

Signed-off-by: Roger Quadros 
---
 drivers/usb/phy/phy-omap-usb3.c |   20 +---
 1 files changed, 17 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/phy/phy-omap-usb3.c b/drivers/usb/phy/phy-omap-usb3.c
index 4a7f27c..bad032e 100644
--- a/drivers/usb/phy/phy-omap-usb3.c
+++ b/drivers/usb/phy/phy-omap-usb3.c
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #definePLL_STATUS  0x0004
 #definePLL_GO  0x0008
@@ -198,6 +199,12 @@ static int omap_usb3_probe(struct platform_device *pdev)
 {
struct omap_usb *phy;
struct resource *res;
+   struct device_node *node = pdev->dev.of_node;
+   struct device_node *control_node;
+   struct platform_device *control_pdev;
+
+   if (!node)
+   return -ENODEV;
 
phy = devm_kzalloc(&pdev->dev, sizeof(*phy), GFP_KERNEL);
if (!phy) {
@@ -239,11 +246,18 @@ static int omap_usb3_probe(struct platform_device *pdev)
return -EINVAL;
}
 
-   phy->control_dev = omap_get_control_dev();
-   if (IS_ERR(phy->control_dev)) {
-   dev_dbg(&pdev->dev, "Failed to get control device\n");
+   control_node = of_parse_phandle(node, "ctrl-module", 0);
+   if (!control_node) {
+   dev_err(&pdev->dev, "Failed to get control device phandle\n");
return -ENODEV;
}
+   control_pdev = of_find_device_by_node(control_node);
+   if (!control_pdev) {
+   dev_err(&pdev->dev, "Failed to get control device\n");
+   return -ENODEV;
+   }
+
+   phy->control_dev = &control_pdev->dev;
 
omap_control_usb_phy_power(phy->control_dev, 0);
usb_add_phy_dev(&phy->phy);
-- 
1.7.4.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 6/7] ARM: dts: omap4: update omap-control-usb nodes

[Roger Quadros]

Split otghs_ctrl and USB2 PHY power down into separate
omap-control-usb nodes. Update ti,mode property.

CC: Benoit Cousson 
Signed-off-by: Roger Quadros 
---
 arch/arm/boot/dts/omap4.dtsi |   17 -
 1 files changed, 12 insertions(+), 5 deletions(-)

diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 22d9f2b..9a6fa27 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -519,7 +519,7 @@
usb2_phy: usb2phy@4a0ad080 {
compatible = "ti,omap-usb2";
reg = <0x4a0ad080 0x58>;
-   ctrl-module = <&omap_control_usb>;
+   ctrl-module = <&omap_control_usb2phy>;
};
};
 
@@ -643,11 +643,17 @@
};
};
 
-   omap_control_usb: omap-control-usb@4a002300 {
+   omap_control_usb2phy: omap-control-usb@4a002300 {
compatible = "ti,omap-control-usb";
-   reg = <0x4a002300 0x4>,
- <0x4a00233c 0x4>;
-   reg-names = "control_dev_conf", "otghs_control";
+   reg = <0x4a002300 0x4>;
+   reg-names = "power";
+   ti,type = <2>;
+   };
+
+   omap_control_usbotg: omap-control-usb@4a00233c {
+   compatible = "ti,omap-control-usb";
+   reg = <0x4a00233c 0x4>;
+   reg-names = "otghs_control";
ti,type = <1>;
};
 
@@ -662,6 +668,7 @@
num-eps = <16>;
ram-bits = <12>;
ti,has-mailbox;
+   ctrl-module = <&omap_control_usbotg>;
};
};
 };
-- 
1.7.4.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 7/7] ARM: dts: omap5: update omap-control-usb node

[Roger Quadros]

Split USB2 PHY and USB3 PHY into separate omap-control-usb
nodes. Update ti,mode property.

CC: Benoit Cousson 
Signed-off-by: Roger Quadros 
---
 arch/arm/boot/dts/omap5.dtsi |   18 --
 1 files changed, 12 insertions(+), 6 deletions(-)

diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 07be2cd..af8ef77 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -626,14 +626,20 @@
hw-caps-temp-alert;
};
 
-   omap_control_usb: omap-control-usb@4a002300 {
+   omap_control_usb2phy: omap-control-usb@4a002300 {
compatible = "ti,omap-control-usb";
-   reg = <0x4a002300 0x4>,
- <0x4a002370 0x4>;
-   reg-names = "control_dev_conf", "phy_power_usb";
+   reg = <0x4a002300 0x4>;
+   reg-names = "power";
ti,type = <2>;
};
 
+   omap_control_usb3phy: omap-control-usb@0x4a002370 {
+   compatible = "ti,omap-control-usb";
+   reg = <0x4a002370 0x4>;
+   reg-names = "power";
+   ti,type = <3>;
+   };
+
omap_dwc3@4a02 {
compatible = "ti,dwc3";
ti,hwmods = "usb_otg_ss";
@@ -661,7 +667,7 @@
usb2_phy: usb2phy@4a084000 {
compatible = "ti,omap-usb2";
reg = <0x4a084000 0x7c>;
-   ctrl-module = <&omap_control_usb>;
+   ctrl-module = <&omap_control_usb2phy>;
};
 
usb3_phy: usb3phy@4a084400 {
@@ -670,7 +676,7 @@
  <0x4a084800 0x64>,
  <0x4a084c00 0x40>;
reg-names = "phy_rx", "phy_tx", "pll_ctrl";
-   ctrl-module = <&omap_control_usb>;
+   ctrl-module = <&omap_control_usb3phy>;
};
};
 
-- 
1.7.4.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 4/7] usb: musb: omap2430: Don't use omap_get_control_dev()

[Roger Quadros]

omap_get_control_dev() is being deprecated as it doesn't support
multiple instances. As control device is present only from OMAP4
onwards which supports DT only, we use phandles to get the
reference to the control device.

Signed-off-by: Roger Quadros 
---
 drivers/usb/musb/omap2430.c |   22 ++
 1 files changed, 18 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index ebb46ec..1db9588 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -38,6 +38,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "musb_core.h"
 #include "omap2430.h"
@@ -547,12 +548,25 @@ static int omap2430_probe(struct platform_device *pdev)
}
 
if (pdata->has_mailbox) {
-   glue->control_otghs = omap_get_control_dev();
-   if (IS_ERR(glue->control_otghs)) {
-   dev_vdbg(&pdev->dev, "Failed to get control device\n");
-   ret = PTR_ERR(glue->control_otghs);
+   struct device_node *control_node;
+   struct platform_device *control_pdev;
+
+   control_node = of_parse_phandle(np, "ctrl-module", 0);
+   if (!control_node) {
+   dev_err(&pdev->dev, "Failed to get control device 
phandle\n");
+   ret = -ENODEV;
+   goto err2;
+   }
+
+   control_pdev = of_find_device_by_node(control_node);
+   if (!control_pdev) {
+   dev_err(&pdev->dev, "Failed to get control device\n");
+   ret = -ENODEV;
goto err2;
}
+
+   glue->control_otghs = &control_pdev->dev;
+
} else {
glue->control_otghs = ERR_PTR(-ENODEV);
}
-- 
1.7.4.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 1/7] usb: phy: omap: Add new PHY types and remove omap_control_usb3_phy_power()

[Roger Quadros]

TYPE2 meaning has changed. It is now a USB2 phy with Power down bit in
control_dev_conf register.

Introduce TYPE3 and TYPE4 PHY. TYPE3 is USB3 phy with DPLL and individual
TX/RX power control. TYPE4 is USB2 phy with power aux register.

Update DT binding information to reflect these changes.

Also get rid of omap_control_usb3_phy_power(). Just one function
i.e. omap_control_usb_phy_power() will now take care of all PHY types.

Signed-off-by: Roger Quadros 
---
 Documentation/devicetree/bindings/usb/omap-usb.txt |   23 ++--
 drivers/usb/phy/phy-omap-control.c |  129 +++-
 drivers/usb/phy/phy-omap-usb2.c|4 +
 drivers/usb/phy/phy-omap-usb3.c|6 +-
 include/linux/usb/omap_control_usb.h   |   18 ++--
 5 files changed, 100 insertions(+), 80 deletions(-)

diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt 
b/Documentation/devicetree/bindings/usb/omap-usb.txt
index 57e71f6..e2606ab 100644
--- a/Documentation/devicetree/bindings/usb/omap-usb.txt
+++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
@@ -75,20 +75,19 @@ OMAP CONTROL USB
 Required properties:
  - compatible: Should be "ti,omap-control-usb"
  - reg : Address and length of the register set for the device. It contains
-   the address of "control_dev_conf" and "otghs_control" or "phy_power_usb"
-   depending upon omap4 or omap5.
- - reg-names: The names of the register addresses corresponding to the 
registers
-   filled in "reg".
- - ti,type: This is used to differentiate whether the control module has
-   usb mailbox or usb3 phy power. omap4 has usb mailbox in control module to
-   notify events to the musb core and omap5 has usb3 phy power register to
-   power on usb3 phy. Should be "1" if it has mailbox and "2" if it has usb3
-   phy power.
+   the address of "otghs_control" for type 1 or "power" register for other 
types.
+   For type 4, it must also contain "power_aux" register.
+ - reg-names: should be otghs_control for type 1 and "power" for other types.
+ - ti,type: This is used to specify the type of control register.
+   Should be one of the following:
+   1 - if it has otghs_control mailbox register (e.g. on OMAP4)
+   2 - if it has Power down bit in control_dev_conf register. e.g. USB2 PHY
+   3 - if it has DPLL and individual Rx & Tx power control. e.g. USB3 PHY or 
SATA PHY
+   4 - if it has both power down and power aux registers. e.g. USB2 PHY on DRA7
 
 omap_control_usb: omap-control-usb@4a002300 {
compatible = "ti,omap-control-usb";
-   reg = <0x4a002300 0x4>,
- <0x4a00233c 0x4>;
-   reg-names = "control_dev_conf", "otghs_control";
+   reg = <0x4a00233c 0x4>;
+   reg-names = "otghs_control";
ti,type = <1>;
 };
diff --git a/drivers/usb/phy/phy-omap-control.c 
b/drivers/usb/phy/phy-omap-control.c
index a4dda8e..cf93c5a 100644
--- a/drivers/usb/phy/phy-omap-control.c
+++ b/drivers/usb/phy/phy-omap-control.c
@@ -46,61 +46,76 @@ struct device *omap_get_control_dev(void)
 EXPORT_SYMBOL_GPL(omap_get_control_dev);
 
 /**
- * omap_control_usb3_phy_power - power on/off the serializer using control
- * module
+ * omap_control_usb_phy_power - power on/off the phy using control module reg
  * @dev: the control module device
- * @on: 0 to off and 1 to on based on powering on or off the PHY
- *
- * usb3 PHY driver should call this API to power on or off the PHY.
+ * @on: 0 or 1, based on powering on or off the PHY
  */
-void omap_control_usb3_phy_power(struct device *dev, bool on)
+void omap_control_usb_phy_power(struct device *dev, int on)
 {
-   u32 val;
+   u32 val, val_aux;
unsigned long rate;
-   struct omap_control_usb *control_usb = dev_get_drvdata(dev);
+   struct omap_control_usb *control_usb;
 
-   if (control_usb->type != OMAP_CTRL_DEV_TYPE2)
+   if (IS_ERR(dev) || !dev) {
+   pr_err("%s: invalid device\n", __func__);
return;
+   }
 
-   rate = clk_get_rate(control_usb->sys_clk);
-   rate = rate/100;
+   control_usb = dev_get_drvdata(dev);
+   if (!control_usb) {
+   dev_err(dev, "%s: invalid control usb device\n", __func__);
+   return;
+   }
 
-   val = readl(control_usb->phy_power);
+   if (control_usb->type == OMAP_CTRL_DEV_TYPE1)
+   return;
 
-   if (on) {
-   val &= ~(OMAP_CTRL_USB_PWRCTL_CLK_CMD_MASK |
-   OMAP_CTRL_USB_PWRCTL_CLK_FREQ_MASK);
-   val |= OMAP_CTRL_USB3_PHY_TX_RX_POWERON <<
-   OMAP_CTRL_USB_PWRCTL_CLK_CMD_SHIFT;
-   val |= rate << OMAP_CTRL_USB_PWRCTL_CLK_FREQ_SHIFT;
-   } else {
-   val &= ~OMAP_CTRL_USB_PWRCTL_CLK_CMD_MASK;
-   val |= OMAP_CTRL_USB3_PHY_TX_RX_POWEROFF <<
-   OMAP_CTRL_USB_PWRCTL_CLK_CMD_SHIFT;
-   }
+   val = readl(control_usb->power);
 
-   writel(val, control_usb->phy_power);

[PATCH 2/7] usb: phy: omap-usb2: Don't use omap_get_control_dev()

[Roger Quadros]

omap_get_control_dev() is being deprecated as it doesn't support
multiple instances. As control device is present only from OMAP4
onwards which supports DT only, we use phandles to get the
reference to the control device.

As we don't support non-DT boot, we just bail out on probe
if device node is not present.

Signed-off-by: Roger Quadros 
---
 drivers/usb/phy/phy-omap-usb2.c |   16 +---
 1 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/phy/phy-omap-usb2.c b/drivers/usb/phy/phy-omap-usb2.c
index 376b367..77e0cf4 100644
--- a/drivers/usb/phy/phy-omap-usb2.c
+++ b/drivers/usb/phy/phy-omap-usb2.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /**
  * omap_usb2_set_comparator - links the comparator present in the sytem with
@@ -124,6 +125,8 @@ static int omap_usb2_probe(struct platform_device *pdev)
struct omap_usb *phy;
struct usb_otg  *otg;
struct device_node *node = pdev->dev.of_node;
+   struct device_node *control_node;
+   struct platform_device *control_pdev;
 
if (!node)
return -ENODEV;
@@ -148,11 +151,18 @@ static int omap_usb2_probe(struct platform_device *pdev)
phy->phy.otg= otg;
phy->phy.type   = USB_PHY_TYPE_USB2;
 
-   phy->control_dev = omap_get_control_dev();
-   if (IS_ERR(phy->control_dev)) {
-   dev_dbg(&pdev->dev, "Failed to get control device\n");
+   control_node = of_parse_phandle(node, "ctrl-module", 0);
+   if (!control_node) {
+   dev_err(&pdev->dev, "Failed to get control device phandle\n");
return -ENODEV;
}
+   control_pdev = of_find_device_by_node(control_node);
+   if (!control_pdev) {
+   dev_err(&pdev->dev, "Failed to get control device\n");
+   return -ENODEV;
+   }
+
+   phy->control_dev = &control_pdev->dev;
 
phy->is_suspended   = 1;
omap_control_usb_phy_power(phy->control_dev, 0);
-- 
1.7.4.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 0/7] phy: omap-usb: Support multiple instances and new types

[Roger Quadros]

Hi,

This patchset does the following:

* Restructure and add support for new PHY types. We now support the follwing
four types

 TYPE1 - if it has otghs_control mailbox register (e.g. on OMAP4)
 TYPE2 - if it has Power down bit in control_dev_conf register. e.g. USB2 PHY
 TYPE3 - if it has DPLL and individual Rx & Tx power control. e.g. USB3 PHY or 
SATA PHY
 TYPE4 - if it has both power down and power aux registers. e.g. USB2 PHY on 
DRA7

* Have only one power control API "omap_control_usb_phy_power()" instead of a
different one for each PHY type.

* Get rid of omap_get_control_dev() so that we can support multiple instances
of the control device. We take advantage of the fact that omap control USB 
device
is only present on OMAP4 onwards and hence only supports DT boot. The users
of control USB device can get a reference to it from the device node's phandle.

Patches are based on top of v3.11-rc3 with balbi/next on top.

Smoke tested on OMAP4 panda with MUSB in gadget mode (g_zero).

You can find the patches in branch
 usb-control-module
in git tree
 git://github.com/rogerq/linux.git

cheers,
-roger

Roger Quadros (7):
  usb: phy: omap: Add new PHY types and remove
omap_control_usb3_phy_power()
  usb: phy: omap-usb2: Don't use omap_get_control_dev()
  usb: phy: omap-usb3: Don't use omap_get_control_dev()
  usb: musb: omap2430: Don't use omap_get_control_dev()
  usb: phy: omap: get rid of omap_get_control_dev()
  ARM: dts: omap4: update omap-control-usb nodes
  ARM: dts: omap5: update omap-control-usb node

 Documentation/devicetree/bindings/usb/omap-usb.txt |   23 ++--
 arch/arm/boot/dts/omap4.dtsi   |   17 ++-
 arch/arm/boot/dts/omap5.dtsi   |   18 ++-
 drivers/usb/musb/omap2430.c|   22 +++-
 drivers/usb/phy/phy-omap-control.c |  160 ++-
 drivers/usb/phy/phy-omap-usb2.c|   20 ++-
 drivers/usb/phy/phy-omap-usb3.c|   26 +++-
 include/linux/usb/omap_control_usb.h   |   23 +--
 8 files changed, 182 insertions(+), 127 deletions(-)

-- 
1.7.4.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 v2] usb/gadget: cdc2: fix conversion to new interface of f_ecm

[Andrzej Pietrasiewicz]

This fixes commit a38a275030086d95306555e544fc7c0e65ccd00e
(usb: gadget: cdc2: convert to new interface of f_ecm)

The invocation of usb_get_function_instance() is in cdc_bind()
and should not be repeated in cdc_do_config().

Signed-off-by: Andrzej Pietrasiewicz 
Signed-off-by: Kyungmin Park 
---
 drivers/usb/gadget/cdc2.c |   19 +--
 1 files changed, 1 insertions(+), 18 deletions(-)

diff --git a/drivers/usb/gadget/cdc2.c b/drivers/usb/gadget/cdc2.c
index 5a5acf2..e126b6b 100644
--- a/drivers/usb/gadget/cdc2.c
+++ b/drivers/usb/gadget/cdc2.c
@@ -113,12 +113,6 @@ static int __init cdc_do_config(struct usb_configuration 
*c)
c->bmAttributes |= USB_CONFIG_ATT_WAKEUP;
}
 
-   fi_ecm = usb_get_function_instance("ecm");
-   if (IS_ERR(fi_ecm)) {
-   status = PTR_ERR(fi_ecm);
-   goto err_func_ecm;
-   }
-
f_ecm = usb_get_function(fi_ecm);
if (IS_ERR(f_ecm)) {
status = PTR_ERR(f_ecm);
@@ -129,35 +123,24 @@ static int __init cdc_do_config(struct usb_configuration 
*c)
if (status)
goto err_add_ecm;
 
-   fi_serial = usb_get_function_instance("acm");
-   if (IS_ERR(fi_serial)) {
-   status = PTR_ERR(fi_serial);
-   goto err_get_acm;
-   }
-
f_acm = usb_get_function(fi_serial);
if (IS_ERR(f_acm)) {
status = PTR_ERR(f_acm);
-   goto err_func_acm;
+   goto err_get_acm;
}
 
status = usb_add_function(c, f_acm);
if (status)
goto err_add_acm;
-
return 0;
 
 err_add_acm:
usb_put_function(f_acm);
-err_func_acm:
-   usb_put_function_instance(fi_serial);
 err_get_acm:
usb_remove_function(c, f_ecm);
 err_add_ecm:
usb_put_function(f_ecm);
 err_get_ecm:
-   usb_put_function_instance(fi_ecm);
-err_func_ecm:
return status;
 }
 
-- 
1.7.0.4

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

[PATCH 5/7] usb: phy: omap: get rid of omap_get_control_dev()

[Roger Quadros]

This function was preventing us from supporting multiple
instances. Get rid of it. Since we support DT boots only,
users can get the control device phandle from the DT node.

Signed-off-by: Roger Quadros 
---
 drivers/usb/phy/phy-omap-control.c   |   31 ++-
 include/linux/usb/omap_control_usb.h |5 -
 2 files changed, 10 insertions(+), 26 deletions(-)

diff --git a/drivers/usb/phy/phy-omap-control.c 
b/drivers/usb/phy/phy-omap-control.c
index cf93c5a..015eeef 100644
--- a/drivers/usb/phy/phy-omap-control.c
+++ b/drivers/usb/phy/phy-omap-control.c
@@ -25,26 +25,6 @@
 #include 
 #include 
 
-static struct omap_control_usb *control_usb;
-
-/**
- * omap_get_control_dev - returns the device pointer for this control device
- *
- * This API should be called to get the device pointer for this control
- * module device. This device pointer should be used for called other
- * exported API's in this driver.
- *
- * To be used by PHY driver and glue driver.
- */
-struct device *omap_get_control_dev(void)
-{
-   if (!control_usb)
-   return ERR_PTR(-ENODEV);
-
-   return control_usb->dev;
-}
-EXPORT_SYMBOL_GPL(omap_get_control_dev);
-
 /**
  * omap_control_usb_phy_power - power on/off the phy using control module reg
  * @dev: the control module device
@@ -187,11 +167,19 @@ void omap_control_usb_set_mode(struct device *dev,
 {
struct omap_control_usb *ctrl_usb;
 
-   if (IS_ERR(dev) || control_usb->type != OMAP_CTRL_DEV_TYPE1)
+   if (IS_ERR(dev) || !dev)
return;
 
ctrl_usb = dev_get_drvdata(dev);
 
+   if (!ctrl_usb) {
+   dev_err(dev, "Invalid control usb device\n");
+   return;
+   }
+
+   if (ctrl_usb->type != OMAP_CTRL_DEV_TYPE1)
+   return;
+
switch (mode) {
case USB_MODE_HOST:
omap_control_usb_host_mode(ctrl_usb);
@@ -214,6 +202,7 @@ static int omap_control_usb_probe(struct platform_device 
*pdev)
struct device_node *np = pdev->dev.of_node;
struct omap_control_usb_platform_data *pdata =
dev_get_platdata(&pdev->dev);
+   struct omap_control_usb *control_usb;
 
control_usb = devm_kzalloc(&pdev->dev, sizeof(*control_usb),
GFP_KERNEL);
diff --git a/include/linux/usb/omap_control_usb.h 
b/include/linux/usb/omap_control_usb.h
index 7f027d3..8b48584 100644
--- a/include/linux/usb/omap_control_usb.h
+++ b/include/linux/usb/omap_control_usb.h
@@ -67,15 +67,10 @@ enum omap_control_usb_mode {
 #define OMAP_CTRL_USB2_PHY_PD  BIT(28)
 
 #if IS_ENABLED(CONFIG_OMAP_CONTROL_USB)
-extern struct device *omap_get_control_dev(void);
 extern void omap_control_usb_phy_power(struct device *dev, int on);
 extern void omap_control_usb_set_mode(struct device *dev,
enum omap_control_usb_mode mode);
 #else
-static inline struct device *omap_get_control_dev(void)
-{
-   return ERR_PTR(-ENODEV);
-}
 
 static inline void omap_control_usb_phy_power(struct device *dev, int on)
 {
-- 
1.7.4.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: Ejected Nook (usb mass storage) prevents suspend

[Oliver Neukum]

On Wed, 2013-07-31 at 11:13 -0400, Alan Stern wrote:

> More importantly, if we already know that the medium is not present or
> has been changed since it was last used, then there's no reason to call
> sd_sync_cache() at all.

Like this?

Regards
Oliver



>From 8c90d860652aa99e6e60d9b32bc3aa8d4db9efa5 Mon Sep 17 00:00:00 2001
From: Oliver Neukum 
Date: Thu, 1 Aug 2013 10:08:20 +0200
Subject: [PATCH] sd: error handling during flushing caches

It makes no sense to flush the cache of a device without medium.
Errors during suspend must be handled according to their causes.
Errors due to missing media or unplugged devices must be ignored.
Errors due to devices being offlined must also be ignored.
The error returns must be modified so that the generic layer
understands them.

Signed-off-by: Oliver Neukum 
---
 drivers/scsi/scsi_pm.c |  3 ++-
 drivers/scsi/sd.c  | 69 ++
 2 files changed, 60 insertions(+), 12 deletions(-)

diff --git a/drivers/scsi/scsi_pm.c b/drivers/scsi/scsi_pm.c
index 4c5aabe..af4c050 100644
--- a/drivers/scsi/scsi_pm.c
+++ b/drivers/scsi/scsi_pm.c
@@ -54,7 +54,8 @@ scsi_bus_suspend_common(struct device *dev, int (*cb)(struct device *))
 		/*
 		 * All the high-level SCSI drivers that implement runtime
 		 * PM treat runtime suspend, system suspend, and system
-		 * hibernate identically.
+		 * hibernate nearly identically. In all cases the requirements
+		 * for runtime suspension are stricter.
 		 */
 		if (pm_runtime_suspended(dev))
 			return 0;
diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c
index 86fcf2c..3c7f918 100644
--- a/drivers/scsi/sd.c
+++ b/drivers/scsi/sd.c
@@ -105,7 +105,8 @@ static void sd_unlock_native_capacity(struct gendisk *disk);
 static int  sd_probe(struct device *);
 static int  sd_remove(struct device *);
 static void sd_shutdown(struct device *);
-static int sd_suspend(struct device *);
+static int sd_suspend_system(struct device *);
+static int sd_suspend_runtime(struct device *);
 static int sd_resume(struct device *);
 static void sd_rescan(struct device *);
 static int sd_done(struct scsi_cmnd *);
@@ -483,11 +484,11 @@ static struct class sd_disk_class = {
 };
 
 static const struct dev_pm_ops sd_pm_ops = {
-	.suspend		= sd_suspend,
+	.suspend		= sd_suspend_system,
 	.resume			= sd_resume,
-	.poweroff		= sd_suspend,
+	.poweroff		= sd_suspend_system,
 	.restore		= sd_resume,
-	.runtime_suspend	= sd_suspend,
+	.runtime_suspend	= sd_suspend_runtime,
 	.runtime_resume		= sd_resume,
 };
 
@@ -1437,6 +1438,8 @@ static int sd_sync_cache(struct scsi_disk *sdkp)
 	if (!scsi_device_online(sdp))
 		return -ENODEV;
 
+	if (!sdkp->media_present)
+		return 0;
 
 	for (retries = 3; retries > 0; --retries) {
 		unsigned char cmd[10] = { 0 };
@@ -1455,12 +1458,31 @@ static int sd_sync_cache(struct scsi_disk *sdkp)
 
 	if (res) {
 		sd_print_result(sdkp, res);
-		if (driver_byte(res) & DRIVER_SENSE)
+
+		if (driver_byte(res) & DRIVER_SENSE) 
 			sd_print_sense_hdr(sdkp, &sshdr);
+		/* we need to evaluate the error return  */
+		if ((scsi_sense_valid(&sshdr) &&
+			/* 0x3a is medium not present */
+			sshdr.asc == 0x3a))
+/* this is no error here */
+return 0;
+
+		switch (host_byte(res)) {
+		/* ignore errors due to racing a disconnection */
+		case DID_BAD_TARGET:
+		case DID_NO_CONNECT:
+			return 0;
+		/* signal the upper layer it might try again */
+		case DID_BUS_BUSY:
+		case DID_IMM_RETRY:
+		case DID_REQUEUE:
+		case DID_SOFT_ERROR:
+			return -EBUSY;
+		default:
+			return -EIO;
+		}
 	}
-
-	if (res)
-		return -EIO;
 	return 0;
 }
 
@@ -3062,9 +3084,17 @@ static int sd_start_stop_device(struct scsi_disk *sdkp, int start)
 		sd_print_result(sdkp, res);
 		if (driver_byte(res) & DRIVER_SENSE)
 			sd_print_sense_hdr(sdkp, &sshdr);
+		if ((scsi_sense_valid(&sshdr) &&
+			/* 0x3a is medium not present */
+			sshdr.asc == 0x3a))
+			res = 0;
 	}
 
-	return res;
+	/* SCSI error codes must not go to the generic layer */
+	if (res)
+		return -EIO;
+
+	return 0;
 }
 
 /*
@@ -3096,7 +3126,7 @@ exit:
 	scsi_disk_put(sdkp);
 }
 
-static int sd_suspend(struct device *dev)
+static int sd_suspend_common(struct device *dev, bool ignore_stop_errors)
 {
 	struct scsi_disk *sdkp = scsi_disk_get_from_dev(dev);
 	int ret = 0;
@@ -3107,13 +3137,20 @@ static int sd_suspend(struct device *dev)
 	if (sdkp->WCE) {
 		sd_printk(KERN_NOTICE, sdkp, "Synchronizing SCSI cache\n");
 		ret = sd_sync_cache(sdkp);
-		if (ret)
+		if (ret) {
+			/* ignore OFFLINE device */
+			if (ret == -ENODEV)
+ret = 0;
 			goto done;
+		}
 	}
 
 	if (sdkp->device->manage_start_stop) {
 		sd_printk(KERN_NOTICE, sdkp, "Stopping disk\n");
+		/* an error is not worth aborting a system sleep */
 		ret = sd_start_stop_device(sdkp, 0);
+		if (ignore_stop_errors)
+			ret = 0;
 	}
 
 done:
@@ -3121,6 +3158,16 @@ done:
 	return ret;
 }
 
+static int sd_suspend_system(struct device *dev)
+{
+	return sd_suspend_common(dev, true);
+}
+
+stati

Re: question: do we have any UML like design diagram for usb core and driver model?

[Alan Stern]

On Thu, 1 Aug 2013, Oliver Neukum wrote:

> On Thu, 2013-08-01 at 17:13 +0800, Chen Wang wrote:
> > hello,
> > I'm reading code of usb core and driver model/sysfs. I believe they are
> > designed with OOP.
> 
> Yes, much of the code is OO. However, we usually
> don't overwrite methods.
> 
> > So, do we have any UML design diagrams for better
> 
> No. The code was designed without diagrams.
> 
> > understanding? I can't image newbies can ramp up quickly in front of
> > such tons of codes without a high-level design guidance, though I
> > believe I can understand them finally after days ;).
> 
> You can write a USB driver without understanding driver
> core. The driver core is needed only to understand
> probing and power management in usbcore.

On the other hand, patches to improve the documentation are always 
welcome.  :-)

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] USB: ohci-at91: add usb_clk for transition to common clk framework

[Alan Stern]

On Thu, 1 Aug 2013, Boris BREZILLON wrote:

> The AT91 PMC (Power Management Controller) provides an USB clock used by
> USB Full Speed host (ohci) and USB Full Speed device (udc).
> The usb drivers (ohci and udc) must configure this clock to 48Mhz.
> This configuration was formely done in mach-at91/clock.c, but this
> implementation will be removed when moving to common clk framework.
> 
> This patch adds support for usb clock retrieval and configuration, and is
> backward compatible with the current at91 clk implementation (if usb clk
> is not found, it does not configure/enable it).
> 
> Signed-off-by: Boris BREZILLON 

> @@ -163,6 +169,8 @@ static int usb_hcd_at91_probe(const struct hc_driver 
> *driver,
>   goto err5;
>   }
>  
> + uclk = clk_get(&pdev->dev, "usb_clk");

What happens if uclk isn't found but it is needed?

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: Audio I/O parameters

[Alan Stern]

On Wed, 31 Jul 2013, James Stone wrote:

> > It seems likely that the error is caused by an SMI taking too much
> > time.  At least, we seem to have ruled out everything else.  Besides,
> > this change has to be made eventually in any case -- underruns can
> > occur at any time, in principle, and they shouldn't cause the audio
> > driver to fail.
> 
> Yep - that makes sense. But has there been a change in SMI timings
> with the new kernel?

SMIs are controlled by the BIOS, not by the kernel.  I don't think 
changing the kernel would affect their timings.

>  I don't think this bug happened with earlier
> kernels.

It depends on what you mean.  The underruns almost certainly did occur 
with earlier kernels.  But they didn't cause failures, so you weren't 
aware of them.

> Oh, by the way, should I be adding anything to #1191603
> seeing as this (non-realtime) bug seems to be the same one everyone
> else is complaining about?

It's up to you.  Bear in mind that your problems have involved three or
four other bugs in addition.

> > By the way, can you post the contents of /proc/interrupts?  I'd like to
> > see if the IRQ line in question is shared.
> >
>CPU0   CPU1   CPU2   CPU3
>  17:5261388  0  1104   IO-APIC-fasteoi
> ehci_hcd:usb1, ehci_hcd:usb2, ehci_hcd:usb3
>  18:  0 52  26049408   IO-APIC-fasteoi
> ohci_hcd:usb4, ohci_hcd:usb5, ohci_hcd:usb6, ohci_hcd:usb7

Okay, so the USB controllers do share IRQ lines.  Were you using the 
other USB buses when the errors occurred?

> >> I just managed to induce another cannot submit URB bug, and there is
> >> definitely nothing written to trace around the time of this bug, with
> >> the settings:
> >>
> >> echo 0 > options/function-trace
> >> echo irqsoff > current_tracer
> >> echo 1 > tracing_on
> >> echo 0 > tracing_max_latency
> >
> > You may need to do "echo 0 >tracing_on" before looking at the file.
> > I'm not sure.
> >
> 
> I don't think that's necessary - it seems to update the file without this.

All right.

> > But the tracer certainly should contain _something_, because interrupts
> > are constantly being disabled and enabled during normal system
> > operation.  Even if nothing went wrong, there would still be a nonzero
> > latency.
> 
> Yes - there was something - from recollection it was some firefox
> process with a latency of 2000us, but what I meant is that nothing new
> seemed to be written at the time the bug happened.

That's to be expected.  The tracer records the _longest_ time that 
interrupts were disabled.  When the bug happened, interrupts were 
disabled for a long time, but it may not have been the longest up to 
that point.

> The file now has:
>  cc1-21060   2d.h.0us!: local_clock <-perf_event_update_userpage
>  cc1-21060   2dN.. 3803us+: trace_hardirqs_on_thunk <-retint_careful
>  cc1-21060   2dN.. 3806us+: trace_hardirqs_on_caller <-retint_careful
>  cc1-21060   2dN.. 3812us : 
>  => trace_hardirqs_on_thunk
> 
> but this is with kernel build going on..

The load shouldn't matter much, as far as I know.  Steven Rostedt said
that perf_event_update_userpage shouldn't take 2 ms; therefore we can
be pretty sure that it shouldn't take 3.8 ms.  :-)

Try running the tracer with "echo 1 > options/function-trace".  That 
ought to provide additional useful information.

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

[PATCH v2 2/2] ARM: dts: USB for Tegra114 Dalmore

[Tuomas Tynkkynen]

From: Mikko Perttunen 

Device tree entries for the three EHCI controllers on Tegra114.
Enables the the third controller (USB host) on Dalmore.

Signed-off-by: Mikko Perttunen 
---
 arch/arm/boot/dts/tegra114-dalmore.dts |  9 +
 arch/arm/boot/dts/tegra114.dtsi| 62 ++
 2 files changed, 71 insertions(+)

diff --git a/arch/arm/boot/dts/tegra114-dalmore.dts 
b/arch/arm/boot/dts/tegra114-dalmore.dts
index cb640eb..f3fc2b0 100644
--- a/arch/arm/boot/dts/tegra114-dalmore.dts
+++ b/arch/arm/boot/dts/tegra114-dalmore.dts
@@ -870,6 +870,15 @@
non-removable;
};
 
+   usb@7d008000 {
+   status = "okay";
+   };
+
+   usb-phy@7d008000 {
+   status = "okay";
+   vbus-supply = <&usb3_vbus_reg>;
+   };
+
clocks {
compatible = "simple-bus";
#address-cells = <1>;
diff --git a/arch/arm/boot/dts/tegra114.dtsi b/arch/arm/boot/dts/tegra114.dtsi
index abf6c40..2905145 100644
--- a/arch/arm/boot/dts/tegra114.dtsi
+++ b/arch/arm/boot/dts/tegra114.dtsi
@@ -430,6 +430,68 @@
status = "disable";
};
 
+   usb@7d00 {
+   compatible = "nvidia,tegra30-ehci", "usb-ehci";
+   reg = <0x7d00 0x4000>;
+   interrupts = ;
+   phy_type = "utmi";
+   clocks = <&tegra_car TEGRA114_CLK_USBD>;
+   nvidia,phy = <&phy1>;
+   status = "disabled";
+   };
+
+   phy1: usb-phy@7d00 {
+   compatible = "nvidia,tegra30-usb-phy";
+   reg = <0x7d00 0x4000 0x7d00 0x4000>;
+   phy_type = "utmi";
+   clocks = <&tegra_car TEGRA114_CLK_USBD>,
+<&tegra_car TEGRA114_CLK_PLL_U>,
+<&tegra_car TEGRA114_CLK_USBD>;
+   clock-names = "reg", "pll_u", "utmi-pads";
+   nvidia,hssync-start-delay = <0>;
+   nvidia,idle-wait-delay = <17>;
+   nvidia,elastic-limit = <16>;
+   nvidia,term-range-adj = <6>;
+   nvidia,xcvr-setup = <9>;
+   nvidia,xcvr-lsfslew = <0>;
+   nvidia,xcvr-lsrslew = <3>;
+   nvidia,hssquelch-level = <2>;
+   nvidia,hsdiscon-level = <5>;
+   nvidia,xcvr-hsslew = <12>;
+   status = "disabled";
+   };
+
+   usb@7d008000 {
+   compatible = "nvidia,tegra30-ehci", "usb-ehci";
+   reg = <0x7d008000 0x4000>;
+   interrupts = ;
+   phy_type = "utmi";
+   clocks = <&tegra_car TEGRA114_CLK_USB3>;
+   nvidia,phy = <&phy3>;
+   status = "disabled";
+   };
+
+   phy3: usb-phy@7d008000 {
+   compatible = "nvidia,tegra30-usb-phy";
+   reg = <0x7d008000 0x4000 0x7d00 0x4000>;
+   phy_type = "utmi";
+   clocks = <&tegra_car TEGRA114_CLK_USB3>,
+<&tegra_car TEGRA114_CLK_PLL_U>,
+<&tegra_car TEGRA114_CLK_USBD>;
+   clock-names = "reg", "pll_u", "utmi-pads";
+   nvidia,hssync-start-delay = <0>;
+   nvidia,idle-wait-delay = <17>;
+   nvidia,elastic-limit = <16>;
+   nvidia,term-range-adj = <6>;
+   nvidia,xcvr-setup = <9>;
+   nvidia,xcvr-lsfslew = <0>;
+   nvidia,xcvr-lsrslew = <3>;
+   nvidia,hssquelch-level = <2>;
+   nvidia,hsdiscon-level = <5>;
+   nvidia,xcvr-hsslew = <12>;
+   status = "disabled";
+   };
+
cpus {
#address-cells = <1>;
#size-cells = <0>;
-- 
1.8.1.5

--
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 v2 1/2] ARM: DTS: tegra: Add USB entries for Tegra30

[Tuomas Tynkkynen]

Add device tree entries for the 3 USB controllers and PHYs and
enable the third controller on Cardhu and Beaver boards.

Fix VBUS regulator entries on Beaver. The GPIO pins were wrong.
Also, internal pullups need to be enabled on those pins.

Signed-off-by: Tuomas Tynkkynen 
---
v2: Use internal pullups on the VBUS regulator GPIOs.
 arch/arm/boot/dts/tegra30-beaver.dts  | 22 -
 arch/arm/boot/dts/tegra30-cardhu.dtsi |  9 
 arch/arm/boot/dts/tegra30.dtsi| 86 +++
 3 files changed, 115 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/tegra30-beaver.dts 
b/arch/arm/boot/dts/tegra30-beaver.dts
index 87c5f7b..fa6f6a6 100644
--- a/arch/arm/boot/dts/tegra30-beaver.dts
+++ b/arch/arm/boot/dts/tegra30-beaver.dts
@@ -76,6 +76,11 @@
nvidia,pull = <0>;
nvidia,tristate = <0>;
};
+   pex_l1_prsnt_n_pdd4 {
+   nvidia,pins =   "pex_l1_prsnt_n_pdd4",
+   "pex_l1_clkreq_n_pdd6";
+   nvidia,pull = <2>;
+   };
sdio3 {
nvidia,pins = "drive_sdio3";
nvidia,high-speed-mode = <0>;
@@ -85,6 +90,10 @@
nvidia,slew-rate-rising = <1>;
nvidia,slew-rate-falling = <1>;
};
+   gpv {
+   nvidia,pins = "drive_gpv";
+   nvidia,pull-up-strength = <16>;
+   };
};
};
 
@@ -285,6 +294,15 @@
non-removable;
};
 
+   usb@7d008000 {
+   status = "okay";
+   };
+
+   usb-phy@7d008000 {
+   vbus-supply = <&usb3_vbus_reg>;
+   status = "okay";
+   };
+
clocks {
compatible = "simple-bus";
#address-cells = <1>;
@@ -357,7 +375,7 @@
regulator-min-microvolt = <500>;
regulator-max-microvolt = <500>;
enable-active-high;
-   gpio = <&gpio TEGRA_GPIO(I, 4) GPIO_ACTIVE_HIGH>;
+   gpio = <&gpio TEGRA_GPIO(DD, 6) GPIO_ACTIVE_HIGH>;
gpio-open-drain;
vin-supply = <&vdd_5v_in_reg>;
};
@@ -369,7 +387,7 @@
regulator-min-microvolt = <500>;
regulator-max-microvolt = <500>;
enable-active-high;
-   gpio = <&gpio TEGRA_GPIO(H, 7) GPIO_ACTIVE_HIGH>;
+   gpio = <&gpio TEGRA_GPIO(DD, 4) GPIO_ACTIVE_HIGH>;
gpio-open-drain;
vin-supply = <&vdd_5v_in_reg>;
};
diff --git a/arch/arm/boot/dts/tegra30-cardhu.dtsi 
b/arch/arm/boot/dts/tegra30-cardhu.dtsi
index f65b53d..7af52e4 100644
--- a/arch/arm/boot/dts/tegra30-cardhu.dtsi
+++ b/arch/arm/boot/dts/tegra30-cardhu.dtsi
@@ -330,6 +330,15 @@
non-removable;
};
 
+   usb@7d008000 {
+   status = "okay";
+   };
+
+   usb-phy@7d008000 {
+   vbus-supply = <&usb3_vbus_reg>;
+   status = "okay";
+   };
+
clocks {
compatible = "simple-bus";
#address-cells = <1>;
diff --git a/arch/arm/boot/dts/tegra30.dtsi b/arch/arm/boot/dts/tegra30.dtsi
index d8783f0..9920797 100644
--- a/arch/arm/boot/dts/tegra30.dtsi
+++ b/arch/arm/boot/dts/tegra30.dtsi
@@ -561,6 +561,92 @@
status = "disabled";
};
 
+   usb@7d00 {
+   compatible = "nvidia,tegra30-ehci", "usb-ehci";
+   reg = <0x7d00 0x4000>;
+   interrupts = ;
+   phy_type = "utmi";
+   clocks = <&tegra_car TEGRA30_CLK_USBD>;
+   nvidia,needs-double-reset;
+   nvidia,phy = <&phy1>;
+   status = "disabled";
+   };
+
+   phy1: usb-phy@7d00 {
+   compatible = "nvidia,tegra30-usb-phy";
+   reg = <0x7d00 0x4000 0x7d00 0x4000>;
+   phy_type = "utmi";
+   clocks = <&tegra_car TEGRA30_CLK_USBD>,
+<&tegra_car TEGRA30_CLK_PLL_U>,
+<&tegra_car TEGRA30_CLK_USBD>;
+   clock-names = "reg", "pll_u", "utmi-pads";
+   nvidia,hssync-start-delay = <9>;
+   nvidia,idle-wait-delay = <17>;
+   nvidia,elastic-limit = <16>;
+   nvidia,term-range-adj = <6>;
+   nvidia,xcvr-setup = <51>;
+   nvidia.xcvr-setup-use-fuses;
+   nvidia,xcvr-lsfslew = <1>;
+   nvidia,xcvr-lsrslew = <1>;
+   nvidia,xcvr-hsslew = <32>;

[PATCH v2 0/2] Device tree changes for Tegra30 and Tegra114 USB Host support

[Tuomas Tynkkynen]

Hi all,

Here's the device tree changes required for USB Host support on Tegra30 and
Tegra114. This enables USB Host on the Cardhu's dock connector port and on the
single built-in A-ports on Dalmore and Beaver.

Diff from v1:
 - Use internal pullups on the VBUS regulator GPIOs on Beaver.

Mikko Perttunen (1):
  ARM: dts: USB for Tegra114 Dalmore

Tuomas Tynkkynen (1):
  ARM: DTS: tegra: Add USB entries for Tegra30

 arch/arm/boot/dts/tegra114-dalmore.dts |  9 
 arch/arm/boot/dts/tegra114.dtsi| 62 
 arch/arm/boot/dts/tegra30-beaver.dts   | 22 -
 arch/arm/boot/dts/tegra30-cardhu.dtsi  |  9 
 arch/arm/boot/dts/tegra30.dtsi | 86 ++
 5 files changed, 186 insertions(+), 2 deletions(-)

-- 
1.8.1.5

--
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 Interrupt Transaction Scheduling

[Fabio Estevam]

Hi Nate,

On Tue, Jul 30, 2013 at 6:33 PM, Stoddard, Nate (GE Healthcare)
 wrote:

> So you would expect a temporary CPU increase when a device is connected or 
> reset since the scheduler will need to set up when the packets will be 
> transferred.  Once this is complete, the CPU should return to a lower amount 
> as

The reset function at drivers/usb/chipidea/core.c has the following:

int hw_device_reset(struct ci_hdrc *ci, u32 mode)
{
/* should flush & stop before reset */
hw_write(ci, OP_ENDPTFLUSH, ~0, ~0);
hw_write(ci, OP_USBCMD, USBCMD_RS, 0);

hw_write(ci, OP_USBCMD, USBCMD_RST, USBCMD_RST);
while (hw_read(ci, OP_USBCMD, USBCMD_RST))
udelay(10); /* not RTOS friendly */

Maybe this udelay is impacting your performance?

It seems that this should be rewritten to avoid the busy loop.
--
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: ohci-at91: add usb_clk for transition to common clk framework

[boris brezillon]

On 01/08/2013 16:39, Alan Stern wrote:

On Thu, 1 Aug 2013, Boris BREZILLON wrote:


The AT91 PMC (Power Management Controller) provides an USB clock used by
USB Full Speed host (ohci) and USB Full Speed device (udc).
The usb drivers (ohci and udc) must configure this clock to 48Mhz.
This configuration was formely done in mach-at91/clock.c, but this
implementation will be removed when moving to common clk framework.

This patch adds support for usb clock retrieval and configuration, and is
backward compatible with the current at91 clk implementation (if usb clk
is not found, it does not configure/enable it).

Signed-off-by: Boris BREZILLON 
@@ -163,6 +169,8 @@ static int usb_hcd_at91_probe(const struct hc_driver 
*driver,
goto err5;
}
  
+	uclk = clk_get(&pdev->dev, "usb_clk");

What happens if uclk isn't found but it is needed?
It will not fail but I guess the usb host won't work as the clock won't 
be correctly

configured.

I agree with you: this is not a good solution.

Another option is to keep the previous version of this patch and put 
uclk handling

in "#ifdef CONFIG_COMMON_CLK #endif" sections.

Would this be acceptable ?



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 1/2] ARM: DTS: tegra: Add USB entries for Tegra30

[Tuomas Tynkkynen]

On 08/01/2013 01:13 AM, Stephen Warren wrote:
> On 07/31/2013 11:42 AM, Tuomas Tynkkynen wrote:
>> Add device tree entries for the 3 USB controllers and PHYs and
>> enable the third controller on Cardhu and Beaver boards.
>>
>> Fix VBUS regulator entries on Beaver. The GPIO pins were wrong.
> 
> That much is correct.
> 
>> Also, a third GPIO is required to power the pullup resistors that drive
>> the VBUS voltage switches, so add an regulator entry for that.
> 
> That is not true. GMI_AD13 / PH5 / 61 is a signal that pulls up all of
> USB1 VBUS, USB3 VBUS, and GMI_AD15, which as far as I can tell is
> entirely unrelated to USB in any way.

I sent a v2 that enables the internal pullups on those pins.

> This part of the change should be removed. I know you mentioned that
> downstream does this, but that means very little; there are many
> mistakes there.

It looks like the pullup resistor from PH5 to GMI_AD15 was added in a later 
board revision,
so the HW guys are to blame this time.
--
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: Audio I/O parameters

[Alan Stern]

On Thu, 1 Aug 2013, James Stone wrote:

> I've got some error messages written to syslog now - with no audible
> effect on audio processing:

> Aug  1 01:12:36 blueberry kernel: [ 6233.028335] ehci-pci
> :00:12.2: iso underrun 8800c872db00 (1407+0 < 1471)

That's an impressive one.  It indicates no interrupts occurred during a
period of at least (1471 - 1407)/8 = 8 ms!  That should have produced
an audible click, if you were listening at the right time and if a 
nonzero sound was playing.

> Aug  1 01:12:36 blueberry kernel: [ 6233.028341] ehci-pci
> :00:12.2: iso underrun 88002e6f6800 (1392+7 < 1471)
> Aug  1 01:12:36 blueberry kernel: [ 6233.028347] ehci-pci
> :00:12.2: iso underrun 8800b65b5e00 (1401+7 < 1471)
...
> Aug  1 01:12:36 blueberry kernel: [ 6233.028462] ehci-pci
> :00:12.2: iso underrun 88002e6f6800 (1464+7 < 1472)

These messages show the audio driver catching up.

> Aug  1 01:12:36 blueberry kernel: [ 6233.028493] ehci-pci
> :00:13.2: iso underrun 8800c9fa6900 (2535+0 < 2606)

I don't understand what happened here.  The microframe number increased
by 1134 from the preceding message, indicating that some 140 ms had
elapsed, but the kernel's timestamp went up by only 30 us.

Something is very wrong in your system.  Maybe in the EHCI hardware, 
maybe in the BIOS firmware, maybe somewhere else.

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: Audio I/O parameters

[Alan Stern]

On Thu, 1 Aug 2013, Clemens Ladisch wrote:

> > It seems likely that the error is caused by an SMI taking too much
> > time.  At least, we seem to have ruled out everything else.  Besides,
> > this change has to be made eventually in any case -- underruns can
> > occur at any time, in principle, and they shouldn't cause the audio
> > driver to fail.
> 
> Well, the failure is a bug in snd-usb-audio: when usb_submit_urb fails,
> it should report the underrun so that the stream can be stopped and
> restarted cleanly.  This would be done by the snd_pcm_stop() call in
> endpoint.c which is currently commented out because of locking problems.

Should we have some sort of threshold for how long an underrun can be 
before it causes a submission failure?

Presumably an underrun of a few ms should not cause the stream to be 
stopped and restarted.  An underrun of 100 ms or more probably should.  
Where do we put the cutoff?

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 4/4] USBNET: ax88179_178a: enable tso if host supports sg dma

[Grant Grundler]

On Wed, Jul 31, 2013 at 3:51 AM, Ming Lei  wrote:
> This patch enables 'can_dma_sg' flag for ax88179_178a device
> if the attached host controller supports building packet from
> discontinuous buffers(DMA SG is possible), so both frame header
> and skb data buffers can be passed to usb stack via urb->sg,
> then skb data copy can be saved.
>
> With the patch, CPU utilization decreased much in iperf test at
> client mode.
>
> Signed-off-by: Ming Lei 
> ---
>  drivers/net/usb/ax88179_178a.c |   30 ++
>  1 file changed, 30 insertions(+)
>
> diff --git a/drivers/net/usb/ax88179_178a.c b/drivers/net/usb/ax88179_178a.c
> index 5a468f3..c75bded 100644
> --- a/drivers/net/usb/ax88179_178a.c
> +++ b/drivers/net/usb/ax88179_178a.c
> @@ -1031,12 +1031,20 @@ static int ax88179_bind(struct usbnet *dev, struct 
> usb_interface *intf)
> dev->mii.phy_id = 0x03;
> dev->mii.supports_gmii = 1;
>
> +   if (dev->udev->bus->no_sg_limit)
> +   dev->can_dma_sg = 1;
> +
> dev->net->features |= NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM |
>   NETIF_F_RXCSUM;
>
> dev->net->hw_features |= NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM |
>  NETIF_F_RXCSUM;
>
> +   if (dev->can_dma_sg) {
> +   dev->net->features |= NETIF_F_SG | NETIF_F_TSO;
> +   dev->net->hw_features |= NETIF_F_SG | NETIF_F_TSO;
> +   }
> +
> /* Enable checksum offload */
> *tmp = AX_RXCOE_IP | AX_RXCOE_TCP | AX_RXCOE_UDP |
>AX_RXCOE_TCPV6 | AX_RXCOE_UDPV6;
> @@ -1170,12 +1178,30 @@ ax88179_tx_fixup(struct usbnet *dev, struct sk_buff 
> *skb, gfp_t flags)
> int mss = skb_shinfo(skb)->gso_size;
> int headroom;
> int tailroom;
> +   struct skb_data *entry = (struct skb_data *)skb->cb;
>
> tx_hdr1 = skb->len;
> tx_hdr2 = mss;
> if (((skb->len + 8) % frame_size) == 0)
> tx_hdr2 |= 0x80008000;  /* Enable padding */
>
> +   if (dev->can_dma_sg) {
> +   if (!(entry->header = kmalloc(8, GFP_ATOMIC)))
> +   goto no_sg;
> +
> +   entry->length = 8;
> +   cpu_to_le32s(&tx_hdr1);
> +   cpu_to_le32s(&tx_hdr2);

http://lxr.free-electrons.com/source/include/linux/byteorder/generic.h#L111
http://lxr.free-electrons.com/ident?i=__cpu_to_le32s

IIRC, cpu_to_leXX() macros return the endian "corrected" value.
In other words, they need to be assigned to something, no?

thanks,
grant

> +   memcpy(entry->header, &tx_hdr1, 4);
> +   memcpy(entry->header + 4, &tx_hdr2, 4);
> +
> +   return skb;
> +   } else {
> +no_sg:
> +   entry->header = NULL;
> +   entry->length = 0;
> +   }
> +
> headroom = skb_headroom(skb);
> tailroom = skb_tailroom(skb);
>
> @@ -1323,6 +1349,10 @@ static int ax88179_reset(struct usbnet *dev)
>
> dev->net->hw_features |= NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM |
>  NETIF_F_RXCSUM;
> +   if (dev->can_dma_sg) {
> +   dev->net->features |= NETIF_F_SG | NETIF_F_TSO;
> +   dev->net->hw_features |= NETIF_F_SG | NETIF_F_TSO;
> +   }
>
> /* Enable checksum offload */
> *tmp = AX_RXCOE_IP | AX_RXCOE_TCP | AX_RXCOE_UDP |
> --
> 1.7.9.5
>
--
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/4] USBNET: ax88179_178a: enable tso if host supports sg dma

[Eric Dumazet]

On Thu, 2013-08-01 at 08:30 -0700, Grant Grundler wrote:

> http://lxr.free-electrons.com/source/include/linux/byteorder/generic.h#L111
> http://lxr.free-electrons.com/ident?i=__cpu_to_le32s
> 
> IIRC, cpu_to_leXX() macros return the endian "corrected" value.
> In other words, they need to be assigned to something, no?
> 

Nope, this in in-place byte swapping (for Big Endian only)


--
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: [RFC] usb: gadget: start to drop endpoint naming conventions

[Alan Stern]

On Thu, 1 Aug 2013, Felipe Balbi wrote:

> Hi folks,
> 
> as we all know naming conventions are fragile and easy to break. We've
> had weird endpoint naming conventions for far too long in the gadget
> framework.
> 
> I'm trying to come up with means to get rid of that and, one of the
> ideas, was to add transfer support flags to our struct usb_ep which gets
> initialized by the UDC driver. Then ep_matches() can use those flags to
> check if it should return that endpoint or not.

The endpoint naming convention currently determines type and direction.  
It works okay for simple cases but not for more complicated ones.  For 
example, it can't handle endpoints that support bulk or interrupt but 
not isochronous.  If you really want to make this general, the way to 
do it is to have separate bitflags for: control, bulk-in, bulk-out, ...

For additional restrictions, I agree that a standardized system is 
needed.

> The ***UNFINISHED*** patch below does just that and shows an example of
> how to initialize such flags on dwc3. Please go over it and let me know
> what you guys think.
> 
> From: Felipe Balbi 
> 
> usb: gadget: add transfer support flags for struct usb_ep
> 
> NYET-Signed-off-by: Felipe Balbi 
> ---
> 
> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
> index f168eae..0bc3621 100644
> --- a/drivers/usb/dwc3/gadget.c
> +++ b/drivers/usb/dwc3/gadget.c
> @@ -1655,6 +1655,9 @@ static int dwc3_gadget_init_hw_endpoints(struct dwc3 
> *dwc,
>   if (epnum == 0 || epnum == 1) {
>   dep->endpoint.maxpacket = 512;
>   dep->endpoint.maxburst = 1;
> +
> + dep->endpoint.supports_control = true;

Does DWC3 really support control transfers on two endpoints?  I have 
never heard of a USB device with a control endpoint other than ep0.

> diff --git a/drivers/usb/gadget/epautoconf.c b/drivers/usb/gadget/epautoconf.c
> index a777f7b..bf72538 100644
> --- a/drivers/usb/gadget/epautoconf.c
> +++ b/drivers/usb/gadget/epautoconf.c
> @@ -57,6 +57,27 @@ ep_matches (
>   if (NULL != ep->driver_data)
>   return 0;
>  
> + /* first try with transfer support flags */
> + type = desc->bmAttributes & USB_ENDPOINT_XFERTYPE_MASK;
> + switch (type) {
> + case USB_ENDPOINT_XFER_CONTROL:
> + if (ep->supports_control)
> + return 0;
> + break;
> + case USB_ENDPOINT_XFER_BULK:
> + if (ep->supports_bulk)
> + return 0;
> + break;
> + case USB_ENDPOINT_XFER_INT:
> + if (ep->supports_interrupt)
> + return 0;
> + break;
> + case USB_ENDPOINT_XFER_ISOC:
> + if (ep->supports_isochronous)
> + return 0;
> + break;
> + }

The tests here are backwards.  Returning 0 means the endpoint _doesn't_
match the requirements.  So for example, the first test above should be
"if (!ep->supports_control)".

You also have to handle UDC drivers that don't define the transfer
support flags.

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: [RFC] usb: gadget: start to drop endpoint naming conventions

[Felipe Balbi]

Hi,

On Thu, Aug 01, 2013 at 11:44:59AM -0400, Alan Stern wrote:
> On Thu, 1 Aug 2013, Felipe Balbi wrote:
> 
> > Hi folks,
> > 
> > as we all know naming conventions are fragile and easy to break. We've
> > had weird endpoint naming conventions for far too long in the gadget
> > framework.
> > 
> > I'm trying to come up with means to get rid of that and, one of the
> > ideas, was to add transfer support flags to our struct usb_ep which gets
> > initialized by the UDC driver. Then ep_matches() can use those flags to
> > check if it should return that endpoint or not.
> 
> The endpoint naming convention currently determines type and direction.  
> It works okay for simple cases but not for more complicated ones.  For 
> example, it can't handle endpoints that support bulk or interrupt but 
> not isochronous.  If you really want to make this general, the way to 
> do it is to have separate bitflags for: control, bulk-in, bulk-out, ...

not bulk-in/bulk-out. I was thinking of having transfer and direction
completely separated. Or would there be cases where endpoint support
bulk in/out but isoc in-only ?

I don't think so...

-- 
balbi


signature.asc
Description: Digital signature

Re: Ejected Nook (usb mass storage) prevents suspend

[Alan Stern]

On Thu, 1 Aug 2013, Oliver Neukum wrote:

> On Wed, 2013-07-31 at 11:13 -0400, Alan Stern wrote:
> 
> > More importantly, if we already know that the medium is not present or
> > has been changed since it was last used, then there's no reason to call
> > sd_sync_cache() at all.
> 
> Like this?

Yes, I like this a lot better, except I would put the test for 
!sdkp->media_present in sd_suspend_common() -- no need to print the 
"Synchronizing SCSI Cache" message if you're not going to go through 
with it.

What do the SCSI people think?

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] USB: ohci-at91: add usb_clk for transition to common clk framework

[Alan Stern]

On Thu, 1 Aug 2013, boris brezillon wrote:

> > What happens if uclk isn't found but it is needed?
> It will not fail but I guess the usb host won't work as the clock won't 
> be correctly
> configured.
> 
> I agree with you: this is not a good solution.
> 
> Another option is to keep the previous version of this patch and put 
> uclk handling
> in "#ifdef CONFIG_COMMON_CLK #endif" sections.
> 
> Would this be acceptable ?

Yes.  However, a more elegant approach is to protect the relevant 
statements with: if (defined(CONFIG_COMMON_CLK)).  This preprocessor 
evaluates this to a 0 or 1, so the compiler will not generate output 
for the protected source code if the symbol isn't defined.

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: [RFC] usb: gadget: start to drop endpoint naming conventions

[Alan Stern]

On Thu, 1 Aug 2013, Felipe Balbi wrote:

> > The endpoint naming convention currently determines type and direction.  
> > It works okay for simple cases but not for more complicated ones.  For 
> > example, it can't handle endpoints that support bulk or interrupt but 
> > not isochronous.  If you really want to make this general, the way to 
> > do it is to have separate bitflags for: control, bulk-in, bulk-out, ...
> 
> not bulk-in/bulk-out. I was thinking of having transfer and direction
> completely separated. Or would there be cases where endpoint support
> bulk in/out but isoc in-only ?
> 
> I don't think so...

Yeah, you're probably right.  But you still need flags for the two 
directions.  I'm pretty sure there are endpoints that are in-only or 
out-only.

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 4/4] USBNET: ax88179_178a: enable tso if host supports sg dma

[Grant Grundler]

On Thu, Aug 1, 2013 at 8:36 AM, Eric Dumazet  wrote:
...
>> IIRC, cpu_to_leXX() macros return the endian "corrected" value.
>> In other words, they need to be assigned to something, no?
>
> Nope, this in in-place byte swapping (for Big Endian only)

Ah ok - thanks for clarifying. I couldn't find the implementation and
this documentation also helped:
   http://kernelnewbies.org/EndianIssues

I don't remember implementing in-place endian correction for
arch/parisc (which is BE). I was expecting to find a generic
definition that did a load/swap/store and didn't.

thanks,
grant
--
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: lsusb doesn't handle 32 bits Usage tags.

[Paul Chavent]

On 08/01/2013 03:54 AM, Greg KH wrote:

On Sun, Jul 07, 2013 at 09:32:55PM +0200, pchavent wrote:

On Sun, 7 Jul 2013 10:37:59 -0700, Greg KH wrote:

On Sun, Jul 07, 2013 at 07:17:40PM +0200, pchavent wrote:

Hi.

lsusb doesn't handle 32 bits Usage tags.

I've tried to do a patch but i'm not confident in its
implementation.


Do you have a HID descriptor with a 32bit usage tag?  I don't think
anyone has seen these before, are they new?

thanks,

greg k-h


Hi

Sorry, i sent you a wrong patch (i join a better one).

Indeed, i build a device that convert some pwm signals for flight
simulation purpose. I would like to give several "Usage" for each
way (standard joystick, plane simulation, helicopter simulation). So
i have followed the examples in the "Universal Serial Bus HID Usage
Tables" (appendix b page 145) [1].

I know that linux doesn't care about alternative usage tags, but for
debugging my device i would like to be able to see a good Report
Descriptor.


Thanks, now applied.

greg k-h



Thank you !
--
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/6] USB tree changes for Tegra30 and Tegra114 USB Host support

[Stephen Warren]

On 08/01/2013 07:02 AM, Tuomas Tynkkynen wrote:
> On 08/01/2013 02:22 AM, Stephen Warren wrote:
>> On 07/31/2013 11:41 AM, Tuomas Tynkkynen wrote:
>>> Hi all,
>>>
>>> Here are the patches for the USB tree to enable USB Host support on Tegra30 
>>> and
>>> Tegra114. These are based on my and Mikko's cleanup patches that just got
>>> merged to Felipe's tree.
>>
>> This series works fine for me on Dalmore. However, on Beaver, I see the
>> following:
>>
>> [2.428480] platform 7d008000.usb: Driver tegra-ehci requests probe
>> deferral
>>
>> ... which never seems to be resolved. You can take a look at my
>> linux-next_common branch to repro this. Does Beaver work for you?
>>
> 
> The clock driver patch is missing from your branch. Applying it should fix 
> that.

Oh so it does. Sorry for forgetting about that patch. Given that, the
series,

Tested-by: Stephen Warren 

I'll also try to review/ack the patches ASAP.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 1/2] ARM: DTS: tegra: Add USB entries for Tegra30

[Stephen Warren]

On 08/01/2013 09:00 AM, Tuomas Tynkkynen wrote:
> Add device tree entries for the 3 USB controllers and PHYs and
> enable the third controller on Cardhu and Beaver boards.
> 
> Fix VBUS regulator entries on Beaver. The GPIO pins were wrong.
> Also, internal pullups need to be enabled on those pins.
> 
> Signed-off-by: Tuomas Tynkkynen 
> ---
> v2: Use internal pullups on the VBUS regulator GPIOs.

Thanks, this version looks good.

Thierry, can you please validate that the gpv group pull strength change
doesn't have any negative affect on your PCIe patches. Thanks.
--
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: Audio I/O parameters

[Alan Stern]

On Thu, 1 Aug 2013, James Stone wrote:

> > SMIs are controlled by the BIOS, not by the kernel.  I don't think
> > changing the kernel would affect their timings.
> >
> 
> Hmm.. ok. So do I need to see if there is a bios update/report this to
> motherboard manufacturer?

If there's an update available, you ought to apply it.

I don't know if talking to the motherboard manufacturer will accomplish 
anything.  They're not likely to listen to you, and in any case, they 
probably didn't write their own BIOS.

> > Okay, so the USB controllers do share IRQ lines.  Were you using the
> > other USB buses when the errors occurred?
> 
> Webcam microphone might have been on.

You should try testing with no other USB activity going on.  Just in
case.

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

[PATCH v2] usb: gadget: at91_udc: add usb_clk for transition to common clk framework

[Boris BREZILLON]

The AT91 PMC (Power Management Controller) provides an USB clock used by
USB Full Speed host (ohci) and USB Full Speed device (udc).
The usb drivers (ohci and udc) must configure this clock to 48Mhz.
This configuration was formely done in mach-at91/clock.c, but this
implementation will be removed when moving to common clk framework.

This patch adds support for usb clock retrieval and configuration, and is
backward compatible with the current at91 clk implementation (if usb clk
is not found, it does not configure/enable it).

Changes since v1:
 - use IS_ENABLED(CONFIG_COMMON_CLK) to isolate new at91 clk support

Signed-off-by: Boris BREZILLON 
---
 drivers/usb/gadget/at91_udc.c |   21 +++--
 drivers/usb/gadget/at91_udc.h |2 +-
 2 files changed, 20 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/gadget/at91_udc.c b/drivers/usb/gadget/at91_udc.c
index fce8e4e..5c7c8bb 100644
--- a/drivers/usb/gadget/at91_udc.c
+++ b/drivers/usb/gadget/at91_udc.c
@@ -870,6 +870,11 @@ static void clk_on(struct at91_udc *udc)
if (udc->clocked)
return;
udc->clocked = 1;
+
+   if (IS_ENABLED(CONFIG_COMMON_CLK)) {
+   clk_set_rate(udc->uclk, 4800);
+   clk_prepare_enable(udc->uclk);
+   }
clk_prepare_enable(udc->iclk);
clk_prepare_enable(udc->fclk);
 }
@@ -882,6 +887,8 @@ static void clk_off(struct at91_udc *udc)
udc->gadget.speed = USB_SPEED_UNKNOWN;
clk_disable_unprepare(udc->fclk);
clk_disable_unprepare(udc->iclk);
+   if (IS_ENABLED(CONFIG_COMMON_CLK))
+   clk_disable_unprepare(udc->uclk);
 }
 
 /*
@@ -1774,10 +1781,12 @@ static int at91udc_probe(struct platform_device *pdev)
/* get interface and function clocks */
udc->iclk = clk_get(dev, "udc_clk");
udc->fclk = clk_get(dev, "udpck");
-   if (IS_ERR(udc->iclk) || IS_ERR(udc->fclk)) {
+   if (IS_ENABLED(CONFIG_COMMON_CLK))
+   udc->uclk = clk_get(dev, "usb_clk");
+   if (IS_ERR(udc->iclk) || IS_ERR(udc->fclk) ||
+   (IS_ENABLED(CONFIG_COMMON_CLK) && IS_ERR(udc->uclk))) {
DBG("clocks missing\n");
retval = -ENODEV;
-   /* NOTE: we "know" here that refcounts on these are NOPs */
goto fail1;
}
 
@@ -1851,6 +1860,12 @@ fail3:
 fail2:
free_irq(udc->udp_irq, udc);
 fail1:
+   if (IS_ENABLED(CONFIG_COMMON_CLK) && !IS_ERR(udc->uclk))
+   clk_put(udc->uclk);
+   if (!IS_ERR(udc->fclk))
+   clk_put(udc->fclk);
+   if (!IS_ERR(udc->iclk))
+   clk_put(udc->iclk);
iounmap(udc->udp_baseaddr);
 fail0a:
if (cpu_is_at91rm9200())
@@ -1894,6 +1909,8 @@ static int __exit at91udc_remove(struct platform_device 
*pdev)
 
clk_put(udc->iclk);
clk_put(udc->fclk);
+   if (IS_ENABLED(CONFIG_COMMON_CLK))
+   clk_put(udc->uclk);
 
return 0;
 }
diff --git a/drivers/usb/gadget/at91_udc.h b/drivers/usb/gadget/at91_udc.h
index e647d1c..0175246 100644
--- a/drivers/usb/gadget/at91_udc.h
+++ b/drivers/usb/gadget/at91_udc.h
@@ -126,7 +126,7 @@ struct at91_udc {
unsignedactive_suspend:1;
u8  addr;
struct at91_udc_databoard;
-   struct clk  *iclk, *fclk;
+   struct clk  *iclk, *fclk, *uclk;
struct platform_device  *pdev;
struct proc_dir_entry   *pde;
void __iomem*udp_baseaddr;
-- 
1.7.9.5

--
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 v2] USB: ohci-at91: add usb_clk for transition to common clk framework

[Boris BREZILLON]

The AT91 PMC (Power Management Controller) provides an USB clock used by
USB Full Speed host (ohci) and USB Full Speed device (udc).
The usb drivers (ohci and udc) must configure this clock to 48Mhz.
This configuration was formely done in mach-at91/clock.c, but this
implementation will be removed when moving to common clk framework.

This patch adds support for usb clock retrieval and configuration, and is
backward compatible with the current at91 clk implementation (if usb clk
is not found, it does not configure/enable it).

Changes since v1:
 - use IS_ENABLED(CONFIG_COMMON_CLK) to isolate new at91 clk support

Signed-off-by: Boris BREZILLON 
---
 drivers/usb/host/ohci-at91.c |   23 +--
 1 file changed, 21 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/host/ohci-at91.c b/drivers/usb/host/ohci-at91.c
index 9677f68..db60048 100644
--- a/drivers/usb/host/ohci-at91.c
+++ b/drivers/usb/host/ohci-at91.c
@@ -31,8 +31,8 @@
 #define at91_for_each_port(index)  \
for ((index) = 0; (index) < AT91_MAX_USBH_PORTS; (index)++)
 
-/* interface and function clocks; sometimes also an AHB clock */
-static struct clk *iclk, *fclk, *hclk;
+/* interface, function and usb clocks; sometimes also an AHB clock */
+static struct clk *iclk, *fclk, *uclk, *hclk;
 static int clocked;
 
 extern int usb_disabled(void);
@@ -41,6 +41,10 @@ extern int usb_disabled(void);
 
 static void at91_start_clock(void)
 {
+   if (IS_ENABLED(CONFIG_COMMON_CLK)) {
+   clk_set_rate(uclk, 4800);
+   clk_prepare_enable(uclk);
+   }
clk_prepare_enable(hclk);
clk_prepare_enable(iclk);
clk_prepare_enable(fclk);
@@ -52,6 +56,8 @@ static void at91_stop_clock(void)
clk_disable_unprepare(fclk);
clk_disable_unprepare(iclk);
clk_disable_unprepare(hclk);
+   if (IS_ENABLED(CONFIG_COMMON_CLK))
+   clk_disable_unprepare(uclk);
clocked = 0;
 }
 
@@ -162,6 +168,14 @@ static int usb_hcd_at91_probe(const struct hc_driver 
*driver,
retval = PTR_ERR(hclk);
goto err5;
}
+   if (IS_ENABLED(CONFIG_COMMON_CLK)) {
+   uclk = clk_get(&pdev->dev, "usb_clk");
+   if (IS_ERR(uclk)) {
+   dev_err(&pdev->dev, "failed to get uclk\n");
+   retval = PTR_ERR(uclk);
+   goto err6;
+   }
+   }
 
at91_start_hc(pdev);
ohci_hcd_init(hcd_to_ohci(hcd));
@@ -173,6 +187,9 @@ static int usb_hcd_at91_probe(const struct hc_driver 
*driver,
/* Error handling */
at91_stop_hc(pdev);
 
+   if (IS_ENABLED(CONFIG_COMMON_CLK))
+   clk_put(uclk);
+ err6:
clk_put(hclk);
  err5:
clk_put(fclk);
@@ -212,6 +229,8 @@ static void usb_hcd_at91_remove(struct usb_hcd *hcd,
release_mem_region(hcd->rsrc_start, hcd->rsrc_len);
usb_put_hcd(hcd);
 
+   if (IS_ENABLED(CONFIG_COMMON_CLK))
+   clk_put(uclk);
clk_put(hclk);
clk_put(fclk);
clk_put(iclk);
-- 
1.7.9.5

--
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: [alsa-devel] Buffer size for ALSA USB PCM audio

[Eldad Zack]

On Tue, 30 Jul 2013, Takashi Iwai wrote:

> At Mon, 29 Jul 2013 21:23:15 +0200,
> Daniel Mack wrote:
> > 
> > On 29.07.2013 20:20, Alan Stern wrote:
> > > data_ep_set_params() checks snd_usb_endpoint_implicit_feedback_sink() 
> > > in three places.  It looks like only the second place is correct.
> > > 
> > > Can you verify whether the other two are right, and explain to me if 
> > > they are?
> > 
> > Which version are you looking at? Eldad Zack recently posted work in
> > that area, but I can't seem to find them anywhere yet in the sound tree.
> > Takashi?
> 
> I'm waiting for the revised patchset (for the issue in patch 9/10
> Clemens pointed).

Sorry for the delayed responses - I'm working on my free time, and that 
can be very sporadic.

I'll get around to that patchset on the weekend.

> > Eldad, as you're likely more into the detail right now - any oppinion on
> > Alan's findings?

Unfortunately I haven't read too deeply into that part of the code.
FWIW, I will take a closer look at the weekend.

Alan, let me know if you plan to post the patch as-is, I'll happily test 
it. 

Cheers,
Eldad
--
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: ohci-at91: add usb_clk for transition to common clk framework

[Sergei Shtylyov]

Hello.

On 08/01/2013 07:56 PM, Alan Stern wrote:


What happens if uclk isn't found but it is needed?



It will not fail but I guess the usb host won't work as the clock won't
be correctly
configured.



I agree with you: this is not a good solution.



Another option is to keep the previous version of this patch and put
uclk handling
in "#ifdef CONFIG_COMMON_CLK #endif" sections.



Would this be acceptable ?



Yes.  However, a more elegant approach is to protect the relevant
statements with: if (defined(CONFIG_COMMON_CLK)).  This preprocessor


   You probably meant IS_ENABLED() or IS_BUIILTIN()? Or is there something I 
don't know about gcc preprocessor?



evaluates this to a 0 or 1, so the compiler will not generate output
for the protected source code if the symbol isn't defined.



Alan Stern


WBR, 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: Buffer size for ALSA USB PCM audio

[Alan Stern]

On Mon, 29 Jul 2013, Clemens Ladisch wrote:

> Alan Stern wrote:
> > Clemens remarked some time ago that keeping the queue full would be
> > trivial, if only he knew how full it needed to be.  The answer to that
> > is given above.  I have been trying to make the appropriate changes,
> > but I'm not finding it "trivial".
> 
> What I meant was that it would be trivial to change the lower bound of
> the period size (from which many queueing parameters are derived).

Here's what I've got.  In turns out the predicting the optimum number
of URBs needed is extremely difficult.  I decided it would be better to
make an overestimate and then to submit URBs as needed, rather than
keeping all of them active all the time.

I ended up with this patch (untested).  It is certainly incomplete 
because it doesn't address endpoints with implicit sync.  It also 
suffers from a race between snd_submit_urbs() and deactivate_urbs():
an URB may be resubmitted after it has been deactivated.  (In all 
fairness, I think this race probably exists in the current code too -- 
there are no spinlocks for synchronization.)

The patch also fixes a couple of unrelated items: MAX_PACKS vs.  
MAX_PACKS_HS, and the maxsize calculation should realize that a packet
can't contain a partial frame.

What do you think of this approach?

Alan Stern



 sound/usb/card.h |7 +
 sound/usb/endpoint.c |  185 +--
 sound/usb/pcm.c  |3 
 3 files changed, 114 insertions(+), 81 deletions(-)

Index: usb-3.11/sound/usb/card.h
===
--- usb-3.11.orig/sound/usb/card.h
+++ usb-3.11/sound/usb/card.h
@@ -4,7 +4,7 @@
 #define MAX_NR_RATES   1024
 #define MAX_PACKS  20
 #define MAX_PACKS_HS   (MAX_PACKS * 8) /* in high speed mode */
-#define MAX_URBS   8
+#define MAX_URBS   11
 #define SYNC_URBS  4   /* always four urbs for sync */
 #define MAX_QUEUE  24  /* try not to exceed this queue length, in ms */
 
@@ -43,6 +43,7 @@ struct snd_urb_ctx {
struct snd_usb_endpoint *ep;
int index;  /* index for urb array */
int packets;/* number of packets per urb */
+   int data_packets;   /* current number of data packets */
int packet_size[MAX_PACKS_HS]; /* size of packets for next submission */
struct list_head ready_list;
 };
@@ -99,6 +100,10 @@ struct snd_usb_endpoint {
int skip_packets;   /* quirks for devices to ignore the 
first n packets
   in a stream */
 
+   unsigned int min_queued_packs;  /* USB hardware queue requirement */
+   unsigned int queued_packs;  /* number of packets currently queued */
+   unsigned int queued_urbs;   /* number of URBs currently queued */
+   int next_urb;   /* next to submit */
spinlock_t lock;
struct list_head list;
 };
Index: usb-3.11/sound/usb/pcm.c
===
--- usb-3.11.orig/sound/usb/pcm.c
+++ usb-3.11/sound/usb/pcm.c
@@ -1328,7 +1328,7 @@ static void prepare_playback_urb(struct
stride = runtime->frame_bits >> 3;
 
frames = 0;
-   urb->number_of_packets = 0;
+   ctx->data_packets = urb->number_of_packets = 0;
spin_lock_irqsave(&subs->lock, flags);
for (i = 0; i < ctx->packets; i++) {
if (ctx->packet_size[i])
@@ -1341,6 +1341,7 @@ static void prepare_playback_urb(struct
urb->iso_frame_desc[i].length = counts * ep->stride;
frames += counts;
urb->number_of_packets++;
+   ctx->data_packets++;
subs->transfer_done += counts;
if (subs->transfer_done >= runtime->period_size) {
subs->transfer_done -= runtime->period_size;
Index: usb-3.11/sound/usb/endpoint.c
===
--- usb-3.11.orig/sound/usb/endpoint.c
+++ usb-3.11/sound/usb/endpoint.c
@@ -217,6 +217,7 @@ static void prepare_outbound_urb(struct
}
 
urb->number_of_packets = ctx->packets;
+   ctx->data_packets = ctx->packets;
urb->transfer_buffer_length = offs * ep->stride;
memset(urb->transfer_buffer, ep->silence_value,
   offs * ep->stride);
@@ -273,6 +274,7 @@ static inline void prepare_inbound_urb(s
 
urb->transfer_buffer_length = offs;
urb->number_of_packets = urb_ctx->packets;
+   urb_ctx->data_packets = urb_ctx->packets;
break;
 
case SND_USB_ENDPOINT_TYPE_SYNC:
@@ -341,6 +343,47 @@ static void queue_pending_output_urbs(st
}
 }
 
+/**
+ * snd_submit_urbs: Submit data URBs for endpoints without implicit feedback
+ *
+ * @ep: The endpoint to use
+ * @ctx: Context

Re: [PATCH v2] USB: ohci-at91: add usb_clk for transition to common clk framework

[Alan Stern]

On Thu, 1 Aug 2013, Boris BREZILLON wrote:

> The AT91 PMC (Power Management Controller) provides an USB clock used by
> USB Full Speed host (ohci) and USB Full Speed device (udc).
> The usb drivers (ohci and udc) must configure this clock to 48Mhz.
> This configuration was formely done in mach-at91/clock.c, but this
> implementation will be removed when moving to common clk framework.
> 
> This patch adds support for usb clock retrieval and configuration, and is
> backward compatible with the current at91 clk implementation (if usb clk
> is not found, it does not configure/enable it).
> 
> Changes since v1:
>  - use IS_ENABLED(CONFIG_COMMON_CLK) to isolate new at91 clk support
> 
> Signed-off-by: Boris BREZILLON 

Acked-by: 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] USB: ohci-at91: add usb_clk for transition to common clk framework

[Alan Stern]

On Thu, 1 Aug 2013, Sergei Shtylyov wrote:

> > Yes.  However, a more elegant approach is to protect the relevant
> > statements with: if (defined(CONFIG_COMMON_CLK)).  This preprocessor
> 
> You probably meant IS_ENABLED() or IS_BUIILTIN()? Or is there something I 
> don't know about gcc preprocessor?

Yes, sorry, I meant IS_ENABLED().  Boris got it right.

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

[PATCH 2/6] staging: ozwpan: Mark string as const

[Rupesh Gujare]

Make sure that we mark const string so that it does not get modified.

Signed-off-by: Rupesh Gujare 
---
 drivers/staging/ozwpan/ozproto.c |6 +++---
 drivers/staging/ozwpan/ozproto.h |4 ++--
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/ozwpan/ozproto.c b/drivers/staging/ozwpan/ozproto.c
index 500800f..2dbaba6 100644
--- a/drivers/staging/ozwpan/ozproto.c
+++ b/drivers/staging/ozwpan/ozproto.c
@@ -636,7 +636,7 @@ static int oz_pkt_recv(struct sk_buff *skb, struct 
net_device *dev,
 
/*--
  * Context: process
  */
-void oz_binding_add(char *net_dev)
+void oz_binding_add(const char *net_dev)
 {
struct oz_binding *binding;
 
@@ -669,7 +669,7 @@ void oz_binding_add(char *net_dev)
 
/*--
  * Context: process
  */
-static int compare_binding_name(char *s1, char *s2)
+static int compare_binding_name(const char *s1, const char *s2)
 {
int i;
for (i = 0; i < OZ_MAX_BINDING_LEN; i++) {
@@ -707,7 +707,7 @@ static void pd_stop_all_for_device(struct net_device 
*net_dev)
 
/*--
  * Context: process
  */
-void oz_binding_remove(char *net_dev)
+void oz_binding_remove(const char *net_dev)
 {
struct oz_binding *binding;
int found = 0;
diff --git a/drivers/staging/ozwpan/ozproto.h b/drivers/staging/ozwpan/ozproto.h
index 305c532..e532347 100644
--- a/drivers/staging/ozwpan/ozproto.h
+++ b/drivers/staging/ozwpan/ozproto.h
@@ -54,8 +54,8 @@ void oz_protocol_term(void);
 int oz_get_pd_list(struct oz_mac_addr *addr, int max_count);
 void oz_app_enable(int app_id, int enable);
 struct oz_pd *oz_pd_find(const u8 *mac_addr);
-void oz_binding_add(char *net_dev);
-void oz_binding_remove(char *net_dev);
+void oz_binding_add(const char *net_dev);
+void oz_binding_remove(const char *net_dev);
 void oz_timer_add(struct oz_pd *pd, int type, unsigned long due_time);
 void oz_timer_delete(struct oz_pd *pd, int type);
 void oz_pd_request_heartbeat(struct oz_pd *pd);
-- 
1.7.9.5

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

[PATCH 3/6] staging: ozwpan: Use kernel strncmp function.

[Rupesh Gujare]

Use kernel's strncmp() function instead of defining same within driver.

Signed-off-by: Rupesh Gujare 
---
 drivers/staging/ozwpan/ozproto.c |   17 +
 1 file changed, 1 insertion(+), 16 deletions(-)

diff --git a/drivers/staging/ozwpan/ozproto.c b/drivers/staging/ozwpan/ozproto.c
index 2dbaba6..ec60286 100644
--- a/drivers/staging/ozwpan/ozproto.c
+++ b/drivers/staging/ozwpan/ozproto.c
@@ -669,21 +669,6 @@ void oz_binding_add(const char *net_dev)
 
/*--
  * Context: process
  */
-static int compare_binding_name(const char *s1, const char *s2)
-{
-   int i;
-   for (i = 0; i < OZ_MAX_BINDING_LEN; i++) {
-   if (*s1 != *s2)
-   return 0;
-   if (!*s1++)
-   return 1;
-   s2++;
-   }
-   return 1;
-}
-/*--
- * Context: process
- */
 static void pd_stop_all_for_device(struct net_device *net_dev)
 {
struct list_head h;
@@ -715,7 +700,7 @@ void oz_binding_remove(const char *net_dev)
oz_dbg(ON, "Removing binding: %s\n", net_dev);
spin_lock_bh(&g_binding_lock);
list_for_each_entry(binding, &g_binding, link) {
-   if (compare_binding_name(binding->name, net_dev)) {
+   if (strncmp(binding->name, net_dev, OZ_MAX_BINDING_LEN) == 0) {
oz_dbg(ON, "Binding '%s' found\n", net_dev);
found = 1;
break;
-- 
1.7.9.5

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

[PATCH 1/6] staging: ozwpan: Use kernel list function for managing interface list.

[Rupesh Gujare]

Managing interface list, is easier if we use kernel list_* API
than managing it on our own.

Signed-off-by: Rupesh Gujare 
---
 drivers/staging/ozwpan/ozproto.c |   29 +
 1 file changed, 13 insertions(+), 16 deletions(-)

diff --git a/drivers/staging/ozwpan/ozproto.c b/drivers/staging/ozwpan/ozproto.c
index ed22729..500800f 100644
--- a/drivers/staging/ozwpan/ozproto.c
+++ b/drivers/staging/ozwpan/ozproto.c
@@ -37,7 +37,7 @@
 struct oz_binding {
struct packet_type ptype;
char name[OZ_MAX_BINDING_LEN];
-   struct oz_binding *next;
+   struct list_head link;
 };
 
 
/*--
@@ -45,7 +45,7 @@ struct oz_binding {
  */
 static DEFINE_SPINLOCK(g_polling_lock);
 static LIST_HEAD(g_pd_list);
-static struct oz_binding *g_binding ;
+static LIST_HEAD(g_binding);
 static DEFINE_SPINLOCK(g_binding_lock);
 static struct sk_buff_head g_rx_queue;
 static u8 g_session_id;
@@ -437,12 +437,13 @@ done:
  */
 void oz_protocol_term(void)
 {
+   struct oz_binding *b, *t;
+
/* Walk the list of bindings and remove each one.
 */
spin_lock_bh(&g_binding_lock);
-   while (g_binding) {
-   struct oz_binding *b = g_binding;
-   g_binding = b->next;
+   list_for_each_entry_safe(b, t, &g_binding, link) {
+   list_del(&b->link);
spin_unlock_bh(&g_binding_lock);
dev_remove_pack(&b->ptype);
if (b->ptype.dev)
@@ -660,8 +661,7 @@ void oz_binding_add(char *net_dev)
if (binding) {
dev_add_pack(&binding->ptype);
spin_lock_bh(&g_binding_lock);
-   binding->next = g_binding;
-   g_binding = binding;
+   list_add_tail(&binding->link, &g_binding);
spin_unlock_bh(&g_binding_lock);
}
}
@@ -710,28 +710,25 @@ static void pd_stop_all_for_device(struct net_device 
*net_dev)
 void oz_binding_remove(char *net_dev)
 {
struct oz_binding *binding;
-   struct oz_binding **link;
+   int found = 0;
+
oz_dbg(ON, "Removing binding: %s\n", net_dev);
spin_lock_bh(&g_binding_lock);
-   binding = g_binding;
-   link = &g_binding;
-   while (binding) {
+   list_for_each_entry(binding, &g_binding, link) {
if (compare_binding_name(binding->name, net_dev)) {
oz_dbg(ON, "Binding '%s' found\n", net_dev);
-   *link = binding->next;
+   found = 1;
break;
-   } else {
-   link = &binding;
-   binding = binding->next;
}
}
spin_unlock_bh(&g_binding_lock);
-   if (binding) {
+   if (found) {
dev_remove_pack(&binding->ptype);
if (binding->ptype.dev) {
dev_put(binding->ptype.dev);
pd_stop_all_for_device(binding->ptype.dev);
}
+   list_del(&binding->link);
kfree(binding);
}
 }
-- 
1.7.9.5

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

[PATCH 4/6] staging: ozwpan: Drop oldest ISOC frame instead of dropping latest.

[Rupesh Gujare]

In case of ISOC transfer, if TX queue is full then we start
dropping latest frame, instead we should drop oldest frame &
add latest frame to TX queue.

Signed-off-by: Rupesh Gujare 
---
 drivers/staging/ozwpan/ozpd.c |   13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/ozwpan/ozpd.c b/drivers/staging/ozwpan/ozpd.c
index 86876bd..17fd7b2 100644
--- a/drivers/staging/ozwpan/ozpd.c
+++ b/drivers/staging/ozwpan/ozpd.c
@@ -844,9 +844,20 @@ int oz_send_isoc_unit(struct oz_pd *pd, u8 ep_num, const 
u8 *data, int len)
struct oz_tx_frame *isoc_unit = NULL;
int nb = pd->nb_queued_isoc_frames;
if (nb >= pd->isoc_latency) {
+   struct list_head *e;
+   struct oz_tx_frame *f;
oz_dbg(TX_FRAMES, "Dropping ISOC Unit nb= %d\n",
   nb);
-   goto out;
+   spin_lock(&pd->tx_frame_lock);
+   list_for_each(e, &pd->tx_queue) {
+   f = container_of(e, struct oz_tx_frame,
+   link);
+   if (f->skb != NULL) {
+   oz_tx_isoc_free(pd, f);
+   break;
+   }
+   }
+   spin_unlock(&pd->tx_frame_lock);
}
isoc_unit = oz_tx_frame_alloc(pd);
if (isoc_unit == NULL)
-- 
1.7.9.5

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

[PATCH 0/6] staging: ozwpan: Use Kernel API & Bug fixes

[Rupesh Gujare]

This patch series removes duplicate code, & replaces it
with kernel library functions, and few bug fixes.

Rupesh Gujare (6):
  staging: ozwpan: Use kernel list function for managing interface
list.
  staging: ozwpan: Mark string as const
  staging: ozwpan: Use kernel strncmp function.
  staging: ozwpan: Drop oldest ISOC frame instead of dropping latest.
  staging: ozwpan: Increase farewell report size.
  staging: ozwpan: Set farewell report length.

 drivers/staging/ozwpan/ozpd.c|   13 +-
 drivers/staging/ozwpan/ozpd.h|2 +-
 drivers/staging/ozwpan/ozproto.c |   51 +-
 drivers/staging/ozwpan/ozproto.h |4 +--
 4 files changed, 32 insertions(+), 38 deletions(-)

-- 
1.7.9.5

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

[PATCH 5/6] staging: ozwpan: Increase farewell report size.

[Rupesh Gujare]

Farewell report size can be bigger than one byte, increase array
size to accomodate maximum 32 bytes of farewell report.

Signed-off-by: Rupesh Gujare 
---
 drivers/staging/ozwpan/ozpd.h |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/ozwpan/ozpd.h b/drivers/staging/ozwpan/ozpd.h
index a281753..57e98c8 100644
--- a/drivers/staging/ozwpan/ozpd.h
+++ b/drivers/staging/ozwpan/ozpd.h
@@ -48,7 +48,7 @@ struct oz_farewell {
struct list_head link;
u8 ep_num;
u8 index;
-   u8 report[1];
+   u8 report[32];
u8 len;
 };
 
-- 
1.7.9.5

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

[PATCH 6/6] staging: ozwpan: Set farewell report length.

[Rupesh Gujare]

Fixes a bug where we were not setting length field causing wrong
report size to be copied.

Signed-off-by: Rupesh Gujare 
---
 drivers/staging/ozwpan/ozproto.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/staging/ozwpan/ozproto.c b/drivers/staging/ozwpan/ozproto.c
index ec60286..084307a 100644
--- a/drivers/staging/ozwpan/ozproto.c
+++ b/drivers/staging/ozwpan/ozproto.c
@@ -296,6 +296,7 @@ static void oz_add_farewell(struct oz_pd *pd, u8 ep_num, u8 
index,
return;
f->ep_num = ep_num;
f->index = index;
+   f->len = len;
memcpy(f->report, report, len);
oz_dbg(ON, "RX: Adding farewell report\n");
spin_lock(&g_polling_lock);
-- 
1.7.9.5

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

Re: [PATCH 2/3] include: Convert ethernet mac address declarations to use ETH_ALEN

[Mauro Carvalho Chehab]

Em Sun, 28 Jul 2013 22:29:04 -0700
Joe Perches  escreveu:

> It's convenient to have ethernet mac addresses use
> ETH_ALEN to be able to grep for them a bit easier and
> also to ensure that the addresses are __aligned(2).
> 
> Add #include  as necessary.
> 
> Signed-off-by: Joe Perches 
> ---
>  include/acpi/actbl2.h   |  4 ++-
>  include/linux/dm9000.h  |  4 ++-
>  include/linux/fs_enet_pd.h  |  3 ++-
>  include/linux/ieee80211.h   | 59 
> +
>  include/linux/mlx4/device.h | 11 
>  include/linux/mlx4/qp.h |  5 ++--
>  include/linux/mv643xx_eth.h |  3 ++-
>  include/linux/sh_eth.h  |  3 ++-
>  include/linux/smsc911x.h|  3 ++-
>  include/linux/uwb/spec.h|  5 ++--
>  include/media/tveeprom.h|  4 ++-

I'm ok with the change at media/tveeprom.h.

Please add my ack on the next version after handling Rafael's request
on acpi.

Acked-by: Mauro Carvalho Chehab 

>  include/net/irda/irlan_common.h |  3 ++-
>  12 files changed, 61 insertions(+), 46 deletions(-)
> 
> diff --git a/include/acpi/actbl2.h b/include/acpi/actbl2.h
> index ffaac0e..3f0f11c 100644
> --- a/include/acpi/actbl2.h
> +++ b/include/acpi/actbl2.h
> @@ -44,6 +44,8 @@
>  #ifndef __ACTBL2_H__
>  #define __ACTBL2_H__
>  
> +#include 
> +
>  
> /***
>   *
>   * Additional ACPI Tables (2)
> @@ -605,7 +607,7 @@ struct acpi_ibft_nic {
>   u8 secondary_dns[16];
>   u8 dhcp[16];
>   u16 vlan;
> - u8 mac_address[6];
> + u8 mac_address[ETH_ALEN];
>   u16 pci_address;
>   u16 name_length;
>   u16 name_offset;
> diff --git a/include/linux/dm9000.h b/include/linux/dm9000.h
> index 96e8769..841925f 100644
> --- a/include/linux/dm9000.h
> +++ b/include/linux/dm9000.h
> @@ -14,6 +14,8 @@
>  #ifndef __DM9000_PLATFORM_DATA
>  #define __DM9000_PLATFORM_DATA __FILE__
>  
> +#include 
> +
>  /* IO control flags */
>  
>  #define DM9000_PLATF_8BITONLY(0x0001)
> @@ -27,7 +29,7 @@
>  
>  struct dm9000_plat_data {
>   unsigned intflags;
> - unsigned char   dev_addr[6];
> + unsigned char   dev_addr[ETH_ALEN];
>  
>   /* allow replacement IO routines */
>  
> diff --git a/include/linux/fs_enet_pd.h b/include/linux/fs_enet_pd.h
> index 51b7934..343d82a 100644
> --- a/include/linux/fs_enet_pd.h
> +++ b/include/linux/fs_enet_pd.h
> @@ -18,6 +18,7 @@
>  
>  #include 
>  #include 
> +#include 
>  #include 
>  
>  #define FS_ENET_NAME "fs_enet"
> @@ -135,7 +136,7 @@ struct fs_platform_info {
>   const struct fs_mii_bus_info *bus_info;
>  
>   int rx_ring, tx_ring;   /* number of buffers on rx */
> - __u8 macaddr[6];/* mac address */
> + __u8 macaddr[ETH_ALEN]; /* mac address */
>   int rx_copybreak;   /* limit we copy small frames  */
>   int use_napi;   /* use NAPI*/
>   int napi_weight;/* NAPI weight */
> diff --git a/include/linux/ieee80211.h b/include/linux/ieee80211.h
> index b0dc87a..4e101af 100644
> --- a/include/linux/ieee80211.h
> +++ b/include/linux/ieee80211.h
> @@ -16,6 +16,7 @@
>  #define LINUX_IEEE80211_H
>  
>  #include 
> +#include 
>  #include 
>  
>  /*
> @@ -209,28 +210,28 @@ static inline u16 ieee80211_sn_sub(u16 sn1, u16 sn2)
>  struct ieee80211_hdr {
>   __le16 frame_control;
>   __le16 duration_id;
> - u8 addr1[6];
> - u8 addr2[6];
> - u8 addr3[6];
> + u8 addr1[ETH_ALEN];
> + u8 addr2[ETH_ALEN];
> + u8 addr3[ETH_ALEN];
>   __le16 seq_ctrl;
> - u8 addr4[6];
> + u8 addr4[ETH_ALEN];
>  } __packed __aligned(2);
>  
>  struct ieee80211_hdr_3addr {
>   __le16 frame_control;
>   __le16 duration_id;
> - u8 addr1[6];
> - u8 addr2[6];
> - u8 addr3[6];
> + u8 addr1[ETH_ALEN];
> + u8 addr2[ETH_ALEN];
> + u8 addr3[ETH_ALEN];
>   __le16 seq_ctrl;
>  } __packed __aligned(2);
>  
>  struct ieee80211_qos_hdr {
>   __le16 frame_control;
>   __le16 duration_id;
> - u8 addr1[6];
> - u8 addr2[6];
> - u8 addr3[6];
> + u8 addr1[ETH_ALEN];
> + u8 addr2[ETH_ALEN];
> + u8 addr3[ETH_ALEN];
>   __le16 seq_ctrl;
>   __le16 qos_ctrl;
>  } __packed __aligned(2);
> @@ -608,8 +609,8 @@ struct ieee80211s_hdr {
>   u8 flags;
>   u8 ttl;
>   __le32 seqnum;
> - u8 eaddr1[6];
> - u8 eaddr2[6];
> + u8 eaddr1[ETH_ALEN];
> + u8 eaddr2[ETH_ALEN];
>  } __packed __aligned(2);
>  
>  /* Mesh flags */
> @@ -758,7 +759,7 @@ struct ieee80211_rann_ie {
>   u8 rann_flags;
>   u8 rann_hopcount;
>   u8 rann_ttl;
> - u8 rann_addr[6];
> + u8 rann_addr[ETH_ALEN];
>   __le32 rann_seq;
>   __le32 rann_interval;
>   __le32 rann_metric;
> @@ -802,9 +803,9 @@ enum ieee80211_vht_opmode_bits {
>  struct ieee80211_mgmt {
>   __le16 frame_control;
>   __le16 dura

Re: [PATCH 2/6] staging: ozwpan: Mark string as const

[Joe Perches]

On Thu, 2013-08-01 at 18:40 +0100, Rupesh Gujare wrote:
> Make sure that we mark const string so that it does not get modified.
[]
> diff --git a/drivers/staging/ozwpan/ozproto.h 
> b/drivers/staging/ozwpan/ozproto.h
[]
> -void oz_binding_add(char *net_dev);
> -void oz_binding_remove(char *net_dev);
> +void oz_binding_add(const char *net_dev);
> +void oz_binding_remove(const char *net_dev);

const char *net_dev is a poor naming choice.
const char *name might be better.


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

Re: Audio I/O parameters

[Clemens Ladisch]

Alan Stern wrote:
> On Thu, 1 Aug 2013, Clemens Ladisch wrote:
>>> It seems likely that the error is caused by an SMI taking too much
>>> time.  At least, we seem to have ruled out everything else.  Besides,
>>> this change has to be made eventually in any case -- underruns can
>>> occur at any time, in principle, and they shouldn't cause the audio
>>> driver to fail.
>>
>> Well, the failure is a bug in snd-usb-audio: when usb_submit_urb fails,
>> it should report the underrun so that the stream can be stopped and
>> restarted cleanly.  This would be done by the snd_pcm_stop() call in
>> endpoint.c which is currently commented out because of locking problems.
>
> Should we have some sort of threshold for how long an underrun can be
> before it causes a submission failure?
>
> Presumably an underrun of a few ms should not cause the stream to be
> stopped and restarted.  An underrun of 100 ms or more probably should.
> Where do we put the cutoff?

This is policy which should not be decided by the HCD; the driver can
decide whether to stop the stream when it sees the error in the
completion callback.

If there was an underrun, packets will fail+complete faster until the
queue has caught up to the actual schedule.  When the length of the
underrun is longer than ALSA's ring buffer, that fast draining of data
will result in an underrun of the ring buffer.  The policy for these
underruns (stop or ignore) can be set by ALSA applications.

So a longer cutoff allows drivers and applications to ignore longer
underruns, if they choose to do so, or to treat them as errors anyway.

So there is no reason for HCDs to make the cutoff smaller than required
for technical reasons.


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: [RFC] usb: gadget: start to drop endpoint naming conventions

[Felipe Balbi]

Hi,

On Thu, Aug 01, 2013 at 11:58:30AM -0400, Alan Stern wrote:
> > > The endpoint naming convention currently determines type and direction.  
> > > It works okay for simple cases but not for more complicated ones.  For 
> > > example, it can't handle endpoints that support bulk or interrupt but 
> > > not isochronous.  If you really want to make this general, the way to 
> > > do it is to have separate bitflags for: control, bulk-in, bulk-out, ...
> > 
> > not bulk-in/bulk-out. I was thinking of having transfer and direction
> > completely separated. Or would there be cases where endpoint support
> > bulk in/out but isoc in-only ?
> > 
> > I don't think so...
> 
> Yeah, you're probably right.  But you still need flags for the two 
> directions.  I'm pretty sure there are endpoints that are in-only or 
> out-only.

perfect, I'll start working on this in a couple weeks (will travel
on Sunday) then I'll send finalized patches which I'll test with
dummy_hcd only since I'll, likely, still lack HW.

-- 
balbi


signature.asc
Description: Digital signature