From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753402AbdGSI7a (ORCPT ); Wed, 19 Jul 2017 04:59:30 -0400 Received: from mail-lf0-f67.google.com ([209.85.215.67]:35591 "EHLO mail-lf0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751815AbdGSI71 (ORCPT ); Wed, 19 Jul 2017 04:59:27 -0400 Date: Wed, 19 Jul 2017 10:59:34 +0200 From: Johan Hovold To: Anatolij Gustschin Cc: Lee Jones , Linus Walleij , Alan Tull , Moritz Fischer , linux-gpio@vger.kernel.org, linux-fpga@vger.kernel.org, linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org, David Laight Subject: Re: [PATCH 1/3] mfd: Add support for FTDI FT232H devices Message-ID: <20170719085934.GU29638@localhost> References: <1499374158-12388-1-git-send-email-agust@denx.de> <1499374158-12388-2-git-send-email-agust@denx.de> <20170710125210.GK29638@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170710125210.GK29638@localhost> User-Agent: Mutt/1.7.2 (2016-11-26) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jul 10, 2017 at 02:52:10PM +0200, Johan Hovold wrote: > On Thu, Jul 06, 2017 at 10:49:16PM +0200, Anatolij Gustschin wrote: > > Add USB part with common functions for USB-GPIO/I2C/SPI master > > adapters. These allow communication with chip's control, transmit > > and receive endpoints and will be used by various FT232H drivers. > > > +static const struct mfd_cell ftdi_cells[] = { > > + { .name = "ftdi-cbus-gpio", }, > > + { .name = "ftdi-mpsse-i2c", }, > > + { .name = "ftdi-mpsse-spi", }, > > + { .name = "ftdi-fifo-fpp-mgr", }, > > +}; > > Correct me if I'm wrong, but aren't these modes really mutually > exclusive, possibly with exception of cbus-gpio (some pins are at least > available as GPIOs in MPSSE mode)? Then MFD is not is not the right fit > here either. You never replied to this, and I'm afraid there are more issue with this series. > And as David Laight already pointed out, your ftdi-fifo-fpp-mgr driver > seems too application specific for a generic chip like this. Of which this is one is one of the major. In short, your driver is much to application specific and is probably something that needs to be implemented in userspace using libftdi. Speaking of libftdi, you seem to have copied or borrowed a lot of code and protocol from libftdi and this should have been mentioned in commit messages and file headers (not just in a comment to one specific function). These chips can be used for a many different applications (also in FIFO mode) so you cannot tie a driver to it exposing just a specific interface for programming a certain class of FPGAs. Johan