> > These users rely on out-of-tree patches to make this driver usable[0]. > > In its current state upstream, this driver is not used/usable. Since you > > have to make update patches anyway, why not simply carry the whole driver > > as an out-of-tree patch? > > > > That is why I was thinking of just marking it deprecated for a cycle > > or two, just to give one last hint that it will be going away soon > > (or you cancarry the driver out-of-tree for however long you want). > > No one notices "deprecated" stuff, they only notice if the code is > removed. So removing it is the only way to pay attention. > > But why are out-of-tree changes needed? If they are needed, why are > they not submitted for us to take so that it is usable by everyone? Or > is the out-of-tree patches also not supposed to be used? I saw Matthijs, did chime in, I'll wait for his full reply, we've been utilizing his knowledge on the pru subsystem to keep the uio driver alive with our out of tree patches. (and extending it to even newer TI am57xx devices, which TI didn't want us to do..) Looking at lore, Matt Porter originally had am335x support in the initial drop of uio when adding it to the DA850 family. https://lore.kernel.org/lkml/20121003150058.GB11180@beef/ I'll dig for his v3 to find the real reason on why it was later dropped. But at some point the remoteproc framework became the preferred method, so uio patches were not allowed.. (one IP block, two drivers.. Community vs TI/Mainline) Regards, -- Robert Nelson https://rcn-ee.com/
