From: Jonathan Cameron <jic23@kernel.org>
To: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: linux-iio@vger.kernel.org, greg@kroah.com,
guenter.roeck@ericsson.com, khali@linux-fr.org,
dmitry.torokhov@gmail.com, alan@lxorguk.ukuu.org.uk,
arnd@arndb.de, linus.walleij@linaro.org,
maxime.ripard@free-electrons.com,
thomas.petazzoni@free-electrons.com, zdevai@gmail.com,
w.sang@pengutronix.de, marek.vasut@gmail.com,
Jonathan Cameron <jic23@cam.ac.uk>
Subject: Re: [PATCH 1/5] staging:iio:core add in kernel interface mapping and getting IIO channels.
Date: Mon, 30 Jan 2012 20:28:50 +0000 [thread overview]
Message-ID: <4F26FD82.0@kernel.org> (raw)
In-Reply-To: <20120130202226.GB9672@opensource.wolfsonmicro.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 01/30/2012 08:22 PM, Mark Brown wrote:
> On Sun, Jan 29, 2012 at 11:46:50AM +0000, Jonathan Cameron wrote:
>
>> -static struct device_type iio_dev_type = { +struct device_type
>> iio_dev_type = { .name = "iio_device", .release =
>> iio_dev_release, };
>
> Why is this exported?
oops. Hangover from previous version I think. Thanks for pointing it out.
>
>> + mutex_lock(&iio_map_list_lock); + while ((maps[i].consumer_dev
>> != NULL) || + (maps[i].consumer_dev_name != NULL)) {
>
> I'd suggest just dropping the struct device - the reason we support
> the struct device directly in the regulator API is that we
> originally had only a struct device and kept the code around as a
> transition measure (though now it's so old we should be able to
> kill it off). This would simplify the code and the interface a
> bit.
Ah, that explains your comment on the 5th patch. Alright, I'll let this
sit for a few days and if no one comes up with a good reason not to
we'll go with just the dev_name option.
Jonathan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBAgAGBQJPJv2CAAoJEFSFNJnE9BaIfRYP/R9nGQIY7sCm4UsdBZldyW93
8Eu0jPMXJs/YLgc7zSJisFqUQNS4BJjORVDh2AcV/hu7FXaxtD6QhxaC3/RMjwfa
EgElSYU7N2yPThJLXh1w12qgvt6+zxAT+Gnv11pHeaf6gZrXU2IUBy1FlExCudpI
hc+CnDSSHjZk6aJKWmockmcmwlSGLy4WV7nH4S907pzm2yXnI9UqvVaHwPVtO/Yl
rZyrZo6T8C4Xw2GeB5QdZ4GNXRuNUOezc1OfqdK/FKj3lVo23ZsAfoMoKkS33ZWF
zjU8deSJY6VSYhfJtnfv7ucv5GjjhbuWSGZP0VD/BR+eTjWD54EasVv5AqwOz/Iz
wwbvanHTqsVrEBU76733wvWRFelZXgzYhFoQYEucQB5F4KCtqO1OTi62stDCXLLR
Z9ygHH92t7TlsKbxaMGL8gU7jGDeIytuHgJW2BXd8ekwQr4fdY7eBwoW4A+TRSKl
rCNSp5iuKIXjyQ8ZJviOKXlZDJa2/5mYuDO8juQFcYshe+X29pbsrybLPkBBKdhl
GxOi8DtiMVPCiHB63bKGXhqe38jNeHK0hboiREHZgnEt1/a+ZkLDVnWtLQcUBuBo
UfLfuzQju/DrtqnWj8asmRzpsA675Lh1xmdLU0tv/NEb/aOGnIAy3+BAhhiq2g1w
OU87P/vuWQrgl1D/jUEh
=l3HK
-----END PGP SIGNATURE-----
next prev parent reply other threads:[~2012-01-30 20:28 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-29 11:46 [RFC PATCH 0/5 V5] IIO: in kernel pull interfaces Jonathan Cameron
2012-01-29 11:46 ` [PATCH 1/5] staging:iio:core add in kernel interface mapping and getting IIO channels Jonathan Cameron
2012-01-30 20:22 ` Mark Brown
2012-01-30 20:28 ` Jonathan Cameron [this message]
2012-02-01 19:58 ` Linus Walleij
2012-02-06 21:30 ` Jonathan Cameron
2012-02-09 18:10 ` Greg KH
2012-02-09 18:34 ` Jonathan Cameron
2012-02-09 18:57 ` Greg KH
2012-02-09 19:15 ` Mark Brown
2012-02-09 19:17 ` Greg KH
2012-02-09 19:20 ` Mark Brown
2012-02-09 21:20 ` Jonathan Cameron
2012-02-10 1:03 ` Linus Walleij
2012-01-29 11:46 ` [PATCH 2/5] staging:iio: move iio data return types into types.h for use by inkern Jonathan Cameron
2012-01-29 11:46 ` [PATCH 3/5] staging:iio::hwmon interface client driver Jonathan Cameron
2012-01-29 11:46 ` [PATCH 4/5] staging:iio:Documentation in kernel pull description Jonathan Cameron
2012-01-29 11:46 ` [PATCH 5/5] stargate2: example of map configuration for iio to hwmon example Jonathan Cameron
2012-01-30 19:33 ` Mark Brown
2012-01-30 20:26 ` Jonathan Cameron
2012-01-30 21:22 ` Mark Brown
2012-01-30 21:48 ` Jonathan Cameron
2012-01-31 8:39 ` Linus Walleij
2012-01-31 11:09 ` Mark Brown
2012-01-30 19:28 ` [RFC PATCH 0/5 V5] IIO: in kernel pull interfaces Linus Walleij
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=4F26FD82.0@kernel.org \
--to=jic23@kernel.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=arnd@arndb.de \
--cc=broonie@opensource.wolfsonmicro.com \
--cc=dmitry.torokhov@gmail.com \
--cc=greg@kroah.com \
--cc=guenter.roeck@ericsson.com \
--cc=jic23@cam.ac.uk \
--cc=khali@linux-fr.org \
--cc=linus.walleij@linaro.org \
--cc=linux-iio@vger.kernel.org \
--cc=marek.vasut@gmail.com \
--cc=maxime.ripard@free-electrons.com \
--cc=thomas.petazzoni@free-electrons.com \
--cc=w.sang@pengutronix.de \
--cc=zdevai@gmail.com \
/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;
as well as URLs for NNTP newsgroup(s).