Re: Fwd: usb: uas: device reset most the time while enumeration- usb3.0

[Felipe Balbi]

Hi,

Greg KH  writes:
> On Wed, Apr 04, 2018 at 05:14:50PM +0530, tnim...@codeaurora.org wrote:
>> Hi Oliver/Greg,
>> 
>> I am able to duplicated the UAS issue on 4.16 as well.
>> The behavior is same new usb device detects and reset after aprox 30
>> sec(SD_TIMEOUT)
>> Logs are already shared below.
>> 
>> We are using Synopsys dwc3 as host controller, May I know have tested it
>> with dwc3?
>> I have tried it on Linux PC (x86 Ubuntu machine) I could not see the issue.
>> It enumerates well.
>
> Great, stick with an x86 platform!  :)
>
> Looks like a dwc3 host controller issue, try enabling tracing and
> debugging in that driver when this happens to see what is going on.
> Also look at all of the recent dwc3 patches that were just sent to Linus
> for 4.17-rc1 to verify if that solves the issue.

dwc3's host side is xhci compliant :-) Some revisions have some quirks
which may not all be supported.

Tushar, which dwc3 revision are you using? Have you gotten in touch with
your HW designers to ask for Errata List? A run with xhci tracepoints
enabled will probably give a lot of insight into the issue.

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

Re: [PATCH 1/4] usb: gadget: udc: renesas_usb3: fix double phy_put()

[Sasha Levin]

Hi Yoshihiro Shimoda.

[This is an automated email]

This commit has been processed because it contains a "Fixes:" tag.
fixing commit: 279d4bc64060 usb: gadget: udc: renesas_usb3: add support for 
generic phy.

The bot has also determined it's probably a bug fixing patch. (score: 96.8529)

The bot has tested the following trees: v4.15.15, 

v4.15.15: Build OK!

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

Re: [PATCH 2/4] usb: gadget: udc: renesas_usb3: should remove debugfs

[Sasha Levin]

Hi Yoshihiro Shimoda.

[This is an automated email]

This commit has been processed because it contains a "Fixes:" tag.
fixing commit: 43ba968b00ea usb: gadget: udc: renesas_usb3: add debugfs to set 
the b-device mode.

The bot has also determined it's probably a bug fixing patch. (score: 94.9837)

The bot has tested the following trees: v4.15.15, v4.14.32, 

