[PATCH] core/addr: fix compilation warning {was Re: [openib-general] Latest build test results}

[Nishanth Aravamudan]

On 15.10.2005 [06:05:54 -0400], Hal Rosenstock wrote:
> Hi Nish,
> 
> On Sat, 2005-10-15 at 01:24, Nishanth Aravamudan wrote:
> > On 11.10.2005 [23:15:27 -0400], Hal Rosenstock wrote:
> > > Hi again Nish,
> > > 
> > > On Tue, 2005-10-11 at 21:39, Nishanth Aravamudan wrote:
> > > > > > > Update arp_recv functions to latest 2.6.14 netdevice.h API for struct
> > > > > > > packet_type
> > > > > > 
> > > > > > Sorry for the delay, I haven't yet had time to test the patches :/ I'll
> > > > > > try to get to it tonight or tomorrow.
> > > > > > 
> > > > > > Is there anyway you can send me patches against the kernel tree as
> > > > > > opposed to the svn repo? It makes my side of things *a lot* easier, as
> > > > > > right now I have to take your patch against svn and either hand-edit or
> > > > > > patch my checkout and then diff against the current kernel tree.
> > > > > 
> > > > > Since you were reporting iSER, AT, and SDP compile warnings/errors,
> > > > > aren't you using the latest OpenIB svn tree with 2.6.14-rc3 ?
> > > > 
> > > > Yes; but you have to understand that the automated build system I have
> > > > access to 1) does not have external internet access (i.e., to the svn
> > > > tree) and 2) only builds kernels unless I manually send commands to the
> > > > terminal.
> > > > 
> > > > So, the way I'm doing things is:
> > > > 
> > > > Send in 4 jobs for mainline (x86 and ppc64 with =y and =m) and then
> > > > generate a patch of the latest svn tree against the current -git release
> > > > (a patch to the kernel) and send it in as a parameter to my builds to
> > > > test the latest svn tree. This leads to another 4 jobs (x86 and ppc64
> > > > with =y and =m).
> > > > 
> > > > I'm *only* doing kernel build testing right now.
> > > > 
> > > > > Which patches are you referring to ? Was it the fib_frontend.c one ?
> > > > > Not sure why they would need any manual fixup. At least that one was
> > > > > pretty straightforward.
> > > > 
> > > > In the sense that I have to edit them to kernel relative paths, not in
> > > > the content of the patch. To test any patch in the system I have access
> > > > to, it needs to be a normal kernel patch (-p1 applicable to the base
> > > > tree).
> > > > 
> > > > Going through and manually applying patches to the svn tree and then
> > > > regenerating the diff completely defeats the purpose of automated
> > > > compilation testing.
> > > 
> > > OK. Do you need any patches regenerated or is this more for the future ?
> > 
> > Please check-in the at.c, sdp_link.c and iser.h fixes, as now gen2 code
> > builds on x86 and ppc64 with only the following warning (which I believe
> > is new)
> > 
> > drivers/infiniband/core/addr.c:330: warning: initialization from incompatible pointer type
> > 
> > when the patches are applied. Without them the x86 build fails
> > completely and the ppc64 build emits several warning.
> > 
> > Sorry for the *long* delay, it took a bit of effort to get the patches
> > to cooperate with our automated build system. Thanks to Hal for his
> > quick response and generous patience in waiting for my ack.
> > 
> > So, officially, I give
> > 
> > Acked-by: Nishanth Aravamudan <nacc at us.ibm.com>
> > 
> > to the at.c, sdp_link.c and iser.h fixes.
> 
> Thanks for trying out these patches. Sorry for the manual intervention.

No problem; it unfortunately wasn't as simple as just editing the
patches, as when I did so, all the hunks would fail. So I just
regenerated them locally against current-git. Not a big deal, since
these were small changes.

> I regenerated the patches for fib_frontend.c, at.c, and sdp_link.c and
> they are in linux-kernel/patches. Hopefully these will work with your
> automated build system. These are found in linux-kernel/patches as:
> linux-2.6.14-rc3-at.diff
> linux-2.6.14-rc3-fib-frontend.diff
> linux-2.6.14-rc3-sdp_link.diff

Those look great and are identical to the ones I generated. So, my
Acked-by applies to those 3.

> Dan will be checking in the iser.h fix. 

Ok, great!

I think the core/addr.c problem can be fixed with the following:

Thanks,
Nish

Description: Fix a compilation warning in core/addr.c due to
packet_type's func member changing prototype.

Signed-off-by: Nishanth Aravamudan <nacc at us.ibm.com>

---

diff -urpN linux-2.6.14-rc4-git4-dev/drivers/infiniband/core/addr.c linux-2.6.14-rc4-git4-dev2/drivers/infiniband/core/addr.c
--- linux-2.6.14-rc4-git4-dev/drivers/infiniband/core/addr.c	2005-10-15 09:52:26.000000000 -0700
+++ linux-2.6.14-rc4-git4-dev2/drivers/infiniband/core/addr.c	2005-10-15 09:52:56.000000000 -0700
@@ -310,7 +310,7 @@ void ib_addr_cancel(struct ib_addr *addr
 EXPORT_SYMBOL(ib_addr_cancel);
 
 static int addr_arp_recv(struct sk_buff *skb, struct net_device *dev,
-			 struct packet_type *pkt)
+			 struct packet_type *pkt, struct net_device *orig_dev)
 {
 	struct arphdr *arp_hdr;