Allow ISA-style drivers on modern systems

Hi William,

Just a small question ...

Quoted 7 lines · On Mon, 23 May 2016 17:20:01 -0400 William Breathitt Gray…

arch/x86/Kconfig +0 -0

index 0a7b885..6601912 100644
@@ -2439,6 +2439,16 @@ config PCI_CNB20LE_QUIRK
 

arch/x86/Kconfig config PCI_CNB20LE_QUIRK · line 2443

Quoted 4 lines

arch/x86/Kconfig +2 -0

 source "drivers/pci/Kconfig"
 
+config ISA_BUS
+	bool "ISA-style bus support on modern systems" if (X86 && EXPERT)

                                                          ^^^

Is CONFIG_X86 not always true when processing this file?

Signature · 2 lines

Cheers,
Stephen Rothwell

With the introduction of the ISA_BUS_API Kconfig option, ISA-style drivers may be built for X86_64 architectures. This patch changes the ISA Kconfig option dependency of the PC/104 drivers to ISA_BUS_API, thus allowing them to build for X86_64 as they are expected to.

Cc Guenter Roeck <[email protected]>

Cc Linus Walleij <[email protected]>

Signed-off-by William Breathitt Gray <[email protected]>

---
 drivers/gpio/Kconfig | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

drivers/gpio/Kconfig +0 -0

index 48da857..dc6da77 100644

Hi!

Quoted 18 lines

With the introduction of the ISA_BUS_API Kconfig option, ISA-style drivers may be built for X86_64 architectures. This patch changes the ISA Kconfig option dependency of the PC/104 drivers to ISA_BUS_API, thus allowing them to build for X86_64 as they are expected to.

Cc Guenter Roeck <[email protected]>

Cc Linus Walleij <[email protected]>

Signed-off-by William Breathitt Gray <[email protected]>

---
 drivers/gpio/Kconfig | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

drivers/gpio/Kconfig +0 -0

index 48da857..dc6da77 100644
@@ -530,7 +530,7 @@ menu "Port-mapped I/O GPIO drivers"
 

drivers/gpio/Kconfig menu "Port-mapped I/O GPIO drivers"

Quoted 7 lines

drivers/gpio/Kconfig +1 -1

 config GPIO_104_DIO_48E
 	tristate "ACCES 104-DIO-48E GPIO support"
-	depends on ISA
+	depends on ISA_BUS_API
 	select GPIOLIB_IRQCHIP
 	help
 	  Enables GPIO support for the ACCES 104-DIO-48E series

Should we do "depends on PC104" here, because that is what it really means, and have PC104 enabled when ISA_BUS_API is enabled or something like that?

Quoted 20 lines · Pavel Machek

Hi!

Quoted 18 lines

With the introduction of the ISA_BUS_API Kconfig option, ISA-style drivers may be built for X86_64 architectures. This patch changes the ISA Kconfig option dependency of the PC/104 drivers to ISA_BUS_API, thus allowing them to build for X86_64 as they are expected to.

Cc Guenter Roeck <[email protected]>

Cc Linus Walleij <[email protected]>

Signed-off-by William Breathitt Gray <[email protected]>

---
 drivers/gpio/Kconfig | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

drivers/gpio/Kconfig +0 -0

index 48da857..dc6da77 100644
@@ -530,7 +530,7 @@ menu "Port-mapped I/O GPIO drivers"
 

Quoted 11 lines

drivers/gpio/Kconfig menu "Port-mapped I/O GPIO drivers"

Quoted 7 lines

drivers/gpio/Kconfig +1 -1

 config GPIO_104_DIO_48E
 	tristate "ACCES 104-DIO-48E GPIO support"
-	depends on ISA
+	depends on ISA_BUS_API
 	select GPIOLIB_IRQCHIP
 	help
 	  Enables GPIO support for the ACCES 104-DIO-48E series

Should we do "depends on PC104" here, because that is what it really means, and have PC104 enabled when ISA_BUS_API is enabled or something like that?

Since the functionality remains the same, I'm a bit indifferent to that change; as long as the driver builds for systems in which it's intended to be used, I'm satisfied.

Differentiating between PC/104 and ISA may be a pointless endeavor though since both buses appear the same to software. But if it is better to differentiate between devices as such, then I see little harm in adding a PC104 Kconfig option which follows the ISA_BUS_API Kconfig option.

Quoted 9 lines · William Breathitt Gray

