Karol,
Do you have an update of your asus driver in the pipeline
that addresses this?
thanks,
-Len
>-----Original Message-----
>From: Linus Torvalds [mailto:[email protected]]
>Sent: Wednesday, December 21, 2005 1:37 PM
>To: Hanno Böck
>Cc: Andrew Morton; Brown, Len;
>[email protected];
>[email protected]; Karol Kozimor; Christian Aichinger
>Subject: Re: asus_acpi still broken on Samsung P30/P35
>
>
>
>On Wed, 21 Dec 2005, Hanno Böck wrote:
>>
>> This is not "some minor issue", this completely breaks the
>usage of current
>> vanilla-kernels on certain Hardware. Can please, please,
>please anyone in the
>> position to do this take care that this patch get's accepted
>before 2.6.15?
>>
>> The patch is available inside mm-sources or here:
>> http://www.int21.de/samsung/p30-2.6.14.diff
>>
>> If I should send it to anyone else or if there's anything I
>can do to help
>> fixing this, I'm glad to help.
>
>Last I saw this patch, I wrote this reply (the patch above is still
>broken). Nobody ever came back to me on it.
>
> Linus
>
>---
>Date: Tue, 13 Dec 2005 21:15:56 -0800 (PST)
>From: Linus Torvalds <[email protected]>
>To: Carl-Daniel Hailfinger <[email protected]>
>cc: Greg KH <[email protected]>,
> Linux Kernel Mailing List <[email protected]>,
> [email protected], acpi-devel <[email protected]>
>Subject: Re: [PATCH] Fix oops in asus_acpi.c on Samsung P30/P35 Laptops
>
>On Wed, 14 Dec 2005, Carl-Daniel Hailfinger wrote:
>>
>> 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
> to not only remove spaces at the end of lines, it _also_
>adds them to
> 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
> good mailer make.
>
> - you were to separate out the oops-fixing code from the code
>that adds
> handling for that (strange?) model type logic.
>
> It seems that the _oops_ is because the later paths just
>assume that
> it's a ACPI_TYPE_STRING and will dereference
>"model->string.pointer"
> regardless of whether that is true or not. And you add a test for
> ACPI_TYPE_INTEGER, however, you do _not_ fix the oops for any other
> type, so the exact _same_ bug is still waiting to happen if
>there is
> some other strange ACPI table entry some day.
>
>So I think the proper fix is to _first_ just do something like
>
> if (model->type != ACPI_TYPE_STRING)
> goto unknown;
>
>which should fix the oops (no?), and then handling
>ACPI_TYPE_INTEGER above
>that as one case would be a separate patch.
>
> Linus
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
