Re: [PATCH v4 2/2] IB/qib: use arch_phys_wc_add()

Doug Ledford
2015-04-22T16:57:18Z

[-- Attachment #1: Type: text/plain, Size: 1891 bytes --]

On Wed, 2015-04-22 at 17:33 +0200, Luis R. Rodriguez wrote:
> On Wed, Apr 22, 2015 at 09:54:38AM -0400, Doug Ledford wrote:
> > On Tue, 2015-04-21 at 14:50 -0700, Luis R. Rodriguez wrote:
> >
> > This:
> > > + /* MTRR was used if this is non-zero */
> > > + if (!dd->wc_cookie)
> > > vma->vm_page_prot = pgprot_writecombine(vma->vm_page_prot);
> >
> > And this:
> > > + dd->wc_cookie = arch_phys_wc_add(pioaddr, piolen);
> > > + if (dd->wc_cookie < 0)
> > > + ret = -EINVAL;
> >
> > don't agree on what wc_cookie will be on error.
>
> Can you elaborate? The one below is the one that starts things,
> and arch_phys_wc_add() will return 0 on PAT systems. For non-PAT
> systems it will return a number > 0 *iff* a valid MTRR was added.
> It will return negative onloy on error then.
>
> The change above is meant to replace a check put in place to see
> if PAT was enabled. The way we replace this is to ensure that
> arch_phys_wc_add() returned 0.
>
> If you disagree it'd be great if you can elaborate why.

Maybe I'm missing something, but in qib_enable_wc() you store the return
from arch_phys_wc_add into wc_cookie. That return is negative, so you
return from qib_enable_wc() to qib_init_one(), they see the ret value,
they print out a warning about bad performance, then they clear the
return value and continue with device initialization.

In all of this though, wc_cookie is never cleared and so it still has
the error condition in it. Then, much later at run time, you call
mmap_piobufs() and you check the contents of wc_cookie, and if it's
non-0 (which is still will be), you do the wrong thing, right? And what
about at shutdown when you call qib_disable_wc() and your cookie still
has an error code in it as well?

--
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
GPG KeyID: 0E572FDD

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]