Re: [PATCH 1/1] usb: xhci: Handle USB transaction error on address command

[Lu Baolu]

Hi,

On 07/26/2017 01:11 PM, Xing, Zhengjun wrote:
>
>
> On 7/25/2017 1:09 PM, Lu Baolu wrote:
>> Xhci driver handles USB transaction errors on transfer events,
>> but transaction errors are possible on address device command
>> completion events as well.
>>
>> The xHCI specification (section 4.6.5) says: A USB Transaction
>> Error Completion Code for an Address Device Command may be due
>> to a Stall response from a device. Software should issue a Disable
>> Slot Command for the Device Slot then an Enable Slot Command to
>> recover from this error.
>>
>> This patch handles USB transaction errors on address command
>> completion events. The related discussion threads can be found
>> through below links.
>>
>> http://marc.info/?l=linux-usb=149362010728921=2
>> http://marc.info/?l=linux-usb=149252752825755=2
>>
>> Suggested-by: Mathias Nyman 
>> Signed-off-by: Lu Baolu 
>> ---
>>   drivers/usb/host/xhci.c | 6 ++
>>   1 file changed, 6 insertions(+)
>>
>> diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
>> index b2ff1ff..9cc56cd 100644
>> --- a/drivers/usb/host/xhci.c
>> +++ b/drivers/usb/host/xhci.c
>> @@ -3836,6 +3836,12 @@ static int xhci_setup_device(struct usb_hcd *hcd, 
>> struct usb_device *udev,
>>   ret = -EINVAL;
>>   break;
>>   case COMP_USB_TRANSACTION_ERROR:
>> +xhci_free_virt_device(xhci, udev->slot_id);
>
>  In xhci_free_virt_device  xhci->devs[slot_id]will be set to NULL.
>
>> +ret = xhci_disable_slot(xhci, command, udev->slot_id);
>
> When xhci_disable_slot check xhci->devs[slot_id] is NULL, just return 
> -EINVAL, the slot will not be disabled.

Yes, really.

I don't think xhci_disable_slot() should return directly when
the virtual device structure is not allocated. This function
is also used to issue a disable slot command when the
virtual device data allocation fails in xhci_alloc_dev().

I will develop v2 patch with a fix for xhci_disable_slot().

Best regards,
Lu Baolu
--
To unsubscribe from this list: send the line "unsubscribe 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 3.0 is broken on Odroid Xu4 on latest kernel

[Anand Moon]

Hi Krzysztof / Felipe,

On 20 July 2017 at 01:50, Krzysztof Kozlowski  wrote:
> On Wed, Jul 19, 2017 at 09:13:29PM +0300, Felipe Balbi wrote:
>>
>> Hi,
>>
>> Anand Moon  writes:
>> > Hi Krzysztof,
>> >
>> > Today I tried to compile the latest kernel for Odroid xu4.
>> > using exynos_defconfig I build and loaded the kernel.
>> > but to my surprise usb 3.0 device and missing.
>> >
>> > odroid login: root
>> > Password:
>> > Last login: Wed Jul 19 14:01:44 UTC 2017 on ttySAC2
>> > Welcome to Ubuntu 16.04.2 LTS (GNU/Linux 4.13.0-rc1-xu4ml-27846-g74cbd96 
>> > armv7l)
>>
>> Dude, you have 27 thousand patches on top of v4.13-rc1??? Try vanilla
>> v4.13-rc1 and try a git bisect.
>
> Hi Anand,
>
> Beside Felipe's comment, I do not have XU4. I cannot reproduce it on
> XU3-Lite (but there is difference in USB2 and USB3, AFAIR).
>
> $ uname -a
> Linux odroidxu3 4.13.0-rc1-00071-ge06fdaf40a5c #1051 SMP PREEMPT Wed Jul 19 
> 22:07:41 CEST 2017 armv7l GNU/Linux
> $ lsusb
> Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
> Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
> Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. SMSC9512/9514 
> Fast Ethernet Adapter
> Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp. SMC9514 Hub
> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
>
> Try to follow Felipe's advice of using vanilla kernel from Linus and
> bisecting it.
>
> Best regards,
> Krzysztof
>

I feel this is long standing issue with phy-exynos5-usbdrd.c
with following patch missing.

[0] https://patchwork.kernel.org/patch/5204471/

with some more updated to phy-exynos5-usbdrd.c
I was able to bring the phy up in cold boot.
but when I perform warm boot the issue persist.

root@odroidxu4q:~# uname -a
Linux odroidxu4q 4.13.0-rc2-xu4next-14488-g25f6a53-dirty #7 SMP
PREEMPT Tue Jul25 20:04:02 UTC 2017 armv7l armv7l armv7l GNU/Linux
root@odroidxu4q:~# lsusb -t
/:  Bus 06.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M
|__ Port 1: Dev 2, If 0, Class=Vendor Specific Class, Driver=r8152, 5000M
/:  Bus 05.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M
/:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/2p, 5000M
|__ Port 1: Dev 3, If 0, Class=Mass Storage, Driver=usb-storage, 5000M
|__ Port 2: Dev 4, If 1, Class=Video, Driver=uvcvideo, 5000M
|__ Port 2: Dev 4, If 0, Class=Video, Driver=uvcvideo, 5000M
/:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/2p, 480M
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=exynos-ohci/3p, 12M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=exynos-ehci/3p, 480M
root@odroidxu4q:~#

Best Regards
-Anand
--
To unsubscribe from this list: send the line "unsubscribe 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: phy: Add USB charger support

[Baolin Wang]

Hi Manu,

On 25 July 2017 at 19:19, Manu Gautam  wrote:
> Hi,
>
>
> On 7/25/2017 1:30 PM, Baolin Wang wrote:
>> This patch introduces the usb charger support based on usb phy that
>> makes an enhancement to a power driver. The basic conception of the
>> usb charger is that, when one usb charger is added or removed by
>> reporting from the extcon device state change, the usb charger will
>> report to power user to set the current limitation.
>>
>> Power user can register a notifiee on the usb phy by issuing
>> usb_register_notifier() to get notified by charger status changes
>> or charger current changes.
>
> Why can't we use power_supply framework for this?
> Power user can register usb power_supply and USB PHY driver
> can update charging current using - power_supply_set_property().

No. We can get the current can be drawn from USB layer not from power
supply framework, moreover some USB controller can detect the charger
type and power supply framework can not. I think you missed lots of
previous discussion, maybe you can check below links to follow what we
have discussed before.
https://lists.gt.net/linux/kernel/2546730
https://patchwork.kernel.org/patch/9601973/


>> we can notify what current to be drawn to power user according to
>> different charger type, and now we have 2 methods to get charger type.
>> One is get charger type from extcon subsystem, which also means the
>> charger state changes. Another is we can get the charger type from
>> USB controller detecting or PMIC detecting, and the charger state
>> changes should be told by issuing usb_phy_set_charger_state().
>>
>> Signed-off-by: Baolin Wang 
>> ---
>>  drivers/usb/phy/phy.c   |  272 
>> +++
>>  include/linux/usb/phy.h |   49 +
>
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
>



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

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

[Baolin Wang]

Hi,

On 25 July 2017 at 17:59, Sebastian Reichel
 wrote:
> Hi,
>
> On Tue, Jul 25, 2017 at 04:00:01PM +0800, Baolin Wang wrote:
>> Integrate with the newly added USB charger interface to limit the current
>> we draw from the USB input based on the input device configuration
>> identified by the USB stack, allowing us to charge more quickly from high
>> current inputs without drawing more current than specified from others.
>>
>> Signed-off-by: Mark Brown 
>> Signed-off-by: Baolin Wang 
>> ---
>>  Documentation/devicetree/bindings/mfd/wm831x.txt |1 +
>>  drivers/power/supply/wm831x_power.c  |   58 
>> ++
>>  2 files changed, 59 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/mfd/wm831x.txt 
>> b/Documentation/devicetree/bindings/mfd/wm831x.txt
>> index 9f8b743..4e3bc07 100644
>> --- a/Documentation/devicetree/bindings/mfd/wm831x.txt
>> +++ b/Documentation/devicetree/bindings/mfd/wm831x.txt
>> @@ -31,6 +31,7 @@ Required properties:
>>  ../interrupt-controller/interrupts.txt
>>
>>  Optional sub-nodes:
>> +  - usb-phy : Contains a phandle to the USB PHY.
>>- regulators : Contains sub-nodes for each of the regulators supplied by
>>  the device. The regulators are bound using their names listed below:
>>
>> diff --git a/drivers/power/supply/wm831x_power.c 
>> b/drivers/power/supply/wm831x_power.c
>> index 7082301..d3948ab 100644
>> --- a/drivers/power/supply/wm831x_power.c
>> +++ b/drivers/power/supply/wm831x_power.c
>> @@ -13,6 +13,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>
>>  #include 
>>  #include 
>> @@ -31,6 +32,8 @@ struct wm831x_power {
>>   char usb_name[20];
>>   char battery_name[20];
>>   bool have_battery;
>> + struct usb_phy *usb_phy;
>> + struct notifier_block usb_notify;
>>  };
>>
>>  static int wm831x_power_check_online(struct wm831x *wm831x, int supply,
>> @@ -125,6 +128,43 @@ static int wm831x_usb_get_prop(struct power_supply *psy,
>>   POWER_SUPPLY_PROP_VOLTAGE_NOW,
>>  };
>>
>> +/* In milliamps */
>> +static const unsigned int wm831x_usb_limits[] = {
>> + 0,
>> + 2,
>> + 100,
>> + 500,
>> + 900,
>> + 1500,
>> + 1800,
>> + 550,
>> +};
>> +
>> +static int wm831x_usb_limit_change(struct notifier_block *nb,
>> +unsigned long limit, void *data)
>> +{
>> + struct wm831x_power *wm831x_power = container_of(nb,
>> +  struct wm831x_power,
>> +  usb_notify);
>> + unsigned int i, best;
>> +
>> + /* Find the highest supported limit */
>> + best = 0;
>> + for (i = 0; i < ARRAY_SIZE(wm831x_usb_limits); i++) {
>> + if (limit >= wm831x_usb_limits[i] &&
>> + wm831x_usb_limits[best] < wm831x_usb_limits[i])
>> + best = i;
>> + }
>> +
>> + dev_dbg(wm831x_power->wm831x->dev,
>> + "Limiting USB current to %umA", wm831x_usb_limits[best]);
>> +
>> + wm831x_set_bits(wm831x_power->wm831x, WM831X_POWER_STATE,
>> + WM831X_USB_ILIM_MASK, best);
>> +
>> + return 0;
>> +}
>> +
>>  /*
>>   *   Battery properties
>>   */
>> @@ -607,6 +647,19 @@ static int wm831x_power_probe(struct platform_device 
>> *pdev)
>>   }
>>   }
>>
>> + power->usb_phy = devm_usb_get_phy_by_phandle(>dev,
>> +  "usb-phy", 0);
>> + if (!IS_ERR(power->usb_phy)) {
>> + power->usb_notify.notifier_call = wm831x_usb_limit_change;
>> + ret = usb_register_notifier(power->usb_phy,
>> + >usb_notify);
>> + if (ret) {
>> + dev_err(>dev, "Failed to register notifier: 
>> %d\n",
>> + ret);
>> + goto err_bat_irq;
>> + }
>> + }
>
> No error handling for power->usb_phy? I think you should bail out
> for all errors except for "not defined in DT". Especially I would
> expect probe defer handling in case the power supply driver is
> loaded before the phy driver.

Make sense. So I think I need to change like below:

