linux-2.5.5-pre1

linux-2.5.5-pre1

[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

----

Summary of changes from v2.5.4 to v2.5.5-pre1
============================================

<paulus@tango.paulus.ozlabs.org> (02/02/10 1.248.5.1)
	Import arch/ppc and include/asm-ppc changes from linuxppc_2_5 tree

<reality@delusion.de> (02/02/10 1.263)
	[PATCH] 2.5.4-pre6 apm compile fix

	Make apm compile properly and without warnings.

<reality@delusion.de> (02/02/10 1.264)
	[PATCH] 2.5.4-pre6 compile fix for i386/kernel/signal.c

	Fixe a compiler warning in signal.c due to a missing prototype for
	"do_coredump".

<torvalds@home.transmeta.com> (02/02/10 1.262.1.1)
	Remove warning in /proc inode conversions.

<davem@pizda.ninka.net> (02/02/10 1.262.2.1)
	Clean up sparc64 build.

<davem@pizda.ninka.net> (02/02/10 1.262.2.2)
	Split protocol specific information out from struct sock.
	Work done by Arnaldo Carvalho de Melo.

<davem@pizda.ninka.net> (02/02/10 1.262.2.3)
	Netfilter bugfixes from Harald and Paul Russell.

<davem@pizda.ninka.net> (02/02/10 1.262.2.4)
	Add writev support to TUN driver.
	From Eddie C. Dost

<axboe@burns.home.kernel.dk> (02/02/11 1.262.3.1)
	This patch fixes a bug that appears when you have more than 16 physical
	LUNs attached to a cciss controller, and a tape drive is beyond the 16th
	LUN.  In such a case, the tape drive would not be accessible without this
	patch.  Applies to 2.5.4-pre3.  -- steve.cameron@compaq.com

<axboe@burns.home.kernel.dk> (02/02/11 1.262.3.2)
	setup_str[] only used in modular builds.

<axboe@burns.home.kernel.dk> (02/02/11 1.262.3.3)
	add more build config files to ignore list

<axboe@burns.home.kernel.dk> (02/02/11 1.262.3.4)
	Fix for cciss driver where I had passed the wrong
	first parameter to grok_partitions in the ioctl for
	registering a new disk.

<axboe@burns.home.kernel.dk> (02/02/11 1.262.3.5)
	Replace awful schedule_timeout polling code with
	completions.  Applies to 2.5.4-pre3
	-- steve.cameron@compaq.com

<axboe@burns.home.kernel.dk> (02/02/11 1.262.3.6)
	Replace calls to suser() with capable().  Move those checks to be
	as late as possible to avoid accounting overcharging processes with
	privilege usage.  Applies to 2.5.4-pre3
	-- steve.cameron@compaq.com

<axboe@burns.home.kernel.dk> (02/02/11 1.262.3.7)
	Make cciss driver contribute to entropy pool.
	Applies to 2.5.4-pre3
	-- steve.cameron@compaq.com

<axboe@burns.home.kernel.dk> (02/02/11 1.262.3.8)
	change cciss driver version number.  Applies to 2.5.4-pre3
	-- steve.cameron@compaq.com

<axboe@burns.home.kernel.dk> (02/02/11 1.262.3.9)
	Small batch of IDE code cleanups from Pavel Machek

<axboe@burns.home.kernel.dk> (02/02/11 1.262.3.10)
	thread_saved_pc fix from akpm

<paulus@tango.paulus.ozlabs.org> (02/02/11 1.257.2.2)
	Update PPC for recent generic changes; in particular adapt to
	having the thread_info struct at the base of the stack and
	the task_struct elsewhere.

<axboe@burns.home.kernel.dk> (02/02/11 1.262.3.11)
	Remove nr_sectors from bio_end_io end I/O callback. It was a relic
	from when completion was potentially called more than once to indicate
	partial end I/O. These days bio->bi_end_io is _only_ called when I/O
	has completed on the entire bio.

<axboe@burns.home.kernel.dk> (02/02/11 1.262.3.12)
	bio_endio doesn't take nr_sectors argument anymore.

<rth@fidel.sfbay.redhat.com> (02/02/11 1.262.4.1)
	Update Alpha UP for thread_info and scheduler changes.

<rth@fidel.sfbay.redhat.com> (02/02/11 1.262.4.2)
	Fixes for premature thread_info changeset.
	Minor warning removal.

<mingo@earth2.(none)> (02/02/11 1.262.6.1)
	merge to the -K3 scheduler.

<greg@soap.kroah.net> (02/02/11 1.262.7.1)
	patch from Peter Osterlund <petero2@telia.com> to fix usb-storage debug code
	compile problem.

<greg@soap.kroah.net> (02/02/11 1.262.7.2)
	patch from David Probnell, updating the USB error-codes.txt file

<greg@soap.kroah.net> (02/02/11 1.262.7.3)
	patch by Simon Evans <spse@secret.org.uk> that adds a Konica USB webcam driver

<greg@soap.kroah.net> (02/02/11 1.262.7.4)
	removed 'typedef' from the Digi Acceleport usb-serial driver.

<greg@soap.kroah.net> (02/02/11 1.262.7.5)
	removed 'typedef' from the ftdi_sio usb-serial driver.

<greg@soap.kroah.net> (02/02/11 1.262.7.6)
	removed 'typedef' from the IO Networks Edgeport usb-serial driver.

<greg@soap.kroah.net> (02/02/11 1.262.7.7)
	removed 'typedef' from the Keyspan usb-serial drivers.

<greg@soap.kroah.net> (02/02/11 1.262.7.8)
	removed 'typedef' from the kl5kusb105 usb-serial driver.

<rth@fidel.sfbay.redhat.com> (02/02/11 1.262.4.3)
	Update Alpha SMP for the new scheduler and preempt api change.

<jgarzik@rum.normnet.org> (02/02/11 1.262.5.2)
	Add a couple #includes to fix the alpha build.

<sfr@canb.auug.org.au> (02/02/11 1.262.8.1)
	[PATCH] 2.5.4-pre6 apm compile fix

	Here is the patch against 2.5.4.  I have compiled this patch under
	2.5.3, so it should still be OK.

	This patch just resyncs the driver with 2.4.18-pre (which is what is
	being testd by others).  The only outstanding known problem is some
	very strange interaction with VMWARE.  But otherwise people seem
	happy with the changes.

	Original announcement to Dave Jones and Marcelo:

		Update a couple of email addresses
		Fix the idle handling (this is an improved version of the fix
			that Alan Cox has in his -ac tree)
		Notify user mode of suspend events before drivers (fix)
		Make the idling percentage boot time configurable
		Rename kapm-idled to kapmd

	Credit to Andreas Steinmetz, Russell King, Thomas Hood and me.

	More small updates to come.
	--
	Cheers,
	Stephen Rothwell                    sfr@canb.auug.org.au
	http://www.canb.auug.org.au/~sfr/

<rml@tech9.net> (02/02/11 1.271)
	[PATCH] Optimized UP preempt fix

	I previously sent a patch by Mikael Pettersson to fix the UP+preempt
	problem.  It seems from your BK repository you have not yet merged it;
	if so, this patch takes a different approach which is optimal, removing
	the unneeded conditional altogether in the UP case.  I have verified UP
	and SMP are now correct.  Patch is against 2.5.4, please apply.

		Robert Love

<viro@math.psu.edu> (02/02/11 1.272)
	[PATCH] (2.5.4) death of ->i_zombie

		Rediffed to 2.5.4, documentation added.  This variant grabs
	->s_vfs_rename_sem only for cross-directory renames.

<davidm@hpl.hp.com> (02/02/11 1.276)
	[PATCH] updated version of VM_DATA_DEFAULT_FLAGS patch

	Here is the latest version of the VM_DATA_DEFAULT_FLAGS patch
	(relative to 2.5.4).

		--david

<rob@osinvestor.com> (02/02/11 1.277)
	[PATCH] drivers/char/pcwd.c

	This patch to drivers/char/pcwd.c against 2.5.4 does two things:
	a) Makes one code snippet more consistent with the rest of the code, and
	b) Makes it possible for this code to actually work

	Nearly the same patch against 2.4 was reviewed by Alan, and, well, the
	maintainer seems to have disappeared.  It's also looking like no one uses
	this driver much either.

	Regards,
	Rob Radez

<davidm@hpl.hp.com> (02/02/11 1.278)
	[PATCH] dma64_addr_t fix ups

	This patch fixes up two places whre dma64_addr_t is used incorrectly.
	Note that pci_dev->dma_mask and the second argument to
	blk_queue_bounce_limit() are both u64, so the old types clearly are
	wrong (besides, dma64_addr_t is supposed to be used only with the
	pci_dac_*() routines, as per DaveM's earlier mail).

		--david

<davidm@hpl.hp.com> (02/02/11 1.279)
	[PATCH] fix for elf coredump deadlock

	This patch fixes a deadlock condition in the elf core dump that shows
	on ia64 because ELF_CORE_COPY_REGS() needs to access user space (to
	get a hold of the backing store of the stacked registers).  Marcelo
	already accepted this into 2.4.17.

		--david

<davidm@hpl.hp.com> (02/02/11 1.280)
	[PATCH] video console fix up

	Here is the last patch for today: it enables writecombined mappings
	for ia64 in fbmem.c and gets rid of an ugly ia64 simulator workaround
	in vgacon.c which isn't needed anymore.

		--david

<rth@twiddle.net> (02/02/11 1.281)
	[PATCH] discarded section problem

	What should be happening with the references to the discarded .text.exit
	section?  I see a __devexit_p mentioned in Documentation/pci.txt, but it
	hasn't been implemented except for down inside ieee1394.

	In any case, I need something like the following in order to build with
	pre-release binutils 2.12.  If this sort of thing is acceptible I can
	prepare a more comprehensive patch.

<reiser@namesys.com> (02/02/11 1.282)
	[PATCH] 01-ioerrors-checks-2.diff

	    Make sure all reiserfs_find_entry users correctly understand IO_ERROR retval.

<reiser@namesys.com> (02/02/11 1.283)
	[PATCH] 02-savelink_nospace_nowarning.diff

	   Do not print a warning if savelink was not created due to lack of space.

<reiser@namesys.com> (02/02/11 1.284)
	[PATCH] 03-savelink_dir_truncate.diff

	   Do not panic on incorrect savelink entries (truncate on directory).
	   Currently we suppose these can be created if switching between kernels
	   with and without savelinks support.

<reiser@namesys.com> (02/02/11 1.285)
	[PATCH] 04-hash_autodetect_fix.diff

	   Correctly detect and print hash values, when manual hash detection is used.

<reiser@namesys.com> (02/02/11 1.286)
	[PATCH] 05-corrupt_items_checks.diff

	   Do not panic when encountered item of unknown type, just print a warning.

<reiser@namesys.com> (02/02/11 1.287)
	[PATCH] 06-kmalloc_cleanup.diff

	   Convert all the code to use reiserfs_{kmalloc,kfree}. Remove all extra
	   reiserfs_{kmalloc,kfree} overhead if CONFIG_REISERFS_CHECK is not set.

<reiser@namesys.com> (02/02/11 1.288)
	[PATCH] 07-reiserfs-bitmap-journal-read-ahead.diff

	   Speed up reading of journal bitmaps. RAID users should notice significant
	   speedup when mounting reiserfs over self-rebuilding RAID arays.

<reiser@namesys.com> (02/02/11 1.289)
	[PATCH] 08-truncate_update_mtime.diff

	   truncate now correctly sets mtime always. Before this fix, mtime was not
	   updated if truncated file was of zero length or if new filesize was bigger
	   then old.
	   Problem was noticed by Matthias Andree <ma@dt.e-technik.uni-dortmund.de>

<viro@math.psu.edu> (02/02/11 1.290)
	[PATCH] BKL-free ext2_get_block()

		Linus, I've got the first of BKL-removal ext2 patches ready to
	go.  It removes BKL from ext2_get_block() and guts of ext2_truncate().
	The only place where we hold BKL on these paths is in dquot.c - probably
	can be easily dealt with, but threading quota is a separate story.

		Inode metadata (pointers to blocks, both in inode itself and in
	indirect blocks, preallocation data and allocation goal) are protected
	by rwlock - EXT2_I(inode)->i_meta_lock.

		Next steps will involve threading the group descriptors and bitmaps
	handling - lock_super() uses in ext2 are going to die.  However, that's
	a separate story - let's do that step-by-step.

		I suspect that patch below will take care of almost all BKL contention
	from ext2 - we still have BKL held over directory operations, but for regular
	files that's it.

<vandrove@vc.cvut.cz> (02/02/11 1.292)
	[PATCH] zisofs compilation error

	* zisofs_cleanup cannot be __exit, as it is invoked from __init
	  section when register_filesystem() fails.

			Petr Vandrovec

<vandrove@vc.cvut.cz> (02/02/11 1.293)
	[PATCH] 2.5.4-pre5 and ncpfs fill_super changes

	* fs/ncpfs/inode.c: Return reasonable error codes instead of universal
	     -EINVAL. Remove printk() as reasonable code is returned.
	     Set maximum file size limit on ncpfs to 4GB-1.

	* fs/ncpfs/sock.c: Return correct error code when send() fails.

		Petr Vandrovec

<jgarzik@rum.normnet.org> (02/02/12 1.294)
	Various minor documentation / comment typo fixes
	for net drivers 3c509, acenic, ni52, and skfp.

	Via Dave Jones.

<jgarzik@rum.normnet.org> (02/02/12 1.295)
	request_region cleanups from 2.4 and the kernel janitors.

	Via Dave Jones.

<jgarzik@rum.normnet.org> (02/02/12 1.296)
	Remove deprecated SIOCDEVPRIVATE ioctls in net drivers
	3c59x, eepro100, sis900, and tulip.

	Also, update eepro100 Becker URL.

	Contributor: Dave Jones

<jgarzik@rum.normnet.org> (02/02/12 1.297)
	Merge basic ethtool ioctl support from 2.4.x for 3c505 and sis900
	net drivers.  Merge two sis900 bug fixes from 2.4.x.

	Via Dave Jones.

<jgarzik@rum.normnet.org> (02/02/12 1.298)
	Fix typo in aironet4500 net driver return value, s/NODEV/-ENODEV/,
	which prevented the driver from building.

	Via Dave Jones.

<jgarzik@rum.normnet.org> (02/02/12 1.299)
	Merge cosmetic cleanup and driver version increment
	for dmfe net driver from 2.4.x.

	Via Dave Jones.

<jgarzik@rum.normnet.org> (02/02/12 1.300)
	Add new ISAPNP card id to 'ne' net driver.

	Via Dave Jones.

<jgarzik@rum.normnet.org> (02/02/12 1.301)
	Merge 8139too net driver oops fix from 2.4.x.

	Fix originally by Andreas Dilger IIRC, merged by Dave Jones.

<jgarzik@rum.normnet.org> (02/02/12 1.302)
	Merge ns83820 GigE net driver changes from 2.4.x kernel:
	0.13a - optical transceiver support added
		by Michael Clark <michael@metaparadigm.com>
	0.13b - call register_netdev earlier in initialization
		suppress duplicate link status messages
	0.15	get ppc (big endian) working

	Via Dave Jones.

<jgarzik@rum.normnet.org> (02/02/12 1.303)
	Merge ethtool support and PPC fix into pcnet32 net driver,
	from 2.4.x.
	Also, remove deprecated SIOCDEVPRIVATE ioctl calls.

	Via Dave Jones.

<jgarzik@rum.normnet.org> (02/02/12 1.304)
	Merge changes from yellowfin GigE net driver version LK1.1.6:
	* Only print warning on truly "oversized" packets
	* Fix theoretical bug on gigabit cards - return to 1.1.3 behavior

	Contributor: Val Henson

<jgarzik@rum.normnet.org> (02/02/12 1.305)
	A minor patch to remove the last isa_read/isa_write function in
	the ibmtr token ring net driver.

	Contributor:
	Mike Phillips
	Linux Token Ring Project

<davem@pizda.ninka.net> (02/02/11 1.262.2.5)
	Fix recalc_sigpending handling.

<jgarzik@rum.normnet.org> (02/02/12 1.306)
	Cleanup and fixes to sleeping/scheduling in the olympic token ring
	net driver.  Also included are a couple of minor error reporting
	updates and the proper detection for cardbus removal.

	Contributor:
	Mike Phillips
	Linux Token Ring Project

<torvalds@home.transmeta.com> (02/02/11 1.293.1.1)
	Fix up typo from Al's ext2 balloc cleanups.

<cyeoh@samba.org> (02/02/11 1.293.1.2)
	[PATCH] mmap can return incorrect errno

	mmap currently sets errno to EINVAL when it should be ENOMEM.
	SUS/POSIX states that ENOMEM should be returned when:

	"MAP_FIXED was specified, and the range [addr, addr + len) exceeds
	that allowed for the address space of a process; or if MAP_FIXED was
	not specified and there is insufficient room in the address space to
	effect the mapping."

	The following patch (against 2.4.17) fixes this behaviour:

<jgarzik@rum.normnet.org> (02/02/12 1.307)
	Add new pci id to via-rhine net driver.

<pmanolov@Lnxw.COM> (02/02/11 1.293.2.1)
	[PATCH] pegasus.h

	this patch somehow didn't get applied to 2.5.4
	so i resend it.  It is pretty harmless - only
	adds 3 more devices and 2 vendor ids into pegasus.h :-)

<vojtech@suse.cz> (02/02/11 1.293.2.2)
	[PATCH] Update of USB input drivers to the latest versions

	Now that the input core changes have made it into 2.5 I can finally
	update the USB input drivers to their latest versions.

	Here is a patch that does that.

	In detail:

		HID driver:
			Fix a bug in descriptor parsing (array/variable),
				namely visible with Logitech new joysticks and mice
			Fix bugs in logical/physical min/max parsing
			Fix bugs in exponent parsing
			Remove workaround for low-speed devices with >8 byte
				reports, fix this in a correct way (bigger irq
				request)
			Untangle some code (fetc_item())
			Implement asynchronous input/output/feature report
				reading and writing
			Implement (hopefully) proper locking in the above
			Implement support for devices with an output endpoint
			Add some support functions for force feedback support
				currently in development
			Add entries to the debug dump code, including FF and
				exponents
			Add more mappings into the hid-input interface
			Cleanups here and there

		usbkbd driver:

			Make LED URBS use GFP_ATOMIC, they'll be called from a
				completion handler
			Remove dependency on hid.h

		usbmouse driver:

			Just conversion to the new input core, minor cleanups

		wacom driver:

			Just conversion to the new input core.

<viro@math.psu.edu> (02/02/12 1.281.1.1)
	[PATCH] BKL shifted into ->lookup()

		OK, here comes: ->lookup() had lost BKL, all in-tree instances of
	->lookup() converted.

		I'm adding Documentation/filesystems/porting - with the list of
	API changes since 2.4.  Are you OK with that format?

	(and yes, this sucker is *post*-compile ;-)

<viro@math.psu.edu> (02/02/12 1.311)
	[PATCH] BKL shifted into ->truncate()

		BKL shifted into all instances of ->truncate().  Callers updated.

<jgarzik@rum.normnet.org> (02/02/12 1.307.1.1)
	Remove GMAC net driver, with the ok of the PPC folks.
	'sungem' which DaveM is maintaining is the replacement.

<jgarzik@rum.normnet.org> (02/02/12 1.307.1.2)
	Merge bug fixes and PPC-specific feature additions from 2.4.x
	into bmac and mace net drivers.

	Via Dave Jones.

<jgarzik@rum.normnet.org> (02/02/12 1.307.1.3)
	Add new pci id to 8139too net driver, for Allied Telesyn cardbus cards.

	Contributor: Go Taniguchi

<jgarzik@rum.normnet.org> (02/02/12 1.293.3.1)
	Add Macrolink board PCI ids to pci.ids and pci_ids.h.

	Contributor: Ed Vance @ Macrolink

<mingo@elte.hu> (02/02/12 1.293.4.1)
	optimization, cleanup: switch_to(3 parameter) => switch_to(2 parameter).

<mingo@elte.hu> (02/02/12 1.293.4.2)
	move sched_find_first_bit() from mmu_context.h to bitops.h, it belongs there.

<mingo@elte.hu> (02/02/12 1.293.4.3)
	a cleanup and a bugfix in the preemptive kernel:

	- the PREEMPT_ACTIVE trick is not needed

	- schedule() should check for need_resched, we might miss a
	  reschedule otherwise.

	the cleanup also fixes the bug. The only reason why i kept
	preempt_schedule() was to fix up p->state to TASK_RUNNING,
	to make it possible to preempt from places that mark the
	task TASK_UNINTERRUPTIBLE before adding the task to a waitqueue,
	and thus a preemption in that small window could cause the
	task to be removed from the runqueue erroneously.

<mingo@elte.hu> (02/02/13 1.293.4.4)
	do not unlock irqs before calling schedule() - besides being a small exit() speedup, this also
	fixes a preemption race that was introduced by my removal of PREEMPT_ACTIVE.

<vojtech@suse.cz> (02/02/12 1.293.2.3)
	usb hid driver:
		- patch to fix bug where urbs were freed too soon.

<mdiehl@mdiehl.de> (02/02/12 1.293.2.4)
	[PATCH] usb_set_interface: correct toggle reset

	this is a patch to prevent usb_set_interface() from erroneously resetting
	the toggles for all endpoints instead of only the affected ones from the
	requested interface/altsetting. I've also added some missing parentheses
	to related macros in usb.h as I prefered not to take special care for
	nasty side-effects ;-)

	Patch below was created against 2.4.18-pre9 (with some lines of offset it
	applies to 2.5.4-pre5 as well).

	Tested in multi-interface configuration to provide evidence it:
	* correctly identifies the affected endpoints and resets the toggles
	* doesn't touch endpoints from other interfaces
	* provides correct handling of shared EP0
	* solves an issue I had with 2.4.18-pre9 where setting one interface
	  occasionally caused transfers on other interface to hang due to lost
	  toggle synchronisation

	Despite being a pure bugfix, well localized and (IMHO) pretty obviously
	correct wrt. USB-spec, I'd like to suggest including this in early
	2.4.19-pre. Just in case some existing driver would somehow workaround
	the currently wrong behavior and might break with this fix. And it's
	not very urgent right now, as we are probably close to 2.4.18-rc1.

	Regards,
	Martin

<mingo@elte.hu> (02/02/13 1.293.4.5)
	this is a fragile piece of the ptrace code, the code relies on a single wakeup coming from the parent.
	This fix is necessery after the preempt_schedule() cleanups, it unbreaks 'strace strace ...'.

<mingo@elte.hu> (02/02/13 1.293.4.6)
	- make the preempt-enable test cheaper - only test for the (very rare) TIF_NEED_RESCHED
	  condition, we test the preemption count in preempt_schedule(). This reduces the icache
	  footprint and the overhead of preemption.

	- plus optimize the irq-path preemption check a bit.

<mingo@elte.hu> (02/02/13 1.293.4.7)
	cleanups.

<perex@perex.cz> (02/02/13 1.262.9.1)
	[PATCH] ALSA patch for 2.5.4

	Integrate ALSA into v2.5.4

	            Jaroslav

<elenstev@mesatop.com> (02/02/13 1.316)
	[PATCH] 2.5.4, add help texts to drivers/net/pcmcia/Config.help

	Add help texts for CONFIG_PCMCIA_AXNET and CONFIG_PCMCIA_XIRCOM

<torvalds@home.transmeta.com> (02/02/13 1.317)
	Make Jaroslav the sound maintainer, remove Alan on his request.

<jgarzik@rum.normnet.org> (02/02/13 1.318)
	Include linux/compiler.h in include/asm-i386/bitops.h,
	for the definition of unlikely().

<mec@shout.net> (02/02/13 1.317.1.1)
	[PATCH] menuconfig: fix error exit if awk fails

	This one-liner fixes an error case in Menuconfig when awk fails.
	Written by Andrew Church (achurch@achurch.org).
	Reviewed and tested by Michael Elizabeth Chastain (mec@shout.net).

	Michael Elizabeth Chastain

	===

<paulus@samba.org> (02/02/13 1.317.1.3)
	[PATCH] fix sd_find_target (v2.5.4)

	This patch fixes a compile error on PPC.  It's in sd_find_target, a
	function that returns a kdev_t.

<paulus@samba.org> (02/02/13 1.317.1.4)
	[PATCH] flush_icache_user_range (v2.5.4)

	The patch below changes access_process_vm to use a new architecture
	hook, flush_icache_user_range, instead of flush_icache_page, and adds
	a definition of flush_icache_user_range which does the same thing as
	flush_icache_page for all architectures except PPC.  (The PPC update
	that is in Linus' BK tree already includes a suitable definition of
	flush_icache_user_range.)

	The reason for doing this is that when flush_icache_page is called
	from do_no_page or do_swap_page, I want to be able to do the flush
	conditionally, based on the state of the page.  In contrast,
	access_process_vm needs to do the flush unconditionally since it has
	just modified the page.  In the access_process_vm case it is useful to
	have the information about the user address and length that have been
	modified since then we can just flush the affected cache lines rather
	than the whole page.

	This patch should make it easy to improve performance on alpha, since
	there (as I understand it) the icache flush is not needed at all in
	do_no_page or do_swap_page, but is needed in access_process_vm.  All
	that is needed is to make flush_icache_page a noop on alpha.  The
	patch below doesn't do this, I'll let the alpha maintainers push that
	change if they want.

<torvalds@home.transmeta.com> (02/02/13 1.320)
	update version

<torvalds@home.transmeta.com> (02/02/13 1.321)
	Avoid pci driver warnings on 64-bit hosts

<ak@muc.de> (02/02/13 1.322)
	[PATCH] x86_64-merge file.c warning

	Just an gcc 3.1 warning fix. It now warns about __FUNCTION__ string
	concatenation. Also remove the check because it does not seem to trigger
	ever.

	-Andi

<ak@muc.de> (02/02/13 1.323)
	[PATCH] x86_64 merge: arch + asm

	This adds the x86_64 arch and asm directories and a Documentation/x86_64.

	It took a bit longer because I first had to make preemption and thread_info
	work and also found some other bugs while doing this. The port has been
	tested for a long time on UP.

	I'm not sure what I should describe.  A lot is based on i386 with
	a lot of cleanups. I wrote a paper about it for last year's OLS that describes
	most of the changes (ftp://ftp.firstfloor.org/pub/ak/x86_64.ps.gz). It is
	a bit outdated now, but should give a good overview.

	It currently has a completely cut'n'pasted from others+hacked 32bit
	emulation. I hope to clean that up in the future by merging the generic
	core of this with other 64bit archs.

	Thanks,
	-Andi

<ak@muc.de> (02/02/13 1.324)
	[PATCH] x86-64 MAINTAINERS

	Add Andi Kleen as x86-64 maintainer.

<ak@muc.de> (02/02/13 1.325)
	[PATCH] x86_64 merge: fs/proc/inode.c #include fix

	fs/proc/inode.c is using __init, but for some reason missing an
	#include <linux/init.h>. Add this.

Re: linux-2.5.5-pre1

[Matthias Andree]

On Wed, 13 Feb 2002, Linus Torvalds wrote:

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

AFAIK, ALSA 0.9 supported this, 0.5 did not, so take this question as
"what version is that ALSA stuff that's been merged?" if you like.

Re: linux-2.5.5-pre1

[Jeff Garzik]

Matthias Andree wrote:
> 
> On Wed, 13 Feb 2002, Linus Torvalds wrote:
> 
> > 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!  :)

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

Re: linux-2.5.5-pre1

[Daniel Phillips]

On February 13, 2002 11:38 pm, Linus Torvalds wrote:
> 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

-- 
Daniel

Re: linux-2.5.5-pre1

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

---------

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

Re: linux-2.5.5-pre1

[Allan Sandfeld]

On Thursday 14 February 2002 02:35, -= M.J. Prinsen =- wrote:
> 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

Re: linux-2.5.5-pre1

[Linus Torvalds]

On Thu, 14 Feb 2002, Daniel Phillips wrote:
> >
> > 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

Re: linux-2.5.5-pre1

[bert hubert]

On Wed, Feb 13, 2002 at 10:40:30PM +0000, Linus Torvalds wrote:
> 
> 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

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

Re: linux-2.5.5-pre1

[Linus Torvalds]

On Thu, 14 Feb 2002, bert hubert wrote:
>
> 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

Re: linux-2.5.5-pre1

[Thomas Capricelli]

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

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

[PATCH} 2.5.5-pre1 VESA fb

[Martin Dalecki]

[-- Attachment #1: Type: text/plain, Size: 237 bytes --]

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



[-- Attachment #2: vesafb.patch --]
[-- Type: text/plain, Size: 755 bytes --]

diff -ur linux-2.5.4/drivers/video/vesafb.c linux/drivers/video/vesafb.c
--- linux-2.5.4/drivers/video/vesafb.c	Mon Feb 11 02:50:09 2002
+++ linux/drivers/video/vesafb.c	Thu Feb 14 13:17:02 2002
@@ -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);

Re: [PATCH} 2.5.5-pre1 VESA fb

[Alan Cox]

> 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

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

Re: [PATCH} 2.5.5-pre1 VESA fb

[Martin Dalecki]

Alan Cox wrote:

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

Compile error with linux-2.5.5-pre1 & advansys scsi

[Gerold J. Wucherpfennig]

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

[PATCH] 2.5.5-pre1 IDE cleanup

[Martin Dalecki]

[-- Attachment #1: Type: text/plain, Size: 329 bytes --]

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.

[-- Attachment #2: ide-clean-8.diff --]
[-- Type: text/plain, Size: 4345 bytes --]

diff -ur linux-2.5.4/drivers/ide/ide-probe.c linux/drivers/ide/ide-probe.c
--- linux-2.5.4/drivers/ide/ide-probe.c	Fri Feb 15 04:36:43 2002
+++ linux/drivers/ide/ide-probe.c	Mon Feb 18 01:46:29 2002
@@ -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,
diff -ur linux-2.5.4/drivers/ide/ide.c linux/drivers/ide/ide.c
--- linux-2.5.4/drivers/ide/ide.c	Fri Feb 15 06:39:29 2002
+++ linux/drivers/ide/ide.c	Mon Feb 18 01:48:31 2002
@@ -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);
 
diff -ur linux-2.5.4/include/linux/ide.h linux/include/linux/ide.h
--- linux-2.5.4/include/linux/ide.h	Fri Feb 15 06:40:48 2002
+++ linux/include/linux/ide.h	Mon Feb 18 02:04:57 2002
@@ -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);

[PATCH] 2.5.5-pre1 IDE cleanup 9

[Martin Dalecki]

[-- Attachment #1: Type: text/plain, Size: 1118 bytes --]

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.



[-- Attachment #2: ide-clean-9.diff --]
[-- Type: text/plain, Size: 20002 bytes --]

diff -ur linux-2.5.4/drivers/ide/Makefile linux/drivers/ide/Makefile
--- linux-2.5.4/drivers/ide/Makefile	Mon Feb 11 02:50:09 2002
+++ linux/drivers/ide/Makefile	Tue Feb 19 02:27:50 2002
@@ -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)
diff -ur linux-2.5.4/drivers/ide/ide-cd.c linux/drivers/ide/ide-cd.c
--- linux-2.5.4/drivers/ide/ide-cd.c	Fri Feb 15 06:35:50 2002
+++ linux/drivers/ide/ide-cd.c	Tue Feb 19 03:11:03 2002
@@ -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;
 }
diff -ur linux-2.5.4/drivers/ide/ide-disk.c linux/drivers/ide/ide-disk.c
--- linux-2.5.4/drivers/ide/ide-disk.c	Fri Feb 15 06:23:11 2002
+++ linux/drivers/ide/ide-disk.c	Tue Feb 19 03:07:32 2002
@@ -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;
 }
diff -ur linux-2.5.4/drivers/ide/ide-floppy.c linux/drivers/ide/ide-floppy.c
--- linux-2.5.4/drivers/ide/ide-floppy.c	Fri Feb 15 06:47:11 2002
+++ linux/drivers/ide/ide-floppy.c	Tue Feb 19 03:14:55 2002
@@ -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;
 }
diff -ur linux-2.5.4/drivers/ide/ide-probe.c linux/drivers/ide/ide-probe.c
--- linux-2.5.4/drivers/ide/ide-probe.c	Mon Feb 18 01:46:29 2002
+++ linux/drivers/ide/ide-probe.c	Tue Feb 19 02:34:37 2002
@@ -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 */
diff -ur linux-2.5.4/drivers/ide/ide-proc.c linux/drivers/ide/ide-proc.c
--- linux-2.5.4/drivers/ide/ide-proc.c	Sun Feb 17 03:43:38 2002
+++ linux/drivers/ide/ide-proc.c	Tue Feb 19 02:59:27 2002
@@ -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);
diff -ur linux-2.5.4/drivers/ide/ide-tape.c linux/drivers/ide/ide-tape.c
--- linux-2.5.4/drivers/ide/ide-tape.c	Fri Feb 15 06:33:15 2002
+++ linux/drivers/ide/ide-tape.c	Tue Feb 19 03:12:58 2002
@@ -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");
diff -ur linux-2.5.4/drivers/ide/ide.c linux/drivers/ide/ide.c
--- linux-2.5.4/drivers/ide/ide.c	Mon Feb 18 01:48:31 2002
+++ linux/drivers/ide/ide.c	Tue Feb 19 02:57:06 2002
@@ -196,10 +196,9 @@
 int noautodma = 0;
 
 /*
- * ide_modules keeps track of the available IDE chipset/probe/driver modules.
+ * This is the anchor of the single linked list of ide device type drivers.
  */
-ide_module_t *ide_modules;
-ide_module_t *ide_probe;
+struct ide_driver_s *ide_drivers;
 
 /*
  * This is declared extern in ide.h, for access by other IDE modules:
@@ -1864,30 +1863,23 @@
 
 static void ide_probe_module (void)
 {
-	if (!ide_probe) {
-#if defined(CONFIG_KMOD) && defined(CONFIG_BLK_DEV_IDE_MODULE)
-		(void) request_module("ide-probe-mod");
-#endif /* (CONFIG_KMOD) && (CONFIG_BLK_DEV_IDE_MODULE) */
-	} else {
-		(void) ide_probe->init();
-	}
+	ideprobe_init();
 	revalidate_drives();
 }
 
 static void ide_driver_module (void)
 {
 	int index;
-	ide_module_t *module = ide_modules;
+	struct ide_driver_s *d;
 
 	for (index = 0; index < MAX_HWIFS; ++index)
 		if (ide_hwifs[index].present)
 			goto search;
 	ide_probe_module();
 search:
-	while (module) {
-		(void) module->init();
-		module = module->next;
-	}
+	for (d = ide_drivers; d != NULL; d = d->next)
+		d->driver_init();
+
 	revalidate_drives();
 }
 
@@ -3528,13 +3520,13 @@
 	return NULL;
 }
 
-int ide_register_subdriver (ide_drive_t *drive, ide_driver_t *driver, int version)
+int ide_register_subdriver (ide_drive_t *drive, ide_driver_t *driver)
 {
 	unsigned long flags;
 
 	save_flags(flags);		/* all CPUs */
 	cli();				/* all CPUs */
-	if (version != IDE_SUBDRIVER_VERSION || !drive->present || drive->driver != NULL || drive->busy || drive->usage) {
+	if (!drive->present || drive->driver != NULL || drive->busy || drive->usage) {
 		restore_flags(flags);	/* all CPUs */
 		return 1;
 	}
@@ -3618,26 +3610,26 @@
 	return 0;
 }
 
-int ide_register_module (ide_module_t *module)
+int ide_register_module (struct ide_driver_s *d)
 {
-	ide_module_t *p = ide_modules;
+	struct ide_driver_s *p = ide_drivers;
 
 	while (p) {
-		if (p == module)
+		if (p == d)
 			return 1;
 		p = p->next;
 	}
-	module->next = ide_modules;
-	ide_modules = module;
+	d->next = ide_drivers;
+	ide_drivers = d;
 	revalidate_drives();
 	return 0;
 }
 
-void ide_unregister_module (ide_module_t *module)
+void ide_unregister_module (struct ide_driver_s *d)
 {
-	ide_module_t **p;
+	struct ide_driver_s **p;
 
-	for (p = &ide_modules; (*p) && (*p) != module; p = &((*p)->next));
+	for (p = &ide_drivers; (*p) && (*p) != d; p = &((*p)->next));
 	if (*p)
 		*p = (*p)->next;
 }
@@ -3662,7 +3654,6 @@
 devfs_handle_t ide_devfs_handle;
 
 EXPORT_SYMBOL(ide_lock);
-EXPORT_SYMBOL(ide_probe);
 EXPORT_SYMBOL(drive_is_flashcard);
 EXPORT_SYMBOL(ide_timer_expiry);
 EXPORT_SYMBOL(ide_intr);
diff -ur linux-2.5.4/drivers/scsi/ide-scsi.c linux/drivers/scsi/ide-scsi.c
--- linux-2.5.4/drivers/scsi/ide-scsi.c	Fri Feb 15 06:43:18 2002
+++ linux/drivers/scsi/ide-scsi.c	Tue Feb 19 03:16:52 2002
@@ -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);
diff -ur linux-2.5.4/include/linux/ide.h linux/include/linux/ide.h
--- linux-2.5.4/include/linux/ide.h	Mon Feb 18 02:04:57 2002
+++ linux/include/linux/ide.h	Tue Feb 19 03:02:28 2002
@@ -99,8 +99,8 @@
 #undef REALLY_FAST_IO
 #endif
 
-#define HWIF(drive)		((ide_hwif_t *)((drive)->hwif))
-#define HWGROUP(drive)		((ide_hwgroup_t *)(HWIF(drive)->hwgroup))
+#define HWIF(drive)		((drive)->hwif)
+#define HWGROUP(drive)		(HWIF(drive)->hwgroup)
 
 /*
  * Definitions for accessing IDE controller registers
@@ -371,7 +371,7 @@
 
 typedef struct ide_drive_s {
 	request_queue_t		 queue;	/* request queue */
-	struct ide_drive_s 	*next;	/* circular list of hwgroup drives */
+	struct ide_drive_s	*next;	/* circular list of hwgroup drives */
 	unsigned long sleep;		/* sleep until this time */
 	unsigned long service_start;	/* time we started last request */
 	unsigned long service_time;	/* service time of last request */
@@ -531,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 */
@@ -702,10 +702,6 @@
 /*
  * Subdrivers support.
  */
-#define IDE_SUBDRIVER_VERSION	1
-
-typedef void		(ide_setting_proc)(ide_drive_t *);
-
 typedef struct ide_driver_s {
 	const char			*name;
 	byte				media;
@@ -726,25 +722,15 @@
 	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 *);
-} ide_driver_t;
-
-#define DRIVER(drive)		((ide_driver_t *)((drive)->driver))
-
-/*
- * IDE modules.
- */
-#define IDE_CHIPSET_MODULE		0	/* not supported yet */
-#define IDE_PROBE_MODULE		1
-#define IDE_DRIVER_MODULE		2
 
+	/* FIXME: Single linked list of drivers for iteration.
+	 */
+	struct ide_driver_s *next;
+} ide_driver_t;
 
-typedef struct ide_module_s {
-	int type;
-	int (*init)(void);
-	void *info;
-	struct ide_module_s *next;
-} ide_module_t;
+#define DRIVER(drive)		((drive)->driver)
 
 /*
  * ide_hwifs[] is the master data structure used to keep track
@@ -755,9 +741,8 @@
  *
  */
 #ifndef _IDE_C
-extern	ide_hwif_t	ide_hwifs[];		/* master data repository */
-extern	ide_module_t	*ide_modules;
-extern	ide_module_t	*ide_probe;
+extern struct hwif_s ide_hwifs[];		/* master data repository */
+extern struct ide_driver_s *ide_drivers;
 #endif
 extern int noautodma;
 
@@ -1060,9 +1045,11 @@
 int ide_reinit_drive (ide_drive_t *drive);
 
 #ifdef _IDE_C
-#ifdef CONFIG_BLK_DEV_IDE
-int ideprobe_init (void);
-#endif /* CONFIG_BLK_DEV_IDE */
+# ifdef CONFIG_BLK_DEV_IDE
+/* Probe for devices attached to the systems host controllers.
+ */
+extern int ideprobe_init (void);
+# endif
 #ifdef CONFIG_BLK_DEV_IDEDISK
 int idedisk_reinit (ide_drive_t *drive);
 int idedisk_init (void);
@@ -1085,12 +1072,12 @@
 #endif /* CONFIG_BLK_DEV_IDESCSI */
 #endif /* _IDE_C */
 
-int ide_register_module (ide_module_t *module);
-void ide_unregister_module (ide_module_t *module);
+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);
-int ide_register_subdriver (ide_drive_t *drive, ide_driver_t *driver, int version);
-int ide_unregister_subdriver (ide_drive_t *drive);
-int ide_replace_subdriver(ide_drive_t *drive, const char *driver);
+extern int ide_register_subdriver(ide_drive_t *drive, ide_driver_t *driver);
+extern int ide_unregister_subdriver(ide_drive_t *drive);
+extern int ide_replace_subdriver(ide_drive_t *drive, const char *driver);
 
 #ifdef CONFIG_BLK_DEV_IDEPCI
 #define ON_BOARD		1

Re: [PATCH] 2.5.5-pre1 IDE cleanup 9

[Gerd Knorr]

>  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

Re: [PATCH] 2.5.5-pre1 IDE cleanup 9

[Martin Dalecki]

Gerd Knorr wrote:
>> 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

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...)

Re: [PATCH] 2.5.5-pre1 IDE cleanup 9

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

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" <dalecki@evision-ventures.com>
To: "Linus Torvalds" <torvalds@transmeta.com>
Cc: "Kernel Mailing List" <linux-kernel@vger.kernel.org>
Sent: Tuesday, February 19, 2002 1:46 PM
Subject: [PATCH] 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.
>
>
>

Re: [PATCH] 2.5.5-pre1 IDE cleanup 9

[Martin Dalecki]

Gadi Oxman wrote:
> 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 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.

> The last example was actually used in ide-scsi.c. The intention in

ide-scsi is intendid to be gone in 2.5.x.

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

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

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.

Re: [PATCH] 2.5.5-pre1 IDE cleanup 9

[Vojtech Pavlik]

On Fri, Feb 22, 2002 at 02:45:32PM +0100, Martin Dalecki wrote:

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

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

-- 
Vojtech Pavlik
SuSE Labs

Re: [PATCH] 2.5.5-pre1 IDE cleanup 9

[Jeff Garzik]

Vojtech Pavlik wrote:
> On Fri, Feb 22, 2002 at 02:45:32PM +0100, Martin Dalecki wrote:
> > 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



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

Re: [PATCH] 2.5.5-pre1 IDE cleanup 9

[Martin Dalecki]

Jeff Garzik wrote:
> Vojtech Pavlik wrote:
> 
>>On Fri, Feb 22, 2002 at 02:45:32PM +0100, Martin Dalecki wrote:
>>
>>>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.

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 ;-).

Re: [PATCH] 2.5.5-pre1 IDE cleanup 9

[Martin Dalecki]

Vojtech Pavlik wrote:
> On Fri, Feb 22, 2002 at 02:45:32PM +0100, Martin Dalecki wrote:
> 
> 
>>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.

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.

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

Re: [PATCH] 2.5.5-pre1 IDE cleanup 9

[Vojtech Pavlik]

On Fri, Feb 22, 2002 at 03:16:22PM +0100, Martin Dalecki wrote:

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

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.

-- 
Vojtech Pavlik
SuSE Labs

Re: [PATCH] 2.5.5-pre1 IDE cleanup 9

[Jeff Garzik]

Vojtech Pavlik wrote:
> On Fri, Feb 22, 2002 at 03:16:22PM +0100, Martin Dalecki wrote:
> > > 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.

It depends on the quirk, really, whether you want the low-level chipset
driver to set a flag that tells the IDE core to do something, or whether
the low-level chipset driver handles the quirk (by a fixup in an IRQ
routine or somesuch).

Basically it's a case-by-case basis...

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

Re: [PATCH] 2.5.5-pre1 IDE cleanup 9

[Martin Dalecki]

Vojtech Pavlik wrote:

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

I just noticed that you are *right*. I'm going over the whole recognized
PCI device list anyway, so I will just add a flag field to the struct 
ide_pci_device_s. There are at least fortunately not more then 32
different quirk types ;-).
And then the whole she-bag can be really pushed down to the
particular chipset setup file indeed.

Re: [PATCH] 2.5.5-pre1 IDE cleanup 9

[Jeff Garzik]

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

Re: [PATCH] 2.5.5-pre1 IDE cleanup 9

[Jeff Garzik]

Martin Dalecki wrote:
> 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

For what the code is trying to accomplish, the code is correct.

I agree the above change is also correct... probably the author wanted
to reduce the size of the -huge- data table where PCI_ALI15X3 symbol is
used.


> And be replaces entierly by register_chipset(...) blah blah or
> therlike ;-) as well as module initialization lists.

When we have "modprobe piix4_ide" loading the IDE subsystem, you are
correct.

IDE is currently driven by an inward->outward setup of module
initialization, which is fundamentally the opposite of what we want,
which is chipset_drvr -> core initialization.

	Jeff



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

Re: [PATCH] 2.5.5-pre1 IDE cleanup 9

[Martin Dalecki]

Jeff Garzik wrote:

>>#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
>>
> 
> For what the code is trying to accomplish, the code is correct.

Of course it's semantically correct. But the usage of an explicitly 
taken function pointer refference is usually a shure sign for a C 
beginner at work. I know and you know that this &xxx == xxx semantics is 
a workarount for pure K&R C implementation quriks.

> I agree the above change is also correct... probably the author wanted
> to reduce the size of the -huge- data table where PCI_ALI15X3 symbol is
> used.

Yes but he just didn't recognize that the whole huge list is the true
cause of grief ;-).

>>And be replaces entierly by register_chipset(...) blah blah or
>>therlike ;-) as well as module initialization lists.
>>
> 
> When we have "modprobe piix4_ide" loading the IDE subsystem, you are
> correct.

That's the intention yes.

> IDE is currently driven by an inward->outward setup of module
> initialization, which is fundamentally the opposite of what we want,
> which is chipset_drvr -> core initialization.

Just one word: Amen.

Re: [PATCH] 2.5.5-pre1 IDE cleanup 9

[Keith Owens]

On Fri, 22 Feb 2002 15:16:22 +0100, 
Martin Dalecki <dalecki@evision-ventures.com> wrote:
>... 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

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.

Re: [PATCH] 2.5.5-pre1 IDE cleanup 9

[Martin Dalecki]

Keith Owens wrote:
> On Fri, 22 Feb 2002 15:16:22 +0100, 
> Martin Dalecki <dalecki@evision-ventures.com> wrote:
> 
>>... 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
>>
> 
> 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.

Re: [PATCH] 2.5.5-pre1 IDE cleanup 9

[Arjan van de Ven]

Vojtech Pavlik wrote:

> 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 ;)

Re: [PATCH] 2.5.5-pre1 IDE cleanup 9

[Vojtech Pavlik]

On Fri, Feb 22, 2002 at 02:16:39PM +0000, Arjan van de Ven wrote:

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

-- 
Vojtech Pavlik
SuSE Labs

Re: [PATCH] 2.5.5-pre1 IDE cleanup 9

[Gérard Roudier]

On Fri, 22 Feb 2002, Vojtech Pavlik wrote:

> On Fri, Feb 22, 2002 at 02:16:39PM +0000, Arjan van de Ven wrote:
>
> > > 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.

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.

Re: [PATCH] 2.5.5-pre1 IDE cleanup 9

[Jeff Garzik]

Gérard Roudier wrote:
> 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?

> 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



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

Re: [PATCH] 2.5.5-pre1 IDE cleanup 9

[Gérard Roudier]

On Fri, 22 Feb 2002, Jeff Garzik wrote:

> Gérard Roudier wrote:
> > 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?
>
> > 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.

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.

Re: [PATCH] 2.5.5-pre1 IDE cleanup 9

[Jeff Garzik]

Gérard Roudier wrote:
> 
> On Fri, 22 Feb 2002, Jeff Garzik wrote:
> 
> > Gérard Roudier wrote:
> > > 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?
> >
> > > 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.
> 
> 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



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

Re: [PATCH] 2.5.5-pre1 IDE cleanup 9

[Vojtech Pavlik]

On Thu, Feb 21, 2002 at 09:31:20PM +0100, G?rard Roudier wrote:

> > On Fri, Feb 22, 2002 at 02:16:39PM +0000, Arjan van de Ven wrote:
> >
> > > > 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.
> 
> 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.

-- 
Vojtech Pavlik
SuSE Labs

Re: [PATCH] 2.5.5-pre1 IDE cleanup 9

[Greg KH]

On Fri, Feb 22, 2002 at 10:34:44PM +0100, Vojtech Pavlik wrote:
> 
> 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

Re: [PATCH] 2.5.5-pre1 IDE cleanup 9

[Jeff Garzik]

Vojtech Pavlik wrote:
> 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].

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

Re: [PATCH] 2.5.5-pre1 IDE cleanup 9

[Vojtech Pavlik]

On Fri, Feb 22, 2002 at 04:56:24PM -0500, Jeff Garzik wrote:
> Vojtech Pavlik wrote:
> > 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.

Exactly.

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

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

-- 
Vojtech Pavlik
SuSE Labs

Re: [PATCH] 2.5.5-pre1 IDE cleanup 9

[Martin Dalecki]

Vojtech Pavlik wrote:

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

Re: [PATCH] 2.5.5-pre1 IDE cleanup 9

[Jeff Garzik]

Vojtech Pavlik wrote:
> 
> On Fri, Feb 22, 2002 at 02:16:39PM +0000, Arjan van de Ven wrote:
> 
> > > 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.

Only 1-2 SCSI drivers do PCI probing "the right way"...  IIRC aic7xxx is
one of them.

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

Re: [PATCH] 2.5.5-pre1 IDE cleanup 9

[Gérard Roudier]

On Fri, 22 Feb 2002, Jeff Garzik wrote:

> Vojtech Pavlik wrote:
> >
> > On Fri, Feb 22, 2002 at 02:16:39PM +0000, Arjan van de Ven wrote:
> >
> > > > 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.
>
> 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.

Re: [PATCH] 2.5.5-pre1 IDE cleanup 9

[Jeff Garzik]

Gérard Roudier wrote:
> On Fri, 22 Feb 2002, Jeff Garzik wrote:
> > 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


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

Re: [PATCH] 2.5.5-pre1 IDE cleanup 9

[Gérard Roudier]

On Fri, 22 Feb 2002, Jeff Garzik wrote:

> Gérard Roudier wrote:
> > On Fri, 22 Feb 2002, Jeff Garzik wrote:
> > > 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.

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.

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

Re: [PATCH] 2.5.5-pre1 IDE cleanup 9

[Greg KH]

On Thu, Feb 21, 2002 at 10:01:14PM +0100, Gérard Roudier wrote:
> 
> 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 :)

> 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

Re: [PATCH] 2.5.5-pre1 IDE cleanup 9

[Gérard Roudier]

On Fri, 22 Feb 2002, Greg KH wrote:

> On Thu, Feb 21, 2002 at 10:01:14PM +0100, Gérard Roudier wrote:
> >
> > 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 :)
>
> > 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.

Re: [PATCH] 2.5.5-pre1 IDE cleanup 9

[Greg KH]

On Thu, Feb 21, 2002 at 10:24:22PM +0100, Gérard Roudier wrote:
> 
> 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

Re: [PATCH] 2.5.5-pre1 IDE cleanup 9

[Erik Andersen]

On Fri Feb 22, 2002 at 12:41:57PM -0800, Greg KH wrote:
> 
> 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--

Re: [PATCH] 2.5.5-pre1 IDE cleanup 9

[Greg KH]

On Fri, Feb 22, 2002 at 02:30:14PM -0700, Erik Andersen wrote:
> On Fri Feb 22, 2002 at 12:41:57PM -0800, Greg KH wrote:
> > 
> > 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

Re: [PATCH] 2.5.5-pre1 IDE cleanup 9

[Erik Andersen]

On Fri Feb 22, 2002 at 01:42:25PM -0800, Greg KH wrote:
> 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--

Re: [PATCH] 2.5.5-pre1 IDE cleanup 9

[Erik Andersen]

On Thu Feb 21, 2002 at 10:24:22PM +0100, Gérard Roudier wrote:
> 
> 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--

Re: [PATCH] 2.5.5-pre1 IDE cleanup 9

[Gérard Roudier]

On Fri, 22 Feb 2002, Erik Andersen wrote:

> On Thu Feb 21, 2002 at 10:24:22PM +0100, Gérard Roudier wrote:
> >
> > 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.

Re: [PATCH] 2.5.5-pre1 IDE cleanup 9

[Erik Andersen]

On Fri Feb 22, 2002 at 12:17:26AM +0100, Gérard Roudier wrote:
> 
> 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--

Re: [PATCH] 2.5.5-pre1 IDE cleanup 9

[Rik van Riel]

On Thu, 21 Feb 2002, Gérard Roudier wrote:

> 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
-- 
"Linux holds advantages over the single-vendor commercial OS"
    -- Microsoft's "Competing with Linux" document

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

Re: [PATCH] 2.5.5-pre1 IDE cleanup 9

[Andre Hedrick]

On Fri, 22 Feb 2002, Greg KH wrote:

> On Thu, Feb 21, 2002 at 10:01:14PM +0100, Gérard Roudier wrote:
> > 
> > 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 :)

Does INT13/INT19 Bios call mean anything?

Last time I checked, ethernet devices are not invoked here but I could be
wrong given PXE.


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

Re: [PATCH] 2.5.5-pre1 IDE cleanup 9

[Greg KH]

On Fri, Feb 22, 2002 at 12:09:47PM -0800, Andre Hedrick wrote:
> 
> 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.

> 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

Re: [PATCH] 2.5.5-pre1 IDE cleanup 9

[Andre Hedrick]

On Fri, 22 Feb 2002, Greg KH wrote:

> On Fri, Feb 22, 2002 at 12:09:47PM -0800, Andre Hedrick wrote:
> > 
> > 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"

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

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

Re: [PATCH] 2.5.5-pre1 IDE cleanup 9

[Vojtech Pavlik]

On Fri, Feb 22, 2002 at 12:34:12PM -0800, Andre Hedrick wrote:

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

-- 
Vojtech Pavlik
SuSE Labs

Re: [PATCH] 2.5.5-pre1 IDE cleanup 9

[arjan]

In article <Pine.LNX.4.10.10202221204400.2519-100000@master.linux-ide.org> you wrote:

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

Eg

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

   

Re: [PATCH] 2.5.5-pre1 IDE cleanup 9

[Vojtech Pavlik]

On Fri, Feb 22, 2002 at 12:09:47PM -0800, Andre Hedrick wrote:
 
> > > 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?

The fact that even though you have one module for the whole family of
host controllers, the hotplug API will only call the remove function of
the one instance of the host controller that is being removed, not
affecting the others.

-- 
Vojtech Pavlik
SuSE Labs

[PATCH] 2.5.5 IDE cleanup 12

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

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.

Re: [PATCH] 2.5.5-pre1 IDE cleanup 9

[Jeff Garzik]

Andre Hedrick wrote:
> 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);

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

Re: [PATCH] 2.5.5-pre1 IDE cleanup 9

[Andre Hedrick]

On Fri, 22 Feb 2002, Jeff Garzik wrote:

> Gérard Roudier wrote:
> > On Fri, 22 Feb 2002, Jeff Garzik wrote:
> > > 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.

Also not that ATA/IDE drivers were not using 2.4 PCI API and likewise was
stable for a while.

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

> 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

Re: [PATCH] 2.5.5-pre1 IDE cleanup 9

[Jeff Garzik]

Andre Hedrick wrote:
> 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.


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


> 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


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

Re: [PATCH] 2.5.5-pre1 IDE cleanup 9

[Andre Hedrick]

On Fri, 22 Feb 2002, Jeff Garzik wrote:

> Andre Hedrick wrote:
> > 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. :-/

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

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

Re: [PATCH] 2.5.5-pre1 IDE cleanup 9

[Vojtech Pavlik]

On Fri, Feb 22, 2002 at 12:19:52PM -0800, Andre Hedrick wrote:
> On Fri, 22 Feb 2002, Jeff Garzik wrote:
> 
> > Andre Hedrick wrote:
> > > 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?

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.

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

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

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

> 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.)

-- 
Vojtech Pavlik
SuSE Labs

Re: [PATCH] 2.5.5-pre1 IDE cleanup 9

[Martin Dalecki]

Andre Hedrick wrote:

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

Re: [PATCH] 2.5.5-pre1 IDE cleanup 9

[Jeff Garzik]

Andre Hedrick wrote:
> 
> On Fri, 22 Feb 2002, Jeff Garzik wrote:
> 
> > Andre Hedrick wrote:
> > > 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. :-/
> 
> > > > 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


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

Re: [PATCH] 2.5.5-pre1 IDE cleanup 9

[Martin Dalecki]

Jeff Garzik wrote:
> Andre Hedrick wrote:
> 
>>On Fri, 22 Feb 2002, Jeff Garzik wrote:
>>
>>
>>>Andre Hedrick wrote:
>>>
>>>>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. :-/
>>
>>
>>>>>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.

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)

Re: [PATCH] 2.5.5-pre1 IDE cleanup 9

[Vojtech Pavlik]

On Fri, Feb 22, 2002 at 11:46:46AM -0800, Andre Hedrick wrote:

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

But that's a shame on the ATA/IDE drivers actually.

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

Exactly. That's why it is needed for hotplug PCI and CardBus.

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

Hmm?

-- 
Vojtech Pavlik
SuSE Labs

Re: [PATCH] 2.5.5-pre1 IDE cleanup 9

[Vojtech Pavlik]

On Thu, Feb 21, 2002 at 09:39:20PM +0100, G?rard Roudier wrote:

> On Fri, 22 Feb 2002, Jeff Garzik wrote:
> 
> > Vojtech Pavlik wrote:
> > >
> > > On Fri, Feb 22, 2002 at 02:16:39PM +0000, Arjan van de Ven wrote:
> > >
> > > > > 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.
> >
> > 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.

I think we're talking about PCI probing all the time ONLY.

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

-- 
Vojtech Pavlik
SuSE Labs

[PATCH] 2.5.5-pre1 IDE cleanup 10

[Martin Dalecki]

[-- Attachment #1: Type: text/plain, Size: 1231 bytes --]

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

[-- Attachment #2: ide-clean-10.diff --]
[-- Type: text/plain, Size: 10042 bytes --]

diff -ur linux-2.5.4/drivers/ide/ide-cd.c linux/drivers/ide/ide-cd.c
--- linux-2.5.4/drivers/ide/ide-cd.c	Tue Feb 19 03:11:03 2002
+++ linux/drivers/ide/ide-cd.c	Wed Feb 20 02:35:14 2002
@@ -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;
 }
diff -ur linux-2.5.4/drivers/ide/ide-disk.c linux/drivers/ide/ide-disk.c
--- linux-2.5.4/drivers/ide/ide-disk.c	Tue Feb 19 03:07:32 2002
+++ linux/drivers/ide/ide-disk.c	Wed Feb 20 02:32:25 2002
@@ -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;
 }
diff -ur linux-2.5.4/drivers/ide/ide-floppy.c linux/drivers/ide/ide-floppy.c
--- linux-2.5.4/drivers/ide/ide-floppy.c	Tue Feb 19 03:14:55 2002
+++ linux/drivers/ide/ide-floppy.c	Wed Feb 20 02:34:00 2002
@@ -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;
 }
diff -ur linux-2.5.4/drivers/ide/ide-proc.c linux/drivers/ide/ide-proc.c
--- linux-2.5.4/drivers/ide/ide-proc.c	Tue Feb 19 02:59:27 2002
+++ linux/drivers/ide/ide-proc.c	Wed Feb 20 02:34:43 2002
@@ -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);
diff -ur linux-2.5.4/drivers/ide/ide-tape.c linux/drivers/ide/ide-tape.c
--- linux-2.5.4/drivers/ide/ide-tape.c	Tue Feb 19 03:12:58 2002
+++ linux/drivers/ide/ide-tape.c	Wed Feb 20 02:33:24 2002
@@ -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");
diff -ur linux-2.5.4/drivers/ide/ide.c linux/drivers/ide/ide.c
--- linux-2.5.4/drivers/ide/ide.c	Tue Feb 19 02:57:06 2002
+++ linux/drivers/ide/ide.c	Wed Feb 20 02:38:30 2002
@@ -196,11 +196,6 @@
 int noautodma = 0;
 
 /*
- * This is the anchor of the single linked list of ide device type drivers.
- */
-struct ide_driver_s *ide_drivers;
-
-/*
  * This is declared extern in ide.h, for access by other IDE modules:
  */
 ide_hwif_t	ide_hwifs[MAX_HWIFS];	/* master data repository */
@@ -1842,7 +1837,11 @@
 	return res;
 }
 
-static void revalidate_drives (void)
+/*
+ * Look again for all drives in the system on all interfaces.  This is used
+ * after a new driver cathegory has been loaded as module.
+ */
+void revalidate_drives (void)
 {
 	ide_hwif_t *hwif;
 	ide_drive_t *drive;
@@ -1870,15 +1869,12 @@
 static void ide_driver_module (void)
 {
 	int index;
-	struct ide_driver_s *d;
 
 	for (index = 0; index < MAX_HWIFS; ++index)
 		if (ide_hwifs[index].present)
 			goto search;
 	ide_probe_module();
 search:
-	for (d = ide_drivers; d != NULL; d = d->next)
-		d->driver_init();
 
 	revalidate_drives();
 }
@@ -3610,30 +3606,6 @@
 	return 0;
 }
 
