If device is set up as a wakeup source, I2C core configures the interrupt
line as wake IRQ and PM core automatically configures it for waking up the
system on system suspend transition, so we do not have to explicitly call
enable_irq_wake() and disable_irq_wake() in suspend/resume.
Link: https://lore.kernel.org/r/20201120073920.3214492-2-dmitry.torokhov@gmail.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
We should not be configuring the controller as a wakeup source in the
driver, but rather rely on I2C core to mark it as such by either
instantiating as I2C_CLIENT_WAKEUP or specifying "wakeup-source" device
property.
Link: https://lore.kernel.org/r/20201120073920.3214492-1-dmitry.torokhov@gmail.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
For SEV, all DMA to and from guest has to use shared (un-encrypted) pages.
SEV uses SWIOTLB to make this happen without requiring changes to device
drivers. However, depending on the workload being run, the default 64MB
of it might not be enough and it may run out of buffers to use for DMA,
resulting in I/O errors and/or performance degradation for high
I/O workloads.
Adjust the default size of SWIOTLB for SEV guests using a
percentage of the total memory available to guest for the SWIOTLB buffers.
Adds a new sev_setup_arch() function which is invoked from setup_arch()
and it calls into a new swiotlb generic code function swiotlb_adjust_size()
to do the SWIOTLB buffer adjustment.
v5 fixed build errors and warnings as
Reported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Ashish Kalra <ashish.kalra@amd.com>
Co-developed-by: Borislav Petkov <bp@suse.de>
Signed-off-by: Borislav Petkov <bp@suse.de>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
As part of adding STRICT_DEVMEM support to the RISC-V port, Zong provided an
implementation of devmem_is_allowed() that's exactly the same as the version in
a handful of other ports. Rather than duplicate code, I've put a generic
version of this in lib/ and used it for the RISC-V port.
* palmer/generic-devmem:
arm64: Use the generic devmem_is_allowed()
arm: Use the generic devmem_is_allowed()
RISC-V: Use the new generic devmem_is_allowed()
lib: Add a generic version of devmem_is_allowed()
I recently copied this into lib/ for use by the RISC-V port.
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Reviewed-by: Luis Chamberlain <mcgrof@kernel.org>
Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
This is exactly the same as the arm64 version, which I recently copied
into lib/ for use by the RISC-V port.
Reviewed-by: Luis Chamberlain <mcgrof@kernel.org>
Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
As part of adding support for STRICT_DEVMEM to the RISC-V port, Zong
provided a devmem_is_allowed() implementation that's exactly the same as
all the others I checked. Instead I'm adding a generic version, which
will soon be used.
Reviewed-by: Luis Chamberlain <mcgrof@kernel.org>
Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
There is no need to get queue number repeatly for different queues from an
AEQE entity, as they are the same. Furthermore, redefine the AEQE
structure to make the codes more readable.
In addition, HNS_ROCE_EVENT_TYPE_CEQ_OVERFLOW is removed because the
hardware never reports this event.
Link: https://lore.kernel.org/r/1607650657-35992-12-git-send-email-liweihang@huawei.com
Signed-off-by: Yixian Liu <liuyixian@huawei.com>
Signed-off-by: Wenpeng Liang <liangwenpeng@huawei.com>
Signed-off-by: Weihang Li <liweihang@huawei.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Some %d in print format string should be %u, and some prints miss the
useful errno or are in nonstandard format. Just fix above issues.
Link: https://lore.kernel.org/r/1607650657-35992-11-git-send-email-liweihang@huawei.com
Signed-off-by: Yixing Liu <liuyixing1@huawei.com>
Signed-off-by: Weihang Li <liweihang@huawei.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Types of some fields, variables and parameters of some functions should be
unsigned.
Link: https://lore.kernel.org/r/1607650657-35992-10-git-send-email-liweihang@huawei.com
Signed-off-by: Wenpeng Liang <liangwenpeng@huawei.com>
Signed-off-by: Weihang Li <liweihang@huawei.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
There is no need to initialize some variable because they will be assigned
with a value later.
Link: https://lore.kernel.org/r/1607650657-35992-9-git-send-email-liweihang@huawei.com
Signed-off-by: Xinhao Liu <liuxinhao5@hisilicon.com>
Signed-off-by: Weihang Li <liweihang@huawei.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Just format the code without modifying anything, including fixing some
redundant and missing blanks and spaces and changing the variable
definition order.
Link: https://lore.kernel.org/r/1607650657-35992-8-git-send-email-liweihang@huawei.com
Signed-off-by: Lang Cheng <chenglang@huawei.com>
Signed-off-by: Weihang Li <liweihang@huawei.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
As the qp access right is checked and setted in common function
hns_roce_v2_set_opt_fields(), there is no need to set again for a special
case INIT2INIT.
Fixes: 926a01dc00 ("RDMA/hns: Add QP operations support for hip08 SoC")
Fixes: 7db82697b8 ("RDMA/hns: Add support for extended atomic in userspace")
Link: https://lore.kernel.org/r/1607650657-35992-7-git-send-email-liweihang@huawei.com
Signed-off-by: Yixian Liu <liuyixian@huawei.com>
Signed-off-by: Weihang Li <liweihang@huawei.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
According to the RoCE v1 specification, the sl (service level) 0-7 are
mapped directly to priorities 0-7 respectively, sl 8-15 are reserved. The
driver should verify whether the value of sl is larger than 7, if so, an
exception should be returned.
Link: https://lore.kernel.org/r/1607650657-35992-6-git-send-email-liweihang@huawei.com
Signed-off-by: Weihang Li <liweihang@huawei.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Only the low 12 bits of vlan_id is valid, and service level has been
filled in Address Vector. So there is no need to fill sl in vlan_id in
Address Vector.
Fixes: 7406c0036f ("RDMA/hns: Only record vlan info for HIP08")
Link: https://lore.kernel.org/r/1607650657-35992-5-git-send-email-liweihang@huawei.com
Signed-off-by: Weihang Li <liweihang@huawei.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
The high 6 bits of traffic class in GRH is DSCP (Differentiated Services
Codepoint), the driver should shift it before the hardware gets it when
using RoCEv2.
Fixes: 606bf89e98 ("RDMA/hns: Refactor for hns_roce_v2_modify_qp function")
Fixes: fba429fcf9 ("RDMA/hns: Fix missing fields in address vector")
Link: https://lore.kernel.org/r/1607650657-35992-4-git-send-email-liweihang@huawei.com
Signed-off-by: Weihang Li <liweihang@huawei.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Whether to enable the these features should better depend on the enable
flags, not the value of related fields.
Fixes: 5c1f167af1 ("RDMA/hns: Init SRQ table for hip08")
Fixes: 3cb2c996c9 ("RDMA/hns: Add support for SCCC in size of 64 Bytes")
Link: https://lore.kernel.org/r/1607650657-35992-3-git-send-email-liweihang@huawei.com
Signed-off-by: Wenpeng Liang <liangwenpeng@huawei.com>
Signed-off-by: Weihang Li <liweihang@huawei.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
For ib_copy_from_user(), the length of udata may not be the same as that
of cmd. For ib_copy_to_user(), the length of udata may not be the same as
that of resp. So limit the length to prevent out-of-bounds read and write
operations from ib_copy_from_user() and ib_copy_to_user().
Fixes: de77503a59 ("RDMA/hns: RDMA/hns: Assign rq head pointer when enable rq record db")
Fixes: 633fb4d9fd ("RDMA/hns: Use structs to describe the uABI instead of opencoding")
Fixes: ae85bf92ef ("RDMA/hns: Optimize qp param setup flow")
Fixes: 6fd610c573 ("RDMA/hns: Support 0 hop addressing for SRQ buffer")
Fixes: 9d9d4ff788 ("RDMA/hns: Update the kernel header file of hns")
Link: https://lore.kernel.org/r/1607650657-35992-2-git-send-email-liweihang@huawei.com
Signed-off-by: Wenpeng Liang <liangwenpeng@huawei.com>
Signed-off-by: Weihang Li <liweihang@huawei.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Originally, commit d7157ff49a ("mtd: rawnand: Use the ECC framework
user input parsing bits") kind of broke the logic around the
initialization of several ECC engines.
Unfortunately, the fix (which indeed moved the ECC initialization to
the right place) did not take into account the fact that a different
ECC algorithm could have been used thanks to a DT property,
considering the "Hamming" algorithm entry a configuration while it was
only a default.
Add the necessary logic to be sure Hamming keeps being only a default.
Fixes: d525914b5b ("mtd: rawnand: xway: Move the ECC initialization to ->attach_chip()")
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20201203190340.15522-10-miquel.raynal@bootlin.com
Originally, commit d7157ff49a ("mtd: rawnand: Use the ECC framework
user input parsing bits") kind of broke the logic around the
initialization of several ECC engines.
Unfortunately, the fix (which indeed moved the ECC initialization to
the right place) did not take into account the fact that a different
ECC algorithm could have been used thanks to a DT property,
considering the "Hamming" algorithm entry a configuration while it was
only a default.
Add the necessary logic to be sure Hamming keeps being only a default.
Fixes: b36bf0a0fe ("mtd: rawnand: socrates: Move the ECC initialization to ->attach_chip()")
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20201203190340.15522-9-miquel.raynal@bootlin.com
Originally, commit d7157ff49a ("mtd: rawnand: Use the ECC framework
user input parsing bits") kind of broke the logic around the
initialization of several ECC engines.
Unfortunately, the fix (which indeed moved the ECC initialization to
the right place) did not take into account the fact that a different
ECC algorithm could have been used thanks to a DT property,
considering the "Hamming" algorithm entry a configuration while it was
only a default.
Add the necessary logic to be sure Hamming keeps being only a default.
Fixes: 612e048e6a ("mtd: rawnand: plat_nand: Move the ECC initialization to ->attach_chip()")
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20201203190340.15522-8-miquel.raynal@bootlin.com
Originally, commit d7157ff49a ("mtd: rawnand: Use the ECC framework
user input parsing bits") kind of broke the logic around the
initialization of several ECC engines.
Unfortunately, the fix (which indeed moved the ECC initialization to
the right place) did not take into account the fact that a different
ECC algorithm could have been used thanks to a DT property,
considering the "Hamming" algorithm entry a configuration while it was
only a default.
Add the necessary logic to be sure Hamming keeps being only a default.
Fixes: 8fc6f1f042 ("mtd: rawnand: pasemi: Move the ECC initialization to ->attach_chip()")
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20201203190340.15522-7-miquel.raynal@bootlin.com
Originally, commit d7157ff49a ("mtd: rawnand: Use the ECC framework
user input parsing bits") kind of broke the logic around the
initialization of several ECC engines.
Unfortunately, the fix (which indeed moved the ECC initialization to
the right place) did not take into account the fact that a different
ECC algorithm could have been used thanks to a DT property,
considering the "Hamming" algorithm entry a configuration while it was
only a default.
Add the necessary logic to be sure Hamming keeps being only a default.
Reported-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
Fixes: 553508cec2 ("mtd: rawnand: orion: Move the ECC initialization to ->attach_chip()")
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Tested-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
Link: https://lore.kernel.org/linux-mtd/20201203190340.15522-6-miquel.raynal@bootlin.com
Originally, commit d7157ff49a ("mtd: rawnand: Use the ECC framework
user input parsing bits") kind of broke the logic around the
initialization of several ECC engines.
Unfortunately, the fix (which indeed moved the ECC initialization to
the right place) did not take into account the fact that a different
ECC algorithm could have been used thanks to a DT property,
considering the "Hamming" algorithm entry a configuration while it was
only a default.
Add the necessary logic to be sure Hamming keeps being only a default.
Fixes: 6dd09f775b ("mtd: rawnand: mpc5121: Move the ECC initialization to ->attach_chip()")
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20201203190340.15522-5-miquel.raynal@bootlin.com
Originally, commit d7157ff49a ("mtd: rawnand: Use the ECC framework
user input parsing bits") kind of broke the logic around the
initialization of several ECC engines.
Unfortunately, the fix (which indeed moved the ECC initialization to
the right place) did not take into account the fact that a different
ECC algorithm could have been used thanks to a DT property,
considering the "Hamming" algorithm entry a configuration while it was
only a default.
Add the necessary logic to be sure Hamming keeps being only a default.
Fixes: f6341f6448 ("mtd: rawnand: gpio: Move the ECC initialization to ->attach_chip()")
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20201203190340.15522-4-miquel.raynal@bootlin.com
Originally, commit d7157ff49a ("mtd: rawnand: Use the ECC framework
user input parsing bits") kind of broke the logic around the
initialization of several ECC engines.
Unfortunately, the fix (which indeed moved the ECC initialization to
the right place) did not take into account the fact that a different
ECC algorithm could have been used thanks to a DT property,
considering the "Hamming" algorithm entry a configuration while it was
only a default.
Add the necessary logic to be sure Hamming keeps being only a default.
Fixes: dbffc8ccdf ("mtd: rawnand: au1550: Move the ECC initialization to ->attach_chip()")
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20201203190340.15522-3-miquel.raynal@bootlin.com
Originally, commit d7157ff49a ("mtd: rawnand: Use the ECC framework
user input parsing bits") kind of broke the logic around the
initialization of several ECC engines.
Unfortunately, the fix (which indeed moved the ECC initialization to
the right place) did not take into account the fact that a different
ECC algorithm could have been used thanks to a DT property,
considering the "Hamming" algorithm entry a configuration while it was
only a default.
Add the necessary logic to be sure Hamming keeps being only a default.
Fixes: 59d9347332 ("mtd: rawnand: ams-delta: Move the ECC initialization to ->attach_chip()")
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20201203190340.15522-2-miquel.raynal@bootlin.com
Make cpufreq_online() return negative error codes on all errors that
cause the policy to be destroyed, as appropriate.
Signed-off-by: Wang ShaoBo <bobo.shaobowang@huawei.com>
[ rjw: Subject and changelog edits ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Fix up the remaining kerneldoc comments that don't adhere to the
expected format and clarify some of them a bit.
No functional changes.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
local_clock() has better precision and accuracy as compared to jiffies,
lets use it for time management in cpufreq stats.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Rearrange a conditional to make it more straightforward.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Avoid doing the same assignment in both branches of a conditional,
do it after the whole conditional instead.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Commit
57d563c829 ("x86: ia32_setup_rt_frame(): consolidate uaccess areas")
dropped a __user annotation in a cast when refactoring __put_user() to
unsafe_put_user().
Hence, since then, sparse warns in arch/x86/ia32/ia32_signal.c:350:9:
warning: cast removes address space '__user' of expression
warning: incorrect type in argument 1 (different address spaces)
expected void const volatile [noderef] __user *ptr
got unsigned long long [usertype] *
Add the __user annotation to restore the propagation of address spaces.
Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Link: https://lkml.kernel.org/r/20201207124141.21859-1-lukas.bulwahn@gmail.com
Detailed description for this pull request:
1. Update devfreq core
- Add new devfreq_frequency tracepoint to show the frequency change
information.
- Add governor feature flag. The devfreq governor is able to
have the specific flag in order to contain the non-common feature.
For example, if governor contains the 'immutable' feature, don't allow
user to change the governor via sysfs.
- Add governor sysfs attribute flag for each sysfs file. Prior to that
devfreq subsystem show the all sysfs files regardless of governor type.
But, some sysfs fils are not supported on the specific devfreq governor.
In order to show the only supported sysfs files according to the governor,
clarify the access permission of sysfs attributes according to governor.
When adding the devfreq governor, can specify the available attribute
information by using DEVFREQ_GOV_ATTR_* constant variable. The user can
read or write the sysfs attributes in accordance to the specified attributes.
- Clean-up the code to remove the duplicate code for the devfreq tracepoint
and to remove redundant governor_name field from struct devfreq
2. Update exynos-bus.c devfreq driver
- Add interconnect API support for the Samsung Exynos Bus Frequency driver
of exynos-bus.c. Complementing the devfreq driver with an interconnect
functionality allows to ensure the QoS requirements of devices accessing
the system memory (e.g. video processing devices) are fulfilled
and allows to avoid issues like the DMA underrun.
3. Update tegra devfreq driver
- Add interconnect support and OPP interface for tegra30-devfreq.c.
Also, it is to guarantee the QoS requirement of some devices like
display controller.
- Move tegra20-devfreq.c from drivers/devfreq/ into driver/memory/tegra/
in order to use the more proper monitoring feature such as EMC_STAT
which is based in driver/memory/tegra/.
- Separate the configuration information for different SoC on
tegra30-devfrqe.c. The tegra30-devfreq.c had been supported both
tegra30-actmon and tegra124-actmon devices. In order to use
the more correct configuration data, separate them.
- Use dev_err_probe() to handle the deferred probe error on tegra30-devfreq.c.
4. Pull the request of 'Tegra SoC and clock controller changes for v5.11'
sent by Krzysztof Kozlowski <krzk@kernel.org> in order to prevent the
build error.
-----BEGIN PGP SIGNATURE-----
iQJKBAABCgA0FiEEsSpuqBtbWtRe4rLGnM3fLN7rz1MFAl/TI+UWHGN3MDAuY2hv
aUBzYW1zdW5nLmNvbQAKCRCczd8s3uvPU8M/EAClq1DatrIsc6eysfvUUYhZgGD4
QC3WrIQ858y9/rZT1If+uZeif6DonOSIYBetCa0Wo5kiuN3BvSCZEnAsndqRPjk1
NyvRbThXUCMrtlgah/rsVPRCgwS8UidTeCqhO1n2kvHlIINgyvqS8EVpDbrOjf8s
0MFAmsh/PK0bIQC53yHs24XhLm4ddk+K1Gw2xlyd+c2E/+6MGeKbtc1nfqSy337K
3GJe9IwC0JHQGC1tPi4wnA+/S+gK0/tP3RGPlF9fk+fnccWSDhIu6tQQh1hjaLwC
5hbjwavEcr67/E0/zkQs+Bm7mEHtHFERAOPKv3C4UzPCL5wg/Z6hVphaKb+hjFDE
kD2JRCyNHwSFemu78+ooef2Af745AH9OJ6Z1ADwTyyI6wPS0qUm0/m3Eu33kJdPb
f7v+DMkqEnzEGn6gMJ2/WAEXmGi7vjwp6W6bqf5Ft13te7K8OKK8jNiFcgDPXznN
7km9gG8/j/nS9J5s01VhxU9QmwD65RsKR8upBhIpkPoMktBoH7Q4P2Ab9XlZbliG
F0p1S6dnwxQI3BIP+BwkGVwgSINPd6bd7PyTCQJx2d3VqF5JVW3jEfXouWw6h8zO
pW+lgUBr8+M5K99UYj8wktROtt5kKQQ0yd85XBdIqSZWZJ2J/D71XxcDjvZdvF3L
4vAeDY224dRuy+PP7g==
=t1gj
-----END PGP SIGNATURE-----
Merge tag 'devfreq-next-for-5.11' of git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/linux
Pull devfreq updates for 5.11 from Chanwoo Choi:
1. Update devfreq core
- Add new devfreq_frequency tracepoint to show the frequency change
information.
- Add governor feature flag. The devfreq governor is able to set the
specific flag in order to support a non-common feature. For
example, if the governor supports the 'immutable' feature, don't
allow user space to change the governor via sysfs.
- Add governor sysfs attribute flag for each sysfs file. Prior to that
the devfreq subsystem allowed all of the sysfs files to be accessed
regardless of the governor type. But some sysfs fils are not
supported by specific devfreq governors. In order to only allow the
sysfs files supported by the governor to be accessed, clarify the
access permissions of sysfs attributes according to the governor.
When adding the devfreq governor, specify the available attribute
information by using DEVFREQ_GOV_ATTR_* symbols. The user can read
or write the sysfs attributes in accordance to the specified
access permissions.
- Clean-up the code to reduce duplication for the devfreq tracepoint
and to remove redundant governor_name field from struct devfreq.
2. Update exynos-bus.c devfreq driver
- Add interconnect API support to the Samsung Exynos Bus Frequency
driver, exynos-bus.c. Complementing the devfreq driver with
interconnect functionality allows to ensure that the QoS
requirements regarding devices accessing the system memory (e.g.
video processing devices) will be met and allows to avoid issues
like DMA underrun.
3. Update tegra devfreq driver
- Add interconnect support and OPP interface to tegra30-devfreq.c.
Also, it is to guarantee the QoS requirement of some devices like
the display controller.
- Move tegra20-devfreq.c from drivers/devfreq/ into drivers/memory/tegra/
in order to use the more proper monitoring feature such as EMC_STAT
which is located in drivers/memory/tegra/.
- Separate the configuration information for different SoCs in
tegra30-devfrqe.c. The tegra30-devfreq.c had been supporting both
tegra30-actmon and tegra124-actmon devices. In order to use the
more correct configuration data, separate them.
- Use dev_err_probe() to handle the deferred probe error in
tegra30-devfreq.c.
4. Pull the request of 'Tegra SoC and clock controller changes for
v5.11' sent by Krzysztof Kozlowski <krzk@kernel.org> in order to
avoid a build error."
* tag 'devfreq-next-for-5.11' of git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/linux:
PM / devfreq: tegra30: Separate configurations per-SoC generation
PM / devfreq: tegra30: Support interconnect and OPPs from device-tree
PM / devfreq: tegra20: Deprecate in a favor of emc-stat based driver
PM / devfreq: exynos-bus: Add registration of interconnect child device
dt-bindings: devfreq: Add documentation for the interconnect properties
soc/tegra: fuse: Add stub for tegra_sku_info
soc/tegra: fuse: Export tegra_read_ram_code()
clk: tegra: Export Tegra20 EMC kernel symbols
PM / devfreq: tegra30: Silence deferred probe error
PM / devfreq: tegra20: Relax Kconfig dependency
PM / devfreq: tegra20: Silence deferred probe error
PM / devfreq: Remove redundant governor_name from struct devfreq
PM / devfreq: Add governor attribute flag for specifc sysfs nodes
PM / devfreq: Add governor feature flag
PM / devfreq: Add tracepoint for frequency changes
PM / devfreq: Unify frequency change to devfreq_update_target func
trace: events: devfreq: Use fixed indentation size to improve readability
debugfs nodes were created in genpd_debug_init alled in late_initcall
preventing power domains registered though loadable modules to have
a debugfs entry.
Create/remove debugfs nodes when the power domain is added/removed
to/from the internal gpd_list.
Signed-off-by: Thierry Strudel <tstrudel@google.com>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Kernel test robot reported warning:
drivers/net/wireless/mediatek/mt76/tx.c: In function
'mt76_txq_schedule':
>> drivers/net/wireless/mediatek/mt76/tx.c:499:21: warning: variable 'q'
>> set but not used [-Wunused-but-set-variable]
499 | struct mt76_queue *q;
| ^
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Souptick Joarder <jrdr.linux@gmail.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/1607542617-4005-1-git-send-email-jrdr.linux@gmail.com
- Fix up some SPI group and a register offset on Intel Jasperlake.
- Set default bias on Intel Merrifield.
- Preserve debouncing on Intel Baytrail.
- Stop .set_type() irqchip callback in the AMD driver from fiddling
with the debounce filter.
- Fix access to GPIO banks that are pass-thru on the Aspeed.
- Fix a fix for the Intel pin control driver to disable Rx/Tx when
requesting a UART line as GPIO.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEElDRnuGcz/wPCXQWMQRCzN7AZXXMFAl/TMjIACgkQQRCzN7AZ
XXOagw//UOHZDJIIoTJiVSksz8yFNjvoidY/O2f419fM/UtF+Mtk4HcZoeVOL2z/
TtpH/wmdd6gzG17gCFGFsfzCGdaWOa9xQA8oiXtThkgiw+HyQPXCWqHnYeNNYPO+
c70VD3fYkGouqY6btQkCmN/koKu6PWuysjYwv3xpSmKZWVlVSDxx6asvZztcoy4T
Fc1q6PqsaM9ixqJI5tDb/CYAXngfyuG045maq/Hg3TCErx4DIxQcL6639vEzcU/4
DuU84cAtsS3Lw+Ke4pAfyfDLCVKTk+f40Ka/iQPZlnEnuDyXr6+xwoEZ0FMubFiQ
D9hNpT4oFJZU6pDRVBUFJ6mtvakP13qGc1rwv7YAmPBO27Umhgrdaw/GPOOcUiE1
Q7INiRFPIWWTmboKhv/oheRNkoDETqBGj0YpkT47RxOEG7GsxVQwmln1vXoWSKCY
t8HtG6pLrhZuibhSebhEF5qT1dm2Th/H99vCuBsb5Y1nkbAQCJbMPfHJTEvWGHj/
JfmIEt1T9JN3AT+hJdqfJuZSsdN6Lh+xECoS7pug/TQHipAs1Xz/dhhS/YrBSikN
rzcCZ148P5OxpakiVDb15gdOQChRMq3f9OYYV0I1G6hCV3I4k48BiqNsySgPfopH
Pt246bFN79O1SgrsBlFio+GhsgtrFE4cVmIrjTJ1KopMhITA0k0=
=QTVd
-----END PGP SIGNATURE-----
Merge tag 'pinctrl-v5.10-3' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl
Pull pin control fixes from Linus Walleij:
"Here is a late set of pin control fixes for v5.10, most concern some
minor and major issues found in the Intel drivers. Some are so hairy
that I have no idea what is going on there, but luckily the maintainer
knows what's up.
We also have an interesting fix for AMD, which makes AMD-based laptops
more stable IIUC.
Summary:
- Fix up some SPI group and a register offset on Intel Jasperlake
- Set default bias on Intel Merrifield
- Preserve debouncing on Intel Baytrail
- Stop .set_type() irqchip callback in the AMD driver from fiddling
with the debounce filter
- Fix access to GPIO banks that are pass-thru on the Aspeed
- Fix a fix for the Intel pin control driver to disable Rx/Tx when
requesting a UART line as GPIO"
* tag 'pinctrl-v5.10-3' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl:
pinctrl: intel: Actually disable Tx and Rx buffers on GPIO request
pinctrl: aspeed: Fix GPIO requests on pass-through banks
pinctrl: amd: remove debounce filter setting in IRQ type setting
pinctrl: baytrail: Avoid clearing debounce value when turning it off
pinctrl: merrifield: Set default bias in case no particular value given
pinctrl: jasperlake: Fix HOSTSW_OWN offset
pinctrl: jasperlake: Unhide SPI group of pins
Fixes the following W=1 kernel build warning(s):
drivers/net/wireless/intel/iwlwifi/fw/acpi.c:123: warning: Function parameter or member 'dev' not described in 'iwl_acpi_get_dsm_object'
drivers/net/wireless/intel/iwlwifi/fw/acpi.c:123: warning: Function parameter or member 'rev' not described in 'iwl_acpi_get_dsm_object'
drivers/net/wireless/intel/iwlwifi/fw/acpi.c:123: warning: Function parameter or member 'func' not described in 'iwl_acpi_get_dsm_object'
drivers/net/wireless/intel/iwlwifi/fw/acpi.c:123: warning: Function parameter or member 'args' not described in 'iwl_acpi_get_dsm_object'
drivers/net/wireless/intel/iwlwifi/fw/acpi.c:142: warning: Function parameter or member 'dev' not described in 'iwl_acpi_get_dsm_u8'
drivers/net/wireless/intel/iwlwifi/fw/acpi.c:142: warning: Function parameter or member 'rev' not described in 'iwl_acpi_get_dsm_u8'
drivers/net/wireless/intel/iwlwifi/fw/acpi.c:142: warning: Function parameter or member 'func' not described in 'iwl_acpi_get_dsm_u8'
Cc: Johannes Berg <johannes.berg@intel.com>
Cc: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Cc: Luca Coelho <luciano.coelho@intel.com>
Cc: Intel Linux Wireless <linuxwifi@intel.com>
Cc: Kalle Valo <kvalo@codeaurora.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Jakub Kicinski <kuba@kernel.org>
Cc: linux-wireless@vger.kernel.org
Cc: netdev@vger.kernel.org
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20201126133152.3211309-17-lee.jones@linaro.org
Fixes the following W=1 kernel build warning(s):
drivers/net/wireless/intel/iwlwifi/fw/dbg.c:1932: warning: Function parameter or member 'reg_data' not described in 'iwl_dump_ini_mem'
drivers/net/wireless/intel/iwlwifi/fw/dbg.c:1932: warning: Excess function parameter 'reg' description in 'iwl_dump_ini_mem'
Cc: Johannes Berg <johannes.berg@intel.com>
Cc: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Cc: Luca Coelho <luciano.coelho@intel.com>
Cc: Intel Linux Wireless <linuxwifi@intel.com>
Cc: Kalle Valo <kvalo@codeaurora.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Jakub Kicinski <kuba@kernel.org>
Cc: Shahar S Matityahu <shahar.s.matityahu@intel.com>
Cc: linux-wireless@vger.kernel.org
Cc: netdev@vger.kernel.org
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20201126133152.3211309-15-lee.jones@linaro.org
Fixes the following W=1 kernel build warning(s):
drivers/net/wireless/intel/iwlwifi/iwl-phy-db.c:97: warning: Function parameter or member 'trans' not described in 'iwl_phy_db'
Cc: Johannes Berg <johannes.berg@intel.com>
Cc: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Cc: Luca Coelho <luciano.coelho@intel.com>
Cc: Intel Linux Wireless <linuxwifi@intel.com>
Cc: Kalle Valo <kvalo@codeaurora.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Jakub Kicinski <kuba@kernel.org>
Cc: linux-wireless@vger.kernel.org
Cc: netdev@vger.kernel.org
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20201126133152.3211309-14-lee.jones@linaro.org
Fixes the following W=1 kernel build warning(s):
drivers/net/wireless/intel/iwlwifi/iwl-eeprom-parse.c:340: warning: cannot understand function prototype: 'struct iwl_eeprom_enhanced_txpwr '
Cc: Johannes Berg <johannes.berg@intel.com>
Cc: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Cc: Luca Coelho <luciano.coelho@intel.com>
Cc: Intel Linux Wireless <linuxwifi@intel.com>
Cc: Kalle Valo <kvalo@codeaurora.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Jakub Kicinski <kuba@kernel.org>
Cc: linux-wireless@vger.kernel.org
Cc: netdev@vger.kernel.org
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20201126133152.3211309-9-lee.jones@linaro.org
Fixes the following W=1 kernel build warning(s):
drivers/net/wireless/intel/iwlwifi/iwl-eeprom-read.c:347: warning: Function parameter or member 'trans' not described in 'iwl_read_eeprom'
drivers/net/wireless/intel/iwlwifi/iwl-eeprom-read.c:347: warning: Function parameter or member 'eeprom' not described in 'iwl_read_eeprom'
drivers/net/wireless/intel/iwlwifi/iwl-eeprom-read.c:347: warning: Function parameter or member 'eeprom_size' not described in 'iwl_read_eeprom'
Cc: Johannes Berg <johannes.berg@intel.com>
Cc: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Cc: Luca Coelho <luciano.coelho@intel.com>
Cc: Intel Linux Wireless <linuxwifi@intel.com>
Cc: Kalle Valo <kvalo@codeaurora.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Jakub Kicinski <kuba@kernel.org>
Cc: linux-wireless@vger.kernel.org
Cc: netdev@vger.kernel.org
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20201126133152.3211309-8-lee.jones@linaro.org
Also add documentation for 'mvm'.
Fixes the following W=1 kernel build warning(s):
drivers/net/wireless/intel/iwlwifi/mvm/rs.c:400: warning: cannot understand function prototype: 'const u16 expected_tpt_legacy[IWL_RATE_COUNT] = '
drivers/net/wireless/intel/iwlwifi/mvm/rs.c:684: warning: Function parameter or member 'mvm' not described in '_rs_collect_tx_data'
drivers/net/wireless/intel/iwlwifi/mvm/rs.c:684: warning: Function parameter or member 'tbl' not described in '_rs_collect_tx_data'
drivers/net/wireless/intel/iwlwifi/mvm/rs.c:684: warning: Function parameter or member 'scale_index' not described in '_rs_collect_tx_data'
drivers/net/wireless/intel/iwlwifi/mvm/rs.c:684: warning: Function parameter or member 'attempts' not described in '_rs_collect_tx_data'
drivers/net/wireless/intel/iwlwifi/mvm/rs.c:684: warning: Function parameter or member 'successes' not described in '_rs_collect_tx_data'
drivers/net/wireless/intel/iwlwifi/mvm/rs.c:684: warning: Function parameter or member 'window' not described in '_rs_collect_tx_data'
drivers/net/wireless/intel/iwlwifi/mvm/rs.c:2677: warning: duplicate section name 'NOTE'
drivers/net/wireless/intel/iwlwifi/mvm/rs.c:2682: warning: Function parameter or member 'mvm' not described in 'rs_initialize_lq'
drivers/net/wireless/intel/iwlwifi/mvm/rs.c:2682: warning: Function parameter or member 'sta' not described in 'rs_initialize_lq'
drivers/net/wireless/intel/iwlwifi/mvm/rs.c:2682: warning: Function parameter or member 'lq_sta' not described in 'rs_initialize_lq'
drivers/net/wireless/intel/iwlwifi/mvm/rs.c:2682: warning: Function parameter or member 'band' not described in 'rs_initialize_lq'
drivers/net/wireless/intel/iwlwifi/mvm/rs.c:3761: warning: Function parameter or member 'mvm' not described in 'rs_program_fix_rate'
drivers/net/wireless/intel/iwlwifi/mvm/rs.c:3761: warning: Function parameter or member 'lq_sta' not described in 'rs_program_fix_rate'
drivers/net/wireless/intel/iwlwifi/mvm/rs.c:4213: warning: Function parameter or member 'mvm' not described in 'iwl_mvm_tx_protection'
Cc: Johannes Berg <johannes.berg@intel.com>
Cc: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Cc: Luca Coelho <luciano.coelho@intel.com>
Cc: Intel Linux Wireless <linuxwifi@intel.com>
Cc: Kalle Valo <kvalo@codeaurora.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Jakub Kicinski <kuba@kernel.org>
Cc: linux-wireless@vger.kernel.org
Cc: netdev@vger.kernel.org
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20201126133152.3211309-3-lee.jones@linaro.org
- Fix runtime PM balancing on the errorpath of the Arizona driver.
- Fix a suspend NULL pointer reference in the dwapb driver.
- Balance free:ing in gpiochip_generic_free()
- Fix runtime PM balancing on the errorpath of the zynq driver.
- Fix irqdomain use-after-free in the mvebu driver.
- Break an eternal loop in the spreadtrum EIC driver.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEElDRnuGcz/wPCXQWMQRCzN7AZXXMFAl/TLq8ACgkQQRCzN7AZ
XXOUMg//aCi2slJSSYmIcg8NKKUpj2UL2n4JUTdOu/PzWUXc9c427mAlJkWexr/s
h5FTPqv8+AoUpJunxct6bsOmaaXrpAfzfLzgUl0NK+3WZ9B+rAnBM5E3g1RY2+bh
08k4vx0nAoSsi25OgQaWz64soK83/Gqx5VHaGQJDI5RaCVWyagLMgciSt2ZXZf02
gC31q8kVG/+Jv7o1RQF2ET81kW2R/C6LDq6c7PtHH9DKatIJc0/yEQu/lRAOPD9J
u72enRyW42Pd6TWP/TccsyiYBp9j6ijgPsnPp4EcoiJjiDuJm2PvDlr+q7iirhyg
Ore8+n9ezR8B1C9g6k/TcCEcc6Ojh4+UQTCpexJfjIOenr8s+gRZyNcrFONzpUyq
Kg71JwRKazn0cU8UQyL557x84DFgG/gWQt29+t21UtkCgRNVmDuFCAukZAS3Eox0
l4om2IidfRhl7Sdln4ipXp9GXR4UQL7L1sKz2DEAboXjo1+tsQVNXaKSU7dQQIcD
n7SN8Bl8fKr1a+FJ/UCtcBJrilasspZc3ZV/jExzKVa6saZPGGy2E6dMk6kmAaCv
MckZxaqmyo90EvBUBT+soqmK4d4kusUg8Ac5ZzsOWi2meLYzCvc87rl3M8nj5rdY
F1kuhpkgmmO1ympfxsvTC5RPG8B+yNtFcmVyjFWZYwioUGIQXL8=
=w5eY
-----END PGP SIGNATURE-----
Merge tag 'v5.10-3' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio
Pull GPIO fixes from Linus Walleij:
"These are hopefully the last GPIO fixes for this cycle.
All are driver fixes except a small resource leak for pin ranges in
the gpiolib. Two are PM related, which is nice because when developers
start to find PM bugs it is usually because they have smoked out the
bugs of more severe nature.
Summary:
- Fix runtime PM balancing on the errorpath of the Arizona driver
- Fix a suspend NULL pointer reference in the dwapb driver
- Balance free:ing in gpiochip_generic_free()
- Fix runtime PM balancing on the errorpath of the zynq driver
- Fix irqdomain use-after-free in the mvebu driver
- Break an eternal loop in the spreadtrum EIC driver"
* tag 'v5.10-3' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio:
gpio: eic-sprd: break loop when getting NULL device resource
gpio: mvebu: fix potential user-after-free on probe
gpio: zynq: fix reference leak in zynq_gpio functions
gpiolib: Don't free if pin ranges are not defined
gpio: dwapb: fix NULL pointer dereference at dwapb_gpio_suspend()
gpio: arizona: disable pm_runtime in case of failure
In preparation to enable -Wimplicit-fallthrough for Clang, fix a
warning by replacing a /* fall through */ comment with the new
pseudo-keyword macro fallthrough; instead of letting the code fall
through to the next case.
Notice that Clang doesn't recognize /* fall through */ comments as
implicit fall-through markings.
Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/edd98d194bfc98b4be93a9bdc303630b719c0e66.1605896060.git.gustavoars@kernel.org
