Re: [PATCH v5 3/6] arm64: dts: qcom: Add AYN QCS8550 Common

[Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>]

On 4/27/26 12:01 AM, Aaron Kling wrote:
> On Fri, Apr 24, 2026 at 7:11 AM Konrad Dybcio
> <konrad.dybcio@oss.qualcomm.com> wrote:
>>
>> On 4/8/26 9:41 PM, Aaron Kling via B4 Relay wrote:
>>> From: Teguh Sobirin <teguh@sobir.in>
>>>
>>> This contains everything common between the AYN QCS8550 devices. It will
>>> be included by device specific dts'.
>>>
>>> Signed-off-by: Teguh Sobirin <teguh@sobir.in>
>>> Co-developed-by: Aaron Kling <webgeek1234@gmail.com>
>>> Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
>>> ---

[...]
>>> +&pm8550_gpios {
>>> +     fan_pwm_active: fan-pwm-active-state {
>>> +             pins = "gpio8";
>>> +             function = "func1";
>>> +             input-disable;
>>> +             output-enable;
>>> +             output-low;
>>
>> Looks like this should be a regulator then, probably?
> 
> Mmm, what would it be tied to, then? The fan already has a reg. I
> presume just modeling it as an always on reg tied to nothing is
> undesirable. I also have no idea what the voltage would be.

Or maybe it's some sort of reset/enable GPIO. Or an enable pin to
whatever feeds into VDD_FAN_5V0. It's hard to tell indeed.

> 
>> [...]
>>
>>> +     wcd_default: wcd-reset-n-active-state {
>>> +             pins = "gpio108";
>>> +             function = "gpio";
>>> +             drive-strength = <16>;
>>> +             bias-disable;
>>> +             output-low;
>>
>> no need for this property
> 
> I'll start with saying that I know basically nothing about qcom
> hardware design and what the average pinmuxing layout looks like. But
> I do note that a lot of existing devices have this exact same node,
> for example the sm8550 hdk [0]. Is there something that makes these
> devices different? Or is this unnecessary everywhere?

That's my understanding.

[...]

>>> +     usb0_sbu_default: usb0-sbu-state {
>>> +             oe-n-pins {
>>> +                     pins = "gpio140";
>>> +                     function = "gpio";
>>> +                     bias-disable;
>>> +                     drive-strength = <16>;
>>> +                     output-high;
>>
>> This is probably not required too.. unless there's a hw bug?
>>
>> fwiw 16 mA is a very high drive-strength - does this come from vendor
>> sources?
> 
> I do not see any pinmux for gpio140 in the downstream dt or anything
> matching pi3usb102 at all, I'm not sure how it's handled there. The
> original source of this dt was written before there was a public gpl
> code release from AYN. I do see other qcom users of the pi3usb102
> doing similar however, for example the sc8280xp crd [1]. So I've got
> the same question as above: is there something different here, or is
> it possible other existing copies of this are also wrong?

You can retrieve the settings from your device at runtime,
/sys/kernel/debug/gpio will read back the hw settings

As for the CRD, I don't know. It may as well be board-specific.

Konrad