On Mon, Jul 29, 2024 at 03:29:43PM +0100, Jonathan Cameron wrote: > On Mon, 29 Jul 2024 15:38:39 +0200 > Borislav Petkov <bp@xxxxxxxxx> wrote: > > > On Mon, Jul 29, 2024 at 01:45:12PM +0100, Jonathan Cameron wrote: > > > One of the key bits of feedback we've had on that series is that it > > > should be integrated with EDAC. Part of the reason being need to get > > > appropriate RAS expert review. > > > > If you mean me with that, my only question back then was: if you're going to > > integrate it somewhere and instead of defining something completely new - you > > can simply reuse what's there. That's why I suggested EDAC. > > Ah fair enough. I'd taken stronger meaning from what you said than > you intended. Thanks for the clarification. > > > > > IOW, the question becomes, why should it be a completely new thing and not > > part of EDAC? > > So that particular feedback perhaps doesn't apply here. > > I still have a concern with things ending up in fwctl that > are later generalized and how that process can happen. My intention with fwctl is that it should never technically inhibit generalization. Someone should be able to come and implement a concurrent kernel subsystem to operate the generalized thing. The documentation attempts to explain this position. I don't know anything about CXL here, but broadly you should very thoughtfully put things into fwctl that are single-instance and become "captured" by it, because this would impede a kernel mediated resource sharing in future. Like continuous memory scrubbing and EDAC is not really fwctl since it is part of the main mission of a memory device. However evaluating the memory to measure current ECC error rate for data collection and debugging would be appropriate for fwctl. If the HW can't share the units that are doing this ECC work then ensuring fwctl is optional and secondary would be the best option. Turn off in-kernel use of the scrubber unit then you can use that unit for debugging. (as an example) Jason
