All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Mark Brown <broonie@kernel.org>,
	linux-fbdev@vger.kernel.org,
	Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
	Noralf Tronnes <notro@tronnes.org>,
	linux-staging@lists.linux.dev, linux-kernel@vger.kernel.org,
	dri-devel@lists.freedesktop.org, linux-spi@vger.kernel.org,
	kernel@pengutronix.de, Heiner Kallweit <hkallweit1@gmail.com>
Subject: Re: [PATCH 2/5] staging: fbtft: Deduplicate driver registration macros
Date: Thu, 27 Jan 2022 22:36:07 +0100	[thread overview]
Message-ID: <20220127213607.xbggvbm454u7qfid@pengutronix.de> (raw)
In-Reply-To: <20220123175201.34839-3-u.kleine-koenig@pengutronix.de>

[-- Attachment #1: Type: text/plain, Size: 1539 bytes --]

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@pengutronix.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/ |

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: linux-fbdev@vger.kernel.org, kernel@pengutronix.de,
	Noralf Tronnes <notro@tronnes.org>,
	linux-staging@lists.linux.dev, linux-kernel@vger.kernel.org,
	dri-devel@lists.freedesktop.org, linux-spi@vger.kernel.org,
	Mark Brown <broonie@kernel.org>,
	Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
	Heiner Kallweit <hkallweit1@gmail.com>
Subject: Re: [PATCH 2/5] staging: fbtft: Deduplicate driver registration macros
Date: Thu, 27 Jan 2022 22:36:07 +0100	[thread overview]
Message-ID: <20220127213607.xbggvbm454u7qfid@pengutronix.de> (raw)
In-Reply-To: <20220123175201.34839-3-u.kleine-koenig@pengutronix.de>

[-- Attachment #1: Type: text/plain, Size: 1539 bytes --]

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@pengutronix.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/ |

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  reply	other threads:[~2022-01-27 21:36 UTC|newest]

Thread overview: 73+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-23 17:51 [PATCH 0/5] spi: make remove callback a void function Uwe Kleine-König
2022-01-23 17:51 ` Uwe Kleine-König
2022-01-23 17:51 ` Uwe Kleine-König
2022-01-23 17:51 ` [PATCH 1/5] staging: fbtft: Fix error path in fbtft_driver_module_init() Uwe Kleine-König
2022-01-23 17:51   ` Uwe Kleine-König
2022-01-23 17:51 ` [PATCH 2/5] staging: fbtft: Deduplicate driver registration macros Uwe Kleine-König
2022-01-23 17:51   ` Uwe Kleine-König
2022-01-27 21:36   ` Uwe Kleine-König [this message]
2022-01-27 21:36     ` Uwe Kleine-König
2022-01-28  7:16     ` Greg Kroah-Hartman
2022-01-28  7:16       ` Greg Kroah-Hartman
2022-01-23 17:51 ` [PATCH 3/5] tpm: st33zp24: Make st33zp24_remove() a void function Uwe Kleine-König
2022-01-23 17:52 ` [PATCH 4/5] platform/chrome: cros_ec: Make cros_ec_unregister() return void Uwe Kleine-König
2022-01-23 17:52 ` [PATCH 5/5] spi: make remove callback a void function Uwe Kleine-König
2022-01-23 17:52   ` Uwe Kleine-König
2022-01-23 17:52   ` Uwe Kleine-König
2022-01-23 22:49   ` Marc Kleine-Budde
2022-01-24 12:23   ` Andy Shevchenko
2022-01-24 12:23     ` Andy Shevchenko
2022-01-24 12:23     ` Andy Shevchenko
2022-01-24 12:23     ` Andy Shevchenko
2022-01-25  9:35   ` Alexandre Belloni
2022-01-25  9:35     ` Alexandre Belloni
2022-01-25  9:35     ` Alexandre Belloni
2022-01-25  9:35     ` Alexandre Belloni
2022-01-25  9:44   ` Stefan Schmidt
2022-01-25  9:44     ` Stefan Schmidt
2022-01-25  9:44     ` Stefan Schmidt
2022-01-25  9:44     ` Stefan Schmidt
2022-01-25  9:47   ` Jonathan Cameron
2022-01-25  9:47     ` Jonathan Cameron
2022-01-25  9:47     ` Jonathan Cameron
2022-01-25  9:47     ` Jonathan Cameron
2022-01-25 10:29     ` Uwe Kleine-König
2022-01-25 10:29       ` Uwe Kleine-König
2022-01-25 10:29       ` Uwe Kleine-König
2022-01-25 10:29       ` Uwe Kleine-König
2022-01-25 10:19   ` Miquel Raynal
2022-01-25 10:19     ` Miquel Raynal
2022-01-25 10:19     ` Miquel Raynal
2022-01-25 10:19     ` Miquel Raynal
2022-01-25 10:25   ` Claudius Heine
2022-01-25 10:25     ` Claudius Heine
2022-01-25 10:25     ` Claudius Heine
2022-01-25 10:25     ` Claudius Heine
2022-01-25 10:37   ` Geert Uytterhoeven
2022-01-25 10:37     ` Geert Uytterhoeven
2022-01-25 10:37     ` Geert Uytterhoeven
2022-01-25 10:37     ` Geert Uytterhoeven
     [not found]   ` <CGME20220125124340eucas1p2504c36206c5c17f63663a814fc8f7feb@eucas1p2.samsung.com>
2022-01-25 12:43     ` Lukasz Stelmach
2022-01-25 14:16   ` Jérôme Pouiller
2022-01-25 14:16     ` Jérôme Pouiller
2022-01-25 14:16     ` Jérôme Pouiller
2022-01-27 11:39   ` Ulf Hansson
2022-01-27 13:41   ` Marcus Folkesson
2022-02-08 13:39   ` Mark Brown
2022-02-08 13:39     ` Mark Brown
2022-02-08 13:39     ` Mark Brown
2022-02-08 13:39     ` Mark Brown
2022-02-18 12:37   ` Hans Verkuil
2022-02-18 12:37     ` Hans Verkuil
2022-02-18 12:37     ` Hans Verkuil
2022-02-18 12:37     ` Hans Verkuil
2022-03-02  7:30   ` Pavel Machek
2022-03-02  7:30     ` Pavel Machek
2022-03-02  7:30     ` Pavel Machek
2022-03-02  7:30     ` Pavel Machek
2022-01-25  9:30 ` [PATCH 0/5] " Lee Jones
2022-01-25  9:30   ` Lee Jones
2022-01-25  9:30   ` Lee Jones
2022-01-25  9:30   ` Lee Jones
2022-02-09 14:34 ` Mark Brown
2022-02-09 14:34   ` Mark Brown

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=20220127213607.xbggvbm454u7qfid@pengutronix.de \
    --to=u.kleine-koenig@pengutronix.de \
    --cc=broonie@kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=hkallweit1@gmail.com \
    --cc=kernel@pengutronix.de \
    --cc=linux-fbdev@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-spi@vger.kernel.org \
    --cc=linux-staging@lists.linux.dev \
    --cc=notro@tronnes.org \
    --cc=thomas.petazzoni@bootlin.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.