Re: [PATCH v4 3/3] arm64: dts: qcom: Add Vicharak Axon Mini

[Konrad Dybcio]

On 6/18/26 8:29 AM, Ajit Singh wrote:
> On Tue, Jun 16, 2026 at 02:10:44PM +0530, Konrad Dybcio wrote:
>> On 6/12/26 6:16 AM, Ajit Singh wrote:
>>> On Wed, Jun 10, 2026 at 02:58:19PM +0530, Konrad Dybcio wrote:
>>>> On 6/7/26 1:36 PM, Ajit Singh wrote:
>>>>> Add DTS for the Vicharak Axon Mini board based on the Qualcomm
>>>>> QCS6490 SoC.
>>>>>
>>>>> This adds debug UART, eMMC, UFS, SDIO WLAN, USB 2.0 host, PCIe
>>>>> support along with regulators.
>>>>>
>>>>> The UFS ICE block is kept disabled because enabling it currently causes
>>>>> an SError during qcom_ice_create() on this board. UFS works without ICE.
>>>>>
>>>>> Signed-off-by: Ajit Singh <blfizzyy@xxxxxxxxx>
>>>>> ---
>>>>
>>>> [...]
>>>>
>>>>> +		vreg_l12c_1p8: ldo12 {
>>>>> +			regulator-name = "vreg_l12c_1p8";
>>>>> +			regulator-min-microvolt = <1800000>;
>>>>> +			regulator-max-microvolt = <2000000>;
>>>>> +			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
>>>>> +
>>>>> +			/*
>>>>> +			 * VREG_L12C_1P8 supplies the Ampak WLAN/BT module
>>>>> +			 * VDDIO and the external 32.768 kHz oscillator.
>>>>> +			 */
>>>>
>>>> Sorry for the long review timelines on the previous patch, many of us
>>>> were out for conferences..
>>>>
>>>> Is the oscillator used for that WLAN module? Would you ideally like to
>>>> be able to turn it on/off?
>>>
>>> yes, oscillator is used for WLAN modules. Oscillator is powered from the same
>>> VREG_L12C rail as WLAN VDDIO, so there is no separate regulator control to put
>>> in pwrseq. So I think this will work fine?
>>
>> Probably? My point is that you marked it as always-on, so it will *never*
>> turn off right now. For e.g. Qualcomm wifi, there's some timing spec that
>> needs to be met wrt delays between toggling various regulators and GPIOs
>> going to the module, hence I suggested you may need some pwrseq inbetween
>> to achieve reliable powering on/off
>>
> Right, I checked the module timing requirements.
> 
> The module requires VBAT to be present before or at the same time as VDDIO, and
> WL_REG_ON to be asserted only after VBAT/VDDIO are valid, around 2 sleep-clock
> cycles later.
> 
> On this board, VBAT is the shared VCC_3V3 rail and is enabled by hardware, so
> it is already present before VDDIO. VREG_L12C supplies WLAN/BT VDDIO and is
> kept on. The WL_REG_ON timing is handled by the existing mmc-pwrseq-simple
> reset GPIO/delay before SDIO enumeration.
> 
> So I think the current sequencing matches the module timing requirement.

Since the sequencing is handled, can we drop the always-on property,
perhaps by describing the SDIO WLAN?

e.g. in arch/arm/boot/dts/st/ste-ux500-samsung-codina-tmo.dts there is:

/* WLAN SDIO channel */
mmc@80118000 {
	arm,primecell-periphid = <0x10480180>;
	max-frequency = <50000000>;
	bus-width = <4>;
	non-removable;
	cap-sd-highspeed;
	pinctrl-names = "default", "sleep";
	pinctrl-0 = <&mc1_a_2_default>;
	pinctrl-1 = <&mc1_a_2_sleep>;
	/*
		* GPIO-controlled voltage enablement: this drives
		* the WL_REG_ON line high when we use this device.
		* Represented as regulator to fill OCR mask.
		*/
	vmmc-supply = <&wl_reg>;

	#address-cells = <1>;
	#size-cells = <0>;
	status = "okay";

	wifi@1 {
		compatible = "brcm,bcm4334-fmac", "brcm,bcm4329-fmac";
		reg = <1>;
		/* GPIO216 WL_HOST_WAKE */
		interrupt-parent = <&gpio6>;
		interrupts = <24 IRQ_TYPE_EDGE_FALLING>;
		interrupt-names = "host-wake";
		pinctrl-names = "default";
		pinctrl-0 = <&wlan_default_mode>;
	};
};

most notably though, it seems that the brcmfmac driver doesn't even use
the regulator framework, probably because all of the SDIO WLANs that
Linux supports were wired in a more "embedded" way, where the V(Q)MMC
supplies were enough.. unless it's the case here too?

Konrad