Message-ID: <81cae5ea-8791-4170-a93e-08c016d74e10@oss.qualcomm.com>
Date: Tue, 6 Jan 2026 10:53:15 +0800
From: "Aiqun(Maria) Yu" <aiqun.yu@....qualcomm.com>
To: Bjorn Andersson <andersson@...nel.org>
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 1/5/2026 11:22 PM, Bjorn Andersson wrote:
> 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.

Those patches is still modify the same file here. And we intend to work
as a team instead of individual developer to ease the maintainers' job.
Here is the 2 options, which one will you prefer?:
1. Have the Tsense and QUP patches split into 2 patches, while still in
this same series.
2. Have the Tsense a separate patch, based on latest merged
kaanapali.dtsi. And have QUP patch as a separate patch, also based on
latest merged kaanapali.dtsi.

The options will be guide on later new functionality added for this
device tree as well. Only single device tree series is suggested, or
tech team suggested to upload their own device tree patches.

By the way, coresight patch is already reviewed-by. We referenced here
only add tags. And clearly inform you that the dependency is all
cleared. So you can apply it.
Also, the other patch can be based on this latest change, that you can
apply without any conflict at all.

> 
> 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
-- 
Thx and BRs,
Aiqun(Maria) Yu

Powered by blists - more mailing lists