* RE: [EXT] Re: [PATCH v8 1/2] media: dt-bindings: Add CSI Pixel Formatter DT bindings
From: G.N. Zhou @ 2026-05-26 9:33 UTC (permalink / raw)
To: Krzysztof Kozlowski, G.N. Zhou (OSS)
Cc: Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Shawn Guo, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Laurent Pinchart, Frank Li, imx@lists.linux.dev,
linux-media@vger.kernel.org, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, Krzysztof Kozlowski
In-Reply-To: <20260526-towering-essential-civet-19a5ad@quoll>
Hi Krzysztof,
Thanks for your review.
> -----Original Message-----
> From: Krzysztof Kozlowski <krzk@kernel.org>
> Sent: Tuesday, May 26, 2026 5:14 PM
> To: G.N. Zhou (OSS) <guoniu.zhou@oss.nxp.com>
> Cc: Mauro Carvalho Chehab <mchehab@kernel.org>; Rob Herring
> <robh@kernel.org>; Krzysztof Kozlowski <krzk+dt@kernel.org>; Conor Dooley
> <conor+dt@kernel.org>; Shawn Guo <shawnguo@kernel.org>; Sascha Hauer
> <s.hauer@pengutronix.de>; Pengutronix Kernel Team
> <kernel@pengutronix.de>; Fabio Estevam <festevam@gmail.com>; Laurent
> Pinchart <laurent.pinchart@ideasonboard.com>; Frank Li <frank.li@nxp.com>;
> imx@lists.linux.dev; linux-media@vger.kernel.org; devicetree@vger.kernel.org;
> linux-arm-kernel@lists.infradead.org; linux-kernel@vger.kernel.org; G.N. Zhou
> <guoniu.zhou@nxp.com>; Krzysztof Kozlowski
> <krzysztof.kozlowski@oss.qualcomm.com>
> Subject: [EXT] Re: [PATCH v8 1/2] media: dt-bindings: Add CSI Pixel Formatter
> DT bindings
>
> Caution: This is an external email. Please take care when clicking links or
> opening attachments. When in doubt, report the message using the 'Report this
> email' button
>
>
> On Mon, May 25, 2026 at 04:12:22PM +0800, Guoniu Zhou wrote:
> > From: Guoniu Zhou <guoniu.zhou@nxp.com>
> >
> > The i.MX95 CSI pixel formatting module uses packet info, pixel and
> > non-pixel data from the CSI-2 host controller and reformat them to
> > match Pixel Link(PL) definition.
> >
> > Reviewed-by: Frank Li <Frank.Li@nxp.com>
> > Reviewed-by: Krzysztof Kozlowski
> > <krzysztof.kozlowski@oss.qualcomm.com>
>
> Drop both review tags and request re-review since you made significant
> changes.
>
> > Signed-off-by: Guoniu Zhou <guoniu.zhou@nxp.com>
> > ---
> > Changes in v8:
> > - Use standard port reference instead of video-interfaces.yaml
>
> Why? Properties are not applicable?
Yes, the properties defined in video-interfaces.yaml (such as hsync-active,
vsync-active, pclk-sample, data-lanes, etc.) are not applicable to this
device. The device only requires the basic port/endpoint structure to
describe the connection topology, so the standard port reference is
sufficient.
>
> > - Add parent syscon node in example to show device integration
> > - Add required constraints for port@0 and port@1 in ports node
> >
> > Changes in v7:
> > - Change compatible to imx95-csi-formatter as IP is i.MX95 specific per
> Marco's suggestion
> > Link:
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore
> > .kernel.org%2Flinux-media%2F20260511-csi_formatter-v6-0-
> 01028e312e2b%4
> >
> 0oss.nxp.com%2FT%2F%23mcd135b3de179b3cb69daa1fd6e0e8e27c85b3332
> &data=0
> >
> 5%7C02%7Cguoniu.zhou%40nxp.com%7C3fc5c66c19574e666c7c08debb0713
> 3d%7C68
> >
> 6ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C639153836249231043%7
> CUnknown%
> >
> 7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJ
> XaW4z
> >
> MiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=ZNSc0TBvF
> V61YL
> > q4u49sEUs7zo5aPODxSKK36y9azAQ%3D&reserved=0
> > ---
> > .../bindings/media/fsl,imx95-csi-formatter.yaml | 92
> ++++++++++++++++++++++
> > 1 file changed, 92 insertions(+)
> >
> > diff --git
> > a/Documentation/devicetree/bindings/media/fsl,imx95-csi-formatter.yaml
> > b/Documentation/devicetree/bindings/media/fsl,imx95-csi-formatter.yaml
> > new file mode 100644
> > index 000000000000..bc2f5d448fe5
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/media/fsl,imx95-csi-formatter.
> > +++ yaml
> > @@ -0,0 +1,92 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2
> > +---
> > +$id:
> > +https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevi
> > +cetree.org%2Fschemas%2Fmedia%2Ffsl%2Cimx95-csi-
> formatter.yaml%23&data
> >
> +=05%7C02%7Cguoniu.zhou%40nxp.com%7C3fc5c66c19574e666c7c08debb0
> 7133d%7
> >
> +C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C63915383624927629
> 7%7CUnkn
> >
> +own%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCI
> sIlAiOiJ
> >
> +XaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=4y
> rIJ8Bn
> > +KlbEdq4%2BbZWNeoSWB4g8N1sChHSQ9z3VRZ0%3D&reserved=0
> > +$schema:
> > +https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevi
> > +cetree.org%2Fmeta-
> schemas%2Fcore.yaml%23&data=05%7C02%7Cguoniu.zhou%4
> >
> +0nxp.com%7C3fc5c66c19574e666c7c08debb07133d%7C686ea1d3bc2b4c6fa
> 92cd99
> >
> +c5c301635%7C0%7C0%7C639153836249307152%7CUnknown%7CTWFpbGZ
> sb3d8eyJFbX
> >
> +B0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWF
> pbCI
> >
> +sIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=MEUhKnYWZqo0gMxynCFUEB
> X8TLGC9aK6
> > +lNgrHXdqpx0%3D&reserved=0
> > +
> > +title: i.MX95 CSI Pixel Formatter
> > +
> > +maintainers:
> > + - Guoniu Zhou <guoniu.zhou@nxp.com>
> > +
> > +description:
> > + The CSI pixel formatting module found on i.MX95 uses packet info,
> > +pixel
> > + and non-pixel data from the CSI-2 host controller and reformat them
> > +to
> > + match Pixel Link(PL) definition.
> > +
> > +properties:
> > + compatible:
> > + const: fsl,imx95-csi-formatter
> > +
> > + reg:
> > + maxItems: 1
> > +
> > + clocks:
> > + maxItems: 1
> > +
> > + power-domains:
> > + maxItems: 1
> > +
> > + ports:
> > + $ref: /schemas/graph.yaml#/properties/ports
> > +
> > + properties:
> > + port@0:
> > + $ref: /schemas/graph.yaml#/properties/port
> > + description: MIPI CSI-2 RX IDI interface
> > +
> > + port@1:
> > + $ref: /schemas/graph.yaml#/properties/port
> > + description: Pixel Link Interface
> > +
> > + required:
> > + - port@0
> > + - port@1
> > +
> > +required:
> > + - compatible
> > + - reg
> > + - clocks
> > + - power-domains
> > + - ports
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > + - |
> > + #include <dt-bindings/clock/nxp,imx95-clock.h>
> > +
> > + syscon@4ac10000 {
> > + compatible = "nxp,imx95-camera-csr", "syscon";
>
> Drop entire node, not relevant. Or actually this example could be in the parent
> binding example.
Okay.
>
>
> > + reg = <0x0 0x4ac10000 0x0 0x10000>;
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > +
> > + formatter@20 {
> > + compatible = "fsl,imx95-csi-formatter";
> > + reg = <0x20 0x100>;
> > + clocks = <&cameramix_csr IMX95_CLK_CAMBLK_CSI2_FOR0>;
> > + power-domains = <&scmi_devpd 3>;
> > +
> > + ports {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + port@0 {
> > + reg = <0>;
> > +
> > + endpoint {
> > + remote-endpoint = <&mipi_csi_0_out>;
> > + };
> > + };
> > +
> > + port@1 {
>
> Messed indentation.
>
> Best regards,
> Krzysztof
^ permalink raw reply
* Re: [PATCH v5 16/19] drm/mode-config: Create drm_mode_config_create_initial_state()
From: Thomas Zimmermann @ 2026-05-26 9:33 UTC (permalink / raw)
To: Maxime Ripard, Maarten Lankhorst, David Airlie, Simona Vetter,
Jonathan Corbet, Shuah Khan, Dmitry Baryshkov, Jyri Sarha,
Tomi Valkeinen, Andrzej Hajda, Neil Armstrong, Robert Foss,
Laurent Pinchart, 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
Cc: dri-devel, linux-doc, linux-kernel, Daniel Stone, intel-gfx,
intel-xe, linux-arm-kernel, linux-sunxi, Laurent Pinchart
In-Reply-To: <20260519-drm-mode-config-init-v5-16-388b03321e38@kernel.org>
Am 19.05.26 um 11:01 schrieb Maxime Ripard:
> drm_mode_config_reset() can be used to create the initial state, but
> also to return to the initial state, when doing a suspend/resume cycle
> for example.
>
> It also affects both the software and the hardware, and drivers can
> choose to reset the hardware as well. Most will just create an empty
> state and the synchronisation between hardware and software states will
> effectively be done when the first commit is done.
>
> That dual role can be harmful, since some objects do need to be
> initialized but also need to be preserved across a suspend/resume cycle.
> drm_private_obj are such objects for example.
>
> Thus, create another helper for drivers to call to initialize their
> state when the driver is loaded, so we can make
> drm_mode_config_reset() only about handling suspend/resume and similar.
>
> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> Signed-off-by: Maxime Ripard <mripard@kernel.org>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
There are some notes on the style of writing below.
> ---
> drivers/gpu/drm/drm_atomic.c | 13 +++++-
> drivers/gpu/drm/drm_mode_config.c | 89 +++++++++++++++++++++++++++++++++++++++
> include/drm/drm_mode_config.h | 1 +
> 3 files changed, 101 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index d98586d89bbe..ea021250925c 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -59,12 +59,21 @@
> * preparing the update and kept alive as long as they are active in the
> * device.
> *
> * Their respective lifetimes are:
> *
> - * - at reset time, the object reset implementation will allocate a new
> - * default state and will store it in the object state pointer.
> + * - at driver initialization time, the driver will call
> + * drm_mode_config_create_initial_state() to allocate an initial,
> + * pristine, state for each object and will store it in the objects
Present form: 'the driver calls', 'and stores it'.
> + * state pointer. 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,
Are there other reset times? If not, then rather say
"- when resuming from suspend, drm_mode_config_reset() resets..."
> + * 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.
Present form.
Best regards
Thomas
> + * Not all objects are affected by drm_mode_config_reset() though.
> *
> * - whenever a new update is needed:
> *
> * + A new &struct drm_atomic_commit is allocated using
> * drm_atomic_commit_alloc().
> diff --git a/drivers/gpu/drm/drm_mode_config.c b/drivers/gpu/drm/drm_mode_config.c
> index 9d240817f8b6..f432f485a914 100644
> --- a/drivers/gpu/drm/drm_mode_config.c
> +++ b/drivers/gpu/drm/drm_mode_config.c
> @@ -21,10 +21,11 @@
> */
>
> #include <linux/export.h>
> #include <linux/uaccess.h>
>
> +#include <drm/drm_atomic.h>
> #include <drm/drm_drv.h>
> #include <drm/drm_encoder.h>
> #include <drm/drm_file.h>
> #include <drm/drm_framebuffer.h>
> #include <drm/drm_managed.h>
> @@ -314,10 +315,98 @@ void drm_mode_config_reset(struct drm_device *dev)
> }
> drm_connector_list_iter_end(&conn_iter);
> }
> EXPORT_SYMBOL(drm_mode_config_reset);
>
> +/**
> + * drm_mode_config_create_initial_state - Allocates the initial state
> + * @dev: drm device
> + *
> + * This functions creates the initial state for all the objects. Drivers
> + * can use this in e.g. probe to initialize their software state.
> + *
> + * It has two main differences with drm_mode_config_reset(): the reset()
> + * hooks aren't called and thus the hardware will be left untouched, but
> + * also the &drm_private_obj structures will be initialized as opposed
> + * to drm_mode_config_reset() that skips them.
> + *
> + * Returns: 0 on success, negative error value on failure.
> + */
> +int drm_mode_config_create_initial_state(struct drm_device *dev)
> +{
> + struct drm_crtc *crtc;
> + struct drm_colorop *colorop;
> + struct drm_plane *plane;
> + struct drm_connector *connector;
> + struct drm_connector_list_iter conn_iter;
> + struct drm_private_obj *privobj;
> + int ret;
> +
> + drm_for_each_privobj(privobj, dev) {
> + struct drm_private_state *privobj_state;
> +
> + if (privobj->state)
> + continue;
> +
> + if (!privobj->funcs->atomic_create_state)
> + continue;
> +
> + privobj_state = privobj->funcs->atomic_create_state(privobj);
> + if (IS_ERR(privobj_state))
> + return PTR_ERR(privobj_state);
> +
> + privobj->state = privobj_state;
> + }
> +
> + drm_for_each_colorop(colorop, dev) {
> + struct drm_colorop_state *colorop_state;
> +
> + if (colorop->state)
> + continue;
> +
> + colorop_state = drm_atomic_helper_colorop_create_state(colorop);
> + if (IS_ERR(colorop_state))
> + return PTR_ERR(colorop_state);
> +
> + colorop->state = colorop_state;
> + }
> +
> + drm_for_each_plane(plane, dev) {
> + if (plane->state)
> + continue;
> +
> + ret = drm_mode_config_plane_create_state(plane);
> + if (ret)
> + return ret;
> + }
> +
> + drm_for_each_crtc(crtc, dev) {
> + if (crtc->state)
> + continue;
> +
> + ret = drm_mode_config_crtc_create_state(crtc);
> + if (ret)
> + return ret;
> + }
> +
> + drm_connector_list_iter_begin(dev, &conn_iter);
> + drm_for_each_connector_iter(connector, &conn_iter) {
> + if (connector->state)
> + continue;
> +
> + ret = drm_mode_config_connector_create_state(connector);
> + if (ret) {
> + drm_connector_list_iter_end(&conn_iter);
> + return ret;
> + }
> + }
> + drm_connector_list_iter_end(&conn_iter);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(drm_mode_config_create_initial_state);
> +
> /*
> * Global properties
> */
> static const struct drm_prop_enum_list drm_plane_type_enum_list[] = {
> { DRM_PLANE_TYPE_OVERLAY, "Overlay" },
> diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
> index e584652ddf67..d8f5b7e9673e 100644
> --- a/include/drm/drm_mode_config.h
> +++ b/include/drm/drm_mode_config.h
> @@ -1005,9 +1005,10 @@ int __must_check drmm_mode_config_init(struct drm_device *dev);
> static inline int drm_mode_config_init(struct drm_device *dev)
> {
> return drmm_mode_config_init(dev);
> }
>
> +int drm_mode_config_create_initial_state(struct drm_device *dev);
> void drm_mode_config_reset(struct drm_device *dev);
> void drm_mode_config_cleanup(struct drm_device *dev);
>
> #endif
>
--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstr. 146, 90461 Nürnberg, Germany, www.suse.com
GF: Jochen Jaser, Andrew McDonald, Werner Knoblich, (HRB 36809, AG Nürnberg)
^ permalink raw reply
* Re: [PATCH] pinctrl: sunxi: Implement function_is_gpio
From: Linus Walleij @ 2026-05-26 9:34 UTC (permalink / raw)
To: Andre Przywara
Cc: Paul Kocialkowski, linux-gpio, linux-arm-kernel, linux-sunxi,
linux-kernel, Chen-Yu Tsai, Jernej Skrabec, Samuel Holland
In-Reply-To: <20260525233808.20e75a21@ryzen.lan>
On Mon, May 25, 2026 at 11:39 PM Andre Przywara <andre.przywara@arm.com> wrote:
> And what about the IRQ function? Isn't that some GPIO as well, or does
> that not count for the purpose of the function_is_gpio() callback?
The purpose of the function is to tell the GPIO subsystem if a pin
is muxed into GPIO mode, and by that we mean a driver using
struct gpio_chip, so we can approve a request of gpiod_get*().
The struct irq_chip is often orthogonal and I think it would usually
"just work", and a struct irq_chip unrelated to a struct gpio_chip
(i.e. there is no way to actually drive or listen to the lines) is
something completely separate from struct gpio_chip.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v5 17/19] drm/drv: Switch skeleton to drm_mode_config_create_initial_state()
From: Thomas Zimmermann @ 2026-05-26 9:34 UTC (permalink / raw)
To: Maxime Ripard, Maarten Lankhorst, David Airlie, Simona Vetter,
Jonathan Corbet, Shuah Khan, Dmitry Baryshkov, Jyri Sarha,
Tomi Valkeinen, Andrzej Hajda, Neil Armstrong, Robert Foss,
Laurent Pinchart, 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
Cc: dri-devel, linux-doc, linux-kernel, Daniel Stone, intel-gfx,
intel-xe, linux-arm-kernel, linux-sunxi
In-Reply-To: <20260519-drm-mode-config-init-v5-17-388b03321e38@kernel.org>
Am 19.05.26 um 11:01 schrieb Maxime Ripard:
> 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>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
> ---
> 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;
> *
> * ret = drm_dev_register(drm);
> * if (ret)
> * return ret;
> *
>
--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstr. 146, 90461 Nürnberg, Germany, www.suse.com
GF: Jochen Jaser, Andrew McDonald, Werner Knoblich, (HRB 36809, AG Nürnberg)
^ permalink raw reply
* Re: [PATCH v5 2/5] dt-bindings: display/msm: gpu: Document Adreno X2-185
From: Krzysztof Kozlowski @ 2026-05-26 9:35 UTC (permalink / raw)
To: Akhil P Oommen
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Rob Clark, Sean Paul, Dmitry Baryshkov,
Abhinav Kumar, Jessica Zhang, Marijn Suijten, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Will Deacon, Robin Murphy, Joerg Roedel,
linux-arm-msm, devicetree, linux-kernel, dri-devel, freedreno,
linux-arm-kernel, iommu
In-Reply-To: <20260522-glymur-gpu-dt-v5-2-562c406b210c@oss.qualcomm.com>
On Fri, May 22, 2026 at 03:41:58PM +0530, Akhil P Oommen wrote:
> Adreno X2-185 GPU found in Glymur chipsets belongs to the A8x family.
> It features a new slice architecture with 4 slices, significantly higher
> bandwidth throughput compared to mobile counterparts, raytracing support,
> and the highest GPU Fmax seen so far on an Adreno GPU (1850 Mhz), among
> other improvements. Update the dt bindings documentation to describe this
> GPU.
>
> Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
> ---
> Documentation/devicetree/bindings/display/msm/gpu.yaml | 16 ++++++++++++++++
> 1 file changed, 16 insertions(+)
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v5 00/19] drm/atomic: Rework initial state allocation
From: Thomas Zimmermann @ 2026-05-26 9:36 UTC (permalink / raw)
To: Maxime Ripard, Maarten Lankhorst, David Airlie, Simona Vetter,
Jonathan Corbet, Shuah Khan, Dmitry Baryshkov, Jyri Sarha,
Tomi Valkeinen, Andrzej Hajda, Neil Armstrong, Robert Foss,
Laurent Pinchart, 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
Cc: dri-devel, linux-doc, linux-kernel, Daniel Stone, intel-gfx,
intel-xe, linux-arm-kernel, linux-sunxi, Laurent Pinchart
In-Reply-To: <20260519-drm-mode-config-init-v5-0-388b03321e38@kernel.org>
I only had comments on the writing. Looks good otherwise.
Best regards
Thomas
Am 19.05.26 um 11:01 schrieb Maxime Ripard:
> Hi,
>
> This series started from my work on the hardware state readout[1], and
> more specifically a discussion with Thomas[2].
>
> This series expands the work that has been merged recently to make
> drm_private_obj and drm_private_state allocation a bit more consistent
> and ended up creating a new atomic_create_state callback to allocate a
> new state with no side effect.
>
> The first patches document the existing behaviour and fix a few
> cleanups and typos.
>
> Then, __drm_*_state_reset() helpers are renamed to
> __drm_*_state_init() to clarify that they initialize rather than
> reset state, and we add the new atomic_create_state callback to
> every other DRM object (planes, CRTCs, connectors, colorops).
>
> Next, we leverage those new callbacks to create a new helper,
> drm_mode_config_create_initial_state(), to create the initial state
> for all the objects of a driver, and update the driver skeleton to
> recommend it.
>
> Finally, we convert the tidss driver and the bridge_connector to the
> new pattern.
>
> This was tested on a TI SK-AM62, with the tidss driver.
>
> Let me know what you think,
> Maxime
>
> 1: https://lore.kernel.org/dri-devel/20250902-drm-state-readout-v1-0-14ad5315da3f@kernel.org/
> 2: https://lore.kernel.org/dri-devel/5920ffe5-b6b1-484b-b320-332b9eb9db82@suse.de/
>
> Signed-off-by: Maxime Ripard <mripard@kernel.org>
> ---
> Changes in v5:
> - Address sashiko reviews
> - Improve the docs
> - Fix drmm_connector_hdmi_init
> - Drop drm/tidss: Switch to drm_mode_config_create_initial_state since
> not all possible bridges would have been converted to create_state
> - Link to v4: https://lore.kernel.org/r/20260512-drm-mode-config-init-v4-0-591dfdcc1bf9@kernel.org
>
> Changes in v4:
> - Rebased on current drm-misc-next
> - Update drm_atomic_state to drm_atomic_commit
> - Various doc impromvements
> - Don't call drm_crtc_vblank_reset in create_state
> - Prevent mem leak if states already have a state when
> drm_mode_config_reset or _create_initial_state are called
> - Link to v3: https://lore.kernel.org/r/20260424-drm-mode-config-init-v3-0-8b68d9db0d8b@kernel.org
>
> Changes in v3:
> - Reintroduce state documentation that was dropped by accident
> - Change name to drm_mode_config_create_initial_state()
> - Don't call drm_mode_config_create_initial_state() in drm_dev_register
> anymore
> - Drop __drm_atomic_helper_*_create_state
> - Improve documentation and commit messages where necessary
> - Collected tags
> - Link to v2: https://lore.kernel.org/r/20260320-drm-mode-config-init-v2-0-c63f1134e76c@kernel.org
>
> Changes in v2:
> - Change the _state_reset function names to _state_init
> - Change the colorop too
> - Various doc improvements
> - Link to v1: https://lore.kernel.org/r/20260310-drm-mode-config-init-v1-0-de7397c8e1cf@kernel.org
>
> ---
> Maxime Ripard (19):
> drm/atomic: Document atomic commit lifetime
> drm/colorop: Fix typos in the doc
> drm/atomic: Drop drm_private_obj.state assignment from create_state
> drm/atomic: Expand atomic_create_state expectations for drm_private_obj
> drm/mode-config: Document drm_private_obj exclusion from drm_mode_config_reset()
> drm/colorop: Rename __drm_colorop_state_reset()
> drm/colorop: Create drm_atomic_helper_colorop_create_state()
> drm/atomic-state-helper: Fix __drm_atomic_helper_plane_reset() doc typo
> drm/atomic-state-helper: Rename __drm_atomic_helper_plane_state_reset()
> drm/plane: Add new atomic_create_state callback
> drm/atomic-state-helper: Rename __drm_atomic_helper_crtc_state_reset()
> drm/crtc: Add new atomic_create_state callback
> drm/atomic-state-helper: Rename __drm_atomic_helper_connector_state_reset()
> drm/hdmi: Rename __drm_atomic_helper_connector_hdmi_reset()
> drm/connector: Add new atomic_create_state callback
> drm/mode-config: Create drm_mode_config_create_initial_state()
> drm/drv: Switch skeleton to drm_mode_config_create_initial_state()
> drm/tidss: Convert to atomic_create_state
> drm/bridge_connector: Convert to atomic_create_state
>
> Documentation/gpu/drm-kms.rst | 6 +
> drivers/gpu/drm/display/drm_bridge_connector.c | 17 +-
> drivers/gpu/drm/display/drm_hdmi_state_helper.c | 15 +-
> drivers/gpu/drm/drm_atomic.c | 67 ++++++++
> drivers/gpu/drm/drm_atomic_state_helper.c | 114 ++++++++++---
> drivers/gpu/drm/drm_colorop.c | 41 ++++-
> drivers/gpu/drm/drm_connector.c | 10 +-
> drivers/gpu/drm/drm_drv.c | 4 +-
> drivers/gpu/drm/drm_mode_config.c | 189 ++++++++++++++++++++-
> drivers/gpu/drm/i915/display/intel_crtc.c | 2 +-
> drivers/gpu/drm/i915/display/intel_plane.c | 2 +-
> drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 2 +-
> drivers/gpu/drm/tests/drm_hdmi_state_helper_test.c | 2 +-
> drivers/gpu/drm/tidss/tidss_crtc.c | 17 +-
> drivers/gpu/drm/tidss/tidss_plane.c | 2 +-
> drivers/gpu/drm/vc4/vc4_hdmi.c | 2 +-
> include/drm/display/drm_hdmi_state_helper.h | 4 +-
> include/drm/drm_atomic.h | 5 +-
> include/drm/drm_atomic_state_helper.h | 12 +-
> include/drm/drm_colorop.h | 2 +
> include/drm/drm_connector.h | 16 ++
> include/drm/drm_crtc.h | 16 ++
> include/drm/drm_mode_config.h | 1 +
> include/drm/drm_plane.h | 16 ++
> 24 files changed, 496 insertions(+), 68 deletions(-)
> ---
> base-commit: 69c95e4c529297c25503e60acba757fba24fdc95
> change-id: 20260310-drm-mode-config-init-1e1f52b745d0
>
> Best regards,
--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstr. 146, 90461 Nürnberg, Germany, www.suse.com
GF: Jochen Jaser, Andrew McDonald, Werner Knoblich, (HRB 36809, AG Nürnberg)
^ permalink raw reply
* Re: [PATCH v5 1/7] dt-bindings: clock: qcom: Add video clock controller on Qualcomm Eliza SoC
From: Krzysztof Kozlowski @ 2026-05-26 9:37 UTC (permalink / raw)
To: Taniya Das
Cc: Bjorn Andersson, Michael Turquette, Stephen Boyd, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Konrad Dybcio, Maxime Coquelin,
Alexandre Torgue, Luca Weiss, Ajit Pandey, Imran Shaik,
Jagadeesh Kona, linux-arm-msm, linux-clk, devicetree,
linux-kernel, linux-stm32, linux-arm-kernel
In-Reply-To: <20260525-eliza_mm_cc_v2-v5-1-a1d125619a5a@oss.qualcomm.com>
On Mon, May 25, 2026 at 04:16:03PM +0530, Taniya Das wrote:
> Eliza Video clock controller is on CX and MX rails similar to Milos.
> Add compatible string for Eliza video clock controller to the existing
> Milos videocc binding and add the dt-bindings header for Eliza.
>
> The video clock controller exposes power domains, so '#power-domain-cells'
> must be present in the device node. Add it to the required properties list
> to enforce this in binding validation.
That's ABI change, so you need to explain impact on existing devices -
Milos.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 2/4] firmware: arm_ffa: Register core as a platform driver
From: Sudeep Holla @ 2026-05-26 9:41 UTC (permalink / raw)
To: Nathan Chancellor
Cc: linux-security-module, linux-kernel, linux-integrity,
linux-arm-kernel, kvmarm, Yeoreum Yun
In-Reply-To: <20260523001148.GA1319283@ax162>
On Fri, May 22, 2026 at 05:11:48PM -0700, Nathan Chancellor wrote:
> Hi Sudeep,
>
> On Fri, May 08, 2026 at 06:54:16PM +0100, Sudeep Holla wrote:
> > Move the FF-A core bring-up and teardown paths into platform driver
> > probe and remove callbacks, and register a synthetic arm-ffa platform
> > device to bind the driver.
> >
> > This makes the FF-A core lifetime follow the driver model while keeping
> > the device creation internal to the FF-A core. Use normal platform driver
> > registration so the probe path has standard driver-core semantics.
> >
> > The synthetic platform device is a temporary bridge until ACPI and
> > devicetree describe the FF-A core device or object. Once those firmware
> > description paths are defined, the internal platform device creation can
> > be dropped and the driver can bind to the firmware-described device
> > directly.
> >
> > Since the transport selection now happens from the platform probe path,
> > drop the __init annotation from ffa_transport_init().
> >
> > Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
>
> I am seeing
>
> arm-ffa arm-ffa: probe with driver arm-ffa failed with error -95
>
> on my two arm64 test machines after this change landed in -next as
> commit e659fc8e537c ("firmware: arm_ffa: Register core as a platform
> driver"), is this expected? If so, perhaps it should be silenced?
>
Yes it should be silenced, I will see how it can be done. Thanks for the
report.
--
Regards,
Sudeep
^ permalink raw reply
* Re: [PATCH v5 5/5] arm64: defconfig: enable Exynos ACPM thermal support
From: Krzysztof Kozlowski @ 2026-05-26 9:42 UTC (permalink / raw)
To: Tudor Ambarus
Cc: Rafael J. Wysocki, Daniel Lezcano, Zhang Rui, Lukasz Luba,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bartlomiej Zolnierkiewicz, Kees Cook, Gustavo A. R. Silva,
Peter Griffin, André Draszik, Alim Akhtar, jyescas,
linux-kernel, linux-samsung-soc, linux-pm, devicetree,
linux-hardening, linux-arm-kernel
In-Reply-To: <20260525-acpm-tmu-v5-5-85fde739752e@linaro.org>
On Mon, May 25, 2026 at 12:50:25PM +0000, Tudor Ambarus wrote:
> Enable the Exynos ACPM thermal driver (CONFIG_EXYNOS_ACPM_THERMAL)
> to allow temperature monitoring and thermal management on Samsung
> Exynos SoCs
"on Samsung Exynos foobar SoCs" or "on Samsung Exynos SoCs (like
Google GS101)", used on "faz baz boards".
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v8 1/2] media: dt-bindings: Add CSI Pixel Formatter DT bindings
From: Laurent Pinchart @ 2026-05-26 9:44 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Guoniu Zhou, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Frank Li, imx,
linux-media, devicetree, linux-arm-kernel, linux-kernel,
Guoniu Zhou, Krzysztof Kozlowski
In-Reply-To: <20260526-towering-essential-civet-19a5ad@quoll>
On Tue, May 26, 2026 at 11:13:35AM +0200, Krzysztof Kozlowski wrote:
> On Mon, May 25, 2026 at 04:12:22PM +0800, Guoniu Zhou wrote:
> > From: Guoniu Zhou <guoniu.zhou@nxp.com>
> >
> > The i.MX95 CSI pixel formatting module uses packet info, pixel and
> > non-pixel data from the CSI-2 host controller and reformat them to
> > match Pixel Link(PL) definition.
> >
> > Reviewed-by: Frank Li <Frank.Li@nxp.com>
> > Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
>
> Drop both review tags and request re-review since you made significant
> changes.
>
> > Signed-off-by: Guoniu Zhou <guoniu.zhou@nxp.com>
> > ---
> > Changes in v8:
> > - Use standard port reference instead of video-interfaces.yaml
>
> Why? Properties are not applicable?
>
> > - Add parent syscon node in example to show device integration
> > - Add required constraints for port@0 and port@1 in ports node
> >
> > Changes in v7:
> > - Change compatible to imx95-csi-formatter as IP is i.MX95 specific per Marco's suggestion
> > Link: https://lore.kernel.org/linux-media/20260511-csi_formatter-v6-0-01028e312e2b@oss.nxp.com/T/#mcd135b3de179b3cb69daa1fd6e0e8e27c85b3332
> > ---
> > .../bindings/media/fsl,imx95-csi-formatter.yaml | 92 ++++++++++++++++++++++
> > 1 file changed, 92 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/media/fsl,imx95-csi-formatter.yaml b/Documentation/devicetree/bindings/media/fsl,imx95-csi-formatter.yaml
> > new file mode 100644
> > index 000000000000..bc2f5d448fe5
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/media/fsl,imx95-csi-formatter.yaml
> > @@ -0,0 +1,92 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/media/fsl,imx95-csi-formatter.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: i.MX95 CSI Pixel Formatter
> > +
> > +maintainers:
> > + - Guoniu Zhou <guoniu.zhou@nxp.com>
> > +
> > +description:
> > + The CSI pixel formatting module found on i.MX95 uses packet info, pixel
> > + and non-pixel data from the CSI-2 host controller and reformat them to
> > + match Pixel Link(PL) definition.
> > +
> > +properties:
> > + compatible:
> > + const: fsl,imx95-csi-formatter
> > +
> > + reg:
> > + maxItems: 1
> > +
> > + clocks:
> > + maxItems: 1
> > +
> > + power-domains:
> > + maxItems: 1
> > +
> > + ports:
> > + $ref: /schemas/graph.yaml#/properties/ports
> > +
> > + properties:
> > + port@0:
> > + $ref: /schemas/graph.yaml#/properties/port
> > + description: MIPI CSI-2 RX IDI interface
> > +
> > + port@1:
> > + $ref: /schemas/graph.yaml#/properties/port
> > + description: Pixel Link Interface
> > +
> > + required:
> > + - port@0
> > + - port@1
> > +
> > +required:
> > + - compatible
> > + - reg
> > + - clocks
> > + - power-domains
> > + - ports
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > + - |
> > + #include <dt-bindings/clock/nxp,imx95-clock.h>
> > +
> > + syscon@4ac10000 {
> > + compatible = "nxp,imx95-camera-csr", "syscon";
>
> Drop entire node, not relevant. Or actually this example could be in the
> parent binding example.
I asked for this in the review of a previous version. The example only
stated "formatter@20" and it was not mentioned anywhere that the device
was supposed to be a child node of a syscon. The driver reads the reg
property and uses it as an offset to the regmap of the syscon, I wanted
to see where/how the node was meant to be integrated in DT.
> > + reg = <0x0 0x4ac10000 0x0 0x10000>;
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > +
> > + formatter@20 {
> > + compatible = "fsl,imx95-csi-formatter";
> > + reg = <0x20 0x100>;
> > + clocks = <&cameramix_csr IMX95_CLK_CAMBLK_CSI2_FOR0>;
> > + power-domains = <&scmi_devpd 3>;
> > +
> > + ports {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + port@0 {
> > + reg = <0>;
> > +
> > + endpoint {
> > + remote-endpoint = <&mipi_csi_0_out>;
> > + };
> > + };
> > +
> > + port@1 {
>
> Messed indentation.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH] irqchip/gic-v4: Harden against bogus command line
From: Marc Zyngier @ 2026-05-26 9:45 UTC (permalink / raw)
To: Mostafa Saleh; +Cc: linux-arm-kernel, linux-kernel, tglx
In-Reply-To: <ahVQtakwshwI9ss-@google.com>
On Tue, 26 May 2026 08:50:13 +0100,
Mostafa Saleh <smostafa@google.com> wrote:
>
> On Sat, May 23, 2026 at 10:53:23AM +0100, Marc Zyngier wrote:
> > On Thu, 21 May 2026 14:05:03 +0100,
> > Mostafa Saleh <smostafa@google.com> wrote:
> > >
> > > When accidentally setting “kvm-arm.vgic_v4_enable=1” on the wrong
> > > setup that has no MSI controller device tree node (it exists but
> > > not used) and GICv4, it caused a panic as “gic_domain” is NULL and
> > > the kernel attempted to access its ops.
> >
> > When you say "that has no MSI controller device tree node", does it
> > mean that the ITS has not been probed at all?
>
> Yes.
>
> >
> > >
> > > Originally, I hit this on an older kernel, but was able to reproduce
> > > it on upstream with Qemu by hacking this unreasonable setup.
> > >
> > > [ 33.145536] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000028
> > > [ 33.145658] Mem abort info:
> > > [ 33.145751] ESR = 0x0000000096000006
> > > ...
> > > [ 33.154057] CPU: 1 UID: 0 PID: 295 Comm: lkvm-static Not tainted 7.1.0-rc4-ge3f15ad3970e #5 PREEMPT
> > > [ 33.156922] Hardware name: linux,dummy-virt (DT)
> > > [ 33.158780] pstate: 81402005 (Nzcv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)
> > > [ 33.160340] pc : __irq_domain_instantiate+0x1d4/0x578
> > > [ 33.162602] lr : __irq_domain_instantiate+0x1cc/0x578
> > >
> > > Add a hardening check to avoid the NULL access, and fail the VM
> > > creation in that case.
> > >
> > > Signed-off-by: Mostafa Saleh <smostafa@google.com>
> > > ---
> > > drivers/irqchip/irq-gic-v4.c | 3 +++
> > > 1 file changed, 3 insertions(+)
> > >
> > > diff --git a/drivers/irqchip/irq-gic-v4.c b/drivers/irqchip/irq-gic-v4.c
> > > index 8455b4a5fbb0..7e39f7eae85f 100644
> > > --- a/drivers/irqchip/irq-gic-v4.c
> > > +++ b/drivers/irqchip/irq-gic-v4.c
> > > @@ -159,6 +159,9 @@ int its_alloc_vcpu_irqs(struct its_vm *vm)
> > > {
> > > int vpe_base_irq, i;
> > >
> > > + if (!gic_domain)
> > > + return -EINVAL;
> > > +
> > > vm->fwnode = irq_domain_alloc_named_id_fwnode("GICv4-vpe",
> > > task_pid_nr(current));
> > > if (!vm->fwnode)
> >
> > I think this check is a good few levels too late. If you want to fix
> > this, I'd rather make sure that kvm_vgic_global_state.has_gicv4 is
> > reliable and covers this case. Which means making sure that
> > gic_kvm_info::has_v4 is itself reliable.
> >
> > If my above understanding is correct, I'd expect the following
> > (untested) hack to help.
>
> Thanks! That also fixes the crash, the VM will launch with a vGIC with
> no ITS in that case.
You should still be able to have a virtual ITS, just no direct
injection of any sort.
If you're happy with that, please respin a patch with this hack.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [PATCH v15 0/3] of: parsing of multi #{iommu,msi}-cells in maps
From: Vijayanand Jitta @ 2026-05-26 9:45 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Nipun Gupta, Nikhil Agarwal, Joerg Roedel, Will Deacon,
Robin Murphy, Marc Zyngier, Lorenzo Pieralisi, Thomas Gleixner,
Saravana Kannan, Richard Zhu, Lucas Stach,
Krzysztof Wilczyński, Manivannan Sadhasivam, Bjorn Helgaas,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Juergen Gross, Stefano Stabellini, Oleksandr Tyshchenko,
Dmitry Baryshkov, Konrad Dybcio, Bjorn Andersson, Rob Herring,
Conor Dooley, Krzysztof Kozlowski, Prakash Gupta, Vikash Garodia,
linux-kernel, iommu, linux-arm-kernel, devicetree, linux-pci, imx,
xen-devel, linux-arm-msm, Charan Teja Kalla
In-Reply-To: <20260526-finicky-crafty-hare-eae27c@quoll>
On 5/26/2026 11:42 AM, Krzysztof Kozlowski wrote:
> On Wed, May 20, 2026 at 01:32:39PM +0530, Vijayanand Jitta wrote:
>> So far our parsing of {iommu,msi}-map properties has always blindly
>> assumed that the output specifiers will always have exactly 1 cell.
>> This typically does happen to be the case, but is not actually enforced
>> (and the PCI msi-map binding even explicitly states support for 0 or 1
>> cells) - as a result we've now ended up with dodgy DTs out in the field
>> which depend on this behaviour to map a 1-cell specifier for a 2-cell
>> provider, despite that being bogus per the bindings themselves.
>>
>> Since there is some potential use[1] in being able to map at least
>> single input IDs to multi-cell output specifiers (and properly support
>> 0-cell outputs as well), add support for properly parsing and using the
>> target nodes' #cells values, albeit with the unfortunate complication of
>> still having to work around expectations of the old behaviour too.
>> -- Robin.
>>
>> Unlike single #{}-cell, it is complex to establish a linear relation
>> between input 'id' and output specifier for multi-cell properties, thus
>> it is always expected that len never going to be > 1.
>>
>> These changes have been tested on QEMU for the arm64 architecture.
>
> So there is no real user for that. That's unconvincing. I would assume
> that at least you have real user where you test it.
>
> If you want to speed up acceptance of your patches, then also I would
> prefer to see at least one more user, beside Qualcomm. IOW, show how you
> solve other people problems, not only yours.
>
> Best regards,
> Krzysztof
>
Hi Krzysztof,
Thank you for the feedback.
The upstream user for the multi-cell iommu-map support is the Lemans
platform's VPU device, which requires iommu-map entries targeting a
2-cell IOMMU node. We are currently working on the glymur series [1]
and once that is finalized we will post the Lemans patches as well.
That said, I think this series can go through independently for the
following reasons:
1. Correctness fix: The iommu-map/msi-map bindings have always
specified that the output cell count is determined by
#iommu-cells/#msi-cells on the target node. The kernel has been
silently ignoring this and assuming 1 cell. This patch makes the
kernel respect the binding specification.
2. Backward compatibility preserved: The of_check_bad_map() workaround
handles existing deployed DTs that target 2-cell IOMMU nodes with
1-cell entries. This series has been tested on the glymur platform
[1], which uses iommu-map with 1-cell specifiers, and the existing
parsing continues to work correctly.
Thanks,
Vijay
[1] https://lore.kernel.org/all/20260515-glymur-v6-5-f6a99cb43a24@oss.qualcomm.com/
^ permalink raw reply
* Re: [PATCH] pinctrl: imx1: fix device_node leak in dt_is_flat_functions()
From: Linus Walleij @ 2026-05-26 9:46 UTC (permalink / raw)
To: Felix Gu
Cc: Dong Aisheng, Fabio Estevam, Frank Li, Jacky Bai,
Pengutronix Kernel Team, NXP S32 Linux Team, Sascha Hauer,
linux-gpio, imx, linux-arm-kernel, linux-kernel
In-Reply-To: <20260523-pinctrl-imx-v1-1-73b7cb731351@gmail.com>
On Sat, May 23, 2026 at 12:27 PM Felix Gu <ustc.gu@gmail.com> wrote:
> for_each_child_of_node() holds a reference on the iterator node that
> must be released on early return. imx1_pinctrl_dt_is_flat_functions()
> has two early return paths inside the loop that skip this cleanup.
>
> Replace both loops with the scoped variant so that the reference is
> automatically dropped when the iterator goes out of scope.
>
> Fixes: 63d2059cd665 ("pinctrl: imx1: Allow parsing DT without function nodes")
> Signed-off-by: Felix Gu <ustc.gu@gmail.com>
So what we got here is a non-critical patch on top of something that was
critical and was merged as fixes. (A minor memory leak is not critical
and not -rc material.)
Linus (the big penguin) has been annoyed of too many noncritical
patches going in as fixes recently so can you please resend this after
the next merge window? (I will try to remember the patch as well.)
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH RFC 00/12] arm64: mediatek: Add M.2 E-key slot on Chromebooks
From: Bartosz Golaszewski @ 2026-05-26 9:48 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Greg Kroah-Hartman, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Matthias Brugger, AngeloGioacchino Del Regno,
linux-pm, linux-usb, devicetree, linux-mediatek, linux-arm-kernel,
linux-kernel, Manivannan Sadhasivam
In-Reply-To: <CAGXv+5HC3dqgcE3KnKzakHHWFHB6m_X42orOkNUvZvp=SL_O8g@mail.gmail.com>
On Sun, May 24, 2026 at 10:06 AM Chen-Yu Tsai <wenst@chromium.org> wrote:
>
> > >
> > > I expect some discussion on this patch, because a) it adds some
> > > OF-specific code into an otherwise generic (core) driver, and
> > > b) it doesn't yet handle USB 2.0 / 3.x shared ports; it ends up powering
> > > on the port twice, which negates the port reset part.
> > >
> >
> > I understand that you do this because the port device has no OF node
> > assigned. If we wanted to call pwrseq_get() for the port device, is
> > there really no other way to associate it with the correct pwrseq
> > provider?
>
> I suppose we could tie the "port@X" node to the usb port device, but
> AFAIK no other subsystem does this so we would be introducing a new
> pattern.
>
> In the M.2 pwrseq driver, we would have to match by port node instead
> of its parent device node. We may end up with different behavior for
> the USB target vs the other targets.
>
I imagine, we can check the bus type of the parent device to know if
this is USB?
> Also, the "port@X" nodes only exist for the OF graph connections to
> connectors and/or muxes (this series doesn't deal with the latter).
> For directly connected devices, there is a "device@X" child node
> directly under the USB hub node. That node is what gets tied to the
> the USB device.
>
Is this a problem? I don't think I understand what you're saying here.
Bart
^ permalink raw reply
* Re: [PATCH] pinctrl: meson: amlogic-a4: fix gpio output glitch
From: Linus Walleij @ 2026-05-26 9:54 UTC (permalink / raw)
To: xianwei.zhao
Cc: Neil Armstrong, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
linux-amlogic, linux-gpio, linux-arm-kernel, linux-kernel
In-Reply-To: <20260518-fix-set-value-glitch-v1-1-d350732dc934@amlogic.com>
On Mon, May 18, 2026 at 10:26 AM Xianwei Zhao via B4 Relay
<devnull+xianwei.zhao.amlogic.com@kernel.org> wrote:
> From: Xianwei Zhao <xianwei.zhao@amlogic.com>
>
> When the system transitions from bootloader to kernel, the GPIO is
> expected to keep driving high.
>
> However, the Linux kernel first configures the pin direction and then
> sets the output value. This may cause a brief low-level glitch on the
> GPIO line, which can be problematic for regulator control.
>
> By configuring the output value before switching the pin direction to
> output, the glitch can be avoided.
>
> This commit fixes the issue by swapping the configuration order.
>
> Fixes: 6e9be3abb78c ("pinctrl: Add driver support for Amlogic SoCs")
> Signed-off-by: Xianwei Zhao <xianwei.zhao@amlogic.com>
Patch applied as non-critical fix based on my gut feeling.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 07/10] clk: amlogic: Support POWER_OF_TWO for PLL pre-divider
From: Jian Hu @ 2026-05-26 9:58 UTC (permalink / raw)
To: Jerome Brunet
Cc: Jian Hu via B4 Relay, Michael Turquette, Stephen Boyd,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
Xianwei Zhao, Kevin Hilman, Martin Blumenstingl, linux-kernel,
linux-clk, devicetree, linux-amlogic, linux-arm-kernel
In-Reply-To: <1jqzn65y9l.fsf@starbuckisacylon.baylibre.com>
On 5/20/2026 3:35 PM, Jerome Brunet wrote:
> [ EXTERNAL EMAIL ]
>
> On mer. 20 mai 2026 at 13:47, Jian Hu <jian.hu@amlogic.com> wrote:
>
>> On 5/14/2026 11:11 PM, Jerome Brunet wrote:
>>> [ EXTERNAL EMAIL ]
>>>
>>> On lun. 11 mai 2026 at 20:47, Jian Hu via B4 Relay <devnull+jian.hu.amlogic.com@kernel.org> wrote:
>>>
>>>> From: Jian Hu <jian.hu@amlogic.com>
>>>>
>>>> The A9 PLL pre-divider uses a division factor of 2^n to ensure a clock
>>>> duty cycle of 50% after predivision.
>>>>
>>>> Add flag 'CLK_MESON_PLL_N_POWER_OF_TWO' to indicate that the PLL
>>>> pre-divider division factor is 2^n.
>>> I understand what you are doing here but I have to ask why this can't be
>>> implemented with independent dividers that already supports power of 2 ?
>>
>> If we use independent dividers, the n member would have to be removed from
>> meson_clk_pll_data.
>>
>> However, n is referenced 35 times in clk-pll.c, which means we would need
>> to modify all
>> related logic across the file. This would be a relatively large
>> change.
> Yes
>
>>
>> Moreover, for all Amlogic chips, the n divider is an indispensable part of
>> the DCO clock.
> There is hardly a justification here
>
>> The difference between SoC generations is as follows:
>> Previous SoCs PLL: n = 1, 2, 3, 4... (linear divider)
>> A9 SoC PLL: n = 2^0, 2^1, 2^2, 2^3, 2^4... (power-of-two
>> divider)
> Yes that was fairly obvious
>
>> Therefore, splitting out the n divider from the DCO clock might not be a
>> good design choice.
> I'm not sure I agree and you've only stated your point of view without
> providing any technical justification here.
>
> From the datasheets of the different SoC we have, the documented
> limitation is always the DCO output rate range. Nothing related to n (or
> m, or the mult-range for that matter). This is a legacy problem, we
> started with monolithic driver and slowly simplified it.
>
> As far as I can see now, reworking the PLL driver to be a simple
> multiplier driver with range output rate constraint could actually be
> simpler than the current code. I would also make simpler to accomodate
> differences such as the one presented here.
>
> Unless you can provide technical reasons why going in this direction
> would be incorrect, that's where I'd prefer to go.
>
>> [...]
>>
>> Best regards,
>>
>> Jian
> --
> Jerome
I agree that having an independent N divider would simplify the PLL rate
calculation.
A separate pre-divider for N is technically possible, but there are some
hardware constraints that need to be considered:
N = 1 is the preferred operating mode except a few fixed-frequency PLLs.
Larger N values reduce the PLL phase detector frequency, which may
negatively impact
jitter performance and overall PLL stability.
Because of this, we cannot guarantee stable system operation when
arbitrary larger
N values are used.
Some PLLs require non-1 N values to generate specific fixed output
frequencies because
the target rate cannot be achieved with N = 1 while keeping the PLL
while keeping the
PLL within its valid operating range. So N is designed to have other
values to
satisfy this requirement.
For example, the AXG PCIe PLL uses N = 3 to generate the required 100
MHz output frequency,
since the target frequency cannot be achieved with N = 1.
Additionally, is the refactored pre-divider N implemented as a separate
patchset,
independent from the A9 PLL changes?
Best regards,
Jian
^ permalink raw reply
* Re: [PATCH 00/10] Add support for A9 family clock controller
From: Jian Hu @ 2026-05-26 10:05 UTC (permalink / raw)
To: Jerome Brunet, Jian Hu via B4 Relay
Cc: Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Neil Armstrong, Xianwei Zhao, Kevin Hilman,
Martin Blumenstingl, linux-kernel, linux-clk, devicetree,
linux-amlogic, linux-arm-kernel
In-Reply-To: <1jldd662x1.fsf@starbuckisacylon.baylibre.com>
On 5/26/2026 3:33 PM, Jerome Brunet wrote:
> [ EXTERNAL EMAIL ]
>
> On lun. 11 mai 2026 at 20:47, Jian Hu via B4 Relay <devnull+jian.hu.amlogic.com@kernel.org> wrote:
>
>> There are 4 clock controllers in A9 SoC:
>> - SCMI clock controller: these clocks are managed by the
>> Trusted Firmware-A(TF-A) and handled through SCMI.
>> - PLL clock controller.
>> - peripheral clock controller.
>> - AO clock controller.
>>
>> There are reserved register regions placed between individual PLLs, so a
>> separate driver is implemented for each PLL, similar to T7.
>>
>> Compared to previous SoCs PLLs, the A9 PLL controller introduces 4 new features:
>> 1.PLL l_detect signal supports active-high configuration.
>> Previous A7 and T7 l_detect signals are active-low.
>> 2.PLL reset signal supports active-low configuration.
>> Previous reset signals are active-high.
>> 3.Support POWER_OF_TWO for the PLL pre-divider N;
>> the N pre-divider follows the same calculation rule as OD.
>> 4.The PLL input path includes an inherent divide-by-2 divider.
>>
>> Implement the first three features in clk-pll.c (verified on A9 and T7),
>> with no impact to PLL logic on existing SoCs. Add a fixed divide-by-2 to
>> A9 PLL driver for the fourth feature.
>>
>> A9 PLL is composed as follows:
>>
>> PLL
>> +---------------------------------+
>> | |
>> | +--+ |
>> in/2 >>---[ /2^N ]-->| | +-----+ |
>> | | |------| DCO |----->> out
>> | +--------->| | +--v--+ |
>> | | +--+ | |
>> | | | |
>> | +--[ *(M + (F/Fmax) ]<--+ |
>> | |
>> +---------------------------------+
>>
>> out = in / 2 * (m + frac / frac_max) / 2^n
>>
>> Signed-off-by: Jian Hu <jian.hu@amlogic.com>
>> ---
>> Jian Hu (10):
>> dt-bindings: clock: Add Amlogic A9 SCMI clock controller
>> dt-bindings: clock: Add Amlogic A9 PLL clock controller
>> dt-bindings: clock: Add Amlogic A9 peripherals clock controller
>> dt-bindings: clock: Add Amlogic A9 AO clock controller
>> clk: amlogic: PLL l_detect signal supports active-high configuration
>> clk: amlogic: PLL reset signal supports active-low configuration
>> clk: amlogic: Support POWER_OF_TWO for PLL pre-divider
>> clk: amlogic: Add A9 PLL clock controller driver
>> clk: amlogic: Add A9 peripherals clock controller driver
>> clk: amlogic: Add A9 AO clock controller driver
>>
>> .../bindings/clock/amlogic,a9-aoclkc.yaml | 76 +
>> .../clock/amlogic,a9-peripherals-clkc.yaml | 150 ++
>> .../bindings/clock/amlogic,a9-pll-clkc.yaml | 110 +
>> drivers/clk/meson/Kconfig | 28 +
>> drivers/clk/meson/Makefile | 2 +
>> drivers/clk/meson/a9-aoclk.c | 494 +++++
>> drivers/clk/meson/a9-peripherals.c | 2317 ++++++++++++++++++++
>> drivers/clk/meson/a9-pll.c | 831 +++++++
>> drivers/clk/meson/clk-pll.c | 79 +-
>> drivers/clk/meson/clk-pll.h | 6 +
>> include/dt-bindings/clock/amlogic,a9-aoclkc.h | 76 +
>> .../clock/amlogic,a9-peripherals-clkc.h | 352 +++
>> include/dt-bindings/clock/amlogic,a9-pll-clkc.h | 55 +
>> include/dt-bindings/clock/amlogic,a9-scmi-clkc.h | 51 +
>> 14 files changed, 4609 insertions(+), 18 deletions(-)
> For the next version, please split things up.
> There is no hard dependency between the different controllers. This will
> ease the review.
>
> The PLL controllers are bringing a new contraints in. The global/static
> nature of the controllers is something that has been bothering me for a
> while but there was no real reason to address it so far. Please give me
> some time to think about. Feel free to re-post the other controllers in the
> meantime.
Ok. I will split the series and re-post the SCMI, peripherals, and aoclk
controllers separately.
Best regards,
Jian
>> ---
>> base-commit: ca89c88bcf69daca829044c638a8163d5ce47af0
>> change-id: 20260511-b4-a9_clk-67652c1ae56e
>>
>> Best regards,
> --
> Jerome
^ permalink raw reply
* [PATCH v7 4/7] ARM: dts: stm32: Sort uart nodes by alphabetical order in stm32mp13xx-dhcor-som.dtsi
From: Patrice Chotard @ 2026-05-26 9:26 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Maxime Coquelin,
Alexandre Torgue, Patrick Delaunay, Christoph Niedermaier,
Marek Vasut
Cc: devicetree, linux-stm32, linux-arm-kernel, linux-kernel, kernel,
Patrice Chotard
In-Reply-To: <20260526-upstream_uboot_properties-v7-0-e17cd424d5db@foss.st.com>
Sort uart4 and uart7 nodes by alphabetical order.
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
---
arch/arm/boot/dts/st/stm32mp13xx-dhcor-som.dtsi | 56 ++++++++++++-------------
1 file changed, 28 insertions(+), 28 deletions(-)
diff --git a/arch/arm/boot/dts/st/stm32mp13xx-dhcor-som.dtsi b/arch/arm/boot/dts/st/stm32mp13xx-dhcor-som.dtsi
index c18156807027..54ece71085c1 100644
--- a/arch/arm/boot/dts/st/stm32mp13xx-dhcor-som.dtsi
+++ b/arch/arm/boot/dts/st/stm32mp13xx-dhcor-som.dtsi
@@ -241,34 +241,6 @@ flash0: flash@0 {
};
};
-/* Console UART */
-&uart4 {
- pinctrl-names = "default", "sleep", "idle";
- pinctrl-0 = <&uart4_pins_b>;
- pinctrl-1 = <&uart4_sleep_pins_b>;
- pinctrl-2 = <&uart4_idle_pins_b>;
- /delete-property/dmas;
- /delete-property/dma-names;
- status = "okay";
-};
-
-/* Bluetooth */
-&uart7 {
- pinctrl-names = "default", "sleep", "idle";
- pinctrl-0 = <&uart7_pins_a>;
- pinctrl-1 = <&uart7_sleep_pins_a>;
- pinctrl-2 = <&uart7_idle_pins_a>;
- uart-has-rtscts;
- status = "okay";
-
- bluetooth {
- compatible = "infineon,cyw43439-bt", "brcm,bcm4329-bt";
- max-speed = <3000000>;
- device-wakeup-gpios = <&gpiog 9 GPIO_ACTIVE_HIGH>;
- shutdown-gpios = <&gpioi 2 GPIO_ACTIVE_HIGH>;
- };
-};
-
/* SDIO WiFi */
&sdmmc1 {
pinctrl-names = "default", "opendrain", "sleep";
@@ -312,3 +284,31 @@ &sdmmc2 {
vqmmc-supply = <&vdd>;
status = "okay";
};
+
+/* Console UART */
+&uart4 {
+ pinctrl-names = "default", "sleep", "idle";
+ pinctrl-0 = <&uart4_pins_b>;
+ pinctrl-1 = <&uart4_sleep_pins_b>;
+ pinctrl-2 = <&uart4_idle_pins_b>;
+ /delete-property/dmas;
+ /delete-property/dma-names;
+ status = "okay";
+};
+
+/* Bluetooth */
+&uart7 {
+ pinctrl-names = "default", "sleep", "idle";
+ pinctrl-0 = <&uart7_pins_a>;
+ pinctrl-1 = <&uart7_sleep_pins_a>;
+ pinctrl-2 = <&uart7_idle_pins_a>;
+ uart-has-rtscts;
+ status = "okay";
+
+ bluetooth {
+ compatible = "infineon,cyw43439-bt", "brcm,bcm4329-bt";
+ max-speed = <3000000>;
+ device-wakeup-gpios = <&gpiog 9 GPIO_ACTIVE_HIGH>;
+ shutdown-gpios = <&gpioi 2 GPIO_ACTIVE_HIGH>;
+ };
+};
--
2.43.0
^ permalink raw reply related
* Re: [PATCH 0/2] i2c: cadence: Add support for Axiado AX3000
From: Swark Yang @ 2026-05-26 10:14 UTC (permalink / raw)
To: Michal Simek, Andi Shyti, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-kernel, linux-i2c, devicetree, linux-kernel, openbmc
In-Reply-To: <20260426-axiado-ax3000-cadence-i2c-support-v1-0-0cb9346a7fb5@axiado.com>
Hi,
Gentle ping on this patch series.
Patch 1/2 (dt-bindings) has already received an Acked-by from Conor.
I wanted to kindly check if you have any comments or feedback regarding
the driver changes in Patch 2/2.
Please let me know if any further adjustments are needed.
Best Regards,
Swark
Swark Yang 於 2026/4/27 上午 11:57 寫道:
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
>
>
> This patch series adds support for the Cadence I2C controller
> integrated into the Axiado AX3000 SoC and enables SMBus Quick
> command functionality.
>
> The Axiado AX3000 utilizes the Cadence I2C IP core (version r1p14).
> While it is largely compatible with the existing i2c-cadence
> driver logic, the AX3000 hardware specifically supports SMBus Quick
> commands. This feature is currently disabled by default in the
> i2c-cadence driver (masked out from I2C_FUNC_SMBUS_EMUL).
>
> To enable this functionality, this series introduces a new
> platform-specific quirk (CDNS_I2C_QUIRK_SMBUS_QUICK) and uses driver
> match data for the "axiado,ax3000-i2c" compatible string. This allows
> tools like 'i2cdetect' to properly scan the bus using quick write
> commands.
>
> The DT binding update follows the recommended fallback structure,
> referencing the 'cdns,i2c-r1p14' fallback to ensure compatibility with
> older kernels while allowing the new quirk to be enabled on AX3000.
>
> Patch breakdown:
>
> Patch 1: dt-bindings: i2c: cadence: Add Axiado AX3000
> Patch 2: i2c: cadence: Add support for Axiado AX3000
>
> These patches are expected to go via the I2C subsystem tree.
>
> Feedback is welcome.
>
> Signed-off-by: Swark Yang <syang@axiado.com>
> ---
> Swark Yang (2):
> dt-bindings: i2c: cadence: Add Axiado AX3000
> i2c: cadence: Add support for Axiado AX3000
>
> Documentation/devicetree/bindings/i2c/cdns,i2c-r1p10.yaml | 10 +++++++---
> drivers/i2c/busses/i2c-cadence.c | 10 ++++++++++
> 2 files changed, 17 insertions(+), 3 deletions(-)
> ---
> base-commit: 63804fed149a6750ffd28610c5c1c98cce6bd377
> change-id: 20260111-axiado-ax3000-cadence-i2c-support-53ec117bb074
>
> Best regards,
> --
> Swark Yang <syang@axiado.com>
>
^ permalink raw reply
* Re: [PATCH] KVM: arm64: Preserve all guest ZCR_EL2.LEN values
From: Mark Brown @ 2026-05-26 10:19 UTC (permalink / raw)
To: Mark Rutland
Cc: Marc Zyngier, Oliver Upton, Joey Gouly, Steffen Eiden,
Suzuki K Poulose, Catalin Marinas, Will Deacon, linux-arm-kernel,
kvmarm, linux-kernel
In-Reply-To: <ahSWwl-uCv4ZW-nE@J2N7QTR9R3>
[-- Attachment #1: Type: text/plain, Size: 1374 bytes --]
On Mon, May 25, 2026 at 07:36:50PM +0100, Mark Rutland wrote:
> On Fri, May 22, 2026 at 07:00:04PM +0100, Mark Brown wrote:
> > Since b3d29a823099 ("KVM: arm64: nv: Handle ZCR_EL2 traps") when guests
> > write to ZCR_EL2 we have clamped the value of ZCR_EL2.LEN to be at most
> > that configuring the maximum guest VL. This is not the behaviour the
...
> Have we sought feedback from architects? While I said "*or* the
> architcture requires a clarification", I think it should be clarified
> more explicitly either way given that the pattern is unusual.
> Given this is particularly subtle, please keep me in the loop when
> speaking with architects about this.
TBH it didn't strike me as subtle, I don't see anything in the
architecture which would lead me to expect the current behaviour. The
psudocode all just has direct assignments for the write and there's
language in the ARM (eg, in the ZCR_EL2 description) saying "for all
purposes other than returning the result of a direct read of ZCR_EL2"
which seems specifically intended to cover there being a divergence
between the written and effective values, though I guess it doesn't
explicitly mention writes in the text.
When I saw the code it looked like something KVM was doing for some
KVM reason that was obscure to me, the lack of clarity seemed like it
was on the KVM side.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [PATCH v4] i2c: davinci: fix division by zero on missing clock-frequency
From: Chaitanya Sabnis @ 2026-05-26 10:22 UTC (permalink / raw)
To: brgl, andi.shyti
Cc: linux-arm-kernel, linux-i2c, linux-kernel, Chaitanya Sabnis,
Sashiko, Bartosz Golaszewski
When the 'clock-frequency' property is missing from the device tree,
the driver falls back to DAVINCI_I2C_DEFAULT_BUS_FREQ. However, this
macro was defined in kHz (100), whereas the device tree property is
expected in Hz.
The probe function divided the fallback value by 1000, causing
integer truncation that resulted in dev->bus_freq = 0. This triggered
a deterministic division-by-zero kernel panic when calculating clock
dividers later in the probe sequence.
Fix this by redefining DAVINCI_I2C_DEFAULT_BUS_FREQ in Hz (100000)
to match the expected device tree property unit, allowing the existing
division logic to work correctly for both cases.
Fixes: b04ce6385979 ("i2c: davinci: kill platform data")
Reported-by: Sashiko <sashiko-bot@kernel.org>
Closes: https://lore.kernel.org/all/20260514044726.57297C2BCB7@smtp.kernel.org/
Signed-off-by: Chaitanya Sabnis <chaitanya.msabnis@gmail.com>
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
---
Changes in v4:
- Restored accidentally removed blank lines (removed ninja changes).
- Collected Reviewed-by tag.
Changes in v3:
- Reverted probe function changes and correctly applied the fix to the macro.
Changes in v2:
- Changed approach: updated macro to Hz instead of dividing in probe.
- Added Fixes tag.
drivers/i2c/busses/i2c-davinci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/i2c-davinci.c b/drivers/i2c/busses/i2c-davinci.c
index a773ba082321..66c23535656b 100644
--- a/drivers/i2c/busses/i2c-davinci.c
+++ b/drivers/i2c/busses/i2c-davinci.c
@@ -117,7 +117,7 @@
/* timeout for pm runtime autosuspend */
#define DAVINCI_I2C_PM_TIMEOUT 1000 /* ms */
-#define DAVINCI_I2C_DEFAULT_BUS_FREQ 100
+#define DAVINCI_I2C_DEFAULT_BUS_FREQ 100000
struct davinci_i2c_dev {
struct device *dev;
--
2.43.0
^ permalink raw reply related
* [PATCH] [net-next] net: dsa: netc: fix enetc dependencies
From: Arnd Bergmann @ 2026-05-26 10:26 UTC (permalink / raw)
To: Wei Fang, Claudiu Manoil, Clark Wang, Christophe Leroy (CS GROUP)
Cc: Arnd Bergmann, Andrew Lunn, Vladimir Oltean, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, imx, netdev,
linux-kernel, linuxppc-dev, linux-arm-kernel
From: Arnd Bergmann <arnd@arndb.de>
The newly added netc dsa support has incorrect Kconfig dependencies,
leading to Kconfig and link failures:
WARNING: unmet direct dependencies detected for FSL_ENETC_MDIO
Depends on [n]: NETDEVICES [=y] && ETHERNET [=n] && NET_VENDOR_FREESCALE [=n] && PCI [=y] && PHYLIB [=y]
Selected by [y]:
- NET_DSA_NETC_SWITCH [=y] && NETDEVICES [=y] && (ARM64 || COMPILE_TEST [=y]) && NET_DSA [=y] && PCI [=y]
WARNING: unmet direct dependencies detected for NXP_NTMP
Depends on [n]: NETDEVICES [=y] && ETHERNET [=n] && NET_VENDOR_FREESCALE [=n]
Selected by [m]:
- NET_DSA_NETC_SWITCH [=m] && NETDEVICES [=y] && (ARM64 || COMPILE_TEST [=y]) && NET_DSA [=m] && PCI [=y]
ERROR: modpost: "enetc_mdio_read_c22" [drivers/net/dsa/netc/nxp-netc-switch.ko] undefined!
ERROR: modpost: "ntmp_fdbt_delete_entry" [drivers/net/dsa/netc/nxp-netc-switch.ko] undefined!
ERROR: modpost: "enetc_mdio_read_c45" [drivers/net/dsa/netc/nxp-netc-switch.ko] undefined!
Add the required 'NET_VENDOR_FREESCALE' dependency to make it possible
to select both the PHY and NTMP library modules. Originally this was
meant to be done through an 'IS_REACHABLE' check in the header file,
but that did not work because the drivers/net/ethernet/freescale
directory is not even entered in this case. IS_REACHABLE() is generally
counterproductive because even when it works as intended, it turns
a helpful link-time error into a silent runtime failure that is
harder to debug. In this case, it clearly did not even do anything.
Fixes: 187fbae024c8 ("net: dsa: netc: introduce NXP NETC switch driver for i.MX94")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/net/dsa/netc/Kconfig | 1 +
include/linux/fsl/enetc_mdio.h | 22 ----------------------
2 files changed, 1 insertion(+), 22 deletions(-)
diff --git a/drivers/net/dsa/netc/Kconfig b/drivers/net/dsa/netc/Kconfig
index d2f78d74ac23..eaad3cb5babe 100644
--- a/drivers/net/dsa/netc/Kconfig
+++ b/drivers/net/dsa/netc/Kconfig
@@ -1,6 +1,7 @@
# SPDX-License-Identifier: GPL-2.0-only
config NET_DSA_NETC_SWITCH
tristate "NXP NETC Ethernet switch support"
+ depends on NET_VENDOR_FREESCALE
depends on ARM64 || COMPILE_TEST
depends on NET_DSA && PCI
select NET_DSA_TAG_NETC
diff --git a/include/linux/fsl/enetc_mdio.h b/include/linux/fsl/enetc_mdio.h
index 623ccfcbf39c..7cd5be694cc4 100644
--- a/include/linux/fsl/enetc_mdio.h
+++ b/include/linux/fsl/enetc_mdio.h
@@ -35,8 +35,6 @@ struct enetc_mdio_priv {
int mdio_base;
};
-#if IS_REACHABLE(CONFIG_FSL_ENETC_MDIO)
-
int enetc_mdio_read_c22(struct mii_bus *bus, int phy_id, int regnum);
int enetc_mdio_write_c22(struct mii_bus *bus, int phy_id, int regnum,
u16 value);
@@ -45,24 +43,4 @@ int enetc_mdio_write_c45(struct mii_bus *bus, int phy_id, int devad, int regnum,
u16 value);
struct enetc_hw *enetc_hw_alloc(struct device *dev, void __iomem *port_regs);
-#else
-
-static inline int enetc_mdio_read_c22(struct mii_bus *bus, int phy_id,
- int regnum)
-{ return -EINVAL; }
-static inline int enetc_mdio_write_c22(struct mii_bus *bus, int phy_id,
- int regnum, u16 value)
-{ return -EINVAL; }
-static inline int enetc_mdio_read_c45(struct mii_bus *bus, int phy_id,
- int devad, int regnum)
-{ return -EINVAL; }
-static inline int enetc_mdio_write_c45(struct mii_bus *bus, int phy_id,
- int devad, int regnum, u16 value)
-{ return -EINVAL; }
-static inline struct enetc_hw *enetc_hw_alloc(struct device *dev,
- void __iomem *port_regs)
-{ return ERR_PTR(-EINVAL); }
-
-#endif
-
#endif
--
2.39.5
^ permalink raw reply related
* [PATCH] firmware: arm_ffa: Treat missing FF-A feature on a platform as a probe miss
From: Sudeep Holla @ 2026-05-26 10:36 UTC (permalink / raw)
To: linux-security-module, linux-kernel, linux-integrity,
linux-arm-kernel, kvmarm
Cc: Sudeep Holla, Yeoreum Yun, Nathan Chancellor
When FF-A initialisation is driven from a platform device probe, systems
that do not implement FF-A can return -EOPNOTSUPP from the early transport
or version discovery paths. Driver core treats that as a matched probe
failure and prints:
| arm-ffa arm-ffa: probe with driver arm-ffa failed with error -95
That is noisy for a firmware interface that can be absent on otherwise
valid systems. Driver core already treats -ENODEV and -ENXIO as quiet
rejected matches, so translate only the early unsupported discovery cases
to -ENODEV. Keep later setup failures unchanged so real FF-A
initialisation problems are still reported as probe failures.
Reported-by: Nathan Chancellor <nathan@kernel.org>
Closes: https://lore.kernel.org/all/20260523001148.GA1319283@ax162
Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
---
drivers/firmware/arm_ffa/driver.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/firmware/arm_ffa/driver.c b/drivers/firmware/arm_ffa/driver.c
index 54984e1b9741..0f468362c288 100644
--- a/drivers/firmware/arm_ffa/driver.c
+++ b/drivers/firmware/arm_ffa/driver.c
@@ -2109,7 +2109,7 @@ static int ffa_probe(struct platform_device *pdev)
ret = ffa_transport_init(&invoke_ffa_fn);
if (ret)
- return ret;
+ return ret == -EOPNOTSUPP ? -ENODEV : ret;
drv_info = kzalloc_obj(*drv_info);
if (!drv_info)
@@ -2117,8 +2117,11 @@ static int ffa_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, drv_info);
ret = ffa_version_check(&drv_info->version);
- if (ret)
+ if (ret) {
+ if (ret == -EOPNOTSUPP)
+ ret = -ENODEV;
goto free_drv_info;
+ }
if (ffa_id_get(&drv_info->vm_id)) {
pr_err("failed to obtain VM id for self\n");
--
2.43.0
^ permalink raw reply related
* [PATCH] usb: udc: pxa: fix error handling
From: Arnd Bergmann @ 2026-05-26 10:47 UTC (permalink / raw)
To: Daniel Mack, Haojian Zhuang, Robert Jarzmik, Greg Kroah-Hartman,
Andy Shevchenko, Arnd Bergmann
Cc: Dan Carpenter, linux-arm-kernel, linux-usb, linux-kernel
From: Arnd Bergmann <arnd@arndb.de>
As Dan Carpenter points out, my recent change makes subtle
changes to the error handling that were not intended.
Move the warning print up so it does not get skipped in
case of an error, but handle -EPROBE_DEFER properly now.
Change the devm_gpiod_get() to the _optional variant, which
is in line with the intended behavior and the DT binding,
though this did not work previously.
Reported-by: Dan Carpenter <error27@gmail.com>
Link: https://lore.kernel.org/linux-usb/ag6-xhfFjb5NpXQz@stanley.mountain/
Fixes: 25bd55f46032 ("usb: udc: pxa: remove unused platform_data")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/usb/gadget/udc/pxa27x_udc.c | 10 +++-------
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/usb/gadget/udc/pxa27x_udc.c b/drivers/usb/gadget/udc/pxa27x_udc.c
index 640f81988c04..df5cca43afbe 100644
--- a/drivers/usb/gadget/udc/pxa27x_udc.c
+++ b/drivers/usb/gadget/udc/pxa27x_udc.c
@@ -2374,9 +2374,10 @@ static int pxa_udc_probe(struct platform_device *pdev)
struct pxa_udc *udc = &memory;
int retval = 0;
- udc->gpiod = devm_gpiod_get(&pdev->dev, NULL, GPIOD_ASIS);
+ udc->gpiod = devm_gpiod_get_optional(&pdev->dev, NULL, GPIOD_ASIS);
if (IS_ERR(udc->gpiod))
- return PTR_ERR(udc->gpiod);
+ return dev_err_probe(&pdev->dev, PTR_ERR(udc->gpiod),
+ "Couldn't find or request D+ gpio\n");
udc->regs = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(udc->regs))
@@ -2395,11 +2396,6 @@ static int pxa_udc_probe(struct platform_device *pdev)
udc->transceiver = usb_get_phy(USB_PHY_TYPE_USB2);
}
- if (IS_ERR(udc->gpiod)) {
- dev_err(&pdev->dev, "Couldn't find or request D+ gpio : %ld\n",
- PTR_ERR(udc->gpiod));
- return PTR_ERR(udc->gpiod);
- }
if (udc->gpiod)
gpiod_direction_output(udc->gpiod, 0);
--
2.39.5
^ permalink raw reply related
* Re: [PATCH v2] net: stmmac: fix RX DMA leak on TX alloc failure
From: Paolo Abeni @ 2026-05-26 10:49 UTC (permalink / raw)
To: Abid Ali, devnull+dev.taqnialabs.gmail.com
Cc: alexandre.torgue, andrew+netdev, davem, edumazet, kuba,
linux-arm-kernel, linux-kernel, linux-stm32, mcoquelin.stm32,
netdev
In-Reply-To: <20260523121708.564-1-dev.taqnialabs@gmail.com>
On 5/23/26 2:17 PM, Abid Ali wrote:
>> ret = alloc_dma_tx_desc_resources(priv, dma_conf);
>> + if (ret)
>> + free_dma_rx_desc_resources(priv, dma_conf);
>>
>> return ret;
>> }
>
> The sashiko-gemini analysis [1] flagged two issues.
>
> 1) Double-free via XDP path:
>
> stmmac_xdp_set_prog() ignores the return of stmmac_xdp_open(), so
> if alloc_dma_tx_desc_resources() fails inside that path,
> rx_q->buf_pool and rx_q->dma_rx are freed for Rx queues.
>
> The interface stays UP, so a later stmmac_release() calls
> free_dma_desc_resources() on the same freed pointers.
>
> Without this patch, the same failure path leaks RX resources
> instead. Either way the root cause seems to be stmmac_xdp_set_prog() not
> handling errors from stmmac_xdp_open().
>
> The reported issue seems to be valid, but I'm not sure why XDP doesn't handle
> a possible error in reinit in the first place.
>
> 2) NULL deref on partial queue alloc:
>
> If alloc_dma_rx_desc_resources() fails for queue N,
> e.g. rx_q->page_pool = page_pool_create() fails, buf_pool is NULL.
> The cleanup free_dma_rx_desc_resources() iterates through all
> queues and will hit a NULL pointer deref in:
>
> static void stmmac_free_rx_buffer(struct stmmac_priv *priv,
> struct stmmac_rx_queue *rx_q,
> int i)
> {
> struct stmmac_rx_buffer *buf = &rx_q->buf_pool[i];
>
> The same could happen without the patch, and similar risk exists for
> rx_q->buf_pool, rx_q->dma_rx, and rx_q->dma_erx which are all freed
> without guards in __free_dma_rx_desc_resources().
>
> I can add the necessary NULL guards in __free_dma_rx_desc_resources()
> for V3 if necessary.
My take is following: even if the sashiko reported issues are
pre-existing, they are so strictly tied to this code path that it makes
sense to address all of them together (different patches in the same
series).
Also all of the above looks like 'net' material, deserving fixes tag in
each patch.
/P
^ 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