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] [day] [month] [year] [list]

Message-ID: <CAMz4kuKeMgZNf-_kO8j=8xPPy3o3pfZ=asv5hZX=2DKUSQBOhg@mail.gmail.com>
Date:   Thu, 14 Feb 2019 18:42:21 +0800
From:   Baolin Wang <baolin.wang@...aro.org>
To:     Linus Walleij <linus.walleij@...aro.org>
Cc:     Bartosz Golaszewski <bgolaszewski@...libre.com>,
        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 Thu, 14 Feb 2019 at 15:56, Linus Walleij <linus.walleij@...aro.org> wrote:
>
> 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.
>

Thanks for your explanation. Yes, as our dts and drivers development
are still in progress, I do not think we need care about the backward
compatibility issue. So I still intend to remove the incorrect
wildcard string.

-- 
Baolin Wang
Best Regards