Messages in this thread | | | From | Robert Richter <> | Subject | Re: [PATCH 12/21] EDAC, ghes: Add support for legacy API counters | Date | Wed, 26 Jun 2019 10:27:23 +0000 |
| |
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
| |