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: <20220825104422.14156-1-henning.schild@siemens.com> <34315356-f23e-34ff-98e6-a152b588f201@redhat.com>
In-Reply-To: <34315356-f23e-34ff-98e6-a152b588f201@redhat.com>
From:   Bartosz Golaszewski <brgl@bgdev.pl>
Date:   Sun, 28 Aug 2022 15:36:25 +0200
Message-ID: <CAMRc=Mc0WSi=1UN8KGEBi42Afty7NPvfOZzxDSaVvVOnsduX0A@mail.gmail.com>
Subject: Re: [PATCH v6 0/7] add support for another simatic board
To:     Hans de Goede <hdegoede@redhat.com>
Cc:     Henning Schild <henning.schild@siemens.com>,
        Linus Walleij <linus.walleij@linaro.org>,
        Pavel Machek <pavel@ucw.cz>, Mark Gross <markgross@kernel.org>,
        Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
        Lee Jones <lee@kernel.org>,
        "open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Linux LED Subsystem <linux-leds@vger.kernel.org>,
        platform-driver-x86@vger.kernel.org,
        Sheng-Yuan Huang <syhuang3@nuvoton.com>,
        Tasanakorn Phaipool <tasanakorn@gmail.com>,
        simon.guinot@sequanux.org
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Thu, Aug 25, 2022 at 4:25 PM Hans de Goede <hdegoede@redhat.com> wrote:
>
> Hi,
>
> On 8/25/22 12:44, Henning Schild wrote:
> > changes since v5:
> >   - adding patch to convert to pr_fmt
> >   - adding patch to prefix macros with "f7188x_"
> >   - rebased p1v4 to be p3v5 and added tag
> >
> > changes since v4:
> >   - remove int case from a printk in p1
> >   - include tags into commit messages
> >
> > changes since v3:
> >   - update Kconfig as well
> >   - drop chip names from comment in driver header
> >   - add manufacturer check for Fintek again, Nuvoton not possible
> >   - drop revision printing for Nuvoton
> >   - restructure defines again
> >   - add new model 427G
> >
> > changes since v2: (p1 only)
> >   - rename macros that change behavior
> >   - use chip type not device id in the macros
> >   - reorder defines a bit
> >
> > changes since v1:
> >   - remove unused define
> >   - fix bug where (base + 2) was used as second data bit
> >   - add macros for "inverted" and "single data bit"
> >
> > The first two patches apply some style refactorings before actual
> > functional changes are made.
> >
> > Later, This series enables a SuperIO GPIO driver to support a chip from
> > the vendor Nuvoton, the driver is for Fintek devices but those just are
> > very similar. And in watchdog and hwmon subsystems these SuperIO drivers
> > also share code and are sometimes called a family.
> >
> > In another step the individual banks receive a label to tell them apart,
> > a step which potentially changes an interface to legacy users that might
> > rely on all banks having the same label, or an exact label. But since a
> > later patch wants to use GPIO_LOOKUP unique labels are needed and i
> > decided to assign them for all supported chips.
> >
> > In a following patch the Simatic GPIO LED driver is extended to provide
> > LEDs in case that SuperIO GPIO driver can be loaded.
> >
> > Last but not least the watchdog module of that same SuperIO gets loaded
> > on a best effort basis.
> >
> > The very last patch enables a second model of that same board type.
> >
> > Henning Schild (7):
> >   gpio-f7188x: switch over to using pr_fmt
> >   gpio-f7188x: add a prefix to macros to keep gpio namespace clean
> >   gpio-f7188x: Add GPIO support for Nuvoton NCT6116
> >   gpio-f7188x: use unique labels for banks/chips
> >   leds: simatic-ipc-leds-gpio: add new model 227G
> >   platform/x86: simatic-ipc: enable watchdog for 227G
> >   platform/x86: simatic-ipc: add new model 427G
>
> So it looks like all these patches are ready for merging now,
> the only thing which is missing is an Ack from Pavel or
> one of the other LED people for patch 5/7.
>
> Pavel can have your ack for merging this through another tree
> please?
>
> So what is the plan for merging this?
>
> I see 2 options:
>
> Option a:
> 1. Merge the GPIO changes (patches 1-4) through the GPIO tree; and
> 2. Merge the leds + pdx86 changes through the pdx86 tree
>
> Option b:
> Merge everything through the pdx86 tree, and I will then provide
> an immutable branch + signed tag for other subsystems to pull
> (if they want to).
>

Hey! Sorry for the delay, I've just come back from vacation. I'm fine
with option b and to that end:

Acked-by: Bartosz Golaszewski <brgl@bgdev.pl>