Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1683095
| From | Richard Leitner <richard.leitner@skidata.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH 2/2] net: ethernet: fsl: add phy reset after clk enable option |
| Date | 2017-07-07 12:00 +0200 |
| Message-ID | <u0ydk-2cj-23@gated-at.bofh.it> (permalink) |
| References | <u0eRj-4MZ-11@gated-at.bofh.it> <u0eRj-4MZ-9@gated-at.bofh.it> <u0u9I-7Qw-15@gated-at.bofh.it> <u0uCJ-8iW-5@gated-at.bofh.it> <u0vyO-sw-21@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On 07/07/2017 09:03 AM, Andy Duan wrote: > From: Richard Leitner <richard.leitner@skidata.com> Sent: Friday, July 07, 2017 1:51 PM >>> Since it is common issue so long as using the PHY, can you move it into smsc >> phy driver like in .smsc_phy_reset() function ? >>> And get the reset pin from phy dts node. >> >> Some more points that come into my mind: >> - The smsc_phy_reset function is registered as "soft_reset". Would it be OK to >> use nRST in it? > > It is not reasonable. > >> - Would it be OK to call the phy_init_hw function from within the >> smsc_phy_reset? > > No, phy_init_hw() already call .drv->soft_reset(). > >> - IMHO I'd have to move the reset gpio binding inside the phy node then. Isn't >> that a pretty big change doing that for all PHYs/FECs? Would it be "worth" it? >> > To make the change to be common, there have big change for phy driver. > Maybe somebody can give one good suggestion/solution for it. Sorry, I don't think I understood everything correctly: 1. The "phy-reset-gpios" binding should go inside the phy node. This will cause to *change ALL FEC and PHY drivers*. Correct? 2. Add an additonal "hard reset" function to the PHY driver which handles the "phy-reset-gpios". Correct? 3. Who should then trigger the "hard reset" of the PHY? phy_init_hw? The FEC? The point is that the LAN8710 is currently not always working correctly, therefore this small change was proposed. Should we really change all PHY/FECs only because of this? Furthermore one problem still remains: The enet_refclk is controlled by the FEC. How does the PHY recognize when it was disabled/enabled? > > Andy > kind regards, Richard.L
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
[PATCH 2/2] net: ethernet: fsl: add phy reset after clk enable option Richard Leitner <richard.leitner@skidata.com> - 2017-07-06 15:20 +0200
Re: [PATCH 2/2] net: ethernet: fsl: add phy reset after clk enable option Andrew Lunn <andrew@lunn.ch> - 2017-07-06 16:00 +0200
Re: [PATCH 2/2] net: ethernet: fsl: add phy reset after clk enable option Richard Leitner <richard.leitner@skidata.com> - 2017-07-06 16:40 +0200
RE: [PATCH 2/2] net: ethernet: fsl: add phy reset after clk enable option Andy Duan <fugang.duan@nxp.com> - 2017-07-07 07:40 +0200
Re: [PATCH 2/2] net: ethernet: fsl: add phy reset after clk enable option Richard Leitner <richard.leitner@skidata.com> - 2017-07-07 08:10 +0200
RE: [PATCH 2/2] net: ethernet: fsl: add phy reset after clk enable option Andy Duan <fugang.duan@nxp.com> - 2017-07-07 09:10 +0200
Re: [PATCH 2/2] net: ethernet: fsl: add phy reset after clk enable option Richard Leitner <richard.leitner@skidata.com> - 2017-07-07 12:00 +0200
RE: [PATCH 2/2] net: ethernet: fsl: add phy reset after clk enable option Andy Duan <fugang.duan@nxp.com> - 2017-07-07 13:10 +0200
Re: [PATCH 2/2] net: ethernet: fsl: add phy reset after clk enable option Richard Leitner <richard.leitner@skidata.com> - 2017-07-07 13:20 +0200
Re: [PATCH 2/2] net: ethernet: fsl: add phy reset after clk enable option Andrew Lunn <andrew@lunn.ch> - 2017-07-07 16:10 +0200
Re: [PATCH 2/2] net: ethernet: fsl: add phy reset after clk enable option Richard Leitner <richard.leitner@skidata.com> - 2017-07-12 11:40 +0200
Re: [PATCH 2/2] net: ethernet: fsl: add phy reset after clk enable option Andrew Lunn <andrew@lunn.ch> - 2017-07-12 15:50 +0200
Re: [PATCH 2/2] net: ethernet: fsl: add phy reset after clk enable option Rob Herring <robh@kernel.org> - 2017-07-10 15:30 +0200
csiph-web