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] [day] [month] [year] [list]
Message-ID: <d6dedcc9-b4f0-4de4-9d26-ec9c0c9fa4f6@bootlin.com>
Date: Thu, 22 Aug 2024 16:06:11 +0200
From: Richard GENOUD <richard.genoud@...tlin.com>
To: Mathieu Othacehe <othacehe@....org>,
 Richard Genoud <richard.genoud@...tlin.com>,
 Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
 Jiri Slaby <jirislaby@...nel.org>,
 Nicolas Ferre <nicolas.ferre@...rochip.com>,
 Alexandre Belloni <alexandre.belloni@...tlin.com>,
 Claudiu Beznea <claudiu.beznea@...on.dev>, linux-kernel@...r.kernel.org,
 linux-serial@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
 Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>
Subject: Re: [PATCH] tty: atmel_serial: use the correct RTS flag.



Le 13/08/2024 à 09:59, Alexander Dahl a écrit :
> Hello Mathieu,
> 
> Am Thu, Aug 08, 2024 at 08:06:37AM +0200 schrieb Mathieu Othacehe:
>> In RS485 mode, the RTS pin is driven high by hardware when the transmitter
>> is operating. This behaviour cannot be changed. This means that the driver
>> should claim that it supports SER_RS485_RTS_ON_SEND and not
>> SER_RS485_RTS_AFTER_SEND.
>>
>> Otherwise, when configuring the port with the SER_RS485_RTS_ON_SEND, one
>> get the following warning:
>>
>> kern.warning kernel: atmel_usart_serial atmel_usart_serial.2.auto:
>> ttyS1 (1): invalid RTS setting, using RTS_AFTER_SEND instead
> 
> I've seen this warning already, when migrating a sam9x60 based board
> from LTS kernel 6.1 to 6.6, so thanks for taking care of this.
> 
> I can confirm after applying the patch on top of 6.6.44 the warning is
> gone, and RS-485 communication still works on our platform, so …
> 
> Tested-by: Alexander Dahl <ada@...rsis.com>

Acked-by: Richard Genoud <richard.genoud@...tlin.com>

> 
> Does this deserve a Fixes tag for the change which introduced struct
> serial_rs485 to the atmel serial driver?  Then it should be this:
> 
> Fixes: af47c491e3c7 ("serial: atmel: Fill in rs485_supported")
> 
> Greets
> Alex
> 
>> which is contradictory with what's really happening.
>>
>> Signed-off-by: Mathieu Othacehe <othacehe@....org>
>> ---
>>   drivers/tty/serial/atmel_serial.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/tty/serial/atmel_serial.c b/drivers/tty/serial/atmel_serial.c
>> index 0a90964d6d107..09b246c9e389e 100644
>> --- a/drivers/tty/serial/atmel_serial.c
>> +++ b/drivers/tty/serial/atmel_serial.c
>> @@ -2514,7 +2514,7 @@ static const struct uart_ops atmel_pops = {
>>   };
>>   
>>   static const struct serial_rs485 atmel_rs485_supported = {
>> -	.flags = SER_RS485_ENABLED | SER_RS485_RTS_AFTER_SEND | SER_RS485_RX_DURING_TX,
>> +	.flags = SER_RS485_ENABLED | SER_RS485_RTS_ON_SEND | SER_RS485_RX_DURING_TX,
>>   	.delay_rts_before_send = 1,
>>   	.delay_rts_after_send = 1,
>>   };
>> -- 
>> 2.45.2
>>
>>
> 

Thanks !

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