linux-kernel - Re: [PATCH v29 00/16] Multicolor Framework v29

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]

Date:   Tue, 7 Jul 2020 10:36:00 -0500
From:   Dan Murphy <dmurphy@...com>
To:     Pavel Machek <pavel@....cz>, <marek.behun@....cz>
CC:     <jacek.anaszewski@...il.com>, <robh@...nel.org>,
        <devicetree@...r.kernel.org>, <linux-leds@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>,
        <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH v29 00/16] Multicolor Framework v29

Pavel

On 7/6/20 7:31 AM, Dan Murphy wrote:
> Pavel
>
> On 7/4/20 7:47 AM, Pavel Machek wrote:
>> Hi!
>>
>>> This is the multi color LED framework. This framework presents 
>>> clustered
>>> colored LEDs into an array and allows the user space to adjust the 
>>> brightness
>>> of the cluster using a single file write.  The individual colored LEDs
>>> intensities are controlled via a single file that is an array of LEDs
>>>
>>> Change to the LEDs Kconfig to fix dependencies on the LP55XX_COMMON.
>>> Added update to the u8500_defconfig
>> Marek, would you be willing to look over this series?
>>
>> Dan, can we please get it in the order
>>
>> 1) fixes first
>>
>> 2) changes needed for multicolor but not depending on dt acks
>>
>> 3) dt changes
>>
>> 4) rest?
>>
>> This is the order it should have been in the first place, and I'd like
>> to get fixes applied, and perhaps some of the preparation.
>
> This will depend on if there are comments.  If I have to push a v30 
> then I will reorder.
>
> If not then there would be no reason to re-order these.
>
FYI I just reordered these locally and the fixes patches applied cleanly 
to your for-next branch and the MC FW patches applied cleanly on top of 
those.

So you should be able to pull in the fixes with no dependency on the MC 
FW patches.  If you can apply the fixes cleanly then if there are 
conflicts with the MC FW patches then I will fix those as well.

Dan


> Dan
>
>