On 20/08/2026 12:07, Dmitry Baryshkov wrote:

On Thu, Aug 20, 2026 at 11:07:45AM +0200, Krzysztof Kozlowski wrote:

...

...

...

...

...

Device node with this compatible is already populated, so this looks simply wrong or you are adding a duplicated driver.

That's a no-go, you are supposed to work with existing drivers and grow them.

I'll bring the discussion again here, there was a discussion to move the driver to accel subsystem if we want to support new features/uAPI changes. Please read [1],[2] threads. The intention is to replace fastrpc driver with QDA eventually.

None of them address the problem. You want to grow fastrpc into user of dmabuf? So you move it from misc to here.

It's not as easy and nice, so I think in this case it's better to repeat

I disagree. The existing fastrpc driver is not that complicated. It's actually moderate amount of code, much less than Venus was (~7 times less).

It easily can grow to support two interfaces and the only difficulty is how to manage these two interfaces simultaneously or exclusively, e.g. opening first one disables the second.

I see the point here.

Would it be acceptable if we add QDA support only on the new platforms (e.g. via the SoC-specific compat), provide QDA for those platforms, and, once it reaches complete API and feature parity, we remove the old fastrpc driver, migrati old platforms.

The problem with this approach is that we have no guarantees that it will reach feature parity in respect of old interface, thus old driver might stay forever. If we agree for duplicated driver, contributors have no incentives to support old approach.

Much better is to refine the old driver, gradually adding new features while maintaining old stuff. This is the only way we can force contributors to actively work on minimizing duplicate parts.

Best regards, Krzysztof