| Message ID | cover.1625118581.git.christophe.jaillet@wanadoo.fr |
|---|---|
| Headers | show |
| Series | gve: Fixes and clean-up | expand |
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
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!
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
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(-)