[U-Boot] USB and unbinding

[Simon Glass]

Hi Hans,

On 20 July 2015 at 09:31, Hans de Goede <hdegoede at redhat.com> wrote:
> Hi,
>
> On 20-07-15 04:23, Simon Glass wrote:
>>
>> Hi Hans,
>>
>> I've been thinking about the USB unbinding code. I know that I agreed
>> to go with it, but in retrospect I think that was a mistake.
>>
>> I believe we should separate out the unbinding and make it an option,
>> so that it is not required in order to use USB. In effect this makes
>> one of driver model's design goals (the option to drop unused code)
>> useless since USB is a common interface.
>>
>> If I recall the only problem the lack of unbinding caused was that the
>> keyboard driver broke. I suspect it broke in a way that can be fixed.
>> In fact I recently converted usb_ether to driver model and I'm willing
>> to do the keyboard side also.
>>
>> I'd like the USB code to function with or without the unbinding (i.e.
>> it uses it if there). What do you think?
>
>
> I strongly believe that unbinding is the proper thing todo for usb since
> it is a hotplug bus.
>
> IMHO the way the usb_find_emul_child() function was used before to re-use
> udevice-s after e.g. a "usb reset" was an ugly hack which just happened to
> work, but it in no way reflects reality.
>
> More importantly we need unbind support to properly stop usb controllers
> when
> booting the OS, so that they are not DMA-ing to/from their scratch-ram area
> in DRAM when the main OS boots, so not having unbind support combined with
> USB really is a no no.
>
> This is why I suggested to simply select the unbind Kconfig when USB is
> selected in Kconfig.

I think you are referring to remove(), not unbind(). Although we might
consider spiting them so we have a DM_DEVICE_REMOVE and a separate
DM_DEVICE_UNBIND.

>
> The actual unbind core code is not that big, so I believe that the best
> solution is to always build the core if either DM_DEVICE_REMOVE *or*
> DM_USB is selected, and non USB drivers can leave out their unbind
> code if DM_DEVICE_REMOVE is not set, that should still give us most of
> the size savings without needing to do ugly hacks for USB.

My main objection is that we tie USB such that it *will not work*
unless we support unbinding. I'm fine with it being recommended, but
core driver model features should be independent of subsystems. This
also seems quite unnecessary. Re your common about the 'ugly hack that
just happened to work', in principle we can just keep on creating new
devices and ignore the old ones. That's the idea behind not supporting
unbinding. There should be no problem with this approach.

So I'd like to adjust the USB code so that it still works without
unbinding, even if it is not optimal. I think that is the right thing
to do in this case.

Regards,
Simon