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

[<Conor.Dooley@microchip.com>]

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.

Cheers,
Conor.