From: Gérard Roudier <groudier@club-internet.fr>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Rasmus Andersen <rasmus@jaquet.dk>,
linux-kernel@vger.kernel.org, linux-scsi@vger.kernel.org
Subject: Re: [PATCH] make sym53c8xx.c and ncr53c8xx.c call pci_enable_device
Date: Wed, 31 Jan 2001 20:56:09 +0100 (CET) [thread overview]
Message-ID: <Pine.LNX.4.10.10101312032590.2134-100000@linux.local> (raw)
In-Reply-To: <E14O2SF-0002tb-00@the-village.bc.nu>
On Wed, 31 Jan 2001, Alan Cox wrote:
> > If the pci_enable_device() thing is to be added to the drivers, it must
> > preferently be placed after the checking against RAID attachement.
>
> You cant check the signature until the device has been enabled. Maybe you
> could poke the LSI guys and find out how windows PnP stuff handles this.
Personnaly I donnot need to know how windows handle this in order to
figure out how it should be properly handled.
In theory, the signature should be checked prior to any change in the
device configuration space. But since PCI BIOS assigning of resource
windows is complete mess-up, the O/S has to probe BAR sizes. The probing
of BAR sizes does not seem to harm. This done, given that it is possible
then to first check the signature and to leave quiet the device if it is
owned by RAID, there is no valuable reason to still tamper the device for
nothing if it is not to be attached.
> I think the proposed change is ok because if the board is enabled then the
> enabling code won't touch it.
Can you swear that the code will never change ?
Anyway, the current code at least enables response to IO and to MEM based
on existing BARs. This probably does not harm but this should be done on
behalf of the software driver and based on actually _used_ resources. On
the other hand, the complex enabling of IRQ is really something we want to
avoid in situation where it is not actually useful.
End of story, since moving pci_enable_device() in its preferred place as I
suggested is an obvious minute change.
Gérard.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
prev parent reply other threads:[~2001-01-31 20:57 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-01-29 22:00 [PATCH] make sym53c8xx.c and ncr53c8xx.c call pci_enable_device (241p11) Rasmus Andersen
2001-01-29 21:50 ` Gérard Roudier
2001-01-31 18:58 ` [PATCH] make sym53c8xx.c and ncr53c8xx.c call pci_enable_device Alan Cox
2001-01-31 19:56 ` Gérard Roudier [this message]
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=Pine.LNX.4.10.10101312032590.2134-100000@linux.local \
--to=groudier@club-internet.fr \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=rasmus@jaquet.dk \
/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
all inboxes | Powered by JetHome®