Re: [PATCH 00/47] arch-removal: device drivers

[Boris Brezillon]

Hi Arnd,

On Wed, 14 Mar 2018 16:35:13 +0100
Arnd Bergmann  wrote:

> Hi driver maintainers,
> 
> I just posted one series with the removal of eight architectures,
> see https://lkml.org/lkml/2018/3/14/505 for details, or
> https://lwn.net/Articles/748074/ for more background.
> 
> These are the device drivers that go along with them. I have already
> picked up the drivers for arch/metag/ into my tree, they were reviewed
> earlier.
> 
> Please let me know if you have any concerns with the patch, or if you
> prefer to pick up the patches in your respective trees.  I created
> the patches with 'git format-patch -D', so they will not apply without
> manually removing those files.
> 
> For anything else, I'd keep the removal patches in my asm-generic tree
> and will send a pull request for 4.17 along with the actual arch removal.
> 
>Arnd
> 
> Arnd Bergmann
>   edac: remove tile driver
>   net: tile: remove ethernet drivers
>   net: adi: remove blackfin ethernet drivers
>   net: 8390: remove m32r specific bits
>   net: remove cris etrax ethernet driver
>   net: smsc: remove m32r specific smc91x configuration
>   raid: remove tile specific raid6 implementation
>   rtc: remove tile driver
>   rtc: remove bfin driver
>   char: remove obsolete ds1302 rtc driver
>   char: remove tile-srom.c
>   char: remove blackfin OTP driver
>   pcmcia: remove m32r drivers
>   pcmcia: remove blackfin driver
>   ASoC: remove blackfin drivers
>   video/logo: remove obsolete logo files
>   fbdev: remove blackfin drivers
>   fbdev: s1d13xxxfb: remove m32r specific hacks
>   crypto: remove blackfin CRC driver
>   media: platform: remove blackfin capture driver
>   media: platform: remove m32r specific arv driver
>   cpufreq: remove blackfin driver
>   cpufreq: remove cris specific drivers
>   gpio: remove etraxfs driver
>   pinctrl: remove adi2/blackfin drivers
>   ata: remove bf54x driver
>   input: keyboard: remove bf54x driver
>   input: misc: remove blackfin rotary driver
>   mmc: remove bfin_sdh driver
>   can: remove bfin_can driver
>   watchdog: remove bfin_wdt driver
>   mtd: maps: remove bfin-async-flash driver
>   mtd: nand: remove bf5xx_nand driver

If you don't mind, I'd like to take the mtd patches through the MTD
tree. As you've probably noticed, nand code has been moved around and
it's easier for me to carry those 2 simple changes in my tree than
creating an immutable branch.

Let me know if this is a problem.

Regards,

Boris

-- 
Boris Brezillon, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 07/12] staging: typec: tcpci: register port before request irq

[Guenter Roeck]

On Tue, Mar 13, 2018 at 05:34:33PM +0800, Li Jun wrote:
> With that we can clear any pending events and the port is registered
> so driver can be ready to handle typec events once we request irq.
> 
> Signed-off-by: Peter Chen 
> Signed-off-by: Li Jun 
> ---
>  drivers/staging/typec/tcpci.c | 15 ---
>  1 file changed, 8 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/staging/typec/tcpci.c b/drivers/staging/typec/tcpci.c
> index ba4627f..f5a3bf5 100644
> --- a/drivers/staging/typec/tcpci.c
> +++ b/drivers/staging/typec/tcpci.c
> @@ -600,25 +600,26 @@ static int tcpci_probe(struct i2c_client *client,
>   if (IS_ERR(chip->data.regmap))
>   return PTR_ERR(chip->data.regmap);
>  
> + i2c_set_clientdata(client, chip);
> +
>   /* Disable chip interrupts before requesting irq */
>   err = regmap_raw_write(chip->data.regmap, TCPC_ALERT_MASK, &val,
>  sizeof(u16));
>   if (err < 0)
>   return err;
>  
> + chip->tcpci = tcpci_register_port(&client->dev, &chip->data);
> + if (PTR_ERR_OR_ZERO(chip->tcpci))
> + return PTR_ERR(chip->tcpci);
> +

I am concerned that the regitration above might already trigger commands,
and that we might miss interrupts if that is the case.

Would it make sense to check for chip->tcpci in the interrupt handler instead ?

>   err = devm_request_threaded_irq(&client->dev, client->irq, NULL,
>   _tcpci_irq,
>   IRQF_ONESHOT | IRQF_TRIGGER_LOW,
>   dev_name(&client->dev), chip);
>   if (err < 0)
> - return err;
> + tcpci_unregister_port(chip->tcpci);
>  
> - chip->tcpci = tcpci_register_port(&client->dev, &chip->data);
> - if (PTR_ERR_OR_ZERO(chip->tcpci))
> - return PTR_ERR(chip->tcpci);
> -
> - i2c_set_clientdata(client, chip);
> - return 0;
> + return err;
>  }
>  
>  static int tcpci_remove(struct i2c_client *client)
> -- 
> 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: [PATCH v3 08/12] staging: typec: tcpci: enable vbus detection

[Guenter Roeck]

On Tue, Mar 13, 2018 at 05:34:34PM +0800, Li Jun wrote:
> TCPCI implementation may need SW to enable VBUS detection to generate
> power status events.
> 
> Signed-off-by: Li Jun 

Makes sense to me. Only question might be if this should be dones before
checking the power status at the beginnng of the function. Any thoughts ?

Otherwise

Reviewed-by: Guenter Roeck 

> ---
>  drivers/staging/typec/tcpci.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/drivers/staging/typec/tcpci.c b/drivers/staging/typec/tcpci.c
> index f5a3bf5..9a230c6 100644
> --- a/drivers/staging/typec/tcpci.c
> +++ b/drivers/staging/typec/tcpci.c
> @@ -373,6 +373,12 @@ static int tcpci_init(struct tcpc_dev *tcpc)
>   if (ret < 0)
>   return ret;
>  
> + /* Enable Vbus detection */
> + ret = regmap_write(tcpci->regmap, TCPC_COMMAND,
> +TCPC_CMD_ENABLE_VBUS_DETECT);
> + if (ret < 0)
> + return ret;
> +
>   reg = TCPC_ALERT_TX_SUCCESS | TCPC_ALERT_TX_FAILED |
>   TCPC_ALERT_TX_DISCARDED | TCPC_ALERT_RX_STATUS |
>   TCPC_ALERT_RX_HARD_RST | TCPC_ALERT_CC_STATUS;
> -- 
> 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: [PATCH v3 11/12] staging: typec: tcpci: Only touch target bit when enable vconn

[Guenter Roeck]

On Tue, Mar 13, 2018 at 05:34:37PM +0800, Li Jun wrote:
> We need regmap_update_bits to avoid touch any other bits when
> enable or disable vconn.
> 
> Signed-off-by: Li Jun 

Reviewed-by: Guenter Roeck 

> ---
>  drivers/staging/typec/tcpci.c | 9 +++--
>  1 file changed, 3 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/staging/typec/tcpci.c b/drivers/staging/typec/tcpci.c
> index 6fdb179..46c4cff 100644
> --- a/drivers/staging/typec/tcpci.c
> +++ b/drivers/staging/typec/tcpci.c
> @@ -219,12 +219,9 @@ static int tcpci_set_vconn(struct tcpc_dev *tcpc, bool 
> enable)
>   return ret;
>   }
>  
> - ret = regmap_write(tcpci->regmap, TCPC_POWER_CTRL,
> -enable ? TCPC_POWER_CTRL_VCONN_ENABLE : 0);
> - if (ret < 0)
> - return ret;
> -
> - return 0;
> + return regmap_update_bits(tcpci->regmap, TCPC_POWER_CTRL,
> + TCPC_POWER_CTRL_VCONN_ENABLE,
> + enable ? TCPC_POWER_CTRL_VCONN_ENABLE : 0);
>  }
>  
>  static int tcpci_set_roles(struct tcpc_dev *tcpc, bool attached,
> -- 
> 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

Intel GemniLake xHCI connected devices can never wake up the system from suspend

[Chris Chiu]

Hi,
I  have a ASUS AIO V222GA and another Acer Desktop XC-830 both
have Intel CPU J5005 and they both hit the same problem. The XHCI
connected USB keyboard/mouse can never wakeup the system from suspend.
It reminds me that similiar thing happens on ApolloLake too which
needs the XHCI_PME_STUCK_QUIRK to get it work. It's also mentioned in
https://www.intel.com/content/dam/www/public/us/en/documents/specification-updates/pentium-celeron-n-series-spec-update.pdf
page #14 for N-seris intel CPU. And I also find the same problem
description in 
https://www.intel.com/content/dam/www/public/us/en/documents/product-briefs/silver-celeron-spec-update.pdf
page #16 for J-series Intel CPU. Seems that they have different
workaround so I can not simply apply XHCI_PME_STUCK_QUIRK to make it
work.

Anyone can help here?

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

DWC2 maintainership change

[John Youn]

Hi Felipe, Greg,

I won't be able to continue maintainership of dwc2.

Minas Harutyunyan, has been doing most of the communication on linux-usb lately 
and much of the maintenance and development work. He has excellent knowledge of 
the controller, having worked with it since its inception many years ago.

I propose that he take over as the new maintainer.

Regards,
John


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

Re: Debugging SCSI 'UNMAP' ("Logical Block Provisioning") failure on an SSD

[Martin K. Petersen]

Kashyap,

> Sorry, I didn't give you complete information — with the previous
> `dmesg` output, I actually attached the SSD (Samsung T5) via regular USB
> "A Cable".  
>
> Now, I re-attached the SSD via the "Thunderbolt" port on my other laptop
> (Lenovo T470s), it _does_ show "UAS".   Refer the arrow below:

Do you get different sg_readcap -l output when accessing it in UAS mode?
I.e. is lbpme=1?

-- 
Martin K. Petersen  Oracle Linux Engineering
--
To unsubscribe from this list: send the line "unsubscribe 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 v4 13/15] usb: dwc3: Add workaround for isoc start transfer failure

[Thinh Nguyen]

Hi Felipe,

On 3/14/2018 1:56 AM, Felipe Balbi wrote:
> 
> Hi,
> 
> Thinh Nguyen  writes:
>>> Thinh Nguyen  writes:
 In DWC_usb31 version 1.70a-ea06 and prior, for highspeed and fullspeed
 isochronous IN, BIT[15:14] of the 16-bit microframe number reported by
 the XferNotReady event are invalid. The driver uses this number to
 schedule the isochronous transfer and passes it to the START TRANSFER
 command. Because this number is invalid, the command may fail. If
 BIT[15:14] matches the internal 16-bit microframe, the START TRANSFER
 command will pass and the transfer will start at the scheduled time, if
 it is off by 1, the command will still pass, but the transfer will start
 2 seconds in the future. All other conditions the START TRANSFER command
 will fail with bus-expiry.

 In order to workaround this issue, we can issue multiple START TRANSFER
 commands with different values of BIT[15:14]: 'b00, 'b01, 'b10, and 'b11
 and do an END TRANSFER command. Each combination is 2 seconds apart. 4
 seconds into the future will cause a bus-expiry failure. As the result,
 within the 4 possible combinations for BIT[15:14], there will be 2
 successful and 2 failure START COMMAND status. One of the 2 successful
 command status will result in a 2-second delay. The smaller BIT[15:14]
 value is the correct one.

 Since there are only 4 outcomes and the results are ordered, we can
 simply test 2 START TRANSFER commands with BIT[15:14] combinations 'b00
 and 'b01 to deduce the smallest successful combination.

   +-+-+
   | BIT(15) | BIT(14) |
   +=+=+
test0  |   0 |0|
   +-+-+
test1  |   0 |1|
   +-+-+

 With test0 and test1 BIT[15:14] combinations, here is the logic:
 if test0 passes and test1 passes, BIT[15:14] is 'b00
 if test0 passes and test1 fails, BIT[15:14] is 'b11
 if test0 fails and test1 fails, BIT[15:14] is 'b10
 if test0 fails and test1 passes, BIT[15:14] is 'b01

 Synopsys STAR 9001202023: Wrong microframe number for isochronous IN
 endpoints.

 Signed-off-by: Thinh Nguyen 
 ---
drivers/usb/dwc3/core.c   |   2 +
drivers/usb/dwc3/core.h   |  13 
drivers/usb/dwc3/gadget.c | 189 
 --
3 files changed, 199 insertions(+), 5 deletions(-)

 diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
 index ddcfa2a60d4b..d27ddfcc3b8a 100644
 --- a/drivers/usb/dwc3/core.c
 +++ b/drivers/usb/dwc3/core.c
>>>
>>> ... because all these tests could be combined in a simple place and
>>> moved inside dwc3_set_isoc_start_frame() so that you could
>>> unconditionally call it here.
>>>
>>> I'll go ahead and drop this series from this merge window, it clearly
>>> needs much more work.
>>>
>>
>> Thank you for reviewing the patches. I'll make the change to this patch
>> for the next merge window. However, can you cherry-pick the other
>> patches in this series for this merge window? If they also need more
>> work, please let me know.
> 
> I don't think it makes sense to pick the others without this, specially
> since you're touching usb core on patch 2 and I can't apply that. I did,
> however, take Mass Storage patch setting its max speed to SSP.
> 

The patch to the usb core is unrelated to this workaround. Only 3 of the 
patches are related to the workaround. Other updates are independent of 
it. The ones that are related are marked with 'X' in the list below:

Thinh Nguyen (15):
   usb: dwc3: Add SoftReset PHY synchonization delay
   usb: core: urb: Check SSP isoc ep comp descriptor
   usb: dwc3: Update DWC_usb31 GTXFIFOSIZ reg fields
   usb: dwc3: Check IP revision for GTXFIFOSIZ
   usb: dwc3: Add DWC_usb31 GRXTHRCFG bit fields
   usb: dwc3: gadget: Check IP revision for GRXTHRCFG
   usb: dwc3: Add DWC_usb31 GTXTHRCFG reg fields
   usb: dwc3: Make TX/RX threshold configurable
   usb: dwc3: Check for ESS TX/RX threshold config
   usb: dwc3: Dump LSP and BMU debug info
X usb: dwc3: Track DWC_usb31 VERSIONTYPE
X usb: dwc3: Add disabling of start_transfer failure quirk
X usb: dwc3: Add workaround for isoc start transfer failure
   usb: dwc3: Check controller type before setting speed
   usb: gadget: mass_storage: Set max_speed to SSP

It would be great if you can apply them this merge window.

Thank you!
Thinh
--
To unsubscribe from this list: send the line "unsubscribe 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] lan78xx: Connect phy early

[Andrew Lunn]

> @@ -2082,8 +2082,6 @@ static int lan78xx_phy_init(struct lan78xx_net *dev)
>  
>   dev->fc_autoneg = phydev->autoneg;
>  
> - phy_start(phydev);
> -
>   netif_dbg(dev, ifup, dev->net, "phy initialised successfully");
>  
>   return 0;
> @@ -2512,9 +2510,7 @@ static int lan78xx_open(struct net_device *net)
>   if (ret < 0)
>   goto done;
>  
> - ret = lan78xx_phy_init(dev);
> - if (ret < 0)
> - goto done;
> + phy_start(net->phydev);

Should the debug message be moved as well?

   Andrew
--
To unsubscribe from this list: send the line "unsubscribe 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: Leak of queue heads in DWC2 driver?

[Paul Zimmerman]

On Tue, 13 Mar 2018 06:22:30 +, Minas Harutyunyan 
 wrote:

> Hi Paul,
> 
> On 3/13/2018 6:26 AM, Paul Zimmerman wrote:
> > Hi Minas,
> > 
> > While ‌looking at the QH queuing in the DWC2 driver, I think I've found
> > some places where the QH struct may not be freed. Normally, the sequence is:
> > 
> > dwc2_hcd_qh_unlink();
> > < other stuff >
> > dwc2_hcd_qh_free();
> > 
> > or else:
> > 
> > dwc2_hcd_qh_unlink();
> > < other stuff >
> > < link the QH to some other list >
> > 
> > For non-periodic EPs, dwc2_hcd_qh_unlink() does
> > list_del_init(&qh->qh_list_entry), or for periodic EPs it calls
> > dwc2_deschedule_periodic() which in turn does the list_del_init().
> > This means the QH is removed from whatever list it was on.
> > 
> > So after the call to dwc2_hcd_qh_unlink(), the QH either needs to be freed
> > by calling dwc2_hcd_qh_free(), or it needs to be re-linked to another list,
> > otherwise the QH would be "lost" and could never be freed.
> > 
> > The places where I think a problem can happen are in 
> > dwc2_hcd_qh_deactivate(),
> > dwc_hcd_urb_dequeue(), and dwc_hcd_complete_xfer_ddma(). In most if not all
> > of these places, interrupts are disabled, which means that 
> > dwc2_hcd_qh_free()
> > cannot be called, since it can sleep. So maybe the freeing was omitted 
> > because
> > it was hard to do in these places?
> > 
> > What do you think, am I reading the code correctly and this could be a real
> > problem, or am I crazy? :)
> > 
> 
> Thank you for your input. I'm planing to review all host code in 1 or 2 
> months. Yes, in host code there are lot of stuff should be 
> updated/corrected. Currently we want to complete all fixes/improvements 
> on gadget side. We still have lot of prepared patches in our queue which 
> need to be included in mainline Kernel. BTW, besides fixes/improvements 
> there are few new features like Service Interval support on device side 
> which currently under development and debugging.

Looks like this was a false alarm. What I missed is that a pointer to the QH
is saved in usb_host_endpoint->hcpriv, and when dwc2_hcd_endpoint_disable()
is called, the QH is fetched from there and then freed. I also added some
debugging code to count the number of QHs allocated, and did not see the
number rising, except when a new device was connected, and in that case
the count fell back to the previous number once the device was disconnected.

So nevermind, and sorry for the noise.

-- 
Paul
--
To unsubscribe from this list: send the line "unsubscribe 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: misc: uss720: more vendor/product ID's

[Daniel Gimpelevich]

Reporting two more VID/PID pairs that work with this driver, having used
an informational webpage  as a buying
guide now. The page listed additional working VID/PID pairs but did not
include these two. None were upstreamed. Also taking this opportunity to
sort the pairs numerically.

Of the two such cables now in my possession, one is white, bearing the
In-System Design ISD-103 label on one side, sold as an Epson CAEUL0002
"USB to Parallel Smart Cable For Apple Macintosh Computers" (04b8:0002),
and the other is black, bearing the In-System Design ISD-101 label on one
side, sold as an early Belkin F5U002 (05ab:0002).

Signed-off-by: Daniel Gimpelevich 
---
 drivers/usb/misc/uss720.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/misc/uss720.c b/drivers/usb/misc/uss720.c
index 263c97f..a208e4b 100644
--- a/drivers/usb/misc/uss720.c
+++ b/drivers/usb/misc/uss720.c
@@ -769,10 +769,15 @@ static void uss720_disconnect(struct usb_interface *intf)
 /* table of cables that work through this driver */
 static const struct usb_device_id uss720_table[] = {
{ USB_DEVICE(0x047e, 0x1001) },
+   { USB_DEVICE(0x04b8, 0x0002) }, /* Daniel Gimpelevich */
+   { USB_DEVICE(0x04b8, 0x0003) }, /* Added by Rab */
+   { USB_DEVICE(0x050d, 0x0002) }, /* Fabio Battaglia */
+   { USB_DEVICE(0x050d, 0x1202) }, /* Added by Rab */
{ USB_DEVICE(0x0557, 0x2001) },
+   { USB_DEVICE(0x05ab, 0x0002) }, /* Daniel Gimpelevich */
+   { USB_DEVICE(0x06c6, 0x0100) }, /* Added by Rab */
{ USB_DEVICE(0x0729, 0x1284) },
{ USB_DEVICE(0x1293, 0x0002) },
-   { USB_DEVICE(0x050d, 0x0002) },
{ } /* Terminating entry */
 };
 
-- 
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 v4 2/2] usb/gadget: Add driver for Aspeed SoC virtual hub

[Benjamin Herrenschmidt]

On Wed, 2018-03-14 at 10:54 +0200, Felipe Balbi wrote:
> Hi,
> 
> Benjamin Herrenschmidt  writes:
> > On Tue, 2018-03-13 at 09:35 +1100, Benjamin Herrenschmidt wrote:
> > > On Fri, 2018-03-09 at 11:20 +0200, Felipe Balbi wrote:
> > > > 
> > > > > diff --git a/drivers/usb/gadget/udc/aspeed-vhub/core.c 
> > > > > b/drivers/usb/gadget/udc/aspeed-vhub/core.c
> > > > > new file mode 100644
> > > > > index ..31ed2b6e241b
> > > > > --- /dev/null
> > > > > +++ b/drivers/usb/gadget/udc/aspeed-vhub/core.c
> > > > > @@ -0,0 +1,429 @@
> > > > 
> > > > missing SPDX license identifier (all files)
> > > 
> > > Ah yup, the driver predates me knowing about them, I'll fix.
> > > 
> > > > > +static bool force_usb1 = false;
> > > > > +static bool no_dma_desc = false;
> > > > > +
> > > > > +module_param_named(force_usb1, force_usb1, bool, 0644);
> > > > > +MODULE_PARM_DESC(force_usb1, "Set to true to force to USB1 speed");
> > > > > +module_param_named(no_dma_desc, no_dma_desc, bool, 0644);
> > > > > +MODULE_PARM_DESC(no_dma_desc, "Set to true to disable use of DMA 
> > > > > descriptors");
> > > > 
> > > > module parameters? Sorry, but no.
> > > 
> > > Why ? Any suggestion then for the two above ? They are mostly meant as
> > > diagnostic/debug features if something doesn't work (for example, the
> > > board has some sub-standard wiring making USB2 unreliable, or a driver
> > > bug with DMA descriptors).
> > > 
> > > I can just take them out completely but it feels like module parameters
> > > are the right thing to do in that specific case.
> > 
> > I've taken out the second one, it isn't that useful. I've left in the
> > first one however. This is the right thing to do. That setting (force
> > USB1 mode) needs to be applied as soon as the vhub gets initialized
> > at driver load time, regardless of what gadgets might be attached to
> > it later on.
> 
> we have DT binding for passing maximum speed. A module parameter is
> global, whereas DT binding (or device property) is per-device.

Hrm, ok I could do that. Less practical for diagnostics, you can't
always easily change the DT (or tell a user to do so over email), but
it would work.

> > > > > +void ast_vhub_init_hw(struct ast_vhub *vhub)
> > > > > +{
> > > > > +   u32 ctrl;
> > > > > +
> > > > > +   UDCDBG(vhub,"(Re)Starting HW ...\n");
> > > > > +
> > > > > +   /* Enable PHY */
> > > > > +   ctrl = VHUB_CTRL_PHY_CLK |
> > > > > +   VHUB_CTRL_PHY_RESET_DIS;
> > > > > +
> > > > > +#if 0 /*
> > > > > +   * This causes registers to become inaccessible during
> > > > > +   * suspend. Need to figure out how to bring the controller
> > > > > +   * back into life to issue a wakeup.
> > > > > +   */
> > > > > +   ctrl |= VHUB_CTRL_CLK_STOP_SUSPEND;
> > > > > +#endif
> > > > 
> > > > no commented code.
> > > 
> > > Why ? This documents a HW issue ... ie, one would normally want to set
> > > this bit but you can't because in practice you can't bring the HW back
> > > short of doing a full reset.
> > 
> > So I don't want to lose the "HW documentation" part of that, I've
> > turned the above into a comment:
> > 
> >   /*
> > * We do *NOT* set the VHUB_CTRL_CLK_STOP_SUSPEND bit
> > * to stop the logic clock during suspend because
> > * it causes the registers to become inaccessible and
> > * we haven't yet figured out a good wayt to bring the
> > * controller back into life to issue a wakeup.
> > */
> 
> this is good
> 
> > It will be in v5 when I post it (I'll test a bit more and wait
> > for other replies from you, if I don't hear back I'll probably send
> > it by end of week or next week).
> 
> okay
> 
> > > > > +   /*
> > > > > +* Set some ISO & split control bits according to Aspeed
> > > > > +* recommendation
> > > > > +*
> > > > > +* VHUB_CTRL_ISO_RSP_CTRL: When set tells the HW to respond
> > > > > +* with 0 bytes data packet to ISO IN endpoints when no data
> > > > > +* is available.
> > > > > +*
> > > > > +* VHUB_CTRL_SPLIT_IN: This makes a SOF complete a split IN
> > > > > +* transaction.
> > > > > +*/
> > > > > +   ctrl |= VHUB_CTRL_ISO_RSP_CTRL | VHUB_CTRL_SPLIT_IN;
> > > > > +   writel(ctrl, vhub->regs + AST_VHUB_CTRL);
> > > > > +   udelay(1);
> > > > > +
> > > > > +   /* Set descriptor ring size */
> > > > > +#if AST_VHUB_DESCS_COUNT == 256
> > > > > +   ctrl |= VHUB_CTRL_LONG_DESC;
> > > > > +   writel(ctrl, vhub->regs + AST_VHUB_CTRL);
> > > > > +#elif AST_VHUB_DESCS_COUNT != 32
> > > > > +   #error Invalid AST_VHUB_DESCS_COUNT
> > > > > +#endif
> > > > 
> > > > find a better way for this. No ifdefs
> > > 
> > > Ugh ? What's that rule ? I could do a module parameter but you hate
> > > that too and honestly keeping that an ifdef makes things easier. It's
> > > not meant to be changed unless a hardware or performance issues shows
> > > up, I wanted to keep both mode of operations available.
> > 
> > Oh well, I've just made it an if () and kept the #define, and the
> 

Re: [RFC v3] Add support for Sony PS2 OHCI

[Alan Stern]

On Wed, 14 Mar 2018, Fredrik Noring wrote:

> Hi Alan Stern,
> 
> > > > What happened to the changes to ohci_run() and ohci_irq() that were in 
> > > > v2 of this RFC?  Did you decide they weren't needed?
> > > 
> > > In v3 Jürgen Urban folded those changes into the driver functions
> > > 
> > >   ohci_ps2_enable(),
> > >   ohci_ps2_disable(),
> > >   ohci_ps2_start_hc() and
> > >   ohci_ps2_stop_hc()
> > > 
> > > in drivers/usb/host/ohci-ps2.c.
> > 
> > Good, I was going to suggest doing that.
> 
> There is one quirk with the ISR that perhaps could be clarified: For some
> reason we have to intercept ohci_irq to disable interrupts, as shown in the
> function below, otherwise the whole USB subsystem eventually will freeze up.
> 
> Is this a known OHCI problem? Is some part of its USB core ISR not reentrant?

The USB interrupt handlers in general are not reentrant.  Or if they 
are, it's more by accident than by design.

> static irqreturn_t ohci_ps2_irq(struct usb_hcd *hcd)
> {
>   struct ohci_hcd *ohci = hcd_to_ohci(hcd);
>   struct ohci_regs __iomem *regs = ohci->regs;
> 
>   /*
>* FIXME: For some reason OHCI_INTR_MIE is required in the
>* IRQ handler. Without it, reading a large amount of data
>* (> 1 GB) from a mass storage device results in a freeze.
>*/
>   ohci_writel(ohci, OHCI_INTR_MIE, ®s->intrdisable);
> 
>   return ohci_irq(hcd); /* Call normal IRQ handler. */
> }

This should not be needed; it indicates that something is wrong with 
the way interrupt requests are handled on this platform.

Are you using threaded interrupts at all?  If you are, you have to 
change the spin_lock() call in ohci_irq() to spin_lock_irqsave().  You 
could try making this change in any case, to see if it prevents the 
freezes.

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

uvc-gadget created with configfs sets all bFrameIndex to 1

[Joel Pepper]

I am currently working on an application for my master thesis that does
transparent inline modification of  frames received from a uvc webcam
which are served to the actual host through a uvc gadget mimicking the
underlying webcam. I recently noticed that the host side v4l2 driver
would only ever request bFrameIndex 1, no matter the requested format.


So I used usbmon to take a closer look (pcap is attached ). Take a look
at the Video Streaming interface descriptor in packet no. 6: All 19
different framesizes have their bFrameIndex set to 1. This makes
requesting any framesize but the actual first one impossible.


I took a quick look at drivers/usb/gadget/function/uvc_configfs.c and
noticed that the bFrameIndex attribute of a frame is set to 1 per
default in "uvcg_frame_make"**, but the attribute is neither made
accessible through configfs nor could I see any mechanism by which the
indices are set automatically.


As I am new to kernel development, I wanted ask for comment first before
I start brewing up a possible patch for this bug. Currently I see three
solutions:

1) Expose bFrameIndex through ConfigFs, to be set by the user

2) Assign an unused bFrameIndex during "uvcg_frame_make"

3) Once framesizes of a format are finalized, iterate through frames and
assign ascending indices


There is also obviously the possibility that I gravely misconfigured my
gadget through configfs, if so please point me in the right direction.


Regards,

Joel



bFrameIndex_bug.pcapng
Description: application/pcapng

Re: [RFC v3] Add support for Sony PS2 OHCI

[Fredrik Noring]

Hi Alan Stern,

> > > What happened to the changes to ohci_run() and ohci_irq() that were in 
> > > v2 of this RFC?  Did you decide they weren't needed?
> > 
> > In v3 Jürgen Urban folded those changes into the driver functions
> > 
> > ohci_ps2_enable(),
> > ohci_ps2_disable(),
> > ohci_ps2_start_hc() and
> > ohci_ps2_stop_hc()
> > 
> > in drivers/usb/host/ohci-ps2.c.
> 
> Good, I was going to suggest doing that.

There is one quirk with the ISR that perhaps could be clarified: For some
reason we have to intercept ohci_irq to disable interrupts, as shown in the
function below, otherwise the whole USB subsystem eventually will freeze up.

Is this a known OHCI problem? Is some part of its USB core ISR not reentrant?

static irqreturn_t ohci_ps2_irq(struct usb_hcd *hcd)
{
struct ohci_hcd *ohci = hcd_to_ohci(hcd);
struct ohci_regs __iomem *regs = ohci->regs;

/*
 * FIXME: For some reason OHCI_INTR_MIE is required in the
 * IRQ handler. Without it, reading a large amount of data
 * (> 1 GB) from a mass storage device results in a freeze.
 */
ohci_writel(ohci, OHCI_INTR_MIE, ®s->intrdisable);

return ohci_irq(hcd); /* Call normal IRQ handler. */
}

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

Re: [PATCH v3 09/12] typec: tcpm: add starting value for drp toggling

[Guenter Roeck]

On Tue, Mar 13, 2018 at 05:34:35PM +0800, Li Jun wrote:
> As DRP port autonomously toggles the Rp/Rd need a start value to
> begin with, so add one parameter for it in tcpm_start_drp_toggling.
> 
> Signed-off-by: Li Jun 

Reviewed-by: Guenter Roeck 

