* [PATCH v3 4/6] regulator: mt6359: const-ify regulator descriptions
From: Chen-Yu Tsai @ 2026-05-12 8:53 UTC (permalink / raw)
To: Mark Brown, Liam Girdwood, Lee Jones, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno
Cc: Chen-Yu Tsai, linux-arm-kernel, linux-mediatek, devicetree
In-Reply-To: <20260512085358.1693208-1-wenst@chromium.org>
The regulator descriptions and extended descriptions don't change at
runtime. The only reason they are not const is that the regulator
driver data is non-const.
Const-ify the descriptions and all references to them. For the driver
data, explicitly cast it to non-const void *.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
---
drivers/regulator/mt6359-regulator.c | 19 ++++++++++---------
1 file changed, 10 insertions(+), 9 deletions(-)
diff --git a/drivers/regulator/mt6359-regulator.c b/drivers/regulator/mt6359-regulator.c
index c8a788858824..bcf9a476a34e 100644
--- a/drivers/regulator/mt6359-regulator.c
+++ b/drivers/regulator/mt6359-regulator.c
@@ -251,7 +251,7 @@ static int mt6359_get_status(struct regulator_dev *rdev)
{
int ret;
u32 regval;
- struct mt6359_regulator_info *info = rdev_get_drvdata(rdev);
+ const struct mt6359_regulator_info *info = rdev_get_drvdata(rdev);
ret = regmap_read(rdev->regmap, info->status_reg, ®val);
if (ret != 0) {
@@ -267,7 +267,7 @@ static int mt6359_get_status(struct regulator_dev *rdev)
static unsigned int mt6359_regulator_get_mode(struct regulator_dev *rdev)
{
- struct mt6359_regulator_info *info = rdev_get_drvdata(rdev);
+ const struct mt6359_regulator_info *info = rdev_get_drvdata(rdev);
int ret, regval;
ret = regmap_read(rdev->regmap, info->modeset_reg, ®val);
@@ -299,7 +299,7 @@ static unsigned int mt6359_regulator_get_mode(struct regulator_dev *rdev)
static int mt6359_regulator_set_mode(struct regulator_dev *rdev,
unsigned int mode)
{
- struct mt6359_regulator_info *info = rdev_get_drvdata(rdev);
+ const struct mt6359_regulator_info *info = rdev_get_drvdata(rdev);
int ret = 0, val;
int curr_mode;
@@ -354,7 +354,7 @@ static int mt6359_regulator_set_mode(struct regulator_dev *rdev,
static int mt6359p_vemc_set_voltage_sel(struct regulator_dev *rdev,
u32 sel)
{
- struct mt6359_regulator_info *info = rdev_get_drvdata(rdev);
+ const struct mt6359_regulator_info *info = rdev_get_drvdata(rdev);
int ret;
u32 val = 0;
@@ -393,7 +393,7 @@ static int mt6359p_vemc_set_voltage_sel(struct regulator_dev *rdev,
static int mt6359p_vemc_get_voltage_sel(struct regulator_dev *rdev)
{
- struct mt6359_regulator_info *info = rdev_get_drvdata(rdev);
+ const struct mt6359_regulator_info *info = rdev_get_drvdata(rdev);
int ret;
u32 val = 0;
@@ -469,7 +469,7 @@ static const struct regulator_ops mt6359p_vemc_ops = {
};
/* The array is indexed by id(MT6359_ID_XXX) */
-static struct mt6359_regulator_info mt6359_regulators[] = {
+static const struct mt6359_regulator_info mt6359_regulators[] = {
MT6359_BUCK("buck_vs1", VS1, 800000, 2200000, 12500,
MT6359_RG_BUCK_VS1_EN_ADDR,
MT6359_DA_VS1_EN_ADDR, MT6359_RG_BUCK_VS1_VOSEL_ADDR,
@@ -705,7 +705,7 @@ static struct mt6359_regulator_info mt6359_regulators[] = {
MT6359_RG_LDO_VSRAM_OTHERS_SSHUB_VOSEL_SHIFT),
};
-static struct mt6359_regulator_info mt6359p_regulators[] = {
+static const struct mt6359_regulator_info mt6359p_regulators[] = {
MT6359_BUCK("buck_vs1", VS1, 800000, 2200000, 12500,
MT6359_RG_BUCK_VS1_EN_ADDR,
MT6359_DA_VS1_EN_ADDR, MT6359_RG_BUCK_VS1_VOSEL_ADDR,
@@ -950,7 +950,7 @@ static int mt6359_regulator_probe(struct platform_device *pdev)
struct mt6397_chip *mt6397 = dev_get_drvdata(pdev->dev.parent);
struct regulator_config config = {};
struct regulator_dev *rdev;
- struct mt6359_regulator_info *mt6359_info;
+ const struct mt6359_regulator_info *mt6359_info;
int i, hw_ver, ret;
ret = regmap_read(mt6397->regmap, MT6359P_HWCID, &hw_ver);
@@ -965,7 +965,8 @@ static int mt6359_regulator_probe(struct platform_device *pdev)
config.dev = mt6397->dev;
config.regmap = mt6397->regmap;
for (i = 0; i < MT6359_MAX_REGULATOR; i++, mt6359_info++) {
- config.driver_data = mt6359_info;
+ /* drop const here, but all uses in the driver are const */
+ config.driver_data = (void *)mt6359_info;
rdev = devm_regulator_register(&pdev->dev, &mt6359_info->desc, &config);
if (IS_ERR(rdev)) {
dev_err(&pdev->dev, "failed to register %s\n", mt6359_info->desc.name);
--
2.54.0.563.g4f69b47b94-goog
^ permalink raw reply related
* Re: [PATCH v5 8/8] unwind: arm64: Use sframe to unwind interrupt frames
From: Mark Rutland @ 2026-05-12 10:18 UTC (permalink / raw)
To: Jens Remus
Cc: Dylan Hatch, Roman Gushchin, Weinan Liu, Will Deacon,
Josh Poimboeuf, Indu Bhagat, Peter Zijlstra, Steven Rostedt,
Catalin Marinas, Jiri Kosina, Prasanna Kumar T S M,
Puranjay Mohan, Song Liu, joe.lawrence, linux-toolchains,
linux-kernel, live-patching, linux-arm-kernel, Randy Dunlap,
Heiko Carstens
In-Reply-To: <0542f042-14fb-4588-bc3a-5031249d9834@linux.ibm.com>
On Tue, May 12, 2026 at 10:55:28AM +0200, Jens Remus wrote:
> On 5/12/2026 5:00 AM, Dylan Hatch wrote:
> > On Fri, May 1, 2026 at 9:46 AM Mark Rutland <mark.rutland@arm.com>
> > wrote:
>
> >> (1) For correctness, we'll need to address a latent issue with
> >> unwinding across an fgraph return trampoline, where the return
> >> address is transiently unrecoverable.
> >> I think we can solve that with some restructuring of that code,
> >> restoring the original address *before* removing that from the
> >> fgraph return stack, and ensuring that the unwinder can find it.
> >
> > If my understanding is correct, the issue arrises in
> > return_to_handler as the return address is recovered:
> >
> > mov x0, sp bl ftrace_return_to_handler // addr =
> > ftrace_return_to_hander(fregs); mov x30, x0 // restore the original
> > return address
> >
> > Because ftrace_return_to_handler pops the return address from the
> > return stack before it can be restored into the LR, it cannot be
> > recovered.
>
> Based on reliable-stacktrace.rst section "4.4 Rewriting of return
> addresses" I wonder whether the following might work:
>
> - If an unwound RA points at return_to_handler the actual RA needs to
> be obtained using ftrace_graph_ret_addr(). This might already be
> taken into account if ftrace_graph_ret_addr() is used unconditionally.
>
> - If an unwound RA points into return_to_handler() mark the stack trace
> as unreliable. This could be accomplished by marking LR in
> return_to_handler() as undefined (i.e. .cfi_undefined 30) to use
> SFrame's outermost frame indication to stop and mark the stack trace
> as unreliable:
We don't currently have any CFI annotations for return_to_handler(), so
if we interrupt that, any unwind will naturally be marked as unreliable.
The problem is that we can try an unwind from an interrupted *callee* of
return_to_handler(). In that case, we'll unwind through
return_to_handler() using the frame pointer, without consulting SFrame.
In that case, the PC will be part-way through return_to_handler(), but
we only call ftrace_graph_ret_addr() when the PC is the start of
return_to_handler, and so we don't even try to recover the return
address.
We can handle that better by checking whether the PC is *within*
return_to_handler(), and aborting when the original return address
cannot be recoverted. I'm happy to go put that together, nad longer term
I would like to do the better reovery I described above such that we can
*always* recover the return address.
Mark.
^ permalink raw reply
* Re: [PATCH net-next 1/2] net: ti: icssg: Derive stats array lengths from ARRAY_SIZE
From: David CARLIER @ 2026-05-12 10:03 UTC (permalink / raw)
To: MD Danish Anwar
Cc: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Jonathan Corbet, Shuah Khan, Roger Quadros,
Andrew Lunn, Jacob Keller, Meghana Malladi, Kevin Hao,
Vadim Fedorenko, netdev, linux-doc, linux-kernel,
linux-arm-kernel, Vignesh Raghavendra
In-Reply-To: <6a1f411c-d7ed-463b-abf1-277d8cc0c184@ti.com>
Hi Danish,
On Tue, 12 May 2026 at 10:40, MD Danish Anwar <danishanwar@ti.com> wrote:
>
> Hi David,
>
> On 12/05/26 1:28 pm, David CARLIER wrote:
> > Hi MD,
> >
> > On Tue, 12 May 2026 at 07:06, MD Danish Anwar <danishanwar@ti.com> wrote:
> >>
> >> Replace the manually maintained ICSSG_NUM_MIIG_STATS and
> >> ICSSG_NUM_PA_STATS constants with ARRAY_SIZE() expressions derived
> >> directly from the corresponding stat descriptor arrays, so that adding
> >> new entries to icssg_all_miig_stats[] or icssg_all_pa_stats[] no longer
> >> requires a separate update to a numeric constant.
> >>
> >> To make this self-contained, break the circular include dependency
> >> between icssg_stats.h and icssg_prueth.h:
> >>
> >> - icssg_stats.h previously included icssg_prueth.h (transitively
> >> pulling in icssg_switch_map.h and ETH_GSTRING_LEN). Replace that
> >> with direct includes of <linux/ethtool.h>, <linux/kernel.h> and
> >> "icssg_switch_map.h".
> >>
> >> - icssg_prueth.h now includes icssg_stats.h, giving it access to
> >> the ARRAY_SIZE-based ICSSG_NUM_MIIG_STATS and ICSSG_NUM_PA_STATS
> >> before they are used in the prueth_emac struct and ICSSG_NUM_STATS.
> >>
> >> Signed-off-by: MD Danish Anwar <danishanwar@ti.com>
> >> ---
> >> drivers/net/ethernet/ti/icssg/icssg_prueth.h | 3 +--
> >> drivers/net/ethernet/ti/icssg/icssg_stats.h | 7 ++++++-
> >> 2 files changed, 7 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/drivers/net/ethernet/ti/icssg/icssg_prueth.h b/drivers/net/ethernet/ti/icssg/icssg_prueth.h
> >> index df93d15c5b78..e2ccecb0a0dd 100644
> >> --- a/drivers/net/ethernet/ti/icssg/icssg_prueth.h
> >> +++ b/drivers/net/ethernet/ti/icssg/icssg_prueth.h
> >> @@ -43,6 +43,7 @@
> >>
> >> #include "icssg_config.h"
> >> #include "icss_iep.h"
> >> +#include "icssg_stats.h"
> >> #include "icssg_switch_map.h"
> >>
> >> #define PRUETH_MAX_MTU (2000 - ETH_HLEN - ETH_FCS_LEN)
> >> @@ -57,8 +58,6 @@
> >>
> >> #define ICSSG_MAX_RFLOWS 8 /* per slice */
> >>
> >> -#define ICSSG_NUM_PA_STATS 32
> >> -#define ICSSG_NUM_MIIG_STATS 60
> >> /* Number of ICSSG related stats */
> >> #define ICSSG_NUM_STATS (ICSSG_NUM_MIIG_STATS + ICSSG_NUM_PA_STATS)
> >> #define ICSSG_NUM_STANDARD_STATS 31
> >> diff --git a/drivers/net/ethernet/ti/icssg/icssg_stats.h b/drivers/net/ethernet/ti/icssg/icssg_stats.h
> >> index 5ec0b38e0c67..b854eb587c1e 100644
> >> --- a/drivers/net/ethernet/ti/icssg/icssg_stats.h
> >> +++ b/drivers/net/ethernet/ti/icssg/icssg_stats.h
> >> @@ -8,10 +8,15 @@
> >> #ifndef __NET_TI_ICSSG_STATS_H
> >> #define __NET_TI_ICSSG_STATS_H
> >>
> >> -#include "icssg_prueth.h"
> >> +#include <linux/ethtool.h>
> >> +#include <linux/kernel.h>
> >> +#include "icssg_switch_map.h"
> >>
> >> #define STATS_TIME_LIMIT_1G_MS 25000 /* 25 seconds @ 1G */
> >>
> >> +#define ICSSG_NUM_MIIG_STATS ARRAY_SIZE(icssg_all_miig_stats)
> >> +#define ICSSG_NUM_PA_STATS ARRAY_SIZE(icssg_all_pa_stats)
> >> +
> >> struct miig_stats_regs {
> >> /* Rx */
> >> u32 rx_packets;
> >> --
> >> 2.34.1
> >>
> >
> > One thing that caught my eye: icssg_all_miig_stats[] and
> > icssg_all_pa_stats[] are 'static const' arrays in icssg_stats.h with
> > ETH_GSTRING_LEN name buffers per entry. Right now only icssg_stats.c
> > and icssg_ethtool.c pull them in. After this patch icssg_prueth.h
> > includes icssg_stats.h, so every .c in the driver (classifier,
> > common, config, mii_cfg, queues, switchdev, ...) ends up with its own
> > static-const copy of both tables.
> >
> > Would a static_assert() work for what you're after? Something like:
> >
>
> While adding more stats manually, The ARRAY_SIZE() approach was
> explicitly requested by maintainer [1]:
>
> This patch is a direct response to that feedback. static_assert() would
> still require updating the numeric constant on every array change. The
> goal here is to eliminate the need of manually incrementing stats count
> whenever new stats are added
>
> Your concern about multiple copies of table is noted and valid. Could
> you advise on the preferred way to reconcile these two requirements? I
> am happy to restructure if there is an approach that satisfies both.
>
> [1]
> https://lore.kernel.org/all/20260112181436.4s5ceywwembn674r@skbuf/#:~:text=Can%27t%20this%20be%20expressed%20as%20ARRAY_SIZE(icssg_all_pa_stats)%3F%20It%20is%20very%0Afragile%20to%20have%20to%20count%20and%20update%20this%20manually.
>
>
> > static const struct icssg_miig_stats icssg_all_miig_stats[] = {
> > ...
> > };
> > static_assert(ARRAY_SIZE(icssg_all_miig_stats) == ICSSG_NUM_MIIG_STATS);
> >
> > next to each array, keeping the numeric #defines as-is. Then 2/2 fails
> > to build the moment a new entry is added without bumping the count,
> > which is the case you're guarding against — without touching the
> > include graph.
> >
> > What do you think ?
> >
> > Cheers.
>
> --
> Thanks and Regards,
> Danish
>
Thanks for digging up the context — fair point, I'd missed Vladimir's
earlier ask. Reading it again though, what he calls fragile is the
silent miscount, not the keystroke of typing a number. A static_assert
turns "forgot to bump" into a build error, which I think gets you
there.
What about moving the two arrays into icssg_stats.c, declaring them
extern in the header, and dropping a static_assert next to each
definition? Numeric #defines stay where they are, icssg_prueth.h
doesn't need to know about icssg_stats.h, and the tables live in one
TU instead of every .o in the driver. If the count and the array
disagree, you get a compile error on the spot.
Probably worth keeping Vladimir on Cc for v2 in case he had something
else in mind.
Cheers,
^ permalink raw reply
* Re: [PATCH v4 2/2] arm64: dts: imx8dxl: Add SolidRun SoM and HummingBoard
From: Josua Mayer @ 2026-05-12 10:27 UTC (permalink / raw)
To: Andrew Lunn, Vladimir Oltean
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Vladimir Oltean, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Yazan Shhady, Mikhail Anikin, Alexander Dahl,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
imx@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
Conor Dooley, Krzysztof Kozlowski, netdev@vger.kernel.org
In-Reply-To: <557f7332-42b4-49eb-85ea-76d141a2150f@lunn.ch>
Hi Andrew,
Am 11.05.26 um 15:29 schrieb Andrew Lunn:
> On Mon, May 11, 2026 at 02:24:38PM +0300, Vladimir Oltean wrote:
>> On Mon, May 11, 2026 at 12:11:31PM +0200, Josua Mayer wrote:
>>> +&eqos {
>>> + /* delays are added by connected ethernet-switch cpu port */
>>> + phy-mode = "rgmii";
> For ethernet-phy combinations i'm pretty strict, but i'm more
> forgiving when switches are involved.
>
> If rx/tx-internal-delays-ps work, that would be better, but i'm
> willing to accept this, with the comment in place.
Only some stmmac driver variants handle delays, dwmac-imx is not one
of them. it cares neither for phy-mode nor rx/tx-internal-delay-ps.
So I wouldn't mind putting instead
phy-mode = "rgmii-id";
rx-internal-delay-ps = <0>;
tx-internal-delay-ps = <0>;
with the same comment, as long as it is more correct.
^ permalink raw reply
* Re: [PATCH v6 08/25] KVM: arm64: iommu: Shadow host stage-2 page table
From: Mostafa Saleh @ 2026-05-12 10:42 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: linux-arm-kernel, linux-kernel, kvmarm, iommu, catalin.marinas,
will, maz, oliver.upton, joey.gouly, suzuki.poulose, yuzenghui,
joro, jean-philippe, mark.rutland, qperret, tabba, vdonnefort,
sebastianene, keirf
In-Reply-To: <20260511142232.GP9285@ziepe.ca>
On Mon, May 11, 2026 at 11:22:32AM -0300, Jason Gunthorpe wrote:
> On Mon, May 11, 2026 at 11:24:14AM +0000, Mostafa Saleh wrote:
> > On Sat, May 09, 2026 at 08:27:14PM -0300, Jason Gunthorpe wrote:
> > > On Mon, May 04, 2026 at 12:28:55PM +0000, Mostafa Saleh wrote:
> > > > So far this is the list of requirements/changes needed share the
> > > > stage-2 page table (besides the obvious: same page table format,
> > > > granularity, endianness...)
> > > >
> > > > 1) HW BBM is not supported in the hypervisor page table, that’s
> > > > because it can generate TLB conflict aborts, which the hypervisor
> > > > can not handle because of the limited syndrome information.
> > > > We can rely on FEAT_BBML3 which was newly introduced to work
> > > > around that, it’s quite niche and not supported in KVM yet or
> > > > have an allow list similar to the kernel
> > > > (as in cpu_supports_bbml2_noabort()) which also limits the number
> > > > of CPUs that can run this.
> > >
> > > Do you think pkvm will need BBM? Hitless replace of a PTE is already a
> > > pretty advanced feature and the SMMU has its own support matrix there
> > > too. Is it for shared/private conversion?
> >
> > Yes, we can break block on memory donation which is transfer of
> > ownership to the hypervisor or a guest.
>
> So you need BBM support on the SMMU too? That is probably a big
> problem because the SMMU is often mismatched to the CPU :\
>
Yes, that's why it's hard to find systems that can easily share the
CPU page table with the SMMU (some might even have mis-match in
OAS/PS)
> Also io-pgtable arm cannot trigger BBM behaviors, so how do you
> implement it?
At the moment, we workaround this by mapping all the memory with PTE
level, while MMIO remains at block level as they never change ownership
at the moment.
This is one of the missing features I plan to add after this series,
if you look in the cover letter, these are listed under “Future work”
>
> > > No.. once you turn on IO like this you don't have page faults
> > > anymore. Everything must be permantently mapped into the SMMU view, it
> > > can never be made non-present and you must run without page
> > > faults. That's what you have in the io-pgtable constructed table,
> > > right?
> >
> > Exactly, but the CPU page table doesn’t guarantee that, so we either
> > have to handle page faults in the IOMMU, or completely change how KVM
> > deals with stage-2 if we want to share the page table with the CPU.
>
> So that's the real explanation, KVM cannot manage the S2 in the right
> way so you can't share it. RMM/etc are managing the S2 without
> pointless page faults so they can share it.
Well, there is not really a right way, even with a fully populated
stage-2 page table, you can’t guarantee not getting TLB conflict aborts
without FEAT_BBML3 (which is quite recent), unless you map everything
with a leaf level, which then impacts performance.
Thanks,
Mostafa
>
> > > > Alternatively, we can pin the stage-2 pages, that would require some
> > > > hypercalls, hacks to the driver/IOMMU API and possibly new semantics
> > > > in the DMA-API for IDENTITY devices as they will still need to pin
> > > > the pages as they are actually in stage-2 translation and not bypass.
> > >
> > > ?? Then how does this series work?
> >
> > This series works fine as it shadows the page table and doesn't share it
> > with the CPU, so it fully populates the address space.
>
> Which is why it is so weird that KVM is using a partially populated S2
> when there is, and must, be a fully populated one for the SMMU. But I
> understand there are reasons fo rthis.
>
> Jason
^ permalink raw reply
* Re: [PATCH] arm64: dts: rockchip: fix emmc reset polarity on px30-cobra
From: Quentin Schulz @ 2026-05-12 10:47 UTC (permalink / raw)
To: Jakob Unterwurzacher, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Heiko Stuebner, Jakob Unterwurzacher
Cc: stable, Heiko Stuebner, devicetree, linux-arm-kernel,
linux-rockchip, linux-kernel
In-Reply-To: <20260512092225.34835-1-jakob.unterwurzacher@cherry.de>
Hi Jakob,
JFYI, the commit author will differ from the Signed-off-by (it's your
gmail address that is going to appear as author).
Usually, when the mail From address is different from the commit author,
there's a From: line as first line in the patch (which won't appear in
the commit once merged). See
https://lore.kernel.org/linux-rockchip/20260421-px30-eth-phy-v2-1-68c375b120fd@cherry.de/
for an example. Not sure what's happening with your setup :)
On 5/12/26 11:22 AM, Jakob Unterwurzacher wrote:
> Technically, the reset signal is active low - it's called RST_n after all.
>
> But it is ignored completely unless RST_n_FUNCTION=1 (byte 162 in extcsd)
> is set in the emmc. It is 0 per default.
>
> For emmcs that have RST_n_FUNCTION=1 we failed like this:
>
> [ 3.074480] mmc1: Failed to initialize a non-removable card
>
> With this change they work normally.
>
> Cc: stable@vger.kernel.org
> Fixes: bb510ddc9d3e ("arm64: dts: rockchip: add px30-cobra base dtsi and board variants")
This also matches the Device Tree bindings for eMMC MMC pwrseq devices,
c.f.
https://elixir.bootlin.com/linux/v7.0.5/source/Documentation/devicetree/bindings/mmc/mmc-pwrseq-emmc.yaml#L33
Looking at their respective schematics and Device Tree, I think we also
have the same issue on our Jaguar, PP-1516, Ringneck and Tiger, would
you be so kind and check I read the schematics properly and send patches
for those as well?
@Heiko, I've checked and it seems like (in addition to Jaguar, PP-1516,
Ringneck and Tiger):
arch/arm/boot/dts/rockchip/rk3288-veyron.dtsi
arch/arm64/boot/dts/rockchip/rk3368-r88.dts
arch/arm64/boot/dts/rockchip/rk3368-orion-r68-meta.dts
arch/arm64/boot/dts/rockchip/rk3368-evb.dtsi
arch/arm64/boot/dts/rockchip/px30-firefly-jd4-core.dtsi
arch/arm64/boot/dts/rockchip/px30-evb.dts
all have that wrong polarity (though, without access to the schematics,
who knows if it's really supposed to be inverted polarity (e.g. because
it's inverted via a transistor)).
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Thanks!
Quentin
^ permalink raw reply
* Re: [PATCH v2] clk: keystone: don't cache clock rate
From: Nishanth Menon @ 2026-05-12 10:48 UTC (permalink / raw)
To: Brian Masney
Cc: a-christidis, Tero Kristo, Santosh Shilimkar, Michael Turquette,
Stephen Boyd, linux-arm-kernel, linux-kernel, linux-clk,
Michael Walle, Kevin Hilman, Randolph Sapp
In-Reply-To: <agHpYnkCgGfZp2-E@redhat.com>
On 10:36-20260511, Brian Masney wrote:
> On Thu, May 07, 2026 at 11:09:34AM -0500, a-christidis@ti.com wrote:
> > From: Michael Walle <mwalle@kernel.org>
> >
> > The TISCI firmware will return 0 if the clock or consumer is not
> > enabled although there is a stored value in the firmware. IOW a call to
> > set rate will work but at get rate will always return 0 if the clock is
> > disabled.
> > The clk framework will try to cache the clock rate when it's requested
> > by a consumer. If the clock or consumer is not enabled at that point,
> > the cached value is 0, which is wrong. Thus, disable the cache
> > altogether.
> >
> > Signed-off-by: Michael Walle <mwalle@kernel.org>
> > Reviewed-by: Kevin Hilman <khilman@baylibre.com>
> > Reviewed-by: Randolph Sapp <rs@ti.com>
> > Reviewed-by: Nishanth Menon <nm@ti.com>
> > Signed-off-by: Antonios Christidis <a-christidis@ti.com>
>
> Reviewed-by: Brian Masney <bmasney@redhat.com>
>
Brian,
Could you clarify if I need to take it via my tree to arnd or if this
patch will go via the clk tree?
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
https://ti.com/opensource
^ permalink raw reply
* Re: [PATCH 2/2] drm/verisilicon: add support for Nuvoton MA35D1 DCUltra Lite display controller
From: Joey Lu @ 2026-05-12 10:59 UTC (permalink / raw)
To: Icenowy Zheng, maarten.lankhorst, mripard, tzimmermann, airlied,
simona, robh, krzk+dt, conor+dt
Cc: ychuang3, schung, yclu4, dri-devel, devicetree, linux-arm-kernel,
linux-kernel
In-Reply-To: <4bf6efbb222ebc4d770ad613d17c6185e7cb2fda.camel@iscas.ac.cn>
On 5/12/2026 6:01 PM, Icenowy Zheng wrote:
> 在 2026-05-12二的 17:06 +0800，Joey Lu写道：
>
> ======= 8< =============
>>>>>> diff --git a/drivers/gpu/drm/verisilicon/vs_bridge.c
>>>>>> b/drivers/gpu/drm/verisilicon/vs_bridge.c
>>>>>> index 7a93049368db..225af322de32 100644
>>>>>> --- a/drivers/gpu/drm/verisilicon/vs_bridge.c
>>>>>> +++ b/drivers/gpu/drm/verisilicon/vs_bridge.c
>>>>>> @@ -164,13 +164,16 @@ static void
>>>>>> vs_bridge_enable_common(struct
>>>>>> vs_crtc *crtc,
>>>>>> VSDC_DISP_PANEL_CONFIG_CLK_EN);
>>>>>> regmap_set_bits(dc->regs,
>>>>>> VSDC_DISP_PANEL_CONFIG(output),
>>>>>> VSDC_DISP_PANEL_CONFIG_RUNNING);
>>>>>> - regmap_clear_bits(dc->regs, VSDC_DISP_PANEL_START,
>>>>>> -
>>>>>> VSDC_DISP_PANEL_START_MULTI_DISP_SYNC);
>>>>>> - regmap_set_bits(dc->regs, VSDC_DISP_PANEL_START,
>>>>>> -
>>>>>> VSDC_DISP_PANEL_START_RUNNING(output));
>>>>>>
>>>>>> - regmap_set_bits(dc->regs,
>>>>>> VSDC_DISP_PANEL_CONFIG_EX(crtc-
>>>>>>> id),
>>>>>> - VSDC_DISP_PANEL_CONFIG_EX_COMMIT);
>>>>>> + if (dc->info->has_config_ex) {
>>>>>> + regmap_clear_bits(dc->regs,
>>>>>> VSDC_DISP_PANEL_START,
>>>>>> +
>>>>>> VSDC_DISP_PANEL_START_MULTI_DISP_SYNC);
>>>>>> + regmap_set_bits(dc->regs,
>>>>>> VSDC_DISP_PANEL_START,
>>>>>> + VSDC_DISP_PANEL_START_RUNNIN
>>>>>> G(ou
>>>>>> tput
>>>>>> ));
>>>>>> +
>>>>>> + regmap_set_bits(dc->regs,
>>>>>> VSDC_DISP_PANEL_CONFIG_EX(crtc->id),
>>>>>> + VSDC_DISP_PANEL_CONFIG_EX_CO
>>>>>> MMIT
>>>>>> );
>>>>> Should the commit operation happen on DC8000/DCUltraLite too?
>>>>> (By
>>>>> writing to DcregFrameBufferConfig0.VALID).
>>>>>
>>>>> Many registers written has "Note: This field is double
>>>>> buffered" in
>>>>> the
>>>>> DCUltraLite documentation.
>>>>>
>>>>> I suggest create a static function for commit -- write to the
>>>>> corresponding commit bit on DC8200, and write to
>>>>> DcregFrameBufferConfig0.VALID on DC8000/DCUltraLite.
>>>> [a] There is no commit operation for DCUltra Lite.
>>>> I'll not add a `VSDC_FB_CONFIG_VALID` macro. VALID (BIT(3)) is a
>>>> hardware-managed double-buffer status bit: hardware writes
>>>> 1=PENDING
>>>> when a new register set is ready and clears to 0=WORKING after
>>>> the
>>>> VBLANK copy. Software must never write it, and there is no
>>>> polling
>>>> use
>>> It seems to be writable and controls whether register buffering is
>>> enabled, see [1].
>>>
>>> The description of this bit in MA35D1 TRM says "This ensures a
>>> frame
>>> will always start with a valid working set if this register is
>>> programmed last, which reduces the need for SW to wait for the
>>> start of
>>> a VBLANK signal in order to ensure all states are loaded before the
>>> next VBLANK", which indicates some kind of "committing write",
>>> although
>>> the code at [1] seems to indicate that double buffering is only
>>> enabled
>>> when bit is cleared.
>>>
>>> Anyway this bit should be programmable, and "Software must never
>>> write
>>> it" contradicts with the MA35D1 TRM.
>>>
>>> Thanks,
>>> Icenowy
>>>
>>> [1]
>>> https://github.com/rockos-riscv/rockos-kernel/blob/rockos-v6.6.y/drivers/gpu/drm/eswin/es_dc_hw.c#L993
>> Thank you for the correction. I'll add
>> `#define VSDC_FB_CONFIG_VALID BIT(3)` to vs_primary_plane_regs.h and
>> write it in `vs_primary_plane_commit()` for non-config_ex variants.
>>>> case in the driver that requires a named constant. For non-
>>>> config_ex
>>>> variants, `vs_primary_plane_commit()` performs no commit
>>>> operation —
>>>> `VSDC_FB_CONFIG_ENABLE` (OUTPUT, BIT(0)) is set in
>>>> `vs_crtc_atomic_enable()` and `VSDC_FB_CONFIG_RESET` (BIT(4)) is
>>>> set/cleared in the bridge enable/disable paths.
> Well according to the driver code for DC8000 from Eswin, and the bit
> named "VALID", maybe it should be cleared before programming the
> registers, and set after programming registers, to make the process of
> programming registers atomic from the perspective of the display
> controller.
>
> Anyway this should require testing on real hardware to verify.
>
> By the way, I see multiple peripheral drivers for MA35D1 get applied in
> the torvalds tree, but the device tree is still only a skeleton; when
> will the device tree be updated?
>
> Thanks,
> Icenowy
Thanks for pointing this out. I’ll perform tests on real hardware since
I haven’t used this bit before.
As for the device tree, we plan to update it comprehensively after
completing several major IPs, with the goal of releasing the update
later this year.
>>> ========= 8< ==========
>>>
^ permalink raw reply
* Re: [PATCH v3 0/3] iio: adc: xilinx-ams: refactor alarm handling to table-driven design
From: Guilherme Ivo Bozi @ 2026-05-12 11:00 UTC (permalink / raw)
To: Jonathan Cameron
Cc: Salih Erim, Conall O'Griofa, Michal Simek, David Lechner,
Nuno Sá, Andy Shevchenko, linux-iio, linux-arm-kernel,
linux-kernel
In-Reply-To: <20260425163449.547b7ed9@jic23-huawei>
> This series looks fine to me.
>
> Given the AMD Xilinx folk are fairly active reviewers I'm just
> waiting on them taking a look.
Hi, just checking in on this series since it’s been some time.
Any updates from AMD Xilinx review or anything else needed from
my side?
--
Thanks,
Guilherme Ivo
^ permalink raw reply
* [PATCH V2] clk: keystone: sci-clk: fix application of sizeof to pointer
From: Nishanth Menon @ 2026-05-12 11:00 UTC (permalink / raw)
To: Brian Masney, Stephen Boyd, Michael Turquette
Cc: Santosh Shilimkar, Tero Kristo, Nishanth Menon, linux-clk,
linux-kernel, linux-arm-kernel, afd, sozdayvek, Jing Yangyang,
Zeal Robot, kernel test robot, Julia Lawall, David Yang
From: Jing Yangyang <jing.yangyang@zte.com.cn>
Coccinelle (scripts/coccinelle/misc/noderef.cocci) reports:
drivers/clk/keystone/sci-clk.c:391:8-14: ERROR: application of
sizeof to pointer
In sci_clk_get(), 'clk' is declared as 'struct sci_clk **', so
sizeof(clk) is sizeof(struct sci_clk **) which is the size of a
pointer rather than the size of an array element. provider->clocks
is an array of 'struct sci_clk *', so the canonical size argument
to bsearch() is sizeof(*clk) (i.e. sizeof(struct sci_clk *)).
The two values are equal on every supported architecture, so this
is correctness/idiom, not a runtime fix, but the new form matches
the rest of the bsearch() callers in the tree and silences the
Coccinelle warning the script flagged.
Reported-by: Zeal Robot <zealci@zte.com.cn>
Closes: https://lore.kernel.org/all/84a6ba16686347099a3dab2e5161a930e792eb6e.1629198281.git.jing.yangyang@zte.com.cn/
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Julia Lawall <julia.lawall@inria.fr>
Closes: https://lore.kernel.org/all/202512040525.zrHSDl5h-lkp@intel.com/
Link: https://lore.kernel.org/linux-clk/20211012021931.176727-1-davidcomponentone@gmail.com/
Reviewed-by: Stepan Ionichev <sozdayvek@gmail.com>
Reviewed-by: Andrew Davis <afd@ti.com>
Signed-off-by: Jing Yangyang <jing.yangyang@zte.com.cn>
Signed-off-by: David Yang <davidcomponentone@gmail.com>
[nm@ti.com: Improved commit message]
Signed-off-by: Nishanth Menon <nm@ti.com>
---
Changes in V2:
- Picked up Stepan's suggestion on commit message
- Picked up Andrew and Stepan's reviewed-by
V1: https://lore.kernel.org/all/20260508152321.3683799-1-nm@ti.com/
drivers/clk/keystone/sci-clk.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/keystone/sci-clk.c b/drivers/clk/keystone/sci-clk.c
index 9d5071223f4c..2fc1f050779b 100644
--- a/drivers/clk/keystone/sci-clk.c
+++ b/drivers/clk/keystone/sci-clk.c
@@ -388,7 +388,7 @@ static struct clk_hw *sci_clk_get(struct of_phandle_args *clkspec, void *data)
key.clk_id = clkspec->args[1];
clk = bsearch(&key, provider->clocks, provider->num_clocks,
- sizeof(clk), _cmp_sci_clk);
+ sizeof(*clk), _cmp_sci_clk);
if (!clk)
return ERR_PTR(-ENODEV);
--
2.32.0
^ permalink raw reply related
* Re: [PATCH v3 0/3] iio: adc: xilinx-ams: refactor alarm handling to table-driven design
From: Michal Simek @ 2026-05-12 11:02 UTC (permalink / raw)
To: Guilherme Ivo Bozi, Jonathan Cameron
Cc: Salih Erim, Conall O'Griofa, David Lechner, Nuno Sá,
Andy Shevchenko, linux-iio, linux-arm-kernel, linux-kernel
In-Reply-To: <CAJgF-xv2SpaOu+6K6k3CzFVNfWTx8LyeGJMZjLheCSETOR3Yzg@mail.gmail.com>
Hi Ivo,
On 5/12/26 13:00, Guilherme Ivo Bozi wrote:
>> This series looks fine to me.
>>
>> Given the AMD Xilinx folk are fairly active reviewers I'm just
>> waiting on them taking a look.
> Hi, just checking in on this series since it’s been some time.
> Any updates from AMD Xilinx review or anything else needed from
> my side?
Checking internally who can test this. Please give me some time.
Thanks,
Michal
^ permalink raw reply
* Re: [PATCH v2 07/16] thermal: mediatek: add PMIC thermal support
From: Andy Shevchenko @ 2026-05-12 11:02 UTC (permalink / raw)
To: Roman Vivchar
Cc: Andy Shevchenko, Jonathan Cameron, David Lechner, Nuno Sá,
Andy Shevchenko, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Matthias Brugger, AngeloGioacchino Del Regno, Sen Chu, Sean Wang,
Macpaul Lin, Lee Jones, Srinivas Kandagatla, Rafael J. Wysocki,
Daniel Lezcano, Zhang Rui, Lukasz Luba, linux-iio, devicetree,
linux-kernel, linux-arm-kernel, linux-mediatek, linux-pm,
Ben Grisdale
In-Reply-To: <j2uhavC9edilBoD6VJnlz8cCmMPhE9rQavh1epqLk61zrlZ3k1rqlyj8fVYWnkddIY1fEfPk1DfcW09i39hd-Q7I9Y8Vxd0w8C2eCjVGLc4=@protonmail.com>
On Tue, May 12, 2026 at 08:55:44AM +0000, Roman Vivchar wrote:
> On Tuesday, May 12th, 2026 at 10:05 AM, Andy Shevchenko <andy.shevchenko@gmail.com> wrote:
> > On Tue, May 12, 2026 at 8:21 AM Roman Vivchar via B4 Relay
> > <devnull+rva333.protonmail.com@kernel.org> wrote:
...
> > > +#include <linux/kernel.h>
> >
> > No way the driver(s) nowadays use this header. Please, drop it and add
> > the ones that are really in use (there are missing ones).
>
> Is there a tool or script that can check for IWYU?
The `iwyu` tool with customised configuration is the closest what we have
(but quite far from ideal), you can read this thread [2].
> For example,
> the u32 and s32 types are defined in the asm-generic/int-ll64.h, which
> is not used by any device driver. Instead, types.h should be used.
> It's difficult to guess which header to use for a given type/function.
I know. I got this knowledge because:
- I do a lot of reviews and patches and gathered it from the experience
- I am the one who reshuffled *some* of the headers
> I've tried include-what-you-use [1], but it gives bad results like
> "add #include <asm-generic/int-ll64.h> // for u32".
See above.
> > > +#include <linux/module.h>
> > > +#include <linux/nvmem-consumer.h>
> > > +#include <linux/platform_device.h>
> > > +#include <linux/property.h>
> > > +#include <linux/regmap.h>
> >
> > > +#include <linux/slab.h>
> >
> > Is it used?
>
> Yes, without slab.h the __free would complain about missing __free_kfree,
> which is DEFINE_FREE(kfree, void *, if (!IS_ERR_OR_NULL(_T)) kfree(_T)).
Ah, indeed. I forgot that this is not the part of cleanup.h.
...
> 1: https://github.com/include-what-you-use/include-what-you-use
[2]: https://lore.kernel.org/all/20260512073505.1310-1-joshua.crofts1@gmail.com/
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v3 16/20] drm/mode-config: Create drm_mode_config_create_initial_state()
From: Maxime Ripard @ 2026-05-12 11:12 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Maarten Lankhorst, Thomas Zimmermann, David Airlie, Simona Vetter,
Jonathan Corbet, Shuah Khan, Dmitry Baryshkov, Jyri Sarha,
Tomi Valkeinen, Andrzej Hajda, Neil Armstrong, Robert Foss,
Jonas Karlman, Jernej Skrabec, Simon Ser, Harry Wentland,
Melissa Wen, Sebastian Wick, Alex Hung, Jani Nikula, Rodrigo Vivi,
Joonas Lahtinen, Tvrtko Ursulin, Chen-Yu Tsai, Samuel Holland,
Dave Stevenson, Maíra Canal, Raspberry Pi Kernel Maintenance,
dri-devel, linux-doc, linux-kernel, Daniel Stone, intel-gfx,
intel-xe, linux-arm-kernel, linux-sunxi
In-Reply-To: <20260504174148.GS1344263@killaraus.ideasonboard.com>
[-- Attachment #1: Type: text/plain, Size: 1029 bytes --]
On Mon, May 04, 2026 at 08:41:48PM +0300, Laurent Pinchart wrote:
> > Historically, this was one
> > + * of drm_mode_config_reset() job, so one might still encounter it in
> > + * a driver.
> > + *
> > + * - at reset time, for example during suspend/resume,
> > + * drm_mode_config_reset() will reset the software and hardware state
> > + * to a known default and will store it in the object's state pointer.
> > + * Not all objects are affected by drm_mode_config_reset() though.
>
> Does the reset implementation store a new state in the object's state
> pointer, or does it reset the contents of the already allocated state ?
> I read the documentation here as meaning the former, if it's actually
> the latter it should be reworded.
It's undefined. Both approach works, most drivers will destroy the old
one and allocate a new one, but mediatek will just clear and
re-initialize the old one:
https://elixir.bootlin.com/linux/v7.1-rc3/source/drivers/gpu/drm/mediatek/mtk_plane.c#L28
Maxime
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 273 bytes --]
^ permalink raw reply
* Re: [PATCH v3 18/20] drm/tidss: Switch to drm_mode_config_create_initial_state()
From: Maxime Ripard @ 2026-05-12 11:18 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Maarten Lankhorst, Thomas Zimmermann, David Airlie, Simona Vetter,
Jonathan Corbet, Shuah Khan, Dmitry Baryshkov, Jyri Sarha,
Tomi Valkeinen, Andrzej Hajda, Neil Armstrong, Robert Foss,
Jonas Karlman, Jernej Skrabec, Simon Ser, Harry Wentland,
Melissa Wen, Sebastian Wick, Alex Hung, Jani Nikula, Rodrigo Vivi,
Joonas Lahtinen, Tvrtko Ursulin, Chen-Yu Tsai, Samuel Holland,
Dave Stevenson, Maíra Canal, Raspberry Pi Kernel Maintenance,
dri-devel, linux-doc, linux-kernel, Daniel Stone, intel-gfx,
intel-xe, linux-arm-kernel, linux-sunxi
In-Reply-To: <20260504174907.GT1344263@killaraus.ideasonboard.com>
[-- Attachment #1: Type: text/plain, Size: 1326 bytes --]
On Mon, May 04, 2026 at 08:49:07PM +0300, Laurent Pinchart wrote:
> Hi Maxime,
>
> Thank you for the patch.
>
> On Fri, Apr 24, 2026 at 12:18:58PM +0200, Maxime Ripard wrote:
> > Now that drm_mode_config_create_initial_state() exists to create the
> > initial state, use it instead of drm_mode_config_reset() during
> > driver probe.
> >
> > Signed-off-by: Maxime Ripard <mripard@kernel.org>
> > ---
> > drivers/gpu/drm/tidss/tidss_drv.c | 6 +++++-
> > 1 file changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/tidss/tidss_drv.c b/drivers/gpu/drm/tidss/tidss_drv.c
> > index 1c8cc18bc53c..f5099d5d6e32 100644
> > --- a/drivers/gpu/drm/tidss/tidss_drv.c
> > +++ b/drivers/gpu/drm/tidss/tidss_drv.c
> > @@ -169,11 +169,15 @@ static int tidss_probe(struct platform_device *pdev)
> > goto err_runtime_suspend;
> > }
> >
> > drm_kms_helper_poll_init(ddev);
> >
> > - drm_mode_config_reset(ddev);
> > + ret = drm_mode_config_create_initial_state(ddev);
> > + if (ret) {
> > + dev_err(dev, "failed to create initial state: %d\n", ret);
> > + goto err_irq_uninstall;
> > + }
>
> There's also a call to drm_mode_config_reset() in tidss_modeset_init(),
> shouldn't it be dropped ?
This has been fixed by f468fef38716 which is in drm-misc-next
Maxime
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 273 bytes --]
^ permalink raw reply
* Re: [PATCH v3 17/20] drm/drv: Switch skeleton to drm_mode_config_create_initial_state()
From: Maxime Ripard @ 2026-05-12 11:20 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Maarten Lankhorst, Thomas Zimmermann, David Airlie, Simona Vetter,
Jonathan Corbet, Shuah Khan, Dmitry Baryshkov, Jyri Sarha,
Tomi Valkeinen, Andrzej Hajda, Neil Armstrong, Robert Foss,
Jonas Karlman, Jernej Skrabec, Simon Ser, Harry Wentland,
Melissa Wen, Sebastian Wick, Alex Hung, Jani Nikula, Rodrigo Vivi,
Joonas Lahtinen, Tvrtko Ursulin, Chen-Yu Tsai, Samuel Holland,
Dave Stevenson, Maíra Canal, Raspberry Pi Kernel Maintenance,
dri-devel, linux-doc, linux-kernel, Daniel Stone, intel-gfx,
intel-xe, linux-arm-kernel, linux-sunxi
In-Reply-To: <20260504180216.GU1344263@killaraus.ideasonboard.com>
[-- Attachment #1: Type: text/plain, Size: 1929 bytes --]
On Mon, May 04, 2026 at 09:02:16PM +0300, Laurent Pinchart wrote:
> On Fri, Apr 24, 2026 at 12:18:57PM +0200, Maxime Ripard wrote:
> > The driver skeleton currently recommends calling
> > drm_mode_config_reset() at probe time to create the initial state.
> >
> > Now that drm_mode_config_create_initial_state() exists to handle
> > initial state allocation without hardware side effects, update the
> > skeleton to recommend it instead.
> >
> > Signed-off-by: Maxime Ripard <mripard@kernel.org>
> > ---
> > drivers/gpu/drm/drm_drv.c | 4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> > index 985c283cf59f..f537556b06a8 100644
> > --- a/drivers/gpu/drm/drm_drv.c
> > +++ b/drivers/gpu/drm/drm_drv.c
> > @@ -340,11 +340,13 @@ void drm_minor_release(struct drm_minor *minor)
> > *
> > * // Further setup, display pipeline etc
> > *
> > * platform_set_drvdata(pdev, drm);
> > *
> > - * drm_mode_config_reset(drm);
> > + * ret = drm_mode_config_create_initial_state(drm);
> > + * if (ret)
> > + * return ret;
>
> There's one point I'm still not sure to understand properly. The
> skeleton example (and the tidss driver, which you convert to the new API
> in this series) both call drm_mode_config_helper_resume(). This in turn
> calls drm_atomic_helper_resume(), and drm_mode_config_reset(). For
> drivers that implement .atomic_create_state() instead of .reset() (such
> as tidss, after its conversion in this series), drm_mode_config_reset()
> will call the drm_mode_config_*_create_state() helpers, which allocate
> and initialize a new state (through .atomic_create_state()), and store
> that new state in the object's ->state field. Won't this leak the state
> previously stored there ?
Thanks for spotting this, you're totally right!
I'll fix it in the next version
Maxime
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 273 bytes --]
^ permalink raw reply
* Re: [PATCH v3 2/7] gpio: regmap: add gpio_regmap_get_gpiochip() accessor
From: Andy Shevchenko @ 2026-05-12 11:20 UTC (permalink / raw)
To: Yu-Chun Lin
Cc: linusw, brgl, robh, krzk+dt, conor+dt, afaerber, wbg,
mathieu.dubois-briand, mwalle, lars, Michael.Hennerich, jic23,
nuno.sa, andy, dlechner, tychang, linux-gpio, devicetree,
linux-kernel, linux-arm-kernel, linux-realtek-soc, linux-iio,
cy.huang, stanley_chang, james.tai
In-Reply-To: <20260512033317.1602537-3-eleanor.lin@realtek.com>
On Tue, May 12, 2026 at 11:33:12AM +0800, Yu-Chun Lin wrote:
> Expose an accessor function to retrieve the gpio_chip pointer from
> a gpio_regmap instance.
>
> This is needed by drivers that use gpio_regmap but also manage their
> own irq_chip, where gpiochip_enable_irq()/gpiochip_disable_irq() must
> be called with the gpio_chip pointer.
>
> Add gpio_regmap_get_gpiochip() to allow drivers with complex custom IRQ
> implementations.
Hmm... Can't we rather add gpio_regmap_enable_irq()/gpio_regmap_disable_irq()
that take regmap or GPIO regmap (whatever suits better for the purpose) and
do the magic inside GPIO regmap library code?
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH] drivers: altera_edac: Guard SDRAM irq2 retrieval for Arria10 only
From: Dinh Nguyen @ 2026-05-12 11:25 UTC (permalink / raw)
To: Nazle Asmade, Muhammad Nazim Amirul, bp@alien8.de,
tony.luck@intel.com
Cc: linux-edac@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <275595ca-6044-4882-a9fd-ca9d496a27a5@altera.com>
On 5/11/26 20:37, Nazle Asmade, Muhammad Nazim Amirul wrote:
> On 11/5/2026 7:54 pm, Dinh Nguyen wrote:
>>
>>
>> On 5/8/26 02:52, muhammad.nazim.amirul.nazle.asmade@altera.com wrote:
>>> From: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
>>>
>>> Guard the irq2 retrieval with an of_machine_is_compatible() check so
>>> that platform_get_irq(pdev, 1) is only called on Arria10 platforms.
>>>
>>> Signed-off-by: Nazim Amirul
>>> <muhammad.nazim.amirul.nazle.asmade@altera.com>
>>> Signed-off-by: Niravkumar L Rabara <nirav.rabara@altera.com>
>>> ---
>>> drivers/edac/altera_edac.c | 3 ++-
>>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/edac/altera_edac.c b/drivers/edac/altera_edac.c
>>> index 4edd2088c2db..b30302198cd4 100644
>>> --- a/drivers/edac/altera_edac.c
>>> +++ b/drivers/edac/altera_edac.c
>>> @@ -348,7 +348,8 @@ static int altr_sdram_probe(struct platform_device
>>> *pdev)
>>> }
>>> /* Arria10 has a 2nd IRQ */
>>> - irq2 = platform_get_irq(pdev, 1);
>>> + if (of_machine_is_compatible("altr,socfpga-arria10"))
>>> + irq2 = platform_get_irq(pdev, 1);
>>> layers[0].type = EDAC_MC_LAYER_CHIP_SELECT;
>>> layers[0].size = 1;
>>
>> Why? We already switch on arria10 later in the same function.
>>
>> Sorry, but NAK.
>>
>> Dinh
> This driver were used by cyclone5 and arria10. Cyclone5 only has one
> interrupt whereby arria10 has 2 interrupt. That is the reason why the
> interrupt was guard by (of_machine_is_compatible("altr,socfpga-arria10"))
>
Yes, but look at line 397,
/* Only the Arria10 has separate IRQs */
if (of_machine_is_compatible("altr,socfpga-arria10")) {
/* Arria10 specific initialization */
Dinh
^ permalink raw reply
* RE: [PATCH v3 0/3] iio: adc: xilinx-ams: refactor alarm handling to table-driven design
From: Erim, Salih @ 2026-05-12 11:26 UTC (permalink / raw)
To: Guilherme Ivo Bozi, Jonathan Cameron
Cc: O'Griofa, Conall, Simek, Michal, David Lechner, Nuno Sá,
Andy Shevchenko, linux-iio@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <CAJgF-xv2SpaOu+6K6k3CzFVNfWTx8LyeGJMZjLheCSETOR3Yzg@mail.gmail.com>
Hi Guilherme,
>
> > This series looks fine to me.
> >
> > Given the AMD Xilinx folk are fairly active reviewers I'm just waiting
> > on them taking a look.
> Hi, just checking in on this series since it’s been some time.
> Any updates from AMD Xilinx review or anything else needed from my side?
No, not needed, I am reviewing and will test it.
>
> --
> Thanks,
> Guilherme Ivo
Salih.
^ permalink raw reply
* Re: [PATCH v3 3/7] gpio: regmap: Add gpio_regmap_operation and write-enable support
From: Andy Shevchenko @ 2026-05-12 11:26 UTC (permalink / raw)
To: Yu-Chun Lin
Cc: linusw, brgl, robh, krzk+dt, conor+dt, afaerber, wbg,
mathieu.dubois-briand, mwalle, lars, Michael.Hennerich, jic23,
nuno.sa, andy, dlechner, tychang, linux-gpio, devicetree,
linux-kernel, linux-arm-kernel, linux-realtek-soc, linux-iio,
cy.huang, stanley_chang, james.tai, Linus Walleij
In-Reply-To: <20260512033317.1602537-4-eleanor.lin@realtek.com>
On Tue, May 12, 2026 at 11:33:13AM +0800, Yu-Chun Lin wrote:
> Extend the reg_mask_xlate callback with an operation type parameter
> (gpio_regmap_operation) to allow drivers to return different
> register/mask combinations for different GPIO operations.
>
> Also add write-enable mechanism for hardware that requires setting a
> write-enable bit before modifying GPIO control registers.
>
> Consequently, update all existing drivers utilizing the gpio-regmap
> framework (across drivers/gpio, drivers/iio, and drivers/pinctrl)
> to accommodate the new reg_mask_xlate function signature.
Dunno if we want per-driver patches (in that case it will be a new name and
callback, conversion per driver, removal old name, and, if required, renaming
back). In any case looks reasonable change.
...
> -static int idi_48_reg_mask_xlate(struct gpio_regmap *gpio, unsigned int base,
> - unsigned int offset, unsigned int *reg,
> - unsigned int *mask)
> +static int idi_48_reg_mask_xlate(struct gpio_regmap *gpio,
> + enum gpio_regmap_operation op,
> + unsigned int base, unsigned int offset,
> + unsigned int *reg, unsigned int *mask)
In every case, use this logical split.
...
> -static int i8255_reg_mask_xlate(struct gpio_regmap *gpio, unsigned int base,
> - unsigned int offset, unsigned int *reg,
> +static int i8255_reg_mask_xlate(struct gpio_regmap *gpio, enum gpio_regmap_operation op,
> + unsigned int base, unsigned int offset, unsigned int *reg,
> unsigned int *mask)
Exempli gratia, this one looks illogical, harder to read.
...
> + ret = gpio->reg_mask_xlate(gpio, GPIO_REGMAP_SET_DIR_WREN_OP, base, offset, ®,
> + &wren_mask);
Ditto. Easier to follow when
ret = gpio->reg_mask_xlate(gpio, GPIO_REGMAP_SET_DIR_WREN_OP, base, offset,
®, &wren_mask);
> if (ret)
> return ret;
...
> +/**
> + * enum gpio_regmap_operation - Operation type for reg_mask_xlate callback
> + *
> + * This enum is used to distinguish between different types of GPIO operations
> + * so that the reg_mask_xlate callback can return the appropriate mask for each
> + * operation type.
> + *
> + * Value operations:
Have you checked the rendered text (HTML, PDF)? I believe this will look awfully wrong.
> + * @GPIO_REGMAP_GET_OP: Mask for reading direction to detect if GPIO is input or output.
> + * Used in gpio_regmap_get() to determine the GPIO direction.
> + * @GPIO_REGMAP_IN: Mask for reading input value. Used when GPIO is configured as input.
> + * @GPIO_REGMAP_OUT: Mask for reading output value. Used when GPIO is configured as output.
> + *
> + * Output operations:
> + * @GPIO_REGMAP_SET_OP: Mask for setting GPIO output value.
> + * @GPIO_REGMAP_SET_WITH_CLEAR_OP: Mask for setting/clearing GPIO using separate registers.
> + * @GPIO_REGMAP_SET_WREN_OP: Write-enable mask for output operations. May be used to enable
> + * writes to protected registers.
> + *
> + * Direction operations:
> + * @GPIO_REGMAP_GET_DIR_OP: Mask for reading GPIO direction (input/output).
> + * @GPIO_REGMAP_SET_DIR_OP: Mask for setting GPIO direction (input/output).
> + * @GPIO_REGMAP_SET_DIR_WREN_OP: Write-enable mask for direction operations. May be used to
> + * enable writes to protected direction registers.
> + */
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 8/8] arm64: dts: qcom: monaco: add AEST error nodes
From: Konrad Dybcio @ 2026-05-12 11:28 UTC (permalink / raw)
To: Umang Chheda, Ruidong Tian, Tony Luck, Borislav Petkov,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Konrad Dybcio, catalin.marinas, will, lpieralisi, rafael,
mark.rutland, Sudeep Holla
Cc: linux-arm-msm, linux-acpi, linux-arm-kernel, linux-edac,
linux-kernel, devicetree, Faruque Ansari
In-Reply-To: <20260505-aest-devicetree-support-v1-8-d5d6ffacf0a5@oss.qualcomm.com>
On 5/5/26 2:23 PM, Umang Chheda wrote:
> Add AEST RAS error source nodes for the Monaco SoC.
>
> The DT describes a processor error source covering all CPU cores and a
> shared L3 cache error source for the cluster. These nodes model the
> hardware error reporting blocks and associated interrupts as required
> by the Arm AEST specification.
>
> Co-developed-by: Faruque Ansari <faruque.ansari@oss.qualcomm.com>
> Signed-off-by: Faruque Ansari <faruque.ansari@oss.qualcomm.com>
> Signed-off-by: Umang Chheda <umang.chheda@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/monaco.dtsi | 41 ++++++++++++++++++++++++++++++++++++
> 1 file changed, 41 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/monaco.dtsi b/arch/arm64/boot/dts/qcom/monaco.dtsi
> index 7b1d57460f1e..8e43ceed7d84 100644
> --- a/arch/arm64/boot/dts/qcom/monaco.dtsi
> +++ b/arch/arm64/boot/dts/qcom/monaco.dtsi
> @@ -3,6 +3,7 @@
> * Copyright (c) 2024 Qualcomm Innovation Center, Inc. All rights reserved.
> */
>
> +#include <dt-bindings/arm/aest.h>
> #include <dt-bindings/clock/qcom,dsi-phy-28nm.h>
> #include <dt-bindings/clock/qcom,qcs8300-gcc.h>
> #include <dt-bindings/clock/qcom,rpmh.h>
> @@ -29,6 +30,46 @@ / {
> #address-cells = <2>;
> #size-cells = <2>;
>
> + aest {
> + compatible = "arm,aest";
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
These 3 properties aren't necessary if none of the subnodes have a
'reg' property
Konrad
^ permalink raw reply
* Re: [PATCH 01/19] btrfs: require at least 4 devices for RAID 6
From: David Sterba @ 2026-05-12 11:42 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Andrew Morton, Catalin Marinas, Will Deacon, Ard Biesheuvel,
Huacai Chen, WANG Xuerui, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP), Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti, Heiko Carstens,
Vasily Gorbik, Alexander Gordeev, Christian Borntraeger,
Sven Schnelle, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, x86, H. Peter Anvin, Herbert Xu, Dan Williams,
Chris Mason, David Sterba, Arnd Bergmann, Song Liu, Yu Kuai,
Li Nan, linux-kernel, linux-arm-kernel, loongarch, linuxppc-dev,
linux-riscv, linux-s390, linux-crypto, linux-btrfs, linux-arch,
linux-raid
In-Reply-To: <20260512052230.2947683-2-hch@lst.de>
On Tue, May 12, 2026 at 07:20:41AM +0200, Christoph Hellwig wrote:
> While the RAID6 algorithm could in theory support 3 devices by just
> copying the data disk to the two parity disks, this version is not only
> useless because it is a suboptimal version of 3-way mirroring, but also
> broken with various crashes and incorrect parity generation in various
> architecture-optimized implementations. Disallow it similar to mdraid
> which requires at least 4 devices for RAID 6.
>
> Fixes: 53b381b3abeb ("Btrfs: RAID5 and RAID6")
> Signed-off-by: Christoph Hellwig <hch@lst.de>
This patch should have been sent separately as it has user visible
impact and can potentially break some setups. The degenerate modes of
raid0, 5, or 6 are explicit as a possible middle step when converting
profiles. We can use a fallback implementation for this case if the
accelerated implementations cannot do it.
^ permalink raw reply
* Re: [PATCH 2/3] iio: adc: sun20i-gpadc: add A523 gpadc support
From: Jonathan Cameron @ 2026-05-12 11:51 UTC (permalink / raw)
To: Michal Piekos
Cc: David Lechner, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai, Jernej Skrabec,
Samuel Holland, Maksim Kiselev, linux-iio, devicetree,
linux-arm-kernel, linux-sunxi, linux-kernel
In-Reply-To: <20260510-sunxi-a523-gpadc-v1-2-4f6b0f4000fb@mmpsystems.pl>
On Sun, 10 May 2026 14:57:23 +0200
Michal Piekos <michal.piekos@mmpsystems.pl> wrote:
> A523 differs from existing sun20i-gpadc-iio by having two clocks; bus
> clock and module clock.
>
> Change driver to enable all clocks.
>
> Signed-off-by: Michal Piekos <michal.piekos@mmpsystems.pl>
I'm expecting this to change given comment on not being quite compatible so
I'll wait for v2 before reviewing.
Thanks,
Jonathan
> ---
> drivers/iio/adc/sun20i-gpadc-iio.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/iio/adc/sun20i-gpadc-iio.c b/drivers/iio/adc/sun20i-gpadc-iio.c
> index 861c14da75ad..dd4c7e6e3d76 100644
> --- a/drivers/iio/adc/sun20i-gpadc-iio.c
> +++ b/drivers/iio/adc/sun20i-gpadc-iio.c
> @@ -180,7 +180,7 @@ static int sun20i_gpadc_probe(struct platform_device *pdev)
> struct iio_dev *indio_dev;
> struct sun20i_gpadc_iio *info;
> struct reset_control *rst;
> - struct clk *clk;
> + struct clk_bulk_data *clks;
> int irq;
> int ret;
>
> @@ -205,9 +205,9 @@ static int sun20i_gpadc_probe(struct platform_device *pdev)
> if (IS_ERR(info->regs))
> return PTR_ERR(info->regs);
>
> - clk = devm_clk_get_enabled(dev, NULL);
> - if (IS_ERR(clk))
> - return dev_err_probe(dev, PTR_ERR(clk), "failed to enable bus clock\n");
> + ret = devm_clk_bulk_get_all_enabled(dev, &clks);
> + if (ret < 0)
> + return dev_err_probe(dev, ret, "failed to enable clocks\n");
>
> rst = devm_reset_control_get_exclusive(dev, NULL);
> if (IS_ERR(rst))
>
^ permalink raw reply
* Re: [PATCH] drivers: altera_edac: Guard SDRAM irq2 retrieval for Arria10 only
From: Nazle Asmade, Muhammad Nazim Amirul @ 2026-05-12 11:51 UTC (permalink / raw)
To: Dinh Nguyen, bp@alien8.de, tony.luck@intel.com
Cc: linux-edac@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <de0f32eb-2216-47a8-80d4-bd66fcb253a9@kernel.org>
On 12/5/2026 7:25 pm, Dinh Nguyen wrote:
>
>
> On 5/11/26 20:37, Nazle Asmade, Muhammad Nazim Amirul wrote:
>> On 11/5/2026 7:54 pm, Dinh Nguyen wrote:
>>>
>>>
>>> On 5/8/26 02:52, muhammad.nazim.amirul.nazle.asmade@altera.com wrote:
>>>> From: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
>>>>
>>>> Guard the irq2 retrieval with an of_machine_is_compatible() check so
>>>> that platform_get_irq(pdev, 1) is only called on Arria10 platforms.
>>>>
>>>> Signed-off-by: Nazim Amirul
>>>> <muhammad.nazim.amirul.nazle.asmade@altera.com>
>>>> Signed-off-by: Niravkumar L Rabara <nirav.rabara@altera.com>
>>>> ---
>>>> drivers/edac/altera_edac.c | 3 ++-
>>>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/edac/altera_edac.c b/drivers/edac/altera_edac.c
>>>> index 4edd2088c2db..b30302198cd4 100644
>>>> --- a/drivers/edac/altera_edac.c
>>>> +++ b/drivers/edac/altera_edac.c
>>>> @@ -348,7 +348,8 @@ static int altr_sdram_probe(struct platform_device
>>>> *pdev)
>>>> }
>>>> /* Arria10 has a 2nd IRQ */
>>>> - irq2 = platform_get_irq(pdev, 1);
>>>> + if (of_machine_is_compatible("altr,socfpga-arria10"))
>>>> + irq2 = platform_get_irq(pdev, 1);
>>>> layers[0].type = EDAC_MC_LAYER_CHIP_SELECT;
>>>> layers[0].size = 1;
>>>
>>> Why? We already switch on arria10 later in the same function.
>>>
>>> Sorry, but NAK.
>>>
>>> Dinh
>> This driver were used by cyclone5 and arria10. Cyclone5 only has one
>> interrupt whereby arria10 has 2 interrupt. That is the reason why the
>> interrupt was guard by (of_machine_is_compatible("altr,socfpga-arria10"))
>>
>
> Yes, but look at line 397,
>
> /* Only the Arria10 has separate IRQs */
> if (of_machine_is_compatible("altr,socfpga-arria10")) {
> /* Arria10 specific initialization */
>
> Dinh
>
>
Hi Dinh, That is true, but the one that we looking at now is at line 352
which enabling the second interrupt and it is not required by cyclone5.
Perhaps are you saying we should move the irq2 at line 352 under this
line 397?
^ permalink raw reply
* Re: [PATCH v3] dt-bindings: iio: adc: Convert xilinx-xadc bindings to YAML schema
From: Rob Herring @ 2026-05-12 12:14 UTC (permalink / raw)
To: David Lechner
Cc: Jonathan Cameron, Pramod Maurya, Nuno Sá, Andy Shevchenko,
Krzysztof Kozlowski, Conor Dooley, Michal Simek,
Lars-Peter Clausen, linux-iio, devicetree, linux-arm-kernel,
linux-kernel
In-Reply-To: <7baf9ca5-50ff-4131-995b-70ee094ed247@baylibre.com>
On Mon, May 11, 2026 at 11:24 AM David Lechner <dlechner@baylibre.com> wrote:
>
> On 5/11/26 11:15 AM, Jonathan Cameron wrote:
> > On Sun, 10 May 2026 08:01:36 -0400
> > Pramod Maurya <pramod.nexgen@gmail.com> wrote:
> >
> >> Convert the Xilinx XADC and UltraScale System Monitor device tree binding
> >> from the legacy plain-text format to a YAML schema, enabling automated
> >> validation with dt-schema.
> >>
> >> The new binding covers the same hardware and compatible strings:
> >> - xlnx,zynq-xadc-1.00.a (ZYNQ hardmacro)
> >> - xlnx,axi-xadc-1.00.a (AXI softmacro)
> >> - xlnx,system-management-wiz-1.3 (UltraScale System Management Wizard)
> >>
> >> Signed-off-by: Pramod Maurya <pramod.nexgen@gmail.com>
> > Hi Pramod,
> >
> > Something went wrong with your sending of v3. I have two versions sent
> > half a day apart and no idea how they are related.
> >
> > Anyhow one of them got feedback from Rob's bot so I'll assume we are
> > getting a v4 and wait for that.
> >
> > Jonathan
>
> I think Rob will have to fix the bot to make an exception for the
> legacy bindings. This should have been called out in the commit message
> as requested in a previous revision.
The bot is not the problem. It just runs validation. The schemas will
have to either drop this check (comma's in nodenames) or exclude just
this property.
Rob
^ permalink raw reply
* Re: [PATCH v4 1/4] kernel: param: initialize module_kset before do_initcalls()
From: Sumit Gupta @ 2026-05-12 12:14 UTC (permalink / raw)
To: Jon Hunter, Shashank Balaji, Thierry Reding
Cc: Gary Guo, Suzuki K Poulose, James Clark, Alexander Shishkin,
Maxime Coquelin, Alexandre Torgue, Greg Kroah-Hartman,
Rafael J. Wysocki, Danilo Krummrich, Miguel Ojeda, Boqun Feng,
Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl,
Trevor Gross, Richard Cochran, Jonathan Corbet, Shuah Khan,
Luis Chamberlain, Petr Pavlu, Daniel Gomez, Sami Tolvanen,
Aaron Tomlin, Mike Leach, Leo Yan, Rahul Bukte, linux-kernel,
coresight, linux-arm-kernel, driver-core, rust-for-linux,
linux-doc, Daniel Palmer, Tim Bird, linux-modules, linux-tegra
In-Reply-To: <40c3aab2-b5cf-4297-9b14-3ccfea377c83@nvidia.com>
On 12/05/26 14:25, Jon Hunter wrote:
> Hi Shashank,
>
> On 12/05/2026 03:12, Shashank Balaji wrote:
>
> ...
>
>>> Hi Thierry and Jonathan,
>>>
>>> You can find the context for this email in this patch:
>>> https://lore.kernel.org/all/20260427-acpi_mod_name-v4-1-22b42240c9bf@sony.com/
>>>
>>>
>>> TL;DR: tegra194_cbb_driver and tegra234_cbb_driver are the only drivers
>>> registering themselves as early as in a pure_initcall. This is a
>>> problem
>>> on two fronts:
>>> 1. Philosophical: As Gary pointed out, pure_initcalls are intended
>>> to purely
>>> initialize variables that couldn't be statically initialized. But these
>>> are doing driver registrations.
>>> 2. module_kset not initialized at pure_initcall stage: This is
>>> needed to
>>> set the module sysfs symlink. Since module_kset is not alive yet during
>>> pure_initcalls, registering these drivers panics the kernel.
>
> Where exactly is this panic seen? Ie. why are we not seeing this?
>
>>> We would like to do the tegra cbb driver registration in a
>>> core_initcall
>>> (or some later initcall works too), and move module_kset initialization
>>> to a pure_initcall. Like this:
>>>
>>> diff --git a/drivers/soc/tegra/cbb/tegra194-cbb.c
>>> b/drivers/soc/tegra/cbb/tegra194-cbb.c
>>> index ab75d50cc85c..2f69e104c838 100644
>>> --- a/drivers/soc/tegra/cbb/tegra194-cbb.c
>>> +++ b/drivers/soc/tegra/cbb/tegra194-cbb.c
>>> @@ -2342,7 +2342,7 @@ static int __init tegra194_cbb_init(void)
>>> {
>>> return platform_driver_register(&tegra194_cbb_driver);
>>> }
>>> -pure_initcall(tegra194_cbb_init);
>>> +core_initcall(tegra194_cbb_init);
>>>
>>> static void __exit tegra194_cbb_exit(void)
>>> {
>>> diff --git a/drivers/soc/tegra/cbb/tegra234-cbb.c
>>> b/drivers/soc/tegra/cbb/tegra234-cbb.c
>>> index fb26f085f691..785072fa4e85 100644
>>> --- a/drivers/soc/tegra/cbb/tegra234-cbb.c
>>> +++ b/drivers/soc/tegra/cbb/tegra234-cbb.c
>>> @@ -1774,7 +1774,7 @@ static int __init tegra234_cbb_init(void)
>>> {
>>> return platform_driver_register(&tegra234_cbb_driver);
>>> }
>>> -pure_initcall(tegra234_cbb_init);
>>> +core_initcall(tegra234_cbb_init);
>>>
>>> static void __exit tegra234_cbb_exit(void)
>>> {
>>>
>>> Would this work?
>
>
> I am adding Sumit who has been doing a lot of the Tegra CBB driver work.
>
> Sumit, any concerns here? We could run this change through our
> internal testing to confirm.
>
> Jon
>
CBB driver can be switched to core_initcall.
pure_initcall was originally added so its IRQ handler is registered
before other Tegra drivers to catch and print any bad MMIO error
during their probe.
Looked at the current state of Tegra drivers:
- The other early Tegra drivers (PMC, fuse, flowctrl, ARI) all run at
early_initcall, before either pure_ or core_initcall.
- The only other Tegra core_initcall is tegra-hsp, and link order keeps
CBB ahead of it (drivers/soc/ links before drivers/mailbox/).
Acked-by: Sumit Gupta <sumitg@nvidia.com>
Thank you,
Sumit Gupta
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox