Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From:   Brad Larson <blarson@amd.com>
To:     <andy.shevchenko@gmail.com>
CC:     <adrian.hunter@intel.com>, <alcooperx@gmail.com>, <arnd@arndb.de>,
        <blarson@amd.com>, <brendan.higgins@linux.dev>,
        <briannorris@chromium.org>, <broonie@kernel.org>,
        <catalin.marinas@arm.com>, <conor+dt@kernel.org>,
        <davidgow@google.com>, <devicetree@vger.kernel.org>,
        <fancer.lancer@gmail.com>, <gerg@linux-m68k.org>,
        <gsomlo@gmail.com>, <hal.feng@starfivetech.com>,
        <hasegawa-hitomi@fujitsu.com>, <j.neuschaefer@gmx.net>,
        <joel@jms.id.au>, <kernel@esmil.dk>, <krzk@kernel.org>,
        <krzysztof.kozlowski+dt@linaro.org>, <lee.jones@linaro.org>,
        <lee@kernel.org>, <linux-arm-kernel@lists.infradead.org>,
        <linux-kernel@vger.kernel.org>, <linux-mmc@vger.kernel.org>,
        <linux-spi@vger.kernel.org>, <p.zabel@pengutronix.de>,
        <rdunlap@infradead.org>, <robh+dt@kernel.org>,
        <samuel@sholland.org>, <skhan@linuxfoundation.org>,
        <suravee.suthikulpanit@amd.com>, <thomas.lendacky@amd.com>,
        <tonyhuang.sunplus@gmail.com>, <ulf.hansson@linaro.org>,
        <vaishnav.a@ti.com>, <walker.chen@starfivetech.com>,
        <will@kernel.org>, <zhuyinbo@loongson.cn>
Subject: Re: [PATCH v14 8/8] soc: amd: Add support for AMD Pensando SoC Controller
Date:   Mon, 22 May 2023 19:12:56 -0700
Message-ID: <20230523021256.61690-1-blarson@amd.com>
In-Reply-To: <CAHp75VdsfcHOOUHuAVA38kdUyq+vwMKFYCNxScogGAJDM8ywBQ@mail.gmail.com>
References: <CAHp75VdsfcHOOUHuAVA38kdUyq+vwMKFYCNxScogGAJDM8ywBQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 May 2023 02:13:42.7873
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 199c5e3c-c56e-44cf-9d7e-08db5b3354e2
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource: DM6NAM11FT094.eop-nam11.prod.protection.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CYYPR12MB8892
X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,
        DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FORGED_SPF_HELO,
        RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_NONE,
        T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED autolearn=no autolearn_force=no
        version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Hi Andy,

On Tue, May 16, 2023 at 00:05:32 Andy Shevchenko <andy.shevchenko@gmail.com> wrote:
> On Mon, May 15, 2023 at 9:18 PM Brad Larson <blarson@amd.com> 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.
>
> ...
>
>> +#include <linux/cdev.h>
>> +#include <linux/device.h>
>> +#include <linux/err.h>
>> +#include <linux/init.h>
>> +#include <linux/mod_devicetable.h>
>> +#include <linux/module.h>
>> +#include <linux/mutex.h>
>
>> +#include <linux/of.h>
>
> Unneeded inclusion.

Removed

>> +#include <linux/reset-controller.h>
>> +#include <linux/spi/spi.h>
>
> ...
>
>
>> +       u8 tx_buf[PENCTRL_MAX_MSG_LEN];
>> +       u8 rx_buf[PENCTRL_MAX_MSG_LEN];
>
> Does it need to be DMA-capable?

Doesn't need to be DMA-capable

> ...
>
>> +       spi->chip_select = current_cs;
>> +       spi->cs_gpiod = spi->controller->cs_gpiods[current_cs];
>
> Nowadays these require API calls instead of direct assignments.

Changed to:
	spi_set_csgpiod(spi, 0, spi->controller->cs_gpiods[current_cs]);

> ...
>
>> +static int penctrl_release(struct inode *inode, struct file *filp)
>> +{
>> +       filp->private_data = NULL;
>> +       return 0;
>> +}
>
> Is it possible to unload the module without releasing the device node?

If the refcount is not zero the kernel prevents the module from being unloaded.

> ...
>
>> +       u8 txbuf[3];
>> +       u8 rxbuf[1];
>
> Same question about DMA.

Not DMA-capable

> ...
>
>> +       ret = spi_sync(spi, &m);
>
>> +       if (ret == 0)
>> +               *val = rxbuf[0];
>> +
>> +       return ret;
>
> Can also be written in more usual way:
>
>  if (ret)
>    return ret;
>  ...
>  return 0;

Yes, changed to:
        ret = spi_sync(spi, &m);
        if (ret)
                return ret;

        *val = rxbuf[0];
        return 0;

> ...
>
>> +       u8 txbuf[4];
>
> DMA?

Not DMA-capable

> ...
>
>> +       spi->chip_select = 0;
>> +       spi->cs_gpiod = spi->controller->cs_gpiods[0];
>
> Setter APIs.

Changed to:
	spi_set_csgpiod(spi, 0, spi->controller->cs_gpiods[0]);

>
> ...
>
>> +       spi->chip_select = 0;
>> +       spi->cs_gpiod = spi->controller->cs_gpiods[0];
>
> Ditto.

Changed to:
	spi_set_csgpiod(spi, 0, spi->controller->cs_gpiods[0]);

>> +       ret = device_property_read_u32(spi->dev.parent, "num-cs", &num_cs);
>> +       if (ret)
>> +               return dev_err_probe(&spi->dev, ret,
>> +                                    "number of chip-selects not defined\n");
>
> Hmm... Shouldn't SPI core take care of this in a generic way? Yes, I
> understand that you need the number for the allocation, but I would
> expect something like spi_fw_get_num_cs() to exist (seems not?).
>

No need to look into the parent node, changed to this:

        num_cs = spi->controller->num_chipselect;

> ...
>
>> +       penctrl->rcdev.of_node = spi->dev.of_node;
>
> Use device_set_node(). It helps to modify the data types beneath.

Added:
	device_set_node(penctrl->rcdev.dev, dev_fwnode(&spi->dev));

Regards,
Brad