[U-Boot] [PATCH v2 26/29] dm: Add child_pre_probe() and child_post_remove() methods

[Simon Glass]

Hi Pavel,

On 15 July 2014 02:26, Pavel Herrmann <morpheus.ibis at gmail.com> wrote:
> Hi
>
> On Tuesday 08 of July 2014 21:38:16 Simon Glass wrote:
>> ...
>> +
>> +Note that the information that controls this behaviour is in the bus's
>> +driver, not the child's. In fact it is possible that child has no knowledge
>> +that it is connected to a bus. The same child device may even be used on
>> two +different bus types. As an example. the 'flash' device shown above may
>> also +be connected on a SATA bus or standalone with no bus:
>> +
>> +   xhci_usb (UCLASS_USB)
>> +      flash (UCLASS_FLASH_STORAGE)  - parent data/methods defined by USB
>> bus +
>> +   sata (UCLASS_SATA)
>> +      flash (UCLASS_FLASH_STORAGE)  - parent data/methods defined by SATA
>> bus +
>> +   flash (UCLASS_FLASH_STORAGE)  - no parent data/methods (not on a bus)
>
> this is not the best example, since the driver actually needs to have an idea
> what parent bus it is connected to, as it should use the parents driver.ops to
> communicate with the device.

Yes, it's not a good example.

>
> the better (more realistic) version would show that the same device would
> operate under various xhci_usb, ohci_usb and ehci_usb busses, which might very
> well have different parent_priv structure (for example, ohci_usb would probably
> not store maximum speed supported by the device, since the bus only has the
> basic one)

They still use the parent driver ops, but now they are all the same?
Do you mean that the uclass would be the same for each bus?

>
> as a side note, flash is a bit tricky here, since USB and SATA do not provide
> you with "flash-like" interface even for flash-based devices, but instead have a
> disk-like interface, which is simpler (does not give you the ability to
> control bad block management, among other things).

Another reason why the example is poor - I was more thinking of flash
as a disk than a raw NAND device.

Regards,
Simon