diff mbox

[v3] net: ethernet: support "fixed-link" DT node on nb8800 driver

Message ID 56B4B013.5030407@laposte.net
State Superseded, archived
Delegated to: David Miller
Headers show

Commit Message

Sebastian Frias Feb. 5, 2016, 2:22 p.m. UTC
Signed-off-by: Sebastian Frias <sf84@laposte.net>
---
  drivers/net/ethernet/aurora/nb8800.c | 14 +++++++++++++-
  1 file changed, 13 insertions(+), 1 deletion(-)

Comments

Måns Rullgård Feb. 5, 2016, 2:34 p.m. UTC | #1
Sebastian Frias <sf84@laposte.net> writes:

> Signed-off-by: Sebastian Frias <sf84@laposte.net>

Please change the subject to something like "net: ethernet: nb8800:
support fixed-link DT node" and add a comment body.

> ---
>  drivers/net/ethernet/aurora/nb8800.c | 14 +++++++++++++-
>  1 file changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/aurora/nb8800.c
> b/drivers/net/ethernet/aurora/nb8800.c
> index ecc4a33..e1fb071 100644
> --- a/drivers/net/ethernet/aurora/nb8800.c
> +++ b/drivers/net/ethernet/aurora/nb8800.c
> @@ -1460,7 +1460,19 @@ static int nb8800_probe(struct platform_device *pdev)
>  		goto err_disable_clk;
>  	}
>
> -	priv->phy_node = of_parse_phandle(pdev->dev.of_node, "phy-handle", 0);
> +	if (of_phy_is_fixed_link(pdev->dev.of_node)) {
> +		ret = of_phy_register_fixed_link(pdev->dev.of_node);
> +		if (ret < 0) {
> +			dev_err(&pdev->dev, "bad fixed-link spec\n");
> +			goto err_free_bus;
> +		}
> +		priv->phy_node = of_node_get(pdev->dev.of_node);
> +	}
> +
> +	if (!priv->phy_node)
> +		priv->phy_node = of_parse_phandle(pdev->dev.of_node,
> +						  "phy-handle", 0);
> +
>  	if (!priv->phy_node) {
>  		dev_err(&pdev->dev, "no PHY specified\n");
>  		ret = -ENODEV;
> -- 
> 2.1.4
Sebastian Frias Feb. 5, 2016, 2:56 p.m. UTC | #2
On 02/05/2016 03:34 PM, Måns Rullgård wrote:
> Sebastian Frias <sf84@laposte.net> writes:
>
>> Signed-off-by: Sebastian Frias <sf84@laposte.net>
>
> Please change the subject to something like "net: ethernet: nb8800:
> support fixed-link DT node" and add a comment body.

The subject is pretty explicit for such a simple patch, what else could 
I add that wouldn't be unnecessary chat?

>
>> ---
>>   drivers/net/ethernet/aurora/nb8800.c | 14 +++++++++++++-
>>   1 file changed, 13 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/ethernet/aurora/nb8800.c
>> b/drivers/net/ethernet/aurora/nb8800.c
>> index ecc4a33..e1fb071 100644
>> --- a/drivers/net/ethernet/aurora/nb8800.c
>> +++ b/drivers/net/ethernet/aurora/nb8800.c
>> @@ -1460,7 +1460,19 @@ static int nb8800_probe(struct platform_device *pdev)
>>   		goto err_disable_clk;
>>   	}
>>
>> -	priv->phy_node = of_parse_phandle(pdev->dev.of_node, "phy-handle", 0);
>> +	if (of_phy_is_fixed_link(pdev->dev.of_node)) {
>> +		ret = of_phy_register_fixed_link(pdev->dev.of_node);
>> +		if (ret < 0) {
>> +			dev_err(&pdev->dev, "bad fixed-link spec\n");
>> +			goto err_free_bus;
>> +		}
>> +		priv->phy_node = of_node_get(pdev->dev.of_node);
>> +	}
>> +
>> +	if (!priv->phy_node)
>> +		priv->phy_node = of_parse_phandle(pdev->dev.of_node,
>> +						  "phy-handle", 0);
>> +
>>   	if (!priv->phy_node) {
>>   		dev_err(&pdev->dev, "no PHY specified\n");
>>   		ret = -ENODEV;
>> --
>> 2.1.4
>
Måns Rullgård Feb. 5, 2016, 3:08 p.m. UTC | #3
Sebastian Frias <sf84@laposte.net> writes:

> On 02/05/2016 03:34 PM, Måns Rullgård wrote:
>> Sebastian Frias <sf84@laposte.net> writes:
>>
>>> Signed-off-by: Sebastian Frias <sf84@laposte.net>
>>
>> Please change the subject to something like "net: ethernet: nb8800:
>> support fixed-link DT node" and add a comment body.
>
> The subject is pretty explicit for such a simple patch, what else
> could I add that wouldn't be unnecessary chat?

It's customary to include a description body even if it's little more
than a restatement of the subject.  Also, while the subject usually only
says _what_ the patch does, the body should additionally state _why_ it
is needed.

>>> ---
>>>   drivers/net/ethernet/aurora/nb8800.c | 14 +++++++++++++-
>>>   1 file changed, 13 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/net/ethernet/aurora/nb8800.c
>>> b/drivers/net/ethernet/aurora/nb8800.c
>>> index ecc4a33..e1fb071 100644
>>> --- a/drivers/net/ethernet/aurora/nb8800.c
>>> +++ b/drivers/net/ethernet/aurora/nb8800.c
>>> @@ -1460,7 +1460,19 @@ static int nb8800_probe(struct platform_device *pdev)
>>>   		goto err_disable_clk;
>>>   	}
>>>
>>> -	priv->phy_node = of_parse_phandle(pdev->dev.of_node, "phy-handle", 0);
>>> +	if (of_phy_is_fixed_link(pdev->dev.of_node)) {
>>> +		ret = of_phy_register_fixed_link(pdev->dev.of_node);
>>> +		if (ret < 0) {
>>> +			dev_err(&pdev->dev, "bad fixed-link spec\n");
>>> +			goto err_free_bus;
>>> +		}
>>> +		priv->phy_node = of_node_get(pdev->dev.of_node);
>>> +	}
>>> +
>>> +	if (!priv->phy_node)
>>> +		priv->phy_node = of_parse_phandle(pdev->dev.of_node,
>>> +						  "phy-handle", 0);
>>> +
>>>   	if (!priv->phy_node) {
>>>   		dev_err(&pdev->dev, "no PHY specified\n");
>>>   		ret = -ENODEV;
>>> --
>>> 2.1.4
>>
Sebastian Frias Feb. 5, 2016, 3:20 p.m. UTC | #4
On 02/05/2016 04:08 PM, Måns Rullgård wrote:
> Sebastian Frias <sf84@laposte.net> writes:
>
>> On 02/05/2016 03:34 PM, Måns Rullgård wrote:
>>> Sebastian Frias <sf84@laposte.net> writes:
>>>
>>>> Signed-off-by: Sebastian Frias <sf84@laposte.net>
>>>
>>> Please change the subject to something like "net: ethernet: nb8800:
>>> support fixed-link DT node" and add a comment body.
>>
>> The subject is pretty explicit for such a simple patch, what else
>> could I add that wouldn't be unnecessary chat?
>
> It's customary to include a description body even if it's little more
> than a restatement of the subject.  Also, while the subject usually only
> says _what_ the patch does, the body should additionally state _why_ it
> is needed.

I understand, but _why_ it is needed is also obvious in this case; I 
mean, without the patch "fixed-link" cannot be used.
Other patches may not be as obvious/simple and thus justify and require 
more details.

Anyway, I added "Properly handles the case where the PHY is not connected
to the real MDIO bus" would that be ok?

>
>>>> ---
>>>>    drivers/net/ethernet/aurora/nb8800.c | 14 +++++++++++++-
>>>>    1 file changed, 13 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/net/ethernet/aurora/nb8800.c
>>>> b/drivers/net/ethernet/aurora/nb8800.c
>>>> index ecc4a33..e1fb071 100644
>>>> --- a/drivers/net/ethernet/aurora/nb8800.c
>>>> +++ b/drivers/net/ethernet/aurora/nb8800.c
>>>> @@ -1460,7 +1460,19 @@ static int nb8800_probe(struct platform_device *pdev)
>>>>    		goto err_disable_clk;
>>>>    	}
>>>>
>>>> -	priv->phy_node = of_parse_phandle(pdev->dev.of_node, "phy-handle", 0);
>>>> +	if (of_phy_is_fixed_link(pdev->dev.of_node)) {
>>>> +		ret = of_phy_register_fixed_link(pdev->dev.of_node);
>>>> +		if (ret < 0) {
>>>> +			dev_err(&pdev->dev, "bad fixed-link spec\n");
>>>> +			goto err_free_bus;
>>>> +		}
>>>> +		priv->phy_node = of_node_get(pdev->dev.of_node);
>>>> +	}
>>>> +
>>>> +	if (!priv->phy_node)
>>>> +		priv->phy_node = of_parse_phandle(pdev->dev.of_node,
>>>> +						  "phy-handle", 0);
>>>> +
>>>>    	if (!priv->phy_node) {
>>>>    		dev_err(&pdev->dev, "no PHY specified\n");
>>>>    		ret = -ENODEV;
>>>> --
>>>> 2.1.4
>>>
>
Måns Rullgård Feb. 5, 2016, 3:26 p.m. UTC | #5
Sebastian Frias <sf84@laposte.net> writes:

> On 02/05/2016 04:08 PM, Måns Rullgård wrote:
>> Sebastian Frias <sf84@laposte.net> writes:
>>
>>> On 02/05/2016 03:34 PM, Måns Rullgård wrote:
>>>> Sebastian Frias <sf84@laposte.net> writes:
>>>>
>>>>> Signed-off-by: Sebastian Frias <sf84@laposte.net>
>>>>
>>>> Please change the subject to something like "net: ethernet: nb8800:
>>>> support fixed-link DT node" and add a comment body.
>>>
>>> The subject is pretty explicit for such a simple patch, what else
>>> could I add that wouldn't be unnecessary chat?
>>
>> It's customary to include a description body even if it's little more
>> than a restatement of the subject.  Also, while the subject usually only
>> says _what_ the patch does, the body should additionally state _why_ it
>> is needed.
>
> I understand, but _why_ it is needed is also obvious in this case; I
> mean, without the patch "fixed-link" cannot be used.

Then say so.

> Other patches may not be as obvious/simple and thus justify and
> require more details.
>
> Anyway, I added "Properly handles the case where the PHY is not connected
> to the real MDIO bus" would that be ok?

Have you read Documentation/SubmittingPatches?  Do so (again) and pay
special attention to section 2 "Describe your changes."

>>>>> ---
>>>>>    drivers/net/ethernet/aurora/nb8800.c | 14 +++++++++++++-
>>>>>    1 file changed, 13 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/drivers/net/ethernet/aurora/nb8800.c
>>>>> b/drivers/net/ethernet/aurora/nb8800.c
>>>>> index ecc4a33..e1fb071 100644
>>>>> --- a/drivers/net/ethernet/aurora/nb8800.c
>>>>> +++ b/drivers/net/ethernet/aurora/nb8800.c
>>>>> @@ -1460,7 +1460,19 @@ static int nb8800_probe(struct platform_device *pdev)
>>>>>    		goto err_disable_clk;
>>>>>    	}
>>>>>
>>>>> -	priv->phy_node = of_parse_phandle(pdev->dev.of_node, "phy-handle", 0);
>>>>> +	if (of_phy_is_fixed_link(pdev->dev.of_node)) {
>>>>> +		ret = of_phy_register_fixed_link(pdev->dev.of_node);
>>>>> +		if (ret < 0) {
>>>>> +			dev_err(&pdev->dev, "bad fixed-link spec\n");
>>>>> +			goto err_free_bus;
>>>>> +		}
>>>>> +		priv->phy_node = of_node_get(pdev->dev.of_node);
>>>>> +	}
>>>>> +
>>>>> +	if (!priv->phy_node)
>>>>> +		priv->phy_node = of_parse_phandle(pdev->dev.of_node,
>>>>> +						  "phy-handle", 0);
>>>>> +
>>>>>    	if (!priv->phy_node) {
>>>>>    		dev_err(&pdev->dev, "no PHY specified\n");
>>>>>    		ret = -ENODEV;
>>>>> --
>>>>> 2.1.4
>>>>
>>
Sebastian Frias Feb. 8, 2016, 10:34 a.m. UTC | #6
On 02/05/2016 04:26 PM, Måns Rullgård wrote:
> Sebastian Frias <sf84@laposte.net> writes:
>
>> On 02/05/2016 04:08 PM, Måns Rullgård wrote:
>>> Sebastian Frias <sf84@laposte.net> writes:
>>>
>>>> On 02/05/2016 03:34 PM, Måns Rullgård wrote:
>>>>> Sebastian Frias <sf84@laposte.net> writes:
>>>>>
>>>>>> Signed-off-by: Sebastian Frias <sf84@laposte.net>
>>>>>
>>>>> Please change the subject to something like "net: ethernet: nb8800:
>>>>> support fixed-link DT node" and add a comment body.
>>>>
>>>> The subject is pretty explicit for such a simple patch, what else
>>>> could I add that wouldn't be unnecessary chat?
>>>
>>> It's customary to include a description body even if it's little more
>>> than a restatement of the subject.  Also, while the subject usually only
>>> says _what_ the patch does, the body should additionally state _why_ it
>>> is needed.
>>
>> I understand, but _why_ it is needed is also obvious in this case; I
>> mean, without the patch "fixed-link" cannot be used.
>
> Then say so.
>
>> Other patches may not be as obvious/simple and thus justify and
>> require more details.
>>
>> Anyway, I added "Properly handles the case where the PHY is not connected
>> to the real MDIO bus" would that be ok?
>
> Have you read Documentation/SubmittingPatches?  Do so (again) and pay
> special attention to section 2 "Describe your changes."

I just sent v5.
If for whatever reason, you or anybody else think that the comment is 
not good, would you mind proposing a comment that would make everybody 
happy so that the patch goes thru?
And if you or anybody else does not want the patch, could you please say 
so as well?

I have to admit this process (sending patches and getting it reviewed) 
could benefit from more clarifications.
For example, the process could say that at least 2 reviewers must agree 
on it (on the comments made to the patch and on the patch itself).
I could also say that reviewers are to express not only their opinion 
but to clearly and unequivocally accept or reject.

For instance, right now, it is not clear to me if your comments are 
"nice to have" or "blocking" the patch.
I don't know if the patch is welcome or not, etc.
So I submitted v5, but maybe it was not even necessary, it's hard to 
know where in the submission process we are.

By the way, I know some people like the command line, email, etc. but 
there ought to be other tools better suited for patch review...




>
>>>>>> ---
>>>>>>     drivers/net/ethernet/aurora/nb8800.c | 14 +++++++++++++-
>>>>>>     1 file changed, 13 insertions(+), 1 deletion(-)
>>>>>>
>>>>>> diff --git a/drivers/net/ethernet/aurora/nb8800.c
>>>>>> b/drivers/net/ethernet/aurora/nb8800.c
>>>>>> index ecc4a33..e1fb071 100644
>>>>>> --- a/drivers/net/ethernet/aurora/nb8800.c
>>>>>> +++ b/drivers/net/ethernet/aurora/nb8800.c
>>>>>> @@ -1460,7 +1460,19 @@ static int nb8800_probe(struct platform_device *pdev)
>>>>>>     		goto err_disable_clk;
>>>>>>     	}
>>>>>>
>>>>>> -	priv->phy_node = of_parse_phandle(pdev->dev.of_node, "phy-handle", 0);
>>>>>> +	if (of_phy_is_fixed_link(pdev->dev.of_node)) {
>>>>>> +		ret = of_phy_register_fixed_link(pdev->dev.of_node);
>>>>>> +		if (ret < 0) {
>>>>>> +			dev_err(&pdev->dev, "bad fixed-link spec\n");
>>>>>> +			goto err_free_bus;
>>>>>> +		}
>>>>>> +		priv->phy_node = of_node_get(pdev->dev.of_node);
>>>>>> +	}
>>>>>> +
>>>>>> +	if (!priv->phy_node)
>>>>>> +		priv->phy_node = of_parse_phandle(pdev->dev.of_node,
>>>>>> +						  "phy-handle", 0);
>>>>>> +
>>>>>>     	if (!priv->phy_node) {
>>>>>>     		dev_err(&pdev->dev, "no PHY specified\n");
>>>>>>     		ret = -ENODEV;
>>>>>> --
>>>>>> 2.1.4
>>>>>
>>>
>
Måns Rullgård Feb. 8, 2016, 1:37 p.m. UTC | #7
Sebastian Frias <sf84@laposte.net> writes:

> On 02/05/2016 04:26 PM, Måns Rullgård wrote:
>> Sebastian Frias <sf84@laposte.net> writes:
>>
>>> On 02/05/2016 04:08 PM, Måns Rullgård wrote:
>>>> Sebastian Frias <sf84@laposte.net> writes:
>>>>
>>>>> On 02/05/2016 03:34 PM, Måns Rullgård wrote:
>>>>>> Sebastian Frias <sf84@laposte.net> writes:
>>>>>>
>>>>>>> Signed-off-by: Sebastian Frias <sf84@laposte.net>
>>>>>>
>>>>>> Please change the subject to something like "net: ethernet: nb8800:
>>>>>> support fixed-link DT node" and add a comment body.
>>>>>
>>>>> The subject is pretty explicit for such a simple patch, what else
>>>>> could I add that wouldn't be unnecessary chat?
>>>>
>>>> It's customary to include a description body even if it's little more
>>>> than a restatement of the subject.  Also, while the subject usually only
>>>> says _what_ the patch does, the body should additionally state _why_ it
>>>> is needed.
>>>
>>> I understand, but _why_ it is needed is also obvious in this case; I
>>> mean, without the patch "fixed-link" cannot be used.
>>
>> Then say so.
>>
>>> Other patches may not be as obvious/simple and thus justify and
>>> require more details.
>>>
>>> Anyway, I added "Properly handles the case where the PHY is not connected
>>> to the real MDIO bus" would that be ok?
>>
>> Have you read Documentation/SubmittingPatches?  Do so (again) and pay
>> special attention to section 2 "Describe your changes."
>
> I just sent v5.

Thanks for your patience.

> If for whatever reason, you or anybody else think that the comment is
> not good, would you mind proposing a comment that would make everybody
> happy so that the patch goes thru?
> And if you or anybody else does not want the patch, could you please
> say so as well?
>
> I have to admit this process (sending patches and getting it reviewed)
> could benefit from more clarifications.
> For example, the process could say that at least 2 reviewers must
> agree on it (on the comments made to the patch and on the patch
> itself).
> I could also say that reviewers are to express not only their opinion
> but to clearly and unequivocally accept or reject.
>
> For instance, right now, it is not clear to me if your comments are
> "nice to have" or "blocking" the patch.
> I don't know if the patch is welcome or not, etc.
> So I submitted v5, but maybe it was not even necessary, it's hard to
> know where in the submission process we are.

In this case, it's ultimately up to Dave Miller.  He'll take into
account whatever comments others have made and decide whether he wants
to accept it.

> By the way, I know some people like the command line, email, etc. but
> there ought to be other tools better suited for patch review...

Some kernel subsystems use http://patchwork.ozlabs.org/ to track status
of various patches.
Mason Feb. 8, 2016, 2:11 p.m. UTC | #8
On 08/02/2016 14:37, Måns Rullgård wrote:

> Sebastian Frias wrote:
> 
>> By the way, I know some people like the command line, email, etc. but
>> there ought to be other tools better suited for patch review...
> 
> Some kernel subsystems use http://patchwork.ozlabs.org/ to track status
> of various patches.

There's also a kernel bugzilla, but it may be for actual bugs.
https://bugzilla.kernel.org/
Sebastian Frias Feb. 8, 2016, 2:32 p.m. UTC | #9
On 02/08/2016 02:37 PM, Måns Rullgård wrote:
> Sebastian Frias <sf84@laposte.net> writes:
>
>> On 02/05/2016 04:26 PM, Måns Rullgård wrote:
>>> Sebastian Frias <sf84@laposte.net> writes:
>>>
>>>> On 02/05/2016 04:08 PM, Måns Rullgård wrote:
>>>>> Sebastian Frias <sf84@laposte.net> writes:
>>>>>
>>>>>> On 02/05/2016 03:34 PM, Måns Rullgård wrote:
>>>>>>> Sebastian Frias <sf84@laposte.net> writes:
>>>>>>>
>>>>>>>> Signed-off-by: Sebastian Frias <sf84@laposte.net>
>>>>>>>
>>>>>>> Please change the subject to something like "net: ethernet: nb8800:
>>>>>>> support fixed-link DT node" and add a comment body.
>>>>>>
>>>>>> The subject is pretty explicit for such a simple patch, what else
>>>>>> could I add that wouldn't be unnecessary chat?
>>>>>
>>>>> It's customary to include a description body even if it's little more
>>>>> than a restatement of the subject.  Also, while the subject usually only
>>>>> says _what_ the patch does, the body should additionally state _why_ it
>>>>> is needed.
>>>>
>>>> I understand, but _why_ it is needed is also obvious in this case; I
>>>> mean, without the patch "fixed-link" cannot be used.
>>>
>>> Then say so.
>>>
>>>> Other patches may not be as obvious/simple and thus justify and
>>>> require more details.
>>>>
>>>> Anyway, I added "Properly handles the case where the PHY is not connected
>>>> to the real MDIO bus" would that be ok?
>>>
>>> Have you read Documentation/SubmittingPatches?  Do so (again) and pay
>>> special attention to section 2 "Describe your changes."
>>
>> I just sent v5.
>
> Thanks for your patience.

:-)

