mbox series

[0/3] gve: Fixes and clean-up

Message ID cover.1625118581.git.christophe.jaillet@wanadoo.fr (mailing list archive)
Headers show
Series gve: Fixes and clean-up | expand

Message

Christophe JAILLET July 1, 2021, 5:58 a.m. UTC
This serie is part of the effort to axe the wrappers in
include/linux/pci-dma-compat.h

While looking at it, I spotted:
  - a resource leak in an error handling path (patch 1)
  - an error code that could be propagated. (patch 2)
    This patch could be ignored. It's only goal is to be more consistent
    with other drivers.

These 2 paches are not related to the 'pci-dma-compat.h' stuff, which can
be found in patch 3.

Christophe JAILLET (3):
  gve: Fix an error handling path in 'gve_probe()'
  gve: Propagate error codes to caller
  gve: Simplify code and axe the use of a deprecated API

 drivers/net/ethernet/google/gve/gve_main.c | 19 ++++++++-----------
 1 file changed, 8 insertions(+), 11 deletions(-)

Comments

Jeroen de Borst July 1, 2021, 4:20 p.m. UTC | #1
On Wed, Jun 30, 2021 at 10:58 PM Christophe JAILLET
<christophe.jaillet@wanadoo.fr> wrote:
>
> This serie is part of the effort to axe the wrappers in
> include/linux/pci-dma-compat.h
>
> While looking at it, I spotted:
>   - a resource leak in an error handling path (patch 1)
>   - an error code that could be propagated. (patch 2)
>     This patch could be ignored. It's only goal is to be more consistent
>     with other drivers.
>
> These 2 paches are not related to the 'pci-dma-compat.h' stuff, which can
> be found in patch 3.
>
> Christophe JAILLET (3):
>   gve: Fix an error handling path in 'gve_probe()'
>   gve: Propagate error codes to caller
>   gve: Simplify code and axe the use of a deprecated API
>
>

Thanks for these patches.

Can split this into 2 patch series; one for net (with the first 2
patches) and one for net-next (with the cleanup one)?
Also the label in the first patch should probably read
'abort_with_gve_init' instead of 'abort_with_vge_init'.

Jeroen
Christophe JAILLET July 1, 2021, 5:42 p.m. UTC | #2
Le 01/07/2021 à 18:20, Jeroen de Borst a écrit :
> On Wed, Jun 30, 2021 at 10:58 PM Christophe JAILLET
> <christophe.jaillet@wanadoo.fr> wrote:
>>
>> This serie is part of the effort to axe the wrappers in
>> include/linux/pci-dma-compat.h
>>
>> While looking at it, I spotted:
>>    - a resource leak in an error handling path (patch 1)
>>    - an error code that could be propagated. (patch 2)
>>      This patch could be ignored. It's only goal is to be more consistent
>>      with other drivers.
>>
>> These 2 paches are not related to the 'pci-dma-compat.h' stuff, which can
>> be found in patch 3.
>>
>> Christophe JAILLET (3):
>>    gve: Fix an error handling path in 'gve_probe()'
>>    gve: Propagate error codes to caller
>>    gve: Simplify code and axe the use of a deprecated API
>>
>>
> 
> Thanks for these patches.
> 
> Can split this into 2 patch series;

Sure.

> one for net (with the first 2
> patches) and one for net-next (with the cleanup one)?

I've never worked with net and net-next directly.
If just adding net and net-next after [PATCH] in the subject of the 
mail, yes, I can do it if it helps.


BTW, I gave a look at https://patchwork.kernel.org/project/netdevbpf/list/
The patch 1/3 is marked as failed because "1 blamed authors not CCed: 
lrizzo@google.com; 1 maintainers not CCed: lrizzo@google.com"

This author/blame was not spotted by get_maintainer.pl. Is it something 
I should worry about?


> Also the label in the first patch should probably read
> 'abort_with_gve_init' instead of 'abort_with_vge_init'.

Good catch. Sorry about that.

> 
> Jeroen
> 

CJ
Jeroen de Borst July 1, 2021, 6:11 p.m. UTC | #3
On Thu, Jul 1, 2021 at 10:42 AM Christophe JAILLET
<christophe.jaillet@wanadoo.fr> wrote:
>
> Le 01/07/2021 à 18:20, Jeroen de Borst a écrit :
> > On Wed, Jun 30, 2021 at 10:58 PM Christophe JAILLET
> > <christophe.jaillet@wanadoo.fr> wrote:
> >>
> >> This serie is part of the effort to axe the wrappers in
> >> include/linux/pci-dma-compat.h
> >>
> >> While looking at it, I spotted:
> >>    - a resource leak in an error handling path (patch 1)
> >>    - an error code that could be propagated. (patch 2)
> >>      This patch could be ignored. It's only goal is to be more consistent
> >>      with other drivers.
> >>
> >> These 2 paches are not related to the 'pci-dma-compat.h' stuff, which can
> >> be found in patch 3.
> >>
> >> Christophe JAILLET (3):
> >>    gve: Fix an error handling path in 'gve_probe()'
> >>    gve: Propagate error codes to caller
> >>    gve: Simplify code and axe the use of a deprecated API
> >>
> >>
> >
> > Thanks for these patches.
> >
> > Can split this into 2 patch series;
>
> Sure.
>
> > one for net (with the first 2
> > patches) and one for net-next (with the cleanup one)?
>
> I've never worked with net and net-next directly.
> If just adding net and net-next after [PATCH] in the subject of the
> mail, yes, I can do it if it helps.
>
>
> BTW, I gave a look at https://patchwork.kernel.org/project/netdevbpf/list/
> The patch 1/3 is marked as failed because "1 blamed authors not CCed:
> lrizzo@google.com; 1 maintainers not CCed: lrizzo@google.com"
>
> This author/blame was not spotted by get_maintainer.pl. Is it something
> I should worry about?
>
>
> > Also the label in the first patch should probably read
> > 'abort_with_gve_init' instead of 'abort_with_vge_init'.
>
> Good catch. Sorry about that.
>
> >
> > Jeroen
> >
>
> CJ
>

[again, now in plaintext, sorry for the spam]

You tag the patch sets with [PATCH net <n>/2] for the 2 fixes and just
[PATCH net-next] for the cleanup one.

You can cc Luigi (lrizzo@google.com) on that one patch for
completeness, but I think it shouldn't be necessary.

Thanks!
Dan Carpenter July 2, 2021, 8:33 a.m. UTC | #4
On Thu, Jul 01, 2021 at 07:42:48PM +0200, Christophe JAILLET wrote:
> > one for net (with the first 2
> > patches) and one for net-next (with the cleanup one)?
> 
> I've never worked with net and net-next directly.
> If just adding net and net-next after [PATCH] in the subject of the mail,
> yes, I can do it if it helps.

I have a separate tree that I use for sending net patches.  I generally
write my patches against linux-next and then postpone sending them until
the next day.

Then I open my patch in mutt.
cd tmp_tree/
../switch_to_net.sh
cat /var/tmp/mutt-speke-1000-511162-9994856746594827871 | patch -p1 --dry-run
If that applies then I "net" to the subject.  Otherwise I do a
`../switch_to_net-next.sh` verify it applies and send that.

Once in a while I will have to modify my patches to apply cleanly
against the net tree.

It's a pain in the butt and I get it wrong disappointingly often.  I
only do it for networking.  Not for linux-wireless.  There is another
tree where they complain if you don't add a tree to their patches but I
forget what it is...  (I don't use the process for them, only for
networking).

regards,
dan carpenter