power->usb_phy = devm_usb_get_phy_by_phandle(>dev, "usb-phy", 0);
if (!IS_ERR(power->usb_phy)) {
power->usb_notify.notifier_call = wm831x_usb_limit_change;
ret = usb_register_notifier(power->usb_phy, >usb_notify);
if (ret) {
dev_err(>dev, "Failed to register notifier: %d\n", ret);
goto err_bat_irq;
}
} else if (PTR_ERR(power->usb_phy) != -ENODEV &&
PTR_ERR(power->usb_phy) != -EINVAL) {
   ret = PTR_ERR(power->usb_phy);
   dev_err(>dev, "Failed to find 

[PATCH] uas: Add US_FL_IGNORE_RESIDUE for Initio Copropration INIC-3069

[Alan Swanson]

Similar to commit d595259fbb7a7afed241b1afb2c4fe4b47de47fa for INIC-3169 in
unusual_devs.h but INIC-3069 already present in unusual_uas.h. Both in same
controller IC family.

Issue is that MakeMKV fails during key exchange with installed bluray drive
with following error:

002004: Error 'Scsi error - ILLEGAL REQUEST:COPY PROTECTION KEY EXCHANGE 
FAILURE - KEY NOT ESTABLISHED'
occurred while issuing SCSI command AD010..080002400 to device 'SG:dev_11:0'

Signed-off-by: Alan Swanson 
---
 drivers/usb/storage/unusual_uas.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/storage/unusual_uas.h 
b/drivers/usb/storage/unusual_uas.h
index cbea9f32..cde11535 100644
--- a/drivers/usb/storage/unusual_uas.h
+++ b/drivers/usb/storage/unusual_uas.h
@@ -124,9 +124,9 @@ UNUSUAL_DEV(0x0bc2, 0xab2a, 0x, 0x,
 /* Reported-by: Benjamin Tissoires  */
 UNUSUAL_DEV(0x13fd, 0x3940, 0x, 0x,
"Initio Corporation",
-   "",
+   "INIC-3069",
USB_SC_DEVICE, USB_PR_DEVICE, NULL,
-   US_FL_NO_ATA_1X),
+   US_FL_NO_ATA_1X | US_FL_IGNORE_RESIDUE),
 
 /* Reported-by: Tom Arild Naess  */
 UNUSUAL_DEV(0x152d, 0x0539, 0x, 0x,
-- 
2.13.2

--
To unsubscribe from this list: send the line "unsubscribe 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: hcd: Mark secondary HCD as dead if the primary one died

[Rafael J. Wysocki]

From: Rafael J. Wysocki 

Make usb_hc_died() clear the HCD_FLAG_RH_RUNNING flag for the shared
HCD and set HCD_FLAG_DEAD for it, in analogy with what is done for
the primary one.

Among other thigs, this prevents check_root_hub_suspended() from
returning -EBUSY for dead HCDs which helps to work around system
suspend issues in some situations.

This actually fixes occasional suspend failures on one of my test
machines.

Suggested-by: Alan Stern 
Signed-off-by: Rafael J. Wysocki 
---
 drivers/usb/core/hcd.c |2 ++
 1 file changed, 2 insertions(+)

Index: linux-pm/drivers/usb/core/hcd.c
===
--- linux-pm.orig/drivers/usb/core/hcd.c
+++ linux-pm/drivers/usb/core/hcd.c
@@ -2485,6 +2485,8 @@ void usb_hc_died (struct usb_hcd *hcd)
}
if (usb_hcd_is_primary_hcd(hcd) && hcd->shared_hcd) {
hcd = hcd->shared_hcd;
+   clear_bit(HCD_FLAG_RH_RUNNING, >flags);
+   set_bit(HCD_FLAG_DEAD, >flags);
if (hcd->rh_registered) {
clear_bit(HCD_FLAG_POLL_RH, >flags);
 

--
To unsubscribe from this list: send the line "unsubscribe 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] PM / USB: hcd_pci: Skip secondary root hub check for HCD_DEAD()

[Rafael J. Wysocki]

On Tuesday, July 25, 2017 05:06:40 PM Alan Stern wrote:
> On Tue, 25 Jul 2017, Rafael J. Wysocki wrote:
> 
> > On Tuesday, July 25, 2017 05:59:04 PM Rafael J. Wysocki wrote:
> > > On Tuesday, July 25, 2017 10:05:03 AM Alan Stern wrote:
> > > > On Tue, 25 Jul 2017, Rafael J. Wysocki wrote:
> > > > 
> > > > > From: Rafael J. Wysocki 
> > > > > 
> > > > > If HCD_DEAD(hcd) is "true" in check_root_hub_suspended(), it is
> > > > > rather pointless to check the secondary root hub, so return early
> > > > > then.
> > > > > 
> > > > > This actually fixes occasional suspend failures on one of my test
> > > > > machines.
> > > > > 
> > > > > Signed-off-by: Rafael J. Wysocki 
> > > > > ---
> > > > >  drivers/usb/core/hcd-pci.c |3 +++
> > > > >  1 file changed, 3 insertions(+)
> > > > > 
> > > > > Index: linux-pm/drivers/usb/core/hcd-pci.c
> > > > > ===
> > > > > --- linux-pm.orig/drivers/usb/core/hcd-pci.c
> > > > > +++ linux-pm/drivers/usb/core/hcd-pci.c
> > > > > @@ -427,6 +427,9 @@ static int check_root_hub_suspended(stru
> > > > >   dev_warn(dev, "Root hub is not suspended\n");
> > > > >   return -EBUSY;
> > > > >   }
> > > > > + if (HCD_DEAD(hcd))
> > > > > + return 0;
> > > > > +
> > > > >   if (hcd->shared_hcd) {
> > > > >   hcd = hcd->shared_hcd;
> > > > >   if (HCD_RH_RUNNING(hcd)) {
> > > > 
> > > > While this is an okay solution, IMO it would be more reliable and more 
> > > > general to have usb_hc_died() clear the HCD_FLAG_RH_RUNNING bit and set 
> > > > the HCD_FLAG_DEAD bit in the shared hcd.  Right now it only does these 
> > > > things for the primary.
> > > > 
> > > > Would you like to write and test a patch to do that?
> > > 
> > > I can do that.
> > 
> > Just to make sure that we are on the same page, is the below what you mean?
> > 
> > ---
> >  drivers/usb/core/hcd.c |2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > Index: linux-pm/drivers/usb/core/hcd.c
> > ===
> > --- linux-pm.orig/drivers/usb/core/hcd.c
> > +++ linux-pm/drivers/usb/core/hcd.c
> > @@ -2485,6 +2485,8 @@ void usb_hc_died (struct usb_hcd *hcd)
> > }
> > if (usb_hcd_is_primary_hcd(hcd) && hcd->shared_hcd) {
> > hcd = hcd->shared_hcd;
> > +   clear_bit(HCD_FLAG_RH_RUNNING, >flags);
> > +   set_bit(HCD_FLAG_DEAD, >flags);
> > if (hcd->rh_registered) {
> > clear_bit(HCD_FLAG_POLL_RH, >flags);
> 
> Yes, exactly.  Does it fix your suspend problem?

Yes, it does.

I guess I should resend it with a changelog and tags, then.

Thanks,
Rafael

--
To unsubscribe from this list: send the line "unsubscribe 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: Please help me with kernel hung

[Alan Stern]

On Wed, 26 Jul 2017, Михаил Гаврилов wrote:

> On 25 July 2017 at 02:12, Alan Stern  wrote:
> > This is enough for now.  The problem is that a USB transfer is started
> > but never stopped, which indicates a problem with the host controller.
> >
> > In this case you're using an xHCI host controller.  Unfortunately the
> > xHCI maintainer is on vacation, so he won't be able to help for a
> > while.
> >
> > In the meantime, you could try doing a git bisection to find which
> > commit caused the problem to occur.
> >
> > Alan Stern
> >
> 
> Sorry, I am afraid I can't bisect because i don't know how triggering
> this issue again.
> It means that I already several times rebooted after this and machine not 
> hung.
> 
> But still occurs another problem that reproducible more successful
> when I run KVM virtual machine and run inside kernel compilation then
> host hung without any records in journalctl log. It's really annoying
> because I don't know who is culprit here. Can here helps bisect?

I don't know.  Try it and see.

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] PM / USB: hcd_pci: Skip secondary root hub check for HCD_DEAD()

[Alan Stern]

On Tue, 25 Jul 2017, Rafael J. Wysocki wrote:

> On Tuesday, July 25, 2017 05:59:04 PM Rafael J. Wysocki wrote:
> > On Tuesday, July 25, 2017 10:05:03 AM Alan Stern wrote:
> > > On Tue, 25 Jul 2017, Rafael J. Wysocki wrote:
> > > 
> > > > From: Rafael J. Wysocki 
> > > > 
> > > > If HCD_DEAD(hcd) is "true" in check_root_hub_suspended(), it is
> > > > rather pointless to check the secondary root hub, so return early
> > > > then.
> > > > 
> > > > This actually fixes occasional suspend failures on one of my test
> > > > machines.
> > > > 
> > > > Signed-off-by: Rafael J. Wysocki 
> > > > ---
> > > >  drivers/usb/core/hcd-pci.c |3 +++
> > > >  1 file changed, 3 insertions(+)
> > > > 
> > > > Index: linux-pm/drivers/usb/core/hcd-pci.c
> > > > ===
> > > > --- linux-pm.orig/drivers/usb/core/hcd-pci.c
> > > > +++ linux-pm/drivers/usb/core/hcd-pci.c
> > > > @@ -427,6 +427,9 @@ static int check_root_hub_suspended(stru
> > > > dev_warn(dev, "Root hub is not suspended\n");
> > > > return -EBUSY;
> > > > }
> > > > +   if (HCD_DEAD(hcd))
> > > > +   return 0;
> > > > +
> > > > if (hcd->shared_hcd) {
> > > > hcd = hcd->shared_hcd;
> > > > if (HCD_RH_RUNNING(hcd)) {
> > > 
> > > While this is an okay solution, IMO it would be more reliable and more 
> > > general to have usb_hc_died() clear the HCD_FLAG_RH_RUNNING bit and set 
> > > the HCD_FLAG_DEAD bit in the shared hcd.  Right now it only does these 
> > > things for the primary.
> > > 
> > > Would you like to write and test a patch to do that?
> > 
> > I can do that.
> 
> Just to make sure that we are on the same page, is the below what you mean?
> 
> ---
>  drivers/usb/core/hcd.c |2 ++
>  1 file changed, 2 insertions(+)
> 
> Index: linux-pm/drivers/usb/core/hcd.c
> ===
> --- linux-pm.orig/drivers/usb/core/hcd.c
> +++ linux-pm/drivers/usb/core/hcd.c
> @@ -2485,6 +2485,8 @@ void usb_hc_died (struct usb_hcd *hcd)
>   }
>   if (usb_hcd_is_primary_hcd(hcd) && hcd->shared_hcd) {
>   hcd = hcd->shared_hcd;
> + clear_bit(HCD_FLAG_RH_RUNNING, >flags);
> + set_bit(HCD_FLAG_DEAD, >flags);
>   if (hcd->rh_registered) {
>   clear_bit(HCD_FLAG_POLL_RH, >flags);

Yes, exactly.  Does it fix your suspend problem?

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] PM / USB: hcd_pci: Skip secondary root hub check for HCD_DEAD()

[Rafael J. Wysocki]

On Tuesday, July 25, 2017 05:59:04 PM Rafael J. Wysocki wrote:
> On Tuesday, July 25, 2017 10:05:03 AM Alan Stern wrote:
> > On Tue, 25 Jul 2017, Rafael J. Wysocki wrote:
> > 
> > > From: Rafael J. Wysocki 
> > > 
> > > If HCD_DEAD(hcd) is "true" in check_root_hub_suspended(), it is
> > > rather pointless to check the secondary root hub, so return early
> > > then.
> > > 
> > > This actually fixes occasional suspend failures on one of my test
> > > machines.
> > > 
> > > Signed-off-by: Rafael J. Wysocki 
> > > ---
> > >  drivers/usb/core/hcd-pci.c |3 +++
> > >  1 file changed, 3 insertions(+)
> > > 
> > > Index: linux-pm/drivers/usb/core/hcd-pci.c
> > > ===
> > > --- linux-pm.orig/drivers/usb/core/hcd-pci.c
> > > +++ linux-pm/drivers/usb/core/hcd-pci.c
> > > @@ -427,6 +427,9 @@ static int check_root_hub_suspended(stru
> > >   dev_warn(dev, "Root hub is not suspended\n");
> > >   return -EBUSY;
> > >   }
> > > + if (HCD_DEAD(hcd))
> > > + return 0;
> > > +
> > >   if (hcd->shared_hcd) {
> > >   hcd = hcd->shared_hcd;
> > >   if (HCD_RH_RUNNING(hcd)) {
> > 
> > While this is an okay solution, IMO it would be more reliable and more 
> > general to have usb_hc_died() clear the HCD_FLAG_RH_RUNNING bit and set 
> > the HCD_FLAG_DEAD bit in the shared hcd.  Right now it only does these 
> > things for the primary.
> > 
> > Would you like to write and test a patch to do that?
> 
> I can do that.

Just to make sure that we are on the same page, is the below what you mean?

---
 drivers/usb/core/hcd.c |2 ++
 1 file changed, 2 insertions(+)

Index: linux-pm/drivers/usb/core/hcd.c
===
--- linux-pm.orig/drivers/usb/core/hcd.c
+++ linux-pm/drivers/usb/core/hcd.c
@@ -2485,6 +2485,8 @@ void usb_hc_died (struct usb_hcd *hcd)
}
if (usb_hcd_is_primary_hcd(hcd) && hcd->shared_hcd) {
hcd = hcd->shared_hcd;
+   clear_bit(HCD_FLAG_RH_RUNNING, >flags);
+   set_bit(HCD_FLAG_DEAD, >flags);
if (hcd->rh_registered) {
clear_bit(HCD_FLAG_POLL_RH, >flags);
 

--
To unsubscribe from this list: send the line "unsubscribe 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: Please help me with kernel hung

[Михаил Гаврилов]

On 25 July 2017 at 02:12, Alan Stern  wrote:
> This is enough for now.  The problem is that a USB transfer is started
> but never stopped, which indicates a problem with the host controller.
>
> In this case you're using an xHCI host controller.  Unfortunately the
> xHCI maintainer is on vacation, so he won't be able to help for a
> while.
>
> In the meantime, you could try doing a git bisection to find which
> commit caused the problem to occur.
>
> Alan Stern
>

Sorry, I am afraid I can't bisect because i don't know how triggering
this issue again.
It means that I already several times rebooted after this and machine not hung.

But still occurs another problem that reproducible more successful
when I run KVM virtual machine and run inside kernel compilation then
host hung without any records in journalctl log. It's really annoying
because I don't know who is culprit here. Can here helps bisect?
--
To unsubscribe from this list: send the line "unsubscribe 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: No Ethernet on Raspberry Pi 3 in v4.13-rc1

[Stefan Wahren]

> Robin Murphy  hat am 25. Juli 2017 um 15:21 geschrieben:
> 
> 
> Hi Stefan,
> 
> On 25/07/17 06:19, Stefan Wahren wrote:
> >>> With arm64 4.13-rc1 I get no eth0 device on Pi3 (openSUSE Tumbleweed).
> >>> The v4.13-rc1 DT works okay with a 4.12 kernel.
> >>>
> >>> Possibly related:
> >>>
> >>> [   15.916350] OF: /soc/usb@7e98: could not get #phy-cells for /phy
> >>>
> >>> [   16.496662] usb 1-1: new high-speed USB device number 2 using dwc2
> >>> [   16.502988] dwc2 3f98.usb: Cannot do DMA to address
> >>> 0x335da400
> >>
> >> This is from SWIOTLB's map_single(), which means whatever device was
> >> passed into dma_map_single() when mapping the URB had a DMA mask smaller
> >> than 30 bits (or none at all), which sounds wrong and is almost
> >> certainly the root of the problem (i.e. it probably wasn't the actual
> >> HCD device described in DT and set up by of_dma_configure()). 
> > 
> > how can i figure out what's cause this issue (bcm283x or dwc2 specific)?
> > 
> > The dwc2 hcd already check the DMA mask on probe [1] and i never saw a 
> > warning in error case.
> 
> I'll admit I'm a little stumped, since the two commits to dwc2 since
> 4.12 seem entirely inconsequential.
> 
> The only way I can see this happening is if the first dma_capable()
> check in swiotlb_map_page() fails, and since swiotlb_force must be set
> to SWIOTLB_NOFORCE in order to print the error later, and the address
> and size look reasonable, that only leaves dev->dma_mask as the culprit.
> 
> From the subsequent fallout (which on closer inspection looks more to do
> with calling into uninitialised SWIOTLB state than the arm64 DMA code
> actually doing anything wrong), I'd guess dev->dma_pfn_offset is
> probably 0 as well, which further points to the wrong device. Maybe
> something's changed lower down in the USB core? Turning on tracing and
> booting with "tp_printk trace_event=swiotlb_bounced" on the command line
> should shed a bit more light on what's going on.
> 

FWIW, i added some dev_info before and after dma_set_mask in dwc2 (error case):

[5.471761] dwc2 3f98.usb: before mask: 
[5.491016] dwc2 3f98.usb: before coherent mask: 
[5.513379] dwc2 3f98.usb: after mask: 
[5.532572] dwc2 3f98.usb: after coherent mask: 
[5.555039] dwc2 3f98.usb: DWC OTG Controller
[5.575855] dwc2 3f98.usb: new USB bus registered, assigned bus number 1
[5.605944] dwc2 3f98.usb: irq 41, io mem 0x3f98

which doesn't match the tracing outputs.

> Robin.
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line "unsubscribe 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: [RFCv2 usb-next 2/3] usb: host: add a generic platform USB roothub driver

[Martin Blumenstingl]

On Tue, Jul 25, 2017 at 8:40 AM, Chunfeng Yun  wrote:
> On Thu, 2017-07-13 at 12:59 +0200, Martin Blumenstingl wrote:
>> Many SoC platforms have separate devices for the USB PHY which are
>> registered through the generic PHY framework. These PHYs have to be
>> enabled to make the USB controller actually work. They also have to be
>> disabled again on shutdown/suspend.
>>
>> Currently (at least) the following HCI platform drivers are using custom
>> code to obtain all PHYs via devicetree for the roothub/controller and
>> disable/enable them when required:
>> - ehci-platform.c has ehci_platform_power_{on,off}
>> - xhci-mtk.c has xhci_mtk_phy_{init,exit,power_on,power_off}
>> - ohci-platform.c has ohci_platform_power_{on,off}
>>
>> These drivers are not using the generic devicetree USB device bindings
>> yet which were only introduced recently (documentation is available in
>> devicetree/bindings/usb/usb-device.txt).
>> With this new driver the usb2-phy and usb3-phy can be specified directly
>> in the child-node of the corresponding port of the roothub via
>> devicetree. This can be extended by not just parsing PHYs (some of the
>> other drivers listed above are for example also parsing a list of clocks
>> as well) when required.
>>
>> Signed-off-by: Martin Blumenstingl 
>> ---
>>  drivers/usb/host/Kconfig|   3 +
>>  drivers/usb/host/Makefile   |   2 +
>>  drivers/usb/host/platform-roothub.c | 146 
>> 
>>  drivers/usb/host/platform-roothub.h |  14 
>>  4 files changed, 165 insertions(+)
>>  create mode 100644 drivers/usb/host/platform-roothub.c
>>  create mode 100644 drivers/usb/host/platform-roothub.h
>>
>> diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
>> index fa5692dec832..b8b05c786b2a 100644
>> --- a/drivers/usb/host/Kconfig
>> +++ b/drivers/usb/host/Kconfig
>> @@ -805,6 +805,9 @@ config USB_HCD_SSB
>>
>> If unsure, say N.
>>
>> +config USB_PLATFORM_ROOTHUB
>> + bool
>> +
>>  config USB_HCD_TEST_MODE
>>   bool "HCD test mode support"
>>   ---help---
>> diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
>> index cf2691fffcc0..dc817f82d632 100644
>> --- a/drivers/usb/host/Makefile
>> +++ b/drivers/usb/host/Makefile
>> @@ -29,6 +29,8 @@ obj-$(CONFIG_USB_WHCI_HCD)  += whci/
>>
>>  obj-$(CONFIG_USB_PCI)+= pci-quirks.o
>>
>> +obj-$(CONFIG_USB_PLATFORM_ROOTHUB)   += platform-roothub.o
>> +
>>  obj-$(CONFIG_USB_EHCI_HCD)   += ehci-hcd.o
>>  obj-$(CONFIG_USB_EHCI_PCI)   += ehci-pci.o
>>  obj-$(CONFIG_USB_EHCI_HCD_PLATFORM)  += ehci-platform.o
>> diff --git a/drivers/usb/host/platform-roothub.c 
>> b/drivers/usb/host/platform-roothub.c
>> new file mode 100644
>> index ..84837e42b006
>> --- /dev/null
>> +++ b/drivers/usb/host/platform-roothub.c
>> @@ -0,0 +1,146 @@
>> +/*
>> + * platform roothub driver - a virtual PHY device which passes all phy_*
>> + * function calls to multiple (actual) PHY devices. This is comes handy when
>> + * initializing all PHYs on a root-hub (to keep them all in the same state).
>> + *
>> + * Copyright (C) 2017 Martin Blumenstingl 
>> 
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + *
>> + * You should have received a copy of the GNU General Public License
>> + * along with this program. If not, see .
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#include "platform-roothub.h"
>> +
>> +#define ROOTHUB_PORTNUM  0
>> +
>> +struct platform_roothub {
>> + struct phy  *phy;
>> + struct list_headlist;
>> +};
>> +
>> +static struct platform_roothub *platform_roothub_alloc(struct device *dev)
>> +{
>> + struct platform_roothub *roothub_entry;
>> +
>> + roothub_entry = devm_kzalloc(dev, sizeof(*roothub_entry), GFP_KERNEL);
>> + if (!roothub_entry)
>> + return ERR_PTR(-ENOMEM);
>> +
>> + INIT_LIST_HEAD(_entry->list);
>> +
>> + return roothub_entry;
>> +}
>> +
>> +static int platform_roothub_add_phy(struct device *dev,
>> + struct device_node *port_np,
>> + const char *con_id, struct list_head *list)
>> +{
>> + struct platform_roothub *roothub_entry;
>> + struct phy *phy = devm_of_phy_get(dev, port_np, con_id);
>> +
>> + if (IS_ERR_OR_NULL(phy)) {
>> + if (!phy || PTR_ERR(phy) == -ENODEV)
>> + return 0;
>> + else
>> + return PTR_ERR(phy);
>> + }
>> +
>> + roothub_entry = platform_roothub_alloc(dev);
>> + if (IS_ERR(roothub_entry))
>> + return PTR_ERR(roothub_entry);
>> +
>> + roothub_entry->phy = 

Re: No Ethernet on Raspberry Pi 3 in v4.13-rc1

[Stefan Wahren]

> Robin Murphy  hat am 25. Juli 2017 um 15:21 geschrieben:
> 
> From the subsequent fallout (which on closer inspection looks more to do
> with calling into uninitialised SWIOTLB state than the arm64 DMA code
> actually doing anything wrong), I'd guess dev->dma_pfn_offset is
> probably 0 as well, which further points to the wrong device. Maybe
> something's changed lower down in the USB core? Turning on tracing and
> booting with "tp_printk trace_event=swiotlb_bounced" on the command line
> should shed a bit more light on what's going on.

I took a slightly different config which also works with 4.12 and break with 
4.13-rc1:

[0.00] Booting Linux on physical CPU 0x0
[0.00] Linux version 4.13.0-rc1-ARCH (stefan@Latitude-E4310) (gcc 
version 6.3.1 20170109 (Linaro GCC 6.3-2017.02)) #34 SMP Tue Jul 25 20:31:35 
CEST 2017
[0.00] Boot CPU: AArch64 Processor [410fd034]
[0.00] Machine model: Raspberry Pi 3 Model B Rev 1.2
[0.00] efi: Getting EFI parameters from FDT:
[0.00] efi: UEFI not found.
[0.00] cma: Failed to reserve 512 MiB
[0.00] percpu: Embedded 3 pages/cpu @80003ae9 s125336 r8192 
d63080 u196608
[0.00] Detected VIPT I-cache on CPU0
[0.00] Built 1 zonelists in Zone order, mobility grouping off.  Total 
pages: 15089
[0.00] Kernel command line: earlyprintk console=ttyAMA0 
bcm2708_fb.fbwidth=656 bcm2708_fb.fbheight=416 bcm2708_fb.fbswap=1 
dma.dmachans=0x7f35 bcm2709.boardrev=0xa02082 bcm2709.serial=0x53a68e44 
bcm2709.uart_clock=4800 smsc95xx.macaddr=B8:27:EB:A6:8E:44 
vc_mem.mem_base=0x3dc0 vc_mem.mem_size=0x3f00  dwc_otg.lpm_enable=0 
console=ttyS0,115200 console=tty1 root=PARTUUID=29cb32be-02 rootfstype=ext4 
elevator=deadline fsck.repair=yes rootwait tp_printk trace_event=swiotlb_bounced
[0.00] PID hash table entries: 4096 (order: -1, 32768 bytes)
[0.00] Dentry cache hash table entries: 131072 (order: 4, 1048576 bytes)
[0.00] Inode-cache hash table entries: 65536 (order: 3, 524288 bytes)
[0.00] Memory: 939712K/966656K available (11836K kernel code, 2400K 
rwdata, 5376K rodata, 1600K init, 1269K bss, 26944K reserved, 0K cma-reserved)
[0.00] Virtual kernel memory layout:
[0.00] modules : 0x - 0x0800   (   128 
MB)
[0.00] vmalloc : 0x0800 - 0x7bdf   (126847 
GB)
[0.00]   .text : 0x0808 - 0x08c1   ( 11840 
KB)
[0.00] .rodata : 0x08c1 - 0x0916   (  5440 
KB)
[0.00]   .init : 0x0916 - 0x092f   (  1600 
KB)
[0.00]   .data : 0x092f - 0x09548200   (  2401 
KB)
[0.00].bss : 0x09548200 - 0x09685988   (  1270 
KB)
[0.00] fixed   : 0x7fdffe7d - 0x7fdffec0   (  4288 
KB)
[0.00] PCI I/O : 0x7fdffee0 - 0x7fdfffe0   (16 
MB)
[0.00] vmemmap : 0x7fe0 - 0x8000   (   128 
GB maximum)
[0.00]   0x7fe0 - 0x7feec000   ( 0 
MB actual)
[0.00] memory  : 0x8000 - 0x80003b00   (   944 
MB)
[0.00] random: get_random_u64 called from 
cache_random_seq_create+0x60/0x118 with crng_init=0
[0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
[0.00] ftrace: allocating 43369 entries in 11 pages
[0.00] Hierarchical RCU implementation.
[0.00]  RCU restricting CPUs from NR_CPUS=8 to nr_cpu_ids=4.
[0.00]  Tasks RCU enabled.
[0.00] RCU: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=4
[0.00] NR_IRQS: 64, nr_irqs: 64, preallocated irqs: 0
[0.00] arch_timer: WARNING: Invalid trigger for IRQ2, assuming level low
[0.00] arch_timer: WARNING: Please fix your firmware
[0.00] arch_timer: cp15 timer(s) running at 19.20MHz (phys).
[0.00] clocksource: arch_sys_counter: mask: 0xff 
max_cycles: 0x46d987e47, max_idle_ns: 440795202767 ns
[0.06] sched_clock: 56 bits at 19MHz, resolution 52ns, wraps every 
4398046511078ns
[0.000180] Console: colour dummy device 80x25
[0.001202] console [tty1] enabled
[0.001246] Calibrating delay loop (skipped), value calculated using timer 
frequency.. 38.40 BogoMIPS (lpj=192000)
[0.001296] pid_max: default: 32768 minimum: 301
[0.002076] Security Framework initialized
[0.002106] Yama: becoming mindful.
[0.002325] Mount-cache hash table entries: 8192 (order: 0, 65536 bytes)
[0.002417] Mountpoint-cache hash table entries: 8192 (order: 0, 65536 bytes)
[0.004540] ASID allocator initialised with 65536 entries
[0.004664] Hierarchical SRCU implementation.
[0.010622] EFI services will not be available.
[0.010923] smp: Bringing up secondary CPUs ...
[0.011453] Detected 

Re: [PATCH] PM / USB: hcd_pci: Skip secondary root hub check for HCD_DEAD()

[Rafael J. Wysocki]

On Tuesday, July 25, 2017 10:05:03 AM Alan Stern wrote:
> On Tue, 25 Jul 2017, Rafael J. Wysocki wrote:
> 
> > From: Rafael J. Wysocki 
> > 
> > If HCD_DEAD(hcd) is "true" in check_root_hub_suspended(), it is
> > rather pointless to check the secondary root hub, so return early
> > then.
> > 
> > This actually fixes occasional suspend failures on one of my test
> > machines.
> > 
> > Signed-off-by: Rafael J. Wysocki 
> > ---
> >  drivers/usb/core/hcd-pci.c |3 +++
> >  1 file changed, 3 insertions(+)
> > 
> > Index: linux-pm/drivers/usb/core/hcd-pci.c
> > ===
> > --- linux-pm.orig/drivers/usb/core/hcd-pci.c
> > +++ linux-pm/drivers/usb/core/hcd-pci.c
> > @@ -427,6 +427,9 @@ static int check_root_hub_suspended(stru
> > dev_warn(dev, "Root hub is not suspended\n");
> > return -EBUSY;
> > }
> > +   if (HCD_DEAD(hcd))
> > +   return 0;
> > +
> > if (hcd->shared_hcd) {
> > hcd = hcd->shared_hcd;
> > if (HCD_RH_RUNNING(hcd)) {
> 
> While this is an okay solution, IMO it would be more reliable and more 
> general to have usb_hc_died() clear the HCD_FLAG_RH_RUNNING bit and set 
> the HCD_FLAG_DEAD bit in the shared hcd.  Right now it only does these 
> things for the primary.
> 
> Would you like to write and test a patch to do that?

I can do that.

> Incidentally, if this fixes occasional suspend failures on your test 
> machine, does that mean the test machine's host controller occasionally 
> dies?  Maybe that should be fixed too...

Yes, it does sometimes.

What appears to happen is that the platform does not initialize properly
sometimes after a reset and then the HCD dies during suspend.

So reproduction may be somewhat tricky, but oh well.

Thanks,
Rafael

--
To unsubscribe from this list: send the line "unsubscribe 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: musb: fix external abort on suspend

[Alan Stern]

On Tue, 25 Jul 2017, Johan Hovold wrote:

> On Mon, Jul 24, 2017 at 01:13:22PM -0400, Alan Stern wrote:
> > On Mon, 24 Jul 2017, Johan Hovold wrote:
> > 
> > > On Mon, Jul 24, 2017 at 10:38:41AM -0400, Alan Stern wrote:
> > > > On Mon, 24 Jul 2017, Johan Hovold wrote:
> > > > 
> > > > > Make sure that the controller is runtime resumed when system 
> > > > > suspending
> > > > > to avoid an external abort when accessing the interrupt registers:
> > > > > 
> > > > >   Unhandled fault: external abort on non-linefetch (0x1008) at 
> > > > > 0xd025840a
> > > > >   ...
> > > > >   [] (musb_default_readb) from [] 
> > > > > (musb_disable_interrupts+0x84/0xa8)
> > > > >   [] (musb_disable_interrupts) from [] 
> > > > > (musb_suspend+0x38/0xb8)
> > > > >   [] (musb_suspend) from [] 
> > > > > (platform_pm_suspend+0x3c/0x64)
> > > > > 
> > > > > This is easily reproduced on a BBB by enabling the peripheral port 
> > > > > only
> > > > > (as the host port may enable the shared clock) and keeping it
> > > > > disconnected so that the controller is runtime suspended. (Well, you
> > > > > would also need to the not-yet-merged am33xx-suspend patches by Dave
> > > > > Gerlach to be able to suspend the BBB.)
> > > > > 
> > > > > This is a regression that was introduced by commit 1c4d0b4e1806 ("usb:
> > > > > musb: Remove pm_runtime_set_irq_safe") which allowed the parent glue
> > > > > device to runtime suspend and thereby exposed a couple of older 
> > > > > issues:
> > > > > 
> > > > > Register accesses without explicitly making sure the controller is
> > > > > runtime resumed during suspend was first introduced by commit
> > > > > c338412b5ded ("usb: musb: unconditionally save and restore the context
> > > > > on suspend") in 3.14.
> > > > > 
> > > > > Commit a1fc1920 ("usb: musb: core: make sure musb is in 
> > > > > RPM_ACTIVE on
> > > > > resume") later started setting the RPM status to active during resume
> > > > > without first making sure that the parent was runtime resumed. This 
> > > > > was
> > > > > also implicitly relying on the parent always being active. Since 
> > > > > commit
> > > > > 71723f95463d ("PM / runtime: print error when activating a child to
> > > > > unactive parent") this now also results in following warning:
> > > > > 
> > > > >   musb-hdrc musb-hdrc.0: runtime PM trying to activate child device
> > > > > musb-hdrc.0 but parent (47401400.usb) is not active
> > > > 
> > > > I don't understand this.  Why wouldn't the parent be in RPM_ACTIVE at
> > > > this time?  After all, how could the system be expected to resume a
> > > > child device if its parent wasn't fully active?
> > > 
> > > The parent for a musb controller is a "glue" device (e.g. musb_dsps)
> > > which previously was always kept active, but that's no longer the case
> > > as mentioned above.
> > 
> > Even if the parent is not always kept active, it should still be active
> > during a system resume.  Starting from the time its resume routine
> > runs, it should remain at full power until the system resume is 
> > finished.
> 
> It is powered, but its runtime PM status does not reflect that, and that
> is the problem. This patch makes sure that the child, and thereby
> parent, are both runtime resumed throughout system suspend, but perhaps
> that should be done explicitly in the parent driver as well (more
> below).
> 
> > > In a system with two controllers (e.g. a Beagle Bone Black),
> > 
> > Do you mean a host controller and a peripheral controller?
> 
> Yes, in this example (the BBB has two OTG controllers), but it could
> just as well be two controllers in peripheral mode where one is active.
> 
> > > the host
> > > port may be active and keep the shared clock enabled (managed by the
> > > grandparent device). Thereby the external-abort crash can be avoided
> > > when suspending a disconnected (and runtime suspended) peripheral port.
> > 
> > So what?  There are lots of ways of avoiding such crashes.  (Disabling
> > the driver entirely, for example.)  They aren't relevant for this
> > discussion.
> 
> Perhaps I read your question too literally above; I'm trying to explain
> how you can end up with a runtime suspended parent during resume, without
> hitting the external abort during suspend, with the current kernel.
> 
> This can be done by keeping the sibling/cousin controller enabled, but
> could of course also have been achieved by preventing the grandparent
> (omap) device (which controls the clock) from suspending by other means.
> 
> I'm just describing how this could happen with the current
> implementation; I'm not claiming that the implementation is correct.
> 
> > > When the system is later resumed, you would hit that broken activation
> > > code of the runtime suspended device, with a likewise runtime suspended
> > > parent, and the warning would be printed.
> > 
> > Why would the parent be runtime suspended?  Why wouldn't it still be in
> > the full-power state, the way its own resume routine should have 

pixart optical mouse dont work

[Matthias Holl]

dear kernel hackers,

with the new kernel 4.13 my optical mouse from pixart dont work
but i can show it with lsusb

bus 007 device 003: id 093a:2510 pixart imaging,inc optical mouse

i changed nothing in my kernel .conf
with kernel 4.12, 4.11...i had no problems
i guess its something with the generic hid driver

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

[PATCH 1/2] usb: core: unlink urbs from the tail of the endpoint's urb_list

[Bin Liu]

While unlink an urb, if the urb has been programmed in the controller,
the controller driver might do some hw related actions to tear down the
urb.

Currently usb_hcd_flush_endpoint() passes each urb from the head of the
endpoint's urb_list to the controller driver, which could make the
controller driver think each urb has been programmed and take the
unnecessary actions for each urb.

This patch changes the behavior in usb_hcd_flush_endpoint() to pass the
urbs from the tail of the list, to avoid any unnecessary actions in an
controller driver.

Cc: sta...@vger.kernel.org # v4.4+
Acked-by: Alan Stern 
Signed-off-by: Bin Liu 
---
 drivers/usb/core/hcd.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index ab1bb3b538ac..193b1249976f 100644
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -1888,7 +1888,7 @@ void usb_hcd_flush_endpoint(struct usb_device *udev,
/* No more submits can occur */
spin_lock_irq(_urb_list_lock);
 rescan:
-   list_for_each_entry (urb, >urb_list, urb_list) {
+   list_for_each_entry_reverse(urb, >urb_list, urb_list) {
int is_in;
 
if (urb->unlinked)
-- 
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 2/2] usb: musb: fix tx fifo flush handling again

[Bin Liu]

commit 68fe05e2a451 ("usb: musb: fix tx fifo flush handling") drops the
1ms delay trying to solve the long disconnect time issue when
application queued many tx urbs. However, the 1ms delay is needed for
some use cases, for example, without the delay, reconnecting AR9271 WIFI
dongle no longer works if the connection is dropped from the AP.

So let's add back the 1ms delay in musb_h_tx_flush_fifo(), and solve the
long disconnect time problem with a separate patch for
usb_hcd_flush_endpoint().

Cc: sta...@vger.kernel.org # v4.4+
Signed-off-by: Bin Liu 
---
 drivers/usb/musb/musb_host.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
index 76decb8011eb..3344ffd5bb13 100644
--- a/drivers/usb/musb/musb_host.c
+++ b/drivers/usb/musb/musb_host.c
@@ -139,6 +139,7 @@ static void musb_h_tx_flush_fifo(struct musb_hw_ep *ep)
"Could not flush host TX%d fifo: csr: %04x\n",
ep->epnum, csr))
return;
+   mdelay(1);
}
 }
 
-- 
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 0/2] musb-fixes for v4.13-rc3

[Bin Liu]

Hi Greg,

Here is a musb fix for v4.13-rc3, for the re-enumeration issue exposed by
AM9271 WIFI dongle. Please let me know if any change is needed.

Regards,
-Bin.
---

Bin Liu (2):
  usb: core: unlink urbs from the tail of the endpoint's urb_list
  usb: musb: fix tx fifo flush handling again

 drivers/usb/core/hcd.c   | 2 +-
 drivers/usb/musb/musb_host.c | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

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

ERROR Transfer event TRB DMA ptr not part of current TD ep_index 0 comp_code 3

[Julian Lyubenov]

Hello,


I am trying to help somebody fix this longtime bug in xhci_hcd driver. (or more 
likely bug in ASMedia controller that we co
I will try provide as much information as I can.


My setup: I am using USB TV tuner card connected to ASMedia USB 3.1 port on 
mainboard.


00:00.0 USB controller: ASMedia Technology Inc. ASM1142 USB 3.1 Host Controller 
(prog-if 30 [XHCI])
        Subsystem: ASRock Incorporation ASM1142 USB 3.1 Host Controller
        Flags: bus master, fast devsel, latency 0, IRQ 34, NUMA node 0
        Memory at df20 (64-bit, non-prefetchable) [size=32K]
        Capabilities: [50] MSI: Enable- Count=1/8 Maskable- 64bit+
        Capabilities: [68] MSI-X: Enable+ Count=8 Masked-
        Capabilities: [78] Power Management version 3
        Capabilities: [80] Express Endpoint, MSI 00
        Capabilities: [100] Virtual Channel
        Capabilities: [200] Advanced Error Reporting
        Capabilities: [280] #19
        Capabilities: [300] Latency Tolerance Reporting
        Kernel driver in use: xhci_hcd
        Kernel modules: xhci_pci


Device is 1b21:1242


Sometimes after few hours, sometimes after 1-2 days - the xhci_hcd driver crash 
with similar error in dmesg:


[125235.391809] xhci_hcd :00:00.0: ERROR Transfer event TRB DMA ptr not 
part of current TD ep_index 0 comp_code 3
[125235.391843] xhci_hcd :00:00.0: Looking for event-dma 00021231a690 
trb-start 00021231a890 trb-end 00021231a8b0 seg-start 00021231a000 
seg-end 00021231aff0


It never happens if I connect my USB TV tuner card to the onboard Intel USB 3.0 
ports. Only with ASMedia USB 3.1 port.


There same issue is present at 
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1667750 but for different 
ASMedia controller.



I have logs: 
mount -t debugfs none /sys/kernel/debug
echo xhci-hcd >> /sys/kernel/debug/tracing/set_event
cat /sys/kernel/debug/tracing/trace


But people from launchpad told me they are not applicable.


Please help me to provide the necessary information to fix this issue.

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: [PATCH] PM / USB: hcd_pci: Skip secondary root hub check for HCD_DEAD()

[Alan Stern]

On Tue, 25 Jul 2017, Rafael J. Wysocki wrote:

> From: Rafael J. Wysocki 
> 
> If HCD_DEAD(hcd) is "true" in check_root_hub_suspended(), it is
> rather pointless to check the secondary root hub, so return early
> then.
> 
> This actually fixes occasional suspend failures on one of my test
> machines.
> 
> Signed-off-by: Rafael J. Wysocki 
> ---
>  drivers/usb/core/hcd-pci.c |3 +++
>  1 file changed, 3 insertions(+)
> 
> Index: linux-pm/drivers/usb/core/hcd-pci.c
> ===
> --- linux-pm.orig/drivers/usb/core/hcd-pci.c
> +++ linux-pm/drivers/usb/core/hcd-pci.c
> @@ -427,6 +427,9 @@ static int check_root_hub_suspended(stru
>   dev_warn(dev, "Root hub is not suspended\n");
>   return -EBUSY;
>   }
> + if (HCD_DEAD(hcd))
> + return 0;
> +
>   if (hcd->shared_hcd) {
>   hcd = hcd->shared_hcd;
>   if (HCD_RH_RUNNING(hcd)) {

While this is an okay solution, IMO it would be more reliable and more 
general to have usb_hc_died() clear the HCD_FLAG_RH_RUNNING bit and set 
the HCD_FLAG_DEAD bit in the shared hcd.  Right now it only does these 
things for the primary.

Would you like to write and test a patch to do that?

Incidentally, if this fixes occasional suspend failures on your test 
machine, does that mean the test machine's host controller occasionally 
dies?  Maybe that should be fixed too...

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: No Ethernet on Raspberry Pi 3 in v4.13-rc1

[Robin Murphy]

Hi Stefan,

On 25/07/17 06:19, Stefan Wahren wrote:
>>> With arm64 4.13-rc1 I get no eth0 device on Pi3 (openSUSE Tumbleweed).
>>> The v4.13-rc1 DT works okay with a 4.12 kernel.
>>>
>>> Possibly related:
>>>
>>> [   15.916350] OF: /soc/usb@7e98: could not get #phy-cells for /phy
>>>
>>> [   16.496662] usb 1-1: new high-speed USB device number 2 using dwc2
>>> [   16.502988] dwc2 3f98.usb: Cannot do DMA to address
>>> 0x335da400
>>
>> This is from SWIOTLB's map_single(), which means whatever device was
>> passed into dma_map_single() when mapping the URB had a DMA mask smaller
>> than 30 bits (or none at all), which sounds wrong and is almost
>> certainly the root of the problem (i.e. it probably wasn't the actual
>> HCD device described in DT and set up by of_dma_configure()). 
> 
> how can i figure out what's cause this issue (bcm283x or dwc2 specific)?
> 
> The dwc2 hcd already check the DMA mask on probe [1] and i never saw a 
> warning in error case.

I'll admit I'm a little stumped, since the two commits to dwc2 since
4.12 seem entirely inconsequential.

The only way I can see this happening is if the first dma_capable()
check in swiotlb_map_page() fails, and since swiotlb_force must be set
to SWIOTLB_NOFORCE in order to print the error later, and the address
and size look reasonable, that only leaves dev->dma_mask as the culprit.

>From the subsequent fallout (which on closer inspection looks more to do
with calling into uninitialised SWIOTLB state than the arm64 DMA code
actually doing anything wrong), I'd guess dev->dma_pfn_offset is
probably 0 as well, which further points to the wrong device. Maybe
something's changed lower down in the USB core? Turning on tracing and
booting with "tp_printk trace_event=swiotlb_bounced" on the command line
should shed a bit more light on what's going on.

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

Re: [PATCH 1/3] mfd: Add support for FTDI FT232H devices

[Anatolij Gustschin]

On Tue, 25 Jul 2017 13:49:08 +0200
Johan Hovold jo...@kernel.org wrote:

>On Wed, Jul 19, 2017 at 01:58:30PM +0200, Anatolij Gustschin wrote:
>> On Mon, 10 Jul 2017 14:52:10 +0200
>> Johan Hovold jo...@kernel.org wrote:
>>   
>> >On Thu, Jul 06, 2017 at 10:49:16PM +0200, Anatolij Gustschin wrote:  
>> >> Add USB part with common functions for USB-GPIO/I2C/SPI master
>> >> adapters. These allow communication with chip's control, transmit
>> >> and receive endpoints and will be used by various FT232H drivers.
>> >  
>> >> +static const struct mfd_cell ftdi_cells[] = {
>> >> + { .name = "ftdi-cbus-gpio", },
>> >> + { .name = "ftdi-mpsse-i2c", },
>> >> + { .name = "ftdi-mpsse-spi", },
>> >> + { .name = "ftdi-fifo-fpp-mgr", },
>> >> +};
>> >
>> >Correct me if I'm wrong, but aren't these modes really mutually
>> >exclusive, possibly with exception of cbus-gpio (some pins are at least
>> >available as GPIOs in MPSSE mode)? Then MFD is not is not the right fit
>> >here either.  
>> 
>> MPSSE and FIFO modes are mutually exclusive, but I'm not sure about
>> MPSSE and CBUS-GPIO. CBUS-GPIO didn't work as expected when I was
>> testing with MPSSE SPI master driver, but maybe it is a driver issue.  
>
>Yes, that wasn't clear to me either from just looking at the data
>sheets. MPSSE seems to deal with its GPIOs differently.

yes, the GPIOs are at different pins in MPSSE mode and these pins are
controlled via writes/reads to/from bulk endpoint with MPSSE commands.

>> FT245 FIFO and CBUS GPIO can be switched by a control request, when
>> FIFO mode is configured in the EEPROM.  
>
>Since the set_bitmode command is used to control the CBUS gpios, does
>that mean that they cannot be toggled independently while FIFO mode is
>in use (as the same command is used to set FIFO mode)?

yes.

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

Re: [PATCH 1/3] mfd: Add support for FTDI FT232H devices

[Anatolij Gustschin]

On Tue, 25 Jul 2017 13:52:35 +0200
Johan Hovold jo...@kernel.org wrote:

>On Wed, Jul 19, 2017 at 02:59:00PM +0200, Anatolij Gustschin wrote:
>> On Wed, 19 Jul 2017 10:59:34 +0200
>> Johan Hovold jo...@kernel.org wrote:  
>
>> >> And as David Laight already pointed out, your ftdi-fifo-fpp-mgr driver
>> >> seems too application specific for a generic chip like this.
>> >
>> >Of which this is one is one of the major.  
>> 
>> Thanks all for feedback. I'm still pondering how to interface the
>> fpga manager driver to FTDI FIFO driver.
>>   
>> >In short, your driver is much to application specific and is probably
>> >something that needs to be implemented in userspace using libftdi.  
>> 
>> I have a requirement to use the fpga manager framework, therefore the
>> kernel driver is needed. Our usage scenario is a multi stage fpga
>> configuration process, the first stage is a pre-configuration via
>> FTDI SPI/FIFO, all subsequent stages are also done by other fpga
>> manager drivers. libftdi based driver already existed for hardware
>> bring-up, now I need similar functionality as kernel fpga manager.  
>
>How are you even accessing these fpga-managers from userspace? I thought
>current interface was for in-kernel use only?

We have different possibilities to access to these fpga-managers from
userspace. On platforms with device-tree support there is a DT-Overlay
configfs interface for inserting a blob with configuration data and
fpga device description. After inserting the blob the fpga manager is
invoked automatically. There are also fpga-mgr debugfs config interface
patches in Altera linux-socfpga git tree for accessing from userspace.
I used them for initial testing, but now I'm using additional kernel
module with a single configuration interface for different managers.

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

Re: [PATCH 1/3] mfd: Add support for FTDI FT232H devices

[Johan Hovold]

On Wed, Jul 19, 2017 at 02:59:00PM +0200, Anatolij Gustschin wrote:
> On Wed, 19 Jul 2017 10:59:34 +0200
> Johan Hovold jo...@kernel.org wrote:

> >> And as David Laight already pointed out, your ftdi-fifo-fpp-mgr driver
> >> seems too application specific for a generic chip like this.  
> >
> >Of which this is one is one of the major.
> 
> Thanks all for feedback. I'm still pondering how to interface the
> fpga manager driver to FTDI FIFO driver.
> 
> >In short, your driver is much to application specific and is probably
> >something that needs to be implemented in userspace using libftdi.
> 
> I have a requirement to use the fpga manager framework, therefore the
> kernel driver is needed. Our usage scenario is a multi stage fpga
> configuration process, the first stage is a pre-configuration via
> FTDI SPI/FIFO, all subsequent stages are also done by other fpga
> manager drivers. libftdi based driver already existed for hardware
> bring-up, now I need similar functionality as kernel fpga manager.

How are you even accessing these fpga-managers from userspace? I thought
current interface was for in-kernel use only?

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

Re: [PATCH 1/3] mfd: Add support for FTDI FT232H devices

[Johan Hovold]

On Wed, Jul 19, 2017 at 01:58:30PM +0200, Anatolij Gustschin wrote:
> On Mon, 10 Jul 2017 14:52:10 +0200
> Johan Hovold jo...@kernel.org wrote:
> 
> >On Thu, Jul 06, 2017 at 10:49:16PM +0200, Anatolij Gustschin wrote:
> >> Add USB part with common functions for USB-GPIO/I2C/SPI master
> >> adapters. These allow communication with chip's control, transmit
> >> and receive endpoints and will be used by various FT232H drivers.  
> >
> >> +static const struct mfd_cell ftdi_cells[] = {
> >> +  { .name = "ftdi-cbus-gpio", },
> >> +  { .name = "ftdi-mpsse-i2c", },
> >> +  { .name = "ftdi-mpsse-spi", },
> >> +  { .name = "ftdi-fifo-fpp-mgr", },
> >> +};  
> >
> >Correct me if I'm wrong, but aren't these modes really mutually
> >exclusive, possibly with exception of cbus-gpio (some pins are at least
> >available as GPIOs in MPSSE mode)? Then MFD is not is not the right fit
> >here either.
> 
> MPSSE and FIFO modes are mutually exclusive, but I'm not sure about
> MPSSE and CBUS-GPIO. CBUS-GPIO didn't work as expected when I was
> testing with MPSSE SPI master driver, but maybe it is a driver issue.

Yes, that wasn't clear to me either from just looking at the data
sheets. MPSSE seems to deal with its GPIOs differently.

> FT245 FIFO and CBUS GPIO can be switched by a control request, when
> FIFO mode is configured in the EEPROM.

Since the set_bitmode command is used to control the CBUS gpios, does
that mean that they cannot be toggled independently while FIFO mode is
in use (as the same command is used to set FIFO mode)?

> >And as David Laight already pointed out, your ftdi-fifo-fpp-mgr driver
> >seems too application specific for a generic chip like this.
> 
> Yes, I agree. I'm thinking of a rework to add a FIFO driver instead
> and use it in the fpp-mgr driver. Is that the right direction? 

That sounds better, but I'm still not sure that we would be able to bind
it to devices with the default (generic) VID/PID.

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

Re: [PATCH] USB: serial: ftdi_sio: only bind FT232H if UART mode is enabled

[Johan Hovold]

On Wed, Jul 19, 2017 at 01:23:27PM +0200, Anatolij Gustschin wrote:
> On Wed, 19 Jul 2017 11:03:11 +0200
> Johan Hovold jo...@kernel.org wrote:
> 
> >On Thu, Jul 13, 2017 at 06:25:25PM +0200, Anatolij Gustschin wrote:
> >> On FT232H the interface mode can be configured in the EEPROM,
> >> and the async UART mode is configured by default. The chip is
> >> also in async UART mode if no EEPROM is connected.
> >> 
> >> Check the EEPROM configuration and do not bind as serial device
> >> when different interface mode is programmed in the EEPROM.  
> >
> >Thanks for the patch. As you may have inferred from my reply to your MFD
> >series, this won't be needed for a while still however.
> >
> >Also note that some people already use asynchronous FIFO mode using this
> >driver (also mentioned in the datasheets as an option) so only binding
> >in UART mode would be too restrictive.
> 
> You probably mean asynchronous bitbang mode, not asynchronous FIFO
> mode?

No, I really meant asynchronous FIFO mode. And as mentioned in the data
sheets that can be used with the normal serial (VCP) drivers on both
Linux and that other OS.

> This bitbang mode can always be set by sending a chip command
> (mentioned as software configured in the datasheets)
> Could you please point to code in this driver used for non-UART modes?
> I don't see such code by a quick glance. There are some quirks for
> various JTAG adapters to skip binding as serial port (the ftdi_sio
> driver is not used in JTAG operation modes then). Or do people use
> usual serial interface to send data in bitbang modes?

Exactly.

> Async and sync FIFO (FT245) modes however can only be configured via
> EEPROM settings, at least for FT232H.

Right.

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

Re: [PATCH v3 2/3] usb: phy: Add USB charger support

[Manu Gautam]

Hi,


On 7/25/2017 1:30 PM, Baolin Wang wrote:
> This patch introduces the usb charger support based on usb phy that
> makes an enhancement to a power driver. The basic conception of the
> usb charger is that, when one usb charger is added or removed by
> reporting from the extcon device state change, the usb charger will
> report to power user to set the current limitation.
>
> Power user can register a notifiee on the usb phy by issuing
> usb_register_notifier() to get notified by charger status changes
> or charger current changes.

Why can't we use power_supply framework for this?
Power user can register usb power_supply and USB PHY driver
can update charging current using - power_supply_set_property().



> we can notify what current to be drawn to power user according to
> different charger type, and now we have 2 methods to get charger type.
> One is get charger type from extcon subsystem, which also means the
> charger state changes. Another is we can get the charger type from
> USB controller detecting or PMIC detecting, and the charger state
> changes should be told by issuing usb_phy_set_charger_state().
>
> Signed-off-by: Baolin Wang 
> ---
>  drivers/usb/phy/phy.c   |  272 
> +++
>  include/linux/usb/phy.h |   49 +

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

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

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

[Sebastian Reichel]

Hi,

On Tue, Jul 25, 2017 at 04:00:01PM +0800, Baolin Wang wrote:
> Integrate with the newly added USB charger interface to limit the current
> we draw from the USB input based on the input device configuration
> identified by the USB stack, allowing us to charge more quickly from high
> current inputs without drawing more current than specified from others.
> 
> Signed-off-by: Mark Brown 
> Signed-off-by: Baolin Wang 
> ---
>  Documentation/devicetree/bindings/mfd/wm831x.txt |1 +
>  drivers/power/supply/wm831x_power.c  |   58 
> ++
>  2 files changed, 59 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/mfd/wm831x.txt 
> b/Documentation/devicetree/bindings/mfd/wm831x.txt
> index 9f8b743..4e3bc07 100644
> --- a/Documentation/devicetree/bindings/mfd/wm831x.txt
> +++ b/Documentation/devicetree/bindings/mfd/wm831x.txt
> @@ -31,6 +31,7 @@ Required properties:
>  ../interrupt-controller/interrupts.txt
>  
>  Optional sub-nodes:
> +  - usb-phy : Contains a phandle to the USB PHY.
>- regulators : Contains sub-nodes for each of the regulators supplied by
>  the device. The regulators are bound using their names listed below:
>  
> diff --git a/drivers/power/supply/wm831x_power.c 
> b/drivers/power/supply/wm831x_power.c
> index 7082301..d3948ab 100644
> --- a/drivers/power/supply/wm831x_power.c
> +++ b/drivers/power/supply/wm831x_power.c
> @@ -13,6 +13,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
> @@ -31,6 +32,8 @@ struct wm831x_power {
>   char usb_name[20];
>   char battery_name[20];
>   bool have_battery;
> + struct usb_phy *usb_phy;
> + struct notifier_block usb_notify;
>  };
>  
>  static int wm831x_power_check_online(struct wm831x *wm831x, int supply,
> @@ -125,6 +128,43 @@ static int wm831x_usb_get_prop(struct power_supply *psy,
>   POWER_SUPPLY_PROP_VOLTAGE_NOW,
>  };
>  
> +/* In milliamps */
> +static const unsigned int wm831x_usb_limits[] = {
> + 0,
> + 2,
> + 100,
> + 500,
> + 900,
> + 1500,
> + 1800,
> + 550,
> +};
> +
> +static int wm831x_usb_limit_change(struct notifier_block *nb,
> +unsigned long limit, void *data)
> +{
> + struct wm831x_power *wm831x_power = container_of(nb,
> +  struct wm831x_power,
> +  usb_notify);
> + unsigned int i, best;
> +
> + /* Find the highest supported limit */
> + best = 0;
> + for (i = 0; i < ARRAY_SIZE(wm831x_usb_limits); i++) {
> + if (limit >= wm831x_usb_limits[i] &&
> + wm831x_usb_limits[best] < wm831x_usb_limits[i])
> + best = i;
> + }
> +
> + dev_dbg(wm831x_power->wm831x->dev,
> + "Limiting USB current to %umA", wm831x_usb_limits[best]);
> +
> + wm831x_set_bits(wm831x_power->wm831x, WM831X_POWER_STATE,
> + WM831X_USB_ILIM_MASK, best);
> +
> + return 0;
> +}
> +
>  /*
>   *   Battery properties
>   */
> @@ -607,6 +647,19 @@ static int wm831x_power_probe(struct platform_device 
> *pdev)
>   }
>   }
>  
> + power->usb_phy = devm_usb_get_phy_by_phandle(>dev,
> +  "usb-phy", 0);
> + if (!IS_ERR(power->usb_phy)) {
> + power->usb_notify.notifier_call = wm831x_usb_limit_change;
> + ret = usb_register_notifier(power->usb_phy,
> + >usb_notify);
> + if (ret) {
> + dev_err(>dev, "Failed to register notifier: %d\n",
> + ret);
> + goto err_bat_irq;
> + }
> + }

No error handling for power->usb_phy? I think you should bail out
for all errors except for "not defined in DT". Especially I would
expect probe defer handling in case the power supply driver is
loaded before the phy driver.

>   return ret;
>  
>  err_bat_irq:
> @@ -637,6 +690,11 @@ static int wm831x_power_remove(struct platform_device 
> *pdev)
>   struct wm831x *wm831x = wm831x_power->wm831x;
>   int irq, i;
>  
> + if (!IS_ERR(wm831x_power->usb_phy)) {
> + usb_unregister_notifier(wm831x_power->usb_phy,
> + _power->usb_notify);
> + }
> +
>   for (i = 0; i < ARRAY_SIZE(wm831x_bat_irqs); i++) {
>   irq = wm831x_irq(wm831x, 
>platform_get_irq_byname(pdev,

-- Sebastian


signature.asc
Description: PGP signature

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

[Charles Keepax]

On Tue, Jul 25, 2017 at 04:00:01PM +0800, Baolin Wang wrote:
> Integrate with the newly added USB charger interface to limit the current
> we draw from the USB input based on the input device configuration
> identified by the USB stack, allowing us to charge more quickly from high
> current inputs without drawing more current than specified from others.
> 
> Signed-off-by: Mark Brown 
> Signed-off-by: Baolin Wang 
> ---

Acked-by: Charles Keepax 

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

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

[Lee Jones]

On Tue, 25 Jul 2017, Baolin Wang wrote:

> Integrate with the newly added USB charger interface to limit the current
> we draw from the USB input based on the input device configuration
> identified by the USB stack, allowing us to charge more quickly from high
> current inputs without drawing more current than specified from others.
> 
> Signed-off-by: Mark Brown 
> Signed-off-by: Baolin Wang 
> ---
>  Documentation/devicetree/bindings/mfd/wm831x.txt |1 +

Acked-by: Lee Jones 

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: v4.13-rc2: usb mouse stopped working?

[Mikael Pettersson]

Jiri Kosina writes:
 > On Mon, 24 Jul 2017, Pavel Machek wrote:
 > 
 > > On thinkpad x220, USB mouse stopped working in v4.13-rc2. v4.12 was
 > > ok, iirc.
 > > 
 > > Now, USB mouse is so common hw that I may have something wrong in my
 > > config...? But I did not change anything there.
 > 
 > Well, your particular USB mouse requires an always-poll quirk, so it's not 
 > *that* common; therefore ...
 > 
 > > In v4.9:
 > > 
 > > [   87.064408] input: Logitech USB Optical Mouse as
 > > /devices/pci:00/:00:1d.0/usb2/2-1/2-1.1/2-1.1.1/2-1.1.1.1/2-1.1.1.1:1.0/0003:046D:C05A.0005/input/input18
 > > [   87.065951] hid-generic 0003:046D:C05A.0005: input,hidraw0: USB HID
 > > v1.11 Mouse [Logitech USB Optical Mouse] on
 > > usb-:00:1d.0-1.1.1.1/input0
 > > pavel@duo:~$
 > > 
 > > v4.13-rc2:
 > > 
 > > [   87.886810] usb 2-1.1.1.1: new low-speed USB device number 10 using 
 > > ehci-pci
 > > [   88.019543] usb 2-1.1.1.1: New USB device found, idVendor=046d, 
 > > idProduct=c05a
 > > [   88.019561] usb 2-1.1.1.1: New USB device strings: Mfr=1, Product=2, 
 > > SerialNumber=0
 > > [   88.019572] usb 2-1.1.1.1: Product: USB Optical Mouse
 > > [   88.019581] usb 2-1.1.1.1: Manufacturer: Logitech
 > > [   88.027276] input: Logitech USB Optical Mouse as 
 > > /devices/pci:00/:00:1d.0/usb2/2-1/2-1.1/2-1.1.1/2-1.1.1.1/2-1.1.1.1:1.0/0003:046D:C05A.0005/input/input18
 > > [   88.027825] hid-generic 0003:046D:C05A.0005: input,hidraw1: USB HID
 > > v1.11 Mouse [Logitech USB Optical Mouse] on
 > > usb-:00:1d.0-1.1.1.1/input0
 > 
 > ... this is most likely caused by e399396a6b0, and fix for that is queued 
 > in hid.git as cf601774c9f ("HID: usbhid: fix "always poll" quirk"); I'm 
 > planning to send it to Linus' tomorrow, but if you can double-check that 
 > it does fix your issue as well, that'd be appreciated.

I had a similar problem (a Logitech USB Optical Mouse being completely dead
with 4.13-rc[12]), and cf601774c9f fixed it.

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

[PATCH 2/3] usb: mtu3: clear u1/u2_enable to 0 in mtu3_gadget_reset

[Chunfeng Yun]

when the device is reset by host, the status of u1_enable and
u2_enable should also be restored to default value.

Signed-off-by: Chunfeng Yun 
---
 drivers/usb/mtu3/mtu3_gadget.c |2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/usb/mtu3/mtu3_gadget.c b/drivers/usb/mtu3/mtu3_gadget.c
index a4ad67c..434fca5 100644
--- a/drivers/usb/mtu3/mtu3_gadget.c
+++ b/drivers/usb/mtu3/mtu3_gadget.c
@@ -728,5 +728,7 @@ void mtu3_gadget_reset(struct mtu3 *mtu)
mtu->address = 0;
mtu->ep0_state = MU3D_EP0_STATE_SETUP;
mtu->may_wakeup = 0;
+   mtu->u1_enable = 0;
+   mtu->u2_enable = 0;
mtu->delayed_status = false;
 }
-- 
1.7.9.5

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

[PATCH 3/3] usb: mtu3: fix ip sleep auto-exit issue when enable DRD mode

[Chunfeng Yun]

Ip sleep will auto exit if vbus comparison circuit of u2 phy is
disabled when system tries to enter suspend mode, so get vbus-valid
status from mac but not from u2 phy when enable DRD mode to fix
the issue.

Signed-off-by: Chunfeng Yun 
---
 drivers/usb/mtu3/mtu3_hw_regs.h |4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/mtu3/mtu3_hw_regs.h b/drivers/usb/mtu3/mtu3_hw_regs.h
index 2123672..06b2966 100644
--- a/drivers/usb/mtu3/mtu3_hw_regs.h
+++ b/drivers/usb/mtu3/mtu3_hw_regs.h
@@ -462,10 +462,12 @@
 #define SSUSB_U3_PORT_DIS  BIT(0)
 
 /* U3D_SSUSB_U2_CTRL_0P */
+#define SSUSB_U2_PORT_VBUSVALIDBIT(9)
 #define SSUSB_U2_PORT_OTG_SEL  BIT(7)
-#define SSUSB_U2_PORT_HOST_SEL BIT(2)
+#define SSUSB_U2_PORT_HOST BIT(2)
 #define SSUSB_U2_PORT_PDN  BIT(1)
 #define SSUSB_U2_PORT_DIS  BIT(0)
+#define SSUSB_U2_PORT_HOST_SEL (SSUSB_U2_PORT_VBUSVALID | SSUSB_U2_PORT_HOST)
 
 /* U3D_SSUSB_DEV_RST_CTRL */
 #define SSUSB_DEV_SW_RST   BIT(0)
-- 
1.7.9.5

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

[PATCH 1/3] usb: mtu3: handle delayed status of the control transfer

[Chunfeng Yun]

Add the delayed status handling. This is used by mass storage etc to
gain some extra time to setup its internal status before it can proceed
further requests, and once the gadget is ready, it will enqueue an
empty packet which is used for synchronization.
The issue may happen on some FGPA platform with very low cpu frequency.

Signed-off-by: Chunfeng Yun 
---
 drivers/usb/mtu3/mtu3.h|2 ++
 drivers/usb/mtu3/mtu3_gadget.c |2 ++
 drivers/usb/mtu3/mtu3_gadget_ep0.c |   23 ---
 3 files changed, 24 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/mtu3/mtu3.h b/drivers/usb/mtu3/mtu3.h
index 7b6dc23..b26fffc 100644
--- a/drivers/usb/mtu3/mtu3.h
+++ b/drivers/usb/mtu3/mtu3.h
@@ -288,6 +288,7 @@ static inline struct ssusb_mtk *dev_to_ssusb(struct device 
*dev)
  * MTU3_U3_IP_SLOT_DEFAULT for U3 IP
  * @may_wakeup: means device's remote wakeup is enabled
  * @is_self_powered: is reported in device status and the config descriptor
+ * @delayed_status: true when function drivers ask for delayed status
  * @ep0_req: dummy request used while handling standard USB requests
  * for GET_STATUS and SET_SEL
  * @setup_buf: ep0 response buffer for GET_STATUS and SET_SEL requests
@@ -327,6 +328,7 @@ struct mtu3 {
unsigned u1_enable:1;
unsigned u2_enable:1;
unsigned is_u3_ip:1;
+   unsigned delayed_status:1;
 
u8 address;
u8 test_mode_nr;
diff --git a/drivers/usb/mtu3/mtu3_gadget.c b/drivers/usb/mtu3/mtu3_gadget.c
index 9dd2441..a4ad67c 100644
--- a/drivers/usb/mtu3/mtu3_gadget.c
+++ b/drivers/usb/mtu3/mtu3_gadget.c
@@ -663,6 +663,7 @@ int mtu3_gadget_setup(struct mtu3 *mtu)
mtu->g.sg_supported = 0;
mtu->g.name = MTU3_DRIVER_NAME;
mtu->is_active = 0;
+   mtu->delayed_status = false;
 
mtu3_gadget_init_eps(mtu);
 
@@ -727,4 +728,5 @@ void mtu3_gadget_reset(struct mtu3 *mtu)
mtu->address = 0;
mtu->ep0_state = MU3D_EP0_STATE_SETUP;
mtu->may_wakeup = 0;
+   mtu->delayed_status = false;
 }
diff --git a/drivers/usb/mtu3/mtu3_gadget_ep0.c 
b/drivers/usb/mtu3/mtu3_gadget_ep0.c
index 2d7427b..958d74d 100644
--- a/drivers/usb/mtu3/mtu3_gadget_ep0.c
+++ b/drivers/usb/mtu3/mtu3_gadget_ep0.c
@@ -16,6 +16,8 @@
  *
  */
 
+#include 
+
 #include "mtu3.h"
 
 /* ep0 is always mtu3->in_eps[0] */
@@ -150,6 +152,7 @@ static void ep0_stall_set(struct mtu3_ep *mep0, bool set, 
u32 pktrdy)
csr = (csr & ~EP0_SENDSTALL) | EP0_SENTSTALL;
mtu3_writel(mtu->mac_base, U3D_EP0CSR, csr);
 
+   mtu->delayed_status = false;
mtu->ep0_state = MU3D_EP0_STATE_SETUP;
 
dev_dbg(mtu->dev, "ep0: %s STALL, ep0_state: %s\n",
@@ -656,6 +659,9 @@ static int ep0_handle_setup(struct mtu3 *mtu)
 finish:
if (mtu->test_mode) {
;   /* nothing to do */
+   } else if (handled == USB_GADGET_DELAYED_STATUS) {
+   /* handle the delay STATUS phase till receive ep_queue on ep0 */
+   mtu->delayed_status = true;
} else if (le16_to_cpu(setup.wLength) == 0) { /* no data stage */
 
mtu3_writel(mbase, U3D_EP0CSR,
@@ -775,9 +781,6 @@ static int ep0_queue(struct mtu3_ep *mep, struct 
mtu3_request *mreq)
dev_dbg(mtu->dev, "%s %s (ep0_state: %s), len#%d\n", __func__,
mep->name, decode_ep0_state(mtu), mreq->request.length);
 
-   if (!list_empty(>req_list))
-   return -EBUSY;
-
switch (mtu->ep0_state) {
case MU3D_EP0_STATE_SETUP:
case MU3D_EP0_STATE_RX: /* control-OUT data */
@@ -789,6 +792,20 @@ static int ep0_queue(struct mtu3_ep *mep, struct 
mtu3_request *mreq)
return -EINVAL;
}
 
+   if (mtu->delayed_status) {
+   u32 csr;
+
+   mtu->delayed_status = false;
+   csr = mtu3_readl(mtu->mac_base, U3D_EP0CSR) & EP0_W1C_BITS;
+   csr |= EP0_SETUPPKTRDY | EP0_DATAEND;
+   mtu3_writel(mtu->mac_base, U3D_EP0CSR, csr);
+   /* needn't giveback the request for handling delay STATUS */
+   return 0;
+   }
+
+   if (!list_empty(>req_list))
+   return -EBUSY;
+
list_add_tail(>list, >req_list);
 
/* sequence #1, IN ... start writing the data */
-- 
1.7.9.5

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

[PATCH v3 0/3] Introduce USB charger support in USB phy

[Baolin Wang]

Currently the Linux kernel does not provide any standard integration of this
feature that integrates the USB subsystem with the system power regulation
provided by PMICs meaning that either vendors must add this in their kernels
or USB gadget devices based on Linux (such as mobile phones) may not behave
as they should. Thus provide a standard USB charger support in USB phy core
for doing this in kernel.

Now introduce one user with wm831x_power to support and test the usb charger.
In future we will also cnvert below power drivers:
drivers/power/supply/axp288_charger.c
drivers/power/supply/bq24190_charger.c
drivers/power/supply/charger-manager.c
drivers/power/supply/qcom_smbb.c

Changes since v1:
 - Fix building errors.
Changes since v2:
 - Add DT binding documentation for wm831x_power driver.
 - Change 'usb-phy' as one optional property for wm831x_power driver.

Baolin Wang (3):
  include: uapi: usb: Introduce USB charger type and state definition
  usb: phy: Add USB charger support
  power: wm831x_power: Support USB charger current limit management

 Documentation/devicetree/bindings/mfd/wm831x.txt |1 +
 drivers/power/supply/wm831x_power.c  |   58 +
 drivers/usb/phy/phy.c|  272 ++
 include/linux/usb/phy.h  |   49 
 include/uapi/linux/usb/charger.h |   31 +++
 5 files changed, 411 insertions(+)
 create mode 100644 include/uapi/linux/usb/charger.h

-- 
1.7.9.5

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

[PATCH v3 1/3] include: uapi: usb: Introduce USB charger type and state definition

[Baolin Wang]

Introducing USB charger type and state definition can help
to support USB charging which will be added in USB phy core.

Signed-off-by: Baolin Wang 
---
 include/uapi/linux/usb/charger.h |   31 +++
 1 file changed, 31 insertions(+)
 create mode 100644 include/uapi/linux/usb/charger.h

diff --git a/include/uapi/linux/usb/charger.h b/include/uapi/linux/usb/charger.h
new file mode 100644
index 000..5f72af3
--- /dev/null
+++ b/include/uapi/linux/usb/charger.h
@@ -0,0 +1,31 @@
+/*
+ * This file defines the USB charger type and state that are needed for
+ * USB device APIs.
+ */
+
+#ifndef _UAPI__LINUX_USB_CHARGER_H
+#define _UAPI__LINUX_USB_CHARGER_H
+
+/*
+ * USB charger type:
+ * SDP (Standard Downstream Port)
+ * DCP (Dedicated Charging Port)
+ * CDP (Charging Downstream Port)
+ * ACA (Accessory Charger Adapters)
+ */
+enum usb_charger_type {
+   UNKNOWN_TYPE,
+   SDP_TYPE,
+   DCP_TYPE,
+   CDP_TYPE,
+   ACA_TYPE,
+};
+
+/* USB charger state */
+enum usb_charger_state {
+   USB_CHARGER_DEFAULT,
+   USB_CHARGER_PRESENT,
+   USB_CHARGER_ABSENT,
+};
+
+#endif /* _UAPI__LINUX_USB_CHARGER_H */
-- 
1.7.9.5

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

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

[Baolin Wang]

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

Signed-off-by: Mark Brown 
Signed-off-by: Baolin Wang 
---
 Documentation/devicetree/bindings/mfd/wm831x.txt |1 +
 drivers/power/supply/wm831x_power.c  |   58 ++
 2 files changed, 59 insertions(+)

diff --git a/Documentation/devicetree/bindings/mfd/wm831x.txt 
b/Documentation/devicetree/bindings/mfd/wm831x.txt
index 9f8b743..4e3bc07 100644
--- a/Documentation/devicetree/bindings/mfd/wm831x.txt
+++ b/Documentation/devicetree/bindings/mfd/wm831x.txt
@@ -31,6 +31,7 @@ Required properties:
 ../interrupt-controller/interrupts.txt
 
 Optional sub-nodes:
+  - usb-phy : Contains a phandle to the USB PHY.
   - regulators : Contains sub-nodes for each of the regulators supplied by
 the device. The regulators are bound using their names listed below:
 
diff --git a/drivers/power/supply/wm831x_power.c 
b/drivers/power/supply/wm831x_power.c
index 7082301..d3948ab 100644
--- a/drivers/power/supply/wm831x_power.c
+++ b/drivers/power/supply/wm831x_power.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -31,6 +32,8 @@ struct wm831x_power {
char usb_name[20];
char battery_name[20];
bool have_battery;
+   struct usb_phy *usb_phy;
+   struct notifier_block usb_notify;
 };
 
 static int wm831x_power_check_online(struct wm831x *wm831x, int supply,
@@ -125,6 +128,43 @@ static int wm831x_usb_get_prop(struct power_supply *psy,
POWER_SUPPLY_PROP_VOLTAGE_NOW,
 };
 
+/* In milliamps */
+static const unsigned int wm831x_usb_limits[] = {
+   0,
+   2,
+   100,
+   500,
+   900,
+   1500,
+   1800,
+   550,
+};
+
+static int wm831x_usb_limit_change(struct notifier_block *nb,
+  unsigned long limit, void *data)
+{
+   struct wm831x_power *wm831x_power = container_of(nb,
+struct wm831x_power,
+usb_notify);
+   unsigned int i, best;
+
+   /* Find the highest supported limit */
+   best = 0;
+   for (i = 0; i < ARRAY_SIZE(wm831x_usb_limits); i++) {
+   if (limit >= wm831x_usb_limits[i] &&
+   wm831x_usb_limits[best] < wm831x_usb_limits[i])
+   best = i;
+   }
+
+   dev_dbg(wm831x_power->wm831x->dev,
+   "Limiting USB current to %umA", wm831x_usb_limits[best]);
+
+   wm831x_set_bits(wm831x_power->wm831x, WM831X_POWER_STATE,
+   WM831X_USB_ILIM_MASK, best);
+
+   return 0;
+}
+
 /*
  * Battery properties
  */
@@ -607,6 +647,19 @@ static int wm831x_power_probe(struct platform_device *pdev)
}
}
 
+   power->usb_phy = devm_usb_get_phy_by_phandle(>dev,
+"usb-phy", 0);
+   if (!IS_ERR(power->usb_phy)) {
+   power->usb_notify.notifier_call = wm831x_usb_limit_change;
+   ret = usb_register_notifier(power->usb_phy,
+   >usb_notify);
+   if (ret) {
+   dev_err(>dev, "Failed to register notifier: %d\n",
+   ret);
+   goto err_bat_irq;
+   }
+   }
+
return ret;
 
 err_bat_irq:
@@ -637,6 +690,11 @@ static int wm831x_power_remove(struct platform_device 
*pdev)
struct wm831x *wm831x = wm831x_power->wm831x;
int irq, i;
 
+   if (!IS_ERR(wm831x_power->usb_phy)) {
+   usb_unregister_notifier(wm831x_power->usb_phy,
+   _power->usb_notify);
+   }
+
for (i = 0; i < ARRAY_SIZE(wm831x_bat_irqs); i++) {
irq = wm831x_irq(wm831x, 
 platform_get_irq_byname(pdev,
-- 
1.7.9.5

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

[PATCH v3 2/3] usb: phy: Add USB charger support

[Baolin Wang]

This patch introduces the usb charger support based on usb phy that
makes an enhancement to a power driver. The basic conception of the
usb charger is that, when one usb charger is added or removed by
reporting from the extcon device state change, the usb charger will
report to power user to set the current limitation.

Power user can register a notifiee on the usb phy by issuing
usb_register_notifier() to get notified by charger status changes
or charger current changes.

we can notify what current to be drawn to power user according to
different charger type, and now we have 2 methods to get charger type.
One is get charger type from extcon subsystem, which also means the
charger state changes. Another is we can get the charger type from
USB controller detecting or PMIC detecting, and the charger state
changes should be told by issuing usb_phy_set_charger_state().

Signed-off-by: Baolin Wang 
---
 drivers/usb/phy/phy.c   |  272 +++
 include/linux/usb/phy.h |   49 +
 2 files changed, 321 insertions(+)

diff --git a/drivers/usb/phy/phy.c b/drivers/usb/phy/phy.c
index 032f5af..2dc48bb 100644
--- a/drivers/usb/phy/phy.c
+++ b/drivers/usb/phy/phy.c
@@ -18,6 +18,18 @@
 
 #include 
 
+/* Default current range by charger type. */
+#define DEFAULT_SDP_CUR_MIN2
+#define DEFAULT_SDP_CUR_MAX500
+#define DEFAULT_SDP_CUR_MIN_SS 150
+#define DEFAULT_SDP_CUR_MAX_SS 900
+#define DEFAULT_DCP_CUR_MIN500
+#define DEFAULT_DCP_CUR_MAX5000
+#define DEFAULT_CDP_CUR_MIN1500
+#define DEFAULT_CDP_CUR_MAX5000
+#define DEFAULT_ACA_CUR_MIN1500
+#define DEFAULT_ACA_CUR_MAX5000
+
 static LIST_HEAD(phy_list);
 static LIST_HEAD(phy_bind_list);
 static DEFINE_SPINLOCK(phy_lock);
@@ -77,6 +89,221 @@ static struct usb_phy *__of_usb_find_phy(struct device_node 
*node)
return ERR_PTR(-EPROBE_DEFER);
 }
 
+static void usb_phy_set_default_current(struct usb_phy *usb_phy)
+{
+   usb_phy->chg_cur.sdp_min = DEFAULT_SDP_CUR_MIN;
+   usb_phy->chg_cur.sdp_max = DEFAULT_SDP_CUR_MAX;
+   usb_phy->chg_cur.dcp_min = DEFAULT_DCP_CUR_MIN;
+   usb_phy->chg_cur.dcp_max = DEFAULT_DCP_CUR_MAX;
+   usb_phy->chg_cur.cdp_min = DEFAULT_CDP_CUR_MIN;
+   usb_phy->chg_cur.cdp_max = DEFAULT_CDP_CUR_MAX;
+   usb_phy->chg_cur.aca_min = DEFAULT_ACA_CUR_MIN;
+   usb_phy->chg_cur.aca_max = DEFAULT_ACA_CUR_MAX;
+}
+
+/**
+ * usb_phy_notify_charger_work - notify the USB charger state
+ * @work - the charger work to notify the USB charger state
+ *
+ * This work can be issued when USB charger state has been changed or
+ * USB charger current has been changed, then we can notify the current
+ * what can be drawn to power user and the charger state to userspace.
+ *
+ * If we get the charger type from extcon subsystem, we can notify the
+ * charger state to power user automatically by usb_phy_get_charger_type()
+ * issuing from extcon subsystem.
+ *
+ * If we get the charger type from ->charger_detect() instead of extcon
+ * subsystem, the usb phy driver should issue usb_phy_set_charger_state()
+ * to set charger state when the charger state has been changed.
+ */
+static void usb_phy_notify_charger_work(struct work_struct *work)
+{
+   struct usb_phy *usb_phy = container_of(work, struct usb_phy, chg_work);
+   char uchger_state[50] = { 0 };
+   char *envp[] = { uchger_state, NULL };
+   unsigned int min, max;
+
+   switch (usb_phy->chg_state) {
+   case USB_CHARGER_PRESENT:
+   usb_phy_get_charger_current(usb_phy, , );
+
+   atomic_notifier_call_chain(_phy->notifier, max, usb_phy);
+   snprintf(uchger_state, ARRAY_SIZE(uchger_state),
+"USB_CHARGER_STATE=%s", "USB_CHARGER_PRESENT");
+   break;
+   case USB_CHARGER_ABSENT:
+   usb_phy_set_default_current(usb_phy);
+
+   atomic_notifier_call_chain(_phy->notifier, 0, usb_phy);
+   snprintf(uchger_state, ARRAY_SIZE(uchger_state),
+"USB_CHARGER_STATE=%s", "USB_CHARGER_ABSENT");
+   break;
+   default:
+   dev_warn(usb_phy->dev, "Unknown USB charger state: %d\n",
+usb_phy->chg_state);
+   return;
+   }
+
+   kobject_uevent_env(_phy->dev->kobj, KOBJ_CHANGE, envp);
+}
+
+static void __usb_phy_get_charger_type(struct usb_phy *usb_phy)
+{
+   if (extcon_get_state(usb_phy->edev, EXTCON_CHG_USB_SDP) > 0) {
+   usb_phy->chg_type = SDP_TYPE;
+   usb_phy->chg_state = USB_CHARGER_PRESENT;
+   } else if (extcon_get_state(usb_phy->edev, EXTCON_CHG_USB_CDP) > 0) {
+   usb_phy->chg_type = CDP_TYPE;
+   usb_phy->chg_state = USB_CHARGER_PRESENT;
+   } else if (extcon_get_state(usb_phy->edev, EXTCON_CHG_USB_DCP) > 0) {
+   usb_phy->chg_type = DCP_TYPE;
+   usb_phy->chg_state = 

Re: [PATCH] USB: musb: fix external abort on suspend

[Johan Hovold]

On Mon, Jul 24, 2017 at 01:13:22PM -0400, Alan Stern wrote:
> On Mon, 24 Jul 2017, Johan Hovold wrote:
> 
> > On Mon, Jul 24, 2017 at 10:38:41AM -0400, Alan Stern wrote:
> > > On Mon, 24 Jul 2017, Johan Hovold wrote:
> > > 
> > > > Make sure that the controller is runtime resumed when system suspending
> > > > to avoid an external abort when accessing the interrupt registers:
> > > > 
> > > >   Unhandled fault: external abort on non-linefetch (0x1008) at 
> > > > 0xd025840a
> > > >   ...
> > > >   [] (musb_default_readb) from [] 
> > > > (musb_disable_interrupts+0x84/0xa8)
> > > >   [] (musb_disable_interrupts) from [] 
> > > > (musb_suspend+0x38/0xb8)
> > > >   [] (musb_suspend) from [] 
> > > > (platform_pm_suspend+0x3c/0x64)
> > > > 
> > > > This is easily reproduced on a BBB by enabling the peripheral port only
> > > > (as the host port may enable the shared clock) and keeping it
> > > > disconnected so that the controller is runtime suspended. (Well, you
> > > > would also need to the not-yet-merged am33xx-suspend patches by Dave
> > > > Gerlach to be able to suspend the BBB.)
> > > > 
> > > > This is a regression that was introduced by commit 1c4d0b4e1806 ("usb:
> > > > musb: Remove pm_runtime_set_irq_safe") which allowed the parent glue
> > > > device to runtime suspend and thereby exposed a couple of older issues:
> > > > 
> > > > Register accesses without explicitly making sure the controller is
> > > > runtime resumed during suspend was first introduced by commit
> > > > c338412b5ded ("usb: musb: unconditionally save and restore the context
> > > > on suspend") in 3.14.
> > > > 
> > > > Commit a1fc1920 ("usb: musb: core: make sure musb is in RPM_ACTIVE 
> > > > on
> > > > resume") later started setting the RPM status to active during resume
> > > > without first making sure that the parent was runtime resumed. This was
> > > > also implicitly relying on the parent always being active. Since commit
> > > > 71723f95463d ("PM / runtime: print error when activating a child to
> > > > unactive parent") this now also results in following warning:
> > > > 
> > > >   musb-hdrc musb-hdrc.0: runtime PM trying to activate child device
> > > > musb-hdrc.0 but parent (47401400.usb) is not active
> > > 
> > > I don't understand this.  Why wouldn't the parent be in RPM_ACTIVE at
> > > this time?  After all, how could the system be expected to resume a
> > > child device if its parent wasn't fully active?
> > 
> > The parent for a musb controller is a "glue" device (e.g. musb_dsps)
> > which previously was always kept active, but that's no longer the case
> > as mentioned above.
> 
> Even if the parent is not always kept active, it should still be active
> during a system resume.  Starting from the time its resume routine
> runs, it should remain at full power until the system resume is 
> finished.

It is powered, but its runtime PM status does not reflect that, and that
is the problem. This patch makes sure that the child, and thereby
parent, are both runtime resumed throughout system suspend, but perhaps
that should be done explicitly in the parent driver as well (more
below).

> > In a system with two controllers (e.g. a Beagle Bone Black),
> 
> Do you mean a host controller and a peripheral controller?

Yes, in this example (the BBB has two OTG controllers), but it could
just as well be two controllers in peripheral mode where one is active.

> > the host
> > port may be active and keep the shared clock enabled (managed by the
> > grandparent device). Thereby the external-abort crash can be avoided
> > when suspending a disconnected (and runtime suspended) peripheral port.
> 
> So what?  There are lots of ways of avoiding such crashes.  (Disabling
> the driver entirely, for example.)  They aren't relevant for this
> discussion.

Perhaps I read your question too literally above; I'm trying to explain
how you can end up with a runtime suspended parent during resume, without
hitting the external abort during suspend, with the current kernel.

This can be done by keeping the sibling/cousin controller enabled, but
could of course also have been achieved by preventing the grandparent
(omap) device (which controls the clock) from suspending by other means.

I'm just describing how this could happen with the current
implementation; I'm not claiming that the implementation is correct.

> > When the system is later resumed, you would hit that broken activation
> > code of the runtime suspended device, with a likewise runtime suspended
> > parent, and the warning would be printed.
> 
> Why would the parent be runtime suspended?  Why wouldn't it still be in
> the full-power state, the way its own resume routine should have left
> it?
> 
> Maybe I'm being slow and dumb here, but I don't see how any of this 
> answers the question I raised earlier.

I think understand what you're getting at and yes, the parent *should*
be RPM_ACTIVE, while I'm saying that it *currently* is not guaranteed.

As mentioned above, 

Re: [RFCv2 usb-next 2/3] usb: host: add a generic platform USB roothub driver

[Chunfeng Yun]

On Thu, 2017-07-13 at 12:59 +0200, Martin Blumenstingl wrote:
> Many SoC platforms have separate devices for the USB PHY which are
> registered through the generic PHY framework. These PHYs have to be
> enabled to make the USB controller actually work. They also have to be
> disabled again on shutdown/suspend.
> 
> Currently (at least) the following HCI platform drivers are using custom
> code to obtain all PHYs via devicetree for the roothub/controller and
> disable/enable them when required:
> - ehci-platform.c has ehci_platform_power_{on,off}
> - xhci-mtk.c has xhci_mtk_phy_{init,exit,power_on,power_off}
> - ohci-platform.c has ohci_platform_power_{on,off}
> 
> These drivers are not using the generic devicetree USB device bindings
> yet which were only introduced recently (documentation is available in
> devicetree/bindings/usb/usb-device.txt).
> With this new driver the usb2-phy and usb3-phy can be specified directly
> in the child-node of the corresponding port of the roothub via
> devicetree. This can be extended by not just parsing PHYs (some of the
> other drivers listed above are for example also parsing a list of clocks
> as well) when required.
> 
> Signed-off-by: Martin Blumenstingl 
> ---
>  drivers/usb/host/Kconfig|   3 +
>  drivers/usb/host/Makefile   |   2 +
>  drivers/usb/host/platform-roothub.c | 146 
> 
>  drivers/usb/host/platform-roothub.h |  14 
>  4 files changed, 165 insertions(+)
>  create mode 100644 drivers/usb/host/platform-roothub.c
>  create mode 100644 drivers/usb/host/platform-roothub.h
> 
> diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
> index fa5692dec832..b8b05c786b2a 100644
> --- a/drivers/usb/host/Kconfig
> +++ b/drivers/usb/host/Kconfig
> @@ -805,6 +805,9 @@ config USB_HCD_SSB
>  
> If unsure, say N.
>  
> +config USB_PLATFORM_ROOTHUB
> + bool
> +
>  config USB_HCD_TEST_MODE
>   bool "HCD test mode support"
>   ---help---
> diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
> index cf2691fffcc0..dc817f82d632 100644
> --- a/drivers/usb/host/Makefile
> +++ b/drivers/usb/host/Makefile
> @@ -29,6 +29,8 @@ obj-$(CONFIG_USB_WHCI_HCD)  += whci/
>  
>  obj-$(CONFIG_USB_PCI)+= pci-quirks.o
>  
> +obj-$(CONFIG_USB_PLATFORM_ROOTHUB)   += platform-roothub.o
> +
>  obj-$(CONFIG_USB_EHCI_HCD)   += ehci-hcd.o
>  obj-$(CONFIG_USB_EHCI_PCI)   += ehci-pci.o
>  obj-$(CONFIG_USB_EHCI_HCD_PLATFORM)  += ehci-platform.o
> diff --git a/drivers/usb/host/platform-roothub.c 
> b/drivers/usb/host/platform-roothub.c
> new file mode 100644
> index ..84837e42b006
> --- /dev/null
> +++ b/drivers/usb/host/platform-roothub.c
> @@ -0,0 +1,146 @@
> +/*
> + * platform roothub driver - a virtual PHY device which passes all phy_*
> + * function calls to multiple (actual) PHY devices. This is comes handy when
> + * initializing all PHYs on a root-hub (to keep them all in the same state).
> + *
> + * Copyright (C) 2017 Martin Blumenstingl 
> 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program. If not, see .
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "platform-roothub.h"
> +
> +#define ROOTHUB_PORTNUM  0
> +
> +struct platform_roothub {
> + struct phy  *phy;
> + struct list_headlist;
> +};
> +
> +static struct platform_roothub *platform_roothub_alloc(struct device *dev)
> +{
> + struct platform_roothub *roothub_entry;
> +
> + roothub_entry = devm_kzalloc(dev, sizeof(*roothub_entry), GFP_KERNEL);
> + if (!roothub_entry)
> + return ERR_PTR(-ENOMEM);
> +
> + INIT_LIST_HEAD(_entry->list);
> +
> + return roothub_entry;
> +}
> +
> +static int platform_roothub_add_phy(struct device *dev,
> + struct device_node *port_np,
> + const char *con_id, struct list_head *list)
> +{
> + struct platform_roothub *roothub_entry;
> + struct phy *phy = devm_of_phy_get(dev, port_np, con_id);
> +
> + if (IS_ERR_OR_NULL(phy)) {
> + if (!phy || PTR_ERR(phy) == -ENODEV)
> + return 0;
> + else
> + return PTR_ERR(phy);
> + }
> +
> + roothub_entry = platform_roothub_alloc(dev);
> + if (IS_ERR(roothub_entry))
> + return PTR_ERR(roothub_entry);
> +
> + roothub_entry->phy = phy;
> +
> + list_add_tail(_entry->list, list);
> +
> + return 0;
> +}
> +
> +struct platform_roothub *platform_roothub_init(struct device *dev)
> +{
> + struct device_node *roothub_np,