Re: [PATCH v2] xhci: Fix front USB ports on ASUS PRIME B350M-A

2018-03-06 Thread Kai Heng Feng 

Hi Matthias,

Do you have any concern about this patch?

Hopefully this can get merged for v4.16…

Kai-Heng
--
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 v5 0/6] dt-bindings: add bindings for USB physical connector

2018-03-06 Thread Chanwoo Choi 
On 2018년 03월 07일 11:12, Chanwoo Choi wrote:
> Hi Rob and Andrzej,
> 
> On 2018년 03월 06일 21:53, Andrzej Hajda wrote:
>> Hi Rob, Chanwoo, Krzysztof,
>>
>>
>> On 27.02.2018 08:11, Andrzej Hajda wrote:
>>> Hi,
>>>
>>> Thanks for reviews of previous iterations.
>>>
>>> This patchset introduces USB physical connector bindings, together with
>>> working example.
>>> I have removed RFC prefix - the patchset seems to be heading
>>> to a happy end :)
>>>
>>> v5: fixed extra parenthesis in dts, renamed extcon function.
>>> v4: improved binding descriptions, added missing reg in dts.
>>> v3: Separate binding for Samsung 11-pin connector, added full-blown USB-C
>>> example.
>>> v2: I have addressed comments by Rob and Laurent, thanks 
>>>
>>> Changes in datail are described in the patches.
>>>
>>> Regards
>>> Andrzej
>>>
>>>
>>> Andrzej Hajda (5):
>>>   dt-bindings: add bindings for USB physical connector
>>>   dt-bindings: add bindings for Samsung micro-USB 11-pin connector
>>>   arm64: dts: exynos: add micro-USB connector node to TM2 platforms
>>>   arm64: dts: exynos: add OF graph between MHL and USB connector
>>>   extcon: add possibility to get extcon device by OF node
>>>
>>> Maciej Purski (1):
>>>   drm/bridge/sii8620: use micro-USB cable detection logic to detect MHL
>>
>> It looks like all patches received R-B or acks (I forgot add Krzysztof's
>> acks for dts part).
>> Now I have a question how to merge them.
>> The only functional dependency is between bridge and extcon, and from
>> the formal PoV bindings should be merged 1st.
>> I can merge it:
>> 1. All patches via drm-misc tree.
>> 2. All patches except dts via drm-misc, and Krzysztof will merge dts via
>> samsung-soc tree.
>>
>> Is it OK, for all? Better ideas?
> 
> Krzysztof picked the dts patches. I'll make the immutable branch based on 
> v4.16-rc1
> and apply them except for dts patchs. And I'll send the immutable branch to 
> Rob and Andrzej.
> 
> 

I made the immutable branch[1] as following: If you agree, I'll send pull 
request.
[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon.git/log/?h=ib-extcon-drm-dt-v4.17

Or you can make the immutable branch and send pull request to Rob and me.

-- 
Best Regards,
Chanwoo Choi
Samsung Electronics
--
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 v5 0/6] dt-bindings: add bindings for USB physical connector

2018-03-06 Thread Chanwoo Choi 
Hi Rob and Andrzej,

On 2018년 03월 06일 21:53, Andrzej Hajda wrote:
> Hi Rob, Chanwoo, Krzysztof,
> 
> 
> On 27.02.2018 08:11, Andrzej Hajda wrote:
>> Hi,
>>
>> Thanks for reviews of previous iterations.
>>
>> This patchset introduces USB physical connector bindings, together with
>> working example.
>> I have removed RFC prefix - the patchset seems to be heading
>> to a happy end :)
>>
>> v5: fixed extra parenthesis in dts, renamed extcon function.
>> v4: improved binding descriptions, added missing reg in dts.
>> v3: Separate binding for Samsung 11-pin connector, added full-blown USB-C
>> example.
>> v2: I have addressed comments by Rob and Laurent, thanks 
>>
>> Changes in datail are described in the patches.
>>
>> Regards
>> Andrzej
>>
>>
>> Andrzej Hajda (5):
>>   dt-bindings: add bindings for USB physical connector
>>   dt-bindings: add bindings for Samsung micro-USB 11-pin connector
>>   arm64: dts: exynos: add micro-USB connector node to TM2 platforms
>>   arm64: dts: exynos: add OF graph between MHL and USB connector
>>   extcon: add possibility to get extcon device by OF node
>>
>> Maciej Purski (1):
>>   drm/bridge/sii8620: use micro-USB cable detection logic to detect MHL
> 
> It looks like all patches received R-B or acks (I forgot add Krzysztof's
> acks for dts part).
> Now I have a question how to merge them.
> The only functional dependency is between bridge and extcon, and from
> the formal PoV bindings should be merged 1st.
> I can merge it:
> 1. All patches via drm-misc tree.
> 2. All patches except dts via drm-misc, and Krzysztof will merge dts via
> samsung-soc tree.
> 
> Is it OK, for all? Better ideas?

Krzysztof picked the dts patches. I'll make the immutable branch based on 
v4.16-rc1
and apply them except for dts patchs. And I'll send the immutable branch to Rob 
and Andrzej.


-- 
Best Regards,
Chanwoo Choi
Samsung Electronics
--
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: [PATH 0/4] usbip: make vhci_hcd.* objects independent of vhci_hcd.0

2018-03-06 Thread Shuah Khan 
On 03/06/2018 01:35 AM, Salvador Fandiño wrote:
> 
> 
> On 03/06/2018 01:03 AM, Shuah Khan wrote:
>> On 03/05/2018 02:00 AM, Salvador Fandiño wrote:
>>> On 02/21/2018 01:35 AM, Shuah Khan wrote:
 Hi Salvador,

 On 01/30/2018 01:36 AM, Salvador Fandino wrote:
> Let me start by explaining the problem that have motivated me to write
> this patches:
>
> I work on the QVD, a virtual desktop platform for Linux. This software
> runs Linux desktops (i.e. XFCE, KDE) and their applications inside LXC
> containers, and makes then available through the network to remote
> users.
>
> Supporting USB devices is a common feature customers have been
> requesting us for a long time (in order to use, for instance, remote
> signature pads, bar-code scanners, fingerprint readers, etc.). So, we
> have been working on that feature using the USB/IP layer on the
> kernel.
>
> Connecting and disconnecting devices and transferring data works
> seamless for the devices listed above. But we also want to make the
> usbip operations private to the container where they are run.  For
> instance, it is unacceptable for our product, that one user could list
> the devices connected by other users or access them.
>
> We can control how can access every device using cgroups once those
> are attached, but the usbip layer is not providing any mechanism for
> controlling who can attach, detach or list the devices.
>> In this use-case:
>>
>> - does a container act as usbip client and attach devices from their
>>    host?
>> - do containers attach remote devices from other systems?
> In my particular case devices are imported from remote machines. But well, 
> the thing is that I don't care where the connections come from, they could 
> even be devices emulated in user space.
> 
>> Is the core of the problem really that any remote system can import without
>> a provision for being able to restrict export to a set of remote machines?
>> If so, this is a generic problem even without containers and I would like
>> to solve this with a generic solution that works in all cases, not just for
>> containers.
> No, that is a different issue. You are talking about controlling which 
> devices can be connected, from which hosts, etc. That is an interesting 
> problem but not the one I am trying to tackle here.
> 

Not entirely. These problems are linked if you use usbip driver and usbip
tools. USBIp driver is intended to be used in conjunction with the usbip
tools.

> I don't mind which every user does inside its container as far as it does not 
> interfere which other users. In practice that means:
> 
> 1- Not being able to attach/detach devices in other container

How do container attach/detach in other containers in your setup?

> 2- Not being able to list devices attached in other containers

How do container list devices in other containers in your setup?

> 3- Not being able to access devices attached in other containers.
> 
> Point 3 is already enforceable using the devices hierarchy in cgroups. For 
> points 1 and 2, my proposition is making every vhci_hcd device have its own 
> fully independent sysfs directory (instead of all of them going through 
> vhci_hcd.0) so that they can be selectively exposed with rw permissions 
> inside the containers.
> 
> 
> 
>> The approach in this patch series appears to solve the problem just for
>> containers.
>>
 Did you explore a solution to add a mechanism for access control to
 usbip?
>>> Could you elaborate on that?
>>>
>>> For "usbip", do you mean the user space tools?
>>> If that is the case, I don't think it would be enough.
>>> My aim is to limit vhci usage from containers and I have no control about 
>>> what runs inside the containers. So, a mangled usbip tool-set could > > be 
>>> used by a malicious user to circumvent any access control set there.>
>> I mean the driver. There might be changes necessary in the user-space
>> as well depending on how the access controls are implemented. I am not
>> proposing implementing access controls in the user-space.
>>
>>
>>> IMO, there is no other choice but to control access to VHCI at the kernel 
>>> level.
>>>
>> Probably. Please give as many details as possible on your environment
>> for me to make a call on if this problem can be solved in a different
>> way.
> 
> In our particular real life application, we are targeting the kernel 
> interface directly, we don't use the usbip tools at all. It is that way 
> because we have our own* transport layer, authentication and authorization 
> mechanisms. And once all the handshaking is done we end with a socket we can 
> directly pass to the kernel in order to get it attached to a vhci_hcd port. 

How do you do that? Can you elaborate on how do you pass the socket to the USBIP
host? The way you are using is unsupported and just not the way it is designed
to be used.


We don't like having an extra

PLEASE REPLY SOONEST.

2018-03-06 Thread fax 
I have a business Proposal that will be of benefit to the both of us.Kindly 
contact me on mrmichealwu...@yahoo.com.hk should this be of interest to 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] usb: gadget: udc: bdc: Use dma_pool_zalloc

2018-03-06 Thread Souptick Joarder 
Any comment for this patch.

