[PATCH v2 0/4] Allow ISA-style drivers on modern systems

[PATCH v2 0/4] Allow ISA-style drivers on modern systems

[William Breathitt Gray]

Changes in v2:
  - Adjusted preprocessor compilation conditional in include/linux/isa.h
    to use CONFIG_ISA_BUS_API in order to link the correct ISA bus
    driver function definitions when available
  - Move ISA_BUS_API Kconfig option to arch/Kconfig, thus making it
    available to all architectures instead of just X86
  - X86 ISA_BUS Kconfig option should be disabled by default; ISA
    devices typically do not have a way to be probed, so users should
    be required to explicitly enable ISA bus driver support, lest a
    selected driver be loaded with the misguided expectation of a safe
    hardware probe

Several modern devices, such as PC/104 cards, are expected to run on
modern systems via an ISA bus interface. Since ISA is a legacy interface
for most modern architectures, ISA support should remain disabled in
general. Support for ISA-style drivers should be enabled on a per driver
basis.

To allow ISA-style drivers on modern systems, this patchset introduces
the ISA_BUS_API and ISA_BUS Kconfig options. The ISA bus driver will now
build conditionally on the ISA_BUS_API Kconfig option, which defaults to
the legacy ISA Kconfig option. The ISA_BUS Kconfig option allows the
ISA_BUS_API Kconfig option to be selected on architectures which do not
enable ISA (e.g. X86_64).

The ISA_BUS Kconfig option is currently only implemented for X86
architectures. Other architectures may have their own ISA_BUS Kconfig
option added as required.

