Re: Gpio reset handling

[Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>]

On Tue, Sep 15, 2009 at 12:32 PM, Michal Simek <monstr-pSz03upnqPeHXe+LvDLADg@public.gmane.org> wrote:
> Hi All,
>
> I would like to find out proper way how to handle xilinx reset gpio.
> We are using gpio for soft reset.
[...]
> Ok and here about description of reset port
> I see two option to write new trigger
> 1. new reset trigger and add it to gpio-leds node - but this should be in gpio-leds node which make
> no sense to me
>
>        reset {
>                label = "Heartbeat";
>                gpios = <&gpio_res 3 1>;
>                linux,default-trigger = "reset";
>        }

This looks like an abuse of the LED infrastructure.

> 2. create own reset node
>
> reset {
>        compatible = "gpio-reset";
>        reset0 {
>                label "Soft reset";
>                gpios = <&gpio_res 1 1>;
>        }
>
>        reset1 {
>                label "Phy reset";
>                gpios = <&gpio_res 2 1>;
>        }
> }
>
> For this node there should be better reset description not just label with different description.
> I expect that it will be useful soft and hard reset and maybe you can find some others.

It sounds like what you are doing is very board specific.  It is
probably premature to design a 'generic' binding for something that
may very well not turn out to be very generic at all.  What I'd do is
create yourself a node for holding board specific properties (like the
binding to the gpio reset line) and parse that data from your board
specific setup code.  I suppose you could also do it from an
of_platform driver, but like irq controllers, it probably doesn't make
a lot of sense to.

So, something like this perhaps:

    machine {
        compatible = "<vendor>,<board>-machine";
        soft-reset-gpio = <&gpio_res 1 1>;
        phy-reset-gpio = <&gpio_res 2 1>;
    };

I don't much like the node name "machine", but I can't think of
anything better at the moment.

Note, this suggestion uses "soft-reset-gpio" and "phy-reset-gpio"
properties instead of the currently documented "gpios" property.  This
usage isn't supported by the current gpio support code, but that code
can be modified, and I think this approach is clearer (as long as the
expected usage of "<vendor>,<board>-machine" is documented.

Cheers,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.