>
>> If for whatever reason, you or anybody else think that the comment is
>> not good, would you mind proposing a comment that would make everybody
>> happy so that the patch goes thru?
>> And if you or anybody else does not want the patch, could you please
>> say so as well?
>>
>> I have to admit this process (sending patches and getting it reviewed)
>> could benefit from more clarifications.
>> For example, the process could say that at least 2 reviewers must
>> agree on it (on the comments made to the patch and on the patch
>> itself).
>> I could also say that reviewers are to express not only their opinion
>> but to clearly and unequivocally accept or reject.
>>
>> For instance, right now, it is not clear to me if your comments are
>> "nice to have" or "blocking" the patch.
>> I don't know if the patch is welcome or not, etc.
>> So I submitted v5, but maybe it was not even necessary, it's hard to
>> know where in the submission process we are.
>
> In this case, it's ultimately up to Dave Miller.  He'll take into
> account whatever comments others have made and decide whether he wants
> to accept it.

Ok, thanks.

>
>> By the way, I know some people like the command line, email, etc. but
>> there ought to be other tools better suited for patch review...
>
> Some kernel subsystems use http://patchwork.ozlabs.org/ to track status
> of various patches.
>

Thanks, I see that netdev is part of it, and that the patches are there:

https://patchwork.ozlabs.org/patch/580217/