-int ide_register_module (struct ide_driver_s *d)
-{
-	struct ide_driver_s *p = ide_drivers;
-
-	while (p) {
-		if (p == d)
-			return 1;
-		p = p->next;
-	}
-	d->next = ide_drivers;
-	ide_drivers = d;
-	revalidate_drives();
-	return 0;
-}
-
-void ide_unregister_module (struct ide_driver_s *d)
-{
-	struct ide_driver_s **p;
-
-	for (p = &ide_drivers; (*p) && (*p) != d; p = &((*p)->next));
-	if (*p)
-		*p = (*p)->next;
-}
-
 struct block_device_operations ide_fops[] = {{
 	owner:			THIS_MODULE,
 	open:			ide_open,
@@ -3644,9 +3616,8 @@
 }};
 
 EXPORT_SYMBOL(ide_hwifs);
-EXPORT_SYMBOL(ide_register_module);
-EXPORT_SYMBOL(ide_unregister_module);
 EXPORT_SYMBOL(ide_spin_wait_hwgroup);
+EXPORT_SYMBOL(revalidate_drives);
 
 /*
  * Probe module
diff -ur linux-2.5.4/drivers/scsi/ide-scsi.c linux/drivers/scsi/ide-scsi.c
--- linux-2.5.4/drivers/scsi/ide-scsi.c	Tue Feb 19 03:16:52 2002
+++ linux/drivers/scsi/ide-scsi.c	Wed Feb 20 02:34:31 2002
@@ -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);
diff -ur linux-2.5.4/include/linux/ide.h linux/include/linux/ide.h
--- linux-2.5.4/include/linux/ide.h	Tue Feb 19 03:02:28 2002
+++ linux/include/linux/ide.h	Wed Feb 20 02:39:09 2002
@@ -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 */

Re: [PATCH] 2.5.5 IDE cleanup 11

[Martin Dalecki]

[-- Attachment #1: Type: text/plain, Size: 1415 bytes --]

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.

[-- Attachment #2: ide-clean-10.diff --]
[-- Type: text/plain, Size: 10042 bytes --]

diff -ur linux-2.5.4/drivers/ide/ide-cd.c linux/drivers/ide/ide-cd.c
--- linux-2.5.4/drivers/ide/ide-cd.c	Tue Feb 19 03:11:03 2002
+++ linux/drivers/ide/ide-cd.c	Wed Feb 20 02:35:14 2002
@@ -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;
 }
diff -ur linux-2.5.4/drivers/ide/ide-disk.c linux/drivers/ide/ide-disk.c
--- linux-2.5.4/drivers/ide/ide-disk.c	Tue Feb 19 03:07:32 2002
+++ linux/drivers/ide/ide-disk.c	Wed Feb 20 02:32:25 2002
@@ -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;
 }
diff -ur linux-2.5.4/drivers/ide/ide-floppy.c linux/drivers/ide/ide-floppy.c
--- linux-2.5.4/drivers/ide/ide-floppy.c	Tue Feb 19 03:14:55 2002
+++ linux/drivers/ide/ide-floppy.c	Wed Feb 20 02:34:00 2002
@@ -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;
 }
diff -ur linux-2.5.4/drivers/ide/ide-proc.c linux/drivers/ide/ide-proc.c
--- linux-2.5.4/drivers/ide/ide-proc.c	Tue Feb 19 02:59:27 2002
+++ linux/drivers/ide/ide-proc.c	Wed Feb 20 02:34:43 2002
@@ -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);
diff -ur linux-2.5.4/drivers/ide/ide-tape.c linux/drivers/ide/ide-tape.c
--- linux-2.5.4/drivers/ide/ide-tape.c	Tue Feb 19 03:12:58 2002
+++ linux/drivers/ide/ide-tape.c	Wed Feb 20 02:33:24 2002
@@ -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");
diff -ur linux-2.5.4/drivers/ide/ide.c linux/drivers/ide/ide.c
--- linux-2.5.4/drivers/ide/ide.c	Tue Feb 19 02:57:06 2002
+++ linux/drivers/ide/ide.c	Wed Feb 20 02:38:30 2002
@@ -196,11 +196,6 @@
 int noautodma = 0;
 
 /*
- * This is the anchor of the single linked list of ide device type drivers.
- */
-struct ide_driver_s *ide_drivers;
-
-/*
  * This is declared extern in ide.h, for access by other IDE modules:
  */
 ide_hwif_t	ide_hwifs[MAX_HWIFS];	/* master data repository */
@@ -1842,7 +1837,11 @@
 	return res;
 }
 
-static void revalidate_drives (void)
+/*
+ * Look again for all drives in the system on all interfaces.  This is used
+ * after a new driver cathegory has been loaded as module.
+ */
+void revalidate_drives (void)
 {
 	ide_hwif_t *hwif;
 	ide_drive_t *drive;
@@ -1870,15 +1869,12 @@
 static void ide_driver_module (void)
 {
 	int index;
-	struct ide_driver_s *d;
 
 	for (index = 0; index < MAX_HWIFS; ++index)
 		if (ide_hwifs[index].present)
 			goto search;
 	ide_probe_module();
 search:
-	for (d = ide_drivers; d != NULL; d = d->next)
-		d->driver_init();
 
 	revalidate_drives();
 }
@@ -3610,30 +3606,6 @@
 	return 0;
 }
 
-int ide_register_module (struct ide_driver_s *d)
-{
-	struct ide_driver_s *p = ide_drivers;
-
-	while (p) {
-		if (p == d)
-			return 1;
-		p = p->next;
-	}
-	d->next = ide_drivers;
-	ide_drivers = d;
-	revalidate_drives();
-	return 0;
-}
-
-void ide_unregister_module (struct ide_driver_s *d)
-{
-	struct ide_driver_s **p;
-
-	for (p = &ide_drivers; (*p) && (*p) != d; p = &((*p)->next));
-	if (*p)
-		*p = (*p)->next;
-}
-
 struct block_device_operations ide_fops[] = {{
 	owner:			THIS_MODULE,
 	open:			ide_open,
@@ -3644,9 +3616,8 @@
 }};
 
 EXPORT_SYMBOL(ide_hwifs);
-EXPORT_SYMBOL(ide_register_module);
-EXPORT_SYMBOL(ide_unregister_module);
 EXPORT_SYMBOL(ide_spin_wait_hwgroup);
+EXPORT_SYMBOL(revalidate_drives);
 
 /*
  * Probe module
diff -ur linux-2.5.4/drivers/scsi/ide-scsi.c linux/drivers/scsi/ide-scsi.c
--- linux-2.5.4/drivers/scsi/ide-scsi.c	Tue Feb 19 03:16:52 2002
+++ linux/drivers/scsi/ide-scsi.c	Wed Feb 20 02:34:31 2002
@@ -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);
diff -ur linux-2.5.4/include/linux/ide.h linux/include/linux/ide.h
--- linux-2.5.4/include/linux/ide.h	Tue Feb 19 03:02:28 2002
+++ linux/include/linux/ide.h	Wed Feb 20 02:39:09 2002
@@ -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 */

[-- Attachment #3: ide-clean-11.diff --]
[-- Type: text/plain, Size: 36109 bytes --]

diff -ur linux-2.5.5/drivers/ide/aec62xx.c linux/drivers/ide/aec62xx.c
--- linux-2.5.5/drivers/ide/aec62xx.c	Wed Feb 20 03:11:00 2002
+++ linux/drivers/ide/aec62xx.c	Thu Feb 21 03:05:15 2002
@@ -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;
 }
diff -ur linux-2.5.5/drivers/ide/ali14xx.c linux/drivers/ide/ali14xx.c
--- linux-2.5.5/drivers/ide/ali14xx.c	Wed Feb 20 03:11:02 2002
+++ linux/drivers/ide/ali14xx.c	Thu Feb 21 03:08:53 2002
@@ -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;
diff -ur linux-2.5.5/drivers/ide/alim15x3.c linux/drivers/ide/alim15x3.c
--- linux-2.5.5/drivers/ide/alim15x3.c	Wed Feb 20 03:10:55 2002
+++ linux/drivers/ide/alim15x3.c	Thu Feb 21 03:01:29 2002
@@ -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)
diff -ur linux-2.5.5/drivers/ide/cmd640.c linux/drivers/ide/cmd640.c
--- linux-2.5.5/drivers/ide/cmd640.c	Wed Feb 20 03:11:01 2002
+++ linux/drivers/ide/cmd640.c	Thu Feb 21 03:06:52 2002
@@ -23,7 +23,7 @@
  *
  *  A.Hartgers@stud.tue.nl, JZDQC@CUNYVM.CUNY.edu, abramov@cecmow.enet.dec.com,
  *  bardj@utopia.ppp.sn.no, bart@gaga.tue.nl, bbol001@cs.auckland.ac.nz,
- *  chrisc@dbass.demon.co.uk, dalecki@namu26.Num.Math.Uni-Goettingen.de,
+ *  chrisc@dbass.demon.co.uk, dalecki@evision-ventures.com,
  *  derekn@vw.ece.cmu.edu, florian@btp2x3.phy.uni-bayreuth.de,
  *  flynn@dei.unipd.it, gadio@netvision.net.il, godzilla@futuris.net,
  *  j@pobox.com, jkemp1@mises.uni-paderborn.de, jtoppe@hiwaay.net,
@@ -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;
diff -ur linux-2.5.5/drivers/ide/cmd64x.c linux/drivers/ide/cmd64x.c
--- linux-2.5.5/drivers/ide/cmd64x.c	Wed Feb 20 03:11:00 2002
+++ linux/drivers/ide/cmd64x.c	Thu Feb 21 03:05:52 2002
@@ -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;
diff -ur linux-2.5.5/drivers/ide/cy82c693.c linux/drivers/ide/cy82c693.c
--- linux-2.5.5/drivers/ide/cy82c693.c	Wed Feb 20 03:10:58 2002
+++ linux/drivers/ide/cy82c693.c	Thu Feb 21 03:03:52 2002
@@ -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 */
 
diff -ur linux-2.5.5/drivers/ide/ht6560b.c linux/drivers/ide/ht6560b.c
--- linux-2.5.5/drivers/ide/ht6560b.c	Wed Feb 20 03:10:57 2002
+++ linux/drivers/ide/ht6560b.c	Thu Feb 21 03:03:11 2002
@@ -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
 		 */
diff -ur linux-2.5.5/drivers/ide/ide-disk.c linux/drivers/ide/ide-disk.c
--- linux-2.5.5/drivers/ide/ide-disk.c	Thu Feb 21 03:58:10 2002
+++ linux/drivers/ide/ide-disk.c	Thu Feb 21 03:32:18 2002
@@ -378,11 +378,6 @@
 	return drive->removable;	/* if removable, always assume it was changed */
 }
 
-static void idedisk_revalidate (ide_drive_t *drive)
-{
-	ide_revalidate_drive(drive);
-}
-
 /*
  * Queries for true maximum capacity of the drive.
  * Returns maximum LBA address (> 0) of the drive, 0 if failed.
@@ -915,13 +910,22 @@
 	ide_add_setting(drive,	"max_failures",		SETTING_RW,					-1,			-1,			TYPE_INT,	0,	65535,				1,	1,	&drive->max_failures,		NULL);
 }
 
-static void idedisk_setup (ide_drive_t *drive)
+/* 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 void idedisk_setup(ide_drive_t *drive)
 {
 	int i;
-	
+
 	struct hd_driveid *id = drive->id;
 	unsigned long capacity;
-	
+	int drvid = -1;
+
 	idedisk_add_settings(drive);
 
 	if (id == NULL)
@@ -933,7 +937,7 @@
 	 */
 	if (drive->removable && !drive_is_flashcard(drive)) {
 		/*
-		 * Removable disks (eg. SYQUEST); ignore 'WD' drives 
+		 * Removable disks (eg. SYQUEST); ignore 'WD' drives.
 		 */
 		if (id->model[0] != 'W' || id->model[1] != 'D') {
 			drive->doorlocking = 1;
@@ -942,13 +946,26 @@
 	for (i = 0; i < MAX_DRIVES; ++i) {
 		ide_hwif_t *hwif = HWIF(drive);
 
-		if (drive != &hwif->drives[i]) continue;
+		if (drive != &hwif->drives[i])
+		    continue;
+		drvid = i;
 		hwif->gd->de_arr[i] = drive->de;
 		if (drive->removable)
 			hwif->gd->flags[i] |= GENHD_FL_REMOVABLE;
 		break;
 	}
 
+	/* Register us within the device tree.
+	 */
+
+	if (drvid != -1) {
+	    sprintf(drive->device.bus_id, "%d", drvid);
+	    sprintf(drive->device.name, "ide-disk");
+	    drive->device.driver = &idedisk_devdrv;
+	    drive->device.parent = &HWIF(drive)->device;
+	    device_register(&drive->device);
+	}
+
 	/* Extract geometry if we did not already have one for the drive */
 	if (!drive->cyl || !drive->head || !drive->sect) {
 		drive->cyl     = drive->bios_cyl  = id->cyls;
@@ -1023,6 +1040,12 @@
 
 static int idedisk_cleanup (ide_drive_t *drive)
 {
+
+	/* FIXME: we will have to think twice whatever this is the proper place
+	 * to do it.
+	 */
+
+	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",
@@ -1050,7 +1073,7 @@
 	open:			idedisk_open,
 	release:		idedisk_release,
 	media_change:		idedisk_media_change,
-	revalidate:		idedisk_revalidate,
+	revalidate:		ide_revalidate_drive,
 	pre_reset:		idedisk_pre_reset,
 	capacity:		idedisk_capacity,
 	special:		idedisk_special,
diff -ur linux-2.5.5/drivers/ide/ide-pnp.c linux/drivers/ide/ide-pnp.c
--- linux-2.5.5/drivers/ide/ide-pnp.c	Wed Feb 20 03:10:59 2002
+++ linux/drivers/ide/ide-pnp.c	Thu Feb 21 01:39:37 2002
@@ -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;
 	}
 
diff -ur linux-2.5.5/drivers/ide/ide-probe.c linux/drivers/ide/ide-probe.c
--- linux-2.5.5/drivers/ide/ide-probe.c	Wed Feb 20 03:10:53 2002
+++ linux/drivers/ide/ide-probe.c	Thu Feb 21 01:31:32 2002
@@ -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);
diff -ur linux-2.5.5/drivers/ide/ide.c linux/drivers/ide/ide.c
--- linux-2.5.5/drivers/ide/ide.c	Thu Feb 21 03:58:10 2002
+++ linux/drivers/ide/ide.c	Thu Feb 21 03:49:46 2002
@@ -128,8 +128,6 @@
 
 #undef REALLY_SLOW_IO		/* most systems can safely undef this */
 
-#define _IDE_C			/* Tell ide.h it's really us */
-
 #include <linux/config.h>
 #include <linux/module.h>
 #include <linux/types.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,17 +162,102 @@
 
 #include "ide_modes.h"
 
-#ifdef CONFIG_KMOD
-#include <linux/kmod.h>
-#endif /* CONFIG_KMOD */
+/* Constant tables for PIO mode programming:
+ */
+
+const ide_pio_timings_t ide_pio_timings[6] = {
+	{ 70,	165,	600 },	/* PIO Mode 0 */
+	{ 50,	125,	383 },	/* PIO Mode 1 */
+	{ 30,	100,	240 },	/* PIO Mode 2 */
+	{ 30,	80,	180 },	/* PIO Mode 3 with IORDY */
+	{ 25,	70,	120 },	/* PIO Mode 4 with IORDY */
+	{ 20,	50,	100 }	/* PIO Mode 5 with IORDY (nonstandard) */
+};
+
+/*
+ * Black list. Some drives incorrectly report their maximal PIO mode,
+ * at least in respect to CMD640. Here we keep info on some known drives.
+ */
+static struct ide_pio_info {
+	const char	*name;
+	int		pio;
+} ide_pio_blacklist [] = {
+/*	{ "Conner Peripherals 1275MB - CFS1275A", 4 }, */
+	{ "Conner Peripherals 540MB - CFS540A", 3 },
+
+	{ "WDC AC2700",  3 },
+	{ "WDC AC2540",  3 },
+	{ "WDC AC2420",  3 },
+	{ "WDC AC2340",  3 },
+	{ "WDC AC2250",  0 },
+	{ "WDC AC2200",  0 },
+	{ "WDC AC21200", 4 },
+	{ "WDC AC2120",  0 },
+	{ "WDC AC2850",  3 },
+	{ "WDC AC1270",  3 },
+	{ "WDC AC1170",  1 },
+	{ "WDC AC1210",  1 },
+	{ "WDC AC280",   0 },
+/*	{ "WDC AC21000", 4 }, */
+	{ "WDC AC31000", 3 },
+	{ "WDC AC31200", 3 },
+/*	{ "WDC AC31600", 4 }, */
+
+	{ "Maxtor 7131 AT", 1 },
+	{ "Maxtor 7171 AT", 1 },
+	{ "Maxtor 7213 AT", 1 },
+	{ "Maxtor 7245 AT", 1 },
+	{ "Maxtor 7345 AT", 1 },
+	{ "Maxtor 7546 AT", 3 },
+	{ "Maxtor 7540 AV", 3 },
+
+	{ "SAMSUNG SHD-3121A", 1 },
+	{ "SAMSUNG SHD-3122A", 1 },
+	{ "SAMSUNG SHD-3172A", 1 },
+
+/*	{ "ST51080A", 4 },
+ *	{ "ST51270A", 4 },
+ *	{ "ST31220A", 4 },
+ *	{ "ST31640A", 4 },
+ *	{ "ST32140A", 4 },
+ *	{ "ST3780A",  4 },
+ */
+	{ "ST5660A",  3 },
+	{ "ST3660A",  3 },
+	{ "ST3630A",  3 },
+	{ "ST3655A",  3 },
+	{ "ST3391A",  3 },
+	{ "ST3390A",  1 },
+	{ "ST3600A",  1 },
+	{ "ST3290A",  0 },
+	{ "ST3144A",  0 },
+	{ "ST3491A",  1 },	/* reports 3, should be 1 or 2 (depending on */	
+				/* drive) according to Seagates FIND-ATA program */
+
+	{ "QUANTUM ELS127A", 0 },
+	{ "QUANTUM ELS170A", 0 },
+	{ "QUANTUM LPS240A", 0 },
+	{ "QUANTUM LPS210A", 3 },
+	{ "QUANTUM LPS270A", 3 },
+	{ "QUANTUM LPS365A", 3 },
+	{ "QUANTUM LPS540A", 3 },
+	{ "QUANTUM LIGHTNING 540A", 3 },
+	{ "QUANTUM LIGHTNING 730A", 3 },
+
+        { "QUANTUM FIREBALL_540", 3 }, /* Older Quantum Fireballs don't work */
+        { "QUANTUM FIREBALL_640", 3 }, 
+        { "QUANTUM FIREBALL_1080", 3 },
+        { "QUANTUM FIREBALL_1280", 3 },
+	{ NULL,	0 }
+};
 
 /* default maximum number of failures */
-#define IDE_DEFAULT_MAX_FAILURES 	1
+#define IDE_DEFAULT_MAX_FAILURES	1
 
 static const byte ide_hwif_to_major[] = { IDE0_MAJOR, IDE1_MAJOR, IDE2_MAJOR, IDE3_MAJOR, IDE4_MAJOR, IDE5_MAJOR, IDE6_MAJOR, IDE7_MAJOR, IDE8_MAJOR, IDE9_MAJOR };
 
 static int	idebus_parameter; /* holds the "idebus=" parameter */
-static int	system_bus_speed; /* holds what we think is VESA/PCI bus speed */
+int system_bus_speed; /* holds what we think is VESA/PCI bus speed */
 static int	initializing;     /* set while initializing built-in drivers */
 
 /*
@@ -200,6 +285,106 @@
  */
 ide_hwif_t	ide_hwifs[MAX_HWIFS];	/* master data repository */
 
+
+/*
+ * This routine searches the ide_pio_blacklist for an entry
+ * matching the start/whole of the supplied model name.
+ *
+ * Returns -1 if no match found.
+ * Otherwise returns the recommended PIO mode from ide_pio_blacklist[].
+ */
+int ide_scan_pio_blacklist (char *model)
+{
+	struct ide_pio_info *p;
+
+	for (p = ide_pio_blacklist; p->name != NULL; p++) {
+		if (strncmp(p->name, model, strlen(p->name)) == 0)
+			return p->pio;
+	}
+	return -1;
+}
+
+/*
+ * This routine returns the recommended PIO settings for a given drive,
+ * based on the drive->id information and the ide_pio_blacklist[].
+ * This is used by most chipset support modules when "auto-tuning".
+ */
+
+/*
+ * Drive PIO mode auto selection
+ */
+byte ide_get_best_pio_mode (ide_drive_t *drive, byte mode_wanted, byte max_mode, ide_pio_data_t *d)
+{
+	int pio_mode;
+	int cycle_time = 0;
+	int use_iordy = 0;
+	struct hd_driveid* id = drive->id;
+	int overridden  = 0;
+	int blacklisted = 0;
+
+	if (mode_wanted != 255) {
+		pio_mode = mode_wanted;
+	} else if (!drive->id) {
+		pio_mode = 0;
+	} else if ((pio_mode = ide_scan_pio_blacklist(id->model)) != -1) {
+		overridden = 1;
+		blacklisted = 1;
+		use_iordy = (pio_mode > 2);
+	} else {
+		pio_mode = id->tPIO;
+		if (pio_mode > 2) {	/* 2 is maximum allowed tPIO value */
+			pio_mode = 2;
+			overridden = 1;
+		}
+		if (id->field_valid & 2) {	  /* drive implements ATA2? */
+			if (id->capability & 8) { /* drive supports use_iordy? */
+				use_iordy = 1;
+				cycle_time = id->eide_pio_iordy;
+				if (id->eide_pio_modes & 7) {
+					overridden = 0;
+					if (id->eide_pio_modes & 4)
+						pio_mode = 5;
+					else if (id->eide_pio_modes & 2)
+						pio_mode = 4;
+					else
+						pio_mode = 3;
+				}
+			} else {
+				cycle_time = id->eide_pio;
+			}
+		}
+
+#if 0
+		if (drive->id->major_rev_num & 0x0004) printk("ATA-2 ");
+#endif
+
+		/*
+		 * Conservative "downgrade" for all pre-ATA2 drives
+		 */
+		if (pio_mode && pio_mode < 4) {
+			pio_mode--;
+			overridden = 1;
+#if 0
+			use_iordy = (pio_mode > 2);
+#endif
+			if (cycle_time && cycle_time < ide_pio_timings[pio_mode].cycle_time)
+				cycle_time = 0; /* use standard timing */
+		}
+	}
+	if (pio_mode > max_mode) {
+		pio_mode = max_mode;
+		cycle_time = 0;
+	}
+	if (d) {
+		d->pio_mode = pio_mode;
+		d->cycle_time = cycle_time ? cycle_time : ide_pio_timings[pio_mode].cycle_time;
+		d->use_iordy = use_iordy;
+		d->overridden = overridden;
+		d->blacklisted = blacklisted;
+	}
+	return pio_mode;
+}
+
 #if (DISK_RECOVERY_TIME > 0)
 /*
  * For really screwy hardware (hey, at least it *can* be used with Linux)
@@ -308,7 +493,6 @@
 	ide_init_default_hwifs();
 
 	idebus_parameter = 0;
-	system_bus_speed = 0;
 }
 
 /*
@@ -342,30 +526,6 @@
 	return 0;	/* no, it is not a flash memory card */
 }
 
-/*
- * ide_system_bus_speed() returns what we think is the system VESA/PCI
- * bus speed (in MHz).  This is used for calculating interface PIO timings.
- * The default is 40 for known PCI systems, 50 otherwise.
- * The "idebus=xx" parameter can be used to override this value.
- * The actual value to be used is computed/displayed the first time through.
- */
-int ide_system_bus_speed (void)
-{
-	if (!system_bus_speed) {
-		if (idebus_parameter)
-			system_bus_speed = idebus_parameter;	/* user supplied value */
-#ifdef CONFIG_PCI
-		else if (pci_present())
-			system_bus_speed = 33;	/* safe default value for PCI */
-#endif /* CONFIG_PCI */
-		else
-			system_bus_speed = 50;	/* safe default value for VESA and PCI */
-		printk("ide: Assuming %dMHz system bus speed for PIO modes%s\n", system_bus_speed,
-			idebus_parameter ? "" : "; override with idebus=xx");
-	}
-	return system_bus_speed;
-}
-
 int __ide_end_request(ide_drive_t *drive, int uptodate, int nr_secs)
 {
 	struct request *rq;
@@ -2005,6 +2165,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)
@@ -2489,11 +2650,6 @@
 #endif /* CONFIG_BLK_DEV_IDECS */
 }
 
-int system_bus_clock (void)
-{
-	return((int) ((!system_bus_speed) ? ide_system_bus_speed() : system_bus_speed ));
-}
-
 int ide_reinit_drive (ide_drive_t *drive)
 {
 	switch (drive->media) {
@@ -3676,9 +3832,6 @@
 EXPORT_SYMBOL(ide_setup_ports);
 EXPORT_SYMBOL(get_info_ptr);
 EXPORT_SYMBOL(current_capacity);
-
-EXPORT_SYMBOL(system_bus_clock);
-
 EXPORT_SYMBOL(ide_reinit_drive);
 
 static int ide_notify_reboot (struct notifier_block *this, unsigned long event, void *x)
@@ -3730,17 +3883,32 @@
 /*
  * This is gets invoked once during initialization, to set *everything* up
  */
-int __init ide_init (void)
+int __init ide_init(void)
 {
-	static char banner_printed;
 	int i;
 
-	if (!banner_printed) {
-		printk(KERN_INFO "Uniform Multi-Platform E-IDE driver " REVISION "\n");
-		ide_devfs_handle = devfs_mk_dir (NULL, "ide", NULL);
-		system_bus_speed = ide_system_bus_speed();
-		banner_printed = 1;
-	}
+	printk(KERN_INFO "Uniform Multi-Platform E-IDE driver " REVISION "\n");
+	ide_devfs_handle = devfs_mk_dir (NULL, "ide", NULL);
+
+	/* Initialize system bus speed.
+	 *
+	 * This can be changed by a particular chipse initialization module.
+	 * Otherwise we assume 33MHz as a safe value for PCI bus based systems.
+	 * 50MHz will be assumed for abolitions like VESA, since higher values
+	 * result in more conservative timing setups.
+	 *
+	 * The kernel parameter idebus=XX overrides the default settings.
+	 */
+
+	system_bus_speed = 50;
+	if (idebus_parameter)
+	    system_bus_speed = idebus_parameter;
+#ifdef CONFIG_PCI
+	else if (pci_present())
+	    system_bus_speed = 33;
+#endif
+
+	printk("ide: system bus speed %dMHz\n", system_bus_speed);
 
 	init_ide_data ();
 
diff -ur linux-2.5.5/drivers/ide/ide_modes.h linux/drivers/ide/ide_modes.h
--- linux-2.5.5/drivers/ide/ide_modes.h	Wed Feb 20 03:10:57 2002
+++ linux/drivers/ide/ide_modes.h	Thu Feb 21 02:33:24 2002
@@ -11,9 +11,6 @@
 
 /*
  * Shared data/functions for determining best PIO mode for an IDE drive.
- * Most of this stuff originally lived in cmd640.c, and changes to the
- * ide_pio_blacklist[] table should be made with EXTREME CAUTION to avoid
- * breaking the fragile cmd640.c support.
  */
 
 #ifdef CONFIG_BLK_DEV_IDE_MODES
@@ -37,200 +34,9 @@
 	byte blacklisted;
 	unsigned int cycle_time;
 } ide_pio_data_t;
-	
-#ifndef _IDE_C
 
-int ide_scan_pio_blacklist (char *model);
-byte ide_get_best_pio_mode (ide_drive_t *drive, byte mode_wanted, byte max_mode, ide_pio_data_t *d);
+extern int ide_scan_pio_blacklist (char *model);
+extern byte ide_get_best_pio_mode (ide_drive_t *drive, byte mode_wanted, byte max_mode, ide_pio_data_t *d);
 extern const ide_pio_timings_t ide_pio_timings[6];
-
-#else /* _IDE_C */
-
-const ide_pio_timings_t ide_pio_timings[6] = {
-	{ 70,	165,	600 },	/* PIO Mode 0 */
-	{ 50,	125,	383 },	/* PIO Mode 1 */
-	{ 30,	100,	240 },	/* PIO Mode 2 */
-	{ 30,	80,	180 },	/* PIO Mode 3 with IORDY */
-	{ 25,	70,	120 },	/* PIO Mode 4 with IORDY */
-	{ 20,	50,	100 }	/* PIO Mode 5 with IORDY (nonstandard) */
-};
-
-/*
- * Black list. Some drives incorrectly report their maximal PIO mode,
- * at least in respect to CMD640. Here we keep info on some known drives.
- */
-static struct ide_pio_info {
-	const char	*name;
-	int		pio;
-} ide_pio_blacklist [] = {
-/*	{ "Conner Peripherals 1275MB - CFS1275A", 4 }, */
-	{ "Conner Peripherals 540MB - CFS540A", 3 },
-
-	{ "WDC AC2700",  3 },
-	{ "WDC AC2540",  3 },
-	{ "WDC AC2420",  3 },
-	{ "WDC AC2340",  3 },
-	{ "WDC AC2250",  0 },
-	{ "WDC AC2200",  0 },
-	{ "WDC AC21200", 4 },
-	{ "WDC AC2120",  0 },
-	{ "WDC AC2850",  3 },
-	{ "WDC AC1270",  3 },
-	{ "WDC AC1170",  1 },
-	{ "WDC AC1210",  1 },
-	{ "WDC AC280",   0 },
-/*	{ "WDC AC21000", 4 }, */
-	{ "WDC AC31000", 3 },
-	{ "WDC AC31200", 3 },
-/*	{ "WDC AC31600", 4 }, */
-
-	{ "Maxtor 7131 AT", 1 },
-	{ "Maxtor 7171 AT", 1 },
-	{ "Maxtor 7213 AT", 1 },
-	{ "Maxtor 7245 AT", 1 },
-	{ "Maxtor 7345 AT", 1 },
-	{ "Maxtor 7546 AT", 3 },
-	{ "Maxtor 7540 AV", 3 },
-
-	{ "SAMSUNG SHD-3121A", 1 },
-	{ "SAMSUNG SHD-3122A", 1 },
-	{ "SAMSUNG SHD-3172A", 1 },
-
-/*	{ "ST51080A", 4 },
- *	{ "ST51270A", 4 },
- *	{ "ST31220A", 4 },
- *	{ "ST31640A", 4 },
- *	{ "ST32140A", 4 },
- *	{ "ST3780A",  4 },
- */
-	{ "ST5660A",  3 },
-	{ "ST3660A",  3 },
-	{ "ST3630A",  3 },
-	{ "ST3655A",  3 },
-	{ "ST3391A",  3 },
-	{ "ST3390A",  1 },
-	{ "ST3600A",  1 },
-	{ "ST3290A",  0 },
-	{ "ST3144A",  0 },
-	{ "ST3491A",  1 },	/* reports 3, should be 1 or 2 (depending on */	
-				/* drive) according to Seagates FIND-ATA program */
-
-	{ "QUANTUM ELS127A", 0 },
-	{ "QUANTUM ELS170A", 0 },
-	{ "QUANTUM LPS240A", 0 },
-	{ "QUANTUM LPS210A", 3 },
-	{ "QUANTUM LPS270A", 3 },
-	{ "QUANTUM LPS365A", 3 },
-	{ "QUANTUM LPS540A", 3 },
-	{ "QUANTUM LIGHTNING 540A", 3 },
-	{ "QUANTUM LIGHTNING 730A", 3 },
-
-        { "QUANTUM FIREBALL_540", 3 }, /* Older Quantum Fireballs don't work */
-        { "QUANTUM FIREBALL_640", 3 }, 
-        { "QUANTUM FIREBALL_1080", 3 },
-        { "QUANTUM FIREBALL_1280", 3 },
-	{ NULL,	0 }
-};
-
-/*
- * This routine searches the ide_pio_blacklist for an entry
- * matching the start/whole of the supplied model name.
- *
- * Returns -1 if no match found.
- * Otherwise returns the recommended PIO mode from ide_pio_blacklist[].
- */
-int ide_scan_pio_blacklist (char *model)
-{
-	struct ide_pio_info *p;
-
-	for (p = ide_pio_blacklist; p->name != NULL; p++) {
-		if (strncmp(p->name, model, strlen(p->name)) == 0)
-			return p->pio;
-	}
-	return -1;
-}
-
-/*
- * This routine returns the recommended PIO settings for a given drive,
- * based on the drive->id information and the ide_pio_blacklist[].
- * This is used by most chipset support modules when "auto-tuning".
- */
-
-/*
- * Drive PIO mode auto selection
- */
-byte ide_get_best_pio_mode (ide_drive_t *drive, byte mode_wanted, byte max_mode, ide_pio_data_t *d)
-{
-	int pio_mode;
-	int cycle_time = 0;
-	int use_iordy = 0;
-	struct hd_driveid* id = drive->id;
-	int overridden  = 0;
-	int blacklisted = 0;
-
-	if (mode_wanted != 255) {
-		pio_mode = mode_wanted;
-	} else if (!drive->id) {
-		pio_mode = 0;
-	} else if ((pio_mode = ide_scan_pio_blacklist(id->model)) != -1) {
-		overridden = 1;
-		blacklisted = 1;
-		use_iordy = (pio_mode > 2);
-	} else {
-		pio_mode = id->tPIO;
-		if (pio_mode > 2) {	/* 2 is maximum allowed tPIO value */
-			pio_mode = 2;
-			overridden = 1;
-		}
-		if (id->field_valid & 2) {	  /* drive implements ATA2? */
-			if (id->capability & 8) { /* drive supports use_iordy? */
-				use_iordy = 1;
-				cycle_time = id->eide_pio_iordy;
-				if (id->eide_pio_modes & 7) {
-					overridden = 0;
-					if (id->eide_pio_modes & 4)
-						pio_mode = 5;
-					else if (id->eide_pio_modes & 2)
-						pio_mode = 4;
-					else
-						pio_mode = 3;
-				}
-			} else {
-				cycle_time = id->eide_pio;
-			}
-		}
-
-#if 0
-		if (drive->id->major_rev_num & 0x0004) printk("ATA-2 ");
 #endif
-
-		/*
-		 * Conservative "downgrade" for all pre-ATA2 drives
-		 */
-		if (pio_mode && pio_mode < 4) {
-			pio_mode--;
-			overridden = 1;
-#if 0
-			use_iordy = (pio_mode > 2);
 #endif
-			if (cycle_time && cycle_time < ide_pio_timings[pio_mode].cycle_time)
-				cycle_time = 0; /* use standard timing */
-		}
-	}
-	if (pio_mode > max_mode) {
-		pio_mode = max_mode;
-		cycle_time = 0;
-	}
-	if (d) {
-		d->pio_mode = pio_mode;
-		d->cycle_time = cycle_time ? cycle_time : ide_pio_timings[pio_mode].cycle_time;
-		d->use_iordy = use_iordy;
-		d->overridden = overridden;
-		d->blacklisted = blacklisted;
-	}
-	return pio_mode;
-}
-
-#endif /* _IDE_C */
-#endif /* CONFIG_BLK_DEV_IDE_MODES */
-#endif /* _IDE_MODES_H */
diff -ur linux-2.5.5/drivers/ide/opti621.c linux/drivers/ide/opti621.c
--- linux-2.5.5/drivers/ide/opti621.c	Wed Feb 20 03:10:56 2002
+++ linux/drivers/ide/opti621.c	Thu Feb 21 03:02:35 2002
@@ -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;
diff -ur linux-2.5.5/drivers/ide/qd65xx.c linux/drivers/ide/qd65xx.c
--- linux-2.5.5/drivers/ide/qd65xx.c	Wed Feb 20 03:10:58 2002
+++ linux/drivers/ide/qd65xx.c	Thu Feb 21 02:59:32 2002
@@ -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);
 }
