From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2166AC7EE2C for ; Wed, 24 May 2023 12:42:26 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231328AbjEXMmY (ORCPT ); Wed, 24 May 2023 08:42:24 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58918 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230316AbjEXMmY (ORCPT ); Wed, 24 May 2023 08:42:24 -0400 Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 626499E; Wed, 24 May 2023 05:42:22 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 953615C0115; Wed, 24 May 2023 08:42:19 -0400 (EDT) Received: from imap51 ([10.202.2.101]) by compute6.internal (MEProxy); Wed, 24 May 2023 08:42:19 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arndb.de; h=cc :cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:sender :subject:subject:to:to; s=fm3; t=1684932139; x=1685018539; bh=SF 9JtV1APOsCbo27SIShQg4r+s7H+woBcWqX/y1Cbdo=; b=MPX0qIkeYUH3javcr4 0T277eOhoLBvj5MGKRxXJIC40iN498Ia5AEtM3WBjzb1WA//1gxTFLvbdzApnw7d mRmcww6BJ2kmp/5HJfmi5V4VysoKZQOQkduOe+RT0ZKgAdsPnVCxGzDjaXcltVRP Iv+J8G/pSOpZTBJQ09PZE4pJTOw3Nh5GEPZrwK/x/Ji10UYampQOuumbfogMXTUH BbjRfAhyCvPbyU4JjPuLGMyu3OPs1L/XS7wah/8I1MneV0Xihice76gYF3MHnj17 kEbKC9cjnMLJOI4wYLRWJ1K09hbY+kD4RR0+VStyUxM9S84S9sTGxPguFxt9+Gbq qMNg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc: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:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; t=1684932139; x=1685018539; bh=SF9JtV1APOsCb o27SIShQg4r+s7H+woBcWqX/y1Cbdo=; b=GEkYChRQYQjJZWyxPqzR0Gap0m3Ek P7uW5ACiQUPHjYZDN4BpnBHUTrx7LYVvnG/j/LnSMLu+n0cyjxlE9l3SWzyVmo0G cOO/pu0PAK7dFF1oluUJf7om+KUHjXFA1RwMFBLO/987q4+KdSdTVh+zXLAaGnnL iJjjqbG/EdcW3dosu6RlHPFvhjGLP5CGyYZRL2IA6idCHY62WLZeSbh4Iecm2svE bREMasYi5OCbVTZVDm2tFhj3YN6fA6zJ8wrJXzDXBXZ9iehzwyFpeaP6IPzR3EB8 FOy3nRGEsEivNdxP2t+t3c5ya8XNnfKkJd9UlJssaPkyl6EnEcYi8WmqA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrfeejhedgheegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvfevufgtsehttdertderredtnecuhfhrohhmpedftehr nhguuceuvghrghhmrghnnhdfuceorghrnhgusegrrhhnuggsrdguvgeqnecuggftrfgrth htvghrnhepffehueegteeihfegtefhjefgtdeugfegjeelheejueethfefgeeghfektdek teffnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprg hrnhgusegrrhhnuggsrdguvg X-ME-Proxy: Feedback-ID: i56a14606:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 64F50B60086; Wed, 24 May 2023 08:42:17 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.9.0-alpha0-441-ga3ab13cd6d-fm-20230517.001-ga3ab13cd Mime-Version: 1.0 Message-Id: <787582a3-51a1-494e-bfd0-b51d1117432e@app.fastmail.com> In-Reply-To: <20230523221132.64464-1-blarson@amd.com> References: <20230523221132.64464-1-blarson@amd.com> Date: Wed, 24 May 2023 14:41:57 +0200 From: "Arnd Bergmann" To: "Brad Larson" Cc: "Adrian Hunter" , alcooperx@gmail.com, "Andy Shevchenko" , brendan.higgins@linux.dev, "Brian Norris" , "Mark Brown" , "Catalin Marinas" , "Conor Dooley" , "David Gow" , devicetree@vger.kernel.org, "Serge Semin" , "Greg Ungerer" , gsomlo@gmail.com, "Hal Feng" , "Hitomi Hasegawa" , =?UTF-8?Q?Jonathan_Neusch=C3=A4fer?= , "Joel Stanley" , "Emil Renner Berthing" , "Krzysztof Kozlowski" , krzysztof.kozlowski+dt@linaro.org, "Lee Jones" , "Lee Jones" , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, "linux-mmc @ vger . kernel . org" , linux-spi@vger.kernel.org, "Philipp Zabel" , "Randy Dunlap" , "Rob Herring" , "Samuel Holland" , skhan@linuxfoundation.org, suravee.suthikulpanit@amd.com, "Tom Lendacky" , "Tony Huang" , "Ulf Hansson" , vaishnav.a@ti.com, "Walker Chen" , "Will Deacon" , "Yinbo Zhu" Subject: Re: [PATCH v14 8/8] soc: amd: Add support for AMD Pensando SoC Controller Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-mmc@vger.kernel.org On Wed, May 24, 2023, at 00:11, Brad Larson wrote: >> On Mon, May 15, 2023, at 20:16, Brad Larson wrote: > >> Also, can you explain why this needs a low-lever user interface >> in the first place, rather than something that can be expressed >> using high-level abstractions as you already do with the reset >> control? >> >> All of the above should be part of the changelog text to get a >> driver like this merged. I don't think we can get a quick >> solution here though, so maybe you can start by removing the >> ioctl side and having the rest of the driver in drivers/reset? > > In the original patchset I added a pensando compatible to spidev and that > was nacked in review and reusing some random compatible that made it into > spidev was just wrong. Further it was recommended this should be a system > specific driver and don't rely on a debug driver like spidev. I changed > over to a platform specific driver and at that time I also needed to include > a reset controller (emmc reset only). I put these in drivers/mfd and > drivers/reset. Review of the device tree for this approach went back and > forth to _not_ have four child nodes on the spi device each with the same > compatible. Decision was to squash the child nodes into the parent and put > the reset-controller there also. One driver and since its pensando > specific its currently in drivers/soc/amd. > > There are five different user processes and some utilities that access the > functionality in the cpld/fpga. You're correct, its passing messages that > are specific to the IP accessed via chip-select. No Elba system will boot > without this driver providing ioctl access. Thank you for the detailed summary. Moving away from spidev and from mfd seems all reasonable here. I'm still a bit confused by why you have multiple chipselects here that are for different subdevices but ended with a single user interface for all of them, but that's not a big deal. The main bit that sticks out about this high-level design is how it relies on user space utilities at all to understand the message format. From what I understand about the actual functionality of this device, it most closely resembles an embedded controller that you might find in a laptop or server machine, and those usually have kernel drivers in drivers/platform/ to interact with the device. Has anyone tried to do it like that? Maybe it would help to see what the full protocol and the user space side looks like, in order to move some or all of it into the kernel. Arnd