From: Jean Delvare <jdelvare@suse.de>
To: Gary Hade <garyhade@us.ibm.com>
Cc: Huang Ying <ying.huang@intel.com>, Len Brown <lenb@kernel.org>,
linux-acpi@vger.kernel.org, hui.xiao@linux.intel.com
Subject: Re: [PATCH] ACPI, APEI: Fixup common access width firmware bug
Date: Fri, 15 Jun 2012 13:40:34 +0200 [thread overview]
Message-ID: <1339760434.4288.20.camel@amber.site> (raw)
In-Reply-To: <20120614170752.GB1999@us.ibm.com>
Hi Gary,
Le jeudi 14 juin 2012 à 10:07 -0700, Gary Hade a écrit :
> On Thu, Jun 14, 2012 at 10:35:11AM +0200, Jean Delvare wrote:
> > I see it as a firmware bug, nothing else
>
> That was my strong feeling but since the number of sightings
> seems to be on the increase, I thought it might be good to talk
> about whether our interpretation is actually correct.
It's always good to ensure we got things right, sure. WRT to the number
of faulty systems, I wouldn't jump to any conclusion. It is sufficient
to have a bug in the reference BIOS code in order to see the same bug
spread across boards and vendors all around.
> > (although I am still waiting
> > for Asus to reply on this.) And if it really isn't a bug, I can only
> > read it as "we have a 32-bit register that can only be read 8-bit at a
> > time so please issue 4 8-bit reads and build up a 32-bit value out of
> > these." And certainly not as "don't touch the upper 24-bits."
>
> It will definitely be interesting to see what you hear from Asus.
If I ever hear something... No news yet :(
> Multiple reads or writes to access all the bits in a register
> does _not_ sound like a reasonable interpretation of the ACPI
> spec to me.
Well, I can imagine that some hardware has (or has had) such
limitations, and the ACPI spec authors may have wanted to play it safe
and make it possible to describe this case. I didn't mean that I expect
it to be the case for my Asus board - I still believe it is a simple
BIOS bug here.
--
Jean Delvare
Suse L3
--
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:[~2012-06-15 11:40 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-12 8:43 [PATCH] ACPI, APEI: Fixup common access width firmware bug Jean Delvare
2012-06-12 8:46 ` Huang Ying
2012-06-14 1:09 ` Gary Hade
2012-06-14 8:35 ` Jean Delvare
2012-06-14 17:07 ` Gary Hade
2012-06-15 11:40 ` Jean Delvare [this message]
2012-07-14 15:02 ` Len Brown
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=1339760434.4288.20.camel@amber.site \
--to=jdelvare@suse.de \
--cc=garyhade@us.ibm.com \
--cc=hui.xiao@linux.intel.com \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).