[PATCH] remove usedac in feature-removal-schedule.txt

[PATCH] remove usedac in feature-removal-schedule.txt

[FUJITA Tomonori]

The reason of removal, "replaced by allowdac and no dac combination"
is incorrect. There is no way to do the same thing with "allowdac" and
"nodac" combination.

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.

Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
---
 Documentation/feature-removal-schedule.txt |    7 -------
 1 files changed, 0 insertions(+), 7 deletions(-)

diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt
index 2a4d779..eb2c138 100644
--- a/Documentation/feature-removal-schedule.txt
+++ b/Documentation/feature-removal-schedule.txt
@@ -291,13 +291,6 @@ Who:	Michael Buesch <mb@bu3sch.de>
 
 ---------------------------
 
-What:	usedac i386 kernel parameter
-When:	2.6.27
-Why:	replaced by allowdac and no dac combination
-Who:	Glauber Costa <gcosta@redhat.com>
-
----------------------------
-
 What: print_fn_descriptor_symbol()
 When: October 2009
 Why:  The %pF vsprintf format provides the same functionality in a
-- 
1.5.6.5

Re: [PATCH] remove usedac in feature-removal-schedule.txt

[Cong Wang]

FUJITA Tomonori wrote:
> The reason of removal, "replaced by allowdac and no dac combination"
> is incorrect. There is no way to do the same thing with "allowdac" and
> "nodac" combination.
> 
> 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.
> 
> Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>


Hi,

This sounds reasonable for me.

Acked-by: WANG Cong <amwang@redhat.com>

> ---
>  Documentation/feature-removal-schedule.txt |    7 -------
>  1 files changed, 0 insertions(+), 7 deletions(-)
> 
> diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt
> index 2a4d779..eb2c138 100644
> --- a/Documentation/feature-removal-schedule.txt
> +++ b/Documentation/feature-removal-schedule.txt
> @@ -291,13 +291,6 @@ Who:	Michael Buesch <mb@bu3sch.de>
>  
>  ---------------------------
>  
> -What:	usedac i386 kernel parameter
> -When:	2.6.27
> -Why:	replaced by allowdac and no dac combination
> -Who:	Glauber Costa <gcosta@redhat.com>
> -
> ----------------------------
> -
>  What: print_fn_descriptor_symbol()
>  When: October 2009
>  Why:  The %pF vsprintf format provides the same functionality in a

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

[tip-bot for FUJITA Tomonori]

Commit-ID:  06f8bda8324fa8bf39eed81d8b3df08063a37696
Gitweb:     http://git.kernel.org/tip/06f8bda8324fa8bf39eed81d8b3df08063a37696
Author:     FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
AuthorDate: Mon, 14 Dec 2009 11:06:15 +0900
Committer:  Ingo Molnar <mingo@elte.hu>
CommitDate: Mon, 14 Dec 2009 08:53:54 +0100

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

The reason of removal, "replaced by allowdac and no dac
combination" is incorrect. There is no way to do the same thing
with "allowdac" and "nodac" combination.

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.

Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Acked-by: WANG Cong <amwang@redhat.com>
Cc: gcosta@redhat.com
LKML-Reference: <20091214104423X.fujita.tomonori@lab.ntt.co.jp>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
 Documentation/feature-removal-schedule.txt |    7 -------
 1 files changed, 0 insertions(+), 7 deletions(-)

diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt
index 2a4d779..eb2c138 100644
--- a/Documentation/feature-removal-schedule.txt
+++ b/Documentation/feature-removal-schedule.txt
@@ -291,13 +291,6 @@ Who:	Michael Buesch <mb@bu3sch.de>
 
 ---------------------------
 
-What:	usedac i386 kernel parameter
-When:	2.6.27
-Why:	replaced by allowdac and no dac combination
-Who:	Glauber Costa <gcosta@redhat.com>
-
----------------------------
-
 What: print_fn_descriptor_symbol()
 When: October 2009
 Why:  The %pF vsprintf format provides the same functionality in a

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

[Valdis.Kletnieks]

[-- 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 --]

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

[FUJITA Tomonori]

On Mon, 14 Dec 2009 09:57:55 -0500
Valdis.Kletnieks@vt.edu wrote:

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

Not safe. Probably, you would see data corruption.

arch/x86/kernel/pci-dma.c says:

/* Many VIA bridges seem to corrupt data for DAC. Disable it here */


Seems that some of VIA bridges were fine. So this option made sense
with some hardware. I'm not sure if there are still users of this
option now.


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

I guess that we could however it doesn't worth adding tricks for old
hardware.