Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
* Re: [PATCH v3 4/7] PCI: dwc: Use common pci_host_common_link_train_delay() helper
From: Hans Zhang @ 2026-05-12 10:06 UTC (permalink / raw)
  To: Krzysztof Wilczyński
  Cc: bhelgaas, lpieralisi, mani, vigneshr, jingoohan1,
	thomas.petazzoni, pali, ryder.lee, claudiu.beznea.uj, mpillai,
	robh, s-vadapalli, linux-omap, linux-arm-kernel, claudiu.beznea,
	linux-mediatek, linux-renesas-soc, linux-pci, linux-kernel
In-Reply-To: <20260512071328.GA3606279@rocinante>



On 5/12/26 15:14, Krzysztof Wilczyński wrote:
> Hello,
> 
>>>> -	/*
>>>> -	 * As per PCIe r6.0, sec 6.6.1, a Downstream Port that supports Link
>>>> -	 * speeds greater than 5.0 GT/s, software must wait a minimum of 100 ms
>>>> -	 * after Link training completes before sending a Configuration Request.
>>>> -	 */
>>>> -	if (pci->max_link_speed > 2)
>>>> -		msleep(PCIE_RESET_CONFIG_WAIT_MS);
>>>> +	pci_host_common_link_train_delay(pci->max_link_speed);
>>>
>>> This comment could move to the helper you added.
>>
>> Hi Krzysztof,
>>
>> Will add.
> 
> No need.  Per Mani's feedback about macro being well documented.
> 

Hi Krzysztof,

Okay.

Best regards,
Hans

> Thank you nonetheless!
> 
> 	Krzysztof



^ permalink raw reply
* Re: [PATCH RFC] iommu: Enable per-device SSID space for SVA
From: Joonwon Kang @ 2026-05-12 10:07 UTC (permalink / raw)
  To: jgg
  Cc: Alexander.Grest, amhetre, baolu.lu, easwar.hariharan, iommu,
	jacob.jun.pan, joonwonkang, joro, jpb, kees, kevin.tian,
	linux-arm-kernel, linux-kernel, nicolinc, praan, robin.murphy,
	smostafa, will
In-Reply-To: <20260509171013.GF9285@ziepe.ca>

> > We have multiple processes and a single device, those processes want to
> > do SVA with the same device, and only one process will do SVA with the
> > device at a time. Though, the problem occurs even when irrelevant
> > processes allocate the PASIDs from the global PASID space for their own
> > irrelevant purposes.
> 
> The only way to allocate a PASID from the global PASID space is to
> establish another SVA, so you have multiple devices doing SVA?

Another way is via iommu_alloc_global_pasid() [1] and it does not require
SVA. No, we currently do not have multiple devices doing SVA. But, the
problem is that it is out of our control when any device is to allocate a
PASID or do SVA for its own purpose.

[1] https://lore.kernel.org/all/20230802212427.1497170-3-jacob.jun.pan@linux.intel.com/

Thanks,
Joonwon Kang


^ permalink raw reply
* Re: [PATCH v5 8/8] unwind: arm64: Use sframe to unwind interrupt frames
From: Mark Rutland @ 2026-05-12 10:07 UTC (permalink / raw)
  To: Dylan Hatch
  Cc: Roman Gushchin, Weinan Liu, Will Deacon, Josh Poimboeuf,
	Indu Bhagat, Peter Zijlstra, Steven Rostedt, Catalin Marinas,
	Jiri Kosina, Jens Remus, Prasanna Kumar T S M, Puranjay Mohan,
	Song Liu, joe.lawrence, linux-toolchains, linux-kernel,
	live-patching, linux-arm-kernel, Randy Dunlap
In-Reply-To: <CADBMgpx9YxNUO6wLP7mYKxWW8L78Hk9gPwHrMjXUwPyUmGEu9w@mail.gmail.com>

