On Wed, 14 Feb 2001, Grant Grundler wrote:
> Philipp Rumpf wrote:
> > Jeff Garzik wrote:
> > > Looks ok, but I wonder if we should include this list in the docs.
> > > These is stuff defined by the PCI spec, and this list could potentially
> > > get longer... (opinions either way wanted...)
>
On Wed, 14 Feb 2001, Grant Grundler wrote:
Philipp Rumpf wrote:
Jeff Garzik wrote:
Looks ok, but I wonder if we should include this list in the docs.
These is stuff defined by the PCI spec, and this list could potentially
get longer... (opinions either way wanted...)
Having
Philipp Rumpf wrote:
> On Wed, 14 Feb 2001, Grant Grundler wrote:
> > Having people look things up in the spec isn't very user friendly.
>
> Having the constants in some well-known header file should be sufficient,
> shouldn't it ?
I would hope anyone bothering to include the constants in a
On Wed, 14 Feb 2001, Grant Grundler wrote:
> Philipp Rumpf wrote:
> > Jeff Garzik wrote:
> > > Looks ok, but I wonder if we should include this list in the docs.
> > > These is stuff defined by the PCI spec, and this list could potentially
> > > get longer... (opinions either way wanted...)
>
>
Philipp Rumpf wrote:
> Jeff Garzik wrote:
> > Looks ok, but I wonder if we should include this list in the docs.
> > These is stuff defined by the PCI spec, and this list could potentially
> > get longer... (opinions either way wanted...)
Having people look things up in the spec isn't very user
On Wed, 14 Feb 2001, Jeff Garzik wrote:
> On Wed, 14 Feb 2001, Tim Waugh wrote:
> > +/**
> > + * pci_find_capability - query for devices' capabilities
> > + * @dev: PCI device to query
> > + * @cap: capability code
> > + *
> > + * Tell if a device supports a given PCI capability.
> > + * Returns
On Wed, 14 Feb 2001, Tim Waugh wrote:
> + * pci_find_subsys - begin or continue searching for a PCI device by
>vendor/subvendor/device/subdevice id
> + * @vendor: PCI vendor id to match, or %PCI_ANY_ID to match all vendor ids
> + * @device: PCI device id to match, or %PCI_ANY_ID to match all
On Wed, 14 Feb 2001, Tim Waugh wrote:
> }
>
> -
> +/**
> + * pci_find_capability - query for devices' capabilities
> + * @dev: PCI device to query
> + * @cap: capability code
> + *
> + * Tell if a device supports a given PCI capability.
> + * Returns the address of the requested capability
On Wed, Feb 14, 2001 at 05:14:19AM -0600, Jeff Garzik wrote:
> Should the call to pci_unregister_driver in cleanup_module be
> conditional on registered_parport as well? I didn't check...
No. (cleanup_module is only called if init_module succeeded.)
> Also, is it possible to convert
On Wed, 14 Feb 2001, Andrew Morton wrote:
> Jeff Garzik wrote:
> >
> > Bad patch. It should be
> >
> > if (r >= 0) {
> > registered_parport = 1;
> > if (r > 0)
> > count += r;
> > }
> >
> > If pci_register_driver returns
On Wed, Feb 14, 2001 at 10:21:38PM +1100, Andrew Morton wrote:
> Now, if there were some actual COMMENTS (scary, I know) in the pci
> code which described the API, stuff like this wouldn't happen.
Oh yeah, that reminds me: if someone would like to make sure that the
following changes are
On Wed, 14 Feb 2001, Tim Waugh wrote:
> On Wed, Feb 14, 2001 at 02:03:07AM -0600, Jeff Garzik wrote:
>
> > If pci_register_driver returns < 0, the driver is not registered with
> > the system.
>
> Thanks. Okay, second try:
>
> 2001-01-14 Tim Waugh <[EMAIL PROTECTED]>
>
> *
Jeff Garzik wrote:
>
> Bad patch. It should be
>
> if (r >= 0) {
> registered_parport = 1;
> if (r > 0)
> count += r;
> }
>
> If pci_register_driver returns < 0, the driver is not registered with
> the system.
eh?
On Wed, Feb 14, 2001 at 02:03:07AM -0600, Jeff Garzik wrote:
> If pci_register_driver returns < 0, the driver is not registered with
> the system.
Thanks. Okay, second try:
2001-01-14 Tim Waugh <[EMAIL PROTECTED]>
* parport_pc.c: Fix PCI driver list corruption on
On Wed, 14 Feb 2001, Jeff Garzik wrote:
> On Tue, 13 Feb 2001, Tim Waugh wrote:
> > Here's a patch that fixes a bug that can cause PCI driver list
> > corruption. If parport_pc's init_module fails after it calls
> > pci_register_driver, cleanup_module isn't called and so it's still
> >
On Wed, 14 Feb 2001, Jeff Garzik wrote:
On Tue, 13 Feb 2001, Tim Waugh wrote:
Here's a patch that fixes a bug that can cause PCI driver list
corruption. If parport_pc's init_module fails after it calls
pci_register_driver, cleanup_module isn't called and so it's still
registered when
On Wed, Feb 14, 2001 at 02:03:07AM -0600, Jeff Garzik wrote:
If pci_register_driver returns 0, the driver is not registered with
the system.
Thanks. Okay, second try:
2001-01-14 Tim Waugh [EMAIL PROTECTED]
* parport_pc.c: Fix PCI driver list corruption on
unsuccessful
Jeff Garzik wrote:
Bad patch. It should be
if (r = 0) {
registered_parport = 1;
if (r 0)
count += r;
}
If pci_register_driver returns 0, the driver is not registered with
the system.
eh?
On Wed, 14 Feb 2001, Tim Waugh wrote:
On Wed, Feb 14, 2001 at 02:03:07AM -0600, Jeff Garzik wrote:
If pci_register_driver returns 0, the driver is not registered with
the system.
Thanks. Okay, second try:
2001-01-14 Tim Waugh [EMAIL PROTECTED]
* parport_pc.c: Fix PCI
On Wed, 14 Feb 2001, Andrew Morton wrote:
Jeff Garzik wrote:
Bad patch. It should be
if (r = 0) {
registered_parport = 1;
if (r 0)
count += r;
}
If pci_register_driver returns 0, the driver is not
On Wed, Feb 14, 2001 at 10:21:38PM +1100, Andrew Morton wrote:
Now, if there were some actual COMMENTS (scary, I know) in the pci
code which described the API, stuff like this wouldn't happen.
Oh yeah, that reminds me: if someone would like to make sure that the
following changes are
On Wed, Feb 14, 2001 at 05:14:19AM -0600, Jeff Garzik wrote:
Should the call to pci_unregister_driver in cleanup_module be
conditional on registered_parport as well? I didn't check...
No. (cleanup_module is only called if init_module succeeded.)
Also, is it possible to convert parport_pc
On Wed, 14 Feb 2001, Tim Waugh wrote:
+ * pci_find_subsys - begin or continue searching for a PCI device by
vendor/subvendor/device/subdevice id
+ * @vendor: PCI vendor id to match, or %PCI_ANY_ID to match all vendor ids
+ * @device: PCI device id to match, or %PCI_ANY_ID to match all vendor
On Wed, 14 Feb 2001, Jeff Garzik wrote:
On Wed, 14 Feb 2001, Tim Waugh wrote:
+/**
+ * pci_find_capability - query for devices' capabilities
+ * @dev: PCI device to query
+ * @cap: capability code
+ *
+ * Tell if a device supports a given PCI capability.
+ * Returns the address of
Philipp Rumpf wrote:
Jeff Garzik wrote:
Looks ok, but I wonder if we should include this list in the docs.
These is stuff defined by the PCI spec, and this list could potentially
get longer... (opinions either way wanted...)
Having people look things up in the spec isn't very user
Philipp Rumpf wrote:
On Wed, 14 Feb 2001, Grant Grundler wrote:
Having people look things up in the spec isn't very user friendly.
Having the constants in some well-known header file should be sufficient,
shouldn't it ?
I would hope anyone bothering to include the constants in a document
On Tue, 13 Feb 2001, Tim Waugh wrote:
> Here's a patch that fixes a bug that can cause PCI driver list
> corruption. If parport_pc's init_module fails after it calls
> pci_register_driver, cleanup_module isn't called and so it's still
> registered when it gets unloaded.
> ---
Linus,
Here's a patch that fixes a bug that can cause PCI driver list
corruption. If parport_pc's init_module fails after it calls
pci_register_driver, cleanup_module isn't called and so it's still
registered when it gets unloaded.
Tim.
*/
2001-01-13 Tim Waugh <[EMAIL PROTECTED]>
*
Linus,
Here's a patch that fixes a bug that can cause PCI driver list
corruption. If parport_pc's init_module fails after it calls
pci_register_driver, cleanup_module isn't called and so it's still
registered when it gets unloaded.
Tim.
*/
2001-01-13 Tim Waugh [EMAIL PROTECTED]
*
On Tue, 13 Feb 2001, Tim Waugh wrote:
Here's a patch that fixes a bug that can cause PCI driver list
corruption. If parport_pc's init_module fails after it calls
pci_register_driver, cleanup_module isn't called and so it's still
registered when it gets unloaded.
---
30 matches
Mail list logo
