pinctrl: intel: Turn Baytrail support to tristate
Subsystems (3)
PATCH RESEND 1/1 pinctrl: intel: Turn Baytrail support to tristate
The pinctrl-baytrail driver builds just fine as a module so give users this option.
---
This was discussed almost one year ago, with no clear conclusion, but also no evidence that the driver can't be built as a module. Is there any way to push this forward?
drivers/pinctrl/intel/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/pinctrl/intel/Kconfig +1 -1
@@ -3,7 +3,7 @@ # config PINCTRL_BAYTRAIL - bool "Intel Baytrail GPIO pin control" + tristate "Intel Baytrail GPIO pin control" depends on GPIOLIB && ACPI select GPIOLIB_IRQCHIP select PINMUX
Signature · 2 lines
Jean Delvare SUSE L3 Support
Quoted 7 lines · Jean Delvare
The pinctrl-baytrail driver builds just fine as a module so give users this option.
Signed-off-by Jean Delvare <[email protected]>Cc Mika Westerberg <[email protected]>Cc Heikki Krogerus <[email protected]>Cc Linus Walleij <[email protected]>
Looks okay to me.
FWIW:
Quoted 24 lines
---
This was discussed almost one year ago, with no clear conclusion, but also no evidence that the driver can't be built as a module. Is there any way to push this forward?drivers/pinctrl/intel/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)drivers/pinctrl/intel/Kconfig 2016-07-12 14:35:44.735904433 +0200 renamed from drivers/pinctrl/intel/Kconfig 2016-07-12 14:35:36.024835842 +0200 +1
-2@@ -3,7 +3,7 @@ # config PINCTRL_BAYTRAIL - bool "Intel Baytrail GPIO pin control" + tristate "Intel Baytrail GPIO pin control" depends on GPIOLIB && ACPI select GPIOLIB_IRQCHIP select PINMUX --Jean Delvare
SUSE L3 Support
Signature · 2 lines
With Best Regards, Andy Shevchenko
Quoted 5 lines · Jean Delvare
The pinctrl-baytrail driver builds just fine as a module so give users this option.
Signed-off-by Jean Delvare <[email protected]>Cc Mika Westerberg <[email protected]>
Assuming you have checked that nothing breaks in Baytrail, I'm fine with this change,
Hi Mika and all,
Quoted 9 lines · Mika Westerberg
Quoted 5 lines · Jean Delvare
The pinctrl-baytrail driver builds just fine as a module so give users this option.
Signed-off-by Jean Delvare <[email protected]>Cc Mika Westerberg <[email protected]>Assuming you have checked that nothing breaks in Baytrail, I'm fine with this change,
I have not, as I do not have access to any Baytrail hardware. This is the very reason why I'd like this code to be buildable as a module: I'm not happy with a useless 50 kB driver being loaded on all my systems. I was hopping someone at Intel would have access to the hardware to perform the test.
Meanwhile I have found that my patch is not good, because since I wrote it, Paul Gortmaker remove the module glue code from the driver itself:
commit 360943a8d26265825025b88da32961bd9ad4f7c6
Author: Paul Gortmaker <[email protected]> Date: Mon Jun 6 22:43:01 2016 -0400
pinctrl: baytrail: make it explicitly non-modular
This would have to be reverted first. Paul, do I understand it correctly that the commit above was generated automatically and was not specific to the pinctrl-baytrail driver?
Signature · 2 lines
Jean Delvare SUSE L3 Support
Mika Westerberg
maintainerQuoted 10 lines · Jean Delvare
Hi Mika and all,
Quoted 7 lines · Mika Westerberg
Quoted 5 lines · Jean Delvare
The pinctrl-baytrail driver builds just fine as a module so give users this option.
Signed-off-by Jean Delvare <[email protected]>Cc Mika Westerberg <[email protected]>
Quoted 8 lines
Quoted 2 lines
Assuming you have checked that nothing breaks in Baytrail, I'm fine with this change,
I have not, as I do not have access to any Baytrail hardware. This is the very reason why I'd like this code to be buildable as a module: I'm not happy with a useless 50 kB driver being loaded on all my systems. I was hopping someone at Intel would have access to the hardware to perform the test.
We do not have all the possible hardware here. I have one Minnowboard MAX which I can test this on (like I commented in the other email) but it does not have any ACPI GPIO OpRegion stuff that is present in many Baytrail based laptops out there.
Quoted 11 lines · Mika Westerberg
Quoted 5 lines · Jean Delvare
I have not, as I do not have access to any Baytrail hardware. This is the very reason why I'd like this code to be buildable as a module: I'm not happy with a useless 50 kB driver being loaded on all my systems. I was hopping someone at Intel would have access to the hardware to perform the test.
We do not have all the possible hardware here. I have one Minnowboard MAX which I can test this on (like I commented in the other email) but it does not have any ACPI GPIO OpRegion stuff that is present in many Baytrail based laptops out there.
Takashi, do you have any such laptop or know anyone at SUSE who does and could test?
Signature · 2 lines
Jean Delvare SUSE L3 Support
Quoted 6 lines · Jean Delvare
The pinctrl-baytrail driver builds just fine as a module so give users this option.
Signed-off-by Jean Delvare <[email protected]>Cc Mika Westerberg <[email protected]>Cc Heikki Krogerus <[email protected]>
OK by me. FWIW.
Thanks,
Signature · 1 line
heikki
Quoted 11 lines · Jean Delvare
The pinctrl-baytrail driver builds just fine as a module so give users this option.
Signed-off-by Jean Delvare <[email protected]>Cc Mika Westerberg <[email protected]>Cc Heikki Krogerus <[email protected]>Cc Linus Walleij <[email protected]>---
This was discussed almost one year ago, with no clear conclusion, but also no evidence that the driver can't be built as a module. Is there any way to push this forward?
I see ACKs for this patch, but in my git I also have:
commit 360943a8d26265825025b88da32961bd9ad4f7c6
pinctrl: baytrail: make it explicitly non-modular
Acked by Mika.
So which one is it going to be?
If this should be applied, the previous patch from Paul Gortmaker should be reverted first. Especially the runtime PM parts seem important to get back.
Then I want a patch reverting that and adding this tristate in one.
Yours,
Linus Walleij
Mika Westerberg
maintainerQuoted 14 lines · Linus Walleij
Quoted 11 lines · Jean Delvare
The pinctrl-baytrail driver builds just fine as a module so give users this option.
Signed-off-by Jean Delvare <[email protected]>Cc Mika Westerberg <[email protected]>Cc Heikki Krogerus <[email protected]>Cc Linus Walleij <[email protected]>---
This was discussed almost one year ago, with no clear conclusion, but also no evidence that the driver can't be built as a module. Is there any way to push this forward?
Quoted 6 lines
I see ACKs for this patch, but in my git I also have:
commit
360943a8d26265825025b88da32961bd9ad4f7c6
pinctrl: baytrail: make it explicitly non-modularAcked by Mika.
Heh, yeah we even removed possibility to unbind the driver with that commit. Totally forgot that one.
Quoted 1 line
So which one is it going to be?
Good question. I'm fine with both but I would really like to get some confirmation that turning the driver to module actually does not break anything.
I have one Minnowboard MAX here but it does not do any ACPI magic for GPIOs so testing on that one might not catch all possible issues.
Quoted 3 lines
If this should be applied, the previous patch from Paul Gortmaker should be reverted first. Especially the runtime PM parts seem important to get back.
Runtime PM actually does not do anything - there is no way to power down the GPIO controller in Baytrail.
Quoted 1 line
Then I want a patch reverting that and adding this tristate in one.
I agree + really good explanation in the changelog why this was done.
Quoted 23 lines · Mika Westerberg
Quoted 14 lines · Linus Walleij
Quoted 11 lines · Jean Delvare
The pinctrl-baytrail driver builds just fine as a module so give users this option.
Signed-off-by Jean Delvare <[email protected]>Cc Mika Westerberg <[email protected]>Cc Heikki Krogerus <[email protected]>Cc Linus Walleij <[email protected]>---
This was discussed almost one year ago, with no clear conclusion, but also no evidence that the driver can't be built as a module. Is there any way to push this forward?Quoted 6 lines
I see ACKs for this patch, but in my git I also have:
commit
360943a8d26265825025b88da32961bd9ad4f7c6
pinctrl: baytrail: make it explicitly non-modularAcked by Mika.
Quoted 8 lines
Heh, yeah we even removed possibility to unbind the driver with that commit. Totally forgot that one.
Quoted 1 line
So which one is it going to be?
Good question. I'm fine with both but I would really like to get some confirmation that turning the driver to module actually does not break anything.
I guess it would break things on some machines if the module loading order isn't setup properly. For example, it's known that pinctrl-cherrytrail breaks MMC or others if it's loaded too lately. On distros, we often work around it by a specific module loading order in initrd.
But this doesn't mean that the modularization itself is wrong. It's merely a setup issue.
thanks,
Takashi
Mika Westerberg
maintainerQuoted 3 lines · Takashi Iwai
I guess it would break things on some machines if the module loading order isn't setup properly. For example, it's known that pinctrl-cherrytrail breaks MMC or others if it's loaded too lately.
Yes, if you have rootfs on eMMC and it requires a GPIO then of course you need to make sure your initrd includes the necessary drivers. Same goes with other media that can be used as rootfs.