linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ulf Hansson <ulf.hansson@linaro.org>
To: "H. Nikolaus Schaller" <hns@goldelico.com>
Cc: "Jérôme Pouiller" <Jerome.Pouiller@silabs.com>,
	"Avri Altman" <avri.altman@wdc.com>,
	"Shawn Lin" <shawn.lin@rock-chips.com>,
	"Linus Walleij" <linus.walleij@linaro.org>,
	"Tony Lindgren" <tony@atomide.com>,
	"Bean Huo" <beanhuo@micron.com>,
	notasas@gmail.com, linux-mmc@vger.kernel.org,
	linux-kernel@vger.kernel.org, letux-kernel@openphoenux.org,
	kernel@pyra-handheld.com
Subject: Re: [RFC v4 2/6] mmc: core: allow to match the device tree to apply quirks
Date: Mon, 8 Nov 2021 16:00:02 +0100	[thread overview]
Message-ID: <CAPDyKFo09xhaWbGgWuPa2=x0zXCfir0VMDhd4ZdSc8rh25nG9A@mail.gmail.com> (raw)
In-Reply-To: <7121F069-56C7-402C-BA82-A922B1A36587@goldelico.com>

On Sat, 6 Nov 2021 at 15:31, H. Nikolaus Schaller <hns@goldelico.com> wrote:
>
> Hi Jérôme,
>
> > Am 05.11.2021 um 15:27 schrieb Jérôme Pouiller <jerome.pouiller@silabs.com>:
> >
> > On Friday 5 November 2021 10:05:47 CET H. Nikolaus Schaller wrote:
> >> From: Jérôme Pouiller <jerome.pouiller@silabs.com>
> >>
> >> MMC subsystem provides a way to apply quirks when a device match some
> >> properties (VID, PID, etc...) Unfortunately, some SDIO devices does not
> >> comply with the SDIO specification and does not provide reliable VID/PID
> >> (eg. Silabs WF200).
> >>
> >> So, the drivers for these devices rely on device tree to identify the
> >> device.
> >>
> >> This patch allows the MMC to also rely on the device tree to apply a
> >> quirk.
> >>
> >> Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
> >
> > Thank you for to have taken care of that (Maybe, you would like to add a
> > "Co-developed-by:" tag).
>
> Well, I just have taken your and Ulf's proposal and done 90% copy&paste.
> So there wasn't much development, just editing...
>
> >
> >
> >> ---
> >> drivers/mmc/core/card.h   |  3 +++
> >> drivers/mmc/core/quirks.h | 17 +++++++++++++++++
> >> 2 files changed, 20 insertions(+)
> >>
> >> +static inline bool mmc_fixup_of_compatible_match(struct mmc_card *card,
> >> +                                                const char *const *compat_list)

After a second thought, I am not sure we really need a list of
compatibles here. The quirks we may want to apply should be specific
per device and most likely not shared among a family of devices, don't
you think?

> >> +{
> >> +       struct device_node *np;
> >> +
> >> +       for_each_child_of_node(mmc_dev(card->host)->of_node, np) {
> >> +               if (of_device_compatible_match(np, compat_list))
> >> +                       return true;
> >
> > Intel robot complains about of_device_compatible_match():
> >
> >    ERROR: modpost: "of_device_compatible_match" [drivers/mmc/core/mmc_core.ko] undefined!
> >
> > I think we have to add this line:
> >
> >    EXPORT_SYMBOL(of_device_compatible_match);
> >
> > in drivers/of/base.c

If we change to use one compatible string, rather than a list - then
we can use of_device_is_compatible() instead, which is already
properly exported with EXPORT_SYMBOL().

>
> I had seen the krobot message as well but could not figure out
> what it meant...
>
> But with your hint it indeed looks like an omission in drivers/of/base.c
> Having something exported in include/linux/of.h but code not
> marked EXPORT_SYMBOL...
>
> That needs a separate patch. I'll add one with a
>
> Reported-by: kernel test robot <lkp@intel.com>
> Reported-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
>
> and some Fixes: tag. Since it has a different audience I think
> I should post it separately.
>
> BTW: krobot noted the same issue for mmc_of_find_child_device()
> in drivers/mmc/core/core.c (which we do not touch in this series).
> But maybe it should be fixed as well.

If there is an existing problem, please send a separate fix/patch for that.

>
> So let's wait for more comments and then I may distribute a [PATCH v1].
> Or should I do a [PATCH v5] to continue version counting?

I suggest moving from RFC into using PATCH v1, as this isn't really an
RFC any more.

>
> BR,
> Nikolaus
>

Kind regards
Uffe

  reply	other threads:[~2021-11-08 15:00 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-05  9:05 [RFC v4 0/6] mmc: core: extend mmc_fixup_device and transplant ti,wl1251 quirks from to be retired omap_hsmmc H. Nikolaus Schaller
2021-11-05  9:05 ` [RFC v4 1/6] mmc: core: rewrite mmc_fixup_device() H. Nikolaus Schaller
2021-11-05  9:05 ` [RFC v4 2/6] mmc: core: allow to match the device tree to apply quirks H. Nikolaus Schaller
2021-11-05 14:27   ` Jérôme Pouiller
2021-11-06 14:31     ` H. Nikolaus Schaller
2021-11-08 15:00       ` Ulf Hansson [this message]
2021-11-08 15:34         ` Jérôme Pouiller
2021-11-08 16:01           ` H. Nikolaus Schaller
2021-11-05  9:05 ` [RFC v4 3/6] mmc: core: provide macro and table " H. Nikolaus Schaller
2021-11-05  9:05 ` [RFC v4 4/6] mmc: core: add new calls to mmc_fixup_device(sdio_card_init_methods) H. Nikolaus Schaller
2021-11-08 15:08   ` Ulf Hansson
2021-11-08 16:07     ` H. Nikolaus Schaller
2021-11-08 15:39   ` Jérôme Pouiller
2021-11-08 16:04     ` H. Nikolaus Schaller
2021-11-05  9:05 ` [RFC v4 5/6] mmc: core: transplant ti,wl1251 quirks from to be retired omap_hsmmc H. Nikolaus Schaller
2021-11-08 15:33   ` Ulf Hansson
2021-11-08 16:08     ` H. Nikolaus Schaller
2021-11-09 10:58     ` H. Nikolaus Schaller
2021-11-09 20:01       ` Ulf Hansson
2021-11-10 16:36         ` H. Nikolaus Schaller
2021-11-10 17:03           ` Ulf Hansson
2021-11-10 17:09             ` H. Nikolaus Schaller
2021-11-05  9:05 ` [RFC v4 6/6] mmc: host: omap_hsmmc: revert special init for wl1251 H. Nikolaus Schaller

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='CAPDyKFo09xhaWbGgWuPa2=x0zXCfir0VMDhd4ZdSc8rh25nG9A@mail.gmail.com' \
    --to=ulf.hansson@linaro.org \
    --cc=Jerome.Pouiller@silabs.com \
    --cc=avri.altman@wdc.com \
    --cc=beanhuo@micron.com \
    --cc=hns@goldelico.com \
    --cc=kernel@pyra-handheld.com \
    --cc=letux-kernel@openphoenux.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=notasas@gmail.com \
    --cc=shawn.lin@rock-chips.com \
    --cc=tony@atomide.com \
    /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).