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: <CAJs94Eb=ioh4fFiU41LfaN1jhq8fWwDA9-cV=pvpOcVC65vdFw@mail.gmail.com>
Date:	Tue, 17 Nov 2015 13:25:36 +0300
From:	"Matwey V. Kornilov" <matwey@....msu.ru>
To:	Uwe Kleine-König 
	<u.kleine-koenig@...gutronix.de>
Cc:	Greg KH <gregkh@...uxfoundation.org>, jslaby@...e.com,
	Peter Hurley <peter@...leysoftware.com>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	linux-serial@...r.kernel.org
Subject: Re: [PATCH v3 5/5] tty: Add software emulated RS485 support for 8250

2015-11-17 12:24 GMT+03:00 Uwe Kleine-König <u.kleine-koenig@...gutronix.de>:
> Hello,
>
> On Thu, Nov 12, 2015 at 05:33:56PM +0300, Matwey V. Kornilov wrote:
>> +static void serial8250_start_tx(struct uart_port *port)
>> +{
>> +     struct uart_8250_port *up = up_to_u8250p(port);
>> +     __u32 delay;
>> +
>> +     serial8250_rpm_get_tx(up);
>> +
>> +     if (timer_pending(&up->rs485_start_tx_timer))
>> +             return;
>
> I think this is wrong (or at least suboptimal). The .start_tx callback
> can be called even if transmission is already ongoing. In this case you
> don't want to restart the rs485_start_tx_timer.

If I understand you correctly, this maybe suboptimal but not wrong.
Calling .start_tx during transmission will lead to call
serial8250_rs485_start_tx which will return 0 because RTS is already
in proper state, and then __start_tx will be called immediately. Just
as it happens now.

>
>> +     if ((delay = serial8250_rs485_start_tx(up))) {
>> +             mod_timer(&up->rs485_start_tx_timer, jiffies + delay * HZ / 1000);
>> +     } else {
>> +             __start_tx(port);
>> +     }
>> +}
>> +
>> [...]
>> diff --git a/include/linux/serial_8250.h b/include/linux/serial_8250.h
>> index faa0e03..c4905e7 100644
>> --- a/include/linux/serial_8250.h
>> +++ b/include/linux/serial_8250.h
>> @@ -86,6 +86,8 @@ struct uart_8250_ops {
>>  struct uart_8250_port {
>>       struct uart_port        port;
>>       struct timer_list       timer;          /* "no irq" timer */
>> +     struct timer_list       rs485_start_tx_timer; /* "rs485 start tx" timer */
>> +     struct timer_list       rs485_stop_tx_timer; /* "rs485 stop tx" timer */
>
> Do you really need two timers here? At each point in time there should
> only be at most one of them active.

You are right, only one is active. Having two timers is implicit way
to store the state ('starting' or 'stopping'). I don't think that this
is the worst way.

>
> Best regards
> Uwe
>
> --
> Pengutronix e.K.                           | Uwe Kleine-König            |
> Industrial Linux Solutions                 | http://www.pengutronix.de/  |
>



-- 
With best regards,
Matwey V. Kornilov.
Sternberg Astronomical Institute, Lomonosov Moscow State University, Russia
119991, Moscow, Universitetsky pr-k 13, +7 (495) 9392382
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