The J7 Quad Port Add-On Ethernet Card for J7200 Common-Proc-Board supports
QSGMII mode. Use the overlay to configure CPSW5G ports in QSGMII mode.
Add support to reset the PHY from kernel by using gpio-hog and gpio-reset.
Add aliases for CPSW5G ports to enable kernel to fetch MAC addresses
directly from U-Boot.
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Reviewed-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20230315062307.1612220-5-s-vadapalli@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
TI's J7200 SoC has a 5 port Ethernet Switch instance with 4 external
ports and 1 host port, referred to as CPSW5G.
Add device-tree nodes for CPSW5G and disable it by default. Device-tree
overlays will be used to enable it.
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Reviewed-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20230315062307.1612220-4-s-vadapalli@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
The J7 Quad Port Add-On Ethernet Card for J721E Common-Proc-Board supports
QSGMII mode. Use the overlay to configure CPSW9G ports in QSGMII mode.
Add support to reset the PHY from kernel by using gpio-hog and gpio-reset.
Add aliases for CPSW9G ports to enable kernel to fetch MAC addresses
directly from U-Boot.
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Reviewed-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20230315062307.1612220-3-s-vadapalli@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20230319100620.295849-4-u.kleine-koenig@pengutronix.de
Signed-off-by: Rob Herring <robh@kernel.org>
unittest_gpio_remove() is only called after unittest_gpio_probe() completed
successfully. In this case driver data was set to a non-NULL value and so
platform_get_drvdata() never returns NULL.
Also note that the compiler might optimize away this check anyhow as
devptr was already dereferenced for the dev_dbg call above.
Drop this if block.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20230319100620.295849-3-u.kleine-koenig@pengutronix.de
Signed-off-by: Rob Herring <robh@kernel.org>
The driver core already unsets driver data after .remove() completes.
So there is no reason to do this explicitly in the driver itself.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20230319100620.295849-2-u.kleine-koenig@pengutronix.de
Signed-off-by: Rob Herring <robh@kernel.org>
Just like in commit eddc630948 ("clk: mediatek: Ensure fhctl code is
available for COMMON_CLK_MT6795"), these three need the shared driver
code, otherwise they run into link errors such as:
aarch64-linux/bin/aarch64-linux-ld: drivers/clk/mediatek/clk-mt8192-apmixedsys.o: in function `clk_mt8192_apmixed_probe':
clk-mt8192-apmixedsys.c:(.text+0x134): undefined reference to `fhctl_parse_dt'
Fixes: 45a5cbe05d ("clk: mediatek: mt8173: Add support for frequency hopping through FHCTL")
Fixes: 4d586e10c4 ("clk: mediatek: mt8192: Add support for frequency hopping through FHCTL")
Fixes: da4a82dc67 ("clk: mediatek: mt8195: Add support for frequency hopping through FHCTL")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/r/20230320091353.1918439-1-arnd@kernel.org
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Merge series from Douglas Anderson <dianders@chromium.org>:
This series directly follows from the discussion when I tried to turn
on PROBE_PREFER_ASYNCHRONOUS just for the fixed-regulator [1] and
attempts to switch everything in drivers/regulator over to async
probe.
Like the similar patch series I did for the MMC subsystem a few years
ago [2], I've split this patch series into batches corresponding to
drivers corresponding to actively maintained stable kernel trees with
the idea to break the patch series up somewhat.
Most of the description of this series is contained in the first patch
of the series and then the further patches simply refer back to the
first one. The logic and reasoning behind all the patches is exactly
the same.
As talked about in the first patch, it wouldn't be at all shocking if
this broke someone. Hopefully this doesn't cause too much of a
problem. Most of the problems expected would be real underlying bugs
that already existed and were just tickled by this change. If you're
facing a problem, it's fairly easy to force individual drivers back to
"synchronous" probing while the problem is tracked down and fixed.
I am opting _not_ to CC every single person involved in each of these
regulators on this patch series because I suspect that the mailing
lists couldn't handle CCing that many people. This should be on LKML
so hopefully people can find it there and respond to it that
way. Anyone who responds will get CCed on future versions, if there
are any.
For reference, the ugly script I used is here:
import os
import re
for filename in os.listdir("."):
found_subsys = False
found_driver = False
output = []
for line in open(filename, "r").readlines():
if "struct platform_driver" in line or \
"struct i2c_driver" in line or \
"struct spmi_driver" in line or \
"struct spi_driver" in line:
found_subsys = True
if found_subsys and re.search(r"\t\.driver\s*=\s*{", line):
found_driver = True
found_subsys = False
mo = re.search(r"(\s*)\.name(\s*)=", line)
if found_driver and mo:
if not line.endswith(",\n"):
line = line[:-1] + ",\n"
output.append(line)
if mo.group(2) == " ":
space = " "
elif mo.group(2) == "\t":
# Best we can do
space = " "
elif mo.group(2).startswith("\t"):
# Guess that removing one tab is right
space = mo.group(2)[1:]
else:
# Guess it's all spaces
space = mo.group(2)[7:] + " "
output.append("%s.probe_type%s= PROBE_PREFER_ASYNCHRONOUS,\n" % (mo.group(1), space))
found_driver = False
else:
output.append(line)
open(filename, "w").write("".join(output))
I manually split drivers up into groups based on the kernel they were
introduced in.
I've run a compile test against "allyesconfig" on amd64, arm32, and
arm64 with this and confirmed it compiled. I've booted this on a
sc7180-trogdor-lazor board and confirmed it booted OK and got the boot
speed improvements I expected and that dmesg was as expected.
[1] https://lore.kernel.org/r/06db017f-e985-4434-8d1d-02ca2100cca0@sirena.org.uk
[2] https://lore.kernel.org/r/20200903232441.2694866-1-dianders@chromium.org/
Douglas Anderson (7):
regulator: Set PROBE_PREFER_ASYNCHRONOUS for drivers that existed in
4.14
regulator: Set PROBE_PREFER_ASYNCHRONOUS for drivers between 4.14 and
4.19
regulator: Set PROBE_PREFER_ASYNCHRONOUS for drivers between 4.19 and
5.4
regulator: Set PROBE_PREFER_ASYNCHRONOUS for drivers between 5.4 and
5.10
regulator: Set PROBE_PREFER_ASYNCHRONOUS for drivers between 5.10 and
5.15
regulator: Set PROBE_PREFER_ASYNCHRONOUS for drivers between 5.15 and
6.1
regulator: Set PROBE_PREFER_ASYNCHRONOUS for drivers that are newer
than 6.1
drivers/regulator/88pg86x.c | 1 +
drivers/regulator/88pm800-regulator.c | 1 +
drivers/regulator/88pm8607.c | 1 +
drivers/regulator/aat2870-regulator.c | 1 +
drivers/regulator/ab8500-ext.c | 1 +
drivers/regulator/ab8500.c | 1 +
drivers/regulator/act8865-regulator.c | 1 +
drivers/regulator/act8945a-regulator.c | 1 +
drivers/regulator/ad5398.c | 1 +
drivers/regulator/anatop-regulator.c | 1 +
drivers/regulator/arizona-ldo1.c | 2 ++
drivers/regulator/arizona-micsupp.c | 2 ++
drivers/regulator/as3711-regulator.c | 1 +
drivers/regulator/as3722-regulator.c | 1 +
drivers/regulator/atc260x-regulator.c | 1 +
drivers/regulator/axp20x-regulator.c | 1 +
drivers/regulator/bcm590xx-regulator.c | 1 +
drivers/regulator/bd71815-regulator.c | 1 +
drivers/regulator/bd71828-regulator.c | 3 ++-
drivers/regulator/bd718x7-regulator.c | 1 +
drivers/regulator/bd9571mwv-regulator.c | 1 +
drivers/regulator/bd9576-regulator.c | 1 +
drivers/regulator/cpcap-regulator.c | 1 +
drivers/regulator/cros-ec-regulator.c | 1 +
drivers/regulator/da903x-regulator.c | 1 +
drivers/regulator/da9052-regulator.c | 1 +
drivers/regulator/da9055-regulator.c | 1 +
drivers/regulator/da9062-regulator.c | 1 +
drivers/regulator/da9063-regulator.c | 1 +
drivers/regulator/da9121-regulator.c | 1 +
drivers/regulator/da9210-regulator.c | 1 +
drivers/regulator/da9211-regulator.c | 1 +
drivers/regulator/db8500-prcmu.c | 1 +
drivers/regulator/dummy.c | 1 +
drivers/regulator/fan53555.c | 1 +
drivers/regulator/fan53880.c | 1 +
drivers/regulator/fixed.c | 1 +
drivers/regulator/gpio-regulator.c | 1 +
drivers/regulator/hi6421-regulator.c | 1 +
drivers/regulator/hi6421v530-regulator.c | 1 +
drivers/regulator/hi6421v600-regulator.c | 1 +
drivers/regulator/hi655x-regulator.c | 1 +
drivers/regulator/isl6271a-regulator.c | 1 +
drivers/regulator/isl9305.c | 1 +
drivers/regulator/lm363x-regulator.c | 1 +
drivers/regulator/lochnagar-regulator.c | 1 +
drivers/regulator/lp3971.c | 1 +
drivers/regulator/lp3972.c | 1 +
drivers/regulator/lp872x.c | 1 +
drivers/regulator/lp873x-regulator.c | 1 +
drivers/regulator/lp8755.c | 1 +
drivers/regulator/lp87565-regulator.c | 1 +
drivers/regulator/lp8788-buck.c | 1 +
drivers/regulator/lp8788-ldo.c | 2 ++
drivers/regulator/ltc3589.c | 1 +
drivers/regulator/ltc3676.c | 1 +
drivers/regulator/max14577-regulator.c | 1 +
drivers/regulator/max1586.c | 1 +
drivers/regulator/max20086-regulator.c | 1 +
drivers/regulator/max20411-regulator.c | 1 +
drivers/regulator/max597x-regulator.c | 1 +
drivers/regulator/max77620-regulator.c | 1 +
drivers/regulator/max77650-regulator.c | 1 +
drivers/regulator/max77686-regulator.c | 1 +
drivers/regulator/max77693-regulator.c | 1 +
drivers/regulator/max77802-regulator.c | 1 +
drivers/regulator/max77826-regulator.c | 1 +
drivers/regulator/max8649.c | 1 +
drivers/regulator/max8660.c | 1 +
drivers/regulator/max8893.c | 1 +
drivers/regulator/max8907-regulator.c | 1 +
drivers/regulator/max8925-regulator.c | 1 +
drivers/regulator/max8952.c | 1 +
drivers/regulator/max8973-regulator.c | 1 +
drivers/regulator/max8997-regulator.c | 1 +
drivers/regulator/max8998.c | 1 +
drivers/regulator/mc13783-regulator.c | 1 +
drivers/regulator/mc13892-regulator.c | 1 +
drivers/regulator/mcp16502.c | 1 +
drivers/regulator/mp5416.c | 1 +
drivers/regulator/mp8859.c | 1 +
drivers/regulator/mp886x.c | 1 +
drivers/regulator/mpq7920.c | 1 +
drivers/regulator/mt6311-regulator.c | 1 +
drivers/regulator/mt6315-regulator.c | 1 +
drivers/regulator/mt6323-regulator.c | 1 +
drivers/regulator/mt6331-regulator.c | 1 +
drivers/regulator/mt6332-regulator.c | 1 +
drivers/regulator/mt6357-regulator.c | 1 +
drivers/regulator/mt6358-regulator.c | 1 +
drivers/regulator/mt6359-regulator.c | 1 +
drivers/regulator/mt6360-regulator.c | 1 +
drivers/regulator/mt6370-regulator.c | 1 +
drivers/regulator/mt6380-regulator.c | 1 +
drivers/regulator/mt6397-regulator.c | 1 +
drivers/regulator/mtk-dvfsrc-regulator.c | 1 +
drivers/regulator/palmas-regulator.c | 1 +
drivers/regulator/pbias-regulator.c | 1 +
drivers/regulator/pca9450-regulator.c | 1 +
drivers/regulator/pcap-regulator.c | 1 +
drivers/regulator/pcf50633-regulator.c | 1 +
drivers/regulator/pf8x00-regulator.c | 1 +
drivers/regulator/pfuze100-regulator.c | 1 +
drivers/regulator/pv88060-regulator.c | 1 +
drivers/regulator/pv88080-regulator.c | 1 +
drivers/regulator/pv88090-regulator.c | 1 +
drivers/regulator/pwm-regulator.c | 1 +
drivers/regulator/qcom-labibb-regulator.c | 1 +
drivers/regulator/qcom-rpmh-regulator.c | 1 +
drivers/regulator/qcom_rpm-regulator.c | 1 +
drivers/regulator/qcom_smd-regulator.c | 1 +
drivers/regulator/qcom_spmi-regulator.c | 1 +
drivers/regulator/qcom_usb_vbus-regulator.c | 1 +
drivers/regulator/rc5t583-regulator.c | 1 +
drivers/regulator/rk808-regulator.c | 3 ++-
drivers/regulator/rn5t618-regulator.c | 1 +
drivers/regulator/rpi-panel-attiny-regulator.c | 1 +
drivers/regulator/rt4801-regulator.c | 1 +
drivers/regulator/rt4831-regulator.c | 1 +
drivers/regulator/rt5033-regulator.c | 1 +
drivers/regulator/rt5120-regulator.c | 1 +
drivers/regulator/rt5190a-regulator.c | 1 +
drivers/regulator/rt5739.c | 1 +
drivers/regulator/rt5759-regulator.c | 1 +
drivers/regulator/rt6160-regulator.c | 1 +
drivers/regulator/rt6190-regulator.c | 1 +
drivers/regulator/rt6245-regulator.c | 1 +
drivers/regulator/rtmv20-regulator.c | 1 +
drivers/regulator/rtq2134-regulator.c | 1 +
drivers/regulator/rtq6752-regulator.c | 1 +
drivers/regulator/s2mpa01.c | 1 +
drivers/regulator/s2mps11.c | 1 +
drivers/regulator/s5m8767.c | 1 +
drivers/regulator/sc2731-regulator.c | 1 +
drivers/regulator/sky81452-regulator.c | 1 +
drivers/regulator/slg51000-regulator.c | 1 +
drivers/regulator/sm5703-regulator.c | 1 +
drivers/regulator/stm32-booster.c | 1 +
drivers/regulator/stm32-pwr.c | 1 +
drivers/regulator/stm32-vrefbuf.c | 1 +
drivers/regulator/stpmic1_regulator.c | 1 +
drivers/regulator/stw481x-vmmc.c | 1 +
drivers/regulator/sy7636a-regulator.c | 1 +
drivers/regulator/sy8106a-regulator.c | 1 +
drivers/regulator/sy8824x.c | 1 +
drivers/regulator/sy8827n.c | 1 +
drivers/regulator/ti-abb-regulator.c | 1 +
drivers/regulator/tps51632-regulator.c | 1 +
drivers/regulator/tps6105x-regulator.c | 1 +
drivers/regulator/tps62360-regulator.c | 1 +
drivers/regulator/tps6286x-regulator.c | 1 +
drivers/regulator/tps65023-regulator.c | 1 +
drivers/regulator/tps6507x-regulator.c | 1 +
drivers/regulator/tps65086-regulator.c | 1 +
drivers/regulator/tps65090-regulator.c | 1 +
drivers/regulator/tps65132-regulator.c | 1 +
drivers/regulator/tps65217-regulator.c | 1 +
drivers/regulator/tps65218-regulator.c | 1 +
drivers/regulator/tps65219-regulator.c | 1 +
drivers/regulator/tps6524x-regulator.c | 1 +
drivers/regulator/tps6586x-regulator.c | 1 +
drivers/regulator/tps65910-regulator.c | 1 +
drivers/regulator/tps65912-regulator.c | 1 +
drivers/regulator/tps68470-regulator.c | 1 +
drivers/regulator/twl-regulator.c | 1 +
drivers/regulator/twl6030-regulator.c | 1 +
drivers/regulator/uniphier-regulator.c | 1 +
drivers/regulator/userspace-consumer.c | 1 +
drivers/regulator/vctrl-regulator.c | 1 +
drivers/regulator/vexpress-regulator.c | 1 +
drivers/regulator/virtual.c | 1 +
drivers/regulator/vqmmc-ipq4019-regulator.c | 1 +
drivers/regulator/wm831x-dcdc.c | 4 ++++
drivers/regulator/wm831x-isink.c | 1 +
drivers/regulator/wm831x-ldo.c | 3 +++
drivers/regulator/wm8350-regulator.c | 1 +
drivers/regulator/wm8400-regulator.c | 1 +
drivers/regulator/wm8994-regulator.c | 1 +
178 files changed, 188 insertions(+), 2 deletions(-)
--
2.40.0.rc1.284.g88254d51c5-goog
Write data to fd by calling "vdprintf", in most implementations
of the standard library, the data is finally written by the writev syscall.
But "uprobe_events/kprobe_events" does not allow segmented writes,
so switch the "append_to_file" function to explicit write() call.
Signed-off-by: Liu Pan <patteliu@gmail.com>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/bpf/20230320030720.650-1-patteliu@gmail.com
Merge series from Uwe Kleine-König <u.kleine-koenig@pengutronix.de>:
An early error return from a remove callback is usally wrong. In the
case of the spi-sprd driver it's not that critical because the skipped
steps are mainly undoing the things that a successful runtime-resume
would have done.
Still it's cleaner to not exit early and not return an (mostly ignored)
error value. The second patch converts to .remove_new (which is the
motivation for this series).
Merge series from Uwe Kleine-König <u.kleine-koenig@pengutronix.de>:
This small series converts the spi-imx driver to .remove_new(). The
motivation for this tree-wide effort are drivers that don't properly
cleanup and return an error code. This is broken as this results in
resource leaks. The spi-imx driver is such a driver. The idea is that if
the remove callback returns void it's obvious that an early error return
is wrong.
Merge series from Cristian Ciocaltea <cristian.ciocaltea@collabora.com>:
There are five I2S/PCM/TDM controllers and two I2S/PCM controllers embedded
in the RK3588 and RK3588S SoCs. Furthermore, RK3588 provides four additional
I2S/PCM/TDM controllers.
This patch series adds the required device tree nodes to support all the above.
Additionally, it enables analog audio support for the Rock 5B SBC, which has
been used to test both audio playback and recording.
The error handling for platform_get_irq() failing no longer works after
a recent change, clang now points this out with a warning:
drivers/gpu/host1x/dev.c:520:6: error: variable 'syncpt_irq' is uninitialized when used here [-Werror,-Wuninitialized]
if (syncpt_irq < 0)
^~~~~~~~~~
Fix this by removing the variable and checking the correct error status.
Fixes: 625d4ffb43 ("gpu: host1x: Rewrite syncpoint interrupt handling")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Reviewed-by: Mikko Perttunen <mperttunen@nvidia.com>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The ref_scale_shutdown() kthread/function uses wait_event() to wait for
the refscale test to complete. However, although the read-side tests
are normally extremely fast, there is no law against specifying a very
large value for the refscale.loops module parameter or against having
a slow read-side primitive. Either way, this might well trigger the
hung-task timeout.
This commit therefore replaces those wait_event() calls with calls to
wait_event_idle(), which do not trigger the hung-task timeout.
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
Signed-off-by: Boqun Feng <boqun.feng@gmail.com>
The rcu_scale_shutdown() and kfree_scale_shutdown() kthreads/functions
use wait_event() to wait for the rcuscale test to complete. However,
each updater thread in such a test waits for at least 100 grace periods.
If each grace period takes more than 1.2 seconds, which is long, but
not insanely so, this can trigger the hung-task timeout.
This commit therefore replaces those wait_event() calls with calls to
wait_event_idle(), which do not trigger the hung-task timeout.
Reported-by: kernel test robot <yujie.liu@intel.com>
Reported-by: Liam Howlett <liam.howlett@oracle.com>
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
Tested-by: Yujie Liu <yujie.liu@intel.com>
Signed-off-by: Boqun Feng <boqun.feng@gmail.com>
Given a non-zero rcutorture.nocbs_nthreads module parameter, the specified
number of nocb kthreads will be created, regardless of whether or not
the RCU implementation under test is capable of offloading callbacks.
Please note that even vanilla RCU is incapable of offloading in kernels
built with CONFIG_RCU_NOCB_CPU=n. And when the RCU implementation is
incapable of offloading callbacks, there is no point in creating those
kthreads.
This commit therefore checks the cur_ops.torture_type module parameter and
CONFIG_RCU_NOCB_CPU Kconfig option in order to avoid creating unnecessary
nocb tasks.
Signed-off-by: Zqiang <qiang1.zhang@intel.com>
Reviewed-by: Joel Fernandes (Google) <joel@joelfernandes.org>
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
[ boqun: Fix checkpatch warning ]
Signed-off-by: Boqun Feng <boqun.feng@gmail.com>
The Acer Aspire 3830TG predates Windows 8, so it defaults to using
acpi_video# for backlight control, but this is non functional on
this model.
Add a DMI quirk to use the native backlight interface which does
work properly.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Some older GPUs (namely a2xx with no opp tables at all and a320 with
downstream-remnants gpu pwrlevels) used not to have OPP tables. They
both however had just one frequency defined, making it extremely easy
to construct such an OPP table from within the driver if need be.
Do so and switch all clk_set_rate calls on core_clk to their OPP
counterparts.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/523784/
Link: https://lore.kernel.org/r/20230223-topic-opp-v3-3-5f22163cd1df@linaro.org
Signed-off-by: Rob Clark <robdclark@chromium.org>
As per the recommended recovery sequence of adreno gpu, cx gdsc should
collapse at hardware before it is turned back ON. This helps to clear
out the stale states in hardware before it is reinitialized. Use the
genpd notifier along with the newly introduced
dev_pm_genpd_synced_poweroff() api to ensure that cx gdsc has collapsed
before we turn it back ON.
Signed-off-by: Akhil P Oommen <quic_akhilpo@quicinc.com>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/516472/
Link: https://lore.kernel.org/r/20230102161757.v5.5.I9e10545c6a448d5eb1b734839b871d1b3146dac3@changeid
Signed-off-by: Rob Clark <robdclark@chromium.org>
The acpi-cpufreq and pcc-cpufreq drivers are loaded through per-CPU
module aliases. This can result in many unnecessary load requests during
boot if another frequency module, such as intel_pstate, is already
active. For instance, on a typical Intel system, one can observe that
udev makes 2x#CPUs attempts to insert acpi_cpufreq and 1x#CPUs attempts
for pcc_cpufreq. All these tries then fail if another frequency module
is already registered.
In the worst case, without the recent fix in commit 0254127ab9
("module: Don't wait for GOING modules"), these module loads occupied
all udev workers and had their initialization attempts ran sequentially.
Resolving all these loads then on some larger machines took too long,
prevented other hardware from getting its drivers initialized and
resulted in a failed boot. Discussion over these duplicate module
requests ended up with a conclusion that only one load attempt should be
ideally made.
Both acpi-cpufreq and pcc-cpufreq drivers use platform firmware controls
which are defined by ACPI. It is possible to treat these interfaces as
platform devices.
The patch extends the ACPI parsing logic to check the ACPI namespace if
the PPC or PCC interface is present and creates a virtual platform
device for each if it is available. The acpi-cpufreq and pcc-cpufreq
drivers are then updated to map to these devices.
This allows to try loading acpi-cpufreq and pcc-cpufreq only once during
boot and only if a given interface is available in the firmware.
Signed-off-by: Petr Pavlu <petr.pavlu@suse.com>
[ rjw: whitespace and error message log level adjustments, subject edits ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Remove the unused 'reset' interface which was supposed to help to ensure
that cx gdsc has collapsed during gpu recovery. This is was not enabled
so far due to missing gpucc driver support. Similar functionality using
genpd framework will be implemented in the upcoming patch.
This effectively reverts commit 1f6cca4049
("drm/msm/a6xx: Ensure CX collapse during gpu recovery").
Signed-off-by: Akhil P Oommen <quic_akhilpo@quicinc.com>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
Patchwork: https://patchwork.freedesktop.org/patch/516470/
Link: https://lore.kernel.org/r/20230102161757.v5.4.I96e0bf9eaf96dd866111c1eec8a4c9b70fd7cbcb@changeid
Signed-off-by: Rob Clark <robdclark@chromium.org>
When a device has multiple power domains, dev->power_domain is left
empty during probe. That didn't cause any issue so far because we are
freeloading on smmu driver's vote on cx gdsc. Instead of that, create
a device_link between cx genpd device and gmu device to keep a vote from
gpu driver.
Before this patch:
localhost ~ # cat /sys/kernel/debug/pm_genpd/pm_genpd_summary
gx_gdsc on 0
/devices/genpd:1:3d6a000.gmu active 0
cx_gdsc on 0
/devices/platform/soc@0/3da0000.iommu active 0
After this patch:
localhost ~ # cat /sys/kernel/debug/pm_genpd/pm_genpd_summary
gx_gdsc on 0
/devices/genpd:1:3d6a000.gmu active 0
cx_gdsc on 0
/devices/platform/soc@0/3da0000.iommu active 0
/devices/genpd:0:3d6a000.gmu active 0
Signed-off-by: Akhil P Oommen <quic_akhilpo@quicinc.com>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/516468/
Link: https://lore.kernel.org/r/20230102161757.v5.3.I7f545d8494dcdbe6e96a15fbe8aaf5bb0c003d50@changeid
Signed-off-by: Rob Clark <robdclark@chromium.org>
TI's J721E SoC has a 9 port Ethernet Switch instance with 8 external
ports and 1 host port, referred to as CPSW9G.
Add device-tree nodes for CPSW9G and disable it by default. Device-tree
overlays will be used to enable it.
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Reviewed-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20230315062307.1612220-2-s-vadapalli@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
J721s2 has two instances of 8 channel ADCs in MCU domain. Add pinmux
information for both ADC nodes.
Signed-off-by: Bhavya Kapoor <b-kapoor@ti.com>
Reviewed-by: Vignesh Raghavendra <vigneshr@ti.com>
Link: https://lore.kernel.org/r/20230316095146.498999-3-b-kapoor@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
Introduce digital RTC node in wakeup domain. Even though this has
no specific battery backup supply, this on-chip RTC is used in
cost-optimized board designs as a wakeup source.
Reviewed-by: Dhruva Gole <d-gole@ti.com>
Reviewed-by: Bryan Brattlof <bb@ti.com>
Link: https://lore.kernel.org/r/20230320165123.80561-2-nm@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
acpi_evaluate_dsm_typed() needs to be gaurded with CONFIG_ACPI to avoid
a redefintion error when the stub is also enabled.
In file included from ../drivers/bluetooth/btintel.c:13:
../include/acpi/acpi_bus.h:57:1: error: redefinition of 'acpi_evaluate_dsm_typed'
57 | acpi_evaluate_dsm_typed(acpi_handle handle, const guid_t *guid,..
| ^~~~~~~~~~~~~~~~~~~~~~~
In file included from ../drivers/bluetooth/btintel.c:12:
../include/linux/acpi.h:967:34: note: previous definition of
'acpi_evaluate_dsm_typed' with type 'union acpi_object *(void *,
const guid_t *, u64, u64, union acpi_object *, acpi_object_type)'
{aka 'union acpi_object *(void *, const guid_t *, long long unsigned int,
long long unsigned int, union acpi_object *, unsigned int)'}
967 | static inline union acpi_object
*acpi_evaluate_dsm_typed(acpi_handle handle,
Fixes: 1b94ad7ccc ("ACPI: utils: Add acpi_evaluate_dsm_typed() and acpi_check_dsm() stubs")
Signed-off-by: Kiran K <kiran.k@intel.com>
[ rjw: Subject and changelog edits ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
J721s2 has two instances of 8 channel ADCs in MCU domain. Add support
for both ADC nodes.
Signed-off-by: Bhavya Kapoor <b-kapoor@ti.com>
Reviewed-by: Vignesh Raghavendra <vigneshr@ti.com>
Link: https://lore.kernel.org/r/20230316095146.498999-2-b-kapoor@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
Add the node for SA2UL to support hardware crypto algorithms,
including SHA-1/256/512, AES, 3DES and AEAD suites.
Add rng node for hardware random number generator.
Signed-off-by: Jayesh Choudhary <j-choudhary@ti.com>
Reviewed-by: Kamlesh Gurudasani <kamlesh@ti.com>
Link: https://lore.kernel.org/r/20230314152611.140969-3-j-choudhary@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
For convenience (less code duplication), the pin controller pin
configuration register values were defined in the bindings header.
These are not some IDs or other abstraction layer but raw numbers used
in the registers.
These constants do not fit the purpose of bindings. They do not
provide any abstraction, any hardware and driver independent ID. In
fact, the Linux pinctrl-single driver actually do not use the bindings
header at all.
All of the constants were moved already to headers local to DTS
(residing in DTS directory), so remove any references to the bindings
header and add a warning that it is deprecated.
Suggested-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/linux-arm-kernel/71c7feff-4189-f12f-7353-bce41a61119d@linaro.org/
Link: https://lore.kernel.org/r/20230315155228.1566883-4-nm@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
The DTS uses hardware register values directly in pin controller pin
configuration and not an abstraction of any form.
These definitions were previously put in the bindings header to avoid
code duplication and to provide some context meaning (name), but they
do not fit the purpose of bindings.
Store the constants in a header next to DTS and use them instead of
bindings.
Suggested-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Suggested-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/all/c4d53e9c-dac0-8ccc-dc86-faada324beba@linaro.org/
Link: https://lore.kernel.org/r/20230315155228.1566883-3-nm@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
Drop the pinmux header reference as it is not used. Examples should
just show the node definition.
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20230315155228.1566883-2-nm@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
The firmware name for this core should stay as the default name
"j7-main-r5f0_0-fw". This is expected to by a symlink to the actual
firmware file. If one wants to use a different firmware they should
change where the symlink points. This is usually achieved with
an update-alternative or other distro specific selection mechanisms.
The actual selection is policy and does not belong in DT.
Remove this name override.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20230307180942.2719-1-afd@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
ACPI 6.5 added six new error types for CXL. See chapter 18
table 18.30.
Add strings for the new types so that Linux will list them in the
/sys/kernel/debug/apei/einj/available_error_types file.
It seems no other changes are needed. Linux already accepts
the CXL codes (on a BIOS that advertises them).
Signed-off-by: Tony Luck <tony.luck@intel.com>
Reviewed-by: Davidlohr Bueso <dave@stgolabs.net>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Merge drm-next into msm-next to pick up external clk and PM dependencies
for improved a6xx GPU reset sequence.
Signed-off-by: Rob Clark <robdclark@chromium.org>
The list of possible pm_profile values listed in sysfs-acpi-pmprofile
does not include the tablet one (8), so update it.
While at it, rewrite the description so it is more accurate and somewhat
easier to follow.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
devm_kzalloc() may fail, clk_data->name might be NULL and will
cause a NULL pointer dereference later.
Signed-off-by: Kang Chen <void0red@gmail.com>
[ rjw: Subject and changelog edits ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
cppcheck reports
drivers/thunderbolt/nhi.c:74:7: style: Local variable 'bit' shadows outer variable [shadowVariable]
int bit;
^
drivers/thunderbolt/nhi.c:66:6: note: Shadowed declaration
int bit = ring_interrupt_index(ring) & 31;
^
drivers/thunderbolt/nhi.c:74:7: note: Shadow variable
int bit;
^
For readablity rename the outer to interrupt_bit and the innner
to auto_clear_bit.
Fixes: 468c49f447 ("thunderbolt: Disable interrupt auto clear for ring")
Cc: stable@vger.kernel.org
Signed-off-by: Tom Rix <trix@redhat.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
BSPEC has updated the cdclk audio keepalives AUD_TS_CDCLK_M value to 60
for all supported platforms and refclks.
BSPEC: 54034
BSPEC: 55409
BSPEC: 65243
Cc: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Cc: Uma Shankar <uma.shankar@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Clint Taylor <clinton.a.taylor@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230316234654.3797572-1-clinton.a.taylor@intel.com
After working with the larger SELinux-based distros for several
years, we're finally at a place where we can disable the SELinux
runtime disable functionality. The existing kernel deprecation
notice explains the functionality and why we want to remove it:
The selinuxfs "disable" node allows SELinux to be disabled at
runtime prior to a policy being loaded into the kernel. If
disabled via this mechanism, SELinux will remain disabled until
the system is rebooted.
The preferred method of disabling SELinux is via the "selinux=0"
boot parameter, but the selinuxfs "disable" node was created to
make it easier for systems with primitive bootloaders that did not
allow for easy modification of the kernel command line.
Unfortunately, allowing for SELinux to be disabled at runtime makes
it difficult to secure the kernel's LSM hooks using the
"__ro_after_init" feature.
It is that last sentence, mentioning the '__ro_after_init' hardening,
which is the real motivation for this change, and if you look at the
diffstat you'll see that the impact of this patch reaches across all
the different LSMs, helping prevent tampering at the LSM hook level.
From a SELinux perspective, it is important to note that if you
continue to disable SELinux via "/etc/selinux/config" it may appear
that SELinux is disabled, but it is simply in an uninitialized state.
If you load a policy with `load_policy -i`, you will see SELinux
come alive just as if you had loaded the policy during early-boot.
It is also worth noting that the "/sys/fs/selinux/disable" file is
always writable now, regardless of the Kconfig settings, but writing
to the file has no effect on the system, other than to display an
error on the console if a non-zero/true value is written.
Finally, in the several years where we have been working on
deprecating this functionality, there has only been one instance of
someone mentioning any user visible breakage. In this particular
case it was an individual's kernel test system, and the workaround
documented in the deprecation notice ("selinux=0" on the kernel
command line) resolved the issue without problem.
Acked-by: Casey Schaufler <casey@schaufler-ca.com>
Signed-off-by: Paul Moore <paul@paul-moore.com>
