Received: by 2002:a05:7412:d024:b0:f9:90c9:de9f with SMTP id bd36csp167190rdb; Wed, 20 Dec 2023 09:00:27 -0800 (PST) X-Google-Smtp-Source: AGHT+IFDJ4TkfbofO1XDWp7KVFnqD3B76Bq4cz1DznjZt3za6FTm8i+3M6WBSRH9r4XTGbK6+0u0 X-Received: by 2002:a05:620a:1273:b0:77f:5332:d5c3 with SMTP id b19-20020a05620a127300b0077f5332d5c3mr19585433qkl.75.1703091626756; Wed, 20 Dec 2023 09:00:26 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1703091626; cv=none; d=google.com; s=arc-20160816; b=eEFpcXc9c+yLyxDyBA5K6ngBAVvxX6w9orTDAt/DOg3jWT6P1VVORvb8zz8LwNUySq +yoMY+7cLuS0hhQ7pefsSTXLNbPEiX68SrJbCP/axzRVHJ5l/sdhIOpHUd83+7C/lS0J lrvGfBsgckoTTkWZloskG7rnOXRu7cUleDce69rGhUqyjguiflKJ+NID+yucO7HSd2VR BcM8R/cYdFKs7gWV/btcHZdLEzZ7SioBco3pW7SnyTUfOQIEHYorsv705jLywVKsW407 P67Gk844tzPC6hPvlZ6IqQVBOvmqtVEA2I2AtLI2CLjsU8mscVp4WOThdxYilC+XbcKm 8SZQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=user-agent:in-reply-to:content-disposition:mime-version :list-unsubscribe:list-subscribe:list-id:precedence:references :message-id:subject:cc:to:from:date; bh=QbfiwtwLGpp1iejgNdpRgI6k5Z9e2Tht3zbwsqRp3U0=; fh=AYz6TFcaJy6kCmbCew8VH4afuVIYHLgyoCAQLf6aFWk=; b=hZoK4hzHOi89OGAXN4aIBVOisD9sPlaNliGAaD/Y/+seZs7wYxB2vA+nrivAopPXeb d+/UC2tovwzaQX3nqb9UdWEK/dKKwmryp5Dj9c0tIhrI8/FiCCrQkp1JBa5QjGo3IAE8 8gTzuiwkqMnKblzxHlEqCJevunxsUTzCZAxzU6YPAsMovoRnoxL93e/gG8SFRzDsfMTN GnuGXYwfHrD//QSzxkNRDoqNNXNExHDlewD4xvtnr3cMjbxpX3ok+C05osY0fvCyXf5s O7jH4l1OuQOIlBXGxu47k4ceHSnRrMO7ODe36G73id8VO392V/d3G7Z0+64iMNYUeK7c EDAA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel+bounces-7331-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-kernel+bounces-7331-linux.lists.archive=gmail.com@vger.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 k13-20020a05620a414d00b0077d58e69edfsi188379qko.233.2023.12.20.09.00.26 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 20 Dec 2023 09:00:26 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-7331-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; spf=pass (google.com: domain of linux-kernel+bounces-7331-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-kernel+bounces-7331-linux.lists.archive=gmail.com@vger.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 3FBCE1C20B83 for ; Wed, 20 Dec 2023 17:00:26 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 07FFD4777A; Wed, 20 Dec 2023 17:00:18 +0000 (UTC) X-Original-To: linux-kernel@vger.kernel.org Received: from bmailout1.hostsharing.net (bmailout1.hostsharing.net [83.223.95.100]) (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 9E60C4653E; Wed, 20 Dec 2023 17:00:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=wunner.de Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=h08.hostsharing.net Received: from h08.hostsharing.net (h08.hostsharing.net [83.223.95.28]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "*.hostsharing.net", Issuer "RapidSSL TLS RSA CA G1" (verified OK)) by bmailout1.hostsharing.net (Postfix) with ESMTPS id 4187730014241; Wed, 20 Dec 2023 18:00:12 +0100 (CET) Received: by h08.hostsharing.net (Postfix, from userid 100393) id 321F6324F8; Wed, 20 Dec 2023 18:00:12 +0100 (CET) Date: Wed, 20 Dec 2023 18:00:12 +0100 From: Lukas Wunner To: Patrick Williams Cc: Howard Chiu , robh+dt@kernel.org, joel@jms.id.au, andrew@aj.id.au, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-aspeed@lists.ozlabs.org, linux-kernel@vger.kernel.org, potin.lai@quantatw.com, Howard Chiu Subject: Re: [PATCH v8] ARM: dts: aspeed: Adding Facebook Bletchley BMC Message-ID: <20231220170012.GA10387@wunner.de> References: <20231220080733.GA30641@wunner.de> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) On Wed, Dec 20, 2023 at 06:38:59AM -0600, Patrick Williams wrote: > On Dec 20, 2023, at 2:07AM, Lukas Wunner wrote: > > On Tue, Dec 07, 2021 at 05:49:24PM +0800, Howard Chiu wrote: > > > Initial introduction of Facebook Bletchley equipped with > > > Aspeed 2600 BMC SoC. > > [...] > > > + tpmdev@0 { > > > + compatible = "tcg,tpm_tis-spi"; > > > > What's the chip used on this board? Going forward, the DT schema for TPMs > > requires the exact chip name in addition to the generic "tcg,tpm_tis-spi". > > Why is this a requirement? This assumes there is exactly one chip. > TPMs are often placed on a pluggable module in which multiple vendors > could be used. There is no way in the DTS to specify multiple compatible > chips. It seems to be a convention to provide the name of the chip that's actually used, in addition to the generic compatible. One advantage I see is that specific properties can be enforced per-chip. E.g. Infineon SLB9670 TPMs support an SPI clock of up to 43 MHz, whereas Atmel ATTPM20P support 36 MHz. The devicetree schema may contain those maximum speeds and the validator can check whether devicetrees observe them. Similarly, a device driver may use chip-specific quirks based on the compatible string. Last not least, it is useful for documentation purposes to specify which chip is used. If chips are dual-sourced or triple-sourced, as you say, and they behave identically, then I think it is fine to specify all of their compatible strings plus the generic compatible. If they do not behave identically, separate devicetrees should be used for each board version with a different chip. As for specifying the generic compatible last, this follows from section 2.3.1 of the devicetree specification: "The compatible property value consists of one or more strings that define the specific programming model for the device. This list of strings should be used by a client program for device driver selection. The property value consists of a concatenated list of null terminated strings, from most specific to most general." https://buildmedia.readthedocs.org/media/pdf/devicetree-specification/latest/devicetree-specification.pdf Thanks, Lukas