[U-Boot] USB Ethernet with device model

[Simon Glass]

Hi Maxime,

On 11 September 2017 at 02:33, Maxime Ripard
<maxime.ripard at 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 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.

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