Re: [PATCH 1/9] EDAC/versalnet: Add NULL check for mci in handle_error()

"Pandey, Radhey Shyam" <[email protected]> Wed, 29 Jul 2026 22:10:30 +0530
Newsgroups org.kernel.vger.linux-edac,org.kernel.vger.linux-kernel
Message-ID <[email protected]>
On 7/29/2026 3:03 AM, Borislav Petkov wrote:
> On Tue, Jul 28, 2026 at 11:57:28PM +0530, Pandey, Radhey Shyam wrote:
>> One clarification on DEV_UNKNOWN: on Versal NET, the driver exposes 8
>> MC5 controller slots, but a given platform may not have all of them
>> configured.
> 
> Are you basically saying that you can have non-contiguous controller slots
> present on a system?
> 

In the Versal NET designs I've examined so far, configuration with fewer
than eight MC5 controllers uses a contiguous set starting at slot 0
(for example, slots 0-3 populated and slots 4-7 absent).

I will let Shubhrajyoti comment if non-contiguous controller slots
are possible on any supported platform?

Agreed for real init failures if initialization of a controller that
should be present fails, probe should fail and unwind all instances
registered so far, same as amd64_edac.

For v2, my proposal is (only if contiguous slot are supported):
-Take the supported controller count from the design/DT rather than
always iterating hardcoded NUM_CONTROLLERS(8). Though it has dependency
on XSA support(hardware description metadata archive exported from
Vivado) and DT binding getting accepted.
-Run init/remove only for that range.
-Treat DEV_UNKNOWN as a probe error with full unwind, not as a silent
skip. Indices beyond the supported count are not probed at all.
-Document this model in the driver.
-The existing WARN_ON_ONCE() check in handle_error() should be
sufficient so the current patch can be dropped.

Shubhrajyoti: please chime in if I've missed anything or if you
have a different view on this approach.

Thanks,
Radhey