Re: [PATCH v2] usb: typec: Add a sysfs node to manage port type

[Guenter Roeck]

On 05/24/2017 08:10 PM, Badhri Jagan Sridharan wrote:

Thanks comments inline.

On Tue, May 23, 2017 at 7:38 PM, Guenter Roeck  wrote:

On 05/23/2017 06:28 PM, Badhri Jagan Sridharan wrote:


User space applications in some cases have the need to enforce a
specific port type(DFP/UFP/DRP). This change allows userspace to
attempt setting the desired port type. Low level drivers can
however reject the request if the specific port type is not supported.

Signed-off-by: Badhri Jagan Sridharan 
---
Changelog since v1:
- introduced a new variable port_type in struct typec_port to track
the current port type instead of changing type member in
typec_capability to address Heikki Krogerus comments.
- changed the output format and strings that would be displayed as
suggested by Heikki Krogerus.

   Documentation/ABI/testing/sysfs-class-typec | 13 ++

   drivers/usb/typec/typec.c   | 66
+
   include/linux/usb/typec.h   |  4 ++
   3 files changed, 83 insertions(+)

diff --git a/Documentation/ABI/testing/sysfs-class-typec
b/Documentation/ABI/testing/sysfs-class-typec
index d4a3d23eb09c..1f224c2e391f 100644
--- a/Documentation/ABI/testing/sysfs-class-typec
+++ b/Documentation/ABI/testing/sysfs-class-typec
@@ -73,6 +73,19 @@ Description:
 Valid values: source, sink, none (to remove preference)
   +What:   /sys/class/typec//port_type
+Date:   May 2017
+Description:
+   Indicates the type of the port. This attribute can be used
for
+   requesting a change in the port type. Port type change is
+   supported as a synchronous operation, so write(2) to the
+   attribute will not return until the operation has
finished.
+
+   Valid values:
+   - source
+   - sink
+   - dual
+
   What: /sys/class/typec//supported_accessory_modes
   Date: April 2017
   Contact:  Heikki Krogerus 
diff --git a/drivers/usb/typec/typec.c b/drivers/usb/typec/typec.c
index 89e540bb7ff3..5063d6e0f8c7 100644
--- a/drivers/usb/typec/typec.c
+++ b/drivers/usb/typec/typec.c
@@ -69,6 +69,7 @@ struct typec_port {
 enum typec_role pwr_role;
 enum typec_role vconn_role;
 enum typec_pwr_opmode   pwr_opmode;
+   enum typec_port_typeport_type;



I am missing where this variable is initialized (when the port is registered
?).


Yes.. I missed it while cleaning up the patch. Will add it to my next patch.




 const struct typec_capability   *cap;
   };
@@ -789,6 +790,12 @@ static const char * const typec_data_roles[] = {
 [TYPEC_HOST]= "host",
   };
   +static const char * const typec_port_types[] = {
+   [TYPEC_PORT_DFP] = "source",
+   [TYPEC_PORT_UFP] = "sink",
+   [TYPEC_PORT_DRP] = "dual",
+};
+
   static ssize_t
   preferred_role_store(struct device *dev, struct device_attribute *attr,
  const char *buf, size_t size)
@@ -856,6 +863,12 @@ static ssize_t data_role_store(struct device *dev,
 return -EOPNOTSUPP;
 }
   + if (port->port_type != TYPEC_PORT_DRP) {
+   dev_dbg(dev, "port type fixed at \"%s\"",
+typec_port_types[port->port_type]);
+   return -EIO;



?? This is already there, or am I missing something ?


I am checking against the current value of port_type variable.
Dont we want to reject role swaps if the port_type is not
TYPEC_PORT_DRP ? My understanding is that if the port type
is fixed at say PORT_TYPE_DFP by userspace, then unless
the userspace sets port_type back to PORT_TYPE_DRP,
role swap requests have to rejected. Is my understanding not
correct ?



Ah yes, the existing check is for port->cap->type. But why not just
replace that check with port->port_type ? Checking both seems overkill.




+   }
+
 ret = sysfs_match_string(typec_data_roles, buf);
 if (ret < 0)
 return ret;
@@ -897,6 +910,12 @@ static ssize_t power_role_store(struct device *dev,
 return -EOPNOTSUPP;
 }
   + if (port->port_type != TYPEC_PORT_DRP) {
+   dev_dbg(dev, "port type fixed at \"%s\"",
+typec_port_types[port->port_type]);
+   return -EIO;



Unrelated change; should be in a separate patch. Also, it should
probably return -EOPNOTSUPP.


similar to what I am doing for data_role_store function.



Not sure here. This is currently treated differently. A host-only
or device-only port was still considered supportable if it supports
power delivery.




+   }
+
 if (port->pwr_opmode != TYPEC_PWR_MODE_PD) {
 dev_dbg(dev, "partner unable to swap power role\n");
 return -EIO;
@@ -926,6 +945,52 @@ static ssize_t 

Re: [RFC PATCH] staging: typec: Intel WhiskeyCove PMIC USB Type-C PHY driver

[Heikki Krogerus]

On Wed, May 24, 2017 at 05:08:10PM +0200, Greg Kroah-Hartman wrote:
> On Wed, May 24, 2017 at 03:54:23PM +0300, Heikki Krogerus wrote:
> > Driver for USB Type-C PHY on Intel WhiskeyCove PMIC that
> > works with Type-C Port Controller Manager to provide USB
> > Power Delivery and USB Type-C functionalities
> > 
> > Signed-off-by: Heikki Krogerus 
> > ---
> >  drivers/staging/typec/Kconfig   |  11 +
> >  drivers/staging/typec/Makefile  |   1 +
> >  drivers/staging/typec/typec_wcove.c | 684 
> > 
> >  drivers/usb/typec/Makefile  |   1 -
> >  drivers/usb/typec/typec_wcove.c | 377 
> >  5 files changed, 696 insertions(+), 378 deletions(-)
> >  create mode 100644 drivers/staging/typec/typec_wcove.c
> >  delete mode 100644 drivers/usb/typec/typec_wcove.c
> > 
> > Hi,
> > 
> > I would like to register also this driver with tcpm, but since tcpm is
> > in staging, can we move the driver to staging like in this patch?
> 
> How about spending the time to get the code out of staging instead?  I
> don't like adding new features to staging drivers, instead, I want to
> see people working to fix what we have before adding new stuff...

I agree that we need to get tcpm out of staging, and soon (I was not
expecting it to go staging at all, but as Guenter said, it's good to
have it in), but I also want to make sure that nobody, instead of
spending the time to get tcpm out of staging, starts preparing their
own USB PD state machines. That is really what has been happening, and
will continue to happen unless we do something.

So I want to make sure tcpm is being developed instead of something
else, and that is the reason I want to hook up also our whiskeycove
driver with it already at this point. I hope that makes sense.


Thanks,

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

Re: [PATCH 1/2] fs: configfs: make qw_sign attribute symmetric

[Stefan Agner]

Hi Felipe,

On 2017-04-19 01:53, Krzysztof Opasiak wrote:
> On 04/15/2017 03:35 AM, Stefan Agner wrote:
>> Currently qw_sign requires UTF-8 character to set, but returns UTF-16
>> when read. This isn't obvious when simply using cat since the null
>> characters are not visible, but hexdump unveils the true string:
>>
>>   # echo MSFT100 > os_desc/qw_sign
>>   # hexdump -C os_desc/qw_sign
>>     4d 00 53 00 46 00 54 00  31 00 30 00 30 00
>> |M.S.F.T.1.0.0.|
>>
>> Make qw_sign symmetric by returning an UTF-8 string too. Also follow
>> common convention and add a new line at the end.
>>
>> Signed-off-by: Stefan Agner 
>> ---
>> Resend as discussed here:
>> https://patchwork.kernel.org/patch/9548869/
>>
>> Sorry, a bit later than we discussed... Hope still not too late?
>>
>> --
>> Stefan
>>
>>  drivers/usb/gadget/configfs.c | 8 ++--
>>  1 file changed, 6 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/usb/gadget/configfs.c b/drivers/usb/gadget/configfs.c
>> index cbff3b02840d..863ca4ded1be 100644
>> --- a/drivers/usb/gadget/configfs.c
>> +++ b/drivers/usb/gadget/configfs.c
>> @@ -787,9 +787,13 @@ static ssize_t os_desc_b_vendor_code_store(struct 
>> config_item *item,
>>  static ssize_t os_desc_qw_sign_show(struct config_item *item, char *page)
>>  {
>>  struct gadget_info *gi = os_desc_item_to_gadget_info(item);
>> +int res;
>>
>> -memcpy(page, gi->qw_sign, OS_STRING_QW_SIGN_LEN);
>> -return OS_STRING_QW_SIGN_LEN;
>> +res = utf16s_to_utf8s((wchar_t *) gi->qw_sign, OS_STRING_QW_SIGN_LEN,
>> +  UTF16_LITTLE_ENDIAN, page, PAGE_SIZE - 1);
>> +page[res++] = '\n';
>> +
>> +return res;
>>  }
>>
>>  static ssize_t os_desc_qw_sign_store(struct config_item *item, const char 
>> *page,
>>
> 
> Code itself looks good to me and from libusbgx perspective it's also
> fine to add this new line as we can just drop it like we do with other
> newlines in case of gadget/config strings.
> 
> Reviewed-by: Krzysztof Opasiak 
> 

Any chance we get this in this merge window?

This still applies fine on v4.12-rc2.

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

Re: [RFC PATCH] staging: typec: Intel WhiskeyCove PMIC USB Type-C PHY driver

[Heikki Krogerus]

On Wed, May 24, 2017 at 08:22:35AM -0700, Guenter Roeck wrote:
> On Wed, May 24, 2017 at 05:08:10PM +0200, Greg Kroah-Hartman wrote:
> > On Wed, May 24, 2017 at 03:54:23PM +0300, Heikki Krogerus wrote:
> > > Driver for USB Type-C PHY on Intel WhiskeyCove PMIC that
> > > works with Type-C Port Controller Manager to provide USB
> > > Power Delivery and USB Type-C functionalities
> > > 
> > > Signed-off-by: Heikki Krogerus 
> > > ---
> > >  drivers/staging/typec/Kconfig   |  11 +
> > >  drivers/staging/typec/Makefile  |   1 +
> > >  drivers/staging/typec/typec_wcove.c | 684 
> > > 
> > >  drivers/usb/typec/Makefile  |   1 -
> > >  drivers/usb/typec/typec_wcove.c | 377 
> > >  5 files changed, 696 insertions(+), 378 deletions(-)
> > >  create mode 100644 drivers/staging/typec/typec_wcove.c
> > >  delete mode 100644 drivers/usb/typec/typec_wcove.c
> > > 
> > > Hi,
> > > 
> > > I would like to register also this driver with tcpm, but since tcpm is
> > > in staging, can we move the driver to staging like in this patch?
> > 
> > How about spending the time to get the code out of staging instead?  I
> > don't like adding new features to staging drivers, instead, I want to
> > see people working to fix what we have before adding new stuff...
> > 
> Either case I think it should possibly be a different driver: One without
> PD support, the other one with PD support.

That works for me. Greg, is that acceptable?


Thanks,

-- 
heikki
--
To unsubscribe from this list: send the line "unsubscribe 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: Runtime PM enabled EHCI does not respond to device plugging.

[Kai-Heng Feng]

On Wed, May 24, 2017 at 11:34 PM, Alan Stern  wrote:
> On Wed, 24 May 2017, Kai-Heng Feng wrote:
>
>> On Wed, May 24, 2017 at 12:43 AM, Alan Stern  
>> wrote:
>> >>
>> >> Output of `cat /sys/kernel/debug/usb/usbmon/1u`:
>> >> Runtime PM disabled as attachment.
>> >
>> > When you say "runtime PM disabled", you mean that it is disabled for
>> > the EHCI controller but enabled for other devices, right?
>>
>> Yes, disabled for the ehci-hcd. Runtime PM is enabled for ehci-pci.
>>
>> >
>> >> It's empty when runtime PM is enabled.
>> >
>> > And nothing shows up in the dmesg log either?  This suggests that the
>> > PME signal isn't working properly.
>> >
>> > Try doing this: With runtime PM enabled, plug in a device.  When
>> > nothing happens, do:
>> >
>> > lspci -v -s 00:12.0
>> >
>> > The output should show whether the controller is sending a wakeup
>> > signal.  Does it cause the device to be detected?
>>
>> No.
>>
>> 00:12.0 USB controller: Advanced Micro Devices, Inc. [AMD] FCH USB
>> EHCI Controller (rev 39) (prog-if 20 [EHCI])
>> Subsystem: Dell FCH USB EHCI Controller
>> Flags: 66MHz, medium devsel, IRQ 18
>> Memory at fe769000 (32-bit, non-prefetchable) [size=256]
>> Capabilities: [c0] Power Management version 2
>> Capabilities: [e4] Debug port: BAR=1 offset=00e0
>> Kernel driver in use: ehci-pci
>>
>> > If it doesn't, run lsusb.  That definitely should wake up the
>> > controller and cause the device to be detected.  Then run the lspci
>> > command again.  Let's see what the output from these commands shows.
>>
>> I plugged an optical mouse to test:
>> lsusb or "lsusb -s 001:001" does nothing, the mouse is not shown in
>> lsusb. The optical light is off.
>> "lsusb -s 001:001 -v" wakes up the controller and make the mouse to be
>> detected, the mouse is in lsusb and works correctly.
>> Once I turned on runtime PM on the mouse, it no longer works. The
>> optical light is still on but it did not response to movement or
>> click.
>>
>> This is the lspci right after I use "lsusb -s 001:001 -v" to wake up
>> the controller:
>> 00:12.0 USB controller: Advanced Micro Devices, Inc. [AMD] FCH USB
>> EHCI Controller (rev 39) (prog-if 20 [EHCI])
>> Subsystem: Dell FCH USB EHCI Controller
>> Flags: bus master, 66MHz, medium devsel, latency 32, IRQ 18
>> Memory at fe769000 (32-bit, non-prefetchable) [size=256]
>> Capabilities: [c0] Power Management version 2
>> Capabilities: [e4] Debug port: BAR=1 offset=00e0
>> Kernel driver in use: ehci-pci
>
> My mistake; we need to see the information from "lspci -vv -s 00:12.0"
> with two "v"'s, not just one.

Before wakeup:
00:12.0 USB controller: Advanced Micro Devices, Inc. [AMD] FCH USB
EHCI Controller (rev 39) (prog-if 20 [EHCI])
Subsystem: Dell FCH USB EHCI Controller
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV+ VGASnoop-
ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium
>TAbort- SERR- TAbort- SERR- 
> There's another piece of information you can collect.  Mount a
> debugfs filesystem at /sys/kernel/debug, and then copy the contents of
> the file
>
> /sys/kernel/debug/usb/ehci/:00:12.0/registers
>
> Do this while the controller is still asleep (after the mouse is
> plugged in) and then again after it is awake.

Before wakeup:
bus pci, device :00:12.0
EHCI Host Controller
SUSPENDED (no register access)

After wakeup:
bus pci, device :00:12.0
EHCI Host Controller
EHCI 1.00, rh state running
ownership 0001
SMI sts/enable 0xc008
structural params 0x0022
capability params 0xa076
status 4008 Periodic FLR
command 0010015 (park)=0 ithresh=1 Periodic period=512 RUN
intrenable 37 IAA FATAL PCD ERR INT
uframe 2d5f
port:1 status 001005 0  ACK POWER sig=se0 PE CONNECT
port:2 status 001000 0  ACK POWER sig=se0
irq normal 1855 err 10 iaa 98 (lost 0)
complete 1865 unlink 10
--
To unsubscribe from this list: send the line "unsubscribe 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] usb:host:xhci:USB 3.1 speed

[YD]

From: YD Tseng 

One of the xHCI host controllers supports both USB 3.1/3.0 extended speed
protocol lists. The content of the lists is shown as below.
In xhci-mem.c, the USB 3.1 speed is parsed first, the min_rev of usb3_rhub
is set as 0x10.  And then USB 3.0 is parsed.  However, the min_rev of
usb3_rhub will be changed to 0x00. If USB 3.1 device is connected behind
this host controller, the speed of USB 3.1 device just reports 5G speed using
lsusb.

 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
  00 01 08 00 00 00 00 00 40 00 00 00 00 00 00 00 00
  10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  20 02 08 10 03 55 53 42 20 01 02 00 00 00 00 00 00 //USB 3.1
  30 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  40 02 08 00 03 55 53 42 20 03 06 00 00 00 00 00 00 //USB 3.0
  50 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  60 02 08 00 02 55 53 42 20 09 0E 19 00 00 00 00 00 //USB 2.0
  70 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

This patch works around for parsing extended speed protocol lists. If the
xHCI controller supports USB 3.1 and 3.0 extended speed protocol, it could
show as one 3.1 roothub.

Signed-off-by: YD Tseng 
---
 drivers/usb/host/xhci-mem.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index 1f1687e..fddf273 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -2119,11 +2119,12 @@ static void xhci_add_in_port(struct xhci_hcd *xhci, 
unsigned int num_ports,
 {
u32 temp, port_offset, port_count;
int i;
-   u8 major_revision;
+   u8 major_revision, minor_revision;
struct xhci_hub *rhub;
 
temp = readl(addr);
major_revision = XHCI_EXT_PORT_MAJOR(temp);
+   minor_revision = XHCI_EXT_PORT_MINOR(temp);
 
if (major_revision == 0x03) {
rhub = >usb3_rhub;
@@ -2137,7 +2138,9 @@ static void xhci_add_in_port(struct xhci_hcd *xhci, 
unsigned int num_ports,
return;
}
rhub->maj_rev = XHCI_EXT_PORT_MAJOR(temp);
-   rhub->min_rev = XHCI_EXT_PORT_MINOR(temp);
+
+   if (rhub->min_rev < minor_revision)
+   rhub->min_rev = minor_revision;
 
/* Port offset and count in the third dword, see section 7.2 */
temp = readl(addr + 2);
-- 
2.7.4

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

Re: [RFC] usb-phy-generic: Add support to SMSC USB3315

[Fabien Lahoudere]

On Tue, 2017-05-23 at 14:00 -0700, Stephen Boyd wrote:
> On 05/23, Fabien Lahoudere wrote:
> > Hi,
> > 
> > We investigate on the topic and now our device tree look like:
> > 
> > in imx53.dtsi:
> > 
> > usbh2: usb@53f80400 {
> > compatible = "fsl,imx53-usb", "fsl,imx27-usb";
> > reg = <0x53f80400 0x0200>;
> > interrupts = <16>;
> > clocks = < IMX5_CLK_USBOH3_GATE>;
> > fsl,usbmisc = < 2>;
> > dr_mode = "host";
> > status = "disabled";
> > };
> > 
> > usbmisc: usbmisc@53f80800 {
> > #index-cells = <1>;
> > compatible = "fsl,imx53-usbmisc";
> > reg = <0x53f80800 0x200>;
> > clocks = < IMX5_CLK_USBOH3_GATE>;
> > };
> > 
> > and in our dts:
> > 
> >  {
> > pinctrl-names = "default";
> > pinctrl-0 = <_usbh2>;
> > disable-int60ck;
> > dr_mode = "host";
> > //fsl,usbphy = <>;
> > vbus-supply = <_usbh2_vbus>;
> > status = "okay";
> > ulpi {
> > phy {
> > compatible = "smsc,usb3315-ulpi";
> > reset-gpios = < 4 GPIO_ACTIVE_LOW>;
> > clock-names = "main_clk";
> > /*
> >  * Hardware uses CKO2 at 24MHz at several places. 
> > Set the parent
> >  *  clock of CKO2 to OSC.
> >  */
> > clock-frequency = <2400>;
> > clocks = < IMX5_CLK_CKO2>;
> > assigned-clocks = < IMX5_CLK_CKO2_SEL>, < 
> > IMX5_CLK_OSC>;
> > assigned-clock-parents = < IMX5_CLK_OSC>;
> > status = "okay";
> > };
> > };
> > };
> > 
> > And we create a basic driver to check what happened:
> > 
> > static int smsc_usb3315_phy_probe(struct ulpi *ulpi)
> > {
> > printk(KERN_ERR "Fabien: %s:%d-%s\n", __FILE__, __LINE__, __func__);
> > 
> > return 0;
> > }
> > 
> > static const struct of_device_id smsc_usb3315_phy_match[] = {
> > { .compatible = "smsc,usb3315-phy", },
> > { }
> > };
> > MODULE_DEVICE_TABLE(of, smsc_usb3315_phy_match);
> > 
> > static struct ulpi_driver smsc_usb3315_phy_driver = {
> > .probe = smsc_usb3315_phy_probe,
> > .driver = {
> > .name = "smsc_usb3315_phy",
> > .of_match_table = smsc_usb3315_phy_match,
> > },
> > };
> > module_ulpi_driver(smsc_usb3315_phy_driver);
> > 
> > /*MODULE_ALIAS("platform:usb_phy_generic");*/
> > MODULE_AUTHOR("GE Healthcare");
> > MODULE_DESCRIPTION("SMSC USB 3315 ULPI Phy driver");
> > MODULE_LICENSE("GPL v2");
> > 
> > I checked that the driver is registered by 
> > drivers/usb/common/ulpi.c:__ulpi_register_driver
> > successfully.
> 
> Does the ulpi device have some vendor/product ids associated
> with it? The design is made to only fallback to matching the
> device to driver based on DT if the ulpi vendor id is 0.
> Otherwise, if vendor is non-zero you'll need to have a
> ulpi_device_id id table in your ulpi_driver structure.
> 

Hi,

Thanks Stephen for your reply.
Indeed we have a vendor/product so I modify my code but without effect.

After looking at the ulpi source code in the kernel, it seems that I need to 
call
ulpi_register_interface. ci_hdrc_probe should be called to execute the ulpi 
init.

The problem is that we replace "fsl,usbphy = <>;" by an ulpi node but 
ci_hdrc_imx_probe fail
because of "data->phy = devm_usb_get_phy_by_phandle(>dev, "fsl,usbphy", 
0);"

So I will try to adapt ci_hdrc_imx_probe to continue phy initialisation if 
fsl,usbphy is missing.
Is it the good way to proceed?

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

Re: [PATCH 0/3] usb: typec: Add proper UCSI support

[Greg KH]

On Tue, May 16, 2017 at 03:26:10PM +0300, Heikki Krogerus wrote:
> Hi,
> 
> This series replaces the current UCSI driver (which was only trying to
> fix the data role of the port to host) with a new driver that registers
> itself to the typec class.
> 
> The driver is split in two. The core part is separated from the (ACPI)
> interface method part so we can easily add support for other interface
> methods later.

At first glance, this looks good to me.  But I'd like some acks/reviews
by Guenter and/or Oliver before I queue it up {hint}.

thanks,

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

Re: [PATCH v9 06/15] mlx5: Replace PCI pool old API

[Romain Perier]

Hello,


Le 23/05/2017 à 17:26, David Miller a écrit :
> From: Romain Perier 
> Date: Tue, 23 May 2017 10:53:36 +0200
>
>> Hello,
>>
>>
>> Le 23/05/2017 à 09:27, Leon Romanovsky a écrit :
>>> On Mon, May 22, 2017 at 06:48:58PM +0200, Romain Perier wrote:
 The PCI pool API is deprecated. This commit replaces the PCI pool old
 API by the appropriate function with the DMA pool API.

 Signed-off-by: Romain Perier 
 Reviewed-by: Peter Senna Tschudin 
 Acked-by: Doug Ledford 
 Tested-by: Doug Ledford 
 ---
  drivers/net/ethernet/mellanox/mlx5/core/cmd.c | 11 ++-
  include/linux/mlx5/driver.h   |  2 +-
  2 files changed, 7 insertions(+), 6 deletions(-)

>>> Who is supposed to merge this patch series?
>>>
>>> Acked-by: Leon Romanovsky 
>> Each maintainer of the corresponding subsystem, can take a patch, I
>> guess. No ?
> It might be easier to accumulate acks and you submit them as a series,
> in my opinion.
That's what I did already, no ?

Romain
--
To unsubscribe from this list: send the line "unsubscribe 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: mtu3: cleanup with list_first_entry_or_null()

[Greg Kroah-Hartman]

On Mon, May 22, 2017 at 09:21:33AM +0800, Chunfeng Yun wrote:
> Hi,
> On Sat, 2017-05-20 at 21:19 +0200, Greg Kroah-Hartman wrote:
> > On Sun, May 21, 2017 at 02:05:31AM +0900, Masahiro Yamada wrote:
> > > The combo of list_empty() and list_first_entry() can be replaced with
> > > list_first_entry_or_null().
> > > 
> > > Signed-off-by: Masahiro Yamada 
> > > ---
> > > 
> > >  drivers/usb/mtu3/mtu3.h | 8 ++--
> > >  1 file changed, 2 insertions(+), 6 deletions(-)
> > > 
> > > diff --git a/drivers/usb/mtu3/mtu3.h b/drivers/usb/mtu3/mtu3.h
> > > index aa6fd6a..7b6dc23 100644
> > > --- a/drivers/usb/mtu3/mtu3.h
> > > +++ b/drivers/usb/mtu3/mtu3.h
> > > @@ -356,12 +356,8 @@ static inline struct mtu3_ep *to_mtu3_ep(struct 
> > > usb_ep *ep)
> > >  
> > >  static inline struct mtu3_request *next_request(struct mtu3_ep *mep)
> > >  {
> > > - struct list_head *queue = >req_list;
> > > -
> > > - if (list_empty(queue))
> > > - return NULL;
> > > -
> > > - return list_first_entry(queue, struct mtu3_request, list);
> > > + return list_first_entry_or_null(>req_list, struct mtu3_request,
> > > + list);
> > 
> > Even better, why is this an inlined function at all?  Why not just have
> > it "open coded" everywhere it is used?
> > 
> This can avoid repeated function definition, currently it is used in
> three files.

Ok, makes sense.

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

Re: [PATCH v2] usb:host:xhci:USB 3.1 Speed

[YD Tseng]

Update V3 patch

>> +   xhci->usb3_rhub.min_rev = 0;
>> +   xhci->usb2_rhub.min_rev = 0;
>
> Why set these?  Are they not already cleared out at initialization time?
They are already cleared out at initialization, removing these 2 lines.

Thanks,
YD

On Tue, May 23, 2017 at 8:09 PM, Greg KH  wrote:
> On Tue, May 23, 2017 at 06:50:49PM +0800, YD wrote:
>> From: YD Tseng 
>>
>> Hi Greg and Mathias,
>
> Why is this here?  :)
>
> Hint, send what you want in the changelog, in the changelog area,
> anything else you want to say, put below the --- line, like
> Documentation/SubmittingPatches says to do.
>
>>
>> This patch works around for parsing extended speed protocol lists.
>
> Trailing space :(
>
>> If the xHCI controller supports USB 3.1 and 3.0 extended speed protocol,
>> it could show as one 3.1 roothub.
>
> I don't understand, what does it do today?
>
>
>>
>> Changes since v1:
>> - change diff path
>
> The changes go below ---
>
>
>>
>> Signed-off-by: YD Tseng 
>>
>> ---
>>
>> diff -up linux/drivers/usb/host/xhci-mem.c{.orig,} > /tmp/patch
>
> Where did this line come from?  git?
>
>> --- linux/drivers/usb/host/xhci-mem.c.orig  2017-04-08 
>> 15:35:38.0 +0800
>> +++ linux/drivers/usb/host/xhci-mem.c   2017-05-22 11:56:21.362907677 +0800
>> @@ -2111,11 +2111,12 @@ static void xhci_add_in_port(struct xhci
>>  {
>> u32 temp, port_offset, port_count;
>> int i;
>> -   u8 major_revision;
>> +   u8 major_revision, minor_revision;
>> struct xhci_hub *rhub;
>>
>> temp = readl(addr);
>
> All of your tabs got changed into spaces, making this patch impossible
> to apply :(
>
>> major_revision = XHCI_EXT_PORT_MAJOR(temp);
>> +   minor_revision = XHCI_EXT_PORT_MINOR(temp);
>>
>> if (major_revision == 0x03) {
>> rhub = >usb3_rhub;
>> @@ -2129,7 +2130,9 @@ static void xhci_add_in_port(struct xhci
>> return;
>> }
>> rhub->maj_rev = XHCI_EXT_PORT_MAJOR(temp);
>> -   rhub->min_rev = XHCI_EXT_PORT_MINOR(temp);
>> +
>> +   if (rhub->min_rev < minor_revision)
>> +   rhub->min_rev = minor_revision;
>
> Why change the revision from what it was?
>
>>
>> /* Port offset and count in the third dword, see section 7.2 */
>> temp = readl(addr + 2);
>> @@ -2280,6 +2283,8 @@ static int xhci_setup_port_arrays(struct
>>
>> offset = cap_start;
>>
>> +   xhci->usb3_rhub.min_rev = 0;
>> +   xhci->usb2_rhub.min_rev = 0;
>
> Why set these?  Are they not already cleared out at initialization time?
>
> thanks,
>
> greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RESEND PATCH v5] ARM: dts: da850: Add the CPPI 4.1 DMA to the USB OTG controller

[Sekhar Nori]

On Friday 19 May 2017 07:03 PM, Alexandre Bailon wrote:
> This adds the CPPI 4.1 DMA controller to the USB OTG controller.
> 
> Changes since v2:
> - Fixed the the property reg-names (had glue register defined)
> - Removed few useless property
> 
> Signed-off-by: Alexandre Bailon 

Looks good to me. Will wait some more time for other feedback before
applying.

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

Re: [RFC PATCH] staging: typec: Intel WhiskeyCove PMIC USB Type-C PHY driver

[Greg Kroah-Hartman]

On Thu, May 25, 2017 at 11:04:19AM +0300, Heikki Krogerus wrote:
> On Wed, May 24, 2017 at 08:22:35AM -0700, Guenter Roeck wrote:
> > On Wed, May 24, 2017 at 05:08:10PM +0200, Greg Kroah-Hartman wrote:
> > > On Wed, May 24, 2017 at 03:54:23PM +0300, Heikki Krogerus wrote:
> > > > Driver for USB Type-C PHY on Intel WhiskeyCove PMIC that
> > > > works with Type-C Port Controller Manager to provide USB
> > > > Power Delivery and USB Type-C functionalities
> > > > 
> > > > Signed-off-by: Heikki Krogerus 
> > > > ---
> > > >  drivers/staging/typec/Kconfig   |  11 +
> > > >  drivers/staging/typec/Makefile  |   1 +
> > > >  drivers/staging/typec/typec_wcove.c | 684 
> > > > 
> > > >  drivers/usb/typec/Makefile  |   1 -
> > > >  drivers/usb/typec/typec_wcove.c | 377 
> > > >  5 files changed, 696 insertions(+), 378 deletions(-)
> > > >  create mode 100644 drivers/staging/typec/typec_wcove.c
> > > >  delete mode 100644 drivers/usb/typec/typec_wcove.c
> > > > 
> > > > Hi,
> > > > 
> > > > I would like to register also this driver with tcpm, but since tcpm is
> > > > in staging, can we move the driver to staging like in this patch?
> > > 
> > > How about spending the time to get the code out of staging instead?  I
> > > don't like adding new features to staging drivers, instead, I want to
> > > see people working to fix what we have before adding new stuff...
> > > 
> > Either case I think it should possibly be a different driver: One without
> > PD support, the other one with PD support.
> 
> That works for me. Greg, is that acceptable?

I don't know, will that just confuse people as we now have two different
drivers for the same hardware?

What is keeping this code in staging at the moment?  Who isn't agreeing
on the existing apis we have there?

thanks,

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

[PATCH]usb:host:xhci AMD Promontory USB disable port support

[Jiahau Chang]

There is some limitation for AMD Promontory xHCI host to
 disable USB port function. It will enable USB wake-up function then cause USB
 disable port feature to fail. 
Workaround this issue on Promontory xHCI host
 is clear PORT_WAKE_BITS.

Signed-off-by: Jiahau Chang 
---
 drivers/usb/host/xhci-hub.c | 20 +++-
 drivers/usb/host/xhci-pci.c | 13 +
 drivers/usb/host/xhci.h |  2 ++
 3 files changed, 30 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
index 0dde49c..252c278 100644
--- a/drivers/usb/host/xhci-hub.c
+++ b/drivers/usb/host/xhci-hub.c
@@ -1218,12 +1218,19 @@ int xhci_hub_control(struct usb_hcd *hcd, u16 typeReq, 
u16 wValue,
xhci_dbg(xhci, "set port reset, actual port %d status  
= 0x%x\n", wIndex, temp);
break;
case USB_PORT_FEAT_REMOTE_WAKE_MASK:
-   xhci_set_remote_wake_mask(xhci, port_array,
+   if((xhci->quirks & XHCI_U2_DISABLE_WAKE) &&(hcd->speed 
< HCD_USB3)) {
+   temp = readl(port_array[wIndex]);
+   xhci_dbg(xhci, "skip set port remote wake mask, 
"
+   "actual port %d status  = 
0x%x\n",
+   wIndex, temp);
+   }else{  
+   xhci_set_remote_wake_mask(xhci, port_array,
wIndex, wake_mask);
-   temp = readl(port_array[wIndex]);
-   xhci_dbg(xhci, "set port remote wake mask, "
-   "actual port %d status  = 0x%x\n",
-   wIndex, temp);
+   temp = readl(port_array[wIndex]);
+   xhci_dbg(xhci, "set port remote wake mask, "
+   "actual port %d status  = 
0x%x\n",
+   wIndex, temp);
+   }
break;
case USB_PORT_FEAT_BH_PORT_RESET:
temp |= PORT_WR;
@@ -1461,6 +1468,9 @@ int xhci_bus_suspend(struct usb_hcd *hcd)
t2 |= PORT_WKOC_E | PORT_WKCONN_E;
t2 &= ~PORT_WKDISC_E;
}
+   
+   if((xhci->quirks & XHCI_U2_DISABLE_WAKE) &&(hcd->speed 
< HCD_USB3))
+   t2 &= ~PORT_WAKE_BITS;
} else
t2 &= ~PORT_WAKE_BITS;
 
diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
index fcf1f3f..8a66ac1 100644
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -54,6 +54,11 @@
 #define PCI_DEVICE_ID_INTEL_APL_XHCI   0x5aa8
 #define PCI_DEVICE_ID_INTEL_DNV_XHCI   0x19d0
 
+#define PCI_DEVICE_ID_AMD_PROMONTORYA_40x43b9
+#define PCI_DEVICE_ID_AMD_PROMONTORYA_30x43ba
+#define PCI_DEVICE_ID_AMD_PROMONTORYA_20x43bb
+#define PCI_DEVICE_ID_AMD_PROMONTORYA_10x43bc
+
 static const char hcd_name[] = "xhci_hcd";
 
 static struct hc_driver __read_mostly xhci_pci_hc_driver;
@@ -135,6 +140,14 @@ static void xhci_pci_quirks(struct device *dev, struct 
xhci_hcd *xhci)
if (pdev->vendor == PCI_VENDOR_ID_AMD)
xhci->quirks |= XHCI_TRUST_TX_LENGTH;
 
+   if((pdev->vendor == PCI_VENDOR_ID_AMD)&&
+   (( pdev->device==PCI_DEVICE_ID_AMD_PROMONTORYA_4)||
+( pdev->device==PCI_DEVICE_ID_AMD_PROMONTORYA_3)||
+( pdev->device==PCI_DEVICE_ID_AMD_PROMONTORYA_2)||
+( pdev->device==PCI_DEVICE_ID_AMD_PROMONTORYA_1)))
+   xhci->quirks |= XHCI_U2_DISABLE_WAKE;
+
+
if (pdev->vendor == PCI_VENDOR_ID_INTEL) {
xhci->quirks |= XHCI_LPM_SUPPORT;
xhci->quirks |= XHCI_INTEL_HOST;
diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index 73a28a9..48b262a 100644
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -1819,6 +1819,8 @@ struct xhci_hcd {
 /* For controller with a broken Port Disable implementation */
 #define XHCI_BROKEN_PORT_PED   (1 << 25)
 #define XHCI_LIMIT_ENDPOINT_INTERVAL_7 (1 << 26)
+#define XHCI_U2_DISABLE_WAKE(1 << 27)
+
 
unsigned intnum_active_eps;
unsigned intlimit_active_eps;
-- 
2.7.4

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

Re: [RFC PATCH] usb: optimize acpi companion search for usb port devices

[Mathias Nyman]

On 24.05.2017 17:44, Greg KH wrote:

On Wed, May 24, 2017 at 04:11:12PM +0300, Mathias Nyman wrote:

This optimization significantly reduces xhci driver load time.

In ACPI tables the acpi companion port devices are children of
the hub device. The port devices are identified by their port number
returned by the ACPI _ADR method.
_ADR 0 is reserved for the root hub device.

The current implementation to find a acpi companion port device
loops through all acpi port devices under that parent hub, calling
their _ADR method each time a new port device is added.

for a xHC controller with 25 ports under its roothub it
will end up invoking ACPI bytecode 625 times before all ports
are ready, making it really slow.

The _ADR values are already read and cached earler. So instead of
running the bytecode again we can check the cached _ADR value first,
and then fall back to the old way.

As one of the more significant changes, the xhci load time on
Intel kabylake reduced by 70%, (28ms) from
initcall xhci_pci_init+0x0/0x49 returned 0 after 39537 usecs
to
initcall xhci_pci_init+0x0/0x49 returned 0 after 11270 usecs

Signed-off-by: Mathias Nyman 
---
  drivers/usb/core/usb-acpi.c | 26 +++---
  1 file changed, 23 insertions(+), 3 deletions(-)


Why is this RFC?  What's wrong with it as-is?



Last minute doubt, nothing should be wrong, but I started to wonder if there is
any particular reason the ACPI part was done the way it was.

Or if maybe other drivers could benefit from checking cached _ADR value first as
well, and this whole thing should be a part of drivers/acpi/glue.c instead?

(adding acpi mailing list, not just Rafael)

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

Re: [PATCH 2/3] usb: typec: Add support for UCSI interface

[Guenter Roeck]

On 05/16/2017 05:26 AM, Heikki Krogerus wrote:

UCSI - USB Type-C Connector System Software Interface - is a
specification that defines set of registers and data
structures for controlling the USB Type-C ports. It's
designed for systems where an embedded controller (EC) is in
charge of the USB Type-C PHY or USB Power Delivery
controller. It is designed for systems with EC, but it is
not limited to them, and for example some USB Power Delivery
controllers will use it as their direct control interface.

With UCSI the EC (or USB PD controller) acts as the port
manager, implementing all USB Type-C and Power Delivery state
machines. The OS can use the interfaces for reading the
status of the ports and controlling basic operations like
role swapping.

The UCSI specification highlights the fact that it does not
define the interface method (PCI/I2C/ACPI/etc.).
Therefore the driver is implemented as library and every
supported interface method needs its own driver. Driver for
ACPI is provided in separate patch following this one.

The initial driver includes support for all required
features from UCSI specification version 1.0 (getting
connector capabilities and status, and support for power and
data role swapping), but none of the optional UCSI features
(alternate modes, power source capabilities, and cable
capabilities).

Signed-off-by: Heikki Krogerus 
---
  drivers/usb/typec/Kconfig   |   2 +
  drivers/usb/typec/Makefile  |   1 +
  drivers/usb/typec/ucsi/Kconfig  |  22 ++
  drivers/usb/typec/ucsi/Makefile |   7 +
  drivers/usb/typec/ucsi/debug.h  |  64 
  drivers/usb/typec/ucsi/trace.c  |   2 +
  drivers/usb/typec/ucsi/trace.h  | 143 
  drivers/usb/typec/ucsi/ucsi.c   | 770 
  drivers/usb/typec/ucsi/ucsi.h   | 329 +
  9 files changed, 1340 insertions(+)
  create mode 100644 drivers/usb/typec/ucsi/Kconfig
  create mode 100644 drivers/usb/typec/ucsi/Makefile
  create mode 100644 drivers/usb/typec/ucsi/debug.h
  create mode 100644 drivers/usb/typec/ucsi/trace.c
  create mode 100644 drivers/usb/typec/ucsi/trace.h
  create mode 100644 drivers/usb/typec/ucsi/ucsi.c
  create mode 100644 drivers/usb/typec/ucsi/ucsi.h

diff --git a/drivers/usb/typec/Kconfig b/drivers/usb/typec/Kconfig
index dfcfe459b7cf..bc1b7745f1d4 100644
--- a/drivers/usb/typec/Kconfig
+++ b/drivers/usb/typec/Kconfig
@@ -19,4 +19,6 @@ config TYPEC_WCOVE
  To compile this driver as module, choose M here: the module will be
  called typec_wcove
  
+source "drivers/usb/typec/ucsi/Kconfig"

+
  endmenu
diff --git a/drivers/usb/typec/Makefile b/drivers/usb/typec/Makefile
index b9cb862221af..bc214f15f1b5 100644
--- a/drivers/usb/typec/Makefile
+++ b/drivers/usb/typec/Makefile
@@ -1,2 +1,3 @@
  obj-$(CONFIG_TYPEC)   += typec.o
  obj-$(CONFIG_TYPEC_WCOVE) += typec_wcove.o
+obj-$(CONFIG_TYPEC_UCSI)   += ucsi/
diff --git a/drivers/usb/typec/ucsi/Kconfig b/drivers/usb/typec/ucsi/Kconfig
new file mode 100644
index ..679ba6648396
--- /dev/null
+++ b/drivers/usb/typec/ucsi/Kconfig
@@ -0,0 +1,22 @@
+config TYPEC_UCSI
+   tristate "USB Type-C Connector System Software Interface driver"
+   select TYPEC
+   help
+ USB Type-C Connector System Software Interface (UCSI) is a
+ specification for an interface that allows the operating system to
+ control the USB Type-C ports. On UCSI system the USB Type-C ports
+ function autonomously by default, but in order to get the status of
+ the ports and support basic operations like role swapping, the driver
+ is required. UCSI is available on most of the new Intel based systems
+ that are equipped with Embedded Controller and USB Type-C ports.
+
+ UCSI specification does not define the interface method, so depending
+ on the platform, ACPI, PCI, I2C, etc. may be used. Therefore this
+ driver only provides the core part, and separate drivers are needed
+ for every supported interface method.
+
+ The UCSI specification can be downloaded from:
+ 
http://www.intel.com/content/www/us/en/io/universal-serial-bus/usb-type-c-ucsi-spec.html
+
+ To compile the driver as a module, choose M here: the module will be
+ called typec_ucsi.
diff --git a/drivers/usb/typec/ucsi/Makefile b/drivers/usb/typec/ucsi/Makefile
new file mode 100644
index ..87dd6ee6c9f3
--- /dev/null
+++ b/drivers/usb/typec/ucsi/Makefile
@@ -0,0 +1,7 @@
+CFLAGS_trace.o := -I$(src)
+
+obj-$(CONFIG_TYPEC_UCSI)   += typec_ucsi.o
+
+typec_ucsi-y   := ucsi.o
+
+typec_ucsi-$(CONFIG_FTRACE)+= trace.o
diff --git a/drivers/usb/typec/ucsi/debug.h b/drivers/usb/typec/ucsi/debug.h
new file mode 100644
index ..87d0cd20597a
--- /dev/null
+++ b/drivers/usb/typec/ucsi/debug.h
@@ -0,0 +1,64 @@
+#ifndef __UCSI_DEBUG_H
+#define __UCSI_DEBUG_H
+

Re: [PATCH] usb: xhci: add quirk flag for broken stop command on AMD platforms

[Shyam Sundar S K]

On 5/22/2017 8:26 PM, Shyam Sundar S K wrote:
>
> On 5/22/2017 6:49 PM, Mathias Nyman wrote:
>> On 22.05.2017 11:56, Shyam Sundar S K wrote:
>>> Hi Mathias,
>>>
>>>
>>> On 5/19/2017 12:43 PM, Mathias Nyman wrote:
 On 18.05.2017 16:46, Alan Stern wrote:
> On Thu, 18 May 2017, Shyam Sundar S K wrote:
>
>> on AMD platforms with SNPS 3.1 USB controller has an issue
>> if the stop EP command is issued when the controller is not
>> in running state. If issued, it is leading to a critical RTL bug
>> because of which controller goes into irrecoverable state.
>>
>> This patch adds a appropriate checks to make sure that scenario
>> does not happen.
>>
>> Signed-off-by: Shyam Sundar S K 
>> Signed-off-by: Nehal Shah 
>> ---
>> --- a/drivers/usb/host/xhci.h
>> +++ b/drivers/usb/host/xhci.h
>> @@ -1819,6 +1819,7 @@ struct xhci_hcd {
>>/* For controller with a broken Port Disable implementation */
>>#define XHCI_BROKEN_PORT_PED(1 << 25)
>>#define XHCI_LIMIT_ENDPOINT_INTERVAL_7(1 << 26)
>> +#define XHCI_BROKEN_STOP(1 << 27)
> Does there really need to be a quirk flag for this?  I should think
> that you never want to issue a STOP EP command while the controller is
> not running, no matter what kind of controller it is.
>
> Alan Stern
>
 If it's about controller not running then there shouldn't be any problems.
 We shouldn't issue a stop endpoint command if controller is halted.

 If this is about issuing a stop endpoint command while endpoint isn't
 running, then fully working controllers should just respond with a command
 completion with "context state error" status.
>>> As per SNPS the controller is responding with "Context State Error", 
>>> however the same is not getting
>>> reflected when we check the cmd->status in the xhci driver.
>>>
 Anyway, as Alan said the quirk is probably unnecessary here.
>>> OK. We will take care of this.
>>>
 We shouldn't need to
 stop endpoints that are not running. Only problem I see here is that the
 endpoint state in the output endpoint context might not be up to date. If 
 driver
 just restarted the endpoint by ringing the doorbell, the output context 
 state
 might not be updated yet.
>>> Before issuing the stop end point command, we checked the state of the 
>>> endpoint and it looks the state of
>>> the end point is EP_STATE_STOPPED. If the output endpoint context is not 
>>> updated is there a better way
>>> to retrieve the EP state before issuing the stop end point command ?
>> Not really, checking endpoint context and possible a software variable kept 
>> up to date
>> by driver to keep track of doorbell. Perhaps checking endpoint ctx is enough 
>> for now
> So, is it OK to guard the stop endpoint by checking the EP context before 
> queuing it?
>
 How does this SNPS 3.1 controller react if the endpoint just halted or 
 moved to
 error state just before controller runs the stop endpoint command? Still 
 triggers
 the RTL bug?
>>> As per SNPS analysis.
>>>
>>> 1) Driver issues STOP ENDPOINT command  and the EP is in Running state.
>>> 2) HW executes the STOP ENDPOINT command successfully
>>> 3) Driver again issues STOP ENDPOINT command.
>>> 4) Since the EP is already halted/stopped, HW completes the command 
>>> execution and reports “device context error” completion code. This is as 
>>> per the spec.
>>> 5) However HW on receiving the second command additionally marks EP to Flow 
>>> control state in HW which is RTL bug
>>> 6) The above bug causes the HW not to respond to any further doorbells that 
>>> are rung by the driver. This causes the EP to not functional anymore and 
>>> causes gross functional failures.
>>>
>> What happens if endpoint ctx shows endpoint is in the halted or error state 
>> when stop endpoint command is issued?
>>  still RTL bug?
> Yes. That's right. If EP context shows as halted/stopped/error and we issue a 
> stop endpoint command it is triggering the RTL bug. Since the tapeout has 
> already happened and there is no way to fix this
> from SNPS side, they are asking for a SW workaround i.e.  "issuing the stop 
> endpoint command only when the EP context state is running."
>
> So, it is OK to have this patch submission which will check for EP context 
> before queuing the stop endpoint command ?
>
 I'm talking about the in xhci spec 4.6.9:

 " A Busy endpoint may asynchronously transition from the Running to the 
 Halted or Error state due
 to error conditions detected while processing TRBs. A possible race 
 condition may occur if
 software, thinking an endpoint is in the Running state, issues a Stop 
 Endpoint Command however
 at the same time the xHC asynchronously transitions the endpoint to the 
 Halted or Error state. In
 this case, a 

Re: [PATCH 3/3] usb: typec: ucsi: Add ACPI driver

[Guenter Roeck]

On 05/16/2017 05:26 AM, Heikki Krogerus wrote:

Driver for ACPI UCSI interface method. This driver replaces
the previous UCSI driver drivers/usb/misc/ucsi.c.

Signed-off-by: Heikki Krogerus 
---
  drivers/usb/misc/Kconfig   |  26 --
  drivers/usb/misc/Makefile  |   1 -
  drivers/usb/misc/ucsi.c| 478 -
  drivers/usb/misc/ucsi.h| 215 -
  drivers/usb/typec/ucsi/Kconfig |  16 ++
  drivers/usb/typec/ucsi/Makefile|   2 +
  drivers/usb/typec/ucsi/ucsi_acpi.c | 157 
  7 files changed, 175 insertions(+), 720 deletions(-)
  delete mode 100644 drivers/usb/misc/ucsi.c
  delete mode 100644 drivers/usb/misc/ucsi.h
  create mode 100644 drivers/usb/typec/ucsi/ucsi_acpi.c

diff --git a/drivers/usb/misc/Kconfig b/drivers/usb/misc/Kconfig
index 1d1d70d62a19..0f9f25db9163 100644
--- a/drivers/usb/misc/Kconfig
+++ b/drivers/usb/misc/Kconfig
@@ -275,29 +275,3 @@ config USB_CHAOSKEY
  
  	  To compile this driver as a module, choose M here: the

  module will be called chaoskey.
-
-config UCSI
-   tristate "USB Type-C Connector System Software Interface driver"
-   depends on ACPI
-   help
- UCSI driver is meant to be used as a convenience tool for desktop and
- server systems that are not equipped to handle USB in device mode. It
- will always select USB host role for the USB Type-C ports on systems
- that provide UCSI interface.
-
- USB Type-C Connector System Software Interface (UCSI) is a
- specification for an interface that allows the Operating System to
- control the USB Type-C ports on a system. Things the need controlling
- include the USB Data Role (host or device), and when USB Power
- Delivery is supported, the Power Role (source or sink). With USB
- Type-C connectors, when two dual role capable devices are attached
- together, the data role is selected randomly. Therefore it is
- important to give the OS a way to select the role. Otherwise the user
- would have to unplug and replug in order in order to attempt to swap
- the data and power roles.
-
- The UCSI specification can be downloaded from:
- 
http://www.intel.com/content/www/us/en/io/universal-serial-bus/usb-type-c-ucsi-spec.html
-
- To compile the driver as a module, choose M here: the module will be
- called ucsi.
diff --git a/drivers/usb/misc/Makefile b/drivers/usb/misc/Makefile
index f6ac6c99a6e6..7fdb45fc976f 100644
--- a/drivers/usb/misc/Makefile
+++ b/drivers/usb/misc/Makefile
@@ -27,7 +27,6 @@ obj-$(CONFIG_USB_HUB_USB251XB)+= usb251xb.o
  obj-$(CONFIG_USB_HSIC_USB3503)+= usb3503.o
  obj-$(CONFIG_USB_HSIC_USB4604)+= usb4604.o
  obj-$(CONFIG_USB_CHAOSKEY)+= chaoskey.o
-obj-$(CONFIG_UCSI) += ucsi.o
  
  obj-$(CONFIG_USB_SISUSBVGA)		+= sisusbvga/

  obj-$(CONFIG_USB_LINK_LAYER_TEST) += lvstest.o
diff --git a/drivers/usb/misc/ucsi.c b/drivers/usb/misc/ucsi.c
deleted file mode 100644
index 07397bddefa3..
--- a/drivers/usb/misc/ucsi.c
+++ /dev/null
@@ -1,478 +0,0 @@
-/*
- * USB Type-C Connector System Software Interface driver
- *
- * Copyright (C) 2016, Intel Corporation
- * Author: Heikki Krogerus 
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-
-#include 
-#include 
-#include 
-#include 
-
-#include "ucsi.h"
-
-/* Double the time defined by MIN_TIME_TO_RESPOND_WITH_BUSY */
-#define UCSI_TIMEOUT_MS 20
-
-enum ucsi_status {
-   UCSI_IDLE = 0,
-   UCSI_BUSY,
-   UCSI_ERROR,
-};
-
-struct ucsi_connector {
-   int num;
-   struct ucsi *ucsi;
-   struct work_struct work;
-   struct ucsi_connector_capability cap;
-};
-
-struct ucsi {
-   struct device *dev;
-   struct ucsi_data __iomem *data;
-
-   enum ucsi_status status;
-   struct completion complete;
-   struct ucsi_capability cap;
-   struct ucsi_connector *connector;
-
-   /* device lock */
-   spinlock_t dev_lock;
-
-   /* PPM Communication lock */
-   struct mutex ppm_lock;
-
-   /* PPM communication flags */
-   unsigned long flags;
-#define EVENT_PENDING  0
-#define COMMAND_PENDING1
-};
-
-static int ucsi_acpi_cmd(struct ucsi *ucsi, struct ucsi_control *ctrl)
-{
-   uuid_le uuid = UUID_LE(0x6f8398c2, 0x7ca4, 0x11e4,
-  0xad, 0x36, 0x63, 0x10, 0x42, 0xb5, 0x00, 0x8f);
-   union acpi_object *obj;
-
-   ucsi->data->ctrl.raw_cmd = ctrl->raw_cmd;
-
-   obj = acpi_evaluate_dsm(ACPI_HANDLE(ucsi->dev), uuid.b, 1, 1, NULL);
-   if (!obj) {
-   dev_err(ucsi->dev, "%s: failed to evaluate 

Re: USB hub clear POWER feature -> device still in 'lsusb' ?!

[Alan Stern]

On Thu, 25 May 2017, Harald Welte wrote:

> What are you referring-to specifically?  We have two distinct issues
> here:
> 
> a) the fact that you can "remove" the device (disable the "enable"
>feature), but there is no similar interface for re-enabling the
>"enable" feature (which appears to be done implicitly by setting the
>"reset" feature).  I think this should be safe and well within the
>USB spec, shouldn't it?

You misunderstand the interface.  The intent of the "remove" file is
not to turn off the enable status; it is to tell the kernel that _you_
are about to unplug the device and therefore the kernel should stop
using it.  In addition, the kernel should put the device into a state 
where the device thinks it can safely be unplugged (some devices turn 
on an LED to tell the user when it's okay to unplug them).

There's no need for a complementary interface because the kernel 
automatically starts using a device after it is plugged in.

Also, the "remove" file isn't guaranteed to turn off the enable 
status.  This is a side effect, and it differs between USB-2 and 
USB-3.

> b) the fact that the device can be powered off and the kernel learning
>about this status change but still happily having the device in its
>data structures.  You can argue which condition keeps the "connect"
>feature, but is there a valid use case for a device without the
>"power" feature still being in the internal lists?  How can it be
>connected without power?  Even a self-powered device is not supposed
>to become active unless it sees VBus, right?

The kernel doesn't specifically check the power status of a port; it 
looks at the connect and enable statuses.  If they indicate the device 
is still attached and running, the kernel believes them.

If a hub is buggy and provides inconsistent information (power off, 
connect or enable on), how can the kernel tell what to believe?

> I guess even if we don't have 'c', 'a' and 'b' can still be adressed:
> 
> * add a mechanism by which the "enable" feature can be set after it has
>   been removed e.g. by means of the "echo > remove".  Not related to
>   power switching at all, merely a matter of having orthogonal
>   interfaces: If you can remove it, you can add it again.  Non-removable
>   USB is pretty frequent these days, think of hub chips built onto
>   mainboards, or USB hub + card reader built into the display.  you
>   cannot re-plug in one chip into the hub on the circuit board next to
>   it.

Resetting the device attached to the port should accomplish what you
want.  A reset can be issued via an ioctl or libusb.

> * as the USB spec states that the "connect" feature should be cleared
>   when "power" is cleared, and there apparently are hubs out there who
>   think it's not their job to do so:  Should the hub.c kernel driver
>   work around that by either clearing it by itself, or by doing a
>   usb_remove_device() in that situation?

The kernel driver cannot actually clear the connect status; the USB
protocol offers no way of doing this.  But we could check for power-off
status and treat it as a disconnect.

I'm not sure there's any good reason for adding this, however.  You'd 
still face the same problem of how to tell the kernel that the device 
(or a different device!) is now attached to the port when the power is 
restored.

Alan Stern

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

Re: [PATCH 1/3] usb: typec: update partner power delivery support with opmode

[Guenter Roeck]

On 05/16/2017 05:26 AM, Heikki Krogerus wrote:

If USB PD contract is established after creation of the
partner, the power delivery support attribute of the partner
needs to be updated separately. This can be done in
typec_set_pwr_opmode() by checking if the port has already
partner and updating the value if it does.

Signed-off-by: Heikki Krogerus 


Reviewed-by: Guenter Roeck 


---
  drivers/usb/typec/typec.c | 19 +++
  1 file changed, 19 insertions(+)

diff --git a/drivers/usb/typec/typec.c b/drivers/usb/typec/typec.c
index 89e540bb7ff3..18076b44cf56 100644
--- a/drivers/usb/typec/typec.c
+++ b/drivers/usb/typec/typec.c
@@ -1123,6 +1123,11 @@ void typec_set_vconn_role(struct typec_port *port, enum 
typec_role role)
  }
  EXPORT_SYMBOL_GPL(typec_set_vconn_role);
  
+static int partner_match(struct device *dev, void *data)

+{
+   return is_typec_partner(dev);
+}
+
  /**
   * typec_set_pwr_opmode - Report changed power operation mode
   * @port: The USB Type-C Port where the mode was changed
@@ -1136,12 +1141,26 @@ EXPORT_SYMBOL_GPL(typec_set_vconn_role);
  void typec_set_pwr_opmode(struct typec_port *port,
  enum typec_pwr_opmode opmode)
  {
+   struct device *partner_dev;
+
if (port->pwr_opmode == opmode)
return;
  
  	port->pwr_opmode = opmode;

sysfs_notify(>dev.kobj, NULL, "power_operation_mode");
kobject_uevent(>dev.kobj, KOBJ_CHANGE);
+
+   partner_dev = device_find_child(>dev, NULL, partner_match);
+   if (partner_dev) {
+   struct typec_partner *partner = to_typec_partner(partner_dev);
+
+   if (opmode == TYPEC_PWR_MODE_PD && !partner->usb_pd) {
+   partner->usb_pd = 1;
+   sysfs_notify(_dev->kobj, NULL,
+"supports_usb_power_delivery");
+   }
+   put_device(partner_dev);
+   }
  }
  EXPORT_SYMBOL_GPL(typec_set_pwr_opmode);
  



--
To unsubscribe from this list: send the line "unsubscribe 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: Runtime PM enabled EHCI does not respond to device plugging.

[Kai-Heng Feng]

On Fri, May 26, 2017 at 1:01 AM, Alan Stern  wrote:
> On Thu, 25 May 2017, Kai-Heng Feng wrote:
>
>> > My mistake; we need to see the information from "lspci -vv -s 00:12.0"
>> > with two "v"'s, not just one.
>>
>> Before wakeup:
>> 00:12.0 USB controller: Advanced Micro Devices, Inc. [AMD] FCH USB
>> EHCI Controller (rev 39) (prog-if 20 [EHCI])
>> Subsystem: Dell FCH USB EHCI Controller
>> Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV+ VGASnoop-
>> ParErr- Stepping- SERR- FastB2B- DisINTx-
>> Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium
>> >TAbort- SERR- > Interrupt: pin A routed to IRQ 18
>> Region 0: Memory at fe769000 (32-bit, non-prefetchable) [size=256]
>> Capabilities: [c0] Power Management version 2
>> Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
>> PME(D0+,D1+,D2+,D3hot+,D3cold+)
>> Status: D3 NoSoftRst- PME-Enable+ DSel=0 DScale=0 PME-
>> Bridge: PM- B3+
>> Capabilities: [e4] Debug port: BAR=1 offset=00e0
>> Kernel driver in use: ehci-pci
>
> Was this before you plugged in the mouse or after?

After.

>
> If it was after, it means there is a bug in the EHCI controller
> hardware.  This line:
>
>> Status: D3 NoSoftRst- PME-Enable+ DSel=0 DScale=0 PME-
>
> says that the PME signal is not enabled, so the controller is not
> sending a wakeup request.  But when a new device gets plugged in, the
> controller is supposed to ask to be woken up.

Hmm, sounds bad.
Is there any known workaround?
Maybe wake up the host every two seconds?
Or use a quirk to disable runtime PM for this host?

>
>> After wakeup:
>> 00:12.0 USB controller: Advanced Micro Devices, Inc. [AMD] FCH USB
>> EHCI Controller (rev 39) (prog-if 20 [EHCI])
>> Subsystem: Dell FCH USB EHCI Controller
>> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop-
>> ParErr- Stepping- SERR- FastB2B- DisINTx-
>> Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium
>> >TAbort- SERR- > Latency: 32, Cache Line Size: 64 bytes
>> Interrupt: pin A routed to IRQ 18
>> Region 0: Memory at fe769000 (32-bit, non-prefetchable) [size=256]
>> Capabilities: [c0] Power Management version 2
>> Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
>> PME(D0+,D1+,D2+,D3hot+,D3cold+)
>> Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
>> Bridge: PM- B3+
>> Capabilities: [e4] Debug port: BAR=1 offset=00e0
>> Kernel driver in use: ehci-pci
>
> Yes, that is normal.
>
>> > There's another piece of information you can collect.  Mount a
>> > debugfs filesystem at /sys/kernel/debug, and then copy the contents of
>> > the file
>> >
>> > /sys/kernel/debug/usb/ehci/:00:12.0/registers
>> >
>> > Do this while the controller is still asleep (after the mouse is
>> > plugged in) and then again after it is awake.
>>
>> Before wakeup:
>> bus pci, device :00:12.0
>> EHCI Host Controller
>> SUSPENDED (no register access)
>>
>> After wakeup:
>> bus pci, device :00:12.0
>> EHCI Host Controller
>> EHCI 1.00, rh state running
>> ownership 0001
>> SMI sts/enable 0xc008
>> structural params 0x0022
>> capability params 0xa076
>> status 4008 Periodic FLR
>> command 0010015 (park)=0 ithresh=1 Periodic period=512 RUN
>> intrenable 37 IAA FATAL PCD ERR INT
>> uframe 2d5f
>> port:1 status 001005 0  ACK POWER sig=se0 PE CONNECT
>> port:2 status 001000 0  ACK POWER sig=se0
>> irq normal 1855 err 10 iaa 98 (lost 0)
>> complete 1865 unlink 10
>
> Again, this is normal.
>
> Alan Stern
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] usb: dwc2: add support for the DWC2 controller on Meson8 SoCs

[Martin Blumenstingl]

Hi John,

On Sat, May 6, 2017 at 7:37 PM, Martin Blumenstingl
 wrote:
> USB support in the Meson8 SoCs is provided by a DWC2 controller which
> works with the same settings as Meson8b and GXBB. Using the generic
> "snps,dwc2" binding results in an endless stream of "Overcurrent change
> detected" messages.
>
> Signed-off-by: Martin Blumenstingl 
do you want me to re-send this with Rob's ACK?
also please let me know if something is still missing in this patch

> ---
>  Documentation/devicetree/bindings/usb/dwc2.txt | 1 +
>  drivers/usb/dwc2/params.c  | 2 ++
>  2 files changed, 3 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/usb/dwc2.txt 
> b/Documentation/devicetree/bindings/usb/dwc2.txt
> index 6c7c2bce6d0c..b55be381ae85 100644
> --- a/Documentation/devicetree/bindings/usb/dwc2.txt
> +++ b/Documentation/devicetree/bindings/usb/dwc2.txt
> @@ -10,6 +10,7 @@ Required properties:
>- "rockchip,rk3288-usb", "rockchip,rk3066-usb", "snps,dwc2": for rk3288 
> Soc;
>- "lantiq,arx100-usb": The DWC2 USB controller instance in Lantiq ARX SoCs;
>- "lantiq,xrx200-usb": The DWC2 USB controller instance in Lantiq XRX SoCs;
> +  - "amlogic,meson8-usb": The DWC2 USB controller instance in Amlogic Meson8 
> SoCs;
>- "amlogic,meson8b-usb": The DWC2 USB controller instance in Amlogic 
> Meson8b SoCs;
>- "amlogic,meson-gxbb-usb": The DWC2 USB controller instance in Amlogic 
> S905 SoCs;
>- "amcc,dwc-otg": The DWC2 USB controller instance in AMCC Canyonlands 
> 460EX SoCs;
> diff --git a/drivers/usb/dwc2/params.c b/drivers/usb/dwc2/params.c
> index 2990c347289f..0d6290ed66ea 100644
> --- a/drivers/usb/dwc2/params.c
> +++ b/drivers/usb/dwc2/params.c
> @@ -128,6 +128,8 @@ const struct of_device_id dwc2_of_match_table[] = {
> { .compatible = "lantiq,xrx200-usb", .data = dwc2_set_ltq_params },
> { .compatible = "snps,dwc2" },
> { .compatible = "samsung,s3c6400-hsotg" },
> +   { .compatible = "amlogic,meson8-usb",
> + .data = dwc2_set_amlogic_params },
> { .compatible = "amlogic,meson8b-usb",
>   .data = dwc2_set_amlogic_params },
> { .compatible = "amlogic,meson-gxbb-usb",
> --
> 2.12.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

Re: [PATCH 1/3] usb: host: ohci-platform: Add basic runtime PM support

[Alan Stern]

On Thu, 25 May 2017, Tony Lindgren wrote:

> This is needed in preparation of adding support for omap3 and
> later OHCI. The runtime PM will only do something on platforms
> that implement it.
> 
> Cc: devicet...@vger.kernel.org
> Cc: Hans de Goede 
> Cc: Rob Herring 
> Cc: Roger Quadros 
> Cc: Sebastian Reichel 
> Cc: Yoshihiro Shimoda 
> Signed-off-by: Tony Lindgren 
> ---
>  drivers/usb/host/ohci-platform.c | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/drivers/usb/host/ohci-platform.c 
> b/drivers/usb/host/ohci-platform.c
> --- a/drivers/usb/host/ohci-platform.c
> +++ b/drivers/usb/host/ohci-platform.c
> @@ -24,6 +24,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -242,6 +243,8 @@ static int ohci_platform_probe(struct platform_device 
> *dev)
>   }
>  #endif
>  
> + pm_runtime_set_active(>dev);
> + pm_runtime_enable(>dev);
>   if (pdata->power_on) {
>   err = pdata->power_on(dev);
>   if (err < 0)
> @@ -271,6 +274,7 @@ static int ohci_platform_probe(struct platform_device 
> *dev)
>   if (pdata->power_off)
>   pdata->power_off(dev);
>  err_reset:
> + pm_runtime_disable(>dev);
>   while (--rst >= 0)
>   reset_control_assert(priv->resets[rst]);
>  err_put_clks:
> @@ -292,6 +296,7 @@ static int ohci_platform_remove(struct platform_device 
> *dev)
>   struct ohci_platform_priv *priv = hcd_to_ohci_priv(hcd);
>   int clk, rst;
>  
> + pm_runtime_get_sync(>dev);
>   usb_remove_hcd(hcd);
>  
>   if (pdata->power_off)
> @@ -305,6 +310,9 @@ static int ohci_platform_remove(struct platform_device 
> *dev)
>  
>   usb_put_hcd(hcd);
>  
> + pm_runtime_put_sync(>dev);
> + pm_runtime_disable(>dev);
> +
>   if (pdata == _platform_defaults)
>   dev->dev.platform_data = NULL;

Acked-by: Alan Stern 

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

Re: [RFC PATCH] staging: typec: Intel WhiskeyCove PMIC USB Type-C PHY driver

[Guenter Roeck]

On Thu, May 25, 2017 at 12:11:53PM +0200, Greg Kroah-Hartman wrote:
> On Thu, May 25, 2017 at 11:04:19AM +0300, Heikki Krogerus wrote:
> > On Wed, May 24, 2017 at 08:22:35AM -0700, Guenter Roeck wrote:
> > > On Wed, May 24, 2017 at 05:08:10PM +0200, Greg Kroah-Hartman wrote:
> > > > On Wed, May 24, 2017 at 03:54:23PM +0300, Heikki Krogerus wrote:
> > > > > Driver for USB Type-C PHY on Intel WhiskeyCove PMIC that
> > > > > works with Type-C Port Controller Manager to provide USB
> > > > > Power Delivery and USB Type-C functionalities
> > > > > 
> > > > > Signed-off-by: Heikki Krogerus 
> > > > > ---
> > > > >  drivers/staging/typec/Kconfig   |  11 +
> > > > >  drivers/staging/typec/Makefile  |   1 +
> > > > >  drivers/staging/typec/typec_wcove.c | 684 
> > > > > 
> > > > >  drivers/usb/typec/Makefile  |   1 -
> > > > >  drivers/usb/typec/typec_wcove.c | 377 
> > > > >  5 files changed, 696 insertions(+), 378 deletions(-)
> > > > >  create mode 100644 drivers/staging/typec/typec_wcove.c
> > > > >  delete mode 100644 drivers/usb/typec/typec_wcove.c
> > > > > 
> > > > > Hi,
> > > > > 
> > > > > I would like to register also this driver with tcpm, but since tcpm is
> > > > > in staging, can we move the driver to staging like in this patch?
> > > > 
> > > > How about spending the time to get the code out of staging instead?  I
> > > > don't like adding new features to staging drivers, instead, I want to
> > > > see people working to fix what we have before adding new stuff...
> > > > 
> > > Either case I think it should possibly be a different driver: One without
> > > PD support, the other one with PD support.
> > 
> > That works for me. Greg, is that acceptable?
> 
> I don't know, will that just confuse people as we now have two different
> drivers for the same hardware?

Depends. They would be mutually exclusive.

> 
> What is keeping this code in staging at the moment?  Who isn't agreeing
> on the existing apis we have there?
> 

I don't think the APIs are at issue; I would not expect any substantial
(if any) changes going forward. We may have additions such as the pending
port type change support, but will always happen.

>From TODO:
- Add documentation (at the very least for the API to low level drivers)
- Split PD code into separate file
- Check if it makes sense to use tracepoints instead of debugfs for debug logs
- Implement Alternate Mode handling
- Address "#if 0" code if not addressed with the above
- Validate all comments marked with "XXX"; either address or remove comments
- Add support for USB PD 3.0. While not mandatory, at least fast role swap
  as well as authentication support would be very desirable.

Not all of it has to be handled. I would see USB PD 3.0 as optional, for
example. For the rest, we would need an agreement about what is mandatory.
Presumably API documentation, but what else ?

Guenter
--
To unsubscribe from this list: send the line "unsubscribe 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: host: ohci-platform: Add basic runtime PM support

[Tony Lindgren]

This is needed in preparation of adding support for omap3 and
later OHCI. The runtime PM will only do something on platforms
that implement it.

Cc: devicet...@vger.kernel.org
Cc: Hans de Goede 
Cc: Rob Herring 
Cc: Roger Quadros 
Cc: Sebastian Reichel 
Cc: Yoshihiro Shimoda 
Signed-off-by: Tony Lindgren 
---
 drivers/usb/host/ohci-platform.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/usb/host/ohci-platform.c b/drivers/usb/host/ohci-platform.c
--- a/drivers/usb/host/ohci-platform.c
+++ b/drivers/usb/host/ohci-platform.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -242,6 +243,8 @@ static int ohci_platform_probe(struct platform_device *dev)
}
 #endif
 
+   pm_runtime_set_active(>dev);
+   pm_runtime_enable(>dev);
if (pdata->power_on) {
err = pdata->power_on(dev);
if (err < 0)
@@ -271,6 +274,7 @@ static int ohci_platform_probe(struct platform_device *dev)
if (pdata->power_off)
pdata->power_off(dev);
 err_reset:
+   pm_runtime_disable(>dev);
while (--rst >= 0)
reset_control_assert(priv->resets[rst]);
 err_put_clks:
@@ -292,6 +296,7 @@ static int ohci_platform_remove(struct platform_device *dev)
struct ohci_platform_priv *priv = hcd_to_ohci_priv(hcd);
int clk, rst;
 
+   pm_runtime_get_sync(>dev);
usb_remove_hcd(hcd);
 
if (pdata->power_off)
@@ -305,6 +310,9 @@ static int ohci_platform_remove(struct platform_device *dev)
 
usb_put_hcd(hcd);
 
+   pm_runtime_put_sync(>dev);
+   pm_runtime_disable(>dev);
+
if (pdata == _platform_defaults)
dev->dev.platform_data = NULL;
 
-- 
2.13.0
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3/3] usb: host: ohci-omap3: Remove driver in favor of ohci-platform

[Tony Lindgren]

This driver is no longer needed and can be removed. The reason why
it's safe to remove this driver is that most omap devices don't have a
USB low-speed or full-speed compatible PHY installed and configured
with drivers/mfd/omap-usb-host.c. This means that devices like
beagleboard and pandaboard need to use a high-speed USB hub in order
to use devices like keyboard and mice.

Currently the only known configured for a full-speed PHY is the
mdm6600 modem on droid 4 and I've verified it works just fine with
ohci-platform.

Acked-by: Alan Stern 
Acked-by: Roger Quadros 
Reviewed-by: Sebastian Reichel 
Signed-off-by: Tony Lindgren 
---
 drivers/usb/host/Kconfig  |   6 +-
 drivers/usb/host/Makefile |   1 -
 drivers/usb/host/ohci-omap3.c | 211 --
 3 files changed, 5 insertions(+), 213 deletions(-)
 delete mode 100644 drivers/usb/host/ohci-omap3.c

diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -473,8 +473,12 @@ config USB_OHCI_HCD_AT91
 config USB_OHCI_HCD_OMAP3
tristate "OHCI support for OMAP3 and later chips"
depends on (ARCH_OMAP3 || ARCH_OMAP4 || SOC_OMAP5)
+   select USB_OHCI_HCD_PLATFORM
default y
-   ---help---
+   help
+ This option is deprecated now and the driver was removed, use
+ USB_OHCI_HCD_PLATFORM instead.
+
  Enables support for the on-chip OHCI controller on
  OMAP3 and later chips.
 
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -52,7 +52,6 @@ obj-$(CONFIG_USB_OHCI_HCD_PCI)+= ohci-pci.o
 obj-$(CONFIG_USB_OHCI_HCD_PLATFORM)+= ohci-platform.o
 obj-$(CONFIG_USB_OHCI_EXYNOS)  += ohci-exynos.o
 obj-$(CONFIG_USB_OHCI_HCD_OMAP1)   += ohci-omap.o
-obj-$(CONFIG_USB_OHCI_HCD_OMAP3)   += ohci-omap3.o
 obj-$(CONFIG_USB_OHCI_HCD_SPEAR)   += ohci-spear.o
 obj-$(CONFIG_USB_OHCI_HCD_STI) += ohci-st.o
 obj-$(CONFIG_USB_OHCI_HCD_AT91)+= ohci-at91.o
diff --git a/drivers/usb/host/ohci-omap3.c b/drivers/usb/host/ohci-omap3.c
deleted file mode 100644
--- a/drivers/usb/host/ohci-omap3.c
+++ /dev/null
@@ -1,211 +0,0 @@
-/*
- * ohci-omap3.c - driver for OHCI on OMAP3 and later processors
- *
- * Bus Glue for OMAP3 USBHOST 3 port OHCI controller
- * This controller is also used in later OMAPs and AM35x chips
- *
- * Copyright (C) 2007-2010 Texas Instruments, Inc.
- * Author: Vikram Pandita 
- * Author: Anand Gadiyar 
- * Author: Keshava Munegowda 
- *
- * Based on ehci-omap.c and some other ohci glue layers
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307 USA
- *
- * TODO (last updated Feb 27, 2011):
- * - add kernel-doc
- */
-
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#include "ohci.h"
-
-#define DRIVER_DESC "OHCI OMAP3 driver"
-
-static const char hcd_name[] = "ohci-omap3";
-static struct hc_driver __read_mostly ohci_omap3_hc_driver;
-
-/*
- * configure so an HC device and id are always provided
- * always called with process context; sleeping is OK
- */
-
-/**
- * ohci_hcd_omap3_probe - initialize OMAP-based HCDs
- *
- * Allocates basic resources for this USB host controller, and
- * then invokes the start() method for the HCD associated with it
- * through the hotplug entry's driver_data.
- */
-static int ohci_hcd_omap3_probe(struct platform_device *pdev)
-{
-   struct device   *dev = >dev;
-   struct ohci_hcd *ohci;
-   struct usb_hcd  *hcd = NULL;
-   void __iomem*regs = NULL;
-   struct resource *res;
-   int ret;
-   int irq;
-
-   if (usb_disabled())
-   return -ENODEV;
-
-   if (!dev->parent) {
-   dev_err(dev, "Missing parent device\n");
-   return -ENODEV;
-   }
-
-   irq = platform_get_irq(pdev, 0);
-   if (irq < 0) {
-   dev_err(dev, "OHCI irq failed\n");
-   return -ENODEV;
-   }
-
-   res = 

[PATCH 2/3] usb: host: ohci-platform: Add support for omap3 and later

[Tony Lindgren]

With the runtime PM implemented for ohci-platform driver, we can
now support omap3 and later OHCI by adding one device tree
property.

Cc: Hans de Goede 
Cc: Rob Herring 
Cc: Yoshihiro Shimoda 
Cc: Sebastian Reichel 
Acked-by: Alan Stern 
Acked-by: Roger Quadros 
Signed-off-by: Tony Lindgren 
---
 Documentation/devicetree/bindings/usb/usb-ohci.txt | 1 +
 drivers/usb/host/ohci-platform.c   | 5 +
 2 files changed, 6 insertions(+)

diff --git a/Documentation/devicetree/bindings/usb/usb-ohci.txt 
b/Documentation/devicetree/bindings/usb/usb-ohci.txt
--- a/Documentation/devicetree/bindings/usb/usb-ohci.txt
+++ b/Documentation/devicetree/bindings/usb/usb-ohci.txt
@@ -10,6 +10,7 @@ Optional properties:
 - big-endian-desc : boolean, set this for hcds with big-endian descriptors
 - big-endian : boolean, for hcds with big-endian-regs + big-endian-desc
 - no-big-frame-no : boolean, set if frame_no lives in bits [15:0] of HCCA
+- remote-wakeup-connected: remote wakeup is wired on the platform
 - num-ports : u32, to override the detected port count
 - clocks : a list of phandle + clock specifier pairs
 - phys : phandle + phy specifier pair
diff --git a/drivers/usb/host/ohci-platform.c b/drivers/usb/host/ohci-platform.c
--- a/drivers/usb/host/ohci-platform.c
+++ b/drivers/usb/host/ohci-platform.c
@@ -164,6 +164,10 @@ static int ohci_platform_probe(struct platform_device *dev)
if (of_property_read_bool(dev->dev.of_node, "no-big-frame-no"))
ohci->flags |= OHCI_QUIRK_FRAME_NO;
 
+   if (of_property_read_bool(dev->dev.of_node,
+ "remote-wakeup-connected"))
+   ohci->hc_control = OHCI_CTRL_RWC;
+
of_property_read_u32(dev->dev.of_node, "num-ports",
 >num_ports);
 
@@ -358,6 +362,7 @@ static int ohci_platform_resume(struct device *dev)
 static const struct of_device_id ohci_platform_ids[] = {
{ .compatible = "generic-ohci", },
{ .compatible = "cavium,octeon-6335-ohci", },
+   { .compatible = "ti,ohci-omap3", },
{ }
 };
 MODULE_DEVICE_TABLE(of, ohci_platform_ids);
-- 
2.13.0
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCHv3 0/3] Make ohci-platform usable for omap3/4/5

[Tony Lindgren]

Hi,

Here's v3 of this series.

Regards,

Tony

Changes since v2:

- Ignore pm_runtime_get_sync for remove(), not much we can do there
  as noted by Alan Stern

- Add acks

Changes since v1:   

  - Update runtime PM support for ohci 
based on Alan's comments and
  more testing  

  - Just remove ohci-omap3 as it needs 
LS/FS USB PHY not available
  on most hardware

Tony Lindgren (3):
  usb: host: ohci-platform: Add basic runtime PM support
  usb: host: ohci-platform: Add support for omap3 and later
  usb: host: ohci-omap3: Remove driver in favor of ohci-platform

 Documentation/devicetree/bindings/usb/usb-ohci.txt |   1 +
 drivers/usb/host/Kconfig   |   6 +-
 drivers/usb/host/Makefile  |   1 -
 drivers/usb/host/ohci-omap3.c  | 211 -
 drivers/usb/host/ohci-platform.c   |  13 ++
 5 files changed, 19 insertions(+), 213 deletions(-)
 delete mode 100644 drivers/usb/host/ohci-omap3.c

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

Re: Runtime PM enabled EHCI does not respond to device plugging.

[Alan Stern]

On Thu, 25 May 2017, Kai-Heng Feng wrote:

> > My mistake; we need to see the information from "lspci -vv -s 00:12.0"
> > with two "v"'s, not just one.
> 
> Before wakeup:
> 00:12.0 USB controller: Advanced Micro Devices, Inc. [AMD] FCH USB
> EHCI Controller (rev 39) (prog-if 20 [EHCI])
> Subsystem: Dell FCH USB EHCI Controller
> Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV+ VGASnoop-
> ParErr- Stepping- SERR- FastB2B- DisINTx-
> Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium
> >TAbort- SERR-  Interrupt: pin A routed to IRQ 18
> Region 0: Memory at fe769000 (32-bit, non-prefetchable) [size=256]
> Capabilities: [c0] Power Management version 2
> Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
> PME(D0+,D1+,D2+,D3hot+,D3cold+)
> Status: D3 NoSoftRst- PME-Enable+ DSel=0 DScale=0 PME-
> Bridge: PM- B3+
> Capabilities: [e4] Debug port: BAR=1 offset=00e0
> Kernel driver in use: ehci-pci

Was this before you plugged in the mouse or after?

If it was after, it means there is a bug in the EHCI controller
hardware.  This line:

> Status: D3 NoSoftRst- PME-Enable+ DSel=0 DScale=0 PME-

says that the PME signal is not enabled, so the controller is not
sending a wakeup request.  But when a new device gets plugged in, the
controller is supposed to ask to be woken up.

> After wakeup:
> 00:12.0 USB controller: Advanced Micro Devices, Inc. [AMD] FCH USB
> EHCI Controller (rev 39) (prog-if 20 [EHCI])
> Subsystem: Dell FCH USB EHCI Controller
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop-
> ParErr- Stepping- SERR- FastB2B- DisINTx-
> Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium
> >TAbort- SERR-  Latency: 32, Cache Line Size: 64 bytes
> Interrupt: pin A routed to IRQ 18
> Region 0: Memory at fe769000 (32-bit, non-prefetchable) [size=256]
> Capabilities: [c0] Power Management version 2
> Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
> PME(D0+,D1+,D2+,D3hot+,D3cold+)
> Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
> Bridge: PM- B3+
> Capabilities: [e4] Debug port: BAR=1 offset=00e0
> Kernel driver in use: ehci-pci

Yes, that is normal.

> > There's another piece of information you can collect.  Mount a
> > debugfs filesystem at /sys/kernel/debug, and then copy the contents of
> > the file
> >
> > /sys/kernel/debug/usb/ehci/:00:12.0/registers
> >
> > Do this while the controller is still asleep (after the mouse is
> > plugged in) and then again after it is awake.
> 
> Before wakeup:
> bus pci, device :00:12.0
> EHCI Host Controller
> SUSPENDED (no register access)
> 
> After wakeup:
> bus pci, device :00:12.0
> EHCI Host Controller
> EHCI 1.00, rh state running
> ownership 0001
> SMI sts/enable 0xc008
> structural params 0x0022
> capability params 0xa076
> status 4008 Periodic FLR
> command 0010015 (park)=0 ithresh=1 Periodic period=512 RUN
> intrenable 37 IAA FATAL PCD ERR INT
> uframe 2d5f
> port:1 status 001005 0  ACK POWER sig=se0 PE CONNECT
> port:2 status 001000 0  ACK POWER sig=se0
> irq normal 1855 err 10 iaa 98 (lost 0)
> complete 1865 unlink 10

Again, this is normal.

Alan Stern

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

Re: [PATCH v2] usb: typec: Add a sysfs node to manage port type

[Badhri Jagan Sridharan]

On Thu, May 25, 2017 at 12:48 AM, Guenter Roeck  wrote:
> On 05/24/2017 08:10 PM, Badhri Jagan Sridharan wrote:
>>
>> Thanks comments inline.
>>
>> On Tue, May 23, 2017 at 7:38 PM, Guenter Roeck  wrote:
>>>
>>> On 05/23/2017 06:28 PM, Badhri Jagan Sridharan wrote:


 User space applications in some cases have the need to enforce a
 specific port type(DFP/UFP/DRP). This change allows userspace to
 attempt setting the desired port type. Low level drivers can
 however reject the request if the specific port type is not supported.

 Signed-off-by: Badhri Jagan Sridharan 
 ---
 Changelog since v1:
 - introduced a new variable port_type in struct typec_port to track
 the current port type instead of changing type member in
 typec_capability to address Heikki Krogerus comments.
 - changed the output format and strings that would be displayed as
 suggested by Heikki Krogerus.
>
>Documentation/ABI/testing/sysfs-class-typec | 13 ++

drivers/usb/typec/typec.c   | 66
 +
include/linux/usb/typec.h   |  4 ++
3 files changed, 83 insertions(+)

 diff --git a/Documentation/ABI/testing/sysfs-class-typec
 b/Documentation/ABI/testing/sysfs-class-typec
 index d4a3d23eb09c..1f224c2e391f 100644
 --- a/Documentation/ABI/testing/sysfs-class-typec
 +++ b/Documentation/ABI/testing/sysfs-class-typec
 @@ -73,6 +73,19 @@ Description:
  Valid values: source, sink, none (to remove preference)
+What:   /sys/class/typec//port_type
 +Date:   May 2017
 +Description:
 +   Indicates the type of the port. This attribute can be
 used
 for
 +   requesting a change in the port type. Port type change
 is
 +   supported as a synchronous operation, so write(2) to the
 +   attribute will not return until the operation has
 finished.
 +
 +   Valid values:
 +   - source
 +   - sink
 +   - dual
 +
What: /sys/class/typec//supported_accessory_modes
Date: April 2017
Contact:  Heikki Krogerus 
 diff --git a/drivers/usb/typec/typec.c b/drivers/usb/typec/typec.c
 index 89e540bb7ff3..5063d6e0f8c7 100644
 --- a/drivers/usb/typec/typec.c
 +++ b/drivers/usb/typec/typec.c
 @@ -69,6 +69,7 @@ struct typec_port {
  enum typec_role pwr_role;
  enum typec_role vconn_role;
  enum typec_pwr_opmode   pwr_opmode;
 +   enum typec_port_typeport_type;
>>>
>>>
>>>
>>> I am missing where this variable is initialized (when the port is
>>> registered
>>> ?).
>>
>>
>> Yes.. I missed it while cleaning up the patch. Will add it to my next
>> patch.
>>
>>>
  const struct typec_capability   *cap;
};
 @@ -789,6 +790,12 @@ static const char * const typec_data_roles[] = {
  [TYPEC_HOST]= "host",
};
+static const char * const typec_port_types[] = {
 +   [TYPEC_PORT_DFP] = "source",
 +   [TYPEC_PORT_UFP] = "sink",
 +   [TYPEC_PORT_DRP] = "dual",
 +};
 +
static ssize_t
preferred_role_store(struct device *dev, struct device_attribute
 *attr,
   const char *buf, size_t size)
 @@ -856,6 +863,12 @@ static ssize_t data_role_store(struct device *dev,
  return -EOPNOTSUPP;
  }
+ if (port->port_type != TYPEC_PORT_DRP) {
 +   dev_dbg(dev, "port type fixed at \"%s\"",
 +typec_port_types[port->port_type]);
 +   return -EIO;
>>>
>>>
>>>
>>> ?? This is already there, or am I missing something ?
>>
>>
>> I am checking against the current value of port_type variable.
>> Dont we want to reject role swaps if the port_type is not
>> TYPEC_PORT_DRP ? My understanding is that if the port type
>> is fixed at say PORT_TYPE_DFP by userspace, then unless
>> the userspace sets port_type back to PORT_TYPE_DRP,
>> role swap requests have to rejected. Is my understanding not
>> correct ?
>>
>
> Ah yes, the existing check is for port->cap->type. But why not just
> replace that check with port->port_type ? Checking both seems overkill.

Thanks. Sure will stick to just checking port->port_type.

>
>>>
 +   }
 +
  ret = sysfs_match_string(typec_data_roles, buf);
  if (ret < 0)
  return ret;
 @@ -897,6 +910,12 @@ static ssize_t power_role_store(struct device *dev,
  return -EOPNOTSUPP;
  }
+ if (port->port_type != TYPEC_PORT_DRP) {

[PATCH] usb: musb: dsps: keep VBUS on for host-only mode

[Bin Liu]

Currently VBUS is turned off while a usb device is detached, and turned
on again by the polling routine. This short period VBUS loss prevents
usb modem to switch mode.

VBUS should be constantly on for host-only mode, so this changes the
driver to not turn off VBUS for host-only mode.

Fixes: 2f3fd2c5bde1 ("usb: musb: Prepare dsps glue layer for PM runtime 
support")
Cc: sta...@vger.kernel.org #v4.11
Reported-by: Moreno Bartalucci 
Acked-by: Tony Lindgren 
Signed-off-by: Bin Liu 
---
 drivers/usb/musb/musb_dsps.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 9c7ee26ef388..bc6a9be2ccc5 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -245,6 +245,11 @@ static int dsps_check_status(struct musb *musb, void 
*unused)
dsps_mod_timer_optional(glue);
break;
case OTG_STATE_A_WAIT_BCON:
+   /* keep VBUS on for host-only mode */
+   if (musb->port_mode == MUSB_PORT_MODE_HOST) {
+   dsps_mod_timer_optional(glue);
+   break;
+   }
musb_writeb(musb->mregs, MUSB_DEVCTL, 0);
skip_session = 1;
/* fall */
-- 
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] musb fixes for v4.12-rc3

[Bin Liu]

Hi Greg,

Here is just one fix for v4.12-rc3. It fixes a musb regression which happens
since v4.9. I will send a separate backport for v4.9-stable. Please let me know
if any change is needed.

Regards,
-Bin.
---

Bin Liu (1):
  usb: musb: dsps: keep VBUS on for host-only mode

 drivers/usb/musb/musb_dsps.c | 5 +
 1 file changed, 5 insertions(+)

-- 
1.9.1

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

Re: [PATCH v2] usb: typec: Add a sysfs node to manage port type

[Guenter Roeck]

On Thu, May 25, 2017 at 11:24:20AM -0700, Badhri Jagan Sridharan wrote:
> On Thu, May 25, 2017 at 12:48 AM, Guenter Roeck  wrote:
> > On 05/24/2017 08:10 PM, Badhri Jagan Sridharan wrote:
> >>
> >> Thanks comments inline.
> >>
> >> On Tue, May 23, 2017 at 7:38 PM, Guenter Roeck  wrote:
> >>>
> >>> On 05/23/2017 06:28 PM, Badhri Jagan Sridharan wrote:
> 
> 
>  User space applications in some cases have the need to enforce a
>  specific port type(DFP/UFP/DRP). This change allows userspace to
>  attempt setting the desired port type. Low level drivers can
>  however reject the request if the specific port type is not supported.
> 
>  Signed-off-by: Badhri Jagan Sridharan 
>  ---
>  Changelog since v1:
>  - introduced a new variable port_type in struct typec_port to track
>  the current port type instead of changing type member in
>  typec_capability to address Heikki Krogerus comments.
>  - changed the output format and strings that would be displayed as
>  suggested by Heikki Krogerus.
> >
> >Documentation/ABI/testing/sysfs-class-typec | 13 ++
> 
> drivers/usb/typec/typec.c   | 66
>  +
> include/linux/usb/typec.h   |  4 ++
> 3 files changed, 83 insertions(+)
> 
>  diff --git a/Documentation/ABI/testing/sysfs-class-typec
>  b/Documentation/ABI/testing/sysfs-class-typec
>  index d4a3d23eb09c..1f224c2e391f 100644
>  --- a/Documentation/ABI/testing/sysfs-class-typec
>  +++ b/Documentation/ABI/testing/sysfs-class-typec
>  @@ -73,6 +73,19 @@ Description:
>   Valid values: source, sink, none (to remove preference)
> +What:   /sys/class/typec//port_type
>  +Date:   May 2017
>  +Description:
>  +   Indicates the type of the port. This attribute can be
>  used
>  for
>  +   requesting a change in the port type. Port type change
>  is
>  +   supported as a synchronous operation, so write(2) to the
>  +   attribute will not return until the operation has
>  finished.
>  +
>  +   Valid values:
>  +   - source
>  +   - sink
>  +   - dual
>  +
> What: /sys/class/typec//supported_accessory_modes
> Date: April 2017
> Contact:  Heikki Krogerus 
>  diff --git a/drivers/usb/typec/typec.c b/drivers/usb/typec/typec.c
>  index 89e540bb7ff3..5063d6e0f8c7 100644
>  --- a/drivers/usb/typec/typec.c
>  +++ b/drivers/usb/typec/typec.c
>  @@ -69,6 +69,7 @@ struct typec_port {
>   enum typec_role pwr_role;
>   enum typec_role vconn_role;
>   enum typec_pwr_opmode   pwr_opmode;
>  +   enum typec_port_typeport_type;
> >>>
> >>>
> >>>
> >>> I am missing where this variable is initialized (when the port is
> >>> registered
> >>> ?).
> >>
> >>
> >> Yes.. I missed it while cleaning up the patch. Will add it to my next
> >> patch.
> >>
> >>>
>   const struct typec_capability   *cap;
> };
>  @@ -789,6 +790,12 @@ static const char * const typec_data_roles[] = {
>   [TYPEC_HOST]= "host",
> };
> +static const char * const typec_port_types[] = {
>  +   [TYPEC_PORT_DFP] = "source",
>  +   [TYPEC_PORT_UFP] = "sink",
>  +   [TYPEC_PORT_DRP] = "dual",
>  +};
>  +
> static ssize_t
> preferred_role_store(struct device *dev, struct device_attribute
>  *attr,
>    const char *buf, size_t size)
>  @@ -856,6 +863,12 @@ static ssize_t data_role_store(struct device *dev,
>   return -EOPNOTSUPP;
>   }
> + if (port->port_type != TYPEC_PORT_DRP) {
>  +   dev_dbg(dev, "port type fixed at \"%s\"",
>  +typec_port_types[port->port_type]);
>  +   return -EIO;
> >>>
> >>>
> >>>
> >>> ?? This is already there, or am I missing something ?
> >>
> >>
> >> I am checking against the current value of port_type variable.
> >> Dont we want to reject role swaps if the port_type is not
> >> TYPEC_PORT_DRP ? My understanding is that if the port type
> >> is fixed at say PORT_TYPE_DFP by userspace, then unless
> >> the userspace sets port_type back to PORT_TYPE_DRP,
> >> role swap requests have to rejected. Is my understanding not
> >> correct ?
> >>
> >
> > Ah yes, the existing check is for port->cap->type. But why not just
> > replace that check with port->port_type ? Checking both seems overkill.
> 
> Thanks. Sure will stick to just checking port->port_type.
> 
> >
> >>>
>  +   }
> 

[PATCH] usb: host: xhci: reliable endpoint reset after halt

[gavinli]

From: Gavin Li 

If a stalling TRB is cancelled and NOOP'ed in xhci_handle_cmd_stop_ep(),
finish_td() never gets called to reset the halted endpoint and the
endpoint remains indefinitely stalled. This patch ensures that
xhci_cleanup_halted_endpoint() is called after a TRB completion if the
endpoint is halted, irregardless of the status of any pending TRBs.
---
 drivers/usb/host/xhci-ring.c | 34 +-
 drivers/usb/host/xhci.h  |  1 +
 2 files changed, 30 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 03f63f50afb6..85bc53d0d43e 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -1113,11 +1113,13 @@ static void xhci_handle_cmd_reset_ep(struct xhci_hcd 
*xhci, int slot_id,
 {
struct xhci_virt_device *vdev;
struct xhci_ep_ctx *ep_ctx;
+   struct xhci_virt_ep *ep;
unsigned int ep_index;
 
ep_index = TRB_TO_EP_INDEX(le32_to_cpu(trb->generic.field[3]));
vdev = xhci->devs[slot_id];
ep_ctx = xhci_get_ep_ctx(xhci, vdev->out_ctx, ep_index);
+   ep = >devs[slot_id]->eps[ep_index];
trace_xhci_handle_cmd_reset_ep(ep_ctx);
 
/* This command will only fail if the endpoint wasn't halted,
@@ -1130,6 +1132,7 @@ static void xhci_handle_cmd_reset_ep(struct xhci_hcd 
*xhci, int slot_id,
 * command complete before the endpoint can be used.  Queue that here
 * because the HW can't handle two commands being queued in a row.
 */
+   ep->ep_state &= ~EP_RESET_PENDING;
if (xhci->quirks & XHCI_RESET_EP_QUIRK) {
struct xhci_command *command;
 
@@ -1145,7 +1148,11 @@ static void xhci_handle_cmd_reset_ep(struct xhci_hcd 
*xhci, int slot_id,
xhci_ring_cmd_db(xhci);
} else {
/* Clear our internal halted state */
-   xhci->devs[slot_id]->eps[ep_index].ep_state &= ~EP_HALTED;
+   ep->ep_state &= ~EP_HALTED;
+   if (!(ep->ep_state & SET_DEQ_PENDING)) {
+   /* Restart any rings with pending URBs */
+   ring_doorbell_for_active_rings(xhci, slot_id, ep_index);
+   }
}
 }
 
@@ -1800,19 +1807,25 @@ struct xhci_segment *trb_in_td(struct xhci_hcd *xhci,
 static void xhci_cleanup_halted_endpoint(struct xhci_hcd *xhci,
unsigned int slot_id, unsigned int ep_index,
unsigned int stream_id,
-   struct xhci_td *td, union xhci_trb *ep_trb)
+   struct xhci_td *td)
 {
struct xhci_virt_ep *ep = >devs[slot_id]->eps[ep_index];
struct xhci_command *command;
+
+   if (ep->ep_state & EP_RESET_PENDING)
+   return;
+
command = xhci_alloc_command(xhci, false, false, GFP_ATOMIC);
if (!command)
return;
 
-   ep->ep_state |= EP_HALTED;
+   ep->ep_state |= EP_HALTED | EP_RESET_PENDING;
ep->stopped_stream = stream_id;
 
xhci_queue_reset_ep(xhci, command, slot_id, ep_index);
-   xhci_cleanup_stalled_ring(xhci, ep_index, td);
+   if (td != NULL && !(ep->ep_state & SET_DEQ_PENDING)) {
+   xhci_cleanup_stalled_ring(xhci, ep_index, td);
+   }
 
ep->stopped_stream = 0;
 
@@ -1947,7 +1960,7 @@ static int finish_td(struct xhci_hcd *xhci, struct 
xhci_td *td,
 * The class driver clears the device side halt later.
 */
xhci_cleanup_halted_endpoint(xhci, slot_id, ep_index,
-   ep_ring->stream_id, td, ep_trb);
+   ep_ring->stream_id, td);
} else {
/* Update ring dequeue pointer */
while (ep_ring->dequeue != td->last_trb)
@@ -2588,6 +2601,17 @@ static int handle_tx_event(struct xhci_hcd *xhci,
 */
} while (handling_skipped_tds);
 
+   /*
+* If a cancelled TRB halts the endpoint, reset it here.
+*/
+   if (trb_comp_code == COMP_STALL_ERROR ||
+   xhci_requires_manual_halt_cleanup(xhci, ep_ctx,
+   trb_comp_code)) {
+   /* No harm in calling this twice; second call will be a no-op */
+   xhci_cleanup_halted_endpoint(xhci, slot_id, ep_index,
+   ep_ring->stream_id, td);
+   }
+
return 0;
 }
 
diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index 73a28a986d5e..0f7439f4d414 100644
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -922,6 +922,7 @@ struct xhci_virt_ep {
 #define EP_HAS_STREAMS (1 << 4)
 /* Transitioning the endpoint to not using streams, don't enqueue URBs */
 #define EP_GETTING_NO_STREAMS  (1 << 5)
+#define EP_RESET_PENDING  (1 << 6) /* For stall recovery */
/*   Related to URB cancellation  */
struct list_head