From: "Rafał Miłecki" <zajec5@gmail.com>
To: Peter Chen <hzpeterchen@gmail.com>
Cc: Felipe Balbi <felipe.balbi@linux.intel.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
"open list:LED SUBSYSTEM" <linux-leds@vger.kernel.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>
Subject: Re: [PATCH V2 0/1] usb: add HCD providers
Date: Fri, 15 Jul 2016 11:35:41 +0200 [thread overview]
Message-ID: <CACna6rxuaVwLirwc982ifd0riwRodb5WgJ51npd1uDeDkYU0dg@mail.gmail.com> (raw)
In-Reply-To: <20160715062209.GC817@shlinux2>
On 15 July 2016 at 08:22, Peter Chen <hzpeterchen@gmail.com> wrote:
> On Fri, Jul 15, 2016 at 07:48:11AM +0200, Rafał Miłecki wrote:
>> >> > Below I supply another thought, please check if it is feasible.
>> >> > In below design, you don't need to change any usb codes.
>> >> >
>> >> > dts:
>> >> >
>> >> > led_1 {
>> >> > led_gpio_1;
>> >> > usb_port = &ohci_port0, &ehci_port1;
>> >> > }
>> >> >
>> >> > led_2 {
>> >> > led_gpio_2;
>> >> > usb_port = &xhci_port0, &xhci_port1;
>> >> > }
>> >> >
>> >> > ohci@1000 {
>> >> > compatible = "generic-ohci";
>> >> > reg = <0x00001000 0x1000>;
>> >> > interrupts = <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>;
>> >> >
>> >> > ohci_port0: port@0 {
>> >> > reg = <0>;
>> >> > };
>> >> >
>> >> > ohci_port1: port@1 {
>> >> > reg = <1>;
>> >> > };
>> >> > };
>> >> >
>> >> > ehci@2000 {
>> >> > compatible = "generic-ehci";
>> >> > reg = <0x00002000 0x1000>;
>> >> > interrupts = <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>;
>> >> >
>> >> > ehci_port0: port@0 {
>> >> > reg = <0>;
>> >> > };
>> >> >
>> >> > ehci_port1: port@1 {
>> >> > reg = <1>;
>> >> > };
>> >> > };
>> >> >
>> >> > xhci@3000 {
>> >> > compatible = "generic-xhci";
>> >> > reg = <0x00003000 0x1000>;
>> >> > interrupts = <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>;
>> >> >
>> >> > /* for xhci, port 0 - [N-1] is USB3, N - [M-1] is USB2/1.
>> >> > * The port 0 and port N is the same physical port
>> >> > */
>> >> > xhci_port0: port@0 {
>> >> > reg = <0>;
>> >> > };
>> >> >
>> >> > xhci_port1: port@1 {
>> >> > reg = <1>;
>> >> > };
>> >> >
>> >> > };
>> >> >
>> >> > At code, compare the usb_device's device_node at usbport_trig_notify
>> >> > if it is at led_1's usb device list, light on it.
>> >>
>> >> This is quite interesting idea, thanks!
>> >>
>> >> So I got following checking code:
>> >>
>> >> count = of_count_phandle_with_args(np, "usb-ports", NULL);
>> >> for (i = 0; i < count; i++) {
>> >> of_parse_phandle_with_args(np, "usb-ports", NULL, i, &args);
>> >> of_property_read_u32(args.np, "reg", &port);
>> >> if (args.np->parent == usb_dev->bus->controller->of_node &&
>> >> port == usb_dev->portnum) {
>> >> of_node_put(args.np);
>> >> return true;
>> >> }
>> >> of_node_put(args.np);
>> >> }
>> >> return false;
>> >
>> > No, compares the USB port directly.
>> >
>> > count = of_count_phandle_with_args(np, "usb-ports", NULL);
>> > for (i = 0; i < count; i++) {
>> > of_parse_phandle_with_args(np, "usb-ports", NULL, i, &args);
>> > if (args.np == usb_dev->dev.of_node)
>> > of_node_put(args.np);
>> > return true;
>> > }
>> > of_node_put(args.np);
>> > }
>> > return false;
>>
>> If we mean to use usb_dev->dev.of_node I *need* to modify USB
>> subsystem, since this pointer is never being set by the current code.
>>
>> [ 71.410505] usb 1-1: new high-speed USB device number 2 using ehci-platform
>> [ 71.564928] [usbport_trig_notify] usb_dev:c6ac1000 &usb_dev->dev:c6ac1068
>> [ 71.579874] [usbport_trig_notify] dev_name(&usb_dev->dev):1-1
>> [ 71.586580] [usbport_trig_notify] usb_dev->dev.of_node: (null)
>>
>> Or am I missing something?
>>
>
> You may need below patches:
>
> commit 69bec725985324e79b1c47ea287815ac4ddb0521
> Author: Peter Chen <peter.chen@freescale.com>
> Date: Fri Feb 19 17:26:15 2016 +0800
>
> USB: core: let USB device know device node
>
> commit 7222c832254a75dcd67d683df75753d4a4e125bb
> Author: Nicolai Stange <nicstange@gmail.com>
> Date: Thu Mar 17 23:53:02 2016 +0100
>
> usb/core: usb_alloc_dev(): fix setting of ->portnum
F*k, I just implemented the same thing on my own and I was going to
submit it :/ Thanks for pointing these commits.
>> >> This works, but I see 3 more problems:
>> >>
>> >> 1) How to access list of available USB devices during activation?
>> >
>> > You mean during LED activation? eg your usbport_trig_activate?
>> > Why do you need it?
>>
>> Yes, I mean usbport_trig_activate. If user plugs in USB device and
>> *then* activates this trigger, we want to set a proper initial state.
>> We can't only depend on USB_DEVICE_ADD.
>>
>
> Oh, I see, I asked it before.
>
> Either you need to register USB notifier before activation
It won't work if someone builds usbport as a module and loads it after
connecting USB devices.
> Or you need to implement something like usb_node_to_dev
> eg: like usb_for_each_dev. If device's state is USB_STATE_CONFIGURED
> this USB device is available.
I think I'll need that.
>> >> 2) What about support for non-DT platforms in usbport driver? Should I
>> >> still allow specifying ports manually? Are you OK with that?
>> >
>> > I am afraid I still don't know how to do it for non-DT platforms.
>> > You can show your design.
>>
>> Please take a look at
>> [PATCH] leds: trigger: Introduce an USB port trigger
>> https://lkml.org/lkml/2016/7/11/305
>>
>> Basically my idea was to support:
>> echo usbport > trigger
>> echo 4-1 > new_port
>> echo 2-1 > new_port
>>
>
> I know your patch, how you plan to support non-DT platforms before?
I didn't have any better idea than just letting user space do some
magic. I don't think we can develop any clever solution for non-DT but
I still want to give these platforms some options. I think I can live
with some more tricky code in user space.
>> >> 3) What about devices with internal hubs? Should we describe their USB
>> >> ports in DT as well? Any idea how to do this?
>> >
>> > Well, the HUB must be hard-wired on board for this LED trigger case.
>> > So, you can described USB topology well at dts. Please note: the
>> > USB port phandle at LED node is the physical connector on board which
>> > the user can plug in USB device, it may be 2nd or more levels from the
>> > controller.
>> >
>> > Below is the example for how to describe 3 levels USB devices, the
>> > USB ethernet port (axis) is one of the ports at internal HUB (genesys).
>> >
>> > http://www.spinics.net/lists/linux-usb/msg143698.html
>>
>> Thanks for this example. I'm only afraid there isn't a way to say what
>> port "ethernet: asix@1" is attached to.
>
> Why? You know your hardware design, you should know the topology, eg
> This physical port is from ehci port, and which port number for its
> internal hub port number. If not, how we describe USB devices on
> dts.
Please ignore that question.
--
Rafał
prev parent reply other threads:[~2016-07-15 9:35 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-12 12:35 [PATCH 0/2] usb: add HCD providers Rafał Miłecki
2016-07-12 12:35 ` [PATCH 1/2] usb: core: add support for " Rafał Miłecki
[not found] ` <1468326921-26485-2-git-send-email-zajec5-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-08-09 13:56 ` Greg Kroah-Hartman
2016-07-12 12:35 ` [PATCH 2/2] ohci-platform: register HCD provider Rafał Miłecki
2016-07-12 12:35 ` [PATCH PROOF OF CONCEPT 3/2] trigger: ledtrig-usbport: read initial state from DT Rafał Miłecki
2016-07-13 4:51 ` [PATCH 0/2] usb: add HCD providers Peter Chen
2016-07-13 5:21 ` Rafał Miłecki
[not found] ` <CACna6rw6QOuY247qvDmO4mKrW3y4yXoeM3qr8SXAwn3CuYAMpw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-07-13 8:02 ` Peter Chen
2016-07-13 9:31 ` Rafał Miłecki
[not found] ` <1468326921-26485-1-git-send-email-zajec5-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-07-13 12:42 ` [PATCH V2 0/1] " Rafał Miłecki
[not found] ` <1468413734-9569-1-git-send-email-zajec5-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-07-13 12:42 ` [PATCH V2 1/1] usb: core: add support for " Rafał Miłecki
2016-07-13 12:42 ` [PATCH V2 PROOF OF CONCEPT 2/1] trigger: ledtrig-usbport: read initial state from DT Rafał Miłecki
[not found] ` <1468413734-9569-3-git-send-email-zajec5-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-07-13 14:48 ` Jacek Anaszewski
[not found] ` <578654A7.2020909-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
2016-07-13 15:05 ` Rafał Miłecki
2016-07-13 13:20 ` [PATCH V2 0/1] usb: add HCD providers Felipe Balbi
[not found] ` <87lh15isi7.fsf-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2016-07-13 13:34 ` Rafał Miłecki
[not found] ` <CACna6rxGN5evQhRpNORUP4RP3-pMa292pQW=4=VWLLnzJyhJJw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-07-13 13:50 ` Felipe Balbi
[not found] ` <87inw9ir4k.fsf-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2016-07-13 14:40 ` Rafał Miłecki
2016-07-14 9:48 ` Peter Chen
2016-07-14 10:05 ` Felipe Balbi
2016-07-14 15:52 ` Rafał Miłecki
2016-07-15 2:28 ` Peter Chen
2016-07-15 5:48 ` Rafał Miłecki
2016-07-15 6:22 ` Peter Chen
2016-07-15 9:35 ` Rafał Miłecki [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CACna6rxuaVwLirwc982ifd0riwRodb5WgJ51npd1uDeDkYU0dg@mail.gmail.com \
--to=zajec5@gmail.com \
--cc=devicetree@vger.kernel.org \
--cc=felipe.balbi@linux.intel.com \
--cc=gregkh@linuxfoundation.org \
--cc=hzpeterchen@gmail.com \
--cc=linux-leds@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).