From: Boris Brezillon <boris.brezillon@collabora.com>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: devel@driverdev.osuosl.org, linux-kernel@vger.kernel.org,
gerg@kernel.org, linux-mtd@lists.infradead.org, neil@brown.name,
linux-mediatek@lists.infradead.org, blogic@openwrt.org
Subject: Re: [PATCH] mtd: rawnand: driver for Mediatek MT7621 SoC NAND flash controller
Date: Sun, 10 Nov 2019 12:39:19 +0100 [thread overview]
Message-ID: <20191110123919.5c998839@collabora.com> (raw)
In-Reply-To: <20191107084007.GA1203521@kroah.com>
On Thu, 7 Nov 2019 09:40:07 +0100
Greg KH <gregkh@linuxfoundation.org> wrote:
> On Thu, Nov 07, 2019 at 05:35:21PM +1000, gerg@kernel.org wrote:
> > From: Greg Ungerer <gerg@kernel.org>
> >
> > Add a driver to support the NAND flash controller of the MediaTek MT7621
> > System-on-Chip device. (This one is the MIPS based parts from Mediatek).
> >
> > This code is a re-working of the earlier patches for this hardware that
> > have been floating around the internet for years:
> >
> > https://github.com/ReclaimYourPrivacy/cloak/blob/master/target/linux/ramips/patches-3.18/0045-mtd-add-mt7621-nand-support.patch
> >
> > This is a much cleaned up version, put in staging to start with.
> > It does still have some problems, mainly that it still uses a lot of the
> > mtd raw nand legacy support.
>
> Is that an issue?
Well, yes that's an issue since we decided that all new drivers should
implement ->exec_op() instead of the legacy hooks. But that would be an
issue even if we were merging the driver in staging.
> Why not just put it in the "real" part of the kernel
> then, if those apis are still in use?
>
> > The driver not only compiles, but it works well on the small range of
> > hardware platforms that it has been used on so far. I have been using
> > for quite a while now, cleaning up as I get time.
> >
> > So... I am looking for comments on the best approach forward with this.
> > At least in staging it can get some more eyeballs going over it.
>
> staging will just nit-pick it to death for coding style issues, it's not
> going to be get any major api changes/cleanups there usually. I'd
> recommend just merging this to the "real" part of the kernel now if it's
> working for you.
I agree on that point: we should merge this driver directly in the NAND
framework after it's been reworked to implement ->exec_op() instead of
the legacy hooks.
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
WARNING: multiple messages have this Message-ID (diff)
From: Boris Brezillon <boris.brezillon@collabora.com>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: devel@driverdev.osuosl.org, linux-kernel@vger.kernel.org,
gerg@kernel.org, linux-mtd@lists.infradead.org, neil@brown.name,
linux-mediatek@lists.infradead.org, blogic@openwrt.org
Subject: Re: [PATCH] mtd: rawnand: driver for Mediatek MT7621 SoC NAND flash controller
Date: Sun, 10 Nov 2019 12:39:19 +0100 [thread overview]
Message-ID: <20191110123919.5c998839@collabora.com> (raw)
In-Reply-To: <20191107084007.GA1203521@kroah.com>
On Thu, 7 Nov 2019 09:40:07 +0100
Greg KH <gregkh@linuxfoundation.org> wrote:
> On Thu, Nov 07, 2019 at 05:35:21PM +1000, gerg@kernel.org wrote:
> > From: Greg Ungerer <gerg@kernel.org>
> >
> > Add a driver to support the NAND flash controller of the MediaTek MT7621
> > System-on-Chip device. (This one is the MIPS based parts from Mediatek).
> >
> > This code is a re-working of the earlier patches for this hardware that
> > have been floating around the internet for years:
> >
> > https://github.com/ReclaimYourPrivacy/cloak/blob/master/target/linux/ramips/patches-3.18/0045-mtd-add-mt7621-nand-support.patch
> >
> > This is a much cleaned up version, put in staging to start with.
> > It does still have some problems, mainly that it still uses a lot of the
> > mtd raw nand legacy support.
>
> Is that an issue?
Well, yes that's an issue since we decided that all new drivers should
implement ->exec_op() instead of the legacy hooks. But that would be an
issue even if we were merging the driver in staging.
> Why not just put it in the "real" part of the kernel
> then, if those apis are still in use?
>
> > The driver not only compiles, but it works well on the small range of
> > hardware platforms that it has been used on so far. I have been using
> > for quite a while now, cleaning up as I get time.
> >
> > So... I am looking for comments on the best approach forward with this.
> > At least in staging it can get some more eyeballs going over it.
>
> staging will just nit-pick it to death for coding style issues, it's not
> going to be get any major api changes/cleanups there usually. I'd
> recommend just merging this to the "real" part of the kernel now if it's
> working for you.
I agree on that point: we should merge this driver directly in the NAND
framework after it's been reworked to implement ->exec_op() instead of
the legacy hooks.
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
WARNING: multiple messages have this Message-ID (diff)
From: Boris Brezillon <boris.brezillon@collabora.com>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: gerg@kernel.org, devel@driverdev.osuosl.org,
linux-kernel@vger.kernel.org, linux-mtd@lists.infradead.org,
neil@brown.name, linux-mediatek@lists.infradead.org,
blogic@openwrt.org
Subject: Re: [PATCH] mtd: rawnand: driver for Mediatek MT7621 SoC NAND flash controller
Date: Sun, 10 Nov 2019 12:39:19 +0100 [thread overview]
Message-ID: <20191110123919.5c998839@collabora.com> (raw)
In-Reply-To: <20191107084007.GA1203521@kroah.com>
On Thu, 7 Nov 2019 09:40:07 +0100
Greg KH <gregkh@linuxfoundation.org> wrote:
> On Thu, Nov 07, 2019 at 05:35:21PM +1000, gerg@kernel.org wrote:
> > From: Greg Ungerer <gerg@kernel.org>
> >
> > Add a driver to support the NAND flash controller of the MediaTek MT7621
> > System-on-Chip device. (This one is the MIPS based parts from Mediatek).
> >
> > This code is a re-working of the earlier patches for this hardware that
> > have been floating around the internet for years:
> >
> > https://github.com/ReclaimYourPrivacy/cloak/blob/master/target/linux/ramips/patches-3.18/0045-mtd-add-mt7621-nand-support.patch
> >
> > This is a much cleaned up version, put in staging to start with.
> > It does still have some problems, mainly that it still uses a lot of the
> > mtd raw nand legacy support.
>
> Is that an issue?
Well, yes that's an issue since we decided that all new drivers should
implement ->exec_op() instead of the legacy hooks. But that would be an
issue even if we were merging the driver in staging.
> Why not just put it in the "real" part of the kernel
> then, if those apis are still in use?
>
> > The driver not only compiles, but it works well on the small range of
> > hardware platforms that it has been used on so far. I have been using
> > for quite a while now, cleaning up as I get time.
> >
> > So... I am looking for comments on the best approach forward with this.
> > At least in staging it can get some more eyeballs going over it.
>
> staging will just nit-pick it to death for coding style issues, it's not
> going to be get any major api changes/cleanups there usually. I'd
> recommend just merging this to the "real" part of the kernel now if it's
> working for you.
I agree on that point: we should merge this driver directly in the NAND
framework after it's been reworked to implement ->exec_op() instead of
the legacy hooks.
next prev parent reply other threads:[~2019-11-10 11:39 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-07 7:35 [PATCH] mtd: rawnand: driver for Mediatek MT7621 SoC NAND flash controller gerg
2019-11-07 7:35 ` gerg
2019-11-07 7:35 ` gerg
2019-11-07 8:40 ` Greg KH
2019-11-07 8:40 ` Greg KH
2019-11-07 8:40 ` Greg KH
2019-11-08 4:34 ` Greg Ungerer
2019-11-08 4:34 ` Greg Ungerer
2019-11-08 4:34 ` Greg Ungerer
2019-11-10 11:39 ` Boris Brezillon [this message]
2019-11-10 11:39 ` Boris Brezillon
2019-11-10 11:39 ` Boris Brezillon
2019-11-10 12:22 ` Boris Brezillon
2019-11-10 12:22 ` Boris Brezillon
2019-11-10 12:22 ` Boris Brezillon
2019-11-07 9:20 ` René van Dorst
2019-11-07 9:20 ` René van Dorst
2019-11-07 9:20 ` René van Dorst
2019-11-08 4:46 ` Greg Ungerer
2019-11-08 4:46 ` Greg Ungerer
2019-11-08 4:46 ` Greg Ungerer
2019-11-10 11:35 ` Boris Brezillon
2019-11-10 11:35 ` Boris Brezillon
2019-11-10 11:35 ` Boris Brezillon
2019-11-10 17:37 ` Andrey Jr. Melnikov
2019-11-07 11:15 ` Dan Carpenter
2019-11-07 11:15 ` Dan Carpenter
2019-11-07 11:15 ` Dan Carpenter
2019-11-08 6:16 ` Greg Ungerer
2019-11-08 6:16 ` Greg Ungerer
2019-11-08 6:16 ` Greg Ungerer
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=20191110123919.5c998839@collabora.com \
--to=boris.brezillon@collabora.com \
--cc=blogic@openwrt.org \
--cc=devel@driverdev.osuosl.org \
--cc=gerg@kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=linux-mtd@lists.infradead.org \
--cc=neil@brown.name \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.