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. Rasmus
