Re: [PATCH] staging: fbtft: fix alignment should match open parenthesis

[David Reaver]

Joe Perches  writes:

> On Sat, 2022-06-25 at 19:00 -0700, David Reaver wrote:
>> Fix alignment of this line of code with the previous parenthesis, as
>> suggested by checkpatch.pl:
> []
>> diff --git a/drivers/staging/fbtft/fb_tinylcd.c 
>> b/drivers/staging/fbtft/fb_tinylcd.c
> []
>> @@ -38,7 +38,7 @@ static int init_display(struct fbtft_par *par)
>>  write_reg(par, 0xE5, 0x00);
>>  write_reg(par, 0xF0, 0x36, 0xA5, 0x53);
>>  write_reg(par, 0xE0, 0x00, 0x35, 0x33, 0x00, 0x00, 0x00,
>> -   0x00, 0x35, 0x33, 0x00, 0x00, 0x00);
>> +  0x00, 0x35, 0x33, 0x00, 0x00, 0x00);
>
> It's probably better to ignore the message in this case as the first
> argument means something and the second and subsequent are the data
> being written via a specific macro using NUMARGS.

Thanks for taking a look Joe! That makes sense. I'm new to the kernel
and running checkpath.pl on staging drivers was suggested as a good
place to start contributing, but I'll keep a more careful eye out next
time and not follow checkpath blindly.

[PATCH] staging: fbtft: fix alignment should match open parenthesis

[David Reaver]

Fix alignment of this line of code with the previous parenthesis, as
suggested by checkpatch.pl:

  $ ./scripts/checkpatch.pl -f drivers/staging/fbtft/fb_tinylcd.c
  CHECK: Alignment should match open parenthesis
  #41: FILE: drivers/staging/fbtft/fb_tinylcd.c:41:
  +   write_reg(par, 0xE0, 0x00, 0x35, 0x33, 0x00, 0x00, 0x00,
  +  0x00, 0x35, 0x33, 0x00, 0x00, 0x00);

Signed-off-by: David Reaver 
---
 drivers/staging/fbtft/fb_tinylcd.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/fbtft/fb_tinylcd.c 
b/drivers/staging/fbtft/fb_tinylcd.c
index 9469248f2c50..60cda57bcb33 100644
--- a/drivers/staging/fbtft/fb_tinylcd.c
+++ b/drivers/staging/fbtft/fb_tinylcd.c
@@ -38,7 +38,7 @@ static int init_display(struct fbtft_par *par)
write_reg(par, 0xE5, 0x00);
write_reg(par, 0xF0, 0x36, 0xA5, 0x53);
write_reg(par, 0xE0, 0x00, 0x35, 0x33, 0x00, 0x00, 0x00,
-  0x00, 0x35, 0x33, 0x00, 0x00, 0x00);
+ 0x00, 0x35, 0x33, 0x00, 0x00, 0x00);
write_reg(par, MIPI_DCS_SET_PIXEL_FORMAT, 0x55);
write_reg(par, MIPI_DCS_EXIT_SLEEP_MODE);
udelay(250);

[PATCH] dma-buf/sync_file: Fix missing colon in kernel-doc for num_fences

[David Reaver]

The struct sync_fence_info member num_fences was missing a colon in the
kernel-doc, causing this warning when running make htmldocs:

./include/uapi/linux/sync_file.h:77: warning: Function parameter or member 
'num_fences' not described in 'sync_file_info'

num_fences was also clearly missing from
https://docs.kernel.org/driver-api/dma-buf.html#c.sync_file_info before
this patch.

Signed-off-by: David Reaver 
---
 include/uapi/linux/sync_file.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/uapi/linux/sync_file.h b/include/uapi/linux/sync_file.h
index 7e42a5b7558b..b389a5495181 100644
--- a/include/uapi/linux/sync_file.h
+++ b/include/uapi/linux/sync_file.h
@@ -56,7 +56,7 @@ struct sync_fence_info {
  * @name:  name of fence
  * @status:status of fence. 1: signaled 0:active <0:error
  * @flags: sync_file_info flags
- * @num_fences number of fences in the sync_file
+ * @num_fences: number of fences in the sync_file
  * @pad:   padding for 64-bit alignment, should always be zero
  * @sync_fence_info: pointer to array of struct &sync_fence_info with all
  *  fences in the sync_file

[PATCH] drm/i915/huc: fix intel_huc.c doc bulleted list format error

[David Reaver]

Fix the following make htmldocs errors/warnings:

./drivers/gpu/drm/i915/gt/uc/intel_huc.c:29: ERROR: Unexpected indentation.
./drivers/gpu/drm/i915/gt/uc/intel_huc.c:30: WARNING: Block quote ends without 
a blank line; unexpected unindent.
./drivers/gpu/drm/i915/gt/uc/intel_huc.c:35: WARNING: Bullet list ends without 
a blank line; unexpected unindent.

This output is a bit misleading. The real issue here is we need a blank
line before and after the bulleted list.

Link: https://www.kernel.org/doc/html/latest/gpu/i915.html#huc
Link: 
https://lore.kernel.org/dri-devel/20230530152958.1384061-1-daniele.ceraolospu...@intel.com/

Signed-off-by: David Reaver 
---
 drivers/gpu/drm/i915/gt/uc/intel_huc.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_huc.c 
b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
index ddd146265beb..fa70defcb5b2 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
@@ -26,6 +26,7 @@
  * The kernel driver is only responsible for loading the HuC firmware and
  * triggering its security authentication. This is done differently depending
  * on the platform:
+ *
  * - older platforms (from Gen9 to most Gen12s): the load is performed via DMA
  *   and the authentication via GuC
  * - DG2: load and authentication are both performed via GSC.
@@ -33,6 +34,7 @@
  *   not-DG2 older platforms), while the authentication is done in 2-steps,
  *   a first auth for clear-media workloads via GuC and a second one for all
  *   workloads via GSC.
+ *
  * On platforms where the GuC does the authentication, to correctly do so the
  * HuC binary must be loaded before the GuC one.
  * Loading the HuC is optional; however, not using the HuC might negatively