Re: linux-next: build failure after merge of the final tree(staging related)

[Henry Ptasinski]

On Thu, Jun 09, 2011 at 11:41:27AM -0700, Greg KH wrote:
> On Thu, Jun 09, 2011 at 05:27:45PM +1000, Stephen Rothwell wrote:
> > Hi Greg,
> > 
> > After merging the final tree, today's linux-next build (powerpc allyesconfig)
> > failed like this:
> > 
> > drivers/staging/brcm80211/brcmsmac/ampdu.c: In function 'wlc_ampdu_dotxstatus':
> > drivers/staging/brcm80211/brcmsmac/ampdu.c:840:17: error: invalid operands to binary ^ (have 'volatile u32 *' and 'int')
> > drivers/staging/brcm80211/brcmsmac/ampdu.c:840:17: error: invalid operands to binary ^ (have 'volatile u32 *' and 'int')
> > drivers/staging/brcm80211/brcmsmac/ampdu.c:848:8: error: invalid operands to binary ^ (have 'volatile u32 *' and 'int')
> > drivers/staging/brcm80211/brcmsmac/ampdu.c:848:8: error: invalid operands to binary ^ (have 'volatile u32 *' and 'int')
> > drivers/staging/brcm80211/brcmsmac/bmac.c: In function 'wlc_bmac_update_slot_timing':
> > drivers/staging/brcm80211/brcmsmac/bmac.c:186:3: error: invalid operands to binary ^ (have 'volatile u16 *' and 'int')
> > drivers/staging/brcm80211/brcmsmac/bmac.c:186:3: error: invalid operands to binary ^ (have 'volatile u16 *' and 'int')
> > drivers/staging/brcm80211/brcmsmac/bmac.c:190:3: error: invalid operands to binary ^ (have 'volatile u16 *' and 'int')
> > drivers/staging/brcm80211/brcmsmac/bmac.c:190:3: error: invalid operands to binary ^ (have 'volatile u16 *' and 'int')
> > drivers/staging/brcm80211/brcmsmac/bmac.c: In function 'wlc_setband_inact':
> > drivers/staging/brcm80211/brcmsmac/bmac.c:234:2: error: invalid operands to binary ^ (have 'volatile u32 *' and 'int')
> > drivers/staging/brcm80211/brcmsmac/bmac.c:234:2: error: invalid operands to binary ^ (have 'volatile u32 *' and 'int')
> > drivers/staging/brcm80211/brcmsmac/bmac.c: In function 'wlc_dpc':
> > drivers/staging/brcm80211/brcmsmac/bmac.c:311:6: error: invalid operands to binary ^ (have 'volatile u32 *' and 'int')
> > 
> > (and lots more)
> 
> Fun :(
> 
> This looks messy.  It's a macro that is trying to be cute by doing:
> #define R_REG(r) \
>         ({ \
>                 __typeof(*(r)) __osl_v; \
>                 __asm__ __volatile__("sync"); \
>                 __osl_v = bcmsdh_reg_read(NULL, (unsigned long)(r),\
>                                           sizeof(*(r))); \
>                 __asm__ __volatile__("sync"); \
>                 __osl_v; \
>         })
> 
> on big-endian, non-mips platforms.  Which I really doubt has ever
> been tested before.

I think it was used on PPC once upon a time, but likely in a very different
incarnation.

> Roland, Brett, any thoughts?
> 
> Should I just disable this module from being build on PPC as it doesn't
> look like its ever been tested or run on that platform before.

Disabling the build on PPC for now sounds ok.  We'll work on cleaning up the
macros and try to get some more platform test coverage.

- Henry


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/