On Wed, Oct 12, 2022 at 09:44:00PM +0200, Borislav Petkov wrote:

On Wed, Oct 12, 2022 at 10:27:43PM +0300, Serge Semin wrote:

quoted

... inter-device parts of the core. The registration procedure is
protected by the mutex and RCU. So it seems as the EDAC core developer

Seems, schmeems. As I said already, EDAC has always had a single
chipset-specific driver. Period. So if one needs to run more than one
chipset-specific driver concurrently, then the whole code needs to be
audited because this hasn't been done before.

quoted

If it has never needed to, then please explain why did you let the
Synopsys EDAC driver being accepted like that then? 

I think I already did.

Kind of. What you didn't explain was the driver-specific problem in the
edac_mc core. What is the difference in the EDAC core handling
two devices (including of difference types) on the same platform and
handling the same devices each probed by two different drivers? (Consider
the drivers are designed thread-safe and we are talking about the EDAC
MC core.)

quoted

In my case it's a single EDAC driver per-chip. There can be several
DDR-controllers installed on the same SoC, but all of them of the same
type (Synopsys DW uMCTL2 v2.61a).

Good.

I'll look at your patches as time allows.

Ok. Thanks in advance.

-Sergey

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel