![]() | |||||||||||||
Messages in this thread |
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: Wed, 08 Nov 2006 16:23:40 +1100 > Then, maybe 6 month, maybe 1 year later, we can change archs that use > the "alternate" semantic like sparc64 to no longer fail > pci_set_dma_mask(64bits). > > In fact, the only breakage here would be for those archs to have some > drivers start going slowly, though we could expect drivers to have been > fixed by then.... (And we can delay that second part of the change as > long as deemed necessary). The arch implementations of pci_map_*() et al. might start failing since they were written assuming that DAC never got enabled. > Yup, but you didn't fix sparc32 :-) I suppose I can try to do it and ask > Anton for help if things go wrong, though I can't be bothered building a > cross toolchain or getting a box on ebay so I'll rely on your for > testing :-) I only do sparc32 build testing, which you can do on a sparc64 box and Al Viro has great recipies for cross tool building and usage. > Thus, that is 3 pointers gone for archs who don't use these, and the ability > to put things like your dma ops in every struct device. How exactly does your device struct extension work? I ask because struct device is embedded into other structs, such as pci_dev, so it has to be fixed in size unless you have some clever trick. :) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | ||||||||||||
| Last update: 2006-11-08 05:31 [from the cache] ©2003-2008 | |||||||||||||