All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.