[i2c] [patch 1/5] i2c stack can probe()

[David Brownell]

On Sunday 04 March 2007 3:54 am, Jean Delvare wrote:
> 
> Where sysfs isn't available, I'm fairly certain people won't need to
> declare i2c devices at runtime.

Likely true.


> > > This 
> > > pretty much means the impossibility to instantiate clients from
> > > user-space in the case where the chip type cannot be probed by the
> > > driver, while the whole point of allowing user-space to instantiate
> > > clients is exactly to workaround detection problems. So we have a
> > > problem here.
> > 
> > An issue to be addressed, sure.  How is it addressed right now?
> > Module parameters using all those arrays, yes?
> 
> Yeah. I hate them and I'm pretty certain you hate them too (or laugh at
> them, at your option). They were probably a nice trick back in 1999

I'm not so sure of that!


> when we supported 5 different hardware monitoring chips or so, but it
> just doesn't scale. I wanted to kill them some times ago already but
> Greg pointed out that it would go away by itself once we moved to the
> device driver model. Which, as you know, didn't quite happen (yet.)

Not quite ... :)

 

> > You misread my comments.  To get a bit more detailed, I originally
> > said "write i2c_board_info into a sysfs file", meaning all strings
> > much like you said.  Assume that file is called "new_chip", and then
> > matching those board_info fields with your example:
> > 
> > 	driver		- "lm90"
> > 	bus_num		- from the adapter
> > 	dev_addr	- 0x4c
> > 	platform_data	- "adm1032" (not a complex datum!!)
> > 	irq		- (unspecified)
> > 
> > I don't see any significant differences between what I sketched and
> > what you sketched.  Specifying an IRQ would be simple, though currently
> > I don't think hwmon uses them.
> 
> You're right, I somewhat misunderstood your original proposal sorry.

It happens.


> The above looks mostly OK then, with just the exception of the
> platform_data / device type part. By definition the format of the
> platform_data structure depends on the driver, while I believe we need
> an interface which is driver independent. Or would it be acceptable to
> wrap all the platform data inside a string, and it would be up to each
> driver to convert it to the relevant platform_data structure? I don't
> much like the idea that each driver would have to provide its own
> conversion function.

Me either.

 
> OTOH the PCI new_id syntax has room for a driver data integer those
> meaning is left to the driver, so maybe we can use a similar idea.

I'd feel safer saying that platform data is NULL going through such
sysfs paths, rather than take the risk that arbitrary integers get
abused as pointers.

 
> > It might be good to defend against such a userspace mechanism storing
> > bogus crap in platform_data; maybe that type info should be stored in
> > i2c_client.name instead.  Storing type information in platform_data is
> > clearly sufficient from the driver perspecive, but it might be easier
> > overall to add a type string to the board_info.  What do you think?
> 
> Yes, this reinforces my feeling that the device type should be a "core"
> attribute of the i2c device definition rather than an optional member
> of the platform_data structure. More on that in the other thread where
> we started discussing it.

My latest patch adds a "type" to the i2c_board_info, using it for
initialization of the i2c_client.name (type) field.

- Dave