Quoted 3 lines · Pavel Machek

Should we do "depends on PC104" here, because that is what it really means, and have PC104 enabled when ISA_BUS_API is enabled or something like that?

Since the functionality remains the same, I'm a bit indifferent to that change; as long as the driver builds for systems in which it's intended to be used, I'm satisfied.

Quoted 5 lines

Differentiating between PC/104 and ISA may be a pointless endeavor though since both buses appear the same to software. But if it is better to differentiate between devices as such, then I see little harm in adding a PC104 Kconfig option which follows the ISA_BUS_API Kconfig option.

Well, they are same to the software, but not at the hardware. If I have a development board that has PC104 (but not isa), I'd like to see prompts for PC104 extensions, not for isa. If PC105 comes out, still ISA compatible, I will want to see prompts for PC104 boards or PC105 boards, but not neccessarily both...

Quoted 16 lines · Pavel Machek

Quoted 9 lines · William Breathitt Gray

Quoted 3 lines · Pavel Machek

Should we do "depends on PC104" here, because that is what it really means, and have PC104 enabled when ISA_BUS_API is enabled or something like that?

Since the functionality remains the same, I'm a bit indifferent to that change; as long as the driver builds for systems in which it's intended to be used, I'm satisfied.

Quoted 5 lines

Differentiating between PC/104 and ISA may be a pointless endeavor though since both buses appear the same to software. But if it is better to differentiate between devices as such, then I see little harm in adding a PC104 Kconfig option which follows the ISA_BUS_API Kconfig option.

Quoted 5 lines

Well, they are same to the software, but not at the hardware. If I have a development board that has PC104 (but not isa), I'd like to see prompts for PC104 extensions, not for isa. If PC105 comes out, still ISA compatible, I will want to see prompts for PC104 boards or PC105 boards, but not neccessarily both...

I think I see the merit of a prompt for PC104 devices. I've encountered a use case recently which I'm curious about in this scenario. Given the compatibility with ISA, manufacturers may occasionally develop variants of existing ISA devices by duplicating the firmware on a PC/104 form factor.

I'm working on an IIO DAC driver for the Measurement Computing CIO-DAC family (CIO-DAC08, CIO-DAC16, and PC104-DAC06); while not a GPIO driver, I believe it can serve as a decent example. Interestingly, while the CIO-DAC08 and CIO-DAC16 are true ISA devices, the PC104-DAC06 is a PC/104 variant compatible with the others in the family. The IIO DAC driver works just as well with the PC104-DAC06, as it does with the true ISA devices in the family.

What would the Kconfig depends line look in this scenario? I imagine simply "depends on PC104" would be inappropriate since there are a number of true ISA devices supported by the driver, but "depends on ISA_BUS_API || PC104" seems somewhat redundant when the PC104 Kconfig option implies ISA_BUS_API. This situation isn't that much of an issue overall, but I anticipate encountering it occassionally as I develop future PC/104 drivers.

Quoted 14 lines · William Breathitt Gray

I think I see the merit of a prompt for PC104 devices. I've encountered a use case recently which I'm curious about in this scenario. Given the compatibility with ISA, manufacturers may occasionally develop variants of existing ISA devices by duplicating the firmware on a PC/104 form factor.

I'm working on an IIO DAC driver for the Measurement Computing CIO-DAC family (CIO-DAC08, CIO-DAC16, and PC104-DAC06); while not a GPIO driver, I believe it can serve as a decent example. Interestingly, while the CIO-DAC08 and CIO-DAC16 are true ISA devices, the PC104-DAC06 is a PC/104 variant compatible with the others in the family. The IIO DAC driver works just as well with the PC104-DAC06, as it does with the true ISA devices in the family.

Quoted 7 lines

What would the Kconfig depends line look in this scenario? I imagine simply "depends on PC104" would be inappropriate since there are a number of true ISA devices supported by the driver, but "depends on ISA_BUS_API || PC104" seems somewhat redundant when the PC104 Kconfig option implies ISA_BUS_API. This situation isn't that much of an issue overall, but I anticipate encountering it occassionally as I develop future PC/104 drivers.

ISA_BUS_API || PC104 sounds fine to me. But it seems probable to me that such devices will be connectable by PC104 and something else that is logically ISA but physically something else...?

So in such case it would be logical to have driver depend on PC104 || SOMETHING_ELSE. Of course, if some hardware is so common it is on many such buses, we can use ISA_BUS_API...