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:32:21 -0500
From: Robert Nelson <robertcnelson@...il.com>
To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc: Andrew Davis <afd@...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

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

I saw Matthijs, did chime in, I'll wait for his full reply, we've been
utilizing his knowledge on the pru subsystem to keep the uio driver
alive with our out of tree patches. (and extending it to even newer
TI am57xx devices, which TI didn't want us to do..)

Looking at lore, Matt Porter originally had am335x support in the
initial drop of uio when adding it to the DA850 family.

https://lore.kernel.org/lkml/20121003150058.GB11180@beef/

I'll dig for his v3 to find the real reason on why it was later dropped.

But at some point the remoteproc framework became the preferred
method, so uio patches were not allowed.. (one IP block, two drivers..
Community vs TI/Mainline)

Regards,

--
Robert Nelson
https://rcn-ee.com/