Messages in this thread | | | From | Scott Wood <> | Date | Wed, 15 Apr 2020 14:26:55 -0500 | Subject | Re: [PATCH v2,5/5] drivers: uio: new driver for fsl_85xx_cache_sram |
| |
On Wed, 2020-04-15 at 08:24 -0700, Wang Wenhu wrote: > +static const struct of_device_id uio_mpc85xx_l2ctlr_of_match[] = { > + { .compatible = "uio,fsl,p2020-l2-cache-controller", }, > + { .compatible = "uio,fsl,p2010-l2-cache-controller", }, > + { .compatible = "uio,fsl,p1020-l2-cache-controller", }, > + { .compatible = "uio,fsl,p1011-l2-cache-controller", }, > + { .compatible = "uio,fsl,p1013-l2-cache-controller", }, > + { .compatible = "uio,fsl,p1022-l2-cache-controller", }, > + { .compatible = "uio,fsl,mpc8548-l2-cache-controller", }, > + { .compatible = "uio,fsl,mpc8544-l2-cache-controller", }, > + { .compatible = "uio,fsl,mpc8572-l2-cache-controller", }, > + { .compatible = "uio,fsl,mpc8536-l2-cache-controller", }, > + { .compatible = "uio,fsl,p1021-l2-cache-controller", }, > + { .compatible = "uio,fsl,p1012-l2-cache-controller", }, > + { .compatible = "uio,fsl,p1025-l2-cache-controller", }, > + { .compatible = "uio,fsl,p1016-l2-cache-controller", }, > + { .compatible = "uio,fsl,p1024-l2-cache-controller", }, > + { .compatible = "uio,fsl,p1015-l2-cache-controller", }, > + { .compatible = "uio,fsl,p1010-l2-cache-controller", }, > + { .compatible = "uio,fsl,bsc9131-l2-cache-controller", }, > + {}, > +};
NACK
The device tree describes the hardware, not what driver you want to bind the hardware to, or how you want to allocate the resources. And even if defining nodes for sram allocation were the right way to go, why do you have a separate compatible for each chip when you're just describing software configuration?
Instead, have module parameters that take the sizes and alignments you'd like to allocate and expose to userspace. Better still would be some sort of dynamic allocation (e.g. open a fd, ioctl to set the requested size/alignment, if it succeeds you can mmap it, and when the fd is closed the region is freed).
-Scott
| |