[PATCH 0/3] gpio: realtek-otto: compile fixes

[PATCH 0/3] gpio: realtek-otto: compile fixes

[Rosen Penev]

Fixes compilation on 32-bit. Also small OF change.

Rosen Penev (3):
  gpio: realtek-otto: use kernel_ulong_t
  gpio: realtek-otto: add COMPILE_TEST
  gpio: realtek-otto: use of instead of device handlers

 drivers/gpio/Kconfig             | 2 +-
 drivers/gpio/gpio-realtek-otto.c | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

--
2.52.0

[PATCH 1/3] gpio: realtek-otto: use kernel_ulong_t

[Rosen Penev]

Fixes compilation on 64-bit platforms as pointers needed a larger type.

Signed-off-by: Rosen Penev <rosenp@gmail.com>
---
 drivers/gpio/gpio-realtek-otto.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpio/gpio-realtek-otto.c b/drivers/gpio/gpio-realtek-otto.c
index de527f4fc6c2..efcddbe01308 100644
--- a/drivers/gpio/gpio-realtek-otto.c
+++ b/drivers/gpio/gpio-realtek-otto.c
@@ -372,7 +372,7 @@ static int realtek_gpio_probe(struct platform_device *pdev)
 	if (!ctrl)
 		return -ENOMEM;
 
-	dev_flags = (unsigned int) device_get_match_data(dev);
+	dev_flags = (unsigned int)(kernel_ulong_t)device_get_match_data(dev);
 
 	ngpios = REALTEK_GPIO_MAX;
 	device_property_read_u32(dev, "ngpios", &ngpios);
-- 
2.52.0

[PATCH 2/3] gpio: realtek-otto: add COMPILE_TEST

[Rosen Penev]

Allows the buildbots to test compilation.

Signed-off-by: Rosen Penev <rosenp@gmail.com>
---
 drivers/gpio/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index bd185482a7fd..fb6b479700d3 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -600,7 +600,7 @@ config GPIO_RDA
 
 config GPIO_REALTEK_OTTO
 	tristate "Realtek Otto GPIO support"
-	depends on MACH_REALTEK_RTL
+	depends on MACH_REALTEK_RTL || COMPILE_TEST
 	default MACH_REALTEK_RTL
 	select GPIO_GENERIC
 	select GPIOLIB_IRQCHIP
-- 
2.52.0

[PATCH 3/3] gpio: realtek-otto: use of instead of device handlers

[Rosen Penev]

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

Re: [PATCH 3/3] gpio: realtek-otto: use of instead of device handlers

[Bartosz Golaszewski]

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

Re: [PATCH 1/3] gpio: realtek-otto: use kernel_ulong_t

[Bartosz Golaszewski]

On Wed, Dec 17, 2025 at 7:32 AM Rosen Penev <rosenp@gmail.com> wrote:
>
> Fixes compilation on 64-bit platforms as pointers needed a larger type.
>
> Signed-off-by: Rosen Penev <rosenp@gmail.com>
> ---
>  drivers/gpio/gpio-realtek-otto.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpio/gpio-realtek-otto.c b/drivers/gpio/gpio-realtek-otto.c
> index de527f4fc6c2..efcddbe01308 100644
> --- a/drivers/gpio/gpio-realtek-otto.c
> +++ b/drivers/gpio/gpio-realtek-otto.c
> @@ -372,7 +372,7 @@ static int realtek_gpio_probe(struct platform_device *pdev)
>         if (!ctrl)
>                 return -ENOMEM;
>
> -       dev_flags = (unsigned int) device_get_match_data(dev);
> +       dev_flags = (unsigned int)(kernel_ulong_t)device_get_match_data(dev);
>
>         ngpios = REALTEK_GPIO_MAX;
>         device_property_read_u32(dev, "ngpios", &ngpios);
> --
> 2.52.0
>

Just make dev_flags an unsigned long and cast
device_get_match_data(dev) to uintptr_t.

Bart

Re: (subset) [PATCH 0/3] gpio: realtek-otto: compile fixes

[Bartosz Golaszewski]

On Tue, 16 Dec 2025 22:32:26 -0800, Rosen Penev wrote:
> Fixes compilation on 32-bit. Also small OF change.
> 
> Rosen Penev (3):
>   gpio: realtek-otto: use kernel_ulong_t
>   gpio: realtek-otto: add COMPILE_TEST
>   gpio: realtek-otto: use of instead of device handlers
> 
> [...]

Applied, thanks!

[2/3] gpio: realtek-otto: add COMPILE_TEST
      commit: 3203d8f573af87d8c967d36e8d5016ef306ff078

Best regards,
-- 
Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>

Re: [PATCH 3/3] gpio: realtek-otto: use of instead of device handlers

[Rosen Penev]

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

Re: [PATCH 1/3] gpio: realtek-otto: use kernel_ulong_t

[David Laight]

On Wed, 17 Dec 2025 10:34:26 +0100
Bartosz Golaszewski <brgl@kernel.org> wrote:

> On Wed, Dec 17, 2025 at 7:32 AM Rosen Penev <rosenp@gmail.com> wrote:
> >
> > Fixes compilation on 64-bit platforms as pointers needed a larger type.
> >
> > Signed-off-by: Rosen Penev <rosenp@gmail.com>
> > ---
> >  drivers/gpio/gpio-realtek-otto.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpio/gpio-realtek-otto.c b/drivers/gpio/gpio-realtek-otto.c
> > index de527f4fc6c2..efcddbe01308 100644
> > --- a/drivers/gpio/gpio-realtek-otto.c
> > +++ b/drivers/gpio/gpio-realtek-otto.c
> > @@ -372,7 +372,7 @@ static int realtek_gpio_probe(struct platform_device *pdev)
> >         if (!ctrl)
> >                 return -ENOMEM;
> >
> > -       dev_flags = (unsigned int) device_get_match_data(dev);
> > +       dev_flags = (unsigned int)(kernel_ulong_t)device_get_match_data(dev);
> >
> >         ngpios = REALTEK_GPIO_MAX;
> >         device_property_read_u32(dev, "ngpios", &ngpios);
> > --
> > 2.52.0
> >  
> 
> Just make dev_flags an unsigned long and cast
> device_get_match_data(dev) to uintptr_t.

Or just cast the pointer to (unsigned long) and leave dev_flags alone.
'uintptr_t' is a 'user' type, not a kernel one.
The kernel tends to just use 'long' when pointers need to be in an integer
type.

	David

> 
> Bart
> 

Re: [PATCH 3/3] gpio: realtek-otto: use of instead of device handlers

[Bartosz Golaszewski]

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

Re: [PATCH 3/3] gpio: realtek-otto: use of instead of device handlers

[Rosen Penev]

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

Re: [PATCH 3/3] gpio: realtek-otto: use of instead of device handlers

[Bartosz Golaszewski]

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