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

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

Hi Michael,

On Tue, 24 Feb 2009 16:09:33 +0100, Michael Lawnick wrote:
> Jean Delvare said the following:
> > On Thu, 19 Feb 2009 15:17:13 +0100, Michael Lawnick wrote:
> <snip>
> >> 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.
> > 
> <snip>
> > 
> > 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.)
> > 
> I have seen the patches, I am planning based on them.
> 
> Well, thinking about it, I hope to have a solution.
> Here is what a H/W might look like:
>                           +-------+   +--------+
>                           |  LM75 |   | EEPROM |
>                           +-------+   +--------+
>  Mainboard                    |           |
> +------------+                |           |
> | controller |----------------+-----+-----+---....
> +------------+                      |
>                                     |
>                                     |
>                                  +------+
>                                  |      |
>    ...>--------------------------| MUX1 |----------------------<...
>                +-----------------|      |---------------+
>                |                 +------+               |
>                |                                        |
>                |                                        |
>                ^                                        ^
> Plugin1        |                          Plugin2       |
>             +------+                                +------+
>             |      |   +-------+                    |      |   +-------+
>         +---| MUX2 |---|  LM75 |                +---| MUX3 |---|  LM75 |
>         |   |      |   +-------+                |   |      |   +-------+
>         |   +------+                            |   +------+
>         |                                       |
>         |   +-------+                           |   +-------+
>         +---|  LM75 |                           +---|  LM75 |
>         |   +-------+                           |   +-------+
>         |                                       |
>         |   +--------+                          |   +--------+
>         +---| EEPROM |                          +---| EEPROM |
>         |   +--------+                          |   +--------+
>         |                                       |
> 

I don't quite get the point of MUX2 and MUX3.

> 
> The idea: when deferring the instantiation of the adapters of MUX1,
> there should be something like a hot-plug event.
> AFAIK, after adding an adapter via i2c_add_numbered_adapter(), the I2C
> subsystem will probe for all currently known clients on this new bus.
> Correct?
> If so, this should cascade through the newly plugged in board.

For I2C chip drivers which do device autodetection (lm75 and eeprom are
amongst them but for example at24 is not) yes. For other drivers (say
at24) there should be a board definition for the new i2c bus segment.
This might be a little difficult to implement with the traditional
i2c_register_board_info() due to the hotplug nature is not all plugins
have the same set of I2C chips. But some custom code using
i2c_new_device() should do.

> This defer could be implemented by removing auto instantiation (module
> parameter)

Auto instantiation only happens if the bus driver asks for it (through
an I2C_CLASS_* flag). If you don't want it, no need for a module
parameter, simply don't set any class flag.

> but adding a sysFs entry on MUX that does it on demand:
> #start controller 5
> echo 5 > /sys/bus/i2c/devices/1-0020/startAdapter
> #stop controller 5
> echo 5 > /sys/bus/i2c/devices/1-0020/stopAdapter
> 
> Any contradictions?

What are you trying to achieve? What is wrong with auto instantiation
as it is implemented today?

-- 
Jean Delvare