Albert D. Cahalan <[EMAIL PROTECTED]> writes:
>PCI is certainly hot-plug hardware, but not on common desktop PCs.
>Since PCI is so popular and so often not hot-plug, users should
>not be forced to have hot-plug PCI support when they only need
>hot-plug SCSI, etc.
>Obvious hack: __pciinit, __pcie
Adam J. Richter writes:
> Can I have a hot plug PCI bridge card that connects to
> a regular PCI backplane (perhaps as some kind of CardBus docking
> station card)? If so, all PCI drivers should use __dev{init,exit}{,data}.
PCI is certainly hot-plug hardware, but not on common desktop PCs
I wrote:
>[...] the cost of incorrectly
>using __initdata when __devinitdata was correct is that the user's
>KERNEL WILL CRASH when the notebook is inserted or removed from such a
>docking station, even when the kernel is built with CONFIG_HOTPLUG.
My statement above, without some missin
>I am willing to consider adding __devxxx only when other __devxxx
>entries already exist.
>These conversions to _devxxx are too late in the freeze, and only have
>value for isolated cases --which you admit you don't even know exist--.
>Linus Rule 1: Don't overdesign.
Even ignoring Card
"Adam J. Richter" wrote:
> Jeff Garzik writes:
> >Are you aware of any hotplug sunhme hardware? If no, don't change it to
> >__devinit...
>
> Can I have a hot plug PCI bridge card that connects to
> a regular PCI backplane (perhaps as some kind of CardBus docking
> station card)? If so,
Jeff Garzik writes:
>Are you aware of any hotplug sunhme hardware? If no, don't change it to
>__devinit...
Can I have a hot plug PCI bridge card that connects to
a regular PCI backplane (perhaps as some kind of CardBus docking
station card)? If so, all PCI drivers should use __dev{init
"Adam J. Richter" wrote:
> -static struct happy_meal *root_happy_dev = NULL;
> -
> #ifdef CONFIG_SBUS
> +static struct happy_meal *root_happy_dev = NULL;
> static struct quattro *qfe_sbus_list = NULL;
> #endif
don't initialize static to zero/null explicitly..
> - if (dev == NULL) {
> -
On Thu, Nov 16, 2000 at 04:22:36AM -0800, David S. Miller wrote:
> Sure, that sounds nice.
>
> Actually, one of the possible "grand plans" for 2.5 is a unified
> "struct device". I don't know what will actually happen here.
apologies for pointing out the potentially obvoius, but people might
w
Date: Thu, 16 Nov 2000 13:13:37 +0100
From: Christoph Hellwig <[EMAIL PROTECTED]>
Would you accept such a change for 2.5?
Sure, that sounds nice.
Actually, one of the possible "grand plans" for 2.5 is a unified
"struct device". I don't know what will actually happen here.
Later,
Davi
In article <[EMAIL PROTECTED]> you wrote:
> I never ported it to the new PCI interfaces strictly because when
> combined with SBUS it makes the driver initialization look really
> sloppy.
BTW, what do you think of a new PCI style probing for SBUS?
When I hacked on a small sbus driver, I thought
From: "Adam J. Richter" <[EMAIL PROTECTED]>
Date: Thu, 16 Nov 2000 03:10:14 -0800
>Sorry, I don't like this change.
Can you at least add the MODULE_DEVICE_TABLE declaration
and the pci_device_id table that it refers to, even if the code
does not directly reference it?
>Sorry, I don't like this change.
Can you at least add the MODULE_DEVICE_TABLE declaration
and the pci_device_id table that it refers to, even if the code
does not directly reference it? (You can make it as __initdata
rather than __devinitdata, since it can safely be thrown away.)
That w
I never ported it to the new PCI interfaces strictly because when
combined with SBUS it makes the driver initialization look really
sloppy.
Sorry, I don't like this change.
Later,
David S. Miller
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
I don't have access to a Sun HME card, but, for some neurotic
reason, I decided to try porting sunhme.c to the new PCI interface.
I believe it has simplified the code slightly. More importantly, it
causes the module to export a table with the PCI ID's that it cares
about, which is used by
14 matches
Mail list logo
