is there a value to CONFIG_NO_ATA_LEGACY?
in drivers/ata/libata-sff.c:
...
#if defined(CONFIG_NO_ATA_LEGACY)
/* Some platforms with PCI limits cannot address compat
port space. In that case we punt if their firmware has
left a device in compatibility mode */
if (legacy_mode) {
printk(KERN_ERR ata: Compatibility mode ATA is not
supported on this platform, skipping.\n);
return -EOPNOTSUPP;
}
#endif
...
there is no Kconfig file that defines that variable -- should that
test be removed? or is something eventually coming that defines it?
rday
--
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
Home page: http://crashcourse.ca
Fedora Cookbook:http://crashcourse.ca/wiki/index.php/Fedora_Cookbook
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: is there a value to CONFIG_NO_ATA_LEGACY?
On Sun, 10 Feb 2008, Alan Cox wrote:
On Sun, 10 Feb 2008 14:44:16 -0500 (EST)
Robert P. J. Day [EMAIL PROTECTED] wrote:
in drivers/ata/libata-sff.c:
...
#if defined(CONFIG_NO_ATA_LEGACY)
/* Some platforms with PCI limits cannot address compat
port space. In that case we punt if their firmware has
left a device in compatibility mode */
if (legacy_mode) {
printk(KERN_ERR ata: Compatibility mode ATA is not
supported on this platform, skipping.\n);
return -EOPNOTSUPP;
}
#endif
...
there is no Kconfig file that defines that variable -- should that
test be removed? or is something eventually coming that defines it?
It is used by some of the unsubmitted tree stuff certainly and is there
because some platforms will need it (eg FRV).
ok, good enough, i'm just trying to cull my list of unreferenced
Kconfig variables.
rday
--
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
Home page: http://crashcourse.ca
Fedora Cookbook:http://crashcourse.ca/wiki/index.php/Fedora_Cookbook
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] IDE: Remove inclusion of non-existent io_trace.h.
Signed-off-by: Robert P. J. Day [EMAIL PROTECTED]
---
the fact that this header file doesn't exist has apparently been
known for quite some time:
http://osdir.com/ml/linux.tape/2005-07/msg1.html
diff --git a/drivers/ide/ide-tape.c b/drivers/ide/ide-tape.c
index 1fa5794..e5a86a9 100644
--- a/drivers/ide/ide-tape.c
+++ b/drivers/ide/ide-tape.c
@@ -621,7 +621,6 @@ typedef struct os_dat_s {
*/
#define USE_IOTRACE0
#if USE_IOTRACE
-#include linux/io_trace.h
#define IO_IDETAPE_FIFO500
#endif
--
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://crashcourse.ca
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: correct kernel parameter in documentation.
On Thu, 27 Sep 2007, Dave Jones wrote: 'noacpi' isn't a standalone parameter, give it its prefix. Signed-off-by: Dave Jones [EMAIL PROTECTED] diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 4d175c7..a87bc58 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -863,6 +863,10 @@ and is between 256 and 4096 characters. It is defined in the file lasi= [HW,SCSI] PARISC LASI driver for the 53c700 chip Format: addr:io,irq:irq + libata.noacpi [LIBATA] Disables use of ACPI in libata suspend/resume + when set. + Format: int + if you're going to add that libata-related parm to the kernel parms file, wouldn't it make sense for consistency to add the other available boot-time parms from libata-core.c as well? it seems counter-productive to document only a subset of them from the same source file. rday p.s. as i think i've mentioned before, i'd prefer to see that entire kernel-parameters.txt file reorganized, where the basic boot time parms are at the top, followed by module specific parameters *after* that, in alphabetical order by module name. i think that would make far more sense. -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://crashcourse.ca - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
