linux-kernel - Re: [PATCH v5 1/3] dt-bindings: dmaengine: Add dmamux for CV18XX/SG200X series SoC

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Tue, 26 Mar 2024 20:06:07 +0800
From: Inochi Amaoto <inochiama@...look.com>
To: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>, 
	Inochi Amaoto <inochiama@...look.com>, Vinod Koul <vkoul@...nel.org>, Rob Herring <robh@...nel.org>, 
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>, Conor Dooley <conor+dt@...nel.org>, 
	Chen Wang <unicorn_wang@...look.com>, Paul Walmsley <paul.walmsley@...ive.com>, 
	Palmer Dabbelt <palmer@...belt.com>, Albert Ou <aou@...s.berkeley.edu>
Cc: Jisheng Zhang <jszhang@...nel.org>, Liu Gui <kenneth.liu@...hgo.com>, 
	Jingbao Qiu <qiujingbao.dlmu@...il.com>, dlan@...too.org, dmaengine@...r.kernel.org, 
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org, linux-riscv@...ts.infradead.org
Subject: Re: [PATCH v5 1/3] dt-bindings: dmaengine: Add dmamux for
 CV18XX/SG200X series SoC

On Tue, Mar 26, 2024 at 12:50:33PM +0100, Krzysztof Kozlowski wrote:
> On 26/03/2024 12:41, Inochi Amaoto wrote:
> >>>
> >>> The driver does use this file.
> >>
> >> I checked and could not find. Please point me to specific parts of the code.
> >>
> > 
> > In cv1800_dmamux_route_allocate.
> >> +	regmap_set_bits(dmamux->regmap,
> >> +			DMAMUX_CH_REG(chid),
> >> +			DMAMUX_CH_SET(chid, devid));
> >> +
> >> +	regmap_update_bits(dmamux->regmap, CV1800_SDMA_DMA_INT_MUX,
> >> +			   DMAMUX_INT_CH_MASK(chid, cpuid),
> >> +			   DMAMUX_INT_CH_BIT(chid, cpuid));
> > 
> > I think this is.
> 
> So where exactly? I don't see any define being used here.
> CV1800_SDMA_DMA_INT_MUX is not in your header. DMAMUX_ is not in your
> header. So what are you pointing?
> 
> I don't understand this communication. Are you mocking me here or what?
> It's waste of my time.
> 

I apologize for my misunderstanding and your wasted time. I had 
previously thought that hardware constants is also binding. This 
leads to a weird communication between us. Since I agree and 
understand this file is not a binding, I will remove this file in
the next version. Anyway, thanks for your kindly explanation.

Regards,
Inochi.

> > 
> >>>
> >>>>> And considering the limitation of this dmamux, maybe only devices that 
> >>>>> require dma as a must can have the dma assigned. 
> >>>>> Due to the fact, I think it may be a long time to wait for this header
> >>>>> to be used as the binding header.
> >>>>
> >>>> I don't understand. You did not provide a single reason why this is a
> >>>> binding. Reason is: mapping IDs between DTS and driver. Where is this
> >>>> reason?
> >>>>
> >>>
> >>> It seems like that I misunderstood something. This file provides one-one
> >>> mapping between the dma device id and cpuid, which is both used in the
> >>> dts and driver. For dts, it provides device id and cpu id mapping. And
> >>> for driver, it is used as the directive to tell how to write the mapping
> >>> register.
> >>
> >> So where is it? I looked for DMA_TDM0_RX - nothing. Then DMA_I2C1_RX -
> >> nothing. Then any "DMA_" - also looks nothing.
> >>
> > 
> > It is just the value writed, so I say it is just a one-one mapping.
> > Maybe I misunderstand the binding meaning? Is the binding a mapping 
> > between the dts and something defind in the driver (not the real 
> > device)?
> 
> Binding headers contains IDs which are used by the driver and DTS code.
> Hardware constants are not bindings. Register values, addresses,
> whatever hardware is using is not a binding.
> 
> 
> Best regards,
> Krzysztof
>