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@xxxxxxx>
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
