linux-mips.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tom Li <tomli@tomli.me>
To: Paul Burton <paul.burton@mips.com>
Cc: James Hogan <jhogan@kernel.org>,
	Jiaxun Yang <jiaxun.yang@flygoat.com>,
	Huacai Chen <chenhc@lemote.com>,
	Ralf Baechle <ralf@linux-mips.org>,
	Alexandre Oliva <lxoliva@fsfla.org>,
	"linux-mips@vger.kernel.org" <linux-mips@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [RFC] On the Current Troubles of Mainlining Loongson Platform Drivers
Date: Sat, 9 Feb 2019 18:11:33 +0800	[thread overview]
Message-ID: <20190209101132.GA3901@localhost.localdomain> (raw)
In-Reply-To: <20190208200852.wcywd7yfcq7zwzve@pburton-laptop>

[-- Attachment #1: Type: text/plain, Size: 1912 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2019-02-09 10:11 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-08  8:30 [RFC] On the Current Troubles of Mainlining Loongson Platform Drivers Tom Li
2019-02-08 20:08 ` Paul Burton
2019-02-09 10:11   ` Tom Li [this message]
2019-02-09 19:38     ` Paul Burton
2019-02-11 12:13 ` Alexandre Oliva
2019-02-11 12:55   ` Tom Li
2019-02-11 22:38     ` Alexandre Oliva
2019-02-11 23:06       ` Aaro Koskinen
2019-02-12  4:39         ` tomli
2019-02-16 23:39         ` Alexandre Oliva
2019-02-17  4:59         ` Alexandre Oliva
2019-02-17 23:59           ` Aaro Koskinen
2019-02-18  1:37             ` Alexandre Oliva
2019-02-18  2:41               ` Maciej W. Rozycki
2019-03-07  6:41                 ` Alexandre Oliva
2019-03-07 17:59                   ` Maciej W. Rozycki
2019-03-08  0:46                     ` Alexandre Oliva
2019-03-08 23:56                       ` Maciej W. Rozycki
2019-05-26  9:19                         ` Alexandre Oliva
2019-06-10 21:49                           ` Aaro Koskinen
2019-06-12  5:55                             ` Maciej W. Rozycki
2019-06-12 19:24                               ` Aaro Koskinen
2020-01-23  0:20                                 ` Matt Turner
2020-01-24 18:58                                   ` Aaro Koskinen
2019-03-07 20:21                   ` Aaro Koskinen
2019-03-07 21:22                     ` Alexandre Oliva
2019-02-17  4:41     ` Alexandre Oliva

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190209101132.GA3901@localhost.localdomain \
    --to=tomli@tomli.me \
    --cc=chenhc@lemote.com \
    --cc=jhogan@kernel.org \
    --cc=jiaxun.yang@flygoat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@vger.kernel.org \
    --cc=lxoliva@fsfla.org \
    --cc=paul.burton@mips.com \
    --cc=ralf@linux-mips.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).