On Sat, Jan 28, 2017 at 01:38:43PM +0100, Alexander Gordeev wrote: > On Sat, Jan 28, 2017 at 12:10:41PM +0100, Andrew Jones wrote: > > > If we checked only requested BAR the function could have > > > succeeded with inconsistent BAR sizes combinations. I.e. > > > imagine a corrupted BARs reported by a device: > > > BAR 0 - 64 bit lower > > > BAR 1 - 64 bit lower > > > BAR 2 - 64 bit upper > > > ... > > > If the function is asked about BAR 1 it would succeed, even > > > though in fact the layout is ambiguous. > > > > Is it possible to have bars messed up like this? I think I'd > > I do not know actually. We spread sanity checks (asserts) here > and there to avoid i.e. DT inconsistency. If we were to propagate > this approach to the rest of the code, then we should assume BARs > could be messed up, right? > > It is a design decision, therefore - up to you ;) I like sanity checking asserts, but a check for bar layout sanity only needs to be made once, not each time any bar is checked for existence. If you want to confirm the layout of bars is sane, then pci_scan_bars is probably the right place. > > > just assume that sane layouts will exist and that we need to > > avoid misinterpreting a high bar. So we just need to know a > > high bar is a high bar, and in that case it's valid. > > [...] > > > Thanks, > > drew
