On Wed, Nov 05, 2008 at 09:38:29AM -0000, James Woodcock wrote: > Well, it's a bit complicated. We have some cards that are based on the > Intel e1000 (and, these days, e1000e) driver. In the past, a colleague > (who has since left) tried to get a patch with our device IDs into the That'd be me. > standard kernel drivers - that's pretty much the only change that is > needed to support our cards. This patch was rejected. I'm not totally > sure why, but I'd assume Intel don't want to be seen to be supporting > hardware that they have know nothing about - which would be an They also had substantial concerns about the use of modified primary vendor ID on hardware otherwise compatible with the vanilla driver, strongly recommending that the hardware not be shipped in that configuration. Unfortunately the hardware was already out in the wild at that point. > understandable position. So I have to support our cards by supplying > patches to our customers to enable them to recompile the e1000 driver to > work with our cards. ...which is rather unfortunate, especially when the required support is simply a matter of adding device IDs. I had contemplated producing a patch which allowed the driver to clearly identify the board hardware vendor which I hoped would address concerns about identification of the hardware but wasn't sure that that would get enough buy in to be worthwhile. Clearly there ought to be some way of supporting the cards in the standard kernel. > There are two reasons I would like the patch applied: > 1. The device ID is used in both e1000 and e1000e drivers. > 2. The simpler my patch is, the more likely it will be able to be > applied to future kernels if the standard e1000 code is modified. You should just be able to change the patch to use the numeric vendor ID so it doesn't depend on pci_ids.h. The reason I'd done it with the symbolic vendor ID was that this was idiomatic for the existing driver. -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
