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

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

 



On Mon, Apr 27, 2009 at 11:07:46AM +0200, Wolfgang Grandegger wrote:
> Jon Smirl wrote:
> > On Fri, Apr 24, 2009 at 6:53 AM, Michael Lawnick <ml.lawnick@xxxxxx> wrote:
> >> Wolfram Sang said the following:
> >> ...
> >>>> Allowing only clients that are mentioned in DTS?
> >>> For now, yes. This is still the common case (=avoid probing). Until a
> >>> mainline solution comes up (which is needed, I agree on that), not so
> >>> common cases could simply patch the driver to add a .class field.
> >>>
> >> Especially it is ugly that devices which are mentioned in DTS but are
> >> not present (because the component isn't plugged in or powered) get an
> >> directory entry in /sys/bus/i2c/devices with bind, unbind, ...
> >> This is my 'problem': I search for a clean way to instantiate on demand
> >> with no zombies in case of missing H/W. I know there are problems in
> >> identification of devices, but to remove all possibilities to try it
> >> seems not a good way for me.
> > 
> > You might want to ask about this on the linux-ppc mailing list.
> > 
> > You're stuck because i2c hardware does not support hotplug. Since the
> > hardware doesn't support hotplug there's no software support for it in
> > the kernel. So you want to fall back to polled probing.
> > 
> > But probing is bad because it isn't standardized and coordinated, one
> > device's probe can cause another device to destroy things (like set a
> > voltage too high on a motherboard). Because of this probing can't be
> > turned on in general.
> 
> To decide if a device exists and responds at a specified I2C address, it
> would be sufficient to just read some data without causing trouble. Is
> that assumption correct or have I missed something? Trying to identify
> the device is a different issue and should be avoided.

It depends if you know what you are expecting to find there, due to
the limited addressing space used by i2c, a number of devices use the
same address and often do not have any indentification information.

Worse, doing a read of the chip requires knowing whether you need to
issue an register address or not, so this makes life even harder if
you are trying to do some form of autodetect.
 
> Wolfgang.
> --
> 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

-- 
Ben (ben@xxxxxxxxx, http://www.fluff.org/)

  'a smiley only costs 4 bytes'
--
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