This is an OF only driver. No point in using generic device handlers.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
---
drivers/gpio/gpio-realtek-otto.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpio/gpio-realtek-otto.c b/drivers/gpio/gpio-realtek-otto.c
index efcddbe01308..8bad43afc586 100644
--- a/drivers/gpio/gpio-realtek-otto.c
+++ b/drivers/gpio/gpio-realtek-otto.c
@@ -372,10 +372,10 @@ static int realtek_gpio_probe(struct platform_device *pdev)
if (!ctrl)
return -ENOMEM;
- dev_flags = (unsigned int)(kernel_ulong_t)device_get_match_data(dev);
+ dev_flags = (unsigned int)(kernel_ulong_t)of_device_get_match_data(dev);
ngpios = REALTEK_GPIO_MAX;
- device_property_read_u32(dev, "ngpios", &ngpios);
+ of_property_read_u32(dev->of_node, "ngpios", &ngpios);
if (ngpios > REALTEK_GPIO_MAX) {
dev_err(&pdev->dev, "invalid ngpios (max. %d)\n",
--
2.52.0
On Wed, Dec 17, 2025 at 7:32 AM Rosen Penev <rosenp@gmail.com> wrote:
>
> This is an OF only driver. No point in using generic device handlers.
>
> Signed-off-by: Rosen Penev <rosenp@gmail.com>
> ---
> drivers/gpio/gpio-realtek-otto.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpio/gpio-realtek-otto.c b/drivers/gpio/gpio-realtek-otto.c
> index efcddbe01308..8bad43afc586 100644
> --- a/drivers/gpio/gpio-realtek-otto.c
> +++ b/drivers/gpio/gpio-realtek-otto.c
> @@ -372,10 +372,10 @@ static int realtek_gpio_probe(struct platform_device *pdev)
> if (!ctrl)
> return -ENOMEM;
>
> - dev_flags = (unsigned int)(kernel_ulong_t)device_get_match_data(dev);
> + dev_flags = (unsigned int)(kernel_ulong_t)of_device_get_match_data(dev);
>
> ngpios = REALTEK_GPIO_MAX;
> - device_property_read_u32(dev, "ngpios", &ngpios);
> + of_property_read_u32(dev->of_node, "ngpios", &ngpios);
>
> if (ngpios > REALTEK_GPIO_MAX) {
> dev_err(&pdev->dev, "invalid ngpios (max. %d)\n",
> --
> 2.52.0
>
Yeah, no, there's almost *never* a point in using OF-specific accessors. NAK.
Bart
On Wed, Dec 17, 2025 at 1:30 AM Bartosz Golaszewski <brgl@kernel.org> wrote:
>
> On Wed, Dec 17, 2025 at 7:32 AM Rosen Penev <rosenp@gmail.com> wrote:
> >
> > This is an OF only driver. No point in using generic device handlers.
> >
> > Signed-off-by: Rosen Penev <rosenp@gmail.com>
> > ---
> > drivers/gpio/gpio-realtek-otto.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpio/gpio-realtek-otto.c b/drivers/gpio/gpio-realtek-otto.c
> > index efcddbe01308..8bad43afc586 100644
> > --- a/drivers/gpio/gpio-realtek-otto.c
> > +++ b/drivers/gpio/gpio-realtek-otto.c
> > @@ -372,10 +372,10 @@ static int realtek_gpio_probe(struct platform_device *pdev)
> > if (!ctrl)
> > return -ENOMEM;
> >
> > - dev_flags = (unsigned int)(kernel_ulong_t)device_get_match_data(dev);
> > + dev_flags = (unsigned int)(kernel_ulong_t)of_device_get_match_data(dev);
> >
> > ngpios = REALTEK_GPIO_MAX;
> > - device_property_read_u32(dev, "ngpios", &ngpios);
> > + of_property_read_u32(dev->of_node, "ngpios", &ngpios);
> >
> > if (ngpios > REALTEK_GPIO_MAX) {
> > dev_err(&pdev->dev, "invalid ngpios (max. %d)\n",
> > --
> > 2.52.0
> >
>
> Yeah, no, there's almost *never* a point in using OF-specific accessors. NAK.
Argument made to me on netdev before is it's pointless overhead for an
OF only driver.
>
> Bart
On Wed, Dec 17, 2025 at 9:26 PM Rosen Penev <rosenp@gmail.com> wrote: > > > > Yeah, no, there's almost *never* a point in using OF-specific accessors. NAK. > > Argument made to me on netdev before is it's pointless overhead for an > OF only driver. Would you mind posting a lore link? I'll gladly chime in. Drivers are OF-only until they aren't. Vide: lots of discussions currently about supporting ARM laptops and servers with mixed DT-ACPI setup. The overhead of going through the fwnode pointer is absolutely negligible while using generic accessors allows taking secondary fwnodes into account. Please don't tell me people are going around the kernel converting drivers to using of_ routines? Bart
On Thu, Dec 18, 2025 at 12:31 AM Bartosz Golaszewski <brgl@kernel.org> wrote: > > On Wed, Dec 17, 2025 at 9:26 PM Rosen Penev <rosenp@gmail.com> wrote: > > > > > > Yeah, no, there's almost *never* a point in using OF-specific accessors. NAK. > > > > Argument made to me on netdev before is it's pointless overhead for an > > OF only driver. > > Would you mind posting a lore link? I'll gladly chime in. > > Drivers are OF-only until they aren't. Vide: lots of discussions > currently about supporting ARM laptops and servers with mixed DT-ACPI > setup. Hrm I must have misremembered or I can't find it. In any case, these devices will never support ACPI. They're all embedded devices with uboot. > > The overhead of going through the fwnode pointer is absolutely > negligible while using generic accessors allows taking secondary > fwnodes into account. > > Please don't tell me people are going around the kernel converting > drivers to using of_ routines? There's one special case I know of, of_get_mac_address vs device_get_mac_address. The former supports NVMEM. The latter does not. > > Bart
On Thu, Dec 18, 2025 at 10:32 AM Rosen Penev <rosenp@gmail.com> wrote: > > On Thu, Dec 18, 2025 at 12:31 AM Bartosz Golaszewski <brgl@kernel.org> wrote: > > > > On Wed, Dec 17, 2025 at 9:26 PM Rosen Penev <rosenp@gmail.com> wrote: > > > > > > > > Yeah, no, there's almost *never* a point in using OF-specific accessors. NAK. > > > > > > Argument made to me on netdev before is it's pointless overhead for an > > > OF only driver. > > > > Would you mind posting a lore link? I'll gladly chime in. > > > > Drivers are OF-only until they aren't. Vide: lots of discussions > > currently about supporting ARM laptops and servers with mixed DT-ACPI > > setup. > Hrm I must have misremembered or I can't find it. In any case, these > devices will never support ACPI. They're all embedded devices with > uboot. > > If I had a euro everytime someone was wrong saying "never"... :) > > The overhead of going through the fwnode pointer is absolutely > > negligible while using generic accessors allows taking secondary > > fwnodes into account. > > > > Please don't tell me people are going around the kernel converting > > drivers to using of_ routines? > There's one special case I know of, of_get_mac_address vs > device_get_mac_address. The former supports NVMEM. The latter does > not. > > Yes, that is one of those special cases but a better fix would be to make NVMEM core fwnode-agnostic. While nvmem remains OF-specific, we can live with using of_get_mac_address(). Bart
© 2016 - 2026 Red Hat, Inc.