All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Jan Beulich" <jbeulich@novell.com>
To: "Robert Moore" <robert.moore@intel.com>,
	"Andi Kleen" <ak@linux.intel.com>
Cc: "Andrew Paprocki" <andrew@ishiboo.com>,
	"Len Brown" <lenb@kernel.org>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"LKML" <linux-kernel@vger.kernel.org>
Subject: RE: ACPI WARNING: at drivers/acpi/tables/tbfadt.c:348acpi_tb_create_local_fadt+0x147/0x2f4()
Date: Fri, 18 Jul 2008 09:43:04 +0100	[thread overview]
Message-ID: <488073B8.76E4.0078.0@novell.com> (raw)
In-Reply-To: <9D39833986E69849A2A8E74C1078B6B3ADFA66@orsmsx415.amr.corp.intel.com>

>>> "Moore, Robert" <robert.moore@intel.com> 17.07.08 19:20 >>>
>So far, in the number of the cases like this that I've seen, it's the v2
>fields that have problems. Perhaps the heuristic should be something
>like "if there is an inconsistency between the v1 and v2 fields, fall
>back to v1". 

While extending the patch to do so, I realize that other v2 fields are
used as-is, no matter whether their bit_width (or other fields) are
wrong. Is that perhaps why hardware/hwregs.c uses hard-coded
constants rather than the specified widths? If so (and if the v1 fields
are considered reliable), shouldn't the v2 ones be sanity-checked
against the v1 ones and then the specified widths be used as intended
by the spec?

Jan


  parent reply	other threads:[~2008-07-18  8:42 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-17  2:29 ACPI WARNING: at drivers/acpi/tables/tbfadt.c:348 acpi_tb_create_local_fadt+0x147/0x2f4() Andrew Paprocki
2008-07-17  3:34 ` Andrew Paprocki
2008-07-17  8:59   ` Jan Beulich
2008-07-17  9:06     ` Andi Kleen
2008-07-17  9:14       ` Jan Beulich
2008-07-17 12:28         ` Andi Kleen
2008-07-17 13:03           ` Andrew Paprocki
2008-07-17 13:58             ` Jan Beulich
2008-07-17 14:32               ` Andrew Paprocki
2008-07-17 15:30                 ` Jan Beulich
2008-07-17 17:20                   ` ACPI WARNING: at drivers/acpi/tables/tbfadt.c:348acpi_tb_create_local_fadt+0x147/0x2f4() Moore, Robert
2008-07-17 17:40                     ` Andi Kleen
2008-07-18  7:53                       ` Jan Beulich
2008-07-18  8:43                     ` Jan Beulich [this message]
2008-07-18 16:52                       ` ACPI WARNING: atdrivers/acpi/tables/tbfadt.c:348acpi_tb_create_local_fadt+0x147/0x2f4() Moore, Robert
2008-07-18  9:48                     ` ACPI WARNING: at drivers/acpi/tables/tbfadt.c:348acpi_tb_create_local_fadt+0x147/0x2f4() Jan Beulich
2008-07-17  9:00   ` ACPI WARNING: at drivers/acpi/tables/tbfadt.c:348 acpi_tb_create_local_fadt+0x147/0x2f4() Andi Kleen

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=488073B8.76E4.0078.0@novell.com \
    --to=jbeulich@novell.com \
    --cc=ak@linux.intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=andrew@ishiboo.com \
    --cc=lenb@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=robert.moore@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.