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: <CAL_Jsq+Zhgn53wGdMbZKMjxk2gPQQFpjSsudVso+keonDCd+oQ@mail.gmail.com>
Date:   Fri, 23 Apr 2021 13:41:56 -0500
From:   Rob Herring <robh@...nel.org>
To:     Ilya Lipnitskiy <ilya.lipnitskiy@...il.com>
Cc:     "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Matthias Brugger <matthias.bgg@...il.com>,
        netdev <netdev@...r.kernel.org>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>,
        linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
        "moderated list:ARM/Mediatek SoC support" 
        <linux-mediatek@...ts.infradead.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        John Crispin <john@...ozen.org>
Subject: Re: [PATCH] dt-bindings: net: mediatek/ralink: remove unused bindings

On Wed, Apr 21, 2021 at 5:05 PM Ilya Lipnitskiy
<ilya.lipnitskiy@...il.com> wrote:
>
> Hi Rob,
>
> On Wed, Apr 21, 2021 at 3:03 PM Rob Herring <robh@...nel.org> wrote:
> >
> > On Mon, Apr 19, 2021 at 07:42:22PM -0700, Ilya Lipnitskiy wrote:
> > > Revert commit 663148e48a66 ("Documentation: DT: net: add docs for
> > > ralink/mediatek SoC ethernet binding")
> > >
> > > No in-tree drivers use the compatible strings present in these bindings,
> > > and some have been superseded by DSA-capable mtk_eth_soc driver, so
> > > remove these obsolete bindings.
> >
> > Looks like maybe OpenWRT folks are using these. If so, you can't revert
> > them.
> Indeed, there are out of tree drivers for some of these. I wasn't sure
> what the dt-binding policy was for such use cases - can you point me
> to a definitive reference?

Perhaps we should write that down more explicitly, but I think it is
pretty rare actually. And really, I'd like to require we have at least
1 dts user. Though, then we'd just have dead dts files. More
generally, other projects use the bindings and dts files. The bindings
and dts files live in the kernel tree for convenience and the simple
fact that is where the vast majority of both developers and hardware
support are. There are exceptions of course such as h/w that doesn't
run Linux.

I'm all for removing this if no one cares (please try to find out) or
if the existing binding is just bad (doesn't match the h/w or is
incomplete in an incompatible way). I would have expected in the 5
years since it was added, a user (either dts file or driver) would
have appeared.

Rob

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