On Tue, Mar 14, 2023 at 11:59:40PM +0300, Arınç ÜNAL wrote:

Look, I don't ask for renaming just for the sake of renaming things. I see a
benefit which would make things clearer.

If you rather mean to, know the driver very well, by saying do 100 useful
commits on the driver beforehand, that makes sense. But I think I'm capable
of managing this. I've got the time and energy.

I'm absolutely sure that you're capable of renaming mt7530 to mt753x,
that's outside the question. That change can be made without even paying
too much attention to the code, which is exactly the problem. If the
proposal is to touch mt7530_read(), mt7530_write(), mt7530_rmw()
(which it seems to be), then that's pretty much the entire driver.

Sorry for being skeptical by default, but generally such refactoring is
done by people who have the commitment to stay around when shit hits the
fan. Think of it as minimizing the time wasted by others due to that
refactoring. That could be time spent by reviewers looking at the code
being changed while trying to identify latent bugs; could be time spent
by someone who fixes a bug that doesn't backport all the way to stable
kernels because it conflicts with the refactoring. Ideally, after a
large refactoring, you would be sufficiently active to find and fix bugs
before others do, and have an eye for problematic code. Respectfully,
you still need to prove all these things. It also helps a lot if you
build a working relationship with the driver maintainers, or if you gain
their trust and become a maintainer yourself. Otherwise, more work will
just fall on the shoulders of fallback maintainers who don't have the
hardware. If there is a self-sustaining development community and they
take care of everything, I really have zero problems with large
refactoring done even by newbies. But the mt7530 maintainers have gone
pretty silent as of late, and I, as a fallback maintainer with no
hardware, have had to send 2 bug fixes to the mt7530 and 1 to the
mtk_eth_soc driver in the past month, to address the reports. Give me a
reason not to refuse more potential work :)

It's great that you have the time and energy, but with the symbolic 100
commits I just meant: start somewhere else within the driver, build the
experience, the knowledge of the development process and the appreciation
for the existing code structure.