From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S964945AbdJRH1u (ORCPT ); Wed, 18 Oct 2017 03:27:50 -0400 Received: from mail-lf0-f67.google.com ([209.85.215.67]:54182 "EHLO mail-lf0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752526AbdJRH1t (ORCPT ); Wed, 18 Oct 2017 03:27:49 -0400 X-Google-Smtp-Source: ABhQp+R/oX2euzKYwxB29TrpSMFR9b5cthH+4o+dDxwN75NRofzcWZwoTSOfIPI3qdsKxCaz/fXDfQ== Date: Wed, 18 Oct 2017 09:27:47 +0200 From: Johan Hovold To: Andrey Smirnov Cc: Johan Hovold , linux-kernel , Chris Healy , Lucas Stach , Nikita Yushchenko , Lee Jones , Greg Kroah-Hartman , Pavel Machek Subject: Re: [RESEND PATCH v7 1/1] platform: Add driver for RAVE Supervisory Processor Message-ID: <20171018072747.GD5638@localhost> References: <20171013061321.31252-1-andrew.smirnov@gmail.com> <20171013061321.31252-2-andrew.smirnov@gmail.com> <20171013072731.GC29243@localhost> <20171016141400.GA5638@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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, Oct 16, 2017 at 09:45:58AM -0700, Andrey Smirnov wrote: > On Mon, Oct 16, 2017 at 7:14 AM, Johan Hovold wrote: > > On Fri, Oct 13, 2017 at 08:56:00AM -0700, Andrey Smirnov wrote: > >> On Fri, Oct 13, 2017 at 12:27 AM, Johan Hovold wrote: > >> > On Thu, Oct 12, 2017 at 11:13:21PM -0700, Andrey Smirnov wrote: > >> >> Add a driver for RAVE Supervisory Processor, an MCU implementing > >> >> varoius bits of housekeeping functionality (watchdoging, backlight > >> >> control, LED control, etc) on RAVE family of products by Zodiac > >> >> Inflight Innovations. > >> >> > >> >> This driver implementes core MFD/serdev device as well as > >> >> communication subroutines necessary for commanding the device. > The reason I mentioned "simple-mfd" was because I assumed it was > necessary to use of_platform_default_populate(), which, re-reading the > corresponding code, seems to have been a mistake on my part. However, > now I am not sure I understand the point you are/were trying to make. > The way I understand "instead of rolling your own mfd-implementation" > is "You ignored/missed the precedent and didn't use agreed-upon way of > creating an MFD from DT and re-invented the code to do so", in which > case I'd like to know the canonical way I missed. > > Form you response, however, I get a feeling that you are trying to > convince me that the driver I submitted is an MFD driver. If so, then > there's no need, we are in agreement here. Good, then we just need to convince Lee. ;) I was merely pointing out that, yes, you are implementing an MFD driver, but you placed it in drivers/platform and did not not use any facilities provided by the MFD subsystem (hence, the "rolling your own"). Take a look at the dln2 mfd driver which I believe implement something similar albeit using USB as a transport (and therefore does not use DT to instantiates the children). One point being that not all mfd drivers use i2c/spi and regmap. > > Also note that no drivers under drivers/platforms does anything like > > this. > > > > I am aware of that. As I as I mentioned before, the decision to place > this code into "drivers/platforms" was not mine. You should have put this in the changelog and commit message since its far from obvious what happened here. Johan