Re: PATCH: pci_enable_device_mask
Martin Mares wrote: > > I didn't update all the archs, just x86.. Enjoy. This is not an > > official patch submission (so Linus if you see it, don't apply...) > > Is there any reason for adding such a thing? I was thinking about it some months > ago and it seemed to me that we always have plenty of space for all the resources. eh, uh? :) This doesn't have much to do with resource space... We are talking about having pci_enable_device -not- enable PCI_COMMAND_IO and/or PCI_COMMAND_MEMORY because some hardware needs to be treated specially, and blindly enabling IO|MEM is bad news for that hardware. > Anyway, I'd prefer selecting such options via extra fields in struct pci_dev > which would the driver set before calling pci_enable_device() -- this way we > can add new options later without introducing new functions. Makes sense to me... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH: pci_enable_device_mask
Hi Jeff! > I didn't update all the archs, just x86.. Enjoy. This is not an > official patch submission (so Linus if you see it, don't apply...) Is there any reason for adding such a thing? I was thinking about it some months ago and it seemed to me that we always have plenty of space for all the resources. Anyway, I'd prefer selecting such options via extra fields in struct pci_dev which would the driver set before calling pci_enable_device() -- this way we can add new options later without introducing new functions. Have a nice fortnight -- Martin `MJ' Mares <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> http://atrey.karlin.mff.cuni.cz/~mj/ "return(ENOTOBACCO); /* Read on an empty pipe */" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH: pci_enable_device_mask
Hi Jeff! I didn't update all the archs, just x86.. Enjoy. This is not an official patch submission (so Linus if you see it, don't apply...) Is there any reason for adding such a thing? I was thinking about it some months ago and it seemed to me that we always have plenty of space for all the resources. Anyway, I'd prefer selecting such options via extra fields in struct pci_dev which would the driver set before calling pci_enable_device() -- this way we can add new options later without introducing new functions. Have a nice fortnight -- Martin `MJ' Mares [EMAIL PROTECTED] [EMAIL PROTECTED] http://atrey.karlin.mff.cuni.cz/~mj/ "return(ENOTOBACCO); /* Read on an empty pipe */" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH: pci_enable_device_mask
Martin Mares wrote: I didn't update all the archs, just x86.. Enjoy. This is not an official patch submission (so Linus if you see it, don't apply...) Is there any reason for adding such a thing? I was thinking about it some months ago and it seemed to me that we always have plenty of space for all the resources. eh, uh? :) This doesn't have much to do with resource space... We are talking about having pci_enable_device -not- enable PCI_COMMAND_IO and/or PCI_COMMAND_MEMORY because some hardware needs to be treated specially, and blindly enabling IO|MEM is bad news for that hardware. Anyway, I'd prefer selecting such options via extra fields in struct pci_dev which would the driver set before calling pci_enable_device() -- this way we can add new options later without introducing new functions. Makes sense to me... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