diff -ur linux-2.5.5/drivers/ide/via82cxxx.c linux/drivers/ide/via82cxxx.c
--- linux-2.5.5/drivers/ide/via82cxxx.c	Wed Feb 20 03:10:59 2002
+++ linux/drivers/ide/via82cxxx.c	Thu Feb 21 03:04:19 2002
@@ -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;
diff -ur linux-2.5.5/include/linux/blk.h linux/include/linux/blk.h
--- linux-2.5.5/include/linux/blk.h	Wed Feb 20 03:10:59 2002
+++ linux/include/linux/blk.h	Thu Feb 21 03:49:40 2002
@@ -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);
 
diff -ur linux-2.5.5/include/linux/ide.h linux/include/linux/ide.h
--- linux-2.5.5/include/linux/ide.h	Thu Feb 21 03:58:10 2002
+++ linux/include/linux/ide.h	Thu Feb 21 03:49:57 2002
@@ -13,6 +13,7 @@
 #include <linux/hdsmart.h>
 #include <linux/blkdev.h>
 #include <linux/proc_fs.h>
+#include <linux/device.h>
 #include <linux/devfs_fs_kernel.h>
 #include <asm/hdreg.h>
 
@@ -426,7 +427,7 @@
 	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 */
-	struct hwif_s   *hwif;		/* actually (ide_hwif_t *) */
+	struct hwif_s   *hwif;		/* parent pointer to the interface we are attached to  */
 	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 */
@@ -450,6 +451,7 @@
 	byte		acoustic;	/* acoustic management */
 	unsigned int	failures;	/* current failure count */
 	unsigned int	max_failures;	/* maximum allowed failure count */
+	struct device	device;		/* global device tree handle */
 } ide_drive_t;
 
 /*
@@ -582,6 +584,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;		/* global device tree handle */
 } ide_hwif_t;
 
 /*
@@ -735,9 +738,7 @@
  * structure directly (the allocation/layout may change!).
  *
  */
-#ifndef _IDE_C
 extern struct hwif_s ide_hwifs[];		/* master data repository */
-#endif
 extern int noautodma;
 
 /*
@@ -812,7 +813,7 @@
 /*
  * Revalidate (read partition tables)
  */
-void ide_revalidate_drive (ide_drive_t *drive);
+extern void ide_revalidate_drive (ide_drive_t *drive);
 
 /*
  * Start a reset operation for an IDE interface.
@@ -953,7 +954,6 @@
 /*
  * Special Flagged Register Validation Caller
  */
-// ide_startstop_t flagged_taskfile (ide_drive_t *drive, ide_task_t *task);
 
 ide_startstop_t set_multmode_intr (ide_drive_t *drive);
 ide_startstop_t set_geometry_intr (ide_drive_t *drive);
@@ -984,7 +984,6 @@
 #endif /* CONFIG_PKT_TASK_IOCTL */
 
 void ide_delay_50ms (void);
-int system_bus_clock(void);
 
 byte ide_auto_reduce_xfer (ide_drive_t *drive);
 int ide_driveid_update (ide_drive_t *drive);
@@ -993,13 +992,7 @@
 byte eighty_ninty_three (ide_drive_t *drive);
 int set_transfer (ide_drive_t *drive, ide_task_t *args);
 
-/*
- * ide_system_bus_speed() returns what we think is the system VESA/PCI
- * bus speed (in MHz).  This is used for calculating interface PIO timings.
- * The default is 40 for known PCI systems, 50 otherwise.
- * The "idebus=xx" parameter can be used to override this value.
- */
-int ide_system_bus_speed (void);
+extern int system_bus_speed;
 
 /*
  * idedisk_input_data() is a wrapper around ide_input_data() which copes
@@ -1031,40 +1024,36 @@
 void do_ide_request (request_queue_t * q);
 void ide_init_subdrivers (void);
 
-#ifndef _IDE_C
 extern struct block_device_operations ide_fops[];
 extern ide_proc_entry_t generic_subdriver_entries[];
-#endif
 
-int ide_reinit_drive (ide_drive_t *drive);
+extern int ide_reinit_drive (ide_drive_t *drive);
 
-#ifdef _IDE_C
-# ifdef CONFIG_BLK_DEV_IDE
+#ifdef CONFIG_BLK_DEV_IDE
 /* Probe for devices attached to the systems host controllers.
  */
 extern int ideprobe_init (void);
-# endif
+#endif
 #ifdef CONFIG_BLK_DEV_IDEDISK
-int idedisk_reinit (ide_drive_t *drive);
-int idedisk_init (void);
+extern int idedisk_reinit (ide_drive_t *drive);
+extern int idedisk_init (void);
 #endif /* CONFIG_BLK_DEV_IDEDISK */
 #ifdef CONFIG_BLK_DEV_IDECD
-int ide_cdrom_reinit (ide_drive_t *drive);
-int ide_cdrom_init (void);
+extern int ide_cdrom_reinit (ide_drive_t *drive);
+extern int ide_cdrom_init (void);
 #endif /* CONFIG_BLK_DEV_IDECD */
 #ifdef CONFIG_BLK_DEV_IDETAPE
-int idetape_reinit (ide_drive_t *drive);
-int idetape_init (void);
+extern int idetape_reinit (ide_drive_t *drive);
+extern int idetape_init (void);
 #endif /* CONFIG_BLK_DEV_IDETAPE */
 #ifdef CONFIG_BLK_DEV_IDEFLOPPY
-int idefloppy_reinit (ide_drive_t *drive);
-int idefloppy_init (void);
+extern int idefloppy_reinit (ide_drive_t *drive);
+extern int idefloppy_init (void);
 #endif /* CONFIG_BLK_DEV_IDEFLOPPY */
 #ifdef CONFIG_BLK_DEV_IDESCSI
-int idescsi_reinit (ide_drive_t *drive);
-int idescsi_init (void);
+extern int idescsi_reinit (ide_drive_t *drive);
+extern int idescsi_init (void);
 #endif /* CONFIG_BLK_DEV_IDESCSI */
-#endif /* _IDE_C */
 
 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);

Re: [PATCH] 2.5.5 IDE cleanup 11

[Jeff Garzik]

> @@ -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;
>  }

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



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

Re: [PATCH] 2.5.5 IDE cleanup 11

[Andre Hedrick]

On Thu, 21 Feb 2002, Jeff Garzik wrote:

> > @@ -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;
> >  }
> 
> 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.

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

Re: [PATCH] 2.5.5 IDE cleanup 11

[Martin Dalecki]

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

Re: [PATCH] 2.5.5 IDE cleanup 11

[Alan Cox]

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

Re: [PATCH] 2.5.5 IDE cleanup 11

[Martin Dalecki]

Alan Cox wrote:
>>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.

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

Re: [PATCH] 2.5.5 IDE cleanup 11

[Alan Cox]

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

> 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

Re: [PATCH] 2.5.5 IDE cleanup 11

[Martin Dalecki]

Alan Cox wrote:
>>>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)
> 
> 
>>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.

Re: [PATCH] 2.5.5 IDE cleanup 11

[Pavel Machek]

Hi!

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

--- linux/drivers/ide/ide-disk.c	Mon Feb 11 20:51:47 2002
+++ linux-dm/drivers/ide/ide-disk.c	Mon Feb 11 23:35:09 2002
@@ -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",
--- linux/drivers/ide/ide-pnp.c	Thu Oct 25 13:25:37 2001
+++ linux-dm/drivers/ide/ide-pnp.c	Thu Feb 14 22:45:13 2002
@@ -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;
 	}
