Lindent formatting issues

Lindent formatting issues

[Laszlo Papp]

Hi,

./scripts/Lindent seems to be working OK, but there are a few minor
issues like this:

static struct i2c_driver max6651_driver = {
        .driver = {
-               .name = "gpio-max6651",
-               .owner = THIS_MODULE,
-       },
+                  .name = "gpio-max6651",
+                  .owner = THIS_MODULE,
+                  },

Is there an option or something to mkae it work automatically? I am
referring to the "}," line which should not have changed.

Cheers,
Laszlo

PS.: I know it is an "indent" related question, but I do not see an
option for available this, and the project seems to be umaintained.

Re: Lindent formatting issues

[Joe Perches]

On Tue, 2013-12-17 at 15:06 +0000, Laszlo Papp wrote:
> ./scripts/Lindent seems to be working OK, but there are a few minor
> issues like this:
> 
> static struct i2c_driver max6651_driver = {
>         .driver = {
> -               .name = "gpio-max6651",
> -               .owner = THIS_MODULE,
> -       },
> +                  .name = "gpio-max6651",
> +                  .owner = THIS_MODULE,
> +                  },
> 
> Is there an option or something to mkae it work automatically? I am
> referring to the "}," line which should not have changed.

Assuming that was a copy/paste translation of
tabs to spaces, the first form is more common
in kernel sources and Lindent isn't doing the
right thing here.

You could also use scripts/checkpatch.pl with
the --fix option.

./scripts/checkpatch.pl -f --fix <file>

with various --types=<TYPE,...> options.

Maybe use: https://lkml.org/lkml/2013/9/23/504

Re: Lindent formatting issues

[Laszlo Papp]

On Tue, Dec 17, 2013 at 8:05 PM, Joe Perches <joe@perches.com> wrote:
> On Tue, 2013-12-17 at 15:06 +0000, Laszlo Papp wrote:
>> ./scripts/Lindent seems to be working OK, but there are a few minor
>> issues like this:
>>
>> static struct i2c_driver max6651_driver = {
>>         .driver = {
>> -               .name = "gpio-max6651",
>> -               .owner = THIS_MODULE,
>> -       },
>> +                  .name = "gpio-max6651",
>> +                  .owner = THIS_MODULE,
>> +                  },
>>
>> Is there an option or something to mkae it work automatically? I am
>> referring to the "}," line which should not have changed.
>
> Assuming that was a copy/paste translation of
> tabs to spaces, the first form is more common
> in kernel sources and Lindent isn't doing the
> right thing here.
>
> You could also use scripts/checkpatch.pl with
> the --fix option.
>
> ./scripts/checkpatch.pl -f --fix <file>
>
> with various --types=<TYPE,...> options.
>
> Maybe use: https://lkml.org/lkml/2013/9/23/504

Thanks Joe. I seem to have further issues with this tool... I tried to
run it on a file I patched, but it generated a lot of noise unrelated
to my logical change... :(

Do you happen to know what the best way is to fix it in such cases? I
am providing some examples below:

        if (devattr == &sensor_dev_attr_fan1_max_alarm.dev_attr
-        || devattr == &sensor_dev_attr_fan1_min_alarm.dev_attr
-        || devattr == &sensor_dev_attr_fan1_fault.dev_attr
-        || devattr == &sensor_dev_attr_gpio1_alarm.dev_attr
-        || devattr == &sensor_dev_attr_gpio2_alarm.dev_attr) {
+           || devattr == &sensor_dev_attr_fan1_min_alarm.dev_attr
+           || devattr == &sensor_dev_attr_fan1_fault.dev_attr
+           || devattr == &sensor_dev_attr_gpio1_alarm.dev_attr
+           || devattr == &sensor_dev_attr_gpio2_alarm.dev_attr) {

....


-                                   int n)
+                                    int n)

....

-       int sysfs_modes[4] = {0, 1, 2, 1};
+       int sysfs_modes[4] = { 0, 1, 2, 1 };

etc.

Re: Lindent formatting issues

[Joe Perches]

