Re: [PATCH v4 4/4] arm64: dts: qcom: Add IMDT QCS8550 SBC

[William Bright]

On Fri, Jun 26, 2026 at 05:18:20PM +0200, Konrad Dybcio wrote:
> > +&gpu_zap_shader {
> > +   firmware-name = "qcom/sm8550/a740_zap.mbn";
> > +   /* Zap shader doesn't load so is disabled */
>
> If your SoC is production fused, you must provide your own ZAP firmware
> that's signed by you. Conversely, if you have a software stack that
> does not include the Gunyah hypervisor, this is likely not necessary
I solved the zap shader failing to load a couple of days ago. U-boot
wasn't fixing up DT memory node correctly so I will enable the zap
shader in V5.
> > +   status = "disabled";
> > +};
> > +
> > +&i2c_master_hub_0 {
> > +   status = "okay";
> > +};
> > +
> > +&i2c_hub_2 {
> > +   clock-frequency = <400000>;
> > +   status = "okay";
>
> nit: let's keep a \n before status, everywhere
>
> [...]
>
Ack all of your above feedback regarding formatting, new lines and
ordering.
> > +
> > +   sd_vset_default: sd-vset-default-state {
> > +           sd-vset-pins {
> > +                   pins = "gpio4";
> > +                   function = "gpio";
> > +                   drive-strength = <16>;
> > +                   bias-disable;
> > +           };
> > +   };
> > +
> > +   /*
> > +    * Drive LAN743x reset high (de-asserted) when pcie1 probes,
> > +    * so the PHY enumerates on the bus.
> > +    */
> > +   gbe_reset_default: gbe-reset-default-state {
> > +           pins = "gpio138";
> > +           function = "gpio";
> > +           drive-strength = <2>;
> > +           bias-disable;
> > +           output-high;
> > +   };
> > +
> > +   /*
> > +    * We drive this GPIO physically high on the M2 Key-E connector
> > +    * to make sure the module is enabled. An M2 Key-E module could
> > +    * be using this pin as a chip enable.
> > +    */
> > +   m2e_sdio_resetn_default: m2e-sdio-resetn-default-state {
> > +           pins = "gpio41";
> > +           function = "gpio";
> > +           drive-strength = <2>;
> > +           bias-disable;
> > +           output-high;
> > +   };
> > +
> > +   /* Force the on-board PCIe switch to select the GbE upstream
> > +    * port.
> > +    */
> > +   pcie_switch_sel_default: pcie-switch-sel-default-state {
> > +           pins = "gpio16";
> > +           function = "gpio";
> > +           drive-strength = <2>;
> > +           bias-disable;
> > +           output-low;
> > +   };
>
> Normally this would be handled via an actual driver - see e.g.
>
> Documentation/devicetree/bindings/pci/toshiba,tc9563.yaml
> https://lore.kernel.org/linux-arm-msm/20260605010022.968612-1-elder@xxxxxxxxxxxx/
>
> Konrad
>
The PCIe switch we are using is a NXP CBTU02044HEJ, this is a simple
1->2 switch that is not PCIe enumerable. Given that there isn't support
for this IC already in the kernel and that it will take quite a few
weeks/months for me to cobble something together, I am thinking that it
might make sense to drop PCIe support from this patch-series in V5 and
then submit a seperate patch-series with a driver and bindings for this
IC whenever I get something working. Are you OK with this?
> > +&usb_1 {
> > +   /delete-property/ usb-role-switch;
> > +   dr_mode = "peripheral";
>
> Is it really peripheral-only?
>
> Konrad
On the SBC we have a TUSB321 for role and orientation detection. I will
add this into the DT in V5 so that both roles are supported.

Thanks again for your feedback,

Will