linux-iio.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Eva Rachel Retuya <eraretuya@gmail.com>
To: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Lars-Peter Clausen <lars@metafoo.de>,
	Jonathan Cameron <jic23@kernel.org>,
	linux-iio@vger.kernel.org, Hartmut Knaack <knaack.h@gmx.de>,
	Peter Meerwald <pmeerw@pmeerw.net>,
	Dmitry Torokhov <dmitry.torokhov@gmail.com>,
	Michael Hennerich <michael.hennerich@analog.com>,
	Daniel Baluta <daniel.baluta@gmail.com>,
	Alison Schofield <amsfield22@gmail.com>,
	Florian Vaussard <florian.vaussard@heig-vd.ch>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Rob Herring <robh+dt@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	devicetree <devicetree@vger.kernel.org>
Subject: Re: [PATCH v3 4/4] iio: accel: adxl345: Add SPI support
Date: Fri, 24 Feb 2017 17:12:33 +0800	[thread overview]
Message-ID: <20170224091231.GC5012@Socrates-UM> (raw)
In-Reply-To: <CAHp75VfbfRB_7Y2CRrJRYHqnJNMYD1hKScGr0HLSpFSGgJtymA@mail.gmail.com>

On Thu, Feb 23, 2017 at 06:58:12PM +0200, Andy Shevchenko wrote:
> On Thu, Feb 23, 2017 at 6:47 PM, Lars-Peter Clausen <lars@metafoo.de> wrote:
> > On 02/23/2017 05:43 PM, Andy Shevchenko wrote:
> >> On Wed, Feb 22, 2017 at 12:23 PM, Eva Rachel Retuya <eraretuya@gmail.com> wrote:
> >>> Add SPI driver that initializes SPI regmap for the adxl345 core driver.
> >>> The driver supports the same functionality as I2C namely the x, y, z and
> >>> scale readings.
> 
> >>>  config ADXL345_I2C
> >>>         tristate
> >>>         select REGMAP_I2C
> >>>
> >>> +config ADXL345_SPI
> >>> +       tristate
> >>> +       select REGMAP_SPI
> >>
> >> Hmm...
> >> I saw another pattern
> >>
> >> Library / core part is non-visible to user, while
> >> SPI and I2C parts are selectable by user.
> >>
> >> Why do you use inverted pattern? What did I miss?
> >
> > The first version of the patch used the other pattern SPI/I2C visible.
> > Jonathan suggested this other pattern. I prefer the explicit SPI/I2C visible
> > pattern, but in the end it doesn't really matter as long as both work.
> 
> Yes, but this pattern makes extra footprint of the kernel and
> basically dead code when I would like, for example, to have SPI bus
> enabled, I2C module available, but SPI module not compiled.
> 
> Other one is when I want to have one compiled in, one as a module by
> whatever reason.
> 
> At the end I have no strong opinion, though rationale for the opposite is above.
> 

Hello Lars and Andy,

I'll revert to the explicit SPI/I2C pattern in order to give more
freedom in configuring as per the scenarios previously stated.

Thanks,
Eva

> -- 
> With Best Regards,
> Andy Shevchenko

  reply	other threads:[~2017-02-24  9:12 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-22 10:22 [PATCH v3 0/4] iio: accel: adxl345: Split driver into core and I2C then add SPI support Eva Rachel Retuya
2017-02-22 10:22 ` [PATCH v3 1/4] Documentation: dt-bindings: Document ADXL345 accelerometer binding Eva Rachel Retuya
2017-02-22 10:22 ` [PATCH v3 2/4] iio: accel: adxl345: Use I2C regmap instead of direct I2C access Eva Rachel Retuya
2017-02-23 16:27   ` Andy Shevchenko
2017-02-24  9:02     ` Eva Rachel Retuya
2017-02-22 10:23 ` [PATCH v3 3/4] iio: accel: adxl345: Split driver into core and I2C Eva Rachel Retuya
2017-02-23 16:36   ` Andy Shevchenko
2017-02-24  9:06     ` Eva Rachel Retuya
2017-02-22 10:23 ` [PATCH v3 4/4] iio: accel: adxl345: Add SPI support Eva Rachel Retuya
2017-02-23 16:43   ` Andy Shevchenko
2017-02-23 16:47     ` Lars-Peter Clausen
2017-02-23 16:58       ` Andy Shevchenko
2017-02-24  9:12         ` Eva Rachel Retuya [this message]
2017-02-24  9:22           ` Lars-Peter Clausen
2017-02-24 11:48             ` Andy Shevchenko
2017-02-24 14:30               ` Eva Rachel Retuya
2017-02-24 19:46                 ` Jonathan Cameron
2017-02-25 15:09                   ` Jonathan Cameron

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=20170224091231.GC5012@Socrates-UM \
    --to=eraretuya@gmail.com \
    --cc=amsfield22@gmail.com \
    --cc=andy.shevchenko@gmail.com \
    --cc=daniel.baluta@gmail.com \
    --cc=devicetree@vger.kernel.org \
    --cc=dmitry.torokhov@gmail.com \
    --cc=florian.vaussard@heig-vd.ch \
    --cc=jic23@kernel.org \
    --cc=knaack.h@gmx.de \
    --cc=lars@metafoo.de \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=michael.hennerich@analog.com \
    --cc=pmeerw@pmeerw.net \
    --cc=robh+dt@kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).