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
| ||
|
Message-Id: <200710241939.17576.david-b@pacbell.net> Date: Wed, 24 Oct 2007 19:39:17 -0700 From: David Brownell <david-b@...bell.net> To: Alan Cox <alan@...rguk.ukuu.org.uk> Cc: Linux Kernel list <linux-kernel@...r.kernel.org>, Andrew Morton <akpm@...ux-foundation.org> Subject: Re: [patch 2.6.24-rc1] resource_len() utility function On Wednesday 24 October 2007, Alan Cox wrote: > On Wed, 24 Oct 2007 18:20:52 -0700 > David Brownell <david-b@...bell.net> wrote: > > > Add a new resource_len() function, so drivers can start using this > > instead of driver-private code for a common idiom. The call can be > > useful with at least: > > > > - request_region(), release_region() > > - request_mem_region(), release_mem_region() > > - ioremap() > > > > Candidate drivers include those using platform or PNP busses, and > > maybe some others. PCI already has a similar function. > > > > This patch also updates a representative set of drivers in two > > subsystems to use this call (SPI, and USB peripheral/gadget). > > PCI also increasingly is using functions that allow the user to choose to > map a resource as a resource (eg pci_iomap). So is it better to have > functions request_mem_resource(res) free_mem_resource(res) and similar > instead or as well ? This was intended to be a minor band-aid. ;) We already have request_resource(), which does something different than the request_*region() calls. I think calls with those names would complicate an already-too-strange interface, adding oddball siblings to request_resource(). I'd hope that when those resource calls were defined they made sense ... but to me, they don't do so today. Consider that the *typical* caller is given a "struct resource", and then to claim the specified address space it must convert it into a "start + length" representation before getting back a *NEW* "struct resource" ... with identical contents, other than the value of one all-but-undocumented flag bit. Then, if it's I/O space the address is usable already; but for memory space, it still needs an ioremap()... Oh, and PCI has its own resource structs ("BAR") that don't look or act the same as other resources. So while I like the notion of starting to abolish that conversion step, this wasn't an attempt to fix all the bizarre behaviors of the resource API. I could imagine a call taking a resource and returning a "void __iomem *" to use for IO, which implicitly claims the region (in either memory or i/o space) and does any ioremap needed for memory space. With a sibling call to undo all that. If that's the answer, someone else should develop the patch and update drivers... - Dave - 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