Re: [PATCH] uio: pruss: Deprecate use of this driver

[Andrew Davis]

On 3/26/24 12:12 PM, Greg Kroah-Hartman wrote:
> 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.

Easy enough, will remove completely for v2.

> 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?

The out-of-tree patches should not be used and are only for backwards
compatibility with folks who have not updated to using the proper
remoteproc/rpmsg driver for PRU. Removing this driver would normally
be a userspace break (which we should obviously avoid), but since
the ability to actually use this driver never made it fully upstream
I see no issue.

And we shouldn't try to now upstream the full usable support for this
UIO driver at this point as we have a proper kernel driver for this hardware
upstream now.

(I'd argue most of UIO should not be used as it ends up just being a
hacky way to avoid writing proper kernel drivers for hardware, but that
is a different topic :))

Andrew

> thanks,
>
> greg k-h