[PATCH] staging: fbtft: Use %pe format specifier for error pointers

[PATCH] staging: fbtft: Use %pe format specifier for error pointers

[Mahad Ibrahim]

The %pe format specifier resolves error pointers to their symbolic
representation. Previously %ld with PTR_ERR() was being used, %pe is a
better alternative.

Fixes the following coccinelle warnings reported by coccicheck:
WARNING: Consider using %pe to print PTR_ERR()

Testing: I do not own the hardware, therefore I could not perform
hardware testing. Compile tested only.

Signed-off-by: Mahad Ibrahim <mahad.ibrahim.dev@gmail.com>
---
 drivers/staging/fbtft/fb_ssd1351.c | 3 +--
 drivers/staging/fbtft/fbtft-core.c | 3 +--
 2 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/fbtft/fb_ssd1351.c b/drivers/staging/fbtft/fb_ssd1351.c
index 6736b09b2f45..15524b80035a 100644
--- a/drivers/staging/fbtft/fb_ssd1351.c
+++ b/drivers/staging/fbtft/fb_ssd1351.c
@@ -218,8 +218,7 @@ static void register_onboard_backlight(struct fbtft_par *par)
 				       &bl_props);
 	if (IS_ERR(bd)) {
 		dev_err(par->info->device,
-			"cannot register backlight device (%ld)\n",
-			PTR_ERR(bd));
+			"cannot register backlight device (%pe)\n", bd);
 		return;
 	}
 	par->info->bl_dev = bd;
diff --git a/drivers/staging/fbtft/fbtft-core.c b/drivers/staging/fbtft/fbtft-core.c
index f427c0914907..823315dfbf5d 100644
--- a/drivers/staging/fbtft/fbtft-core.c
+++ b/drivers/staging/fbtft/fbtft-core.c
@@ -187,8 +187,7 @@ void fbtft_register_backlight(struct fbtft_par *par)
 				       &fbtft_bl_ops, &bl_props);
 	if (IS_ERR(bd)) {
 		dev_err(par->info->device,
-			"cannot register backlight device (%ld)\n",
-			PTR_ERR(bd));
+			"cannot register backlight device (%pe)\n", bd);
 		return;
 	}
 	par->info->bl_dev = bd;
-- 
2.39.5

Re: [PATCH] staging: fbtft: Use %pe format specifier for error pointers

[Andy Shevchenko]

On Sun, Apr 12, 2026 at 5:46 PM Mahad Ibrahim
<mahad.ibrahim.dev@gmail.com> wrote:
>
> The %pe format specifier resolves error pointers to their symbolic
> representation. Previously %ld with PTR_ERR() was being used, %pe is a
> better alternative.
>
> Fixes the following coccinelle warnings reported by coccicheck:
> WARNING: Consider using %pe to print PTR_ERR()
>
> Testing: I do not own the hardware, therefore I could not perform
> hardware testing. Compile tested only.

I don't think it makes any difference for this driver. But I am not
objecting to the change. Up to Greg if he wants to apply or not.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH] staging: fbtft: Use %pe format specifier for error pointers

[Dan Carpenter]

On Mon, Apr 13, 2026 at 10:03:58AM +0300, Andy Shevchenko wrote:
> On Sun, Apr 12, 2026 at 5:46 PM Mahad Ibrahim
> <mahad.ibrahim.dev@gmail.com> wrote:
> >
> > The %pe format specifier resolves error pointers to their symbolic
> > representation. Previously %ld with PTR_ERR() was being used, %pe is a
> > better alternative.
> >
> > Fixes the following coccinelle warnings reported by coccicheck:
> > WARNING: Consider using %pe to print PTR_ERR()
> >
> > Testing: I do not own the hardware, therefore I could not perform
> > hardware testing. Compile tested only.
> 
> I don't think it makes any difference for this driver. But I am not
> objecting to the change. Up to Greg if he wants to apply or not.

I always like these changes.  I wish that there were an equivalent
%e which printed error codes that weren't stored in an error pointer.

KTODO: introduce a %e type format thing which prints error codes

regards,
dan carpenter

Re: [PATCH] staging: fbtft: Use %pe format specifier for error pointers

[Andy Shevchenko]

On Mon, Apr 13, 2026 at 10:49 AM Dan Carpenter <error27@gmail.com> wrote:
> On Mon, Apr 13, 2026 at 10:03:58AM +0300, Andy Shevchenko wrote:
> > On Sun, Apr 12, 2026 at 5:46 PM Mahad Ibrahim
> > <mahad.ibrahim.dev@gmail.com> wrote:

...

> I always like these changes.  I wish that there were an equivalent
> %e which printed error codes that weren't stored in an error pointer.
>
> KTODO: introduce a %e type format thing which prints error codes

Never happens until it becomes a C standard.


-- 
With Best Regards,
Andy Shevchenko

Claude review: staging: fbtft: Use %pe format specifier for error pointers

[Claude Code Review Bot]

Overall Series Review

Subject: staging: fbtft: Use %pe format specifier for error pointers
Author: Mahad Ibrahim <mahad.ibrahim.dev@gmail.com>
Patches: 4
Reviewed: 2026-04-13T19:00:42.245948

---

This is a single, straightforward cleanup patch that replaces `%ld` + `PTR_ERR()` with the `%pe` format specifier in two files under `drivers/staging/fbtft/`. The change is mechanically correct and addresses a well-known coccinelle warning. It is a low-risk, textbook cleanup appropriate for staging.

**Verdict: Looks good to me.** No functional or correctness concerns.

---
Generated by Claude Code Patch Reviewer

Claude review: staging: fbtft: Use %pe format specifier for error pointers

[Claude Code Review Bot]

Patch Review

**fb_ssd1351.c change:**
```c
-		"cannot register backlight device (%ld)\n",
-		PTR_ERR(bd));
+		"cannot register backlight device (%pe)\n", bd);
```

**fbtft-core.c change:**
```c
-		"cannot register backlight device (%ld)\n",
-		PTR_ERR(bd));
+		"cannot register backlight device (%pe)\n", bd);
```

Both hunks are correct. In each case `bd` has just been confirmed to be an error pointer via `IS_ERR(bd)`, so passing it directly with `%pe` is safe and will print the symbolic error name (e.g. `-ENOMEM`) instead of a raw number.

**Minor observations (not blocking):**

- The commit message is clear and well-structured. The "Testing" note about compile-only testing is appreciated and appropriate for a printf-format-only change in staging.
- The `Fixes:` tag is absent, which is fine — this is a cosmetic cleanup, not a bug fix, so no `Fixes:` tag is needed. However, the commit message says "Fixes the following coccinelle warnings" which could be slightly misleading since `Fixes:` has a specific meaning in the kernel. Consider rephrasing to "Addresses the following coccinelle warnings" or "Resolves the following coccinelle warning" to avoid any ambiguity, though this is a very minor nit.

**Reviewed-by worthy:** Yes. The patch is trivially correct.

---
Generated by Claude Code Patch Reviewer