Sent from my iPhone
> On 16 Nov 2024, at 05:40, Dan Carpenter <dan.carpenter@xxxxxxxxxx> wrote:
>
> On Sat, Nov 16, 2024 at 11:06:55AM +0100, Christophe Leroy wrote:
>>> diff --git a/arch/powerpc/platforms/pseries/papr_scm.c b/arch/powerpc/platforms/pseries/papr_scm.c
>>> index 9e297f88adc5d97d4dc7b267b0bfebd58e5cf193..9e8086ec66e0f0e555ac27933854c06cfcf91a04 100644
>>> --- a/arch/powerpc/platforms/pseries/papr_scm.c
>>> +++ b/arch/powerpc/platforms/pseries/papr_scm.c
>>> @@ -543,7 +543,7 @@ static int drc_pmem_query_health(struct papr_scm_priv *p)
>>>
>>> /* Jiffies offset for which the health data is assumed to be same */
>>> cache_timeout = p->lasthealth_jiffies +
>>> - msecs_to_jiffies(MIN_HEALTH_QUERY_INTERVAL * 1000);
>>> + secs_to_jiffies(MIN_HEALTH_QUERY_INTERVAL);
>>
>> Wouldn't it now fit on a single line ?
>>
>
> Some maintainers still prefer to put a line break at 80 characters.
Coccinelle tries for 80 chars. It may have a command line option to specify something else.
Julia
> It's kind
> of a nightmare for an automated script like this to figure out everyone's
> preferences. In this particular
> file, there are some lines which go over 80
> characters so sure. Earlier in the patchset one of these introduced a line
> break that wasn't there before so I think maybe Coccinelle is applying the 80
> character line break rule?
>
> There are sometimes where the 80 character rule really hurts readability, but
> here it doesn't make any difference.
>
> regards,
> dan carpenter
>
[Index of Archives]
[Pulseaudio]
[Linux Audio Users]
[ALSA Devel]
[Fedora Desktop]
[Fedora SELinux]
[Big List of Linux Books]
[Yosemite News]
[KDE Users]