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]
Date:   Wed, 3 Apr 2019 20:04:08 -0500
From:   Rob Herring <>
To:     Borislav Petkov <>
Cc:     James Morse <>,
        Yash Shah <>,,,
        Palmer Dabbelt <>,
        Paul Walmsley <>,
        "" <>,
        Mark Rutland <>,
        Albert Ou <>,
        Mauro Carvalho Chehab <>,
Subject: Re: [PATCH 1/2] edac: sifive: Add DT documentation for SiFive L2
 cache Controller

On Fri, Mar 29, 2019 at 3:24 PM Borislav Petkov <> wrote:
> On Fri, Mar 29, 2019 at 02:41:05PM -0500, Rob Herring wrote:
> > DT dictates aligning with what the h/w looks like which has little to
> > do with OS driver design.
> Ok, then, where does this goal for doing a driver or compilation unit
> per IP block come from?
> Because everytime an ARM EDAC driver pops up, we are having the same
> discussion.
> > I never said you should change EDAC and I outlined how things should
> > be handled if it is one driver.
> Ok, we will add that to the EDAC driver design document we're currently
> working on.
> > DT and OS subsystems are independent things. I can't tell you how to
> > design the subsystem and you can't dictate DT design (based on EDAC
> > design).
> I don't think I've ever intentionally or unintentionally dictated DT
> design - all I've opposed to is having multiple EDAC drivers on ARM.

No, but folks just extend 1 driver to mean 1 DT node because that's
easy and certainly the more common case.


Powered by blists - more mailing lists