[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID:
<DM4PR12MB7693C526AE5D9DE4A09B4BBFDC4A2@DM4PR12MB7693.namprd12.prod.outlook.com>
Date: Mon, 28 Oct 2024 06:41:57 +0000
From: "Mahapatra, Amit Kumar" <amit.kumar-mahapatra@....com>
To: Krzysztof Kozlowski <krzk@...nel.org>, "tudor.ambarus@...aro.org"
<tudor.ambarus@...aro.org>, "michael@...le.cc" <michael@...le.cc>,
"broonie@...nel.org" <broonie@...nel.org>, "pratyush@...nel.org"
<pratyush@...nel.org>, "richard@....at" <richard@....at>, "vigneshr@...com"
<vigneshr@...com>, "miquel.raynal@...tlin.com" <miquel.raynal@...tlin.com>,
"robh@...nel.org" <robh@...nel.org>, "conor+dt@...nel.org"
<conor+dt@...nel.org>, "krzk+dt@...nel.org" <krzk+dt@...nel.org>
CC: "Abbarapu, Venkatesh" <venkatesh.abbarapu@....com>,
"linux-spi@...r.kernel.org" <linux-spi@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-mtd@...ts.infradead.org" <linux-mtd@...ts.infradead.org>,
"nicolas.ferre@...rochip.com" <nicolas.ferre@...rochip.com>,
"alexandre.belloni@...tlin.com" <alexandre.belloni@...tlin.com>,
"claudiu.beznea@...on.dev" <claudiu.beznea@...on.dev>, "Simek, Michal"
<michal.simek@....com>, "linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>, "alsa-devel@...a-project.org"
<alsa-devel@...a-project.org>, "patches@...nsource.cirrus.com"
<patches@...nsource.cirrus.com>, "git (AMD-Xilinx)" <git@....com>,
"amitrkcian2002@...il.com" <amitrkcian2002@...il.com>, "beanhuo@...ron.com"
<beanhuo@...ron.com>
Subject: RE: [RFC PATCH 1/2] dt-bindings: mtd: Add bindings for describing
concatinated MTD devices
Hello Krzysztof
> > This approach was suggested by Rob [1] during a discussion on Miquel's
> > initial approach [2] to extend the MTD-CONCAT driver to support
> > stacked memories.
> > Define each flash node separately with its respective partitions, and
> > add a 'concat-parts' binding to link the partitions of the two flash
> > nodes that need to be concatenated.
>
> I understand this was not sent to proper addresses for review because it is a RFC.
Yes, that’s correct.
Regards,
Amit
> It's fine then.
>
> If this was not the intention and this should be reviewed (and tested, although I
> assume you tested these patches first), then please read the standard form bellow:
>
> <form letter>
> Please use scripts/get_maintainers.pl to get a list of necessary people and lists to
> CC. It might happen, that command when run on an older kernel, gives you outdated
> entries. Therefore please be sure you base your patches on recent Linux kernel.
>
> Tools like b4 or scripts/get_maintainer.pl provide you proper list of people, so fix your
> workflow. Tools might also fail if you work on some ancient tree (don't, instead use
> mainline) or work on fork of kernel (don't, instead use mainline). Just use b4 and
> everything should be fine, although remember about `b4 prep --auto-to-cc` if you
> added new patches to the patchset.
>
> You missed at least devicetree list (maybe more), so this won't be tested by
> automated tooling. Performing review on untested code might be a waste of time.
>
> Please kindly resend and include all necessary To/Cc entries.
> </form letter>
>
> Best regards,
> Krzysztof
Powered by blists - more mailing lists