lkml.org 
[lkml]   [2011]   [Jul]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] x86: PCI config space accessor functions should not ignore the segment argument
On Thu, 21 Jul 2011 11:05:40 +0200
Ingo Molnar <mingo@elte.hu> wrote:

> > > also, the analysis/explanation is a bit incomplete:
> > >
> > >> The access method 1 accessor, as it can be used for extended
> > >> accesses (on AMD systems) instead gets added checks for the
> > >> passed in segment to be zero (returning an error just like out
> > >> of range values of the other arguments would cause).
> > >
> > > Under what circumstances can this trigger in practice, with the
> > > current code?
> >
> > I really don't know whether multi-segment PCI systems with AMD CPUs
> > are existing in practice. If they do, and if MMCFG cannot be used
> > there for whatever reason, accesses to segments other than zero
> > would get issued to the wrong device(s). I would have thought that
> > this is what the paragraph above says, but I certainly can add this
> > more explicit description...
>
> Do we have to re-discuss the upstream changelog policy every single
> time again?
>
> Yes, overly verbose, reader-friendly changelogs are preferred over
> 'anyone who is an expert in this field should know all the
> expectations, status quo and consequences' kind of minimalistic
> changelogs.
>
> The former is consciously information-rich and robust, the latter is
> information-poor and prone to be fragile, prone to be ambiguous,
> making both the merge flow, any bug and commit triage and eventual
> later fixes more difficult.

I did a double take on the original, so yeah more verbose would be
good. But generally you're right we should flag this kind of incorrect
usage, so from that perspective the patch looks good.

Thanks,
--
Jesse Barnes, Intel Open Source Technology Center


\
 
 \ /
  Last update: 2011-07-21 22:03    [W:0.034 / U:0.620 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site