linux-kernel - Re: ARM, SoC: About the use DT-defined properties by 3rd-party drivers

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: <20160912170604.GG14165@leverpostej>
Date:   Mon, 12 Sep 2016 18:06:05 +0100
From:   Mark Rutland <mark.rutland@....com>
To:     Warner Losh <imp@...imp.com>
Cc:     Sebastian Frias <sf84@...oste.net>,
        devicetree <devicetree@...r.kernel.org>,
        Mason <slash.tmp@...e.fr>, Timur Tabi <timur@...i.org>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: ARM, SoC: About the use DT-defined properties by 3rd-party
 drivers

Hi,

On Mon, Sep 12, 2016 at 10:45:37AM -0600, Warner Losh wrote:
> Do I have more examples where FreeBSD has to deviate because the DT is
> actually Linux specific and does a poor job of modeling the hardware
> and instead reflects the Linux driver model? I have plenty of those...

I guess you don't actually have those written down, but on the
off-chance, would you be able to share any major pain points?

We do try (admittedly far from perfectly) to avoid implementation
details in bindings, but driver mdoel details are fairly difficult to
pin down either way. It would be nice to be more aware.

Thanks,
Mark.