Replace sizeof(struct bb_priv) with sizeof(*board->private_data)
to follow kernel coding style and improve maintainability.

checkpatch.pl also reports that LINVAL macro should be enclosed
in parentheses. However, LINVAL intentionally expands to a
comma-separated list of arguments matching the LINFMT format
string used in dbg_printk() calls.

Wrapping it in parentheses would change semantics due to the
comma operator, causing only the last expression to be passed.

Therefore, no change is made to LINVAL.

Signed-off-by: Ajanth Badiger <badigerajanth1301@gmail.com>
---
 drivers/staging/gpib/gpio/gpib_bitbang.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/gpib/gpio/gpib_bitbang.c b/drivers/staging/gpib/gpio/gpib_bitbang.c
index 374cd61355e9..2fff9ec9a01c 100644
--- a/drivers/staging/gpib/gpio/gpib_bitbang.c
+++ b/drivers/staging/gpib/gpio/gpib_bitbang.c
@@ -1066,7 +1066,7 @@ static int bb_line_status(const struct gpib_board *board)
 
 static int allocate_private(struct gpib_board *board)
 {
-	board->private_data = kzalloc(sizeof(struct bb_priv), GFP_KERNEL);
+	board->private_data = kzalloc(sizeof(*board->private_data), GFP_KERNEL);
 	if (!board->private_data)
 		return -1;
 	return 0;
-- 
2.43.0

On Sun, May 03, 2026 at 03:05:58PM +0530, Ajanth Badiger wrote:
> Replace sizeof(struct bb_priv) with sizeof(*board->private_data)
> to follow kernel coding style and improve maintainability.
> 
> checkpatch.pl also reports that LINVAL macro should be enclosed
> in parentheses. However, LINVAL intentionally expands to a
> comma-separated list of arguments matching the LINFMT format
> string used in dbg_printk() calls.
> 
> Wrapping it in parentheses would change semantics due to the
> comma operator, causing only the last expression to be passed.
> 
> Therefore, no change is made to LINVAL.
> 
> Signed-off-by: Ajanth Badiger <badigerajanth1301@gmail.com>
> ---
>  drivers/staging/gpib/gpio/gpib_bitbang.c | 2 +-

This file is not in the tree, what version did you make this against?
Please always use linux-next for development work.

thanks,

greg k-h