Re: [PATCH] spi: Add FSI-attached SPI controller driver

[Eddie James]

On 1/30/20 10:37 AM, Andy Shevchenko wrote:
> On Wed, Jan 29, 2020 at 10:09 PM Eddie James <eajames@xxxxxxxxxxxxx> wrote:
> > There exists a set of SPI controllers on some POWER processors that may
> > be accessed through the FSI bus. Add a driver to traverse the FSI CFAM
> > engine that can access and drive the SPI controllers. This driver would
> > typically be used by a baseboard management controller (BMC).
> ...
>
> > +#include <linux/bitfield.h>
> > +#include <linux/bits.h>
> > +#include <linux/of.h>
> ...
>
> > +struct fsi_spi {
> > +       struct device *dev;
> Isn't fsl->dev the same?
> Perhaps kernel doc to explain the difference?


No, it's not the same, as dev here is the SPI controller. I'll add a 
comment.


> > +       struct fsi_device *fsi;
> > +       u32 base;
> > +};
> ...
>
> > +static int fsi_spi_read_reg(struct fsi_spi *ctx, u32 offset, u64 *value)
> > +{
> > +       int rc;
> > +       __be32 cmd_be;
> > +       __be32 data_be;
> > +       *value = 0ULL;
> Usually the pattern is don't pollute output on error condition. Any
> reason why you zeroing output beforehand?


Well otherwise I have to store another 64 bit int and do another 
assignment at the end. This is an internal function and all the users 
below know what's happening.


> > +       cmd_be = cpu_to_be32(offset + ctx->base);
> > +       rc = fsi_device_write(ctx->fsi, FSI2SPI_CMD, &cmd_be, sizeof(cmd_be));
> > +       if (rc)
> > +               return rc;
> > +       return 0;
> > +}
> ...
>
> > +       data_be = cpu_to_be32((value >> 32) & 0xFFFFFFFF);
> Redundant & 0xff... part.
>
> > +       data_be = cpu_to_be32(value & 0xFFFFFFFF);
> Ditto.
>
> You may use upper_32_bits() / lower_32_bits() instead.


OK, thanks.


> ...
>
> > +static int fsi_spi_data_in(u64 in, u8 *rx, int len)
> > +{
> > +       int i;
> > +       int num_bytes = len > 8 ? 8 : len;
> min(len, 8);


Sure.


> > +       for (i = 0; i < num_bytes; ++i)
> > +               rx[i] = (u8)((in >> (8 * ((num_bytes - 1) - i))) & 0xffULL);
> Redundant & 0xffULL part.
>
> Isn't it NIH of get_unalinged_be64 / le64 or something similar?


No, these are shift in/out operations. The read register will also have 
previous operations data in them and must be extracted with only the 
correct number of bytes.


> > +       return num_bytes;
> > +}
> > +static int fsi_spi_data_out(u64 *out, const u8 *tx, int len)
> > +{
> Ditto as for above function. (put_unaligned ...)
>
> > +}
> ...
>
> > +       dev_info(ctx->dev, "Resetting SPI controller.\n");
> info?! Why?
>
> > +       rc = fsi_spi_write_reg(ctx, SPI_FSI_CLOCK_CFG,
> > +                              SPI_FSI_CLOCK_CFG_RESET2);
> > +       return rc;
> return fsi_spi_write_reg();
>
> ...
>
> > +       return ((64 - seq->bit) / 8) - 2;
> Too many parentheses.


I prefer using 2 extra characters to make it much clearer at a glance.


