linux-kernel - Re: [PATCH v2 19/25] tty: serial: samsung

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: <31068a51-736b-08f6-6c00-1779734465ea@marcan.st>
Date:   Thu, 18 Feb 2021 22:53:10 +0900
From:   Hector Martin <marcan@...can.st>
To:     Krzysztof Kozlowski <krzk@...nel.org>
Cc:     linux-arm-kernel@...ts.infradead.org,
        Marc Zyngier <maz@...nel.org>, Rob Herring <robh@...nel.org>,
        Arnd Bergmann <arnd@...nel.org>,
        Olof Johansson <olof@...om.net>,
        Mark Kettenis <mark.kettenis@...all.nl>,
        Tony Lindgren <tony@...mide.com>,
        Mohamed Mediouni <mohamed.mediouni@...amail.com>,
        Stan Skowronek <stan@...ellium.com>,
        Alexander Graf <graf@...zon.com>,
        Will Deacon <will@...nel.org>,
        Linus Walleij <linus.walleij@...aro.org>,
        Mark Rutland <mark.rutland@....com>,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 19/25] tty: serial: samsung_tty: IRQ rework

On 16/02/2021 03.40, Krzysztof Kozlowski wrote:
> On Mon, Feb 15, 2021 at 09:17:07PM +0900, Hector Martin wrote:
>> * Split out s3c24xx_serial_tx_chars from s3c24xx_serial_tx_irq,
>>    where only the latter acquires the port lock.
> 
> I miss here information why you do all this.

Added an explanation for v3. This is used by a subsequent patch in the 
series.

>>
>> * For S3C64xx, return IRQ_NONE if no flag bits were set, so the
>>    interrupt core can detect IRQ storms. Note that both IRQ handlers
>>    always return IRQ_HANDLED anyway, so 'or' logic isn't necessary here,
>>    if either handler ran we are always going to return IRQ_HANDLED.
> 
> It looks like separate patch. Your patches should do only one thing at
> once. The fact that you have here three bullet points is a warning
> sign. This is even more important if you do some refactorings and
> cleanups which should not affect functionality. Hiding there changes
> which could affect functionality is a no-go.

I've reverted this one. I don't think it should affect functionality, 
but I don't have any way to test on these devices, so I'll leave it to 
someone else to be safe :)

>>
>> * Rename s3c24xx_serial_rx_chars to s3c24xx_serial_rx_irq for
>>    consistency with the above. All it does now is call two other
>>    functions anyway.
> 
> Separate patch for trivial renaming.

I think it makes sense to do this rename together with the first change 
above, as it keeps both functions symmetric. Otherwise we end up with an 
inconsistent function naming between both patches. If you really want it 
separate though, I can do that.

> 
>>
>> Signed-off-by: Hector Martin <marcan@...can.st>
>> ---
>>   drivers/tty/serial/samsung_tty.c | 41 +++++++++++++++++++-------------
>>   1 file changed, 24 insertions(+), 17 deletions(-)
>>
>> diff --git a/drivers/tty/serial/samsung_tty.c b/drivers/tty/serial/samsung_tty.c
>> index 21955be680a4..821cd0e4f870 100644
>> --- a/drivers/tty/serial/samsung_tty.c
>> +++ b/drivers/tty/serial/samsung_tty.c
>> @@ -151,6 +151,9 @@ struct s3c24xx_uart_port {
>>   #endif
>>   };
>>   
>> +static void s3c24xx_serial_start_next_tx(struct s3c24xx_uart_port *ourport);
>> +static void s3c24xx_serial_tx_chars(struct s3c24xx_uart_port *ourport);
>> +
>>   /* conversion functions */
>>   
>>   #define s3c24xx_dev_to_port(__dev) dev_get_drvdata(__dev)
>> @@ -316,8 +319,6 @@ static void s3c24xx_serial_stop_tx(struct uart_port *port)
>>   	ourport->tx_mode = 0;
>>   }
>>   
>> -static void s3c24xx_serial_start_next_tx(struct s3c24xx_uart_port *ourport);
>> -
> 
> Why moving this? Why adding s3c24xx_serial_tx_chars() forward
> declaration?

This should've gone in the next patch. A previous reviewer told me to 
put declarations at the top of the file, so I put it there and moved 
this one along with it, but I'll keep it to the additon only for v3.

-- 
Hector Martin (marcan@...can.st)
Public Key: https://mrcn.st/pub