lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 08 Feb 2016 11:34:44 +0100
From:	Sebastian Frias <sf84@...oste.net>
To:	Måns Rullgård <mans@...sr.com>
CC:	"David S. Miller" <davem@...emloft.net>, netdev@...r.kernel.org,
	LKML <linux-kernel@...r.kernel.org>, mason <slash.tmp@...e.fr>
Subject: Re: [PATCH v3] net: ethernet: support "fixed-link" DT node on nb8800
 driver

On 02/05/2016 04:26 PM, Måns Rullgård wrote:
> Sebastian Frias <sf84@...oste.net> writes:
>
>> On 02/05/2016 04:08 PM, Måns Rullgård wrote:
>>> Sebastian Frias <sf84@...oste.net> writes:
>>>
>>>> On 02/05/2016 03:34 PM, Måns Rullgård wrote:
>>>>> Sebastian Frias <sf84@...oste.net> writes:
>>>>>
>>>>>> Signed-off-by: Sebastian Frias <sf84@...oste.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
>>>>>
>>>
>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