Bug 107468 - change some driver mapping
Summary: change some driver mapping
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Raw Hide
Classification: Retired
Component: hwdata
Version: 1.0
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact: David Lawrence
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-10-18 18:19 UTC by acount closed by user
Modified: 2014-03-17 02:39 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2003-11-02 20:14:57 UTC
Embargoed:

Attachments (Terms of Use)

Description acount closed by user 2003-10-18 18:19:51 UTC 
- pcitable:

 sym53c8xx -> sym53c8xx_2
 ncr53c8xx -> sym53c8xx_2

- upgradelist:

 sym53c8xx SCSI sym53c8xx_2
 ncr53c8xx SCSI sym53c8xx_2
Comment 1 Bill Nottingham 2003-10-20 04:11:31 UTC 
The drivers don't have one-to-one mappings of what IDs they handle.
Comment 2 acount closed by user 2003-10-23 02:56:40 UTC 
sym53c8xx_2 is the substitute of the old drivers (sym53c8xx and ncr53c8xx)
and it handles all these SCSI HBA:

(NCR 0x1000)

SYM53C810        0x0001
SYM53C810AP      0x0005
SYM53C815        0x0004
SYM53C820        0x0002
SYM53C825        0x0003
SYM53C860        0x0006
SYM53C875        0x000f
SYM53C875_2      0x008f
SYM53C885        0x000d
SYM53C895        0x000c
SYM53C896        0x000b
SYM53C895A       0x0012
SYM53C875A       0x0013
LSI53C1010       0x0020
LSI53C1010_2     0x0021
LSI53C1510D      0x000a
Comment 3 Bill Nottingham 2003-10-24 00:53:03 UTC 
In the case where there are multiple drivers for the same chip, we only change
the default driver to what is recommended by the on-staff kernel maintainers.

Any such change is not happening at *this* stage of Fedora Core 1.

In 2.6, the driver name is sym53c8xx. At that point we'll need a migration
entry for ncr53c8xx, but that's it.
Comment 4 acount closed by user 2003-10-24 02:28:37 UTC 
Forget FC 1, it's closed. This change is oriented to FC 2. And don't be so
optimistic, 2.6 kernel has a long path to be stable ;-).

I think sym53c8xx_2 is preferred in 2.4 over ncr53c8xx/sym53c8xx.
what do rh kernel hackers believe?

-thanks-
Comment 5 Bill Nottingham 2003-10-24 02:39:10 UTC 
Asking them.
Comment 6 Arjan van de Ven 2003-10-24 07:13:23 UTC 
we prefer the 1 version actually for the hw it supports in 2.4.
In 2.6 it's different story, so hopefully for FC2.
Note You need to log in before you can comment on or make changes to this bug.