From: Michael Lawnick <ml.lawnick@gmx.de>
To: lm-sensors@vger.kernel.org
Subject: Re: [lm-sensors] [PATCH v3] hwmon: lm75: Add __devinit and
Date: Mon, 13 Sep 2010 12:18:08 +0000 [thread overview]
Message-ID: <4C8E1680.4000401@gmx.de> (raw)
In-Reply-To: <1284365862-20438-1-git-send-email-shubhrajyoti@ti.com>
Datta, Shubhrajyoti said the following:
>
>
>> -----Original Message-----
>> From: Michael Lawnick [mailto:ml.lawnick@gmx.de]
>> Sent: Monday, September 13, 2010 4:42 PM
>> To: Datta, Shubhrajyoti
>> Cc: lm-sensors@lm-sensors.org
>> Subject: Re: [lm-sensors] [PATCH v3] hwmon: lm75: Add __devinit and
>> __devexit section initializers
>>
>> Datta, Shubhrajyoti said the following:
>> >
>> >
>> >> -----Original Message-----
>> >> From: Michael Lawnick [mailto:ml.lawnick@gmx.de]
>> >> Sent: Monday, September 13, 2010 2:52 PM
>> >> To: Datta, Shubhrajyoti
>> >> Cc: lm-sensors@lm-sensors.org
>> >> Subject: Re: [lm-sensors] [PATCH v3] hwmon: lm75: Add __devinit and
>> >> __devexit section initializers
>> >>
>> >> Shubhrajyoti D said the following:
>> >> ...
>> >>
>> >> > -static int
>> >> > +static int __devinit
>> >> > lm75_probe(struct i2c_client *client, const struct i2c_device_id
>> *id)
>> >> Are you sure?
>> >> If I understand correctly, this function will be thrown away after
>> >> system/module init. But what's about devices that are added later?
>> >> I would expect them to crash on init...
>> > As all of these are I2C devices are I2C I thought it makes sense.
>> > Are you aware of devices that can be plugged/wired runtime?
>>
>> Almost all if behind a multiplexer ;-)
> I missed this part.
There even exist multiplexer that check the bus state and allow
connection only within stop<->start phases.
>
>> There is just some care in synchronization needed.
>> We are currently working with such a system that dynamically adds buses
>> and drops them again (triggered by hotplug).
> Does it mean that all the existing drivers need to adapt.
I expect them to get adapted step by step when/if this really becomes an
issue. Maybe someday a general cleanup will necessary (and done). Anyway
this might be already an issue for hot plugged cards (e.g. a compact PCI
TV card) that has a local i2c adapter on and common devices on its local
bus. But either this scenario does not exist in practical life or was
fixed by a local code fix.
--
KR
Michael
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
next prev parent reply other threads:[~2010-09-13 12:18 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-13 8:29 [lm-sensors] [PATCH v3] hwmon: lm75: Add __devinit and __devexit Shubhrajyoti D
2010-09-13 9:22 ` [lm-sensors] [PATCH v3] hwmon: lm75: Add __devinit and Michael Lawnick
2010-09-13 10:52 ` Datta, Shubhrajyoti
2010-09-13 11:12 ` Michael Lawnick
2010-09-13 11:46 ` Datta, Shubhrajyoti
2010-09-13 12:18 ` Michael Lawnick [this message]
2010-09-13 14:49 ` Guenter Roeck
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4C8E1680.4000401@gmx.de \
--to=ml.lawnick@gmx.de \
--cc=lm-sensors@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.