From: David Mosberger-Tang <davidm@egauge.net>
To: Claudiu.Beznea@microchip.com, Ajay.Kathat@microchip.com
Cc: adham.abozaeid@microchip.com, davem@davemloft.net,
devicetree@vger.kernel.org, kuba@kernel.org,
kvalo@codeaurora.org, linux-kernel@vger.kernel.org,
linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
robh+dt@kernel.org
Subject: Re: [PATCH v5 1/2] wilc1000: Add reset/enable GPIO support to SPI driver
Date: Wed, 15 Dec 2021 07:59:05 -0700 [thread overview]
Message-ID: <9cfbcc99f8a70ba2c03a9ad99f273f12e237e09f.camel@egauge.net> (raw)
In-Reply-To: <d55a2558-b05d-5995-b0f0-f234cb3b50aa@microchip.com>
On Wed, 2021-12-15 at 06:41 +0000, Claudiu.Beznea@microchip.com wrote:
> On 15.12.2021 05:05, David Mosberger-Tang wrote:
> >
> +static int wilc_parse_gpios(struct wilc *wilc)
> > +{
> > + struct spi_device *spi = to_spi_device(wilc->dev);
> > + struct wilc_spi *spi_priv = wilc->bus_data;
> > + struct wilc_gpios *gpios = &spi_priv->gpios;
> > +
> > + /* get ENABLE pin and deassert it (if it is defined): */
> > + gpios->enable = devm_gpiod_get_optional(&spi->dev,
> > + "enable", GPIOD_OUT_LOW);
> > + /* get RESET pin and assert it (if it is defined): */
> > + if (gpios->enable) {
> > + /* if enable pin exists, reset must exist as well */
> > + gpios->reset = devm_gpiod_get(&spi->dev,
> > + "reset", GPIOD_OUT_HIGH);
>
> As far as I can tell form gpiolib code the difference b/w GPIOD_OUT_HIGH
> and GPIOD_OUT_LOW in gpiolib is related to the initial value for the GPIO.
Yes.
> Did you used GPIOD_OUT_HIGH for reset to have the chip out of reset at this
> point?
No, ~RESET is an active-low signal. GPIOD_OUT_LOW should really be
called GPIOD_OUT_DEASSERTED or something like that. The code ensures
that the chip is in RESET and ~ENABLEd after parsing the GPIOs.
> > + if (IS_ERR(gpios->reset)) {
> > + dev_err(&spi->dev, "missing reset gpio.\n");
> > + return PTR_ERR(gpios->reset);
> > + }
> > + } else {
> > + gpios->reset = devm_gpiod_get_optional(&spi->dev,
> > + "reset", GPIOD_OUT_HIGH);
> > + }
> > + return 0;
> > +}
> > +
> > +static void wilc_wlan_power(struct wilc *wilc, bool on)
> > +{
> > + struct wilc_spi *spi_priv = wilc->bus_data;
> > + struct wilc_gpios *gpios = &spi_priv->gpios;
> > +
> > + if (on) {
> > + gpiod_set_value(gpios->enable, 1); /* assert ENABLE */
> > + mdelay(5);
> > + gpiod_set_value(gpios->reset, 0); /* deassert RESET */
>
> From what I can tell from gpiolib code, requesting the pin from device tree
> with:
>
> + reset-gpios = <&pioA 6 GPIO_ACTIVE_LOW>;
>
> makes the value written with gpiod_set_value() to be negated, thus the 0
> written here is translated to a 1 on the pin. Is there a reason you did it
> like this?
Yes, of course. RESET is an active-low signal, as defined in the
datasheet.
> Would it have been simpler to have both pins requested with
> GPIO_ACTIVE_HIGH and here to do gpiod_set_value(gpio, 1) for both of the
> pin. In this way, at the first read of the code one one would have been
> telling that it does what datasheet specifies: for power on toggle enable
> and reset gpios from 0 to 1 with a delay in between.
I think you're confusing 0 and 1 with low-voltage and high-voltage. 0
means de-assert the signal, 1 means assert the signal. Whether that
translates to a low voltage or a high voltage depends on whether the
signal a active-low or active-high.
>
>
> > + } else {
> > + gpiod_set_value(gpios->reset, 1); /* assert RESET */
> > + gpiod_set_value(gpios->enable, 0); /* deassert ENABLE */
>
> I don't usually see comments near the code line in kernel. Maybe move them
> before the actual code line or remove them at all as the code is impler enough?
You're kidding, right?
--david
next prev parent reply other threads:[~2021-12-15 14:59 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-15 3:05 [PATCH v5 0/2] wilc1000: Add reset/enable GPIO support to SPI driver David Mosberger-Tang
2021-12-15 3:05 ` [PATCH v5 1/2] " David Mosberger-Tang
2021-12-15 6:41 ` Claudiu.Beznea
2021-12-15 14:59 ` David Mosberger-Tang [this message]
2021-12-16 7:08 ` Claudiu.Beznea
2021-12-16 8:10 ` Kalle Valo
2021-12-16 15:26 ` David Mosberger-Tang
2021-12-20 8:46 ` Kalle Valo
2021-12-15 3:05 ` [PATCH v5 2/2] wilc1000: Document enable-gpios and reset-gpios properties David Mosberger-Tang
2021-12-16 19:00 ` Rob Herring
2021-12-15 5:37 ` [PATCH v5 0/2] wilc1000: Add reset/enable GPIO support to SPI driver Claudiu.Beznea
2021-12-15 14:48 ` David Mosberger-Tang
2021-12-16 8:03 ` Claudiu.Beznea
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9cfbcc99f8a70ba2c03a9ad99f273f12e237e09f.camel@egauge.net \
--to=davidm@egauge.net \
--cc=Ajay.Kathat@microchip.com \
--cc=Claudiu.Beznea@microchip.com \
--cc=adham.abozaeid@microchip.com \
--cc=davem@davemloft.net \
--cc=devicetree@vger.kernel.org \
--cc=kuba@kernel.org \
--cc=kvalo@codeaurora.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=robh+dt@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).