linux-kernel - Re: [PATCH 2/2] gpio: sprd: Change to use SoC compatible string

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: <CACRpkdZ8vrNjju=Lmqu5x7VqKB7C2GU-oiryCRpcpCf2rBo4UA@mail.gmail.com>
Date:   Thu, 14 Feb 2019 08:56:26 +0100
From:   Linus Walleij <linus.walleij@...aro.org>
To:     Bartosz Golaszewski <bgolaszewski@...libre.com>
Cc:     Baolin Wang <baolin.wang@...aro.org>,
        Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Orson Zhai <orsonzhai@...il.com>,
        Lyra Zhang <zhang.lyra@...il.com>,
        Mark Brown <broonie@...nel.org>,
        linux-devicetree <devicetree@...r.kernel.org>,
        linux-gpio <linux-gpio@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 2/2] gpio: sprd: Change to use SoC compatible string

On Wed, Feb 13, 2019 at 5:10 PM Bartosz Golaszewski
<bgolaszewski@...libre.com> wrote:
> śr., 13 lut 2019 o 14:15 Baolin Wang <baolin.wang@...aro.org> napisał(a):
> >
> > On Wed, 13 Feb 2019 at 20:59, Bartosz Golaszewski
> > <bgolaszewski@...libre.com> wrote:
> > >
> > > śr., 13 lut 2019 o 13:49 Baolin Wang <baolin.wang@...aro.org> napisał(a):
> > > >
> > > > Change to use SoC compatible string instead of wildcard string.
> > > >
> > > > Signed-off-by: Baolin Wang <baolin.wang@...aro.org>
> > > > ---
> > > >  drivers/gpio/gpio-pmic-eic-sprd.c |    2 +-
> > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/gpio/gpio-pmic-eic-sprd.c b/drivers/gpio/gpio-pmic-eic-sprd.c
> > > > index ac573da..24228cf 100644
> > > > --- a/drivers/gpio/gpio-pmic-eic-sprd.c
> > > > +++ b/drivers/gpio/gpio-pmic-eic-sprd.c
> > > > @@ -364,7 +364,7 @@ static int sprd_pmic_eic_probe(struct platform_device *pdev)
> > > >  }
> > > >
> > > >  static const struct of_device_id sprd_pmic_eic_of_match[] = {
> > > > -       { .compatible = "sprd,sc27xx-eic", },
> > > > +       { .compatible = "sprd,sc2731-eic", },
> > > >         { /* end of list */ }
> > > >  };
> > > >  MODULE_DEVICE_TABLE(of, sprd_pmic_eic_of_match);
> > > > --
> > > > 1.7.9.5
> > > >
> > >
> > > We guarantee to make older device-trees to work with new kernel so you
> > > can add the new compatible, but you can't remove the old one.
> >
> > But the old one is incorrect, and we still keep it?
> >
>
> Well in theory the device-tree is supposed to be a stable ABI so once
> it's released, it should work with any following kernel version.
>
> In practice changes are sometimes allowed and there are also bugs in DT files.
>
> Linus: what do you think?

In this specific case I'd keep both strings, it doesn't hurt does it?

You could add a comment to the wildcard string saying it is only there
for compatibility with elder device trees.

In general as long as there are not (a lot of) products shipped with
a certain device tree, I don't care much whether we change the bindings
or contents.

The hard rule to keep the device trees backward-compatible comes
from SPARC SunOS where the DTB was burned into a BIOS ROM
that was hard or impossible to update, Linux just had to handle
whatever was in there. If the situation with the device tree we change
is not similiar, we should not care either.

In practice there are companies and developers that always
recompile and ship their device trees at the same time as they
compile and ship their kernel, and in that case we need not care
about backward compatibility.

While the device tree enablement on ARM started out with the
former (strict) assumption, the practice of using DTs has shown
that it is an unrealistic and inappropriate stance to have for all
device trees. (IMO!) So I don't mind if you break compatibility here.

Yours,
Linus Walleij