drm/panel: novatek-nt35560: avoid on-stack device structure

From: Arnd Bergmann <[email protected]>

A cleanup patch apparently by accident used a local device structure instead of a pointer to one in the nt35560_read_id() function, causing a warning about stack usage:

drivers/gpu/drm/panel/panel-novatek-nt35560.c: In function 'nt35560_read_id':
drivers/gpu/drm/panel/panel-novatek-nt35560.c:249:1: error: the frame size of 1296 bytes is larger than 1280 bytes [-Werror=frame-larger-than=]

Change this to a pointer as was liley intended here.

---
 drivers/gpu/drm/panel/panel-novatek-nt35560.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

index 561e6643dcbb..6e5173f98a22 100644
@@ -213,7 +213,7 @@ static const struct backlight_properties nt35560_bl_props = {
 
 static void nt35560_read_id(struct mipi_dsi_multi_context *dsi_ctx)
 {
-	struct device dev = dsi_ctx->dsi->dev;
+	struct device *dev = &dsi_ctx->dsi->dev;
 	u8 vendor, version, panel;
 	u16 val;
 

@@ -225,7 +225,7 @@ static void nt35560_read_id(struct mipi_dsi_multi_context *dsi_ctx)
 		return;
 
 	if (vendor == 0x00) {
-		dev_err(&dev, "device vendor ID is zero\n");
+		dev_err(dev, "device vendor ID is zero\n");
 		dsi_ctx->accum_err = -ENODEV;
 		return;
 	}

@@ -236,12 +236,12 @@ static void nt35560_read_id(struct mipi_dsi_multi_context *dsi_ctx)
 	case DISPLAY_SONY_ACX424AKP_ID2:
 	case DISPLAY_SONY_ACX424AKP_ID3:
 	case DISPLAY_SONY_ACX424AKP_ID4:
-		dev_info(&dev,
+		dev_info(dev,
 			 "MTP vendor: %02x, version: %02x, panel: %02x\n",
 			 vendor, version, panel);
 		break;
 	default:
-		dev_info(&dev,
+		dev_info(dev,
 			 "unknown vendor: %02x, version: %02x, panel: %02x\n",
 			 vendor, version, panel);
 		break;

2.39.5

Hi,

Whoops! Not sure how I missed that in code review. Thanks for the fix!

Pushed to drm-misc-fixes:

[1/1] drm/panel: novatek-nt35560: avoid on-stack device structure

      commit: 1a7a7b80a22448dff55e1ad69a4681fd8b760b85

Shoot, you're absolutely right that I didn't mean to create a copy of the struct on the stack when I wrote that code. Thanks for the fix! I'll try to be more careful with struct usage and the stack in the future.

Can I ask how you got the build process to emit those warnings? I didn't see it when I developed my patch.

Thanks again,
Brigham

I'm doing randconfig tests to check a large number of possible configurations. I also have the CONFIG_FRAME_WARN logic replaced with lower configuration specific default to catch more regressions in this particular area.

Arnd