- 27 Aug, 2015 4 commits
-
-
Vasant Hegde authored
Commit 84ad6e5c added LEDS support for PowerNV platform. Lets update ppc64_defconfig to pick LEDS driver. PowerNV LEDS driver looks for "/ibm,opal/leds" node in device tree and loads if this node exists. Hence added it as 'm'. Also note that powernv LEDS driver needs NEW_LEDS and LEDS_CLASS as well. Hence added them to config file. mpe: Also add them to pseries_defconfig, which is currently also used for powernv systems. Suggested-by:
Michael Ellerman <mpe@ellerman.id.au> Signed-off-by:
Vasant Hegde <hegdevasant@linux.vnet.ibm.com> Cc: Stewart Smith <stewart@linux.vnet.ibm.com> Signed-off-by:
-
Alexey Kardashevskiy authored
Commit e91c2511 "powerpc/iommu: Cleanup setting of DMA base/offset" expects that the default DMA offset is set from pnv_ioda_setup_bus_dma() which is correct unless it is SRIOV where the code flow is different - at the moment when pnv_ioda_setup_bus_dma() is called, PCI devices for VFs are not created yet. This adds missing set_dma_offset() to pnv_pci_ioda_dma_dev_setup() to cover the case of SRIOV. Note that we still need set_dma_offset() in pnv_ioda_setup_bus_dma() as at the boot time pnv_pci_ioda_dma_dev_setup() is called when no PE was created yet, this happens at the PHB fixup stage. Fixes: e91c2511 ("powerpc/iommu: Cleanup setting of DMA base/offset") Signed-off-by:
Alexey Kardashevskiy <aik@ozlabs.ru> Reviewed-by:
Gavin Shan <gwshan@linux.vnet.ibm.com> Signed-off-by:
-
Daniel Axtens authored
cxl_reset currently PERSTs the slot, and then repeatedly tries to read MMIO space in order to kick off EEH. There are 2 problems with this: it's unnecessary, and it's racy. It's unnecessary because the PERST will bring down the PHB link. That will be picked up by the CAPP, which will send out an HMI. Skiboot, noticing an HMI from the CAPP, will send an OPAL notification to the kernel, which will trigger EEH recovery. It's also racy: the EEH recovery triggered by the CAPP will eventually cause the MMIO space to have its mapping invalidated and the pointer NULLed out. This races with our attempt to read the MMIO space. This is causing OOPSes in testing. Simply drop all the attempts to force EEH detection, and trust that Skiboot will send the notification and that we'll act on it. The Skiboot code to send the EEH notification has been in Skiboot for as long as CAPP recovery has been supported, so we don't need to worry about breaking obscure setups with ancient firmware. Cc: Ryan Grimm <grimm@linux.vnet.ibm.com> Cc: stable@vger.kernel.org Fixes: 62fa19d4 ("cxl: Add ability to reset the card") Signed-off-by:
Daniel Axtens <dja@axtens.net> Acked-by:
Ian Munsie <imunsie@au1.ibm.com> Signed-off-by:
-
Vaibhav Jain authored
This minor patch plugs a potential irq leak in case of a memory allocation failure inside function the afu_allocate_irqs. Presently the irqs allocated to the context gets leaked if allocation of either one of context irq_bitmap or irq_names fails. Signed-off-by:
Vaibhav Jain <vaibhav@linux.vnet.ibm.com> Acked-by:
-
- 22 Aug, 2015 2 commits
-
-
Vaishali Thakkar authored
Macro DEFINE_PCI_DEVICE_TABLE is deprecated. So, here use struct pci_device_id instead of DEFINE_PCI_DEVICE_TABLE with the goal of getting rid of this macro completely. The Coccinelle semantic patch that performs this transformation is as follows: @@ identifier a; declarer name DEFINE_PCI_DEVICE_TABLE; initializer i; @@ - DEFINE_PCI_DEVICE_TABLE(a) + const struct pci_device_id a[] = i; Signed-off-by:
Vaishali Thakkar <vthakkar1994@gmail.com> Acked-by:
Michael Neuling <mikey@neuling.org> Acked-by:
-
Michael Ellerman authored
When I merged the OPAL support for the powernv LEDS driver I missed a hunk. This is slightly modified from the original patch, as the original added code to opal-api.h which is not in the skiboot version, which is discouraged. Instead those values are moved into the driver, which is the only place they are used. Fixes: 8a8d9181 ("powerpc/powernv: Add OPAL interfaces for accessing and modifying system LED states") Reviewed-by:
-
- 20 Aug, 2015 10 commits
-
-
Samuel Mendoza-Jonas authored
On powernv secondary cpus are returned to OPAL, and will then enter the target kernel in big-endian. However if it is set the HILE bit will persist, causing the first exception in the target kernel to be delivered in litte-endian regardless of the current endianness. If running on top of OPAL make sure the HILE bit is reset once we've finished waiting for all of the secondaries to be returned to OPAL. Signed-off-by:
Samuel Mendoza-Jonas <sam.mj@au1.ibm.com> Signed-off-by:
-
Samuel Mendoza-Jonas authored
If the target kernel does not inlcude the FIXUP_ENDIAN check, coming from a different-endian kernel will cause the target kernel to panic. All ppc64 kernels can handle starting in big-endian mode, so return to big-endian before branching into the target kernel. This mainly affects pseries as secondaries on powernv are returned to OPAL. Signed-off-by:
-
Laurent Dufour authored
This patch fixes several endianness issues detected when running the HVSI driver in little endian mode. These issues are raised in little endian mode because the data exchanged in memory between the kernel and the hypervisor has to be in big endian format. This exhibits as errors such as: irq: (null) didn't like hwirq-0x1000a00 to VIRQ16 mapping (rc=-22) hvsi_console_init: couldn't create irq mapping for 0x1000a00 The data structures already have endian annotations, and sparse is generating numerous warnings based on those. This commit fixes all of them. Signed-off-by:
Laurent Dufour <ldufour@linux.vnet.ibm.com> CC: Greg Kroah-Hartman <gregkh@linuxfoundation.org> CC: Jiri Slaby <jslaby@suse.cz> CC: linuxppc-dev@lists.ozlabs.org CC: linux-kernel@vger.kernel.org [mpe: Flesh out change log] Signed-off-by:
-
Vasant Hegde authored
This patch implements LED driver for PowerNV platform using the existing generic LED class framework. PowerNV platform has below type of LEDs: - System attention Indicates there is a problem with the system that needs attention. - Identify Helps the user locate/identify a particular FRU or resource in the system. - Fault Indicates there is a problem with the FRU or resource at the location with which the indicator is associated. We register classdev structures for all individual LEDs detected on the system through LED specific device tree nodes. Device tree nodes specify what all kind of LEDs present on the same location code. It registers LED classdev structure for each of them. All the system LEDs can be found in the same regular path /sys/class/leds/. We don't use LED colors. We use LED node and led-types property to form LED classdev. Our LEDs have names in this format. <location_code>:<attention|identify|fault> Any positive brightness value would turn on the LED and a zero value would turn off the LED. The driver will return LED_FULL (255) for any turned on LED and LED_OFF (0) for any turned off LED. The platform level implementation of LED get and set state has been achieved through OPAL calls. These calls are made available for the driver by exporting from architecture specific codes. Signed-off-by:Anshuman Khandual <khandual@linux.vnet.ibm.com> Acked-by:
Stewart Smith <stewart@linux.vnet.ibm.com> Tested-by:
Jacek Anaszewski <j.anaszewski@samsung.com> Signed-off-by:
-
Vasant Hegde authored
This patch adds platform devices for leds. Also export LED related OPAL API's so that led driver can use these APIs. Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by:
-
Anshuman Khandual authored
This patch registers the following two new OPAL interfaces calls for the platform LED subsystem. With the help of these new OPAL calls, the kernel will be able to get or set the state of various individual LEDs on the system at any given location code which is passed through the LED specific device tree nodes. (1) OPAL_LEDS_GET_INDICATOR opal_leds_get_ind (2) OPAL_LEDS_SET_INDICATOR opal_leds_set_ind Signed-off-by:
-
Wei Yang authored
On powernv platform, IOV BAR would be shifted if necessary. While the log message is not correct when disabling VFs. This patch fixes this by print correct message based on the offset value. Signed-off-by:
Wei Yang <weiyang@linux.vnet.ibm.com> Signed-off-by:
-
Andrew Donnellan authored
If we open a context but do not start it (either because we do not attempt to start it, or because it fails to start for some reason), we are left with a context in state OPENED. Previously, cxl_release_context() only allowed releasing contexts in state CLOSED, so attempting to release an OPENED context would fail. In particular, this bug causes available contexts to run out after some EEH failures, where drivers attempt to release contexts that have failed to start. Allow releasing contexts in any state with a value lower than STARTED, i.e. OPENED or CLOSED (we can't release a STARTED context as it's currently using the hardware, and we assume that contexts in any new states which may be added in future with a value higher than STARTED are also unsafe to release). Cc: stable@vger.kernel.org Fixes: 6f7f0b3d ("cxl: Add AFU virtual PHB and kernel API") Signed-off-by:
Andrew Donnellan <andrew.donnellan@au1.ibm.com> Signed-off-by:
-
Javier Martinez Canillas authored
The I2C core always reports the MODALIAS uevent as "i2c:<client name" regardless if the driver was matched using the I2C id_table or the of_match_table. So technically there's no need for a driver to export the OF table since currently it's not used. In fact, the I2C device ID table is mandatory for I2C drivers since a i2c_device_id is passed to the driver's probe function even if the I2C core used the OF table to match the driver. And since the I2C core uses different tables, OF-only drivers needs to have duplicated data that has to be kept in sync and also the dev node compatible manufacturer prefix is stripped when reporting the MODALIAS. To avoid the above, the I2C core behavior may be changed in the future to not require an I2C device table for OF-only drivers and report the OF module alias. So, it's better to also export the OF table to prevent breaking module autoloading if that happens. Signed-off-by:
Javier Martinez Canillas <javier@osg.samsung.com> Signed-off-by:
-
Javier Martinez Canillas authored
The I2C core always reports the MODALIAS uevent as "i2c:<client name" regardless if the driver was matched using the I2C id_table or the of_match_table. So the driver needs to export the I2C table and this be built into the module or udev won't have the necessary information to auto load the correct module when the device is added. Signed-off-by:
-
- 19 Aug, 2015 2 commits
-
-
Gerhard Sittig authored
the PPC_MPC512x config automatically selected USB_EHCI_BIG_ENDIAN_* switches, which made Kconfig warn about "unmet direct dependencies": scripts/kconfig/conf --silentoldconfig Kconfig warning: (PPC_MPC512x && 440EPX) selects USB_EHCI_BIG_ENDIAN_DESC which has unmet direct dependencies (USB_SUPPORT && USB && USB_EHCI_HCD) warning: (PPC_MPC512x && PPC_PS3 && PPC_CELLEB && 440EPX) selects USB_EHCI_BIG_ENDIAN_MMIO which has unmet direct dependencies (USB_SUPPORT && USB && USB_EHCI_HCD) warning: (PPC_MPC512x && 440EPX) selects USB_EHCI_BIG_ENDIAN_DESC which has unmet direct dependencies (USB_SUPPORT && USB && USB_EHCI_HCD) warning: (PPC_MPC512x && PPC_PS3 && PPC_CELLEB && 440EPX) selects USB_EHCI_BIG_ENDIAN_MMIO which has unmet direct dependencies (USB_SUPPORT && USB && USB_EHCI_HCD) make the selected entries additionally depend on USB_EHCI_HCD which silences the warning Signed-off-by:
Gerhard Sittig <gsi@denx.de> Signed-off-by:
-
Hari Bathini authored
Pstore only supports one backend at a time. The preferred pstore backend is set by passing the pstore.backend=<name> argument to the kernel at boot time. Currently, while trying to register with pstore, nvram throws an error message even when "pstore.backend != nvram", which is unnecessary. This patch removes the error message in case "pstore.backend != nvram". Signed-off-by:
Hari Bathini <hbathini@linux.vnet.ibm.com> Signed-off-by:
-
- 18 Aug, 2015 13 commits
-
-
Ian Munsie authored
userspace programs using cxl currently have to use two strategies for dealing with MMIO errors simultaneously. They have to check every read for a return of all Fs in case the adapter has gone away and the kernel has not yet noticed, and they have to deal with SIGBUS in case the kernel has already noticed, invalidated the mapping and marked the context as failed. In order to simplify things, this patch adds an alternative approach where the kernel will return a page filled with Fs instead of delivering a SIGBUS. This allows userspace to only need to deal with one of these two error paths, and is intended for use in libraries that use cxl transparently and may not be able to safely install a signal handler. This approach will only work if certain constraints are met. Namely, if the application is both reading and writing to an address in the problem state area it cannot assume that a non-FF read is OK, as it may just be reading out a value it has previously written. Further - since only one page is used per context a write to a given offset would be visible when reading the same offset from a different page in the mapping (this only applies within a single context, not between contexts). An application could deal with this by e.g. making sure it also reads from a read-only offset after any reads to a read/write offset. Due to these constraints, this functionality must be explicitly requested by userspace when starting the context by passing in the CXL_START_WORK_ERR_FF flag. Signed-off-by:
-
Andrzej Hajda authored
The patch was generated using fixed coccinelle semantic patch scripts/coccinelle/api/memdup.cocci [1]. [1]: http://permalink.gmane.org/gmane.linux.kernel/2014320Signed-off-by:
Andrzej Hajda <a.hajda@samsung.com> Reviewed-by:
Nathan Fontenot <nfont@linux.vnet.ibm.com> Signed-off-by:
-
Andrzej Hajda authored
The patch was generated using fixed coccinelle semantic patch scripts/coccinelle/api/memdup.cocci [1]. [1]: http://permalink.gmane.org/gmane.linux.kernel/2014320Signed-off-by:
-
Gavin Shan authored
pcibios_set_pcie_reset_state() could be called to complete reset request when passing through PCI device, flag EEH_PE_ISOLATED is set before saving the PCI config sapce. On some Broadcom adapters, EEH_PE_CFG_BLOCKED is automatically set when the flag EEH_PE_ISOLATED is marked. It caused bogus data saved from the PCI config space, which will be restored to the PCI adapter after the reset. Eventually, the hardware can't work with corrupted data in PCI config space. The patch fixes the issue with eeh_pe_state_mark_no_cfg(), which doesn't set EEH_PE_CFG_BLOCKED when seeing EEH_PE_ISOLATED on the PE, in order to avoid the bogus data saved and restored to the PCI config space. Reported-by:
Rajanikanth H. Adaveeshaiah <rajanikanth.ha@in.ibm.com> Signed-off-by:
-
Gavin Shan authored
This adds include/uapi/asm/eeh.h to kbuild so that the header file will be exported automatically with below command. The header file was added by commit ed3e81ff ("powerpc/eeh: Move PE state constants around") make INSTALL_HDR_PATH=/tmp/headers \ SRCARCH=powerpc headers_install Signed-off-by:
-
Vaibhav Jain authored
A working rtc kernel driver is needed so that hwclock can synchronize system clock to rtc during shutdown/boot. We already have a powernv platform rtc driver located at drivers/rtc/rtc-opal.c. However it depends on CONFIG_RTC_CLASS which is disabled by default. Hence the driver isn't enabled and not compiled for the powernv kernel. We fix this by enabling rtc class support in pseries defconfig which enables this driver and compiles it into the pseries kernel. In case CONFIG_PPC_POWERNV is not enabled we fallback to 'Generic RTC support' driver which emulates the legacy 'PC RTC driver'. Signed-off-by:
-
Nikunj A Dadhania authored
In some situations, a NUMA guest that supports ibm,dynamic-memory-reconfiguration node will end up having flat NUMA distances between nodes. This is because of two problems in the current code. 1) Different representations of associativity lists. There is an assumption about the associativity list in initialize_distance_lookup_table(). Associativity list has two forms: a) [cpu,memory]@x/ibm,associativity has following format: <N> <N integers> b) ibm,dynamic-reconfiguration-memory/ibm,associativity-lookup-arrays <M> <N> <M associativity lists each having N integers> M = the number of associativity lists N = the number of entries per associativity list Fix initialize_distance_lookup_table() so that it does not assume "case a". And update the caller to skip the length field before sending the associativity list. 2) Distance table not getting updated from drconf path. Node distance table will not get initialized in certain cases as ibm,dynamic-reconfiguration-memory path does not initialize the lookup table. Call initialize_distance_lookup_table() from drconf path with appropriate associativity list. Reported-by:Bharata B Rao <bharata@linux.vnet.ibm.com> Signed-off-by:
Nikunj A Dadhania <nikunj@linux.vnet.ibm.com> Acked-by:
Anton Blanchard <anton@samba.org> Signed-off-by:
-
Andrew Donnellan authored
Simplify the dma_get_required_mask call chain by moving it from pnv_phb to pci_controller_ops, similar to commit 763d2d8d ("powerpc/powernv: Move dma_set_mask from pnv_phb to pci_controller_ops"). Previous call chain: 0) call dma_get_required_mask() (kernel/dma.c) 1) call ppc_md.dma_get_required_mask, if it exists. On powernv, that points to pnv_dma_get_required_mask() (platforms/powernv/setup.c) 2) device is PCI, therefore call pnv_pci_dma_get_required_mask() (platforms/powernv/pci.c) 3) call phb->dma_get_required_mask if it exists 4) it only exists in the ioda case, where it points to pnv_pci_ioda_dma_get_required_mask() (platforms/powernv/pci-ioda.c) New call chain: 0) call dma_get_required_mask() (kernel/dma.c) 1) device is PCI, therefore call pci_controller_ops.dma_get_required_mask if it exists 2) in the ioda case, that points to pnv_pci_ioda_dma_get_required_mask() (platforms/powernv/pci-ioda.c) In the p5ioc2 case, the call chain remains the same - dma_get_required_mask() does not find either a ppc_md call or pci_controller_ops call, so it calls __dma_get_required_mask(). Signed-off-by:
-
Michael Ellerman authored
The relation between CONFIG_PPC_HAS_HASH_64K and CONFIG_PPC_64K_PAGES is painfully complicated. But if we rearrange it enough we can see that PPC_HAS_HASH_64K essentially depends on PPC_STD_MMU_64 && PPC_64K_PAGES. We can then notice that PPC_HAS_HASH_64K is used in files that are only built for PPC_STD_MMU_64, meaning it's equivalent to PPC_64K_PAGES. So replace all uses and drop it. Signed-off-by:
Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
-
Michael Ellerman authored
For config options with only a single value, guarding the single value with 'if' is the same as adding a 'depends' statement. And it's more standard to just use 'depends'. And if the option has both an 'if' guard and a 'depends' we can collapse them into a single 'depends' by combining them with &&. Signed-off-by:
-
Michael Ellerman authored
Now that support for 64k pages with a 4K kernel is removed, this code is unreachable. CONFIG_PPC_HAS_HASH_64K can only be true when CONFIG_PPC_64K_PAGES is also true. But when CONFIG_PPC_64K_PAGES is true we include pte-hash64.h which includes pte-hash64-64k.h, which defines both pte_pagesize_index() and crucially __real_pte, which means this definition can never be used. Signed-off-by:
-
Michael Ellerman authored
Back in the olden days we added support for using 64K pages to map the SPU (Synergistic Processing Unit) local store on Cell, when the main kernel was using 4K pages. This was useful at the time because distros were using 4K pages, but using 64K pages on the SPUs could reduce TLB pressure there. However these days the number of Cell users is approaching zero, and supporting this option adds unpleasant complexity to the memory management code. So drop the option, CONFIG_SPU_FS_64K_LS, and all related code. Signed-off-by:
Jeremy Kerr <jk@ozlabs.org>
-
Michael Ellerman authored
The powerpc kernel can be built to have either a 4K PAGE_SIZE or a 64K PAGE_SIZE. However when built with a 4K PAGE_SIZE there is an additional config option which can be enabled, PPC_HAS_HASH_64K, which means the kernel also knows how to hash a 64K page even though the base PAGE_SIZE is 4K. This is used in one obscure configuration, to support 64K pages for SPU local store on the Cell processor when the rest of the kernel is using 4K pages. In this configuration, pte_pagesize_index() is defined to just pass through its arguments to get_slice_psize(). However pte_pagesize_index() is called for both user and kernel addresses, whereas get_slice_psize() only knows how to handle user addresses. This has been broken forever, however until recently it happened to work. That was because in get_slice_psize() the large kernel address would cause the right shift of the slice mask to return zero. However in commit 7aa0727f ("powerpc/mm: Increase the slice range to 64TB"), the get_slice_psize() code was changed so that instead of a right shift we do an array lookup based on the address. When passed a kernel address this means we index way off the end of the slice array and return random junk. That is only fatal if we happen to hit something non-zero, but when we do return a non-zero value we confuse the MMU code and eventually cause a check stop. This fix is ugly, but simple. When we're called for a kernel address we return 4K, which is always correct in this configuration, otherwise we use the slice mask. Fixes: 7aa0727f ("powerpc/mm: Increase the slice range to 64TB") Reported-by:
Cyril Bur <cyrilbur@gmail.com> Signed-off-by:
-
- 17 Aug, 2015 3 commits
-
-
Michael Ellerman authored
We forgot to install the tempfile, so when the selftests are installed and then run the subpage_prot_file test fails. Signed-off-by: -
Vaibhav Jain authored
This patch plugs the leak of irq_bitmap, allocated as part of initialization of cxl_context struct; during the call to afu_allocate_irqs. The bitmap is now release during the call to function afu_release_irqs. Reported-by:
Matthew R. Ochs <mrochs@linux.vnet.ibm.com> Signed-off-by:
-
Daniel Axtens authored
CONFIG_CXL_EEH is for CXL's EEH related code. Other drivers can depend on or #ifdef on this symbol to configure PERST behaviour, allowing CXL to participate in the EEH process. Reviewed-by:
-
- 14 Aug, 2015 6 commits
-
-
Daniel Axtens authored
EEH (Enhanced Error Handling) allows a driver to recover from the temporary failure of an attached PCI card. Enable basic CXL support for EEH. Signed-off-by:
-
Daniel Axtens authored
Provide a kernel API and a sysfs entry which allow a user to specify that when a card is PERSTed, it's image will stay the same, allowing it to participate in EEH. cxl_reset is used to reflash the card. In that case, we cannot safely assert that the image will not change. Therefore, disallow cxl_reset if the flag is set. Signed-off-by:
-
Daniel Axtens authored
If the driver doesn't participate in EEH, the AFUs will be removed by cxl_remove, which will be invoked by EEH. If the driver does particpate in EEH, the vPHB needs to stick around so that the it can particpate. In both cases, we shouldn't remove the AFU/vPHB. Reviewed-by:
-
Daniel Axtens authored
As with an adapter, some aspects of initialisation are done only once in the lifetime of an AFU: for example, allocating memory, or setting up sysfs/debugfs files. However, we may want to be able to do some parts of the initialisation multiple times: for example, in error recovery we want to be able to tear down and then re-map IO memory and IRQs. Therefore, refactor AFU init/teardown as follows. - Create two new functions: 'cxl_configure_afu', and its pair 'cxl_deconfigure_afu'. As with the adapter functions, these (de)configure resources that do not need to last the entire lifetime of the AFU. - Allocating and releasing memory remain the task of 'cxl_alloc_afu' and 'cxl_release_afu'. - Once-only functions that do not involve allocating/releasing memory stay in the overarching 'cxl_init_afu'/'cxl_remove_afu' pair. However, the task of picking an AFU mode and activating it has been broken out. Signed-off-by:
-
Daniel Axtens authored
Some aspects of initialisation are done only once in the lifetime of an adapter: for example, allocating memory for the adapter, allocating the adapter number, or setting up sysfs/debugfs files. However, we may want to be able to do some parts of the initialisation multiple times: for example, in error recovery we want to be able to tear down and then re-map IO memory and IRQs. Therefore, refactor CXL init/teardown as follows. - Keep the overarching functions 'cxl_init_adapter' and its pair, 'cxl_remove_adapter'. - Move all 'once only' allocation/freeing steps to the existing 'cxl_alloc_adapter' function, and its pair 'cxl_release_adapter' (This involves moving allocation of the adapter number out of cxl_init_adapter.) - Create two new functions: 'cxl_configure_adapter', and its pair 'cxl_deconfigure_adapter'. These two functions 'wire up' the hardware --- they (de)configure resources that do not need to last the entire lifetime of the adapter Signed-off-by:
-
Daniel Axtens authored
- MMIO pointer unmapping is guarded by a null pointer check. However, iounmap doesn't null the pointer, just invalidate it. Therefore, explicitly null the pointer after unmapping. - afu_desc_mmio also needs to be unmapped. - PCI regions are allocated in cxl_map_adapter_regs. Therefore they should be released in unmap, not elsewhere. Acked-by:
-
