* [PATCH 19/35] fbdev: savage: Use safer strscpy() instead of strcpy()
From: Ai Chao @ 2026-04-25 6:59 UTC (permalink / raw)
To: deller, nicolas.ferre, alexandre.belloni, claudiu.beznea, linux,
dilinger, adaplas, James.Bottomley, FlorianSchandinat, alchark,
krzk, kees, rene, tzimmermann, rongqianfeng, thorsten.blum,
chelsyratnawat2001, soci, gregkh, daniel, linmq006,
fourier.thomas
Cc: linux-fbdev, dri-devel, linux-kernel, linux-arm-kernel,
linux-geode, linux-parisc, Ai Chao
In-Reply-To: <20260425065926.1091168-1-aichao@kylinos.cn>
Use a safer function strscpy() instead of strcpy() for copying to arrays.
Only idiomatic code replacement, and no functional changes.
Signed-off-by: Ai Chao <aichao@kylinos.cn>
---
drivers/video/fbdev/savage/savagefb-i2c.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/savage/savagefb-i2c.c b/drivers/video/fbdev/savage/savagefb-i2c.c
index 80fa87e2ae2f..820d1f83669d 100644
--- a/drivers/video/fbdev/savage/savagefb-i2c.c
+++ b/drivers/video/fbdev/savage/savagefb-i2c.c
@@ -136,7 +136,7 @@ static int savage_setup_i2c_bus(struct savagefb_i2c_chan *chan,
int rc = 0;
if (chan->par) {
- strcpy(chan->adapter.name, name);
+ strscpy(chan->adapter.name, name);
chan->adapter.owner = THIS_MODULE;
chan->adapter.algo_data = &chan->algo;
chan->adapter.dev.parent = &chan->par->pcidev->dev;
--
2.34.1
^ permalink raw reply related
* Re: [PATCH 03/35] fbdev: sisfb: Use safer strscpy() instead of strcpy()
From: Helge Deller @ 2026-04-25 8:08 UTC (permalink / raw)
To: Ai Chao, nicolas.ferre, alexandre.belloni, claudiu.beznea, linux,
dilinger, adaplas, James.Bottomley, FlorianSchandinat, alchark,
krzk, kees, rene, tzimmermann, rongqianfeng, thorsten.blum,
chelsyratnawat2001, soci, gregkh, daniel, linmq006,
fourier.thomas
Cc: linux-fbdev, dri-devel, linux-kernel, linux-arm-kernel,
linux-geode, linux-parisc
In-Reply-To: <20260425065926.1091168-4-aichao@kylinos.cn>
Hello Ai,
Thanks that you want to contribute!
But your series isn't beneficial in most areas.
Some examples:
On 4/25/26 08:58, Ai Chao wrote:
> Use a safer function strscpy() instead of strcpy() for copying to arrays.
>
> Only idiomatic code replacement, and no functional changes.
>
> Signed-off-by: Ai Chao <aichao@kylinos.cn>
> ---
> drivers/video/fbdev/sis/sis_main.c | 16 ++++++++--------
> 1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/video/fbdev/sis/sis_main.c b/drivers/video/fbdev/sis/sis_main.c
> index 84567d67f71d..e87fa261f76c 100644
> --- a/drivers/video/fbdev/sis/sis_main.c
> +++ b/drivers/video/fbdev/sis/sis_main.c
> @@ -205,7 +205,7 @@ static void sisfb_search_mode(char *name, bool quiet)
> }
>
> if(strlen(name) <= 19) {
> - strcpy(strbuf1, name);
> + strscpy(strbuf1, name);
We have strbuf1[20] above, and the length is checked.
There is no benefit of using strscpy() here.
(The code could be cleaned up in other ways though).
> for(i = 0; i < strlen(strbuf1); i++) {
> if(strbuf1[i] < '0' || strbuf1[i] > '9') strbuf1[i] = ' ';
> }
> @@ -5947,33 +5947,33 @@ static int sisfb_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
> #ifdef CONFIG_FB_SIS_300
> case PCI_DEVICE_ID_SI_730:
> ivideo->chip = SIS_730;
> - strcpy(ivideo->myid, "SiS 730");
> + strscpy(ivideo->myid, "SiS 730");
The compiler knows at build time the length of myid, and the "SIS 730" string.
Using strscpy() has no benefit here either. Contrary, the code generated
because of using strscpy() is probably even larger.
Don't replace such code with strscpy().
--- a/drivers/video/fbdev/i810/i810-i2c.c
+++ b/drivers/video/fbdev/i810/i810-i2c.c
@@ -91,7 +91,7 @@ static int i810_setup_i2c_bus(struct i810fb_i2c_chan *chan, const char *name)
{
int rc;
- strcpy(chan->adapter.name, name);
+ strscpy(chan->adapter.name, name);
Here it might make sense to use strscpy(), but it should be checked manually
and not using scripts to simply replace code.
That said: Thanks for your patches, but as-is I won't take them.
Helge
^ permalink raw reply
* [PATCH v2] arm: dts: allwinner: t113s: enable watchdog for reboot
From: Michal Piekos @ 2026-04-25 8:19 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland
Cc: devicetree, linux-arm-kernel, linux-sunxi, linux-kernel,
Michal Piekos
Reboot hangs on T113s boards because no restart handler is
available.
Enable the SoC watchdog whose driver registers a restart handler.
Tested on MangoPi MQ-R T113s.
Signed-off-by: Michal Piekos <michal.piekos@mmpsystems.pl>
---
Changes in v2:
- Moved watchdog enablement to SoC level dts following Jernej's
suggestion
- Link to v1: https://lore.kernel.org/r/20260412-t113-mangopi-reboot-hang-v1-1-5002cfa6e0cc@mmpsystems.pl
---
arch/arm/boot/dts/allwinner/sun8i-t113s.dtsi | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/allwinner/sun8i-t113s.dtsi b/arch/arm/boot/dts/allwinner/sun8i-t113s.dtsi
index 424f4a2487e2..d3bbed84eedb 100644
--- a/arch/arm/boot/dts/allwinner/sun8i-t113s.dtsi
+++ b/arch/arm/boot/dts/allwinner/sun8i-t113s.dtsi
@@ -34,6 +34,12 @@ cpu1: cpu@1 {
};
};
+ soc {
+ wdt {
+ status = "okay";
+ };
+ };
+
gic: interrupt-controller@1c81000 {
compatible = "arm,gic-400";
reg = <0x03021000 0x1000>,
---
base-commit: 27d128c1cff64c3b8012cc56dd5a1391bb4f1821
change-id: 20260412-t113-mangopi-reboot-hang-c9a9def82e2b
Best regards,
--
Michal Piekos <michal.piekos@mmpsystems.pl>
^ permalink raw reply related
* Re: [RFC PATCH v3 2/4] security: ima: call ima_init() again at late_initcall_sync for defered TPM
From: Jonathan McDowell @ 2026-04-25 9:10 UTC (permalink / raw)
To: Mimi Zohar
Cc: linux-security-module, linux-kernel, linux-integrity,
linux-arm-kernel, kvmarm, paul, jmorris, serge, roberto.sassu,
dmitry.kasatkin, eric.snowberg, jarkko, jgg, sudeep.holla, maz,
oupton, joey.gouly, suzuki.poulose, yuzenghui, catalin.marinas,
will, noodles, sebastianene, Yeoreum Yun
In-Reply-To: <43ff6ca37df45ed53061dad46e9d31a5118e5714.camel@linux.ibm.com>
On Fri, Apr 24, 2026 at 04:25:31PM -0400, Mimi Zohar wrote:
>Thanks, Jonathan!
>
>On Fri, 2026-04-24 at 14:24 +0100, Jonathan McDowell wrote:
>> -static int __init init_ima(void)
>> +static int __init init_ima(bool late)
>> {
>> int error;
>>
>> @@ -1247,10 +1247,26 @@ static int __init init_ima(void)
>> return 0;
>> }
>>
>> + /*
>> + * If we found the TPM during our first attempt, or we know there's no
>> + * TPM, nothing further to do
>> + */
>
>Perhaps it's just me, but the comment wording is a bit off. Could I change it
>to: If we either found the TPM or knew there's no TPM during our first attempt,
>nothing futher to do.
No objections to that updated wording from me.
>Otherwise the patch looks good.
>
>Mimi
>
>
>> + if (late && (ima_tpm_chip || !IS_ENABLED(CONFIG_TCG_TPM)))
>> + return 0;
>> +
>> + ima_tpm_chip = tpm_default_chip();
>> + if (!ima_tpm_chip && !late && IS_ENABLED(CONFIG_TCG_TPM)) {
>> + pr_debug("TPM not available, will try later\n");
>> + return -EPROBE_DEFER;
>> + }
>> +
>> + if (!ima_tpm_chip)
>> + pr_info("No TPM chip found, activating TPM-bypass!\n");
>> +
J.
--
Revd Jonathan McDowell, ULC | Run like hell!
^ permalink raw reply
* [PATCH 0/3] spi: rockchip: ISR fix and minor cleanups
From: John Madieu @ 2026-04-25 9:29 UTC (permalink / raw)
To: broonie, heiko
Cc: jon.lin, linux-spi, linux-arm-kernel, linux-rockchip,
linux-kernel, John Madieu
Hi all,
This series fixes one real bug in the Rockchip SPI driver and tidies up
two unrelated cosmetic issues spotted while looking at the same area.
The patches are independent and could be applied in any order; they are
ordered here by decreasing severity.
John Madieu (3):
spi: rockchip: Read ISR, not IMR, to detect cs-inactive IRQ
spi: rockchip: Drop unused and broken CR0 macros
spi: rockchip: Drop dead zero-check on fifo_len
drivers/spi/spi-rockchip.c | 8 ++------
1 file changed, 2 insertions(+), 6 deletions(-)
--
2.25.1
^ permalink raw reply
* [PATCH 1/3] spi: rockchip: Read ISR, not IMR, to detect cs-inactive IRQ
From: John Madieu @ 2026-04-25 9:29 UTC (permalink / raw)
To: broonie, heiko
Cc: jon.lin, linux-spi, linux-arm-kernel, linux-rockchip,
linux-kernel, John Madieu
In-Reply-To: <20260425092936.2590132-1-john.madieu@gmail.com>
rockchip_spi_isr() decides whether the current interrupt was the
cs-inactive event by reading IMR:
if (rs->cs_inactive &&
readl_relaxed(rs->regs + ROCKCHIP_SPI_IMR) & INT_CS_INACTIVE)
ctlr->target_abort(ctlr);
IMR is the interrupt mask register: it tells which sources are enabled,
not which one fired. In the PIO path, rockchip_spi_prepare_irq() enables
both INT_RF_FULL and INT_CS_INACTIVE in IMR when rs->cs_inactive is true:
if (rs->cs_inactive)
writel_relaxed(INT_RF_FULL | INT_CS_INACTIVE,
rs->regs + ROCKCHIP_SPI_IMR);
so the IMR check is always true once cs_inactive is enabled, and every
PIO interrupt - including normal RF_FULL completions - is dispatched to
ctlr->target_abort(), aborting the transfer. The bug is reachable on
ROCKCHIP_SPI_VER2_TYPE2 in target mode with a DMA-capable controller
when the transfer is short enough to fall back to PIO
(rockchip_spi_can_dma() returns false below fifo_len).
Read ISR (which is RISR masked by IMR) so the check actually reflects
which interrupt fired, and parenthesise the expression for clarity while
at it.
Fixes: 869f2c94db92 ("spi: rockchip: Stop spi slave dma receiver when cs inactive")
Signed-off-by: John Madieu <john.madieu@gmail.com>
---
drivers/spi/spi-rockchip.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/spi/spi-rockchip.c b/drivers/spi/spi-rockchip.c
index 14cd1b9d9793..de39f5da62cb 100644
--- a/drivers/spi/spi-rockchip.c
+++ b/drivers/spi/spi-rockchip.c
@@ -357,7 +357,8 @@ static irqreturn_t rockchip_spi_isr(int irq, void *dev_id)
struct rockchip_spi *rs = spi_controller_get_devdata(ctlr);
/* When int_cs_inactive comes, spi target abort */
- if (rs->cs_inactive && readl_relaxed(rs->regs + ROCKCHIP_SPI_IMR) & INT_CS_INACTIVE) {
+ if (rs->cs_inactive &&
+ (readl_relaxed(rs->regs + ROCKCHIP_SPI_ISR) & INT_CS_INACTIVE)) {
ctlr->target_abort(ctlr);
writel_relaxed(0, rs->regs + ROCKCHIP_SPI_IMR);
writel_relaxed(0xffffffff, rs->regs + ROCKCHIP_SPI_ICR);
--
2.25.1
^ permalink raw reply related
* [PATCH 2/3] spi: rockchip: Drop unused and broken CR0 macros
From: John Madieu @ 2026-04-25 9:29 UTC (permalink / raw)
To: broonie, heiko
Cc: jon.lin, linux-spi, linux-arm-kernel, linux-rockchip,
linux-kernel, John Madieu
In-Reply-To: <20260425092936.2590132-1-john.madieu@gmail.com>
Two CTRLR0 macros are defined but never referenced, and both are wrong:
- CR0_XFM_MASK shifts by SPI_XFM_OFFSET, which does not exist anywhere
in the tree. The intended symbol is CR0_XFM_OFFSET.
- CR0_MTM_OFFSET is defined as 0x21, i.e. bit 33 of a 32-bit register.
The value is meaningless and the macro is unused.
Drop both. They can be re-introduced correctly when an actual user
appears.
Signed-off-by: John Madieu <john.madieu@gmail.com>
---
drivers/spi/spi-rockchip.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/spi/spi-rockchip.c b/drivers/spi/spi-rockchip.c
index de39f5da62cb..231fbcf0e7aa 100644
--- a/drivers/spi/spi-rockchip.c
+++ b/drivers/spi/spi-rockchip.c
@@ -98,7 +98,6 @@
#define CR0_FRF_MICROWIRE 0x2
#define CR0_XFM_OFFSET 18
-#define CR0_XFM_MASK (0x03 << SPI_XFM_OFFSET)
#define CR0_XFM_TR 0x0
#define CR0_XFM_TO 0x1
#define CR0_XFM_RO 0x2
@@ -109,8 +108,6 @@
#define CR0_SOI_OFFSET 23
-#define CR0_MTM_OFFSET 0x21
-
/* Bit fields in SER, 2bit */
#define SER_MASK 0x3
--
2.25.1
^ permalink raw reply related
* [PATCH 3/3] spi: rockchip: Drop dead zero-check on fifo_len
From: John Madieu @ 2026-04-25 9:29 UTC (permalink / raw)
To: broonie, heiko
Cc: jon.lin, linux-spi, linux-arm-kernel, linux-rockchip,
linux-kernel, John Madieu
In-Reply-To: <20260425092936.2590132-1-john.madieu@gmail.com>
rs->fifo_len is assigned from get_fifo_len(), which returns 64 for the
two known SPI controller versions and 32 for everything else - never 0.
The subsequent
if (!rs->fifo_len)
return dev_err_probe(...);
is therefore unreachable.
Drop the check. If unknown controller versions ever need to fail probe
explicitly, that should be expressed in get_fifo_len() itself, not
through an impossible post-condition.
Signed-off-by: John Madieu <john.madieu@gmail.com>
---
drivers/spi/spi-rockchip.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/spi/spi-rockchip.c b/drivers/spi/spi-rockchip.c
index 231fbcf0e7aa..1bd48376498a 100644
--- a/drivers/spi/spi-rockchip.c
+++ b/drivers/spi/spi-rockchip.c
@@ -824,8 +824,6 @@ static int rockchip_spi_probe(struct platform_device *pdev)
}
rs->fifo_len = get_fifo_len(rs);
- if (!rs->fifo_len)
- return dev_err_probe(&pdev->dev, -EINVAL, "Failed to get fifo length\n");
pm_runtime_set_autosuspend_delay(&pdev->dev, ROCKCHIP_AUTOSUSPEND_TIMEOUT);
pm_runtime_use_autosuspend(&pdev->dev);
--
2.25.1
^ permalink raw reply related
* Re: [PATCH net-next v6 3/3] riscv: dts: eswin: eic7700-hifive-premier-p550: enable Ethernet controller
From: Krzysztof Kozlowski @ 2026-04-25 9:33 UTC (permalink / raw)
To: lizhi2
Cc: devicetree, andrew+netdev, davem, edumazet, kuba, robh, krzk+dt,
conor+dt, netdev, pabeni, mcoquelin.stm32, alexandre.torgue,
rmk+kernel, pjw, palmer, aou, alex, linux-riscv, linux-stm32,
linux-arm-kernel, linux-kernel, maxime.chevallier, ningyu, linmin,
pinkesh.vaghela, pritesh.patel, weishangjuan, horms
In-Reply-To: <20260423085650.820-1-lizhi2@eswincomputing.com>
On Thu, Apr 23, 2026 at 04:56:50PM +0800, lizhi2@eswincomputing.com wrote:
> From: Zhi Li <lizhi2@eswincomputing.com>
>
> Enable the on-board Gigabit Ethernet controller on the
> HiFive Premier P550 development board.
>
> Signed-off-by: Zhi Li <lizhi2@eswincomputing.com>
> ---
> .../devicetree/bindings/mfd/syscon.yaml | 2 +
> .../dts/eswin/eic7700-hifive-premier-p550.dts | 232 ++++++++++++++++++
> arch/riscv/boot/dts/eswin/eic7700.dtsi | 103 ++++++++
> 3 files changed, 337 insertions(+)
>
Please split the patches.
Please run scripts/checkpatch.pl on the patches and fix reported
warnings. After that, run also 'scripts/checkpatch.pl --strict' on the
patches and (probably) fix more warnings. Some warnings can be ignored,
especially from --strict run, but the code here looks like it needs a
fix. Feel free to get in touch if the warning is not clear.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v4 2/3] dt-bindings: mfd: syscon: add aspeed,ast2600-i3c-global compatible
From: Krzysztof Kozlowski @ 2026-04-25 9:40 UTC (permalink / raw)
To: Dawid Glazik
Cc: Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Joel Stanley, Andrew Jeffery, linux-aspeed, devicetree,
linux-arm-kernel, linux-kernel, maciej.lawniczak
In-Reply-To: <41d66492e1a1d42f6888459288311094c8b7bc51.1777058942.git.dawid.glazik@linux.intel.com>
On Fri, Apr 24, 2026 at 10:21:00PM +0200, Dawid Glazik wrote:
> Add aspeed,ast2600-i3c-global to the syscon binding compatible
> lists to document the AST2600 I3C global register syscon node.
>
> Signed-off-by: Dawid Glazik <dawid.glazik@linux.intel.com>
> ---
> Documentation/devicetree/bindings/mfd/syscon.yaml | 2 ++
> 1 file changed, 2 insertions(+)
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 6/7] media: dt-bindings: add NXP i.MX95 compatible string
From: Krzysztof Kozlowski @ 2026-04-25 9:50 UTC (permalink / raw)
To: Guoniu Zhou
Cc: Michael Riesch, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Laurent Pinchart, Frank Li, Sakari Ailus, Bryan O'Donoghue,
Mehdi Djait, Hans Verkuil, linux-media, linux-kernel, devicetree,
imx, linux-arm-kernel, linux-rockchip
In-Reply-To: <20260423-csi2_imx95-v2-6-934c02f3422a@oss.nxp.com>
On Thu, Apr 23, 2026 at 04:23:01PM +0800, Guoniu Zhou wrote:
> The i.MX95 CSI-2 controller is nearly identical to i.MX93, with the
> main difference being the data output interface:
>
> i.MX93 use IPI (Image Pixel Interface), which requires:
> - Pixel clock input
> - Software configuration through registers
>
> i.MX95 uses IDI (Image Data Interface), which:
> - Does not require pixel clock
> - Is software transparent (no register configuration needed)
>
> Due to these differences in register layout and initialization needs,
> the two variants cannot share the same compatible string. The driver
> needs to distinguish between them to handle the interface correctly.
>
> Signed-off-by: Guoniu Zhou <guoniu.zhou@oss.nxp.com>
> ---
> Changes in v2:
> - Add dedicated constraint block for i.MX95 to reflect different clock
> requirements (only per clock needed vs i.MX93 which needs both per
> and pixel clocks)
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/5] dt-bindings: display: panel: Document Samsung LTL101DL02-002 panel
From: Krzysztof Kozlowski @ 2026-04-25 9:54 UTC (permalink / raw)
To: Lukas Timmermann
Cc: Neil Armstrong, Jessica Zhang, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Thierry Reding, Sam Ravnborg,
Douglas Anderson, Sylwester Nawrocki, Chanwoo Choi, Alim Akhtar,
Michael Turquette, Stephen Boyd, dri-devel, devicetree,
linux-kernel, linux-samsung-soc, linux-clk, linux-arm-kernel,
Alexandre Marquet
In-Reply-To: <20260423-manta-display-v1-1-196f80c5673a@timmermann.space>
On Thu, Apr 23, 2026 at 11:14:37PM +0200, Lukas Timmermann wrote:
> From: Alexandre Marquet <tb@a-marquet.fr>
>
> Add the dt-bindings for the LTL101DL02-002 panel.
>
> Signed-off-by: Alexandre Marquet <tb@a-marquet.fr>
> Signed-off-by: Lukas Timmermann <linux@timmermann.space>
> ---
> Documentation/devicetree/bindings/display/panel/panel-simple.yaml | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
> index 24e277b19094..2de0a3a6d1fe 100644
> --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
> +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
> @@ -283,6 +283,8 @@ properties:
> # Samsung Electronics 10.6" FWXGA (1366x768) TFT LCD panel
> - samsung,ltl106al01
> # Samsung Electronics 10.1" WSVGA TFT LCD panel
> + - samsung,ltl101dl02-002
This looks like incorrectly placed (101 < 106) and comment should be
above the compatible, at least judging by context.
> + # Samsung Electronics 10.1" WQXGA (2560x1600) TFT LCD panel
> - samsung,ltn101nt05
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 3/5] dt-bindings: clock: samsung: Add fimd1 and vpll muxes
From: Krzysztof Kozlowski @ 2026-04-25 9:56 UTC (permalink / raw)
To: Lukas Timmermann
Cc: Neil Armstrong, Jessica Zhang, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Thierry Reding, Sam Ravnborg,
Douglas Anderson, Sylwester Nawrocki, Chanwoo Choi, Alim Akhtar,
Michael Turquette, Stephen Boyd, dri-devel, devicetree,
linux-kernel, linux-samsung-soc, linux-clk, linux-arm-kernel
In-Reply-To: <20260423-manta-display-v1-3-196f80c5673a@timmermann.space>
On Thu, Apr 23, 2026 at 11:14:39PM +0200, Lukas Timmermann wrote:
> Add two clocks necessary for the google-manta board
> display.
>
> Signed-off-by: Lukas Timmermann <linux@timmermann.space>
> ---
> include/dt-bindings/clock/exynos5250.h | 2 ++
> 1 file changed, 2 insertions(+)
>
If there is going to be any new version, better to split this and send
all SoC patches (clk + DTS) separately from DRM.
No need to resend just for that, I will pick up Samsung SoC things after
the merge window.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 5/5] ARM: dts: exynos: Add display support for exynos5250-manta
From: Krzysztof Kozlowski @ 2026-04-25 9:58 UTC (permalink / raw)
To: Lukas Timmermann
Cc: Neil Armstrong, Jessica Zhang, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Thierry Reding, Sam Ravnborg,
Douglas Anderson, Sylwester Nawrocki, Chanwoo Choi, Alim Akhtar,
Michael Turquette, Stephen Boyd, dri-devel, devicetree,
linux-kernel, linux-samsung-soc, linux-clk, linux-arm-kernel,
Alexandre Marquet
In-Reply-To: <20260423-manta-display-v1-5-196f80c5673a@timmermann.space>
On Thu, Apr 23, 2026 at 11:14:41PM +0200, Lukas Timmermann wrote:
> Adds the necessary entries for panel and backlight as
> well as the fimd controller.
>
> Signed-off-by: Alexandre Marquet <tb@a-marquet.fr>
> Signed-off-by: Lukas Timmermann <linux@timmermann.space>
> ---
> arch/arm/boot/dts/samsung/exynos5250-manta.dts | 99 ++++++++++++++++++++++++++
> 1 file changed, 99 insertions(+)
>
> diff --git a/arch/arm/boot/dts/samsung/exynos5250-manta.dts b/arch/arm/boot/dts/samsung/exynos5250-manta.dts
> index 76d3657eb22f..eb97a28ff4e3 100644
> --- a/arch/arm/boot/dts/samsung/exynos5250-manta.dts
> +++ b/arch/arm/boot/dts/samsung/exynos5250-manta.dts
> @@ -25,6 +25,29 @@ aliases {
> mmc1 = &mmc_1; /* WiFi */
> };
>
> + backlight: backlight {
> + compatible = "pwm-backlight";
> + pwms = <&pwm 0 1000000 0>;
> +
> + brightness-levels = <2 255>; /* TODO */
> + num-interpolated-steps = <254>; /* TODO */
> + default-brightness-level = <102>; /* TODO */
> + post-pwm-on-delay-ms = <97>; /* TODO */
> +
> + power-supply = <&backlight_reg>;
> + enable-gpios = <&gpg0 5 GPIO_ACTIVE_HIGH>;
> +
> + pinctrl-0 = <&led_bl_reset &pwm0_out>;
> + pinctrl-names = "default";
> + };
> +
> + backlight_reg: regulator-backlight {
> + compatible = "regulator-fixed";
> + regulator-name = "APS_EN_18V";
> + pinctrl-0 = <&aps_en_18v>;
> + pinctrl-names = "default";
No enable GPIO? No voltage?
> + };
> +
> /* Voltage source unknown */
> bmp180_vdda_reg: regulator-bmp180-vdda {
> compatible = "regulator-fixed";
> @@ -105,6 +128,28 @@ multi-led {
> leds = <&status_red>, <&status_green>, <&status_blue>, <&status_white>;
> };
>
> + panel {
> + compatible = "samsung,ltl101dl02-002";
> +
> + backlight = <&backlight>;
> + power-supply = <&panel_reg>;
> + enable-gpios = <&gph1 7 GPIO_ACTIVE_HIGH>;
> + pinctrl-0 = <&lcd_en>;
> + pinctrl-names = "default";
> + no-hpd;
> +
> + port {
> + panel: endpoint {
> + remote-endpoint = <&dp_out>;
> + };
> + };
> + };
> +
> + panel_reg: regulator-panel {
> + compatible = "regulator-fixed";
> + regulator-name = "LCD_EN";
That's incomplete. You should have at least voltage.
> + };
> +
> pwrseq: mmc1-pwrseq {
> compatible = "mmc-pwrseq-simple";
>
> @@ -146,10 +191,36 @@ &cpu1 {
> cpu-supply = <&buck2_reg>;
> };
>
> +&dp {
> + status = "okay";
> +
> + samsung,color-space = <0>;
> + samsung,color-depth = <1>;
> + samsung,link-rate = <0x0a>;
> + samsung,lane-count = <4>;
> + samsung,dynamic-range = <0>;
> + samsung,ycbcr-coeff = <0>;
> +
> + ports {
> + port {
> + dp_out: endpoint {
> + remote-endpoint = <&panel>;
> + };
> + };
> + };
> +};
> +
> &ehci {
> status = "disabled";
> };
>
> +&fimd {
> + status = "okay";
> +
> + assigned-clocks = <&clock CLK_MOUT_FIMD1>, <&clock CLK_MOUT_VPLL>;
> + assigned-clock-parents = <&clock CLK_MOUT_VPLL>;
> +};
> +
> &i2c_1 {
> status = "okay";
>
> @@ -396,6 +467,12 @@ ldo25_reg: LDO25 {
> };
> };
>
> +&mali {
> + status = "okay";
> +
> + mali-supply = <&buck4_reg>;
> +};
> +
> &mixer {
> status = "okay";
> };
> @@ -489,6 +566,14 @@ wlan_irq: wlan-irq-pins {
> };
>
> &pinctrl_1 {
> + aps_en_18v: aps-en-18v-pins {
> + samsung,pins = "gph1-6";
> + samsung,pin-function = <EXYNOS_PIN_FUNC_OUTPUT>; /* TODO */
TODO why? IOW, what are you missing here? Was this tested?
TODO note can stay, but I would prefer to see short comment explaining
why.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v1 1/3] dt-bindings: PCI: imx6q-pcie: Add intr, aer and pme interrupts
From: Krzysztof Kozlowski @ 2026-04-25 10:00 UTC (permalink / raw)
To: Conor Dooley
Cc: Richard Zhu, robh, krzk+dt, conor+dt, bhelgaas, frank.li, l.stach,
lpieralisi, kwilczynski, mani, s.hauer, kernel, festevam,
linux-pci, linux-arm-kernel, devicetree, imx, linux-kernel
In-Reply-To: <20260424-sinless-unfiled-d1087a894da5@spud>
On Fri, Apr 24, 2026 at 06:06:18PM +0100, Conor Dooley wrote:
> On Fri, Apr 24, 2026 at 10:57:33AM +0800, Richard Zhu wrote:
> > Add optional 'intr', 'aer', and 'pme' interrupt entries to the i.MX6Q
> > PCIe binding to support PCIe event-based interrupts for general
> > controller events, Advanced Error Reporting, and Power Management Events
> > respectively.
> >
> > Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
> > ---
>
> This binding supports lots of devices. Do they all have these additional
> interrupts?
Yep. Commit msg says only i.MX6Q...
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v14 05/28] drm/display: bridge_connector: Use HDMI color format for HDMI conns
From: Dmitry Baryshkov @ 2026-04-25 11:02 UTC (permalink / raw)
To: Nicolas Frattaroli
Cc: Harry Wentland, Leo Li, Rodrigo Siqueira, Alex Deucher,
Christian König, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Sandy Huang, Heiko Stübner,
Andy Yan, Jani Nikula, Rodrigo Vivi, Joonas Lahtinen,
Tvrtko Ursulin, Dmitry Baryshkov, Sascha Hauer, Rob Herring,
Jonathan Corbet, Shuah Khan, kernel, amd-gfx, dri-devel,
linux-kernel, linux-arm-kernel, linux-rockchip, intel-gfx,
intel-xe, linux-doc, wayland-devel
In-Reply-To: <20260423-color-format-v14-5-449a419ccbd4@collabora.com>
On Thu, Apr 23, 2026 at 09:03:28PM +0200, Nicolas Frattaroli wrote:
> For bridge connectors which contain an HDMI bridge at some stage, the
> HDMI state helpers' format selection logic should be involved.
>
> Add an implementation for the drm_bridge_funcs color_format function,
> which translates from the HDMI state's output format to a connector
> format for bridge connectors involving an HDMI bridge, but return the
> connector state's color_format member unchanged otherwise.
>
> Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
> ---
> drivers/gpu/drm/display/drm_bridge_connector.c | 24 ++++++++++++++++++++++++
> 1 file changed, 24 insertions(+)
Thanks! I like how it ended up looking.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH 03/35] fbdev: sisfb: Use safer strscpy() instead of strcpy()
From: David Laight @ 2026-04-25 11:02 UTC (permalink / raw)
To: Helge Deller
Cc: Ai Chao, nicolas.ferre, alexandre.belloni, claudiu.beznea, linux,
dilinger, adaplas, James.Bottomley, FlorianSchandinat, alchark,
krzk, kees, rene, tzimmermann, rongqianfeng, thorsten.blum,
chelsyratnawat2001, soci, gregkh, daniel, linmq006,
fourier.thomas, linux-fbdev, dri-devel, linux-kernel,
linux-arm-kernel, linux-geode, linux-parisc
In-Reply-To: <ccd01f97-d4b7-4bd0-92c1-adc3b1136cbc@gmx.de>
On Sat, 25 Apr 2026 10:08:08 +0200
Helge Deller <deller@gmx.de> wrote:
> Hello Ai,
...
> > - strcpy(ivideo->myid, "SiS 730");
> > + strscpy(ivideo->myid, "SiS 730");
>
> The compiler knows at build time the length of myid, and the "SIS 730" string.
> Using strscpy() has no benefit here either. Contrary, the code generated
> because of using strscpy() is probably even larger.
> Don't replace such code with strscpy().
Both should get converted to a memcpy().
If you increase the literal to be too long I'm pretty sure you'll
get a compiler warning/error from strcpy().
OTOH strscpy() is more likely to truncate the string (I'd need to
check).
So leaving it as strcpy() is fine - and possibly even better.
The header files might get changed to error strcpy() unless the compiler
knows the source string has a constant length and the destination is
big enough - but that hasn't been done yet.
David
^ permalink raw reply
* Re: [PATCH v14 06/28] drm/bridge: Act on the DRM color format property
From: Dmitry Baryshkov @ 2026-04-25 11:03 UTC (permalink / raw)
To: Nicolas Frattaroli
Cc: Harry Wentland, Leo Li, Rodrigo Siqueira, Alex Deucher,
Christian König, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Sandy Huang, Heiko Stübner,
Andy Yan, Jani Nikula, Rodrigo Vivi, Joonas Lahtinen,
Tvrtko Ursulin, Dmitry Baryshkov, Sascha Hauer, Rob Herring,
Jonathan Corbet, Shuah Khan, kernel, amd-gfx, dri-devel,
linux-kernel, linux-arm-kernel, linux-rockchip, intel-gfx,
intel-xe, linux-doc, wayland-devel
In-Reply-To: <20260423-color-format-v14-6-449a419ccbd4@collabora.com>
On Thu, Apr 23, 2026 at 09:03:29PM +0200, Nicolas Frattaroli wrote:
> The new DRM color format property allows userspace to request a specific
> color format on a connector. In turn, this fills the connector state's
> color_format member to switch color formats.
>
> Make drm_bridges consider the color_format set in the connector state
> during the atomic bridge check. Call into the connector function to get
> the connector state's connector color format. For bridge connectors
> including an HDMI bridge, this will make use of whatever the HDMI
> implementation set as output formats, and AUTO will never be part of the
> rejection logic.
>
> Reject any output bus formats that do not correspond to the requested
> color format. DRM_CONNECTOR_COLOR_FORMAT_AUTO is always accepted as a
> matching color format for a bus format, meaning that non-HDMI bridge
> chains will end up picking the first bus format choice that works, as
> has already been the case previously.
>
> Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
> ---
> drivers/gpu/drm/drm_bridge.c | 64 +++++++++++++++++++++++++++++++++++++++++++-
> 1 file changed, 63 insertions(+), 1 deletion(-)
>
Nice, generic and easily reusable for DP!
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v14 04/28] drm/connector: Let connectors have a say in their color format
From: Dmitry Baryshkov @ 2026-04-25 11:09 UTC (permalink / raw)
To: Nicolas Frattaroli
Cc: Harry Wentland, Leo Li, Rodrigo Siqueira, Alex Deucher,
Christian König, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Sandy Huang, Heiko Stübner,
Andy Yan, Jani Nikula, Rodrigo Vivi, Joonas Lahtinen,
Tvrtko Ursulin, Dmitry Baryshkov, Sascha Hauer, Rob Herring,
Jonathan Corbet, Shuah Khan, kernel, amd-gfx, dri-devel,
linux-kernel, linux-arm-kernel, linux-rockchip, intel-gfx,
intel-xe, linux-doc, wayland-devel
In-Reply-To: <20260423-color-format-v14-4-449a419ccbd4@collabora.com>
On Thu, Apr 23, 2026 at 09:03:27PM +0200, Nicolas Frattaroli wrote:
> Add a function to get the connector color format from a connector state,
> and a new function pointer in drm_connector_funcs to allow connectors to
> override what connector color format it returns.
>
> This is useful for the bridge chain recursive bus format selection code,
> which does not wish to implement connector implementation specific
> checks like whether it involves HDMI.
>
> Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
> ---
> drivers/gpu/drm/drm_connector.c | 16 ++++++++++++++++
> include/drm/drm_connector.h | 12 ++++++++++++
> 2 files changed, 28 insertions(+)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH 2/5] drm/panel-edp: Add support for Samsung LTL101DL02-002 panel
From: Dmitry Baryshkov @ 2026-04-25 11:23 UTC (permalink / raw)
To: Doug Anderson
Cc: Lukas Timmermann, Neil Armstrong, Jessica Zhang,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Thierry Reding, Sam Ravnborg, Krzysztof Kozlowski,
Sylwester Nawrocki, Chanwoo Choi, Alim Akhtar, Michael Turquette,
Stephen Boyd, dri-devel, devicetree, linux-kernel,
linux-samsung-soc, linux-clk, linux-arm-kernel, Alexandre Marquet
In-Reply-To: <CAD=FV=VNvPtG_f1W942SKJfM4ptK8Wvd-nZs4geBCG3bO_A0BA@mail.gmail.com>
On Thu, Apr 23, 2026 at 02:49:53PM -0700, Doug Anderson wrote:
> Hi,
>
> On Thu, Apr 23, 2026 at 2:15 PM Lukas Timmermann <linux@timmermann.space> wrote:
> >
> > From: Alexandre Marquet <tb@a-marquet.fr>
> >
> > Add a panel entry for the Samsung LTL101DL02-002 panel, as found in
> > Samsung Manta (Google Nexus 10).
> >
> > Signed-off-by: Alexandre Marquet <tb@a-marquet.fr>
> > Signed-off-by: Lukas Timmermann <linux@timmermann.space>
> > ---
> > drivers/gpu/drm/panel/panel-edp.c | 31 +++++++++++++++++++++++++++++++
> > 1 file changed, 31 insertions(+)
>
> Adding new panels like this is discouraged these days. Is there a
> reason you can't use the generic "edp-panel" compatible? I know that
> the exynos5 driver is pretty old, but a quick glance shows that it's
> based on the same analogix-dp core that "rockchip,analogix-dp" is, and
> that seems to have support for aux-bus...
I'd also prefer to NAK this change. If the driver can't cope with the
"edp-panel", the driver must be modified rather than pushing more and
more legacy panel compatibile strings.
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH 5/5] ARM: dts: exynos: Add display support for exynos5250-manta
From: Dmitry Baryshkov @ 2026-04-25 11:27 UTC (permalink / raw)
To: Lukas Timmermann
Cc: Neil Armstrong, Jessica Zhang, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Thierry Reding, Sam Ravnborg,
Douglas Anderson, Krzysztof Kozlowski, Sylwester Nawrocki,
Chanwoo Choi, Alim Akhtar, Michael Turquette, Stephen Boyd,
dri-devel, devicetree, linux-kernel, linux-samsung-soc, linux-clk,
linux-arm-kernel, Alexandre Marquet
In-Reply-To: <20260423-manta-display-v1-5-196f80c5673a@timmermann.space>
On Thu, Apr 23, 2026 at 11:14:41PM +0200, Lukas Timmermann wrote:
> Adds the necessary entries for panel and backlight as
> well as the fimd controller.
>
> Signed-off-by: Alexandre Marquet <tb@a-marquet.fr>
> Signed-off-by: Lukas Timmermann <linux@timmermann.space>
> ---
> arch/arm/boot/dts/samsung/exynos5250-manta.dts | 99 ++++++++++++++++++++++++++
> 1 file changed, 99 insertions(+)
>
> diff --git a/arch/arm/boot/dts/samsung/exynos5250-manta.dts b/arch/arm/boot/dts/samsung/exynos5250-manta.dts
> index 76d3657eb22f..eb97a28ff4e3 100644
> --- a/arch/arm/boot/dts/samsung/exynos5250-manta.dts
> +++ b/arch/arm/boot/dts/samsung/exynos5250-manta.dts
> @@ -25,6 +25,29 @@ aliases {
> mmc1 = &mmc_1; /* WiFi */
> };
>
> + backlight: backlight {
> + compatible = "pwm-backlight";
> + pwms = <&pwm 0 1000000 0>;
> +
> + brightness-levels = <2 255>; /* TODO */
> + num-interpolated-steps = <254>; /* TODO */
> + default-brightness-level = <102>; /* TODO */
> + post-pwm-on-delay-ms = <97>; /* TODO */
> +
> + power-supply = <&backlight_reg>;
> + enable-gpios = <&gpg0 5 GPIO_ACTIVE_HIGH>;
> +
> + pinctrl-0 = <&led_bl_reset &pwm0_out>;
> + pinctrl-names = "default";
> + };
> +
> + backlight_reg: regulator-backlight {
> + compatible = "regulator-fixed";
> + regulator-name = "APS_EN_18V";
> + pinctrl-0 = <&aps_en_18v>;
> + pinctrl-names = "default";
> + };
> +
> /* Voltage source unknown */
> bmp180_vdda_reg: regulator-bmp180-vdda {
> compatible = "regulator-fixed";
> @@ -105,6 +128,28 @@ multi-led {
> leds = <&status_red>, <&status_green>, <&status_blue>, <&status_white>;
> };
>
> + panel {
> + compatible = "samsung,ltl101dl02-002";
> +
> + backlight = <&backlight>;
> + power-supply = <&panel_reg>;
> + enable-gpios = <&gph1 7 GPIO_ACTIVE_HIGH>;
> + pinctrl-0 = <&lcd_en>;
> + pinctrl-names = "default";
> + no-hpd;
> +
> + port {
> + panel: endpoint {
> + remote-endpoint = <&dp_out>;
> + };
> + };
> + };
No, the panel is not just being attached to the device. I asumme it is
controlled over the AUX bus, so it shoud be a child device of the
AUX bus.
> +
> + panel_reg: regulator-panel {
> + compatible = "regulator-fixed";
> + regulator-name = "LCD_EN";
> + };
> +
> pwrseq: mmc1-pwrseq {
> compatible = "mmc-pwrseq-simple";
>
> @@ -146,10 +191,36 @@ &cpu1 {
> cpu-supply = <&buck2_reg>;
> };
>
> +&dp {
> + status = "okay";
> +
> + samsung,color-space = <0>;
> + samsung,color-depth = <1>;
> + samsung,link-rate = <0x0a>;
> + samsung,lane-count = <4>;
> + samsung,dynamic-range = <0>;
> + samsung,ycbcr-coeff = <0>;
> +
> + ports {
> + port {
> + dp_out: endpoint {
> + remote-endpoint = <&panel>;
> + };
> + };
> + };
> +};
> +
> &ehci {
> status = "disabled";
> };
>
> +&fimd {
> + status = "okay";
> +
> + assigned-clocks = <&clock CLK_MOUT_FIMD1>, <&clock CLK_MOUT_VPLL>;
> + assigned-clock-parents = <&clock CLK_MOUT_VPLL>;
> +};
> +
> &i2c_1 {
> status = "okay";
>
> @@ -396,6 +467,12 @@ ldo25_reg: LDO25 {
> };
> };
>
> +&mali {
> + status = "okay";
> +
> + mali-supply = <&buck4_reg>;
> +};
> +
> &mixer {
> status = "okay";
> };
> @@ -489,6 +566,14 @@ wlan_irq: wlan-irq-pins {
> };
>
> &pinctrl_1 {
> + aps_en_18v: aps-en-18v-pins {
> + samsung,pins = "gph1-6";
> + samsung,pin-function = <EXYNOS_PIN_FUNC_OUTPUT>; /* TODO */
> + samsung,pin-con-pdn = <EXYNOS_PIN_PDN_INPUT>; /* TODO */
> + samsung,pin-pud-pdn = <EXYNOS_PIN_PULL_UP>; /* TODO */
> + samsung,pin-val = <0>; /* TODO */
> + };
> +
> bh1721fvc_reset: bh1721fvc-reset-pins {
> samsung,pins = "gph1-2";
> samsung,pin-function = <EXYNOS_PIN_FUNC_OUTPUT>;
> @@ -509,6 +594,20 @@ bt_wake: bt-wake-pins {
> samsung,pin-pud-pdn = <EXYNOS_PIN_PULL_NONE>;
> };
>
> + lcd_en: lcd-en-pins {
> + samsung,pins = "gph1-7";
> + samsung,pin-function = <EXYNOS_PIN_FUNC_OUTPUT>; /* TODO */
> + samsung,pin-val = <0>;
> + };
> +
> + led_bl_reset: led-bl-rst-pins {
> + samsung,pins = "gpg0-5";
> + samsung,pin-function = <EXYNOS_PIN_FUNC_OUTPUT>; /* TODO */
> + samsung,pin-con-pdn = <EXYNOS_PIN_PDN_PREV>; /* TODO */
> + samsung,pin-pud-pdn = <EXYNOS_PIN_PULL_NONE>; /* TODO */
> + samsung,pin-val = <0>; /* TODO */
> + };
> +
> msense_reset: msense-reset-pins {
> samsung,pins = "gpg2-0";
> samsung,pin-function = <EXYNOS_PIN_FUNC_OUTPUT>;
>
> --
> 2.53.0
>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v8 3/6] drm/bridge: simple: Add the Lontium LT8711UXD DP-to-HDMI bridge
From: Laurent Pinchart @ 2026-04-25 11:28 UTC (permalink / raw)
To: Dennis Gilmore
Cc: Heiko Stuebner, Andrzej Hajda, Neil Armstrong, Robert Foss,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Jonas Karlman,
Jernej Skrabec, Maxime Ripard, Alexey Charkov, devicetree,
linux-rockchip, linux-arm-kernel, dri-devel, linux-kernel,
Dmitry Baryshkov
In-Reply-To: <20260425031011.2529364-4-dennis@ausil.us>
Hi Dennis,
Thank you for the patch.
On Fri, Apr 24, 2026 at 10:10:08PM -0500, Dennis Gilmore wrote:
> The Lontium LT8711UXD is a high performance two lane Type-C/DP1.4
> to HDMI2.0 converter, designed to connect a USB Type-C source or
> a DP1.4 source to an HDMI2.0 sink.
As far as I can tell, the LT8711UXD has an I2C control interface.
Shouldn't it be an I2C device ?
> Signed-off-by: Dennis Gilmore <dennis@ausil.us>
> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> ---
> drivers/gpu/drm/bridge/simple-bridge.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/bridge/simple-bridge.c b/drivers/gpu/drm/bridge/simple-bridge.c
> index 8aa31ca3c72d..42c1f3d5ba0c 100644
> --- a/drivers/gpu/drm/bridge/simple-bridge.c
> +++ b/drivers/gpu/drm/bridge/simple-bridge.c
> @@ -270,6 +270,11 @@ static const struct of_device_id simple_bridge_match[] = {
> .data = &(const struct simple_bridge_info) {
> .connector_type = DRM_MODE_CONNECTOR_HDMIA,
> },
> + }, {
> + .compatible = "lontium,lt8711uxd",
> + .data = &(const struct simple_bridge_info) {
> + .connector_type = DRM_MODE_CONNECTOR_HDMIA,
> + },
> }, {
> .compatible = "parade,ps185hdm",
> .data = &(const struct simple_bridge_info) {
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH v2] raid6: arm64: add SVE optimized implementation for syndrome generation
From: Demian Shulhan @ 2026-04-25 11:46 UTC (permalink / raw)
To: Mark Brown
Cc: Ard Biesheuvel, Robin Murphy, Christoph Hellwig, Mark Rutland,
Song Liu, Yu Kuai, Will Deacon, Catalin Marinas, linux-arm-kernel,
Li Nan, linux-raid, linux-kernel
In-Reply-To: <2c2eb793-c0a4-4b65-93f1-0ece5cf820d7@sirena.org.uk>
Hi all!
In the future I will try to look at optimisation of current algorithms
instead of SVE realisation, looks like there are few interesting
cases, I will share details in future changes.
Thanks all for the discussion!
пт, 17 квіт. 2026 р. о 18:36 Mark Brown <broonie@kernel.org> пише:
>
> On Fri, Apr 17, 2026 at 04:43:06PM +0200, Ard Biesheuvel wrote:
>
> > On arm64, kernel mode NEON is mostly used to gain access to AES and SHA
> > instructions, and only to a lesser degree to speed up ordinary
> > arithmetic, and so XOR is somewhat of an outlier here.
>
> > Given that Neoverse V1 apparently already carves up ordinary arithmetic
> > performed on 256-bit vectors and operates on 128 bits at a time, I am
> > rather skeptical that we're likely to see any SVE implementations of the
> > crypto extensions soon that are meaningfully faster, given that these
> > are presumably much costlier to implement in terms of gate count, and
> > therefore likely to be split up even on SVE implementations that can
> > perform ordinary arithmetic on 256+ bit vectors in a single cycle. Note
> > that even the arm64 SIMD accelerated CRC implementations rely heavily on
> > 64x64->128 polynomial multiplication.
>
> I'd not be surprised to see something that delivers useful benefits
> using SVE at some point.
>
> > IOW, before we consider kernel mode SVE, I'd like to see some benchmarks
> > for other algorithms too.
>
> Definitely, it needs a solid win to merge anything. I do want to get
> back to the situation where we've got out of tree infrastructure patches
> so that people working on algorithms have something to base their work
> on (and see the overheads using SVE incurs) but unless theres's a
> practical user they should stay out of tree.
^ permalink raw reply
* [PATCH] net: stmmac: fix RX DMA leak on TX alloc failure
From: Abid Ali via B4 Relay @ 2026-04-25 12:38 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Maxime Coquelin, Alexandre Torgue
Cc: netdev, linux-stm32, linux-arm-kernel, linux-kernel, Abid Ali
From: Abid Ali <dev.taqnialabs@gmail.com>
Free RX DMA resources when alloc_dma_tx_desc_resources() fails in
alloc_dma_desc_resources().
Signed-off-by: Abid Ali <dev.taqnialabs@gmail.com>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 13d3cac05..8bb843b55 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -2370,8 +2370,12 @@ static int alloc_dma_desc_resources(struct stmmac_priv *priv,
return ret;
ret = alloc_dma_tx_desc_resources(priv, dma_conf);
+ if (ret) {
+ free_dma_rx_desc_resources(priv, dma_conf);
+ return ret;
+ }
- return ret;
+ return 0;
}
/**
---
base-commit: 028ef9c96e96197026887c0f092424679298aae8
change-id: 20260425-stmmac-rx-desc-cleanup-440f05845492
Best regards,
--
Abid Ali <dev.taqnialabs@gmail.com>
^ permalink raw reply related
* Re: [PATCH v3 0/3] crypto: atmel-sha204a - multiple RNG fixes
From: Lothar Rubusch @ 2026-04-25 13:34 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Herbert Xu, Thorsten Blum, davem, nicolas.ferre,
alexandre.belloni, claudiu.beznea, Linus Walleij, linux-crypto,
linux-arm-kernel, linux-kernel
In-Reply-To: <a82278e5-9b5e-4fb9-9e7a-800ef2898ec5@app.fastmail.com>
Hi Ard and ML!
On Thu, Apr 23, 2026 at 11:25 AM Ard Biesheuvel <ardb@kernel.org> wrote:
>
> Hi Lothar,
>
> On Wed, 22 Apr 2026, at 23:09, Lothar Rubusch wrote:
> > When testing the RNG functionality on the Atmel SHA204a hardware, I
> > found the following issues: rngtest reported failures and hexdump
> > reveiled only the first 8 bytes out of 32 provided actually entropy.
> >
> > Having a closer look into it, I found a (small) memory leak, missing
> > to free work_data, miss-reading of the count field into the entropy
> > fields and parts of the 32 random bytes staying 0 due to reading the
> > slow i2c device.
> >
> > The series proposes fixes and how fixed functionality can be/was
> > verified. Executing rngtest afterward showed a decent result, due
> > to the i2c bus a bit slow.
> >
> > All setups require selecting the Atmel-sha204a as active RNG.
> > $ cat /sys/class/misc/hw_random/rng_available
> > 3f104000.rng 1-0064 none
> >
> > $ echo 1-0064 > /sys/class/misc/hw_random/rng_current
> >
> > $ cat /sys/class/misc/hw_random/rng_current
> > 1-0064
> >
> > Testing RNG properties currently shows problematic results:
> > $ rngtest < /dev/hwrng
> > rngtest 2.6
> > Copyright (c) 2004 by Henrique de Moraes Holschuh
> > This is free software; see the source for copying conditions. There is NO
> > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> >
> > rngtest: starting FIPS tests...
> > rngtest: bits received from input: 1040032
> > rngtest: FIPS 140-2 successes: 0
> > rngtest: FIPS 140-2 failures: 52
> > rngtest: FIPS 140-2(2001-10-10) Monobit: 52
> > rngtest: FIPS 140-2(2001-10-10) Poker: 52
> > rngtest: FIPS 140-2(2001-10-10) Runs: 52
> > rngtest: FIPS 140-2(2001-10-10) Long run: 52
> > rngtest: FIPS 140-2(2001-10-10) Continuous run: 52
> > rngtest: input channel speed: (min=7.631; avg=7.804; max=7.827)Kibits/s
> > rngtest: FIPS tests speed: (min=32.273; avg=32.701; max=33.056)Mibits/s
> > rngtest: Program run time: 130177956 microseconds
> >
> > Signed-off-by: Lothar Rubusch <l.rubusch@gmail.com>
> > ---
> > v2 -> v3: Removal blank line, rebased
> > v1 -> v2: Removal of C++ style comment (I saw it too late, sry for that)
> > ---
> > Lothar Rubusch (3):
> > crypto: atmel-sha204a - fix memory leak at non-blocking RNG work_data
> > crypto: atmel-sha204a - fix truncated 32-byte blocking read
> > crypto: atmel-sha204a - fix non-blocking read logic
> >
> > drivers/crypto/atmel-sha204a.c | 60 ++++++++++++++++++++++------------
> > 1 file changed, 39 insertions(+), 21 deletions(-)
> >
>
> Thanks for the report and the fixes. However, I'm not sure you are entirely
> on the right track here. I managed to fix the rngtest issues that you report by
> making the changes below. As I already replied, I think it would be better to
> propose this as a standalone patch, and backport it to stable.
>
Thank you so much for taking the time and answering, I really appreciate!
Like two months ago I started playing a bit more with these Atmel i2c
devices. Actually I wanted to prepare something
different (and still pretend doing so). Figuring out things here, I
noticed this RNG feature did not work as I expected.
Around that time I prepared this patch set.
Probably, I was a bit too euphoric - I mean, it's a bit unlikely the
driver was upstreamed and never really worked.
I have to admit, I did not go thoroughly through the git history
first, since the driver does not do significantly more than
RNG, there must have happened a degradation. I'll keep this in mind:
first to build up better understanding of the driver
history. than to start digging into the code. Anyway, I wanted to get
some feedback.
> The remaining changes are somewhat debatable IMO: the leak is not really a leak,
> so I'd like to understand better what you are fixing here. The command field
> changes seems completely misguided (unless I am missing something)
>
So, firstly in the current RNG implementation I definitely see an
issue. If that's ok, I'll to prepare a patch to re-init probably
rather
to what you proposed, since it makes more sense to me now. Thank you
for pointing this out.
Secondly, I noticed the device is picky about its i2c communication
timings. Yes, definitely. Nowadays, after having worked with
it a bit more, I'd rather say generally reducing response time is
probably not the solution. I still think I see some timing issue,
which
I wanted to better address in an upcoming patch set (but probably not
related to this RNG thing). Currently the AtSHA204a and
the AtECC508a (and related families) are sharing the same Atmel i2c
driver. This core driver uses hardcoded max timings for
its i2c command operations. Going over the datasheets of both chips,
both have totally different max timings.
Currently just having RNG for AtSHA204a and ECDH and related for AtECC
- it probably doesn't matter too much. Anyway, also
read and write command timings differ and mix up then in the Atmel i2c
core driver. I guess, this was kind of a starting point for
me to dig deeper. So, I probably will drop that i2c timing change from
this RNG fix set.
Thirdly, the "leak" I think is probably rather a theoretic issue. I'll
sepearate it out, think over it, and in case prepare something,
let me then know what you think.
>
>
> --- a/drivers/crypto/atmel-sha204a.c
> +++ b/drivers/crypto/atmel-sha204a.c
> @@ -47,8 +47,8 @@
>
> if (rng->priv) {
> work_data = (struct atmel_i2c_work_data *)rng->priv;
> - max = min(sizeof(work_data->cmd.data), max);
> - memcpy(data, &work_data->cmd.data, max);
> + max = min(RANDOM_RSP_SIZE - CMD_OVERHEAD_SIZE, max);
> + memcpy(data, &work_data->cmd.data[1], max);
> rng->priv = 0;
> } else {
> work_data = kmalloc_obj(*work_data, GFP_ATOMIC);
> @@ -86,8 +86,8 @@
> if (ret)
> return ret;
>
> - max = min(sizeof(cmd.data), max);
> - memcpy(data, cmd.data, max);
> + max = min(RANDOM_RSP_SIZE - CMD_OVERHEAD_SIZE, max);
> + memcpy(data, &cmd.data[1], max);
>
> return max;
> }
^ 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