- Jul 10, 2020
-
-
Dan Carpenter authored
We recently introduced a bug when we tried to convert of_iomap() to devm_of_iomap(). The problem was that there were two drivers mapping the same io region. The first driver was using of_iomap() and the second driver was using devm_of_iomap() and the kernel booted fine. When we converted the first drive to use devm_of_iomap() then the second driver failed with -EBUSY and the kernel couldn't boot. Let's add a comment to prevent this sort of mistake in the future. Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Acked-by:
Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20200609104642.GA43074@mwanda Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Vladimir Oltean authored
Sometimes debugging a device is easiest using devmem on its register map, and that can be seen with /proc/iomem. But some device drivers have many memory regions. Take for example a networking switch. Its memory map used to look like this in /proc/iomem: 1fc000000-1fc3fffff : pcie@1f0000000 1fc000000-1fc3fffff : 0000:00:00.5 1fc010000-1fc01ffff : sys 1fc030000-1fc03ffff : rew 1fc060000-1fc0603ff : s2 1fc070000-1fc0701ff : devcpu_gcb 1fc080000-1fc0800ff : qs 1fc090000-1fc0900cb : ptp 1fc100000-1fc10ffff : port0 1fc110000-1fc11ffff : port1 1fc120000-1fc12ffff : port2 1fc130000-1fc13ffff : port3 1fc140000-1fc14ffff : port4 1fc150000-1fc15ffff : port5 1fc200000-1fc21ffff : qsys 1fc280000-1fc28ffff : ana But after the patch in Fixes: was applied, the information is now presented in a much more opaque way: 1fc000000-1fc3fffff : pcie@1f0000000 1fc000000-1fc3fffff : 0000:00:00.5 1fc010000-1fc01ffff : 0000:00:00.5 1fc030000-1fc03ffff : 0000:00:00.5 1fc060000-1fc0603ff : 0000:00:00.5 1fc070000-1fc0701ff : 0000:00:00.5 1fc080000-1fc0800ff : 0000:00:00.5 1fc090000-1fc0900cb : 0000:00:00.5 1fc100000-1fc10ffff : 0000:00:00.5 1fc110000-1fc11ffff : 0000:00:00.5 1fc120000-1fc12ffff : 0000:00:00.5 1fc130000-1fc13ffff : 0000:00:00.5 1fc140000-1fc14ffff : 0000:00:00.5 1fc150000-1fc15ffff : 0000:00:00.5 1fc200000-1fc21ffff : 0000:00:00.5 1fc280000-1fc28ffff : 0000:00:00.5 That patch made a fair comment that /proc/iomem might be confusing when it shows resources without an associated device, but we can do better than just hide the resource name altogether. Namely, we can print the device name _and_ the resource name. Like this: 1fc000000-1fc3fffff : pcie@1f0000000 1fc000000-1fc3fffff : 0000:00:00.5 1fc010000-1fc01ffff : 0000:00:00.5 sys 1fc030000-1fc03ffff : 0000:00:00.5 rew 1fc060000-1fc0603ff : 0000:00:00.5 s2 1fc070000-1fc0701ff : 0000:00:00.5 devcpu_gcb 1fc080000-1fc0800ff : 0000:00:00.5 qs 1fc090000-1fc0900cb : 0000:00:00.5 ptp 1fc100000-1fc10ffff : 0000:00:00.5 port0 1fc110000-1fc11ffff : 0000:00:00.5 port1 1fc120000-1fc12ffff : 0000:00:00.5 port2 1fc130000-1fc13ffff : 0000:00:00.5 port3 1fc140000-1fc14ffff : 0000:00:00.5 port4 1fc150000-1fc15ffff : 0000:00:00.5 port5 1fc200000-1fc21ffff : 0000:00:00.5 qsys 1fc280000-1fc28ffff : 0000:00:00.5 ana Fixes: 8d84b18f ("devres: always use dev_name() in devm_ioremap_resource()") Signed-off-by:Vladimir Oltean <vladimir.oltean@nxp.com> Link: https://lore.kernel.org/r/20200601095826.1757621-1-olteanv@gmail.com Signed-off-by:
-
- Jan 06, 2020
-
-
Christoph Hellwig authored
ioremap has provided non-cached semantics by default since the Linux 2.6 days, so remove the additional ioremap_nocache interface. Signed-off-by:
Christoph Hellwig <hch@lst.de> Acked-by:
-
- Nov 11, 2019
-
-
Tuowen Zhao authored
Implement a resource managed strongly uncachable ioremap function. Cc: <stable@vger.kernel.org> # v4.19+ Tested-by:
AceLan Kao <acelan.kao@canonical.com> Signed-off-by:
Tuowen Zhao <ztuowen@gmail.com> Acked-by:
Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by:
Luis Chamberlain <mcgrof@kernel.org> Signed-off-by:
Lee Jones <lee.jones@linaro.org>
-
- Nov 05, 2019
-
-
Bartosz Golaszewski authored
Provide a variant of devm_ioremap_resource() for write-combined ioremap. Signed-off-by:
Bartosz Golaszewski <bgolaszewski@baylibre.com> Reviewed-by:
-
Bartosz Golaszewski authored
We want to add the write-combined variant of devm_ioremap_resource(). Let's first implement __devm_ioremap_resource() which takes an additional argument type. The types are the same as for __devm_ioremap(). The existing devm_ioremap_resource() now simply calls __devm_ioremap_resource() with regular DEVM_IOREMAP type. Signed-off-by:
-
- Oct 14, 2019
-
-
Denis Efremov authored
Code that iterates over all standard PCI BARs typically uses PCI_STD_RESOURCE_END. However, that requires the unusual test "i <= PCI_STD_RESOURCE_END" rather than something the typical "i < PCI_STD_NUM_BARS". Add a definition for PCI_STD_NUM_BARS and change loops to use the more idiomatic C style to help avoid fencepost errors. Link: https://lore.kernel.org/r/20190927234026.23342-1-efremov@linux.com Link: https://lore.kernel.org/r/20190927234308.23935-1-efremov@linux.com Link: https://lore.kernel.org/r/20190916204158.6889-3-efremov@linux.com Signed-off-by:
Denis Efremov <efremov@linux.com> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Acked-by: Sebastian Ott <sebott@linux.ibm.com> # arch/s390/ Acked-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> # video/fbdev/ Acked-by: Gustavo Pimentel <gustavo.pimentel@synopsys.com> # pci/controller/dwc/ Acked-by: Jack Wang <jinpu.wang@cloud.ionos.com> # scsi/pm8001/ Acked-by: Martin K. Petersen <martin.petersen@oracle.com> # scsi/pm8001/ Acked-by: Ulf Hansson <ulf.hansson@linaro.org> # memstick/
-
- Jul 05, 2019
-
-
Arnd Bergmann authored
devm_ioremap_resource() does not currently take 'const' arguments, which results in a warning from the first driver trying to do it anyway: drivers/gpio/gpio-amd-fch.c: In function 'amd_fch_gpio_probe': drivers/gpio/gpio-amd-fch.c:171:49: error: passing argument 2 of 'devm_ioremap_resource' discards 'const' qualifier from pointer target type [-Werror=discarded-qualifiers] priv->base = devm_ioremap_resource(&pdev->dev, &amd_fch_gpio_iores); ^~~~~~~~~~~~~~~~~~~ Change the prototype to allow it, as there is no real reason not to. Link: http://lkml.kernel.org/r/20190628150049.1108048-1-arnd@arndb.de Fixes: 9bb2e0452508 ("gpio: amd: Make resource struct const") Signed-off-by:
Enrico Weigelt <info@metux.net>
Reviewed-by: Andrew Morton <akpm@linux-foundation.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Arnd Bergmann <arnd@arndb.de> Cc: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com> Cc: Ulf Hansson <ulf.hansson@linaro.org> Cc: Andy Shevchenko <andy.shevchenko@gmail.com> Cc: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
- Jul 03, 2019
-
-
devm_ioremap_resource() does not currently take 'const' arguments, which results in a warning from the first driver trying to do it anyway: drivers/gpio/gpio-amd-fch.c: In function 'amd_fch_gpio_probe': drivers/gpio/gpio-amd-fch.c:171:49: error: passing argument 2 of 'devm_ioremap_resource' discards 'const' qualifier from pointer target type [-Werror=discarded-qualifiers] priv->base = devm_ioremap_resource(&pdev->dev, &amd_fch_gpio_iores); ^~~~~~~~~~~~~~~~~~~ Change the prototype to allow it, as there is no real reason not to. Fixes: 9bb2e0452508 ("gpio: amd: Make resource struct const") Signed-off-by:Enrico Weigelt <info@metux.net>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
- Jan 31, 2019
-
-
Sergei Shtylyov authored
devm_ioremap_resource() prefers calling devm_request_mem_region() with a resource name instead of a device name -- this looks pretty iff a resource name isn't specified via a device tree with a "reg-names" property (in this case, a resource name is set to a device node's full name), but if it is, it doesn't really scale since these names are only unique to a given device node, not globally; so, looking at the output of 'cat /proc/iomem', you do not have an idea which memory region belongs to which device (see "dirmap", "regs", and "wbuf" lines below): 08000000-0bffffff : dirmap 48000000-bfffffff : System RAM 48000000-48007fff : reserved 48080000-48b0ffff : Kernel code 48b10000-48b8ffff : reserved 48b90000-48c7afff : Kernel data bc6a4000-bcbfffff : reserved bcc0f000-bebfffff : reserved bec0e000-bec0efff : reserved bec11000-bec11fff : reserved bec12000-bec14fff : reserved bec15000-bfffffff : reserved e6050000-e605004f : gpio@e6050000 e6051000-e605104f : gpio@e6051000 e6052000-e605204f : gpio@e6052000 e6053000-e605304f : gpio@e6053000 e6054000-e605404f : gpio@e6054000 e6055000-e605504f : gpio@e6055000 e6060000-e606050b : pin-controller@e6060000 e6e60000-e6e6003f : e6e60000.serial e7400000-e7400fff : ethernet@e7400000 ee200000-ee2001ff : regs ee208000-ee2080ff : wbuf I think that devm_request_mem_region() should be called with dev_name() despite the region names won't look as pretty as before (however, we gain more consistency with e.g. the serial driver: 08000000-0bffffff : ee200000.rpc 48000000-bfffffff : System RAM 48000000-48007fff : reserved 48080000-48b0ffff : Kernel code 48b10000-48b8ffff : reserved 48b90000-48c7afff : Kernel data bc6a4000-bcbfffff : reserved bcc0f000-bebfffff : reserved bec0e000-bec0efff : reserved bec11000-bec11fff : reserved bec12000-bec14fff : reserved bec15000-bfffffff : reserved e6050000-e605004f : e6050000.gpio e6051000-e605104f : e6051000.gpio e6052000-e605204f : e6052000.gpio e6053000-e605304f : e6053000.gpio e6054000-e605404f : e6054000.gpio e6055000-e605504f : e6055000.gpio e6060000-e606050b : e6060000.pin-controller e6e60000-e6e6003f : e6e60000.serial e7400000-e7400fff : e7400000.ethernet ee200000-ee2001ff : ee200000.rpc ee208000-ee2080ff : ee200000.rpc Fixes: 72f8c0bf ("lib: devres: add convenience function to remap a resource") Signed-off-by:
Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Signed-off-by:
-
- Jul 23, 2018
-
-
Benjamin Herrenschmidt authored
There are still quite a few cases where a device might want to get to a different node of the device-tree, obtain the resources and map them. We have of_iomap() and of_io_request_and_map() but they both have shortcomings, such as not returning the size of the resource found (which can be useful) and not being "managed". This adds a devm_of_iomap() that provides all of these and should probably replace uses of the above in most drivers. Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Reviewed-by:
Joel Stanley <joel@jms.id.au>
-
- Mar 15, 2018
-
-
Yisheng Xie authored
When I tried to use devm_ioremap function and review related code, I found devm_ioremap_* almost have the similar realize with each other, which can be combined. In the former version, I have tried to kill ioremap_cache to reduce the size of devres, which can not work for ioremap is not the same as ioremap_nocache in some ARCHs likes ia64. Therefore, as the suggestion of Christophe, I introduce a help function __devm_ioremap, let devm_ioremap* inline and call __devm_ioremap with different devm_ioremap_type. After apply the patch, the size of devres.o can be reduce from 8216 Bytes to 8052 Bytes in my compile environment. Suggested-by:
Christophe LEROY <christophe.leroy@c-s.fr> Signed-off-by:
Yisheng Xie <xieyisheng1@huawei.com> Reviewed-by:
-
- Nov 02, 2017
-
-
Greg Kroah-Hartman authored
Many source files in the tree are missing licensing information, which makes it harder for compliance tools to determine the correct license. By default all files without license information are under the default license of the kernel, which is GPL version 2. Update the files which contain no license information with the 'GPL-2.0' SPDX license identifier. The SPDX identifier is a legally binding shorthand, which can be used instead of the full boiler plate text. This patch is based on work done by Thomas Gleixner and Kate Stewart and Philippe Ombredanne. How this work was done: Patches were generated and checked against linux-4.14-rc6 for a subset of the use cases: - file had no licensing information it it. - file was a */uapi/* one with no licensing information in it, - file was a */uapi/* one with existing licensing information, Further patches will be generated in subsequent months to fix up cases where non-standard...
-
- Apr 24, 2017
-
-
Lorenzo Pieralisi authored
The offset parameter in the devres devm_ioremap_*() functions kerneldoc entries is erroneously defined as BUS offset whereas it is actually a resource address. Since it is actually misleading, fix the devres devm_ioremap_* offset parameter kerneldoc entry by replacing BUS offset with a more suitable description (ie Resource address). Signed-off-by:
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by:
-
- Feb 08, 2016
-
-
Geliang Tang authored
Use to_pci_dev() instead of open-coding it. Signed-off-by:
Geliang Tang <geliangtang@163.com> Acked-by:
Tejun Heo <tj@kernel.org> Signed-off-by:
-
- Oct 05, 2015
-
-
Dan Carpenter authored
The iomap[] array has PCIM_IOMAP_MAX (6) elements and not DEVICE_COUNT_RESOURCE (16). This bug was found using a static checker. It may be that the "if (!(mask & (1 << i)))" check means we never actually go past the end of the array in real life. Fixes: ec04b075 ('iomap: implement pcim_iounmap_regions()') Signed-off-by:
-
- Aug 11, 2015
-
-
Dan Williams authored
Quoting Arnd: I was thinking the opposite approach and basically removing all uses of IORESOURCE_CACHEABLE from the kernel. There are only a handful of them.and we can probably replace them all with hardcoded ioremap_cached() calls in the cases they are actually useful. All existing usages of IORESOURCE_CACHEABLE call ioremap() instead of ioremap_nocache() if the resource is cacheable, however ioremap() is uncached by default. Clearly none of the existing usages care about the cacheability. Particularly devm_ioremap_resource() never worked as advertised since it always fell back to plain ioremap(). Clean this up as the new direction we want is to convert ioremap_<type>() usages to memremap(..., flags). Suggested-by:Dan Williams <dan.j.williams@intel.com>
-
- Mar 16, 2015
-
-
Abhilash Kesavan authored
Implement a resource managed writecombine ioremap function. Signed-off-by:
Abhilash Kesavan <a.kesavan@samsung.com> Acked-by:
Catalin Marinas <catalin.marinas@arm.com> Signed-off-by:
-
- Nov 07, 2014
-
-
Cristian Stoica authored
As in 4f452e8a, use resource_size_t to accomodate sizes greater than the size of an unsigned long int on platforms that have more than 32 bit physical addresses. Signed-off-by:
Cristian Stoica <cristian.stoica@freescale.com> Signed-off-by:
-
- Jul 23, 2014
-
-
Matthias Brugger authored
A call to of_iomap does not request the memory region. This patch adds the function of_io_request_and_map which requests the memory region before mapping it. Signed-off-by:
Matthias Brugger <matthias.bgg@gmail.com> Suggested-by:
Thomas Gleixner <tglx@linutronix.de> Suggested-by:
Rob Herring <robh@kernel.org> Acked-by:
Daniel Lezcano <daniel.lezcano@linaro.org>
-
- Jun 20, 2014
-
-
Jingoo Han authored
devm_request_and_ioremap() was obsoleted by the commit 75096579 ("lib: devres: Introduce devm_ioremap_resource()") and has been deprecated for a long time. So, let's remove this function. In addition, all usages of devm_request_and_ioremap() are also removed. Signed-off-by:
Jingoo Han <jg1.han@samsung.com> Signed-off-by:
-
- May 23, 2014
-
-
Fabian Frederick authored
Fix 3 checkpatch warnings: 'ERROR: "foo * const * bar" should be "foo * const *bar"' Cc: Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Fabian Frederick <fabf@skynet.be> Signed-off-by:
-
Fabian Frederick authored
devm_request_and_ioremap was the only function to use device instead of dev. This fixes kernel-doc warning. Cc: Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
- Apr 07, 2014
-
-
Uwe Kleine-König authored
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:
-
- Apr 03, 2014
-
-
Steven Rostedt authored
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:
-
- Feb 28, 2013
-
-
Jingoo Han authored
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:
-
- Jan 22, 2013
-
-
Thierry Reding authored
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:
-
Thierry Reding authored
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:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
-
- Mar 07, 2012
-
-
Paul Gortmaker authored
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>
-
- Jan 06, 2012
-
-
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>
-
- Nov 16, 2011
-
-
Wolfram Sang authored
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:
Greg Kroah-Hartman <gregkh@suse.de>
-
Wolfram Sang authored
While working on devres, I found those make navigating the code a tad easier. Signed-off-by:
-
- Jul 26, 2011
-
-
Maxin authored
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:
-
- Jul 11, 2010
-
-
Kulikov Vasiliy authored
'Unamp' should be 'Unmap'. Signed-off-by:
Kulikov Vasiliy <segooon@gmail.com> Acked-by:
Jiri Kosina <jkosina@suse.cz>
-
- Mar 30, 2010
-
-
Tejun Heo authored
include cleanup: Update gfp.h and slab.h includes to prepare for breaking 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:
Christoph Lameter <cl@linux-foundation.org> Cc: Ingo Molnar <mingo@redhat.com> Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
-
- May 05, 2008
-
-
Emil Medve authored
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:
Paul Mackerras <paulus@samba.org>
-
- Apr 30, 2008
-
-
Kumar Gala authored
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:
-
- Mar 17, 2008
-
-
Tejun Heo authored
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:
Jeff Garzik <jeff@garzik.org>
-
- Apr 28, 2007
-
-
Tejun Heo authored
Implement pcim_iounmap_regions() - the opposite of pcim_iomap_regions(). Signed-off-by:
-
- Feb 16, 2007
-
-
Frederik Deweerdt authored
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:
-
