linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dan Murphy <dmurphy@ti.com>
To: Pavel Machek <pavel@ucw.cz>,
	Jacek Anaszewski <jacek.anaszewski@gmail.com>
Cc: <robh+dt@kernel.org>, <devicetree@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>, <lee.jones@linaro.org>,
	<linux-omap@vger.kernel.org>, <linux-leds@vger.kernel.org>,
	Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Subject: Re: [RFC PATCH v2 1/9] leds: add TI LMU backlight driver
Date: Wed, 3 Oct 2018 07:00:46 -0500	[thread overview]
Message-ID: <6f96a5bd-27df-7906-73bf-67bdf848308a@ti.com> (raw)
In-Reply-To: <20181002220754.GA20413@amd>

Hello

On 10/02/2018 05:07 PM, Pavel Machek wrote:
> Hi!
> 
>>> We have debated this over and over and now we have 3 different implementations
>>> available we need to collude on which one we want to support.
>>>
>>> Jacek I defer to you and Pavel since you are both LED maintainers.
>>>
>>> I can support the dedicated LED drivers but I cannot support the TI LMU only implementation.
>>
>> I uphold my previous opinion - please go ahead with moving the support
>> for non-MFD devices from MFD subsystem to the LED subsystem. And yes -
>> along with the bindings. This is semantically correct, and yet we don't
>> have mainline users.
>>
>> Pavel - you will have to engage more people for your crusade to prevail.
>> For now, to speed up the things, I am forced to ignore your NAK.
>> So NAK to your NAK. Sorry.
> 
> No need to be sorry :-).
> 
> Lets ignore the code for now, as code can be changed easily.
> 
> Bindings are not something you or I maintain, so we don't have final
> word there, and I have feeling this is not going to go past device
> tree maintainers. [AFAICT: you can move binding in Documentation/ to
> different place, that's not a problem; but creating a new binding when
> old one exists is.]
> 
> If you and Dan feel that is okay, you are welcome to try to get the
> patches past Rob, just please retain the NAK so that he remembers the
> discussion, and so that it is clear that I don't like the changes.
> 
> I believe smart thing to do is to try to do that before working
> further on the code, but of course, its all up to you :-).

I was looking for the review for the ti-lmu.txt binding on patchworks to see what
the comments were on the review or any explanation from reviewers to
why this implementation was done in the MFD.

Maybe there is some historical context that needs to be learned from here from
1.5 years ago.

I cannot seem to find any review posted in the patchworks archive.
I see reviews posted for the ti-lmu-backlight binding but none from
the ti-lmu.txt base binding.

Does anyone have a reference to the review?

If there is no review then I am wondering how this binding was accepted.
If there is no review and no current users then I would think that binding
 modification should be allowed.  But thats just my opinion.

Dan


> 
> Friends,
> 									Pavel
> 


-- 
------------------
Dan Murphy

  reply	other threads:[~2018-10-03 12:01 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-28 18:29 [RFC PATCH v2 0/9] TI LMU and Dedicated Drivers Dan Murphy
2018-09-28 18:29 ` [RFC PATCH v2 1/9] leds: add TI LMU backlight driver Dan Murphy
2018-10-02  7:56   ` Pavel Machek
2018-10-02 12:32     ` Dan Murphy
2018-10-02 18:52       ` Jacek Anaszewski
2018-10-02 22:07         ` Pavel Machek
2018-10-03 12:00           ` Dan Murphy [this message]
2018-10-03 12:10             ` Dan Murphy
2018-09-28 18:29 ` [RFC PATCH v2 2/9] dt-bindings: ti-lmu: Remove LM3697 Dan Murphy
2018-10-02  7:28   ` Pavel Machek
2018-10-03 12:24     ` Dan Murphy
2018-10-03 13:01       ` Pavel Machek
2018-10-03 20:46         ` Jacek Anaszewski
2018-10-04 13:26           ` Dan Murphy
2018-09-28 18:29 ` [RFC PATCH v2 3/9] mfd: ti-lmu: Remove support for LM3697 Dan Murphy
2018-09-28 18:29 ` [RFC PATCH v2 4/9] dt-bindings: leds: Add bindings for lm3697 driver Dan Murphy
2018-09-28 18:29 ` [RFC PATCH v2 5/9] leds: lm3697: Introduce the " Dan Murphy
2018-09-28 18:29 ` [RFC PATCH v2 6/9] dt-bindings: leds: Add support for the LM3633 Dan Murphy
2018-09-28 18:29 ` [RFC PATCH v2 7/9] leds: lm3633: Introduce the lm3633 driver Dan Murphy
2018-09-28 18:29 ` [RFC PATCH v2 8/9] dt-bindings: leds: Add the LM3632 LED dt binding Dan Murphy
2018-09-28 18:29 ` [RFC PATCH v2 9/9] leds: lm3632: Introduce the TI LM3632 driver 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=6f96a5bd-27df-7906-73bf-67bdf848308a@ti.com \
    --to=dmurphy@ti.com \
    --cc=devicetree@vger.kernel.org \
    --cc=jacek.anaszewski@gmail.com \
    --cc=lee.jones@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-leds@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=pavel@ucw.cz \
    --cc=robh+dt@kernel.org \
    --cc=sebastian.reichel@collabora.co.uk \
    /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).