[PATCH] drm/sitronix: Fix broken backwards-compatibility layer

[PATCH] drm/sitronix: Fix broken backwards-compatibility layer

[Geert Uytterhoeven]

When moving the Sitronix DRM drivers and renaming their Kconfig symbols,
the old symbols were kept, aiming to provide a seamless migration path
when running "make olddefconfig" or "make oldconfig".

However, the old compatibility symbols are not visible.  Hence unless
they are selected by another symbol (which they are not), they can never
be enabled, and no backwards compatibility is provided.

Fix this by making them visible, and inverting the selection logic.
Add comments to make it clear why there are two symbols with the same
description.

Fixes: 9b8f32002cddf792 ("drm/sitronix: move tiny Sitronix drivers to their own subdir")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
arch/arm/configs/davinci_all_defconfig must be updated after this has
hit upstream.
---
 drivers/gpu/drm/sitronix/Kconfig | 14 ++++++++------
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/sitronix/Kconfig b/drivers/gpu/drm/sitronix/Kconfig
index c069d0d417753bcf..8b3565b8eca3918e 100644
--- a/drivers/gpu/drm/sitronix/Kconfig
+++ b/drivers/gpu/drm/sitronix/Kconfig
@@ -10,9 +10,11 @@ config DRM_ST7571_I2C
 
 	  if M is selected the module will be called st7571-i2c.
 
+# To be removed once all users have updated their (def)configs
 config TINYDRM_ST7586
-	tristate
-	default n
+	tristate "DRM support for Sitronix ST7586 display panels"
+	depends on DRM && SPI
+	select DRM_ST7586
 
 config DRM_ST7586
 	tristate "DRM support for Sitronix ST7586 display panels"
@@ -21,16 +23,17 @@ config DRM_ST7586
 	select DRM_KMS_HELPER
 	select DRM_GEM_DMA_HELPER
 	select DRM_MIPI_DBI
-	default TINYDRM_ST7586
 	help
 	  DRM driver for the following Sitronix ST7586 panels:
 	  * LEGO MINDSTORMS EV3
 
 	  If M is selected the module will be called st7586.
 
+# To be removed once all users have updated their (def)configs
 config TINYDRM_ST7735R
-	tristate
-	default n
+	tristate "DRM support for Sitronix ST7715R/ST7735R display panels"
+	depends on DRM && SPI
+	select DRM_ST7735R
 
 config DRM_ST7735R
 	tristate "DRM support for Sitronix ST7715R/ST7735R display panels"
@@ -40,7 +43,6 @@ config DRM_ST7735R
 	select DRM_GEM_DMA_HELPER
 	select DRM_MIPI_DBI
 	select BACKLIGHT_CLASS_DEVICE
-	default TINYDRM_ST7735R
 	help
 	  DRM driver for Sitronix ST7715R/ST7735R with one of the following
 	  LCDs:
-- 
2.43.0

Re: [PATCH] drm/sitronix: Fix broken backwards-compatibility layer

[Thomas Zimmermann]

Hi

Am 20.05.25 um 14:40 schrieb Geert Uytterhoeven:
> When moving the Sitronix DRM drivers and renaming their Kconfig symbols,
> the old symbols were kept, aiming to provide a seamless migration path
> when running "make olddefconfig" or "make oldconfig".
>
> However, the old compatibility symbols are not visible.  Hence unless
> they are selected by another symbol (which they are not), they can never
> be enabled, and no backwards compatibility is provided.
>
> Fix this by making them visible, and inverting the selection logic.
> Add comments to make it clear why there are two symbols with the same
> description.

These symbols were only meant for variants of 'make oldconfig' to pick 
up th enew symbols. They where never for being selected manually.

Best regards
Thomas

>
> Fixes: 9b8f32002cddf792 ("drm/sitronix: move tiny Sitronix drivers to their own subdir")
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
> arch/arm/configs/davinci_all_defconfig must be updated after this has
> hit upstream.
> ---
>   drivers/gpu/drm/sitronix/Kconfig | 14 ++++++++------
>   1 file changed, 8 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/sitronix/Kconfig b/drivers/gpu/drm/sitronix/Kconfig
> index c069d0d417753bcf..8b3565b8eca3918e 100644
> --- a/drivers/gpu/drm/sitronix/Kconfig
> +++ b/drivers/gpu/drm/sitronix/Kconfig
> @@ -10,9 +10,11 @@ config DRM_ST7571_I2C
>   
>   	  if M is selected the module will be called st7571-i2c.
>   
> +# To be removed once all users have updated their (def)configs
>   config TINYDRM_ST7586
> -	tristate
> -	default n
> +	tristate "DRM support for Sitronix ST7586 display panels"
> +	depends on DRM && SPI
> +	select DRM_ST7586
>   
>   config DRM_ST7586
>   	tristate "DRM support for Sitronix ST7586 display panels"
> @@ -21,16 +23,17 @@ config DRM_ST7586
>   	select DRM_KMS_HELPER
>   	select DRM_GEM_DMA_HELPER
>   	select DRM_MIPI_DBI
> -	default TINYDRM_ST7586
>   	help
>   	  DRM driver for the following Sitronix ST7586 panels:
>   	  * LEGO MINDSTORMS EV3
>   
>   	  If M is selected the module will be called st7586.
>   
> +# To be removed once all users have updated their (def)configs
>   config TINYDRM_ST7735R
> -	tristate
> -	default n
> +	tristate "DRM support for Sitronix ST7715R/ST7735R display panels"
> +	depends on DRM && SPI
> +	select DRM_ST7735R
>   
>   config DRM_ST7735R
>   	tristate "DRM support for Sitronix ST7715R/ST7735R display panels"
> @@ -40,7 +43,6 @@ config DRM_ST7735R
>   	select DRM_GEM_DMA_HELPER
>   	select DRM_MIPI_DBI
>   	select BACKLIGHT_CLASS_DEVICE
> -	default TINYDRM_ST7735R
>   	help
>   	  DRM driver for Sitronix ST7715R/ST7735R with one of the following
>   	  LCDs:

