All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Zheng, Lv" <lv.zheng@intel.com>
To: "Luck, Tony" <tony.luck@intel.com>,
	"Wysocki, Rafael J" <rafael.j.wysocki@intel.com>,
	"Brown, Len" <len.brown@intel.com>
Cc: Lv Zheng <zetalog@gmail.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
	"Yu, Fenghua" <fenghua.yu@intel.com>
Subject: RE: [PATCH 2/2] ACPICA: acpidump: Remove translation protection on integer types.
Date: Tue, 18 Feb 2014 00:57:29 +0000	[thread overview]
Message-ID: <1AE640813FDE7649BE1B193DEA596E88024B105B@SHSMSX101.ccr.corp.intel.com> (raw)
In-Reply-To: <3908561D78D1C84285E8C5FCA982C28F31DC88AC@ORSMSX106.amr.corp.intel.com>

Hi, Tony

> From: Luck, Tony
> Sent: Friday, February 14, 2014 7:35 AM
> 
> >    All definitions are equal except ACPI_UINT64_MAX for CONFIG_IA64.  It
> >    is changed from sizeof(unsigned long) to sizeof(unsigned long long).
> >    By investigation, 64bit Linux kernel build is LP64 compliant, i.e.,
> >    sizeof(long) and (pointer) are 64.  As sizeof(unsigned long) equals to
> >    sizeof(unsigned long long) on IA64 platform where CONFIG_64BIT cannot be
> >    disabled, this change actually will not affect the value of
> >    ACPI_UINT64_MAX on IA64 platforms.
> 
> This all looks correct to me - it really shouldn't make any difference
> to ia64 whether we use "long" or "long long" ... both are 8-byte entities.
> The compiler would complain in some places if you mixed & matched
> incorrectly (e.g. printk("val = %ld\n", val); will give a warning if val has
> been switched from "long" to "long long" and the format would need
> to change to "%lld").  But it looks like nothing like that happens as a
> result of this patch. All my ia64 configs build with no new warnings.
> 
> Boots OK too.

It looked scary to me that without applying this patch, Linux ACPICA was using the u64 defined by Linux but defining ACPI_UINT64_MAX to the value that could be different from sizeof(u64).
This patch can make them converged.  I was worrying about the regressions that could be triggered by this fix if there was something already dependent on this divergence.
Great to hear that there is no such dependency. :-)

Thanks and best regards
-Lv
 
> 
> -Tony

      parent reply	other threads:[~2014-02-18  0:57 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-11  2:51 [PATCH 0/2] ACPICA: Preparations of acpidump release automation Lv Zheng
2014-02-11  2:51 ` Lv Zheng
2014-02-11  2:51 ` [PATCH 1/2] ACPICA: acpidump: Add sparse declarators support Lv Zheng
2014-02-11  2:51   ` Lv Zheng
2014-02-11  2:51 ` [PATCH 2/2] ACPICA: acpidump: Remove translation protection on integer types Lv Zheng
2014-02-11  2:51   ` Lv Zheng
2014-02-13  2:44   ` Zheng, Lv
2014-02-13 23:34     ` Luck, Tony
2014-02-13 23:55       ` Rafael J. Wysocki
2014-02-18  0:57       ` Zheng, Lv [this message]

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=1AE640813FDE7649BE1B193DEA596E88024B105B@SHSMSX101.ccr.corp.intel.com \
    --to=lv.zheng@intel.com \
    --cc=fenghua.yu@intel.com \
    --cc=len.brown@intel.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rafael.j.wysocki@intel.com \
    --cc=tony.luck@intel.com \
    --cc=zetalog@gmail.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.