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)
Also in several other files in drivers/staging/brcm80211/
Also:
drivers/staging/comedi/drivers.c: In function 'comedi_buf_alloc':
drivers/staging/comedi/drivers.c:505:37: error: 'PAGE_KERNEL_NOCACHE' undeclared (first use in this function)
In file included from drivers/staging/comedi/drivers/addi_apci_035.c:7:0:
drivers/staging/comedi/drivers/addi-data/addi_common.c: In function 'i_ADDI_Attach':
drivers/staging/comedi/drivers/addi-data/addi_common.c:2765:7: error: implicit declaration of function 'virt_to_bus'
(Also several other occurrences of that one)
I left this build broken, but these should be fixed if you are going to
remove STAGING_EXCLUDE_BUILD.
--
Cheers,
Stephen Rothwell [email protected]
http://www.canb.auug.org.au/~sfr/
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.
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.
> Also in several other files in drivers/staging/brcm80211/
>
> Also:
>
> drivers/staging/comedi/drivers.c: In function 'comedi_buf_alloc':
> drivers/staging/comedi/drivers.c:505:37: error: 'PAGE_KERNEL_NOCACHE' undeclared (first use in this function)
> In file included from drivers/staging/comedi/drivers/addi_apci_035.c:7:0:
> drivers/staging/comedi/drivers/addi-data/addi_common.c: In function 'i_ADDI_Attach':
> drivers/staging/comedi/drivers/addi-data/addi_common.c:2765:7: error: implicit declaration of function 'virt_to_bus'
>
> (Also several other occurrences of that one)
I'll fix this up, it looks just like a #include that needs to be added.
thanks,
greg k-h
On Thu, Jun 09, 2011 at 11:41:27AM -0700, Greg KH wrote:
> > Also in several other files in drivers/staging/brcm80211/
> >
> > Also:
> >
> > drivers/staging/comedi/drivers.c: In function 'comedi_buf_alloc':
> > drivers/staging/comedi/drivers.c:505:37: error: 'PAGE_KERNEL_NOCACHE' undeclared (first use in this function)
> > In file included from drivers/staging/comedi/drivers/addi_apci_035.c:7:0:
> > drivers/staging/comedi/drivers/addi-data/addi_common.c: In function 'i_ADDI_Attach':
> > drivers/staging/comedi/drivers/addi-data/addi_common.c:2765:7: error: implicit declaration of function 'virt_to_bus'
> >
> > (Also several other occurrences of that one)
>
> I'll fix this up, it looks just like a #include that needs to be added.
I've fixed all of these up, thanks for reporting them.
greg k-h
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
On Thu, Jun 09, 2011 at 12:52:12PM -0700, Henry Ptasinski wrote:
> 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.
Ok, I've done that now and pushed it to the staging-next tree.
greg k-h
Hi Greg,
On Thu, 9 Jun 2011 12:22:43 -0700 Greg KH <[email protected]> wrote:
>
> On Thu, Jun 09, 2011 at 11:41:27AM -0700, Greg KH wrote:
> > > Also in several other files in drivers/staging/brcm80211/
> > >
> > > Also:
> > >
> > > drivers/staging/comedi/drivers.c: In function 'comedi_buf_alloc':
> > > drivers/staging/comedi/drivers.c:505:37: error: 'PAGE_KERNEL_NOCACHE' undeclared (first use in this function)
> > > In file included from drivers/staging/comedi/drivers/addi_apci_035.c:7:0:
> > > drivers/staging/comedi/drivers/addi-data/addi_common.c: In function 'i_ADDI_Attach':
> > > drivers/staging/comedi/drivers/addi-data/addi_common.c:2765:7: error: implicit declaration of function 'virt_to_bus'
> > >
> > > (Also several other occurrences of that one)
> >
> > I'll fix this up, it looks just like a #include that needs to be added.
>
> I've fixed all of these up, thanks for reporting them.
No, I still get these:
In file included from drivers/staging/comedi/drivers/addi_apci_035.c:7:0:
drivers/staging/comedi/drivers/addi-data/addi_common.c: In function 'i_ADDI_Attach':
drivers/staging/comedi/drivers/addi-data/addi_common.c:2765:7: error: implicit declaration of function 'virt_to_bus'
virt_to_bus is only defined for 32 bit powerpc (not 64 bit) (and maybe
not at all on some architectures e.g. sparc).
From Documentation/DMA-API-HOWTO.txt:
"All drivers should be using these interfaces with no exceptions. It
is planned to completely remove virt_to_bus() and bus_to_virt() as
they are entirely deprecated. Some ports already do not provide these
as it is impossible to correctly support them."
--
Cheers,
Stephen Rothwell [email protected]
http://www.canb.auug.org.au/~sfr/
Hi Greg,
On Fri, 10 Jun 2011 16:05:48 +1000 Stephen Rothwell <[email protected]> wrote:
>
> No, I still get these:
>
> In file included from drivers/staging/comedi/drivers/addi_apci_035.c:7:0:
> drivers/staging/comedi/drivers/addi-data/addi_common.c: In function 'i_ADDI_Attach':
> drivers/staging/comedi/drivers/addi-data/addi_common.c:2765:7: error: implicit declaration of function 'virt_to_bus'
>
> virt_to_bus is only defined for 32 bit powerpc (not 64 bit) (and maybe
> not at all on some architectures e.g. sparc).
>
> From Documentation/DMA-API-HOWTO.txt:
> "All drivers should be using these interfaces with no exceptions. It
> is planned to completely remove virt_to_bus() and bus_to_virt() as
> they are entirely deprecated. Some ports already do not provide these
> as it is impossible to correctly support them."
Drivers that use virt_to_bus should Kconfig depend on VIRT_TO_BUS.
--
Cheers,
Stephen Rothwell [email protected]
http://www.canb.auug.org.au/~sfr/
On Fri, Jun 10, 2011 at 04:09:38PM +1000, Stephen Rothwell wrote:
> Hi Greg,
>
> On Fri, 10 Jun 2011 16:05:48 +1000 Stephen Rothwell <[email protected]> wrote:
> >
> > No, I still get these:
> >
> > In file included from drivers/staging/comedi/drivers/addi_apci_035.c:7:0:
> > drivers/staging/comedi/drivers/addi-data/addi_common.c: In function 'i_ADDI_Attach':
> > drivers/staging/comedi/drivers/addi-data/addi_common.c:2765:7: error: implicit declaration of function 'virt_to_bus'
> >
> > virt_to_bus is only defined for 32 bit powerpc (not 64 bit) (and maybe
> > not at all on some architectures e.g. sparc).
> >
> > From Documentation/DMA-API-HOWTO.txt:
> > "All drivers should be using these interfaces with no exceptions. It
> > is planned to completely remove virt_to_bus() and bus_to_virt() as
> > they are entirely deprecated. Some ports already do not provide these
> > as it is impossible to correctly support them."
>
> Drivers that use virt_to_bus should Kconfig depend on VIRT_TO_BUS.
Ah, I missed that, sorry. I'll go make that change as well.
greg k-h
Hi Greg,
On Fri, 10 Jun 2011 15:34:23 -0700 Greg KH <[email protected]> wrote:
>
> On Fri, Jun 10, 2011 at 04:09:38PM +1000, Stephen Rothwell wrote:
> >
> > On Fri, 10 Jun 2011 16:05:48 +1000 Stephen Rothwell <[email protected]> wrote:
> > >
> > > No, I still get these:
> > >
> > > In file included from drivers/staging/comedi/drivers/addi_apci_035.c:7:0:
> > > drivers/staging/comedi/drivers/addi-data/addi_common.c: In function 'i_ADDI_Attach':
> > > drivers/staging/comedi/drivers/addi-data/addi_common.c:2765:7: error: implicit declaration of function 'virt_to_bus'
> > >
> > > virt_to_bus is only defined for 32 bit powerpc (not 64 bit) (and maybe
> > > not at all on some architectures e.g. sparc).
> > >
> > > From Documentation/DMA-API-HOWTO.txt:
> > > "All drivers should be using these interfaces with no exceptions. It
> > > is planned to completely remove virt_to_bus() and bus_to_virt() as
> > > they are entirely deprecated. Some ports already do not provide these
> > > as it is impossible to correctly support them."
> >
> > Drivers that use virt_to_bus should Kconfig depend on VIRT_TO_BUS.
>
> Ah, I missed that, sorry. I'll go make that change as well.
Ping?
--
Cheers,
Stephen Rothwell [email protected]
http://www.canb.auug.org.au/~sfr/
On Fri, Jun 10, 2011 at 08:05, Stephen Rothwell <[email protected]> wrote:
> On Thu, 9 Jun 2011 12:22:43 -0700 Greg KH <[email protected]> wrote:
>> On Thu, Jun 09, 2011 at 11:41:27AM -0700, Greg KH wrote:
>> > > Also in several other files in drivers/staging/brcm80211/
>> > >
>> > > Also:
>> > >
>> > > drivers/staging/comedi/drivers.c: In function 'comedi_buf_alloc':
>> > > drivers/staging/comedi/drivers.c:505:37: error: 'PAGE_KERNEL_NOCACHE' undeclared (first use in this function)
I have my doubts
#ifdef PAGE_KERNEL_NOCACHE
vmap(pages, n_pages, VM_MAP, PAGE_KERNEL_NOCACHE);
#else
vmap(pages, n_pages, VM_MAP, PAGE_KERNEL);
#endif
is the right "fix" for this...
BTW, PAGE_KERNEL_NOCACHE is defined on frv, m32r, mn10300, sh, and x86 only.
Strangely, both sparc and tile have
/*
* Some hardware wants to get fixmapped without caching.
*/
#define set_fixmap_nocache(idx, phys) \
__set_fixmap(idx, phys, PAGE_KERNEL_NOCACHE)
in their <asm/fixmap.h>, without having PAGE_KERNEL_NOCACHE...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
TILE doesn't support PAGE_KERNEL_NOCACHE so the macro isn't useful;
it's a copy-and-paste from the first version of this header in 2007.
Signed-off-by: Chris Metcalf <[email protected]>
---
arch/tile/include/asm/fixmap.h | 6 ------
1 files changed, 0 insertions(+), 6 deletions(-)
diff --git a/arch/tile/include/asm/fixmap.h b/arch/tile/include/asm/fixmap.h
index 51537ff..c66f793 100644
--- a/arch/tile/include/asm/fixmap.h
+++ b/arch/tile/include/asm/fixmap.h
@@ -75,12 +75,6 @@ extern void __set_fixmap(enum fixed_addresses idx,
#define set_fixmap(idx, phys) \
__set_fixmap(idx, phys, PAGE_KERNEL)
-/*
- * Some hardware wants to get fixmapped without caching.
- */
-#define set_fixmap_nocache(idx, phys) \
- __set_fixmap(idx, phys, PAGE_KERNEL_NOCACHE)
-
#define clear_fixmap(idx) \
__set_fixmap(idx, 0, __pgprot(0))
--
1.6.5.2
On Wed, Jun 15, 2011 at 02:05:29PM +0200, Geert Uytterhoeven wrote:
> On Fri, Jun 10, 2011 at 08:05, Stephen Rothwell <[email protected]> wrote:
> > On Thu, 9 Jun 2011 12:22:43 -0700 Greg KH <[email protected]> wrote:
> >> On Thu, Jun 09, 2011 at 11:41:27AM -0700, Greg KH wrote:
> >> > > Also in several other files in drivers/staging/brcm80211/
> >> > >
> >> > > Also:
> >> > >
> >> > > drivers/staging/comedi/drivers.c: In function 'comedi_buf_alloc':
> >> > > drivers/staging/comedi/drivers.c:505:37: error: 'PAGE_KERNEL_NOCACHE' undeclared (first use in this function)
>
> I have my doubts
>
> #ifdef PAGE_KERNEL_NOCACHE
> vmap(pages, n_pages, VM_MAP, PAGE_KERNEL_NOCACHE);
> #else
> vmap(pages, n_pages, VM_MAP, PAGE_KERNEL);
> #endif
>
> is the right "fix" for this...
>
> BTW, PAGE_KERNEL_NOCACHE is defined on frv, m32r, mn10300, sh, and x86 only.
>
> Strangely, both sparc and tile have
>
> /*
> * Some hardware wants to get fixmapped without caching.
> */
> #define set_fixmap_nocache(idx, phys) \
> __set_fixmap(idx, phys, PAGE_KERNEL_NOCACHE)
>
> in their <asm/fixmap.h>, without having PAGE_KERNEL_NOCACHE...
So, what should the correct fix here be?
confused,
greg k-h
On Wed, Jun 15, 2011 at 02:21:55PM +1000, Stephen Rothwell wrote:
> Hi Greg,
>
> On Fri, 10 Jun 2011 15:34:23 -0700 Greg KH <[email protected]> wrote:
> >
> > On Fri, Jun 10, 2011 at 04:09:38PM +1000, Stephen Rothwell wrote:
> > >
> > > On Fri, 10 Jun 2011 16:05:48 +1000 Stephen Rothwell <[email protected]> wrote:
> > > >
> > > > No, I still get these:
> > > >
> > > > In file included from drivers/staging/comedi/drivers/addi_apci_035.c:7:0:
> > > > drivers/staging/comedi/drivers/addi-data/addi_common.c: In function 'i_ADDI_Attach':
> > > > drivers/staging/comedi/drivers/addi-data/addi_common.c:2765:7: error: implicit declaration of function 'virt_to_bus'
> > > >
> > > > virt_to_bus is only defined for 32 bit powerpc (not 64 bit) (and maybe
> > > > not at all on some architectures e.g. sparc).
> > > >
> > > > From Documentation/DMA-API-HOWTO.txt:
> > > > "All drivers should be using these interfaces with no exceptions. It
> > > > is planned to completely remove virt_to_bus() and bus_to_virt() as
> > > > they are entirely deprecated. Some ports already do not provide these
> > > > as it is impossible to correctly support them."
> > >
> > > Drivers that use virt_to_bus should Kconfig depend on VIRT_TO_BUS.
> >
> > Ah, I missed that, sorry. I'll go make that change as well.
>
> Ping?
Sorry, been swamped with other work, I'll get to this soon...
With a very relative value of soon.
greg k-h
Hi Greg,
On Thu, 16 Jun 2011 12:14:48 -0700 Greg KH <[email protected]> wrote:
>
> On Wed, Jun 15, 2011 at 02:21:55PM +1000, Stephen Rothwell wrote:
> >
> > On Fri, 10 Jun 2011 15:34:23 -0700 Greg KH <[email protected]> wrote:
> > >
> > > On Fri, Jun 10, 2011 at 04:09:38PM +1000, Stephen Rothwell wrote:
> > > >
> > > > On Fri, 10 Jun 2011 16:05:48 +1000 Stephen Rothwell <[email protected]> wrote:
> > > > >
> > > > > No, I still get these:
> > > > >
> > > > > In file included from drivers/staging/comedi/drivers/addi_apci_035.c:7:0:
> > > > > drivers/staging/comedi/drivers/addi-data/addi_common.c: In function 'i_ADDI_Attach':
> > > > > drivers/staging/comedi/drivers/addi-data/addi_common.c:2765:7: error: implicit declaration of function 'virt_to_bus'
> > > > >
> > > > > virt_to_bus is only defined for 32 bit powerpc (not 64 bit) (and maybe
> > > > > not at all on some architectures e.g. sparc).
> > > > >
> > > > > From Documentation/DMA-API-HOWTO.txt:
> > > > > "All drivers should be using these interfaces with no exceptions. It
> > > > > is planned to completely remove virt_to_bus() and bus_to_virt() as
> > > > > they are entirely deprecated. Some ports already do not provide these
> > > > > as it is impossible to correctly support them."
> > > >
> > > > Drivers that use virt_to_bus should Kconfig depend on VIRT_TO_BUS.
> > >
> > > Ah, I missed that, sorry. I'll go make that change as well.
> >
> > Ping?
>
> Sorry, been swamped with other work, I'll get to this soon...
ping?
> With a very relative value of soon.
Yeah, I understand busy ... but this is a simple patch, rigth?
--
Cheers,
Stephen Rothwell [email protected]
http://www.canb.auug.org.au/~sfr/
On Thu, Jun 23, 2011 at 10:35:03AM +1000, Stephen Rothwell wrote:
> Hi Greg,
>
> On Thu, 16 Jun 2011 12:14:48 -0700 Greg KH <[email protected]> wrote:
> >
> > On Wed, Jun 15, 2011 at 02:21:55PM +1000, Stephen Rothwell wrote:
> > >
> > > On Fri, 10 Jun 2011 15:34:23 -0700 Greg KH <[email protected]> wrote:
> > > >
> > > > On Fri, Jun 10, 2011 at 04:09:38PM +1000, Stephen Rothwell wrote:
> > > > >
> > > > > On Fri, 10 Jun 2011 16:05:48 +1000 Stephen Rothwell <[email protected]> wrote:
> > > > > >
> > > > > > No, I still get these:
> > > > > >
> > > > > > In file included from drivers/staging/comedi/drivers/addi_apci_035.c:7:0:
> > > > > > drivers/staging/comedi/drivers/addi-data/addi_common.c: In function 'i_ADDI_Attach':
> > > > > > drivers/staging/comedi/drivers/addi-data/addi_common.c:2765:7: error: implicit declaration of function 'virt_to_bus'
> > > > > >
> > > > > > virt_to_bus is only defined for 32 bit powerpc (not 64 bit) (and maybe
> > > > > > not at all on some architectures e.g. sparc).
> > > > > >
> > > > > > From Documentation/DMA-API-HOWTO.txt:
> > > > > > "All drivers should be using these interfaces with no exceptions. It
> > > > > > is planned to completely remove virt_to_bus() and bus_to_virt() as
> > > > > > they are entirely deprecated. Some ports already do not provide these
> > > > > > as it is impossible to correctly support them."
> > > > >
> > > > > Drivers that use virt_to_bus should Kconfig depend on VIRT_TO_BUS.
> > > >
> > > > Ah, I missed that, sorry. I'll go make that change as well.
> > >
> > > Ping?
> >
> > Sorry, been swamped with other work, I'll get to this soon...
>
> ping?
>
> > With a very relative value of soon.
>
> Yeah, I understand busy ... but this is a simple patch, rigth?
Sorry, I'm away from home, with a very spotty internet connection, on
vacation, so it's hard to get this done at the moment. I'll get to it
on the 27th when I return.
thanks,
greg k-h
Hi Greg,
On Thu, 23 Jun 2011 14:51:15 -0700 Greg KH <[email protected]> wrote:
>
> Sorry, I'm away from home, with a very spotty internet connection, on
> vacation, so it's hard to get this done at the moment. I'll get to it
> on the 27th when I return.
I can understand vacation as well :-)
Thanks. I will use Ralf's (arch restricting) patch until you come up
with something better.
--
Cheers,
Stephen Rothwell [email protected]
http://www.canb.auug.org.au/~sfr/
On Fri, Jun 24, 2011 at 10:00:05AM +1000, Stephen Rothwell wrote:
> Hi Greg,
>
> On Thu, 23 Jun 2011 14:51:15 -0700 Greg KH <[email protected]> wrote:
> >
> > Sorry, I'm away from home, with a very spotty internet connection, on
> > vacation, so it's hard to get this done at the moment. I'll get to it
> > on the 27th when I return.
>
> I can understand vacation as well :-)
>
> Thanks. I will use Ralf's (arch restricting) patch until you come up
> with something better.
That's good, but it doesn't fix the root problem here. I've now fixed
this up in the staging-linus branch.
You shouldn't have any more build breakages in the drivers/staging/*
tree now as I am pretty sure I've fixed all reported issues. If not,
please let me know.
thanks,
greg k-h
Hi Greg,
On Mon, 27 Jun 2011 14:45:47 -0700 Greg KH <[email protected]> wrote:
>
> On Fri, Jun 24, 2011 at 10:00:05AM +1000, Stephen Rothwell wrote:
> >
> > Thanks. I will use Ralf's (arch restricting) patch until you come up
> > with something better.
>
> That's good, but it doesn't fix the root problem here. I've now fixed
> this up in the staging-linus branch.
OK, I have removed my copy of Ralf's patch.
> You shouldn't have any more build breakages in the drivers/staging/*
> tree now as I am pretty sure I've fixed all reported issues. If not,
> please let me know.
Great, thanks.
--
Cheers,
Stephen Rothwell [email protected]
http://www.canb.auug.org.au/~sfr/