From: Bjorn Helgaas <bhelgaas@google.com>
To: Thomas Renninger <trenn@suse.de>
Cc: Myron Stowe <myron.stowe@redhat.com>,
Len Brown <len.brown@intel.com>,
bondd@us.ibm.com, lenb@kernel.org, linux-acpi@vger.kernel.org,
rjw@sisk.pl, ying.huang@intel.com
Subject: Re: [PATCH 0/2] ACPI: Re-factor and remove ./drivers/acpi/atomicio.[ch]
Date: Thu, 3 Nov 2011 07:53:09 -0600 [thread overview]
Message-ID: <CAErSpo7CTFTCQRPJtAqYM2VnhV4nOWX799YrwCBZTufGZ7rMEQ@mail.gmail.com> (raw)
In-Reply-To: <201111031016.52676.trenn@suse.de>
On Thu, Nov 3, 2011 at 3:16 AM, Thomas Renninger <trenn@suse.de> wrote:
> On Monday, October 31, 2011 04:51:07 PM Bjorn Helgaas wrote:
>> On Mon, Oct 31, 2011 at 4:33 AM, Thomas Renninger <trenn@suse.de> wrote:
>
>> Seems like these are BIOS bugs. Do we know for sure that Windows
>> consumes this information that seems to be wrong? Have you had a
>> conversation with the vendor about whether the BIOS is at fault here?
> Such closed specifications between a major OS and specific HW vendors
> should be forbidden by law and I expect in some countries you'll win
> if you contest this contract in a high enough court...
> APEI is based on the Windows WHEA specification which only specific
> vendors can retrieve from Windows if they sign an NDA contract.
> I could imagine there you find details about the GAS structure usage
> in WHEA/APEI tables the way Windows like it.
>
> After looking at quite a lot APEI tables and their bit width, byte access
> and mask values, I am pretty sure bit width is ignored on Windows.
> Or say, if these tables are used, access width is always correct while
> bit width is not.
>
>> If we make Linux ignore the bit_width, that might "fix" these boxes
>> with broken BIOSes, but at the cost of breaking a box that uses
>> bit_width correctly.
> None of the "broken bit width" boxes I looked at should break if
> access width is used.
Yes, but bit_width is a standard part of the ACPI generic address
structure, and there's nothing to prevent a future BIOS from using it
and expecting it to work as documented. If we make Linux
ignore/override the bit_width now, we'll build a legacy of machines
that depend on the fact that we ignore it, and then we would have no
way to deal with future machines that might expect us to pay attention
to it.
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2011-11-03 13:53 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-29 21:59 [PATCH 0/2] ACPI: Re-factor and remove ./drivers/acpi/atomicio.[ch] Myron Stowe
2011-09-29 21:59 ` [PATCH 1/2] ACPI: Export interfaces for ioremapping/iounmapping ACPI registers Myron Stowe
2011-11-06 12:49 ` Rafael J. Wysocki
2011-09-29 21:59 ` [PATCH 2/2] ACPI: Convert acpi_pre_map_gar()/acpi_atomic_read() and remove ./drivers/acpi/atomicio.[ch] Myron Stowe
2011-11-06 13:05 ` Rafael J. Wysocki
2011-10-28 1:49 ` [PATCH 0/2] ACPI: Re-factor " Thomas Renninger
2011-10-28 15:03 ` Bjorn Helgaas
2011-10-31 10:47 ` Thomas Renninger
2011-11-03 1:42 ` Myron Stowe
2011-11-06 13:30 ` Rafael J. Wysocki
2011-11-04 23:54 ` Myron Stowe
2011-11-05 2:42 ` Thomas Renninger
2011-11-06 13:42 ` Rafael J. Wysocki
2011-11-15 18:45 ` Bjorn Helgaas
2011-11-06 13:25 ` Rafael J. Wysocki
2011-11-06 13:23 ` Rafael J. Wysocki
2011-10-28 15:14 ` Bjorn Helgaas
2011-10-31 10:33 ` Thomas Renninger
2011-10-31 15:51 ` Bjorn Helgaas
2011-11-03 9:16 ` Thomas Renninger
2011-11-03 13:53 ` Bjorn Helgaas [this message]
2011-11-03 16:18 ` Thomas Renninger
2011-11-03 16:44 ` Myron Stowe
2011-11-04 2:16 ` Thomas Renninger
2011-11-04 1:55 ` Myron Stowe
2011-10-28 22:40 ` Myron Stowe
2011-11-06 13:19 ` Rafael J. Wysocki
2011-11-03 16:31 ` Thomas Renninger
2011-11-04 0:56 ` Huang Ying
2011-11-04 2:24 ` Thomas Renninger
2011-11-04 1:32 ` Huang Ying
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAErSpo7CTFTCQRPJtAqYM2VnhV4nOWX799YrwCBZTufGZ7rMEQ@mail.gmail.com \
--to=bhelgaas@google.com \
--cc=bondd@us.ibm.com \
--cc=len.brown@intel.com \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=myron.stowe@redhat.com \
--cc=rjw@sisk.pl \
--cc=trenn@suse.de \
--cc=ying.huang@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.