LinuxLists.cc - [PATCH 0/8] FPGA DFL Changes for 5.12

[permalink] [raw]

Subject: [PATCH 3/8] fpga: dfl: fix the definitions of type & feature_id for dfl devices

From: Xu Yilun <[email protected]>

The value of the field dfl_device.type comes from the 12 bits register
field DFH_ID according to DFL spec. So this patch changes the definition
of the type field to u16.

Also it is not necessary to illustrate the valid bits of the type field
in comments. Instead we should explicitly define the possible values in
the enumeration type for it, because they are shared by hardware spec.
We should not let the compiler decide these values.

Similar changes are also applied to dfl_device.feature_id.

This patch also fixed the MODALIAS format according to the changes
above.

Signed-off-by: Xu Yilun <[email protected]>
Reviewed-by: Tom Rix <[email protected]>
Signed-off-by: Moritz Fischer <[email protected]>
---
drivers/fpga/dfl.c | 3 +--
drivers/fpga/dfl.h | 14 +++++++-------
2 files changed, 8 insertions(+), 9 deletions(-)

diff --git a/drivers/fpga/dfl.c b/drivers/fpga/dfl.c
index b450870b75ed..5a6ba3b2fa05 100644
--- a/drivers/fpga/dfl.c
+++ b/drivers/fpga/dfl.c
@@ -298,8 +298,7 @@ static int dfl_bus_uevent(struct device *dev, struct kobj_uevent_env *env)
{
struct dfl_device *ddev = to_dfl_dev(dev);

- /* The type has 4 valid bits and feature_id has 12 valid bits */
- return add_uevent_var(env, "MODALIAS=dfl:t%01Xf%03X",
+ return add_uevent_var(env, "MODALIAS=dfl:t%04Xf%04X",
ddev->type, ddev->feature_id);
}

diff --git a/drivers/fpga/dfl.h b/drivers/fpga/dfl.h
index 5dc758f655b7..ac373b1fcff9 100644
--- a/drivers/fpga/dfl.h
+++ b/drivers/fpga/dfl.h
@@ -520,19 +520,19 @@ long dfl_feature_ioctl_set_irq(struct platform_device *pdev,
* enum dfl_id_type - define the DFL FIU types
*/
enum dfl_id_type {
- FME_ID,
- PORT_ID,
+ FME_ID = 0,
+ PORT_ID = 1,
DFL_ID_MAX,
};

/**
* struct dfl_device_id - dfl device identifier
- * @type: contains 4 bits DFL FIU type of the device. See enum dfl_id_type.
- * @feature_id: contains 12 bits feature identifier local to its DFL FIU type.
+ * @type: DFL FIU type of the device. See enum dfl_id_type.
+ * @feature_id: feature identifier local to its DFL FIU type.
* @driver_data: driver specific data.
*/
struct dfl_device_id {
- u8 type;
+ u16 type;
u16 feature_id;
unsigned long driver_data;
};
@@ -543,7 +543,7 @@ struct dfl_device_id {
* @dev: generic device interface.
* @id: id of the dfl device.
* @type: type of DFL FIU of the device. See enum dfl_id_type.
- * @feature_id: 16 bits feature identifier local to its DFL FIU type.
+ * @feature_id: feature identifier local to its DFL FIU type.
* @mmio_res: mmio resource of this dfl device.
* @irqs: list of Linux IRQ numbers of this dfl device.
* @num_irqs: number of IRQs supported by this dfl device.
@@ -553,7 +553,7 @@ struct dfl_device_id {
struct dfl_device {
struct device dev;
int id;
- u8 type;
+ u16 type;
u16 feature_id;
struct resource mmio_res;
int *irqs;
--
2.30.0

2021-01-07 16:11:51

[permalink] [raw]

Subject: Re: [PATCH 0/8] FPGA DFL Changes for 5.12

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.

2. an in-flight dev branch for the outstanding patches

Tom

2021-01-07 16:15:24

[permalink] [raw]

Subject: Re: [PATCH 0/8] FPGA DFL Changes for 5.12

On Thu, Jan 07, 2021 at 08:09:12AM -0800, 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 ?

This is all now merged in my tree, so there's not much left to do here
:)

thanks,

greg k-h

2021-01-07 17:05:21

[permalink] [raw]

Subject: Re: [PATCH 0/8] FPGA DFL Changes for 5.12

On 1/7/21 8:14 AM, Greg KH wrote:
> On Thu, Jan 07, 2021 at 08:09:12AM -0800, 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 ?
> This is all now merged in my tree, so there's not much left to do here
> :)

Yes this patchset is done now.

I am offering to help in an ongoing manner, something like 10hr/week would be easy as i already spend about 30hr/week doing stuff in the kernel in addition to reviewing linux-fpga.

Tom

> thanks,
>
> greg k-h
>

2021-01-10 15:51:29

[permalink] [raw]

Subject: Re: [PATCH 0/8] FPGA DFL Changes for 5.12

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.
>
> 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

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/[email protected]/

https://lore.kernel.org/linux-fpga/[email protected]/

There are a couple of patchsets that conflict

https://lore.kernel.org/linux-fpga/[email protected]/

https://lore.kernel.org/linux-fpga/[email protected]/

Which I will follow up on.

And the xilinx patchset

https://lore.kernel.org/linux-fpga/[email protected]/

Which is being split/worked on offline.

If I have missed any patchset, poke me.

Tom

>
> Tom
>
>

2021-01-10 17:11:24

[permalink] [raw]

Subject: Re: [PATCH 0/8] FPGA DFL Changes for 5.12

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.
> >
> > 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.

Tbh I'd much rather see the patchwork instance be cleaned up if you want
to do stuff.
>
>
> 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/[email protected]/
>
> https://lore.kernel.org/linux-fpga/[email protected]/

I was going to pick them up monday ...
>
>
> There are a couple of patchsets that conflict
>
> https://lore.kernel.org/linux-fpga/[email protected]/
>
> https://lore.kernel.org/linux-fpga/[email protected]/

Conflict between what and what?

> And the xilinx patchset
>
> https://lore.kernel.org/linux-fpga/[email protected]/
>
> Which is being split/worked on offline.

I'm not sure what that means.
>
>
> If I have missed any patchset, poke me.
>
> Tom

- Moritz

2021-01-10 19:47:57

[permalink] [raw]

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/[email protected]/
>>
>> https://lore.kernel.org/linux-fpga/[email protected]/
> I was going to pick them up monday ...
>>
>> There are a couple of patchsets that conflict
>>
>> https://lore.kernel.org/linux-fpga/[email protected]/
>>
>> https://lore.kernel.org/linux-fpga/[email protected]/
> 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/[email protected]/
>>
>> 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
>

2021-01-11 07:17:34

[permalink] [raw]

Subject: Re: [PATCH 0/8] FPGA DFL Changes for 5.12

On Sun, Jan 10, 2021 at 11:43:54AM -0800, Tom Rix wrote:
>
> 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.

Ick, no! NEVER rebase a public branch. Why does it matter the speed of
my branch vs. anyone elses? Git handles merges very well.

Just like Linus's branches move much faster than mine, and I don't
rebase my branches, you shouldn't rebase yours.

Becides, I'm only taking _PATCHES_ for fpga changes at the moment, no
git pulls, so why does it matter at all for any of this?

What is the problem you are trying to solve here?

thanks,

greg k-h

2021-01-11 14:44:49

[permalink] [raw]

Subject: Re: [PATCH 0/8] FPGA DFL Changes for 5.12

On 1/10/21 10:57 PM, Greg KH wrote:
> On Sun, Jan 10, 2021 at 11:43:54AM -0800, Tom Rix wrote:
>> 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.
> Ick, no! NEVER rebase a public branch. Why does it matter the speed of
> my branch vs. anyone elses? Git handles merges very well.
>
> Just like Linus's branches move much faster than mine, and I don't
> rebase my branches, you shouldn't rebase yours.
>
> Becides, I'm only taking _PATCHES_ for fpga changes at the moment, no
> git pulls, so why does it matter at all for any of this?
>
> What is the problem you are trying to solve here?

This 5.12 fpga patchset not making it into 5.11.

At some point before the 5.11 window, I tried it on next and it failed to merge.

This points to needing some c/i so it does not happen again.

Tom

>
> thanks,
>
> greg k-h
>

2021-01-11 14:58:02

[permalink] [raw]

Subject: Re: [PATCH 0/8] FPGA DFL Changes for 5.12

On Mon, Jan 11, 2021 at 06:40:24AM -0800, Tom Rix wrote:
>
> On 1/10/21 10:57 PM, Greg KH wrote:
> > On Sun, Jan 10, 2021 at 11:43:54AM -0800, Tom Rix wrote:
> >> 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.
> > Ick, no! NEVER rebase a public branch. Why does it matter the speed of
> > my branch vs. anyone elses? Git handles merges very well.
> >
> > Just like Linus's branches move much faster than mine, and I don't
> > rebase my branches, you shouldn't rebase yours.
> >
> > Becides, I'm only taking _PATCHES_ for fpga changes at the moment, no
> > git pulls, so why does it matter at all for any of this?
> >
> > What is the problem you are trying to solve here?
>
> This 5.12 fpga patchset not making it into 5.11.

Ok, but isn't it the responsibility of the submitter to make sure they
apply properly when sending them out?

> At some point before the 5.11 window, I tried it on next and it failed to merge.
>
> This points to needing some c/i so it does not happen again.

"again"? Merges and the like are a totally normal thing and happen all
the time, I still fail to understand what you are trying to "solve" for
here...

thanks,

greg k-h

2021-01-11 16:01:22

[permalink] [raw]

Subject: Re: [PATCH 0/8] FPGA DFL Changes for 5.12

On 1/11/21 6:54 AM, Greg KH wrote:
> On Mon, Jan 11, 2021 at 06:40:24AM -0800, Tom Rix wrote:
>> On 1/10/21 10:57 PM, Greg KH wrote:
>>> On Sun, Jan 10, 2021 at 11:43:54AM -0800, Tom Rix wrote:
>>>> 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.
>>> Ick, no! NEVER rebase a public branch. Why does it matter the speed of
>>> my branch vs. anyone elses? Git handles merges very well.
>>>
>>> Just like Linus's branches move much faster than mine, and I don't
>>> rebase my branches, you shouldn't rebase yours.
>>>
>>> Becides, I'm only taking _PATCHES_ for fpga changes at the moment, no
>>> git pulls, so why does it matter at all for any of this?
>>>
>>> What is the problem you are trying to solve here?
>> This 5.12 fpga patchset not making it into 5.11.
> Ok, but isn't it the responsibility of the submitter to make sure they
> apply properly when sending them out?
>
>> At some point before the 5.11 window, I tried it on next and it failed to merge.
>>
>> This points to needing some c/i so it does not happen again.
> "again"? Merges and the like are a totally normal thing and happen all
> the time, I still fail to understand what you are trying to "solve" for
> here...

What can I do to help make your merges as easy as possible ?

Does the patchwork infra Moritz was speaking of earlier need fixing help?

Any other things ?

Tom

>
> thanks,
>
> greg k-h
>

2021-01-11 16:11:12

[permalink] [raw]

Subject: Re: [PATCH 0/8] FPGA DFL Changes for 5.12

On Mon, Jan 11, 2021 at 07:55:24AM -0800, Tom Rix wrote:
>
> On 1/11/21 6:54 AM, Greg KH wrote:
> > On Mon, Jan 11, 2021 at 06:40:24AM -0800, Tom Rix wrote:
> >> On 1/10/21 10:57 PM, Greg KH wrote:
> >>> On Sun, Jan 10, 2021 at 11:43:54AM -0800, Tom Rix wrote:
> >>>> 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.
> >>> Ick, no! NEVER rebase a public branch. Why does it matter the speed of
> >>> my branch vs. anyone elses? Git handles merges very well.
> >>>
> >>> Just like Linus's branches move much faster than mine, and I don't
> >>> rebase my branches, you shouldn't rebase yours.
> >>>
> >>> Becides, I'm only taking _PATCHES_ for fpga changes at the moment, no
> >>> git pulls, so why does it matter at all for any of this?
> >>>
> >>> What is the problem you are trying to solve here?
> >> This 5.12 fpga patchset not making it into 5.11.
> > Ok, but isn't it the responsibility of the submitter to make sure they
> > apply properly when sending them out?
> >
> >> At some point before the 5.11 window, I tried it on next and it failed to merge.
> >>
> >> This points to needing some c/i so it does not happen again.
> > "again"? Merges and the like are a totally normal thing and happen all
> > the time, I still fail to understand what you are trying to "solve" for
> > here...
>
> What can I do to help make your merges as easy as possible ?

I have not had any problems with merges, I've only had "problems"
rejecting patches for their content.

Try helping out with patch reviews if you want, finding and fixing
things before I review them is usually a good idea :)

> Does the patchwork infra Moritz was speaking of earlier need fixing help?

No idea, I don't use it.

> Any other things ?

What problems are you trying to solve here? What's wrong with how this
subsystem is working that you are feeling needs to be addressed?

confused,

greg k-h

2021-01-11 16:48:10

[permalink] [raw]

Subject: Re: [PATCH 0/8] FPGA DFL Changes for 5.12

On 1/11/21 8:09 AM, Greg KH wrote:
> On Mon, Jan 11, 2021 at 07:55:24AM -0800, Tom Rix wrote:
>> On 1/11/21 6:54 AM, Greg KH wrote:
>>> On Mon, Jan 11, 2021 at 06:40:24AM -0800, Tom Rix wrote:
>>>> On 1/10/21 10:57 PM, Greg KH wrote:
>>>>> On Sun, Jan 10, 2021 at 11:43:54AM -0800, Tom Rix wrote:
>>>>>> 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.
>>>>> Ick, no! NEVER rebase a public branch. Why does it matter the speed of
>>>>> my branch vs. anyone elses? Git handles merges very well.
>>>>>
>>>>> Just like Linus's branches move much faster than mine, and I don't
>>>>> rebase my branches, you shouldn't rebase yours.
>>>>>
>>>>> Becides, I'm only taking _PATCHES_ for fpga changes at the moment, no
>>>>> git pulls, so why does it matter at all for any of this?
>>>>>
>>>>> What is the problem you are trying to solve here?
>>>> This 5.12 fpga patchset not making it into 5.11.
>>> Ok, but isn't it the responsibility of the submitter to make sure they
>>> apply properly when sending them out?
>>>
>>>> At some point before the 5.11 window, I tried it on next and it failed to merge.
>>>>
>>>> This points to needing some c/i so it does not happen again.
>>> "again"? Merges and the like are a totally normal thing and happen all
>>> the time, I still fail to understand what you are trying to "solve" for
>>> here...
>> What can I do to help make your merges as easy as possible ?
> I have not had any problems with merges, I've only had "problems"
> rejecting patches for their content.
>
> Try helping out with patch reviews if you want, finding and fixing
> things before I review them is usually a good idea :)
ok.
>
>> Does the patchwork infra Moritz was speaking of earlier need fixing help?
> No idea, I don't use it.
>
>> Any other things ?
> What problems are you trying to solve here? What's wrong with how this
> subsystem is working that you are feeling needs to be addressed?

I do not believe the issue I raised in 5.10 has made any progress.

If you look at the content in 5.11 we have actually regressed.

https://lore.kernel.org/linux-fpga/[email protected]/

Over the last two releases, I have shown i have the time and interest to maintain this subsystem.

So I am asking for

diff --git a/MAINTAINERS b/MAINTAINERS
index 11b38acb4c08..269cd08f4969 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6951,7 +6951,7 @@ F:        drivers/net/ethernet/nvidia/*

FPGA DFL DRIVERS
M:     Wu Hao <[email protected]>
-R:     Tom Rix <[email protected]>
+M:     Tom Rix <[email protected]>
L:     [email protected]
S:     Maintained
F:     Documentation/ABI/testing/sysfs-bus-dfl*
@@ -6962,7 +6962,7 @@ F:        include/uapi/linux/fpga-dfl.h

FPGA MANAGER FRAMEWORK
M:     Moritz Fischer <[email protected]>
-R:     Tom Rix <[email protected]>
+M:     Tom Rix <[email protected]>
L:     [email protected]
S:     Maintained
W:     http://www.rocketboards.org

And to use/maintain my fpga-next and fpga-testing as official kernel.org branches.

Tom

>
> confused,
>
> greg k-h
>

2021-01-11 18:28:14

[permalink] [raw]

Subject: Re: [PATCH 0/8] FPGA DFL Changes for 5.12

On Mon, Jan 11, 2021 at 08:43:15AM -0800, Tom Rix wrote:
>
> On 1/11/21 8:09 AM, Greg KH wrote:
> > On Mon, Jan 11, 2021 at 07:55:24AM -0800, Tom Rix wrote:
> >> On 1/11/21 6:54 AM, Greg KH wrote:
> >>> On Mon, Jan 11, 2021 at 06:40:24AM -0800, Tom Rix wrote:
> >>>> On 1/10/21 10:57 PM, Greg KH wrote:
> >>>>> On Sun, Jan 10, 2021 at 11:43:54AM -0800, Tom Rix wrote:
> >>>>>> 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.
> >>>>> Ick, no! NEVER rebase a public branch. Why does it matter the speed of
> >>>>> my branch vs. anyone elses? Git handles merges very well.
> >>>>>
> >>>>> Just like Linus's branches move much faster than mine, and I don't
> >>>>> rebase my branches, you shouldn't rebase yours.
> >>>>>
> >>>>> Becides, I'm only taking _PATCHES_ for fpga changes at the moment, no
> >>>>> git pulls, so why does it matter at all for any of this?
> >>>>>
> >>>>> What is the problem you are trying to solve here?
> >>>> This 5.12 fpga patchset not making it into 5.11.
> >>> Ok, but isn't it the responsibility of the submitter to make sure they
> >>> apply properly when sending them out?
> >>>
> >>>> At some point before the 5.11 window, I tried it on next and it failed to merge.
> >>>>
> >>>> This points to needing some c/i so it does not happen again.
> >>> "again"? Merges and the like are a totally normal thing and happen all
> >>> the time, I still fail to understand what you are trying to "solve" for
> >>> here...
> >> What can I do to help make your merges as easy as possible ?
> > I have not had any problems with merges, I've only had "problems"
> > rejecting patches for their content.
> >
> > Try helping out with patch reviews if you want, finding and fixing
> > things before I review them is usually a good idea :)
> ok.
> >
> >> Does the patchwork infra Moritz was speaking of earlier need fixing help?
> > No idea, I don't use it.
> >
> >> Any other things ?
> > What problems are you trying to solve here? What's wrong with how this
> > subsystem is working that you are feeling needs to be addressed?
>
> I do not believe the issue I raised in 5.10 has made any progress.

What issue?

> If you look at the content in 5.11 we have actually regressed.

What bugs regressed?

> https://lore.kernel.org/linux-fpga/[email protected]/

I don't see the problem here, other than a low-quality of patches that
need reworking for some patchsets, and others are just fine. Just like
all kernel subsystems, I don't see anything odd here.

> Over the last two releases, I have shown i have the time and interest to maintain this subsystem.

That's not how any of this works :)

> So I am asking for
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 11b38acb4c08..269cd08f4969 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -6951,7 +6951,7 @@ F:??????? drivers/net/ethernet/nvidia/*
> ?
> ?FPGA DFL DRIVERS
> ?M:???? Wu Hao <[email protected]>
> -R:???? Tom Rix <[email protected]>
> +M:???? Tom Rix <[email protected]>

That's generous, but how about doing review first, the maintainership of
this subsystem does not feel like any sort of bottleneck to me. I
personally have no problems with Moritz's interactions with the
community, his reviewing of patches, and forwarding on to me.

Of course we all have delays as we have other work to do than just this,
that's just part of normal development. I don't see anything stalled at
the moment, nor anything that having another maintainer would have
helped out with at all, so this feels like it is not needed from my end.

Again, it feels like the developers need more reviews, and good ones, so
please continue to help out with that, as that's the best thing I can
see to do here.

thanks,

greg k-h

2021-01-11 19:49:50

[permalink] [raw]

Subject: Re: [PATCH 0/8] FPGA DFL Changes for 5.12

On 1/11/21 10:21 AM, Greg KH wrote:
> On Mon, Jan 11, 2021 at 08:43:15AM -0800, Tom Rix wrote:
>> On 1/11/21 8:09 AM, Greg KH wrote:
>>> On Mon, Jan 11, 2021 at 07:55:24AM -0800, Tom Rix wrote:
>>>> On 1/11/21 6:54 AM, Greg KH wrote:
>>>>> On Mon, Jan 11, 2021 at 06:40:24AM -0800, Tom Rix wrote:
>>>>>> On 1/10/21 10:57 PM, Greg KH wrote:
>>>>>>> On Sun, Jan 10, 2021 at 11:43:54AM -0800, Tom Rix wrote:
>>>>>>>> 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.
>>>>>>> Ick, no! NEVER rebase a public branch. Why does it matter the speed of
>>>>>>> my branch vs. anyone elses? Git handles merges very well.
>>>>>>>
>>>>>>> Just like Linus's branches move much faster than mine, and I don't
>>>>>>> rebase my branches, you shouldn't rebase yours.
>>>>>>>
>>>>>>> Becides, I'm only taking _PATCHES_ for fpga changes at the moment, no
>>>>>>> git pulls, so why does it matter at all for any of this?
>>>>>>>
>>>>>>> What is the problem you are trying to solve here?
>>>>>> This 5.12 fpga patchset not making it into 5.11.
>>>>> Ok, but isn't it the responsibility of the submitter to make sure they
>>>>> apply properly when sending them out?
>>>>>
>>>>>> At some point before the 5.11 window, I tried it on next and it failed to merge.
>>>>>>
>>>>>> This points to needing some c/i so it does not happen again.
>>>>> "again"? Merges and the like are a totally normal thing and happen all
>>>>> the time, I still fail to understand what you are trying to "solve" for
>>>>> here...
>>>> What can I do to help make your merges as easy as possible ?
>>> I have not had any problems with merges, I've only had "problems"
>>> rejecting patches for their content.
>>>
>>> Try helping out with patch reviews if you want, finding and fixing
>>> things before I review them is usually a good idea :)
>> ok.
>>>> Does the patchwork infra Moritz was speaking of earlier need fixing help?
>>> No idea, I don't use it.
>>>
>>>> Any other things ?
>>> What problems are you trying to solve here? What's wrong with how this
>>> subsystem is working that you are feeling needs to be addressed?
>> I do not believe the issue I raised in 5.10 has made any progress.
> What issue?
>
>> If you look at the content in 5.11 we have actually regressed.
> What bugs regressed?
>
>> https://lore.kernel.org/linux-fpga/[email protected]/
> I don't see the problem here, other than a low-quality of patches that
> need reworking for some patchsets, and others are just fine. Just like
> all kernel subsystems, I don't see anything odd here.
>
>> Over the last two releases, I have shown i have the time and interest to maintain this subsystem.
> That's not how any of this works :)
>
>> So I am asking for
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index 11b38acb4c08..269cd08f4969 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -6951,7 +6951,7 @@ F:        drivers/net/ethernet/nvidia/*
>>
>> FPGA DFL DRIVERS
>> M:     Wu Hao <[email protected]>
>> -R:     Tom Rix <[email protected]>
>> +M:     Tom Rix <[email protected]>
> That's generous, but how about doing review first, the maintainership of
> this subsystem does not feel like any sort of bottleneck to me. I
> personally have no problems with Moritz's interactions with the
> community, his reviewing of patches, and forwarding on to me.
>
> Of course we all have delays as we have other work to do than just this,
> that's just part of normal development. I don't see anything stalled at
> the moment, nor anything that having another maintainer would have
> helped out with at all, so this feels like it is not needed from my end.
>
> Again, it feels like the developers need more reviews, and good ones, so
> please continue to help out with that, as that's the best thing I can
> see to do here.

I have been doing the first review in a couple of days after every patch landing.

I see some pretty good response from the developers to fix the issues raised.

But I do not see Moritz picking up the review until weeks later.

This consistent delay in timely reviews is a bottleneck.

It would be good if the big first reviews could be done in parallel.

Tom

>
> thanks,
>
> greg k-h
>

2021-01-11 20:08:08

[permalink] [raw]

Subject: Re: [PATCH 0/8] FPGA DFL Changes for 5.12

On Mon, Jan 11, 2021 at 11:46:03AM -0800, Tom Rix wrote:
>
> On 1/11/21 10:21 AM, Greg KH wrote:
> > On Mon, Jan 11, 2021 at 08:43:15AM -0800, Tom Rix wrote:
> >> On 1/11/21 8:09 AM, Greg KH wrote:
> >>> On Mon, Jan 11, 2021 at 07:55:24AM -0800, Tom Rix wrote:
> >>>> On 1/11/21 6:54 AM, Greg KH wrote:
> >>>>> On Mon, Jan 11, 2021 at 06:40:24AM -0800, Tom Rix wrote:
> >>>>>> On 1/10/21 10:57 PM, Greg KH wrote:
> >>>>>>> On Sun, Jan 10, 2021 at 11:43:54AM -0800, Tom Rix wrote:
> >>>>>>>> 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.
> >>>>>>> Ick, no! NEVER rebase a public branch. Why does it matter the speed of
> >>>>>>> my branch vs. anyone elses? Git handles merges very well.
> >>>>>>>
> >>>>>>> Just like Linus's branches move much faster than mine, and I don't
> >>>>>>> rebase my branches, you shouldn't rebase yours.
> >>>>>>>
> >>>>>>> Becides, I'm only taking _PATCHES_ for fpga changes at the moment, no
> >>>>>>> git pulls, so why does it matter at all for any of this?
> >>>>>>>
> >>>>>>> What is the problem you are trying to solve here?
> >>>>>> This 5.12 fpga patchset not making it into 5.11.
> >>>>> Ok, but isn't it the responsibility of the submitter to make sure they
> >>>>> apply properly when sending them out?
> >>>>>
> >>>>>> At some point before the 5.11 window, I tried it on next and it failed to merge.
> >>>>>>
> >>>>>> This points to needing some c/i so it does not happen again.
> >>>>> "again"? Merges and the like are a totally normal thing and happen all
> >>>>> the time, I still fail to understand what you are trying to "solve" for
> >>>>> here...
> >>>> What can I do to help make your merges as easy as possible ?
> >>> I have not had any problems with merges, I've only had "problems"
> >>> rejecting patches for their content.
> >>>
> >>> Try helping out with patch reviews if you want, finding and fixing
> >>> things before I review them is usually a good idea :)
> >> ok.
> >>>> Does the patchwork infra Moritz was speaking of earlier need fixing help?
> >>> No idea, I don't use it.
> >>>
> >>>> Any other things ?
> >>> What problems are you trying to solve here? What's wrong with how this
> >>> subsystem is working that you are feeling needs to be addressed?
> >> I do not believe the issue I raised in 5.10 has made any progress.
> > What issue?
> >
> >> If you look at the content in 5.11 we have actually regressed.
> > What bugs regressed?
> >
> >> https://lore.kernel.org/linux-fpga/[email protected]/
> > I don't see the problem here, other than a low-quality of patches that
> > need reworking for some patchsets, and others are just fine. Just like
> > all kernel subsystems, I don't see anything odd here.
> >
> >> Over the last two releases, I have shown i have the time and interest to maintain this subsystem.
> > That's not how any of this works :)
> >
> >> So I am asking for
> >>
> >> diff --git a/MAINTAINERS b/MAINTAINERS
> >> index 11b38acb4c08..269cd08f4969 100644
> >> --- a/MAINTAINERS
> >> +++ b/MAINTAINERS
> >> @@ -6951,7 +6951,7 @@ F:??????? drivers/net/ethernet/nvidia/*
> >> ?
> >> ?FPGA DFL DRIVERS
> >> ?M:???? Wu Hao <[email protected]>
> >> -R:???? Tom Rix <[email protected]>
> >> +M:???? Tom Rix <[email protected]>
> > That's generous, but how about doing review first, the maintainership of
> > this subsystem does not feel like any sort of bottleneck to me. I
> > personally have no problems with Moritz's interactions with the
> > community, his reviewing of patches, and forwarding on to me.
> >
> > Of course we all have delays as we have other work to do than just this,
> > that's just part of normal development. I don't see anything stalled at
> > the moment, nor anything that having another maintainer would have
> > helped out with at all, so this feels like it is not needed from my end.
> >
> > Again, it feels like the developers need more reviews, and good ones, so
> > please continue to help out with that, as that's the best thing I can
> > see to do here.
>
> I have been doing the first review in a couple of days after every patch landing.
>
> I see some pretty good response from the developers to fix the issues raised.?
>
> But I do not see Moritz picking up the review until weeks later.
>
> This consistent delay in timely reviews is a bottleneck.

What is being prevented from merging at this moment because of this?

There is always ebbs and flows with patch reviews, what do you consider
"manditory" time to review a patch from a maintainer?

Remember, we are almost all doing this not as our paid job, but as part
of what we do.

And to be frank, I personally have been putting the fpga patchset at the
_end_ of my reviews because of the quality of them in the past. While
it is slowly getting better, you all have a big hole to dig out from,
and maybe you need to step up your reviews to raise that bar so I don't
dread seeing them in my review queue :)

> It would be good if the big first reviews could be done in parallel.

parallel with what?

All I'm getting here is "I wish patches were accepted faster!" from you.
When personally, I think they are being accepted at a very nice rate for
such a tiny subsystem.

Good luck with your reviews,

greg k-h

2021-01-12 09:37:39

[permalink] [raw]

Subject: Re: [PATCH 0/8] FPGA DFL Changes for 5.12

Tom,

On Mon, Jan 11, 2021 at 11:46:03AM -0800, Tom Rix wrote:

[..]
> I have been doing the first review in a couple of days after every patch landing.

I appreciate your help with doing reviews.

> I see some pretty good response from the developers to fix the issues raised.?

... yet patches have been rejected. So it doesn't seem purely a matter
of throughput?

> But I do not see Moritz picking up the review until weeks later.

I'll admit there are delays that happen, I have a dayjob as I pointed
out in earlier conversations. Furthermore, just because I do not
immediately send out an email does not mean I don't look at stuff.

If people show up with 100kLOC patchsets that don't pass checkpatch,
it'll take a while for me to even read up and understand what they're
doing / trying to do.

> This consistent delay in timely reviews is a bottleneck.

As Greg pointed out even ones that were reviewed got rejected, so
clearly the issue is with the quality and not the speed at which we send
them on.

> It would be good if the big first reviews could be done in parallel.

Again depending how the patchsets are structured it will take me a while
to process. Having them re-use existing infrastructure, following
coding and submission guidelines will speed up the process.

On a personal level, being told I'm too slow and not doing my job as
maintainer doesn't exactly increase my motivation to get to it ...

- Moritz

2021-01-12 09:57:22

[permalink] [raw]

Subject: Re: [PATCH 0/8] FPGA DFL Changes for 5.12

On 1/11/21 12:28 PM, Moritz Fischer wrote:
> Tom,
>
> On Mon, Jan 11, 2021 at 11:46:03AM -0800, Tom Rix wrote:
>
> [..]
>> I have been doing the first review in a couple of days after every patch landing.
> I appreciate your help with doing reviews.
>
>> I see some pretty good response from the developers to fix the issues raised.Ã‚Â
> ... yet patches have been rejected. So it doesn't seem purely a matter
> of throughput?
>
>> But I do not see Moritz picking up the review until weeks later.
> I'll admit there are delays that happen, I have a dayjob as I pointed
> out in earlier conversations. Furthermore, just because I do not
> immediately send out an email does not mean I don't look at stuff.
>
> If people show up with 100kLOC patchsets that don't pass checkpatch,
> it'll take a while for me to even read up and understand what they're
> doing / trying to do.
>
>> This consistent delay in timely reviews is a bottleneck.
> As Greg pointed out even ones that were reviewed got rejected, so
> clearly the issue is with the quality and not the speed at which we send
> them on.
>
>> It would be good if the big first reviews could be done in parallel.
> Again depending how the patchsets are structured it will take me a while
> to process. Having them re-use existing infrastructure, following
> coding and submission guidelines will speed up the process.
>
> On a personal level, being told I'm too slow and not doing my job as
> maintainer doesn't exactly increase my motivation to get to it ...

Sorry about that.

I really do want to help out, earlier you mentioned patchwork problems.

If you can point me at the wreckage, I'll take a look.

Tom

>
> - Moritz
>

2021-01-14 16:50:29