On Wed, Jun 09, 2010 at 08:13:30AM +0200, Wolfgang Denk wrote: > In message <aanlktimis90kr5uqhdbq02osd94dn08soitm51ylr...@mail.gmail.com> you > wrote:
> > Would making a change in uboot be a better solution? Eric, can you > > verify if changing uboot also fixes the problem? > To me it seems better if the driver itself does what needs to be done > instead of relying on specific settings that may or may not be done in > U-Boot. Keep in mind that drivers may be loaded as modules, and that > we even see cases where the same port serves multiple purposes by > loading different driver modules (yes, this is not exactly a clever > idea, but hardware designers come up with such solutions). I do tend to agree that having the driver be able to cope with things is a bit more robust - it's not terribly discoverable for users and people are often justifiably nervous about updating their bootloader. It might, however, be sensible to make the GPIO based reset be optional based on having the OF data for the GPIOs. That way existing DTs will work without changes and systems that can use the reset implementation in the controller will be able to do so. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev