Re: [PATCH 0/2] mpc5200 ac97 gpio reset

[Grant Likely <grant.likely@secretlab.ca>]

On Wed, Jun 9, 2010 at 4:30 AM, Mark Brown
<broonie@opensource.wolfsonmicro.com> wrote:
> On Wed, Jun 09, 2010 at 08:13:30AM +0200, Wolfgang Denk wrote:
>> In message <AANLkTimIs90kR5uqhdBQ02oSd94dn08sOITm51Ylrl4-@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. =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.