Re: [balbi-usb:xceiv 3/3] drivers/usb/phy/rcar-phy.c:75:3: error: implicit declaration of function 'iowrite32'

Re: [balbi-usb:xceiv 3/3] drivers/usb/phy/rcar-phy.c:75:3: error: implicit declaration of function 'iowrite32'

[Greg KH]

On Thu, Nov 01, 2012 at 12:50:34PM +0200, Felipe Balbi wrote:
> On Thu, Nov 01, 2012 at 12:33:39PM +0200, Felipe Balbi wrote:
> > Hi,
> > 
> > On Thu, Nov 01, 2012 at 06:29:30PM +0800, kbuild test robot wrote:
> > > tree:   git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git xceiv
> > > head:   1789e52acc90c87484a109d6349eefe63cabb257
> > > commit: 1789e52acc90c87484a109d6349eefe63cabb257 [3/3] usb: phy: add R-Car USB phy driver
> > > config: make ARCH=cris allyesconfig
> > > 
> > > All error/warnings:
> > > 
> > > drivers/usb/phy/rcar-phy.c: In function 'rcar_usb_phy_init':
> > > drivers/usb/phy/rcar-phy.c:75:3: error: implicit declaration of function 'iowrite32' [-Werror=implicit-function-declaration]
> > > drivers/usb/phy/rcar-phy.c:83:4: error: implicit declaration of function 'ioread32' [-Werror=implicit-function-declaration]
> > > cc1: some warnings being treated as errors
> > 
> > too bad that it compiles fine on x86 and ARM :-(
> > 
> > Kuninori, care to send me a fixup patch ? I guess using writel()/readl()
> > should do it ?!?
> 
> looks like this isn't enough. We have 6 arches which don't provide
> writel()/readl(), namely blackfin, c6x, openrisc, s390, score, and um.
> 
> Should those arches be fixed instead ? Don't we have a single
> memory-mapped access set of APIs which are supposed to be provided by
> all arches ?
> 
> Greg, you've been doing this for much more time then I have. Should all
> arches provide writeb/w/l/q and readb/w/l/q ??

I would think so, but I really don't know.

linux-arch people, what do we do about architectures that don't provide
these functions?  Just disable building the drivers for them, or do we
fix them somehow?

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [balbi-usb:xceiv 3/3] drivers/usb/phy/rcar-phy.c:75:3: error: implicit declaration of function 'iowrite32'

[Greg KH]

On Thu, Nov 01, 2012 at 12:50:34PM +0200, Felipe Balbi wrote:
> On Thu, Nov 01, 2012 at 12:33:39PM +0200, Felipe Balbi wrote:
> > Hi,
> > 
> > On Thu, Nov 01, 2012 at 06:29:30PM +0800, kbuild test robot wrote:
> > > tree:   git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git xceiv
> > > head:   1789e52acc90c87484a109d6349eefe63cabb257
> > > commit: 1789e52acc90c87484a109d6349eefe63cabb257 [3/3] usb: phy: add R-Car USB phy driver
> > > config: make ARCH=cris allyesconfig
> > > 
> > > All error/warnings:
> > > 
> > > drivers/usb/phy/rcar-phy.c: In function 'rcar_usb_phy_init':
> > > drivers/usb/phy/rcar-phy.c:75:3: error: implicit declaration of function 'iowrite32' [-Werror=implicit-function-declaration]
> > > drivers/usb/phy/rcar-phy.c:83:4: error: implicit declaration of function 'ioread32' [-Werror=implicit-function-declaration]
> > > cc1: some warnings being treated as errors
> > 
> > too bad that it compiles fine on x86 and ARM :-(
> > 
> > Kuninori, care to send me a fixup patch ? I guess using writel()/readl()
> > should do it ?!?
> 
> looks like this isn't enough. We have 6 arches which don't provide
> writel()/readl(), namely blackfin, c6x, openrisc, s390, score, and um.
> 
> Should those arches be fixed instead ? Don't we have a single
> memory-mapped access set of APIs which are supposed to be provided by
> all arches ?
> 
> Greg, you've been doing this for much more time then I have. Should all
> arches provide writeb/w/l/q and readb/w/l/q ??

I would think so, but I really don't know.

linux-arch people, what do we do about architectures that don't provide
these functions?  Just disable building the drivers for them, or do we
fix them somehow?

thanks,

greg k-h

Re: [balbi-usb:xceiv 3/3] drivers/usb/phy/rcar-phy.c:75:3: error: implicit declaration of function 'iowrite32'

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 2164 bytes --]

Hi,

On Thu, Nov 01, 2012 at 06:04:20AM -0700, Greg KH wrote:
> On Thu, Nov 01, 2012 at 12:50:34PM +0200, Felipe Balbi wrote:
> > On Thu, Nov 01, 2012 at 12:33:39PM +0200, Felipe Balbi wrote:
> > > Hi,
> > > 
> > > On Thu, Nov 01, 2012 at 06:29:30PM +0800, kbuild test robot wrote:
> > > > tree:   git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git xceiv
> > > > head:   1789e52acc90c87484a109d6349eefe63cabb257
> > > > commit: 1789e52acc90c87484a109d6349eefe63cabb257 [3/3] usb: phy: add R-Car USB phy driver
> > > > config: make ARCH=cris allyesconfig
> > > > 
> > > > All error/warnings:
> > > > 
> > > > drivers/usb/phy/rcar-phy.c: In function 'rcar_usb_phy_init':
> > > > drivers/usb/phy/rcar-phy.c:75:3: error: implicit declaration of function 'iowrite32' [-Werror=implicit-function-declaration]
> > > > drivers/usb/phy/rcar-phy.c:83:4: error: implicit declaration of function 'ioread32' [-Werror=implicit-function-declaration]
> > > > cc1: some warnings being treated as errors
> > > 
> > > too bad that it compiles fine on x86 and ARM :-(
> > > 
> > > Kuninori, care to send me a fixup patch ? I guess using writel()/readl()
> > > should do it ?!?
> > 
> > looks like this isn't enough. We have 6 arches which don't provide
> > writel()/readl(), namely blackfin, c6x, openrisc, s390, score, and um.
> > 
> > Should those arches be fixed instead ? Don't we have a single
> > memory-mapped access set of APIs which are supposed to be provided by
> > all arches ?
> > 
> > Greg, you've been doing this for much more time then I have. Should all
> > arches provide writeb/w/l/q and readb/w/l/q ??
> 
> I would think so, but I really don't know.
> 
> linux-arch people, what do we do about architectures that don't provide
> these functions?  Just disable building the drivers for them, or do we
> fix them somehow?

btw, only alpha and x86 seem to be providing all of those, but if you
look into our documentation, it's said that drivers are supposed to use
write/read{b,w,l,q} for all memory-mapped io. I'd expect all platforms
to provide those even if just to allow compilation of drivers.

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [balbi-usb:xceiv 3/3] drivers/usb/phy/rcar-phy.c:75:3: error: implicit declaration of function 'iowrite32'

[Bjørn Mork]

Felipe Balbi <balbi-l0cyMroinI0@public.gmane.org> writes:

> btw, only alpha and x86 seem to be providing all of those, but if you
> look into our documentation, it's said that drivers are supposed to use
> write/read{b,w,l,q} for all memory-mapped io. I'd expect all platforms
> to provide those even if just to allow compilation of drivers.

Only if HAS_IOMEM is true, I believe.


Bjørn
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [balbi-usb:xceiv 3/3] drivers/usb/phy/rcar-phy.c:75:3: error: implicit declaration of function 'iowrite32'

[Bjørn Mork]

Felipe Balbi <balbi@ti.com> writes:

> btw, only alpha and x86 seem to be providing all of those, but if you
> look into our documentation, it's said that drivers are supposed to use
> write/read{b,w,l,q} for all memory-mapped io. I'd expect all platforms
> to provide those even if just to allow compilation of drivers.

Only if HAS_IOMEM is true, I believe.


Bjørn

Re: [balbi-usb:xceiv 3/3] drivers/usb/phy/rcar-phy.c:75:3: error: implicit declaration of function 'iowrite32'

[Max Filippov]

On Thu, Nov 1, 2012 at 5:23 PM, Felipe Balbi <balbi@ti.com> wrote:
> Hi,
>
> On Thu, Nov 01, 2012 at 06:04:20AM -0700, Greg KH wrote:
>> On Thu, Nov 01, 2012 at 12:50:34PM +0200, Felipe Balbi wrote:
>> > On Thu, Nov 01, 2012 at 12:33:39PM +0200, Felipe Balbi wrote:
>> > > Hi,
>> > >
>> > > On Thu, Nov 01, 2012 at 06:29:30PM +0800, kbuild test robot wrote:
>> > > > tree:   git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git xceiv
>> > > > head:   1789e52acc90c87484a109d6349eefe63cabb257
>> > > > commit: 1789e52acc90c87484a109d6349eefe63cabb257 [3/3] usb: phy: add R-Car USB phy driver
>> > > > config: make ARCH=cris allyesconfig
>> > > >
>> > > > All error/warnings:
>> > > >
>> > > > drivers/usb/phy/rcar-phy.c: In function 'rcar_usb_phy_init':
>> > > > drivers/usb/phy/rcar-phy.c:75:3: error: implicit declaration of function 'iowrite32' [-Werror=implicit-function-declaration]
>> > > > drivers/usb/phy/rcar-phy.c:83:4: error: implicit declaration of function 'ioread32' [-Werror=implicit-function-declaration]
>> > > > cc1: some warnings being treated as errors
>> > >
>> > > too bad that it compiles fine on x86 and ARM :-(
>> > >
>> > > Kuninori, care to send me a fixup patch ? I guess using writel()/readl()
>> > > should do it ?!?
>> >
>> > looks like this isn't enough. We have 6 arches which don't provide
>> > writel()/readl(), namely blackfin, c6x, openrisc, s390, score, and um.
>> >
>> > Should those arches be fixed instead ? Don't we have a single
>> > memory-mapped access set of APIs which are supposed to be provided by
>> > all arches ?
>> >
>> > Greg, you've been doing this for much more time then I have. Should all
>> > arches provide writeb/w/l/q and readb/w/l/q ??
>>
>> I would think so, but I really don't know.
>>
>> linux-arch people, what do we do about architectures that don't provide
>> these functions?  Just disable building the drivers for them, or do we
>> fix them somehow?
>
> btw, only alpha and x86 seem to be providing all of those, but if you
> look into our documentation, it's said that drivers are supposed to use
> write/read{b,w,l,q} for all memory-mapped io. I'd expect all platforms
> to provide those even if just to allow compilation of drivers.

Strange, AFAICS architectures that use asm-generic/io.h (blackfin, openrisc,
score, unicore32 and xtensa) also provide those functions.

-- 
Thanks.
-- Max

Re: [balbi-usb:xceiv 3/3] drivers/usb/phy/rcar-phy.c:75:3: error: implicit declaration of function 'iowrite32'

[Fengguang Wu]

On Thu, Nov 01, 2012 at 04:47:14PM +0300, Max Filippov wrote:
> On Thu, Nov 1, 2012 at 5:23 PM, Felipe Balbi <balbi@ti.com> wrote:
> > Hi,
> >
> > On Thu, Nov 01, 2012 at 06:04:20AM -0700, Greg KH wrote:
> >> On Thu, Nov 01, 2012 at 12:50:34PM +0200, Felipe Balbi wrote:
> >> > On Thu, Nov 01, 2012 at 12:33:39PM +0200, Felipe Balbi wrote:
> >> > > Hi,
> >> > >
> >> > > On Thu, Nov 01, 2012 at 06:29:30PM +0800, kbuild test robot wrote:
> >> > > > tree:   git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git xceiv
> >> > > > head:   1789e52acc90c87484a109d6349eefe63cabb257
> >> > > > commit: 1789e52acc90c87484a109d6349eefe63cabb257 [3/3] usb: phy: add R-Car USB phy driver
> >> > > > config: make ARCH=cris allyesconfig
> >> > > >
> >> > > > All error/warnings:
> >> > > >
> >> > > > drivers/usb/phy/rcar-phy.c: In function 'rcar_usb_phy_init':
> >> > > > drivers/usb/phy/rcar-phy.c:75:3: error: implicit declaration of function 'iowrite32' [-Werror=implicit-function-declaration]
> >> > > > drivers/usb/phy/rcar-phy.c:83:4: error: implicit declaration of function 'ioread32' [-Werror=implicit-function-declaration]
> >> > > > cc1: some warnings being treated as errors
> >> > >
> >> > > too bad that it compiles fine on x86 and ARM :-(
> >> > >
> >> > > Kuninori, care to send me a fixup patch ? I guess using writel()/readl()
> >> > > should do it ?!?
> >> >
> >> > looks like this isn't enough. We have 6 arches which don't provide
> >> > writel()/readl(), namely blackfin, c6x, openrisc, s390, score, and um.
> >> >
> >> > Should those arches be fixed instead ? Don't we have a single
> >> > memory-mapped access set of APIs which are supposed to be provided by
> >> > all arches ?
> >> >
> >> > Greg, you've been doing this for much more time then I have. Should all
> >> > arches provide writeb/w/l/q and readb/w/l/q ??
> >>
> >> I would think so, but I really don't know.
> >>
> >> linux-arch people, what do we do about architectures that don't provide
> >> these functions?  Just disable building the drivers for them, or do we
> >> fix them somehow?
> >
> > btw, only alpha and x86 seem to be providing all of those, but if you
> > look into our documentation, it's said that drivers are supposed to use
> > write/read{b,w,l,q} for all memory-mapped io. I'd expect all platforms
> > to provide those even if just to allow compilation of drivers.
> 
> Strange, AFAICS architectures that use asm-generic/io.h (blackfin, openrisc,
> score, unicore32 and xtensa) also provide those functions.

FYI, build log shows that the errors only happen for cris among all
the allyesconfig builds: 

        cris-allyesconfig
        parisc-allyesconfig
        sparc64-allyesconfig
        xtensa-allyesconfig
        sparc-allyesconfig
        m68k-allyesconfig
        x86_64-allyesconfig
        powerpc-allyesconfig
        mips-allyesconfig

Thanks,
Fengguang

Re: [balbi-usb:xceiv 3/3] drivers/usb/phy/rcar-phy.c:75:3: error: implicit declaration of function 'iowrite32'

[David Miller]

From: Bjørn Mork <bjorn@mork.no>
Date: Thu, 01 Nov 2012 14:38:29 +0100

> Felipe Balbi <balbi@ti.com> writes:
> 
>> btw, only alpha and x86 seem to be providing all of those, but if you
>> look into our documentation, it's said that drivers are supposed to use
>> write/read{b,w,l,q} for all memory-mapped io. I'd expect all platforms
>> to provide those even if just to allow compilation of drivers.
> 
> Only if HAS_IOMEM is true, I believe.

This is correct.

Re: [balbi-usb:xceiv 3/3] drivers/usb/phy/rcar-phy.c:75:3: error: implicit declaration of function 'iowrite32'

[David Miller]

From: Max Filippov <jcmvbkbc@gmail.com>
Date: Thu, 1 Nov 2012 16:47:14 +0300

> Strange, AFAICS architectures that use asm-generic/io.h (blackfin, openrisc,
> score, unicore32 and xtensa) also provide those functions.

They define HAVE_IOMEM, s390 does not, therefore you must protect
the driver Kconfig with HAVE_IOMEM.

Re: [balbi-usb:xceiv 3/3] drivers/usb/phy/rcar-phy.c:75:3: error: implicit declaration of function 'iowrite32'

[James Bottomley]

On Thu, 2012-11-01 at 06:04 -0700, Greg KH wrote:
> On Thu, Nov 01, 2012 at 12:50:34PM +0200, Felipe Balbi wrote:
> > On Thu, Nov 01, 2012 at 12:33:39PM +0200, Felipe Balbi wrote:
> > > Hi,
> > > 
> > > On Thu, Nov 01, 2012 at 06:29:30PM +0800, kbuild test robot wrote:
> > > > tree:   git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git xceiv
> > > > head:   1789e52acc90c87484a109d6349eefe63cabb257
> > > > commit: 1789e52acc90c87484a109d6349eefe63cabb257 [3/3] usb: phy: add R-Car USB phy driver
> > > > config: make ARCH=cris allyesconfig
> > > > 
> > > > All error/warnings:
> > > > 
> > > > drivers/usb/phy/rcar-phy.c: In function 'rcar_usb_phy_init':
> > > > drivers/usb/phy/rcar-phy.c:75:3: error: implicit declaration of function 'iowrite32' [-Werror=implicit-function-declaration]
> > > > drivers/usb/phy/rcar-phy.c:83:4: error: implicit declaration of function 'ioread32' [-Werror=implicit-function-declaration]
> > > > cc1: some warnings being treated as errors
> > > 
> > > too bad that it compiles fine on x86 and ARM :-(
> > > 
> > > Kuninori, care to send me a fixup patch ? I guess using writel()/readl()
> > > should do it ?!?
> > 
> > looks like this isn't enough. We have 6 arches which don't provide
> > writel()/readl(), namely blackfin, c6x, openrisc, s390, score, and um.
> > 
> > Should those arches be fixed instead ? Don't we have a single
> > memory-mapped access set of APIs which are supposed to be provided by
> > all arches ?
> > 
> > Greg, you've been doing this for much more time then I have. Should all
> > arches provide writeb/w/l/q and readb/w/l/q ??

Certainly not the q variants.  It's debatable on the l ones.

The reason for the q problem is that if the arch can achieve atomic bus
transactions for 8 bytes, that's fine, but if the arch can't do that,
it's up to the driver to decide what it needs.  Most can do two 4 byte
writes, but a few need the atomicity.  We can't decide that in the arch
so we'd have to assume the most extreme case, so using a spinlock around
the two 4 byte writes to ensure atomicity, which would be a killer for
performance.

> I would think so, but I really don't know.
> 
> linux-arch people, what do we do about architectures that don't provide
> these functions?  Just disable building the drivers for them, or do we
> fix them somehow?

A good driver has #if's for this case ... see for example

drivers/scsi/ipr.h

(ipr doesn't need atomicity, so it just defines writeq to be a pair of
writels.  See drivers/scsi/mpt2sas/mpt2sas_base.c for a driver that
requires atomicity.)

James


--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [balbi-usb:xceiv 3/3] drivers/usb/phy/rcar-phy.c:75:3: error: implicit declaration of function 'iowrite32'

[James Bottomley]

On Thu, 2012-11-01 at 06:04 -0700, Greg KH wrote:
> On Thu, Nov 01, 2012 at 12:50:34PM +0200, Felipe Balbi wrote:
> > On Thu, Nov 01, 2012 at 12:33:39PM +0200, Felipe Balbi wrote:
> > > Hi,
> > > 
> > > On Thu, Nov 01, 2012 at 06:29:30PM +0800, kbuild test robot wrote:
> > > > tree:   git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git xceiv
> > > > head:   1789e52acc90c87484a109d6349eefe63cabb257
> > > > commit: 1789e52acc90c87484a109d6349eefe63cabb257 [3/3] usb: phy: add R-Car USB phy driver
> > > > config: make ARCH=cris allyesconfig
> > > > 
> > > > All error/warnings:
> > > > 
> > > > drivers/usb/phy/rcar-phy.c: In function 'rcar_usb_phy_init':
> > > > drivers/usb/phy/rcar-phy.c:75:3: error: implicit declaration of function 'iowrite32' [-Werror=implicit-function-declaration]
> > > > drivers/usb/phy/rcar-phy.c:83:4: error: implicit declaration of function 'ioread32' [-Werror=implicit-function-declaration]
> > > > cc1: some warnings being treated as errors
> > > 
> > > too bad that it compiles fine on x86 and ARM :-(
> > > 
> > > Kuninori, care to send me a fixup patch ? I guess using writel()/readl()
> > > should do it ?!?
> > 
> > looks like this isn't enough. We have 6 arches which don't provide
> > writel()/readl(), namely blackfin, c6x, openrisc, s390, score, and um.
> > 
> > Should those arches be fixed instead ? Don't we have a single
> > memory-mapped access set of APIs which are supposed to be provided by
> > all arches ?
> > 
> > Greg, you've been doing this for much more time then I have. Should all
> > arches provide writeb/w/l/q and readb/w/l/q ??

Certainly not the q variants.  It's debatable on the l ones.

The reason for the q problem is that if the arch can achieve atomic bus
transactions for 8 bytes, that's fine, but if the arch can't do that,
it's up to the driver to decide what it needs.  Most can do two 4 byte
writes, but a few need the atomicity.  We can't decide that in the arch
so we'd have to assume the most extreme case, so using a spinlock around
the two 4 byte writes to ensure atomicity, which would be a killer for
performance.

> I would think so, but I really don't know.
> 
> linux-arch people, what do we do about architectures that don't provide
> these functions?  Just disable building the drivers for them, or do we
> fix them somehow?

A good driver has #if's for this case ... see for example

drivers/scsi/ipr.h

(ipr doesn't need atomicity, so it just defines writeq to be a pair of
writels.  See drivers/scsi/mpt2sas/mpt2sas_base.c for a driver that
requires atomicity.)

James

Re: [balbi-usb:xceiv 3/3] drivers/usb/phy/rcar-phy.c:75:3: error: implicit declaration of function 'iowrite32'

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 850 bytes --]

Hi,

On Thu, Nov 01, 2012 at 11:06:58AM -0400, David Miller wrote:
> From: Bjørn Mork <bjorn@mork.no>
> Date: Thu, 01 Nov 2012 14:38:29 +0100
> 
> > Felipe Balbi <balbi@ti.com> writes:
> > 
> >> btw, only alpha and x86 seem to be providing all of those, but if you
> >> look into our documentation, it's said that drivers are supposed to use
> >> write/read{b,w,l,q} for all memory-mapped io. I'd expect all platforms
> >> to provide those even if just to allow compilation of drivers.
> > 
> > Only if HAS_IOMEM is true, I believe.
> 
> This is correct.

fair enough, then we can depend on HAS_IOMEM.

Another question, if HAS_IOMEM is true, is the arch expected to provide
*all* accessor methods ? And the last one: if the arch provides
read/write{b,w,l,q}, should it be selecting HAS_IOMEM ??

cheers, thanks

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [balbi-usb:xceiv 3/3] drivers/usb/phy/rcar-phy.c:75:3: error: implicit declaration of function 'iowrite32'

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 2611 bytes --]

Hi,

On Thu, Nov 01, 2012 at 04:47:14PM +0300, Max Filippov wrote:
> On Thu, Nov 1, 2012 at 5:23 PM, Felipe Balbi <balbi@ti.com> wrote:
> > Hi,
> >
> > On Thu, Nov 01, 2012 at 06:04:20AM -0700, Greg KH wrote:
> >> On Thu, Nov 01, 2012 at 12:50:34PM +0200, Felipe Balbi wrote:
> >> > On Thu, Nov 01, 2012 at 12:33:39PM +0200, Felipe Balbi wrote:
> >> > > Hi,
> >> > >
> >> > > On Thu, Nov 01, 2012 at 06:29:30PM +0800, kbuild test robot wrote:
> >> > > > tree:   git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git xceiv
> >> > > > head:   1789e52acc90c87484a109d6349eefe63cabb257
> >> > > > commit: 1789e52acc90c87484a109d6349eefe63cabb257 [3/3] usb: phy: add R-Car USB phy driver
> >> > > > config: make ARCH=cris allyesconfig
> >> > > >
> >> > > > All error/warnings:
> >> > > >
> >> > > > drivers/usb/phy/rcar-phy.c: In function 'rcar_usb_phy_init':
> >> > > > drivers/usb/phy/rcar-phy.c:75:3: error: implicit declaration of function 'iowrite32' [-Werror=implicit-function-declaration]
> >> > > > drivers/usb/phy/rcar-phy.c:83:4: error: implicit declaration of function 'ioread32' [-Werror=implicit-function-declaration]
> >> > > > cc1: some warnings being treated as errors
> >> > >
> >> > > too bad that it compiles fine on x86 and ARM :-(
> >> > >
> >> > > Kuninori, care to send me a fixup patch ? I guess using writel()/readl()
> >> > > should do it ?!?
> >> >
> >> > looks like this isn't enough. We have 6 arches which don't provide
> >> > writel()/readl(), namely blackfin, c6x, openrisc, s390, score, and um.
> >> >
> >> > Should those arches be fixed instead ? Don't we have a single
> >> > memory-mapped access set of APIs which are supposed to be provided by
> >> > all arches ?
> >> >
> >> > Greg, you've been doing this for much more time then I have. Should all
> >> > arches provide writeb/w/l/q and readb/w/l/q ??
> >>
> >> I would think so, but I really don't know.
> >>
> >> linux-arch people, what do we do about architectures that don't provide
> >> these functions?  Just disable building the drivers for them, or do we
> >> fix them somehow?
> >
> > btw, only alpha and x86 seem to be providing all of those, but if you
> > look into our documentation, it's said that drivers are supposed to use
> > write/read{b,w,l,q} for all memory-mapped io. I'd expect all platforms
> > to provide those even if just to allow compilation of drivers.
> 
> Strange, AFAICS architectures that use asm-generic/io.h (blackfin, openrisc,
> score, unicore32 and xtensa) also provide those functions.

hehe, missed that part :-)

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [balbi-usb:xceiv 3/3] drivers/usb/phy/rcar-phy.c:75:3: error: implicit declaration of function 'iowrite32'

[Bjørn Mork]

Felipe Balbi <balbi-l0cyMroinI0@public.gmane.org> writes:
> On Thu, Nov 01, 2012 at 11:06:58AM -0400, David Miller wrote:
>> From: Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org>
>> Date: Thu, 01 Nov 2012 14:38:29 +0100
>> 
>> > Felipe Balbi <balbi-l0cyMroinI0@public.gmane.org> writes:
>> > 
>> >> btw, only alpha and x86 seem to be providing all of those, but if you
>> >> look into our documentation, it's said that drivers are supposed to use
>> >> write/read{b,w,l,q} for all memory-mapped io. I'd expect all platforms
>> >> to provide those even if just to allow compilation of drivers.
>> > 
>> > Only if HAS_IOMEM is true, I believe.
>> 
>> This is correct.
>
> fair enough, then we can depend on HAS_IOMEM.
>
> Another question, if HAS_IOMEM is true, is the arch expected to provide
> *all* accessor methods ?

I'll leave this for those with more clue...

But there is a comment in arch/alpha/include/asm/io.h indicating that
writeq/readq support is tested separately, so I guess it must be
optional:

/*
 * Some mucking forons use if[n]def writeq to check if platform has it.
 * It's a bloody bad idea and we probably want ARCH_HAS_WRITEQ for them
 * to play with; for now just use cpp anti-recursion logics and make sure
 * that damn thing is defined and expands to itself.
 */

#define writeq writeq
#define readq readq


> And the last one: if the arch provides
> read/write{b,w,l,q}, should it be selecting HAS_IOMEM ??

But that one is easy: HAS_IOMEM is true by default.  The arch sets
NO_IOMEM to disable it. Similar to HAS_DMA.  So you can be pretty sure
that HAS_IOMEM is selected unless the arch has reasons not to.  From
lib/Kconfig:

config HAS_IOMEM
        boolean
        depends on !NO_IOMEM
        select GENERIC_IO
        default y



Bjørn
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [balbi-usb:xceiv 3/3] drivers/usb/phy/rcar-phy.c:75:3: error: implicit declaration of function 'iowrite32'

[Bjørn Mork]

Felipe Balbi <balbi@ti.com> writes:
> On Thu, Nov 01, 2012 at 11:06:58AM -0400, David Miller wrote:
>> From: Bjørn Mork <bjorn@mork.no>
>> Date: Thu, 01 Nov 2012 14:38:29 +0100
>> 
>> > Felipe Balbi <balbi@ti.com> writes:
>> > 
>> >> btw, only alpha and x86 seem to be providing all of those, but if you
>> >> look into our documentation, it's said that drivers are supposed to use
>> >> write/read{b,w,l,q} for all memory-mapped io. I'd expect all platforms
>> >> to provide those even if just to allow compilation of drivers.
>> > 
>> > Only if HAS_IOMEM is true, I believe.
>> 
>> This is correct.
>
> fair enough, then we can depend on HAS_IOMEM.
>
> Another question, if HAS_IOMEM is true, is the arch expected to provide
> *all* accessor methods ?

I'll leave this for those with more clue...

But there is a comment in arch/alpha/include/asm/io.h indicating that
writeq/readq support is tested separately, so I guess it must be
optional:

/*
 * Some mucking forons use if[n]def writeq to check if platform has it.
 * It's a bloody bad idea and we probably want ARCH_HAS_WRITEQ for them
 * to play with; for now just use cpp anti-recursion logics and make sure
 * that damn thing is defined and expands to itself.
 */

#define writeq writeq
#define readq readq


> And the last one: if the arch provides
> read/write{b,w,l,q}, should it be selecting HAS_IOMEM ??

But that one is easy: HAS_IOMEM is true by default.  The arch sets
NO_IOMEM to disable it. Similar to HAS_DMA.  So you can be pretty sure
that HAS_IOMEM is selected unless the arch has reasons not to.  From
lib/Kconfig:

config HAS_IOMEM
        boolean
        depends on !NO_IOMEM
        select GENERIC_IO
        default y



Bjørn