From: Scott Wood <oss@buserror.net>
To: 王文虎 <wenhu.wang@vivo.com>, "Rob Herring" <robh@kernel.org>
Cc: gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org,
christophe.leroy@c-s.fr, linuxppc-dev@lists.ozlabs.org,
kernel@vivo.com
Subject: Re: [PATCH v4,4/4] drivers: uio: new driver for fsl_85xx_cache_sram
Date: Thu, 16 Apr 2020 23:58:29 -0500 [thread overview]
Message-ID: <64bb1f056abd8bfab2befef5d1e6baec2056077f.camel@buserror.net> (raw)
In-Reply-To: <ANcAoADRCKKtO5p9r33Ll4og.3.1587090694317.Hmail.wenhu.wang@vivo.com>
On Fri, 2020-04-17 at 10:31 +0800, 王文虎 wrote:
> > > On Thu, 2020-04-16 at 08:35 -0700, Wang Wenhu wrote:
> > > > +#define UIO_INFO_VER "devicetree,pseudo"
> > >
> > > What does this mean? Changing a number into a non-obvious string (Why
> > > "pseudo"? Why does the UIO user care that the config came from the
> > > device
> > > tree?) just to avoid setting off Greg's version number autoresponse
> > > isn't
> > > really helping anything.
> > >
> > > > +static const struct of_device_id uio_mpc85xx_l2ctlr_of_match[] = {
> > > > + { .compatible = "uio,mpc85xx-cache-sram", },
> >
> > Form is <vendor>,<device> and "uio" is not a vendor (and never will be).
> >
>
> Should have been something like "fsl,mpc85xx-cache-sram-uio", and if it is
> to be defined with module parameters, this would be user defined.
> Anyway, <vendor>,<device> should always be used.
>
> > > > + {},
> > > > +};
> > > > +
> > > > +static struct platform_driver uio_fsl_85xx_cache_sram = {
> > > > + .probe = uio_fsl_85xx_cache_sram_probe,
> > > > + .remove = uio_fsl_85xx_cache_sram_remove,
> > > > + .driver = {
> > > > + .name = DRIVER_NAME,
> > > > + .owner = THIS_MODULE,
> > > > + .of_match_table = uio_mpc85xx_l2ctlr_of_match,
> > > > + },
> > > > +};
> > >
> > > Greg's comment notwithstanding, I really don't think this belongs in the
> > > device tree (and if I do get overruled on that point, it at least needs
> > > a
> > > binding document). Let me try to come up with a patch for dynamic
> > > allocation.
> >
> > Agreed. "UIO" bindings have long been rejected.
> >
>
> Sounds it is. And does the modification below fit well?
> ---
> -static const struct of_device_id uio_mpc85xx_l2ctlr_of_match[] = {
> - { .compatible = "uio,mpc85xx-cache-sram", },
> - {},
> +#ifdef CONFIG_OF
> +static struct of_device_id uio_fsl_85xx_cache_sram_of_match[] = {
> + { /* This is filled with module_parm */ },
> + { /* Sentinel */ },
> };
> +MODULE_DEVICE_TABLE(of, uio_fsl_85xx_cache_sram_of_match);
> +module_param_string(of_id, uio_fsl_85xx_cache_sram_of_match[0].compatible,
> + sizeof(uio_fsl_85xx_cache_sram_of_match[0].compa
> tible), 0);
> +MODULE_PARM_DESC(of_id, "platform device id to be handled by cache-sram-
> uio");
> +#endif
No. The point is that you wouldn't be configuring this with the device tree
at all.
-Scott
next prev parent reply other threads:[~2020-04-17 5:00 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-16 15:35 [PATCH v4,0/4] drivers: uio: new driver uio_fsl_85xx_cache_sram Wang Wenhu
2020-04-16 15:35 ` [PATCH v4,1/4] powerpc: sysdev: fix compile error for fsl_85xx_l2ctlr Wang Wenhu
2020-04-16 15:45 ` Christophe Leroy
2020-04-16 15:35 ` [PATCH v4,2/4] powerpc: sysdev: fix compile error for fsl_85xx_cache_sram Wang Wenhu
2020-04-16 15:45 ` Christophe Leroy
2020-04-16 15:35 ` [PATCH v4,3/4] powerpc: sysdev: fix compile warning " Wang Wenhu
2020-04-16 15:46 ` Christophe Leroy
2020-04-16 15:35 ` [PATCH v4,4/4] drivers: uio: new driver " Wang Wenhu
2020-04-16 15:43 ` Christophe Leroy
2020-04-16 19:59 ` Scott Wood
2020-04-16 21:35 ` Rob Herring
2020-04-17 2:31 ` 王文虎
2020-04-17 4:58 ` Scott Wood [this message]
2020-04-17 7:04 ` 王文虎
2020-04-17 7:42 ` Greg KH
2020-04-17 9:17 ` Scott Wood
2020-04-17 14:16 ` 王文虎
2020-04-17 22:50 ` Scott Wood
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=64bb1f056abd8bfab2befef5d1e6baec2056077f.camel@buserror.net \
--to=oss@buserror.net \
--cc=christophe.leroy@c-s.fr \
--cc=gregkh@linuxfoundation.org \
--cc=kernel@vivo.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=robh@kernel.org \
--cc=wenhu.wang@vivo.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).