* [PATCH v2 2/4] drm/ssd130x: Add RGB565 support to SSD133X family
From: Amit Barzilai @ 2026-06-22 15:25 UTC (permalink / raw)
To: javierm, maarten.lankhorst, mripard, tzimmermann, airlied, simona,
robh, krzk+dt, conor+dt, andy, gregkh, deller
Cc: azuddinadam, chintanlike, dri-devel, devicetree, linux-kernel,
linux-fbdev, linux-staging, Amit Barzilai
In-Reply-To: <20260622152506.78627-1-amit.barzilai22@gmail.com>
SSD133X screens were getting 8bpp (RGB332) instead of the 16bpp
(RGB565) that they support. This change adds a boolean to the
deviceinfo struct selecting whether the variant is driven at
DRM_FORMAT_RGB565.
Changed SSD133X to now utilize 65k color (RGB565).
Assisted-by: Claude:claude-opus-4-8
Signed-off-by: Amit Barzilai <amit.barzilai22@gmail.com>
---
drivers/gpu/drm/solomon/ssd130x.c | 55 +++++++++++++++++++++++++------
drivers/gpu/drm/solomon/ssd130x.h | 7 ++++
2 files changed, 52 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/solomon/ssd130x.c b/drivers/gpu/drm/solomon/ssd130x.c
index 04da4f2f7d08..2b0a8218f529 100644
--- a/drivers/gpu/drm/solomon/ssd130x.c
+++ b/drivers/gpu/drm/solomon/ssd130x.c
@@ -140,6 +140,12 @@
#define SSD133X_SET_PRECHARGE_VOLTAGE 0xbb
#define SSD133X_SET_VCOMH_VOLTAGE 0xbe
+/* ssd133x remap byte (data of SSD13XX_SET_SEG_REMAP) */
+#define SSD133X_SET_REMAP_COM_SPLIT BIT(5)
+#define SSD133X_SET_REMAP_COLOR_DEPTH_MASK GENMASK(7, 6)
+#define SSD133X_COLOR_DEPTH_256 0x0
+#define SSD133X_COLOR_DEPTH_65K 0x1
+
#define MAX_CONTRAST 255
const struct ssd130x_deviceinfo ssd130x_variants[] = {
@@ -206,6 +212,7 @@ const struct ssd130x_deviceinfo ssd130x_variants[] = {
[SSD1331_ID] = {
.default_width = 96,
.default_height = 64,
+ .format_rgb565 = 1,
.family_id = SSD133X_FAMILY,
}
};
@@ -584,6 +591,10 @@ static int ssd132x_init(struct ssd130x_device *ssd130x)
static int ssd133x_init(struct ssd130x_device *ssd130x)
{
+ u8 remap = SSD133X_SET_REMAP_COM_SPLIT |
+ FIELD_PREP(SSD133X_SET_REMAP_COLOR_DEPTH_MASK,
+ ssd130x->device_info->format_rgb565 ?
+ SSD133X_COLOR_DEPTH_65K : SSD133X_COLOR_DEPTH_256);
const u8 cmds[] = {
2, SSD133X_CONTRAST_A, 0x91,
2, SSD133X_CONTRAST_B, 0x50,
@@ -595,9 +606,9 @@ static int ssd133x_init(struct ssd130x_device *ssd130x)
* Horizontal Address Increment
* Normal order SA,SB,SC (e.g. RGB)
* COM Split Odd Even
- * 256 color format
+ * 256 or 65k color format, depending on the variant
*/
- 2, SSD13XX_SET_SEG_REMAP, 0x20,
+ 2, SSD13XX_SET_SEG_REMAP, remap,
2, SSD133X_SET_DISPLAY_START, 0x00,
2, SSD133X_SET_DISPLAY_OFFSET, 0x00,
1, SSD133X_SET_DISPLAY_NORMAL,
@@ -794,14 +805,20 @@ static int ssd133x_update_rect(struct ssd130x_device *ssd130x,
* COM0 to COM[N - 1] are the rows and SEG0 to SEG[M - 1] are
* the columns.
*
- * Each Segment has a 8-bit pixel and each Common output has a
- * row of pixels. When using the (default) horizontal address
- * increment mode, each byte of data sent to the controller has
- * a Segment (e.g: SEG0).
+ * Each Segment holds one pixel and each Common output has a row
+ * of pixels. A pixel is 8 bits (one byte) in the 256 color
+ * (RGB332) format or 16 bits (two bytes) in the 65k color
+ * (RGB565) format. When using the (default) horizontal address
+ * increment mode, the pixel data is sent Segment by Segment
+ * (e.g: SEG0 first).
*
* When using the 256 color depth format, each pixel contains 3
* sub-pixels for color A, B and C. These have 3 bit, 3 bit and
* 2 bits respectively.
+ *
+ * When using the 65k color depth format, each pixel contains 3
+ * sub-pixels for color A, B and C. These have 5 bit, 6 bit and
+ * 5 bits respectively.
*/
/* Set column start and end */
@@ -872,9 +889,24 @@ static void ssd132x_clear_screen(struct ssd130x_device *ssd130x, u8 *data_array)
ssd130x_write_data(ssd130x, data_array, columns * height);
}
+/*
+ * The SSD133X family can drive the panel in either RGB332 (1 byte per pixel)
+ * or RGB565 (2 bytes per pixel). The format is a per-variant policy choice
+ * selected through ssd130x_deviceinfo::format_rgb565, not a capability probe.
+ * Centralize the choice here so that the buffer sizing (allocation, clear and
+ * blit pitch) can never disagree.
+ */
+static const struct drm_format_info *ssd133x_format_info(struct ssd130x_device *ssd130x)
+{
+ if (ssd130x->device_info->format_rgb565)
+ return drm_format_info(DRM_FORMAT_RGB565);
+
+ return drm_format_info(DRM_FORMAT_RGB332);
+}
+
static void ssd133x_clear_screen(struct ssd130x_device *ssd130x, u8 *data_array)
{
- const struct drm_format_info *fi = drm_format_info(DRM_FORMAT_RGB332);
+ const struct drm_format_info *fi = ssd133x_format_info(ssd130x);
unsigned int pitch;
if (!fi)
@@ -945,7 +977,7 @@ static int ssd133x_fb_blit_rect(struct drm_framebuffer *fb,
struct drm_format_conv_state *fmtcnv_state)
{
struct ssd130x_device *ssd130x = drm_to_ssd130x(fb->dev);
- const struct drm_format_info *fi = drm_format_info(DRM_FORMAT_RGB332);
+ const struct drm_format_info *fi = ssd133x_format_info(ssd130x);
unsigned int dst_pitch;
struct iosys_map dst;
int ret = 0;
@@ -956,7 +988,10 @@ static int ssd133x_fb_blit_rect(struct drm_framebuffer *fb,
dst_pitch = drm_format_info_min_pitch(fi, 0, drm_rect_width(rect));
iosys_map_set_vaddr(&dst, data_array);
- drm_fb_xrgb8888_to_rgb332(&dst, &dst_pitch, vmap, fb, rect, fmtcnv_state);
+ if (ssd130x->device_info->format_rgb565)
+ drm_fb_xrgb8888_to_rgb565be(&dst, &dst_pitch, vmap, fb, rect, fmtcnv_state);
+ else
+ drm_fb_xrgb8888_to_rgb332(&dst, &dst_pitch, vmap, fb, rect, fmtcnv_state);
ssd133x_update_rect(ssd130x, rect, data_array, dst_pitch);
@@ -1414,7 +1449,7 @@ static int ssd133x_crtc_atomic_check(struct drm_crtc *crtc,
struct ssd130x_device *ssd130x = drm_to_ssd130x(drm);
struct drm_crtc_state *crtc_state = drm_atomic_get_new_crtc_state(state, crtc);
struct ssd130x_crtc_state *ssd130x_state = to_ssd130x_crtc_state(crtc_state);
- const struct drm_format_info *fi = drm_format_info(DRM_FORMAT_RGB332);
+ const struct drm_format_info *fi = ssd133x_format_info(ssd130x);
unsigned int pitch;
int ret;
diff --git a/drivers/gpu/drm/solomon/ssd130x.h b/drivers/gpu/drm/solomon/ssd130x.h
index a4554018bb2a..b0b487c06e04 100644
--- a/drivers/gpu/drm/solomon/ssd130x.h
+++ b/drivers/gpu/drm/solomon/ssd130x.h
@@ -54,6 +54,13 @@ struct ssd130x_deviceinfo {
bool need_pwm;
bool need_chargepump;
bool page_mode_only;
+ /*
+ * Per-variant output format selector for the SSD133X data path. The
+ * hardware can drive the panel in RGB332 (1 byte/pixel) or RGB565
+ * (2 bytes/pixel); this is a policy choice per variant, not a
+ * capability probe. When set, the variant is driven at RGB565.
+ */
+ bool format_rgb565;
enum ssd130x_family_ids family_id;
};
--
2.54.0
^ permalink raw reply related
* [PATCH v2 1/4] dt-bindings: display: Add Solomon SSD1351 OLED controller
From: Amit Barzilai @ 2026-06-22 15:25 UTC (permalink / raw)
To: javierm, maarten.lankhorst, mripard, tzimmermann, airlied, simona,
robh, krzk+dt, conor+dt, andy, gregkh, deller
Cc: azuddinadam, chintanlike, dri-devel, devicetree, linux-kernel,
linux-fbdev, linux-staging, Amit Barzilai
In-Reply-To: <20260622152506.78627-1-amit.barzilai22@gmail.com>
Add a device tree binding for the Solomon SSD1351, a 128x128 65k-color
RGB OLED display controller driven over a 4-wire SPI bus. The binding
builds on the shared solomon,ssd-common.yaml properties already used by
the other Solomon display controllers.
Assisted-by: Claude:claude-opus-4-8
Signed-off-by: Amit Barzilai <amit.barzilai22@gmail.com>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
---
.../bindings/display/solomon,ssd1351.yaml | 42 +++++++++++++++++++
1 file changed, 42 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/solomon,ssd1351.yaml
diff --git a/Documentation/devicetree/bindings/display/solomon,ssd1351.yaml b/Documentation/devicetree/bindings/display/solomon,ssd1351.yaml
new file mode 100644
index 000000000000..80850c2ab5b3
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/solomon,ssd1351.yaml
@@ -0,0 +1,42 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/solomon,ssd1351.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Solomon SSD1351 OLED Display Controller
+
+maintainers:
+ - Amit Barzilai <amit.barzilai22@gmail.com>
+ - Javier Martinez Canillas <javierm@redhat.com>
+
+allOf:
+ - $ref: solomon,ssd-common.yaml#
+
+properties:
+ compatible:
+ enum:
+ - solomon,ssd1351
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ oled@0 {
+ compatible = "solomon,ssd1351";
+ reg = <0x0>;
+ reset-gpios = <&gpio2 7 GPIO_ACTIVE_LOW>;
+ dc-gpios = <&gpio2 8 GPIO_ACTIVE_HIGH>;
+ spi-max-frequency = <10000000>;
+ };
+ };
--
2.54.0
^ permalink raw reply related
* [PATCH v2 0/4] drm/ssd130x: Add support for the Solomon SSD1351 OLED controller
From: Amit Barzilai @ 2026-06-22 15:25 UTC (permalink / raw)
To: javierm, maarten.lankhorst, mripard, tzimmermann, airlied, simona,
robh, krzk+dt, conor+dt, andy, gregkh, deller
Cc: azuddinadam, chintanlike, dri-devel, devicetree, linux-kernel,
linux-fbdev, linux-staging, Amit Barzilai
This series adds support for the Solomon SSD1351, a 128x128 65k-color
RGB OLED controller, to the ssd130x DRM driver, and removes the legacy
fbtft fb_ssd1351 driver it supersedes.
v1 [1] was a self-contained ssd1351.c driver. Following Javier's review,
the SSD1351 is instead folded into ssd130x as a new color family, which
also brings 65k color to the existing SSD1331. The work is split as:
- Patch 1 adds the device tree binding. It was previously posted
standalone as a v2 [2]; it is folded into this series here, as Conor
asked, so the binding lands together with the driver and the fbtft
removal.
- Patch 2 changes the SSD133X family to drive RGB565 instead of
RGB332, via a per-variant flag in deviceinfo. The SSD1331 is the
only current member and gains 65k color from this.
- Patch 3 adds the SSD1351 as a new SSD135X_FAMILY, reusing the
SSD133X plane/CRTC and blit/clear helpers. The only data-path
difference is the explicit Write RAM command (0x5c) the SSD1351
needs before pixel data; it also gets its own init sequence and a
longer post-reset settle delay.
- Patch 4 removes the now-redundant staging fbtft fb_ssd1351 driver.
Testing:
- The SSD1351 (patches 1 and 3) is tested on hardware.
- The SSD1331 RGB565 change (patch 2) is compile-tested only; I do not
currently have a working SSD1331 panel. Javier has kindly offered to
test it on his SSD1331.
Dependency:
The SSD1351 reuses ssd133x_update_rect(), which programs the column
and row *end* address as a relative offset rather than an absolute
coordinate. This breaks partial updates that do not start at (0,0). A
separate fix is posted at [3]; until it lands, the SSD1351 shows the
same partial-redraw artifacts. This series applies independently of
that fix, but the two are best merged together.
Based on drm-misc-next.
[1] standalone v1 driver:
https://lore.kernel.org/dri-devel/20260615181253.97551-1-amit.barzilai22@gmail.com
[2] standalone v2 binding:
https://lore.kernel.org/dri-devel/20260615175620.88828-1-amit.barzilai22@gmail.com
[3] ssd132x/ssd133x update_rect end-address fix:
https://lore.kernel.org/dri-devel/20260622122604.32500-1-amit.barzilai22@gmail.com
---
Changes since v1:
- Fold the SSD1351 into ssd130x as a new SSD135X family instead of a
standalone ssd1351.c driver (per Javier).
- Add RGB565 to the SSD133X family, so the SSD1331 also gains 65k color.
- Drop native 256k color (no matching DRM fourcc) and the 0/180
rotation support, to keep the series focused; both can return later.
- Binding: drop solomon,width / solomon,height (deducible from the
compatible) and the rotation property (no consumer), per Krzysztof;
use dt-bindings/gpio/gpio.h flag defines in the example.
- Remove the staging fbtft fb_ssd1351 driver in the same series (per
Conor).
Amit Barzilai (4):
dt-bindings: display: Add Solomon SSD1351 OLED controller
drm/ssd130x: Add RGB565 support to SSD133X family
drm/ssd130x: Add SSD135X_FAMILY and SSD1351 support
staging: fbtft: remove fb_ssd1351 driver
.../bindings/display/solomon,ssd1351.yaml | 42 +++
drivers/gpu/drm/solomon/ssd130x-spi.c | 7 +
drivers/gpu/drm/solomon/ssd130x.c | 269 +++++++++++++++---
drivers/gpu/drm/solomon/ssd130x.h | 12 +-
drivers/staging/fbtft/Kconfig | 5 -
drivers/staging/fbtft/Makefile | 1 -
drivers/staging/fbtft/fb_ssd1351.c | 240 ----------------
7 files changed, 283 insertions(+), 293 deletions(-)
create mode 100644 Documentation/devicetree/bindings/display/solomon,ssd1351.yaml
delete mode 100644 drivers/staging/fbtft/fb_ssd1351.c
--
2.54.0
^ permalink raw reply
* Re: [PATCH v4 5/5] clk: renesas: r9a09g077: Add LCDC and PLL3 clock support for RZ/T2H display pipeline
From: Lad, Prabhakar @ 2026-06-22 15:21 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Michael Turquette, Stephen Boyd, Brian Masney, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Magnus Damm, linux-kernel,
linux-renesas-soc, linux-clk, devicetree, Biju Das,
Fabrizio Castro, Lad Prabhakar
In-Reply-To: <CAMuHMdXX-3ddkTmHGQOySZygRmvhnG6snk7uv4xmA8NjM9MsDw@mail.gmail.com>
Hi Geert,
Thank you for the review.
On Mon, Jun 22, 2026 at 2:13 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> Hi Prabhakar,
>
> On Thu, 18 Jun 2026 at 20:19, Prabhakar <prabhakar.csengg@gmail.com> wrote:
> > From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> >
> > Add the clock definitions and PLL logic required to supply the LCDC
> > (VSPD/FCPVD/DU) blocks on the RZ/T2H (R9A09G077) SoC. The RZ/T2H display
> > subsystem depends on a dedicated PLL (PLL3) and a set of new derived
> > clocks.
> >
> > Introduce a new PLL clock type and implement rate recalculation,
> > programming and locking sequences for PLL3 using the RZ/T2H specific
> > divider and VCO limits. Add the corresponding muxes and divider entries,
> > expose the LCDC core clock, and register the LCDC module clock using the
> > correct PCLK parent.
> >
> > This enables the RZ/T2H clock driver to generate the display pipeline
> > clocking tree needed by the DU and VSP-based composition engines, allowing
> > upcoming display support to be integrated without duplicating CPG logic.
> >
> > Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> > Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> > ---
> > v3->v4:
> > - Added RB tag from Geert.
>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> i.e. will queue in renesas-clk for v7.3.
>
> > + rate_millihz = mul_u32_u32(req->rate, MILLI);
>
> The issue pointed out by Sashiko (req->rate is unsigned long, i.e. can
> be larger than u32 on 64-bit) is valid, but I believe it can't happen
> in practice. Still, would be good to fix it in a subsequent patch.
>
Agreed.
Cheers,
Prahakar
^ permalink raw reply
* Re: [PATCH v4 01/13] clk: qcom: gcc-qcm2290: Keep the critical clocks always-on from probe
From: Dmitry Baryshkov @ 2026-06-22 15:12 UTC (permalink / raw)
To: Imran Shaik
Cc: Bjorn Andersson, Michael Turquette, Stephen Boyd, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Konrad Dybcio, Loic Poulain,
Brian Masney, Ajit Pandey, Taniya Das, Jagadeesh Kona,
linux-arm-msm, linux-clk, devicetree, linux-kernel
In-Reply-To: <f6264995-a6f6-498f-9557-723c39becf1a@oss.qualcomm.com>
On Sun, 21 Jun 2026 at 16:28, Imran Shaik <imran.shaik@oss.qualcomm.com> wrote:
>
>
>
> On 06-06-2026 04:54 pm, Dmitry Baryshkov wrote:
> > On Thu, Jun 04, 2026 at 10:56:07AM +0530, Imran Shaik wrote:
> >> Some GCC branch clocks are required to be kept always-on due to the
> >> hardware requirements. Drop the modelling of those always-on QCM2290 GCC
> >> clocks and use the latest .clk_cbcr convention to keep them enabled from
> >> probe.
> >
> > You got the feedback, but it got ignored. There is no explanation about
> > gcc_gpu_iref_clk and several other clocks becoming always on.
> >
>
> Apologies for the late reply.
>
> I have updated generically that few clocks are required to be kept ON
> due to the hardware requirements. For gcc_gpu_iref_clk clock the
> Power-On-Reset value is default ON, and such clocks are kept ON from
> probe. As Agatti is working functionally, I will keep this clock
> modelling same as before.
>
> And I will update commit text that the GCC video ahb/xo clocks are
> required to be kept ON similar to other camera/disp ahb/xo clocks.
Why? What is _wrong_ with thow they are modelled now?
>
> Thanks,
> Imran
>
> >>
> >> Signed-off-by: Imran Shaik <imran.shaik@oss.qualcomm.com>
> >> ---
> >> drivers/clk/qcom/gcc-qcm2290.c | 160 +++++------------------------------------
> >> 1 file changed, 18 insertions(+), 142 deletions(-)
> >>
> >
>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v2 1/3] dt-bindings: power: limits: Describe Qualcomm SPEL hardware
From: Manaf Meethalavalappu Pallikunhi @ 2026-06-22 15:11 UTC (permalink / raw)
To: Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Rafael J. Wysocki, Bjorn Andersson, Konrad Dybcio, Daniel Lezcano
Cc: Gaurav Kohli, linux-arm-msm, devicetree, linux-kernel, linux-pm
In-Reply-To: <50d92653-b403-402d-af82-a037114c3aab@oss.qualcomm.com>
Hi Konrad,
On 6/22/2026 4:32 PM, Konrad Dybcio wrote:
> On 6/19/26 10:39 PM, Manaf Meethalavalappu Pallikunhi wrote:
>> The Qualcomm SoC Power and Electrical Limits (SPEL) provides hardware
>> based power monitoring and limiting capabilities for various domains.
>>
>> Add a DeviceTree binding to describe the SPEL block on Qualcomm's SoC.
>>
>> Signed-off-by: Manaf Meethalavalappu Pallikunhi <manaf.pallikunhi@oss.qualcomm.com>
>> ---
>> .../bindings/power/limits/qcom,spel.yaml | 47 ++++++++++++++++++++++
>> MAINTAINERS | 6 +++
>> 2 files changed, 53 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/power/limits/qcom,spel.yaml b/Documentation/devicetree/bindings/power/limits/qcom,spel.yaml
>> new file mode 100644
>> index 000000000000..4c6e6cbfbfe4
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/power/limits/qcom,spel.yaml
>> @@ -0,0 +1,47 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/power/limits/qcom,spel.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Qualcomm SoC Power and Electrical Limits (SPEL)
>> +
>> +maintainers:
>> + - Manaf Meethalavalappu Pallikunhi <manaf.pallikunhi@oss.qualcomm.com>
>> +
>> +description:
>> + The Qualcomm SPEL (SoC Power and Electrical Limits) provides hardware-based
>> + power monitoring and limiting capabilities for various power domains in
>> + Qualcomm SoCs.
>> +
>> +properties:
>> + compatible:
>> + const: qcom,glymur-spel
>> +
>> + reg:
>> + maxItems: 3
>> +
>> + reg-names:
>> + items:
>> + - const: config
>> + - const: constraints
>> + - const: nodes
>> +
>> +required:
>> + - compatible
>> + - reg
>> + - reg-names
>> +
>> +additionalProperties: false
>> +
>> +examples:
>> + - |
>> + power-limits@ef3b000 {
>> + compatible = "qcom,glymur-spel";
>> + reg = <0x0ef3b000 0x1000>,
>> + <0x0ef3d000 0x1000>,
>
> Don't we need the range inbetween these two (base=0xef3c000)?
>
No, it is consumed by firmware.
Thanks,
Manaf
> Konrad
^ permalink raw reply
* Re: [PATCH v4 2/2] media: i2c: ov5640: Add reset controller support with GPIO fallback
From: Frank Li @ 2026-06-22 15:02 UTC (permalink / raw)
To: Philipp Zabel
Cc: robby.cai, robh, krzk+dt, conor+dt, Frank.Li, s.hauer, festevam,
sebastian.krzyszkowiak, slongerbeam, sakari.ailus, mchehab,
kieran.bingham, kernel, devicetree, imx, linux-arm-kernel,
linux-kernel
In-Reply-To: <7ee62b699c5cabb00cd7706ea42573da81c5bc84.camel@pengutronix.de>
On Mon, Jun 22, 2026 at 11:05:34AM +0200, Philipp Zabel wrote:
> On Fr, 2026-06-19 at 09:18 -0500, Frank Li wrote:
> > On Fri, Jun 19, 2026 at 06:05:32PM +0800, robby.cai@oss.nxp.com wrote:
> > > [You don't often get email from robby.cai@oss.nxp.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
> > >
> > > From: Robby Cai <robby.cai@nxp.com>
> > >
> > > Add support for the reset controller framework by acquiring the reset
> > > line using devm_reset_control_get_optional_shared_deasserted(). This
> > > allows the driver to handle reset lines provided by a reset controller,
> > > including shared ones, while avoiding unbalanced deassert counts.
> > >
> > > Retain support for legacy reset-gpios as a fallback when no reset
> > > controller is defined. In that case, request the GPIO and keep it in the
> > > deasserted state as the initial configuration.
> > >
> > > This enables the driver to support both reset-controller-backed reset
> > > lines and older GPIO-based descriptions while preserving the existing
> > > power-up sequencing behavior.
> > >
> > > Signed-off-by: Robby Cai <robby.cai@nxp.com>
> > > ---
> > > drivers/media/i2c/ov5640.c | 80 +++++++++++++++++++++++++++++++++-----
> > > 1 file changed, 70 insertions(+), 10 deletions(-)
> > >
> > > diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
> > > index 85ecc23b3587..5e6db8aacb11 100644
> > > --- a/drivers/media/i2c/ov5640.c
> > > +++ b/drivers/media/i2c/ov5640.c
> > > @@ -17,6 +17,7 @@
> > > #include <linux/module.h>
> > > #include <linux/pm_runtime.h>
> > > #include <linux/regulator/consumer.h>
> > > +#include <linux/reset.h>
> > > #include <linux/slab.h>
> > > #include <linux/types.h>
> > > #include <media/v4l2-async.h>
> > > @@ -442,6 +443,7 @@ struct ov5640_dev {
> > > u32 xclk_freq;
> > >
> > > struct regulator_bulk_data supplies[OV5640_NUM_SUPPLIES];
> > > + struct reset_control *reset;
> > > struct gpio_desc *reset_gpio;
> > > struct gpio_desc *pwdn_gpio;
> > > bool upside_down;
> > > @@ -2431,6 +2433,48 @@ static int ov5640_restore_mode(struct ov5640_dev *sensor)
> > > return ov5640_set_framefmt(sensor, &sensor->fmt);
> > > }
> > >
> > > +static int ov5640_get_reset(struct device *dev, struct ov5640_dev *sensor)
> > > +{
> > > + /* use deasserted version to avoid unbalanced deassert counts */
> > > + sensor->reset =
> > > + devm_reset_control_get_optional_shared_deasserted(dev, NULL);
> > > + if (IS_ERR(sensor->reset))
> > > + return dev_err_probe(dev, PTR_ERR(sensor->reset),
> > > + "Failed to get reset\n");
> > > + else if (sensor->reset)
> > > + return 0;
> > > +
> > > + /*
> > > + * fallback to legacy reset-gpios
> > > + * GPIOD_OUT_HIGH ensures deasserted state for ACTIVE_LOW reset
> > > + */
> > > + sensor->reset_gpio = devm_gpiod_get_optional(dev, "reset",
> > > + GPIOD_OUT_HIGH);
> > > + if (IS_ERR(sensor->reset_gpio))
> > > + return dev_err_probe(dev, PTR_ERR(sensor->reset_gpio),
> > > + "Failed to get reset gpio");
> >
> > I think needn't fallback here, NO ABI change, just change to use reset-gpio
> > driver.
>
> Please keep the gpiod fallback, the reset-gpio driver may not be
> available on all platforms using ov5640.
Maybe try promote reset-gpio is default build in / as module. Leave such
fallback every where make code complex.
Krysztof:
Any suggestion?
Frank
>
> > > +
> > > + return 0;
> > > +}
> > > +
> > > +static int ov5640_reset_assert(struct ov5640_dev *sensor)
> > > +{
> > > + if (sensor->reset)
> > > + return reset_control_assert(sensor->reset);
> >
> > needn't check sensor->reset, reset_control_assert() is no ops if NULL.
> >
> > > +
> > > + gpiod_set_value_cansleep(sensor->reset_gpio, 1);
> >
> > Needn't fallback, directly replace.
>
> See above.
>
>
> regards
> Philipp
^ permalink raw reply
* Re: [PATCH v4 2/4] PCI: rzg3s-host: Use shared reset controls for power domain resets
From: Lad, Prabhakar @ 2026-06-22 14:53 UTC (permalink / raw)
To: Manivannan Sadhasivam
Cc: Philipp Zabel, Claudiu Beznea, Lorenzo Pieralisi,
Krzysztof Wilczyński, Rob Herring, Bjorn Helgaas,
Krzysztof Kozlowski, Conor Dooley, Geert Uytterhoeven,
Magnus Damm, linux-pci, linux-renesas-soc, devicetree,
linux-kernel, Biju Das, Fabrizio Castro, Lad Prabhakar
In-Reply-To: <fuefvecgjdqbnbvpvam4gmewmpmhofllyq2ootwi6cjqhnyoys@edjzqlh6fjw4>
Hi Manivannan,
On Mon, Jun 22, 2026 at 3:30 PM Manivannan Sadhasivam <mani@kernel.org> wrote:
>
> On Fri, Jun 05, 2026 at 12:54:46PM +0100, Lad, Prabhakar wrote:
> > Hi Philipp,
> >
> > Thank you for the review.
> >
> > On Wed, Jun 3, 2026 at 9:16 AM Philipp Zabel <p.zabel@pengutronix.de> wrote:
> > >
> > > On Di, 2026-06-02 at 20:50 +0100, Prabhakar wrote:
> > > > From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> > > >
> > > > Switch to shared reset controls for PCIe power resets to prepare for
> > > > RZ/V2H(P) support. On this platform, multiple PCIe controllers share
> > > > the same reset line, requiring shared ownership of the reset control.
> > > >
> > > > Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> > > > Reviewed-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
> > > > Tested-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
> > > > ---
> > > > v3->v4:
> > > > - Added RB/TB tags.
> > > >
> > > > v2->v3:
> > > > - No change.
> > > >
> > > > v1->v2:
> > > > - Updated commit message.
> > > > ---
> > > > drivers/pci/controller/pcie-rzg3s-host.c | 6 +++---
> > > > 1 file changed, 3 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git a/drivers/pci/controller/pcie-rzg3s-host.c b/drivers/pci/controller/pcie-rzg3s-host.c
> > > > index d86e7516dcc2..a5192e4b58df 100644
> > > > --- a/drivers/pci/controller/pcie-rzg3s-host.c
> > > > +++ b/drivers/pci/controller/pcie-rzg3s-host.c
> > > > @@ -1276,9 +1276,9 @@ static int rzg3s_pcie_resets_prepare_and_get(struct rzg3s_pcie_host *host)
> > > > for (i = 0; i < data->num_cfg_resets; i++)
> > > > host->cfg_resets[i].id = data->cfg_resets[i];
> > > >
> > > > - ret = devm_reset_control_bulk_get_exclusive(host->dev,
> > > > - data->num_power_resets,
> > > > - host->power_resets);
> > > > + ret = devm_reset_control_bulk_get_shared(host->dev,
> > > > + data->num_power_resets,
> > > > + host->power_resets);
> > > > if (ret)
> > > > return ret;
> > > >
> > >
> > > I have a few questions about this.
> > >
> > > Can you move rzg3s_pcie_resets_prepare_and_get() and
> > > rzg3s_pcie_power_resets_deassert() up before setting
> > > RZG3S_SYSC_FUNC_ID_MODE and RZG3S_SYSC_FUNC_ID_RST_RSM_B in
> > > rzg3s_pcie_probe() without ill effect?
> > >
> > > Can you move rzg3s_pcie_power_resets_deassert() up before setting
> > > RZG3S_SYSC_FUNC_ID_MODE and RZG3S_SYSC_FUNC_ID_RST_RSM_B
> > > rzg3s_pcie_resume_noirq()?
> > >
> > > Those would have the same effect as the reset already being deasserted
> > > by the other controller.
> > >
> > Yes to both. I have reordered the sequences as suggested, and it works
> > perfectly without any ill effects.
> >
>
> Are you going to respin the patches incorporating the review comments?
>
If I have not mistaken, no code changes were requested; it was just
that Philipp wanted to ensure the shared reset worked correctly after
shuffling the code around.
I can respin the series if it fails to apply on top of pci/next.
Cheers,
Prabhakar
^ permalink raw reply
* Re: [PATCH 1/9] arm64: dts: renesas: r8a774a1: Add soc: label to soc node
From: Geert Uytterhoeven @ 2026-06-22 14:37 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-arm-kernel, Conor Dooley, Krzysztof Kozlowski, Rob Herring,
devicetree, linux-kernel, linux-renesas-soc
In-Reply-To: <8cb1c3cb-3d8f-4e76-99e9-ad78ee149556@mailbox.org>
Hi Marek,
On Mon, 22 Jun 2026 at 15:56, Marek Vasut <marek.vasut@mailbox.org> wrote:
> On 6/22/26 12:35 PM, Geert Uytterhoeven wrote:
> > On Sun, 21 Jun 2026 at 04:51, Marek Vasut
> > <marek.vasut+renesas@mailbox.org> wrote:
> >> Add soc: label to the /soc {} node to align the DT with r8a77951.dtsi
> >> which already has that soc: label. The soc: label is useful in U-Boot
> >> where it is used in U-Boot extras DT fragments.
> >>
> >> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
> >
> > For the whole series:
> > Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> > i.e. will queue in renesas-devel for v7.3, squashed into a single
> > commit. Unfortunately there is no cover letter, so I will have to add
> > all nine Link-tags.
>
> Is that why cover letter helps you ?
Another reason is that my scripting turns cover letters into empty
commits in my local tree, serving as separators between patch series.
> If so, I will start generating ones ?
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v3 5/5] dmaengine: sun6i-dma: Add support for Allwinner A733 DMA controller
From: Frank Li @ 2026-06-22 14:35 UTC (permalink / raw)
To: Yuanshen Cao
Cc: conor+dt, mripard, krzk+dt, robh, samuel, wens, jernej.skrabec,
Frank.Li, vkoul, dmaengine, linux-arm-kernel, linux-sunxi,
devicetree, linux-kernel
In-Reply-To: <20260622-sun60i-a733-dma-v3-5-f697ef296cbc@gmail.com>
On Mon, Jun 22, 2026 at 01:36:27AM +0000, Yuanshen Cao wrote:
> Support Allwinner A733 DMA controller. Define new register offsets,
> bitfield mappings and dma_config required for the A733, which slightly
> differs from the older `sun6i` DMA controllers.
>
> Changes:
> - New register macros for A733 interrupt enable `DMA_IRQ_EN_A733`,
> status `DMA_IRQ_STAT_A733`, and channel count `DMA_IRQ_CHAN_NR_A733`.
> - New `SRC_HIGH_ADDR_32G` and `DST_HIGH_ADDR_32G` macro to handle the
> 32G high-address field in the LLI.
> - Implemented `sun6i_dma_set_addr_a733` and A733-specific interrupt
> register accessors.
> - Added `sun60i_a733_dma_cfg`, which ties all the refactored
> functionality together for this specific hardware.
>
> Signed-off-by: Yuanshen Cao <alex.caoys@gmail.com>
> ---
> drivers/dma/sun6i-dma.c | 87 +++++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 87 insertions(+)
>
> diff --git a/drivers/dma/sun6i-dma.c b/drivers/dma/sun6i-dma.c
> index 196a0d73b221..4808015934cc 100644
> --- a/drivers/dma/sun6i-dma.c
> +++ b/drivers/dma/sun6i-dma.c
> @@ -52,6 +52,15 @@
> #define SUNXI_H3_SECURE_REG 0x20
> #define SUNXI_H3_DMA_GATE 0x28
> #define SUNXI_H3_DMA_GATE_ENABLE 0x4
> +
> +/*
> + * sun60i specific registers
> + */
> +#define DMA_IRQ_EN_A733(x) ((x) * 0x40 + 0x134)
> +#define DMA_IRQ_STAT_A733(x) ((x) * 0x40 + 0x138)
> +
> +#define DMA_IRQ_CHAN_NR_A733 1
> +
> /*
> * Channels specific registers
> */
> @@ -100,6 +109,8 @@
> */
> #define SRC_HIGH_ADDR(x) (((x) & 0x3U) << 16)
> #define DST_HIGH_ADDR(x) (((x) & 0x3U) << 18)
> +#define SRC_HIGH_ADDR_32G(x) (((x) & 0x7U) << 11)
> +#define DST_HIGH_ADDR_32G(x) (((x) & 0x7U) << 15)
Because the previous code use this pattern, I provide my reviewed-by tags.
I suggest change to use GEN_MASK and FIELD_PREP macro in future.
Reviewed-by: Frank Li <Frank.Li@nxp.com>
>
> /*
> * Various hardware related defines
> @@ -257,6 +268,23 @@ static inline void sun6i_dma_dump_com_regs(struct sun6i_dma_dev *sdev)
> DMA_STAT, readl(sdev->base + DMA_STAT));
> }
>
> +static inline void sun6i_dma_dump_com_regs_a733(struct sun6i_dma_dev *sdev)
> +{
> + int i;
> +
> + for (i = 0; i < sdev->num_pchans / sdev->cfg->num_channels_per_reg; i++) {
> + dev_dbg(sdev->slave.dev, "Common register:\n"
> + "chan num %d\n"
> + "\tmask(%04x): 0x%08x\n"
> + "\tpend(%04x): 0x%08x\n"
> + "\tstats(%04x): 0x%08x\n",
> + i,
> + DMA_IRQ_EN_A733(i), readl(sdev->base + DMA_IRQ_EN_A733(i)),
> + DMA_IRQ_STAT_A733(i), readl(sdev->base + DMA_IRQ_STAT_A733(i)),
> + DMA_STAT, readl(sdev->base + DMA_STAT));
> + }
> +}
> +
> static inline void sun6i_dma_dump_chan_regs(struct sun6i_dma_dev *sdev,
> struct sun6i_pchan *pchan)
> {
> @@ -360,21 +388,41 @@ static u32 sun6i_read_irq_en(struct sun6i_dma_dev *sdev, u32 irq_reg)
> return readl(sdev->base + DMA_IRQ_EN(irq_reg));
> }
>
> +static u32 sun6i_read_irq_en_a733(struct sun6i_dma_dev *sdev, u32 irq_reg)
> +{
> + return readl(sdev->base + DMA_IRQ_EN_A733(irq_reg));
> +}
> +
> static void sun6i_write_irq_en(struct sun6i_dma_dev *sdev, u32 irq_reg, u32 irq_val)
> {
> writel(irq_val, sdev->base + DMA_IRQ_EN(irq_reg));
> }
>
> +static void sun6i_write_irq_en_a733(struct sun6i_dma_dev *sdev, u32 irq_reg, u32 irq_val)
> +{
> + writel(irq_val, sdev->base + DMA_IRQ_EN_A733(irq_reg));
> +}
> +
> static u32 sun6i_read_irq_stat(struct sun6i_dma_dev *sdev, u32 irq_reg)
> {
> return readl(sdev->base + DMA_IRQ_STAT(irq_reg));
> }
>
> +static u32 sun6i_read_irq_stat_a733(struct sun6i_dma_dev *sdev, u32 irq_reg)
> +{
> + return readl(sdev->base + DMA_IRQ_STAT_A733(irq_reg));
> +}
> +
> static void sun6i_write_irq_stat(struct sun6i_dma_dev *sdev, u32 irq_reg, u32 status)
> {
> writel(status, sdev->base + DMA_IRQ_STAT(irq_reg));
> }
>
> +static void sun6i_write_irq_stat_a733(struct sun6i_dma_dev *sdev, u32 irq_reg, u32 status)
> +{
> + writel(status, sdev->base + DMA_IRQ_STAT_A733(irq_reg));
> +}
> +
> static size_t sun6i_get_chan_size(struct sun6i_pchan *pchan)
> {
> struct sun6i_desc *txd = pchan->desc;
> @@ -695,6 +743,17 @@ static void sun6i_dma_set_addr_a100(struct sun6i_dma_dev *sdev,
> DST_HIGH_ADDR(upper_32_bits(dst));
> }
>
> +static void sun6i_dma_set_addr_a733(struct sun6i_dma_dev *sdev,
> + struct sun6i_dma_lli *v_lli,
> + dma_addr_t src, dma_addr_t dst)
> +{
> + v_lli->src = lower_32_bits(src);
> + v_lli->dst = lower_32_bits(dst);
> +
> + v_lli->para |= SRC_HIGH_ADDR_32G(upper_32_bits(src)) |
> + DST_HIGH_ADDR_32G(upper_32_bits(dst));
> +}
> +
> static inline void sun6i_dma_set_addr(struct sun6i_dma_dev *sdev,
> struct sun6i_dma_lli *v_lli,
> dma_addr_t src, dma_addr_t dst)
> @@ -1339,6 +1398,33 @@ static struct sun6i_dma_config sun50i_h6_dma_cfg = {
> SUN6I_DMA_IRQ_A31_COMMON_OPS
> };
>
> +/*
> + * The A733 binding uses the number of dma channels from the
> + * device tree node.
> + */
> +static struct sun6i_dma_config sun60i_a733_dma_cfg = {
> + .clock_autogate_enable = sun6i_enable_clock_autogate_h3,
> + .set_burst_length = sun6i_set_burst_length_h3,
> + .set_drq = sun6i_set_drq_h6,
> + .set_mode = sun6i_set_mode_h6,
> + .set_addr = sun6i_dma_set_addr_a733,
> + .dump_com_regs = sun6i_dma_dump_com_regs_a733,
> + .read_irq_en = sun6i_read_irq_en_a733,
> + .write_irq_en = sun6i_write_irq_en_a733,
> + .read_irq_stat = sun6i_read_irq_stat_a733,
> + .write_irq_stat = sun6i_write_irq_stat_a733,
> + .src_burst_lengths = BIT(1) | BIT(4) | BIT(8) | BIT(16),
> + .dst_burst_lengths = BIT(1) | BIT(4) | BIT(8) | BIT(16),
> + .src_addr_widths = BIT(DMA_SLAVE_BUSWIDTH_1_BYTE) |
> + BIT(DMA_SLAVE_BUSWIDTH_2_BYTES) |
> + BIT(DMA_SLAVE_BUSWIDTH_4_BYTES),
> + .dst_addr_widths = BIT(DMA_SLAVE_BUSWIDTH_1_BYTE) |
> + BIT(DMA_SLAVE_BUSWIDTH_2_BYTES) |
> + BIT(DMA_SLAVE_BUSWIDTH_4_BYTES),
> + .num_channels_per_reg = DMA_IRQ_CHAN_NR_A733,
> + .has_mbus_clk = true,
> +};
> +
> /*
> * The V3s have only 8 physical channels, a maximum DRQ port id of 23,
> * and a total of 24 usable source and destination endpoints.
> @@ -1375,6 +1461,7 @@ static const struct of_device_id sun6i_dma_match[] = {
> { .compatible = "allwinner,sun50i-a64-dma", .data = &sun50i_a64_dma_cfg },
> { .compatible = "allwinner,sun50i-a100-dma", .data = &sun50i_a100_dma_cfg },
> { .compatible = "allwinner,sun50i-h6-dma", .data = &sun50i_h6_dma_cfg },
> + { .compatible = "allwinner,sun60i-a733-dma", .data = &sun60i_a733_dma_cfg },
> { /* sentinel */ }
> };
> MODULE_DEVICE_TABLE(of, sun6i_dma_match);
>
> --
> 2.54.0
>
^ permalink raw reply
* Re: [PATCH] dt-bindings: clock: ti,clockdomain: Convert to DT schema
From: Rob Herring (Arm) @ 2026-06-22 14:35 UTC (permalink / raw)
To: Bhargav Joshi
Cc: simona.toaca, Krzysztof Kozlowski, Stephen Boyd, Conor Dooley,
linux-clk, Brian Masney, devicetree, Tero Kristo, daniel.baluta,
Michael Turquette, linux-kernel, goledhruva, m-chawdhry
In-Reply-To: <20260621-ti-clockdomain-v1-1-e99a56af98ea@gmail.com>
On Sun, 21 Jun 2026 21:23:35 +0530, Bhargav Joshi wrote:
> Convert TI clockdomain to yaml DT schema. Drop '#clock-cells' from the
> required list as this binding doesn't define a new clock binding type,
> it is used to group existing clock nodes under hardware hierarchy. Most
> existing dts omit '#clock-cells'.
>
> Signed-off-by: Bhargav Joshi <j.bhargav.u@gmail.com>
> ---
> .../devicetree/bindings/clock/ti/clockdomain.txt | 25 -------------
> .../bindings/clock/ti/ti,clockdomain.yaml | 41 ++++++++++++++++++++++
> 2 files changed, 41 insertions(+), 25 deletions(-)
>
My bot found errors running 'make dt_binding_check' on your patch:
yamllint warnings/errors:
dtschema/dtc warnings/errors:
doc reference errors (make refcheckdocs):
Warning: Documentation/devicetree/bindings/clock/ti/ti,gate-clock.yaml references a file that doesn't exist: Documentation/devicetree/bindings/clock/ti/clockdomain.txt
Documentation/devicetree/bindings/clock/ti/ti,gate-clock.yaml: Documentation/devicetree/bindings/clock/ti/clockdomain.txt
See https://patchwork.kernel.org/project/devicetree/patch/20260621-ti-clockdomain-v1-1-e99a56af98ea@gmail.com
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.
^ permalink raw reply
* Re: [PATCH v2 2/4] irqchip/gic-v3: Refactor GIC600 limited to 32bit PA erratum handling
From: Marek Vasut @ 2026-06-22 14:22 UTC (permalink / raw)
To: Geert Uytterhoeven, Marek Vasut
Cc: linux-pci, Marc Zyngier, Krzysztof Wilczyński, Bjorn Helgaas,
Catalin Marinas, Conor Dooley, Geert Uytterhoeven,
Krzysztof Kozlowski, Lorenzo Pieralisi, Manivannan Sadhasivam,
Rob Herring, Yoshihiro Shimoda, devicetree, linux-arm-kernel,
linux-doc, linux-kernel, linux-renesas-soc
In-Reply-To: <CAMuHMdUxT87M1oQvPP_h4YX4vXFaVbbG+LCG8EdmuLTuHNtybQ@mail.gmail.com>
On 6/22/26 11:52 AM, Geert Uytterhoeven wrote:
Hello Geert,
>> +++ b/drivers/irqchip/irq-gic-v3-its.c
>> @@ -4890,10 +4890,17 @@ static bool __maybe_unused its_enable_quirk_hip09_162100801(void *data)
>> return true;
>> }
>>
>> -static bool __maybe_unused its_enable_rk3568002(void *data)
>> +static const char * const dma_32bit_impaired_platforms[] = {
>> +#ifdef CONFIG_ROCKCHIP_ERRATUM_3568002
>> + "rockchip,rk3566",
>> + "rockchip,rk3568",
>> +#endif
>> + NULL,
>> +};
>> +
>> +static bool __maybe_unused its_enable_dma32(void *data)
>
> __maybe_unused can be dropped...
I will fix that in V3. Thank you !
^ permalink raw reply
* Re: [PATCH v2 4/4] MAINTAINERS: Add the Renesas RZ/N1 timers driver entry
From: Geert Uytterhoeven @ 2026-06-22 14:23 UTC (permalink / raw)
To: Herve Codina (Schneider Electric)
Cc: Wolfram Sang, Daniel Lezcano, Thomas Gleixner, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Geert Uytterhoeven,
Magnus Damm, linux-renesas-soc, linux-kernel, devicetree,
Pascal Eberhard, Miquel Raynal, Thomas Petazzoni
In-Reply-To: <20260429115054.158160-5-herve.codina@bootlin.com>
On Wed, 29 Apr 2026 at 13:51, Herve Codina (Schneider Electric)
<herve.codina@bootlin.com> wrote:
> After contributing the driver, add myself as the maintainer for the
> Renesas RZ/N1 timers driver.
>
> Signed-off-by: Herve Codina (Schneider Electric) <herve.codina@bootlin.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v4 2/4] PCI: rzg3s-host: Use shared reset controls for power domain resets
From: Manivannan Sadhasivam @ 2026-06-22 14:30 UTC (permalink / raw)
To: Lad, Prabhakar
Cc: Philipp Zabel, Claudiu Beznea, Lorenzo Pieralisi,
Krzysztof Wilczyński, Rob Herring, Bjorn Helgaas,
Krzysztof Kozlowski, Conor Dooley, Geert Uytterhoeven,
Magnus Damm, linux-pci, linux-renesas-soc, devicetree,
linux-kernel, Biju Das, Fabrizio Castro, Lad Prabhakar
In-Reply-To: <CA+V-a8uGho2RMhreDgieOOZTggUALoF0bGyjdEEDvyL_75sAyw@mail.gmail.com>
On Fri, Jun 05, 2026 at 12:54:46PM +0100, Lad, Prabhakar wrote:
> Hi Philipp,
>
> Thank you for the review.
>
> On Wed, Jun 3, 2026 at 9:16 AM Philipp Zabel <p.zabel@pengutronix.de> wrote:
> >
> > On Di, 2026-06-02 at 20:50 +0100, Prabhakar wrote:
> > > From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> > >
> > > Switch to shared reset controls for PCIe power resets to prepare for
> > > RZ/V2H(P) support. On this platform, multiple PCIe controllers share
> > > the same reset line, requiring shared ownership of the reset control.
> > >
> > > Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> > > Reviewed-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
> > > Tested-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
> > > ---
> > > v3->v4:
> > > - Added RB/TB tags.
> > >
> > > v2->v3:
> > > - No change.
> > >
> > > v1->v2:
> > > - Updated commit message.
> > > ---
> > > drivers/pci/controller/pcie-rzg3s-host.c | 6 +++---
> > > 1 file changed, 3 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/pci/controller/pcie-rzg3s-host.c b/drivers/pci/controller/pcie-rzg3s-host.c
> > > index d86e7516dcc2..a5192e4b58df 100644
> > > --- a/drivers/pci/controller/pcie-rzg3s-host.c
> > > +++ b/drivers/pci/controller/pcie-rzg3s-host.c
> > > @@ -1276,9 +1276,9 @@ static int rzg3s_pcie_resets_prepare_and_get(struct rzg3s_pcie_host *host)
> > > for (i = 0; i < data->num_cfg_resets; i++)
> > > host->cfg_resets[i].id = data->cfg_resets[i];
> > >
> > > - ret = devm_reset_control_bulk_get_exclusive(host->dev,
> > > - data->num_power_resets,
> > > - host->power_resets);
> > > + ret = devm_reset_control_bulk_get_shared(host->dev,
> > > + data->num_power_resets,
> > > + host->power_resets);
> > > if (ret)
> > > return ret;
> > >
> >
> > I have a few questions about this.
> >
> > Can you move rzg3s_pcie_resets_prepare_and_get() and
> > rzg3s_pcie_power_resets_deassert() up before setting
> > RZG3S_SYSC_FUNC_ID_MODE and RZG3S_SYSC_FUNC_ID_RST_RSM_B in
> > rzg3s_pcie_probe() without ill effect?
> >
> > Can you move rzg3s_pcie_power_resets_deassert() up before setting
> > RZG3S_SYSC_FUNC_ID_MODE and RZG3S_SYSC_FUNC_ID_RST_RSM_B
> > rzg3s_pcie_resume_noirq()?
> >
> > Those would have the same effect as the reset already being deasserted
> > by the other controller.
> >
> Yes to both. I have reordered the sequences as suggested, and it works
> perfectly without any ill effects.
>
Are you going to respin the patches incorporating the review comments?
- Mani
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH v2 2/4] clocksource/drivers: Add support for the Renesas RZ/N1 timers
From: Geert Uytterhoeven @ 2026-06-22 14:22 UTC (permalink / raw)
To: Herve Codina (Schneider Electric)
Cc: Wolfram Sang, Daniel Lezcano, Thomas Gleixner, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Magnus Damm, linux-renesas-soc,
linux-kernel, devicetree, Pascal Eberhard, Miquel Raynal,
Thomas Petazzoni
In-Reply-To: <20260429115054.158160-3-herve.codina@bootlin.com>
Hi Hervé,
Thanks for your patch!
Just a few generic comments, as I am not a timer expert, and have no
access to the hardware.
On Wed, 29 Apr 2026 at 13:51, Herve Codina (Schneider Electric)
<herve.codina@bootlin.com> wrote:
> The Renesas RZ/N1 timer block controller is the controller in charge of
> timers available in the Renesas RZ/N1 SoCs family.
>
> This controller handles 8 timers:
> - 6 16-bit timers
> - 2 32-bit timers
>
> Each timer has its own interrupt, its own prescaler that can be used to
> device the clock by 25 and all of them can work in either one-shot or
divide
> periodic mode.
>
> Signed-off-by: Herve Codina (Schneider Electric) <herve.codina@bootlin.com>
> ---
> drivers/clocksource/Kconfig | 10 +
> drivers/clocksource/Makefile | 1 +
> drivers/clocksource/timer-rzn1.c | 442 +++++++++++++++++++++++++++++++
> 3 files changed, 453 insertions(+)
> create mode 100644 drivers/clocksource/timer-rzn1.c
>
> diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
> index d1a33a231a44..f8e49a4ac8f6 100644
> --- a/drivers/clocksource/Kconfig
> +++ b/drivers/clocksource/Kconfig
> @@ -152,6 +152,16 @@ config REALTEK_OTTO_TIMER
> RT8391, RTL8392, RTL8393 and RTL8396 and chips of the RTL930x series
> such as RTL9301, RTL9302 or RTL9303.
>
> +config RZN1_TIMER
> + bool "Renesas RZ/N1 Timer"
So this cannot be a module.
> + depends on HAS_IOMEM && COMMON_CLK && (ARCH_RZN1 || COMPILE_TEST)
I would split this in two lines, to make it easier to read (and
maintain, if the same timer ends up in a different SoC series).
> + help
> + Enables support for RZ/N1 SoC timers.
> + A timers block in RZ/N1 SoCs is composed of 8 timers
> + - 6 16-bit timers
> + - 2 32-bit timers
> + Two timers blocks are available in RZ/N1 SoCs.
> +
> config SUN4I_TIMER
> bool "Sun4i timer driver" if COMPILE_TEST
> depends on HAS_IOMEM
> --- /dev/null
> +++ b/drivers/clocksource/timer-rzn1.c
> +/*
> + * 8 timers are available. Among those 8 timers, the first 6 timers are 16-bit
> + * timers and the last two ones are 32-bit timers.
> + */
> +#define RZN1_TIMER_BASE_INDEX_16BIT_TIMERS 0
> +#define RZN1_TIMER_NB_16BIT_TIMERS 6
> +
> +#define RZN1_TIMER_BASE_INDEX_32BIT_TIMER 6
> +#define RZN1_TIMER_NB_32BIT_TIMERS 2
Align the number columns?
> +static int rzn1_timer_probe_first(struct platform_device *pdev, struct rzn1_timer *tab_timers,
> + void __iomem *base, unsigned long clock_rate)
> +{
> + struct device *dev = &pdev->dev;
> + struct rzn1_timer *timer;
> + unsigned int i;
> + char *name;
> + int irq;
> + int ret;
> +
> + /*
> + * Probe the first instance. In that case, timers are assigned as
> + * follow:
> + * - First 16-bit timer: clocksource and sched_clock
> + * - Other 16-bit timers: clock events for all possible CPUs
> + * - 32-bit timers: clock events per CPU
> + *
> + * First step, perform all operation that could fail without calling
> + * clockevents_config_and_register(), sched_clock_register() nor
> + * cpuhp_setup_state(). Those operation don't have unregister nor
> + * teardown counterparts and so, once called, we cannot remove the
> + * related resource.
> + */
> +
> + /*
> + * First step for 16-bit timers except the first one and all 32-bit
> + * timers.
> + */
> + for (i = RZN1_TIMER_BASE_INDEX_16BIT_TIMERS + 1; i < RZN1_TIMER_NB_TIMERS; i++) {
> + timer = &tab_timers[i];
> +
> + rzn1_timer_init(timer, i, base, clock_rate);
> +
> + irq = platform_get_irq(pdev, i);
> + if (irq < 0)
> + return irq;
> +
> + name = devm_kasprintf(dev, GFP_KERNEL, "%s-%u", dev_name(dev), i);
> + if (!name)
> + return -ENOMEM;
> +
> + rzn1_timer_clkevt_init_ced(timer, name, irq);
> +
> + ret = devm_request_irq(dev, timer->ced.irq, rzn1_timer_interrupt,
> + IRQF_TIMER, timer->ced.name, timer);
> + if (ret < 0)
> + return dev_err_probe(dev, irq, "timer%d: Failed to request IRQ\n", i);
%u
> +
> + rzn1_timer_int_enable(timer);
> + }
> +
> + /*
> + * Second step, almost all operations that can fail have been called.
> + * Timers are ready to work. Start with the last operation that can fail,
> + * installing and invoking hotplug callbacks
> + */
> + rzn1_tab_timers = tab_timers;
> + ret = cpuhp_setup_state(CPUHP_AP_ONLINE_DYN,
> + "clockevents/rzn1/global_timer:starting",
> + rzn1_local_timer_starting_cpu, NULL);
> + if (ret < 0)
> + return dev_err_probe(dev, ret, "Setup CPU hotplug state failed\n");
> +
> + /*
> + * At this point, no more operations can fail. Perform remaining
> + * operations. Starting by handling the first 16-bit timer
> + */
> + timer = &tab_timers[RZN1_TIMER_BASE_INDEX_16BIT_TIMERS];
> +
> + rzn1_timer_init(timer, RZN1_TIMER_BASE_INDEX_16BIT_TIMERS, base, clock_rate);
> + rzn1_timer_config(timer, GENMASK(timer->width - 1, 0), true);
> +
> + rzn1_sched_clock = timer;
> +
> + sched_clock_register(rzn1_sched_read, rzn1_sched_clock->width, rzn1_sched_clock->rate);
> +
> + rzn1_clocksource.mask = CLOCKSOURCE_MASK(rzn1_sched_clock->width);
> + clocksource_register_hz(&rzn1_clocksource, rzn1_sched_clock->rate);
> +
> + /*
> + * Register clockevents only for 16-bit timers. 32-bit timers clockevents
> + * are registered by CPU hotplug startup function set previously by the
> + * cpuhp_setup_state() call.
> + */
> + for (i = RZN1_TIMER_BASE_INDEX_16BIT_TIMERS + 1; i < RZN1_TIMER_NB_16BIT_TIMERS; i++) {
> + timer = &tab_timers[i];
> + clockevents_config_and_register(&timer->ced, timer->rate,
> + 1, GENMASK(timer->width - 1, 0));
> + }
> +
> + return 0;
> +}
> +
> +static int rzn1_timer_probe_other(struct platform_device *pdev, struct rzn1_timer *tab_timers,
> + void __iomem *base, unsigned long clock_rate)
> +{
> + struct device *dev = &pdev->dev;
> + struct rzn1_timer *timer;
> + unsigned int i;
> + char *name;
> + int irq;
> + int ret;
> +
> + /*
> + * Probe other instance(s), i.e. not the first one. In that case,
> + * all timers are used as clock events and available for all possible
> + * CPUs
> + *
> + * First step, perform all operation that could fail without calling
> + * clockevents_config_and_register(). Unregister counterpart does not
> + * exist and so, once called, we cannot remove the related resource.
> + */
> + for (i = 0; i < RZN1_TIMER_NB_TIMERS; i++) {
Technically "0" is RZN1_TIMER_BASE_INDEX_16BIT_TIMERS.
> + timer = &tab_timers[i];
> +
> + rzn1_timer_init(timer, i, base, clock_rate);
> +
> + irq = platform_get_irq(pdev, i);
> + if (irq < 0)
> + return irq;
> +
> + name = devm_kasprintf(dev, GFP_KERNEL, "%s-%u", dev_name(dev), i);
> + if (!name)
> + return -ENOMEM;
> +
> + rzn1_timer_clkevt_init_ced(timer, name, irq);
> +
> + ret = devm_request_irq(dev, timer->ced.irq, rzn1_timer_interrupt,
> + IRQF_TIMER, timer->ced.name, timer);
> + if (ret < 0)
> + return dev_err_probe(dev, irq, "timer%d: Failed to request IRQ\n", i);
%u
> +
> + rzn1_timer_int_enable(timer);
> + }
This loop is identical to the first loop in rzn1_timer_probe_first(),
except for the lower bound. Perhaps it can be factored out?
> +
> + /*
> + * Second step, all operation that can fail have been called. We can
> + * register our timers
> + */
> +
> + for (i = 0; i < RZN1_TIMER_NB_TIMERS; i++) {
Technically "0" is RZN1_TIMER_BASE_INDEX_16BIT_TIMERS.
> + timer = &tab_timers[i];
> + clockevents_config_and_register(&timer->ced, timer->rate,
> + 1, GENMASK(timer->width - 1, 0));
> + }
> +
> + return 0;
> +}
This loop is identical to the second loop in rzn1_timer_probe_first(),
except for the lower and upper bound. Perhaps it can be factored out?
Alternatively, you can
1. Unify rzn1_timer_probe_{first,other}(), and pass the different
bounds as parameters, OR
2. Split rzn1_timer_probe_first() in three sub-functions, and call
these from rzn1_timer_probe() directly.
> +static struct platform_driver rzn1_timer_driver = {
> + .driver = {
> + .name = "rzn1_timer",
> + .of_match_table = rzn1_timer_of_match,
This driver can't be modular, and can't be unbound:
.suppress_bind_attrs = true
> + },
> +};
> +builtin_platform_driver_probe(rzn1_timer_driver, rzn1_timer_probe);
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v2 3/4] ARM: dts: r9a06g032: Add support for timers
From: Geert Uytterhoeven @ 2026-06-22 14:23 UTC (permalink / raw)
To: Herve Codina (Schneider Electric)
Cc: Wolfram Sang, Daniel Lezcano, Thomas Gleixner, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Magnus Damm, linux-renesas-soc,
linux-kernel, devicetree, Pascal Eberhard, Miquel Raynal,
Thomas Petazzoni
In-Reply-To: <20260429115054.158160-4-herve.codina@bootlin.com>
On Wed, 29 Apr 2026 at 13:51, Herve Codina (Schneider Electric)
<herve.codina@bootlin.com> wrote:
> In the Renesas RZ/N1 SoCs family, two timers block are available.
>
> Each block contains 8 timers composed of 6 16-bits timers and 2 32-bits
> timers.
>
> Each timer has its own interrupt line.
>
> Describe those timers blocks.
>
> Signed-off-by: Herve Codina (Schneider Electric) <herve.codina@bootlin.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in renesas-devel for v7.3, pending acceptance of the
DT bindings.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v2 1/4] dt-bindings: timer: Add the Renesas RZ/N1 timer
From: Geert Uytterhoeven @ 2026-06-22 14:22 UTC (permalink / raw)
To: Herve Codina (Schneider Electric)
Cc: Wolfram Sang, Daniel Lezcano, Thomas Gleixner, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Geert Uytterhoeven,
Magnus Damm, linux-renesas-soc, linux-kernel, devicetree,
Pascal Eberhard, Miquel Raynal, Thomas Petazzoni,
Krzysztof Kozlowski
In-Reply-To: <20260429115054.158160-2-herve.codina@bootlin.com>
On Wed, 29 Apr 2026 at 13:51, Herve Codina (Schneider Electric)
<herve.codina@bootlin.com> wrote:
> The Renesas RZ/N1 timer block controller is the controller in charge of
> timers available in the Renesas RZ/N1 SoCs family.
>
> This controller handles 8 timers:
> - 6 16-bit timers
> - 2 32-bit timers
>
> Signed-off-by: Herve Codina (Schneider Electric) <herve.codina@bootlin.com>
> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 1/9] dt-bindings: nvmem: imx-ocotp: Add support for secure-enclave
From: Frank Li @ 2026-06-22 14:14 UTC (permalink / raw)
To: Frieder Schrempf
Cc: Krzysztof Kozlowski, Frieder Schrempf, Srinivas Kandagatla,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Shawn Guo,
devicetree, imx, linux-arm-kernel, linux-kernel
In-Reply-To: <085262ba-32e5-4011-8df3-5a677575b2db@kontron.de>
On Wed, Jun 17, 2026 at 01:36:30PM +0200, Frieder Schrempf wrote:
> On 17.06.26 12:49, Krzysztof Kozlowski wrote:
> > On Tue, Jun 16, 2026 at 01:52:16PM +0200, Frieder Schrempf wrote:
> >> From: Frieder Schrempf <frieder.schrempf@kontron.de>
> >>
> >> Some SoCs like the i.MX9 family allow full access to the fuses only
> >> through the secure enclave firmware API. Add a property to reference
> >> the secure enclave node and let the driver use the API.
> >>
> >> Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de>
> >> ---
> >> Documentation/devicetree/bindings/nvmem/imx-ocotp.yaml | 4 ++++
> >> 1 file changed, 4 insertions(+)
> >>
> >> diff --git a/Documentation/devicetree/bindings/nvmem/imx-ocotp.yaml b/Documentation/devicetree/bindings/nvmem/imx-ocotp.yaml
> >> index a8076d0e2737..14a6429f4a4c 100644
> >> --- a/Documentation/devicetree/bindings/nvmem/imx-ocotp.yaml
> >> +++ b/Documentation/devicetree/bindings/nvmem/imx-ocotp.yaml
> >> @@ -53,6 +53,10 @@ properties:
> >> reg:
> >> maxItems: 1
> >>
> >> + secure-enclave:
> >> + $ref: /schemas/types.yaml#/definitions/phandle
> >> + description: A phandle to the secure enclave node
> >
> > Two things here:
> > 1. Here you describe what for is that phandle, how it is used by the
> > hardware. Currently the description repeats the property name and type,
> > so not much useful.
>
> Ok, agree.
>
> >
> > 2. If you access OTP via firmware, then this is completely different
> > interface than MMIO, thus:
> > A. reg is not appropriate
> > B. Device is very different thus it has different compatible and I even
> > claim should be in different binding. Devices having completely
> > different SW interface should not be in the same binding, at least
> > usually.
> >
> > If any of above is not accurate, then your commit msg should answer why
> > and give some background.
>
> Thanks for the feedback!
>
> The driver currently uses the limited MMIO (FSB) interface to access the
> OTPs. The intention is to support the firmware interface alongside the
> MMIO interface so the driver can pick the interface that is available
> (firmware might not be loaded) and fallback to MMIO.
Does ELE and MMIO access the same bank of fuse? If access the same bank,
why not always use MMIO. Any beneafit from ELE firmware?
Frank
>
> Following your argument would mean a driver deciding by itself which
> interface to use at runtime is not something we want to have in general,
> right?
>
> In turn this would mean we need two drivers, or at least two
> compatibles/bindings for something that is effectively the same hardware.
>
> Actually, my first RFC approach [1] was to create a separate driver. But
> in the end it seemed very weird to have two drivers and two DT nodes for
> the same hardware block. Also I have no idea what happens if both
> interfaces are used at the same time.
>
> The other idea from back then was to replace the MMIO (FSB) interface
> with ELE, but this would mean that we rely on the proprietary ELE
> firmware to be available for simple things like reading a MAC address,
> which is not desirable either, I guess.
>
> In which direction should I move on with this?
>
> [1]
> https://patchwork.kernel.org/project/linux-arm-kernel/patch/20250416142715.1042363-1-frieder@fris.de/
>
^ permalink raw reply
* Re: [PATCH 0/6] Additional regulator support for the Qualcomm SGMII SerDes PHY
From: Loic Poulain @ 2026-06-22 14:08 UTC (permalink / raw)
To: Mohd Ayaan Anwar
Cc: Vinod Koul, Kishon Vijay Abraham I, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bartosz Golaszewski,
Bjorn Andersson, Konrad Dybcio, Wasim Nazir, Mohd Ayaan Anwar,
Yijie Yang, linux-arm-msm, linux-phy, devicetree, linux-kernel,
Konrad Dybcio
In-Reply-To: <20251124-sgmiieth_serdes_regulator-v1-0-73ae8f9cbe2a@oss.qualcomm.com>
Hi,
On Mon, Nov 24, 2025 at 10:26 AM Mohd Ayaan Anwar
<mohd.anwar@oss.qualcomm.com> wrote:
>
> This patch series addresses a SerDes power-up failure observed on the
> QCS8300 Ride board using the phy-qcom-sgmii-eth driver. The issue occurs
> because the SerDes PHY requires both L5A and L4A regulators to be
> enabled during initialization. If either one of them is disabled, the
> status register does not reset, and the Ethernet interface fails to come
> up due to a timeout:
>
> [ 77.105651] qcom-dwmac-sgmii-phy 8909000.phy: QSERDES_COM_C_READY_STATUS timed-out
> [ 77.113447] qcom-ethqos 23040000.ethernet eth0: __stmmac_open: Serdes powerup failed
>
> Presumably, the issue is not seen on all users of this PHY because both
> regulators are often shared with other peripherals. However, the power
> rail schematics for boards using this SerDes PHY show that it is
> supplied by both L5A (1.2V) and L4A (0.9V) regulators.
>
> This series has been tested on the QCS8300 Ride board, and the reported
> issue was resolved. All Monaco and Lemans derivative boards require this
> new configuration as they use the same SerDes PHY.
>
> Signed-off-by: Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com>
This appears to be a real issue, but I haven’t seen a new version of
the series or any response to the feedback so far. Could you please
follow up on this?
> ---
> Mohd Ayaan Anwar (6):
> dt-bindings: phy: describe additional regulator for Qualcomm SGMII PHY
> arm64: dts: qcom: lemans-evk: add additional SerDes PHY regulator
> arm64: dts: qcom: lemans-ride-common: add additional SerDes PHY regulators
> arm64: dts: qcom: monaco-evk: fix the SerDes PHY regulators
> arm64: dts: qcom: qcs8300-ride: add additional SerDes PHY regulator
> phy: qcom: sgmii-eth: add second regulator support
>
> .../bindings/phy/qcom,sa8775p-dwmac-sgmii-phy.yaml | 4 ++++
> arch/arm64/boot/dts/qcom/lemans-evk.dts | 1 +
> arch/arm64/boot/dts/qcom/lemans-ride-common.dtsi | 4 ++++
> arch/arm64/boot/dts/qcom/monaco-evk.dts | 3 ++-
> arch/arm64/boot/dts/qcom/qcs8300-ride.dts | 2 ++
> drivers/phy/qualcomm/phy-qcom-sgmii-eth.c | 24 +++++++++++++++++++++-
> 6 files changed, 36 insertions(+), 2 deletions(-)
> ---
> base-commit: 0f2995693867bfb26197b117cd55624ddc57582f
> change-id: 20251124-sgmiieth_serdes_regulator-027fc6b15216
>
> Best regards,
> --
> Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com>
>
>
^ permalink raw reply
* Re: [PATCH 4/5] hwmon: add Stratix 10 SoC FPGA hardware monitor driver
From: Krzysztof Kozlowski @ 2026-06-22 14:08 UTC (permalink / raw)
To: tze.yee.ng
Cc: Guenter Roeck, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-hwmon, devicetree, linux-kernel, Dinh Nguyen, Mahesh Rao,
Jonathan Corbet, Shuah Khan, linux-doc
In-Reply-To: <081650bc4d92e9497b7a5a926e79a067cca3519f.1781861409.git.tze.yee.ng@altera.com>
On Fri, Jun 19, 2026 at 02:38:55AM -0700, tze.yee.ng@altera.com wrote:
> + dev_warn(dev, "unsupported sensor type %s\n", type);
> + return 0;
> +}
> +
> +static int stratix10_hwmon_probe_child_from_dt(struct device *dev,
> + struct device_node *child,
np
> + struct stratix10_hwmon_priv *priv)
> +{
> + struct device_node *grandchild;
child
> + const char *label;
> + u32 val;
> + int ret;
> +
> + for_each_child_of_node(child, grandchild) {
child
> + ret = of_property_read_u32(grandchild, "reg", &val);
> + if (ret) {
> + dev_err(dev, "missing reg property of %pOFn\n",
> + grandchild);
> + of_node_put(grandchild);
> + return ret;
> + }
> +
> + ret = of_property_read_string(grandchild, "label", &label);
> + if (ret)
> + label = grandchild->name;
> +
> + stratix10_hwmon_add_channel(dev, child->name, val, label, priv);
> + }
> +
> + return 0;
> +}
> +
> +static int stratix10_hwmon_probe_from_dt(struct device *dev,
> + struct stratix10_hwmon_priv *priv)
> +{
> + struct device_node *child;
> + int ret;
> +
> + if (!dev->of_node)
> + return 0;
> +
> + for_each_child_of_node(dev->of_node, child) {
Just use scoped. And why not available child node? Why do you probe
disabled channels?
> + ret = stratix10_hwmon_probe_child_from_dt(dev, child, priv);
> + if (ret) {
> + of_node_put(child);
> + return ret;
> + }
> + }
> +
> + return 0;
> +}
> +
> +static int stratix10_hwmon_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct stratix10_hwmon_priv *priv;
> + struct device *hwmon_dev;
> + int ret;
> +
> + priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
> + if (!priv)
> + return -ENOMEM;
> +
> + priv->client.dev = dev;
> + priv->client.priv = priv;
> + init_completion(&priv->completion);
> + mutex_init(&priv->lock);
> +
> + ret = stratix10_hwmon_probe_from_dt(dev, priv);
> + if (ret) {
> + dev_err(dev, "Unable to probe from device tree\n");
> + return ret;
> + }
> +
> + if (!priv->temperature_channels && !priv->voltage_channels) {
> + dev_err(dev, "no temperature or voltage channels in device tree\n");
> + return -ENODEV;
> + }
> +
> + priv->chan = stratix10_svc_request_channel_byname(&priv->client,
> + SVC_CLIENT_HWMON);
> + if (IS_ERR(priv->chan)) {
> + ret = PTR_ERR(priv->chan);
> + if (ret == -EPROBE_DEFER)
> + dev_dbg(dev, "service channel %s not ready, deferring probe\n",
> + SVC_CLIENT_HWMON);
> + else
> + dev_err(dev, "couldn't get service channel %s: %d\n",
> + SVC_CLIENT_HWMON, ret);
> + return ret;
> + }
> +
> + ret = stratix10_svc_add_async_client(priv->chan, false);
> + switch (ret) {
> + case 0:
> + priv->async = true;
> + break;
> + case -EINVAL:
> + dev_dbg(dev, "async operations not supported, using sync mode\n");
> + priv->async = false;
> + break;
> + default:
> + dev_err(dev, "failed to add async client: %d\n", ret);
> + stratix10_svc_free_channel(priv->chan);
> + return ret;
> + }
> +
> + dev_info(dev, "Initialized %d temperature and %d voltage channels\n",
> + priv->temperature_channels, priv->voltage_channels);
Drop, driver should be silent on success. dev_dbg might be fine, but
honestly that's static information from DT so zero usefulness.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 2/5] dt-bindings: firmware: svc: add hwmon property
From: Krzysztof Kozlowski @ 2026-06-22 14:05 UTC (permalink / raw)
To: tze.yee.ng
Cc: Guenter Roeck, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-hwmon, devicetree, linux-kernel, Dinh Nguyen, Mahesh Rao,
Jonathan Corbet, Shuah Khan, linux-doc
In-Reply-To: <be798fdfb7ec76e1f7d04c1fd00126c88c8a2e31.1781861409.git.tze.yee.ng@altera.com>
On Fri, Jun 19, 2026 at 02:38:53AM -0700, tze.yee.ng@altera.com wrote:
> From: Tze Yee Ng <tze.yee.ng@altera.com>
>
> Altera Stratix 10 SoCFPGA supports hardware monitor access through the
> service layer mailbox. Add an optional hwmon child node to the service
> layer binding so device trees can describe the hardware monitor.
>
> Signed-off-by: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
> Signed-off-by: Tze Yee Ng <tze.yee.ng@altera.com>
> ---
> .../devicetree/bindings/firmware/intel,stratix10-svc.yaml | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/firmware/intel,stratix10-svc.yaml b/Documentation/devicetree/bindings/firmware/intel,stratix10-svc.yaml
> index b42cfa78b28b..86ffdb10132f 100644
> --- a/Documentation/devicetree/bindings/firmware/intel,stratix10-svc.yaml
> +++ b/Documentation/devicetree/bindings/firmware/intel,stratix10-svc.yaml
> @@ -62,6 +62,10 @@ properties:
> $ref: /schemas/fpga/intel,stratix10-soc-fpga-mgr.yaml
> description: Optional child node for fpga manager to perform fabric configuration.
>
> + hwmon:
> + $ref: /schemas/hwmon/altr,stratix10-hwmon.yaml
So hwmon is completely fake wrapper over two other wrappers... If in
doubts, please read slides from DTS101 presentations from OSS, including
the chapter about Linux driver design.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/5] dt-bindings: hwmon: add Altera Stratix 10 hardware monitor binding
From: Krzysztof Kozlowski @ 2026-06-22 14:04 UTC (permalink / raw)
To: tze.yee.ng
Cc: Guenter Roeck, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-hwmon, devicetree, linux-kernel, Dinh Nguyen, Mahesh Rao,
Jonathan Corbet, Shuah Khan, linux-doc
In-Reply-To: <ac5a118394e96f707823463fedd32b6a484c1ceb.1781861409.git.tze.yee.ng@altera.com>
On Fri, Jun 19, 2026 at 02:38:52AM -0700, tze.yee.ng@altera.com wrote:
> From: Tze Yee Ng <tze.yee.ng@altera.com>
>
> Document the device tree binding for the Altera Stratix 10 SoC FPGA
> hardware monitor, including temperature and voltage sensor nodes.
Also:
A nit, subject: drop second/last, redundant "binding". The
"dt-bindings" prefix is already stating that these are bindings.
See also:
https://elixir.bootlin.com/linux/v7.1-rc7/source/Documentation/devicetree/bindings/submitting-patches.rst#L23
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/5] dt-bindings: hwmon: add Altera Stratix 10 hardware monitor binding
From: Krzysztof Kozlowski @ 2026-06-22 14:04 UTC (permalink / raw)
To: tze.yee.ng
Cc: Guenter Roeck, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-hwmon, devicetree, linux-kernel, Dinh Nguyen, Mahesh Rao,
Jonathan Corbet, Shuah Khan, linux-doc
In-Reply-To: <ac5a118394e96f707823463fedd32b6a484c1ceb.1781861409.git.tze.yee.ng@altera.com>
On Fri, Jun 19, 2026 at 02:38:52AM -0700, tze.yee.ng@altera.com wrote:
> From: Tze Yee Ng <tze.yee.ng@altera.com>
>
> Document the device tree binding for the Altera Stratix 10 SoC FPGA
> hardware monitor, including temperature and voltage sensor nodes.
>
> Signed-off-by: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
> Signed-off-by: Tze Yee Ng <tze.yee.ng@altera.com>
> ---
> .../bindings/hwmon/altr,stratix10-hwmon.yaml | 164 ++++++++++++++++++
> MAINTAINERS | 7 +
> 2 files changed, 171 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/hwmon/altr,stratix10-hwmon.yaml
>
> diff --git a/Documentation/devicetree/bindings/hwmon/altr,stratix10-hwmon.yaml b/Documentation/devicetree/bindings/hwmon/altr,stratix10-hwmon.yaml
> new file mode 100644
> index 000000000000..5bd98660ee7b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/hwmon/altr,stratix10-hwmon.yaml
> @@ -0,0 +1,164 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/hwmon/altr,stratix10-hwmon.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Altera Hardware Monitor for Stratix 10 SoC FPGA
> +
> +maintainers:
> + - Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
> + - Tze Yee Ng <tze.yee.ng@altera.com>
> +
> +description: |
> + The Altera Stratix 10 SoC FPGA hardware monitor unit provides on-chip
> + voltage and temperature sensors. These sensors can be used to monitor
> + external voltages and on-chip operating conditions such as internal
> + power rails and on-chip junction temperatures.
> +
> + The specific sensor configuration varies by device. Check the device
> + documentation to verify which sensors are available.
> +
> + Stratix 10 voltage sensors:
> +
> + page 0, channel 2 = 0.8V VCC
> + page 0, channel 3 = 1.8V VCCIO_SDM
> + page 0, channel 6 = 0.9V VCCERAM
> +
> + Stratix 10 temperature sensors:
> +
> + page 0, channel 0 = main die
> + page 0, channel 1 = tile bottom left
> + page 0, channel 2 = tile middle left
> + page 0, channel 3 = tile top left
> + page 0, channel 4 = tile bottom right
> + page 0, channel 5 = tile middle right
> + page 0, channel 6 = tile top right
> + page 0, channel 7 = hbm2 bottom
> + page 0, channel 8 = hbm2 top
> +
> +properties:
> + compatible:
> + const: altr,stratix10-hwmon
> +
Where are top-level properties? clocks? interrupts? power-domain,
resets? address space? Anything? Did you read writing bindings doc?
> + temperature:
> + description:
> + The temperature node specifies mappings of temperature sensor diodes on
> + the Stratix 10 SoC FPGA main die and tile die.
> + type: object
Blank line
> + properties:
> + '#address-cells':
> + const: 1
> + '#size-cells':
> + const: 0
Blank line
> + patternProperties:
> + "^input(@[0-9a-f]+)?$":
Unit address should not be optional.
Also, use consistent style of quotes.
> + description:
> + The input node specifies each individual temperature sensor.
> + type: object
> + properties:
> + reg:
> + description:
> + Sensor channel index in the lower 16-bits (0-15). For temperature
> + sensors, the page number is encoded in the upper 16-bits.
> + The driver encodes the SMC request argument as a channel
> + bitmask (1 << channel) in bits 0..15, with the page number
> + placed in bits 16..31. Channel values >= 16 are rejected to
> + avoid overlap with the page field. For example, reg = <2>
> + selects channel 2 and the driver passes 0x4 to the service layer.
> + label:
> + description:
> + A descriptive name for this channel (e.g. "Main Die" or
> + "Tile Bottom Left").
> + required:
> + - reg
> + additionalProperties: false
All this is difficult to read. Please open other bindings to understand
the style used in Linux kernel.
> + required:
> + - '#address-cells'
> + - '#size-cells'
> + additionalProperties: false
> +
> + voltage:
> + description:
> + The voltage node specifies mappings of voltage sensors on the Stratix 10
> + SoC FPGA analog to digital converter of the Secure Device Manager (SDM).
> + type: object
> + properties:
> + '#address-cells':
> + const: 1
> + '#size-cells':
> + const: 0
> + patternProperties:
> + "^input(@[0-9a-f]+)?$":
Isn't this usually called channel?
> + description:
> + The input node specifies each individual voltage sensor.
> + type: object
> + properties:
> + reg:
> + description:
> + Sensor channel index in the lower 16-bits (0-15). The driver
> + encodes the SMC request argument as a channel bitmask
> + (1 << channel). For example, reg = <2> selects channel 2 and
> + the driver passes 0x4 to the service layer.
> + label:
> + description:
> + A descriptive name for this channel (e.g. "0.8V VCC" or
> + "1.8V VCCIO_SDM").
> + required:
> + - reg
> + additionalProperties: false
> + required:
> + - '#address-cells'
> + - '#size-cells'
> + additionalProperties: false
> +
> +required:
> + - compatible
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + hwmon {
> + compatible = "altr,stratix10-hwmon";
> +
> + voltage {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + input@2 {
> + label = "0.8V VCC";
> + reg = <2>;
> + };
> +
> + input@3 {
> + label = "1.8V VCCIO_SDM";
> + reg = <3>;
> + };
> +
> + input@6 {
> + label = "0.9V VCCERAM";
> + reg = <6>;
> + };
> + };
> +
> + temperature {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + input@0 {
> + label = "Main Die";
> + reg = <0>;
> + };
> +
> + input@1 {
> + label = "Tile Bottom Left";
> + reg = <1>;
> + };
> +
> + input@2 {
> + label = "Tile Middle Left";
> + reg = <2>;
> + };
> + };
> + };
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 6aa3fe2ee1bb..678f6c429627 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -937,6 +937,13 @@ ALPS PS/2 TOUCHPAD DRIVER
> R: Pali Rohár <pali@kernel.org>
> F: drivers/input/mouse/alps.*
>
> +ALTERA STRATIX 10 SoC FPGA HWMON DRIVER
> +M: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
> +M: Tze Yee Ng <tze.yee.ng@altera.com>
> +L: linux-hwmon@vger.kernel.org
> +S: Maintained
> +F: Documentation/devicetree/bindings/hwmon/altr,stratix10-hwmon.yaml
> +
> ALTERA MAILBOX DRIVER
Does not look sorted. Please read this file before changing it.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 4/5] clk: qcom: gcc-hawi: Add support for global clock controller on Maili
From: Konrad Dybcio @ 2026-06-22 14:00 UTC (permalink / raw)
To: Taniya Das, Bjorn Andersson, Michael Turquette, Stephen Boyd,
Brian Masney, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Vivek Aknurwar
Cc: Ajit Pandey, Imran Shaik, Jagadeesh Kona, linux-arm-msm,
linux-clk, devicetree, linux-kernel
In-Reply-To: <20260618-maili_initial_clock-v1-4-d6ede0352113@oss.qualcomm.com>
On 6/18/26 7:21 PM, Taniya Das wrote:
> Add support for the global clock controller (GCC) on the Qualcomm Maili
> SoC by extending the Hawi global clock controller since Maili is identical
> to Hawi and has few additional clocks.
>
> Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com>
> ---
[...]
> @@ -3485,6 +3617,11 @@ static struct clk_regmap *gcc_hawi_clocks[] = {
> [GCC_USB3_PRIM_PHY_PIPE_CLK_SRC] = &gcc_usb3_prim_phy_pipe_clk_src.clkr,
> [GCC_VIDEO_AXI0_CLK] = &gcc_video_axi0_clk.clkr,
> [GCC_VIDEO_AXI0C_CLK] = &gcc_video_axi0c_clk.clkr,
> + /*
> + * Maili-only clocks: NULL here to size the array to the highest Maili
> + * clock index.
> + */
> + [GCC_QUPV3_WRAP_5_S_AHB_CLK] = NULL,
we have:
--- common.c
qcom_cc_really_probe():
...
cc->rclks = rclks; // desc->clks
cc->num_rclks = num_clks; // desc->num_clks
...
-> devm_of_clk_add_hw_provider(dev, qcom_cc_clk_hw_get, cc);
and qcom_cc_clk_hw_get() has:
if (idx >= cc->num_rclks) {
pr_err("%s: invalid index %u\n", __func__, idx);
return ERR_PTR(-EINVAL);
}
so I think this should be unnecessary
Besides, is that new set of clocks actually unique to Maili, or
is it bound to a QSPI usecase on the specific QUP?
Konrad
^ permalink raw reply
* Re: [PATCH 5/5] dt-bindings: mailbox: qcom: Document Maili CPUCP mailbox controller
From: Krzysztof Kozlowski @ 2026-06-22 13:59 UTC (permalink / raw)
To: Taniya Das
Cc: Bjorn Andersson, Michael Turquette, Stephen Boyd, Brian Masney,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Vivek Aknurwar,
Ajit Pandey, Imran Shaik, Jagadeesh Kona, linux-arm-msm,
linux-clk, devicetree, linux-kernel
In-Reply-To: <20260618-maili_initial_clock-v1-5-d6ede0352113@oss.qualcomm.com>
On Thu, Jun 18, 2026 at 10:51:20PM +0530, Taniya Das wrote:
> Document the CPU Control Processor (CPUCP) mailbox controller for the
> Qualcomm Maili SoC. It is software compatible with the X1E80100 CPUCP
> mailbox controller and uses it as a fallback compatible string.
>
> Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com>
> ---
> Documentation/devicetree/bindings/mailbox/qcom,cpucp-mbox.yaml | 1 +
> 1 file changed, 1 insertion(+)
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ 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