[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 at 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>