linux-toradex.git/drivers/net/phy/dp83640.c, branch v4.4.156

dp83640: Ensure against premature access to PHY registers after reset

2018-05-30T05:49:08+00:00

[ Upstream commit 76327a35caabd1a932e83d6a42b967aa08584e5d ]

The datasheet specifies a 3uS pause after performing a software
reset. The default implementation of genphy_soft_reset() does not
provide this, so implement soft_reset with the needed pause.

Signed-off-by: Esben Haabendal 
Reviewed-by: Andrew Lunn 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

net: dp83640: Avoid NULL pointer dereference.

2017-07-21T05:44:54+00:00

commit db9d8b29d19d2801793e4419f4c6272bf8951c62 upstream.

The function, skb_complete_tx_timestamp(), used to allow passing in a
NULL pointer for the time stamps, but that was changed in commit
62bccb8cdb69051b95a55ab0c489e3cab261c8ef ("net-timestamp: Make the
clone operation stand-alone from phy timestamping"), and the existing
call sites, all of which are in the dp83640 driver, were fixed up.

Even though the kernel-doc was subsequently updated in commit
7a76a021cd5a292be875fbc616daf03eab1e6996 ("net-timestamp: Update
skb_complete_tx_timestamp comment"), still a bug fix from Manfred
Rudigier came into the driver using the old semantics.  Probably
Manfred derived that patch from an older kernel version.

This fix should be applied to the stable trees as well.

Fixes: 81e8f2e930fe ("net: dp83640: Fix tx timestamp overflow handling.")
Signed-off-by: Richard Cochran 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

dp83640: don't recieve time stamps twice

2017-05-03T04:19:53+00:00

[ Upstream commit 9d386cd9a755c8293e8916264d4d053878a7c9c7 ]

This patch is prompted by a static checker warning about a potential
use after free.  The concern is that netif_rx_ni() can free "skb" and we
call it twice.

When I look at the commit that added this, it looks like some stray
lines were added accidentally.  It doesn't make sense to me that we
would recieve the same data two times.  I asked the author but never
recieved a response.

I can't test this code, but I'm pretty sure my patch is correct.

Fixes: 4b063258ab93 ("dp83640: Delay scheduled work.")
Signed-off-by: Dan Carpenter 
Acked-by: Stefan Sørensen 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

net: dp83640: Fix tx timestamp overflow handling.

2016-03-03T23:07:04+00:00

[ Upstream commit 81e8f2e930fe76b9814c71b9d87c30760b5eb705 ]

PHY status frames are not reliable, the PHY may not be able to send them
during heavy receive traffic. This overflow condition is signaled by the
PHY in the next status frame, but the driver did not make use of it.
Instead it always reported wrong tx timestamps to user space after an
overflow happened because it assigned newly received tx timestamps to old
packets in the queue.

This commit fixes this issue by clearing the tx timestamp queue every time
an overflow happens, so that no timestamps are delivered for overflow
packets. This way time stamping will continue correctly after an overflow.

Signed-off-by: Manfred Rudigier 
Acked-by: Richard Cochran 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

dp83640: Only wait for timestamps for packets with timestamping enabled.

2015-11-03T16:08:22+00:00

In the packet timestamping function, check that the ptp version and
protocol of the packet matches what we have configured the hardware to
actually generate timestamps for, before looking/waiting for a timestamp.

Signed-off-by: Stefan Sørensen 
Signed-off-by: David S. Miller

dp83640: Prune rx timestamp list before reading from it

2015-11-03T16:08:21+00:00

The list of rx timestamps are currently only pruned of old entries when a
new entry is inserted. If no new entries are added, old timestamps may
survive beyond their lifetime, possible causing them to be attached to
packets with the same sequence number after a rollover.

Signed-off-by: Stefan Sørensen 
Signed-off-by: David S. Miller

dp83640: Delay scheduled work.

2015-11-03T16:08:21+00:00

Currently rx_timestamp_work reschedules itself as a regular workqueue item,
effectively causing it run constantly as long as there are packets left in
the queue. Fix by using delayed workqueue items, limiting it to run only
every two jiffies.

Signed-off-by: Stefan Sørensen 
Signed-off-by: David S. Miller

dp83640: Include hash in timestamp/packet matching

2015-11-03T16:08:21+00:00

Only using the message type and sequence id for matching timestamps
with packets is error prone, as multiple clients may very well be
sending packets with the same messagetype and timestamp at the same
time. Fix by extending the check to include the hash of bytes 20-29
(source id in PTPv2) that is provided with the timestamps.

Signed-off-by: Stefan Sørensen 
Signed-off-by: David S. Miller

dp83640: only report generic filters in ts_info

2015-07-18T02:59:06+00:00

Signed-off-by: Jacob Keller 
Acked-by: Richard Cochran 
Signed-off-by: Jeff Kirsher

net: dp83640: fix improper double spin locking.

2015-05-25T22:21:59+00:00

A pair of nested spin locks was introduced in commit 63502b8d0
"dp83640: Fix receive timestamp race condition".

Unfortunately the 'flags' parameter was reused for the inner lock,
clobbering the originally saved IRQ state.  This patch fixes the issue
by changing the inner lock to plain spin_lock without irqsave.

Signed-off-by: Richard Cochran 
Signed-off-by: David S. Miller