linux-kernel - Re: [PATCH v3 4/4] arm64: dts: qcom: Add base HAMOA-IOT-EVK board

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: <myk2qvna427nmfz37p7xniafueu2akpmqzq2y7qmqnzsmggwks@fctmeqkgdkrc>
Date: Fri, 1 Aug 2025 20:54:06 +0300
From: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
To: Konrad Dybcio <konrad.dybcio@....qualcomm.com>
Cc: Yijie Yang <yijie.yang@....qualcomm.com>,
        Bjorn Andersson <andersson@...nel.org>,
        Konrad Dybcio <konradybcio@...nel.org>, Rob Herring <robh@...nel.org>,
        Krzysztof Kozlowski <krzk+dt@...nel.org>,
        Conor Dooley <conor+dt@...nel.org>, linux-arm-msm@...r.kernel.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 4/4] arm64: dts: qcom: Add base HAMOA-IOT-EVK board

On Fri, Aug 01, 2025 at 12:39:09PM +0200, Konrad Dybcio wrote:
> On 8/1/25 3:48 AM, Yijie Yang wrote:
> > 
> > 
> > On 2025-08-01 04:22, Dmitry Baryshkov wrote:
> >> On Thu, Jul 31, 2025 at 04:45:33PM +0800, Yijie Yang wrote:
> >>>
> >>>
> >>> On 2025-07-31 02:42, Dmitry Baryshkov wrote:
> >>>> On Wed, Jul 30, 2025 at 02:28:25PM +0800, Yijie Yang wrote:
> >>>>>
> >>>>>
> >>>>> On 2025-07-29 18:37, Dmitry Baryshkov wrote:
> >>>>>> On Tue, Jul 29, 2025 at 09:32:00AM +0800, Yijie Yang wrote:
> >>>>>>> The HAMOA-IOT-EVK is an evaluation platform for IoT products, composed of
> >>>>>>> the Hamoa IoT SoM and a carrier board. Together, they form a complete
> >>>>>>> embedded system capable of booting to UART.
> >>>>>>>
> >>>>>>> This change enables and overlays the following peripherals on the carrier
> >>>>>>> board:
> >>>>>>> - UART
> >>>>>>> - On-board regulators
> >>>>>>> - USB Type-C mux
> >>>>>>> - Pinctrl
> >>>>>>> - Embedded USB (EUSB) repeaters
> >>>>>>> - NVMe
> >>>>>>> - pmic-glink
> >>>>>>> - USB DisplayPorts
> >>>>>>>
> >>>>
> >>>>
> >>>>>>> +    vreg_rtmr0_1p15: regulator-rtmr0-1p15 {
> >>>>>>
> >>>>>> Hmm, so there are regulators for the retimer, but they are not used.
> >>>>>> Could you please point out, why?
> >>>>>
> >>>>> According to the schematic, there is a regulator and a retimer (PS8830).
> >>>>> However, as mentioned above, the retimer is not connected to USB 0 and is
> >>>>> therefore not used in the EVK. As a result, the regulator is left unused in
> >>>>> this context.
> >>>>
> >>>> What is connected to the retimer then?
> >>>
> >>> All data lines are broken, except for some power lines.
> >>
> >> Ok. please add a comment. If the retimer is connected to I2C bus, please
> >> define it too.
> > 
> > It’s not connected to I2C. I will add a comment here.
> > 
> >>
> >>>
> >>>>
> >>>>>
> >>>>>>
> >>>>>>> +        compatible = "regulator-fixed";
> >>>>>>> +
> >>>>
> >>>> [...]
> >>>>
> >>>>>>> +
> >>>>>>> +    usb_1_ss0_sbu_default: usb-1-ss0-sbu-state {
> >>>>>>> +        mode-pins {
> >>>>>>> +            pins = "gpio166";
> >>>>>>> +            function = "gpio";
> >>>>>>> +            bias-disable;
> >>>>>>> +            drive-strength = <2>;
> >>>>>>> +            output-high;
> >>>>>>
> >>>>>> What does this pin do? It's not recommended to set GPIO values through
> >>>>>> pinctrl.
> >>>>>
> >>>>> It is used to switch data lines between USB Type-C orientation detection and
> >>>>> DisplayPort AUX channels.
> >>>>
> >>>> I don't think I follow it here. Which data lines? Type-C orientation
> >>>> detection uses CC1 / CC2, DP AUX use SBU lines.
> >>>
> >>> I made a mistake here — this pin switches between two data sources: one is
> >>> DP AUX, and the other is a GPIO pair configured with the function
> >>> usb0_sbrx/usb0_sbtx. Both data sources originate from the SoC and are routed
> >>> to the USB0_SBU1 and USB0_SBU2 lines of the USB Type-C connector.
> >>
> >> So, it's some USB4 stuff. Ideally it should be described via the
> >> gpio-sbu-mux, but I don't think we can do that for now. I'd let Bjorn,
> >> Konrad or Abel comment on this.
> > 
> > Sure.
> 
> There is no DT representation of USB4 hardware at the moment, feel
> free to pretend it doesn't exist for now.
> 
> If we wanted to be hyper-correct, the way USB(3) is plugged into the
> bigger picture isn't quite pristine either, but that's a story for
> another day - need some puzzle pieces to come together first

Ack. Then the current description is fine.

-- 
With best wishes
Dmitry