Re: [RFC] On the Current Troubles of Mainlining Loongson Platform Drivers

[Paul Burton]

Hi Tom,

On Fri, Feb 08, 2019 at 04:30:39PM +0800, Tom Li wrote:
> Hello, Greg, Ralf, Paul, James, Alexandre and Huacai
> 
> Many years ago when I was still in the middle scheool, I got a Loongson
> Yeeloong laptop to explore the world of non-x86 world, as Geert Uytterhoeven
> once said, there's lots of Linux beyond IA-32. At that time I've noticed there
> was no platform driver for the laptop. I just assumed that nobody bothered
> mainlining it and everyone were using Alexandre Oliva's tree. I've diffed
> his tree, got the patches, discovered and fixed two minor bugs and submitted
> to Alexandre, and called it a day.
> 
> Years later, I stared at my machine, and found Alexandre Oliva has stopped
> maintaining his tree, yet there is still no platform driver in the mainline.
> So I decided that submitting the Yeeloong driver to the mainline kernel is
> the my current personal project of this year. I only work for myself for fun,
> not for profit. I see Loongson as an interesting non-x86 platform, but I do
> not work for Loongson, do not explictly support them, nor supported by them
> in any way.
> 
> Reviewing the previous E-mails and patches at Linux/MIPS mailing list, I've
> noticed that, from 2009 to 2019, in a 10-year span, there have been at least
> 3 attempts by 3 people to submit the platform driver for Yeeloong laptop to
> the Linux/MIPS tree, all implicitly rejected. This is not meant to be a
> criticism for maintainers' hard work and high quality standard, but rather,
> I think it shows a serious challenge on development of platform drivers that
> worth discussing. since there's even more unsubmitted platform drivers for
> more devices, especially Loongson3. We need to find a solution both for
> short-term and long-term further development of these platform drivers.
> 
> Here, I give a quick summary about the situation, and see what can I/we
> do about it. Digging into the mailing list, in the hindsight, it's clear
> to see the fate of this platform driver. In December 2009, Wu Zhangin
> submitted a refined version of the initial platform driver to the mailing
> list.
> 
> His intention was to create a MIPS-equivalent version of the x86 platform
> drivers, as he said,
> 
> > I like the folks did under drivers/platform/x86/ ;) which
> > will be better to maintain. for all of these drivers are really only
> > YeeLoong platform specific ;)
> 
> However, Ralf Baechle commented, that
> 
> > You split old, big driver into several individual drivers - good.
> [...]
> > Experience has shown that drivers for a particular subsystem are best
> > combined in a single menu, in a single directory. Otherwise any changes
> > to subsystem's internal APIs will become a major pain.
> 
> Dmitry Torokhov gave another response,
> 
> > Umm, it still mixes up bunch of stuff not directly related to input.
> > I'd vote for drivers/platform/mips (since we have a few of kitchen-sink
> > style drivers for x86-based laptops in drivers/platform/x86).
> 
> This discussion is frozen without any progress in the following years.
> 
> For example, when the driver was resubmitted to James Hogan in late 2018,
> he noted, possibly without knowledge of the discussion in 2009,
> 
> > I can't help thinking it would be better to separate this into separate
> > drivers for each part (backlight, power supply etc), and move them into
> > the appropriate driver directories (drivers/power/supply,
> > drivers/video/backlight etc). That way each part would get proper review
> > from the appropriate maintainers (or at least they should be Cc'd).
> > 
> > Is there a particular reason for it to be a single driver?
> 
> So I think it's the time to restart this discussion. Should the driver be
> submitted as a platform driver, or be splitted and merged into various
> subsystems? I've considered reasons from both sides.

Right off the bat, let me express my whole-hearted agreement with James
& the question he asked in that quote. If there is a good reason for
some things to be one large driver then we can discuss that, but so far I
don't believe anybody has given one - nobody replied to James' mail that
you quote [1].

It looks to me like in 2009 someone did the work to split the driver up,
which shows that it's possible, but the drivers were placed under
arch/mips which is not where they belong. They should individually be
placed at the right points under drivers/, and submitted to the relevant
subsystem maintainers.

To address the particular quote you give from Dmitry Torokhov on the
yeeloong_hotkey driver - just because the driver as-is includes a bunch
of non-input related things doesn't mean that it should or has to. From
a look at the 2009 submission it seems to mix a bunch of policy into the
kernel which really ought to be elsewhere. Generally the input driver
reports that a key was pressed & something in userland decides what to
do with it, whereas this driver seems to attempt to bypass that & prod
at unrelated hardware all by itself.

> Unsolved problems still remains, however. First, how to solve the coordination
> problem? Linux/MIPS is a relatively low-volume and slow list, what to do if the
> unmerged MIPS patches becomes a blocker for other drivers?

Anyone watching will have noticed that Ralf was only intermittently
active for quite a while, and has more recently he's been absent due to
ill health. Correspondingly there was a time when patches sent to
linux-mips didn't go anywhere quickly. Towards the end of 2017 James
Hogan stepped up & things started moving again, and more recently I've
been maintaining arch/mips/. The number of patches being applied has
increased, the frequency of pull requests has increased & stopped being
so last minute, and hopefully responses on the mailing list have become
more regular.

So if unmerged arch/mips/ patches are holding you up, ping me, but
preferrably make sure code being added actually belongs under arch/mips/
first.

On Loongson patches in particular there's a recurring theme in which
patches are submitted, review comments are provided, they're ignored &
the patches are later submitted again without addressing the review
comments. That's not universally true of all Loongson-related patches,
but there are plenty of examples of it. Of course when resubmitted the
patches still don't get merged, because they still have unaddressed
problems.

The seeming lack of documentation for particular Loongson-based
machines, lack of English documentation for the CPU cores & lack of
detailed errata information all contribute to difficulties too. For a
recent example see the loongson_llsc_mb() workaround currently in the
mips-fixes branch - we got there in the end but it took a surprising
amount of back & forth effort to obtain enough information about what
the CPU bug actually is.

I want to be clear that I absolutely want Linux to have good support for
Loongson hardware, but that doesn't mean I'll merge things before
they're of sufficient quality & it doesn't mean I'll try to merge things
that really belong under the care of other maintainers.

> Second, we already have a hwmon driver under drivers/platform/mips,
> should we put a warning that says new drivers under this directory
> shouldn't be written?

Personally I see no reason for that hwmon driver to live under
drivers/platform/mips rather than drivers/hwmon. All that does is bypass
the attention of the drivers/hwmon/ maintainers who would be best placed
to offer input & ensure the driver is actually any good.

> Third, if we agree to create drivers/platform/loongson in the future,
> how can we ask the maintainers of other subsystems to review the
> drivers in it?

I think that question should prompt another - if we have maintainers for
various driver subsystems, why not place the drivers under their care in
the already established directories?

> I think Google bypassed the problem because they have lots of kernel
> developers, but not us. Does anyone know more about Chromebook's
> development procedures? Also, if we want drivers/platform/loongson and
> its own tree, what are the procedures to get them created?

I can't speak to Google's intentions or methods, but would expect the
procedure to be approximately:

  1) Have a generally agreed upon good reason for the new directory.

  2) Have someone willing & able to maintain it, preferrably with a good
     track record of contributions to the kernel.

  3) Ideally submit it for inclusion in linux-next.

  4) Send a pull request to Linus.

  5) Wait & see if he accepts or says no.

I think this particular case falls down at step 1.

Thanks,
    Paul

[1] https://lore.kernel.org/linux-mips/20180124115833.GC5446@saruman/