linux-scsi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Michael Tokarev <mjt@tls.msk.ru>
To: Sergey Vlasov <vsu@altlinux.ru>
Cc: Andi Kleen <ak@suse.de>,
	linux-scsi@vger.kernel.org,
	Luben Tuikov <luben_tuikov@adaptec.com>
Subject: Re: [PATCH] Add proper module ID tables to Adaptec aic7[9x]xx drivers
Date: Wed, 06 Oct 2004 23:47:33 +0400	[thread overview]
Message-ID: <41644BD5.7030807@tls.msk.ru> (raw)
In-Reply-To: <linux.scsi.20040621161047.GD16453@master.mivlgu.local>

[Answering to an old post -- rehashing the topic.
  I didn't trim the email.  See my comments below.]

On Mon, 21 Jun 2004 20:10:47 +0400, Sergey Vlasov wrote:
> On Mon, Jun 21, 2004 at 06:24:40PM +0200, Andi Kleen wrote:
> 
>>On Mon, 21 Jun 2004 17:44:08 +0400
>>Sergey Vlasov <vsu@altlinux.ru> wrote:
>>
>>>On Mon, 21 Jun 2004 16:14:41 +0200 Andi Kleen wrote:
>>>
>>>
>>>>This is needed for 2.6 hotplug where the driver is autoloaded. When you have
>>>>multiple conflicting entries the hotplug module loader usually loads
>>>>the first one listed, which may be correct or may be not.
>>>>
>>>>With these changes the drivers announce the correct PCI IDs.
>>>
>>>Unfortunately, the patch does not seem to be correct :(
>>>
>>>struct pci_device_id does not have the mask field, therefore the
>>>ID_9005_GENERIC_MASK restriction cannot be specified other than by
>>>listing all 16 possible IDs as separate entries.  Your patch adds only
>>>one entry, thus losing 15 other possible IDs.
>>
>>Hmm, good point.  Thanks for catching this.
>>
>>Here is a new patch.  Does this one look better?
> 
> It fixes the above problem, but it's hard to say that the patch is
> correct without carefully checking all the tables.  I'm trying to
> hack up something to autogenerate the pci_device_id table from the
> aic7xxx internal table.
> 
> BTW, ID_AIC7810 and ID_AIC7815 probably should not be in the PCI ID
> table at all - ahc_raid_setup() just prints "RAID functionality
> unsupported" for them.  And some more IDs generated by ID16 are
> really rejected by the driver due to the (ID_9005_SISL_ID,
> ID_9005_SISL_MASK) exclusion entry.

I found several "OEM" (on-board) aic79xx controllers (mostly on
HP boxes) that breaks after the above-mentioned change, which
found it's way into 2.6.8 kernel.  For example, HP ProLiant ML
machines and others.  The end-result is that the driver, which
worked just fine before, does not "detect" the card anymore.

On one of such machines, AIC7902 U320 (rev 03) card is shown
as device=9005:801f (identified by the driver), but subsystem
id is 103c:103c, wich gets interpreted by pci.ids as
"Hewlett-Packard Company: Unknown device 103c".  It does
not look like a right thing to do, but HP knows better it
seems.

Also, I tried to guess what all those new PCI ID macros does
in the driver, but that's quite a challenge: deeply-nested
macros with non-obvious bit manipulation... ;)   So I can't
produce a patch right now for this problem.  Either way,
the resulting PCI table does not look right:

$ fgrep aic79xx /lib/modules/`uname -r`/modules.pcimap | wc -l
32
$ fgrep aic79xx /lib/modules/`uname -r`/modules.pcimap | sort -u | wc -l
15

Devices 9005:800f and 9005:801e are listed with *:* subsystem,
while the rest (incl. 9005:801f -- the one shown above) specifies
several non-wildcard subsystem entries, nothing to match 103c
(HP).

Maybe just list all subsystems as wildcards?

Thanks.

/mjt

       reply	other threads:[~2004-10-06 19:47 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <linux.scsi.20040621161047.GD16453@master.mivlgu.local>
2004-10-06 19:47 ` Michael Tokarev [this message]
2004-10-06 20:25   ` [PATCH] Add proper module ID tables to Adaptec aic7[9x]xx drivers Andi Kleen
2004-10-06 21:36     ` Michael Tokarev
2004-10-07 18:08     ` Luben Tuikov
2004-10-07 19:12       ` Michael Tokarev
2004-10-07 19:46         ` Luben Tuikov
2004-10-07 20:36           ` Christoph Hellwig
2004-10-07 20:42             ` Luben Tuikov
2004-10-07 20:47               ` Christoph Hellwig
2004-06-21 14:14 Andi Kleen
2004-06-21 13:44 ` Sergey Vlasov
2004-06-21 16:24   ` Andi Kleen
2004-06-21 16:10     ` Sergey Vlasov
2004-06-21 15:30 ` Luben Tuikov
2004-06-21 15:37   ` Arjan van de Ven
2004-06-21 18:03   ` Andi Kleen
2004-06-21 16:10     ` Luben Tuikov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=41644BD5.7030807@tls.msk.ru \
    --to=mjt@tls.msk.ru \
    --cc=ak@suse.de \
    --cc=linux-scsi@vger.kernel.org \
    --cc=luben_tuikov@adaptec.com \
    --cc=vsu@altlinux.ru \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).