From: Andy Shevchenko <andriy.shevchenko@linux.intel.com> To: Mark Brown <broonie@kernel.org> Cc: linux-spi@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Daniel Mack <daniel@zonque.org>, Haojian Zhuang <haojian.zhuang@gmail.com>, Robert Jarzmik <robert.jarzmik@free.fr>, Russell King <linux@armlinux.org.uk> Subject: Re: [PATCH v1 01/10] spi: pxa2xx: Drop ACPI_PTR() and of_match_ptr() Date: Tue, 26 Mar 2024 22:04:43 +0200 [thread overview] Message-ID: <ZgMqW6TSHYJ2NOPq@smile.fi.intel.com> (raw) In-Reply-To: <a30da48d-f801-4d0a-9db7-9c9bb159ca6b@sirena.org.uk> 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
WARNING: multiple messages have this Message-ID (diff)
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com> To: Mark Brown <broonie@kernel.org> Cc: linux-spi@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Daniel Mack <daniel@zonque.org>, Haojian Zhuang <haojian.zhuang@gmail.com>, Robert Jarzmik <robert.jarzmik@free.fr>, Russell King <linux@armlinux.org.uk> Subject: Re: [PATCH v1 01/10] spi: pxa2xx: Drop ACPI_PTR() and of_match_ptr() Date: Tue, 26 Mar 2024 22:04:43 +0200 [thread overview] Message-ID: <ZgMqW6TSHYJ2NOPq@smile.fi.intel.com> (raw) In-Reply-To: <a30da48d-f801-4d0a-9db7-9c9bb159ca6b@sirena.org.uk> 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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2024-03-26 20:04 UTC|newest] Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top 2024-03-26 18:07 [PATCH v1 00/10] spi: pxa2xx: Drop linux/spi/pxa2xx_spi.h Andy Shevchenko 2024-03-26 18:07 ` Andy Shevchenko 2024-03-26 18:07 ` [PATCH v1 01/10] spi: pxa2xx: Drop ACPI_PTR() and of_match_ptr() Andy Shevchenko 2024-03-26 18:07 ` Andy Shevchenko 2024-03-26 18:16 ` Mark Brown 2024-03-26 18:16 ` Mark Brown 2024-03-26 18:22 ` Andy Shevchenko 2024-03-26 18:22 ` Andy Shevchenko 2024-03-26 18:25 ` Mark Brown 2024-03-26 18:25 ` Mark Brown 2024-03-26 18:44 ` Andy Shevchenko 2024-03-26 18:44 ` Andy Shevchenko 2024-03-26 18:49 ` Mark Brown 2024-03-26 18:49 ` Mark Brown 2024-03-26 18:52 ` Andy Shevchenko 2024-03-26 18:52 ` Andy Shevchenko 2024-03-26 19:10 ` Mark Brown 2024-03-26 19:10 ` Mark Brown 2024-03-26 19:20 ` Andy Shevchenko 2024-03-26 19:20 ` Andy Shevchenko 2024-03-26 19:21 ` Andy Shevchenko 2024-03-26 19:21 ` Andy Shevchenko 2024-03-26 19:32 ` Mark Brown 2024-03-26 19:32 ` Mark Brown 2024-03-26 20:04 ` Andy Shevchenko [this message] 2024-03-26 20:04 ` Andy Shevchenko 2024-03-26 20:12 ` Mark Brown 2024-03-26 20:12 ` Mark Brown 2024-03-26 20:17 ` Andy Shevchenko 2024-03-26 20:17 ` Andy Shevchenko 2024-03-26 18:07 ` [PATCH v1 02/10] spi: pxa2xx: Keep PXA*_SSP types together Andy Shevchenko 2024-03-26 18:07 ` Andy Shevchenko 2024-03-26 18:07 ` [PATCH v1 03/10] spi: pxa2xx: Switch to use dev_err_probe() Andy Shevchenko 2024-03-26 18:07 ` Andy Shevchenko 2024-03-26 18:07 ` [PATCH v1 04/10] spi: pxa2xx: Extract pxa2xx_spi_init_ssp() helper Andy Shevchenko 2024-03-26 18:07 ` Andy Shevchenko 2024-03-26 18:07 ` [PATCH v1 05/10] spi: pxa2xx: Skip SSP initialization if it's done elsewhere Andy Shevchenko 2024-03-26 18:07 ` Andy Shevchenko 2024-03-26 18:07 ` [PATCH v1 06/10] spi: pxa2xx: Allow number of chip select pins to be read from property Andy Shevchenko 2024-03-26 18:07 ` Andy Shevchenko 2024-03-26 18:07 ` [PATCH v1 07/10] spi: pxa2xx: Provide num-cs for Sharp PDAs via device properties Andy Shevchenko 2024-03-26 18:07 ` Andy Shevchenko 2024-03-26 18:21 ` Mark Brown 2024-03-26 18:21 ` Mark Brown 2024-03-26 18:50 ` Andy Shevchenko 2024-03-26 18:50 ` Andy Shevchenko 2024-03-26 20:02 ` Mark Brown 2024-03-26 20:02 ` Mark Brown 2024-03-26 20:12 ` Andy Shevchenko 2024-03-26 20:12 ` Andy Shevchenko 2024-03-26 20:26 ` Mark Brown 2024-03-26 20:26 ` Mark Brown 2024-03-26 21:20 ` Andy Shevchenko 2024-03-26 21:20 ` Andy Shevchenko 2024-03-26 18:07 ` [PATCH v1 08/10] spi: pxa2xx: Move contents of linux/spi/pxa2xx_spi.h to a local one Andy Shevchenko 2024-03-26 18:07 ` Andy Shevchenko 2024-03-26 18:07 ` [PATCH v1 09/10] spi: pxa2xx: Remove outdated documentation Andy Shevchenko 2024-03-26 18:07 ` Andy Shevchenko 2024-03-26 18:08 ` [PATCH v1 10/10] spi: pxa2xx: Don't use "proxy" headers Andy Shevchenko 2024-03-26 18:08 ` Andy Shevchenko 2024-03-26 20:55 ` (subset) [PATCH v1 00/10] spi: pxa2xx: Drop linux/spi/pxa2xx_spi.h Mark Brown 2024-03-26 20:55 ` Mark Brown
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=ZgMqW6TSHYJ2NOPq@smile.fi.intel.com \ --to=andriy.shevchenko@linux.intel.com \ --cc=broonie@kernel.org \ --cc=daniel@zonque.org \ --cc=haojian.zhuang@gmail.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-spi@vger.kernel.org \ --cc=linux@armlinux.org.uk \ --cc=robert.jarzmik@free.fr \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.