Message-ID: <7c379ee9-a9e7-e0a5-14a5-9074d6a964e7@kontron.de>
Date:   Mon, 12 Nov 2018 11:24:22 +0000
From:   Schrempf Frieder <frieder.schrempf@...tron.De>
To:     Boris Brezillon <boris.brezillon@...tlin.com>
CC:     Olof Johansson <olof@...om.net>,
        "linux-mtd@...ts.infradead.org" <linux-mtd@...ts.infradead.org>,
        "linux-spi@...r.kernel.org" <linux-spi@...r.kernel.org>,
        David Woodhouse <dwmw2@...radead.org>,
        "Brian Norris" <computersforpeace@...il.com>,
        Mark Vasut <marek.vasut@...il.com>,
        Richard Weinberger <richard@....at>,
        "miquel.raynal@...tlin.com" <miquel.raynal@...tlin.com>,
        Mark Brown <broonie@...nel.org>,
        "david.wolfe@....com" <david.wolfe@....com>,
        Fabio Estevam <fabio.estevam@....com>,
        "prabhakar.kushwaha@....com" <prabhakar.kushwaha@....com>,
        "yogeshnarayan.gaur@....com" <yogeshnarayan.gaur@....com>,
        "han.xu@....com" <han.xu@....com>, Shawn Guo <shawnguo@...nel.org>,
        "frieder.schrempf@...eet.de" <frieder.schrempf@...eet.de>,
        Sascha Hauer <s.hauer@...gutronix.de>,
        "Sascha Hauer" <kernel@...gutronix.de>,
        "linux-imx@....com" <linux-imx@....com>,
        Russell King <linux@...linux.org.uk>,
        Arnd Bergmann <arnd@...db.de>,
        Alexandre TORGUE <alexandre.torgue@...com>,
        Eric Anholt <eric@...olt.net>, Stefan Agner <stefan@...er.ch>,
        Simon Horman <horms+renesas@...ge.net.au>,
        Tony Lindgren <tony@...mide.com>,
        Geert Uytterhoeven <geert+renesas@...der.be>,
        Stefan Wahren <stefan.wahren@...e.com>,
        "yannick.fertre@...com" <yannick.fertre@...com>,
        Linux ARM Mailing List <linux-arm-kernel@...ts.infradead.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v4 06/10] ARM: defconfig: Use the new FSL QSPI driver
 under the SPI framework

On 12.11.18 11:56, Boris Brezillon wrote:
> On Mon, 12 Nov 2018 10:46:45 +0000
> Schrempf Frieder <frieder.schrempf@...tron.De> wrote:
> 
>> On 08.11.18 09:34, Boris Brezillon wrote:
>>> On Wed, 7 Nov 2018 16:36:13 +0000
>>> Schrempf Frieder <frieder.schrempf@...tron.De> wrote:
>>>    
>>>> Hi Olof,
>>>>
>>>> On 07.11.18 17:20, Olof Johansson wrote:
>>>>> On Wed, Nov 7, 2018 at 6:44 AM Frieder Schrempf
>>>>> <frieder.schrempf@...tron.de> wrote:
>>>>>>
>>>>>> From: Frieder Schrempf <frieder.schrempf@...eet.de>
>>>>>>
>>>>>> 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 <frieder.schrempf@...eet.de>
>>>>>
>>>>> 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.
>>
>> I think having both drivers in the tree for a while wouldn't be so bad.
>> So if any compatibility issues come up with the new driver, people can
>> still use the old one.
> 
> Except that's not what happens in practice. Believe me, I tried this
> approach several times, and people keep using the old driver until
> they're forced to switch to the new one. So you actually don't address
> the problem, you just delay it a bit, and you'll have to fix
> regressions anyway.

Ok, I see.

>> Therefore I think I will drop the patches that change the defconfig and
>> remove the old driver code and keep the different Kconfig options. And
>> maybe add an exclusive dependency in Kconfig, so both drivers can not be
>> enabled at the same time.
>>
>> Does this make sense?
> 
> I'd really prefer to have the removal of the old driver in the same
> release the new driver is introduced but if that's not possible, let's
> have a clear plan, like "introduce new driver in release X, remove the
> old one in release X+1".

We can do it as you suggested. I will think about whether to use option 
#1 or #2.
With #1 we will have the removal of the old driver and adding the new 
driver in one single patch.
With #2 we will have the disabling of the old driver via Makefile in the 
same patch thats adding the new driver.

Powered by blists - more mailing lists