[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1235676121.8730.167.camel@macbook.infradead.org>
Date: Fri, 27 Feb 2009 04:22:01 +0900
From: David Woodhouse <david.woodhouse@...el.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Jesper Krogh <jesper@...gh.cc>, Dave Olsen <dolsen@...i.com>,
Ryan Jackson <rjackson@...i.com>,
"linux-mtd@...ts.infradead.org" <linux-mtd@...ts.infradead.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Linux 2.6.29-rc6
On Thu, 2009-02-26 at 17:53 +0000, Linus Torvalds wrote:
> Dave Olsen <dolsen@...i.com>,
> Ryan Jackson <rjackson@...i.com>, David.Woodhouse@...el.com,
> linux-mtd@...ts.infradead.org
>
>
> On Thu, 26 Feb 2009, Jesper Krogh wrote:
> >
> >
> > Booting up 2.6.29-rc6 gave me this one in dmesg...
> >
> > [ 21.136149] ck804xrom ck804xrom_init_one(): Unable to register resource 0x00000000ff000000-0x00000000ffffffff - kernel bug?
>
> Well, it _is_ a kernel bug, but it's in that stupid driver. It does
> everything wrong, including printing out a scary message.
>
> Piece of sh*t driver, in other words.
>
> I mean, it even has a _comment_ about how the request_region is likely to
> not succeed, and then it prints out that scary message when it
> then doesn't do so.
>
> Not to mention that the driver is likely _wrong_ to just unconditionally
> try to enable that resource without *first* checking whether the resource
> can actually be enabled or whether there are other resources in that same
> window.
>
> Quite frankly, I find that whole thing scary. The driver should be deleted
> or at least marked EXPERIMENTAL or BROKEN.
It's giving you access to your BIOS flash so that you can overwrite it
from within Linux. It's _supposed_ to be scary :)
It's also always going to be a hack -- it's a PITA getting direct access
to that flash on most PeeCee chipsets. The driver operates on the
principle that it knows the hardware, and it can _make_ the flash appear
at the appropriate physical addresses. The theory, at least, is that it
knows better than the kernel does.
But yeah, it should probably at least look for other things which
already overlap with the region that it's trying to 'create'. Although
the comment leads me to believe that sometimes that's _expected_ and
shouldn't cause the driver to abort.
Dave, Ryan, are you still actively using this?
--
David Woodhouse Open Source Technology Centre
David.Woodhouse@...el.com Intel Corporation
---------------------------------------------------------------------
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
--
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