Re: [Regression][v3.17][v3.18] USB: Fix persist resume of some SS USB devices

[Pratyush Anand]

On Wed, Nov 05, 2014 at 10:53:35AM +0530, Pratyush Anand wrote:
> Hello Joe,
> 
> On Wed, Nov 05, 2014 at 06:20:06AM +0800, Joseph Salisbury wrote:
> > Hello Pratyush,
> > 
> > A kernel bug report was opened against Ubuntu [0].  After a kernel
> > bisect, it was found that reverting the following commit resolved this bug:
> > 
> > commit a40178b2fa6ad87670fb1e5fa4024db00c149629
> > Author: Pratyush Anand 
> > Date:   Fri Jul 18 12:37:10 2014 +0530
> > 
> > USB: Fix persist resume of some SS USB devices
> > 
> > The regression was introduced as of v3.17-rc1.  The regression still
> > exists in the 3.18-rc3 mainline kernel, and has made it's way into the
> > stable kernels.
> 
> Its strange, as per my understanding patch does not introduce any side
> effect for devices whose resume time is normal. So, if a device is
> connected to the SS port and it was working after resume from
> suspend to ram without this patch, then that device should still work
> with this patch.
> 
> Infact this has resolved another bug reported to bugzilla
> https://bugzilla.kernel.org/show_bug.cgi?id=53211
> 
> 
> > 
> > I was hoping to get your feedback, since you are the patch author.  Do
> > you think gathering any additional data will help diagnose this issue,
> 
> Yaa, sure additional info will help to understand the issue.
> -- dmesg log of suspend resume when this patch is not applied and also
> when applied.

I see that you have already provided both log to the buglink. I had a
look on that. 


When it fails (with this patch):
Oct 22 15:38:59 mana kernel: [   59.825122] PM: resume of devices
complete after 3.878 msecs

When it passed (without this patch):
Oct 22 15:37:19 mana kernel: [   53.495109] PM: resume of devices
complete after 3641.933 msecs
However, even when patch was not present(and it passed), there is a logical
disconnection of devices, so you would face the issue mentioned in
https://bugzilla.kernel.org/show_bug.cgi?id=53211.

Looking to the timeout, it seems that wait loop went for full length
(2S) for all the devices, still could not find a connected device. So,
basically SS link between root hub and hub was not up in 2 sec. Not
sure why, but reading further hub port status caused some fatal issue
with xhci host and so it is not able to get new device connection
after logical disconnection.

Increasing the timeout value may help. But with this long timeout I see a
possibility of sync issue between port_event and usb_port_resume. It
might happen that port_event reads hub port status before
usb_port_resume handles reset_resume.

Can you try following patch with step increasing varied value of
PORT_ENABLE_WAIT, and then let me know which value of
PORT_ENABLE_WAIT works for you (if it works ;)).

diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 11e80ac31324..6eaf481d3d53 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -3311,13 +3311,14 @@ static int finish_port_resume(struct usb_device *udev)
  * This routine should only be called when persist is enabled for a SS
  * device.
  */
+#define PORT_ENABLE_WAIT   2000
 static int wait_for_ss_port_enable(struct usb_device *udev,
struct usb_hub *hub, int *port1,
u16 *portchange, u16 *portstatus)
 {
int status = 0, delay_ms = 0;
 
-   while (delay_ms < 2000) {
+   while (delay_ms < PORT_ENABLE_WAIT) {
if (status || *portstatus & USB_PORT_STAT_CONNECTION)
break;
msleep(20);
@@ -4881,6 +4882,22 @@ static void hub_port_connect_change(struct usb_hub *hub, 
int port1,
usb_lock_port(port_dev);
 }
 
+static void wait_for_reset_resume(struct usb_hub *hub, int port)
+{
+   struct usb_device *udev;
+   int delay_ms = 0;
+
+   udev = hub->ports[port -1]->child;
+   if (udev && udev->reset_resume) {
+   while (delay_ms < PORT_ENABLE_WAIT) {
+   if (!udev->reset_resume)
+   break;
+   msleep(20);
+   delay_ms += 20;
+   }
+   }
+}
+
 static void port_event(struct usb_hub *hub, int port1)
__must_hold(&port_dev->status_lock)
 {
@@ -4894,6 +4911,8 @@ static void port_event(struct usb_hub *hub, int port1)
clear_bit(port1, hub->event_bits);
clear_bit(port1, hub->wakeup_bits);
 
+   wait_for_reset_resume(hub, port1);
+
if (hub_port_status(hub, port1, &portstatus, &portchange) < 0)
return;
 
Regards
Pratyush

> -- dmesg log with following additional debug print.
> @@ -3318,6 +3318,7 @@ static int wait_for_ss_port_enable(struct usb_device 
> *udev,
> int status = 0, delay_ms = 0;
>  
> while (delay_ms < 2000) {
> +   printk("%s:portstatus is %x and portchange is %x\n", 
> __func__, *portstatus, *portchange);
>if (status || *portstatus & USB_PORT_STAT_CONNECTION)
> break;

Re: usbserial / ftdi_sio (+ others) bug?

[Johan Hovold]

On Tue, Nov 04, 2014 at 08:29:13PM +0200, Janne Huttunen wrote:
> On Tue, 4 Nov 2014 09:14:49 +0100
> Johan Hovold  wrote:
> > > 2. The chip responds with single correct character followed by a few
> > >hundred or so replies containing only the overrun status (no
> > > data) which are then converted to a bunch of binary zeroes by the
> > > ldisc because of the bug I mentioned earlier. After that the chip
> > > starts responding with proper data again and works until closed.
> > 
> > Note that the only "bug" is that the application cannot disable the
> > overrun reporting, but why would you want that?
> 
> The merits of doing so may be debatable, but if using the quotes
> around "bug" is supposed to indicate that it isn't one, I have
> to respectfully disagree. I know it is not the most important
> thing in the world and without the hardware fault I probably
> would not have seen it at all, but I would still call it a bug.

And so have I. It is a bug, but it's not what causing your problems
here. In fact, I would argue that you do not even want to disable
overrun reporting. That was my point.

> > What's on the other side of the FTDI chip?
> 
> Some kind of an optical receiver circuit (the link is optically
> isolated). On the other side of that is then the device that sends
> periodical data packets (a couple of times per second 17 bytes
> each) to the computer. The computer doesn't send anything i.e.
> the tx functionality of the chip is not used at all.

What baudrates? Have you verified the RS232 signals?

> > It still sounds like your hardware is broken, but at least you
> > seem to have found a work-around.
> 
> Like I said, the hw is the real culprit here, there's no doubt
> about it. But I also doubt that it's just the individual chip
> in my device that has this issue. The device is practically
> brand new and while that is no guarantee that there won't be any
> faults, I find it much more likely that what I am seeing here is
> a quirk of the implementation and there are lots of these chips
> with the same issue out there.

Your device behaving this way is the first one I hear of. 

> The real questions that remain are then; 1. is the chip real or
> counterfeit and how am I supposed to know it,

No idea.

I have three FT232R plugged in as we speak and they have the same
descriptors as yours (bcdDevice etc). Haven't had any issues with them.

> 2. how much the driver can or even should try to accommodate the
> quirks of the hw, and

Without knowing for sure that this is an issue with a class of devices,
there's not much we can do.

> 3. does the answer to #2 depend on the answer to #1.

Yes.

> > Perhaps you can report it to the logging-device (?) manufacturer
> > or FTDI.
> 
> Sure, if I can find someone that cares, which is doubtful.

If the chip is sold as part of the logging device, I would hope the
manufacturer would.

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

Re: [PATCH v3] usb: Remove references to non-existent PLAT_S5P symbol

[Sylwester Nawrocki]

On 04/11/14 20:52, Paul Bolle wrote:
> On Tue, 2014-11-04 at 11:42 -0800, Greg KH wrote:
>> > As it's something that no one seemed to ever need before (i.e. it's not
>> > a regression fix), but it would be a "new feature", I don't think it's
>> > really a stable fix.
>> > 
>> > But feel free to convince me otherwise :)
>
> Sylwester, was I right in thinking that users of PLAT_S5P, who could set
> USB_EHCI_EXYNOS or USB_OHCI_EXYNOS pre v3.17, got, well, transferred to
> ARCH_S5PV210 and lost the ability to set one of those symbols in v3.17?

Yes, after commit d78c16ccde96 ("ARM: SAMSUNG: Remove remaining legacy code")
we lost the ability to enable USB OHCI and EHCI on S5PV210 SoC.
Thus for those who use the mainline kernel (might be rare) with S5PV210 SoC
there is obviously a regression in USB subsystem in v3.17.


-- 
Regards,
Sylwester
--
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: [3.16.1 BISECTED REGRESSION]: Simtec Entropy Key (cdc-acm) broken in 3.16

[Johan Hovold]

On Fri, Oct 31, 2014 at 04:44:46PM +, Nix wrote:
> Sorry for the delay: illness and work-related release time flurries.
> 
> On 24 Oct 2014, Johan Hovold told this:
> 
> > [ +CC: linux-usb ]
> >
> > On Wed, Oct 22, 2014 at 04:36:59PM +0100, Nix wrote:
> >> On 22 Oct 2014, Johan Hovold outgrape:
> >> 
> >> > On Wed, Oct 22, 2014 at 10:31:17AM +0100, Nix wrote:
> >> >> On 14 Oct 2014, Johan Hovold verbalised:
> >> >> 
> >> >> > On Sun, Oct 12, 2014 at 10:36:30PM +0100, Nix wrote:
> >> >> >> I have checked: this code is being executed against a symlink that
> >> >> >> points to /dev/ttyACM0, and the tcsetattr() succeeds. (At least, it's
> >> >> >> succeeding on the kernel I'm running now, but of course that's 3.16.5
> >> >> >> with this commit reverted...)
> >> >> >
> >> >> > You could verify that by enabling debugging in the cdc-acm driver and
> >> >> > making sure that the corresponding control messages are indeed sent on
> >> >> > close.
> >> >> 
> >> >> I have a debugging dump at
> >> >> ; it's fairly
> >> >
> >> > What kernel were you using here? The log seems to suggest that it was
> >> > generated with the commit in question reverted.
> >> 
> >> Look now :) (the previous log is still there in cdc-acm-reverted.log.)
> >
> > Unfortunately, it seems the logs are incomplete. There are lots of
> > entries missing (e.g. "acm_tty_install" when opening, but also some
> > "acm_submit_read_urb"), some of which were there in your first log.
> 
> OK. What we have now in
>  is a log from the
> pristine upstream 3.16.6 kernel with cdc-acm debugging turned on and the
> acm_tty_write - count stuff in acm_tty_write() disabled: I've increased
> the dmesg buffer size so the top isn't being cut off any more. It took a
> lot of boots for it to fail this time: about a dozen. The log contains
> the boot that failed and the one before.
> 
> (To my uneducated eye, the initial traffic to/from the key looks *very*
> different in the second boot. Something is clearly wrong by this point,
> but that's not much of a surprise!)

The log appears incomplete again, this time it seems the last part is
completely missing (the device is never closed for example). The device
still seems to be responding.

> >> This contains two boots -- one on which the USB key worked, and the next
> >> (with an identical kernel) with which the key was broken. (I'm not sure
> >> whether this problem happens at startup or shutdown time, so it seemed
> >> best to provide both.)
> >
> > That's a good idea.
> >
> > Is it only after reboot you've seen the device fail?
> 
> So far.
> 
> >  What if you
> > physically disconnect and reconnect the device instead, or simply
> 
> That fixes it, in fact it's the only way to fix it once it's broken by
> this bug.

I didn't mean whether it would get the device working again, but rather
whether you could kill it this way.

> > repeatedly open and close it?
> 
> Hm. Good idea.

Same here, but the below test was also informative.
 
> ... no, that doesn't help. Additional log from that shows a lot of what
> looks like error returns:
> 
> Oct 31 16:38:03 fold kern debug: : [  168.135213] cdc_acm 2-1:1.0: 
> acm_tty_close
> Oct 31 16:38:08 fold kern debug: : [  173.130531] cdc_acm 2-1:1.0: 
> acm_ctrl_msg - rq 0x22, val 0x0, len 0x0, result -110

Yeah, it seems your device firmware has crashed. It stops responding to
control requests.

> Oct 31 16:38:08 fold kern debug: : [  173.130557] cdc_acm 2-1:1.0: 
> acm_port_shutdown
> Oct 31 16:38:08 fold kern debug: : [  173.131475] cdc_acm 2-1:1.0: 
> acm_ctrl_irq - urb shutting down with status: -2
> Oct 31 16:38:08 fold kern debug: : [  173.132474] cdc_acm 2-1:1.1: 
> acm_write_bulk - len 0/1, status -2
> Oct 31 16:38:08 fold kern debug: : [  173.132519] cdc_acm 2-1:1.1: acm_softint
> Oct 31 16:38:08 fold kern debug: : [  173.133473] cdc_acm 2-1:1.1: 
> acm_write_bulk - len 0/1, status -2
> Oct 31 16:38:08 fold kern debug: : [  173.133510] cdc_acm 2-1:1.1: acm_softint
> Oct 31 16:38:08 fold kern debug: : [  173.134471] cdc_acm 2-1:1.1: 
> acm_write_bulk - len 0/1, status -2
> Oct 31 16:38:08 fold kern debug: : [  173.134507] cdc_acm 2-1:1.1: acm_softint
> Oct 31 16:38:08 fold kern debug: : [  173.135471] cdc_acm 2-1:1.1: 
> acm_write_bulk - len 0/1, status -2
> Oct 31 16:38:08 fold kern debug: : [  173.135509] cdc_acm 2-1:1.1: acm_softint
> Oct 31 16:38:08 fold kern debug: : [  173.136472] cdc_acm 2-1:1.1: 
> acm_write_bulk - len 0/1, status -2
> Oct 31 16:38:08 fold kern debug: : [  173.136507] cdc_acm 2-1:1.1: acm_softint
> Oct 31 16:38:08 fold kern debug: : [  173.137471] cdc_acm 2-1:1.1: 
> acm_write_bulk - len 0/1, status -2
> Oct 31 16:38:08 fold kern debug: : [  173.137517] cdc_acm 2-1:1.1: acm_softint
> Oct 31 16:38:08 fold kern debug: : [  173.138471] cdc_acm 2-1:1.1: 
> acm_write_bulk - len 0/1, status -2
> Oct 

RE: "asix: Don't reset PHY on if_up for ASIX 88772" breaks net onarndale platform

[Stam, Michel [FINT]]

Hello Charles,

After looking around I found the reset value for the 8772 chip, which
seems to be 0x1E1 (ANAR register).

This equates to (according to include/uapi/linux/mii.h)
ADVERTISE_ALL | ADVERTISE_CSMA.

The register only seems to become 0 if the software reset fails.

Unfortunately, this is exactly what I get when the patch is applied;
asix 1-2:1.0 eth1: Failed to send software reset: ffb5
asix 1-2:1.0 eth1: link reset failed (-75) usbnet usb-:00:1d.0-2, 
ASIX AX88772 USB 2.0 Ethernet
asix 1-2:1.0 eth1: Failed to send software reset: ffb5
asix 1-2:1.0 eth1: link reset failed (-75) usbnet usb-:00:1d.0-2, 
ASIX AX88772 USB 2.0 Ethernet

A little while after this its 'Failed to enable software MII access'.
The ethernet device fails to see any link or accept any ethtool -s
command.

My device has vid:devid 0b95:772a (ASIX Elec. Corp.).

Can you tell me what device is on the Andale platform, Charles? Same
vendor/device id?

Another thing that bothers me is that dev->mii.advertising seems to
contain the same value, so maybe that can be used instead of a call to
asix_mdio_read(). Can anyone comment on its purpose? Should it be a
shadow copy of the real register or something?

Riku, can you test Charles' patch as well?

Kind regards,

Michel Stam

-Original Message-
From: Charles Keepax [mailto:ckee...@opensource.wolfsonmicro.com] 
Sent: Tuesday, November 04, 2014 21:09 PM
To: Stam, Michel [FINT]
Cc: Riku Voipio; da...@davemloft.net; linux-usb@vger.kernel.org;
net...@vger.kernel.org; linux-ker...@vger.kernel.org;
linux-samsung-...@vger.kernel.org
Subject: Re: "asix: Don't reset PHY on if_up for ASIX 88772" breaks net
onarndale platform

On Tue, Nov 04, 2014 at 11:23:06AM +0100, Stam, Michel [FINT] wrote:
> Hello Riku,
> 
> >Fixing a bug (ethtool support) must not cause breakage elsewhere (in
> this case on arndale). This is now a regression of functionality from 
> 3.17.
> >
> >I think it would better to revert the change now and with less hurry
> introduce a ethtool fix that doesn't break arndale.
> 
> I don't fully agree here;
> I would like to point out that this commit is a revert itself. Fixing 
> the armdale will then cause breakage in other implementations, such as

> ours. Blankly reverting breaks other peoples' implementations.
> 
> The PHY reset is the thing that breaks ethtool support, so any fix 
> that appeases all would have to take existing PHY state into account.
> 
> I'm not an expert on the ASIX driver, nor the MII, but I think this is

> the cause;
> drivers/net/usb/asix_devices.c:
>361  asix_mdio_write(dev->net, dev->mii.phy_id, MII_BMCR,
> BMCR_RESET);
>362  asix_mdio_write(dev->net, dev->mii.phy_id, MII_ADVERTISE,
>363  ADVERTISE_ALL | ADVERTISE_CSMA);
>364  mii_nway_restart(&dev->mii);
> 
> I would think that the ADVERTISE_ALL is the cause here, as it will 
> reset the MII back to default, thus overriding ethtool settings.
> Would an:
> Int reg;
> reg = asix_mdio_read(dev->net,dev->mii.phy_id,MII_ADVERTISE);
> 
> prior to the offending lines, and then;
> 
>362  asix_mdio_write(dev->net, dev->mii.phy_id, MII_ADVERTISE,
>363 reg);
> 
> solve the problem for you guys?

If I revert the patch in question and add this in:

--- a/drivers/net/usb/asix_devices.c
+++ b/drivers/net/usb/asix_devices.c
@@ -299,6 +299,7 @@ static int ax88772_reset(struct usbnet *dev)  {
struct asix_data *data = (struct asix_data *)&dev->data;
int ret, embd_phy;
+   int reg;
u16 rx_ctl;

ret = asix_write_gpio(dev,
@@ -359,8 +360,10 @@ static int ax88772_reset(struct usbnet *dev)
msleep(150);

asix_mdio_write(dev->net, dev->mii.phy_id, MII_BMCR,
BMCR_RESET);
-   asix_mdio_write(dev->net, dev->mii.phy_id, MII_ADVERTISE,
-   ADVERTISE_ALL | ADVERTISE_CSMA);
+   reg = asix_mdio_read(dev->net, dev->mii.phy_id, MII_ADVERTISE);
+   if (!reg)
+   reg = ADVERTISE_ALL | ADVERTISE_CSMA;
+   asix_mdio_write(dev->net, dev->mii.phy_id, MII_ADVERTISE, reg);
mii_nway_restart(&dev->mii);

ret = asix_write_medium_mode(dev, AX88772_MEDIUM_DEFAULT);

Then things work on Arndale for me. Does that work for you?
Whether that is a sensible fix I don't know however.

> 
> Mind, maybe the read function should take into account the reset value

> of the MII, and set it to ADVERTISE_ALL | ADVERTISE_CSMA. I don't have

> any documention here at the moment.

Yeah I also have no documentation.

Thanks,
Charles

> 
> Is anyone able to confirm my suspicions?
> 
> Kind regards,
> 
> Michel Stam
> -Original Message-
> From: Riku Voipio [mailto:riku.voi...@iki.fi]
> Sent: Tuesday, November 04, 2014 10:44 AM
> To: Stam, Michel [FINT]
> Cc: Riku Voipio; da...@davemloft.net; linux-usb@vger.kernel.org; 
> net...@vger.kernel.org; linux-ker...@vger.kernel.org; 
> linux-samsung-...@vger.kernel.org; ckee...@opensource.wolfsonmicro.com
> Subject: Re: 

Re: "asix: Don't reset PHY on if_up for ASIX 88772" breaks net onarndale platform

[Riku Voipio]

Hi Michel,

On Wed, Nov 05, 2014 at 01:04:37PM +0100, Stam, Michel [FINT] wrote:
> After looking around I found the reset value for the 8772 chip, which
> seems to be 0x1E1 (ANAR register).
> 
> This equates to (according to include/uapi/linux/mii.h)
> ADVERTISE_ALL | ADVERTISE_CSMA.
> 
> The register only seems to become 0 if the software reset fails.
> 
> Unfortunately, this is exactly what I get when the patch is applied;
> asix 1-2:1.0 eth1: Failed to send software reset: ffb5
> asix 1-2:1.0 eth1: link reset failed (-75) usbnet usb-:00:1d.0-2, 
> ASIX AX88772 USB 2.0 Ethernet
> asix 1-2:1.0 eth1: Failed to send software reset: ffb5
> asix 1-2:1.0 eth1: link reset failed (-75) usbnet usb-:00:1d.0-2, 
> ASIX AX88772 USB 2.0 Ethernet
> 
> A little while after this its 'Failed to enable software MII access'.
> The ethernet device fails to see any link or accept any ethtool -s
> command.

> My device has vid:devid 0b95:772a (ASIX Elec. Corp.).

> Can you tell me what device is on the Andale platform, Charles? Same
> vendor/device id?

Bus 003 Device 004: ID 0b95:772a ASIX Electronics Corp. AX88772A Fast Ethernet

> Another thing that bothers me is that dev->mii.advertising seems to
> contain the same value, so maybe that can be used instead of a call to
> asix_mdio_read(). Can anyone comment on its purpose? Should it be a
> shadow copy of the real register or something?
 
> Riku, can you test Charles' patch as well?

With that patch + revert to ax88772_reset network works. I'm unable to get
ethtool to work with that patch or with the original 3.17 state of asix.
Once i disable autoneg network doesn't just work. 

> > >I think it would better to revert the change now and with less hurry
> > introduce a ethtool fix that doesn't break arndale.

> > I don't fully agree here;
> > I would like to point out that this commit is a revert itself. Fixing 
> > the armdale will then cause breakage in other implementations, such as
> > ours. Blankly reverting breaks other peoples' implementations.

My concern is, that none of us with this problem is a linux network
drivers expert. And no such expert joined the thread to help us. Thus if
we hurry to have proper fix for 3.18, our fix might easily be really
wrong.

Hence, it would seem safer to revert to 3.17 state before 3.18, so we
can propose a proper fix for 3.19. At least from our myopic view, having
no functioning net on arndale is worse than having non-functioning
ethtool (which doesn't seem to have bothered people for years).

Riku

> > The PHY reset is the thing that breaks ethtool support, so any fix 
> > that appeases all would have to take existing PHY state into account.
> > 
> > I'm not an expert on the ASIX driver, nor the MII, but I think this is
> 
> > the cause;
> > drivers/net/usb/asix_devices.c:
> >361  asix_mdio_write(dev->net, dev->mii.phy_id, MII_BMCR,
> > BMCR_RESET);
> >362  asix_mdio_write(dev->net, dev->mii.phy_id, MII_ADVERTISE,
> >363  ADVERTISE_ALL | ADVERTISE_CSMA);
> >364  mii_nway_restart(&dev->mii);
> > 
> > I would think that the ADVERTISE_ALL is the cause here, as it will 
> > reset the MII back to default, thus overriding ethtool settings.
> > Would an:
> > Int reg;
> > reg = asix_mdio_read(dev->net,dev->mii.phy_id,MII_ADVERTISE);
> > 
> > prior to the offending lines, and then;
> > 
> >362  asix_mdio_write(dev->net, dev->mii.phy_id, MII_ADVERTISE,
> >363 reg);
> > 
> > solve the problem for you guys?
> 
> If I revert the patch in question and add this in:
> 
> --- a/drivers/net/usb/asix_devices.c
> +++ b/drivers/net/usb/asix_devices.c
> @@ -299,6 +299,7 @@ static int ax88772_reset(struct usbnet *dev)  {
> struct asix_data *data = (struct asix_data *)&dev->data;
> int ret, embd_phy;
> +   int reg;
> u16 rx_ctl;
> 
> ret = asix_write_gpio(dev,
> @@ -359,8 +360,10 @@ static int ax88772_reset(struct usbnet *dev)
> msleep(150);
> 
> asix_mdio_write(dev->net, dev->mii.phy_id, MII_BMCR,
> BMCR_RESET);
> -   asix_mdio_write(dev->net, dev->mii.phy_id, MII_ADVERTISE,
> -   ADVERTISE_ALL | ADVERTISE_CSMA);
> +   reg = asix_mdio_read(dev->net, dev->mii.phy_id, MII_ADVERTISE);
> +   if (!reg)
> +   reg = ADVERTISE_ALL | ADVERTISE_CSMA;
> +   asix_mdio_write(dev->net, dev->mii.phy_id, MII_ADVERTISE, reg);
> mii_nway_restart(&dev->mii);
> 
> ret = asix_write_medium_mode(dev, AX88772_MEDIUM_DEFAULT);
> 
> Then things work on Arndale for me. Does that work for you?
> Whether that is a sensible fix I don't know however.
> 
> > 
> > Mind, maybe the read function should take into account the reset value
> 
> > of the MII, and set it to ADVERTISE_ALL | ADVERTISE_CSMA. I don't have
> 
> > any documention here at the moment.
> 
> Yeah I also have no documentation.
> 
> Thanks,
> Charles
> 
> > 
> > Is anyone able to confirm my suspicions?
> > 
> > Kind regards,
> > 

Re: [PATCH v1 1/3] usb: phy: device-tree documentation for gpio-vbus

[Sergei Shtylyov]

Hello.

On 11/2/2014 9:11 PM, Robert Jarzmik wrote:


Add documentation for device-tree binding of the generic gpio-vbus phy
controller.



Signed-off-by: Robert Jarzmik 
Cc: devicet...@vger.kernel.org
---
  .../devicetree/bindings/phy/gpio-vbus.txt  | 23 ++
  1 file changed, 23 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/phy/gpio-vbus.txt



diff --git a/Documentation/devicetree/bindings/phy/gpio-vbus.txt 
b/Documentation/devicetree/bindings/phy/gpio-vbus.txt
new file mode 100644
index 000..ffcfd35
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/gpio-vbus.txt
@@ -0,0 +1,23 @@
+GPIO VBus phy


   It's either VBUS or Vbus.


+=
+
+gpio-vbus is a phy controller supporting VBus detection and pullup activation 
on


   s/phy/PHY/.


+GPIOs.
+
+Required properties:
+- compatible : should be "generic,phy-gpio-vbus"


   "generic," not needed.


+- #phy-cells : from the generic PHY bindings, must be 1.


   However, you don't specify it in the example. It's also not clear why you 
need 1, not 0.



+- gpios  : set of 2 gpio properties (see gpio.txt for gpio properties 
format)
+   first gpio is required, it's the VBus sensing input gpio
+  second gpio is optional, it's the D+ pullup controlling output
+  gpio


   s/gpio/GPIO/.


+
+Optional properties:
+- wakeup : boolean, if true the VBus gpio will wakeup the platform
+
+Example:
+   usb2phy : gpio-vbus@13 {


   Please use the generic node name ("usb-phy") in order to comply with the 
ePAPR standard.



+   compatible = "generic,phy-gpio-vbus";
+   gpios = <&gpio 13 GPIO_ACTIVE_LOW>;
+   wakeup;
+   };


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 v2 2/2] [usb] add support for ACPI identification to xhci-platform

[Mark Langsdorf]

On 11/04/2014 11:12 AM, Greg KH wrote:

On Tue, Nov 04, 2014 at 10:50:33AM -0600, Mark Langsdorf wrote:

Provide the methods to let ACPI identify the need to use
xhci-platform. Change the Kconfig files so the
xhci-plat.o file is selectable during kernel config.

Signed-off-by: Mark Langsdorf 
---
Changes from v1
Renamed from "add support for APM X-Gene to xhci-platform"
Removed changes to arm64/Kconfig
Made CONFIG_USB_XHCI_PLATFORM a user selectable config option

  drivers/usb/host/Kconfig |  7 ++-
  drivers/usb/host/xhci-plat.c | 11 +++
  2 files changed, 17 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 82800a7..060a2361 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -27,7 +27,12 @@ config USB_XHCI_HCD
  if USB_XHCI_HCD

  config USB_XHCI_PLATFORM
-   tristate
+   tristate "xHCI platform driver support"
+   --help--
+ Say 'Y' to enable the support for the xHCI host controller
+ as a platform device. Many ARM SoCs provide USB this way.
+
+ If unsure, say 'Y'.


You really want a 'default Y' response here?

That's not good at all, what happens if I select this on a system
without such hardware?


Based on testing with my 2 x86 systems, nothing bad, but I'll make
it 'M' because that's correct.


  config USB_XHCI_MVEBU
tristate "xHCI support for Marvell Armada 375/38x"
diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 91c7557..3db47ea 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -18,6 +18,7 @@
  #include 
  #include 
  #include 
+#include 

  #include "xhci.h"
  #include "xhci-mvebu.h"
@@ -287,6 +288,15 @@ static const struct of_device_id usb_xhci_of_match[] = {
  MODULE_DEVICE_TABLE(of, usb_xhci_of_match);
  #endif

+#ifdef CONFIG_ACPI
+static const struct acpi_device_id usb_xhci_acpi_match[] = {
+   /* APM X-Gene USB Controller */
+   { "PNP0D10", },
+   { }
+};
+MODULE_DEVICE_TABLE(acpi, usb_xhci_acpi_match);
+#endif


That looks like a very "generic" PNP value, are you sure it is assigned
only to this specific device?


I'll adjust the comment. It is a generic PNP value and a lot of
other SoCs will use this controller.


+
  static struct platform_driver usb_xhci_driver = {
.probe  = xhci_plat_probe,
.remove = xhci_plat_remove,
@@ -294,6 +304,7 @@ static struct platform_driver usb_xhci_driver = {
.name = "xhci-hcd",
.pm = DEV_PM_OPS,
.of_match_table = of_match_ptr(usb_xhci_of_match),
+   .acpi_match_table = ACPI_PTR(usb_xhci_acpi_match),


Shouldn't the reworked driver core code handle this differently with the
ability to handle either OF or ACPI in the same driver?


I'm not sure I understand the question. With these changes, the driver
handles both ACPI and DTB/OF. It's the same style of code as used
in drivers/ata/plat-xgene.c, which also handles both ACPI and DTB/OF.
Why do you think this code isn't correct?

--Mark Langsdorf

--
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: "asix: Don't reset PHY on if_up for ASIX 88772" breaks net onarndale platform

[Charles Keepax]

On Wed, Nov 05, 2014 at 01:04:37PM +0100, Stam, Michel [FINT] wrote:
> Hello Charles,
> 
> After looking around I found the reset value for the 8772 chip, which
> seems to be 0x1E1 (ANAR register).
> 
> This equates to (according to include/uapi/linux/mii.h)
> ADVERTISE_ALL | ADVERTISE_CSMA.
> 
> The register only seems to become 0 if the software reset fails.

Odd it definitely reads back as zero on Arndale. I am guessing
that the root of the problem here is that for some reason Arndale
POR of the ethernet is pants and it needs a full software reset
before it will work and the patch removes the full reset
callback.

> 
> Unfortunately, this is exactly what I get when the patch is applied;
> asix 1-2:1.0 eth1: Failed to send software reset: ffb5
> asix 1-2:1.0 eth1: link reset failed (-75) usbnet usb-:00:1d.0-2, 
> ASIX AX88772 USB 2.0 Ethernet
> asix 1-2:1.0 eth1: Failed to send software reset: ffb5
> asix 1-2:1.0 eth1: link reset failed (-75) usbnet usb-:00:1d.0-2, 
> ASIX AX88772 USB 2.0 Ethernet

Ok so I am guessing you have a value in the register which is
neither the reset value or 0 and this causing problems later in
the reset/on the next reset. I do find the naming confusing in
the error message there as it says link reset failed but the
link_reset callback can't fail in the driver and I modified the
reset callback. But I guess that is just oddities of the network
stack I am not familiar with.

The other thing that feels odd is (and again apologies as I know
next to nothing about the networking stack) how come it is
unexpected that the reset callback destroys the state of the
device. Naively I would have expected that a reset callback would
reset the device back to its default state. Here we seem to be
trying to avoid that happening.

> 
> A little while after this its 'Failed to enable software MII access'.
> The ethernet device fails to see any link or accept any ethtool -s
> command.
> 
> My device has vid:devid 0b95:772a (ASIX Elec. Corp.).
> 
> Can you tell me what device is on the Andale platform, Charles? Same
> vendor/device id?

Yeah mine also idVendor=0b95, idProduct=772a

Thanks,
Charles

> 
> Another thing that bothers me is that dev->mii.advertising seems to
> contain the same value, so maybe that can be used instead of a call to
> asix_mdio_read(). Can anyone comment on its purpose? Should it be a
> shadow copy of the real register or something?
> 
> Riku, can you test Charles' patch as well?
> 
> Kind regards,
> 
> Michel Stam
> 
> -Original Message-
> From: Charles Keepax [mailto:ckee...@opensource.wolfsonmicro.com] 
> Sent: Tuesday, November 04, 2014 21:09 PM
> To: Stam, Michel [FINT]
> Cc: Riku Voipio; da...@davemloft.net; linux-usb@vger.kernel.org;
> net...@vger.kernel.org; linux-ker...@vger.kernel.org;
> linux-samsung-...@vger.kernel.org
> Subject: Re: "asix: Don't reset PHY on if_up for ASIX 88772" breaks net
> onarndale platform
> 
> On Tue, Nov 04, 2014 at 11:23:06AM +0100, Stam, Michel [FINT] wrote:
> > Hello Riku,
> > 
> > >Fixing a bug (ethtool support) must not cause breakage elsewhere (in
> > this case on arndale). This is now a regression of functionality from 
> > 3.17.
> > >
> > >I think it would better to revert the change now and with less hurry
> > introduce a ethtool fix that doesn't break arndale.
> > 
> > I don't fully agree here;
> > I would like to point out that this commit is a revert itself. Fixing 
> > the armdale will then cause breakage in other implementations, such as
> 
> > ours. Blankly reverting breaks other peoples' implementations.
> > 
> > The PHY reset is the thing that breaks ethtool support, so any fix 
> > that appeases all would have to take existing PHY state into account.
> > 
> > I'm not an expert on the ASIX driver, nor the MII, but I think this is
> 
> > the cause;
> > drivers/net/usb/asix_devices.c:
> >361  asix_mdio_write(dev->net, dev->mii.phy_id, MII_BMCR,
> > BMCR_RESET);
> >362  asix_mdio_write(dev->net, dev->mii.phy_id, MII_ADVERTISE,
> >363  ADVERTISE_ALL | ADVERTISE_CSMA);
> >364  mii_nway_restart(&dev->mii);
> > 
> > I would think that the ADVERTISE_ALL is the cause here, as it will 
> > reset the MII back to default, thus overriding ethtool settings.
> > Would an:
> > Int reg;
> > reg = asix_mdio_read(dev->net,dev->mii.phy_id,MII_ADVERTISE);
> > 
> > prior to the offending lines, and then;
> > 
> >362  asix_mdio_write(dev->net, dev->mii.phy_id, MII_ADVERTISE,
> >363 reg);
> > 
> > solve the problem for you guys?
> 
> If I revert the patch in question and add this in:
> 
> --- a/drivers/net/usb/asix_devices.c
> +++ b/drivers/net/usb/asix_devices.c
> @@ -299,6 +299,7 @@ static int ax88772_reset(struct usbnet *dev)  {
> struct asix_data *data = (struct asix_data *)&dev->data;
> int ret, embd_phy;
> +   int reg;
> u16 rx_ctl;
> 
> ret = asix_write_gpio(dev,
> @@ -359,8 +360,10 @@ static int ax88772_reset(str

Re: [PATCH] usb: dwc3: remove warning of disable scramble check

[Felipe Balbi]

On Wed, Nov 05, 2014 at 12:39:51PM +0800, Huang Rui wrote:
> On Tue, Nov 04, 2014 at 08:47:26AM -0600, Felipe Balbi wrote:
> > On Tue, Nov 04, 2014 at 05:29:51PM +0800, Huang Rui wrote:
> > > Some SoC's FPGA platform will need this quirk, but it will complain if
> > > running at true SoC platform. This is a normal case, so remove this
> > > warning.
> > 
> > nope, why do you need disable_scramble on actual SoC ? Without an
> > erratum number I will not accept this, sorry.
> > 
> 
> Oh, that's my faulty. I can set disable_scramble_quirk=false after
> actual SoC, at that time, we can drop FPGA support. :)

correct, thank you

-- 
balbi


signature.asc
Description: Digital signature

Re: [3.16.1 BISECTED REGRESSION]: Simtec Entropy Key (cdc-acm) broken in 3.16

[Nix]

On 5 Nov 2014, Johan Hovold stated:

> On Fri, Oct 31, 2014 at 04:44:46PM +, Nix wrote:
>> Sorry for the delay: illness and work-related release time flurries.
>> 
>> On 24 Oct 2014, Johan Hovold told this:
>> 
>> > [ +CC: linux-usb ]
>> >
>> > On Wed, Oct 22, 2014 at 04:36:59PM +0100, Nix wrote:
>> >> On 22 Oct 2014, Johan Hovold outgrape:
>> >> 
>> >> > On Wed, Oct 22, 2014 at 10:31:17AM +0100, Nix wrote:
>> >> >> On 14 Oct 2014, Johan Hovold verbalised:
>> >> >> 
>> >> >> > On Sun, Oct 12, 2014 at 10:36:30PM +0100, Nix wrote:
>> >> >> >> I have checked: this code is being executed against a symlink that
>> >> >> >> points to /dev/ttyACM0, and the tcsetattr() succeeds. (At least, 
>> >> >> >> it's
>> >> >> >> succeeding on the kernel I'm running now, but of course that's 
>> >> >> >> 3.16.5
>> >> >> >> with this commit reverted...)
>> >> >> >
>> >> >> > You could verify that by enabling debugging in the cdc-acm driver and
>> >> >> > making sure that the corresponding control messages are indeed sent 
>> >> >> > on
>> >> >> > close.
>> >> >> 
>> >> >> I have a debugging dump at
>> >> >> ; it's fairly
>> >> >
>> >> > What kernel were you using here? The log seems to suggest that it was
>> >> > generated with the commit in question reverted.
>> >> 
>> >> Look now :) (the previous log is still there in cdc-acm-reverted.log.)
>> >
>> > Unfortunately, it seems the logs are incomplete. There are lots of
>> > entries missing (e.g. "acm_tty_install" when opening, but also some
>> > "acm_submit_read_urb"), some of which were there in your first log.
>> 
>> OK. What we have now in
>>  is a log from the
>> pristine upstream 3.16.6 kernel with cdc-acm debugging turned on and the
>> acm_tty_write - count stuff in acm_tty_write() disabled: I've increased
>> the dmesg buffer size so the top isn't being cut off any more. It took a
>> lot of boots for it to fail this time: about a dozen. The log contains
>> the boot that failed and the one before.
>> 
>> (To my uneducated eye, the initial traffic to/from the key looks *very*
>> different in the second boot. Something is clearly wrong by this point,
>> but that's not much of a surprise!)
>
> The log appears incomplete again, this time it seems the last part is
> completely missing (the device is never closed for example). The device
> still seems to be responding.

Nope -- by the time I clipped the log, the device was definitely
nonresponsive.

I've appended the remaining log, just in case. This is the same as the
snapshot I added to the email itself last time: a close-and-open as I
tried restarting the daemon, and another close as part of system
shutdown.

>> >  What if you
>> > physically disconnect and reconnect the device instead, or simply
>> 
>> That fixes it, in fact it's the only way to fix it once it's broken by
>> this bug.
>
> I didn't mean whether it would get the device working again, but rather
> whether you could kill it this way.

Never seen it fail after a physical disconnection.

>> ... no, that doesn't help. Additional log from that shows a lot of what
>> looks like error returns:
>> 
>> Oct 31 16:38:03 fold kern debug: : [  168.135213] cdc_acm 2-1:1.0: 
>> acm_tty_close
>> Oct 31 16:38:08 fold kern debug: : [  173.130531] cdc_acm 2-1:1.0: 
>> acm_ctrl_msg - rq 0x22, val 0x0, len 0x0, result -110
>
> Yeah, it seems your device firmware has crashed. It stops responding to
> control requests.

Not surprising: I was fairly sure we were provoking a key firmware crash
or something like that. This is a device with no support for flow
control at all, after all, so I'm not terribly surprised that trying to
do flow control confuses it.

> The above is all normal, but
>
>> Oct 31 16:38:08 fold kern debug: : [  173.161489] cdc_acm 2-1:1.0: 
>> acm_ctrl_msg - rq 0x22, val 0x3, len 0x0, result -62
>
> here's another timeout. It's dead.

Again, not surprising.

> Did you get anywhere with trying to look at the device firmware?

Look at it? Only Daniel Silverstone (Cc:ed) can do that. The only copy
of the firmware I have is baked into the sealed key. :)

-- 
NULL && (void)
--
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 Data toggle differences between USB 2 and USB 3?

[Mathias Nyman]

On 04.11.2014 23:58, m. allan noah wrote:
> Hello linux-usb! I am the administrator of SANE (Scanner Access Now
> Easy), which provides scanner drivers for over 1000 models of scanner
> on multiple platforms, including Linux. Many of those scanners are
> USB, and we have had an increase in bug reports in some of those as of
> late. So, I have done some initial investigation, and need some help.
> 
> Generally, we use a wrapper around libusb for our access, and don't
> have to worry much about kernel-level details. However, we have a
> number of reports where our code works perfectly when a scanner is
> attached to a usb port controlled by ehci_hcd, but fails when that
> same port is controlled by xhci_hcd. The libusb, sane, and kernel
> versions are varied, though the behaviour is consistent. This seems at
> first glance to be a Data0/1 toggle problem.
> 
> Specifically, the sane protocol has a detection step, followed by a
> separate 'actually do something' step. The former involves many
> distinct drivers each trying in turn to open, communicate with, and
> close any attached scanners they recognise. The latter is a single
> driver reopening a single scanner, and doing more extensive
> communications before closing again. Under USB 2, this pattern works,
> though the second step sometimes requires retries on the first command
> sent, because the Data toggle is confused. Attempts to use that same
> code on USB 3 (including the retries) fail. Modifications to the
> initial step to either: 1. stop closing the descriptor, or 2. make the
> number of commands even, seem to correct the problem for at least one
> iteration of the process.
> 
> So, my questions- What is different about the handling of the Data
> toggle between the implementation of USB 2 and 3, and is there
> something different that we should be doing from user space to prevent
> this issue? I will be happy to provide additional debugging info, just
> let me know.
> 
> Thanks for any insights-
> allan
> 

Hi

I was looking at some time ago.

If I remember correctly the issue was believed to be that xhci refuses to reset 
an endpoint if it's not halted.
SetFeature(ENDPOINT_HALT) will set the device to halted state, but it requires 
some additional transfer that returns STALL until xHCI will see the endpoint as 
halted.
Same goes for calling reset endpoint as a "soft reset" on xhci, expecting 
toggle to reset will not work unless the endpoint is actually halted.

There was an addition to xhci specs about this, with a solution proposal:

" If software wishes reset the Data Toggle or Sequence Number of an endpoint 
that isn't in the Halted state, then software may issue a Configure Endpoint 
Command with the Drop and Add bits set for the
target endpoint."

I got some code for handling this, so far I got very mixed results (fixes, 
doesn't fix, new minor issues, or new major issus seen).
You can try it out at:

git://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git ep_reset_halt_test
https://git.kernel.org/cgit/linux/kernel/git/mnyman/xhci.git/log/?h=ep_reset_halt_test
(remember to checkout the ep_reset_halt_test branch)

But it's some time since I wrote it, and I since then got a bit better 
understanding about the xhci reset handling.
I need to revisit it again.

-Mathias


--
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 v9 4/4] gpio: add support for the Diolan DLN-2 USB GPIO driver

[Johan Hovold]

On Mon, Oct 27, 2014 at 06:31:12PM +0200, Octavian Purdila wrote:
> From: Daniel Baluta 
> 
> This patch adds GPIO and IRQ support for the Diolan DLN-2 GPIO module.

[...]

> +static void dln2_gpio_pin_set_out_val(struct dln2_gpio *dln2,
> +   unsigned int pin, int value)
> +{
> + struct dln2_gpio_pin_val req = {
> + .pin = cpu_to_le16(pin),
> + .value = cpu_to_le16(value),

Drop cpu_to_le16 (value is u8).

> + };
> +
> + dln2_transfer_tx(dln2->pdev, DLN2_GPIO_PIN_SET_OUT_VAL, &req,
> +  sizeof(req));
> +}
> +
> +#define DLN2_GPIO_DIRECTION_IN   0
> +#define DLN2_GPIO_DIRECTION_OUT  1
> +
> +static int dln2_gpio_request(struct gpio_chip *chip, unsigned offset)
> +{
> + struct dln2_gpio *dln2 = container_of(chip, struct dln2_gpio, gpio);
> + struct dln2_gpio_pin req = {
> + .pin = cpu_to_le16(offset),
> + };
> + struct dln2_gpio_pin_val rsp;
> + int len = sizeof(rsp);
> + int ret;
> +
> + ret = dln2_gpio_pin_cmd(dln2, DLN2_GPIO_PIN_ENABLE, offset);
> + if (ret < 0)
> + return ret;
> +
> + /* cache the pin direction */
> + ret = dln2_transfer(dln2->pdev, DLN2_GPIO_PIN_GET_DIRECTION,
> + &req, sizeof(req), &rsp, &len);
> + if (ret < 0)
> + return ret;
> + if (len < sizeof(rsp) || req.pin != rsp.pin) {
> + ret = -EPROTO;
> + goto out_disable;
> + }
> +
> + switch (rsp.value) {
> + case DLN2_GPIO_DIRECTION_IN:
> + clear_bit(offset, dln2->output_enabled);
> + return 0;
> + case DLN2_GPIO_DIRECTION_OUT:
> + set_bit(offset, dln2->output_enabled);
> + return 0;
> + default:
> + ret = -EPROTO;
> + goto out_disable;
> + }
> +
> +out_disable:
> + dln2_gpio_pin_cmd(dln2, DLN2_GPIO_PIN_DISABLE, offset);
> + return ret;
> +}
> +
> +static void dln2_gpio_free(struct gpio_chip *chip, unsigned offset)
> +{
> + struct dln2_gpio *dln2 = container_of(chip, struct dln2_gpio, gpio);
> +
> + dln2_gpio_pin_cmd(dln2, DLN2_GPIO_PIN_DISABLE, offset);
> +}
> +
> +static int dln2_gpio_get_direction(struct gpio_chip *chip, unsigned offset)
> +{
> + struct dln2_gpio *dln2 = container_of(chip, struct dln2_gpio, gpio);
> +
> + if (test_bit(offset, dln2->output_enabled))
> + return GPIOF_DIR_OUT;
> +
> + return GPIOF_DIR_IN;
> +}
> +
> +static int dln2_gpio_get(struct gpio_chip *chip, unsigned int offset)
> +{
> + struct dln2_gpio *dln2 = container_of(chip, struct dln2_gpio, gpio);
> + int dir;
> +
> + dir = dln2_gpio_get_direction(chip, offset);
> + if (dir < 0)
> + return dir;
> +
> + if (dir == GPIOF_DIR_IN)
> + return dln2_gpio_pin_get_in_val(dln2, offset);
> +
> + return dln2_gpio_pin_get_out_val(dln2, offset);
> +}
> +
> +static void dln2_gpio_set(struct gpio_chip *chip, unsigned offset, int value)
> +{
> + struct dln2_gpio *dln2 = container_of(chip, struct dln2_gpio, gpio);
> +
> + dln2_gpio_pin_set_out_val(dln2, offset, value);
> +}
> +
> +static int dln2_gpio_set_direction(struct gpio_chip *chip, unsigned offset,
> +unsigned dir)
> +{
> + struct dln2_gpio *dln2 = container_of(chip, struct dln2_gpio, gpio);
> + struct dln2_gpio_pin_val req = {
> + .pin = cpu_to_le16(offset),
> + .value = cpu_to_le16(dir),

Same here.

Johan
--
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 v9 2/4] i2c: add support for Diolan DLN-2 USB-I2C adapter

[Johan Hovold]

On Mon, Oct 27, 2014 at 06:31:10PM +0200, Octavian Purdila wrote:
> From: Laurentiu Palcu 
> 
> This patch adds support for the Diolan DLN-2 I2C master module. Due
> to hardware limitations it does not support SMBUS quick commands.
> 
> Information about the USB protocol interface can be found in the
> Programmer's Reference Manual [1], see section 6.2.2 for the I2C
> master module commands and responses.
> 
> [1] https://www.diolan.com/downloads/dln-api-manual.pdf
> 
> Signed-off-by: Laurentiu Palcu 
> Signed-off-by: Octavian Purdila 

Reviewed-by: Johan Hovold 

Johan
--
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 v9 1/4] mfd: add support for Diolan DLN-2 devices

[Johan Hovold]

On Mon, Oct 27, 2014 at 06:31:09PM +0200, Octavian Purdila wrote:
> This patch implements the USB part of the Diolan USB-I2C/SPI/GPIO
> Master Adapter DLN-2. Details about the device can be found here:
> 
> https://www.diolan.com/i2c/i2c_interface.html.
> 
> Information about the USB protocol can be found in the Programmer's
> Reference Manual [1], see section 1.7.
> 
> Because the hardware has a single transmit endpoint and a single
> receive endpoint the communication between the various DLN2 drivers
> and the hardware will be muxed/demuxed by this driver.
> 
> Each DLN2 module will be identified by the handle field within the DLN2
> message header. If a DLN2 module issues multiple commands in parallel
> they will be identified by the echo counter field in the message header.
> 
> The DLN2 modules can use the dln2_transfer() function to issue a
> command and wait for its response. They can also register a callback
> that is going to be called when a specific event id is generated by
> the device (e.g. GPIO interrupts). The device uses handle 0 for
> sending events.
> 
> [1] https://www.diolan.com/downloads/dln-api-manual.pdf
> 
> Signed-off-by: Octavian Purdila 
> ---
>  drivers/mfd/Kconfig  |  11 +
>  drivers/mfd/Makefile |   1 +
>  drivers/mfd/dln2.c   | 761 
> +++
>  include/linux/mfd/dln2.h | 103 +++
>  4 files changed, 876 insertions(+)
>  create mode 100644 drivers/mfd/dln2.c
>  create mode 100644 include/linux/mfd/dln2.h
> 
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index c9200d3..4538815a 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -189,6 +189,17 @@ config MFD_DA9063
> Additional drivers must be enabled in order to use the functionality
> of the device.
>  
> +config MFD_DLN2
> + tristate "Diolan DLN2 support"
> + select MFD_CORE
> + depends on USB
> + help
> +
> +   This adds support for Diolan USB-I2C/SPI/GPIO Master Adapter
> +   DLN-2. Additional drivers such as I2C_DLN2, GPIO_DLN2,
> +   etc. must be enabled in order to use the functionality of
> +   the device.
> +
>  config MFD_MC13XXX
>   tristate
>   depends on (SPI_MASTER || I2C)
> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> index 61f8dbf..2cd7e74 100644
> --- a/drivers/mfd/Makefile
> +++ b/drivers/mfd/Makefile
> @@ -175,6 +175,7 @@ obj-$(CONFIG_MFD_STW481X) += stw481x.o
>  obj-$(CONFIG_MFD_IPAQ_MICRO) += ipaq-micro.o
>  obj-$(CONFIG_MFD_MENF21BMC)  += menf21bmc.o
>  obj-$(CONFIG_MFD_HI6421_PMIC)+= hi6421-pmic-core.o
> +obj-$(CONFIG_MFD_DLN2)   += dln2.o
>  
>  intel-soc-pmic-objs  := intel_soc_pmic_core.o intel_soc_pmic_crc.o
>  obj-$(CONFIG_INTEL_SOC_PMIC) += intel-soc-pmic.o
> diff --git a/drivers/mfd/dln2.c b/drivers/mfd/dln2.c
> new file mode 100644
> index 000..b3946ef
> --- /dev/null
> +++ b/drivers/mfd/dln2.c

[...]

> +struct dln2_header {
> + __le16 size;
> + __le16 id;
> + __le16 echo;
> + __le16 handle;
> +} __packed;
> +
> +struct dln2_response {
> + struct dln2_header hdr;
> + __le16 result;
> +} __packed;
> +

__packed not needed on either struct above.

[...]

> +/*
> + * Returns true if a valid transfer slot is found. In this case the URB must 
> not
> + * be resubmitted imediately in dln2_rx as we need the data when 
> dln2_transfer

s/imediately/immediately/

> + * is woke up. It will be resubmitted there.
> + */
> +static bool dln2_transfer_complete(struct dln2_dev *dln2, struct urb *urb,
> +u16 handle, u16 rx_slot)
> +{
> + struct device *dev = &dln2->interface->dev;
> + struct dln2_mod_rx_slots *rxs = &dln2->mod_rx_slots[handle];
> + struct dln2_rx_context *rxc;
> + bool valid_slot = false;
> +
> + rxc = &rxs->slots[rx_slot];
> +
> + /*
> +  * No need to disable interrupts as this lock is not taken in interrupt
> +  * context elsewhere in this driver. This function (or its callers) are
> +  * also not exported to other modules.
> +  */
> + spin_lock(&rxs->lock);
> + if (rxc->in_use && !rxc->urb) {
> + rxc->urb = urb;
> + complete(&rxc->done);
> + valid_slot = true;
> + }
> + spin_unlock(&rxs->lock);
> +
> + if (!valid_slot)
> + dev_warn(dev, "bad/late response %d/%d\n", handle, rx_slot);
> +
> + return valid_slot;
> +}
> +
> +static void dln2_run_event_callbacks(struct dln2_dev *dln2, u16 id, u16 echo,
> +  void *data, int len)
> +{
> + struct dln2_event_cb_entry *i;
> +
> + rcu_read_lock();
> +
> + list_for_each_entry_rcu(i, &dln2->event_cb_list, list)
> + if (i->id == id)
> + i->callback(i->pdev, echo, data, len);

No need to continue the search if id is found as it will be unique in
the list.

> +
> + rcu_read_unlock();
> +}
> +
> +static void dln2_rx(struct urb *urb)
>

Re: [3.16.1 BISECTED REGRESSION]: Simtec Entropy Key (cdc-acm) broken in 3.16

[Daniel Silverstone]

On Wed, Nov 05, 2014 at 15:14:49 +, Nix wrote:
> > Did you get anywhere with trying to look at the device firmware?
> Look at it? Only Daniel Silverstone (Cc:ed) can do that. The only copy
> of the firmware I have is baked into the sealed key. :)

Sadly I can't look at the exact firmware of the device, but I can tell you it
was based on ST Electronics' virtual COM port example in their *old* STM32
development kits.

Fortunately I do have a record of that example code here:
https://git.gitano.org.uk/stm32-virtcomport.git/

I'm not a USB guru though.

D.

-- 
Daniel Silverstone http://www.digital-scurf.org/
PGP mail accepted and encouraged.Key Id: 3CCE BABE 206C 3B69
--
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: Large disk drives

[Dale R. Worley]

Replying to two messages at once:

> Date: Tue, 4 Nov 2014 11:14:39 -0500 (EST)
> From: Alan Stern 
> cc: "Dale R. Worley" , ,
> 
> 
> On Tue, 4 Nov 2014, James Bottomley wrote:
> 
> > On Mon, 2014-11-03 at 16:06 -0500, Dale R. Worley wrote:
> > > Was there any resolution as to how large disk drives would be handled
> > > if their interface did not support the "capacity" request that would
> > > tell how large they were?
> > 
> > Realistically no ... unless someone comes up with a reliable heuristic
> > to give us the size.

I can understand why the linux-scsi project would not want to take up
what is really a hack to work around a hardware deficiency.

> I posted a patch to allow the user to override the reported capacity:
> 
>   http://marc.info/?l=linux-scsi&m=140993840113445&w=2
> 
> Nobody responded to it.
> 
> > > Unfortunately, such devices work OK with Windows (since Windows trusts
> > > what the partition table says), you can't just say to the salesperson
> > > "It has to work on drives over 3 TB."
> > 
> > This is a stopgap: your 3TB drive can be guessed as the 16 bit capacity
> > plus 2TB, but the same won't happen for a 5TB device.  Believing the
> > partition table gives us a chicken and egg problem because something
> > still has to get the partition table on to the device.
> > 
> > I don't think "don't buy something that doesn't work" is a hugely
> > unreasonable response to this.
> 
> The problem is knowing beforehand whether it will work.  Once you buy 
> the device and can test it, returning it is annoying and time-consuming 
> at best.

Or as I would phrase it, How do you turn "Don't buy something that
doesn't work!" into an algorithm?  That is:  I'm standing in
MicroCenter, holding a box in my hand that contains a USB-to-SCSI
adapter.  How do I determine whether or not it supports large disks?
The problem being that it *works with Windows*, so I can't just ask
the friendly salesperson, Does this work with 3 terabyte disks?

In my case, the Diablotek device works, while the Kingwin EZ-Connect
does not, despite being labeled in essentially the same way.  (Neither
says that Linux is supported.)

I admit that my problem may be my deficiency in dealing with the
retail situation, as I'm a much better software engineer than shopper.

Dale
--
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: Large disk drives

[James Bottomley]

On Tue, 2014-11-04 at 11:14 -0500, Alan Stern wrote:
> On Tue, 4 Nov 2014, James Bottomley wrote:
> 
> > On Mon, 2014-11-03 at 16:06 -0500, Dale R. Worley wrote:
> > > Was there any resolution as to how large disk drives would be handled
> > > if their interface did not support the "capacity" request that would
> > > tell how large they were?
> > 
> > Realistically no ... unless someone comes up with a reliable heuristic
> > to give us the size.
> 
> I posted a patch to allow the user to override the reported capacity:
> 
>   http://marc.info/?l=linux-scsi&m=140993840113445&w=2
> 
> Nobody responded to it.

Sorry, meant to.  In principle I'm OK with this as the lever for the
hack (largely because it means we don't need to do anything) but will
the distributions support it?

> > > Unfortunately, such devices work OK with Windows (since Windows trusts
> > > what the partition table says), you can't just say to the salesperson
> > > "It has to work on drives over 3 TB."
> > 
> > This is a stopgap: your 3TB drive can be guessed as the 16 bit capacity
> > plus 2TB, but the same won't happen for a 5TB device.  Believing the
> > partition table gives us a chicken and egg problem because something
> > still has to get the partition table on to the device.
> > 
> > I don't think "don't buy something that doesn't work" is a hugely
> > unreasonable response to this.
> 
> The problem is knowing beforehand whether it will work.  Once you buy 
> the device and can test it, returning it is annoying and time-consuming 
> at best.

OK, but I still don't understand how windows gets the partition table on
there in the first place ... that must surely be some sort of guess the
disk size hack.

James


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


--
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: "asix: Don't reset PHY on if_up for ASIX 88772" breaks netonarndale platform

[Stam, Michel [FINT]]

Hello Charles,

First of all, my apologies. I manually applied your patch and made a
mistake; I swapped ax88772_link_reset with ax88772_reset for struct
driver_info_ax88772_info structure, which caused the software reset
failures. Blame it on a lack of coffee... Please disregard my previous
mail.

After (correctly) applying the patch I still don't get the desired
results; see below.

Test situation:
ifconfig eth1 down
ethtool -s advertise 1
ifconfig eth1 up

Check dmesg, It will report a link down, followed by the new speed,
which when using advertise 1, should be 10 Mbps/half duplex.
To make it more interesting, ethtool eth1 reports 10 Mbps/half duplex
even though the kernel reports 100 Mbps/full duplex.

What does work (but did before this whole situation as well):
ifconfig eth1 up
ethtool -s eth1 advertise 1

The interface will now be in 10 Mbps/half duplex, that is, until the
reset function is called (interface down or otherwise). 

What I do notice, is that dev->mii.advertising follows whatever I set
with ethtool. I tried writing the ADVERTISE register with the value of
the dev->mii.advertising variable, but that did not give me the desired
result either.

Kind regards,

Michel Stam

-Original Message-
From: Charles Keepax [mailto:ckee...@opensource.wolfsonmicro.com] 
Sent: Wednesday, November 05, 2014 16:03 PM
To: Stam, Michel [FINT]
Cc: Riku Voipio; da...@davemloft.net; linux-usb@vger.kernel.org;
net...@vger.kernel.org; linux-ker...@vger.kernel.org;
linux-samsung-...@vger.kernel.org
Subject: Re: "asix: Don't reset PHY on if_up for ASIX 88772" breaks
netonarndale platform

On Wed, Nov 05, 2014 at 01:04:37PM +0100, Stam, Michel [FINT] wrote:
> Hello Charles,
> 
> After looking around I found the reset value for the 8772 chip, which 
> seems to be 0x1E1 (ANAR register).
> 
> This equates to (according to include/uapi/linux/mii.h) ADVERTISE_ALL 
> | ADVERTISE_CSMA.
> 
> The register only seems to become 0 if the software reset fails.

Odd it definitely reads back as zero on Arndale. I am guessing that the
root of the problem here is that for some reason Arndale POR of the
ethernet is pants and it needs a full software reset before it will work
and the patch removes the full reset callback.

> 
> Unfortunately, this is exactly what I get when the patch is applied; 
> asix 1-2:1.0 eth1: Failed to send software reset: ffb5 asix 
> 1-2:1.0 eth1: link reset failed (-75) usbnet usb-:00:1d.0-2, ASIX 
> AX88772 USB 2.0 Ethernet asix 1-2:1.0 eth1: Failed to send software 
> reset: ffb5 asix 1-2:1.0 eth1: link reset failed (-75) usbnet 
> usb-:00:1d.0-2, ASIX AX88772 USB 2.0 Ethernet

Ok so I am guessing you have a value in the register which is neither
the reset value or 0 and this causing problems later in the reset/on the
next reset. I do find the naming confusing in the error message there as
it says link reset failed but the link_reset callback can't fail in the
driver and I modified the reset callback. But I guess that is just
oddities of the network stack I am not familiar with.

The other thing that feels odd is (and again apologies as I know next to
nothing about the networking stack) how come it is unexpected that the
reset callback destroys the state of the device. Naively I would have
expected that a reset callback would reset the device back to its
default state. Here we seem to be trying to avoid that happening.

> 
> A little while after this its 'Failed to enable software MII access'.
> The ethernet device fails to see any link or accept any ethtool -s 
> command.
> 
> My device has vid:devid 0b95:772a (ASIX Elec. Corp.).
> 
> Can you tell me what device is on the Andale platform, Charles? Same 
> vendor/device id?

Yeah mine also idVendor=0b95, idProduct=772a

Thanks,
Charles

> 
> Another thing that bothers me is that dev->mii.advertising seems to 
> contain the same value, so maybe that can be used instead of a call to

> asix_mdio_read(). Can anyone comment on its purpose? Should it be a 
> shadow copy of the real register or something?
> 
> Riku, can you test Charles' patch as well?
> 
> Kind regards,
> 
> Michel Stam
> 
> -Original Message-
> From: Charles Keepax [mailto:ckee...@opensource.wolfsonmicro.com]
> Sent: Tuesday, November 04, 2014 21:09 PM
> To: Stam, Michel [FINT]
> Cc: Riku Voipio; da...@davemloft.net; linux-usb@vger.kernel.org; 
> net...@vger.kernel.org; linux-ker...@vger.kernel.org; 
> linux-samsung-...@vger.kernel.org
> Subject: Re: "asix: Don't reset PHY on if_up for ASIX 88772" breaks 
> net onarndale platform
> 
> On Tue, Nov 04, 2014 at 11:23:06AM +0100, Stam, Michel [FINT] wrote:
> > Hello Riku,
> > 
> > >Fixing a bug (ethtool support) must not cause breakage elsewhere 
> > >(in
> > this case on arndale). This is now a regression of functionality 
> > from 3.17.
> > >
> > >I think it would better to revert the change now and with less 
> > >hurry
> > introduce a ethtool fix that doesn't break arndale.
> > 
> > I don't fully agree here;
> >

RE: "asix: Don't reset PHY on if_up for ASIX 88772" breaks net onarndale platform

[Stam, Michel [FINT]]

Hello Riku,

I will quickly reply to your message, and reserve any further comments
for the other thread.

>My concern is, that none of us with this problem is a linux network
drivers expert. And no such expert joined the thread to help us. Thus if
we hurry to have proper fix for 3.18, our fix might easily be really
wrong.
>
>Hence, it would seem safer to revert to 3.17 state before 3.18, so we
can propose a proper fix for 3.19. At least from our myopic view, having
no functioning net on arndale is worse than having non-functioning
ethtool (which doesn't >seem to have bothered people for years).

Lets agree to disagree here. Any further comment on this would not be
productive.

Kind regards,

Michel Stam

-Original Message-
From: Riku Voipio [mailto:riku.voi...@iki.fi] 
Sent: Wednesday, November 05, 2014 13:40 PM
To: Stam, Michel [FINT]
Cc: Charles Keepax; da...@davemloft.net; linux-usb@vger.kernel.org;
net...@vger.kernel.org; linux-ker...@vger.kernel.org;
linux-samsung-...@vger.kernel.org
Subject: Re: "asix: Don't reset PHY on if_up for ASIX 88772" breaks net
onarndale platform

Hi Michel,

On Wed, Nov 05, 2014 at 01:04:37PM +0100, Stam, Michel [FINT] wrote:
> After looking around I found the reset value for the 8772 chip, which 
> seems to be 0x1E1 (ANAR register).
> 
> This equates to (according to include/uapi/linux/mii.h) ADVERTISE_ALL 
> | ADVERTISE_CSMA.
> 
> The register only seems to become 0 if the software reset fails.
> 
> Unfortunately, this is exactly what I get when the patch is applied; 
> asix 1-2:1.0 eth1: Failed to send software reset: ffb5 asix 
> 1-2:1.0 eth1: link reset failed (-75) usbnet usb-:00:1d.0-2, ASIX 
> AX88772 USB 2.0 Ethernet asix 1-2:1.0 eth1: Failed to send software 
> reset: ffb5 asix 1-2:1.0 eth1: link reset failed (-75) usbnet 
> usb-:00:1d.0-2, ASIX AX88772 USB 2.0 Ethernet
> 
> A little while after this its 'Failed to enable software MII access'.
> The ethernet device fails to see any link or accept any ethtool -s 
> command.

> My device has vid:devid 0b95:772a (ASIX Elec. Corp.).

> Can you tell me what device is on the Andale platform, Charles? Same 
> vendor/device id?

Bus 003 Device 004: ID 0b95:772a ASIX Electronics Corp. AX88772A Fast
Ethernet

> Another thing that bothers me is that dev->mii.advertising seems to 
> contain the same value, so maybe that can be used instead of a call to

> asix_mdio_read(). Can anyone comment on its purpose? Should it be a 
> shadow copy of the real register or something?
 
> Riku, can you test Charles' patch as well?

With that patch + revert to ax88772_reset network works. I'm unable to
get ethtool to work with that patch or with the original 3.17 state of
asix.
Once i disable autoneg network doesn't just work. 

> > >I think it would better to revert the change now and with less 
> > >hurry
> > introduce a ethtool fix that doesn't break arndale.

> > I don't fully agree here;
> > I would like to point out that this commit is a revert itself. 
> > Fixing the armdale will then cause breakage in other 
> > implementations, such as ours. Blankly reverting breaks other
peoples' implementations.

My concern is, that none of us with this problem is a linux network
drivers expert. And no such expert joined the thread to help us. Thus if
we hurry to have proper fix for 3.18, our fix might easily be really
wrong.

Hence, it would seem safer to revert to 3.17 state before 3.18, so we
can propose a proper fix for 3.19. At least from our myopic view, having
no functioning net on arndale is worse than having non-functioning
ethtool (which doesn't seem to have bothered people for years).

Riku

> > The PHY reset is the thing that breaks ethtool support, so any fix 
> > that appeases all would have to take existing PHY state into
account.
> > 
> > I'm not an expert on the ASIX driver, nor the MII, but I think this 
> > is
> 
> > the cause;
> > drivers/net/usb/asix_devices.c:
> >361  asix_mdio_write(dev->net, dev->mii.phy_id, MII_BMCR,
> > BMCR_RESET);
> >362  asix_mdio_write(dev->net, dev->mii.phy_id,
MII_ADVERTISE,
> >363  ADVERTISE_ALL | ADVERTISE_CSMA);
> >364  mii_nway_restart(&dev->mii);
> > 
> > I would think that the ADVERTISE_ALL is the cause here, as it will 
> > reset the MII back to default, thus overriding ethtool settings.
> > Would an:
> > Int reg;
> > reg = asix_mdio_read(dev->net,dev->mii.phy_id,MII_ADVERTISE);
> > 
> > prior to the offending lines, and then;
> > 
> >362  asix_mdio_write(dev->net, dev->mii.phy_id,
MII_ADVERTISE,
> >363 reg);
> > 
> > solve the problem for you guys?
> 
> If I revert the patch in question and add this in:
> 
> --- a/drivers/net/usb/asix_devices.c
> +++ b/drivers/net/usb/asix_devices.c
> @@ -299,6 +299,7 @@ static int ax88772_reset(struct usbnet *dev)  {
> struct asix_data *data = (struct asix_data *)&dev->data;
> int ret, embd_phy;
> +   int reg;
> u16 rx_ctl;
> 
> ret 

Re: [PATCH v3] usb: Remove references to non-existent PLAT_S5P symbol

[Greg KH]

On Wed, Nov 05, 2014 at 11:23:36AM +0100, Sylwester Nawrocki wrote:
> On 04/11/14 20:52, Paul Bolle wrote:
> > On Tue, 2014-11-04 at 11:42 -0800, Greg KH wrote:
> >> > As it's something that no one seemed to ever need before (i.e. it's not
> >> > a regression fix), but it would be a "new feature", I don't think it's
> >> > really a stable fix.
> >> > 
> >> > But feel free to convince me otherwise :)
> >
> > Sylwester, was I right in thinking that users of PLAT_S5P, who could set
> > USB_EHCI_EXYNOS or USB_OHCI_EXYNOS pre v3.17, got, well, transferred to
> > ARCH_S5PV210 and lost the ability to set one of those symbols in v3.17?
> 
> Yes, after commit d78c16ccde96 ("ARM: SAMSUNG: Remove remaining legacy code")
> we lost the ability to enable USB OHCI and EHCI on S5PV210 SoC.
> Thus for those who use the mainline kernel (might be rare) with S5PV210 SoC
> there is obviously a regression in USB subsystem in v3.17.

Ok, I'll add this to 3.17-stable when it hits Linus's tree, 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: Large disk drives

[Alan Stern]

On Wed, 5 Nov 2014, James Bottomley wrote:

> On Tue, 2014-11-04 at 11:14 -0500, Alan Stern wrote:
> > On Tue, 4 Nov 2014, James Bottomley wrote:
> > 
> > > On Mon, 2014-11-03 at 16:06 -0500, Dale R. Worley wrote:
> > > > Was there any resolution as to how large disk drives would be handled
> > > > if their interface did not support the "capacity" request that would
> > > > tell how large they were?
> > > 
> > > Realistically no ... unless someone comes up with a reliable heuristic
> > > to give us the size.
> > 
> > I posted a patch to allow the user to override the reported capacity:
> > 
> > http://marc.info/?l=linux-scsi&m=140993840113445&w=2
> > 
> > Nobody responded to it.
> 
> Sorry, meant to.  In principle I'm OK with this as the lever for the
> hack (largely because it means we don't need to do anything) but will
> the distributions support it?

While I can't speak for the distributions, it's reasonable to assume 
that if something becomes part of the upstream kernel then they will 
include it.

> OK, but I still don't understand how windows gets the partition table on
> there in the first place ... that must surely be some sort of guess the
> disk size hack.

It's simpler than that: The drive is attached directly to the computer
(i.e., via SATA rather than USB) when the partition table is created.  
With no USB-SATA bridge chip to mess things up, there's no problem
determining the correct capacity.

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 v10 1/3] mfd: add support for Diolan DLN-2 devices

[Octavian Purdila]

This patch implements the USB part of the Diolan USB-I2C/SPI/GPIO
Master Adapter DLN-2. Details about the device can be found here:

https://www.diolan.com/i2c/i2c_interface.html.

Information about the USB protocol can be found in the Programmer's
Reference Manual [1], see section 1.7.

Because the hardware has a single transmit endpoint and a single
receive endpoint the communication between the various DLN2 drivers
and the hardware will be muxed/demuxed by this driver.

Each DLN2 module will be identified by the handle field within the DLN2
message header. If a DLN2 module issues multiple commands in parallel
they will be identified by the echo counter field in the message header.

The DLN2 modules can use the dln2_transfer() function to issue a
command and wait for its response. They can also register a callback
that is going to be called when a specific event id is generated by
the device (e.g. GPIO interrupts). The device uses handle 0 for
sending events.

[1] https://www.diolan.com/downloads/dln-api-manual.pdf

Signed-off-by: Octavian Purdila 
---
 drivers/mfd/Kconfig  |  11 +
 drivers/mfd/Makefile |   1 +
 drivers/mfd/dln2.c   | 763 +++
 include/linux/mfd/dln2.h | 103 +++
 4 files changed, 878 insertions(+)
 create mode 100644 drivers/mfd/dln2.c
 create mode 100644 include/linux/mfd/dln2.h

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index cbdb109..32d7cab 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -189,6 +189,17 @@ config MFD_DA9063
  Additional drivers must be enabled in order to use the functionality
  of the device.
 
+config MFD_DLN2
+   tristate "Diolan DLN2 support"
+   select MFD_CORE
+   depends on USB
+   help
+
+ This adds support for Diolan USB-I2C/SPI/GPIO Master Adapter
+ DLN-2. Additional drivers such as I2C_DLN2, GPIO_DLN2,
+ etc. must be enabled in order to use the functionality of
+ the device.
+
 config MFD_MC13XXX
tristate
depends on (SPI_MASTER || I2C)
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 8e679d6..53467e2 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -175,6 +175,7 @@ obj-$(CONFIG_MFD_STW481X)   += stw481x.o
 obj-$(CONFIG_MFD_IPAQ_MICRO)   += ipaq-micro.o
 obj-$(CONFIG_MFD_MENF21BMC)+= menf21bmc.o
 obj-$(CONFIG_MFD_HI6421_PMIC)  += hi6421-pmic-core.o
+obj-$(CONFIG_MFD_DLN2) += dln2.o
 
 intel-soc-pmic-objs:= intel_soc_pmic_core.o intel_soc_pmic_crc.o
 obj-$(CONFIG_INTEL_SOC_PMIC)   += intel-soc-pmic.o
diff --git a/drivers/mfd/dln2.c b/drivers/mfd/dln2.c
new file mode 100644
index 000..9765a17
--- /dev/null
+++ b/drivers/mfd/dln2.c
@@ -0,0 +1,763 @@
+/*
+ * Driver for the Diolan DLN-2 USB adapter
+ *
+ * Copyright (c) 2014 Intel Corporation
+ *
+ * Derived from:
+ *  i2c-diolan-u2c.c
+ *  Copyright (c) 2010-2011 Ericsson AB
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation, version 2.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct dln2_header {
+   __le16 size;
+   __le16 id;
+   __le16 echo;
+   __le16 handle;
+};
+
+struct dln2_response {
+   struct dln2_header hdr;
+   __le16 result;
+};
+
+#define DLN2_GENERIC_MODULE_ID 0x00
+#define DLN2_GENERIC_CMD(cmd)  DLN2_CMD(cmd, DLN2_GENERIC_MODULE_ID)
+#define CMD_GET_DEVICE_VER DLN2_GENERIC_CMD(0x30)
+#define CMD_GET_DEVICE_SN  DLN2_GENERIC_CMD(0x31)
+
+#define DLN2_HW_ID 0x200
+#define DLN2_USB_TIMEOUT   200 /* in ms */
+#define DLN2_MAX_RX_SLOTS  16
+#define DLN2_MAX_URBS  16
+#define DLN2_RX_BUF_SIZE   512
+
+enum dln2_handle {
+   DLN2_HANDLE_EVENT = 0,  /* don't change, hardware defined */
+   DLN2_HANDLE_CTRL,
+   DLN2_HANDLE_GPIO,
+   DLN2_HANDLE_I2C,
+   DLN2_HANDLES
+};
+
+/*
+ * Receive context used between the receive demultiplexer and the transfer
+ * routine. While sending a request the transfer routine will look for a free
+ * receive context and use it to wait for a response and to receive the URB and
+ * thus the response data.
+ */
+struct dln2_rx_context {
+   /* completion used to wait for a response */
+   struct completion done;
+
+   /* if non-NULL the URB contains the response */
+   struct urb *urb;
+
+   /* if true then this context is used to wait for a response */
+   bool in_use;
+};
+
+/*
+ * Receive contexts for a particular DLN2 module (i2c, gpio, etc.). We use the
+ * handle header field to identify the module in dln2_dev.mod_rx_slots and then
+ * the echo header field to index the slots field and find the receive context
+ * for a particular request.
+ */

[PATCH v10 0/3] add support for Diolan DLN-2

[Octavian Purdila]

This patch series adds support for Diolan USB-I2C/GPIO Master Adapter
DLN-2. Details about device can be found here:

https://www.diolan.com/i2c/i2c_interface.html.

This patch series has been rebased against the for-mfd-next branch of
the MFD tree.

Changes since v9:

 * MFD: use decimal serial no, break the run callback loop (there can
   be only one entry per id), move up the declaration of a couple of
   variables, remove a couple of redundant __packed attributes, fix a
   typo and cleanup an error message, use unsigned long instead of int
   for timeout

 * I2C: none

 * GPIO: drop a couple of cpu_to_le16() due to receiving data type
   being u8

Daniel Baluta (1):
  gpio: add support for the Diolan DLN-2 USB GPIO driver

Laurentiu Palcu (1):
  i2c: add support for Diolan DLN-2 USB-I2C adapter

Octavian Purdila (1):
  mfd: add support for Diolan DLN-2 devices

 drivers/gpio/Kconfig  |  12 +
 drivers/gpio/Makefile |   1 +
 drivers/gpio/gpio-dln2.c  | 553 ++
 drivers/i2c/busses/Kconfig|  10 +
 drivers/i2c/busses/Makefile   |   1 +
 drivers/i2c/busses/i2c-dln2.c | 267 +++
 drivers/mfd/Kconfig   |  11 +
 drivers/mfd/Makefile  |   1 +
 drivers/mfd/dln2.c| 763 ++
 include/linux/mfd/dln2.h  | 103 ++
 10 files changed, 1722 insertions(+)
 create mode 100644 drivers/gpio/gpio-dln2.c
 create mode 100644 drivers/i2c/busses/i2c-dln2.c
 create mode 100644 drivers/mfd/dln2.c
 create mode 100644 include/linux/mfd/dln2.h

-- 
1.9.1

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

[PATCH v10 2/3] i2c: add support for Diolan DLN-2 USB-I2C adapter

[Octavian Purdila]

From: Laurentiu Palcu 

This patch adds support for the Diolan DLN-2 I2C master module. Due
to hardware limitations it does not support SMBUS quick commands.

Information about the USB protocol interface can be found in the
Programmer's Reference Manual [1], see section 6.2.2 for the I2C
master module commands and responses.

[1] https://www.diolan.com/downloads/dln-api-manual.pdf

Signed-off-by: Laurentiu Palcu 
Signed-off-by: Octavian Purdila 
Acked-by: Wolfram Sang 
Reviewed-by: Johan Hovold 
---
 drivers/i2c/busses/Kconfig|  10 ++
 drivers/i2c/busses/Makefile   |   1 +
 drivers/i2c/busses/i2c-dln2.c | 267 ++
 3 files changed, 278 insertions(+)
 create mode 100644 drivers/i2c/busses/i2c-dln2.c

diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index 917c358..059e846 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -881,6 +881,16 @@ config I2C_DIOLAN_U2C
  This driver can also be built as a module.  If so, the module
  will be called i2c-diolan-u2c.
 
+config I2C_DLN2
+   tristate "Diolan DLN-2 USB I2C adapter"
+   depends on MFD_DLN2
+   help
+ If you say yes to this option, support will be included for Diolan
+ DLN2, a USB to I2C interface.
+
+ This driver can also be built as a module.  If so, the module
+ will be called i2c-dln2.
+
 config I2C_PARPORT
tristate "Parallel port adapter"
depends on PARPORT
diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
index 78d56c5..cdac7f1 100644
--- a/drivers/i2c/busses/Makefile
+++ b/drivers/i2c/busses/Makefile
@@ -87,6 +87,7 @@ obj-$(CONFIG_I2C_RCAR)+= i2c-rcar.o
 
 # External I2C/SMBus adapter drivers
 obj-$(CONFIG_I2C_DIOLAN_U2C)   += i2c-diolan-u2c.o
+obj-$(CONFIG_I2C_DLN2) += i2c-dln2.o
 obj-$(CONFIG_I2C_PARPORT)  += i2c-parport.o
 obj-$(CONFIG_I2C_PARPORT_LIGHT)+= i2c-parport-light.o
 obj-$(CONFIG_I2C_ROBOTFUZZ_OSIF)   += i2c-robotfuzz-osif.o
diff --git a/drivers/i2c/busses/i2c-dln2.c b/drivers/i2c/busses/i2c-dln2.c
new file mode 100644
index 000..010a5fa
--- /dev/null
+++ b/drivers/i2c/busses/i2c-dln2.c
@@ -0,0 +1,267 @@
+/*
+ * Driver for the Diolan DLN-2 USB-I2C adapter
+ *
+ * Copyright (c) 2014 Intel Corporation
+ *
+ * Derived from:
+ *  i2c-diolan-u2c.c
+ *  Copyright (c) 2010-2011 Ericsson AB
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation, version 2.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DLN2_I2C_MODULE_ID 0x03
+#define DLN2_I2C_CMD(cmd)  DLN2_CMD(cmd, DLN2_I2C_MODULE_ID)
+
+/* I2C commands */
+#define DLN2_I2C_GET_PORT_COUNTDLN2_I2C_CMD(0x00)
+#define DLN2_I2C_ENABLEDLN2_I2C_CMD(0x01)
+#define DLN2_I2C_DISABLE   DLN2_I2C_CMD(0x02)
+#define DLN2_I2C_IS_ENABLEDDLN2_I2C_CMD(0x03)
+#define DLN2_I2C_WRITE DLN2_I2C_CMD(0x06)
+#define DLN2_I2C_READ  DLN2_I2C_CMD(0x07)
+#define DLN2_I2C_SCAN_DEVICES  DLN2_I2C_CMD(0x08)
+#define DLN2_I2C_PULLUP_ENABLE DLN2_I2C_CMD(0x09)
+#define DLN2_I2C_PULLUP_DISABLEDLN2_I2C_CMD(0x0A)
+#define DLN2_I2C_PULLUP_IS_ENABLED DLN2_I2C_CMD(0x0B)
+#define DLN2_I2C_TRANSFER  DLN2_I2C_CMD(0x0C)
+#define DLN2_I2C_SET_MAX_REPLY_COUNT   DLN2_I2C_CMD(0x0D)
+#define DLN2_I2C_GET_MAX_REPLY_COUNT   DLN2_I2C_CMD(0x0E)
+
+#define DLN2_I2C_MAX_XFER_SIZE 256
+#define DLN2_I2C_BUF_SIZE  (DLN2_I2C_MAX_XFER_SIZE + 16)
+
+struct dln2_i2c {
+   struct platform_device *pdev;
+   struct i2c_adapter adapter;
+   u8 port;
+   /*
+* Buffer to hold the packet for read or write transfers. One is enough
+* since we can't have multiple transfers in parallel on the i2c bus.
+*/
+   void *buf;
+};
+
+static int dln2_i2c_enable(struct dln2_i2c *dln2, bool enable)
+{
+   int ret;
+   u16 cmd;
+   struct {
+   u8 port;
+   } tx;
+
+   tx.port = dln2->port;
+
+   if (enable)
+   cmd = DLN2_I2C_ENABLE;
+   else
+   cmd = DLN2_I2C_DISABLE;
+
+   ret = dln2_transfer_tx(dln2->pdev, cmd, &tx, sizeof(tx));
+   if (ret < 0)
+   return ret;
+
+   return 0;
+}
+
+static int dln2_i2c_write(struct dln2_i2c *dln2, u8 addr,
+ u8 *data, u16 data_len)
+{
+   int ret;
+   struct {
+   u8 port;
+   u8 addr;
+   u8 mem_addr_len;
+   __le32 mem_addr;
+   __le16 buf_len;
+   u8 buf[DLN2_I2C_MAX_XFER_SIZE];
+   } __packed *tx = dln2->buf;
+   unsigned len;
+
+   BUILD_BUG_ON(sizeof(*tx) > DLN2_I2C_BUF_SIZE);
+
+   tx->port = dln2->port;

[PATCH v10 3/3] gpio: add support for the Diolan DLN-2 USB GPIO driver

[Octavian Purdila]

From: Daniel Baluta 

This patch adds GPIO and IRQ support for the Diolan DLN-2 GPIO module.

Information about the USB protocol interface can be found in the
Programmer's Reference Manual [1], see section 2.9 for the GPIO
module commands and responses.

[1] https://www.diolan.com/downloads/dln-api-manual.pdf

Signed-off-by: Daniel Baluta 
Signed-off-by: Octavian Purdila 
Acked-by: Linus Walleij 
---
 drivers/gpio/Kconfig |  12 +
 drivers/gpio/Makefile|   1 +
 drivers/gpio/gpio-dln2.c | 553 +++
 3 files changed, 566 insertions(+)
 create mode 100644 drivers/gpio/gpio-dln2.c

diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 0959ca9..23dfd5f 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -905,4 +905,16 @@ config GPIO_VIPERBOARD
   River Tech's viperboard.h for detailed meaning
   of the module parameters.
 
+config GPIO_DLN2
+   tristate "Diolan DLN2 GPIO support"
+   depends on MFD_DLN2
+   select GPIOLIB_IRQCHIP
+
+   help
+ Select this option to enable GPIO driver for the Diolan DLN2
+ board.
+
+ This driver can also be built as a module. If so, the module
+ will be called gpio-dln2.
+
 endif
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index e5d346c..e60677b 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -26,6 +26,7 @@ obj-$(CONFIG_GPIO_CRYSTAL_COVE)   += gpio-crystalcove.o
 obj-$(CONFIG_GPIO_DA9052)  += gpio-da9052.o
 obj-$(CONFIG_GPIO_DA9055)  += gpio-da9055.o
 obj-$(CONFIG_GPIO_DAVINCI) += gpio-davinci.o
+obj-$(CONFIG_GPIO_DLN2)+= gpio-dln2.o
 obj-$(CONFIG_GPIO_DWAPB)   += gpio-dwapb.o
 obj-$(CONFIG_GPIO_EM)  += gpio-em.o
 obj-$(CONFIG_GPIO_EP93XX)  += gpio-ep93xx.o
diff --git a/drivers/gpio/gpio-dln2.c b/drivers/gpio/gpio-dln2.c
new file mode 100644
index 000..978b51e
--- /dev/null
+++ b/drivers/gpio/gpio-dln2.c
@@ -0,0 +1,553 @@
+/*
+ * Driver for the Diolan DLN-2 USB-GPIO adapter
+ *
+ * Copyright (c) 2014 Intel Corporation
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation, version 2.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DLN2_GPIO_ID   0x01
+
+#define DLN2_GPIO_GET_PIN_COUNTDLN2_CMD(0x01, DLN2_GPIO_ID)
+#define DLN2_GPIO_SET_DEBOUNCE DLN2_CMD(0x04, DLN2_GPIO_ID)
+#define DLN2_GPIO_GET_DEBOUNCE DLN2_CMD(0x05, DLN2_GPIO_ID)
+#define DLN2_GPIO_PORT_GET_VAL DLN2_CMD(0x06, DLN2_GPIO_ID)
+#define DLN2_GPIO_PIN_GET_VAL  DLN2_CMD(0x0B, DLN2_GPIO_ID)
+#define DLN2_GPIO_PIN_SET_OUT_VAL  DLN2_CMD(0x0C, DLN2_GPIO_ID)
+#define DLN2_GPIO_PIN_GET_OUT_VAL  DLN2_CMD(0x0D, DLN2_GPIO_ID)
+#define DLN2_GPIO_CONDITION_MET_EV DLN2_CMD(0x0F, DLN2_GPIO_ID)
+#define DLN2_GPIO_PIN_ENABLE   DLN2_CMD(0x10, DLN2_GPIO_ID)
+#define DLN2_GPIO_PIN_DISABLE  DLN2_CMD(0x11, DLN2_GPIO_ID)
+#define DLN2_GPIO_PIN_SET_DIRECTIONDLN2_CMD(0x13, DLN2_GPIO_ID)
+#define DLN2_GPIO_PIN_GET_DIRECTIONDLN2_CMD(0x14, DLN2_GPIO_ID)
+#define DLN2_GPIO_PIN_SET_EVENT_CFGDLN2_CMD(0x1E, DLN2_GPIO_ID)
+#define DLN2_GPIO_PIN_GET_EVENT_CFGDLN2_CMD(0x1F, DLN2_GPIO_ID)
+
+#define DLN2_GPIO_EVENT_NONE   0
+#define DLN2_GPIO_EVENT_CHANGE 1
+#define DLN2_GPIO_EVENT_LVL_HIGH   2
+#define DLN2_GPIO_EVENT_LVL_LOW3
+#define DLN2_GPIO_EVENT_CHANGE_RISING  0x11
+#define DLN2_GPIO_EVENT_CHANGE_FALLING  0x21
+#define DLN2_GPIO_EVENT_MASK   0x0F
+
+#define DLN2_GPIO_MAX_PINS 32
+
+struct dln2_irq_work {
+   struct work_struct work;
+   struct dln2_gpio *dln2;
+   int pin;
+   int type;
+};
+
+struct dln2_gpio {
+   struct platform_device *pdev;
+   struct gpio_chip gpio;
+
+   /*
+* Cache pin direction to save us one transfer, since the hardware has
+* separate commands to read the in and out values.
+*/
+   DECLARE_BITMAP(output_enabled, DLN2_GPIO_MAX_PINS);
+
+   DECLARE_BITMAP(irqs_masked, DLN2_GPIO_MAX_PINS);
+   DECLARE_BITMAP(irqs_enabled, DLN2_GPIO_MAX_PINS);
+   DECLARE_BITMAP(irqs_pending, DLN2_GPIO_MAX_PINS);
+   struct dln2_irq_work *irq_work;
+};
+
+struct dln2_gpio_pin {
+   __le16 pin;
+};
+
+struct dln2_gpio_pin_val {
+   __le16 pin __packed;
+   u8 value;
+};
+
+static int dln2_gpio_get_pin_count(struct platform_device *pdev)
+{
+   int ret;
+   __le16 count;
+   int len = sizeof(count);
+
+   ret = dln2_transfer_rx(pdev, DLN2_GPIO_GET_PIN_COUNT, &count, &len);
+   if (ret < 0)
+   return ret;
+   if (len < sizeof(count))
+   return -EPROTO;
+
+   return le16_to_cpu(count);
+}
+
+static int dln2_gpio_pin_cmd(struct 

Re: [PATCH v10 3/3] gpio: add support for the Diolan DLN-2 USB GPIO driver

[Johan Hovold]

On Wed, Nov 05, 2014 at 07:05:01PM +0200, Octavian Purdila wrote:
> From: Daniel Baluta 
> 
> This patch adds GPIO and IRQ support for the Diolan DLN-2 GPIO module.
> 
> Information about the USB protocol interface can be found in the
> Programmer's Reference Manual [1], see section 2.9 for the GPIO
> module commands and responses.
> 
> [1] https://www.diolan.com/downloads/dln-api-manual.pdf
> 
> Signed-off-by: Daniel Baluta 
> Signed-off-by: Octavian Purdila 
> Acked-by: Linus Walleij 

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

Re: [PATCH v10 1/3] mfd: add support for Diolan DLN-2 devices

[Johan Hovold]

On Wed, Nov 05, 2014 at 07:04:59PM +0200, Octavian Purdila wrote:
> This patch implements the USB part of the Diolan USB-I2C/SPI/GPIO
> Master Adapter DLN-2. Details about the device can be found here:
> 
> https://www.diolan.com/i2c/i2c_interface.html.
> 
> Information about the USB protocol can be found in the Programmer's
> Reference Manual [1], see section 1.7.
> 
> Because the hardware has a single transmit endpoint and a single
> receive endpoint the communication between the various DLN2 drivers
> and the hardware will be muxed/demuxed by this driver.
> 
> Each DLN2 module will be identified by the handle field within the DLN2
> message header. If a DLN2 module issues multiple commands in parallel
> they will be identified by the echo counter field in the message header.
> 
> The DLN2 modules can use the dln2_transfer() function to issue a
> command and wait for its response. They can also register a callback
> that is going to be called when a specific event id is generated by
> the device (e.g. GPIO interrupts). The device uses handle 0 for
> sending events.
> 
> [1] https://www.diolan.com/downloads/dln-api-manual.pdf
> 
> Signed-off-by: Octavian Purdila 

Reviewed-by: Johan Hovold 

Just noticed checkpatch complains about two typos in the header file
(since v9?). ;)

Thanks,
Johan
--
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 Resend] USB: cdc-acm: only raise DTR on transitions from B0

[Johan Hovold]

Make sure to only raise DTR on transitions from B0 in set_termios.

Also allow set_termios to be called from open with a termios_old of
NULL. Note that DTR will not be raised prematurely in this case.

Cc: stable 
Signed-off-by: Johan Hovold 
---

Greg,

I just noticed that this one did not make into usb-linus yet, although
24cb4502c97b ("cdc-acm: ensure that termios get set when the port is
activated"), which depend on this patch did.

Johan


 drivers/usb/class/cdc-acm.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/class/cdc-acm.c b/drivers/usb/class/cdc-acm.c
index 6771f884cb82..9d6495424b06 100644
--- a/drivers/usb/class/cdc-acm.c
+++ b/drivers/usb/class/cdc-acm.c
@@ -985,11 +985,12 @@ static void acm_tty_set_termios(struct tty_struct *tty,
/* FIXME: Needs to clear unsupported bits in the termios */
acm->clocal = ((termios->c_cflag & CLOCAL) != 0);
 
-   if (!newline.dwDTERate) {
+   if (C_BAUD(tty) == B0) {
newline.dwDTERate = acm->line.dwDTERate;
newctrl &= ~ACM_CTRL_DTR;
-   } else
+   } else if (termios_old && (termios_old->c_cflag & CBAUD) == B0) {
newctrl |=  ACM_CTRL_DTR;
+   }
 
if (newctrl != acm->ctrlout)
acm_set_control(acm, acm->ctrlout = newctrl);
-- 
2.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: [3.16.1 BISECTED REGRESSION]: Simtec Entropy Key (cdc-acm) broken in 3.16

[Johan Hovold]

On Wed, Nov 05, 2014 at 03:14:49PM +, Nix wrote:
> On 5 Nov 2014, Johan Hovold stated:
> 
> > On Fri, Oct 31, 2014 at 04:44:46PM +, Nix wrote:
> >> Sorry for the delay: illness and work-related release time flurries.
> >> 
> >> On 24 Oct 2014, Johan Hovold told this:
> >> 

> > The log appears incomplete again, this time it seems the last part is
> > completely missing (the device is never closed for example). The device
> > still seems to be responding.
> 
> Nope -- by the time I clipped the log, the device was definitely
> nonresponsive.
>
> I've appended the remaining log, just in case. This is the same as the
> snapshot I added to the email itself last time: a close-and-open as I
> tried restarting the daemon, and another close as part of system
> shutdown.

Ok, yeah, there's the crash.

> >> >  What if you
> >> > physically disconnect and reconnect the device instead, or simply
> >> 
> >> That fixes it, in fact it's the only way to fix it once it's broken by
> >> this bug.
> >
> > I didn't mean whether it would get the device working again, but rather
> > whether you could kill it this way.
> 
> Never seen it fail after a physical disconnection.

Ok.

And it has to include an enumeration, since just opening and closing it
(restarting the daemon) repeatedly seems to work?

> >> ... no, that doesn't help. Additional log from that shows a lot of what
> >> looks like error returns:
> >> 
> >> Oct 31 16:38:03 fold kern debug: : [  168.135213] cdc_acm 2-1:1.0: 
> >> acm_tty_close
> >> Oct 31 16:38:08 fold kern debug: : [  173.130531] cdc_acm 2-1:1.0: 
> >> acm_ctrl_msg - rq 0x22, val 0x0, len 0x0, result -110
> >
> > Yeah, it seems your device firmware has crashed. It stops responding to
> > control requests.
> 
> Not surprising: I was fairly sure we were provoking a key firmware crash
> or something like that. This is a device with no support for flow
> control at all, after all, so I'm not terribly surprised that trying to
> do flow control confuses it.

Only weird thing is that it has been coping with those calls for a long
time. Only the slightly changed timings seems to have triggered this
issue.

> > The above is all normal, but
> >
> >> Oct 31 16:38:08 fold kern debug: : [  173.161489] cdc_acm 2-1:1.0: 
> >> acm_ctrl_msg - rq 0x22, val 0x3, len 0x0, result -62
> >
> > here's another timeout. It's dead.
> 
> Again, not surprising.
> 
> > Did you get anywhere with trying to look at the device firmware?
> 
> Look at it? Only Daniel Silverstone (Cc:ed) can do that. The only copy
> of the firmware I have is baked into the sealed key. :)

Ah, ok. I guess we need a new quirk then. There's already a quirk in the
driver to suppress error from when trying to set the control lines.

But that doesn't help this device, which happily accepts the requests
and then dies at random times.

Could you try two more things (too make sure line control is really the
culprit):

1. If you clear HUPCL in ekeyd so that the lines are never lowered, does
that fix the stability issue?

2. Can you verify that the patch below works? Did I use the correct
VID/PID? Could you provide "lsusb -v" output (for the capability flags)
as well?

Note that the patch is against the usb-linus branch of the usb tree,
which also contains another fix which could affect this device
(set_termios will now be called an extra time on every open). You also
need this one, which have not yet been applied:

http://marc.info/?l=linux-usb&m=141520959813505&w=2

Thanks,
Johan


>From 76abc8a7eda9ea1978ee3527c773210c28332317 Mon Sep 17 00:00:00 2001
From: Johan Hovold 
Date: Wed, 5 Nov 2014 18:51:54 +0100
Subject: [PATCH] USB: cdc-acm: add quirk for control-line state requests

Add new quirk for devices that cannot handle control-line state
requests.

Note that we currently send these requests to all devices, regardless of
whether they claim to support it, but that errors are only logged if
support is claimed.

Since commit 0943d8ead30e ("USB: cdc-acm: use tty-port dtr_rts"), which
only changed the timings for these requests slightly, this has been
reported to cause occasional firmware crashes on Simtec Electronics
Entropy Key devices after re-enumeration. Enable the quirk for this
device.

Reported-by: Nix 
Cc: stable  # v3.16
Signed-off-by: Johan Hovold 
---
 drivers/usb/class/cdc-acm.c | 14 --
 drivers/usb/class/cdc-acm.h |  2 ++
 2 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/class/cdc-acm.c b/drivers/usb/class/cdc-acm.c
index 9d6495424b06..077d58ac3dcb 100644
--- a/drivers/usb/class/cdc-acm.c
+++ b/drivers/usb/class/cdc-acm.c
@@ -148,8 +148,15 @@ static int acm_ctrl_msg(struct acm *acm, int request, int 
value,
 /* devices aren't required to support these requests.
  * the cdc acm descriptor tells whether they do...
  */
-#define acm_set_control(acm, control) \
-   acm_ctrl_msg(acm, USB_CDC_REQ_SET_CONTROL_LINE_STATE, control, NULL, 0)
+stati

Re: [Regression][v3.17][v3.18] USB: Fix persist resume of some SS USB devices

[Joseph Salisbury]

On 11/05/2014 03:48 AM, Pratyush Anand wrote:
> On Wed, Nov 05, 2014 at 10:53:35AM +0530, Pratyush Anand wrote:
>> Hello Joe,
>>
>> On Wed, Nov 05, 2014 at 06:20:06AM +0800, Joseph Salisbury wrote:
>>> Hello Pratyush,
>>>
>>> A kernel bug report was opened against Ubuntu [0].  After a kernel
>>> bisect, it was found that reverting the following commit resolved this bug:
>>>
>>> commit a40178b2fa6ad87670fb1e5fa4024db00c149629
>>> Author: Pratyush Anand 
>>> Date:   Fri Jul 18 12:37:10 2014 +0530
>>>
>>> USB: Fix persist resume of some SS USB devices
>>>
>>> The regression was introduced as of v3.17-rc1.  The regression still
>>> exists in the 3.18-rc3 mainline kernel, and has made it's way into the
>>> stable kernels.
>> Its strange, as per my understanding patch does not introduce any side
>> effect for devices whose resume time is normal. So, if a device is
>> connected to the SS port and it was working after resume from
>> suspend to ram without this patch, then that device should still work
>> with this patch.
>>
>> Infact this has resolved another bug reported to bugzilla
>> https://bugzilla.kernel.org/show_bug.cgi?id=53211
>>
>>
>>> I was hoping to get your feedback, since you are the patch author.  Do
>>> you think gathering any additional data will help diagnose this issue,
>> Yaa, sure additional info will help to understand the issue.
>> -- dmesg log of suspend resume when this patch is not applied and also
>> when applied.
> I see that you have already provided both log to the buglink. I had a
> look on that. 
>
>
> When it fails (with this patch):
> Oct 22 15:38:59 mana kernel: [   59.825122] PM: resume of devices
> complete after 3.878 msecs
>
> When it passed (without this patch):
> Oct 22 15:37:19 mana kernel: [   53.495109] PM: resume of devices
> complete after 3641.933 msecs
> However, even when patch was not present(and it passed), there is a logical
> disconnection of devices, so you would face the issue mentioned in
> https://bugzilla.kernel.org/show_bug.cgi?id=53211.
>
> Looking to the timeout, it seems that wait loop went for full length
> (2S) for all the devices, still could not find a connected device. So,
> basically SS link between root hub and hub was not up in 2 sec. Not
> sure why, but reading further hub port status caused some fatal issue
> with xhci host and so it is not able to get new device connection
> after logical disconnection.
>
> Increasing the timeout value may help. But with this long timeout I see a
> possibility of sync issue between port_event and usb_port_resume. It
> might happen that port_event reads hub port status before
> usb_port_resume handles reset_resume.
>
> Can you try following patch with step increasing varied value of
> PORT_ENABLE_WAIT, and then let me know which value of
> PORT_ENABLE_WAIT works for you (if it works ;)).
>
> diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
> index 11e80ac31324..6eaf481d3d53 100644
> --- a/drivers/usb/core/hub.c
> +++ b/drivers/usb/core/hub.c
> @@ -3311,13 +3311,14 @@ static int finish_port_resume(struct usb_device *udev)
>   * This routine should only be called when persist is enabled for a SS
>   * device.
>   */
> +#define PORT_ENABLE_WAIT 2000
>  static int wait_for_ss_port_enable(struct usb_device *udev,
>   struct usb_hub *hub, int *port1,
>   u16 *portchange, u16 *portstatus)
>  {
>   int status = 0, delay_ms = 0;
>  
> - while (delay_ms < 2000) {
> + while (delay_ms < PORT_ENABLE_WAIT) {
>   if (status || *portstatus & USB_PORT_STAT_CONNECTION)
>   break;
>   msleep(20);
> @@ -4881,6 +4882,22 @@ static void hub_port_connect_change(struct usb_hub 
> *hub, int port1,
>   usb_lock_port(port_dev);
>  }
>  
> +static void wait_for_reset_resume(struct usb_hub *hub, int port)
> +{
> + struct usb_device *udev;
> + int delay_ms = 0;
> +
> + udev = hub->ports[port -1]->child;
> + if (udev && udev->reset_resume) {
> + while (delay_ms < PORT_ENABLE_WAIT) {
> + if (!udev->reset_resume)
> + break;
> + msleep(20);
> + delay_ms += 20;
> + }
> + }
> +}
> +
>  static void port_event(struct usb_hub *hub, int port1)
>   __must_hold(&port_dev->status_lock)
>  {
> @@ -4894,6 +4911,8 @@ static void port_event(struct usb_hub *hub, int port1)
>   clear_bit(port1, hub->event_bits);
>   clear_bit(port1, hub->wakeup_bits);
>  
> + wait_for_reset_resume(hub, port1);
> +
>   if (hub_port_status(hub, port1, &portstatus, &portchange) < 0)
>   return;
>  
> Regards
> Pratyush

Thanks for the feedback, Pratyush.  We'll test your patch and get back
to you.


>
>> -- dmesg log with following additional debug print.
>> @@ -3318,6 +3318,7 @@ static int wait_for_ss_port_enable(struct usb_device 
>> *udev,
>> int status = 0, delay_ms = 0;
>>  
>>  

Re: usb media detection issue on USB_MUSB_HDRC on kernel 3.17

[Angelo Dureghello]

I have some more, hope useful info on this issue,
i am working now in MUSB_OTG mode, as default

See what is happening on the table below.

Device (arm, am1808 cpu) boots

 state
eventchanges to  devctl

boot
interruptb_idle  0x81  (b1001, B device, session start)
interrupta_wait_vrise0x19  (b00011001, A device, above VBUS valid)
key inserted
interrupta_host  0x5d  (b01011101, A device, host mode,above 
VBUS valid)
interrupta_host  0x5d (b01011101, A device, host mode,above 
VBUS valid)
interrupt a_host  0x5d  (b01011101, A device, host mode,above 
VBUS valid)


interruptrepeated several times

key removed (some scsi I/O errors appears)
interruptb_idle  0x98  (b10011000, B device, above VBUS 
valid, session end)
interruptb_idle  0x99  (b10011001, B device, above VBUS 
valid, session start)


from here, there is no more reaction and / or interrupt happening
inserting or removing the key. State remains stucked on b_host.



--
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: phy: mxs: change test clock gating on connection/disconnection

[Vladimir Zapolskiy]

On some boards powered by iMX6Q rev1.0 I get non-working USB Host 1
(connected to a hub, no other devices are connected to this hub) and
repeating resets from the chipidea host driver (with ported pm support
from Freescale):

  
  [   25.481714] usb 2-1: reset high-speed USB device number 2 using ci_hdrc
  [   27.491716] usb 2-1: reset high-speed USB device number 2 using ci_hdrc
  [   29.501721] usb 2-1: reset high-speed USB device number 2 using ci_hdrc
  

As for me it seems that usb phy test clock gating may be done
incorrectly, on disconnection it is running, and on connection it is
gated, but may be it is the intention, unfortunately iMX6Q RM is not
a satisfactory source of information on the topic.

Either complete disabling of loopback for the host or inverting test
clock gating solves my problem, this change proposes to invert test
clock gating setting.

Signed-off-by: Vladimir Zapolskiy 
Cc: Peter Chen 
---
 drivers/usb/phy/phy-mxs-usb.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/phy/phy-mxs-usb.c b/drivers/usb/phy/phy-mxs-usb.c
index 0e0c415..fbd079f 100644
--- a/drivers/usb/phy/phy-mxs-usb.c
+++ b/drivers/usb/phy/phy-mxs-usb.c
@@ -231,7 +231,7 @@ static void __mxs_phy_disconnect_line(struct mxs_phy 
*mxs_phy, bool disconnect)
 
if (disconnect)
writel_relaxed(BM_USBPHY_DEBUG_CLKGATE,
-   base + HW_USBPHY_DEBUG_CLR);
+   base + HW_USBPHY_DEBUG_SET);
 
if (mxs_phy->port_id == 0) {
reg = disconnect ? ANADIG_USB1_LOOPBACK_SET
@@ -249,7 +249,7 @@ static void __mxs_phy_disconnect_line(struct mxs_phy 
*mxs_phy, bool disconnect)
 
if (!disconnect)
writel_relaxed(BM_USBPHY_DEBUG_CLKGATE,
-   base + HW_USBPHY_DEBUG_SET);
+   base + HW_USBPHY_DEBUG_CLR);
 
/* Delay some time, and let Linestate be SE0 for controller */
if (disconnect)
-- 
1.7.10.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: Large disk drives

[Boaz Harrosh]

On 11/05/2014 06:34 PM, Alan Stern wrote:
<>
> 
> It's simpler than that: The drive is attached directly to the computer
> (i.e., via SATA rather than USB) when the partition table is created.  
> With no USB-SATA bridge chip to mess things up, there's no problem
> determining the correct capacity.
> 

Right!

I think it should be very simple to, just as we send a
READ_CAPACITY16 / READ_CAPACITY32 / READ_CAPACITY64 or is
it a GET_CODE_PAGE ? whatever we send today we can also
have READ_CAPACITY_PART() which will send a READ of
sector 0 the raw PC_COMMAND way and run it through some
partition analyzer. We only need to support gpt or msdos
partitions I think in this case.

Then if READ_CAPACITY16 returns all (s) and
READ_CAPACITY32 is not supported and/or blacklisted,
then yes attempt a READ_CAPACITY_PART() which should
be sam-2 compatible.

It should not take longer than a weekend afternoon over
cup of Machha. If any one sends a bad device my way, I'll
do it. But anyone should be able to code something so simple.

> Alan Stern
> 

Cheers
Boaz

--
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: phy: mxs: change test clock gating on connection/disconnection

[Felipe Balbi]

On Wed, Nov 05, 2014 at 08:52:25PM +0200, Vladimir Zapolskiy wrote:
> On some boards powered by iMX6Q rev1.0 I get non-working USB Host 1
> (connected to a hub, no other devices are connected to this hub) and
> repeating resets from the chipidea host driver (with ported pm support
> from Freescale):
> 
>   
>   [   25.481714] usb 2-1: reset high-speed USB device number 2 using ci_hdrc
>   [   27.491716] usb 2-1: reset high-speed USB device number 2 using ci_hdrc
>   [   29.501721] usb 2-1: reset high-speed USB device number 2 using ci_hdrc
>   
> 
> As for me it seems that usb phy test clock gating may be done
> incorrectly, on disconnection it is running, and on connection it is
> gated, but may be it is the intention, unfortunately iMX6Q RM is not
> a satisfactory source of information on the topic.
> 
> Either complete disabling of loopback for the host or inverting test
> clock gating solves my problem, this change proposes to invert test
> clock gating setting.
> 
> Signed-off-by: Vladimir Zapolskiy 
> Cc: Peter Chen 

Make sure to Cc the maintainer of the framework, that'll help make sure
your patch is not lost.

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH 00/17] usb: gadget: convert udc driver to use udc-core's reset notifier

[Felipe Balbi]

On Mon, Oct 27, 2014 at 08:13:54AM +0800, Peter Chen wrote:
> On Tue, Sep 16, 2014 at 09:26:35PM -0500, Felipe Balbi wrote:
> > Hi,
> > 
> > On Wed, Sep 17, 2014 at 09:13:53AM +0800, Peter Chen wrote:
> > > Hi Felipe,
> > > 
> > > In this series, I convert udc driver to use udc-core's reset notifier
> > > which has added recently, I only change the drivers which has
> > > bus reset handler and call usb_gadget_driver's ->disconnect in it.
> > > 
> > > For five you and Alan's patches, I cherry-pick them from your
> > > gadget-add-reset-method branch and change some code and comments
> > > for using udc-core's reset notifier.
> > > 
> > > This series is based on yours next tree, and pass the compile test
> > > and checkpatch.pl.
> > > 
> > > Alan Stern (3):
> > >   usb: gadget: dummy-hcd: use udc-core's reset notifier
> > >   usb: gadget: net2280: use udc-core's reset notifier
> > >   usb: gadget: net2272: use udc-core's reset notifier
> > > 
> > > Felipe Balbi (2):
> > >   usb: dwc3: gadget: use udc-core's reset notifier
> > >   usb: musb: gadget: use udc-core's reset notifier
> > > 
> > > Peter Chen (12):
> > >   usb: chipidea: gadget: use udc-core's reset notifier
> > >   usb: gadget: pxa25x_udc: use udc-core's reset notifier
> > >   usb: gadget: m66592-udc: use udc-core's reset notifier
> > >   usb: gadget: fsl_udc_core: use udc-core's reset notifier
> > >   usb: gadget: at91_udc: use udc-core's reset notifier
> > >   usb: gadget: mv_udc_core: use udc-core's reset notifier
> > >   usb: gadget: fsl_qe_udc: use udc-core's reset notifier
> > >   usb: gadget: pch_udc: use udc-core's reset notifier
> > >   usb: gadget: amd5536udc: use udc-core's reset notifier
> > >   usb: gadget: r8a66597-udc: use udc-core's reset notifier
> > >   usb: gadget: bcm63xx_udc: use udc-core's reset notifier
> > >   usb: gadget: atmel_usba_udc: use udc-core's reset notifier
> > 
> > thanks, but I'll have to defer this one for v3.19. I already closed my
> > tree. I'll ask you to resend these once v3.18-rc1 is tagged, until them
> > I'm dropping them from my queue otherwise I'll go a little nuts. In any
> > case, this gives people some time to review and ack your patches.
> > 
> 
> Felipe, is it ok I recend them now?

Sorry, I missed this email. Please resend. It should be fine now :-)

Thanks for your patience.

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH] usb: gadget: don't create new string_container if already exist

[Felipe Balbi]

On Tue, Nov 04, 2014 at 03:05:57AM -0800, Neil Zhang wrote:
> 
> > -Original Message-
> > From: Andrzej Pietrasiewicz [mailto:andrze...@samsung.com]
> > Sent: 2014年10月28日 21:10
> > To: Neil Zhang; linux-usb@vger.kernel.org; linux-ker...@vger.kernel.org
> > Cc: ba...@ti.com; gre...@linuxfoundation.org
> > Subject: Re: [PATCH] usb: gadget: don't create new string_container if 
> > already
> > exist
> > 
> > Hi,
> > 
> > W dniu 28.10.2014 o 12:33, Neil Zhang pisze:
> > > Don't create new usb_gadget_string_container if the current strings
> > > are already exist in the usb_composite_dev.
> > > Otherwise the ids_tab will overflow soon if we bind / unbind usb
> > > functions frequently like android does.
> > 
> > The problem you are describing does not exist in mainline kernel, where
> > functions are always unbound as part of the whole gadget's unbind - 
> > regardless
> > of whether it is a legacy gadget or configfs-composed gadget. When the whole
> > gadget is unbound, composite_dev_cleanup() is called which zeroes cdev-
> > >next_string_id and frees all gadget strings containers.
> > 
> 
> Yes, you are right that the current mainline won't suffer this issue.
> But it will be needed if we want to implement similar features like android 
> do.

once you have the features, then implement it. I don't want any unused
code here, specially since it won't be tested by anything.

> It will only remove config rather than whole gadget driver.

also, this is just wrong. You can't remove just one configuration, you
need to remove the whole thing and the host needs to see a
disconnection.

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH usb v3 00/29] cleanup and fixes on resource check

[Felipe Balbi]

Hi,

On Tue, Nov 04, 2014 at 06:46:16AM +0530, Varka Bhadram wrote:
> Hi greg k-h,
> 
> On Tuesday 04 November 2014 05:16 AM, Greg KH wrote:
> >On Fri, Oct 31, 2014 at 05:31:41PM +0300, Sergei Shtylyov wrote:
> >>Hello.
> >>
> >>On 10/31/2014 4:14 AM, Varka Bhadram wrote:
> >>
> >>>This series removes the duplication of sanity check for
> >>>platform_get_resource() return resource. It will be checked
> >>>with devm_ioremap_resource()
> >>>This entire series rebased on testing/fixes of [1].
> >>>[1]: http://git.kernel.org/cgit/linux/kernel/git/balbi/usb.git
> >>
> >>>changes since v1:
> >>>   - removed broken patches
> >>>   - added Ack of Alan Stern for all the ehci, ohci, and uhci changes.
> >>>changes since v2:
> >>>   - addressed Sergei Shtylyov comments
> >>>Varka Bhadram (29):
> >>>   host: ehci-atmel: remove duplicate check on resource
> >>>   host: ohci-da8xx: remove duplicate check on resource
> >>>   host: ehci-tegra: remove duplicate check on resource
> >>>   host: ehci-w90x900: remove duplicate check on resource
> >>>   host: ohci-at91: remove duplicate check on resource
> >>>   host: ohci-exynos: remove duplicate check on resource
> >>>   host: ohci-jz4740: remove duplicate check on resource
> >>>   host: ohci-octeon: remove duplicate check on resource
> >>>   host: ohci-platform: remove duplicate check on resource
> >>>   host: ohci-pxa27x: remove duplicate check on resource
> >>>   host: ehci-sh: remove duplicate check on resource
> >>>   host: ohci-spear: remove duplicate check on resource
> >>>   host: ehci-msm: remove duplicate check on resource
> >>>   host: ehci-mv: remove duplicate check on resource
> >>>   host: ehci-mxc: remove duplicate check on resource
> >>>   host: ehci-octeon: remove duplicate check on resource
> >>>   host: ehci-orion: remove duplicate check on resource
> >>>   host: ehci-platform: remove duplicate check on resource
> >>>   host: ehci-sead3: fix NULL pointer dereference on resource
> >>
> >>Mixing fixes and cleanups in one series is not a good idea, generally
> >>speaking.
> >I agree.  Send me the fixes "first" in a series, so that I can get them
> >into this kernel release, and older ones.  Then send the cleanups in a
> >separate series based on your first one, if needed, and all should be
> >good.
> 
> I will send the fixes based on [1] usb-next branch first, then cleanup
> as a separate series.
> 
> But balbi told that these series should go through his [2] kernel
> tree. Can i send this entire series based on [1] usb-next branch..?

read again my comment. I said that I take care of dwc3, dwc2, renesas,
usb gadget, musb, and PHY. I don't have any thing to do with the host
side.

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH v2 2/2] [usb] add support for ACPI identification to xhci-platform

[Greg KH]

On Wed, Nov 05, 2014 at 07:59:32AM -0600, Mark Langsdorf wrote:
> >>  static struct platform_driver usb_xhci_driver = {
> >>.probe  = xhci_plat_probe,
> >>.remove = xhci_plat_remove,
> >>@@ -294,6 +304,7 @@ static struct platform_driver usb_xhci_driver = {
> >>.name = "xhci-hcd",
> >>.pm = DEV_PM_OPS,
> >>.of_match_table = of_match_ptr(usb_xhci_of_match),
> >>+   .acpi_match_table = ACPI_PTR(usb_xhci_acpi_match),
> >
> >Shouldn't the reworked driver core code handle this differently with the
> >ability to handle either OF or ACPI in the same driver?
> 
> I'm not sure I understand the question. With these changes, the driver
> handles both ACPI and DTB/OF. It's the same style of code as used
> in drivers/ata/plat-xgene.c, which also handles both ACPI and DTB/OF.
> Why do you think this code isn't correct?

There is a new framework in the kernel that keeps a driver from having
to query both of and acpi to get the needed resources, it just does one
query and depending on the platform, everything "just works".  Shouldn't
that be used here 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: Large disk drives

[Theodore Ts'o]

On Wed, Nov 05, 2014 at 05:07:48PM +0100, James Bottomley wrote:
> 
> OK, but I still don't understand how windows gets the partition table on
> there in the first place ... that must surely be some sort of guess the
> disk size hack.

99% of the time the partition table was provided by the drive
manufacturer; I would assume they have a way of doing that as a part
of their manufacturing processes that don't require an OS individually
running the equivalent of fdisk or gdisk on said drive.

   - Ted
--
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 RESEND v2] usb: gadget: Add UDC driver for Broadcom USB3.0 device controller IP BDC

[Felipe Balbi]

On Fri, Oct 31, 2014 at 01:14:33PM -0700, Ashwini Pahuja wrote:
> This patch adds a UDC driver for Broadcom's USB3.0 Peripheral core
> named BDC. BDC is capable of supporting all transfer types control,
> bulk, Int and isoch on each endpoint.
> 
> Signed-off-by: Ashwini Pahuja 
> ---
> Changes for v2:
> - Includes all the feedback provided by Felipe on the v1.
> - Removed unnecessary out of memory messages.
> - Added usb_gadget_giveback_request.
> - udc_stop: removed unnecessary driver argument.
> - Removed unused defines.
> - Renamed upsc to uspc.

which platform uses this ? Is the platform working in mainline today ?
Can you show me boot up logs and logs of this driver working with g_zero
and g_mass_storage ? Also make sure to run USB20CV chapter 9 with both
g_zero and mass_storage and post the logs somewhere I can access, or
just attach everything to this mail as a tarball or something.

> diff --git a/drivers/usb/gadget/udc/bdc/bdc_dbg.c 
> b/drivers/usb/gadget/udc/bdc/bdc_dbg.c
> new file mode 100644
> index 000..ab109b2
> --- /dev/null
> +++ b/drivers/usb/gadget/udc/bdc/bdc_dbg.c
> @@ -0,0 +1,231 @@
> +/*
> + * bdc_dbg.c - BRCM BDC USB3.0 device controller debug functions
> + *
> + * Copyright (C) 2014 Broadcom Corporation
> + *
> + * Author: Ashwini Pahuja
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License as published by the
> + * Free Software Foundation; either version 2 of the License, or (at your
> + * option) any later version.
> + *
> + */
> +
> +#include "bdc.h"
> +#include "bdc_dbg.h"
> +
> +void bdc_dbg_regs(struct bdc *bdc)
> +{
> + u32 temp;
> +
> + dev_dbg(bdc->dev, "bdc->regs:%p\n", bdc->regs);
> + temp = bdc_readl(bdc->regs, BDC_BDCCFG0);
> + dev_dbg(bdc->dev, "bdccfg0:0x%08x\n", temp);
> + temp = bdc_readl(bdc->regs, BDC_BDCCFG1);
> + dev_dbg(bdc->dev, "bdccfg1:0x%08x\n", temp);
> + temp = bdc_readl(bdc->regs, BDC_BDCCAP0);
> + dev_dbg(bdc->dev, "bdccap0:0x%08x\n", temp);
> + temp = bdc_readl(bdc->regs, BDC_BDCCAP1);
> + dev_dbg(bdc->dev, "bdccap1:0x%08x\n", temp);
> + temp = bdc_readl(bdc->regs, BDC_USPC);
> + dev_dbg(bdc->dev, "uspc:0x%08x\n", temp);
> + temp = bdc_readl(bdc->regs, BDC_DVCSA);
> + dev_dbg(bdc->dev, "dvcsa:0x%08x\n", temp);
> + temp = bdc_readl(bdc->regs, BDC_DVCSB);
> + dev_dbg(bdc->dev, "dvcsb:0x%x08\n", temp);
> +}
> +
> +void bdc_dump_epsts(struct bdc *bdc)
> +{
> + u32 temp;
> +
> + temp = bdc_readl(bdc->regs, BDC_EPSTS0(0));
> + dev_vdbg(bdc->dev, "BDC_EPSTS0:0x%08x\n", temp);
> +
> + temp = bdc_readl(bdc->regs, BDC_EPSTS1(0));
> + dev_vdbg(bdc->dev, "BDC_EPSTS1:0x%x\n", temp);
> +
> + temp = bdc_readl(bdc->regs, BDC_EPSTS2(0));
> + dev_vdbg(bdc->dev, "BDC_EPSTS2:0x%08x\n", temp);
> +
> + temp = bdc_readl(bdc->regs, BDC_EPSTS3(0));
> + dev_vdbg(bdc->dev, "BDC_EPSTS3:0x%08x\n", temp);
> +
> + temp = bdc_readl(bdc->regs, BDC_EPSTS4(0));
> + dev_vdbg(bdc->dev, "BDC_EPSTS4:0x%08x\n", temp);
> +
> + temp = bdc_readl(bdc->regs, BDC_EPSTS5(0));
> + dev_vdbg(bdc->dev, "BDC_EPSTS5:0x%08x\n", temp);
> +
> + temp = bdc_readl(bdc->regs, BDC_EPSTS6(0));
> + dev_vdbg(bdc->dev, "BDC_EPSTS6:0x%08x\n", temp);
> +
> + temp = bdc_readl(bdc->regs, BDC_EPSTS7(0));
> + dev_vdbg(bdc->dev, "BDC_EPSTS7:0x%08x\n", temp);
> +}
> +
> +void bdc_dbg_uspc(struct bdc *bdc, u32 uspc)
> +{
> + u32 temp1, temp2;
> +
> + temp1 = bdc_readl(bdc->regs, BDC_USPPM2);
> + temp2 = bdc_readl(bdc->regs, BDC_USPPMS);
> + dev_dbg(bdc->dev,
> + "uspc=%08x usppm2=%08x usppms=%08x\n",
> + uspc, temp1, temp2);
> + switch (BDC_PST(uspc)) {
> + case 0:
> + dev_dbg(bdc->dev, "PST=%x Enabled\n", BDC_PST(uspc));
> + break;
> +
> + case 2:
> + dev_dbg(bdc->dev, "PST=%x L1 Suspend\n", BDC_PST(uspc));
> + break;
> +
> + case 3:
> + dev_dbg(bdc->dev, "PST=%x L2 Suspend\n", BDC_PST(uspc));
> + break;
> +
> + case 5:
> + dev_dbg(bdc->dev, "PST=%x Disabled\n", BDC_PST(uspc));
> + break;
> +
> + case 9:
> + dev_dbg(bdc->dev, "PST=%x USB20 Reset\n", BDC_PST(uspc));
> + break;
> +
> + case 0xFF:
> + dev_dbg(bdc->dev, "PST=%x Resume\n", BDC_PST(uspc));
> + break;
> + }
> +
> + switch (BDC_PSP(uspc)) {
> + case 0:
> + dev_dbg(bdc->dev, "PSP=%x Not connected\n", BDC_PSP(uspc));
> + break;
> +
> + case 1:
> + dev_dbg(bdc->dev, "PSP=%x connected FS\n", BDC_PSP(uspc));
> + break;
> +
> + case 2:
> + dev_dbg(bdc->dev, "PSP=%x connected LS\n", BDC_PSP(uspc));
> + break;
> +
> + case 3:
> + dev_dbg(bdc->dev, "PSP=%x connected HS\n", BDC_PSP(uspc));
> + break;
> +
> + case 4:
> + 

Re: [PATCH 2/2] usb: musb: musb_cppi41: revert to old timer poll intervals

[Felipe Balbi]

On Fri, Oct 31, 2014 at 10:39:11PM +0100, Sebastian Andrzej Siewior wrote:
> On 10/31/2014 10:36 PM, Sebastian Andrzej Siewior wrote:
> > diff --git a/drivers/usb/musb/musb_cppi41.c b/drivers/usb/musb/musb_cppi41.c
> > index d16b7561cce4..355f0dac9f0f 100644
> > --- a/drivers/usb/musb/musb_cppi41.c
> > +++ b/drivers/usb/musb/musb_cppi41.c
> > @@ -212,7 +212,7 @@ static enum hrtimer_restart 
> > cppi41_recheck_tx_req(struct hrtimer *timer)
> > if (!list_empty(&controller->early_tx_list)) {
> > ret = HRTIMER_RESTART;
> > hrtimer_forward_now(&controller->early_tx,
> > -   ktime_set(0, 20 * NSEC_PER_USEC));
> > +   ktime_set(0, 150 * NSEC_PER_USEC));
> > }
> >  
> > spin_unlock_irqrestore(&musb->lock, flags);
> > @@ -293,14 +293,11 @@ static void cppi41_dma_callback(void *private_data)
> > }
> > list_add_tail(&cppi41_channel->tx_check,
> > &controller->early_tx_list);
> > -   if (!hrtimer_is_queued(&controller->early_tx)) {
> > -   unsigned long usecs = cppi41_channel->total_len / 10;
> > -
> > +   if (!hrtimer_is_queued(&controller->early_tx))
> > hrtimer_start_range_ns(&controller->early_tx,
> > -   ktime_set(0, usecs * NSEC_PER_USEC),
> > +   ktime_set(0, 130 * NSEC_PER_USEC),
> > 20 * NSEC_PER_USEC,
> > HRTIMER_MODE_REL);
> > -   }
> > }
> >  out:
> > spin_unlock_irqrestore(&musb->lock, flags);
> > 
> 
> sending patches after 6pm on a Friday. This is the correct hunk :)

could you just resend these two aptches ?

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH 2/2] usb: musb: musb_cppi41: revert to old timer poll intervals

[Sebastian Andrzej Siewior]

On 11/05/2014 08:20 PM, Felipe Balbi wrote:
> 
> could you just resend these two aptches ?

I think about waiting for Daniel for some feedback. What about I resend
them next week if I don't hear from him until then?

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 2/2] usb: musb: musb_cppi41: revert to old timer poll intervals

[Felipe Balbi]

On Wed, Nov 05, 2014 at 08:21:41PM +0100, Sebastian Andrzej Siewior wrote:
> On 11/05/2014 08:20 PM, Felipe Balbi wrote:
> > 
> > could you just resend these two aptches ?
> 
> I think about waiting for Daniel for some feedback. What about I resend
> them next week if I don't hear from him until then?

sure thing :-)

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH 2/2] usb: musb: try a race-free wakeup

[Felipe Balbi]

On Mon, Oct 27, 2014 at 07:06:19PM +0100, Sebastian Andrzej Siewior wrote:
> Attaching a keyboard, using it as a wakeup via
> |for f in $(find /sys/devices/ocp.3/4740.usb -name wakeup)
> |do
> | echo enabled > $f
> |done
> 
> going into standby
> |  echo standby >  /sys/power/state
> 
> and now a wake up by a pressing a key.
> What happens is that the system wakes up but the USB device is dead. The
> USB stack tries to send a few control URBs but nothing comes back.
> Eventually it gaves up and the device remains dead:
> |[  632.559678] PM: Wakeup source USB1_PHY
> |[  632.581074] PM: noirq resume of devices complete after 21.261 msecs
> |[  632.607521] PM: early resume of devices complete after 10.360 msecs
> |[  632.616854] net eth2: initializing cpsw version 1.12 (0)
> |[  632.704126] net eth2: phy found : id is : 0x4dd074
> |[  636.704048] libphy: 4a101000.mdio:00 - Link is Up - 1000/Full
> |[  638.444620] usb 1-1: reset low-speed USB device number 2 using musb-hdrc
> |[  653.713435] usb 1-1: device descriptor read/64, error -110
> |[  669.093435] usb 1-1: device descriptor read/64, error -110
> |[  669.473424] usb 1-1: reset low-speed USB device number 2 using musb-hdrc
> |[  684.743436] usb 1-1: device descriptor read/64, error -110
> |[  690.065097] PM: resume of devices complete after 57450.744 msecs
> |[  690.076601] PM: Finishing wakeup.
> |[  690.076627] Restarting tasks ...
> 
> It seems that since we got woken up via MUSB_INTR_RESUME the
> musb_host_finish_resume() callback is executed before the
> resume-callbacks of the PHY and glue layer are invoked. If I delay it
> until the glue layer resumed then I don't see this problem.
> 
> I also move musb_host_resume_root_hub() into that callback since I don't
> see any reason in doing anything resume-link if there are still pieces
> not restored.
> 
> Signed-off-by: Sebastian Andrzej Siewior 

this one I had a little trouble applying, can you make sure my
testing/next looks as you intended ?

Thanks

ps: give it some 10 minutes for things to sync up.

-- 
balbi


signature.asc
Description: Digital signature

Re: xHCI bug

[Felipe Balbi]

Hi,

On Tue, Oct 14, 2014 at 04:34:00PM +0300, Mathias Nyman wrote:
> >>> Could you try with xhci debugging enabled? (will probably produce a
> >>> lot of output)
> >>>
> >>> echo -n 'module xhci_hcd =p' > /sys/kernel/debug/dynamic_debug/control
> >>
> >> I'll try, sure.
> > 
> > I used tracing otherwise the problem wouldn't show up. Attached you can
> > find output:
> > 
> > 0b7e070de7b65de9f70805f4639b3e58  xhci-timeout-testusb.txt.gz
> > 
> 
> Thanks, looks like we end up calling cleanup_halted_endpoint()  a lot.
> This will (try to) reset the endpoint and move to handle the next TD (URB).
> 
> This is called when we're processing contorl transfers and something out of 
> the ordinary happends (returned STALL, BABBLE, and some other reasons)
> 
> I need to dig a bit deeper to know what actually is going on. 

any news here ? It's been almost a month.

cheers

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH v1 2/3] usb: phy: convert gpio-vbus to gpio_desc

[Felipe Balbi]

Hi,

On Sun, Nov 02, 2014 at 07:11:49PM +0100, Robert Jarzmik wrote:
> In order to prepare device-tree conversion, port gpio_vbus to use
> gpio_desc.
> 
> Signed-off-by: Robert Jarzmik 

Can we just convert users of this to a phy-generic.c with a regulator ?

This is basically what gpio-vbus is doing, it's basically a regulator.

We can figure out how to maintain backwards compatibility with older DTS
too, no problem.

cheers

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH v1 3/3] usb: phy: add device-tree support for gpio-vbus

[Felipe Balbi]

On Sun, Nov 02, 2014 at 07:11:50PM +0100, Robert Jarzmik wrote:
> Add device-tree support for the generic gpio-vbus driver.
> 
> Signed-off-by: Robert Jarzmik 
> Cc: devicet...@vger.kernel.org
> ---

I would rather see you converting to a fixed-regulator with phy-generic.

-- 
balbi


signature.asc
Description: Digital signature

Re: Large disk drives

[Christoph Hellwig]

On Wed, Nov 05, 2014 at 11:34:11AM -0500, Alan Stern wrote:
> > Sorry, meant to.  In principle I'm OK with this as the lever for the
> > hack (largely because it means we don't need to do anything) but will
> > the distributions support it?
> 
> While I can't speak for the distributions, it's reasonable to assume 
> that if something becomes part of the upstream kernel then they will 
> include it.

Btw, we do have precedence for looking at partition tables from SCSI
code with scsi_partsize(), so the layering violation of looking at
EFI labels for disks sizes wouldn't be something entirely new even
if we did it in kernel space.
--
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: dwc3: ep0: remove unnecessary break after return

[Felipe Balbi]

On Tue, Nov 04, 2014 at 10:37:30AM +0900, Jingoo Han wrote:
> Fix the following checkpatch warning.
> 
>   WARNING: break is not useful after a goto or return
> 
> Signed-off-by: Jingoo Han 
> ---
>  drivers/usb/dwc3/ep0.c |2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/usb/dwc3/ep0.c b/drivers/usb/dwc3/ep0.c
> index 711b230..1d91c93 100644
> --- a/drivers/usb/dwc3/ep0.c
> +++ b/drivers/usb/dwc3/ep0.c
> @@ -441,7 +441,6 @@ static int dwc3_ep0_handle_feature(struct dwc3 *dwc,
>  
>   case USB_DEVICE_LTM_ENABLE:
>   return -EINVAL;
> - break;

heh, I remember we left that because either checkpatch or sparse used to
complain about the lack of it :-) I'll take this one already.

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH 2/8] usb: gadget: f_hid: check return value of device_create

[Felipe Balbi]

Hi,

On Fri, Oct 10, 2014 at 08:07:31PM +0200, Andrzej Pietrasiewicz wrote:
> device_create() might fail, so check its return value and react
> appropriately.
> 
> Signed-off-by: Andrzej Pietrasiewicz 

this patch doesn't apply, please rebase on my testing/next

-- 
balbi


signature.asc
Description: Digital signature

Re: [RFC v5] usb: phy: Hold wakeupsource when USB is enumerated in peripheral mode

[Felipe Balbi]

On Tue, Nov 04, 2014 at 03:30:54PM +0530, Kiran Kumar Raparthy wrote:
> From: Todd Poynor 
> 
> usb: phy: Hold wakeupsource when USB is enumerated in peripheral mode
> 
> Some systems require a mechanism to prevent system to enter into suspend
> state when USB is connected and enumerated in peripheral mode.
> 
> This patch provides an interface to hold a wakeupsource to prevent suspend.
> PHY drivers can use this interface when USB is connected and enumerated in
> peripheral mode.
> 
> A timed wakeupsource is temporarily held on USB disconnect events, to allow
> the rest of the system to react to the USB disconnection (dropping host
> sessions, updating charger status, etc.) prior to re-allowing suspend.
> 
> Cc: Kishon Vijay Abraham I 
> Cc: Felipe Balbi 
> Cc: Greg Kroah-Hartman 
> Cc: linux-ker...@vger.kernel.org
> Cc: linux-usb@vger.kernel.org
> Cc: Android Kernel Team 
> Cc: John Stultz 
> Cc: Sumit Semwal 
> Cc: Arve Hj�nnev�g 
> Cc: Benoit Goby 
> Signed-off-by: Todd Poynor 
> [kiran: Added context to commit message, squished build fixes
> from Benoit Goby and Arve Hj�nnev�g, changed wakelocks usage
> to wakeupsource, merged Todd's refactoring logic and simplified
> the structures and code and addressed community feedback]
> Signed-off-by: Kiran Raparthy 

you still didn't get this right. I asked that you introduce
usb_phy_set_event() as a separate patch, then make PHY drivers use it
and only on a third patch should you hold a wakeupsource.

-- 
balbi


signature.asc
Description: Digital signature

Re: [RFC PATCH] usb: gadget: composite: Provide list of registered functions

[Felipe Balbi]

On Mon, Oct 20, 2014 at 01:41:37PM +0200, Krzysztof Opasiak wrote:
> Driver which provides implementation of some USB functions
> registers its usb_function_driver structure in framework.
> Function drivers are identifed using registered name.
> 
> When gadget is composed user must know what names has been

"user *must" know", why ?

> registered. If function is compiled as a module this
> information can be found in modules.alias file. But if
> function is compiled-in, there is no way to discover what
> functions are available in currently running kernel.
> 
> Such situation is nothing new for linux kernel.
> Similar situation is with file systems. While mounting user
> can provide an fs type using -t option in mount. Those type
> names are registered by drivers. To make those names
> discoverable there is a proc fs attribute filesystems which
> exports the fils of currently registered file systems.
> 
> This patch adds proc fs attribute which exports the list
> of currently registered function drivers. This allows user
> to discover list of both compiled-in functions and
> from loaded kernel modules.

ugh, new procfs files. Thanks, but no thanks.

Also, I thought Sebastian had explained to you that Target framework
does not provide any list of any sorts.

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH v4] usb: gadget: f_fs: add "no_disconnect" mode

[Felipe Balbi]

On Mon, Nov 03, 2014 at 10:11:02AM -0600, Felipe Balbi wrote:
> Hi,
> 
> On Thu, Oct 09, 2014 at 03:21:51PM +0200, Robert Baldyga wrote:
> > Since we can compose gadgets from many functions, there is the problem
> > related to gadget breakage while FunctionFS daemon being closed. FFS
> > function is userspace code so there is no way to know when it will close
> > files (it doesn't matter what is the reason of this situation, it can
> > be daemon logic, program breakage, process kill or any other). So when
> > we have another function in gadget which, for example, sends some amount
> > of data, does some software update or implements some real-time 
> > functionality,
> > we may want to keep the gadget connected despite FFS function is no longer
> > functional.
> > 
> > We can't just remove one of functions from gadget since it has been
> > enumerated, so the only way to keep entire gadget working is to make
> > broken FFS function deactivated but still visible to host. For this
> > purpose this patch introduces "no_disconnect" mode. It can be enabled
> > by setting mount option "no_disconnect=1", and results with defering
> > function disconnect to the moment of reopen ep0 file or filesystem
> > unmount. After closing all endpoint files, FunctionFS is set to state
> > FFS_DEACTIVATED.
> > 
> > When ffs->state == FFS_DEACTIVATED:
> > - function is still bound and visible to host,
> > - setup requests are automatically stalled,
> > - transfers on other endpoints are refused,
> > - epfiles, except ep0, are deleted from the filesystem,
> > - opening ep0 causes the function to be closes, and then FunctionFS
> >   is ready for descriptors and string write,
> > - unmounting of the FunctionFS instance causes the function to be closed.
> > 
> > Signed-off-by: Robert Baldyga 
> 
> David, you have been messing with ffs lately, can I get a Tested-by from
> you on this patch ?

ping. David ? Any chance you can test this one out ?

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH v2 2/2] [usb] add support for ACPI identification to xhci-platform

[Mark Langsdorf]

On 11/05/2014 01:11 PM, Greg KH wrote:

On Wed, Nov 05, 2014 at 07:59:32AM -0600, Mark Langsdorf wrote:

  static struct platform_driver usb_xhci_driver = {
.probe  = xhci_plat_probe,
.remove = xhci_plat_remove,
@@ -294,6 +304,7 @@ static struct platform_driver usb_xhci_driver = {
.name = "xhci-hcd",
.pm = DEV_PM_OPS,
.of_match_table = of_match_ptr(usb_xhci_of_match),
+   .acpi_match_table = ACPI_PTR(usb_xhci_acpi_match),


Shouldn't the reworked driver core code handle this differently with the
ability to handle either OF or ACPI in the same driver?


I'm not sure I understand the question. With these changes, the driver
handles both ACPI and DTB/OF. It's the same style of code as used
in drivers/ata/plat-xgene.c, which also handles both ACPI and DTB/OF.
Why do you think this code isn't correct?


There is a new framework in the kernel that keeps a driver from having
to query both of and acpi to get the needed resources, it just does one
query and depending on the platform, everything "just works".  Shouldn't
that be used here as well?


Would you send me a pointer to a driver that's using this new
framework? I can't find any references to it and all the other
drivers that support ACPI and OF are doing it the way I'm doing
it.

--Mark Langsdorf

--
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 v1 2/3] usb: phy: convert gpio-vbus to gpio_desc

[Robert Jarzmik]

Felipe Balbi  writes:

> Hi,
>
> On Sun, Nov 02, 2014 at 07:11:49PM +0100, Robert Jarzmik wrote:
>> In order to prepare device-tree conversion, port gpio_vbus to use
>> gpio_desc.
>> 
>> Signed-off-by: Robert Jarzmik 
>
> Can we just convert users of this to a phy-generic.c with a regulator ?
Maybe, let's see what is missing.

> This is basically what gpio-vbus is doing, it's basically a regulator.
And a detector too. The basic thing is that it request an interrupt, and upon
this interrupt it schedules through a workqueue a usb_gadget_vbus_connect() and
the regulator stuff.

I don't see the interrupt+ usb_gadget_vbus_connect() stuff that in the
phy-generic. Am I missing something ?

Cheers.

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

[ANNOUNCE] Patch queue caught up

[Felipe Balbi]

Hi folks,

so I've now caught up with my linux-usb inbox. Most of you have already
received my automated email that patch has been applied. I still have
quite a few patches pending on testing/next (see below), but if your
patch isn't there and you haven't received any email from me asking you
to rebase or modify the patch in any way, it's time to resend.

Andrzej Pietrasiewicz (8):
  usb: gadget: Kconfig: enable separate compilation of uac1/uac2 functions
  usb: gadget: f_midi: enable use of the index parameter
  usb: gadget: f_midi: check kstrdup() return value
  usb: gadget: f_midi: convert to new function interface with backward 
compatibility
  usb: gadget: midi: convert to new interface of f_midi
  usb: gadget: f_midi: remove compatibility layer
  usb: gadget: f_midi: use usb_gstrings_attach
  usb: gadget: f_midi: add configfs support

Jingoo Han (2):
  usb: dwc3: exynos: remove non-DT support for Exynos Specific Glue layer
  usb: dwc3: ep0: remove unnecessary break after return

Kazuya Mizuguchi (1):
  usb: renesas_usbhs: gadget: fix NULL pointer dereference in ep_disable()

Sebastian Andrzej Siewior (2):
  usb: musb: core: check link status on resume
  usb: musb: try a race-free wakeup

Takeshi Kihara (1):
  usb: renesas_usbhs: gadget: fix the behavior of pullup

Yoshihiro Shimoda (2):
  usb: renesas_usbhs: fix the timing of dcp_control_transfer_done
  usb: renesas_usbhs: fix usbhs_pipe_clear() for DCP PIPE


-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH v1 2/3] usb: phy: convert gpio-vbus to gpio_desc

[Felipe Balbi]

On Wed, Nov 05, 2014 at 08:46:58PM +0100, Robert Jarzmik wrote:
> Felipe Balbi  writes:
> 
> > Hi,
> >
> > On Sun, Nov 02, 2014 at 07:11:49PM +0100, Robert Jarzmik wrote:
> >> In order to prepare device-tree conversion, port gpio_vbus to use
> >> gpio_desc.
> >> 
> >> Signed-off-by: Robert Jarzmik 
> >
> > Can we just convert users of this to a phy-generic.c with a regulator ?
> Maybe, let's see what is missing.
> 
> > This is basically what gpio-vbus is doing, it's basically a regulator.
> And a detector too. The basic thing is that it request an interrupt, and upon
> this interrupt it schedules through a workqueue a usb_gadget_vbus_connect() 
> and
> the regulator stuff.
> 
> I don't see the interrupt+ usb_gadget_vbus_connect() stuff that in the
> phy-generic. Am I missing something ?

Well, let's add that :-) Just make it optional. It's pointless to have
80% duplicated code just because of 20% missing in phy-generic :-)

Then we avoid adding gpio-vbus specific DT properties too.

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH] usb: phy: mxs: change test clock gating on connection/disconnection

[Vladimir Zapolskiy]

Hi Felipe,On 05.11.2014 21:00, Felipe Balbi wrote:
> On Wed, Nov 05, 2014 at 08:52:25PM +0200, Vladimir Zapolskiy wrote:
>> On some boards powered by iMX6Q rev1.0 I get non-working USB Host 1
>> (connected to a hub, no other devices are connected to this hub) and
>> repeating resets from the chipidea host driver (with ported pm support
>> from Freescale):
>>
>>   
>>   [   25.481714] usb 2-1: reset high-speed USB device number 2 using ci_hdrc
>>   [   27.491716] usb 2-1: reset high-speed USB device number 2 using ci_hdrc
>>   [   29.501721] usb 2-1: reset high-speed USB device number 2 using ci_hdrc
>>   
>>
>> As for me it seems that usb phy test clock gating may be done
>> incorrectly, on disconnection it is running, and on connection it is
>> gated, but may be it is the intention, unfortunately iMX6Q RM is not
>> a satisfactory source of information on the topic.
>>
>> Either complete disabling of loopback for the host or inverting test
>> clock gating solves my problem, this change proposes to invert test
>> clock gating setting.
>>
>> Signed-off-by: Vladimir Zapolskiy 
>> Cc: Peter Chen 
> 
> Make sure to Cc the maintainer of the framework, that'll help make sure
> your patch is not lost.
> 

thank you for reminder, frankly speaking I should tag the change as RFC,
please do not include it for merging before Peter's review, I planned to
let you know after it happens.

It is a fix for me, but I don't know, if it is a completely correct fix
or if it has drawbacks (none are known to me so far, moreover in vanilla
kernel it is a modification of dead code AFAIK).

With best wishes,
Vladimir
--
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 2/2] [usb] add support for ACPI identification to xhci-platform

[Greg KH]

On Wed, Nov 05, 2014 at 01:44:43PM -0600, Mark Langsdorf wrote:
> On 11/05/2014 01:11 PM, Greg KH wrote:
> >On Wed, Nov 05, 2014 at 07:59:32AM -0600, Mark Langsdorf wrote:
>   static struct platform_driver usb_xhci_driver = {
>   .probe  = xhci_plat_probe,
>   .remove = xhci_plat_remove,
> @@ -294,6 +304,7 @@ static struct platform_driver usb_xhci_driver = {
>   .name = "xhci-hcd",
>   .pm = DEV_PM_OPS,
>   .of_match_table = of_match_ptr(usb_xhci_of_match),
> + .acpi_match_table = ACPI_PTR(usb_xhci_acpi_match),
> >>>
> >>>Shouldn't the reworked driver core code handle this differently with the
> >>>ability to handle either OF or ACPI in the same driver?
> >>
> >>I'm not sure I understand the question. With these changes, the driver
> >>handles both ACPI and DTB/OF. It's the same style of code as used
> >>in drivers/ata/plat-xgene.c, which also handles both ACPI and DTB/OF.
> >>Why do you think this code isn't correct?
> >
> >There is a new framework in the kernel that keeps a driver from having
> >to query both of and acpi to get the needed resources, it just does one
> >query and depending on the platform, everything "just works".  Shouldn't
> >that be used here as well?
> 
> Would you send me a pointer to a driver that's using this new
> framework? I can't find any references to it and all the other
> drivers that support ACPI and OF are doing it the way I'm doing
> it.

See the email on lkml:
 Subject: [PATCH v6 00/12] Add ACPI _DSD and unified device properties support

for the latest patch series.

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: phy: mxs: change test clock gating on connection/disconnection

[Felipe Balbi]

On Wed, Nov 05, 2014 at 09:50:17PM +0200, Vladimir Zapolskiy wrote:
> Hi Felipe,On 05.11.2014 21:00, Felipe Balbi wrote:
> > On Wed, Nov 05, 2014 at 08:52:25PM +0200, Vladimir Zapolskiy wrote:
> >> On some boards powered by iMX6Q rev1.0 I get non-working USB Host 1
> >> (connected to a hub, no other devices are connected to this hub) and
> >> repeating resets from the chipidea host driver (with ported pm support
> >> from Freescale):
> >>
> >>   
> >>   [   25.481714] usb 2-1: reset high-speed USB device number 2 using 
> >> ci_hdrc
> >>   [   27.491716] usb 2-1: reset high-speed USB device number 2 using 
> >> ci_hdrc
> >>   [   29.501721] usb 2-1: reset high-speed USB device number 2 using 
> >> ci_hdrc
> >>   
> >>
> >> As for me it seems that usb phy test clock gating may be done
> >> incorrectly, on disconnection it is running, and on connection it is
> >> gated, but may be it is the intention, unfortunately iMX6Q RM is not
> >> a satisfactory source of information on the topic.
> >>
> >> Either complete disabling of loopback for the host or inverting test
> >> clock gating solves my problem, this change proposes to invert test
> >> clock gating setting.
> >>
> >> Signed-off-by: Vladimir Zapolskiy 
> >> Cc: Peter Chen 
> > 
> > Make sure to Cc the maintainer of the framework, that'll help make sure
> > your patch is not lost.
> 
> thank you for reminder, frankly speaking I should tag the change as RFC,

ok

> please do not include it for merging before Peter's review, I planned to
> let you know after it happens.
> 
> It is a fix for me, but I don't know, if it is a completely correct fix

right, I got that from commit log.

> or if it has drawbacks (none are known to me so far, moreover in vanilla
> kernel it is a modification of dead code AFAIK).

so this can't even be exercised in mainline ? Oh boy that's terrible.

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH v1 2/3] usb: phy: convert gpio-vbus to gpio_desc

[Robert Jarzmik]

Felipe Balbi  writes:

> On Wed, Nov 05, 2014 at 08:46:58PM +0100, Robert Jarzmik wrote:
> Well, let's add that :-) Just make it optional. It's pointless to have
> 80% duplicated code just because of 20% missing in phy-generic :-)
>
> Then we avoid adding gpio-vbus specific DT properties too.
OK, got it.

It will take me a couple of days. Philipp, am I missing something apart the
detection and connect stuff ? While I'm at making my board work with
phy-generic, let's thing ahead.

Felipe, that will mean at least this for phy-generic :
 - usb_phy_gen_create_phy() will be enhanced
   => struct usb_phy_generic_platform_data will get a :
 - int gpio_vbus field (or whatever name you wish)
 - int gpio_vbus_inverted (or maybe we could go directly for gpio desc)
 - int gpio_pullup field (I'm not sure here, maybe we should just drop that)
 - bool wakeup field (or another name)
   => device tree will get :
 - a vbus-gpio (or another name)
 - a pullup-gpio (or nothing if we drop)
 - there will be a request_irq() and a workqueue (mostly taken from gpio-vbus)
   => will call usb_gadget_vbus_connect()
   => will call usb_gadget_vbus_disconnect()

I'm writing all this just to be sure I have the good picture before I start
coding.

Cheers.

-- 
Robert
--
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 v1 2/3] usb: phy: convert gpio-vbus to gpio_desc

[Felipe Balbi]

Hi,

On Wed, Nov 05, 2014 at 09:02:04PM +0100, Robert Jarzmik wrote:
> Felipe Balbi  writes:
> 
> > On Wed, Nov 05, 2014 at 08:46:58PM +0100, Robert Jarzmik wrote:
> > Well, let's add that :-) Just make it optional. It's pointless to have
> > 80% duplicated code just because of 20% missing in phy-generic :-)
> >
> > Then we avoid adding gpio-vbus specific DT properties too.
> OK, got it.
> 
> It will take me a couple of days. Philipp, am I missing something apart the
> detection and connect stuff ? While I'm at making my board work with
> phy-generic, let's thing ahead.
> 
> Felipe, that will mean at least this for phy-generic :
>  - usb_phy_gen_create_phy() will be enhanced
>=> struct usb_phy_generic_platform_data will get a :
>  - int gpio_vbus field (or whatever name you wish)
>  - int gpio_vbus_inverted (or maybe we could go directly for gpio desc)

Actually, you might want to first convert phy-generic to gpio_desc and
avoid the inverted field.

>  - int gpio_pullup field (I'm not sure here, maybe we should just drop 
> that)
>  - bool wakeup field (or another name)

sonds good to me.

>=> device tree will get :
>  - a vbus-gpio (or another name)
>  - a pullup-gpio (or nothing if we drop)

fine by me, as long as their all optional and agreed with devicetree
folks. I think we still have time for v3.19 if you manage to finish this
before next week's end.

>  - there will be a request_irq() and a workqueue (mostly taken from gpio-vbus)
>=> will call usb_gadget_vbus_connect()
>=> will call usb_gadget_vbus_disconnect()

the workqueue should be unnecessary if you use
devm_request_threaded_irq() without a top half.

> I'm writing all this just to be sure I have the good picture before I
> start coding.

sounds good to me :-)

When it comes to DT, let's try to keep things as generic as possible so
we can just move phy-generic.c into drivers/phy/ later on without much
effort ;-)

I guess everything that you need already has existent bindings.

cheers

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH 1/1] x86: Surface Pro 3 Type Cover 3

[Jiri Kosina]

On Mon, 3 Nov 2014, Alan Wu wrote:

> Surface Pro 3 Type Cover that works with Ubuntu (and possibly Arch) from this 
> thread. Both trackpad and keyboard work after compiling my own kernel.
> http://ubuntuforums.org/showthread.php?t=2231207&page=2&s=44910e0c56047e4f93dfd9fea58121ef
> 
> Also includes Jarrad Whitaker's message which sources
> http://winaero.com/blog/how-to-install-linux-on-surface-pro-3/
> which he says is sourced from a Russian site
> 
> Signed-off-by: Alan Wu 

Adding Jarrad to CC so that he can test your patch as well.

Jarrad, if you could provide your Tested-by: to Alan's patch, I'd 
appreciate it (that would mean that we've reached the right super-position 
of both the patches you guys submitted).

I don't own the device, so I fully depend on what you guys submit and 
test.

Thanks.

> ---
>  drivers/hid/hid-core.c  | 6 ++
>  drivers/hid/hid-ids.h   | 1 +
>  drivers/hid/hid-microsoft.c | 2 ++
>  drivers/hid/usbhid/hid-quirks.c | 1 +
>  4 files changed, 10 insertions(+)
> 
> diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
> index 73bd9e2..e94afcc 100644
> --- a/drivers/hid/hid-core.c
> +++ b/drivers/hid/hid-core.c
> @@ -702,6 +702,11 @@ static void hid_scan_collection(struct hid_parser 
> *parser, unsigned type)
>   if (((parser->global.usage_page << 16) == HID_UP_SENSOR) &&
>   type == HID_COLLECTION_PHYSICAL)
>   hid->group = HID_GROUP_SENSOR_HUB;
> +
> + if (hid->vendor == USB_VENDOR_ID_MICROSOFT &&
> + hid->product == USB_DEVICE_ID_MS_TYPE_COVER_3 &&
> + hid->group == HID_GROUP_MULTITOUCH)
> + hid->group = HID_GROUP_GENERIC;
>  }
>  
>  static int hid_scan_main(struct hid_parser *parser, struct hid_item *item)
> @@ -1861,6 +1866,7 @@ static const struct hid_device_id 
> hid_have_special_driver[] = {
>   { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, 
> USB_DEVICE_ID_MS_DIGITAL_MEDIA_3K) },
>   { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, 
> USB_DEVICE_ID_WIRELESS_OPTICAL_DESKTOP_3_0) },
>   { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_OFFICE_KB) },
> + { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, 
> USB_DEVICE_ID_MS_TYPE_COVER_3) },
>   { HID_USB_DEVICE(USB_VENDOR_ID_MONTEREY, USB_DEVICE_ID_GENIUS_KB29E) },
>   { HID_USB_DEVICE(USB_VENDOR_ID_MSI, USB_DEVICE_ID_MSI_GT683R_LED_PANEL) 
> },
>   { HID_USB_DEVICE(USB_VENDOR_ID_NTRIG, USB_DEVICE_ID_NTRIG_TOUCH_SCREEN) 
> },
> diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
> index e23ab8b..15f32c2 100644
> --- a/drivers/hid/hid-ids.h
> +++ b/drivers/hid/hid-ids.h
> @@ -648,6 +648,7 @@
>  #define USB_DEVICE_ID_MS_SURFACE_PRO_2   0x0799
>  #define USB_DEVICE_ID_MS_TOUCH_COVER_2   0x07a7
>  #define USB_DEVICE_ID_MS_TYPE_COVER_20x07a9
> +#define USB_DEVICE_ID_MS_TYPE_COVER_30x07dc
>  
>  #define USB_VENDOR_ID_MOJO   0x8282
>  #define USB_DEVICE_ID_RETRO_ADAPTER  0x3201
> diff --git a/drivers/hid/hid-microsoft.c b/drivers/hid/hid-microsoft.c
> index 8ba17a9..cacda43 100644
> --- a/drivers/hid/hid-microsoft.c
> +++ b/drivers/hid/hid-microsoft.c
> @@ -274,6 +274,8 @@ static const struct hid_device_id ms_devices[] = {
>   .driver_data = MS_NOGET },
>   { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, 
> USB_DEVICE_ID_MS_COMFORT_MOUSE_4500),
>   .driver_data = MS_DUPLICATE_USAGES },
> + { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, 
> USB_DEVICE_ID_MS_TYPE_COVER_3),
> + .driver_data = MS_HIDINPUT },
>  
>   { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_MICROSOFT, 
> USB_DEVICE_ID_MS_PRESENTER_8K_BT),
>   .driver_data = MS_PRESENTER },
> diff --git a/drivers/hid/usbhid/hid-quirks.c b/drivers/hid/usbhid/hid-quirks.c
> index 5014bb5..cebfaf2 100644
> --- a/drivers/hid/usbhid/hid-quirks.c
> +++ b/drivers/hid/usbhid/hid-quirks.c
> @@ -77,6 +77,7 @@ static const struct hid_blacklist {
>   { USB_VENDOR_ID_FORMOSA, USB_DEVICE_ID_FORMOSA_IR_RECEIVER, 
> HID_QUIRK_NO_INIT_REPORTS },
>   { USB_VENDOR_ID_FREESCALE, USB_DEVICE_ID_FREESCALE_MX28, 
> HID_QUIRK_NOGET },
>   { USB_VENDOR_ID_MGE, USB_DEVICE_ID_MGE_UPS, HID_QUIRK_NOGET },
> + { USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_TYPE_COVER_3, 
> HID_QUIRK_NO_INIT_REPORTS },
>   { USB_VENDOR_ID_MSI, USB_DEVICE_ID_MSI_GT683R_LED_PANEL, 
> HID_QUIRK_NO_INIT_REPORTS },
>   { USB_VENDOR_ID_NEXIO, USB_DEVICE_ID_NEXIO_MULTITOUCH_PTI0750, 
> HID_QUIRK_NO_INIT_REPORTS },
>   { USB_VENDOR_ID_NOVATEK, USB_DEVICE_ID_NOVATEK_MOUSE, 
> HID_QUIRK_NO_INIT_REPORTS },
> -- 
> 2.1.0
> 

-- 
Jiri Kosina
SUSE Labs
--
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 2/2] [usb] add support for ACPI identification to xhci-platform

