linux-kernel - Re: [PATCH 5/5] net: phy: dp83867: Use unsigned variables to store unsigned properties

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, 13 May 2019 22:46:41 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     Heiner Kallweit <hkallweit1@...il.com>
Cc:     Trent Piepho <tpiepho@...inj.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "f.fainelli@...il.com" <f.fainelli@...il.com>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>
Subject: Re: [PATCH 5/5] net: phy: dp83867: Use unsigned variables to store
 unsigned properties

> > Perhaps you could tell me if the approach I've taken in patch 3, 
> > "Add ability to disable output clock", and patch 4, "Disable tx/rx
> > delay when not configured", are considered acceptable?  I can conceive
> > of arguments for alternate approaches.  I would like to add support for
> >  these into u-boot too, but typically u-boot follows the kernel DT
> > bindings, so I want to finalize the kernel DT semantics before sending
> > patches to u-boot.
> > 
> I lack experience with these TI PHY's. Maybe Andrew or Florian can advise.

Hi Trent

I already deleted the patches. For patch 3:

+ 	  if (dp83867->clk_output_sel > DP83867_CLK_O_SEL_REF_CLK &&
+	         dp83867->clk_output_sel != DP83867_CLK_O_SEL_OFF) {
+		 	phydev_err(phydev, "ti,clk-output-sel value %u out of range\n",
+				   dp83867->clk_output_sel);
+			return -EINVAL;
+													       }

This last bit looks odd. If it is not OFF, it is invalid?

Are there any in tree users of DP83867_CLK_O_SEL_REF_CLK? We have to
be careful changing its meaning. But if nobody is actually using it...

Patch 4:

This is harder. Ideally we want to fix this. At some point, somebody
is going to want 'rgmii' to actually mean 'rgmii', because that is
what their hardware needs.

Could you add a WARN_ON() for 'rgmii' but the PHY is actually adding a
delay? And add a comment about setting the correct thing in device
tree?  Hopefully we will then get patches correcting DT blobs. And if
we later do need to fix 'rgmii', we will break less board.

> >>> Please note that net-next is closed currently. Please resubmit the
> >>> patches once it's open again, and please annotate them properly
> >>> with net-next.
> > 
> > Sorry, didn't know about this policy.  Been years since I've submitted
> > net patches.  Is there a description somewhere of how this is done? 
> > Googling net-next wasn't helpful.  I gather new patches are only
> > allowed when the kernel merge window is open?  And they can't be queued
> > on patchwork or a topic branch until this happens?

You can post patches while it is closed for review, but add "RFC" in
the subject so it is clear you just want comments. You will still need
to resubmit once it opens up again.

    Andrew