[U-Boot] USB Ethernet with device model

[U-Boot] USB Ethernet with device model

[Maxime Ripard]

Hi,

I've been working with USB-Ethernet gadget for quite some time on the
Allwinner SoCs, especially because most Allwinner boards lack an
ethernet controller.

The thing is, it wasn't really upstreamable all this time since we've
had also some boards that had a controller with DM_ETH. And usb_ether
didn't have DM_ETH support until recently.

So I gave it a shot, and encountered a few weird things that prevented
it from working (and still do):

1) I converted our musb glue to support the DM even in the peripheral
   mode. Here is the code: http://code.bulix.org/m846ni-194479

   It almost works, except that usb_scan_bus in usb-uclass.c for some
   reason unknown to me tries to scan the peripheral device, and
   fails. Skipping that scan makes fastboot works, so I guess the
   peripheral is working. Is there any particular reason that the
   DM_USB code tries to scan even peripheral devices ?

2) I can't manage to get usb_ether to probe after that, using the
   DM. It seems that we need to call usb_ether_init, and that it looks
   for UCLASS_USB_DEV_GENERIC devices and binds the usb_ether gadget
   to it.

   However, every board or arch hooks I tried seems to be much earlier
   than the USB controller, leading to the binding failing since we
   don't have a controller to bind to yet.

   Adding that code right after the USB controller initialisation in
   the musb probe solves that issue, but for some other reason, it
   looks for a device of the USB_DEV_GENERIC uclass, while the uclass
   for the USB controllers seems to be USB. Actually, I don't seem to
   find any user of the USB_DEV_GENERIC uclass but the usb_ether
   driver, so I'm not really sure how it's supposed to work either...

Is there some user of this in U-Boot right now? the only call there is
to usb_ether_init seems to be for the am33xx SoCs, whose usb glue
don't register a peripheral controller (yet), so I don't really know
how that can work either.

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20170905/760e7e63/attachment.sig>

[U-Boot] USB Ethernet with device model

[Simon Glass]

+Bin

Hi Maxiime,

On 5 September 2017 at 14:32, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> Hi,
>
> I've been working with USB-Ethernet gadget for quite some time on the
> Allwinner SoCs, especially because most Allwinner boards lack an
> ethernet controller.
>
> The thing is, it wasn't really upstreamable all this time since we've
> had also some boards that had a controller with DM_ETH. And usb_ether
> didn't have DM_ETH support until recently.
>
> So I gave it a shot, and encountered a few weird things that prevented
> it from working (and still do):
>
> 1) I converted our musb glue to support the DM even in the peripheral
>    mode. Here is the code: http://code.bulix.org/m846ni-194479
>
>    It almost works, except that usb_scan_bus in usb-uclass.c for some
>    reason unknown to me tries to scan the peripheral device, and
>    fails. Skipping that scan makes fastboot works, so I guess the
>    peripheral is working. Is there any particular reason that the
>    DM_USB code tries to scan even peripheral devices ?

Perhaps because it might be a hub? This is for companion support which
Bin may know more about.

>
> 2) I can't manage to get usb_ether to probe after that, using the
>    DM. It seems that we need to call usb_ether_init, and that it looks
>    for UCLASS_USB_DEV_GENERIC devices and binds the usb_ether gadget
>    to it.
>
>    However, every board or arch hooks I tried seems to be much earlier
>    than the USB controller, leading to the binding failing since we
>    don't have a controller to bind to yet.
>
>    Adding that code right after the USB controller initialisation in
>    the musb probe solves that issue, but for some other reason, it
>    looks for a device of the USB_DEV_GENERIC uclass, while the uclass
>    for the USB controllers seems to be USB. Actually, I don't seem to
>    find any user of the USB_DEV_GENERIC uclass but the usb_ether
>    driver, so I'm not really sure how it's supposed to work either...

USB_DEV_GENERIC is a USB device (i.e. something ON the bus) which is
not identified (i.e. not UCLASS_ETH for example). Anything that has a
driver will be picked up by usb_find_and_bind_driver(). Note that the
generic device is a fallback when the search fails.

>
> Is there some user of this in U-Boot right now? the only call there is
> to usb_ether_init seems to be for the am33xx SoCs, whose usb glue
> don't register a peripheral controller (yet), so I don't really know
> how that can work either.

Well once the UCLASS_ETH device is found on USB, it will appear as a
normal Ethernet device and operate as any other such device.

Thanks for looking at this. It will require some refactoring since the
code is made for host mode at present.

Regards,
Simon

[U-Boot] USB Ethernet with device model

[Vignesh R]

Hi,

Removing mugunthanvnm at ti.com, who is no longer working for TI.

