summaryrefslogtreecommitdiff
path: root/lib/devres.c
AgeCommit message (Collapse)AuthorFilesLines
2014-04-08Kconfig: rename HAS_IOPORT to HAS_IOPORT_MAPUwe Kleine-König1-2/+2
If the renamed symbol is defined lib/iomap.c implements ioport_map and ioport_unmap and currently (nearly) all platforms define the port accessor functions outb/inb and friend unconditionally. So HAS_IOPORT_MAP is the better name for this. Consequently NO_IOPORT is renamed to NO_IOPORT_MAP. The motivation for this change is to reintroduce a symbol HAS_IOPORT that signals if outb/int et al are available. I will address that at least one merge window later though to keep surprises to a minimum and catch new introductions of (HAS|NO)_IOPORT. The changes in this commit were done using: $ git grep -l -E '(NO|HAS)_IOPORT' | xargs perl -p -i -e 's/\b((?:CONFIG_)?(?:NO|HAS)_IOPORT)\b/$1_MAP/' Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2014-04-04lib/devres.c: fix some sparse warningsSteven Rostedt1-5/+7
Having a discussion about sparse warnings in the kernel, and that we should clean them up, I decided to pick a random file to do so. This happened to be devres.c which gives the following warnings: CHECK lib/devres.c lib/devres.c:83:9: warning: cast removes address space of expression lib/devres.c:117:31: warning: incorrect type in return expression (different address spaces) lib/devres.c:117:31: expected void [noderef] <asn:2>* lib/devres.c:117:31: got void * lib/devres.c:125:31: warning: incorrect type in return expression (different address spaces) lib/devres.c:125:31: expected void [noderef] <asn:2>* lib/devres.c:125:31: got void * lib/devres.c:136:26: warning: incorrect type in assignment (different address spaces) lib/devres.c:136:26: expected void [noderef] <asn:2>*[assigned] dest_ptr lib/devres.c:136:26: got void * lib/devres.c:226:9: warning: cast removes address space of expression Mostly it's just the use of typecasting to void * without adding __force, or returning ERR_PTR(-ESOMEERR) without typecasting to a __iomem type. I added a helper macro IOMEM_ERR_PTR() that does the typecast to make the code a little nicer than adding ugly typecasts to the code. Signed-off-by: Steven Rostedt <rostedt@goodmis.org> Cc: Tejun Heo <tj@kernel.org> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-02-28lib/devres.c: fix misplaced #endifJingoo Han1-1/+1
A misplaced #endif causes link errors related to pcim_*() functions. This is because pcim_*() functions are related to CONFIG_PCI option, however these are not related to CONFIG_HAS_IOPORT option. Therefore, when CONFIG_PCI is enabled and CONFIG_HAS_IOPORT is not enabled, it makes link errors related to pcim_*() functions as below: drivers/ata/libata-sff.c:3233: undefined reference to `pcim_iomap_regions' drivers/ata/libata-sff.c:3238: undefined reference to `pcim_iomap_table' drivers/built-in.o: In function `ata_pci_sff_init_host': drivers/ata/libata-sff.c:2318: undefined reference to `pcim_iomap_regions' drivers/ata/libata-sff.c:2329: undefined reference to `pcim_iomap_table Signed-off-by: Jingoo Han <jg1.han@samsung.com> Cc: Greg KH <greg@kroah.com> Cc: Tejun Heo <tj@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-01-23lib: devres: Fix build breakageThierry Reding1-0/+1
The ERR_PTR() and IS_ERR() macros used by the devm_ioremap_resource() function are defined in the linux/err.h header. On ARM this seems to be pulled in by one of the other headers but the build fails at least on OpenRISC. Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de> Reported-by: kbuild test robot <fengguang.wu@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-01-22lib: devres: Introduce devm_ioremap_resource()Thierry Reding1-13/+44
The devm_request_and_ioremap() function is very useful and helps avoid a whole lot of boilerplate. However, one issue that keeps popping up is its lack of a specific error code to determine which of the steps that it performs failed. Furthermore, while the function gives an example and suggests what error code to return on failure, a wide variety of error codes are used throughout the tree. In an attempt to fix these problems, this patch adds a new function that drivers can transition to. The devm_ioremap_resource() returns a pointer to the remapped I/O memory on success or an ERR_PTR() encoded error code on failure. Callers can check for failure using IS_ERR() and determine its cause by extracting the error code using PTR_ERR(). devm_request_and_ioremap() is implemented as a wrapper around the new API and return NULL on failure as before. This ensures that backwards compatibility is maintained until all users have been converted to the new API, at which point the old devm_request_and_ioremap() function should be removed. A semantic patch is included which can be used to convert from the old devm_request_and_ioremap() API to the new devm_ioremap_resource() API. Some non-trivial cases may require manual intervention, though. Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de> Cc: Arnd Bergmann <arnd@arndb.de> Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-03-08lib: reduce the use of module.h wherever possiblePaul Gortmaker1-1/+1
For files only using THIS_MODULE and/or EXPORT_SYMBOL, map them onto including export.h -- or if the file isn't even using those, then just delete the include. Fix up any implicit include dependencies that were being masked by module.h along the way. Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2012-01-12Merge branch 'linux-next' of ↵Linus Torvalds1-3/+3
git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci * 'linux-next' of git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci: (80 commits) x86/PCI: Expand the x86_msi_ops to have a restore MSIs. PCI: Increase resource array mask bit size in pcim_iomap_regions() PCI: DEVICE_COUNT_RESOURCE should be equal to PCI_NUM_RESOURCES PCI: pci_ids: add device ids for STA2X11 device (aka ConneXT) PNP: work around Dell 1536/1546 BIOS MMCONFIG bug that breaks USB x86/PCI: amd: factor out MMCONFIG discovery PCI: Enable ATS at the device state restore PCI: msi: fix imbalanced refcount of msi irq sysfs objects PCI: kconfig: English typo in pci/pcie/Kconfig PCI/PM/Runtime: make PCI traces quieter PCI: remove pci_create_bus() xtensa/PCI: convert to pci_scan_root_bus() for correct root bus resources x86/PCI: convert to pci_create_root_bus() and pci_scan_root_bus() x86/PCI: use pci_scan_bus() instead of pci_scan_bus_parented() x86/PCI: read Broadcom CNB20LE host bridge info before PCI scan sparc32, leon/PCI: convert to pci_scan_root_bus() for correct root bus resources sparc/PCI: convert to pci_create_root_bus() sh/PCI: convert to pci_scan_root_bus() for correct root bus resources powerpc/PCI: convert to pci_create_root_bus() powerpc/PCI: split PHB part out of pcibios_map_io_space() ... Fix up conflicts in drivers/pci/msi.c and include/linux/pci_regs.h due to the same patches being applied in other branches.
2012-01-07PCI: Increase resource array mask bit size in pcim_iomap_regions()Yinghai Lu1-3/+3
DEVICE_COUNT_RESOURCE will be bigger than 16 when SRIOV supported is enabled. Let them pass with int just like pci_enable_resources(). Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2011-11-16lib: devres: add convenience function to remap a resourceWolfram Sang1-0/+51
Almost every platform_driver does the three steps get_resource, request_mem_region, ioremap. This does not only lead to a lot of code duplication, but also a huge number of similar error strings and inconsistent error codes on failure. So, introduce a helper function which simplifies remapping a resource and make it hard to do something wrong and add documentation for it. Signed-off-by: Wolfram Sang <w.sang@pengutronix.de> Acked-by: Grant Likely <grant.likely@secretlab.ca> Acked-by: Tejun Heo <tj@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-11-16lib: devres: add annotations for #endifWolfram Sang1-2/+2
While working on devres, I found those make navigating the code a tad easier. Signed-off-by: Wolfram Sang <w.sang@pengutronix.de> Acked-by: Grant Likely <grant.likely@secretlab.ca> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-07-26devres: fix possible use after freeMaxin B John1-1/+1
devres uses the pointer value as key after it's freed, which is safe but triggers spurious use-after-free warnings on some static analysis tools. Rearrange code to avoid such warnings. Signed-off-by: Maxin B. John <maxin.john@gmail.com> Reviewed-by: Rolf Eike Beer <eike-kernel@sf-tec.de> Acked-by: Tejun Heo <tj@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-07-12lib/devres.c: fix comment typoKulikov Vasiliy1-1/+1
'Unamp' should be 'Unmap'. Signed-off-by: Kulikov Vasiliy <segooon@gmail.com> Acked-by: Tejun Heo <tj@kernel.org> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2010-03-30include cleanup: Update gfp.h and slab.h includes to prepare for breaking ↵Tejun Heo1-0/+1
implicit slab.h inclusion from percpu.h percpu.h is included by sched.h and module.h and thus ends up being included when building most .c files. percpu.h includes slab.h which in turn includes gfp.h making everything defined by the two files universally available and complicating inclusion dependencies. percpu.h -> slab.h dependency is about to be removed. Prepare for this change by updating users of gfp and slab facilities include those headers directly instead of assuming availability. As this conversion needs to touch large number of source files, the following script is used as the basis of conversion. http://userweb.kernel.org/~tj/misc/slabh-sweep.py The script does the followings. * Scan files for gfp and slab usages and update includes such that only the necessary includes are there. ie. if only gfp is used, gfp.h, if slab is used, slab.h. * When the script inserts a new include, it looks at the include blocks and try to put the new include such that its order conforms to its surrounding. It's put in the include block which contains core kernel includes, in the same order that the rest are ordered - alphabetical, Christmas tree, rev-Xmas-tree or at the end if there doesn't seem to be any matching order. * If the script can't find a place to put a new include (mostly because the file doesn't have fitting include block), it prints out an error message indicating which .h file needs to be added to the file. The conversion was done in the following steps. 1. The initial automatic conversion of all .c files updated slightly over 4000 files, deleting around 700 includes and adding ~480 gfp.h and ~3000 slab.h inclusions. The script emitted errors for ~400 files. 2. Each error was manually checked. Some didn't need the inclusion, some needed manual addition while adding it to implementation .h or embedding .c file was more appropriate for others. This step added inclusions to around 150 files. 3. The script was run again and the output was compared to the edits from #2 to make sure no file was left behind. 4. Several build tests were done and a couple of problems were fixed. e.g. lib/decompress_*.c used malloc/free() wrappers around slab APIs requiring slab.h to be added manually. 5. The script was run on all .h files but without automatically editing them as sprinkling gfp.h and slab.h inclusions around .h files could easily lead to inclusion dependency hell. Most gfp.h inclusion directives were ignored as stuff from gfp.h was usually wildly available and often used in preprocessor macros. Each slab.h inclusion directive was examined and added manually as necessary. 6. percpu.h was updated not to include slab.h. 7. Build test were done on the following configurations and failures were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my distributed build env didn't work with gcov compiles) and a few more options had to be turned off depending on archs to make things build (like ipr on powerpc/64 which failed due to missing writeq). * x86 and x86_64 UP and SMP allmodconfig and a custom test config. * powerpc and powerpc64 SMP allmodconfig * sparc and sparc64 SMP allmodconfig * ia64 SMP allmodconfig * s390 SMP allmodconfig * alpha SMP allmodconfig * um on x86_64 SMP allmodconfig 8. percpu.h modifications were reverted so that it could be applied as a separate patch and serve as bisection point. Given the fact that I had only a couple of failures from tests on step 6, I'm fairly confident about the coverage of this conversion patch. If there is a breakage, it's likely to be something in one of the arch headers which should be easily discoverable easily on most builds of the specific arch. Signed-off-by: Tejun Heo <tj@kernel.org> Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org> Cc: Ingo Molnar <mingo@redhat.com> Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
2008-05-05[POWERPC] devres: Add devm_ioremap_prot()Emil Medve1-1/+1
We provide an ioremap_flags, so this provides a corresponding devm_ioremap_prot. The slight name difference is at Ben Herrenschmidt's request as he plans on changing ioremap_flags to ioremap_prot in the future. Signed-off-by: Emil Medve <Emilian.Medve@Freescale.com> Signed-off-by: Kumar Gala <galak@kernel.crashing.org> Acked-by: Tejun Heo <htejun@gmail.com> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-05-01devres: support addresses greater than an unsigned long via dev_ioremapKumar Gala1-2/+2
Use a resource_size_t instead of unsigned long since some arch's are capable of having ioremap deal with addresses greater than the size of a unsigned long. Signed-off-by: Kumar Gala <galak@kernel.crashing.org> Cc: Tejun Heo <htejun@gmail.com> Cc: Jeff Garzik <jgarzik@pobox.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-03-17devres: implement pcim_iomap_regions_request_all()Tejun Heo1-0/+25
Some drivers need to reserve all PCI BARs to prevent other drivers misusing unoccupied BARs. pcim_iomap_regions_request_all() requests all BARs and iomap specified BARs. Signed-off-by: Tejun Heo <htejun@gmail.com> Cc: Greg Kroah-Hartman <gregkh@suse.de> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Cc: Jeff Garzik <jeff@garzik.org> Signed-off-by: Jeff Garzik <jeff@garzik.org>
2007-04-28iomap: implement pcim_iounmap_regions()Tejun Heo1-0/+26
Implement pcim_iounmap_regions() - the opposite of pcim_iomap_regions(). Signed-off-by: Tejun heo <htejun@gmail.com> Signed-off-by: Jeff Garzik <jeff@garzik.org>
2007-02-16[PATCH] pci_iomap_regions() error handling fixFrederik Deweerdt1-4/+4
It appears that the pcim_iomap_regions() function doesn't get the error handling right. It BUGs early at boot with a backtrace along the lines of: ahci_init pci_register_driver driver_register [...] ahci_init_one pcim_iomap_region pcim_iounmap The following patch allows me to boot. Only the if(mask..) continue; part fixes the problem actually, the gotos where changed so that we don't try to unmap something we couldn't map anyway. Signed-off-by: Frederik Deweerdt <frederik.deweerdt@gmail.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Tejun Heo <htejun@gmail.com> Cc: Jeff Garzik <jeff@garzik.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-11[PATCH] sort the devres mess outAl Viro1-0/+300
* Split the implementation-agnostic stuff in separate files. * Make sure that targets using non-default request_irq() pull kernel/irq/devres.o * Introduce new symbols (HAS_IOPORT and HAS_IOMEM) defaulting to positive; allow architectures to turn them off (we needed these symbols anyway for dependencies of quite a few drivers). * protect the ioport-related parts of lib/devres.o with CONFIG_HAS_IOPORT. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>