| Message ID | 20220914142713.29351-2-lukas.bulwahn@gmail.com |
|---|---|
| State | New |
| Headers | show |
| Series | [1/2] ata: clean up how architectures enable PATA_PLATFORM and PATA_OF_PLATFORM | expand |
On Wed, Sep 14, 2022, at 4:27 PM, Lukas Bulwahn wrote: > It is currently possible to select "Generic platform device PATA support" > in two situations: > > - architecture allows the generic platform device PATA support and > indicates that with "select HAVE_PATA_PLATFORM". > - if the user claims to be an EXPERT by setting CONFIG_EXPERT to yes > > However, there is no use case to have Generic platform device PATA support > in a kernel build if the architecture definition, i.e., the selection of > configs by an architecture, does not support it. > > If the architecture definition is wrong, i.e., it just misses a 'select > HAVE_PATA_PLATFORM', then even an expert that configures the kernel build > should not just fix that by overruling the claimed support by an > architecture. If the architecture definition is wrong, the expert should > just provide a patch to correct the architecture definition instead---in > the end, if the user is an expert, sending a quick one-line patch should > not be an issue. > > In other words, I do not see the deeper why an expert can overrule the > architecture definition in this case, as the expert may not overrule the > config selections defined by the architecture in the large majority > ---or probably all other (modulo some mistakes)---of similar cases. > > Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com> Sounds reasonable. My best guess about the intention of the EXPERT dependency is that it would be used for users with third-party board files or dts files referencing these. We can't really help users with out-of-tree boardfiles, and the external dts case would be covered by your patch 1/2. Reviewed-by: Arnd Bergmann <arnd@arndb.de>
diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig index c93d97455744..fc11d9d30d72 100644 --- a/drivers/ata/Kconfig +++ b/drivers/ata/Kconfig @@ -1102,7 +1102,7 @@ config PATA_PCMCIA If unsure, say N. config PATA_PLATFORM - tristate "Generic platform device PATA support" if EXPERT || HAVE_PATA_PLATFORM + tristate "Generic platform device PATA support" if HAVE_PATA_PLATFORM help This option enables support for generic directly connected ATA devices commonly found on embedded systems.
It is currently possible to select "Generic platform device PATA support" in two situations: - architecture allows the generic platform device PATA support and indicates that with "select HAVE_PATA_PLATFORM". - if the user claims to be an EXPERT by setting CONFIG_EXPERT to yes However, there is no use case to have Generic platform device PATA support in a kernel build if the architecture definition, i.e., the selection of configs by an architecture, does not support it. If the architecture definition is wrong, i.e., it just misses a 'select HAVE_PATA_PLATFORM', then even an expert that configures the kernel build should not just fix that by overruling the claimed support by an architecture. If the architecture definition is wrong, the expert should just provide a patch to correct the architecture definition instead---in the end, if the user is an expert, sending a quick one-line patch should not be an issue. In other words, I do not see the deeper why an expert can overrule the architecture definition in this case, as the expert may not overrule the config selections defined by the architecture in the large majority ---or probably all other (modulo some mistakes)---of similar cases. Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com> --- drivers/ata/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)