linux-kernel - Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 21 Jun 2016 10:26:00 +0300
From:	Felipe Balbi <balbi@...nel.org>
To:	Peter Chen <hzpeterchen@...il.com>
Cc:	Roger Quadros <rogerq@...com>, peter.chen@...escale.com,
	tony@...mide.com, gregkh@...uxfoundation.org,
	dan.j.williams@...el.com, mathias.nyman@...ux.intel.com,
	Joao.Pinto@...opsys.com, sergei.shtylyov@...entembedded.com,
	jun.li@...escale.com, grygorii.strashko@...com,
	yoshihiro.shimoda.uh@...esas.com, robh@...nel.org, nsekhar@...com,
	b-liu@...com, joe@...ches.com, linux-usb@...r.kernel.org,
	linux-omap@...r.kernel.org, linux-kernel@...r.kernel.org,
	devicetree@...r.kernel.org
Subject: Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core


Hi,

Peter Chen <hzpeterchen@...il.com> writes:
>> >> > It provides APIs for the following tasks
>> >> >
>> >> > - Registering an OTG/dual-role capable controller
>> >> > - Registering Host and Gadget controllers to OTG core
>> >> > - Providing inputs to and kicking the OTG state machine
>> >> 
>> >> I think I have already mentioned this, but after over 10 years of OTG,
>> >> nobody seems to care about it, why are we still touching at all I don't
>> >> know. For common non-OTG role-swapping we really don't need any of this
>> >> and, quite frankly, I fail to see enough users for this.
>> >> 
>> >> Apparently there's only chipidea which, AFAICT, already had working
>> >> dual-role before this OTG State Machine was added to the kernel.
>> >
>> > Some users would like to know if vendor's platform is OTG compliance,
>> > so we add it to pass usb.org USB OTG certification test.
>> 
>> I strongly doubt that's really what they mean. IMHO, users want to know
>> if they can swap roles. Ask them if they are really going for OTG
>> certification. Ask them if they have an OPT tester. Ask them if they
>> really want all those timers. If they want HNP polling, etc etc etc.
>> 
>> So far, I haven't seen anybody talking about real USB OTG (the spec)
>> when they say OTG. Usually they just mean "a method for swapping between
>> host and peripheral roles, but we really don't want all the extra cost
>> of the OTG specification".
>> 
>
> That's what I thought before, but the request from the Marketing guy is
> "To prove the SoC is OTG compliance, support HNP and SRP", don't you
> see the SoC reference manual say "it supports HNP and SRP"?
>
> If there is no request, who else wants to implement so complicated FSM
> but seldom use cases, and go to pass OTG compliance test (tested by PET).

I stand corrected :-)

So there is one user for this layer. And this user has its own role
control registers. I'm not convinced we need this large generic layer
for one user.

>> > For the real use case, some Carplay platforms need it.
>> 
>> Carplay does *NOT* rely on OTG. Apple has its own proprietary and closed
>> specification which is not OTG-compliant.
>> 
>
> Yes, it is not OTG-compliant, but it can co-work with some standard OTG FSM
> states to finish role swap.

What are you referring to as "finish role swap"? I don't get that.

> Notice, it needs to swap role without disconnect cable.

right, I can swap role without changing cable, but that's not OTG. The
mechanism for that, AFAICT, is not HNP. I don't know details about
CarPlay because the spec isn't public, but my understanding is that
CarPlay doesn't rely on anything from OTG spec.

>> >> > diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
>> >> > index f4fc0aa..1d74fb8 100644
>> >> > --- a/include/linux/usb/gadget.h
>> >> > +++ b/include/linux/usb/gadget.h
>> >> > @@ -328,6 +328,7 @@ struct usb_gadget_ops {
>> >> >   * @in_epnum: last used in ep number
>> >> >   * @mA: last set mA value
>> >> >   * @otg_caps: OTG capabilities of this gadget.
>> >> > + * @otg_dev: OTG controller device, if needs to be used with OTG core.
>> >> 
>> >> do you really know of any platform which has a separate OTG controller?
>> >> 
>> >
>> > It may not be a real separate OTG controller. It can be a hardware part
>> > (external connector, external IC, SoC OTG register area, etc) to handle vbus
>> > ,id and other signals which are used for role swap.
>> 
>> That's already solved. EXTCON solved that years back and OMAP has been
>> using EXTCON to program its UTMI mailbox.
>> 
>
> No, that's not the same thing, it does not include the swap role.

Read your original comment:

"handle vbus, id and other signals which are *used for* role swap"

You didn't include role swap in your original comment. Semantics aside...

> Consider the use case the host driver is at host/ and udc driver is
> at gadget/udc, how to finish to role swap?

... why does the source code placement matter? And what do you mean by
"finish role swap"?

-- 
balbi

Download attachment "signature.asc" of type "application/pgp-signature" (819 bytes)