lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 29 Apr 2022 18:37:58 +0200
From:   "Sven Peter" <sven@...npeter.dev>
To:     "hch@....de" <hch@....de>, "Arnd Bergmann" <arnd@...db.de>
Cc:     "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>,
        "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 Thu, Apr 28, 2022, at 16:24, hch@....de wrote:
> 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.

So If I understand all this correctly either
	1) I send a pull request with rtkit+sart to Arnd/soc@ followed by
	   a pull request with the same commits + the nvme driver to
	   Christoph/nvme to make sure the commit hashes in both trees
	   are the same. 
or
	2) I send a pull request with rtkit+sart+nvme to soc@ and we
	   take the entire driver through there with Christoph's ack
	   if Arnd is fine with carrying it as well.

In either case SMC (or thunderbolt if I finish in time) can also be based
on the same rtkit commit and could go into 5.19 as well.
I don't have any preference here (not that my opinion matters much
for this decision anyway :-))


Sven

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