Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20220131151346.45792-1-andriy.shevchenko@linux.intel.com>
 <20220308193522.26696-1-henning.schild@siemens.com> <YnJ2tYjCpJi7yc4j@smile.fi.intel.com>
 <20220504171951.0d569632@md1za8fc.ad001.siemens.net>
In-Reply-To: <20220504171951.0d569632@md1za8fc.ad001.siemens.net>
From:   Andy Shevchenko <andy.shevchenko@gmail.com>
Date:   Wed, 4 May 2022 18:36:33 +0200
Message-ID: <CAHp75VfhzYrCRd_Ne_JPdzXgNaaHz8Eg_Rr+n83umWVFtoTzfA@mail.gmail.com>
Subject: Re: [PATCH 0/2] simatic-ipc additions to p2sb apl lake gpio
To:     Henning Schild <henning.schild@siemens.com>
Cc:     Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
        Mark Gross <markgross@kernel.org>,
        Wim Van Sebroeck <wim@linux-watchdog.org>,
        Guenter Roeck <linux@roeck-us.net>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Linux LED Subsystem <linux-leds@vger.kernel.org>,
        Platform Driver <platform-driver-x86@vger.kernel.org>,
        linux-watchdog@vger.kernel.org, Enrico Weigelt <lkml@metux.net>,
        Gerd Haeussler <gerd.haeussler.ext@siemens.com>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Wed, May 4, 2022 at 6:16 PM Henning Schild
<henning.schild@siemens.com> wrote:
> Am Wed, 4 May 2022 15:51:01 +0300
> schrieb Andy Shevchenko <andriy.shevchenko@linux.intel.com>:
> > On Tue, Mar 08, 2022 at 08:35:20PM +0100, Henning Schild wrote:

...

> > Second question is could it be possible to split first patch into
> > three, or it has to be in one?
>
> I assume one for leds one for wdt and finally drop stuff from platform,

Yes.

> and i will go with that assumption for a next round based on your tree
> directly.

> Can you explain why that will be useful? While it is kind of a
> separation of concerns and subsystems ... it also kind of all belongs
> together and needs to be merged in a rather strict order.

The main case here is that it's easy to review during upstreaming and
in case of somebody looking into the history. It keeps each of the
changes logically isolated. I.o.w. it adds flexibility, for example
changing ordering of the WDT and LED patches in the series in this
case.

I admit that for _this_ series my arguments are not strong, but I'm
speaking out of general approach. The pattern
  1) add new api
  2) switch driver #1 to it
  ...
  2+n) switch driver #n to it
  3+n) drop old API
is how we do in the Linux kernel, even if the changes are coupled
together from a functional / compile perspective.

-- 
With Best Regards,
Andy Shevchenko