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]

Date:	Fri, 14 Feb 2014 19:38:24 +0100 (CET)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	"H. Peter Anvin" <hpa@...or.com>
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

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

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