On Thu, Sep 10, 2026 at 7:25 AM Bjorn Andersson <[email protected]> wrote: > > On Wed, Sep 09, 2026 at 02:48:17PM +0300, Dmitry Baryshkov wrote: > > On Tue, Sep 08, 2026 at 05:44:10PM -0500, Bjorn Andersson wrote: > > > On Wed, Aug 26, 2026 at 06:37:00PM +0530, Ekansh Gupta wrote: > > > > On 20-08-2026 20:17, Rob Clark wrote: > > > > > On Wed, Aug 19, 2026 at 11:15 PM Krzysztof Kozlowski > > > > > <[email protected]> wrote: > > > > >> > > > > >> On 19/08/2026 17:48, Rob Clark wrote: > > > > >>> On Wed, Aug 19, 2026 at 8:27 AM Krzysztof Kozlowski > > > > >>> <[email protected]> wrote: > > > > >>>> The rule of usptream development is that we do not accept > > > > >>>> duplicated > > > > >>>> code, just because a vendor wants to write something new. This is > > > > >>>> basically the concept applied all over the drivers tree, where we > > > > >>>> pushed > > > > >>>> back against all sorts of duplications all over the vendors. > > > > >>>> > > > > >>>> What I miss in this thread is why would there be any exception > > > > >>>> here. We > > > > >>>> do not grant exceptions from standard practices on "I want" > > > > >>>> reasons. > > > > >>> > > > > >>> I agree that we should not have duplicated drivers just for vendor > > > > >>> lolz. But when it comes to adopting common frameworks and > > > > >>> integrating > > > > >>> better into the ecosystem, this doesn't seem like something we > > > > >>> should > > > > >>> actively discourage. I don't think this is a case of vendor lolz, > > > > >>> but > > > > >> > > > > >> No one discourages it. Following standard Linux kernel practices and > > > > >> requirements is not discouraging, do not twist the narrative here. > > > > >> Again, it is standard upstream review telling that we do not > > > > >> duplicate > > > > >> drivers. Ever, unless there is serious exception needed. > > > > > > > > > > I wasn't trying to twist the narrative, just trying to come up with a > > > > > path forward that isn't "no" or "improve existing driver", since > > > > > neither of those gets us towards a future using common frameworks. > > > > > > > > > >> I asked why there should be an exception granted? Is the reason for > > > > >> exception following: > > > > >> "We want to adopt common framework" > > > > >> ? > > > > > > > > > > Possibly? But I don't think we want two drivers to be any sort of > > > > > long term solution. (Ie. as long as venus/iris have co-exist.) > > > > > > > > > >> > > > > >>> rather reacting to drm/accel emerging as the standard framework for > > > > >>> this sort of driver. > > > > >>> > > > > >>> So how do we get from here to there? > > > > >> > > > > >> What is wrong with my proposal? > > > > > > > > > > Maybe I missed something, my understanding was your proposal was > > > > > "Grow/replace/improve existing driver instead of coming with a > > > > > duplicate".. grow or improve doesn't move us toward common > > > > > frameworks. Maybe "replace" is a valid option. If there is something > > > > > I missed, then I apologize. > > > > > > > > > > Options I can think of are: > > > > > > > > > > 1. Hardware cutoff.. new hw gets new driver, existing hw gets existing > > > > > driver > > > > > 2. Backwards compat chardev registered by new driver, providing > > > > > existing > > > > > UABI. I'm not 100% sure about the feasibility/drawbacks of this.. > > > > > AFAIU the fastrpc folks where planning a backwards compat layer in > > > > > userspace, so maybe it is possible. > > > > > 3. exception? > > > > > > > > > > I'd like to know what the feasibility of #2 is, since at a high level > > > > > that sounds like the best option. Possibly limit exposure of legacy > > > > > UABI to existing hw so we don't get into a place of needing to extend > > > > > the legacy UABI for new hw? > > > > > > > > > > But #1 sounds like a non-controversial place to start regardless. > > > > > Possibly with #2 coming as followup and necessary step before eventual > > > > > migration to new driver for existing hw? > > > > > > > > > > Even if we start with #2, how do we handle first-merge-window > > > > > bugs/regressions without reverting addition of new driver and removal > > > > > of old? It seems like we'd need a window of a couple release cycles > > > > > where both drivers exist? > > > > > > > > > > Maybe others have other/better options in mind? > > > > To all, I'm seeking on the approach I should follow to go ahead here. I > > > > can work on implementing #1(as per Rob's list) with hw specific > > > > compatible for v4 if it's acceptable. > > > > > > > > > > I don't see any reason for you to define a "hw specific compatible", > > > because as you have shown in this series (and as Rob point out), there's > > > no difference in the "hardware". > > > > > > The only reason for your "hw specific compatible" is to make a software > > > selection in Linux - and that's not what DeviceTree is for. > > > > That's not exactly true. There are protocol differences. For example, > > polling mode is supported only since a certain timeline in the history. > > Likewise other interface features are not supported on all the FastRPC > > devices. For the polling mode support we were already beaten by the lack > > of SoC-specific compats. > > > > I can see the benefit of capturing some of the generational features in > a compatible, like the changes related to address width. But for pure > software features that doesn't have an actual bearing in the hardware, > I'd prefer if we relied on dynamic discovery. > > But none of that applies to the question of "can I use compatible to > select if we should use the new or old Linux driver". >
Nit, driver could still have an allow/deny-list of machine compatibles. Might be something to keep in mind if a phased depreciation strategy was desirable.. BR, -R
