From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934257AbcCPHsc (ORCPT ); Wed, 16 Mar 2016 03:48:32 -0400 Received: from mail-wm0-f52.google.com ([74.125.82.52]:35586 "EHLO mail-wm0-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932950AbcCPHs2 (ORCPT ); Wed, 16 Mar 2016 03:48:28 -0400 Date: Wed, 16 Mar 2016 07:48:24 +0000 From: Lee Jones To: Josh Cartwright Cc: Greg KH , Kyle Roeschley , arnd@arndb.de, linux-kernel@vger.kernel.org, jeff.westfahl@ni.com, nathan.sullivan@ni.com, xander.huff@ni.com Subject: Re: [PATCH 1/2] misc: add nirtfeatures driver Message-ID: <20160316074824.GT13692@x1> References: <1457992472-18680-1-git-send-email-kyle.roeschley@ni.com> <20160314220559.GA18771@kroah.com> <20160314223022.GB22360@jcartwri.amer.corp.natinst.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20160314223022.GB22360@jcartwri.amer.corp.natinst.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 14 Mar 2016, Josh Cartwright wrote: > On Mon, Mar 14, 2016 at 03:05:59PM -0700, Greg KH wrote: > > On Mon, Mar 14, 2016 at 04:54:32PM -0500, Kyle Roeschley wrote: > > > From: Jeff Westfahl > > > > > > This driver introduces support for hardware features of National > > > Instruments real-time controllers. This is an ACPI device that exposes > > > LEDs, switches, and watchdogs. > > > > If it's an acpi driver, why not put it in drivers/acpi? > > For the same reason we don't move all drivers for devices-on-a-PCI-bus > into drivers/pci? > > Drivers typically exist in the sourcetree with other drivers which > implement similar functionality, which works great for devices with > clear functional boundaries (GPIO controller drivers in drivers/gpio, > led drivers in drivers/leds, etc. etc.); but for devices which are a > hodgepodge of functionality, there isn't really a good fit anywhere > except maybe in misc or mfd. > > We could move it to mfd, but drivers in drivers/mfd which don't make use > of MFD_CORE seems equally strange (although, I suppose there is > precedent). Maybe Lee has some thoughts. Is there any reason why the functionality can't be split up into different source files? Create an LED driver, a Switch (whatever that is) driver and a Watchdog driver, place them in drivers/{appropriate}, then register from each of them using the MFD API. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog