On 26-02-06, Ahmad Fatoum wrote:
> Hi,
> 
> On 2/5/26 4:45 PM, Marco Felsch wrote:

...

> > +   };
> > +
> > +   /*
> > +    * Prohibit OP-TEE from turning of the UART output if enabled via
> > +    * CFG_UART_BASE. To do so we need to specify a stdout-path which
> > +    * doesn't exist else OP-TEE turns off the UART.
> > +    */
> > +   secure-chosen {
> > +           stdout-path = "/this-path/does/not/exist";
> 
> ... :/
> 
> > +&usdhc3 { /* eMMC */
> > +   assigned-clocks = <&clk IMX8MM_CLK_USDHC3_ROOT>;
> > +   assigned-clock-rates = <400000000>;
> > +   pinctrl-names = "default", "state_100mhz", "state_200mhz";
> > +   pinctrl-0 = <&pinctrl_usdhc3>;
> > +   pinctrl-1 = <&pinctrl_usdhc3_100mhz>;
> > +   pinctrl-2 = <&pinctrl_usdhc3_200mhz>;
> > +   bus-width = <8>;
> > +   non-removable;
> 
> no-sd;
> no-sdio;
> 
> to skip their detect?

Yes, thanks!

> > +   pinctrl_gpio1: gpio1grp {
> > +           fsl,pins = <
> > +                   MX8MM_IOMUXC_GPIO1_IO10_GPIO1_IO10              0x100
> 
> This looks a bit unconventional. Can't the consumer select this group?

Good catch, this was required before we had the EFI driver. I will adapt
the driver to request the pin accordingly.

> > +config BOARD_HGS
> > +   bool
> > +   select ARCH_IMX_ATF_PASS_BL_PARAMS
> > +   select ARM_SMCCC
> > +   select FIRMWARE_IMX_LPDDR4_PMU_TRAIN
> > +   select I2C_IMX_EARLY
> > +   select IMX8M_DRAM
> > +   select HABV4
> 
> Do you need to select this one? I think it would be better without to
> allow it to be enabled in the defconfig without flipping HABv4 on for
> all other boards?

Good point albeit this is secure-boot only platform it makes sense to
enable it within the defconfig to benefit from the CI. We don't have a
good CI setup for secure-boot builds, right?

> > +static int hgs_console_open_fixup(struct device_node *root, void *context)
> > +{
> > +   struct hgs_machine *machine = context;
> > +   struct device_node *console_np;
> > +   struct property *property;
> > +
> > +   console_np = of_find_node_by_alias(root, machine->console_alias);
> > +   if (!console_np)
> > +           return -EINVAL;
> > +
> > +   property = of_rename_property(console_np, "pinctrl-1", "pinctrl-0");
> 
> Does this not yield an invalid DT when passed to the kernel?
> I think you want to either keep pinctrl-1 as is or shorten pinctrl-names
> as well.

FYI, what the kernel-DT is doing:

| pinctrl-names = "default";
| pinctrl-0 = <&pinctrl_uart3_gpio>;
| pinctrl-1 = <&pinctrl_uart3>;

The of_rename_property() will delete the pinctrl-0 first and and later
on renames pinctrl-1 to pinctrl-0. Therefore we don't have issues with
invalid DTs.

This is a bit different to the barebox-DT since for the barebox-DT but
could be aligned later in either way of course!

> > +   pinctrl = pinctrl_get_select(console->dev, "uart");
> 
> Nitpick: I think a name like "open" might be clearer?

IMHO pinctrl "uart" is easier to understand given the context that this
function is called within hgs_open_console(). What would be a "open"
console mean?

Regards,
  Marco

> 
> 
> Cheers,
> Ahmad
> 
> -- 
> Pengutronix e.K.                  |                             |
> Steuerwalder Str. 21              | http://www.pengutronix.de/  |
> 31137 Hildesheim, Germany         | Phone: +49-5121-206917-0    |
> Amtsgericht Hildesheim, HRA 2686  | Fax:   +49-5121-206917-5555 |
> 
> 

-- 
#gernperDu 
#CallMeByMyFirstName

Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | https://www.pengutronix.de/ |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-9    |

Reply via email to