linux-kernel - Re: [PATCH v14 8/8] soc: amd: Add support for AMD Pensando SoC Controller

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <bc5118f2-8982-46ff-bc75-d0c71475e909@app.fastmail.com>
Date:   Tue, 16 May 2023 13:03:01 +0200
From:   "Arnd Bergmann" <arnd@...db.de>
To:     "Brad Larson" <blarson@....com>,
        linux-arm-kernel@...ts.infradead.org
Cc:     linux-kernel@...r.kernel.org,
        "linux-mmc @ vger . kernel . org" <linux-mmc@...r.kernel.org>,
        linux-spi@...r.kernel.org,
        "Adrian Hunter" <adrian.hunter@...el.com>, alcooperx@...il.com,
        "Andy Shevchenko" <andy.shevchenko@...il.com>,
        brendan.higgins@...ux.dev,
        "Brian Norris" <briannorris@...omium.org>,
        "Catalin Marinas" <catalin.marinas@....com>,
        "Conor Dooley" <conor+dt@...nel.org>,
        "David Gow" <davidgow@...gle.com>, gsomlo@...il.com,
        "Greg Ungerer" <gerg@...ux-m68k.org>,
        "Hal Feng" <hal.feng@...rfivetech.com>,
        "Hitomi Hasegawa" <hasegawa-hitomi@...itsu.com>,
        Jonathan Neuschäfer <j.neuschaefer@....net>,
        "Joel Stanley" <joel@....id.au>,
        "Emil Renner Berthing" <kernel@...il.dk>,
        "Krzysztof Kozlowski" <krzk@...nel.org>,
        krzysztof.kozlowski+dt@...aro.org, "Lee Jones" <lee@...nel.org>,
        "Lee Jones" <lee.jones@...aro.org>,
        "Mark Brown" <broonie@...nel.org>,
        "Philipp Zabel" <p.zabel@...gutronix.de>,
        "Randy Dunlap" <rdunlap@...radead.org>,
        "Rob Herring" <robh+dt@...nel.org>,
        "Samuel Holland" <samuel@...lland.org>,
        "Serge Semin" <fancer.lancer@...il.com>, skhan@...uxfoundation.org,
        suravee.suthikulpanit@....com,
        "Tom Lendacky" <thomas.lendacky@....com>,
        "Tony Huang" <tonyhuang.sunplus@...il.com>,
        "Ulf Hansson" <ulf.hansson@...aro.org>, vaishnav.a@...com,
        "Walker Chen" <walker.chen@...rfivetech.com>,
        "Will Deacon" <will@...nel.org>,
        "Yinbo Zhu" <zhuyinbo@...ngson.cn>, devicetree@...r.kernel.org
Subject: Re: [PATCH v14 8/8] soc: amd: Add support for AMD Pensando SoC Controller

On Mon, May 15, 2023, at 20:16, Brad Larson wrote:
> The Pensando SoC controller is a SPI connected companion device
> that is present in all Pensando SoC board designs.  The essential
> board management registers are accessed on chip select 0 with
> board mgmt IO support accessed using additional chip selects.
>
> Signed-off-by: Brad Larson <blarson@....com>

Hi Brad,

I'm sorry I wasn't paying enough attention to this driver as the
past 13 revisions went by.

> v10 changes:
> - Different driver implementation specific to this Pensando controller device.
> - Moved to soc/amd directory under new name based on guidance.  This driver is
>   of no use to any design other than all Pensando SoC based cards.
> - Removed use of builtin_driver, can be built as a module.

it looks like this was a fundamental change that I failed to see.

> +# SPDX-License-Identifier: GPL-2.0-only
> +menu "AMD Pensando SoC drivers"
> +
> +config AMD_PENSANDO_CTRL
> +	tristate "AMD Pensando SoC Controller"
> +	depends on SPI_MASTER=y
> +	depends on (ARCH_PENSANDO && OF) || COMPILE_TEST
> +	default ARCH_PENSANDO
> +	select REGMAP_SPI
> +	select MFD_SYSCON
> +	help
> +	  Enables AMD Pensando SoC controller device support.  This is a SPI
> +	  attached companion device in all Pensando SoC board designs which
> +	  provides essential board control/status registers and management IO
> +	  support.

So generally speaking, I don't want custom user interfaces in
drivers/soc. It looks like this one has internal interfaces for
a reset controller and the regmap, so those parts are fine, but
I'm confused about the purpose of the ioctl interface:

> +static long
> +penctrl_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
> +{

> +	if (num_msgs > 1) {
> +		msg++;
> +		if (msg->len > PENCTRL_MAX_MSG_LEN) {
> +			ret = -EINVAL;
> +			goto out_unlock;
> +		}
> +		t[1].rx_buf = rx_buf;
> +		t[1].len = msg->len;
> +	}
> +	spi_message_init_with_transfers(&m, t, num_msgs);

This seems to be just a passthrough of user space messages, which
is what the spidev driver already provides, but using a different
ioctl interface. I don't really want any user-level interfaces
in drivers/soc as a rule, but having one that duplicates existing
functionality seems particularly wrong.

Can you explain what the purpose is? Is this about serializing
access between the in-kernel reset control and the user-side
access?

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?

     Arnd