From: Stephen Warren <swarren@wwwdotorg.org>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] pinctrl/nomadik: add STn8815 ASIC support
Date: Tue, 12 Jun 2012 10:17:29 -0600 [thread overview]
Message-ID: <4FD76B99.9070901@wwwdotorg.org> (raw)
In-Reply-To: <CACRpkdZyirEvBH7yDXCW2h54oEKueJh4fnmDrPLPH2B00m=YSg@mail.gmail.com>
On 06/12/2012 05:28 AM, Linus Walleij wrote:
> On Fri, Jun 8, 2012 at 6:39 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
>> On 06/08/2012 03:07 AM, Linus Walleij wrote:
>>> This adds support for the STN8815 ASIC for the Nomadik pin
>>> controller.
>>
>>> diff --git a/drivers/pinctrl/pinctrl-nomadik.c b/drivers/pinctrl/pinctrl-nomadik.c
>>
>>> @@ -1717,6 +1717,8 @@ static int __devinit nmk_pinctrl_probe(struct platform_device *pdev)
>>> of_match_device(nmk_pinctrl_match, &pdev->dev)->data;
>>>
>>> /* Poke in other ASIC variants here */
>>> + if (version == PINCTRL_NMK_STN8815)
>>> + nmk_pinctrl_stn8815_init(&npct->soc);
>>> if (version == PINCTRL_NMK_DB8500)
>>> nmk_pinctrl_db8500_init(&npct->soc);
>>
>> One comment that came up in other reviews is that we shouldn't have a
>> single driver that switches on the SoC type it's running on and then
>> dispatches to different ${soc}_init() functions, but rather should have
>> multiple separate drivers, where each probe calls some utility function
>> with the appropriate SoC parameterization structures/tables.
>
> I discussed this with Arnd, the patch doesn't give the context of where this
> identifier comes from:
>
> static const struct platform_device_id nmk_pinctrl_id[] = {
> { "pinctrl-stn8815", PINCTRL_NMK_STN8815 },
> { "pinctrl-db8500", PINCTRL_NMK_DB8500 },
> };
>
> static struct platform_driver nmk_pinctrl_driver = {
> .driver = {
> .owner = THIS_MODULE,
> .name = "pinctrl-nomadik",
> .of_match_table = nmk_pinctrl_match,
> },
> .probe = nmk_pinctrl_probe,
> .id_table = nmk_pinctrl_id,
> };
>
> And the probe looks like so:
>
> static int __devinit nmk_pinctrl_probe(struct platform_device *pdev)
> {
> const struct platform_device_id *platid = platform_get_device_id(pdev);
> (...)
> if (platid)
> version = platid->driver_data;
>
> So the same driver handles several platform device names, then
> the name is used to select a variant. IIRC I asked Arnd about this
> and he preferred this, and I was told by Mark Brown in the past
> to do things this way (c.f. drivers/mfs/ab8500-core.c).
Hmm. I believe that's the exact opposite of what Arnd said during review
of the SPEAr pinctrl driver! Maybe there's some other aspect of the
design that caused this scheme to be perceived as worse for SPEAr,
beyond just this simple issue.
Still, I only raised this comment because I recalled it being made on
the SPEAr review. I'm not particularly attached to doing it one way or
the other, so don't count this sub-thread as NAKing the patch or
anything like that.
> Doing it the other way is also possible but leads to a proliferation
> of probe() calls and struct platform_driver blocks, and result in
> more lines of code.
>
> Both ways have precedents in the kernel so I actually think both
> are OK, there is two ways to skin this cat simply and I'm not that
> sensitive to which one is used.
>
> Yours,
> Linus Walleij
next prev parent reply other threads:[~2012-06-12 16:17 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-08 9:07 [PATCH 1/2] pinctrl/nomadik: add STn8815 ASIC support Linus Walleij
2012-06-08 16:39 ` Stephen Warren
2012-06-12 11:28 ` Linus Walleij
2012-06-12 16:17 ` Stephen Warren [this message]
-- strict thread matches above, loose matches on Subject: below --
2012-08-09 22:43 Linus Walleij
2012-08-10 23:15 ` Stephen Warren
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=4FD76B99.9070901@wwwdotorg.org \
--to=swarren@wwwdotorg.org \
--cc=linus.walleij@linaro.org \
--cc=linux-kernel@vger.kernel.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