From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from codeconstruct.com.au (pi.codeconstruct.com.au [203.29.241.158]) (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 B37861C3BEB for ; Tue, 16 Jun 2026 00:16:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=203.29.241.158 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781568997; cv=none; b=lAoAEWTEMV4178Q7+q7Ye84Fsw6DiJ1p9OMEPlnmK5b4sT2t1ox11i0sPocJtBN/WyZyM4XVsO8GVHbJu9erBb0/vNRx1PRRnAqe4rwwushYVPpDRirE1rMDxWHlxYRTqSWmH8HI7rrIjqnK85vNg5Qt6MK34jMCgSOwj9XPU4c= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781568997; c=relaxed/simple; bh=RKUaFCacTQWmQr8n2TjbN4DQwtg9kdMWdI+WTObxrBA=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=XZgX7bcHISSj6FwC+TIJ3Skw+0rUleUinc4nRTmUDDA1FZzkArEGXBfsGOBKOo2U4w9R+7u9aFC0guGl+gatadl+BaWBI7cRrSxGBTF8owuLkgxrK8wMgxrMh2r0vWmeLV8mXGfeo3z7rQIUnHZPh6IaD8YLbi85JIvKGFnQ1i0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=codeconstruct.com.au; spf=pass smtp.mailfrom=codeconstruct.com.au; dkim=pass (2048-bit key) header.d=codeconstruct.com.au header.i=@codeconstruct.com.au header.b=QMI/IHg3; arc=none smtp.client-ip=203.29.241.158 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=codeconstruct.com.au Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=codeconstruct.com.au Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=codeconstruct.com.au header.i=@codeconstruct.com.au header.b="QMI/IHg3" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=codeconstruct.com.au; s=2022a; t=1781568987; bh=RKUaFCacTQWmQr8n2TjbN4DQwtg9kdMWdI+WTObxrBA=; h=Subject:From:To:Cc:Date:In-Reply-To:References; b=QMI/IHg3RKAmtHyfDwCfFr6Xt61lvSz8XYsLBaduQrmlCR0nvKeNRPKERL7At5v5D 7wlsCeyvSZikD3A4Xf1uDOqKm8vYDdBxzT5KOolMb1Wyv/m4M2YVa6HCeCkuC+xXIg VrX6sz3C/qUV20c3y31b8DjA/MDIS9QMX6MeUOhQ02e//CGxBoEGqtQ60b6HdmE6vF RFtbmNbJVI2RRKD3cmRv/BtpOP/JwvlTNyq+VCjbDr1RUM9MuJ854wQ6TAcn9wbAxH UrdOf5/kdPd2QeLEm8zgemaE5lm8mxMCmLp0L9LLlY/pgAT2O6dcG3yBkBUCL4kwAY AGcXesseuwIoQ== Received: from [192.168.68.117] (unknown [180.150.112.11]) by mail.codeconstruct.com.au (Postfix) with ESMTPSA id DE1786001B; Tue, 16 Jun 2026 08:16:24 +0800 (AWST) Message-ID: Subject: Re: [PATCH v2 1/2] soc: aspeed: add BMC-side PCIe BMC device driver From: Andrew Jeffery To: =?ISO-8859-1?Q?Gr=E9goire?= Layet Cc: joel@jms.id.au, andrew@lunn.ch, jacky_chou@aspeedtech.com, yh_chung@aspeedtech.com, ninad@linux.ibm.com, linux-aspeed@lists.ozlabs.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, anirudhsriniv@gmail.com Date: Tue, 16 Jun 2026 09:46:24 +0930 In-Reply-To: References: <4839c31f666b612799a795bb47c884901fd2a903.camel@codeconstruct.com.au> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.56.2-0+deb13u1 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 On Fri, 2026-06-12 at 11:21 +0200, Gr=C3=A9goire Layet wrote: > Hello Andrew, >=20 > Anirudh Srinivasan and I have found that IPMI over KCS using the > PCI worked with the stock ASPEED bmc driver (the bmc driver in the V1) > but not with the trimmed-down version in the V2. I have apparently remove= d > a bit too much from the V2 , but that's not what I want to focus on. Sure. >=20 > This brings back the question of where we should put the registers > configuration, > considering that two different functionalities depend on it. >=20 > > It is also possible to put the SCU initialisation on the > > 8250_aspeed_vuart driver > > directly. This could be activated with a specific flag added to VUART n= odes > > ('pcie2vuart' for example) on the DeviceTree. The concept sounds reasonable to me. There's probably some bikeshedding to do on the devicetree property though. >=20 > Similarly to this idea, we could include have the necessary configuration= in the > 'kcs_bmc_aspeed' driver. This could be activated using a similar flag > ,such as 'pci2lpc' > or 'pci2kcs' directly. However, this would result in a lot of code > duplication for most > of the configuration. Can you outline the duplication you're concerned about? I think it's a matter of resolving the SCU syscon to its regmap, then performing the necessary accesses? >=20 > The issue for me is that, two drivers configuring the same registers > is not a good idea. I think it's not as bad as you make it out to be. The SCU's regmap protects updates to individual registers under a lock, so concurrent modification isn't a concern. The hardware design choices make all of this slightly awkward for any related software design. As an alternative you could implement a mini subsystem that relevant drivers could call through to set the bits, but I currently think that's unnecessary work. Andrew