Re: [TECH TOPIC] UALink driver upstreaming

[Greg KH <gregkh@linuxfoundation.org>]

On Fri, Sep 12, 2025 at 09:22:29AM +0200, Linus Walleij wrote:
> On Thu, Sep 11, 2025 at 8:10 PM Konstantin Sinyuk <sinyuk@gmail.com> wrote:
> > On Thu, Sep 11, 2025 at 10:42:01AM +0200, Linus Walleij wrote:
> 
> > > So this gives at hand that since this is no "ordinary" memory-mapped
> > > driver, it needs its own bus and therefore intuitively its own subsystem?
> > >
> > > What about drivers/accel/ual where other accelerators live?
> > >
> > > Or if that is somehow inappropriate, just drivers/ual, don't be shy.
> >
> > Hi Linus,
> >
> > For the initial RFC, I thought to start under drivers/misc/ just as a
> > lightweight entry point to get early review. But I agree with you that
> > UALink fits more naturally as its own subsystem, similar to how CXL is
> > handled, rather than being grouped under accel. The long-term plan
> > should definitely be drivers/ual/.
> 
> If you want to "ease in" drivers the appropriate place is drivers/staging.

Not really.  Staging is for "stuff that is not cleaned up yet and we
want to do that work in-tree".  It's best for existing code bases that
have been around for a while to get dropped in there and take advantage
of people wanting to do simple "first task" type of kernel patches
(coding style cleanups, shim layer removals, spelling fixes.)

It's almost never a good idea to use staging for a new subsystem as the
work it takes to get it merged out of staging is almost always more than
it would be to just do "all of the coding style cleanups first" out of
the tree and then merge it properly.

So I do not recommend staging for anything with an "active" developer
community, as it would just slow down the acceptance of the code to the
real part of the kernel.

> But if you have a focused team and you are going to start small
> and work on this then just use drivers/accel/ual from day 1.

Totally agreed.

thanks,

greg k-h