linux-i2c.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Javier Martinez Canillas <javier-0uQlZySMnqxg9hUCZPvPmw@public.gmane.org>
To: Wolfram Sang <wsa-z923LK4zBo2bacvFa/9K2g@public.gmane.org>
Cc: Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
	"devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	kernel-F5mvAk5X5gdBDgjK7y7TUQ@public.gmane.org,
	Linus Walleij
	<linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
	Linux Kernel
	<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Grant Likely
	<grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
	"linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
	<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
	Sjoerd Simons
	<sjoerd.simons-ZGY8ohtN/8pPYcu2f3hruQ@public.gmane.org>
Subject: Re: [PATCH RESEND 0/8] i2c: Relax mandatory I2C ID table passing
Date: Fri, 12 Sep 2014 19:32:22 +0200	[thread overview]
Message-ID: <CABxcv==OXd+uePcB8zDzB-DDmr9ci6zscHX5TCauWoTO6E4fpg@mail.gmail.com> (raw)
In-Reply-To: <20140912134632.GE1930@katana>

[adding Sjoerd as cc who was the one that raised the module auto-loading issue]

Hello,

On Fri, Sep 12, 2014 at 3:46 PM, Wolfram Sang <wsa-z923LK4zBo2bacvFa/9K2g@public.gmane.org> wrote:
>>
>> Placing this firmly back on your plate.  I truly hope we don't miss
>> another merge-window.  This patch-set has the support of some pretty
>> senior kernel maintainers, so I hope acceptance shouldn't be too
>> difficult.
>>
>> As previously discussed I believe it should be okay for an I2C device
>> driver _not_ supply an I2C ID table to match to.  The I2C subsystem
>> should be able to match via other means, such as via OF tables.  The
>> blocking factor during our previous conversation was to keep
>> registering via sysfs up and running.  This set does that.
>
> As mentioned in another thread, modaliases are one other possible side
> effect. As Javier correctly mentions, the beaviour does not really
> change with your patchset. Yet, if we remove i2c_device_id from drivers
> too carelessly, they might not be bound anymore.
>

Right, removing the I2C ID table even from drivers that don't really
need it (e.g: IP blocks only present in DT platforms) will as you said
break module auto-loading. Probing will work since the OF table is
used to match the device in i2c_device_match() but is the I2C table
what is used to fill the valid module aliases with the current
behavior of i2c_device_uevent(), the aliases filled from the OF table
are never used.

So what I propose is to do it incrementally:

1) Merge Lee's series since that is definitely a step in the right
direction to not make an I2C table mandatory (still will be needed for
module auto loading though).

2) On a follow-up series, make sure that all I2C drivers have a proper
OF table and that are using the MODULE_DEVICE_TABLE(of,...) macro to
fill the of:<foo> module aliases. That way the modules will have the
proper aliases of the form "of:<foo>" besides the "i2c:<foo>" one.
(even when always i2c:<foo> is reported to user-space currently).

3) Apply the patch I posted [0] that changes the behavior of
i2c_device_uevent() to report the OF uevent env vars to user-space in
case of DT probing which after 2) should not regress any driver module
auto-loading since all drivers should fill the of:<foo> aliases.

After this, DT-only drivers will only need an OF table and legacy
drivers will only need an I2C table. Drivers that support both will
still need the two tables though which is a drawback of this approach
since unnecessary duplication will exist on these drivers and can
cause issues when both tables are not in sync as we saw on the issue
reported by Sjoerd on [1].

So an alternate approach could be to do the opposite, just remove the
OF tables entirely from the I2C drivers and only use the I2C table
even for DT-only drivers. This is possible since i2c_device_match()
will succeed even without an OF table because i2c_match_id() matches
for compatible strings and what is reported as uevent is what is in
the I2C table anyways. I believe that is what Sjoerd suggested but
I'll let him comment on that in case I misunderstood.

By the way, the SPI subsystem has the same behavior, I raised the issue on [2].

Best regards,
Javier

[0]: https://lkml.org/lkml/2014/9/11/269
[1]: https://lkml.org/lkml/2014/9/9/100
[2]: https://lkml.org/lkml/2014/9/11/458

  reply	other threads:[~2014-09-12 17:32 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-28 14:35 [PATCH RESEND 0/8] i2c: Relax mandatory I2C ID table passing Lee Jones
2014-08-28 14:35 ` [PATCH 1/8] i2c: Add pointer dereference protection to i2c_match_id() Lee Jones
2014-08-28 14:35 ` [PATCH 3/8] i2c: Match using traditional OF methods, then by vendor-less compatible strings Lee Jones
2014-08-28 14:35 ` [PATCH 4/8] i2c: Make I2C ID tables non-mandatory for DT'ed devices Lee Jones
2014-08-28 14:35 ` [PATCH 6/8] i2c: Provide a temporary .probe2() call-back type Lee Jones
     [not found]   ` <1409236538-21274-7-git-send-email-lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2014-09-12 13:50     ` Wolfram Sang
2014-08-28 14:35 ` [PATCH 7/8] mfd: 88pm860x: Move over to new I2C device .probe() call Lee Jones
     [not found] ` <1409236538-21274-1-git-send-email-lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2014-08-28 14:35   ` [PATCH 2/8] i2c: Add the ability to match device to compatible string without an of_node Lee Jones
2014-09-12 13:46     ` Wolfram Sang
2014-08-28 14:35   ` [PATCH 5/8] i2c: Export i2c_match_id() for direct use by device drivers Lee Jones
2014-08-28 14:35   ` [PATCH 8/8] mfd: as3722: Rid driver of superfluous I2C device ID structure Lee Jones
2014-08-29  8:45   ` [PATCH RESEND 0/8] i2c: Relax mandatory I2C ID table passing Wolfram Sang
2014-08-29  8:58     ` Lee Jones
2014-09-12 13:46   ` Wolfram Sang
2014-09-12 17:32     ` Javier Martinez Canillas [this message]
2014-09-15 22:46       ` Lee Jones
2014-09-16  8:00         ` Javier Martinez Canillas

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='CABxcv==OXd+uePcB8zDzB-DDmr9ci6zscHX5TCauWoTO6E4fpg@mail.gmail.com' \
    --to=javier-0uqlzysmnqxg9huczpvpmw@public.gmane.org \
    --cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
    --cc=kernel-F5mvAk5X5gdBDgjK7y7TUQ@public.gmane.org \
    --cc=lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
    --cc=linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
    --cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
    --cc=linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=sjoerd.simons-ZGY8ohtN/8pPYcu2f3hruQ@public.gmane.org \
    --cc=wsa-z923LK4zBo2bacvFa/9K2g@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).