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 <balejk@matfyz.cz>
---
 .../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;
+			};
 		};
 	};
 };
@@ -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>;
+
+	wifi@1 {
+		compatible = "marvell,sd8777";
+		reg = <1>;
+	};
 };
 
 &pwm3 {
-- 
2.51.1

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 <balejk@matfyz.cz>
> ---
>  .../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?

> +			};
>  		};
>  	};
>  };
> @@ -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.

Brian

> +
> +	wifi@1 {
> +		compatible = "marvell,sd8777";
> +		reg = <1>;
> +	};
>  };
>  
>  &pwm3 {
> -- 
> 2.51.1
>

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 <balejk@matfyz.cz>
>> ---
>>  .../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.

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

Duje Mihanović, 2025-12-12T15:55:48+01:00:
> On 12/12/25 09:36, Karel Balej wrote:
>>>> +			};
>>>>   		};
>>>>   	};
>>>>   };
>>>> @@ -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).

Something like this occurred to me too but would the chip even see the
networks if this was the case? Although you are right that it could only
power some specific part of the radio.

>> 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).

I have experimented with rfkill here before. The chip has a specific pin
for this so I don't think handling the regulator alone would suffice.
But yes, it should certainly be associated with the rfkill if possible
so that it could be turned off to save power when the radio is disabled.

Brian, is it possible to attach the rfkill pin (and ideally this
regulator) to the wireless device solely through the device tree in some
generic way or must this be implemented in the driver? I have
experimented with the rfkill-gpio driver in the past but it appeared as
a separate rfkill device with its own controls independent of the
mwifiex device and I could only soft block both (soft blocking the
rfkill-gpio device of course had effect on the wifi though).

Regards,
K. B.

On Friday, 12 December 2025 22:17:12 Central European Standard Time Karel 
Balej wrote:
> Duje Mihanović, 2025-12-12T15:55:48+01:00:
> > On 12/12/25 09:36, Karel Balej wrote:
> >> 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).
> 
> Something like this occurred to me too but would the chip even see the
> networks if this was the case? Although you are right that it could only
> power some specific part of the radio.

AFAIK you don't need the transmitter to capture and parse beacon frames. Of 
course, connecting to networks is a completely different story.

Regards,
--
Duje