- 20 10月, 2013 2 次提交
-
-
由 Alexandre Courbot 提交于
Refactor the of_ functions of gpiolib to use the now public gpiod interface, and export of_get_named_gpiod_flags() and of_get_gpiod_flags() functions. Signed-off-by: NAlexandre Courbot <acourbot@nvidia.com> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Alexandre Courbot 提交于
This patch exports the gpiod_* family of API functions, a safer alternative to the legacy GPIO interface. Differences between the gpiod and legacy gpio APIs are: - gpio works with integers, whereas gpiod operates on opaque handlers which cannot be forged or used before proper acquisition - gpiod get/set functions are aware of the active low state of a GPIO - gpio consumers should now include <linux/gpio/consumer.h> to access the new interface, whereas chips drivers will use <linux/gpio/driver.h> The legacy gpio API is now built as inline functions on top of gpiod. Signed-off-by: NAlexandre Courbot <acourbot@nvidia.com> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
- 19 10月, 2013 1 次提交
-
-
由 Markus Mayer 提交于
The physical address of the GPIO memory address is already printed implicitly by dev_info() as part of the device name. The virtual address doesn't add any value. In addition, printing a resource_size_t with %x lead to a compiler warning on some platforms. Signed-off-by: NMarkus Mayer <markus.mayer@linaro.org> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
- 18 10月, 2013 1 次提交
-
-
由 Greg Kroah-Hartman 提交于
This reverts commit 90d33f3e as it's not the correct fix for this issue, and it causes a build warning to be added to the kernel tree. Cc: K. Y. Srinivasan <kys@microsoft.com> Cc: <stable@vger.kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 17 10月, 2013 14 次提交
-
-
由 Rafael J. Wysocki 提交于
Two functions defined in device_pm.c, acpi_dev_pm_add_dependent() and acpi_dev_pm_remove_dependent(), have no callers and may be dropped, so drop them. Moreover, they are the only functions adding entries to and removing entries from the power_dependent list in struct acpi_device, so drop that list too. Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Aaron Lu 提交于
Previously, we wanted SCSI devices corrsponding to ATA devices to be runtime resumed when the power resource for those ATA device was turned on by some other device, so we added the SCSI device to the dependent device list of the ATA device's ACPI node. However, this code has no effect after commit 41863fce (ACPI / power: Drop automaitc resume of power resource dependent devices) and the mechanism it was supposed to implement is regarded as a bad idea now, so drop it. [rjw: Changelog] Signed-off-by: NAaron Lu <aaron.lu@intel.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Stephen Warren 提交于
Whenever an IRQ is claimed or freed, call gpio_lock_as_irq() or gpio_unlock_as_irq() on the associated GPIO, to prevent that GPIO from being configured in a manner incompatible with an interrupt. Signed-off-by: NStephen Warren <swarren@nvidia.com> Reviewed-by: NJavier Martinez Canillas <javier@dowhile0.org> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Yasuaki Ishimatsu 提交于
When inserting a wrong value to /sys/devices/system/memory/memoryX/state file, following messages are shown. And device_hotplug_lock is never released. ================================================ [ BUG: lock held when returning to user space! ] 3.12.0-rc4-debug+ #3 Tainted: G W ------------------------------------------------ bash/6442 is leaving the kernel with locks still held! 1 lock held by bash/6442: #0: (device_hotplug_lock){+.+.+.}, at: [<ffffffff8146cbb5>] lock_device_hotplug_sysfs+0x15/0x50 This issue was introdued by commit fa2be40f (drivers: base: use standard device online/offline for state change). This patch releases device_hotplug_lcok when store_mem_state returns EINVAL. Signed-off-by: NYasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com> Reviewed-by: NToshi Kani <toshi.kani@hp.com> CC: Seth Jennings <sjenning@linux.vnet.ibm.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Charles Keepax 提交于
The index field of cpufreq_frequency_table has been renamed to driver_data by commit 50701588 (cpufreq: rename index as driver_data in cpufreq_frequency_table). This patch updates the s3c64xx driver to match. Signed-off-by: NCharles Keepax <ckeepax@opensource.wolfsonmicro.com> Cc: 3.11+ <stable@vger.kernel.org> # 3.11+ Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Rafael J. Wysocki 提交于
The mechanism causing devices depending on a given power resource (that is, devices that can be in D0 only if that power resource is on) to be resumed automatically when the power resource is turned on (and their "inferred" power state becomes D0 as a result) is inherently racy and in fact unnecessary. It is racy, because if the power resource is turned on and then immediately off, the device resume triggered by the first transition to "on" may still happen, causing the power resource to be turned on again. That again will trigger the "resume of dependent devices" mechanism, but if the devices in question are not in use, they will be suspended in the meantime causing the power resource to be turned off. However, the "resume of dependent devices" will next resume them again and so on. In some cases (USB port PM in particular) that leads to an endless busy loop of flipping the resource on and off continuously. It is needless, because whoever turns a power resource on will most likely turn it off at some point and the devices that go into "D0" as a result of turning it on will then go back into D3cold (generally, the state they were in before). Moreover, turning on all power resources a device needs to go into D0 is not sufficient for a full transition into D0 in general. Namely, _PS0 may need to be executed in addition to that in some cases. This means that the whole rationale of the "resume of dependent devices" mechanism was incorrect to begin with and it's best to remove it entirely. Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Rafael J. Wysocki 提交于
The expression in line 398 of intel_pstate.c causes the following warning to be emitted: drivers/cpufreq/intel_pstate.c:398:3: warning: left shift count >= width of type which happens because unsigned long is 32-bit on some architectures. Fix that by using a helper u64 variable and simplify the code slightly. Tested-by: NSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 K. Y. Srinivasan 提交于
Rescind of subchannels were not being correctly handled. Fix the bug. Signed-off-by: NK. Y. Srinivasan <kys@microsoft.com> Cc: <stable@vger.kernel.org> [3.11+] Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Matthew Dawson 提交于
The USB3503 driver had an incorrect depedency on REGMAP, instead of REGMAP_I2C. This caused the build to fail since the necessary regmap i2c pieces were not available. Signed-off-by: NMatthew Dawson <matthew@mjdsystems.ca> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Russell King - ARM Linux 提交于
When CMA fails to initialize in v3.12-rc4, the chipidea driver oopses the kernel while trying to remove and put the HCD which doesn't exist: WARNING: CPU: 0 PID: 6 at /home/rmk/git/linux-rmk/arch/arm/mm/dma-mapping.c:511 __dma_alloc+0x200/0x240() coherent pool not initialised! Modules linked in: CPU: 0 PID: 6 Comm: kworker/u2:0 Tainted: G W 3.12.0-rc4+ #56 Workqueue: deferwq deferred_probe_work_func Backtrace: [<c001218c>] (dump_backtrace+0x0/0x10c) from [<c0012328>] (show_stack+0x18/0x1c) r6:c05fd9cc r5:000001ff r4:00000000 r3:df86ad00 [<c0012310>] (show_stack+0x0/0x1c) from [<c05f3a4c>] (dump_stack+0x70/0x8c) [<c05f39dc>] (dump_stack+0x0/0x8c) from [<c00230a8>] (warn_slowpath_common+0x6c/0x8c) r4:df883a60 r3:df86ad00 [<c002303c>] (warn_slowpath_common+0x0/0x8c) from [<c002316c>] (warn_slowpath_fmt+0x38/0x40) r8:ffffffff r7:00001000 r6:c083b808 r5:00000000 r4:df2efe80 [<c0023134>] (warn_slowpath_fmt+0x0/0x40) from [<c00196bc>] (__dma_alloc+0x200/0x240) r3:00000000 r2:c05fda00 [<c00194bc>] (__dma_alloc+0x0/0x240) from [<c001982c>] (arm_dma_alloc+0x88/0xa0) [<c00197a4>] (arm_dma_alloc+0x0/0xa0) from [<c03e2904>] (ehci_setup+0x1f4/0x438) [<c03e2710>] (ehci_setup+0x0/0x438) from [<c03cbd60>] (usb_add_hcd+0x18c/0x664) [<c03cbbd4>] (usb_add_hcd+0x0/0x664) from [<c03e89f4>] (host_start+0xf0/0x180) [<c03e8904>] (host_start+0x0/0x180) from [<c03e7c34>] (ci_hdrc_probe+0x360/0x670 ) r6:df2ef410 r5:00000000 r4:df2c3010 r3:c03e8904 [<c03e78d4>] (ci_hdrc_probe+0x0/0x670) from [<c0311044>] (platform_drv_probe+0x20/0x24) [<c0311024>] (platform_drv_probe+0x0/0x24) from [<c030fcac>] (driver_probe_device+0x9c/0x234) ... ---[ end trace c88ccaf3969e8422 ]--- Unable to handle kernel NULL pointer dereference at virtual address 00000028 pgd = c0004000 [00000028] *pgd=00000000 Internal error: Oops: 17 [#1] SMP ARM Modules linked in: CPU: 0 PID: 6 Comm: kworker/u2:0 Tainted: G W 3.12.0-rc4+ #56 Workqueue: deferwq deferred_probe_work_func task: df86ad00 ti: df882000 task.ti: df882000 PC is at usb_remove_hcd+0x10/0x150 LR is at host_stop+0x1c/0x3c pc : [<c03cacec>] lr : [<c03e88e4>] psr: 60000013 sp : df883b50 ip : df883b78 fp : df883b74 r10: c11f4c54 r9 : c0836450 r8 : df30c400 r7 : fffffff4 r6 : df2ef410 r5 : 00000000 r4 : df2c3010 r3 : 00000000 r2 : 00000000 r1 : df86b0a0 r0 : 00000000 Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel Control: 10c53c7d Table: 2f29404a DAC: 00000015 Process kworker/u2:0 (pid: 6, stack limit = 0xdf882240) Stack: (0xdf883b50 to 0xdf884000) ... Backtrace: [<c03cacdc>] (usb_remove_hcd+0x0/0x150) from [<c03e88e4>] (host_stop+0x1c/0x3c) r6:df2ef410 r5:00000000 r4:df2c3010 [<c03e88c8>] (host_stop+0x0/0x3c) from [<c03e8aa0>] (ci_hdrc_host_destroy+0x1c/0x20) r5:00000000 r4:df2c3010 [<c03e8a84>] (ci_hdrc_host_destroy+0x0/0x20) from [<c03e7c80>] (ci_hdrc_probe+0x3ac/0x670) [<c03e78d4>] (ci_hdrc_probe+0x0/0x670) from [<c0311044>] (platform_drv_probe+0x20/0x24) [<c0311024>] (platform_drv_probe+0x0/0x24) from [<c030fcac>] (driver_probe_device+0x9c/0x234) [<c030fc10>] (driver_probe_device+0x0/0x234) from [<c030ff28>] (__device_attach+0x44/0x48) ... ---[ end trace c88ccaf3969e8423 ]--- Fix this so at least we can continue booting and get to a shell prompt. Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk> Tested-by: NRussell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Oliver Neukum 提交于
Some USB drive enclosures do not correctly report an overflow condition if they hold a drive with a capacity over 2TB and are confronted with a READ_CAPACITY_10. They answer with their capacity modulo 2TB. The generic layer cannot cope with that. It must be told to use READ_CAPACITY_16 from the beginning. Signed-off-by: NOliver Neukum <oneukum@suse.de> Cc: stable <stable@vger.kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Enrico Mioso 提交于
Interface 6 of this device speaks QMI as per tests done by us. Credits go to Antonella for providing the hardware. Signed-off-by: NEnrico Mioso <mrkiko.rs@gmail.com> Signed-off-by: NAntonella Pellizzari <anto.pellizzari83@gmail.com> Tested-by: NDan Williams <dcbw@redhat.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Roel Kluin 提交于
Due to missing braces on an if statement, in presence of a device_node a port was always assigned -1, regardless of any alias entries in the device tree. Conversely, if device_node was NULL, an unitialized port ended up being used. This patch adds the missing braces, fixing the issues. Signed-off-by: NRoel Kluin <roel.kluin@gmail.com> Acked-by: NTony Prisk <linux@prisktech.co.nz> Cc: stable <stable@vger.kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Oliver Neukum 提交于
The device descriptors are messed up after remote wakeup Signed-off-by: NOliver Neukum <oneukum@suse.de> Cc: stable <stable@vger.kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 16 10月, 2013 21 次提交
-
-
由 Sachin Kamat 提交于
'of_match_ptr' is defined in linux/of.h. Include it explicitly to avoid build breakage in the future. Signed-off-by: NSachin Kamat <sachin.kamat@linaro.org> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Sachin Kamat 提交于
'of_match_ptr' is defined in linux/of.h. Include it explicitly to avoid build breakage in the future. Signed-off-by: NSachin Kamat <sachin.kamat@linaro.org> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Javier Martinez Canillas 提交于
The OMAP GPIO driver keeps track about GPIO pins that are used as IRQ lines for two reasons: 1) To prevent GPIO banks to be disabled while one of their GPIO pins are only used as an interrupt line. 2) To not allow another caller to set the GPIO pin as output. Now gpiolib has an API to mark GPIO pins as used as IRQ lines so the GPIO core only allows to set as output GPIO pins not tied to an IRQ. So there is no need to have custom code for 2). The IRQ usage still has to be maintained locally for 1) though. Signed-off-by: NJavier Martinez Canillas <javier.martinez@collabora.co.uk> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Linus Walleij 提交于
When an IRQ is started on a GPIO line, mark this GPIO as IRQ in the gpiolib so we can keep track of the usage centrally. Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Linus Walleij 提交于
When an IRQ is started on a GPIO line, mark this GPIO as IRQ in the gpiolib so we can keep track of the usage centrally. Cc: Enric Balletbo i Serra <eballetbo@gmail.com> Cc: Grant Likely <grant.likely@linaro.org> Cc: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Stephen Warren <swarren@wwwdotorg.org> Cc: Javier Martinez Canillas <javier.martinez@collabora.co.uk> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Linus Walleij 提交于
It is currently often possible in many GPIO drivers to request a GPIO line to be used as IRQ after calling gpio_to_irq() and, as the gpiolib is not aware of this, set the same line to output and start driving it, with undesired side effects. As it is a bogus usage scenario to request a line flagged as output to used as IRQ, we introduce APIs to let gpiolib track the use of a line as IRQ, and also set this flag from the userspace ABI. The API is symmetric so that lines can also be flagged from .irq_enable() and unflagged from IRQ by .irq_disable(). The debugfs file is altered so that we see if a line is reserved for IRQ. Cc: Enric Balletbo i Serra <eballetbo@gmail.com> Cc: Grant Likely <grant.likely@linaro.org> Cc: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Acked-by: NAlexandre Courbot <acourbot@nvidia.com> Reviewed-by: NStephen Warren <swarren@nvidia.com> Reviewed-by: NJavier Martinez Canillas <javier.martinez@collabora.co.uk> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Linus Walleij 提交于
I have no idea why this driver is using __raw* accessors for reading and writing registers, I suspect it is just force of habit or copy/paste. Change all to readb()/writeb() except one chain where I used writeb_relaxed() up until the last writeb(). Cc: Ryan Mallon <rmallon@gmail.com> Cc: H Hartley Sweeten <hartleys@visionengravers.com> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Linus Walleij 提交于
Rename the argument "virq" to just "irq", this IRQ isn't any more "virtual" than any other Linux IRQ number, we use "hwirq" for the actual hw-numbers, "virq" is just bogus. When doing this I see that the hwirq argument is used for mapping rather than the Linux IRQ in the map function. This doesn't look right. Use the Linux IRQ instead. I cannot test this patch so I don't know if the mapping change is correct, however since absolutely every other driver does it the other way around this doesn't look sound at all. Please help out with review. Cc: Vipul Kumar Samar <vipulkumar.samar@st.com> Cc: Lee Jones <lee.jones@linaro.org> Cc: Gabriel Fernandez <gabriel.fernandez@st.com> Cc: Jean-Nicolas Graux <jean-nicolas.graux@st.com> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Linus Walleij 提交于
Rename the argument "virq" to just "irq", this IRQ isn't any more "virtual" than any other Linux IRQ number, we use "hwirq" for the actual hw-numbers, "virq" is just bogus. Cc: Magnus Damm <damm@opensource.se> Acked-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Linus Walleij 提交于
Rename the argument "virq" to just "irq", this IRQ isn't any more "virtual" than any other Linux IRQ number, we use "hwirq" for the actual hw-numbers, "virq" is just bogus. Cc: Haojian Zhuang <haojian.zhuang@linaro.org> Cc: Rob Herring <rob.herring@calxeda.com> Acked-by: NBaruch Siach <baruch@tkos.co.il> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Linus Walleij 提交于
Rename the argument "virq" to just "irq", this IRQ isn't any more "virtual" than any other Linux IRQ number, we use "hwirq" for the actual hw-numbers, "virq" is just bogus. Cc: Anatolij Gustschin <agust@denx.de> Cc: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Linus Walleij 提交于
Rename the argument "virq" to just "irq", this IRQ isn't any more "virtual" than any other Linux IRQ number, we use "hwirq" for the actual hw-numbers, "virq" is just bogus. Take this opportunity to sink a variable into a loop. Acked-by: NMathias Nyman <mathias.nyman@linux.intel.com> Acked-by: NMika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Linus Walleij 提交于
Rename the argument "virq" to just "irq", this IRQ isn't any more "virtual" than any other Linux IRQ number, we use "hwirq" for the actual hw-numbers, "virq" is just bogus. Acked-by: NDavid Cohen <david.a.cohen@linux.intel.com> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Linus Walleij 提交于
Rename the argument "virq" to just "irq", this IRQ isn't any more "virtual" than any other Linux IRQ number, we use "hwirq" for the actual hw-numbers, "virq" is just bogus. Cc: Magnus Damm <damm@opensource.se> Reviewed-by: NIan Molton <ian.molton@codethink.co.uk> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Linus Walleij 提交于
Rename the argument "virq" to just "irq", this IRQ isn't any more "virtual" than any other Linux IRQ number, we use "hwirq" for the actual hw-numbers, "virq" is just bogus. Rename the "gpio" variable to "hwirq" to reflect what it is. Rename one instance of "virq" to "child_irq" that better describes what it is. Cc: Markus Mayer <markus.mayer@linaro.org> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Linus Walleij 提交于
This variable is confusingly named, the different Linux IRQs aren't any more virtual than any other Linux IRQ. Give it a non-misleading name. Acked-by: NLars Poeschel <poeschel@lemonage.de> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Mikulas Patocka 提交于
This patch fixes a particular type of data corruption that has been encountered when loading a snapshot's metadata from disk. When we allocate a new chunk in persistent_prepare, we increment ps->next_free and we make sure that it doesn't point to a metadata area by further incrementing it if necessary. When we load metadata from disk on device activation, ps->next_free is positioned after the last used data chunk. However, if this last used data chunk is followed by a metadata area, ps->next_free is positioned erroneously to the metadata area. A newly-allocated chunk is placed at the same location as the metadata area, resulting in data or metadata corruption. This patch changes the code so that ps->next_free skips the metadata area when metadata are loaded in function read_exceptions. The patch also moves a piece of code from persistent_prepare_exception to a separate function skip_metadata to avoid code duplication. CVE-2013-4299 Signed-off-by: NMikulas Patocka <mpatocka@redhat.com> Cc: stable@vger.kernel.org Cc: Mike Snitzer <snitzer@redhat.com> Signed-off-by: NAlasdair G Kergon <agk@redhat.com>
-
由 Dirk Brandewie 提交于
If the system is suspended while max_perf_pct is less than 100 percent or no_turbo set policy->{min,max} will be set incorrectly with scaled values which turn the scaled values into hard limits. References: https://bugzilla.kernel.org/show_bug.cgi?id=61241Reported-by: NPatrick Bartels <petzicus@googlemail.com> Signed-off-by: NDirk Brandewie <dirk.j.brandewie@intel.com> Cc: 3.9+ <stable@vger.kernel.org> # 3.9+ Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Krzysztof Mazur 提交于
Commit 1696d9dc (ACPI: Remove the old /proc/acpi/event interface) left /proc/acpi/event in the ACPI_BUTTON help in Kconfig, so remove it from there. [rjw: Changelog] Signed-off-by: NKrzysztof Mazur <krzysiek@podlesie.net> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Lan Tianyu 提交于
In acpi_resume_power_resources() resource_lock should be released when acpi_power_get_state() fails and before passing to next power resource on the list. Signed-off-by: NLan Tianyu <tianyu.lan@intel.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Lars-Peter Clausen 提交于
Usually the active scan mask is freed in __iio_update_buffers() when the buffer is disabled. But when the device is still sampling when it is removed we'll end up disabling the buffers in iio_disable_all_buffers(). So we also need to free the active scan mask here, otherwise it will be leaked. Signed-off-by: NLars-Peter Clausen <lars@metafoo.de> Signed-off-by: NJonathan Cameron <jic23@kernel.org>
-
- 15 10月, 2013 1 次提交
-
-
由 Marek Szyprowski 提交于
This reverts commit 9d8eab7a. There is still no consensus on the bindings for the reserved memory and various drawbacks of the proposed solution has been shown, so the best now is to revert it completely and start again from scratch later. Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: NGrant Likely <grant.likely@linaro.org>
-