On Tue, Aug 20, 2024 at 02:14:01PM +0200, Heinrich Schuchardt wrote: > On 20.08.24 11:37, Mayuresh Chitale wrote: > > +void riscv_zicbom_init(void) > > +{ > > + struct udevice *dev; > > + > > + if (!CONFIG_IS_ENABLED(RISCV_ISA_ZICBOM)) > > + return; > > + > > + uclass_first_device(UCLASS_CPU, &dev); > > + if (!dev) { > > + log_err("Failed to get cpu device!\n"); > > + return; > > Please, return an error code. > > > + } > > + > > + (void)dev_read_u32(dev, "riscv,cbom-block-size", &zicbom_block_size); > > Please, do not ignore errors.
I'm curious what the policy of U-Boot is w.r.t. extension probing. Is it okay to enable the option for Zicbom even if your hardware does not support it, in which case riscv_zicbom_init() would be expected to fail gracefully and no CMOs done? Say, for example, you had two very similar chips, one with DMA non-coherent peripherals and one that only differed by having DMA coherent ones, and you wanted to run the same U-Boot binary on both devices using a devicetree passed from firmware.
signature.asc
Description: PGP signature