Drop rather useless use of ACPI_PTR() and of_match_ptr().
It also removes the necessity to be dependent on ACPI and
of.h inclusion.
Signed-off-by: Andy Shevchenko <[email protected]>
---
drivers/spi/Kconfig | 2 +-
drivers/spi/spi-pxa2xx.c | 9 +++------
2 files changed, 4 insertions(+), 7 deletions(-)
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index bc7021da2fe9..7cf86b034083 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -817,7 +817,7 @@ config SPI_PPC4xx
config SPI_PXA2XX
tristate "PXA2xx SSP SPI master"
- depends on ARCH_PXA || ARCH_MMP || PCI || ACPI || COMPILE_TEST
+ depends on ARCH_PXA || ARCH_MMP || PCI || COMPILE_TEST
select PXA_SSP if ARCH_PXA || ARCH_MMP
help
This enables using a PXA2xx or Sodaville SSP port as a SPI master
diff --git a/drivers/spi/spi-pxa2xx.c b/drivers/spi/spi-pxa2xx.c
index 6c2a14418972..2c39d3ff498e 100644
--- a/drivers/spi/spi-pxa2xx.c
+++ b/drivers/spi/spi-pxa2xx.c
@@ -19,7 +19,6 @@
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/mod_devicetable.h>
-#include <linux/of.h>
#include <linux/platform_device.h>
#include <linux/pm_runtime.h>
#include <linux/property.h>
@@ -1730,7 +1729,6 @@ static const struct dev_pm_ops pxa2xx_spi_pm_ops = {
RUNTIME_PM_OPS(pxa2xx_spi_runtime_suspend, pxa2xx_spi_runtime_resume, NULL)
};
-#ifdef CONFIG_ACPI
static const struct acpi_device_id pxa2xx_spi_acpi_match[] = {
{ "80860F0E", LPSS_BYT_SSP },
{ "8086228E", LPSS_BSW_SSP },
@@ -1741,9 +1739,8 @@ static const struct acpi_device_id pxa2xx_spi_acpi_match[] = {
{}
};
MODULE_DEVICE_TABLE(acpi, pxa2xx_spi_acpi_match);
-#endif
-static const struct of_device_id pxa2xx_spi_of_match[] __maybe_unused = {
+static const struct of_device_id pxa2xx_spi_of_match[] = {
{ .compatible = "marvell,mmp2-ssp", .data = (void *)MMP2_SSP },
{}
};
@@ -1753,8 +1750,8 @@ static struct platform_driver driver = {
.driver = {
.name = "pxa2xx-spi",
.pm = pm_ptr(&pxa2xx_spi_pm_ops),
- .acpi_match_table = ACPI_PTR(pxa2xx_spi_acpi_match),
- .of_match_table = of_match_ptr(pxa2xx_spi_of_match),
+ .acpi_match_table = pxa2xx_spi_acpi_match,
+ .of_match_table = pxa2xx_spi_of_match,
},
.probe = pxa2xx_spi_probe,
.remove_new = pxa2xx_spi_remove,
--
2.43.0.rc1.1.gbec44491f096
On Tue, Mar 26, 2024 at 08:07:51PM +0200, Andy Shevchenko wrote:
> Drop rather useless use of ACPI_PTR() and of_match_ptr().
> It also removes the necessity to be dependent on ACPI and
> of.h inclusion.
I think the ACPI dependency there is as much about hiding the device on
irrelevant platforms as anything else, might be better replaced with an
x86 dependency though.
On Tue, Mar 26, 2024 at 08:22:59PM +0200, Andy Shevchenko wrote:
> On Tue, Mar 26, 2024 at 06:16:28PM +0000, Mark Brown wrote:
> > On Tue, Mar 26, 2024 at 08:07:51PM +0200, Andy Shevchenko wrote:
> > > Drop rather useless use of ACPI_PTR() and of_match_ptr().
> > > It also removes the necessity to be dependent on ACPI and
> > > of.h inclusion.
> > I think the ACPI dependency there is as much about hiding the device on
> > irrelevant platforms as anything else, might be better replaced with an
> > x86 dependency though.
> The whole idea behind ACPI_PTR() (which seems following the of_match_ptr()
> implementation) looks premature. Now we have a lot of patches from DT people to
> remove of_match_ptr(), i.o.w. make the ID visible even on non-OF platforms.
> Having the list of supported IDs is not bad thing anyway as it might help
> to google for a device elsewhere, for example.
That's nice but I'm not sure what that has to do with the dependency on
ACPI?
On Tue, Mar 26, 2024 at 06:25:16PM +0000, Mark Brown wrote:
> On Tue, Mar 26, 2024 at 08:22:59PM +0200, Andy Shevchenko wrote:
> > On Tue, Mar 26, 2024 at 06:16:28PM +0000, Mark Brown wrote:
> > > On Tue, Mar 26, 2024 at 08:07:51PM +0200, Andy Shevchenko wrote:
>
> > > > Drop rather useless use of ACPI_PTR() and of_match_ptr().
> > > > It also removes the necessity to be dependent on ACPI and
> > > > of.h inclusion.
>
> > > I think the ACPI dependency there is as much about hiding the device on
> > > irrelevant platforms as anything else, might be better replaced with an
> > > x86 dependency though.
>
> > The whole idea behind ACPI_PTR() (which seems following the of_match_ptr()
> > implementation) looks premature. Now we have a lot of patches from DT people to
> > remove of_match_ptr(), i.o.w. make the ID visible even on non-OF platforms.
>
> > Having the list of supported IDs is not bad thing anyway as it might help
> > to google for a device elsewhere, for example.
>
> That's nice but I'm not sure what that has to do with the dependency on
> ACPI?
ACPI_PTR() makes ID no-op only if ACPI is defined. That also satisfies
the ugly ifdeffery that is removed by this patch as well. If there is
no dependency we will have compiler warning for defined but not used
variable.
--
With Best Regards,
Andy Shevchenko
On Tue, Mar 26, 2024 at 06:49:58PM +0000, Mark Brown wrote:
> On Tue, Mar 26, 2024 at 08:44:11PM +0200, Andy Shevchenko wrote:
> > On Tue, Mar 26, 2024 at 06:25:16PM +0000, Mark Brown wrote:
> > > On Tue, Mar 26, 2024 at 08:22:59PM +0200, Andy Shevchenko wrote:
> > > > On Tue, Mar 26, 2024 at 06:16:28PM +0000, Mark Brown wrote:
>
> > > > > I think the ACPI dependency there is as much about hiding the device on
> > > > > irrelevant platforms as anything else, might be better replaced with an
> > > > > x86 dependency though.
..
> > > That's nice but I'm not sure what that has to do with the dependency on
> > > ACPI?
>
> > ACPI_PTR() makes ID no-op only if ACPI is defined. That also satisfies
> > the ugly ifdeffery that is removed by this patch as well. If there is
> > no dependency we will have compiler warning for defined but not used
> > variable.
>
> Again I don't think that's the main purpose of the dependency here.
Oh, oh, my bad I missed acpi_dev_uid_to_integer() call.
Okay, with that in mind it's functional dependency for the ACPI-based
platforms. Do you want to keep it untouched?
--
With Best Regards,
Andy Shevchenko
On Tue, Mar 26, 2024 at 08:44:11PM +0200, Andy Shevchenko wrote:
> On Tue, Mar 26, 2024 at 06:25:16PM +0000, Mark Brown wrote:
> > On Tue, Mar 26, 2024 at 08:22:59PM +0200, Andy Shevchenko wrote:
> > > On Tue, Mar 26, 2024 at 06:16:28PM +0000, Mark Brown wrote:
> > > > I think the ACPI dependency there is as much about hiding the device on
> > > > irrelevant platforms as anything else, might be better replaced with an
> > > > x86 dependency though.
..
> > That's nice but I'm not sure what that has to do with the dependency on
> > ACPI?
> ACPI_PTR() makes ID no-op only if ACPI is defined. That also satisfies
> the ugly ifdeffery that is removed by this patch as well. If there is
> no dependency we will have compiler warning for defined but not used
> variable.
Again I don't think that's the main purpose of the dependency here.
On Tue, Mar 26, 2024 at 08:52:53PM +0200, Andy Shevchenko wrote:
> On Tue, Mar 26, 2024 at 06:49:58PM +0000, Mark Brown wrote:
> > > > > > I think the ACPI dependency there is as much about hiding the device on
> > > > > > irrelevant platforms as anything else, might be better replaced with an
> > > > > > x86 dependency though.
> Oh, oh, my bad I missed acpi_dev_uid_to_integer() call.
> Okay, with that in mind it's functional dependency for the ACPI-based
> platforms. Do you want to keep it untouched?
That's not actually what I was thinking of (please read what I wrote
above, like I say I was thining about hiding things) but surely if that
was a reason to keep the dependency it'd need to be an actual ACPI
dependency rather than an ||?
On Tue, Mar 26, 2024 at 09:20:05PM +0200, Andy Shevchenko wrote:
> On Tue, Mar 26, 2024 at 07:10:09PM +0000, Mark Brown wrote:
> > On Tue, Mar 26, 2024 at 08:52:53PM +0200, Andy Shevchenko wrote:
> > > On Tue, Mar 26, 2024 at 06:49:58PM +0000, Mark Brown wrote:
> >
> > > > > > > > I think the ACPI dependency there is as much about hiding the device on
> > > > > > > > irrelevant platforms as anything else, might be better replaced with an
> > > > > > > > x86 dependency though.
> >
> > > Oh, oh, my bad I missed acpi_dev_uid_to_integer() call.
> > > Okay, with that in mind it's functional dependency for the ACPI-based
> > > platforms. Do you want to keep it untouched?
> >
> > That's not actually what I was thinking of (please read what I wrote
> > above, like I say I was thining about hiding things) but surely if that
> > was a reason to keep the dependency it'd need to be an actual ACPI
> > dependency rather than an ||?
>
> For my knowledge there is none of the ACPI-based platform where CONFIG_ACPI
> needs to be 'n' while having the real device (as per ACPI ID table) to be on.
to be on --> in a sense of "to be present".
> That's why I answered purely from the compilation point of view.
>
> Personally I see that dependency more confusing than hinting about anything.
--
With Best Regards,
Andy Shevchenko
On Tue, Mar 26, 2024 at 07:32:47PM +0000, Mark Brown wrote:
> On Tue, Mar 26, 2024 at 09:20:05PM +0200, Andy Shevchenko wrote:
>
> > For my knowledge there is none of the ACPI-based platform where CONFIG_ACPI
> > needs to be 'n' while having the real device (as per ACPI ID table) to be on.
> > That's why I answered purely from the compilation point of view.
>
> I don't understand the relevance of that, and frankly can't make much
> sense of it.
It's relevant to the ID table presence at run-time. But it seems I wrongly got
your point (see below).
> > Personally I see that dependency more confusing than hinting about anything.
>
> When you don't have a dependency in Kconfig then people get offered the
> device even if it is impossible for it to be useful on their platform.
There is currently a dependency among others PCI || ACPI || COMPILE_TEST
From the point of view of the real platforms it means that if there is
a PCI compiled we support PCI devices that use this "platform" driver.
Similar with ACPI.
What you want is to hide this in the menuconfig for the irrelevant platforms
which have PCI _or_ ACPI enabled, correct?
But if we add x86 dependency to that, it will drop the support for non-x86
ACPI-based platforms with this device. I have no clue what are those.
Yes, we may try to have ((PCI || ACPI) && X86) at the end, but I believe
this will have a good regression effect.
> The purpose of any || COMPILE_TEST dependency is to improve the
> usability of Kconfig.
Right, when I see FOO || COMPILE_TEST I interpret FOO as *functional*
dependency, meaning that without FOO the certain driver makes no sense
from functional point of view.
--
With Best Regards,
Andy Shevchenko
On Tue, Mar 26, 2024 at 09:20:05PM +0200, Andy Shevchenko wrote:
> For my knowledge there is none of the ACPI-based platform where CONFIG_ACPI
> needs to be 'n' while having the real device (as per ACPI ID table) to be on.
> That's why I answered purely from the compilation point of view.
I don't understand the relevance of that, and frankly can't make much
sense of it.
> Personally I see that dependency more confusing than hinting about anything.
When you don't have a dependency in Kconfig then people get offered the
device even if it is impossible for it to be useful on their platform.
The purpose of any || COMPILE_TEST dependency is to improve the
usability of Kconfig.
On Tue, Mar 26, 2024 at 10:04:43PM +0200, Andy Shevchenko wrote:
> There is currently a dependency among others PCI || ACPI || COMPILE_TEST
> From the point of view of the real platforms it means that if there is
> a PCI compiled we support PCI devices that use this "platform" driver.
> Similar with ACPI.
> What you want is to hide this in the menuconfig for the irrelevant platforms
> which have PCI _or_ ACPI enabled, correct?
> But if we add x86 dependency to that, it will drop the support for non-x86
> ACPI-based platforms with this device. I have no clue what are those.
Given the history I would be surprised to learn of any platforms that
have used this other than PXA, MMP or x86. It's possible Intel shipped
the IP directly exposed on a PCI card of some kind but it'd be pretty
surprising given the way it tends to get used and the idiom for PCI
cards, Marvell having done that would be even more surprising. The x86
uses I'm aware of are integrated into the chipset rather than something
meaingfully separate to the SoC.
On Tue, Mar 26, 2024 at 08:12:09PM +0000, Mark Brown wrote:
> On Tue, Mar 26, 2024 at 10:04:43PM +0200, Andy Shevchenko wrote:
>
> > There is currently a dependency among others PCI || ACPI || COMPILE_TEST
>
> > From the point of view of the real platforms it means that if there is
> > a PCI compiled we support PCI devices that use this "platform" driver.
> > Similar with ACPI.
>
> > What you want is to hide this in the menuconfig for the irrelevant platforms
> > which have PCI _or_ ACPI enabled, correct?
>
> > But if we add x86 dependency to that, it will drop the support for non-x86
> > ACPI-based platforms with this device. I have no clue what are those.
>
> Given the history I would be surprised to learn of any platforms that
> have used this other than PXA, MMP or x86. It's possible Intel shipped
> the IP directly exposed on a PCI card of some kind but it'd be pretty
> surprising given the way it tends to get used and the idiom for PCI
> cards, Marvell having done that would be even more surprising. The x86
> uses I'm aware of are integrated into the chipset rather than something
> meaingfully separate to the SoC.
Okay, do you want to have an experimental (that we might revert in the future
if any regression being reported) patch to narrow this dependencies as I
described above?
I can prepend the v2 with a such.
--
With Best Regards,
Andy Shevchenko
On Tue, Mar 26, 2024 at 06:16:28PM +0000, Mark Brown wrote:
> On Tue, Mar 26, 2024 at 08:07:51PM +0200, Andy Shevchenko wrote:
> > Drop rather useless use of ACPI_PTR() and of_match_ptr().
> > It also removes the necessity to be dependent on ACPI and
> > of.h inclusion.
>
> I think the ACPI dependency there is as much about hiding the device on
> irrelevant platforms as anything else, might be better replaced with an
> x86 dependency though.
The whole idea behind ACPI_PTR() (which seems following the of_match_ptr()
implementation) looks premature. Now we have a lot of patches from DT people to
remove of_match_ptr(), i.o.w. make the ID visible even on non-OF platforms.
Having the list of supported IDs is not bad thing anyway as it might help
to google for a device elsewhere, for example.
--
With Best Regards,
Andy Shevchenko
On Tue, Mar 26, 2024 at 07:10:09PM +0000, Mark Brown wrote:
> On Tue, Mar 26, 2024 at 08:52:53PM +0200, Andy Shevchenko wrote:
> > On Tue, Mar 26, 2024 at 06:49:58PM +0000, Mark Brown wrote:
>
> > > > > > > I think the ACPI dependency there is as much about hiding the device on
> > > > > > > irrelevant platforms as anything else, might be better replaced with an
> > > > > > > x86 dependency though.
>
> > Oh, oh, my bad I missed acpi_dev_uid_to_integer() call.
> > Okay, with that in mind it's functional dependency for the ACPI-based
> > platforms. Do you want to keep it untouched?
>
> That's not actually what I was thinking of (please read what I wrote
> above, like I say I was thining about hiding things) but surely if that
> was a reason to keep the dependency it'd need to be an actual ACPI
> dependency rather than an ||?
For my knowledge there is none of the ACPI-based platform where CONFIG_ACPI
needs to be 'n' while having the real device (as per ACPI ID table) to be on.
That's why I answered purely from the compilation point of view.
Personally I see that dependency more confusing than hinting about anything.
--
With Best Regards,
Andy Shevchenko