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]
Message-ID: <hezcpngxf5lyopkvzh5b7f66jr5f6bjowphigviqimadpcgpbs@ki7qfxs52ynv>
Date: Mon, 5 Jan 2026 09:22:54 -0600
From: Bjorn Andersson <andersson@...nel.org>
To: "Aiqun(Maria) Yu" <aiqun.yu@....qualcomm.com>
Cc: Konrad Dybcio <konrad.dybcio@....qualcomm.com>, 
	Jingyi Wang <jingyi.wang@....qualcomm.com>, Konrad Dybcio <konradybcio@...nel.org>, 
	Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>, 
	Conor Dooley <conor+dt@...nel.org>, tingwei.zhang@....qualcomm.com, trilok.soni@....qualcomm.com, 
	yijie.yang@....qualcomm.com, linux-arm-msm@...r.kernel.org, devicetree@...r.kernel.org, 
	linux-kernel@...r.kernel.org, 
	Manaf Meethalavalappu Pallikunhi <manaf.pallikunhi@....qualcomm.com>, Jyothi Kumar Seerapu <jyothi.seerapu@....qualcomm.com>
Subject: Re: [PATCH v2 2/2] arm64: dts: qcom: kaanapali: Add TSENS and QUPv3
 serial engines

On Mon, Jan 05, 2026 at 04:24:19PM +0800, Aiqun(Maria) Yu wrote:
> On 12/29/2025 9:12 PM, Konrad Dybcio wrote:
> > On 12/26/25 4:06 AM, Jingyi Wang wrote:
> >> Add new features on the Kaanapali Platform including:
> >>
> >> - Temperature Sensor (TSENS) and thermal zones
> >> - QUPv3 serial engine protocols with 5 I2C hubs and 24 QUP serial engines
> >>   across 4 QUP wrappers, each with support of GPI DMA engines.
> >>
> >> Co-developed-by: Manaf Meethalavalappu Pallikunhi <manaf.pallikunhi@....qualcomm.com>
> >> Signed-off-by: Manaf Meethalavalappu Pallikunhi <manaf.pallikunhi@....qualcomm.com>
> >> Co-developed-by: Jyothi Kumar Seerapu <jyothi.seerapu@....qualcomm.com>
> >> Signed-off-by: Jyothi Kumar Seerapu <jyothi.seerapu@....qualcomm.com>
> >> Signed-off-by: Jingyi Wang <jingyi.wang@....qualcomm.com>
> >> ---
> > 
> > Since the base DT is now merged, all subsequent patches are
> > supposed to be patch-sized, i.e. usually scoped for one feature that
> > makes sense. This one happens to be an arbitrary concatenation of two
> > separate ones. Were they separate, the original authors would benefit
> > from the full attribution and they would be easier for us to review
> 
> Hi Konrad,
> 
> Are you suggesting to split this patch into 3 function independent
> patches here?
> 

As far as I can see, you already have 3 independent patches here
(stuffed in 2 patches) - they don't overlap, they don't depend on each
other. So, yes this would be easier to handle as separate patches.

I would still like to see dependent patches be gathered and sent
together in a patch series.

For example smp2p + remoteproc + glink are owned by different teams, but
there's no benefit to merging only smp2p, or only smp2p + remoteproc. So
seeing all three (or more) parts in one series would be preferred (one
patch would also be accepted).



Regardless of who sends these patches or how this is done going forward,
this patch 2/2 is two separate, independent patches. Or you need to
describe why they belong together - what is the connection between tsens
and QUP? (I presume none)

Thanks,
Bjorn

> The current dt series is to ease the maintainers' effort to have an
> organized patch in one series in below manner:
> 1. And the series of the dt change will only have all dependency cleared
> functionality in this series.
> 2. dt maintainer won't have any conflict when apply.
> 3. we will suggest developers can do it's own upload when basic
> dependencies like mm-clock and pmic dependencies are all applied.
> 
> Are you suggesting splitting this patch into three independent
> functional patches here?
> The current DT series is designed to simplify maintainers’ efforts by
> keeping the patches organized within a single series, structured as follows:
> 
> 1. This DT series will include only functionality where all dependencies
> have been reviewed-by at least.
> 2. DT maintainers will not encounter conflicts when applying these patches.
> 3. We will recommend that developers upload their own patches once the
> basic dependencies—such as MM-clock and PMIC—have been applied.
> 
> This reflects our discussion with Bjorn and serves as a lesson learned:
> even with a Reviewed-by tag, patch application can be significantly
> delayed when the DT series involves a highly complex dependency chain.
> 
> > 
> > Konrad
> 
> -- 
> Thx and BRs,
> Aiqun(Maria) Yu

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