linux-kernel - Re: [PATCH 2/2] leds: rgb: leds-qcom-lpg: Fix line wrapping style issues

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: <mummt6hl5c4iih6dvc5qcg6uijkluareqmjbxcfyfyzvhadpcd@oswmwaecv5ic>
Date: Fri, 7 Jun 2024 13:56:48 -0500
From: Bjorn Andersson <andersson@...nel.org>
To: Anjelique Melendez <quic_amelende@...cinc.com>
Cc: pavel@....cz, lee@...nel.org, robh@...nel.org, 
	u.kleine-koenig@...gutronix.de, marijn.suijten@...ainline.org, kees@...nel.org, 
	morf3089@...il.com, quic_gurus@...cinc.com, quic_subbaram@...cinc.com, 
	linux-arm-msm@...r.kernel.org, linux-leds@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] leds: rgb: leds-qcom-lpg: Fix line wrapping style
 issues

On Thu, Jun 06, 2024 at 05:52:52PM GMT, Anjelique Melendez wrote:
> Fix line wrapping style issues introduced in previous patches.

Bending the line length guidelines is okay when it results in easier to
read code. I find the existing code easier to read...

Regards,
Bjorn

> 
> Signed-off-by: Anjelique Melendez <quic_amelende@...cinc.com>
> ---
>  drivers/leds/rgb/leds-qcom-lpg.c | 19 +++++++++++++------
>  1 file changed, 13 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/leds/rgb/leds-qcom-lpg.c b/drivers/leds/rgb/leds-qcom-lpg.c
> index e74b2ceed1c2..7c35b3ba09a3 100644
> --- a/drivers/leds/rgb/leds-qcom-lpg.c
> +++ b/drivers/leds/rgb/leds-qcom-lpg.c
> @@ -620,6 +620,7 @@ static void lpg_sdam_apply_lut_control(struct lpg_channel *chan)
>  	u8 val = 0, conf = 0, lut_offset = 0;
>  	unsigned int hi_pause, lo_pause;
>  	struct lpg *lpg = chan->lpg;
> +	u16 addr;
>  
>  	if (!chan->ramp_enabled || chan->pattern_lo_idx == chan->pattern_hi_idx)
>  		return;
> @@ -640,17 +641,23 @@ static void lpg_sdam_apply_lut_control(struct lpg_channel *chan)
>  		lo_idx += lut_offset;
>  	}
>  
> -	nvmem_device_write(lpg_chan_sdam, SDAM_PBS_SCRATCH_LUT_COUNTER_OFFSET + chan->sdam_offset, 1, &val);
> -	nvmem_device_write(lpg_chan_sdam, SDAM_PATTERN_CONFIG_OFFSET + chan->sdam_offset, 1, &conf);
> -	nvmem_device_write(lpg_chan_sdam, SDAM_END_INDEX_OFFSET + chan->sdam_offset, 1, &hi_idx);
> -	nvmem_device_write(lpg_chan_sdam, SDAM_START_INDEX_OFFSET + chan->sdam_offset, 1, &lo_idx);
> +	addr = SDAM_PBS_SCRATCH_LUT_COUNTER_OFFSET + chan->sdam_offset;
> +	nvmem_device_write(lpg_chan_sdam, addr, 1, &val);
> +	addr = SDAM_PATTERN_CONFIG_OFFSET + chan->sdam_offset;
> +	nvmem_device_write(lpg_chan_sdam, addr, 1, &conf);
> +	addr = SDAM_END_INDEX_OFFSET + chan->sdam_offset;
> +	nvmem_device_write(lpg_chan_sdam, addr, 1, &hi_idx);
> +	addr = SDAM_START_INDEX_OFFSET + chan->sdam_offset;
> +	nvmem_device_write(lpg_chan_sdam, addr, 1, &lo_idx);
>  
>  	val = RAMP_STEP_DURATION(chan->ramp_tick_ms);
>  	nvmem_device_write(lpg_chan_sdam, SDAM_REG_RAMP_STEP_DURATION, 1, &val);
>  
>  	if (lpg->lut_sdam) {
> -		nvmem_device_write(lpg_chan_sdam, SDAM_PAUSE_HI_MULTIPLIER_OFFSET + chan->sdam_offset, 1, &hi_pause);
> -		nvmem_device_write(lpg_chan_sdam, SDAM_PAUSE_LO_MULTIPLIER_OFFSET + chan->sdam_offset, 1, &lo_pause);
> +		addr = SDAM_PAUSE_HI_MULTIPLIER_OFFSET + chan->sdam_offset;
> +		nvmem_device_write(lpg_chan_sdam, addr, 1, &hi_pause);
> +		addr = SDAM_PAUSE_LO_MULTIPLIER_OFFSET + chan->sdam_offset;
> +		nvmem_device_write(lpg_chan_sdam, addr, 1, &lo_pause);
>  	}
>  
>  }
> -- 
> 2.34.1
>