On Mon, May 11, 2026 at 08:00:21PM -0700, Dylan Hatch wrote:
> Hi Mark,
> 
> Thanks for all the feedback and help on this. I'm planning on getting
> your comments addressed in the coming days, but I have some initial
> clarifying questions.
> 
> On Fri, May 1, 2026 at 9:46 AM Mark Rutland <mark.rutland@arm.com> wrote:
> >
> > Hi Dylan,
> >
> > Thanks for putting this together. I think this is looking pretty good.
> > However, there are some things that aren't quite right and need some
> > work, which I've commented on below.
> >
> > More generally, there are a few things that aren't addressed by this
> > series that we will also need to address. Importantly:
> >
> > (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.
> >
> >     Before this series, that doesn't matter for livepatching because the
> >     livepatching code isn't called synchronously within the fgraph
> >     handler, and unwinds which cross an exception boundary are marked as
> >     unreliable.
> >
> >     After this series, that does matter as we can unwind across an
> >     exception boundary, and might happen to interrupt that transient
> >     window.
> >
> >     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.

Yes.

To be clear, please don't worry about solving that for the next version
of this series; let's get the SFrame bits into shape first. I just
wanted to highlight that there's some more general work that we'll need
to do.

I think we can *detect* this case (and mark the unwind as unreliable)
with some tiny changes to the arm64 code. I'm happy to put that
together.

> Based on this, I believe you are suggesting to restructure this code
> path such that the return address is removed from the return stack
> only after it has been restored to LR. But since kernel/trace/fgraph.c
> is core kernel code, will this end up requiring either (1) a similar
> restructuring of other arches supporting ftrace, or (2) an
> arm64-specific implementation of this recovery logic?

Yes, I am say that to *recover* the address we'd need to make changes to
core code.

In the mean time we can *detect* this case with some minimal changes to
arm64 code, and abort. As above, I'm happy to go put that together.

> It looks to me like there is essentially the same recovery pattern on
> other arches; is there a reason this transient unrecoverability isn't
> an issue for reliable unwind on other platforms?

Yep; on all architectures there's a transient period where the address
cannot be recovered. It's not a correctness issue so long as the
architecture detects this case and marks the unwind as unreliable.

IIUC x86 will mark the unwind as unreliable in this case.

I don't know whether other architectures detect this reliably. That's a
question for loonarch, parisc, powerpc, and s390 folk.

> >     I'm not immediately sure whether kretprobes has a similar issue.
> >
> > (2) To make unwinding generally possible, we'll need to annotate some
> >     assembly functions as unwindable. We'll need to do that for string
> >     routines under lib/, and probably some crypto code, but we don't
> >     need to do that for most code in head.S, entry.S, etc.
> >
> >     The vast majority of relevant assembly functions are leaf functions
> >     (where the return address is never moved out of the LR), so we can
> >     probably get away with a simple annotation for those that avoids the
> >     need for open-coded CFI directives everywhere.
> 
> Are you suggesting something like a SYM_LEAF_FUNC_(START|END), that
> wraps CFI directives for leaf functions?

Yep; that's exactly the sort of thing I was thinking of.

That or have a seaprate annotation we can add, e.g.

SYM_FUNC_START(foo)
SYM_FUN_END(foo)
SYM_FUNC_IS_LEAF_AND_DOES_NOT_TOUCH_LR(foo)

> > I've pushed some reliable stacktrace tests to:
> >
> >   git://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git stacktrace/tests
> >
> > That finds the fgraph issue (regardless of this series). When merged
> > with this series triggers a warning in kunwind_next_frame_record_meta(),
> > where unwind_next_frame_sframe() calls that erroneously as a fallback.
> 
> Thanks for the pointer on these tests, they're super useful! I've been
> able to reproduce the fgraph failure you mentioned.

Great!

Mark.


^ permalink raw reply
* [PATCH v2] phy: fsl-imx8mq-usb: set usb phy to be wakeup capable
From: Xu Yang @ 2026-05-12 10:10 UTC (permalink / raw)
  To: vkoul, neil.armstrong, Frank.Li, s.hauer, kernel, festevam,
	jun.li, a.fatoum, franz.schnyder, stefano.radaelli21, linux-phy,
	imx, linux-arm-kernel, linux-kernel

USB remote wakeup need its PHY power domain to be active,
so set PHY to be wakeup capable.

Signed-off-by: Li Jun <jun.li@nxp.com>
Signed-off-by: Xu Yang <xu.yang_2@nxp.com>

---
Changes in v2:
 - no changes
---
 drivers/phy/freescale/phy-fsl-imx8mq-usb.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/phy/freescale/phy-fsl-imx8mq-usb.c b/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
index 958d114b0c83..50b67f1e6a90 100644
--- a/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
+++ b/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
@@ -750,6 +750,7 @@ static int imx8mq_usb_phy_probe(struct platform_device *pdev)
 					"failed to get tca\n");
 
 	imx8m_get_phy_tuning_data(imx_phy);
