From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932727AbcASJda (ORCPT ); Tue, 19 Jan 2016 04:33:30 -0500 Received: from mga11.intel.com ([192.55.52.93]:32684 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932624AbcASJdZ (ORCPT ); Tue, 19 Jan 2016 04:33:25 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.22,316,1449561600"; d="scan'208";a="635981826" Message-ID: <1453196024.2521.108.camel@linux.intel.com> Subject: Re: [PATCH 0/3] 8250: Split Fintek PCIE to UART to independent file From: Andy Shevchenko To: Peter Hung , Paul Gortmaker Cc: gregkh@linuxfoundation.org, jslaby@suse.com, heikki.krogerus@linux.intel.com, peter@hurleysoftware.com, soeren.grunewald@desy.de, udknight@gmail.com, adam.lee@canonical.com, arnd@arndb.de, yamada.masahiro@socionext.com, mans@mansr.com, scottwood@freescale.com, paul.burton@imgtec.com, matthias.bgg@gmail.com, manabian@gmail.com, peter.ujfalusi@ti.com, linux-kernel@vger.kernel.org, linux-serial@vger.kernel.org, peter_hong@fintek.com.tw, Peter Hung Date: Tue, 19 Jan 2016 11:33:44 +0200 In-Reply-To: <569DF7C3.5050306@gmail.com> References: <1453171266-15874-1-git-send-email-hpeter+linux_kernel@gmail.com> <20160119035649.GA1696@windriver.com> <569DF7C3.5050306@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 On Tue, 2016-01-19 at 16:45 +0800, Peter Hung wrote: > Hi Paul, > > Paul Gortmaker 於 2016/1/19 上午 11:56 寫道: > > > The serial ports support from 50bps to 1.5Mbps with Linux > > > baudrate > > > define excluding 1.0Mbps due to not support 16MHz clock source. > > > > How does this differ from what was achieved or possible with the > > old way > > of things?  What was the limitation in the existing 8250 code > > sharing > > that required Fintek code to fork and become independent? > > The architecture of 8250_pci.c is good for PCIE device with 8250 > compatible serial ports. We want to implement all functions of > F81504/508/512, but it'll make 8250_pci.c bloated and complex if we > implement GPIOLIB in 8250_pci.c > > Could I implement GPIOLIB within 8250_pci.c instead of a newer file? Hm… So, can we stick with separate driver, or you're gonna shake for each reviewer's comment? > > > How much code was just copied 8250 boilerplate vs. being a new > > implementation?  The diffstat shows approx 500 lines of new > > code.  What > > does that add vs. just copying? > > Due to this IC contains 8250-compatible ports, the most functions is > copy from fintek section of 8250_pci.c. The differences are highbaud > rate & GPIOLIB implementations. I agree with Paul, I think what you have done is to: 1) split out existing code to separate driver (no your changes, but minimum necessary to this split) — one patch! 2) clean up it (at least I see the old PM code which should be refactored) 3) enhance functionality accordingly to what you need. > > > > > If someone had 8250 (PCI) builtin before, and Fintek stops working, > > they will most guaranteed bisect to this commit above where you > > remove > > support.  That is less than ideal.  We try to avoid code deletions > > or > > Kconfig addtions that will be obvious bisect magnets. > > It can be prevented if implements GPIOLIB in 8250_pci.c. Yeah, see item 1) above. -- Andy Shevchenko Intel Finland Oy