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=-5.9 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no 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 E0CC5C433ED for ; Sun, 9 May 2021 02:17:00 +0000 (UTC) Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (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 4B2F961364 for ; Sun, 9 May 2021 02:17:00 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4B2F961364 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=desiato.20200630; h=Sender:Content-Transfer-Encoding :Content-Type:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=0ewKb2sQTAuIaJgHOa0hLbGBU29lyB/WNUWdERpKk0A=; b=cgMKEj9Oezgx+RYogH7RwOc0h ThN4zfoS5AUUbjpuprEl4lE8OwwRQANNXNC5dIgX/y82rseJdhFg8k2YWGgMYGBuSrApmK2tQfd31 L6GdU+adMfAT2hP1kvxUL4N7UdK7/Jrin+4iv1879wr/S5rXUo6sf5+PfN9wpQE55bBOTMR4u85Ee Hc4lcf+j1Kvgl0rFBZLPZbiZB9F/RWG5oeutWPrURm/E+BVHDuSPZizHZj7kv5pQsAzliFN0kF5au gsZDc81fOs+oK1U2MsmbqzgupHGUsVGCd+MNtG58HwYKjEYzm6+rp6IS+mFj3DQhdxzP7wiDNo9am z0bm6f+Jg==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lfYyF-00AlhQ-7P; Sun, 09 May 2021 02:15:03 +0000 Received: from bombadil.infradead.org ([2607:7c80:54:e::133]) by desiato.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lfYyB-00Alh5-69 for linux-arm-kernel@desiato.infradead.org; Sun, 09 May 2021 02:15:00 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=In-Reply-To:Content-Type:MIME-Version :References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=Yo0KQvoiXvT8aOrdD5NF+kaz4eBGOnmZ/KNVCKPE7tc=; b=4lXDm1/+/JQdw48eD2Ytnu99hr zxD/JQ3B84aFdVaHN7KlWT+3YLZmv6emJaCMkq8r7U2nhO1nZpL61PWc2PKopkjDPZiHZqvK10EER JpnBZI3AeOrJrn3BI3vD21CHPH1qQi3semmeXkan9X3YPVxf2oWpE9PnseHMb6vf46d4tIElFKQyC FlH7AmBuqd7JIqrDx4O0hmNQ2LxuKAB8alH/eWNUmvaqMqNzh21+pBWfoJIUEzx+5UH0jyrcxT00Z chWtXwu/RqK/0H8SQj1ABg3jyqKdce0AFfB7wwsRR7AccXjNPBvngvNToRYbKwKgFmHpbsOv1iAxh 80vuuVQQ==; Received: from mail-pj1-x102a.google.com ([2607:f8b0:4864:20::102a]) by bombadil.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lfYy6-007oXu-UR for linux-arm-kernel@lists.infradead.org; Sun, 09 May 2021 02:14:56 +0000 Received: by mail-pj1-x102a.google.com with SMTP id md17so7880380pjb.0 for ; Sat, 08 May 2021 19:14:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=Yo0KQvoiXvT8aOrdD5NF+kaz4eBGOnmZ/KNVCKPE7tc=; b=mjxYMvW/+v9g3q+EnJujlRtxIAAnpJeF4PjKGr3m6DlcGUcwMQGyp5ei450aJx9Vn2 /TaosHSBCaZRQXeDmHfRT+veBFw3kjY5BIVtmoxF05rBCrW7GMw8JRc+WgSrpywhT8E9 U3dtSExDi9fvhapwA7AZd8DMYUiD3t6SMqfGXEGTJicqRRen/xfUV7ApgUtWmRKG3MS4 oxwJ9yLiS/9jdduY/OeUTJamGhhBAt+wsQBu31r+pdnWrX0ynx8OEA7byPUEF0ydenZE SFBM1wtiVXu02COjEkzoGR0pT139+/FSWCFY2YcH2ashUuRY8KWVjX0oPe9yTeFpCOQK VoSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=Yo0KQvoiXvT8aOrdD5NF+kaz4eBGOnmZ/KNVCKPE7tc=; b=uBkTg6DXph0YGd+RF7xbjQQKzO8bz5NLK/41l+YpF6CObWBcTWQNN6k5sNCT1RNrZo ZczO8LTrQmjOdylJB3jRRX1wcx62X2oPD081mQR+bngZHUv5Rz9yzROD3R5Cx+vlUfJt /yQ4lIQyBnIKkBBY4YCnMEbFT8I3xcuyaXaJNq0b5rW3lqH+Ka7MgfZAz8dutpdBFsSg lCmMnCAGMA8jlmxD82E/BzdCRjDOT8BVRpRPza/Lx+O1dZAK0nrb4R4wBwoSZkjKcHKg kMWpacitBB7qG4jbmW+mMANcVBDoY0O9tWyQrLt1UrlQ+L62r1iONzZGttbKHuSvJLuK h4gA== X-Gm-Message-State: AOAM5306AqcD5nyed34J/2/cKiejRMpF/m0m2UFHjbGx+pXJtLalJbf/ 0GJql2ocuDLQQRn4WkA57nQSYA== X-Google-Smtp-Source: ABdhPJy0ul308TSBzRKYuK9i3aBcixl6K5aFZ9TuP2H2bcxthK/ZEvIVgwwP7k0pJunw1xf0ampsZQ== X-Received: by 2002:a17:90b:3615:: with SMTP id ml21mr31833701pjb.28.1620526491111; Sat, 08 May 2021 19:14:51 -0700 (PDT) Received: from dragon (80.251.214.228.16clouds.com. [80.251.214.228]) by smtp.gmail.com with ESMTPSA id y13sm7952004pgs.93.2021.05.08.19.14.48 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Sat, 08 May 2021 19:14:50 -0700 (PDT) Date: Sun, 9 May 2021 10:14:44 +0800 From: Shawn Guo To: Robin Murphy Cc: Will Deacon , Bjorn Andersson , Lorenzo Pieralisi , Hanjun Guo , Sudeep Holla , Mark Rutland , linux-arm-kernel@lists.infradead.org, linux-arm-msm@vger.kernel.org Subject: Re: [PATCH v2 1/3] ACPI/IORT: Consolidate use of SMMU device platdata Message-ID: <20210509021443.GC8679@dragon> References: <20210402035602.9484-1-shawn.guo@linaro.org> <20210402035602.9484-2-shawn.guo@linaro.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210508_191455_015333_D5720E99 X-CRM114-Status: GOOD ( 29.36 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 On Tue, Apr 27, 2021 at 06:37:24PM +0100, Robin Murphy wrote: > On 2021-04-02 04:56, Shawn Guo wrote: > > Currently the platdata is being used in different way by SMMU and PMCG > > device. The former uses it for acpi_iort_node pointer passing, while > > the later uses it for model identifier. As it's been seen that the > > model identifier is useful for SMMU devices as well, let's consolidate > > the platdata use to get it accommodate both acpi_iort_node pointer and > > model identifier, so that all IORT devices (SMMU, SMMUv3 and PMCG) pass > > platdata in a consistent manner. > > > > With this change, model identifier is not specific to PMCG, so > > IORT_SMMU_V3_PMCG_GENERIC gets renamed to IORT_SMMU_GENERIC. While at > > it, the spaces used in model defines are converted to tabs. > > SMMUs and PMCGs are deliberately kept distinct because they are not > necessarily equivalent - a PMCG may belong to something other than an SMMU, > (like a root complex or a device with its own TLB), and even a single SMMU > may implement heterogeneous PMCGs (e.g. Arm's MMU-600 has PMCGs in its > control unit and TLB units which count different sets of events). So NAK to > that aspect, sorry. > > FWIW this was originally here because we envisaged needing to identify > individual PMCG implementations through a variety of poking at different > fields and tables, so hiding that behind an abstraction in ACPI code seemed > neatest. However, things haven't really panned out that way - now we seem to > have moved more towards describing events in userspace in conjunction with > other system-specific identifiers. If we've no need to identify PMCGs in the > kernel for the sake of exporting imp-def events, then most of the argument > for this PMCG identifier abstraction is gone, and it's looking increasingly > like the HIP08 case deserves to be punted back to the PMCG driver itself as > a one-off erratum workaround. > > I think at this point we should accept that if a driver needs to match > *some* platform-specific data for its own internal purposes, the fact that > that data might be the IORT header still doesn't make it "IORT > functionality", and referencing ACPI_SIG_IORT from drivers is a lesser evil > than cluttering up the IORT code with increasing amounts of random stuff > that's outside the scope of the IORT specification itself. Thanks much for the comments, Robin! Indeed, it makes more sense to sort the issue out in qcom driver than IORT code. v3 is on the way. Shawn _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel