On 12.11.18 11:56, Boris Brezillon wrote: > On Mon, 12 Nov 2018 10:46:45 +0000 > Schrempf Frieder <frieder.schre...@kontron.de> wrote: > >> On 08.11.18 09:34, Boris Brezillon wrote: >>> On Wed, 7 Nov 2018 16:36:13 +0000 >>> Schrempf Frieder <frieder.schre...@kontron.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.schre...@kontron.de> wrote: >>>>>> >>>>>> From: Frieder Schrempf <frieder.schre...@exceet.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.schre...@exceet.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.