[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220428142412.GA19708@lst.de>
Date: Thu, 28 Apr 2022 16:24:12 +0200
From: "hch@....de" <hch@....de>
To: Arnd Bergmann <arnd@...db.de>
Cc: Sven Peter <sven@...npeter.dev>, Hector Martin <marcan@...can.st>,
Alyssa Rosenzweig <alyssa@...enzweig.io>,
Rob Herring <robh+dt@...nel.org>,
Krzysztof Kozlowski <krzk+dt@...nel.org>,
Keith Busch <kbusch@...nel.org>, "axboe@...com" <axboe@...com>,
"hch@....de" <hch@....de>, "sagi@...mberg.me" <sagi@...mberg.me>,
Marc Zyngier <maz@...nel.org>, Janne Grunau <j@...nau.net>,
DTML <devicetree@...r.kernel.org>,
Linux ARM <linux-arm-kernel@...ts.infradead.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
linux-nvme@...ts.infradead.org
Subject: Re: [PATCH v3 0/6] Apple M1 (Pro/Max) NVMe driver
On Wed, Apr 27, 2022 at 07:39:49PM +0200, Arnd Bergmann wrote:
> The usual trick is to have a branch with the shared patches and have
> that pulled into every other tree that needs these, but make sure you never
> rebase. In this case, you could have something like
>
> a) rtkit driver in a shared branch (private only)
> b) thunderbolt driver based on branch a), merged through
> thunderbolt/usb/pci tree (I don't know who is responsible here)
> c) sart driver based on branch a), merged through soc tree
> d) nvme driver based on branch c), merged through nvme tree
>
> since the commit hashes are all identical, each patch only shows up in
> the git tree once, but you get a somewhat funny history.
Given that the nvme driver is just addition of new code I'm perfectly
fine with sending it through whatever tree is most convenient.
Powered by blists - more mailing lists