[RFC] pinctrl: ingenic: impossible MACH_* guards can drop OF match data

[RFC] pinctrl: ingenic: impossible MACH_* guards can drop OF match data

[Pengpeng Hou]

Hi,

while auditing conditional data-provider paths, I noticed that
drivers/pinctrl/pinctrl-ingenic.c still derives some SoC descriptor exposure
from IS_ENABLED(CONFIG_MACH_*) style conditions whose corresponding Kconfig
symbols do not appear to exist in the current Ingenic Kconfig universe.

This looks like a data-symbol legality issue rather than a simple cleanup:
the OF match table .data entries carry SoC-specific pinctrl descriptors.  If
the guard can never be true, a compatible string can lose the intended
descriptor provider even though the descriptor is still present in source.

I am not sending a patch yet because the correct policy is not obvious.  The
possible directions include:

1. remove impossible MACH_* gates from the OF match data;
2. restore current Kconfig symbols for the intended SoC families;
3. split unsupported legacy SoCs from supported descriptor exposure; or
4. keep the gates and document that these descriptors are intentionally not
   exposed.

Could you confirm which direction matches the current Ingenic pinctrl support
policy?

This is static source/Kconfig analysis only.  I have not tested the affected
hardware.

Thanks,
Pengpeng

Re: [RFC] pinctrl: ingenic: impossible MACH_* guards can drop OF match data

[H. Nikolaus Schaller]

Hi,

Since I am just these days working to extend the ingenic-pinctrl driver for x2600
support, I can comment from a distribution kernel perspective.

> Am 25.06.2026 um 08:09 schrieb Pengpeng Hou <pengpeng@iscas.ac.cn>:
> 
> Hi,
> 
> while auditing conditional data-provider paths, I noticed that
> drivers/pinctrl/pinctrl-ingenic.c still derives some SoC descriptor exposure
> from IS_ENABLED(CONFIG_MACH_*) style conditions whose corresponding Kconfig
> symbols do not appear to exist in the current Ingenic Kconfig universe.
> 
> This looks like a data-symbol legality issue rather than a simple cleanup:
> the OF match table .data entries carry SoC-specific pinctrl descriptors.  If

The idea is that you can choose through CONFIG_MACH_* which records are
included in the match table at all to be able to shrink the driver to a bare
minimum for embedded use (e.g. X1600 with just 32 MB RAM).

Or have a full driver for a distribution kernel which supports all options by a
full driver (module).

Currently we have in the LetuxOS kernel:

grep -e "CONFIG_MACH_JZ" -e "CONFIG_MACH_X" .config
CONFIG_MACH_JZ4725B=y
CONFIG_MACH_JZ4730=y
CONFIG_MACH_JZ4740=y
CONFIG_MACH_JZ4770=y
CONFIG_MACH_JZ4780=y
CONFIG_MACH_X1000=y
CONFIG_MACH_X1600=y
CONFIG_MACH_X1830=y
CONFIG_MACH_X2000=y
CONFIG_MACH_X2600=y

> the guard can never be true, a compatible string can lose the intended
> descriptor provider even though the descriptor is still present in source.
> 
> I am not sending a patch yet because the correct policy is not obvious.  The
> possible directions include:
> 
> 1. remove impossible MACH_* gates from the OF match data;
> 2. restore current Kconfig symbols for the intended SoC families;
> 3. split unsupported legacy SoCs from supported descriptor exposure; or
> 4. keep the gates and document that these descriptors are intentionally not
>   exposed.

5. keep it as is and wait until we can upstream some missing SoC families.

(BTW: can you list what you think is unsupported legacy or impossible please?)

> 
> Could you confirm which direction matches the current Ingenic pinctrl support
> policy?
> 
> This is static source/Kconfig analysis only.  I have not tested the affected
> hardware.
> 
> Thanks,
> Pengpeng

Hope this helps the maintainers to decide.

BR,
Nikolaus