[PATCH v1 2/3] riscv: cache: Add CBO instructions

[Mayuresh Chitale]

On Wed, Aug 21, 2024 at 3:33 PM <Conor.Dooley at microchip.com> wrote:
>
> On 21/08/2024 10:57, Conor Dooley wrote:
> > 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.
>
> To be clear, I did notice that if the dev_read_u32() does not populate
> zicbom_block_size no cache ops will be done. My question was about
> the behaviour relating to the config option and or emitting warnings etc.
I am planning to add a info message if the config option is enabled
but the dt property is not found.
>
> Cheers,
> Conor.