linux-kernel - Re: [tip:x86/urgent] x86: Remove usedac in feature-removal-schedule.txt

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:	Mon, 14 Dec 2009 09:57:55 -0500
From:	Valdis.Kletnieks@...edu
To:	mingo@...hat.com, hpa@...or.com, linux-kernel@...r.kernel.org,
	fujita.tomonori@....ntt.co.jp, tglx@...utronix.de,
	amwang@...hat.com, mingo@...e.hu
Cc:	linux-tip-commits@...r.kernel.org
Subject: Re: [tip:x86/urgent] x86: Remove usedac in feature-removal-schedule.txt

On Mon, 14 Dec 2009 07:58:01 GMT, tip-bot for FUJITA Tomonori said:
> Commit-ID:  06f8bda8324fa8bf39eed81d8b3df08063a37696

> x86: Remove usedac in feature-removal-schedule.txt

> The usedac option enables us to stop via_no_dac() setting
> forbid_dac to 1. That is, someone who uses VIA bridges can use
> DAC with this option even if some of VIA bridges seem to be
> broken about DAC.

Does there exist real hardware where this makes sense?  If the chipset
detects as "broken-DAC", is it in fact safe to use?  Or is it similar to
the 'force-enable HPET' code for some older boxes, where the HPET was in
fact there but simply not advertised, so going ahead and using it was
in fact perfectly safe? Allowing the use of "working but not advertised"
is probably a good thing, allowing the use of known-broken probably isn't.

If it's just unadvertised, I wonder if if there's a way to write a quirk
for VIA systems that will detect the situation and enable the support?

Content of type "application/pgp-signature" skipped