seems like a slight layer over plain email and mailinglists; I was 
thinking of something more in the line of https://www.gerritcodereview.com/
I believe Google uses Gerrit for Android.
I think Gerrit would probably be too big (and being written in Java, 
using Prolog and other DSLs, implementing its own Git server in Java, 
etc, may make some -or lots?- of kernel developers cry :-) )
However, in Gerrit it is easier to know where in the "review" process we 
are, because people have to explicitly give a score "+/- X" when 
commenting on a patch.
Also, the diff can operate between different versions of the patches 
themselves to see if the inlined comments were addressed.
Sebastian Frias Feb. 8, 2016, 2:38 p.m. UTC | #10
On 02/08/2016 03:11 PM, Mason wrote:
> On 08/02/2016 14:37, Måns Rullgård wrote:
>
>> Sebastian Frias wrote:
>>
>>> By the way, I know some people like the command line, email, etc. but
>>> there ought to be other tools better suited for patch review...
>>
>> Some kernel subsystems use http://patchwork.ozlabs.org/ to track status
>> of various patches.
>
> There's also a kernel bugzilla, but it may be for actual bugs.
> https://bugzilla.kernel.org/
>

Thanks, and what would be the definition of a bug?
I mean, would the issue from this thread qualify?
Should I have created a bug report before submitting the patch?
Måns Rullgård Feb. 8, 2016, 2:44 p.m. UTC | #11
Sebastian Frias <sf84@laposte.net> writes:

