Re: [Patch] MPC Adapter: read class attribute from device tree

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Apr 21, 2009 at 12:33 PM, Jean Delvare <khali@xxxxxxxxxxxx> wrote:
> On Tue, 21 Apr 2009 12:00:02 -0400, Jon Smirl wrote:
>> On Tue, Apr 21, 2009 at 10:11 AM, Michael Lawnick <ml.lawnick@xxxxxx> wrote:
>> > Jean Delvare said the following:
>> >> You apparently still have a hard time differentiating between devices
>> >> and drivers. Loading modules at runtime != instantiating devices at
>> >> runtime.
>> >>
>> > Well, till now I assumed that you can't instantiate a device who's
>> > driver isn't loaded. But I am eager to learn.
>> >
>> >> (And both can be done, but if you can't define your needs, we won't go
>> >> very far.)
>> >
>> > I thought I had explained very often. I'll do it once again:
>> > We load drivers at runtime directly after boot which does automatic
>> > instantiation. There will occur further devices on bus after some time
>> > (hotplug) and therefore we need later on instantiation without reloading
>> > drivers. We cannot define which devices will exactly be plugged in, it
>> > might even be possible that on same bus address there occur different
>> > devices (as an possible option and not at same time of course). So
>> > device detection is highly appreciated.
>> > Do you need more info?
>>
>> Jean, haven't you told me multiple times that hotplug doesn't work for
>> i2c? How can you tell when a new device has been added to an i2c bus?
>
> I did say so, and I maintain this assertion. Warm-plug, on the other
> hand, could be supported (but isn't yet.) By warm-plug, I mean: switch
> off one "channel" of a multiplexer, add one chip to that segment, and
> enable the channel again. Once we have multiplexing support, this
> should be doable, if we implement the proper interface. But this really
> is per-segment, not per-device.
>
> Of course this can never be hot-plug like e.g. USB has it: you're not
> going to get a signal when a new I2C device is connected. This has to
> be a partly manual process, where you tell the system that a new I2C
> segment is available, and that the usual rules (per-board instantiation
> or device detection) have to be applied.

So a solution might lie down the path of having whatever catches the
hotplug event (pci, usb, ..) run code that modifies the device tree
and inserts the new i2c nodes. After the device tree has been modified
trigger a rescan of devices so that the i2c drivers get loaded.  I've
never tried doing that but it should be doable in theory.

Something has to trigger an interrupt (or the user types a command)
indicating that new hardware has been added. The driver of that device
can modify the device tree. The rescan of the device tree will cause
the i2c modules to automatically load. This shouldn't require any
changes to the current i2c sub-system.



>
>> There is already code in the kernel that will dynamically load the
>> correct i2c device drivers based on the device tree. The i2c drivers
>> don't need to be build into the kernel. Just put drivers for all of
>> your devices onto the initrd.
>
> --
> Jean Delvare
>



-- 
Jon Smirl
jonsmirl@xxxxxxxxx
--
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

[Index of Archives]     [Linux GPIO]     [Linux SPI]     [Linux Hardward Monitoring]     [LM Sensors]     [Linux USB Devel]     [Linux Media]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux