| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Thu, 22 Jan 2015 03:24:52 +0000
From: "Zheng, Lv" <lv.zheng@...el.com>
To: Jiang Liu <jiang.liu@...ux.intel.com>,
"Rafael J. Wysocki" <rjw@...ysocki.net>,
Thomas Gleixner <tglx@...utronix.de>,
Bjorn Helgaas <bhelgaas@...gle.com>,
Yinghai Lu <yinghai@...nel.org>,
Borislav Petkov <bp@...en8.de>,
"Moore, Robert" <robert.moore@...el.com>,
"Wysocki, Rafael J" <rafael.j.wysocki@...el.com>,
Len Brown <lenb@...nel.org>
CC: "Luck, Tony" <tony.luck@...el.com>,
"x86@...nel.org" <x86@...nel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
"devel@...ica.org" <devel@...ica.org>
Subject: RE: [RFC Patch 05/19] ACPI: Provide union for address_space64 and
ext_address_space64
Hi, Gerry
> From: Jiang Liu [mailto:jiang.liu@...ux.intel.com]
> Sent: Thursday, January 22, 2015 10:58 AM
>
> On 2015/1/22 10:32, Zheng, Lv wrote:
> > Hi, Thomas and Jiang
> >
> >> From: Jiang Liu [mailto:jiang.liu@...ux.intel.com]
> >> Sent: Thursday, January 08, 2015 10:33 AM
> >>
> >> From: Thomas Gleixner <tglx@...utronix.de>
> >>
> >> address_space64 and ext_address_space64 share substracts just at
> >> different offsets. To unify the parsing functions implement the two
> >> structs as unions of their substructs, so we can extract the shared
> >> data.
> >>
> >> Signed-off-by: Thomas Gleixner <tglx@...utronix.de>
> >> Signed-off-by: Jiang Liu <jiang.liu@...ux.intel.com>
> >> ---
> >> include/acpi/acrestyp.h | 49 ++++++++++++++++++++++++++++++++++-------------
> >> 1 file changed, 36 insertions(+), 13 deletions(-)
> >>
> >> diff --git a/include/acpi/acrestyp.h b/include/acpi/acrestyp.h
> >> index eb760ca0b2e0..307d5b2605c8 100644
> >> --- a/include/acpi/acrestyp.h
> >> +++ b/include/acpi/acrestyp.h
> >> @@ -326,23 +326,46 @@ struct acpi_resource_address32 {
> >> struct acpi_resource_source resource_source;
> >> };
> >>
> >> -struct acpi_resource_address64 {
> >> - ACPI_RESOURCE_ADDRESS_COMMON u64 granularity;
> >> - u64 minimum;
> >> - u64 maximum;
> >> - u64 translation_offset;
> >> +#define ACPI_RESOURCE_ADDRESS64_COMMON \
> >> + u64 granularity; \
> >> + u64 minimum; \
> >> + u64 maximum; \
> >> + u64 translation_offset; \
> >> u64 address_length;
> >> - struct acpi_resource_source resource_source;
> >> +
> >> +struct acpi_resource_address64_common {
> >> +ACPI_RESOURCE_ADDRESS64_COMMON};
> >> +
> >> +struct acpi_resource_address64 {
> >> + union {
> >> + struct {
> >> + ACPI_RESOURCE_ADDRESS_COMMON
> >> + ACPI_RESOURCE_ADDRESS64_COMMON
> >> + struct acpi_resource_source resource_source;
> >> + };
> >
> > This looks wrong to ACPICA upstream.
> >
> >> + struct {
> >> + struct acpi_resource_address base;
> >> + struct acpi_resource_address64_common addr;
> >> + struct acpi_resource_source resource_source;
> >> + } common;
> >> + };
> >> };
> >
> > And this.
> > Though anonymous structs/unions are now C11 standard, I still didn't see it used in the ACPICA upstream.
> > It could be a problem if someone still compiles ACPICA using old compilers.
> >
> >>
> >> struct acpi_resource_extended_address64 {
> >> - ACPI_RESOURCE_ADDRESS_COMMON u8 revision_ID;
> >> - u64 granularity;
> >> - u64 minimum;
> >> - u64 maximum;
> >> - u64 translation_offset;
> >> - u64 address_length;
> >> - u64 type_specific;
> >> + union {
> >> + struct {
> >> + ACPI_RESOURCE_ADDRESS_COMMON
> >> + u8 revision_ID;
> >> + ACPI_RESOURCE_ADDRESS64_COMMON
> >> + u64 type_specific;
> >> + };
> >
> > Ditto.
> >
> >> + struct {
> >> + struct acpi_resource_address base;
> >> + u8 revision_ID;
> >> + struct acpi_resource_address64_common addr;
> >> + u64 type_specific;
> >> + } common;
> >> + };
> >
> > Ditto.
> >
> > I think what you want is the ability to access common.addr and common.base from different resource address64 types.
> > So we can achieve this directly in the ACPICA upstream without using the union.
> >
> > I tried this in the ACPICA upstream and the result is:
> > https://github.com/zetalog/acpica/commit/0f4ed510
> > Let me send its linuxized version after this email.
> Hi Lv,
> Thanks for your great support:)
> What's the normal process to propagate this patch into
> linux kernel? Or how long will it take? We have another hotplug
> patch set which depends on this patch set, then depends on this
> ACPICA core change.
There won't be divergences if things are proceeded in this way:
If we can reach an agreement on the linuxized version, then it can be merged directly by Rafael.
And I'll zap it from the ACPICA release series.
Thanks and best regards
-Lv
> Regards!
> Gerry
> >
> > Thanks and best regards
> > -Lv
> >
> >> };
> >>
> >> struct acpi_resource_extended_irq {
> >> --
> >> 1.7.10.4
> >
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists