[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <95af46d6-d123-f610-2f21-6d6de6f248e9@redhat.com>
Date: Sun, 10 Jan 2021 11:43:54 -0800
From: Tom Rix <trix@...hat.com>
To: Moritz Fischer <mdf@...nel.org>
Cc: gregkh@...uxfoundation.org,
"linux-fpga@...r.kernel.org" <linux-fpga@...r.kernel.org>,
linux-kernel@...r.kernel.org, moritzf@...gle.com,
Rikard Falkeborn <rikard.falkeborn@...il.com>,
Zheng Yongjun <zhengyongjun3@...wei.com>,
Russ Weight <russell.h.weight@...el.com>,
"Gerlach, Matthew" <matthew.gerlach@...el.com>,
Sonal Santan <sonal.santan@...inx.com>,
Xu Yilun <yilun.xu@...el.com>,
Richard Gong <richard.gong@...el.com>
Subject: Re: [PATCH 0/8] FPGA DFL Changes for 5.12
On 1/10/21 9:05 AM, Moritz Fischer wrote:
> Tom,
>
> On Sun, Jan 10, 2021 at 07:46:29AM -0800, Tom Rix wrote:
>> On 1/7/21 8:09 AM, Tom Rix wrote:
>>> On 1/6/21 8:37 PM, Moritz Fischer wrote:
>>>> This is a resend of the previous (unfortunately late) patchset of
>>>> changes for FPGA DFL.
>>> Is there something I can do to help ?
>>>
>>> I am paid to look after linux-fpga, so i have plenty of time.
>>>
>>> Some ideas of what i am doing now privately i can do publicly.
>>>
>>> 1. keep linux-fpga sync-ed to greg's branch so linux-fpga is normally in a pullable state.
> Is it not? It currently points to v5.11-rc1. If I start applying patches
> that require the changes that went into Greg's branch I can merge.
I mean the window between when we have staged patches and when they go into Greg's branch.
We don't have any now, maybe those two trival ones.
Since Greg's branch moves much faster than ours, our staging branch needs to be rebased regularly until its merge.
There are no outstanding fixes so all changes would go to -next.
>>> 2. an in-flight dev branch for the outstanding patches
>> I have setup these branches based on Greg's char-misc-next
>>
>> fpga-next, which is char-misc-next base for fpga-testing
>>
>> fpga-testing, all the in-flight patches that would apply with automatic merge conflict resolution
>>
>> These are respectively
>>
>> https://github.com/trixirt/linux-fpga/tree/fpga-next
>>
>> https://github.com/trixirt/linux-fpga/tree/fpga-testing
> Feel free to have your own repos/branches etc, but I'd like to keep the
> offical trees on kernel.org.
Is there a way for me to move these to kernel.org ?
>
> Tbh I'd much rather see the patchwork instance be cleaned up if you want
> to do stuff.
Please point me at the wreckage and I will clean it up.
>>
>> There are two trivial changes, that could go to 5.12 now.
>>
>> fpga: dfl: fme: Constify static attribute_group structs
>>
>> fpga: Use DEFINE_SPINLOCK() for spinlock
>>
>> respectively
>>
>> https://lore.kernel.org/linux-fpga/20210108235414.48017-1-rikard.falkeborn@gmail.com/
>>
>> https://lore.kernel.org/linux-fpga/20201228135135.28788-1-zhengyongjun3@huawei.com/
> I was going to pick them up monday ...
>>
>> There are a couple of patchsets that conflict
>>
>> https://lore.kernel.org/linux-fpga/20210105230855.15019-7-russell.h.weight@intel.com/
>>
>> https://lore.kernel.org/linux-fpga/20201203171548.1538178-3-matthew.gerlach@linux.intel.com/
> Conflict between what and what?
There are basic git am ... applying problems.
By having a -testing branch it is easier to see where the conficts with all the outstanding patchsets.
>
>> And the xilinx patchset
>>
>> https://lore.kernel.org/linux-fpga/20201217075046.28553-1-sonals@xilinx.com/
>>
>> Which is being split/worked on offline.
> I'm not sure what that means.
Don't worry about this until a new patchset lands.
Tom
>>
>> If I have missed any patchset, poke me.
>>
>> Tom
> - Moritz
>
Powered by blists - more mailing lists