> ---
>  drivers/usb/typec/tcpm.c | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/usb/typec/tcpm.c b/drivers/usb/typec/tcpm.c
> index 0bd34c9..ef3a60d 100644
> --- a/drivers/usb/typec/tcpm.c
> +++ b/drivers/usb/typec/tcpm.c
> @@ -1990,15 +1990,15 @@ static int tcpm_set_charge(struct tcpm_port *port, 
> bool charge)
>   return 0;
>  }
>  
> -static bool tcpm_start_drp_toggling(struct tcpm_port *port)
> +static bool tcpm_start_drp_toggling(struct tcpm_port *port,
> + enum typec_cc_status cc)
>  {
>   int ret;
>  
>   if (port->tcpc->start_drp_toggling &&
>   port->port_type == TYPEC_PORT_DRP) {
>   tcpm_log_force(port, "Start DRP toggling");
> - ret = port->tcpc->start_drp_toggling(port->tcpc,
> -  tcpm_rp_cc(port));
> + ret = port->tcpc->start_drp_toggling(port->tcpc, cc);
>   if (!ret)
>   return true;
>   }
> @@ -2308,7 +2308,7 @@ static void run_state_machine(struct tcpm_port *port)
>   if (!port->non_pd_role_swap)
>   tcpm_swap_complete(port, -ENOTCONN);
>   tcpm_src_detach(port);
> - if (tcpm_start_drp_toggling(port)) {
> + if (tcpm_start_drp_toggling(port, tcpm_rp_cc(port))) {
>   tcpm_set_state(port, DRP_TOGGLING, 0);
>   break;
>   }
> @@ -2480,7 +2480,7 @@ static void run_state_machine(struct tcpm_port *port)
>   if (!port->non_pd_role_swap)
>   tcpm_swap_complete(port, -ENOTCONN);
>   tcpm_snk_detach(port);
> - if (tcpm_start_drp_toggling(port)) {
> + if (tcpm_start_drp_toggling(port, TYPEC_CC_RD)) {
>   tcpm_set_state(port, DRP_TOGGLING, 0);
>   break;
>   }
> -- 
> 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: WARN_ON(irqs_disabled()) in dma_free_attrs?

[Robin Murphy]

On 13/03/18 13:17, Christoph Hellwig wrote:

On Tue, Mar 13, 2018 at 12:11:49PM +, Robin Murphy wrote:

Taking a step back, though, provided the original rationale about
dma_declare_coherent_memory() is still valid, I wonder if we should simply
permit the USB code to call dma_{alloc,free}_from_dev_coherent() directly
here instead of being "good" and indirecting through the top-level DMA API
(which is the part which leads to problems). Given that it's a specific DMA
bounce buffer implementation within a core API, not just any old driver
code, I personally would consider that reasonable.


Looking back I don't really understand why we even indirect the "classic"
per-device dma_declare_coherent_memory use case through the DMA API.


It certainly makes sense for devices which can exist in both 
shared-memory and device-local-memory configurations, so the driver 
doesn't have to care about the details (particularly on mobile SoCs 
where the 'local' memory might just be a chunk of system RAM reserved by 
the bootloader, and it's just a matter of different use-cases on 
identical hardware).



It seems like a pretty different use case to me.  In the USB case we
also have the following additional twist in that it doesn't even need
the mapping to be coherent.


I'm pretty sure it does (in the sense that it needs to ensure the arch 
code makes the mapping non-cacheable), otherwise I can't see how the 
bouncing could work properly. I think the last bit of the comment above 
hcd_alloc_coherent() is a bit misleading.



So maybe for now the quick fix is to move the sleep check as suggested
earlier in this thread, but in the long run we probably need to do some
major rework of how dma_declare_coherent_memory and friends work.


Maybe; I do think the specific hcd_alloc_coherent() case could still be 
fixed within the scope of the existing code, but it's not quite as clean 
and straightforward as I first thought, and the practical impact of 
tweaking the WARN should be effectively zero despite the theoretical 
edge cases it opens up. Do you want me to write it up as a proper patch?


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

Re: [PATCH 38/47] usb: musb: remove blackfin port

[Bin Liu]

Hi,

On Wed, Mar 14, 2018 at 04:35:51PM +0100, Arnd Bergmann wrote:
> The blackfin architecture is getting removed, so we can clean up
> all the special cases in the musb driver.
> 
> Signed-off-by: Arnd Bergmann 
> ---
>  drivers/usb/musb/Kconfig|  10 +-
>  drivers/usb/musb/Makefile   |   1 -
>  drivers/usb/musb/blackfin.c | 623 
> 
>  drivers/usb/musb/blackfin.h |  81 --
>  drivers/usb/musb/musb_core.c|   5 -
>  drivers/usb/musb/musb_core.h|  30 --
>  drivers/usb/musb/musb_debugfs.c |   2 -
>  drivers/usb/musb/musb_dma.h |  11 -
>  drivers/usb/musb/musb_gadget.c  |  35 ---
>  drivers/usb/musb/musb_regs.h| 182 
>  drivers/usb/musb/musbhsdma.c|   5 -
>  drivers/usb/musb/musbhsdma.h|  64 -
>  include/linux/usb/musb.h|   7 -
>  13 files changed, 1 insertion(+), 1055 deletions(-)
>  delete mode 100644 drivers/usb/musb/blackfin.c
>  delete mode 100644 drivers/usb/musb/blackfin.h
> 
> diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig
> index 5506a9c03c1f..490990e8b015 100644
> --- a/drivers/usb/musb/Kconfig
> +++ b/drivers/usb/musb/Kconfig
> @@ -18,9 +18,6 @@ config USB_MUSB_HDRC

This config entry has "ADI" in its tristate message:

config USB_MUSB_HDRC
tristate 'Inventra Highspeed Dual Role Controller (TI, ADI, AW, ...)'

so we might want to remove it along with the whole parentheses?

-   tristate 'Inventra Highspeed Dual Role Controller (TI, ADI, AW, ...)'
+   tristate 'Inventra Highspeed Dual Role Controller'

Other than this,

Acked-by: Bin Liu 

Regards,
-Bin.
--
To unsubscribe from this list: send the line "unsubscribe 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 37/47] usb: host: remove tilegx platform glue

[Alan Stern]

On Wed, 14 Mar 2018, Greg Kroah-Hartman wrote:

> On Wed, Mar 14, 2018 at 04:35:50PM +0100, Arnd Bergmann wrote:
> > The tile architecture is getting removed, so the ehci and ohci platform
> > glue drivers are no longer needed. In case of ohci, this is the last
> > one to define a PLATFORM_DRIVER macro, so we can remove even more.
> > 
> > Signed-off-by: Arnd Bergmann 
> > ---
> >  drivers/usb/host/ehci-hcd.c|   5 -
> >  drivers/usb/host/ehci-tilegx.c | 207 
> > -
> >  drivers/usb/host/ohci-hcd.c|  18 
> >  drivers/usb/host/ohci-tilegx.c | 196 --
> >  include/linux/usb/tilegx.h |  35 ---
> >  5 files changed, 461 deletions(-)
> >  delete mode 100644 drivers/usb/host/ehci-tilegx.c
> >  delete mode 100644 drivers/usb/host/ohci-tilegx.c
> >  delete mode 100644 include/linux/usb/tilegx.h
> 
> Acked-by: Greg Kroah-Hartman 

Acked-by: Alan Stern 

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

Re: [PATCH 38/47] usb: musb: remove blackfin port

[Greg Kroah-Hartman]

On Wed, Mar 14, 2018 at 04:35:51PM +0100, Arnd Bergmann wrote:
> The blackfin architecture is getting removed, so we can clean up
> all the special cases in the musb driver.
> 
> Signed-off-by: Arnd Bergmann 
> ---
>  drivers/usb/musb/Kconfig|  10 +-
>  drivers/usb/musb/Makefile   |   1 -
>  drivers/usb/musb/blackfin.c | 623 
> 
>  drivers/usb/musb/blackfin.h |  81 --
>  drivers/usb/musb/musb_core.c|   5 -
>  drivers/usb/musb/musb_core.h|  30 --
>  drivers/usb/musb/musb_debugfs.c |   2 -
>  drivers/usb/musb/musb_dma.h |  11 -
>  drivers/usb/musb/musb_gadget.c  |  35 ---
>  drivers/usb/musb/musb_regs.h| 182 
>  drivers/usb/musb/musbhsdma.c|   5 -
>  drivers/usb/musb/musbhsdma.h|  64 -
>  include/linux/usb/musb.h|   7 -
>  13 files changed, 1 insertion(+), 1055 deletions(-)
>  delete mode 100644 drivers/usb/musb/blackfin.c
>  delete mode 100644 drivers/usb/musb/blackfin.h

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

Re: [PATCH 37/47] usb: host: remove tilegx platform glue

[Greg Kroah-Hartman]

On Wed, Mar 14, 2018 at 04:35:50PM +0100, Arnd Bergmann wrote:
> The tile architecture is getting removed, so the ehci and ohci platform
> glue drivers are no longer needed. In case of ohci, this is the last
> one to define a PLATFORM_DRIVER macro, so we can remove even more.
> 
> Signed-off-by: Arnd Bergmann 
> ---
>  drivers/usb/host/ehci-hcd.c|   5 -
>  drivers/usb/host/ehci-tilegx.c | 207 
> -
>  drivers/usb/host/ohci-hcd.c|  18 
>  drivers/usb/host/ohci-tilegx.c | 196 --
>  include/linux/usb/tilegx.h |  35 ---
>  5 files changed, 461 deletions(-)
>  delete mode 100644 drivers/usb/host/ehci-tilegx.c
>  delete mode 100644 drivers/usb/host/ohci-tilegx.c
>  delete mode 100644 include/linux/usb/tilegx.h

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

Re: [PATCH 2/2] usb: host: xhci-plat: Fix clock resource by adding a register clock

[Gregory CLEMENT]

Hi Rob,

(resent because of malformed cc list)
 
 On mer., févr. 28 2018, Mathias Nyman  wrote:

> On 14.02.2018 18:16, Gregory CLEMENT wrote:
>> On Armada 7K/8K we need to explicitly enable the register clock. This
>> clock is optional because not all the SoCs using this IP need it but at
>> least for Armada 7K/8K it is actually mandatory.
>>
>> The change was done at xhci-plat level and not at a xhci-mvebu.c because,
>> it is expected that other SoC would have this kind of constraint.
>>
>> The binding documentation is updating accordingly.
>>
>> Signed-off-by: Gregory CLEMENT 
>> ---
>>   Documentation/devicetree/bindings/usb/usb-xhci.txt |  5 +++-
>>   drivers/usb/host/xhci-plat.c   | 33 
>> ++
>>   drivers/usb/host/xhci.h|  3 +-
>>   3 files changed, 33 insertions(+), 8 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/usb/usb-xhci.txt 
>> b/Documentation/devicetree/bindings/usb/usb-xhci.txt
>> index e2ea59bbca93..e4b14511f4f8 100644
>> --- a/Documentation/devicetree/bindings/usb/usb-xhci.txt
>> +++ b/Documentation/devicetree/bindings/usb/usb-xhci.txt
>> @@ -27,7 +27,10 @@ Required properties:
>> - interrupts: one XHCI interrupt should be described here.
>> Optional properties:
>> -  - clocks: reference to a clock
>> +  - clocks: reference to the clocks
>> +  - clock-names: mandatory if there is a second clock, in this case
>> +the name must be "core" for the first clock and "reg" for the
>> +second one
>> - usb2-lpm-disable: indicate if we don't want to enable USB2 HW LPM
>> - usb3-lpm-capable: determines if platform is USB3 LPM capable
>> - quirk-broken-port-ped: set if the controller has broken port disable 
>> mechanism
>
> Would be good to get a Ack or review by Rob Herring for the above

Would you mind to have a look on this binding update ?

Initially I didn't copy you trying to not overflow you because this
change is only about adding a new clock, which is pretty common. But I
think Mathias would be more confident with a Ack or review by you.

Thanks,

Gregory

-- 
Gregory Clement, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
http://bootlin.com
--
To unsubscribe from this list: send the line "unsubscribe 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 38/47] usb: musb: remove blackfin port

[Arnd Bergmann]

The blackfin architecture is getting removed, so we can clean up
all the special cases in the musb driver.

Signed-off-by: Arnd Bergmann 
---
 drivers/usb/musb/Kconfig|  10 +-
 drivers/usb/musb/Makefile   |   1 -
 drivers/usb/musb/blackfin.c | 623 
 drivers/usb/musb/blackfin.h |  81 --
 drivers/usb/musb/musb_core.c|   5 -
 drivers/usb/musb/musb_core.h|  30 --
 drivers/usb/musb/musb_debugfs.c |   2 -
 drivers/usb/musb/musb_dma.h |  11 -
 drivers/usb/musb/musb_gadget.c  |  35 ---
 drivers/usb/musb/musb_regs.h| 182 
 drivers/usb/musb/musbhsdma.c|   5 -
 drivers/usb/musb/musbhsdma.h|  64 -
 include/linux/usb/musb.h|   7 -
 13 files changed, 1 insertion(+), 1055 deletions(-)
 delete mode 100644 drivers/usb/musb/blackfin.c
 delete mode 100644 drivers/usb/musb/blackfin.h

diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig
index 5506a9c03c1f..490990e8b015 100644
--- a/drivers/usb/musb/Kconfig
+++ b/drivers/usb/musb/Kconfig
@@ -18,9 +18,6 @@ config USB_MUSB_HDRC
  Texas Instruments families using this IP include DaVinci
  (35x, 644x ...), OMAP 243x, OMAP 3, and TUSB 6010.
 
- Analog Devices parts using this IP include Blackfin BF54x,
- BF525 and BF527.
-
  Allwinner SoCs using this IP include A10, A13, A20, ...
 
  If you do not know what this is, please say N.
@@ -107,11 +104,6 @@ config USB_MUSB_DSPS
depends on ARCH_OMAP2PLUS || COMPILE_TEST
depends on OF_IRQ
 
-config USB_MUSB_BLACKFIN
-   tristate "Blackfin"
-   depends on (BF54x && !BF544) || (BF52x && ! BF522 && !BF523)
-   depends on NOP_USB_XCEIV
-
 config USB_MUSB_UX500
tristate "Ux500 platforms"
depends on ARCH_U8500 || COMPILE_TEST
@@ -149,7 +141,7 @@ config USB_UX500_DMA
 
 config USB_INVENTRA_DMA
bool 'Inventra'
-   depends on USB_MUSB_OMAP2PLUS || USB_MUSB_BLACKFIN
+   depends on USB_MUSB_OMAP2PLUS
help
  Enable DMA transfers using Mentor's engine.
 
diff --git a/drivers/usb/musb/Makefile b/drivers/usb/musb/Makefile
index 79d4d5439164..3a88c79e650c 100644
--- a/drivers/usb/musb/Makefile
+++ b/drivers/usb/musb/Makefile
@@ -21,7 +21,6 @@ obj-$(CONFIG_USB_MUSB_DSPS)   += musb_dsps.o
 obj-$(CONFIG_USB_MUSB_TUSB6010)+= tusb6010.o
 obj-$(CONFIG_USB_MUSB_DAVINCI) += davinci.o
 obj-$(CONFIG_USB_MUSB_DA8XX)   += da8xx.o
-obj-$(CONFIG_USB_MUSB_BLACKFIN)+= blackfin.o
 obj-$(CONFIG_USB_MUSB_UX500)   += ux500.o
 obj-$(CONFIG_USB_MUSB_JZ4740)  += jz4740.o
 obj-$(CONFIG_USB_MUSB_SUNXI)   += sunxi.o
diff --git a/drivers/usb/musb/blackfin.c b/drivers/usb/musb/blackfin.c
deleted file mode 100644
index 0a98dcd66d19..
diff --git a/drivers/usb/musb/blackfin.h b/drivers/usb/musb/blackfin.h
deleted file mode 100644
index 5b149915b0f8..
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index c344ef4e5355..72bb03e7b751 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -126,7 +126,6 @@ EXPORT_SYMBOL_GPL(musb_get_mode);
 
 /*-*/
 
-#ifndef CONFIG_BLACKFIN
 static int musb_ulpi_read(struct usb_phy *phy, u32 reg)
 {
void __iomem *addr = phy->io_priv;
@@ -208,10 +207,6 @@ static int musb_ulpi_write(struct usb_phy *phy, u32 val, 
u32 reg)
 
return ret;
 }
-#else
-#define musb_ulpi_read NULL
-#define musb_ulpi_writeNULL
-#endif
 
 static struct usb_phy_io_ops musb_ulpi_access = {
.read = musb_ulpi_read,
diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
index 385841ee6f46..ac675b1a34c4 100644
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -467,34 +467,6 @@ static inline char *musb_ep_xfertype_string(u8 type)
return s;
 }
 
-#ifdef CONFIG_BLACKFIN
-static inline int musb_read_fifosize(struct musb *musb,
-   struct musb_hw_ep *hw_ep, u8 epnum)
-{
-   musb->nr_endpoints++;
-   musb->epmask |= (1 << epnum);
-
-   if (epnum < 5) {
-   hw_ep->max_packet_sz_tx = 128;
-   hw_ep->max_packet_sz_rx = 128;
-   } else {
-   hw_ep->max_packet_sz_tx = 1024;
-   hw_ep->max_packet_sz_rx = 1024;
-   }
-   hw_ep->is_shared_fifo = false;
-
-   return 0;
-}
-
-static inline void musb_configure_ep0(struct musb *musb)
-{
-   musb->endpoints[0].max_packet_sz_tx = MUSB_EP0_FIFOSIZE;
-   musb->endpoints[0].max_packet_sz_rx = MUSB_EP0_FIFOSIZE;
-   musb->endpoints[0].is_shared_fifo = true;
-}
-
-#else
-
 static inline int musb_read_fifosize(struct musb *musb,
struct musb_hw_ep *hw_ep, u8 epnum)
 {
@@ -531,8 +503,6 @@ static inline void musb_configure_ep0(struct

[PATCH 37/47] usb: host: remove tilegx platform glue

[Arnd Bergmann]

The tile architecture is getting removed, so the ehci and ohci platform
glue drivers are no longer needed. In case of ohci, this is the last
one to define a PLATFORM_DRIVER macro, so we can remove even more.

Signed-off-by: Arnd Bergmann 
---
 drivers/usb/host/ehci-hcd.c|   5 -
 drivers/usb/host/ehci-tilegx.c | 207 -
 drivers/usb/host/ohci-hcd.c|  18 
 drivers/usb/host/ohci-tilegx.c | 196 --
 include/linux/usb/tilegx.h |  35 ---
 5 files changed, 461 deletions(-)
 delete mode 100644 drivers/usb/host/ehci-tilegx.c
 delete mode 100644 drivers/usb/host/ohci-tilegx.c
 delete mode 100644 include/linux/usb/tilegx.h

diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index 7f0737449df7..d927adf3afcd 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -1275,11 +1275,6 @@ MODULE_LICENSE ("GPL");
 #define XILINX_OF_PLATFORM_DRIVER  ehci_hcd_xilinx_of_driver
 #endif
 
-#ifdef CONFIG_TILE_USB
-#include "ehci-tilegx.c"
-#definePLATFORM_DRIVER ehci_hcd_tilegx_driver
-#endif
-
 #ifdef CONFIG_USB_EHCI_HCD_PMC_MSP
 #include "ehci-pmcmsp.c"
 #definePLATFORM_DRIVER ehci_hcd_msp_driver
diff --git a/drivers/usb/host/ehci-tilegx.c b/drivers/usb/host/ehci-tilegx.c
deleted file mode 100644
index 610ed437ed2c..
diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c
index 84f88fa411cd..199f1b7a91a3 100644
--- a/drivers/usb/host/ohci-hcd.c
+++ b/drivers/usb/host/ohci-hcd.c
@@ -1244,11 +1244,6 @@ MODULE_LICENSE ("GPL");
 #define TMIO_OHCI_DRIVER   ohci_hcd_tmio_driver
 #endif
 
-#ifdef CONFIG_TILE_USB
-#include "ohci-tilegx.c"
-#define PLATFORM_DRIVERohci_hcd_tilegx_driver
-#endif
-
 static int __init ohci_hcd_mod_init(void)
 {
int retval = 0;
@@ -1273,12 +1268,6 @@ static int __init ohci_hcd_mod_init(void)
goto error_ps3;
 #endif
 
-#ifdef PLATFORM_DRIVER
-   retval = platform_driver_register(&PLATFORM_DRIVER);
-   if (retval < 0)
-   goto error_platform;
-#endif
-
 #ifdef OF_PLATFORM_DRIVER
retval = platform_driver_register(&OF_PLATFORM_DRIVER);
if (retval < 0)
@@ -1322,10 +1311,6 @@ static int __init ohci_hcd_mod_init(void)
platform_driver_unregister(&OF_PLATFORM_DRIVER);
  error_of_platform:
 #endif
-#ifdef PLATFORM_DRIVER
-   platform_driver_unregister(&PLATFORM_DRIVER);
- error_platform:
-#endif
 #ifdef PS3_SYSTEM_BUS_DRIVER
ps3_ohci_driver_unregister(&PS3_SYSTEM_BUS_DRIVER);
  error_ps3:
@@ -1353,9 +1338,6 @@ static void __exit ohci_hcd_mod_exit(void)
 #ifdef OF_PLATFORM_DRIVER
platform_driver_unregister(&OF_PLATFORM_DRIVER);
 #endif
-#ifdef PLATFORM_DRIVER
-   platform_driver_unregister(&PLATFORM_DRIVER);
-#endif
 #ifdef PS3_SYSTEM_BUS_DRIVER
ps3_ohci_driver_unregister(&PS3_SYSTEM_BUS_DRIVER);
 #endif
diff --git a/drivers/usb/host/ohci-tilegx.c b/drivers/usb/host/ohci-tilegx.c
deleted file mode 100644
index d21ca3ce9a30..
diff --git a/include/linux/usb/tilegx.h b/include/linux/usb/tilegx.h
deleted file mode 100644
index 817908573fe8..
-- 
2.9.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: [PATCH 2/3] usb: host: pci: introduce PCI vendor ID for Netlogic

[Richard Leitner]

On 03/14/2018 04:27 PM, Oliver Neukum wrote:
> Am Mittwoch, den 14.03.2018, 14:31 +0100 schrieb Richard Leitner:
>> Hi Oliver,
>> thank you for your feedback!
>>
>> On 03/14/2018 01:17 PM, Oliver Neukum wrote:
>>> Am Mittwoch, den 14.03.2018, 11:29 +0100 schrieb Richard Leitner:
 From: Richard Leitner 

 Replace the hardcoded PCI vendor ID of Netlogic with a definition in
 pci_ids.h
>>>
>>> Hi,
>>>
>>> in general, why?
>>> Does this patch generate any benefit for any developer
>>> reading the source? I don't see it. Does it cause an
>>> issue for anybody who has a log file with the nummerical
>>> ID and needs to grep for it? Yes it does.
>>
>> I'll send a v2 where I also use this definition in 
>> arch/mips/netlogic/xlp/ instead of PCI_VENDOR_NETLOGIC from
>> arch/mips/include/asm/netlogic/xlp-hal/iomap.h.
>>
>> Therefore it will remove this definition from the iomap.h
>> and move it to pci_ids.h
>>
>> This will IMHO be a clear benefit as it removes a redundant
>> definition.
> 
> Well, but it does not. Removing a redundant definition is a clear
> benefit. But you are not removing a definition. You are introducing
> a preprocessor constant. Why?
> What is its benefit?

AFAIK pci_ids.h collects PCI vendor and device IDs in one single 
point. As the PCI vendor ID of Netlogic is used in multiple files
IMHO it would be a good idea to add it to pci_ids.h and furthermore
remove it from arch/mips/include/asm/netlogic/xlp-hal/iomap.h (where
it's currently defined).

Or am I getting things wrong?

regards;richard.l
--
To unsubscribe from this list: send the line "unsubscribe 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 00/47] arch-removal: device drivers

[Arnd Bergmann]

Hi driver maintainers,

I just posted one series with the removal of eight architectures,
see https://lkml.org/lkml/2018/3/14/505 for details, or
https://lwn.net/Articles/748074/ for more background.

These are the device drivers that go along with them. I have already
picked up the drivers for arch/metag/ into my tree, they were reviewed
earlier.

Please let me know if you have any concerns with the patch, or if you
prefer to pick up the patches in your respective trees.  I created
the patches with 'git format-patch -D', so they will not apply without
manually removing those files.

For anything else, I'd keep the removal patches in my asm-generic tree
and will send a pull request for 4.17 along with the actual arch removal.

   Arnd

Arnd Bergmann
  edac: remove tile driver
  net: tile: remove ethernet drivers
  net: adi: remove blackfin ethernet drivers
  net: 8390: remove m32r specific bits
  net: remove cris etrax ethernet driver
  net: smsc: remove m32r specific smc91x configuration
  raid: remove tile specific raid6 implementation
  rtc: remove tile driver
  rtc: remove bfin driver
  char: remove obsolete ds1302 rtc driver
  char: remove tile-srom.c
  char: remove blackfin OTP driver
  pcmcia: remove m32r drivers
  pcmcia: remove blackfin driver
  ASoC: remove blackfin drivers
  video/logo: remove obsolete logo files
  fbdev: remove blackfin drivers
  fbdev: s1d13xxxfb: remove m32r specific hacks
  crypto: remove blackfin CRC driver
  media: platform: remove blackfin capture driver
  media: platform: remove m32r specific arv driver
  cpufreq: remove blackfin driver
  cpufreq: remove cris specific drivers
  gpio: remove etraxfs driver
  pinctrl: remove adi2/blackfin drivers
  ata: remove bf54x driver
  input: keyboard: remove bf54x driver
  input: misc: remove blackfin rotary driver
  mmc: remove bfin_sdh driver
  can: remove bfin_can driver
  watchdog: remove bfin_wdt driver
  mtd: maps: remove bfin-async-flash driver
  mtd: nand: remove bf5xx_nand driver
  spi: remove blackfin related host drivers
  i2c: remove bfin-twi driver
  pwm: remobe pwm-bfin driver
  usb: host: remove tilegx platform glue
  usb: musb: remove blackfin port
  usb: isp1362: remove blackfin arch glue
  serial: remove cris/etrax uart drivers
  serial: remove blackfin drivers
  serial: remove m32r_sio driver
  serial: remove tile uart driver
  tty: remove bfin_jtag_comm and hvc_bfin_jtag drivers
  tty: hvc: remove tile driver
  staging: irda: remove bfin_sir driver
  staging: iio: remove iio-trig-bfin-timer driver

 .../devicetree/bindings/gpio/gpio-etraxfs.txt  |   22 -
 .../bindings/serial/axis,etraxfs-uart.txt  |   22 -
 Documentation/watchdog/watchdog-parameters.txt |5 -
 MAINTAINERS|8 -
 drivers/ata/Kconfig|9 -
 drivers/ata/Makefile   |1 -
 drivers/ata/pata_bf54x.c   | 1703 
 drivers/char/Kconfig   |   48 -
 drivers/char/Makefile  |3 -
 drivers/char/bfin-otp.c|  237 --
 drivers/char/ds1302.c  |  357 --
 drivers/char/tile-srom.c   |  475 ---
 drivers/cpufreq/Makefile   |3 -
 drivers/cpufreq/blackfin-cpufreq.c |  217 -
 drivers/cpufreq/cris-artpec3-cpufreq.c |   93 -
 drivers/cpufreq/cris-etraxfs-cpufreq.c |   92 -
 drivers/crypto/Kconfig |7 -
 drivers/crypto/Makefile|1 -
 drivers/crypto/bfin_crc.c  |  753 
 drivers/crypto/bfin_crc.h  |  124 -
 drivers/edac/Kconfig   |8 -
 drivers/edac/Makefile  |2 -
 drivers/edac/tile_edac.c   |  265 --
 drivers/gpio/Kconfig   |9 -
 drivers/gpio/Makefile  |1 -
 drivers/gpio/gpio-etraxfs.c|  475 ---
 drivers/i2c/busses/Kconfig |   18 -
 drivers/i2c/busses/Makefile|1 -
 drivers/i2c/busses/i2c-bfin-twi.c  |  737 
 drivers/input/keyboard/Kconfig |9 -
 drivers/input/keyboard/Makefile|1 -
 drivers/input/keyboard/bf54x-keys.c|  396 --
 drivers/input/misc/Kconfig |9 -
 drivers/input/misc/Makefile|1 -
 drivers/input/misc/bfin_rotary.c   |  294 --
 drivers/media/platform/Kconfig |   22 -
 drivers/media/platform/Makefile|4 -
 drivers/media/platform/arv.c   |  884 
 drivers/media/platform/blackfin/Kconfig|   16 -
 drivers/media/platform/blackfin/Makefile   | 

Re: [PATCH 2/3] usb: host: pci: introduce PCI vendor ID for Netlogic

[Oliver Neukum]

Am Mittwoch, den 14.03.2018, 14:31 +0100 schrieb Richard Leitner:
> Hi Oliver,
> thank you for your feedback!
> 
> On 03/14/2018 01:17 PM, Oliver Neukum wrote:
> > Am Mittwoch, den 14.03.2018, 11:29 +0100 schrieb Richard Leitner:
> > > From: Richard Leitner 
> > > 
> > > Replace the hardcoded PCI vendor ID of Netlogic with a definition in
> > > pci_ids.h
> > 
> > Hi,
> > 
> > in general, why?
> > Does this patch generate any benefit for any developer
> > reading the source? I don't see it. Does it cause an
> > issue for anybody who has a log file with the nummerical
> > ID and needs to grep for it? Yes it does.
> 
> I'll send a v2 where I also use this definition in 
> arch/mips/netlogic/xlp/ instead of PCI_VENDOR_NETLOGIC from
> arch/mips/include/asm/netlogic/xlp-hal/iomap.h.
> 
> Therefore it will remove this definition from the iomap.h
> and move it to pci_ids.h
> 
> This will IMHO be a clear benefit as it removes a redundant
> definition.

Well, but it does not. Removing a redundant definition is a clear
benefit. But you are not removing a definition. You are introducing
a preprocessor constant. Why?
What is its benefit?

Regards
Oliver

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

RE: [PATCH] lan78xx: Connect phy early

[Woojung.Huh]

Hi Alexander,

Thanks for patch. We will look into it if there is any corner case
Such as plug in/out while operations.

Woojung

> -Original Message-
> From: Alexander Graf [mailto:ag...@suse.de]
> Sent: Wednesday, March 14, 2018 10:55 AM
> To: Woojung Huh - C21699 
> Cc: UNGLinuxDriver ; net...@vger.kernel.org; 
> linux-
> u...@vger.kernel.org; linux-ker...@vger.kernel.org; Thomas Bogendoerfer
> ; Phil Elwell 
> Subject: [PATCH] lan78xx: Connect phy early
> 
> When using wicked with a lan78xx device attached to the system, we
> end up with ethtool commands issued on the device before an ifup
> got issued. That lead to the following crash:
> 
> Unable to handle kernel NULL pointer dereference at virtual address 
> 039c
> pgd = 800035b3
> [039c] *pgd=
> Internal error: Oops: 9604 [#1] SMP
> Modules linked in: [...]
> Supported: Yes
> CPU: 3 PID: 638 Comm: wickedd Tainted: GE  
> 4.12.14-0-default #1
> Hardware name: raspberrypi rpi/rpi, BIOS 2018.03-rc2 02/21/2018
> task: 800035e74180 task.stack: 800036718000
> PC is at phy_ethtool_ksettings_get+0x20/0x98
> LR is at lan78xx_get_link_ksettings+0x44/0x60 [lan78xx]
> pc : [] lr : [] pstate: 2005
> sp : 80003671bb20
> x29: 80003671bb20 x28: 800035e74180
> x27: 08912000 x26: 001d
> x25: 0124 x24: 08f74d00
> x23: 004000114809 x22: 
> x21: 80003671bbd0 x20: 
> x19: 80003671bbd0 x18: 040d
> x17: 0001 x16: 
> x15:  x14: 
> x13:  x12: 0020
> x11: 0101010101010101 x10: fefefefefefefeff
> x9 : 7f7f7f7f7f7f7f7f x8 : fefefeff31677364
> x7 : 80808080 x6 : 80003671bc9c
> x5 : 80003671b9f8 x4 : 80002c296190
> x3 :  x2 : 
> x1 : 80003671bbd0 x0 : 80003671bc00
> Process wickedd (pid: 638, stack limit = 0x800036718000)
> Call trace:
> Exception stack(0x80003671b9e0 to 0x80003671bb20)
> b9e0: 80003671bc00 80003671bbd0  
> ba00: 80002c296190 80003671b9f8 80003671bc9c 80808080
> ba20: fefefeff31677364 7f7f7f7f7f7f7f7f fefefefefefefeff 0101010101010101
> ba40: 0020   
> ba60:  0001 040d 80003671bbd0
> ba80:  80003671bbd0  004000114809
> baa0: 08f74d00 0124 001d 08912000
> bac0: 800035e74180 80003671bb20 00dcca84 80003671bb20
> bae0: 086f7f30 2005 80002c296000 800035223900
> bb00:   80003671bb20 086f7f30
> [] phy_ethtool_ksettings_get+0x20/0x98
> [] lan78xx_get_link_ksettings+0x44/0x60 [lan78xx]
> [] ethtool_get_settings+0x68/0x210
> [] dev_ethtool+0x214/0x2180
> [] dev_ioctl+0x400/0x630
> [] sock_do_ioctl+0x70/0x88
> [] sock_ioctl+0x208/0x368
> [] do_vfs_ioctl+0xb0/0x848
> [] SyS_ioctl+0x8c/0xa8
> Exception stack(0x80003671bec0 to 0x80003671c000)
> bec0: 0009 8946 f4e841d0 aa0032687465
> bee0: fa2319d4 f4e841d4 32687465 32687465
> bf00: 001d 7f7fff7f7f7f7f7f 72606b622e71ff4c 7f7f7f7f7f7f7f7f
> bf20: 0101010101010101 0020  7f510c68
> bf40: 7f6a9d18 7f44ce30 040d 7f6f98f0
> bf60: f4e842c0 0001 fa2c2e00 7f6ab000
> bf80: f4e842c0 7f62a000 fa2b9f20 fa2c2e00
> bfa0: f4e84818 f4e841a0 7f5ad0cc f4e841a0
> bfc0: 7f44ce3c 8000 0009 001d
> bfe0:    
> 
> The culprit is quite simple: The driver tries to access the phy left and 
> right,
> but only actually has a working reference to it when the device is up.
> 
> The fix thus is quite simple too: Get a reference to the phy on probe already
> and keep it even when the device is going down.
> 
> With this patch applied, I can successfully run wicked on my system and bring
> the interface up and down as many times as I want, without getting NULL 
> pointer
> dereferences in between.
> 
> Signed-off-by: Alexander Graf 
> ---
>  drivers/net/usb/lan78xx.c | 21 ++---
>  1 file changed, 10 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/net/usb/lan78xx.c b/drivers/net/usb/lan78xx.c
> index 60a604cc7647..931cc124ab0c 100644
> --- a/drivers/net/usb/lan78xx.c
> +++

[PATCH] lan78xx: Connect phy early

[Alexander Graf]

When using wicked with a lan78xx device attached to the system, we
end up with ethtool commands issued on the device before an ifup
got issued. That lead to the following crash:

Unable to handle kernel NULL pointer dereference at virtual address 039c
pgd = 800035b3
[039c] *pgd=
Internal error: Oops: 9604 [#1] SMP
Modules linked in: [...]
Supported: Yes
CPU: 3 PID: 638 Comm: wickedd Tainted: GE  
4.12.14-0-default #1
Hardware name: raspberrypi rpi/rpi, BIOS 2018.03-rc2 02/21/2018
task: 800035e74180 task.stack: 800036718000
PC is at phy_ethtool_ksettings_get+0x20/0x98
LR is at lan78xx_get_link_ksettings+0x44/0x60 [lan78xx]
pc : [] lr : [] pstate: 2005
sp : 80003671bb20
x29: 80003671bb20 x28: 800035e74180
x27: 08912000 x26: 001d
x25: 0124 x24: 08f74d00
x23: 004000114809 x22: 
x21: 80003671bbd0 x20: 
x19: 80003671bbd0 x18: 040d
x17: 0001 x16: 
x15:  x14: 
x13:  x12: 0020
x11: 0101010101010101 x10: fefefefefefefeff
x9 : 7f7f7f7f7f7f7f7f x8 : fefefeff31677364
x7 : 80808080 x6 : 80003671bc9c
x5 : 80003671b9f8 x4 : 80002c296190
x3 :  x2 : 
x1 : 80003671bbd0 x0 : 80003671bc00
Process wickedd (pid: 638, stack limit = 0x800036718000)
Call trace:
Exception stack(0x80003671b9e0 to 0x80003671bb20)
b9e0: 80003671bc00 80003671bbd0  
ba00: 80002c296190 80003671b9f8 80003671bc9c 80808080
ba20: fefefeff31677364 7f7f7f7f7f7f7f7f fefefefefefefeff 0101010101010101
ba40: 0020   
ba60:  0001 040d 80003671bbd0
ba80:  80003671bbd0  004000114809
baa0: 08f74d00 0124 001d 08912000
bac0: 800035e74180 80003671bb20 00dcca84 80003671bb20
bae0: 086f7f30 2005 80002c296000 800035223900
bb00:   80003671bb20 086f7f30
[] phy_ethtool_ksettings_get+0x20/0x98
[] lan78xx_get_link_ksettings+0x44/0x60 [lan78xx]
[] ethtool_get_settings+0x68/0x210
[] dev_ethtool+0x214/0x2180
[] dev_ioctl+0x400/0x630
[] sock_do_ioctl+0x70/0x88
[] sock_ioctl+0x208/0x368
[] do_vfs_ioctl+0xb0/0x848
[] SyS_ioctl+0x8c/0xa8
Exception stack(0x80003671bec0 to 0x80003671c000)
bec0: 0009 8946 f4e841d0 aa0032687465
bee0: fa2319d4 f4e841d4 32687465 32687465
bf00: 001d 7f7fff7f7f7f7f7f 72606b622e71ff4c 7f7f7f7f7f7f7f7f
bf20: 0101010101010101 0020  7f510c68
bf40: 7f6a9d18 7f44ce30 040d 7f6f98f0
bf60: f4e842c0 0001 fa2c2e00 7f6ab000
bf80: f4e842c0 7f62a000 fa2b9f20 fa2c2e00
bfa0: f4e84818 f4e841a0 7f5ad0cc f4e841a0
bfc0: 7f44ce3c 8000 0009 001d
bfe0:    

The culprit is quite simple: The driver tries to access the phy left and right,
but only actually has a working reference to it when the device is up.

The fix thus is quite simple too: Get a reference to the phy on probe already
and keep it even when the device is going down.

With this patch applied, I can successfully run wicked on my system and bring
the interface up and down as many times as I want, without getting NULL pointer
dereferences in between.

Signed-off-by: Alexander Graf 
---
 drivers/net/usb/lan78xx.c | 21 ++---
 1 file changed, 10 insertions(+), 11 deletions(-)

diff --git a/drivers/net/usb/lan78xx.c b/drivers/net/usb/lan78xx.c
index 60a604cc7647..931cc124ab0c 100644
--- a/drivers/net/usb/lan78xx.c
+++ b/drivers/net/usb/lan78xx.c
@@ -2082,8 +2082,6 @@ static int lan78xx_phy_init(struct lan78xx_net *dev)
 
dev->fc_autoneg = phydev->autoneg;
 
-   phy_start(phydev);
-
netif_dbg(dev, ifup, dev->net, "phy initialised successfully");
 
return 0;
@@ -2512,9 +2510,7 @@ static int lan78xx_open(struct net_device *net)
if (ret < 0)
goto done;
 
-   ret = lan78xx_phy_init(dev);
-   if (ret < 0)
-   goto done;
+   phy_start(net->phydev);
 
/* for Link Check */
if (dev->urb_intr) {
@@ -2575,13 +2571,7 @@ static int lan78xx_stop(struct net_device *net)
if (ti

[PATCH 11/16] treewide: simplify Kconfig dependencies for removed archs

[Arnd Bergmann]

A lot of Kconfig symbols have architecture specific dependencies.
In those cases that depend on architectures we have already removed,
they can be omitted.

Signed-off-by: Arnd Bergmann 
---
 block/bounce.c   |  2 +-
 drivers/ide/Kconfig  |  2 +-
 drivers/ide/ide-generic.c| 12 +---
 drivers/input/joystick/analog.c  |  2 +-
 drivers/isdn/hisax/Kconfig   | 10 +-
 drivers/net/ethernet/davicom/Kconfig |  2 +-
 drivers/net/ethernet/smsc/Kconfig|  6 +++---
 drivers/net/wireless/cisco/Kconfig   |  2 +-
 drivers/pwm/Kconfig  |  2 +-
 drivers/rtc/Kconfig  |  2 +-
 drivers/spi/Kconfig  |  4 ++--
 drivers/usb/musb/Kconfig |  2 +-
 drivers/video/console/Kconfig|  3 +--
 drivers/watchdog/Kconfig |  6 --
 drivers/watchdog/Makefile|  6 --
 fs/Kconfig.binfmt|  5 ++---
 fs/minix/Kconfig |  2 +-
 include/linux/ide.h  |  7 +--
 init/Kconfig |  5 ++---
 lib/Kconfig.debug| 13 +
 lib/test_user_copy.c |  2 --
 mm/Kconfig   |  7 ---
 mm/percpu.c  |  4 
 23 files changed, 31 insertions(+), 77 deletions(-)

diff --git a/block/bounce.c b/block/bounce.c
index 6a3e68292273..dd0b93f2a871 100644
--- a/block/bounce.c
+++ b/block/bounce.c
@@ -31,7 +31,7 @@
 static struct bio_set *bounce_bio_set, *bounce_bio_split;
 static mempool_t *page_pool, *isa_page_pool;
 
-#if defined(CONFIG_HIGHMEM) || defined(CONFIG_NEED_BOUNCE_POOL)
+#if defined(CONFIG_HIGHMEM)
 static __init int init_emergency_pool(void)
 {
 #if defined(CONFIG_HIGHMEM) && !defined(CONFIG_MEMORY_HOTPLUG)
diff --git a/drivers/ide/Kconfig b/drivers/ide/Kconfig
index cf1fb3fb5d26..901b8833847f 100644
--- a/drivers/ide/Kconfig
+++ b/drivers/ide/Kconfig
@@ -200,7 +200,7 @@ comment "IDE chipset support/bugfixes"
 
 config IDE_GENERIC
tristate "generic/default IDE chipset support"
-   depends on ALPHA || X86 || IA64 || M32R || MIPS || ARCH_RPC
+   depends on ALPHA || X86 || IA64 || MIPS || ARCH_RPC
default ARM && ARCH_RPC
help
  This is the generic IDE driver.  This driver attaches to the
diff --git a/drivers/ide/ide-generic.c b/drivers/ide/ide-generic.c
index 54d7c4685d23..80c0d69b83ac 100644
--- a/drivers/ide/ide-generic.c
+++ b/drivers/ide/ide-generic.c
@@ -13,13 +13,10 @@
 #include 
 #include 
 
-/* FIXME: convert arm and m32r to use ide_platform host driver */
+/* FIXME: convert arm to use ide_platform host driver */
 #ifdef CONFIG_ARM
 #include 
 #endif
-#ifdef CONFIG_M32R
-#include 
-#endif
 
 #define DRV_NAME   "ide_generic"
 
@@ -35,13 +32,6 @@ static const struct ide_port_info ide_generic_port_info = {
 #ifdef CONFIG_ARM
 static const u16 legacy_bases[] = { 0x1f0 };
 static const int legacy_irqs[]  = { IRQ_HARDDISK };
-#elif defined(CONFIG_PLAT_M32700UT) || defined(CONFIG_PLAT_MAPPI2) || \
-  defined(CONFIG_PLAT_OPSPUT)
-static const u16 legacy_bases[] = { 0x1f0 };
-static const int legacy_irqs[]  = { PLD_IRQ_CFIREQ };
-#elif defined(CONFIG_PLAT_MAPPI3)
-static const u16 legacy_bases[] = { 0x1f0, 0x170 };
-static const int legacy_irqs[]  = { PLD_IRQ_CFIREQ, PLD_IRQ_IDEIREQ };
 #elif defined(CONFIG_ALPHA)
 static const u16 legacy_bases[] = { 0x1f0, 0x170, 0x1e8, 0x168 };
 static const int legacy_irqs[]  = { 14, 15, 11, 10 };
diff --git a/drivers/input/joystick/analog.c b/drivers/input/joystick/analog.c
index be1b4921f22a..eefac7978f93 100644
--- a/drivers/input/joystick/analog.c
+++ b/drivers/input/joystick/analog.c
@@ -163,7 +163,7 @@ static unsigned int get_time_pit(void)
 #define GET_TIME(x)do { x = (unsigned int)rdtsc(); } while (0)
 #define DELTA(x,y) ((y)-(x))
 #define TIME_NAME  "TSC"
-#elif defined(__alpha__) || defined(CONFIG_ARM) || defined(CONFIG_ARM64) || 
defined(CONFIG_RISCV) || defined(CONFIG_TILE)
+#elif defined(__alpha__) || defined(CONFIG_ARM) || defined(CONFIG_ARM64) || 
defined(CONFIG_RISCV)
 #define GET_TIME(x)do { x = get_cycles(); } while (0)
 #define DELTA(x,y) ((y)-(x))
 #define TIME_NAME  "get_cycles"
diff --git a/drivers/isdn/hisax/Kconfig b/drivers/isdn/hisax/Kconfig
index eb83d94ab4fe..38cfc8baae19 100644
--- a/drivers/isdn/hisax/Kconfig
+++ b/drivers/isdn/hisax/Kconfig
@@ -109,7 +109,7 @@ config HISAX_16_3
 
 config HISAX_TELESPCI
bool "Teles PCI"
-   depends on PCI && (BROKEN || !(SPARC || PPC || PARISC || M68K || (MIPS 
&& !CPU_LITTLE_ENDIAN) || FRV || (XTENSA && !CPU_LITTLE_ENDIAN)))
+   depends on PCI && (BROKEN || !(SPARC || PPC || PARISC || M68K || (MIPS 
&& !CPU_LITTLE_ENDIAN) || (XTENSA && !CPU_LITTLE_ENDIAN)))
help
  This enables HiSax support for the Teles PCI.
  See  on how to configure it.
@@ -237,7 +237,7 @@ config HISAX_MIC
 
 config HISAX_NETJET
bool "NET

[PATCH 00/16] remove eight obsolete architectures

[Arnd Bergmann]

Here is the collection of patches I have applied to my 'asm-generic' tree
on top of the 'metag' removal. This does not include any of the device
drivers, I'll send those separately to a someone different list of people.

The removal came out of a discussion that is now documented at
https://lwn.net/Articles/748074/

Following up from the state described there, I ended up removing the
mn10300, tile, blackfin and cris architectures directly, rather than
waiting, after consulting with the respective maintainers.

However, the unicore32 architecture is no longer part of the removal,
after its maintainer Xuetao Guan said that the port is still actively
being used and that he intends to keep working on it, and that he will
try to provide updated toolchain sources.

In the end, it seems that while the eight architectures are extremely
different, they all suffered the same fate: There was one company in
charge of an SoC line, a CPU microarchitecture and a software ecosystem,
which was more costly than licensing newer off-the-shelf CPU cores from
a third party (typically ARM, MIPS, or RISC-V). It seems that all the
SoC product lines are still around, but have not used the custom CPU
architectures for several years at this point.

  Arnd

Arnd Bergmann (14):
  arch: remove frv port
  arch: remove m32r port
  arch: remove score port
  arch: remove blackfin port
  arch: remove tile port
  procfs: remove CONFIG_HARDWALL dependency
  mm: remove blackfin MPU support
  mm: remove obsolete alloc_remap()
  treewide: simplify Kconfig dependencies for removed archs
  asm-generic: siginfo: remove obsolete #ifdefs
  Documentation: arch-support: remove obsolete architectures
  asm-generic: clean up asm/unistd.h
  recordmcount.pl: drop blackin and tile support
  ktest: remove obsolete architectures

David Howells (1):
  mn10300: Remove the architecture

Jesper Nilsson (1):
  CRIS: Drop support for the CRIS port

Dirstat only (full diffstat is over 100KB):

   6.3% arch/blackfin/mach-bf548/include/mach/
   4.5% arch/blackfin/mach-bf609/include/mach/
  26.3% arch/blackfin/
   4.1% arch/cris/arch-v32/
   5.6% arch/cris/include/arch-v32/arch/hwregs/iop/
   4.1% arch/cris/include/arch-v32/mach-a3/mach/hwregs/
   4.7% arch/cris/include/arch-v32/
   7.8% arch/cris/
   5.6% arch/frv/
   5.5% arch/m32r/
   7.0% arch/mn10300/
   7.6% arch/tile/include/
   6.4% arch/tile/kernel/
   0.0% Documentation/admin-guide/
   0.0% Documentation/blackfin/
   0.0% Documentation/cris/
   0.0% Documentation/devicetree/bindings/cris/
   0.0% Documentation/devicetree/bindings/interrupt-controller/
   2.8% Documentation/features/
   0.5% Documentation/frv/
   0.0% Documentation/ioctl/
   0.0% Documentation/mn10300/
   0.0% Documentation/
   0.0% block/
   0.0% crypto/
   0.0% drivers/ide/
   0.0% drivers/input/joystick/
   0.0% drivers/isdn/hisax/
   0.0% drivers/net/ethernet/davicom/
   0.0% drivers/net/ethernet/smsc/
   0.0% drivers/net/wireless/cisco/
   0.0% drivers/pci/
   0.0% drivers/pwm/
   0.0% drivers/rtc/
   0.0% drivers/spi/
   0.0% drivers/staging/speakup/
   0.0% drivers/usb/musb/
   0.0% drivers/video/console/
   0.0% drivers/watchdog/
   0.0% fs/minix/
   0.0% fs/proc/
   0.0% fs/
   0.0% include/asm-generic/
   0.0% include/linux/
   0.0% include/uapi/asm-generic/
   0.0% init/
   0.0% kernel/
   0.0% lib/
   0.0% mm/
   0.0% samples/blackfin/
   0.0% samples/kprobes/
   0.0% samples/
   0.0% scripts/mod/
   0.0% scripts/
   0.0% tools/arch/frv/include/uapi/asm/
   0.0% tools/arch/m32r/include/uapi/asm/
   0.0% tools/arch/mn10300/include/uapi/asm/
   0.0% tools/arch/score/include/uapi/asm/
   0.0% tools/arch/tile/include/asm/
   0.0% tools/arch/tile/include/uapi/asm/
   0.0% tools/include/asm-generic/
   0.0% tools/scripts/
   0.0% tools/testing/ktest/examples/
   0.0% tools/testing/ktest/

Cc: linux-...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: linux-bl...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: linux-in...@vger.kernel.org
Cc: net...@vger.kernel.org
Cc: linux-wirel...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: linux-usb@vger.kernel.org
Cc: dri-de...@lists.freedesktop.org
Cc: linux-fb...@vger.kernel.org
Cc: linux-watch...@vger.kernel.org
Cc: linux-fsde...@vger.kernel.org
Cc: linux-a...@vger.kernel.org
Cc: linux...@kvack.org
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v1 2/2] usb: dwc3: Add Qualcomm DWC3 glue driver

[Heikki Krogerus]

Hi,

On Wed, Mar 14, 2018 at 10:50:12AM +0200, Felipe Balbi wrote:
> >>>  - Support to replace pip3 clock going to DWC3 with utmi clock
> >>>for hardware configuration where SSPHY is not used with DWC3.
> >> Is that SW configurable? Really? In any case seems like this and SESSVLD
> >> valid should be handled using Hans' and Heikki's mux support.
> >
> > Yes, with this we can use dwc3 without using SSPHY. Please point me to
> > those patches. There are only bunch of register writes in glue wrapper to
> > achieve the same.
> 
> https://www.spinics.net/lists/linux-usb/msg160868.html

I'm not sure if that series is usable in this case. Though we do
control the VBUSVLD pin on DWC3 in the driver for the "Intel USB
mux" Hans is introducing, the framework for the USB role switches does
not provide any support for it.

The Intel USB mux driver simply enables VBUSVLD when device mode is
selected, and disables it if host mode is selected, and when the
selection is cleared (disconnection).


Br,

-- 
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 2/3] usb: host: pci: introduce PCI vendor ID for Netlogic

[Richard Leitner]

Hi Oliver,
thank you for your feedback!

On 03/14/2018 01:17 PM, Oliver Neukum wrote:
> Am Mittwoch, den 14.03.2018, 11:29 +0100 schrieb Richard Leitner:
>> From: Richard Leitner 
>>
>> Replace the hardcoded PCI vendor ID of Netlogic with a definition in
>> pci_ids.h
> 
> Hi,
> 
> in general, why?
> Does this patch generate any benefit for any developer
> reading the source? I don't see it. Does it cause an
> issue for anybody who has a log file with the nummerical
> ID and needs to grep for it? Yes it does.

I'll send a v2 where I also use this definition in 
arch/mips/netlogic/xlp/ instead of PCI_VENDOR_NETLOGIC from
arch/mips/include/asm/netlogic/xlp-hal/iomap.h.

Therefore it will remove this definition from the iomap.h
and move it to pci_ids.h

This will IMHO be a clear benefit as it removes a redundant
definition.

> 
> Where is the point of this patch?
> 
>   Regards
>   Oliver
> 

regards;Richard.L
--
To unsubscribe from this list: send the line "unsubscribe 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: Fix interval type issue

[Minas Harutyunyan]

On 3/14/2018 2:12 PM, Minas Harutyunyan wrote:
> On 2/6/2018 7:07 PM, Grigor Tovmasyan wrote:
>> The maximum value that unsigned char can hold is 255, meanwhile
>> the maximum value of interval is  2^(bIntervalMax-1)=2^15.
>>
>> Signed-off-by: Grigor Tovmasyan 
>> ---
>>drivers/usb/dwc2/core.h | 2 +-
>>1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
>> index 0f0c21cf0192..51c3d5170b3b 100644
>> --- a/drivers/usb/dwc2/core.h
>> +++ b/drivers/usb/dwc2/core.h
>> @@ -217,7 +217,7 @@ struct dwc2_hsotg_ep {
>>  unsigned char   dir_in;
>>  unsigned char   index;
>>  unsigned char   mc;
>> -unsigned char   interval;
>> +u16 interval;
>>
>>  unsigned inthalted:1;
>>  unsigned intperiodic:1;
>>
> 
> Acked-by: Minas Harutyunyan 
> --

Sorry for "Acked-by".
Tested-by: Minas Harutyunyan 
--
To unsubscribe from this list: send the line "unsubscribe 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 v8 00/12] USB Type-C device-connection, mux and switch support

[Heikki Krogerus]

Hi,

This is version 8 of series we prepare with Hans where we are introducing
support for USB muxes and generic device connections. The only change in this
version is to patch 1/12 (the device connections), where we are no longer using
rcu. Greg pointed out that we are not doing anything heavy enough to justify use
of rcu.


Cover-letter of v7:

This is version 7 of Hans' and my series introducing support for USB muxes and
generic device-connections. The api naming for device-connections is now made
according to proposal from Greg, connection.h is dropped and the prototypes are
now in device.h. kbuild test robot  also found stylistic
problems from patches 9/12 and 10/12 which were fixed. The patch 4/12 ("usb:
typec: Separate the definitions for data and power roles") was added to the
series.

Check the v6 from here:
https://lkml.org/lkml/2018/3/2/340


Here is the cover-letter of v6:

Hi All,

Here is version 6 of Heikki's and my USB Type-C device-connection, mux and
switch support series. Versions 2 - 5 bring various small code and style
fixes based on review (no major changes). Version 6 is rebased on top of
the latest usb-next and brings one small but important code fix in
the devcon code.

Here is the original cover-letter of v1:

Some devices with an USB Type-C connector have a bunch of muxes
behind that connector which need to be controlled by the kernel (rather
then having them controlled by firmware as on most devices).

Quite a while back I submitted a patch-series to tie together these muxes
and the Type-C Port Manager (tcpm) code, using the then new drivers/mux
framework. But the way I used the mux framework went against what it was
designed for, so in the end that series got nowhere.

Heikki Krogerus from Intel, who maintains the USB TYPEC subsystem, has
recently been working on solving the same problem for some boards he is
doing hardware-enablement for.

Heikki has come up with a number of infrastructure patches for this.
The first one is a new device-connection framework. This solves the
problem of describing non bus device-links on x86 in what in my experience
with this problematic area is a really nice simple, clean and *generic*
way. This could for example in the near future also replace the custom
lookup code in the pwm subsys and the custom pwm_add_table() /
pwm_remove_table() functions.

The other 3 patches add a framework for the different type of Type-C /
USB "muxes".

Heikki and I have gone through a number of iterations of these patches
together and we believe these are now ready for merging. Since merging
infrastructure patches without users is not done and Heikki's own use-case
for these is not yet ready for merging, the rest of this series consists
of patches by me to make the Type-C connector found on some Cherry Trail
devices (finally) be able to actually work as an USB port and not just
a charge port.

The last patch uses the new usb-role-switch framework to also do proper
devcie / host switching on CHT devices with a USB micro AB connector.
This is also a big feature for CHT users, because before this they had
to do a reboot to get an OTG-host cable recognized (on some devices).

Part of this series is an usb-role-switch driver for the role-switch
found inside the xhci controller on e.g. CHT devices, this is currently
implemented as the generic xhci controller instantiating a platform
child-device for this, since this really is a separate chunk of HW
which happens to sit in the XHCI mmio space. This approach may not be
universally liked, given that in this new series the role-switch driver
is much smaller and does not have any external deps anymore we could
just integrate it into the xhci code if that is preferred.

About merging this series (once everything is reviewed, etc.), there are
quite some interdependencies in it esp. a lot of the patches depend on
the first patch. Luckily patches 1-10 all apply to subsystems which are
maintained by Greg (most to the USB subsys). Which just leaves patches
11 and 12 once 1-10 are merged. Greg, can you create an immutable branch
for the platform/x86 and extcon maintainers to merge once this is done?

Regards,

Hans



Hans de Goede (7):
  usb: typec: tcpm: Set USB role switch to device mode when configured
as such
  usb: typec: tcpm: Use new Type-C switch/mux and usb-role-switch
functions
  xhci: Add Intel extended cap / otg phy mux handling
  usb: roles: Add Intel xHCI USB role switch driver
  usb: typec: driver for Pericom PI3USB30532 Type-C cross switch
  platform/x86: intel_cht_int33fe: Add device connections for the Type-C
port
  extcon: axp288: Set USB role where necessary

Heikki Krogerus (4):
  drivers: base: Unified device connection lookup
  usb: typec: API for controlling USB Type-C Multiplexers
  usb: common: Small class for USB role switches
  usb: typec: Separate the definitions for data and power roles

Mathias Nyman (1):
  xhci: Add option to get next extended capability in list by passing id
= 0

 Doc

[PATCH v8 01/12] drivers: base: Unified device connection lookup

[Heikki Krogerus]

Several frameworks - clk, gpio, phy, pmw, etc. - maintain
lookup tables for describing connections and provide custom
API for handling them. This introduces a single generic
lookup table and API for the connections.

The motivation for this commit is centralizing the
connection lookup, but the goal is to ultimately extract the
connection descriptions also from firmware by using the
fwnode_graph_* functions and other mechanisms that are
available.

Reviewed-by: Hans de Goede 
Reviewed-by: Andy Shevchenko 
Signed-off-by: Heikki Krogerus 
---
Changes in v8:
- No longer using rcu.

Changes in v7:
- API naming improvements suggested by Greg
- Prototypes to device.h, also suggested by Greg
- I removed the DEVCON() macro as it was not used yet and it needs to be
  rewritten

Changes in v6:
-Fix data and match arguments being swapped in __device_find_connection()
 call in device_find_connection() (as noticed by Jun Li)

Changes in v5:
-Add missing documentation for @list struct devcon member

Changes in v4:
-Add Andy's Reviewed-by

Changes in v3:
-Various spelling and gramar fixes in the docs pointed out by Randy Dunlap

Changes in v2:
-Add a (struct devcon) cast to the DEVCON() macro
---
 Documentation/driver-api/device_connection.rst |  43 
 drivers/base/Makefile  |   3 +-
 drivers/base/devcon.c  | 136 +
 include/linux/device.h |  22 
 4 files changed, 203 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/driver-api/device_connection.rst
 create mode 100644 drivers/base/devcon.c

diff --git a/Documentation/driver-api/device_connection.rst 
b/Documentation/driver-api/device_connection.rst
new file mode 100644
index ..affbc5566ab0
--- /dev/null
+++ b/Documentation/driver-api/device_connection.rst
@@ -0,0 +1,43 @@
+==
+Device connections
+==
+
+Introduction
+
+
+Devices often have connections to other devices that are outside of the direct
+child/parent relationship. A serial or network communication controller, which
+could be a PCI device, may need to be able to get a reference to its PHY
+component, which could be attached for example to the I2C bus. Some device
+drivers need to be able to control the clocks or the GPIOs for their devices,
+and so on.
+
+Device connections are generic descriptions of any type of connection between
+two separate devices.
+
+Device connections alone do not create a dependency between the two devices.
+They are only descriptions which are not tied to either of the devices 
directly.
+A dependency between the two devices exists only if one of the two endpoint
+devices requests a reference to the other. The descriptions themselves can be
+defined in firmware (not yet supported) or they can be built-in.
+
+Usage
+-
+
+Device connections should exist before device ``->probe`` callback is called 
for
+either endpoint device in the description. If the connections are defined in
+firmware, this is not a problem. It should be considered if the connection
+descriptions are "built-in", and need to be added separately.
+
+The connection description consists of the names of the two devices with the
+connection, i.e. the endpoints, and unique identifier for the connection which
+is needed if there are multiple connections between the two devices.
+
+After a description exists, the devices in it can request reference to the 
other
+endpoint device, or they can request the description itself.
+
+API
+---
+
+.. kernel-doc:: drivers/base/devcon.c
+   : functions: device_connection_find_match device_connection_find 
device_connection_add device_connection_remove
diff --git a/drivers/base/Makefile b/drivers/base/Makefile
index e32a52490051..12a7f64d35a9 100644
--- a/drivers/base/Makefile
+++ b/drivers/base/Makefile
@@ -5,7 +5,8 @@ obj-y   := component.o core.o bus.o dd.o 
syscore.o \
   driver.o class.o platform.o \
   cpu.o firmware.o init.o map.o devres.o \
   attribute_container.o transport_class.o \
-  topology.o container.o property.o cacheinfo.o
+  topology.o container.o property.o cacheinfo.o \
+  devcon.o
 obj-$(CONFIG_DEVTMPFS) += devtmpfs.o
 obj-$(CONFIG_DMA_CMA) += dma-contiguous.o
 obj-y  += power/
diff --git a/drivers/base/devcon.c b/drivers/base/devcon.c
new file mode 100644
index ..2513961a3712
--- /dev/null
+++ b/drivers/base/devcon.c
@@ -0,0 +1,136 @@
+// SPDX-License-Identifier: GPL-2.0
+/**
+ * Device connections
+ *
+ * Copyright (C) 2018 Intel Corporation
+ * Author: Heikki Krogerus 
+ */
+
+#include 
+
+static DEFINE_MUTEX(devcon_lock);
+static LIST_HEAD(devcon_list);
+
+/**
+ * device_connection_find_match - Find physical connection to a device
+ * @dev: Device with the connection
+ * @con_id: Identifier for the con

[PATCH v8 05/12] usb: typec: tcpm: Set USB role switch to device mode when configured as such

[Heikki Krogerus]

From: Hans de Goede 

Setting the mux to MUX_NONE and the switch to USB_SWITCH_DISCONNECT when
the data-role is device is not correct. Plenty of devices support
operating as USB device through a (separate) USB device controller.

We really need 2 different versions of USB_SWITCH_CONNECT,
USB_SWITCH_CONNECT_HOST and USB_SWITCH_DEVICE. Rather then modifying the
tcpc_usb_switch enum for this, simply remove it and switch to the
usb_role enum which provides exactly this, this will save use needing to
convert betweent the 2 enums when calling an usb-role-switch driver later.

Besides switching to the usb_role type, this commit also actually sets the
mux to TYPEC_MUX_USB and the switch to USB_ROLE_DEVICE instead of setting
both to none when the data-role is device.

This commit also makes tcpm_reset_port() call tcpm_mux_set(port,
TYPEC_MUX_NONE, USB_ROLE_NONE) so that the mux and switch
do _not_ stay in their last mode after a detach.

Signed-off-by: Hans de Goede 
Reviewed-by: Guenter Roeck 
Reviewed-by: Andy Shevchenko 
Signed-off-by: Heikki Krogerus 
---
Changes in v4:
-Add Andy's Reviewed-by

Changes in v3:
-Add Guenter's Reviewed-by

Changes in v2:
-Added Heikki's Reviewed-by
---
 drivers/usb/typec/tcpm.c | 22 +++---
 include/linux/usb/tcpm.h |  8 ++--
 2 files changed, 13 insertions(+), 17 deletions(-)

diff --git a/drivers/usb/typec/tcpm.c b/drivers/usb/typec/tcpm.c
index 064b456dcf04..5e527e2e1506 100644
--- a/drivers/usb/typec/tcpm.c
+++ b/drivers/usb/typec/tcpm.c
@@ -607,15 +607,15 @@ void tcpm_pd_transmit_complete(struct tcpm_port *port,
 EXPORT_SYMBOL_GPL(tcpm_pd_transmit_complete);
 
 static int tcpm_mux_set(struct tcpm_port *port, enum tcpc_mux_mode mode,
-   enum tcpc_usb_switch config)
+   enum usb_role usb_role)
 {
int ret = 0;
 
-   tcpm_log(port, "Requesting mux mode %d, config %d, polarity %d",
-mode, config, port->polarity);
+   tcpm_log(port, "Requesting mux mode %d, usb-role %d, polarity %d",
+mode, usb_role, port->polarity);
 
if (port->tcpc->mux)
-   ret = port->tcpc->mux->set(port->tcpc->mux, mode, config,
+   ret = port->tcpc->mux->set(port->tcpc->mux, mode, usb_role,
   port->polarity);
 
return ret;
@@ -731,14 +731,15 @@ static int tcpm_set_attached_state(struct tcpm_port 
*port, bool attached)
 static int tcpm_set_roles(struct tcpm_port *port, bool attached,
  enum typec_role role, enum typec_data_role data)
 {
+   enum usb_role usb_role;
int ret;
 
if (data == TYPEC_HOST)
-   ret = tcpm_mux_set(port, TYPEC_MUX_USB,
-  TCPC_USB_SWITCH_CONNECT);
+   usb_role = USB_ROLE_HOST;
else
-   ret = tcpm_mux_set(port, TYPEC_MUX_NONE,
-  TCPC_USB_SWITCH_DISCONNECT);
+   usb_role = USB_ROLE_DEVICE;
+
+   ret = tcpm_mux_set(port, TYPEC_MUX_USB, usb_role);
if (ret < 0)
return ret;
 
@@ -2085,7 +2086,7 @@ static int tcpm_src_attach(struct tcpm_port *port)
 out_disable_pd:
port->tcpc->set_pd_rx(port->tcpc, false);
 out_disable_mux:
-   tcpm_mux_set(port, TYPEC_MUX_NONE, TCPC_USB_SWITCH_DISCONNECT);
+   tcpm_mux_set(port, TYPEC_MUX_NONE, USB_ROLE_NONE);
return ret;
 }
 
@@ -2129,6 +2130,7 @@ static void tcpm_reset_port(struct tcpm_port *port)
tcpm_init_vconn(port);
tcpm_set_current_limit(port, 0, 0);
tcpm_set_polarity(port, TYPEC_POLARITY_CC1);
+   tcpm_mux_set(port, TYPEC_MUX_NONE, USB_ROLE_NONE);
tcpm_set_attached_state(port, false);
port->try_src_count = 0;
port->try_snk_count = 0;
@@ -2179,8 +2181,6 @@ static int tcpm_snk_attach(struct tcpm_port *port)
 static void tcpm_snk_detach(struct tcpm_port *port)
 {
tcpm_detach(port);
-
-   /* XXX: (Dis)connect SuperSpeed mux? */
 }
 
 static int tcpm_acc_attach(struct tcpm_port *port)
diff --git a/include/linux/usb/tcpm.h b/include/linux/usb/tcpm.h
index 5a5e1d8c5b65..3e8bdaa5085a 100644
--- a/include/linux/usb/tcpm.h
+++ b/include/linux/usb/tcpm.h
@@ -16,6 +16,7 @@
 #define __LINUX_USB_TCPM_H
 
 #include 
+#include 
 #include 
 #include "pd.h"
 
@@ -98,11 +99,6 @@ struct tcpc_config {
const struct typec_altmode_desc *alt_modes;
 };
 
-enum tcpc_usb_switch {
-   TCPC_USB_SWITCH_CONNECT,
-   TCPC_USB_SWITCH_DISCONNECT,
-};
-
 /* Mux state attributes */
 #define TCPC_MUX_USB_ENABLED   BIT(0)  /* USB enabled */
 #define TCPC_MUX_DP_ENABLEDBIT(1)  /* DP enabled */
@@ -119,7 +115,7 @@ enum tcpc_mux_mode {
 
 struct tcpc_mux_dev {
int (*set)(struct tcpc_mux_dev *dev, enum tcpc_mux_mode mux_mode,
-  enum tcpc_usb_switch usb_config,
+  enum usb_role usb_role,
   enum typec_cc_polarity polarity);
bool dfp_o

[PATCH v8 04/12] usb: typec: Separate the definitions for data and power roles

[Heikki Krogerus]

USB Type-C specification v1.2 separated the power and data
roles more clearly. Dual-Role-Data term was introduced, and
the meaning of DRP was changed from "Dual-Role-Port" to
"Dual-Role-Power".

In order to allow the port drivers to describe the
capabilities of the ports more clearly according to the
newest specifications, introducing separate definitions for
the data roles.

Reviewed-by: Guenter Roeck 
Signed-off-by: Heikki Krogerus 
---
 drivers/usb/typec/class.c   | 56 ++---
 drivers/usb/typec/fusb302/fusb302.c |  1 +
 drivers/usb/typec/tcpm.c|  9 +++---
 drivers/usb/typec/tps6598x.c| 26 +++--
 drivers/usb/typec/typec_wcove.c |  1 +
 drivers/usb/typec/ucsi/ucsi.c   | 13 +++--
 include/linux/usb/tcpm.h|  1 +
 include/linux/usb/typec.h   | 14 --
 8 files changed, 80 insertions(+), 41 deletions(-)

diff --git a/drivers/usb/typec/class.c b/drivers/usb/typec/class.c
index 2620a694704f..53df10df2f9d 100644
--- a/drivers/usb/typec/class.c
+++ b/drivers/usb/typec/class.c
@@ -282,10 +282,10 @@ typec_altmode_roles_show(struct device *dev, struct 
device_attribute *attr,
ssize_t ret;
 
switch (mode->roles) {
-   case TYPEC_PORT_DFP:
+   case TYPEC_PORT_SRC:
ret = sprintf(buf, "source\n");
break;
-   case TYPEC_PORT_UFP:
+   case TYPEC_PORT_SNK:
ret = sprintf(buf, "sink\n");
break;
case TYPEC_PORT_DRP:
@@ -797,14 +797,14 @@ static const char * const typec_data_roles[] = {
 };
 
 static const char * const typec_port_types[] = {
-   [TYPEC_PORT_DFP] = "source",
-   [TYPEC_PORT_UFP] = "sink",
+   [TYPEC_PORT_SRC] = "source",
+   [TYPEC_PORT_SNK] = "sink",
[TYPEC_PORT_DRP] = "dual",
 };
 
 static const char * const typec_port_types_drp[] = {
-   [TYPEC_PORT_DFP] = "dual [source] sink",
-   [TYPEC_PORT_UFP] = "dual source [sink]",
+   [TYPEC_PORT_SRC] = "dual [source] sink",
+   [TYPEC_PORT_SNK] = "dual source [sink]",
[TYPEC_PORT_DRP] = "[dual] source sink",
 };
 
@@ -875,9 +875,7 @@ static ssize_t data_role_store(struct device *dev,
return ret;
 
mutex_lock(&port->port_type_lock);
-   if (port->port_type != TYPEC_PORT_DRP) {
-   dev_dbg(dev, "port type fixed at \"%s\"",
-typec_port_types[port->port_type]);
+   if (port->cap->data != TYPEC_PORT_DRD) {
ret = -EOPNOTSUPP;
goto unlock_and_ret;
}
@@ -897,7 +895,7 @@ static ssize_t data_role_show(struct device *dev,
 {
struct typec_port *port = to_typec_port(dev);
 
-   if (port->cap->type == TYPEC_PORT_DRP)
+   if (port->cap->data == TYPEC_PORT_DRD)
return sprintf(buf, "%s\n", port->data_role == TYPEC_HOST ?
   "[host] device" : "host [device]");
 
@@ -1328,7 +1326,6 @@ struct typec_port *typec_register_port(struct device 
*parent,
   const struct typec_capability *cap)
 {
struct typec_port *port;
-   int role;
int ret;
int id;
 
@@ -1354,21 +1351,36 @@ struct typec_port *typec_register_port(struct device 
*parent,
goto err_mux;
}
 
-   if (cap->type == TYPEC_PORT_DFP)
-   role = TYPEC_SOURCE;
-   else if (cap->type == TYPEC_PORT_UFP)
-   role = TYPEC_SINK;
-   else
-   role = cap->prefer_role;
-
-   if (role == TYPEC_SOURCE) {
-   port->data_role = TYPEC_HOST;
+   switch (cap->type) {
+   case TYPEC_PORT_SRC:
port->pwr_role = TYPEC_SOURCE;
port->vconn_role = TYPEC_SOURCE;
-   } else {
-   port->data_role = TYPEC_DEVICE;
+   break;
+   case TYPEC_PORT_SNK:
port->pwr_role = TYPEC_SINK;
port->vconn_role = TYPEC_SINK;
+   break;
+   case TYPEC_PORT_DRP:
+   if (cap->prefer_role != TYPEC_NO_PREFERRED_ROLE)
+   port->pwr_role = cap->prefer_role;
+   else
+   port->pwr_role = TYPEC_SINK;
+   break;
+   }
+
+   switch (cap->data) {
+   case TYPEC_PORT_DFP:
+   port->data_role = TYPEC_HOST;
+   break;
+   case TYPEC_PORT_UFP:
+   port->data_role = TYPEC_DEVICE;
+   break;
+   case TYPEC_PORT_DRD:
+   if (cap->prefer_role == TYPEC_SOURCE)
+   port->data_role = TYPEC_HOST;
+   else
+   port->data_role = TYPEC_DEVICE;
+   break;
}
 
port->id = id;
diff --git a/drivers/usb/typec/fusb302/fusb302.c 
b/drivers/usb/typec/fusb302/fusb302.c
index da179aaf789e..f2d98c3c1f30 100644
--- a/drivers/usb/typec/fusb302/fusb302.c
+++ b/drivers/usb/typec/fusb302/fusb302.c
@@

[PATCH v8 06/12] usb: typec: tcpm: Use new Type-C switch/mux and usb-role-switch functions

[Heikki Krogerus]

From: Hans de Goede 

Remove the unused (not implemented anywhere) tcpc_mux_dev abstraction
and replace it with calling the new typec_set_orientation,
usb_role_switch_set and typec_set_mode functions.

Signed-off-by: Hans de Goede 
Reviewed-by: Guenter Roeck 
Reviewed-by: Andy Shevchenko 
Signed-off-by: Heikki Krogerus 
---
Changes in v4:
-Add Andy's Reviewed-by

Changes in v3:
-Add Guenter's Reviewed-by

Changes in v2:
-Added Heikki's Reviewed-by
---
 drivers/usb/typec/Kconfig   |  1 +
 drivers/usb/typec/fusb302/fusb302.c |  1 -
 drivers/usb/typec/tcpm.c| 46 -
 include/linux/usb/tcpm.h| 10 
 4 files changed, 36 insertions(+), 22 deletions(-)

diff --git a/drivers/usb/typec/Kconfig b/drivers/usb/typec/Kconfig
index bcb2744c5977..a2a0684e7c82 100644
--- a/drivers/usb/typec/Kconfig
+++ b/drivers/usb/typec/Kconfig
@@ -48,6 +48,7 @@ if TYPEC
 config TYPEC_TCPM
tristate "USB Type-C Port Controller Manager"
depends on USB
+   select USB_ROLE_SWITCH
help
  The Type-C Port Controller Manager provides a USB PD and USB Type-C
  state machine for use with Type-C Port Controllers.
diff --git a/drivers/usb/typec/fusb302/fusb302.c 
b/drivers/usb/typec/fusb302/fusb302.c
index f2d98c3c1f30..f0a2f8954bbd 100644
--- a/drivers/usb/typec/fusb302/fusb302.c
+++ b/drivers/usb/typec/fusb302/fusb302.c
@@ -1239,7 +1239,6 @@ static void init_tcpc_dev(struct tcpc_dev 
*fusb302_tcpc_dev)
fusb302_tcpc_dev->set_roles = tcpm_set_roles;
fusb302_tcpc_dev->start_drp_toggling = tcpm_start_drp_toggling;
fusb302_tcpc_dev->pd_transmit = tcpm_pd_transmit;
-   fusb302_tcpc_dev->mux = NULL;
 }
 
 static const char * const cc_polarity_name[] = {
diff --git a/drivers/usb/typec/tcpm.c b/drivers/usb/typec/tcpm.c
index 5e527e2e1506..3f0851bfe18f 100644
--- a/drivers/usb/typec/tcpm.c
+++ b/drivers/usb/typec/tcpm.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -176,6 +177,7 @@ struct tcpm_port {
struct typec_port *typec_port;
 
struct tcpc_dev *tcpc;
+   struct usb_role_switch *role_sw;
 
enum typec_role vconn_role;
enum typec_role pwr_role;
@@ -607,18 +609,25 @@ void tcpm_pd_transmit_complete(struct tcpm_port *port,
 EXPORT_SYMBOL_GPL(tcpm_pd_transmit_complete);
 
 static int tcpm_mux_set(struct tcpm_port *port, enum tcpc_mux_mode mode,
-   enum usb_role usb_role)
+   enum usb_role usb_role,
+   enum typec_orientation orientation)
 {
-   int ret = 0;
+   int ret;
 
-   tcpm_log(port, "Requesting mux mode %d, usb-role %d, polarity %d",
-mode, usb_role, port->polarity);
+   tcpm_log(port, "Requesting mux mode %d, usb-role %d, orientation %d",
+mode, usb_role, orientation);
 
-   if (port->tcpc->mux)
-   ret = port->tcpc->mux->set(port->tcpc->mux, mode, usb_role,
-  port->polarity);
+   ret = typec_set_orientation(port->typec_port, orientation);
+   if (ret)
+   return ret;
 
-   return ret;
+   if (port->role_sw) {
+   ret = usb_role_switch_set_role(port->role_sw, usb_role);
+   if (ret)
+   return ret;
+   }
+
+   return typec_set_mode(port->typec_port, mode);
 }
 
 static int tcpm_set_polarity(struct tcpm_port *port,
@@ -731,15 +740,21 @@ static int tcpm_set_attached_state(struct tcpm_port 
*port, bool attached)
 static int tcpm_set_roles(struct tcpm_port *port, bool attached,
  enum typec_role role, enum typec_data_role data)
 {
+   enum typec_orientation orientation;
enum usb_role usb_role;
int ret;
 
+   if (port->polarity == TYPEC_POLARITY_CC1)
+   orientation = TYPEC_ORIENTATION_NORMAL;
+   else
+   orientation = TYPEC_ORIENTATION_REVERSE;
+
if (data == TYPEC_HOST)
usb_role = USB_ROLE_HOST;
else
usb_role = USB_ROLE_DEVICE;
 
-   ret = tcpm_mux_set(port, TYPEC_MUX_USB, usb_role);
+   ret = tcpm_mux_set(port, TYPEC_MUX_USB, usb_role, orientation);
if (ret < 0)
return ret;
 
@@ -2086,7 +2101,8 @@ static int tcpm_src_attach(struct tcpm_port *port)
 out_disable_pd:
port->tcpc->set_pd_rx(port->tcpc, false);
 out_disable_mux:
-   tcpm_mux_set(port, TYPEC_MUX_NONE, USB_ROLE_NONE);
+   tcpm_mux_set(port, TYPEC_MUX_NONE, USB_ROLE_NONE,
+TYPEC_ORIENTATION_NONE);
return ret;
 }
 
@@ -2130,7 +2146,8 @@ static void tcpm_reset_port(struct tcpm_port *port)
tcpm_init_vconn(port);
tcpm_set_current_limit(port, 0, 0);
tcpm_set_polarity(port, TYPEC_POLARITY_CC1);
-   tcpm_mux_set(port, TYPEC_MUX_NONE, USB_ROLE_NONE);
+   tcpm_mux_set(port, TYPEC_MUX_NONE, USB_ROLE_NONE,

[PATCH v8 07/12] xhci: Add option to get next extended capability in list by passing id = 0

[Heikki Krogerus]

From: Mathias Nyman 

Modify xhci_find_next_ext_cap(base, offset, id) to return the next
capability offset if 0 is passed for id. Otherwise it will behave as
previously and return the offset of the next capability with matching id

capability id 0 is not used by xHCI (reserved)

This is useful when we want to loop through all capabilities.

Signed-off-by: Mathias Nyman 
Reviewed-by: Andy Shevchenko 
Signed-off-by: Heikki Krogerus 
---
Changes in v4:
-Add Andy's Reviewed-by

Changes in v2:
-Added Heikki's Reviewed-by
---
 drivers/usb/host/xhci-ext-caps.h | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/host/xhci-ext-caps.h b/drivers/usb/host/xhci-ext-caps.h
index bf7316e130d3..631e7cc62604 100644
--- a/drivers/usb/host/xhci-ext-caps.h
+++ b/drivers/usb/host/xhci-ext-caps.h
@@ -84,7 +84,8 @@
  * @base   PCI MMIO registers base address.
  * @start  address at which to start looking, (0 or HCC_PARAMS to start at
  * beginning of list)
- * @id Extended capability ID to search for.
+ * @id Extended capability ID to search for, or 0 for the next
+ * capability
  *
  * Returns the offset of the next matching extended capability structure.
  * Some capabilities can occur several times, e.g., the XHCI_EXT_CAPS_PROTOCOL,
@@ -110,7 +111,7 @@ static inline int xhci_find_next_ext_cap(void __iomem 
*base, u32 start, int id)
val = readl(base + offset);
if (val == ~0)
return 0;
-   if (XHCI_EXT_CAPS_ID(val) == id && offset != start)
+   if (offset != start && (id == 0 || XHCI_EXT_CAPS_ID(val) == id))
return offset;
 
next = XHCI_EXT_CAPS_NEXT(val);
-- 
2.16.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 v8 08/12] xhci: Add Intel extended cap / otg phy mux handling

[Heikki Krogerus]

From: Hans de Goede 

The xHCI controller on various Intel SoCs has an extended cap mmio-range
which contains registers to control the muxing to the xHCI (host mode)
or the dwc3 (device mode) and vbus-detection for the otg usb-phy.

Having a role-sw driver included in the xHCI code (under drivers/usb/host)
is not desirable. So this commit adds a simple handler for this extended
capability, which creates a platform device with the caps mmio region as
resource, this allows us to write a separate platform role-sw driver for
the role-switch.

Note this commit adds a call to the new xhci_ext_cap_init() function
to xhci_pci_probe(), it is added here because xhci_ext_cap_init() must
be called only once. If in the future we also want to handle ext-caps
on non pci xHCI HCDs from xhci_ext_cap_init() a call to it should also
be added to other bus probe paths.

Signed-off-by: Hans de Goede 
Acked-by: Mathias Nyman 
Reviewed-by: Andy Shevchenko 
Signed-off-by: Heikki Krogerus 
---
Changes in v4:
-Add Andy's Reviewed-by

Changes in v2:
-Use SPDX license header
-Various small style cleanups / changes
-Add Heikki's Reviewed-by

Changes from some time ago when this patch was part of another patch-set:
-Check xHCI controller PCI device-id instead of only checking for the
 Intel Extended capability ID, as the Extended capability ID is used on
 other model Intel xHCI controllers too
-Add a new generic xhci_ext_cap_init() function and handle the new
 XHCI_INTEL_CHT_USB_MUX quirk there.
-Stop using Cherry Trail / CHT in various places as other Intel SoCs
 (e.g. Broxton / Apollo Lake) also have this
---
 drivers/usb/host/Makefile|  2 +-
 drivers/usb/host/xhci-ext-caps.c | 90 
 drivers/usb/host/xhci-ext-caps.h |  2 +
 drivers/usb/host/xhci-pci.c  |  5 +++
 drivers/usb/host/xhci.h  |  2 +
 5 files changed, 100 insertions(+), 1 deletion(-)
 create mode 100644 drivers/usb/host/xhci-ext-caps.c

diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index 4ede4ce12366..8a8cffe0b445 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -11,7 +11,7 @@ fhci-y += fhci-mem.o fhci-tds.o fhci-sched.o
 
 fhci-$(CONFIG_FHCI_DEBUG) += fhci-dbg.o
 
-xhci-hcd-y := xhci.o xhci-mem.o
+xhci-hcd-y := xhci.o xhci-mem.o xhci-ext-caps.o
 xhci-hcd-y += xhci-ring.o xhci-hub.o xhci-dbg.o
 xhci-hcd-y += xhci-trace.o
 
diff --git a/drivers/usb/host/xhci-ext-caps.c b/drivers/usb/host/xhci-ext-caps.c
new file mode 100644
index ..399113f9fc5c
--- /dev/null
+++ b/drivers/usb/host/xhci-ext-caps.c
@@ -0,0 +1,90 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * XHCI extended capability handling
+ *
+ * Copyright (c) 2017 Hans de Goede 
+ */
+
+#include 
+#include "xhci.h"
+
+#define USB_SW_DRV_NAME"intel_xhci_usb_sw"
+#define USB_SW_RESOURCE_SIZE   0x400
+
+static void xhci_intel_unregister_pdev(void *arg)
+{
+   platform_device_unregister(arg);
+}
+
+static int xhci_create_intel_xhci_sw_pdev(struct xhci_hcd *xhci, u32 
cap_offset)
+{
+   struct usb_hcd *hcd = xhci_to_hcd(xhci);
+   struct device *dev = hcd->self.controller;
+   struct platform_device *pdev;
+   struct resource res = { 0, };
+   int ret;
+
+   pdev = platform_device_alloc(USB_SW_DRV_NAME, PLATFORM_DEVID_NONE);
+   if (!pdev) {
+   xhci_err(xhci, "couldn't allocate %s platform device\n",
+USB_SW_DRV_NAME);
+   return -ENOMEM;
+   }
+
+   res.start = hcd->rsrc_start + cap_offset;
+   res.end   = res.start + USB_SW_RESOURCE_SIZE - 1;
+   res.name  = USB_SW_DRV_NAME;
+   res.flags = IORESOURCE_MEM;
+
+   ret = platform_device_add_resources(pdev, &res, 1);
+   if (ret) {
+   dev_err(dev, "couldn't add resources to intel_xhci_usb_sw 
pdev\n");
+   platform_device_put(pdev);
+   return ret;
+   }
+
+   pdev->dev.parent = dev;
+
+   ret = platform_device_add(pdev);
+   if (ret) {
+   dev_err(dev, "couldn't register intel_xhci_usb_sw pdev\n");
+   platform_device_put(pdev);
+   return ret;
+   }
+
+   ret = devm_add_action_or_reset(dev, xhci_intel_unregister_pdev, pdev);
+   if (ret) {
+   dev_err(dev, "couldn't add unregister action for 
intel_xhci_usb_sw pdev\n");
+   return ret;
+   }
+
+   return 0;
+}
+
+int xhci_ext_cap_init(struct xhci_hcd *xhci)
+{
+   void __iomem *base = &xhci->cap_regs->hc_capbase;
+   u32 offset, val;
+   int ret;
+
+   offset = xhci_find_next_ext_cap(base, 0, 0);
+
+   while (offset) {
+   val = readl(base + offset);
+
+   switch (XHCI_EXT_CAPS_ID(val)) {
+   case XHCI_EXT_CAPS_VENDOR_INTEL:
+   if (xhci->quirks & XHCI_INTEL_USB_ROLE_SW) {
+   ret = xhci_create_intel_xhci_sw_pdev(xhci,
+  

[PATCH v8 12/12] extcon: axp288: Set USB role where necessary

[Heikki Krogerus]

From: Hans de Goede 

The AXP288 BC1.2 charger detection / extcon code may seem like a strange
place to add code to control the USB role-switch on devices with an AXP288,
but there are 2 reasons to do this inside the axp288 extcon code:

1) On many devices the USB role is controlled by ACPI AML code, but the AML
   code only switches between the host and none roles, because of Windows
   not really using device mode. To make device mode work we need to toggle
   between the none/device roles based on Vbus presence, and the axp288
   extcon gets interrupts on Vbus insertion / removal.

2) In order for our BC1.2 charger detection to work properly the role
   mux must be properly set to device mode before we do the detection.

Also note the Kconfig help-text / obsolete depends on USB_PHY which are
remnants from older never upstreamed code also controlling the mux from
the axp288 extcon code.

This commit also adds code to get notifications from the INT3496 extcon
device, which is used on some devices to notify the kernel about id-pin
changes instead of them being handled through AML code.

This fixes:
-Device mode not working on most CHT devices with an AXP288
-Host mode not working on devices with an INT3496 ACPI device
-Charger-type misdetection (always SDP) on devices with an INT3496 when the
 USB role (always) gets initialized as host

Signed-off-by: Hans de Goede 
Reviewed-by: Andy Shevchenko 
Signed-off-by: Heikki Krogerus 
---
Changes in v4:
-Add Andy's Reviewed-by

Changes in v2:
-Add depends on X86 to Kconfig (the AXP288 PMIC is only used on X86)
-Use new acpi_dev_get_first_match_name() helper to get the INT3496 device-name
-Add Heikki's Reviewed-by
---
 drivers/extcon/Kconfig |   3 +-
 drivers/extcon/extcon-axp288.c | 176 +++--
 2 files changed, 170 insertions(+), 9 deletions(-)

diff --git a/drivers/extcon/Kconfig b/drivers/extcon/Kconfig
index a7bca4207f44..de15bf55895b 100644
--- a/drivers/extcon/Kconfig
+++ b/drivers/extcon/Kconfig
@@ -30,7 +30,8 @@ config EXTCON_ARIZONA
 
 config EXTCON_AXP288
tristate "X-Power AXP288 EXTCON support"
-   depends on MFD_AXP20X && USB_PHY
+   depends on MFD_AXP20X && USB_SUPPORT && X86
+   select USB_ROLE_SWITCH
help
  Say Y here to enable support for USB peripheral detection
  and USB MUX switching by X-Power AXP288 PMIC.
diff --git a/drivers/extcon/extcon-axp288.c b/drivers/extcon/extcon-axp288.c
index 3ec4c715e240..a983708b77a6 100644
--- a/drivers/extcon/extcon-axp288.c
+++ b/drivers/extcon/extcon-axp288.c
@@ -1,6 +1,7 @@
 /*
  * extcon-axp288.c - X-Power AXP288 PMIC extcon cable detection driver
  *
+ * Copyright (c) 2017-2018 Hans de Goede 
  * Copyright (C) 2015 Intel Corporation
  * Author: Ramakrishna Pallala 
  *
@@ -14,6 +15,7 @@
  * GNU General Public License for more details.
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -25,6 +27,11 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+
+#include 
+#include 
 
 /* Power source status register */
 #define PS_STAT_VBUS_TRIGGER   BIT(0)
@@ -97,9 +104,19 @@ struct axp288_extcon_info {
struct device *dev;
struct regmap *regmap;
struct regmap_irq_chip_data *regmap_irqc;
+   struct usb_role_switch *role_sw;
+   struct work_struct role_work;
int irq[EXTCON_IRQ_END];
struct extcon_dev *edev;
+   struct extcon_dev *id_extcon;
+   struct notifier_block id_nb;
unsigned int previous_cable;
+   bool vbus_attach;
+};
+
+static const struct x86_cpu_id cherry_trail_cpu_ids[] = {
+   { X86_VENDOR_INTEL, 6, INTEL_FAM6_ATOM_AIRMONT, X86_FEATURE_ANY },
+   {}
 };
 
 /* Power up/down reason string array */
@@ -137,20 +154,74 @@ static void axp288_extcon_log_rsi(struct 
axp288_extcon_info *info)
regmap_write(info->regmap, AXP288_PS_BOOT_REASON_REG, clear_mask);
 }
 
-static int axp288_handle_chrg_det_event(struct axp288_extcon_info *info)
+/*
+ * The below code to control the USB role-switch on devices with an AXP288
+ * may seem out of place, but there are 2 reasons why this is the best place
+ * to control the USB role-switch on such devices:
+ * 1) On many devices the USB role is controlled by AML code, but the AML code
+ *only switches between the host and none roles, because of Windows not
+ *really using device mode. To make device mode work we need to toggle
+ *between the none/device roles based on Vbus presence, and this driver
+ *gets interrupts on Vbus insertion / removal.
+ * 2) In order for our BC1.2 charger detection to work properly the role
+ *mux must be properly set to device mode before we do the detection.
+ */
+
+/* Returns the id-pin value, note pulled low / false == host-mode */
+static bool axp288_get_id_pin(struct axp288_extcon_info *info)
 {
-   int ret, stat, cfg, pwr_stat;
-   u8 chrg_type;
-   unsigned int cable = info->previous_cable;
-   bool vbus_attach = false;
+  

[PATCH v8 10/12] usb: typec: driver for Pericom PI3USB30532 Type-C cross switch

[Heikki Krogerus]

From: Hans de Goede 

Add a driver for the Pericom PI3USB30532 Type-C cross switch /
mux chip found on some devices with a Type-C port.

Signed-off-by: Hans de Goede 
Reviewed-by: Andy Shevchenko 
Signed-off-by: Heikki Krogerus 
---
Changes in v7:
- Remove unneeded semicolon

Changes in v4:
-Add Andy's Reviewed-by

Changes in v2:
-Cleanup pi3usb30532_set_conf() error handling
-Add Heikki's Reviewed-by

Changes in v1:
-This is a rewrite of my previous driver which was using the
 drivers/mux framework to use the new drivers/usb/typec/mux framework
---
 MAINTAINERS |   6 ++
 drivers/usb/typec/Kconfig   |   2 +
 drivers/usb/typec/Makefile  |   1 +
 drivers/usb/typec/mux/Kconfig   |  10 ++
 drivers/usb/typec/mux/Makefile  |   3 +
 drivers/usb/typec/mux/pi3usb30532.c | 178 
 6 files changed, 200 insertions(+)
 create mode 100644 drivers/usb/typec/mux/Kconfig
 create mode 100644 drivers/usb/typec/mux/Makefile
 create mode 100644 drivers/usb/typec/mux/pi3usb30532.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 5f1988cddbe8..17b64236719f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -14521,6 +14521,12 @@ F: drivers/usb/
 F: include/linux/usb.h
 F: include/linux/usb/
 
+USB TYPEC PI3USB30532 MUX DRIVER
+M: Hans de Goede 
+L: linux-usb@vger.kernel.org
+S: Maintained
+F: drivers/usb/typec/mux/pi3usb30532.c
+
 USB TYPEC SUBSYSTEM
 M: Heikki Krogerus 
 L: linux-usb@vger.kernel.org
diff --git a/drivers/usb/typec/Kconfig b/drivers/usb/typec/Kconfig
index a2a0684e7c82..030f88cb0c3f 100644
--- a/drivers/usb/typec/Kconfig
+++ b/drivers/usb/typec/Kconfig
@@ -85,4 +85,6 @@ config TYPEC_TPS6598X
  If you choose to build this driver as a dynamically linked module, the
  module will be called tps6598x.ko.
 
+source "drivers/usb/typec/mux/Kconfig"
+
 endif # TYPEC
diff --git a/drivers/usb/typec/Makefile b/drivers/usb/typec/Makefile
index 56b2e9516ec1..1f599a6c30cc 100644
--- a/drivers/usb/typec/Makefile
+++ b/drivers/usb/typec/Makefile
@@ -6,3 +6,4 @@ obj-y   += fusb302/
 obj-$(CONFIG_TYPEC_WCOVE)  += typec_wcove.o
 obj-$(CONFIG_TYPEC_UCSI)   += ucsi/
 obj-$(CONFIG_TYPEC_TPS6598X)   += tps6598x.o
+obj-$(CONFIG_TYPEC)+= mux/
diff --git a/drivers/usb/typec/mux/Kconfig b/drivers/usb/typec/mux/Kconfig
new file mode 100644
index ..9a954d2b8d8f
--- /dev/null
+++ b/drivers/usb/typec/mux/Kconfig
@@ -0,0 +1,10 @@
+menu "USB Type-C Multiplexer/DeMultiplexer Switch support"
+
+config TYPEC_MUX_PI3USB30532
+   tristate "Pericom PI3USB30532 Type-C cross switch driver"
+   depends on I2C
+   help
+ Say Y or M if your system has a Pericom PI3USB30532 Type-C cross
+ switch / mux chip found on some devices with a Type-C port.
+
+endmenu
diff --git a/drivers/usb/typec/mux/Makefile b/drivers/usb/typec/mux/Makefile
new file mode 100644
index ..1332e469b8a0
--- /dev/null
+++ b/drivers/usb/typec/mux/Makefile
@@ -0,0 +1,3 @@
+# SPDX-License-Identifier: GPL-2.0
+
+obj-$(CONFIG_TYPEC_MUX_PI3USB30532)+= pi3usb30532.o
diff --git a/drivers/usb/typec/mux/pi3usb30532.c 
b/drivers/usb/typec/mux/pi3usb30532.c
new file mode 100644
index ..b0e88db60ecf
--- /dev/null
+++ b/drivers/usb/typec/mux/pi3usb30532.c
@@ -0,0 +1,178 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Pericom PI3USB30532 Type-C cross switch / mux driver
+ *
+ * Copyright (c) 2017-2018 Hans de Goede 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define PI3USB30532_CONF   0x00
+
+#define PI3USB30532_CONF_OPEN  0x00
+#define PI3USB30532_CONF_SWAP  0x01
+#define PI3USB30532_CONF_4LANE_DP  0x02
+#define PI3USB30532_CONF_USB3  0x04
+#define PI3USB30532_CONF_USB3_AND_2LANE_DP 0x06
+
+struct pi3usb30532 {
+   struct i2c_client *client;
+   struct mutex lock; /* protects the cached conf register */
+   struct typec_switch sw;
+   struct typec_mux mux;
+   u8 conf;
+};
+
+static int pi3usb30532_set_conf(struct pi3usb30532 *pi, u8 new_conf)
+{
+   int ret = 0;
+
+   if (pi->conf == new_conf)
+   return 0;
+
+   ret = i2c_smbus_write_byte_data(pi->client, PI3USB30532_CONF, new_conf);
+   if (ret) {
+   dev_err(&pi->client->dev, "Error writing conf: %d\n", ret);
+   return ret;
+   }
+
+   pi->conf = new_conf;
+   return 0;
+}
+
+static int pi3usb30532_sw_set(struct typec_switch *sw,
+ enum typec_orientation orientation)
+{
+   struct pi3usb30532 *pi = container_of(sw, struct pi3usb30532, sw);
+   u8 new_conf;
+   int ret;
+
+   mutex_lock(&pi->lock);
+   new_conf = pi->conf;
+
+   switch (orientation) {
+   case TYPEC_ORIENTATION_NONE:
+   new_conf = PI3USB30532_CONF_OPEN;
+   break;
+ 

[PATCH v8 11/12] platform/x86: intel_cht_int33fe: Add device connections for the Type-C port

[Heikki Krogerus]

From: Hans de Goede 

We need to add device-connections for the Type-C mux/switch and usb-role
code to be able to find the PI3USB30532 Type-C cross-switch and the
device/host role-switch integrated in the CHT SoC.

Signed-off-by: Hans de Goede 
Reviewed-by: Andy Shevchenko 
Signed-off-by: Heikki Krogerus 
---
Changes in v4:
-Replace Andy's Acked-by with his Reviewed-by

Changes in v2:
-Add Andy's Acked-by
-Add Heikki's Reviewed-by
---
 drivers/platform/x86/intel_cht_int33fe.c | 24 
 1 file changed, 24 insertions(+)

diff --git a/drivers/platform/x86/intel_cht_int33fe.c 
b/drivers/platform/x86/intel_cht_int33fe.c
index 380ef7ec094f..39d4100c60a2 100644
--- a/drivers/platform/x86/intel_cht_int33fe.c
+++ b/drivers/platform/x86/intel_cht_int33fe.c
@@ -33,6 +33,8 @@ struct cht_int33fe_data {
struct i2c_client *max17047;
struct i2c_client *fusb302;
struct i2c_client *pi3usb30532;
+   /* Contain a list-head must be per device */
+   struct device_connection connections[3];
 };
 
 /*
@@ -172,6 +174,20 @@ static int cht_int33fe_probe(struct i2c_client *client)
return -EPROBE_DEFER; /* Wait for i2c-adapter to load */
}
 
+   data->connections[0].endpoint[0] = "i2c-fusb302";
+   data->connections[0].endpoint[1] = "i2c-pi3usb30532";
+   data->connections[0].id = "typec-switch";
+   data->connections[1].endpoint[0] = "i2c-fusb302";
+   data->connections[1].endpoint[1] = "i2c-pi3usb30532";
+   data->connections[1].id = "typec-mux";
+   data->connections[2].endpoint[0] = "i2c-fusb302";
+   data->connections[2].endpoint[1] = "intel_xhci_usb_sw-role-switch";
+   data->connections[2].id = "usb-role-switch";
+
+   device_connection_add(&data->connections[0]);
+   device_connection_add(&data->connections[1]);
+   device_connection_add(&data->connections[2]);
+
memset(&board_info, 0, sizeof(board_info));
strlcpy(board_info.type, "typec_fusb302", I2C_NAME_SIZE);
board_info.dev_name = "fusb302";
@@ -201,6 +217,10 @@ static int cht_int33fe_probe(struct i2c_client *client)
if (data->max17047)
i2c_unregister_device(data->max17047);
 
+   device_connection_remove(&data->connections[2]);
+   device_connection_remove(&data->connections[1]);
+   device_connection_remove(&data->connections[0]);
+
return -EPROBE_DEFER; /* Wait for the i2c-adapter to load */
 }
 
@@ -213,6 +233,10 @@ static int cht_int33fe_remove(struct i2c_client *i2c)
if (data->max17047)
i2c_unregister_device(data->max17047);
 
+   device_connection_remove(&data->connections[2]);
+   device_connection_remove(&data->connections[1]);
+   device_connection_remove(&data->connections[0]);
+
return 0;
 }
 
-- 
2.16.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 v8 09/12] usb: roles: Add Intel xHCI USB role switch driver

[Heikki Krogerus]

From: Hans de Goede 

Various Intel SoCs (Cherry Trail, Broxton and others) have an internal USB
role switch for swiching the OTG USB data lines between the xHCI host
controller and the dwc3 gadget controller.

Note on some Cherry Trail systems there is ACPI/AML code listening to
edge interrupts on the id-pin (through an _AIE ACPI method) and switching
the role between ROLE_HOST and ROLE_NONE based on the id-pin. Note it does
not set the role to ROLE_DEVICE, because device-mode is usually not used
under Windows.

The presence of AML code which modifies the cfg0 reg (on some systems)
means that our read/write/modify of cfg0 may race with the AML code
doing the same to avoid this we take the global ACPI lock while doing
the read/write/modify.

Signed-off-by: Hans de Goede 
Reviewed-by: Andy Shevchenko 
Signed-off-by: Heikki Krogerus 
---
Changes in v7:
- Declare intel_xhci_usb_remove() as static

Changes in v4:
-Add Andy's Reviewed-by
-Add Heikki's Reviewed-by

Changes in v2:
-Drop unnecessary depends on EXTCON from Kconfig
-Use BIT(), resource_size()
-Various other small style fixes
---
 MAINTAINERS|   6 +
 drivers/usb/Kconfig|   2 +
 drivers/usb/Makefile   |   2 +
 drivers/usb/roles/Kconfig  |  14 ++
 drivers/usb/roles/Makefile |   1 +
 drivers/usb/roles/intel-xhci-usb-role-switch.c | 192 +
 6 files changed, 217 insertions(+)
 create mode 100644 drivers/usb/roles/Kconfig
 create mode 100644 drivers/usb/roles/Makefile
 create mode 100644 drivers/usb/roles/intel-xhci-usb-role-switch.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 93a12af4f180..5f1988cddbe8 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -14385,6 +14385,12 @@ S: Maintained
 F: Documentation/hid/hiddev.txt
 F: drivers/hid/usbhid/
 
+USB INTEL XHCI ROLE MUX DRIVER
+M: Hans de Goede 
+L: linux-usb@vger.kernel.org
+S: Maintained
+F: drivers/usb/roles/intel-xhci-usb-role-switch.c
+
 USB ISP116X DRIVER
 M: Olav Kongas 
 L: linux-usb@vger.kernel.org
diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig
index f278958e04ca..75f7fb151f71 100644
--- a/drivers/usb/Kconfig
+++ b/drivers/usb/Kconfig
@@ -171,6 +171,8 @@ source "drivers/usb/gadget/Kconfig"
 
 source "drivers/usb/typec/Kconfig"
 
+source "drivers/usb/roles/Kconfig"
+
 config USB_LED_TRIG
bool "USB LED Triggers"
depends on LEDS_CLASS && LEDS_TRIGGERS
diff --git a/drivers/usb/Makefile b/drivers/usb/Makefile
index 060643a1b5c8..7d1b8c82b208 100644
--- a/drivers/usb/Makefile
+++ b/drivers/usb/Makefile
@@ -65,3 +65,5 @@ obj-$(CONFIG_USB_COMMON)  += common/
 obj-$(CONFIG_USBIP_CORE)   += usbip/
 
 obj-$(CONFIG_TYPEC)+= typec/
+
+obj-$(CONFIG_USB_ROLE_SWITCH)  += roles/
diff --git a/drivers/usb/roles/Kconfig b/drivers/usb/roles/Kconfig
new file mode 100644
index ..f5a5e6f79f1b
--- /dev/null
+++ b/drivers/usb/roles/Kconfig
@@ -0,0 +1,14 @@
+if USB_ROLE_SWITCH
+
+config USB_ROLES_INTEL_XHCI
+   tristate "Intel XHCI USB Role Switch"
+   depends on ACPI && X86
+   help
+ Driver for the internal USB role switch for switching the USB data
+ lines between the xHCI host controller and the dwc3 gadget controller
+ found on various Intel SoCs.
+
+ To compile the driver as a module, choose M here: the module will
+ be called intel-xhci-usb-role-switch.
+
+endif # USB_ROLE_SWITCH
diff --git a/drivers/usb/roles/Makefile b/drivers/usb/roles/Makefile
new file mode 100644
index ..e44b179ba275
--- /dev/null
+++ b/drivers/usb/roles/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_USB_ROLES_INTEL_XHCI) += intel-xhci-usb-role-switch.o
diff --git a/drivers/usb/roles/intel-xhci-usb-role-switch.c 
b/drivers/usb/roles/intel-xhci-usb-role-switch.c
new file mode 100644
index ..58c1b60a33c1
--- /dev/null
+++ b/drivers/usb/roles/intel-xhci-usb-role-switch.c
@@ -0,0 +1,192 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Intel XHCI (Cherry Trail, Broxton and others) USB OTG role switch driver
+ *
+ * Copyright (c) 2016-2017 Hans de Goede 
+ *
+ * Loosely based on android x86 kernel code which is:
+ *
+ * Copyright (C) 2014 Intel Corp.
+ *
+ * Author: Wu, Hao
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* register definition */
+#define DUAL_ROLE_CFG0 0x68
+#define SW_VBUS_VALID  BIT(24)
+#define SW_IDPIN_ENBIT(21)
+#define SW_IDPIN   BIT(20)
+
+#define DUAL_ROLE_CFG1 0x6c
+#define HOST_MODE  BIT(29)
+
+#define DUAL_ROLE_CFG1_POLL_TIMEOUT1000
+
+#define DRV_NAME   "intel_xhci_usb_sw"
+
+struct intel_xhci_usb_data {
+   struct usb_role_switch *role_sw;
+   void __iomem *base;
+};
+
+struct intel_xhci_acpi_match {
+   const char *hid;
+   

[PATCH v8 03/12] usb: common: Small class for USB role switches

[Heikki Krogerus]

USB role switch is a device that can be used to choose the
data role for USB connector. With dual-role capable USB
controllers, the controller itself will be the switch, but
on some platforms the USB host and device controllers are
separate IPs and there is a mux between them and the
connector. On those platforms the mux driver will need to
register the switch.

With USB Type-C connectors, the host-to-device relationship
is negotiated over the Configuration Channel (CC). That
means the USB Type-C drivers need to be in control of the
role switch. The class provides a simple API for the USB
Type-C drivers for the control.

For other types of USB connectors (mainly microAB) the class
provides user space control via sysfs attribute file that
can be used to request role swapping from the switch.

Reviewed-by: Hans de Goede 
Reviewed-by: Andy Shevchenko 
Signed-off-by: Heikki Krogerus 
---
Changes in v4:
-Consistently use IS_ERR_OR_NULL where applicable
-Add Andy's Reviewed-by

Changes in v2:
-Minor style fixes from review of v1
---
 Documentation/ABI/testing/sysfs-class-usb_role |  21 ++
 drivers/usb/Kconfig|   3 +
 drivers/usb/common/Makefile|   1 +
 drivers/usb/common/roles.c | 305 +
 include/linux/usb/role.h   |  53 +
 5 files changed, 383 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-class-usb_role
 create mode 100644 drivers/usb/common/roles.c
 create mode 100644 include/linux/usb/role.h

diff --git a/Documentation/ABI/testing/sysfs-class-usb_role 
b/Documentation/ABI/testing/sysfs-class-usb_role
new file mode 100644
index ..3b810a425a52
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-usb_role
@@ -0,0 +1,21 @@
+What:  /sys/class/usb_role/
+Date:  Jan 2018
+Contact:   Heikki Krogerus 
+Description:
+   Place in sysfs for USB Role Switches. USB Role Switch is a
+   device that can select the data role (host or device) for USB
+   port.
+
+What:  /sys/class/usb_role//role
+Date:  Jan 2018
+Contact:   Heikki Krogerus 
+Description:
+   The current role of the switch. This attribute can be used for
+   requesting role swapping with non-USB Type-C ports. With USB
+   Type-C ports, the ABI defined for USB Type-C connector class
+   must be used.
+
+   Valid values:
+   - none
+   - host
+   - device
diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig
index 148f3ee70286..f278958e04ca 100644
--- a/drivers/usb/Kconfig
+++ b/drivers/usb/Kconfig
@@ -203,4 +203,7 @@ config USB_ULPI_BUS
  To compile this driver as a module, choose M here: the module will
  be called ulpi.
 
+config USB_ROLE_SWITCH
+   tristate
+
 endif # USB_SUPPORT
diff --git a/drivers/usb/common/Makefile b/drivers/usb/common/Makefile
index 0a7c45e85481..fb4d5ef4165c 100644
--- a/drivers/usb/common/Makefile
+++ b/drivers/usb/common/Makefile
@@ -9,3 +9,4 @@ usb-common-$(CONFIG_USB_LED_TRIG) += led.o
 
 obj-$(CONFIG_USB_OTG_FSM) += usb-otg-fsm.o
 obj-$(CONFIG_USB_ULPI_BUS) += ulpi.o
+obj-$(CONFIG_USB_ROLE_SWITCH)  += roles.o
diff --git a/drivers/usb/common/roles.c b/drivers/usb/common/roles.c
new file mode 100644
index ..15cc76e22123
--- /dev/null
+++ b/drivers/usb/common/roles.c
@@ -0,0 +1,305 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * USB Role Switch Support
+ *
+ * Copyright (C) 2018 Intel Corporation
+ * Author: Heikki Krogerus 
+ * Hans de Goede 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static struct class *role_class;
+
+struct usb_role_switch {
+   struct device dev;
+   struct mutex lock; /* device lock*/
+   enum usb_role role;
+
+   /* From descriptor */
+   struct device *usb2_port;
+   struct device *usb3_port;
+   struct device *udc;
+   usb_role_switch_set_t set;
+   usb_role_switch_get_t get;
+   bool allow_userspace_control;
+};
+
+#define to_role_switch(d)  container_of(d, struct usb_role_switch, dev)
+
+/**
+ * usb_role_switch_set_role - Set USB role for a switch
+ * @sw: USB role switch
+ * @role: USB role to be switched to
+ *
+ * Set USB role @role for @sw.
+ */
+int usb_role_switch_set_role(struct usb_role_switch *sw, enum usb_role role)
+{
+   int ret;
+
+   if (IS_ERR_OR_NULL(sw))
+   return 0;
+
+   mutex_lock(&sw->lock);
+
+   ret = sw->set(sw->dev.parent, role);
+   if (!ret)
+   sw->role = role;
+
+   mutex_unlock(&sw->lock);
+
+   return ret;
+}
+EXPORT_SYMBOL_GPL(usb_role_switch_set_role);
+
+/**
+ * usb_role_switch_get_role - Get the USB role for a switch
+ * @sw: USB role switch
+ *
+ * Depending on the role-switch-driver this function returns either a cached
+ * value of the last set role, or reads back the actual value from the 

[PATCH v8 02/12] usb: typec: API for controlling USB Type-C Multiplexers

[Heikki Krogerus]

USB Type-C connectors consist of various muxes and switches
that route the pins on the connector to the right locations.
The USB Type-C drivers need to be able to control the muxes,
as they are the ones that know things like the cable plug
orientation, and the current mode that was negotiated with
the partner.

This introduces a small API for registering and controlling
cable plug orientation switches, and separate small API for
registering and controlling pin multiplexer/demultiplexer
switches that are needed with Accessory/Alternate Modes.

Reviewed-by: Hans de Goede 
Reviewed-by: Andy Shevchenko 
Signed-off-by: Heikki Krogerus 
---
Changes in v4:
-Add Andy's Reviewed-by

Changes in v3:
-Add #include-s for a few missing headers to drivers/usb/typec/mux.c
-Various spelling and gramar fixes in the docs pointed out by Randy Dunlap
---
 Documentation/driver-api/usb/typec.rst |  73 +++--
 drivers/usb/typec/Makefile |   1 +
 drivers/usb/typec/{typec.c => class.c} |  70 
 drivers/usb/typec/mux.c| 191 +
 include/linux/usb/typec.h  |  14 +++
 include/linux/usb/typec_mux.h  |  55 ++
 6 files changed, 393 insertions(+), 11 deletions(-)
 rename drivers/usb/typec/{typec.c => class.c} (95%)
 create mode 100644 drivers/usb/typec/mux.c
 create mode 100644 include/linux/usb/typec_mux.h

diff --git a/Documentation/driver-api/usb/typec.rst 
b/Documentation/driver-api/usb/typec.rst
index 8a7249f2ff04..feb31946490b 100644
--- a/Documentation/driver-api/usb/typec.rst
+++ b/Documentation/driver-api/usb/typec.rst
@@ -61,7 +61,7 @@ Registering the ports
 The port drivers will describe every Type-C port they control with struct
 typec_capability data structure, and register them with the following API:
 
-.. kernel-doc:: drivers/usb/typec/typec.c
+.. kernel-doc:: drivers/usb/typec/class.c
:functions: typec_register_port typec_unregister_port
 
 When registering the ports, the prefer_role member in struct typec_capability
@@ -80,7 +80,7 @@ typec_partner_desc. The class copies the details of the 
partner during
 registration. The class offers the following API for registering/unregistering
 partners.
 
-.. kernel-doc:: drivers/usb/typec/typec.c
+.. kernel-doc:: drivers/usb/typec/class.c
:functions: typec_register_partner typec_unregister_partner
 
 The class will provide a handle to struct typec_partner if the registration was
@@ -92,7 +92,7 @@ should include handle to struct usb_pd_identity instance. The 
class will then
 create a sysfs directory for the identity under the partner device. The result
 of Discover Identity command can then be reported with the following API:
 
-.. kernel-doc:: drivers/usb/typec/typec.c
+.. kernel-doc:: drivers/usb/typec/class.c
:functions: typec_partner_set_identity
 
 Registering Cables
@@ -113,7 +113,7 @@ typec_cable_desc and about a plug in struct 
typec_plug_desc. The class copies
 the details during registration. The class offers the following API for
 registering/unregistering cables and their plugs:
 
-.. kernel-doc:: drivers/usb/typec/typec.c
+.. kernel-doc:: drivers/usb/typec/class.c
:functions: typec_register_cable typec_unregister_cable typec_register_plug 
typec_unregister_plug
 
 The class will provide a handle to struct typec_cable and struct typec_plug if
@@ -125,7 +125,7 @@ include handle to struct usb_pd_identity instance. The 
class will then create a
 sysfs directory for the identity under the cable device. The result of Discover
 Identity command can then be reported with the following API:
 
-.. kernel-doc:: drivers/usb/typec/typec.c
+.. kernel-doc:: drivers/usb/typec/class.c
:functions: typec_cable_set_identity
 
 Notifications
@@ -135,7 +135,7 @@ When the partner has executed a role change, or when the 
default roles change
 during connection of a partner or cable, the port driver must use the following
 APIs to report it to the class:
 
-.. kernel-doc:: drivers/usb/typec/typec.c
+.. kernel-doc:: drivers/usb/typec/class.c
:functions: typec_set_data_role typec_set_pwr_role typec_set_vconn_role 
typec_set_pwr_opmode
 
 Alternate Modes
@@ -150,7 +150,7 @@ and struct typec_altmode_desc which is a container for all 
the supported modes.
 Ports that support Alternate Modes need to register each SVID they support with
 the following API:
 
-.. kernel-doc:: drivers/usb/typec/typec.c
+.. kernel-doc:: drivers/usb/typec/class.c
:functions: typec_port_register_altmode
 
 If a partner or cable plug provides a list of SVIDs as response to USB Power
@@ -159,12 +159,12 @@ registered.
 
 API for the partners:
 
-.. kernel-doc:: drivers/usb/typec/typec.c
+.. kernel-doc:: drivers/usb/typec/class.c
:functions: typec_partner_register_altmode
 
 API for the Cable Plugs:
 
-.. kernel-doc:: drivers/usb/typec/typec.c
+.. kernel-doc:: drivers/usb/typec/class.c
:functions: typec_plug_register_altmode
 
 So ports, partners and cable plugs will register the altern

Re: Debugging SCSI 'UNMAP' ("Logical Block Provisioning") failure on an SSD

[Kashyap Chamarthy]

On Wed, Mar 14, 2018 at 12:29:50PM +0100, Oliver Neukum wrote:
> Am Mittwoch, den 14.03.2018, 11:22 +0100 schrieb Kashyap Chamarthy:
> > I see.  So I ran `dmesg -w`, as I attached the disk & see the following:
> 
> UAS and no quirk for your device. It looks like it indeed just does
> not support TRIM.

Sorry, I didn't give you complete information — with the previous
`dmesg` output, I actually attached the SSD (Samsung T5) via regular USB
"A Cable".  

Now, I re-attached the SSD via the "Thunderbolt" port on my other laptop
(Lenovo T470s), it _does_ show "UAS".   Refer the arrow below:

[...]
[131839.680706] usb 4-1: new SuperSpeedPlus USB device number 2 using xhci_hcd
[131839.698814] usb 4-1: New USB device found, idVendor=04e8, idProduct=61f5
[131839.698817] usb 4-1: New USB device strings: Mfr=2, Product=3, 
SerialNumber=1
[131839.698818] usb 4-1: Product: Portable SSD T5
[131839.698819] usb 4-1: Manufacturer: Samsung
[131839.698820] usb 4-1: SerialNumber: 1234567A7AD6
[131839.701232] scsi host2: uas   <---
[131839.701631] scsi 2:0:0:0: Direct-Access Samsung  Portable SSD T5  0
PQ: 0 ANSI: 6
[131839.703470] sd 2:0:0:0: Attached scsi generic sg1 type 0
[131839.705486] sd 2:0:0:0: [sdc] 976773168 512-byte logical blocks: (500 
GB/466 GiB)
[131839.705895] sd 2:0:0:0: [sdc] Write Protect is off
[131839.705900] sd 2:0:0:0: [sdc] Mode Sense: 43 00 00 00
[131839.706146] sd 2:0:0:0: [sdc] Write cache: enabled, read cache: enabled, 
doesn't support DPO or FUA
[131839.709656] sd 2:0:0:0: [sdc] Attached SCSI disk
[131839.927167] EXT4-fs (sdc): recovery complete
[131839.927175] EXT4-fs (sdc): mounted filesystem with ordered data mode. Opts: 
(null)
[...]

-- 
/kashyap
--
To unsubscribe from this list: send the line "unsubscribe 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 v7 01/12] drivers: base: Unified device connection lookup

[Greg Kroah-Hartman]

On Wed, Mar 14, 2018 at 02:13:23PM +0200, Heikki Krogerus wrote:
> > Sorry I missed this the last review cycles.
> 
> Np. I'll prepare v8. This will not affect the other patches, so is it
> enough if I just update this patch? Or do you prefer that I re-send
> the whole series?

Resending the whole series makes it easiest for me, 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 2/3] usb: host: pci: introduce PCI vendor ID for Netlogic

[Oliver Neukum]

Am Mittwoch, den 14.03.2018, 11:29 +0100 schrieb Richard Leitner:
> From: Richard Leitner 
> 
> Replace the hardcoded PCI vendor ID of Netlogic with a definition in
> pci_ids.h

Hi,

in general, why?
Does this patch generate any benefit for any developer
reading the source? I don't see it. Does it cause an
issue for anybody who has a log file with the nummerical
ID and needs to grep for it? Yes it does.

Where is the point of this patch?

Regards
Oliver

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

Re: [PATCH v7 01/12] drivers: base: Unified device connection lookup

[Heikki Krogerus]

On Wed, Mar 14, 2018 at 12:16:05PM +0100, Greg Kroah-Hartman wrote:
> On Mon, Mar 12, 2018 at 05:34:20PM +0300, Heikki Krogerus wrote:
> > Several frameworks - clk, gpio, phy, pmw, etc. - maintain
> > lookup tables for describing connections and provide custom
> > API for handling them. This introduces a single generic
> > lookup table and API for the connections.
> > 
> > The motivation for this commit is centralizing the
> > connection lookup, but the goal is to ultimately extract the
> > connection descriptions also from firmware by using the
> > fwnode_graph_* functions and other mechanisms that are
> > available.
> > 
> > Reviewed-by: Hans de Goede 
> > Reviewed-by: Andy Shevchenko 
> > Signed-off-by: Heikki Krogerus 
> > ---
> > Changes in v7:
> > - API naming improvements suggested by Greg
> > - Prototypes to device.h, also suggested by Greg
> > - I removed the DEVCON() macro as it was not used yet and it needs to be
> >   rewritten
> > 
> > Changes in v6:
> > -Fix data and match arguments being swapped in __device_find_connection()
> >  call in device_find_connection() (as noticed by Jun Li)
> > 
> > Changes in v5:
> > -Add missing documentation for @list struct devcon member
> > 
> > Changes in v4:
> > -Add Andy's Reviewed-by
> > 
> > Changes in v3:
> > -Various spelling and gramar fixes in the docs pointed out by Randy Dunlap
> > 
> > Changes in v2:
> > -Add a (struct devcon) cast to the DEVCON() macro
> > ---
> >  Documentation/driver-api/device_connection.rst |  43 
> >  drivers/base/Makefile  |   3 +-
> >  drivers/base/devcon.c  | 141 
> > +
> >  include/linux/device.h |  22 
> >  4 files changed, 208 insertions(+), 1 deletion(-)
> >  create mode 100644 Documentation/driver-api/device_connection.rst
> >  create mode 100644 drivers/base/devcon.c
> > 
> > diff --git a/Documentation/driver-api/device_connection.rst 
> > b/Documentation/driver-api/device_connection.rst
> > new file mode 100644
> > index ..affbc5566ab0
> > --- /dev/null
> > +++ b/Documentation/driver-api/device_connection.rst
> > @@ -0,0 +1,43 @@
> > +==
> > +Device connections
> > +==
> > +
> > +Introduction
> > +
> > +
> > +Devices often have connections to other devices that are outside of the 
> > direct
> > +child/parent relationship. A serial or network communication controller, 
> > which
> > +could be a PCI device, may need to be able to get a reference to its PHY
> > +component, which could be attached for example to the I2C bus. Some device
> > +drivers need to be able to control the clocks or the GPIOs for their 
> > devices,
> > +and so on.
> > +
> > +Device connections are generic descriptions of any type of connection 
> > between
> > +two separate devices.
> > +
> > +Device connections alone do not create a dependency between the two 
> > devices.
> > +They are only descriptions which are not tied to either of the devices 
> > directly.
> > +A dependency between the two devices exists only if one of the two endpoint
> > +devices requests a reference to the other. The descriptions themselves can 
> > be
> > +defined in firmware (not yet supported) or they can be built-in.
> > +
> > +Usage
> > +-
> > +
> > +Device connections should exist before device ``->probe`` callback is 
> > called for
> > +either endpoint device in the description. If the connections are defined 
> > in
> > +firmware, this is not a problem. It should be considered if the connection
> > +descriptions are "built-in", and need to be added separately.
> > +
> > +The connection description consists of the names of the two devices with 
> > the
> > +connection, i.e. the endpoints, and unique identifier for the connection 
> > which
> > +is needed if there are multiple connections between the two devices.
> > +
> > +After a description exists, the devices in it can request reference to the 
> > other
> > +endpoint device, or they can request the description itself.
> > +
> > +API
> > +---
> > +
> > +.. kernel-doc:: drivers/base/devcon.c
> > +   : functions: device_connection_find_match device_connection_find 
> > device_connection_add device_connection_remove
> > diff --git a/drivers/base/Makefile b/drivers/base/Makefile
> > index e32a52490051..12a7f64d35a9 100644
> > --- a/drivers/base/Makefile
> > +++ b/drivers/base/Makefile
> > @@ -5,7 +5,8 @@ obj-y   := component.o core.o bus.o 
> > dd.o syscore.o \
> >driver.o class.o platform.o \
> >cpu.o firmware.o init.o map.o devres.o \
> >attribute_container.o transport_class.o \
> > -  topology.o container.o property.o cacheinfo.o
> > +  topology.o container.o property.o cacheinfo.o \
> > +  devcon.o
> >  obj-$(CONFIG_DEVTMPFS) += devtmpfs.o
> >  obj-$(CONFIG_DMA_CMA) += dma-contiguous.o
> 

Re: [PATCH 2/3] usb: host: pci: introduce PCI vendor ID for Netlogic

[Greg KH]

On Wed, Mar 14, 2018 at 12:36:17PM +0100, Richard Leitner wrote:
> 
> On 03/14/2018 11:48 AM, Greg KH wrote:
> > On Wed, Mar 14, 2018 at 11:29:32AM +0100, Richard Leitner wrote:
> >> From: Richard Leitner 
> >>
> >> Replace the hardcoded PCI vendor ID of Netlogic with a definition in
> >> pci_ids.h
> > 
> > Why?  It's only being used in one file, so it should not be in
> > pci_ids.h, right?
> 
> It's also used as PCI_VENDOR_NETLOGIC in arch/mips/netlogic/xlp/.
> 
> Should this be replaced with PCI_VENDOR_ID_NETLOGIC from pci_ids.h?

Yes, if you are going to add it to pci_ids.h, it had better be used by
multiple files, otherwise it does not belong in 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

Re: [PATCH 2/3] usb: host: pci: introduce PCI vendor ID for Netlogic

[Richard Leitner]

On 03/14/2018 11:48 AM, Greg KH wrote:
> On Wed, Mar 14, 2018 at 11:29:32AM +0100, Richard Leitner wrote:
>> From: Richard Leitner 
>>
>> Replace the hardcoded PCI vendor ID of Netlogic with a definition in
>> pci_ids.h
> 
> Why?  It's only being used in one file, so it should not be in
> pci_ids.h, right?

It's also used as PCI_VENDOR_NETLOGIC in arch/mips/netlogic/xlp/.

Should this be replaced with PCI_VENDOR_ID_NETLOGIC from pci_ids.h?

> 
> thanks,
> 
> greg k-h
> 

thank you!

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

Re: [PATCH 3/3] usb: host: pci: replace hardcoded renesas PCI IDs

[Richard Leitner]

On 03/14/2018 11:49 AM, Greg KH wrote:
> On Wed, Mar 14, 2018 at 11:29:33AM +0100, Richard Leitner wrote:
>> From: Richard Leitner 
>>
>> Introduce Renesas uPD72020{1,2} PCI device IDs in pci_ids.h and replace
>> the harcoded values with them.
>>
>> Signed-off-by: Richard Leitner 
>> ---
>>  drivers/usb/host/pci-quirks.c | 6 --
>>  drivers/usb/host/xhci-pci.c   | 4 ++--
>>  include/linux/pci_ids.h   | 2 ++
>>  3 files changed, 8 insertions(+), 4 deletions(-)
>>

> Now this patch was fine :)
> 
> Care to redo this series?

Sure. Will send a v2 soon.

> 
> thanks,
> 
> greg k-h
> 

thank you!

regards;Richard.L
--
To unsubscribe from this list: send the line "unsubscribe 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: Debugging SCSI 'UNMAP' ("Logical Block Provisioning") failure on an SSD

[Oliver Neukum]

Am Mittwoch, den 14.03.2018, 11:22 +0100 schrieb Kashyap Chamarthy:
> I see.  So I ran `dmesg -w`, as I attached the disk & see the following:

UAS and no quirk for your device. It looks like it indeed just does
not support TRIM.

Sorry
Oliver

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

[GIT PULL] USB fixes for 4.16-rc6

[Greg KH]

The following changes since commit 4a3928c6f8a53fa1aed28ccba227742486e8ddcb:

  Linux 4.16-rc3 (2018-02-25 18:50:41 -0800)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/ 
tags/usb-4.16-rc6

for you to fetch changes up to 94e46a4f2d5eb14059e42f313c098d4854847376:

  usb: musb: Fix external abort in musb_remove on omap2430 (2018-03-13 16:36:59 
+0100)


USB fixes for 4.16-rc6

Here are a small clump of USB fixes for 4.16-rc6.

Nothing major, just a number of fixes in lots of different drivers, as
well as a PHY driver fix that snuck into this tree.  Full details are in
the shortlog.

All of these have been in linux-next with no reported issues.

Signed-off-by: Greg Kroah-Hartman 


Amelie Delaunay (2):
  dt-bindings: usb: fix the STM32F7 DWC2 OTG HS core binding
  usb: dwc2: fix STM32F7 USB OTG HS compatible

Arnd Bergmann (1):
  phy: qcom-ufs: add MODULE_LICENSE tag

Colin Ian King (1):
  usbip: vudc: fix null pointer dereference on udc->lock

Danilo Krummrich (1):
  usb: quirks: add control message delay for 1b1c:1b20

Fredrik Noring (1):
  USB: OHCI: Fix NULL dereference in HCDs using HCD_LOCAL_MEM

Greg Kroah-Hartman (2):
  Merge tag 'fixes-for-v4.16-rc4' of git://git.kernel.org/.../balbi/usb 
into usb-linus
  Merge tag 'phy-for-4.16-rc' of git://git.kernel.org/.../kishon/linux-phy 
into usb-linus

Hans de Goede (2):
  Revert "typec: tcpm: Only request matching pdos"
  usb: typec: tcpm: fusb302: Do not log an error on -EPROBE_DEFER

Kai-Heng Feng (1):
  xhci: Fix front USB ports on ASUS PRIME B350M-A

Lu Baolu (1):
  usb: xhci: dbc: Fix lockdep warning

Mathias Nyman (1):
  xhci: fix endpoint context tracer output

Merlijn Wajer (2):
  usb: musb: call pm_runtime_{get,put}_sync before reading vbus registers
  usb: musb: Fix external abort in musb_remove on omap2430

Oliver Neukum (1):
  uas: fix comparison for error code

Pete Zaitcev (1):
  usb: usbmon: Read text within supplied buffer size

Roger Quadros (1):
  usb: dwc3: Fix lock-up on ID change during system suspend/resume

Teijo Kinnunen (1):
  USB: storage: Add JMicron bridge 152d:2567 to unusual_devs.h

Xinyong (1):
  usb: gadget: f_fs: Fix use-after-free in ffs_fs_kill_sb()

Yoshihiro Shimoda (4):
  usb: renesas_usbhs: add binding for r8a77965
  usb: gadget: udc: renesas_usb3: add binging for r8a77965
  usb: host: xhci-rcar: add support for r8a77965
  usb: host: xhci-plat: revert "usb: host: xhci-plat: enable clk in resume 
timing"

 Documentation/devicetree/bindings/usb/dwc2.txt |   2 +-
 .../devicetree/bindings/usb/renesas_usb3.txt   |   1 +
 .../devicetree/bindings/usb/renesas_usbhs.txt  |   1 +
 Documentation/devicetree/bindings/usb/usb-xhci.txt |   1 +
 drivers/phy/qualcomm/phy-qcom-ufs.c|   5 +
 drivers/usb/core/message.c |   4 +
 drivers/usb/core/quirks.c  |   3 +-
 drivers/usb/dwc2/params.c  |   6 +-
 drivers/usb/dwc3/core.c|   2 +-
 drivers/usb/gadget/function/f_fs.c |   1 -
 drivers/usb/host/ohci-hcd.c|   3 +-
 drivers/usb/host/xhci-dbgcap.c |  20 ++-
 drivers/usb/host/xhci-dbgtty.c |  20 ++-
 drivers/usb/host/xhci-pci.c|   3 +
 drivers/usb/host/xhci-plat.c   |  11 +-
 drivers/usb/host/xhci-rcar.c   |   4 +
 drivers/usb/host/xhci.c|   3 +
 drivers/usb/host/xhci.h|  23 +--
 drivers/usb/mon/mon_text.c | 126 ++--
 drivers/usb/musb/musb_core.c   |   4 +-
 drivers/usb/storage/uas.c  |   2 +-
 drivers/usb/storage/unusual_devs.h |   7 +
 drivers/usb/typec/fusb302/fusb302.c|   3 +-
 drivers/usb/typec/tcpm.c   | 163 ++---
 drivers/usb/usbip/vudc_sysfs.c |   8 +-
 include/linux/usb/quirks.h |   3 +
 26 files changed, 211 insertions(+), 218 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v7 01/12] drivers: base: Unified device connection lookup

[Greg Kroah-Hartman]

On Mon, Mar 12, 2018 at 05:34:20PM +0300, Heikki Krogerus wrote:
> Several frameworks - clk, gpio, phy, pmw, etc. - maintain
> lookup tables for describing connections and provide custom
> API for handling them. This introduces a single generic
> lookup table and API for the connections.
> 
> The motivation for this commit is centralizing the
> connection lookup, but the goal is to ultimately extract the
> connection descriptions also from firmware by using the
> fwnode_graph_* functions and other mechanisms that are
> available.
> 
> Reviewed-by: Hans de Goede 
> Reviewed-by: Andy Shevchenko 
> Signed-off-by: Heikki Krogerus 
> ---
> Changes in v7:
> - API naming improvements suggested by Greg
> - Prototypes to device.h, also suggested by Greg
> - I removed the DEVCON() macro as it was not used yet and it needs to be
>   rewritten
> 
> Changes in v6:
> -Fix data and match arguments being swapped in __device_find_connection()
>  call in device_find_connection() (as noticed by Jun Li)
> 
> Changes in v5:
> -Add missing documentation for @list struct devcon member
> 
> Changes in v4:
> -Add Andy's Reviewed-by
> 
> Changes in v3:
> -Various spelling and gramar fixes in the docs pointed out by Randy Dunlap
> 
> Changes in v2:
> -Add a (struct devcon) cast to the DEVCON() macro
> ---
>  Documentation/driver-api/device_connection.rst |  43 
>  drivers/base/Makefile  |   3 +-
>  drivers/base/devcon.c  | 141 
> +
>  include/linux/device.h |  22 
>  4 files changed, 208 insertions(+), 1 deletion(-)
>  create mode 100644 Documentation/driver-api/device_connection.rst
>  create mode 100644 drivers/base/devcon.c
> 
> diff --git a/Documentation/driver-api/device_connection.rst 
> b/Documentation/driver-api/device_connection.rst
> new file mode 100644
> index ..affbc5566ab0
> --- /dev/null
> +++ b/Documentation/driver-api/device_connection.rst
> @@ -0,0 +1,43 @@
> +==
> +Device connections
> +==
> +
> +Introduction
> +
> +
> +Devices often have connections to other devices that are outside of the 
> direct
> +child/parent relationship. A serial or network communication controller, 
> which
> +could be a PCI device, may need to be able to get a reference to its PHY
> +component, which could be attached for example to the I2C bus. Some device
> +drivers need to be able to control the clocks or the GPIOs for their devices,
> +and so on.
> +
> +Device connections are generic descriptions of any type of connection between
> +two separate devices.
> +
> +Device connections alone do not create a dependency between the two devices.
> +They are only descriptions which are not tied to either of the devices 
> directly.
> +A dependency between the two devices exists only if one of the two endpoint
> +devices requests a reference to the other. The descriptions themselves can be
> +defined in firmware (not yet supported) or they can be built-in.
> +
> +Usage
> +-
> +
> +Device connections should exist before device ``->probe`` callback is called 
> for
> +either endpoint device in the description. If the connections are defined in
> +firmware, this is not a problem. It should be considered if the connection
> +descriptions are "built-in", and need to be added separately.
> +
> +The connection description consists of the names of the two devices with the
> +connection, i.e. the endpoints, and unique identifier for the connection 
> which
> +is needed if there are multiple connections between the two devices.
> +
> +After a description exists, the devices in it can request reference to the 
> other
> +endpoint device, or they can request the description itself.
> +
> +API
> +---
> +
> +.. kernel-doc:: drivers/base/devcon.c
> +   : functions: device_connection_find_match device_connection_find 
> device_connection_add device_connection_remove
> diff --git a/drivers/base/Makefile b/drivers/base/Makefile
> index e32a52490051..12a7f64d35a9 100644
> --- a/drivers/base/Makefile
> +++ b/drivers/base/Makefile
> @@ -5,7 +5,8 @@ obj-y := component.o core.o bus.o dd.o 
> syscore.o \
>  driver.o class.o platform.o \
>  cpu.o firmware.o init.o map.o devres.o \
>  attribute_container.o transport_class.o \
> -topology.o container.o property.o cacheinfo.o
> +topology.o container.o property.o cacheinfo.o \
> +devcon.o
>  obj-$(CONFIG_DEVTMPFS)   += devtmpfs.o
>  obj-$(CONFIG_DMA_CMA) += dma-contiguous.o
>  obj-y+= power/
> diff --git a/drivers/base/devcon.c b/drivers/base/devcon.c
> new file mode 100644
> index ..e783c2c2ed1a
> --- /dev/null
> +++ b/drivers/base/devcon.c
> @@ -0,0 +1,141 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/**
> + * Device connections
> + *
> + * Copyright (C) 2018

Re: [PATCH 2/3] usb: host: pci: introduce PCI vendor ID for Netlogic

[Greg KH]

On Wed, Mar 14, 2018 at 11:29:32AM +0100, Richard Leitner wrote:
> From: Richard Leitner 
> 
> Replace the hardcoded PCI vendor ID of Netlogic with a definition in
> pci_ids.h

Why?  It's only being used in one file, so it should not be in
pci_ids.h, right?

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 3/3] usb: host: pci: replace hardcoded renesas PCI IDs

[Greg KH]

On Wed, Mar 14, 2018 at 11:29:33AM +0100, Richard Leitner wrote:
> From: Richard Leitner 
> 
> Introduce Renesas uPD72020{1,2} PCI device IDs in pci_ids.h and replace
> the harcoded values with them.
> 
> Signed-off-by: Richard Leitner 
> ---
>  drivers/usb/host/pci-quirks.c | 6 --
>  drivers/usb/host/xhci-pci.c   | 4 ++--
>  include/linux/pci_ids.h   | 2 ++
>  3 files changed, 8 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/usb/host/pci-quirks.c b/drivers/usb/host/pci-quirks.c
> index 39d163729b89..5e1ad523622e 100644
> --- a/drivers/usb/host/pci-quirks.c
> +++ b/drivers/usb/host/pci-quirks.c
> @@ -1170,7 +1170,8 @@ static void quirk_usb_handoff_xhci(struct pci_dev *pdev)
>   /* Auto handoff never worked for these devices. Force it and continue */
>   if ((pdev->vendor == PCI_VENDOR_ID_TI &&
>pdev->device == PCI_DEVICE_ID_TI_TUSB73X0) ||
> - (pdev->vendor == PCI_VENDOR_ID_RENESAS && pdev->device == 0x0014)) {
> + (pdev->vendor == PCI_VENDOR_ID_RENESAS &&
> +  pdev->device == PCI_DEVICE_ID_RENESAS_UPD720201)) {
>   val = (val | XHCI_HC_OS_OWNED) & ~XHCI_HC_BIOS_OWNED;
>   writel(val, base + ext_cap_offset);
>   }
> @@ -1282,7 +1283,8 @@ bool usb_xhci_needs_pci_reset(struct pci_dev *pdev)
>* quirk, or the system will be in a rather bad state.
>*/
>   if (pdev->vendor == PCI_VENDOR_ID_RENESAS &&
> - (pdev->device == 0x0014 || pdev->device == 0x0015))
> + (pdev->device == PCI_DEVICE_ID_RENESAS_UPD720201 ||
> +  pdev->device == PCI_DEVICE_ID_RENESAS_UPD720202))
>   return true;
>  
>   return false;
> diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
> index a5bfd890190c..a453e4c35ac7 100644
> --- a/drivers/usb/host/xhci-pci.c
> +++ b/drivers/usb/host/xhci-pci.c
> @@ -189,10 +189,10 @@ static void xhci_pci_quirks(struct device *dev, struct 
> xhci_hcd *xhci)
>   xhci->quirks |= XHCI_BROKEN_STREAMS;
>   }
>   if (pdev->vendor == PCI_VENDOR_ID_RENESAS &&
> - pdev->device == 0x0014)
> + pdev->device == PCI_DEVICE_ID_RENESAS_UPD720201)
>   xhci->quirks |= XHCI_TRUST_TX_LENGTH;
>   if (pdev->vendor == PCI_VENDOR_ID_RENESAS &&
> - pdev->device == 0x0015)
> + pdev->device == PCI_DEVICE_ID_RENESAS_UPD720202)
>   xhci->quirks |= XHCI_RESET_ON_RESUME;
>   if (pdev->vendor == PCI_VENDOR_ID_VIA)
>   xhci->quirks |= XHCI_RESET_ON_RESUME;
> diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
> index d23a97868dee..eb52f0e9b651 100644
> --- a/include/linux/pci_ids.h
> +++ b/include/linux/pci_ids.h
> @@ -2427,6 +2427,8 @@
>  #define PCI_DEVICE_ID_RENESAS_SH7763 0x0004
>  #define PCI_DEVICE_ID_RENESAS_SH7785 0x0007
>  #define PCI_DEVICE_ID_RENESAS_SH7786 0x0010
> +#define PCI_DEVICE_ID_RENESAS_UPD720201  0x0014
> +#define PCI_DEVICE_ID_RENESAS_UPD720202  0x0015

Now this patch was fine :)

Care to redo this series?

thanks,

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

Re: [PATCH 1/3] usb: host: pci: use existing Intel PCI ID macros

[Greg KH]

On Wed, Mar 14, 2018 at 11:29:31AM +0100, Richard Leitner wrote:
> From: Richard Leitner 
> 
> Instead of the hardcoded hexadecimal PCI IDs use the existing macros
> from pci_ids.h for Intel IDs.


You also did something else in this patch, yet failed to mention it
here:

> Signed-off-by: Richard Leitner 
> ---
>  drivers/usb/host/pci-quirks.c | 10 +-
>  drivers/usb/host/xhci-pci.c   |  3 ++-
>  include/linux/pci_ids.h   |  1 +
>  3 files changed, 8 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/usb/host/pci-quirks.c b/drivers/usb/host/pci-quirks.c
> index 67ad4bb6919a..4f4a9f36a68e 100644
> --- a/drivers/usb/host/pci-quirks.c
> +++ b/drivers/usb/host/pci-quirks.c
> @@ -858,8 +858,8 @@ static void ehci_bios_handoff(struct pci_dev *pdev,
>*
>* The HASEE E200 hangs when the semaphore is set (bugzilla #77021).
>*/
> - if (pdev->vendor == 0x8086 && (pdev->device == 0x283a ||
> - pdev->device == 0x27cc)) {
> + if (pdev->vendor == PCI_VENDOR_ID_INTEL &&
> + (pdev->device == 0x283a || pdev->device == 0x27cc)) {
>   if (dmi_check_system(ehci_dmi_nohandoff_table))
>   try_handoff = 0;
>   }
> @@ -1168,9 +1168,9 @@ static void quirk_usb_handoff_xhci(struct pci_dev *pdev)
>   val = readl(base + ext_cap_offset);
>  
>   /* Auto handoff never worked for these devices. Force it and continue */
> - if ((pdev->vendor == PCI_VENDOR_ID_TI && pdev->device == 0x8241) ||
> - (pdev->vendor == PCI_VENDOR_ID_RENESAS
> -  && pdev->device == 0x0014)) {
> + if ((pdev->vendor == PCI_VENDOR_ID_TI &&
> +  pdev->device == PCI_DEVICE_ID_TI_TUSB73X0) ||
> + (pdev->vendor == PCI_VENDOR_ID_RENESAS && pdev->device == 0x0014)) {
>   val = (val | XHCI_HC_OS_OWNED) & ~XHCI_HC_BIOS_OWNED;
>   writel(val, base + ext_cap_offset);
>   }
> diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
> index 5262fa571a5d..a5bfd890190c 100644
> --- a/drivers/usb/host/xhci-pci.c
> +++ b/drivers/usb/host/xhci-pci.c
> @@ -213,7 +213,8 @@ static void xhci_pci_quirks(struct device *dev, struct 
> xhci_hcd *xhci)
>   pdev->device == PCI_DEVICE_ID_ASMEDIA_1042A_XHCI)
>   xhci->quirks |= XHCI_ASMEDIA_MODIFY_FLOWCONTROL;
>  
> - if (pdev->vendor == PCI_VENDOR_ID_TI && pdev->device == 0x8241)
> + if (pdev->vendor == PCI_VENDOR_ID_TI &&
> + pdev->device == PCI_DEVICE_ID_TI_TUSB73X0)
>   xhci->quirks |= XHCI_LIMIT_ENDPOINT_INTERVAL_7;
>  
>   if (xhci->quirks & XHCI_RESET_ON_RESUME)
> diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
> index a6b30667a331..e8d1af82a688 100644
> --- a/include/linux/pci_ids.h
> +++ b/include/linux/pci_ids.h
> @@ -838,6 +838,7 @@
>  #define PCI_DEVICE_ID_TI_XX120x8039
>  #define PCI_DEVICE_ID_TI_XX12_FM 0x803b
>  #define PCI_DEVICE_ID_TI_XIO2000A0x8231
> +#define PCI_DEVICE_ID_TI_TUSB73X00x8241

You shared a TI device id.

Please break this up into 2 patches.

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 v1 2/2] usb: dwc3: Add Qualcomm DWC3 glue driver

[kbuild test robot]

Hi Manu,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on v4.16-rc4]
[also build test ERROR on next-20180314]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Manu-Gautam/dt-bindings-usb-Update-documentation-for-Qualcomm-DWC3-driver/20180314-095557
config: x86_64-allmodconfig (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

>> ERROR: "__tracepoint_dwc3_writel" [drivers/usb/dwc3/dwc3-qcom.ko] undefined!
>> ERROR: "__tracepoint_dwc3_readl" [drivers/usb/dwc3/dwc3-qcom.ko] undefined!

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


.config.gz
Description: application/gzip

Re: [RFC PATCH] usb: typec: tcpm: match source fixed pdo with sink variable pdo

[Hans de Goede]

Hi,

On 14-03-18 10:32, Jun Li wrote:

Hi

-Original Message-
From: Hans de Goede [mailto:hdego...@redhat.com]
Sent: 2018年3月13日 19:36
To: Jun Li ; gre...@linuxfoundation.org; li...@roeck-us.net;
heikki.kroge...@linux.intel.com; adam.thomson.opensou...@diasemi.com;
bad...@google.com
Cc: linux-usb@vger.kernel.org; dl-linux-imx 
Subject: Re: [RFC PATCH] usb: typec: tcpm: match source fixed pdo with sink
variable pdo

Hi,

On 13-03-18 01:02, Li Jun wrote:

This patch tries to fix the problem describled on revert patch
commit[1], suppose any supported voltage ranges of sink should be
describled by variable pdo, so instead of revert the patch of only
comparing source and sink pdo to select one source pdo, this patch
adds the match between source fixed pdo and sink variable pdo.

[1]


https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww

.spinics.net%2Flists%2Flinux-usb%2Fmsg166366.html&data=02%7C01%7Cju

n.l



i%40nxp.com%7C569be5e2496442f514bd08d588d69fc6%7C686ea1d3bc2b4
c6fa92cd



99c5c301635%7C0%7C0%7C636565377744465803&sdata=hUPib1nNtXArpZ
Pn0TfMdui

ARnVPvc6CezTr0UxJFCI%3D&reserved=0

CC: Hans de Goede 
CC: Guenter Roeck 
CC: Heikki Krogerus 
CC: Adam Thomson 
CC: Badhri Jagan Sridharan 
Signed-off-by: Li Jun 
---
   drivers/usb/typec/tcpm.c | 31 +++
   1 file changed, 31 insertions(+)

diff --git a/drivers/usb/typec/tcpm.c b/drivers/usb/typec/tcpm.c index
ef3a60d..8a74a43 100644
--- a/drivers/usb/typec/tcpm.c
+++ b/drivers/usb/typec/tcpm.c
@@ -1815,6 +1815,37 @@ static int tcpm_pd_select_pdo(struct tcpm_port

*port, int *sink_pdo,

break;
}
}
+
+   /*
+* If the source pdo has the same voltage with one
+* fixed pdo, no need check variable pdo for it.
+*/
+   if (j < port->nr_fixed)
+   continue;
+
+   for (j = port->nr_fixed +
+port->nr_batt;
+j < port->nr_fixed +
+port->nr_batt +
+port->nr_var;
+j++) {
+   if (pdo_fixed_voltage(pdo) >=
+pdo_min_voltage(port->snk_pdo[j]) &&
+pdo_fixed_voltage(pdo) <=
+pdo_max_voltage(port->snk_pdo[j])) {
+   ma = min_current(pdo, port->snk_pdo[j]);
+   mv = pdo_fixed_voltage(pdo);
+   mw = ma * mv / 1000;
+   if (mw > max_mw ||
+   (mw == max_mw && mv > max_mv)) {
+   ret = 0;
+   *src_pdo = i;
+   *sink_pdo = j;
+   max_mw = mw;
+   max_mv = mv;
+   }
+   }
+   }
} else if (type == PDO_TYPE_BATT) {
for (j = port->nr_fixed;
 j < port->nr_fixed +



First of all, this seems to be a fix on top of your previous, reverted patch.



It's on top of the patch to be reverted by you.
  

Since your patch has been reverted, please send a new fixed patch replacing it.



It's Badhri's patch, not mine.

Author: Badhri Jagan Sridharan 
Date:   Wed Nov 15 17:01:56 2017 -0800

 typec: tcpm: Only request matching pdos


As for the proposed fix, you are just fixing the fixed source, variable snk cap
case here. What if things are the other way around, so fixed snk, variable
source?


I think that may not work, as the sink defines itself only can work at one
fixed voltage, a variable PDO can make sure the output voltage fixed?

Below is the description of variable supply PDO from PD spec:
"The Variable Supply (non-Battery) PDO exposes very poorly regulated Sources.
The output voltage of a Variable Supply (non-Battery) shall remain within the
absolute maximum output voltage and the absolute minimum output voltage
exposed in the Variable Supply PDO"

So I think a basic rule is the voltage range of selected source PDO should be
within the voltage range of sink PDO, no matter what type they are:
(max_src_mv <= max_snk_mv && min_src_mv >= min_snk_mv)


Yes you are right, I did not realize that a variable source PDO meant that
the voltage is not stable.

I expected that to mean that the sink could pick a voltage and the source would
then regulate at that voltage, but clearly I was wrong.


With this condition meet, then we can select one source PDO with bigge

Re: [PATCH 0/2] USB 3.2 initial support

[Oliver Neukum]

Am Dienstag, den 13.03.2018, 19:22 +0200 schrieb Mathias Nyman:

> My understanding is that Gen XxY notion is only used for symmetric devices
> where tx lanes = rx lanes. Only SSIC devices can be asymmetric.
> 
> USB 3.2 spec mentions the (Gen 1x1, 1x2, 2x1 and 2x2) alternatives, nothing 
> more.
> Nothing about different lane counts on rx and tx related to Gen XxY.

Hi,

normally I would say that we should worry about this only when we need
to, but an API in sysfs is an exception to that rule. We can avoid
pain later if we export lane counts for both directions now
in all cases.

We should also export all raw data we have. User space can be trusted
to get a multiplication right and it is not the kernels job
to interpret such data.

Regards
Oliver

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

[PATCH 1/3] usb: host: pci: use existing Intel PCI ID macros

[Richard Leitner]

From: Richard Leitner 

Instead of the hardcoded hexadecimal PCI IDs use the existing macros
from pci_ids.h for Intel IDs.

Signed-off-by: Richard Leitner 
---
 drivers/usb/host/pci-quirks.c | 10 +-
 drivers/usb/host/xhci-pci.c   |  3 ++-
 include/linux/pci_ids.h   |  1 +
 3 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/usb/host/pci-quirks.c b/drivers/usb/host/pci-quirks.c
index 67ad4bb6919a..4f4a9f36a68e 100644
--- a/drivers/usb/host/pci-quirks.c
+++ b/drivers/usb/host/pci-quirks.c
@@ -858,8 +858,8 @@ static void ehci_bios_handoff(struct pci_dev *pdev,
 *
 * The HASEE E200 hangs when the semaphore is set (bugzilla #77021).
 */
-   if (pdev->vendor == 0x8086 && (pdev->device == 0x283a ||
-   pdev->device == 0x27cc)) {
+   if (pdev->vendor == PCI_VENDOR_ID_INTEL &&
+   (pdev->device == 0x283a || pdev->device == 0x27cc)) {
if (dmi_check_system(ehci_dmi_nohandoff_table))
try_handoff = 0;
}
@@ -1168,9 +1168,9 @@ static void quirk_usb_handoff_xhci(struct pci_dev *pdev)
val = readl(base + ext_cap_offset);
 
/* Auto handoff never worked for these devices. Force it and continue */
-   if ((pdev->vendor == PCI_VENDOR_ID_TI && pdev->device == 0x8241) ||
-   (pdev->vendor == PCI_VENDOR_ID_RENESAS
-&& pdev->device == 0x0014)) {
+   if ((pdev->vendor == PCI_VENDOR_ID_TI &&
+pdev->device == PCI_DEVICE_ID_TI_TUSB73X0) ||
+   (pdev->vendor == PCI_VENDOR_ID_RENESAS && pdev->device == 0x0014)) {
val = (val | XHCI_HC_OS_OWNED) & ~XHCI_HC_BIOS_OWNED;
writel(val, base + ext_cap_offset);
}
diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
index 5262fa571a5d..a5bfd890190c 100644
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -213,7 +213,8 @@ static void xhci_pci_quirks(struct device *dev, struct 
xhci_hcd *xhci)
pdev->device == PCI_DEVICE_ID_ASMEDIA_1042A_XHCI)
xhci->quirks |= XHCI_ASMEDIA_MODIFY_FLOWCONTROL;
 
-   if (pdev->vendor == PCI_VENDOR_ID_TI && pdev->device == 0x8241)
+   if (pdev->vendor == PCI_VENDOR_ID_TI &&
+   pdev->device == PCI_DEVICE_ID_TI_TUSB73X0)
xhci->quirks |= XHCI_LIMIT_ENDPOINT_INTERVAL_7;
 
if (xhci->quirks & XHCI_RESET_ON_RESUME)
diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
index a6b30667a331..e8d1af82a688 100644
--- a/include/linux/pci_ids.h
+++ b/include/linux/pci_ids.h
@@ -838,6 +838,7 @@
 #define PCI_DEVICE_ID_TI_XX12  0x8039
 #define PCI_DEVICE_ID_TI_XX12_FM   0x803b
 #define PCI_DEVICE_ID_TI_XIO2000A  0x8231
+#define PCI_DEVICE_ID_TI_TUSB73X0  0x8241
 #define PCI_DEVICE_ID_TI_1130  0xac12
 #define PCI_DEVICE_ID_TI_1031  0xac13
 #define PCI_DEVICE_ID_TI_1131  0xac15
-- 
2.11.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 2/3] usb: host: pci: introduce PCI vendor ID for Netlogic

[Richard Leitner]

From: Richard Leitner 

Replace the hardcoded PCI vendor ID of Netlogic with a definition in
pci_ids.h

Signed-off-by: Richard Leitner 
---
 drivers/usb/host/pci-quirks.c | 2 +-
 include/linux/pci_ids.h   | 2 ++
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/host/pci-quirks.c b/drivers/usb/host/pci-quirks.c
index 4f4a9f36a68e..39d163729b89 100644
--- a/drivers/usb/host/pci-quirks.c
+++ b/drivers/usb/host/pci-quirks.c
@@ -1243,7 +1243,7 @@ static void quirk_usb_early_handoff(struct pci_dev *pdev)
/* Skip Netlogic mips SoC's internal PCI USB controller.
 * This device does not need/support EHCI/OHCI handoff
 */
-   if (pdev->vendor == 0x184e) /* vendor Netlogic */
+   if (pdev->vendor == PCI_VENDOR_ID_NETLOGIC)
return;
if (pdev->class != PCI_CLASS_SERIAL_USB_UHCI &&
pdev->class != PCI_CLASS_SERIAL_USB_OHCI &&
diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
index e8d1af82a688..d23a97868dee 100644
--- a/include/linux/pci_ids.h
+++ b/include/linux/pci_ids.h
@@ -3067,4 +3067,6 @@
 
 #define PCI_VENDOR_ID_OCZ  0x1b85
 
+#define PCI_VENDOR_ID_NETLOGIC 0x184e
+
 #endif /* _LINUX_PCI_IDS_H */
-- 
2.11.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: pci: replace hardcoded renesas PCI IDs

[Richard Leitner]

From: Richard Leitner 

Introduce Renesas uPD72020{1,2} PCI device IDs in pci_ids.h and replace
the harcoded values with them.

Signed-off-by: Richard Leitner 
---
 drivers/usb/host/pci-quirks.c | 6 --
 drivers/usb/host/xhci-pci.c   | 4 ++--
 include/linux/pci_ids.h   | 2 ++
 3 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/host/pci-quirks.c b/drivers/usb/host/pci-quirks.c
index 39d163729b89..5e1ad523622e 100644
--- a/drivers/usb/host/pci-quirks.c
+++ b/drivers/usb/host/pci-quirks.c
@@ -1170,7 +1170,8 @@ static void quirk_usb_handoff_xhci(struct pci_dev *pdev)
/* Auto handoff never worked for these devices. Force it and continue */
if ((pdev->vendor == PCI_VENDOR_ID_TI &&
 pdev->device == PCI_DEVICE_ID_TI_TUSB73X0) ||
-   (pdev->vendor == PCI_VENDOR_ID_RENESAS && pdev->device == 0x0014)) {
+   (pdev->vendor == PCI_VENDOR_ID_RENESAS &&
+pdev->device == PCI_DEVICE_ID_RENESAS_UPD720201)) {
val = (val | XHCI_HC_OS_OWNED) & ~XHCI_HC_BIOS_OWNED;
writel(val, base + ext_cap_offset);
}
@@ -1282,7 +1283,8 @@ bool usb_xhci_needs_pci_reset(struct pci_dev *pdev)
 * quirk, or the system will be in a rather bad state.
 */
if (pdev->vendor == PCI_VENDOR_ID_RENESAS &&
-   (pdev->device == 0x0014 || pdev->device == 0x0015))
+   (pdev->device == PCI_DEVICE_ID_RENESAS_UPD720201 ||
+pdev->device == PCI_DEVICE_ID_RENESAS_UPD720202))
return true;
 
return false;
diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
index a5bfd890190c..a453e4c35ac7 100644
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -189,10 +189,10 @@ static void xhci_pci_quirks(struct device *dev, struct 
xhci_hcd *xhci)
xhci->quirks |= XHCI_BROKEN_STREAMS;
}
if (pdev->vendor == PCI_VENDOR_ID_RENESAS &&
-   pdev->device == 0x0014)
+   pdev->device == PCI_DEVICE_ID_RENESAS_UPD720201)
xhci->quirks |= XHCI_TRUST_TX_LENGTH;
if (pdev->vendor == PCI_VENDOR_ID_RENESAS &&
-   pdev->device == 0x0015)
+   pdev->device == PCI_DEVICE_ID_RENESAS_UPD720202)
xhci->quirks |= XHCI_RESET_ON_RESUME;
if (pdev->vendor == PCI_VENDOR_ID_VIA)
xhci->quirks |= XHCI_RESET_ON_RESUME;
diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
index d23a97868dee..eb52f0e9b651 100644
--- a/include/linux/pci_ids.h
+++ b/include/linux/pci_ids.h
@@ -2427,6 +2427,8 @@
 #define PCI_DEVICE_ID_RENESAS_SH7763   0x0004
 #define PCI_DEVICE_ID_RENESAS_SH7785   0x0007
 #define PCI_DEVICE_ID_RENESAS_SH7786   0x0010
+#define PCI_DEVICE_ID_RENESAS_UPD7202010x0014
+#define PCI_DEVICE_ID_RENESAS_UPD7202020x0015
 
 #define PCI_VENDOR_ID_SOLARFLARE   0x1924
 #define PCI_DEVICE_ID_SOLARFLARE_SFC4000A_00x0703
-- 
2.11.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 0/3] usb: host: pci: PCI ID consolidation

[Richard Leitner]

From: Richard Leitner 

Centralize some hardcoded PCI IDs as definitions in the global
include/linux/pci_ids.h file. This is done to reduce the amount of
scattered PCI ID definitions and hardcoded values across the kernel.

Richard Leitner (3):
  usb: host: pci: use existing Intel PCI ID macros
  usb: host: pci: introduce PCI vendor ID for Netlogic
  usb: host: pci: replace hardcoded renesas PCI IDs

 drivers/usb/host/pci-quirks.c | 16 +---
 drivers/usb/host/xhci-pci.c   |  7 ---
 include/linux/pci_ids.h   |  5 +
 3 files changed, 18 insertions(+), 10 deletions(-)

-- 
2.11.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: Debugging SCSI 'UNMAP' ("Logical Block Provisioning") failure on an SSD

[Kashyap Chamarthy]

On Wed, Mar 14, 2018 at 10:52:36AM +0100, Oliver Neukum wrote:
> Am Dienstag, den 13.03.2018, 12:50 +0100 schrieb Kashyap Chamarthy:
> > Earlier, I didn't know which list to email, so I wrote to Martin K.
> > Petersen (who pointed me to the lists when I asked where I can post
> > publicly), and he made this observation on the above quoted text:
> > 
> >     "Linux can run USB block devices in either legacy or UAS mode.
> >     Chances are this device is being driven in usb-storage mode. We
> >     usually have quirks based on the model strings that decide whether
> >     to use one or the other."
> 
> Neither driver would edit commands or result to that degree.
> Whether UAS or storage are used dmesg will tell you.

I see.  So I ran `dmesg -w`, as I attached the disk & see the following:

---
[...]
[474027.606253] sd 3:0:0:0: Attached scsi generic sg1 type 0
[474027.607751] sd 3:0:0:0: [sdb] 976773168 512-byte logical blocks: (500 
GB/466 GiB)
[474027.607857] sd 3:0:0:0: [sdb] Write Protect is off
[474027.607858] sd 3:0:0:0: [sdb] Mode Sense: 43 00 00 00
[474027.608019] sd 3:0:0:0: [sdb] Write cache: enabled, read cache: enabled, 
doesn't support DPO or FUA
[474027.612347] sd 3:0:0:0: [sdb] Attached SCSI disk
[474027.863216] EXT4-fs (sdb): recovery complete
[474027.866955] EXT4-fs (sdb): mounted filesystem with ordered data mode. Opts: 
(null)
[474038.146095] usb 3-1: USB disconnect, device number 4
[474038.147543] print_req_error: I/O error, dev sdb, sector 0
[474038.155354] sd 3:0:0:0: [sdb] Synchronizing SCSI cache
[474038.175128] print_req_error: I/O error, dev sdb, sector 0
[474038.179130] print_req_error: I/O error, dev sdb, sector 0
[474038.183135] print_req_error: I/O error, dev sdb, sector 0
[474038.183156] print_req_error: I/O error, dev sdb, sector 0
[474038.267134] sd 3:0:0:0: [sdb] Synchronize Cache(10) failed: Result: 
hostbyte=DID_ERROR driverbyte=DRIVER_OK
[474076.230377] usb 3-1: new SuperSpeed USB device number 5 using xhci_hcd
[474076.248589] usb 3-1: New USB device found, idVendor=04e8, idProduct=61f5
[474076.248593] usb 3-1: New USB device strings: Mfr=2, Product=3, 
SerialNumber=1
[474076.248596] usb 3-1: Product: Portable SSD T5
[474076.248598] usb 3-1: Manufacturer: Samsung
[474076.248600] usb 3-1: SerialNumber: 1234567A7AD6
[474076.254990] scsi host3: uas
[474076.255605] scsi 3:0:0:0: Direct-Access Samsung  Portable SSD T5  0
PQ: 0 ANSI: 6
[474076.263707] sd 3:0:0:0: Attached scsi generic sg1 type 0
[474076.264140] sd 3:0:0:0: [sdb] 976773168 512-byte logical blocks: (500 
GB/466 GiB)
[474076.264220] sd 3:0:0:0: [sdb] Write Protect is off
[474076.264222] sd 3:0:0:0: [sdb] Mode Sense: 43 00 00 00
[474076.264546] sd 3:0:0:0: [sdb] Write cache: enabled, read cache: enabled, 
doesn't support DPO or FUA
[474076.267595] sd 3:0:0:0: [sdb] Attached SCSI disk
[474076.463067] EXT4-fs (sdb): recovery complete
[474076.463070] EXT4-fs (sdb): mounted filesystem with ordered data mode. Opts: 
(null)
---

-- 
/kashyap
--
To unsubscribe from this list: send the line "unsubscribe 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: Fix interval type issue

[Minas Harutyunyan]

On 2/6/2018 7:07 PM, Grigor Tovmasyan wrote:
> The maximum value that unsigned char can hold is 255, meanwhile
> the maximum value of interval is  2^(bIntervalMax-1)=2^15.
> 
> Signed-off-by: Grigor Tovmasyan 
> ---
>   drivers/usb/dwc2/core.h | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
> index 0f0c21cf0192..51c3d5170b3b 100644
> --- a/drivers/usb/dwc2/core.h
> +++ b/drivers/usb/dwc2/core.h
> @@ -217,7 +217,7 @@ struct dwc2_hsotg_ep {
>   unsigned char   dir_in;
>   unsigned char   index;
>   unsigned char   mc;
> - unsigned char   interval;
> + u16 interval;
>   
>   unsigned inthalted:1;
>   unsigned intperiodic:1;
> 

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

Re: [PATCH v3 04/12] usb: typec: add API to get typec basic port power and data config

[Heikki Krogerus]

Hi,

On Tue, Mar 13, 2018 at 05:34:30PM +0800, Li Jun wrote:
> +/**
> + * typec_get_power_type - Get the typec port power type
> + * @fwnode: Firmware node to get the property of
> + *
> + * This routine is used by typec hardware driver to read property
> + * port power type from the device firmware description.
> + *
> + * Returns typec_port_type if success, otherwise negative error code.
> + */
> +int typec_get_power_type(struct fwnode_handle *fwnode)
> +{
> + const char *type_str;
> + int ret;
> +
> + if (!fwnode)
> + return -EINVAL;
> +
> + ret = fwnode_property_read_string(fwnode, "power-type", &type_str);
> + if (ret < 0)
> + return ret;
> +
> + return match_string(typec_port_types, ARRAY_SIZE(typec_port_types),
> + type_str);
> +}
> +EXPORT_SYMBOL_GPL(typec_get_power_type);
> 
> +/**
> + * typec_get_preferred_role - Get the typec preferred power role
> + * @fwnode: Firmware node to get the property of
> + *
> + * This routine is used by typec hardware driver to read property
> + * try-power-role from the device firmware description to decide
> + * if the port can support Try.SRC or Try.SNK.
> + *
> + * Returns typec_role if success, otherwise negative error code.
> + */
> +int typec_get_preferred_role(struct fwnode_handle *fwnode)
> +{
> + const char *type_str;
> + int ret;
> +
> + if (!fwnode)
> + return -EINVAL;
> +
> + ret = fwnode_property_read_string(fwnode, "try-power-role", &type_str);
> + if (ret < 0)
> + return ret;
> +
> + return match_string(typec_roles, ARRAY_SIZE(typec_roles), type_str);
> +}
> +EXPORT_SYMBOL_GPL(typec_get_preferred_role);
> +
> +/**
> + * typec_get_data_type - Get the typec port data type
> + * @fwnode: Firmware node to get the property of
> + *
> + * This routine is used by typec hardware driver to read property
> + * port data type from the device firmware description.
> + *
> + * Returns typec_data_type if success, otherwise negative error code.
> + */
> +int typec_get_data_type(struct fwnode_handle *fwnode)
> +{
> + const char *type_str;
> + int ret;
> +
> + if (!fwnode)
> + return -EINVAL;
> +
> + ret = fwnode_property_read_string(fwnode, "data-type", &type_str);
> + if (ret < 0)
> + return ret;
> +
> + return match_string(typec_data_types, ARRAY_SIZE(typec_data_types),
> + type_str);
> +}
> +EXPORT_SYMBOL_GPL(typec_get_data_type);

I been thinking about this. Perhaps it's better that we don't read
any properties in these helpers. These helpers become more useful that
way, and we can use the in other places as well if needed.

So my proposal is that the callers of these functions are responsible
of reading the property values. Here we just convert the strings to
values:

int typec_find_preferred_role(const char *name)
{
return match_string(typec_roles, ARRAY_SIZE(typec_roles), name);
}
EXPORT_SYMBOL_GPL(typec_find_preferred_role);

int typec_find_power_role(const char *name)
{
return match_string(typec_port_types, ARRAY_SIZE(typec_data_types),
name);
}
EXPORT_SYMBOL_GPL(typec_find_data_role);

int typec_find_data_role(const char *name)
{
return match_string(typec_data_types, ARRAY_SIZE(typec_data_types),
name);
}
EXPORT_SYMBOL_GPL(typec_find_data_role);


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: Debugging SCSI 'UNMAP' ("Logical Block Provisioning") failure on an SSD

[Oliver Neukum]

Am Dienstag, den 13.03.2018, 12:50 +0100 schrieb Kashyap Chamarthy:
> Earlier, I didn't know which list to email, so I wrote to Martin K.
> Petersen (who pointed me to the lists when I asked where I can post
> publicly), and he made this observation on the above quoted text:
> 
>     "Linux can run USB block devices in either legacy or UAS mode.
>     Chances are this device is being driven in usb-storage mode. We
>     usually have quirks based on the model strings that decide whether
>     to use one or the other."

Neither driver would edit commands or result to that degree.
Whether UAS or storage are used dmesg will tell you.

Regards
Oliver

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

Re: 4.14.13: Kernel panic, NULL pointer dereference in xhci_hcd

[Oliver Neukum]

Am Dienstag, den 13.03.2018, 17:53 +0200 schrieb Juho Tykkälä :
> This is originally raised as Debian bug but the more I investigate
> it seems to trace back to 4.14.x xhci.

Hi,

does vanilla 4.14.0 work? Could you bisect?

Regards
Oliver

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

[PATCH v3] usb: core: introduce per-port over-current counters

[Richard Leitner]

From: Richard Leitner 

For some userspace applications information on the number of
over-current conditions at specific USB hub ports is relevant.

In our case we have a series of USB hardware (using the cp210x driver)
which communicates using a proprietary protocol. These devices sometimes
trigger an over-current situation on some hubs. In case of such an
over-current situation the USB devices offer an interface for reducing
the max used power. As these conditions are quite rare and imply
performance reductions of the device we don't want to reduce the max
power always.

Therefore give user-space applications the possibility to react
adequately by introducing an over_current_counter in the usb port struct
which is exported via sysfs.

Signed-off-by: Richard Leitner 
---
 Documentation/ABI/testing/sysfs-bus-usb | 10 ++
 drivers/usb/core/hub.c  |  4 +++-
 drivers/usb/core/hub.h  |  1 +
 drivers/usb/core/port.c | 10 ++
 4 files changed, 24 insertions(+), 1 deletion(-)

diff --git a/Documentation/ABI/testing/sysfs-bus-usb 
b/Documentation/ABI/testing/sysfs-bus-usb
index 0bd731cbb50c..c702c78f24d8 100644
--- a/Documentation/ABI/testing/sysfs-bus-usb
+++ b/Documentation/ABI/testing/sysfs-bus-usb
@@ -189,6 +189,16 @@ Description:
The file will read "hotplug", "wired" and "not used" if the
information is available, and "unknown" otherwise.
 
+What:  /sys/bus/usb/devices/.../(hub 
interface)/portX/over_current_count
+Date:  February 2018
+Contact:   Richard Leitner 
+Description:
+   Most hubs are able to detect over-current situations on their
+   ports and report them to the kernel. This attribute is to expose
+   the number of over-current situation occurred on a specific port
+   to user space. This file will contain an unsigned 32 bit value
+   which wraps to 0 after its maximum is reached.
+
 What:  /sys/bus/usb/devices/.../(hub interface)/portX/usb3_lpm_permit
 Date:  November 2015
 Contact:   Lu Baolu 
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index c5c1f6cf3228..6f779b518e75 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -5104,8 +5104,10 @@ static void port_event(struct usb_hub *hub, int port1)
 
if (portchange & USB_PORT_STAT_C_OVERCURRENT) {
u16 status = 0, unused;
+   port_dev->over_current_count++;
 
-   dev_dbg(&port_dev->dev, "over-current change\n");
+   dev_dbg(&port_dev->dev, "over-current change #%u\n",
+   port_dev->over_current_count);
usb_clear_port_feature(hdev, port1,
USB_PORT_FEAT_C_OVER_CURRENT);
msleep(100);/* Cool down */
diff --git a/drivers/usb/core/hub.h b/drivers/usb/core/hub.h
index 2a700ccc868c..78d7f4dad618 100644
--- a/drivers/usb/core/hub.h
+++ b/drivers/usb/core/hub.h
@@ -100,6 +100,7 @@ struct usb_port {
unsigned int is_superspeed:1;
unsigned int usb3_lpm_u1_permit:1;
unsigned int usb3_lpm_u2_permit:1;
+   unsigned int over_current_count;
 };
 
 #define to_usb_port(_dev) \
diff --git a/drivers/usb/core/port.c b/drivers/usb/core/port.c
index 1a01e9ad3804..6979bde87d31 100644
--- a/drivers/usb/core/port.c
+++ b/drivers/usb/core/port.c
@@ -41,6 +41,15 @@ static ssize_t connect_type_show(struct device *dev,
 }
 static DEVICE_ATTR_RO(connect_type);
 
+static ssize_t over_current_count_show(struct device *dev,
+  struct device_attribute *attr, char *buf)
+{
+   struct usb_port *port_dev = to_usb_port(dev);
+
+   return sprintf(buf, "%u\n", port_dev->over_current_count);
+}
+static DEVICE_ATTR_RO(over_current_count);
+
 static ssize_t usb3_lpm_permit_show(struct device *dev,
  struct device_attribute *attr, char *buf)
 {
@@ -109,6 +118,7 @@ static DEVICE_ATTR_RW(usb3_lpm_permit);
 
 static struct attribute *port_dev_attrs[] = {
&dev_attr_connect_type.attr,
+   &dev_attr_over_current_count.attr,
NULL,
 };
 
-- 
2.11.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: [PATCH v3 01/12] dt-bindings: connector: add properties for typec

[Jun Li]

> -Original Message-
> From: linux-usb-ow...@vger.kernel.org
> [mailto:linux-usb-ow...@vger.kernel.org] On Behalf Of Heikki Krogerus
> Sent: 2018年3月14日 17:40
> To: Jun Li 
> Cc: robh...@kernel.org; mark.rutl...@arm.com;
> gre...@linuxfoundation.org; a.ha...@samsung.com; li...@roeck-us.net;
> yue...@google.com; shufan_...@richtek.com; o_leve...@orange.fr;
> linux-usb@vger.kernel.org; dl-linux-imx 
> Subject: Re: [PATCH v3 01/12] dt-bindings: connector: add properties for typec
> 
> On Tue, Mar 13, 2018 at 05:34:27PM +0800, Li Jun wrote:
> > Add bingdings supported by current typec driver, so user can pass all
> > those properties via dt.
> >
> > Signed-off-by: Li Jun 
> > ---
> > Change for v3:
> > - port-type change to be power-type which only for power.
> > - add data-type for data capability.
> > - preferred-role change to try-power-role(bool property need 2, and user
> >   may add both at the same time, so still use one property but rename
> >   it to be try-power-role).
> > - Separate basic typec and power delivery properties.
> > - keep the max-sink-mv/ma/mw, and op-mw, because the counterpart driver
> >   code is to be back[1], to be discussed if we need those 4 setting for long
> >   term.
> >
> > [1]
> >
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
> > .spinics.net%2Flists%2Flinux-usb%2Fmsg166366.html&data=02%7C01%7Cju
> n.l
> >
> i%40nxp.com%7C1dd1571bd9ea4743ec6d08d5898f9d63%7C686ea1d3bc2b4
> c6fa92cd
> >
> 99c5c301635%7C0%7C1%7C636566172296570893&sdata=expnxYX8F5wbW
> VZoZgl91JV
> > shsCTVwq98OpMslMV3XE%3D&reserved=0
> >
> >  .../bindings/connector/usb-connector.txt   | 48
> ++
> >  1 file changed, 48 insertions(+)
> >
> > diff --git
> > a/Documentation/devicetree/bindings/connector/usb-connector.txt
> > b/Documentation/devicetree/bindings/connector/usb-connector.txt
> > index e1463f1..9c7fc83 100644
> > --- a/Documentation/devicetree/bindings/connector/usb-connector.txt
> > +++ b/Documentation/devicetree/bindings/connector/usb-connector.txt
> > @@ -15,6 +15,35 @@ Optional properties:
> >  - type: size of the connector, should be specified in case of USB-A, USB-B
> >non-fullsize connectors: "mini", "micro".
> >
> > +Optional properties for usb-c-connector:
> > +- power-type: should be one of "source", "sink" or "dual"(DRP) if
> > +typec
> > +  connector has power support.
> > +- try-power-role: preferred power role if "dual"(DRP) can support
> > +Try.SNK
> > +  or Try.SRC, should be "sink" for Try.SNK or "source" for Try.SRC.
> > +- data-type: should be one of "host", "device", "dual"(DRD) if typec
> > +  connector supports USB data.
> 
> Why not "power-role" and "data-role" instead of "power-type" and
> "data-type"?

Intention is to reflect the port capability(not state), we already have
power role and data role in sys ABI for current role, I have no strong
preference, if you think power-role and data-role is easy to understand
and proper here, I am ok to follow it. 

Jun
> 
> 
> 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
> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fvger.k
> ernel.org%2Fmajordomo-info.html&data=02%7C01%7Cjun.li%40nxp.com%7C
> 1dd1571bd9ea4743ec6d08d5898f9d63%7C686ea1d3bc2b4c6fa92cd99c5c30
> 1635%7C0%7C1%7C636566172296570893&sdata=iIpoPotQYRA3tCTzTGlqfXx
> BFBA267L%2B4gaXINiB7Iw%3D&reserved=0

Re: [PATCH v3 01/12] dt-bindings: connector: add properties for typec

[Heikki Krogerus]

On Tue, Mar 13, 2018 at 05:34:27PM +0800, Li Jun wrote:
> Add bingdings supported by current typec driver, so user can pass
> all those properties via dt.
> 
> Signed-off-by: Li Jun 
> ---
> Change for v3:
> - port-type change to be power-type which only for power.
> - add data-type for data capability.
> - preferred-role change to try-power-role(bool property need 2, and user
>   may add both at the same time, so still use one property but rename
>   it to be try-power-role).
> - Separate basic typec and power delivery properties.
> - keep the max-sink-mv/ma/mw, and op-mw, because the counterpart driver
>   code is to be back[1], to be discussed if we need those 4 setting for long
>   term.
> 
> [1] https://www.spinics.net/lists/linux-usb/msg166366.html
>  
>  .../bindings/connector/usb-connector.txt   | 48 
> ++
>  1 file changed, 48 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/connector/usb-connector.txt 
> b/Documentation/devicetree/bindings/connector/usb-connector.txt
> index e1463f1..9c7fc83 100644
> --- a/Documentation/devicetree/bindings/connector/usb-connector.txt
> +++ b/Documentation/devicetree/bindings/connector/usb-connector.txt
> @@ -15,6 +15,35 @@ Optional properties:
>  - type: size of the connector, should be specified in case of USB-A, USB-B
>non-fullsize connectors: "mini", "micro".
>  
> +Optional properties for usb-c-connector:
> +- power-type: should be one of "source", "sink" or "dual"(DRP) if typec
> +  connector has power support.
> +- try-power-role: preferred power role if "dual"(DRP) can support Try.SNK
> +  or Try.SRC, should be "sink" for Try.SNK or "source" for Try.SRC.
> +- data-type: should be one of "host", "device", "dual"(DRD) if typec
> +  connector supports USB data.

Why not "power-role" and "data-role" instead of "power-type" and
"data-type"?


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: [RFC PATCH] usb: typec: tcpm: match source fixed pdo with sink variable pdo

[Jun Li]

Hi
> -Original Message-
> From: Hans de Goede [mailto:hdego...@redhat.com]
> Sent: 2018年3月13日 19:36
> To: Jun Li ; gre...@linuxfoundation.org; li...@roeck-us.net;
> heikki.kroge...@linux.intel.com; adam.thomson.opensou...@diasemi.com;
> bad...@google.com
> Cc: linux-usb@vger.kernel.org; dl-linux-imx 
> Subject: Re: [RFC PATCH] usb: typec: tcpm: match source fixed pdo with sink
> variable pdo
> 
> Hi,
> 
> On 13-03-18 01:02, Li Jun wrote:
> > This patch tries to fix the problem describled on revert patch
> > commit[1], suppose any supported voltage ranges of sink should be
> > describled by variable pdo, so instead of revert the patch of only
> > comparing source and sink pdo to select one source pdo, this patch
> > adds the match between source fixed pdo and sink variable pdo.
> >
> > [1]
> >
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
> > .spinics.net%2Flists%2Flinux-usb%2Fmsg166366.html&data=02%7C01%7Cju
> n.l
> >
> i%40nxp.com%7C569be5e2496442f514bd08d588d69fc6%7C686ea1d3bc2b4
> c6fa92cd
> >
> 99c5c301635%7C0%7C0%7C636565377744465803&sdata=hUPib1nNtXArpZ
> Pn0TfMdui
> > ARnVPvc6CezTr0UxJFCI%3D&reserved=0
> >
> > CC: Hans de Goede 
> > CC: Guenter Roeck 
> > CC: Heikki Krogerus 
> > CC: Adam Thomson 
> > CC: Badhri Jagan Sridharan 
> > Signed-off-by: Li Jun 
> > ---
> >   drivers/usb/typec/tcpm.c | 31 +++
> >   1 file changed, 31 insertions(+)
> >
> > diff --git a/drivers/usb/typec/tcpm.c b/drivers/usb/typec/tcpm.c index
> > ef3a60d..8a74a43 100644
> > --- a/drivers/usb/typec/tcpm.c
> > +++ b/drivers/usb/typec/tcpm.c
> > @@ -1815,6 +1815,37 @@ static int tcpm_pd_select_pdo(struct tcpm_port
> *port, int *sink_pdo,
> > break;
> > }
> > }
> > +
> > +   /*
> > +* If the source pdo has the same voltage with one
> > +* fixed pdo, no need check variable pdo for it.
> > +*/
> > +   if (j < port->nr_fixed)
> > +   continue;
> > +
> > +   for (j = port->nr_fixed +
> > +port->nr_batt;
> > +j < port->nr_fixed +
> > +port->nr_batt +
> > +port->nr_var;
> > +j++) {
> > +   if (pdo_fixed_voltage(pdo) >=
> > +pdo_min_voltage(port->snk_pdo[j]) &&
> > +pdo_fixed_voltage(pdo) <=
> > +pdo_max_voltage(port->snk_pdo[j])) {
> > +   ma = min_current(pdo, port->snk_pdo[j]);
> > +   mv = pdo_fixed_voltage(pdo);
> > +   mw = ma * mv / 1000;
> > +   if (mw > max_mw ||
> > +   (mw == max_mw && mv > max_mv)) {
> > +   ret = 0;
> > +   *src_pdo = i;
> > +   *sink_pdo = j;
> > +   max_mw = mw;
> > +   max_mv = mv;
> > +   }
> > +   }
> > +   }
> > } else if (type == PDO_TYPE_BATT) {
> > for (j = port->nr_fixed;
> >  j < port->nr_fixed +
> >
> 
> First of all, this seems to be a fix on top of your previous, reverted patch.
>

It's on top of the patch to be reverted by you.
 
> Since your patch has been reverted, please send a new fixed patch replacing 
> it.
> 

It's Badhri's patch, not mine.

Author: Badhri Jagan Sridharan 
Date:   Wed Nov 15 17:01:56 2017 -0800

typec: tcpm: Only request matching pdos

> As for the proposed fix, you are just fixing the fixed source, variable snk 
> cap
> case here. What if things are the other way around, so fixed snk, variable
> source?

I think that may not work, as the sink defines itself only can work at one
fixed voltage, a variable PDO can make sure the output voltage fixed?

Below is the description of variable supply PDO from PD spec:
"The Variable Supply (non-Battery) PDO exposes very poorly regulated Sources.
The output voltage of a Variable Supply (non-Battery) shall remain within the
absolute maximum output voltage and the absolute minimum output voltage
exposed in the Variable Supply PDO"

So I think a basic rule is the voltage range of selected source PDO should be
within the voltage range of sink PDO, no matter what type they are:
(max_src_mv <= max_snk_mv && min_src_mv >= min_snk_mv)

With this condition meet, then we can select one source PDO with bigger mw or,
the same mw but higher voltage.

> 
> You really need to stop comparing fixed to fixed and variable to variable, 
> e

Re: [PATCH 0/2] USB 3.2 initial support

[Mathias Nyman]

On 13.03.2018 21:58, Adrian Bocaniciu wrote:

On Tue, 13 Mar 2018 17:27:21 +0200
Mathias Nyman  wrote:


Example for clarification:
Gen 1x1 = 5Gbps, SuperSpeed, one lane, same as USB3.0, and USB 3.1 Gen1
Gen 2x1 = 10Gbps, SuperSpeedPlus, one lane, same as USB 3.1 Gen2
Gen 1x2 = 10Gbps, SuperSpeed, Dual-lane (2 x 5Gbps)
Gen 2x2 = 20Gbps, SuperSpeedPlus, Dual-lane (2 x 10Gbps)


4. Should the "speed" sysfs entry be more accurate? USB 3.1 and later
can list different supported lane speeds other than the 5Gbps or 10Gbps.
actual port speed would be lane count * current lane speed in use.
Or do we just keep it simple and show the maximum signaling
rate * lane count, i.e. 5000, 1 or 2?
and show "SSIC" instead of "Gen XxY" for asymetric lane SSIC devices,
skipping details on rx and tx lane counts.



Please do not compute "signaling rate * count", because it is very misleading 
and that value cannot be used to verify whether the hardware works at its maximum 
available speed or not.

Gen 1x2 is not 5 * 2 = 10 Gbps, but only 8 Gbps (like Gb Ethernet is 1 Gbps, 
not 1.25 Gbps), while Gen 2x1 is very close to 10 Gbps, i.e. significantly 
faster (due to a different encoding), so it would be wrong to display them as 
equivalent.



Good point, There is a collision where both Gen 1x2 and and Gen 2x1 both would 
show
10Gbps as "speed" as it so far is based on signaling rate.

But I think this boils down to a compromise between usability, complexity and 
amount of people
we are misleading.

The USB "speeds" are commonly known as 1.5Mbps, 12Mbps, 480Mbps, 5Gbps, and 
10Gbps.
That's what people remember and are probably written on boxes and in wikipedia.

If we take the line Encoding into account the speeds will be:

Gen 1x1 = 4Gbps (8b/10b)
Gen 1x2 = 8Gbps
Gen 2x1 = 9.697Gbps (128b/132b)
Gen 2x2 = 19.394Gbps

Or if we take into account flow control, packet framing and protocol
overhead the effective bandwidth is even less.

I think we will get far more people concerned about their USB 3 device working
only at 4Gbps in Linux when it should be 5Gbps, than we get complaints about 
someone
actually comparing throughputs of Gen 2x1 and Gen 1x2 devices, not being aware 
of
different encodings and overhead.

To verify if the hardware works at it maximum available speed It would be 
important
to show either the lane count or Gen XxY version to the user.

One option is to not show 10Gbps (1) as the sysfs "speed" for Gen 1x2, but 
instead
something like "Dual5000" or "5000x2", but that again can hit scrips and 
userspace
programs expecting "speed" to be numerical. And it feels like adding 
unnecessary complexity

-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 v3 10/12] staging: typec: tcpci: keep the not connecting cc line open

[李書帆]

Hi Jun,

-Original Message-
From: Li Jun [mailto:jun...@nxp.com]
Sent: Tuesday, March 13, 2018 5:35 PM
To: robh...@kernel.org; mark.rutl...@arm.com; gre...@linuxfoundation.org; 
heikki.kroge...@linux.intel.com
Cc: a.ha...@samsung.com; jun...@nxp.com; li...@roeck-us.net; yue...@google.com; 
shufan_lee(李書帆); o_leve...@orange.fr; linux-usb@vger.kernel.org; 
linux-...@nxp.com
Subject: [PATCH v3 10/12] staging: typec: tcpci: keep the not connecting cc 
line open

While set polarity, we should keep the not connecting cc line to be open when 
attached.

Signed-off-by: Li Jun 
---
 drivers/staging/typec/tcpci.c | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/typec/tcpci.c b/drivers/staging/typec/tcpci.c 
index 9a230c6..6fdb179 100644
--- a/drivers/staging/typec/tcpci.c
+++ b/drivers/staging/typec/tcpci.c
@@ -185,6 +185,7 @@ static int tcpci_set_polarity(struct tcpc_dev *tcpc,
   enum typec_cc_polarity polarity)  {
 struct tcpci *tcpci = tcpc_to_tcpci(tcpc);
+unsigned int reg;
 int ret;

 ret = regmap_write(tcpci->regmap, TCPC_TCPC_CTRL, @@ -193,7 +194,17 @@ static 
int tcpci_set_polarity(struct tcpc_dev *tcpc,
 if (ret < 0)
 return ret;

-return 0;
+/* Set the not connected cc line open */
+ret = regmap_read(tcpci->regmap, TCPC_ROLE_CTRL, ®);
+if (ret < 0)
+return ret;
+if (polarity == TYPEC_POLARITY_CC2)
+ret = TCPC_ROLE_CTRL_CC1_SHIFT;
+else
+ret = TCPC_ROLE_CTRL_CC2_SHIFT;
+reg |= TCPC_ROLE_CTRL_CC_OPEN << ret;
+reg &= ~TCPC_ROLE_CTRL_DRP;
+return regmap_write(tcpci->regmap, TCPC_ROLE_CTRL, reg);
 }

 static int tcpci_set_vconn(struct tcpc_dev *tcpc, bool enable)
--
2.7.4

  I applied all of your patches and tested with RT1711H.
  I met a case as following:
  1. The state machine starts toggling with RC.CCx = Rp/Rp
  2. Connect to adapter with an A2C cable
  3. open/open is received after setting RC.DRP to 0. Because RC.CCx is Rp/Rp 
while setting RC.DRP to 0 and the connected A2C cable is a cable with Rp.

  According to TCPCI's specification, Figure 4-20. DRP Initialization and 
Connection Detection, we need to set RC.CCx before setting RC.DRP to 0.

  ConnectionDetermine CC & VCONN
- Set RC.CC1 & RC.CC2 per decision
- Set RC.DRP=0
- Set TCPC_CONTROl.PlugOrientation
- Set PC.AutoDischargeDisconnect=1 & PC.EnableVconn

  If I understand correctly, we'll need to do the following step before setting 
DRP to 0.

@@ -1900,6 +1901,8 @@ static int tcpm_src_attach(struct tcpm_port *port)
if (port->attached)
return 0;

+   tcpm_set_cc(port, tcpm_rp_cc(port));
+
ret = tcpm_set_polarity(port, polarity);
if (ret < 0)
return ret;
@@ -2014,6 +2017,8 @@ static int tcpm_snk_attach(struct tcpm_port *port)
if (port->attached)
return 0;

+   tcpm_set_cc(port, TYPEC_CC_RD);
+
ret = tcpm_set_polarity(port, port->cc2 != TYPEC_CC_OPEN ?
TYPEC_POLARITY_CC2 : TYPEC_POLARITY_CC1);
if (ret < 0)

* Email Confidentiality Notice 

The information contained in this e-mail message (including any attachments) 
may be confidential, proprietary, privileged, or otherwise exempt from 
disclosure under applicable laws. It is intended to be conveyed only to the 
designated recipient(s). Any use, dissemination, distribution, printing, 
retaining or copying of this e-mail (including its attachments) by unintended 
recipient(s) is strictly prohibited and may be unlawful. If you are not an 
intended recipient of this e-mail, or believe that you have received this 
e-mail in error, please notify the sender immediately (by replying to this 
e-mail), delete any and all copies of this e-mail (including any attachments) 
from your system, and do not disclose the content of this e-mail to any other 
person. Thank you!

Re: [PATCH][usb-next] usb: dwc2: ix spelling mistake: "genereted" -> "generated"

[Felipe Balbi]

Hi,

Colin King  writes:
> From: Colin Ian King 
>
> Trivial fix to spelling mistake in dev_warn warning message text.
>
> Signed-off-by: Colin Ian King 

seems like we need a patch to fix your subject ;-) I'll fix it when applying

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH v4 13/15] usb: dwc3: Add workaround for isoc start transfer failure

[Felipe Balbi]

Hi,

Thinh Nguyen  writes:
>> Thinh Nguyen  writes:
>>> In DWC_usb31 version 1.70a-ea06 and prior, for highspeed and fullspeed
>>> isochronous IN, BIT[15:14] of the 16-bit microframe number reported by
>>> the XferNotReady event are invalid. The driver uses this number to
>>> schedule the isochronous transfer and passes it to the START TRANSFER
>>> command. Because this number is invalid, the command may fail. If
>>> BIT[15:14] matches the internal 16-bit microframe, the START TRANSFER
>>> command will pass and the transfer will start at the scheduled time, if
>>> it is off by 1, the command will still pass, but the transfer will start
>>> 2 seconds in the future. All other conditions the START TRANSFER command
>>> will fail with bus-expiry.
>>>
>>> In order to workaround this issue, we can issue multiple START TRANSFER
>>> commands with different values of BIT[15:14]: 'b00, 'b01, 'b10, and 'b11
>>> and do an END TRANSFER command. Each combination is 2 seconds apart. 4
>>> seconds into the future will cause a bus-expiry failure. As the result,
>>> within the 4 possible combinations for BIT[15:14], there will be 2
>>> successful and 2 failure START COMMAND status. One of the 2 successful
>>> command status will result in a 2-second delay. The smaller BIT[15:14]
>>> value is the correct one.
>>>
>>> Since there are only 4 outcomes and the results are ordered, we can
>>> simply test 2 START TRANSFER commands with BIT[15:14] combinations 'b00
>>> and 'b01 to deduce the smallest successful combination.
>>>
>>>  +-+-+
>>>  | BIT(15) | BIT(14) |
>>>  +=+=+
>>>   test0  |   0 |0|
>>>  +-+-+
>>>   test1  |   0 |1|
>>>  +-+-+
>>>
>>> With test0 and test1 BIT[15:14] combinations, here is the logic:
>>> if test0 passes and test1 passes, BIT[15:14] is 'b00
>>> if test0 passes and test1 fails, BIT[15:14] is 'b11
>>> if test0 fails and test1 fails, BIT[15:14] is 'b10
>>> if test0 fails and test1 passes, BIT[15:14] is 'b01
>>>
>>> Synopsys STAR 9001202023: Wrong microframe number for isochronous IN
>>> endpoints.
>>>
>>> Signed-off-by: Thinh Nguyen 
>>> ---
>>>   drivers/usb/dwc3/core.c   |   2 +
>>>   drivers/usb/dwc3/core.h   |  13 
>>>   drivers/usb/dwc3/gadget.c | 189 
>>> --
>>>   3 files changed, 199 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
>>> index ddcfa2a60d4b..d27ddfcc3b8a 100644
>>> --- a/drivers/usb/dwc3/core.c
>>> +++ b/drivers/usb/dwc3/core.c
>>> @@ -1073,6 +1073,8 @@ static void dwc3_get_properties(struct dwc3 *dwc)
>>> "snps,is-utmi-l1-suspend");
>>> device_property_read_u8(dev, "snps,hird-threshold",
>>> &hird_threshold);
>>> +   dwc->dis_start_transfer_quirk = device_property_read_bool(dev,
>>> +   "snps,dis-start-transfer-quirk");
>>> dwc->usb3_lpm_capable = device_property_read_bool(dev,
>>> "snps,usb3_lpm_capable");
>>> device_property_read_u8(dev, "snps,rx-thr-num-pkt-prd",
>>> diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
>>> index 71cf53a06e49..c09cd0c6354e 100644
>>> --- a/drivers/usb/dwc3/core.h
>>> +++ b/drivers/usb/dwc3/core.h
>>> @@ -555,6 +555,10 @@ struct dwc3_event_buffer {
>>>* @name: a human readable name e.g. ep1out-bulk
>>>* @direction: true for TX, false for RX
>>>* @stream_capable: true when streams are enabled
>>> + * @frame_number_15_14: BIT[15:14] of the frame number to test isochronous
>>> + * START TRANSFER command failure workaround
>>> + * @test0_status: the result of testing START TRANSFER command with
>>> + * frame_number_15_14 = 'b00 (non-zero means failure)
>>>*/
>>>   struct dwc3_ep {
>>> struct usb_ep   endpoint;
>>> @@ -608,6 +612,10 @@ struct dwc3_ep {
>>>   
>>> unsigneddirection:1;
>>> unsignedstream_capable:1;
>>> +
>>> +   /* Isochronous START TRANSFER workaround for STAR 9001202023 */
>>> +   u8  frame_number_15_14;
>>> +   int test0_status;
>>>   };
>>>   
>>>   enum dwc3_phy {
>>> @@ -862,6 +870,8 @@ struct dwc3_scratchpad_array {
>>>* @pullups_connected: true when Run/Stop bit is set
>>>* @setup_packet_pending: true when there's a Setup Packet in FIFO. 
>>> Workaround
>>>* @three_stage_setup: set if we perform a three phase setup
>>> + * @dis_start_transfer_quirk: set if start_transfer failure SW workaround 
>>> is
>>> + * not needed for DWC_usb31 version 1.70a-ea06 and below
>>>* @usb3_lpm_capable: set if hadrware supports Link Power Management
>>>* @disable_scramble_quirk: set if we enable the disable scramble quirk
>>>* @u2exit_lfps_quirk: set if we enable u2exit lfps quirk
>>> @@ -982,10 +992,12 @@ stru

Re: [PATCH v4 2/2] usb/gadget: Add driver for Aspeed SoC virtual hub

[Felipe Balbi]

Hi,

Benjamin Herrenschmidt  writes:
> On Tue, 2018-03-13 at 09:35 +1100, Benjamin Herrenschmidt wrote:
>> On Fri, 2018-03-09 at 11:20 +0200, Felipe Balbi wrote:
>> > 
>> > > diff --git a/drivers/usb/gadget/udc/aspeed-vhub/core.c 
>> > > b/drivers/usb/gadget/udc/aspeed-vhub/core.c
>> > > new file mode 100644
>> > > index ..31ed2b6e241b
>> > > --- /dev/null
>> > > +++ b/drivers/usb/gadget/udc/aspeed-vhub/core.c
>> > > @@ -0,0 +1,429 @@
>> > 
>> > missing SPDX license identifier (all files)
>> 
>> Ah yup, the driver predates me knowing about them, I'll fix.
>> 
>> > > +static bool force_usb1 = false;
>> > > +static bool no_dma_desc = false;
>> > > +
>> > > +module_param_named(force_usb1, force_usb1, bool, 0644);
>> > > +MODULE_PARM_DESC(force_usb1, "Set to true to force to USB1 speed");
>> > > +module_param_named(no_dma_desc, no_dma_desc, bool, 0644);
>> > > +MODULE_PARM_DESC(no_dma_desc, "Set to true to disable use of DMA 
>> > > descriptors");
>> > 
>> > module parameters? Sorry, but no.
>> 
>> Why ? Any suggestion then for the two above ? They are mostly meant as
>> diagnostic/debug features if something doesn't work (for example, the
>> board has some sub-standard wiring making USB2 unreliable, or a driver
>> bug with DMA descriptors).
>> 
>> I can just take them out completely but it feels like module parameters
>> are the right thing to do in that specific case.
>
> I've taken out the second one, it isn't that useful. I've left in the
> first one however. This is the right thing to do. That setting (force
> USB1 mode) needs to be applied as soon as the vhub gets initialized
> at driver load time, regardless of what gadgets might be attached to
> it later on.

we have DT binding for passing maximum speed. A module parameter is
global, whereas DT binding (or device property) is per-device.

>> > > +void ast_vhub_init_hw(struct ast_vhub *vhub)
>> > > +{
>> > > +   u32 ctrl;
>> > > +
>> > > +   UDCDBG(vhub,"(Re)Starting HW ...\n");
>> > > +
>> > > +   /* Enable PHY */
>> > > +   ctrl = VHUB_CTRL_PHY_CLK |
>> > > +   VHUB_CTRL_PHY_RESET_DIS;
>> > > +
>> > > +#if 0 /*
>> > > +   * This causes registers to become inaccessible during
>> > > +   * suspend. Need to figure out how to bring the controller
>> > > +   * back into life to issue a wakeup.
>> > > +   */
>> > > +   ctrl |= VHUB_CTRL_CLK_STOP_SUSPEND;
>> > > +#endif
>> > 
>> > no commented code.
>> 
>> Why ? This documents a HW issue ... ie, one would normally want to set
>> this bit but you can't because in practice you can't bring the HW back
>> short of doing a full reset.
>
> So I don't want to lose the "HW documentation" part of that, I've
> turned the above into a comment:
>
>   /*
>   * We do *NOT* set the VHUB_CTRL_CLK_STOP_SUSPEND bit
>   * to stop the logic clock during suspend because
>   * it causes the registers to become inaccessible and
>   * we haven't yet figured out a good wayt to bring the
>   * controller back into life to issue a wakeup.
>   */

this is good

> It will be in v5 when I post it (I'll test a bit more and wait
> for other replies from you, if I don't hear back I'll probably send
> it by end of week or next week).

okay

>> > > +   /*
>> > > +* Set some ISO & split control bits according to Aspeed
>> > > +* recommendation
>> > > +*
>> > > +* VHUB_CTRL_ISO_RSP_CTRL: When set tells the HW to respond
>> > > +* with 0 bytes data packet to ISO IN endpoints when no data
>> > > +* is available.
>> > > +*
>> > > +* VHUB_CTRL_SPLIT_IN: This makes a SOF complete a split IN
>> > > +* transaction.
>> > > +*/
>> > > +   ctrl |= VHUB_CTRL_ISO_RSP_CTRL | VHUB_CTRL_SPLIT_IN;
>> > > +   writel(ctrl, vhub->regs + AST_VHUB_CTRL);
>> > > +   udelay(1);
>> > > +
>> > > +   /* Set descriptor ring size */
>> > > +#if AST_VHUB_DESCS_COUNT == 256
>> > > +   ctrl |= VHUB_CTRL_LONG_DESC;
>> > > +   writel(ctrl, vhub->regs + AST_VHUB_CTRL);
>> > > +#elif AST_VHUB_DESCS_COUNT != 32
>> > > +   #error Invalid AST_VHUB_DESCS_COUNT
>> > > +#endif
>> > 
>> > find a better way for this. No ifdefs
>> 
>> Ugh ? What's that rule ? I could do a module parameter but you hate
>> that too and honestly keeping that an ifdef makes things easier. It's
>> not meant to be changed unless a hardware or performance issues shows
>> up, I wanted to keep both mode of operations available.
>
> Oh well, I've just made it an if () and kept the #define, and the
> #error turns into a BUILD_BUG_ON(). Same principle... but I don't
> like those arbitrary "rules", I try to avoid them for things I
> maintain (granted, not much anymore these days).

they're not arbitrary, actually, and have been around for a long time ;-)

> Do you have more comments for the rest of the driver or that's it ?

so far, that's it.

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH v1 2/2] usb: dwc3: Add Qualcomm DWC3 glue driver

[Felipe Balbi]

Hi,

Manu Gautam  writes:
> Hi,
>
>
> On 3/13/2018 4:38 PM, Felipe Balbi wrote:
>> Hi,
>>
>> +Andy
>>
>> Manu Gautam  writes:
>>> DWC3 controller on Qualcomm SOCs has a Qscratch wrapper.
>>> Some of its uses are described below resulting in need to
>>> have a separate glue driver instead of using dwc3-of-simple:
>>>  - It exposes register interface to override vbus-override
>>>and lane0-pwr-present signals going to hardware. These
>>>must be updated in peripheral mode for DWC3 if vbus lines
>>>are not connected to hardware block. Otherwise RX termination
>>>in SS mode or DP pull-up is not applied by device controller.
>> right, core needs to know that VBUS is above 4.4V. Why wasn't this a
>> problem when the original glue layer was first published?
>
> Thanks for reviewing.
> Original glue layer supported only host mode, hence this wasn't needed.

okay

>>>  - pwr_events_irq_stat support to ensure USB2 PHY is in L2 state
>>>before glue driver can turn-off clocks and suspend PHY.
>> Core manages PHY suspend automatically. Isn't that working for you? Why?
>
> Yes, it is not supported with QUSB2 PHY (usb2-phy on Qualcomm SOCs).

but the PHY doesn't need to support it, DWC3 does :-)

> Issue is that If core suspends USB2 PHY (say in host mode if some SS device 
> connected),
> USB2 PHY stops responding to any attach event as it can't exit suspend state 
> by itself.

Okay, so we miss remote wakeup events. Fair enough.

>>>  - Support to replace pip3 clock going to DWC3 with utmi clock
>>>for hardware configuration where SSPHY is not used with DWC3.
>> Is that SW configurable? Really? In any case seems like this and SESSVLD
>> valid should be handled using Hans' and Heikki's mux support.
>
> Yes, with this we can use dwc3 without using SSPHY. Please point me to
> those patches. There are only bunch of register writes in glue wrapper to
> achieve the same.

https://www.spinics.net/lists/linux-usb/msg160868.html

>>> +static int dwc3_qcom_suspend(struct dwc3_qcom *qcom)
>>> +{
>>> +   struct dwc3 *dwc = platform_get_drvdata(qcom->dwc3);
>> nope! Glue shouldn't touch dwc3 at all.
> Other than PHY handles, need this to fail runtime suspend if dwc3 hasn't
> probed yet.

Will that even happen? You should pm_runtime_forbid() by default,
anyway and expect it to be enabled via sysfs later, no?

>>> +   dwc3_qcom_suspend_hsphy(qcom);
>>> +
>>> +   if (dwc->usb2_generic_phy)
>>> +   phy_pm_runtime_put_sync(dwc->usb2_generic_phy);
>>> +   if (dwc->usb3_generic_phy)
>>> +   phy_pm_runtime_put_sync(dwc->usb3_generic_phy);
>> core.c should do this.
> Recommended sequence from h/w programming guide is that:
> 1. PHY autosuspend must be left disabled - 
> snps,dis_u2_susphy_quirk/dis_enblslpm_quirk
> 2. During runtime-suspend (say on xhci bus_suspend) , PHY should be suspended
>     using GUSB2PHYCFG register

this is something that dwc3 core can do on its own suspend implementation.

> 3. Wait until pwr_event_irq_stat in qscratch reflects PHY transition to L2.

this is interesting part. Is this register accessible by the PHY driver?
Seems like that would be the best place to stuff this...

> 3. USB2 PHY driver can suspend - enable wakeup events and turns off clocks 
> etc.

... together with this.

> 4. dwc3 glue driver can suspend.
>
> Since, pwr_event_irq stat can't be checked in core driver, I added this 
> handling
> in glue driver. Alternative approach I can think of is to let dwc3 core 
> suspend
> PHY using GUSBPHYCFG register on suspend,  add some delay before
> suspending PHY. Glue driver can check for pwr_event_irq stat and throw a
> warning if PHY not in L2.

almost :-) core_suspend fiddles with GUSB2PHYCFG for suspend and calls
phy_suspend() (or whatever the function is called heh), that will go to
your phy driver's suspend callback, which checks pwr_event_irq_stat and
then pm_runtime_put() to schedule ->runtime_suspend() so that can enable
wakeups and switch off clocks.

>>> +   irq = platform_get_irq_byname(pdev, "dp_hs_phy_irq");
>>> +   if (irq > 0) {
>>> +   irq_set_status_flags(irq, IRQ_NOAUTOEN);
>> why do you need to set this flag?
> These wakeup_irqs should be enabled only during suspend. With this flag I
> don't need to disable irq immediately after requesting it.

oh, okay. You may want to add a comment here :-)

>
>>
>>> +   ret = devm_request_threaded_irq(qcom->dev, irq, NULL,
>>> +   qcom_dwc3_resume_irq,
>>> +   IRQF_TRIGGER_HIGH | IRQF_ONESHOT,
>>> +   "qcom_dwc3 DP_HS", qcom);
>> this is the same as devm_request_irq()
> I am passing hard_irq handler as NULL whereas thread_fn is not NULL.
> devm_request_irq is just the opposite.

oh, indeed. I misparsed it.

>>> +static const struct dev_pm_ops dwc3_qcom_dev_pm_ops = {
>>> +   SET_SYSTEM_SLEEP_PM_OPS(dwc3_qcom_pm_suspend, dwc3_qcom_pm_resume)
>>> +   SET_RUNTIME_PM_OPS(dwc3_qcom_runtime_suspend, 

Re: [PATCH] usb: misc: supports Apple Carplay driver

[Chunfeng Yun]

On Wed, 2018-03-14 at 07:16 +0100, Greg Kroah-Hartman wrote:
> On Wed, Mar 14, 2018 at 02:02:36PM +0800, Chunfeng Yun wrote:
> > The driver is used to support Apple carplay feature by a debugfs
> > interface which can force the driver to send a USB Vendor Request
> > of "Apple Device to Host Mode Switch" to switch Apple Device
> > into host mode.
> 
> While I am all for crazy debugfs interfaces, I would _strongly_ suggest
> not doing that here for the main API to the device.  I know Android is
> trying to prevent any new devices from even enabling debugfs, and as the
> file system requires root permissions by default, you are forcing any
> user of your new api to run as root, which is not a good idea either.
> 
> Given that all you are doing here is a single usb control message, why
> does this even need to be a kernel driver at all?  Can't you do the same
> thing from userspace with a simple libusb/usbfs program?  Or even a
> simple script?
Ok, I'll abandon this patch, and do it by libusb

Thanks a lot

> 
> 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] Add Apple Carplay driver

[Chunfeng Yun]

On Tue, 2018-03-13 at 23:53 -0700, Matthew Dharm wrote:
> Why is this a kernel-level driver, rather than a userspace application
> that uses libusb to send the single vendor-specific command required?
> Since this command would be applicable to many CarPlay devices, with
> many different VID/PIDs, it would seem to make more sense as a
> userspace app that took a reference to a USB device or VID/PID.
Sorry, I'm not familiar with libusb.
But after I roughly read a simple example using libusb, it indeed can be
realized by a userspace driver.

Thanks for your useful comments

> 
> Matt
> 
> On Tue, Mar 13, 2018 at 11:02 PM, Chunfeng Yun
>  wrote:
> > From bf48dcd9cb254576cfea373c9a5d2ab996408895 Mon Sep 17 00:00:00 2001
> > From: Chunfeng Yun 
> > Date: Tue, 13 Mar 2018 11:47:38 +0800
> > Subject: [PATCH] Add Apple Carplay driver
> >
> > Some Apple devices which support Carplay can enter USB Host Mode from USB
> > Device Mode after receiving a specific USB Vendor Request. There is a
> > requirement apply to accesssories that support the USB dual role switch
> > feature, and must have a USB-A receptacle that is capable of functioning
> > in both USB Host and USB Device roles.
> > It means that the driver should supports manual Dual-Role switch, due to
> > no IDDIG pin is avaliable.
> >
> > There is no suitable place to add this spicific USB Vendor Request, so
> > here I extract a single driver which allow user force to send it by a debug
> > interface when need it, and keep it independent on USB Dual-Role Controller
> > Drivers.
> > But to implement carplay feature, there are some requirments for USB 
> > Dual-Role
> > Driver:
> > 1. supports manual dual-role switch, such as, by a debug interface;
> > 2. keep vbus alive even when switch host into device mode;
> >
> > More information please refer to "Chapter 46. USB Role Switch" in
> > MFI Accessroy Interface Specification.pdf
> >
> > Chunfeng Yun (1):
> >   usb: misc: supports Apple Carplay driver
> >
> >  drivers/usb/misc/Kconfig   |9 +++
> >  drivers/usb/misc/Makefile  |1 +
> >  drivers/usb/misc/carplay.c |  193 
> > 
> >  3 files changed, 203 insertions(+)
> >  create mode 100644 drivers/usb/misc/carplay.c
> >
> > --
> > 1.7.9.5
> >
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 
> 


--
To unsubscribe from this list: send the line "unsubscribe 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: misc: supports Apple Carplay driver

[Greg Kroah-Hartman]

On Wed, Mar 14, 2018 at 02:02:36PM +0800, Chunfeng Yun wrote:
> The driver is used to support Apple carplay feature by a debugfs
> interface which can force the driver to send a USB Vendor Request
> of "Apple Device to Host Mode Switch" to switch Apple Device
> into host mode.

While I am all for crazy debugfs interfaces, I would _strongly_ suggest
not doing that here for the main API to the device.  I know Android is
trying to prevent any new devices from even enabling debugfs, and as the
file system requires root permissions by default, you are forcing any
user of your new api to run as root, which is not a good idea either.

Given that all you are doing here is a single usb control message, why
does this even need to be a kernel driver at all?  Can't you do the same
thing from userspace with a simple libusb/usbfs program?  Or even a
simple script?

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