public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: Pratyush Yadav <pratyush@kernel.org>
To: Miquel Raynal <miquel.raynal@bootlin.com>
Cc: Pratyush Yadav <pratyush@kernel.org>,
	 Richard Weinberger <richard@nod.at>,
	 Vignesh Raghavendra <vigneshr@ti.com>,
	 Tudor Ambarus <tudor.ambarus@linaro.org>,
	 Michael Walle <mwalle@kernel.org>,
	linux-mtd@lists.infradead.org
Subject: Re: [GIT PULL] mtd: spi-nor: changes for v6.12
Date: Sat, 14 Sep 2024 17:55:39 +0200	[thread overview]
Message-ID: <mafs0v7yy9qmc.fsf@kernel.org> (raw)
In-Reply-To: <20240913195915.4bd2a88c@xps-13> (Miquel Raynal's message of "Fri, 13 Sep 2024 19:59:15 +0200")

On Fri, Sep 13 2024, Miquel Raynal wrote:

> Hi Pratyush,
>
> pratyush@kernel.org wrote on Thu, 12 Sep 2024 12:28:57 +0200:
>
>> Hi Miquel,
>> 
>> Here are the SPI NOR changes for v6.12. I usually base my branch on top
>> of -rc1, but this time around it seems I did it a few commits after
>> v6.11-rc1. Probably just didn't notice torvalds/master had moved. Should
>> make no difference in practice anyway.
>
> I don't think I can merge your tag without the 4 minmax patches, which
> means they will appear in my final merge request to Linus, unless I
> explicitly don't use an -rc as a base, but this must be justified I
> believe. Can you please fix the branch and regenerate the tag? I don't
> mind personally if you force push, if it makes the history more clear.

TL;DR: I'll rebase and send you a new pull request.

I thought it wouldn't matter since Linus' tree already has those minmax
commits anyway. I did a test merge just now and seems I was right. When
I merge current spi-nor/next into mtd/next, and then merge mtd/next into
torvalds/master, here's the merge I get:

    Merge branch 'mtd/merge-test'

    * mtd/merge-test:
    mtd: spi-nor: fix flash probing
    mtd: powernv: Add check devm_kasprintf() returned value
    mtd: spi-nor: spansion: Add support for S28HS256T
    mtd: concat: Use kmemdup_array instead of kmemdup for multiple allocation
    mtd: parsers: bcm47xxpart: make read-only array possible_nvram_sizes static const
    mtd: Use of_property_read_bool()
    mtd: slram: insert break after errors in parsing the map
    mtd: spi-nor: winbond: add Zetta ZD25Q128C support
    mtd: spi-nor: micron-st: Add n25q064a WP support
    mtd: spi-nor: sst: Factor out common write operation to `sst_nor_write_data()`

But since mtd/next doesn't have the minmax commits, here is what the
merge of spi-nor/next into mtd/next looks like:

    Merge branch 'spi-nor/next' into mtd/merge-test

    * spi-nor/next:
    mtd: spi-nor: fix flash probing
    mtd: spi-nor: spansion: Add support for S28HS256T
    mtd: spi-nor: winbond: add Zetta ZD25Q128C support
    mtd: spi-nor: micron-st: Add n25q064a WP support
    mtd: spi-nor: sst: Factor out common write operation to `sst_nor_write_data()`
    minmax: simplify min()/max()/clamp() implementation
    minmax: don't use max() in situations that want a C constant expression
    minmax: scsi: fix mis-use of 'clamp()' in sr.c
    minmax: make generic MIN() and MAX() macros available everywhere

Essentially, your merge to Linus would be fine but my merge to your
branch will (appear to) have these extra commits.

I don't think any of this is worth the extra confusion so I will just
rebase my branch on v6.11-rc1 force push. Will send you a v2 of the pull
request soon.

Side note:

> [...]unless I explicitly don't use an -rc as a base, but this must be
> justified I believe.

I am curious why that is so. I don't see how using an -rc as base is any
better than using any other commit in Linus' tree. For git it doesn't
matter since an -rc commit is the same as any other commit. I suppose if
everyone does it, the history might be a bit cleaner, but I don't see
how it would make much of a difference in practice.

-- 
Regards,
Pratyush Yadav

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

  reply	other threads:[~2024-09-14 15:55 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-12 10:28 [GIT PULL] mtd: spi-nor: changes for v6.12 Pratyush Yadav
2024-09-13 17:59 ` Miquel Raynal
2024-09-14 15:55   ` Pratyush Yadav [this message]
2024-09-15 10:37     ` Miquel Raynal

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=mafs0v7yy9qmc.fsf@kernel.org \
    --to=pratyush@kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=miquel.raynal@bootlin.com \
    --cc=mwalle@kernel.org \
    --cc=richard@nod.at \
    --cc=tudor.ambarus@linaro.org \
    --cc=vigneshr@ti.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox