From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from fout-a4-smtp.messagingengine.com (fout-a4-smtp.messagingengine.com [103.168.172.147]) (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 1C76F3630B6; Tue, 17 Mar 2026 09:50:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=103.168.172.147 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773741045; cv=none; b=Eh8hmf1bhM9wcgp0+TZwSSfK3Zumi3vDhydwWVXbLLDSmfSa30Gfu662lc9xt1vtcHk/iz/ywEoRxaF19UYqqnP2Qi6DaE/P8qggz0bbVJrEURx+UqEEVj78GM6ZRUkyFqNJnqcaoQ/TLICnPkuAJ3aPvL78Pe0k1UespwkBPQs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773741045; c=relaxed/simple; bh=oKvyNW/r9fOVfzt0pMIxQnO6P8WC7aGwQQO2eaTNeC8=; h=MIME-Version:Date:From:To:Cc:Message-Id:In-Reply-To:References: Subject:Content-Type; b=VHGvB0A2cfoqVIs0fhYZ1AIoNwt4VNq7mps0r/k9UaorAUpy+vO66mn3TfvgG24F1nI7oxfxdtCeGGBdA0TpIvCJIBk6aFchuDKTRGtsPkO+X6Ujvl5qCpUlwIDQDaGWJGX5GSHcQArgXX9YbY6v0+9VzDr9P00V7m58DavF+78= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arndb.de; spf=pass smtp.mailfrom=arndb.de; dkim=pass (2048-bit key) header.d=arndb.de header.i=@arndb.de header.b=j9izhecz; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b=Sphob5gh; arc=none smtp.client-ip=103.168.172.147 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arndb.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arndb.de Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=arndb.de header.i=@arndb.de header.b="j9izhecz"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="Sphob5gh" Received: from phl-compute-04.internal (phl-compute-04.internal [10.202.2.44]) by mailfout.phl.internal (Postfix) with ESMTP id 4E466EC00DD; Tue, 17 Mar 2026 05:50:42 -0400 (EDT) Received: from phl-imap-02 ([10.202.2.81]) by phl-compute-04.internal (MEProxy); Tue, 17 Mar 2026 05:50:42 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arndb.de; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm3; t=1773741042; x=1773827442; bh=5fLxoANUqctZUS+Z3Co69HqUNOcNosCE/Q8jVsqBBUg=; b= j9izheczf9aXHJ3ux1Ulk46cPvtmXGU6l5efH9OapXxeqAsXntGEdDL9qxCMXStG fkAGLeArjUnIc1TYDeDdzPKRN0fuAWkudgs/Ms1mFEQE4ktPc+z4ETtXoMD+NS4g Amb1DvREGwg737NlFYD+bHd1Rr+jp31cio2idHBrQ6Pxx3/kNBZEM+J1VYqXvku5 ZAuxAwazvXYjI9AXrlJxASnPrmfTOrDBlMspqpTflfASkF9vaxmAfCSLkweE+5+h WTBubjmgB0HA9w7lPlcGQgY22YVHWU4I3rHCZqawtwAXN3YZ5V6kQ/xp7kAs15Oz uCqL8oKfIBi9o/k/VFGpKw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1773741042; x= 1773827442; bh=5fLxoANUqctZUS+Z3Co69HqUNOcNosCE/Q8jVsqBBUg=; b=S phob5ghFn0DzHcEbtHEBV5Nllsaqn0xB7zZEmEtSv/6QFpFi9jsLW1o6PCgXLAAk 4oLzUYxc+yDp0+fDEqV7M7M+NCmdy4DY8Gb4UIj7KAwadWr9K1PJ99nXcnj8pYI8 rQDukuCasyugtvAfAHshMDm09awoOn3m844pFGd5P9UL9pR6JFWFGpFQJXxsiyLO eT2j/cIjOQpRlfHQXA9p+RwXmXaX4RXIKnIBddp6mUwtHjn6UKwiz5uJiJJwwyh1 vJqcCNX5LP3i+qhHKNVxFhbdNia9sC4eGyCt7bDcYSCZH9VKCWbHuE4pFuDbNCSv PQfr4Zmoga9Z1uSYNyk1Q== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefgedrtddtgdeftddtleefucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhepofggfffhvfevkfgjfhfutgfgsehtjeertdertddtnecuhfhrohhmpedftehrnhgu uceuvghrghhmrghnnhdfuceorghrnhgusegrrhhnuggsrdguvgeqnecuggftrfgrthhtvg hrnhepfefhheetffduvdfgieeghfejtedvkeetkeejfeekkeelffejteevvdeghffhiefh necuffhomhgrihhnpehkvghrnhgvlhdrohhrghenucevlhhushhtvghrufhiiigvpedtne curfgrrhgrmhepmhgrihhlfhhrohhmpegrrhhnugesrghrnhgusgdruggvpdhnsggprhgt phhtthhopeduiedpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtoheprhihrghnpggthh gvnhesrghsphgvvgguthgvtghhrdgtohhmpdhrtghpthhtohephihhpggthhhunhhgsegr shhpvggvughtvggthhdrtghomhdprhgtphhtthhopegrnhgurhgvfiestghouggvtghonh hsthhruhgtthdrtghomhdrrghupdhrtghpthhtohepmhgrtghivghjrdhlrgifnhhitgii rghksehinhhtvghlrdgtohhmpdhrtghpthhtohepjhhovghlsehjmhhsrdhiugdrrghupd hrtghpthhtohepsghrohhonhhivgeskhgvrhhnvghlrdhorhhgpdhrtghpthhtoheptgho nhhorhdoughtsehkvghrnhgvlhdrohhrghdprhgtphhtthhopegtohhnohhrsehkvghrnh gvlhdrohhrghdprhgtphhtthhopehkrhiikhdoughtsehkvghrnhgvlhdrohhrgh X-ME-Proxy: Feedback-ID: i56a14606:Fastmail Received: by mailuser.phl.internal (Postfix, from userid 501) id CE679700065; Tue, 17 Mar 2026 05:50:40 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-ThreadId: A224H4bSXjB- Date: Tue, 17 Mar 2026 10:50:10 +0100 From: "Arnd Bergmann" To: aspeedyh , "Andrew Jeffery" , "Conor Dooley" Cc: "Rob Herring" , "Krzysztof Kozlowski" , "Conor Dooley" , "Joel Stanley" , "Ryan Chen" , "Philipp Zabel" , "devicetree@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "linux-aspeed@lists.ozlabs.org" , "linux-kernel@vger.kernel.org" , "openbmc@lists.ozlabs.org" , "maciej.lawniczak@intel.com" , "Mark Brown" Message-Id: <0f7f0f96-a918-47d5-a0bd-bbde494c8fed@app.fastmail.com> In-Reply-To: References: <20260313-upstream_espi-v1-0-9504428e1f43@aspeedtech.com> <20260313-energy-casket-ca8adc1f1fd1@spud> <23909400-4e7f-49c9-a982-14036372af98@app.fastmail.com> Subject: Re: [PATCH 0/7] soc: aspeed: Add AST2600 eSPI controller support Content-Type: text/plain Content-Transfer-Encoding: 7bit On Tue, Mar 17, 2026, at 09:14, YH Chung wrote: > > In the meantime, my understanding is that this driver is for the Intel > eSPI interface used by the AST2600 BMC, > rather than fitting a conventional SPI controller/device model. That > was the reason for initially placing it under > drivers/soc/aspeed/, since there does not appear to be an in-tree eSPI > subsystem at present. > However, if that is not the preferred upstream direction, we are happy > to restructure the series accordingly. > It would be very helpful if you could advise on the preferred placement. I think we need to make sure everyone understands what the options are here based on what the hardware can do, and what your use cases require. >From reading the old comments that Andrew linked to at https://lore.kernel.org/linux-aspeed/HK0PR06MB377924CFCBFE9BD40E1C4A5D91D49@HK0PR06MB3779.apcprd06.prod.outlook.com/ I understand that the SoC has a "hardware mode" in which eSPI is directly implemented by redirecting upper-level eSPI transactions into functional blocks of the chip, while the software mode behaves like a regular SPI endpoint controller and your driver implements the same interfaces in a mix of kernel and userspace components. Can you confirm that this is a correct understanding of what the hardware does, or where I misunderstand parts? If I understood this correctly, I think there is a general agreement upstream that the low-level device access should indeed be in a drivers/spi driver, with no ports of it in drivers/soc/aspeed. Using a portable driver subsystem is always better than a custom solution if it works at all. For the higher-level interfaces (flash, gpio, ...), I don't think there is any consensus yet about how this should be done, but again I think this won't be drivers/soc but instead something more generic. One option here would be to sidestep this problem entirely by moving all of the eSPI implementation out of the kernel but instead have a hardware-independent userspace implementation that uses the spidev ioctl interface. This is always going to be slower than an in-kernel implementation, but also much easier to implement and debug. An in-kernel implementation of the eSPI backend (on top of the SPI layer) is certainly a realistic option for the higher layers, but requires finding consensus both on the the logistics (subsystem, code ownership, interfaces to other subsystems) and more importantly the user space interfaces that look like they will require several revisions on top of what you have today. Arnd