linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mark Brown <broonie@kernel.org>
To: Dan Murphy <dmurphy@ti.com>
Cc: jacek.anaszewski@gmail.com, pavel@ucw.cz, lgirdwood@gmail.com,
	lee.jones@linaro.org, linux-leds@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [RESEND PATCH v4 1/6] regulator: lm363x: Make the gpio register enable flexible
Date: Wed, 29 May 2019 16:10:00 +0100	[thread overview]
Message-ID: <20190529151000.GP2456@sirena.org.uk> (raw)
In-Reply-To: <2398099b-16e6-f155-5852-45ba3dbc21ef@ti.com>

[-- Attachment #1: Type: text/plain, Size: 1109 bytes --]

On Wed, May 29, 2019 at 06:51:32AM -0500, Dan Murphy wrote:

> Although I don't disagree with you I don't see how the interface is fragile
> with only these 3 regulators defined.

> Would it not be prudent to amend this driver if/when a new regulator is
> needed that has a different enable bit/register combination?   And if that

The fragility I'm worried about is someone forgetting to make suitable
updates, especially if they don't use the feature in their own system.

> was the case I would almost expect a different driver completely if the
> regmap did not line up correctly.  I only reused this driver because the
> registers and bits lined up and did not think it was necessary to create a
> whole new driver.

This is a single register bit which is set once on startup isn't it?  It
seems like exactly the sort of thing that a hardware designer might
change incompatibly, perhaps even for good reasons like adding more
flexibility over which pins can be used to control the enable and far
from something that would require a totally new driver if it was handled
differently.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  reply	other threads:[~2019-05-29 15:10 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-22 19:27 [PATCH v4 0/6] LM36274 Introduction Dan Murphy
2019-05-22 19:27 ` [RESEND PATCH v4 1/6] regulator: lm363x: Make the gpio register enable flexible Dan Murphy
2019-05-22 21:22   ` Pavel Machek
2019-05-23 13:03   ` Mark Brown
2019-05-23 13:50     ` Dan Murphy
2019-05-26 12:48       ` Mark Brown
2019-05-29 11:51         ` Dan Murphy
2019-05-29 15:10           ` Mark Brown [this message]
2019-05-29 20:47             ` Dan Murphy
2019-05-30 15:26               ` Mark Brown
2019-06-04 15:14                 ` Dan Murphy
2019-06-04 15:33                   ` Mark Brown
2019-05-22 19:27 ` [RESEND PATCH v4 2/6] dt-bindings: mfd: Add lm36274 bindings to ti-lmu Dan Murphy
2019-05-22 21:22   ` Pavel Machek
2019-05-22 19:27 ` [RESEND PATCH v4 3/6] mfd: ti-lmu: Add LM36274 support to the ti-lmu Dan Murphy
2019-05-23  8:09   ` Pavel Machek
2019-05-22 19:27 ` [RESEND PATCH v4 4/6] regulator: lm363x: Add support for LM36274 Dan Murphy
2019-05-23  8:12   ` Pavel Machek
2019-05-23 13:04   ` Mark Brown
2019-05-22 19:27 ` [RESEND PATCH v4 5/6] dt-bindings: leds: Add LED bindings for the LM36274 Dan Murphy
2019-05-23 12:43   ` Pavel Machek
2019-05-22 19:27 ` [RESEND PATCH v4 6/6] leds: lm36274: Introduce the TI LM36274 LED driver Dan Murphy
2019-05-23 12:50   ` Pavel Machek
2019-05-23 19:09     ` Dan Murphy
2019-05-24 20:51       ` Jacek Anaszewski
2019-05-29 13:58         ` Lee Jones
2019-05-29 20:50           ` Jacek Anaszewski
2019-05-30  7:38             ` Lee Jones
2019-05-30 19:58               ` Jacek Anaszewski
2019-05-31  6:23                 ` Lee Jones
2019-05-31 19:44                   ` Jacek Anaszewski
2019-05-31 21:07                     ` Dan Murphy
2019-05-31 21:57                       ` Jacek Anaszewski
2019-05-31 22:41                         ` Dan Murphy
2019-06-01 13:55                           ` Jacek Anaszewski
2019-05-22 19:37 ` [PATCH v4 0/6] LM36274 Introduction Jacek Anaszewski
2019-05-22 19:39   ` Dan Murphy

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=20190529151000.GP2456@sirena.org.uk \
    --to=broonie@kernel.org \
    --cc=dmurphy@ti.com \
    --cc=jacek.anaszewski@gmail.com \
    --cc=lee.jones@linaro.org \
    --cc=lgirdwood@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-leds@vger.kernel.org \
    --cc=pavel@ucw.cz \
    /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).