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
============================================
<[email protected]> (02/02/10 1.248.5.1)
Import arch/ppc and include/asm-ppc changes from linuxppc_2_5 tree
<[email protected]> (02/02/10 1.263)
[PATCH] 2.5.4-pre6 apm compile fix
Make apm compile properly and without warnings.
<[email protected]> (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".
<[email protected]> (02/02/10 1.262.1.1)
Remove warning in /proc inode conversions.
<[email protected]> (02/02/10 1.262.2.1)
Clean up sparc64 build.
<[email protected]> (02/02/10 1.262.2.2)
Split protocol specific information out from struct sock.
Work done by Arnaldo Carvalho de Melo.
<[email protected]> (02/02/10 1.262.2.3)
Netfilter bugfixes from Harald and Paul Russell.
<[email protected]> (02/02/10 1.262.2.4)
Add writev support to TUN driver.
From Eddie C. Dost
<[email protected]> (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. -- [email protected]
<[email protected]> (02/02/11 1.262.3.2)
setup_str[] only used in modular builds.
<[email protected]> (02/02/11 1.262.3.3)
add more build config files to ignore list
<[email protected]> (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.
<[email protected]> (02/02/11 1.262.3.5)
Replace awful schedule_timeout polling code with
completions. Applies to 2.5.4-pre3
-- [email protected]
<[email protected]> (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
-- [email protected]
<[email protected]> (02/02/11 1.262.3.7)
Make cciss driver contribute to entropy pool.
Applies to 2.5.4-pre3
-- [email protected]
<[email protected]> (02/02/11 1.262.3.8)
change cciss driver version number. Applies to 2.5.4-pre3
-- [email protected]
<[email protected]> (02/02/11 1.262.3.9)
Small batch of IDE code cleanups from Pavel Machek
<[email protected]> (02/02/11 1.262.3.10)
thread_saved_pc fix from akpm
<[email protected]> (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.
<[email protected]> (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.
<[email protected]> (02/02/11 1.262.3.12)
bio_endio doesn't take nr_sectors argument anymore.
<[email protected]> (02/02/11 1.262.4.1)
Update Alpha UP for thread_info and scheduler changes.
<[email protected]> (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.
<[email protected]> (02/02/11 1.262.7.1)
patch from Peter Osterlund <[email protected]> to fix usb-storage debug code
compile problem.
<[email protected]> (02/02/11 1.262.7.2)
patch from David Probnell, updating the USB error-codes.txt file
<[email protected]> (02/02/11 1.262.7.3)
patch by Simon Evans <[email protected]> that adds a Konica USB webcam driver
<[email protected]> (02/02/11 1.262.7.4)
removed 'typedef' from the Digi Acceleport usb-serial driver.
<[email protected]> (02/02/11 1.262.7.5)
removed 'typedef' from the ftdi_sio usb-serial driver.
<[email protected]> (02/02/11 1.262.7.6)
removed 'typedef' from the IO Networks Edgeport usb-serial driver.
<[email protected]> (02/02/11 1.262.7.7)
removed 'typedef' from the Keyspan usb-serial drivers.
<[email protected]> (02/02/11 1.262.7.8)
removed 'typedef' from the kl5kusb105 usb-serial driver.
<[email protected]> (02/02/11 1.262.4.3)
Update Alpha SMP for the new scheduler and preempt api change.
<[email protected]> (02/02/11 1.262.5.2)
Add a couple #includes to fix the alpha build.
<[email protected]> (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 [email protected]
http://www.canb.auug.org.au/~sfr/
<[email protected]> (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
<[email protected]> (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.
<[email protected]> (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
<[email protected]> (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
<[email protected]> (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
<[email protected]> (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
<[email protected]> (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
<[email protected]> (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.
<[email protected]> (02/02/11 1.282)
[PATCH] 01-ioerrors-checks-2.diff
Make sure all reiserfs_find_entry users correctly understand IO_ERROR retval.
<[email protected]> (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.
<[email protected]> (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.
<[email protected]> (02/02/11 1.285)
[PATCH] 04-hash_autodetect_fix.diff
Correctly detect and print hash values, when manual hash detection is used.
<[email protected]> (02/02/11 1.286)
[PATCH] 05-corrupt_items_checks.diff
Do not panic when encountered item of unknown type, just print a warning.
<[email protected]> (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.
<[email protected]> (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.
<[email protected]> (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 <[email protected]>
<[email protected]> (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.
<[email protected]> (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
<[email protected]> (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
<[email protected]> (02/02/12 1.294)
Various minor documentation / comment typo fixes
for net drivers 3c509, acenic, ni52, and skfp.
Via Dave Jones.
<[email protected]> (02/02/12 1.295)
request_region cleanups from 2.4 and the kernel janitors.
Via Dave Jones.
<[email protected]> (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
<[email protected]> (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.
<[email protected]> (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.
<[email protected]> (02/02/12 1.299)
Merge cosmetic cleanup and driver version increment
for dmfe net driver from 2.4.x.
Via Dave Jones.
<[email protected]> (02/02/12 1.300)
Add new ISAPNP card id to 'ne' net driver.
Via Dave Jones.
<[email protected]> (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.
<[email protected]> (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 <[email protected]>
0.13b - call register_netdev earlier in initialization
suppress duplicate link status messages
0.15 get ppc (big endian) working
Via Dave Jones.
<[email protected]> (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.
<[email protected]> (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
<[email protected]> (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
<[email protected]> (02/02/11 1.262.2.5)
Fix recalc_sigpending handling.
<[email protected]> (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
<[email protected]> (02/02/11 1.293.1.1)
Fix up typo from Al's ext2 balloc cleanups.
<[email protected]> (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:
<[email protected]> (02/02/12 1.307)
Add new pci id to via-rhine net driver.
<[email protected]> (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 :-)
<[email protected]> (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.
<[email protected]> (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 ;-)
<[email protected]> (02/02/12 1.311)
[PATCH] BKL shifted into ->truncate()
BKL shifted into all instances of ->truncate(). Callers updated.
<[email protected]> (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.
<[email protected]> (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.
<[email protected]> (02/02/12 1.307.1.3)
Add new pci id to 8139too net driver, for Allied Telesyn cardbus cards.
Contributor: Go Taniguchi
<[email protected]> (02/02/12 1.293.3.1)
Add Macrolink board PCI ids to pci.ids and pci_ids.h.
Contributor: Ed Vance @ Macrolink
<[email protected]> (02/02/12 1.293.4.1)
optimization, cleanup: switch_to(3 parameter) => switch_to(2 parameter).
<[email protected]> (02/02/12 1.293.4.2)
move sched_find_first_bit() from mmu_context.h to bitops.h, it belongs there.
<[email protected]> (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.
<[email protected]> (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.
<[email protected]> (02/02/12 1.293.2.3)
usb hid driver:
- patch to fix bug where urbs were freed too soon.
<[email protected]> (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
<[email protected]> (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 ...'.
<[email protected]> (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.
<[email protected]> (02/02/13 1.293.4.7)
cleanups.
<[email protected]> (02/02/13 1.262.9.1)
[PATCH] ALSA patch for 2.5.4
Integrate ALSA into v2.5.4
Jaroslav
<[email protected]> (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
<[email protected]> (02/02/13 1.317)
Make Jaroslav the sound maintainer, remove Alan on his request.
<[email protected]> (02/02/13 1.318)
Include linux/compiler.h in include/asm-i386/bitops.h,
for the definition of unlikely().
<[email protected]> (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 ([email protected]).
Reviewed and tested by Michael Elizabeth Chastain ([email protected]).
Michael Elizabeth Chastain
===
<[email protected]> (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.
<[email protected]> (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.
<[email protected]> (02/02/13 1.320)
update version
<[email protected]> (02/02/13 1.321)
Avoid pci driver warnings on 64-bit hosts
<[email protected]> (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
<[email protected]> (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
<[email protected]> (02/02/13 1.324)
[PATCH] x86-64 MAINTAINERS
Add Andi Kleen as x86-64 maintainer.
<[email protected]> (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.
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.
On Wed, 2002-02-13 at 18:20, [email protected] 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
On Wed, 13 Feb 2002 [email protected] 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
Robert Love wrote:
> On Wed, 2002-02-13 at 18:20, [email protected] 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")
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
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
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
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
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
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
> linux-2.5.5-pre1
>
> From: Linus Torvalds ([email protected])
> 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: [email protected]
TeraPort GmbH | Phone: +49-89-510857-309
C+ITS | Fax: +49-89-510857-111
http://www.teraport.de | Mobile: +49-170-4904759
Martin Knoblauch <[email protected]> writes:
>> linux-2.5.5-pre1
>>
>> From: Linus Torvalds ([email protected])
>> 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 [email protected]
private [email protected]
http://www.suse.de/~aj
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);
> 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
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
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
> 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
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
--- linux/drivers/scsi/advansys.c Thu Feb 7 22:31:04 2002
+++ linux/drivers/scsi/advansys.cmin6 Thu Feb 7 23:23:59 2002
@@ -1,4 +1,4 @@
-#define ASC_VERSION "3.3GG" /* AdvanSys Driver Version */
+#define ASC_VERSION "3.3GI" /* AdvanSys Driver Version */
/*
* advansys.c - Linux Host Driver for AdvanSys SCSI Adapters
@@ -670,7 +670,7 @@
1. Return an error from narrow boards if passed a 16 byte
CDB. The wide board can already handle 16 byte CDBs.
- 3.3GG (01/02/02):
+ 3.3GI (2/07/02):
1. hacks for lk 2.5 series (D. Gilbert)
I. Known Problems/Fix List (XXX)
@@ -752,7 +752,6 @@
*/
-#error Please convert me to Documentation/DMA-mapping.txt
/*
* --- Linux Version
@@ -869,8 +868,8 @@
* will give us time to change the HW and FW to handle 64-bit
* addresses.
*/
-#define ASC_VADDR_TO_U32 virt_to_bus
-#define ASC_U32_TO_VADDR bus_to_virt
+#define ASC_VADDR_TO_U32 __pa
+#define ASC_U32_TO_VADDR __va
typedef unsigned char uchar;
@@ -2151,8 +2150,8 @@
* will give us time to change the HW and FW to handle 64-bit
* addresses.
*/
-#define ADV_VADDR_TO_U32 virt_to_bus
-#define ADV_U32_TO_VADDR bus_to_virt
+#define ADV_VADDR_TO_U32 __pa
+#define ADV_U32_TO_VADDR __va
#define AdvPortAddr ulong /* Virtual memory address size */
@@ -3614,23 +3613,6 @@
#define ASC_MIN(a, b) (((a) < (b)) ? (a) : (b))
#endif /* CONFIG_PROC_FS */
-/*
- * XXX - Release and acquire the io_request_lock. These macros are needed
- * because the 2.4 kernel SCSI mid-level driver holds the 'io_request_lock'
- * on entry to SCSI low-level drivers.
- *
- * These definitions and all code that uses code should be removed when the
- * SCSI mid-level driver no longer holds the 'io_request_lock' on entry to
- * SCSI low-level driver detect, queuecommand, and reset entrypoints.
- *
- * The interrupt flags values doesn't matter in the macros because the
- * SCSI mid-level will save and restore the flags values before and after
- * calling advansys_detect, advansys_queuecommand, and advansys_reset where
- * these macros are used. We do want interrupts enabled after the lock is
- * released so an explicit sti() is done. The driver only needs interrupts
- * disabled when it acquires the per board lock.
- */
-
/* Asc Library return codes */
#define ASC_TRUE 1
#define ASC_FALSE 0
@@ -4822,7 +4804,7 @@
boardp->id = asc_board_count - 1;
/* Initialize spinlock. */
- boardp->lock = SPIN_LOCK_UNLOCKED; /* replaced by host_lock dpg */
+ boardp->lock = SPIN_LOCK_UNLOCKED;
/*
* Handle both narrow and wide boards.
@@ -5872,7 +5854,7 @@
/* host_lock taken by mid-level prior to call but need to protect */
/* against own ISR */
- spin_lock_irqsave(boardp->lock, flags);
+ spin_lock_irqsave(&boardp->lock, flags);
/*
* Block new commands while handling a reset or abort request.
@@ -6676,7 +6658,7 @@
asc_scsi_q.q1.target_id = ASC_TID_TO_TARGET_ID(scp->target);
asc_scsi_q.q1.target_lun = scp->lun;
asc_scsi_q.q2.target_ix = ASC_TIDLUN_TO_IX(scp->target, scp->lun);
- asc_scsi_q.q1.sense_addr = cpu_to_le32(virt_to_bus(&scp->sense_buffer[0]));
+ asc_scsi_q.q1.sense_addr = cpu_to_le32(__pa(&scp->sense_buffer[0]));
asc_scsi_q.q1.sense_len = sizeof(scp->sense_buffer);
/*
@@ -6707,7 +6689,7 @@
*/
ASC_STATS(scp->host, cont_cnt);
asc_scsi_q.q1.data_addr =
- cpu_to_le32(virt_to_bus(scp->request_buffer));
+ cpu_to_le32(__pa(scp->request_buffer));
asc_scsi_q.q1.data_cnt = cpu_to_le32(scp->request_bufflen);
ASC_STATS_ADD(scp->host, cont_xfer,
ASC_CEILING(scp->request_bufflen, 512));
@@ -6751,8 +6733,7 @@
slp = (struct scatterlist *) scp->request_buffer;
for (sgcnt = 0; sgcnt < scp->use_sg; sgcnt++, slp++) {
asc_sg_head.sg_list[sgcnt].addr =
- cpu_to_le32(virt_to_bus(slp->address ?
- (unsigned char *)slp->address :
+ cpu_to_le32(__pa(
(unsigned char *)page_address(slp->page) + slp->offset));
asc_sg_head.sg_list[sgcnt].bytes = cpu_to_le32(slp->length);
ASC_STATS_ADD(scp->host, sg_xfer, ASC_CEILING(slp->length, 512));
@@ -6848,7 +6829,7 @@
scsiqp->target_id = scp->target;
scsiqp->target_lun = scp->lun;
- scsiqp->sense_addr = cpu_to_le32(virt_to_bus(&scp->sense_buffer[0]));
+ scsiqp->sense_addr = cpu_to_le32(__pa(&scp->sense_buffer[0]));
scsiqp->sense_len = sizeof(scp->sense_buffer);
/*
@@ -6857,7 +6838,7 @@
*/
scsiqp->data_cnt = cpu_to_le32(scp->request_bufflen);
scsiqp->vdata_addr = scp->request_buffer;
- scsiqp->data_addr = cpu_to_le32(virt_to_bus(scp->request_buffer));
+ scsiqp->data_addr = cpu_to_le32(__pa(scp->request_buffer));
if (scp->use_sg == 0) {
/*
@@ -6977,7 +6958,7 @@
* the allocated ADV_SG_BLOCK structure.
*/
sg_block = (ADV_SG_BLOCK *) ADV_8BALIGN(&sgblkp->sg_block);
- sg_block_paddr = virt_to_bus(sg_block);
+ sg_block_paddr = __pa(sg_block);
/*
* Check if this is the first 'adv_sgblk_t' for the request.
@@ -7011,9 +6992,8 @@
for (i = 0; i < NO_OF_SG_PER_BLOCK; i++)
{
sg_block->sg_list[i].sg_addr =
- cpu_to_le32(virt_to_bus(slp->address ?
- (unsigned char *)slp->address :
- (unsigned char *)page_address(slp->page) + slp->offset));
+ cpu_to_le32(__pa(
+ (unsigned char *)page_address(slp->page) + slp->offset));
sg_block->sg_list[i].sg_count = cpu_to_le32(slp->length);
ASC_STATS_ADD(scp->host, sg_xfer, ASC_CEILING(slp->length, 512));
@@ -9162,7 +9142,7 @@
{
ADV_PADDR paddr;
- paddr = virt_to_bus(vaddr);
+ paddr = __pa(vaddr);
ASC_DBG4(4,
"DvcGetPhyAddr: vaddr 0x%lx, lenp 0x%lx *lenp %lu, paddr 0x%lx\n",
@@ -9415,8 +9395,8 @@
printk("Scsi_Host at addr 0x%lx\n", (ulong) s);
printk(
-" next 0x%lx, extra_bytes %u, host_busy %u, host_no %d, last_reset %d,\n",
- (ulong) s->next, s->extra_bytes, s->host_busy, s->host_no,
+" next 0x%lx, host_busy %u, host_no %d, last_reset %d,\n",
+ (ulong) s->next, s->host_busy, s->host_no,
(unsigned) s->last_reset);
#if ASC_LINUX_KERNEL24
@@ -12764,7 +12744,7 @@
ASC_TID_TO_TARGET_ID(asc_dvc->cfg->chip_scsi_id));
/* Align overrun buffer on an 8 byte boundary. */
- phy_addr = virt_to_bus(asc_dvc->cfg->overrun_buf);
+ phy_addr = __pa(asc_dvc->cfg->overrun_buf);
phy_addr = cpu_to_le32((phy_addr + 7) & ~0x7);
AscMemDWordCopyPtrToLram(iop_base, ASCV_OVERRUN_PADDR_D,
(uchar *) &phy_addr, 1);
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);
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
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 */
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 @@
*
* [email protected], [email protected], [email protected],
* [email protected], [email protected], [email protected],
- * [email protected], [email protected],
+ * [email protected], [email protected],
* [email protected], [email protected],
* [email protected], [email protected], [email protected],
* [email protected], [email protected], [email protected],
@@ -596,14 +596,13 @@
{
int setup_time, active_time, recovery_time, clock_time;
byte setup_count, active_count, recovery_count, recovery_count2, cycle_count;
- int bus_speed = system_bus_clock();
if (pio_mode > 5)
pio_mode = 5;
setup_time = ide_pio_timings[pio_mode].setup_time;
active_time = ide_pio_timings[pio_mode].active_time;
recovery_time = cycle_time - (setup_time + active_time);
- clock_time = 1000 / bus_speed;
+ clock_time = 1000 / system_bus_speed;
cycle_count = (cycle_time + clock_time - 1) / clock_time;
setup_count = (setup_time + clock_time - 1) / clock_time;
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);
> @@ -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"
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
> 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
> hum, I'm not sure that removing ->driver_init is a good idea.
>
> Seems like a loss of flexibility to me, not a cleanup, and I wonder if
> you have thought through all the paths that wind up calling
> ->driver_init.
Yes I have tought it all through!
Please trust me - I eat at least myself my dog-food.
And the driver_init function is something which where currently
just the bloody module initialization function get's called
a seond time - and this is just plain wrong.
If I hadn't tought about it I wouldn't be that advantegrous.
And my testing of it did consist of the following:
1. 2 x IDE drives of one IDE port.
2. 1 x CD-RW on a second port - modularized.
3. 1 x CarBus to CF adapter.
It all worked well after the removal!
Alan Cox 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?
> 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.
> 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)
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...
> > 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
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...
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.
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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
Alan,
Please let me correct this issue as now I am going to start new driver
since this one is now beyond repair for me.
Regards,
Andre Hedrick
Linux Disk Certification Project Linux ATA Development
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 [email protected]
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
> >
>
> Alan,
>
> Please let me correct this issue as now I am going to start new driver
> since this one is now beyond repair for me.
>
> Regards,
>
> Andre Hedrick
> Linux Disk Certification Project Linux ATA Development
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
On Friday 15 February 2002 01:34, Douglas Gilbert wrote:
> "Gerold J. Wucherpfennig" <[email protected]> wrote:
> > The advansys scsi driver of linux-2.5.5-pre1 doesn't compile ...
>
> Gerold,
> Please try the attachment, tested on i386 UP + SMP.
>
> Doug Gilbert
This patch works very well for me and it's a pitty that it wasn't included
into Kernel 2.5.5-final.
I'm using advansys scsi with my P2 UP (Intel LX).
It should be included into Dave Jones tree (or is it already?),
because Linus seems to be very busy (as usual).
Gerold J. Wucherpfennig
"Gerold J. Wucherpfennig" wrote:
>
> On Friday 15 February 2002 01:34, Douglas Gilbert wrote:
> > "Gerold J. Wucherpfennig" <[email protected]> wrote:
> > > The advansys scsi driver of linux-2.5.5-pre1 doesn't compile ...
> >
> > Gerold,
> > Please try the attachment, tested on i386 UP + SMP.
> >
> > Doug Gilbert
>
> This patch works very well for me and it's a pitty that it wasn't included
> into Kernel 2.5.5-final.
>
> I'm using advansys scsi with my P2 UP (Intel LX).
>
> It should be included into Dave Jones tree (or is it already?),
The advansys patch is in patch-2.5.5-dj1 .
> because Linus seems to be very busy (as usual).
Doug Gilbert
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
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/
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
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.
Hi Martin,
ide_module_t was designed to conceptually divide the code to multiple
layers,
whether one actually uses modules or compiles all the IDE code into the
kernel,
and in the future, to alow several parallel implementations of the same
functionality
which could reside in the kernel simultaneously.
The job was not finished, but the original idea was to have:
1. Core IDE code.
2. Chipset modules.
3. Probe modules.
4. Subdriver modules.
ide_module_t was created so that the core IDE code could track all the
modules
currently available to it, and to be able to have several chipset drivers
for the same
chipset simultaneously, several probe modules simultaneously, and several
subdrivers
for the same device type (so that one could choose the one which works
best).
The last example was actually used in ide-scsi.c. The intention in
ide_module_t was
that one would be able to have, for example, ide-cdrom + ide-scsi or
ide-tape + ide-scsi
in the kernel simultaneously (either compiled in or as modules), known to
the
core IDE code, and one could then change drivers for a single drive on the
fly using
something like "cat driver_name > /proc/ide/hdx/driver".
Upon receiving such a command, the IDE core could call the cleanup code of
the driver which was originally assigned to hdx, the cleanup code would
de-attach
the driver from hdx without unloading the module and without affecting the
other drives which are currently supported by it. The core code could then
call the init code of the other driver to attach to the device.
The reason ide-probe was splitted to a different module is that in most of
the
time, one doesn't need the probe code in the kernel. It is needed during
boot, and
each time one "hot swaps" an IDE device. In addition, it could provide the
framework
for having several probe modules simultaneously, altough that never
materialized.
Cheers,
Gadi
----- Original Message -----
From: "Martin Dalecki" <[email protected]>
To: "Linus Torvalds" <[email protected]>
Cc: "Kernel Mailing List" <[email protected]>
Sent: Tuesday, February 19, 2002 1:46 PM
Subject: [PATCH] 2.5.5-pre1 IDE cleanup 9
> 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.
>
>
>
From: Andre Hedrick <[email protected]>
Date: Fri, 22 Feb 2002 01:25:36 -0800 (PST)
I refuse to fix this mess.
Andre, go take a nap or something and come back when you're not in
whining mode ok?
If you can't handle someone else doing cleanups of a subsystem you
happen to maintain, GO FIND ANOTHER PROJECT TO WORK ON.
Because nobody owns any particular piece of code in that way,
plain and simple. I used to think I could whine when people put in
cleanups of the networking behind my back, I WAS WRONG. Just like you
are wrong.
All of the cleanup changesets from Martin I saw go in were just
fine anyways.
If you can't be bothered to handle the conflicts introduced by such
cleanups, that is your problem. And finally your mouth is much larger
than the code you write. So you might want to work on that ratio a
little bit.
> 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
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.
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...)
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
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 |
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.
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 ;)
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 ;-).
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
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
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 |
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 |
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.
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 |
--
Jeff Garzik | "UNIX enhancements aren't."
Building 1024 | -- says /usr/games/fortune
MandrakeSoft |
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.
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.
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.
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.
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.
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.
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.
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
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
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
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
> 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
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 |
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
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 |
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
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 |
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
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
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
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
In article <[email protected]> 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...
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
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
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--
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--
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
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
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
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
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
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
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--
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 |
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
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--
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 |
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?
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.
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/
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
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
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 |
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 |
On Fri, 22 Feb 2002 15:16:22 +0100,
Martin Dalecki <[email protected]> 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.
Keith Owens wrote:
> On Fri, 22 Feb 2002 15:16:22 +0100,
> Martin Dalecki <[email protected]> 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.
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)
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.
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
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
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
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
> 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' | [email protected]
-----"If this message isn't misspelled, I didn't write it" -- Me -----
"Why do musicians compose symphonies and poets write poems? They do it
because life wouldn't have any meaning for them if they didn't. That's
why I draw cartoons. It's my life." -- Charles Schulz
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
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
> 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.
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.
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.
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
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' | [email protected]
-----"If this message isn't misspelled, I didn't write it" -- Me -----
"Why do musicians compose symphonies and poets write poems? They do it
because life wouldn't have any meaning for them if they didn't. That's
why I draw cartoons. It's my life." -- Charles Schulz
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?
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
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
> 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
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...)
> (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 ?
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' | [email protected]
-----"If this message isn't misspelled, I didn't write it" -- Me -----
"Why do musicians compose symphonies and poets write poems? They do it
because life wouldn't have any meaning for them if they didn't. That's
why I draw cartoons. It's my life." -- Charles Schulz
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.
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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
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 |
On Sun, 24 Feb 2002 [email protected] wrote:
> None of the chipsets that supported VLB had more than one buss. What
> I don't know is some idiot may have built a VLB-VLB bridge, but I
> doubt it.
There are PCI-VLB bridges. Though it's unlikely, it may be
possible that there are systems with multiple such bridges
around... ;)
regards,
Rik
--
"Linux holds advantages over the single-vendor commercial OS"
-- Microsoft's "Competing with Linux" document
http://www.surriel.com/ http://distro.conectiva.com/
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
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
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
On Sun, Feb 24, 2002 at 06:32:09PM -0300, Rik van Riel wrote:
> On Sun, 24 Feb 2002 [email protected] wrote:
>
> > None of the chipsets that supported VLB had more than one buss. What
> > I don't know is some idiot may have built a VLB-VLB bridge, but I
> > doubt it.
>
> There are PCI-VLB bridges. Though it's unlikely, it may be
> possible that there are systems with multiple such bridges
> around... ;)
Uhh? I thought most the PCI & VLB systems had the PCI hanging off the
VLB and not the other way around. At least those I've seen had it this
way.
--
Vojtech Pavlik
SuSE Labs
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 |
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/
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 [email protected] wrote:
> >
> > > None of the chipsets that supported VLB had more than one buss. What
> > > I don't know is some idiot may have built a VLB-VLB bridge, but I
> > > doubt it.
> >
> > There are PCI-VLB bridges. Though it's unlikely, it may be
> > possible that there are systems with multiple such bridges
> > around... ;)
>
> Uhh? I thought most the PCI & VLB systems had the PCI hanging off the
> VLB and not the other way around. At least those I've seen had it this
> way.
>
> --
> Vojtech Pavlik
> SuSE Labs
>
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
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.
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.
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
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
From: Alan Cox <[email protected]>
Date: Sun, 24 Feb 2002 21:15:06 +0000 (GMT)
its the platform specific bus code that can find the bus speed out
(if anyone)
some platforms in fact already calculate it :-)
Vojtech Pavlik 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.
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.
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
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' | [email protected]
-----"If this message isn't misspelled, I didn't write it" -- Me -----
"Why do musicians compose symphonies and poets write poems? They do it
because life wouldn't have any meaning for them if they didn't. That's
why I draw cartoons. It's my life." -- Charles Schulz
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
From: Vojtech Pavlik <[email protected]>
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?
> 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
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
On Sun, Feb 24, 2002 at 02:44:23PM -0800, David S. Miller wrote:
> From: Vojtech Pavlik <[email protected]>
> 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
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 <[email protected]>
> > 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' | [email protected]
-----"If this message isn't misspelled, I didn't write it" -- Me -----
"Why do musicians compose symphonies and poets write poems? They do it
because life wouldn't have any meaning for them if they didn't. That's
why I draw cartoons. It's my life." -- Charles Schulz
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 <[email protected]>
> > > 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
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
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
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
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
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.
> As a point of reference for removal of the pci read/write space to the
> host, I strongly suggest that be left alone. As for the removal of the
> settings file, may of the distributions use this as a means to issue
> script calls to enable and disable features w/o the use of an additional
> application like "hdparm".
You are sure the distros write to the PCI config space of the host chip
device or the IO registers at boot time????!!! In esp. since the
abolition in case did only just get introduced at 2.4.xx times???
Just show me one please!
> Vojtech Pavlik 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
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: [email protected]
-M: [email protected]
+P: Martin Dalecki
+M: [email protected]
+I: pl_PL.ISO8859-2, de_DE.ISO8859-15, (en_US.ISO8859-1)
L: [email protected]
-W: http://www.kernel.org/pub/linux/kernel/people/hedrick/
-W: http://www.linux-ide.org/
-W: http://www.linuxdiskcert.org/
-S: Maintained
+W: http://www.dalecki.de
+S: Developement
IDE/ATAPI CDROM DRIVER
P: Jens Axboe
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 <[email protected]>
#
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 <[email protected]>
- *
- * 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 <[email protected]>
+ * Copyright (C) 2002 Lionel Bouton <[email protected]>, 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, ®_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, ®00);
+ 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, ®00);
+ pci_read_config_byte(bmide_dev, 0x41+2*pos, ®01);
+ pci_read_config_byte(bmide_dev, 0x44+2*pos, ®10);
+ pci_read_config_byte(bmide_dev, 0x45+2*pos, ®11);
+
+/* 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, ®);
- 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, ®);
+
+/* Status */
+ pci_read_config_byte(bmide_dev, 0x4a, ®);
+ 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, ®);
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, ®);
- 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, ®2);
- rc = pci_read_config_word(bmide_dev, 0x4e, ®3);
- p += sprintf(p, "Prefetch Count: %d \t \t \t \t %d\n",
- reg2, reg3);
-
- rc = pci_read_config_byte(bmide_dev, 0x4b, ®);
- 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, ®);
- rc = pci_read_config_byte(bmide_dev, 0x45, ®1);
- 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, ®);
- rc = pci_read_config_byte(bmide_dev, 0x44, ®1);
- 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, ®);
+ 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, ®);
- 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, ®2);
+ pci_read_config_word(bmide_dev, 0x4e, ®3);
+ p += sprintf(p, "Prefetch Count: %d \t \t \t \t %d\n",
+ reg2, reg3);
- rc = pci_read_config_byte(bmide_dev, 0x43, ®);
- rc = pci_read_config_byte(bmide_dev, 0x47, ®1);
- 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, ®);
- rc = pci_read_config_byte(bmide_dev, 0x46, ®1);
- 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, ®4bh);
+#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, ®4bh);
+
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, ®);
+ /* 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, ®52h);
- 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, ®);
+ 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, ®);
+ 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, ®);
+ 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, ®);
+ 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, ®48h);
- 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
*/
-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
Normally the website points to a direct link where you can get the latest
IDE goodies, you might wanna change that or adjust your URL accordingly.
Regards,
Zwane
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: [email protected]
Current: [email protected]
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.
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);
/*
> 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
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 http://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.
> 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
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?
Martin Dalecki <[email protected]> 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 <[email protected]>
GPL'ed software available at: http://www.qcc.sk.ca/~charlesc/software/
-----------------------------------------------------------------------
> 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
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 http://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
> 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.
> 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
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
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/
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
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... ;-)
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
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...
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
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
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.)
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
>
>
> 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?
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).
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
> 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 ?
> 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
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...
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 ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
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...).
> 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
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
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...
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
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
> 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 ?
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
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
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...
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/
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/
> > For gods sake:
> >
> > 1. How is Win2000 going to work then?
>
> Because its standards compliant. It wasnt written by a half clued wannabe
> who has never read the manuals and can do nothing but call people who have
> a "liar". And a standards compliant implementation does all the right power
> management commands. Win 98 didnt quite get it right and you'll find one
> of the updates addresses IDE problems. Ironically fixing the same flush
> cache and shut down politely problem you plan to break in Linux
Windows 2000 doesn't even get this right 100% of the time either:
http://support.microsoft.com/default.aspx?scid=kb;EN-US;q281672
(I've seen this bug corrupt data in real life -- it's not just
theoretical. The really unfortunate part is that Win2K also forces the
write cache on, even if you try to turn it off, due to another bug.)
AFAIK a fix for this is planned for Win2K Service Pack 3, and WinXP works
properly (in this regard anyway) out-of-the-box.
-Barry K. Nathan <[email protected]>
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
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
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/
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/
> > 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
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
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
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 <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
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/
>
Vojtech Pavlik <[email protected]> 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"
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
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.
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.
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.
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.
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.
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
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 ...
>
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
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--