[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y9qRC2qz7ZbKslnb@google.com>
Date: Wed, 1 Feb 2023 08:19:23 -0800
From: Dmitry Torokhov <dmitry.torokhov@...il.com>
To: Stefan Schmidt <stefan@...enfreihafen.org>
Cc: Arnd Bergmann <arnd@...nel.org>,
Alexander Aring <alex.aring@...il.com>,
Arnd Bergmann <arnd@...db.de>,
Miquel Raynal <miquel.raynal@...tlin.com>,
Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
"David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>,
Paolo Abeni <pabeni@...hat.com>, linux-kernel@...r.kernel.org,
linux-wpan@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [PATCH] [v2] at86rf230: convert to gpio descriptors
On Wed, Feb 01, 2023 at 01:42:37PM +0100, Stefan Schmidt wrote:
> Hello Dmitry.
>
> On 01.02.23 01:50, Dmitry Torokhov wrote:
> > On Tue, Jan 31, 2023 at 3:52 PM Dmitry Torokhov
> > <dmitry.torokhov@...il.com> wrote:
> > >
> > > Hi Arnd,
> > >
> > > On Thu, Jan 26, 2023 at 8:32 AM Arnd Bergmann <arnd@...nel.org> wrote:
> > > >
> > > > /* Reset */
> > > > - if (gpio_is_valid(rstn)) {
> > > > + if (rstn) {
> > > > udelay(1);
> > > > - gpio_set_value_cansleep(rstn, 0);
> > > > + gpiod_set_value_cansleep(rstn, 0);
> > > > udelay(1);
> > > > - gpio_set_value_cansleep(rstn, 1);
> > > > + gpiod_set_value_cansleep(rstn, 1);
> > >
> > > For gpiod conversions, if we are not willing to chase whether existing
> > > DTSes specify polarities
> > > properly and create workarounds in case they are wrong, we should use
> > > gpiod_set_raw_value*()
> > > (my preference would be to do the work and not use "raw" variants).
> > >
> > > In this particular case, arch/arm/boot/dts/vf610-zii-dev-rev-c.dts
> > > defines reset line as active low,
> > > so you are leaving the device in reset state.
> > >
> > > Please review your other conversion patches.
> >
> > We also can not change the names of requested GPIOs from "reset-gpio"
> > to "rstn-gpios" and expect
> > this to work.
> >
> > Stefan, please consider reverting this and applying a couple of
> > patches I will send out shortly.
>
> Thanks for having another look at these patches. Do you have the same
> concern for the convesion patch to cc2520 that has been posted and applied
> as well?
There are no DT users of cc2520 in the tree, so while ideally reset line
should not be left in "logical active" state at the end of the probe, we
can deal with this in a follow up patch, I doubt it will lead to
regressions as it is.
If I were really nitpicky I would adjust error messages when we fail to
get GPIOs, but again, can be done as a followup.
>
> Arnd, if you have any concerns about the revert please speak up soon as I am
> going to revert your patch and get these patches into my tree later today.
>
Thanks.
--
Dmitry
Powered by blists - more mailing lists