On 22:47 Fri 31 Aug , Sylwester Nawrocki wrote:
> 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 you will describe it via DT as done on all the other drivers
>
> > 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.
no I really see no point on these list of platform_id it's does not look more
nice just more huggly to have x names. This is at the end the same as passing
platform data via soc info (add_xx or dtsi)
And here you just do the same as cpu_is via names.
The driver need to read IP revision instead
Best Regards,
J.
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
