From: darron@griffin.net (Darron Black)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] RS485: fix inconsistencies in the meaning of some variables
Date: Sun, 13 Nov 2011 18:37:11 -0600 [thread overview]
Message-ID: <4EC062B7.2090100@griffin.net> (raw)
In-Reply-To: <20111113215318.GA2966@pengutronix.de>
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.
>> 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
>
next prev parent reply other threads:[~2011-11-14 0:37 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-15 14:28 [PATCH] atmel_serial: RS485: receiving enabled when sending data Bernhard Roth
2011-08-22 21:18 ` Greg KH
2011-08-23 8:30 ` Claudio Scordino
2011-08-23 9:30 ` Russell King - ARM Linux
2011-08-23 10:06 ` Claudio Scordino
2011-08-23 10:14 ` Alan Cox
2011-08-23 10:21 ` Russell King - ARM Linux
2011-08-23 15:39 ` Greg KH
2011-08-24 7:48 ` Claudio Scordino
2011-11-04 8:19 ` [PATCH] RS485: fix inconsistencies in the meaning of some variables Claudio Scordino
2011-11-04 10:36 ` Jesper Nilsson
2011-11-08 9:30 ` Nicolas Ferre
2011-11-08 9:59 ` Jean-Christophe PLAGNIOL-VILLARD
2011-11-08 10:48 ` Claudio Scordino
2011-11-08 13:48 ` Alan Cox
2011-11-08 14:24 ` Greg KH
2011-11-09 14:51 ` Claudio Scordino
2011-11-13 21:53 ` Wolfram Sang
2011-11-14 0:37 ` Darron Black [this message]
2011-11-14 11:11 ` Nicolas Ferre
2011-11-14 12:07 ` Alan Cox
2011-11-14 8:22 ` Claudio Scordino
2011-11-14 12:18 ` Nicolas Ferre
2011-11-08 15:02 ` Nicolas Ferre
2011-11-08 15:45 ` Claudio Scordino
2011-11-08 16:34 ` Jesper Nilsson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4EC062B7.2090100@griffin.net \
--to=darron@griffin.net \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).