[PATCH v2 11/11] RAS: add DeviceTree firmware-first CPER provider

Jonathan Cameron jonathan.cameron at huawei.com
Thu Mar 12 07:50:06 PDT 2026


> >> +Firmware-first CPER via DeviceTree
> >> +----------------------------------
> >> +
> >> +Some systems expose Common Platform Error Record (CPER) data
> >> +via DeviceTree instead of ACPI HEST tables.  
> > 
> > I'd argue this isn't really DT specific, it's just not ACPI table.
> > You could for instance use PRP0001 and wire this up on ACPI with only
> > one trivial change to generic property.h accessor for the boolean.
> > 
> > Or use another firmware information source entirely.  
> 
> I'm intentionally keeping the scope DT-only for this series,
> so I'll keep the wording DT-focused.

Why?  Generally when the support works fine with generic firmware
accessors that's preferred because there are no real disadvantages.

> >> +#include <acpi/ghes.h>
> >> +#include <acpi/ghes_cper.h>
> >> +
> >> +static atomic_t ghes_ffh_source_ids = ATOMIC_INIT(0);  
> > I'd normally expect an IDA or similar. If nothing else it clearly
> > indicates we only want a unique ID.  
> 
> I'll keep the atomic for now; it's just a monotonic unique ID with no
> lifetime tracking. If you strongly prefer IDA I can switch.

If it doesn't 'need' to be monotonic due to some design issue then
yes I'd prefer an IDA.


> >> +	spinlock_t lock;
> >> +};  
> > 
> >   
> >> +
> >> +static void ghes_ffh_process(struct ghes_ffh *ctx)
> >> +{
> >> +	unsigned long flags;
> >> +	int sev;
> >> +
> >> +	spin_lock_irqsave(&ctx->lock, flags);  
> > 
> > guard() + include cleanup.h. Then can do returns in error paths.  
> 
> Agreed. I'll switch to guard() and include <linux/cleanup.h>.
A general process thing.  If you agree with a suggestion, just
do it and crop that section of the email thread out.
Reply that you agree tends not to benefit anyone!


> 
> >> +			ghes_estatus_cache_add(ctx->generic, ctx->estatus);
> >> +	}
> >> +
> >> +	ghes_cper_handle_status(ctx->dev, ctx->generic, ctx->estatus, ctx->sync);
> >> +
> >> +	ghes_ffh_ack(ctx);
> >> +
> >> +out:
> >> +	spin_unlock_irqrestore(&ctx->lock, flags);
> >> +}
...

> >> +{
> >> +	struct ghes_ffh *ctx;
> >> +	struct resource *res;
> >> +	int rc;
> >> +
> >> +	ctx = devm_kzalloc(&pdev->dev, sizeof(*ctx), GFP_KERNEL);
> >> +	if (!ctx)
> >> +		return -ENOMEM;
> >> +
> >> +	spin_lock_init(&ctx->lock);
> >> +	ctx->dev = &pdev->dev;
> >> +	ctx->sync = of_property_read_bool(pdev->dev.of_node, "arm,sea-notify");  
> > Hmm. I'd allow for other firmware types with
> > 	device_property_read_bool() instead.  
> 
> Given DT-only scope, I'll keep of_property_read_bool() here.
> 
> >> +
> >> +	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> >> +	if (!res) {
> >> +		dev_err(&pdev->dev, "status region missing\n");  

Jonathan




More information about the linux-arm-kernel mailing list