Re: [PATCH v7 04/14] spi: cadence: Provide a capability structure

Pratyush Yadav
2021-12-21T12:06:16Z

On 21/12/21 12:19PM, Miquel Raynal wrote:
> Hi Pratyush,
>
> p.yadav@ti.com wrote on Tue, 21 Dec 2021 16:11:10 +0530:
>
> > On 21/12/21 11:16AM, Miquel Raynal wrote:
> > > Hi Pratyush,
> > >
> > > p.yadav@ti.com wrote on Tue, 21 Dec 2021 00:25:18 +0530:
> > >
> > > > > Subject: [PATCH v7 04/14] spi: cadence: Provide a capability structure
> > > >
> > > > s/cadence/cadence-quadspi/
> > >
> > > Right.
> > >
> > > >
> > > > On 17/12/21 05:16PM, Miquel Raynal wrote:
> > > > > This controller has DTR support, so advertize it with a capability now
> > > > > that the spi_controller_mem_ops structure contains this new field. This
> > > > > will later be used by the core to discriminate whether an operation is
> > > > > supported or not, in a more generic way than having different helpers.
> > > > >
> > > > > Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> > > > > ---
> > > > > drivers/spi/spi-cadence-quadspi.c | 5 +++++
> > > > > 1 file changed, 5 insertions(+)
> > > > >
> > > > > diff --git a/drivers/spi/spi-cadence-quadspi.c b/drivers/spi/spi-cadence-quadspi.c
> > > > > index 101cc71bffa7..98e0cc4236e3 100644
> > > > > --- a/drivers/spi/spi-cadence-quadspi.c
> > > > > +++ b/drivers/spi/spi-cadence-quadspi.c
> > > > > @@ -1388,10 +1388,15 @@ static const char *cqspi_get_name(struct spi_mem *mem)
> > > > > return devm_kasprintf(dev, GFP_KERNEL, "%s.%d", dev_name(dev), mem->spi->chip_select);
> > > > > }
> > > > >
> > > > > +static const struct spi_controller_mem_caps cqspi_mem_caps = {
> > > > > + .dtr = true,
> > > > > +};
> > > > > +
> > > > > static const struct spi_controller_mem_ops cqspi_mem_ops = {
> > > > > .exec_op = cqspi_exec_mem_op,
> > > > > .get_name = cqspi_get_name,
> > > > > .supports_op = cqspi_supports_mem_op,
> > > > > + .caps = &cqspi_mem_caps,
> > > >
> > > > I just noticed you put it under struct spi_mem_ops, not under struct
> > > > spi_mem. This is not an operation per se so wouldn't it be better if it
> > > > is moved to struct spi_mem?
> > >
> > > I had a hard time taking a decision but my conclusion was that these
> > > caps are static controller capabilities and exclusively tight to the
> > > controller. The spi_mem structure defines a SPI peripheral. The
> > > spi_mem_ops structure is the only spi-mem related field of the
> > > spi-controller structure. I could have added my own field there but
> > > as these caps are only meant to be used by the spi_mem_ops anyway
> > > (exclusively ->supports_op() for now), it seemed to be a good location,
> > > at least better than the spi-mem structure.
> >
> > Can we have a 3rd person chime in and break the tie? :-)
>
> I don't quite get why we should put controller specific information
> into the memory device structure?

Hmm, you're right. struct spi_controller would probably be a better
place.

>
> Anyway, do you mind if we move forward first? Not that I don't think
> that this choice should be discussed further, but I think this can
> easily be changed in the near future if there is a desire to
> reorganize spi-mem objects. In fact, these capabilities are accessed
> through a helper so that hypothetic change would be almost transparent.

Okay. I would still like to hear other opinions on this, but fine by me
if you want to take this in as-is.

--
Regards,
Pratyush Yadav
Texas Instruments Inc.