From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-11.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B5AB4C2D0A8 for ; Wed, 23 Sep 2020 16:57:10 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 34AB320BED for ; Wed, 23 Sep 2020 16:57:10 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="Ab5QFvSb"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="qc7i6qa4" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 34AB320BED Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linaro.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=Ul+32J5RAu7rfkzCU6mfE1kpAEfrXvMNjhLj3HvwDxw=; b=Ab5QFvSbLN7kkLQOhwrRhFuZS 3lsuqNsQN8nN2eU/V9UWAKQXBonS70zf2IwXVuvWr071ddRdAsuPR7Fo3zXcwuuruYyAUgeQkc450 PgFLLvDu0rZ6P5SHwqCJJwN4CcoicK4MLIOAnSG0ECsGqi/TQLkSTjPgIDBXUG367o671+cQDBq46 Y0PU0OVvB2k3JdDdqaRUlCjZhtipRbY0vBpaoFUxZLS0vr12+W6sA0uXS6xlAxHEhZYAaCYru+wo9 4fB2RiOvi/dlSyqbh6Yc45D3qysnJ7V+0CqdcXnu8fzShP1SfR7oAzWzhIUMqjZ8MtulatCsoe1Nl UuEjRovUQ==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kL83G-0000zj-K7; Wed, 23 Sep 2020 16:55:30 +0000 Received: from mail-ed1-x542.google.com ([2a00:1450:4864:20::542]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kL83C-0000zK-Ih for linux-arm-kernel@lists.infradead.org; Wed, 23 Sep 2020 16:55:27 +0000 Received: by mail-ed1-x542.google.com with SMTP id ay8so471980edb.8 for ; Wed, 23 Sep 2020 09:55:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dDv0qa/Cuby4V1jSKlMhAvu5ZDlcgFLWZenyhpW4DoI=; b=qc7i6qa46MyJUUBRhEUuVNMEivxlnygmI3d2ZVAqhDjsjtXAOGFqG5HG7u9mrGWG6Z C7i+pcFOIOYWae+flZR7yjclEifmRUCkQh8R2uPg9UG0ih2Y4sjh9N7X5bNHdAaa/JEF R5l16/7z3DQFlM8ZIDzuVFrFFVLzw0Yc0WdwQRDwyLCNNAG3M1Pocrbr2AQ4CjDJqBtx h7RBzG+I1dmiP/Fea2Eqv2O0J8Z2QS+4mrkJrkvrtlqMdeivfrDu8kaKUVM3+HSaZmmH FdCDCCW2bswr94KsatuKy97C1UzXawYKSK0TSZT1GmJxXJJXQ8BsJwpMQ+ChHlCqITM/ GEZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dDv0qa/Cuby4V1jSKlMhAvu5ZDlcgFLWZenyhpW4DoI=; b=m/0NV86vraBkRONiNhaqAVgto7ZdAikld1B4mT1bHTGLCQLMTJsSOk30jqDE/bzg+J du5y+3ckA8vq9uczFebZ31y81HOMjB/vshycTDA9LnYJdA9D6OsqYIOA7nh8hah+R8kq bfQKHmhMFPphlITgRQZjwr87riNcpjJXmKsk/0uhQDLJJV0g947iKXtdaISmWIjpAwhQ AuIVjun+uPz+Y0HyMVhVUXX7PwpAIKCLydnmHVeCfX6h1LK3qqiRlhqCTRwwDZfbaDJv N0wMd1LS8RCeRC8HqyxMQqPJWUk46qpsRJF685P1B+bG4GdT7s02GcHhBT97TOA6GPO8 8uQQ== X-Gm-Message-State: AOAM532bFSmfAnV6UflMvSDJCDY0LZKsoUlXHQhBcHfjMTFDnsN5ihmM 54COqEnAAWQYrOFQWddfnHCtoe76+14PIQJf88DllQ== X-Google-Smtp-Source: ABdhPJw4bILqg/Zu+tFbYEb2eTpezX8RFKtVoXCKhH8vZyrW4LRx8V3JM0/KYuuLa8yexATN2CuG4TQ0TgQ7JHMcmG0= X-Received: by 2002:a05:6402:70f:: with SMTP id w15mr277553edx.202.1600880123499; Wed, 23 Sep 2020 09:55:23 -0700 (PDT) MIME-Version: 1.0 References: <20200911084119.1080694-1-suzuki.poulose@arm.com> <20200911084119.1080694-19-suzuki.poulose@arm.com> <5092f3d7-0dfa-b4b0-6854-5ad861c8e657@arm.com> In-Reply-To: <5092f3d7-0dfa-b4b0-6854-5ad861c8e657@arm.com> From: Mike Leach Date: Wed, 23 Sep 2020 17:55:12 +0100 Message-ID: Subject: Re: [PATCH 18/19] coresight: etm4x: Add support for sysreg only devices To: Suzuki K Poulose X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200923_125526_913083_AF880941 X-CRM114-Status: GOOD ( 34.41 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Coresight ML , anshuman.khandual@arm.com, Mathieu Poirier , linux-arm-kernel , Leo Yan Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Suzuki, On Wed, 23 Sep 2020 at 12:47, Suzuki K Poulose wrote: > > Hi Mike > > On 09/18/2020 04:35 PM, Mike Leach wrote: > > Hi Suzuki, > > > > On Fri, 11 Sep 2020 at 09:41, Suzuki K Poulose wrote: > >> > >> Add support for devices with system instruction access only. > >> They don't have a memory mapped interface and thus are not > >> AMBA devices. > >> > >> Cc: Mathieu Poirier > >> Cc: Mike Leach > >> Signed-off-by: Suzuki K Poulose > >> --- > >> drivers/hwtracing/coresight/coresight-etm4x.c | 42 ++++++++++++++++++- > >> 1 file changed, 40 insertions(+), 2 deletions(-) > >> > >> diff --git a/drivers/hwtracing/coresight/coresight-etm4x.c b/drivers/hwtracing/coresight/coresight-etm4x.c > >> index 7d5f942c2108..212713ffa37e 100644 > >> --- a/drivers/hwtracing/coresight/coresight-etm4x.c > >> +++ b/drivers/hwtracing/coresight/coresight-etm4x.c > >> @@ -26,6 +26,7 @@ > >> #include > >> #include > >> #include > >> +#include > >> #include > >> #include > >> #include > >> @@ -1712,6 +1713,20 @@ static int etm4_probe_amba(struct amba_device *adev, const struct amba_id *id) > >> return ret; > >> } > >> > >> +static int etm4_probe_platform_dev(struct platform_device *pdev) > >> +{ > >> + int ret; > >> + > >> + pm_runtime_get_noresume(&pdev->dev); > >> + pm_runtime_set_active(&pdev->dev); > >> + pm_runtime_enable(&pdev->dev); > >> + > > > > Right about here is where I would expect the sysreg access to > > TRCDEVARCH etc, to determine if this is an ETM device that can be > > supported by the driver. > > This matches approximately the similar ID table checks that the AMBA > > driver did to ensure a valid device match. > > The problem is, we have to do this on the target CPU and later do another > one for feature check. > > > This logically separates "is this a device we support" from "what > > features does this supported device have" > The additional point is that it also keeps the register access specific code encapsulated in the register access specific area. The whole point of the access abstraction is that the common code just works. Is it not better that the access decision is made as early as possible and the access abstraction is set up, then the more code is common and maintenance is easier going forwards? > While I understand the logical argument, it doesn't buy us much. Even now we do an > additional check on the supported architecture in the etm4x_probe() anyway and reject > the unsupported CPUs there. I do question the value of that check. It's been around since the start of the driver, but perhaps has outlived its usefulness. Even in the AMBA memory mapped case, by the time we get there, we have matched the device based on supplied part numbers & binding information in the device tree, so checking 4 bits (major version number) out of a register does seem curious! If we have somehow got a bunch of other things wrong, there is a 1 in 16 chance that this check will fail too with a false positive. Obviously I can see why you wouldn't want to rely on just that to validate the component type for register access - DEVARCH is far better for that use case. The etmv3 version is a little more interesting - it checks 8 bits, both maj and min versions, with specific checks on 3.3, 3.5, 1.0 and 1.1 (pft), The remainder of the coresight drivers simply trust the part number detection mechanisms. Would it not be more consistent to do the same for ETMv4 as well? > The only change here is we move the supported architecture > check in to the etm4_init_arch_data() and stop the hard work if it is not supported. > > I would prefer to keep the current method if possible, while cleaning up the detection > of the supported (old) devices as agreed in the other patch. > > > Cheers > Suzuki Cheers Mike -- Mike Leach Principal Engineer, ARM Ltd. Manchester Design Centre. UK _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel