From: sylvester.nawrocki@gmail.com (Sylwester Nawrocki)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 3/8] i2c: at91: use an id table for SoC dependent parameters
Date: Fri, 31 Aug 2012 22:47:15 +0200 [thread overview]
Message-ID: <504122D3.70507@gmail.com> (raw)
In-Reply-To: <5040CF80.8060201@atmel.com>
On 08/31/2012 04:51 PM, Nicolas Ferre wrote:
>>> diff --git a/arch/arm/mach-at91/at91rm9200.c b/arch/arm/mach-at91/at91rm9200.c
>>> index f2112f9..0bc91e5 100644
>>> --- a/arch/arm/mach-at91/at91rm9200.c
>>> +++ b/arch/arm/mach-at91/at91rm9200.c
>>> @@ -187,7 +187,7 @@ static struct clk_lookup periph_clocks_lookups[] = {
>>> CLKDEV_CON_DEV_ID("pclk", "ssc.0",&ssc0_clk),
>>> CLKDEV_CON_DEV_ID("pclk", "ssc.1",&ssc1_clk),
>>> CLKDEV_CON_DEV_ID("pclk", "ssc.2",&ssc2_clk),
>>> - CLKDEV_CON_DEV_ID(NULL, "at91_i2c",&twi_clk),
>>> + CLKDEV_CON_DEV_ID(NULL, "at91rm9200_i2c",&twi_clk),
>> use i2c-xxx as on other drivers
>>
>> and I do not like to have platform_device_id
>
> Me, I like it and find this implementation very elegant.
>
>> as we need to touch the driver to add a new soc
>
> So what? We still keep the compatibility if the new SoC has it
> compatibility assured with previous revision: there is nothing to modify.
I agree. The driver would need to be touched to support new SoC only if
the IP there have had some differences, which would have needed to be
resolved anyway.
>> please use platform data
Using platform data for the dt platforms would have been more troublesome,
wouldn't it ? I like Ludovic's approach which handles both: dt and non-dt
cases in uniform way from the driver's POV.
> No, it does not have to be exposed to the user: these data are highly
> dependent on the actual hardware (IP revision in fact). So, no need to
> mess with platform data.
Agreed.
> So I will acknowledge Ludo's patches.
>
> Bye,
--
Regards,
Sylwester
next prev parent reply other threads:[~2012-08-31 20:47 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-31 9:21 [PATCH 0/8] i2c: at91: cleanup and dt support ludovic.desroches at atmel.com
2012-08-31 9:21 ` [PATCH 1/8] i2c: at91: use managed resources ludovic.desroches at atmel.com
2012-09-03 5:52 ` Voss, Nikolaus
2012-08-31 9:21 ` [PATCH 2/8] i2c: at91: add warning about transmission issues for some devices ludovic.desroches at atmel.com
2012-09-03 5:54 ` Voss, Nikolaus
2012-08-31 9:21 ` [PATCH 3/8] i2c: at91: use an id table for SoC dependent parameters ludovic.desroches at atmel.com
2012-08-31 14:29 ` Jean-Christophe PLAGNIOL-VILLARD
2012-08-31 14:51 ` Nicolas Ferre
2012-08-31 20:47 ` Sylwester Nawrocki [this message]
2012-09-01 9:10 ` Jean-Christophe PLAGNIOL-VILLARD
2012-09-02 17:21 ` Sylwester Nawrocki
2012-09-06 4:54 ` Warner Losh
2012-09-03 6:16 ` Voss, Nikolaus
2012-09-03 7:24 ` ludovic.desroches
2012-09-03 7:51 ` Nicolas Ferre
2012-09-03 5:55 ` Voss, Nikolaus
2012-08-31 9:21 ` [PATCH 4/8] ARM: at91: do not configure at91sam9g10 twi pio as open-drain ludovic.desroches at atmel.com
2012-09-03 5:57 ` Voss, Nikolaus
2012-08-31 9:23 ` ludovic.desroches at atmel.com
2012-08-31 9:23 ` [PATCH 5/8] i2c: at91: add dt support to i2c-at91 ludovic.desroches at atmel.com
2012-09-03 5:58 ` Voss, Nikolaus
2012-08-31 9:24 ` [PATCH 6/8] ARM: at91: add clocks for I2C DT entries ludovic.desroches at atmel.com
2012-09-03 5:58 ` Voss, Nikolaus
2012-08-31 9:24 ` [PATCH 7/8] ARM: dts: add twi nodes for atmel SOCs ludovic.desroches at atmel.com
2012-08-31 14:41 ` Jean-Christophe PLAGNIOL-VILLARD
2012-08-31 14:46 ` ludovic.desroches
2012-08-31 14:56 ` Nicolas Ferre
2012-08-31 9:24 ` [PATCH 8/8] ARM: dts: add twi nodes for atmel boards ludovic.desroches at atmel.com
2012-08-31 14:42 ` Jean-Christophe PLAGNIOL-VILLARD
2012-08-31 15:07 ` Nicolas Ferre
2012-09-01 9:12 ` Jean-Christophe PLAGNIOL-VILLARD
2012-09-03 7:55 ` [PATCH 0/8] i2c: at91: cleanup and dt support Nicolas Ferre
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=504122D3.70507@gmail.com \
--to=sylvester.nawrocki@gmail.com \
--cc=linux-arm-kernel@lists.infradead.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).