linux-kernel - Re: [PATCH v3 00/11] USB: OTG/DRD Core functionality

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]

Message-ID: <CAL1qeaEkpUq3mzZXpr2gxceW3q_zHLspWUv9qxBP8q_1+_g-OA@mail.gmail.com>
Date:	Thu, 16 Jul 2015 11:29:58 -0700
From:	Andrew Bresticker <abrestic@...omium.org>
To:	Roger Quadros <rogerq@...com>
Cc:	Alan Stern <stern@...land.harvard.edu>,
	Felipe Balbi <balbi@...com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Peter Chen <peter.chen@...escale.com>,
	Dan Williams <dan.j.williams@...el.com>, jun.li@...escale.com,
	Mathias Nyman <mathias.nyman@...ux.intel.com>,
	Tony Lindgren <tony@...mide.com>, Joao.Pinto@...opsys.com,
	"linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	linux-omap@...r.kernel.org,
	"linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>
Subject: Re: [PATCH v3 00/11] USB: OTG/DRD Core functionality

Hi Roger,

On Wed, Jul 15, 2015 at 6:26 AM, Roger Quadros <rogerq@...com> wrote:
> Hi Andrew,
>
> On 13/07/15 22:14, Andrew Bresticker wrote:
>> Hi Roger,
>>
>> On Wed, Jul 8, 2015 at 3:19 AM, Roger Quadros <rogerq@...com> wrote:
>>> Usage model:
>>> -----------
>>>
>>> - The OTG controller device is assumed to be the parent of
>>> the host and gadget controller. It must call usb_otg_register()
>>> before populating the host and gadget devices so that the OTG
>>> core is aware that it is an OTG device before the host & gadget
>>> register. The OTG controller must provide struct otg_fsm_ops *
>>> which will be called by the OTG core depending on OTG bus state.
>>
>> I'm wondering if the requirement that the OTG controller be the parent
>> of the USB host/device-controllers makes sense.  For some context, I'm
>> working on adding dual-role support for Tegra210, specifically on a
>> system with USB Type-C.  On Tegra, the USB host-controller and USB
>> device-controller are two separate IP blocks (XUSB host and XUSB
>> device) with another, separate, IP block (XUSB padctl) for the USB PHY
>> and OTG support.  In the non-Type-C case, your OTG framework could
>> work well, though it's debatable as to whether or not the XUSB padctl
>> device should be a parent to the XUSB host/device-controller devices
>> (currently it isn't - it's just a PHY provider).  But in the Type-C
>> case, it's an off-chip embedded controller that determines the
>> dual-role status of the Type-C port, so the above requirement doesn't
>> make sense at all.
>>
>> My idea was to have the OTG/DRD controller explicitly specify its host
>> and device controllers, so in DT, something like:
>>
>> otg-controller {
>>     ...
>>     device-controller = <&usb_device>;
>>     host-controller = <&usb_host>;
>>     ...
>> };
>>
>> usb_device: usb-device@.... {
>>     ...
>> };
>>
>> usb_host: usb-host@... {
>>     ...
>> };
>>
>> What do you think?
>
> I agree that we need to support your use case but how to do it
> is not yet clear to me.
>
> In your above example the otg controller knows what are the host
> and gadget controllers but the host/gadget devices don't
> know who is their otg controller.
>
> So the problem is that when usb_otg_register_hcd/gadget() is called
> we need to get a handle to the otg controller.
>
> One solution I see is to iterate over the registered otg_controller_list
> and check if we match the host/gadget controller in there.
>
> Then there is also a possibility that host/gadget controllers get
> registered before the OTG controller. Then we can't know for sure if
> the host/gadget controller was meant for dual-role operation or not
> and it will resort to single role operation.
>
> Any idea to prevent the above situation?
>
> Maybe we need to add some logic in host/gadget cores to check if the port
> is meant for dual-role use and defer probe if OTG controller is not yet
> registered?

In the DT case, I think we could add an "otg-controller" property to
the host and gadget nodes, and in usb_otg_register_{hcd,gadget}()
check for that property and defer probe if the referenced OTG
controller has not yet been registered.  Not sure how to indicate that
a host/gadget is meant for dual-role operation on non-DT platforms
though.

Thanks,
Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/