+	device_set_wakeup_capable(dev, true);
 
 	phy_provider = devm_of_phy_provider_register(dev, of_phy_simple_xlate);
 
-- 
2.34.1



^ permalink raw reply related
* [PATCH v2] phy: fsl-imx8mq-usb: add control register regmap
From: Xu Yang @ 2026-05-12 10:12 UTC (permalink / raw)
  To: vkoul, neil.armstrong, Frank.Li, s.hauer, kernel, festevam,
	jun.li, a.fatoum, franz.schnyder, stefano.radaelli21, linux-phy,
	imx, linux-arm-kernel, linux-kernel

The CR port is a simple 16-bit data/address parallel port that is
provided for on-chip access to the control registers inside the
USB 3.0 femtoPHY. Add control register regmap and export these
registers by debugfs to help PHY's diagnostic.

Signed-off-by: Xu Yang <xu.yang_2@nxp.com>

---
Changes in v2:
 - no changes
---
 drivers/phy/freescale/phy-fsl-imx8mq-usb.c | 19 ++++++++++++++++++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/drivers/phy/freescale/phy-fsl-imx8mq-usb.c b/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
index b05d80e849a1..958d114b0c83 100644
--- a/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
+++ b/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
@@ -1,5 +1,5 @@
 // SPDX-License-Identifier: GPL-2.0+
-/* Copyright (c) 2017 NXP. */
+/* Copyright 2017-2026 NXP. */
 
 #include <linux/bitfield.h>
 #include <linux/clk.h>
@@ -9,6 +9,7 @@
 #include <linux/of.h>
 #include <linux/phy/phy.h>
 #include <linux/platform_device.h>
+#include <linux/regmap.h>
 #include <linux/regulator/consumer.h>
 #include <linux/usb/typec_mux.h>
 
@@ -55,6 +56,8 @@
 #define PHY_CTRL6_ALT_CLK_EN		BIT(1)
 #define PHY_CTRL6_ALT_CLK_SEL		BIT(0)
 
+#define PHY_CRCTL			0x30
+
 #define PHY_TUNE_DEFAULT		0xffffffff
 
 #define TCA_CLK_RST			0x00
