We did discuss this, but I've come to the conclusion that's the wrong
approach. Converting is going to need to track kernel closely as there
are lots of dependencies with the various rust abstractions needed. If
we just copy over the C driver, that's an invitation to diverge and
accumulate technical debt. The advice to upstreaming things is never
go work on a fork for a couple of years and come back with a huge pile
of code to upstream. I don't think this situation is any different. If
there's a path to do it in small pieces, we should take it.
I'd be quite keen for the "fork" to live in the upstream kernel. My
preference is for the two drivers to sit side-by-side. I'm not sure
whether that's a common view though.
I agree that a panthor.rs should to exist side by side with the C for
some time. I guess it's going to be in the order of a year or so (or
maybe more) and not a few weeks, so keeping the C and Rust in sync will
be important.
My take is that such drivers probably belong in non-mainline dev trees
until they settle a bit, are at least fully functional and we're down to
arguing finer details. Especially since the other Rust infra they depend
on not mainline yet either.
Given that, my opinion is this patch probably needs to be originally in
C then with a rust idiomatic port in the in-progress rust rewrite, or
there needs to be a lot more effort to building the right panthor layers
such as better register abstractions for example as part of this which
certainly will raise the workload to get this in.