v4.15.15: Build OK!
v4.14.32: Failed to apply! Possible dependencies:
279d4bc64060: ("usb: gadget: udc: renesas_usb3: add support for generic 
phy")
cf06df3fae28: ("usb: gadget: udc: renesas_usb3: move 
pm_runtime_{en,dis}able()")
90d588642a7f: ("usb: gadget: udc: renesas_usb3: Add suspend/resume 
functions")


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

Re: [PATCH 3/4] usb: gadget: udc: renesas_usb3: should call pm_runtime_enable() before add udc

[Sasha Levin]

Hi Yoshihiro Shimoda.

[This is an automated email]

This commit has been processed because it contains a "Fixes:" tag.
fixing commit: cf06df3fae28 usb: gadget: udc: renesas_usb3: move 
pm_runtime_{en,dis}able().

The bot has also determined it's probably a bug fixing patch. (score: 98.8092)

The bot has tested the following trees: v4.15.15, 

v4.15.15: Build OK!

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

Re: [PATCH 4/4] usb: gadget: udc: renesas_usb3: should call devm_phy_get() before add udc

[Sasha Levin]

Hi Yoshihiro Shimoda.

[This is an automated email]

This commit has been processed because it contains a "Fixes:" tag.
fixing commit: 279d4bc64060 usb: gadget: udc: renesas_usb3: add support for 
generic phy.

The bot has also determined it's probably a bug fixing patch. (score: 99.1076)

The bot has tested the following trees: v4.15.15, 

v4.15.15: Failed to apply! Possible dependencies:
938408cce8cd: ("usb: gadget: udc: renesas_usb3: should call 
pm_runtime_enable() before add udc")


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

RE: usb: usbtmc: Proposal for new ioctl functions

[Guido Kiener]

Greg,

Before sending patches we want to be sure doing  the right things. I'm not sure 
how we should deal with the sysfs parameters for USBTMC devices:
See 
https://github.com/torvalds/linux/blob/master/Documentation/ABI/stable/sysfs-driver-usb-usbtmc
There are some parameters defined for each device instance: TermChar, 
TermCharEnabled, and auto_abort.
The new driver should include ioctl functions to change these parameters for 
each file handle and not for each device instance.
So we could reassign the device instance parameters (TermChar, TermCharEnabled) 
to be default values for each file handle.
Furthermore the new driver will have more ioctl functions to change timeout and 
EOM flag,
Here are my questions:
1. Are there any (test) scripts that are using the sysfs parameters TermChar, 
TermCharEnabled where we can check that the new driver is doing the same things?
2. Shall we add new sysfs parameters for timeout and EOM flag? (ioctls are 
already added)
3. Is there any rule when to use upper/lower case or underscore for these 
parameters (e.g. Timeout, EOM or end_of_message)?

Well, I'm quite happy with the performance of the new ioctl functions for 
generic read/write and I don't want to start a lengthy discussion here.
However I need some expert knowledge and hints about the following questions:
1. We can detect short USB packages. A ZLP (Zero Length Package) can happen 
when the previous package has the maximum packet length.
The driver could be simplified if it would be possible to detect ZLPs. Is there 
any way (without changing the USB subsystem) to detect ZLPs? 
2. For ultimate performance: Is there any trick where a usb_complete_t function 
or submitted urb can transfer (copy) received data directly to a userland 
buffer (e.g. scatter/gather streams) ?

Best regards,

Guido


-Original Message-
From: Greg KH  
Sent: Wednesday, March 28, 2018 7:52 AM
To: Kiener Guido 1DC3 
Subject: Re: usb: usbtmc: Proposal for new ioctl functions

On Tue, Mar 27, 2018 at 08:57:27PM +0200, guido.kie...@rohde-schwarz.com wrote:
> Hi all,
> 
> This is a follow up mail from the discussion of thread
>  https://marc.info/?l=linux-usb=149485247607564=2
> 
> Our working group "VISA for Linux" (IVI Foundation, 
> www.ivifoundation.org)
> 
> wants to extend the Linux USBTMC driver 
> (linux/drivers/usb/class/usbtmc.c)
> that can communicate with the T instruments.
> 
> To meet our requirements we need some additional ioctl functions that 
> can send control, bulk in/out messages in a generic way.
> 
> Kindly supported by Dave Penkler there is now a github project at 
> https://github.com/dpenkler/linux-usbtmc
> that already supports new functions to set/get timeout, EOM flag (End 
> of Message), and termchar (detection of termination character).
> 
> This project and forked repos are our playground and still under 
> development.
> 
> Our experimental and generic functions are currently developed at the
> fork:
> https://github.com/GuidoKiener/linux-usbtmc
> 
> For a fast read/write we want to implement new generic ioctl functions:
> #define USBTMC_IOCTL_WRITE  _IOWR(USBTMC_IOC_NR, 13, struct
> usbtmc_message)
> #define USBTMC_IOCTL_READ_IOWR(USBTMC_IOC_NR, 14, struct 
> usbtmc_message)
> #define USBTMC_IOCTL_WRITE_RESULT _IOWR(USBTMC_IOC_NR, 15, __u64) 
> #define USBTMC488_IOCTL_WAIT_SRQ  _IOW(USBTMC_IOC_NR, 23, unsigned int)
> #define USBTMC_IOCTL_CANCEL_IO_IO(USBTMC_IOC_NR, 35)
> #define USBTMC_IOCTL_CLEANUP_IO   _IO(USBTMC_IOC_NR, 36)
> /* For test purpose only */
> #define USBTMC_IOCTL_SET_OUT_HALT _IO(USBTMC_IOC_NR, 30) #define 
> USBTMC_IOCTL_SET_IN_HALT  _IO(USBTMC_IOC_NR, 31)
> 
> For further description please refer to the readme.md file at 
> https://github.com/GuidoKiener/linux-usbtmc/blob/master/README.md
> 
> Open questions and comments can be just added to the wiki:
> https://github.com/GuidoKiener/linux-usbtmc/wiki
> 
> When our working group is happy with the proposed extensions and the 
> driver tested by several T companies then we would like to submit 
> these patches to the Linux kernel.

Great, submit patches like any other developer when you have them ready.
You don't need to do anything special here, that's how Linux is developed. :)

Note, please do not depend on these new apis until _after_ we have merged the 
patches, as there might be changes required due to the review process finding 
problems, so please submit changes as soon as possible.

thanks,

greg k-h

Re: [PATCH v2 2/5] usb: typec: fusb302: remove max_snk_* for sink config

[Hans de Goede]

Hi,

On 04-04-18 14:06, Mats Karrman wrote:

Hi Li,

On 2018-03-23 15:58, Li Jun wrote:


Since max_snk_* is to be deprecated, so remove max_snk_* by adding a
variable PDO for sink config.

Signed-off-by: Li Jun 
---
  drivers/usb/typec/fusb302/fusb302.c | 51 +++--
  1 file changed, 37 insertions(+), 14 deletions(-)

diff --git a/drivers/usb/typec/fusb302/fusb302.c 
b/drivers/usb/typec/fusb302/fusb302.c
index 7036171..db4d9cd 100644
--- a/drivers/usb/typec/fusb302/fusb302.c
+++ b/drivers/usb/typec/fusb302/fusb302.c
@@ -120,6 +120,7 @@ struct fusb302_chip {
  enum typec_cc_polarity cc_polarity;
  enum typec_cc_status cc1;
  enum typec_cc_status cc2;
+    u32 snk_pdo[PDO_MAX_OBJECTS];
  #ifdef CONFIG_DEBUG_FS
  struct dentry *dentry;
@@ -1212,11 +1213,6 @@ static const u32 snk_pdo[] = {
  static const struct tcpc_config fusb302_tcpc_config = {
  .src_pdo = src_pdo,
  .nr_src_pdo = ARRAY_SIZE(src_pdo),
-    .snk_pdo = snk_pdo,
-    .nr_snk_pdo = ARRAY_SIZE(snk_pdo),
-    .max_snk_mv = 5000,
-    .max_snk_ma = 3000,
-    .max_snk_mw = 15000,
  .operating_snk_mw = 2500,
  .type = TYPEC_PORT_DRP,
  .data = TYPEC_PORT_DRD,
@@ -1756,6 +1752,38 @@ static int init_gpio(struct fusb302_chip *chip)
  return 0;
  }
+static int fusb302_composite_snk_pdo_array(struct fusb302_chip *chip)
+{
+    struct device *dev = chip->dev;
+    u32 mv, ma, mw, min_mv;
+    unsigned int i;
+
+    /* Copy the static snk pdo */
+    for (i = 0; i < ARRAY_SIZE(snk_pdo); i++)
+    chip->snk_pdo[i] = snk_pdo[i];
+
+    if (device_property_read_u32(dev, "fcs,max-sink-microvolt", ) ||
+    device_property_read_u32(dev, "fcs,max-sink-microamp", ) ||
+    device_property_read_u32(dev, "fcs,max-sink-microwatt", ))
+    return i;
+
+    mv = mv / 1000;
+    ma = ma / 1000;
+    mw = mw / 1000;
+
+    min_mv = 1000 * chip->tcpc_config.operating_snk_mw / ma;
+    if (pdo_type(snk_pdo[i-1] == PDO_TYPE_FIXED))


You've got the parentheses wrong.

Apart from that I don't like/understand why the PDO's should be fixed.
Every product should be able to have its own settings, including the first PDO 
(e.g. it
might need to specify a higher current and/or set the "Higher Capability" bit).

I think this would be best solved the same way as in your TCPCI driver patch 
series [1]
with a list freely specified by a property.

[1] https://www.spinics.net/lists/linux-usb/msg167398.html


Hmm, interesting, for the x86 use-case that would require updating
the properties for the fusb302 defined in:

drivers/platform/x86/intel_cht_int33fe.c

In tandem, which is easily doable.

But what about other users of the fusb302 driver? Since this driver
was added before I started using it for some x86 boards, I assume
there are some non x86 users, so we should preserve compatibility
for DTB files which don't define any sink PDOs in their properties,
I guess we could fall to a default fixed 5V sink pdo for those.

Regards,

Hans






+    min_mv = max(min_mv, pdo_fixed_voltage(snk_pdo[i-1]));
+    else
+    min_mv = max(min_mv, pdo_max_voltage(snk_pdo[i-1]));
+    ma = min(ma, 1000 * mw / min_mv);
+
+    /* Insert the new pdo to the end */
+    chip->snk_pdo[i] = PDO_VAR(min_mv, mv, ma);
+
+    return i+1;
+}
+
  static int fusb302_probe(struct i2c_client *client,
   const struct i2c_device_id *id)
  {
@@ -1784,18 +1812,13 @@ static int fusb302_probe(struct i2c_client *client,
  chip->tcpc_dev.config = >tcpc_config;
  mutex_init(>lock);
-    if (!device_property_read_u32(dev, "fcs,max-sink-microvolt", ))
-    chip->tcpc_config.max_snk_mv = v / 1000;
-
-    if (!device_property_read_u32(dev, "fcs,max-sink-microamp", ))
-    chip->tcpc_config.max_snk_ma = v / 1000;
-
-    if (!device_property_read_u32(dev, "fcs,max-sink-microwatt", ))
-    chip->tcpc_config.max_snk_mw = v / 1000;
-
  if (!device_property_read_u32(dev, "fcs,operating-sink-microwatt", ))
  chip->tcpc_config.operating_snk_mw = v / 1000;
+    /* Composite sink PDO */
+    chip->tcpc_config.nr_snk_pdo = fusb302_composite_snk_pdo_array(chip);
+    chip->tcpc_config.snk_pdo = chip->snk_pdo;
+
  /*
   * Devicetree platforms should get extcon via phandle (not yet
   * supported). On ACPI platforms, we get the name from a device prop.


--
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: select USB_COMMON for usb role switch config

[Hans de Goede]

Hi,

On 04-04-18 14:21, Arnd Bergmann wrote:

The new axp288 extcon driver has no dependency on USB itself but
calls the usb role switch helper functions. This causes a link error
when USB_COMMON is disabled, as that subdirectory never gets entered:

drivers/extcon/extcon-axp288.o: In function `axp288_usb_role_work':
extcon-axp288.c:(.text+0x47b): undefined reference to `usb_role_switch_set_role'
extcon-axp288.c:(.text+0x498): undefined reference to `usb_role_switch_get_role'
drivers/extcon/extcon-axp288.o: In function `axp288_extcon_probe':
extcon-axp288.c:(.text+0x675): undefined reference to `usb_role_switch_get'
extcon-axp288.c:(.text+0x6d1): undefined reference to `usb_role_switch_put'
drivers/extcon/extcon-axp288.o: In function `axp288_put_role_sw':
extcon-axp288.c:(.text+0x1c): undefined reference to `usb_role_switch_put'

There are multiple ways of fixing this, I chose to 'select USB_COMMON',
since that is how we solved the same problem for other helpers like
USB_LED_TRIG or PHY drivers.

Fixes: d54f063cdbe4 ("extcon: axp288: Set USB role where necessary")
Signed-off-by: Arnd Bergmann 

Thanks.

I agree that this is the right way to fix this (matches the other
drivers/usb/Kconfig bits):

Reviewed-by: Hans de Goede 

Regards,

Hans




---
  drivers/usb/Kconfig | 1 +
  1 file changed, 1 insertion(+)

diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig
index 75f7fb151f71..987fc5ba6321 100644
--- a/drivers/usb/Kconfig
+++ b/drivers/usb/Kconfig
@@ -207,5 +207,6 @@ config USB_ULPI_BUS
  
  config USB_ROLE_SWITCH

tristate
+   select USB_COMMON
  
  endif # USB_SUPPORT



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

Re: [PATCH v2] lan78xx: Connect phy early

[David Miller]

From: Alexander Graf 
Date: Wed,  4 Apr 2018 00:19:35 +0200

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

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

Re: [PATCH] usbip: vhc_hcd: prevent module being removed while device are attached

[Shuah Khan]

On 04/04/2018 02:25 AM, Oliver Neukum wrote:
> Am Dienstag, den 03.04.2018, 09:56 -0600 schrieb Shuah Khan:
>> This is a virtual device associated to a real physical device on a different
>> system. My concern is that if the module gets removed accidentally then it
>> could disrupt access to the remote device. The remote nature of the device
>> with several players involved makes this scenario a bit more complex than
> 
> Hi,
> 
> you would doubtlessly lose connection to that device. Yet you would
> also lose connections if you down your network. You need to be root
> to unload a module. You could overwrite your root filesystems or flash
> your firmware. In general we cannot and don't try to protect root
> from such accidents.
> 

Yes. There are several scenarios that could disrupt access. There are
no bad things happening other than the expected read failures when the
device is actively in use.

thanks for the review.
-- Shuah
--
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: Fwd: usb: uas: device reset most the time while enumeration- usb3.0

[Greg KH]

On Wed, Apr 04, 2018 at 06:41:41PM +0530, tnim...@codeaurora.org wrote:
> On 2018-04-04 18:07, Greg KH wrote:
> > On Wed, Apr 04, 2018 at 05:14:50PM +0530, tnim...@codeaurora.org wrote:
> > > Hi Oliver/Greg,
> > > 
> > > I am able to duplicated the UAS issue on 4.16 as well.
> > > The behavior is same new usb device detects and reset after aprox 30
> > > sec(SD_TIMEOUT)
> > > Logs are already shared below.
> > > 
> > > We are using Synopsys dwc3 as host controller, May I know have
> > > tested it
> > > with dwc3?
> > > I have tried it on Linux PC (x86 Ubuntu machine) I could not see the
> > > issue.
> > > It enumerates well.
> > 
> > Great, stick with an x86 platform!  :)
> > 
> > Looks like a dwc3 host controller issue, try enabling tracing and
> > debugging in that driver when this happens to see what is going on.
> 
> Oh if so let me enable the trace for that. I will respond you on this.
> 
> > Also look at all of the recent dwc3 patches that were just sent to Linus
> > for 4.17-rc1 to verify if that solves the issue.
> > 
> I do not have idea how I can get those patches. Could you please tell me?

Look at the git tree listed in the MAINTAINERS file.

> Is there any mailing list/link for this ?

Yes, this one (linux-usb@vger).  Also, all of the patches are in
the linux-next tree.

thanks,

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

Re: [PATCH v4] usb: dwc2: dwc2_vbus_supply_init: fix error check

[Tomeu Vizoso]

Could this patch be picked up, please?

Thanks,

Tomeu

On 26 March 2018 at 13:51, Heiko Stübner  wrote:
> Am Montag, 26. März 2018, 11:00:01 CEST schrieb Tomeu Vizoso:
>> devm_regulator_get_optional returns -ENODEV if the regulator isn't
>> there, so if that's the case we have to make sure not to leave -ENODEV
>> in the regulator pointer.
>>
>> Also, make sure we return 0 in that case, but correctly propagate any
>> other errors. Also propagate the error from _dwc2_hcd_start.
>>
>> Fixes: 531ef5ebea96 ("usb: dwc2: add support for host mode external vbus
>> supply") Cc: Amelie Delaunay 
>> Signed-off-by: Tomeu Vizoso 
>
> Reviewed-by: Heiko Stuebner 
--
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: Fwd: usb: uas: device reset most the time while enumeration- usb3.0

[tnimkar]

On 2018-04-04 18:07, Greg KH wrote:

On Wed, Apr 04, 2018 at 05:14:50PM +0530, tnim...@codeaurora.org wrote:

Hi Oliver/Greg,

I am able to duplicated the UAS issue on 4.16 as well.
The behavior is same new usb device detects and reset after aprox 30
sec(SD_TIMEOUT)
Logs are already shared below.

We are using Synopsys dwc3 as host controller, May I know have tested 
it

with dwc3?
I have tried it on Linux PC (x86 Ubuntu machine) I could not see the 
issue.

It enumerates well.


Great, stick with an x86 platform!  :)

Looks like a dwc3 host controller issue, try enabling tracing and
debugging in that driver when this happens to see what is going on.


Oh if so let me enable the trace for that. I will respond you on this.

Also look at all of the recent dwc3 patches that were just sent to 
Linus

for 4.17-rc1 to verify if that solves the issue.

I do not have idea how I can get those patches. Could you please tell 
me?

Is there any mailing list/link for this ?


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

--
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: Fwd: usb: uas: device reset most the time while enumeration- usb3.0

[Greg KH]

On Wed, Apr 04, 2018 at 05:14:50PM +0530, tnim...@codeaurora.org wrote:
> Hi Oliver/Greg,
> 
> I am able to duplicated the UAS issue on 4.16 as well.
> The behavior is same new usb device detects and reset after aprox 30
> sec(SD_TIMEOUT)
> Logs are already shared below.
> 
> We are using Synopsys dwc3 as host controller, May I know have tested it
> with dwc3?
> I have tried it on Linux PC (x86 Ubuntu machine) I could not see the issue.
> It enumerates well.

Great, stick with an x86 platform!  :)

Looks like a dwc3 host controller issue, try enabling tracing and
debugging in that driver when this happens to see what is going on.
Also look at all of the recent dwc3 patches that were just sent to Linus
for 4.17-rc1 to verify if that solves the issue.

thanks,

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

[PATCH] usb: select USB_COMMON for usb role switch config

[Arnd Bergmann]

The new axp288 extcon driver has no dependency on USB itself but
calls the usb role switch helper functions. This causes a link error
when USB_COMMON is disabled, as that subdirectory never gets entered:

drivers/extcon/extcon-axp288.o: In function `axp288_usb_role_work':
extcon-axp288.c:(.text+0x47b): undefined reference to `usb_role_switch_set_role'
extcon-axp288.c:(.text+0x498): undefined reference to `usb_role_switch_get_role'
drivers/extcon/extcon-axp288.o: In function `axp288_extcon_probe':
extcon-axp288.c:(.text+0x675): undefined reference to `usb_role_switch_get'
extcon-axp288.c:(.text+0x6d1): undefined reference to `usb_role_switch_put'
drivers/extcon/extcon-axp288.o: In function `axp288_put_role_sw':
extcon-axp288.c:(.text+0x1c): undefined reference to `usb_role_switch_put'

There are multiple ways of fixing this, I chose to 'select USB_COMMON',
since that is how we solved the same problem for other helpers like
USB_LED_TRIG or PHY drivers.

Fixes: d54f063cdbe4 ("extcon: axp288: Set USB role where necessary")
Signed-off-by: Arnd Bergmann 
---
 drivers/usb/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig
index 75f7fb151f71..987fc5ba6321 100644
--- a/drivers/usb/Kconfig
+++ b/drivers/usb/Kconfig
@@ -207,5 +207,6 @@ config USB_ULPI_BUS
 
 config USB_ROLE_SWITCH
tristate
+   select USB_COMMON
 
 endif # USB_SUPPORT
-- 
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: [usb-next PATCH v11 3/8] usb: core: add a wrapper for the USB PHYs on the HCD

[Masahiro Yamada]

2018-03-04 6:43 GMT+09:00 Martin Blumenstingl
:
> Many SoC platforms have separate devices for the USB PHY which are
> registered through the generic PHY framework. These PHYs have to be
> enabled to make the USB controller actually work. They also have to be
> disabled again on shutdown/suspend.
>
> Currently (at least) the following HCI platform drivers are using custom
> code to obtain all PHYs via devicetree for the roothub/controller and
> disable/enable them when required:
> - ehci-platform.c has ehci_platform_power_{on,off}
> - xhci-mtk.c has xhci_mtk_phy_{init,exit,power_on,power_off}
> - ohci-platform.c has ohci_platform_power_{on,off}
>
> With this new wrapper the USB PHYs can be specified directly in the
> USB controller's devicetree node (just like on the drivers listed
> above). This allows SoCs like the Amlogic Meson GXL family to operate
> correctly once this is wired up correctly. These SoCs use a dwc3
> controller and require all USB PHYs to be initialized (if one of the USB
> PHYs it not initialized then none of USB port works at all).
>
> Signed-off-by: Martin Blumenstingl 
> Tested-by: Yixun Lan 
> Cc: Neil Armstrong 
> Cc: Chunfeng Yun 
> ---
>  drivers/usb/core/Makefile |   2 +-
>  drivers/usb/core/phy.c| 158 
> ++
>  drivers/usb/core/phy.h|   7 ++
>  3 files changed, 166 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/usb/core/phy.c
>  create mode 100644 drivers/usb/core/phy.h
>
> diff --git a/drivers/usb/core/Makefile b/drivers/usb/core/Makefile
> index 92c9cefb4317..18e874b0441e 100644
> --- a/drivers/usb/core/Makefile
> +++ b/drivers/usb/core/Makefile
> @@ -6,7 +6,7 @@
>  usbcore-y := usb.o hub.o hcd.o urb.o message.o driver.o
>  usbcore-y += config.o file.o buffer.o sysfs.o endpoint.o
>  usbcore-y += devio.o notify.o generic.o quirks.o devices.o
> -usbcore-y += port.o
> +usbcore-y += phy.o port.o
>
>  usbcore-$(CONFIG_OF)   += of.o
>  usbcore-$(CONFIG_USB_PCI)  += hcd-pci.o
> diff --git a/drivers/usb/core/phy.c b/drivers/usb/core/phy.c
> new file mode 100644
> index ..09b7c43c0ea4
> --- /dev/null
> +++ b/drivers/usb/core/phy.c
> @@ -0,0 +1,158 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * A wrapper for multiple PHYs which passes all phy_* function calls to
> + * multiple (actual) PHY devices. This is comes handy when initializing
> + * all PHYs on a HCD and to keep them all in the same state.
> + *
> + * Copyright (C) 2018 Martin Blumenstingl 
> 
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "phy.h"
> +
> +struct usb_phy_roothub {
> +   struct phy  *phy;
> +   struct list_headlist;
> +};
> +
> +static struct usb_phy_roothub *usb_phy_roothub_alloc(struct device *dev)
> +{
> +   struct usb_phy_roothub *roothub_entry;
> +
> +   roothub_entry = devm_kzalloc(dev, sizeof(*roothub_entry), GFP_KERNEL);
> +   if (!roothub_entry)
> +   return ERR_PTR(-ENOMEM);
> +
> +   INIT_LIST_HEAD(_entry->list);
> +
> +   return roothub_entry;
> +}
> +
> +static int usb_phy_roothub_add_phy(struct device *dev, int index,
> +  struct list_head *list)
> +{
> +   struct usb_phy_roothub *roothub_entry;
> +   struct phy *phy = devm_of_phy_get_by_index(dev, dev->of_node, index);
> +
> +   if (IS_ERR_OR_NULL(phy)) {
> +   if (!phy || PTR_ERR(phy) == -ENODEV)
> +   return 0;
> +   else
> +   return PTR_ERR(phy);
> +   }
> +
> +   roothub_entry = usb_phy_roothub_alloc(dev);
> +   if (IS_ERR(roothub_entry))
> +   return PTR_ERR(roothub_entry);
> +
> +   roothub_entry->phy = phy;
> +
> +   list_add_tail(_entry->list, list);
> +
> +   return 0;
> +}
> +
> +struct usb_phy_roothub *usb_phy_roothub_init(struct device *dev)
> +{
> +   struct usb_phy_roothub *phy_roothub;
> +   struct usb_phy_roothub *roothub_entry;
> +   struct list_head *head;
> +   int i, num_phys, err;
> +
> +   num_phys = of_count_phandle_with_args(dev->of_node, "phys",
> + "#phy-cells");
> +   if (num_phys <= 0)
> +   return NULL;
> +
> +   phy_roothub = usb_phy_roothub_alloc(dev);
> +   if (IS_ERR(phy_roothub))
> +   return phy_roothub;
> +
> +   for (i = 0; i < num_phys; i++) {
> +   err = usb_phy_roothub_add_phy(dev, i, _roothub->list);
> +   if (err)
> +   goto err_out;
> +   }
> +
> +   head = _roothub->list;


I think phy_roothub->phy is always empty,
and only phy_roothub->list is used.


I just wondered if we can directly put 'struct list_head' into
'struct usb_hcd'.

Re: [PATCH v2 2/5] usb: typec: fusb302: remove max_snk_* for sink config

[Mats Karrman]

Hi Li,

On 2018-03-23 15:58, Li Jun wrote:


Since max_snk_* is to be deprecated, so remove max_snk_* by adding a
variable PDO for sink config.

Signed-off-by: Li Jun 
---
  drivers/usb/typec/fusb302/fusb302.c | 51 +++--
  1 file changed, 37 insertions(+), 14 deletions(-)

diff --git a/drivers/usb/typec/fusb302/fusb302.c 
b/drivers/usb/typec/fusb302/fusb302.c
index 7036171..db4d9cd 100644
--- a/drivers/usb/typec/fusb302/fusb302.c
+++ b/drivers/usb/typec/fusb302/fusb302.c
@@ -120,6 +120,7 @@ struct fusb302_chip {
enum typec_cc_polarity cc_polarity;
enum typec_cc_status cc1;
enum typec_cc_status cc2;
+   u32 snk_pdo[PDO_MAX_OBJECTS];
  
  #ifdef CONFIG_DEBUG_FS

struct dentry *dentry;
@@ -1212,11 +1213,6 @@ static const u32 snk_pdo[] = {
  static const struct tcpc_config fusb302_tcpc_config = {
.src_pdo = src_pdo,
.nr_src_pdo = ARRAY_SIZE(src_pdo),
-   .snk_pdo = snk_pdo,
-   .nr_snk_pdo = ARRAY_SIZE(snk_pdo),
-   .max_snk_mv = 5000,
-   .max_snk_ma = 3000,
-   .max_snk_mw = 15000,
.operating_snk_mw = 2500,
.type = TYPEC_PORT_DRP,
.data = TYPEC_PORT_DRD,
@@ -1756,6 +1752,38 @@ static int init_gpio(struct fusb302_chip *chip)
return 0;
  }
  
+static int fusb302_composite_snk_pdo_array(struct fusb302_chip *chip)

+{
+   struct device *dev = chip->dev;
+   u32 mv, ma, mw, min_mv;
+   unsigned int i;
+
+   /* Copy the static snk pdo */
+   for (i = 0; i < ARRAY_SIZE(snk_pdo); i++)
+   chip->snk_pdo[i] = snk_pdo[i];
+
+   if (device_property_read_u32(dev, "fcs,max-sink-microvolt", ) ||
+   device_property_read_u32(dev, "fcs,max-sink-microamp", ) ||
+   device_property_read_u32(dev, "fcs,max-sink-microwatt", ))
+   return i;
+
+   mv = mv / 1000;
+   ma = ma / 1000;
+   mw = mw / 1000;
+
+   min_mv = 1000 * chip->tcpc_config.operating_snk_mw / ma;
+   if (pdo_type(snk_pdo[i-1] == PDO_TYPE_FIXED))


You've got the parentheses wrong.

Apart from that I don't like/understand why the PDO's should be fixed.
Every product should be able to have its own settings, including the first PDO 
(e.g. it
might need to specify a higher current and/or set the "Higher Capability" bit).

I think this would be best solved the same way as in your TCPCI driver patch 
series [1]
with a list freely specified by a property.

[1] https://www.spinics.net/lists/linux-usb/msg167398.html


+   min_mv = max(min_mv, pdo_fixed_voltage(snk_pdo[i-1]));
+   else
+   min_mv = max(min_mv, pdo_max_voltage(snk_pdo[i-1]));
+   ma = min(ma, 1000 * mw / min_mv);
+
+   /* Insert the new pdo to the end */
+   chip->snk_pdo[i] = PDO_VAR(min_mv, mv, ma);
+
+   return i+1;
+}
+
  static int fusb302_probe(struct i2c_client *client,
 const struct i2c_device_id *id)
  {
@@ -1784,18 +1812,13 @@ static int fusb302_probe(struct i2c_client *client,
chip->tcpc_dev.config = >tcpc_config;
mutex_init(>lock);
  
-	if (!device_property_read_u32(dev, "fcs,max-sink-microvolt", ))

-   chip->tcpc_config.max_snk_mv = v / 1000;
-
-   if (!device_property_read_u32(dev, "fcs,max-sink-microamp", ))
-   chip->tcpc_config.max_snk_ma = v / 1000;
-
-   if (!device_property_read_u32(dev, "fcs,max-sink-microwatt", ))
-   chip->tcpc_config.max_snk_mw = v / 1000;
-
if (!device_property_read_u32(dev, "fcs,operating-sink-microwatt", ))
chip->tcpc_config.operating_snk_mw = v / 1000;
  
+	/* Composite sink PDO */

+   chip->tcpc_config.nr_snk_pdo = fusb302_composite_snk_pdo_array(chip);
+   chip->tcpc_config.snk_pdo = chip->snk_pdo;
+
/*
 * Devicetree platforms should get extcon via phandle (not yet
 * supported). On ACPI platforms, we get the name from a device prop.


--
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 -next] usb: dwc2: pci: Fix error return code in dwc2_pci_probe()

[Minas Harutyunyan]

On 3/30/2018 11:35 AM, Grigor Tovmasyan wrote:
> On 3/28/2018 5:36 PM, Wei Yongjun wrote:
>> Fix to return error code -ENOMEM from the alloc fail error handling
>> case instead of 0, as done elsewhere in this function.
>>
>> Fixes: ecd29dabb2ba ("usb: dwc2: pci: Handle error cleanup in probe")
>> Signed-off-by: Wei Yongjun 
> 
> Reviewed-by: Grigor Tovmasyan 

Acked-by: Minas Harutyunyan 
> 
>> ---
>>drivers/usb/dwc2/pci.c | 4 +++-
>>1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/usb/dwc2/pci.c b/drivers/usb/dwc2/pci.c
>> index 7f21747..bea2e8e 100644
>> --- a/drivers/usb/dwc2/pci.c
>> +++ b/drivers/usb/dwc2/pci.c
>> @@ -141,8 +141,10 @@ static int dwc2_pci_probe(struct pci_dev *pci,
>>  goto err;
>>
>>  glue = devm_kzalloc(dev, sizeof(*glue), GFP_KERNEL);
>> -if (!glue)
>> +if (!glue) {
>> +ret = -ENOMEM;
>>  goto err;
>> +}
>>
>>  ret = platform_device_add(dwc2);
>>  if (ret) {
>>
>> --
>> 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://urldefense.proofpoint.com/v2/url?u=http-3A__vger.kernel.org_majordomo-2Dinfo.html=DwICAw=DPL6_X_6JkXFx7AXWqB0tg=K1ULVL1slpLXpMJJlAXSOxws4tRq0IkTBqxDkyW2hUQ=6vLEHiNG2gKkx9F-l1Yy77Kde75g7qA8Aw3fKXaQgCI=rFkdkzcIhy-tbIL8_skjqNXbFvj1Iolbh9CZ4-LNt4U=
>>
> 
> 

--
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: Fwd: usb: uas: device reset most the time while enumeration- usb3.0

[tnimkar]

Hi Oliver/Greg,

I am able to duplicated the UAS issue on 4.16 as well.
The behavior is same new usb device detects and reset after aprox 30 
sec(SD_TIMEOUT)

Logs are already shared below.

We are using Synopsys dwc3 as host controller, May I know have tested it 
with dwc3?
I have tried it on Linux PC (x86 Ubuntu machine) I could not see the 
issue. It enumerates well.



Right now I have 2 UAS device and on both issue is duplicated.
1) StoreJet TS256GESD400K
2) Samsung  Portable SSD T3

Any input is helpful.

Best Regards,
Tushar R Nimkar
Mob No : +91-9052258800

QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a 
member of Code Aurora Forum, hosted by The Linux Foundation



On 2018-04-04 16:39, Tushar Nimkar wrote:

-- Forwarded message --

forwarding to codeaurora account...

From: Tushar Nimkar 
Date: Wed, Feb 7, 2018 at 8:48 PM
Subject: Re: usb: uas: device reset most the time while enumeration- 
usb3.0

To: Oliver Neukum 
Cc: Greg KH , linux-usb@vger.kernel.org

Oliver/Greg,
sorry to say but for my custom board it's difficult to flash 4.14 or
4.15. I are not sure that it will boot or not on my platform.
But Still i will try to do that and in parallel will try to flash on
Beagle bone.And will try.

 I used Lecroy today following are some observation..

working case :
for every try of ready_capacity_16 (total 3), there are bulk
transfer(OUT and IN) and status for read_capacity_16 is  "GOOD"

non-working case:
for first try of ready_capacity_16 there is bulk OUT but no IN
transfer , status for read_capacity_16 is "MISSING"
...seems that's that is the case we are receiving the
blk_rq_timed_out_timer() and eventually uas_eh_device_reset_handler()
I could not find why the bulk transfer could not  complete and causing
timer to expire.


Also  adding some msleep(100) before calling sd_read_capacity(), many
times i could not see the issue.

I don't know how to share Lecroy logs here. I can share the logs.

Best Regards,
Tushar R Nimkar
Mob No : +91-9052258800


On Tue, Feb 6, 2018 at 3:32 PM, Oliver Neukum  wrote:

Am Montag, den 05.02.2018, 23:46 +0530 schrieb Tushar Nimkar:

Greg,

I have cherry-picked 9 patches as follows.


Those won't do you any good. Please test

a) with 4.14 or 4.15
b) test on another host

And tell me what read_capacity_16() does at USB2.0 speeds

We need to determine whether error handling just works better
at lower speed or high speed triggers the error. And with
a current kernel if possible at all.

Regards
Oliver





From: Tushar Nimkar 
Date: Mon, Feb 5, 2018 at 11:46 PM
Subject: Re: usb: uas: device reset most the time while enumeration- 
usb3.0

To: Greg KH 
Cc: linux-usb@vger.kernel.org


Greg,

I have cherry-picked 9 patches as follows.


d921462 USB: uas and storage: Add US_FL_BROKEN_FUA for another JMicron 
JMS567 ID


d7321ce uas: Add US_FL_IGNORE_RESIDUE for Initio Corporation INIC-3069

b3568a9 uas: Always apply US_FL_NO_ATA_1X quirk to Seagate devices

66215a3 USB: uas: fix bug in handling of alternate settings

34ce628 scsi: uas: move eh_bus_reset_handler to eh_device_reset_handler

c5afd93 uas: remove can_queue set in host template

75b8da4 USB: uas: add full support for RESPONSE IU

befea02 uas: no gfp argument to uas_submit_urbs()

849b7c6 uas: use the BIT() macro




I will try and update the same if possible to duplicate this on 4.14.14 
or 4.15


On Mon, Feb 5, 2018 at 11:40 PM, Greg KH  
wrote:

On Mon, Feb 05, 2018 at 11:34:40PM +0530, Tushar Nimkar wrote:

Hi ,

I am enabling uas support. And facing the issue as follows.

I have observed that when ( Transcend StoreJet TS256GESD400K )
connected to my custom board,  it detects first then
uas_eh_abort_handler() get call and then reset and enumerates
properly.When same device is used with 2.0 HUB their is no such 
issue.



logs-->Super-speed

 [  323.912384] usb 2-1: new SuperSpeed USB device number 3 using 
xhci-hcd

[  323.947103] scsi host1: uas
[  323.948153] scsi 1:0:0:0: Direct-Access StoreJet TS256GESD400K
  0PQ: 0 ANSI: 6
[  323.949825] sd 1:0:0:0: [sda] 500118192 512-byte logical blocks:
(256 GB/238 GiB)
[  354.092341] sd 1:0:0:0: tag#0 uas_eh_abort_handler 0 uas-tag 1
inflight: CMD IN
[  354.092380] sd 1:0:0:0: tag#0 CDB: opcode=0x12 12 01 00 00 40 00
[  354.098922] scsi host1: uas_eh_device_reset_handler start
[  354.104963] xhci-hcd xhci-hcd.0.auto: ERROR Transfer event for
disabled endpoint or incorrect stream ring
[  354.110095] xhci-hcd xhci-hcd.0.auto: @7d41f750 
 1b00 01078001
[  354.232398] usb 2-1: reset SuperSpeed USB device number 3 using 
xhci-hcd

[  354.253844] scsi host1: uas_eh_device_reset_handler success
[  354.263222] sd 1:0:0:0: [sda] Write Protect is off
[  354.263461] sd 1:0:0:0: [sda] Write cache: enabled, read cache:

Re: Multiple generic PHY instances for DWC3 USB IP

[Masahiro Yamada]

Hi Arnd,

2018-04-04 17:43 GMT+09:00 Arnd Bergmann :
> On Wed, Apr 4, 2018 at 10:00 AM, Felipe Balbi
>  wrote:
>>
>> Hi,
>>
>> Masahiro Yamada  writes:
> Each DWC3 instance is connected with
> multiple HS PHYs and multiple SS PHYs,
> depending on the number of ports.

 in that case, you shouldn't need dwc3 at all. A Host-only dwc3 is xHCI
 compliant. If you really don't have the gadget block, there's no need
 for you to use dwc3. Just use xhci-plat directly.
>>>
>>> Sorry, I was misunderstanding.
>>>
>>> Some of our SoCs support gadget,
>>> so we need to use the dwc3 driver.
>>
>> fair enough. Now we need to figure out how to pass multiply PHYs to a
>> multi-port dwc3 instance.
>>
>> Kishon, any ideas? How do you think DT should look like?
>
> See this series from Martin Blumenstingl:
>
> https://www.spinics.net/lists/linux-usb/msg166281.html
>
>   Arnd


Very useful information!

Not tested yet, but I quickly reviewed the series visually,
and probably this will work for us.

Thanks!


-- 
Best Regards
Masahiro Yamada
--
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/PHY driver patches for 4.17-rc1

[Greg KH]

The following changes since commit c698ca5278934c0ae32297a8725ced2e27585d7f:

  Linux 4.16-rc6 (2018-03-18 17:48:42 -0700)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/ 
tags/usb-4.17-rc1

for you to fetch changes up to 5267c5e09c25e2ee6242b37833a9bdf9d97f54a2:

  Revert "USB: serial: ftdi_sio: add Id for Physik Instrumente E-870" 
(2018-03-29 18:37:28 +0200)


USB/PHY patches for 4.17-rc1

Here is the big set of USB and PHY driver patches for 4.17-rc1.

Lots of USB typeC work happened this round, with code moving from the
staging directory into the "real" part of the kernel, as well as new
infrastructure being added to be able to handle the different types of
"roles" that typeC requires.

There is also the normal huge set of USB gadget controller and driver
updates, along with XHCI changes, and a raft of other tiny fixes all
over the USB tree.  And the PHY driver updates are merged in here as
well as they interacted with the USB drivers in some places.

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

Signed-off-by: Greg Kroah-Hartman 


Adam Thomson (3):
  typec: tcpm: Add PD Rev 3.0 definitions to PD header
  typec: tcpm: Add ADO header for Alert message handling
  typec: tcpm: Add SDB header for Status message handling

Alban Bedel (1):
  usb: host: Remove the deprecated ATH79 USB host config options

Alex Hung (1):
  usb: clarify ACPI spec version and section number for _UPC & _PLD

Alexander Monakov (1):
  phy: berlin-usb: adjust USB_PHY_RX_CTRL init flags

Alexey Khoroshilov (1):
  phy: lpc18xx-usb-otg: error handling in lpc18xx_usb_otg_phy_power_on()

Amelie Delaunay (3):
  usb: dwc2: add support for host mode external vbus supply
  dt-bindings: phy: add support for STM32 USB PHY Controller (USBPHYC)
  phy: stm32: add support for STM32 USB PHY Controller (USBPHYC)

Andy Shevchenko (19):
  USB: dwc2: Re-use DEFINE_SHOW_ATTRIBUTE() macro
  USB: gadget: bcm63xx: Re-use DEFINE_SHOW_ATTRIBUTE() macro
  USB: gadget: gr: Re-use DEFINE_SHOW_ATTRIBUTE() macro
  USB: gadget: pxa25x: Re-use DEFINE_SHOW_ATTRIBUTE() macro
  USB: gadget: pxa27x: Re-use DEFINE_SHOW_ATTRIBUTE() macro
  USB: chipidea: Re-use DEFINE_SHOW_ATTRIBUTE() macro
  USB: dwc2: Re-use DEFINE_SHOW_ATTRIBUTE() macro
  USB: musb: Re-use DEFINE_SHOW_ATTRIBUTE() macro
  USB: gadget: bcm63xx: Re-use DEFINE_SHOW_ATTRIBUTE() macro
  USB: gadget: gr: Re-use DEFINE_SHOW_ATTRIBUTE() macro
  USB: gadget: pxa25x: Re-use DEFINE_SHOW_ATTRIBUTE() macro
  USB: gadget: pxa27x: Re-use DEFINE_SHOW_ATTRIBUTE() macro
  USB: host: fhci: Re-use DEFINE_SHOW_ATTRIBUTE() macro
  USB: host: imx21: Re-use DEFINE_SHOW_ATTRIBUTE() macro
  USB: host: isp116x: Re-use DEFINE_SHOW_ATTRIBUTE() macro
  USB: host: whci: Re-use DEFINE_SHOW_ATTRIBUTE() macro
  USB: typec: Re-use DEFINE_SHOW_ATTRIBUTE() macro
  uwb: Re-use DEFINE_SHOW_ATTRIBUTE() macro
  USB: host: sl811: Re-use DEFINE_SHOW_ATTRIBUTE() macro

Ben Hutchings (1):
  usbip: Correct maximum value of CONFIG_USBIP_VHCI_HC_PORTS

Benjamin Herrenschmidt (1):
  usb/gadget: Add an EP dispose() callback for EP lifetime tracking

Benson Leung (1):
  USB: announce bcdDevice as well as idVendor, idProduct.

Chen-Yu Tsai (1):
  phy: allwinner: sun4i-usb: poll vbus changes on A23/A33 when driving VBUS

Chris Dickens (2):
  usb: gadget: composite: fix incorrect handling of OS desc requests
  usb: gadget: composite: remove duplicated code in OS desc handling

Chris Zhong (2):
  phy: rockchip-typec: force to USB2 if DP at 4 lanes mode
  phy: rockchip-typec: support DP phy switch

Chunfeng Yun (4):
  phy: phy-mtk-tphy: keep default value of mcu_bus_ck_gate_en
  phy: phy-mtk-tphy: add configurable parameters for slew rate calibrate
  dt-bindings: phy-mtk-tphy: add properties for U2 slew rate calibrate
  usb: skip phys initialization of shared hcd

Clemens Werther (1):
  USB: serial: ftdi_sio: add support for Harman FirmwareHubEmulator

Colin Ian King (4):
  phy: tegra: remove redundant self assignment of 'map'
  USB: gadget: function: remove redundant initialization of 'tv_nexus'
  USB: wusbcore: remove redundant re-assignment to pointer 'dev'
  usb: dwc2: fix spelling mistake: "genereted" -> "generated"

Dan Carpenter (1):
  usb: xhci: Clean up error code in xhci_dbc_tty_register_device()

Daniel Gimpelevich (1):
  USB: misc: uss720: more vendor/product ID's

Dmitry Osipenko (1):
  usb: phy: tegra: Increase PHY clock stabilization timeout

Dov Levenglick (1):
  phy: fix structure documentation

Enric Balletbo i Serra (4):
  phy: rockchip-typec: deprecate some DT properties for various register 

Re: Multiple generic PHY instances for DWC3 USB IP

[Arnd Bergmann]

On Wed, Apr 4, 2018 at 10:00 AM, Felipe Balbi
 wrote:
>
> Hi,
>
> Masahiro Yamada  writes:
 Each DWC3 instance is connected with
 multiple HS PHYs and multiple SS PHYs,
 depending on the number of ports.
>>>
>>> in that case, you shouldn't need dwc3 at all. A Host-only dwc3 is xHCI
>>> compliant. If you really don't have the gadget block, there's no need
>>> for you to use dwc3. Just use xhci-plat directly.
>>
>> Sorry, I was misunderstanding.
>>
>> Some of our SoCs support gadget,
>> so we need to use the dwc3 driver.
>
> fair enough. Now we need to figure out how to pass multiply PHYs to a
> multi-port dwc3 instance.
>
> Kishon, any ideas? How do you think DT should look like?

See this series from Martin Blumenstingl:

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

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

Re: [PATCH] usbip: vhc_hcd: prevent module being removed while device are attached

[Oliver Neukum]

Am Dienstag, den 03.04.2018, 09:56 -0600 schrieb Shuah Khan:
> This is a virtual device associated to a real physical device on a different
> system. My concern is that if the module gets removed accidentally then it
> could disrupt access to the remote device. The remote nature of the device
> with several players involved makes this scenario a bit more complex than

Hi,

you would doubtlessly lose connection to that device. Yet you would
also lose connections if you down your network. You need to be root
to unload a module. You could overwrite your root filesystems or flash
your firmware. In general we cannot and don't try to protect root
from such accidents.

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] usb: dwc3: of-simple: use managed and shared reset control

[Philipp Zabel]

On Wed, 2018-04-04 at 10:25 +0900, Masahiro Yamada wrote:
> 2018-04-03 19:35 GMT+09:00 Vivek Gautam :
> > 
> > 
> > On 4/3/2018 3:49 PM, Masahiro Yamada wrote:
> > > 
> > > 2018-04-03 17:46 GMT+09:00 Philipp Zabel :
> > > > 
> > > > On Tue, 2018-04-03 at 17:30 +0900, Masahiro Yamada wrote:
> > > > > 
> > > > > 2018-04-03 17:00 GMT+09:00 Philipp Zabel :
> > > > > > 
> > > > > > On Thu, 2018-03-29 at 15:07 +0900, Masahiro Yamada wrote:
> > > > > > > 
> > > > > > > This driver handles the reset control in a common manner; deassert
> > > > > > > resets before use, assert them after use.  There is no good reason
> > > > > > > why it should be exclusive.
> > > > > > 
> > > > > > Is this preemptive cleanup, or do you have hardware on the horizon 
> > > > > > that
> > > > > > shares these reset lines with other peripherals?
> > > > > 
> > > > > This patch is necessary for Socionext SoCs.
> > > > > 
> > > > > The same reset lines are shared between
> > > > > this dwc3-of_simple and other glue circuits.
> > > > 
> > > > Thanks, this is helpful information.
> > > > 
> > > > > > > Also, use devm_ for clean-up.
> > > > > > > 
> > > > > > > Signed-off-by: Masahiro Yamada 
> > > > > > > ---
> > > > > > > 
> > > > > > > CCing Philipp Zabel.
> > > > > > > I see his sob in commit 06c47e6286d5.
> > > > > > 
> > > > > > At the time I was concerned with the reset_control_array addition 
> > > > > > and
> > > > > > didn't look closely at the exclusive vs shared issue.
> > > > > > > 
> > > > > > >   drivers/usb/dwc3/dwc3-of-simple.c | 7 ++-
> > > > > > >   1 file changed, 2 insertions(+), 5 deletions(-)
> > > > > > > 
> > > > > > > diff --git a/drivers/usb/dwc3/dwc3-of-simple.c
> > > > > > > b/drivers/usb/dwc3/dwc3-of-simple.c
> > > > > > > index e54c362..bd6ab65 100644
> > > > > > > --- a/drivers/usb/dwc3/dwc3-of-simple.c
> > > > > > > +++ b/drivers/usb/dwc3/dwc3-of-simple.c
> > > > > > > @@ -91,7 +91,7 @@ static int dwc3_of_simple_probe(struct
> > > > > > > platform_device *pdev)
> > > > > > >platform_set_drvdata(pdev, simple);
> > > > > > >simple->dev = dev;
> > > > > > > 
> > > > > > > - simple->resets =
> > > > > > > of_reset_control_array_get_optional_exclusive(np);
> > > > > > > + simple->resets =
> > > > > > > devm_reset_control_array_get_optional_shared(dev);
> > > > > > 
> > > > > >  From the usage in the driver, it does indeed look like _shared 
> > > > > > reset
> > > > > > usage is appropriate. I assume that the hardware has no need for the
> > > > > > reset to be asserted right before probe or after remove, it just
> > > > > > requires that the reset line is kept deasserted while the driver is
> > > > > > probed.
> > > > > > 
> > > > > > >if (IS_ERR(simple->resets)) {
> > > > > > >ret = PTR_ERR(simple->resets);
> > > > > > >dev_err(dev, "failed to get device resets, 
> > > > > > > err=%d\n",
> > > > > > > ret);
> > > > > > > @@ -100,7 +100,7 @@ static int dwc3_of_simple_probe(struct
> > > > > > > platform_device *pdev)
> > > > > > > 
> > > > > > >ret = reset_control_deassert(simple->resets);
> > > > > > >if (ret)
> > > > > > > - goto err_resetc_put;
> > > > > > > + return ret;
> > > > > > > 
> > > > > > >ret = dwc3_of_simple_clk_init(simple,
> > > > > > > of_count_phandle_with_args(np,
> > > > > > >"clocks",
> > > > > > > "#clock-cells"));
> > > > > > > @@ -126,8 +126,6 @@ static int dwc3_of_simple_probe(struct
> > > > > > > platform_device *pdev)
> > > > > > >   err_resetc_assert:
> > > > > > >reset_control_assert(simple->resets);
> > > > > > > 
> > > > > > > -err_resetc_put:
> > > > > > > - reset_control_put(simple->resets);
> > > > > > >return ret;
> > > > > > >   }
> > > > > > > 
> > > > > > > @@ -146,7 +144,6 @@ static int dwc3_of_simple_remove(struct
> > > > > > > platform_device *pdev)
> > > > > > >simple->num_clocks = 0;
> > > > > > > 
> > > > > > >reset_control_assert(simple->resets);
> > > > > > > - reset_control_put(simple->resets);
> > > > > > > 
> > > > > > >pm_runtime_put_sync(dev);
> > > > > > >pm_runtime_disable(dev);
> > > > > > 
> > > > > > Changing to devm_ changes the order here. Whether or not it could 
> > > > > > be a
> > > > > > problem to assert the reset only after pm_runtime_put (or 
> > > > > > potentially
> > > > > > never), I can't say. I assume this is a non-issue, but somebody who
> > > > > > knows the hardware better would have to decide.
> > > > > 
> > > > > 
> > > > > 
> > > > > I do not understand what you mean.
> > > > 
> > > > Sorry for the confusion, I have mixed up things here.
> > > > 
> > > > > Can you describe your concern in more details?
> > > > > 
> > > > > I am not touching reset_control_assert() here.
> > > > 
> > > > With the change to shared 

Re: Multiple generic PHY instances for DWC3 USB IP

[Felipe Balbi]

Hi,

Masahiro Yamada  writes:
>>> Each DWC3 instance is connected with
>>> multiple HS PHYs and multiple SS PHYs,
>>> depending on the number of ports.
>>
>> in that case, you shouldn't need dwc3 at all. A Host-only dwc3 is xHCI
>> compliant. If you really don't have the gadget block, there's no need
>> for you to use dwc3. Just use xhci-plat directly.
>
> Sorry, I was misunderstanding.
>
> Some of our SoCs support gadget,
> so we need to use the dwc3 driver.

fair enough. Now we need to figure out how to pass multiply PHYs to a
multi-port dwc3 instance.

Kishon, any ideas? How do you think DT should look like?

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

Re: [PATCH] Driver for MaxLinear/Exar USB (UART) Serial adapters.

[Greg KH]

On Wed, Apr 04, 2018 at 12:06:34AM -0700, Patong Yang wrote:
> - When specific IOCTLs are called by a user-space application, a 
>   port_config file is created for the /dev/ttyXRUSB device at a
>   specific USB tree location, and some configuration data is stored. 
>   The driver checks for the port_config file when the driver is loaded
>   for each port and loads the configuration settings if there is a
>   port_config file for the USB tree location.

Custom IOCTLS on a USB serial driver are not ok, sorry.  Please use the
standard ioctls and userspace apis for setting up and handling
configuration of your device.

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] Driver for MaxLinear/Exar USB (UART) Serial adapters.

[Greg KH]

On Wed, Apr 04, 2018 at 12:06:34AM -0700, Patong Yang wrote:
> The driver is based on the CDC-ACM driver. In addition to supporting 
> the features of the MaxLinear/Exar USB UART devices, the driver also 
> has support for 2 other functions per customer requirements:
> 
> - Specific entries are checked in the BIOS to detect if the board is a
>   "Caracalla" board before enabling specific modes in the MaxLinear/Exar
>   USB UARTs.  The smbios code is based on the example at:
>   https://sourceforge.net/projects/smbios/
> 
> - When specific IOCTLs are called by a user-space application, a 
>   port_config file is created for the /dev/ttyXRUSB device at a
>   specific USB tree location, and some configuration data is stored. 
>   The driver checks for the port_config file when the driver is loaded
>   for each port and loads the configuration settings if there is a
>   port_config file for the USB tree location.
> 
> Signed-off-by: Patong Yang 
> ---
>  drivers/usb/serial/xrusb_serial.c | 3285 
> +
>  drivers/usb/serial/xrusb_serial.h |  448 +
>  2 files changed, 3733 insertions(+)
>  create mode 100644 drivers/usb/serial/xrusb_serial.c
>  create mode 100644 drivers/usb/serial/xrusb_serial.h
> 
> diff --git a/drivers/usb/serial/xrusb_serial.c 
> b/drivers/usb/serial/xrusb_serial.c
> new file mode 100644
> index ..16a5bcff9103
> --- /dev/null
> +++ b/drivers/usb/serial/xrusb_serial.c
> @@ -0,0 +1,3285 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * xrusb_serial.c
> + *
> + * Copyright (c) 2018 Patong Yang 
> + *
> + * USB Serial Driver based on the cdc-acm.c driver for the
> + * MaxLinear/Exar USB UARTs/Serial adapters
> + */
> +
> +
> +#undef DEBUG
> +#undef VERBOSE_DEBUG

No need for these #undef in the driver.

And as Oliver points out, why does this have to be a totally different
driver?  And putting SMBIOS calls in a USB driver is very strange, can't
the USB devices describe themselves properly?

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] Driver for MaxLinear/Exar USB (UART) Serial adapters.

[Oliver Neukum]

Am Mittwoch, den 04.04.2018, 00:06 -0700 schrieb Patong Yang:
> The driver is based on the CDC-ACM driver. In addition to supporting 
> the features of the MaxLinear/Exar USB UART devices, the driver also 

Hi,

it is rather drastic a measure to duplicate a driver just for a low
number of devices. It makes fixing bugs double the work. At a minimum,
before we look at the code itself, could you please explain why

a) the code cannot be added to cdc-acm?
b) the check for SMBIOS is needed?

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: Multiple generic PHY instances for DWC3 USB IP

[Masahiro Yamada]

2018-04-04 15:04 GMT+09:00 Felipe Balbi :
>
> Hi,
>
> Masahiro Yamada  writes:
>> 2018-04-04 14:36 GMT+09:00 Felipe Balbi :
>>>
>>> Hi,
>>>
>>> Masahiro Yamada  writes:
 Currently, DWC3 core IP (drivers/usb/dwc3/core.c)
 can take only one PHY phandle for each of SS, HS.
 (phy-names DT property is "usb2-phy" and "usb3-phy" for each)
>>>
>>> We never had any other requirements :-)
>>>
 The DWC3 core IP is provided by Synopsys,
 but some SoC-dependent parts (a.k.a glue-layer)
 are implemented by SoC venders.

 The number of connected PHY instances are SoC-dependent.

 If you look at generic drivers such as
   drivers/usb/host/ehci-platform.c
 the driver can handle arbitrary number of PHY instances.

 However, as mentioned above, DWC3 core allows only one PHY phandle
 for each SS/HS.
 This can result in a strange DT structure.

 For example, Socionext PXs3 SoC is integrated with 2 instances of DWC3.

 The instance 0 of DWC3 is connected with 2 super-speed PHYs.
>>>
>>> why 2 super-speed phys? Is this a two-port host-only implementation?
>>
>>
>> Socionext SoCs only support the host-mode.
>>
>>
>> The instance 0 has 2 ports.
>> In our integration, 1 SS PHY is needed for each port.
>> That's why it needs 2 SS PHYs.
>>
>> Each DWC3 instance is connected with
>> multiple HS PHYs and multiple SS PHYs,
>> depending on the number of ports.
>
> in that case, you shouldn't need dwc3 at all. A Host-only dwc3 is xHCI
> compliant. If you really don't have the gadget block, there's no need
> for you to use dwc3. Just use xhci-plat directly.

Sorry, I was misunderstanding.

Some of our SoCs support gadget,
so we need to use the dwc3 driver.


 Is this OK?
>>>
>>> I don't know, I need a bit more details about your integration :-)
>>
>>
>> I can send a patch.
>>
>> My concern is the following commit.
>> I do not know which parts are using this lookups.
>
> Samsung SoCs, probably ;-)
>
> Anyway, if your IP really is host-only, then you don't need dwc3 for
> anything. Just go for xHCI directly. If xHCI needs to be extended when
> it comes to PHY, then you can discuss with Mathias Nyman :-)
>
> --
> balbi



