Thread (1 message) 1 message, 1 author, 2012-08-31

Re: [PATCH 3/8] i2c: at91: use an id table for SoC dependent parameters

From: Sylwester Nawrocki <hidden>
Date: 2012-08-31 20:47:15
Also in: linux-arm-kernel, linux-i2c

On 08/31/2012 04:51 PM, Nicolas Ferre wrote:
quoted
quoted
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.
quoted
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.
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help