From: Lee Jones <lee.jones@linaro.org>
To: Maxime Ripard <maxime.ripard@free-electrons.com>
Cc: Quentin Schulz <quentin.schulz@free-electrons.com>,
jdelvare@suse.com, linux@roeck-us.net, jic23@kernel.org,
knaack.h@gmx.de, lars@metafoo.de, pmeerw@pmeerw.net,
wens@csie.org, thomas.petazzoni@free-electrons.com,
antoine.tenart@free-electrons.com, linux-kernel@vger.kernel.org,
linux-hwmon@vger.kernel.org, linux-iio@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v5 2/3] mfd: add support for Allwinner SoCs ADC
Date: Mon, 12 Sep 2016 16:07:15 +0100 [thread overview]
Message-ID: <20160912150715.GG9789@dell> (raw)
In-Reply-To: <20160912143548.GL9449@lukather>
On Mon, 12 Sep 2016, Maxime Ripard wrote:
> On Mon, Sep 12, 2016 at 02:56:55PM +0100, Lee Jones wrote:
> > > >>> Then use .data = <defined model ID> and set up a switch() in .probe().
> > > >>
> > > >> Uh? Why? It just adds a non-standard indirection, while using
> > > >> of_match_device is very standard, and used extensively in Linux.
> > > >
> > > > You still use of_match_device() to obtain the ID.
> > > >
> > > > The "don't mix DT with the MFD API" is there to prevent some of the
> > > > nasty hacks I've seen previously. This particular example doesn't
> > > > seem so bad, but it's a gateway to ridiculous hackery!
> > >
> > > How am I supposed to get the .data without of_match_node then?
> > > What's more hackish in using .data field for specific data for each
> > > compatible than in using a random ID in .data and switching on it? The
> > > result is exactly the same, the switching case being more verbose and
> > > adding complexity to something that can be done in a straightforward manner.
> >
> > I've already agreed that your implementation isn't terrible, but I'd
> > still like to remain strict on the rules.
> >
> > Better still, can you can dynamically test which platform you're on,
> > via a version register or similar?
> >
> > Failing that, see how everyone else does it:
> >
> > `git grep "\.data" -- drivers/mfd/`
>
> Just to make sure, you prefer something like
>
> static struct my_struct data = {
> };
>
> static struct my_struct data2 = {
> };
>
> struct of_device_id matches[] = {
> { compatible = "...", data = <ID> },
> { compatible = "...", data = <ID2> },
> };
>
> of_id = of_match_device (dev, matches);
> switch (of_id->data) {
> case <ID>:
> function(data);
> case <ID2>:
> function(data2);
> };
>
> over
>
> static struct my_struct data = {
> };
>
> static struct my_struct data2 = {
> };
>
> struct of_device_id matches[] = {
> { compatible = "...", data = data },
> { compatible = "...", data = data2 },
> };
>
> of_id = of_match_device (dev, matches);
> function(of_id->data);
>
> ?
>
> This is the *only* time this is going to be used in that driver. I can
> understand the need for a version if you need to apply quirks in
> several functions, but here it clearly looks suboptimal.
>
> And we are indeed using this construct in the AXP MFD, and it just
> doesn't scale either and become quite difficult to maintain when you
> have a significant number of variants, and then you have to patch
> *all* the switch instances to get something done.
static struct my_struct data = {
};
static struct my_struct data2 = {
};
struct of_device_id matches[] = {
{ compatible = "...", data = <ID> },
{ compatible = "...", data = <ID2> },
};
int probe()
{
struct mfd_cell *cell;
of_id = of_match_device (dev, matches);
switch (of_id->data) {
case <ID>:
cell = data;
case <ID2>:
cell = data2;
};
mfd_add_devices(..., cell, ...)
};
It's an extra few lines, but worth it to unbind MFD from DT.
Is there really no way to obtain this information dynamically?
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
next prev parent reply other threads:[~2016-09-12 15:07 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-08 14:28 [PATCH v5 0/3] add support for Allwinner SoCs ADC Quentin Schulz
2016-09-08 14:28 ` [PATCH v5 1/3] hwmon: iio_hwmon: defer probe when no channel is found Quentin Schulz
2016-09-09 4:26 ` Guenter Roeck
2016-09-10 15:02 ` Jonathan Cameron
2016-09-08 14:28 ` [PATCH v5 2/3] mfd: add support for Allwinner SoCs ADC Quentin Schulz
2016-09-09 14:38 ` Maxime Ripard
2016-09-10 15:07 ` Jonathan Cameron
2016-09-12 9:18 ` Lee Jones
2016-09-12 9:43 ` Quentin Schulz
2016-09-12 9:59 ` Lee Jones
2016-09-12 10:07 ` Maxime Ripard
2016-09-12 10:49 ` Lee Jones
2016-09-12 10:58 ` Quentin Schulz
2016-09-12 13:56 ` Lee Jones
2016-09-12 14:35 ` Maxime Ripard
2016-09-12 15:07 ` Lee Jones [this message]
2016-09-12 11:08 ` Quentin Schulz
2016-09-12 13:56 ` Lee Jones
2016-09-13 7:06 ` Quentin Schulz
2016-09-13 8:21 ` Lee Jones
2016-09-08 14:28 ` [PATCH v5 3/3] iio: adc: " Quentin Schulz
2016-09-09 14:50 ` Maxime Ripard
2016-09-10 15:09 ` 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=20160912150715.GG9789@dell \
--to=lee.jones@linaro.org \
--cc=antoine.tenart@free-electrons.com \
--cc=jdelvare@suse.com \
--cc=jic23@kernel.org \
--cc=knaack.h@gmx.de \
--cc=lars@metafoo.de \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-hwmon@vger.kernel.org \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=maxime.ripard@free-electrons.com \
--cc=pmeerw@pmeerw.net \
--cc=quentin.schulz@free-electrons.com \
--cc=thomas.petazzoni@free-electrons.com \
--cc=wens@csie.org \
/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).