[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <7sbof5mgm7mqtm4gh45f4w7264akplqtkfyplrerek4w6seipl@ith7sc3wmgih>
Date: Mon, 19 Jan 2026 11:46:13 +0200
From: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
To: 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 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.
>
> >
> > >
> > > >
> > > > Best regards,
> > > > Krzysztof
> > >
> > > --
> > > Best Regards,
> > > Yijie
> > >
> >
>
> --
> Best Regards,
> Yijie
>
--
With best wishes
Dmitry
Powered by blists - more mailing lists