-- 
Best Regards
Masahiro Yamada
--
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] Driver for MaxLinear/Exar USB (UART) Serial adapters.

[Patong Yang]

The driver is based on the CDC-ACM driver. In addition to supporting 
the features of the MaxLinear/Exar USB UART devices, the driver also 
has support for 2 other functions per customer requirements:

- Specific entries are checked in the BIOS to detect if the board is a
  "Caracalla" board before enabling specific modes in the MaxLinear/Exar
  USB UARTs.  The smbios code is based on the example at:
  https://sourceforge.net/projects/smbios/

- When specific IOCTLs are called by a user-space application, a 
  port_config file is created for the /dev/ttyXRUSB device at a
  specific USB tree location, and some configuration data is stored. 
  The driver checks for the port_config file when the driver is loaded
  for each port and loads the configuration settings if there is a
  port_config file for the USB tree location.

Signed-off-by: Patong Yang 
---
 drivers/usb/serial/xrusb_serial.c | 3285 +
 drivers/usb/serial/xrusb_serial.h |  448 +
 2 files changed, 3733 insertions(+)
 create mode 100644 drivers/usb/serial/xrusb_serial.c
 create mode 100644 drivers/usb/serial/xrusb_serial.h

diff --git a/drivers/usb/serial/xrusb_serial.c 
b/drivers/usb/serial/xrusb_serial.c
new file mode 100644
index ..16a5bcff9103
--- /dev/null
+++ b/drivers/usb/serial/xrusb_serial.c
@@ -0,0 +1,3285 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * xrusb_serial.c
+ *
+ * Copyright (c) 2018 Patong Yang 
+ *
+ * USB Serial Driver based on the cdc-acm.c driver for the
+ * MaxLinear/Exar USB UARTs/Serial adapters
+ */
+
+
+#undef DEBUG
+#undef VERBOSE_DEBUG
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "linux/version.h"
+#include "xrusb_serial.h"
+
+#define DRIVER_AUTHOR "Patong Yang "
+#define DRIVER_DESC "MaxLinear/Exar USB UART (serial port) driver"
+
+static struct usb_driver xrusb_driver;
+static struct tty_driver *xrusb_tty_driver;
+static struct xrusb *xrusb_table[XRUSB_TTY_MINORS];
+static struct file *port_param_file[32];
+static struct reg_addr_map xr2280x_reg_map;
+static struct reg_addr_map xr21b1411_reg_map;
+static struct reg_addr_map xr21v141x_reg_map;
+static struct reg_addr_map xr21b142x_reg_map;
+
+static DEFINE_MUTEX(xrusb_table_lock);
+
+/*
+ * SMBIOS code snippets below borrowed from
+ * https://sourceforge.net/projects/smbios/
+ *
+ * Checking SMBIOS values to determine if this is Caracalla board
+ * where modes are programmed in the BIOS
+ *
+ */
+
+unsigned char smbios_check_entry_point (void *addr)
+{
+   unsigned char *i;
+   unsigned char checksum = 0;
+   unsigned char length;
+
+   length = ((struct smbios_entry_point_struct *) addr)->
+   entry_point_length;
+   /* calculate checksum for entry point structure (should be 0) */
+   for (i = (unsigned char *) addr;
+   i < (unsigned char *) addr + length; i++)
+   checksum += *i;
+   return checksum;
+}
+
+struct smbios_entry_point_struct *smbios_find_entry_point (void *base)
+{
+   struct smbios_entry_point_struct *entry_point = 0;
+   unsigned int *temp;
+
+   /* search for the magic dword on paragraph boundaries */
+   for (temp = base;
+   !entry_point && temp < (unsigned int *) base + BIOS_MAP_LENGTH;
+   temp += 4) {
+
+   if (*temp == SMBIOS_MAGIC_DWORD) {
+   /* check if entry point valid (build checksum) */
+   if (!(smbios_check_entry_point (temp))) {
+   entry_point = (struct
+   smbios_entry_point_struct *) temp;
+
+   // fix display of Bios version string
+   // SMBios version is known as 2.1, 2.2,
+   // 2.3 and 2.3.1, never as 2.01 (JB)
+   SM_BIOS_DEBUG("SM-BIOS V%d.%d entry point ",
+   entry_point->major_version,
+   entry_point->minor_version);
+   SM_BIOS_DEBUG("found at 0x%x\n",
+   (unsigned int) temp);
+   }
+   }
+   }
+   return entry_point;
+}
+
+int smbios_check_caracalla_config(unsigned char *config0,
+   unsigned char *config1)
+{
+
+   int i;
+   int result = -1;
+   unsigned char *p;
+
+   smbios_base = ioremap(BIOS_START_ADDRESS, BIOS_MAP_LENGTH);
+
+   if (!smbios_base) {
+   SM_BIOS_DEBUG("ioremap() for entry point failed\n");
+   result = -ENXIO;
+   return result;
+   }
+
+   smbios_entry_point = 

Re: [PATCH 0/2] usb: dwc2: gadget: Fixes for LPM

[Grigor Tovmasyan]

He Stefan

On 4/3/2018 8:09 PM, Stefan Wahren wrote:
> Hi Grigor,
> 
> Am 03.04.2018 um 13:21 schrieb Grigor Tovmasyan:
>> Here are two little fixes for LPM feature.
>>
>> First one is coverity warning fix.
>>
>> The Second one was asserted by Stefan Wahren.
> 
> AFAIK Minas Harutyunyan is the new maintainer of dwc2. So this series
> should go to him.
> 
> Regards
> Stefan
> 
Thanks you. Me and Minas working in the same place.
The script which I used to create patches for kernel are using 
MAINTAINER file. In that file the maintainer is still John.

I forgot to change it manually.

BR,
Grigor.
>>
>>
>> Grigor Tovmasyan (2):
>> usb: dwc2: gadget: Fix coverity issue
>> usb: dwc2: gadget: Change default values
>>
>>drivers/usb/dwc2/params.c | 10 +-
>>1 file changed, 5 insertions(+), 5 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: Multiple generic PHY instances for DWC3 USB IP

[Felipe Balbi]

Hi,

Masahiro Yamada  writes:
> 2018-04-04 14:36 GMT+09:00 Felipe Balbi :
>>
>> Hi,
>>
>> Masahiro Yamada  writes:
>>> Currently, DWC3 core IP (drivers/usb/dwc3/core.c)
>>> can take only one PHY phandle for each of SS, HS.
>>> (phy-names DT property is "usb2-phy" and "usb3-phy" for each)
>>
>> We never had any other requirements :-)
>>
>>> The DWC3 core IP is provided by Synopsys,
>>> but some SoC-dependent parts (a.k.a glue-layer)
>>> are implemented by SoC venders.
>>>
>>> The number of connected PHY instances are SoC-dependent.
>>>
>>> If you look at generic drivers such as
>>>   drivers/usb/host/ehci-platform.c
>>> the driver can handle arbitrary number of PHY instances.
>>>
>>> However, as mentioned above, DWC3 core allows only one PHY phandle
>>> for each SS/HS.
>>> This can result in a strange DT structure.
>>>
>>> For example, Socionext PXs3 SoC is integrated with 2 instances of DWC3.
>>>
>>> The instance 0 of DWC3 is connected with 2 super-speed PHYs.
>>
>> why 2 super-speed phys? Is this a two-port host-only implementation?
>
>
> Socionext SoCs only support the host-mode.
>
>
> The instance 0 has 2 ports.
> In our integration, 1 SS PHY is needed for each port.
> That's why it needs 2 SS PHYs.
>
> Each DWC3 instance is connected with
> multiple HS PHYs and multiple SS PHYs,
> depending on the number of ports.

in that case, you shouldn't need dwc3 at all. A Host-only dwc3 is xHCI
compliant. If you really don't have the gadget block, there's no need
for you to use dwc3. Just use xhci-plat directly.

>>> Is this OK?
>>
>> I don't know, I need a bit more details about your integration :-)
>
>
> I can send a patch.
>
> My concern is the following commit.
> I do not know which parts are using this lookups.

Samsung SoCs, probably ;-)

Anyway, if your IP really is host-only, then you don't need dwc3 for
anything. Just go for xHCI directly. If xHCI needs to be extended when
it comes to PHY, then you can discuss with Mathias Nyman :-)

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