linux-kernel - Re: AW: AW: [PATCH] x86: HPET force enable for Soekris net6501

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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <a1204336-ad8d-4f2f-8078-24f043f123e6@email.android.com>
Date:	Fri, 14 Feb 2014 10:39:40 -0800
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Thomas Gleixner <tglx@...utronix.de>
CC:	Conrad Kostecki <ck@...rad-kostecki.de>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"x86@...nel.org" <x86@...nel.org>,
	"mingo@...hat.com" <mingo@...hat.com>
Subject: Re: AW: AW: [PATCH] x86: HPET force enable for Soekris net6501

We could also just add an ACPI table... same concept.  Still need to find it.

On February 14, 2014 10:38:24 AM PST, Thomas Gleixner <tglx@...utronix.de> wrote:
>On Fri, 14 Feb 2014, H. Peter Anvin wrote:
>> On 02/14/2014 10:21 AM, Thomas Gleixner wrote:
>> > I wish we could just use devicetree for such cases and fix the crud
>> > ourself.
>> > 
>> 
>> We'd have to identify the platform, which is the main problem.  Right
>> now we support quirking for DMI or PCI, but I don't think we do for
>MPTABLE.
>
>My point is that device tree support for some basic stuff like
>hpet/ioapic and such would allow people like Conrad to avoid the
>stupid hackery of quirks.
>
>Building your own DT requires to read a datasheet as does hacking a
>quirk, but its definitely simpler. And we can collect the DTs for
>known boards either in the kernel or in some external repository.
>
>People who are dealing with embedded stuff are not those who are
>frightened by datasheets and building a custom kernel with some extra
>blob.
>
>I bet Conrad is also stuck with PIC on the E6xx CPU and that's a major
>PITA. I have such a board as well and it simply sucks.
>
>Now you can't hack an ioapic quirk because that's way to complex, but
>we have proven with the ce4100 that it is reasonably simple to get
>that stuff working nicely when you can read a datasheet. If we could
>generalize that for a few crucial devices that would help a lot.
>
>When I asked the board vendor why there are no acpi tables in the
>device, I got the answer, that this is an embedded board and the
>"BIOS" built with BLDK does not support that. We all know that's not
>true, but how does that help?
>
>The people who brought up the initial target OS (WinCE) on that board
>worked around the lack of ACPI by hacking HPET support into the CE
>preloader and switched all device drivers to use MSI because CE failed
>to handle the PIC properly. That avoided that they needed to hack the
>ioapic into submission as well.
>
>That's the sad reality. And we have to cope with these boards whether
>we like it or not.
>
>Thanks,
>
>	tglx

-- 
Sent from my mobile phone.  Please pardon brevity and lack of formatting.
--
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/