[Arnd Bergmann]

On Wednesday 05 November 2014 11:55:07 Greg KH wrote:
> On Wed, Nov 05, 2014 at 01:44:43PM -0600, Mark Langsdorf wrote:
> > On 11/05/2014 01:11 PM, Greg KH wrote:
> > >On Wed, Nov 05, 2014 at 07:59:32AM -0600, Mark Langsdorf wrote:
> >   static struct platform_driver usb_xhci_driver = {
> >   .probe  = xhci_plat_probe,
> >   .remove = xhci_plat_remove,
> > @@ -294,6 +304,7 @@ static struct platform_driver usb_xhci_driver = {
> >   .name = "xhci-hcd",
> >   .pm = DEV_PM_OPS,
> >   .of_match_table = of_match_ptr(usb_xhci_of_match),
> > + .acpi_match_table = ACPI_PTR(usb_xhci_acpi_match),
> > >>>
> > >>>Shouldn't the reworked driver core code handle this differently with the
> > >>>ability to handle either OF or ACPI in the same driver?
> > >>
> > >>I'm not sure I understand the question. With these changes, the driver
> > >>handles both ACPI and DTB/OF. It's the same style of code as used
> > >>in drivers/ata/plat-xgene.c, which also handles both ACPI and DTB/OF.
> > >>Why do you think this code isn't correct?
> > >
> > >There is a new framework in the kernel that keeps a driver from having
> > >to query both of and acpi to get the needed resources, it just does one
> > >query and depending on the platform, everything "just works".  Shouldn't
> > >that be used here as well?
> > 
> > Would you send me a pointer to a driver that's using this new
> > framework? I can't find any references to it and all the other
> > drivers that support ACPI and OF are doing it the way I'm doing
> > it.
> 
> See the email on lkml:
>  Subject: [PATCH v6 00/12] Add ACPI _DSD and unified device properties support
> 
> for the latest patch series.
> 

The _DSD approach is for devices that do not follow the ACPI specification
but do have a DT binding. Those will work without the .acpi_match_table
entry when the firmware uses the compatible value in the new properties.

In this case, the device does have an official ACPI ID "PNP0D10", so we should
use that for compatibility with other operating systems and with BIOS
versions that provide the standard IDs.

Arnd
--
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: Fw: USB3: unable to enumerate, device not accepting address

[Sarah Sharp]

I'm no longer the USB 3.0 driver maintainer.  Please work with Mathias
Nyman to fix this issue.

Sarah Sharp

On Fri, Oct 31, 2014 at 06:01:24PM +0300, parafin wrote:
> Hi,
> 
> it was suggested to me that since you are the author of offending
> commit I should forward this email to you. Also see this bug:
> https://bugzilla.kernel.org/show_bug.cgi?id=41752
> 
> Begin forwarded message:
> 
> Date: Thu, 30 Oct 2014 22:56:29 +0300
> From: parafin 
> To: 
> Subject: USB3: unable to enumerate, device not accepting address
> 
> 
> Hi,
> 
> I have 2 very similar USB3 devices that stopped working sometime after
> kernel version 3.3 - they fail to enumerate unless I reload xhci_hcd
> driver.
> 
> These are the devices:
> http://www.agestar.com/en/Products/Docking-Station/USB3-0/974-usb30esata-to-2535-sata-hdd-docking-station.html
> http://www.agestar.com/en/Products/Docking-Station/USB3-0/980-usb30esata-to-2535-sata-hdd-docking-station.html
> Basically it's some eSATA->USB3 bridge JMicron chip (I'm guessing it's
> the same one in both devices):
> Bus 009 Device 002: ID 152d:2509 JMicron Technology Corp. / JMicron USA 
> Technology Corp. JMS539 SuperSpeed SATA II 3.0G Bridge
> 
> This is USB controller I am testing them with:
> 01:00.0 USB controller: NEC Corporation uPD720200 USB 3.0 Host Controller 
> (rev 03)
> I even tried upgrading firmware, with no result
> 
> It appears in system as 2 buses (lsusb -t output):
> /:  Bus 09.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 5000M
> /:  Bus 08.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 480M
> One for SuperSpeed devices, another for slower.
> 
> So here's dmesg for when it fails:
> [  195.207408] hub 8-0:1.0: unable to enumerate USB device on port 1
> [  196.016556] usb 9-1: device not accepting address 2, error -22
> [  196.520572] hub 9-0:1.0: unable to enumerate USB device on port 1
> 
> And here how it should look (when it works):
> [   61.686218] hub 8-0:1.0: unable to enumerate USB device on port 1
> [   63.620211] usb 9-1: new SuperSpeed USB device number 2 using xhci_hcd
> [   63.636918] usb 9-1: New USB device found, idVendor=152d, idProduct=2509
> [   63.636932] usb 9-1: New USB device strings: Mfr=1, Product=11, 
> SerialNumber=3
> [   63.636942] usb 9-1: Product: Usb production
> [   63.636950] usb 9-1: Manufacturer: JMicron
> [   63.636956] usb 9-1: SerialNumber: 00A1234578EA
> [   63.638549] scsi5 : usb-storage 9-1:1.0
> [   64.926983] scsi 5:0:0:0: Direct-Access Jmicron  Corp. 
> PQ: 0 ANSI: 5
> [   64.927925] sd 5:0:0:0: Attached scsi generic sg6 type 0
> [   64.929912] sd 5:0:0:0: [sdg] Very big device. Trying to use READ 
> CAPACITY(16).
> [   64.930353] sd 5:0:0:0: [sdg] 5860533168 512-byte logical blocks: (3.00 
> TB/2.72 TiB)
> [   64.931031] sd 5:0:0:0: [sdg] Write Protect is off
> [   64.931042] sd 5:0:0:0: [sdg] Mode Sense: 28 00 00 00
> [   64.931764] sd 5:0:0:0: [sdg] No Caching mode page present
> [   64.931772] sd 5:0:0:0: [sdg] Assuming drive cache: write through
> [   64.932486] sd 5:0:0:0: [sdg] Very big device. Trying to use READ 
> CAPACITY(16).
> [   64.933992] sd 5:0:0:0: [sdg] No Caching mode page present
> [   64.933997] sd 5:0:0:0: [sdg] Assuming drive cache: write through
> [   64.989015]  sdg: sdg1 sdg2 sdg3 sdg4
> [   64.992112] sd 5:0:0:0: [sdg] Very big device. Trying to use READ 
> CAPACITY(16).
> [   64.993885] sd 5:0:0:0: [sdg] No Caching mode page present
> [   64.993898] sd 5:0:0:0: [sdg] Assuming drive cache: write through
> [   64.993909] sd 5:0:0:0: [sdg] Attached SCSI disk
> First line doesn't always appear, might depend on kernel version, I'm
> not sure.
> 
> I managed to bisect this down to this commit:
> beabe20445c60322719d8f58e9eb9dd4660c1b3e
> (it's from 3.4 branch, included in 3.4.36 release, upstream commit id
> from commit message seems to be invalid, at least it's missing one
> character).
> I backported reverse of this commit to 3.17.1 (I can't run 3.4 kernel
> due to different issues) and it helps with this issue. Patch attached
> in case it is helpful, sorry though for whitespace mess, I used nano:)
> 
> I doubt that just reverting is acceptable solution for mainstream
> kernel, so I'm willing to test some other patches (on top of 3.17.1
> would be best) or provide additional information so that this issue
> could be fixed in next releases.

> --- drivers/usb/core/hub.c.orig   2014-10-30 21:44:50.000746074 +0300
> +++ drivers/usb/core/hub.c2014-10-30 22:12:01.561256025 +0300
> @@ -2664,56 +2664,95 @@
>   if ((portstatus & USB_PORT_STAT_RESET))
>   return -EBUSY;
>  
> - if (hub_port_warm_reset_required(hub, port1, portstatus))
> - return -ENOTCONN;
> -
> - /* Device went away? */
> - if (!(portstatus & USB_PORT_STAT_CONNECTION))
> - return -ENOTCONN;
> -
> - /* bomb out completely if the connection bounced.  A USB 3.0
> -  * connection may bounce if multiple warm resets were issued,
> -  * but the de

Re: btusb_intr_complete returns -EPIPE

[Alan Stern]

On Wed, 5 Nov 2014, Naveen Kumar Parna wrote:

> > Can you do it again, but this time keep the SOF packets?
> >
> > You don't have to post the entire analyzer log.  Just extract 3 or 4 ms
> > from the middle, where it shows the SSPLITS but no CSPLITS for the
> > interrupt endpoints, and post only that portion.
> >
> 
> I tried again, I keep getting STALL's but this time I see CSPLITS  for
> the interrupt end points.

Any idea why you see the CSPLITs now but didn't see them before?

> usbmon log:
> 8800b2cce6c0 1558099725 C Ii:1:055:1 -32:1 0
> 8800b2cce6c0 1558099740 S Ii:1:055:1 -115:1 16 <
> 8800b2cce6c0 1558435684 C Ii:1:055:1 -32:1 0
> 8800b2cce6c0 1558435700 S Ii:1:055:1 -115:1 16 <
> 8800b2cce6c0 1558447773 C Ii:1:055:1 -32:1 0
> 8800b2cce6c0 1558447790 S Ii:1:055:1 -115:1 16 <
> 8800b2cce6c0 1562003759 C Ii:1:055:1 -32:1 0
> 8800b2cce6c0 1562003777 S Ii:1:055:1 -115:1 16 <
> 8800b2cce6c0 1835091798 C Ii:1:055:1 -32:1 0
> 8800b2cce6c0 1835091818 S Ii:1:055:1 -115:1 16 <
> 8800b2cce6c0 2360295770 C Ii:1:055:1 -32:1 0
> 8800b2cce6c0 2360295785 S Ii:1:055:1 -115:1 16 <
> 8800b2cce6c0 2360307814 C Ii:1:055:1 -32:1 0
> 8800b2cce6c0 2360307827 S Ii:1:055:1 -115:1 16 <
> 8800b2cce6c0 2746327776 C Ii:1:055:1 -32:1 0
> 8800b2cce6c0 2746327796 S Ii:1:055:1 -115:1 16 <
> 8800b2cce6c0 2750455832 C Ii:1:055:1 -32:1 0
> 8800b2cce6c0 2750455844 S Ii:1:055:1 -115:1 16 <
> 8800b2cce6c0 2751751777 C Ii:1:055:1 -32:1 0
> 8800b2cce6c0 2751751788 S Ii:1:055:1 -115:1 16 <
> 8800b2cce6c0 2752707689 C Ii:1:055:1 -32:1 0
> 8800b2cce6c0 2752707707 S Ii:1:055:1 -115:1 16 <
> 8800b2cce6c0 2762271761 C Ii:1:055:1 -32:1 0
> 8800b2cce6c0 2762271776 S Ii:1:055:1 -115:1 16 <
> 8800b2cce6c0 2977131824 C Ii:1:055:1 -32:1 0
> 8800b2cce6c0 2977131835 S Ii:1:055:1 -115:1 16 <
> 8800b2cce6c0 3602679779 C Ii:1:055:1 -32:1 0
> 8800b2cce6c0 3602679798 S Ii:1:055:1 -115:1 16 <
> 8800b2cce6c0 456023739 C Ii:1:055:1 -32:1 0
> 8800b2cce6c0 456023758 S Ii:1:055:1 -115:1 16 <
> 8800b2cce6c0 456231695 C Ii:1:055:1 -32:1 0
> 8800b2cce6c0 456231712 S Ii:1:055:1 -115:1 16 <

Notice that the problem seems to occur very rarely.  There are often
many seconds between the -32 status values, whereas the interrupt
endpoint gets polled 1000 times per second.

Inconsistent behavior like that tends to indicate a hardware problem.  
Software would behave the same way every time, unless there was some 
sort of race.

> Dev 55 usb log:
> 
> SSPLIT IN transaction 55 1 HS No data 0.000 238 117
> Start of Frame (2) HS 228.0 -> 228.1 0.000 340 583
> CSPLIT IN transaction 55 1 NAK HS No data 0.000 489 817
> Start of Frame (6) HS 228.2 -> 228.7 0.000 590 617
> SSPLIT IN transaction 55 1 HS No data 0.001 238 117
> Start of Frame (2) HS 229.0 -> 229.1 0.001 340 733
> CSPLIT IN transaction 55 1 NAK HS No data 0.001 489 850
> Start of Frame (6) HS 229.2 -> 229.7 0.001 590 767
> SSPLIT IN transaction 55 1 HS No data 0.002 238 933
> Start of Frame (2) HS 230.0 -> 230.1 0.002 340 867
> CSPLIT IN transaction 55 1 NAK HS No data 0.002 489 933
> Start of Frame (6) HS 230.2 -> 230.7 0.002 590 900
> SSPLIT IN transaction 55 1 HS No data 0.003 238 967
> Start of Frame (2) HS 231.0 -> 231.1 0.003 341 017
> CSPLIT IN transaction 55 1 NAK HS No data 0.003 489 900
> Start of Frame (6) HS 231.2 -> 231.7 0.003 591 050
> SSPLIT IN transaction 55 1 HS No data 0.004 238 950
> Start of Frame (2) HS 232.0 -> 232.1 0.004 341 150
> CSPLIT IN transaction 55 1 NAK HS No data 0.004 489 950
> Start of Frame (6) HS 232.2 -> 232.7 0.004 591 183
> SSPLIT IN transaction 55 1 HS No data 0.005 239 000
> Start of Frame (2) HS 233.0 -> 233.1 0.005 341 283
> CSPLIT IN transaction 55 1 NAK HS No data 0.005 490 000

This looks right.  The SSPLIT packets get sent in microframe 7 of each
frame and the CSPLIT packets get sent in microframe 1.  (The full-speed
bus transaction occurs during microframe 0, in between.)

Also, a NAK response to a CSPLIT is correct when the device has no data 
to send.  It wouldn't cause you to get a STALL indication.

I need to see the portion of the analyzer log that corresponds to one 
of those -32 events in the usbmon log.  It ought to show something 
different, something that would cause the -32 status.

> External USB-2 hub (Dev 51) log:
> Start of Frame (570) HS 258.7 -> 330.0 0.000 090 550
> IN transaction 51 1 NAK HS No data 0.071 226 050
> Start of Frame (2,048) HS 299.0 -> 554.7 0.071 350 517
> IN transaction 51 1 NAK HS No data 0.327 261 817
> Start of Frame (2,048) HS 555.0 -> 810.7 0.327 386 250
> IN transaction 51 1 NAK HS No data 0.583 297 550
> Start of Frame (2,048) HS 811.0 -> 1,066.7 0.583 422 000
> IN transaction 51 1 NAK HS No data 0.839 333 283
> Start of Frame (2,048) HS 1,067.0 -> 1,322.7 0.839 457 733
> IN transaction 51 1 NAK HS No data 1.095 369 050
> Start of Frame (2,048) HS 1,323.0 -> 1,578.7 1.095 493 483
> IN transaction 51 1 N

Re: your mail

[Sebastian Andrzej Siewior]

On 11/04/2014 08:10 PM, Alan Stern wrote:
> Now, maybe something went wrong somewhere.  Perhaps the kernel thought 
> that after the system resume, the root hub was still in runtime 
> suspend.  If that's true, we need to find out why and fix it.

This is what I have so far (I have no idea what is correct / wrong I
just document what I figured out):
- good case no wakeup active.
  - usb_suspend() => choose_wakeup()
   "if (udev->state == USB_STATE_SUSPENDED && w !=
udev->do_remote_wakeup)"
w is 0 and do_remote_wakeup is 1. This means pm_runtime_resume() is
invoked.
  - device status goes RPM_SUSPENDED => RPM_RESUMING => RPM_ACTIVE
  - after we are in usb_suspend_both() and udev->state is 7
(USB_STATE_CONFIGURED), hub_suspend() is beeing invoked.
The status urb is dequeued, RPM of usb1 is still RPM_ACTIVE

- in the bad case (wakeup active)
  - usb_suspend => choose_wakeup()
- in the check above we do nothing because w and …do_remote_wakeup
  is 1
- usb_suspend_both() does nothing because udev->state is 8
  (USB_STATE_SUSPENDED) so we leave. RPM of both devices (hub and
   usb1 is RPM_SUSPENDED)

--- now get back out of suspend ---
- usb_resume() is invoked with different RPM status.
- hub_activate() is invoked. The status URB is enqueued again, RPM
  remains unchanged.
- and we are done
- we get a HUB event, khubd is kicked.
- the hub invokes usb_autopm_get_interface() on the interface which is
  suspended. The hub device is suspended and has
  dev->power.no_callbacks set. Now:
  - in the "good" case it sees that the parent (usb1) is still
RPM_ACTIVE so it sets the status of the status of hub to RPM_ACTIVE
and leaves without doing anything.
  - in the bad case the ave RPM still set to RPM_SUSPENDED so we call
resume for usb1 again which leads to the second status URB enqueue

So that is the history. I *think* that we shouldn't to hub_suspend() +
hub_resume() without changing the RPM status (the choose_wakeup()
difference). This might also fix the RPM status for usb1 which is in
RPM_SUSPENDED while it should be active (shouldn't it?) since it has
remote_wakeup active.

> 
> Alan Stern
> 
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 v3 2/3] usb: xhci: This reworks ff8cbf250b448aac35589f6075082c3fcad8a8fe

[Alan Stern]

On Wed, 5 Nov 2014, Lu Baolu wrote:

> xhci: clear root port wake on bits if controller isn't allowed to do wakeup
> 
> When system is being suspended, if host device is not allowed to do wakeup,
> xhci_suspend() needs to clear all root port wake on bits. Otherwise, some
> platforms may generate spurious wakeup, even if PCI PME# is disabled.
> 
> Signed-off-by: Lu Baolu 
> Suggested-by: Alan Stern 

This looks pretty good now.

> +static void xhci_disable_port_wake_on_bits(struct xhci_hcd *xhci)
> +{
> + int port_index;
> + __le32 __iomem **port_array;
> + unsigned long flags;
> + u32 t1, t2;
> +
> + spin_lock_irqsave(&xhci->lock, flags);
> +
> + /* disble usb3 ports Wake bits*/
> + port_index = xhci->num_usb3_ports;
> + port_array = xhci->usb3_ports;
> + while (port_index--) {
> + t1 = readl(port_array[port_index]);
> + t2 = xhci_port_state_to_neutral(t1);
> + t2 &= ~PORT_WAKE_BITS;
> + t1 = xhci_port_state_to_neutral(t1);
> + if (t1 != t2)
> + writel(t2, port_array[port_index]);

Why not just do:

t1 = readl(port_array[port_index]);
t1 = xhci_port_state_to_neutral(t1);
t2 = t1 & ~PORT_WAKE_BITS;
if (t1 != t2) ...

Apart from that minor point,

Acked-by: Alan Stern 

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 v2 2/2] [usb] add support for ACPI identification to xhci-platform

[Greg KH]

