Re: [PATCH v4,4/4] drivers: uio: new driver for fsl_85xx_cache_sram

From: Greg KH
Date: Fri Apr 17 2020 - 03:42:34 EST


On Thu, Apr 16, 2020 at 11:58:29PM -0500, Scott Wood wrote:
> 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.

Wait, why not? Don't force people to use module parameters, that is
crazy. DT describes the hardware involved, if someone wants to bind to
a specific range of memory, as described by DT, why can't they do so?

I can understand not liking the name "uio" in a dt tree, but there's no
reason that DT can not describe what a driver binds to here.

Remember, module parameters are NEVER the answer, this isn't the 1990's
anymore.

thanks,

greg k-h