From patchwork Fri Mar 3 23:23:05 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: James Hogan X-Patchwork-Id: 9603705 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 008FF60453 for ; Fri, 3 Mar 2017 23:24:34 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id E63472861A for ; Fri, 3 Mar 2017 23:24:33 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id DACAD2861D; Fri, 3 Mar 2017 23:24:33 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=2.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, T_TVD_MIME_EPI autolearn=unavailable version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id BB5D92861A for ; Fri, 3 Mar 2017 23:24:32 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752339AbdCCXX5 (ORCPT ); Fri, 3 Mar 2017 18:23:57 -0500 Received: from mailapp01.imgtec.com ([195.59.15.196]:58571 "EHLO imgpgp01.kl.imgtec.org" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752064AbdCCXXy (ORCPT ); Fri, 3 Mar 2017 18:23:54 -0500 Received: from imgpgp01.kl.imgtec.org (imgpgp01.kl.imgtec.org [127.0.0.1]) by imgpgp01.kl.imgtec.org (PGP Universal) with ESMTP id 65EE241F8E31; Sat, 4 Mar 2017 00:27:51 +0000 (GMT) Received: from mailapp01.imgtec.com ([10.100.180.241]) by imgpgp01.kl.imgtec.org (PGP Universal service); Sat, 04 Mar 2017 00:27:51 +0000 X-PGP-Universal: processed; by imgpgp01.kl.imgtec.org on Sat, 04 Mar 2017 00:27:51 +0000 Received: from hhmail02.hh.imgtec.org (unknown [10.100.10.20]) by Forcepoint Email with ESMTPS id 8200492B8A993; Fri, 3 Mar 2017 23:23:01 +0000 (GMT) Received: from localhost (192.168.154.110) by hhmail02.hh.imgtec.org (10.100.10.21) with Microsoft SMTP Server (TLS) id 14.3.294.0; Fri, 3 Mar 2017 23:23:06 +0000 Date: Fri, 3 Mar 2017 23:23:05 +0000 From: James Hogan To: Andy Shevchenko CC: Heiko Stuebner , Jason Uy , Greg Kroah-Hartman , Jiri Slaby , Kefeng Wang , Noam Camus , Heikki Krogerus , Wang Hongcheng , , LKML , , Linux MIPS Mailing List , David Daney , Russell King , , Viresh Kumar Subject: Re: [PATCH v2 1/1] serial: 8250_dw: Allow hardware flow control to be used Message-ID: <20170303232305.GU996@jhogan-linux.le.imgtec.org> References: <1484164100-9805-1-git-send-email-jason.uy@broadcom.com> <1484164100-9805-2-git-send-email-jason.uy@broadcom.com> <1488394220.20145.68.camel@linux.intel.com> <20170303002129.GS996@jhogan-linux.le.imgtec.org> <1488547866.20145.74.camel@linux.intel.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1488547866.20145.74.camel@linux.intel.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-Originating-IP: [192.168.154.110] X-ESG-ENCRYPT-TAG: 1b7d744b Sender: linux-clk-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-clk@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On Fri, Mar 03, 2017 at 03:31:06PM +0200, Andy Shevchenko wrote: > On Fri, 2017-03-03 at 00:21 +0000, James Hogan wrote: > > The CONFIG_HAVE_CLK=n implementation of devm_clk_get() in particular > > seems highly questionable to me, given that commit 93abe8e4b13a ("clk: > > add non CONFIG_HAVE_CLK routines") which added it 5 years ago says: > > > > > These calls will return error for platforms that don't select > > > HAVE_CLK > > > > And NULL isn't an error in this API. > > Which is okay. I dunno what should be returned from clk_round_rate() if > clk is NULL. I would fix CLK framework, though I would like to gather > more details. Hmm, the common clock framwork is just one implementation of the clock API that won't use NULL as a valid clock handle. HAVE_CLK=n is just another implementation that does return NULL as a valid value, and accepts that value in the other clk functions. > Btw, I hope you also noticed this one: > > http://www.spinics.net/lists/linux-serial/msg25314.html Interesting. Following Russel's past advise[1], the following patch on top of Heiko's patch also fixes things for me on Octeon: [1] https://lists.gt.net/linux/kernel/2102623 If thats an acceptable fix I'll post it properly. Thoughts? Cheers James diff --git a/drivers/tty/serial/8250/8250_dw.c b/drivers/tty/serial/8250/8250_dw.c index 223ac234ddb2..e65808c482f1 100644 --- a/drivers/tty/serial/8250/8250_dw.c +++ b/drivers/tty/serial/8250/8250_dw.c @@ -267,6 +267,8 @@ static void dw8250_set_termios(struct uart_port *p, struct ktermios *termios, rate = clk_round_rate(d->clk, baud * 16); if (rate < 0) ret = rate; + else if (rate == 0) + ret = -ENOENT; else ret = clk_set_rate(d->clk, rate); clk_prepare_enable(d->clk);