On Wed, Nov 05, 2014 at 09:41:23PM +0100, Arnd Bergmann wrote:
> On Wednesday 05 November 2014 11:55:07 Greg KH wrote:
> > On Wed, Nov 05, 2014 at 01:44:43PM -0600, Mark Langsdorf wrote:
> > > On 11/05/2014 01:11 PM, Greg KH wrote:
> > > >On Wed, Nov 05, 2014 at 07:59:32AM -0600, Mark Langsdorf wrote:
> > >   static struct platform_driver usb_xhci_driver = {
> > >   .probe  = xhci_plat_probe,
> > >   .remove = xhci_plat_remove,
> > > @@ -294,6 +304,7 @@ static struct platform_driver usb_xhci_driver = {
> > >   .name = "xhci-hcd",
> > >   .pm = DEV_PM_OPS,
> > >   .of_match_table = of_match_ptr(usb_xhci_of_match),
> > > + .acpi_match_table = ACPI_PTR(usb_xhci_acpi_match),
> > > >>>
> > > >>>Shouldn't the reworked driver core code handle this differently with 
> > > >>>the
> > > >>>ability to handle either OF or ACPI in the same driver?
> > > >>
> > > >>I'm not sure I understand the question. With these changes, the driver
> > > >>handles both ACPI and DTB/OF. It's the same style of code as used
> > > >>in drivers/ata/plat-xgene.c, which also handles both ACPI and DTB/OF.
> > > >>Why do you think this code isn't correct?
> > > >
> > > >There is a new framework in the kernel that keeps a driver from having
> > > >to query both of and acpi to get the needed resources, it just does one
> > > >query and depending on the platform, everything "just works".  Shouldn't
> > > >that be used here as well?
> > > 
> > > Would you send me a pointer to a driver that's using this new
> > > framework? I can't find any references to it and all the other
> > > drivers that support ACPI and OF are doing it the way I'm doing
> > > it.
> > 
> > See the email on lkml:
> >  Subject: [PATCH v6 00/12] Add ACPI _DSD and unified device properties 
> > support
> > 
> > for the latest patch series.
> > 
> 
> The _DSD approach is for devices that do not follow the ACPI specification
> but do have a DT binding. Those will work without the .acpi_match_table
> entry when the firmware uses the compatible value in the new properties.
> 
> In this case, the device does have an official ACPI ID "PNP0D10", so we should
> use that for compatibility with other operating systems and with BIOS
> versions that provide the standard IDs.

Ah, ok, nevermind then, sorry for the noise, I wasn't aware of this.

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: [PATCHv2] usb: gadget: composite: Provide a list of available functions

[Sebastian Andrzej Siewior]

* Krzysztof Opasiak | 2014-10-27 11:53:09 [+0100]:

>Main difference is that each loaded fabric module provides its own
>directory (/sys/kernel/config/target/$FABRIC_MOD/). This means that
>each loaded or built-in module has there it own directory.

So I assumed they don't do and I don't recall this by the time I want
through the code. But if they really do this (as in code of current git)
why not stick to the same way instead of hacking a procfs/sysfs
interface?

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 v2] usb: phy: remove file names from heading comments

[Felipe Balbi]

On Thu, Nov 06, 2014 at 01:18:44AM +0300, Sergei Shtylyov wrote:
> Hello.
> 
> On 10/10/2014 12:02 AM, Sergei Shtylyov wrote:
> 
> >File names in the heading comments fell out of favor long ago, and these 
> >weren't
> >even changed when the drivers were moved from drivers/usb/otg/, so remove 
> >them
> >at last...
> 
> >Signed-off-by: Sergei Shtylyov 
> >
> >---
> >Changes in version 2:
> >- fixed typos in the summary.
> 
> >This patch is atop of the 'next' branch of Felipe's 'usb.git' repo.
> 
> >  drivers/usb/phy/phy-ab8500-usb.c |2 --
> >  drivers/usb/phy/phy-generic.c|2 --
> >  2 files changed, 4 deletions(-)
> >
> >Index: usb/drivers/usb/phy/phy-ab8500-usb.c
> >===
> >--- usb.orig/drivers/usb/phy/phy-ab8500-usb.c
> >+++ usb/drivers/usb/phy/phy-ab8500-usb.c
> >@@ -1,6 +1,4 @@
> >  /*
> >- * drivers/usb/otg/ab8500_usb.c
> >- *
> >   * USB transceiver driver for AB8500 family chips
> >   *
> >   * Copyright (C) 2010-2013 ST-Ericsson AB
> >Index: usb/drivers/usb/phy/phy-generic.c
> >===
> >--- usb.orig/drivers/usb/phy/phy-generic.c
> >+++ usb/drivers/usb/phy/phy-generic.c
> >@@ -1,6 +1,4 @@
> >  /*
> >- * drivers/usb/otg/nop-usb-xceiv.c
> >- *
> >   * NOP USB transceiver for all USB transceiver which are either built-in
> >   * into USB IP or which are mostly autonomous.
> >   *
> 
>Felipe, looks like you haven't applied this one. Should I repost or
> perhaps it's a trivial tree meterial?

Thanks for letting me know, it's now on my testing/next, should show up
on k.org in the next few minutes.

cheers

-- 
balbi


signature.asc
Description: Digital signature

Re: USB3: unable to enumerate, device not accepting address

[parafin]

Update to this issue:
OS X has problems recognizing these devices as well - 10.9 managed to
enumerate it after several attempts, but after upgrade to the latest
release (10.10 Yosemite) OS X only sees these USB devices if they were
connected before booting up (so same as Linux). Windows, of course, has
no such problems (tested with Win 7 Pro).
While googling about possible solutions for OS X, I found out that it
is possible to upgrade firmware of JMS539 chipset inside these docking
stations (of course the utility is Windows-only):
http://www.station-drivers.com/index.php/downloads/Drivers/Jmicron/JMS539-Sata-USB-3.0-Controller/
Firmware version all previous tests were done with is 255.00.06.00.14,
I've updated it to the latest 255.31.3.41.22 and it solved enumeration
problem on both Linux and OS X!
I left old firmware on one of the devices so I still can test some
patches. I'm not sure though if it is worth fixing now, in the light of
what I wrote above, I would still say yes, because: first of all it
won't be obvious that firmware upgrade is required (or that it's at
all possible) for anyone else encountering this issue; secondly Windows
is required to run firmware upgrade and not everyone has readily access
to it; thirdly there might be other chipsets out there with same quirks
and no available fixes; and finally it worked before, so it is a
regression even though most likely it is the device who's doing the
wrong thing.

On Wed, 5 Nov 2014 12:50:36 -0800
Sarah Sharp  wrote:

> I'm no longer the USB 3.0 driver maintainer.  Please work with Mathias
> Nyman to fix this issue.
> 
> Sarah Sharp
> 
> On Fri, Oct 31, 2014 at 06:01:24PM +0300, parafin wrote:
> > Hi,
> > 
> > it was suggested to me that since you are the author of offending
> > commit I should forward this email to you. Also see this bug:
> > https://bugzilla.kernel.org/show_bug.cgi?id=41752
> > 
> > Begin forwarded message:
> > 
> > Date: Thu, 30 Oct 2014 22:56:29 +0300
> > From: parafin 
> > To: 
> > Subject: USB3: unable to enumerate, device not accepting address
> > 
> > 
> > Hi,
> > 
> > I have 2 very similar USB3 devices that stopped working sometime after
> > kernel version 3.3 - they fail to enumerate unless I reload xhci_hcd
> > driver.
> > 
> > These are the devices:
> > http://www.agestar.com/en/Products/Docking-Station/USB3-0/974-usb30esata-to-2535-sata-hdd-docking-station.html
> > http://www.agestar.com/en/Products/Docking-Station/USB3-0/980-usb30esata-to-2535-sata-hdd-docking-station.html
> > Basically it's some eSATA->USB3 bridge JMicron chip (I'm guessing it's
> > the same one in both devices):
> > Bus 009 Device 002: ID 152d:2509 JMicron Technology Corp. / JMicron USA 
> > Technology Corp. JMS539 SuperSpeed SATA II 3.0G Bridge
> > 
> > This is USB controller I am testing them with:
> > 01:00.0 USB controller: NEC Corporation uPD720200 USB 3.0 Host Controller 
> > (rev 03)
> > I even tried upgrading firmware, with no result
> > 
> > It appears in system as 2 buses (lsusb -t output):
> > /:  Bus 09.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 5000M
> > /:  Bus 08.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 480M
> > One for SuperSpeed devices, another for slower.
> > 
> > So here's dmesg for when it fails:
> > [  195.207408] hub 8-0:1.0: unable to enumerate USB device on port 1
> > [  196.016556] usb 9-1: device not accepting address 2, error -22
> > [  196.520572] hub 9-0:1.0: unable to enumerate USB device on port 1
> > 
> > And here how it should look (when it works):
> > [   61.686218] hub 8-0:1.0: unable to enumerate USB device on port 1
> > [   63.620211] usb 9-1: new SuperSpeed USB device number 2 using xhci_hcd
> > [   63.636918] usb 9-1: New USB device found, idVendor=152d, idProduct=2509
> > [   63.636932] usb 9-1: New USB device strings: Mfr=1, Product=11, 
> > SerialNumber=3
> > [   63.636942] usb 9-1: Product: Usb production
> > [   63.636950] usb 9-1: Manufacturer: JMicron
> > [   63.636956] usb 9-1: SerialNumber: 00A1234578EA
> > [   63.638549] scsi5 : usb-storage 9-1:1.0
> > [   64.926983] scsi 5:0:0:0: Direct-Access Jmicron  Corp.
> >  PQ: 0 ANSI: 5
> > [   64.927925] sd 5:0:0:0: Attached scsi generic sg6 type 0
> > [   64.929912] sd 5:0:0:0: [sdg] Very big device. Trying to use READ 
> > CAPACITY(16).
> > [   64.930353] sd 5:0:0:0: [sdg] 5860533168 512-byte logical blocks: (3.00 
> > TB/2.72 TiB)
> > [   64.931031] sd 5:0:0:0: [sdg] Write Protect is off
> > [   64.931042] sd 5:0:0:0: [sdg] Mode Sense: 28 00 00 00
> > [   64.931764] sd 5:0:0:0: [sdg] No Caching mode page present
> > [   64.931772] sd 5:0:0:0: [sdg] Assuming drive cache: write through
> > [   64.932486] sd 5:0:0:0: [sdg] Very big device. Trying to use READ 
> > CAPACITY(16).
> > [   64.933992] sd 5:0:0:0: [sdg] No Caching mode page present
> > [   64.933997] sd 5:0:0:0: [sdg] Assuming drive cache: write through
> > [   64.989015]  sdg: sdg1 sdg2 sdg3 sdg4
> > [   64.992112] sd 5:0:0:0: [sdg] Very big device. Trying t

Re: [PATCHv2] usb: gadget: composite: Provide a list of available functions

[Felipe Balbi]

On Wed, Nov 05, 2014 at 11:18:12PM +0100, Sebastian Andrzej Siewior wrote:
> * Krzysztof Opasiak | 2014-10-27 11:53:09 [+0100]:
> 
> >Main difference is that each loaded fabric module provides its own
> >directory (/sys/kernel/config/target/$FABRIC_MOD/). This means that
> >each loaded or built-in module has there it own directory.
> 
> So I assumed they don't do and I don't recall this by the time I want
> through the code. But if they really do this (as in code of current git)
> why not stick to the same way instead of hacking a procfs/sysfs
> interface?

The problem is that we would now have userland ABI problems, unless we
have a way of providing backwards compatibility. We would also need
patches to libusbg making sure it works with both old and new ways.

Without that, we can't move forward :-s

-- 
balbi


signature.asc
Description: Digital signature

Re: [RFC PATCH] usb: gadget: composite: Provide list of registered functions

[Sebastian Andrzej Siewior]

* Felipe Balbi | 2014-11-05 13:42:56 [-0600]:

>Also, I thought Sebastian had explained to you that Target framework
>does not provide any list of any sorts.
There is older thread
"[PATCHv2] usb: gadget: composite: Provide a list of available"

where I explained it again. I think we can continue the conversation
there since this the old approach / patch reposted.

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 v2] usb: phy: remove file names from heading comments

[Sergei Shtylyov]

Hello.

On 10/10/2014 12:02 AM, Sergei Shtylyov wrote:


File names in the heading comments fell out of favor long ago, and these weren't
even changed when the drivers were moved from drivers/usb/otg/, so remove them
at last...



Signed-off-by: Sergei Shtylyov 

---
Changes in version 2:
- fixed typos in the summary.



This patch is atop of the 'next' branch of Felipe's 'usb.git' repo.



  drivers/usb/phy/phy-ab8500-usb.c |2 --
  drivers/usb/phy/phy-generic.c|2 --
  2 files changed, 4 deletions(-)

Index: usb/drivers/usb/phy/phy-ab8500-usb.c
===
--- usb.orig/drivers/usb/phy/phy-ab8500-usb.c
+++ usb/drivers/usb/phy/phy-ab8500-usb.c
@@ -1,6 +1,4 @@
  /*
- * drivers/usb/otg/ab8500_usb.c
- *
   * USB transceiver driver for AB8500 family chips
   *
   * Copyright (C) 2010-2013 ST-Ericsson AB
Index: usb/drivers/usb/phy/phy-generic.c
===
--- usb.orig/drivers/usb/phy/phy-generic.c
+++ usb/drivers/usb/phy/phy-generic.c
@@ -1,6 +1,4 @@
  /*
- * drivers/usb/otg/nop-usb-xceiv.c
- *
   * NOP USB transceiver for all USB transceiver which are either built-in
   * into USB IP or which are mostly autonomous.
   *


   Felipe, looks like you haven't applied this one. Should I repost or 
perhaps it's a trivial tree meterial?


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: [RFC PATCH] usb: gadget: composite: Provide list of registered functions

[Felipe Balbi]

Hi,

On Wed, Nov 05, 2014 at 11:23:24PM +0100, Sebastian Andrzej Siewior wrote:
> * Felipe Balbi | 2014-11-05 13:42:56 [-0600]:
> 
> >Also, I thought Sebastian had explained to you that Target framework
> >does not provide any list of any sorts.
> There is older thread
>   "[PATCHv2] usb: gadget: composite: Provide a list of available"
> 
> where I explained it again. I think we can continue the conversation
> there since this the old approach / patch reposted.

Right, I don't want to see any more "provide list of registered
functions" patches until all details are hashed out. It's
counter-productive to push for something which, clearly, hasn't been
accepted by at least one very active member of the community (that's you
Sebastian :-)

cheers.

-- 
balbi


signature.asc
Description: Digital signature

Re: Large disk drives

[Dale R. Worley]

> From: Alan Stern 

> I posted a patch to allow the user to override the reported capacity:
> 
>   http://marc.info/?l=linux-scsi&m=140993840113445&w=2

I see the patch, and I feel confident I could install it if I needed
to.  What command do I execute to "write to the capacity_override
attribute", before I do "blockdev --rereadpt /dev/sdX"?

Dale
--
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: USB3: unable to enumerate, device not accepting address

[parafin]

Well, not everything as good as it seemed - upgrading JMS539 firmware
completely disabled eSATA port on docking station :( So that's another
reason to solve this issue inside Linux kernel.

On Thu, 6 Nov 2014 01:26:07 +0300
parafin  wrote:

> Update to this issue:
> OS X has problems recognizing these devices as well - 10.9 managed to
> enumerate it after several attempts, but after upgrade to the latest
> release (10.10 Yosemite) OS X only sees these USB devices if they were
> connected before booting up (so same as Linux). Windows, of course, has
> no such problems (tested with Win 7 Pro).
> While googling about possible solutions for OS X, I found out that it
> is possible to upgrade firmware of JMS539 chipset inside these docking
> stations (of course the utility is Windows-only):
> http://www.station-drivers.com/index.php/downloads/Drivers/Jmicron/JMS539-Sata-USB-3.0-Controller/
> Firmware version all previous tests were done with is 255.00.06.00.14,
> I've updated it to the latest 255.31.3.41.22 and it solved enumeration
> problem on both Linux and OS X!
> I left old firmware on one of the devices so I still can test some
> patches. I'm not sure though if it is worth fixing now, in the light of
> what I wrote above, I would still say yes, because: first of all it
> won't be obvious that firmware upgrade is required (or that it's at
> all possible) for anyone else encountering this issue; secondly Windows
> is required to run firmware upgrade and not everyone has readily access
> to it; thirdly there might be other chipsets out there with same quirks
> and no available fixes; and finally it worked before, so it is a
> regression even though most likely it is the device who's doing the
> wrong thing.
> 
> On Wed, 5 Nov 2014 12:50:36 -0800
> Sarah Sharp  wrote:
> 
> > I'm no longer the USB 3.0 driver maintainer.  Please work with Mathias
> > Nyman to fix this issue.
> > 
> > Sarah Sharp
> > 
> > On Fri, Oct 31, 2014 at 06:01:24PM +0300, parafin wrote:
> > > Hi,
> > > 
> > > it was suggested to me that since you are the author of offending
> > > commit I should forward this email to you. Also see this bug:
> > > https://bugzilla.kernel.org/show_bug.cgi?id=41752
> > > 
> > > Begin forwarded message:
> > > 
> > > Date: Thu, 30 Oct 2014 22:56:29 +0300
> > > From: parafin 
> > > To: 
> > > Subject: USB3: unable to enumerate, device not accepting address
> > > 
> > > 
> > > Hi,
> > > 
> > > I have 2 very similar USB3 devices that stopped working sometime after
> > > kernel version 3.3 - they fail to enumerate unless I reload xhci_hcd
> > > driver.
> > > 
> > > These are the devices:
> > > http://www.agestar.com/en/Products/Docking-Station/USB3-0/974-usb30esata-to-2535-sata-hdd-docking-station.html
> > > http://www.agestar.com/en/Products/Docking-Station/USB3-0/980-usb30esata-to-2535-sata-hdd-docking-station.html
> > > Basically it's some eSATA->USB3 bridge JMicron chip (I'm guessing it's
> > > the same one in both devices):
> > > Bus 009 Device 002: ID 152d:2509 JMicron Technology Corp. / JMicron USA 
> > > Technology Corp. JMS539 SuperSpeed SATA II 3.0G Bridge
> > > 
> > > This is USB controller I am testing them with:
> > > 01:00.0 USB controller: NEC Corporation uPD720200 USB 3.0 Host Controller 
> > > (rev 03)
> > > I even tried upgrading firmware, with no result
> > > 
> > > It appears in system as 2 buses (lsusb -t output):
> > > /:  Bus 09.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 5000M
> > > /:  Bus 08.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 480M
> > > One for SuperSpeed devices, another for slower.
> > > 
> > > So here's dmesg for when it fails:
> > > [  195.207408] hub 8-0:1.0: unable to enumerate USB device on port 1
> > > [  196.016556] usb 9-1: device not accepting address 2, error -22
> > > [  196.520572] hub 9-0:1.0: unable to enumerate USB device on port 1
> > > 
> > > And here how it should look (when it works):
> > > [   61.686218] hub 8-0:1.0: unable to enumerate USB device on port 1
> > > [   63.620211] usb 9-1: new SuperSpeed USB device number 2 using xhci_hcd
> > > [   63.636918] usb 9-1: New USB device found, idVendor=152d, 
> > > idProduct=2509
> > > [   63.636932] usb 9-1: New USB device strings: Mfr=1, Product=11, 
> > > SerialNumber=3
> > > [   63.636942] usb 9-1: Product: Usb production
> > > [   63.636950] usb 9-1: Manufacturer: JMicron
> > > [   63.636956] usb 9-1: SerialNumber: 00A1234578EA
> > > [   63.638549] scsi5 : usb-storage 9-1:1.0
> > > [   64.926983] scsi 5:0:0:0: Direct-Access Jmicron  Corp.
> > >  PQ: 0 ANSI: 5
> > > [   64.927925] sd 5:0:0:0: Attached scsi generic sg6 type 0
> > > [   64.929912] sd 5:0:0:0: [sdg] Very big device. Trying to use READ 
> > > CAPACITY(16).
> > > [   64.930353] sd 5:0:0:0: [sdg] 5860533168 512-byte logical blocks: 
> > > (3.00 TB/2.72 TiB)
> > > [   64.931031] sd 5:0:0:0: [sdg] Write Protect is off
> > > [   64.931042] sd 5:0:0:0: [sdg] Mode Sense: 28 00 00 00
> > > [   64.931764] sd 5:0:0:0: [sdg] 

USB controller: VIA Technologies, Inc. VL80x xHCI USB 3.0 Controller (rev 03)

[Stefan Gies]

Off-board Controller do not initialize external hard disk properly. Motherboard 
MSI FM2-A75MA-P33 with AMD A10-6800k.

Error: If a external hard disk is attached a during a running system the drive 
is mounted without errors. If the hard disk is attached as an additional drive, 
e.g. /data, and the PC and hdd was off, the drive will not be found. The system 
waits for a long time to find the drive, but without success. Only switching 
off the hdd and the PC, the drive will bw found on the second or third boot.
I checked the configuration with Windows 7 HomePremium and there are no errors. 
The drive will be found at every time I boot the system.

I attached the hdd to the onboard USB3.0 controller and the hdd will be found 
at everytime I boot the system.

Attached is my hardwarelist.



hardinfo_report.tar.gz
Description: application/gzip

Re: [PATCH 1/2] [usb] make xhci platform driver use 64 bit or 32 bit DMA

[Arnd Bergmann]

On Tuesday 04 November 2014 10:33:18 Al Stone wrote:
> On 11/03/2014 10:14 AM, Arnd Bergmann wrote:
> > On Monday 03 November 2014 09:15:51 Mark Salter wrote:
> >> On Thu, 2014-10-30 at 22:05 +0100, Arnd Bergmann wrote:
> >>> Note that the discussions about merging ACPI support on ARM64
> >>> are based on the assumption that we'd only ever support SBSA-like
> >>> platforms, not something like X-Gene that looks more like an
> >>> embedded SoC. Your XHCI patches still obviously make sense for
> >>> other platforms, so that's not a show-stopper.
> >>
> >> But for some misconfiguration, the arm64 kernels in fedora arm
> >> koji would boot using ACPI on Mustang, the Foundation model,
> >> and AMD Seattle platforms. All very much a work in progress,
> >> but the tree from which the fedora patches are taken is the
> >> devel branch of:
> >>
> >>   git.fedorahosted.org/git/kernel-arm64.git
> >>
> >> The configuration will be fixed this week and then you can
> >> just grab an arm64 fedora kernel and boot with acpi=force.
> 
> Please note that I work directly with Mark Salter and that I have
> personally handed out this particular URL many times at either Linaro
> Connect and/or to individuals directly.  It is not now nor has it ever
> been secret, at any time.

What I meant was that the patches haven't been circulated on the
usual mailing lists when this is exactly the work that needs to
be discussed before the base patches that are being sent out can
be merged.

I was also under the impression (based on the URL) that this
was the official Fedora kernel for ARM64. Apparently that is not
true, and I probably overreacted based on that. I certainly don't
want to see this kind of patches being put into Fedora before
there is basic consensus about whether or not they can eventaully
get merged upstream.

> > It's not as bad as I had feared, but it still does a lot of
> > the things that in previous discussions were said that ACPI
> > would avoid doing, and that were used as arguments against
> > just using DT on all arm64 servers:
> > 
> > - The use of the device properties API that was introduced for
> >   Intel's embedded devices for on-chip components directly
> >   contradicts the "standardized firmware interfaces" argument
> >   that certain people keep making. This certainly explains how
> >   you plan to use the networking side, but I suspect it's not
> >   what the ACPI proponents were looking for, or what the base
> >   patch set is being advertised as.
> 
> I do not understand this statement at all.  One of the things
> that was added to the ACPI 5.1 specification was the _DSD method
> -- Device Specific Properties -- specifically so that device
> properties could be standardized.  The API mentioned relies on the
> existence of _DSD for ACPI.  Further, there are people from Linaro
> (who happen to work in the kernel and ACPI), the Linux community,
> as well as from Intel, ARM and even Microsoft working together to
> figure out ways to standardize the device properties being used in
> the ACPI Spec Working Group (ASWG) of the UEFI Forum; several of us
> are of course paying attention to, participating in, and incorporating
> the discussions on this kernel list and others.
> 
> So what is not being standardized?  From where I sit, as part of ASWG,
> Linaro, Red Hat, and some-time contributor to the Linux kernel, this
> whole device properties API was driven by the desire to have a
> standardized firmware interface.  It even seems to be going a step
> further and trying to standardize how the kernel interacts with any
> firmware.

The point of _DSD is to allow a more generalized format for describing
devices that are not standardized. We need this for (x86) embedded
systems, because the standardization process is not scalable for
coming up with an official description for every single device, so
_DSD with the DT properties extension is a great workaround.

In particular, this allows us to have a common stable binding for
devices between ACPI and DT, which is also great because we already
have DT bindings for hundreds or thousands of peripherals that are
used on embedded systems. Grant has also started conversations with
a number of parties about creating an official standard for the
subsystem specific DT bindings that are not part of IEEE1275 or
ePAPR, but the individual device bindings are not standardized in
the sense of having a standardization body oversee the addition
of every single device property in the form that the UEFI forum
oversees the things that go into the ACPI specification.

We still need to discuss about what this means for ARM servers, and
when we raised this topic during the kernel summit, it was far from
clear whether we would apply the _DSD device properties to ARM64
servers or not. I think there are good reasons on both sides of
the argument.

> > - Using custom drivers for hardware that is required by SBSA
> >   (ahci, pci, ...) means you are contradicting the 
> >   Documentation/arm64/ar

[PATCH] drivers/usb/musb/Kconfig: Use menu instead of choice for Platform Glue Layer

[Ben Hutchings]

A Kconfig choice only allows one 'y' selection or multiple 'm'
selections, but it is valid to have any combination of 'y' and 'm'
selections here (dependent on USB_MUSB_HDRC).  Use a menu instead.

Reported-by: Arnaud Patard 
Signed-off-by: Ben Hutchings 
---
 drivers/usb/musb/Kconfig | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig
index 06cc5d6..655e5d1 100644
--- a/drivers/usb/musb/Kconfig
+++ b/drivers/usb/musb/Kconfig
@@ -58,8 +58,7 @@ config USB_MUSB_DUAL_ROLE
 
 endchoice
 
-choice
-   prompt "Platform Glue Layer"
+menu "Platform Glue Layer"
 
 config USB_MUSB_DAVINCI
tristate "DaVinci"
@@ -101,7 +100,7 @@ config USB_MUSB_JZ4740
depends on USB_MUSB_GADGET
depends on USB_OTG_BLACKLIST_HUB
 
-endchoice
+endmenu
 
 config USB_MUSB_AM335X_CHILD
tristate

-- 
Ben Hutchings
Beware of programmers who carry screwdrivers. - Leonard Brandwein


signature.asc
Description: This is a digitally signed message part

[PATCH v2] usb: dwc2: add bus suspend/resume for dwc2

[Kever Yang]

Hcd controller needs bus_suspend/resume, dwc2 controller make
root hub generate suspend/resume signal with hprt0 register
when work in host mode.
After the root hub enter suspend, we can make controller enter
low power state with PCGCTL register.

We also update the lx_state for hsotg state.

This patch has tested on rk3288 with suspend/resume.

Signed-off-by: Kever Yang 
---

Changes in v2:
- update commit message
- make dwc2 suspend/resume sourcecode work

 drivers/usb/dwc2/hcd.c | 78 +++---
 1 file changed, 67 insertions(+), 11 deletions(-)

diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
index 0a0e6f0..01a415b 100644
--- a/drivers/usb/dwc2/hcd.c
+++ b/drivers/usb/dwc2/hcd.c
@@ -1471,6 +1471,30 @@ static void dwc2_port_suspend(struct dwc2_hsotg *hsotg, 
u16 windex)
}
 }
 
+static void dwc2_port_resume(struct dwc2_hsotg *hsotg)
+{
+   u32 hprt0;
+
+   /* After clear the Stop PHY clock bit, we should wait for a moment
+* for PLL work stable with clock output.
+*/
+   writel(0, hsotg->regs + PCGCTL);
+   usleep_range(2000, 4000);
+
+   hprt0 = dwc2_read_hprt0(hsotg);
+   hprt0 |= HPRT0_RES;
+   writel(hprt0, hsotg->regs + HPRT0);
+   hprt0 &= ~HPRT0_SUSP;
+   /* according to USB2.0 Spec 7.1.7.7, the host must send the resume
+* signal for at least 20ms
+*/
+   usleep_range(2, 25000);
+
+   hprt0 &= ~HPRT0_RES;
+   writel(hprt0, hsotg->regs + HPRT0);
+   hsotg->lx_state = DWC2_L0;
+}
+
 /* Handles hub class-specific requests */
 static int dwc2_hcd_hub_control(struct dwc2_hsotg *hsotg, u16 typereq,
u16 wvalue, u16 windex, char *buf, u16 wlength)
@@ -1516,17 +1540,7 @@ static int dwc2_hcd_hub_control(struct dwc2_hsotg 
*hsotg, u16 typereq,
case USB_PORT_FEAT_SUSPEND:
dev_dbg(hsotg->dev,
"ClearPortFeature USB_PORT_FEAT_SUSPEND\n");
-   writel(0, hsotg->regs + PCGCTL);
-   usleep_range(2, 4);
-
-   hprt0 = dwc2_read_hprt0(hsotg);
-   hprt0 |= HPRT0_RES;
-   writel(hprt0, hsotg->regs + HPRT0);
-   hprt0 &= ~HPRT0_SUSP;
-   usleep_range(10, 15);
-
-   hprt0 &= ~HPRT0_RES;
-   writel(hprt0, hsotg->regs + HPRT0);
+   dwc2_port_resume(hsotg);
break;
 
case USB_PORT_FEAT_POWER:
@@ -2299,6 +2313,44 @@ static void _dwc2_hcd_stop(struct usb_hcd *hcd)
usleep_range(1000, 3000);
 }
 
