Re: [PATCH] firmware: google: fix orphaned devices on partial populate failure

[Titouan Ameline]

Thanks for feedback. You are right that the distinction matters

Looking at what device_register() can realistically return in this context:
it calls device_add(),  which can fail with -ENOMEM during
kobject/sysfs setup, or with -EEXIST if the device name already exists
in sysfs.

 -ENOMEM is systemic and means subsequent entries will also fail,
while -EEXIST would be entry-specific
so a duplicate name for one entry shouldn't prevent others from registering.

Given that, would the right approach be to continue the loop on
entry-specific errors ( logging a warning), while still aborting and
cleaning up on systemic ones like -ENOMEM? Or is the name collision
case considered impossible here since names are derived from the
tag/index and the table is only parsed once?

If continuing on all errors is preferred for simplicity, I can rework
the patch to skip failing entries rather than aborting, and drop the
cleanup entirely.


Le lun. 27 avr. 2026 à 21:03, Julius Werner <jwerner@xxxxxxxxxxxx> a écrit :
>
> Why does device_register() generally fail? Is it usually a problem
> with the device specifically (e.g. the device driver probe failed) or
> does it always indicate an issue with the core Linux device framework?
>
> The coreboot table entries are generally independent of each other, so
> if one of them has a problem that doesn't mean we need to kill all the
> others. If there's a chance that later device_register() for other
> entries would still succeed, I'd say we should actually just continue
> the loop instead of returning immediately. If it is certain that later
> entries can also not succeed (e.g. because this error can only happen
> when the device framework ran out of some allocatable resource or
> something), then I think the current code makes sense that just exits
> with the devices we already managed to create.