| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Wed, 6 Jul 2022 14:28:41 +0000
From: Frank Li <frank.li@....com>
To: Yoshihiro Shimoda <yoshihiro.shimoda.uh@...esas.com>,
Serge Semin <Sergey.Semin@...kalelectronics.ru>
CC: Serge Semin <fancer.lancer@...il.com>,
Alexey Malahov <Alexey.Malahov@...kalelectronics.ru>,
Pavel Parkhomenko <Pavel.Parkhomenko@...kalelectronics.ru>,
Krzysztof Wilczyński <kw@...ux.com>,
"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
"dmaengine@...r.kernel.org" <dmaengine@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Gustavo Pimentel <gustavo.pimentel@...opsys.com>,
Vinod Koul <vkoul@...nel.org>, Rob Herring <robh@...nel.org>,
Bjorn Helgaas <bhelgaas@...gle.com>,
Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
Jingoo Han <jingoohan1@...il.com>,
Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>
Subject: RE: [EXT] RE: [PATCH v3 19/24] dmaengine: dw-edma: Use non-atomic
io-64 methods
> -----Original Message-----
> From: Yoshihiro Shimoda <yoshihiro.shimoda.uh@...esas.com>
> Sent: Wednesday, July 6, 2022 12:43 AM
> To: Serge Semin <Sergey.Semin@...kalelectronics.ru>
> Cc: Serge Semin <fancer.lancer@...il.com>; Alexey Malahov
> <Alexey.Malahov@...kalelectronics.ru>; Pavel Parkhomenko
> <Pavel.Parkhomenko@...kalelectronics.ru>; Krzysztof Wilczyński
> <kw@...ux.com>; linux-pci@...r.kernel.org; dmaengine@...r.kernel.org;
> linux-kernel@...r.kernel.org; Gustavo Pimentel
> <gustavo.pimentel@...opsys.com>; Vinod Koul <vkoul@...nel.org>; Rob
> Herring <robh@...nel.org>; Bjorn Helgaas <bhelgaas@...gle.com>; Lorenzo
> Pieralisi <lorenzo.pieralisi@....com>; Jingoo Han <jingoohan1@...il.com>;
> Frank Li <frank.li@....com>; Manivannan Sadhasivam
> <manivannan.sadhasivam@...aro.org>
> Subject: [EXT] RE: [PATCH v3 19/24] dmaengine: dw-edma: Use non-atomic
> io-64 methods
>
> Caution: EXT Email
>
> Hi,
>
> > From: Serge Semin, Sent: Friday, June 10, 2022 6:15 PM
> >
> > Instead of splitting the 64-bits IOs up into two 32-bits ones it's
> > possible to use an available set of the non-atomic readq/writeq methods
> > implemented exactly for such cases. They are defined in the dedicated
> > header files io-64-nonatomic-lo-hi.h/io-64-nonatomic-hi-lo.h. So in case
> > if the 64-bits readq/writeq methods are unavailable on some platforms at
> > consideration, the corresponding drivers can have any of these headers
> > included and stop locally re-implementing the 64-bits IO accessors taking
> > into account the non-atomic nature of the included methods. Let's do that
> > in the DW eDMA driver too. Note by doing so we can discard the
> > CONFIG_64BIT config ifdefs from the code. Also note that if a platform
> > doesn't support 64-bit DBI IOs then the corresponding accessors will just
> > directly call the lo_hi_readq()/lo_hi_writeq() methods.
> >
> > Signed-off-by: Serge Semin <Sergey.Semin@...kalelectronics.ru>
> > Reviewed-by: Manivannan Sadhasivam
> <manivannan.sadhasivam@...aro.org>
> > Tested-by: Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>
> > ---
> > drivers/dma/dw-edma/dw-edma-v0-core.c | 71 +++++++++------------------
> > 1 file changed, 24 insertions(+), 47 deletions(-)
> >
> > diff --git a/drivers/dma/dw-edma/dw-edma-v0-core.c b/drivers/dma/dw-
> edma/dw-edma-v0-core.c
> > index e6d611176891..4348d2323125 100644
> > --- a/drivers/dma/dw-edma/dw-edma-v0-core.c
> > +++ b/drivers/dma/dw-edma/dw-edma-v0-core.c
> <snip>
> > @@ -417,18 +404,8 @@ void dw_edma_v0_core_start(struct
> dw_edma_chunk *chunk, bool first)
> > SET_CH_32(dw, chan->dir, chan->id, ch_control1,
> > (DW_EDMA_V0_CCS | DW_EDMA_V0_LLE));
> > /* Linked list */
> > - if ((chan->dw->chip->flags & DW_EDMA_CHIP_32BIT_DBI) ||
>
> I'm trying to use this patch series, but I could not apply this patch.
> I investigated why, and then IIUC the DW_EDMA_CHIP_32BIT_DBI flag
> doesn't
> exist on the following based patches:
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatch
> work.kernel.org%2Fproject%2Flinux-pci%2Fcover%2F20220624143947.8991-
> 1-
> Sergey.Semin%40baikalelectronics.ru%2F&data=05%7C01%7CFrank.Li%
> 40nxp.com%7C44fc7f7d7f844fb10b4a08da5f125456%7C686ea1d3bc2b4c6fa
> 92cd99c5c301635%7C0%7C0%7C637926829585015681%7CUnknown%7CTWF
> pbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXV
> CI6Mn0%3D%7C3000%7C%7C%7C&sdata=nwJEnsQoej4RzpY9ZTDfOwh
> on%2BzjXz48Xx5Yz5WAR2w%3D&reserved=0
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatch
> work.kernel.org%2Fproject%2Flinux-
> dmaengine%2Fcover%2F20220524152159.2370739-1-
> Frank.Li%40nxp.com%2F&data=05%7C01%7CFrank.Li%40nxp.com%7C4
> 4fc7f7d7f844fb10b4a08da5f125456%7C686ea1d3bc2b4c6fa92cd99c5c301635
> %7C0%7C0%7C637926829585015681%7CUnknown%7CTWFpbGZsb3d8eyJWI
> joiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3
> 000%7C%7C%7C&sdata=rNV74hncfbxxb4crPA2PGfkeIW68GBOiv58Q1yC
> heUo%3D&reserved=0
>
> According to the comment from Zhi Li [1], the flag can be skipped by the fixed
> patch [2].
> That's why the flag doesn't exist on the based patches.
>
> [1]
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatch
> work.kernel.org%2Fproject%2Flinux-
> dmaengine%2Fpatch%2F20220503005801.1714345-9-
> Frank.Li%40nxp.com%2F%2324844332&data=05%7C01%7CFrank.Li%40
> nxp.com%7C44fc7f7d7f844fb10b4a08da5f125456%7C686ea1d3bc2b4c6fa92c
> d99c5c301635%7C0%7C0%7C637926829585015681%7CUnknown%7CTWFpb
> GZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6
> Mn0%3D%7C3000%7C%7C%7C&sdata=Q%2Bx5IxIaQyS1oVZEoNXEL2X4
> SAB0ffO2NjMrUT3MGho%3D&reserved=0
> [2]
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.ker
> nel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Fvkoul%2Fdmaengine.git
> %2Fcommit%2F%3Fh%3Dfixes%26id%3D8fc5133d6d4da65cad6b73152fc714a
> d3d7f91c1&data=05%7C01%7CFrank.Li%40nxp.com%7C44fc7f7d7f844f
> b10b4a08da5f125456%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7
> C637926829585015681%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAw
> MDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C
> %7C&sdata=nGZetYm3da8Vj4adPAXZV7Rr0kXvcliW%2B0PlwOmsnsg%3
> D&reserved=0
>
> Since both codes in #ifdef and #else are the same, we can just remove code
> of the #else part.
> But, what do you think?
> -----
> #ifdef CONFIG_64BIT
> /* llp is not aligned on 64bit -> keep 32bit accesses */
> SET_CH_32(dw, chan->dir, chan->id, llp.lsb,
> lower_32_bits(chunk->ll_region.paddr));
> SET_CH_32(dw, chan->dir, chan->id, llp.msb,
> upper_32_bits(chunk->ll_region.paddr));
> #else /* CONFIG_64BIT */
> SET_CH_32(dw, chan->dir, chan->id, llp.lsb,
> lower_32_bits(chunk->ll_region.paddr));
> SET_CH_32(dw, chan->dir, chan->id, llp.msb,
> upper_32_bits(chunk->ll_region.paddr));
> #endif /* CONFIG_64BIT */
> -----
>
Latest Linux-next code have removed CONFIG_64BIT.
Best regards
Frank Li
> Best regards,
> Yoshihiro Shimoda
>
> > - !IS_ENABLED(CONFIG_64BIT)) {
> > - SET_CH_32(dw, chan->dir, chan->id, llp.lsb,
> > - lower_32_bits(chunk->ll_region.paddr));
> > - SET_CH_32(dw, chan->dir, chan->id, llp.msb,
> > - upper_32_bits(chunk->ll_region.paddr));
> > - } else {
> > - #ifdef CONFIG_64BIT
> > - SET_CH_64(dw, chan->dir, chan->id, llp.reg,
> > - chunk->ll_region.paddr);
> > - #endif
> > - }
> > + SET_CH_64(dw, chan->dir, chan->id, llp.reg,
> > + chunk->ll_region.paddr);
> > }
> > /* Doorbell */
> > SET_RW_32(dw, chan->dir, doorbell,
> > --
> > 2.35.1
Powered by blists - more mailing lists