On Tue, Mar 26, 2024 at 12:02:09PM -0500, Andrew Davis wrote: > On 3/26/24 11:19 AM, Robert Nelson wrote: > > On Tue, Mar 26, 2024 at 12:41 AM Greg Kroah-Hartman > > <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > > > > > > On Mon, Mar 25, 2024 at 04:00:45PM -0500, Andrew Davis wrote: > > > > This UIO driver was used to control the PRU processors found on various > > > > TI SoCs. It was created before the Remoteproc framework, but now with > > > > that we have a standard way to program and manage the PRU processors. > > > > The proper PRU Remoteproc driver should be used instead of this driver. > > > > Mark this driver deprecated. > > > > > > > > The userspace tools to use this are no longer available, so also remove > > > > those dead links from the Kconfig description. > > > > > > > > Signed-off-by: Andrew Davis <afd@xxxxxx> > > > > --- > > > > drivers/uio/Kconfig | 10 ++-------- > > > > 1 file changed, 2 insertions(+), 8 deletions(-) > > > > > > > > diff --git a/drivers/uio/Kconfig b/drivers/uio/Kconfig > > > > index 2e16c5338e5b1..358dc2d19b885 100644 > > > > --- a/drivers/uio/Kconfig > > > > +++ b/drivers/uio/Kconfig > > > > @@ -126,19 +126,13 @@ config UIO_FSL_ELBC_GPCM_NETX5152 > > > > http://www.hilscher.com/netx > > > > > > > > config UIO_PRUSS > > > > - tristate "Texas Instruments PRUSS driver" > > > > + tristate "Texas Instruments PRUSS driver (DEPRECATED)" > > > > > > This isn't going to do much, why not just delete the driver entirely if > > > no one uses it? > > > > CC'ing Matthijs one of our BeagleBoard community members who utilizes > > and supports UIO on a number of community projects. > > > > We know TI and Mainline in general do not like this UIO driver as it's > > very open-ended. > > > > While the remoteproc_pruss driver is now mainline (it has taken a long > > time, since 3.14.x i I think TI first started this..) > > > > There is a large user base of UIO examples that have been running > > since 3.8.x and as a community we have made sure ( mostly Matthijs ) > > that these continue to operate on this driver in > > v5.x/v6.x/lts/mainline branches. > > > > 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? thanks, greg k-h
