Re: [PATCH 0/1] misc: Add Tunnel creek In-Vehicle I2C loader driver

[Jean Delvare <khali-PUYAD+kWke1g9hUCZPvPmw@public.gmane.org>]

Hi Richard,

On Wed, 29 Sep 2010 10:38:40 +0200, Richard Röjfors wrote:
> On 09/08/2010 04:41 PM, Richard Röjfors wrote:
> > To follow is a patch adding a driver which adds devices to the I2C
> > bus on tunnel creek in-vehicle development boards.
> 
> I never got any feedback on my patch.
> 
> It doesn't seem like misc has it own mailinglist so I suppose this is
> where it should be posted(?)
> 
> The reason for the driver is the lack of board config in X86 so there is
> simply no way to define the devices on the I2C bus. It can not be done
> from the user space, since GPIO pins need to be turned into interrupts
> numbers and passed in the platform data to the I2C devices.
> 
> Any suggestions how to move forward to get such driver into the kernel?

I don't like the idea of such "loader" drivers. If we need to have such
a separate driver for every embedded x86 system, things will get pretty
ugly quickly. I know we already have at least two somewhat similar
drivers (i2c-amd756-s4882 and i2c-nforce2-s4985) but I really would
like to get rid of them, not add more of the same type.

My impression is that x86 doesn't have board config because it wasn't
so far an architecture used for embedded systems. But times are
changing, and now x86 starts being used for embedded systems. Instead
of coming up with a new way of handling I2C device instantiation
("loader" drivers), I think we simply want to add board config support
to x86 as many other architectures already have.

As a matter of fact, I have been discussing this with Intel people
recently:
  http://marc.info/?t=128683908500001&r=1&w=2
It is pretty clear that Intel have added board config support to x86
already, even though that change may not be public yet. So I can only
encourage you to discuss this with Jacob Pan, Feng Tang and Alan Cox.

If you need a temporary solution until then, I encourage you to simply
add your code to the I2C bus driver your system is using. We already
have examples of this in i2c-i801, i2c-ocores, i2c-powermac,
i2c-taos-evm and i2c-xiic, so at least you wouldn't be doing
something new.

-- 
Jean Delvare