From: William Breathitt Gray <vilhelm.gray@gmail.com>
To: Jonathan Cameron <jic23@kernel.org>
Cc: knaack.h@gmx.de, lars@metafoo.de, pmeerw@pmeerw.net,
linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] iio: Add IIO support for the DAC on the Apex Embedded Systems STX104
Date: Wed, 10 Feb 2016 16:22:40 -0500 [thread overview]
Message-ID: <20160210212240.GA12207@sophia> (raw)
In-Reply-To: <56BB87B1.3030806@kernel.org>
On Wed, Feb 10, 2016 at 06:55:45PM +0000, Jonathan Cameron wrote:
>On 10/02/16 02:19, William Breathitt Gray wrote:
>> On Tue, Feb 09, 2016 at 10:37:09PM +0000, Jonathan Cameron wrote:
>>> My only real question is on the naming of the module parameter.
>>> Is it the equivalent of the io address that a load of ISA
>>> radio drivers seem to use? (fed to me by grepping isa_register_driver)
>>> If so perhaps that's the 'standard' name as much as one exists for this?
>>
>> Yes, you noted correctly that the stx104_base module parameter fulfills
>> the same function as the io module parameter used in many of the radio
>> drivers: it's an array holding the io port address of each device.
>> However, I find "io" to be a rather vague module parameter name, so I've
>> decided to use the more apt "stx104_base" name for my array of base
>> addresses.
>>
>> As you've probably noticed, there are few ISA drivers existing in the
>> kernel baseline currently, so not much of a standard is set yet. I'm all
>> right with renaming the module parameter if you have a preference, just
>> as long as the name is more informative than simply "io."
>>
>> For what it's worth, this driver is part of a series of PC/104 drivers
>> I've been submitting to various subsystems (in the hopes of improving
>> the lack of PC/104 support in the baseline Linux kernel); see
>> drivers/gpio/gpio-104-idio-16.c and drivers/gpio/gpio-104-idi-48.c for
>> example. I have thus far been following the convention of naming the
>> base address module parameter as "modname_base," where "modname" is the
>> respective module name.
>I've been trying to work out if IO ports is a generic enough ISA term
>to take the view that anyone using an ISA card should know about it...
>I certainly know the I/O space approach to interacting with PCI cards is
>well understood in people working with shall we say 'dumb' PCI hardware.
>
>I guess I don't really care all that much on this though - just nice to
>be consistent / general when possible.
I believe that port-mapped I/O is ubiquitous enough in the industry that
anyone with an ISA card will understand the term; in fact, I can't
recall any PC/104 card datasheet I've encountered without a chapter
section devoted to "I/O port address" configuration.
The ISA drivers in the sound subsystem use "port" as the module
parameter name for the I/O port base address of the respective sound
device. Notice also how there are module parameters such as "midi_port"
which represent the I/O port address of various registers on the device.
"I/O port address" does not necessarily mean the base address of the
device, but simply a port address (typically pointing to a particular
register). For this reason, I prefer the more specific name "base" to
indicate the I/O port base address of the device from which to derive
the register addresses.
Thinking it over again, I want to submit a version 3 of this patch which
will rename "stx104_base" to the more general "base" name; the "stx104_"
prefix is overly verbose for a module parameter since the user should
already know the module he/she is configuring. Hopefully, by using a
more general name, there will also arise a more consistent way of
configuring the I/O port base addresses among other PC/104 and ISA
drivers via the "base" module parameter.
Are there any other changes I should include in version 3?
On an unrelated note, I may write a patch in the future to add support
for the 16-channel ADC on the STX104. Should this support be added into
this existing iio/dac/stx104.c file, or into a new iio/adc/stx104.c
file?
William Breathitt Gray
next prev parent reply other threads:[~2016-02-10 21:22 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-08 17:50 [PATCH v2] iio: Add IIO support for the DAC on the Apex Embedded Systems STX104 William Breathitt Gray
2016-02-09 22:37 ` Jonathan Cameron
2016-02-10 2:19 ` William Breathitt Gray
2016-02-10 18:55 ` Jonathan Cameron
2016-02-10 21:22 ` William Breathitt Gray [this message]
2016-02-10 22:46 ` Jonathan Cameron
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=20160210212240.GA12207@sophia \
--to=vilhelm.gray@gmail.com \
--cc=jic23@kernel.org \
--cc=knaack.h@gmx.de \
--cc=lars@metafoo.de \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pmeerw@pmeerw.net \
/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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox