I accidentally found that a change in commit 1045b03e07 ("netlink: fix
overrun in attribute iteration") was not synchronized to the function
`nla_ok` in tools/lib/bpf/nlattr.c, I think it is necessary to modify,
this patch will do it.
Signed-off-by: Xin Liu <liuxin350@huawei.com>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/bpf/20220930090708.62394-1-liuxin350@huawei.com
To make clk-mt8365 compilable as a module there are a few function
symbols missing. This patch adds the required EXPORT_SYMBOL_GPL to the
functions.
Signed-off-by: Markus Schneider-Pargmann <msp@baylibre.com>
Link: https://lore.kernel.org/r/20220822152652.3499972-4-msp@baylibre.com
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
There are a couple of spelling mistakes, one in a literal string and one
in a comment. Fix them.
Signed-off-by: Colin Ian King <colin.i.king@gmail.com>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Acked-by: John Fastabend <john.fastabend@gmail.com>
Link: https://lore.kernel.org/bpf/20220928221555.67873-1-colin.i.king@gmail.com
Provide a helper that replaces the kzalloc with devm_kzalloc so error
handling gets easier.
Signed-off-by: Markus Schneider-Pargmann <msp@baylibre.com>
Link: https://lore.kernel.org/r/20220822152652.3499972-3-msp@baylibre.com
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Add the clock bindings for the MediaTek MT8365 SoC.
Signed-off-by: Fabien Parent <fparent@baylibre.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Markus Schneider-Pargmann <msp@baylibre.com>
Link: https://lore.kernel.org/r/20220822152652.3499972-2-msp@baylibre.com
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Use devm_add_action_or_reset() instead of devres_alloc() and
devres_add(), which works the same. This will simplify the
code. There is no functional changes.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20220623115719.52683-3-andriy.shevchenko@linux.intel.com
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Platform driver clk-bcm2835 gets an inaccurate clock for VEC (107MHz).
Export VEC clock trough clk-raspberrypi which uses the right PLL to
get an accurate 108MHz.
Signed-off-by: Dom Cobley <popcornmix@gmail.com>
[iivanov: Adapted on top of v5.17-rc6]
Signed-off-by: Ivan T. Ivanov <iivanov@suse.de>
Link: https://lore.kernel.org/r/20220829152154.147250-4-iivanov@suse.de
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
The clk-bcm2835 handling of the pixel clock does not function
correctly when the HDMI power domain is disabled.
The firmware supports it correctly, so add it to the
firmware clock driver.
Acked-by: Maxime Ripard <maxime@cerno.tech>
Acked-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Signed-off-by: Ivan T. Ivanov <iivanov@suse.de>
Link: https://lore.kernel.org/r/20220829152154.147250-3-iivanov@suse.de
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Export clock required for RPiVid video decoder hardware.
Cc: Dom Cobley <popcornmix@gmail.com>
Acked-by: Maxime Ripard <maxime@cerno.tech>
Signed-off-by: Ivan T. Ivanov <iivanov@suse.de>
Link: https://lore.kernel.org/r/20220829152154.147250-2-iivanov@suse.de
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
The return value of bcm2835_clock_rate_from_divisor is always unsigned
and also all caller expect this. So fix the declaration accordingly.
Fixes: 41691b8862 ("clk: bcm2835: Add support for programming the audio domain clocks")
Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
Link: https://lore.kernel.org/r/20220904141037.38816-1-stefan.wahren@i2se.com
Reviewed-by: Ivan T. Ivanov <iivanov@suse.de>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
It was reported that RPi3[1] and RPi Zero 2W boards have issues with
the Bluetooth. It turns out that when switching from initial to
operation speed host and device no longer can talk each other because
host uses incorrect UART baud rate.
The UART driver used in this case is amba-pl011. Original fix, see
below Github link[2], was inside pl011 module, but somehow it didn't
look as the right place to fix. Beside that this original rounding
function is not exactly perfect for all possible clock values. So I
deiced to move the hack to the platform which actually need it.
The UART clock is initialised to be as close to the requested
frequency as possible without exceeding it. Now that there is a
clock manager that returns the actual frequencies, an expected
48MHz clock is reported as 47999625. If the requested baud rate
== requested clock/16, there is no headroom and the slight
reduction in actual clock rate results in failure.
If increasing a clock by less than 0.1% changes it from ..999..
to ..000.., round it up.
[1] https://bugzilla.suse.com/show_bug.cgi?id=1188238
[2] ab3f1b3953
Cc: Phil Elwell <phil@raspberrypi.com>
Signed-off-by: Ivan T. Ivanov <iivanov@suse.de>
Reviewed-by: Stefan Wahren <stefan.wahren@i2se.com>
Link: https://lore.kernel.org/r/20220912081306.24662-1-iivanov@suse.de
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
When testing for a series affecting the VEC, it was discovered that
turning off and on the VEC clock is crashing the system.
It turns out that, when disabling the VEC clock, it's the only child of
the PLLC-per clock which will also get disabled. The source of the crash
is PLLC-per being disabled.
It's likely that some other device might not take a clock reference that
it actually needs, but it's unclear which at this point. Let's make
PLLC-per critical so that we don't have that crash.
Reported-by: Noralf Trønnes <noralf@tronnes.org>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Link: https://lore.kernel.org/r/20220926084509.12233-1-maxime@cerno.tech
Reviewed-by: Stefan Wahren <stefan.wahren@i2se.com>
Acked-by: Noralf Trønnes <noralf@tronnes.org>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
of_device_is_compatible() accepts const device node pointer, there is
no reason why of_device_compatible_match() can't do the same.
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Link: https://lore.kernel.org/r/YzY5MaU5N4A2st5R@google.com
Signed-off-by: Rob Herring <robh@kernel.org>
In accordance with the way the MIPS platform is normally design there are
only six clock sources which need to be available on the kernel start in
order to one end up booting correctly:
+ CPU PLL: needed by the r4k and MIPS GIC timer drivers. The former one is
initialized by the arch code, while the later one is implemented in the
mips-gic-timer.c driver as the OF-declared timer.
+ PCIe PLL: required as a parental clock source for the APB/timer domains.
+ APB clock: needed in order to access all the SoC CSRs at least for the
timer OF-declared drivers.
+ APB Timer{0-2} clocks: these are the DW APB timers which drivers
dw_apb_timer_of.c are implemented as the OF-declared timers.
So as long as the clocks above are available early the kernel will
normally work. Let's convert the Baikal-T1 CCU drivers to the platform
device drivers keeping that in mind.
Generally speaking the conversion isn't that complicated since the driver
infrastructure has been designed as flexible enough for that. First we
need to add a new PLL/Divider clock features flag which indicates the
corresponding clock source as a basic one and that clock sources will be
available on the kernel early boot stages. Second the internal PLL/Divider
descriptors need to be initialized with -EPROBE_DEFER value as the
corresponding clock source is unavailable at the early stages. They will
be allocated and initialized on the Baikal-T1 clock platform driver probe
procedure. Finally the already available PLL/Divider init functions need
to be split up into two ones: init procedure performed in the framework of
the OF-declared clock initialization (of_clk_init()), and the probe
procedure called by the platform devices bus driver. Note the later method
will just continue the system clocks initialization started in the former
one.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Link: https://lore.kernel.org/r/20220929225402.9696-9-Sergey.Semin@baikalelectronics.ru
[sboyd@kernel.org: Remove module things because the Kconfig is still
bool]
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Aside with a set of the trigger-like resets Baikal-T1 CCU provides two
additional blocks with directly controlled reset signals. In particular it
concerns DDR full and initial resets and various PCIe sub-domains resets.
Let's add the direct reset assertion/de-assertion of the corresponding
flags support into the Baikal-T1 CCU driver then. It will be required at
least for the PCIe platform driver. Obviously the DDR controller isn't
supposed to be fully reset in the kernel, so the corresponding controls
are added just for the sake of the interface implementation completeness.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
Link: https://lore.kernel.org/r/20220929225402.9696-8-Sergey.Semin@baikalelectronics.ru
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Aside with a set of the trigger-like resets Baikal-T1 CCU provides
additional directly controlled reset signals for the DDR and PCIe
controllers. As a preparation before adding these resets support to the
kernel let's extent the Baikal-T1 CCU IDs list with the new IDs, which
will be used to access the corresponding reset controls.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
Acked-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20220929225402.9696-7-Sergey.Semin@baikalelectronics.ru
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Before adding the directly controlled resets support it's reasonable to
move the existing resets control functionality into a dedicated object for
the sake of the CCU dividers clock driver simplification. After the new
functionality was added clk-ccu-div.c would have got to a mixture of the
weakly dependent clocks and resets methods. Splitting the methods up into
the two objects will make the code easier to read and maintain. It shall
also improve the code scalability (though hopefully we won't need this
part that much in the future).
The reset control functionality is now implemented in the framework of a
single unit since splitting it up doesn't make much sense due to
relatively simple reset operations. The ccu-rst.c has been designed to be
looking like ccu-div.c or ccu-pll.c with two globally available methods
for the sake of the code unification and better code readability.
This commit doesn't provide any change in the CCU reset implementation
semantics. As before the driver will support the trigger-like CCU resets
only, which are responsible for the AXI-bus, APB-bus and SATA-ref blocks
reset. The assert/de-assert-capable reset controls support will be added
in the next commit.
Note the CCU Clock dividers and resets functionality split up was possible
due to not having any side-effects (at least we didn't found ones) of the
regmap-based concurrent access of the common CCU dividers/reset CSRs.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
Link: https://lore.kernel.org/r/20220929225402.9696-6-Sergey.Semin@baikalelectronics.ru
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
It turns out the internal SATA reference clock signal will stay
unavailable for the SATA interface consumer until the buffer on it's way
is ungated. So aside with having the actual clock divider enabled we need
to ungate a buffer placed on the signal way to the SATA controller (most
likely some rudiment from the initial SoC release). Seeing the switch flag
is placed in the same register as the SATA-ref clock divider at a
non-standard ffset, let's implement it as a separate clock controller with
the set-rate propagation to the parental clock divider wrapper. As such
we'll be able to disable/enable and still change the original clock source
rate.
Fixes: 353afa3a8d ("clk: Add Baikal-T1 CCU Dividers driver")
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Link: https://lore.kernel.org/r/20220929225402.9696-5-Sergey.Semin@baikalelectronics.ru
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Baikal-T1 CCU reference manual says that both xGMAC reference and xGMAC
PTP clocks are generated by two different wrappers with the same constant
divider thus each producing a 156.25 MHz signal. But for some reason both
of these clock sources are gated by a single switch-flag in the CCU
registers space - CCU_SYS_XGMAC_BASE.BIT(0). In order to make the clocks
handled independently we need to define a shared parental gate so the base
clock signal would be switched off only if both of the child-clocks are
disabled.
Note the ID is intentionally set to -2 since we are going to add a one
more internal clock identifier in the next commit.
Fixes: 353afa3a8d ("clk: Add Baikal-T1 CCU Dividers driver")
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Link: https://lore.kernel.org/r/20220929225402.9696-4-Sergey.Semin@baikalelectronics.ru
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Most likely due to copy-paste mistake the divider has been set to 10 while
according to the SoC reference manual it's supposed to be 8 thus having
PTP clock frequency of 156.25 MHz.
Fixes: 353afa3a8d ("clk: Add Baikal-T1 CCU Dividers driver")
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Link: https://lore.kernel.org/r/20220929225402.9696-3-Sergey.Semin@baikalelectronics.ru
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
We have discovered random glitches during the system boot up procedure.
The problem investigation led us to the weird outcomes: when none of the
Renesas 5P49V6901 ports are explicitly enabled by the kernel driver, the
glitches disappeared. It was a mystery since the SoC external clock
domains were fed with different 5P49V6901 outputs. The driver code didn't
seem like bogus either. We almost despaired to find out a root cause when
the solution has been found for a more modern revision of the chip. It
turned out the 5P49V6901 clock generator stopped its output for a short
period of time during the VC5_OUT_DIV_CONTROL register writing. The same
problem was found for the 5P49V6965 revision of the chip and was
successfully fixed in commit fc336ae622 ("clk: vc5: fix output disabling
when enabling a FOD") by enabling the "bypass_sync" flag hidden inside
"Unused Factory Reserved Register". Even though the 5P49V6901 registers
description and programming guide doesn't provide any intel regarding that
flag, setting it up anyway in the officially unused register completely
eliminated the denoted glitches. Thus let's activate the functionality
submitted in commit fc336ae622 ("clk: vc5: fix output disabling when
enabling a FOD") for the Renesas 5P49V6901 chip too in order to remove the
ports implicit inter-dependency.
Fixes: dbf6b16f56 ("clk: vc5: Add support for IDT VersaClock 5P49V6901")
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Reviewed-by: Luca Ceresoli <luca@lucaceresoli.net>
Link: https://lore.kernel.org/r/20220929225402.9696-2-Sergey.Semin@baikalelectronics.ru
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Yuan Can says:
====================
This series contains two cleanup patches, remove unused struct.
====================
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
After commit 9b190f185d ("tools/bpftool: switch map event_pipe to
libbpf's perf_buffer"), struct event_ring_info is not used any more and
can be removed as well.
Signed-off-by: Yuan Can <yuancan@huawei.com>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/bpf/20220928090440.79637-3-yuancan@huawei.com
After commit 2828d0d75b ("bpftool: Switch to libbpf's hashmap for
programs/maps in BTF listing"), struct btf_attach_point is not used
anymore and can be removed as well.
Signed-off-by: Yuan Can <yuancan@huawei.com>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/bpf/20220928090440.79637-2-yuancan@huawei.com
switch to common helper to initialize rlc firmware
for gfx11
Signed-off-by: Hawking Zhang <Hawking.Zhang@amd.com>
Acked-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
To initialzie rlc firmware according to rlc
firmware header version
v2: squash in backwards compat fix
Signed-off-by: Hawking Zhang <Hawking.Zhang@amd.com>
Acked-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
To initialize rlc firmware in header v2_4
Signed-off-by: Hawking Zhang <Hawking.Zhang@amd.com>
Acked-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
To initialize rlc firmware in header v2_3
Signed-off-by: Hawking Zhang <Hawking.Zhang@amd.com>
Acked-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
To initialize rlc firmware in header v2_2
Signed-off-by: Hawking Zhang <Hawking.Zhang@amd.com>
Acked-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
To initialize rlc firmware in header v2_1
Signed-off-by: Hawking Zhang <Hawking.Zhang@amd.com>
Acked-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
To initialize rlc firmware in header v2_0
Signed-off-by: Hawking Zhang <Hawking.Zhang@amd.com>
Acked-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
dev_err() can be replace with dev_err_probe() which will check if error
code is -EPROBE_DEFER.
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Link: https://lore.kernel.org/r/20220913032228.985852-1-yangyingliang@huawei.com
Reviewed-by: David Lechner <david@lechnology.com>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
While creating a patch submission on the davinci clock drivers, I noticed
that the header file include/linux/clk/davinci.h belongs to the section
TI DAVINCI SERIES CLOCK DRIVER.
Add a file entry for this header file in TI DAVINCI SERIES CLOCK DRIVER.
Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
Link: https://lore.kernel.org/r/20220720110026.9173-1-lukas.bulwahn@gmail.com
Reviewed-by: David Lechner <david@lechnology.com>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
The PXA168 has a peculiar setup with the AXI clock enable control for
the SDHC controllers. The bits in the SDH0 register control the AXI
clock enable for both SDH0 and SDH1. Likewise, the bits in the SDH2
register control both SDH2 and SDH3. This is modeled with two new
parentless clocks that control the shared bits.
Previously, SDH0 had to be enabled in order for SDH1 to be used, and
when SDH1 was enabled, unused bits in the SDH1 register were being
controlled. This fixes those issues. A future commit will add support
for these new shared clocks to be enabled by the PXA168 SDHC driver.
Signed-off-by: Doug Brown <doug@schmorgal.com>
Link: https://lore.kernel.org/r/20220612192937.162952-13-doug@schmorgal.com
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
There are four SDHC peripherals on the PXA168, but only three of them
were present in the DT bindings. This commit adds the fourth.
Signed-off-by: Doug Brown <doug@schmorgal.com>
Link: https://lore.kernel.org/r/20220612192937.162952-10-doug@schmorgal.com
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
According to the datasheet, only bit 0 of APBC_GPIO should be controlled
for the clock enable. Bit 1 is marked as reserved (always write 0).
Signed-off-by: Doug Brown <doug@schmorgal.com>
Link: https://lore.kernel.org/r/20220612192937.162952-9-doug@schmorgal.com
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Xin Liu
Fabien Parent
Markus Schneider-Pargmann
Colin Ian King
Deming Wang
Andy Shevchenko
Dom Cobley
Ivan T. Ivanov
Stefan Wahren
Maxime Ripard
Dmitry Torokhov
Serge Semin
Daniel Vetter
Andrii Nakryiko
Yuan Can
Hawking Zhang
Yang Yingliang
Jiangshan Yi
Lukas Bulwahn
Dave Thaler
Doug Brown