Received: by 2002:a05:7412:b995:b0:f9:9502:5bb8 with SMTP id it21csp7192700rdb; Wed, 3 Jan 2024 07:33:24 -0800 (PST) X-Google-Smtp-Source: AGHT+IFwiGpiQzevdcP3rJwuP6Cs1EO29z8TgPw4y7D/tM82SJLBV95yIrdaoI5k5XG6kpntUhlX X-Received: by 2002:a05:620a:5221:b0:781:ced5:cb96 with SMTP id dc33-20020a05620a522100b00781ced5cb96mr3184418qkb.58.1704296003814; Wed, 03 Jan 2024 07:33:23 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1704296003; cv=none; d=google.com; s=arc-20160816; b=blIqGXNenP3bTPYhnsoAutvwhHMQxTIJE/740DNhbEw4GP9r1b6EGkSqWkReiHxPU3 KUQV/oST4n9Xfn8bLCm76m3X4+a/WC0GBhKv0WgwV23/X+FiYwVHYMt9ALKkYMkfJrk/ BRahp5rTTENR64OLye2X8CsrV4snj87QaOlARWEssHEC6AA9jJ/IPxzWpQxRKAhD4QyY ML6pmB1bnMpNNJDMCT49bjt5HqTjO2Pj2efAL41A8m0NHdFiK10VE2o9OFEKjuIVJ3V/ topVExBS5w60uEd44M/TP2gQPpbqseffNiQlvAoPa50A+qwM86biH7GZg7fhT7buC8iX VmlQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:list-unsubscribe:list-subscribe :list-id:precedence:dkim-signature; bh=JVXPt20l7zebSe28/N3FLcKoWO8oltobpfgzlH5pFsA=; fh=Aoq/z+kR2pcnoc2sW9M8yK0Zd90VePE4uYc0V9wNS2A=; b=iAgFlHPm68lXp4mYEQyhk06DC4S1eeIfuahiMt6E0FuGFAjG046RmR7olMV8+lVY5D y6UzkBGINGMSihUIpM6yt7bbaBvfmlee2DQuLX2Ogm4TqEV9savZ+3vw/mKWGckB6hxL 2/G27+ocPpEIM4S29Huas+kEUZvRxvEJgOtrFbQsHyYNdGGpr95yBEvlKFxOs8TunZpT uaa9091N9KSeIJ0wSWXyNlVwMrEz2C/0wrWhz7byci6Hia1BrqvxoLfmQh6oLuOhEosa rlskO3v1KWiqMNWnwLbNlwCiaz3fFEuiUeBoQ8hZhrXi8WgbMdBHYBBZp06BHKHA59fq 3UFQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=TjFlJBc9; spf=pass (google.com: domain of linux-kernel+bounces-15702-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-kernel+bounces-15702-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [147.75.199.223]) by mx.google.com with ESMTPS id u16-20020a05620a431000b0078114cc3893si31169147qko.37.2024.01.03.07.33.23 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 03 Jan 2024 07:33:23 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-15702-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=TjFlJBc9; spf=pass (google.com: domain of linux-kernel+bounces-15702-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-kernel+bounces-15702-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ny.mirrors.kernel.org (Postfix) with ESMTPS id 7B9341C23754 for ; Wed, 3 Jan 2024 15:33:23 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id AF6FB1B272; Wed, 3 Jan 2024 15:33:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="TjFlJBc9" X-Original-To: linux-kernel@vger.kernel.org Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DE3C91A731; Wed, 3 Jan 2024 15:33:14 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 687F6C433CA; Wed, 3 Jan 2024 15:33:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1704295994; bh=ylV0o20b8JZnTMZTGmAwoeArfi4QzOCuKZgDMqvoNJY=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=TjFlJBc9PW4t3SSg0jjMYnP7ZBZ3NSK4uPJB6zJdetNcshf9E2pzqIfC7LlJDA646 nV188Fh81QBrP8XDzvxrLw4OviIkBO9S3veJ5mMD3tqFxy5ytUnn75DMyb6FQ6l7eu K7V8Am9mxJskpu73cjU118pYVg+aiYjKwDx/HhyjJzEGN8b+BXD2PRYRtRt4JZAWev WxOGjcrP8z6gyjsEQZVxtG2H/4MXauh31rItYgZx4Cf3Y6l6Z27d7nIkXrKKZCVfU1 zDw9e8mIAWUvV5WWbCawodLQ9WXHWDqggu26mMQgfIIeBUqHmPZ1Y8B3volvhOBd9h /MevTp/qY7GtA== Received: by mail-lj1-f174.google.com with SMTP id 38308e7fff4ca-2ccbf8cbf3aso99906301fa.3; Wed, 03 Jan 2024 07:33:14 -0800 (PST) X-Gm-Message-State: AOJu0YxD10vMHtmYL6rpGZCEidoRwa5l19RI10S+Oa6rSMX/28CAh4t8 kNy3dfFdQWeXZ677OpWqfkL3yckLBoRb5Juryg== X-Received: by 2002:a05:651c:11d3:b0:2cc:eae4:b3f6 with SMTP id z19-20020a05651c11d300b002cceae4b3f6mr4041154ljo.44.1704295992630; Wed, 03 Jan 2024 07:33:12 -0800 (PST) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <20231228093321.5522-1-quic_jinlmao@quicinc.com> <12ce6e5d-6e4d-fb99-eb82-dece97423bfb@arm.com> In-Reply-To: From: Rob Herring Date: Wed, 3 Jan 2024 08:32:56 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] coresight: Add coresight name support To: Mike Leach , Mao Jinlong Cc: James Clark , Suzuki K Poulose , coresight@lists.linaro.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org, Tingwei Zhang , Yuanfang Zhang , Tao Zhang , Leo Yan , Alexander Shishkin Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jan 2, 2024 at 5:05=E2=80=AFAM Mike Leach w= rote: > > As James mentions this is clearly a V2 of a previous patch - please > mark as such in future. > > Adding to what James has already said:- > > 1) Mapping between the canonical names used in the drivers and the > information as to the precise device is as easy as running 'ls' on > /sys/bus/coresight/devices:- > > root@linaro-developer:/home/linaro/cs-mods# ls -al /sys/bus/coresight/dev= ices/ > total 0 > drwxr-xr-x 2 root root 0 Jan 2 11:27 . > drwxr-xr-x 4 root root 0 Jan 2 11:27 .. > lrwxrwxrwx 1 root root 0 Jan 2 11:27 cti_cpu0 -> > ../../../devices/platform/soc@0/858000.cti/cti_cpu0 > lrwxrwxrwx 1 root root 0 Jan 2 11:27 cti_cpu1 -> > ../../../devices/platform/soc@0/859000.cti/cti_cpu1 > lrwxrwxrwx 1 root root 0 Jan 2 11:27 cti_cpu2 -> > ../../../devices/platform/soc@0/85a000.cti/cti_cpu2 > lrwxrwxrwx 1 root root 0 Jan 2 11:27 cti_cpu3 -> > ../../../devices/platform/soc@0/85b000.cti/cti_cpu3 > lrwxrwxrwx 1 root root 0 Jan 2 11:27 cti_sys0 -> > ../../../devices/platform/soc@0/810000.cti/cti_sys0 > lrwxrwxrwx 1 root root 0 Jan 2 11:27 cti_sys1 -> > ../../../devices/platform/soc@0/811000.cti/cti_sys1 > lrwxrwxrwx 1 root root 0 Jan 2 11:27 etm0 -> > ../../../devices/platform/soc@0/85c000.etm/etm0 > lrwxrwxrwx 1 root root 0 Jan 2 11:27 etm1 -> > ../../../devices/platform/soc@0/85d000.etm/etm1 > lrwxrwxrwx 1 root root 0 Jan 2 11:27 etm2 -> > ../../../devices/platform/soc@0/85e000.etm/etm2 > lrwxrwxrwx 1 root root 0 Jan 2 11:27 etm3 -> > ../../../devices/platform/soc@0/85f000.etm/etm3 > lrwxrwxrwx 1 root root 0 Jan 2 11:42 funnel0 -> > ../../../devices/platform/soc@0/821000.funnel/funnel0 > lrwxrwxrwx 1 root root 0 Jan 2 11:42 funnel1 -> > ../../../devices/platform/soc@0/841000.funnel/funnel1 > lrwxrwxrwx 1 root root 0 Jan 2 11:42 replicator0 -> > ../../../devices/platform/soc@0/824000.replicator/replicator0 > lrwxrwxrwx 1 root root 0 Jan 2 11:42 tmc_etf0 -> > ../../../devices/platform/soc@0/825000.etf/tmc_etf0 > lrwxrwxrwx 1 root root 0 Jan 2 11:42 tmc_etr0 -> > ../../../devices/platform/soc@0/826000.etr/tmc_etr0 > > > 2) The patch set must contain the usage and specification in the .yaml > file(s) of the property used. For the record, I don't like "coresight-name". I don't have another suggestion because "easy" is not sufficient reasoning for why this is needed. > However, there was a standard property called 'name' which is > deprecated - see > https://devicetree-specification.readthedocs.io/en/latest/chapter2-device= tree-basics.html > section 2.3.11. I do not believe that adding another 'name' property > would be accepted by the DT maintainers. "name" is just the node name for anything in the last 15 years. They used to be separate, but would still mostly be the same. The only case I found with them different was old PowerPC Macs. > 3) the 'device_node' structure has a 'name' field that contains the > node name in the DT approved "node-name@unit-address" format. Actually, it is without the unit-address. full_name is with the unit-addres= s. > This > contains whatever node names you used in the dt. Why not use this if > a change has to be made and find some conditional to activate it. Don't go accessing "name" or "full_name" directly. I intend to get rid of "name" and generate it from full_name. So use the accessors and printk specifiers if you need node names. Rob