Russell Currey <rus...@russell.cc> writes:
> On Tue, 2018-11-20 at 17:55 +1100, Alexey Kardashevskiy wrote:
>>
>> On 20/11/2018 14:51, Sam Bobroff wrote:
>> > On Tue, Nov 20, 2018 at 01:51:06PM +1100, Michael Ellerman wrote:
>> > > Alexey Kardashevskiy <a...@ozlabs.ru> writes:
>> > >
>> > > > The current implementation of the OPAL_PCI_EEH_FREEZE_STATUS
>> > > > call in
>> > > > skiboot's NPU driver does not touch the pci_error_type
>> > > > parameter so
>> > > > it might have garbage but the powernv code analyzes it
>> > > > nevertheless.
>> > > >
>> > > > This initializes pcierr and fstate to zero in all call sites.
>> > > >
>> > > > Signed-off-by: Alexey Kardashevskiy <a...@ozlabs.ru>
>> > > > ---
>> > >
>> > > Can we tag this with a Fixes? And seems like it should probably
>> > > go to
>> > > stable, or can we not trigger this path on older kernels?
>> > >
>> > > cheers
>> >
>> > Hmm, it's triggered by use on an NPU PE so that would be any kernel
>> > that
>> > can run on P8 or later (AFAIK).
>> >
>> > It looks like the issue was present earlier, but the code was last
>> > touched when it was moved, in...
>> >
>> > 40ae5f693f6a ("powerpc/powernv: Drop PHB operation get_state()")
>> >
>> > ... which was back in v4.1.
>>
>> The original commit is
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8c41a7f3f7593fe57
>>
>> 2013-06-20 13:21:09 +0800
>> ===
>> powerpc/eeh: I/O chip EEH state retrieval
>>
>> The patch adds I/O chip backend to retrieve the state for the
>> indicated PE. While the PE state is temperarily unavailable,
>> the upper layer (powernv platform) should return default delay
>> (1 second).
>> ===
>>
>> This was 3.10-rc5 (this is what that sha1's Makefile has).
>>
>> But this was not the issue till skiboot decided not to zero these
>> parameters so "Fixes:" should point to what?
>
> It should still be that commit, it's perfectly reasonable (however
> unlikely) that someone could be running a 3.10 kernel with a modern
> skiboot.
Yeah that kernel commit is the earliest point where we could hit the
bug, so that's where Fixes should point.
If the bug's not actually in that commit, as it sounds here, then you
can explain that in the change log.
The other way to think about is if someone has back ported
8c41a7f3f7593fe57 then they would also want this fix, so pointing the
Fixes tag at 8c41a7f3f7593fe57 expresses that.
cheers
