From: Andy Shevchenko <andy.shevchenko@gmail.com> To: Boris Brezillon <boris.brezillon@collabora.com> Cc: "Ramuthevar, Vadivel MuruganX" <vadivel.muruganx.ramuthevar@linux.intel.com>, Martin Blumenstingl <martin.blumenstingl@googlemail.com>, Anders Roxell <anders.roxell@linaro.org>, Andriy Shevchenko <andriy.shevchenko@intel.com>, Arnd Bergmann <arnd@arndb.de>, Brendan Higgins <brendanhiggins@google.com>, cheol.yong.kim@intel.com, devicetree <devicetree@vger.kernel.org>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, "open list:MEMORY TECHNOLOGY..." <linux-mtd@lists.infradead.org>, masonccyang@mxic.com.tw, Miquel Raynal <miquel.raynal@bootlin.com>, piotrs@cadence.com, qi-ming.wu@intel.com, Richard Weinberger <richard@nod.at>, Rob Herring <robh+dt@kernel.org>, Thomas Gleixner <tglx@linutronix.de>, Vignesh R <vigneshr@ti.com> Subject: Re: [PATCH v1 2/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC Date: Thu, 16 Apr 2020 15:26:51 +0300 [thread overview] Message-ID: <CAHp75Vcpb-556imBuhsY-asrKqx7LjvQbq+P-ysK-+ii91YpWQ@mail.gmail.com> (raw) In-Reply-To: <20200416135711.039ba85c@collabora.com> On Thu, Apr 16, 2020 at 3:03 PM Boris Brezillon <boris.brezillon@collabora.com> wrote: > On Thu, 16 Apr 2020 19:38:03 +0800 > "Ramuthevar, Vadivel MuruganX" > <vadivel.muruganx.ramuthevar@linux.intel.com> wrote: > > On 16/4/2020 7:17 pm, Boris Brezillon wrote: > > > On Thu, 16 Apr 2020 18:40:53 +0800 > > > "Ramuthevar, Vadivel MuruganX" > > > <vadivel.muruganx.ramuthevar@linux.intel.com> wrote: ... > > There are different features involved and lines of code is more, if we > > add new driver patches over xway-nand driver > > How about retro-fitting the xway logic into your driver then? I mean, > adding a 100 lines of code to your driver to get rid of the 500+ lines > we have in xway_nand.c is still a win. > > > > > is completely looks ugly and it may disturb the existing functionality > > as well since we don't have platform to validate:'(. > > How ugly? Can you show us? Maybe we can come with a solution to make it > less ugly. > > As for the testing part, there are 4 scenarios: > > 1/ Your changes work perfectly fine on older platforms. Yay \o/! > 2/ You break the xway driver and existing users notice it before this > series gets merged. Now you found someone to validate your changes. > 3/ You break the xway driver and none of the existing users notice it > before the driver is merged, but they notice it afterwards. Too bad > this happened after we've merged the driver, but now you've found > someone to help you fix the problem :P. > 4/ You break things for old platforms but no one ever complains about > it, either because there's no users left or because they never > update their kernels. In any case, that's no longer your problem. > Someone will remove those old platforms one day and get rid of the > unneeded code in the NAND driver. > > What's more likely to happen is #3 or #4, and I think the NAND > maintainer would be fine with both. > > Note that the NAND subsystem is full of unmaintained legacy drivers, so > every time we see someone who could help us get rid or update one of > them we have to take this opportunity. Don't we rather insist to have a MAINTAINERS record for new code to avoid (or delay at least) the fate of the legacy drivers? -- With Best Regards, Andy Shevchenko
WARNING: multiple messages have this Message-ID (diff)
From: Andy Shevchenko <andy.shevchenko@gmail.com> To: Boris Brezillon <boris.brezillon@collabora.com> Cc: cheol.yong.kim@intel.com, devicetree <devicetree@vger.kernel.org>, qi-ming.wu@intel.com, Anders Roxell <anders.roxell@linaro.org>, Andriy Shevchenko <andriy.shevchenko@intel.com>, Arnd Bergmann <arnd@arndb.de>, Martin Blumenstingl <martin.blumenstingl@googlemail.com>, Richard Weinberger <richard@nod.at>, Brendan Higgins <brendanhiggins@google.com>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Vignesh R <vigneshr@ti.com>, "Ramuthevar, Vadivel MuruganX" <vadivel.muruganx.ramuthevar@linux.intel.com>, Rob Herring <robh+dt@kernel.org>, "open list:MEMORY TECHNOLOGY..." <linux-mtd@lists.infradead.org>, Miquel Raynal <miquel.raynal@bootlin.com>, Thomas Gleixner <tglx@linutronix.de>, masonccyang@mxic.com.tw, piotrs@cadence.com Subject: Re: [PATCH v1 2/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC Date: Thu, 16 Apr 2020 15:26:51 +0300 [thread overview] Message-ID: <CAHp75Vcpb-556imBuhsY-asrKqx7LjvQbq+P-ysK-+ii91YpWQ@mail.gmail.com> (raw) In-Reply-To: <20200416135711.039ba85c@collabora.com> On Thu, Apr 16, 2020 at 3:03 PM Boris Brezillon <boris.brezillon@collabora.com> wrote: > On Thu, 16 Apr 2020 19:38:03 +0800 > "Ramuthevar, Vadivel MuruganX" > <vadivel.muruganx.ramuthevar@linux.intel.com> wrote: > > On 16/4/2020 7:17 pm, Boris Brezillon wrote: > > > On Thu, 16 Apr 2020 18:40:53 +0800 > > > "Ramuthevar, Vadivel MuruganX" > > > <vadivel.muruganx.ramuthevar@linux.intel.com> wrote: ... > > There are different features involved and lines of code is more, if we > > add new driver patches over xway-nand driver > > How about retro-fitting the xway logic into your driver then? I mean, > adding a 100 lines of code to your driver to get rid of the 500+ lines > we have in xway_nand.c is still a win. > > > > > is completely looks ugly and it may disturb the existing functionality > > as well since we don't have platform to validate:'(. > > How ugly? Can you show us? Maybe we can come with a solution to make it > less ugly. > > As for the testing part, there are 4 scenarios: > > 1/ Your changes work perfectly fine on older platforms. Yay \o/! > 2/ You break the xway driver and existing users notice it before this > series gets merged. Now you found someone to validate your changes. > 3/ You break the xway driver and none of the existing users notice it > before the driver is merged, but they notice it afterwards. Too bad > this happened after we've merged the driver, but now you've found > someone to help you fix the problem :P. > 4/ You break things for old platforms but no one ever complains about > it, either because there's no users left or because they never > update their kernels. In any case, that's no longer your problem. > Someone will remove those old platforms one day and get rid of the > unneeded code in the NAND driver. > > What's more likely to happen is #3 or #4, and I think the NAND > maintainer would be fine with both. > > Note that the NAND subsystem is full of unmaintained legacy drivers, so > every time we see someone who could help us get rid or update one of > them we have to take this opportunity. Don't we rather insist to have a MAINTAINERS record for new code to avoid (or delay at least) the fate of the legacy drivers? -- With Best Regards, Andy Shevchenko ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/
next prev parent reply other threads:[~2020-04-16 12:27 UTC|newest] Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-04-14 2:24 [PATCH v1 0/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC Ramuthevar,Vadivel MuruganX 2020-04-14 2:24 ` Ramuthevar, Vadivel MuruganX 2020-04-14 2:24 ` [PATCH v1 1/2] dt-bindings: mtd: Add YAML for Nand Flash Controller support Ramuthevar,Vadivel MuruganX 2020-04-14 2:24 ` Ramuthevar, Vadivel MuruganX 2020-04-14 7:04 ` Boris Brezillon 2020-04-14 7:04 ` Boris Brezillon 2020-04-15 1:51 ` Ramuthevar, Vadivel MuruganX 2020-04-15 1:51 ` Ramuthevar, Vadivel MuruganX 2020-04-14 2:24 ` [PATCH v1 2/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC Ramuthevar,Vadivel MuruganX 2020-04-14 2:24 ` Ramuthevar, Vadivel MuruganX 2020-04-14 7:21 ` Boris Brezillon 2020-04-14 7:21 ` Boris Brezillon 2020-04-15 6:01 ` Ramuthevar, Vadivel MuruganX 2020-04-15 6:01 ` Ramuthevar, Vadivel MuruganX 2020-04-15 22:05 ` Martin Blumenstingl 2020-04-15 22:05 ` Martin Blumenstingl 2020-04-16 9:35 ` Ramuthevar, Vadivel MuruganX 2020-04-16 9:35 ` Ramuthevar, Vadivel MuruganX 2020-04-16 9:38 ` Boris Brezillon 2020-04-16 9:38 ` Boris Brezillon 2020-04-16 9:45 ` Ramuthevar, Vadivel MuruganX 2020-04-16 9:45 ` Ramuthevar, Vadivel MuruganX 2020-04-16 10:26 ` Boris Brezillon 2020-04-16 10:26 ` Boris Brezillon 2020-04-16 10:40 ` Ramuthevar, Vadivel MuruganX 2020-04-16 10:40 ` Ramuthevar, Vadivel MuruganX 2020-04-16 11:17 ` Boris Brezillon 2020-04-16 11:17 ` Boris Brezillon 2020-04-16 11:32 ` Andy Shevchenko 2020-04-16 11:32 ` Andy Shevchenko 2020-04-17 5:10 ` Ramuthevar, Vadivel MuruganX 2020-04-17 5:10 ` Ramuthevar, Vadivel MuruganX [not found] ` <de9f50b8-9215-d294-9914-e49701552185@linux.intel.com> 2020-04-16 11:57 ` Boris Brezillon 2020-04-16 11:57 ` Boris Brezillon 2020-04-16 12:26 ` Andy Shevchenko [this message] 2020-04-16 12:26 ` Andy Shevchenko 2020-04-16 12:40 ` Boris Brezillon 2020-04-16 12:40 ` Boris Brezillon 2020-04-16 13:20 ` Arnd Bergmann 2020-04-16 13:20 ` Arnd Bergmann 2020-04-16 13:51 ` John Crispin 2020-04-16 13:51 ` John Crispin 2020-04-20 1:09 ` Ramuthevar, Vadivel MuruganX 2020-04-20 1:09 ` Ramuthevar, Vadivel MuruganX 2020-04-16 18:08 ` Martin Blumenstingl 2020-04-16 18:08 ` Martin Blumenstingl 2020-04-17 5:21 ` Ramuthevar, Vadivel MuruganX 2020-04-17 5:21 ` Ramuthevar, Vadivel MuruganX 2020-04-17 7:02 ` Boris Brezillon 2020-04-17 7:02 ` Boris Brezillon 2020-04-17 7:53 ` Ramuthevar, Vadivel MuruganX 2020-04-17 7:53 ` Ramuthevar, Vadivel MuruganX
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=CAHp75Vcpb-556imBuhsY-asrKqx7LjvQbq+P-ysK-+ii91YpWQ@mail.gmail.com \ --to=andy.shevchenko@gmail.com \ --cc=anders.roxell@linaro.org \ --cc=andriy.shevchenko@intel.com \ --cc=arnd@arndb.de \ --cc=boris.brezillon@collabora.com \ --cc=brendanhiggins@google.com \ --cc=cheol.yong.kim@intel.com \ --cc=devicetree@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mtd@lists.infradead.org \ --cc=martin.blumenstingl@googlemail.com \ --cc=masonccyang@mxic.com.tw \ --cc=miquel.raynal@bootlin.com \ --cc=piotrs@cadence.com \ --cc=qi-ming.wu@intel.com \ --cc=richard@nod.at \ --cc=robh+dt@kernel.org \ --cc=tglx@linutronix.de \ --cc=vadivel.muruganx.ramuthevar@linux.intel.com \ --cc=vigneshr@ti.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: linkBe 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.