On Wednesday 06 September 2017 02:02 AM, Maxime Ripard wrote:
> Hi,
> 
> I've been working with USB-Ethernet gadget for quite some time on the
> Allwinner SoCs, especially because most Allwinner boards lack an
> ethernet controller.
> 
> The thing is, it wasn't really upstreamable all this time since we've
> had also some boards that had a controller with DM_ETH. And usb_ether
> didn't have DM_ETH support until recently.
> 
> So I gave it a shot, and encountered a few weird things that prevented
> it from working (and still do):
> 
> 1) I converted our musb glue to support the DM even in the peripheral
>    mode. Here is the code: http://code.bulix.org/m846ni-194479
> 
>    It almost works, except that usb_scan_bus in usb-uclass.c for some
>    reason unknown to me tries to scan the peripheral device, and
>    fails. Skipping that scan makes fastboot works, so I guess the
>    peripheral is working. Is there any particular reason that the
>    DM_USB code tries to scan even peripheral devices ?
> 
> 2) I can't manage to get usb_ether to probe after that, using the
>    DM. It seems that we need to call usb_ether_init, and that it looks
>    for UCLASS_USB_DEV_GENERIC devices and binds the usb_ether gadget
>    to it.
> 
>    However, every board or arch hooks I tried seems to be much earlier
>    than the USB controller, leading to the binding failing since we
>    don't have a controller to bind to yet.
> 

am33xx probes MISC devices in arch_misc_init()
(arch/arm/mach-omap2/am33xx/board.c)

>    Adding that code right after the USB controller initialisation in
>    the musb probe solves that issue, but for some other reason, it
>    looks for a device of the USB_DEV_GENERIC uclass, while the uclass
>    for the USB controllers seems to be USB. Actually, I don't seem to
>    find any user of the USB_DEV_GENERIC uclass but the usb_ether
>    driver, so I'm not really sure how it's supposed to work either...
> 

Sorry, DM based eth gadget support is still missing for am33xx. This
patch in particular was asked to be reworked:
https://patchwork.ozlabs.org/patch/696033/

> Is there some user of this in U-Boot right now? the only call there is
> to usb_ether_init seems to be for the am33xx SoCs, whose usb glue
> don't register a peripheral controller (yet), so I don't really know
> how that can work either.
> 

Last time I tried to upstream dwc3 usb ethernet gaget and rndis boot
support, Lukasz Majewski had ideas to move towards adding DM
infrastructure for USB gadget:
https://patchwork.ozlabs.org/patch/775110/



-- 
Regards
Vignesh

[U-Boot] USB Ethernet with device model

[Maxime Ripard]

Hi Simon,

On Fri, Sep 08, 2017 at 10:55:24PM -0600, Simon Glass wrote:
> On 5 September 2017 at 14:32, Maxime Ripard
> <maxime.ripard@free-electrons.com> wrote:
> > Hi,
> >
> > I've been working with USB-Ethernet gadget for quite some time on the
> > Allwinner SoCs, especially because most Allwinner boards lack an
> > ethernet controller.
> >
> > The thing is, it wasn't really upstreamable all this time since we've
> > had also some boards that had a controller with DM_ETH. And usb_ether
> > didn't have DM_ETH support until recently.
> >
> > So I gave it a shot, and encountered a few weird things that prevented
> > it from working (and still do):
> >
> > 1) I converted our musb glue to support the DM even in the peripheral
> >    mode. Here is the code: http://code.bulix.org/m846ni-194479
> >
> >    It almost works, except that usb_scan_bus in usb-uclass.c for some
> >    reason unknown to me tries to scan the peripheral device, and
> >    fails. Skipping that scan makes fastboot works, so I guess the
> >    peripheral is working. Is there any particular reason that the
> >    DM_USB code tries to scan even peripheral devices ?
> 
> Perhaps because it might be a hub? This is for companion support which
> Bin may know more about.

I think it was because I was registering the peripheral-mode driver as
a member of UCLASS_USB, which seems to be only for host devices.

The code would then start to scan the device (as it should for host
devices) and things were falling apart because, well, it was not a
host device.

> >
> > 2) I can't manage to get usb_ether to probe after that, using the
> >    DM. It seems that we need to call usb_ether_init, and that it looks
> >    for UCLASS_USB_DEV_GENERIC devices and binds the usb_ether gadget
> >    to it.
> >
> >    However, every board or arch hooks I tried seems to be much earlier
> >    than the USB controller, leading to the binding failing since we
> >    don't have a controller to bind to yet.
> >
> >    Adding that code right after the USB controller initialisation in
> >    the musb probe solves that issue, but for some other reason, it
> >    looks for a device of the USB_DEV_GENERIC uclass, while the uclass
> >    for the USB controllers seems to be USB. Actually, I don't seem to
> >    find any user of the USB_DEV_GENERIC uclass but the usb_ether
> >    driver, so I'm not really sure how it's supposed to work either...
> 
> USB_DEV_GENERIC is a USB device (i.e. something ON the bus) which is
> not identified (i.e. not UCLASS_ETH for example). Anything that has a
> driver will be picked up by usb_find_and_bind_driver(). Note that the
> generic device is a fallback when the search fails.

Ok, so I guess the reason to choose USB_DEV_GENERIC is because we're
acting as that device on the bus when probing a gadget?

> > Is there some user of this in U-Boot right now? the only call there is
> > to usb_ether_init seems to be for the am33xx SoCs, whose usb glue
> > don't register a peripheral controller (yet), so I don't really know
> > how that can work either.
> 
> Well once the UCLASS_ETH device is found on USB, it will appear as a
> normal Ethernet device and operate as any other such device.
> 
> Thanks for looking at this. It will require some refactoring since the
> code is made for host mode at present.

It works quite well already once a few quirks figured out. I've sent a
serie of patch that works already, it should be in your INBOX. I guess
most of the quirks are not trivial to get because there's no-one using
that setup for now.

Hopefully, it should be easier to get once they're merged.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20170911/6d05f908/attachment.sig>

[U-Boot] USB Ethernet with device model

[Simon Glass]

Hi Maxime,

On 11 September 2017 at 02:33, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> Hi Simon,
>
> On Fri, Sep 08, 2017 at 10:55:24PM -0600, Simon Glass wrote:
>> On 5 September 2017 at 14:32, Maxime Ripard
>> <maxime.ripard@free-electrons.com> wrote:
>> > Hi,
>> >
>> > I've been working with USB-Ethernet gadget for quite some time on the
>> > Allwinner SoCs, especially because most Allwinner boards lack an
>> > ethernet controller.
>> >
>> > The thing is, it wasn't really upstreamable all this time since we've
>> > had also some boards that had a controller with DM_ETH. And usb_ether
>> > didn't have DM_ETH support until recently.
>> >
>> > So I gave it a shot, and encountered a few weird things that prevented
>> > it from working (and still do):
>> >
>> > 1) I converted our musb glue to support the DM even in the peripheral
>> >    mode. Here is the code: http://code.bulix.org/m846ni-194479
>> >
>> >    It almost works, except that usb_scan_bus in usb-uclass.c for some
>> >    reason unknown to me tries to scan the peripheral device, and
>> >    fails. Skipping that scan makes fastboot works, so I guess the
>> >    peripheral is working. Is there any particular reason that the
>> >    DM_USB code tries to scan even peripheral devices ?
>>
>> Perhaps because it might be a hub? This is for companion support which
>> Bin may know more about.
>
> I think it was because I was registering the peripheral-mode driver as
> a member of UCLASS_USB, which seems to be only for host devices.

Yes that's right.

>
> The code would then start to scan the device (as it should for host
> devices) and things were falling apart because, well, it was not a
> host device.
>
>> >
>> > 2) I can't manage to get usb_ether to probe after that, using the
>> >    DM. It seems that we need to call usb_ether_init, and that it looks
>> >    for UCLASS_USB_DEV_GENERIC devices and binds the usb_ether gadget
>> >    to it.
>> >
>> >    However, every board or arch hooks I tried seems to be much earlier
>> >    than the USB controller, leading to the binding failing since we
>> >    don't have a controller to bind to yet.
>> >
>> >    Adding that code right after the USB controller initialisation in
>> >    the musb probe solves that issue, but for some other reason, it
>> >    looks for a device of the USB_DEV_GENERIC uclass, while the uclass
>> >    for the USB controllers seems to be USB. Actually, I don't seem to
>> >    find any user of the USB_DEV_GENERIC uclass but the usb_ether
>> >    driver, so I'm not really sure how it's supposed to work either...
>>
>> USB_DEV_GENERIC is a USB device (i.e. something ON the bus) which is
>> not identified (i.e. not UCLASS_ETH for example). Anything that has a
>> driver will be picked up by usb_find_and_bind_driver(). Note that the
>> generic device is a fallback when the search fails.
>
> Ok, so I guess the reason to choose USB_DEV_GENERIC is because we're
> acting as that device on the bus when probing a gadget?

I don't understand' probing a gadget'. Do you mean 'probing a USB device'?

It's really just a placeholder. We have to have some sort of DM device
in order to even report the existence of a USB device so this is our
way of doing so when we have no real driver.

In practice I don't think that devices of type 'USB_DEV_GENERIC' are
accessed, but it would be possible to send them commands.

So for USB gadget I don't think this will be needed, since U-Boot will
always have a driver for the gadget (e.g. for Ethernet gadget it
cannot work unless the gadget is UCLASS_ETHERNET).

BTW we do the same thing with PCI, I2C and SPI. Anything where a
driver cannot be found, we have to use some sort of placeholder
uclass.

>
>> > Is there some user of this in U-Boot right now? the only call there is
>> > to usb_ether_init seems to be for the am33xx SoCs, whose usb glue
>> > don't register a peripheral controller (yet), so I don't really know
>> > how that can work either.
>>
>> Well once the UCLASS_ETH device is found on USB, it will appear as a
>> normal Ethernet device and operate as any other such device.
>>
>> Thanks for looking at this. It will require some refactoring since the
>> code is made for host mode at present.
>
> It works quite well already once a few quirks figured out. I've sent a
> serie of patch that works already, it should be in your INBOX. I guess
> most of the quirks are not trivial to get because there's no-one using
> that setup for now.
>
> Hopefully, it should be easier to get once they're merged.

OK sounds good.

>
> Maxime
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com

Regards,
Simon