All of lore.kernel.org
 help / color / mirror / Atom feed
From: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
To: Serge Semin <fancer.lancer@gmail.com>
Cc: Frank Li <Frank.Li@nxp.com>,
	Serge Semin <Sergey.Semin@baikalelectronics.ru>,
	gustavo.pimentel@synopsys.com, hongxing.zhu@nxp.com,
	l.stach@pengutronix.de, linux-imx@nxp.com,
	linux-pci@vger.kernel.org, dmaengine@vger.kernel.org,
	lznuaa@gmail.com, helgaas@kernel.org, vkoul@kernel.org,
	lorenzo.pieralisi@arm.com, robh@kernel.org, kw@linux.com,
	bhelgaas@google.com
Subject: Re: [PATCH v6 7/9] dmaengine: dw-edma: Add support for chip specific flags
Date: Wed, 13 Apr 2022 14:58:08 +0530	[thread overview]
Message-ID: <20220413092808.GF2015@thinkpad> (raw)
In-Reply-To: <20220413091837.an75fiqazjhpapf4@mobilestation>

On Wed, Apr 13, 2022 at 12:18:37PM +0300, Serge Semin wrote:
> On Wed, Apr 06, 2022 at 10:23:45AM -0500, Frank Li wrote:
> > Add a "flags" field to the "struct dw_edma_chip" so that the controller
> > drivers can pass flags that are relevant to the platform.
> > 
> > DW_EDMA_CHIP_LOCAL - Used by the controller drivers accessing eDMA
> > locally. Local eDMA access doesn't require generating MSIs to the remote.
> > 
> > Signed-off-by: Frank Li <Frank.Li@nxp.com>
> > ---
> 
> > Change from v5 to v6
> >  - use enum instead of define
> 
> Hm, why have you decided to do that? I don't see a well justified
> reason to use the enumeration here, but see my next comment for
> details.

It was me who suggested using the enums for flags instead of defines.
Enums helps with kdoc and it also provides a neat way to group flags together.

> 
> > 
> > Change from v4 to v5
> >  - split two two patch
> >  - rework commit message
> > Change from v3 to v4
> > none
> > Change from v2 to v3
> >  - rework commit message
> >  - Change to DW_EDMA_CHIP_32BIT_DBI
> >  - using DW_EDMA_CHIP_LOCAL control msi
> >  - Apply Bjorn's comments,
> >         if (!j) {
> >                control |= DW_EDMA_V0_LIE;
> >                if (!(chan->chip->flags & DW_EDMA_CHIP_LOCAL))
> >                                control |= DW_EDMA_V0_RIE;
> >         }
> > 
> >         if ((chan->chip->flags & DW_EDMA_CHIP_REG32BIT) ||
> >               !IS_ENABLED(CONFIG_64BIT)) {
> >           SET_CH_32(...);
> >           SET_CH_32(...);
> >        } else {
> >           SET_CH_64(...);
> >        }
> > 
> > 
> > Change from v1 to v2
> > - none
> > 
> >  drivers/dma/dw-edma/dw-edma-v0-core.c | 9 ++++++---
> >  include/linux/dma/edma.h              | 9 +++++++++
> >  2 files changed, 15 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/dma/dw-edma/dw-edma-v0-core.c b/drivers/dma/dw-edma/dw-edma-v0-core.c
> > index 8ddc537d11fd6..30f8bfe6e5712 100644
> > --- a/drivers/dma/dw-edma/dw-edma-v0-core.c
> > +++ b/drivers/dma/dw-edma/dw-edma-v0-core.c

[...]

> > +	enum dw_edma_chip_flags	flags;
> 
> There is no point in having the named enumeration here since the flags
> field semantics is actually a bitfield rather than a single value. If
> you want to stick to the enumerated flags, then please use the
> anonymous enum like this:

I agree with using u32 for flags field but I don't agree with anonymous enums.
Enums with a name conveys information of what the enumerated types represent.
If you just look at your example below, it is difficult to guess the purpose of
this enum.

Thanks,
Mani

> +enum {
> +	DW_EDMA_CHIP_LOCAL	= BIT(0),
> +};
> and explicit unsigned int type of the flags field.
> 
> -Sergey
> 
> >  
> >  	void __iomem		*reg_base;
> >  
> > -- 
> > 2.35.1
> > 

  reply	other threads:[~2022-04-13  9:28 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-06 15:23 [PATCH v6 0/9] Enable designware PCI EP EDMA locally Frank Li
2022-04-06 15:23 ` [PATCH v6 1/9] dmaengine: dw-edma: Detach the private data and chip info structures Frank Li
2022-04-13  8:51   ` Serge Semin
2022-04-13 14:53     ` Zhi Li
2022-04-13 16:58       ` Serge Semin
2022-04-13 19:04     ` Zhi Li
2022-04-13 19:08       ` Serge Semin
2022-04-06 15:23 ` [PATCH v6 2/9] dmaengine: dw-edma: Remove unused field irq in struct dw_edma_chip Frank Li
2022-04-13  8:55   ` Serge Semin
2022-04-06 15:23 ` [PATCH v6 3/9] dmaengine: dw-edma: Change rg_region to reg_base " Frank Li
2022-04-06 15:23 ` [PATCH v6 4/9] dmaengine: dw-edma: Rename wr(rd)_ch_cnt to ll_wr(rd)_cnt " Frank Li
2022-04-06 15:23 ` [PATCH v6 5/9] dmaengine: dw-edma: Drop dma_slave_config.direction field usage Frank Li
2022-04-06 15:23 ` [PATCH v6 6/9] dmaengine: dw-edma: Fix eDMA Rd/Wr-channels and DMA-direction semantics Frank Li
2022-04-06 15:23 ` [PATCH v6 7/9] dmaengine: dw-edma: Add support for chip specific flags Frank Li
2022-04-13  9:18   ` Serge Semin
2022-04-13  9:28     ` Manivannan Sadhasivam [this message]
2022-04-13 11:53       ` Serge Semin
2022-04-06 15:23 ` [PATCH v6 8/9] dmaengine: dw-edma: Add DW_EDMA_CHIP_32BIT_DBI " Frank Li
2022-04-13  9:20   ` Serge Semin
2022-04-06 15:23 ` [PATCH v6 9/9] PCI: endpoint: Add embedded DMA controller test Frank Li

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220413092808.GF2015@thinkpad \
    --to=manivannan.sadhasivam@linaro.org \
    --cc=Frank.Li@nxp.com \
    --cc=Sergey.Semin@baikalelectronics.ru \
    --cc=bhelgaas@google.com \
    --cc=dmaengine@vger.kernel.org \
    --cc=fancer.lancer@gmail.com \
    --cc=gustavo.pimentel@synopsys.com \
    --cc=helgaas@kernel.org \
    --cc=hongxing.zhu@nxp.com \
    --cc=kw@linux.com \
    --cc=l.stach@pengutronix.de \
    --cc=linux-imx@nxp.com \
    --cc=linux-pci@vger.kernel.org \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=lznuaa@gmail.com \
    --cc=robh@kernel.org \
    --cc=vkoul@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.