From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752402AbcBEObR (ORCPT ); Fri, 5 Feb 2016 09:31:17 -0500 Received: from mout.kundenserver.de ([212.227.126.135]:65122 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751147AbcBEObP (ORCPT ); Fri, 5 Feb 2016 09:31:15 -0500 From: Arnd Bergmann To: linux-arm-kernel@lists.infradead.org Cc: Alexander Shishkin , Chunyan Zhang , mathieu.poirier@linaro.org, mark.rutland@arm.com, al.grant@arm.com, corbet@lwn.net, zhang.lyra@gmail.com, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, tor@ti.com, broonie@kernel.org, mike.leach@arm.com, linux-api@vger.kernel.org, Russell King , pratikp@codeaurora.org, nicolas.guion@st.com Subject: Re: [PATCH V2 6/6] coresight-stm: adding driver for CoreSight STM component Date: Fri, 05 Feb 2016 15:30:19 +0100 Message-ID: <1481791.6NqBhgWcKU@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: <87h9hn5msz.fsf@ashishki-desk.ger.corp.intel.com> References: <1454487337-30184-1-git-send-email-zhang.chunyan@linaro.org> <1454487337-30184-7-git-send-email-zhang.chunyan@linaro.org> <87h9hn5msz.fsf@ashishki-desk.ger.corp.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:ASMdjAa4hs2J7PiXOhGwzikh2ih3UhqSgICAiDMRm5pT7svaOqo 1+dYHur1ucmVA8ItFSAwnJSvwxBUlNO5wSRX41yrQG66zcDsQiY1b3xApOMYH0p9L9FG+s1 isZxQyJ1GTCrsSqMHcKaHR0mDQ/61zn8MENyVFd8g+dvZaol771meJBbOZAELnJrYFagDst 2AI/L7Glj6mttwYXJURAw== X-UI-Out-Filterresults: notjunk:1;V01:K0:I10RUXoovYI=:ZD3yCo3550BpT1BmXfcQFH AD138NJkbdZRWHd9cVA7TV19hFh8l2TAPJ9cP1cjMr6KcKVOM/sg2PDUWMnrjHC3sO0kzDGBo P6Of5QVCjF2yBLpDYfxqBmLIW0BzVmuxBhPp8aNtZbWNCL4dkBA9ibaBuDFYKPCVaSvneU28N h2G0CgE/F7OgSD4o6yKJk05+3i3a7ou+sVqPQDysGQujS3en1TcTQ72aDDdLIb/JRKSmyjI6x 8aP50hrFg0WCUu8hsA23elX6PVpEkrPQZjpJL08dkR9idkcfEcLb8eWG8jCMPp2AM6zw8RuM1 t+NmyJAOgmOHAqNxIv7vDVNK5pO6gxtPcCAeNkHVcf/Z6YTg2dwtNQ1oAouByh7CBuGNuybIo hLUhCDbnodQRA9qr6lO2XEKy8VZmKyuams16BxT+SekgUHuRenS0jtswgon/ty7Djr1gRtxZz e1bpBKwZz12heBsGnyAsrIajiJtPFhu5UOc2KPoMYdReWg1/fZ5xMKTzt7GWmQNTMdpngUbUA crZ5S6iF/rWgHjlBkJfP1zU16KMm+iia1bENpG7ICU7+KpV/ua0TcFpoThOAf3/M3Aiu8Irz3 sXGQH1zQH9aPiFiMvIGeS/AOsEiFVnWD7TFULElQClMBenXQ5JcLjznF2dh+lB5LkrrR4SC93 mhpcJBNbd3XZl4v8/iWldh6I/5/jNnt0ofzJQHcH4gpG/yBz9/Fm2TmnR2gCoOV5Rx5gzPEXa e8KPB/gfTJkLXuhd Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Friday 05 February 2016 15:06:20 Alexander Shishkin wrote: > Chunyan Zhang writes: > > > +#ifndef CONFIG_64BIT > > +static inline void __raw_writeq(u64 val, volatile void __iomem *addr) > > +{ > > + asm volatile("strd %1, %0" > > + : "+Qo" (*(volatile u64 __force *)addr) > > + : "r" (val)); > > +} > > Is it really ok to do this for all !64bit arms, inside a driver, just > like that? I'm not an expert, but I'm pretty sure there's more to it. It's normally device dependent whether this works or not, on 32-bit architectures, a 64-bit access to an I/O bus tends to get split into two 32 bit accesses and the order might not be the as what was intended. We have functions in include/linux/io-64-nonatomic-hi-lo.h and include/linux/io-64-nonatomic-lo-hi.h that are meant to do this right. Maybe the driver can be changed to use whichever one is correct for it. Arnd