From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932270AbcBPNYQ (ORCPT ); Tue, 16 Feb 2016 08:24:16 -0500 Received: from ni.piap.pl ([195.187.100.4]:49425 "EHLO ni.piap.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932212AbcBPNYO (ORCPT ); Tue, 16 Feb 2016 08:24:14 -0500 From: khalasa@piap.pl (Krzysztof =?utf-8?Q?Ha=C5=82asa?=) To: Arnd Bergmann Cc: linux-arm-kernel@lists.infradead.org, Felipe Balbi , Greg Kroah-Hartman , linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org, Felipe Balbi , Haojian Zhuang , Daniel Mack , Imre Kaloz , Robert Jarzmik Subject: Re: [PATCH 3/7] usb: gadget: pxa25x_udc: use readl/writel for mmio References: <1453997722-3489596-1-git-send-email-arnd@arndb.de> <4239208.KBB6rfivoa@wuerfel> <2702068.KRp0Bplb5Q@wuerfel> Date: Tue, 16 Feb 2016 14:24:10 +0100 In-Reply-To: <2702068.KRp0Bplb5Q@wuerfel> (Arnd Bergmann's message of "Tue, 16 Feb 2016 12:26:23 +0100") Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-KLMS-Rule-ID: 1 X-KLMS-Message-Action: clean X-KLMS-AntiSpam-Lua-Profiles: 91387 [Feb 16 2016] X-KLMS-AntiSpam-Version: 5.5.9.33 X-KLMS-AntiSpam-Envelope-From: khalasa@piap.pl X-KLMS-AntiSpam-Rate: 0 X-KLMS-AntiSpam-Status: not_detected X-KLMS-AntiSpam-Method: none X-KLMS-AntiSpam-Moebius-Timestamps: 3965241, 3965275, 3965100 X-KLMS-AntiSpam-Info: LuaCore: 414 414 652141367f63b6038f5642fa97308d3a9d2edb46, Auth:dkim=none X-KLMS-AntiSpam-Interceptor-Info: scan successful X-KLMS-AntiPhishing: Clean, 2016/02/15 14:33:11 X-KLMS-AntiVirus: Kaspersky Security 8.0 for Linux Mail Server, version 8.0.1.721, bases: 2016/02/16 06:30:00 #7174531 X-KLMS-AntiVirus-Status: Clean, skipped Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Arnd Bergmann writes: > Both writes leave the CPU core within the spinlock but are not serialized > with anything else, so there is no ordering between the CPUs when they > enter the shared bus, other than having address before data. You'd > expect to see address0, data0, address1, data1, but it could also > be e.g. address0, address1, data1, data0. Ah, so it's a matter of flushing the write buffers before exiting the spinlock-protected code. > The point is more what the common case is. Almost all machines we support > have fixed-endian devices, and the drivers are correct when using readl() > or in_le32() but are not endian-safe when using __raw_readl(). Sure, e.g. PCI does it this way (eventually swapping the data lanes if needed). > Using __raw_readl() has the big danger of someone accidentally "fixing" > the driver to work like all the others in order to solve a theoretical > endian problem, while it should really be made obvious that the hardware > actively swaps its data on the bus. Sure - if this is the case. On-chip IXP4xx peripherals don't swap data at all (i.e., they match CPU endianess) - accessing their registers is like accessing a normal CPU register. That's why they don't use PCI-style readl() etc. - however a better name than __raw_* would probably help here. Using __raw_* in a PCI driver would be generally wrong. -- Krzysztof Halasa Industrial Research Institute for Automation and Measurements PIAP Al. Jerozolimskie 202, 02-486 Warsaw, Poland