From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: "hongxu.zhao" <hongxu.zhao@mediatek.com>
Cc: "open list:STAGING SUBSYSTEM" <devel@driverdev.osuosl.org>,
wsd_upstream@mediatek.com, Weiqi Fu <weiqi.fu@mediatek.com>,
open list <linux-kernel@vger.kernel.org>,
Cunliang Du <cunliang.du@mediatek.com>,
"moderated list:ARM/Mediatek SoC support"
<linux-mediatek@lists.infradead.org>,
"moderated list:ARM/Mediatek SoC support"
<linux-arm-kernel@lists.infradead.org>,
Matthias Brugger <matthias.bgg@gmail.com>,
Zhen jiang <zhen.jiang@mediatek.com>
Subject: Re: [PATCH] staging: Add Mediatek High Frequency Manager Framework
Date: Tue, 4 Aug 2020 10:11:26 +0200 [thread overview]
Message-ID: <20200804081126.GA1765831@kroah.com> (raw)
In-Reply-To: <20200804075339.9820-1-hongxu.zhao@mediatek.com>
On Tue, Aug 04, 2020 at 03:52:49PM +0800, hongxu.zhao wrote:
> Add a new sensor framework into linux kernel which can support multi client request sensor data.
> There are the following features:
> 1.Ringbuffer between manager and client;
> 2.Kernel space user interface;
> 3.User space user interface with syscall;
> 4.Each client hang detect mechanism;
> 5.Polling timer management in framework no need driver concern;
> 6.Polling kthread work intergrated into a single kthread
> worker to save system resources in framework no need driver concern;
> 7.Proc file system to show manager device and client details;
> 8.Compitable with android and widely used in many mediatek platform products;
>
> Change-Id: I6361cdc2d51de50f66eede7df099c4575e7ec473
Did you not run checkpatch.pl on this? :)
No need for change-id here.
But, most importantly, why is this in drivers/staging? What keeps it
from being in the "real" part of the kernel? I need a TODO file in the
directory of the driver listing what remains to be done and who is
responsible for doing this work and reviewing patches.
Can you resend this with that file added and the Change-id removed?
Also, why not just use the IIO interface, why are you creating
yet-another api for sensors? We already have 2, making a third seems
like something that guarantees this will never be mergable to the
correct part of the kernel.
And finally, /proc/ is not for devices, that is what sysfs is for,
please use that.
thanks,
greg k-h
next parent reply other threads:[~2020-08-04 8:11 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20200804075339.9820-1-hongxu.zhao@mediatek.com>
2020-08-04 8:11 ` Greg Kroah-Hartman [this message]
[not found] ` <1596702748.6258.3.camel@mbjsdccf07>
2020-08-06 10:53 ` [PATCH] staging: Add Mediatek High Frequency Manager Framework Greg Kroah-Hartman
[not found] ` <1596781829.14444.17.camel@mbjsdccf07>
2020-08-07 6:45 ` Greg Kroah-Hartman
2020-08-04 10:35 ` kernel test robot
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=20200804081126.GA1765831@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=cunliang.du@mediatek.com \
--cc=devel@driverdev.osuosl.org \
--cc=hongxu.zhao@mediatek.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=matthias.bgg@gmail.com \
--cc=weiqi.fu@mediatek.com \
--cc=wsd_upstream@mediatek.com \
--cc=zhen.jiang@mediatek.com \
/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