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: <20160912133510.GC13192@bill-the-cat>
Date:   Mon, 12 Sep 2016 09:35:10 -0400
From:   Tom Rini <trini@...sulko.com>
To:     Matthijs van Duin <matthijsvanduin@...il.com>
Cc:     Rob Herring <robh+dt@...nel.org>, Nishanth Menon <nm@...com>,
        Frank Rowand <frowand.list@...il.com>,
        Tony Lindgren <tony@...mide.com>,
        Grant Likely <grant.likely@...aro.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        linux-omap <linux-omap@...r.kernel.org>,
        Tero Kristo <t-kristo@...com>
Subject: Re: [PATCHv2] of: Add generic handling for ePAPR 1.1 fail-sss states

On Sat, Sep 10, 2016 at 03:11:17AM +0200, Matthijs van Duin wrote:
> On 8 September 2016 at 15:38, Rob Herring <robh+dt@...nel.org> wrote:
> > Yes, in theory a device can go from disabled to okay, but that's
> > generally never been supported. Linux takes the simple approach of
> > "disabled" means ignore it. I think we'll see that change with
> > overlays.
> 
> No need for future tense there, overlays are being used on a daily
> basis on the BeagleBone and have already been for years.
> 
> > I don't agree. Generally, disabled means the h/w is there, but don't
> > use it. There may be some cases where the hardware doesn't exist for
> > the convenience of having a single dts, but that's the exception.
> 
> Yes and no. What matters is whether "don't use it" means "you can't
> put it to good use" or "don't even try to reach the peripheral, bad
> things will happen". Right now it's used for both cases.
> 
> Ideally the latter case would be removed from the kernel's view entirely.

What do you mean by "you can't put it to good use" ?  Is that the case
of stuff that's say exposed via a header and could be used but isn't (ie
the cape/hat/chip/etc case) or the IP block is still OK but just not
exposed at all?

What we're trying to address here is the case of "don't even try to
use the peripheral, bad things will happen.  But please properly idle
the IP block!".

-- 
Tom

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