[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AANLkTi=JGSL5=cXRJgv857AXx64OvWzz8TAS4XJNHtW8@mail.gmail.com>
Date: Mon, 3 Jan 2011 12:26:07 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Chris Wilson <chris@...is-wilson.co.uk>
Cc: Knut Petersen <Knut_Petersen@...nline.de>, airlied@...ux.ie,
eric@...olt.net, jesse.barnes@...el.com,
linux-kernel@...r.kernel.org,
intel-gfx <intel-gfx@...ts.freedesktop.org>, gregkh@...e.de,
Jean Delvare <khali@...ux-fr.org>,
David Brownell <david-b@...bell.net>
Subject: Re: [PATCH] Fix i915 drm regression on AOpen i915GMm-HFS motherboard
[ related, but independent, issue ]
On Mon, Jan 3, 2011 at 11:59 AM, Chris Wilson <chris@...is-wilson.co.uk> wrote:
>
> That function currently requires
> GMBUS to differentiate between a NAK and an IO error (bitbanging just
> returns EREMOTEIO regardless, iirc).
Hmm. That sounds like something that would be worth fixing regardless
and independently of this. I'd expect that a lot of users would care
whether there was an actual protocol error or whether the command got
a NAK. There's a big difference between "those lines don't seem to
even be connected to anything" and "the other end didn't like us".
Even the comments in the bitbanging code seem to say that it should be
returning ETIMEDOUT etc for when there is no answer (and the low-level
"i2c_outb()" seems to do that), but then the code does seem to ignore
all that information and turn all errors into EREMOTEIO.
Which sounds bogus.
Added Jean to the cc in case he has some input (or knows who we should
bug about algo-bit.c). Also David Brownell, because he touched an
error code in that file two and a half years ago, so he now owns it
forever ;)
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists