From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1752500AbbCKBUx (ORCPT <rfc822;w@1wt.eu>);
	Tue, 10 Mar 2015 21:20:53 -0400
Received: from szxga02-in.huawei.com ([119.145.14.65]:45992 "EHLO
	szxga02-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1751426AbbCKBUq (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Tue, 10 Mar 2015 21:20:46 -0400
Message-ID: <54FF9853.2060105@huawei.com>
Date: Wed, 11 Mar 2015 09:20:19 +0800
From: Zhang Zhen <zhenzhang.zhang@huawei.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20121010 Thunderbird/16.0.1
MIME-Version: 1.0
To: Peter Hurley <peter@hurleysoftware.com>
CC: Tim Kryger <tim.kryger@gmail.com>, Alan Cox <alan@linux.intel.com>,
        "long.wanglong" <long.wanglong@huawei.com>,
        <linux-serial@vger.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        <gregkh@linuxfoundation.org>, Jamie Iles <jamie@jamieiles.com>,
        Arnd Bergmann <arnd@arndb.de>, <shenjiangjiang@huawei.com>,
        Wang Kai <morgan.wang@huawei.com>
Subject: Re: [RFC] With 8250 Designware UART, if writes to the LCR failed
 the kernel will hung up
References: <54F96F5B.2090601@huawei.com>	<54F9DACA.3020103@hurleysoftware.com>	<CAD7vxxJXEz8KfXd9fBjkxTi5Nnjyw0=wwvbw5qCSwCMbBd64eA@mail.gmail.com>	<54FD4779.3020902@huawei.com>	<1425907939.3838.182.camel@linux.intel.com>	<CAD7vxxJvL61BjD9AMBF34Y8xnY+D-umuWLUq8Dh7ZbSm5tCE9w@mail.gmail.com>	<1425913502.3838.185.camel@linux.intel.com> <CAD7vxx+WYgOujpTAxXsUmcr8T4zHS9MYfwrWu8hV2t=TudLamQ@mail.gmail.com> <54FEF0B0.6010002@hurleysoftware.com>
In-Reply-To: <54FEF0B0.6010002@hurleysoftware.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-Originating-IP: [10.111.68.57]
X-CFilter-Loop: Reflected
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 2015/3/10 21:25, Peter Hurley wrote:
> On 03/09/2015 10:47 PM, Tim Kryger wrote:
>> The current workaround of clearing fifos and retrying a fixed number
>> of times isn't ideal but I'm not sure what else can be done given the
>> way this hardware works.
> 
> But hanging the machine is not an acceptable outcome.
> 
> Since the hang stems from the printk while already holding the port->lock,
> until I can fix the console write, I think it's best to comment out
> the dev_err() with a FIXME note.

Yeah，i agree.
> 
> The 8250 console write already checks port->sysrq to allow printk from
> within the driver so this solution just needs to be generalized.
> And there are debug uses of printk() from within the driver that are just
> as broken, so this isn't the only use case. (I want to do something
> similar for the au_serial-* i/o accessors too).
> 
> Regards,
> Peter Hurley
> 
> 
> 
> .
>