Re: [PATCH v5 5/5] alpha: decode Clipper environmental events and retain Tsunami console logs

[Matt Turner]

On Fri, Oct 9, 2026, Magnus Lindholm wrote:
> +static const char * const CLIPPER_EnvQW5DOOR[] = {
> + "",
> + "Set = System CPU door is open",
> + "Set = System Fan door is open",
> + "Set = System PCI door is open",

The "Set = " looks like it came along from the table in the manual.
"System CPU door is open" reads better in a log.

> + if (!(status & MCHK_DISPOSITION_REPORT))
> + return MCHK_DISPOSITION_DISMISS;

An event with no fault bit set is dropped, so a recovery (door closed,
supply back) is silent unless some other fault bit is still set. If I
read your cover letter right, the "enabled again" report in the PSU test
was only printed because SMIR bit 0 stayed set. Is that intended? I
think I would want to see the recovery.

> +void __init
> +tsunami_init_pci(void)
> +{
> + size_t i;
> +
> + for (i = 0; i < ARRAY_SIZE(el_tsunami_annotations); i++)
> + cdl_register_subpacket_annotation(&el_tsunami_annotations[i]);
> + cdl_register_subpacket_handler(&tsunami_subpacket_handler);
> + ev6_register_error_handlers();
> + cdl_check_console_data_log();
> + common_init_pci();
> +}

Two things here.

cdl_check_console_data_log() follows console_data_log_pa from the HWRPB
on every Tsunami board now, and this has run on an ES40 only. It is fine
on QEMU's clipper, which I booted, but there the log is empty. I do not
know what older DS10, DS20 or XP1000 firmware leaves in that field, and
a bad pointer would mean a crash during boot. Can anyone on the list try
it on one of those?

It is also odd to have the PCI init hook in the error file. Titan has
titan_register_error_handlers() in err_titan.c and leaves the init_pci
hook in sys_titan.c, which calls cdl_check_console_data_log() itself.
The same split would work here.

The table sizes all match their masks, and the subpacket length checks
look right to me.