From: David Rivshin
If a fixed-link DT subnode is used, the phy_device was looked up so
that a PHY ID string could be constructed and passed to phy_connect().
This is not necessary, as the device_node can be passed directly to
of_phy_connect() instead. This reuses the same codepath as if the
phy-
From: David Rivshin
The phy-handle, phy_id, and fixed-link properties are mutually exclusive,
and only one need be specified. Make this clear in the binding doc.
Also mark the phy_id property as deprecated, as phy-handle should be
used instead.
Signed-off-by: David Rivshin
---
Changes since v
From: David Rivshin
The phy-mode emac property was only being processed in the phy_id
or fixed-link cases. However if phy-handle was specified instead,
an error message would complain about the lack of phy_id or
fixed-link, and then jump past the of_get_phy_mode(). This would
result in the PHY mo
From: David Rivshin
If an emac node has a phy-handle property that points to something
which is not a phy, then a segmentation fault will occur when the
interface is brought up. This is because while phy_connect() will
return ERR_PTR() on failure, of_phy_connect() will return NULL.
The common err
From: David Rivshin
Commit 9e42f715264ff158478fa30eaed847f6e131366b ("drivers: net: cpsw: add
phy-handle parsing") saved the "phy-handle" phandle into a new cpsw_priv
field. However, phy connections are per-slave, so the phy_node field should
be in cpsw_slave_data rather than cpsw_priv.
This wou
From: David Rivshin
This series fixes a number of related issues around using phy-handle
properties in cpsw emac nodes.
Patch 1 fixes a bug if more than one slave is used, and either
slave uses the phy-handle property in the devicetree.
Patch 2 fixes a NULL pointer dereference which can occur i
On Mon, 25 Apr 2016 22:14:07 +0300
Grygorii Strashko wrote:
> On 04/22/2016 04:03 PM, Grygorii Strashko wrote:
> > On 04/21/2016 09:19 PM, David Rivshin (Allworx) wrote:
> >> From: David Rivshin
> >>
> >> Commit 9e42f715264ff158478fa30eaed847f6e131366
On Mon, 25 Apr 2016 22:12:20 +0300
Grygorii Strashko wrote:
> On 04/22/2016 06:45 PM, David Rivshin (Allworx) wrote:
> > On Fri, 22 Apr 2016 16:03:34 +0300
> > Grygorii Strashko wrote:
> >
> >> On 04/21/2016 09:26 PM, David Rivshin (Allworx) wrot
On Fri, 22 Apr 2016 16:03:34 +0300
Grygorii Strashko wrote:
> On 04/21/2016 09:26 PM, David Rivshin (Allworx) wrote:
> > From: David Rivshin
> >
> > The phy-handle, phy_id, and fixed-link properties are mutually exclusive,
> > and only one need be specified. However
From: David Rivshin
If a fixed-link DT subnode is used, the phy_device was looked up so
that a PHY ID string could be constructed and passed to phy_connect().
This is not necessary, as the device_node can be passed directly to
of_phy_connect() instead. This reuses the same codepath as if the
phy-
From: David Rivshin
The phy-handle, phy_id, and fixed-link properties are mutually exclusive,
and only one need be specified. However if phy-handle was specified, an
error message would complain about the lack of phy_id or fixed-link.
Also, if phy-handle was specified and the subsequent of_phy_c
From: David Rivshin
Commit 9e42f715264ff158478fa30eaed847f6e131366b ("drivers: net: cpsw: add
phy-handle parsing") saved the "phy-handle" phandle into a new cpsw_priv
field. However, phy connections are per-slave, so the phy_node field should
be in cpsw_slave_data rather than cpsw_priv.
This wou
From: David Rivshin
The first patch fixes a bug that makes dual_emac mode break if
either slave uses the phy-handle property in the devicetree.
The second patch fixes some cosmetic problems with error messages,
and also makes the binding documentation more explicit.
The third patch cleans up th
know.
For tonight, I guess I have no choice but to give up. I'll try again
tomorrow in hopes gmail becomes sane again.
On Wed, 20 Apr 2016 23:24:39 -0400
"David Rivshin (Allworx)" wrote:
> From: David Rivshin
>
> The first patch fixes a bug that makes dual_emac mode
From: David Rivshin
The first patch fixes a bug that makes dual_emac mode break if
either slave uses the phy-handle property in the devicetree.
The second patch fixes some cosmetic problems with error messages,
and also makes the binding documentation more explicit.
The third patch cleans up th
From: David Rivshin
The first patch fixes a bug that makes dual_emac mode break if
either slave uses the phy-handle property in the devicetree.
The second patch fixes some cosmetic problems with error messages,
and also makes the binding documentation more explicit.
The third patch cleans up th
On Tue, 19 Apr 2016 18:43:39 -0400 (EDT)
David Miller wrote:
> From: Grygorii Strashko
> Date: Tue, 19 Apr 2016 21:44:09 +0300
>
> > May be you can send revert + your patch 1 (only fix for this issue).
> >
> > Dave, Does that sound good to you?
>
> Sure.
OK, I will hopefully have that read
On Tue, 19 Apr 2016 18:44:41 +0300
Grygorii Strashko wrote:
> On 04/19/2016 06:01 PM, David Rivshin (Allworx) wrote:
> > On Tue, 19 Apr 2016 17:41:07 +0300
> > Grygorii Strashko wrote:
> >
> >> Hi,
> >>
> >> On 04/19/2016 04:56 PM, Andrew
On Tue, 19 Apr 2016 17:41:07 +0300
Grygorii Strashko wrote:
> Hi,
>
> On 04/19/2016 04:56 PM, Andrew Goodbody wrote:
> > Adding a 2nd PHY to cpsw results in a NULL pointer dereference
> > as below. Fix by maintaining a reference to each PHY node in slave
> > struct instead of a single reference
On Wed, 23 Dec 2015 20:18:16 -0500
"David Rivshin (Allworx)" wrote:
> On Thu, 24 Dec 2015 00:34:49 +0100
> Nicolas Chauvet wrote:
>
> > 2015-12-23 22:54 GMT+01:00 David Rivshin (Allworx) <
> > drivshin.allw...@gmail.com>:
> >
> > &
From: David Rivshin
The cpsw-phy-sel driver supports only MII, RMII, and RGMII PHY modes,
and silently handled any other values as if MII was specified. In a
case where the PHY mode was incorrectly specified, or a bug elsewhere,
there would be no indication of a problem. If MII was the correct mo
On Thu, 24 Dec 2015 00:34:49 +0100
Nicolas Chauvet wrote:
> 2015-12-23 22:54 GMT+01:00 David Rivshin (Allworx) <
> drivshin.allw...@gmail.com>:
>
> > On Wed, 23 Dec 2015 22:20:58 +0100
> > Nicolas Chauvet wrote:
> >
> > > 2015-12-23 1:36 GMT+01:00 Dav
On Wed, 23 Dec 2015 22:20:58 +0100
Nicolas Chauvet wrote:
> 2015-12-23 1:36 GMT+01:00 David Rivshin (Allworx) <
> drivshin.allw...@gmail.com>:
>
> > From: David Rivshin
> >
> > This series is based on the tip of the net tree.
> >
> > The first patc
On Wed, 23 Dec 2015 19:35:37 +0100
Markus Brunner wrote:
> On Wednesday 23 December 2015 12:04:25 David Miller wrote:
> > From: "David Rivshin (Allworx)"
> > Date: Tue, 22 Dec 2015 19:36:31 -0500
> >
> > > Testing by anyone who has real hardware using
From: David Rivshin
If a fixed-link DT subnode is used, the phy_device was looked up so
that a PHY ID string could be constructed and passed to phy_connect().
This is not necessary, as the device_node can be passed directly to
of_phy_connect() instead. This reuses the same codepath as if the
phy-
From: David Rivshin
Commit 9e42f715264ff158478fa30eaed847f6e131366b ("drivers: net: cpsw: add
phy-handle parsing") saved the "phy-handle" phandle into a new cpsw_priv
field. However, phy connections are per-slave, so the phy_node field should
be in cpsw_slave_data rather than cpsw_priv.
This wou
From: David Rivshin
The phy-handle, phy_id, and fixed-link properties are mutually exclusive,
and only one need be specified. However if phy-handle was specified, an
error message would complain about the lack of phy_id or fixed-link.
Also, if phy-handle was specified and the subsequent of_phy_c
From: David Rivshin
This series is based on the tip of the net tree.
The first patch fixes a bug that makes dual_emac mode break if
either slave uses the phy-handle property in the devicetree.
The second patch fixes some cosmetic problems with error messages,
and also makes the binding document
On Fri, 18 Dec 2015 11:20:21 +0100
Daniel Trautmann wrote:
> On Thu, Dec 17, 2015 at 03:45:08PM -0500, David Miller wrote:
> > From: "David Rivshin (Allworx)"
> > Date: Wed, 16 Dec 2015 23:02:08 -0500
> >
> > > I have tested on the following hardware co
On Thu, 17 Dec 2015 12:04:48 -0500 (EST)
David Miller wrote:
> From: Johannes Berg
> Date: Thu, 17 Dec 2015 13:44:32 +0100
>
> > On Wed, 2015-12-16 at 18:34 -0500, David Miller wrote:
> >>
> >> Something about your text encoding kept this from ending up
> >> in patchwork for some reason.
> >>
On Wed, 16 Dec 2015 07:39:16 +0100
Markus Brunner wrote:
> On Monday 14 December 2015 13:04:46 David Rivshin wrote:
> > On Sat, 12 Dec 2015 16:44:19 +0100
> ...
> > > Your patch works fine on my board, which uses MII and dual_emac
> > > with a fixed_phy and a real one.
> >
> > Thanks for checkin
From: David Rivshin
When a fixed-link sub-node exists in a slave node, the slave node
is also the PHY node. Since this is a separate use of the slave node,
of_node_get() should be used to increment the reference count.
Fixes: 1f71e8c96fc6 ("drivers: net: cpsw: Add support for fixed-link PHY")
Si
From: Pascal Speck (Iktek)
Date: Fri, 04 Dec 2015 16:55:17 +0100
When using more than one slave with ti cpsw and fixed phy the pd->phy_id
will be always zero, but slave_data->phy_id must be unique. pd->phy_id
means a "phy hardware id" whereas slave_data->phy_id means an "unique id",
so we should
Commit 1f71e8c96fc654724723ce987e0a8b2aeb81746d ("drivers: net: cpsw:
Add support for fixed-link PHY") added initial fixed-link PHY support
for CPSW, but missed a few considerations.
This series is based on the tip of the net tree. The first two patches
fix user-visible errors in different hardwar
From: David Rivshin
Commit 1f71e8c96fc654724723ce987e0a8b2aeb81746d ("drivers: net: cpsw: Add
support for fixed-link PHY") did not parse the "phy-mode" property in
the case of a fixed-link PHY, leaving slave_data->phy_if with its default
of PHY_INTERFACE_MODE_NA(0). This later gets passed to phy_
On Sat, 12 Dec 2015 16:44:19 +0100
Markus Brunner wrote:
> On Wednesday 09 December 2015 22:31:15 David Rivshin wrote:
> ...
> > This patch was originally developed in parallel with 1f71e8c96fc6 to
> > accomplish the same goal. When I replaced this patch with
> > 1f71e8c96fc6, I found that it did
rnel log messages seem to indicate
that the interface is set up, there is no network communication. Eventually
a watchdog error occurs:
NETDEV WATCHDOG: eth0 (cpsw): transmit queue 0 timed out
Signed-off-by: David Rivshin (Allworx)
Fixes: 1f71e8c96fc6 ("drivers: net: cpsw: Add support for
37 matches
Mail list logo
