All of lore.kernel.org
 help / color / mirror / Atom feed
From: Masahiro Yamada <yamada.masahiro@socionext.com>
To: Wolfram Sang <wsa@the-dreams.de>
Cc: Javier Martinez Canillas <javierm@redhat.com>,
	Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>,
	Michal Marek <michal.lkml@markovi.net>,
	Linux Kbuild mailing list <linux-kbuild@vger.kernel.org>,
	open list <linux-kernel@vger.kernel.org>,
	Linux-Renesas <linux-renesas-soc@vger.kernel.org>,
	Lee Jones <lee.jones@linaro.org>,
	Alexandre Belloni <alexandre.belloni@bootlin.com>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	Mark Brown <broonie@kernel.org>
Subject: Re: [PATCH RFC] modpost: Support I2C Aliases from OF tables
Date: Thu, 1 Aug 2019 11:17:32 +0900	[thread overview]
Message-ID: <CAK7LNAQ6siWHU+N2c+6gqh7hHEJ_aDrVoiWnrTq1jiXQWSYYBA@mail.gmail.com> (raw)
In-Reply-To: <20190731194419.GB4084@kunai>

Hi.

On Thu, Aug 1, 2019 at 4:44 AM Wolfram Sang <wsa@the-dreams.de> wrote:
>
> Hi Javier,
>
> thank you for providing the extra information.
>
> (And Kieran, thanks for the patch!)
>
> > The other option is to remove i2c_of_match_device() and don't make OF match
> > to fallback to i2c_of_match_device_sysfs(). This is what happens in the ACPI
> > case, since i2c_device_match() just calls acpi_driver_match_device() directly
> > and doesn't have a wrapper function that fallbacks to sysfs matching.
> >
> > In this case an I2C device ID table would be required if the devices have to
> > be instantiated through sysfs. That way the I2C table would be used both for
> > auto-loading and also to match the device when it doesn't have an of_node.
>
> That would probably mean that only a minority of drivers will not add an I2C
> device ID table because it is easy to add an you get the sysfs feature?
>
> Then we are back again with the situation that most drivers will have
> multiple tables. With the minor change that the I2C device id table is
> not required anymore by the core, but it will be just very useful to
> have? Or?
>
> > If the former is the correct way to solve this then the patch looks good to me.
> >
> > Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
>
> For this actual patch from Kieran, I'd like to hear an opinion from the
> people maintaining modpost.


As you see 'git log scripts/mod/file2alias.c',
this file is touched by every subsystem.

So, the decision is up to you, Wolfram.
And, you can pick this to your tree if you like.


The implementation is really trivial.


As Javier pointed out, this discussion comes down to
"do we want to fall back to i2c_of_match_device_sysfs()?"

If a driver supports DT and devices are instantiated via DT,
in which situation is this useful?
Do legacy non-DT platforms need this?



> The aproach looks okay to me, yet I can't
> tell how "easy" we are with adding new types like 'i2c_of'.

As far as I understood, this patch provides a shorthand.
You can save one table, but still get the
same MODULE_ALIAS in the *.mod.c file.
You need to add two MODULE_DEVICE_TABLE() though.

MODULE_DEVICE_TABLE(of, si4713_of_match);
MODULE_DEVICE_TABLE(i2c_of, si4713_of_match);


-- 
Best Regards
Masahiro Yamada

  reply	other threads:[~2019-08-01  2:18 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-10 19:39 [PATCH RFC] modpost: Support I2C Aliases from OF tables Kieran Bingham
2019-07-10 19:39 ` Kieran Bingham
2019-07-22 13:03 ` Javier Martinez Canillas
2019-07-31 19:44   ` Wolfram Sang
2019-08-01  2:17     ` Masahiro Yamada [this message]
2019-08-05 22:48       ` Javier Martinez Canillas
2019-08-06  7:30         ` Geert Uytterhoeven
2019-08-06 17:39           ` Javier Martinez Canillas
2019-08-05 22:25     ` Javier Martinez Canillas
2019-08-06  7:22       ` Geert Uytterhoeven
2019-08-06 17:12         ` Javier Martinez Canillas
2019-08-08 13:12           ` Enrico Weigelt, metux IT consult
2019-08-08 13:24             ` Andy Shevchenko
2019-08-08 14:00               ` Enrico Weigelt, metux IT consult

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=CAK7LNAQ6siWHU+N2c+6gqh7hHEJ_aDrVoiWnrTq1jiXQWSYYBA@mail.gmail.com \
    --to=yamada.masahiro@socionext.com \
    --cc=alexandre.belloni@bootlin.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=broonie@kernel.org \
    --cc=javierm@redhat.com \
    --cc=kieran.bingham+renesas@ideasonboard.com \
    --cc=lee.jones@linaro.org \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=michal.lkml@markovi.net \
    --cc=wsa@the-dreams.de \
    /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.