On Tue, Apr 26, 2022 at 10:15 PM Sven Peter <[email protected]> wrote:
>
> Hi,
>
> This series includes everything[*] required to get NVMe up and running on
> Apple's M1, M1 Pro and M1 Max SoCs.
>
> v1: https://lore.kernel.org/linux-nvme/[email protected]/T/
> v2: https://lore.kernel.org/linux-nvme/[email protected]/T/
>
> Thanks everyone for the reviews of v2 again! There are just some minor
> changes since v2 listed in the individual commits again.
Nice! I had not looked at v2 in much detail, but I'm perfectly happy
with this version,
I found a few things that could be improved if you do a respin, but
nothing important.
> [*] The only missing part in this series are the device tree updates
> but since these will go through arm-soc anyway I haven't included
> them here but will instead submit them once this series is in a shape
> where it can be merged.
Just as a clarification: the drivers/soc/ portion should normally go through the
soc tree as well, but I'm happy for those to get merged along with the
nvme driver
if that helps get it all mainlined more quickly.
Arnd
On Tue, Apr 26, 2022, at 23:15, Arnd Bergmann wrote:
> On Tue, Apr 26, 2022 at 10:15 PM Sven Peter <[email protected]> wrote:
>>
>> Hi,
>>
>> This series includes everything[*] required to get NVMe up and running on
>> Apple's M1, M1 Pro and M1 Max SoCs.
>>
>> v1: https://lore.kernel.org/linux-nvme/[email protected]/T/
>> v2: https://lore.kernel.org/linux-nvme/[email protected]/T/
>>
>> Thanks everyone for the reviews of v2 again! There are just some minor
>> changes since v2 listed in the individual commits again.
>
> Nice! I had not looked at v2 in much detail, but I'm perfectly happy
> with this version,
>
> I found a few things that could be improved if you do a respin, but
> nothing important.
Thanks, I'll respin it later this week to fix those things!
>
>> [*] The only missing part in this series are the device tree updates
>> but since these will go through arm-soc anyway I haven't included
>> them here but will instead submit them once this series is in a shape
>> where it can be merged.
>
> Just as a clarification: the drivers/soc/ portion should normally go through the
> soc tree as well, but I'm happy for those to get merged along with the
> nvme driver
> if that helps get it all mainlined more quickly.
Makes sense!
I don't think I'll be ready to submit USB3/USB4/Thunderbolt (which also needs
RTKit) during this cycle but I think there's a decent chance marcan will submit
SMC which also depends on RTKit and will go through a different subsystem.
What's the best way to handle the RTKit commits in that case?
It would be great if we could get both into 5.19.
Sven
On Wed, Apr 27, 2022 at 5:33 PM Sven Peter <[email protected]> wrote:
> On Tue, Apr 26, 2022, at 23:15, Arnd Bergmann wrote:
> > On Tue, Apr 26, 2022 at 10:15 PM Sven Peter <[email protected]> wrote:
>
> Makes sense!
> I don't think I'll be ready to submit USB3/USB4/Thunderbolt (which also needs
> RTKit) during this cycle but I think there's a decent chance marcan will submit
> SMC which also depends on RTKit and will go through a different subsystem.
> What's the best way to handle the RTKit commits in that case?
> It would be great if we could get both into 5.19.
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.
Arnd
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.