[DONOTAPPLY RFC PATCH v2 4/4] arm64: dts: samsung,coreprimevelte: add wifi node
Duje Mihanović
duje at dujemihanovic.xyz
Fri Dec 12 06:55:48 PST 2025
On 12/12/25 09:36, Karel Balej wrote:
> Brian Norris, 2025-12-03T13:47:27-08:00:
>>
>> Do we have a min/max voltage for this regulator?
>
> The downstream node is defined with the same values as the above ldo14,
> they however are however only defined in the PMIC dtsi and correspond to
> the actual physical limits of the regulator specified also in the
> driver, so this doesn't really give any specific constraints for the
> board itself.
>
> The downstream code enabling WiFi seems to force it to 3300000 (which
> also seems to be the startup value) unconditionally, so I suppose I will
> just set the both limits to this value?
This sounds reasonable to me.
>>
>>> + };
>>> };
>>> };
>>> };
>>> @@ -523,6 +531,13 @@ &sdh1 {
>>> pinctrl-1 = <&sdh1_fast_pins_0 &sdh1_fast_pins_1 &sdh1_pins_2>;
>>> bus-width = <4>;
>>> non-removable;
>>> + #address-cells = <1>;
>>> + #size-cells = <0>;
>>
>> I wonder if this should have:
>>
>> vmmc-supply = <&ldo16>;
>>
>> rather than regulator-always-on above.
>
> You mean ldo15 right?
>
> Not having any board schematics, I don't really know what exactly the
> regulator's purpose is. As I mentioned in the commit message, the
> communication with the chipset seems to work even if this is disabled
> (e. g. FW loads, networks can be scanned for,...) which doesn't seem
> like it should be the case if this was a main power supply for the bus,
> only actual connecting to networks doesn't work (gives
> CONNECT_ERR_ASSOC_ERR_TIMEOUT errors).
To me, this strongly suggests that the regulator powers the WiFi
transmitter or at least a part of it (such as the RF amp).
> So this didn't seem too fitting for either vmmc nor vqmmc as far as I
> understand their semantics, so I went with the regulator-always-on
> approach to be safe.
Considering the above, I'd reckon it'd be good to have the option to
toggle it for rfkill if anything. I'm however not sure what would be the
right way to do so, nor how rfkill even works, if at all, with mwifiex
(from what I see, the driver does not use the API).
Regards,
--
Duje
More information about the linux-arm-kernel
mailing list