Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1413474 > unrolled thread

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

Started byPavel Machek <pavel@ucw.cz>
First post2016-06-03 23:00 +0200
Last post2016-06-05 22:10 +0200
Articles 6 — 2 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH v2 2/4] gpio: Allow PC/104 devices on X86_64 Pavel Machek <pavel@ucw.cz> - 2016-06-03 23:00 +0200
    Re: [PATCH v2 2/4] gpio: Allow PC/104 devices on X86_64 William Breathitt Gray <vilhelm.gray@gmail.com> - 2016-06-03 23:20 +0200
      Re: [PATCH v2 2/4] gpio: Allow PC/104 devices on X86_64 Pavel Machek <pavel@ucw.cz> - 2016-06-04 09:20 +0200
        Re: [PATCH v2 2/4] gpio: Allow PC/104 devices on X86_64 William Breathitt Gray <vilhelm.gray@gmail.com> - 2016-06-04 13:20 +0200
          Re: [PATCH v2 2/4] gpio: Allow PC/104 devices on X86_64 Pavel Machek <pavel@ucw.cz> - 2016-06-05 21:30 +0200
            Re: [PATCH v2 2/4] gpio: Allow PC/104 devices on X86_64 William Breathitt Gray <vilhelm.gray@gmail.com> - 2016-06-05 22:10 +0200

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

FromPavel Machek <pavel@ucw.cz>
Date2016-06-03 23:00 +0200
SubjectRe: [PATCH v2 2/4] gpio: Allow PC/104 devices on X86_64
Message-ID<rG4md-83b-7@gated-at.bofh.it>
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

[toc] | [next] | [standalone]

#1413488

FromWilliam Breathitt Gray <vilhelm.gray@gmail.com>
Date2016-06-03 23:20 +0200
Message-ID<rG4Fz-8oJ-1@gated-at.bofh.it>
In reply to#1413474
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.

William Breathitt Gray

[toc] | [prev] | [next] | [standalone]

#1413669

FromPavel Machek <pavel@ucw.cz>
Date2016-06-04 09:20 +0200
Message-ID<rGe2d-5Mb-1@gated-at.bofh.it>
In reply to#1413488
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

[toc] | [prev] | [next] | [standalone]

#1413692

FromWilliam Breathitt Gray <vilhelm.gray@gmail.com>
Date2016-06-04 13:20 +0200
Message-ID<rGhMu-8gX-5@gated-at.bofh.it>
In reply to#1413669
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

[toc] | [prev] | [next] | [standalone]

#1414151

FromPavel Machek <pavel@ucw.cz>
Date2016-06-05 21:30 +0200
Message-ID<rGLUd-2qQ-7@gated-at.bofh.it>
In reply to#1413692
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

[toc] | [prev] | [next] | [standalone]

#1414199

FromWilliam Breathitt Gray <vilhelm.gray@gmail.com>
Date2016-06-05 22:10 +0200
Message-ID<rGMwW-2Vg-17@gated-at.bofh.it>
In reply to#1414151
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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web