Brian Norris, 2025-12-03T13:47:27-08:00:
> On Sun, Oct 26, 2025 at 07:20:41PM +0100, Karel Balej wrote:
>> Add a node for the phone's WiFi serviced by the Marvell SD8777 chip a
>> communication with which happens over the SDIO. Also enable a regulator
>> without which it is not possible to connect to networks although they
>> are discovered properly.
>>
>> Signed-off-by: Karel Balej <[email protected]>
>> ---
>> .../mmp/pxa1908-samsung-coreprimevelte.dts | 15 +++++++++++++++
>> 1 file changed, 15 insertions(+)
>>
>> diff --git
>> a/arch/arm64/boot/dts/marvell/mmp/pxa1908-samsung-coreprimevelte.dts
>> b/arch/arm64/boot/dts/marvell/mmp/pxa1908-samsung-coreprimevelte.dts
>> index b2ce5edd9c6a..36d6ae4e902e 100644
>> --- a/arch/arm64/boot/dts/marvell/mmp/pxa1908-samsung-coreprimevelte.dts
>> +++ b/arch/arm64/boot/dts/marvell/mmp/pxa1908-samsung-coreprimevelte.dts
>> @@ -475,6 +475,14 @@ ldo14: ldo14 {
>> regulator-min-microvolt = <1200000>;
>> regulator-max-microvolt = <3300000>;
>> };
>> +
>> + /*
>> + * Needs to be enabled in order for the WiFi to be able
>> + * to connect to networks.
>> + */
>> + ldo15 {
>> + regulator-always-on;
>
> 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?
>
>> + };
>> };
>> };
>> };
>> @@ -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).
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.
Thank you for the comments,
K. B.
