Re: [PATCH 1/1] arm64: dts: qcom: monaco-evk: Add Mezzanine

[Bjorn Andersson]

On Mon, Feb 16, 2026 at 01:44:40PM +0530, Umang Chheda wrote:
> Hello Bjorn,
> 
> On 2/13/2026 1:33 AM, Bjorn Andersson wrote:
> > On Tue, Feb 10, 2026 at 04:08:21PM +0530, Umang Chheda wrote:
> >> diff --git a/arch/arm64/boot/dts/qcom/monaco-evk-mezzanine.dtso b/arch/arm64/boot/dts/qcom/monaco-evk-mezzanine.dtso
> > [..]
> >> +&i2c15 {
> >> +	#address-cells = <1>;
> >> +	#size-cells = <0>;
> > Do we need to repeat this? It's in the top-level i2c15 definition
> > already?
> 
> Yes this is required to be repeated in case of DTSO -- else seeing DT
> binding error if these cells are not added here. Seems the compiler is
> not looking at what is present in the Base DT first and is considering
> the default values for address and size cells and throwing error. Had
> to add similarly add for PCIe node as well to suppress binding errors.
> 

Understood, no concerns then. Thanks for helping me understand.

> >
> >> +
> >> +	status = "okay";
> > I presume this overlay is used on top of monaco-evk.dtb, which already
> > says that status is okay.
> 
> Ack
> 
> >
> >
> > That said, I don't see a "clock-frequency" in either node, so I presume
> > you have an error/warning in your kernel log about this. But unless you
> > have reason to change that in your overlay, I think that's a unrelated
> > patch on the monaco-evk.dts - which I would like you to send, separately.
> 
> 
> Ack, will share a separate patch to fix this issue.
> 
> >
> >> +
> >> +	eeprom1: eeprom@52 {
> >> +		compatible = "giantec,gt24c256c", "atmel,24c256";
> >> +		reg = <0x52>;
> >> +		pagesize = <64>;
> >> +
> >> +		nvmem-layout {
> >> +			compatible = "fixed-layout";
> >> +			#address-cells = <1>;
> >> +			#size-cells = <1>;
> >> +		};
> >> +	};
> >> +};
> >> +
> > [..]
> >> +&tlmm {
> >> +	tc9563_resx_n: tc9563-resx-state {
> >> +		pins = "gpio124";
> >> +		function = "gpio";
> >> +
> >> +		bias-disable;
> >> +		input-disable;
> >> +		output-enable;
> >> +		power-source = <0>;
> > Does these properties really match the TLMM binding? Please double
> > check.
> 
> Double checked on this -- all the properties match the TLMM bindings.
> 

I do believe the logic is binary, so input-disable == output-enable (in
contrast to the SPMI gpio binding, where those two are configured
separately). It's not listed among the valid properties for a
qcom-tlmm-state object, but perhaps I'm misremembering how the
dt-validator uses those properties.

But there's no "power-source" for TLMM, you should see an "Unsupported
config parameter" in the kernel log when you try to apply this setting.

Regards,
Bjorn

> >
> > Regards,
> > Bjorn
> >
> >> +	};
> >> +};
> >> --
> >> 2.34.1
> 
> 
> Thanks,
> Umang
>