On 26.06.19 10:33:28, James Morse wrote: > On 20/06/2019 07:55, Robert Richter wrote:
> > It is not that I am keen on fixing legacy edac sysfs. It just happens > > while unifying the error handlers in ghes_edac and edac_mc. As I see > > you are reluctant on just letting it go, let's just disable > > EDAC_LEGACY_SYSFS for ARM64. > > That would break other drivers where those legacy counters expose valid > values. > > You're painting me as some kind of stubborn villan here. You're right my > initial reaction > was 'what for?'. Adding new support for legacy counters that have never > worked with > ghes_edac looks like the wrong thing to do. > > But unfortunately edac-utils is still using this legacy interface. I am sorry for mis-understanding you here. I haven't seen your motivation for this which is now clear to me. > If we're going to fix it, could we fix it properly? (separate series that can > be > backported to stable). I see your point here. This is also the reason why I (try to) put fixes at the beginning of a series to allow backports to stable (or distros). Clearly, this must be better separated here. > > Though, I don't agree with it as there > > still could be some userland tools that use this interface that cannot > > be used any longer after a transition from x86 to arm64. > > I don't think this is the right thing to do. ghes_edac's behaviour should not > change > between architectures. > > > Where we aren't agreeing is how we fix bugs: > > Its either broken, and no-one cares, we should remove it. > Or, we should fix it and those fixes should go to stable. > > We can't mix fixes and features in a patch series, as the fixes then can't > easily be > backported. If its ever in doubt, the patches should still be as separate > fixes so the > maintainer can decide. I will better separate fix here and update in the next v3. Thanks and sorry again, -Robert
