linux-kernel - Re: [RFC PATCH v2 1/9] leds: add TI LMU backlight driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <b8f8c1e2-64fb-57ea-4b48-1e4738e9cb6b@ti.com>
Date:   Wed, 3 Oct 2018 07:10:59 -0500
From:   Dan Murphy <dmurphy@...com>
To:     Pavel Machek <pavel@....cz>,
        Jacek Anaszewski <jacek.anaszewski@...il.com>
CC:     <robh+dt@...nel.org>, <devicetree@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, <lee.jones@...aro.org>,
        <linux-omap@...r.kernel.org>, <linux-leds@...r.kernel.org>,
        Sebastian Reichel <sebastian.reichel@...labora.co.uk>,
        Lee Jones <lee.jones@...aro.org>
Subject: Re: [RFC PATCH v2 1/9] leds: add TI LMU backlight driver

Hello

On 10/03/2018 07:00 AM, Dan Murphy wrote:
> 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?

I found the review or at least the reference for the ti-lmu.txt binding.

https://lore.kernel.org/patchwork/patch/764180/

Does not appear that the binding was sent to the device tree mail list.
(Maybe that email list did not exist in Feb 2017).
Especially with the amount of change that is being submitted in the
newer patchsets.

Dan

> 
> 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