Re: [Linaro-acpi] [PATCH] ACPI: ARM: link ARM and the ACPI reduced hardware profile

On 11/14/2013 10:38 AM, Andrea Gallo wrote:

Hi Al,

I fully share your thoughts, my suggestion was to have the two compile options independent though both must be set to run on current ARM platforms.

Aha. There are separate CONFIG_ACPI and CONFIG_ACPI_REDUCED_HARDWARE options. The patch only says if you choose ACPI, *and* you choose an ARM architecture, CONFIG_ACPI_REDUCED_HARDWARE is automatically set true. It's also a one line change in the Kconfig should anyone ever wish to remove that restriction (though I may have to slap them for suggesting it :).

I have anyway no problem to accept your current withdrawal of your previous withdrawal and look at further withdrawal only when any ARM vendor may come up with such hybrid beasts, if any.

LOL. Um, yeah. I _think_ I followed that :).

Graeme: once acked, could you please apply? Thanks.

Thanks for your guidance and also for your patience :-)

/Andrea

On 14 November 2013 18:31, Al Stone <al.stone@linaro.org mailto:al.stone@linaro.org> wrote:

On 11/14/2013 03:27 AM, Tomasz Nowicki wrote:



    On 14.11.2013 10:10, Graeme Gregory wrote:

        On Wed, Nov 13, 2013 at 01:08:25PM -0700, Al Stone wrote:

            On 11/13/2013 01:44 AM, Hanjun Guo wrote:

                On 2013-11-13 15:59, Andrea Gallo wrote:

                    Al

                    I am not sure about this.

                    What if one day we have ARM vendors showing up
                    with x86-like fake
                    registers just to be fully fixed hw profile
                    compliant and feeling
                    they could be safer than with the resuced hw
                    profile, for whichever
                    reason?

                    I would suggest we have two flags, which would
                    be both set in 99.9%
                    of ARM platforms but maybe there could be a 0.1%
                    where it is ARM
                    and fixed profile one day?


                I agree with Andrea.
                we can't just let ARM = HW-reduced, some OEM vendors
                may implement
                ACPI hardware one day.

                Thanks
                Hanjun


            Hrm.  I was unaware that some vendors were already going
            down
            the path of full ACPI hardware.  In that case, we should
            leave
            things as they are and if a particular vendor wants to have
            reduced HW the default (or not), then they can do that
            in their
            specific Kconfig items.  So, I'm withdrawing this patch as
            unneeded.


        I very much disagree with Andrea and Hanjun, we cannot
        design software
        for an infinite number of "what if?". Especially when its a
        complex
        system which requires testing. I very much doubt someone
        will come up
        with an emulated non reduced hardware platform on arm that
        just works on
        first boot. Considering they will have to do a lot of
        testing and
        probably
        code changes then one line in a config file is not a major
        extra bit of
        work.

        Also consider if we do not push this patch we will be
        answering the
        question
        approximately once a day of why our ARM acpi code core dumps
        due to
        random
        memory access because someone forgot to set that flag in
        their .config.

        Graeme


    I also would like to see hardware reduce selected along with
    ARM. This
    way vendors are somehow forced to implement new feature in
    generic way,
    what means all flavour of ARM platforms can use it (eventual others
    platforms too). Personally, my feeling is that fixed version of
    ACPI is
    only for x86 and hardware reduce is right direction.

    Tomasz


I think I may have answered in haste (it has been a *long* week
already and I've been tired).

The more I think about this, I realize I have to withdraw my
withdrawal :).  The issue is that the reduced HW profile is
meant to be more architecturally neutral, while the full ACPI
profile is actually x86-dependent.  Not only is it x86 specific,
it carries with it a whole raft of baggage from pre-ACPI 5.0
legacy systems (there are Atom systems using reduced HW mode
just to avoid this cruft).

As the most egregious example, if an ARM vendor is to make an
SoC that implements the full ACPI profile, they *must* implement
an NMI interrupt line that behaves like a real NMI (none of this
priority stuff).  If they do, is that really an ARM processor?
I don't think so -- it's some sort of hybrid beast.  The same
problem exists for SCI, and possibly MCE and others that are
very specific to x86 *and* impose HW requirements on the SoC
vendors to step outside of a normal ARM implementation.

The next layer is that the FACS table would also impose the
requirement to implement various registers with very specific
semantics, again specific to x86, and outside the definition
of ARM.

The final thought that occurs to me is that without reduced HW
profile, we *must* implement a single global lock in ACPI.  That
lock could be abused in a bazillion different ways that would
end up creating a single global lock in the kernel.  Since there
is by definition no ACPI global lock in reduced HW, that cannot
happen.

So, now that I think about it more, we *must* link reduced HW and
ARM ACPI unless we want to force HW requirements on SoC vendors
that would (a) force them to add x86-specific features to their
ARM hardware, and (b) force them to support legacy x86 hardware
features that even Intel is moving away from.

--
ciao,
al
------------------------------__-----
Al Stone
Software Engineer
Linaro Enterprise Group
al.stone@linaro.org <mailto:al.stone@linaro.org>
------------------------------__-----

_________________________________________________
Linaro-acpi mailing list
Linaro-acpi@lists.linaro.org <mailto:Linaro-acpi@lists.linaro.org>
http://lists.linaro.org/__mailman/listinfo/linaro-acpi
<http://lists.linaro.org/mailman/listinfo/linaro-acpi>