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-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
