All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wolfram Sang <w.sang@pengutronix.de>
To: Claudio Scordino <claudio@evidence.eu.com>
Cc: Greg KH <greg@kroah.com>, Alan Cox <alan@lxorguk.ukuu.org.uk>,
	Nicolas Ferre <nicolas.ferre@atmel.com>,
	alan@linux.intel.com, linux-kernel@vger.kernel.org,
	linux-serial@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	Jesper Nilsson <Jesper.Nilsson@axis.com>,
	Mikael Starvik <mikael.starvik@axis.com>,
	Darron Black <darron@griffin.net>
Subject: Re: [PATCH] RS485: fix inconsistencies in the meaning of some variables
Date: Sun, 13 Nov 2011 22:53:18 +0100	[thread overview]
Message-ID: <20111113215318.GA2966@pengutronix.de> (raw)
In-Reply-To: <4EBA9385.7010806@evidence.eu.com>

[-- Attachment #1: Type: text/plain, Size: 1785 bytes --]

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?)

> 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

-- 
Pengutronix e.K.                           | Wolfram Sang                |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: w.sang@pengutronix.de (Wolfram Sang)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] RS485: fix inconsistencies in the meaning of some variables
Date: Sun, 13 Nov 2011 22:53:18 +0100	[thread overview]
Message-ID: <20111113215318.GA2966@pengutronix.de> (raw)
In-Reply-To: <4EBA9385.7010806@evidence.eu.com>

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?)

> 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

-- 
Pengutronix e.K.                           | Wolfram Sang                |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20111113/76fe5548/attachment.sig>

  reply	other threads:[~2011-11-13 21:53 UTC|newest]

Thread overview: 60+ 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-15 14:28 ` Bernhard Roth
2011-08-22 21:18 ` Greg KH
2011-08-22 21:18   ` Greg KH
2011-08-23  8:30   ` Claudio Scordino
2011-08-23  8:30     ` Claudio Scordino
2011-08-23  8:30     ` Claudio Scordino
2011-08-23  9:30     ` Russell King - ARM Linux
2011-08-23  9:30       ` Russell King - ARM Linux
2011-08-23  9:30       ` Russell King - ARM Linux
2011-08-23 10:06       ` Claudio Scordino
2011-08-23 10:06         ` Claudio Scordino
2011-08-23 10:14         ` Alan Cox
2011-08-23 10:14           ` Alan Cox
2011-08-23 10:21           ` Russell King - ARM Linux
2011-08-23 10:21             ` Russell King - ARM Linux
2011-08-23 10:21             ` Russell King - ARM Linux
2011-08-23 15:39     ` Greg KH
2011-08-23 15:39       ` Greg KH
2011-08-23 15:39       ` Greg KH
2011-08-24  7:48       ` Claudio Scordino
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  8:19     ` Claudio Scordino
2011-11-04 10:36     ` Jesper Nilsson
2011-11-04 10:36       ` Jesper Nilsson
2011-11-04 10:36       ` Jesper Nilsson
2011-11-08  9:30     ` Nicolas Ferre
2011-11-08  9:30       ` Nicolas Ferre
2011-11-08  9:59       ` Jean-Christophe PLAGNIOL-VILLARD
2011-11-08  9:59         ` Jean-Christophe PLAGNIOL-VILLARD
2011-11-08  9:59         ` Jean-Christophe PLAGNIOL-VILLARD
2011-11-08 10:48       ` Claudio Scordino
2011-11-08 10:48         ` Claudio Scordino
2011-11-08 13:48         ` Alan Cox
2011-11-08 13:48           ` Alan Cox
2011-11-08 14:24           ` Greg KH
2011-11-08 14:24             ` Greg KH
2011-11-09 14:51             ` Claudio Scordino
2011-11-09 14:51               ` Claudio Scordino
2011-11-13 21:53               ` Wolfram Sang [this message]
2011-11-13 21:53                 ` Wolfram Sang
2011-11-14  0:37                 ` Darron Black
2011-11-14  0:37                   ` Darron Black
2011-11-14  0:37                   ` Darron Black
2011-11-14 11:11                   ` Nicolas Ferre
2011-11-14 11:11                     ` Nicolas Ferre
2011-11-14 12:07                   ` Alan Cox
2011-11-14 12:07                     ` Alan Cox
2011-11-14  8:22                 ` Claudio Scordino
2011-11-14  8:22                   ` Claudio Scordino
2011-11-14 12:18               ` Nicolas Ferre
2011-11-14 12:18                 ` Nicolas Ferre
2011-11-08 15:02         ` Nicolas Ferre
2011-11-08 15:02           ` Nicolas Ferre
2011-11-08 15:45           ` Claudio Scordino
2011-11-08 15:45             ` Claudio Scordino
2011-11-08 16:34             ` Jesper Nilsson
2011-11-08 16:34               ` Jesper Nilsson
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=20111113215318.GA2966@pengutronix.de \
    --to=w.sang@pengutronix.de \
    --cc=Jesper.Nilsson@axis.com \
    --cc=alan@linux.intel.com \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=claudio@evidence.eu.com \
    --cc=darron@griffin.net \
    --cc=greg@kroah.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-serial@vger.kernel.org \
    --cc=mikael.starvik@axis.com \
    --cc=nicolas.ferre@atmel.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.