From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1DD69C433EF for ; Wed, 4 May 2022 16:37:14 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236816AbiEDQks (ORCPT ); Wed, 4 May 2022 12:40:48 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42882 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231852AbiEDQks (ORCPT ); Wed, 4 May 2022 12:40:48 -0400 Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 087C015711; Wed, 4 May 2022 09:37:11 -0700 (PDT) Received: by mail-ed1-x52c.google.com with SMTP id d6so2321472ede.8; Wed, 04 May 2022 09:37:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xf0XnIUXSUk6cizryQBZy/YJHjA9ZjdH2YsUOzyDnc4=; b=aSXtoSMHDvZNXMhWaihhLP25nQOQhiEHCKB91OUlWvLZD0yCipp8z5dzqA69y0ms61 Lq8x67iU3jxnqIMy4JG6m3PIEmXpy6R1DEZDGGSdgtjRu07/Xsd77YBZQ43e6zWVaYQ5 MP1lZaWwaOiuqf2Ddf4OPGhE53cKuuXZoPSktz7O+xjodz7Tbtl9invbFlKBgWRh2q8K Bp6XRGmdhMHMvAcPYe5A7MxC9Wu76/YGcQW8qLUMreFTu1O1DCin2OiWNE1GSjYs8Zrx u5Y0jwDXFcbnRPgCQa0UEB7k08nXH/WpKUg6QkZ9ml4hyJYfsm2oLkuNaLHDW36+8h82 yAFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=xf0XnIUXSUk6cizryQBZy/YJHjA9ZjdH2YsUOzyDnc4=; b=6sExnOamH6OLNhCg3fHPq6eYJ9D9QxOntpKJFDzhMyWSkanhiGiPkL7xoQXvL/Ho0r 6jKTvKNeOz2GaHCzGS+4W9iIq75I8BMlFlV04r46rdW0R+7kyBmQV2hRh6T+hAFOrody ZAPXIVeiNQTtuY9+aFQck2kT1ys3xBZ2TDAy+Mu7MoZ3TYxLmqmaaX9j0qcUWKN1XOIw hKO7mpACf/XMWSoHF+ONVoI5JRW+w5Qe4GtuR4fNEpB1clb0NiJkmJEzd+u8ZUY/7f+/ WADTG7OCLvkYc3cSBdqLS7spypshN6/z9OTwh+JJJXUSCSu53a1c9YIhFfet3//BrlZW XNdg== X-Gm-Message-State: AOAM533l5IG29udDARzm8ZPDqzY/721uaucsVkHqtlgYrIr3aiUr9l2g +abbNDAU0ku3rv6/caEQnCYlyI7k5OlS5o/RwCRBWi4UMYDGAdDp X-Google-Smtp-Source: ABdhPJzvVj4QAu2vJSNQvv5AulXPLXlXytMRH0aeuSwaDWF3GIZlKBljGm3kzbhGM2ilk0akA+eSiBvblyYOUScdFNE= X-Received: by 2002:a05:6402:54:b0:419:9b58:e305 with SMTP id f20-20020a056402005400b004199b58e305mr23790727edu.158.1651682229586; Wed, 04 May 2022 09:37:09 -0700 (PDT) MIME-Version: 1.0 References: <20220131151346.45792-1-andriy.shevchenko@linux.intel.com> <20220308193522.26696-1-henning.schild@siemens.com> <20220504171951.0d569632@md1za8fc.ad001.siemens.net> In-Reply-To: <20220504171951.0d569632@md1za8fc.ad001.siemens.net> From: Andy Shevchenko Date: Wed, 4 May 2022 18:36:33 +0200 Message-ID: Subject: Re: [PATCH 0/2] simatic-ipc additions to p2sb apl lake gpio To: Henning Schild Cc: Andy Shevchenko , Mark Gross , Wim Van Sebroeck , Guenter Roeck , Linux Kernel Mailing List , Linux LED Subsystem , Platform Driver , linux-watchdog@vger.kernel.org, Enrico Weigelt , Gerd Haeussler Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-leds@vger.kernel.org On Wed, May 4, 2022 at 6:16 PM Henning Schild wrote: > Am Wed, 4 May 2022 15:51:01 +0300 > schrieb Andy Shevchenko : > > 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