[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20191124223734.GA13261@nessie>
Date: Sun, 24 Nov 2019 22:37:34 +0000
From: Dan Robertson <dan@...obertson.com>
To: Jonathan Cameron <jic23@...nel.org>
Cc: Andy Shevchenko <andy.shevchenko@...il.com>,
linux-iio <linux-iio@...r.kernel.org>,
Peter Meerwald-Stadler <pmeerw@...erw.net>,
devicetree <devicetree@...r.kernel.org>,
Hartmut Knaack <knaack.h@....de>,
Rob Herring <robh+dt@...nel.org>,
Mark Rutland <mark.rutland@....com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Randy Dunlap <rdunlap@...radead.org>
Subject: Re: [PATCH v4 2/2] iio: (bma400) add driver for the BMA400
On Sat, Nov 23, 2019 at 12:51:35PM +0000, Jonathan Cameron wrote:
> If a function is your preferred route you could also just use it to compute
> the values for the available table at startup?
Yeah that makes sense. I'll add that in the next patchset version.
> > The sampling ratio, frequency, etc code seems to be the most complicated part
> > of the driver. Is it typically recommended to upstream a more minimal driver
> > that might assume the defaults?
>
> Often people upstream a first version that just uses defaults, then follow
> up (if they care) with later series adding the more fiddly elements.
>
> Sometimes those more fiddly bits never come as a particular author
> never needed them. That's absolutely fine. It's a rare driver
> that supports all the features on a non trivial device!
Makes sense. I'll likely add some extra bits in a follow-up patchset, so I can
learn a bit more.
Cheers,
- Dan
Powered by blists - more mailing lists