Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752250AbcCARsO (ORCPT ); Tue, 1 Mar 2016 12:48:14 -0500 Received: from mga14.intel.com ([192.55.52.115]:58430 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751026AbcCARsM (ORCPT ); Tue, 1 Mar 2016 12:48:12 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.22,524,1449561600"; d="scan'208";a="914575210" Message-ID: <1456854532.13244.215.camel@linux.intel.com> Subject: Re: [PATCH v7] serial: support for 16550A serial ports on LP-8x4x From: Andy Shevchenko To: Sergei Ianovich , linux-kernel@vger.kernel.org Cc: Alan Cox , Arnd Bergmann , Rob Herring , Pawel Moll , Mark Rutland , Ian Campbell , Kumar Gala , Greg Kroah-Hartman , Jiri Slaby , Heikki Krogerus , Peter Hurley , Masahiro Yamada , Paul Burton , Mans Rullgard , Joachim Eastwood , Scott Wood , Paul Gortmaker , Peter Ujfalusi , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , "open list:SERIAL DRIVERS" Date: Tue, 01 Mar 2016 19:48:52 +0200 In-Reply-To: <1456852472.23036.124.camel@gmail.com> References: <1456589675-25377-1-git-send-email-ynvich@gmail.com> <1456781209-11390-1-git-send-email-ynvich@gmail.com> <1456830401.13244.189.camel@linux.intel.com> <1456849504.23036.108.camel@gmail.com> <1456850782.13244.208.camel@linux.intel.com> <1456852472.23036.124.camel@gmail.com> Organization: Intel Finland Oy Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.18.3-1 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1946 Lines: 66 On Tue, 2016-03-01 at 20:14 +0300, Sergei Ianovich wrote: > On Tue, 2016-03-01 at 18:46 +0200, Andy Shevchenko wrote: > > On Tue, 2016-03-01 at 19:25 +0300, Sergei Ianovich wrote: > > > On Tue, 2016-03-01 at 13:06 +0200, Andy Shevchenko wrote: > > > > On Tue, 2016-03-01 at 00:26 +0300, Sergei Ianovich wrote: > > So, but if you support only fixed rates, why do you care about > > BOTHER > > at all? > > If BOTHER is defined, tty_termios_baud_rate() > and tty_termios_encode_baud_rate() allow non-standard baud rates. I > should clear it from c_cflag to indicate I don't support it. > > > > > >   > > > > I think you can call this unconditionally together with case > > > > > 115200. > > > > > > The calls are orthogonal. This one deals with the case when > > > BOTHER > > > is > > > defined and set, and we have non-zero rate with BOTHER, but we > > > have > > > zero rate after BOTHER is cleared. So we set 9600 as a sane > > > default > > > speed. Maybe you just set a baud rate nearest to the one from the table in case of BOTHER? In that case perhaps you have to supply +-1 to the range. That's why I asked about uart_get_baud_rate().  Maybe this flow will work for you if (BOTHER)  clear BOTHER  call uart_get_baud_rate() ? > The warning seems to be the result of initializing a spinlock with > zero. Spinlocks are intentionally obfuscated, but I didn't > investigate > further. > > > $ git grep -n 'struct .* = {0};' | wc -l > > 338 > > > > $ git grep -n 'struct .* = { \?0 \?};' | wc -l > > 550 > > > > ( '… = { 0 };' included) > > The first structure member is most likely not a spinlock in those > cases. Hmm... Interesting. On one hand the poison is reasonable, on the other we often do a memset() or {0} on structures, i.o.w. assign 0 as initial value until spinlock_init(). Arnd, what do you think about this (and similar) case(s)? -- Andy Shevchenko Intel Finland Oy