linux-kernel - Re: [PATCH v7 0/5] Reintroduce i.MX EPIT Timer

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 for Android: free password hash cracker in your pocket

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

Date:   Tue, 10 Jul 2018 17:37:26 +0200
From:   Daniel Lezcano <daniel.lezcano@...aro.org>
To:     Clément Péron <peron.clem@...il.com>
Cc:     Colin Didier <colin.didier@...ialet.com>,
        linux-arm-kernel@...ts.infradead.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org, Stefan Agner <stefan@...er.ch>,
        Thomas Gleixner <tglx@...utronix.de>,
        Fabio Estevam <fabio.estevam@....com>,
        Vladimir Zapolskiy <vladimir_zapolskiy@...tor.com>,
        Sascha Hauer <s.hauer@...gutronix.de>,
        Rob Herring <robh@...nel.org>,
        NXP Linux Team <linux-imx@....com>,
        Pengutronix Kernel Team <kernel@...gutronix.de>,
        Clément Peron <clement.peron@...ialet.com>
Subject: Re: [PATCH v7 0/5] Reintroduce i.MX EPIT Timer

On 10/07/2018 17:22, Clément Péron wrote:
> Hi Daniel,
> 
> On Tue, 10 Jul 2018 at 17:12, Daniel Lezcano <daniel.lezcano@...aro.org> wrote:
>>
>> On 10/07/2018 16:55, Clément Péron wrote:
>>> Hi,
>>>
>>> Is there still some remark against merging this ?
>>
>> How do you want this to be merged ?
>>
>> Shall I take the two patches related to the timer ? Or Ack them ?
> 
> I'm not an expert on how submitting patches works, it's the first
> driver I submit.

Ok, so usually this is what happens when there is a set of changes:

 1.  they all touch the same subsystem (eg. drivers/clocksource), you
just send all the patches to the maintainer(s) + mailing list + related
people

 2. they touch different subsystems:

   2.1) the changes are not connected (not related together), you have
to split in smaller parts and send the patches to the right subsystem
maintainer (so falling back to 1.)

   2.2) the changes are connected:

      2.2.1) Ask all the different subsystem maintainers to acknowledge
the changes and submit the patches to arm-soc@

      2.2.2) Ask each maintainer to take their part if the changes are
connected but not interdependent (patches individually won't break the
system)


You are in the 2.2) situation. My question is do you want 2.2.1) or 2.2.2) ?


-- 
 <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog