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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Tue, 26 Mar 2024 12:34:09 -0500
From: Andrew Davis <afd@...com>
To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
CC: Robert Nelson <robertcnelson@...il.com>,
        Jason Kridner
	<jkridner@...gleboard.org>,
        Matthijs van Duin <matthijsvanduin@...il.com>,
        Drew Fustini <drew@...gleboard.org>, Tony Lindgren <tony@...mide.com>,
        <linux-omap@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] uio: pruss: Deprecate use of this driver

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@...uxfoundation.org> 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@...com>
>>>>> ---
>>>>>    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