linux-kernel - [PATCH 0/2] PCI Hotplug: acpiphp wants a 64-bit

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <20081211181242.GD18309@ldl.fc.hp.com>
Date:	Thu, 11 Dec 2008 11:12:42 -0700
From:	Alex Chiang <achiang@...com>
To:	Jesse Barnes <jbarnes@...tuousgeek.org>
Cc:	justin.chen@...com, linux-pci <linux-pci@...r.kernel.org>,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: [PATCH 0/2] PCI Hotplug: acpiphp wants a 64-bit _SUN

Hi Jesse,

Here are two patches for acpiphp.

Although Willy's patch 27663c5855b10af9ec67bc7dfba001426ba21222
(ACPI: Change acpi_evaluate_integer to support 64-bit on 32-bit
kernels) is now in, the problem we were initially trying to fix
before discovering that patch still exists.

The problem is that on certain HP systems, the _SUN method does
utilize the full 64 bits. Declaring sun in struct acpiphp_slot as
a u32 leads to name collisions on our systems.

The first patch from Justin changes the declaration of sun to
unsigned long long. It has been tested and verified that it fixes
the name collision issue on our machines.

I also did a build test in a 32-bit x86 environment to make sure
we don't get any compiler warnings, and it was clean.

Please consider that patch for 2.6.28. It's late-breaking, but I
feel is low-risk.

The second patch is a mere whitespace patch. Since I was in the
file anyway, I figured I'd clean it up a bit.

[setting 'let c_space_errors=1' in a .vimrc shows all kinds of
wonderful stuff ;) ]

Thanks.

/ac

--
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/