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

[Pratyush Yadav]

On 21/12/21 12:19PM, Miquel Raynal wrote:
> Hi Pratyush,
> 
> p.yadav at 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 at 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 at 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.