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=-4.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_PASS,URIBL_BLOCKED autolearn=ham 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 B5FB3C32789 for ; Thu, 8 Nov 2018 08:34:56 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 7DE5C20827 for ; Thu, 8 Nov 2018 08:34:56 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7DE5C20827 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=bootlin.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726848AbeKHSJS (ORCPT ); Thu, 8 Nov 2018 13:09:18 -0500 Received: from mail.bootlin.com ([62.4.15.54]:57203 "EHLO mail.bootlin.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726252AbeKHSJS (ORCPT ); Thu, 8 Nov 2018 13:09:18 -0500 Received: by mail.bootlin.com (Postfix, from userid 110) id AC04B2072D; Thu, 8 Nov 2018 09:34:52 +0100 (CET) Received: from bbrezillon (aaubervilliers-681-1-30-49.w90-88.abo.wanadoo.fr [90.88.15.49]) by mail.bootlin.com (Postfix) with ESMTPSA id F051E2039F; Thu, 8 Nov 2018 09:34:51 +0100 (CET) Date: Thu, 8 Nov 2018 09:34:51 +0100 From: Boris Brezillon To: Schrempf Frieder Cc: Olof Johansson , "linux-mtd@lists.infradead.org" , "linux-spi@vger.kernel.org" , David Woodhouse , "Brian Norris" , Mark Vasut , Richard Weinberger , "miquel.raynal@bootlin.com" , Mark Brown , "david.wolfe@nxp.com" , Fabio Estevam , "prabhakar.kushwaha@nxp.com" , "yogeshnarayan.gaur@nxp.com" , "han.xu@nxp.com" , Shawn Guo , "frieder.schrempf@exceet.de" , Sascha Hauer , "Sascha Hauer" , "linux-imx@nxp.com" , Russell King , Arnd Bergmann , Alexandre TORGUE , Eric Anholt , Stefan Agner , Simon Horman , Tony Lindgren , Geert Uytterhoeven , Stefan Wahren , "yannick.fertre@st.com" , Linux ARM Mailing List , Linux Kernel Mailing List Subject: Re: [PATCH v4 06/10] ARM: defconfig: Use the new FSL QSPI driver under the SPI framework Message-ID: <20181108093451.08dfe63e@bbrezillon> In-Reply-To: References: <1541601809-16950-1-git-send-email-frieder.schrempf@kontron.de> <1541601809-16950-7-git-send-email-frieder.schrempf@kontron.de> X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.32; x86_64-pc-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 Wed, 7 Nov 2018 16:36:13 +0000 Schrempf Frieder wrote: > Hi Olof, > > On 07.11.18 17:20, Olof Johansson wrote: > > On Wed, Nov 7, 2018 at 6:44 AM Frieder Schrempf > > wrote: > >> > >> From: Frieder Schrempf > >> > >> The new driver at spi/spi-fsl-qspi.c replaces the old SPI NOR driver > >> at mtd/fsl-quadspi.c. Switch to the new driver in the defconfigs. > >> > >> Signed-off-by: Frieder Schrempf > > > > Hi Frieder, > > > > This patch is part of a series that I didn't see the rest of, but in > > general we prefer to merge these through arm-soc even if the driver > > goes in through another tree. The way we'd prefer to handle it is that > > once the driver lands, we'll take the config option change to turn it > > on. To avoid our branches to break until both sides have landed, it > > might be a good idea to keep both drivers on for a short while (one > > release). > > > > So, I'm not going to ack this since we avoid taking defconfig changes > > through driver trees (these two defconfigs tend to churn a lot and we > > don't want to create merge conflicts where we don't have to), but > > we'll be happy to pick it up when the time comes. > > Ok, thank you for explaining the common practice. I will drop the config > changes for the next version and send it separately when the time is ready. > > Both the old driver and the new one use the same compatible strings for > probing. Wouldn't that cause problems if both drivers are enabled for a > while, or am I missing something? Or maybe we should not introduce a new Kconfig option and just reuse the old one. It probably requires re-ordering patches a bit (patch 1 should be moved after patch 5). Then you have 2 choices: 1/ merge patch 1 and 6 so that the new driver effectively replaces the old one but uses the same Kconfig option 2/ remove the ability to compile the old driver when the new one is introduced: remove the line from drivers/mtd/spi-nor Makefile and move the Kconfig entry from drivers/mtd/spi-nor/Kconfig to drivers/spi/Kconfig. And remove the old code in a separate patch I'm fine either way, but option #2 will probably make the patch introducing the new driver bigger and hurt readability.