Re: Request for Clarification: old - legacy - new driver model

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

On Thu, 19 Feb 2009 15:17:13 +0100, Michael Lawnick wrote:
> Wolfram Sang said the following:
> > Hi Michael,
> > 
> >> Can someone give me explanations/links/msg ids?
> > 
> > Documentation/i2c/upgrading-clients
> > 
> After re-reading it, I have to state that this document doesn't answer
> the questions behind my original ones (which I wanted to answer myself
> by following helpful links):
> From which kernel version on should the 'new-binding' model work?

It started in kernel 2.6.22. But there were significant changes later
in kernels 2.6.25 and 2.6.26.

> How is attaching of a hot plugged i2c device achieved a) from kernel b)
> from user space.

The I2C bus doesn't support hot-plugging, so I am not sure what you
mean?

> For kernel space init I assume its a call to i2c_new_device(). Here I'm
> wondering where I should get the adapter info from.

Depends. i2c_new_device() is suitable for TV adapters for example. For
embedded boards, you'd rather declare all I2C devices with
i2c_register_board_info() and use fixed I2C bus numbers.

> For user space I'm completely lost (ioctl on /dev/i2cx?).

User-space access through i2c-dev is entirely unchanged.

If you mean creating I2C devices from user-space, the interface for
this doesn't exist yet. I have a simple one in mind, but I can never
find the time to work on it :/

That being said, this can be worked around using the old
I2C_CLIENT_INSMOD macros. These let you pass module parameters forcing
clients at a specific address.

> Our situation: main board is up and running, all drivers loaded.
> Now an extension board will be plugged in. It is detected by
> periodically polling via I2C for MUX. After detection the drivers e.g.

This is totally unsupported. I2C isn't an hot-pluggable bus.

(Not to mention that support for mux chips is currently missing, but at
least this is being worked on and fixable.)

> for temperature an MUX on the secondary board need to be attached to I2C
> subsystem. Instances of both drivers are already running for local
> devices, re-loading is only a bad option.

You shouldn't have to reload any driver.

> Do I really have to read and understand i2c-core.c and i2c-dev.c to find
> out?

i2c-dev most probably doesn't have anything to do with your problem.

What you are missing, as far as I can see, is proper mux support.
Rodolfo Giometti (Cc'd) is working on this, if you want to test his
patches (which I still didn't have the time to look at, sadly.)

-- 
Jean Delvare