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

[Andrew Davis]

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).

Andrew

[0] https://github.com/beagleboard/linux/commit/d5a2815173b26095fa469e6f428ff55990f51138

> We can always revert/etc..  But I'm hoping Matthijs will chime-in..
>
> Regards,