| Age | Commit message (Collapse) | Author | Files | Lines |
|
Just to make this more clear to outside contributors that these are
DC-specific structs, as this also threw me into a loop a number of times
before I figured out the purpose of this.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Cc: Wayne Lin <Wayne.Lin@amd.com>
Cc: Fangzhi Zuo <Jerry.Zuo@amd.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220817193847.557945-2-lyude@redhat.com
|
|
Pull parisc fixes from Helge Deller:
"Some interesting background to the current patchset:
It turned out that the fldw instruction (which loads a 32-bit word
from memory into one half of a FP register) failed on unaligned
addresses and even trashed some other random FP register instead. It's
a trivial one-liner fix in the exception handler but this failure
dates back to the very beginnings of the parisc-port. It's strange
that it was never noticed before.
Another patch fixes an annoyance noticed by Randy Dunlap. Running
"make ARCH=parisc64 randconfig" always returned a 32-bit config,
although one would expect a 64-bit config. Masahiro Yamada suggested
to mimik sparc Kconfig code, which fixed the issue nicely. This
allowed to drop some compiler build checks too.
Third, it's possible to build an optimized 32-bit kernel for PA8X00
(64-bit) CPUs, which then wouldn't start on 32-bit-only (PA1.x)
machines. I've added a bootup check which prevents that and which
prints a message to the console. This can be tested with qemu, which
currently only supports 32-bit emulation.
The other patches are usual clean-up stuff like added return value
checks and typo fixes in comments.
Summary:
- Fix emulation of fldw instruction on unaligned addresses
- Fix "make ARCH=parisc64 randconfig" to return a 64-bit config
- Prevent boot if trying to boot a 32-bit kernel compiled for PA8X00
CPUs on 32-bit only machines
- ccio-dma: Handle kmalloc failure in ccio_init_resources()"
* tag 'parisc-for-6.0-2' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux:
parisc: Add runtime check to prevent PA2.0 kernels on PA1.x machines
parisc: ccio-dma: Handle kmalloc failure in ccio_init_resources()
parisc: led: Move from strlcpy with unused retval to strscpy
parisc: ccio-dma: Fix typo in comment
Revert "parisc: Show error if wrong 32/64-bit compiler is being used"
parisc: Make CONFIG_64BIT available for ARCH=parisc64 only
parisc: Fix exception handler for fldw and fstw instructions
|
|
The devm_clk_get_enabled() helper:
- calls devm_clk_get()
- calls clk_prepare_enable() and registers what is needed in order to
call clk_disable_unprepare() when needed, as a managed resource.
This simplifies the code, the error handling paths and avoid the need of
a dedicated function used with devm_add_action_or_reset().
Based on my test with allyesconfig, this reduces the .o size from:
text data bss dec hex filename
6705 1968 0 8673 21e1 drivers/rtc/rtc-mxc.o
down to:
6212 1968 0 8180 1ff4 drivers/rtc/rtc-mxc.o
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/1b5ad1877304b01ddbba73ca615274a52f781aa2.1660582728.git.christophe.jaillet@wanadoo.fr
|
|
Pull misc fixes from Andrew Morton:
"Thirteen fixes, almost all for MM.
Seven of these are cc:stable and the remainder fix up the changes
which went into this -rc cycle"
* tag 'mm-hotfixes-stable-2022-08-22' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm:
kprobes: don't call disarm_kprobe() for disabled kprobes
mm/shmem: shmem_replace_page() remember NR_SHMEM
mm/shmem: tmpfs fallocate use file_modified()
mm/shmem: fix chattr fsflags support in tmpfs
mm/hugetlb: support write-faults in shared mappings
mm/hugetlb: fix hugetlb not supporting softdirty tracking
mm/uffd: reset write protection when unregister with wp-mode
mm/smaps: don't access young/dirty bit if pte unpresent
mm: add DEVICE_ZONE to FOR_ALL_ZONES
kernel/sys_ni: add compat entry for fadvise64_64
mm/gup: fix FOLL_FORCE COW security issue and remove FOLL_COW
Revert "zram: remove double compression logic"
get_maintainer: add Alan to .get_maintainer.ignore
|
|
This register would fail to be reset if reading the RTC bias failed for
whichever reason. This commit reorganises the code around to
unconditionally write it back to its previous value, unmap it, and
return the result of regmap_read(), which makes it both simpler and more
correct in the error case.
Signed-off-by: Emmanuel Gil Peyrot <linkmauve@linkmauve.fr>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/20220823130702.1046-1-linkmauve@linkmauve.fr
|
|
To allow new SoCs to use this device without a new compatible string,
use a soc_device_attribute list to define all SoCs affected by the TI
i2327 erratum and require help from their bootloaders to unlock this
device.
Signed-off-by: Bryan Brattlof <bb@ti.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/20220816173312.23243-2-bb@ti.com
|
|
After writing the magic words to the KICK0 and KICK1 registers, we must
wait for a 1 in the unlock field of the general control register to
signify when the rtc device is in an unlocked state.
Signed-off-by: Bryan Brattlof <bb@ti.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/20220816173312.23243-1-bb@ti.com
|
|
Pull KUnit fixes from Shuah Khan:
"Fix for a mmc test and to load .kunit_test_suites section when
CONFIG_KUNIT=m, and not just when KUnit is built-in"
* tag 'linux-kselftest-kunit-fixes-6.0-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest:
module: kunit: Load .kunit_test_suites section when CONFIG_KUNIT=m
mmc: sdhci-of-aspeed: test: Fix dependencies when KUNIT=m
|
|
During boot, the driver prints out a stray carriage return character.
Remove it, together with the preceding space character.
While at it, change prescaler to "unsigned long", as returned by
clk_get_rate(), to avoid truncating very large clock rates, and update
the format specifiers.
Fixes: 0b31d703598dc199 ("rtc: Add driver for Microchip PolarFire SoC")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/bce2ca405ef96b1363fd1370887409d9e8468422.1660659437.git.geert+renesas@glider.be
|
|
There are sparse warning:
drivers/remoteproc/imx_dsp_rproc.c:602:49: sparse: sparse: incorrect type in argument 2 (different address spaces) @@ expected void *va @@ got void [noderef] __iomem *[assigned] cpu_addr @@
drivers/remoteproc/imx_dsp_rproc.c:602:49: sparse: expected void *va
drivers/remoteproc/imx_dsp_rproc.c:602:49: sparse: got void [noderef] __iomem *[assigned] cpu_addr
drivers/remoteproc/imx_dsp_rproc.c:638:49: sparse: sparse: incorrect type in argument 2 (different address spaces) @@ expected void *va @@ got void [noderef] __iomem *[assigned] cpu_addr @@
drivers/remoteproc/imx_dsp_rproc.c:638:49: sparse: expected void *va
drivers/remoteproc/imx_dsp_rproc.c:638:49: sparse: got void [noderef] __iomem *[assigned] cpu_addr
Fixes: ec0e5549f358 ("remoteproc: imx_dsp_rproc: Add remoteproc driver for DSP on i.MX")
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
Link: https://lore.kernel.org/r/1660567398-24495-1-git-send-email-shengjiu.wang@nxp.com
Acked-by: Mukesh Ojha <quic_mojha@quicinc.com>
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
|
|
The DLM_LSFL_FS flag is set in lockspaces created directly
for a kernel user, as opposed to those lockspaces created
for user space applications. The user space libdlm allowed
this flag to be set for lockspaces created from user space,
but then used by a kernel user. No kernel user has ever
used this method, so remove the ability to do it.
Signed-off-by: Alexander Aring <aahringo@redhat.com>
Signed-off-by: David Teigland <teigland@redhat.com>
|
|
dev_err_probe() already prints the error code in a human readable way, so
there is no need to duplicate it as a numerical value at the end of the
message.
While at it, remove 'ret' that is mostly useless.
Fixes: 2df7062002d0 ("remoteproc: imx_proc: enable virtio/mailbox")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Link: https://lore.kernel.org/r/6b9343c2688117a340661d8ee491c2962c54a09a.1659736936.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
|
|
There is no need to check if the cpufreq driver implements callback
cpufreq_driver::target_index. The logic in the __resolve_freq uses
the frequency table available in the policy. It doesn't matter if the
driver provides 'target_index' or 'target' callback. It just has to
populate the 'policy->freq_table'.
Thus, check only frequency table during the frequency resolving call.
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Lukasz Luba <lukasz.luba@arm.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
In some case, the GDDV returns a package with a buffer which has
zero length. It causes that kmemdup() returns ZERO_SIZE_PTR (0x10).
Then the data_vault_read() got NULL point dereference problem when
accessing the 0x10 value in data_vault.
[ 71.024560] BUG: kernel NULL pointer dereference, address:
0000000000000010
This patch uses ZERO_OR_NULL_PTR() for checking ZERO_SIZE_PTR or
NULL value in data_vault.
Signed-off-by: "Lee, Chun-Yi" <jlee@suse.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Add compatible string for GT1158 missing from the previous patch.
Fixes: 425fe4709c76 ("Input: goodix - add support for GT1158")
Signed-off-by: Jarrah Gosbell <kernel@undef.tools>
Link: https://lore.kernel.org/r/20220813043821.9981-1-kernel@undef.tools
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
|
|
The regulators set consists of 3 bucks DCDCs and 4 LDOs. The output
voltages are configurable and are meant to supply power to the
main processor and other components.
Validation:
Visual check: cat /sys/kernel/debug/regulator/regulator_summary
Validation: userspace-consumer and virtual-regulator required
to test further
Enable/Disable:
cat /sys/devices/platform/userspace-consumer-VDDSHV_SD_IO_PMIC/state
echo disabled > /sys/devices/platform/
userspace-consumer-VDDSHV_SD_IO_PMIC/state
echo enabled > /sys/devices/platform/
userspace-consumer-VDDSHV_SD_IO_PMIC/state
Change voltage:
cat /sys/devices/platform/regulator-virtual-ldo1/min_microvolts
echo 1000000 > /sys/devices/platform/regulator-virtual-ldo1/
min_microvolts
echo 3000000 > /sys/devices/platform/regulator-virtual-ldo1/
max_microvolts
Signed-off-by: Jerome Neanne <jneanne@baylibre.com>
Link: https://lore.kernel.org/r/20220805121852.21254-9-jneanne@baylibre.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The ranges and types are taken from the relevant SPMI driver:
- ftsmps_510: s1-s4, s8
- buck_510: s5-s7
- ldo_nX_510: l1-l4, l6-l8, l17-18
- ldo_mv_pX_510: l5, l15, l19-l24
- ldo_lv_pX_510: l9-l14, l16
Signed-off-by: Adam Skladowski <a39.skl@gmail.com>
Signed-off-by: Iskren Chernev <iskren.chernev@gmail.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://lore.kernel.org/r/20220802221112.2280686-14-iskren.chernev@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The sorting is split in multiple commits for easier reviewing.
Signed-off-by: Iskren Chernev <iskren.chernev@gmail.com>
Link: https://lore.kernel.org/r/20220802221112.2280686-13-iskren.chernev@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The sorting is split in multiple commits for easier reviewing.
Signed-off-by: Iskren Chernev <iskren.chernev@gmail.com>
Link: https://lore.kernel.org/r/20220802221112.2280686-12-iskren.chernev@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The sorting is split in multiple commits for easier reviewing.
Signed-off-by: Iskren Chernev <iskren.chernev@gmail.com>
Link: https://lore.kernel.org/r/20220802221112.2280686-11-iskren.chernev@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Add support for PM6125 PMIC which is found on SM4250/6115 SoCs.
S1, S2, S3, S4, S8 are FTS+FTSMPS_510, rev 2
- range is 0.3-1.372V by 4mV increments
S5, S6, s7 are BUCK+HFSMPS_510, rev 4
- range is 0.32-2.04V by 8mV increment
L1, L3, L7 are LDO+N600_510, rev 2
L2, L4, L8, L17, L18 are LDO+N300_510, rev 2
L6 is LDO+N1200_510, rev 2
- range is 0.32-1.304V by 8mV increment
L5 is LDO+MV_P50_510, rev 2
L15, L19, L20 are LDO+MV_P150_510, rev 2
L21, L22, L23, L24 are LDO+MV_P600_510, rev 2
- range is 1.504-3.544V by 8mV increment
L9, L11, L14 are LDO+LV_P600_510, rev 2
L10, L16 are LDO+LV_P150_510, rev 2
L12, L13 are LDO+LV_P300_510, rev 2
- range 1.504-2V by 8mV increment
Signed-off-by: Adam Skladowski <a39.skl@gmail.com>
Signed-off-by: Iskren Chernev <iskren.chernev@gmail.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://lore.kernel.org/r/20220802221112.2280686-10-iskren.chernev@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The sorting is split in multiple commits for easier reviewing.
Signed-off-by: Iskren Chernev <iskren.chernev@gmail.com>
Link: https://lore.kernel.org/r/20220802221112.2280686-9-iskren.chernev@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The sorting is split in multiple commits for easier reviewing.
Signed-off-by: Iskren Chernev <iskren.chernev@gmail.com>
Link: https://lore.kernel.org/r/20220802221112.2280686-8-iskren.chernev@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Add support for LDO_510 and FTSMPS3 regulators, all belonging to register
layout HFSMPS. This is done in preparation for adding support for the
PM6125 PMIC.
For FTSMPS3 and LDO_510, only IDLE and NORMAL modes are selectable (no
FAST).
The inspiration for the magic constants was taken from [1]
[1]: https://source.codeaurora.org/quic/la/kernel/msm-5.4/commit/?h=kernel.lnx.5.4.r1-rel&id=d1220daeffaa440ffff0a8c47322eb0033bf54f5
Signed-off-by: Adam Skladowski <a39.skl@gmail.com>
Signed-off-by: Iskren Chernev <iskren.chernev@gmail.com>
Link: https://lore.kernel.org/r/20220802221112.2280686-7-iskren.chernev@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
This is preparation for supporing PM6125.
The HFSMPS is a BUCK type regulator with subtype 0x0a, same as the
existing HFS430 regulator.
Even though the HFSMPS and HFS430 share a type and subtype, the HFSMPS has
an updated register map, including different mode values, moved pull down
register, and different slew rate address and formula.
In addition to NORMAL (NPM), FAST (AUTO_LPM) and IDLE (LPM), the
regulator also supports RETENTION and AUTO_RM which are currently
unselectable by the driver.
The inspiration of this is taken from [1].
[1] https://source.codeaurora.org/quic/la/kernel/msm-5.4/commit/?h=kernel.lnx.5.4.r1-rel&id=d1220daeffaa440ffff0a8c47322eb0033bf54f5
Signed-off-by: Iskren Chernev <iskren.chernev@gmail.com>
Link: https://lore.kernel.org/r/20220802221112.2280686-6-iskren.chernev@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The module and function information can be added with
'modprobe foo dyndbg=+pmf'
Suggested-by: Greg KH <gregkh@linuxfoundation.org>
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com>
Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Link: https://lore.kernel.org/r/20220823050158.2671245-3-yung-chuan.liao@linux.intel.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
The module and function information can be added with
'modprobe foo dyndbg=+pmf'
Suggested-by: Greg KH <gregkh@linuxfoundation.org>
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com>
Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Link: https://lore.kernel.org/r/20220823050158.2671245-2-yung-chuan.liao@linux.intel.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
Merge series from patrice.chotard@foss.st.com <patrice.chotard@foss.st.com>:
The goal of this series is to allow to use QSPI bus as a 8 lines communication
channel for specific purpose.
The QSPI block offers the possibility to communicate with 2 flashes in
parrallel using the dual flash mode, 8 data lines are then used.
Usage of cs-gpios populated and spi-tx-bus-width / spi-rx-bus-width both set to 8,
is needed to enable dual flash mode.
The addition of the legacy transfer_one_message() spi callback is also needed
as currently the stm32-qspi driver only supports spi_controller_mem_ops API.
|
|
The DSDT for this device has a number of problems:
a) it lists rt711 on link0 and link1, but link1 is disabled
b) the rt711 entry on link0 uses the wrong v2 instead of v3 (SDCA)
c) the rt1316 amplifier on link3 is not listed.
Add a remapping table to work-around these BIOS shenanigans.
BugLink: https://github.com/thesofproject/sof/issues/5955
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Link: https://lore.kernel.org/r/20220823030919.2346629-1-yung-chuan.liao@linux.intel.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
The capabilities enabled for multi-link are required as part of the
programming sequences, even when a stream uses a single link we still
use the syncArm/syncGo sequences. Therefore the TODO is no longer
necessary.
Suggested-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Khalid Masum <khalid.masum.92@gmail.com>
Link: https://lore.kernel.org/r/20220817074859.4759-1-khalid.masum.92@gmail.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
Follow the advice of the below link and prefer 'strscpy' in this
subsystem. Conversion is 1:1 because the return value is not used.
Generated by a coccinelle script.
Link: https://lore.kernel.org/r/CAHk-=wgfRnXz0W3D37d01q3JFkr_i_uTL=V6A6G1oUZcprmknw@mail.gmail.com/
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Update error prints to debug prints to avoid redundant logging in kernel
boot time, as these prints are informative prints in irq handler.
Signed-off-by: Srinivasa Rao Mandadapu <quic_srivasam@quicinc.com>
Reviewed-by: Andrew Halaney <ahalaney@redhat.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/1657724067-19004-1-git-send-email-quic_srivasam@quicinc.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
The documentation for acpi_dev_state_d0() referred to
Documentation/firmware-guide/acpi/low-power-probe.rst that does not exist,
the right file name is Documentation/firmware-guide/acpi/non-d0-probe.rst.
Fix this.
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
[ rjw: Subject edits ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
We were using the wrong bound in the debug prints: this
needs to be the number of elements, not the number of bytes,
since we're indexing into an element-size typed array.
Fixes: c20cc099b30a ("regmap: Support accelerated noinc operations")
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20220823135700.265019-1-linus.walleij@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Instead of having acpi_device_add() defined as a wrapper around
__acpi_device_add(), export acpi_tie_acpi_dev() so it can be called
directly by acpi_add_power_resource(), fold acpi_device_add() into the
latter and rename __acpi_device_add() to acpi_device_add().
No intentional functional impact.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Punit Agrawal <punit.agrawal@bytedance.com>
|
|
The initialization of ACPI device objects is split between
acpi_init_device_object() and __acpi_device_add() that initializes
the dev field in struct acpi_device. The "release" function pointer
is passed to __acpi_device_add() for this reason.
However, that split is artificial and all of the initialization can
be carried out by acpi_init_device_object(), so rearrange the code
to that end. In particular, make acpi_init_device_object() take the
"release" pointer as an argument, along with the "type" which is
related to it, instead of __acpi_device_add().
No intentional functional impact.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Punit Agrawal <punit.agrawal@bytedance.com>
|
|
The acpi_bus_get_parent() name doesn't really reflect the
purpose of the function so change it to a more accurate
acpi_find_parent_acpi_dev().
While at it, rearrange the code inside that function to make it
easier to read.
No intentional functional impact.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Punit Agrawal <punit.agrawal@bytedance.com>
|
|
Because acpi_bus_get_acpi_device() is completely analogous to
acpi_fetch_acpi_dev(), rename it to acpi_get_acpi_dev() and
add a kerneldoc comment to it.
Accordingly, rename acpi_bus_put_acpi_device() to acpi_put_acpi_dev()
and update all of the users of these two functions.
While at it, move the acpi_fetch_acpi_dev() header next to the
acpi_get_acpi_dev() header in the header file holding them.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Guenter Roeck <linux@roeck-us.net>
Reviewed-by: Punit Agrawal <punit.agrawal@bytedance.com>
|
|
Add an eDP panel entry for IVO M133NW4J-R3.
Due to lack of documentation, use the delay_200_500_p2e100 timings for
now.
Signed-off-by: Steev Klimaszewski <steev@kali.org>
[dianders: fixed typo in commit message]
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20220720054152.2450-1-steev@kali.org
|
|
The freq Qos request would be removed repeatedly if the cpufreq policy
relates to more than one CPU. Then, it would cause the "called for unknown
object" warning.
Remove the freq Qos request for each CPU relates to the cpufreq policy,
instead of removing repeatedly for the last CPU of it.
Fixes: a1bb46c36ce3 ("ACPI: processor: Add QoS requests for all CPUs")
Reported-by: Jeremy Linton <Jeremy.Linton@arm.com>
Tested-by: Jeremy Linton <jeremy.linton@arm.com>
Signed-off-by: Riwen Lu <luriwen@kylinos.cn>
Cc: 5.4+ <stable@vger.kernel.org> # 5.4+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Delete the redundant word 'at'.
Signed-off-by: wangjianli <wangjianli@cdjrlc.com>
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Signed-off-by: Karol Herbst <kherbst@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220821143038.46589-1-wangjianli@cdjrlc.com
|
|
It is a bit unlcear to us why that's helping, but it does and unbreaks
suspend/resume on a lot of GPUs without any known drawbacks.
Cc: stable@vger.kernel.org # v5.15+
Closes: https://gitlab.freedesktop.org/drm/nouveau/-/issues/156
Signed-off-by: Karol Herbst <kherbst@redhat.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220819200928.401416-1-kherbst@redhat.com
|
|
Looks like adding clock gate flag patch forgot to remove the old code that
gets reset control.
This causes below crash on platforms that do not need reset.
[ 15.653501] reset_control_reset+0x124/0x170
[ 15.653508] qcom_swrm_init+0x50/0x1a0
[ 15.653514] qcom_swrm_probe+0x320/0x668
[ 15.653519] platform_probe+0x68/0xe0
[ 15.653529] really_probe+0xbc/0x2a8
[ 15.653535] __driver_probe_device+0x7c/0xe8
[ 15.653541] driver_probe_device+0x40/0x110
[ 15.653547] __device_attach_driver+0x98/0xd0
[ 15.653553] bus_for_each_drv+0x68/0xd0
[ 15.653559] __device_attach+0xf4/0x188
[ 15.653565] device_initial_probe+0x14/0x20
Fix this by removing old code.
Reported-by: Amit Pundir <amit.pundir@linaro.org>
Fixes: 1fd0d85affe4 ("soundwire: qcom: Add flag for software clock gating check")
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Tested-by: Amit Pundir <amit.pundir@linaro.org>
Link: https://lore.kernel.org/r/20220814123800.31200-1-srinivas.kandagatla@linaro.org
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
Pps power hook seems to be problematic for backlight controlled via
aux channel. Disable it for such cases.
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3657
Cc: stable@vger.kernel.org
Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220822140836.534432-1-jouni.hogander@intel.com
|
|
Looks to have been left out in an oversight.
Cc: Mahesh Bandewar <maheshb@google.com>
Cc: Sainath Grandhi <sainath.grandhi@intel.com>
Fixes: 235a9d89da97 ('ipvtap: IP-VLAN based tap driver')
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Link: https://lore.kernel.org/r/20220821130808.12143-1-zenczykowski@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
Always update the status variables in rtw_led_control when we start
blinking because of no link. The code is easier to understand without
the if conditions.
Signed-off-by: Martin Kaiser <martin@kaiser.cx>
Link: https://lore.kernel.org/r/20220822201329.95559-4-martin@kaiser.cx
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
In rtw_led_control, we can always cancel a running blink worker when we
start blinking because of no link.
The worker will be scheduled again and there's no point in having more
than one pending blink worker.
Signed-off-by: Martin Kaiser <martin@kaiser.cx>
Link: https://lore.kernel.org/r/20220822201329.95559-3-martin@kaiser.cx
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Simplify one of the cases in rtw_led_control. If we're already blinking
because we have no link, we don't have to restart this blinking when the
caller requests it again. We can simply return and keep on blinking.
Signed-off-by: Martin Kaiser <martin@kaiser.cx>
Link: https://lore.kernel.org/r/20220822201329.95559-2-martin@kaiser.cx
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
The module parameter rtw_chip_version sets the chip_version field of
struct registry_priv but that field is never used in the driver code.
Remove the unused module parameter.
Tested-by: Philipp Hortmann <philipp.g.hortmann@gmail.com> # Edimax N150
Signed-off-by: Michael Straube <straube.linux@gmail.com>
Link: https://lore.kernel.org/r/20220821123138.8070-1-straube.linux@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
After previous cleanups the header xmit_osdep.h only contains some
structure forward declarations and extern declarations for some module
parameters. The forward declarations are not needed. We can make the
module parameters static in os_dep/os_intf.c and remove xmit_osdep.h.
Tested-by: Philipp Hortmann <philipp.g.hortmann@gmail.com> # Edimax N150
Signed-off-by: Michael Straube <straube.linux@gmail.com>
Link: https://lore.kernel.org/r/20220820181623.12497-20-straube.linux@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|