Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <20210811095759.1281480-1-geert@linux-m68k.org>
 <20210811095759.1281480-20-geert@linux-m68k.org> <20210811124755.37b0a0a9@thinkpad>
 <CAMuHMdUFPvJBuFByiN6pb539REYtcsNJMKML+M2NQw=GJxTYJg@mail.gmail.com>
 <CAHp75VeNyHUmcU7GPnP8woRcDErDNQ5M3FHQGpLnhUoL5qTnLQ@mail.gmail.com> <CAMuHMdVFOu6EXKqkiLgBp3n8Oujm+uSpFn-ximtp+37TOZSp9A@mail.gmail.com>
In-Reply-To: <CAMuHMdVFOu6EXKqkiLgBp3n8Oujm+uSpFn-ximtp+37TOZSp9A@mail.gmail.com>
From:   Andy Shevchenko <andy.shevchenko@gmail.com>
Date:   Fri, 13 Aug 2021 16:59:13 +0300
Message-ID: <CAHp75VfsOFdgQP3-XStFieBQ9o4P=FVY43N4WXg6yOe+2O0bwg@mail.gmail.com>
Subject: Re: [PATCH v5 19/19] auxdisplay: ht16k33: Add LED support
To:     Geert Uytterhoeven <geert@linux-m68k.org>
Cc:     =?UTF-8?B?TWFyZWsgQmVow7pu?= <kabel@kernel.org>,
        Robin van der Gracht <robin@protonic.nl>,
        Miguel Ojeda <ojeda@kernel.org>,
        Rob Herring <robh+dt@kernel.org>,
        Paul Burton <paulburton@kernel.org>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Pavel Machek <pavel@ucw.cz>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@vger.kernel.org>,
        linux-leds <linux-leds@vger.kernel.org>,
        "open list:BROADCOM NVRAM DRIVER" <linux-mips@vger.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Mika Westerberg <mika.westerberg@linux.intel.com>,
        "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Fri, Aug 13, 2021 at 3:53 PM Geert Uytterhoeven <geert@linux-m68k.org> w=
rote:
> On Thu, Aug 12, 2021 at 2:33 PM Andy Shevchenko
> <andy.shevchenko@gmail.com> wrote:
> > On Wednesday, August 11, 2021, Geert Uytterhoeven <geert@linux-m68k.org=
> wrote:
> >> On Wed, Aug 11, 2021 at 12:48 PM Marek Beh=C3=BAn <kabel@kernel.org> w=
rote:
> >> > On Wed, 11 Aug 2021 11:57:59 +0200

...

> >> Sure, that can be done later, when an ACPI user appears?
> >
> > Actually with PRP0001 approach any of compatible driver may be used onA=
CPI platform. So, what you are saying can be interpreted the way =E2=80=9Cw=
e don=E2=80=99t care about users on ACPI based platforms=E2=80=9D. If it is=
 the case, then it should be told explicitly.
>
> I think you're interpreting too much ;-)
> My point is simply:
>
> >> The dependency on OF was pre-existing, and this series is already
> >> at v5.

Okay, but we can get rid of it. Why not make it more generic at the
same time? Does it make sense?
(I believe this is what Marek is asking initially)

> If any OF compatible driver can now be used on ACPI platforms, perhaps
> this should be handled at the API level? I.e. the distinction between
> OF and device properties should be dropped completely,

And this is done by device_*() / fwnode_*() APIs. And that's what can
be easily done here.

>  and all drivers
> be converted mechanically in one shot, instead of a gradual ad-hoc
> conversion being sneaked in through other series like this one?

Do you realize that you are asking for something impossible?

Moreover, an ad-hoc approach is what we do for plenty of things in the
kernel (WRT new APIs, that don't replace old ones immediately).

--=20
With Best Regards,
Andy Shevchenko