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]
Date:   Wed, 25 Jan 2017 17:15:52 -0700
From:   Al Stone <ahs3@...hat.com>
To:     Dmitry Torokhov <dmitry.torokhov@...il.com>
Cc:     Mark Brown <broonie@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Furquan Shaikh <furquan@...omium.org>,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        "Rafael J . Wysocki" <rjw@...ysocki.net>,
        Liam Girdwood <lgirdwood@...il.com>,
        Tony Lindgren <tony@...mide.com>, Len Brown <lenb@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
        Hanjun Guo <hanjun.guo@...aro.org>,
        Will Deacon <will.deacon@....com>,
        Rob Herring <robh@...nel.org>,
        Sathyanarayana Nujella <sathyanarayana.nujella@...el.com>,
        Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
        Adam Thomson <Adam.Thomson.Opensource@...semi.com>,
        Linus Walleij <linus.walleij@...aro.org>,
        Alexandre Courbot <gnurou@...il.com>,
        linux-gpio@...r.kernel.org,
        ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux OMAP Mailing List <linux-omap@...r.kernel.org>,
        Aaron Durbin <adurbin@...omium.org>, dlaurie@...omium.org
Subject: Re: [PATCH 0/7] Implement generic regulator constraints parsing for
 ACPI and OF

On 01/25/2017 04:27 PM, Dmitry Torokhov wrote:
> On Wed, Jan 25, 2017 at 02:44:10PM -0700, Al Stone wrote:
>>
>> But, to the point of some of the other discussion on the thread, this ACPI sort
>> of power management is a very, very different model than DT so that intertwining
>> the two models is highly unlikely to work, IMHO.
> 
> And yet this is something that is sorely needed. If you look, for
> example, at drivers in drivers/input/*, then all non-SOC-specific
> devices can easily find their way onto both ACPI-based and DT-based
> systems (not mentioning legacy-style boards). Having two distinct power
> schemes implemented in drivers will lead to many problems.

I really can't speak to those sorts of systems; where I deal with ACPI
is on enterprise-class server systems which seldom have a graphics card,
much less input devices other than a keyboard.  And in general, those
systems are required to use only ACPI.  If a vendor wants their device to
work on such a system, they need to provide a driver that works with ACPI.
It may also work with DT, but in this environment it doesn't matter.

Whether or not there are two power schemes is a moot point.  We have DT
and we have ACPI, and they have very different schemes for power management,
so we're already there.  And so far, my experience has been that as long as
the ACPI and DT parts of the driver are kept disjoint when the models diverge,
and share code when they are semantically absolutely identical, things work
pretty well.

> Having unified way of describing hardware is how _DSD came about, right?
> Nobody wanted to write and maintain and test two separate ways of
> describing properties when one was already implemented and working.

I can't speak for those that proposed _DSD to be part of the ACPI spec,
but no, it was not meant as a unified way of describing hardware, as far
as I can remember from the ASWG discussions I was part of.  The intent,
as I recall it, was to provide some of the same flexibility to ASL that
was available in DT.  At the time, power managment was even discussed as
one of the areas where the DT model and the ACPI model clashed.

-- 
ciao,
al
-----------------------------------
Al Stone
Software Engineer
Red Hat, Inc.
ahs3@...hat.com
-----------------------------------

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