Currently, there are two separate ways of handling device wakeup
settings in the ACPI core, depending on whether this is runtime
wakeup or system wakeup (from sleep states). However, after the
previous commit eliminating the run_wake ACPI device wakeup flag,
there is no difference between the two any more at the ACPI level,
so they can be combined.
For this reason, introduce acpi_pm_set_device_wakeup() to replace both
acpi_pm_device_run_wake() and acpi_pm_device_sleep_wake() and make it
check the ACPI device object's wakeup.valid flag to determine whether
or not the device can be set up to generate wakeup signals.
Also notice that zpodd_enable/disable_run_wake() only call
device_set_run_wake() because acpi_pm_device_run_wake() called
device_run_wake(), which is not done by acpi_pm_set_device_wakeup(),
so drop the now redundant device_set_run_wake() calls from there.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
The run_wake flag in struct acpi_device_wakeup_flags stores the
information on whether or not the device can generate wakeup
signals at run time, but in ACPI that really is equivalent to
being able to generate wakeup signals at all.
In fact, run_wake will always be set after successful executeion of
acpi_setup_gpe_for_wake(), but if that fails, the device will not be
able to use a wakeup GPE at all, so it won't be able to wake up the
systems from sleep states too. Hence, run_wake actually means that
the device is capable of triggering wakeup and so it is equivalent
to the valid flag.
For this reason, drop run_wake from struct acpi_device_wakeup_flags
and make sure that the valid flag is only set if
acpi_setup_gpe_for_wake() has been successful.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Require all dax-drivers to register a ->copy_from_iter() operation so
that it is clear which dax_operations are optional and which must be
implemented for filesystem-dax to operate.
Cc: Gerald Schaefer <gerald.schaefer@de.ibm.com>
Suggested-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Allow volatile nfit ranges to participate in all the same infrastructure
provided for persistent memory regions. A resulting resulting namespace
device will still be called "pmem", but the parent region type will be
"nd_volatile". This is in preparation for disabling the dax ->flush()
operation in the pmem driver when it is hosted on a volatile range.
Cc: Jan Kara <jack@suse.cz>
Cc: Jeff Moyer <jmoyer@redhat.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Matthew Wilcox <mawilcox@microsoft.com>
Cc: Ross Zwisler <ross.zwisler@linux.intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
The controller state is set to resetting prior to disabling the
controller, so this patch accounts for that state when deciding if it
needs to freeze the queues. Without this, an 'nvme reset /dev/nvme0'
blocks forever because the queues were never frozen.
Fixes: 82b057caef ("nvme-pci: fix multiple ctrl removal scheduling")
Signed-off-by: Keith Busch <keith.busch@intel.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
The pmem driver assumes if platform firmware describes the memory
devices associated with a persistent memory range and
CONFIG_ARCH_HAS_PMEM_API=y that it has all the mechanism necessary to
flush data to a power-fail safe zone. We warn if the firmware does not
describe memory devices, but we also need to warn if the architecture
does not claim pmem support.
Cc: Jeff Moyer <jmoyer@redhat.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Matthew Wilcox <mawilcox@microsoft.com>
Cc: Ross Zwisler <ross.zwisler@linux.intel.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
The switchtec driver also supports the PAX, PFXL and PFXI products which
have the same management interface.
Signed-off-by: Logan Gunthorpe <logang@deltatee.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Kurt Schwemmer <kurt.schwemmer@microsemi.com>
This flag lets userspace know which firmware partitions are currently in
use as opposed to just active. "Active" means they will be in use for the
next reboot, whereas "running" means they are currently in use.
If an old kernel is in use, or the firmware doesn't support these fields,
the new flag will not be set in the output.
Signed-off-by: Logan Gunthorpe <logang@deltatee.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Kurt Schwemmer <kurt.schwemmer@microsemi.com>
Drop the dependency on RESET_CONTROLLER for the Keystone remoteproc
driver to resolve some circular dependencies around different choices
for RESET_CONTROLLER on common ARM configs. This dependency is
inherent as the RESET_CONTROLLER will be enabled due to the enabled
ARCH_HAS_RESET_CONTROLLER for ARCH_KEYSTONE.
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
All the remoteproc platform driver Kconfig symbols are defined and
included under an if REMOTEPROC condition, so the dependency on
REMOTEPROC is implicit and they do not need an explicit 'depends
on REMOTEPROC' line. So, clean these up.
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
A dependency to VIRTUALIZATION has been added to REMOTEPROC in v3.10
kernel in commit b9777859ec ("remoteproc: fix kconfig dependencies
for VIRTIO") to resolve Kconfig warnings due to the inclusion of the
virtio configuration file from the ARM's KVM config file. The KVM
config was fixed properly in the subsequent release in commit
8bd4ffd6b3 ("ARM: kvm: don't include drivers/virtio/Kconfig").
So, drop this unneeded VIRTUALIZATION dependency from REMOTEPROC.
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
A dependency to VIRTUALIZATION has been added to RPMSG_VIRTIO (back
when it was named RPMSG) in v3.10 kernel in commit 397944df32
("rpmsg: fix kconfig dependencies for VIRTIO") to resolve Kconfig
warnings due to the inclusion of the virtio configuration file from
the ARM's KVM config file. The KVM config was fixed properly in the
subsequent release in commit 8bd4ffd6b3 ("ARM: kvm: don't include
drivers/virtio/Kconfig"). So, drop this unneeded VIRTUALIZATION
dependency from RPMSG_VIRTIO.
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
File size before:
text data bss dec hex filename
3890 1152 8 5050 13ba drivers/base/power/sysfs.o
File size After adding 'const':
text data bss dec hex filename
4250 800 8 5058 13c2 drivers/base/power/sysfs.o
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Fixes wrong bits shift operation in the rapl_write_data_raw function, which
might cause overridding bits outside of the mask.
For example, writing new TIME_WINDOW1 value can override POWER_LIMIT1.
Signed-off-by: Adam Lessnau <adam.lessnau@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Local instances of struct attribute_group are not modified so they can
be made const to increase code safeness.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The 'info' string appearing in many places points to a .rodata string so
it should be passes as pointer to const.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The pm_verb() returns a pointer to string from .rodata so it should be
marked as const.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Mark pointer to struct generic_pm_domain const (either passed in
argument or used localy in a function), whenever it is not modifed by
the function itself.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
- Changes in Kconfig to enable I2C_DESIGNWARE_SLAVE support
- Slave functions added to core library file
- Slave abort sources added to common source file
- New driver: i2c-designware-slave added
- Changes in the Makefile to compile the I2C_DESIGNWARE_SLAVE module
when supported by the architecture.
All the SLAVE flow is added but it is not enabled via platform
driver.
Signed-off-by: Luis Oliveira <lolivei@synopsys.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
[wsa: made a function static and one-lined a message]
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
0-DAY kernel test reports the following build issue on IA64 architecture
with allmodconfig.
drivers/i2c/busses/i2c-zx2967.c: In function 'zx2967_i2c_writesb':
>> drivers/i2c/busses/i2c-zx2967.c:87:2: error: implicit declaration of function 'writesb' [-Werror=implicit-function-declaration]
writesb(i2c->reg_base + reg, data, len);
^~~~~~~
drivers/i2c/busses/i2c-zx2967.c: In function 'zx2967_i2c_readsb':
>> drivers/i2c/busses/i2c-zx2967.c:93:2: error: implicit declaration of function 'readsb' [-Werror=implicit-function-declaration]
readsb(i2c->reg_base + reg, data, len);
^~~~~~
cc1: some warnings being treated as errors
It's caused by that writesb/readsb are unavailable on IA64 architecture.
Let's drop COMPILE_TEST dependency to avoid the build issue.
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Let's always use the platform device for dev_* and not sometimes the
adapter device as well. Also fix this checkpatch check:
CHECK: Macro argument 'i2c' may be better as '(i2c)' to avoid precedence issues
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Acked-by: Shawn Guo <shawnguo@kernel.org>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
The struct layout randomization plugin detects and randomizes any structs
that contain only function pointers. Once layout is randomized, all
initialization must be designated or the compiler will misalign the
assignments. This switches all the ACPICA function pointer struct to
use designated initializers, using the proposed upstream ACPICA macro:
https://github.com/acpica/acpica/pull/248/
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPICA commit 117be4819588df3b7146f6f01723639b1d61e775
By doing so, external control method resolutions can be resolved like
normal control methods. This eliminates the need to reparse the aml
all over again for external control methods that were encoded within
the aml with the 0x15 bytecode.
Link: https://github.com/acpica/acpica/commit/117be481
Signed-off-by: Erik Schmauss <erik.schmauss@intel.com>
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPICA commit c512c2bfcce65b8e8f37d549ac2fa4a1e0182e46
Since Externals could be of ACPI_TYPE_METHOD, there is a possibility
that the acpi_ns_lookup may cause a new scope to be opened. Therefore,
disable opening the scope for all acpi_ns_lookup invocations that deal
with externals.
Link: https://github.com/acpica/acpica/commit/c512c2bf
Signed-off-by: Erik Schmauss <erik.schmauss@intel.com>
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Switch to using the devm_ APIs and remove the now unnecessary error
handling and most of the device removal code.
Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
[wsa: adapted error handling I added in previous patch]
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
The 35h instruction op code has two aliases/macro definitions:
- SPINOR_OP_RDCR from include/linux/mtd/spi-nor.h
- SPINOR_OP_RDSR2 from drivers/mtd/devices/serial_flash_cmds.h
Actually, some manufacturers name the associated internal register Status
Register 2 whereas other manufacturers name it Configuration Register
hence the two different macros for the very same instruction op code.
Since the spi-nor.h file is the reference file for all SPI NOR instruction
op codes, this patch removes the definition of the SPINOR_OP_RDSR2 macro.
Also the SPINOR_OP_RDSR2 macro will be associated to another instruction
op code in a further patch so we need to avoid a conflict defining this
macro twice. Indeed the JESD216 rev B specification, defining the SFDP
tables, also refers to the 3Eh and 3Fh instruction op codes to write/read
the Status Register 2 on some SPI NOR flash memories, the 35h op code
still being used to read the Configuration Register/Status Register 2 on
other memories.
Signed-off-by: Cyrille Pitchen <cyrille.pitchen@microchip.com>
Acked-by: Marek Vasut <marek.vasut@gmail.com>
Jakub Kicinski says:
====================
nfp: get_phys_port_name for representors and SR-IOV reorder
This series starts by making the error message if FW cannot be located
easier to understand. Then I move some functions from PCI probe files
into library code (nfpcore) where they belong, and remove one function
which is never used.
Next few patches equip representors with nfp_port structure and make
their NDOs fully shared (not defined in apps), thanks to which we can
easily determine which netdevs are NFP's by comparing the NDO pointers.
10th patch makes use of the shared NDOs and nfp_ports to deliver
netdev-type independent .ndo_get_phys_port_name() implementation.
Patches 11 and 12 reorder the nfp_app SR-IOV callbacks with enabling
SR-IOV VFs. Unfortunately due to how PCI subsystem works we can't
guarantee being able to disable SR-IOV at exit or that it will be
disabled when we first probe... We must therefore make sure FW is
able to deal with being loaded while SR-IOV is already on.
Patch 13 fixes potential deadlock when enabling SR-IOV happens at
the same time as port state refresh. Note that this can't happen
at this point, since Flower doesn't refresh ports... but lockdep
doesn't know about such details and we will have to deal with this
sooner or later anyway.
Last but not least a new Kconfig is added to make sure those who
don't care about flower offloads have a way of not including the
code in their kernels. Thanks to nfp_app separation this costs us
a single ifdef and excluding flower files from the build.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Since we grab pf->lock around pci_enable_sriov() we can no longer
safely queue work which may also grab that lock onto system workqueue.
pci_enable_sriov() will flush system workqueue as part to wait for VF
probing.
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Reviewed-by: Simon Horman <simon.horman@netronome.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
