Messages in this thread | | | Date | Thu, 16 Apr 2020 16:35:35 -0500 | From | Rob Herring <> | Subject | Re: [PATCH v4,4/4] drivers: uio: new driver for fsl_85xx_cache_sram |
| |
On Thu, Apr 16, 2020 at 02:59:36PM -0500, Scott Wood 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).
> > + {}, > > +}; > > + > > +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.
Rob
| |