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 v16 6/6] soc: amd: Add support for AMD Pensando SoC Controller
Date: Tue, 26 Sep 2023 13:05:41 -0700 [thread overview]
Message-ID: <20230926200541.35787-1-blarson@amd.com> (raw)
In-Reply-To: <CAHp75VfRLv1=3M+a9pr=ZJgNwtBOrT9xi0UjDJMuY8uM9+ffSw@mail.gmail.com>
Hi Andy,
On Thu, Sep 21, 2023 at 18:19:57 +0300 Andy Shevchenko <andy.shevchenko@gmail.com> wrote:
> On Thu, Sep 14, 2023 at 12:52 AM 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/fs.h>
>> +#include <linux/init.h>
>> +#include <linux/miscdevice.h>
>> +#include <linux/mod_devicetable.h>
>> +#include <linux/module.h>
>> +#include <linux/mutex.h>
>> +#include <linux/reset-controller.h>
>> +#include <linux/spi/spi.h>
>
> types.h ?
I'll add types.h
>> +#include <linux/uaccess.h>
...
>> + struct penctrl_device *penctrl;
>
>> + u8 tx_buf[PENCTRL_MAX_MSG_LEN];
>> + u8 rx_buf[PENCTRL_MAX_MSG_LEN];
>
> These are not DMA-safe, is this a problem?
It's not a problem, the peripheral is PIO FIFO driven only.
>> + struct spi_transfer t[2] = {};
>> + struct penctrl_spi_xfer *msg;
>> + struct spi_device *spi;
>> + unsigned int num_msgs;
>> + struct spi_message m;
>> + u32 size;
>> + int ret;
...
>> + /* Verify and prepare SPI message */
>> + size = _IOC_SIZE(cmd);
>> + num_msgs = size / sizeof(struct penctrl_spi_xfer);
>
> sizeof (*msg) ?
Yes, more compact for here and below.
>
>> + if (num_msgs > 2 || size == 0 || size % sizeof(struct penctrl_spi_xfer)) {
>
> Dito.
>
>> + ret = -EINVAL;
>> + goto out_unlock;
>> + }
...
>> + msg = memdup_user((struct penctrl_spi_xfer *)arg, size);
>> + if (IS_ERR(msg)) {
>> + ret = PTR_ERR(msg);
>> + goto out_unlock;
>> + }
>
> Wondering if you can start using cleanup.h.
Perhaps if recommended, I don't see DEFINE_(FREE,UNLOCK,...) being used.
...
>> + /* Perform the transfer */
>> + mutex_lock(&spi_lock);
>> + ret = spi_sync(spi, &m);
>> + mutex_unlock(&spi_lock);
>> + if (ret || (num_msgs == 1))
>> + goto out_unlock;
>
> Second conditional will return 0. Is it by design?
> Since it's not so obvious I would split these conditionals.
I'll split this to be clear, yes return 0 for success.
...
>> + spi->chip_select = current_cs;
>
> spi_set_chipselect()
Yes, I'll change to inline function spi_set_chipselect(spi, 0, current_cs). The
second arg must be legacy as its unused.
...
>> +static int penctrl_regs_read(struct penctrl_device *penctrl, u32 reg, u32 *val)
>> +{
>> + struct spi_device *spi = penctrl->spi;
>> + struct spi_transfer t[2] = {};
>> + struct spi_message m;
>
>> + u8 txbuf[3];
>> + u8 rxbuf[1];
>
> Not DMA-safe. Is it a problem?
>
Not a problem, the peripheral is PIO only using FIFOs.
>> + int ret;
>
>> + txbuf[0] = PENCTRL_SPI_CMD_REGRD;
>> + txbuf[1] = reg;
>> + txbuf[2] = 0;
>
> Can be assigned in the definition block
>
> u8 txbuf[] = { ... };
>
I'll change that here and below.
>> + t[0].tx_buf = txbuf;
>> + t[0].len = sizeof(txbuf);
>
>> + rxbuf[0] = 0;
>
> Ditto.
>
> u8 rxbuf[] = { 0 };
>
>> + t[1].rx_buf = rxbuf;
>> + t[1].len = sizeof(rxbuf);
>> +
>> + spi_message_init_with_transfers(&m, t, ARRAY_SIZE(t));
>> + ret = spi_sync(spi, &m);
>> + if (ret)
>> + return ret;
>> +
>> + *val = rxbuf[0];
>> + return 0;
>> +}
...
>> +static int penctrl_regs_write(struct penctrl_device *penctrl, u32 reg, u32 val)
>> +{
>> + struct spi_device *spi = penctrl->spi;
>> + struct spi_transfer t = {};
>> + struct spi_message m;
>> + u8 txbuf[4];
>> + txbuf[0] = PENCTRL_SPI_CMD_REGWR;
>> + txbuf[1] = reg;
>> + txbuf[2] = val;
>> + txbuf[3] = 0;
> Can be assigned in the definition block.
>> + t.tx_buf = txbuf;
>> + t.len = sizeof(txbuf);
>> + spi_message_init_with_transfers(&m, &t, 1);
>> + return spi_sync(spi, &m);
>> +}
...
>> + struct penctrl_device *penctrl =
>> + container_of(rcdev, struct penctrl_device, rcdev);
>
> One line?
I'll check/change.
>
>...
>
>> + spi->chip_select = 0;
>
> spi_set_chipselect()
Yes, spi_set_chipselect(spi, 0, 0);
...
>> + struct penctrl_device *penctrl =
>> + container_of(rcdev, struct penctrl_device, rcdev);
>
> One line?
I'll check/change.
...
>> + spi->chip_select = 0;
>
> spi_set_chipselect()
Yes, spi_set_chipselect(spi, 0, 0);
...
>> +static int penctrl_spi_probe(struct spi_device *spi)
>> +{
>> + int i, ret;
>> +
>> + /* Allocate driver data */
>> + penctrl = kzalloc(sizeof(*penctrl), GFP_KERNEL);
>
> devm_kzalloc() ?
Yes will change to devm_kzalloc().
>> + if (!penctrl)
>> + return -ENOMEM;
>> +
>> + penctrl->spi = spi;
>> + mutex_init(&spi_lock);
>> +
>> + for (i = 0; i < ARRAY_SIZE(penctrl_devices); i++) {
>> + ret = misc_register(&penctrl_devices[i]);
>> + if (ret) {
>> + dev_err(&spi->dev, "Failed to register device %s\n",
>> + penctrl_devices[i].name);
>> + goto cleanup;
>> + }
>> + }
>> +
>> + /* Register reset controller */
>> + penctrl->rcdev.dev = &spi->dev;
>> + penctrl->rcdev.ops = &penctrl_reset_ops;
>> + penctrl->rcdev.owner = THIS_MODULE;
>> + penctrl->rcdev.of_node = spi->dev.of_node;
>> + penctrl->rcdev.nr_resets = 1;
>> + device_set_node(penctrl->rcdev.dev, dev_fwnode(&spi->dev));
>> +
>> + ret = reset_controller_register(&penctrl->rcdev);
>> + if (ret)
>> + return dev_err_probe(&spi->dev, ret,
>> + "failed to register reset controller\n");
>> + return 0;
>
>> +cleanup:
>
> err_cleanup: ?
Will use err_cleanup:
>> + for (i = 0; i < ARRAY_SIZE(penctrl_devices); i++) {
>
> while (i--) {
>
Yes, can change to while(), order doesn't matter.
>> + if (penctrl_devices[i].this_device)
>> + misc_deregister(&penctrl_devices[i]);
>> + }
>> + return ret;
>> +}
Regards,
Brad
WARNING: multiple messages have this Message-ID (diff)
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 v16 6/6] soc: amd: Add support for AMD Pensando SoC Controller
Date: Tue, 26 Sep 2023 13:05:41 -0700 [thread overview]
Message-ID: <20230926200541.35787-1-blarson@amd.com> (raw)
In-Reply-To: <CAHp75VfRLv1=3M+a9pr=ZJgNwtBOrT9xi0UjDJMuY8uM9+ffSw@mail.gmail.com>
Hi Andy,
On Thu, Sep 21, 2023 at 18:19:57 +0300 Andy Shevchenko <andy.shevchenko@gmail.com> wrote:
> On Thu, Sep 14, 2023 at 12:52 AM 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/fs.h>
>> +#include <linux/init.h>
>> +#include <linux/miscdevice.h>
>> +#include <linux/mod_devicetable.h>
>> +#include <linux/module.h>
>> +#include <linux/mutex.h>
>> +#include <linux/reset-controller.h>
>> +#include <linux/spi/spi.h>
>
> types.h ?
I'll add types.h
>> +#include <linux/uaccess.h>
...
>> + struct penctrl_device *penctrl;
>
>> + u8 tx_buf[PENCTRL_MAX_MSG_LEN];
>> + u8 rx_buf[PENCTRL_MAX_MSG_LEN];
>
> These are not DMA-safe, is this a problem?
It's not a problem, the peripheral is PIO FIFO driven only.
>> + struct spi_transfer t[2] = {};
>> + struct penctrl_spi_xfer *msg;
>> + struct spi_device *spi;
>> + unsigned int num_msgs;
>> + struct spi_message m;
>> + u32 size;
>> + int ret;
...
>> + /* Verify and prepare SPI message */
>> + size = _IOC_SIZE(cmd);
>> + num_msgs = size / sizeof(struct penctrl_spi_xfer);
>
> sizeof (*msg) ?
Yes, more compact for here and below.
>
>> + if (num_msgs > 2 || size == 0 || size % sizeof(struct penctrl_spi_xfer)) {
>
> Dito.
>
>> + ret = -EINVAL;
>> + goto out_unlock;
>> + }
...
>> + msg = memdup_user((struct penctrl_spi_xfer *)arg, size);
>> + if (IS_ERR(msg)) {
>> + ret = PTR_ERR(msg);
>> + goto out_unlock;
>> + }
>
> Wondering if you can start using cleanup.h.
Perhaps if recommended, I don't see DEFINE_(FREE,UNLOCK,...) being used.
...
>> + /* Perform the transfer */
>> + mutex_lock(&spi_lock);
>> + ret = spi_sync(spi, &m);
>> + mutex_unlock(&spi_lock);
>> + if (ret || (num_msgs == 1))
>> + goto out_unlock;
>
> Second conditional will return 0. Is it by design?
> Since it's not so obvious I would split these conditionals.
I'll split this to be clear, yes return 0 for success.
...
>> + spi->chip_select = current_cs;
>
> spi_set_chipselect()
Yes, I'll change to inline function spi_set_chipselect(spi, 0, current_cs). The
second arg must be legacy as its unused.
...
>> +static int penctrl_regs_read(struct penctrl_device *penctrl, u32 reg, u32 *val)
>> +{
>> + struct spi_device *spi = penctrl->spi;
>> + struct spi_transfer t[2] = {};
>> + struct spi_message m;
>
>> + u8 txbuf[3];
>> + u8 rxbuf[1];
>
> Not DMA-safe. Is it a problem?
>
Not a problem, the peripheral is PIO only using FIFOs.
>> + int ret;
>
>> + txbuf[0] = PENCTRL_SPI_CMD_REGRD;
>> + txbuf[1] = reg;
>> + txbuf[2] = 0;
>
> Can be assigned in the definition block
>
> u8 txbuf[] = { ... };
>
I'll change that here and below.
>> + t[0].tx_buf = txbuf;
>> + t[0].len = sizeof(txbuf);
>
>> + rxbuf[0] = 0;
>
> Ditto.
>
> u8 rxbuf[] = { 0 };
>
>> + t[1].rx_buf = rxbuf;
>> + t[1].len = sizeof(rxbuf);
>> +
>> + spi_message_init_with_transfers(&m, t, ARRAY_SIZE(t));
>> + ret = spi_sync(spi, &m);
>> + if (ret)
>> + return ret;
>> +
>> + *val = rxbuf[0];
>> + return 0;
>> +}
...
>> +static int penctrl_regs_write(struct penctrl_device *penctrl, u32 reg, u32 val)
>> +{
>> + struct spi_device *spi = penctrl->spi;
>> + struct spi_transfer t = {};
>> + struct spi_message m;
>> + u8 txbuf[4];
>> + txbuf[0] = PENCTRL_SPI_CMD_REGWR;
>> + txbuf[1] = reg;
>> + txbuf[2] = val;
>> + txbuf[3] = 0;
> Can be assigned in the definition block.
>> + t.tx_buf = txbuf;
>> + t.len = sizeof(txbuf);
>> + spi_message_init_with_transfers(&m, &t, 1);
>> + return spi_sync(spi, &m);
>> +}
...
>> + struct penctrl_device *penctrl =
>> + container_of(rcdev, struct penctrl_device, rcdev);
>
> One line?
I'll check/change.
>
>...
>
>> + spi->chip_select = 0;
>
> spi_set_chipselect()
Yes, spi_set_chipselect(spi, 0, 0);
...
>> + struct penctrl_device *penctrl =
>> + container_of(rcdev, struct penctrl_device, rcdev);
>
> One line?
I'll check/change.
...
>> + spi->chip_select = 0;
>
> spi_set_chipselect()
Yes, spi_set_chipselect(spi, 0, 0);
...
>> +static int penctrl_spi_probe(struct spi_device *spi)
>> +{
>> + int i, ret;
>> +
>> + /* Allocate driver data */
>> + penctrl = kzalloc(sizeof(*penctrl), GFP_KERNEL);
>
> devm_kzalloc() ?
Yes will change to devm_kzalloc().
>> + if (!penctrl)
>> + return -ENOMEM;
>> +
>> + penctrl->spi = spi;
>> + mutex_init(&spi_lock);
>> +
>> + for (i = 0; i < ARRAY_SIZE(penctrl_devices); i++) {
>> + ret = misc_register(&penctrl_devices[i]);
>> + if (ret) {
>> + dev_err(&spi->dev, "Failed to register device %s\n",
>> + penctrl_devices[i].name);
>> + goto cleanup;
>> + }
>> + }
>> +
>> + /* Register reset controller */
>> + penctrl->rcdev.dev = &spi->dev;
>> + penctrl->rcdev.ops = &penctrl_reset_ops;
>> + penctrl->rcdev.owner = THIS_MODULE;
>> + penctrl->rcdev.of_node = spi->dev.of_node;
>> + penctrl->rcdev.nr_resets = 1;
>> + device_set_node(penctrl->rcdev.dev, dev_fwnode(&spi->dev));
>> +
>> + ret = reset_controller_register(&penctrl->rcdev);
>> + if (ret)
>> + return dev_err_probe(&spi->dev, ret,
>> + "failed to register reset controller\n");
>> + return 0;
>
>> +cleanup:
>
> err_cleanup: ?
Will use err_cleanup:
>> + for (i = 0; i < ARRAY_SIZE(penctrl_devices); i++) {
>
> while (i--) {
>
Yes, can change to while(), order doesn't matter.
>> + if (penctrl_devices[i].this_device)
>> + misc_deregister(&penctrl_devices[i]);
>> + }
>> + return ret;
>> +}
Regards,
Brad
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2023-09-26 20:05 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-13 21:49 [PATCH v16 0/6] Support AMD Pensando Elba SoC Brad Larson
2023-09-13 21:49 ` Brad Larson
2023-09-13 21:49 ` [PATCH v16 1/6] dt-bindings: arm: add AMD Pensando boards Brad Larson
2023-09-13 21:49 ` Brad Larson
2023-09-13 21:49 ` [PATCH v16 2/6] dt-bindings: soc: amd: amd,pensando-elba-ctrl: Add Pensando SoC Controller Brad Larson
2023-09-13 21:49 ` Brad Larson
2023-09-13 21:49 ` [PATCH v16 3/6] MAINTAINERS: Add entry for AMD PENSANDO Brad Larson
2023-09-13 21:49 ` Brad Larson
2023-09-13 21:49 ` [PATCH v16 4/6] arm64: Add config for AMD Pensando SoC platforms Brad Larson
2023-09-13 21:49 ` Brad Larson
2023-09-13 21:49 ` [PATCH v16 5/6] arm64: dts: Add AMD Pensando Elba SoC support Brad Larson
2023-09-13 21:49 ` Brad Larson
2023-09-14 18:52 ` Rob Gardner
2023-09-14 18:52 ` Rob Gardner
2023-09-13 21:49 ` [PATCH v16 6/6] soc: amd: Add support for AMD Pensando SoC Controller Brad Larson
2023-09-13 21:49 ` Brad Larson
2023-09-21 15:19 ` Andy Shevchenko
2023-09-21 15:19 ` Andy Shevchenko
2023-09-26 20:05 ` Brad Larson [this message]
2023-09-26 20:05 ` Brad Larson
2023-09-27 12:59 ` Andy Shevchenko
2023-09-27 12:59 ` Andy Shevchenko
2023-09-22 10:24 ` Arnd Bergmann
2023-09-22 10:24 ` Arnd Bergmann
2023-09-25 8:51 ` Andy Shevchenko
2023-09-25 8:51 ` Andy Shevchenko
2023-09-26 17:47 ` Brad Larson
2023-09-26 17:47 ` Brad Larson
2023-09-26 17:51 ` Arnd Bergmann
2023-09-26 17:51 ` Arnd Bergmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230926200541.35787-1-blarson@amd.com \
--to=blarson@amd.com \
--cc=adrian.hunter@intel.com \
--cc=alcooperx@gmail.com \
--cc=andy.shevchenko@gmail.com \
--cc=arnd@arndb.de \
--cc=brendan.higgins@linux.dev \
--cc=briannorris@chromium.org \
--cc=broonie@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=conor+dt@kernel.org \
--cc=davidgow@google.com \
--cc=devicetree@vger.kernel.org \
--cc=fancer.lancer@gmail.com \
--cc=gerg@linux-m68k.org \
--cc=gsomlo@gmail.com \
--cc=hal.feng@starfivetech.com \
--cc=hasegawa-hitomi@fujitsu.com \
--cc=j.neuschaefer@gmx.net \
--cc=joel@jms.id.au \
--cc=kernel@esmil.dk \
--cc=krzk@kernel.org \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=lee.jones@linaro.org \
--cc=lee@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mmc@vger.kernel.org \
--cc=linux-spi@vger.kernel.org \
--cc=p.zabel@pengutronix.de \
--cc=rdunlap@infradead.org \
--cc=robh+dt@kernel.org \
--cc=samuel@sholland.org \
--cc=skhan@linuxfoundation.org \
--cc=suravee.suthikulpanit@amd.com \
--cc=thomas.lendacky@amd.com \
--cc=tonyhuang.sunplus@gmail.com \
--cc=ulf.hansson@linaro.org \
--cc=vaishnav.a@ti.com \
--cc=walker.chen@starfivetech.com \
--cc=will@kernel.org \
--cc=zhuyinbo@loongson.cn \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.