[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200930150312.ipt724uihixblr3a@mobilestation>
Date: Wed, 30 Sep 2020 18:03:12 +0300
From: Serge Semin <Sergey.Semin@...kalelectronics.ru>
To: Mark Brown <broonie@...nel.org>
CC: Alexey Malahov <Alexey.Malahov@...kalelectronics.ru>,
Ramil Zaripov <Ramil.Zaripov@...kalelectronics.ru>,
Pavel Parkhomenko <Pavel.Parkhomenko@...kalelectronics.ru>,
Andy Shevchenko <andy.shevchenko@...il.com>,
Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
Lars Povlsen <lars.povlsen@...rochip.com>,
"wuxu . wu" <wuxu.wu@...wei.com>, Feng Tang <feng.tang@...el.com>,
Rob Herring <robh+dt@...nel.org>, <linux-spi@...r.kernel.org>,
<devicetree@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 11/30] spi: dw: Add DWC SSI capability
Mark,
A concrete question is below of my previous comment.
On Wed, Sep 30, 2020 at 01:17:37AM +0300, Serge Semin wrote:
> On Tue, Sep 29, 2020 at 02:52:33PM +0100, Mark Brown wrote:
> > On Sun, Sep 20, 2020 at 02:28:55PM +0300, Serge Semin wrote:
> >
> > > - /*
> > > - * SPI mode (SCPOL|SCPH)
> > > - * CTRLR0[ 8] Serial Clock Phase
> > > - * CTRLR0[ 9] Serial Clock Polarity
> > > - */
> > > - cr0 |= ((spi->mode & SPI_CPOL) ? 1 : 0) << DWC_SSI_CTRLR0_SCPOL_OFFSET;
> > > - cr0 |= ((spi->mode & SPI_CPHA) ? 1 : 0) << DWC_SSI_CTRLR0_SCPH_OFFSET;
> >
>
> > > + cr0 |= SSI_MOTO_SPI << DWC_SSI_CTRLR0_FRF_OFFSET;
> > > + cr0 |= ((spi->mode & SPI_CPOL) ? 1 : 0) << DWC_SSI_CTRLR0_SCPOL_OFFSET;
> > > + cr0 |= ((spi->mode & SPI_CPHA) ? 1 : 0) << DWC_SSI_CTRLR0_SCPH_OFFSET;
> >
> > The new code seems less well commented than the old code here.
>
> You are right. The comments are omitted. The thing is that they are absolutely
> redundant here, for the same reason they haven't been added to the standard
> update_cr0() method. Both the DWC SSI-capable and standard DW APB SSI-specific
> part of the code do the same thing: setup the CTRLR0 fields, which are described
> by the macro definitions. So there is no need to duplicate that information in
> the comments, moreover seeing it can be inferred from the code.
>
> -Sergey
My response to your comment was that those in-code comments have been absolutely
redundant. So I just removed them, since I was touching that part of the driver
anyway. If you are agree with me having that done here, then please, accept the
patch the way it is. If you disagree, or have any other though, please give me
your answer, why.
-Sergey
Powered by blists - more mailing lists