Linux MultiMedia Card development
 help / color / mirror / Atom feed
From: Christian Loehle <CLoehle@hyperstone.com>
To: Ulf Hansson <ulf.hansson@linaro.org>,
	"linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.org>,
	Marek Vasut <marex@denx.de>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH 01/11] mmc: core: Use BIT() macro
Date: Wed, 21 Jun 2023 11:23:54 +0000	[thread overview]
Message-ID: <da39a415784e4bbabfa99596ffd5b565@hyperstone.com> (raw)
In-Reply-To: <CAPDyKFoLaYegCxw35XPNWuzg_F4M-UPho=+XweB+V4oCXaMxGA@mail.gmail.com>

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



> -----Original Message-----
> From: Ulf Hansson <ulf.hansson@linaro.org>
> Sent: Mittwoch, 21. Juni 2023 11:19
> To: Marek Vasut <marex@denx.de>
> Cc: linux-mmc@vger.kernel.org; Adrian Hunter <adrian.hunter@intel.com>;
> Avri Altman <avri.altman@wdc.com>; Bo Liu <liubo03@inspur.com>; Deren
> Wu <deren.wu@mediatek.com>; Philipp Zabel <p.zabel@pengutronix.de>;
> Pierre Ossman <pierre@ossman.eu>; Russell King <linux@armlinux.org.uk>;
> Yang Yingliang <yangyingliang@huawei.com>
> Subject: Re: [PATCH 01/11] mmc: core: Use BIT() macro
> 
> CAUTION: this mail comes from external!/ACHTUNG: Diese Mail kommt von
> extern!
> 
> On Wed, 21 Jun 2023 at 04:36, Marek Vasut <marex@denx.de> wrote:
> >
> > On 6/20/23 13:15, Ulf Hansson wrote:
> > > On Tue, 20 Jun 2023 at 12:47, Marek Vasut <marex@denx.de> wrote:
> > >>
> > >> Use the BIT(n) macro instead of (1<<n), no functional change.
> > >> Regex 's@(1 \?<< \?\([0-9A-Z_]\+\))@BIT(\1)' .
> > >>
> > >> Signed-off-by: Marek Vasut <marex@denx.de>
> > >
> > > I don't think the benefit of this change is worth it. For example,
> > > it's quite useful to run a git blame to see the history of what has
> > > happened.
> >
> > Understood.
> >
> > git blame does allow you to specify either --since or revision range though.
> 
> Yes, but I think you get my point.
> 
> >
> > > So, sorry, but I am not going to pick this up - or any other similar
> > > changes, at least for the core layer.
> >
> > Is this a policy of the mmc subsystem to reject all code clean ups then ?
> 
> Of course it isn't, I regularly pick up clean ups.
> 
> My point here is that the clean-up should make the code better, in some
> way. I don't think converting to the BIT macro helps in this regard. It may be
> preferred to use the BIT macro by some and by others not.

FWIW I agree with Uffe here.
For host/ files, which are mostly written by a handful each, it's still a nuisance. (One could argue that they are often git blamed by people not familiar with mmc subsystem, thus giving off the wrong picture).
For much of the core code you already have to go many revisions back, I'm grateful for each I don't have to.
Something like the mq rework would have been a good moment to do these minor nitpicks, if something like that ever happens again, but even then I  would prefer just one commit including everything.


Regards,
Christian

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 10302 bytes --]

      parent reply	other threads:[~2023-06-21 11:24 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-20 10:47 [PATCH 01/11] mmc: core: Use BIT() macro Marek Vasut
2023-06-20 10:47 ` [PATCH 02/11] mmc: card: " Marek Vasut
2023-06-20 10:47 ` [PATCH 03/11] mmc: host: " Marek Vasut
2023-06-20 10:47 ` [PATCH 04/11] mmc: mmc: " Marek Vasut
2023-06-20 10:47 ` [PATCH 05/11] mmc: sd: " Marek Vasut
2023-06-20 10:47 ` [PATCH 06/11] mmc: sdio: " Marek Vasut
2023-06-20 10:47 ` [PATCH 07/11] mmc: mmci: " Marek Vasut
2023-06-20 10:47 ` [PATCH 08/11] mmc: pxav3: " Marek Vasut
2023-06-20 10:47 ` [PATCH 09/11] mmc: sdhci: " Marek Vasut
2023-06-20 10:47 ` [PATCH 10/11] mmc: vub300: " Marek Vasut
2023-06-20 10:47 ` [PATCH 11/11] mmc: wbsd: " Marek Vasut
2023-06-20 11:15 ` [PATCH 01/11] mmc: core: " Ulf Hansson
2023-06-21  2:36   ` Marek Vasut
2023-06-21  9:18     ` Ulf Hansson
2023-06-21 10:28       ` Marek Vasut
2023-06-21 11:23       ` Christian Loehle [this message]

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=da39a415784e4bbabfa99596ffd5b565@hyperstone.com \
    --to=cloehle@hyperstone.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=marex@denx.de \
    --cc=ulf.hansson@linaro.org \
    /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