@@ -118,6 +121,7 @@ struct imx8mq_usb_phy {
 	void __iomem *base;
 	struct regulator *vbus;
 	struct tca_blk *tca;
+	struct regmap *cr_regmap;
 	u32 pcs_tx_swing_full;
 	u32 pcs_tx_deemph_3p5db;
 	u32 tx_vref_tune;
@@ -685,6 +689,14 @@ static const struct of_device_id imx8mq_usb_phy_of_match[] = {
 };
 MODULE_DEVICE_TABLE(of, imx8mq_usb_phy_of_match);
 
+static const struct regmap_config imx_cr_regmap_config = {
+	.name = "cr",
+	.reg_bits = 32,
+	.val_bits = 32,
+	.reg_stride = 4,
+	.max_register = 0x7,
+};
+
 static int imx8mq_usb_phy_probe(struct platform_device *pdev)
 {
 	struct phy_provider *phy_provider;
@@ -713,6 +725,11 @@ static int imx8mq_usb_phy_probe(struct platform_device *pdev)
 	if (IS_ERR(imx_phy->base))
 		return PTR_ERR(imx_phy->base);
 
+	imx_phy->cr_regmap = devm_regmap_init_mmio(dev, imx_phy->base + PHY_CRCTL,
+						   &imx_cr_regmap_config);
+	if (IS_ERR(imx_phy->cr_regmap))
+		return PTR_ERR(imx_phy->cr_regmap);
+
 	phy_ops = of_device_get_match_data(dev);
 	if (!phy_ops)
 		return -EINVAL;
-- 
2.34.1



^ permalink raw reply related
* Re: [PATCH v3 12/20] drm/crtc: Add new atomic_create_state callback
From: Maxime Ripard @ 2026-05-12 10:16 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: <20260504172858.GO1344263@killaraus.ideasonboard.com>

[-- Attachment #1: Type: text/plain, Size: 4008 bytes --]

Hi,

On Mon, May 04, 2026 at 08:28:58PM +0300, Laurent Pinchart wrote:
> On Fri, Apr 24, 2026 at 12:18:52PM +0200, Maxime Ripard wrote:
> > Commit 47b5ac7daa46 ("drm/atomic: Add new atomic_create_state callback
> > to drm_private_obj") introduced a new pattern for allocating drm object
> > states.
> > 
> > Instead of relying on the reset() callback, it created a new
> > atomic_create_state hook. This is helpful because reset is a bit
> > overloaded: it's used to create the initial software state, reset it,
> > but also reset the hardware.
> > 
> > It can also be used either at probe time, to create the initial state
> > and possibly reset the hardware to an expected default, but also during
> > suspend/resume.
> > 
> > Both these cases come with different expectations too: during the
> > initialization, we want to initialize all states, but during
> > suspend/resume, drm_private_states for example are expected to be kept
> > around.
> > 
> > reset() also isn't fallible, which makes it harder to handle
> > initialization errors properly. This is only really relevant for some
> > drivers though, since all the helpers for reset only create a new
> > state, and don't touch the hardware at all.
> > 
> > It was thus decided to create a new hook that would allocate and
> > initialize a pristine state without any side effect:
> > atomic_create_state to untangle a bit some of it, and to separate the
> > initialization with the actual reset one might need during a
> > suspend/resume.
> > 
> > Continue the transition to the new pattern with CRTCs.
> > 
> > Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> > Signed-off-by: Maxime Ripard <mripard@kernel.org>
> > ---
> >  drivers/gpu/drm/drm_atomic_state_helper.c | 47 +++++++++++++++++++++++++++++++
> >  drivers/gpu/drm/drm_mode_config.c         | 21 +++++++++++++-
> >  include/drm/drm_atomic_state_helper.h     |  4 +++
> >  include/drm/drm_crtc.h                    | 16 +++++++++++
> >  4 files changed, 87 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c b/drivers/gpu/drm/drm_atomic_state_helper.c
> > index 9cd8550cabb7..b7da134c8c50 100644
> > --- a/drivers/gpu/drm/drm_atomic_state_helper.c
> > +++ b/drivers/gpu/drm/drm_atomic_state_helper.c
> > @@ -103,10 +103,32 @@ __drm_atomic_helper_crtc_reset(struct drm_crtc *crtc,
> >  
> >  	crtc->state = crtc_state;
> >  }
> >  EXPORT_SYMBOL(__drm_atomic_helper_crtc_reset);
> >  
> > +/**
> > + * __drm_atomic_helper_crtc_create_state - initializes crtc state
> 
> "Initialize a CRTC state"

Good catch, thanks.

> The name of the function is misleading ("*_create_*" while you state it
> performs initialization).
>
> > + * @crtc: crtc object
> > + * @state: new state to initialize
> > + *
> > + * Initializes the newly allocated @state, usually required when
> > + * initializing the drivers.
> > + *
> > + * @state is assumed to be zeroed.
> > + *
> > + * This is useful for drivers that subclass @drm_crtc_state.
> > + */
> > +void __drm_atomic_helper_crtc_create_state(struct drm_crtc *crtc,
> > +					   struct drm_crtc_state *state)
> > +{
> > +	__drm_atomic_helper_crtc_state_init(state, crtc);
> > +
> > +	if (drm_dev_has_vblank(crtc->dev))
> > +		drm_crtc_vblank_reset(crtc);
> 
> This is confusing to me (at least before reading the rest of the
> series), and itn't mentioned in the function documentation or in the
> commit message.
>
> Furthermore, __drm_atomic_helper_crtc_create_state() is later used in
> tidss_crtc_create_state(), which is the
> drm_crtc_funcs.atomic_create_state() implementation of the tidss driver.
> The atomic_create_state documentation states that "This callback must
> have no side effect", and drm_crtc_vblank_reset() has side effects.

That's a good point. I've dropped that function entirely and moved the
drm_crtc_vblank_reset() call in drm_mode_config_crtc_create_state().

Maxime

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 273 bytes --]

^ permalink raw reply
* [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, &regval);
 	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, &regval);
@@ -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, &reg,
> +				   &wren_mask);

Ditto. Easier to follow when

	ret = gpio->reg_mask_xlate(gpio, GPIO_REGMAP_SET_DIR_WREN_OP, base, offset,
				   &reg, &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
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox