Match next line with open parentheses by adding tabs/spaces
to conform with Linux kernel coding style.
Reported by checkpatch.
Signed-off-by: Zhansaya Bagdauletkyzy <[email protected]>
---
drivers/staging/greybus/camera.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/greybus/camera.c b/drivers/staging/greybus/camera.c
index cdbb42cd413b..5dca585694c0 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;
@@ -378,8 +378,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 +783,8 @@ 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;
--
2.25.1
On Tue, Apr 06, 2021 at 06:42:59PM +0600, Zhansaya Bagdauletkyzy wrote:
> Match next line with open parentheses by adding tabs/spaces
> to conform with Linux kernel coding style.
> Reported by checkpatch.
>
> Signed-off-by: Zhansaya Bagdauletkyzy <[email protected]>
> ---
> drivers/staging/greybus/camera.c | 10 +++++-----
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/staging/greybus/camera.c b/drivers/staging/greybus/camera.c
> index cdbb42cd413b..5dca585694c0 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;
> @@ -378,8 +378,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)
And now you violate another coding style requirement, which means
someone will send another patch to fix that up and around and around it
goes...
Sorry, not going to take this.
greg k-h
On Tue, 2021-04-06 at 15:27 +0200, Greg KH wrote:
> On Tue, Apr 06, 2021 at 06:42:59PM +0600, Zhansaya Bagdauletkyzy wrote:
> > Match next line with open parentheses by adding tabs/spaces
> > to conform with Linux kernel coding style.
> > Reported by checkpatch.
[]
> > diff --git a/drivers/staging/greybus/camera.c b/drivers/staging/greybus/camera.c
[]
> > @@ -378,8 +378,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)
>
> And now you violate another coding style requirement, which means
> someone will send another patch to fix that up and around and around it
> goes...
None of the coding style document is an actual requirement Greg.
It's all rules of thumb. Useful rules, but not hard and fast right?
To me, the biggest issue with this code isn't whether or not the
code is aligned at open parentheses or stays within 80 columns,
but is the use of 30+ character length identifiers.
Using identifiers of that length makes using 80 column, or even
100 column length lines infeasible.
Perhaps seeing if include/linux/greybus/greybus_protocols.h
could be updated to use shorter length identifiers might be useful.
The median length identifier there is ~25 chars long and the
maximum length identifier is ~50 chars.
On Wed, 2021-04-14 at 08:17 -0500, Alex Elder wrote:
> Perhaps (like the -W options for GCC) there
> could be a way to specify in a Makefile which checkpatch
> messages are reported/not reported? I don't claim that's
> a good suggestion, but if I could optionally indicate
> somewhere that "two consecutive blank lines is OK for
> Greybus" (one example that comes to mind) I might do so.
checkpatch already has --ignore=<list> and --types=<list>
for the various classes of messages it emits.
see: $ ./scripts/checkpatch.pl --list-types --verbose
Dwaipayan Ray (cc'd) is supposedly working on expanding
the verbose descriptions of each type.
On 4/14/21 9:29 AM, Joe Perches wrote:
> On Wed, 2021-04-14 at 08:17 -0500, Alex Elder wrote:
>> Perhaps (like the -W options for GCC) there
>> could be a way to specify in a Makefile which checkpatch
>> messages are reported/not reported? I don't claim that's
>> a good suggestion, but if I could optionally indicate
>> somewhere that "two consecutive blank lines is OK for
>> Greybus" (one example that comes to mind) I might do so.
>
> checkpatch already has --ignore=<list> and --types=<list>
> for the various classes of messages it emits.
>
> see: $ ./scripts/checkpatch.pl --list-types --verbose
>
> Dwaipayan Ray (cc'd) is supposedly working on expanding
> the verbose descriptions of each type.
>
That's awesome, I wasn't aware of that.
Any suggestions on a standardized way to say "in this
subtree, please provide these arguments to checkpatch.pl"?
I can probably stick it in a README file or something,
but is there an existing best practice?
Thanks.
-Alex
On 4/6/21 12:21 PM, Joe Perches wrote:
> On Tue, 2021-04-06 at 15:27 +0200, Greg KH wrote:
>> On Tue, Apr 06, 2021 at 06:42:59PM +0600, Zhansaya Bagdauletkyzy wrote:
>>> Match next line with open parentheses by adding tabs/spaces
>>> to conform with Linux kernel coding style.
>>> Reported by checkpatch.
> []
>>> diff --git a/drivers/staging/greybus/camera.c b/drivers/staging/greybus/camera.c
> []
>>> @@ -378,8 +378,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)
>>
>> And now you violate another coding style requirement, which means
>> someone will send another patch to fix that up and around and around it
>> goes...
>
> None of the coding style document is an actual requirement Greg.
> It's all rules of thumb. Useful rules, but not hard and fast right?
I agree with this, but this ambiguity causes some problems.
Greybus is a go-to place for just-starting developers to
work with some reasonably good "real" code. But someone
just starting has no way of judging whether the warnings
issued by checkpatch are real or not. Even experienced
developers will lack the insight to judge this if they
are modifying on a less-familiar part of the kernel.
The result--for Greybus certainly--is fairly regular
stream patches that suggest making trivial changes based
on checkpatch recommendations. And unfortunately each
one is destined to be rejected by the maintainers. This
is no good for anybody.
Can you think of a way to try to further characterize
how "serious" a warning message is? I recognize that
even if (for example) you had something like 1-10 severity
scale, the scale might not be uniform across the whole
kernel tree. Perhaps (like the -W options for GCC) there
could be a way to specify in a Makefile which checkpatch
messages are reported/not reported? I don't claim that's
a good suggestion, but if I could optionally indicate
somewhere that "two consecutive blank lines is OK for
Greybus" (one example that comes to mind) I might do so.
> To me, the biggest issue with this code isn't whether or not the
> code is aligned at open parentheses or stays within 80 columns,
> but is the use of 30+ character length identifiers.
I agree with you on this one... I've worked with code
like that and it's very difficult to make it readable.
I've made a mental note to go look at this and see if
I can make it better. I can't say when I'll get to it
but I think it's a good suggestion.
-Alex
> Using identifiers of that length makes using 80 column, or even
> 100 column length lines infeasible.
>
> Perhaps seeing if include/linux/greybus/greybus_protocols.h
> could be updated to use shorter length identifiers might be useful.
>
> The median length identifier there is ~25 chars long and the
> maximum length identifier is ~50 chars.
>
>
>
On Wed, 2021-04-14 at 09:35 -0500, Alex Elder wrote:
> On 4/14/21 9:29 AM, Joe Perches wrote:
> > On Wed, 2021-04-14 at 08:17 -0500, Alex Elder wrote:
> > > Perhaps (like the -W options for GCC) there
> > > could be a way to specify in a Makefile which checkpatch
> > > messages are reported/not reported? I don't claim that's
> > > a good suggestion, but if I could optionally indicate
> > > somewhere that "two consecutive blank lines is OK for
> > > Greybus" (one example that comes to mind) I might do so.
> >
> > checkpatch already has --ignore=<list> and --types=<list>
> > for the various classes of messages it emits.
> >
> > see: $ ./scripts/checkpatch.pl --list-types --verbose
> >
> > Dwaipayan Ray (cc'd) is supposedly working on expanding
> > the verbose descriptions of each type.
> >
>
> That's awesome, I wasn't aware of that.
>
> Any suggestions on a standardized way to say "in this
> subtree, please provide these arguments to checkpatch.pl"?
>
> I can probably stick it in a README file or something,
> but is there an existing best practice?
There is no standardized mechanism for this checkpatch use.
Putting something in a staging README is in general a good way for
it to _not_ be read by people doing 'my first kernel patch'.
I still think emitting a message for overly long identifiers could
be a decent checkpatch test.
https://lore.kernel.org/lkml/[email protected]/