linux-kernel - Re: [PATCH 01/05] fbdev: sh_mipi_dsi: Remove request/release mem region

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20101117072553.GB10671@linux-sh.org>
Date:	Wed, 17 Nov 2010 16:25:53 +0900
From:	Paul Mundt <lethal@...ux-sh.org>
To:	Magnus Damm <magnus.damm@...il.com>
Cc:	linux-kernel@...r.kernel.org, g.liakhovetski@....de,
	linux-sh@...r.kernel.org
Subject: Re: [PATCH 01/05] fbdev: sh_mipi_dsi: Remove request/release mem region

On Wed, Nov 17, 2010 at 03:44:15PM +0900, Magnus Damm wrote:
> The driver core already manages resources for us, so
> there is no need to perform request_mem_region() and
> release_mem_region() in the MIPI-DSI driver.
> 
No. This comes up time and time again for some reason, I'm not sure why
this misconception keeps being propagated (and it's definitely a mistake
I've made myself too!)

The driver core simply takes your resources and inserts them in to the
resource tree, it has nothing to do with requesting ranges, or checking
for conflicts. The main rationale for this is that drivers (think MFDs)
may pass in a large resource range, which in turn will be broken up and
requested by individual drivers nested underneath it. Only at request
time will the requested range (which can be the entire thing, or a
subset) be flagged as busy and conflicts detected.

The current logic is quite correct in what it is doing.
--
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/