Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <b0627883-d764-e951-ead8-f5a047ce66e3@foss.st.com>
Date:   Wed, 5 Jul 2023 18:02:01 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Subject: Re: [PATCH 6/7] rtc: stm32: fix unnecessary parentheses
Content-Language: en-US
To:     Alexandre Belloni <alexandre.belloni@bootlin.com>
CC:     Alessandro Zummo <a.zummo@towertech.it>,
        Alexandre Torgue <alexandre.torgue@foss.st.com>,
        Antonio Borneo <antonio.borneo@foss.st.com>,
        Christophe Guibout <christophe.guibout@foss.st.com>,
        Gabriel Fernandez <gabriel.fernandez@foss.st.com>,
        <linux-rtc@vger.kernel.org>,
        <linux-stm32@st-md-mailman.stormreply.com>,
        <linux-arm-kernel@lists.infradead.org>,
        <linux-kernel@vger.kernel.org>
References: <20230615092753.323844-1-valentin.caron@foss.st.com>
 <20230615092753.323844-7-valentin.caron@foss.st.com>
 <202306252316063d08f43c@mail.local>
From:   Valentin CARON <valentin.caron@foss.st.com>
In-Reply-To: <202306252316063d08f43c@mail.local>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk


On 6/26/23 01:16, Alexandre Belloni wrote:
> Hello,
>
> On 15/06/2023 11:27:52+0200, Valentin Caron wrote:
>> Fix a few style issues reported by checkpatch.pl:
>> - Unnecessary parentheses
>> - Lines should not end with a '('
>>
>> Signed-off-by: Valentin Caron <valentin.caron@foss.st.com>
>> ---
>>   drivers/rtc/rtc-stm32.c | 29 ++++++++++++++---------------
>>   1 file changed, 14 insertions(+), 15 deletions(-)
>>
>> diff --git a/drivers/rtc/rtc-stm32.c b/drivers/rtc/rtc-stm32.c
>> index 17e549806784..30c5004d6902 100644
>> --- a/drivers/rtc/rtc-stm32.c
>> +++ b/drivers/rtc/rtc-stm32.c
>> @@ -160,10 +160,9 @@ static int stm32_rtc_enter_init_mode(struct stm32_rtc *rtc)
>>   		 * slowest rtc_ck frequency may be 32kHz and highest should be
>>   		 * 1MHz, we poll every 10 us with a timeout of 100ms.
>>   		 */
>> -		return readl_relaxed_poll_timeout_atomic(
>> -					rtc->base + regs->isr,
>> -					isr, (isr & STM32_RTC_ISR_INITF),
>> -					10, 100000);
>> +		return readl_relaxed_poll_timeout_atomic(rtc->base + regs->isr, isr,
>> +							 (isr & STM32_RTC_ISR_INITF),
>> +							 10, 100000);
>>   	}
>>   
>>   	return 0;
>> @@ -448,16 +447,16 @@ static int stm32_rtc_valid_alrm(struct stm32_rtc *rtc, struct rtc_time *tm)
>>   	 *	M-D-Y H:M:S < alarm <= (M+1)-D-Y H:M:S
>>   	 * with a specific case for December...
>>   	 */
>> -	if ((((tm->tm_year > cur_year) &&
>> -	      (tm->tm_mon == 0x1) && (cur_mon == 0x12)) ||
>> -	     ((tm->tm_year == cur_year) &&
>> -	      (tm->tm_mon <= cur_mon + 1))) &&
>> -	    ((tm->tm_mday > cur_day) ||
>> -	     ((tm->tm_mday == cur_day) &&
>> -	     ((tm->tm_hour > cur_hour) ||
>> -	      ((tm->tm_hour == cur_hour) && (tm->tm_min > cur_min)) ||
>> -	      ((tm->tm_hour == cur_hour) && (tm->tm_min == cur_min) &&
>> -	       (tm->tm_sec >= cur_sec))))))
>> +	if (((tm->tm_year > cur_year &&
>> +	      tm->tm_mon == 0x1 && cur_mon == 0x12) ||
>> +	     (tm->tm_year == cur_year &&
>> +	      tm->tm_mon <= cur_mon + 1)) &&
>> +	    (tm->tm_mday > cur_day ||
>> +	     (tm->tm_mday == cur_day &&
>> +	     (tm->tm_hour > cur_hour ||
>> +	      (tm->tm_hour == cur_hour && tm->tm_min > cur_min) ||
>> +	      (tm->tm_hour == cur_hour && tm->tm_min == cur_min &&
>> +	       tm->tm_sec >= cur_sec)))))
> This change is dropped in the following patch. I guess you can remove
> the unnecessary churn.

Yes absolutely ! Let's go for a v2.

Thanks,
Valentin

>
>>   		return 0;
>>   
>>   	return -EINVAL;
>> @@ -666,7 +665,7 @@ static int stm32_rtc_init(struct platform_device *pdev,
>>   	 * Can't find a 1Hz, so give priority to RTC power consumption
>>   	 * by choosing the higher possible value for prediv_a
>>   	 */
>> -	if ((pred_s > pred_s_max) || (pred_a > pred_a_max)) {
>> +	if (pred_s > pred_s_max || pred_a > pred_a_max) {
>>   		pred_a = pred_a_max;
>>   		pred_s = (rate / (pred_a + 1)) - 1;
>>   
>> -- 
>> 2.25.1
>>