Making pinctrl drivers and subsequently the pinctrl framework
user-controllable, allows building a kernel without this.
While in many (most) cases, this could make the system unbootable, it
does allow building smaller kernels for those situations where picntrl
is not needed.
One such situation is when building a kernel for NXP LS1021A systems,
which does not have run-time controllable pinctrl, so pinctrl framework
and drivers are 100% dead-weight.
Signed-off-by: Esben Haabendal <esben@geanix.com>
---
arch/arm/mach-imx/Kconfig | 16 ----------------
drivers/pinctrl/freescale/Kconfig | 15 +++++++++++++++
2 files changed, 15 insertions(+), 16 deletions(-)
diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
index ab767f059929..e4fe059cd861 100644
--- a/arch/arm/mach-imx/Kconfig
+++ b/arch/arm/mach-imx/Kconfig
@@ -6,7 +6,6 @@ menuconfig ARCH_MXC
select CLKSRC_IMX_GPT
select GENERIC_IRQ_CHIP
select GPIOLIB
- select PINCTRL
select PM_OPP if PM
select SOC_BUS
select SRAM
@@ -49,7 +48,6 @@ config SOC_IMX31
config SOC_IMX35
bool "i.MX35 support"
select MXC_AVIC
- select PINCTRL_IMX35
help
This enables support for Freescale i.MX35 processor
@@ -61,7 +59,6 @@ config SOC_IMX1
bool "i.MX1 support"
select CPU_ARM920T
select MXC_AVIC
- select PINCTRL_IMX1
help
This enables support for Freescale i.MX1 processor
@@ -73,7 +70,6 @@ config SOC_IMX25
bool "i.MX25 support"
select CPU_ARM926T
select MXC_AVIC
- select PINCTRL_IMX25
help
This enables support for Freescale i.MX25 processor
@@ -81,7 +77,6 @@ config SOC_IMX27
bool "i.MX27 support"
select CPU_ARM926T
select MXC_AVIC
- select PINCTRL_IMX27
help
This enables support for Freescale i.MX27 processor
@@ -98,7 +93,6 @@ config SOC_IMX5
config SOC_IMX50
bool "i.MX50 support"
- select PINCTRL_IMX50
select SOC_IMX5
help
@@ -106,14 +100,12 @@ config SOC_IMX50
config SOC_IMX51
bool "i.MX51 support"
- select PINCTRL_IMX51
select SOC_IMX5
help
This enables support for Freescale i.MX51 processor
config SOC_IMX53
bool "i.MX53 support"
- select PINCTRL_IMX53
select SOC_IMX5
help
@@ -137,7 +129,6 @@ config SOC_IMX6Q
select ARM_ERRATA_775420
select HAVE_ARM_SCU if SMP
select HAVE_ARM_TWD
- select PINCTRL_IMX6Q
select SOC_IMX6
help
@@ -147,7 +138,6 @@ config SOC_IMX6SL
bool "i.MX6 SoloLite support"
select ARM_ERRATA_754322
select ARM_ERRATA_775420
- select PINCTRL_IMX6SL
select SOC_IMX6
help
@@ -157,7 +147,6 @@ config SOC_IMX6SLL
bool "i.MX6 SoloLiteLite support"
select ARM_ERRATA_754322
select ARM_ERRATA_775420
- select PINCTRL_IMX6SLL
select SOC_IMX6
help
@@ -167,7 +156,6 @@ config SOC_IMX6SX
bool "i.MX6 SoloX support"
select ARM_ERRATA_754322
select ARM_ERRATA_775420
- select PINCTRL_IMX6SX
select SOC_IMX6
help
@@ -175,7 +163,6 @@ config SOC_IMX6SX
config SOC_IMX6UL
bool "i.MX6 UltraLite support"
- select PINCTRL_IMX6UL
select SOC_IMX6
select ARM_ERRATA_814220
@@ -211,7 +198,6 @@ config SOC_IMX7D_CM4
config SOC_IMX7D
bool "i.MX7 Dual support"
- select PINCTRL_IMX7D
select SOC_IMX7D_CA7 if ARCH_MULTI_V7
select SOC_IMX7D_CM4 if ARM_SINGLE_ARMV7M
select ARM_ERRATA_814220 if ARCH_MULTI_V7
@@ -221,7 +207,6 @@ config SOC_IMX7D
config SOC_IMX7ULP
bool "i.MX7ULP support"
select CLKSRC_IMX_TPM
- select PINCTRL_IMX7ULP
select SOC_IMX7D_CA7 if ARCH_MULTI_V7
select SOC_IMX7D_CM4 if ARM_SINGLE_ARMV7M
help
@@ -237,7 +222,6 @@ config SOC_IMXRT
config SOC_VF610
bool "Vybrid Family VF610 support"
select ARM_GIC if ARCH_MULTI_V7
- select PINCTRL_VF610
help
This enables support for Freescale Vybrid VF610 processor.
diff --git a/drivers/pinctrl/freescale/Kconfig b/drivers/pinctrl/freescale/Kconfig
index 27bdc548f3a7..ef39bb6cf9cb 100644
--- a/drivers/pinctrl/freescale/Kconfig
+++ b/drivers/pinctrl/freescale/Kconfig
@@ -20,6 +20,7 @@ config PINCTRL_IMX1_CORE
config PINCTRL_IMX1
bool "IMX1 pinctrl driver"
depends on SOC_IMX1
+ default SOC_IMX1
select PINCTRL_IMX1_CORE
help
Say Y here to enable the imx1 pinctrl driver
@@ -27,6 +28,7 @@ config PINCTRL_IMX1
config PINCTRL_IMX27
bool "IMX27 pinctrl driver"
depends on SOC_IMX27
+ default SOC_IMX27
select PINCTRL_IMX1_CORE
help
Say Y here to enable the imx27 pinctrl driver
@@ -36,6 +38,7 @@ config PINCTRL_IMX25
bool "IMX25 pinctrl driver"
depends on OF
depends on SOC_IMX25
+ default SOC_IMX25
select PINCTRL_IMX
help
Say Y here to enable the imx25 pinctrl driver
@@ -43,6 +46,7 @@ config PINCTRL_IMX25
config PINCTRL_IMX35
bool "IMX35 pinctrl driver"
depends on SOC_IMX35
+ default SOC_IMX35
select PINCTRL_IMX
help
Say Y here to enable the imx35 pinctrl driver
@@ -50,6 +54,7 @@ config PINCTRL_IMX35
config PINCTRL_IMX50
bool "IMX50 pinctrl driver"
depends on SOC_IMX50
+ default SOC_IMX50
select PINCTRL_IMX
help
Say Y here to enable the imx50 pinctrl driver
@@ -57,6 +62,7 @@ config PINCTRL_IMX50
config PINCTRL_IMX51
bool "IMX51 pinctrl driver"
depends on SOC_IMX51
+ default SOC_IMX51
select PINCTRL_IMX
help
Say Y here to enable the imx51 pinctrl driver
@@ -64,6 +70,7 @@ config PINCTRL_IMX51
config PINCTRL_IMX53
bool "IMX53 pinctrl driver"
depends on SOC_IMX53
+ default SOC_IMX53
select PINCTRL_IMX
help
Say Y here to enable the imx53 pinctrl driver
@@ -71,6 +78,7 @@ config PINCTRL_IMX53
config PINCTRL_IMX6Q
bool "IMX6Q/DL pinctrl driver"
depends on SOC_IMX6Q
+ default SOC_IMX6Q
select PINCTRL_IMX
help
Say Y here to enable the imx6q/dl pinctrl driver
@@ -78,6 +86,7 @@ config PINCTRL_IMX6Q
config PINCTRL_IMX6SL
bool "IMX6SL pinctrl driver"
depends on SOC_IMX6SL
+ default SOC_IMX6SL
select PINCTRL_IMX
help
Say Y here to enable the imx6sl pinctrl driver
@@ -85,6 +94,7 @@ config PINCTRL_IMX6SL
config PINCTRL_IMX6SLL
bool "IMX6SLL pinctrl driver"
depends on SOC_IMX6SLL
+ default SOC_IMX6SLL
select PINCTRL_IMX
help
Say Y here to enable the imx6sll pinctrl driver
@@ -92,6 +102,7 @@ config PINCTRL_IMX6SLL
config PINCTRL_IMX6SX
bool "IMX6SX pinctrl driver"
depends on SOC_IMX6SX
+ default SOC_IMX6SX
select PINCTRL_IMX
help
Say Y here to enable the imx6sx pinctrl driver
@@ -99,6 +110,7 @@ config PINCTRL_IMX6SX
config PINCTRL_IMX6UL
bool "IMX6UL pinctrl driver"
depends on SOC_IMX6UL
+ default SOC_IMX6UL
select PINCTRL_IMX
help
Say Y here to enable the imx6ul pinctrl driver
@@ -106,6 +118,7 @@ config PINCTRL_IMX6UL
config PINCTRL_IMX7D
bool "IMX7D pinctrl driver"
depends on SOC_IMX7D
+ default SOC_IMX7D
select PINCTRL_IMX
help
Say Y here to enable the imx7d pinctrl driver
@@ -113,6 +126,7 @@ config PINCTRL_IMX7D
config PINCTRL_IMX7ULP
bool "IMX7ULP pinctrl driver"
depends on SOC_IMX7ULP
+ default SOC_IMX7ULP
select PINCTRL_IMX
help
Say Y here to enable the imx7ulp pinctrl driver
@@ -194,6 +208,7 @@ config PINCTRL_IMX93
config PINCTRL_VF610
bool "Freescale Vybrid VF610 pinctrl driver"
depends on SOC_VF610
+ default SOC_VF610
select PINCTRL_IMX
help
Say Y here to enable the Freescale Vybrid VF610 pinctrl driver
--
2.45.0On Mon, May 06, 2024 at 12:23:53PM +0200, Esben Haabendal wrote: > Making pinctrl drivers and subsequently the pinctrl framework > user-controllable, allows building a kernel without this. > While in many (most) cases, this could make the system unbootable, it > does allow building smaller kernels for those situations where picntrl > is not needed. > > One such situation is when building a kernel for NXP LS1021A systems, > which does not have run-time controllable pinctrl, so pinctrl framework > and drivers are 100% dead-weight. > > > Signed-off-by: Esben Haabendal <esben@geanix.com> This patch didn't update default configurations, meaning PINCTRL is now disabled by affected configurations such as imx_v4_v5_defconfig or imx_v6_v7_defconfig, making pretty much all imx platforms non-bootable unless the default configuration is changed manually. Guenter
On Tue, Nov 26, 2024 at 5:17 PM Guenter Roeck <linux@roeck-us.net> wrote:
> On Mon, May 06, 2024 at 12:23:53PM +0200, Esben Haabendal wrote:
> > Making pinctrl drivers and subsequently the pinctrl framework
> > user-controllable, allows building a kernel without this.
> > While in many (most) cases, this could make the system unbootable, it
> > does allow building smaller kernels for those situations where picntrl
> > is not needed.
> >
> > One such situation is when building a kernel for NXP LS1021A systems,
> > which does not have run-time controllable pinctrl, so pinctrl framework
> > and drivers are 100% dead-weight.
> >
> >
> > Signed-off-by: Esben Haabendal <esben@geanix.com>
>
> This patch didn't update default configurations, meaning PINCTRL is now
> disabled by affected configurations such as imx_v4_v5_defconfig or
> imx_v6_v7_defconfig, making pretty much all imx platforms non-bootable
> unless the default configuration is changed manually.
Since the patch tries to add default selects for all drivers I suspect this
oneliner is the culprit:
@@ -6,7 +6,6 @@ menuconfig ARCH_MXC
select CLKSRC_IMX_GPT
select GENERIC_IRQ_CHIP
select GPIOLIB
- select PINCTRL
select PM_OPP if PM
select SOC_BUS
select SRAM
Should we just add that one line back?
Yours,
Linus Walleij
On 11/26/24 13:24, Linus Walleij wrote: > On Tue, Nov 26, 2024 at 5:17 PM Guenter Roeck <linux@roeck-us.net> wrote: >> On Mon, May 06, 2024 at 12:23:53PM +0200, Esben Haabendal wrote: > >>> Making pinctrl drivers and subsequently the pinctrl framework >>> user-controllable, allows building a kernel without this. >>> While in many (most) cases, this could make the system unbootable, it >>> does allow building smaller kernels for those situations where picntrl >>> is not needed. >>> >>> One such situation is when building a kernel for NXP LS1021A systems, >>> which does not have run-time controllable pinctrl, so pinctrl framework >>> and drivers are 100% dead-weight. >>> >>> >>> Signed-off-by: Esben Haabendal <esben@geanix.com> >> >> This patch didn't update default configurations, meaning PINCTRL is now >> disabled by affected configurations such as imx_v4_v5_defconfig or >> imx_v6_v7_defconfig, making pretty much all imx platforms non-bootable >> unless the default configuration is changed manually. > > Since the patch tries to add default selects for all drivers I suspect this > oneliner is the culprit: > > @@ -6,7 +6,6 @@ menuconfig ARCH_MXC > select CLKSRC_IMX_GPT > select GENERIC_IRQ_CHIP > select GPIOLIB > - select PINCTRL > select PM_OPP if PM > select SOC_BUS > select SRAM > > Should we just add that one line back? > My understanding (which may be wrong) is that being able to disable PINCTRL was the whole point of the patch. Fabio submitted a patch enabling PINCTRL for imx_v4_v5_defconfig and imx_v6_v7_defconfig explicitly [1]. I don't know if that fixes the problem for good - I see CONFIG_ARCH_MXC in other configurations as well. Guenter --- [1] https://lore.kernel.org/imx/d718ddd2-d473-4455-b21a-15024e46787c@roeck-us.net/T/#mc71dc21d99e0b013c5ce46c0d90940fd8806ae9a
On Tue, Nov 26, 2024 at 8:53 PM Guenter Roeck <linux@roeck-us.net> wrote: > My understanding (which may be wrong) is that being able to disable > PINCTRL was the whole point of the patch. Exactly. Adding back the "select PINCTRL" line defeats the purpose of the patch in Subject. > Fabio submitted a patch enabling PINCTRL for imx_v4_v5_defconfig and > imx_v6_v7_defconfig explicitly [1]. I don't know if that fixes the > problem for good - I see CONFIG_ARCH_MXC in other configurations as > well. Good point. I can send a v2 adding CONFIG_PINCTRL=y to the other defconfigs. However, after thinking more about it, I wonder if the patch in Subject is worth it. It can help reduce the kernel size for LS1021A that does not need pinctrl, but on the other hand, it will cause pain to lots of people who have i.MX products running custom defconfigs. When they update their kernel to 6.13-rc1 their i.MX will not boot and that will be a very unpleasant experience. What do you think? Should we go with the approach of selecting CONFIG_PINCTRL=y or should we revert this patch? IMHO, the benefit of this patch does not justify the bad impact on users.
On Tue, Nov 26 2024, Fabio Estevam <festevam@gmail.com> wrote: > On Tue, Nov 26, 2024 at 8:53 PM Guenter Roeck <linux@roeck-us.net> wrote: > >> My understanding (which may be wrong) is that being able to disable >> PINCTRL was the whole point of the patch. > > Exactly. > > Adding back the "select PINCTRL" line defeats the purpose of the patch > in Subject. > Yup. >> Fabio submitted a patch enabling PINCTRL for imx_v4_v5_defconfig and >> imx_v6_v7_defconfig explicitly [1]. I don't know if that fixes the >> problem for good - I see CONFIG_ARCH_MXC in other configurations as >> well. > > Good point. I can send a v2 adding CONFIG_PINCTRL=y to the other defconfigs. > Instead of doing that, isn't this exactly what the 'imply' keyword is for? - weak reverse dependencies: "imply" <symbol> ["if" <expr>] This is similar to "select" as it enforces a lower limit on another symbol except that the "implied" symbol's value may still be set to n from a direct dependency or with a visible prompt. So how about adding 'imply PINCTRL' in lieu of the previous 'select PINCTRL'? And that would also better match the intention of the patch in question (namely that the user needs to take explicit action to disable PINCTRL). Rasmus
On Wed, Nov 27, 2024, at 10:13, Rasmus Villemoes wrote:
> On Tue, Nov 26 2024, Fabio Estevam <festevam@gmail.com> wrote:
>>> Fabio submitted a patch enabling PINCTRL for imx_v4_v5_defconfig and
>>> imx_v6_v7_defconfig explicitly [1]. I don't know if that fixes the
>>> problem for good - I see CONFIG_ARCH_MXC in other configurations as
>>> well.
>>
>> Good point. I can send a v2 adding CONFIG_PINCTRL=y to the other defconfigs.
>>
>
> Instead of doing that, isn't this exactly what the 'imply' keyword is
> for?
>
> - weak reverse dependencies: "imply" <symbol> ["if" <expr>]
>
> This is similar to "select" as it enforces a lower limit on another
> symbol except that the "implied" symbol's value may still be set to n
> from a direct dependency or with a visible prompt.
>
>
> So how about adding 'imply PINCTRL' in lieu of the previous 'select
> PINCTRL'? And that would also better match the intention of the patch in
> question (namely that the user needs to take explicit action to disable
> PINCTRL).
Please never use imply. Even if you think it's the right
thing in a particular case, it will come back to bite you
later.
See also https://en.wikipedia.org/wiki/COMEFROM ;-)
I would prefer we completely kill off that keyword from the Kconfig
language and replace it with the reverse 'default'. In this
particular case, having 'default ARCH_IMX' in 'PINCTRL'
would of course not be a great idea, but for the exact same
reason, the 'imply' is wrong here.
Arnd
On Wed, Nov 27 2024, "Arnd Bergmann" <arnd@arndb.de> wrote: > On Wed, Nov 27, 2024, at 10:13, Rasmus Villemoes wrote: >> On Tue, Nov 26 2024, Fabio Estevam <festevam@gmail.com> wrote: >>>> Fabio submitted a patch enabling PINCTRL for imx_v4_v5_defconfig and >>>> imx_v6_v7_defconfig explicitly [1]. I don't know if that fixes the >>>> problem for good - I see CONFIG_ARCH_MXC in other configurations as >>>> well. >>> >>> Good point. I can send a v2 adding CONFIG_PINCTRL=y to the other defconfigs. >>> >> >> Instead of doing that, isn't this exactly what the 'imply' keyword is >> for? >> >> - weak reverse dependencies: "imply" <symbol> ["if" <expr>] >> >> This is similar to "select" as it enforces a lower limit on another >> symbol except that the "implied" symbol's value may still be set to n >> from a direct dependency or with a visible prompt. >> >> >> So how about adding 'imply PINCTRL' in lieu of the previous 'select >> PINCTRL'? And that would also better match the intention of the patch in >> question (namely that the user needs to take explicit action to disable >> PINCTRL). > > Please never use imply. Even if you think it's the right > thing in a particular case, it will come back to bite you > later. Could you elaborate? > See also https://en.wikipedia.org/wiki/COMEFROM ;-) Yes yes, we've probably all seen that at some point and chuckled, but I fail to see why imply would be worse than select. > I would prefer we completely kill off that keyword from the Kconfig > language and replace it with the reverse 'default'. In this > particular case, having 'default ARCH_IMX' in 'PINCTRL' > would of course not be a great idea, Just to be clear, it would be 'default y if ARCH_MXC', not 'default ARCH_IMX', right? Yes, given that the PINCTRL entry doesn't currently have a list of "default y if ...", it would seem inappropriate. > but for the exact same reason, the 'imply' is wrong here. I don't follow, sorry. Rasmus
On Wed, Nov 27, 2024, at 11:13, Rasmus Villemoes wrote:
> On Wed, Nov 27 2024, "Arnd Bergmann" <arnd@arndb.de> wrote:
>> On Wed, Nov 27, 2024, at 10:13, Rasmus Villemoes wrote:
>>> On Tue, Nov 26 2024, Fabio Estevam <festevam@gmail.com> wrote:
>>
>> Please never use imply. Even if you think it's the right
>> thing in a particular case, it will come back to bite you
>> later.
>
> Could you elaborate?
>
>> See also https://en.wikipedia.org/wiki/COMEFROM ;-)
>
> Yes yes, we've probably all seen that at some point and chuckled, but I
> fail to see why imply would be worse than select.
There are multiple problems here that I conflated, let
me try to explain better:
- The patch here replaces a hard 'select' with a softer 'default'
for the i.MX drivers. Both variants are used in multiple
pinctrl drivers, and there are sensible arguments to go
one way or another. However, mixing 'select' and 'default'
on a given platform would be wrong, and my point here is
that mixing 'imply' and 'default' on a single platform is
just as wrong, specifically because of the COMEFROM issue:
even if it all works as intended, a reader will have a hard
time figuring out why exactly it works like this, and this
likely leads to bugs in the future.
- In the more common cases I've seen, the use of 'imply' is
itself a bug, usually developers pick it because there is a
hard dependency between two drivers, but using 'select'
causes build issues, either from broken Kconfig constraints
or from link failures. I tend to find out about them when
a randconfig build still runs into the link failure and
the 'imply' just made it less likely to happen.
>> I would prefer we completely kill off that keyword from the Kconfig
>> language and replace it with the reverse 'default'. In this
>> particular case, having 'default ARCH_IMX' in 'PINCTRL'
>> would of course not be a great idea,
>
> Just to be clear, it would be 'default y if ARCH_MXC', not 'default
> ARCH_IMX', right?
Either one, the two statements have the same effect in this case
since both ARCH_IMX and PINCTRL are 'bool' symbols.
Overall, my best advice here is still to not change the way
i.MX pinctrl works at all, but just fix Layerscape to not depend
on i.MX. The reason for the 'select' here is clearly that the
i.MX machines would fail to boot without pinctrl, and changing
that because of Layerscape seems backwards.
On the other hand, removing all 'select PINCTRL' and instead
using 'default' consistently may be a good idea for the
long run, especially if we want to do the same for clk, irqchip,
timer, regulator etc. At the moment, we have an arbitrary
cutoff where some subsystems are always considered essential,
while others are always considered optional and some are in
the middle even if turning them off still makes the system
unusable.
Arnd
On Wed, Nov 27, 2024 at 8:30 AM Arnd Bergmann <arnd@arndb.de> wrote: > Overall, my best advice here is still to not change the way > i.MX pinctrl works at all, but just fix Layerscape to not depend > on i.MX. The reason for the 'select' here is clearly that the > i.MX machines would fail to boot without pinctrl, and changing > that because of Layerscape seems backwards. The suggestion to make Layerscape independent of i.MX makes sense, but I don't know if it can be safely applied in 6.13-rc. This proposed change also has the risk of causing regressions. What if we revert the patch in Subject for now and then someone (maybe Esben) tries again for a proper fix targeting 6.14?
Fabio Estevam <festevam@gmail.com> writes: > On Wed, Nov 27, 2024 at 8:30 AM Arnd Bergmann <arnd@arndb.de> wrote: > >> Overall, my best advice here is still to not change the way >> i.MX pinctrl works at all, but just fix Layerscape to not depend >> on i.MX. The reason for the 'select' here is clearly that the >> i.MX machines would fail to boot without pinctrl, and changing >> that because of Layerscape seems backwards. > > The suggestion to make Layerscape independent of i.MX makes sense, but > I don't know if it can be safely applied in 6.13-rc. > > This proposed change also has the risk of causing regressions. > > What if we revert the patch in Subject for now and then someone (maybe > Esben) tries again for a proper fix targeting 6.14? What about your fix to the in-tree imx defconfigs [1]? Was it dropped/rejected? [1] https://lore.kernel.org/imx/d718ddd2-d473-4455-b21a-15024e46787c@roeck-us.net/T/#mc71dc21d99e0b013c5ce46c0d90940fd8806ae9a /Esben
On Mon, May 6, 2024 at 12:24 PM Esben Haabendal <esben@geanix.com> wrote: > Making pinctrl drivers and subsequently the pinctrl framework > user-controllable, allows building a kernel without this. > While in many (most) cases, this could make the system unbootable, it > does allow building smaller kernels for those situations where picntrl > is not needed. > > One such situation is when building a kernel for NXP LS1021A systems, > which does not have run-time controllable pinctrl, so pinctrl framework > and drivers are 100% dead-weight. > > > Signed-off-by: Esben Haabendal <esben@geanix.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> I guess this needs to be merged through the SoC tree. Yours, Linus Walleij
On Tue, Sep 24, 2024 at 09:45:32AM +0200, Linus Walleij wrote: > On Mon, May 6, 2024 at 12:24 PM Esben Haabendal <esben@geanix.com> wrote: > > > Making pinctrl drivers and subsequently the pinctrl framework > > user-controllable, allows building a kernel without this. > > While in many (most) cases, this could make the system unbootable, it > > does allow building smaller kernels for those situations where picntrl > > is not needed. > > > > One such situation is when building a kernel for NXP LS1021A systems, > > which does not have run-time controllable pinctrl, so pinctrl framework > > and drivers are 100% dead-weight. > > > > > > Signed-off-by: Esben Haabendal <esben@geanix.com> > > Acked-by: Linus Walleij <linus.walleij@linaro.org> > > I guess this needs to be merged through the SoC tree. Hi Linus, Reading your comment[1], I was thinking that you will merge the series through pinctrl tree, no? Shawn [1] https://lore.kernel.org/linux-arm-kernel/CACRpkdYbOTXmap-vJy4JNZSaZnE=yzC35EPD2F=bD8gWdD8-GQ@mail.gmail.com/
Linus Walleij <linus.walleij@linaro.org> writes: > On Mon, May 6, 2024 at 12:24 PM Esben Haabendal <esben@geanix.com> wrote: > >> Making pinctrl drivers and subsequently the pinctrl framework >> user-controllable, allows building a kernel without this. >> While in many (most) cases, this could make the system unbootable, it >> does allow building smaller kernels for those situations where picntrl >> is not needed. >> >> One such situation is when building a kernel for NXP LS1021A systems, >> which does not have run-time controllable pinctrl, so pinctrl framework >> and drivers are 100% dead-weight. >> >> >> Signed-off-by: Esben Haabendal <esben@geanix.com> > > Acked-by: Linus Walleij <linus.walleij@linaro.org> > > I guess this needs to be merged through the SoC tree. Anything more I need to make that happen? /Esben
On Mon, May 06, 2024 at 12:23:53PM +0200, Esben Haabendal wrote: > Making pinctrl drivers and subsequently the pinctrl framework > user-controllable, allows building a kernel without this. > While in many (most) cases, this could make the system unbootable, it > does allow building smaller kernels for those situations where picntrl > is not needed. > > One such situation is when building a kernel for NXP LS1021A systems, > which does not have run-time controllable pinctrl, so pinctrl framework > and drivers are 100% dead-weight. > > > Signed-off-by: Esben Haabendal <esben@geanix.com> Acked-by: Shawn Guo <shawnguo@kernel.org>
Shawn Guo <shawnguo2@yeah.net> writes: > On Mon, May 06, 2024 at 12:23:53PM +0200, Esben Haabendal wrote: >> Making pinctrl drivers and subsequently the pinctrl framework >> user-controllable, allows building a kernel without this. >> While in many (most) cases, this could make the system unbootable, it >> does allow building smaller kernels for those situations where picntrl >> is not needed. >> >> One such situation is when building a kernel for NXP LS1021A systems, >> which does not have run-time controllable pinctrl, so pinctrl framework >> and drivers are 100% dead-weight. >> >> >> Signed-off-by: Esben Haabendal <esben@geanix.com> > > Acked-by: Shawn Guo <shawnguo@kernel.org> Was this only for this patch 1/3, or the whole series? /Esben
© 2016 - 2025 Red Hat, Inc.