Re: [PATCH 12/21] EDAC, ghes: Add support for legacy API counters

[Robert Richter]

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