Re: [PATCH 0/2] usb: add HCD providers

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 13 July 2016 at 10:02, Peter Chen <hzpeterchen@xxxxxxxxx> wrote:
> On Wed, Jul 13, 2016 at 07:21:09AM +0200, Rafał Miłecki wrote:
>> On 13 July 2016 at 06:51, Peter Chen <hzpeterchen@xxxxxxxxx> wrote:
>> > On Tue, Jul 12, 2016 at 02:35:18PM +0200, Rafał Miłecki wrote:
>> >> I was working on an "usbport" LED trigger driver and specifying its
>> >> default state in DT. I realized I can't really determine numbering of
>> >> USB ports on any device as it depends on compiled drivers and the
>> >> loading orders.
>> >>
>> >> It means that my physical USB port can be e.g. 1-1 or 2-1 depending on
>> >> my current config/setup. I needed a way to specify a particular HCD in
>> >> DT and then hardcode port number (as this part doesn't change).
>> >>
>> >
>> > I have a question:
>> >
>> > What does your "usbport" LED trigger for? What kinds of information
>> > you would like to show on LED?
>>
>> It's a trigger that turns on LED whenever USB device appears at
>> specified USB port. There are plenty of home routers that have USB
>> labeled LED(s). To support them nicely, first of all we need a trigger
>> that will watch for USB subsystem events. Secondly we need a way to
>> setup its initial state correctly as most users don't want to play
>> with sysfs on their own.
>>
>> I sent usbport trigger in:
>> [PATCH] leds: trigger: Introduce an USB port trigger
>> <1468239883-22695-1-git-send-email-zajec5@xxxxxxxxx>
>> https://lkml.org/lkml/2016/7/11/305
>> You may read commit message and ledtrig-usbport.txt for more details.
>>
>
> Well, it is an interesting use case. You can try to add provider (un)register
> at hub driver (drivers/usb/core/hub.c) instead of each platform drivers, you
> could refer my USB pwrseq as an example[1].

That was my initial plan, but then I realized we can have more complex
cases with few HCDs per single device (and device_node). Take a look
at dummy_hcd.c, xhci-mtk.c and xhci-plat.c. All of them register two
HCDs: a shared one and primary one. In above drivers I planned to have
custom xlate function with support for an extra argument. I was
thinking about something like:
usb-controllers = <&ohci>, <&ehci>, <&xhci USB_HCD_SHARED>;

Now you made me look closer at controller drivers, I'm not so sure
what is the best way for this.
We have ~65 drivers registering only one HCD and ~26 of them use DT.
We should modify at least those ~26 ones to register a provider.
So maybe it's indeed better to add providers in a generic way,
probably just inside usb_add_hcd. We could make generic xlate function
aware of primary and shared HCDs. Hopefully there won't be way more
complicate cases in the future, like a single controller driver
registering 3, 4 or more HCDs. If that ever happens, we can always
modify usb_add_hcd to somehow tell it to don't register providers in
such cases.


> For roothub, you can get the busnum through comparing controller's of_node, for
> internal hub, you can get hub's dev name like (1-1) through comparing
> its of_node (you need to describe your hard-wired hub on dts).

I'm not really sure what do you mean here. I believe my
of_hcd_get_from_provider already does compare controller's of_node?

When working with internal hubs I never meant to reference them in DT.
I meant to reference root hub only and then hardcode the rest of
"path". For example my old BCM4706 device (MIPS supported by bcm47xx
without DT) has internal
05e3:0608 Genesys Logic, Inc. USB-2.0 4-Port HUB
connected to the 1-1. It has 2 physical USB connectors, if I connect
USB device to the "upper" one it appears as 1-1.1, if I connect to the
"lower" it appears as 1-1.2.
In such case (if bcm47xx was using DT) I'd only need reference to "1"
root hub bus number and I could hardcode "1.1" and "1.2" in DT.


> Two more questions:
>
> - How to support the USB device on the port when boots up?

It's not supported by my usbport trigger driver yet. I'll probably
support it by calling usb_find_device_by_name whenever a new entry
gets added to the list of monitored ports.


> - Any cases we need to add mapping using new_port_store, the user may
> not know bus number for physical port.

Initially I implemented new_port_store for my testing purposes but I
think it may be useful for platforms without DT. It would allow some
user space scripts to add proper entries.

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



[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]
  Powered by Linux