linux-serial.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Paul Gortmaker <paul.gortmaker@windriver.com>
To: Peter Hung <hpeter@gmail.com>
Cc: gregkh@linuxfoundation.org, jslaby@suse.com,
	andriy.shevchenko@linux.intel.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 <hpeter+linux_kernel@gmail.com>
Subject: Re: [PATCH 0/3] 8250: Split Fintek PCIE to UART to independent file
Date: Mon, 18 Jan 2016 22:56:50 -0500	[thread overview]
Message-ID: <20160119035649.GA1696@windriver.com> (raw)
In-Reply-To: <1453171266-15874-1-git-send-email-hpeter+linux_kernel@gmail.com>

[[PATCH 0/3] 8250: Split Fintek PCIE to UART to independent file] On 19/01/2016 (Tue 10:41) Peter Hung wrote:

> Fintek F81504/508/512 is a multi-functional PCIE device. It contains
> GPIO and serial port with high baudrate & RTS auto direction for RS485.
> 

Some general high level comments (meaning I've not looked at the code in
detail, but have looked at this series) and I wonder about some issues:

> 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? 

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?

Don't get me wrong -- forking workarounds for buggy hardware into
smaller workaround files and/or Kconfigs can be a win for everyone else,
but we should be clear on why we do them.

> 
> IC function list:
> 	F81504: Max 2x8 GPIOs and max 4 serial ports
> 			port2/3 are multi-function
> 	F81508: Max 6x8 GPIOs and max 8 serial ports
> 			port2/3 are multi-function, port8/9/10/11 are gpio only
> 	F81512: Max 6x8 GPIOs and max 12 serial ports
> 			port2/3/8/9/10/11 are multi-function
> 
> We'll spilt from 8250_pci.c to new file 8250_fintek_pci.c and make it
> as a kernel module with first & second patch, implements GPIOLIB with
> third patch. 

> 
> Peter Hung (3):
>   serial: 8250_pci: Remove Fintek PCIE UART driver

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.

>   8250_fintek_pci: Add Fintek PCIE UART driver

This creates a new Kconfig var. which is default=m.  How does that work
if people were using these for built-in early console support in the
past?  Are these cards universal, or should it be default=m if (...)
based on a Kconfig where this hardware exists?

>   8250_fintek_pci: Add GPIOLIB support

What does this add?  The commit log is not at all clear.  Leaving me to
ask if it does belong in the core PCI support code at all?  I honestly
don't know, since I don't know the hardware details here.  The commit
long logs could go a long way to closing this knowledge gap if the 0/N
listed the shortcomings and the 3/3 here indicated what the GPIO magic
had managed to add.

Again, this may be obvious to others, but the long logs should try and
give a hint to people on the fringe who maybe don't have all the
specific Fintek hardware details when reading the logs.

P.

  parent reply	other threads:[~2016-01-19  3:56 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-19  2:41 [PATCH 0/3] 8250: Split Fintek PCIE to UART to independent file Peter Hung
2016-01-19  2:41 ` [PATCH 1/3] serial: 8250_pci: Remove Fintek PCIE UART driver Peter Hung
2016-01-19  2:41 ` [PATCH 2/3] 8250_fintek_pci: Add " Peter Hung
2016-01-19  2:41 ` [PATCH 3/3] 8250_fintek_pci: Add GPIOLIB support Peter Hung
2016-01-19  3:56 ` Paul Gortmaker [this message]
2016-01-19  8:45   ` [PATCH 0/3] 8250: Split Fintek PCIE to UART to independent file Peter Hung
2016-01-19  9:33     ` Andy Shevchenko
2016-01-19 12:33     ` One Thousand Gnomes
2016-01-19 13:21       ` Andy Shevchenko
2016-01-20  2:59         ` Peter Hung
2016-01-20  6:22           ` Sudip Mukherjee
2016-01-20  8:24             ` Peter Hung
2016-01-22 10:53               ` Sudip Mukherjee
2016-01-22 13:44                 ` Andy Shevchenko
2016-01-29 17:38                   ` Sudip Mukherjee
2016-01-29 18:35                     ` Andy Shevchenko

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=20160119035649.GA1696@windriver.com \
    --to=paul.gortmaker@windriver.com \
    --cc=adam.lee@canonical.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=arnd@arndb.de \
    --cc=gregkh@linuxfoundation.org \
    --cc=heikki.krogerus@linux.intel.com \
    --cc=hpeter+linux_kernel@gmail.com \
    --cc=hpeter@gmail.com \
    --cc=jslaby@suse.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-serial@vger.kernel.org \
    --cc=manabian@gmail.com \
    --cc=mans@mansr.com \
    --cc=matthias.bgg@gmail.com \
    --cc=paul.burton@imgtec.com \
    --cc=peter.ujfalusi@ti.com \
    --cc=peter@hurleysoftware.com \
    --cc=peter_hong@fintek.com.tw \
    --cc=scottwood@freescale.com \
    --cc=soeren.grunewald@desy.de \
    --cc=udknight@gmail.com \
    --cc=yamada.masahiro@socionext.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).