> ...
>
> > +static int fsi_spi_sequence_transfer(struct fsi_spi *ctx,
> > +                                    struct fsi_spi_sequence *seq,
> > +                                    struct spi_transfer *transfer)
> > +{
> > +       int loops = 1;
> > +       int idx = 0;
> > +       int rc;
> > +       u8 len;
> > +       u8 rem = 0;
> > +       if (transfer->len > 8) {
> > +               loops = transfer->len / 8;
> > +               rem = transfer->len - (loops * 8);
> > +               len = 8;
> > +       } else {
> > +               len = transfer->len;
> > +       }
> len = min(transfer->len, 8);
>
> loops = transfer->len / len;
> rem = transfer->len % len;


Sure.


> (I think compiler is clever enough to find out that the division can be avoided)
>
> ...and drop assignments in definition block.
>
> I didn't look carefully in the implementation, but I believe there is
> still room for improvement / optimization.
>
> > +       if (loops > 1) {
> > +               rc = fsi_spi_write_reg(ctx, SPI_FSI_COUNTER_CFG,
> > +                                      SPI_FSI_COUNTER_CFG_LOOPS(loops - 1));
> > +               if (rc) {
> > +                       /* Ensure error returns < 0 in this case. */
> I didn't get why this case is special? Why not to be consistent with
> return value?


Sure, will fix, this was leftover from some testing.


> > +                       if (rc > 0)
> > +                               rc = -rc;
> > +
> > +                       return rc;
> > +               }
> > +               return loops;
> If we return here the amount of loops...
>
> > +       }
> > +
> > +       return 0;
> ...why here is 0?
>
> I think more consistency is required.


Will refactor.


> > +}
> ...
>
> > +static int fsi_spi_transfer_data(struct fsi_spi *ctx,
> > +                                struct spi_transfer *transfer)
> > +{
> Can you refactor to tx and rx parts?


Why?


> > +       return 0;
> > +}
> ...
>
> > +       do {
> > +               rc = fsi_spi_read_reg(ctx, SPI_FSI_STATUS, &status);
> > +               if (rc)
> > +                       return rc;
> > +
> > +               if (status & (SPI_FSI_STATUS_ANY_ERROR |
> > +                             SPI_FSI_STATUS_TDR_FULL |
> > +                             SPI_FSI_STATUS_RDR_FULL)) {
> > +                       rc = fsi_spi_reset(ctx);
> > +                       if (rc)
> > +                               return rc;
> > +
> > +                       continue;
> I forgot if this to be infinite loop or if it's going to check
> previous seq_state value. In any case this code is a bit fishy. Needs
> comments / refactoring.


I'll add a timeout.


> > +               }
> > +
> > +               seq_state = status & SPI_FSI_STATUS_SEQ_STATE;
> > +       } while (seq_state && (seq_state != SPI_FSI_STATUS_SEQ_STATE_IDLE));
> ...
>
> > +       if ((clock_cfg & (SPI_FSI_CLOCK_CFG_MM_ENABLE |
> > +                         SPI_FSI_CLOCK_CFG_ECC_DISABLE |
> > +                         SPI_FSI_CLOCK_CFG_MODE |
> > +                         SPI_FSI_CLOCK_CFG_SCK_RECV_DEL |
> > +                         SPI_FSI_CLOCK_CFG_SCK_DIV)) != wanted_clock_cfg)
> > +               rc = fsi_spi_write_reg(ctx, SPI_FSI_CLOCK_CFG,
> > +                                      wanted_clock_cfg);
> Missed {} ?


No? It's one line under the if.


> > +
> > +       return rc;
> > +}
> ...
>
> > +       rc = fsi_slave_read(fsi->slave, 0x2860, &root_ctrl_8,
> What is this magic for?


Added comment.


> > +                           sizeof(root_ctrl_8));
> > +       if (rc)
> > +               return rc;
> ...
>
> > +static int fsi_spi_remove(struct device *dev)
> > +{
> > +       return 0;
> > +}
> Why do you need this?


Will drop it.


Thanks for the review!

Eddie


> ...
>
> > +static struct fsi_driver fsi_spi_driver = {
> > +       .id_table = fsi_spi_ids,
> > +       .drv = {
> > +               .name = "spi-fsi",
> > +               .bus = &fsi_bus_type,
> Why is it not in the module_fsi_driver() macro?
>
> > +               .probe = fsi_spi_probe,
> > +               .remove = fsi_spi_remove,
> > +       },
> > +};
> > +
> > +module_fsi_driver(fsi_spi_driver);