On 19/08/2026 17:23, Rob Clark wrote:
Growing old driver does not look complicated itself. The only a bit tricky thing is to present somehow exclusive interface to user-space, like usage of one disables the second etc. Depending on actual differences in that interface.
But having a duplicated driver is a clear no go and it is well known upstream requirement. Nothing new here.
Would it be acceptable as a first step to, by default (ie. when no cmdline override/etc) for the new driver to bind to new compatibles
You have one compatible.
and the existing driver to old? Ie. have both drivers but only one binds on a given platform?
I don't see how is it possible to write such DTS, because - repeating my question - how many hardware blocks is there? I believe only one per given DSP, so how could you have two device nodes?
Maybe I'm misunderstanding something here.. I don't see any new bindings with this series so my assumption is that the bindings are the same. What I meant was something more like "qcom,glymur-fastrpc" would bind to new driver but "qcom,fastrpc" (which seems to be what is used on older platforms) would bind to the old driver.
So single dts node, but different compatible strings picking which driver is used.
Glymur is already done, so imagining we talk about next/future SoC then we would be at point of duplicating drivers for the same hardware. So back to square one of my comments.
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.
Best regards, Krzysztof