An earlier attempt to allow the ISA bus driver to build for X86_64 took
an inappropriate approach resulting in legacy ISA drivers becoming
enabled unconditionally on untested and unsupported architectures.
Commit 51e68d055cba ("x86 isa: add back X86_32 dependency on
CONFIG_ISA"), added to restrict the ISA bus driver to only X86_32,
causes several drivers intended for X86_64 to be restricted to X86_32 as
well.

This patchset replaces the ISA Kconfig option dependency of several
drivers to ISA_BUS_API, so that they may build for X86_64 as intended.
The respective drivers are as follows:
    * ACCES 104-IDIO-16 GPIO driver
    * ACCES 104-IDI-48 GPIO driver
    * ACCES 104-DIO-48E GPIO driver
    * Apex Embedded Systems STX104 DAC driver
    * WinSystems EBC-C384 watchdog timer driver
    * WinSystems WS16C48 GPIO driver

William Breathitt Gray (4):
  isa: Allow ISA-style drivers on modern systems
  gpio: Allow PC/104 devices on X86_64
  iio: stx104: Allow build for X86_64
  watchdog: ebc-c384_wdt: Allow build for X86_64

 arch/Kconfig             |  3 +++
 arch/x86/Kconfig         | 10 ++++++++++
 drivers/base/Makefile    |  2 +-
 drivers/gpio/Kconfig     |  8 ++++----
 drivers/iio/dac/Kconfig  |  2 +-
 drivers/watchdog/Kconfig |  2 +-
 include/linux/isa.h      |  2 +-
 7 files changed, 21 insertions(+), 8 deletions(-)

-- 
2.7.3

[PATCH v2 1/4] isa: Allow ISA-style drivers on modern systems

[William Breathitt Gray]

Several modern devices, such as PC/104 cards, are expected to run on
modern systems via an ISA bus interface. Since ISA is a legacy interface
for most modern architectures, ISA support should remain disabled in
general. Support for ISA-style drivers should be enabled on a per driver
basis.

To allow ISA-style drivers on modern systems, this patch introduces the
ISA_BUS_API and ISA_BUS Kconfig options. The ISA bus driver will now
build conditionally on the ISA_BUS_API Kconfig option, which defaults to
the legacy ISA Kconfig option. The ISA_BUS Kconfig option allows the
ISA_BUS_API Kconfig option to be selected on architectures which do not
enable ISA (e.g. X86_64).

The ISA_BUS Kconfig option is currently only implemented for X86
architectures. Other architectures may have their own ISA_BUS Kconfig
options added as required.

Cc: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com>
---
 arch/Kconfig          |  3 +++
 arch/x86/Kconfig      | 10 ++++++++++
 drivers/base/Makefile |  2 +-
 include/linux/isa.h   |  2 +-
 4 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/arch/Kconfig b/arch/Kconfig
index b16e74e..9d9942f 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -598,6 +598,9 @@ config HAVE_STACK_VALIDATION
 	  Architecture supports the 'objtool check' host tool command, which
 	  performs compile-time stack metadata validation.
 
+config ISA_BUS_API
+	def_bool ISA
+
 #
 # ABI hall of shame
 #
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 0a7b885..6601912 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2439,6 +2439,16 @@ config PCI_CNB20LE_QUIRK
 
 source "drivers/pci/Kconfig"
 
+config ISA_BUS
+	bool "ISA-style bus support on modern systems" if (X86 && EXPERT)
+	default n
+	select ISA_BUS_API
+	help
+	  Enables ISA-style drivers on modern systems. This is necessary to
+	  support PC/104 devices on X86_64 platforms.
+
+	  If unsure, say N.
+
 # x86_64 have no ISA slots, but can have ISA-style DMA.
 config ISA_DMA_API
 	bool "ISA-style DMA support" if (X86_64 && EXPERT)
diff --git a/drivers/base/Makefile b/drivers/base/Makefile
index 6b2a84e..2609ba2 100644
--- a/drivers/base/Makefile
+++ b/drivers/base/Makefile
@@ -10,7 +10,7 @@ obj-$(CONFIG_DMA_CMA) += dma-contiguous.o
 obj-y			+= power/
 obj-$(CONFIG_HAS_DMA)	+= dma-mapping.o
 obj-$(CONFIG_HAVE_GENERIC_DMA_COHERENT) += dma-coherent.o
-obj-$(CONFIG_ISA)	+= isa.o
+obj-$(CONFIG_ISA_BUS_API)	+= isa.o
 obj-$(CONFIG_FW_LOADER)	+= firmware_class.o
 obj-$(CONFIG_NUMA)	+= node.o
 obj-$(CONFIG_MEMORY_HOTPLUG_SPARSE) += memory.o
diff --git a/include/linux/isa.h b/include/linux/isa.h
index 5ab8528..384ab9b 100644
--- a/include/linux/isa.h
+++ b/include/linux/isa.h
@@ -22,7 +22,7 @@ struct isa_driver {
 
 #define to_isa_driver(x) container_of((x), struct isa_driver, driver)
 
-#ifdef CONFIG_ISA
+#ifdef CONFIG_ISA_BUS_API
 int isa_register_driver(struct isa_driver *, unsigned int);
 void isa_unregister_driver(struct isa_driver *);
 #else
-- 
2.7.3

[PATCH v2 2/4] gpio: Allow PC/104 devices on X86_64

[William Breathitt Gray]

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 <linux@roeck-us.net>
Cc: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com>
---
 drivers/gpio/Kconfig | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 48da857..dc6da77 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -530,7 +530,7 @@ menu "Port-mapped I/O GPIO drivers"
 
 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 (104-DIO-48E,
@@ -540,7 +540,7 @@ config GPIO_104_DIO_48E
 
 config GPIO_104_IDIO_16
 	tristate "ACCES 104-IDIO-16 GPIO support"
-	depends on ISA
+	depends on ISA_BUS_API
 	select GPIOLIB_IRQCHIP
 	help
 	  Enables GPIO support for the ACCES 104-IDIO-16 family (104-IDIO-16,
@@ -551,7 +551,7 @@ config GPIO_104_IDIO_16
 
 config GPIO_104_IDI_48
 	tristate "ACCES 104-IDI-48 GPIO support"
-	depends on ISA
+	depends on ISA_BUS_API
 	select GPIOLIB_IRQCHIP
 	help
 	  Enables GPIO support for the ACCES 104-IDI-48 family (104-IDI-48A,
@@ -627,7 +627,7 @@ config GPIO_TS5500
 
 config GPIO_WS16C48
 	tristate "WinSystems WS16C48 GPIO support"
-	depends on ISA
+	depends on ISA_BUS_API
 	select GPIOLIB_IRQCHIP
 	help
 	  Enables GPIO support for the WinSystems WS16C48. The base port
-- 
2.7.3

[PATCH v2 3/4] iio: stx104: Allow build for X86_64

[William Breathitt Gray]

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 Apex Embedded Systems STX104 DAC
driver to ISA_BUS_API, thus allowing it to build for X86_64 as it is
expected to.

Cc: Hartmut Knaack <knaack.h@gmx.de>
Cc: Lars-Peter Clausen <lars@metafoo.de>
Cc: Peter Meerwald-Stadler <pmeerw@pmeerw.net>
Cc: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com>
---
 drivers/iio/dac/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/iio/dac/Kconfig b/drivers/iio/dac/Kconfig
index e63b957..315442f 100644
--- a/drivers/iio/dac/Kconfig
+++ b/drivers/iio/dac/Kconfig
@@ -247,7 +247,7 @@ config MCP4922
 
 config STX104
 	tristate "Apex Embedded Systems STX104 DAC driver"
-	depends on X86 && ISA
+	depends on ISA_BUS_API
 	help
 	  Say yes here to build support for the 2-channel DAC on the Apex
 	  Embedded Systems STX104 integrated analog PC/104 card. The base port
-- 
2.7.3

[PATCH v2 4/4] watchdog: ebc-c384_wdt: Allow build for X86_64

[William Breathitt Gray]

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 WinSystems EBC-C384 watchdog timer
driver to ISA_BUS_API, thus allowing it to build for X86_64 as it is
expected to.

Cc: Guenter Roeck <linux@roeck-us.net>
Cc: Wim Van Sebroeck <wim@iguana.be>
Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com>
---
 drivers/watchdog/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index b54f26c..3938e2d 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -746,7 +746,7 @@ config ALIM7101_WDT
 
 config EBC_C384_WDT
 	tristate "WinSystems EBC-C384 Watchdog Timer"
-	depends on X86 && ISA
+	depends on ISA_BUS_API
 	select WATCHDOG_CORE
 	help
 	  Enables watchdog timer support for the watchdog timer on the
-- 
2.7.3

Re: [PATCH v2 1/4] isa: Allow ISA-style drivers on modern systems

[Stephen Rothwell]

Hi William,

Just a small question ...

On Mon, 23 May 2016 17:20:01 -0400 William Breathitt Gray <vilhelm.gray-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index 0a7b885..6601912 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -2439,6 +2439,16 @@ config PCI_CNB20LE_QUIRK
>  
>  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?

-- 
Cheers,
Stephen Rothwell

Re: [PATCH v2 1/4] isa: Allow ISA-style drivers on modern systems

[William Breathitt Gray]

On Tue, May 24, 2016 at 08:29:12AM +1000, Stephen Rothwell wrote:
>Hi William,
>
>Just a small question ...
>
>On Mon, 23 May 2016 17:20:01 -0400 William Breathitt Gray <vilhelm.gray@gmail.com> wrote:
>>
>> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
>> index 0a7b885..6601912 100644
>> --- a/arch/x86/Kconfig
>> +++ b/arch/x86/Kconfig
>> @@ -2439,6 +2439,16 @@ config PCI_CNB20LE_QUIRK
>>  
>>  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?
>
>-- 
>Cheers,
>Stephen Rothwell

Yes, I believe you are correct. I'll remove the explicit X86 dependency
as it is redundant inside the arch/x86/Kconfig file.

William Breathitt Gray

Re: [PATCH v2 2/4] gpio: Allow PC/104 devices on X86_64

[Pavel Machek]

Hi!

> 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 <linux@roeck-us.net>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com>
> ---
>  drivers/gpio/Kconfig | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
> index 48da857..dc6da77 100644
> --- a/drivers/gpio/Kconfig
> +++ b/drivers/gpio/Kconfig
> @@ -530,7 +530,7 @@ menu "Port-mapped I/O GPIO drivers"
>  
>  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?

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [PATCH v2 2/4] gpio: Allow PC/104 devices on X86_64

[William Breathitt Gray]

On Fri, Jun 03, 2016 at 10:57:03PM +0200, Pavel Machek wrote:
>Hi!
>
>> 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 <linux-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org>
>> Cc: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
>> Signed-off-by: William Breathitt Gray <vilhelm.gray-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>> ---
>>  drivers/gpio/Kconfig | 8 ++++----
>>  1 file changed, 4 insertions(+), 4 deletions(-)
>> 
>> diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
>> index 48da857..dc6da77 100644
>> --- a/drivers/gpio/Kconfig
>> +++ b/drivers/gpio/Kconfig
>> @@ -530,7 +530,7 @@ menu "Port-mapped I/O GPIO drivers"
>>  
>>  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.

William Breathitt Gray
--
To unsubscribe from this list: send the line "unsubscribe linux-watchdog" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 2/4] gpio: Allow PC/104 devices on X86_64

[Pavel Machek]

On Fri 2016-06-03 17:12:44, William Breathitt Gray wrote:
> On Fri, Jun 03, 2016 at 10:57:03PM +0200, Pavel Machek wrote:
> >Hi!
> >
> >> 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 <linux@roeck-us.net>
> >> Cc: Linus Walleij <linus.walleij@linaro.org>
> >> Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com>
> >> ---
> >>  drivers/gpio/Kconfig | 8 ++++----
> >>  1 file changed, 4 insertions(+), 4 deletions(-)
> >> 
> >> diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
> >> index 48da857..dc6da77 100644
> >> --- a/drivers/gpio/Kconfig
> >> +++ b/drivers/gpio/Kconfig
> >> @@ -530,7 +530,7 @@ menu "Port-mapped I/O GPIO drivers"
> >>  
> >>  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.

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...

Best regards,
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [PATCH v2 2/4] gpio: Allow PC/104 devices on X86_64

[William Breathitt Gray]

On Sat, Jun 04, 2016 at 09:14:08AM +0200, Pavel Machek wrote:
>On Fri 2016-06-03 17:12:44, William Breathitt Gray wrote:
>> On Fri, Jun 03, 2016 at 10:57:03PM +0200, Pavel Machek wrote:
>> >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.
>
>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.

William Breathitt Gray

Re: [PATCH v2 2/4] gpio: Allow PC/104 devices on X86_64

[Pavel Machek]

On Sat 2016-06-04 07:12:21, William Breathitt Gray wrote:
> On Sat, Jun 04, 2016 at 09:14:08AM +0200, Pavel Machek wrote:
> >On Fri 2016-06-03 17:12:44, William Breathitt Gray wrote:
> >> On Fri, Jun 03, 2016 at 10:57:03PM +0200, Pavel Machek wrote:
> >> >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.
> >
> >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.

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...

Best regards,
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [PATCH v2 2/4] gpio: Allow PC/104 devices on X86_64

[William Breathitt Gray]

On Sun, Jun 05, 2016 at 09:24:24PM +0200, Pavel Machek wrote:
>On Sat 2016-06-04 07:12:21, William Breathitt Gray wrote:
>> 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.
>
>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...

It does sound like it would be good to have a filter for drivers which
support only PC/104 device: a user would be able to conveniently filter
out PC/104 drivers, since most consumer systems do not feature a PC/104
bus even if they do possess an ISA bus. For drivers which support both
ISA and PC/104 devices, we could simply do as you suggest; but it's
likely that we will see fewer and fewer of these true ISA devices in the
future, which leaves the PC104 Kconfig option quite useful to implement.

William Breathitt Gray