+static int _dwc2_hcd_suspend(struct usb_hcd *hcd)
+{
+   struct dwc2_hsotg *hsotg = dwc2_hcd_to_hsotg(hcd);
+   u32 hprt0;
+
+   if (!((hsotg->op_state == OTG_STATE_B_HOST) ||
+   (hsotg->op_state == OTG_STATE_A_HOST)))
+   return 0;
+
+   if (hsotg->lx_state != DWC2_L0)
+   return 0;
+
+   hprt0 = dwc2_read_hprt0(hsotg);
+   if (hprt0 & HPRT0_CONNSTS)
+   dwc2_port_suspend(hsotg, 1);
+
+   return 0;
+}
+
+static int _dwc2_hcd_resume(struct usb_hcd *hcd)
+{
+   struct dwc2_hsotg *hsotg = dwc2_hcd_to_hsotg(hcd);
+   u32 hprt0;
+
+   if (!((hsotg->op_state == OTG_STATE_B_HOST) ||
+   (hsotg->op_state == OTG_STATE_A_HOST)))
+   return 0;
+
+   if (hsotg->lx_state != DWC2_L2)
+   return 0;
+
+   hprt0 = dwc2_read_hprt0(hsotg);
+   if ((hprt0 & HPRT0_CONNSTS) && (hprt0 & HPRT0_SUSP))
+   dwc2_port_resume(hsotg);
+
+   return 0;
+}
+
 /* Returns the current frame number */
 static int _dwc2_hcd_get_frame_number(struct usb_hcd *hcd)
 {
@@ -2669,6 +2721,10 @@ static struct hc_driver dwc2_hc_driver = {
.hub_status_data = _dwc2_hcd_hub_status_data,
.hub_control = _dwc2_hcd_hub_control,
.clear_tt_buffer_complete = _dwc2_hcd_clear_tt_buffer_complete,
+#ifdef CONFIG_PM
+   .bus_suspend = _dwc2_hcd_suspend,
+   .bus_resume = _dwc2_hcd_resume,
+#endif
 };
 
 /*
-- 
1.9.1

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

Re: [PATCH v3 2/3] usb: xhci: This reworks ff8cbf250b448aac35589f6075082c3fcad8a8fe

[Lu, Baolu]

On 11/6/2014 5:24 AM, Alan Stern wrote:

On Wed, 5 Nov 2014, Lu Baolu wrote:


xhci: clear root port wake on bits if controller isn't allowed to do wakeup

When system is being suspended, if host device is not allowed to do wakeup,
xhci_suspend() needs to clear all root port wake on bits. Otherwise, some
platforms may generate spurious wakeup, even if PCI PME# is disabled.

Signed-off-by: Lu Baolu 
Suggested-by: Alan Stern 

This looks pretty good now.


+static void xhci_disable_port_wake_on_bits(struct xhci_hcd *xhci)
+{
+   int port_index;
+   __le32 __iomem **port_array;
+   unsigned long flags;
+   u32 t1, t2;
+
+   spin_lock_irqsave(&xhci->lock, flags);
+
+   /* disble usb3 ports Wake bits*/
+   port_index = xhci->num_usb3_ports;
+   port_array = xhci->usb3_ports;
+   while (port_index--) {
+   t1 = readl(port_array[port_index]);
+   t2 = xhci_port_state_to_neutral(t1);
+   t2 &= ~PORT_WAKE_BITS;
+   t1 = xhci_port_state_to_neutral(t1);
+   if (t1 != t2)
+   writel(t2, port_array[port_index]);

Why not just do:

t1 = readl(port_array[port_index]);
t1 = xhci_port_state_to_neutral(t1);
t2 = t1 & ~PORT_WAKE_BITS;
if (t1 != t2) ...
Right, this looks better. I will test and resend the patches with this 
change.




Apart from that minor point,

Acked-by: Alan Stern 

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


--
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 controller: VIA Technologies, Inc. VL80x xHCI USB 3.0 Controller (rev 03)

[Greg KH]

On Thu, Nov 06, 2014 at 01:01:06AM +0100, Stefan Gies wrote:
> Off-board Controller do not initialize external hard disk properly.
> Motherboard MSI FM2-A75MA-P33 with AMD A10-6800k.
> 
> Error: If a external hard disk is attached a during a running system
> the drive is mounted without errors. If the hard disk is attached as
> an additional drive, e.g. /data, and the PC and hdd was off, the drive
> will not be found. The system waits for a long time to find the drive,
> but without success. Only switching off the hdd and the PC, the drive
> will bw found on the second or third boot.  I checked the
> configuration with Windows 7 HomePremium and there are no errors. The
> drive will be found at every time I boot the system.

Any hints as to what the kernel log messages are when there are
problems?  Your html attachment didn't show any :)

And can you try the 3.17 kernel release?  Lots of xhci fixes have gone
into there since 3.16 was released.

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] drivers/usb/musb/Kconfig: Use menu instead of choice for Platform Glue Layer

[Felipe Balbi]

On Thu, Nov 06, 2014 at 01:25:39AM +, Ben Hutchings wrote:
> A Kconfig choice only allows one 'y' selection or multiple 'm'
> selections, but it is valid to have any combination of 'y' and 'm'
> selections here (dependent on USB_MUSB_HDRC).  Use a menu instead.
> 
> Reported-by: Arnaud Patard 
> Signed-off-by: Ben Hutchings 

not yet. A kernel with TUSB6010=y and any other glue layer =y won't
work, IIRC it won't even build. How have you tested this patch ?

ps: are you carrying a screwdriver ? Should I be concerned? :-p

-- 
balbi


signature.asc
Description: Digital signature

[PATCH v4 0/3] Rework "xhci: clear root port wake on bits if controller isn't wake-up capable"

[Lu Baolu]

This serie of patch reworks commit ff8cbf250b448aac35589f6075082c3fcad8a8fe.
This has been discussed at http://www.spinics.net/lists/linux-usb/msg114986.html
It also includes a patch to fix a comment in drivers/usb/host/xhci.h.

Changes in v4:
- Refine xhci_disable_port_wake_on_bits().
- Add "Acked-by: Alan Stern"

Changes in v3:
- Need to consider run-time suspend as well.
- Change "wake-up capable" to "allowed to do wakeup"
in both comments and patch description.
- Add "Suggested-by: Alan Stern"

Changes in v2:
- Should not be a quirk.
- Should be applied to all xhci controllers.

Lu Baolu (3):
  usb: xhci: Revert "xhci: clear root port wake on bits if controller
isn't wake-up capable"
  usb: xhci: This reworks ff8cbf250b448aac35589f6075082c3fcad8a8fe
  usb: xhci: fix comment for PORT_DEV_REMOVE

 drivers/usb/host/xhci-hub.c  |  5 +
 drivers/usb/host/xhci-pci.c  |  2 +-
 drivers/usb/host/xhci-plat.c | 10 +-
 drivers/usb/host/xhci.c  | 42 +-
 drivers/usb/host/xhci.h  |  4 ++--
 5 files changed, 54 insertions(+), 9 deletions(-)

-- 
1.9.1

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

[PATCH v4 2/3] usb: xhci: This reworks ff8cbf250b448aac35589f6075082c3fcad8a8fe

[Lu Baolu]

xhci: clear root port wake on bits if controller isn't allowed to do wakeup

When system is being suspended, if host device is not allowed to do wakeup,
xhci_suspend() needs to clear all root port wake on bits. Otherwise, some
platforms may generate spurious wakeup, even if PCI PME# is disabled.

Signed-off-by: Lu Baolu 
Suggested-by: Alan Stern 
Acked-by: Alan Stern 
---
 drivers/usb/host/xhci-pci.c  |  2 +-
 drivers/usb/host/xhci-plat.c | 10 +-
 drivers/usb/host/xhci.c  | 42 +-
 drivers/usb/host/xhci.h  |  2 +-
 4 files changed, 52 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
index 280dde9..d3fa3c2 100644
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -291,7 +291,7 @@ static int xhci_pci_suspend(struct usb_hcd *hcd, bool 
do_wakeup)
if (xhci->quirks & XHCI_COMP_MODE_QUIRK)
pdev->no_d3cold = true;
 
-   return xhci_suspend(xhci);
+   return xhci_suspend(xhci, do_wakeup);
 }
 
 static int xhci_pci_resume(struct usb_hcd *hcd, bool hibernated)
diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 3d78b0c..646300c 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -204,7 +204,15 @@ static int xhci_plat_suspend(struct device *dev)
struct usb_hcd  *hcd = dev_get_drvdata(dev);
struct xhci_hcd *xhci = hcd_to_xhci(hcd);
 
-   return xhci_suspend(xhci);
+   /*
+* xhci_suspend() needs `do_wakeup` to know whether host is allowed
+* to do wakeup during suspend. Since xhci_plat_suspend is currently
+* only designed for system suspend, device_may_wakeup() is enough
+* to dertermine whether host is allowed to do wakeup. Need to
+* reconsider this when xhci_plat_suspend enlarges its scope, e.g.,
+* also applies to runtime suspend.
+*/
+   return xhci_suspend(xhci, device_may_wakeup(dev));
 }
 
 static int xhci_plat_resume(struct device *dev)
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 2a5d45b..b832841 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -35,6 +35,8 @@
 #define DRIVER_AUTHOR "Sarah Sharp"
 #define DRIVER_DESC "'eXtensible' Host Controller (xHC) Driver"
 
+#definePORT_WAKE_BITS  (PORT_WKOC_E | PORT_WKDISC_E | PORT_WKCONN_E)
+
 /* Some 0.95 hardware can't handle the chain bit on a Link TRB being cleared */
 static int link_quirk;
 module_param(link_quirk, int, S_IRUGO | S_IWUSR);
@@ -851,13 +853,47 @@ static void xhci_clear_command_ring(struct xhci_hcd *xhci)
xhci_set_cmd_ring_deq(xhci);
 }
 
+static void xhci_disable_port_wake_on_bits(struct xhci_hcd *xhci)
+{
+   int port_index;
+   __le32 __iomem **port_array;
+   unsigned long flags;
+   u32 t1, t2;
+
+   spin_lock_irqsave(&xhci->lock, flags);
+
+   /* disble usb3 ports Wake bits*/
+   port_index = xhci->num_usb3_ports;
+   port_array = xhci->usb3_ports;
+   while (port_index--) {
+   t1 = readl(port_array[port_index]);
+   t1 = xhci_port_state_to_neutral(t1);
+   t2 = t1 & ~PORT_WAKE_BITS;
+   if (t1 != t2)
+   writel(t2, port_array[port_index]);
+   }
+
+   /* disble usb2 ports Wake bits*/
+   port_index = xhci->num_usb2_ports;
+   port_array = xhci->usb2_ports;
+   while (port_index--) {
+   t1 = readl(port_array[port_index]);
+   t1 = xhci_port_state_to_neutral(t1);
+   t2 = t1 & ~PORT_WAKE_BITS;
+   if (t1 != t2)
+   writel(t2, port_array[port_index]);
+   }
+
+   spin_unlock_irqrestore(&xhci->lock, flags);
+}
+
 /*
  * Stop HC (not bus-specific)
  *
  * This is called when the machine transition into S3/S4 mode.
  *
  */
-int xhci_suspend(struct xhci_hcd *xhci)
+int xhci_suspend(struct xhci_hcd *xhci, bool do_wakeup)
 {
int rc = 0;
unsigned intdelay = XHCI_MAX_HALT_USEC;
@@ -868,6 +904,10 @@ int xhci_suspend(struct xhci_hcd *xhci)
xhci->shared_hcd->state != HC_STATE_SUSPENDED)
return -EINVAL;
 
+   /* Clear root port wake on bits if wakeup not allowed. */
+   if (!do_wakeup)
+   xhci_disable_port_wake_on_bits(xhci);
+
/* Don't poll the roothubs on bus suspend. */
xhci_dbg(xhci, "%s: stopping port polling.\n", __func__);
clear_bit(HCD_FLAG_POLL_RH, &hcd->flags);
diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index df76d64..d745715 100644
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -1746,7 +1746,7 @@ int xhci_gen_setup(struct usb_hcd *hcd, xhci_get_quirks_t 
get_quirks);
 void xhci_init_driver(struct hc_driver *drv, int (*setup_fn)(struct usb_hcd 
*));
 
 #ifdef CONFIG_PM
-int xhci_suspend(struct xhci_hcd *xhci);
+int xhci_suspend(s

[PATCH v4 3/3] usb: xhci: fix comment for PORT_DEV_REMOVE

[Lu Baolu]

According to xHCI specification, PORT_DEV_REMOVE(bit 30) in PORTSC
true means "Device is non-removable".

Signed-off-by: Lu Baolu 
Reported-by: Juro Bystricky 
---
 drivers/usb/host/xhci.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index d745715..ab36bbb 100644
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -358,7 +358,7 @@ struct xhci_op_regs {
 /* wake on over-current (enable) */
 #define PORT_WKOC_E(1 << 27)
 /* bits 28:29 reserved */
-/* true: device is removable - for USB 3.0 roothub emulation */
+/* true: device is non-removable - for USB 3.0 roothub emulation */
 #define PORT_DEV_REMOVE(1 << 30)
 /* Initiate a warm port reset - complete when PORT_WRC is '1' */
 #define PORT_WR(1 << 31)
-- 
1.9.1

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

[PATCH v4 1/3] usb: xhci: Revert "xhci: clear root port wake on bits if controller isn't wake-up capable"

[Lu Baolu]

This reverts commit ff8cbf250b448aac35589f6075082c3fcad8a8fe.

Commit ff8cbf250b448aac35589f6075082c3fcad8a8fe triggers the bug logged at

https://bugzilla.kernel.org/show_bug.cgi?id=85701

Signed-off-by: Lu Baolu 
Reported-by: Dmitry Nezhevenko 
---
 drivers/usb/host/xhci-hub.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
index 696160d..388cfd8 100644
--- a/drivers/usb/host/xhci-hub.c
+++ b/drivers/usb/host/xhci-hub.c
@@ -22,7 +22,6 @@
 
 
 #include 
-#include 
 #include 
 
 #include "xhci.h"
@@ -1149,9 +1148,7 @@ int xhci_bus_suspend(struct usb_hcd *hcd)
 * including the USB 3.0 roothub, but only if CONFIG_PM_RUNTIME
 * is enabled, so also enable remote wake here.
 */
-   if (hcd->self.root_hub->do_remote_wakeup
-   && device_may_wakeup(hcd->self.controller)) {
-
+   if (hcd->self.root_hub->do_remote_wakeup) {
if (t1 & PORT_CONNECT) {
t2 |= PORT_WKOC_E | PORT_WKDISC_E;
t2 &= ~PORT_WKCONN_E;
-- 
1.9.1

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

Re: [PATCH] drivers/usb/musb/Kconfig: Use menu instead of choice for Platform Glue Layer

[Ben Hutchings]

On Wed, 2014-11-05 at 20:56 -0600, Felipe Balbi wrote:
> On Thu, Nov 06, 2014 at 01:25:39AM +, Ben Hutchings wrote:
> > A Kconfig choice only allows one 'y' selection or multiple 'm'
> > selections, but it is valid to have any combination of 'y' and 'm'
> > selections here (dependent on USB_MUSB_HDRC).  Use a menu instead.
> > 
> > Reported-by: Arnaud Patard 
> > Signed-off-by: Ben Hutchings 
> 
> not yet. A kernel with TUSB6010=y and any other glue layer =y won't
> work, IIRC it won't even build. How have you tested this patch ?

Arnaud had a configuration for Debian where this was needed, and his
patch removed the choice and endchoice.  We didn't run into that
incomapatibility.  However, we don't currently use a mixture of 'y' and
'm', so I have to confess I haven't tested it.

> ps: are you carrying a screwdriver ? Should I be concerned? :-p

Not at the moment.

Ben.

-- 
Ben Hutchings
Beware of programmers who carry screwdrivers. - Leonard Brandwein


signature.asc
Description: This is a digitally signed message part

Re: [PATCH net-next] r8152: disable the tasklet by default

[David Miller]

From: Hayes Wang 
Date: Wed, 5 Nov 2014 10:17:02 +0800

> Let the tasklet only be enabled after open(), and be disabled for
> the other situation. The tasklet is only necessary after open() for
> tx/rx, so it could be disabled by default.
> 
> Signed-off-by: Hayes Wang 

Applied, 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: [RFC v5] usb: phy: Hold wakeupsource when USB is enumerated in peripheral mode

[Kiran Raparthy]

Hi Felipe,

On 6 November 2014 01:10, Felipe Balbi  wrote:
> On Tue, Nov 04, 2014 at 03:30:54PM +0530, Kiran Kumar Raparthy wrote:
>> From: Todd Poynor 
>>
>> usb: phy: Hold wakeupsource when USB is enumerated in peripheral mode
>>
>> Some systems require a mechanism to prevent system to enter into suspend
>> state when USB is connected and enumerated in peripheral mode.
>>
>> This patch provides an interface to hold a wakeupsource to prevent suspend.
>> PHY drivers can use this interface when USB is connected and enumerated in
>> peripheral mode.
>>
>> A timed wakeupsource is temporarily held on USB disconnect events, to allow
>> the rest of the system to react to the USB disconnection (dropping host
>> sessions, updating charger status, etc.) prior to re-allowing suspend.
>>
>> Cc: Kishon Vijay Abraham I 
>> Cc: Felipe Balbi 
>> Cc: Greg Kroah-Hartman 
>> Cc: linux-ker...@vger.kernel.org
>> Cc: linux-usb@vger.kernel.org
>> Cc: Android Kernel Team 
>> Cc: John Stultz 
>> Cc: Sumit Semwal 
>> Cc: Arve Hjønnevåg 
>> Cc: Benoit Goby 
>> Signed-off-by: Todd Poynor 
>> [kiran: Added context to commit message, squished build fixes
>> from Benoit Goby and Arve Hjønnevåg, changed wakelocks usage
>> to wakeupsource, merged Todd's refactoring logic and simplified
>> the structures and code and addressed community feedback]
>> Signed-off-by: Kiran Raparthy 
>
> you still didn't get this right. I asked that you introduce
> usb_phy_set_event() as a separate patch, then make PHY drivers use it
> and only on a third patch should you hold a wakeupsource.
Thanks for your time.
Sure,I'll resend the patches as per your suggestion,could you please
let me know whether you are okay with this new approach?.
This will help me to consolidate all your inputs in new patch set.
Regards,
Kiran
>
> --
> balbi
--
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 0/3] r8152: rtl_ops_init modify

[Hayes Wang]

Initialize the ops through tp->version. This could skip checking
each VID/PID.

Hayes Wang (3):
  r8152: move r8152b_get_version
  r8152: modify rtl_ops_init
  r8152: remove the definitions of the PID

 drivers/net/usb/r8152.c | 92 +
 1 file changed, 32 insertions(+), 60 deletions(-)

-- 
1.9.3

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

[PATCH net-next 2/3] r8152: modify rtl_ops_init

[Hayes Wang]

Replace using VID/PID with using tp->version to initialize the ops.

Signed-off-by: Hayes Wang 
---
 drivers/net/usb/r8152.c | 79 ++---
 1 file changed, 28 insertions(+), 51 deletions(-)

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 4b6db8a..cf1b8a7 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -3742,66 +3742,43 @@ static void rtl8153_unload(struct r8152 *tp)
r8153_power_cut_en(tp, false);
 }
 
-static int rtl_ops_init(struct r8152 *tp, const struct usb_device_id *id)
+static int rtl_ops_init(struct r8152 *tp)
 {
struct rtl_ops *ops = &tp->rtl_ops;
-   int ret = -ENODEV;
-
-   switch (id->idVendor) {
-   case VENDOR_ID_REALTEK:
-   switch (id->idProduct) {
-   case PRODUCT_ID_RTL8152:
-   ops->init   = r8152b_init;
-   ops->enable = rtl8152_enable;
-   ops->disable= rtl8152_disable;
-   ops->up = rtl8152_up;
-   ops->down   = rtl8152_down;
-   ops->unload = rtl8152_unload;
-   ops->eee_get= r8152_get_eee;
-   ops->eee_set= r8152_set_eee;
-   ret = 0;
-   break;
-   case PRODUCT_ID_RTL8153:
-   ops->init   = r8153_init;
-   ops->enable = rtl8153_enable;
-   ops->disable= rtl8153_disable;
-   ops->up = rtl8153_up;
-   ops->down   = rtl8153_down;
-   ops->unload = rtl8153_unload;
-   ops->eee_get= r8153_get_eee;
-   ops->eee_set= r8153_set_eee;
-   ret = 0;
-   break;
-   default:
-   break;
-   }
+   int ret = 0;
+
+   switch (tp->version) {
+   case RTL_VER_01:
+   case RTL_VER_02:
+   ops->init   = r8152b_init;
+   ops->enable = rtl8152_enable;
+   ops->disable= rtl8152_disable;
+   ops->up = rtl8152_up;
+   ops->down   = rtl8152_down;
+   ops->unload = rtl8152_unload;
+   ops->eee_get= r8152_get_eee;
+   ops->eee_set= r8152_set_eee;
break;
 
-   case VENDOR_ID_SAMSUNG:
-   switch (id->idProduct) {
-   case PRODUCT_ID_SAMSUNG:
-   ops->init   = r8153_init;
-   ops->enable = rtl8153_enable;
-   ops->disable= rtl8153_disable;
-   ops->up = rtl8153_up;
-   ops->down   = rtl8153_down;
-   ops->unload = rtl8153_unload;
-   ops->eee_get= r8153_get_eee;
-   ops->eee_set= r8153_set_eee;
-   ret = 0;
-   break;
-   default:
-   break;
-   }
+   case RTL_VER_03:
+   case RTL_VER_04:
+   case RTL_VER_05:
+   ops->init   = r8153_init;
+   ops->enable = rtl8153_enable;
+   ops->disable= rtl8153_disable;
+   ops->up = rtl8153_up;
+   ops->down   = rtl8153_down;
+   ops->unload = rtl8153_unload;
+   ops->eee_get= r8153_get_eee;
+   ops->eee_set= r8153_set_eee;
break;
 
default:
+   ret = -ENODEV;
+   netif_err(tp, probe, tp->netdev, "Unknown Device\n");
break;
}
 
-   if (ret)
-   netif_err(tp, probe, tp->netdev, "Unknown Device\n");
-
return ret;
 }
 
@@ -3834,7 +3811,7 @@ static int rtl8152_probe(struct usb_interface *intf,
tp->intf = intf;
 
r8152b_get_version(tp);
-   ret = rtl_ops_init(tp, id);
+   ret = rtl_ops_init(tp);
if (ret)
goto out;
 
-- 
1.9.3

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

[PATCH net-next 3/3] r8152: remove the definitions of the PID

[Hayes Wang]

The PIDs are only used in the id table, so the definitions are
unnacessary. Remove them wouldn't have confusion.

Signed-off-by: Hayes Wang 
---
 drivers/net/usb/r8152.c | 10 +++---
 1 file changed, 3 insertions(+), 7 deletions(-)

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index cf1b8a7..66b139a 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -461,11 +461,7 @@ enum rtl8152_flags {
 
 /* Define these values to match your device */
 #define VENDOR_ID_REALTEK  0x0bda
-#define PRODUCT_ID_RTL8152 0x8152
-#define PRODUCT_ID_RTL8153 0x8153
-
 #define VENDOR_ID_SAMSUNG  0x04e8
-#define PRODUCT_ID_SAMSUNG 0xa101
 
 #define MCU_TYPE_PLA   0x0100
 #define MCU_TYPE_USB   0x
@@ -3898,9 +3894,9 @@ static void rtl8152_disconnect(struct usb_interface *intf)
 
 /* table of devices that work with this driver */
 static struct usb_device_id rtl8152_table[] = {
-   {USB_DEVICE(VENDOR_ID_REALTEK, PRODUCT_ID_RTL8152)},
-   {USB_DEVICE(VENDOR_ID_REALTEK, PRODUCT_ID_RTL8153)},
-   {USB_DEVICE(VENDOR_ID_SAMSUNG, PRODUCT_ID_SAMSUNG)},
+   {USB_DEVICE(VENDOR_ID_REALTEK, 0x8152)},
+   {USB_DEVICE(VENDOR_ID_REALTEK, 0x8153)},
+   {USB_DEVICE(VENDOR_ID_SAMSUNG, 0xa101)},
{}
 };
 
-- 
1.9.3

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

[PATCH net-next 1/3] r8152: move r8152b_get_version

[Hayes Wang]

Move r8152b_get_version() to the location before rtl_ops_init().
Then, the rtl_ops_init() could use tp->version.

Signed-off-by: Hayes Wang 
---
 drivers/net/usb/r8152.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index fd41675..4b6db8a 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -3833,6 +3833,7 @@ static int rtl8152_probe(struct usb_interface *intf,
tp->netdev = netdev;
tp->intf = intf;
 
+   r8152b_get_version(tp);
ret = rtl_ops_init(tp, id);
if (ret)
goto out;
@@ -3866,11 +3867,9 @@ static int rtl8152_probe(struct usb_interface *intf,
tp->mii.phy_id_mask = 0x3f;
tp->mii.reg_num_mask = 0x1f;
tp->mii.phy_id = R8152_PHY_ID;
-   tp->mii.supports_gmii = 0;
 
intf->needs_remote_wakeup = 1;
 
-   r8152b_get_version(tp);
tp->rtl_ops.init(tp);
set_ethernet_addr(tp);
 
-- 
1.9.3

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

[PATCH] usb: gadget: udc: pxa27x: fix build warning when !OF

[Felipe Balbi]

in case kernel is built without CONFIG_OF there
will be a build warning (see below) due to of_match_ptr()
being defined to NULL.

Because of_match_ptr() is pretty pointless anyway,
let's just remove it and fix the warning.

drivers/usb/gadget/udc/pxa27x_udc.c:2403:28: warning: ‘udc_pxa_dt_ids’ defined 
but not used [-Wunused-variable]
 static struct of_device_id udc_pxa_dt_ids[] = {
^
Signed-off-by: Felipe Balbi 
---
 drivers/usb/gadget/udc/pxa27x_udc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/gadget/udc/pxa27x_udc.c 
b/drivers/usb/gadget/udc/pxa27x_udc.c
index 69e7b816..d1d8a9f 100644
--- a/drivers/usb/gadget/udc/pxa27x_udc.c
+++ b/drivers/usb/gadget/udc/pxa27x_udc.c
@@ -2590,7 +2590,7 @@ static struct platform_driver udc_driver = {
.driver = {
.name   = "pxa27x-udc",
.owner  = THIS_MODULE,
-   .of_match_table = of_match_ptr(udc_pxa_dt_ids),
+   .of_match_table = udc_pxa_dt_ids,
},
.probe  = pxa_udc_probe,
.remove = pxa_udc_remove,
-- 
2.1.0.GIT

--
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] drivers/usb/musb/Kconfig: Use menu instead of choice for Platform Glue Layer

[Felipe Balbi]

On Thu, Nov 06, 2014 at 03:13:57AM +, Ben Hutchings wrote:
> On Wed, 2014-11-05 at 20:56 -0600, Felipe Balbi wrote:
> > On Thu, Nov 06, 2014 at 01:25:39AM +, Ben Hutchings wrote:
> > > A Kconfig choice only allows one 'y' selection or multiple 'm'
> > > selections, but it is valid to have any combination of 'y' and 'm'
> > > selections here (dependent on USB_MUSB_HDRC).  Use a menu instead.
> > > 
> > > Reported-by: Arnaud Patard 
> > > Signed-off-by: Ben Hutchings 
> > 
> > not yet. A kernel with TUSB6010=y and any other glue layer =y won't
> > work, IIRC it won't even build. How have you tested this patch ?
> 
> Arnaud had a configuration for Debian where this was needed, and his
> patch removed the choice and endchoice.  We didn't run into that
> incomapatibility.  However, we don't currently use a mixture of 'y' and
> 'm', so I have to confess I haven't tested it.

I'll run a few build tests here with this patch and see what comes out
of it.

cheers

-- 
balbi


signature.asc
Description: Digital signature

Re: [RFC v5] usb: phy: Hold wakeupsource when USB is enumerated in peripheral mode

[Felipe Balbi]

On Thu, Nov 06, 2014 at 10:04:01AM +0530, Kiran Raparthy wrote:
> Hi Felipe,
> 
> On 6 November 2014 01:10, Felipe Balbi  wrote:
> > On Tue, Nov 04, 2014 at 03:30:54PM +0530, Kiran Kumar Raparthy wrote:
> >> From: Todd Poynor 
> >>
> >> usb: phy: Hold wakeupsource when USB is enumerated in peripheral mode
> >>
> >> Some systems require a mechanism to prevent system to enter into suspend
> >> state when USB is connected and enumerated in peripheral mode.
> >>
> >> This patch provides an interface to hold a wakeupsource to prevent suspend.
> >> PHY drivers can use this interface when USB is connected and enumerated in
> >> peripheral mode.
> >>
> >> A timed wakeupsource is temporarily held on USB disconnect events, to allow
> >> the rest of the system to react to the USB disconnection (dropping host
> >> sessions, updating charger status, etc.) prior to re-allowing suspend.
> >>
> >> Cc: Kishon Vijay Abraham I 
> >> Cc: Felipe Balbi 
> >> Cc: Greg Kroah-Hartman 
> >> Cc: linux-ker...@vger.kernel.org
> >> Cc: linux-usb@vger.kernel.org
> >> Cc: Android Kernel Team 
> >> Cc: John Stultz 
> >> Cc: Sumit Semwal 
> >> Cc: Arve Hjønnevåg 
> >> Cc: Benoit Goby 
> >> Signed-off-by: Todd Poynor 
> >> [kiran: Added context to commit message, squished build fixes
> >> from Benoit Goby and Arve Hjønnevåg, changed wakelocks usage
> >> to wakeupsource, merged Todd's refactoring logic and simplified
> >> the structures and code and addressed community feedback]
> >> Signed-off-by: Kiran Raparthy 
> >
> > you still didn't get this right. I asked that you introduce
> > usb_phy_set_event() as a separate patch, then make PHY drivers use it
> > and only on a third patch should you hold a wakeupsource.
> Thanks for your time.
> Sure,I'll resend the patches as per your suggestion,could you please
> let me know whether you are okay with this new approach?.
> This will help me to consolidate all your inputs in new patch set.

I'll review again in the morning, sure.

cheers

-- 
balbi


signature.asc
Description: Digital signature