--- linux/drivers/ide/ide-probe.c	Thu Jan 31 23:39:35 2002
+++ linux-dm/drivers/ide/ide-probe.c	Thu Feb 14 22:50:53 2002
@@ -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);
--- linux/drivers/ide/ide.c	Mon Feb 11 20:51:47 2002
+++ linux-dm/drivers/ide/ide.c	Mon Feb 11 23:35:09 2002
@@ -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)
--- linux/include/linux/ide.h	Mon Feb 11 21:15:04 2002
+++ linux-dm/include/linux/ide.h	Thu Feb 14 22:47:23 2002
@@ -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;
 
 /*
 

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

Re: [PATCH] 2.5.5 IDE cleanup 11

[Alan Cox]

> 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

Re: [PATCH] 2.5.5 IDE cleanup 11

[Martin Dalecki]

Alan Cox wrote:
>>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?

Re: [PATCH] 2.5.5 IDE cleanup 11

[Alan Cox]

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

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

Re: [PATCH] 2.5.5 IDE cleanup 11

[Martin Dalecki]

Alan Cox wrote:
>>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.

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

Re: [PATCH] 2.5.5 IDE cleanup 11

[Andre Hedrick]

On Thu, 21 Feb 2002, Alan Cox wrote:

> > 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
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> 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

Re: [PATCH] 2.5.5 IDE cleanup 11

[Andre Hedrick]

[-- Attachment #1: Type: text/plain, Size: 1855 bytes --]


Alan,

Sorry I forgot to include the patch.

Andre Hedrick
Linux Disk Certification Project                Linux ATA Development

On Thu, 21 Feb 2002, Andre Hedrick wrote:

> On Thu, 21 Feb 2002, Alan Cox wrote:
> 
> > > 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
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majordomo@vger.kernel.org
> > 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
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 


[-- Attachment #2: Type: text/plain, Size: 984 bytes --]

--- linux-2.5.5-pristine/MAINTAINERS.orig	Thu Feb 21 13:26:44 2002
+++ linux-2.5.5-pristine/MAINTAINERS	Thu Feb 21 13:30:56 2002
@@ -697,13 +697,9 @@
 S:      Supported 
 
 IDE DRIVER [GENERAL]
-P:	Andre Hedrick
-M:	andre@linux-ide.org
-M:	andre@linuxdiskcert.org
+P:	Martin Dalecki	
+M:	Martin Dalecki <dalecki@evision-ventures.com>
 L:	linux-kernel@vger.kernel.org
-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:	vtun@office.satix.net
 W:	http://vtun.sourceforge.net/tun
 S:	Maintained
+
+SATA/PATA/ACB DRIVER [ALL]
+P:	Andre Hedrick
+M:	andre@linux-ide.org
+M:	andre@linuxdiskcert.org
+L:	linux-kernel@vger.kernel.org
+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

Flash Back -- kernel 2.1.111

[Andre Hedrick]

Linus,

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

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

Re: Flash Back -- kernel 2.1.111

[Rik van Riel]

On Fri, 22 Feb 2002, Andre Hedrick wrote:

> 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
-- 
"Linux holds advantages over the single-vendor commercial OS"
    -- Microsoft's "Competing with Linux" document

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

Re: Flash Back -- kernel 2.1.111

[Jens Axboe]

On Fri, Feb 22 2002, Rik van Riel wrote:
> On Fri, 22 Feb 2002, Andre Hedrick wrote:
> 
> > 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.

2.5 already supports 48-bit lba addressing.

-- 
Jens Axboe

Re: Flash Back -- kernel 2.1.111

[Linus Torvalds]

On Fri, 22 Feb 2002, Rik van Riel wrote:
>
> 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

Re: Flash Back -- kernel 2.1.111

[Andre Hedrick]

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


On Fri, 22 Feb 2002, Linus Torvalds wrote:

> 
> 
> On Fri, 22 Feb 2002, Rik van Riel wrote:
> >
> > 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

Re: Flash Back -- kernel 2.1.111

[Linus Torvalds]

On Fri, 22 Feb 2002, Andre Hedrick wrote:
> 
> 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

Re: Flash Back -- kernel 2.1.111

[Andre Hedrick]

On Sat, 23 Feb 2002, Linus Torvalds wrote:

> 
> On Fri, 22 Feb 2002, Andre Hedrick wrote:
> > 
> > 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?

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

> 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

Re: Flash Back -- kernel 2.1.111

[Andre Hedrick]

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

Re: Flash Back -- kernel 2.1.111

[Linus Torvalds]

On Sat, 23 Feb 2002, Andre Hedrick wrote:
>
> 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:

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

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

Re: Flash Back -- kernel 2.1.111

[Troy Benjegerdes]

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

-- 
Troy Benjegerdes | master of mispeeling | 'da hozer' |  hozer@drgw.net
-----"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

Re: Flash Back -- kernel 2.1.111

[Martin Dalecki]

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

Re: Flash Back -- kernel 2.1.111

[Troy Benjegerdes]

On Sun, Feb 24, 2002 at 01:18:33PM +0100, Martin Dalecki 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?
> > 
> > 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'.

-- 
Troy Benjegerdes | master of mispeeling | 'da hozer' |  hozer@drgw.net
-----"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

Re: Flash Back -- kernel 2.1.111

[Martin Dalecki]

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

Re: Flash Back -- kernel 2.1.111

[Alan Cox]

> 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

Re: Flash Back -- kernel 2.1.111

[Martin Dalecki]

Alan Cox wrote:
>>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...)

Re: Flash Back -- kernel 2.1.111

[Alan Cox]

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

Re: Flash Back -- kernel 2.1.111

[Martin Dalecki]

Alan Cox wrote:
>>(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.

Re: Flash Back -- kernel 2.1.111

[nick]

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

On Sun, 24 Feb 2002, Alan Cox wrote:

> > (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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Re: Flash Back -- kernel 2.1.111

[Rik van Riel]

On Sun, 24 Feb 2002 nick@snowman.net 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
-- 
"Linux holds advantages over the single-vendor commercial OS"
    -- Microsoft's "Competing with Linux" document

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

Re: Flash Back -- kernel 2.1.111

[Vojtech Pavlik]

On Sun, Feb 24, 2002 at 06:32:09PM -0300, Rik van Riel wrote:
> On Sun, 24 Feb 2002 nick@snowman.net 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.

-- 
Vojtech Pavlik
SuSE Labs

Re: Flash Back -- kernel 2.1.111

[nick]

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

On Sun, 24 Feb 2002, Vojtech Pavlik wrote:

> On Sun, Feb 24, 2002 at 06:32:09PM -0300, Rik van Riel wrote:
> > On Sun, 24 Feb 2002 nick@snowman.net 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.
> 
> -- 
> Vojtech Pavlik
> SuSE Labs
> 

Re: Flash Back -- kernel 2.1.111

[Vojtech Pavlik]

On Sun, Feb 24, 2002 at 09:31:37PM +0000, Alan Cox wrote:
> > (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?

-- 
Vojtech Pavlik
SuSE Labs

Re: Flash Back -- kernel 2.1.111

[Rik van Riel]

On Sun, 24 Feb 2002, Vojtech Pavlik wrote:

> 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
-- 
"Linux holds advantages over the single-vendor commercial OS"
    -- Microsoft's "Competing with Linux" document

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

Re: Flash Back -- kernel 2.1.111

[Jeff Garzik]

Alan Cox wrote:
> 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

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

Re: Flash Back -- kernel 2.1.111

[Vojtech Pavlik]

On Sun, Feb 24, 2002 at 09:15:06PM +0000, Alan Cox wrote:

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

-- 
Vojtech Pavlik
SuSE Labs

Re: Flash Back -- kernel 2.1.111

[Jeff Garzik]

Vojtech Pavlik wrote:
> 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



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

Re: Flash Back -- kernel 2.1.111

[Vojtech Pavlik]

On Sun, Feb 24, 2002 at 04:46:07PM -0500, Jeff Garzik wrote:

> > 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).

-- 
Vojtech Pavlik
SuSE Labs

Re: Flash Back -- kernel 2.1.111

[David S. Miller]

   From: Alan Cox <alan@lxorguk.ukuu.org.uk>
   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 :-)

Re: Flash Back -- kernel 2.1.111

[Vojtech Pavlik]

On Sun, Feb 24, 2002 at 02:29:03PM -0600, Troy Benjegerdes wrote:

> On Sun, Feb 24, 2002 at 01:18:33PM +0100, Martin Dalecki 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?
> > > 
> > > 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.

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

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

-- 
Vojtech Pavlik
SuSE Labs

Re: Flash Back -- kernel 2.1.111

[Troy Benjegerdes]

On Sun, Feb 24, 2002 at 09:54:22PM +0100, Vojtech Pavlik wrote:
> On Sun, Feb 24, 2002 at 02:29:03PM -0600, Troy Benjegerdes wrote:
> 
> > On Sun, Feb 24, 2002 at 01:18:33PM +0100, Martin Dalecki 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?
> > > > 
> > > > 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.
> 
> No. You don't need it. The base clock and multiplier are enough and you
> have the multiplier from PCI config.
> 
> > 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.

-- 
Troy Benjegerdes | master of mispeeling | 'da hozer' |  hozer@drgw.net
-----"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

Re: Flash Back -- kernel 2.1.111

[Vojtech Pavlik]

On Sun, Feb 24, 2002 at 03:19:23PM -0600, Troy Benjegerdes wrote:
> On Sun, Feb 24, 2002 at 09:54:22PM +0100, Vojtech Pavlik wrote:
> > On Sun, Feb 24, 2002 at 02:29:03PM -0600, Troy Benjegerdes wrote:
> > 
> > > On Sun, Feb 24, 2002 at 01:18:33PM +0100, Martin Dalecki 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?
> > > > > 
> > > > > 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.
> > 
> > No. You don't need it. The base clock and multiplier are enough and you
> > have the multiplier from PCI config.
> > 
> > > 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
> 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.

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

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

-- 
Vojtech Pavlik
SuSE Labs

Re: Flash Back -- kernel 2.1.111

[Paul Mackerras]

Vojtech Pavlik writes:

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

Re: Flash Back -- kernel 2.1.111

[Vojtech Pavlik]

On Mon, Feb 25, 2002 at 09:03:10AM +1100, Paul Mackerras wrote:
> Vojtech Pavlik writes:
> 
> > > 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.

-- 
Vojtech Pavlik
SuSE Labs

Re: Flash Back -- kernel 2.1.111

[Paul Mackerras]

Vojtech Pavlik writes:
> On Mon, Feb 25, 2002 at 09:03:10AM +1100, Paul Mackerras wrote:
> > Vojtech Pavlik writes:
> > 
> > > > 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.

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

Paul.

Re: Flash Back -- kernel 2.1.111

[Troy Benjegerdes]

On Mon, Feb 25, 2002 at 09:23:18AM +1100, Paul Mackerras wrote:
> Vojtech Pavlik writes:
> > On Mon, Feb 25, 2002 at 09:03:10AM +1100, Paul Mackerras wrote:
> > > Vojtech Pavlik writes:
> > > 
> > > > > 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.
> 
> 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 ;)

-- 
Troy Benjegerdes | master of mispeeling | 'da hozer' |  hozer@drgw.net
-----"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

Re: Flash Back -- kernel 2.1.111

[Chris Wedgwood]

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

Re: Flash Back -- kernel 2.1.111

[Paul Mackerras]

Vojtech Pavlik writes:

> On Sun, Feb 24, 2002 at 02:29:03PM -0600, Troy Benjegerdes wrote:
> > 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.

Re: Flash Back -- kernel 2.1.111

[Vojtech Pavlik]

On Mon, Feb 25, 2002 at 09:01:06AM +1100, Paul Mackerras wrote:
> Vojtech Pavlik writes:
> 
> > On Sun, Feb 24, 2002 at 02:29:03PM -0600, Troy Benjegerdes wrote:
> > > 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.

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.

-- 
Vojtech Pavlik
SuSE Labs

Re: Flash Back -- kernel 2.1.111

[Paul Mackerras]

Vojtech Pavlik writes:
> On Mon, Feb 25, 2002 at 09:01:06AM +1100, Paul Mackerras wrote:
> > 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.

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

The bus speed drops to 33MHz.

Paul.

Re: Flash Back -- kernel 2.1.111

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

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

Re: Flash Back -- kernel 2.1.111

[Vojtech Pavlik]

On Sun, Feb 24, 2002 at 02:27:51PM -0800, Andre Hedrick wrote:
> 
> 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.

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

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

I don't think driverfs will change this much.

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

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

-- 
Vojtech Pavlik
SuSE Labs

Re: Flash Back -- kernel 2.1.111

[Martin Dalecki]

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

Re: Flash Back -- kernel 2.1.111

[Vojtech Pavlik]

On Mon, Feb 25, 2002 at 09:25:13AM +1100, Paul Mackerras wrote:

> Vojtech Pavlik writes:
> > On Mon, Feb 25, 2002 at 09:01:06AM +1100, Paul Mackerras wrote:
> > > 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.

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

-- 
Vojtech Pavlik
SuSE Labs

Re: Flash Back -- kernel 2.1.111

[David S. Miller]

   From: Vojtech Pavlik <vojtech@suse.cz>
   Date: Sun, 24 Feb 2002 23:39:37 +0100
   
   > > 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?

Re: Flash Back -- kernel 2.1.111

[Vojtech Pavlik]

On Sun, Feb 24, 2002 at 02:44:23PM -0800, David S. Miller wrote:

>    From: Vojtech Pavlik <vojtech@suse.cz>
>    Date: Sun, 24 Feb 2002 23:39:37 +0100
>    
>    > > 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?

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.

-- 
Vojtech Pavlik
SuSE Labs

Re: Flash Back -- kernel 2.1.111

[Troy Benjegerdes]

On Sun, Feb 24, 2002 at 11:51:13PM +0100, Vojtech Pavlik wrote:
> On Sun, Feb 24, 2002 at 02:44:23PM -0800, David S. Miller wrote:
> 
> >    From: Vojtech Pavlik <vojtech@suse.cz>
> >    Date: Sun, 24 Feb 2002 23:39:37 +0100
> >    
> >    > > 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?
> 
> 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..

-- 
Troy Benjegerdes | master of mispeeling | 'da hozer' |  hozer@drgw.net
-----"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

Re: Flash Back -- kernel 2.1.111

[Vojtech Pavlik]

On Sun, Feb 24, 2002 at 04:59:37PM -0600, Troy Benjegerdes wrote:
> On Sun, Feb 24, 2002 at 11:51:13PM +0100, Vojtech Pavlik wrote:
> > On Sun, Feb 24, 2002 at 02:44:23PM -0800, David S. Miller wrote:
> > 
> > >    From: Vojtech Pavlik <vojtech@suse.cz>
> > >    Date: Sun, 24 Feb 2002 23:39:37 +0100
> > >    
> > >    > > 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?
> > 
> > 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..

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

-- 
Vojtech Pavlik
SuSE Labs

Re: Flash Back -- kernel 2.1.111

[Paul Mackerras]

Vojtech Pavlik writes:

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

Re: Flash Back -- kernel 2.1.111

[Remco Post]

> Vojtech Pavlik writes:
> 
> > 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 ;)


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

Re: Flash Back -- kernel 2.1.111

[Chris Wedgwood]

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

Re: Flash Back -- kernel 2.1.111

[Chris Wedgwood]

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

Re: Flash Back -- kernel 2.1.111

[Alan Cox]

> 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

Re: Flash Back -- kernel 2.1.111

[Vojtech Pavlik]

On Sun, Feb 24, 2002 at 01:18:33PM +0100, Martin Dalecki 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?
> > 
> > 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.

-- 
Vojtech Pavlik
SuSE Labs

Re: Flash Back -- kernel 2.1.111

[Chris Wedgwood]

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

Re: Flash Back -- kernel 2.1.111

[Andre Hedrick]

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

[PATCH] IDE clean 12 3rd attempt

[Martin Dalecki]

[-- Attachment #1: Type: text/plain, Size: 3673 bytes --]

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.



[-- Attachment #2: ide-clean-12.diff.gz --]
[-- Type: application/x-gzip, Size: 19969 bytes --]

Re: [PATCH] IDE clean 12 3rd attempt

[Greg KH]

On Sun, Feb 24, 2002 at 01:28:48PM +0100, Martin Dalecki wrote:
> 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

[PATCH] 2.5.6 IDE 18

[Martin Dalecki]

[-- Attachment #1: Type: text/plain, Size: 1738 bytes --]

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

[-- Attachment #2: ide-clean-18.diff --]
[-- Type: text/plain, Size: 77904 bytes --]

diff -urN linux-2.5.6/MAINTAINERS linux/MAINTAINERS
--- linux-2.5.6/MAINTAINERS	Fri Mar  8 03:18:07 2002
+++ linux/MAINTAINERS	Fri Mar  8 10:49:13 2002
@@ -709,14 +709,12 @@
 S:	Supported 
 
 IDE DRIVER [GENERAL]
-P:	Andre Hedrick
-M:	andre@linux-ide.org
-M:	andre@linuxdiskcert.org
+P:	Martin Dalecki
+M:	martin@dalecki.de
+I:	pl_PL.ISO8859-2, de_DE.ISO8859-15, (en_US.ISO8859-1)
 L:	linux-kernel@vger.kernel.org
-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
diff -urN linux-2.5.6/arch/alpha/defconfig linux/arch/alpha/defconfig
--- linux-2.5.6/arch/alpha/defconfig	Fri Mar  8 03:18:32 2002
+++ linux/arch/alpha/defconfig	Fri Mar  8 10:49:13 2002
@@ -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
diff -urN linux-2.5.6/arch/arm/def-configs/iq80310 linux/arch/arm/def-configs/iq80310
--- linux-2.5.6/arch/arm/def-configs/iq80310	Fri Mar  8 03:18:15 2002
+++ linux/arch/arm/def-configs/iq80310	Fri Mar  8 10:49:13 2002
@@ -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
diff -urN linux-2.5.6/arch/i386/defconfig linux/arch/i386/defconfig
--- linux-2.5.6/arch/i386/defconfig	Fri Mar  8 03:18:13 2002
+++ linux/arch/i386/defconfig	Fri Mar  8 10:49:13 2002
@@ -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
diff -urN linux-2.5.6/arch/ia64/defconfig linux/arch/ia64/defconfig
--- linux-2.5.6/arch/ia64/defconfig	Fri Mar  8 03:18:11 2002
+++ linux/arch/ia64/defconfig	Fri Mar  8 10:49:13 2002
@@ -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
diff -urN linux-2.5.6/arch/mips/defconfig-ddb5476 linux/arch/mips/defconfig-ddb5476
--- linux-2.5.6/arch/mips/defconfig-ddb5476	Fri Mar  8 03:18:28 2002
+++ linux/arch/mips/defconfig-ddb5476	Fri Mar  8 10:49:13 2002
@@ -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
diff -urN linux-2.5.6/arch/mips/defconfig-it8172 linux/arch/mips/defconfig-it8172
--- linux-2.5.6/arch/mips/defconfig-it8172	Fri Mar  8 03:18:25 2002
+++ linux/arch/mips/defconfig-it8172	Fri Mar  8 10:49:13 2002
@@ -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
diff -urN linux-2.5.6/arch/mips64/kernel/ioctl32.c linux/arch/mips64/kernel/ioctl32.c
--- linux-2.5.6/arch/mips64/kernel/ioctl32.c	Fri Mar  8 03:18:31 2002
+++ linux/arch/mips64/kernel/ioctl32.c	Fri Mar  8 10:49:13 2002
@@ -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),
diff -urN linux-2.5.6/arch/ppc/configs/common_defconfig linux/arch/ppc/configs/common_defconfig
--- linux-2.5.6/arch/ppc/configs/common_defconfig	Fri Mar  8 03:18:21 2002
+++ linux/arch/ppc/configs/common_defconfig	Fri Mar  8 10:49:13 2002
@@ -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
diff -urN linux-2.5.6/arch/ppc/configs/k2_defconfig linux/arch/ppc/configs/k2_defconfig
--- linux-2.5.6/arch/ppc/configs/k2_defconfig	Fri Mar  8 03:18:06 2002
+++ linux/arch/ppc/configs/k2_defconfig	Fri Mar  8 10:49:13 2002
@@ -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
diff -urN linux-2.5.6/arch/ppc/configs/menf1_defconfig linux/arch/ppc/configs/menf1_defconfig
--- linux-2.5.6/arch/ppc/configs/menf1_defconfig	Fri Mar  8 03:18:03 2002
+++ linux/arch/ppc/configs/menf1_defconfig	Fri Mar  8 10:49:13 2002
@@ -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
diff -urN linux-2.5.6/arch/ppc/configs/pmac_defconfig linux/arch/ppc/configs/pmac_defconfig
--- linux-2.5.6/arch/ppc/configs/pmac_defconfig	Fri Mar  8 03:18:57 2002
+++ linux/arch/ppc/configs/pmac_defconfig	Fri Mar  8 10:49:13 2002
@@ -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
diff -urN linux-2.5.6/arch/ppc/configs/pplus_defconfig linux/arch/ppc/configs/pplus_defconfig
--- linux-2.5.6/arch/ppc/configs/pplus_defconfig	Fri Mar  8 03:18:55 2002
+++ linux/arch/ppc/configs/pplus_defconfig	Fri Mar  8 10:49:13 2002
@@ -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
diff -urN linux-2.5.6/arch/ppc/configs/sandpoint_defconfig linux/arch/ppc/configs/sandpoint_defconfig
--- linux-2.5.6/arch/ppc/configs/sandpoint_defconfig	Fri Mar  8 03:18:29 2002
+++ linux/arch/ppc/configs/sandpoint_defconfig	Fri Mar  8 10:49:13 2002
@@ -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
diff -urN linux-2.5.6/arch/ppc/defconfig linux/arch/ppc/defconfig
--- linux-2.5.6/arch/ppc/defconfig	Fri Mar  8 03:18:19 2002
+++ linux/arch/ppc/defconfig	Fri Mar  8 10:49:13 2002
@@ -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
diff -urN linux-2.5.6/arch/ppc64/kernel/ioctl32.c linux/arch/ppc64/kernel/ioctl32.c
--- linux-2.5.6/arch/ppc64/kernel/ioctl32.c	Fri Mar  8 03:18:59 2002
+++ linux/arch/ppc64/kernel/ioctl32.c	Fri Mar  8 10:49:13 2002
@@ -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),
diff -urN linux-2.5.6/arch/sparc64/defconfig linux/arch/sparc64/defconfig
--- linux-2.5.6/arch/sparc64/defconfig	Fri Mar  8 03:18:23 2002
+++ linux/arch/sparc64/defconfig	Fri Mar  8 10:49:13 2002
@@ -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
diff -urN linux-2.5.6/arch/sparc64/kernel/ioctl32.c linux/arch/sparc64/kernel/ioctl32.c
--- linux-2.5.6/arch/sparc64/kernel/ioctl32.c	Fri Mar  8 03:18:24 2002
+++ linux/arch/sparc64/kernel/ioctl32.c	Fri Mar  8 10:49:13 2002
@@ -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)
diff -urN linux-2.5.6/arch/x86_64/ia32/ia32_ioctl.c linux/arch/x86_64/ia32/ia32_ioctl.c
--- linux-2.5.6/arch/x86_64/ia32/ia32_ioctl.c	Fri Mar  8 03:18:03 2002
+++ linux/arch/x86_64/ia32/ia32_ioctl.c	Fri Mar  8 10:49:13 2002
@@ -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)
diff -urN linux-2.5.6/drivers/ide/Config.help linux/drivers/ide/Config.help
--- linux-2.5.6/drivers/ide/Config.help	Fri Mar  8 03:18:57 2002
+++ linux/drivers/ide/Config.help	Fri Mar  8 10:49:13 2002
@@ -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.
 
diff -urN linux-2.5.6/drivers/ide/Config.in linux/drivers/ide/Config.in
--- linux-2.5.6/drivers/ide/Config.in	Fri Mar  8 03:18:57 2002
+++ linux/drivers/ide/Config.in	Fri Mar  8 10:49:13 2002
@@ -4,7 +4,7 @@
 # Andre Hedrick <andre@linux-ide.org>
 #
 mainmenu_option next_comment
-comment 'IDE, ATA and ATAPI Block devices'
+comment 'ATA and ATAPI Block devices'
 
 dep_tristate 'Enhanced IDE/MFM/RLL disk/cdrom/tape/floppy support' CONFIG_BLK_DEV_IDE $CONFIG_IDE
 comment 'Please see Documentation/ide.txt for help/info on IDE drives'
@@ -34,121 +34,120 @@
    dep_tristate '  SCSI emulation support' CONFIG_BLK_DEV_IDESCSI $CONFIG_BLK_DEV_IDE $CONFIG_SCSI
 
    comment 'IDE chipset support'
-   if [ "$CONFIG_BLK_DEV_IDE" != "n" ]; then
-      dep_bool '  CMD640 chipset bugfix/support' CONFIG_BLK_DEV_CMD640 $CONFIG_X86
-      dep_bool '    CMD640 enhanced support' CONFIG_BLK_DEV_CMD640_ENHANCED $CONFIG_BLK_DEV_CMD640
-      dep_bool '  ISA-PNP EIDE support' CONFIG_BLK_DEV_ISAPNP $CONFIG_ISAPNP
-      if [ "$CONFIG_PCI" = "y" ]; then
-	 dep_bool '  RZ1000 chipset bugfix/support' CONFIG_BLK_DEV_RZ1000 $CONFIG_X86
-	 bool '  Generic PCI IDE chipset support' CONFIG_BLK_DEV_IDEPCI
-	 if [ "$CONFIG_BLK_DEV_IDEPCI" = "y" ]; then
-	    bool '    Sharing PCI IDE interrupts support' CONFIG_IDEPCI_SHARE_IRQ
-	    bool '    Generic PCI bus-master DMA support' CONFIG_BLK_DEV_IDEDMA_PCI
-	    bool '    Boot off-board chipsets first support' CONFIG_BLK_DEV_OFFBOARD
-	    dep_bool '      Use PCI DMA by default when available' CONFIG_IDEDMA_PCI_AUTO $CONFIG_BLK_DEV_IDEDMA_PCI
-            dep_bool '    Enable DMA only for disks ' CONFIG_IDEDMA_ONLYDISK $CONFIG_IDEDMA_PCI_AUTO
-	    define_bool CONFIG_BLK_DEV_IDEDMA $CONFIG_BLK_DEV_IDEDMA_PCI
-	    dep_bool '      ATA Work(s) In Progress (EXPERIMENTAL)' CONFIG_IDEDMA_PCI_WIP $CONFIG_BLK_DEV_IDEDMA_PCI $CONFIG_EXPERIMENTAL
-	    dep_bool '      Attempt to HACK around Chipsets that TIMEOUT (WIP)' CONFIG_BLK_DEV_IDEDMA_TIMEOUT $CONFIG_IDEDMA_PCI_WIP
-	    dep_bool '      Good-Bad DMA Model-Firmware (WIP)' CONFIG_IDEDMA_NEW_DRIVE_LISTINGS $CONFIG_IDEDMA_PCI_WIP
-#	    dep_bool '      Asynchronous DMA support (WIP) (EXPERIMENTAL)' CONFIG_BLK_DEV_ADMA $CONFIG_BLK_DEV_IDEDMA_PCI $CONFIG_IDEDMA_PCI_WIP
-	    define_bool CONFIG_BLK_DEV_ADMA $CONFIG_BLK_DEV_IDEDMA_PCI
-#	    dep_bool '      Tag Command Queue DMA support (WIP) (EXPERIMENTAL)' CONFIG_BLK_DEV_IDEDMA_TCQ $CONFIG_BLK_DEV_IDEDMA_PCI $CONFIG_IDEDMA_PCI_WIP
-
-	    dep_bool '    AEC62XX chipset support' CONFIG_BLK_DEV_AEC62XX $CONFIG_BLK_DEV_IDEDMA_PCI
-	    dep_mbool '      AEC62XX Tuning support' CONFIG_AEC62XX_TUNING $CONFIG_BLK_DEV_AEC62XX
-	    dep_bool '    ALI M15x3 chipset support' CONFIG_BLK_DEV_ALI15X3 $CONFIG_BLK_DEV_IDEDMA_PCI
-	    dep_mbool '      ALI M15x3 WDC support (DANGEROUS)' CONFIG_WDC_ALI15X3 $CONFIG_BLK_DEV_ALI15X3
-	    dep_bool '    AMD Viper support' CONFIG_BLK_DEV_AMD74XX $CONFIG_BLK_DEV_IDEDMA_PCI
-	    dep_mbool '      AMD Viper ATA-66 Override (WIP)' CONFIG_AMD74XX_OVERRIDE $CONFIG_BLK_DEV_AMD74XX $CONFIG_IDEDMA_PCI_WIP
-	    dep_bool '    CMD64X chipset support' CONFIG_BLK_DEV_CMD64X $CONFIG_BLK_DEV_IDEDMA_PCI
-	    dep_bool '    CY82C693 chipset support' CONFIG_BLK_DEV_CY82C693 $CONFIG_BLK_DEV_IDEDMA_PCI
-	    dep_bool '    Cyrix CS5530 MediaGX chipset support' CONFIG_BLK_DEV_CS5530 $CONFIG_BLK_DEV_IDEDMA_PCI
-  	    dep_bool '    HPT34X chipset support' CONFIG_BLK_DEV_HPT34X $CONFIG_BLK_DEV_IDEDMA_PCI
-	    dep_mbool '      HPT34X AUTODMA support (WIP)' CONFIG_HPT34X_AUTODMA $CONFIG_BLK_DEV_HPT34X $CONFIG_IDEDMA_PCI_WIP
-	    dep_bool '    HPT366 chipset support' CONFIG_BLK_DEV_HPT366 $CONFIG_BLK_DEV_IDEDMA_PCI
-	    if [ "$CONFIG_X86" = "y" -o "$CONFIG_IA64" = "y" ]; then
-	       dep_mbool '    Intel PIIXn chipsets support' CONFIG_BLK_DEV_PIIX $CONFIG_BLK_DEV_IDEDMA_PCI
-	       dep_mbool '      PIIXn Tuning support' CONFIG_PIIX_TUNING $CONFIG_BLK_DEV_PIIX $CONFIG_IDEDMA_PCI_AUTO
-	    fi
-	    if [ "$CONFIG_MIPS_ITE8172" = "y" -o "$CONFIG_MIPS_IVR" = "y" ]; then
-	       dep_mbool '    IT8172 IDE support' CONFIG_BLK_DEV_IT8172 $CONFIG_BLK_DEV_IDEDMA_PCI
-	       dep_mbool '      IT8172 IDE Tuning support' CONFIG_IT8172_TUNING $CONFIG_BLK_DEV_IT8172 $CONFIG_IDEDMA_PCI_AUTO
-	    fi
-	    dep_bool '    NS87415 chipset support (EXPERIMENTAL)' CONFIG_BLK_DEV_NS87415 $CONFIG_BLK_DEV_IDEDMA_PCI
-	    dep_bool '    OPTi 82C621 chipset enhanced support (EXPERIMENTAL)' CONFIG_BLK_DEV_OPTI621 $CONFIG_EXPERIMENTAL
-	    dep_mbool '   Pacific Digital A-DMA support (EXPERIMENTAL)' CONFIG_BLK_DEV_PDC_ADMA $CONFIG_BLK_DEV_ADMA $CONFIG_IDEDMA_PCI_WIP
-	    dep_bool '    PROMISE PDC202{46|62|65|67|68|69|70} support' CONFIG_BLK_DEV_PDC202XX $CONFIG_BLK_DEV_IDEDMA_PCI
-	    dep_bool '      Special UDMA Feature' CONFIG_PDC202XX_BURST $CONFIG_BLK_DEV_PDC202XX
-	    dep_bool '      Special FastTrak Feature' CONFIG_PDC202XX_FORCE $CONFIG_BLK_DEV_PDC202XX
-	    dep_bool '    ServerWorks OSB4/CSB5 chipsets support' CONFIG_BLK_DEV_SVWKS $CONFIG_BLK_DEV_IDEDMA_PCI $CONFIG_X86
-	    dep_bool '    SiS5513 chipset support' CONFIG_BLK_DEV_SIS5513 $CONFIG_BLK_DEV_IDEDMA_PCI $CONFIG_X86
-	    dep_bool '    SLC90E66 chipset support' CONFIG_BLK_DEV_SLC90E66 $CONFIG_BLK_DEV_IDEDMA_PCI $CONFIG_X86
-	    dep_bool '    Tekram TRM290 chipset support (EXPERIMENTAL)' CONFIG_BLK_DEV_TRM290 $CONFIG_BLK_DEV_IDEDMA_PCI
-	    dep_bool '    VIA82CXXX chipset support' CONFIG_BLK_DEV_VIA82CXXX $CONFIG_BLK_DEV_IDEDMA_PCI
-         fi
-
-	 if [ "$CONFIG_PPC" = "y" -o "$CONFIG_ARM" = "y" ]; then
-	    bool '    Winbond SL82c105 support' CONFIG_BLK_DEV_SL82C105
-	 fi
-      fi
-      if [ "$CONFIG_ALL_PPC" = "y" ]; then
-	 bool '    Builtin PowerMac IDE support' CONFIG_BLK_DEV_IDE_PMAC
-	 dep_bool '      PowerMac IDE DMA support' CONFIG_BLK_DEV_IDEDMA_PMAC $CONFIG_BLK_DEV_IDE_PMAC
-	 dep_bool '        Use DMA by default' CONFIG_BLK_DEV_IDEDMA_PMAC_AUTO $CONFIG_BLK_DEV_IDEDMA_PMAC
-	 if [ "$CONFIG_BLK_DEV_IDE_PMAC" = "y" ]; then
-	   define_bool CONFIG_BLK_DEV_IDEDMA $CONFIG_BLK_DEV_IDEDMA_PMAC
+   dep_bool '  CMD640 chipset bugfix/support' CONFIG_BLK_DEV_CMD640 $CONFIG_X86
+   dep_bool '    CMD640 enhanced support' CONFIG_BLK_DEV_CMD640_ENHANCED $CONFIG_BLK_DEV_CMD640
+   dep_bool '  ISA-PNP EIDE support' CONFIG_BLK_DEV_ISAPNP $CONFIG_ISAPNP
+   if [ "$CONFIG_PCI" = "y" ]; then
+      dep_bool '  RZ1000 chipset bugfix/support' CONFIG_BLK_DEV_RZ1000 $CONFIG_X86
+      bool '  Generic PCI IDE chipset support' CONFIG_BLK_DEV_IDEPCI
+      if [ "$CONFIG_BLK_DEV_IDEPCI" = "y" ]; then
+	 bool '    Boot off-board chipsets first support' CONFIG_BLK_DEV_OFFBOARD
+	 bool '    Sharing PCI IDE interrupts support' CONFIG_IDEPCI_SHARE_IRQ
+	 bool '    Generic PCI bus-master DMA support' CONFIG_BLK_DEV_IDEDMA_PCI
+	 dep_bool '      Use PCI DMA by default when available' CONFIG_IDEDMA_PCI_AUTO $CONFIG_BLK_DEV_IDEDMA_PCI
+         dep_bool '    Enable DMA only for disks ' CONFIG_IDEDMA_ONLYDISK $CONFIG_IDEDMA_PCI_AUTO
+	 define_bool CONFIG_BLK_DEV_IDEDMA $CONFIG_BLK_DEV_IDEDMA_PCI
+	 dep_bool '    ATA Work(s) In Progress (EXPERIMENTAL)' CONFIG_IDEDMA_PCI_WIP $CONFIG_BLK_DEV_IDEDMA_PCI $CONFIG_EXPERIMENTAL
+	 dep_bool '    Attempt to HACK around Chipsets that TIMEOUT (WIP)' CONFIG_BLK_DEV_IDEDMA_TIMEOUT $CONFIG_IDEDMA_PCI_WIP
+	 dep_bool '    Good-Bad DMA Model-Firmware (WIP)' CONFIG_IDEDMA_NEW_DRIVE_LISTINGS $CONFIG_IDEDMA_PCI_WIP
+	 dep_bool '    AEC62XX chipset support' CONFIG_BLK_DEV_AEC62XX $CONFIG_BLK_DEV_IDEDMA_PCI
+	 dep_mbool '      AEC62XX Tuning support' CONFIG_AEC62XX_TUNING $CONFIG_BLK_DEV_AEC62XX
+	 dep_bool '    ALI M15x3 chipset support' CONFIG_BLK_DEV_ALI15X3 $CONFIG_BLK_DEV_IDEDMA_PCI
+	 dep_mbool '      ALI M15x3 WDC support (DANGEROUS)' CONFIG_WDC_ALI15X3 $CONFIG_BLK_DEV_ALI15X3
+	 dep_bool '    AMD Viper support' CONFIG_BLK_DEV_AMD74XX $CONFIG_BLK_DEV_IDEDMA_PCI
+	 dep_mbool '      AMD Viper ATA-66 Override (WIP)' CONFIG_AMD74XX_OVERRIDE $CONFIG_BLK_DEV_AMD74XX $CONFIG_IDEDMA_PCI_WIP
+	 dep_bool '    CMD64X chipset support' CONFIG_BLK_DEV_CMD64X $CONFIG_BLK_DEV_IDEDMA_PCI
+	 dep_bool '    CY82C693 chipset support' CONFIG_BLK_DEV_CY82C693 $CONFIG_BLK_DEV_IDEDMA_PCI
+	 dep_bool '    Cyrix CS5530 MediaGX chipset support' CONFIG_BLK_DEV_CS5530 $CONFIG_BLK_DEV_IDEDMA_PCI
+  	 dep_bool '    HPT34X chipset support' CONFIG_BLK_DEV_HPT34X $CONFIG_BLK_DEV_IDEDMA_PCI
+	 dep_mbool '      HPT34X AUTODMA support (WIP)' CONFIG_HPT34X_AUTODMA $CONFIG_BLK_DEV_HPT34X $CONFIG_IDEDMA_PCI_WIP
+	 dep_bool '    HPT366 chipset support' CONFIG_BLK_DEV_HPT366 $CONFIG_BLK_DEV_IDEDMA_PCI
+	 if [ "$CONFIG_X86" = "y" -o "$CONFIG_IA64" = "y" ]; then
+	    dep_mbool '    Intel PIIXn chipsets support' CONFIG_BLK_DEV_PIIX $CONFIG_BLK_DEV_IDEDMA_PCI
+	    dep_mbool '      PIIXn Tuning support' CONFIG_PIIX_TUNING $CONFIG_BLK_DEV_PIIX $CONFIG_IDEDMA_PCI_AUTO
 	 fi
-	 if [ "$CONFIG_BLK_DEV_IDEDMA_PMAC" = "y" ]; then
-	   define_bool CONFIG_BLK_DEV_IDEPCI $CONFIG_BLK_DEV_IDEDMA_PMAC
+	 if [ "$CONFIG_MIPS_ITE8172" = "y" -o "$CONFIG_MIPS_IVR" = "y" ]; then
+	    dep_mbool '    IT8172 IDE support' CONFIG_BLK_DEV_IT8172 $CONFIG_BLK_DEV_IDEDMA_PCI
+	    dep_mbool '      IT8172 IDE Tuning support' CONFIG_IT8172_TUNING $CONFIG_BLK_DEV_IT8172 $CONFIG_IDEDMA_PCI_AUTO
 	 fi
+	 dep_bool '    NS87415 chipset support (EXPERIMENTAL)' CONFIG_BLK_DEV_NS87415 $CONFIG_BLK_DEV_IDEDMA_PCI
+	 dep_bool '    OPTi 82C621 chipset enhanced support (EXPERIMENTAL)' CONFIG_BLK_DEV_OPTI621 $CONFIG_EXPERIMENTAL
+	 dep_mbool '    Pacific Digital A-DMA support (EXPERIMENTAL)' CONFIG_BLK_DEV_PDC_ADMA $CONFIG_IDEDMA_PCI_WIP
+	 dep_bool '    PROMISE PDC202{46|62|65|67|68|69|70} support' CONFIG_BLK_DEV_PDC202XX $CONFIG_BLK_DEV_IDEDMA_PCI
+	 dep_bool '      Special UDMA Feature' CONFIG_PDC202XX_BURST $CONFIG_BLK_DEV_PDC202XX
+	 dep_bool '      Special FastTrak Feature' CONFIG_PDC202XX_FORCE $CONFIG_BLK_DEV_PDC202XX
+	 dep_bool '    ServerWorks OSB4/CSB5 chipsets support' CONFIG_BLK_DEV_SVWKS $CONFIG_BLK_DEV_IDEDMA_PCI $CONFIG_X86
+	 dep_bool '    SiS5513 chipset support' CONFIG_BLK_DEV_SIS5513 $CONFIG_BLK_DEV_IDEDMA_PCI $CONFIG_X86
+	 dep_bool '    SLC90E66 chipset support' CONFIG_BLK_DEV_SLC90E66 $CONFIG_BLK_DEV_IDEDMA_PCI $CONFIG_X86
+	 dep_bool '    Tekram TRM290 chipset support (EXPERIMENTAL)' CONFIG_BLK_DEV_TRM290 $CONFIG_BLK_DEV_IDEDMA_PCI
+	 dep_bool '    VIA82CXXX chipset support' CONFIG_BLK_DEV_VIA82CXXX $CONFIG_BLK_DEV_IDEDMA_PCI
       fi
-      if [ "$CONFIG_ARCH_ACORN" = "y" ]; then
-	 dep_bool '    ICS IDE interface support' CONFIG_BLK_DEV_IDE_ICSIDE $CONFIG_ARCH_ACORN
-	 dep_bool '      ICS DMA support' CONFIG_BLK_DEV_IDEDMA_ICS $CONFIG_BLK_DEV_IDE_ICSIDE
-	 dep_bool '        Use ICS DMA by default' CONFIG_IDEDMA_ICS_AUTO $CONFIG_BLK_DEV_IDEDMA_ICS
-	 define_bool CONFIG_BLK_DEV_IDEDMA $CONFIG_BLK_DEV_IDEDMA_ICS
-	 dep_bool '    RapIDE interface support' CONFIG_BLK_DEV_IDE_RAPIDE $CONFIG_ARCH_ACORN
-      fi
-      if [ "$CONFIG_AMIGA" = "y" ]; then
-	 dep_bool '  Amiga Gayle IDE interface support' CONFIG_BLK_DEV_GAYLE $CONFIG_AMIGA
-	 dep_mbool '    Amiga IDE Doubler support (EXPERIMENTAL)' CONFIG_BLK_DEV_IDEDOUBLER $CONFIG_BLK_DEV_GAYLE $CONFIG_EXPERIMENTAL
-      fi
-      if [ "$CONFIG_ZORRO" = "y" -a "$CONFIG_EXPERIMENTAL" = "y" ]; then
-	 dep_mbool '  Buddha/Catweasel IDE interface support (EXPERIMENTAL)' CONFIG_BLK_DEV_BUDDHA $CONFIG_ZORRO $CONFIG_EXPERIMENTAL
-      fi
-      if [ "$CONFIG_ATARI" = "y" ]; then
-	 dep_bool '  Falcon IDE interface support' CONFIG_BLK_DEV_FALCON_IDE $CONFIG_ATARI
-      fi
-      if [ "$CONFIG_MAC" = "y" ]; then
-	 dep_bool '  Macintosh Quadra/Powerbook IDE interface support' CONFIG_BLK_DEV_MAC_IDE $CONFIG_MAC
+
+      if [ "$CONFIG_PPC" = "y" -o "$CONFIG_ARM" = "y" ]; then
+	 bool '    Winbond SL82c105 support' CONFIG_BLK_DEV_SL82C105
       fi
-      if [ "$CONFIG_Q40" = "y" ]; then
-	 dep_bool '  Q40/Q60 IDE interface support' CONFIG_BLK_DEV_Q40IDE $CONFIG_Q40
+   fi
+   if [ "$CONFIG_ALL_PPC" = "y" ]; then
+      bool '    Builtin PowerMac IDE support' CONFIG_BLK_DEV_IDE_PMAC
+      dep_bool '      PowerMac IDE DMA support' CONFIG_BLK_DEV_IDEDMA_PMAC $CONFIG_BLK_DEV_IDE_PMAC
+      dep_bool '        Use DMA by default' CONFIG_BLK_DEV_IDEDMA_PMAC_AUTO $CONFIG_BLK_DEV_IDEDMA_PMAC
+      if [ "$CONFIG_BLK_DEV_IDE_PMAC" = "y" ]; then
+	 define_bool CONFIG_BLK_DEV_IDEDMA $CONFIG_BLK_DEV_IDEDMA_PMAC
       fi
-      if [ "$CONFIG_8xx" = "y" ]; then
-         dep_bool '  MPC8xx IDE support' CONFIG_BLK_DEV_MPC8xx_IDE $CONFIG_8xx
+      if [ "$CONFIG_BLK_DEV_IDEDMA_PMAC" = "y" ]; then
+	 define_bool CONFIG_BLK_DEV_IDEPCI $CONFIG_BLK_DEV_IDEDMA_PMAC
       fi
+   fi
+   if [ "$CONFIG_ARCH_ACORN" = "y" ]; then
+      dep_bool '    ICS IDE interface support' CONFIG_BLK_DEV_IDE_ICSIDE $CONFIG_ARCH_ACORN
+      dep_bool '      ICS DMA support' CONFIG_BLK_DEV_IDEDMA_ICS $CONFIG_BLK_DEV_IDE_ICSIDE
+      dep_bool '        Use ICS DMA by default' CONFIG_IDEDMA_ICS_AUTO $CONFIG_BLK_DEV_IDEDMA_ICS
+      define_bool CONFIG_BLK_DEV_IDEDMA $CONFIG_BLK_DEV_IDEDMA_ICS
+      dep_bool '    RapIDE interface support' CONFIG_BLK_DEV_IDE_RAPIDE $CONFIG_ARCH_ACORN
+   fi
+   if [ "$CONFIG_AMIGA" = "y" ]; then
+      dep_bool '  Amiga Gayle IDE interface support' CONFIG_BLK_DEV_GAYLE $CONFIG_AMIGA
+      dep_mbool '    Amiga IDE Doubler support (EXPERIMENTAL)' CONFIG_BLK_DEV_IDEDOUBLER $CONFIG_BLK_DEV_GAYLE $CONFIG_EXPERIMENTAL
+   fi
+   if [ "$CONFIG_ZORRO" = "y" -a "$CONFIG_EXPERIMENTAL" = "y" ]; then
+      dep_mbool '  Buddha/Catweasel IDE interface support (EXPERIMENTAL)' CONFIG_BLK_DEV_BUDDHA $CONFIG_ZORRO $CONFIG_EXPERIMENTAL
+   fi
+   if [ "$CONFIG_ATARI" = "y" ]; then
+      dep_bool '  Falcon IDE interface support' CONFIG_BLK_DEV_FALCON_IDE $CONFIG_ATARI
+   fi
+   if [ "$CONFIG_MAC" = "y" ]; then
+      dep_bool '  Macintosh Quadra/Powerbook IDE interface support' CONFIG_BLK_DEV_MAC_IDE $CONFIG_MAC
+   fi
+   if [ "$CONFIG_Q40" = "y" ]; then
+      dep_bool '  Q40/Q60 IDE interface support' CONFIG_BLK_DEV_Q40IDE $CONFIG_Q40
+   fi
+   if [ "$CONFIG_8xx" = "y" ]; then
+      dep_bool '  MPC8xx IDE support' CONFIG_BLK_DEV_MPC8xx_IDE $CONFIG_8xx
+   fi
 
-      if [ "$CONFIG_BLK_DEV_MPC8xx_IDE" = "y" ]; then
-         choice 'Type of MPC8xx IDE interface'		\
-		"8xx_PCCARD	CONFIG_IDE_8xx_PCCARD	\
-		 8xx_DIRECT	CONFIG_IDE_8xx_DIRECT	\
-		 EXT_DIRECT	CONFIG_IDE_EXT_DIRECT"	8xx_PCCARD
-      fi
+   if [ "$CONFIG_BLK_DEV_MPC8xx_IDE" = "y" ]; then
+      choice 'Type of MPC8xx IDE interface'		\
+	     "8xx_PCCARD	CONFIG_IDE_8xx_PCCARD	\
+	      8xx_DIRECT	CONFIG_IDE_8xx_DIRECT	\
+	      EXT_DIRECT	CONFIG_IDE_EXT_DIRECT"	8xx_PCCARD
+   fi
 
-      bool '  Other IDE chipset support' CONFIG_IDE_CHIPSETS
-      if [ "$CONFIG_IDE_CHIPSETS" = "y" ]; then
-	 comment 'Note: most of these also require special kernel boot parameters'
-	 bool '    ALI M14xx support' CONFIG_BLK_DEV_ALI14XX
-	 bool '    DTC-2278 support' CONFIG_BLK_DEV_DTC2278
-	 bool '    Holtek HT6560B support' CONFIG_BLK_DEV_HT6560B
-	 if [ "$CONFIG_BLK_DEV_IDEDISK" = "y" -a "$CONFIG_EXPERIMENTAL" = "y" ]; then
-	    bool '    PROMISE DC4030 support (EXPERIMENTAL)' CONFIG_BLK_DEV_PDC4030
-	 fi
-	 bool '    QDI QD65xx support' CONFIG_BLK_DEV_QD65XX
-	 bool '    UMC-8672 support' CONFIG_BLK_DEV_UMC8672
+   bool '  Other IDE chipset support' CONFIG_IDE_CHIPSETS
+   if [ "$CONFIG_IDE_CHIPSETS" = "y" ]; then
+      comment 'Note: most of these also require special kernel boot parameters'
+      bool '    ALI M14xx support' CONFIG_BLK_DEV_ALI14XX
+      bool '    DTC-2278 support' CONFIG_BLK_DEV_DTC2278
+      bool '    Holtek HT6560B support' CONFIG_BLK_DEV_HT6560B
+      if [ "$CONFIG_BLK_DEV_IDEDISK" = "y" -a "$CONFIG_EXPERIMENTAL" = "y" ]; then
+	 bool '    PROMISE DC4030 support (EXPERIMENTAL)' CONFIG_BLK_DEV_PDC4030
       fi
+      bool '    QDI QD65xx support' CONFIG_BLK_DEV_QD65XX
+      bool '    UMC-8672 support' CONFIG_BLK_DEV_UMC8672
+   fi
+   if [ "$CONFIG_BLK_DEV_IDEDMA_PCI" = "y" -o \
+        "$CONFIG_BLK_DEV_IDEDMA_PMAC" = "y" -o \
+        "$CONFIG_BLK_DEV_IDEDMA_ICS" = "y" ]; then
+      bool '  IGNORE word93 Validation BITS' CONFIG_IDEDMA_IVB
    fi
 else
    bool 'Old hard disk (MFM/RLL/IDE) driver' CONFIG_BLK_DEV_HD_ONLY
@@ -163,12 +162,6 @@
    define_bool CONFIG_IDEDMA_AUTO n
 fi
 
-if [ "$CONFIG_BLK_DEV_IDEDMA_PCI" = "y" -o \
-     "$CONFIG_BLK_DEV_IDEDMA_PMAC" = "y" -o \
-     "$CONFIG_BLK_DEV_IDEDMA_ICS" = "y" ]; then
-   bool '  IGNORE word93 Validation BITS' CONFIG_IDEDMA_IVB
-fi
-
 if [ "$CONFIG_BLK_DEV_TIVO" = "y" ]; then
   define_bool CONFIG_DMA_NONPCI y
 else
diff -urN linux-2.5.6/drivers/ide/Makefile linux/drivers/ide/Makefile
--- linux-2.5.6/drivers/ide/Makefile	Fri Mar  8 03:18:11 2002
+++ linux/drivers/ide/Makefile	Fri Mar  8 10:49:13 2002
@@ -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
diff -urN linux-2.5.6/drivers/ide/ide-adma.c linux/drivers/ide/ide-adma.c
--- linux-2.5.6/drivers/ide/ide-adma.c	Fri Mar  8 03:18:27 2002
+++ linux/drivers/ide/ide-adma.c	Thu Jan  1 01:00:00 1970
@@ -1,9 +0,0 @@
-/*
- *  linux/drivers/ide/ide-adma.c         Version 0.00	June 24, 2001
- *
- *  Copyright (c) 2001		Andre Hedrick <andre@linux-ide.org>
- *
- *  Asynchronous DMA -- TBA, this is a holding file.
- *
- */
-
diff -urN linux-2.5.6/drivers/ide/ide-cd.c linux/drivers/ide/ide-cd.c
--- linux-2.5.6/drivers/ide/ide-cd.c	Fri Mar  8 03:18:28 2002
+++ linux/drivers/ide/ide-cd.c	Fri Mar  8 10:49:13 2002
@@ -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,
diff -urN linux-2.5.6/drivers/ide/ide-cs.c linux/drivers/ide/ide-cs.c
--- linux-2.5.6/drivers/ide/ide-cs.c	Fri Mar  8 03:18:23 2002
+++ linux/drivers/ide/ide-cs.c	Fri Mar  8 10:49:13 2002
@@ -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;
     }
 
