From: Valdis.Kletnieks@vt.edu
To: mingo@redhat.com, hpa@zytor.com, linux-kernel@vger.kernel.org,
fujita.tomonori@lab.ntt.co.jp, tglx@linutronix.de,
amwang@redhat.com, mingo@elte.hu
Cc: linux-tip-commits@vger.kernel.org
Subject: Re: [tip:x86/urgent] x86: Remove usedac in feature-removal-schedule.txt
Date: Mon, 14 Dec 2009 09:57:55 -0500 [thread overview]
Message-ID: <17113.1260802675@localhost> (raw)
In-Reply-To: Your message of "Mon, 14 Dec 2009 07:58:01 GMT." <tip-06f8bda8324fa8bf39eed81d8b3df08063a37696@git.kernel.org>
[-- Attachment #1: Type: text/plain, Size: 968 bytes --]
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?
[-- Attachment #2: Type: application/pgp-signature, Size: 227 bytes --]
next prev parent reply other threads:[~2009-12-14 14:58 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-14 2:06 [PATCH] remove usedac in feature-removal-schedule.txt FUJITA Tomonori
2009-12-14 7:50 ` Cong Wang
2009-12-14 7:58 ` [tip:x86/urgent] x86: Remove " tip-bot for FUJITA Tomonori
2009-12-14 14:57 ` Valdis.Kletnieks [this message]
2009-12-14 23:13 ` FUJITA Tomonori
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=17113.1260802675@localhost \
--to=valdis.kletnieks@vt.edu \
--cc=amwang@redhat.com \
--cc=fujita.tomonori@lab.ntt.co.jp \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-tip-commits@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=mingo@redhat.com \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox