On 04/09/2023 13:01, Ian Abbott wrote:
On 04/09/2023 12:23, Niklas Schnelle wrote:
On Mon, 2023-09-04 at 11:10 +0100, Ian Abbott wrote:
On 03/09/2023 16:49, Arnd Bergmann wrote:
On Fri, Sep 1, 2023, at 15:26, Ian Abbott wrote:
Commit b5c75b68b7de ("comedi: add HAS_IOPORT dependencies") changed the "select" directives to "depend on" directives for several config stanzas, but the options they depended on could not be selected, breaking previously selected options.
---8<---
@@ -735,8 +738,8 @@ config COMEDI_ADL_PCI9111
config COMEDI_ADL_PCI9118 tristate "ADLink PCI-9118DG, PCI-9118HG, PCI-9118HR support" + depends on HAS_IOPORT depends on HAS_DMA - depends on COMEDI_8254 help Enable support for ADlink PCI-9118DG, PCI-9118HG, PCI-9118HR cards
I don't see why you'd remove the 'depends on COMEDI_8254' here rather than turning it back into 'select' as it was originally.
Oops! That's an error on my part. Thanks for catching it!
It might be easier to revert the original patch, and then follow up with a fixed version.
Will any random config builds break in 6.5 stable if the original patch is reverted, or is the 'HAS_IOPORT' stuff still in preparation for future use?
The patch that finally compile-time disables I/O port accesses as well as a few others are still not merged. I was away for a few weeks and also still have a few todos. I also and found a few things needed for new changes. So no a revert will not break compiles or anything like that.
Thanks for the confirmation. Will it be safe to assume that anything that selects ISA will also select HAS_IOPORT? That is trivially the case for arch/{alpha,arm,x86}; arch/mips explicitly selects HAS_IOPORT if ISA is selected; arch/powerpc explicitly selects HAS_IOPORT if PCI is selected and it is only possible to configure ISA if PPC_CHRP is configured which selects FORCE_PCI and therefore selects PCI and therefore selects HAS_IOPORT; arch/um does not select HAS_IOPORT and although it has a 'config ISA', nothing appears to select it. None of the remaining arch/* have 'select ISA'.
Another quick question: Will dummy versions of request_region(), request_muxed_region() and release_region() (and the devm variants) exist in the future even if HAS_IOPORT is not selected? If so, I guess any drivers that only use inb()/outb() and friends on successfully requested regions can safely replace inb()/outb() and friends with conditionally compiled wrappers.