From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_2 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3930CC2BB55 for ; Thu, 16 Apr 2020 12:41:07 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 1EAC6217D8 for ; Thu, 16 Apr 2020 12:41:07 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2635931AbgDPMlE (ORCPT ); Thu, 16 Apr 2020 08:41:04 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48382 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S2635883AbgDPMkq (ORCPT ); Thu, 16 Apr 2020 08:40:46 -0400 Received: from bhuna.collabora.co.uk (bhuna.collabora.co.uk [IPv6:2a00:1098:0:82:1000:25:2eeb:e3e3]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id F1FE5C061A0C; Thu, 16 Apr 2020 05:40:43 -0700 (PDT) Received: from localhost (unknown [IPv6:2a01:e0a:2c:6930:5cf4:84a1:2763:fe0d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: bbrezillon) by bhuna.collabora.co.uk (Postfix) with ESMTPSA id 750ED2A20B2; Thu, 16 Apr 2020 13:40:40 +0100 (BST) Date: Thu, 16 Apr 2020 14:40:36 +0200 From: Boris Brezillon To: Andy Shevchenko Cc: "Ramuthevar, Vadivel MuruganX" , Martin Blumenstingl , Anders Roxell , Andriy Shevchenko , Arnd Bergmann , Brendan Higgins , cheol.yong.kim@intel.com, devicetree , Linux Kernel Mailing List , "open list:MEMORY TECHNOLOGY..." , masonccyang@mxic.com.tw, Miquel Raynal , piotrs@cadence.com, qi-ming.wu@intel.com, Richard Weinberger , Rob Herring , Vignesh R Subject: Re: [PATCH v1 2/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC Message-ID: <20200416144036.3ce8432f@collabora.com> In-Reply-To: References: <20200414022433.36622-3-vadivel.muruganx.ramuthevar@linux.intel.com> <20200415220533.733834-1-martin.blumenstingl@googlemail.com> <20200416113822.2ef326cb@collabora.com> <18568cf6-2955-472e-7b68-eb35e654a906@linux.intel.com> <20200416122619.2c481792@collabora.com> <20200416131725.51259573@collabora.com> <20200416135711.039ba85c@collabora.com> Organization: Collabora X-Mailer: Claws Mail 3.17.5 (GTK+ 2.24.32; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 16 Apr 2020 15:26:51 +0300 Andy Shevchenko wrote: > On Thu, Apr 16, 2020 at 3:03 PM Boris Brezillon > wrote: > > On Thu, 16 Apr 2020 19:38:03 +0800 > > "Ramuthevar, Vadivel MuruganX" > > wrote: > > > On 16/4/2020 7:17 pm, Boris Brezillon wrote: > > > > On Thu, 16 Apr 2020 18:40:53 +0800 > > > > "Ramuthevar, Vadivel MuruganX" > > > > 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? > Well, that's what we do for new drivers, but the xway driver has been added in 2012 and the policy was not enforced at that time. BTW, that goes for most of the legacy drivers in have in the NAND subsystems (some of them even predate the git era). To be clear, I just checked and there's no official maintainer for this driver. Best option would be to Cc the original author and contributors who proposed functional changes to the code, as well as the MIPS maintainers (Xway is a MIPS platform). From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.2 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_2 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id CD4B2C352BE for ; Thu, 16 Apr 2020 12:40:47 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id A01B7217D8 for ; Thu, 16 Apr 2020 12:40:47 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="cJVAtnnx" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A01B7217D8 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=collabora.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-mtd-bounces+linux-mtd=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=PVoNG/fscAu1v+PICZwO+uK768zR3IwVNAXneyMM/yw=; b=cJVAtnnxK0vNs3 46ml7Oep/35+zq840LLWHWdLSZNjt1AP/XV9E2/ZzzhpXjlCgjKH4MSEFj1L6Opti9oO4c8T/YZDc Wmi3NkLwnQ3NpRcFVyGGTxKcpTPZLJZ7MfA8T2wBVcePKPlgvzEjOjPl1eXixJLboM+urewleZl/v IwKH6JOhvhzm30WXqPzUewjCj9FZRsRXLw8aClnyoKC6JT6W31aUyd4TuEkjLCY+wh0vQAXffXMJf S6QXOeXrJJqqhPJSm1HT2KB9rK18OISzDyFxvZ4Io0B5PXMqoM0AcGp7xpynNdBmrBXzNtT0eYtvr jQD84ab93BNAfKckaTrw==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jP3p0-0000mn-EE; Thu, 16 Apr 2020 12:40:46 +0000 Received: from bhuna.collabora.co.uk ([2a00:1098:0:82:1000:25:2eeb:e3e3]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jP3ox-0000lX-VR for linux-mtd@lists.infradead.org; Thu, 16 Apr 2020 12:40:45 +0000 Received: from localhost (unknown [IPv6:2a01:e0a:2c:6930:5cf4:84a1:2763:fe0d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: bbrezillon) by bhuna.collabora.co.uk (Postfix) with ESMTPSA id 750ED2A20B2; Thu, 16 Apr 2020 13:40:40 +0100 (BST) Date: Thu, 16 Apr 2020 14:40:36 +0200 From: Boris Brezillon To: Andy Shevchenko Subject: Re: [PATCH v1 2/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC Message-ID: <20200416144036.3ce8432f@collabora.com> In-Reply-To: References: <20200414022433.36622-3-vadivel.muruganx.ramuthevar@linux.intel.com> <20200415220533.733834-1-martin.blumenstingl@googlemail.com> <20200416113822.2ef326cb@collabora.com> <18568cf6-2955-472e-7b68-eb35e654a906@linux.intel.com> <20200416122619.2c481792@collabora.com> <20200416131725.51259573@collabora.com> <20200416135711.039ba85c@collabora.com> Organization: Collabora X-Mailer: Claws Mail 3.17.5 (GTK+ 2.24.32; x86_64-redhat-linux-gnu) MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200416_054044_145279_7CF5E103 X-CRM114-Status: GOOD ( 24.02 ) X-BeenThere: linux-mtd@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: cheol.yong.kim@intel.com, devicetree , qi-ming.wu@intel.com, Anders Roxell , Andriy Shevchenko , Arnd Bergmann , Martin Blumenstingl , Richard Weinberger , Brendan Higgins , Linux Kernel Mailing List , Vignesh R , "Ramuthevar, Vadivel MuruganX" , Rob Herring , "open list:MEMORY TECHNOLOGY..." , Miquel Raynal , masonccyang@mxic.com.tw, piotrs@cadence.com Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-mtd" Errors-To: linux-mtd-bounces+linux-mtd=archiver.kernel.org@lists.infradead.org On Thu, 16 Apr 2020 15:26:51 +0300 Andy Shevchenko wrote: > On Thu, Apr 16, 2020 at 3:03 PM Boris Brezillon > wrote: > > On Thu, 16 Apr 2020 19:38:03 +0800 > > "Ramuthevar, Vadivel MuruganX" > > wrote: > > > On 16/4/2020 7:17 pm, Boris Brezillon wrote: > > > > On Thu, 16 Apr 2020 18:40:53 +0800 > > > > "Ramuthevar, Vadivel MuruganX" > > > > 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? > Well, that's what we do for new drivers, but the xway driver has been added in 2012 and the policy was not enforced at that time. BTW, that goes for most of the legacy drivers in have in the NAND subsystems (some of them even predate the git era). To be clear, I just checked and there's no official maintainer for this driver. Best option would be to Cc the original author and contributors who proposed functional changes to the code, as well as the MIPS maintainers (Xway is a MIPS platform). ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/