On Wed, Feb 14, 2018 at 11:59 PM, Souptick Joarder  wrote:
> Use dma_pool_zalloc instead of dma_pool_alloc + memset
>
> Signed-off-by: Souptick Joarder 
> ---
>  drivers/usb/gadget/udc/bdc/bdc_ep.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/usb/gadget/udc/bdc/bdc_ep.c 
> b/drivers/usb/gadget/udc/bdc/bdc_ep.c
> index f40d4c1..03149b9d 100644
> --- a/drivers/usb/gadget/udc/bdc/bdc_ep.c
> +++ b/drivers/usb/gadget/udc/bdc/bdc_ep.c
> @@ -151,7 +151,7 @@ static int ep_bd_list_alloc(struct bdc_ep *ep)
> if (!bd_table)
> goto fail;
>
> -   bd_table->start_bd = dma_pool_alloc(bdc->bd_table_pool,
> +   bd_table->start_bd = dma_pool_zalloc(bdc->bd_table_pool,
> GFP_ATOMIC,
> );
> if (!bd_table->start_bd) {
> @@ -167,7 +167,6 @@ static int ep_bd_list_alloc(struct bdc_ep *ep)
> (unsigned long long)bd_table->dma, prev_table);
>
> ep->bd_list.bd_table_array[index] = bd_table;
> -   memset(bd_table->start_bd, 0, bd_p_tab * sizeof(struct 
> bdc_bd));
> if (prev_table)
> chain_table(prev_table, bd_table, bd_p_tab);
>
> --
> 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 v5 4/6] arm64: dts: exynos: add OF graph between MHL and USB connector

2018-03-06 Thread Krzysztof Kozlowski 
On Tue, Feb 27, 2018 at 08:11:32AM +0100, Andrzej Hajda wrote:
> OF graph describes MHL data lanes between MHL and respective USB
> connector.
> 
> Signed-off-by: Andrzej Hajda 
> ---
> v5: removed extra parenthesis (kbuild test robot)
> v4: added missing reg property in connector's port node (Krzysztof)
> ---
>  .../boot/dts/exynos/exynos5433-tm2-common.dtsi | 31 
> +++---
>  1 file changed, 28 insertions(+), 3 deletions(-)
> 

Thanks, applied.

Best regards,
Krzysztof

--
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 v5 3/6] arm64: dts: exynos: add micro-USB connector node to TM2 platforms

2018-03-06 Thread Krzysztof Kozlowski 
On Tue, Feb 27, 2018 at 08:11:31AM +0100, Andrzej Hajda wrote:
> Since USB connector bindings are available we can describe it on TM2(e).
> 
> Signed-off-by: Andrzej Hajda 
> ---
>  arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi | 7 +++
>  1 file changed, 7 insertions(+)
> 

Thanks, applied.

Best regards,
Krzysztof

--
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: Re: Bug 198731 "USB devices not seen with newest kernel"

2018-03-06 Thread Oliver Neukum 
Am Montag, den 05.03.2018, 16:27 +0200 schrieb Mathias Nyman:
> On 26.02.2018 16:05, Oliver Neukum wrote:
> > 
> > Am Dienstag, den 13.02.2018, 13:56 -0800 schrieb The Real Bev:
> > > 
> > it looks like a relatively old issue with D3 on some instances of XHCI.
> > 
> 
> Yep, The "Host halt failed, -19" (ENODEV) is seen when xhci driver tries to
> halt the host during setup, polling a mmio register but reading only 
> 0x.
> 
> Which I guess is expected if controller is still on D3.
> 
> No idea why this controller fails to change from D3 to D0.
> Any PCI changes betewen 4.8 and 4.9?

commit 4132a577a0a7e75b938d2ae49c7a16b358f60661
Author: Lukas Wunner 
Date:   Sun Sep 18 05:39:20 2016 +0200

PCI: Afford direct-complete to devices with non-standard PM

commit cc7cc02bada84f0d707aa5b6d2ef8728a2e1f911
Author: Lukas Wunner 
Date:   Sun Sep 18 05:39:20 2016 +0200

PCI: Query platform firmware for device power state

commit a6a64026c0cd1a76a0c8ab1c05a421aa4821887b
Author: Lukas Wunner 
Date:   Sun Sep 18 05:39:20 2016 +0200

PCI: Recognize D3cold in pci_update_current_state()

commit a0d2a959d3da343554523d26902de1d40a9e5c28
Author: Lukas Wunner 
Date:   Sun Sep 18 05:39:20 2016 +0200

PCI: Avoid unnecessary resume after direct-complete

Could you test with a revert
of a0d2a959d3da343554523d26902de1d40a9e5c28 ?

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] uas: fix comparison for error code

2018-03-06 Thread Hans de Goede 

Hi,

On 06-03-18 15:04, Oliver Neukum wrote:

A typo broke the comparison.

Fixes: cbeef22fd611c4f47c494b821b2b105b8af970bb ("usb: uas: unconditionally bring 
back host after reset")
Signed-off-by: Oliver Neukum 
CC: sta...@kernel.org


Thanks.

Acked-by: Hans de Goede 

Regards,

Hans




---
  drivers/usb/storage/uas.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/storage/uas.c b/drivers/usb/storage/uas.c
index 3b1b9695177a..6034c39b67d1 100644
--- a/drivers/usb/storage/uas.c
+++ b/drivers/usb/storage/uas.c
@@ -1076,7 +1076,7 @@ static int uas_post_reset(struct usb_interface *intf)
return 0;
  
  	err = uas_configure_endpoints(devinfo);

-   if (err && err != ENODEV)
+   if (err && err != -ENODEV)
shost_printk(KERN_ERR, shost,
 "%s: alloc streams error %d after reset",
 __func__, err);


--
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 1/2] dt-bindings: usb: ehci: add optional external vbus supply property

2018-03-06 Thread Rob Herring 
On Tue, Mar 6, 2018 at 8:09 AM, Robin Murphy  wrote:
> On 06/03/18 01:57, Rob Herring wrote:
>>
>> On Thu, Mar 01, 2018 at 10:51:38AM +0100, Amelie Delaunay wrote:
>>>
>>> On some boards, especially when vbus supply requires large current,
>>> and the charge pump on the PHY isn't enough, an external vbus power
>>> switch
>>> per port may be used.
>>> Add portN_vbus-supply property to usb-ehci bindings. As the number of
>>> ports
>>> depends on the ehci controller, and the port on which an external vbus
>>> supply depends on the platform,  is used to make it generic.
>>>
>>> Signed-off-by: Amelie Delaunay 
>>> ---
>>>   Documentation/devicetree/bindings/usb/usb-ehci.txt | 1 +
>>>   1 file changed, 1 insertion(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/usb/usb-ehci.txt
>>> b/Documentation/devicetree/bindings/usb/usb-ehci.txt
>>> index 3efde12..cd576db 100644
>>> --- a/Documentation/devicetree/bindings/usb/usb-ehci.txt
>>> +++ b/Documentation/devicetree/bindings/usb/usb-ehci.txt
>>> @@ -19,6 +19,7 @@ Optional properties:
>>>- phys : phandle + phy specifier pair
>>>- phy-names : "usb"
>>>- resets : phandle + reset specifier pair
>>> + - portN_vbus-supply : phandle of regulator supplying vbus for port N
>>
>>
>> Just make this an array with the index being the port (and drop
>> "portN_").
>
>
> Does that still work if there is an external supply for port 1 but none for
> port 0? I believe that was brought up as a possibility before.

Yes, if you use 0 or -1 to skip over an index.

Really, this should go in the connector node instead because Vbus is
supplied to the connector, not the host controller. The connector
binding is on its way into mainline.

Rob
--
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: musb: "(null)" in sysfs mode file after disabling a gadget (and at other times, system hangs)

2018-03-06 Thread Bin Liu 
On Mon, Mar 05, 2018 at 08:44:40PM +0100, Merlijn Wajer wrote:
> Hi Bin,
> 
> On 05/03/18 20:28, Bin Liu wrote:
> 
> > The musb udc driver sets the state to b_idle without checking a
> > gadget driver, this should be cleaned up. I have add this in my backlog.
> > But if this issue doesn't bother you much right now, I will make the
> > action low priority and address it later whenever I got time. (likely
> > not very soon, I have a hand full of musb driver bugs to fix...)
> 
> I can try to fix it this (or next) week. Do you have a pointer for me?

Quickly looking at the code, musb->xceiv->otg->state is set to OTG_STATE_B_IDLE
in musb_init_controller(), musb_gadget_setup(), musb_gadget_start(), and
musb_g_disconnect(). I am not sure if there is redundancy, and gadget
driver should be checked in some of them.

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 v4 1/2] dt-bindings: usb: ehci: add optional external vbus supply property

2018-03-06 Thread Robin Murphy 

On 06/03/18 01:57, Rob Herring wrote:

On Thu, Mar 01, 2018 at 10:51:38AM +0100, Amelie Delaunay wrote:

On some boards, especially when vbus supply requires large current,
and the charge pump on the PHY isn't enough, an external vbus power switch
per port may be used.
Add portN_vbus-supply property to usb-ehci bindings. As the number of ports
depends on the ehci controller, and the port on which an external vbus
supply depends on the platform,  is used to make it generic.

Signed-off-by: Amelie Delaunay 
---
  Documentation/devicetree/bindings/usb/usb-ehci.txt | 1 +
  1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/usb/usb-ehci.txt 
b/Documentation/devicetree/bindings/usb/usb-ehci.txt
index 3efde12..cd576db 100644
--- a/Documentation/devicetree/bindings/usb/usb-ehci.txt
+++ b/Documentation/devicetree/bindings/usb/usb-ehci.txt
@@ -19,6 +19,7 @@ Optional properties:
   - phys : phandle + phy specifier pair
   - phy-names : "usb"
   - resets : phandle + reset specifier pair
+ - portN_vbus-supply : phandle of regulator supplying vbus for port N


Just make this an array with the index being the port (and drop
"portN_").


Does that still work if there is an external supply for port 1 but none 
for port 0? I believe that was brought up as a possibility before.


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

[PATCH] uas: fix comparison for error code

2018-03-06 Thread Oliver Neukum 
A typo broke the comparison.

Fixes: cbeef22fd611c4f47c494b821b2b105b8af970bb ("usb: uas: unconditionally 
bring back host after reset")
Signed-off-by: Oliver Neukum 
CC: sta...@kernel.org
---
 drivers/usb/storage/uas.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/storage/uas.c b/drivers/usb/storage/uas.c
index 3b1b9695177a..6034c39b67d1 100644
--- a/drivers/usb/storage/uas.c
+++ b/drivers/usb/storage/uas.c
@@ -1076,7 +1076,7 @@ static int uas_post_reset(struct usb_interface *intf)
return 0;
 
err = uas_configure_endpoints(devinfo);
-   if (err && err != ENODEV)
+   if (err && err != -ENODEV)
shost_printk(KERN_ERR, shost,
 "%s: alloc streams error %d after reset",
 __func__, err);
-- 
2.13.6

--
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 v5 0/6] dt-bindings: add bindings for USB physical connector

2018-03-06 Thread Krzysztof Kozlowski 
On Tue, Mar 6, 2018 at 1:53 PM, Andrzej Hajda  wrote:
> Hi Rob, Chanwoo, Krzysztof,
>
>
> On 27.02.2018 08:11, Andrzej Hajda wrote:
>> Hi,
>>
>> Thanks for reviews of previous iterations.
>>
>> This patchset introduces USB physical connector bindings, together with
>> working example.
>> I have removed RFC prefix - the patchset seems to be heading
>> to a happy end :)
>>
>> v5: fixed extra parenthesis in dts, renamed extcon function.
>> v4: improved binding descriptions, added missing reg in dts.
>> v3: Separate binding for Samsung 11-pin connector, added full-blown USB-C
>> example.
>> v2: I have addressed comments by Rob and Laurent, thanks
>>
>> Changes in datail are described in the patches.
>>
>> Regards
>> Andrzej
>>
>>
>> Andrzej Hajda (5):
>>   dt-bindings: add bindings for USB physical connector
>>   dt-bindings: add bindings for Samsung micro-USB 11-pin connector
>>   arm64: dts: exynos: add micro-USB connector node to TM2 platforms
>>   arm64: dts: exynos: add OF graph between MHL and USB connector
>>   extcon: add possibility to get extcon device by OF node
>>
>> Maciej Purski (1):
>>   drm/bridge/sii8620: use micro-USB cable detection logic to detect MHL
>
> It looks like all patches received R-B or acks (I forgot add Krzysztof's
> acks for dts part).
> Now I have a question how to merge them.
> The only functional dependency is between bridge and extcon, and from
> the formal PoV bindings should be merged 1st.
> I can merge it:
> 1. All patches via drm-misc tree.
> 2. All patches except dts via drm-misc, and Krzysztof will merge dts via
> samsung-soc tree.

2) option please. The DTS should always go through arm-soc because it
is independent of driver code. I'll take the DTS today.

Best regards,
Krzysztof
--
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 v5 0/6] dt-bindings: add bindings for USB physical connector

2018-03-06 Thread Andrzej Hajda 
Hi Rob, Chanwoo, Krzysztof,


On 27.02.2018 08:11, Andrzej Hajda wrote:
> Hi,
>
> Thanks for reviews of previous iterations.
>
> This patchset introduces USB physical connector bindings, together with
> working example.
> I have removed RFC prefix - the patchset seems to be heading
> to a happy end :)
>
> v5: fixed extra parenthesis in dts, renamed extcon function.
> v4: improved binding descriptions, added missing reg in dts.
> v3: Separate binding for Samsung 11-pin connector, added full-blown USB-C
> example.
> v2: I have addressed comments by Rob and Laurent, thanks 
>
> Changes in datail are described in the patches.
>
> Regards
> Andrzej
>
>
> Andrzej Hajda (5):
>   dt-bindings: add bindings for USB physical connector
>   dt-bindings: add bindings for Samsung micro-USB 11-pin connector
>   arm64: dts: exynos: add micro-USB connector node to TM2 platforms
>   arm64: dts: exynos: add OF graph between MHL and USB connector
>   extcon: add possibility to get extcon device by OF node
>
> Maciej Purski (1):
>   drm/bridge/sii8620: use micro-USB cable detection logic to detect MHL

It looks like all patches received R-B or acks (I forgot add Krzysztof's
acks for dts part).
Now I have a question how to merge them.
The only functional dependency is between bridge and extcon, and from
the formal PoV bindings should be merged 1st.
I can merge it:
1. All patches via drm-misc tree.
2. All patches except dts via drm-misc, and Krzysztof will merge dts via
samsung-soc tree.

Is it OK, for all? Better ideas?

Regards
Andrzej


>
>  .../connector/samsung,usb-connector-11pin.txt  | 49 +++
>  .../bindings/connector/usb-connector.txt   | 75 +
>  .../boot/dts/exynos/exynos5433-tm2-common.dtsi | 38 -
>  drivers/extcon/extcon.c| 44 +++---
>  drivers/gpu/drm/bridge/sil-sii8620.c   | 97 
> +-
>  include/linux/extcon.h |  6 ++
>  6 files changed, 293 insertions(+), 16 deletions(-)
>  create mode 100644 
> Documentation/devicetree/bindings/connector/samsung,usb-connector-11pin.txt
>  create mode 100644 
> Documentation/devicetree/bindings/connector/usb-connector.txt
>

--
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.16 REGRESSION fix] Revert "typec: tcpm: Only request matching pdos"

2018-03-06 Thread Heikki Krogerus 
On Tue, Mar 06, 2018 at 10:50:05AM +0100, Hans de Goede wrote:
> Commit 57e6f0d7b804 ("typec: tcpm: Only request matching pdos") is causing
> a regression, before this commit e.g. the GPD win and GPD pocket devices
> were charging at 9V 3A with a PD charger, now they are instead slowly
> discharging  at 5V 0.4A, as this commit causes the ports max_snk_mv/ma/mw
> settings to be completely ignored.
> 
> Arguably the way to fix this would be to add a PDO_VAR() describing the
> voltage range to the snk_caps of boards which can handle any voltage in
> their range, but the "typec: tcpm: Only request matching pdos" commit
> looks at the type of PDO advertised by the source/charger and if that
> is fixed (as it typically is) only compairs against PDO_FIXED entries
> in the snk_caps so supporting a range of voltage would require adding a
> PDO_FIXED entry for *every possible* voltage to snk_caps.
> 
> AFAICT there is no reason why a fixed source_cap cannot be matched against
> a variable snk_cap, so at a minimum the commit should be rewritten to
> support that.
> 
> For now lets revert the "typec: tcpm: Only request matching pdos" commit,
> fixing the regression.
> 
> Cc: Badhri Jagan Sridharan 
> Signed-off-by: Hans de Goede 

You are correct. The patch should be rewritten.

Acked-by: Heikki Krogerus 


Thanks,

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

RE: [PATCH 4.16 REGRESSION fix] Revert "typec: tcpm: Only request matching pdos"

2018-03-06 Thread Adam Thomson 
On 06 March 2018 09:50, Hans de Goede wrote:

> Commit 57e6f0d7b804 ("typec: tcpm: Only request matching pdos") is causing
> a regression, before this commit e.g. the GPD win and GPD pocket devices
> were charging at 9V 3A with a PD charger, now they are instead slowly
> discharging  at 5V 0.4A, as this commit causes the ports max_snk_mv/ma/mw
> settings to be completely ignored.
> 
> Arguably the way to fix this would be to add a PDO_VAR() describing the
> voltage range to the snk_caps of boards which can handle any voltage in
> their range, but the "typec: tcpm: Only request matching pdos" commit
> looks at the type of PDO advertised by the source/charger and if that
> is fixed (as it typically is) only compairs against PDO_FIXED entries
> in the snk_caps so supporting a range of voltage would require adding a
> PDO_FIXED entry for *every possible* voltage to snk_caps.
> 
> AFAICT there is no reason why a fixed source_cap cannot be matched against
> a variable snk_cap, so at a minimum the commit should be rewritten to
> support that.
> 
> For now lets revert the "typec: tcpm: Only request matching pdos" commit,
> fixing the regression.
> 
> Cc: Badhri Jagan Sridharan 
> Signed-off-by: Hans de Goede 

Thanks Hans. Sadly I alluded to this problem before the patch was pulled in but
this was seemingly missed:

 https://lkml.org/lkml/2017/11/28/186

FWIW, Acked-by: Adam Thomson 

