From: Finn Thain
Date: Sun, 03 Jan 2021 11:26:26 +1100
> From: Christophe JAILLET
>
> A call to dma_alloc_coherent() is wrapped by sonic_alloc_descriptors().
>
> This is correctly freed in the remove function, but not in the error
> handling path of the probe function. Fix this by adding the m
From: Christophe JAILLET
A call to dma_alloc_coherent() is wrapped by sonic_alloc_descriptors().
This is correctly freed in the remove function, but not in the error
handling path of the probe function. Fix this by adding the missing
dma_free_coherent() call.
While at it, rename a label in orde
On Tue, 12 May 2020, Markus Elfring wrote:
> > Markus, if you were to write a patch to improve upon coding-style.rst,
> > who should review it?
>
> All involved contributors have got chances to provide constructive
> comments.
But how could someone be elevated to "involved contributor" if thei
> Markus, if you were to write a patch to improve upon coding-style.rst,
> who should review it?
All involved contributors have got chances to provide constructive comments.
I would be curious who will actually dare to contribute further ideas for this
area.
> If you are unable to write or revi
On Mon, 11 May 2020, Markus Elfring wrote:
> > If you can't determine when the bug was introduced,
>
> I might be able to determine also this information.
>
This is tantamount to an admission of duplicity.
>
> > how can you criticise a patch for the lack of a Fixes tag?
>
> I dared to point
r this code review.
[PATCH v2] net/sonic: Fix some resource leaks in error handling paths
https://lore.kernel.org/r/3eaa58c16dcf313ff7cb873dcff21659b0ea037d.1589158098.git.fth...@telegraphics.com.au/
Regards,
Markus
> Changed since v1:
> - Improved commit log slightly.
> - Changed 'undo_probe1' to 'undo_probe' where appropriate.
I find this response interesting.
> ---
I suggest to replace these triple dashes by a blank line.
> drivers/net/ethernet/natsemi/macsonic.c | 17 +
> drivers/n
> If you can't determine when the bug was introduced,
I might be able to determine also this information.
> how can you criticise a patch for the lack of a Fixes tag?
I dared to point two details out for the discussed patch.
>> To which commit would you like to refer to for the proposed adjus
On Sun, 10 May 2020, Markus Elfring wrote:
> >
> > Do you know when these bugs were introduced?
>
> I suggest to take another look at a provided tag “Fixes”.
If you can't determine when the bug was introduced, how can you criticise
a patch for the lack of a Fixes tag?
> To which commit would y
>> https://lore.kernel.org/lkml/20200427061803.53857-1-christophe.jail...@wanadoo.fr/
>
> Do you know when these bugs were introduced?
I suggest to take another look at a provided tag “Fixes”.
To which commit would you like to refer to for the proposed adjustment of
the function “mac_sonic_platfor
On Sun, 10 May 2020, Markus Elfring wrote:
> Christophe Jaillet proposed to complete the exception handling also for this
> function implementation.
> I find that such a software correction is qualified for this tag.
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documen
> Is there a way to add a Fixes tag that would not invoke the -stable
> process? And was that what you had in mind?
Christophe Jaillet proposed to complete the exception handling also for this
function implementation.
I find that such a software correction is qualified for this tag.
https://git.ke
On Fri, 8 May 2020, Jakub Kicinski wrote:
> On Fri, 8 May 2020 19:25:57 +0200 Christophe JAILLET wrote:
> > @@ -527,8 +531,9 @@ static int mac_sonic_platform_remove(struct
> > platform_device *pdev)
> > struct sonic_local* lp = netdev_priv(dev);
> >
> > unregister_netdev(dev);
> > -
On Sat, 9 May 2020, Markus Elfring wrote:
> > While at it, rename a label in order to be slightly more informative and
> > split some too long lines.
>
> Would you like to add the tag 'Fixes' to the change description?
>
Sorry but I don't follow your reasoning here. Are you saying that this
ne
On Sat, 2020-05-09 at 16:32 -0700, David Miller wrote:
> From: Joe Perches
> Date: Sat, 09 May 2020 15:42:36 -0700
>
> > David, maybe I missed some notification about Jakub's role.
> >
> > What is Jakub's role in relation to the networking tree?
>
> He is the co-maintainer of the networking tre
From: Joe Perches
Date: Sat, 09 May 2020 15:42:36 -0700
> David, maybe I missed some notification about Jakub's role.
>
> What is Jakub's role in relation to the networking tree?
He is the co-maintainer of the networking tree and you should respect
his actions and feedback as if it were coming
On Sat, 2020-05-09 at 11:13 -0700, Jakub Kicinski wrote:
> On Sat, 9 May 2020 18:47:08 +0200 Christophe JAILLET wrote:
> > Le 09/05/2020 à 03:54, Jakub Kicinski a écrit :
> > > On Fri, 8 May 2020 19:25:57 +0200 Christophe JAILLET wrote:
> > > > @@ -527,8 +531,9 @@ static int mac_sonic_platform_r
Le 09/05/2020 à 20:13, Jakub Kicinski a écrit :
On Sat, 9 May 2020 18:47:08 +0200 Christophe JAILLET wrote:
Le 09/05/2020 à 03:54, Jakub Kicinski a écrit :
On Fri, 8 May 2020 19:25:57 +0200 Christophe JAILLET wrote:
@@ -527,8 +531,9 @@ static int mac_sonic_platform_remove(struct platform_devi
On Sat, 9 May 2020 18:47:08 +0200 Christophe JAILLET wrote:
> Le 09/05/2020 à 03:54, Jakub Kicinski a écrit :
> > On Fri, 8 May 2020 19:25:57 +0200 Christophe JAILLET wrote:
> >> @@ -527,8 +531,9 @@ static int mac_sonic_platform_remove(struct
> >> platform_device *pdev)
> >>struct sonic_loc
Le 09/05/2020 à 03:54, Jakub Kicinski a écrit :
On Fri, 8 May 2020 19:25:57 +0200 Christophe JAILLET wrote:
@@ -527,8 +531,9 @@ static int mac_sonic_platform_remove(struct platform_device
*pdev)
struct sonic_local* lp = netdev_priv(dev);
unregister_netdev(dev);
- dma_free_
> While at it, rename a label in order to be slightly more informative and
> split some too long lines.
Would you like to add the tag “Fixes” to the change description?
…
> +++ b/drivers/net/ethernet/natsemi/macsonic.c
> @@ -506,10 +506,14 @@ static int mac_sonic_platform_probe(struct
> platfor
On Sat, 9 May 2020 11:57:44 +1000 (AEST) Finn Thain wrote:
> On Fri, 8 May 2020, Jakub Kicinski wrote:
> > On Fri, 8 May 2020 19:25:57 +0200 Christophe JAILLET wrote:
> > > Only macsonic has been compile tested. I don't have the needed setup to
> > > compile xtsonic
> >
> > Well, we gotta do
On Fri, 8 May 2020, Jakub Kicinski wrote:
> On Fri, 8 May 2020 19:25:57 +0200 Christophe JAILLET wrote:
> > Only macsonic has been compile tested. I don't have the needed setup to
> > compile xtsonic
>
> Well, we gotta do that before we apply the patch :S
>
I've compiled xtsonic.c with this
On Fri, 8 May 2020 19:25:57 +0200 Christophe JAILLET wrote:
> @@ -527,8 +531,9 @@ static int mac_sonic_platform_remove(struct
> platform_device *pdev)
> struct sonic_local* lp = netdev_priv(dev);
>
> unregister_netdev(dev);
> - dma_free_coherent(lp->device, SIZEOF_SONIC_DESC *
On Fri, 8 May 2020 19:25:57 +0200 Christophe JAILLET wrote:
> Only macsonic has been compile tested. I don't have the needed setup to
> compile xtsonic
Well, we gotta do that before we apply the patch :S
Does the driver actually depend on some platform stuff, or can we
do this:
diff --git a/dr
On Fri, 8 May 2020, Christophe JAILLET wrote:
> A call to 'dma_alloc_coherent()' is hidden in
> 'sonic_alloc_descriptors()'.
>
> This is correctly freed in the remove function, but not in the error
> handling path of the probe function. Fix it and add the missing
> 'dma_free_coherent()' call
A call to 'dma_alloc_coherent()' is hidden in 'sonic_alloc_descriptors()'.
This is correctly freed in the remove function, but not in the error
handling path of the probe function.
Fix it and add the missing 'dma_free_coherent()' call.
While at it, rename a label in order to be slightly more info
27 matches
Mail list logo
