SDK 2.3.0 - can't disable qspi in DT overlay file?

We have just migrated the software for our custom nrf5340 based board from SDK v1.9.1 to v2.3.0.
Everything seems to be working well but we have one issue with the nrf5340dk_nrf5340_cpuapp.overlay file.

We have two GPIO's (pins 13 & 18) that we use that conflict with the pins assigned to the qspi device pre-configured in the
/nordic/ncs/v2.3.0/zephyr/boards/arm/nrf5340dk_nrf5340/nrf5340_cpuapp_common.dts file.

One of those custom GPIO's (pin 13) is used to disconnect the battery from the device (!!) and the other is used to switch off power to our i2c peripherals.
We can see that the pre-configured qspi device is defined in exactly the same way in SDK v1.9.1 & v2.3.0 (of course v2.3.0 uses the new pin control format), 
in the /nordic/ncs/v2.3.0/zephyr/boards/arm/nrf5340dk_nrf5340/nrf5340_cpuapp_common.dts file.

In BOTH SDK's, the qspi is defined with: status = "okay" in that nrf5340dk_nrf5340/nrf5340_cpuapp_common.dts file mentioned above.
So in theory there should be no difference in the way qspi is used (or rather NOT used!) between v1.9.1 & v2.3.0 builds.

In our v1.9.1 overlay file we never referenced the qspi device.  However, when we build with SDK v2.3.0 (after having followed all the migration steps),
we find that two of the GPIO pins we use, (pins 13 & 18) are suddenly oscillating even when we do NOT reference those pins in our code.
Plus all the voltage rails are much noisier (by around 0.3v) indicating contention. We also do not reference or use the qspi device in our code. 

After we investigated/debugged this, we found that this "problem" (in our v2.3.0 build) went away as soon as we disabled the qspi device - which makes sense & is OK. 

HOWEVER, the qspi device can NOT be disabled in the nrf5340dk_nrf5340_cpuapp.overlay file!!?? When we add:

&qspi {
	status = "disabled";
};


it has NO EFFECT and the problem described above (with pins 13 & 18) and the noise on all power rails remains.

So the only way we seem to be able to "get rid of" (= disable!) the qspi device, is to change the status from "okay" to "disabled" in the 
SDK file /nordic/ncs/v2.3.0/zephyr/boards/arm/nrf5340dk_nrf5340/nrf5340_cpuapp_common.dts

Although this solves our problem, obviously doing it this way is less than ideal (difficult to track/remember when one updates the SDK, etc) & it should be done in the overlay file.

So my question is: Why can the qspi device not be disabled in the SDK v2.3.0 overlay file?
Is this is bug in the v2.3.0 SDK? Or is there another way to do this in our v2.3.0 overlay file?
We also disable a number of other devices (like all uart's, etc) in our v2.3.0 overlay file, so we know the file itself is working and being included in our build.
There are no new warnings in our v2.3.0 build (vs. the v1.9.1 builds).

What is also strange to us is that in the SDK v1.9.1 builds, we didn't even have to disable the qspi device (as we never had that issue with pins 13 & 18 with our v1.9.1 builds).
As I mentioned our hardware design & software NEVER references or uses the qspi device.

Below is our SDK v2.3.0 overlay file:

&pinctrl {
	uart0_default_alt: uart0_default_alt {
		group1 {
			psels = <NRF_PSEL(UART_TX, 1, 4)>,
				<NRF_PSEL(UART_RTS, 1, 6)>;
		};
		group2 {
			psels = <NRF_PSEL(UART_RX, 1, 5)>,
				<NRF_PSEL(UART_CTS, 1, 7)>;
			bias-pull-up;
		};
	};

	uart0_sleep_alt: uart0_sleep_alt {
		group1 {
			psels = <NRF_PSEL(UART_TX, 1, 4)>,
				<NRF_PSEL(UART_RX, 1, 5)>,
				<NRF_PSEL(UART_RTS, 1, 6)>,
				<NRF_PSEL(UART_CTS, 1, 7)>;
			low-power-enable;
		};
	};
	
	i2c1_default: i2c1_default {
		group1 {
			psels = <NRF_PSEL(TWIM_SDA, 1, 2)>,
				<NRF_PSEL(TWIM_SCL, 1, 3)>;
			bias-pull-up;
			nordic,drive-mode = < NRF_DRIVE_S0D1 >;
		};
	};

	i2c1_sleep: i2c1_sleep {
		group1 {
			psels = <NRF_PSEL(TWIM_SDA, 1, 2)>,
				<NRF_PSEL(TWIM_SCL, 1, 3)>;
			low-power-enable;
		};
	};
};

&adc {
	status = "okay";
};

&gpio0 {
	status = "okay";
};
&gpio1 {
	status = "okay";
};

&gpiote {
	status = "disabled";
};

&qspi {
	status = "disabled";
};

&i2c1 {
	status = "okay";
    accelerometer: accelerometer@5 {
        compatible = "i2c-device";
        reg = < 0x05 >;
        label = "ACCELEROMETER";
    };
	tdksensor: TDKsensor@8 {
        compatible = "i2c-device";
        reg = < 0x08 >;
        label = "TDKSENSOR";
    };
};
&i2c0 {
	status = "disabled";
};
&i2c2 {
	status = "disabled";
};

&uart0 {
	status = "disabled";
    pinctrl-0 = <&uart0_default_alt>;
    pinctrl-1 = <&uart0_sleep_alt>;
    pinctrl-names = "default", "sleep";
};
&uart1 {
	status = "disabled";
};
&uart2 {
	status = "disabled";
};
&uart3 {
	status = "disabled";
};

&led0 {
	status = "disabled";
};
&led1 {
	status = "disabled";
};
&led2 {
	status = "disabled";
};
&led3 {
	status = "disabled";
};

&pwm_led0 {
	status = "disabled";
};

&spi0 {
	status = "disabled";
};
&spi1 {
	status = "disabled";
};
&spi2 {
	status = "disabled";
};
&spi3 {
	status = "disabled";
};
&spi4 {
	status = "disabled";
};

&button0 {
	status = "disabled";
};
&button1 {
	status = "disabled";
};
&button2 {
	status = "disabled";
};
&button3 {
	status = "disabled";
};

&zephyr_udc0 {
    status = "disabled";
	/*
	cdc_acm_uart0: cdc_acm_uart0 {
		compatible = "zephyr,cdc-acm-uart";
		label = "CDC_ACM_0";
	};
	*/
};
/*
/ {
	chosen {
			zephyr,console = &cdc_acm_uart0;
	};
};
*/

Thanks

Gerard
 

Related