On Wed, Jun 9, 2010 at 4:30 AM, Mark Brown
[off-list ref] wrote:

On Wed, Jun 09, 2010 at 08:13:30AM +0200, Wolfgang Denk wrote:

quoted

In message <AANLkTimIs90kR5uqhdBQ02oSd94dn08sOITm51Ylrl4-@mail.gmail.com=

you wrote:

quoted

quoted

Would making a change in uboot be a better solution? Eric, can you
verify if changing uboot also fixes the problem?

quoted

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. =A0That way existing DTs will
work without changes and systems that can use the reset implementation
in the controller will be able to do so.

To me, this seems firmly in the realm of silicon bug workaround.
Considering that the pins aren't relocatable (ie, the GPIO numbers
never change), I've got no problem having the GPIO reset logic added
to arch/powerpc/platforms/52xx and hard coding the GPIO numbers.

I completely agree that it should not require a firmware update to get
the hardware to work correctly.

g.