On Thu, Dec 13, 2012 at 07:14:49PM +0100, Alessandro Rubini wrote:
> This is a long-standing problem, but with not practical effects. I
> proposed a pair of different fixes quite some months ago. I'll respin
> the problem tomorrow.
Did this got fixed in some tree in the meantime? Because I still see it on
current Linus + tip/master:
arch/x86/pci/sta2x11-fixup.c:186:2: warning: initialization from incompatible pointer type [enabled by default]
arch/x86/pci/sta2x11-fixup.c:186:2: warning: (near initialization for ‘sta2x11_dma_ops.free’) [enabled by default]
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
> Did this got fixed in some tree in the meantime? Because I still see it on
> current Linus + tip/master:
>
> arch/x86/pci/sta2x11-fixup.c:186:2: warning: initialization from incompatible pointer type [enabled by default]
> arch/x86/pci/sta2x11-fixup.c:186:2: warning: (near initialization for âsta2x11_dma_ops.freeâ) [enabled by default]
Last time I sent the patch was on Feb 22nd:
The .free field of struct dma_map_ops features a prototype that is
different from what lib/swiotlb.c offers. The new "attrs" argument in
dma_ops.free is missing from the generic implementation.
This removes the build warning by providing a function that just calls
swiotlb_free_coherent() without passing "attrs", like others do.
I got no reply.
This is the link:
http://lkml.org/lkml/2013/2/22/111
It is in patchwork here:
https://patchwork.kernel.org/patch/2175551/
/alessandro
On Sun, May 05, 2013 at 10:24:22PM +0200, Alessandro Rubini wrote:
> > Did this got fixed in some tree in the meantime? Because I still see it on
> > current Linus + tip/master:
> >
> > arch/x86/pci/sta2x11-fixup.c:186:2: warning: initialization from incompatible pointer type [enabled by default]
> > arch/x86/pci/sta2x11-fixup.c:186:2: warning: (near initialization for âsta2x11_dma_ops.freeâ) [enabled by default]
>
> Last time I sent the patch was on Feb 22nd:
>
> The .free field of struct dma_map_ops features a prototype that is
> different from what lib/swiotlb.c offers. The new "attrs" argument in
> dma_ops.free is missing from the generic implementation.
>
> This removes the build warning by providing a function that just calls
> swiotlb_free_coherent() without passing "attrs", like others do.
>
> I got no reply.
It probably fell through the cracks...
> This is the link:
>
> http://lkml.org/lkml/2013/2/22/111
>
> It is in patchwork here:
>
> https://patchwork.kernel.org/patch/2175551/
Ingo, hpa, can you guys pick it up?
Thanks.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
* Borislav Petkov <[email protected]> wrote:
> On Sun, May 05, 2013 at 10:24:22PM +0200, Alessandro Rubini wrote:
> > > Did this got fixed in some tree in the meantime? Because I still see it on
> > > current Linus + tip/master:
> > >
> > > arch/x86/pci/sta2x11-fixup.c:186:2: warning: initialization from incompatible pointer type [enabled by default]
> > > arch/x86/pci/sta2x11-fixup.c:186:2: warning: (near initialization for ??????sta2x11_dma_ops.free??????) [enabled by default]
> >
> > Last time I sent the patch was on Feb 22nd:
> >
> > The .free field of struct dma_map_ops features a prototype that is
> > different from what lib/swiotlb.c offers. The new "attrs" argument in
> > dma_ops.free is missing from the generic implementation.
> >
> > This removes the build warning by providing a function that just calls
> > swiotlb_free_coherent() without passing "attrs", like others do.
> >
> > I got no reply.
>
> It probably fell through the cracks...
>
> > This is the link:
> >
> > http://lkml.org/lkml/2013/2/22/111
> >
> > It is in patchwork here:
> >
> > https://patchwork.kernel.org/patch/2175551/
>
> Ingo, hpa, can you guys pick it up?
A lot happened meanwhile - patches got acked, applied - so I expected a
resend of the patches that are still pending, with all acks in place in
the patches (not in the cover letter), and against Linus's latest tree.
Thanks,
Ingo
All-To: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected] Re: [PATCH v4 0/7] enable support for AMBA drivers under x86
> From: Ingo Molnar <[email protected]>
> To: Borislav Petkov <[email protected]>
> Cc: Alessandro Rubini <[email protected]>, [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
> Subject: Re: [PATCH v4 0/7] enable support for AMBA drivers under x86
> Date: Mon, 6 May 2013 11:41:54 +0200
> A lot happened meanwhile - patches got acked, applied - so I expected a
> resend of the patches that are still pending, with all acks in place in
> the patches (not in the cover letter), and against Linus's latest tree.
Ok, I'll resend this AMBA/PCI set. But this warning we are discussing
about is unrelated and I sent it by itself in february. Anyways, I'll
add it to the patch-set I'm going to send most likely tomorrow.
thanks
/alessndro
On Mon, May 06, 2013 at 11:41:54AM +0200, Ingo Molnar wrote:
> A lot happened meanwhile - patches got acked, applied - so I expected
> a resend of the patches that are still pending, with all acks in place
> in the patches (not in the cover letter), and against Linus's latest
> tree.
That one above was a single submission anyway and it could go in now
since it fixes a build issue. I don't know about the rest of the set
though.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--