-- 
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)

Re: [PATCH] drm/sitronix: Fix broken backwards-compatibility layer

[Geert Uytterhoeven]

Hi Thomas,

On Tue, 20 May 2025 at 15:04, Thomas Zimmermann <tzimmermann@suse.de> wrote:
> Am 20.05.25 um 14:40 schrieb Geert Uytterhoeven:
> > When moving the Sitronix DRM drivers and renaming their Kconfig symbols,
> > the old symbols were kept, aiming to provide a seamless migration path
> > when running "make olddefconfig" or "make oldconfig".
> >
> > However, the old compatibility symbols are not visible.  Hence unless
> > they are selected by another symbol (which they are not), they can never
> > be enabled, and no backwards compatibility is provided.
> >
> > Fix this by making them visible, and inverting the selection logic.
> > Add comments to make it clear why there are two symbols with the same
> > description.
>
> These symbols were only meant for variants of 'make oldconfig' to pick
> up th enew symbols. They where never for being selected manually.

But that pick-up does not work, unfortunately...
(I know, I had one of them enabled in one of my configs ;-)

The alternative is to just drop the old symbols, and ignore current users.
Which is not that uncommon...

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH] drm/sitronix: Fix broken backwards-compatibility layer

[Thomas Zimmermann]

Hi

Am 20.05.25 um 15:09 schrieb Geert Uytterhoeven:
> Hi Thomas,
>
> On Tue, 20 May 2025 at 15:04, Thomas Zimmermann <tzimmermann@suse.de> wrote:
>> Am 20.05.25 um 14:40 schrieb Geert Uytterhoeven:
>>> When moving the Sitronix DRM drivers and renaming their Kconfig symbols,
>>> the old symbols were kept, aiming to provide a seamless migration path
>>> when running "make olddefconfig" or "make oldconfig".
>>>
>>> However, the old compatibility symbols are not visible.  Hence unless
>>> they are selected by another symbol (which they are not), they can never
>>> be enabled, and no backwards compatibility is provided.
>>>
>>> Fix this by making them visible, and inverting the selection logic.
>>> Add comments to make it clear why there are two symbols with the same
>>> description.
>> These symbols were only meant for variants of 'make oldconfig' to pick
>> up th enew symbols. They where never for being selected manually.
> But that pick-up does not work, unfortunately...
> (I know, I had one of them enabled in one of my configs ;-)

I see.

>
> The alternative is to just drop the old symbols, and ignore current users.
> Which is not that uncommon...

If there's no easy fix for the current setup, I'd prefer removing the 
old symbols.

Best regards
Thomas

>
> Gr{oetje,eeting}s,
>
>                          Geert
>

-- 
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)

Re: [PATCH] drm/sitronix: Fix broken backwards-compatibility layer

[Javier Martinez Canillas]

Thomas Zimmermann <tzimmermann@suse.de> writes:

> Hi
>
> Am 20.05.25 um 15:09 schrieb Geert Uytterhoeven:
>> Hi Thomas,
>>
>> On Tue, 20 May 2025 at 15:04, Thomas Zimmermann <tzimmermann@suse.de> wrote:
>>> Am 20.05.25 um 14:40 schrieb Geert Uytterhoeven:
>>>> When moving the Sitronix DRM drivers and renaming their Kconfig symbols,
>>>> the old symbols were kept, aiming to provide a seamless migration path
>>>> when running "make olddefconfig" or "make oldconfig".
>>>>
>>>> However, the old compatibility symbols are not visible.  Hence unless
>>>> they are selected by another symbol (which they are not), they can never
>>>> be enabled, and no backwards compatibility is provided.
>>>>
>>>> Fix this by making them visible, and inverting the selection logic.
>>>> Add comments to make it clear why there are two symbols with the same
>>>> description.
>>> These symbols were only meant for variants of 'make oldconfig' to pick
>>> up th enew symbols. They where never for being selected manually.
>> But that pick-up does not work, unfortunately...
>> (I know, I had one of them enabled in one of my configs ;-)
>
> I see.
>
>>
>> The alternative is to just drop the old symbols, and ignore current users.
>> Which is not that uncommon...
>
> If there's no easy fix for the current setup, I'd prefer removing the 
> old symbols.
>

I agree. When this was discussed, I argued that we should just remove the
old symbols and let kernel packagers to deal with it. As Geert said, it's
not uncommon for Kconfig symbols names to change over time...

-- 
Best regards,

Javier Martinez Canillas
Core Platforms
Red Hat