- 13 2月, 2018 1 次提交
-
-
由 Charles Keepax 提交于
The cache pointer points to the actual memory used by the cache, as the comparison here is looking for the type of the cache it should check against cache_type. Fixes: 1ea975cf ("regmap: Add a function to check if a regmap register is cached") Signed-off-by: NCharles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by: NMark Brown <broonie@kernel.org>
-
- 07 2月, 2018 1 次提交
-
-
由 Ulf Hansson 提交于
Commit b539cc82 (PM / Domains: Ignore domain-idle-states that are not compatible), made it possible to ignore non-compatible domain-idle-states OF nodes. However, in case that happens while doing the OF parsing, the number of elements in the allocated array would exceed the numbers actually needed, thus wasting memory. Fix this by pre-iterating the genpd OF node and counting the number of compatible domain-idle-states nodes, before doing the allocation. While doing this, it makes sense to rework the code a bit to avoid open coding, of parts responsible for the OF node iteration. Let's also take the opportunity to clarify the function header for of_genpd_parse_idle_states(), about what is being returned in case of errors. Fixes: b539cc82 (PM / Domains: Ignore domain-idle-states that are not compatible) Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org> Reviewed-by: NLina Iyer <ilina@codeaurora.org> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 25 1月, 2018 3 次提交
-
-
由 Andy Shevchenko 提交于
Reuse property_entry_free_data() in property_entry_copy_data() to make code slightly cleaner. Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Andy Shevchenko 提交于
It's just a preparatory patch to use property_entry_free_data() later on. No functional change intended. Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Benjamin Gilbert 提交于
It doesn't actually do anything. Merge its help text into EXTRA_FIRMWARE. Fixes: 5620a0d1 ("firmware: delete in-kernel firmware") Fixes: 0946b2fb ("firmware: cleanup FIRMWARE_IN_KERNEL message") Signed-off-by: NBenjamin Gilbert <benjamin.gilbert@coreos.com> Signed-off-by: NRobin H. Johnson <robbat2@gentoo.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 24 1月, 2018 1 次提交
-
-
由 Eric W. Biederman 提交于
Today 4 architectures set ARCH_SUPPORTS_MEMORY_FAILURE (arm64, parisc, powerpc, and x86), while 4 other architectures set __ARCH_SI_TRAPNO (alpha, metag, sparc, and tile). These two sets of architectures do not interesect so remove the trapno paramater to remove confusion. Signed-off-by: N"Eric W. Biederman" <ebiederm@xmission.com>
-
- 23 1月, 2018 1 次提交
-
-
由 Arend van Spriel 提交于
This adds the coredump driver operation. When the driver defines it a coredump file is added in the sysfs folder of the device upon driver binding. The file is removed when the driver is unbound. User-space can trigger a coredump for this device by echo'ing to the coredump file. Signed-off-by: NArend van Spriel <aspriel@gmail.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 22 1月, 2018 4 次提交
-
-
由 Marcin Wojtas 提交于
Implement a new helper function fwnode_get_next_available_child_node(), which enables obtaining next enabled child fwnode, which works on a similar basis to OF's of_get_next_available_child(). This commit also introduces a macro, thanks to which it is possible to iterate over the available fwnodes, using the new function described above. Signed-off-by: NMarcin Wojtas <mw@semihalf.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Marcin Wojtas 提交于
Until now there were two very similar functions allowing to get Linux IRQ number from ACPI handle (acpi_irq_get()) and OF node (of_irq_get()). The first one appeared to be used only as a subroutine of platform_irq_get(), which (in the generic code) limited IRQ obtaining from _CRS method only to nodes associated to kernel's struct platform_device. This patch introduces a new helper routine - fwnode_irq_get(), which allows to get the IRQ number directly from the fwnode to be used as common for OF/ACPI worlds. It is usable not only for the parents fwnodes, but also for the child nodes comprising their own _CRS methods with interrupts description. In order to be able o satisfy compilation with !CONFIG_ACPI and also simplify the new code, introduce a helper macro (ACPI_HANDLE_FWNODE), with which it is possible to reach an ACPI handle directly from its fwnode. Signed-off-by: NMarcin Wojtas <mw@semihalf.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Marcin Wojtas 提交于
Until now there were two almost identical functions for obtaining network PHY mode - of_get_phy_mode() and, more generic, device_get_phy_mode(). However it is not uncommon, that the network interface is represented as a child of the actual controller, hence it is not associated directly to any struct device, required by the latter routine. This commit allows for getting the PHY mode for children nodes in the ACPI world by introducing a new function - fwnode_get_phy_mode(). This commit also changes device_get_phy_mode() routine to be its wrapper, in order to prevent unnecessary duplication. Signed-off-by: NMarcin Wojtas <mw@semihalf.com> Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Marcin Wojtas 提交于
Until now there were two almost identical functions for obtaining MAC address - of_get_mac_address() and, more generic, device_get_mac_address(). However it is not uncommon, that the network interface is represented as a child of the actual controller, hence it is not associated directly to any struct device, required by the latter routine. This commit allows for getting the MAC address for children nodes in the ACPI world by introducing a new function - fwnode_get_mac_address(). This commit also changes device_get_mac_address() routine to be its wrapper, in order to prevent unnecessary duplication. Signed-off-by: NMarcin Wojtas <mw@semihalf.com> Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 17 1月, 2018 1 次提交
-
-
由 Ulf Hansson 提交于
The pm_runtime_force_suspend|resume() helpers currently requires the device to at some level (PM domain, bus, etc), have the ->runtime_suspend|resume() callbacks assigned for it, else -ENOSYS is returned as an error. However, there are no reason for this requirement, so let's simply remove it by allowing these callbacks to be NULL. Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 16 1月, 2018 1 次提交
-
-
由 Rafael J. Wysocki 提交于
Modify pm_runtime_need_not_resume() to make it avoid taking power.child_count for devices with power.ignore_children which is consistent with the runtime PM usage of these fields. Suggested-by: NUlf Hansson <ulf.hansson@linaro.org> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: NUlf Hansson <ulf.hansson@linaro.org>
-
- 15 1月, 2018 2 次提交
-
-
由 Rafael J. Wysocki 提交于
One of the limitations of pm_runtime_force_suspend/resume() is that if a parent driver wants to use these functions, all of its child drivers generally have to do that too because of the parent usage counter manipulations necessary to get the correct state of the parent during system-wide transitions to the working state (system resume). However, that limitation turns out to be artificial, so remove it. Namely, pm_runtime_force_suspend() only needs to update the children counter of its parent (if there's is a parent) when the device can stay in suspend after the subsequent system resume transition, as that counter is correct already otherwise. Now, if the parent's children counter is not updated, it is not necessary to increment the parent's usage counter in that case any more, as long as the children counters of devices are checked along with their usage counters in order to decide whether or not the devices may be left in suspend after the subsequent system resume transition. Accordingly, modify pm_runtime_force_suspend() to only call pm_runtime_set_suspended() for devices whose usage and children counters are at the "no references" level (the runtime PM status of the device needs to be updated to "suspended" anyway in case this function is called once again for the same device during the transition under way), drop the parent usage counter incrementation from it and update pm_runtime_force_resume() to compensate for these changes. Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: NUlf Hansson <ulf.hansson@linaro.org>
-
由 Rafael J. Wysocki 提交于
There are problems with calling pm_runtime_force_suspend/resume() to "stop" and "start" devices in genpd_finish_suspend() and genpd_resume_noirq() (and in analogous hibernation-specific genpd callbacks) after commit 122a2237 (PM / Domains: Stop/start devices during system PM suspend/resume in genpd) as those routines do much more than just "stopping" and "starting" devices (which was the stated purpose of that commit) unnecessarily and may not play well with system-wide PM driver callbacks. First, consider the pm_runtime_force_suspend() in genpd_finish_suspend(). If the current runtime PM status of the device is "suspended", that function most likely does the right thing by ignoring the device, because it should have been "stopped" already and whatever needed to be done to deactivate it shoud have been done. In turn, if the runtime PM status of the device is "active", genpd_runtime_suspend() is called for it (indirectly) and (1) runs the ->runtime_suspend callback provided by the device's driver (assuming no bus type with ->runtime_suspend of its own), (2) "stops" the device and (3) checks if the domain can be powered down, and then (4) the device's runtime PM status is changed to "suspended". Out of the four actions above (1) is not necessary and it may be outright harmful, (3) is pointless and (4) is questionable. The only operation that needs to be carried out here is (2). The reason why (1) is not necessary is because the system-wide PM callbacks provided by the device driver for the transition in question have been run and they should have taken care of the driver's part of device suspend already. Moreover, it may be harmful, because the ->runtime_suspend callback may want to access the device which is partially suspended at that point and may not be responsive. Also, system-wide PM callbacks may have been run already (in the previous phases of the system transition under way) for the device's parent or for its supplier devices (if any) and the device may not be accessible because of that. There also is no reason to do (3), because genpd_finish_suspend() will repeat it anyway, and (4) potentially causes confusion to ensue during the subsequent system transition to the working state. Consider pm_runtime_force_resume() in genpd_resume_noirq() now. It runs genpd_runtime_resume() for all devices with runtime PM status set to "suspended", which includes all of the devices whose runtime PM status was changed by pm_runtime_force_suspend() before and may include some devices already suspended when the pm_runtime_force_suspend() was running, which may be confusing. The genpd_runtime_resume() first tries to power up the domain, which (again) is pointless, because genpd_resume_noirq() has done that already. Then, it "starts" the device and runs the ->runtime_resume callback (from the driver, say) for it. If all is well, the device is left with the runtime PM status set to "active". Unfortunately, running the driver's ->runtime_resume callback before its system-wide PM callbacks and possibly before some system-wide PM callbacks of the parent device's driver (let alone supplier drivers) is asking for trouble, especially if the device had been suspended before pm_runtime_force_suspend() ran previously or if the callbacks in question expect to be run back-to-back with their suspend-side counterparts. It also should not be necessary, because the system-wide PM driver callbacks that will be invoked for the device subsequently should take care of resuming it just fine. [Running the driver's ->runtime_resume callback in the "noirq" phase of the transition to the working state may be problematic even for devices whose drivers do use pm_runtime_force_resume() in (or as) their system-wide PM callbacks if they have suppliers other than their parents, because it may cause the supplier to be resumed after the consumer in some cases.] Because of the above, modify genpd as follows: 1. Change genpd_finish_suspend() to only "stop" devices with runtime PM status set to "active" (without invoking runtime PM callbacks for them, changing their runtime PM status and so on). That doesn't change the handling of devices whose drivers use pm_runtime_force_suspend/resume() in (or as) their system-wide PM callbacks and addresses the issues described above for the other devices. 2. Change genpd_resume_noirq() to only "start" devices with runtime PM status set to "active" (without invoking runtime PM callbacks for them, changing their runtime PM status and so on). Again, that doesn't change the handling of devices whose drivers use pm_runtime_force_suspend/resume() in (or as) their system-wide PM callbacks and addresses the described issues for the other devices. Devices with runtime PM status set to "suspended" are not started with the assumption that they will be resumed later, either by pm_runtime_force_resume() or via runtime PM. 3. Change genpd_restore_noirq() to follow genpd_resume_noirq(). That causes devices already suspended before hibernation to be left alone (which also is the case without the change) and avoids running the ->runtime_resume driver callback too early for the other devices. 4. Change genpd_freeze_noirq() and genpd_thaw_noirq() in accordance with the above modifications. Fixes: 122a2237 (PM / Domains: Stop/start devices during system PM suspend/resume in genpd) Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: NUlf Hansson <ulf.hansson@linaro.org>
-
- 12 1月, 2018 1 次提交
-
-
由 Ulf Hansson 提交于
In general, wakeup settings are not supposed to be changed during any of the system wide PM phases. The reason is simply that it would break guarantees provided by the PM core, to properly act on active wakeup sources. However, there are exceptions to when, in particular, disabling a device as wakeup source makes sense. For example, in cases when a driver realizes that its device is dead during system suspend. For these scenarios, we don't need to care about acting on the wakeup source correctly, because a dead device shouldn't deliver wakeup signals. To this reasoning and to help users to properly manage wakeup settings, let's print a warning in cases someone calls device_wakeup_enable() during system sleep. Suggested-by: NRafael J. Wysocki <rafael@kernel.org> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org> [ rjw: Message to be printed ] Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 11 1月, 2018 1 次提交
-
-
由 Ulf Hansson 提交于
Commit 10da6542 (PM / Domains: Call driver's noirq callbacks) started to respect driver's noirq callbacks, but while doing that it also introduced a few potential problems. More precisely, in genpd_finish_suspend() and genpd_resume_noirq() the noirq callbacks at the driver level should be invoked, no matter of whether dev->power.wakeup_path is set or not. Additionally, the commit in question also made genpd_resume_noirq() to ignore the return value from pm_runtime_force_resume(). Let's fix both these issues! Fixes: 10da6542 (PM / Domains: Call driver's noirq callbacks) Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 10 1月, 2018 2 次提交
-
-
由 Ulf Hansson 提交于
Currently the wakeup_path status flag becomes propagated from a child device to its parent device at __device_suspend(). This allows a driver dealing with a parent device to act on the flag from its ->suspend() callback. However, in situations when the wakeup_path status flag needs to be set from a ->suspend_late() callback, its value doesn't get propagated to the parent by the PM core. Let's address this limitation, by also propagating the flag at __device_suspend_late(). Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Ulf Hansson 提交于
To make the code more consistent, let's clear the parent's direct_complete flag along with clearing it for suppliers, instead of as currently, when propagating the wakeup_path flag to parents. While changing this, let's take the opportunity to rename the affected internal functions, to make them self-explanatory. Like this: dpm_clear_suppliers_direct_complete -> dpm_clear_superiors_direct_complete dpm_propagate_to_parent -> dpm_propagate_wakeup_to_parent Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 09 1月, 2018 2 次提交
-
-
由 Ulf Hansson 提交于
The PM core in the device_prepare() phase, resets the wakeup_path status flag to the value of device_may_wakeup(). This means if a ->prepare() or a ->suspend() callback for the device would update the device's wakeup setting, this doesn't become reflected in the wakeup_path status flag. In general this isn't a problem, because wakeup settings are not supposed to be changed (via for example calling device_set_wakeup_enable()) during any system wide suspend/resume phase. Nevertheless there are some users, which can be considered as legacy, that don't conform to this behaviour. These legacy cases should be corrected, however until that is done, let's address the issue from the PM core, by moving the assignment of the wakeup_path status flag to the __device_suspend() phase and after the ->suspend() callback has been invoked. Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Rafael J. Wysocki 提交于
Returning an error code from dev_pm_attach_wake_irq() if device_wakeup_attach_irq() called by it returns an error is pointless, because the wakeup source used by it may be deleted by user space via sysfs at any time and in particular right after dev_pm_attach_wake_irq() has returned. Moreover, it requires the callers of dev_pm_attach_wake_irq() to create that wakeup source via device_wakeup_enable() upfront, but that obviously is racy with respect to the sysfs-based manipulations of it. To avoid the race, modify device_wakeup_attach_irq() to check that the wakeup source it is going to use is there (and return early otherwise), make it void (as it cannot fail after that change) and make dev_pm_attach_wake_irq() simply call it for the device unconditionally. Tested-by: NTony Lindgren <tony@atomide.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 08 1月, 2018 4 次提交
-
-
由 Andrew F. Davis 提交于
All zero read and write masks in the regmap config are used to signal no special mask is needed and the bus defaults are used. In some devices all zero read/write masks are the special mask and bus defaults should not be used. To signal this a new variable is added. For example SPI often sets bit 7 in address to signal to the device a read is requested. On TI AFE44xx parts with SPI interfaces no bit needs to be set as registers are either read or write only and the operation can be determined from the address only. For this case both masks must be zero to not effect the address. Signed-off-by: NAndrew F. Davis <afd@ti.com> Signed-off-by: NMark Brown <broonie@kernel.org>
-
由 Andrew F. Davis 提交于
This makes the code slightly more readable and allows for cleaner addition of functionality in later patches. Signed-off-by: NAndrew F. Davis <afd@ti.com> Signed-off-by: NMark Brown <broonie@kernel.org>
-
由 Vinod Koul 提交于
SoundWire bus provides sdw_read() and sdw_write() APIs for Slave devices to program the registers. Provide support in regmap for SoundWire bus. Signed-off-by: NHardik T Shah <hardik.t.shah@intel.com> Signed-off-by: NSanyog Kale <sanyog.r.kale@intel.com> Reviewed-by: NPhilippe Ombredanne <pombredanne@nexb.com> Acked-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: NTakashi Iwai <tiwai@suse.de> Signed-off-by: NVinod Koul <vinod.koul@intel.com> Signed-off-by: NMark Brown <broonie@kernel.org>
-
由 Thomas Gleixner 提交于
As the meltdown/spectre problem affects several CPU architectures, it makes sense to have common way to express whether a system is affected by a particular vulnerability or not. If affected the way to express the mitigation should be common as well. Create /sys/devices/system/cpu/vulnerabilities folder and files for meltdown, spectre_v1 and spectre_v2. Allow architectures to override the show function. Signed-off-by: NThomas Gleixner <tglx@linutronix.de> Reviewed-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Will Deacon <will.deacon@arm.com> Cc: Dave Hansen <dave.hansen@intel.com> Cc: Linus Torvalds <torvalds@linuxfoundation.org> Cc: Borislav Petkov <bp@alien8.de> Cc: David Woodhouse <dwmw@amazon.co.uk> Link: https://lkml.kernel.org/r/20180107214913.096657732@linutronix.de
-
- 05 1月, 2018 1 次提交
-
-
由 Sergey Senozhatsky 提交于
print_symbol() is a very old API that has been obsoleted by %pS format specifier in a normal printk() call. Replace print_symbol() with a direct printk("%pS") call. Link: http://lkml.kernel.org/r/20171211125025.2270-10-sergey.senozhatsky@gmail.com To: Andrew Morton <akpm@linux-foundation.org> To: Russell King <linux@armlinux.org.uk> To: Catalin Marinas <catalin.marinas@arm.com> To: Mark Salter <msalter@redhat.com> To: Tony Luck <tony.luck@intel.com> To: David Howells <dhowells@redhat.com> To: Yoshinori Sato <ysato@users.sourceforge.jp> To: Guan Xuetao <gxt@mprc.pku.edu.cn> To: Borislav Petkov <bp@alien8.de> To: Greg Kroah-Hartman <gregkh@linuxfoundation.org> To: Thomas Gleixner <tglx@linutronix.de> To: Peter Zijlstra <peterz@infradead.org> To: Vineet Gupta <vgupta@synopsys.com> To: Fengguang Wu <fengguang.wu@intel.com> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: Petr Mladek <pmladek@suse.com> Cc: LKML <linux-kernel@vger.kernel.org> Cc: linux-arm-kernel@lists.infradead.org Cc: linux-c6x-dev@linux-c6x.org Cc: linux-ia64@vger.kernel.org Cc: linux-am33-list@redhat.com Cc: linux-sh@vger.kernel.org Cc: linux-edac@vger.kernel.org Cc: x86@kernel.org Cc: linux-snps-arc@lists.infradead.org Signed-off-by: NSergey Senozhatsky <sergey.senozhatsky@gmail.com> [pmladek@suse.com: updated commit message] Signed-off-by: NPetr Mladek <pmladek@suse.com>
-
- 03 1月, 2018 5 次提交
-
-
由 Rafael J. Wysocki 提交于
Make the PM core handle DPM_FLAG_LEAVE_SUSPENDED directly for devices whose "noirq", "late" and "early" driver callbacks are invoked directly by it. Namely, make it skip all of the system-wide resume callbacks for such devices with DPM_FLAG_LEAVE_SUSPENDED set if they are in runtime suspend during the "noirq" phase of system-wide suspend (or analogous) transitions or the system transition under way is a proper suspend (rather than anything related to hibernation) and the device's wakeup settings are compatible with runtime PM (that is, the device cannot generate wakeup signals at all or it is allowed to wake up the system from sleep). Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Rafael J. Wysocki 提交于
Make the PM core avoid invoking the "late" and "noirq" system-wide suspend (or analogous) callbacks provided by device drivers directly for devices with DPM_FLAG_SMART_SUSPEND set that are in runtime suspend during the "late" and "noirq" phases of system-wide suspend (or analogous) transitions. That is only done for devices without any middle-layer "late" and "noirq" suspend callbacks (to avoid confusing the middle layer if there is one). The underlying observation is that runtime PM is disabled for devices during the "late" and "noirq" system-wide suspend phases, so if they remain in runtime suspend from the "late" phase forward, it doesn't make sense to invoke the "late" and "noirq" callbacks provided by the drivers for them (arguably, the device is already suspended and in the right state). Thus, if the remaining driver suspend callbacks are to be invoked directly by the core, they can be skipped. This change really makes it possible for, say, platform device drivers to re-use runtime PM suspend and resume callbacks by pointing ->suspend_late and ->resume_early, respectively (and possibly the analogous hibernation-related callback pointers too), to them without adding any extra "is the device already suspended?" type of checks to the callback routines, as long as they will be invoked directly by the core. Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Rafael J. Wysocki 提交于
Add helper routines to find and return a suitable subsystem callback during the "noirq" phases of system suspend/resume (or analogous) transitions as well as during the "late" phase of system suspend and the "early" phase of system resume (or analogous) transitions. The helpers will be called from additional sites going forward. Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: NUlf Hansson <ulf.hansson@linaro.org> Reviewed-by: NGeert Uytterhoeven <geert+renesas@glider.be>
-
由 Rafael J. Wysocki 提交于
Since device_wakeup_disable() checks the device's power.can_wakeup flag, device_init_wakeup() doesn't need to do that before calling it, so drop that redundant check from device_init_wakeup(). No intentional changes in functionality. Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: NUlf Hansson <ulf.hansson@linaro.org>
-
由 Rafael J. Wysocki 提交于
Since both device_wakeup_enable() and device_wakeup_disable() check if dev is not NULL and whether or not power.can_wakeup is set for it, device_set_wakeup_enable() doesn't have to do that, so drop that check from it. No intentional changes in functionality. Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: NUlf Hansson <ulf.hansson@linaro.org>
-
- 27 12月, 2017 2 次提交
-
-
由 Baolin Wang 提交于
Since the hwlock id 0 is valid for hardware spinlock core, but now id 0 is treated as one invalid value for regmap. Thus we should add one extra flag for regmap config to indicate if a hardware spinlock should be used, then id 0 can be valid for regmap to request. Signed-off-by: NBaolin Wang <baolin.wang@linaro.org> Signed-off-by: NMark Brown <broonie@kernel.org>
-
由 Bartosz Golaszewski 提交于
This is a follow-up to commit a5ba91c3 ("regmap: debugfs: emit a debug message when locking is disabled"). I figured that a user may see this message, grep the code, come to this place and he still won't know why we actually disabled debugfs. Add a comment explaining the reason. Signed-off-by: NBartosz Golaszewski <brgl@bgdev.pl> Signed-off-by: NMark Brown <broonie@kernel.org>
-
- 21 12月, 2017 1 次提交
-
-
由 Bartosz Golaszewski 提交于
We currently silently omit creating the debugfs entries when regmap locking is disabled. Users may not be aware of the reason for which regmap files don't show up in debugfs. Add a dev_dbg() message explaining that. Signed-off-by: NBartosz Golaszewski <brgl@bgdev.pl> Signed-off-by: NMark Brown <broonie@kernel.org>
-
- 19 12月, 2017 3 次提交
-
-
由 Krzysztof Adamski 提交于
The map->work_buf is a buffer preallocated in __regmap_init() with size allowing it to store all 3 parts of a buffer - reg, pad and val. While reg and val parts are always properly setup before each transaction, the pad part is left at its default value (zeros). Until it is overwritten, that is. _regmap_bus_read(), when calling _regmap_raw_read() uses beginning of work_buf as a place to store data read. Usually that is fine but if val_bits > reg_bits && pad_bits > 0, padding area of work_buf() may get overwritten. Since padding is not zeroed before each transaction, garbage will be used on next calls. This patch moves the val pointer used for _regmap_raw_read() to point to a part of work_buf intended for storing value read. Signed-off-by: NKrzysztof Adamski <krzysztof.adamski@nokia.com> Signed-off-by: NMark Brown <broonie@kernel.org>
-
由 Srinivas Kandagatla 提交于
This patch adds support to read/write SLIMbus value elements. Currently it only supports byte read/write. Adding this support in regmap would give codec drivers more flexibility when there are more than 2 control interfaces like SLIMbus, i2c. Without this patch each codec driver has to directly call SLIMbus value element apis, and this could would get messy once we want to add i2c interface to it. Signed-off-by: NSrinivas Kandagatla <srinivas.kandagatla@linaro.org> Reviwed-by: NMark Brown <broonie@kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Brian Norris 提交于
I'll admit admit it: I've written bad driver code that tries to configure a device's wake IRQ without having called device_init_wakeup() first. But do you really have to ask ask me twice? Signed-off-by: NBrian Norris <briannorris@chromium.org> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 18 12月, 2017 2 次提交
-
-
由 Maciej Purski 提交于
Currently there is no information in any vfs about which devices a master component consists of, what makes debugging hard if one of the component devices fails to register. Add 'device_component' directory to debugfs. Create a new file for each component master, when it has been added. Remove it on a master deletion. Show a list of devices required by the given master and their status (registered or not). This provides an easy way to check, which device has failed to register if the given master device is not available in the system. Signed-off-by: NMaciej Purski <m.purski@samsung.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Gimcuan Hui 提交于
When error happens, these interators return the error, no interation should be continued, so make the change for getting out of while immediately. Signed-off-by: NGimcuan Hui <gimcuan@gmail.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 16 12月, 2017 1 次提交
-
-
由 Sudeep Holla 提交于
Commit dfea747d ("drivers: base: cacheinfo: support DT overrides for cache properties") doesn't initialise the cache type if it's present only in DT and the architecture is not aware of it. They are unified system level cache which are generally transparent. This patch check if the cache type is set to NOCACHE but the DT node indicates that it's unified cache and sets the cache type accordingly. Fixes: dfea747d ("drivers: base: cacheinfo: support DT overrides for cache properties") Reported-and-tested-by: NTan Xiaojun <tanxiaojun@huawei.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NSudeep Holla <sudeep.holla@arm.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-