IMX8MP: Failed to register regulator

Technical Support
, , ,
1

Hi,

during Linux kernel boot I get the following error in the console:

[ 1.267553] reg-fixed-voltage regulator-module-eth1phy: Failed to register regulator: -517

I’m using Toradex BSP 5.6.0-devel-202202 with an Verdin Plus V1.0 Module and a custom carrier board. For the carrier board I created a device-tree file that includes the .dtsi files from Toradex. So I did not patch or modify the file imx8mp-verdin.dtsi, where this On-SOM-module regulator “regulator-module-eth1phy” is defined.

What is the problem here and how can I get rid of the error?
The eth1 interface is actually working, but I do not find any problems in the dev-tree.

The custom carrier board .dts file looks like this:

/dts-v1/;

#include "imx8mp-verdin.dtsi"
#include "imx8mp-verdin-nonwifi.dtsi"

/ {
	model = "Toradex Verdin iMX8M Plus on Verdin Development Board";
	compatible = "toradex,verdin-imx8mp-nonwifi-dev",
		     "toradex,verdin-imx8mp-nonwifi",
		     "toradex,verdin-imx8mp",
		     "fsl,imx8mp";

    /* Carrier Board Supply +V3.3 */
    reg_3p3v: regulator-3p3v {
        compatible = "regulator-fixed";
        regulator-max-microvolt = <3300000>;
        regulator-min-microvolt = <3300000>;
        regulator-name = "+V3.3_SW";
    };
};

&pinctrl_uart1 {
	fsl,pins = <
		MX8MP_IOMUXC_UART1_RXD__UART1_DCE_RX		0x1c4	/* SODIMM 129 */
		MX8MP_IOMUXC_UART1_TXD__UART1_DCE_TX		0x1c4	/* SODIMM 131 */
		/*
		MX8MP_IOMUXC_SAI2_TXFS__UART1_DCE_CTS		0x1c4	// SODIMM 133 
		MX8MP_IOMUXC_SAI2_RXD0__UART1_DCE_RTS		0x1c4	// SODIMM 135 
		*/
	>;
};

&fec {
	fsl,magic-packet;
	phy-supply = <&reg_3p3v>;
	phy-handle = <&ethphy1>;
	phy-mode = "rgmii-id";
	pinctrl-names = "default", "sleep";
	pinctrl-0 = <&pinctrl_fec>;
	pinctrl-1 = <&pinctrl_fec_sleep>;
	status = "okay";

	mdio {
		#address-cells = <1>;
		#size-cells = <0>;

		/delete-node/ ethernet-phy@7;

		ethphy1: ethernet-phy@3 {
			compatible = "ethernet-phy-ieee802.3-c22";
			interrupt-parent = <&gpio4>;
			interrupts = <18 IRQ_TYPE_LEVEL_LOW>;
			micrel,led-mode = <0>;
			eee-broken-100tx;
			eee-broken-1000t;
			reg = <3>;
		};
	};
};

&rtc_i2c {
	aux-voltage-chargeable = <1>;
};

/* Verdin SPI_1 */
&ecspi1 {
	/* enabled in dev-tree overlay for et1100 */
	status = "disabled";

	spidev10: spidev@0 {
		compatible = "toradex,evalspi";
		reg = <0>;
		spi-max-frequency = <10000000>;
		status = "okay";
	};
};

/* EEPROM on display adapter boards */
&eeprom_display_adapter {
	status = "okay";
};

/* EEPROM on Verdin Development board */
&eeprom_carrier_board {
	status = "disabled";
};

&eqos {
	status = "okay";
};

&flexcan1 {
	status = "okay";
};

&flexcan2 {
	status = "okay";
};

/* Verdin QSPI_1 */
&flexspi {
	status = "disabled";
};

/* Current measurement into module VCC */
&hwmon {
	status = "okay";
};

&hwmon_temp {
	status = "okay";
};

/* Verdin I2C_2_DSI */
&i2c2 {
	status = "okay";
};

&i2c3 {
	status = "okay";
};

&i2c4 {
	status = "okay";
};

/* Verdin PCIE_1 */
&pcie {
	epdev_on-supply = <&reg_3p3v>;
	status = "disabled";
};

&pcie_phy{
	status = "disabled";
};

/* Verdin PWM_1 */
&pwm1 {
	status = "okay";
};

/* Verdin PWM_2 */
&pwm2 {
	status = "okay";
};

/* Verdin PWM_3_DSI */
&pwm3 {
	status = "okay";
};

&reg_usdhc2_vmmc {
	vin-supply = <&reg_3p3v>;
};

/* VERDIN I2S_1 */
&sai1 {
	status = "disabled";
};

/* Verdin UART_1 */
&uart1 {
	status = "okay";
};

/* Verdin UART_2 */
&uart2 {
	status = "okay";
};

/* Verdin UART_3, used as the Linux Console */
&uart3 {
	status = "okay";
};

/* Verdin USB_1 */
&usb3_phy0 {
	status = "okay";
};

&usb3_0 {
	status = "okay";
};

&usb_dwc3_0 {
	status = "okay";
};

/* Verdin USB_2 */
&usb3_phy1 {
	status = "okay";
};

&usb3_1 {
	status = "okay";
};

&usb_dwc3_1 {
	status = "okay";
};

/* Verdin SD_1 */
&usdhc2 {
	status = "okay";
};

Thanks in advance!
Regards, Ralph

2

Hi @Ralph ,

We tested it on our side and we can also see this error message.

This error message seems to be harmless. Does this pose any issues on your side ? If so can you share more insight?

Best Regards
Kevin

3

Hi @kevin,

right now I do not see any negative impacts from this error message. But I’d prefer to have a bootup sequence without any error messages.
It also seems odd to me that it cannot be fixed somehow? Obviously the kernel sees an issue with this regulator…

BR Ralph

4

Hi @Ralph ,

Thanks for your answer.

As it seems this is not a blocking issue on your side as well as on our side. Anyway, we will collect your feedback and also do some further tests to report it internally.

We reach out to you here, as soon as we have new information. Feel free to add any new information you might come across.

Best Regards
Kevin

5

Hi @Ralph ,

I got some new information for you.

So the situation is the following:

The message you see with code -517 is not an actual error. This is the way, the driver reports to the kernel that a certain module that is needed by the driver is not ready, which is why the driver couldn’t be initialized. This is caused by the parallelization process while booting. Following this, the driver will automatically try again at a later point in time. If the driver succeeds no further messages are displayed and all is as it should be.

If you have unresolved messages at the end of a boot, this would mean that a certain module is trying to get something that is not there even if the boot process was completed. That would then mean that some configuration is not ideal.

Hope this helped.

Best Regards
Kevin