On Mon, 14 Nov 2022 09:37:59 +0100 Rasmus Villemoes <linux@xxxxxxxxxxxxxxxxxx> wrote: > On 12/11/2022 18.07, Jonathan Cameron wrote: > > On Fri, 11 Nov 2022 15:39:21 +0100 > > Rasmus Villemoes <linux@xxxxxxxxxxxxxxxxxx> wrote: > > > >> We have a board where the reset pin of the ad74412 is connected to a > >> gpio, but also pulled low by default. Hence to get the chip out of > >> reset, the driver needs to know about that gpio and set it high before > >> attempting to communicate with it. > > > > I'm a little confused on polarity here. The pin is a !reset so > > we need to drive it low briefly to trigger a reset. > > I'm guessing for your board the pin is set to active low? (an example > > in the dt would have made that clearer) Hence the pulse > > in here to 1 is actually briefly driving it low before restoring to high? > > Yes. I actually thought that was pretty standard. I do indeed have > something like > > reset-gpios = <&gpio1 3 GPIO_ACTIVE_LOW>; > > in my .dts, so setting the gpio value to 1 (logically asserting its > function) will end up driving the signal low, and setting it to 0 > (de-asserting reset) will set the signal high. I will add that line to > the example in the binding. > > > For a pin documented as !reset that seems backwards > > Well, it depends on where the knowledge of the pin being active low > belongs. In this case, the driver itself handles the gpio so it could be > done both ways. > > But if, for example, the iio framework would handle an optional > reset-gpio for each device, it couldn't possibly know whether to set it > to 1 or 0 for a given device, it could only set it logic 1 to assert > reset and then rely on DT gpio descriptor to include the active low/high > info. > > Also, see the "The active low and open drain semantics" section in > Documentation/driver-api/gpio/consumer.rst. Throw in an example in the dt-binding and I'm fine with this as it stands. Jonathan > > Rasmus >
