From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qk1-f174.google.com (mail-qk1-f174.google.com [209.85.222.174]) (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 7F2D936D503 for ; Wed, 6 May 2026 22:41:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.222.174 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778107308; cv=none; b=n8cOOuCOD0eQIm544Q/Pw9jeoiVwrbWL3+Ttz3PwzmCldFSMHWWOUNHFFjhGVi4uqbpyRA0K1xHbwaMkAV67XuzdYXh8rDRvvLuY2k/rw2MOQiANqQuuW/AmalUUDoBMkGah56Mk3C2G91vdkZZe/H75RCQ/U5f0sN+IJ2jy6HY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778107308; c=relaxed/simple; bh=j2FRj+deFkHt2WLaAmO7r/2FVYSQVST0KS2E7oMmoXw=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=qeT/2p2tMhJQzRiOjOpmVLnfgUGjLP4GBWnXssHjr1uxBTPukvDBKn4hbsMOZPvp34BEUwcu1X89TfOyhaZLYvNcQCyv6eB5ZIsh1uzW1GBlWSrf9Ma0gBHKAfH9s9X7JmzpivZgYuTXwn6dFHgsDwoO/LNwKVZTkCo5JFQ02w4= 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=QLEzLtPn; arc=none smtp.client-ip=209.85.222.174 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="QLEzLtPn" Received: by mail-qk1-f174.google.com with SMTP id af79cd13be357-8ec37d52c0dso31493985a.0 for ; Wed, 06 May 2026 15:41:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=riscstar-com.20251104.gappssmtp.com; s=20251104; t=1778107305; x=1778712105; darn=vger.kernel.org; h=content-transfer-encoding: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; bh=cYpEI+XfMfA1fnjJlUUXbcclTkGZqiM6qT8lT03dl1A=; b=QLEzLtPnhE1dLbAV7ROfw46TtBAx80QhnwTBTtA2FmtA+LtfeWlGSeB695RHwhb+xF u5wQtnm1Iucl8JL8HnLepq0BPHfRN+ij+zpomS4mgCcJgQE7hFZeymodi3J5/zkyq8U5 m/xgdP5tT1m+S4DvK6EgTgXx2oPbJmE6skIZHAflAS0Ooh5X8maB8a1FJKO24HPldpay ScL7f7MEzuZQ1NJecMhDaZ60x8iT3vqcq29ttdkdaexCORpTSFGcqEVXZdmMLA3sxJ77 oWqpS+xVY2PkG08NQ9IDpkIZFYwoYKciES/P1sDKIoEzS8uK7fACaz4iD3Eqx1vCM5m9 acmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778107305; x=1778712105; h=content-transfer-encoding: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; bh=cYpEI+XfMfA1fnjJlUUXbcclTkGZqiM6qT8lT03dl1A=; b=KJ11uRYYs0APc7KyYp1vEFELIpJ+DERZNUquhAu6fpW+fHiTDtPLzfQD2bI88bUf+T OBs117fj42Q+/wYMkFgrSwcySuC6XlCtRYjfaSZpz9CxLdUNPYkRAvHFUjEOsXltiOj+ KirmW8O/IP3c7l9jxhgXHZddOr5m13ZxyQnq88qPGspc5Jx59aTJEQ/9kKRLNSVrQOa0 K1c1EwJYPrAEgoDAe37H6ByEeFV/som4cMZlsz2ZQL6qP2bFyCR/UAFNupG8KiTqb130 qv18nuQZeBVVMWfWF42gl7a/BszYUDGynH4aEgqKb1bYXCwAp81BYYsEckMRvIfHtE8d vVDA== X-Forwarded-Encrypted: i=1; AFNElJ+9p6KIStD4kCdFZwwR+AzRr165w+2g8Kxw2b5UByfrVGO4rB64NVV+bTCon4R8ZJj4AkCzvAqzMCBu@vger.kernel.org X-Gm-Message-State: AOJu0YwZN1V8//bb1Ezo7TOOmHDQP30482F19efininqbrq7HmHElvdU eqyF3QY1jKvzpzlkxzqsG6zDVmbvk8PGutzVJfDga4EsiYFTPRU8LYbsKmRaprL1R/E= X-Gm-Gg: AeBDietQhBKcDt3DD9eQyCBIlp6S0p80UpVxf4+l19s1jSgH3E2LjnOAFg2ps1j+yop qdY+ZafLziNXiqLGjA6cBsW5fB8G5l/yj8ms3kaDceivC/e2zJFzy5TTYwGtNIgxkei9hD8AMxy PFpfbgQuVwHCWXnZyyc/nqZL0pOGcQXBS9kZDYHcvNsxzdNSi5tGNW7eoBbi/5k3NTY3yliGpZI vD6Pnj9I9sM8OMYlzNwR9xQeDJDAGyzeRCYNThRSpf46daighbsa9BbL9SYowQxHKzKSraLVXu8 cxavBuEOXo2wBRIxTu0Go7F+qdYHxuM+q6dAwIa9TnWHyTfNaA0kz52IlH3AWQL0T1onhweSGFU 7ms4gKOGUANAGCMSNspKss4yfdAIn9xBUvz7rdyYdSPPn+v0n6bEEfcMcEUauW6EePI+W9aYi0S /BdMSRYfduxpU+zMARdE/NaB2xjgvyL6YVyJbR/m7ijGlB0VPzJQecEwGr2yWz+sUDn/imkPJLY +9wWDUjNTsX X-Received: by 2002:a05:620a:f0c:b0:8f1:9e59:220e with SMTP id af79cd13be357-904d63e7a90mr807845985a.39.1778107305508; Wed, 06 May 2026 15:41:45 -0700 (PDT) Received: from [172.22.22.28] (c-75-72-117-212.hsd1.mn.comcast.net. [75.72.117.212]) by smtp.gmail.com with ESMTPSA id af79cd13be357-8fc2cd06f16sm1787057085a.42.2026.05.06.15.41.42 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 06 May 2026 15:41:45 -0700 (PDT) Message-ID: <3e1b1859-2d02-41ce-838e-a0b7f4745d82@riscstar.com> Date: Wed, 6 May 2026 17:41:41 -0500 Precedence: bulk X-Mailing-List: devicetree@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH net-next 09/12] gpio: tc956x: add TC956x/QPS615 support To: Andrew Lunn Cc: andrew+netdev@lunn.ch, davem@davemloft.net, edumazet@google.com, kuba@kernel.org, pabeni@redhat.com, maxime.chevallier@bootlin.com, rmk+kernel@armlinux.org.uk, andersson@kernel.org, konradybcio@kernel.org, robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org, linusw@kernel.org, brgl@kernel.org, arnd@arndb.de, gregkh@linuxfoundation.org, daniel@riscstar.com, mohd.anwar@oss.qualcomm.com, a0987203069@gmail.com, alexandre.torgue@foss.st.com, ast@kernel.org, boon.khai.ng@altera.com, chenchuangyu@xiaomi.com, chenhuacai@kernel.org, daniel@iogearbox.net, hawk@kernel.org, hkallweit1@gmail.com, inochiama@gmail.com, john.fastabend@gmail.com, julianbraha@gmail.com, livelycarpet87@gmail.com, mcoquelin.stm32@gmail.com, me@ziyao.cc, prabhakar.mahadev-lad.rj@bp.renesas.com, richardcochran@gmail.com, rohan.g.thomas@altera.com, sdf@fomichev.me, siyanteng@cqsoftware.com.cn, weishangjuan@eswincomputing.com, wens@kernel.org, netdev@vger.kernel.org, bpf@vger.kernel.org, linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org, linux-gpio@vger.kernel.org, linux-stm32@st-md-mailman.stormreply.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org References: <20260501155421.3329862-1-elder@riscstar.com> <20260501155421.3329862-10-elder@riscstar.com> <736fb3b7-c88a-4ec4-96ad-d1b79cc48d30@lunn.ch> <30cec7dd-ac3c-47ab-896a-c29992bd5ba5@riscstar.com> <3666e3e6-e6f3-4cbf-b9fe-caa394fbab7c@lunn.ch> <0751a051-9894-45be-92d6-0d46f2c39293@riscstar.com> <7d7b6b89-3ef4-4891-a794-c8b11f39db34@lunn.ch> <79684efa-4ba9-4144-a99b-dab935007a2f@riscstar.com> Content-Language: en-US From: Alex Elder In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 5/6/26 4:43 PM, Andrew Lunn wrote: >> To be clear, the reason you're asking is that you're suggesting >> we might want to model the GPIO controller differently, correct? > > Correct. > >> I.e., model it as *not* associated with the embedded PCIe >> functions. Then we need to think about what its parent device >> would be (the power control device, which I think somehow >> duplicates the switch device?). > > Logically, the GPIO controller cannot be part of a downstream > function, if you need to use the GPIO controller to turn the > downstream function on. Yes you're right, though the PCIe power controller functions before the PCIe switch is enabled, and uses I2C to communicate with the host. > Logically, the GPIO controller needs to be above the switch downstream > end points. Where above, i don't know. Which is why i was asking about > where it appears in the address spaces. You are touching on an issue we have faced since we started on this earlier in the year. Our objective was to enable the eMACs, but there was no device representing the "chip" (which holds the switch and the GPIO controller, etc.). The TC956x is more than just a PCIe switch, and more than just two Ethernet MACs. The vendor code handles some of this between PCIe functions with some reference counting and perhaps other things. Eventually we settled on the model we have presented, which creates a device for each function and lets one of them take care of common "chip" things (including creating the GPIO auxiliary device). The function device driver creates a new auxiliary device to represent the MAC for each function. I also considered modeling the TC956x as a remoteproc, but have been reluctant to really pursue that. > But i also don't know too much about PCI, i'm used to SoCs with simple > linear MMIO. I'm no PCI expert either, but I'm learning. > From the little i know, it is more than what address space does the > GPIO appear in. Its also, what enumerable entity does it appear in > within the PCI bus. Because its the enumeration which is going to > trigger a driver load, which can then drive the GPIO controller. > > Or, something more radical, you make the PCIe power controller an MFD, > instantiating both the power controller and a GPIO controller over the > I2C bus. GPIO access will not be as fast, but is there anything here > which needs to be fast? I considered that, but opted not to mess with the PCIe power controller driver. It's only asserting resets in the RB3gen2, so I don't the speed is a major factor. -Alex > > Andrew