linux-kernel - Re: [PATCH 0/2] simatic-ipc additions to p2sb apl lake gpio

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAHp75VfhzYrCRd_Ne_JPdzXgNaaHz8Eg_Rr+n83umWVFtoTzfA@mail.gmail.com>
Date:   Wed, 4 May 2022 18:36:33 +0200
From:   Andy Shevchenko <andy.shevchenko@...il.com>
To:     Henning Schild <henning.schild@...mens.com>
Cc:     Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Mark Gross <markgross@...nel.org>,
        Wim Van Sebroeck <wim@...ux-watchdog.org>,
        Guenter Roeck <linux@...ck-us.net>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux LED Subsystem <linux-leds@...r.kernel.org>,
        Platform Driver <platform-driver-x86@...r.kernel.org>,
        linux-watchdog@...r.kernel.org, Enrico Weigelt <lkml@...ux.net>,
        Gerd Haeussler <gerd.haeussler.ext@...mens.com>
Subject: Re: [PATCH 0/2] simatic-ipc additions to p2sb apl lake gpio

On Wed, May 4, 2022 at 6:16 PM Henning Schild
<henning.schild@...mens.com> wrote:
> Am Wed, 4 May 2022 15:51:01 +0300
> schrieb Andy Shevchenko <andriy.shevchenko@...ux.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