> On 02/08/2016 03:11 PM, Mason wrote:
>> On 08/02/2016 14:37, Måns Rullgård wrote:
>>
>>> Sebastian Frias wrote:
>>>
>>>> By the way, I know some people like the command line, email, etc. but
>>>> there ought to be other tools better suited for patch review...
>>>
>>> Some kernel subsystems use http://patchwork.ozlabs.org/ to track status
>>> of various patches.
>>
>> There's also a kernel bugzilla, but it may be for actual bugs.
>> https://bugzilla.kernel.org/
>>
>
> Thanks, and what would be the definition of a bug?
> I mean, would the issue from this thread qualify?
> Should I have created a bug report before submitting the patch?

No, that is not necessary.  My understanding is that the bugzilla is
more of a place to report a bug you've found but don't have a patch
for.  Patches always go through the mailing lists.
Måns Rullgård Feb. 8, 2016, 2:50 p.m. UTC | #12
Sebastian Frias <sf84@laposte.net> writes:

>>> By the way, I know some people like the command line, email, etc. but
>>> there ought to be other tools better suited for patch review...
>>
>> Some kernel subsystems use http://patchwork.ozlabs.org/ to track status
>> of various patches.
>>
>
> Thanks, I see that netdev is part of it, and that the patches are there:
>
> https://patchwork.ozlabs.org/patch/580217/
>
> seems like a slight layer over plain email and mailinglists; I was
> thinking of something more in the line of
> https://www.gerritcodereview.com/
> I believe Google uses Gerrit for Android.
> I think Gerrit would probably be too big (and being written in Java,
> using Prolog and other DSLs, implementing its own Git server in Java,
> etc, may make some -or lots?- of kernel developers cry :-) )
> However, in Gerrit it is easier to know where in the "review" process
> we are, because people have to explicitly give a score "+/- X" when
> commenting on a patch.
> Also, the diff can operate between different versions of the patches
> themselves to see if the inlined comments were addressed.

