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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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,





[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux