linux-2.5.5-pre1

In reply to Daniel Phillips

Quoted 6 lines · Linus Torvalds

This is a _huge_ patch, mainly because it includes three big pending
things: the ALSA merge (which is much smaller in the BK tree than in the patch, because a lot of them are due to renames), merging most of x86_64, and merging some PPC patches.
Full changelog appended.

Wow, that is one fine changelog, thanks

Signature · 1 line

Daniel

-= M.J. Prinsen =-

2002-02-14 01:36 UTC #3 lore raw

When compiling v2.5.5-pre1 I get the following error.
I want to compile this kernel and boot my computer from a raid-0 array (Highpoint HPT370)
Idea's?

---------

gcc -D__KERNEL__ -I/usr/src/linux-2.5.4/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common -pipe -mpreferred-stack-boundary=2 -march=athlon -DKBUILD_BASENAME=ataraid -DEXPORT_SYMTAB -c ataraid.c ataraid.c: In function `ataraid_ioctl':
ataraid.c:73: invalid operands to binary &
ataraid.c:72: warning: minor' might be used uninitialized in this function ataraid.c: In function ataraid_open':
ataraid.c:83: invalid operands to binary &
ataraid.c:82: warning: minor' might be used uninitialized in this function ataraid.c: In function ataraid_release':
ataraid.c:94: invalid operands to binary &
ataraid.c:93: warning: minor' might be used uninitialized in this function ataraid.c: In function ataraid_make_request':
ataraid.c:105: structure has no member named b_rdev' ataraid.c:103: warning: minor' might be used uninitialized in this function ataraid.c: In function `ataraid_split_request':
ataraid.c:182: structure has no member named b_rsector' ataraid.c:193: warning: passing arg 1 of generic_make_request' makes pointer from integer without a cast
ataraid.c:193: too many arguments to function generic_make_request' ataraid.c:194: warning: passing arg 1 of generic_make_request' makes pointer from integer without a cast
ataraid.c:194: too many arguments to function generic_make_request' ataraid.c: In function ataraid_register_disk':
ataraid.c:233: incompatible type for argument 2 of register_disk' ataraid.c: In function ataraid_init':
ataraid.c:249: `hardsect_size' undeclared (first use in this function) ataraid.c:249: (Each undeclared identifier is reported only once ataraid.c:249: for each function it appears in.)
ataraid.c:280: warning: passing arg 2 of `blk_queue_make_request' from incompatible pointer type
ataraid.c: In function `ataraid_exit':
ataraid.c:289: `hardsect_size' undeclared (first use in this function) make[3]: *** [ataraid.o] Error 1
make[3]: Leaving directory `/usr/src/linux-2.5.4/drivers/ide' make[2]: *** [first_rule] Error 2
make[2]: Leaving directory `/usr/src/linux-2.5.4/drivers/ide' make[1]: *** [_subdir_ide] Error 2
make[1]: Leaving directory `/usr/src/linux-2.5.4/drivers'
make: *** [_dir_drivers] Error 2

-------

M.J. Prinsen
http://bovendelft.xs4all.nl

Linus Torvalds

author

2002-02-14 05:32 UTC #4 lore raw

Quoted 4 lines · Daniel Phillips

Quoted 2 lines
Full changelog appended.
Wow, that is one fine changelog, thanks

You're welcome. I've got the changelog generation automated too, so these days the quality of the changelog is directly dependent on the quality of the explanations that accompany the email patches or the changelogs in the BK trees that I merge.

Linus

Allan Sandfeld

2002-02-14 09:26 UTC #5 lore raw

In reply to Daniel Phillips

Quoted 5 lines · -= M.J. Prinsen =-

When compiling v2.5.5-pre1 I get the following error.
I want to compile this kernel and boot my computer from a raid-0 array (Highpoint HPT370)
Idea's?

This has been broken for a long time 2.5, the RAID both software and hardware havent been ported to the new block io layer. You are welcome to try, personally havent got a clue what needs to be changed.

greetings
-Allan

Jeff Garzik

2002-02-14 02:30 UTC #6 lore raw

Quoted 10 lines · Matthias Andree

Quoted 2 lines · Linus Torvalds
This is a _huge_ patch, mainly because it includes three big pending
things: the ALSA merge [...]
Regression test: Does that ALSA stuff that's just been merged support 16bit I/O on Creative Labs Sound Blaster Vibra 16X (DSP 4.xx, those with the two 8-bit-DMA channels rather than the usual 1 8-bit and 1 16-bit DMA channel as found on other ISA sound blaster cards)?

Doesn't matter 1) The OSS drivers are still all there

Doesn't matter 2) We finally have a sound maintainer who can respond to this... with code! :)

Signature · 3 lines

Jeff Garzik      | "I went through my candy like hot oatmeal
Building 1024    |  through an internally-buttered weasel."
MandrakeSoft     |             - goats.com

bert hubert

2002-02-14 08:04 UTC #7 lore raw

Quoted 7 lines · Linus Torvalds

This is a _huge_ patch, mainly because it includes three big pending
things: the ALSA merge (which is much smaller in the BK tree than in the patch, because a lot of them are due to renames), merging most of x86_64, and merging some PPC patches.
Full changelog appended.

Linus,

Did you always merge this many patches, or does it just look like more using this very nice changelog format? Anyhow, I'm impressed about the amount of work accepted in such a short time.

Regards,

bert

Signature · 4 lines

http://www.PowerDNS.com          Versatile DNS Software & Services
http://www.tk                              the dot in .tk
Netherlabs BV / Rent-a-Nerd.nl           - Nerd Available -
Linux Advanced Routing & Traffic Control: http://ds9a.nl/lartc

Linus Torvalds

author

2002-02-14 16:24 UTC #8 lore raw

Quoted 4 lines · bert hubert

Did you always merge this many patches, or does it just look like more using this very nice changelog format? Anyhow, I'm impressed about the amount of work accepted in such a short time.

It looks like more because of the changelog format.

The old changelogs were one-liners, and didn't mention small patches at all (ie the entries like "Remove warning in /proc inode conversions" would not even have made it into the changelog before).

Also, I used to combine entries from the same person, so the eight patches for reiserfs would have been one entry ("reiserfs update"), and the 20 entries from Jeff would likewise have been just one entry ("update network drivers").

That said, this week I've basically spent _only_ on making sure I work well with BitKeeper (so far so good), so I have spent more time than I normally do on merging. So yes, it's actually more merging too. That will calm down eventually.

(The happy news is that I expected to be slowed down by BK for a while, and that hasn't really happened. Some things take more effort now, but to offset that some other stuff is _much_ easier, so..)

Linus

Thomas Capricelli

2002-02-14 16:54 UTC #9 lore raw

Quoted 3 lines

That said, this week I've basically spent _only_ on making sure I work well with BitKeeper (so far so good), so I have spent more time than I

and :

Quoted 3 lines

(The happy news is that I expected to be slowed down by BK for a while, and that hasn't really happened. Some things take more effort now, but to offset that some other stuff is _much_ easier, so..)

I'm really happy your testing seems to go well. Will you make an explicit
statement when you actually decide to use bk or not ? To make clear that your 'testing period' is over.

Thomas

Martin Dalecki

2002-02-14 14:09 UTC #10 lore raw

[PATCH} 2.5.5-pre1 VESA fb

This adjusts the VESA fb driver to the new bus mapping API.
I think that this time this is providing the right replacement.... but who knows what DM had in mind once again...
At least this is working on my notebook without any glitch

drivers/video/vesafb.c +1 -1

diff -ur linux-2.5.4/drivers/video/vesafb.c linux/drivers/video/vesafb.c
@@ -550,7 +550,7 @@
 		ypan = pmi_setpal = 0; /* not available or some DOS TSR ... */
 
 	if (ypan || pmi_setpal) {
-		pmi_base  = (unsigned short*)bus_to_virt(((unsigned long)screen_info.vesapm_seg << 4) + screen_info.vesapm_off);
+		pmi_base  = (unsigned short*)isa_bus_to_virt(((unsigned long)screen_info.vesapm_seg << 4) + screen_info.vesapm_off);
 		pmi_start = (void*)((char*)pmi_base + pmi_base[1]);
 		pmi_pal   = (void*)((char*)pmi_base + pmi_base[2]);
 		printk(KERN_INFO "vesafb: pmi: set display start = %p, set palette = %p\n",pmi_start,pmi_pal);

Alan Cox

2002-02-14 15:02 UTC #11 lore raw

Re: [PATCH} 2.5.5-pre1 VESA fb

Quoted 3 lines

This adjusts the VESA fb driver to the new bus mapping API. I think that this time this is providing the right replacement.... but who knows

The VESA fb window will be higher than the ISA window as its a linear frame buffer

drivers/video/vesafb.c line 553

Quoted 2 lines

drivers/video/vesafb.c +1 -1

-		pmi_base  = (unsigned short*)bus_to_virt(((unsigned long)screen_info.vesapm_seg << 4) + screen_info.vesapm_off);
+		pmi_base  = (unsigned short*)isa_bus_to_virt(((unsigned long)screen_info.vesapm_seg << 4) + screen_info.vesapm_off);

I don't think it actually matters on x86 but phys_to_virt() is probably more correct

Martin Dalecki

2002-02-14 15:33 UTC #12 lore raw

Re: [PATCH} 2.5.5-pre1 VESA fb

Quoted 7 lines · Alan Cox

Quoted 3 lines
This adjusts the VESA fb driver to the new bus mapping API.
I think that this time this is providing the right replacement.... but who knows
The VESA fb window will be higher than the ISA window as its a linear frame buffer

Quoted 7 lines

drivers/video/vesafb.c line 553
Quoted 3 lines
drivers/video/vesafb.c +1 -1
-		pmi_base  = (unsigned short*)bus_to_virt(((unsigned long)screen_info.vesapm_seg << 4) + screen_info.vesapm_off);
+		pmi_base  = (unsigned short*)isa_bus_to_virt(((unsigned long)screen_info.vesapm_seg << 4) + screen_info.vesapm_off);
I don't think it actually matters on x86 but phys_to_virt() is probably more correct

Well I think this is only the BIOS register gateway which we deal with here and I was therefore assuming (without reading the doc's about the *isa*pci*bus*phys*virt* ) that this can be expected to reside in the low memmory area < 1M of the physical address space. And then there are no pci references in the vesa driver at all. Perhaps becouse they ignore the actual frame-buffer mapping games for non intel archs entierly. Anyway I think that the isa_variant is correct. But please feel free to consider me a bit arrogant for not reading the doc's about the address mapping functions. If I'm mistaken here, you could alternatively consider it as a test for the fact that the API isn't "obvious" in first place, becouse it's not easy to figure out what to do without sudying the docu for something such trivial like IO address range mapping ;-).

Regards

Gerold J. Wucherpfennig

2002-02-14 20:48 UTC #13 lore raw

Compile error with linux-2.5.5-pre1 & advansys scsi

The advansys scsi driver of linux-2.5.5-pre1 doesn't compile ...

Here is the error message:

make[3]: Entering directory `/usr/src/linux/drivers/scsi'
gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common
-pipe -mpreferred-stack-boundary=2 -march=i686 -DKBUILD_BASENAME=advansys
-c -o advansys.o advansys.c
advansys.c:755:2: #error Please convert me to Documentation/DMA-mapping.txt advansys.c: In function `asc_build_req':
advansys.c:6754: structure has no member named address' advansys.c:6754: structure has no member named address' advansys.c: In function `adv_get_sglist':
advansys.c:7014: structure has no member named address' advansys.c:7014: structure has no member named address' advansys.c: In function `asc_isr_callback':
advansys.c:7056: warning: passing arg 1 of `bus_to_virt_not_defined_use_pci_map' makes pointer from integer without a cast
advansys.c: In function `adv_isr_callback':
advansys.c:7231: warning: passing arg 1 of `bus_to_virt_not_defined_use_pci_map' makes pointer from integer without a cast
advansys.c: In function `AdvInitAsc3550Driver':
advansys.c:15507: warning: passing arg 1 of `bus_to_virt_not_defined_use_pci_map' makes pointer from integer without a cast
advansys.c:15528: warning: passing arg 1 of `bus_to_virt_not_defined_use_pci_map' makes pointer from integer without a cast
advansys.c: In function `AdvInitAsc38C0800Driver':
advansys.c:16129: warning: passing arg 1 of `bus_to_virt_not_defined_use_pci_map' makes pointer from integer without a cast
advansys.c:16151: warning: passing arg 1 of `bus_to_virt_not_defined_use_pci_map' makes pointer from integer without a cast
advansys.c: In function `AdvInitAsc38C1600Driver':
advansys.c:16765: warning: passing arg 1 of `bus_to_virt_not_defined_use_pci_map' makes pointer from integer without a cast
advansys.c:16790: warning: passing arg 1 of `bus_to_virt_not_defined_use_pci_map' makes pointer from integer without a cast
advansys.c: In function `AdvExeScsiQueue':
advansys.c:17982: warning: passing arg 1 of `bus_to_virt_not_defined_use_pci_map' makes pointer from integer without a cast
advansys.c: In function `AdvISR':
advansys.c:18308: warning: passing arg 1 of `bus_to_virt_not_defined_use_pci_map' makes pointer from integer without a cast
advansys.c:18329: warning: passing arg 1 of `bus_to_virt_not_defined_use_pci_map' makes pointer from integer without a cast
make[3]: *** [advansys.o] Error 1
make[3]: Leaving directory `/usr/src/linux/drivers/scsi' make[2]: *** [first_rule] Error 2
make[2]: Leaving directory `/usr/src/linux/drivers/scsi' make[1]: *** [_subdir_scsi] Error 2
make[1]: Leaving directory `/usr/src/linux/drivers'
make: *** [_dir_drivers] Error 2

Martin Dalecki

2002-02-19 11:38 UTC #14 lore raw

PATCH 1/1 2.5.5-pre1 IDE cleanup

The attached patch does:

1. Kill two exports which mankind will never know what they where good for

2. Kill duplicated comments.

3. Kill declarations of never defined functions

4. Some other minor tidups here and there.

It is created on top of the other patches I already send to you however it should apply independantly.

drivers/ide/ide-probe.c +6 ~~-23~~

diff -ur linux-2.5.4/drivers/ide/ide-probe.c linux/drivers/ide/ide-probe.c
@@ -406,22 +406,19 @@
 }
 
 /*
- * probe_for_drive() tests for existence of a given drive using do_probe().
- *
- * Returns:	0  no device was found
- *		1  device was found (note: drive->present might still be 0)
+ * Tests for existence of a given drive using do_probe().
  */
-static inline byte probe_for_drive (ide_drive_t *drive)
+static inline void probe_for_drive (ide_drive_t *drive)
 {
 	if (drive->noprobe)			/* skip probing? */
-		return drive->present;
+		return;
 	if (do_probe(drive, WIN_IDENTIFY) >= 2) { /* if !(success||timed-out) */
-		(void) do_probe(drive, WIN_PIDENTIFY); /* look for ATAPI device */
+		do_probe(drive, WIN_PIDENTIFY); /* look for ATAPI device */
 	}
 	if (drive->id && strstr(drive->id->model, "E X A B Y T E N E S T"))
 		enable_nest(drive);
 	if (!drive->present)
-		return 0;			/* drive not found */
+		return;			/* drive not found */
 	if (drive->id == NULL) {		/* identification failed? */
 		if (drive->media == ide_disk) {
 			printk ("%s: non-IDE drive, CHS=%d/%d/%d\n",

@@ -432,7 +429,6 @@
 			drive->present = 0;	/* nuke it */
 		}
 	}
-	return 1;	/* drive was found */
 }
 
 /*

@@ -548,7 +544,7 @@
 	 */
 	for (unit = 0; unit < MAX_DRIVES; ++unit) {
 		ide_drive_t *drive = &hwif->drives[unit];
-		(void) probe_for_drive (drive);
+		probe_for_drive (drive);
 		if (drive->present && !hwif->present) {
 			hwif->present = 1;
 			if (hwif->chipset != ide_4drives || !hwif->mate->present) {

@@ -931,19 +927,6 @@
 	return hwif->present;
 }
 
-void export_ide_init_queue (ide_drive_t *drive)
-{
-	ide_init_queue(drive);
-}
-
-byte export_probe_for_drive (ide_drive_t *drive)
-{
-	return probe_for_drive(drive);
-}
-
-EXPORT_SYMBOL(export_ide_init_queue);
-EXPORT_SYMBOL(export_probe_for_drive);
-
 int ideprobe_init (void);
 static ide_module_t ideprobe_module = {
 	IDE_PROBE_MODULE,

drivers/ide/ide.c +3 ~~-10~~

diff -ur linux-2.5.4/drivers/ide/ide.c linux/drivers/ide/ide.c
@@ -1965,11 +1965,10 @@
 #endif
 
 /*
- * Note that we only release the standard ports,
- * and do not even try to handle any extra ports
- * allocated for weird IDE interface chipsets.
+ * Note that we only release the standard ports, and do not even try to handle
+ * any extra ports allocated for weird IDE interface chipsets.
  */
-void hwif_unregister (ide_hwif_t *hwif)
+static void hwif_unregister(ide_hwif_t *hwif)
 {
 	if (hwif->straight8) {
 		ide_release_region(hwif->io_ports[IDE_DATA_OFFSET], 8);

@@ -2063,11 +2062,6 @@
 	if (irq_count == 1)
 		free_irq(hwif->irq, hwgroup);
 
-	/*
-	 * Note that we only release the standard ports,
-	 * and do not even try to handle any extra ports
-	 * allocated for weird IDE interface chipsets.
-	 */
 	hwif_unregister(hwif);
 
 	/*

@@ -3718,7 +3712,6 @@
 EXPORT_SYMBOL(ide_register);
 EXPORT_SYMBOL(ide_unregister);
 EXPORT_SYMBOL(ide_setup_ports);
-EXPORT_SYMBOL(hwif_unregister);
 EXPORT_SYMBOL(get_info_ptr);
 EXPORT_SYMBOL(current_capacity);

include/linux/ide.h +2 -7

diff -ur linux-2.5.4/include/linux/ide.h linux/include/linux/ide.h
@@ -1101,7 +1101,6 @@
 #  define OFF_BOARD		NEVER_BOARD
 #endif /* CONFIG_BLK_DEV_OFFBOARD */
 
-unsigned long ide_find_free_region (unsigned short size) __init;
 void ide_scan_pcibus (int scan_direction) __init;
 #endif
 #ifdef CONFIG_BLK_DEV_IDEDMA

@@ -1115,14 +1114,10 @@
 int ide_dmaproc (ide_dma_action_t func, ide_drive_t *drive);
 int ide_release_dma (ide_hwif_t *hwif);
 void ide_setup_dma (ide_hwif_t *hwif, unsigned long dmabase, unsigned int num_ports) __init;
-unsigned long ide_get_or_set_dma_base (ide_hwif_t *hwif, int extra, const char *name) __init;
+/* FIXME spilt this up into a get and set function */
+extern unsigned long ide_get_or_set_dma_base (ide_hwif_t *hwif, int extra, const char *name) __init;
 #endif
 
-void hwif_unregister (ide_hwif_t *hwif);
-
-void export_ide_init_queue (ide_drive_t *drive);
-byte export_probe_for_drive (ide_drive_t *drive);
-
 extern spinlock_t ide_lock;
 
 extern int drive_is_ready(ide_drive_t *drive);

Martin Dalecki

2002-02-19 11:47 UTC #15 lore raw

PATCH 1/1 2.5.5-pre1 IDE cleanup 9

The attached patch does the following:

1. Kill the ide-probe-mod by merging it with ide-mod. There is *really* no reaons for having this stuff split up into two different modules unless you wan't to create artificial module dependancies
and waste space
of page boundaries during memmory allocation for the modules

2. Kill the ide_module_t - which is unnecessary and presents a "reimplementation" of module handling inside the ide driver. This is achieved by
attaching the
initialization routine ot the ide_driver_t, which will be gone next
time,
since there is no sane reason apparently, which this couldn't be done during the module-generic initialization of the corresponding driver
module.

3. Kill unnecessary tagging of "subdriver" with IDE_SUBDRIVER_VERSION - we have plenty of other mechanisms for module consistency checking. And
anyway
the ide code didn't any consistence checks on this value at all.

NOTE: The ide_(un)register_module() functions will be killed in next round.

This patch should apply to mainstream, however it waws created on top of the others.

drivers/ide/Makefile +3 -7

diff -ur linux-2.5.4/drivers/ide/Makefile linux/drivers/ide/Makefile
@@ -11,14 +11,14 @@
 O_TARGET := idedriver.o
 
 export-objs		:= ide-taskfile.o ide.o ide-features.o ide-probe.o ataraid.o
-list-multi		:= ide-mod.o ide-probe-mod.o
+list-multi		:= ide-mod.o
 
 obj-y		:=
 obj-m		:=
 ide-obj-y	:=
 
 obj-$(CONFIG_BLK_DEV_HD)	+= hd.o
-obj-$(CONFIG_BLK_DEV_IDE)       += ide-mod.o ide-probe-mod.o
+obj-$(CONFIG_BLK_DEV_IDE)       += ide-mod.o
 obj-$(CONFIG_BLK_DEV_IDECS)     += ide-cs.o
 obj-$(CONFIG_BLK_DEV_IDEDISK)   += ide-disk.o
 obj-$(CONFIG_BLK_DEV_IDECD)     += ide-cd.o

@@ -76,13 +76,9 @@
 
 ide-obj-$(CONFIG_PROC_FS)		+= ide-proc.o
 
-ide-mod-objs		:= ide-taskfile.o ide.o ide-features.o $(ide-obj-y)
-ide-probe-mod-objs	:= ide-probe.o ide-geometry.o
+ide-mod-objs		:= ide-taskfile.o ide.o ide-probe.o ide-geometry.o ide-features.o $(ide-obj-y)
 
 include $(TOPDIR)/Rules.make
 
 ide-mod.o: $(ide-mod-objs)
 	$(LD) -r -o $@ $(ide-mod-objs)
-
-ide-probe-mod.o: $(ide-probe-mod-objs)
-	$(LD) -r -o $@ $(ide-probe-mod-objs)

drivers/ide/ide-cd.c +7 ~~-13~~

diff -ur linux-2.5.4/drivers/ide/ide-cd.c linux/drivers/ide/ide-cd.c
@@ -2906,6 +2906,7 @@
 	return 0;
 }
 
+int ide_cdrom_init(void);
 int ide_cdrom_reinit (ide_drive_t *drive);
 
 static ide_driver_t ide_cdrom_driver = {

@@ -2928,17 +2929,10 @@
 	capacity:		ide_cdrom_capacity,
 	special:		NULL,
 	proc:			NULL,
+	driver_init:		ide_cdrom_init,
 	driver_reinit:		ide_cdrom_reinit,
 };
 
-int ide_cdrom_init(void);
-static ide_module_t ide_cdrom_module = {
-	IDE_DRIVER_MODULE,
-	ide_cdrom_init,
-	&ide_cdrom_driver,
-	NULL
-};
-
 /* options */
 char *ignore = NULL;

@@ -2956,7 +2950,7 @@
 		printk ("%s: Can't allocate a cdrom structure\n", drive->name);
 		return 1;
 	}
-	if (ide_register_subdriver (drive, &ide_cdrom_driver, IDE_SUBDRIVER_VERSION)) {
+	if (ide_register_subdriver (drive, &ide_cdrom_driver)) {
 		printk ("%s: Failed to register the driver with ide.c\n", drive->name);
 		kfree (info);
 		return 1;

@@ -2973,7 +2967,7 @@
 	DRIVER(drive)->busy--;
 	failed--;
 
-	ide_register_module(&ide_cdrom_module);
+	ide_register_module(&ide_cdrom_driver);
 	MOD_DEC_USE_COUNT;
 	return 0;
 }

@@ -2988,7 +2982,7 @@
 			printk ("%s: cleanup_module() called while still busy\n", drive->name);
 			failed++;
 		}
-	ide_unregister_module (&ide_cdrom_module);
+	ide_unregister_module (&ide_cdrom_driver);
 }
  
 int ide_cdrom_init(void)

@@ -3015,7 +3009,7 @@
 			printk ("%s: Can't allocate a cdrom structure\n", drive->name);
 			continue;
 		}
-		if (ide_register_subdriver (drive, &ide_cdrom_driver, IDE_SUBDRIVER_VERSION)) {
+		if (ide_register_subdriver (drive, &ide_cdrom_driver)) {
 			printk ("%s: Failed to register the driver with ide.c\n", drive->name);
 			kfree (info);
 			continue;

@@ -3032,7 +3026,7 @@
 		DRIVER(drive)->busy--;
 		failed--;
 	}
-	ide_register_module(&ide_cdrom_module);
+	ide_register_module(&ide_cdrom_driver);
 	MOD_DEC_USE_COUNT;
 	return 0;
 }

drivers/ide/ide-disk.c +7 ~~-13~~

diff -ur linux-2.5.4/drivers/ide/ide-disk.c linux/drivers/ide/ide-disk.c
@@ -1030,6 +1030,7 @@
 	return ide_unregister_subdriver(drive);
 }
 
+int idedisk_init (void);
 int idedisk_reinit(ide_drive_t *drive);
 
 /*

@@ -1055,17 +1056,10 @@
 	capacity:		idedisk_capacity,
 	special:		idedisk_special,
 	proc:			idedisk_proc,
+	driver_init:		idedisk_init,
 	driver_reinit:		idedisk_reinit,
 };
 
-int idedisk_init (void);
-static ide_module_t idedisk_module = {
-	IDE_DRIVER_MODULE,
-	idedisk_init,
-	&idedisk_driver,
-	NULL
-};
-
 MODULE_DESCRIPTION("ATA DISK Driver");
 
 int idedisk_reinit (ide_drive_t *drive)

@@ -1074,7 +1068,7 @@
 
 	MOD_INC_USE_COUNT;
 
-	if (ide_register_subdriver (drive, &idedisk_driver, IDE_SUBDRIVER_VERSION)) {
+	if (ide_register_subdriver (drive, &idedisk_driver)) {
 		printk (KERN_ERR "ide-disk: %s: Failed to register the driver with ide.c\n", drive->name);
 		return 1;
 	}

@@ -1089,7 +1083,7 @@
 	DRIVER(drive)->busy--;
 	failed--;
 
-	ide_register_module(&idedisk_module);
+	ide_register_module(&idedisk_driver);
 	MOD_DEC_USE_COUNT;
 	return 0;
 }

@@ -1111,7 +1105,7 @@
 			ide_remove_proc_entries(drive->proc, idedisk_proc);
 #endif
 	}
-	ide_unregister_module(&idedisk_module);
+	ide_unregister_module(&idedisk_driver);
 }
 
 int idedisk_init (void)

@@ -1121,7 +1115,7 @@
 	
 	MOD_INC_USE_COUNT;
 	while ((drive = ide_scan_devices (ide_disk, idedisk_driver.name, NULL, failed++)) != NULL) {
-		if (ide_register_subdriver (drive, &idedisk_driver, IDE_SUBDRIVER_VERSION)) {
+		if (ide_register_subdriver (drive, &idedisk_driver)) {
 			printk (KERN_ERR "ide-disk: %s: Failed to register the driver with ide.c\n", drive->name);
 			continue;
 		}

@@ -1136,7 +1130,7 @@
 		DRIVER(drive)->busy--;
 		failed--;
 	}
-	ide_register_module(&idedisk_module);
+	ide_register_module(&idedisk_driver);
 	MOD_DEC_USE_COUNT;
 	return 0;
 }

drivers/ide/ide-floppy.c +7 ~~-13~~

diff -ur linux-2.5.4/drivers/ide/ide-floppy.c linux/drivers/ide/ide-floppy.c
@@ -2046,6 +2046,7 @@
 
 #endif	/* CONFIG_PROC_FS */
 
+int idefloppy_init(void);
 int idefloppy_reinit(ide_drive_t *drive);
 
 /*

@@ -2071,17 +2072,10 @@
 	capacity:		idefloppy_capacity,
 	special:		NULL,
 	proc:			idefloppy_proc,
+	driver_init:		idefloppy_init,
 	driver_reinit:		idefloppy_reinit,
 };
 
-int idefloppy_init (void);
-static ide_module_t idefloppy_module = {
-	IDE_DRIVER_MODULE,
-	idefloppy_init,
-	&idefloppy_driver,
-	NULL
-};
-
 int idefloppy_reinit (ide_drive_t *drive)
 {
 	idefloppy_floppy_t *floppy;

@@ -2101,7 +2095,7 @@
 			printk (KERN_ERR "ide-floppy: %s: Can't allocate a floppy structure\n", drive->name);
 			continue;
 		}
-		if (ide_register_subdriver (drive, &idefloppy_driver, IDE_SUBDRIVER_VERSION)) {
+		if (ide_register_subdriver (drive, &idefloppy_driver)) {
 			printk (KERN_ERR "ide-floppy: %s: Failed to register the driver with ide.c\n", drive->name);
 			kfree (floppy);
 			continue;

@@ -2111,7 +2105,7 @@
 		DRIVER(drive)->busy--;
 		failed--;
 	}
-	ide_register_module(&idefloppy_module);
+	ide_register_module(&idefloppy_driver);
 	MOD_DEC_USE_COUNT;
 	return 0;
 }

@@ -2136,7 +2130,7 @@
 			ide_remove_proc_entries(drive->proc, idefloppy_proc);
 #endif
 	}
-	ide_unregister_module(&idefloppy_module);
+	ide_unregister_module(&idefloppy_driver);
 }
 
 /*

@@ -2163,7 +2157,7 @@
 			printk (KERN_ERR "ide-floppy: %s: Can't allocate a floppy structure\n", drive->name);
 			continue;
 		}
-		if (ide_register_subdriver (drive, &idefloppy_driver, IDE_SUBDRIVER_VERSION)) {
+		if (ide_register_subdriver (drive, &idefloppy_driver)) {
 			printk (KERN_ERR "ide-floppy: %s: Failed to register the driver with ide.c\n", drive->name);
 			kfree (floppy);
 			continue;

@@ -2173,7 +2167,7 @@
 		DRIVER(drive)->busy--;
 		failed--;
 	}
-	ide_register_module(&idefloppy_module);
+	ide_register_module(&idefloppy_driver);
 	MOD_DEC_USE_COUNT;
 	return 0;
 }

drivers/ide/ide-probe.c +0 ~~-34~~

diff -ur linux-2.5.4/drivers/ide/ide-probe.c linux/drivers/ide/ide-probe.c
@@ -927,19 +927,11 @@
 	return hwif->present;
 }
 
-int ideprobe_init (void);
-static ide_module_t ideprobe_module = {
-	IDE_PROBE_MODULE,
-	ideprobe_init,
-	NULL
-};
-
 int ideprobe_init (void)
 {
 	unsigned int index;
 	int probe[MAX_HWIFS];
 	
-	MOD_INC_USE_COUNT;
 	memset(probe, 0, MAX_HWIFS * sizeof(int));
 	for (index = 0; index < MAX_HWIFS; ++index)
 		probe[index] = !ide_hwifs[index].present;

@@ -953,31 +945,5 @@
 	for (index = 0; index < MAX_HWIFS; ++index)
 		if (probe[index])
 			hwif_init(&ide_hwifs[index]);
-	if (!ide_probe)
-		ide_probe = &ideprobe_module;
-	MOD_DEC_USE_COUNT;
-	return 0;
-}
-
-#ifdef MODULE
-extern int (*ide_xlate_1024_hook)(kdev_t, int, int, const char *);
-
-int init_module (void)
-{
-	unsigned int index;
-	
-	for (index = 0; index < MAX_HWIFS; ++index)
-		ide_unregister(index);
-	ideprobe_init();
-	create_proc_ide_interfaces();
-	ide_xlate_1024_hook = ide_xlate_1024;
 	return 0;
 }
-
-void cleanup_module (void)
-{
-	ide_probe = NULL;
-	ide_xlate_1024_hook = 0;
-}
-MODULE_LICENSE("GPL");
-#endif /* MODULE */

drivers/ide/ide-proc.c +3 -7

diff -ur linux-2.5.4/drivers/ide/ide-proc.c linux/drivers/ide/ide-proc.c
@@ -378,14 +378,10 @@
 {
 	char		*out = page;
 	int		len;
-	ide_module_t	*p = ide_modules;
-	ide_driver_t	*driver;
+	struct ide_driver_s * driver;
 
-	while (p) {
-		driver = (ide_driver_t *) p->info;
-		if (driver)
-			out += sprintf(out, "%s\n",driver->name);
-		p = p->next;
+	for (driver = ide_drivers; driver; driver = driver->next) {
+		out += sprintf(out, "%s\n",driver->name);
 	}
 	len = out - page;
 	PROC_IDE_READ_RETURN(page,start,off,count,eof,len);

drivers/ide/ide-tape.c +7 ~~-13~~

diff -ur linux-2.5.4/drivers/ide/ide-tape.c linux/drivers/ide/ide-tape.c
@@ -6137,6 +6137,7 @@
 
 #endif
 
+int idetape_init (void);
 int idetape_reinit(ide_drive_t *drive);
 
 /*

@@ -6161,17 +6162,10 @@
 	pre_reset:		idetape_pre_reset,
 	capacity:		NULL,
 	proc:			idetape_proc,
+	driver_init:		idetape_init,
 	driver_reinit:		idetape_reinit,
 };
 
-int idetape_init (void);
-static ide_module_t idetape_module = {
-	IDE_DRIVER_MODULE,
-	idetape_init,
-	&idetape_driver,
-	NULL
-};
-
 /*
  *	Our character device supporting functions, passed to register_chrdev.
  */

@@ -6233,7 +6227,7 @@
 			printk (KERN_ERR "ide-tape: %s: Can't allocate a tape structure\n", drive->name);
 			continue;
 		}
-		if (ide_register_subdriver (drive, &idetape_driver, IDE_SUBDRIVER_VERSION)) {
+		if (ide_register_subdriver (drive, &idetape_driver)) {
 			printk (KERN_ERR "ide-tape: %s: Failed to register the driver with ide.c\n", drive->name);
 			kfree (tape);
 			continue;

@@ -6283,7 +6277,7 @@
 		if (drive != NULL && idetape_cleanup (drive))
 		printk (KERN_ERR "ide-tape: %s: cleanup_module() called while still busy\n", drive->name);
 	}
-	ide_unregister_module(&idetape_module);
+	ide_unregister_module(&idetape_driver);
 }
 
 /*

@@ -6304,7 +6298,7 @@
 			idetape_chrdevs[minor].drive = NULL;
 
 	if ((drive = ide_scan_devices (ide_tape, idetape_driver.name, NULL, failed++)) == NULL) {
-		ide_register_module (&idetape_module);
+		ide_register_module (&idetape_driver);
 		MOD_DEC_USE_COUNT;
 #if ONSTREAM_DEBUG
 		printk(KERN_INFO "ide-tape: MOD_DEC_USE_COUNT in idetape_init\n");

@@ -6338,7 +6332,7 @@
 			printk (KERN_ERR "ide-tape: %s: Can't allocate a tape structure\n", drive->name);
 			continue;
 		}
-		if (ide_register_subdriver (drive, &idetape_driver, IDE_SUBDRIVER_VERSION)) {
+		if (ide_register_subdriver (drive, &idetape_driver)) {
 			printk (KERN_ERR "ide-tape: %s: Failed to register the driver with ide.c\n", drive->name);
 			kfree (tape);
 			continue;

@@ -6363,7 +6357,7 @@
 		devfs_unregister_chrdev (IDETAPE_MAJOR, "ht");
 	} else
 		idetape_chrdev_present = 1;
-	ide_register_module (&idetape_module);
+	ide_register_module (&idetape_driver);
 	MOD_DEC_USE_COUNT;
 #if ONSTREAM_DEBUG
 	printk(KERN_INFO "ide-tape: MOD_DEC_USE_COUNT in idetape_init\n");

drivers/ide/ide.c +17 ~~-26~~

103 lines not on this page · raw message

drivers/scsi/ide-scsi.c +6 ~~-12~~

diff -ur linux-2.5.4/drivers/scsi/ide-scsi.c linux/drivers/scsi/ide-scsi.c
@@ -535,6 +535,7 @@
 	return 0;
 }
 
+int idescsi_init(void);
 int idescsi_reinit(ide_drive_t *drive);
 
 /*

@@ -560,17 +561,10 @@
 	capacity:		NULL,
 	special:		NULL,
 	proc:			NULL,
+	driver_init:		idescsi_init,
 	driver_reinit:		idescsi_reinit,
 };
 
-int idescsi_init (void);
-static ide_module_t idescsi_module = {
-	IDE_DRIVER_MODULE,
-	idescsi_init,
-	&idescsi_driver,
-	NULL
-};
-
 int idescsi_reinit (ide_drive_t *drive)
 {
 #if 0

@@ -592,7 +586,7 @@
 				printk (KERN_ERR "ide-scsi: %s: Can't allocate a scsi structure\n", drive->name);
 				continue;
 			}
-			if (ide_register_subdriver (drive, &idescsi_driver, IDE_SUBDRIVER_VERSION)) {
+			if (ide_register_subdriver (drive, &idescsi_driver)) {
 				printk (KERN_ERR "ide-scsi: %s: Failed to register the driver with ide.c\n", drive->name);
 				kfree (scsi);
 				continue;

@@ -632,7 +626,7 @@
 				printk (KERN_ERR "ide-scsi: %s: Can't allocate a scsi structure\n", drive->name);
 				continue;
 			}
-			if (ide_register_subdriver (drive, &idescsi_driver, IDE_SUBDRIVER_VERSION)) {
+			if (ide_register_subdriver (drive, &idescsi_driver)) {
 				printk (KERN_ERR "ide-scsi: %s: Failed to register the driver with ide.c\n", drive->name);
 				kfree (scsi);
 				continue;

@@ -642,7 +636,7 @@
 			failed--;
 		}
 	}
-	ide_register_module(&idescsi_module);
+	ide_register_module(&idescsi_driver);
 	MOD_DEC_USE_COUNT;
 	return 0;
 }

@@ -912,7 +906,7 @@
 				failed++;
 			}
 	}
-	ide_unregister_module(&idescsi_module);
+	ide_unregister_module(&idescsi_driver);
 }
 
 module_init(init_idescsi_module);

include/linux/ide.h +22 ~~-35~~

109 lines not on this page · raw message

Martin Dalecki

2002-02-20 10:50 UTC #16 lore raw

PATCH 1/1 2.5.5-pre1 IDE cleanup 10

Hello!

This is finishing the cleanup parts already started in ide-clean-9.

It kills the ide_register_module() and ide_unregister_module() as well as associated idiosyncracies alltogether. It turns out
that this patch is actually fixing a bug which was present in the driver before: the sub-module initialization functions where called at least twice - which is an abundance.

Tough there is a bit of global namespace pollution caused by this patch - but I'm aware of it and will fix it just a bit later. (The terminology used inside the IDE code is anyway nothing common else in the linux universum...)

The next targets will be:

1. Code obfuscation by "wrappers" around generic BIO level functions.

2. ide_hwgroup_t - which is only used to serialize multiple discs on the same interrupt and similar. This is however a tough one.

3. There is a plenty of code waste in the chipset drivers, where there
is baroque informative code for the proc file system for static stuff, which in fact belongs just to syslog(). In fact the default RedHat distribution kernel is killing this gratitious abuse of the /proc concept since a long long time...

I'm still awaiting the day of /proc/GPL, where GPL contains the full text of it...

drivers/ide/ide-cd.c +2 -5

diff -ur linux-2.5.4/drivers/ide/ide-cd.c linux/drivers/ide/ide-cd.c
@@ -2906,7 +2906,6 @@
 	return 0;
 }
 
-int ide_cdrom_init(void);
 int ide_cdrom_reinit (ide_drive_t *drive);
 
 static ide_driver_t ide_cdrom_driver = {

@@ -2929,7 +2928,6 @@
 	capacity:		ide_cdrom_capacity,
 	special:		NULL,
 	proc:			NULL,
-	driver_init:		ide_cdrom_init,
 	driver_reinit:		ide_cdrom_reinit,
 };

@@ -2967,7 +2965,7 @@
 	DRIVER(drive)->busy--;
 	failed--;
 
-	ide_register_module(&ide_cdrom_driver);
+	revalidate_drives();
 	MOD_DEC_USE_COUNT;
 	return 0;
 }

@@ -2982,7 +2980,6 @@
 			printk ("%s: cleanup_module() called while still busy\n", drive->name);
 			failed++;
 		}
-	ide_unregister_module (&ide_cdrom_driver);
 }
  
 int ide_cdrom_init(void)

@@ -3026,7 +3023,7 @@
 		DRIVER(drive)->busy--;
 		failed--;
 	}
-	ide_register_module(&ide_cdrom_driver);
+	revalidate_drives();
 	MOD_DEC_USE_COUNT;
 	return 0;
 }

drivers/ide/ide-disk.c +2 -5

diff -ur linux-2.5.4/drivers/ide/ide-disk.c linux/drivers/ide/ide-disk.c
@@ -1030,7 +1030,6 @@
 	return ide_unregister_subdriver(drive);
 }
 
-int idedisk_init (void);
 int idedisk_reinit(ide_drive_t *drive);
 
 /*

@@ -1056,7 +1055,6 @@
 	capacity:		idedisk_capacity,
 	special:		idedisk_special,
 	proc:			idedisk_proc,
-	driver_init:		idedisk_init,
 	driver_reinit:		idedisk_reinit,
 };

@@ -1083,7 +1081,7 @@
 	DRIVER(drive)->busy--;
 	failed--;
 
-	ide_register_module(&idedisk_driver);
+	revalidate_drives();
 	MOD_DEC_USE_COUNT;
 	return 0;
 }

@@ -1105,7 +1103,6 @@
 			ide_remove_proc_entries(drive->proc, idedisk_proc);
 #endif
 	}
-	ide_unregister_module(&idedisk_driver);
 }
 
 int idedisk_init (void)

@@ -1130,7 +1127,7 @@
 		DRIVER(drive)->busy--;
 		failed--;
 	}
-	ide_register_module(&idedisk_driver);
+	revalidate_drives();
 	MOD_DEC_USE_COUNT;
 	return 0;
 }

drivers/ide/ide-floppy.c +2 -5

diff -ur linux-2.5.4/drivers/ide/ide-floppy.c linux/drivers/ide/ide-floppy.c
@@ -2046,7 +2046,6 @@
 
 #endif	/* CONFIG_PROC_FS */
 
-int idefloppy_init(void);
 int idefloppy_reinit(ide_drive_t *drive);
 
 /*

@@ -2072,7 +2071,6 @@
 	capacity:		idefloppy_capacity,
 	special:		NULL,
 	proc:			idefloppy_proc,
-	driver_init:		idefloppy_init,
 	driver_reinit:		idefloppy_reinit,
 };

@@ -2105,7 +2103,7 @@
 		DRIVER(drive)->busy--;
 		failed--;
 	}
-	ide_register_module(&idefloppy_driver);
+	revalidate_drives();
 	MOD_DEC_USE_COUNT;
 	return 0;
 }

@@ -2130,7 +2128,6 @@
 			ide_remove_proc_entries(drive->proc, idefloppy_proc);
 #endif
 	}
-	ide_unregister_module(&idefloppy_driver);
 }
 
 /*

@@ -2167,7 +2164,7 @@
 		DRIVER(drive)->busy--;
 		failed--;
 	}
-	ide_register_module(&idefloppy_driver);
+	revalidate_drives();
 	MOD_DEC_USE_COUNT;
 	return 0;
 }

drivers/ide/ide-proc.c +0 ~~-17~~

diff -ur linux-2.5.4/drivers/ide/ide-proc.c linux/drivers/ide/ide-proc.c
@@ -373,20 +373,6 @@
 	return digit;
 }
 
-static int proc_ide_read_drivers
-	(char *page, char **start, off_t off, int count, int *eof, void *data)
-{
-	char		*out = page;
-	int		len;
-	struct ide_driver_s * driver;
-
-	for (driver = ide_drivers; driver; driver = driver->next) {
-		out += sprintf(out, "%s\n",driver->name);
-	}
-	len = out - page;
-	PROC_IDE_READ_RETURN(page,start,off,count,eof,len);
-}
-
 static int proc_ide_read_imodel
 	(char *page, char **start, off_t off, int count, int *eof, void *data)
 {

@@ -852,9 +838,6 @@
 
 	create_proc_ide_interfaces();
 
-	create_proc_read_entry("drivers", 0, proc_ide_root,
-				proc_ide_read_drivers, NULL);
-
 #ifdef CONFIG_BLK_DEV_AEC62XX
 	if ((aec62xx_display_info) && (aec62xx_proc))
 		create_proc_info_entry("aec62xx", 0, proc_ide_root, aec62xx_display_info);

drivers/ide/ide-tape.c +4 -7

diff -ur linux-2.5.4/drivers/ide/ide-tape.c linux/drivers/ide/ide-tape.c
@@ -6137,7 +6137,6 @@
 
 #endif
 
-int idetape_init (void);
 int idetape_reinit(ide_drive_t *drive);
 
 /*

@@ -6162,7 +6161,6 @@
 	pre_reset:		idetape_pre_reset,
 	capacity:		NULL,
 	proc:			idetape_proc,
-	driver_init:		idetape_init,
 	driver_reinit:		idetape_reinit,
 };

@@ -6193,7 +6191,7 @@
 			idetape_chrdevs[minor].drive = NULL;
 
 	if ((drive = ide_scan_devices (ide_tape, idetape_driver.name, NULL, failed++)) == NULL) {
-		ide_register_module (&idetape_module);
+		revalidate_drives();
 		MOD_DEC_USE_COUNT;
 #if ONSTREAM_DEBUG
 		printk(KERN_INFO "ide-tape: MOD_DEC_USE_COUNT in idetape_init\n");

@@ -6252,7 +6250,7 @@
 		devfs_unregister_chrdev (IDETAPE_MAJOR, "ht");
 	} else
 		idetape_chrdev_present = 1;
-	ide_register_module (&idetape_module);
+	revalidate_drives();
 	MOD_DEC_USE_COUNT;
 #if ONSTREAM_DEBUG
 	printk(KERN_INFO "ide-tape: MOD_DEC_USE_COUNT in idetape_init\n");

@@ -6277,7 +6275,6 @@
 		if (drive != NULL && idetape_cleanup (drive))
 		printk (KERN_ERR "ide-tape: %s: cleanup_module() called while still busy\n", drive->name);
 	}
-	ide_unregister_module(&idetape_driver);
 }
 
 /*

@@ -6298,7 +6295,7 @@
 			idetape_chrdevs[minor].drive = NULL;
 
 	if ((drive = ide_scan_devices (ide_tape, idetape_driver.name, NULL, failed++)) == NULL) {
-		ide_register_module (&idetape_driver);
+		revalidate_drives();
 		MOD_DEC_USE_COUNT;
 #if ONSTREAM_DEBUG
 		printk(KERN_INFO "ide-tape: MOD_DEC_USE_COUNT in idetape_init\n");

@@ -6357,7 +6354,7 @@
 		devfs_unregister_chrdev (IDETAPE_MAJOR, "ht");
 	} else
 		idetape_chrdev_present = 1;
-	ide_register_module (&idetape_driver);
+	revalidate_drives();
 	MOD_DEC_USE_COUNT;
 #if ONSTREAM_DEBUG
 	printk(KERN_INFO "ide-tape: MOD_DEC_USE_COUNT in idetape_init\n");

drivers/ide/ide.c +6 ~~-35~~

78 lines not on this page · raw message

drivers/scsi/ide-scsi.c +2 -5

diff -ur linux-2.5.4/drivers/scsi/ide-scsi.c linux/drivers/scsi/ide-scsi.c
@@ -535,7 +535,6 @@
 	return 0;
 }
 
-int idescsi_init(void);
 int idescsi_reinit(ide_drive_t *drive);
 
 /*

@@ -561,7 +560,6 @@
 	capacity:		NULL,
 	special:		NULL,
 	proc:			NULL,
-	driver_init:		idescsi_init,
 	driver_reinit:		idescsi_reinit,
 };

@@ -596,7 +594,7 @@
 			failed--;
 		}
 	}
-	ide_register_module(&idescsi_module);
+	revalidate_drives();
 	MOD_DEC_USE_COUNT;
 #endif
 	return 0;

@@ -636,7 +634,7 @@
 			failed--;
 		}
 	}
-	ide_register_module(&idescsi_driver);
+	revalidate_drives();
 	MOD_DEC_USE_COUNT;
 	return 0;
 }

@@ -906,7 +904,6 @@
 				failed++;
 			}
 	}
-	ide_unregister_module(&idescsi_driver);
 }
 
 module_init(init_idescsi_module);

include/linux/ide.h +1 -8

diff -ur linux-2.5.4/include/linux/ide.h linux/include/linux/ide.h
@@ -722,12 +722,7 @@
 	unsigned long (*capacity)(ide_drive_t *);
 	ide_startstop_t	(*special)(ide_drive_t *);
 	ide_proc_entry_t		*proc;
-	int (*driver_init)(void);
 	int (*driver_reinit)(ide_drive_t *);
-
-	/* FIXME: Single linked list of drivers for iteration.
-	 */
-	struct ide_driver_s *next;
 } ide_driver_t;
 
 #define DRIVER(drive)		((drive)->driver)

@@ -742,7 +737,6 @@
  */
 #ifndef _IDE_C
 extern struct hwif_s ide_hwifs[];		/* master data repository */
-extern struct ide_driver_s *ide_drivers;
 #endif
 extern int noautodma;

@@ -1072,8 +1066,6 @@
 #endif /* CONFIG_BLK_DEV_IDESCSI */
 #endif /* _IDE_C */
 
-extern int ide_register_module (struct ide_driver_s *d);
-extern void ide_unregister_module (struct ide_driver_s *d);
 ide_drive_t *ide_scan_devices (byte media, const char *name, ide_driver_t *driver, int n);
 extern int ide_register_subdriver(ide_drive_t *drive, ide_driver_t *driver);
 extern int ide_unregister_subdriver(ide_drive_t *drive);

@@ -1108,5 +1100,6 @@
 extern spinlock_t ide_lock;
 
 extern int drive_is_ready(ide_drive_t *drive);
+extern void revalidate_drives(void);
 
 #endif /* _IDE_H */

Martin Dalecki

2002-02-21 09:40 UTC #17 lore raw

Re: [PATCH] 2.5.5 IDE cleanup 11

Hello!

This is the next round of IDE driver cleanups.
Please note tat this applies on top of ide-clean-10.diff. ide-clean-10.diff, which was done agains 2.5.5-pre1 still applies without glitch to 2.5.5 final. (For the sake of completeness I'm attaching it as well.)

The patch does the following:

1. Start of driver tree usage upon suggestion from Pavel Machek. This still will needs a lot of further work in the future, but the current code doesn't hurt anything and allowa Pavel to work further from the base line. In esp. natively implemented suspend to file requires this - which I would love to see comming in,since I'm quite frequently using a notebook myself.

2. Kill the _IDE_C macro, which was playing games on entierly unnecessary declarations inside of header files in esp ide_modes.h

3. Replace the functionally totally equal system_bus_block() and ide_system_bus_speed() functions with one simple global
variable: system_bus_speed. This saves quite a significatn amount of code. Unfortunately this is the part, which is makeing this patch to appear bigger then it really is...

4. Use ide_devalidate_drive() directly instead of idedisk_revalidate().

5. Kill conditional CONFIG_KMOD as well as some other minor tweaks.

Well this isn't that much in terms of functionality, but it took me quite q bit of time to catch up on the patch-2.5.5.gz ;-)

Regards.

drivers/ide/ide-cd.c +2 -5

diff -ur linux-2.5.4/drivers/ide/ide-cd.c linux/drivers/ide/ide-cd.c
@@ -2906,7 +2906,6 @@
 	return 0;
 }
 
-int ide_cdrom_init(void);
 int ide_cdrom_reinit (ide_drive_t *drive);
 
 static ide_driver_t ide_cdrom_driver = {

@@ -2929,7 +2928,6 @@
 	capacity:		ide_cdrom_capacity,
 	special:		NULL,
 	proc:			NULL,
-	driver_init:		ide_cdrom_init,
 	driver_reinit:		ide_cdrom_reinit,
 };

@@ -2967,7 +2965,7 @@
 	DRIVER(drive)->busy--;
 	failed--;
 
-	ide_register_module(&ide_cdrom_driver);
+	revalidate_drives();
 	MOD_DEC_USE_COUNT;
 	return 0;
 }

@@ -2982,7 +2980,6 @@
 			printk ("%s: cleanup_module() called while still busy\n", drive->name);
 			failed++;
 		}
-	ide_unregister_module (&ide_cdrom_driver);
 }
  
 int ide_cdrom_init(void)

@@ -3026,7 +3023,7 @@
 		DRIVER(drive)->busy--;
 		failed--;
 	}
-	ide_register_module(&ide_cdrom_driver);
+	revalidate_drives();
 	MOD_DEC_USE_COUNT;
 	return 0;
 }

drivers/ide/ide-disk.c +2 -5

diff -ur linux-2.5.4/drivers/ide/ide-disk.c linux/drivers/ide/ide-disk.c
@@ -1030,7 +1030,6 @@
 	return ide_unregister_subdriver(drive);
 }
 
-int idedisk_init (void);
 int idedisk_reinit(ide_drive_t *drive);
 
 /*

@@ -1056,7 +1055,6 @@
 	capacity:		idedisk_capacity,
 	special:		idedisk_special,
 	proc:			idedisk_proc,
-	driver_init:		idedisk_init,
 	driver_reinit:		idedisk_reinit,
 };

@@ -1083,7 +1081,7 @@
 	DRIVER(drive)->busy--;
 	failed--;
 
-	ide_register_module(&idedisk_driver);
+	revalidate_drives();
 	MOD_DEC_USE_COUNT;
 	return 0;
 }

@@ -1105,7 +1103,6 @@
 			ide_remove_proc_entries(drive->proc, idedisk_proc);
 #endif
 	}
-	ide_unregister_module(&idedisk_driver);
 }
 
 int idedisk_init (void)

@@ -1130,7 +1127,7 @@
 		DRIVER(drive)->busy--;
 		failed--;
 	}
-	ide_register_module(&idedisk_driver);
+	revalidate_drives();
 	MOD_DEC_USE_COUNT;
 	return 0;
 }

drivers/ide/ide-floppy.c +2 -5

diff -ur linux-2.5.4/drivers/ide/ide-floppy.c linux/drivers/ide/ide-floppy.c
@@ -2046,7 +2046,6 @@
 
 #endif	/* CONFIG_PROC_FS */
 
-int idefloppy_init(void);
 int idefloppy_reinit(ide_drive_t *drive);
 
 /*

@@ -2072,7 +2071,6 @@
 	capacity:		idefloppy_capacity,
 	special:		NULL,
 	proc:			idefloppy_proc,
-	driver_init:		idefloppy_init,
 	driver_reinit:		idefloppy_reinit,
 };

@@ -2105,7 +2103,7 @@
 		DRIVER(drive)->busy--;
 		failed--;
 	}
-	ide_register_module(&idefloppy_driver);
+	revalidate_drives();
 	MOD_DEC_USE_COUNT;
 	return 0;
 }

@@ -2130,7 +2128,6 @@
 			ide_remove_proc_entries(drive->proc, idefloppy_proc);
 #endif
 	}
-	ide_unregister_module(&idefloppy_driver);
 }
 
 /*

@@ -2167,7 +2164,7 @@
 		DRIVER(drive)->busy--;
 		failed--;
 	}
-	ide_register_module(&idefloppy_driver);
+	revalidate_drives();
 	MOD_DEC_USE_COUNT;
 	return 0;
 }

drivers/ide/ide-proc.c +0 ~~-17~~

diff -ur linux-2.5.4/drivers/ide/ide-proc.c linux/drivers/ide/ide-proc.c
@@ -373,20 +373,6 @@
 	return digit;
 }
 
-static int proc_ide_read_drivers
-	(char *page, char **start, off_t off, int count, int *eof, void *data)
-{
-	char		*out = page;
-	int		len;
-	struct ide_driver_s * driver;
-
-	for (driver = ide_drivers; driver; driver = driver->next) {
-		out += sprintf(out, "%s\n",driver->name);
-	}
-	len = out - page;
-	PROC_IDE_READ_RETURN(page,start,off,count,eof,len);
-}
-
 static int proc_ide_read_imodel
 	(char *page, char **start, off_t off, int count, int *eof, void *data)
 {

@@ -852,9 +838,6 @@
 
 	create_proc_ide_interfaces();
 
-	create_proc_read_entry("drivers", 0, proc_ide_root,
-				proc_ide_read_drivers, NULL);
-
 #ifdef CONFIG_BLK_DEV_AEC62XX
 	if ((aec62xx_display_info) && (aec62xx_proc))
 		create_proc_info_entry("aec62xx", 0, proc_ide_root, aec62xx_display_info);

drivers/ide/ide-tape.c +4 -7

diff -ur linux-2.5.4/drivers/ide/ide-tape.c linux/drivers/ide/ide-tape.c
@@ -6137,7 +6137,6 @@
 
 #endif
 
-int idetape_init (void);
 int idetape_reinit(ide_drive_t *drive);
 
 /*

@@ -6162,7 +6161,6 @@
 	pre_reset:		idetape_pre_reset,
 	capacity:		NULL,
 	proc:			idetape_proc,
-	driver_init:		idetape_init,
 	driver_reinit:		idetape_reinit,
 };

@@ -6193,7 +6191,7 @@
 			idetape_chrdevs[minor].drive = NULL;
 
 	if ((drive = ide_scan_devices (ide_tape, idetape_driver.name, NULL, failed++)) == NULL) {
-		ide_register_module (&idetape_module);
+		revalidate_drives();
 		MOD_DEC_USE_COUNT;
 #if ONSTREAM_DEBUG
 		printk(KERN_INFO "ide-tape: MOD_DEC_USE_COUNT in idetape_init\n");

@@ -6252,7 +6250,7 @@
 		devfs_unregister_chrdev (IDETAPE_MAJOR, "ht");
 	} else
 		idetape_chrdev_present = 1;
-	ide_register_module (&idetape_module);
+	revalidate_drives();
 	MOD_DEC_USE_COUNT;
 #if ONSTREAM_DEBUG
 	printk(KERN_INFO "ide-tape: MOD_DEC_USE_COUNT in idetape_init\n");

@@ -6277,7 +6275,6 @@
 		if (drive != NULL && idetape_cleanup (drive))
 		printk (KERN_ERR "ide-tape: %s: cleanup_module() called while still busy\n", drive->name);
 	}
-	ide_unregister_module(&idetape_driver);
 }
 
 /*

@@ -6298,7 +6295,7 @@
 			idetape_chrdevs[minor].drive = NULL;
 
 	if ((drive = ide_scan_devices (ide_tape, idetape_driver.name, NULL, failed++)) == NULL) {
-		ide_register_module (&idetape_driver);
+		revalidate_drives();
 		MOD_DEC_USE_COUNT;
 #if ONSTREAM_DEBUG
 		printk(KERN_INFO "ide-tape: MOD_DEC_USE_COUNT in idetape_init\n");

@@ -6357,7 +6354,7 @@
 		devfs_unregister_chrdev (IDETAPE_MAJOR, "ht");
 	} else
 		idetape_chrdev_present = 1;
-	ide_register_module (&idetape_driver);
+	revalidate_drives();
 	MOD_DEC_USE_COUNT;
 #if ONSTREAM_DEBUG
 	printk(KERN_INFO "ide-tape: MOD_DEC_USE_COUNT in idetape_init\n");

drivers/ide/ide.c +6 ~~-35~~

78 lines not on this page · raw message

drivers/scsi/ide-scsi.c +2 -5

diff -ur linux-2.5.4/drivers/scsi/ide-scsi.c linux/drivers/scsi/ide-scsi.c
@@ -535,7 +535,6 @@
 	return 0;
 }
 
-int idescsi_init(void);
 int idescsi_reinit(ide_drive_t *drive);
 
 /*

@@ -561,7 +560,6 @@
 	capacity:		NULL,
 	special:		NULL,
 	proc:			NULL,
-	driver_init:		idescsi_init,
 	driver_reinit:		idescsi_reinit,
 };

@@ -596,7 +594,7 @@
 			failed--;
 		}
 	}
-	ide_register_module(&idescsi_module);
+	revalidate_drives();
 	MOD_DEC_USE_COUNT;
 #endif
 	return 0;

@@ -636,7 +634,7 @@
 			failed--;
 		}
 	}
-	ide_register_module(&idescsi_driver);
+	revalidate_drives();
 	MOD_DEC_USE_COUNT;
 	return 0;
 }

@@ -906,7 +904,6 @@
 				failed++;
 			}
 	}
-	ide_unregister_module(&idescsi_driver);
 }
 
 module_init(init_idescsi_module);

include/linux/ide.h +1 -8

diff -ur linux-2.5.4/include/linux/ide.h linux/include/linux/ide.h
@@ -722,12 +722,7 @@
 	unsigned long (*capacity)(ide_drive_t *);
 	ide_startstop_t	(*special)(ide_drive_t *);
 	ide_proc_entry_t		*proc;
-	int (*driver_init)(void);
 	int (*driver_reinit)(ide_drive_t *);
-
-	/* FIXME: Single linked list of drivers for iteration.
-	 */
-	struct ide_driver_s *next;
 } ide_driver_t;
 
 #define DRIVER(drive)		((drive)->driver)

@@ -742,7 +737,6 @@
  */
 #ifndef _IDE_C
 extern struct hwif_s ide_hwifs[];		/* master data repository */
-extern struct ide_driver_s *ide_drivers;
 #endif
 extern int noautodma;

@@ -1072,8 +1066,6 @@
 #endif /* CONFIG_BLK_DEV_IDESCSI */
 #endif /* _IDE_C */
 
-extern int ide_register_module (struct ide_driver_s *d);
-extern void ide_unregister_module (struct ide_driver_s *d);
 ide_drive_t *ide_scan_devices (byte media, const char *name, ide_driver_t *driver, int n);
 extern int ide_register_subdriver(ide_drive_t *drive, ide_driver_t *driver);
 extern int ide_unregister_subdriver(ide_drive_t *drive);

@@ -1108,5 +1100,6 @@
 extern spinlock_t ide_lock;
 
 extern int drive_is_ready(ide_drive_t *drive);
+extern void revalidate_drives(void);
 
 #endif /* _IDE_H */

drivers/ide/aec62xx.c +2 -6

diff -ur linux-2.5.5/drivers/ide/aec62xx.c linux/drivers/ide/aec62xx.c
@@ -203,22 +203,18 @@
 
 static byte pci_bus_clock_list (byte speed, struct chipset_bus_clock_list_entry * chipset_table)
 {
-	int bus_speed = system_bus_clock();
-
 	for ( ; chipset_table->xfer_speed ; chipset_table++)
 		if (chipset_table->xfer_speed == speed) {
-			return ((byte) ((bus_speed <= 33) ? chipset_table->chipset_settings_33 : chipset_table->chipset_settings_34));
+			return ((byte) ((system_bus_speed <= 33) ? chipset_table->chipset_settings_33 : chipset_table->chipset_settings_34));
 		}
 	return 0x00;
 }
 
 static byte pci_bus_clock_list_ultra (byte speed, struct chipset_bus_clock_list_entry * chipset_table)
 {
-	int bus_speed = system_bus_clock();
-
 	for ( ; chipset_table->xfer_speed ; chipset_table++)
 		if (chipset_table->xfer_speed == speed) {
-			return ((byte) ((bus_speed <= 33) ? chipset_table->ultra_settings_33 : chipset_table->ultra_settings_34));
+			return ((byte) ((system_bus_speed <= 33) ? chipset_table->ultra_settings_33 : chipset_table->ultra_settings_34));
 		}
 	return 0x00;
 }

drivers/ide/ali14xx.c +2 -3

diff -ur linux-2.5.5/drivers/ide/ali14xx.c linux/drivers/ide/ali14xx.c
@@ -119,15 +119,14 @@
 	byte param1, param2, param3, param4;
 	unsigned long flags;
 	ide_pio_data_t d;
-	int bus_speed = system_bus_clock();
 
 	pio = ide_get_best_pio_mode(drive, pio, ALI_MAX_PIO, &d);
 
 	/* calculate timing, according to PIO mode */
 	time1 = d.cycle_time;
 	time2 = ide_pio_timings[pio].active_time;
-	param3 = param1 = (time2 * bus_speed + 999) / 1000;
-	param4 = param2 = (time1 * bus_speed + 999) / 1000 - param1;
+	param3 = param1 = (time2 * system_bus_speed + 999) / 1000;
+	param4 = param2 = (time1 * system_bus_speed + 999) / 1000 - param1;
 	if (pio < 3) {
 		param3 += 8;
 		param4 += 8;

drivers/ide/alim15x3.c +4 -5

diff -ur linux-2.5.5/drivers/ide/alim15x3.c linux/drivers/ide/alim15x3.c
@@ -247,7 +247,6 @@
 	int s_time, a_time, c_time;
 	byte s_clc, a_clc, r_clc;
 	unsigned long flags;
-	int bus_speed = system_bus_clock();
 	int port = hwif->index ? 0x5c : 0x58;
 	int portFIFO = hwif->channel ? 0x55 : 0x54;
 	byte cd_dma_fifo = 0;

@@ -255,18 +254,18 @@
 	pio = ide_get_best_pio_mode(drive, pio, 5, &d);
 	s_time = ide_pio_timings[pio].setup_time;
 	a_time = ide_pio_timings[pio].active_time;
-	if ((s_clc = (s_time * bus_speed + 999) / 1000) >= 8)
+	if ((s_clc = (s_time * system_bus_speed + 999) / 1000) >= 8)
 		s_clc = 0;
-	if ((a_clc = (a_time * bus_speed + 999) / 1000) >= 8)
+	if ((a_clc = (a_time * system_bus_speed + 999) / 1000) >= 8)
 		a_clc = 0;
 	c_time = ide_pio_timings[pio].cycle_time;
 
 #if 0
-	if ((r_clc = ((c_time - s_time - a_time) * bus_speed + 999) / 1000) >= 16)
+	if ((r_clc = ((c_time - s_time - a_time) * system_bus_speed + 999) / 1000) >= 16)
 		r_clc = 0;
 #endif
 
-	if (!(r_clc = (c_time * bus_speed + 999) / 1000 - a_clc - s_clc)) {
+	if (!(r_clc = (c_time * system_bus_speed + 999) / 1000 - a_clc - s_clc)) {
 		r_clc = 1;
 	} else {
 		if (r_clc >= 16)

drivers/ide/cmd640.c +2 -3

diff -ur linux-2.5.5/drivers/ide/cmd640.c linux/drivers/ide/cmd640.c
@@ -23,7 +23,7 @@
  *
  *  [email protected], [email protected], [email protected],
  *  [email protected], [email protected], [email protected],
- *  [email protected], [email protected],
+ *  [email protected], [email protected],
  *  [email protected], [email protected],
  *  [email protected], [email protected], [email protected],
  *  [email protected], [email protected], [email protected],

@@ -596,14 +596,13 @@
 {
 	int setup_time, active_time, recovery_time, clock_time;
 	byte setup_count, active_count, recovery_count, recovery_count2, cycle_count;
-	int bus_speed = system_bus_clock();
 
 	if (pio_mode > 5)
 		pio_mode = 5;
 	setup_time  = ide_pio_timings[pio_mode].setup_time;
 	active_time = ide_pio_timings[pio_mode].active_time;
 	recovery_time = cycle_time - (setup_time + active_time);
-	clock_time = 1000 / bus_speed;
+	clock_time = 1000 / system_bus_speed;
 	cycle_count = (cycle_time + clock_time - 1) / clock_time;
 
 	setup_count = (setup_time + clock_time - 1) / clock_time;

drivers/ide/cmd64x.c +1 -3

diff -ur linux-2.5.5/drivers/ide/cmd64x.c linux/drivers/ide/cmd64x.c
@@ -283,8 +283,6 @@
 	int setup_time, active_time, recovery_time, clock_time, pio_mode, cycle_time;
 	byte recovery_count2, cycle_count;
 	int setup_count, active_count, recovery_count;
-	int bus_speed = system_bus_clock();
-	/*byte b;*/
 	ide_pio_data_t  d;
 
 	switch (mode_wanted) {

@@ -309,7 +307,7 @@
 	setup_time  = ide_pio_timings[pio_mode].setup_time;
 	active_time = ide_pio_timings[pio_mode].active_time;
 	recovery_time = cycle_time - (setup_time + active_time);
-	clock_time = 1000 / bus_speed;
+	clock_time = 1000 / system_bus_speed;
 	cycle_count = (cycle_time + clock_time - 1) / clock_time;
 
 	setup_count = (setup_time + clock_time - 1) / clock_time;

drivers/ide/cy82c693.c +3 -4

diff -ur linux-2.5.5/drivers/ide/cy82c693.c linux/drivers/ide/cy82c693.c
@@ -141,7 +141,6 @@
 static void compute_clocks (byte pio, pio_clocks_t *p_pclk)
 {
 	int clk1, clk2;
-	int bus_speed = system_bus_clock();	/* get speed of PCI bus */
 
 	/* we don't check against CY82C693's min and max speed,
 	 * so you can play with the idebus=xx parameter

@@ -151,17 +150,17 @@
 		pio = CY82C693_MAX_PIO;
 
 	/* let's calc the address setup time clocks */
-	p_pclk->address_time = (byte)calc_clk(ide_pio_timings[pio].setup_time, bus_speed);
+	p_pclk->address_time = (byte)calc_clk(ide_pio_timings[pio].setup_time, system_bus_speed);
 
 	/* let's calc the active and recovery time clocks */
-	clk1 = calc_clk(ide_pio_timings[pio].active_time, bus_speed);
+	clk1 = calc_clk(ide_pio_timings[pio].active_time, system_bus_speed);
 
 	/* calc recovery timing */
 	clk2 =	ide_pio_timings[pio].cycle_time -
 		ide_pio_timings[pio].active_time -
 		ide_pio_timings[pio].setup_time;
 
-	clk2 = calc_clk(clk2, bus_speed);
+	clk2 = calc_clk(clk2, system_bus_speed);
 
 	clk1 = (clk1<<4)|clk2;	/* combine active and recovery clocks */

drivers/ide/ht6560b.c +2 -3

diff -ur linux-2.5.5/drivers/ide/ht6560b.c linux/drivers/ide/ht6560b.c
@@ -207,7 +207,6 @@
 	int active_time, recovery_time;
 	int active_cycles, recovery_cycles;
 	ide_pio_data_t d;
-	int bus_speed = system_bus_clock();
 	
         if (pio) {
 		pio = ide_get_best_pio_mode(drive, pio, 5, &d);

@@ -224,8 +223,8 @@
 		/*
 		 *  Cycle times should be Vesa bus cycles
 		 */
-		active_cycles   = (active_time   * bus_speed + 999) / 1000;
-		recovery_cycles = (recovery_time * bus_speed + 999) / 1000;
+		active_cycles   = (active_time   * system_bus_speed + 999) / 1000;
+		recovery_cycles = (recovery_time * system_bus_speed + 999) / 1000;
 		/*
 		 *  Upper and lower limits
 		 */

drivers/ide/ide-disk.c +34 ~~-11~~

91 lines not on this page · raw message

drivers/ide/ide-pnp.c +4 -2

diff -ur linux-2.5.5/drivers/ide/ide-pnp.c linux/drivers/ide/ide-pnp.c
@@ -57,6 +57,7 @@
 static int __init pnpide_generic_init(struct pci_dev *dev, int enable)
 {
 	hw_regs_t hw;
+	ide_hwif_t *hwif;
 	int index;
 
 	if (!enable)

@@ -69,10 +70,11 @@
 			generic_ide_offsets, (ide_ioreg_t) DEV_IO(dev, 1),
 			0, NULL, DEV_IRQ(dev, 0));
 
-	index = ide_register_hw(&hw, NULL);
+	index = ide_register_hw(&hw, &hwif);
 
 	if (index != -1) {
-	    	printk("ide%d: %s IDE interface\n", index, DEV_NAME(dev));
+		hwif->pci_dev = dev;
+		printk("ide%d: %s IDE interface\n", index, DEV_NAME(dev));
 		return 0;
 	}

drivers/ide/ide-probe.c +12 -0

diff -ur linux-2.5.5/drivers/ide/ide-probe.c linux/drivers/ide/ide-probe.c
@@ -46,6 +46,7 @@
 #include <linux/delay.h>
 #include <linux/ide.h>
 #include <linux/spinlock.h>
+#include <linux/pci.h>
 
 #include <asm/byteorder.h>
 #include <asm/irq.h>

@@ -465,6 +466,17 @@
 
 static void hwif_register (ide_hwif_t *hwif)
 {
+	/* Register this hardware interface within the global device tree.
+	 */
+	sprintf(hwif->device.bus_id, "%04x", hwif->io_ports[IDE_DATA_OFFSET]);
+	sprintf(hwif->device.name, "ide");
+	hwif->device.driver_data = hwif;
+	if (hwif->pci_dev)
+		hwif->device.parent = &hwif->pci_dev->dev;
+	else
+		hwif->device.parent = NULL; /* Would like to do = &device_legacy */
+	device_register(&hwif->device);
+
 	if (((unsigned long)hwif->io_ports[IDE_DATA_OFFSET] | 7) ==
 	    ((unsigned long)hwif->io_ports[IDE_STATUS_OFFSET])) {
 		ide_request_region(hwif->io_ports[IDE_DATA_OFFSET], 8, hwif->name);

drivers/ide/ide.c +216 ~~-48~~

333 lines not on this page · raw message

drivers/ide/ide_modes.h +2 ~~-196~~

211 lines not on this page · raw message

drivers/ide/opti621.c +4 -5

diff -ur linux-2.5.5/drivers/ide/opti621.c linux/drivers/ide/opti621.c
@@ -164,7 +164,7 @@
 	}
 }
 
-int cmpt_clk(int time, int bus_speed)
+static int cmpt_clk(int time, int bus_speed)
 /* Returns (rounded up) time in clocks for time in ns,
  * with bus_speed in MHz.
  * Example: bus_speed = 40 MHz, time = 80 ns

@@ -216,14 +216,13 @@
 {
         if (pio != PIO_NOT_EXIST) {
         	int adr_setup, data_pls;
-		int bus_speed = system_bus_clock();
 
  	       	adr_setup = ide_pio_timings[pio].setup_time;
   	      	data_pls = ide_pio_timings[pio].active_time;
-	  	clks->address_time = cmpt_clk(adr_setup, bus_speed);
-	     	clks->data_time = cmpt_clk(data_pls, bus_speed);
+	  	clks->address_time = cmpt_clk(adr_setup, system_bus_speed);
+	     	clks->data_time = cmpt_clk(data_pls, system_bus_speed);
      		clks->recovery_time = cmpt_clk(ide_pio_timings[pio].cycle_time
-     			- adr_setup-data_pls, bus_speed);
+     			- adr_setup-data_pls, system_bus_speed);
      		if (clks->address_time<1) clks->address_time = 1;
      		if (clks->address_time>4) clks->address_time = 4;
      		if (clks->data_time<1) clks->data_time = 1;

drivers/ide/qd65xx.c +7 -7

diff -ur linux-2.5.5/drivers/ide/qd65xx.c linux/drivers/ide/qd65xx.c
@@ -139,12 +139,12 @@
 {
 	byte active_cycle,recovery_cycle;
 
-	if (ide_system_bus_speed()<=33) {
-		active_cycle =   9  - IDE_IN(active_time   * ide_system_bus_speed() / 1000 + 1, 2, 9);
-		recovery_cycle = 15 - IDE_IN(recovery_time * ide_system_bus_speed() / 1000 + 1, 0, 15);
+	if (system_bus_speed <= 33) {
+		active_cycle =   9  - IDE_IN(active_time   * system_bus_speed / 1000 + 1, 2, 9);
+		recovery_cycle = 15 - IDE_IN(recovery_time * system_bus_speed / 1000 + 1, 0, 15);
 	} else {
-		active_cycle =   8  - IDE_IN(active_time   * ide_system_bus_speed() / 1000 + 1, 1, 8);
-		recovery_cycle = 18 - IDE_IN(recovery_time * ide_system_bus_speed() / 1000 + 1, 3, 18);
+		active_cycle =   8  - IDE_IN(active_time   * system_bus_speed / 1000 + 1, 1, 8);
+		recovery_cycle = 18 - IDE_IN(recovery_time * system_bus_speed / 1000 + 1, 3, 18);
 	}
 
 	return((recovery_cycle<<4) | 0x08 | active_cycle);

@@ -158,8 +158,8 @@
 
 static byte qd6580_compute_timing (int active_time, int recovery_time)
 {
-	byte active_cycle   = 17-IDE_IN(active_time   * ide_system_bus_speed() / 1000 + 1, 2, 17);
-	byte recovery_cycle = 15-IDE_IN(recovery_time * ide_system_bus_speed() / 1000 + 1, 2, 15);
+	byte active_cycle   = 17-IDE_IN(active_time   * system_bus_speed / 1000 + 1, 2, 17);
+	byte recovery_cycle = 15-IDE_IN(recovery_time * system_bus_speed / 1000 + 1, 2, 15);
 
 	return((recovery_cycle<<4) | active_cycle);
 }

drivers/ide/via82cxxx.c +1 -1

diff -ur linux-2.5.5/drivers/ide/via82cxxx.c linux/drivers/ide/via82cxxx.c
@@ -484,7 +484,7 @@
  * Determine system bus clock.
  */
 
-	via_clock = system_bus_clock() * 1000;
+	via_clock = system_bus_speed * 1000;
 
 	switch (via_clock) {
 		case 33000: via_clock = 33333; break;

include/linux/blk.h +0 -5

diff -ur linux-2.5.5/include/linux/blk.h linux/include/linux/blk.h
@@ -8,11 +8,6 @@
 #include <linux/spinlock.h>
 #include <linux/compiler.h>
 
-/*
- * get rid of this next...
- */
-extern int ide_init(void);
-
 extern void set_device_ro(kdev_t dev,int flag);
 extern void add_blkdev_randomness(int major);

include/linux/ide.h +19 ~~-30~~

127 lines not on this page · raw message

Alan Cox

2002-02-21 13:45 UTC #18 lore raw

Re: [PATCH] 2.5.5 IDE cleanup 11

Quoted 1 line

This is the next round of IDE driver cleanups.

How about fixing the stuff you've already messed up (like putting the drive present flags and the probe return back) ? The changes you made to the init code also broke the framework so that 2.5 would eventually let you do

	open("/dev/cdrom")
	read/write
	close("/dev/cdrom")
	open("/dev/sda")		/* Same device */
	burn a cd

without loading/unloading modules

I'm also confused how you plan to fix the hot swap case after your changes because you've not allowed for the fact drives might be hot swapped while you are suspended. The old code was careful to keep the hooks for that ready.

Finally you forgot to update the MAINTAINER entry since you've now clearly decided to walk over Andre and become the IDE maintainer

Alan

Martin Dalecki

2002-02-21 17:34 UTC #19 lore raw

Re: [PATCH] 2.5.5 IDE cleanup 11

Quoted 5 lines · Alan Cox

Quoted 2 lines
This is the next round of IDE driver cleanups.
How about fixing the stuff you've already messed up (like putting the drive present flags and the probe return back) ? The changes you made

Please note that *this* stuff was messed up before as well.

In esp using a CardBus ide adapter will give you after first
plug: /dev/hdc, after second plug /dev/hde and so on... on 2.4.17.

I'm just rying to clarify the code-flow before stuff like the above can be cleaned up.

And please note that it certainly was and isn't a good idea to call the module initialization routine twice. OK?

Alan Cox

2002-02-21 17:42 UTC #20 lore raw

Re: [PATCH] 2.5.5 IDE cleanup 11

Quoted 2 lines

In esp using a CardBus ide adapter will give you after first
plug: /dev/hdc, after second plug /dev/hde and so on... on 2.4.17.

Just tried that - its working for me in 2.4.18pre - do you know what triggers that ?

Quoted 2 lines

I'm just rying to clarify the code-flow before stuff like the above can be cleaned up.

The problem is if you keep cleaning up stuff which was there ready to merge new stuff, then its impossible to merge new stuff. At the moment there are two many cooks involved in that code. It all needs to go via one person and in an ordered way - even if it isnt Andre since Linus and Andre aren't the most compatible people 8)

Martin Dalecki

2002-02-21 18:18 UTC #21 lore raw

Re: [PATCH] 2.5.5 IDE cleanup 11

Quoted 5 lines · Alan Cox

Quoted 2 lines
In esp using a CardBus ide adapter will give you after first
plug: /dev/hdc, after second plug /dev/hde and so on... on 2.4.17
Just tried that - its working for me in 2.4.18pre - do you know what triggers that ?

1. Clarification: The system where 2.4.18rc2, 2.5.5+x

2. Yes I know it is the very same bad workflow of initialization and deallocation routines. I suppose that the particular cause is inside the ide_module_t area.

3. I was compleatly ignorant about calling some device eject utilities or similar.

Quoted 9 lines

Quoted 3 lines
I'm just rying to clarify the code-flow before stuff like the above can be cleaned up.
The problem is if you keep cleaning up stuff which was there ready to merge new stuff, then its impossible to merge new stuff. At the moment there are two many cooks involved in that code. It all needs to go via one person and in an ordered way - even if it isnt Andre since Linus and Andre aren't the most compatible people 8)

Andre already asked in private if I would dare to take care of new stuff comming from him for 2.5.5.

Please note that thus far I didn't see *any* concerete code from him.

But I still don't see any great problems in merging some forthcomming stuff iff it comes along.

Please see as well the quite nice mode of cooperation I had with Vojtech Pavlik.

Please note further that the foundations for true hot plugging done the right way where comming from Pavel Machek i have just picked it up as well as the _IDE_C mess and some other nit's here and there.

And finally - I don't do anything inside an ebony tower - I just *post* everything to lkml - whatever finished or not. Please feel free to discuss it.

Everybody who wants to contribute *please feel free* to post a ide-clean-11+x.diff. I'm NOT playing hodge on the code at all!

So the political problems you talk about are perhaps just not there...

Andre Hedrick

2002-02-21 21:37 UTC #22 lore raw

Re: [PATCH] 2.5.5 IDE cleanup 11

http://www.kernel.org/pub/linux/kernel/people/hedrick/ide-2.5.5/

Quoted 23 lines · Alan Cox

Quoted 1 line
This is the next round of IDE driver cleanups.
How about fixing the stuff you've already messed up (like putting the drive present flags and the probe return back) ? The changes you made to the init code also broke the framework so that 2.5 would eventually let you do
	open("/dev/cdrom")
	read/write
	close("/dev/cdrom")
	open("/dev/sda")		/* Same device */
	burn a cd
without loading/unloading modules
I'm also confused how you plan to fix the hot swap case after your changes because you've not allowed for the fact drives might be hot swapped while you are suspended. The old code was careful to keep the hooks for that ready.
Finally you forgot to update the MAINTAINER entry since you've now clearly decided to walk over Andre and become the IDE maintainer

Quoted 7 lines

Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Alan,

Please let me correct this issue as now I am going to start new driver since this one is now beyond repair for me.

Regards,

Andre Hedrick
Linux Disk Certification Project Linux ATA Development

Andre Hedrick

2002-02-21 21:42 UTC #23 lore raw

Re: [PATCH] 2.5.5 IDE cleanup 11

Alan,

Sorry I forgot to include the patch.

Andre Hedrick
Linux Disk Certification Project Linux ATA Development

Quoted 40 lines · Andre Hedrick

Quoted 23 lines · Alan Cox
Quoted 1 line
This is the next round of IDE driver cleanups.
How about fixing the stuff you've already messed up (like putting the drive present flags and the probe return back) ? The changes you made to the init code also broke the framework so that 2.5 would eventually let you do
	open("/dev/cdrom")
	read/write
	close("/dev/cdrom")
	open("/dev/sda")		/* Same device */
	burn a cd
without loading/unloading modules
I'm also confused how you plan to fix the hot swap case after your changes because you've not allowed for the fact drives might be hot swapped while you are suspended. The old code was careful to keep the hooks for that ready.
Finally you forgot to update the MAINTAINER entry since you've now clearly decided to walk over Andre and become the IDE maintainer
Quoted 7 lines
Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Alan,
Please let me correct this issue as now I am going to start new driver since this one is now beyond repair for me.
Regards,

Quoted 9 lines

Andre Hedrick
Linux Disk Certification Project Linux ATA Development
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

MAINTAINERS renamed from MAINTAINERS.orig +12 -6

@@ -697,13 +697,9 @@
 S:      Supported 
 
 IDE DRIVER [GENERAL]
-P:	Andre Hedrick
-M:	[email protected]
-M:	[email protected]
+P:	Martin Dalecki	
+M:	Martin Dalecki <[email protected]>
 L:	[email protected]
-W:	http://www.kernel.org/pub/linux/kernel/people/hedrick/
-W:	http://www.linux-ide.org/
-W:	http://www.linuxdiskcert.org/
 S:	Maintained
 
 IDE/ATAPI CDROM DRIVER

@@ -1523,6 +1519,16 @@
 L:	[email protected]
 W:	http://vtun.sourceforge.net/tun
 S:	Maintained
+
+SATA/PATA/ACB DRIVER [ALL]
+P:	Andre Hedrick
+M:	[email protected]
+M:	[email protected]
+L:	[email protected]
+W:	http://www.kernel.org/pub/linux/kernel/people/hedrick/
+W:	http://www.linux-ide.org/
+W:	http://www.linuxdiskcert.org/
+S:	Future Creation
 
 U14-34F SCSI DRIVER
 P:	Dario Ballabio

Andre Hedrick

2002-02-22 09:38 UTC #24 lore raw

Flash Back -- kernel 2.1.111

Linus,

If you want me to continue to work on 2.5.5, back it all out. Otherwise Martin Dalecki is your NEW IDE Maintainer in the Development tree and beyond. I will continue to work on 2.4.X it is save from such changes.

I refuse to fix this mess. I go off to a standards meeting for two days and come back to a destroyed STACK. There is no reason for me to continue to lobby for modification the Microsoft Proposal of a new command, Force Unit Access, as make the Journaling File Systems stable. Especially since their proposal and usage of the command under EXT3/Reiser/XFS/etc would damage the data.

Please allow him to UPDATE and correct the SCSI core, also. I was joking with Christoph Hellwig about his work on the SCSI API, suggested he work with Martin to accellerate the rewrite. So I am inviting Martin to assist in the SCSI directory and any other place you needs such an incredible grasp of your "DARWINISM" v/s logical "DESIGN".

Regards,

Andre Hedrick
Linux Disk Certification Project Linux ATA Development

Rik van Riel

2002-02-22 10:09 UTC #25 lore raw

Re: Flash Back -- kernel 2.1.111

Quoted 5 lines · Andre Hedrick

Please allow him to UPDATE and correct the SCSI core, also. I was joking with Christoph Hellwig about his work on the SCSI API, suggested he work with Martin to accellerate the rewrite. So I am inviting Martin to assist in the SCSI directory and any other place you needs such an incredible grasp of your "DARWINISM" v/s logical "DESIGN".

Martin,

please tell us up-front if you are able to make Linux work with 48-bit IDE stuff so Linux is able to talk to drives larger than 137 GB.

If you're not, please stop pissing off Andre and work together with him ... we need the features of his new IDE work in order to be able to support the new IDE hardware which is being released soon (or sold already).

cheers,

Rik

Signature · 4 lines

"Linux holds advantages over the single-vendor commercial OS"
    -- Microsoft's "Competing with Linux" document

http://www.surriel.com/		http://distro.conectiva.com/

Linus Torvalds

author

2002-02-22 17:08 UTC #26 lore raw

Re: Flash Back -- kernel 2.1.111

Quoted 9 lines · Rik van Riel

Martin,
please tell us up-front if you are able to make Linux work with 48-bit IDE stuff so Linux is able to talk to drives larger than 137 GB.
If you're not, please stop pissing off Andre and work together with him ...

Rik, get off the high horse.

2.5.x already supports 48-bit LBA addressing.

And quite frankly, it's not Martin who cannot work with Andre, it's Andre who so far has shown himself _totally_ unable to work with anybody at all.

Whenever somebody comes and even tries to do trivial and obviously correct cleanups that do not actually change any semantics at all, Andre stands out and shouts bloody murder from the rooftops, completely ignoring the fact that he hasn't even looked at the patches.

All the crap Andre has shouted about "IDE mess" and "timing changes" is total and utter CRAP. None of the patches I've seen has changed _anything_ but cleanups, or removed _any_ features.

Guys, you need to realize that Martin is NOT the bad guy here. The problem is not Martin, the problem is that Andre cannot take any level or criticism, and in the five years or so that he has been maintainer I have yet to see a _single_ person who has been able to work together with him (as opposed to some people who have been able to maintain their own subdrivers _despite_ him).

Andre, your threats about not wanting to maintain 2.5.x are just a symptom of this inability to accept the fact that other people actually do know what they are doing, even if what they are doing is only cleanups with no semantic changes.

Rik, _look_ at the patches, instead of just taking Andre's word for it.

Linus

Andre Hedrick

2002-02-22 19:11 UTC #27 lore raw

Re: Flash Back -- kernel 2.1.111

Linus,

Obvious you have a bug up the backside, so I am totally hands off until you and Martin are done. See you back at 2.5.10. I will not comment on the changes because you want something and I do not have the timetable to deliver and you are upset.

I am more concerned with the stablity of the core of ATA/ATAPI and next in queue was to address the entire ATAPI data-phases issues that appear to have some problems.

It is clear you want a cosmetic change and I am not ready to make one.

Therefore I will be patient and wait for you get the facelift you want and then see what needs to be salvaged afterwards.

--a

Quoted 44 lines · Linus Torvalds

Quoted 9 lines · Rik van Riel
Martin,
please tell us up-front if you are able to make Linux work with 48-bit IDE stuff so Linux is able to talk to drives larger than 137 GB.
If you're not, please stop pissing off Andre and work together with him ...
Rik, get off the high horse.
2.5.x already supports 48-bit LBA addressing.
And quite frankly, it's not Martin who cannot work with Andre, it's Andre who so far has shown himself _totally_ unable to work with anybody at all.
Whenever somebody comes and even tries to do trivial and obviously correct cleanups that do not actually change any semantics at all, Andre stands out and shouts bloody murder from the rooftops, completely ignoring the fact that he hasn't even looked at the patches.
All the crap Andre has shouted about "IDE mess" and "timing changes" is total and utter CRAP. None of the patches I've seen has changed _anything_ but cleanups, or removed _any_ features.
Guys, you need to realize that Martin is NOT the bad guy here. The problem is not Martin, the problem is that Andre cannot take any level or criticism, and in the five years or so that he has been maintainer I have yet to see a _single_ person who has been able to work together with him (as opposed to some people who have been able to maintain their own subdrivers _despite_ him).
Andre, your threats about not wanting to maintain 2.5.x are just a symptom of this inability to accept the fact that other people actually do know what they are doing, even if what they are doing is only cleanups with no semantic changes.
Rik, _look_ at the patches, instead of just taking Andre's word for it.
Linus

Linus Torvalds

author

2002-02-23 17:57 UTC #28 lore raw

Re: Flash Back -- kernel 2.1.111

Quoted 2 lines · Andre Hedrick

Obvious you have a bug up the backside

Yes.

What really bugs me about this is that while normally you're hard to communicate with, this time you have actively _lied_ about the patches on IRC and in email about how they will cause IDE corruption etc due to timing changes.

No such timing changes existed, and whenever you were asked about what was actually actively _wrong_ with the patches, you didn't reply.

There's a difference between being difficult to work with and being actively dishonest, and you crossed that line.

Linus

Andre Hedrick

2002-02-24 04:55 UTC #29 lore raw

Re: Flash Back -- kernel 2.1.111

Quoted 11 lines · Linus Torvalds

Quoted 2 lines · Andre Hedrick
Obvious you have a bug up the backside
Yes.
What really bugs me about this is that while normally you're hard to communicate with, this time you have actively _lied_ about the patches on IRC and in email about how they will cause IDE corruption etc due to timing changes.

Before I truley reply to this statement above, would you like to recant it?

Quoted 2 lines

No such timing changes existed, and whenever you were asked about what was actually actively _wrong_ with the patches, you didn't reply.

Here I question the taking of a patch 12 which altered the behavior of the subsystem baseclock to setting up PIO timings for the executing command block operations. I then looked over the patch again and saw you had not taken it yet.

In that private email, I clearly stated I made a mistake in reading what was accepted into 2.5.5. The fact is you had not accepted it yet. However I expect you will take it. Given that very few people in the world have most of the hardware that was effected by that change, and even less have the NDA documents on the rules, please accept the change.

Quoted 2 lines

There's a difference between being difficult to work with and being actively dishonest, and you crossed that line.

If this line has be crossed it is because you have moved and altered that which is defined as truth. You by now are having other people question your position on issues, and I will leave it at that ...

Regards,

Andre Hedrick
Linux Disk Certification Project Linux ATA Development

Andre Hedrick

2002-02-24 05:51 UTC #30 lore raw

Re: Flash Back -- kernel 2.1.111

Wait -- this was a stupid reply by me.

The correct response should have been ...

"LIAR LIAR PANTS ON FIRE"

Linus,

Lets both grow up!

Cheers,

Andre Hedrick
Linux Disk Certification Project Linux ATA Development

Linus Torvalds

author

2002-02-24 06:02 UTC #31 lore raw

Re: Flash Back -- kernel 2.1.111

Quoted 2 lines · Andre Hedrick

Lets both grow up!

I repeat, as I did in a private to-you-only email before: every _single_ complain you have had about the patches I've seen has been 100% bogus.

The patch was called "IDE cleanup", and cleanup it was. Nothing but. The timings didn't change, although the stupid (twice duplicated) functions that "calculated" them were removed and replaces with one boot-time calculation.

Martin not only had "cleanup" in the subject line, but actually explained all the changes, including the timing change. The comments at the top of the patch mail said (on that particular change, which seems to have been your favourite target), typos and all:

and the patch itself certainly agrees with what Martin claimed.

Your ranting, both on linux-kernel and on the IRC channels, has been totally bogus, as if you didn't read either the explanation _or_ the actual patch itself. And pointing this out multiple times doesn't seem to have made any difference.

Linus

Andre Hedrick

2002-02-24 09:40 UTC #32 lore raw

Re: Flash Back -- kernel 2.1.111

Linus,

I'm sure you have good reasons for feeling the way you do and beating up on me. I'm often misunderstood because of the way I phrase things. I have no hard feelings, just wish you and I could find a middle ground that worked again.

cheers,

--andre

Martin Dalecki

2002-02-24 12:29 UTC #33 lore raw

PATCH 1/1 IDE clean 12 3rd attempt

Since this apparently didn't get through to the mailing list I'm sending it again. This time compressed.
S'cuse me for the inconvenience.
The same notes as before apply:

This patch does the following:

1. Add some notes to Documentation/driver-model.txt about how and and where to mount the driverfs.

2. Reorganize and prepare the PCI scanning code for proper device dependant splitup. Basically tedious cleanup of macro games.

3. Use struct pci_dev name field as the name of PCI host dapaters instead of invention ambigious IDE special names. This makes the kernel bootup messages look a bit shifted, since those names are bit
longer, but makes up for consistance and should allow one later
to rearage things to fit into the generic PCI device initialization
mechanisms provided by the kernel.

4. Set 3. Allowed us to make the host chip specific pci_init_xxx class functions have the proper signature of module initializers. This will make it possible to make true modules out of them later.

5. Make some functions in cmd64x.c static which where not used elsewhere.

6. rename ide_special_settings to trust_pci_irq - this is reflecting it's functionality better. And make it match the pci device vendor as well as the device ID. It was a BUG to match only the device id!.

7. Make the chanell setup more tollerant for BIOS-es which don't report IO and MEM bases properly. The code found previously there tryed but was inconsistant.

8. Start to use proper terminology in ide-pci.c: host chip, channel, drive instead of hwif, port, drive...

9. Enlarge the name field from ide_hwif_t to 64 bytes. It was only 6 previously and there where custom names there which where exceeding this!!! But since we use the proper pci devce name there now instead, we had to extend the size of this field anyway.

10. Add some explanatory comments and fix misguiding comments here and there.

11. Kill the proc_ide_write_config and proc_ide_read_config brain damage! Those where backdoors to the pci configuration registers on PCI devices and IO registers on directly connected ISA ATA controllers. They didn't discrement between them!

Access to both of them *simply* doesn't belong into an operating system,
which is supposed to abstract out the access to hardware! Did I mention
that access to both can be done from user land without an IDE special interface! Any program which was using them (I hardly beleve there is one) just deserves to loose. The programmer responsible for it
deserves to be fired immediately.

12. Move ide_map_xx and ide_unmap_xx tinny bio level wrappers away from the "global" ide.h to where those are actually used and kill trivial wrappers for otherwise generic bio_ routines. Just fighting code obfuscation. The "rq->bio is used or is not there" brain damage in ide-taskfile.c has to be fixed later. Possibly by killing ide-taskfile.c alltogether, becouse this should be a driver for users and not a driver for ATA disk disaster recovery companys...

13. Kill hwif->pci_devid and hwif->pci_venid. Just use the already present hwif->pci_dev field instead.

14. Kill unused big switch ide_reinit_drive function. This silly functon was switching upon every possible device driver cathegory and calling the correspondng reinit function directly. This idiocy was fortunately not used.

That's all... Most will be clear if one starts looking at the changes in ide.h of course...

In contrast to the previous patches this one is actually fixing two serious bugs.

The next direct step will be to kill the sigle place global PCI device type recognition list from ide-pci.c by pushing the entries to where they belong -> the host chips setup modules.

Greg KH

2002-02-24 16:20 UTC #34 lore raw

Re: [PATCH] IDE clean 12 3rd attempt

Quoted 4 lines · Martin Dalecki

This patch does the following:
1. Add some notes to Documentation/driver-model.txt about how and and where to mount the driverfs.

This portion of the patch should be split out and submitted separately, to the author of the document, as it doesn't really have anything to do with the rest of the ide changes.

thanks,

greg k-h

Troy Benjegerdes

2002-02-24 22:38 UTC #35 lore raw

Re: Flash Back -- kernel 2.1.111

Quoted 11 lines · Paul Mackerras

Quoted 10 lines · Vojtech Pavlik
Quoted 8 lines · Paul Mackerras
Quoted 4 lines · Vojtech Pavlik
Quoted 1 line
83 MHz 55 MHz 41 MHz 0111 1101
This one is a problem, because 41*2 != 55. However, this is also illegal according to the PCI spec.
Where does the PCI spec say that is illegal?

Quoted 7 lines

Quoted 4 lines
Well, I'm assuming the 41 MHz clocked bus is not a 66-MHz type PCI bus (doesn't have the 66 MHz bit set and can't operate at 20.5 MHz if you plug in a card that can't do 66 MHz operation), rather it's an overclocked 33 MHz bus.
Yes, of course the 41MHz bus would have to conform to the rules for 66MHz buses. Does it, Troy?

I believe the bridge chip (64260) is capable of 66mhz operation on both busses, so it would follow the 66mhz operation rules. I'm not sure about this since it's not an immediate problem and I don't want to wade through 600pages of documentation to figure it out ;)

Signature · 5 lines

Troy Benjegerdes | master of mispeeling | 'da hozer' |  [email protected]
-----"If this message isn't misspelled, I didn't write it" -- Me -----
"Why do musicians compose symphonies and poets write poems? They do it
because life wouldn't have any meaning for them if they didn't. That's 
why I draw cartoons. It's my life." -- Charles Schulz

Martin Dalecki

2002-03-08 15:48 UTC #36 lore raw

PATCH 1/1 2.5.6 IDE 18

No fixes for new problems which occured since today, just syncup.

- Remove help text about suitable compiler versions, which is obsoleted by the overall kernel reality.

- Remove traces of not progressing work in progress code for the CONFIG_BLK_DEV_ADMA option as well as the empty ide-adma.c file as well as CONFIG_BLK_DEV_IDEDMA_TCQ.

- Remove redundant CONFIG_BLK_DEV_IDE != n check in ide/Config.in. Hugh, this is a tricky one...

- Add EXPORT_SYMBOL(ide_fops) again, since it's used in ide-cd.c add a note there that this is actually possibly adding the same device twice to the devfs stuff.

- Finally change the MAINTAINER entry. Just too many persons bogged me about it and it doesn't take me too much time apparently.

- Apply sis.patch.20020304_1.

- Don't call ide_release_dma twice in cleanup_ata, since ide_unregister is already calling it for us. Change prototype of ide_unregister to take a hwif as parameter and disable an ioctl for removing/scanning hwif from the list of handled interfaces. I see no reasons for having it and doing it is the fastest DOS attack on my home system I know about it. Contrary to the comments found here and there, hdparm doesn't use it. There are better hot plugging interfaces coming to the kernel right now anyway.

- Wrap invalidate_drives in ide_unregister under the ide_lock instead of disabling and enabling interrupts during this operation. There are plenty of other places where the IDE drivers are enabling and disabling interrupts just to protect some data structures.

- Don't call destroy_proc_ide_drives(hwif) for every single drive out there.This routine takes a hwif as a parameter.

- Resync with the instable 2.5.6...

MAINTAINERS +5 -7

diff -urN linux-2.5.6/MAINTAINERS linux/MAINTAINERS
@@ -709,14 +709,12 @@
 S:	Supported 
 
 IDE DRIVER [GENERAL]
-P:	Andre Hedrick
-M:	[email protected]
-M:	[email protected]
+P:	Martin Dalecki
+M:	[email protected]
+I:	pl_PL.ISO8859-2, de_DE.ISO8859-15, (en_US.ISO8859-1)
 L:	[email protected]
-W:	http://www.kernel.org/pub/linux/kernel/people/hedrick/
-W:	http://www.linux-ide.org/
-W:	http://www.linuxdiskcert.org/
-S:	Maintained
+W:	http://www.dalecki.de
+S:	Developement
 
 IDE/ATAPI CDROM DRIVER
 P:	Jens Axboe

arch/alpha/defconfig +0 -1

diff -urN linux-2.5.6/arch/alpha/defconfig linux/arch/alpha/defconfig
@@ -255,7 +255,6 @@
 # CONFIG_IDEDMA_PCI_WIP is not set
 # CONFIG_BLK_DEV_IDEDMA_TIMEOUT is not set
 # CONFIG_IDEDMA_NEW_DRIVE_LISTINGS is not set
-CONFIG_BLK_DEV_ADMA=y
 # CONFIG_BLK_DEV_AEC62XX is not set
 # CONFIG_AEC62XX_TUNING is not set
 CONFIG_BLK_DEV_ALI15X3=y

arch/arm/def-configs/iq80310 +0 -1

diff -urN linux-2.5.6/arch/arm/def-configs/iq80310 linux/arch/arm/def-configs/iq80310
@@ -454,7 +454,6 @@
 CONFIG_BLK_DEV_IDEPCI=y
 # CONFIG_IDEPCI_SHARE_IRQ is not set
 CONFIG_BLK_DEV_IDEDMA_PCI=y
-CONFIG_BLK_DEV_ADMA=y
 # CONFIG_BLK_DEV_OFFBOARD is not set
 CONFIG_IDEDMA_PCI_AUTO=y
 CONFIG_BLK_DEV_IDEDMA=y

arch/i386/defconfig +0 -1

diff -urN linux-2.5.6/arch/i386/defconfig linux/arch/i386/defconfig
@@ -258,7 +258,6 @@
 # CONFIG_IDEDMA_PCI_WIP is not set
 # CONFIG_BLK_DEV_IDEDMA_TIMEOUT is not set
 # CONFIG_IDEDMA_NEW_DRIVE_LISTINGS is not set
-CONFIG_BLK_DEV_ADMA=y
 # CONFIG_BLK_DEV_AEC62XX is not set
 # CONFIG_AEC62XX_TUNING is not set
 # CONFIG_BLK_DEV_ALI15X3 is not set

arch/ia64/defconfig +0 -1

diff -urN linux-2.5.6/arch/ia64/defconfig linux/arch/ia64/defconfig
@@ -207,7 +207,6 @@
 CONFIG_BLK_DEV_IDEPCI=y
 CONFIG_IDEPCI_SHARE_IRQ=y
 CONFIG_BLK_DEV_IDEDMA_PCI=y
-CONFIG_BLK_DEV_ADMA=y
 # CONFIG_BLK_DEV_OFFBOARD is not set
 # CONFIG_IDEDMA_PCI_AUTO is not set
 CONFIG_BLK_DEV_IDEDMA=y

arch/mips/defconfig-ddb5476 +0 -1

diff -urN linux-2.5.6/arch/mips/defconfig-ddb5476 linux/arch/mips/defconfig-ddb5476
@@ -224,7 +224,6 @@
 CONFIG_BLK_DEV_IDEPCI=y
 # CONFIG_IDEPCI_SHARE_IRQ is not set
 # CONFIG_BLK_DEV_IDEDMA_PCI is not set
-# CONFIG_BLK_DEV_ADMA is not set
 # CONFIG_BLK_DEV_OFFBOARD is not set
 # CONFIG_IDEDMA_PCI_AUTO is not set
 # CONFIG_BLK_DEV_IDEDMA is not set

arch/mips/defconfig-it8172 +0 -1

diff -urN linux-2.5.6/arch/mips/defconfig-it8172 linux/arch/mips/defconfig-it8172
@@ -289,7 +289,6 @@
 CONFIG_BLK_DEV_IDEPCI=y
 CONFIG_IDEPCI_SHARE_IRQ=y
 CONFIG_BLK_DEV_IDEDMA_PCI=y
-CONFIG_BLK_DEV_ADMA=y
 # CONFIG_BLK_DEV_OFFBOARD is not set
 CONFIG_IDEDMA_PCI_AUTO=y
 CONFIG_BLK_DEV_IDEDMA=y

arch/mips64/kernel/ioctl32.c +0 -2

diff -urN linux-2.5.6/arch/mips64/kernel/ioctl32.c linux/arch/mips64/kernel/ioctl32.c
@@ -750,9 +750,7 @@
 	IOCTL32_DEFAULT(HDIO_SET_NOWERR),
 	IOCTL32_DEFAULT(HDIO_SET_DMA),
 	IOCTL32_DEFAULT(HDIO_SET_PIO_MODE),
-	IOCTL32_DEFAULT(HDIO_SCAN_HWIF),
 	IOCTL32_DEFAULT(HDIO_SET_NICE),
-	//HDIO_UNREGISTER_HWIF
 
 	IOCTL32_DEFAULT(BLKROSET),			/* fs.h ioctls  */
 	IOCTL32_DEFAULT(BLKROGET),

arch/ppc/configs/common_defconfig +0 -1

diff -urN linux-2.5.6/arch/ppc/configs/common_defconfig linux/arch/ppc/configs/common_defconfig
@@ -252,7 +252,6 @@
 CONFIG_BLK_DEV_IDEPCI=y
 CONFIG_IDEPCI_SHARE_IRQ=y
 CONFIG_BLK_DEV_IDEDMA_PCI=y
-CONFIG_BLK_DEV_ADMA=y
 # CONFIG_BLK_DEV_OFFBOARD is not set
 CONFIG_IDEDMA_PCI_AUTO=y
 CONFIG_BLK_DEV_IDEDMA=y

arch/ppc/configs/k2_defconfig +0 -1

diff -urN linux-2.5.6/arch/ppc/configs/k2_defconfig linux/arch/ppc/configs/k2_defconfig
@@ -235,7 +235,6 @@
 CONFIG_BLK_DEV_IDEPCI=y
 CONFIG_IDEPCI_SHARE_IRQ=y
 CONFIG_BLK_DEV_IDEDMA_PCI=y
-CONFIG_BLK_DEV_ADMA=y
 # CONFIG_BLK_DEV_OFFBOARD is not set
 # CONFIG_IDEDMA_PCI_AUTO is not set
 CONFIG_BLK_DEV_IDEDMA=y

arch/ppc/configs/menf1_defconfig +0 -1

diff -urN linux-2.5.6/arch/ppc/configs/menf1_defconfig linux/arch/ppc/configs/menf1_defconfig
@@ -239,7 +239,6 @@
 CONFIG_BLK_DEV_IDEPCI=y
 # CONFIG_IDEPCI_SHARE_IRQ is not set
 # CONFIG_BLK_DEV_IDEDMA_PCI is not set
-# CONFIG_BLK_DEV_ADMA is not set
 # CONFIG_BLK_DEV_OFFBOARD is not set
 # CONFIG_IDEDMA_PCI_AUTO is not set
 # CONFIG_BLK_DEV_IDEDMA is not set

arch/ppc/configs/pmac_defconfig +0 -1

diff -urN linux-2.5.6/arch/ppc/configs/pmac_defconfig linux/arch/ppc/configs/pmac_defconfig
@@ -242,7 +242,6 @@
 CONFIG_BLK_DEV_IDEPCI=y
 CONFIG_IDEPCI_SHARE_IRQ=y
 CONFIG_BLK_DEV_IDEDMA_PCI=y
-CONFIG_BLK_DEV_ADMA=y
 # CONFIG_BLK_DEV_OFFBOARD is not set
 CONFIG_IDEDMA_PCI_AUTO=y
 CONFIG_BLK_DEV_IDEDMA=y

arch/ppc/configs/pplus_defconfig +0 -1

diff -urN linux-2.5.6/arch/ppc/configs/pplus_defconfig linux/arch/ppc/configs/pplus_defconfig
@@ -246,7 +246,6 @@
 CONFIG_BLK_DEV_IDEPCI=y
 CONFIG_IDEPCI_SHARE_IRQ=y
 CONFIG_BLK_DEV_IDEDMA_PCI=y
-CONFIG_BLK_DEV_ADMA=y
 # CONFIG_BLK_DEV_OFFBOARD is not set
 # CONFIG_IDEDMA_PCI_AUTO is not set
 CONFIG_BLK_DEV_IDEDMA=y

arch/ppc/configs/sandpoint_defconfig +0 -1

diff -urN linux-2.5.6/arch/ppc/configs/sandpoint_defconfig linux/arch/ppc/configs/sandpoint_defconfig
@@ -209,7 +209,6 @@
 CONFIG_BLK_DEV_IDEPCI=y
 CONFIG_IDEPCI_SHARE_IRQ=y
 CONFIG_BLK_DEV_IDEDMA_PCI=y
-CONFIG_BLK_DEV_ADMA=y
 # CONFIG_BLK_DEV_OFFBOARD is not set
 # CONFIG_IDEDMA_PCI_AUTO is not set
 CONFIG_BLK_DEV_IDEDMA=y

arch/ppc/defconfig +0 -1

diff -urN linux-2.5.6/arch/ppc/defconfig linux/arch/ppc/defconfig
@@ -252,7 +252,6 @@
 CONFIG_BLK_DEV_IDEPCI=y
 CONFIG_IDEPCI_SHARE_IRQ=y
 CONFIG_BLK_DEV_IDEDMA_PCI=y
-CONFIG_BLK_DEV_ADMA=y
 # CONFIG_BLK_DEV_OFFBOARD is not set
 CONFIG_IDEDMA_PCI_AUTO=y
 CONFIG_BLK_DEV_IDEDMA=y

arch/ppc64/kernel/ioctl32.c +0 -1

diff -urN linux-2.5.6/arch/ppc64/kernel/ioctl32.c linux/arch/ppc64/kernel/ioctl32.c
@@ -3713,7 +3713,6 @@
 COMPATIBLE_IOCTL(HDIO_SET_MULTCOUNT),
 COMPATIBLE_IOCTL(HDIO_DRIVE_CMD),
 COMPATIBLE_IOCTL(HDIO_SET_PIO_MODE),
-COMPATIBLE_IOCTL(HDIO_SCAN_HWIF),
 COMPATIBLE_IOCTL(HDIO_SET_NICE),
 /* 0x02 -- Floppy ioctls */
 COMPATIBLE_IOCTL(FDMSGON),

arch/sparc64/defconfig +0 -1

diff -urN linux-2.5.6/arch/sparc64/defconfig linux/arch/sparc64/defconfig
@@ -291,7 +291,6 @@
 # CONFIG_IDEDMA_PCI_WIP is not set
 # CONFIG_BLK_DEV_IDEDMA_TIMEOUT is not set
 # CONFIG_IDEDMA_NEW_DRIVE_LISTINGS is not set
-CONFIG_BLK_DEV_ADMA=y
 # CONFIG_BLK_DEV_AEC62XX is not set
 # CONFIG_AEC62XX_TUNING is not set
 CONFIG_BLK_DEV_ALI15X3=y

arch/sparc64/kernel/ioctl32.c +0 -1

diff -urN linux-2.5.6/arch/sparc64/kernel/ioctl32.c linux/arch/sparc64/kernel/ioctl32.c
@@ -3973,7 +3973,6 @@
 COMPATIBLE_IOCTL(HDIO_SET_MULTCOUNT)
 COMPATIBLE_IOCTL(HDIO_DRIVE_CMD)
 COMPATIBLE_IOCTL(HDIO_SET_PIO_MODE)
-COMPATIBLE_IOCTL(HDIO_SCAN_HWIF)
 COMPATIBLE_IOCTL(HDIO_SET_NICE)
 /* 0x02 -- Floppy ioctls */
 COMPATIBLE_IOCTL(FDMSGON)

arch/x86_64/ia32/ia32_ioctl.c +0 -1

diff -urN linux-2.5.6/arch/x86_64/ia32/ia32_ioctl.c linux/arch/x86_64/ia32/ia32_ioctl.c
@@ -3059,7 +3059,6 @@
 COMPATIBLE_IOCTL(HDIO_SET_MULTCOUNT)
 COMPATIBLE_IOCTL(HDIO_DRIVE_CMD)
 COMPATIBLE_IOCTL(HDIO_SET_PIO_MODE)
-COMPATIBLE_IOCTL(HDIO_SCAN_HWIF)
 COMPATIBLE_IOCTL(HDIO_SET_NICE)
 /* 0x02 -- Floppy ioctls */
 COMPATIBLE_IOCTL(FDMSGON)

drivers/ide/Config.help +9 ~~-11~~

diff -urN linux-2.5.6/drivers/ide/Config.help linux/drivers/ide/Config.help
@@ -251,10 +251,6 @@
   be (U)DMA capable but aren't. This is a blanket on/off test with no
   speed limit options.
 
-  Straight GNU GCC 2.7.3/2.8.X compilers are known to be safe;
-  whereas, many versions of EGCS have a problem and miscompile if you
-  say Y here.
-
   If in doubt, say N.
 
 CONFIG_BLK_DEV_IDEDMA_TIMEOUT

@@ -319,10 +315,6 @@
 
   It is SAFEST to say N to this question.
 
-CONFIG_BLK_DEV_ADMA
-  Please read the comments at the top of
-  <file:drivers/ide/ide-adma.c>.
-
 CONFIG_BLK_DEV_PDC_ADMA
   Please read the comments at the top of <file:drivers/ide/ide-pci.c>.

@@ -515,10 +507,16 @@
   For FastTrak enable overriding BIOS.
 
 CONFIG_BLK_DEV_SIS5513
-  This driver ensures (U)DMA support for SIS5513 chipset based
-  mainboards. SiS620/530 UDMA mode 4, SiS5600/5597 UDMA mode 2, all
-  other DMA mode 2 limited chipsets are unsupported to date.
+  This driver ensures (U)DMA support for SIS5513 chipset family based
+  mainboards.
 
+  The following chipsets are supported:
+  ATA16:  SiS5511, SiS5513
+  ATA33:  SiS5591, SiS5597, SiS5598, SiS5600
+  ATA66:  SiS530, SiS540, SiS620, SiS630, SiS640
+  ATA100: SiS635, SiS645, SiS650, SiS730, SiS735, SiS740,
+          SiS745, SiS750
+ 
   If you say Y here, you need to say Y to "Use DMA by default when
   available" as well.

drivers/ide/Config.in +106 ~~-113~~

246 lines not on this page · raw message

drivers/ide/Makefile +0 -1

diff -urN linux-2.5.6/drivers/ide/Makefile linux/drivers/ide/Makefile
@@ -44,7 +44,6 @@
 ide-obj-$(CONFIG_BLK_DEV_HPT366)	+= hpt366.o
 ide-obj-$(CONFIG_BLK_DEV_HT6560B)	+= ht6560b.o
 ide-obj-$(CONFIG_BLK_DEV_IDE_ICSIDE)	+= icside.o
-ide-obj-$(CONFIG_BLK_DEV_ADMA)		+= ide-adma.o
 ide-obj-$(CONFIG_BLK_DEV_IDEDMA_PCI)	+= ide-dma.o
 ide-obj-$(CONFIG_BLK_DEV_IDEPCI)	+= ide-pci.o
 ide-obj-$(CONFIG_BLK_DEV_ISAPNP)	+= ide-pnp.o

drivers/ide/ide-adma.c +0 -9

diff -urN linux-2.5.6/drivers/ide/ide-adma.c linux/drivers/ide/ide-adma.c
@@ -1,9 +0,0 @@
-/*
- *  linux/drivers/ide/ide-adma.c         Version 0.00	June 24, 2001
- *
- *  Copyright (c) 2001		Andre Hedrick <[email protected]>
- *
- *  Asynchronous DMA -- TBA, this is a holding file.
- *
- */
-

drivers/ide/ide-cd.c +5 -0

diff -urN linux-2.5.6/drivers/ide/ide-cd.c linux/drivers/ide/ide-cd.c
@@ -2508,6 +2508,11 @@
 	if (!CDROM_CONFIG_FLAGS (drive)->close_tray)
 		devinfo->mask |= CDC_CLOSE_TRAY;
 
+	/* FIXME: I'm less that sure that this is the proper thing to do, since
+	 * ware already adding the devices to devfs int ide.c upon device
+	 * registration.
+	 */
+
 	devinfo->de = devfs_register(drive->de, "cd", DEVFS_FL_DEFAULT,
 				     HWIF(drive)->major, minor,
 				     S_IFBLK | S_IRUGO | S_IWUGO,

drivers/ide/ide-cs.c +1 -1

diff -urN linux-2.5.6/drivers/ide/ide-cs.c linux/drivers/ide/ide-cs.c
@@ -401,7 +401,7 @@
     DEBUG(0, "ide_release(0x%p)\n", link);
 
     if (info->ndev) {
-	ide_unregister(info->hd);
+	ide_unregister(&ide_hwifs[info->hd]);
 	MOD_DEC_USE_COUNT;
     }

drivers/ide/ide-dma.c +6 -1

diff -urN linux-2.5.6/drivers/ide/ide-dma.c linux/drivers/ide/ide-dma.c
@@ -707,8 +707,11 @@
 /*
  * Needed for allowing full modular support of ide-driver
  */
-int ide_release_dma (ide_hwif_t *hwif)
+int ide_release_dma(ide_hwif_t *hwif)
 {
+	if (!hwif->dma_base)
+		return;
+
 	if (hwif->dmatable_cpu) {
 		pci_free_consistent(hwif->pci_dev,
 				    PRD_ENTRIES * PRD_BYTES,

@@ -723,6 +726,8 @@
 	if ((hwif->dma_extra) && (hwif->channel == 0))
 		release_region((hwif->dma_base + 16), hwif->dma_extra);
 	release_region(hwif->dma_base, 8);
+	hwif->dma_base = 0;
+
 	return 1;
 }

drivers/ide/ide-pci.c +19 ~~-27~~

97 lines not on this page · raw message

drivers/ide/ide-probe.c +7 -6

diff -urN linux-2.5.6/drivers/ide/ide-probe.c linux/drivers/ide/ide-probe.c
@@ -576,18 +576,19 @@
 {
 	request_queue_t *q = &drive->queue;
 	int max_sectors;
-#ifdef CONFIG_BLK_DEV_PDC4030
-	int is_pdc4030_chipset = (HWIF(drive)->chipset == ide_pdc4030);
-#else
-	const int is_pdc4030_chipset = 0;
-#endif
 
 	q->queuedata = HWGROUP(drive);
 	blk_init_queue(q, do_ide_request, &ide_lock);
 	blk_queue_segment_boundary(q, 0xffff);
 
 	/* IDE can do up to 128K per request, pdc4030 needs smaller limit */
-	max_sectors = (is_pdc4030_chipset ? 127 : 255);
+#ifdef CONFIG_BLK_DEV_PDC4030
+	if (HWIF(drive)->chipset == ide_pdc4030)
+		max_sectors = 127;
+	else
+#else
+		max_sectors = 255;
+#endif
 	blk_queue_max_sectors(q, max_sectors);
 
 	/* IDE DMA can do PRD_ENTRIES number of segments. */

drivers/ide/ide.c +41 ~~-60~~

251 lines not on this page · raw message

drivers/ide/sis5513.c +522 ~~-327~~

1,070 lines not on this page · raw message

include/linux/hdreg.h +0 ~~-15~~

diff -urN linux-2.5.6/include/linux/hdreg.h linux/include/linux/hdreg.h
@@ -368,9 +368,7 @@
 #define HDIO_SET_NOWERR		0x0325	/* change ignore-write-error flag */
 #define HDIO_SET_DMA		0x0326	/* change use-dma flag */
 #define HDIO_SET_PIO_MODE	0x0327	/* reconfig interface to new speed */
-#define HDIO_SCAN_HWIF		0x0328	/* register and (re)scan interface */
 #define HDIO_SET_NICE		0x0329	/* set nice flags */
-#define HDIO_UNREGISTER_HWIF	0x032a  /* unregister interface */
 #define HDIO_SET_WCACHE		0x032b	/* change write cache enable-disable */
 #define HDIO_SET_ACOUSTIC	0x032c	/* change acoustic behavior */
 #define HDIO_SET_BUSSTATE	0x032d	/* set the bus state of the hwif */

@@ -645,17 +643,4 @@
 #define IDE_NICE_1		(3)	/* when probably won't affect us much */
 #define IDE_NICE_2		(4)	/* when we know it's on our expense */
 
-#ifdef __KERNEL__
-/*
- * These routines are used for kernel command line parameters from main.c:
- */
-#include <linux/config.h>
-
-#if defined(CONFIG_BLK_DEV_IDE) || defined(CONFIG_BLK_DEV_IDE_MODULE)
-int ide_register(int io_port, int ctl_port, int irq);
-void ide_unregister(unsigned int);
-#endif /* CONFIG_BLK_DEV_IDE || CONFIG_BLK_DEV_IDE_MODULE */
-
-#endif  /* __KERNEL__ */
-
 #endif	/* _LINUX_HDREG_H */

include/linux/ide.h +3 -2

diff -urN linux-2.5.6/include/linux/ide.h linux/include/linux/ide.h
@@ -242,8 +242,7 @@
 /*
  * Register new hardware with ide
  */
-int ide_register_hw(hw_regs_t *hw, struct hwif_s **hwifp);
-
+extern int ide_register_hw(hw_regs_t *hw, struct hwif_s **hwifp);
 /*
  * Set up hw_regs_t structure before calling ide_register_hw (optional)
  */

@@ -506,6 +505,8 @@
 	struct device	device;		/* global device tree handle */
 } ide_hwif_t;
 
+extern void ide_unregister(ide_hwif_t *hwif);
+
 /*
  * Status returned from various ide_ functions
  */

Richard Gooch

2002-03-08 16:42 UTC #37 lore raw

Re: [PATCH] 2.5.6 IDE 18

Quoted 3 lines · Martin Dalecki

- Add EXPORT_SYMBOL(ide_fops) again, since it's used in ide-cd.c add a note there that this is actually possibly adding the same device twice to the devfs stuff.

If it is adding the same device twice, that's definately a bug. Duplicate devfs entries are not allowed.

				Regards,

					Richard....
Permanent: [email protected]
Current:   [email protected]

Martin Dalecki

2002-03-09 12:58 UTC #38 lore raw

Re: [PATCH] 2.5.6 IDE 18

Quoted 9 lines · Richard Gooch

Quoted 4 lines · Martin Dalecki
- Add EXPORT_SYMBOL(ide_fops) again, since it's used in ide-cd.c add a note there that this is actually possibly adding the same device twice to the devfs stuff.
If it is adding the same device twice, that's definately a bug. Duplicate devfs entries are not allowed.

Thank you for reafirmation. As noted in the code
I will re-check this again soon.

Troy Benjegerdes

2002-02-24 07:33 UTC #39 lore raw

Re: Flash Back -- kernel 2.1.111

Quoted 10 lines

Martin not only had "cleanup" in the subject line, but actually explained all the changes, including the timing change. The comments at the top of the patch mail said (on that particular change, which seems to have been your favourite target), typos and all:
3. Replace the functionally totally equal system_bus_block() and ide_system_bus_speed() functions with one simple global
variable: system_bus_speed. This saves quite a significatn amount of code. Unfortunately this is the part, which is makeing this patch to appear bigger then it really is...

Ummm, how does this work if I have two PCI ide cards, one on a 66mhz PCI bus, and one on a 33mhz PCI bus?

Or am I missing something?

Signature · 5 lines

Troy Benjegerdes | master of mispeeling | 'da hozer' |  [email protected]
-----"If this message isn't misspelled, I didn't write it" -- Me -----
"Why do musicians compose symphonies and poets write poems? They do it
because life wouldn't have any meaning for them if they didn't. That's 
why I draw cartoons. It's my life." -- Charles Schulz

Martin Dalecki

2002-02-24 12:19 UTC #40 lore raw

Re: Flash Back -- kernel 2.1.111

Quoted 3 lines

Ummm, how does this work if I have two PCI ide cards, one on a 66mhz PCI bus, and one on a 33mhz PCI bus?
Or am I missing something?

You are missing the fact that it didn't work before.

Troy Benjegerdes

2002-02-24 20:30 UTC #41 lore raw

Re: Flash Back -- kernel 2.1.111

Quoted 6 lines · Martin Dalecki

Quoted 4 lines
Ummm, how does this work if I have two PCI ide cards, one on a 66mhz PCI bus, and one on a 33mhz PCI bus?
Or am I missing something?
You are missing the fact that it didn't work before.

What hardware, chipsets, situations, etc did the previous code not work on?

There is no avoiding the fact you need some kind of per-IDE controller data for the clock for that particular PCI device.

I believe there are systems with 33mhz pci and 50mhz pci. Trying to find a 'common' base clock just seems to be an excercise in confusion. The only thing that really makes sense is 'how fast is said PCI device clocked'.

Signature · 5 lines

Troy Benjegerdes | master of mispeeling | 'da hozer' |  [email protected]
-----"If this message isn't misspelled, I didn't write it" -- Me -----
"Why do musicians compose symphonies and poets write poems? They do it
because life wouldn't have any meaning for them if they didn't. That's 
why I draw cartoons. It's my life." -- Charles Schulz

Martin Dalecki

2002-02-24 20:33 UTC #42 lore raw

Re: Flash Back -- kernel 2.1.111

Quoted 8 lines · Troy Benjegerdes

Quoted 5 lines
Quoted 4 lines
Ummm, how does this work if I have two PCI ide cards, one on a 66mhz PCI bus, and one on a 33mhz PCI bus?
Or am I missing something?
You are missing the fact that it didn't work before.
What hardware, chipsets, situations, etc did the previous code not work on?

The previous code didn't distinguish the bus speed between different busses and it doesn't do now as well.
It could be really helpfull to look at the patch actually. Don't you think?

Alan Cox

2002-02-24 21:02 UTC #43 lore raw

Re: Flash Back -- kernel 2.1.111

Quoted 4 lines

The previous code didn't distinguish the bus speed between different busses and it doesn't do now as well.
It could be really helpfull to look at the patch actually. Don't you think?

I know what would actually help here, (the other code wasn't broken IMHO) and would clean this up properly for not just IDE. Add a bus_speed field to the struct pci_bus - that is where the info belongs and its the platform specific bus code that can find the bus speed out (if anyone)

Alan

Martin Dalecki

2002-02-24 21:12 UTC #44 lore raw

Re: Flash Back -- kernel 2.1.111

Quoted 10 lines · Alan Cox

Quoted 5 lines
The previous code didn't distinguish the bus speed between different busses and it doesn't do now as well.
It could be really helpfull to look at the patch actually. Don't you think?
I know what would actually help here, (the other code wasn't broken IMHO) and would clean this up properly for not just IDE. Add a bus_speed field to the struct pci_bus - that is where the info belongs and its the platform specific bus code that can find the bus speed out (if anyone)

Alan you are of course right. But what to do about VLB and friends? Unfortunately there isn't something comparable to struct pci_bus for them in the kernel. (Or I'm missing something here?).
Iff then I would rather like to have a generic solution.

(Do you remmeber about 4 years ago there *was* already a lengthy discussion about bus speed detection, without any proper resolution at all...I remember myself having even provided some code for this purpose...which was basicually just measuring RAM transfer rates...)

Alan Cox

2002-02-24 21:18 UTC #45 lore raw

Re: Flash Back -- kernel 2.1.111

Quoted 4 lines

(Do you remmeber about 4 years ago there *was* already a lengthy discussion about bus speed detection, without any proper resolution at all...I remember myself having even provided some code for this purpose...which was basicually just measuring RAM transfer rates...)

I guess we register an isa and a vlb bus - anyone have two vlb busses ?

Martin Dalecki

2002-02-24 21:21 UTC #46 lore raw

Re: Flash Back -- kernel 2.1.111

Quoted 7 lines · Alan Cox

Quoted 5 lines
(Do you remmeber about 4 years ago there *was* already a lengthy discussion about bus speed detection, without any proper resolution at all...I remember myself having even provided some code for this purpose...which was basicually just measuring RAM transfer rates...)
I guess we register an isa and a vlb bus - anyone have two vlb busses ?

Two VLB busses... I couldn't hardly imagine this, since VLB was basically the 486 CPU - RAM interface exposed on a slot.

[email protected]

2002-02-24 21:27 UTC #47 lore raw

Re: Flash Back -- kernel 2.1.111

In reply to [email protected]

None of the chipsets that supported VLB had more than one buss. What I don't know is some idiot may have built a VLB-VLB bridge, but I doubt it.
Nick

Quoted 12 lines · Alan Cox

Quoted 4 lines
(Do you remmeber about 4 years ago there *was* already a lengthy discussion about bus speed detection, without any proper resolution at all...I remember myself having even provided some code for this purpose...which was basicually just measuring RAM transfer rates...)
I guess we register an isa and a vlb bus - anyone have two vlb busses ? -
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Rik van Riel

2002-02-24 21:33 UTC #48 lore raw

Re: Flash Back -- kernel 2.1.111

Quoted 3 lines · On Sun, 24 Feb 2002 [email protected] wrote:

None of the chipsets that supported VLB had more than one buss. What I don't know is some idiot may have built a VLB-VLB bridge, but I doubt it.

There are PCI-VLB bridges. Though it's unlikely, it may be possible that there are systems with multiple such bridges around... ;)

regards,

Rik

Signature · 4 lines

"Linux holds advantages over the single-vendor commercial OS"
    -- Microsoft's "Competing with Linux" document

http://www.surriel.com/		http://distro.conectiva.com/

Vojtech Pavlik

2002-02-24 21:43 UTC #49 lore raw

Re: Flash Back -- kernel 2.1.111

Quoted 9 lines · Rik van Riel

Quoted 3 lines · On Sun, 24 Feb 2002 [email protected] wrote:
None of the chipsets that supported VLB had more than one buss. What I don't know is some idiot may have built a VLB-VLB bridge, but I doubt it.
There are PCI-VLB bridges. Though it's unlikely, it may be possible that there are systems with multiple such bridges around... ;)

Uhh? I thought most the PCI & VLB systems had the PCI hanging off the VLB and not the other way around. At least those I've seen had it this way.

Signature · 2 lines

Vojtech Pavlik
SuSE Labs

[email protected]

2002-02-24 21:50 UTC #50 lore raw

Re: Flash Back -- kernel 2.1.111

That was my understanding as well. It woulnd't make terribly much sense to hang a VLB off a PCI bus, and I'd expect it to be very difficult.
Nick

Quoted 19 lines · Vojtech Pavlik

Quoted 9 lines · Rik van Riel
Quoted 3 lines · On Sun, 24 Feb 2002 [email protected] wrote:
None of the chipsets that supported VLB had more than one buss. What I don't know is some idiot may have built a VLB-VLB bridge, but I doubt it.
There are PCI-VLB bridges. Though it's unlikely, it may be possible that there are systems with multiple such bridges around... ;)
Uhh? I thought most the PCI & VLB systems had the PCI hanging off the VLB and not the other way around. At least those I've seen had it this way.
Signature · 2 lines
Vojtech Pavlik
SuSE Labs

Vojtech Pavlik

2002-02-24 21:42 UTC #51 lore raw

Re: Flash Back -- kernel 2.1.111

Quoted 6 lines · Alan Cox

Quoted 4 lines
(Do you remmeber about 4 years ago there *was* already a lengthy discussion about bus speed detection, without any proper resolution at all...I remember myself having even provided some code for this purpose...which was basicually just measuring RAM transfer rates...)
I guess we register an isa and a vlb bus - anyone have two vlb busses ?

I think having two VLBs is quite impossible - they were wired right to the CPU. Maybe in some early weird multiprocessor 486 or p5 machine?

Signature · 2 lines

Vojtech Pavlik
SuSE Labs

Rik van Riel

2002-02-24 21:48 UTC #52 lore raw

Re: Flash Back -- kernel 2.1.111

Quoted 2 lines · Vojtech Pavlik

I think having two VLBs is quite impossible - they were wired right to the CPU. Maybe in some early weird multiprocessor 486 or p5 machine?

I've had a 486 box with a PCI bus and a VLB bus behind a PCI-VLB bridge.

Rik

Signature · 4 lines

"Linux holds advantages over the single-vendor commercial OS"
    -- Microsoft's "Competing with Linux" document

http://www.surriel.com/		http://distro.conectiva.com/

Jeff Garzik

2002-02-24 21:31 UTC #53 lore raw

Re: Flash Back -- kernel 2.1.111

Quoted 4 lines · Alan Cox

I know what would actually help here, (the other code wasn't broken IMHO) and would clean this up properly for not just IDE. Add a bus_speed field to the struct pci_bus - that is where the info belongs and its the platform specific bus code that can find the bus speed out (if anyone)

agreed

Signature · 3 lines

Jeff Garzik      | "UNIX enhancements aren't."
Building 1024    |           -- says /usr/games/fortune
MandrakeSoft     |

David S. Miller

2002-02-24 22:22 UTC #54 lore raw

Re: Flash Back -- kernel 2.1.111

From: Alan Cox <[email protected]>
Date: Sun, 24 Feb 2002 21:15:06 +0000 (GMT)

its the platform specific bus code that can find the bus speed out (if anyone)

some platforms in fact already calculate it :-)

Vojtech Pavlik

2002-02-24 21:40 UTC #55 lore raw

Re: Flash Back -- kernel 2.1.111

Quoted 9 lines · Alan Cox

Quoted 4 lines
The previous code didn't distinguish the bus speed between different busses and it doesn't do now as well.
It could be really helpfull to look at the patch actually. Don't you think?
I know what would actually help here, (the other code wasn't broken IMHO) and would clean this up properly for not just IDE. Add a bus_speed field to the struct pci_bus - that is where the info belongs and its the platform specific bus code that can find the bus speed out (if anyone)

I have some experimental IDE based code which can detect the PCI bus speed by doing some IDE transfers and measuring the time it takes. It isn't 100% reliable, though. I haven't found any other way to detect PCI clock reliably, unfortunately it cannot be safely guessed from the CPU clock or FSB clock or anything.

Signature · 2 lines

Vojtech Pavlik
SuSE Labs

Jeff Garzik

2002-02-24 21:46 UTC #56 lore raw

Re: Flash Back -- kernel 2.1.111

Quoted 5 lines · Vojtech Pavlik

I have some experimental IDE based code which can detect the PCI bus speed by doing some IDE transfers and measuring the time it takes. It isn't 100% reliable, though. I haven't found any other way to detect PCI clock reliably, unfortunately it cannot be safely guessed from the CPU clock or FSB clock or anything.

Maybe your code cannot detect the "right answer" perfectly, but at least it could be useful as a sanity check, to let you know if the timings/bus speed are wildly off...

Jeff

Signature · 3 lines

Jeff Garzik      | "UNIX enhancements aren't."
Building 1024    |           -- says /usr/games/fortune
MandrakeSoft     |

Vojtech Pavlik

2002-02-24 21:50 UTC #57 lore raw

Re: Flash Back -- kernel 2.1.111

Quoted 9 lines · Jeff Garzik

Quoted 5 lines
I have some experimental IDE based code which can detect the PCI bus speed by doing some IDE transfers and measuring the time it takes. It isn't 100% reliable, though. I haven't found any other way to detect PCI clock reliably, unfortunately it cannot be safely guessed from the CPU clock or FSB clock or anything.
Maybe your code cannot detect the "right answer" perfectly, but at least it could be useful as a sanity check, to let you know if the timings/bus speed are wildly off...

Yes, but actually the bus speeds are never 'wildly off', the realistic values being somewhere between 25 to 41.5 MHz, and because all the new mainboards have the FSB tunable with a resolution of a single megahertz, almost all values in this range are posible. And even quite small changes make sometimes a huge difference (works or doesn't).

Signature · 2 lines

Vojtech Pavlik
SuSE Labs

Vojtech Pavlik

2002-02-24 20:52 UTC #58 lore raw

Re: Flash Back -- kernel 2.1.111

Quoted 6 lines · Martin Dalecki

Quoted 4 lines
Ummm, how does this work if I have two PCI ide cards, one on a 66mhz PCI bus, and one on a 33mhz PCI bus?
Or am I missing something?
You are missing the fact that it didn't work before.

Actually, no. The parameter is a 'base clock', it isn't related to the 66 MHz - if you set it to for example 25, the drivers will know that if you have a PCI 66 MHz bus, it's running only on 2*25 = 50 MHz. The multiplier is known from PCI config and isn't related to this parameter.

The parameter is also used for VLB, where it is more important, because VLB has no standard clock - it can run at 33, 40 or 50 MHz.

Let me also note here that the bus speed value here doesn't have the necessary precision to compute the IDE timings correctly for higher UDMA speeds, and that most drivers either assume 33 MHz PCI blindly or have a set of fixed values they know.

Signature · 2 lines

Vojtech Pavlik
SuSE Labs

Vojtech Pavlik

2002-02-24 20:54 UTC #59 lore raw

Re: Flash Back -- kernel 2.1.111

Quoted 6 lines · Troy Benjegerdes

Quoted 5 lines · Martin Dalecki
Quoted 4 lines
Ummm, how does this work if I have two PCI ide cards, one on a 66mhz PCI bus, and one on a 33mhz PCI bus?
Or am I missing something?

Quoted 7 lines

Quoted 1 line
You are missing the fact that it didn't work before.
What hardware, chipsets, situations, etc did the previous code not work on?
There is no avoiding the fact you need some kind of per-IDE controller data for the clock for that particular PCI device.

No. You don't need it. The base clock and multiplier are enough and you have the multiplier from PCI config.

Quoted 3 lines

I believe there are systems with 33mhz pci and 50mhz pci. Trying to find a 'common' base clock just seems to be an excercise in confusion. The only thing that really makes sense is 'how fast is said PCI device clocked'.

Show me one.

Signature · 2 lines

Vojtech Pavlik
SuSE Labs

Paul Mackerras

2002-02-24 22:05 UTC #60 lore raw

Re: Flash Back -- kernel 2.1.111

Quoted 6 lines · Vojtech Pavlik

Quoted 3 lines · Troy Benjegerdes
I believe there are systems with 33mhz pci and 50mhz pci. Trying to find a 'common' base clock just seems to be an excercise in confusion. The only thing that really makes sense is 'how fast is said PCI device clocked'.
Show me one.

We have some RS/6000 machines that have two separate PCI buses (two host bridges) that run at 33MHz and 50MHz respectively. Fortunately we also get a device tree from the firmware that tells us this.

Paul.

Alan Cox

2002-02-24 22:49 UTC #61 lore raw

Re: Flash Back -- kernel 2.1.111

Quoted 3 lines

We have some RS/6000 machines that have two separate PCI buses (two host bridges) that run at 33MHz and 50MHz respectively. Fortunately we also get a device tree from the firmware that tells us this.

Ok - thats another argument for stuffing it in the pci_bus struct

Troy Benjegerdes

2002-02-24 21:20 UTC #62 lore raw

Re: Flash Back -- kernel 2.1.111

Quoted 16 lines · Vojtech Pavlik

Quoted 6 lines · Troy Benjegerdes
Quoted 5 lines · Martin Dalecki
Quoted 4 lines
Ummm, how does this work if I have two PCI ide cards, one on a 66mhz PCI bus, and one on a 33mhz PCI bus?
Or am I missing something?
Quoted 7 lines
Quoted 1 line
You are missing the fact that it didn't work before.
What hardware, chipsets, situations, etc did the previous code not work on?
There is no avoiding the fact you need some kind of per-IDE controller data for the clock for that particular PCI device.

Quoted 8 lines

No. You don't need it. The base clock and multiplier are enough and you have the multiplier from PCI config.
Quoted 3 lines
I believe there are systems with 33mhz pci and 50mhz pci. Trying to find a 'common' base clock just seems to be an excercise in confusion. The only thing that really makes sense is 'how fast is said PCI device clocked'.
Show me one.

There is one on my desk, using a gt64260 PowerPC bridge chip. It's got dual PCI busses, and each can be clocked independently.

Table 2-6. System Clock Selection
CPU &

Memory Bus Fast/3V PCI     Slow/5V PCI 
Speed      Bus Speed       Bus Speed SW7 Settings
133 MHz    66 MHz          33 MHz    0100 0010 
100 MHz    66 MHz          33 MHz    1111 1010
100 MHz    33 MHz          33 MHz    1010 1000
83 MHz     55 MHz          41 MHz    0111 1101
66 MHz     66 MHz          33 MHz    0101 0101
66 MHz     33 MHz          33 MHz    0000 0001

These is just a partial list of potential clock rates.

Signature · 5 lines

Troy Benjegerdes | master of mispeeling | 'da hozer' |  [email protected]
-----"If this message isn't misspelled, I didn't write it" -- Me -----
"Why do musicians compose symphonies and poets write poems? They do it
because life wouldn't have any meaning for them if they didn't. That's 
why I draw cartoons. It's my life." -- Charles Schulz

Vojtech Pavlik

2002-02-24 21:38 UTC #63 lore raw

Re: Flash Back -- kernel 2.1.111

Quoted 31 lines · Troy Benjegerdes

Quoted 16 lines · Vojtech Pavlik
Quoted 6 lines · Troy Benjegerdes
Quoted 5 lines · Martin Dalecki
Quoted 4 lines
Ummm, how does this work if I have two PCI ide cards, one on a 66mhz PCI bus, and one on a 33mhz PCI bus?
Or am I missing something?
Quoted 7 lines
Quoted 1 line
You are missing the fact that it didn't work before.
What hardware, chipsets, situations, etc did the previous code not work on?
There is no avoiding the fact you need some kind of per-IDE controller data for the clock for that particular PCI device.
Quoted 8 lines
No. You don't need it. The base clock and multiplier are enough and you have the multiplier from PCI config.
Quoted 3 lines
I believe there are systems with 33mhz pci and 50mhz pci. Trying to find a 'common' base clock just seems to be an excercise in confusion. The only thing that really makes sense is 'how fast is said PCI device clocked'.
Show me one.
There is one on my desk, using a gt64260 PowerPC bridge chip. It's got dual PCI busses, and each can be clocked independently.
Table 2-6. System Clock Selection
CPU &

Quoted 7 lines

Memory Bus Fast/3V PCI     Slow/5V PCI 
Speed      Bus Speed       Bus Speed SW7 Settings
133 MHz    66 MHz          33 MHz    0100 0010 
100 MHz    66 MHz          33 MHz    1111 1010
100 MHz    33 MHz          33 MHz    1010 1000
66 MHz     66 MHz          33 MHz    0101 0101
66 MHz     33 MHz          33 MHz    0000 0001

All of these pose no problem, because we know if the PCI is running at double the nominal speed.

Quoted 1 line

83 MHz 55 MHz 41 MHz 0111 1101

This one is a problem, because 41*2 != 55. However, this is also illegal according to the PCI spec.

Quoted 1 line

These is just a partial list of potential clock rates.

But yes, you convinced me that we may want to keep the clock speed per bus (perhaps in the pci_bus struct ...), to be able to work with all the (maybe spec noncompliant, or just weird) hardware.

Thanks.

Signature · 2 lines

Vojtech Pavlik
SuSE Labs

Paul Mackerras

2002-02-24 22:05 UTC #64 lore raw

Re: Flash Back -- kernel 2.1.111

Quoted 4 lines · Vojtech Pavlik

Quoted 1 line
83 MHz 55 MHz 41 MHz 0111 1101
This one is a problem, because 41*2 != 55. However, this is also illegal according to the PCI spec.

Where does the PCI spec say that is illegal?

Paul.

Vojtech Pavlik

2002-02-24 22:10 UTC #65 lore raw

Re: Flash Back -- kernel 2.1.111

Quoted 8 lines · Paul Mackerras

Quoted 4 lines · Vojtech Pavlik
Quoted 1 line
83 MHz 55 MHz 41 MHz 0111 1101
This one is a problem, because 41*2 != 55. However, this is also illegal according to the PCI spec.
Where does the PCI spec say that is illegal?

Well, I'm assuming the 41 MHz clocked bus is not a 66-MHz type PCI bus (doesn't have the 66 MHz bit set and can't operate at 20.5 MHz if you plug in a card that can't do 66 MHz operation), rather it's an overclocked 33 MHz bus.

And running PCI over 33 MHz isn't legal in the PCI spec as far as I know. You can go lower, but I think the limit is 16 MHz there.

Signature · 2 lines

Vojtech Pavlik
SuSE Labs

Paul Mackerras

2002-02-24 22:27 UTC #66 lore raw

Re: Flash Back -- kernel 2.1.111

Quoted 8 lines · Vojtech Pavlik

Quoted 7 lines · Paul Mackerras
Quoted 4 lines · Vojtech Pavlik
Quoted 1 line
83 MHz 55 MHz 41 MHz 0111 1101
This one is a problem, because 41*2 != 55. However, this is also illegal according to the PCI spec.

Quoted 6 lines

Quoted 1 line
Where does the PCI spec say that is illegal?
Well, I'm assuming the 41 MHz clocked bus is not a 66-MHz type PCI bus (doesn't have the 66 MHz bit set and can't operate at 20.5 MHz if you plug in a card that can't do 66 MHz operation), rather it's an overclocked 33 MHz bus.

Yes, of course the 41MHz bus would have to conform to the rules for 66MHz buses. Does it, Troy?

Paul.

Vojtech Pavlik

2002-02-24 22:12 UTC #67 lore raw

Re: Flash Back -- kernel 2.1.111

In reply to Paul Mackerras

Quoted 7 lines · Paul Mackerras

Quoted 5 lines · Vojtech Pavlik
Quoted 3 lines · Troy Benjegerdes
I believe there are systems with 33mhz pci and 50mhz pci. Trying to find a 'common' base clock just seems to be an excercise in confusion. The only thing that really makes sense is 'how fast is said PCI device clocked'.

Quoted 5 lines

Quoted 1 line
Show me one.
We have some RS/6000 machines that have two separate PCI buses (two host bridges) that run at 33MHz and 50MHz respectively. Fortunately we also get a device tree from the firmware that tells us this.

I really wonder why the 50 MHz one doesn't run at 66 MHz, and what happens if you plug in a 66MHz non-capable card to the 50 MHz bus.

Signature · 2 lines

Vojtech Pavlik
SuSE Labs

Paul Mackerras

2002-02-24 22:27 UTC #68 lore raw

Re: Flash Back -- kernel 2.1.111

Quoted 6 lines · Vojtech Pavlik

Quoted 3 lines · Paul Mackerras
We have some RS/6000 machines that have two separate PCI buses (two host bridges) that run at 33MHz and 50MHz respectively. Fortunately we also get a device tree from the firmware that tells us this.
I really wonder why the 50 MHz one doesn't run at 66 MHz, and what

Apparently the rationale is that you can put more slots on the bus if you run it at 50MHz than you can at 66MHz.

Quoted 1 line

happens if you plug in a 66MHz non-capable card to the 50 MHz bus.

The bus speed drops to 33MHz.

Paul.

Andre Hedrick

2002-02-24 22:41 UTC #69 lore raw

Re: Flash Back -- kernel 2.1.111

Obviously this will be a sticking point on the baseclock assumed for each host; however, the excitement of the commentary tends to validate the concerns express, but poor word choice.

Given the baseclock is used to setup PIO, and that is the method to issue and execute the command block, and all other transfers which are not DMA, it stands to reason, if this becomes messed up so will the transfers.

So my comments in concerns are valid given each host is different and those capable of determining there internal baseclock which may vary from the actual PCI slot baseclock, FSB, etc ... will be okay. The rest of those which depend on user input of a default safe value which has been defined in the past and verified by history must remain.

In the past we carried a global since driverfs was not present.

As a point of reference for removal of the pci read/write space to the host, I strongly suggest that be left alone. As for the removal of the settings file, may of the distributions use this as a means to issue script calls to enable and disable features w/o the use of an additional application like "hdparm".

Regards,

Andre Hedrick
Linux Disk Certification Project Linux ATA Development

Martin Dalecki

2002-02-25 08:50 UTC #70 lore raw

Re: Flash Back -- kernel 2.1.111

Quoted 6 lines

As a point of reference for removal of the pci read/write space to the host, I strongly suggest that be left alone. As for the removal of the settings file, may of the distributions use this as a means to issue script calls to enable and disable features w/o the use of an additional application like "hdparm".

You are sure the distros write to the PCI config space of the host chip device or the IO registers at boot time????!!! In esp. since the abolition in case did only just get introduced at 2.4.xx times???

Just show me one please!

Vojtech Pavlik

2002-02-24 22:48 UTC #71 lore raw

Re: Flash Back -- kernel 2.1.111

Quoted 9 lines · Andre Hedrick

Obviously this will be a sticking point on the baseclock assumed for each host; however, the excitement of the commentary tends to validate the concerns express, but poor word choice.
Given the baseclock is used to setup PIO, and that is the method to issue and execute the command block, and all other transfers which are not DMA, it stands to reason, if this becomes messed up so will the transfers.

Quoted 5 lines

So my comments in concerns are valid given each host is different and those capable of determining there internal baseclock which may vary from the actual PCI slot baseclock, FSB, etc ... will be okay. The rest of those which depend on user input of a default safe value which has been defined in the past and verified by history must remain.

And so they stay, if you read the patch. It doesn't change any functionality, really, just the implementation.

Quoted 1 line

In the past we carried a global since driverfs was not present.

I don't think driverfs will change this much.

Quoted 2 lines

As a point of reference for removal of the pci read/write space to the host, I strongly suggest that be left alone.

Why? Please name at least one good reason.

Quoted 4 lines

As for the removal of the
settings file, may of the distributions use this as a means to issue script calls to enable and disable features w/o the use of an additional application like "hdparm".

I don't remember this being removed, but my memory may be wrong here.

Signature · 2 lines

Vojtech Pavlik
SuSE Labs

Vojtech Pavlik

2002-02-24 22:51 UTC #72 lore raw

Re: Flash Back -- kernel 2.1.111

Quoted 11 lines · David S. Miller

From: Vojtech Pavlik <[email protected]>
Date: Sun, 24 Feb 2002 23:39:37 +0100
Quoted 3 lines
Quoted 1 line
happens if you plug in a 66MHz non-capable card to the 50 MHz bus.
The bus speed drops to 33MHz.
Interesting. I'd expect 25 myself ... then we'll definitely need two clock values in struct pci_bus - because the hi-speed one isn't always a double the low one - as shown by your example.

Quoted 6 lines

You only need one, the current active one.
If you think that hot-plug is an issue, the arch dependant could would need to recalculate the "current bus speed" and all would be fine.
So why do we need two values?

Oh, you're right. We indeed need only one.

Hmm, now hotplug changing the PCI clock would be quite a lot of fun - all running drivers will need to know about the change, because some may need to recompute the timings they have programmed into the chips ...

Because virtually disconnecting and reconnecting all the cards for which the timings have changed will probably not be an option.

Signature · 2 lines

Vojtech Pavlik
SuSE Labs

Troy Benjegerdes

2002-02-24 23:00 UTC #73 lore raw

Re: Flash Back -- kernel 2.1.111

Quoted 20 lines · Vojtech Pavlik

Quoted 11 lines · David S. Miller
From: Vojtech Pavlik <[email protected]>
Date: Sun, 24 Feb 2002 23:39:37 +0100
Quoted 3 lines
Quoted 1 line
happens if you plug in a 66MHz non-capable card to the 50 MHz bus.
The bus speed drops to 33MHz.
Interesting. I'd expect 25 myself ... then we'll definitely need two clock values in struct pci_bus - because the hi-speed one isn't always a double the low one - as shown by your example.
Quoted 6 lines
You only need one, the current active one.
If you think that hot-plug is an issue, the arch dependant could would need to recalculate the "current bus speed" and all would be fine.
So why do we need two values?

Quoted 8 lines

Oh, you're right. We indeed need only one.
Hmm, now hotplug changing the PCI clock would be quite a lot of fun - all running drivers will need to know about the change, because some may need to recompute the timings they have programmed into the chips ...
Because virtually disconnecting and reconnecting all the cards for which the timings have changed will probably not be an option.

Personally, I think hot-plugging a 33mhz pci device into a 66mhz pci bus with other active devices on it is either user error or designer error (should have had a bridge), and a 'virtual disconnect and reconnect' is reasonable.

You're going to kill (or at least stop) any transactions going on on the bus while you're physically hot-plugging anway..

Signature · 5 lines

Troy Benjegerdes | master of mispeeling | 'da hozer' |  [email protected]
-----"If this message isn't misspelled, I didn't write it" -- Me -----
"Why do musicians compose symphonies and poets write poems? They do it
because life wouldn't have any meaning for them if they didn't. That's 
why I draw cartoons. It's my life." -- Charles Schulz

Vojtech Pavlik

2002-02-24 23:03 UTC #74 lore raw

Re: Flash Back -- kernel 2.1.111

Quoted 30 lines · Troy Benjegerdes

Quoted 20 lines · Vojtech Pavlik
Quoted 11 lines · David S. Miller
From: Vojtech Pavlik <[email protected]>
Date: Sun, 24 Feb 2002 23:39:37 +0100
Quoted 3 lines
Quoted 1 line
happens if you plug in a 66MHz non-capable card to the 50 MHz bus.
The bus speed drops to 33MHz.
Interesting. I'd expect 25 myself ... then we'll definitely need two clock values in struct pci_bus - because the hi-speed one isn't always a double the low one - as shown by your example.
Quoted 6 lines
You only need one, the current active one.
If you think that hot-plug is an issue, the arch dependant could would need to recalculate the "current bus speed" and all would be fine.
So why do we need two values?
Quoted 8 lines
Oh, you're right. We indeed need only one.
Hmm, now hotplug changing the PCI clock would be quite a lot of fun - all running drivers will need to know about the change, because some may need to recompute the timings they have programmed into the chips ...
Because virtually disconnecting and reconnecting all the cards for which the timings have changed will probably not be an option.

Quoted 7 lines

Personally, I think hot-plugging a 33mhz pci device into a 66mhz pci bus with other active devices on it is either user error or designer error (should have had a bridge), and a 'virtual disconnect and reconnect' is reasonable.
You're going to kill (or at least stop) any transactions going on on the bus while you're physically hot-plugging anway..

I'd guess most hotpluggable PCIs will have a bridge per slot ... hopefully.

Signature · 2 lines

Vojtech Pavlik
SuSE Labs

Paul Mackerras

2002-02-24 23:29 UTC #75 lore raw

Re: Flash Back -- kernel 2.1.111

Quoted 2 lines · Vojtech Pavlik

I'd guess most hotpluggable PCIs will have a bridge per slot ... hopefully.

That is certainly the case on all the IBM pSeries (RS/6000) machines with hot-plug PCI that I know of.

Paul.

Remco Post

2002-02-27 15:59 UTC #76 lore raw

Re: Flash Back -- kernel 2.1.111

Quoted 9 lines

Quoted 2 lines · Vojtech Pavlik
I'd guess most hotpluggable PCIs will have a bridge per slot ... hopefully.
That is certainly the case on all the IBM pSeries (RS/6000) machines with hot-plug PCI that I know of.
Paul.

IIRC this is not true on the p690, but then again, who has a p690 running linux ;)

Signature · 10 lines

Met vriendelijke groeten,

Remco Post

SARA - Stichting Academisch Rekencentrum Amsterdam
High Performance Computing  Tel. +31 20 592 8008    Fax. +31 20 668 3167

"I really didn't foresee the Internet. But then, neither did the computer
industry. Not that that tells us very much of course - the computer industry
didn't even foresee that the century was going to end." -- Douglas Adams

Vojtech Pavlik

2002-02-24 22:40 UTC #77 lore raw

Re: Flash Back -- kernel 2.1.111

Quoted 10 lines · Paul Mackerras

Quoted 6 lines · Vojtech Pavlik
Quoted 3 lines · Paul Mackerras
We have some RS/6000 machines that have two separate PCI buses (two host bridges) that run at 33MHz and 50MHz respectively. Fortunately we also get a device tree from the firmware that tells us this.
I really wonder why the 50 MHz one doesn't run at 66 MHz, and what
Apparently the rationale is that you can put more slots on the bus if you run it at 50MHz than you can at 66MHz.

I see. That makes sense.

Quoted 3 lines

Quoted 1 line
happens if you plug in a 66MHz non-capable card to the 50 MHz bus.
The bus speed drops to 33MHz.

Interesting. I'd expect 25 myself ... then we'll definitely need two clock values in struct pci_bus - because the hi-speed one isn't always a double the low one - as shown by your example.

Signature · 2 lines

Vojtech Pavlik
SuSE Labs

David S. Miller

2002-02-24 22:47 UTC #78 lore raw

Re: Flash Back -- kernel 2.1.111

From: Vojtech Pavlik <[email protected]>
Date: Sun, 24 Feb 2002 23:39:37 +0100

Quoted 3 lines

Quoted 1 line
happens if you plug in a 66MHz non-capable card to the 50 MHz bus.
The bus speed drops to 33MHz.

Interesting. I'd expect 25 myself ... then we'll definitely need two clock values in struct pci_bus - because the hi-speed one isn't always a double the low one - as shown by your example.

You only need one, the current active one.

If you think that hot-plug is an issue, the arch dependant could would need to recalculate the "current bus speed" and all would be fine.

So why do we need two values?

Chris Wedgwood

2002-02-24 23:04 UTC #79 lore raw

Re: Flash Back -- kernel 2.1.111

On Sun, Feb 24, 2002 at 01:30:38AM -0600, Troy Benjegerdes wrote:

Ummm, how does this work if I have two PCI ide cards, one on a 66mhz PCI bus, and one on a 33mhz PCI bus?

The PCI bus speed will be the greatest that all cards on that bus can support (33Mhz). To get 66Mhz PCI cards working at 66Mhz, all cards on that bus must be 66Mhz.

--cw

Chris Wedgwood

2002-02-24 23:09 UTC #80 lore raw

Re: Flash Back -- kernel 2.1.111

On Sun, Feb 24, 2002 at 11:08:55PM +0100, Vojtech Pavlik wrote:

And running PCI over 33 MHz isn't legal in the PCI spec as far as I know. You can go lower, but I think the limit is 16 MHz there.

_ALL_ PCI 2.x cards must work at at least 33 Mhz, some way work higher. _ALL_ must work lower speeds too (for example a power saving measures might be dropping the PCI bus speed).

--cw

Chris Wedgwood

2002-02-24 23:10 UTC #81 lore raw

Re: Flash Back -- kernel 2.1.111

On Sun, Feb 24, 2002 at 11:10:02PM +0100, Vojtech Pavlik wrote:

I really wonder why the 50 MHz one doesn't run at 66 MHz, and what happens if you plug in a 66MHz non-capable card to the 50 MHz bus.

The bus is supposed to go as fast as the slowest card --- no faster. In this case I assume the bridge will drop the speed? Paul?

--cw

Chris Wedgwood

2002-02-24 23:13 UTC #82 lore raw

Re: Flash Back -- kernel 2.1.111

On Sun, Feb 24, 2002 at 11:39:37PM +0100, Vojtech Pavlik wrote:

Interesting. I'd expect 25 myself ... then we'll definitely need two clock values in struct pci_bus - because the hi-speed one isn't always a double the low one - as shown by your example.

No; all devices on the same bus run at the same speed ... for per device (well, per bus) we need a speed.

Actually, strictly speaking drivers should be able to handle the speed changing at runtime too --- I'm not sure if anything does this right now but it is permissible.

--cw

Martin Dalecki

2002-02-24 12:15 UTC #83 lore raw

Re: Flash Back -- kernel 2.1.111

Quoted 4 lines · Andre Hedrick

Here I question the taking of a patch 12 which altered the behavior of the subsystem baseclock to setting up PIO timings for the executing command block operations. I then looked over the patch again and saw you had not taken it yet.

This is a lie. It doesn't alter the system base clock.

Vojtech Pavlik

2002-02-24 10:24 UTC #84 lore raw

Re: Flash Back -- kernel 2.1.111

Quoted 15 lines · Andre Hedrick

Quoted 4 lines
What really bugs me about this is that while normally you're hard to communicate with, this time you have actively _lied_ about the patches on IRC and in email about how they will cause IDE corruption etc due to timing changes.
Before I truley reply to this statement above, would you like to recant it?
Quoted 2 lines
No such timing changes existed, and whenever you were asked about what was actually actively _wrong_ with the patches, you didn't reply.
Here I question the taking of a patch 12 which altered the behavior of the subsystem baseclock to setting up PIO timings for the executing command block operations. I then looked over the patch again and saw you had not taken it yet.

Quoted 5 lines

In that private email, I clearly stated I made a mistake in reading what was accepted into 2.5.5. The fact is you had not accepted it yet. However I expect you will take it. Given that very few people in the world have most of the hardware that was effected by that change, and even less have the NDA documents on the rules, please accept the change.

Maybe then you'll want to point out how patch #12 can change any PIO timings? I'm definitely curious ... that'd affect my VIA driver as well, you know ...

Signature · 2 lines

Vojtech Pavlik
SuSE Labs

Martin Dalecki

2002-03-11 12:42 UTC #85 lore raw

PATCH 1/1 2.5.6 IDE 19

- Fix oversight in replacement of sti() cli() pairs for data structure access protection. This finally resolvs my problems with the 2.5.6 kernel
series.
Now I'm in fact quite puzzled how it was even possible for the system
to get
into the init stage without this fix..

- Fix usage of CONFIG_BLK_DEV_IDE_MODULES instead of CONFIG_BLK_DEV_IDE_MODULE.

- Make idescsi_init global for usage in systems without module support enabled.

- Apply Pavels Macheks patch for suspend support. Whatever some persons argue that it's not fully implemented, I think that we are in development
series
right now. I don't buy the mock-up examples for problems with either outdated or broken hardware. Micro Drives are for example expected to
be drop
in replacements for CF cards in digital cameras and I would rather expect them to be very tolerant about the driver in front of them. And then
the WB
caches of IDE devices are not caches in the sense of a MESI cache,
they are
more like buffer caches and should therefore flush them self after s
short
period of inactivity without the application of any special flush
command.
The upcomming explicit flushing commands in the ATA standard are
about data
integrity guarantees in high reliability systems, like DB servers for
example,
and not about simple cache validity.

- Apply Vojtech Pavliks fix to the VIA host chip initialization code.

- Add missing if-defs around PIO timing tables.

- Fix max() min() related compile warnings in IDE-scsi.

OK thin on top of patch 18 this is actually useful.

drivers/ide/ide-disk.c +27 -1

diff -urN linux-2.5.6/drivers/ide/ide-disk.c linux/drivers/ide/ide-disk.c
@@ -117,6 +117,8 @@
  */
 static ide_startstop_t do_rw_disk (ide_drive_t *drive, struct request *rq, unsigned long block)
 {
+	if (drive->blocked)
+		panic("ide: Request while drive blocked? You don't like your data intact?");
 	if (!(rq->flags & REQ_CMD)) {
 		blk_dump_rq_flags(rq, "do_rw_disk, bad command");
 		ide_end_request(drive, 0);

@@ -903,13 +905,36 @@
 	ide_add_setting(drive,	"max_failures",		SETTING_RW,					-1,			-1,			TYPE_INT,	0,	65535,				1,	1,	&drive->max_failures,		NULL);
 }
 
+static int idedisk_suspend(struct device *dev, u32 state, u32 level)
+{
+	int i;
+	ide_drive_t *drive = dev->driver_data;
+
+	printk("ide_disk_suspend()\n");
+	while (HWGROUP(drive)->handler)
+		schedule();
+	drive->blocked = 1;
+}
+
+static int idedisk_resume(struct device *dev, u32 level)
+{
+	ide_drive_t *drive = dev->driver_data;
+	if (!drive->blocked)
+		panic("ide: Resume but not suspended?\n");
+	drive->blocked = 0;
+}
+
+
 /* This is just a hook for the overall driver tree.
  *
  * FIXME: This is soon goig to replace the custom linked list games played up
  * to great extend between the different components of the IDE drivers.
  */
 
-static struct device_driver idedisk_devdrv = {};
+static struct device_driver idedisk_devdrv = {
+	suspend: idedisk_suspend,
+	resume: idedisk_resume,
+};
 
 static void idedisk_setup(ide_drive_t *drive)
 {

@@ -956,6 +981,7 @@
 	    sprintf(drive->device.name, "ide-disk");
 	    drive->device.driver = &idedisk_devdrv;
 	    drive->device.parent = &HWIF(drive)->device;
+	    drive->device.driver_data = drive;
 	    device_register(&drive->device);
 	}

drivers/ide/ide-pci.c +12 -4

diff -urN linux-2.5.6/drivers/ide/ide-pci.c linux/drivers/ide/ide-pci.c
@@ -35,6 +35,7 @@
  */
 
 #define	ATA_PCI_IGNORE	((void *)-1)
+#define IDE_NO_DRIVER	((void *)-2)
 
 #ifdef CONFIG_BLK_DEV_AEC62XX
 extern unsigned int pci_init_aec62xx(struct pci_dev *);

@@ -313,7 +314,7 @@
 	{PCI_VENDOR_ID_UMC, PCI_DEVICE_ID_UMC_UM8886A, NULL, NULL, NULL, NULL, {{0x00,0x00,0x00}, {0x00,0x00,0x00}}, ON_BOARD, 0, ATA_F_FIXIRQ },
 	{PCI_VENDOR_ID_UMC, PCI_DEVICE_ID_UMC_UM8886BF, NULL, NULL, NULL, NULL, {{0x00,0x00,0x00}, {0x00,0x00,0x00}}, ON_BOARD, 0, ATA_F_FIXIRQ },
 	{PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C561, NULL, NULL, NULL, NULL, {{0x00,0x00,0x00}, {0x00,0x00,0x00}}, ON_BOARD, 0, ATA_F_NOADMA },
-	{PCI_VENDOR_ID_TTI, PCI_DEVICE_ID_TTI_HPT366, NULL, NULL, NULL, NULL, {{0x00,0x00,0x00}, {0x00,0x00,0x00}}, OFF_BOARD, 240, ATA_F_IRQ | ATA_F_HPTHACK },
+	{PCI_VENDOR_ID_TTI, PCI_DEVICE_ID_TTI_HPT366, NULL, NULL, IDE_NO_DRIVER, NULL, {{0x00,0x00,0x00}, {0x00,0x00,0x00}}, OFF_BOARD, 240, ATA_F_IRQ | ATA_F_HPTHACK },
 	{0, 0, NULL, NULL, NULL, NULL, {{0x00,0x00,0x00}, {0x00,0x00,0x00}}, ON_BOARD, 0 }};
 
 /*

@@ -682,6 +683,11 @@
 		autodma = 1;
 #endif
 
+	if (d->init_hwif == IDE_NO_DRIVER) {
+		printk(KERN_WARNING "%s: detected chipset, but driver not compiled in!\n", dev->name);
+		d->init_hwif = NULL;
+	}
+
 	if (pci_enable_device(dev)) {
 		printk(KERN_WARNING "%s: Could not enable PCI device.\n", dev->name);
 		return;

@@ -916,15 +922,17 @@
 	}
 }
 
-void __init ide_scan_pcibus (int scan_direction)
+void __init ide_scan_pcibus(int scan_direction)
 {
 	struct pci_dev *dev;
 
 	if (!scan_direction) {
-		pci_for_each_dev(dev)
+		pci_for_each_dev(dev) {
 			scan_pcidev(dev);
+		}
 	} else {
-		pci_for_each_dev_reverse(dev)
+		pci_for_each_dev_reverse(dev) {
 			scan_pcidev(dev);
+		}
 	}
 }

drivers/ide/ide-probe.c +1 -4

diff -urN linux-2.5.6/drivers/ide/ide-probe.c linux/drivers/ide/ide-probe.c
@@ -575,7 +575,7 @@
 static void ide_init_queue(ide_drive_t *drive)
 {
 	request_queue_t *q = &drive->queue;
-	int max_sectors;
+	int max_sectors = 255;
 
 	q->queuedata = HWGROUP(drive);
 	blk_init_queue(q, do_ide_request, &ide_lock);

@@ -585,9 +585,6 @@
 #ifdef CONFIG_BLK_DEV_PDC4030
 	if (HWIF(drive)->chipset == ide_pdc4030)
 		max_sectors = 127;
-	else
-#else
-		max_sectors = 255;
 #endif
 	blk_queue_max_sectors(q, max_sectors);

drivers/ide/ide.c +20 ~~-19~~

diff -urN linux-2.5.6/drivers/ide/ide.c linux/drivers/ide/ide.c
@@ -194,6 +194,7 @@
 extern void pnpide_init(int);
 #endif
 
+#ifdef CONFIG_BLK_DEV_IDE_MODES
 /*
  * Constant tables for PIO mode programming:
  */

@@ -282,6 +283,7 @@
         { "QUANTUM FIREBALL_1280", 3 },
 	{ NULL,	0 }
 };
+#endif
 
 /* default maximum number of failures */
 #define IDE_DEFAULT_MAX_FAILURES	1

@@ -314,7 +316,7 @@
  */
 ide_hwif_t ide_hwifs[MAX_HWIFS];	/* master data repository */
 
-
+#ifdef CONFIG_BLK_DEV_IDE_MODES
 /*
  * This routine searches the ide_pio_blacklist for an entry
  * matching the start/whole of the supplied model name.

@@ -332,6 +334,7 @@
 	}
 	return -1;
 }
+#endif
 
 /*
  * This routine returns the recommended PIO settings for a given drive,

@@ -445,7 +448,7 @@
 /*
  * Do not even *think* about calling this!
  */
-static void init_hwif_data(ide_hwif_t *hwif, int index)
+static void init_hwif_data(ide_hwif_t *hwif, unsigned int index)
 {
 	static const byte ide_major[] = {
 		IDE0_MAJOR, IDE1_MAJOR, IDE2_MAJOR, IDE3_MAJOR, IDE4_MAJOR,

@@ -1866,7 +1869,7 @@
  * get_info_ptr() returns the (ide_drive_t *) for a given device number.
  * It returns NULL if the given device number does not match any present drives.
  */
-ide_drive_t *get_info_ptr (kdev_t i_rdev)
+ide_drive_t *get_info_ptr(kdev_t i_rdev)
 {
 	unsigned int major = major(i_rdev);
 	int h;

@@ -2174,8 +2177,7 @@
 	unsigned int p, minor;
 	ide_hwif_t old_hwif;
 
-	save_flags(flags);	/* all CPUs */
-	cli();			/* all CPUs */
+	spin_lock_irqsave(&ide_lock, flags);
 	if (!hwif->present)
 		goto abort;
 	put_device(&hwif->device);

@@ -2198,7 +2200,7 @@
 	/*
 	 * All clear?  Then blow away the buffer cache
 	 */
-	spin_lock_irqsave(&ide_lock, flags);
+	spin_unlock_irqrestore(&ide_lock, flags);
 	for (unit = 0; unit < MAX_DRIVES; ++unit) {
 		drive = &hwif->drives[unit];
 		if (!drive->present)

@@ -2210,13 +2212,11 @@
 				invalidate_device(devp, 0);
 			}
 		}
-
 	}
-
 #ifdef CONFIG_PROC_FS
 	destroy_proc_ide_drives(hwif);
 #endif
-	spin_unlock_irqrestore(&ide_lock, flags);
+	spin_lock_irqsave(&ide_lock, flags);
 	hwgroup = hwif->hwgroup;
 
 	/*

@@ -2330,7 +2330,7 @@
 #endif
 	hwif->straight8		= old_hwif.straight8;
 abort:
-	restore_flags(flags);	/* all CPUs */
+	spin_unlock_irqrestore(&ide_lock, flags);
 }
 
 /*

@@ -2375,23 +2375,23 @@
  */
 int ide_register_hw(hw_regs_t *hw, ide_hwif_t **hwifp)
 {
-	int index, retry = 1;
+	int h, retry = 1;
 	ide_hwif_t *hwif;
 
 	do {
-		for (index = 0; index < MAX_HWIFS; ++index) {
-			hwif = &ide_hwifs[index];
+		for (h = 0; h < MAX_HWIFS; ++h) {
+			hwif = &ide_hwifs[h];
 			if (hwif->hw.io_ports[IDE_DATA_OFFSET] == hw->io_ports[IDE_DATA_OFFSET])
 				goto found;
 		}
-		for (index = 0; index < MAX_HWIFS; ++index) {
-			hwif = &ide_hwifs[index];
+		for (h = 0; h < MAX_HWIFS; ++h) {
+			hwif = &ide_hwifs[h];
 			if ((!hwif->present && !hwif->mate && !initializing) ||
 			    (!hwif->hw.io_ports[IDE_DATA_OFFSET] && initializing))
 				goto found;
 		}
-		for (index = 0; index < MAX_HWIFS; index++)
-			ide_unregister(&ide_hwifs[index]);
+		for (h = 0; h < MAX_HWIFS; ++h)
+			ide_unregister(&ide_hwifs[h]);
 	} while (retry--);
 	return -1;
 found:

@@ -2415,7 +2415,7 @@
 	if (hwifp)
 		*hwifp = hwif;
 
-	return (initializing || hwif->present) ? index : -1;
+	return (initializing || hwif->present) ? h : -1;
 }
 
 /*

@@ -3476,6 +3476,7 @@
 
 EXPORT_SYMBOL(ide_lock);
 EXPORT_SYMBOL(drive_is_flashcard);
+EXPORT_SYMBOL(ide_timer_expiry);
 EXPORT_SYMBOL(ide_intr);
 EXPORT_SYMBOL(ide_get_queue);
 EXPORT_SYMBOL(ide_add_generic_settings);

@@ -3651,7 +3652,7 @@
 	pnpide_init(1);
 #endif
 
-#if defined(CONFIG_BLK_DEV_IDE) || defined(CONFIG_BLK_DEV_IDE_MODULES)
+#if defined(CONFIG_BLK_DEV_IDE) || defined(CONFIG_BLK_DEV_IDE_MODULE)
 # if defined(__mc68000__) || defined(CONFIG_APUS)
 	if (ide_hwifs[0].io_ports[IDE_DATA_OFFSET]) {
 		ide_get_lock(&ide_intr_lock, NULL, NULL);/* for atari only */

drivers/ide/via82cxxx.c +3 -3

diff -urN linux-2.5.6/drivers/ide/via82cxxx.c linux/drivers/ide/via82cxxx.c
@@ -1,5 +1,5 @@
 /*
- * $Id: via82cxxx.c,v 3.33 2001/12/23 22:46:12 vojtech Exp $
+ * $Id: via82cxxx.c,v 3.34 2002/02/12 11:26:11 vojtech Exp $
  *
  *  Copyright (c) 2000-2001 Vojtech Pavlik
  *

@@ -163,7 +163,7 @@
 
 	via_print("----------VIA BusMastering IDE Configuration----------------");
 
-	via_print("Driver Version:                     3.33");
+	via_print("Driver Version:                     3.34");
 	via_print("South Bridge:                       VIA %s", via_config->name);
 
 	pci_read_config_byte(isa_dev, PCI_REVISION_ID, &t);

@@ -495,7 +495,7 @@
 	if (via_clock < 20000 || via_clock > 50000) {
 		printk(KERN_WARNING "VP_IDE: User given PCI clock speed impossible (%d), using 33 MHz instead.\n", via_clock);
 		printk(KERN_WARNING "VP_IDE: Use ide0=ata66 if you want to assume 80-wire cable.\n");
-		via_clock = 33;
+		via_clock = 33333;
 	}
 
 /*

drivers/scsi/ide-scsi.c +3 -3

diff -urN linux-2.5.6/drivers/scsi/ide-scsi.c linux/drivers/scsi/ide-scsi.c
@@ -290,7 +290,7 @@
 			if (!test_bit(PC_WRITING, &pc->flags) && pc->actually_transferred && pc->actually_transferred <= 1024 && pc->buffer) {
 				printk(", rst = ");
 				scsi_buf = pc->scsi_cmd->request_buffer;
-				hexdump(scsi_buf, min(16, pc->scsi_cmd->request_bufflen));
+				hexdump(scsi_buf, min(16U, pc->scsi_cmd->request_bufflen));
 			} else printk("\n");
 		}
 	}

@@ -307,7 +307,7 @@
 
 static inline unsigned long get_timeout(idescsi_pc_t *pc)
 {
-	return max(WAIT_CMD, pc->timeout - jiffies);
+	return max((unsigned long) WAIT_CMD, pc->timeout - jiffies);
 }
 
 /*

@@ -565,7 +565,7 @@
 /*
  *	idescsi_init will register the driver for each scsi.
  */
-static int idescsi_init(void)
+int idescsi_init(void)
 {
 	ide_drive_t *drive;
 	idescsi_scsi_t *scsi;

include/linux/ide.h +5 -4

diff -urN linux-2.5.6/include/linux/ide.h linux/include/linux/ide.h
@@ -240,10 +240,6 @@
 } hw_regs_t;
 
 /*
- * Register new hardware with ide
- */
-extern int ide_register_hw(hw_regs_t *hw, struct hwif_s **hwifp);
-/*
  * Set up hw_regs_t structure before calling ide_register_hw (optional)
  */
 void ide_setup_ports(hw_regs_t *hw,

@@ -336,6 +332,7 @@
 	unsigned autotune	: 2;	/* 1=autotune, 2=noautotune, 0=default */
 	unsigned remap_0_to_1	: 2;	/* 0=remap if ezdrive, 1=remap, 2=noremap */
 	unsigned ata_flash	: 1;	/* 1=present, 0=default */
+	unsigned blocked        : 1;	/* 1=powermanagment told us not to do anything, so sleep nicely */
 	unsigned	addressing;	/* : 2; 0=28-bit, 1=48-bit, 2=64-bit */
 	byte		scsi;		/* 0=default, 1=skip current ide-subdriver for ide-scsi emulation */
 	select_t	select;		/* basic drive/head select reg value */

@@ -505,6 +502,10 @@
 	struct device	device;		/* global device tree handle */
 } ide_hwif_t;
 
+/*
+ * Register new hardware with ide
+ */
+extern int ide_register_hw(hw_regs_t *hw, struct hwif_s **hwifp);
 extern void ide_unregister(ide_hwif_t *hwif);
 
 /*

Alan Cox

2002-03-11 15:04 UTC #86 lore raw

Re: [PATCH] 2.5.6 IDE 19

Quoted 2 lines

in replacements for CF cards in digital cameras and I would rather expect them to be very tolerant about the driver in front of them. And then

Oh dear me. Wrong again. Microdrives require proper polite wakeups. But you see camera vendors buy in IDE code from people who can read and follow standards documents.

Quoted 7 lines

the WB
caches of IDE devices are not caches in the sense of a MESI cache,
they are
more like buffer caches and should therefore flush them self after s
short
period of inactivity without the application of any special flush
command.

You now have an absolute vote of *NO CONFIDENCE* on my part. I'm simply not going to consider running your code. "It probably wont eat your disk" and handwaving is not how you write a block layer.

How is anyone supposed to debug file system code in 2.5 when its known that it will trash data on some disks anyway ? I'd like to see you cite a paragraph where the IDE device is required to flush the data back promptly, or on power off. I'd like to see what you plan to do about all the IBM disks you plan to mistreat and give bad blocks that require a reformat ?

Alan

Martin Dalecki

2002-03-11 16:25 UTC #87 lore raw

Re: [PATCH] 2.5.6 IDE 19

Quoted 17 lines · Alan Cox

Quoted 3 lines
in replacements for CF cards in digital cameras and I would rather expect them to be very tolerant about the driver in front of them. And then
Oh dear me. Wrong again. Microdrives require proper polite wakeups. But you see camera vendors buy in IDE code from people who can read and follow standards documents.
Quoted 8 lines
the WB
caches of IDE devices are not caches in the sense of a MESI cache,
they are
more like buffer caches and should therefore flush them self after s
short
period of inactivity without the application of any special flush
command.

Quoted 3 lines

You now have an absolute vote of *NO CONFIDENCE* on my part. I'm simply not going to consider running your code. "It probably wont eat your disk" and handwaving is not how you write a block layer.

You are claiming this repeatidly. But please just send me the f*cking strace and I will beleve you. Or point me at the corresponding docs. I see no special purpose Win2000 microdrive drivers on IBM.
And I suppose you don't even *own* an IBM MicroDrive. And please note as well that I didn't tell: "I will never ever include such a thing if it's required". What I was about is that there is *no* reason to not include Pavels stuff, even if it leaks, which I know very well, some required functionality by now. Just to satisfy your imagination of how broken an implementation of the ATA firmware could be isn't a reaons. If you have a damn Micro Drive, then feel free to add the required wakeup code - you are all welcome. But please don't implement it as cat jksadfgkjhasdjkf > /proc/some/wried/stuff.

Quoted 5 lines

How is anyone supposed to debug file system code in 2.5 when its known that it will trash data on some disks anyway ? I'd like to see you cite a paragraph where the IDE device is required to flush the data back promptly, or on power off. I'd like to see what you plan to do about all the IBM disks you plan to mistreat and give bad blocks that require a reformat ?

For gods sake:

1. How is Win2000 going to work then?

2. I assume (modulo mistakes) that writers of firmware
are just not stupid and implement the cache as a write behind buffer and not as a MESI cache snooping on the drives bus. But I never claimed that I'm relying on this assumption in any way!

3. Why are *all the other* ATA drivers in different operating systems such easy on this matter and generally much simpler leaner and more readable then the Linux one?!

It's not like one couldn't compare... see for example www.ata-atapi.com

Fsck let's cite the IBM appilcation notes about the Micro Drive found here http://www.storage.ibm.com/hdd/micro/appguide.htm

The IBM microdrive supports the write cache feature. When the write cache feature is enabled, the microdrive posts a command completion for the write command as soon as all the write data has been transferred to the microdrive's cache buffer. The host system, then, can prepare for the next command while the microdrive performs actual disk writing off-line. The write cache feature also contributes to the host system's battery life by shortening the amount of time for write operation.

Because the write command completion does not correspond with the actual disk-write completion, the host system is required to take special care not to lose supply power to the microdrive so that the data that is cached but not yet written to disk will no be lost.

To ensure that the actual disk-writing of the cached data has been completed, it is recommended that a host system issues a `Standby Immediate' command and waits for a command complete from the microdrive.

The cached data will be lost when :
1. A host system cuts off the power for the microdrive
2. A user ejects the microdrive
before the microdrive completes writing cached data to disk.

The microdrive cleans (flushes out) whole cached data upon command completion of Standby Immediate. If the host system enables the write cache feature, it is strongly recommended to issue Standby Immediate before power removed, system shutdown or ejection of the microdrive.

The write cache feature is disabled at power-on reset. It is possible for the host system to enable this feature by issuing Set Features (Enable Write Cache). Because the microdrive may be used with a host system without such care for data integrity, IBM insists that the write cache feature should not be a power-on default.

* Consideration for a time-out value when using the write cache

The microdrive can queue several consecutive write commands. Even if the host system receives a command completion, the microdrive may still be performing disk writing for queued commands, each of which could take up to 7.5 seconds as previously mentioned if an error has occurred and an error recovery routine starts.
This delay eventually surfaces when processing a first non-queued command during write cache.

For example, suppose the microdrive queues 2 write commands and each command takes 7.5 seconds for some extreme reason. Then if the microdrive receives Read Sectors, which is a non-queue command, it will be processed just after disk writing is completed. In the worst case, delay for the Read Sectors would be close to 15 seconds (7.5 x 2).

In light of the stuation above, IBM recommends 30 seconds as a time-out value if the host system uses the write cache feature.

And apparently we see that there is nothing special about them... Just don't enable the write cache and all should be well with a timeout of 30 seconds.

Alan Cox

2002-03-11 16:44 UTC #88 lore raw

Re: [PATCH] 2.5.6 IDE 19

Quoted 2 lines

You are claiming this repeatidly. But please just send me the f*cking strace and I will beleve you. Or point me at the corresponding docs.

You tell me how to strace the bios for one

Quoted 1 line

I see no special purpose Win2000 microdrive drivers on IBM.

No because Microsoft implement the bloody standard in the first place. It works very nicely in MS systems. It works ok in 2.4.18 except with a couple of boxes that don't poke the drive from the APM layer (eg IBM PC110)

Quoted 1 line

And I suppose you don't even *own* an IBM MicroDrive. And please

If you wish to call me a liar, why not do so directly ?

Quoted 5 lines

some required functionality by now. Just to satisfy your imagination of how broken an implementation of the ATA firmware could be isn't a reaons. If you have a damn Micro Drive, then feel free to add the required wakeup code - you are all welcome. But please don't implement it as cat jksadfgkjhasdjkf > /proc/some/wried/stuff.

I've got a nice working 2.4 system thank you. I don't have time to rewrite the IDE layer at the moment. The fact that every 2.5 I've tried either crashed or corrupted my filesystems the moment I did anything load related with it (eg cerberus) convinces me its not something I have time to even consider yet.

Quoted 7 lines

Quoted 3 lines
promptly, or on power off. I'd like to see what you plan to do about all the IBM disks you plan to mistreat and give bad blocks that require a reformat ?
For gods sake:
1. How is Win2000 going to work then?

Because its standards compliant. It wasnt written by a half clued wannabe who has never read the manuals and can do nothing but call people who have a "liar". And a standards compliant implementation does all the right power management commands. Win 98 didnt quite get it right and you'll find one of the updates addresses IDE problems. Ironically fixing the same flush cache and shut down politely problem you plan to break in Linux

Quoted 3 lines

3. Why are *all the other* ATA drivers in different operating systems such easy on this matter and generally much simpler leaner and more readable then the Linux one?!

For the other reason - they are better written. But a driven can be both well written and correct. Its quite apparently you don't care about "correct". If your design is not rigorously following the standard (plus the usual amount of vendor got it wrong slop) then bad things will occur.

I'm not arguing that Andre's code is good, or that it doesn't need some serious redesign. I'm just suggesting it would be a good idea if whoever wrote it new what the hell the were doing, or at least spent the time to understand the ATA documentation and implement it.

Now contrary to your claim I do have an ibm microdrive, do you have the ATA specs, have you ever read them ? I really doubt it.

Alan

Martin Dalecki

2002-03-11 17:05 UTC #89 lore raw

Re: [PATCH] 2.5.6 IDE 19

Quoted 5 lines · Alan Cox

Quoted 3 lines
You are claiming this repeatidly. But please just send me the f*cking strace and I will beleve you. Or point me at the corresponding docs.
You tell me how to strace the bios for one

OK, so there is no f*cking magic utility from IBM to do suspend of MicroDrives under linux through the TASKFILE interface at all as you have climed!

Quoted 4 lines

Quoted 2 lines
I see no special purpose Win2000 microdrive drivers on IBM.
No because Microsoft implement the bloody standard in the first place. It

Hack, then tell me what I'm at?

Quoted 6 lines

works very nicely in MS systems. It works ok in 2.4.18 except with a couple of boxes that don't poke the drive from the APM layer (eg IBM PC110)
Quoted 1 line
And I suppose you don't even *own* an IBM MicroDrive. And please
If you wish to call me a liar, why not do so directly ?

If I wished this I would just do. Trust me!

Quoted 6 lines

Quoted 2 lines
1. How is Win2000 going to work then?
Because its standards compliant. It wasnt written by a half clued wannabe who has never read the manuals and can do nothing but call people who have a "liar". And a standards compliant implementation does all the right power

Andre Hedrick will may kill you... However apparently we agree that there is something wrong with the current driver.

Quoted 3 lines

management commands. Win 98 didnt quite get it right and you'll find one of the updates addresses IDE problems. Ironically fixing the same flush cache and shut down politely problem you plan to break in Linux

No, the problem *is there* Pavel just attempts to FIX IT and I do nothing but supporting him on this. You can hardly claim that he hooks the whole up on the wrong place...

Quoted 2 lines

For the other reason - they are better written. But a driven can be both well written and correct. Its quite apparently you don't care about "correct".

Wrong I care. But I still didn't get too this right now.

Quoted 2 lines

If your design is not rigorously following the standard (plus the usual amount of vendor got it wrong slop) then bad things will occur.

Trivially right.

Quoted 4 lines

I'm not arguing that Andre's code is good, or that it doesn't need some serious redesign. I'm just suggesting it would be a good idea if whoever wrote it new what the hell the were doing, or at least spent the time to understand the ATA documentation and implement it.

So what the heck. Do you thing it will happen overnight!?
Just see how much time it took to get the init tables into
some reasonable shape... and the road is still ahead on the
simple issue of getting them out of ide-pci.c finally!!!
There is only one way of cooperation here - sharing even not quite finished but not broken code - and I still hold up that this is the case with Pavels code.

Quoted 2 lines

Now contrary to your claim I do have an ibm microdrive, do you have the ATA specs, have you ever read them ? I really doubt it.

It wasn't a claim but just a suspiction. So this is cleared. But apparently there is no special IBM command using taskfile to do magic things to it. So therefore it's still valid:
your example was indeed a mock-up.

For your information: I have read the standard papers and comments to them. But the application notes from IBM and actual code from different operating systems gives a much better formal description of what is needed anyway. Or are you going to claim that narrative languaue is more precise then actual C code?

Alan Cox

2002-03-11 17:16 UTC #90 lore raw

Re: [PATCH] 2.5.6 IDE 19

Quoted 3 lines

OK, so there is no f*cking magic utility from IBM to do suspend of MicroDrives under linux through the TASKFILE interface at all as you have climed!

I wrote some bits for the PC110 to work around the APM problem.

Quoted 2 lines

Quoted 1 line
No because Microsoft implement the bloody standard in the first place. It
Hack, then tell me what I'm at?

I'd hope implementing the bloody standard.

Quoted 2 lines

Andre Hedrick will may kill you... However apparently we agree that there is something wrong with the current driver.

Yes. There is an awful lot wrong

Quoted 4 lines

It wasn't a claim but just a suspiction. So this is cleared. But apparently there is no special IBM command using taskfile to do magic things to it. So therefore it's still valid:
your example was indeed a mock-up.

There are standard commands for power management, and for cache flush.

Quoted 4 lines

to them. But the application notes from IBM and actual code from different operating systems gives a much better formal description of what is needed anyway. Or are you going to claim that narrative languaue is more precise then actual C code?

That depends if the C code is right.

Understand - I really appreciate the fact you are planning to tackle this its just the way it comes across on correctness or lack thereof I find a little alarming. Maybe I am misjudging you - if so I certainly apologise

Alan

Martin Dalecki

2002-03-11 18:25 UTC #91 lore raw

Re: [PATCH] 2.5.6 IDE 19

Quoted 32 lines · Alan Cox

Quoted 4 lines
OK, so there is no f*cking magic utility from IBM to do suspend of MicroDrives under linux through the TASKFILE interface at all as you have climed!
I wrote some bits for the PC110 to work around the APM problem.
Quoted 4 lines
Quoted 2 lines
No because Microsoft implement the bloody standard in the first place. It
Hack, then tell me what I'm at?
I'd hope implementing the bloody standard.
Quoted 3 lines
Andre Hedrick will may kill you... However apparently we agree that there is something wrong with the current driver.
Yes. There is an awful lot wrong
Quoted 5 lines
It wasn't a claim but just a suspiction. So this is cleared. But apparently there is no special IBM command using taskfile to do magic things to it. So therefore it's still valid:
your example was indeed a mock-up.
There are standard commands for power management, and for cache flush.

Quoted 7 lines

Quoted 5 lines
to them. But the application notes from IBM and actual code from different operating systems gives a much better formal description of what is needed anyway. Or are you going to claim that narrative languaue is more precise then actual C code?
That depends if the C code is right.

Not quite if it still works... or if nobody is implementing the standard up to word, becouse for example everybody was deriving the drivers (or let's say it clear: his TCP/IP stack) from the same basic source code and finally the hardware adjusted to the reality instead of the standard.
Or if the standard was in fact just an aftertought after some "refference implementation".
And anyway it's hard to argue that code is formally tighter then narrative. (I didn't argue whatever it's formally correct). That's a rather trivial fact.

But anyway I think you understand those issues and it's a bit "theoretical" in respect to the ATA stuff right now.

Quoted 3 lines

Understand - I really appreciate the fact you are planning to tackle this its just the way it comes across on correctness or lack thereof I find a little alarming. Maybe I am misjudging you - if so I certainly apologise

So let's just settle on the fruitless discussions and wait and see... OK? Peace? I was basically just alarmed by the fact that you sounded a bit discouraging to Pavel. (BTW.> The flush part I have already just added to my sorcebase for the parts which Pavels patch tangles... ;-)

Alan Cox

2002-03-11 19:27 UTC #92 lore raw

Re: [PATCH] 2.5.6 IDE 19

Quoted 2 lines

So let's just settle on the fruitless discussions and wait and see... OK? Peace? I was basically just alarmed by the fact that you sounded a bit

Peace is terribly out of fashion nowdays, but sure

Andre Hedrick

2002-03-11 18:03 UTC #93 lore raw

Re: [PATCH] 2.5.6 IDE 19

http://www.t13.org/technical/d99114r0.pdf

Quoted 3 lines · Martin Dalecki

OK, so there is no f*cking magic utility from IBM to do suspend of MicroDrives under linux through the TASKFILE interface at all as you have climed!

It does not need to be there, but since the truth needs to be known. You got in the way with a cosmetic blowjob to Linus while I was trying to fix the bottom transport layer. Since I never got to finish, I left it to you hands to to finish. Even after telling Linus about the problem he still does not get it.

Quoted 7 lines

Quoted 4 lines
Quoted 2 lines
I see no special purpose Win2000 microdrive drivers on IBM.
No because Microsoft implement the bloody standard in the first place. It
Hack, then tell me what I'm at?

Quoted 8 lines

Quoted 6 lines
works very nicely in MS systems. It works ok in 2.4.18 except with a couple of boxes that don't poke the drive from the APM layer (eg IBM PC110)
Quoted 1 line
And I suppose you don't even *own* an IBM MicroDrive. And please
If you wish to call me a liar, why not do so directly ?
If I wished this I would just do. Trust me!

Yep, even you know how many babies were made on the statement "Trust me!".

Quoted 9 lines

Quoted 6 lines
Quoted 2 lines
1. How is Win2000 going to work then?
Because its standards compliant. It wasnt written by a half clued wannabe who has never read the manuals and can do nothing but call people who have a "liar". And a standards compliant implementation does all the right power
Andre Hedrick will may kill you... However apparently we agree that there is something wrong with the current driver.

Oh I fixed the problem as far as the hardware atomic segment goes, I am waiting to see if you understand the problem and can fix it. The real problem is Linus ... because he can not or will not see the issue. Nor will he listen to the issue anymore.

Quoted 7 lines

Quoted 3 lines
management commands. Win 98 didnt quite get it right and you'll find one of the updates addresses IDE problems. Ironically fixing the same flush cache and shut down politely problem you plan to break in Linux
No, the problem *is there* Pavel just attempts to FIX IT and I do nothing but supporting him on this. You can hardly claim that he hooks the whole up on the wrong place...

Recall Pavel refused my offer of assistance to help him, but that was in a private mail.

Quoted 9 lines

Quoted 2 lines
For the other reason - they are better written. But a driven can be both well written and correct. Its quite apparently you don't care about "correct".
Wrong I care. But I still didn't get too this right now.
Quoted 2 lines
If your design is not rigorously following the standard (plus the usual amount of vendor got it wrong slop) then bad things will occur.
Trivially right.

Whatever ....

Quoted 5 lines

Quoted 4 lines
I'm not arguing that Andre's code is good, or that it doesn't need some serious redesign. I'm just suggesting it would be a good idea if whoever wrote it new what the hell the were doing, or at least spent the time to understand the ATA documentation and implement it.

Quoted 7 lines

So what the heck. Do you thing it will happen overnight!?
Just see how much time it took to get the init tables into
some reasonable shape... and the road is still ahead on the
simple issue of getting them out of ide-pci.c finally!!!
There is only one way of cooperation here - sharing even not quite finished but not broken code - and I still hold up that this is the case with Pavels code.

Lame, could have been fixed w/ a know solution.
The main reason for delaying this feature set was to have an means to force open spec for most of the hardware in PATA.

Quoted 7 lines

Quoted 2 lines
Now contrary to your claim I do have an ibm microdrive, do you have the ATA specs, have you ever read them ? I really doubt it.
It wasn't a claim but just a suspiction. So this is cleared. But apparently there is no special IBM command using taskfile to do magic things to it. So therefore it's still valid:
your example was indeed a mock-up.

No, mine has there real test base, I goto there Lab people and submit examples and questions and learn. I doubt they will listen to you reading your code base, since you have claimed taskfile is wrong. It was developed in concert with IBM.

Quoted 5 lines

For your information: I have read the standard papers and comments to them. But the application notes from IBM and actual code from different operating systems gives a much better formal description of what is needed anyway. Or are you going to claim that narrative languaue is more precise then actual C code?

Oh and I only have co-authored the document you are reading and work with the OEM. So I am clearly out classed by you.

Regards,

Andre Hedrick
The Second Linux X-IDE guy

Gunther Mayer

2002-03-11 19:03 UTC #94 lore raw

Re: [PATCH] 2.5.6 IDE 19, return of taskfile

Quoted 8 lines · Andre Hedrick

Quoted 5 lines · Martin Dalecki
It wasn't a claim but just a suspiction. So this is cleared. But apparently there is no special IBM command using taskfile to do magic things to it. So therefore it's still valid:
your example was indeed a mock-up.

Quoted 5 lines

No, mine has there real test base, I goto there Lab people and submit examples and questions and learn. I doubt they will listen to you reading your code base, since you have claimed taskfile is wrong. It was developed in concert with IBM.

The ANSI/NCITS ATA Standard documents lack proper definition what
a "task file" or "taskfile" is ! ATA-1, -2, -3 don't mention this (at least acroread didn't find),
ATAPI-4 has 3 references but no definition. This is a serious omission for a well-written standard !
Andre, will this be corrected in some newer standard you participate? ( Don't know about ata-5/6 yet)

These two meanings certainly explain some confusion about "taskfile":
1) The IDE register set (e.g. 0x1f0-0x1f7) used by a special state-machine (e.g. ATAPI)
2) Andres implementation to export the "task file" to user mode (as in his patches which were refused by Linus)

Andre, your approach to "parse" the takfile access and let only known commands through
must be weighted against a "generic" taskfile ioctl, where _I_ give all needed state-machine information
(incl. state-machine as needed) to serve my reuqest.

Currently your taskfile access is hardcoded in tables in your ide patches and this is

inflexible (e.g. cannot support future commands, unknown at the time of your writing) !

Your "case" structures and accompanying code are considered kernel bloat, because it can be done in user code (with a "generic ioctl" and a "generic task file state machine" which surely
can be extracted from your patch).

Regards, Gunther

P.S.
For some more fun read
http://support.microsoft.com/default.aspx?scid=kb;EN-US;q239700

Andre Hedrick

2002-03-11 19:15 UTC #95 lore raw

Re: [PATCH] 2.5.6 IDE 19, return of taskfile

Gunther,

See in working documents we use the terms we all know,

Cheers,

Andre Hedrick
The Second Linux X-IDE guy

Quoted 53 lines · Gunther Mayer

Quoted 8 lines · Andre Hedrick
Quoted 5 lines · Martin Dalecki
It wasn't a claim but just a suspiction. So this is cleared. But apparently there is no special IBM command using taskfile to do magic things to it. So therefore it's still valid:
your example was indeed a mock-up.
Quoted 5 lines
No, mine has there real test base, I goto there Lab people and submit examples and questions and learn. I doubt they will listen to you reading your code base, since you have claimed taskfile is wrong. It was developed in concert with IBM.
The ANSI/NCITS ATA Standard documents lack proper definition what
a "task file" or "taskfile" is ! ATA-1, -2, -3 don't mention this (at least acroread didn't find),
ATAPI-4 has 3 references but no definition. This is a serious omission for a well-written standard !
Andre, will this be corrected in some newer standard you participate? ( Don't know about ata-5/6 yet)
These two meanings certainly explain some confusion about "taskfile":
1) The IDE register set (e.g. 0x1f0-0x1f7) used by a special state-machine (e.g. ATAPI)
2) Andres implementation to export the "task file" to user mode (as in his patches which were refused by Linus)
Andre, your approach to "parse" the takfile access and let only known commands through
must be weighted against a "generic" taskfile ioctl, where _I_ give all needed state-machine information
(incl. state-machine as needed) to serve my reuqest.
Currently your taskfile access is hardcoded in tables in your ide patches and this is
inflexible (e.g. cannot support future commands, unknown at the time of your writing) !
Your "case" structures and accompanying code are considered kernel bloat, because it can be done in user code (with a "generic ioctl" and a "generic task file state machine" which surely
can be extracted from your patch).
Regards, Gunther
P.S.
For some more fun read
http://support.microsoft.com/default.aspx?scid=kb;EN-US;q239700

Gunther Mayer

2002-03-11 19:22 UTC #96 lore raw

Re: [PATCH] 2.5.6 IDE 19, return of taskfile

Quoted 5 lines · Andre Hedrick

Gunther,
http://www.t13.org/technical/d99114r0.pdf
See in working documents we use the terms we all know,

d99114r0 does not contain "working documents" references.

It just uses the term "task file", though formal definition is missing (again).

Alan Cox

2002-03-11 19:32 UTC #97 lore raw

Re: [PATCH] 2.5.6 IDE 19, return of taskfile

In reply to Gunther Mayer

Quoted 4 lines

Currently your taskfile access is hardcoded in tables in your ide patches and this is
inflexible (e.g. cannot support future commands, unknown at the time of your writing) !

It stops things like disk level DRM nicely too

Alexander Viro

2002-03-11 19:39 UTC #98 lore raw

Re: [PATCH] 2.5.6 IDE 19, return of taskfile

Quoted 6 lines · Alan Cox

Quoted 4 lines
Currently your taskfile access is hardcoded in tables in your ide patches and this is
inflexible (e.g. cannot support future commands, unknown at the time of your writing) !
It stops things like disk level DRM nicely too

Umm... By what magic? The entire interface _is_ root-only, isn't it? And root can do a lot of fun stuff, starting with editing the kernel image...

Andre Hedrick

2002-03-11 19:43 UTC #99 lore raw

Re: [PATCH] 2.5.6 IDE 19, return of taskfile

Quoted 6 lines · Alexander Viro

Quoted 2 lines · Alan Cox
Quoted 2 lines
Currently your taskfile access is hardcoded in tables in your ide patches and this is

Quoted 9 lines

Quoted 4 lines
Quoted 2 lines
inflexible (e.g. cannot support future commands, unknown at the time of your writing) !
It stops things like disk level DRM nicely too
Umm... By what magic? The entire interface _is_ root-only, isn't it? And root can do a lot of fun stuff, starting with editing the kernel image...

Well why did you not object to the SCSI sequencer in the past. Your argument proves that hardware venders will not like Linux and the childlike additude of not protecting the hardware. ROOT is a brained GAWD that should run for local Politics.

--andre

Alexander Viro

2002-03-11 19:56 UTC #100 lore raw

Re: [PATCH] 2.5.6 IDE 19, return of taskfile

Quoted 4 lines · Andre Hedrick

Well why did you not object to the SCSI sequencer in the past. Your argument proves that hardware venders will not like Linux and the childlike additude of not protecting the hardware. ROOT is a brained GAWD that should run for local Politics.

Andre, get a fucking clue. If you claim that your "filtering" provides any security - you are making fradulent claims. End of story.

Fact of life: process with EUID 0 can bypass your "protection" easily. IF filtering is useful for some reasons, these reasons have nothing to security.

Again, by mentioning security considerations among the reasons you are harming yourself - it's kinda hard to take you seriously if you do not understand the basic stuff. It's not like we didn't have that conversation before...

Alan Cox

2002-03-11 19:48 UTC #101 lore raw

Re: [PATCH] 2.5.6 IDE 19, return of taskfile

Quoted 3 lines

Umm... By what magic? The entire interface _is_ root-only, isn't it? And root can do a lot of fun stuff, starting with editing the kernel image...

No argument there.

Do we want to assume all raw commands are CAP_SYS_RAWIO or break them down a bit ?

Pavel Machek

2002-03-13 21:01 UTC #102 lore raw

Re: [PATCH] 2.5.6 IDE 19, return of taskfile

Hi!

Quoted 8 lines

Quoted 3 lines
Umm... By what magic? The entire interface _is_ root-only, isn't it? And root can do a lot of fun stuff, starting with editing the kernel image...
No argument there.
Do we want to assume all raw commands are CAP_SYS_RAWIO or break them down a bit ?

As noone seriously uses capabiities, anyway, I guess CAP_SYS_RAWIO for all is ok.

Signature · 2 lines

Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.

john slee

2002-03-15 19:25 UTC #103 lore raw

Re: [PATCH] 2.5.6 IDE 19, return of taskfile

Quoted 6 lines · Pavel Machek

Hi!
Quoted 4 lines
Quoted 3 lines
Umm... By what magic? The entire interface _is_ root-only, isn't it? And root can do a lot of fun stuff, starting with editing the kernel image...

Quoted 7 lines

Quoted 4 lines
No argument there.
Do we want to assume all raw commands are CAP_SYS_RAWIO or break them down a bit ?
As noone seriously uses capabiities, anyway, I guess CAP_SYS_RAWIO for all is ok.

i believe the next debian (after the one currently stabilizing for release) has "real" use of capabilities as a major goal although that was hearsay and may be entirely false. the amount of work involved is not insignificant

it'd certainly be a good thing to see. after all these years of slowly converting things to use CAP_SYS_* instead of uid==0 i certainly don't want that effort to be wasted.

Signature · 2 lines

R N G G   "Well, there it goes again... And we just sit 
 I G G G   here without opposable thumbs." -- gary larson

Erik Andersen

2002-03-16 02:27 UTC #104 lore raw

Re: [PATCH] 2.5.6 IDE 19, return of taskfile

Quoted 4 lines · john slee

i believe the next debian (after the one currently stabilizing for release) has "real" use of capabilities as a major goal although that was hearsay and may be entirely false. the amount of work involved is not insignificant

I expect that teaching start-stop-daemon about capabilities would take care of much of the needed work automagically. But this is rapidly wandering off topic.

-Erik

--
Erik B. Andersen http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--

Andre Hedrick

2002-03-11 19:40 UTC #105 lore raw

Re: [PATCH] 2.5.6 IDE 19, return of taskfile

Quoted 6 lines · Alan Cox

Quoted 4 lines
Currently your taskfile access is hardcoded in tables in your ide patches and this is
inflexible (e.g. cannot support future commands, unknown at the time of your writing) !
It stops things like disk level DRM nicely too

Stop using "logic", it is clear it is not a "Darwin" thing to do.

Cheers,

Andre Hedrick
The Second Linux X-IDE guy

Martin Dalecki

2002-03-11 19:25 UTC #106 lore raw

Re: [PATCH] 2.5.6 IDE 19, return of taskfile

Quoted 3 lines · Gunther Mayer

Currently your taskfile access is hardcoded in tables in your ide patches and this is
inflexible (e.g. cannot support future commands, unknown at the time of your writing)

And vendor specific commands which they don't wan't the world to know about and the list would be complete. Anyway thank you for this well done clarification.

Quoted 4 lines

Your "case" structures and accompanying code are considered kernel bloat, because it can be done in user code (with a "generic ioctl" and a "generic task file state machine" which surely
can be extracted from your patch).

The worsest thing about them is that they are translating the plain commands to some obscure internal values and vice versa. This is making it a bit tedious to remove them directly. And it's in esp. error prone.

The fortunate thing is that the state machine points can be really easly identifyed. The unfortunate thing is that there is simple that much plain poor C coding in the drivers code that it will just take time until one can get at this. Please see the notes inside my patches about buffer overruns... methods called twice and modularization as well as comments about functions passing timeout pointers, which are taken by reusing the IRQ code path and so on...

Zwane Mwaikambo

2002-03-12 10:09 UTC #107 lore raw

Re: [PATCH] 2.5.6 IDE 19, return of taskfile

Quoted 3 lines · Martin Dalecki

buffer overruns... methods called twice and modularization as well as comments about functions passing timeout pointers, which are taken by reusing the IRQ code path and so on...

Are you referring to the IDE-CD code there? If so can you show me where the timeout handler uses the ISRs? And what exactly is wrong with the timeout handlers anyway?

Regards,
Zwane Mwaikambo

Charles Cazabon

2002-03-11 17:10 UTC #108 lore raw

Re: [PATCH] 2.5.6 IDE 19

Quoted 6 lines · Martin Dalecki

For your information: I have read the standard papers and comments to them. But the application notes from IBM and actual code from different operating systems gives a much better formal description of what is needed anyway. Or are you going to claim that narrative languaue is more precise then actual C code?

It appears that you're confusing an implementation of a specification with the specification itself. The specification wins out, and therefore you can't just copy the behvaiour of another implementation.

Charles

Signature · 4 lines

-----------------------------------------------------------------------
Charles Cazabon                            <[email protected]>
GPL'ed software available at:  http://www.qcc.sk.ca/~charlesc/software/
-----------------------------------------------------------------------

Barry K. Nathan

2002-03-11 21:49 UTC #109 lore raw

Re: [PATCH] 2.5.6 IDE 19

Quoted 10 lines

Quoted 3 lines
For gods sake:
1. How is Win2000 going to work then?
Because its standards compliant. It wasnt written by a half clued wannabe who has never read the manuals and can do nothing but call people who have a "liar". And a standards compliant implementation does all the right power management commands. Win 98 didnt quite get it right and you'll find one of the updates addresses IDE problems. Ironically fixing the same flush cache and shut down politely problem you plan to break in Linux

Windows 2000 doesn't even get this right 100% of the time either:
http://support.microsoft.com/default.aspx?scid=kb;EN-US;q281672
(I've seen this bug corrupt data in real life -- it's not just theoretical. The really unfortunate part is that Win2K also forces the write cache on, even if you try to turn it off, due to another bug.)

AFAIK a fix for this is planned for Win2K Service Pack 3, and WinXP works properly (in this regard anyway) out-of-the-box.

-Barry K. Nathan <[email protected]>

Pavel Machek

2002-03-12 23:08 UTC #110 lore raw

Re: [PATCH] 2.5.6 IDE 19

Hi!

Quoted 6 lines

Quoted 3 lines
management commands. Win 98 didnt quite get it right and you'll find one of the updates addresses IDE problems. Ironically fixing the same flush cache and shut down politely problem you plan to break in Linux
No, the problem *is there* Pavel just attempts to FIX IT and I do nothing but supporting him on this. You can hardly claim that

Actually, problem is not yet there, because current S3 sleep is so broken it is *very* likely to crash your box (and thereby save your data). But when S3 is repaired, this code is going to be needed.
Pavel

Signature · 2 lines

Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.

Andre Hedrick

2002-03-11 17:44 UTC #111 lore raw

Re: [PATCH] 2.5.6 IDE 19

In reply to Anton Altaparmakov

I am now sick of what I see and will now make a little noise!

Quoted 43 lines · Martin Dalecki

Quoted 18 lines · Alan Cox
Quoted 3 lines
in replacements for CF cards in digital cameras and I would rather expect them to be very tolerant about the driver in front of them. And then
Oh dear me. Wrong again. Microdrives require proper polite wakeups. But you see camera vendors buy in IDE code from people who can read and follow standards documents.
Quoted 8 lines
the WB
caches of IDE devices are not caches in the sense of a MESI cache,
they are
more like buffer caches and should therefore flush them self after s
short
period of inactivity without the application of any special flush
command.
Quoted 3 lines
You now have an absolute vote of *NO CONFIDENCE* on my part. I'm simply not going to consider running your code. "It probably wont eat your disk" and handwaving is not how you write a block layer.
You are claiming this repeatidly. But please just send me the f*cking strace and I will beleve you. Or point me at the corresponding docs. I see no special purpose Win2000 microdrive drivers on IBM.
And I suppose you don't even *own* an IBM MicroDrive. And please note as well that I didn't tell: "I will never ever include such a thing if it's required". What I was about is that there is *no* reason to not include Pavels stuff, even if it leaks, which I know very well, some required functionality by now. Just to satisfy your imagination of how broken an implementation of the ATA firmware could be isn't a reaons. If you have a damn Micro Drive, then feel free to add the required wakeup code - you are all welcome. But please don't implement it as cat jksadfgkjhasdjkf > /proc/some/wried/stuff.
Quoted 6 lines
How is anyone supposed to debug file system code in 2.5 when its known that it will trash data on some disks anyway ? I'd like to see you cite a paragraph where the IDE device is required to flush the data back promptly, or on power off. I'd like to see what you plan to do about all the IBM disks you plan to mistreat and give bad blocks that require a reformat ?

Quoted 3 lines

For gods sake:
1. How is Win2000 going to work then?

If you are going to compare Linux to Mircosoft code you need to know what the other side does. Does reseting the bus between commands ring a bell?

Does the fact that MS XP Service Pack #2 having as similar taskfile command passthrough method mean anything ... Oh Oh, but there is no Service Pack #1 how could one know this ... guess my friend some of us are in the business and you are trying to get there and I wish you success.

Quoted 4 lines

2. I assume (modulo mistakes) that writers of firmware
are just not stupid and implement the cache as a write behind buffer and not as a MESI cache snooping on the drives bus. But I never claimed that I'm relying on this assumption in any way!

Sheesh, you are not even capable of reading the standard which I help to co-author and mold. It is a standard about "DEVICES" not about "HOSTS". For a person citing MicroSoft Windows you are clueless to there erratium about a HOST SHALL flush cache before a spin down. Your darwin Linus model is why WHQL exists for the other OS.

Were you ever a MDDK users? It really sounds like it.

Quoted 5 lines

3. Why are *all the other* ATA drivers in different operating systems such easy on this matter and generally much simpler leaner and more readable then the Linux one?!
It's not like one couldn't compare... see for example www.ata-atapi.com

Funny Hale and I are friends, and I think he would laugh you off the planet for your thoughts. "YOU ARE A BAD HOST" is what I can hear in the background.

Quoted 2 lines

Fsck let's cite the IBM appilcation notes about the Micro Drive found here http://www.storage.ibm.com/hdd/micro/appguide.htm

Funny you should mention that point ... The "flagged taskfile code" is a project to allow for NATIVE DFT support in Linux. Nice screw job you did to IBM.

Quoted 10 lines

The IBM microdrive supports the write cache feature. When the write cache feature is enabled, the
microdrive posts a command completion for the write command as soon as all the write data has
been transferred to the microdrive's cache buffer. The host system, then, can prepare for the next
command while the microdrive performs actual disk writing off-line. The write cache feature also
contributes to the host system's battery life by shortening the amount of time for write operation.

I bet you are clueless to MicroDrives having a new MetaData Cache set. Goggle it, I am not going to teach you what you should know if you are going to be a Maintainer.

Quoted 5 lines

Because the write command completion does not correspond with the actual disk-write completion,
the host system is required to take special care not to lose supply power to the microdrive so that the
data that is cached but not yet written to disk will no be lost.

So what is your point, did you just figure this out. FYI SCSI does this too but they have FUA.

Quoted 5 lines

To ensure that the actual disk-writing of the cached data has been completed, it is recommended that
a host system issues a `Standby Immediate' command and waits for a command complete from the
microdrive.

Reread all of the document, all 500+ pages and figure out the rules sequence, before you start trying to bible bang it.

Quoted 4 lines

The cached data will be lost when :
1. A host system cuts off the power for the microdrive
2. A user ejects the microdrive
before the microdrive completes writing cached data to disk.

Maybe that is why YOU and PAVEL are not getting this suspend to disk write, you can not follow the rules.
ATA-ATAPI ~= LINUS, it is a DICTATORSHIP also. If you can not follow the rules you get ABORTED, or CORRUPTED. What part is not clear? See I got aborted by Linus, you have been corrupted.

Quoted 6 lines

The microdrive cleans (flushes out) whole cached data upon command completion of Standby Immediate. If
the host system enables the write cache feature, it is strongly recommended to issue Standby Immediate
before power removed, system shutdown or ejection of the microdrive.

Quoted 8 lines

The write cache feature is disabled at power-on reset. It is possible for the host system to enable this feature
by issuing Set Features (Enable Write Cache). Because the microdrive may be used with a host system
without such care for data integrity, IBM insists that the write cache feature should not be a power-on default.
* Consideration for a time-out value when using the write cache

Well of it does not complete you do not let the suspend complete and you give ACPI the finger and provide the enduser a way to override the ruleset. Let ROOT screw the system, but be a "GOOD HOST" and prevent it by default.

Quoted 9 lines

The microdrive can queue several consecutive write commands. Even if the host system receives a
command completion, the microdrive may still be performing disk writing for queued commands, each of
which could take up to 7.5 seconds as previously mentioned if an error has occurred and an error
recovery routine starts.
This delay eventually surfaces when processing a first non-queued command during write cache.

WTF are you talking about ?? TCQ ?? Go and whiteboard it and you will see the problem. If you are talking about write cache, all drives do this and the point again was ??

Quoted 7 lines

For example, suppose the microdrive queues 2 write commands and each command takes 7.5 seconds
for some extreme reason. Then if the microdrive receives Read Sectors, which is a non-queue command,
it will be processed just after disk writing is completed. In the worst case, delay for the Read Sectors
would be close to 15 seconds (7.5 x 2).

How are you going to delay commands unless metadata hardware cache is used?

Quoted 3 lines

In light of the stuation above, IBM recommends 30 seconds as a time-out value if the host system uses
the write cache feature.

The SPEC does does not address CFA hardware, goto CFA to get their ruleset.

Quoted 2 lines

And apparently we see that there is nothing special about them... Just don't enable the write cache and all should be well with a timeout of 30 seconds.

Well it is safer than what you are mumbling about.

Linus you learn anything yet, either?

Andre Hedrick
The Second Linux X-IDE guy

Alan Cox

2002-03-11 17:54 UTC #112 lore raw

Re: [PATCH] 2.5.6 IDE 19

Quoted 4 lines

Does the fact that MS XP Service Pack #2 having as similar taskfile command passthrough method mean anything ... Oh Oh, but there is no Service Pack #1 how could one know this ... guess my friend some of us are in the business and you are trying to get there and I wish you success.

Actually helping him by getting him info like that would be perhaps more productive than grinning from on high ?

Quoted 3 lines

Funny you should mention that point ... The "flagged taskfile code" is a project to allow for NATIVE DFT support in Linux. Nice screw job you did to IBM.

Ok so whats native DFT and where does he (and I for that matter) read about it ?

Quoted 1 line

The SPEC does does not address CFA hardware, goto CFA to get their ruleset.

The URL is http://www.compactflash.org/specdl1.htm btw if anyone wants that one. Its got fun stuff like how to password protect your cf cards but I don't seem to remember PM stuff in it ?

Alan

Anton Altaparmakov

2002-03-11 18:07 UTC #113 lore raw

Re: [PATCH] 2.5.6 IDE 19

Quoted 6 lines · Alan Cox

Quoted 3 lines
Funny you should mention that point ... The "flagged taskfile code" is a project to allow for NATIVE DFT support in Linux. Nice screw job you did to IBM.
Ok so whats native DFT and where does he (and I for that matter) read about it ?

DFT = Drive Fault Tolerance

It is an IBM utility which performs extensive diagnostics of a hard drive. At present this is a DOS program which is used via a dos boot disk.

Have look at the IBM website where you can download this (you can get a dd image of the boot floppy from there, too, if you don't have Windows).

The idea behind native DFT is to be able to perform drive diagnostics from within the OS without rebooting with a DOS disk and tying up the system for hours during the checks. The advantages of this combined with IDE/SCSI hot swap are strikingly obvious...

The utility also returns a special fault code which in combination with the ibm website allows you to return a faulty disk and obtain a replacement very easily.

Best regards,

Anton

Signature · 3 lines

Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Linux NTFS maintainer / WWW: http://linux-ntfs.sf.net/
ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/

Alan Cox

2002-03-11 19:25 UTC #114 lore raw

Re: [PATCH] 2.5.6 IDE 19

Quoted 4 lines

The idea behind native DFT is to be able to perform drive diagnostics from within the OS without rebooting with a DOS disk and tying up the system for hours during the checks. The advantages of this combined with IDE/SCSI hot swap are strikingly obvious...

So providing we have a properly generic "issue IDE command from user space" do we need any more kernel magic for this ?

Anton Altaparmakov

2002-03-11 22:06 UTC #115 lore raw

Re: [PATCH] 2.5.6 IDE 19

Quoted 7 lines · Alan Cox

Quoted 4 lines
The idea behind native DFT is to be able to perform drive diagnostics from within the OS without rebooting with a DOS disk and tying up the system for hours during the checks. The advantages of this combined with IDE/SCSI hot swap are strikingly obvious...
So providing we have a properly generic "issue IDE command from user space" do we need any more kernel magic for this ?

No, AFAIK.

You need to be able to tell the kernel not to touch the drive during the testing or a lot of fun things might happen... (I would assume.)

Oh and I was brain dead when I wrote what DFT stands for. Sorry. It is of course DFT = Drive Fitness Test and the DFT utility boot floppy I mentioned can be downloaded from: http://www.storage.ibm.com/hdd/support/download.htm

Anton

Signature · 5 lines

  "I've not lost my mind. It's backed up on tape somewhere." - Unknown
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Linux NTFS Maintainer / WWW: http://linux-ntfs.sf.net/
ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/

Vojtech Pavlik

2002-03-11 22:03 UTC #116 lore raw

Re: [PATCH] 2.5.6 IDE 19

Quoted 7 lines · Alan Cox

Quoted 4 lines
The idea behind native DFT is to be able to perform drive diagnostics from within the OS without rebooting with a DOS disk and tying up the system for hours during the checks. The advantages of this combined with IDE/SCSI hot swap are strikingly obvious...
So providing we have a properly generic "issue IDE command from user space" do we need any more kernel magic for this ?

That's all we need, yes. And I hope that's exactly what we'll have.

Signature · 2 lines

Vojtech Pavlik
SuSE Labs

Wayne Whitney

2002-03-11 18:09 UTC #117 lore raw

Re: [PATCH] 2.5.6 IDE 19

Quoted 2 lines · you

Ok so whats native DFT and where does he (and I for that matter) read about it ?

Having recently RMA'ed an IBM drive, I can say that DFT = Drive Fitness Test, IBM's low-level diagnostics. And that makes sense in this context, their DFT software would need taskfile access.

Wayne

Andre Hedrick

2002-03-11 18:28 UTC #118 lore raw

Re: [PATCH] 2.5.6 IDE 19

http://www.t13.org/ballots/e01028r0.pdf

Quoted 7 lines · Alan Cox

Quoted 4 lines
Does the fact that MS XP Service Pack #2 having as similar taskfile command passthrough method mean anything ... Oh Oh, but there is no Service Pack #1 how could one know this ... guess my friend some of us are in the business and you are trying to get there and I wish you success.
Actually helping him by getting him info like that would be perhaps more productive than grinning from on high ?

I would but he is equivalent to Linus and will not listen to facts.

Quoted 4 lines

Quoted 3 lines
Funny you should mention that point ... The "flagged taskfile code" is a project to allow for NATIVE DFT support in Linux. Nice screw job you did to IBM.

Quoted 8 lines

Ok so whats native DFT and where does he (and I for that matter) read about it ?
Quoted 1 line
The SPEC does does not address CFA hardware, goto CFA to get their ruleset.
The URL is http://www.compactflash.org/specdl1.htm btw if anyone wants that one. Its got fun stuff like how to password protect your cf cards but I don't seem to remember PM stuff in it ?

Sorry there is a mix up, since MicroDrives are fixed disk that miss report by design, you have mix the two to get it right. However I will check with IBM again on the specifics for you.

Cheers,

Andre Hedrick
The Second Linux X-IDE guy

Martin Dalecki

2002-03-11 18:52 UTC #119 lore raw

Re: [PATCH] 2.5.6 IDE 19

Quoted 8 lines · Andre Hedrick

Quoted 5 lines · Alan Cox
Quoted 5 lines
Does the fact that MS XP Service Pack #2 having as similar taskfile command passthrough method mean anything ... Oh Oh, but there is no Service Pack #1 how could one know this ... guess my friend some of us are in the business and you are trying to get there and I wish you success.

Quoted 5 lines

Quoted 3 lines
Actually helping him by getting him info like that would be perhaps more productive than grinning from on high ?
I would but he is equivalent to Linus and will not listen to facts.

Fact is you are a lame coder. Whatever your other competences are - I don't know. (Plese note this doesn't imply that I'm a "master coder".)

Perhaps the only equivalent betwen Linus and me is that we are both from a cold part of the world, called the Baltic area ;-) You have even offered to me to provide a stripped down version of the driver without the *current* task file implementation yourself. I'm still awaiting it. Or was it your "invisible friend" talking that time again?

I can really really understand why Pavel is just ignoring you...

But you know what? It's really hard to take someone serious who is publically calling me doing a blow-job on Linus. You would be surprised: I don't exchange *that* much with Linus. I send him patches - he applies them that's all. And that's all that I expect. What's driving me is the encouragement from other people just that... and of course the fun at tinkering with the stuff.

BTW.> I have looked at the contributors lists of some recent ATA deocument's and couldn't find your name anywhere there. Maybe you did just the spell checking for them...? Or mind you could, in a rare moment of clear mind, send me a pointer? URL perhaps? That would be really delightfull...

Andre Hedrick

2002-03-11 19:03 UTC #120 lore raw

Re: [PATCH] 2.5.6 IDE 19

Quoted 19 lines · Martin Dalecki

Quoted 8 lines · Andre Hedrick
Quoted 5 lines · Alan Cox
Quoted 5 lines
Does the fact that MS XP Service Pack #2 having as similar taskfile command passthrough method mean anything ... Oh Oh, but there is no Service Pack #1 how could one know this ... guess my friend some of us are in the business and you are trying to get there and I wish you success.
Quoted 5 lines
Quoted 3 lines
Actually helping him by getting him info like that would be perhaps more productive than grinning from on high ?
I would but he is equivalent to Linus and will not listen to facts.
Fact is you are a lame coder. Whatever your other competences are - I don't know. (Plese note this doesn't imply that I'm a "master coder".)

Quoted 6 lines

Perhaps the only equivalent betwen Linus and me is that we are both from a cold part of the world, called the Baltic area ;-) You have even offered to me to provide a stripped down version of the driver without the *current* task file implementation yourself. I'm still awaiting it. Or was it your "invisible friend" talking that time again?

Deal, will do it.

Quoted 9 lines

I can really really understand why Pavel is just ignoring you...
But you know what? It's really hard to take someone serious who is publically calling me doing a blow-job on Linus. You would be surprised: I don't exchange *that* much with Linus. I send him patches - he applies them that's all. And that's all that I expect. What's driving me is the encouragement from other people just that... and of course the fun at tinkering with the stuff.

You got in there and give Linus the comsetic changes that were in the works early. I asked you hold off because there was a transport layer problem. You agreed. Next thing I know you turn the flipside on me. You expect me to have warm and fuzzys?

Quoted 6 lines

BTW.> I have looked at the contributors lists of some recent ATA deocument's and couldn't find your name anywhere there. Maybe you did just the spell checking for them...? Or mind you could, in a rare moment of clear mind, send me a pointer? URL perhaps? That would be really delightfull...

*****************
The ATA/ATAPI-6 letter ballot has closed. The results are 18 votes for the motion, 0 votes against the motion, 0 abstentions, and 2 eligible members did not vote. 2 yes votes had comments. The motion passes.

I have uploaded e01028r0.doc the official announcement of the vote to incoming on the FTP site. I have also uploaded e01143r0.doc the editors proposed resolution of the letter ballot comments. This will be reviewed at the December meeting.
*****************

I do not see your name on that list for the ballot.

Cheers,

Andre Hedrick
The Second Linux X-IDE guy

Martin Dalecki

2002-03-11 19:13 UTC #121 lore raw

Re: [PATCH] 2.5.6 IDE 19

Quoted 1 line

Deal, will do it.

I don't expect anymore that you hold your word.

Quoted 11 lines

Quoted 10 lines
I can really really understand why Pavel is just ignoring you...
But you know what? It's really hard to take someone serious who is publically calling me doing a blow-job on Linus. You would be surprised: I don't exchange *that* much with Linus. I send him patches - he applies them that's all. And that's all that I expect. What's driving me is the encouragement from other people just that... and of course the fun at tinkering with the stuff.

Quoted 4 lines

You got in there and give Linus the comsetic changes that were in the works early. I asked you hold off because there was a transport layer problem. You agreed. Next thing I know you turn the flipside on me. You expect me to have warm and fuzzys?

Maybe your invisible friend wisperid that to you: but I DIDN'T AGREE TO HOLD OFF. The changes thus far are quite trivial and should be a piece of cake to adjust too for an averegely capable programmer wich you are not and which is the main problem with you cherishing the driver in question. I'm clear enough now? Or does one have to be a psychiatrist to talk to you?

Quoted 11 lines

*****************
The ATA/ATAPI-6 letter ballot has closed. The results are 18 votes for the motion, 0 votes against the motion, 0 abstentions, and 2 eligible members did not vote. 2 yes votes had comments. The motion passes.
I have uploaded e01028r0.doc the official announcement of the vote to incoming on the FTP site. I have also uploaded e01143r0.doc the editors proposed resolution of the letter ballot comments. This will be reviewed at the December meeting.
*****************

Quoted 3 lines

http://www.t13.org/ballots/e01028r0.pdf
I do not see your name on that list for the ballot.

I didn't claim too. Your invisible friend was apparently talking to you again. But still my question remains where the heck is Yours?

Andre Hedrick

2002-03-11 19:25 UTC #122 lore raw

Re: [PATCH] 2.5.6 IDE 19

Quoted 7 lines · Martin Dalecki

Quoted 3 lines
http://www.t13.org/ballots/e01028r0.pdf
I do not see your name on that list for the ballot.
I didn't claim too. Your invisible friend was apparently talking to you again. But still my question remains where the heck is Yours?

More proof that you can not read the documents handed to you.

Listed between Iomega and LSI Logic

But know I will not allow you to torque me anymore.
You will get a patch that effectively removes the patch submitted to for 2.5.3. Unfortunately all the functionality will be gone too, so the driver will be crippled again and that is saddening.

Regards,

Andre Hedrick
The Second Linux X-IDE guy

Martin Dalecki

2002-03-11 19:32 UTC #123 lore raw

Re: [PATCH] 2.5.6 IDE 19

Quoted 5 lines · Andre Hedrick

Quoted 2 lines · Martin Dalecki
Quoted 2 lines
http://www.t13.org/ballots/e01028r0.pdf

Quoted 8 lines

Quoted 6 lines
Quoted 2 lines
I do not see your name on that list for the ballot.
I didn't claim too. Your invisible friend was apparently talking to you again. But still my question remains where the heck is Yours?
More proof that you can not read the documents handed to you.

That is only a list of voters over the document there. This doesn't imply that you co-authored it.
And finally this isn't a voting over the standard itself but rather about the submission of a draft to the standard body.

(Clear thinking can be pesky isn't it?)

Quoted 6 lines

Listed between Iomega and LSI Logic
But know I will not allow you to torque me anymore.
You will get a patch that effectively removes the patch submitted to for 2.5.3. Unfortunately all the functionality will be gone too, so the driver will be crippled again and that is saddening.

Thank you very much right now I can do a diff between 2.5.3 and 2.5.4 myself actually. I would be rather interrested in the "plain interface" without any parsing in between.
(Which is the reason I didn't remove the parse code thus far...).

Andre Hedrick

2002-03-11 19:36 UTC #124 lore raw

Re: [PATCH] 2.5.6 IDE 19

Quoted 8 lines · Martin Dalecki

That is only a list of voters over the document there. This doesn't imply that you co-authored it.
And finally this isn't a voting over the standard itself but rather about the submission of a draft to the standard body.
(Clear thinking can be pesky isn't it?)

You deserve to be the Maintainer, You have even out classed me in being a total ASS and that is mighty hard to do. You have ONE-UPED-ME. I am impressed.

Quoted 11 lines

Quoted 6 lines
Listed between Iomega and LSI Logic
But know I will not allow you to torque me anymore.
You will get a patch that effectively removes the patch submitted to for 2.5.3. Unfortunately all the functionality will be gone too, so the driver will be crippled again and that is saddening.
Thank you very much right now I can do a diff between 2.5.3 and 2.5.4 myself actually. I would be rather interrested in the "plain interface" without any parsing in between.
(Which is the reason I didn't remove the parse code thus far...).

You are the Maintainer go take it out yourself unless you need help. Oh, I forgot you did ask for help ... my bad.

Regards,

Andre

Davide Libenzi

2002-03-11 19:47 UTC #125 lore raw

Re: [PATCH] 2.5.6 IDE 19

Quoted 21 lines · Andre Hedrick

Quoted 8 lines · Martin Dalecki
That is only a list of voters over the document there. This doesn't imply that you co-authored it.
And finally this isn't a voting over the standard itself but rather about the submission of a draft to the standard body.
(Clear thinking can be pesky isn't it?)
You deserve to be the Maintainer, You have even out classed me in being a total ASS and that is mighty hard to do. You have ONE-UPED-ME. I am impressed.
Quoted 7 lines
Quoted 6 lines
Listed between Iomega and LSI Logic
But know I will not allow you to torque me anymore.
You will get a patch that effectively removes the patch submitted to for 2.5.3. Unfortunately all the functionality will be gone too, so the driver will be crippled again and that is saddening.

Quoted 7 lines

Quoted 4 lines
Thank you very much right now I can do a diff between 2.5.3 and 2.5.4 myself actually. I would be rather interrested in the "plain interface" without any parsing in between.
(Which is the reason I didn't remove the parse code thus far...).
You are the Maintainer go take it out yourself unless you need help. Oh, I forgot you did ask for help ... my bad.

When you guys finished beating each other would you mind trying to solve the IDE timer issue that still hit my 2.5.6 ( not pre3 Linus sorry, i swear i didn't drink :) ). Please ...

- Davide

Andre Hedrick

2002-03-11 19:52 UTC #126 lore raw

Re: [PATCH] 2.5.6 IDE 19

Quoted 6 lines · Davide Libenzi

Quoted 2 lines
You are the Maintainer go take it out yourself unless you need help. Oh, I forgot you did ask for help ... my bad.
When you guys finished beating each other would you mind trying to solve the IDE timer issue that still hit my 2.5.6 ( not pre3 Linus sorry, i swear i didn't drink :) ). Please ...

Yes I will fix it, since I am the only one here that can or at least will admit to being able to fix it.

Andre Hedrick
Linux Disk Certification Project Linux ATA Development

Rik van Riel

2002-03-11 21:20 UTC #127 lore raw

Re: [PATCH] 2.5.6 IDE 19

In reply to Davide Libenzi

Quoted 3 lines · Davide Libenzi

When you guys finished beating each other would you mind trying to solve the IDE timer issue that still hit my 2.5.6 ( not pre3 Linus sorry, i swear i didn't drink :) ). Please ...

Personally I've given up on using 2.5 on my machines.

regards,

Rik

Signature · 3 lines

<insert bitkeeper endorsement here>

http://www.surriel.com/		http://distro.conectiva.com/

Davide Libenzi

2002-03-11 22:41 UTC #128 lore raw

Re: [PATCH] 2.5.6 IDE 19

Quoted 7 lines · Rik van Riel

Quoted 3 lines · Davide Libenzi
When you guys finished beating each other would you mind trying to solve the IDE timer issue that still hit my 2.5.6 ( not pre3 Linus sorry, i swear i didn't drink :) ). Please ...
Personally I've given up on using 2.5 on my machines.

But if noones is using/testing 2.5.x we'll be using 2.4.x forever :-) ... and i kind of like the behavior of 2.5.x ...

- Davide

David Ford

2002-03-13 19:21 UTC #129 lore raw

Re: [PATCH] 2.5.6 IDE 19

I'll test 2.5 when buslogic gets functional :)

-d

Quoted 6 lines · Davide Libenzi

Quoted 2 lines
Personally I've given up on using 2.5 on my machines.
But if noones is using/testing 2.5.x we'll be using 2.4.x forever :-) ... and i kind of like the behavior of 2.5.x ...

Jos Hulzink

2002-03-12 00:00 UTC #130 lore raw

Re: [PATCH] 2.5.6 IDE 19

In reply to Rik van Riel

Quoted 1 line · Rik van Riel

Personally I've given up on using 2.5 on my machines.

Gee... and I should trust my 80 GB of IDE disks to mud-throwing kiddies like you guys ? I was working on some FAT enhancements in the 2.5 tree, but I agree with Rik. Maybe I should just forget 2.5.

Jos

Andre Hedrick

2002-03-12 05:19 UTC #131 lore raw

Re: [PATCH] 2.5.6 IDE 19

In reply to Rik van Riel

Please drop me off the thread I am not the Maintainer for 2.5

Regards,

Andre Hedrick
Linux Disk Certification Project Linux ATA Development

Quoted 16 lines · Rik van Riel

Quoted 3 lines · Davide Libenzi
When you guys finished beating each other would you mind trying to solve the IDE timer issue that still hit my 2.5.6 ( not pre3 Linus sorry, i swear i didn't drink :) ). Please ...
Personally I've given up on using 2.5 on my machines.
regards,
Rik
Signature · 3 lines
<insert bitkeeper endorsement here>

http://www.surriel.com/		http://distro.conectiva.com/

Russell King

2002-03-11 19:28 UTC #132 lore raw

Re: [PATCH] 2.5.6 IDE 19

Quoted 3 lines · Martin Dalecki

I didn't claim too. Your invisible friend was apparently talking to you again. But still my question remains where the heck is Yours?

Martin,

Please calm down.

When you're calm, go to the URL Andre gave, download the document and *read* it. You *will* find his name there, whether he was there, and what vote he cast.

How do I know? I've done just that.

So, both of you stop flaming and get back on to technical issues.

Signature · 2 lines

Russell King ([email protected])                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Vojtech Pavlik

2002-03-11 22:02 UTC #133 lore raw

Re: [PATCH] 2.5.6 IDE 19

Quoted 9 lines · Anton Altaparmakov

Quoted 6 lines · Alan Cox
Quoted 3 lines
Funny you should mention that point ... The "flagged taskfile code" is a project to allow for NATIVE DFT support in Linux. Nice screw job you did to IBM.
Ok so whats native DFT and where does he (and I for that matter) read about it ?
DFT = Drive Fault Tolerance

Hmmm, I thought it was Drive Fitness test. TLAs ...

Quoted 2 lines

It is an IBM utility which performs extensive diagnostics of a hard drive. At present this is a DOS program which is used via a dos boot disk.

Which is quite enough as it is. Anyway, the diagnostics consist mostly of S.M.A.R.T commands plus some seeking and linear reading of the surface.

Quoted 11 lines

Have look at the IBM website where you can download this (you can get a dd image of the boot floppy from there, too, if you don't have Windows).
The idea behind native DFT is to be able to perform drive diagnostics from within the OS without rebooting with a DOS disk and tying up the system for hours during the checks. The advantages of this combined with IDE/SCSI hot swap are strikingly obvious...
The utility also returns a special fault code which in combination with the ibm website allows you to return a faulty disk and obtain a replacement very easily.

Hmm. I stopped believing in the usefulness of the IBM DFT after my IBM drive started giving unrecoverable errors reading my swap partition and the DFT said that everything was OK later when I ran it ...

Signature · 2 lines

Vojtech Pavlik
SuSE Labs

Anton Altaparmakov

2002-03-11 22:09 UTC #134 lore raw

Re: [PATCH] 2.5.6 IDE 19

Quoted 8 lines · Vojtech Pavlik

Quoted 2 lines · Anton Altaparmakov
Quoted 1 line · Alan Cox
Quoted 1 line
Funny you should mention that point ... The "flagged taskfile code"
is a
Quoted 1 line
Quoted 1 line
Quoted 1 line
project to allow for NATIVE DFT support in Linux. Nice screw job
you did
Quoted 2 lines
Quoted 2 lines
Quoted 1 line
to IBM.

Quoted 7 lines

Quoted 1 line
Quoted 1 line
Ok so whats native DFT and where does he (and I for that matter) read
about
Quoted 3 lines
Quoted 1 line
it ?
DFT = Drive Fault Tolerance
Hmmm, I thought it was Drive Fitness test. TLAs ...

Yes, sorry. I had a dim moment... You are of course right.

Quoted 15 lines

Quoted 2 lines
It is an IBM utility which performs extensive diagnostics of a hard drive. At present this is a DOS program which is used via a dos boot disk.
Which is quite enough as it is. Anyway, the diagnostics consist mostly of S.M.A.R.T commands plus some seeking and linear reading of the surface.
Quoted 8 lines
Have look at the IBM website where you can download this (you can get a dd image of the boot floppy from there, too, if you don't have Windows).
The idea behind native DFT is to be able to perform drive diagnostics from within the OS without rebooting with a DOS disk and tying up the system for hours during the checks. The advantages of this combined with IDE/SCSI hot swap are strikingly obvious...

Quoted 7 lines

Quoted 3 lines
The utility also returns a special fault code which in combination with the ibm website allows you to return a faulty disk and obtain a replacement very easily.
Hmm. I stopped believing in the usefulness of the IBM DFT after my IBM drive started giving unrecoverable errors reading my swap partition and the DFT said that everything was OK later when I ran it ...

Has worked well for a couple of times... (the extended tests anyway, the basic test always succeeds for me). DFT was detecting problems (and I was running it as I was having problems in Linux), then I upgraded the firmware and it no longer detected problems (and the drives have worked happily ever after). So I guess it just not perfect but it certainly worked for me.

Anton

Signature · 5 lines

  "I've not lost my mind. It's backed up on tape somewhere." - Unknown
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Linux NTFS Maintainer / WWW: http://linux-ntfs.sf.net/
ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/

Joachim Breuer

2002-03-12 08:59 UTC #135 lore raw

Re: [PATCH] 2.5.6 IDE 19

Quoted 11 lines · Vojtech Pavlik

Quoted 9 lines · Anton Altaparmakov
Quoted 6 lines · Alan Cox
Quoted 3 lines
Funny you should mention that point ... The "flagged taskfile code" is a project to allow for NATIVE DFT support in Linux. Nice screw job you did to IBM.
Ok so whats native DFT and where does he (and I for that matter) read about it ?
DFT = Drive Fault Tolerance

Quoted 7 lines

Hmmm, I thought it was Drive Fitness test. TLAs ...
[...]
Hmm. I stopped believing in the usefulness of the IBM DFT after my IBM drive started giving unrecoverable errors reading my swap partition and the DFT said that everything was OK later when I ran it ...

Happened to me *more than once*. Every single time: Drive has what looks like "Surface Errors" to the OS, SMART thinks the drive is dandy, DFT thinks the drive is dandy and after using the DFT "erase" feature it would even work (on the whole surface) again. Question only remains for how long. My dealer usually gives me a replacement disk when I tell him "this one's bogus" even if it doesn't show any immediate errors in DFT and similar tests, but I'm sure not everyone's that lucky.

I don't usually bash manufacturers, but with recent (> 10GB) IBM ATA-33+ drives I've experienced this behaviour in well above 50% of all units I've seen. The MTBF on their SCA LVD ones doesn't make me squirm with delight either, but those a) don't lie about being broken and b) tend to be easier to replace.

So long,
Joe

Signature · 3 lines

"I use emacs, which might be thought of as a thermonuclear
 word processor."
-- Neal Stephenson, "In the beginning... was the command line"

Bill Davidsen

2002-03-12 00:50 UTC #136 lore raw

Re: [PATCH] 2.5.6 IDE 19

Quoted 5 lines · Martin Dalecki

Quoted 3 lines · Alan Cox
Oh dear me. Wrong again. Microdrives require proper polite wakeups. But you see camera vendors buy in IDE code from people who can read and follow standards documents.

This seems relevant in light of:

	[snip]

Quoted 2 lines

Fsck let's cite the IBM appilcation notes about the Micro Drive found here http://www.storage.ibm.com/hdd/micro/appguide.htm

[snip, but relevant]

Quoted 20 lines

* Consideration for a time-out value when using the write cache
The microdrive can queue several consecutive write commands. Even if the host system receives a
command completion, the microdrive may still be performing disk writing for queued commands, each of
which could take up to 7.5 seconds as previously mentioned if an error has occurred and an error
recovery routine starts.
This delay eventually surfaces when processing a first non-queued command during write cache.
For example, suppose the microdrive queues 2 write commands and each command takes 7.5 seconds
for some extreme reason. Then if the microdrive receives Read Sectors, which is a non-queue command,
it will be processed just after disk writing is completed. In the worst case, delay for the Read Sectors
would be close to 15 seconds (7.5 x 2).

Quoted 7 lines

In light of the stuation above, IBM recommends 30 seconds as a time-out value if the host system uses
the write cache feature.
And apparently we see that there is nothing special about them... Just don't enable the write cache and all should be well with a timeout of 30 seconds.

How can you read that recommendation into what you just quoted? IBM says use 30 sec if you enable write buffers, why would eliminate the long delay but use the slow timeout anyway? To slow retry to a crawl? It would seem obvious to do one thing or the other, but not to take all possible action to make things crawl. I suggest that the obvious solution is use a sensible timeout without write buffers to be really safe, or to get best performance use the write buffers and force a flush at a sensible point, somewhat like flushing buffers to disk with bdflush. There are already spindown timers and such in the drivers, this isn't a "whole new thing."

Since we have the ability to let the user set this now, I see no reason not to let the user make the choice, Linux is about choice.

Finally, about copying other drivers: to quote my youngest, "yuckie-poo!" Drivers should be written to the standard, with reality dictating that it is sometimes required to write to the hardware when you absolutely MUST use non-compliant hardware. To copy code from another driver seems like a lack or either ability or committment.

Signature · 3 lines

bill davidsen <[email protected]>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Pavel Machek

2002-03-12 23:08 UTC #137 lore raw

Re: [PATCH] 2.5.6 IDE 19

Hi!

Quoted 6 lines

Because its standards compliant. It wasnt written by a half clued wannabe who has never read the manuals and can do nothing but call people who have a "liar". And a standards compliant implementation does all the right power management commands. Win 98 didnt quite get it right and you'll find one of the updates addresses IDE problems. Ironically fixing the same flush cache and shut down politely problem you plan to break in Linux

He is not breaking anything.

Just now linux will happily suspend in the middle of read command, then wake up, get spurious interrupt, say "I'm happy read finished", and corrupt data. What's there is first step in getting it right, and more steps are needed.

NOTICE NOTICE NOTICE: unless you are using S3/S4, that change is a NOP. On 2.4.18 you can't use S3/S4, so it is definitely NOP for you. Will not eat your data.
Pavel

Signature · 2 lines

Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.

Arjan van de Ven

2002-03-11 17:53 UTC #138 lore raw

Re: [PATCH] 2.5.6 IDE 19

Quoted 3 lines

And apparently we see that there is nothing special about them... Just don't enable the write cache and all should be well with a timeout of 30 seconds.

Quite a few controllers enable the write cache in their bootstrap before the OS gets involved.
Just "don't enable" is not an option.

Rik van Riel

2002-03-11 21:03 UTC #139 lore raw

Re: [PATCH] 2.5.6 IDE 19

Quoted 6 lines · Arjan van de Ven

Quoted 2 lines
And apparently we see that there is nothing special about them... Just don't enable the write cache and all should be well with a timeout of 30 seconds.
Quite a few controllers enable the write cache in their bootstrap before the OS gets involved.
Just "don't enable" is not an option.

I've heard some talk about drives that turn it on
automatically when they get "too busy".

regards,

Rik

Signature · 3 lines

<insert bitkeeper endorsement here>

http://www.surriel.com/		http://distro.conectiva.com/

Alan Cox

2002-03-11 22:29 UTC #140 lore raw

Re: [PATCH] 2.5.6 IDE 19

Quoted 5 lines

Quoted 2 lines
the OS gets involved.
Just "don't enable" is not an option.
I've heard some talk about drives that turn it on
automatically when they get "too busy".

Its also a pain because some drives seem to drop into snail racing mode when you turn it off

Martin Dalecki

2002-03-11 19:05 UTC #141 lore raw

Re: [PATCH] 2.5.6 IDE 19

Quoted 7 lines · Arjan van de Ven

Quoted 3 lines
And apparently we see that there is nothing special about them... Just don't enable the write cache and all should be well with a timeout of 30 seconds.
Quite a few controllers enable the write cache in their bootstrap before the OS gets involved.
Just "don't enable" is not an option.

Right. But that can be already handled by the hdparm utility at boot. Please note as well that the controller we are talking about is basically the CardBus PCI-ISA bridge kind of ;-).
It doesn't do much setup. (Fingers corssed becouse I didn't check the cs code thus far.)

Pavel Machek

2002-03-12 23:08 UTC #142 lore raw

Re: [PATCH] 2.5.6 IDE 19

Hi!

Quoted 11 lines

Quoted 7 lines
the WB
caches of IDE devices are not caches in the sense of a MESI cache,
they are
more like buffer caches and should therefore flush them self after s
short
period of inactivity without the application of any special flush
command.
You now have an absolute vote of *NO CONFIDENCE* on my part. I'm simply not going to consider running your code. "It probably wont eat your disk" and handwaving is not how you write a block layer.

This is S3/S4 support. Not used during normal operation. S3/S4 without this is as dangerous as "oops, we've written wrong data to wrong place, without even knowing that". With this, the problem is "maybe your hdd is not initialized properly, so you lost ability to talk to it".

Quoted 2 lines

How is anyone supposed to debug file system code in 2.5 when its known that it will trash data on some disks anyway ? I'd like to see you cite

It will not. This is only used when ACPI suspend-to-disk/suspend-to-ram is used (and at that time, you have worse problems than IDE driver).
Pavel

Signature · 2 lines

Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.

Martin Dalecki

2002-03-13 14:16 UTC #143 lore raw

PATCH 1/1 IDE 21

If I was to give this patch a name it would be:

"Vojtech Pavlik unleashed from the chains".

So credit where credit is due :-).

BTW> There never was any ide-clean-20.
I have compressed it just to get it through linux-kernel, becouse I would rather like it to reach any interrested party. Please excuse me for the inconvenience.

Anyway here follows the change log:

Mon Mar 11 23:48:28 CET 2002 ide-clean-21

- Swallow rewritten amd74xx host chip setup code from Vojtech Pavlik. We can revert it easly if it turns out to be a bad thing. However the code looks quite sane to me. In esp. it doesn't containg that many magic numbers.

- Clean stale white spaces in ide-timing.h tirvial fix.

- Make ide_release_dma return void. It's value is never used anyway.

- Swallow more timing setup code cleanup by Vojtech Pavlik. Apply some cosmetics to it. Port opti621 to the new setup code.

- Kill abuse of ide_do_reset() on error return paths for atapi floppy tape and cd-rom devices. Just stop them. This gives better changes that defect removable media will not cause suddenly broken timings on hard discs containing system data! Even then comments in ide_do_reset() admit, that resetting the whole channel can have adverse effects on the second interface on this channel. And I have too frequently observed linux struggling on defect cd-rom for a far too long time to wish it to continue.

Oh did I forget to say that the corresponding "how can I break my system fast and reliable" ioctl is gone as well?

Removing it recovered the fact that the CONFIG_BLK_DEV_IDEDMA_TIMEOUT is completely bogous. I have removed this option therefore as well, because it's playing the same wrack havoc on the devices if enabled. This cat has been in an unfinished and *unfunctional* state anyway.

- Actually add physical suspend code to the power handling code. Still the resume code isn't finished just jet. This is all subject to change at the point in time when we get to proper command queueing.
I think however that Pavel will be interrested in tidding this bit up...

- Resync with 2.5.7-pre1.

Vojtech Pavlik

2002-03-13 17:42 UTC #144 lore raw

Re: [PATCH] IDE 21

Quoted 5 lines · Martin Dalecki

If I was to give this patch a name it would be:
"Vojtech Pavlik unleashed from the chains".
So credit where credit is due :-).

For bugs as well. :(

In the FIT macro in ide-timing.h the argument got swapped because of a typo. All timings generated for VIA and AMD chips are wrong because of that. Safe, though, but slow.

Signature · 2 lines

Vojtech Pavlik
SuSE Labs

Jens Axboe

2002-02-22 10:12 UTC #145 lore raw

Re: Flash Back -- kernel 2.1.111

Quoted 8 lines · Rik van Riel

Quoted 5 lines · Andre Hedrick
Please allow him to UPDATE and correct the SCSI core, also. I was joking with Christoph Hellwig about his work on the SCSI API, suggested he work with Martin to accellerate the rewrite. So I am inviting Martin to assist in the SCSI directory and any other place you needs such an incredible grasp of your "DARWINISM" v/s logical "DESIGN".

Quoted 5 lines

Martin,
please tell us up-front if you are able to make Linux work with 48-bit IDE stuff so Linux is able to talk to drives larger than 137 GB.

2.5 already supports 48-bit lba addressing.

Signature · 1 line

Jens Axboe

David S. Miller

2002-02-22 10:39 UTC #146 lore raw

Re: Flash Back -- kernel 2.1.111

From: Andre Hedrick <[email protected]>
Date: Fri, 22 Feb 2002 01:25:36 -0800 (PST)

I refuse to fix this mess.

Andre, go take a nap or something and come back when you're not in whining mode ok?

If you can't handle someone else doing cleanups of a subsystem you happen to maintain, GO FIND ANOTHER PROJECT TO WORK ON.

Because nobody owns any particular piece of code in that way, plain and simple. I used to think I could whine when people put in cleanups of the networking behind my back, I WAS WRONG. Just like you are wrong.

All of the cleanup changesets from Martin I saw go in were just fine anyways.

If you can't be bothered to handle the conflicts introduced by such cleanups, that is your problem. And finally your mouth is much larger than the code you write. So you might want to work on that ratio a little bit.

Pedro M. Rodrigues

2002-02-22 10:14 UTC #147 lore raw

Re: Flash Back -- kernel 2.1.111

I checked Microsoft's proposal recently. Didn't see see anything
devastating, could you please enlighten me on this one?

Thanks,
Pedro

Quoted 4 lines · Andre Hedrick

continue to lobby for modification the Microsoft Proposal of a new command, Force Unit Access, as make the Journaling File Systems stable. Especially since their proposal and usage of the command under EXT3/Reiser/XFS/etc would damage the data.

Andre Hedrick

2002-02-22 19:16 UTC #148 lore raw

Re: Flash Back -- kernel 2.1.111

Quoted 3 lines · Pedro M. Rodrigues

I checked Microsoft's proposal recently. Didn't see see anything
devastating, could you please enlighten me on this one?

Does forcing a command to bypass the contents in the cache meaning anything. This is not a cache sync like SCSI. It is a cache bypass and will violate the journal on the down/commit block.

Quoted 12 lines

Thanks,
Pedro
Quoted 4 lines · Andre Hedrick
continue to lobby for modification the Microsoft Proposal of a new command, Force Unit Access, as make the Journaling File Systems stable. Especially since their proposal and usage of the command under EXT3/Reiser/XFS/etc would damage the data.

Andre Hedrick
Linux Disk Certification Project Linux ATA Development

Alan Cox

2002-02-22 19:43 UTC #149 lore raw

Re: Flash Back -- kernel 2.1.111

Quoted 3 lines

Does forcing a command to bypass the contents in the cache meaning anything. This is not a cache sync like SCSI. It is a cache bypass and will violate the journal on the down/commit block.

Thats a really useful option for a whole load of operations. Database folk in paticular may well benefit as will O_DIRECT stuff

Andre Hedrick

2002-02-22 19:52 UTC #150 lore raw

Re: Flash Back -- kernel 2.1.111

Quoted 7 lines · Alan Cox

Quoted 3 lines
Does forcing a command to bypass the contents in the cache meaning anything. This is not a cache sync like SCSI. It is a cache bypass and will violate the journal on the down/commit block.
Thats a really useful option for a whole load of operations. Database folk in paticular may well benefit as will O_DIRECT stuff

I agree that command mode has a proper use but the goal was to add in write ordering barrier operations w/ a setfeature to modify the behavior of the command.

Cheers,

Andre Hedrick
Linux Disk Certification Project Linux ATA Development

Jeff Garzik

2002-02-21 10:53 UTC #151 lore raw

Re: [PATCH] 2.5.5 IDE cleanup 11

Quoted 9 lines

(quoted diff) +0 -1

@@ -2929,7 +2928,6 @@
        capacity:               ide_cdrom_capacity,
        special:                NULL,
        proc:                   NULL,
-       driver_init:            ide_cdrom_init,
        driver_reinit:          ide_cdrom_reinit,
 };

Review line 2971

Quoted 8 lines

(quoted diff) +1 -1

@@ -2967,7 +2965,7 @@
        DRIVER(drive)->busy--;
        failed--;
 
-       ide_register_module(&ide_cdrom_driver);
+       revalidate_drives();
        MOD_DEC_USE_COUNT;
        return 0;
 }

hum, I'm not sure that removing ->driver_init is a good idea.

Seems like a loss of flexibility to me, not a cleanup, and I wonder if you have thought through all the paths that wind up calling ->driver_init.

Jeff

Signature · 4 lines

Jeff Garzik      | "Why is it that attractive girls like you
Building 1024    |  always seem to have a boyfriend?"
MandrakeSoft     | "Because I'm a nympho that owns a brewery?"
                 |             - BBC TV show "Coupling"

Andre Hedrick

2002-02-21 11:19 UTC #152 lore raw

Re: [PATCH] 2.5.5 IDE cleanup 11

Quoted 20 lines · Jeff Garzik

Quoted 9 lines

(quoted diff) +0 -1

@@ -2929,7 +2928,6 @@
        capacity:               ide_cdrom_capacity,
        special:                NULL,
        proc:                   NULL,
-       driver_init:            ide_cdrom_init,
        driver_reinit:          ide_cdrom_reinit,
 };

Review line 2971

Quoted 8 lines

(quoted diff) +1 -1

@@ -2967,7 +2965,7 @@
        DRIVER(drive)->busy--;
        failed--;
 
-       ide_register_module(&ide_cdrom_driver);
+       revalidate_drives();
        MOD_DEC_USE_COUNT;
        return 0;
 }

hum, I'm not sure that removing ->driver_init is a good idea.

Quoted 3 lines

Seems like a loss of flexibility to me, not a cleanup, and I wonder if you have thought through all the paths that wind up calling ->driver_init.

Nah, go ahead add it.

I have been meaning to start another driver from scratch that is fully threaded IO and can deal with register core operations independent of the how the arch calls the transport.

Cheers,

Andre Hedrick
Linux Disk Certification Project Linux ATA Development

Martin Dalecki

2002-02-21 17:28 UTC #153 lore raw

Re: [PATCH] 2.5.5 IDE cleanup 11

Quoted 5 lines

hum, I'm not sure that removing ->driver_init is a good idea.
Seems like a loss of flexibility to me, not a cleanup, and I wonder if you have thought through all the paths that wind up calling ->driver_init.

Yes I have tought it all through!
Please trust me - I eat at least myself my dog-food.

And the driver_init function is something which where currently just the bloody module initialization function get's called a seond time - and this is just plain wrong.

If I hadn't tought about it I wouldn't be that advantegrous. And my testing of it did consist of the following:

1. 2 x IDE drives of one IDE port.

2. 1 x CD-RW on a second port - modularized.

3. 1 x CarBus to CF adapter.

It all worked well after the removal!

Alan Cox

2002-02-21 17:39 UTC #154 lore raw

Re: [PATCH] 2.5.5 IDE cleanup 11

Quoted 6 lines

If I hadn't tought about it I wouldn't be that advantegrous. And my testing of it did consist of the following:
1. 2 x IDE drives of one IDE port.
2. 1 x CD-RW on a second port - modularized.
3. 1 x CarBus to CF adapter.

So you didnt test or consider the upcoming things like hotplug.

I'm sure the cleanup works now, but imagine if I was to "clean up" Jens new block code by removing all the stuff he has there ready for next features.

Martin Dalecki

2002-02-21 17:59 UTC #155 lore raw

Re: [PATCH] 2.5.5 IDE cleanup 11

Quoted 9 lines · Alan Cox

Quoted 7 lines
If I hadn't tought about it I wouldn't be that advantegrous. And my testing of it did consist of the following:
1. 2 x IDE drives of one IDE port.
2. 1 x CD-RW on a second port - modularized.
3. 1 x CarBus to CF adapter.
So you didnt test or consider the upcoming things like hotplug.

I did plugging and unplugging a CardBus IDE contoller in and out on a hot system.

Quoted 3 lines

I'm sure the cleanup works now, but imagine if I was to "clean up" Jens new block code by removing all the stuff he has there ready for next features.

Well the hotplug/suspension problem is certinaly to be targetted by using the struct device_driver infrastructure and not by reduplicating it's fuctionality inside ide.c. Agreed? Before one could even thing about this the splitting between ide_driver_t and ide_module_t *had* to
be removed.

Just have a look at the massive code duplication between init_module and driver_reinit functions inside the subdrivers to see why this is.

Before this can happen one has to untagle the flow of the current
driver. Like for exampel double calls to module initialization functions. The device detection part *has* to be pulled out from the corresponding module initialization routines - yes I'm aware of this. But I would rathter like them to find they home inside the following:

struct device_driver {
        int     (*probe)        (struct device *dev);
        int     (*remove)       (struct device *dev);

        int     (*suspend)      (struct device *dev, u32 state, u32 level);
        int     (*resume)       (struct device *dev, u32 level);
}

instead of ide_driver_t ide_hwif_t or whatever the ide-typdef of the day is.

Finally: Before something can go in - well something has to go out. In esp. if it is in the way and the removal doesn't cause any loss modulo current functionality.

This is the reaons of the FIXME notes I have itroduced here and there inside the patch as well.

But currently one has to fight far too frequently with functions which are exported without any justification or different functions which basically just do the same, games on ifdef's inside headers and so on...

Alan Cox

2002-02-21 18:01 UTC #156 lore raw

Re: [PATCH] 2.5.5 IDE cleanup 11

Quoted 4 lines

Quoted 1 line
So you didnt test or consider the upcoming things like hotplug.
I did plugging and unplugging a CardBus IDE contoller in and out on a hot system.

IDE hotplug is device level (hence you want ->present)

Quoted 2 lines

using the struct device_driver infrastructure and not by reduplicating it's fuctionality inside ide.c. Agreed? Before one could even thing

Not agreed - its a layer lower I'm talking about

Martin Dalecki

2002-02-21 18:46 UTC #157 lore raw

Re: [PATCH] 2.5.5 IDE cleanup 11

Quoted 6 lines · Alan Cox

Quoted 5 lines
Quoted 2 lines
So you didnt test or consider the upcoming things like hotplug.
I did plugging and unplugging a CardBus IDE contoller in and out on a hot system.

Quoted 7 lines

IDE hotplug is device level (hence you want ->present)
Quoted 2 lines
using the struct device_driver infrastructure and not by reduplicating it's fuctionality inside ide.c. Agreed? Before one could even thing
Not agreed - its a layer lower I'm talking about

Then please tell me why the sudden /dev/hdc -> /dev/hde name change occured?

I state - *neither* level get's handled properly now.

Pavel Machek

2002-02-22 15:54 UTC #158 lore raw

Re: [PATCH] 2.5.5 IDE cleanup 11

Hi!

Quoted 11 lines

Quoted 4 lines
Quoted 1 line
So you didnt test or consider the upcoming things like hotplug.
I did plugging and unplugging a CardBus IDE contoller in and out on a hot system.
IDE hotplug is device level (hence you want ->present)
Quoted 2 lines
using the struct device_driver infrastructure and not by reduplicating it's fuctionality inside ide.c. Agreed? Before one could even thing
Not agreed - its a layer lower I'm talking about

I want both "ide controller" *and* "ide disk" to have struct device. And my patches do exactly that, see:

Pavel

drivers/ide/ide-disk.c +14 -0

@@ -925,12 +925,16 @@
 	ide_add_setting(drive,	"max_failures",		SETTING_RW,					-1,			-1,			TYPE_INT,	0,	65535,				1,	1,	&drive->max_failures,		NULL);
 }
 
+static struct device_driver idedisk_device_driver = {
+};
+
 static void idedisk_setup (ide_drive_t *drive)
 {
 	int i;
 	
 	struct hd_driveid *id = drive->id;
 	unsigned long capacity;
+	int myid = -1;
 	
 	idedisk_add_settings(drive);

@@ -953,11 +957,20 @@
 		ide_hwif_t *hwif = HWIF(drive);
 
 		if (drive != &hwif->drives[i]) continue;
+		myid = i;
 		hwif->gd->de_arr[i] = drive->de;
 		if (drive->removable)
 			hwif->gd->flags[i] |= GENHD_FL_REMOVABLE;
 		break;
 	}
+	{
+		ide_hwif_t *hwif = HWIF(drive);
+		sprintf(drive->device.bus_id, "%d", myid);
+		sprintf(drive->device.name, "ide-disk");
+		drive->device.driver = &idedisk_device_driver;
+		drive->device.parent = &hwif->device;
+		device_register(&drive->device);
+	}
 
 	/* Extract geometry if we did not already have one for the drive */
 	if (!drive->cyl || !drive->head || !drive->sect) {

@@ -1033,6 +1046,7 @@
 
 static int idedisk_cleanup (ide_drive_t *drive)
 {
+	put_device(&drive->device);
 	if ((drive->id->cfs_enable_2 & 0x3000) && drive->wcache)
 		if (do_idedisk_flushcache(drive))
 			printk (KERN_INFO "%s: Write Cache FAILED Flushing!\n",

drivers/ide/ide-pnp.c +3 -1

@@ -57,6 +57,7 @@
 static int __init pnpide_generic_init(struct pci_dev *dev, int enable)
 {
 	hw_regs_t hw;
+	ide_hwif_t *hwif;
 	int index;
 
 	if (!enable)

@@ -69,9 +70,10 @@
 			generic_ide_offsets, (ide_ioreg_t) DEV_IO(dev, 1),
 			0, NULL, DEV_IRQ(dev, 0));
 
-	index = ide_register_hw(&hw, NULL);
+	index = ide_register_hw(&hw, &hwif);
 
 	if (index != -1) {
+		hwif->pci_dev = dev;
 	    	printk("ide%d: %s IDE interface\n", index, DEV_NAME(dev));
 		return 0;
 	}

drivers/ide/ide-probe.c +9 -0

@@ -46,6 +46,7 @@
 #include <linux/delay.h>
 #include <linux/ide.h>
 #include <linux/spinlock.h>
+#include <linux/pci.h>
 
 #include <asm/byteorder.h>
 #include <asm/irq.h>

@@ -469,6 +470,14 @@
 
 static void hwif_register (ide_hwif_t *hwif)
 {
+	sprintf(hwif->device.bus_id, "%04x", hwif->io_ports[IDE_DATA_OFFSET]);
+	sprintf(hwif->device.name, "ide");
+	hwif->device.driver_data = hwif;
+	if (hwif->pci_dev)
+		hwif->device.parent = &hwif->pci_dev->dev;
+	else
+		hwif->device.parent = NULL; /* Would like to do = &device_legacy */
+	device_register(&hwif->device);
 	if (((unsigned long)hwif->io_ports[IDE_DATA_OFFSET] | 7) ==
 	    ((unsigned long)hwif->io_ports[IDE_STATUS_OFFSET])) {
 		ide_request_region(hwif->io_ports[IDE_DATA_OFFSET], 8, hwif->name);

drivers/ide/ide.c +3 -5

@@ -143,9 +143,7 @@
 #include <linux/genhd.h>
 #include <linux/blkpg.h>
 #include <linux/slab.h>
-#ifndef MODULE
 #include <linux/init.h>
-#endif /* MODULE */
 #include <linux/pci.h>
 #include <linux/delay.h>
 #include <linux/ide.h>

@@ -153,6 +151,8 @@
 #include <linux/completion.h>
 #include <linux/reboot.h>
 #include <linux/cdrom.h>
+#include <linux/device.h>
+#include <linux/kmod.h>
 
 #include <asm/byteorder.h>
 #include <asm/irq.h>

@@ -162,9 +162,6 @@
 
 #include "ide_modes.h"
 
-#ifdef CONFIG_KMOD
-#include <linux/kmod.h>
-#endif /* CONFIG_KMOD */
 
 /* default maximum number of failures */
 #define IDE_DEFAULT_MAX_FAILURES 	1

@@ -2027,6 +2024,7 @@
 	hwif = &ide_hwifs[index];
 	if (!hwif->present)
 		goto abort;
+	put_device(&hwif->device);
 	for (unit = 0; unit < MAX_DRIVES; ++unit) {
 		drive = &hwif->drives[unit];
 		if (!drive->present)

include/linux/ide.h +6 -3

@@ -14,6 +14,7 @@
 #include <linux/blkdev.h>
 #include <linux/proc_fs.h>
 #include <linux/devfs_fs_kernel.h>
+#include <linux/device.h>
 #include <asm/hdreg.h>
 
 /*

@@ -424,12 +425,12 @@
 	unsigned long	capacity;	/* total number of sectors */
 	unsigned long long capacity48;	/* total number of sectors */
 	unsigned int	drive_data;	/* for use by tuneproc/selectproc as needed */
-	void		  *hwif;	/* actually (ide_hwif_t *) */
+	struct hwif_s   *hwif;	/* actually (ide_hwif_t *) */
 	wait_queue_head_t wqueue;	/* used to wait for drive in open() */
 	struct hd_driveid *id;		/* drive model identification info */
 	struct hd_struct  *part;	/* drive partition table */
 	char		name[4];	/* drive name, such as "hda" */
-	void 		*driver;	/* (ide_driver_t *) */
+	struct ide_driver_s *driver;	/* (ide_driver_t *) */
 	void		*driver_data;	/* extra driver data */
 	devfs_handle_t	de;		/* directory for device */
 	struct proc_dir_entry *proc;	/* /proc/ide/ directory entry */

@@ -448,6 +449,7 @@
 	byte		acoustic;	/* acoustic management */
 	unsigned int	failures;	/* current failure count */
 	unsigned int	max_failures;	/* maximum allowed failure count */
+	struct device	device;
 } ide_drive_t;
 
 /*

@@ -529,7 +531,7 @@
 
 typedef struct hwif_s {
 	struct hwif_s	*next;		/* for linked-list in ide_hwgroup_t */
-	void		*hwgroup;	/* actually (ide_hwgroup_t *) */
+	struct hwgroup_s *hwgroup;	/* actually (ide_hwgroup_t *) */
 	ide_ioreg_t	io_ports[IDE_NR_PORTS];	/* task file registers */
 	hw_regs_t	hw;		/* Hardware info */
 	ide_drive_t	drives[MAX_DRIVES];	/* drive info */

@@ -580,6 +582,7 @@
 	void		*hwif_data;	/* extra hwif data */
 	ide_busproc_t	*busproc;	/* driver soft-power interface */
 	byte		bus_state;	/* power state of the IDE bus */
+	struct device	device;
 } ide_hwif_t;
 
 /*

Signature · 2 lines

(about SSSCA) "I don't say this lightly.  However, I really think that the U.S.
no longer is classifiable as a democracy, but rather as a plutocracy." --hpa

Gadi Oxman

2002-02-22 10:34 UTC #159 lore raw

Re: [PATCH] 2.5.5-pre1 IDE cleanup 9

Hi Martin,

ide_module_t was designed to conceptually divide the code to multiple layers,
whether one actually uses modules or compiles all the IDE code into the kernel,
and in the future, to alow several parallel implementations of the same functionality
which could reside in the kernel simultaneously.

The job was not finished, but the original idea was to have:

1. Core IDE code.
2. Chipset modules.
3. Probe modules.
4. Subdriver modules.

ide_module_t was created so that the core IDE code could track all the modules
currently available to it, and to be able to have several chipset drivers for the same
chipset simultaneously, several probe modules simultaneously, and several subdrivers
for the same device type (so that one could choose the one which works best).

The last example was actually used in ide-scsi.c. The intention in ide_module_t was
that one would be able to have, for example, ide-cdrom + ide-scsi or ide-tape + ide-scsi
in the kernel simultaneously (either compiled in or as modules), known to the
core IDE code, and one could then change drivers for a single drive on the fly using
something like "cat driver_name > /proc/ide/hdx/driver".

Upon receiving such a command, the IDE core could call the cleanup code of the driver which was originally assigned to hdx, the cleanup code would de-attach
the driver from hdx without unloading the module and without affecting the other drives which are currently supported by it. The core code could then call the init code of the other driver to attach to the device.

The reason ide-probe was splitted to a different module is that in most of the
time, one doesn't need the probe code in the kernel. It is needed during boot, and
each time one "hot swaps" an IDE device. In addition, it could provide the framework
for having several probe modules simultaneously, altough that never materialized.

Cheers,

Gadi

----- Original Message -----
From: "Martin Dalecki" <[email protected]>
To: "Linus Torvalds" <[email protected]>
Cc: "Kernel Mailing List" <[email protected]>
Sent: Tuesday, February 19, 2002 1:46 PM
Subject: [PATCH] 2.5.5-pre1 IDE cleanup 9

Quoted 18 lines

The attached patch does the following:
1. Kill the ide-probe-mod by merging it with ide-mod. There is *really* no reaons for having this stuff split up into two different modules unless you wan't to create artificial module dependancies
and waste space
of page boundaries during memmory allocation for the modules
2. Kill the ide_module_t - which is unnecessary and presents a "reimplementation"
of module handling inside the ide driver. This is achieved by
attaching the
initialization routine ot the ide_driver_t, which will be gone next
time,
since there is no sane reason apparently, which this couldn't be done during the module-generic initialization of the corresponding driver
module.

Quoted 6 lines

3. Kill unnecessary tagging of "subdriver" with IDE_SUBDRIVER_VERSION - we have plenty of other mechanisms for module consistency checking. And
anyway
the ide code didn't any consistence checks on this value at all.
NOTE: The ide_(un)register_module() functions will be killed in next

round.

Quoted 6 lines

This patch should apply to mainstream, however it waws created on top of the others.

Gerd Knorr

2002-02-22 11:10 UTC #160 lore raw

Re: [PATCH] 2.5.5-pre1 IDE cleanup 9

Quoted 5 lines

1. Kill the ide-probe-mod by merging it with ide-mod. There is *really* no reaons for having this stuff split up into two different modules unless you wan't to create artificial module dependancies
and waste space
of page boundaries during memmory allocation for the modules

Ah, seems you are the one who broke modular ide in 2.5.5:

Older kernels:
insmod ide-mod, insmod ide-disk, insmod ide-probe-mod => works.

2.5.5:
insmod ide-mod, insmod ide-disk => mounting /dev/hda2 doesn't work.

Gerd

Martin Dalecki

2002-02-22 13:46 UTC #161 lore raw

Re: [PATCH] 2.5.5-pre1 IDE cleanup 9

Quoted 17 lines · Gadi Oxman

Hi Martin,
ide_module_t was designed to conceptually divide the code to multiple layers,
whether one actually uses modules or compiles all the IDE code into the kernel,
and in the future, to alow several parallel implementations of the same functionality
which could reside in the kernel simultaneously.
The job was not finished, but the original idea was to have:
1. Core IDE code.
2. Chipset modules.
3. Probe modules.
4. Subdriver modules.

Quoted 8 lines

ide_module_t was created so that the core IDE code could track all the modules
currently available to it, and to be able to have several chipset drivers for the same
chipset simultaneously, several probe modules simultaneously, and several subdrivers
for the same device type (so that one could choose the one which works best).

The normal linux way using multiple driver implementations are
aliases in /etc/modules.conf - see for example ALSA vers. OSS sound drivers for the same hardware.

Quoted 1 line

The last example was actually used in ide-scsi.c. The intention in

ide-scsi is intendid to be gone in 2.5.x.

Quoted 10 lines

ide_module_t was
that one would be able to have, for example, ide-cdrom + ide-scsi or ide-tape + ide-scsi
in the kernel simultaneously (either compiled in or as modules), known to the
core IDE code, and one could then change drivers for a single drive on the fly using
something like "cat driver_name > /proc/ide/hdx/driver".

See above that is *not* the proper interface for implementation choice, which is *user* policy anyway and can be handled fine by the existing generic module interface infrastructure.

For the sake of modularization. I have already at home a version of ide-pci.c, where the signatures of chipset initialization source code modules match the singature of a normal pci device initialization hook. This should enable it to make them true modules RSN.

The chipset drivers will register lists of PCI-id's they can handle instead of the single only global list found in ide-pci.c.

Quoted 7 lines

Upon receiving such a command, the IDE core could call the cleanup code of the driver which was originally assigned to hdx, the cleanup code would de-attach
the driver from hdx without unloading the module and without affecting the other drives which are currently supported by it. The core code could then call the init code of the other driver to attach to the device.

Quoted 8 lines

The reason ide-probe was splitted to a different module is that in most of the
time, one doesn't need the probe code in the kernel. It is needed during boot, and
each time one "hot swaps" an IDE device. In addition, it could provide the framework
for having several probe modules simultaneously, altough that never materialized.

It's inventing too many races (in esp. in the hot plug case) and the module would be too small for beeing worth it:

[root@kozaczek ide]# size ide-probe.o
text data bss dec hex filename
8445 16 0 8461 210d ide-probe.o
[root@kozaczek ide]# size ide.o
text data bss dec hex filename
30951 521 9376 40848 9f90 ide.o
[root@kozaczek ide]#

(BTW.> I hate the ALSA OSS emultaion module splitup as well.)

As it goes about the possibility of multiple different probe implementatoins - please show me a different one.

Martin Dalecki

2002-02-22 13:50 UTC #162 lore raw

Re: [PATCH] 2.5.5-pre1 IDE cleanup 9

Quoted 9 lines · Gerd Knorr

Quoted 6 lines
1. Kill the ide-probe-mod by merging it with ide-mod. There is *really* no reaons for having this stuff split up into two different modules unless you wan't to create artificial module dependancies
and waste space
of page boundaries during memmory allocation for the modules
Ah, seems you are the one who broke modular ide in 2.5.5:

Quoted 7 lines

Older kernels:
insmod ide-mod, insmod ide-disk, insmod ide-probe-mod => works.
2.5.5:
insmod ide-mod, insmod ide-disk => mounting /dev/hda2 doesn't work.
Gerd

Well I will have to check this soon on a system booting out from SCSI. Most propably it's an simple "load order" problem, where ide-disk should call the probe code again. (But somehow ide-scsi, ide-cd and friends do...)

Vojtech Pavlik

2002-02-22 14:03 UTC #163 lore raw

Re: [PATCH] 2.5.5-pre1 IDE cleanup 9

Quoted 9 lines · Martin Dalecki

See above that is *not* the proper interface for implementation choice, which is *user* policy anyway and can be handled fine by the existing generic module interface infrastructure.
For the sake of modularization. I have already at home a version of ide-pci.c, where the signatures of chipset initialization source code modules match the singature of a normal pci device initialization hook. This should enable it to make them true modules RSN.

If you can, please send this to me - I'd like to take a look.

Quoted 2 lines

The chipset drivers will register lists of PCI-id's they can handle instead of the single only global list found in ide-pci.c.

I think it'd be even better if the chipset drivers did the probing themselves, and once they find the IDE device, they can register it with the IDE core. Same as all the other subsystem do this.

Signature · 2 lines

Vojtech Pavlik
SuSE Labs

Jeff Garzik

2002-02-22 14:12 UTC #164 lore raw

Re: [PATCH] 2.5.5-pre1 IDE cleanup 9

Quoted 7 lines · Vojtech Pavlik

Quoted 2 lines · Martin Dalecki
The chipset drivers will register lists of PCI-id's they can handle instead of the single only global list found in ide-pci.c.
I think it'd be even better if the chipset drivers did the probing themselves, and once they find the IDE device, they can register it with the IDE core. Same as all the other subsystem do this.

Yes. I've mentioned before converting the IDE driver into a sort of structure, but it always boiled down to "that requires a complete rewrite" reply to me... If someone accomplishes such, I would be happy.

Jeff

Signature · 3 lines

Jeff Garzik      | "UNIX enhancements aren't."
Building 1024    |           -- says /usr/games/fortune
MandrakeSoft     |

Arjan van de Ven

2002-02-22 14:17 UTC #165 lore raw

Re: [PATCH] 2.5.5-pre1 IDE cleanup 9

Quoted 3 lines · Vojtech Pavlik

I think it'd be even better if the chipset drivers did the probing themselves, and once they find the IDE device, they can register it with the IDE core. Same as all the other subsystem do this.

Please send me your scsi subsystem then ;)

Martin Dalecki

2002-02-22 14:17 UTC #166 lore raw

Re: [PATCH] 2.5.5-pre1 IDE cleanup 9

Quoted 7 lines · Vojtech Pavlik

Quoted 4 lines · Martin Dalecki
See above that is *not* the proper interface for implementation choice, which is *user* policy anyway and can be handled fine by the existing generic module interface infrastructure.

Quoted 8 lines

Quoted 6 lines
For the sake of modularization. I have already at home a version of ide-pci.c, where the signatures of chipset initialization source code modules match the singature of a normal pci device initialization hook. This should enable it to make them true modules RSN.
If you can, please send this to me - I'd like to take a look.

Will do soon. But now I don't have it at hand, it's on my home system unfortunately and I would like to finish some other minor things there as well. I mean basically the macro games showing that somebody didn't
understand C pointer semantics found at places like:

#ifdef CONFIG_BLK_DEV_ALI15X3
extern unsigned int pci_init_ali15x3(struct pci_dev *, const char *);
...
#define PCI_ALI15X3 &pci_init_ali15x3
#else
...
#define PCI_ALI15X3 NULL
#endif

This should rather look like:

#ifdef CONFIG_BLK_DEV_ALI15X3
extern unsigned int pci_init_ali15x3(struct pci_dev *); #else
#define pci_init_ali15x3 NULL
#endif

And be replaces entierly by register_chipset(...) blah blah or therlike ;-) as well as module initialization lists.

Quoted 7 lines

Quoted 3 lines
The chipset drivers will register lists of PCI-id's they can handle instead of the single only global list found in ide-pci.c.
I think it'd be even better if the chipset drivers did the probing themselves, and once they find the IDE device, they can register it with the IDE core. Same as all the other subsystem do this.

Well the lists are needed for quirk handling in the ide-pci.c code. But if it turns out to be possible - I'm all for it.

Keith Owens

2002-02-23 08:06 UTC #167 lore raw

Re: [PATCH] 2.5.5-pre1 IDE cleanup 9

Quoted 13 lines · Martin Dalecki

... I would like to finish some other minor things there
as well. I mean basically the macro games showing that somebody didn't understand C pointer semantics found at places like:
#ifdef CONFIG_BLK_DEV_ALI15X3
extern unsigned int pci_init_ali15x3(struct pci_dev *, const char *);
...
#define PCI_ALI15X3 &pci_init_ali15x3
#else
...
#define PCI_ALI15X3 NULL
#endif

Quoted 7 lines

This should rather look like:
#ifdef CONFIG_BLK_DEV_ALI15X3
extern unsigned int pci_init_ali15x3(struct pci_dev *); #else
#define pci_init_ali15x3 NULL
#endif

That will probably break with CONFIG_MODVERSIONS. At the very least it will require make mrproper when changing CONFIG_BLK_DEV_ALI15X3 and CONFIG_MODVERSIONS is set to y.

Modversions does its own #define of nthe function name. Anybody contemplating a mixture of real functions and #define of the function name must test their patch with CONFIG_MODVERSIONS=y, otherwise you are setting users up for wierd bug reports.

Martin Dalecki

2002-02-23 14:56 UTC #168 lore raw

Re: [PATCH] 2.5.5-pre1 IDE cleanup 9

Quoted 24 lines · Keith Owens

Quoted 13 lines · Martin Dalecki
... I would like to finish some other minor things there
as well. I mean basically the macro games showing that somebody didn't understand C pointer semantics found at places like:
#ifdef CONFIG_BLK_DEV_ALI15X3
extern unsigned int pci_init_ali15x3(struct pci_dev *, const char *);
...
#define PCI_ALI15X3 &pci_init_ali15x3
#else
...
#define PCI_ALI15X3 NULL
#endif
Quoted 8 lines
This should rather look like:
#ifdef CONFIG_BLK_DEV_ALI15X3
extern unsigned int pci_init_ali15x3(struct pci_dev *); #else
#define pci_init_ali15x3 NULL
#endif

Quoted 3 lines

That will probably break with CONFIG_MODVERSIONS. At the very least it will require make mrproper when changing CONFIG_BLK_DEV_ALI15X3 and CONFIG_MODVERSIONS is set to y.

No it won't. The functions above are:

1. Not exported at all to modules.
2. If the will be exported it will happen through a generic struct of function pointers.

Martin Dalecki

2002-02-22 14:21 UTC #169 lore raw

Re: [PATCH] 2.5.5-pre1 IDE cleanup 9

Quoted 7 lines · Jeff Garzik

Quoted 5 lines · Vojtech Pavlik
Quoted 3 lines · Martin Dalecki
The chipset drivers will register lists of PCI-id's they can handle instead of the single only global list found in ide-pci.c.

Quoted 8 lines

Quoted 4 lines
I think it'd be even better if the chipset drivers did the probing themselves, and once they find the IDE device, they can register it with the IDE core. Same as all the other subsystem do this.
Yes. I've mentioned before converting the IDE driver into a sort of structure, but it always boiled down to "that requires a complete rewrite" reply to me... If someone accomplishes such, I would be happy.

Well, apparently it turned out to be true.

BTW> If you have any "dirt bag" of "unfinished" code going into this direction I would be quite happy to have a look at it ;-).

Vojtech Pavlik

2002-02-22 14:39 UTC #170 lore raw

Re: [PATCH] 2.5.5-pre1 IDE cleanup 9

Quoted 29 lines · Martin Dalecki

Will do soon. But now I don't have it at hand, it's on my home system unfortunately and I would like to finish some other minor things there as well. I mean basically the macro games showing that somebody didn't understand C pointer semantics found at places like:
#ifdef CONFIG_BLK_DEV_ALI15X3
extern unsigned int pci_init_ali15x3(struct pci_dev *, const char *);
...
#define PCI_ALI15X3 &pci_init_ali15x3
#else
...
#define PCI_ALI15X3 NULL
#endif
This should rather look like:
#ifdef CONFIG_BLK_DEV_ALI15X3
extern unsigned int pci_init_ali15x3(struct pci_dev *); #else
#define pci_init_ali15x3 NULL
#endif
And be replaces entierly by register_chipset(...) blah blah or therlike ;-) as well as module initialization lists.
Quoted 4 lines
Quoted 3 lines
The chipset drivers will register lists of PCI-id's they can handle instead of the single only global list found in ide-pci.c.

Quoted 6 lines

Quoted 3 lines
I think it'd be even better if the chipset drivers did the probing themselves, and once they find the IDE device, they can register it with the IDE core. Same as all the other subsystem do this.
Well the lists are needed for quirk handling in the ide-pci.c code. But if it turns out to be possible - I'm all for it.

I don't think so. If needed we can make some generic IDE_QUIRK_XXX defines which then the chipset drivers can use where applicable, passing them to the generic code.

Signature · 2 lines

Vojtech Pavlik
SuSE Labs

Vojtech Pavlik

2002-02-22 14:40 UTC #171 lore raw

Re: [PATCH] 2.5.5-pre1 IDE cleanup 9

Quoted 5 lines · Arjan van de Ven

Quoted 3 lines
I think it'd be even better if the chipset drivers did the probing themselves, and once they find the IDE device, they can register it with the IDE core. Same as all the other subsystem do this.
Please send me your scsi subsystem then ;)

I must agree that SCSI controllers aren't doing their probing in a uniform and clean way even on PCI, but at least they do the probing themselves and don't have the mid-layer SCSI code do it for them like IDE.

Signature · 2 lines

Vojtech Pavlik
SuSE Labs

Gérard Roudier

2002-02-22 19:32 UTC #172 lore raw

Re: [PATCH] 2.5.5-pre1 IDE cleanup 9

Quoted 6 lines · Vojtech Pavlik

Quoted 4 lines · Arjan van de Ven
Quoted 3 lines
I think it'd be even better if the chipset drivers did the probing themselves, and once they find the IDE device, they can register it with the IDE core. Same as all the other subsystem do this.

Quoted 6 lines

Quoted 1 line
Please send me your scsi subsystem then ;)
I must agree that SCSI controllers aren't doing their probing in a uniform and clean way even on PCI, but at least they do the probing themselves and don't have the mid-layer SCSI code do it for them like IDE.

The problem that bites us since years is not the PCI probing, but the order in which SCSI devices are attached. Microsoft O/Ses have been smart enough for ordering hard disks in the way user sets it from system setup, but Unices just messed up the thing.

There have been exceptions to this. People that use sym53c8xx HBA with NVRAM for hard disk devices with either the sym53c8xx or the sym53c8xx_2 drivers see their hard disks under Linux in the expected order. The work is performed by the low level driver by:

1) Detecting a controller with NVRAM that contains the HBA attachment order.
2) Attaching the HBAs in this order.
2.1 For each HBA, attaching the devices configured for SCAN at BOOT.

Then other devices can be probed after boot by user in the order it desires.

Basically at the moment, if the driver allows upper 'seeming cleaner and smarter' PCI probing things to deal with the HBA attachment order, at least all my machines running Linux will not even reboot.

Being smart is doing what user expects, here.

Gérard.

Jeff Garzik

2002-02-22 19:56 UTC #173 lore raw

Re: [PATCH] 2.5.5-pre1 IDE cleanup 9

Quoted 5 lines · Gérard Roudier

Basically at the moment, if the driver allows upper 'seeming cleaner and smarter' PCI probing things to deal with the HBA attachment order, at least all my machines running Linux will not even reboot.
Being smart is doing what user expects, here.

Oh come on, how hard is the following?

Quoted 7 lines

static int __init foo_init(void)
{
	int rc = pci_module_init(&sym2_pci_driver);
	if (rc) return rc;
	do_deferred_work();
}
module_init(foo_init);

You have tons of flexibility you are ignoring here... For the non-hotplug hosts (ie. present at boot), just use pci_driver::probe to register hosts on a list, and little other work. do_deferred_work() handles the list in a manner that ensures proper boot and/or host ordering.

So for non-hotplug hosts you do a init_module time:
register N hosts with PCI API register N hosts with SCSI API

And hotplugged hosts would do the same, with N==1.

What you describe -is- supported with the PCI API.

Jeff

Signature · 3 lines

Jeff Garzik      | "UNIX enhancements aren't."
Building 1024    |           -- says /usr/games/fortune
MandrakeSoft     |

Gérard Roudier

2002-02-22 20:15 UTC #174 lore raw

Re: [PATCH] 2.5.5-pre1 IDE cleanup 9

Quoted 23 lines · Jeff Garzik

Quoted 5 lines · Gérard Roudier
Basically at the moment, if the driver allows upper 'seeming cleaner and smarter' PCI probing things to deal with the HBA attachment order, at least all my machines running Linux will not even reboot.
Being smart is doing what user expects, here.
Oh come on, how hard is the following?
Quoted 7 lines
static int __init foo_init(void)
{
	int rc = pci_module_init(&sym2_pci_driver);
	if (rc) return rc;
	do_deferred_work();
}
module_init(foo_init);
You have tons of flexibility you are ignoring here... For the non-hotplug hosts (ie. present at boot), just use pci_driver::probe to register hosts on a list, and little other work. do_deferred_work() handles the list in a manner that ensures proper boot and/or host ordering.

Quoted 7 lines

So for non-hotplug hosts you do a init_module time:
register N hosts with PCI API register N hosts with SCSI API
And hotplugged hosts would do the same, with N==1.
What you describe -is- supported with the PCI API.

At the time I investigated the API it just mixed the probing and the registering by performing some auto-registration based on return value. May-be the API did evolve since that time or I missed something important.

For now I will be in vacation for 1 week. I will re-investigate this when I will be back.

Thanks,
Gérard.

Jeff Garzik

2002-02-22 22:35 UTC #175 lore raw

Re: [PATCH] 2.5.5-pre1 IDE cleanup 9

Quoted 32 lines · Gérard Roudier

Quoted 29 lines · Jeff Garzik
Quoted 5 lines · Gérard Roudier
Basically at the moment, if the driver allows upper 'seeming cleaner and smarter' PCI probing things to deal with the HBA attachment order, at least all my machines running Linux will not even reboot.
Being smart is doing what user expects, here.
Oh come on, how hard is the following?
Quoted 7 lines
static int __init foo_init(void)
{
    int rc = pci_module_init(&sym2_pci_driver);
    if (rc) return rc;
    do_deferred_work();
}
module_init(foo_init);
You have tons of flexibility you are ignoring here... For the non-hotplug hosts (ie. present at boot), just use pci_driver::probe to register hosts on a list, and little other work. do_deferred_work() handles the list in a manner that ensures proper boot and/or host ordering.
So for non-hotplug hosts you do a init_module time:
register N hosts with PCI API register N hosts with SCSI API
And hotplugged hosts would do the same, with N==1.

Quoted 8 lines

Quoted 1 line
What you describe -is- supported with the PCI API.
At the time I investigated the API it just mixed the probing and the registering by performing some auto-registration based on return value. May-be the API did evolve since that time or I missed something important.
For now I will be in vacation for 1 week. I will re-investigate this when I will be back.

Thanks!

One thing that is slowly becoming apparently to me during this thread is the importance of separating ordering [of hosts, of disks] from the registration of the resource itself.

Thinking about the problem a bit more (NVRAM boot disk ordering, etc.) I believe that what I describe above might be considered a transition step... In Step Two, do_deferred_work() [above] would likely be moved to userspace, running on initramfs.

Jeff

Signature · 3 lines

Jeff Garzik      | "UNIX enhancements aren't."
Building 1024    |           -- says /usr/games/fortune
MandrakeSoft     |

Vojtech Pavlik

2002-02-22 21:37 UTC #176 lore raw

Re: [PATCH] 2.5.5-pre1 IDE cleanup 9

Quoted 13 lines · G?rard Roudier

Quoted 6 lines · Arjan van de Ven
Quoted 5 lines
Quoted 4 lines
I think it'd be even better if the chipset drivers did the probing themselves, and once they find the IDE device, they can register it with the IDE core. Same as all the other subsystem do this.
Quoted 6 lines
Quoted 1 line
Please send me your scsi subsystem then ;)
I must agree that SCSI controllers aren't doing their probing in a uniform and clean way even on PCI, but at least they do the probing themselves and don't have the mid-layer SCSI code do it for them like IDE.

Quoted 4 lines

The problem that bites us since years is not the PCI probing, but the order in which SCSI devices are attached. Microsoft O/Ses have been smart enough for ordering hard disks in the way user sets it from system setup, but Unices just messed up the thing.

For some adapters, this is possible, for other it is not (at all). You happen to be a maintainer of one for which it is possible, and thus your point of view is quite different from mine - mine comes from USB and other parts of the device world, where no order can even be defined.

And because of that, I do not think that having the host adapters decide what device gets what number is a good idea. They should provide the information if they have it, but the final decision should definitely be done in userspace, by the hotplug agent.

Ie. it should be configurable.

Signature · 2 lines

Vojtech Pavlik
SuSE Labs

Greg KH

2002-02-22 21:51 UTC #177 lore raw

Re: [PATCH] 2.5.5-pre1 IDE cleanup 9

Quoted 7 lines · Vojtech Pavlik

And because of that, I do not think that having the host adapters decide what device gets what number is a good idea. They should provide the information if they have it, but the final decision should definitely be done in userspace, by the hotplug agent.
Ie. it should be configurable.

I totally agree. Network devices are now configured by the hotplug agent and can handle different PCI probe order, rearranging cards in a system, and other fun things that cause them to be initialized in a different order. All of this now "just works" as far as the user is concerned.

I don't see why SCSI should be any different.

thanks,

greg k-h

Jeff Garzik

2002-02-22 21:56 UTC #178 lore raw

Re: [PATCH] 2.5.5-pre1 IDE cleanup 9

Quoted 11 lines · Vojtech Pavlik

For some adapters, this is possible, for other it is not (at all). You happen to be a maintainer of one for which it is possible, and thus your point of view is quite different from mine - mine comes from USB and other parts of the device world, where no order can even be defined.
And because of that, I do not think that having the host adapters decide what device gets what number is a good idea. They should provide the information if they have it, but the final decision should definitely be done in userspace, by the hotplug agent.
Ie. it should be configurable.

For the future, we need to get away from legacy methods of disk ordering, indeed.

For Gerard's case, I can see a userspace agent running in initramfs discovering the order...

Most filesystems have some sort of serial number of labelling capability which allows them to be addressed independent of spindle, or starting position on that spindle [partition].

Signature · 3 lines

Jeff Garzik      | "UNIX enhancements aren't."
Building 1024    |           -- says /usr/games/fortune
MandrakeSoft     |

Vojtech Pavlik

2002-02-22 22:02 UTC #179 lore raw

Re: [PATCH] 2.5.5-pre1 IDE cleanup 9

Quoted 11 lines · Jeff Garzik

Quoted 10 lines · Vojtech Pavlik
For some adapters, this is possible, for other it is not (at all). You happen to be a maintainer of one for which it is possible, and thus your point of view is quite different from mine - mine comes from USB and other parts of the device world, where no order can even be defined.
And because of that, I do not think that having the host adapters decide what device gets what number is a good idea. They should provide the information if they have it, but the final decision should definitely be done in userspace, by the hotplug agent.

Quoted 4 lines

Quoted 1 line
Ie. it should be configurable.
For the future, we need to get away from legacy methods of disk ordering, indeed.

Exactly.

Quoted 2 lines

For Gerard's case, I can see a userspace agent running in initramfs discovering the order...

The same agent that decides for the other cases - only in Gerard's case it has more information to work with, we just have to make sure it can access the information.

Quoted 3 lines

Most filesystems have some sort of serial number of labelling capability which allows them to be addressed independent of spindle, or starting position on that spindle [partition].

Yes, yes, yes.

Signature · 2 lines

Vojtech Pavlik
SuSE Labs

Martin Dalecki

2002-02-22 23:07 UTC #180 lore raw

Re: [PATCH] 2.5.5-pre1 IDE cleanup 9

Quoted 11 lines · Vojtech Pavlik

For some adapters, this is possible, for other it is not (at all). You happen to be a maintainer of one for which it is possible, and thus your point of view is quite different from mine - mine comes from USB and other parts of the device world, where no order can even be defined.
And because of that, I do not think that having the host adapters decide what device gets what number is a good idea. They should provide the information if they have it, but the final decision should definitely be done in userspace, by the hotplug agent.
Ie. it should be configurable.

Partition labeling takes care of about 99% + 1% of the ordering problems for disk drives.

Jeff Garzik

2002-02-22 14:45 UTC #181 lore raw

Re: [PATCH] 2.5.5-pre1 IDE cleanup 9

Quoted 7 lines · Vojtech Pavlik

Quoted 4 lines · Arjan van de Ven
Quoted 3 lines
I think it'd be even better if the chipset drivers did the probing themselves, and once they find the IDE device, they can register it with the IDE core. Same as all the other subsystem do this.

Quoted 6 lines

Quoted 1 line
Please send me your scsi subsystem then ;)
I must agree that SCSI controllers aren't doing their probing in a uniform and clean way even on PCI, but at least they do the probing themselves and don't have the mid-layer SCSI code do it for them like IDE.

Only 1-2 SCSI drivers do PCI probing "the right way"... IIRC aic7xxx is one of them.

Signature · 3 lines

Jeff Garzik      | "UNIX enhancements aren't."
Building 1024    |           -- says /usr/games/fortune
MandrakeSoft     |

Gérard Roudier

2002-02-22 19:40 UTC #182 lore raw

Re: [PATCH] 2.5.5-pre1 IDE cleanup 9

Quoted 10 lines · Jeff Garzik

Quoted 9 lines · Vojtech Pavlik
Quoted 5 lines · Arjan van de Ven
Quoted 3 lines
I think it'd be even better if the chipset drivers did the probing themselves, and once they find the IDE device, they can register it with the IDE core. Same as all the other subsystem do this.
Please send me your scsi subsystem then ;)

Quoted 7 lines

Quoted 4 lines
I must agree that SCSI controllers aren't doing their probing in a uniform and clean way even on PCI, but at least they do the probing themselves and don't have the mid-layer SCSI code do it for them like IDE.
Only 1-2 SCSI drivers do PCI probing "the right way"... IIRC aic7xxx is one of them.

Could you, please, not mix PCI probing and SCSI probing.

Average user does not care about PCI probing. But it does care on booting the expected kernel image and mounting the expected partitions. It also doesn't care of code aesthetical issue even with free software since average user is not a kernel hacker.

Gérard.

Jeff Garzik

2002-02-22 19:48 UTC #183 lore raw

Re: [PATCH] 2.5.5-pre1 IDE cleanup 9

Quoted 10 lines · Gérard Roudier

Quoted 2 lines · Jeff Garzik
Only 1-2 SCSI drivers do PCI probing "the right way"... IIRC aic7xxx is one of them.
Could you, please, not mix PCI probing and SCSI probing.
Average user does not care about PCI probing. But it does care on booting the expected kernel image and mounting the expected partitions. It also doesn't care of code aesthetical issue even with free software since average user is not a kernel hacker.

Most SCSI drivers are not using the 2.4 PCI API, which has been documented and stable for a while now.

This is need for transparented support for cardbus and hotplug PCI, not some pie-in-the-sky code asthetic. This will become further important as 2.5.x transitions more and more to Mochel's driver model work, which will among other things provide a sane power management model.

To tangent, IDE and SCSI hotplug issues are interesting, because a lot of people forget or mix up the two types of hotplug, board (host) hotplug and drive hotplug.

Jeff

Signature · 3 lines

Jeff Garzik      | "UNIX enhancements aren't."
Building 1024    |           -- says /usr/games/fortune
MandrakeSoft     |

Andre Hedrick

2002-02-22 19:59 UTC #184 lore raw

Re: [PATCH] 2.5.5-pre1 IDE cleanup 9

Quoted 7 lines · Jeff Garzik

Quoted 6 lines · Gérard Roudier
Quoted 2 lines · Jeff Garzik
Only 1-2 SCSI drivers do PCI probing "the right way"... IIRC aic7xxx is one of them.
Could you, please, not mix PCI probing and SCSI probing.

Quoted 7 lines

Quoted 4 lines
Average user does not care about PCI probing. But it does care on booting the expected kernel image and mounting the expected partitions. It also doesn't care of code aesthetical issue even with free software since average user is not a kernel hacker.
Most SCSI drivers are not using the 2.4 PCI API, which has been documented and stable for a while now.

Also not that ATA/IDE drivers were not using 2.4 PCI API and likewise was stable for a while.

Quoted 1 line

This is need for transparented support for cardbus and hotplug PCI, not

This is HOST level operation not DEVICE, and you do not see the differenc.

Quoted 7 lines

some pie-in-the-sky code asthetic. This will become further important as 2.5.x transitions more and more to Mochel's driver model work, which will among other things provide a sane power management model.
To tangent, IDE and SCSI hotplug issues are interesting, because a lot of people forget or mix up the two types of hotplug, board (host) hotplug and drive hotplug.

It is a shame that I will now have to start from scratch to create another API for hotplug device for ATA/ATAPI that was migrating into SCSI because of the ide-scsi driver.

Andre Hedrick
Linux Disk Certification Project Linux ATA Development

Jeff Garzik

2002-02-22 20:07 UTC #185 lore raw

Re: [PATCH] 2.5.5-pre1 IDE cleanup 9

Quoted 2 lines · Andre Hedrick

Also not that ATA/IDE drivers were not using 2.4 PCI API and likewise was stable for a while.

Stable? Yes. But it's not modular nor compatible with current efforts like 2.4 cardbus or 2.4 hotplug pci or 2.5 device mode. If one cannot do
modprobe piix4_ide
and have the right things happen automatically, the system is not modular. If it doesn't use the PCI API, it's implementing CardBus support in a non-standard way if at all.

Quoted 3 lines

Quoted 1 line
This is need for transparented support for cardbus and hotplug PCI, not
This is HOST level operation not DEVICE, and you do not see the differenc.

I do. I am talking about a HOST api here.

Quoted 3 lines

It is a shame that I will now have to start from scratch to create another API for hotplug device for ATA/ATAPI that was migrating into SCSI because of the ide-scsi driver.

Why not work with Patrick to make sure his device model properly supports disks?

Jeff

Signature · 3 lines

Jeff Garzik      | "UNIX enhancements aren't."
Building 1024    |           -- says /usr/games/fortune
MandrakeSoft     |

Andre Hedrick

2002-02-22 20:32 UTC #186 lore raw

Re: [PATCH] 2.5.5-pre1 IDE cleanup 9

Quoted 11 lines · Jeff Garzik

Quoted 2 lines · Andre Hedrick
Also not that ATA/IDE drivers were not using 2.4 PCI API and likewise was stable for a while.
Stable? Yes. But it's not modular nor compatible with current efforts like 2.4 cardbus or 2.4 hotplug pci or 2.5 device mode. If one cannot do
modprobe piix4_ide
and have the right things happen automatically, the system is not modular. If it doesn't use the PCI API, it's implementing CardBus support in a non-standard way if at all.

Now what happens if you have more than one HOST of the same kind or the "SAME HOST" with multiple functions but are really one HOST?

I do not see how this will handle the problem.
But obviously I have been to far down making sure the DATA got to platter correct and most likely missed a few things. :-/

Quoted 5 lines

Quoted 3 lines
Quoted 1 line
This is need for transparented support for cardbus and hotplug PCI, not
This is HOST level operation not DEVICE, and you do not see the differenc.
I do. I am talking about a HOST api here.

Okay we are getting some place now, cause what I was reading and seeing in the changes registers a DRIVE to the PCI API and not a HOST.

Quoted 7 lines

Quoted 4 lines
It is a shame that I will now have to start from scratch to create another API for hotplug device for ATA/ATAPI that was migrating into SCSI because of the ide-scsi driver.
Why not work with Patrick to make sure his device model properly supports disks?

I thought there were a few conversations to address this point. What everyone is maybe missing is PATA (parallel ata) does not permit "Disconnect/Release".

Maybe I need to sit down w/ Patrick to figure out how to pound the model into my thick head.

Much of my unwillingness to move rapid is because the past has shown massive problem, and Linus has never permitted rapid design changes in the ata/atapi stack. So much if this is a shock to the system.

Cheers,

Andre Hedrick
Linux Disk Certification Project Linux ATA Development

Martin Dalecki

2002-02-22 23:04 UTC #187 lore raw

Re: [PATCH] 2.5.5-pre1 IDE cleanup 9

Quoted 3 lines · Andre Hedrick

Okay we are getting some place now, cause what I was reading and seeing in the changes registers a DRIVE to the PCI API and not a HOST.

The changes add a only a drive and driver, becouse a pci_dev was already there and is used. This is by the way corresposnding to the HOST host.

Can't be that you don't understand the code you claim to care that much about?

Jeff Garzik

2002-02-22 23:47 UTC #188 lore raw

Re: [PATCH] 2.5.5-pre1 IDE cleanup 9

Quoted 22 lines · Andre Hedrick

Quoted 11 lines · Jeff Garzik
Quoted 2 lines · Andre Hedrick
Also not that ATA/IDE drivers were not using 2.4 PCI API and likewise was stable for a while.
Stable? Yes. But it's not modular nor compatible with current efforts like 2.4 cardbus or 2.4 hotplug pci or 2.5 device mode. If one cannot do
modprobe piix4_ide
and have the right things happen automatically, the system is not modular. If it doesn't use the PCI API, it's implementing CardBus support in a non-standard way if at all.
Now what happens if you have more than one HOST of the same kind or the "SAME HOST" with multiple functions but are really one HOST?
I do not see how this will handle the problem.
But obviously I have been to far down making sure the DATA got to platter correct and most likely missed a few things. :-/

Quoted 8 lines

Quoted 5 lines
Quoted 3 lines
Quoted 1 line
This is need for transparented support for cardbus and hotplug PCI, not
This is HOST level operation not DEVICE, and you do not see the differenc.
I do. I am talking about a HOST api here.
Okay we are getting some place now, cause what I was reading and seeing in the changes registers a DRIVE to the PCI API and not a HOST.

Yes... I think there was some earlier confusion. PCI API is definitely an API for registering hosts.

If you have a C structure "struct drive", it may be useful to have a pointer to struct pci_dev. That is just a reference from drive back to the host. So you could do crazy references like this pseudocode:

struct pci_dev *host_pci;
struct ata_host *host_ata;
struct ata_channel *channel;

  host_pci = cur_drive->pci_dev;
  host_ata = pci_get_drvdata(host_pci);
  channel = &host_ata->channels[cur_drive->channel_number];

These back-references are very useful, and use of a concept like this may be the source of confusion.

Jeff

Signature · 3 lines

Jeff Garzik      | "UNIX enhancements aren't."
Building 1024    |           -- says /usr/games/fortune
MandrakeSoft     |

Martin Dalecki

2002-02-23 14:54 UTC #189 lore raw

Re: [PATCH] 2.5.5-pre1 IDE cleanup 9

Quoted 47 lines · Jeff Garzik

Quoted 24 lines · Andre Hedrick
Quoted 5 lines · Jeff Garzik
Quoted 3 lines · Andre Hedrick
Also not that ATA/IDE drivers were not using 2.4 PCI API and likewise was stable for a while.
Quoted 8 lines
Stable? Yes. But it's not modular nor compatible with current efforts like 2.4 cardbus or 2.4 hotplug pci or 2.5 device mode. If one cannot do
modprobe piix4_ide
and have the right things happen automatically, the system is not modular. If it doesn't use the PCI API, it's implementing CardBus support in a non-standard way if at all.
Now what happens if you have more than one HOST of the same kind or the "SAME HOST" with multiple functions but are really one HOST?
I do not see how this will handle the problem.
But obviously I have been to far down making sure the DATA got to platter correct and most likely missed a few things. :-/
Quoted 9 lines
Quoted 6 lines
Quoted 4 lines
Quoted 2 lines
This is need for transparented support for cardbus and hotplug PCI, not
This is HOST level operation not DEVICE, and you do not see the differenc.
I do. I am talking about a HOST api here.
Okay we are getting some place now, cause what I was reading and seeing in the changes registers a DRIVE to the PCI API and not a HOST.
Yes... I think there was some earlier confusion. PCI API is definitely an API for registering hosts.
If you have a C structure "struct drive", it may be useful to have a pointer to struct pci_dev. That is just a reference from drive back to the host. So you could do crazy references like this pseudocode:
struct pci_dev *host_pci;
struct ata_host *host_ata;
struct ata_channel *channel;

Quoted 6 lines

  host_pci = cur_drive->pci_dev;
  host_ata = pci_get_drvdata(host_pci);
  channel = &host_ata->channels[cur_drive->channel_number];
These back-references are very useful, and use of a concept like this may be the source of confusion.

BTW.> The ATA driver is currently entierly confused about
hosts and channels. Usually a host has two channels on it but it
doesn't deal properly with this fact. (to ide_hwif_t instances... and a "mate" pointer)

Vojtech Pavlik

2002-02-22 21:50 UTC #190 lore raw

Re: [PATCH] 2.5.5-pre1 IDE cleanup 9

In reply to Jeff Garzik

Quoted 14 lines · Andre Hedrick

Quoted 11 lines · Jeff Garzik
Quoted 2 lines · Andre Hedrick
Also not that ATA/IDE drivers were not using 2.4 PCI API and likewise was stable for a while.
Stable? Yes. But it's not modular nor compatible with current efforts like 2.4 cardbus or 2.4 hotplug pci or 2.5 device mode. If one cannot do
modprobe piix4_ide
and have the right things happen automatically, the system is not modular. If it doesn't use the PCI API, it's implementing CardBus support in a non-standard way if at all.

Quoted 2 lines

Now what happens if you have more than one HOST of the same kind or the "SAME HOST" with multiple functions but are really one HOST?

Nothing extra. Same as happens when you 'modprobe usb-uhci' or 'modprobe tulip'. All the PCI devices of the type supported by the module are found, initialized and registered with the ide/usb/network core.

Quoted 3 lines

I do not see how this will handle the problem.
But obviously I have been to far down making sure the DATA got to platter correct and most likely missed a few things. :-/

Yes, it seems so.

Quoted 6 lines

Quoted 3 lines
Quoted 2 lines
Quoted 1 line
This is need for transparented support for cardbus and hotplug PCI, not
This is HOST level operation not DEVICE, and you do not see the differenc.
I do. I am talking about a HOST api here.
Okay we are getting some place now, cause what I was reading and seeing in the changes registers a DRIVE to the PCI API and not a HOST.

A drive can't register to a PCI API. A drive isn't a PCI device. That's quite clear, ain't it?

Quoted 6 lines

Quoted 2 lines
Why not work with Patrick to make sure his device model properly supports disks?
I thought there were a few conversations to address this point. What everyone is maybe missing is PATA (parallel ata) does not permit "Disconnect/Release".

Uh? This is quite irrelevant - while it may not support hot(un)plugging, it still supports power management. Hence the need for Patricks device model support.

Quoted 6 lines

Maybe I need to sit down w/ Patrick to figure out how to pound the model into my thick head.
Much of my unwillingness to move rapid is because the past has shown massive problem, and Linus has never permitted rapid design changes in the ata/atapi stack. So much if this is a shock to the system.

Well, the changes happening now from the hands of Martin are definitely not rapid at all. They're pretty incremental without any huge steps which is what Linus dislikes. (And I must agree with him, merging huge patches is not a nice work.)

Signature · 2 lines

Vojtech Pavlik
SuSE Labs

Gérard Roudier

2002-02-22 20:02 UTC #191 lore raw

Re: [PATCH] 2.5.5-pre1 IDE cleanup 9

In reply to Jeff Garzik

Quoted 7 lines · Jeff Garzik

Quoted 6 lines · Gérard Roudier
Quoted 2 lines · Jeff Garzik
Only 1-2 SCSI drivers do PCI probing "the right way"... IIRC aic7xxx is one of them.
Could you, please, not mix PCI probing and SCSI probing.

Quoted 7 lines

Quoted 4 lines
Average user does not care about PCI probing. But it does care on booting the expected kernel image and mounting the expected partitions. It also doesn't care of code aesthetical issue even with free software since average user is not a kernel hacker.
Most SCSI drivers are not using the 2.4 PCI API, which has been documented and stable for a while now.

I have investigated it, but it didn't seem to allow the boot order set by user in sym53c8xx HBA NVRAMs to be applied, breaking as a result all systems depending on it. Since it is transparently handled by the sym53c8xx driver and just behaves _as_ user expects, my guess is that numerous users may just have their system relying on it.

Quoted 8 lines

This is need for transparented support for cardbus and hotplug PCI, not some pie-in-the-sky code asthetic. This will become further important as 2.5.x transitions more and more to Mochel's driver model work, which will among other things provide a sane power management model.
To tangent, IDE and SCSI hotplug issues are interesting, because a lot of people forget or mix up the two types of hotplug, board (host) hotplug and drive hotplug.

Propose a kernel API that does not break more features that it adds and I will be glad to use it.

Gérard.

Greg KH

2002-02-22 20:13 UTC #192 lore raw

Re: [PATCH] 2.5.5-pre1 IDE cleanup 9

In reply to Jeff Garzik

Quoted 6 lines · Gérard Roudier

I have investigated it, but it didn't seem to allow the boot order set by user in sym53c8xx HBA NVRAMs to be applied, breaking as a result all systems depending on it. Since it is transparently handled by the sym53c8xx driver and just behaves _as_ user expects, my guess is that numerous users may just have their system relying on it.

But as Jeff noted, it is _required_ for PCI hotplug functionality. Because allmost all of the SCSI drivers are not using this over 2 year old interface, they will not work properly on large machines that now support PCI hotplug. Much to my dismay.

Init order works off of PCI probing order. If the network people can handle this, the SCSI people can :)

Quoted 2 lines

Propose a kernel API that does not break more features that it adds and I will be glad to use it.

Huh? This is not a new API. What does it break for you?

thanks,

greg k-h

Andre Hedrick

2002-02-22 20:22 UTC #193 lore raw

Re: [PATCH] 2.5.5-pre1 IDE cleanup 9

Quoted 8 lines · Greg KH

Quoted 6 lines · Gérard Roudier
I have investigated it, but it didn't seem to allow the boot order set by user in sym53c8xx HBA NVRAMs to be applied, breaking as a result all systems depending on it. Since it is transparently handled by the sym53c8xx driver and just behaves _as_ user expects, my guess is that numerous users may just have their system relying on it.

Quoted 7 lines

But as Jeff noted, it is _required_ for PCI hotplug functionality. Because allmost all of the SCSI drivers are not using this over 2 year old interface, they will not work properly on large machines that now support PCI hotplug. Much to my dismay.
Init order works off of PCI probing order. If the network people can handle this, the SCSI people can :)

Does INT13/INT19 Bios call mean anything?

Last time I checked, ethernet devices are not invoked here but I could be wrong given PXE.

Quoted 4 lines

Quoted 2 lines
Propose a kernel API that does not break more features that it adds and I will be glad to use it.
Huh? This is not a new API. What does it break for you?

The problem is how do you deal with multiple HOSTs given there drivers are not (have not checked lately) capable of discrete HOST addition and removal.

SCSI/ATA share the same problem IIRC, the host/chipset drivers load all the device hosts who match that driver code.

What am I missing?

Cheers,

Andre Hedrick
Linux Disk Certification Project Linux ATA Development

[email protected]

2002-02-22 20:34 UTC #194 lore raw

Re: [PATCH] 2.5.5-pre1 IDE cleanup 9

Quoted 4 lines · In article <[email protected]> you…

SCSI/ATA share the same problem IIRC, the host/chipset drivers load all the device hosts who match that driver code.
What am I missing?

I know that for scsi it can be fixed. Ok the current scsi layer doesn't do it right, but there's nothing that prevents it in principle.

PCI code sees a PCI ID, calls probe for the chip
chip driver looks and sees 2 "cables" and creates host structures for each.
per host drive discovery is done and registered with a (thin) generic "I am a disk, gimme a major/minor" layer.

That ought to work. And on hotplug your probe just get called again...

Jeff Garzik

2002-02-23 00:00 UTC #195 lore raw

Re: [PATCH] 2.5.5-pre1 IDE cleanup 9

Quoted 8 lines · Andre Hedrick

The problem is how do you deal with multiple HOSTs given there drivers are not (have not checked lately) capable of discrete HOST addition and removal.
SCSI/ATA share the same problem IIRC, the host/chipset drivers load all the device hosts who match that driver code.
What am I missing?

Nothing, I think --

The PCI API is just a different way of doing the same thing: discrete HOST addition and removal. That is --exactly-- what the PCI API is.

Let me give an example of a very simple PCI API IDE driver:
(WARNING WARNING, no error checking!)

struct pci_driver jgarzik_ide_driver = {
	probe:	jg_host_add,
	remove: jg_host_remove,
};

static int __devinit jg_host_add(struct pci_dev *host_pci, ...)

{
	ide_hwif_t *host_ata = kmalloc(sizeof(*host_ata), GFP_KERNEL);
	pci_set_drvdata(host_pci, host_ata);
	ide_setup_ports(&host_ata->hw, ...);
	return ide_register_hw(&host_ata->hw, &host_ata);
}

static void __devexit jg_host_remove(struct pci_dev *host_pci)

{
	ide_hwif_t *host_ata = pci_get_drvdata(host_pci);
	ide_unregister_hw(&host_ata->hw, &host_ata);
	kfree(host_ata);
	pci_set_drvdata(host_pci, NULL);
}

static int __init jg_driver_init(void)

{
	return pci_module_init(&jgarzik_ide_driver);
}

static void __exit jg_driver_exit(void)

{
	pci_unregister_driver(&jgarzik_ide_driver);
}

module_init(jg_driver_init);
module_exit(jg_driver_exit);

Signature · 3 lines

Jeff Garzik      | "UNIX enhancements aren't."
Building 1024    |           -- says /usr/games/fortune
MandrakeSoft     |

Gérard Roudier

2002-02-22 20:25 UTC #196 lore raw

Re: [PATCH] 2.5.5-pre1 IDE cleanup 9

Quoted 13 lines · Greg KH

Quoted 6 lines · Gérard Roudier
I have investigated it, but it didn't seem to allow the boot order set by user in sym53c8xx HBA NVRAMs to be applied, breaking as a result all systems depending on it. Since it is transparently handled by the sym53c8xx driver and just behaves _as_ user expects, my guess is that numerous users may just have their system relying on it.
But as Jeff noted, it is _required_ for PCI hotplug functionality. Because allmost all of the SCSI drivers are not using this over 2 year old interface, they will not work properly on large machines that now support PCI hotplug. Much to my dismay.

Quoted 7 lines

Init order works off of PCI probing order. If the network people can handle this, the SCSI people can :)
Quoted 2 lines
Propose a kernel API that does not break more features that it adds and I will be glad to use it.
Huh? This is not a new API. What does it break for you?

Thanks for the reply. But my concern is user convenience in _average_ here. Basically, I want the 99% of users that cannot afford neither need nor want PCI hotplug to have their system just dead in order to make happy the 1%.

In other word, I donnot care about this 1% if it makes run a tiny risk to the 99% to get inconvenience a single second. Btw, I am among the 99%.

Gérard.

Rik van Riel

2002-02-22 23:27 UTC #197 lore raw

Re: [PATCH] 2.5.5-pre1 IDE cleanup 9

Quoted 4 lines · Gérard Roudier

Thanks for the reply. But my concern is user convenience in _average_ here. Basically, I want the 99% of users that cannot afford neither need nor want PCI hotplug to have their system just dead in order to make happy the 1%.

Following this logic, we should just fix the thing for laptop users and ignore the few folks who run multiple SCSI busses, right ?

Of course you'll shout bloody murder since you're part of the 1% now ;)

I guess we want a solution which works for both situations, instead of people discouraging each other from fixing the kernel for situations they're not experiencing themselves.

regards,

Rik

Signature · 4 lines

"Linux holds advantages over the single-vendor commercial OS"
    -- Microsoft's "Competing with Linux" document

http://www.surriel.com/		http://distro.conectiva.com/

Greg KH

2002-02-22 20:35 UTC #198 lore raw

Re: [PATCH] 2.5.5-pre1 IDE cleanup 9

Quoted 2 lines · Andre Hedrick

Does INT13/INT19 Bios call mean anything?

To me, no. I do not know anything about IDE. :)

I thought we were talking about SCSI PCI drivers here.

Quoted 8 lines

The problem is how do you deal with multiple HOSTs given there drivers are not (have not checked lately) capable of discrete HOST addition and removal.
SCSI/ATA share the same problem IIRC, the host/chipset drivers load all the device hosts who match that driver code.
What am I missing?

Nothing. It is the same problem for IDE PCI drivers. In order for PCI Hotplug to work on these devices, they have to implement the 2.4 pci interface. If they do that, they work with PCI hotplug systems. If they do not, they don't.

thanks,

greg k-h

Andre Hedrick

2002-02-22 20:46 UTC #199 lore raw

Re: [PATCH] 2.5.5-pre1 IDE cleanup 9

Quoted 7 lines · Greg KH

Quoted 2 lines · Andre Hedrick
Does INT13/INT19 Bios call mean anything?
To me, no. I do not know anything about IDE. :)
I thought we were talking about SCSI PCI drivers here.

Under x86 SCSI is hooked w/ INT13/INT19 calls, that is how you can boot a SCSI "Direct-Access", that is why I moved away from ATA and was hoping it would be "generic storage"

Quoted 7 lines

Quoted 7 lines
The problem is how do you deal with multiple HOSTs given there drivers are not (have not checked lately) capable of discrete HOST addition and removal.
SCSI/ATA share the same problem IIRC, the host/chipset drivers load all the device hosts who match that driver code.

Quoted 6 lines

Quoted 1 line
What am I missing?
Nothing. It is the same problem for IDE PCI drivers. In order for PCI Hotplug to work on these devices, they have to implement the 2.4 pci interface. If they do that, they work with PCI hotplug systems. If they do not, they don't.

Okay, but where is a card that is capable, and cardbus is not the same issue.

Cheers,

Andre Hedrick
Linux Disk Certification Project Linux ATA Development

Vojtech Pavlik

2002-02-22 23:47 UTC #200 lore raw

Re: [PATCH] 2.5.5-pre1 IDE cleanup 9

Quoted 7 lines · Andre Hedrick

Quoted 4 lines
Nothing. It is the same problem for IDE PCI drivers. In order for PCI Hotplug to work on these devices, they have to implement the 2.4 pci interface. If they do that, they work with PCI hotplug systems. If they do not, they don't.
Okay, but where is a card that is capable, and cardbus is not the same issue.

Any PCI card can be hot-plugged and hot-unplugged if the *mainboard* supports it. Still talking about (un)plugging the controllers, not the drives. And this is the same issue as cardbus.

Signature · 2 lines

Vojtech Pavlik
SuSE Labs

Greg KH

2002-02-22 20:48 UTC #201 lore raw

Re: [PATCH] 2.5.5-pre1 IDE cleanup 9

Quoted 8 lines · Gérard Roudier

Thanks for the reply. But my concern is user convenience in _average_ here. Basically, I want the 99% of users that cannot afford neither need nor want PCI hotplug to have their system just dead in order to make happy the 1%.
In other word, I donnot care about this 1% if it makes run a tiny risk to the 99% to get inconvenience a single second. Btw, I am among the 99%.

With some of the upcoming changes int 2.5 (like initramfs), it will be more important than ever to move to the current PCI API.

I'm not saying that you are being forced to convert the code, but more and more the driver will not work with new features.

Right now I just point people to the Adaptec cards when they complain about their controllers not working with hotplug :)

thanks,

greg k-h

Erik Andersen

2002-02-22 21:23 UTC #202 lore raw

Re: [PATCH] 2.5.5-pre1 IDE cleanup 9

In reply to Erik Andersen

Quoted 5 lines · Gérard Roudier

Thanks for the reply. But my concern is user convenience in _average_ here. Basically, I want the 99% of users that cannot afford neither need nor want PCI hotplug to have their system just dead in order to make happy the 1%.

I think _lots_ of people have laptops -- far more than just 1%. Those laptops have cardbus slots, which need PCI hotplug to work properly. And I _know_ that Linus has a laptop with a cardbus slot...

-Erik

--
Erik B. Andersen http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--

Gérard Roudier

2002-02-22 22:18 UTC #203 lore raw

Re: [PATCH] 2.5.5-pre1 IDE cleanup 9

Quoted 11 lines · Erik Andersen

Quoted 5 lines · Gérard Roudier
Thanks for the reply. But my concern is user convenience in _average_ here. Basically, I want the 99% of users that cannot afford neither need nor want PCI hotplug to have their system just dead in order to make happy the 1%.
I think _lots_ of people have laptops -- far more than just 1%. Those laptops have cardbus slots, which need PCI hotplug to work properly. And I _know_ that Linus has a laptop with a cardbus slot...

My reply was in the only context of sym53c8xx PCI-SCSI chips. Even in the full SCSI context + laptops, the 'lots of people' you are talking about should be near absolute zero in my opinion. :)

Gérard.

Erik Andersen

2002-02-22 22:23 UTC #204 lore raw

Re: [PATCH] 2.5.5-pre1 IDE cleanup 9

Quoted 4 lines · Gérard Roudier

My reply was in the only context of sym53c8xx PCI-SCSI chips. Even in the full SCSI context + laptops, the 'lots of people' you are talking about should be near absolute zero in my opinion. :)

I must be an absolute zero then, since I (at least try to) use my Adaptec 1480 card in my laptop fairly regularly. Perhaps we should call up Adaptec and tell them to halt manufacturing?

-Erik

--
Erik B. Andersen http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--

Erik Andersen

2002-02-22 21:30 UTC #205 lore raw

Re: [PATCH] 2.5.5-pre1 IDE cleanup 9

Quoted 3 lines · Greg KH

Right now I just point people to the Adaptec cards when they complain about their controllers not working with hotplug :)

Well, even aic7xxx actually don't do hotplug correctly either. Or more accurately, with my Adaptec 1480B I can hotplug, and I can then hot-unplug, but I can't hotplug again... Just try pulling the 1480 card and then doing a
cat /proc/scsi/aic7xxx/0
some time and watch all the fireworks,

-Erik

--
Erik B. Andersen http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--

Greg KH

2002-02-22 21:48 UTC #206 lore raw

Re: [PATCH] 2.5.5-pre1 IDE cleanup 9

Quoted 11 lines · Erik Andersen

Quoted 3 lines · Greg KH
Right now I just point people to the Adaptec cards when they complain about their controllers not working with hotplug :)
Well, even aic7xxx actually don't do hotplug correctly either. Or more accurately, with my Adaptec 1480B I can hotplug, and I can then hot-unplug, but I can't hotplug again... Just try pulling the 1480 card and then doing a
cat /proc/scsi/aic7xxx/0
some time and watch all the fireworks,

Hm, I didn't try the 'cat' test, but I did successfully unplug and then add a card, and then spin up the drives attached to that drive. But that was a long time ago. Things might have changed since then.

This is with a cardbus device, right? I have never looked into them before.

thanks,

greg k-h

Erik Andersen

2002-02-22 21:54 UTC #207 lore raw

Re: [PATCH] 2.5.5-pre1 IDE cleanup 9

Quoted 6 lines · Greg KH

Hm, I didn't try the 'cat' test, but I did successfully unplug and then add a card, and then spin up the drives attached to that drive. But that was a long time ago. Things might have changed since then.
This is with a cardbus device, right? I have never looked into them before.

Yup. One of these:
http://www.adaptec.com/worldwide/product/proddetail.html?prodkey=APA-1480B
which I have been using to connect my MO drive to my laptop. I'm happy to provide details. I spent about two hours last week digging through the various layers trying to understand how the SCSI layer had leftover state. I found one little bug, but had to move on to other things before I'd found the cause,

-Erik

--
Erik B. Andersen http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--

Vojtech Pavlik

2002-02-22 23:44 UTC #208 lore raw

Re: [PATCH] 2.5.5-pre1 IDE cleanup 9