[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