diff -urN linux-2.5.6/drivers/ide/ide-dma.c linux/drivers/ide/ide-dma.c
--- linux-2.5.6/drivers/ide/ide-dma.c	Fri Mar  8 03:18:16 2002
+++ linux/drivers/ide/ide-dma.c	Fri Mar  8 10:49:13 2002
@@ -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;
 }
 
diff -urN linux-2.5.6/drivers/ide/ide-pci.c linux/drivers/ide/ide-pci.c
--- linux-2.5.6/drivers/ide/ide-pci.c	Fri Mar  8 03:18:56 2002
+++ linux/drivers/ide/ide-pci.c	Fri Mar  8 10:49:13 2002
@@ -6,15 +6,8 @@
  */
 
 /*
- *  This module provides support for automatic detection and
- *  configuration of all PCI IDE interfaces present in a system.
- */
-
-/*
- * Chipsets that are on the IDE_IGNORE list because of problems of not being
- * set at compile time.
- *
- * CONFIG_BLK_DEV_PDC202XX
+ *  This module provides support for automatic detection and configuration of
+ *  all PCI ATA host chip chanells interfaces present in a system.
  */
 
 #include <linux/config.h>
@@ -34,8 +27,14 @@
 #define PCI_VENDOR_ID_HINT 0x3388
 #define PCI_DEVICE_ID_HINT 0x8013
 
-#define	IDE_IGNORE	((void *)-1)
-#define IDE_NO_DRIVER	((void *)-2)
+/*
+ * Some combi chips, which can be used on the PCI bus or the VL bus can be in
+ * some systems acessed either through the PCI config space or through the
+ * hosts IO bus.  If the corresponding initialization driver is using the host
+ * IO space to deal with them please define the following.
+ */
+
+#define	ATA_PCI_IGNORE	((void *)-1)
 
 #ifdef CONFIG_BLK_DEV_AEC62XX
 extern unsigned int pci_init_aec62xx(struct pci_dev *);
@@ -306,7 +305,7 @@
 	 * but which still need some generic quirk handling.
 	 */
 	{PCI_VENDOR_ID_PCTECH, PCI_DEVICE_ID_PCTECH_SAMURAI_IDE, NULL, NULL, NULL, NULL, {{0x00,0x00,0x00}, {0x00,0x00,0x00}}, ON_BOARD, 0, 0 },
-	{PCI_VENDOR_ID_CMD, PCI_DEVICE_ID_CMD_640, NULL, NULL, IDE_IGNORE, NULL, {{0x00,0x00,0x00}, {0x00,0x00,0x00}}, ON_BOARD, 0, 0 },
+	{PCI_VENDOR_ID_CMD, PCI_DEVICE_ID_CMD_640, NULL, NULL, ATA_PCI_IGNORE, NULL, {{0x00,0x00,0x00}, {0x00,0x00,0x00}}, ON_BOARD, 0, 0 },
 	{PCI_VENDOR_ID_NS, PCI_DEVICE_ID_NS_87410, NULL, NULL, NULL, NULL, {{0x43,0x08,0x08}, {0x47,0x08,0x08}}, ON_BOARD, 0, 0 },
 	{PCI_VENDOR_ID_HINT, PCI_DEVICE_ID_HINT, NULL, NULL, NULL, NULL, {{0x00,0x00,0x00}, {0x00,0x00,0x00}}, ON_BOARD, 0, 0 },
 	{PCI_VENDOR_ID_HOLTEK, PCI_DEVICE_ID_HOLTEK_6565, NULL, NULL, NULL, NULL, {{0x00,0x00,0x00}, {0x00,0x00,0x00}}, ON_BOARD, 0, 0 },
@@ -314,7 +313,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, IDE_NO_DRIVER, 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, NULL, 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 }};
 
 /*
@@ -683,11 +682,6 @@
 		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;
@@ -883,11 +877,11 @@
  * This finds all PCI IDE controllers and calls appropriate initialization
  * functions for them.
  */
-static void __init ide_scan_pcidev(struct pci_dev *dev)
+static void __init scan_pcidev(struct pci_dev *dev)
 {
 	unsigned short vendor;
 	unsigned short device;
-	ide_pci_device_t	*d;
+	ide_pci_device_t *d;
 
 	vendor = dev->vendor;
 	device = dev->device;
@@ -898,7 +892,7 @@
 	while (d->vendor && !(d->vendor == vendor && d->device == device))
 		++d;
 
-	if (d->init_hwif == IDE_IGNORE)
+	if (d->init_hwif == ATA_PCI_IGNORE)
 		printk("%s: has been ignored by PCI bus scan\n", dev->name);
 	else if ((d->vendor == PCI_VENDOR_ID_OPTI && d->device == PCI_DEVICE_ID_OPTI_82C558) && !(PCI_FUNC(dev->devfn) & 1))
 		return;
@@ -927,12 +921,10 @@
 	struct pci_dev *dev;
 
 	if (!scan_direction) {
-		pci_for_each_dev(dev) {
-			ide_scan_pcidev(dev);
-		}
+		pci_for_each_dev(dev)
+			scan_pcidev(dev);
 	} else {
-		pci_for_each_dev_reverse(dev) {
-			ide_scan_pcidev(dev);
-		}
+		pci_for_each_dev_reverse(dev)
+			scan_pcidev(dev);
 	}
 }
diff -urN linux-2.5.6/drivers/ide/ide-probe.c linux/drivers/ide/ide-probe.c
--- linux-2.5.6/drivers/ide/ide-probe.c	Fri Mar  8 03:18:03 2002
+++ linux/drivers/ide/ide-probe.c	Fri Mar  8 10:49:13 2002
@@ -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. */
diff -urN linux-2.5.6/drivers/ide/ide.c linux/drivers/ide/ide.c
--- linux-2.5.6/drivers/ide/ide.c	Fri Mar  8 03:18:29 2002
+++ linux/drivers/ide/ide.c	Fri Mar  8 10:49:13 2002
@@ -445,7 +445,7 @@
 /*
  * Do not even *think* about calling this!
  */
-static void init_hwif_data (unsigned int index)
+static void init_hwif_data(ide_hwif_t *hwif, int index)
 {
 	static const byte ide_major[] = {
 		IDE0_MAJOR, IDE1_MAJOR, IDE2_MAJOR, IDE3_MAJOR, IDE4_MAJOR,
@@ -454,7 +454,6 @@
 
 	unsigned int unit;
 	hw_regs_t hw;
-	ide_hwif_t *hwif = &ide_hwifs[index];
 
 	/* bulk initialize hwif & drive info with zeros */
 	memset(hwif, 0, sizeof(ide_hwif_t));
@@ -507,7 +506,7 @@
 #define MAGIC_COOKIE 0x12345678
 static void __init init_ide_data (void)
 {
-	unsigned int index;
+	unsigned int h;
 	static unsigned long magic_cookie = MAGIC_COOKIE;
 
 	if (magic_cookie != MAGIC_COOKIE)
@@ -515,8 +514,8 @@
 	magic_cookie = 0;
 
 	/* Initialize all interface structures */
-	for (index = 0; index < MAX_HWIFS; ++index)
-		init_hwif_data(index);
+	for (h = 0; h < MAX_HWIFS; ++h)
+		init_hwif_data(&ide_hwifs[h], h);
 
 	/* Add default hw interfaces */
 	ide_init_default_hwifs();
@@ -1629,7 +1628,7 @@
  * But note that it can also be invoked as a result of a "sleep" operation
  * triggered by the mod_timer() call in ide_do_request.
  */
-void ide_timer_expiry (unsigned long data)
+void ide_timer_expiry(unsigned long data)
 {
 	ide_hwgroup_t	*hwgroup = (ide_hwgroup_t *) data;
 	ide_handler_t	*handler;
@@ -1667,7 +1666,7 @@
 			if ((expiry = hwgroup->expiry) != NULL) {
 				/* continue */
 				if ((wait = expiry(drive)) != 0) {
-					/* reset timer */
+					/* reengage timer */
 					hwgroup->timer.expires  = jiffies + wait;
 					add_timer(&hwgroup->timer);
 					spin_unlock_irqrestore(&ide_lock, flags);
@@ -1869,13 +1868,13 @@
  */
 ide_drive_t *get_info_ptr (kdev_t i_rdev)
 {
-	int		major = major(i_rdev);
-	unsigned int	h;
+	unsigned int major = major(i_rdev);
+	int h;
 
 	for (h = 0; h < MAX_HWIFS; ++h) {
 		ide_hwif_t  *hwif = &ide_hwifs[h];
 		if (hwif->present && major == hwif->major) {
-			unsigned unit = DEVICE_NR(i_rdev);
+			int unit = DEVICE_NR(i_rdev);
 			if (unit < MAX_DRIVES) {
 				ide_drive_t *drive = &hwif->drives[unit];
 				if (drive->present)
@@ -2012,13 +2011,13 @@
 {
 	ide_hwif_t *hwif;
 	ide_drive_t *drive;
-	int index;
-	int unit;
+	int h;
 
-	for (index = 0; index < MAX_HWIFS; ++index) {
-		hwif = &ide_hwifs[index];
+	for (h = 0; h < MAX_HWIFS; ++h) {
+		int unit;
+		hwif = &ide_hwifs[h];
 		for (unit = 0; unit < MAX_DRIVES; ++unit) {
-			drive = &ide_hwifs[index].drives[unit];
+			drive = &ide_hwifs[h].drives[unit];
 			if (drive->revalidate) {
 				drive->revalidate = 0;
 				if (!initializing)
@@ -2164,22 +2163,19 @@
 #endif
 }
 
-void ide_unregister (unsigned int index)
+void ide_unregister(ide_hwif_t *hwif)
 {
 	struct gendisk *gd;
 	ide_drive_t *drive, *d;
-	ide_hwif_t *hwif, *g;
+	ide_hwif_t *g;
 	ide_hwgroup_t *hwgroup;
 	int irq_count = 0, unit, i;
 	unsigned long flags;
 	unsigned int p, minor;
 	ide_hwif_t old_hwif;
 
-	if (index >= MAX_HWIFS)
-		return;
 	save_flags(flags);	/* all CPUs */
 	cli();			/* all CPUs */
-	hwif = &ide_hwifs[index];
 	if (!hwif->present)
 		goto abort;
 	put_device(&hwif->device);
@@ -2202,7 +2198,7 @@
 	/*
 	 * All clear?  Then blow away the buffer cache
 	 */
-	sti();
+	spin_lock_irqsave(&ide_lock, flags);
 	for (unit = 0; unit < MAX_DRIVES; ++unit) {
 		drive = &hwif->drives[unit];
 		if (!drive->present)
@@ -2214,11 +2210,13 @@
 				invalidate_device(devp, 0);
 			}
 		}
+
+	}
+
 #ifdef CONFIG_PROC_FS
-		destroy_proc_ide_drives(hwif);
+	destroy_proc_ide_drives(hwif);
 #endif
-	}
-	cli();
+	spin_unlock_irqrestore(&ide_lock, flags);
 	hwgroup = hwif->hwgroup;
 
 	/*
@@ -2271,11 +2269,8 @@
 		hwgroup->hwif = HWIF(hwgroup->drive);
 
 #if defined(CONFIG_BLK_DEV_IDEDMA) && !defined(CONFIG_DMA_NONPCI)
-	if (hwif->dma_base) {
-		(void) ide_release_dma(hwif);
-		hwif->dma_base = 0;
-	}
-#endif /* (CONFIG_BLK_DEV_IDEDMA) && !(CONFIG_DMA_NONPCI) */
+	ide_release_dma(hwif);
+#endif
 
 	/*
 	 * Remove us from the kernel's knowledge
@@ -2297,8 +2292,14 @@
 		kfree(gd);
 		hwif->gd = NULL;
 	}
+
+	/*
+	 * Reinitialize the hwif handler, but preserve any special methods for
+	 * it.
+	 */
+
 	old_hwif		= *hwif;
-	init_hwif_data(index);	/* restore hwif data to pristine status */
+	init_hwif_data(hwif, hwif->index);
 	hwif->hwgroup		= old_hwif.hwgroup;
 	hwif->tuneproc		= old_hwif.tuneproc;
 	hwif->speedproc		= old_hwif.speedproc;
@@ -2390,12 +2391,11 @@
 				goto found;
 		}
 		for (index = 0; index < MAX_HWIFS; index++)
-			ide_unregister(index);
+			ide_unregister(&ide_hwifs[index]);
 	} while (retry--);
 	return -1;
 found:
-	if (hwif->present)
-		ide_unregister(index);
+	ide_unregister(hwif);
 	if (hwif->present)
 		return -1;
 	memcpy(&hwif->hw, hw, sizeof(*hw));
@@ -2756,21 +2756,6 @@
 				return -EACCES;
 			return ide_task_ioctl(drive, inode, file, cmd, arg);
 
-		case HDIO_SCAN_HWIF:
-		{
-			int args[3];
-			if (!capable(CAP_SYS_ADMIN)) return -EACCES;
-			if (copy_from_user(args, (void *)arg, 3 * sizeof(int)))
-				return -EFAULT;
-			if (ide_register(args[0], args[1], args[2]) == -1)
-				return -EIO;
-			return 0;
-		}
-	        case HDIO_UNREGISTER_HWIF:
-			if (!capable(CAP_SYS_ADMIN)) return -EACCES;
-			/* (arg > MAX_HWIFS) checked in function */
-			ide_unregister(arg);
-			return 0;
 		case HDIO_SET_NICE:
 			if (!capable(CAP_SYS_ADMIN)) return -EACCES;
 			if (arg != (arg & ((1 << IDE_NICE_DSC_OVERLAP) | (1 << IDE_NICE_1))))
@@ -3479,6 +3464,7 @@
 	revalidate:		ide_revalidate_disk
 }};
 
+EXPORT_SYMBOL(ide_fops);
 EXPORT_SYMBOL(ide_hwifs);
 EXPORT_SYMBOL(ide_spin_wait_hwgroup);
 EXPORT_SYMBOL(revalidate_drives);
@@ -3490,7 +3476,6 @@
 
 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);
@@ -3584,7 +3569,7 @@
  */
 static int __init ata_module_init(void)
 {
-	int i;
+	int h;
 
 	printk(KERN_INFO "Uniform Multi-Platform E-IDE driver ver.:" VERSION "\n");
 
@@ -3714,8 +3699,8 @@
 
 	initializing = 0;
 
-	for (i = 0; i < MAX_HWIFS; ++i) {
-		ide_hwif_t  *hwif = &ide_hwifs[i];
+	for (h = 0; h < MAX_HWIFS; ++h) {
+		ide_hwif_t  *hwif = &ide_hwifs[h];
 		if (hwif->present)
 			ide_geninit(hwif);
 	}
@@ -3750,21 +3735,17 @@
 
 static void __exit cleanup_ata (void)
 {
-	int index;
+	int h;
 
 	unregister_reboot_notifier(&ide_notifier);
-	for (index = 0; index < MAX_HWIFS; ++index) {
-		ide_unregister(index);
-# if defined(CONFIG_BLK_DEV_IDEDMA) && !defined(CONFIG_DMA_NONPCI)
-		if (ide_hwifs[index].dma_base)
-			ide_release_dma(&ide_hwifs[index]);
-# endif /* (CONFIG_BLK_DEV_IDEDMA) && !(CONFIG_DMA_NONPCI) */
+	for (h = 0; h < MAX_HWIFS; ++h) {
+		ide_unregister(&ide_hwifs[h]);
 	}
 
 # ifdef CONFIG_PROC_FS
 	proc_ide_destroy();
 # endif
-	devfs_unregister (ide_devfs_handle);
+	devfs_unregister(ide_devfs_handle);
 }
 
 module_init(init_ata);
diff -urN linux-2.5.6/drivers/ide/sis5513.c linux/drivers/ide/sis5513.c
--- linux-2.5.6/drivers/ide/sis5513.c	Fri Mar  8 03:18:25 2002
+++ linux/drivers/ide/sis5513.c	Fri Mar  8 10:49:13 2002
@@ -1,11 +1,35 @@
 /*
- * linux/drivers/ide/sis5513.c		Version 0.11	June 9, 2000
+ * linux/drivers/ide/sis5513.c		Version 0.13	March 4, 2002
  *
  * Copyright (C) 1999-2000	Andre Hedrick <andre@linux-ide.org>
+ * Copyright (C) 2002		Lionel Bouton <Lionel.Bouton@inet6.fr>, Maintainer
  * May be copied or modified under the terms of the GNU General Public License
  *
- * Thanks to SIS Taiwan for direct support and hardware.
- * Tested and designed on the SiS620/5513 chipset.
+*/
+
+/* Thanks :
+ * For direct support and hardware : SiS Taiwan.
+ * For ATA100 support advice       : Daniela Engert.
+ * For checking code correctness, providing patches :
+ * John Fremlin, Manfred Spraul
+ */
+
+/*
+ * Original tests and design on the SiS620/5513 chipset.
+ * ATA100 tests and design on the SiS735/5513 chipset.
+ * ATA16/33 design from specs
+ */
+
+/*
+ * TODO:
+ *	- Get ridden of SisHostChipInfo[] completness dependancy.
+ *	- Get ATA-133 datasheets, implement ATA-133 init code.
+ *	- Are there pre-ATA_16 SiS chips ? -> tune init code for them
+ *	  or remove ATA_00 define
+ *	- More checks in the config registers (force values instead of
+ *	  relying on the BIOS setting them correctly).
+ *	- Further optimisations ?
+ *	  . for example ATA66+ regs 0x48 & 0x4A
  */
 
 #include <linux/config.h>
@@ -28,88 +52,184 @@
 
 #include "ide_modes.h"
 
+// #define DEBUG
+/* if BROKEN_LEVEL is defined it limits the DMA mode
+   at boot time to its value */
+// #define BROKEN_LEVEL XFER_SW_DMA_0
 #define DISPLAY_SIS_TIMINGS
-#define SIS5513_DEBUG_DRIVE_INFO	0
 
-static struct pci_dev *host_dev = NULL;
+/* Miscellaneaous flags */
+#define SIS5513_LATENCY		0x01
+/* ATA transfer mode capabilities */
+#define ATA_00		0x00
+#define ATA_16		0x01
+#define ATA_33		0x02
+#define ATA_66		0x03
+#define ATA_100a	0x04
+#define ATA_100		0x05
+#define ATA_133		0x06
+
+static unsigned char dma_capability = 0x00;
 
-#define SIS5513_FLAG_ATA_00		0x00000000
-#define SIS5513_FLAG_ATA_16		0x00000001
-#define SIS5513_FLAG_ATA_33		0x00000002
-#define SIS5513_FLAG_ATA_66		0x00000004
-#define SIS5513_FLAG_LATENCY		0x00000010
 
+/*
+ * Debug code: following IDE config registers' changes
+ */
+#ifdef DEBUG
+/* Copy of IDE Config registers 0x00 -> 0x58
+   Fewer might be used depending on the actual chipset */
+static unsigned char ide_regs_copy[] = {
+	0x0, 0x0, 0x0, 0x0,
+	0x0, 0x0, 0x0, 0x0,
+	0x0, 0x0, 0x0, 0x0,
+	0x0, 0x0, 0x0, 0x0,
+	0x0, 0x0, 0x0, 0x0,
+	0x0, 0x0, 0x0, 0x0,
+	0x0, 0x0, 0x0, 0x0,
+	0x0, 0x0, 0x0, 0x0,
+	0x0, 0x0, 0x0, 0x0,
+	0x0, 0x0, 0x0, 0x0,
+	0x0, 0x0, 0x0, 0x0,
+	0x0, 0x0, 0x0, 0x0,
+	0x0, 0x0, 0x0, 0x0,
+	0x0, 0x0, 0x0, 0x0,
+	0x0, 0x0, 0x0, 0x0,
+	0x0, 0x0, 0x0, 0x0,
+	0x0, 0x0, 0x0, 0x0,
+	0x0, 0x0, 0x0, 0x0,
+	0x0, 0x0, 0x0, 0x0,
+	0x0, 0x0, 0x0, 0x0,
+	0x0, 0x0, 0x0, 0x0,
+	0x0, 0x0, 0x0, 0x0
+};
+
+static byte sis5513_max_config_register(void) {
+	switch(dma_capability) {
+		case ATA_00:
+		case ATA_16:	return 0x4f;
+		case ATA_33:	return 0x52;
+		case ATA_66:
+		case ATA_100a:
+		case ATA_100:
+		case ATA_133:
+		default:	return 0x57;
+	}
+}
+
+/* Read config registers, print differences from previous read */
+static void sis5513_load_verify_registers(struct pci_dev* dev, char* info) {
+	int i;
+	byte reg_val;
+	byte changed=0;
+	byte max = sis5513_max_config_register();
+
+	printk("SIS5513: %s, changed registers:\n", info);
+	for(i=0; i<=max; i++) {
+		pci_read_config_byte(dev, i, &reg_val);
+		if (reg_val != ide_regs_copy[i]) {
+			printk("%0#x: %0#x -> %0#x\n",
+			       i, ide_regs_copy[i], reg_val);
+			ide_regs_copy[i]=reg_val;
+			changed=1;
+		}
+	}
+
+	if (!changed) {
+		printk("none\n");
+	}
+}
+
+/* Load config registers, no printing */
+static void sis5513_load_registers(struct pci_dev* dev) {
+	int i;
+	byte max = sis5513_max_config_register();
+
+	for(i=0; i<=max; i++) {
+		pci_read_config_byte(dev, i, &(ide_regs_copy[i]));
+	}
+}
+
+/* Print a register */
+static void sis5513_print_register(int reg) {
+	printk(" %0#x:%0#x", reg, ide_regs_copy[reg]);
+}
+
+/* Print valuable registers */
+static void sis5513_print_registers(struct pci_dev* dev, char* marker) {
+	int i;
+	byte max = sis5513_max_config_register();
+
+	sis5513_load_registers(dev);
+	printk("SIS5513 %s\n", marker);
+	printk("SIS5513 dump:");
+	for(i=0x00; i<0x40; i++) {
+		if ((i % 0x10)==0) printk("\n             ");
+		sis5513_print_register(i);
+	}
+	for(; i<49; i++) {
+		sis5513_print_register(i);
+	}
+	printk("\n             ");
+
+	for(; i<=max; i++) {
+		sis5513_print_register(i);
+	}
+	printk("\n");
+}
+#endif
+
+
+/*
+ * Devices supported
+ */
 static const struct {
 	const char *name;
 	unsigned short host_id;
-	unsigned int flags;
+	unsigned char dma_capability;
+	unsigned char flags;
 } SiSHostChipInfo[] = {
-	{ "SiS530",	PCI_DEVICE_ID_SI_530,	SIS5513_FLAG_ATA_66, },
-	{ "SiS540",	PCI_DEVICE_ID_SI_540,	SIS5513_FLAG_ATA_66, },
-	{ "SiS620",	PCI_DEVICE_ID_SI_620,	SIS5513_FLAG_ATA_66|SIS5513_FLAG_LATENCY, },
-	{ "SiS630",	PCI_DEVICE_ID_SI_630,	SIS5513_FLAG_ATA_66|SIS5513_FLAG_LATENCY, },
-	{ "SiS635",	PCI_DEVICE_ID_SI_635,	SIS5513_FLAG_ATA_66|SIS5513_FLAG_LATENCY, },
-	{ "SiS640",	PCI_DEVICE_ID_SI_640,	SIS5513_FLAG_ATA_66|SIS5513_FLAG_LATENCY, },
-	{ "SiS645",	PCI_DEVICE_ID_SI_645,	SIS5513_FLAG_ATA_66|SIS5513_FLAG_LATENCY, },
-	{ "SiS650",	PCI_DEVICE_ID_SI_650,	SIS5513_FLAG_ATA_66|SIS5513_FLAG_LATENCY, },
-	{ "SiS730",	PCI_DEVICE_ID_SI_730,	SIS5513_FLAG_ATA_66|SIS5513_FLAG_LATENCY, },
-	{ "SiS735",	PCI_DEVICE_ID_SI_735,	SIS5513_FLAG_ATA_66|SIS5513_FLAG_LATENCY, },
-	{ "SiS740",	PCI_DEVICE_ID_SI_740,	SIS5513_FLAG_ATA_66|SIS5513_FLAG_LATENCY, },
-	{ "SiS745",	PCI_DEVICE_ID_SI_745,	SIS5513_FLAG_ATA_66|SIS5513_FLAG_LATENCY, },
-	{ "SiS750",	PCI_DEVICE_ID_SI_750,	SIS5513_FLAG_ATA_66|SIS5513_FLAG_LATENCY, },
-	{ "SiS5591",	PCI_DEVICE_ID_SI_5591,	SIS5513_FLAG_ATA_33, },
-	{ "SiS5597",	PCI_DEVICE_ID_SI_5597,	SIS5513_FLAG_ATA_33, },
-	{ "SiS5600",	PCI_DEVICE_ID_SI_5600,	SIS5513_FLAG_ATA_33, },
-	{ "SiS5511",	PCI_DEVICE_ID_SI_5511,	SIS5513_FLAG_ATA_16, },
-};
-
-#if 0
-
-static struct _pio_mode_mapping {
-	byte data_active;
-	byte recovery;
-	byte pio_mode;
-} pio_mode_mapping[] = {
-	{ 8, 12, 0 },
-	{ 6,  7, 1 },
-	{ 4,  4, 2 },
-	{ 3,  3, 3 },
-	{ 3,  1, 4 }
+	{ "SiS750",	PCI_DEVICE_ID_SI_750,	ATA_100,	SIS5513_LATENCY },
+	{ "SiS745",	PCI_DEVICE_ID_SI_745,	ATA_100,	SIS5513_LATENCY },
+	{ "SiS740",	PCI_DEVICE_ID_SI_740,	ATA_100,	SIS5513_LATENCY },
+	{ "SiS735",	PCI_DEVICE_ID_SI_735,	ATA_100,	SIS5513_LATENCY },
+	{ "SiS730",	PCI_DEVICE_ID_SI_730,	ATA_100a,	SIS5513_LATENCY },
+	{ "SiS650",	PCI_DEVICE_ID_SI_650,	ATA_100,	SIS5513_LATENCY },
+	{ "SiS645",	PCI_DEVICE_ID_SI_645,	ATA_100,	SIS5513_LATENCY },
+	{ "SiS635",	PCI_DEVICE_ID_SI_635,	ATA_100,	SIS5513_LATENCY },
+	{ "SiS640",	PCI_DEVICE_ID_SI_640,	ATA_66,		SIS5513_LATENCY },
+	{ "SiS630",	PCI_DEVICE_ID_SI_630,	ATA_66,		SIS5513_LATENCY },
+	{ "SiS620",	PCI_DEVICE_ID_SI_620,	ATA_66,		SIS5513_LATENCY },
+	{ "SiS540",	PCI_DEVICE_ID_SI_540,	ATA_66,		0},
+	{ "SiS530",	PCI_DEVICE_ID_SI_530,	ATA_66,		0},
+	{ "SiS5600",	PCI_DEVICE_ID_SI_5600,	ATA_33,		0},
+	{ "SiS5598",	PCI_DEVICE_ID_SI_5598,	ATA_33,		0},
+	{ "SiS5597",	PCI_DEVICE_ID_SI_5597,	ATA_33,		0},
+	{ "SiS5591",	PCI_DEVICE_ID_SI_5591,	ATA_33,		0},
+	{ "SiS5513",	PCI_DEVICE_ID_SI_5513,	ATA_16,		0},
+	{ "SiS5511",	PCI_DEVICE_ID_SI_5511,	ATA_16,		0},
 };
 
-static struct _dma_mode_mapping {
-	byte data_active;
-	byte recovery;
-	byte dma_mode;
-} dma_mode_mapping[] = {
-	{ 8, 8, 0 },
-	{ 3, 2, 1 },
-	{ 3, 1, 2 }
+/* Cycle time bits and values vary accross chip dma capabilities
+   These three arrays hold the register layout and the values to set.
+   Indexed by dma_capability and (dma_mode - XFER_UDMA_0) */
+static byte cycle_time_offset[] = {0,0,5,4,4,0,0};
+static byte cycle_time_range[] = {0,0,2,3,3,4,4};
+static byte cycle_time_value[][XFER_UDMA_5 - XFER_UDMA_0 + 1] = {
+	{0,0,0,0,0,0}, /* no udma */
+	{0,0,0,0,0,0}, /* no udma */
+	{3,2,1,0,0,0},
+	{7,5,3,2,1,0},
+	{7,5,3,2,1,0},
+	{11,7,5,4,2,1},
+	{0,0,0,0,0,0} /* not yet known, ask SiS */
 };
 
-static struct _udma_mode_mapping {
-	byte cycle_time;
-	char * udma_mode;
-} udma_mode_mapping[] = {
-	{ 8, "Mode 0" },
-	{ 6, "Mode 1" },
-	{ 4, "Mode 2" }, 
-	{ 3, "Mode 3" },
-	{ 2, "Mode 4" },
-	{ 0, "Mode 5" }
-};
+static struct pci_dev *host_dev = NULL;
 
-static __inline__ char * find_udma_mode (byte cycle_time)
-{
-	int n;
-	
-	for (n = 0; n <= 4; n++)
-		if (udma_mode_mapping[n].cycle_time <= cycle_time)
-			return udma_mode_mapping[n].udma_mode;
-	return udma_mode_mapping[4].udma_mode;
-}
-#endif
 
+/*
+ * Printing configuration
+ */
 #if defined(DISPLAY_SIS_TIMINGS) && defined(CONFIG_PROC_FS)
 #include <linux/stat.h>
 #include <linux/proc_fs.h>
@@ -118,12 +238,12 @@
 extern int (*sis_display_info)(char *, char **, off_t, int); /* ide-proc.c */
 static struct pci_dev *bmide_dev;
 
-static char *cable_type[] = {
+static char* cable_type[] = {
 	"80 pins",
 	"40 pins"
 };
 
-static char *recovery_time [] ={
+static char* recovery_time[] ={
 	"12 PCICLK", "1 PCICLK",
 	"2 PCICLK", "3 PCICLK",
 	"4 PCICLK", "5 PCICLCK",
@@ -134,101 +254,184 @@
 	"15 PCICLK", "15 PCICLK"
 };
 
-static char * cycle_time [] = {
-	"2 CLK", "2 CLK",
-	"3 CLK", "4 CLK",
-	"5 CLK", "6 CLK",
-	"7 CLK", "8 CLK"
-};
-
-static char * active_time [] = {
+static char* active_time[] = {
 	"8 PCICLK", "1 PCICLCK",
-	"2 PCICLK", "2 PCICLK",
+	"2 PCICLK", "3 PCICLK",
 	"4 PCICLK", "5 PCICLK",
 	"6 PCICLK", "12 PCICLK"
 };
 
+static char* cycle_time[] = {
+	"Reserved", "2 CLK",
+	"3 CLK", "4 CLK",
+	"5 CLK", "6 CLK",
+	"7 CLK", "8 CLK",
+	"9 CLK", "10 CLK",
+	"11 CLK", "12 CLK",
+	"Reserved", "Reserved",
+	"Reserved", "Reserved"
+};
+
+/* Generic add master or slave info function */
+static char* get_drives_info (char *buffer, byte pos)
+{
+	byte reg00, reg01, reg10, reg11; /* timing registers */
+	char* p = buffer;
+
+/* Postwrite/Prefetch */
+	pci_read_config_byte(bmide_dev, 0x4b, &reg00);
+	p += sprintf(p, "Drive %d:        Postwrite %s \t \t Postwrite %s\n",
+		     pos, (reg00 & (0x10 << pos)) ? "Enabled" : "Disabled",
+		     (reg00 & (0x40 << pos)) ? "Enabled" : "Disabled");
+	p += sprintf(p, "                Prefetch  %s \t \t Prefetch  %s\n",
+		     (reg00 & (0x01 << pos)) ? "Enabled" : "Disabled",
+		     (reg00 & (0x04 << pos)) ? "Enabled" : "Disabled");
+
+	pci_read_config_byte(bmide_dev, 0x40+2*pos, &reg00);
+	pci_read_config_byte(bmide_dev, 0x41+2*pos, &reg01);
+	pci_read_config_byte(bmide_dev, 0x44+2*pos, &reg10);
+	pci_read_config_byte(bmide_dev, 0x45+2*pos, &reg11);
+
+/* UDMA */
+	if (dma_capability >= ATA_33) {
+		p += sprintf(p, "                UDMA %s \t \t \t UDMA %s\n",
+			     (reg01 & 0x80)  ? "Enabled" : "Disabled",
+			     (reg11 & 0x80) ? "Enabled" : "Disabled");
+
+		p += sprintf(p, "                UDMA Cycle Time    ");
+		switch(dma_capability) {
+			case ATA_33:	p += sprintf(p, cycle_time[(reg01 & 0x60) >> 5]); break;
+			case ATA_66:
+			case ATA_100a:	p += sprintf(p, cycle_time[(reg01 & 0x70) >> 4]); break;
+			case ATA_100:	p += sprintf(p, cycle_time[reg01 & 0x0F]); break;
+			case ATA_133:
+			default:	p += sprintf(p, "133+ ?"); break;
+		}
+		p += sprintf(p, " \t UDMA Cycle Time    ");
+		switch(dma_capability) {
+			case ATA_33:	p += sprintf(p, cycle_time[(reg11 & 0x60) >> 5]); break;
+			case ATA_66:
+			case ATA_100a:	p += sprintf(p, cycle_time[(reg11 & 0x70) >> 4]); break;
+			case ATA_100:	p += sprintf(p, cycle_time[reg11 & 0x0F]); break;
+			case ATA_133:
+			default:	p += sprintf(p, "133+ ?"); break;
+		}
+		p += sprintf(p, "\n");
+	}
+
+/* Data Active */
+	p += sprintf(p, "                Data Active Time   ");
+	switch(dma_capability) {
+		case ATA_00:
+		case ATA_16: /* confirmed */
+		case ATA_33:
+		case ATA_66:
+		case ATA_100a: p += sprintf(p, active_time[reg01 & 0x07]); break;
+		case ATA_100: p += sprintf(p, active_time[(reg00 & 0x70) >> 4]); break;
+		case ATA_133:
+		default: p += sprintf(p, "133+ ?"); break;
+	}
+	p += sprintf(p, " \t Data Active Time   ");
+	switch(dma_capability) {
+		case ATA_00:
+		case ATA_16:
+		case ATA_33:
+		case ATA_66:
+		case ATA_100a: p += sprintf(p, active_time[reg11 & 0x07]); break;
+		case ATA_100: p += sprintf(p, active_time[(reg10 & 0x70) >> 4]); break;
+		case ATA_133:
+		default: p += sprintf(p, "133+ ?"); break;
+	}
+	p += sprintf(p, "\n");
+
+/* Data Recovery */
+	/* warning: may need (reg&0x07) for pre ATA66 chips */
+	p += sprintf(p, "                Data Recovery Time %s \t Data Recovery Time %s\n",
+		     recovery_time[reg00 & 0x0f], recovery_time[reg10 & 0x0f]);
+
+	return p;
+}
+
+static char* get_masters_info(char* buffer)
+{
+	return get_drives_info(buffer, 0);
+}
+
+static char* get_slaves_info(char* buffer)
+{
+	return get_drives_info(buffer, 1);
+}
+
+/* Main get_info, called on /proc/ide/sis reads */
 static int sis_get_info (char *buffer, char **addr, off_t offset, int count)
 {
-	int rc;
 	char *p = buffer;
-	byte reg,reg1;
+	byte reg;
 	u16 reg2, reg3;
 
+	p += sprintf(p, "\nSiS 5513 ");
+	switch(dma_capability) {
+		case ATA_00: p += sprintf(p, "Unknown???"); break;
+		case ATA_16: p += sprintf(p, "DMA 16"); break;
+		case ATA_33: p += sprintf(p, "Ultra 33"); break;
+		case ATA_66: p += sprintf(p, "Ultra 66"); break;
+		case ATA_100a:
+		case ATA_100: p += sprintf(p, "Ultra 100"); break;
+		case ATA_133:
+		default: p+= sprintf(p, "Ultra 133+"); break;
+	}
+	p += sprintf(p, " chipset\n");
 	p += sprintf(p, "--------------- Primary Channel ---------------- Secondary Channel -------------\n");
-	rc = pci_read_config_byte(bmide_dev, 0x4a, &reg);
-	p += sprintf(p, "Channel Status: %s \t \t \t \t %s \n",
-		     (reg & 0x02) ? "On" : "Off",
-		     (reg & 0x04) ? "On" : "Off");
-		     
-	rc = pci_read_config_byte(bmide_dev, 0x09, &reg);
+
+/* Status */
+	pci_read_config_byte(bmide_dev, 0x4a, &reg);
+	p += sprintf(p, "Channel Status: ");
+	if (dma_capability < ATA_66) {
+		p += sprintf(p, "%s \t \t \t \t %s\n",
+			     (reg & 0x04) ? "On" : "Off",
+			     (reg & 0x02) ? "On" : "Off");
+	} else {
+		p += sprintf(p, "%s \t \t \t \t %s \n",
+			     (reg & 0x02) ? "On" : "Off",
+			     (reg & 0x04) ? "On" : "Off");
+	}
+
+/* Operation Mode */
+	pci_read_config_byte(bmide_dev, 0x09, &reg);
 	p += sprintf(p, "Operation Mode: %s \t \t \t %s \n",
 		     (reg & 0x01) ? "Native" : "Compatible",
 		     (reg & 0x04) ? "Native" : "Compatible");
-		     	     
-	rc = pci_read_config_byte(bmide_dev, 0x48, &reg);
-	p += sprintf(p, "Cable Type:     %s \t \t \t %s\n",
-		     (reg & 0x10) ? cable_type[1] : cable_type[0],
-		     (reg & 0x20) ? cable_type[1] : cable_type[0]);
-		     
-	rc = pci_read_config_word(bmide_dev, 0x4c, &reg2);
-	rc = pci_read_config_word(bmide_dev, 0x4e, &reg3);
-	p += sprintf(p, "Prefetch Count: %d \t \t \t \t %d\n",
-		     reg2, reg3);
-
-	rc = pci_read_config_byte(bmide_dev, 0x4b, &reg);	     
-	p += sprintf(p, "Drive 0:        Postwrite %s \t \t Postwrite %s\n",
-		     (reg & 0x10) ? "Enabled" : "Disabled",
-		     (reg & 0x40) ? "Enabled" : "Disabled");
-	p += sprintf(p, "                Prefetch  %s \t \t Prefetch  %s\n",
-		     (reg & 0x01) ? "Enabled" : "Disabled",
-		     (reg & 0x04) ? "Enabled" : "Disabled");
-		          
-	rc = pci_read_config_byte(bmide_dev, 0x41, &reg);
-	rc = pci_read_config_byte(bmide_dev, 0x45, &reg1);
-	p += sprintf(p, "                UDMA %s \t \t \t UDMA %s\n",
-		     (reg & 0x80)  ? "Enabled" : "Disabled",
-		     (reg1 & 0x80) ? "Enabled" : "Disabled");
-	p += sprintf(p, "                UDMA Cycle Time    %s \t UDMA Cycle Time    %s\n",
-		     cycle_time[(reg & 0x70) >> 4], cycle_time[(reg1 & 0x70) >> 4]);
-	p += sprintf(p, "                Data Active Time   %s \t Data Active Time   %s\n",
-		     active_time[(reg & 0x07)], active_time[(reg1 &0x07)] ); 
-
-	rc = pci_read_config_byte(bmide_dev, 0x40, &reg);
-	rc = pci_read_config_byte(bmide_dev, 0x44, &reg1);
-	p += sprintf(p, "                Data Recovery Time %s \t Data Recovery Time %s\n",
-		     recovery_time[(reg & 0x0f)], recovery_time[(reg1 & 0x0f)]);
 
+/* 80-pin cable ? */
+	if (dma_capability > ATA_33) {
+		pci_read_config_byte(bmide_dev, 0x48, &reg);
+		p += sprintf(p, "Cable Type:     %s \t \t \t %s\n",
+			     (reg & 0x10) ? cable_type[1] : cable_type[0],
+			     (reg & 0x20) ? cable_type[1] : cable_type[0]);
+	}
 
-	rc = pci_read_config_byte(bmide_dev, 0x4b, &reg);	     
-	p += sprintf(p, "Drive 1:        Postwrite %s \t \t Postwrite %s\n",
-		     (reg & 0x20) ? "Enabled" : "Disabled",
-		     (reg & 0x80) ? "Enabled" : "Disabled");
-	p += sprintf(p, "                Prefetch  %s \t \t Prefetch  %s\n",
-		     (reg & 0x02) ? "Enabled" : "Disabled",
-		     (reg & 0x08) ? "Enabled" : "Disabled");
+/* Prefetch Count */
+	pci_read_config_word(bmide_dev, 0x4c, &reg2);
+	pci_read_config_word(bmide_dev, 0x4e, &reg3);
+	p += sprintf(p, "Prefetch Count: %d \t \t \t \t %d\n",
+		     reg2, reg3);
 
-	rc = pci_read_config_byte(bmide_dev, 0x43, &reg);
-	rc = pci_read_config_byte(bmide_dev, 0x47, &reg1);
-	p += sprintf(p, "                UDMA %s \t \t \t UDMA %s\n",
-		     (reg & 0x80)  ? "Enabled" : "Disabled",
-		     (reg1 & 0x80) ? "Enabled" : "Disabled");
-	p += sprintf(p, "                UDMA Cycle Time    %s \t UDMA Cycle Time    %s\n",
-		     cycle_time[(reg & 0x70) >> 4], cycle_time[(reg1 & 0x70) >> 4]);
-	p += sprintf(p, "                Data Active Time   %s \t Data Active Time   %s\n",
-		     active_time[(reg & 0x07)], active_time[(reg1 &0x07)] ); 
+	p = get_masters_info(p);
+	p = get_slaves_info(p);
 
-	rc = pci_read_config_byte(bmide_dev, 0x42, &reg);
-	rc = pci_read_config_byte(bmide_dev, 0x46, &reg1);
-	p += sprintf(p, "                Data Recovery Time %s \t Data Recovery Time %s\n",
-		     recovery_time[(reg & 0x0f)], recovery_time[(reg1 & 0x0f)]);
 	return p-buffer;
 }
 #endif /* defined(DISPLAY_SIS_TIMINGS) && defined(CONFIG_PROC_FS) */
 
+
 byte sis_proc = 0;
 extern char *ide_xfer_verbose (byte xfer_rate);
 
+
+/*
+ * Configuration functions
+ */
+/* Enables per-drive prefetch and postwrite */
 static void config_drive_art_rwp (ide_drive_t *drive)
 {
 	ide_hwif_t *hwif	= HWIF(drive);
@@ -237,14 +440,24 @@
 	byte reg4bh		= 0;
 	byte rw_prefetch	= (0x11 << drive->dn);
 
-	pci_read_config_byte(dev, 0x4b, &reg4bh);
+#ifdef DEBUG
+	printk("SIS5513: config_drive_art_rwp, drive %d\n", drive->dn);
+	sis5513_load_verify_registers(dev, "config_drive_art_rwp start");
+#endif
+
 	if (drive->type != ATA_DISK)
 		return;
-	
+	pci_read_config_byte(dev, 0x4b, &reg4bh);
+
 	if ((reg4bh & rw_prefetch) != rw_prefetch)
 		pci_write_config_byte(dev, 0x4b, reg4bh|rw_prefetch);
+#ifdef DEBUG
+	sis5513_load_verify_registers(dev, "config_drive_art_rwp end");
+#endif
 }
 
+
+/* Set per-drive active and recovery time */
 static void config_art_rwp_pio (ide_drive_t *drive, byte pio)
 {
 	ide_hwif_t *hwif	= HWIF(drive);
@@ -255,6 +468,10 @@
 	unsigned short eide_pio_timing[6] = {600, 390, 240, 180, 120, 90};
 	unsigned short xfer_pio = drive->id->eide_pio_modes;
 
+#ifdef DEBUG
+	sis5513_load_verify_registers(dev, "config_drive_art_rwp_pio start");
+#endif
+
 	config_drive_art_rwp(drive);
 	pio = ide_get_best_pio_mode(drive, 255, pio, NULL);
 
@@ -263,8 +480,8 @@
 
 	if (drive->id->eide_pio_iordy > 0) {
 		for (xfer_pio = 5;
-			xfer_pio>0 &&
-			drive->id->eide_pio_iordy>eide_pio_timing[xfer_pio];
+			(xfer_pio > 0) &&
+			(drive->id->eide_pio_iordy > eide_pio_timing[xfer_pio]);
 			xfer_pio--);
 	} else {
 		xfer_pio = (drive->id->eide_pio_modes & 4) ? 0x05 :
@@ -274,14 +491,10 @@
 
 	timing = (xfer_pio >= pio) ? xfer_pio : pio;
 
-/*
- *               Mode 0       Mode 1     Mode 2     Mode 3     Mode 4
- * Active time    8T (240ns)  6T (180ns) 4T (120ns) 3T  (90ns) 3T  (90ns)
- * 0x41 2:0 bits  000          110        100        011        011
- * Recovery time 12T (360ns)  7T (210ns) 4T (120ns) 3T  (90ns) 1T  (30ns)
- * 0x40 3:0 bits 0000         0111       0100       0011       0001
- * Cycle time    20T (600ns) 13T (390ns) 8T (240ns) 6T (180ns) 4T (120ns)
- */
+#ifdef DEBUG
+	printk("SIS5513: config_drive_art_rwp_pio, drive %d, pio %d, timing %d\n",
+	       drive->dn, pio, timing);
+#endif
 
 	switch(drive->dn) {
 		case 0:		drive_pci = 0x40; break;
@@ -291,31 +504,43 @@
 		default:	return;
 	}
 
-	pci_read_config_byte(dev, drive_pci, &test1);
-	pci_read_config_byte(dev, drive_pci|0x01, &test2);
-
-	/*
-	 * Do a blanket clear of active and recovery timings.
-	 */
-
-	test1 &= ~0x07;
-	test2 &= ~0x0F;
-
-	switch(timing) {
-		case 4:		test1 |= 0x01; test2 |= 0x03; break;
-		case 3:		test1 |= 0x03; test2 |= 0x03; break;
-		case 2:		test1 |= 0x04; test2 |= 0x04; break;
-		case 1:		test1 |= 0x07; test2 |= 0x06; break;
-		default:	break;
+	/* register layout changed with newer ATA100 chips */
+	if (dma_capability < ATA_100) {
+		pci_read_config_byte(dev, drive_pci, &test1);
+		pci_read_config_byte(dev, drive_pci+1, &test2);
+
+		/* Clear active and recovery timings */
+		test1 &= ~0x0F;
+		test2 &= ~0x07;
+
+		switch(timing) {
+			case 4:		test1 |= 0x01; test2 |= 0x03; break;
+			case 3:		test1 |= 0x03; test2 |= 0x03; break;
+			case 2:		test1 |= 0x04; test2 |= 0x04; break;
+			case 1:		test1 |= 0x07; test2 |= 0x06; break;
+			default:	break;
+		}
+		pci_write_config_byte(dev, drive_pci, test1);
+		pci_write_config_byte(dev, drive_pci+1, test2);
+	} else {
+		switch(timing) { /*   active  recovery
+					  v     v */
+			case 4:		test1 = 0x30|0x01; break;
+			case 3:		test1 = 0x30|0x03; break;
+			case 2:		test1 = 0x40|0x04; break;
+			case 1:		test1 = 0x60|0x07; break;
+			default:	break;
+		}
+		pci_write_config_byte(dev, drive_pci, test1);
 	}
 
-	pci_write_config_byte(dev, drive_pci, test1);
-	pci_write_config_byte(dev, drive_pci|0x01, test2);
+#ifdef DEBUG
+	sis5513_load_verify_registers(dev, "config_drive_art_rwp_pio start");
+#endif
 }
 
 static int config_chipset_for_pio (ide_drive_t *drive, byte pio)
 {
-	int err;
 	byte speed;
 
 	switch(pio) {
@@ -328,8 +553,7 @@
 
 	config_art_rwp_pio(drive, pio);
 	drive->current_speed = speed;
-	err = ide_config_drive_speed(drive, speed);
-	return err;
+	return ide_config_drive_speed(drive, speed);
 }
 
 static int sis5513_tune_chipset (ide_drive_t *drive, byte speed)
@@ -337,82 +561,73 @@
 	ide_hwif_t *hwif	= HWIF(drive);
 	struct pci_dev *dev	= hwif->pci_dev;
 
-	byte			drive_pci, test1, test2;
-	byte			unmask, four_two, mask = 0;
-
-	if (host_dev) {
-		switch(host_dev->device) {
-			case PCI_DEVICE_ID_SI_530:
-			case PCI_DEVICE_ID_SI_540:
-			case PCI_DEVICE_ID_SI_620:
-			case PCI_DEVICE_ID_SI_630:
-			case PCI_DEVICE_ID_SI_635:
-			case PCI_DEVICE_ID_SI_640:
-			case PCI_DEVICE_ID_SI_645:
-			case PCI_DEVICE_ID_SI_650:
-			case PCI_DEVICE_ID_SI_730:
-			case PCI_DEVICE_ID_SI_735:
-			case PCI_DEVICE_ID_SI_740:
-			case PCI_DEVICE_ID_SI_745:
-			case PCI_DEVICE_ID_SI_750:
-				unmask   = 0xF0;
-				four_two = 0x01;
-				break;
-			default:
-				unmask   = 0xE0;
-				four_two = 0x00;
-				break;
-		}
-	} else {
-		unmask   = 0xE0;
-		four_two = 0x00;
-	}
+	byte			drive_pci, reg;
 
+#ifdef DEBUG
+	sis5513_load_verify_registers(dev, "sis5513_tune_chipset start");
+	printk("SIS5513: sis5513_tune_chipset, drive %d, speed %d\n",
+	       drive->dn, speed);
+#endif
 	switch(drive->dn) {
-		case 0:		drive_pci = 0x40;break;
-		case 1:		drive_pci = 0x42;break;
-		case 2:		drive_pci = 0x44;break;
-		case 3:		drive_pci = 0x46;break;
+		case 0:		drive_pci = 0x40; break;
+		case 1:		drive_pci = 0x42; break;
+		case 2:		drive_pci = 0x44; break;
+		case 3:		drive_pci = 0x46; break;
 		default:	return ide_dma_off;
 	}
 
-	pci_read_config_byte(dev, drive_pci, &test1);
-	pci_read_config_byte(dev, drive_pci|0x01, &test2);
+#ifdef BROKEN_LEVEL
+#ifdef DEBUG
+	printk("SIS5513: BROKEN_LEVEL activated, speed=%d -> speed=%d\n", speed, BROKEN_LEVEL);
+#endif
+	if (speed > BROKEN_LEVEL) speed = BROKEN_LEVEL;
+#endif
 
-	if ((speed <= XFER_MW_DMA_2) && (test2 & 0x80)) {
-		pci_write_config_byte(dev, drive_pci|0x01, test2 & ~0x80);
-		pci_read_config_byte(dev, drive_pci|0x01, &test2);
-	} else {
-		pci_write_config_byte(dev, drive_pci|0x01, test2 & ~unmask);
+	pci_read_config_byte(dev, drive_pci+1, &reg);
+	/* Disable UDMA bit for non UDMA modes on UDMA chips */
+	if ((speed < XFER_UDMA_0) && (dma_capability > ATA_16)) {
+		reg &= 0x7F;
+		pci_write_config_byte(dev, drive_pci+1, reg);
 	}
 
+	/* Config chip for mode */
 	switch(speed) {
 #ifdef CONFIG_BLK_DEV_IDEDMA
-		case XFER_UDMA_5: mask = 0x80; break;
-		case XFER_UDMA_4: mask = 0x90; break;
-		case XFER_UDMA_3: mask = 0xA0; break;
-		case XFER_UDMA_2: mask = (four_two) ? 0xB0 : 0xA0; break;
-		case XFER_UDMA_1: mask = (four_two) ? 0xD0 : 0xC0; break;
-		case XFER_UDMA_0: mask = unmask; break;
+		case XFER_UDMA_5:
+		case XFER_UDMA_4:
+		case XFER_UDMA_3:
+		case XFER_UDMA_2:
+		case XFER_UDMA_1:
+		case XFER_UDMA_0:
+			/* Force the UDMA bit on if we want to use UDMA */
+			reg |= 0x80;
+			/* clean reg cycle time bits */
+			reg &= ~((0xFF >> (8 - cycle_time_range[dma_capability]))
+				 << cycle_time_offset[dma_capability]);
+			/* set reg cycle time bits */
+			reg |= cycle_time_value[dma_capability-ATA_00][speed-XFER_UDMA_0]
+				<< cycle_time_offset[dma_capability];
+			pci_write_config_byte(dev, drive_pci+1, reg);
+			break;
 		case XFER_MW_DMA_2:
 		case XFER_MW_DMA_1:
 		case XFER_MW_DMA_0:
 		case XFER_SW_DMA_2:
 		case XFER_SW_DMA_1:
-		case XFER_SW_DMA_0: break;
+		case XFER_SW_DMA_0:
+			break;
 #endif /* CONFIG_BLK_DEV_IDEDMA */
 		case XFER_PIO_4: return((int) config_chipset_for_pio(drive, 4));
 		case XFER_PIO_3: return((int) config_chipset_for_pio(drive, 3));
 		case XFER_PIO_2: return((int) config_chipset_for_pio(drive, 2));
 		case XFER_PIO_1: return((int) config_chipset_for_pio(drive, 1));
 		case XFER_PIO_0:
-		default:	 return((int) config_chipset_for_pio(drive, 0));
+		default:	 return((int) config_chipset_for_pio(drive, 0));	
 	}
-
-	if (speed > XFER_MW_DMA_2)
-		pci_write_config_byte(dev, drive_pci|0x01, test2|mask);
-
 	drive->current_speed = speed;
+#ifdef DEBUG
+	sis5513_load_verify_registers(dev, "sis5513_tune_chipset end");
+#endif
 	return ((int) ide_config_drive_speed(drive, speed));
 }
 
@@ -430,47 +645,27 @@
 	struct hd_driveid *id	= drive->id;
 	ide_hwif_t *hwif	= HWIF(drive);
 
-	byte			four_two = 0, speed = 0;
-	int			err;
+	byte			speed = 0;
 
 	byte unit		= (drive->select.b.unit & 0x01);
 	byte udma_66		= eighty_ninty_three(drive);
-	byte ultra_100		= 0;
 
-	if (host_dev) {
-		switch(host_dev->device) {
-			case PCI_DEVICE_ID_SI_635:
-			case PCI_DEVICE_ID_SI_640:
-			case PCI_DEVICE_ID_SI_645:
-			case PCI_DEVICE_ID_SI_650:
-			case PCI_DEVICE_ID_SI_730:
-			case PCI_DEVICE_ID_SI_735:
-			case PCI_DEVICE_ID_SI_740:
-			case PCI_DEVICE_ID_SI_745:
-			case PCI_DEVICE_ID_SI_750:
-				ultra_100 = 1;
-			case PCI_DEVICE_ID_SI_530:
-			case PCI_DEVICE_ID_SI_540:
-			case PCI_DEVICE_ID_SI_620:
-			case PCI_DEVICE_ID_SI_630:
-				four_two = 0x01;
-				break;
-			default:
-				four_two = 0x00; break;
-		}
-	}
+#ifdef DEBUG
+	printk("SIS5513: config_chipset_for_dma, drive %d, ultra %d\n",
+	       drive->dn, ultra);
+#endif
 
-	if ((id->dma_ultra & 0x0020) && (ultra) && (udma_66) && (four_two) && (ultra_100))
+	if ((id->dma_ultra & 0x0020) && ultra && udma_66 && (dma_capability >= ATA_100a))
 		speed = XFER_UDMA_5;
-	else if ((id->dma_ultra & 0x0010) && (ultra) && (udma_66) && (four_two))
+	else if ((id->dma_ultra & 0x0010) && ultra && udma_66 && (dma_capability >= ATA_66))
 		speed = XFER_UDMA_4;
-	else if ((id->dma_ultra & 0x0008) && (ultra) && (udma_66) && (four_two))
+	else if ((id->dma_ultra & 0x0008) && ultra && udma_66 && (dma_capability >= ATA_66))
 		speed = XFER_UDMA_3;
-	else if ((id->dma_ultra & 0x0004) && (ultra))
+	else if ((id->dma_ultra & 0x0004) && ultra && (dma_capability >= ATA_33))
 		speed = XFER_UDMA_2;
-	else if ((id->dma_ultra & 0x0002) && (ultra))
+	else if ((id->dma_ultra & 0x0002) && ultra && (dma_capability >= ATA_33))
 		speed = XFER_UDMA_1;
-	else if ((id->dma_ultra & 0x0001) && (ultra))
+	else if ((id->dma_ultra & 0x0001) && ultra && (dma_capability >= ATA_33))
 		speed = XFER_UDMA_0;
 	else if (id->dma_mword & 0x0004)
 		speed = XFER_MW_DMA_2;
@@ -489,11 +684,7 @@
 
 	outb(inb(hwif->dma_base+2)|(1<<(5+unit)), hwif->dma_base+2);
 
-	err = sis5513_tune_chipset(drive, speed);
-
-#if SIS5513_DEBUG_DRIVE_INFO
-	printk("%s: %s drive%d\n", drive->name, ide_xfer_verbose(speed), drive->dn);
-#endif /* SIS5513_DEBUG_DRIVE_INFO */
+	sis5513_tune_chipset(drive, speed);
 
 	return ((int)	((id->dma_ultra >> 11) & 7) ? ide_dma_on :
 			((id->dma_ultra >> 8) & 7) ? ide_dma_on :
@@ -550,9 +741,7 @@
 	return HWIF(drive)->dmaproc(dma_func, drive);
 }
 
-/*
- * sis5513_dmaproc() initiates/aborts (U)DMA read/write operations on a drive.
- */
+/* initiates/aborts (U)DMA read/write operations on a drive. */
 int sis5513_dmaproc (ide_dma_action_t func, ide_drive_t *drive)
 {
 	switch (func) {
@@ -567,15 +756,18 @@
 }
 #endif /* CONFIG_BLK_DEV_IDEDMA */
 
+/* Chip detection and general config */
 unsigned int __init pci_init_sis5513(struct pci_dev *dev)
 {
 	struct pci_dev *host;
 	int i = 0;
-	byte latency = 0;
 
-	pci_read_config_byte(dev, PCI_LATENCY_TIMER, &latency);
+#ifdef DEBUG
+	sis5513_print_registers(dev, "pci_init_sis5513 start");
+#endif
 
-	for (i = 0; i < ARRAY_SIZE (SiSHostChipInfo) && !host_dev; i++) {
+	/* Find the chip */
+	for (i = 0; i < ARRAY_SIZE(SiSHostChipInfo) && !host_dev; i++) {
 		host = pci_find_device (PCI_VENDOR_ID_SI,
 					SiSHostChipInfo[i].host_id,
 					NULL);
@@ -583,30 +775,67 @@
 			continue;
 
 		host_dev = host;
+		dma_capability = SiSHostChipInfo[i].dma_capability;
 		printk(SiSHostChipInfo[i].name);
 		printk("\n");
-		if (SiSHostChipInfo[i].flags & SIS5513_FLAG_LATENCY) {
-			if (latency != 0x10)
-				pci_write_config_byte(dev, PCI_LATENCY_TIMER, 0x10);
+
+		if (SiSHostChipInfo[i].flags & SIS5513_LATENCY) {
+			byte latency = (dma_capability == ATA_100)? 0x80 : 0x10; /* Lacking specs */
+			pci_write_config_byte(dev, PCI_LATENCY_TIMER, latency);
 		}
 	}
 
+	/* Make general config ops here
+	   1/ tell IDE channels to operate in Compabitility mode only
+	   2/ tell old chips to allow per drive IDE timings */
 	if (host_dev) {
-		byte reg52h = 0;
-
-		pci_read_config_byte(dev, 0x52, &reg52h);
-		if (!(reg52h & 0x04)) {
-			/* set IDE controller to operate in Compabitility mode only */
-			pci_write_config_byte(dev, 0x52, reg52h|0x04);
+		byte reg;
+		switch(dma_capability) {
+			case ATA_133:
+			case ATA_100:
+				/* Set compatibility bit */
+				pci_read_config_byte(dev, 0x49, &reg);
+				if (!(reg & 0x01)) {
+					pci_write_config_byte(dev, 0x49, reg|0x01);
+				}
+				break;
+			case ATA_100a:
+			case ATA_66:
+				/* On ATA_66 chips the bit was elsewhere */
+				pci_read_config_byte(dev, 0x52, &reg);
+				if (!(reg & 0x04)) {
+					pci_write_config_byte(dev, 0x52, reg|0x04);
+				}
+				break;
+			case ATA_33:
+				/* On ATA_33 we didn't have a single bit to set */
+				pci_read_config_byte(dev, 0x09, &reg);
+				if ((reg & 0x0f) != 0x00) {
+					pci_write_config_byte(dev, 0x09, reg&0xf0);
+				}
+			case ATA_16:
+				/* force per drive recovery and active timings
+				   needed on ATA_33 and below chips */
+				pci_read_config_byte(dev, 0x52, &reg);
+				if (!(reg & 0x08)) {
+					pci_write_config_byte(dev, 0x52, reg|0x08);
+				}
+				break;
+			case ATA_00:
+			default: break;
 		}
+
 #if defined(DISPLAY_SIS_TIMINGS) && defined(CONFIG_PROC_FS)
 		if (!sis_proc) {
 			sis_proc = 1;
 			bmide_dev = dev;
 			sis_display_info = &sis_get_info;
 		}
-#endif /* defined(DISPLAY_SIS_TIMINGS) && defined(CONFIG_PROC_FS) */
+#endif
 	}
+#ifdef DEBUG
+	sis5513_load_verify_registers(dev, "pci_init_sis5513 end");
+#endif
 	return 0;
 }
 
@@ -616,27 +845,10 @@
 	byte mask = hwif->channel ? 0x20 : 0x10;
 	pci_read_config_byte(hwif->pci_dev, 0x48, &reg48h);
 
-	if (host_dev) {
-		switch(host_dev->device) {
-			case PCI_DEVICE_ID_SI_530:
-			case PCI_DEVICE_ID_SI_540:
-			case PCI_DEVICE_ID_SI_620:
-			case PCI_DEVICE_ID_SI_630:
-			case PCI_DEVICE_ID_SI_635:
-			case PCI_DEVICE_ID_SI_640:
-			case PCI_DEVICE_ID_SI_645:
-			case PCI_DEVICE_ID_SI_650:
-			case PCI_DEVICE_ID_SI_730:
-			case PCI_DEVICE_ID_SI_735:
-			case PCI_DEVICE_ID_SI_740:
-			case PCI_DEVICE_ID_SI_745:
-			case PCI_DEVICE_ID_SI_750:
-				ata66 = (reg48h & mask) ? 0 : 1;
-			default:
-				break;
-		}
+	if (dma_capability >= ATA_66) {
+		ata66 = (reg48h & mask) ? 0 : 1;
 	}
-        return (ata66);
+        return ata66;
 }
 
 void __init ide_init_sis5513 (ide_hwif_t *hwif)
@@ -651,34 +863,17 @@
 		return;
 
 	if (host_dev) {
-		switch(host_dev->device) {
 #ifdef CONFIG_BLK_DEV_IDEDMA
-			case PCI_DEVICE_ID_SI_530:
-			case PCI_DEVICE_ID_SI_540:
-			case PCI_DEVICE_ID_SI_620:
-			case PCI_DEVICE_ID_SI_630:
-			case PCI_DEVICE_ID_SI_635:
-			case PCI_DEVICE_ID_SI_640:
-			case PCI_DEVICE_ID_SI_645:
-			case PCI_DEVICE_ID_SI_650:
-			case PCI_DEVICE_ID_SI_730:
-			case PCI_DEVICE_ID_SI_735:
-			case PCI_DEVICE_ID_SI_740:
-			case PCI_DEVICE_ID_SI_745:
-			case PCI_DEVICE_ID_SI_750:
-			case PCI_DEVICE_ID_SI_5600:
-			case PCI_DEVICE_ID_SI_5597:
-			case PCI_DEVICE_ID_SI_5591:
-				if (!noautodma)
-					hwif->autodma = 1;
-				hwif->highmem = 1;
-				hwif->dmaproc = &sis5513_dmaproc;
-				break;
-#endif /* CONFIG_BLK_DEV_IDEDMA */
-			default:
-				hwif->autodma = 0;
-				break;
+		if (dma_capability > ATA_16) {
+			hwif->autodma = noautodma ? 0 : 1;
+			hwif->highmem = 1;
+			hwif->dmaproc = &sis5513_dmaproc;
+		} else {
+#endif
+			hwif->autodma = 0;
+#ifdef CONFIG_BLK_DEV_IDEDMA
 		}
+#endif
 	}
 	return;
 }
diff -urN linux-2.5.6/include/linux/hdreg.h linux/include/linux/hdreg.h
--- linux-2.5.6/include/linux/hdreg.h	Fri Mar  8 03:18:29 2002
+++ linux/include/linux/hdreg.h	Fri Mar  8 10:49:13 2002
@@ -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 */
diff -urN linux-2.5.6/include/linux/ide.h linux/include/linux/ide.h
--- linux-2.5.6/include/linux/ide.h	Fri Mar  8 03:18:16 2002
+++ linux/include/linux/ide.h	Fri Mar  8 10:53:21 2002
@@ -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
  */

Re: [PATCH] 2.5.6 IDE 18

[Richard Gooch]

Martin Dalecki writes:
> - 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: rgooch@atnf.csiro.au
Current:   rgooch@ras.ucalgary.ca

Re: [PATCH] 2.5.6 IDE 18

[Martin Dalecki]

Richard Gooch wrote:
> Martin Dalecki writes:
> 
>>- 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.

Re: Flash Back -- kernel 2.1.111

[Vojtech Pavlik]

On Sat, Feb 23, 2002 at 08:42:37PM -0800, Andre Hedrick wrote:

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

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

-- 
Vojtech Pavlik
SuSE Labs

Re: Flash Back -- kernel 2.1.111

[Martin Dalecki]

Andre Hedrick wrote:
> 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.

[PATCH] 2.5.6 IDE 19

[Martin Dalecki]

[-- Attachment #1: Type: text/plain, Size: 1588 bytes --]


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

[-- Attachment #2: ide-clean-19.diff --]
[-- Type: text/plain, Size: 11685 bytes --]

diff -urN linux-2.5.6/drivers/ide/ide-disk.c linux/drivers/ide/ide-disk.c
--- linux-2.5.6/drivers/ide/ide-disk.c	Fri Mar  8 03:18:04 2002
+++ linux/drivers/ide/ide-disk.c	Mon Mar 11 12:50:44 2002
@@ -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);
 	}
 
diff -urN linux-2.5.6/drivers/ide/ide-pci.c linux/drivers/ide/ide-pci.c
--- linux-2.5.6/drivers/ide/ide-pci.c	Mon Mar 11 13:05:59 2002
+++ linux/drivers/ide/ide-pci.c	Mon Mar 11 02:44:27 2002
@@ -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);
+		}
 	}
 }
diff -urN linux-2.5.6/drivers/ide/ide-probe.c linux/drivers/ide/ide-probe.c
--- linux-2.5.6/drivers/ide/ide-probe.c	Mon Mar 11 13:05:59 2002
+++ linux/drivers/ide/ide-probe.c	Mon Mar 11 02:43:32 2002
@@ -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);
 
diff -urN linux-2.5.6/drivers/ide/ide.c linux/drivers/ide/ide.c
--- linux-2.5.6/drivers/ide/ide.c	Mon Mar 11 13:05:59 2002
+++ linux/drivers/ide/ide.c	Mon Mar 11 12:56:00 2002
@@ -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 */
diff -urN linux-2.5.6/drivers/ide/via82cxxx.c linux/drivers/ide/via82cxxx.c
--- linux-2.5.6/drivers/ide/via82cxxx.c	Fri Mar  8 03:18:22 2002
+++ linux/drivers/ide/via82cxxx.c	Mon Mar 11 12:48:51 2002
@@ -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;
 	}
 
 /*
diff -urN linux-2.5.6/drivers/scsi/ide-scsi.c linux/drivers/scsi/ide-scsi.c
--- linux-2.5.6/drivers/scsi/ide-scsi.c	Fri Mar  8 03:18:06 2002
+++ linux/drivers/scsi/ide-scsi.c	Mon Mar 11 12:47:42 2002
@@ -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;
diff -urN linux-2.5.6/include/linux/ide.h linux/include/linux/ide.h
--- linux-2.5.6/include/linux/ide.h	Mon Mar 11 13:05:59 2002
+++ linux/include/linux/ide.h	Mon Mar 11 12:50:44 2002
@@ -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);
 
 /*

Re: [PATCH] 2.5.6 IDE 19

[Alan Cox]

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

> 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

Re: [PATCH] 2.5.6 IDE 19

[Martin Dalecki]

Alan Cox wrote:
>>   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. 
> 
> 
>>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.

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.

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

Re: [PATCH] 2.5.6 IDE 19

[Alan Cox]

> 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

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

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

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

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

> 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

Re: [PATCH] 2.5.6 IDE 19

[Martin Dalecki]

Alan Cox wrote:
>>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!

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

> 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)
> 
> 
>>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!

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

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

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

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

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

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

Re: [PATCH] 2.5.6 IDE 19

[Charles Cazabon]

Martin Dalecki <dalecki@evision-ventures.com> wrote:
> 
> 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
-- 
-----------------------------------------------------------------------
Charles Cazabon                            <linux@discworld.dyndns.org>
GPL'ed software available at:  http://www.qcc.sk.ca/~charlesc/software/
-----------------------------------------------------------------------

Re: [PATCH] 2.5.6 IDE 19

[Alan Cox]

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

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

> 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

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

> 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

Re: [PATCH] 2.5.6 IDE 19

[Martin Dalecki]

Alan Cox wrote:
>>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.
> 
> 
>>>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. 
> 
> 
>>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
> 
> 
>>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.
> 
> 
>>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.

> 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... ;-)

Re: [PATCH] 2.5.6 IDE 19

[Alan Cox]

> 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

Re: [PATCH] 2.5.6 IDE 19

[Andre Hedrick]

On Mon, 11 Mar 2002, Martin Dalecki wrote:

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

> >>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?
>
> > 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)
> > 
> > 
> >>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!".

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

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

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

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

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.

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

> 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

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

[Gunther Mayer]

Andre Hedrick wrote:

> On Mon, 11 Mar 2002, Martin Dalecki wrote:
>
> >
> > 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.
>

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

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

[Andre Hedrick]

Gunther,

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

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

Cheers,

Andre Hedrick
The Second Linux X-IDE guy

On Mon, 11 Mar 2002, Gunther Mayer wrote:

> Andre Hedrick wrote:
> 
> > On Mon, 11 Mar 2002, Martin Dalecki wrote:
> >
> > >
> > > 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.
> >
> 
> 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
> 
> 

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

[Gunther Mayer]

Andre Hedrick wrote:

> 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).

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

[Martin Dalecki]

Gunther Mayer wrote:

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

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

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

[Zwane Mwaikambo]

On Mon, 11 Mar 2002, Martin Dalecki wrote:

> 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

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

[Alan Cox]

> 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

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

[Alexander Viro]

On Mon, 11 Mar 2002, Alan Cox wrote:

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

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

[Andre Hedrick]

On Mon, 11 Mar 2002, Alexander Viro wrote:

> 
> 
> On Mon, 11 Mar 2002, Alan Cox wrote:
> 
> > > 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...
> 

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

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

[Alexander Viro]

On Mon, 11 Mar 2002, Andre Hedrick wrote:

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

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

[Alan Cox]

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

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

[Pavel Machek]

Hi!

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

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

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

[john slee]

On Wed, Mar 13, 2002 at 12:55:07PM +0000, Pavel Machek wrote:
> Hi!
> 
> > > 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.

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.

j.

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

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

[Erik Andersen]

On Sat Mar 16, 2002 at 04:49:17AM +1100, john slee wrote:
> 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--

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

[Andre Hedrick]

On Mon, 11 Mar 2002, Alan Cox wrote:

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

Re: [PATCH] 2.5.6 IDE 19

[Pavel Machek]

Hi!

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

Re: [PATCH] 2.5.6 IDE 19

[Barry K. Nathan]

> > 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 <barryn@pobox.com>

Re: [PATCH] 2.5.6 IDE 19

[Pavel Machek]

Hi!

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

Re: [PATCH] 2.5.6 IDE 19

[Andre Hedrick]

I am now sick of what I see and will now make a little noise!

On Mon, 11 Mar 2002, Martin Dalecki wrote:

> Alan Cox wrote:
> >>   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. 
> > 
> > 
> >>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.
> 
> 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.
> 
> > 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?

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.

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

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

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

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

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

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

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

> 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

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.

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

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

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

> 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

Re: [PATCH] 2.5.6 IDE 19

[Alan Cox]

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

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

> 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

Re: [PATCH] 2.5.6 IDE 19

[Anton Altaparmakov]

On Mon, 11 Mar 2002, Alan Cox wrote:
> > 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
-- 
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/

Re: [PATCH] 2.5.6 IDE 19

[Alan Cox]

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

Re: [PATCH] 2.5.6 IDE 19

[Vojtech Pavlik]

On Mon, Mar 11, 2002 at 07:39:06PM +0000, Alan Cox wrote:
> > 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.

-- 
Vojtech Pavlik
SuSE Labs

Re: [PATCH] 2.5.6 IDE 19

[Vojtech Pavlik]

On Mon, Mar 11, 2002 at 06:05:36PM +0000, Anton Altaparmakov wrote:
> On Mon, 11 Mar 2002, Alan Cox wrote:
> > > 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 ...

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

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

-- 
Vojtech Pavlik
SuSE Labs

Re: [PATCH] 2.5.6 IDE 19

[Joachim Breuer]

Vojtech Pavlik <vojtech@suse.cz> writes:

> On Mon, Mar 11, 2002 at 06:05:36PM +0000, Anton Altaparmakov wrote:
>> On Mon, 11 Mar 2002, Alan Cox wrote:
>> > > 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 ...
>
> [...]
>
> 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

-- 
"I use emacs, which might be thought of as a thermonuclear
 word processor."
-- Neal Stephenson, "In the beginning... was the command line"

Re: [PATCH] 2.5.6 IDE 19

[Anton Altaparmakov]

At 19:39 11/03/02, Alan Cox wrote:
> > 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


-- 
   "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/

Re: [PATCH] 2.5.6 IDE 19

[Anton Altaparmakov]

At 22:01 11/03/02, Vojtech Pavlik wrote:
>On Mon, Mar 11, 2002 at 06:05:36PM +0000, Anton Altaparmakov wrote:
> > On Mon, 11 Mar 2002, Alan Cox wrote:
> > > > 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 ...

Yes, sorry. I had a dim moment... You are of course right.

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

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


-- 
   "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/

Re: [PATCH] 2.5.6 IDE 19

[Wayne Whitney]

In mailing-lists.linux-kernel, you wrote:

> 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

Re: [PATCH] 2.5.6 IDE 19

[Andre Hedrick]

On Mon, 11 Mar 2002, Alan Cox wrote:

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

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

Re: [PATCH] 2.5.6 IDE 19

[Martin Dalecki]

Andre Hedrick wrote:
> On Mon, 11 Mar 2002, Alan Cox wrote:
> 
> 
>>>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.

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

Re: [PATCH] 2.5.6 IDE 19

[Andre Hedrick]

On Mon, 11 Mar 2002, Martin Dalecki wrote:

> Andre Hedrick wrote:
> > On Mon, 11 Mar 2002, Alan Cox wrote:
> > 
> > 
> >>>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.
> 
> 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?

Deal, will do it.

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

> 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.
*****************

http://www.t13.org/ballots/e01028r0.pdf

I do not see your name on that list for the ballot.

Cheers,

Andre Hedrick
The Second Linux X-IDE guy

Re: [PATCH] 2.5.6 IDE 19

[Martin Dalecki]

> Deal, will do it.

I don't expect anymore that you hold your word.

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

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?

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

Re: [PATCH] 2.5.6 IDE 19

[Andre Hedrick]

On Mon, 11 Mar 2002, Martin Dalecki wrote:

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

Re: [PATCH] 2.5.6 IDE 19

[Martin Dalecki]

Andre Hedrick wrote:
> On Mon, 11 Mar 2002, Martin Dalecki wrote:
> 
> 
>>>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.

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

> 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...).

Re: [PATCH] 2.5.6 IDE 19

[Andre Hedrick]

On Mon, 11 Mar 2002, Martin Dalecki wrote:
> 
> 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.

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

Re: [PATCH] 2.5.6 IDE 19

[Davide Libenzi]

On Mon, 11 Mar 2002, Andre Hedrick wrote:

> On Mon, 11 Mar 2002, Martin Dalecki wrote:
> >
> > 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.
>
> > > 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.

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

Re: [PATCH] 2.5.6 IDE 19

[Andre Hedrick]

On Mon, 11 Mar 2002, Davide Libenzi wrote:
> > 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

Re: [PATCH] 2.5.6 IDE 19

[Rik van Riel]

On Mon, 11 Mar 2002, Davide Libenzi wrote:

> 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
-- 
<insert bitkeeper endorsement here>

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

Re: [PATCH] 2.5.6 IDE 19

[Davide Libenzi]

On Mon, 11 Mar 2002, Rik van Riel wrote:

> On Mon, 11 Mar 2002, Davide Libenzi wrote:
>
> > 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

Re: [PATCH] 2.5.6 IDE 19

[David Ford]

I'll test 2.5 when buslogic gets functional :)

-d

Davide Libenzi wrote:

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

Re: [PATCH] 2.5.6 IDE 19

[Jos Hulzink]

On Mon, 11 Mar 2002, Rik van Riel wrote:
> 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

Re: [PATCH] 2.5.6 IDE 19

[Andre Hedrick]

Please drop me off the thread I am not the Maintainer for 2.5

Regards,

Andre Hedrick
Linux Disk Certification Project                Linux ATA Development

On Mon, 11 Mar 2002, Rik van Riel wrote:

> On Mon, 11 Mar 2002, Davide Libenzi wrote:
> 
> > 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
> -- 
> <insert bitkeeper endorsement here>
> 
> http://www.surriel.com/		http://distro.conectiva.com/
> 

Re: [PATCH] 2.5.6 IDE 19

[Russell King]

On Mon, Mar 11, 2002 at 08:12:26PM +0100, Martin Dalecki wrote:
> 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.

-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: [PATCH] 2.5.6 IDE 19

[Arjan van de Ven]

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

Re: [PATCH] 2.5.6 IDE 19

[Martin Dalecki]

Arjan van de Ven wrote:
>>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.)

Re: [PATCH] 2.5.6 IDE 19

[Rik van Riel]

On Mon, 11 Mar 2002, Arjan van de Ven wrote:

> > 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
-- 
<insert bitkeeper endorsement here>

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

Re: [PATCH] 2.5.6 IDE 19

[Alan Cox]

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

Re: [PATCH] 2.5.6 IDE 19

[Bill Davidsen]

On Mon, 11 Mar 2002, Martin Dalecki wrote:

> Alan Cox wrote:

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

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

>   * 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.

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.

-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: [PATCH] 2.5.6 IDE 19

[Pavel Machek]

Hi!

> > 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".

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

[PATCH] IDE 21

[Martin Dalecki]

[-- Attachment #1: Type: text/plain, Size: 2140 bytes --]

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.

[-- Attachment #2: ide-clean-21.diff.gz --]
[-- Type: application/x-gzip, Size: 26623 bytes --]

Re: [PATCH] IDE 21

[Vojtech Pavlik]

On Wed, Mar 13, 2002 at 03:14:55PM +0100, Martin Dalecki wrote:

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

-- 
Vojtech Pavlik
SuSE Labs

Re: Flash Back -- kernel 2.1.111

[Pedro M. Rodrigues]

   I checked Microsoft's proposal recently. Didn't see see anything 
devastating, could you please enlighten me on this one?


Thanks,
Pedro

On 22 Feb 2002 at 1:25, Andre Hedrick wrote:

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

Re: Flash Back -- kernel 2.1.111

[Andre Hedrick]

On Fri, 22 Feb 2002, Pedro M. Rodrigues wrote:

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


> 
> Thanks,
> Pedro
> 
> On 22 Feb 2002 at 1:25, Andre Hedrick wrote:
> 
> > 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

Re: Flash Back -- kernel 2.1.111

[Alan Cox]

> 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

Re: Flash Back -- kernel 2.1.111

[Andre Hedrick]

On Fri, 22 Feb 2002, Alan Cox wrote:

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

Re: Flash Back -- kernel 2.1.111

[David S. Miller]

   From: Andre Hedrick <andre@linuxdiskcert.org>
   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.

Re: linux-2.5.5-pre1

[Wayne.Brown]

So where is it?  I haven't been able to find it at kernel.org yet.

Re: linux-2.5.5-pre1

[Robert Love]

On Wed, 2002-02-13 at 18:20, Wayne.Brown@altec.com wrote:

> So where is it?  I haven't been able to find it at kernel.org yet.

I'll keep the list in the CC since I see this question on IRC ...

its in 
	/pub/linux/kernel/testing
not the usual
	/pub/linux/kernel/v2.5/testing

	Robert Love

Re: linux-2.5.5-pre1

[Alessandro Suardi]

Robert Love wrote:
> On Wed, 2002-02-13 at 18:20, Wayne.Brown@altec.com wrote:
> 
> 
>>So where is it?  I haven't been able to find it at kernel.org yet.
>>
> 
> I'll keep the list in the CC since I see this question on IRC ...
> 
> its in 
> 	/pub/linux/kernel/testing
> not the usual
> 	/pub/linux/kernel/v2.5/testing

More issues:

  - xconfig broken

[asuardi@dolphin linux]$ make xconfig
rm -f include/asm
( cd include ; ln -sf asm-i386 asm)
/usr/src/linux/include
make -C scripts kconfig.tk
make[1]: Entering directory `/usr/src/linux-2.5.5-pre1/scripts'
gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -c -o tkparse.o tkparse.cgcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -c -o tkcond.o tkcond.c
gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -c -o tkgen.o tkgen.c
gcc -o tkparse tkparse.o tkcond.o tkgen.o
cat header.tk >> ./kconfig.tk
./tkparse < ../arch/i386/config.in >> kconfig.tk
sound/Config.in: 22: incorrect argument
make[1]: *** [kconfig.tk] Error 1
make[1]: Leaving directory `/usr/src/linux-2.5.5-pre1/scripts'
make: *** [xconfig] Error 2



  - rtctimer.c doesn't build due to undefined rtc_task_t

gcc -D__KERNEL__ -I/usr/src/linux-2.5.5-pre1/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common -pipe -mpreferred-stack-boundary=2 -march=i686   -DKBUILD_BASENAME=rtctimer  -DEXPORT_SYMTAB -c rtctimer.c
rtctimer.c:75: parse error before "rtc_task"
rtctimer.c:75: warning: type defaults to `int' in declaration of `rtc_task'
rtctimer.c:75: warning: data definition has no type or storage class
rtctimer.c: In function `rtctimer_start':
rtctimer.c:99: `rtc_task_t' undeclared (first use in this function)
rtctimer.c:99: (Each undeclared identifier is reported only once
rtctimer.c:99: for each function it appears in.)
rtctimer.c:99: `rtc' undeclared (first use in this function)
rtctimer.c:99: invalid lvalue in assignment
rtctimer.c:101: warning: implicit declaration of function `rtc_control'
rtctimer.c: In function `rtctimer_stop':
rtctimer.c:110: `rtc_task_t' undeclared (first use in this function)
rtctimer.c:110: `rtc' undeclared (first use in this function)
rtctimer.c:110: invalid lvalue in assignment
rtctimer.c: In function `rtctimer_interrupt':
rtctimer.c:123: warning: implicit declaration of function `tasklet_hi_schedule'
rtctimer.c: In function `rtctimer_private_free':
rtctimer.c:143: `rtc_task_t' undeclared (first use in this function)
rtctimer.c:143: `rtc' undeclared (first use in this function)
rtctimer.c:143: invalid lvalue in assignment
rtctimer.c:145: warning: implicit declaration of function `rtc_unregister'
rtctimer.c: In function `rtctimer_init':
rtctimer.c:174: warning: implicit declaration of function `tasklet_init'
rtctimer.c:182: request for member `func' in something not a structure or union
rtctimer.c:183: request for member `private_data' in something not a structure or union
rtctimer.c:184: warning: implicit declaration of function `rtc_register'
rtctimer.c: At top level:
rtctimer.c:79: storage size of `rtc_tq' isn't known
make[3]: *** [rtctimer.o] Error 1
make[3]: Leaving directory `/usr/src/linux-2.5.5-pre1/sound/core'
make[2]: *** [first_rule] Error 2
make[2]: Leaving directory `/usr/src/linux-2.5.5-pre1/sound/core'
make[1]: *** [_subdir_core] Error 2
make[1]: Leaving directory `/usr/src/linux-2.5.5-pre1/sound'
make: *** [_dir_sound] Error 2



  - ramdisk broken (at least as module)

gcc -D__KERNEL__ -I/usr/src/linux-2.5.5-pre1/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common -pipe -mpreferred-stack-boundary=2 -march=i686 -DMODULE  -DKBUILD_BASENAME=rd  -c -o rd.o rd.c
rd.c: In function `rd_make_request':
rd.c:271: too many arguments to function
make[2]: *** [rd.o] Error 1
make[2]: Leaving directory `/usr/src/linux-2.5.5-pre1/drivers/block'
make[1]: *** [_modsubdir_block] Error 2
make[1]: Leaving directory `/usr/src/linux-2.5.5-pre1/drivers'
make: *** [_mod_drivers] Error 2

--alessandro

  "If your heart is a flame burning brightly
    you'll have light and you'll never be cold
   And soon you will know that you just grow / You're not growing old"
                               (Husker Du, "Flexible Flyer")

Re: linux-2.5.5-pre1

[Rob Radez]

On Wed, 13 Feb 2002 Wayne.Brown@altec.com wrote:

>
>
> So where is it?  I haven't been able to find it at kernel.org yet.

In a different (wrong?) directory: /pub/linux/kernel/testing/ instead of
/pub/linux/kernel/v2.5/testing which is also why hpa's scripts haven't
picked up on it yet.

Regards,
Rob Radez

Re: linux-2.5.5-pre1

[Martin Knoblauch]

> linux-2.5.5-pre1
> 
> From: Linus Torvalds (torvalds@transmeta.com)
> Date: Wed Feb 13 2002 - 17:38:12 EST
> 
> 
> 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.
> 

 just curious :-)) Is the x86_64 stuff based/tested on real HW,
simulators or just on the specs.

Martin
-- 
------------------------------------------------------------------
Martin Knoblauch         |    email:  Martin.Knoblauch@TeraPort.de
TeraPort GmbH            |    Phone:  +49-89-510857-309
C+ITS                    |    Fax:    +49-89-510857-111
http://www.teraport.de   |    Mobile: +49-170-4904759

Re: linux-2.5.5-pre1

[Andreas Jaeger]

Martin Knoblauch <Martin.Knoblauch@TeraPort.de> writes:

>> linux-2.5.5-pre1
>> 
>> From: Linus Torvalds (torvalds@transmeta.com)
>> Date: Wed Feb 13 2002 - 17:38:12 EST
>> 
>> 
>> 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.
>> 
>
>  just curious :-)) Is the x86_64 stuff based/tested on real HW,
> simulators or just on the specs.

The x86-64 stuff was developed and extensivly tested - and also
demonstrated at the last show cases like LinuxWorldExpo NY ;-) - using
a software simulator.  You cannot develop such a beast just with the
specs...

For more information about Linux on x86-64, check also
http://www.x86-64.org

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj