lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e24e41be-b2c4-4bda-8a34-a628c55c4061@ieee.org>
Date:   Thu, 19 Oct 2023 19:15:37 -0500
From:   Alex Elder <elder@...e.org>
To:     Nandha Kumar Singaram <nandhakumar.singaram@...il.com>,
        Johan Hovold <johan@...nel.org>, Alex Elder <elder@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        greybus-dev@...ts.linaro.org, linux-staging@...ts.linux.dev,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] staging: greybus: Alignment should match open parenthesis

On 10/19/23 4:39 PM, Nandha Kumar Singaram wrote:
> Adhere to linux coding style. Reported by checkpatch.pl:
> CHECK: Alignment should match open parenthesis

Sometimes checkpatch.pl warns about things that are not
really that important.  One class of this type of issue
is white space errors.

Yes, consistency is good, but the kernel simply doesn't
have universally consistent conventions, and I doubt
it ever will.  There might be times where a source file
consistently follows a white space convention that
differs from what checkpatch wants.  Suggesting a
wholesale change to that file to "fix" that typically
wouldn't be welcome.

Unfortunately without some experience it's hard to know
which checkpatch warnings can be safely ignored.  I would
place white space warnings at a lower priority for fixing
than some others.  For example, this is also a pretty
trivial warning:
   CHECK: Macro argument 'gcam' may be better as '(gcam)' to avoid 
precedence issues
And it is most likely not a problem in this case, but fixing
this type of warning is probably more constructive than
just adjusting white space.

I have no objection to your patch, and it's a fine way to
get some experience with the patch process, but I don't
think this particular change is necessary.

					-Alex

> Signed-off-by: Nandha Kumar Singaram <nandhakumar.singaram@...il.com>
> ---
>   drivers/staging/greybus/camera.c | 14 +++++++-------
>   1 file changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/staging/greybus/camera.c b/drivers/staging/greybus/camera.c
> index cdbb42cd413b..405c8e78aa72 100644
> --- a/drivers/staging/greybus/camera.c
> +++ b/drivers/staging/greybus/camera.c
> @@ -220,7 +220,7 @@ static int gb_camera_operation_sync_flags(struct gb_connection *connection,
>   }
>   
>   static int gb_camera_get_max_pkt_size(struct gb_camera *gcam,
> -		struct gb_camera_configure_streams_response *resp)
> +				      struct gb_camera_configure_streams_response *resp)
>   {
>   	unsigned int max_pkt_size = 0;
>   	unsigned int i;
> @@ -267,8 +267,7 @@ static int gb_camera_get_max_pkt_size(struct gb_camera *gcam,
>    * Validate the stream configuration response verifying padding is correctly
>    * set and the returned number of streams is supported
>    */
> -static const int gb_camera_configure_streams_validate_response(
> -		struct gb_camera *gcam,
> +static const int gb_camera_configure_streams_validate_response(struct gb_camera *gcam,
>   		struct gb_camera_configure_streams_response *resp,
>   		unsigned int nstreams)
>   {
> @@ -378,8 +377,8 @@ struct ap_csi_config_request {
>   #define GB_CAMERA_CSI_CLK_FREQ_MARGIN		150000000U
>   
>   static int gb_camera_setup_data_connection(struct gb_camera *gcam,
> -		struct gb_camera_configure_streams_response *resp,
> -		struct gb_camera_csi_params *csi_params)
> +					   struct gb_camera_configure_streams_response *resp,
> +					   struct gb_camera_csi_params *csi_params)
>   {
>   	struct ap_csi_config_request csi_cfg;
>   	struct gb_connection *conn;
> @@ -783,8 +782,9 @@ static ssize_t gb_camera_op_capabilities(void *priv, char *data, size_t len)
>   }
>   
>   static int gb_camera_op_configure_streams(void *priv, unsigned int *nstreams,
> -		unsigned int *flags, struct gb_camera_stream *streams,
> -		struct gb_camera_csi_params *csi_params)
> +					  unsigned int *flags,
> +					  struct gb_camera_stream *streams,
> +					  struct gb_camera_csi_params *csi_params)
>   {
>   	struct gb_camera *gcam = priv;
>   	struct gb_camera_stream_config *gb_streams;

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