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