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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20190209101132.GA3901@localhost.localdomain>
Date:   Sat, 9 Feb 2019 18:11:33 +0800
From:   Tom Li <tomli@...li.me>
To:     Paul Burton <paul.burton@...s.com>
Cc:     James Hogan <jhogan@...nel.org>,
        Jiaxun Yang <jiaxun.yang@...goat.com>,
        Huacai Chen <chenhc@...ote.com>,
        Ralf Baechle <ralf@...ux-mips.org>,
        Alexandre Oliva <lxoliva@...la.org>,
        "linux-mips@...r.kernel.org" <linux-mips@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [RFC] On the Current Troubles of Mainlining Loongson Platform
 Drivers

> 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.

Sure, the hotkey driver has some problems in its current shape. I think
the existing code makes some hotkeys on the keyboard behave like a hardware
switch to order to implement rfkill hardblock, and also controls the video
output switch. I think I need to investigate it further.

> 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.

Yes. I think if our conclusion is "drivers/platform/mips is not a good idea",
it should be moved to the appropriate category in the future.

> 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?
>
> Thanks,
>     Paul

Thanks for your reply, I'm fully agree with your comments about platform
drivers.

I find reorganization of the current Yeeloong platform driver is relatively
easy, since it only involves one machine, I'm already working on it.

If future developers find it's difficult to support new machines, we can simply
have more discussion, reorganize the existing hierarchy further, and make
incremental changes.

Cheers,
Tom Li
Beijing GNU/Linux User Group.

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)