linux-kernel - Re: [PATCH] RS485: fix inconsistencies in the meaning of some variables

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: <4EC0F75D.4060102@atmel.com>
Date:	Mon, 14 Nov 2011 12:11:25 +0100
From:	Nicolas Ferre <nicolas.ferre@...el.com>
To:	Darron Black <darron@...ffin.net>,
	Claudio Scordino <claudio@...dence.eu.com>
CC:	Wolfram Sang <w.sang@...gutronix.de>, Greg KH <greg@...ah.com>,
	Alan Cox <alan@...rguk.ukuu.org.uk>, alan@...ux.intel.com,
	linux-kernel@...r.kernel.org, linux-serial@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org,
	Jesper Nilsson <Jesper.Nilsson@...s.com>,
	Mikael Starvik <mikael.starvik@...s.com>
Subject: Re: [PATCH] RS485: fix inconsistencies in the meaning of some variables

On 11/14/2011 01:37 AM, Darron Black :
> On 11/13/2011 03:53 PM, Wolfram Sang wrote:
>> Hi,
>>
>> I have been working on a patch series which adds hardware RS485 to the
>> 8250
>> according to the latest developments. The series will be posted
>> tomorrow after
>> some more tests. However, there is one thing I wondered about:
>>
>>>  From now on, SER_RS485_RTS_AFTER_SEND and SER_RS485_RTS_ON_SEND will
>>> be used to
>>> set the voltage of the RTS pin (as in the crisv10.c driver); the
>>> delay will be
>>> understood by looking only at the value of delay_rts_before_send and
>>> delay_rts_after_send.
>> Do I overlook something or is SER_RS485_RTS_AFTER_SEND always the
>> inverted
>> signal of SER_RS485_RTS_ON_SEND. So why do we need both? (BTW
>> SER_RS485_RTS_ON_SEND is a non-obvious name, I think. But changing it
>> will
>> probably break even more users?)
> It allows the application to configure RTS to not toggle at all in one
> of those two scenarios.
> 
> Perhaps the RTS toggle after transmit delay needs to be large, and
> they'd rather do it in userspace than block in the driver. I also recall
> a protocol that would send a master assertion command and hold on to RTS
> afterwards. I can easily imagine needing to quickly transmit something,
> hold on to RTS for a while, then finish your transmit later.
> 
> However, I don't have any concrete examples of needing this outside that
> vague recollection of a master assertion sequence in an old embedded
> platform far away from Linux.

Darron, Claudio,

This explanation makes sense. Thanks for this.

Bye,


>>> diff --git a/include/linux/serial.h b/include/linux/serial.h
>>> index 97ff8e2..3d86517 100644
>>> --- a/include/linux/serial.h
>>> +++ b/include/linux/serial.h
>>> @@ -207,13 +207,15 @@ struct serial_icounter_struct {
>>>
>>>   struct serial_rs485 {
>>>       __u32    flags;            /* RS485 feature flags */
>>> -#define SER_RS485_ENABLED        (1<<  0)
>>> -#define SER_RS485_RTS_ON_SEND        (1<<  1)
>>> -#define SER_RS485_RTS_AFTER_SEND    (1<<  2)
>>> -#define SER_RS485_RTS_BEFORE_SEND    (1<<  3)
>>> +#define SER_RS485_ENABLED        (1<<  0)    /* If enabled */
>>> +#define SER_RS485_RTS_ON_SEND        (1<<  1)    /* Logical level for
>>> +                               RTS pin when
>>> +                               sending */
>>> +#define SER_RS485_RTS_AFTER_SEND    (1<<  2)    /* Logical level for
>>> +                               RTS pin after sent*/
>> Nit: 80 char should be broken here, because that is not readable. Or
>> put the
>> comment above the define.
>>
>> Thanks,
>>
>>     Wolfram
>>
> 
> 


-- 
Nicolas Ferre
--
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/