linux-i2c.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Kay Sievers <kay.sievers-tD+1rO4QERM@public.gmane.org>
To: Jean Delvare <khali-PUYAD+kWke1g9hUCZPvPmw@public.gmane.org>
Cc: Linux I2C <linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: [PATCH] i2c: Do not give adapters a default parent
Date: Sun, 5 Jul 2009 22:19:46 +0200	[thread overview]
Message-ID: <ac3eb2510907051319i414a5e78r74d623ebb0508d0@mail.gmail.com> (raw)
In-Reply-To: <20090704191431.3d352d0b-ig7AzVSIIG7kN2dkZ6Wm7A@public.gmane.org>

On Sat, Jul 4, 2009 at 19:14, Jean Delvare<khali-PUYAD+kWke1g9hUCZPvPmw@public.gmane.org> wrote:
> On Mon, 4 May 2009 14:40:36 +0200, Kay Sievers wrote:

>> (The less difference between classes and buses the better. It is wrong
>> to have two types of subsystems, doing almost the same thing. One
>> could argue that it could be useful inside the kernel, which it isn't,
>> I think, but exporting them to userspace was definitely the wrong
>> thing.)
>
> I finally took a stab at this. The resulting patch is below. I have
> used device_type to differentiate between I2C clients and I2C adapters.
> Is this what you had in mind?

Looks fine, by just looking at the patch.

> It seems to work reasonably well, with the following issues remaining:
>
> * The change breaks at least sensors-detect and libsensors. I can
>  easily modify them so that they work again, but we still have a
>  compatibility issue. Is it possible to have a compatibility option
>  that would add symbolic links from class/i2c-adapter/i2c-* to
>  bus/i2c/devices/i2c-* for a couple years?

Yeah, we can add that. I guess others will need that too, if we
convert things from class to bus. How would that look like? Like a
device_add_class_compat_link(*dev, *class)?

> * Now that i2c-core makes use of device_type, I tried to move the power
>  management handling callbacks there from bus_type, to save a test in
>  each function, however I found that the callback set is different
>  between bus_type and device_type.pm. Why is it so? Is there a document
>  explaining the difference? Is the whole world (including bus_type)
>  eventually moving to dev_pm_ops?

I think this is already removed in the current git tree, and all
should use dev_pm_ops, yes.

> * When i2c-adapters were class devices, virtual ones (for example
>  i2c-stub) appeared in sysfs as devices/virtual/i2c-adapter/i2c-*,
>  which made sense and seemed safe. Now that I have turned them into
>  bus devices, virtual ones appear in sysfs as devices/i2c-* directly,
>  which looks dirty and could result in collisions someday. What should
>  be done about this? I wanted to use virtual_device_parent() but it is
>  internal to the driver core at the moment, and doesn't even exist if
>  CONFIG_SYSFS_DEPRECATED=y.

Yeah, we just need to apply the /sys/devices/virtual logic to bus
devices too, it's currently limited to class devices, because there
was no bus device so far who needed this, but should be an easy
change.

> I would be grateful if you can advise on any of the above points.

If you decide to do it that way, you would need the driver core to be able:
  - to create a link from an otherwise empty "struct class" to an
existing bus-device
  - put bus devices without a parent into the /sys/devices/virtual logic
right? Let me know, I can look into that, if you need that.

Thanks,
Kay

  parent reply	other threads:[~2009-07-05 20:19 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-26  8:30 [PATCH] i2c: Warn when adapters have no parent Jean Delvare
     [not found] ` <20090426103025.4525edd3-ig7AzVSIIG7kN2dkZ6Wm7A@public.gmane.org>
2009-05-04 10:43   ` [PATCH] i2c: Do not give adapters a default parent Jean Delvare
     [not found]     ` <20090504124341.42405e79-ig7AzVSIIG7kN2dkZ6Wm7A@public.gmane.org>
2009-05-04 12:40       ` Kay Sievers
     [not found]         ` <ac3eb2510905040540k65afe3f8k7e6c696d11bf7e1d-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2009-07-04 17:14           ` Jean Delvare
     [not found]             ` <20090704191431.3d352d0b-ig7AzVSIIG7kN2dkZ6Wm7A@public.gmane.org>
2009-07-05 20:19               ` Kay Sievers [this message]
     [not found]                 ` <ac3eb2510907051319i414a5e78r74d623ebb0508d0-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2009-07-05 20:56                   ` Jean Delvare
     [not found]                     ` <20090705225616.1d4817e7-ig7AzVSIIG7kN2dkZ6Wm7A@public.gmane.org>
2009-07-05 21:34                       ` Kay Sievers
     [not found]                         ` <ac3eb2510907051434i4ee351cbk3db17b50c7e7618b-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2009-07-22 19:07                           ` Jean Delvare
     [not found]                             ` <20090722210753.35802816-ig7AzVSIIG7kN2dkZ6Wm7A@public.gmane.org>
2009-07-22 21:04                               ` Kay Sievers
     [not found]                                 ` <1248296688.2065.4.camel-2/CBIq5w30c@public.gmane.org>
2009-07-23 14:02                                   ` Jean Delvare
     [not found]                                     ` <20090723160259.78a10e37-ig7AzVSIIG7kN2dkZ6Wm7A@public.gmane.org>
2009-07-23 15:19                                       ` Kay Sievers
     [not found]                                         ` <ac3eb2510907230819g1b8edf63g42ffc4c87dbc0cb5-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2009-07-28 12:47                                           ` Jean Delvare
     [not found]                                             ` <20090728144755.69d328d4-ig7AzVSIIG7kN2dkZ6Wm7A@public.gmane.org>
2009-07-30 15:12                                               ` Kay Sievers
     [not found]                                                 ` <ac3eb2510907300812q2d848108ofe1d25801f7b990f-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2009-08-04 10:55                                                   ` Jean Delvare
     [not found]                                                     ` <20090804125534.6a555cc2-ig7AzVSIIG7kN2dkZ6Wm7A@public.gmane.org>
2009-08-05  2:20                                                       ` Kay Sievers

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=ac3eb2510907051319i414a5e78r74d623ebb0508d0@mail.gmail.com \
    --to=kay.sievers-td+1ro4qerm@public.gmane.org \
    --cc=khali-PUYAD+kWke1g9hUCZPvPmw@public.gmane.org \
    --cc=linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).