linux-kernel - Re: [PATCH 2/5] staging: fbtft: Deduplicate driver registration macros

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:   Thu, 27 Jan 2022 22:36:07 +0100
From:   Uwe Kleine-König <u.kleine-koenig@...gutronix.de>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     Mark Brown <broonie@...nel.org>, linux-fbdev@...r.kernel.org,
        Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
        Noralf Tronnes <notro@...nnes.org>,
        linux-staging@...ts.linux.dev, linux-kernel@...r.kernel.org,
        dri-devel@...ts.freedesktop.org, linux-spi@...r.kernel.org,
        kernel@...gutronix.de, Heiner Kallweit <hkallweit1@...il.com>
Subject: Re: [PATCH 2/5] staging: fbtft: Deduplicate driver registration
 macros

Hello Greg,

On Sun, Jan 23, 2022 at 06:51:58PM +0100, Uwe Kleine-König wrote:
> The two macros FBTFT_REGISTER_DRIVER and FBTFT_REGISTER_SPI_DRIVER
> contain quite some duplication: Both define an spi driver and an of device
> table and the differences are quite subtle.
> 
> So create two new macros and use both twice.
> 
> Link: https://lore.kernel.org/r/20220118181338.207943-2-u.kleine-koenig@pengutronix.de
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@...gutronix.de>

You picked this patch into your staging-next branch, I guess from the
original submission. Not sure how Mark wants to continue with the series
from this thread, but at least my plan was that he will create an
immutable branch on top of 5.17-rc2 (assuming 5.17-rc2 will contain
"staging: fbtft: Fix error path in fbtft_driver_module_init()") with the
remaining 4 patches in this series.

In a private mail you agreed to this procedure, but this didn't stop you
taking this patch?! What is your plan here? The obvious (to me) options
are:

 - Delay this series until after the next merge window.
 - You back out this patch from staging-next and ack here for Mark to
   apply it to an immutable branch.
 - You keep this patch in staging-next and still ack here for Mark to
   apply it to an immutable branch. Then the patch would be included
   twice.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)