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

Pavel Herrmann morpheus.ibis at gmail.com
Thu Jul 17 09:09:55 CEST 2014


On Wednesday 16 of July 2014 23:41:57 Simon Glass wrote:
> 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?

Yes, I imagine the uclass for USB host controller would the same, not 
depending on the speed of the controller.

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

regards
Pavel Herrmann


More information about the U-Boot mailing list