From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qk1-f172.google.com (mail-qk1-f172.google.com [209.85.222.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 725D447F761 for ; Thu, 20 Aug 2026 17:18:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.222.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787246334; cv=none; b=RbWRRX5ijiCjHtdvh8X4FzALxly9lRZi8z/TKFRqONagryYtk56hMdSzhv93jn09m2mZ/QnLwQtp2t13Q8caLFHlLJjb6RG+jFoEv09c2TiKp5H09QuLMWs3SoqQpMz5R88A1SKj84tloNh2YS8IG7ri9NYnTmhSs82FL1XQPaE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787246334; c=relaxed/simple; bh=sDIQ1vLsYFppGokpUhtjUe6z+MBWd9JK7GkUzlazqsQ=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=vETcNCf6avvlPjLYumNFNrqwLdF+2qQA8t1H8GStBqi6CGDbTHmzBAHJ9wHI2ZZ/Fc0/dFzW/jVAgA/M1eJugbfBH+uWWXNpJnWEylYG6bCeOCxvc5pQc6glX1U1uQOa3oWYmF8ReWLTrcmS1tpJxuDhbLlIZqhUt72Cvks5J3c= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=riscstar.com; spf=pass smtp.mailfrom=riscstar.com; dkim=pass (2048-bit key) header.d=riscstar-com.20251104.gappssmtp.com header.i=@riscstar-com.20251104.gappssmtp.com header.b=eB6hJXBq; arc=none smtp.client-ip=209.85.222.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=riscstar.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=riscstar.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=riscstar-com.20251104.gappssmtp.com header.i=@riscstar-com.20251104.gappssmtp.com header.b="eB6hJXBq" Received: by mail-qk1-f172.google.com with SMTP id af79cd13be357-936623c6dd3so80896485a.0 for ; Thu, 20 Aug 2026 10:18:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=riscstar-com.20251104.gappssmtp.com; s=20251104; t=1787246331; x=1787851131; darn=vger.kernel.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=IRMpkuU4HK2cX9MBfuMzYQo0OypqY8QmS/84hefJFZU=; b=eB6hJXBqsckOHJuZyi9K64sStQ8nr5UQ91s+Rd0dim6LH9LpMuBETf6fofRz9WQsZB rUZMuDSMX7xHxysqLXdh6pYGlbu/jRPMw8YhKhv/6PPjpg8Huo/+sAyyBEsVPWmtazeh wEBOsc0oHurLJ4wnW7zexk3AnyDzlJk71AEuxp4DEVuJUqg8gNbh1NzH+gGuA9ggd+zs mufBuB4UHmB8BL+IQOLYYFj2+d/rz4P/X430QQ+vTWWGjhrHCbX/1OSGuqZAPWHD9RlY a8wuR2XRX6ybsXy1DvKaj815/anApGc5X2B25/JEnYDhr77sgA4OhxnX1iOD+TFMkfrh MBSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787246331; x=1787851131; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=IRMpkuU4HK2cX9MBfuMzYQo0OypqY8QmS/84hefJFZU=; b=RbA4VWuYc9Y53Xxc8Hgoo4FiPTa3Uvhow5gZ7kao2xTsLtuidecbBrL/9uNnmcFGd+ cRXus1aSuHUr5yhQmLG42YbX23jyaJtIKx1aH1wC1Xo5xC/QDF1WZtZiWCNfzBPuKYtZ 5eQ/CD8qJTWqxbx9rN68tABf+BJLOuuyijgx7QoQZNEbeO1JckgVZPLoXsaxTgMDYzbZ ADN+/XB35Ba5DWWIn+HRF+pYdZxocDTA4s77WCP7t4iz3XKi9xdgQ6QAWKBuLXXScPr8 366Zqy9am12gGbtopwmWo0uDMQpjCuI3Z7vELHhUg2+wkuEZNesmNfSOdGe1Oom8vSMv +8Kw== X-Forwarded-Encrypted: i=1; AHgh+Rq9kFwKSBqv6nyevmHkCBnqf5YWfJwkDTyR1dVAK9ENWx5CduRaZrvfdX5GCOvUyZNoO7FF+gfAyn6BKxE=@vger.kernel.org X-Gm-Message-State: AOJu0Yw2XU/zjZIv86SgqSeK5PAzWXG+f/LwFB6hWaj3Vm5XqJvzzqgN /Q5UnXsS4VwMMmvRuguSCbK+fqsLRD5a5i8gF/kJeibbY0TBi36wtRf/tYqJ83lX6s4= X-Gm-Gg: AR+sD12t2NzHWVWI2Zx1FluyQnzJzzQcuBS2Btdty3vrN5CPe3OkWEeF00aKfcUlvp2 Sba6vxOwIBgkWc7L2qFfgpPnfmHOxs9I2AgHVQq4SYJPwdNyHzyvUVne0nXGJfGYa4Tnua0M3rZ ZzB8EHekiR0TByO4aRqYH3MO+4lfP20mM4Rn3h+1C+aTLT2VkKmwX/qwuXJwONR6wIYDNDbNVTw hXatYVkT5Nx0QyP24Is/YoSgKfCOSWXEKFIdrJ6Gwug2BgLfbj4HACRF1afgmd8X4KxFg+vSnDQ AM6swGab8R+bH4i4eHZeRILddBieNesXvqaYRmJQ3ZiY4zA6LxpVMP1zAF7wbHe7zMgSZrkqjxT dwkxU0po0G95BM+r3q+svvjnHqEyl98aUz4EuPl92z3hgj4K058MYEkKdgRRYVEszpbAlaX1CrO 2oyjJogiLF7xNPE9J/LKf+8DCyc8ViKRTea3liPnyOduPETyU6PmBrlMETVpm8 X-Received: by 2002:a05:620a:4887:b0:930:bd6c:9c32 with SMTP id af79cd13be357-9372849f086mr799219985a.12.1787246330439; Thu, 20 Aug 2026 10:18:50 -0700 (PDT) Received: from [172.22.22.28] ([73.62.185.64]) by smtp.gmail.com with ESMTPSA id af79cd13be357-937204a91b0sm418891185a.15.2026.08.20.10.18.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 20 Aug 2026 10:18:49 -0700 (PDT) Message-ID: Date: Thu, 20 Aug 2026 12:18:49 -0500 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/2] dt-bindings: misc: introduce pci1179,0220.yaml To: Krzysztof Kozlowski Cc: robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org, arnd@arndb.de, gregkh@linuxfoundation.org, bhelgaas@google.com, daniel@riscstar.com, mohdayaa@qti.qualcomm.com, lbiancon@qti.qualcomm.com, devicetree@vger.kernel.org, linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org References: <20260813222943.1655453-1-elder@riscstar.com> <20260813222943.1655453-2-elder@riscstar.com> <20260814-deft-unnatural-teal-1dbac3@quoll> <8c33e30a-e35e-47d4-a851-c82e18ed7472@riscstar.com> <55991af4-c613-4cde-a121-30f2ff9c8347@kernel.org> Content-Language: en-US From: Alex Elder In-Reply-To: <55991af4-c613-4cde-a121-30f2ff9c8347@kernel.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 8/17/26 1:18 AM, Krzysztof Kozlowski wrote: > On 14/08/2026 18:55, Alex Elder wrote: >> On 8/14/26 2:01 AM, Krzysztof Kozlowski wrote: >>> On Thu, Aug 13, 2026 at 05:29:41PM -0500, Alex Elder wrote: >>>> Define the binding for the Toshiba TC9564 PCI endpoint function device. >>>> The third downstream PCIe switch port within this chip has an embedded >>>> PCIe controller, and that implements two of these PCIe functions. >>>> >>>> Signed-off-by: Daniel Thompson >>>> Signed-off-by: Alex Elder >>>> --- >>>> .../bindings/misc/pci1179,0220.yaml | 150 ++++++++++++++++++ >>>> MAINTAINERS | 6 + >>>> 2 files changed, 156 insertions(+) >>>> create mode 100644 Documentation/devicetree/bindings/misc/pci1179,0220.yaml >>>> >>> >>> There are no properties in the binding except standard PCIe ones, so why >>> do you need it in DT in the first place? We do not describe PCI devices >>> in DT by default, so you are doing something unusual. Commit msg should >>> explain that. >> >> Maybe because it's using pci-ep-bus? I'm not sure I can answer your >> question though. > > What is pcie-ep bus? If a device is a PCI device (so not the host > bridge), we do not need to define it in DT except a few cases and this > does not look like one. It's a weird case because PCI has its own enumeration method, so there should no need to involve devicetree. Nevertheless the pci-ep-bus model *is* a devicetree thing related to PCI, describing devices accessible via PCI BARs. Documentation/devicetree/bindings/pci/pci-ep-bus.yaml It is used for the LAN966x SoC, however that driver loads the devicetree content dynamically using an overlay, and its overlay source is found under drivers/misc: drivers/misc/lan966x_pci.c drivers/misc/lan966x_pci.dtso This use of the LAN966x has no devicetree binding. The Raspberry Pi RP1 also uses pci-ep-bus. It, however does have a binding: Documentation/devicetree/bindings/misc/pci1de4,1.yaml >> An earlier version used auxiliary devices. This time the PCI device >> sort of stands by itself as provider of the endpoint buses that are >> used by other devices within the SoC. There is otherwise no single >> driver (e.g., for an Ethernet interface) that is implemented as a >> PCI driver to bind with the hardware. The SoC drivers will all be >> platform drivers. > > All this is driver explanation, so does not really answer my questions. > Whether something is using platform bus or auxiliary devices it > absolutely does not matter for the DT. It cannot even matter for DT. I understand what you're saying, and I do agree with you. Still, this is a strange case where the devicetree language is used to describe devices and properties that are not discoverable, using this pci-ep-bus devicetree *technique*. The core PCI functionality gets discovered in the usual PCI way (enumeration). But this allows additional hardware to be described. I think that if the devicetree language is used to describe hardware, having a binding to explain what's valid for that hardware description makes sense. As I understand it, for the LAN966x, the original use of the SoC used an internal processor to run Linux. So platform drivers for the devices within the SoC were created that matched with compatible strings, etc. Then in another mode, LAN966x is used as a PCI add-in card, and the pci-ep-bus allowed all of those other drivers to be used, unmodified. So anyway, pci-ep-bus is an odd situation. If the answer is "don't create a binding for this stuff, even if it gets defined in the devicetree file" then I'll accept that. But my instinct is that it's good to use a binding to describe what the DTS describing the hardware should look like (despite it being accessed using what amounts to a logical bus). -Alex > > Best regards, > Krzysztof