Add comments to spinlock and mutex fields explaining what they protect, as required by kernel coding style for lock definitions.
Signed-off-by: Noah Techoueyres noahtechoueyres@gmail.com --- drivers/staging/greybus/uart.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/greybus/uart.c b/drivers/staging/greybus/uart.c index 7d060b4cd33d..46f38428c5cc 100644 --- a/drivers/staging/greybus/uart.c +++ b/drivers/staging/greybus/uart.c @@ -50,12 +50,12 @@ struct gb_tty { unsigned int minor; unsigned char clocal; bool disconnected; - spinlock_t read_lock; - spinlock_t write_lock; + spinlock_t read_lock; /* Protects read operations */ + spinlock_t write_lock; /* Protects write operations */ struct async_icount iocount; struct async_icount oldcount; wait_queue_head_t wioctl; - struct mutex mutex; + struct mutex mutex; /* Protects port configuration */ u8 ctrlin; /* input control lines */ u8 ctrlout; /* output control lines */ struct gb_uart_set_line_coding_request line_coding;
On Sun, Aug 02, 2026 at 10:18:57PM -0400, Noah Techoueyres wrote:
Add comments to spinlock and mutex fields explaining what they protect, as required by kernel coding style for lock definitions.
Signed-off-by: Noah Techoueyres noahtechoueyres@gmail.com
To be honest, I don't love this checkpatch warning. It seems like a really easy task but it's actually difficult so it tricks people into sending patches that they shouldn't.
We really want a proper analysis of the locking and not a three word guess. What I *really* want is for people to check for bugs as they are doing this analysis. If you can't find the bugs then this task is too difficult at this stage.
regards, dan carpenter