Received: by 2002:a6b:500f:0:0:0:0:0 with SMTP id e15csp4832485iob; Mon, 9 May 2022 02:42:10 -0700 (PDT) X-Google-Smtp-Source: ABdhPJywK9sJk2PwUFQw49w/4h+P7wZOeKnXKLJkDhDzc8z8sIU9Am2HSGdvutFlB2/tddLD4MPS X-Received: by 2002:a17:90a:b10c:b0:1d9:49de:81c5 with SMTP id z12-20020a17090ab10c00b001d949de81c5mr17117700pjq.120.1652089330758; Mon, 09 May 2022 02:42:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1652089330; cv=none; d=google.com; s=arc-20160816; b=JyN6g+cOqf7OT8mjonp4xIMoAirYJdWKnzGfPZwLrcmZ02MugjgSbZmp8PDd0voLvP KHZEwlFRpg9ASZc7o5+GXknceUiDpTDNMNGG/xKTNlt9vg8aMdFWBr1gPsgQ6Ys0KNEz ex3uIjx0IOLF78BTfqXMIwogqYZl7ESr7d9p8qNx83M93B+ygVmiRHeVAELV5/o2mtMM Ctz3xS1eKl10UKykWmu2RPgNe4E9FsiteNJRcOhQTGJNy3ofvzX7P3uTBxLXpC61Csbm WMPZYKlPb9cj6w+55bcerzmFpS9/I2GWhqFIyqlnf6Bq5p8oM6PN5726FRCGBssCD10h dJOQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:subject:user-agent:mime-version:date:message-id; bh=zkr/ifEAGN2TsADaS7qwTWG+Ia565GD+7s65dmaxm+s=; b=I58ee5Jt2/PZgfcTEA42DsDfOUN2aCjltBsdU2L885XHQ+9twKorkyoERQ0jab2fgg HUGfZAsu3WlC3AuweMMJJR05xvmP+Nzm4Nrx+07x11e1DALtefpCPZ10mKc3BgLY8eWw POeWHsHSNrKufPX0z59iJ1aVpR/TrRhNzAmf6CW9R44kyKAlWN20SiR5fHtBFGHzfXPO GsP36kH0UKMnSaGiwJIqAQ2WJgh6QTjyO4IoVCIpr4H83efPIFuxqPFjZF4sSwu3sD7X CUEDWwNccvcYCnfa0G86POPfwHutYdXLHUJoyEvHqsELQJxwsMTGI6gjkKOX+ew/gcYU 9b1w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id g26-20020a63201a000000b003863b74af82si14149789pgg.393.2022.05.09.02.42.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 09 May 2022 02:42:10 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 263E115FE04; Mon, 9 May 2022 02:26:01 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1390514AbiEFJ0E (ORCPT + 99 others); Fri, 6 May 2022 05:26:04 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39784 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1390570AbiEFJZu (ORCPT ); Fri, 6 May 2022 05:25:50 -0400 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 8E1A169284; Fri, 6 May 2022 02:21:34 -0700 (PDT) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id CC3E9ED1; Fri, 6 May 2022 02:21:33 -0700 (PDT) Received: from [10.57.0.148] (unknown [10.57.0.148]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id C01AC3FA31; Fri, 6 May 2022 02:21:31 -0700 (PDT) Message-ID: <687b78b5-5671-5317-ce9e-98720bb533fa@arm.com> Date: Fri, 6 May 2022 10:21:30 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 Subject: Re: [PATCHv14 2/9] coresight: etm4x: Use asm-generic IO memory barriers To: Sai Prakash Ranjan , arnd@arndb.de, catalin.marinas@arm.com, rostedt@goodmis.org Cc: gregkh@linuxfoundation.org, linux-arm-kernel@lists.infradead.org, linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org, maz@kernel.org, quic_psodagud@quicinc.com, quic_tsoni@quicinc.com, will@kernel.org, Mathieu Poirier References: <0d76de0ecc0aa7cb01fd8b8863a8e567abd4410b.1651663123.git.quic_saipraka@quicinc.com> <483bb401-13e6-8c52-4b5f-f3c635b9ad46@arm.com> From: Suzuki K Poulose In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.0 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A, RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 06/05/2022 04:02, Sai Prakash Ranjan wrote: > Hi Suzuki, > > On 5/6/2022 5:14 AM, Suzuki K Poulose wrote: >> Hi, >> >> On 04/05/2022 12:28, Sai Prakash Ranjan wrote: >>> Per discussion in [1], it was decided to move to using architecture >>> independent/asm-generic IO memory barriers to have just one set of >>> them and deprecate use of arm64 specific IO memory barriers in driver >>> code. So replace current usage of __io_rmb()/__iowmb() in drivers to >>> __io_ar()/__io_bw(). >>> >>> [1] >>> https://lore.kernel.org/lkml/CAK8P3a0L2tLeF1Q0+0ijUxhGNaw+Z0fyPC1oW6_ELQfn0=i4iw@mail.gmail.com/ >>> >>> >> >> Looking at the dis-assembly it looks like in effect they are slightly >> different for arm64. >> >> i.e., before this patch we had >> >> "dmb osh{ld/st}" >> >> and after the patch we have : >> >> "dsb {ld/st}" >> >> Is this really what we want ? I don't think this is desirable. >> >> Suzuki >> > > No, this is not supposed to happen and I do not see how it could happen. > __io_ar() is defined as __iormb() and __io_bw() is __iowmb(). > > I checked the disassembly in both case with MMIO trace off/on with > __etm4_cpu_save() > as below and saw the same number of "dmb"s. > > aarch64-linux-gnu-gdb -batch -ex "disassemble/rs __etm4_cpu_save" > vmlinux-without-mmio > aarch64-linux-gnu-gdb -batch -ex "disassemble/rs __etm4_cpu_save" > vmlinux-with-mmio > > Can you tell me how are you validating if I am missing something? Apologies, I was missing the patch in this series, which adds the arm64 definition for __io_ar/__io_bw. (hint: Please Cc the affected subsystem in the Cover letter for the series, so we know what the intention of the changes are). With the patch1, yes this makes sense to me. Otherwise, __io_ar() is default to rmb() which implies dsb ld. With that said, Reviewed-by: Suzuki K Poulose