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