[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <d1d05b31-f70e-4250-8ff0-bfcba7f5923d@oss.qualcomm.com>
Date: Mon, 19 Jan 2026 14:31:16 +0100
From: Konrad Dybcio <konrad.dybcio@....qualcomm.com>
To: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>,
Yijie Yang <yijie.yang@....qualcomm.com>
Cc: Krzysztof Kozlowski <krzk@...nel.org>, andersson@...nel.org,
konradybcio@...nel.org, robh@...nel.org, krzk+dt@...nel.org,
conor+dt@...nel.org, linux-arm-msm@...r.kernel.org,
linux-kernel@...r.kernel.org, devicetree@...r.kernel.org
Subject: Re: [PATCH v4 4/4] arm64: dts: qcom: Add base PURWA-IOT-EVK board
On 1/19/26 10:46 AM, Dmitry Baryshkov wrote:
> On Mon, Jan 19, 2026 at 04:48:20PM +0800, Yijie Yang wrote:
>>
>>
>> On 1/19/2026 2:33 PM, Dmitry Baryshkov wrote:
>>> On Mon, Jan 19, 2026 at 11:13:29AM +0800, Yijie Yang wrote:
>>>>
>>>>
>>>> On 1/17/2026 12:19 AM, Krzysztof Kozlowski wrote:
>>>>> On 16/01/2026 11:41, YijieYang wrote:
>>>>>> From: Yijie Yang <yijie.yang@....qualcomm.com>
>>>>>>
>>>>>> The PURWA-IOT-EVK is an evaluation platform for IoT products, composed of
>>>>>> the Purwa IoT SoM and a carrier board. Together, they form a complete
>>>>>> embedded system capable of booting to UART.
>>>>>>
>>>>>> PURWA-IOT-EVK uses the PS8833 as a retimer for USB0, unlike HAMOA-IOT-EVK.
>>>>>> Meanwhile, USB0 bypasses the SBU selector FSUSB42.
>>>>>>
>>>>>
>>>>> NAK.
>>>>>
>>>>> Warnings were reported at v3. Did you address them? No, you completely
>>>>> ignored them, so warnings are reported again at v4.
>>>>>
>>>>> What do you think these emails are for?
>>>>
>>>> This warning is caused by the pcie3_phy node in purwa.dtsi, which is not
>>>> introduced by this patch set. Since it does not impact functionality, would
>>>> it be appropriate to fix it in a separate patch?
>>>
>>> Why can't it be fixed as a part of this patchset?
>>
>> 'qcom,4ln-config-sel' is a property related to bifurcated PHY support, which
>> Purwa’s PCIe3 does not provide. Therefore, introducing a new compatible with
>> a corresponding binding would be more appropriate than simply adding this
>> property. Is it acceptable to address this within the current patch set?
>
> Within this or in the separate patchset, but it needs to be fixed before
> this patch can go in. Otherwise we are enabling broken PCIe3.
https://lore.kernel.org/linux-arm-msm/20260119-topic-purwa_phy_shutup_warning-v1-1-997a692b31c6@oss.qualcomm.com/T/#u
Konrad
Powered by blists - more mailing lists