[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACRpkdYKo+HTwrm1BssJ9nm_xsGFsdRoqDkJWJMETTL2fwaP2A@mail.gmail.com>
Date: Sun, 21 Apr 2024 20:33:28 +0200
From: Linus Walleij <linus.walleij@...aro.org>
To: Aapo Vienamo <aapo.vienamo@...ux.intel.com>
Cc: Bartosz Golaszewski <brgl@...ev.pl>, Andy Shevchenko <andy@...nel.org>, linux-kernel@...r.kernel.org,
linux-gpio@...r.kernel.org, Mika Westerberg <mika.westerberg@...ux.intel.com>,
Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Subject: Re: [PATCH] gpio: Add Intel Granite Rapids-D vGPIO driver
On Fri, Apr 19, 2024 at 4:43 PM Aapo Vienamo
<aapo.vienamo@...ux.intel.com> wrote:
> > Can you rename this:
> > gnr_gpio_configure_direction()?
>
> I do agree that the pad part of the name maybe isn't the best, though
> this function isn't just for direction control, since it's used for
> setting the pin output state as well in gnr_gpio_set(). The idea is that
> locking and masking of the register accesses is factored out of the gpio
> callbacks and implemented in this function.
>
> Maybe gnr_gpio_configure_pin()?
gnr_gpio_configure_line() in that case, it clearly isn't a pin since it is
virtual and for that reason called *v*GPIO, right? Pins are a very
physical thing. It's that kind of confusion I want to avoid in naming.
Yours,
Linus Walleij
Powered by blists - more mailing lists