From: Kefeng Wang <wangkefeng.wang@huawei.com>
To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
Noam Camus <noamc@ezchip.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Heikki Krogerus <heikki.krogerus@linux.intel.com>,
linux-serial@vger.kernel.org, linux-kernel@vger.kernel.org,
guohanjun@huawei.com, xuwei5@hisilicon.com
Subject: Re: [PATCH v4] serial: 8250_dw: fix wrong logic in dw8250_check_lcr()
Date: Thu, 7 Apr 2016 16:33:34 +0800 [thread overview]
Message-ID: <57061B5E.7040707@huawei.com> (raw)
In-Reply-To: <1459853407.12843.7.camel@linux.intel.com>
On 2016/4/5 18:50, Andy Shevchenko wrote:
> On Tue, 2016-04-05 at 13:53 +0800, Kefeng Wang wrote:
>> Commit cdcea058e510 ("serial: 8250_dw: Avoid serial_outx code
>> duplicate
>> with new dw8250_check_lcr()") introduce a wrong logic when write val
>> to
>> LCR reg. When CONFIG_64BIT enabled, __raw_writeq is used
>> unconditionally.
>>
>> The __raw_readq/__raw_writeq is introduced by commit bca2092d7897
>> ("serial:
>> 8250_dw: Use 64-bit access for OCTEON.") for OCTEON, so for
>> !PORT_OCTEON,
>> we better to use coincident write func.
>>
>> Fixes: cdcea058e510("serial: 8250_dw: Avoid serial_outx code
>> duplicate with new dw8250_check_lcr()")
>> Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
>> ---
>>
>> Changes since v3:
>> - Add patch change log, suggested by Greg Kroah-Hartman.
>> Changes since v2:
>> - Add #ifdef CONFIG_64BIT back, ensure it can be built under
>
> Oh, true. Since it's a native IO we can't use writeq() helper from io-
> 64-nonatomic-*.
>
>> configuration lacking readq/writeq.
>> Changes since v1:
>> - Repace '#ifdef CONFIG_64BIT' with IS_ENABLED(CONFIG_64BIT).
>> - Enrich patch log, and add Fixes tag.
[...]
>
> So, this changes logic to write the value on any 64 platform, using
> different (non-64-bit) accessors, so, the case to fix is
> actually "64BIT && !PORT_OCTEON". Perhaps commit message should be
> amended to point that clearly.
Yes, it's more clear. thanks for review and point it out.
To Greg, should I resend it or can you help me to change the patch log when you merge it. Thanks.
WARNING: multiple messages have this Message-ID (diff)
From: Kefeng Wang <wangkefeng.wang@huawei.com>
To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
Noam Camus <noamc@ezchip.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Heikki Krogerus <heikki.krogerus@linux.intel.com>,
<linux-serial@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
<guohanjun@huawei.com>, <xuwei5@hisilicon.com>
Subject: Re: [PATCH v4] serial: 8250_dw: fix wrong logic in dw8250_check_lcr()
Date: Thu, 7 Apr 2016 16:33:34 +0800 [thread overview]
Message-ID: <57061B5E.7040707@huawei.com> (raw)
In-Reply-To: <1459853407.12843.7.camel@linux.intel.com>
On 2016/4/5 18:50, Andy Shevchenko wrote:
> On Tue, 2016-04-05 at 13:53 +0800, Kefeng Wang wrote:
>> Commit cdcea058e510 ("serial: 8250_dw: Avoid serial_outx code
>> duplicate
>> with new dw8250_check_lcr()") introduce a wrong logic when write val
>> to
>> LCR reg. When CONFIG_64BIT enabled, __raw_writeq is used
>> unconditionally.
>>
>> The __raw_readq/__raw_writeq is introduced by commit bca2092d7897
>> ("serial:
>> 8250_dw: Use 64-bit access for OCTEON.") for OCTEON, so for
>> !PORT_OCTEON,
>> we better to use coincident write func.
>>
>> Fixes: cdcea058e510("serial: 8250_dw: Avoid serial_outx code
>> duplicate with new dw8250_check_lcr()")
>> Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
>> ---
>>
>> Changes since v3:
>> - Add patch change log, suggested by Greg Kroah-Hartman.
>> Changes since v2:
>> - Add #ifdef CONFIG_64BIT back, ensure it can be built under
>
> Oh, true. Since it's a native IO we can't use writeq() helper from io-
> 64-nonatomic-*.
>
>> configuration lacking readq/writeq.
>> Changes since v1:
>> - Repace '#ifdef CONFIG_64BIT' with IS_ENABLED(CONFIG_64BIT).
>> - Enrich patch log, and add Fixes tag.
[...]
>
> So, this changes logic to write the value on any 64 platform, using
> different (non-64-bit) accessors, so, the case to fix is
> actually "64BIT && !PORT_OCTEON". Perhaps commit message should be
> amended to point that clearly.
Yes, it's more clear. thanks for review and point it out.
To Greg, should I resend it or can you help me to change the patch log when you merge it. Thanks.
next prev parent reply other threads:[~2016-04-07 8:33 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-05 3:32 [PATCH v3] serial: 8250_dw: fix wrong logic in dw8250_check_lcr() Kefeng Wang
2016-04-05 3:32 ` Kefeng Wang
2016-04-05 4:02 ` Greg Kroah-Hartman
2016-04-05 4:55 ` Kefeng Wang
2016-04-05 4:55 ` Kefeng Wang
2016-04-05 5:53 ` [PATCH v4] " Kefeng Wang
2016-04-05 5:53 ` Kefeng Wang
2016-04-05 10:50 ` Andy Shevchenko
2016-04-07 8:33 ` Kefeng Wang [this message]
2016-04-07 8:33 ` Kefeng Wang
2016-04-19 8:29 ` Kefeng Wang
2016-04-19 8:29 ` Kefeng Wang
2016-04-29 0:44 ` Greg Kroah-Hartman
2016-05-02 9:19 ` [PATCH v5] " Kefeng Wang
2016-05-02 9:19 ` Kefeng Wang
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=57061B5E.7040707@huawei.com \
--to=wangkefeng.wang@huawei.com \
--cc=andriy.shevchenko@linux.intel.com \
--cc=gregkh@linuxfoundation.org \
--cc=guohanjun@huawei.com \
--cc=heikki.krogerus@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-serial@vger.kernel.org \
--cc=noamc@ezchip.com \
--cc=xuwei5@hisilicon.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.