On Thu, 2013-12-19 at 16:17 +0000, Laszlo Papp wrote:
> On Tue, Dec 17, 2013 at 8:05 PM, Joe Perches <joe@perches.com> wrote:
[]
> > You could also use scripts/checkpatch.pl with
> > the --fix option.
> >
> > ./scripts/checkpatch.pl -f --fix <file>
> >
> > with various --types=<TYPE,...> options.
> >
> > Maybe use: https://lkml.org/lkml/2013/9/23/504
> 
> Thanks Joe. I seem to have further issues with this tool... I tried to
> run it on a file I patched, but it generated a lot of noise unrelated
> to my logical change... :(

checkpatch is really for patches.  Using -f is a
convenience ability.  You can limit what messages
checkpatch emits by using "--types=<FOO[,BAR...]>"

You can show what message classifications are being
used by adding "--show-types".

> Do you happen to know what the best way is to fix it in such cases? I
> am providing some examples below:
> 
>         if (devattr == &sensor_dev_attr_fan1_max_alarm.dev_attr
> -        || devattr == &sensor_dev_attr_fan1_min_alarm.dev_attr
> -        || devattr == &sensor_dev_attr_fan1_fault.dev_attr
> -        || devattr == &sensor_dev_attr_gpio1_alarm.dev_attr
> -        || devattr == &sensor_dev_attr_gpio2_alarm.dev_attr) {
> +           || devattr == &sensor_dev_attr_fan1_min_alarm.dev_attr
> +           || devattr == &sensor_dev_attr_fan1_fault.dev_attr
> +           || devattr == &sensor_dev_attr_gpio1_alarm.dev_attr
> +           || devattr == &sensor_dev_attr_gpio2_alarm.dev_attr) {

Well, here the general kernel style is to put
the logical && or || test at the end of the
previous line so:

	if (devattr == &sensor_dev_attr_fan1_max_alarm.dev_attr ||
	    devattr == &sensor_dev_attr_fan1_min_alarm.dev_attr ||
	    devattr == &sensor_dev_attr_fan1_fault.dev_attr ||
	    devattr == &sensor_dev_attr_gpio1_alarm.dev_attr ||
	    devattr == &sensor_dev_attr_gpio2_alarm.dev_attr) {

would likely be preferred.

> -                                   int n)
> +                                    int n)

This may be indentation alignment but I don't follow
how this is a problem.

> -       int sysfs_modes[4] = {0, 1, 2, 1};
> +       int sysfs_modes[4] = { 0, 1, 2, 1 };

Is this change from Lindent or checkpatch?

Re: Lindent formatting issues

[Laszlo Papp]

On Thu, Dec 19, 2013 at 4:32 PM, Joe Perches <joe@perches.com> wrote:
> On Thu, 2013-12-19 at 16:17 +0000, Laszlo Papp wrote:
>> On Tue, Dec 17, 2013 at 8:05 PM, Joe Perches <joe@perches.com> wrote:
> []
>> > You could also use scripts/checkpatch.pl with
>> > the --fix option.
>> >
>> > ./scripts/checkpatch.pl -f --fix <file>
>> >
>> > with various --types=<TYPE,...> options.
>> >
>> > Maybe use: https://lkml.org/lkml/2013/9/23/504
>>
>> Thanks Joe. I seem to have further issues with this tool... I tried to
>> run it on a file I patched, but it generated a lot of noise unrelated
>> to my logical change... :(
>
> checkpatch is really for patches.  Using -f is a
> convenience ability.  You can limit what messages
> checkpatch emits by using "--types=<FOO[,BAR...]>"
>
> You can show what message classifications are being
> used by adding "--show-types".
>
>> Do you happen to know what the best way is to fix it in such cases? I
>> am providing some examples below:
>>
>>         if (devattr == &sensor_dev_attr_fan1_max_alarm.dev_attr
>> -        || devattr == &sensor_dev_attr_fan1_min_alarm.dev_attr
>> -        || devattr == &sensor_dev_attr_fan1_fault.dev_attr
>> -        || devattr == &sensor_dev_attr_gpio1_alarm.dev_attr
>> -        || devattr == &sensor_dev_attr_gpio2_alarm.dev_attr) {
>> +           || devattr == &sensor_dev_attr_fan1_min_alarm.dev_attr
>> +           || devattr == &sensor_dev_attr_fan1_fault.dev_attr
>> +           || devattr == &sensor_dev_attr_gpio1_alarm.dev_attr
>> +           || devattr == &sensor_dev_attr_gpio2_alarm.dev_attr) {
>
> Well, here the general kernel style is to put
> the logical && or || test at the end of the
> previous line so:
>
>         if (devattr == &sensor_dev_attr_fan1_max_alarm.dev_attr ||
>             devattr == &sensor_dev_attr_fan1_min_alarm.dev_attr ||
>             devattr == &sensor_dev_attr_fan1_fault.dev_attr ||
>             devattr == &sensor_dev_attr_gpio1_alarm.dev_attr ||
>             devattr == &sensor_dev_attr_gpio2_alarm.dev_attr) {
>
> would likely be preferred.
>
>> -                                   int n)
>> +                                    int n)
>
> This may be indentation alignment but I don't follow
> how this is a problem.

It is a problem because it is a noise for a logical change that is not
about whitespace fixup. The kernel maintainer would probably
rightfully reject it with such a line in.

>
>> -       int sysfs_modes[4] = {0, 1, 2, 1};
>> +       int sysfs_modes[4] = { 0, 1, 2, 1 };
>
> Is this change from Lindent or checkpatch?

I have used Lindent when these lines were generated. Here is some more:

-               data->dac = 180 - (180 * pwm)/255;
+               data->dac = 180 - (180 * pwm) / 255;
        else
-               data->dac = 76 - (76 * pwm)/255;
+               data->dac = 76 - (76 * pwm) / 255;

...

-       .probe          = max6650_probe,
-       .remove         = max6650_remove,
-       .id_table       = max6650_id,
+       .probe          = max6650_probe,
+       .remove = max6650_remove,
+       .id_table = max6650_id,

...

-                        const char *buf, size_t count)
+                         const char *buf, size_t count)

Re: Lindent formatting issues

[Joe Perches]

On Thu, 2013-12-19 at 17:30 +0000, Laszlo Papp wrote:
> On Thu, Dec 19, 2013 at 4:32 PM, Joe Perches <joe@perches.com> wrote:

> > Is this change from Lindent or checkpatch?
> 
> I have used Lindent when these lines were generated. Here is some more:

I am not a Lindent / indent maintainer.

My suggestion remains not to use Lindent.

I _have_ suggested that Lindent be removed from the kernel.

http://lkml.org/lkml/2013/2/11/390

Re: Lindent formatting issues

[Laszlo Papp]

On Thu, Dec 19, 2013 at 5:34 PM, Joe Perches <joe@perches.com> wrote:
> On Thu, 2013-12-19 at 17:30 +0000, Laszlo Papp wrote:
>> On Thu, Dec 19, 2013 at 4:32 PM, Joe Perches <joe@perches.com> wrote:
>
>> > Is this change from Lindent or checkpatch?
>>
>> I have used Lindent when these lines were generated. Here is some more:
>
> I am not a Lindent / indent maintainer.
>
> My suggestion remains not to use Lindent.
>
> I _have_ suggested that Lindent be removed from the kernel.
>
> http://lkml.org/lkml/2013/2/11/390

I see. It was quite a while ago. You could post a follow-up? ;-)