All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nicolas Ferre <nicolas.ferre@atmel.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>,
	Josh Wu <josh.wu@atmel.com>, Bo Shen <voice.shen@atmel.com>,
	<linux-arm-kernel@lists.infradead.org>,
	<linux-serial@vger.kernel.org>,
	Ludovic Desroches <ludovic.desroches@atmel.com>,
	<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2/2] tty/serial: at91: add a fallback option to determine uart/usart property
Date: Thu, 17 Oct 2013 10:16:47 +0200	[thread overview]
Message-ID: <525F9CEF.9020904@atmel.com> (raw)
In-Reply-To: <20131016201451.GA21296@kroah.com>

On 16/10/2013 22:14, Greg Kroah-Hartman :
> On Tue, Oct 15, 2013 at 11:19:18AM +0200, Nicolas Ferre wrote:
>> On 14/10/2013 15:59, Jean-Christophe PLAGNIOL-VILLARD :
>>> On 10:43 Thu 10 Oct     , Nicolas Ferre wrote:
>>>> On older SoC, the "name" field is not filled in the register map.
>>>> Fix the way to figure out if the serial port is an uart or an usart for these
>>>> older products (with corresponding properties).
>>>>
>>>> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
>>>> ---
>>>>   drivers/tty/serial/atmel_serial.c | 19 ++++++++++++++++++-
>>>>   include/linux/atmel_serial.h      |  1 +
>>>>   2 files changed, 19 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/tty/serial/atmel_serial.c b/drivers/tty/serial/atmel_serial.c
>>>> index 6b0f75e..c7d99af 100644
>>>> --- a/drivers/tty/serial/atmel_serial.c
>>>> +++ b/drivers/tty/serial/atmel_serial.c
>>>> @@ -99,6 +99,7 @@ static void atmel_stop_rx(struct uart_port *port);
>>>>   #define UART_PUT_RTOR(port,v)	__raw_writel(v, (port)->membase + ATMEL_US_RTOR)
>>>>   #define UART_PUT_TTGR(port, v)	__raw_writel(v, (port)->membase + ATMEL_US_TTGR)
>>>>   #define UART_GET_IP_NAME(port)	__raw_readl((port)->membase + ATMEL_US_NAME)
>>>> +#define UART_GET_IP_VERSION(port) __raw_readl((port)->membase + ATMEL_US_VERSION)
>>>>
>>>>    /* PDC registers */
>>>>   #define UART_PUT_PTCR(port,v)	__raw_writel(v, (port)->membase + ATMEL_PDC_PTCR)
>>>> @@ -1503,6 +1504,7 @@ static void atmel_get_ip_name(struct uart_port *port)
>>>>   {
>>>>   	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
>>>>   	int name = UART_GET_IP_NAME(port);
>>>> +	u32 version;
>>>>   	int usart, uart;
>>>>   	/* usart and uart ascii */
>>>>   	usart = 0x55534152;
>>>> @@ -1517,7 +1519,22 @@ static void atmel_get_ip_name(struct uart_port *port)
>>>>   		dev_dbg(port->dev, "This is uart\n");
>>>>   		atmel_port->is_usart = false;
>>>>   	} else {
>>>> -		dev_err(port->dev, "Not supported ip name, set to uart\n");
>>>> +		/* fallback for older SoCs: use version field */
>>>> +		version = UART_GET_IP_VERSION(port);
>>>> +		switch (version) {
>>>> +		case 0x302:
>>>> +		case 0x10213:
>>>> +			dev_dbg(port->dev, "This version is usart\n");
>>>> +			atmel_port->is_usart = true;
>>>> +			break;
>>>> +		case 0x203:
>>>> +		case 0x10202:
>>>> +			dev_dbg(port->dev, "This version is uart\n");
>>>> +			atmel_port->is_usart = false;
>>>> +			break;
>>>> +		default:
>>>> +			dev_err(port->dev, "Not supported ip name nor version, set to uart\n");
>>>
>>> it's not really an error a dev_warn is more oppropriate
>>
>> As we are already in -rc5 and that these fixes are critical for at91
>> platforms, I will not re-spin another patch just for this.
>>
>> Moreover, I have the feeling that if we end up in this case, it
>> means that we are in big troubles because the usart/uart included in
>> the product triggering this log is not known (I recall that newer
>> products do not have to hit these lines of code).
>>
>> With these 2 reasons, I prefer to keep my patch like it is.
>>
>> Greg, can you consider taking these two patches as regression fixes
>> for 3.12 (with Tested-by tag from Thomas)?
>
> Is this really a regression from 3.11?

Yes it is. Commit id that I am referring to in patch 1/2 
(055560b04a8cd063aea916fd083b7aec02c2adb8) hit the mainline in 3.12-rc 
time-frame.

> What's the worry about waiting
> for 3.13-rc1, getting this correct, and then backporting them to the
> 3.12-stable trees?

It will break all older at91 in 3.12-final. Moreover, I do think that 
the actual patches are bringing an incorrect solution and I do not plan 
to have a better one (which one?) for 3.13...

> I'd prefer that, so, please clean this up properly and resend it, with
> the tested-by: lines and I'll queue them up for 3.13-rc1.

I do not know what to cleanup. Anyway, tell me if you want that I resend 
the series of 2 patches with the "Tested-by" tag included.

Bye,
-- 
Nicolas Ferre

WARNING: multiple messages have this Message-ID (diff)
From: Nicolas Ferre <nicolas.ferre@atmel.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>,
	Josh Wu <josh.wu@atmel.com>, Bo Shen <voice.shen@atmel.com>,
	linux-arm-kernel@lists.infradead.org,
	linux-serial@vger.kernel.org,
	Ludovic Desroches <ludovic.desroches@atmel.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] tty/serial: at91: add a fallback option to determine uart/usart property
Date: Thu, 17 Oct 2013 10:16:47 +0200	[thread overview]
Message-ID: <525F9CEF.9020904@atmel.com> (raw)
In-Reply-To: <20131016201451.GA21296@kroah.com>

On 16/10/2013 22:14, Greg Kroah-Hartman :
> On Tue, Oct 15, 2013 at 11:19:18AM +0200, Nicolas Ferre wrote:
>> On 14/10/2013 15:59, Jean-Christophe PLAGNIOL-VILLARD :
>>> On 10:43 Thu 10 Oct     , Nicolas Ferre wrote:
>>>> On older SoC, the "name" field is not filled in the register map.
>>>> Fix the way to figure out if the serial port is an uart or an usart for these
>>>> older products (with corresponding properties).
>>>>
>>>> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
>>>> ---
>>>>   drivers/tty/serial/atmel_serial.c | 19 ++++++++++++++++++-
>>>>   include/linux/atmel_serial.h      |  1 +
>>>>   2 files changed, 19 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/tty/serial/atmel_serial.c b/drivers/tty/serial/atmel_serial.c
>>>> index 6b0f75e..c7d99af 100644
>>>> --- a/drivers/tty/serial/atmel_serial.c
>>>> +++ b/drivers/tty/serial/atmel_serial.c
>>>> @@ -99,6 +99,7 @@ static void atmel_stop_rx(struct uart_port *port);
>>>>   #define UART_PUT_RTOR(port,v)	__raw_writel(v, (port)->membase + ATMEL_US_RTOR)
>>>>   #define UART_PUT_TTGR(port, v)	__raw_writel(v, (port)->membase + ATMEL_US_TTGR)
>>>>   #define UART_GET_IP_NAME(port)	__raw_readl((port)->membase + ATMEL_US_NAME)
>>>> +#define UART_GET_IP_VERSION(port) __raw_readl((port)->membase + ATMEL_US_VERSION)
>>>>
>>>>    /* PDC registers */
>>>>   #define UART_PUT_PTCR(port,v)	__raw_writel(v, (port)->membase + ATMEL_PDC_PTCR)
>>>> @@ -1503,6 +1504,7 @@ static void atmel_get_ip_name(struct uart_port *port)
>>>>   {
>>>>   	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
>>>>   	int name = UART_GET_IP_NAME(port);
>>>> +	u32 version;
>>>>   	int usart, uart;
>>>>   	/* usart and uart ascii */
>>>>   	usart = 0x55534152;
>>>> @@ -1517,7 +1519,22 @@ static void atmel_get_ip_name(struct uart_port *port)
>>>>   		dev_dbg(port->dev, "This is uart\n");
>>>>   		atmel_port->is_usart = false;
>>>>   	} else {
>>>> -		dev_err(port->dev, "Not supported ip name, set to uart\n");
>>>> +		/* fallback for older SoCs: use version field */
>>>> +		version = UART_GET_IP_VERSION(port);
>>>> +		switch (version) {
>>>> +		case 0x302:
>>>> +		case 0x10213:
>>>> +			dev_dbg(port->dev, "This version is usart\n");
>>>> +			atmel_port->is_usart = true;
>>>> +			break;
>>>> +		case 0x203:
>>>> +		case 0x10202:
>>>> +			dev_dbg(port->dev, "This version is uart\n");
>>>> +			atmel_port->is_usart = false;
>>>> +			break;
>>>> +		default:
>>>> +			dev_err(port->dev, "Not supported ip name nor version, set to uart\n");
>>>
>>> it's not really an error a dev_warn is more oppropriate
>>
>> As we are already in -rc5 and that these fixes are critical for at91
>> platforms, I will not re-spin another patch just for this.
>>
>> Moreover, I have the feeling that if we end up in this case, it
>> means that we are in big troubles because the usart/uart included in
>> the product triggering this log is not known (I recall that newer
>> products do not have to hit these lines of code).
>>
>> With these 2 reasons, I prefer to keep my patch like it is.
>>
>> Greg, can you consider taking these two patches as regression fixes
>> for 3.12 (with Tested-by tag from Thomas)?
>
> Is this really a regression from 3.11?

Yes it is. Commit id that I am referring to in patch 1/2 
(055560b04a8cd063aea916fd083b7aec02c2adb8) hit the mainline in 3.12-rc 
time-frame.

> What's the worry about waiting
> for 3.13-rc1, getting this correct, and then backporting them to the
> 3.12-stable trees?

It will break all older at91 in 3.12-final. Moreover, I do think that 
the actual patches are bringing an incorrect solution and I do not plan 
to have a better one (which one?) for 3.13...

> I'd prefer that, so, please clean this up properly and resend it, with
> the tested-by: lines and I'll queue them up for 3.13-rc1.

I do not know what to cleanup. Anyway, tell me if you want that I resend 
the series of 2 patches with the "Tested-by" tag included.

Bye,
-- 
Nicolas Ferre

WARNING: multiple messages have this Message-ID (diff)
From: nicolas.ferre@atmel.com (Nicolas Ferre)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/2] tty/serial: at91: add a fallback option to determine uart/usart property
Date: Thu, 17 Oct 2013 10:16:47 +0200	[thread overview]
Message-ID: <525F9CEF.9020904@atmel.com> (raw)
In-Reply-To: <20131016201451.GA21296@kroah.com>

On 16/10/2013 22:14, Greg Kroah-Hartman :
> On Tue, Oct 15, 2013 at 11:19:18AM +0200, Nicolas Ferre wrote:
>> On 14/10/2013 15:59, Jean-Christophe PLAGNIOL-VILLARD :
>>> On 10:43 Thu 10 Oct     , Nicolas Ferre wrote:
>>>> On older SoC, the "name" field is not filled in the register map.
>>>> Fix the way to figure out if the serial port is an uart or an usart for these
>>>> older products (with corresponding properties).
>>>>
>>>> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
>>>> ---
>>>>   drivers/tty/serial/atmel_serial.c | 19 ++++++++++++++++++-
>>>>   include/linux/atmel_serial.h      |  1 +
>>>>   2 files changed, 19 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/tty/serial/atmel_serial.c b/drivers/tty/serial/atmel_serial.c
>>>> index 6b0f75e..c7d99af 100644
>>>> --- a/drivers/tty/serial/atmel_serial.c
>>>> +++ b/drivers/tty/serial/atmel_serial.c
>>>> @@ -99,6 +99,7 @@ static void atmel_stop_rx(struct uart_port *port);
>>>>   #define UART_PUT_RTOR(port,v)	__raw_writel(v, (port)->membase + ATMEL_US_RTOR)
>>>>   #define UART_PUT_TTGR(port, v)	__raw_writel(v, (port)->membase + ATMEL_US_TTGR)
>>>>   #define UART_GET_IP_NAME(port)	__raw_readl((port)->membase + ATMEL_US_NAME)
>>>> +#define UART_GET_IP_VERSION(port) __raw_readl((port)->membase + ATMEL_US_VERSION)
>>>>
>>>>    /* PDC registers */
>>>>   #define UART_PUT_PTCR(port,v)	__raw_writel(v, (port)->membase + ATMEL_PDC_PTCR)
>>>> @@ -1503,6 +1504,7 @@ static void atmel_get_ip_name(struct uart_port *port)
>>>>   {
>>>>   	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
>>>>   	int name = UART_GET_IP_NAME(port);
>>>> +	u32 version;
>>>>   	int usart, uart;
>>>>   	/* usart and uart ascii */
>>>>   	usart = 0x55534152;
>>>> @@ -1517,7 +1519,22 @@ static void atmel_get_ip_name(struct uart_port *port)
>>>>   		dev_dbg(port->dev, "This is uart\n");
>>>>   		atmel_port->is_usart = false;
>>>>   	} else {
>>>> -		dev_err(port->dev, "Not supported ip name, set to uart\n");
>>>> +		/* fallback for older SoCs: use version field */
>>>> +		version = UART_GET_IP_VERSION(port);
>>>> +		switch (version) {
>>>> +		case 0x302:
>>>> +		case 0x10213:
>>>> +			dev_dbg(port->dev, "This version is usart\n");
>>>> +			atmel_port->is_usart = true;
>>>> +			break;
>>>> +		case 0x203:
>>>> +		case 0x10202:
>>>> +			dev_dbg(port->dev, "This version is uart\n");
>>>> +			atmel_port->is_usart = false;
>>>> +			break;
>>>> +		default:
>>>> +			dev_err(port->dev, "Not supported ip name nor version, set to uart\n");
>>>
>>> it's not really an error a dev_warn is more oppropriate
>>
>> As we are already in -rc5 and that these fixes are critical for at91
>> platforms, I will not re-spin another patch just for this.
>>
>> Moreover, I have the feeling that if we end up in this case, it
>> means that we are in big troubles because the usart/uart included in
>> the product triggering this log is not known (I recall that newer
>> products do not have to hit these lines of code).
>>
>> With these 2 reasons, I prefer to keep my patch like it is.
>>
>> Greg, can you consider taking these two patches as regression fixes
>> for 3.12 (with Tested-by tag from Thomas)?
>
> Is this really a regression from 3.11?

Yes it is. Commit id that I am referring to in patch 1/2 
(055560b04a8cd063aea916fd083b7aec02c2adb8) hit the mainline in 3.12-rc 
time-frame.

> What's the worry about waiting
> for 3.13-rc1, getting this correct, and then backporting them to the
> 3.12-stable trees?

It will break all older at91 in 3.12-final. Moreover, I do think that 
the actual patches are bringing an incorrect solution and I do not plan 
to have a better one (which one?) for 3.13...

> I'd prefer that, so, please clean this up properly and resend it, with
> the tested-by: lines and I'll queue them up for 3.13-rc1.

I do not know what to cleanup. Anyway, tell me if you want that I resend 
the series of 2 patches with the "Tested-by" tag included.

Bye,
-- 
Nicolas Ferre

  reply	other threads:[~2013-10-17  8:17 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-10  8:43 [PATCH 1/2] tty/serial: at91: fix uart/usart selection for older products Nicolas Ferre
2013-10-10  8:43 ` Nicolas Ferre
2013-10-10  8:43 ` Nicolas Ferre
2013-10-10  8:43 ` [PATCH 2/2] tty/serial: at91: add a fallback option to determine uart/usart property Nicolas Ferre
2013-10-10  8:43   ` Nicolas Ferre
2013-10-10  8:43   ` Nicolas Ferre
2013-10-12 15:00   ` Thomas Petazzoni
2013-10-12 15:00     ` Thomas Petazzoni
2013-10-12 15:00     ` Thomas Petazzoni
2013-10-14 13:59   ` Jean-Christophe PLAGNIOL-VILLARD
2013-10-14 13:59     ` Jean-Christophe PLAGNIOL-VILLARD
2013-10-14 13:59     ` Jean-Christophe PLAGNIOL-VILLARD
2013-10-15  9:19     ` Nicolas Ferre
2013-10-15  9:19       ` Nicolas Ferre
2013-10-15  9:19       ` Nicolas Ferre
2013-10-16 20:14       ` Greg Kroah-Hartman
2013-10-16 20:14         ` Greg Kroah-Hartman
2013-10-17  8:16         ` Nicolas Ferre [this message]
2013-10-17  8:16           ` Nicolas Ferre
2013-10-17  8:16           ` Nicolas Ferre
2013-10-17 14:13           ` Greg Kroah-Hartman
2013-10-17 14:13             ` Greg Kroah-Hartman
2013-10-17 15:33             ` Nicolas Ferre
2013-10-17 15:33               ` Nicolas Ferre
2013-10-17 15:33               ` Nicolas Ferre
2013-10-14 13:58 ` [PATCH 1/2] tty/serial: at91: fix uart/usart selection for older products Jean-Christophe PLAGNIOL-VILLARD
2013-10-14 13:58   ` Jean-Christophe PLAGNIOL-VILLARD
2013-10-14 13:58   ` Jean-Christophe PLAGNIOL-VILLARD
2013-10-15  9:10   ` Nicolas Ferre
2013-10-15  9:10     ` Nicolas Ferre
2013-10-15  9:10     ` Nicolas Ferre

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=525F9CEF.9020904@atmel.com \
    --to=nicolas.ferre@atmel.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=josh.wu@atmel.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-serial@vger.kernel.org \
    --cc=ludovic.desroches@atmel.com \
    --cc=plagnioj@jcrosoft.com \
    --cc=voice.shen@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.