> ---
>  drivers/usb/typec/tcpm.c | 163 
> ---
>  1 file changed, 42 insertions(+), 121 deletions(-)
> 
> diff --git a/drivers/usb/typec/tcpm.c b/drivers/usb/typec/tcpm.c
> index bfcaf6618a1f..735a6dd74c20 100644
> --- a/drivers/usb/typec/tcpm.c
> +++ b/drivers/usb/typec/tcpm.c
> @@ -254,9 +254,6 @@ struct tcpm_port {
>   unsigned int nr_src_pdo;
>   u32 snk_pdo[PDO_MAX_OBJECTS];
>   unsigned int nr_snk_pdo;
> - unsigned int nr_fixed; /* number of fixed sink PDOs */
> - unsigned int nr_var; /* number of variable sink PDOs */
> - unsigned int nr_batt; /* number of battery sink PDOs */
>   u32 snk_vdo[VDO_MAX_OBJECTS];
>   unsigned int nr_snk_vdo;
> 
> @@ -1786,90 +1783,39 @@ static int tcpm_pd_check_request(struct tcpm_port
> *port)
>   return 0;
>  }
> 
> -#define min_power(x, y) min(pdo_max_power(x), pdo_max_power(y))
> -#define min_current(x, y) min(pdo_max_current(x), pdo_max_current(y))
> -
> -static int tcpm_pd_select_pdo(struct tcpm_port *port, int *sink_pdo,
> -   int *src_pdo)
> +static int tcpm_pd_select_pdo(struct tcpm_port *port)
>  {
> - unsigned int i, j, max_mw = 0, max_mv = 0, mw = 0, mv = 0, ma = 0;
> + unsigned int i, max_mw = 0, max_mv = 0;
>   int ret = -EINVAL;
> 
>   /*
> -  * Select the source PDO providing the most power which has a
> -  * matchig sink cap.
> +  * Select the source PDO providing the most power while staying within
> +  * the board's voltage limits. Prefer PDO providing exp
>*/
>   for (i = 0; i < port->nr_source_caps; i++) {
>   u32 pdo = port->source_caps[i];
>   enum pd_pdo_type type = pdo_type(pdo);
> + unsigned int mv, ma, mw;
> 
> - if (type == PDO_TYPE_FIXED) {
> - for (j = 0; j < port->nr_fixed; j++) {
> - if (pdo_fixed_voltage(pdo) ==
> - pdo_fixed_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;
> - }
> - /* There could only be one fixed pdo
> -  * at a specific voltage level.
> -  * So breaking here.
> -  */
> - break;
> - }
> - }
> - } else if (type == PDO_TYPE_BATT) {
> - for (j = port->nr_fixed;
> -  j < port->nr_fixed +
> -  port->nr_batt;
> -  j++) {
> - if (pdo_min_voltage(pdo) >=
> -  pdo_min_voltage(port->snk_pdo[j]) &&
> -  pdo_max_voltage(pdo) <=
> -

Re: [PATCH v2 10/12] dt-bindings: connector: add properties for typec power delivery

2018-03-06 Thread Heikki Krogerus 
Hi guys,

On Tue, Mar 06, 2018 at 09:38:59AM +, Jun Li wrote:
> > >>> diff --git
> > >>> a/Documentation/devicetree/bindings/connector/usb-connector.txt
> > >>> b/Documentation/devicetree/bindings/connector/usb-connector.txt
> > >>> index e1463f1..242f6df 100644
> > >>> --- a/Documentation/devicetree/bindings/connector/usb-connector.txt
> > >>> +++
> > b/Documentation/devicetree/bindings/connector/usb-connector.txt
> > >>> @@ -15,6 +15,30 @@ Optional properties:
> > >>>  - type: size of the connector, should be specified in case of USB-A,
> > USB-B
> > >>>non-fullsize connectors: "mini", "micro".
> > >>>
> > >>> +Required properties for usb-c-connector with power delivery support:
> > >>> +- port-type: should be one of "source", "sink" or "dual".
> > >>> +- default-role: preferred power role if port-type is "dual"(drp),
> > >>> +should be
> > >>> +  "sink" or "source".
> > >> Since port carries data and power, it would be better to explicitly
> > >> mention it in names of properties which can be ambiguous.
> > >> Maybe instead of 'port-type' you can use 'power-role', for example.
> > > Port-type is align with the name of typec coding and ABI, 'power-role'
> > > is more like for the current role rather than the port's ability.
> > 
> > I am not sure what are you exactly mean by "coding and ABI", but I guess it 
> > is
> > just about Power-Delivery part of USB-C. And if you want to put this 
> > property
> > into USB node without mark it is related to PD part of USB connector, you
> > risk confusion with possible USB data related properties.
> 
> Understood your concern, I am following typec naming conventions,
> for typec, port-type property has the same meaning as
> /sys/class/typec/portx/port_type
> which is not only for power, also for data, there are dedicated
> sys files power_role for power and data_role for data.
> 
> > Simple question, what if somebody wants to add property describing USB
> > data capabilities (DFP, UFP, DRD), how should it be named?
> > 
> 
> Then we may use data-role?
> 
> > >
> > >> Other thing is that default-role is required only in case of DRP, so
> > >> maybe better would be to squash it in power-role, for example:
> > >> ?? power-role: should be on of "source", "sink", "dual-source",
> > >> "dual-sink", in case of dual roles suffix determines preferred role.
> > > I don't know how much this squash can benefit, "dual-source/sink" is
> > > not directly showing its meaning by name.
> > 
> > Some benefit is simpler binding, no conditionally-required property.
> > 
> 
> There is already string definition for port type and preferred role parse 
> static const char * const typec_port_types[] = {
>  [TYPEC_PORT_DFP] = "source",
>  [TYPEC_PORT_UFP] = "sink",
>  [TYPEC_PORT_DRP] = "dual",
> };
> And I think there will be other conditionally-required properties
> to be extended later, are we going to name all of them by this way?
> Either way is OK for me, I am not sure if there is principle like we
> should avoid conditionally-required property, if we should, maybe
> "dual-preferred-source/sink" is better.
> 
> Hi Heikki,
> Do you have any comments/preference here?

In the first versions of USB Type-C specification the data and power
roles were in practice coupled together. There were no data role
specific modes, just DFP, UFP and DRP. However, v1.2 of the spec.
introduced separate modes for the data roles as well, and I have a
patch for that (attached).

If you are asking my opinion, the data role must be handled as
separate capability of the port, i.e. you probable want to have
separate properties for the power role and data role, even if we did
not support that yet in the class code. Don't use "port-type" name,
just call them "power-role" and "data-role" from now on.

The default-role should tell the state machines whether Try.SNK or
Try.SRC states should be used or not. Perhaps you should have boolean
property for both: "try-snk" and "try-src" (note: both can not be true).

Final note. I think it would make sense to clearly separate the USB
Type-C specific properties from USB PD ones. Though it is unlikely
that we will see USB PD being used with other connector types besides
Type-C anymore, USB Type-C connectors will still definitely not
always support USB PD, but when USB PD is not supported, we still need
to know the data-role, power-role, default-role (or try-snk, try-src),
etc.


Br,

-- 
heikki
>From 4f7652ba8a3d4e8f7bd30cf7ca8beba6af5ad873 Mon Sep 17 00:00:00 2001
From: Heikki Krogerus 
Date: Tue, 2 Jan 2018 17:07:58 +0300
Subject: [PATCH] usb: typec: Separate the definitions for data and power roles

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

[PATCH v5 3/3] USB3/DWC3: Enable undefined length INCR burst type

2018-03-06 Thread Ran Wang 
Enable the undefined length INCR burst type and set INCRx.
Different platform may has the different burst size type.
In order to get best performance, we need to tune the burst size to
one special value, instead of the default value.

Signed-off-by: Changming Huang 
Signed-off-by: Rajesh Bhagat 
Signed-off-by: Ran Wang 
---
Changes in v5:
  - no change
Changes in v4:
  - Modify the codes according to the definition of this property.
Changes in v3:
  - add new property for INCR burst in usb node to reset GSBUSCFG0.
Changes in v2:
  - split patch
  - create one new function to handle soc bus configuration register.

 drivers/usb/dwc3/core.c |   83 +++
 drivers/usb/dwc3/core.h |7 
 2 files changed, 90 insertions(+), 0 deletions(-)

diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index f1d838a..8ea2bc8 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -741,6 +741,87 @@ static void dwc3_core_setup_global_control(struct dwc3 
*dwc)
 static int dwc3_core_get_phy(struct dwc3 *dwc);
 static int dwc3_core_ulpi_init(struct dwc3 *dwc);
 
+/* set global soc bus configuration registers */
+static void dwc3_set_soc_bus_cfg(struct dwc3 *dwc)
+{
+   struct device *dev = dwc->dev;
+   u32 *vals;
+   u32 cfg;
+   int ntype;
+   int ret;
+   int i;
+
+   cfg = dwc3_readl(dwc->regs, DWC3_GSBUSCFG0);
+
+   /*
+* Handle property "snps,incr-burst-type-adjustment".
+* Get the number of value from this property:
+* result <= 0, means this property is not supported.
+* result = 1, means INCRx burst mode supported.
+* result > 1, means undefined length burst mode supported.
+*/
+   ntype = device_property_read_u32_array(dev,
+   "snps,incr-burst-type-adjustment", NULL, 0);
+   if (ntype > 0) {
+   vals = kcalloc(ntype, sizeof(u32), GFP_KERNEL);
+   if (!vals) {
+   dev_err(dev, "Error to get memory\n");
+   return;
+   }
+   /* Get INCR burst type, and parse it */
+   ret = device_property_read_u32_array(dev,
+   "snps,incr-burst-type-adjustment", vals, ntype);
+   if (ret) {
+   dev_err(dev, "Error to get property\n");
+   return;
+   }
+   *(dwc->incrx_type + 1) = vals[0];
+   if (ntype > 1) {
+   *dwc->incrx_type = 1;
+   for (i = 1; i < ntype; i++) {
+   if (vals[i] > *(dwc->incrx_type + 1))
+   *(dwc->incrx_type + 1) = vals[i];
+   }
+   } else
+   *dwc->incrx_type = 0;
+
+   /* Enable Undefined Length INCR Burst and Enable INCRx Burst */
+   cfg &= ~DWC3_GSBUSCFG0_INCRBRST_MASK;
+   if (*dwc->incrx_type)
+   cfg |= DWC3_GSBUSCFG0_INCRBRSTENA;
+   switch (*(dwc->incrx_type + 1)) {
+   case 256:
+   cfg |= DWC3_GSBUSCFG0_INCR256BRSTENA;
+   break;
+   case 128:
+   cfg |= DWC3_GSBUSCFG0_INCR128BRSTENA;
+   break;
+   case 64:
+   cfg |= DWC3_GSBUSCFG0_INCR64BRSTENA;
+   break;
+   case 32:
+   cfg |= DWC3_GSBUSCFG0_INCR32BRSTENA;
+   break;
+   case 16:
+   cfg |= DWC3_GSBUSCFG0_INCR16BRSTENA;
+   break;
+   case 8:
+   cfg |= DWC3_GSBUSCFG0_INCR8BRSTENA;
+   break;
+   case 4:
+   cfg |= DWC3_GSBUSCFG0_INCR4BRSTENA;
+   break;
+   case 1:
+   break;
+   default:
+   dev_err(dev, "Invalid property\n");
+   break;
+   }
+   }
+
+   dwc3_writel(dwc->regs, DWC3_GSBUSCFG0, cfg);
+}
+
 /**
  * dwc3_core_init - Low-level initialization of DWC3 Core
  * @dwc: Pointer to our controller context structure
@@ -803,6 +884,8 @@ static int dwc3_core_init(struct dwc3 *dwc)
/* Adjust Frame Length */
dwc3_frame_length_adjustment(dwc);
 
+   dwc3_set_soc_bus_cfg(dwc);
+
usb_phy_set_suspend(dwc->usb2_phy, 0);
usb_phy_set_suspend(dwc->usb3_phy, 0);
ret = phy_power_on(dwc->usb2_generic_phy);
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 8f97f61..565d7ec 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -806,6 +806,7 @@ struct dwc3_scratchpad_array {
  * @regs: base address for our registers
  * @regs_size: address space size

[PATCH v5 2/3] USB3/DWC3: Add property "snps,incr-burst-type-adjustment" for INCR burst type

2018-03-06 Thread Ran Wang 
Property "snps,incr-burst-type-adjustment = , ..." for USB3.0 DWC3.
When only one value means INCRx mode with fix burst type.
When more than one value, means undefined length burst mode, USB controller
can use the length less than or equal to the largest enabled burst length.

While enabling undefined length INCR burst type and INCR16 burst type,
get better write performance on NXP Layerscape platforms:
around 3% improvement (from 364MB/s to 375MB/s).

Signed-off-by: Changming Huang 
Signed-off-by: Ran Wang 
---
Changes in v5:
  - add support for ls1021a, ls1012a, ls1046a, ls1088a, ls1021a
  - update ls208xa support according to code base change
Changes in v4:
  - change definition for this property.
Changes in v3:
  - add new property for INCR burst in usb node.

 Documentation/devicetree/bindings/usb/dwc3.txt |6 ++
 arch/arm/boot/dts/ls1021a.dtsi |1 +
 arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi |1 +
 arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi |3 +++
 arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi |3 +++
 arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi |2 ++
 arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi |2 ++
 7 files changed, 18 insertions(+), 0 deletions(-)

diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt 
b/Documentation/devicetree/bindings/usb/dwc3.txt
index 44e8bab..d1779b2 100644
--- a/Documentation/devicetree/bindings/usb/dwc3.txt
+++ b/Documentation/devicetree/bindings/usb/dwc3.txt
@@ -59,6 +59,11 @@ Optional properties:
fladj_30mhz_sdbnd signal is invalid or incorrect.
 
  -  tx-fifo-resize: determines if the FIFO *has* to be reallocated.
+ - snps,incr-burst-type-adjustment: Value for INCR burst type of GSBUSCFG0
+   register, undefined length INCR burst type enable and INCRx type.
+   When just one value, which means INCRX burst mode. When more than one
+   value, which means undefined length INCR burst type enabled.
+   The values can be 1, 4, 8, 16, 32, 64, 128 and 256.
 
  - in addition all properties from usb-xhci.txt from the current directory are
supported as well
@@ -71,4 +76,5 @@ dwc3@4a03 {
reg = <0x4a03 0xcfff>;
interrupts = <0 92 4>
usb-phy = <_phy>, <,phy>;
+   snps,incr-burst-type-adjustment = <1>, <4>, <8>, <16>;
 };
diff --git a/arch/arm/boot/dts/ls1021a.dtsi b/arch/arm/boot/dts/ls1021a.dtsi
index c31dad9..b0c3f4f 100644
--- a/arch/arm/boot/dts/ls1021a.dtsi
+++ b/arch/arm/boot/dts/ls1021a.dtsi
@@ -705,6 +705,7 @@
dr_mode = "host";
snps,quirk-frame-length-adjustment = <0x20>;
snps,dis_rxdet_inp3_quirk;
+   snps,incr-burst-type-adjustment = <1>, <4>, <8>, <16>;
};
 
pcie@340 {
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi 
b/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
index 82b272f..4275a8f 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
@@ -464,6 +464,7 @@
dr_mode = "host";
snps,quirk-frame-length-adjustment = <0x20>;
snps,dis_rxdet_inp3_quirk;
+   snps,incr-burst-type-adjustment = <1>, <4>, <8>, <16>;
};
 
sata: sata@320 {
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi 
b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
index 380e7c7..0067567 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
@@ -622,6 +622,7 @@
dr_mode = "host";
snps,quirk-frame-length-adjustment = <0x20>;
snps,dis_rxdet_inp3_quirk;
+   snps,incr-burst-type-adjustment = <1>, <4>, <8>, <16>;
};
 
usb1: usb3@300 {
@@ -631,6 +632,7 @@
dr_mode = "host";
snps,quirk-frame-length-adjustment = <0x20>;
snps,dis_rxdet_inp3_quirk;
+   snps,incr-burst-type-adjustment = <1>, <4>, <8>, <16>;
};
 
usb2: usb3@310 {
@@ -640,6 +642,7 @@
dr_mode = "host";
snps,quirk-frame-length-adjustment = <0x20>;
snps,dis_rxdet_inp3_quirk;
+   snps,incr-burst-type-adjustment = <1>, <4>, <8>, <16>;
};
 
sata: sata@320 {
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi 
b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
index 06b5e12..2bf6756 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
@@ -602,6 +602,7 @@
dr_mode = "host";
snps,quirk-frame-length-adjustment = <0x20>;

[PATCH v5 1/3] USB3/DWC3: Add definition for global soc bus configuration register

2018-03-06 Thread Ran Wang 
From: Changming Huang 

Add the macro definition for global soc bus configuration register 0/1

Signed-off-by: Changming Huang 
Signed-off-by: Ran Wang 
---
Changes in v5:
  - no change
Changes in v4:
  - no change
Changes in v3:
  - no change
Changes in v2:
  - split the patch
  - add more macro definition for soc bus configuration register

 drivers/usb/dwc3/core.h |   26 ++
 1 files changed, 26 insertions(+), 0 deletions(-)

diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 860d2bc..8f97f61 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -153,6 +153,32 @@
 
 /* Bit fields */
 
+/* Global SoC Bus Configuration Register 0 */
+#define AXI3_CACHE_TYPE_AW 0x8 /* write allocate */
+#define AXI3_CACHE_TYPE_AR 0x4 /* read allocate */
+#define AXI3_CACHE_TYPE_SNP0x2 /* cacheable */
+#define AXI3_CACHE_TYPE_BUF0x1 /* bufferable */
+#define DWC3_GSBUSCFG0_DATARD_SHIFT28
+#define DWC3_GSBUSCFG0_DESCRD_SHIFT24
+#define DWC3_GSBUSCFG0_DATAWR_SHIFT20
+#define DWC3_GSBUSCFG0_DESCWR_SHIFT16
+#define DWC3_GSBUSCFG0_SNP_MASK0x
+#define DWC3_GSBUSCFG0_DATABIGEND  (1 << 11)
+#define DWC3_GSBUSCFG0_DESCBIGEND  (1 << 10)
+#define DWC3_GSBUSCFG0_INCR256BRSTENA  (1 << 7) /* INCR256 burst */
+#define DWC3_GSBUSCFG0_INCR128BRSTENA  (1 << 6) /* INCR128 burst */
+#define DWC3_GSBUSCFG0_INCR64BRSTENA   (1 << 5) /* INCR64 burst */
+#define DWC3_GSBUSCFG0_INCR32BRSTENA   (1 << 4) /* INCR32 burst */
+#define DWC3_GSBUSCFG0_INCR16BRSTENA   (1 << 3) /* INCR16 burst */
+#define DWC3_GSBUSCFG0_INCR8BRSTENA(1 << 2) /* INCR8 burst */
+#define DWC3_GSBUSCFG0_INCR4BRSTENA(1 << 1) /* INCR4 burst */
+#define DWC3_GSBUSCFG0_INCRBRSTENA (1 << 0) /* undefined length enable */
+#define DWC3_GSBUSCFG0_INCRBRST_MASK   0xff
+
+/* Global SoC Bus Configuration Register 1 */
+#define DWC3_GSBUSCFG1_1KPAGEENA   (1 << 12) /* 1K page boundary enable */
+#define DWC3_GSBUSCFG1_PTRANSLIMIT_MASK0xf00
+
 /* Global Debug Queue/FIFO Space Available Register */
 #define DWC3_GDBGFIFOSPACE_NUM(n)  ((n) & 0x1f)
 #define DWC3_GDBGFIFOSPACE_TYPE(n) (((n) << 5) & 0x1e0)
-- 
1.7.1

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

Re: [PATCH v2 10/12] dt-bindings: connector: add properties for typec power delivery

2018-03-06 Thread Andrzej Hajda 
On 06.03.2018 10:38, Jun Li wrote:
> Hi
>> -Original Message-
>> From: Andrzej Hajda [mailto:a.ha...@samsung.com]
>> Sent: 2018年3月5日 17:59
>> To: Jun Li ; gre...@linuxfoundation.org;
>> robh...@kernel.org; heikki.kroge...@linux.intel.com; li...@roeck-us.net
>> Cc: mark.rutl...@arm.com; yue...@google.com; Peter Chen
>> ; garsi...@embeddedor.com; o_leve...@orange.fr;
>> shufan_...@richtek.com; linux-usb@vger.kernel.org;
>> devicet...@vger.kernel.org; dl-linux-imx 
>> Subject: Re: [PATCH v2 10/12] dt-bindings: connector: add properties for
>> typec power delivery
>>
>> On 05.03.2018 08:00, Jun Li wrote:
 -Original Message-
 From: Andrzej Hajda [mailto:a.ha...@samsung.com]
 Sent: 2018年2月27日 16:41
 To: Jun Li ; gre...@linuxfoundation.org;
 robh...@kernel.org; heikki.kroge...@linux.intel.com;
 robh+li...@roeck-us.net
 Cc: mark.rutl...@arm.com; yue...@google.com; Peter Chen
 ; garsi...@embeddedor.com;
>> o_leve...@orange.fr;
 shufan_...@richtek.com; linux-usb@vger.kernel.org;
 devicet...@vger.kernel.org; dl-linux-imx 
 Subject: Re: [PATCH v2 10/12] dt-bindings: connector: add properties
 for typec power delivery

 On 26.02.2018 12:49, Li Jun wrote:
> In case of usb-c-connector with power delivery support, add
> bingdings supported by current typec driver, so user can pass all
> those properties via dt.
>
> Signed-off-by: Li Jun 
> ---
> Changes for v2:
> - Added typec properties are based on general usb connector bindings[1]
>   proposed by Andrzej Hajda.
> - Use the standard unit suffixes as defined in property-units.txt.
>
> [1]
>
>> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpa
 t

>> chwork.kernel.org%2Fpatch%2F10231447%2F=02%7C01%7Cjun.li%40
 nxp.co

>> m%7Cccf14a36ca6445ee5f1108d57dbde3c7%7C686ea1d3bc2b4c6fa92cd99
 c5c30163

>> 5%7C0%7C0%7C636553176880292197=2Pi0AtiwAqHQE3rGl%2Bo49K
 7yZZcp%2B
> 5bvJAknRBMGTrk%3D=0
>
>  .../bindings/connector/usb-connector.txt   | 43
 ++
>  1 file changed, 43 insertions(+)
>
> diff --git
> a/Documentation/devicetree/bindings/connector/usb-connector.txt
> b/Documentation/devicetree/bindings/connector/usb-connector.txt
> index e1463f1..242f6df 100644
> --- a/Documentation/devicetree/bindings/connector/usb-connector.txt
> +++
>> b/Documentation/devicetree/bindings/connector/usb-connector.txt
> @@ -15,6 +15,30 @@ Optional properties:
>  - type: size of the connector, should be specified in case of USB-A,
>> USB-B
>non-fullsize connectors: "mini", "micro".
>
> +Required properties for usb-c-connector with power delivery support:
> +- port-type: should be one of "source", "sink" or "dual".
> +- default-role: preferred power role if port-type is "dual"(drp),
> +should be
> +  "sink" or "source".
 Since port carries data and power, it would be better to explicitly
 mention it in names of properties which can be ambiguous.
 Maybe instead of 'port-type' you can use 'power-role', for example.
>>> Port-type is align with the name of typec coding and ABI, 'power-role'
>>> is more like for the current role rather than the port's ability.
>> I am not sure what are you exactly mean by "coding and ABI", but I guess it 
>> is
>> just about Power-Delivery part of USB-C. And if you want to put this property
>> into USB node without mark it is related to PD part of USB connector, you
>> risk confusion with possible USB data related properties.
> Understood your concern, I am following typec naming conventions,
> for typec, port-type property has the same meaning as
> /sys/class/typec/portx/port_type
> which is not only for power, also for data, there are dedicated
> sys files power_role for power and data_role for data.
>
>> Simple question, what if somebody wants to add property describing USB
>> data capabilities (DFP, UFP, DRD), how should it be named?
>>
> Then we may use data-role?

Few lines above you have said -role is "for the current role rather than
the port's ability" :)

Generally my intention was to avoid such inconsistencies, for example by
using consistently
prefixes (for example: power and data) and suffixes (for example: mode
and role), which are used in specs.
We would have then:
- power_mode - for PD capabilities,
- power_role - for default/initial role,
- data_mode - for data capabilities,
- data_role - for default/initial role (as I understand specs this
property is redundant, as initial data_role is determined by power_role).

Of course if there is already well established convention, we shouldn't
change it, is there any, sysfs is well established?

>
 Other thing is that default-role is required only in case of DRP, so
 maybe better would be

Re: [PATCH 4.16 REGRESSION fix] Revert "typec: tcpm: Only request matching pdos"

2018-03-06 Thread Guenter Roeck 

On 03/06/2018 01:50 AM, Hans de Goede wrote:

Commit 57e6f0d7b804 ("typec: tcpm: Only request matching pdos") is causing
a regression, before this commit e.g. the GPD win and GPD pocket devices
were charging at 9V 3A with a PD charger, now they are instead slowly
discharging  at 5V 0.4A, as this commit causes the ports max_snk_mv/ma/mw
settings to be completely ignored.

Arguably the way to fix this would be to add a PDO_VAR() describing the
voltage range to the snk_caps of boards which can handle any voltage in
their range, but the "typec: tcpm: Only request matching pdos" commit
looks at the type of PDO advertised by the source/charger and if that
is fixed (as it typically is) only compairs against PDO_FIXED entries
in the snk_caps so supporting a range of voltage would require adding a
PDO_FIXED entry for *every possible* voltage to snk_caps.

AFAICT there is no reason why a fixed source_cap cannot be matched against
a variable snk_cap, so at a minimum the commit should be rewritten to
support that.

For now lets revert the "typec: tcpm: Only request matching pdos" commit,
fixing the regression.

Cc: Badhri Jagan Sridharan 
Signed-off-by: Hans de Goede 


Reviewed-by: Guenter Roeck 


---
  drivers/usb/typec/tcpm.c | 163 ---
  1 file changed, 42 insertions(+), 121 deletions(-)

diff --git a/drivers/usb/typec/tcpm.c b/drivers/usb/typec/tcpm.c
index bfcaf6618a1f..735a6dd74c20 100644
--- a/drivers/usb/typec/tcpm.c
+++ b/drivers/usb/typec/tcpm.c
@@ -254,9 +254,6 @@ struct tcpm_port {
unsigned int nr_src_pdo;
u32 snk_pdo[PDO_MAX_OBJECTS];
unsigned int nr_snk_pdo;
-   unsigned int nr_fixed; /* number of fixed sink PDOs */
-   unsigned int nr_var; /* number of variable sink PDOs */
-   unsigned int nr_batt; /* number of battery sink PDOs */
u32 snk_vdo[VDO_MAX_OBJECTS];
unsigned int nr_snk_vdo;
  
@@ -1786,90 +1783,39 @@ static int tcpm_pd_check_request(struct tcpm_port *port)

return 0;
  }
  
-#define min_power(x, y) min(pdo_max_power(x), pdo_max_power(y))

-#define min_current(x, y) min(pdo_max_current(x), pdo_max_current(y))
-
-static int tcpm_pd_select_pdo(struct tcpm_port *port, int *sink_pdo,
- int *src_pdo)
+static int tcpm_pd_select_pdo(struct tcpm_port *port)
  {
-   unsigned int i, j, max_mw = 0, max_mv = 0, mw = 0, mv = 0, ma = 0;
+   unsigned int i, max_mw = 0, max_mv = 0;
int ret = -EINVAL;
  
  	/*

-* Select the source PDO providing the most power which has a
-* matchig sink cap.
+* Select the source PDO providing the most power while staying within
+* the board's voltage limits. Prefer PDO providing exp
 */
for (i = 0; i < port->nr_source_caps; i++) {
u32 pdo = port->source_caps[i];
enum pd_pdo_type type = pdo_type(pdo);
+   unsigned int mv, ma, mw;
  
-		if (type == PDO_TYPE_FIXED) {

-   for (j = 0; j < port->nr_fixed; j++) {
-   if (pdo_fixed_voltage(pdo) ==
-   pdo_fixed_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;
-   }
-   /* There could only be one fixed pdo
-* at a specific voltage level.
-* So breaking here.
-*/
-   break;
-   }
-   }
-   } else if (type == PDO_TYPE_BATT) {
-   for (j = port->nr_fixed;
-j < port->nr_fixed +
-port->nr_batt;
-j++) {
-   if (pdo_min_voltage(pdo) >=
-pdo_min_voltage(port->snk_pdo[j]) &&
-pdo_max_voltage(pdo) <=
-pdo_max_voltage(port->snk_pdo[j])) {
-   mw = min_power(pdo, port->snk_pdo[j]);
-   mv = pdo_min_voltage(pdo);
-   if

[PATCH 4.16 REGRESSION fix] Revert "typec: tcpm: Only request matching pdos"

2018-03-06 Thread Hans de Goede 
Commit 57e6f0d7b804 ("typec: tcpm: Only request matching pdos") is causing
a regression, before this commit e.g. the GPD win and GPD pocket devices
were charging at 9V 3A with a PD charger, now they are instead slowly
discharging  at 5V 0.4A, as this commit causes the ports max_snk_mv/ma/mw
settings to be completely ignored.

Arguably the way to fix this would be to add a PDO_VAR() describing the
voltage range to the snk_caps of boards which can handle any voltage in
their range, but the "typec: tcpm: Only request matching pdos" commit
looks at the type of PDO advertised by the source/charger and if that
is fixed (as it typically is) only compairs against PDO_FIXED entries
in the snk_caps so supporting a range of voltage would require adding a
PDO_FIXED entry for *every possible* voltage to snk_caps.

AFAICT there is no reason why a fixed source_cap cannot be matched against
a variable snk_cap, so at a minimum the commit should be rewritten to
support that.

For now lets revert the "typec: tcpm: Only request matching pdos" commit,
fixing the regression.

Cc: Badhri Jagan Sridharan 
Signed-off-by: Hans de Goede 
---
 drivers/usb/typec/tcpm.c | 163 ---
 1 file changed, 42 insertions(+), 121 deletions(-)

diff --git a/drivers/usb/typec/tcpm.c b/drivers/usb/typec/tcpm.c
index bfcaf6618a1f..735a6dd74c20 100644
--- a/drivers/usb/typec/tcpm.c
+++ b/drivers/usb/typec/tcpm.c
@@ -254,9 +254,6 @@ struct tcpm_port {
unsigned int nr_src_pdo;
u32 snk_pdo[PDO_MAX_OBJECTS];
unsigned int nr_snk_pdo;
-   unsigned int nr_fixed; /* number of fixed sink PDOs */
-   unsigned int nr_var; /* number of variable sink PDOs */
-   unsigned int nr_batt; /* number of battery sink PDOs */
u32 snk_vdo[VDO_MAX_OBJECTS];
unsigned int nr_snk_vdo;
 
@@ -1786,90 +1783,39 @@ static int tcpm_pd_check_request(struct tcpm_port *port)
return 0;
 }
 
-#define min_power(x, y) min(pdo_max_power(x), pdo_max_power(y))
-#define min_current(x, y) min(pdo_max_current(x), pdo_max_current(y))
-
-static int tcpm_pd_select_pdo(struct tcpm_port *port, int *sink_pdo,
- int *src_pdo)
+static int tcpm_pd_select_pdo(struct tcpm_port *port)
 {
-   unsigned int i, j, max_mw = 0, max_mv = 0, mw = 0, mv = 0, ma = 0;
+   unsigned int i, max_mw = 0, max_mv = 0;
int ret = -EINVAL;
 
/*
-* Select the source PDO providing the most power which has a
-* matchig sink cap.
+* Select the source PDO providing the most power while staying within
+* the board's voltage limits. Prefer PDO providing exp
 */
for (i = 0; i < port->nr_source_caps; i++) {
u32 pdo = port->source_caps[i];
enum pd_pdo_type type = pdo_type(pdo);
+   unsigned int mv, ma, mw;
 
-   if (type == PDO_TYPE_FIXED) {
-   for (j = 0; j < port->nr_fixed; j++) {
-   if (pdo_fixed_voltage(pdo) ==
-   pdo_fixed_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;
-   }
-   /* There could only be one fixed pdo
-* at a specific voltage level.
-* So breaking here.
-*/
-   break;
-   }
-   }
-   } else if (type == PDO_TYPE_BATT) {
-   for (j = port->nr_fixed;
-j < port->nr_fixed +
-port->nr_batt;
-j++) {
-   if (pdo_min_voltage(pdo) >=
-pdo_min_voltage(port->snk_pdo[j]) &&
-pdo_max_voltage(pdo) <=
-pdo_max_voltage(port->snk_pdo[j])) {
-   mw = min_power(pdo, port->snk_pdo[j]);
-   mv = pdo_min_voltage(pdo);
-   if (mw > max_mw ||
-   (mw == max_mw && mv > max_mv)) {
-

Re: [PATCH 2/2] usb: gadget: udc: renesas_usb3: add binging for r8a77965

2018-03-06 Thread Simon Horman 
On Tue, Feb 27, 2018 at 05:16:03PM +0900, Yoshihiro Shimoda wrote:
> This patch adds binding for r8a77965 (R-Car M3-N).
> 
> Signed-off-by: Yoshihiro Shimoda 

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

Re: [PATCH 1/2] usb: renesas_usbhs: add binding for r8a77965

2018-03-06 Thread Simon Horman 
On Tue, Feb 27, 2018 at 05:16:02PM +0900, Yoshihiro Shimoda wrote:
> This patch adds binding for r8a77965 (R-Car M3-N).
> 
> Signed-off-by: Yoshihiro Shimoda 

Reviewed-by: Simon Horman 

--
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 10/12] dt-bindings: connector: add properties for typec power delivery

2018-03-06 Thread Jun Li 
Hi
> -Original Message-
> From: Andrzej Hajda [mailto:a.ha...@samsung.com]
> Sent: 2018年3月5日 17:59
> To: Jun Li ; gre...@linuxfoundation.org;
> robh...@kernel.org; heikki.kroge...@linux.intel.com; li...@roeck-us.net
> Cc: mark.rutl...@arm.com; yue...@google.com; Peter Chen
> ; garsi...@embeddedor.com; o_leve...@orange.fr;
> shufan_...@richtek.com; linux-usb@vger.kernel.org;
> devicet...@vger.kernel.org; dl-linux-imx 
> Subject: Re: [PATCH v2 10/12] dt-bindings: connector: add properties for
> typec power delivery
> 
> On 05.03.2018 08:00, Jun Li wrote:
> >
> >> -Original Message-
> >> From: Andrzej Hajda [mailto:a.ha...@samsung.com]
> >> Sent: 2018年2月27日 16:41
> >> To: Jun Li ; gre...@linuxfoundation.org;
> >> robh...@kernel.org; heikki.kroge...@linux.intel.com;
> >> robh+li...@roeck-us.net
> >> Cc: mark.rutl...@arm.com; yue...@google.com; Peter Chen
> >> ; garsi...@embeddedor.com;
> o_leve...@orange.fr;
> >> shufan_...@richtek.com; linux-usb@vger.kernel.org;
> >> devicet...@vger.kernel.org; dl-linux-imx 
> >> Subject: Re: [PATCH v2 10/12] dt-bindings: connector: add properties
> >> for typec power delivery
> >>
> >> On 26.02.2018 12:49, Li Jun wrote:
> >>> In case of usb-c-connector with power delivery support, add
> >>> bingdings supported by current typec driver, so user can pass all
> >>> those properties via dt.
> >>>
> >>> Signed-off-by: Li Jun 
> >>> ---
> >>> Changes for v2:
> >>> - Added typec properties are based on general usb connector bindings[1]
> >>>   proposed by Andrzej Hajda.
> >>> - Use the standard unit suffixes as defined in property-units.txt.
> >>>
> >>> [1]
> >>>
> >>
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpa
> >> t
> >>
> chwork.kernel.org%2Fpatch%2F10231447%2F=02%7C01%7Cjun.li%40
> >> nxp.co
> >>
> m%7Cccf14a36ca6445ee5f1108d57dbde3c7%7C686ea1d3bc2b4c6fa92cd99
> >> c5c30163
> >>
> 5%7C0%7C0%7C636553176880292197=2Pi0AtiwAqHQE3rGl%2Bo49K
> >> 7yZZcp%2B
> >>> 5bvJAknRBMGTrk%3D=0
> >>>
> >>>  .../bindings/connector/usb-connector.txt   | 43
> >> ++
> >>>  1 file changed, 43 insertions(+)
> >>>
> >>> diff --git
> >>> a/Documentation/devicetree/bindings/connector/usb-connector.txt
> >>> b/Documentation/devicetree/bindings/connector/usb-connector.txt
> >>> index e1463f1..242f6df 100644
> >>> --- a/Documentation/devicetree/bindings/connector/usb-connector.txt
> >>> +++
> b/Documentation/devicetree/bindings/connector/usb-connector.txt
> >>> @@ -15,6 +15,30 @@ Optional properties:
> >>>  - type: size of the connector, should be specified in case of USB-A,
> USB-B
> >>>non-fullsize connectors: "mini", "micro".
> >>>
> >>> +Required properties for usb-c-connector with power delivery support:
> >>> +- port-type: should be one of "source", "sink" or "dual".
> >>> +- default-role: preferred power role if port-type is "dual"(drp),
> >>> +should be
> >>> +  "sink" or "source".
> >> Since port carries data and power, it would be better to explicitly
> >> mention it in names of properties which can be ambiguous.
> >> Maybe instead of 'port-type' you can use 'power-role', for example.
> > Port-type is align with the name of typec coding and ABI, 'power-role'
> > is more like for the current role rather than the port's ability.
> 
> I am not sure what are you exactly mean by "coding and ABI", but I guess it is
> just about Power-Delivery part of USB-C. And if you want to put this property
> into USB node without mark it is related to PD part of USB connector, you
> risk confusion with possible USB data related properties.

Understood your concern, I am following typec naming conventions,
for typec, port-type property has the same meaning as
/sys/class/typec/portx/port_type
which is not only for power, also for data, there are dedicated
sys files power_role for power and data_role for data.

> Simple question, what if somebody wants to add property describing USB
> data capabilities (DFP, UFP, DRD), how should it be named?
> 

Then we may use data-role?

> >
> >> Other thing is that default-role is required only in case of DRP, so
> >> maybe better would be to squash it in power-role, for example:
> >>     power-role: should be on of "source", "sink", "dual-source",
> >> "dual-sink", in case of dual roles suffix determines preferred role.
> > I don't know how much this squash can benefit, "dual-source/sink" is
> > not directly showing its meaning by name.
> 
> Some benefit is simpler binding, no conditionally-required property.
> 

There is already string definition for port type and preferred role parse 
static const char * const typec_port_types[] = {
 [TYPEC_PORT_DFP] = "source",
 [TYPEC_PORT_UFP] = "sink",
 [TYPEC_PORT_DRP] = "dual",
};
And I think there will be other conditionally-required properties
to be extended later, are we going to name all of them by this way?
Either

Re: [PATCH] usb: host: xhci-rcar: add support for r8a77965

2018-03-06 Thread Simon Horman 
On Tue, Feb 27, 2018 at 05:15:20PM +0900, Yoshihiro Shimoda wrote:
> This patch adds support for r8a77965 (R-Car M3-N).
> 
> Signed-off-by: Yoshihiro Shimoda 

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

[PATCH resend] usb: quirks: add control message delay for 1b1c:1b20

2018-03-06 Thread Danilo Krummrich 
Corsair Strafe RGB keyboard does not respond to usb control messages
sometimes and hence generates timeouts.

Commit de3af5bf259d ("usb: quirks: add delay init quirk for Corsair
Strafe RGB keyboard") tried to fix those timeouts by adding
USB_QUIRK_DELAY_INIT.

Unfortunately, even with this quirk timeouts of usb_control_msg()
can still be seen, but with a lower frequency (approx. 1 out of 15):

[   29.103520] usb 1-8: string descriptor 0 read error: -110
[   34.363097] usb 1-8: can't set config #1, error -110

Adding further delays to different locations where usb control
messages are issued just moves the timeouts to other locations,
e.g.:

[   35.400533] usbhid 1-8:1.0: can't add hid device: -110
[   35.401014] usbhid: probe of 1-8:1.0 failed with error -110

The only way to reliably avoid those issues is having a pause after
each usb control message. In approx. 200 boot cycles no more timeouts
were seen.

Addionaly, keep USB_QUIRK_DELAY_INIT as it turned out to be necessary
to have the delay in hub_port_connect() after hub_port_init().

The overall boot time seems not to be influenced by these additional
delays, even on fast machines and lightweight distributions.

Fixes: de3af5bf259d ("usb: quirks: add delay init quirk for Corsair Strafe RGB 
keyboard")
Cc: sta...@vger.kernel.org
Signed-off-by: Danilo Krummrich 
---
 drivers/usb/core/message.c | 4 
 drivers/usb/core/quirks.c  | 3 ++-
 include/linux/usb/quirks.h | 3 +++
 3 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/core/message.c b/drivers/usb/core/message.c
index c64cf6c4a83d..0c11d40a12bc 100644
--- a/drivers/usb/core/message.c
+++ b/drivers/usb/core/message.c
@@ -151,6 +151,10 @@ int usb_control_msg(struct usb_device *dev, unsigned int 
pipe, __u8 request,
 
ret = usb_internal_control_msg(dev, pipe, dr, data, size, timeout);
 
+   /* Linger a bit, prior to the next control message. */
+   if (dev->quirks & USB_QUIRK_DELAY_CTRL_MSG)
+   msleep(200);
+
kfree(dr);
 
return ret;
diff --git a/drivers/usb/core/quirks.c b/drivers/usb/core/quirks.c
index f4a548471f0f..54b019e267c5 100644
--- a/drivers/usb/core/quirks.c
+++ b/drivers/usb/core/quirks.c
@@ -230,7 +230,8 @@ static const struct usb_device_id usb_quirk_list[] = {
{ USB_DEVICE(0x1b1c, 0x1b13), .driver_info = USB_QUIRK_DELAY_INIT },
 
/* Corsair Strafe RGB */
-   { USB_DEVICE(0x1b1c, 0x1b20), .driver_info = USB_QUIRK_DELAY_INIT },
+   { USB_DEVICE(0x1b1c, 0x1b20), .driver_info = USB_QUIRK_DELAY_INIT |
+ USB_QUIRK_DELAY_CTRL_MSG },
 
/* Corsair K70 LUX */
{ USB_DEVICE(0x1b1c, 0x1b36), .driver_info = USB_QUIRK_DELAY_INIT },
diff --git a/include/linux/usb/quirks.h b/include/linux/usb/quirks.h
index f1fcec2fd5f8..b7a99ce56bc9 100644
--- a/include/linux/usb/quirks.h
+++ b/include/linux/usb/quirks.h
@@ -63,4 +63,7 @@
  */
 #define USB_QUIRK_DISCONNECT_SUSPEND   BIT(12)
 
+/* Device needs a pause after every control message. */
+#define USB_QUIRK_DELAY_CTRL_MSG   BIT(13)
+
 #endif /* __LINUX_USB_QUIRKS_H */
-- 
2.16.2

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

Re: [PATH 0/4] usbip: make vhci_hcd.* objects independent of vhci_hcd.0

2018-03-06 Thread Salvador Fandiño 



On 03/06/2018 01:03 AM, Shuah Khan wrote:

On 03/05/2018 02:00 AM, Salvador Fandiño wrote:

On 02/21/2018 01:35 AM, Shuah Khan wrote:

Hi Salvador,

On 01/30/2018 01:36 AM, Salvador Fandino wrote:

Let me start by explaining the problem that have motivated me to write
this patches:

I work on the QVD, a virtual desktop platform for Linux. This software
runs Linux desktops (i.e. XFCE, KDE) and their applications inside LXC
containers, and makes then available through the network to remote
users.

Supporting USB devices is a common feature customers have been
requesting us for a long time (in order to use, for instance, remote
signature pads, bar-code scanners, fingerprint readers, etc.). So, we
have been working on that feature using the USB/IP layer on the
kernel.

Connecting and disconnecting devices and transferring data works
seamless for the devices listed above. But we also want to make the
usbip operations private to the container where they are run.  For
instance, it is unacceptable for our product, that one user could list
the devices connected by other users or access them.

We can control how can access every device using cgroups once those
are attached, but the usbip layer is not providing any mechanism for
controlling who can attach, detach or list the devices.

In this use-case:

- does a container act as usbip client and attach devices from their
   host?
- do containers attach remote devices from other systems?
In my particular case devices are imported from remote machines. But 
well, the thing is that I don't care where the connections come from, 
they could even be devices emulated in user space.



Is the core of the problem really that any remote system can import without
a provision for being able to restrict export to a set of remote machines?
If so, this is a generic problem even without containers and I would like
to solve this with a generic solution that works in all cases, not just for
containers.
No, that is a different issue. You are talking about controlling which 
devices can be connected, from which hosts, etc. That is an interesting 
problem but not the one I am trying to tackle here.


I don't mind which every user does inside its container as far as it 
does not interfere which other users. In practice that means:


1- Not being able to attach/detach devices in other containers
2- Not being able to list devices attached in other containers
3- Not being able to access devices attached in other containers.

Point 3 is already enforceable using the devices hierarchy in cgroups. 
For points 1 and 2, my proposition is making every vhci_hcd device have 
its own fully independent sysfs directory (instead of all of them going 
through vhci_hcd.0) so that they can be selectively exposed with rw 
permissions inside the containers.





The approach in this patch series appears to solve the problem just for
containers.


Did you explore a solution to add a mechanism for access control to
usbip?

Could you elaborate on that?

For "usbip", do you mean the user space tools?
If that is the case, I don't think it would be enough.
My aim is to limit vhci usage from containers and I have no control about what runs 
inside the containers. So, a mangled usbip tool-set could > > be used by a 
malicious user to circumvent any access control set there.>

I mean the driver. There might be changes necessary in the user-space
as well depending on how the access controls are implemented. I am not
proposing implementing access controls in the user-space.



IMO, there is no other choice but to control access to VHCI at the kernel level.


Probably. Please give as many details as possible on your environment
for me to make a call on if this problem can be solved in a different
way.


In our particular real life application, we are targeting the kernel 
interface directly, we don't use the usbip tools at all. It is that way 
because we have our own* transport layer, authentication and 
authorization mechanisms. And once all the handshaking is done we end 
with a socket we can directly pass to the kernel in order to get it 
attached to a vhci_hcd port. We don't like having an extra application 
listening on some TCP port which can be accessed by third parties on the 
client side either.


The imported USB devices used are mostly devices which do not require 
kernel modules and that are accessed though libusb by the applications 
(i.e., id card readers, barcode scanners, signing pads, etc.).


* Just in case you want to know, USBIP data goes through a channel in a 
nx (https://github.com/ArcticaProject/nx-libs) connection running over a 
websocket over TLS. Authentication is performed by the broker (a proxy 
which knows where a user containers are running). Authorization is 
performed following policies configured by the administrator (currently 
it is just an all or nothing policy: USPIP is allowed or not) by the 
control application at container creation time.



--
To unsubscribe from this list:

[PATCH] USB: serial: cp210x: add ELDAT Easywave RX09 id

2018-03-06 Thread Johan Hovold 
Add device id for ELDAT Easywave RX09 tranceiver.

Reported-by: Jan Jansen 
Cc: stable 
Signed-off-by: Johan Hovold 
---
 drivers/usb/serial/cp210x.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/usb/serial/cp210x.c b/drivers/usb/serial/cp210x.c
index 06d502b3e913..de1e759dd512 100644
--- a/drivers/usb/serial/cp210x.c
+++ b/drivers/usb/serial/cp210x.c
@@ -155,6 +155,7 @@ static const struct usb_device_id id_table[] = {
{ USB_DEVICE(0x12B8, 0xEC62) }, /* Link G4+ ECU */
{ USB_DEVICE(0x13AD, 0x) }, /* Baltech card reader */
{ USB_DEVICE(0x1555, 0x0004) }, /* Owen AC4 USB-RS485 Converter */
+   { USB_DEVICE(0x155A, 0x1006) }, /* ELDAT Easywave RX09 */
{ USB_DEVICE(0x166A, 0x0201) }, /* Clipsal 5500PACA C-Bus Pascal 
Automation Controller */
{ USB_DEVICE(0x166A, 0x0301) }, /* Clipsal 5800PC C-Bus Wireless PC 
Interface */
{ USB_DEVICE(0x166A, 0x0303) }, /* Clipsal 5500PCU C-Bus USB interface 
*/
-- 
2.16.2

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

Re: High CPU load produced by USB (DW2)

2018-03-06 Thread Minas Harutyunyan 
Hi,

On 3/6/2018 10:45 AM, Minas Harutyunyan wrote:
> Hi,
> 
> On 3/5/2018 11:14 PM, Marek Vasut wrote:
>> On 02/20/2018 06:51 AM, Minas Harutyunyan wrote:
>> [...]
>> Is there a way to reduce that or is that the absolute minimum in HS mode?
>>
> We already discussed, in this email thread earlier, why SOF interrupts
> required and unmasked.
> Only in case when connected device with CTRL+BLK EP's only (like flash
> drive) and directly connected to cores root HUB, SOF's will be masked.

 That's the setup I have on Altera SoCFPGA, yet the SOFs are still present.

>>> Could you please send verbose lsusb on connected to dwc2 device
>>
>> See attached
>>
>>> and driver debug log.
>>
>> What exactly do you mean by this one ?
> Enable debugging messages and verbose debugging messages for dwc2 from
> make menuconfig. Provide dmesg starting from dwc2 load till HS device
> connected to dwc2 port and enumerated.
> 
> Thanks,
> Minas
> 
>>
> 
> 
Driver debug log not required.
Based on lsusb output: to dwc2 port connected "Standard Microsystems 
Corp. USB 2.0 Hub" to which connected your HS device "SanDisk Corp. 
Ultra". Because of connected HUB, which have periodic endpoint 
(Interrupt IN EP1) like all HUB's, dwc2 forced in Buffer DMA mode unmask 
SOF interrupts.

Thanks,
Minas



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