[openfabrics-ewg] [PATCH] ehca backport openib_dma_addr_t_ofed_1.1_to_2_6_9.patch

[Michael S. Tsirkin]

Quoting r. Hoang-Nam Nguyen <HNGUYEN at de.ibm.com>:
> Subject: Re: [PATCH] ehca backport openib_dma_addr_t_ofed_1.1_to_2_6_9.patch
> 
> Hi,
> > Please note 2.6.9 from kernel.org is not supported by OFED -
> > these backports are actually for RHEL4 U2.
> ok
> > This does not make sense to me.
> > Can we just do
> > #define dma_map dma64_map
> Sure. We can do that as newer kernels map dma_addr_t to u32 resp u64.

Hmm. Which kernels do that?

> > And what will this do on non-ppc arches?
> For non-ppc arches and non-ibmebus, ie. for pci and vio,
> dma64_map/unmap_single() will call the actual dma_map/unmap_single(),
> whose result is 32-bit number and does fit certainly into caller's
> assigment
> of type dma_addr_t/dma64_addr_t.
> > I don't think we can add such intrusive patches at this late stage.
> I see your point. However this touches only usage of dma_addr_t and
> dma_map/unmap_single() as explained above. So I personally think it should
> not harm the rest `theoretically`. Note that this is related to and
> requires ibmebus patch.

Let's see the patch with #defines then. If it's small, maybe we can apply it
if ehca is enabled only, so at least there will be a work-around
if it breaks things.

> Hm, if this will not be included in 1.1, do we plan to have a kind of
> "service pack" then? If yes, can you tell me the schedules?

Donnu, really. But ehca is a technology preview anyway, I don't think
we'll be able to add major changes because of this, either.

> Thanks!
> Nam Nguyen
> 

-- 
MST