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
