lkml.org 
[lkml]   [2006]   [Nov]   [8]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
    /
    DateTue, 07 Nov 2006 21:29:37 -0800 (PST)
    SubjectRe: DMA APIs gumble grumble
    FromDavid Miller <>
    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 06:31    [from the cache]
    ©2003-2008