From: Lee Jones <lee.jones@linaro.org>
To: Josh Cartwright <joshc@ni.com>
Cc: Greg KH <gregkh@linuxfoundation.org>,
Kyle Roeschley <kyle.roeschley@ni.com>,
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
Date: Wed, 16 Mar 2016 07:48:24 +0000 [thread overview]
Message-ID: <20160316074824.GT13692@x1> (raw)
In-Reply-To: <20160314223022.GB22360@jcartwri.amer.corp.natinst.com>
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 <jeff.westfahl@ni.com>
> > >
> > > 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
next prev parent reply other threads:[~2016-03-16 7:48 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-14 21:54 [PATCH 1/2] misc: add nirtfeatures driver Kyle Roeschley
2016-03-14 22:05 ` Greg KH
2016-03-14 22:30 ` Josh Cartwright
2016-03-14 22:36 ` Kyle Roeschley
2016-03-16 7:48 ` Lee Jones [this message]
2016-03-16 22:30 ` Kyle Roeschley
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=20160316074824.GT13692@x1 \
--to=lee.jones@linaro.org \
--cc=arnd@arndb.de \
--cc=gregkh@linuxfoundation.org \
--cc=jeff.westfahl@ni.com \
--cc=joshc@ni.com \
--cc=kyle.roeschley@ni.com \
--cc=linux-kernel@vger.kernel.org \
--cc=nathan.sullivan@ni.com \
--cc=xander.huff@ni.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.