[ACPI] Re: asus_acpi still broken on Samsung P30/P35

[Linus T. <tor...@os...>]

On Wed, 21 Dec 2005, Hanno B=C3=B6ck wrote:
>=20
> This is not "some minor issue", this completely breaks the usage of cur=
rent=20
> vanilla-kernels on certain Hardware. Can please, please, please anyone =
in the=20
> position to do this take care that this patch get's accepted before 2.6=
.15?
>=20
> The patch is available inside mm-sources or here:
> http://www.int21.de/samsung/p30-2.6.14.diff
>=20
> If I should send it to anyone else or if there's anything I can do to h=
elp=20
> fixing this, I'm glad to help.

Last I saw this patch, I wrote this reply (the patch above is still=20
broken). Nobody ever came back to me on it.

			Linus

---
Date: Tue, 13 Dec 2005 21:15:56 -0800 (PST)
From: Linus Torvalds <tor...@os...>
To: Carl-Daniel Hailfinger <c-d...@gm...>
cc: Greg KH <gr...@kr...>,=20
    Linux Kernel Mailing List <lin...@vg...>,=20
    st...@ke..., acpi-devel <acp...@li...>
Subject: Re: [PATCH] Fix oops in asus_acpi.c on Samsung P30/P35 Laptops

On Wed, 14 Dec 2005, Carl-Daniel Hailfinger wrote:
>=20
> The patch has been tested and verified, is shipped in the
> SUSE 10.0 kernel and does not cause any regressions.

I'd be _much_ happier if

 - the patch wasn't totally whitespace-damaged (your mailer seems=20
   to not only remove spaces at the end of lines, it _also_ adds them to=20
   the beginning when there was another space there, as far as I can tell=
)

   Being right "on average" thanks to having two different bugs does not =
a=20
   good mailer make.

 - you were to separate out the oops-fixing code from the code that adds=20
   handling for that (strange?) model type logic.

   It seems that the _oops_ is because the later paths just assume that=20
   it's a ACPI_TYPE_STRING and will dereference "model->string.pointer"=20
   regardless of whether that is true or not. And you add a test for=20
   ACPI_TYPE_INTEGER, however, you do _not_ fix the oops for any other=20
   type, so the exact _same_ bug is still waiting to happen if there is=20
   some other strange ACPI table entry some day.

So I think the proper fix is to _first_ just do something like

	if (model->type !=3D ACPI_TYPE_STRING)
		goto unknown;

which should fix the oops (no?), and then handling ACPI_TYPE_INTEGER abov=
e=20
that as one case would be a separate patch.

		Linus