Gerrit has some merits, but for seasoned developers it's largely a
nuisance.  It's probably good at keeping junior/undisciplined developers
from doing too much damage by strictly enforcing a cumbersome process.
diff mbox

Patch

diff --git a/drivers/net/ethernet/aurora/nb8800.c 
b/drivers/net/ethernet/aurora/nb8800.c
index ecc4a33..e1fb071 100644
--- a/drivers/net/ethernet/aurora/nb8800.c
+++ b/drivers/net/ethernet/aurora/nb8800.c
@@ -1460,7 +1460,19 @@  static int nb8800_probe(struct platform_device *pdev)
  		goto err_disable_clk;
  	}

-	priv->phy_node = of_parse_phandle(pdev->dev.of_node, "phy-handle", 0);
+	if (of_phy_is_fixed_link(pdev->dev.of_node)) {
+		ret = of_phy_register_fixed_link(pdev->dev.of_node);
+		if (ret < 0) {
+			dev_err(&pdev->dev, "bad fixed-link spec\n");
+			goto err_free_bus;
+		}
+		priv->phy_node = of_node_get(pdev->dev.of_node);
+	}
+
+	if (!priv->phy_node)
+		priv->phy_node = of_parse_phandle(pdev->dev.of_node,
+						  "phy-handle", 0);
+
  	if (!priv->phy_node) {
  		dev_err(&pdev->dev, "no PHY specified\n");
  		ret = -ENODEV;