Hi Andy,
On Tue, May 16, 2023 at 00:05:32 Andy Shevchenko <andy.shevchenko@xxxxxxxxx> wrote:
> On Mon, May 15, 2023 at 9:18 PM Brad Larson <blarson@xxxxxxx> 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
