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] [day] [month] [year] [list]
Message-ID: <8c9b26f3-e782-437c-9930-2996fc625542@iscas.ac.cn>
Date: Mon, 23 Jun 2025 17:42:20 +0800
From: Vivian Wang <wangruikang@...as.ac.cn>
To: Guodong Xu <guodong@...cstar.com>, Yixun Lan <dlan@...too.org>
Cc: Alex Elder <elder@...e.org>, Ze Huang <huangze@...t.edu.cn>,
 spacemit@...ts.linux.dev, Rob Herring <robh@...nel.org>,
 Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
 <conor+dt@...nel.org>, Paul Walmsley <paul.walmsley@...ive.com>,
 Palmer Dabbelt <palmer@...belt.com>, Albert Ou <aou@...s.berkeley.edu>,
 Alexandre Ghiti <alex@...ti.fr>, devicetree@...r.kernel.org,
 linux-riscv@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH RFC] riscv: dts: spacemit: Add DMA translation buses for
 K1

Hi Guodong and Yixun,

>>>>> <snip>
>>>>>
>>>>>> By the way, I don't think I will be making an RFC v2 of this. I think we
>>>>>> should get everything sorted under this one thread.
>>>>>>
>>>>> Instead, from a SoC tree maintainer's perspective (whom taking care of
>>>>> merging all the dts files), I'd rather perfer an independent or
>>>>> separated patch for this given every party reached consesus, so we could
>>>>> get this patch merged first and early, instead of getting them distributed all
>>>>> over in different series, IMO, separated patches brings more dedependencies
>>>>> if more than two series require one bus and result in more merge conflicts..
>>>>> Besides, introducing new busses result in re-arrangement of previous nodes,
>>>>> those like uart, i2c (even they have no DMA feature implemented currently)..
>>>>>
>>>> Hi Yixun,
>>>>
>>>> So, here is my proposed plan: I will submit two patches. The first
>>>> patch will introduce the dma-bus node and move the relevant (uart0, uart2
>>>> ..uart9) device nodes under it. The second patch will then add the pdma0
>>>> node itself. Please let me know if you have a different approach in mind.
>>>>
>>> ..
>>>> Maybe you want to see an independent patchset with just the first patch? This
>>>> way it can be merged early without waiting for the pdma0 series.
>>>> Let me know. Thanks.
>>> yes, I prefer this way, this will also help other drivers - usb/emac,
>>> since they all wait for those bus nodes..
>>>
>>> please submit following two parts a) introduce bus b) move relevant nodes.
>>> notice, I don't mind who (you or Vivian) doing the job, but keep in
>>> mind don't duplicate the work..
>>>
>> to make it clear, I'd like to see all relevant *bus nodes added in one
>> independent series, not only dma-bus, even some nodes currently not used.
>> the goal here is "do it once, and do it well"
>>
>> in fact, I'd expect Vivian(or Guodong, whoever) to send a new version
>> of this patch without RFC prefix..
>>
> I'm ok if Vivian can do that.
> Thanks.

I will post v1 of this series soon.

Thanks,
Vivian "dramforever" Wang


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