* [PATCH net-next v3 6/8] net: mscc: improve the frame header parsing readability
From: Antoine Tenart @ 2019-07-24 8:17 UTC (permalink / raw)
To: davem, richardcochran, alexandre.belloni, UNGLinuxDriver, ralf,
paul.burton, jhogan
Cc: Antoine Tenart, netdev, linux-mips, thomas.petazzoni,
allan.nielsen
In-Reply-To: <20190724081715.29159-1-antoine.tenart@bootlin.com>
This cosmetic patch improves the frame header parsing readability by
introducing a new macro to access and mask its fields.
Signed-off-by: Antoine Tenart <antoine.tenart@bootlin.com>
---
drivers/net/ethernet/mscc/ocelot_board.c | 24 +++++++++++++-----------
1 file changed, 13 insertions(+), 11 deletions(-)
diff --git a/drivers/net/ethernet/mscc/ocelot_board.c b/drivers/net/ethernet/mscc/ocelot_board.c
index 990027f04d1b..5e4f1718dd99 100644
--- a/drivers/net/ethernet/mscc/ocelot_board.c
+++ b/drivers/net/ethernet/mscc/ocelot_board.c
@@ -16,24 +16,26 @@
#include "ocelot.h"
-static int ocelot_parse_ifh(u32 *ifh, struct frame_info *info)
+#define IFH_EXTRACT_BITFIELD64(x, o, w) (((x) >> (o)) & GENMASK_ULL((w) - 1, 0))
+
+static int ocelot_parse_ifh(u32 *_ifh, struct frame_info *info)
{
- int i;
u8 llen, wlen;
+ u64 ifh[2];
+
+ ifh[0] = be64_to_cpu(((__force __be64 *)_ifh)[0]);
+ ifh[1] = be64_to_cpu(((__force __be64 *)_ifh)[1]);
- /* The IFH is in network order, switch to CPU order */
- for (i = 0; i < IFH_LEN; i++)
- ifh[i] = ntohl((__force __be32)ifh[i]);
+ wlen = IFH_EXTRACT_BITFIELD64(ifh[0], 7, 8);
+ llen = IFH_EXTRACT_BITFIELD64(ifh[0], 15, 6);
- wlen = (ifh[1] >> 7) & 0xff;
- llen = (ifh[1] >> 15) & 0x3f;
info->len = OCELOT_BUFFER_CELL_SZ * wlen + llen - 80;
- info->port = (ifh[2] & GENMASK(14, 11)) >> 11;
+ info->port = IFH_EXTRACT_BITFIELD64(ifh[1], 43, 4);
- info->cpuq = (ifh[3] & GENMASK(27, 20)) >> 20;
- info->tag_type = (ifh[3] & BIT(16)) >> 16;
- info->vid = ifh[3] & GENMASK(11, 0);
+ info->cpuq = IFH_EXTRACT_BITFIELD64(ifh[1], 20, 8);
+ info->tag_type = IFH_EXTRACT_BITFIELD64(ifh[1], 16, 1);
+ info->vid = IFH_EXTRACT_BITFIELD64(ifh[1], 0, 12);
return 0;
}
--
2.21.0
^ permalink raw reply related
* [PATCH net-next v3 0/8] net: mscc: PTP Hardware Clock (PHC) support
From: Antoine Tenart @ 2019-07-24 8:17 UTC (permalink / raw)
To: davem, richardcochran, alexandre.belloni, UNGLinuxDriver, ralf,
paul.burton, jhogan
Cc: Antoine Tenart, netdev, linux-mips, thomas.petazzoni,
allan.nielsen
Hello,
This series introduces the PTP Hardware Clock (PHC) support to the Mscc
Ocelot switch driver. In order to make use of this, a new register bank
is added and described in the device tree, as well as a new interrupt.
The use this bank and interrupt was made optional in the driver for dt
compatibility reasons.
Patches 2 and 4 should probably go through the MIPS tree.
Thanks!
Antoine
Since v2:
- Prevented from a possible infinite loop when reading the h/w
timestamps.
- s/GFP_KERNEL/GFP_ATOMIC/ in the Tx path.
- Set rx_filter to HWTSTAMP_FILTER_PTP_V2_EVENT at probe.
- Fixed s/w timestamping dependencies.
- Added Paul Burton's Acked-by on patches 2 and 4.
Since v1:
- Used list_for_each_safe() in ocelot_deinit().
- Fixed a memory leak in ocelot_deinit() by calling
dev_kfree_skb_any().
- Fixed a locking issue in get_hwtimestamp().
- Handled the NULL case of ptp_clock_register().
- Added comments on optional dt properties.
Antoine Tenart (8):
Documentation/bindings: net: ocelot: document the PTP bank
MIPS: dts: mscc: describe the PTP register range
Documentation/bindings: net: ocelot: document the PTP ready IRQ
MIPS: dts: mscc: describe the PTP ready interrupt
net: mscc: describe the PTP register range
net: mscc: improve the frame header parsing readability
net: mscc: remove the frame_info cpuq member
net: mscc: PTP Hardware Clock (PHC) support
.../devicetree/bindings/net/mscc-ocelot.txt | 20 +-
arch/mips/boot/dts/mscc/ocelot.dtsi | 7 +-
drivers/net/ethernet/mscc/ocelot.c | 394 +++++++++++++++++-
drivers/net/ethernet/mscc/ocelot.h | 49 ++-
drivers/net/ethernet/mscc/ocelot_board.c | 144 ++++++-
drivers/net/ethernet/mscc/ocelot_ptp.h | 41 ++
drivers/net/ethernet/mscc/ocelot_regs.c | 11 +
7 files changed, 634 insertions(+), 32 deletions(-)
create mode 100644 drivers/net/ethernet/mscc/ocelot_ptp.h
--
2.21.0
^ permalink raw reply
* [PATCH net-next v3 7/8] net: mscc: remove the frame_info cpuq member
From: Antoine Tenart @ 2019-07-24 8:17 UTC (permalink / raw)
To: davem, richardcochran, alexandre.belloni, UNGLinuxDriver, ralf,
paul.burton, jhogan
Cc: Antoine Tenart, netdev, linux-mips, thomas.petazzoni,
allan.nielsen
In-Reply-To: <20190724081715.29159-1-antoine.tenart@bootlin.com>
In struct frame_info, the cpuq member is never used. This cosmetic patch
removes it from the structure, and from the parsing of the frame header
as it's only set but never used.
Signed-off-by: Antoine Tenart <antoine.tenart@bootlin.com>
---
drivers/net/ethernet/mscc/ocelot.h | 1 -
drivers/net/ethernet/mscc/ocelot_board.c | 1 -
2 files changed, 2 deletions(-)
diff --git a/drivers/net/ethernet/mscc/ocelot.h b/drivers/net/ethernet/mscc/ocelot.h
index e0da8b4eddf2..515dee6fa8a6 100644
--- a/drivers/net/ethernet/mscc/ocelot.h
+++ b/drivers/net/ethernet/mscc/ocelot.h
@@ -45,7 +45,6 @@ struct frame_info {
u32 len;
u16 port;
u16 vid;
- u8 cpuq;
u8 tag_type;
};
diff --git a/drivers/net/ethernet/mscc/ocelot_board.c b/drivers/net/ethernet/mscc/ocelot_board.c
index 5e4f1718dd99..df8d15994a89 100644
--- a/drivers/net/ethernet/mscc/ocelot_board.c
+++ b/drivers/net/ethernet/mscc/ocelot_board.c
@@ -33,7 +33,6 @@ static int ocelot_parse_ifh(u32 *_ifh, struct frame_info *info)
info->port = IFH_EXTRACT_BITFIELD64(ifh[1], 43, 4);
- info->cpuq = IFH_EXTRACT_BITFIELD64(ifh[1], 20, 8);
info->tag_type = IFH_EXTRACT_BITFIELD64(ifh[1], 16, 1);
info->vid = IFH_EXTRACT_BITFIELD64(ifh[1], 0, 12);
--
2.21.0
^ permalink raw reply related
* [PATCH net-next v3 8/8] net: mscc: PTP Hardware Clock (PHC) support
From: Antoine Tenart @ 2019-07-24 8:17 UTC (permalink / raw)
To: davem, richardcochran, alexandre.belloni, UNGLinuxDriver, ralf,
paul.burton, jhogan
Cc: Antoine Tenart, netdev, linux-mips, thomas.petazzoni,
allan.nielsen
In-Reply-To: <20190724081715.29159-1-antoine.tenart@bootlin.com>
This patch adds support for PTP Hardware Clock (PHC) to the Ocelot
switch for both PTP 1-step and 2-step modes.
Signed-off-by: Antoine Tenart <antoine.tenart@bootlin.com>
---
drivers/net/ethernet/mscc/ocelot.c | 394 ++++++++++++++++++++++-
drivers/net/ethernet/mscc/ocelot.h | 39 +++
drivers/net/ethernet/mscc/ocelot_board.c | 111 ++++++-
3 files changed, 536 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/mscc/ocelot.c b/drivers/net/ethernet/mscc/ocelot.c
index b71e4ecbe469..4f287202bf03 100644
--- a/drivers/net/ethernet/mscc/ocelot.c
+++ b/drivers/net/ethernet/mscc/ocelot.c
@@ -14,6 +14,7 @@
#include <linux/module.h>
#include <linux/netdevice.h>
#include <linux/phy.h>
+#include <linux/ptp_clock_kernel.h>
#include <linux/skbuff.h>
#include <linux/iopoll.h>
#include <net/arp.h>
@@ -538,7 +539,7 @@ static int ocelot_port_stop(struct net_device *dev)
*/
static int ocelot_gen_ifh(u32 *ifh, struct frame_info *info)
{
- ifh[0] = IFH_INJ_BYPASS;
+ ifh[0] = IFH_INJ_BYPASS | ((0x1ff & info->rew_op) << 21);
ifh[1] = (0xf00 & info->port) >> 8;
ifh[2] = (0xff & info->port) << 24;
ifh[3] = (info->tag_type << 16) | info->vid;
@@ -548,6 +549,7 @@ static int ocelot_gen_ifh(u32 *ifh, struct frame_info *info)
static int ocelot_port_xmit(struct sk_buff *skb, struct net_device *dev)
{
+ struct skb_shared_info *shinfo = skb_shinfo(skb);
struct ocelot_port *port = netdev_priv(dev);
struct ocelot *ocelot = port->ocelot;
u32 val, ifh[IFH_LEN];
@@ -566,6 +568,14 @@ static int ocelot_port_xmit(struct sk_buff *skb, struct net_device *dev)
info.port = BIT(port->chip_port);
info.tag_type = IFH_TAG_TYPE_C;
info.vid = skb_vlan_tag_get(skb);
+
+ /* Check if timestamping is needed */
+ if (ocelot->ptp && shinfo->tx_flags & SKBTX_HW_TSTAMP) {
+ info.rew_op = port->ptp_cmd;
+ if (port->ptp_cmd == IFH_REW_OP_TWO_STEP_PTP)
+ info.rew_op |= (port->ts_id % 4) << 3;
+ }
+
ocelot_gen_ifh(ifh, &info);
for (i = 0; i < IFH_LEN; i++)
@@ -596,11 +606,51 @@ static int ocelot_port_xmit(struct sk_buff *skb, struct net_device *dev)
dev->stats.tx_packets++;
dev->stats.tx_bytes += skb->len;
- dev_kfree_skb_any(skb);
+
+ if (ocelot->ptp && shinfo->tx_flags & SKBTX_HW_TSTAMP &&
+ port->ptp_cmd == IFH_REW_OP_TWO_STEP_PTP) {
+ struct ocelot_skb *oskb =
+ kzalloc(sizeof(struct ocelot_skb), GFP_ATOMIC);
+
+ oskb->skb = skb;
+ oskb->id = port->ts_id % 4;
+ port->ts_id++;
+
+ list_add_tail(&oskb->head, &port->skbs);
+ } else {
+ dev_kfree_skb_any(skb);
+ }
return NETDEV_TX_OK;
}
+void ocelot_get_hwtimestamp(struct ocelot *ocelot, struct timespec64 *ts)
+{
+ unsigned long flags;
+ u32 val;
+
+ spin_lock_irqsave(&ocelot->ptp_clock_lock, flags);
+
+ /* Read current PTP time to get seconds */
+ val = ocelot_read_rix(ocelot, PTP_PIN_CFG, TOD_ACC_PIN);
+
+ val &= ~(PTP_PIN_CFG_SYNC | PTP_PIN_CFG_ACTION_MASK | PTP_PIN_CFG_DOM);
+ val |= PTP_PIN_CFG_ACTION(PTP_PIN_ACTION_SAVE);
+ ocelot_write_rix(ocelot, val, PTP_PIN_CFG, TOD_ACC_PIN);
+ ts->tv_sec = ocelot_read_rix(ocelot, PTP_PIN_TOD_SEC_LSB, TOD_ACC_PIN);
+
+ /* Read packet HW timestamp from FIFO */
+ val = ocelot_read(ocelot, SYS_PTP_TXSTAMP);
+ ts->tv_nsec = SYS_PTP_TXSTAMP_PTP_TXSTAMP(val);
+
+ /* Sec has incremented since the ts was registered */
+ if ((ts->tv_sec & 0x1) != !!(val & SYS_PTP_TXSTAMP_PTP_TXSTAMP_SEC))
+ ts->tv_sec--;
+
+ spin_unlock_irqrestore(&ocelot->ptp_clock_lock, flags);
+}
+EXPORT_SYMBOL(ocelot_get_hwtimestamp);
+
static int ocelot_mc_unsync(struct net_device *dev, const unsigned char *addr)
{
struct ocelot_port *port = netdev_priv(dev);
@@ -917,6 +967,97 @@ static int ocelot_get_port_parent_id(struct net_device *dev,
return 0;
}
+static int ocelot_hwstamp_get(struct ocelot_port *port, struct ifreq *ifr)
+{
+ struct ocelot *ocelot = port->ocelot;
+
+ return copy_to_user(ifr->ifr_data, &ocelot->hwtstamp_config,
+ sizeof(ocelot->hwtstamp_config)) ? -EFAULT : 0;
+}
+
+static int ocelot_hwstamp_set(struct ocelot_port *port, struct ifreq *ifr)
+{
+ struct ocelot *ocelot = port->ocelot;
+ struct hwtstamp_config cfg;
+
+ if (copy_from_user(&cfg, ifr->ifr_data, sizeof(cfg)))
+ return -EFAULT;
+
+ /* reserved for future extensions */
+ if (cfg.flags)
+ return -EINVAL;
+
+ /* Tx type sanity check */
+ switch (cfg.tx_type) {
+ case HWTSTAMP_TX_ON:
+ port->ptp_cmd = IFH_REW_OP_TWO_STEP_PTP;
+ break;
+ case HWTSTAMP_TX_ONESTEP_SYNC:
+ /* IFH_REW_OP_ONE_STEP_PTP updates the correctional field, we
+ * need to update the origin time.
+ */
+ port->ptp_cmd = IFH_REW_OP_ORIGIN_PTP;
+ break;
+ case HWTSTAMP_TX_OFF:
+ port->ptp_cmd = 0;
+ break;
+ default:
+ return -ERANGE;
+ }
+
+ mutex_lock(&ocelot->ptp_lock);
+
+ switch (cfg.rx_filter) {
+ case HWTSTAMP_FILTER_NONE:
+ break;
+ case HWTSTAMP_FILTER_ALL:
+ case HWTSTAMP_FILTER_SOME:
+ case HWTSTAMP_FILTER_PTP_V1_L4_EVENT:
+ case HWTSTAMP_FILTER_PTP_V1_L4_SYNC:
+ case HWTSTAMP_FILTER_PTP_V1_L4_DELAY_REQ:
+ case HWTSTAMP_FILTER_NTP_ALL:
+ case HWTSTAMP_FILTER_PTP_V2_L4_EVENT:
+ case HWTSTAMP_FILTER_PTP_V2_L4_SYNC:
+ case HWTSTAMP_FILTER_PTP_V2_L4_DELAY_REQ:
+ case HWTSTAMP_FILTER_PTP_V2_L2_EVENT:
+ case HWTSTAMP_FILTER_PTP_V2_L2_SYNC:
+ case HWTSTAMP_FILTER_PTP_V2_L2_DELAY_REQ:
+ case HWTSTAMP_FILTER_PTP_V2_EVENT:
+ case HWTSTAMP_FILTER_PTP_V2_SYNC:
+ case HWTSTAMP_FILTER_PTP_V2_DELAY_REQ:
+ cfg.rx_filter = HWTSTAMP_FILTER_PTP_V2_EVENT;
+ break;
+ default:
+ mutex_unlock(&ocelot->ptp_lock);
+ return -ERANGE;
+ }
+
+ /* Commit back the result & save it */
+ memcpy(&ocelot->hwtstamp_config, &cfg, sizeof(cfg));
+ mutex_unlock(&ocelot->ptp_lock);
+
+ return copy_to_user(ifr->ifr_data, &cfg, sizeof(cfg)) ? -EFAULT : 0;
+}
+
+static int ocelot_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd)
+{
+ struct ocelot_port *port = netdev_priv(dev);
+ struct ocelot *ocelot = port->ocelot;
+
+ /* The function is only used for PTP operations for now */
+ if (!ocelot->ptp)
+ return -EOPNOTSUPP;
+
+ switch (cmd) {
+ case SIOCSHWTSTAMP:
+ return ocelot_hwstamp_set(port, ifr);
+ case SIOCGHWTSTAMP:
+ return ocelot_hwstamp_get(port, ifr);
+ default:
+ return -EOPNOTSUPP;
+ }
+}
+
static const struct net_device_ops ocelot_port_netdev_ops = {
.ndo_open = ocelot_port_open,
.ndo_stop = ocelot_port_stop,
@@ -933,6 +1074,7 @@ static const struct net_device_ops ocelot_port_netdev_ops = {
.ndo_set_features = ocelot_set_features,
.ndo_get_port_parent_id = ocelot_get_port_parent_id,
.ndo_setup_tc = ocelot_setup_tc,
+ .ndo_do_ioctl = ocelot_ioctl,
};
static void ocelot_get_strings(struct net_device *netdev, u32 sset, u8 *data)
@@ -1014,12 +1156,37 @@ static int ocelot_get_sset_count(struct net_device *dev, int sset)
return ocelot->num_stats;
}
+static int ocelot_get_ts_info(struct net_device *dev,
+ struct ethtool_ts_info *info)
+{
+ struct ocelot_port *ocelot_port = netdev_priv(dev);
+ struct ocelot *ocelot = ocelot_port->ocelot;
+
+ if (!ocelot->ptp)
+ return ethtool_op_get_ts_info(dev, info);
+
+ info->phc_index = ocelot->ptp_clock ?
+ ptp_clock_index(ocelot->ptp_clock) : -1;
+ info->so_timestamping |= SOF_TIMESTAMPING_TX_SOFTWARE |
+ SOF_TIMESTAMPING_RX_SOFTWARE |
+ SOF_TIMESTAMPING_SOFTWARE |
+ SOF_TIMESTAMPING_TX_HARDWARE |
+ SOF_TIMESTAMPING_RX_HARDWARE |
+ SOF_TIMESTAMPING_RAW_HARDWARE;
+ info->tx_types = BIT(HWTSTAMP_TX_OFF) | BIT(HWTSTAMP_TX_ON) |
+ BIT(HWTSTAMP_TX_ONESTEP_SYNC);
+ info->rx_filters = BIT(HWTSTAMP_FILTER_NONE) | BIT(HWTSTAMP_FILTER_ALL);
+
+ return 0;
+}
+
static const struct ethtool_ops ocelot_ethtool_ops = {
.get_strings = ocelot_get_strings,
.get_ethtool_stats = ocelot_get_ethtool_stats,
.get_sset_count = ocelot_get_sset_count,
.get_link_ksettings = phy_ethtool_get_link_ksettings,
.set_link_ksettings = phy_ethtool_set_link_ksettings,
+ .get_ts_info = ocelot_get_ts_info,
};
static int ocelot_port_attr_stp_state_set(struct ocelot_port *ocelot_port,
@@ -1629,6 +1796,196 @@ struct notifier_block ocelot_switchdev_blocking_nb __read_mostly = {
};
EXPORT_SYMBOL(ocelot_switchdev_blocking_nb);
+int ocelot_ptp_gettime64(struct ptp_clock_info *ptp, struct timespec64 *ts)
+{
+ struct ocelot *ocelot = container_of(ptp, struct ocelot, ptp_info);
+ unsigned long flags;
+ time64_t s;
+ u32 val;
+ s64 ns;
+
+ spin_lock_irqsave(&ocelot->ptp_clock_lock, flags);
+
+ val = ocelot_read_rix(ocelot, PTP_PIN_CFG, TOD_ACC_PIN);
+ val &= ~(PTP_PIN_CFG_SYNC | PTP_PIN_CFG_ACTION_MASK | PTP_PIN_CFG_DOM);
+ val |= PTP_PIN_CFG_ACTION(PTP_PIN_ACTION_SAVE);
+ ocelot_write_rix(ocelot, val, PTP_PIN_CFG, TOD_ACC_PIN);
+
+ s = ocelot_read_rix(ocelot, PTP_PIN_TOD_SEC_MSB, TOD_ACC_PIN) & 0xffff;
+ s <<= 32;
+ s += ocelot_read_rix(ocelot, PTP_PIN_TOD_SEC_LSB, TOD_ACC_PIN);
+ ns = ocelot_read_rix(ocelot, PTP_PIN_TOD_NSEC, TOD_ACC_PIN);
+
+ spin_unlock_irqrestore(&ocelot->ptp_clock_lock, flags);
+
+ /* Deal with negative values */
+ if (ns >= 0x3ffffff0 && ns <= 0x3fffffff) {
+ s--;
+ ns &= 0xf;
+ ns += 999999984;
+ }
+
+ set_normalized_timespec64(ts, s, ns);
+ return 0;
+}
+EXPORT_SYMBOL(ocelot_ptp_gettime64);
+
+static int ocelot_ptp_settime64(struct ptp_clock_info *ptp,
+ const struct timespec64 *ts)
+{
+ struct ocelot *ocelot = container_of(ptp, struct ocelot, ptp_info);
+ unsigned long flags;
+ u32 val;
+
+ spin_lock_irqsave(&ocelot->ptp_clock_lock, flags);
+
+ val = ocelot_read_rix(ocelot, PTP_PIN_CFG, TOD_ACC_PIN);
+ val &= ~(PTP_PIN_CFG_SYNC | PTP_PIN_CFG_ACTION_MASK | PTP_PIN_CFG_DOM);
+ val |= PTP_PIN_CFG_ACTION(PTP_PIN_ACTION_IDLE);
+
+ ocelot_write_rix(ocelot, val, PTP_PIN_CFG, TOD_ACC_PIN);
+
+ ocelot_write_rix(ocelot, lower_32_bits(ts->tv_sec), PTP_PIN_TOD_SEC_LSB,
+ TOD_ACC_PIN);
+ ocelot_write_rix(ocelot, upper_32_bits(ts->tv_sec), PTP_PIN_TOD_SEC_MSB,
+ TOD_ACC_PIN);
+ ocelot_write_rix(ocelot, ts->tv_nsec, PTP_PIN_TOD_NSEC, TOD_ACC_PIN);
+
+ val = ocelot_read_rix(ocelot, PTP_PIN_CFG, TOD_ACC_PIN);
+ val &= ~(PTP_PIN_CFG_SYNC | PTP_PIN_CFG_ACTION_MASK | PTP_PIN_CFG_DOM);
+ val |= PTP_PIN_CFG_ACTION(PTP_PIN_ACTION_LOAD);
+
+ ocelot_write_rix(ocelot, val, PTP_PIN_CFG, TOD_ACC_PIN);
+
+ spin_unlock_irqrestore(&ocelot->ptp_clock_lock, flags);
+ return 0;
+}
+
+static int ocelot_ptp_adjtime(struct ptp_clock_info *ptp, s64 delta)
+{
+ if (delta > -(NSEC_PER_SEC / 2) && delta < (NSEC_PER_SEC / 2)) {
+ struct ocelot *ocelot = container_of(ptp, struct ocelot, ptp_info);
+ unsigned long flags;
+ u32 val;
+
+ spin_lock_irqsave(&ocelot->ptp_clock_lock, flags);
+
+ val = ocelot_read_rix(ocelot, PTP_PIN_CFG, TOD_ACC_PIN);
+ val &= ~(PTP_PIN_CFG_SYNC | PTP_PIN_CFG_ACTION_MASK | PTP_PIN_CFG_DOM);
+ val |= PTP_PIN_CFG_ACTION(PTP_PIN_ACTION_IDLE);
+
+ ocelot_write_rix(ocelot, val, PTP_PIN_CFG, TOD_ACC_PIN);
+
+ ocelot_write_rix(ocelot, 0, PTP_PIN_TOD_SEC_LSB, TOD_ACC_PIN);
+ ocelot_write_rix(ocelot, 0, PTP_PIN_TOD_SEC_MSB, TOD_ACC_PIN);
+ ocelot_write_rix(ocelot, delta, PTP_PIN_TOD_NSEC, TOD_ACC_PIN);
+
+ val = ocelot_read_rix(ocelot, PTP_PIN_CFG, TOD_ACC_PIN);
+ val &= ~(PTP_PIN_CFG_SYNC | PTP_PIN_CFG_ACTION_MASK | PTP_PIN_CFG_DOM);
+ val |= PTP_PIN_CFG_ACTION(PTP_PIN_ACTION_DELTA);
+
+ ocelot_write_rix(ocelot, val, PTP_PIN_CFG, TOD_ACC_PIN);
+
+ spin_unlock_irqrestore(&ocelot->ptp_clock_lock, flags);
+ } else {
+ /* Fall back using ocelot_ptp_settime64 which is not exact. */
+ struct timespec64 ts;
+ u64 now;
+
+ ocelot_ptp_gettime64(ptp, &ts);
+
+ now = ktime_to_ns(timespec64_to_ktime(ts));
+ ts = ns_to_timespec64(now + delta);
+
+ ocelot_ptp_settime64(ptp, &ts);
+ }
+ return 0;
+}
+
+static int ocelot_ptp_adjfine(struct ptp_clock_info *ptp, long scaled_ppm)
+{
+ struct ocelot *ocelot = container_of(ptp, struct ocelot, ptp_info);
+ u32 unit = 0, direction = 0;
+ unsigned long flags;
+ u64 adj = 0;
+
+ if (!scaled_ppm)
+ goto disable_adj;
+
+ if (scaled_ppm < 0) {
+ direction = PTP_CFG_CLK_ADJ_CFG_DIR;
+ scaled_ppm = -scaled_ppm;
+ }
+
+ adj = PSEC_PER_SEC << 16;
+ do_div(adj, scaled_ppm);
+ do_div(adj, 1000);
+
+ /* If the adjustment value is too large, use ns instead */
+ if (adj >= (1L << 30)) {
+ unit = PTP_CFG_CLK_ADJ_FREQ_NS;
+ do_div(adj, 1000);
+ }
+
+ spin_lock_irqsave(&ocelot->ptp_clock_lock, flags);
+
+ /* Still too big */
+ if (adj >= (1L << 30))
+ goto disable_adj;
+
+ ocelot_write(ocelot, unit | adj, PTP_CLK_CFG_ADJ_FREQ);
+ ocelot_write(ocelot, PTP_CFG_CLK_ADJ_CFG_ENA | direction,
+ PTP_CLK_CFG_ADJ_CFG);
+
+ spin_unlock_irqrestore(&ocelot->ptp_clock_lock, flags);
+ return 0;
+
+disable_adj:
+ ocelot_write(ocelot, 0, PTP_CLK_CFG_ADJ_CFG);
+
+ spin_unlock_irqrestore(&ocelot->ptp_clock_lock, flags);
+ return 0;
+}
+
+static struct ptp_clock_info ocelot_ptp_clock_info = {
+ .owner = THIS_MODULE,
+ .name = "ocelot ptp",
+ .max_adj = 0x7fffffff,
+ .n_alarm = 0,
+ .n_ext_ts = 0,
+ .n_per_out = 0,
+ .n_pins = 0,
+ .pps = 0,
+ .gettime64 = ocelot_ptp_gettime64,
+ .settime64 = ocelot_ptp_settime64,
+ .adjtime = ocelot_ptp_adjtime,
+ .adjfine = ocelot_ptp_adjfine,
+};
+
+static int ocelot_init_timestamp(struct ocelot *ocelot)
+{
+ ocelot->ptp_info = ocelot_ptp_clock_info;
+ ocelot->ptp_clock = ptp_clock_register(&ocelot->ptp_info, ocelot->dev);
+ if (IS_ERR(ocelot->ptp_clock))
+ return PTR_ERR(ocelot->ptp_clock);
+ /* Check if PHC support is missing at the configuration level */
+ if (!ocelot->ptp_clock)
+ return 0;
+
+ ocelot_write(ocelot, SYS_PTP_CFG_PTP_STAMP_WID(30), SYS_PTP_CFG);
+ ocelot_write(ocelot, 0xffffffff, ANA_TABLES_PTP_ID_LOW);
+ ocelot_write(ocelot, 0xffffffff, ANA_TABLES_PTP_ID_HIGH);
+
+ ocelot_write(ocelot, PTP_CFG_MISC_PTP_EN, PTP_CFG_MISC);
+
+ /* There is no device reconfiguration, PTP Rx stamping is always
+ * enabled.
+ */
+ ocelot->hwtstamp_config.rx_filter = HWTSTAMP_FILTER_PTP_V2_EVENT;
+
+ return 0;
+}
+
int ocelot_probe_port(struct ocelot *ocelot, u8 port,
void __iomem *regs,
struct phy_device *phy)
@@ -1661,6 +2018,8 @@ int ocelot_probe_port(struct ocelot *ocelot, u8 port,
ocelot_mact_learn(ocelot, PGID_CPU, dev->dev_addr, ocelot_port->pvid,
ENTRYTYPE_LOCKED);
+ INIT_LIST_HEAD(&ocelot_port->skbs);
+
err = register_netdev(dev);
if (err) {
dev_err(ocelot->dev, "register_netdev failed\n");
@@ -1684,7 +2043,7 @@ EXPORT_SYMBOL(ocelot_probe_port);
int ocelot_init(struct ocelot *ocelot)
{
u32 port;
- int i, cpu = ocelot->num_phys_ports;
+ int i, ret, cpu = ocelot->num_phys_ports;
char queue_name[32];
ocelot->lags = devm_kcalloc(ocelot->dev, ocelot->num_phys_ports,
@@ -1699,6 +2058,8 @@ int ocelot_init(struct ocelot *ocelot)
return -ENOMEM;
mutex_init(&ocelot->stats_lock);
+ mutex_init(&ocelot->ptp_lock);
+ spin_lock_init(&ocelot->ptp_clock_lock);
snprintf(queue_name, sizeof(queue_name), "%s-stats",
dev_name(ocelot->dev));
ocelot->stats_queue = create_singlethread_workqueue(queue_name);
@@ -1812,15 +2173,42 @@ int ocelot_init(struct ocelot *ocelot)
INIT_DELAYED_WORK(&ocelot->stats_work, ocelot_check_stats_work);
queue_delayed_work(ocelot->stats_queue, &ocelot->stats_work,
OCELOT_STATS_CHECK_DELAY);
+
+ if (ocelot->ptp) {
+ ret = ocelot_init_timestamp(ocelot);
+ if (ret) {
+ dev_err(ocelot->dev,
+ "Timestamp initialization failed\n");
+ return ret;
+ }
+ }
+
return 0;
}
EXPORT_SYMBOL(ocelot_init);
void ocelot_deinit(struct ocelot *ocelot)
{
+ struct list_head *pos, *tmp;
+ struct ocelot_port *port;
+ struct ocelot_skb *entry;
+ int i;
+
destroy_workqueue(ocelot->stats_queue);
mutex_destroy(&ocelot->stats_lock);
ocelot_ace_deinit();
+
+ for (i = 0; i < ocelot->num_phys_ports; i++) {
+ port = ocelot->ports[i];
+
+ list_for_each_safe(pos, tmp, &port->skbs) {
+ entry = list_entry(pos, struct ocelot_skb, head);
+
+ list_del(pos);
+ dev_kfree_skb_any(entry->skb);
+ kfree(entry);
+ }
+ }
}
EXPORT_SYMBOL(ocelot_deinit);
diff --git a/drivers/net/ethernet/mscc/ocelot.h b/drivers/net/ethernet/mscc/ocelot.h
index 515dee6fa8a6..e40773c01a44 100644
--- a/drivers/net/ethernet/mscc/ocelot.h
+++ b/drivers/net/ethernet/mscc/ocelot.h
@@ -11,9 +11,11 @@
#include <linux/bitops.h>
#include <linux/etherdevice.h>
#include <linux/if_vlan.h>
+#include <linux/net_tstamp.h>
#include <linux/phy.h>
#include <linux/phy/phy.h>
#include <linux/platform_device.h>
+#include <linux/ptp_clock_kernel.h>
#include <linux/regmap.h>
#include "ocelot_ana.h"
@@ -39,6 +41,8 @@
#define OCELOT_STATS_CHECK_DELAY (2 * HZ)
+#define OCELOT_PTP_QUEUE_SZ 128
+
#define IFH_LEN 4
struct frame_info {
@@ -46,6 +50,8 @@ struct frame_info {
u16 port;
u16 vid;
u8 tag_type;
+ u16 rew_op;
+ u32 timestamp; /* rew_val */
};
#define IFH_INJ_BYPASS BIT(31)
@@ -54,6 +60,12 @@ struct frame_info {
#define IFH_TAG_TYPE_C 0
#define IFH_TAG_TYPE_S 1
+#define IFH_REW_OP_NOOP 0x0
+#define IFH_REW_OP_DSCP 0x1
+#define IFH_REW_OP_ONE_STEP_PTP 0x2
+#define IFH_REW_OP_TWO_STEP_PTP 0x3
+#define IFH_REW_OP_ORIGIN_PTP 0x5
+
#define OCELOT_SPEED_2500 0
#define OCELOT_SPEED_1000 1
#define OCELOT_SPEED_100 2
@@ -401,6 +413,13 @@ enum ocelot_regfield {
REGFIELD_MAX
};
+enum ocelot_clk_pins {
+ ALT_PPS_PIN = 1,
+ EXT_CLK_PIN,
+ ALT_LDST_PIN,
+ TOD_ACC_PIN
+};
+
struct ocelot_multicast {
struct list_head list;
unsigned char addr[ETH_ALEN];
@@ -450,6 +469,13 @@ struct ocelot {
u64 *stats;
struct delayed_work stats_work;
struct workqueue_struct *stats_queue;
+
+ u8 ptp:1;
+ struct ptp_clock *ptp_clock;
+ struct ptp_clock_info ptp_info;
+ struct hwtstamp_config hwtstamp_config;
+ struct mutex ptp_lock; /* Protects the PTP interface state */
+ spinlock_t ptp_clock_lock; /* Protects the PTP clock */
};
struct ocelot_port {
@@ -473,6 +499,16 @@ struct ocelot_port {
struct phy *serdes;
struct ocelot_port_tc tc;
+
+ u8 ptp_cmd;
+ struct list_head skbs;
+ u8 ts_id;
+};
+
+struct ocelot_skb {
+ struct list_head head;
+ struct sk_buff *skb;
+ u8 id;
};
u32 __ocelot_read_ix(struct ocelot *ocelot, u32 reg, u32 offset);
@@ -517,4 +553,7 @@ extern struct notifier_block ocelot_netdevice_nb;
extern struct notifier_block ocelot_switchdev_nb;
extern struct notifier_block ocelot_switchdev_blocking_nb;
+int ocelot_ptp_gettime64(struct ptp_clock_info *ptp, struct timespec64 *ts);
+void ocelot_get_hwtimestamp(struct ocelot *ocelot, struct timespec64 *ts);
+
#endif
diff --git a/drivers/net/ethernet/mscc/ocelot_board.c b/drivers/net/ethernet/mscc/ocelot_board.c
index df8d15994a89..0b14e7110e7f 100644
--- a/drivers/net/ethernet/mscc/ocelot_board.c
+++ b/drivers/net/ethernet/mscc/ocelot_board.c
@@ -31,6 +31,8 @@ static int ocelot_parse_ifh(u32 *_ifh, struct frame_info *info)
info->len = OCELOT_BUFFER_CELL_SZ * wlen + llen - 80;
+ info->timestamp = IFH_EXTRACT_BITFIELD64(ifh[0], 21, 32);
+
info->port = IFH_EXTRACT_BITFIELD64(ifh[1], 43, 4);
info->tag_type = IFH_EXTRACT_BITFIELD64(ifh[1], 16, 1);
@@ -98,7 +100,11 @@ static irqreturn_t ocelot_xtr_irq_handler(int irq, void *arg)
int sz, len, buf_len;
u32 ifh[4];
u32 val;
- struct frame_info info;
+ struct frame_info info = {};
+ struct timespec64 ts;
+ struct skb_shared_hwtstamps *shhwtstamps;
+ u64 tod_in_ns;
+ u64 full_ts_in_ns;
for (i = 0; i < IFH_LEN; i++) {
err = ocelot_rx_frame_word(ocelot, grp, true, &ifh[i]);
@@ -145,6 +151,22 @@ static irqreturn_t ocelot_xtr_irq_handler(int irq, void *arg)
break;
}
+ if (ocelot->ptp) {
+ ocelot_ptp_gettime64(&ocelot->ptp_info, &ts);
+
+ tod_in_ns = ktime_set(ts.tv_sec, ts.tv_nsec);
+ if ((tod_in_ns & 0xffffffff) < info.timestamp)
+ full_ts_in_ns = (((tod_in_ns >> 32) - 1) << 32) |
+ info.timestamp;
+ else
+ full_ts_in_ns = (tod_in_ns & GENMASK_ULL(63, 32)) |
+ info.timestamp;
+
+ shhwtstamps = skb_hwtstamps(skb);
+ memset(shhwtstamps, 0, sizeof(struct skb_shared_hwtstamps));
+ shhwtstamps->hwtstamp = full_ts_in_ns;
+ }
+
/* Everything we see on an interface that is in the HW bridge
* has already been forwarded.
*/
@@ -164,6 +186,70 @@ static irqreturn_t ocelot_xtr_irq_handler(int irq, void *arg)
return IRQ_HANDLED;
}
+static irqreturn_t ocelot_ptp_rdy_irq_handler(int irq, void *arg)
+{
+ int budget = OCELOT_PTP_QUEUE_SZ;
+ struct ocelot *ocelot = arg;
+
+ do {
+ struct skb_shared_hwtstamps shhwtstamps;
+ struct list_head *pos, *tmp;
+ struct sk_buff *skb = NULL;
+ struct ocelot_skb *entry;
+ struct ocelot_port *port;
+ struct timespec64 ts;
+ u32 val, id, txport;
+
+ /* Prevent from infinite loop */
+ if (unlikely(!--budget))
+ break;
+
+ val = ocelot_read(ocelot, SYS_PTP_STATUS);
+
+ /* Check if a timestamp can be retrieved */
+ if (!(val & SYS_PTP_STATUS_PTP_MESS_VLD))
+ break;
+
+ WARN_ON(val & SYS_PTP_STATUS_PTP_OVFL);
+
+ /* Retrieve the ts ID and Tx port */
+ id = SYS_PTP_STATUS_PTP_MESS_ID_X(val);
+ txport = SYS_PTP_STATUS_PTP_MESS_TXPORT_X(val);
+
+ /* Retrieve its associated skb */
+ port = ocelot->ports[txport];
+
+ list_for_each_safe(pos, tmp, &port->skbs) {
+ entry = list_entry(pos, struct ocelot_skb, head);
+ if (entry->id != id)
+ continue;
+
+ skb = entry->skb;
+
+ list_del(pos);
+ kfree(entry);
+ }
+
+ /* Next ts */
+ ocelot_write(ocelot, SYS_PTP_NXT_PTP_NXT, SYS_PTP_NXT);
+
+ if (unlikely(!skb))
+ continue;
+
+ /* Get the h/w timestamp */
+ ocelot_get_hwtimestamp(ocelot, &ts);
+
+ /* Set the timestamp into the skb */
+ memset(&shhwtstamps, 0, sizeof(shhwtstamps));
+ shhwtstamps.hwtstamp = ktime_set(ts.tv_sec, ts.tv_nsec);
+ skb_tstamp_tx(skb, &shhwtstamps);
+
+ dev_kfree_skb_any(skb);
+ } while (true);
+
+ return IRQ_HANDLED;
+}
+
static const struct of_device_id mscc_ocelot_match[] = {
{ .compatible = "mscc,vsc7514-switch" },
{ }
@@ -172,8 +258,8 @@ MODULE_DEVICE_TABLE(of, mscc_ocelot_match);
static int mscc_ocelot_probe(struct platform_device *pdev)
{
- int err, irq;
unsigned int i;
+ int err, irq_xtr, irq_ptp_rdy;
struct device_node *np = pdev->dev.of_node;
struct device_node *ports, *portnp;
struct ocelot *ocelot;
@@ -232,16 +318,31 @@ static int mscc_ocelot_probe(struct platform_device *pdev)
if (err)
return err;
- irq = platform_get_irq_byname(pdev, "xtr");
- if (irq < 0)
+ irq_xtr = platform_get_irq_byname(pdev, "xtr");
+ if (irq_xtr < 0)
return -ENODEV;
- err = devm_request_threaded_irq(&pdev->dev, irq, NULL,
+ err = devm_request_threaded_irq(&pdev->dev, irq_xtr, NULL,
ocelot_xtr_irq_handler, IRQF_ONESHOT,
"frame extraction", ocelot);
if (err)
return err;
+
+ irq_ptp_rdy = platform_get_irq_byname(pdev, "ptp_rdy");
+ if (irq_ptp_rdy > 0) {
+ err = devm_request_threaded_irq(&pdev->dev, irq_ptp_rdy, NULL,
+ ocelot_ptp_rdy_irq_handler,
+ IRQF_ONESHOT, "ptp ready",
+ ocelot);
+ if (err)
+ return err;
+
+ /* Check if we can support PTP */
+ if (ocelot->targets[PTP])
+ ocelot->ptp = 1;
+ }
+
regmap_field_write(ocelot->regfields[SYS_RESET_CFG_MEM_INIT], 1);
regmap_field_write(ocelot->regfields[SYS_RESET_CFG_MEM_ENA], 1);
--
2.21.0
^ permalink raw reply related
* Re: [RFC PATCH 1/2] gianfar: convert to phylink
From: Russell King - ARM Linux admin @ 2019-07-24 8:19 UTC (permalink / raw)
To: Arseny Solokha; +Cc: Claudiu Manoil, Ioana Ciornei, Andrew Lunn, netdev
In-Reply-To: <20190723151702.14430-2-asolokha@kb.kras.ru>
On Tue, Jul 23, 2019 at 10:17:01PM +0700, Arseny Solokha wrote:
> -static noinline void gfar_update_link_state(struct gfar_private *priv)
> +static void gfar_mac_config(struct phylink_config *config, unsigned int mode,
> + const struct phylink_link_state *state)
> {
> + struct gfar_private *priv = netdev_priv(to_net_dev(config->dev));
> struct gfar __iomem *regs = priv->gfargrp[0].regs;
> - struct net_device *ndev = priv->ndev;
> - struct phy_device *phydev = ndev->phydev;
> - struct gfar_priv_rx_q *rx_queue = NULL;
> - int i;
> + u32 maccfg1, new_maccfg1;
> + u32 maccfg2, new_maccfg2;
> + u32 ecntrl, new_ecntrl;
> + u32 tx_flow, new_tx_flow;
>
> if (unlikely(test_bit(GFAR_RESETTING, &priv->state)))
> return;
>
> - if (phydev->link) {
> - u32 tempval1 = gfar_read(®s->maccfg1);
> - u32 tempval = gfar_read(®s->maccfg2);
> - u32 ecntrl = gfar_read(®s->ecntrl);
> - u32 tx_flow_oldval = (tempval1 & MACCFG1_TX_FLOW);
> + if (unlikely(phylink_autoneg_inband(mode)))
> + return;
Given that SFPs can be either SGMII or 1000BASE-X (which require
different configuration) and that the intention here is to support
SFPs, I don't see how this works with the above.
How is the difference between SGMII and 1000BASE-X handled?
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
^ permalink raw reply
* Driver support for Realtek RTL8125 2.5GB Ethernet
From: Jian-Hong Pan @ 2019-07-24 8:19 UTC (permalink / raw)
To: Linux Netdev List, Yan-Hsuan Chuang; +Cc: Linux Upstreaming Team
Hi all,
We have got a consumer desktop equipped with Realtek RTL8125 2.5GB
Ethernet [1] recently. But, there is no related driver in mainline
kernel yet. So, we can only use the vendor driver [2] and customize
it [3] right now.
Is anyone working on an upstream driver for this hardware?
[1] https://www.realtek.com/en/press-room/news-releases/item/realtek-launches-world-s-first-single-chip-2-5g-ethernet-controller-for-multiple-applications-including-gaming-solution
[2] https://www.realtek.com/en/component/zoo/category/network-interface-controllers-10-100-1000m-gigabit-ethernet-pci-express-software
[3] https://github.com/endlessm/linux/commit/da1e43f58850d272eb72f571524ed71fd237d32b
Jian-Hong Pan
^ permalink raw reply
* Re: memory leak in kobject_set_name_vargs (2)
From: Dmitry Vyukov @ 2019-07-24 8:25 UTC (permalink / raw)
To: Steffen Klassert, Herbert Xu, David Miller, Alexey Kuznetsov,
Hideaki YOSHIFUJI, netdev
Cc: LKML, syzkaller-bugs, syzbot
In-Reply-To: <000000000000edcb3c058e6143d5@google.com>
On Wed, Jul 24, 2019 at 1:08 AM syzbot
<syzbot+ad8ca40ecd77896d51e2@syzkaller.appspotmail.com> wrote:
>
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: 3bfe1fc4 Merge tag 'for-5.3/dm-changes-2' of git://git.ker..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=130322afa00000
> kernel config: https://syzkaller.appspot.com/x/.config?x=dcfc65ee492509c6
> dashboard link: https://syzkaller.appspot.com/bug?extid=ad8ca40ecd77896d51e2
> compiler: gcc (GCC) 9.0.0 20181231 (experimental)
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=135cbed0600000
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=14dd4e34600000
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+ad8ca40ecd77896d51e2@syzkaller.appspotmail.com
+net/ipv6/ip6_vti.c maintainers
> BUG: memory leak
> unreferenced object 0xffff88810cc5d860 (size 32):
> comm "syz-executor938", pid 7153, jiffies 4294945400 (age 8.020s)
> hex dump (first 32 bytes):
> 69 70 36 5f 76 74 69 31 00 2f 37 31 35 33 00 00 ip6_vti1./7153..
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> backtrace:
> [<000000000800471f>] kmemleak_alloc_recursive
> /./include/linux/kmemleak.h:43 [inline]
> [<000000000800471f>] slab_post_alloc_hook /mm/slab.h:522 [inline]
> [<000000000800471f>] slab_alloc /mm/slab.c:3319 [inline]
> [<000000000800471f>] __do_kmalloc /mm/slab.c:3653 [inline]
> [<000000000800471f>] __kmalloc_track_caller+0x165/0x300 /mm/slab.c:3670
> [<000000007a2eef8e>] kstrdup+0x3a/0x70 /mm/util.c:53
> [<00000000a309e483>] kstrdup_const+0x48/0x60 /mm/util.c:75
> [<00000000cf8dc39b>] kvasprintf_const+0x7e/0xe0 /lib/kasprintf.c:48
> [<000000005a964730>] kobject_set_name_vargs+0x40/0xe0 /lib/kobject.c:289
> [<00000000e2a9ccdf>] dev_set_name+0x63/0x90 /drivers/base/core.c:1915
> [<000000007bc7b1da>] netdev_register_kobject+0x5a/0x1b0
> /net/core/net-sysfs.c:1727
> [<00000000637b4645>] register_netdevice+0x397/0x600 /net/core/dev.c:8723
> [<0000000038b21fdc>] vti6_tnl_create2+0x47/0xb0 /net/ipv6/ip6_vti.c:189
> [<0000000023231475>] vti6_tnl_create /net/ipv6/ip6_vti.c:229 [inline]
> [<0000000023231475>] vti6_locate /net/ipv6/ip6_vti.c:277 [inline]
> [<0000000023231475>] vti6_locate+0x244/0x2c0 /net/ipv6/ip6_vti.c:255
> [<000000006ebf0a44>] vti6_ioctl+0x17f/0x390 /net/ipv6/ip6_vti.c:802
> [<00000000077406fa>] dev_ifsioc+0x324/0x460 /net/core/dev_ioctl.c:322
> [<00000000465d817c>] dev_ioctl+0x157/0x45e /net/core/dev_ioctl.c:514
> [<00000000e2472af6>] sock_ioctl+0x394/0x480 /net/socket.c:1099
> [<0000000024234c3b>] vfs_ioctl /fs/ioctl.c:46 [inline]
> [<0000000024234c3b>] file_ioctl /fs/ioctl.c:509 [inline]
> [<0000000024234c3b>] do_vfs_ioctl+0x62a/0x810 /fs/ioctl.c:696
> [<0000000015b52ca4>] ksys_ioctl+0x86/0xb0 /fs/ioctl.c:713
>
>
>
> ---
> This bug is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at syzkaller@googlegroups.com.
>
> syzbot will keep track of this bug report. See:
> https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
> syzbot can test patches for this bug, for details see:
> https://goo.gl/tpsmEJ#testing-patches
>
> --
> You received this message because you are subscribed to the Google Groups "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller-bugs+unsubscribe@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-bugs/000000000000edcb3c058e6143d5%40google.com.
^ permalink raw reply
* Re: [PATCH] can: ti_hecc: use timestamp based rx-offloading
From: Marc Kleine-Budde @ 2019-07-24 8:26 UTC (permalink / raw)
To: Jeroen Hofstee, linux-can@vger.kernel.org
Cc: Anant Gole, AnilKumar Ch, Wolfgang Grandegger, David S. Miller,
open list:NETWORKING DRIVERS, open list
In-Reply-To: <1556539376-20932-1-git-send-email-jhofstee@victronenergy.com>
[-- Attachment #1.1: Type: text/plain, Size: 6420 bytes --]
On 4/29/19 2:03 PM, Jeroen Hofstee wrote:
> As already mentioned in [1] and included in [2], there is an off by one
> issue since the high bank is already enabled when the _next_ mailbox to
> be read has index 12, so the mailbox being read was 13. The message can
> therefore go into mailbox 31 and the driver will be repolled until the
> mailbox 12 eventually receives a msg. Or the message might end up in the
> 12th mailbox, but then it would become disabled after reading it and only
> be enabled again in the next "round" after mailbox 13 was read, which can
> cause out of order messages, since the lower priority mailboxes can
> accept messages in the meantime.
>
> As mentioned in [3] there is a hardware race condition when changing the
> CANME register while messages are being received. Even when including a
> busy poll on reception, like in [2] there are still overflows and out of
> order messages at times, but less then without the busy loop polling.
> Unlike what the patch suggests, the polling time is not in the microsecond
> range, but takes as long as a current CAN bus reception needs to finish,
> so typically more in the fraction of millisecond range. Since the timeout
> is in jiffies it won't timeout.
>
> Even with these additional fixes the driver is still not able to provide a
> proper FIFO which doesn't drop packages. So change the driver to use
> rx-offload and base order on timestamp instead of message box numbers. As
> a side affect, this also fixes [4] and [5].
>
> Before this change messages with a single byte counter were dropped /
> received out of order at a bitrate of 250kbit/s on an am3517. With this
> patch that no longer occurs up to and including 1Mbit/s.
>
> [1] https://linux-can.vger.kernel.narkive.com/zgO9inVi/patch-can-ti-hecc-fix-rx-wrong-sequence-issue#post6
> [2] http://arago-project.org/git/projects/?p=linux-omap3.git;a=commit;h=02346892777f07245de4d5af692513ebd852dcb2
> [3] https://linux-can.vger.kernel.narkive.com/zgO9inVi/patch-can-ti-hecc-fix-rx-wrong-sequence-issue#post5
> [4] https://patchwork.ozlabs.org/patch/895956/
> [5] https://www.spinics.net/lists/netdev/msg494971.html
>
> Cc: Anant Gole <anantgole@ti.com>
> Cc: AnilKumar Ch <anilkumar@ti.com>
> Signed-off-by: Jeroen Hofstee <jhofstee@victronenergy.com>
> ---
> drivers/net/can/ti_hecc.c | 189 +++++++++++++---------------------------------
> 1 file changed, 53 insertions(+), 136 deletions(-)
>
> diff --git a/drivers/net/can/ti_hecc.c b/drivers/net/can/ti_hecc.c
> index db6ea93..fe7ffff 100644
> --- a/drivers/net/can/ti_hecc.c
> +++ b/drivers/net/can/ti_hecc.c
> @@ -5,6 +5,7 @@
> * specs for the same is available at <http://www.ti.com>
> *
> * Copyright (C) 2009 Texas Instruments Incorporated - http://www.ti.com/
> + * Copyright (C) 2019 Jeroen Hofstee <jhofstee@victronenergy.com>
> *
> * This program is free software; you can redistribute it and/or
> * modify it under the terms of the GNU General Public License as
> @@ -34,6 +35,7 @@
> #include <linux/can/dev.h>
> #include <linux/can/error.h>
> #include <linux/can/led.h>
> +#include <linux/can/rx-offload.h>
>
> #define DRV_NAME "ti_hecc"
> #define HECC_MODULE_VERSION "0.7"
> @@ -63,29 +65,16 @@ MODULE_VERSION(HECC_MODULE_VERSION);
> #define HECC_TX_PRIO_MASK (MAX_TX_PRIO << HECC_MB_TX_SHIFT)
> #define HECC_TX_MB_MASK (HECC_MAX_TX_MBOX - 1)
> #define HECC_TX_MASK ((HECC_MAX_TX_MBOX - 1) | HECC_TX_PRIO_MASK)
> -#define HECC_TX_MBOX_MASK (~(BIT(HECC_MAX_TX_MBOX) - 1))
> -#define HECC_DEF_NAPI_WEIGHT HECC_MAX_RX_MBOX
>
> /*
> - * Important Note: RX mailbox configuration
> - * RX mailboxes are further logically split into two - main and buffer
> - * mailboxes. The goal is to get all packets into main mailboxes as
> - * driven by mailbox number and receive priority (higher to lower) and
> - * buffer mailboxes are used to receive pkts while main mailboxes are being
> - * processed. This ensures in-order packet reception.
> - *
> - * Here are the recommended values for buffer mailbox. Note that RX mailboxes
> - * start after TX mailboxes:
> - *
> - * HECC_MAX_RX_MBOX HECC_RX_BUFFER_MBOX No of buffer mailboxes
> - * 28 12 8
> - * 16 20 4
> + * RX mailbox configuration
> + * The remaining mailboxes are used for reception and are delivered based on
> + * their timestamp, to avoid a hardware race when CANME is changed while
> + * CAN-bus traffix is being received.
> */
>
> #define HECC_MAX_RX_MBOX (HECC_MAX_MAILBOXES - HECC_MAX_TX_MBOX)
> -#define HECC_RX_BUFFER_MBOX 12 /* as per table above */
> #define HECC_RX_FIRST_MBOX (HECC_MAX_MAILBOXES - 1)
> -#define HECC_RX_HIGH_MBOX_MASK (~(BIT(HECC_RX_BUFFER_MBOX) - 1))
>
> /* TI HECC module registers */
> #define HECC_CANME 0x0 /* Mailbox enable */
> @@ -123,6 +112,8 @@ MODULE_VERSION(HECC_MODULE_VERSION);
> #define HECC_CANMDL 0x8
> #define HECC_CANMDH 0xC
>
> +#define HECC_CANMOTS 0x100
It's actually 0x80
> +
> #define HECC_SET_REG 0xFFFFFFFF
> #define HECC_CANID_MASK 0x3FF /* 18 bits mask for extended id's */
> #define HECC_CCE_WAIT_COUNT 100 /* Wait for ~1 sec for CCE bit */
> @@ -193,7 +184,7 @@ static const struct can_bittiming_const ti_hecc_bittiming_const = {
>
> struct ti_hecc_priv {
> struct can_priv can; /* MUST be first member/field */
> - struct napi_struct napi;
> + struct can_rx_offload offload;
> struct net_device *ndev;
> struct clk *clk;
> void __iomem *base;
> @@ -203,7 +194,6 @@ struct ti_hecc_priv {
> spinlock_t mbx_lock; /* CANME register needs protection */
> u32 tx_head;
> u32 tx_tail;
> - u32 rx_next;
> struct regulator *reg_xceiver;
> };
>
> @@ -265,6 +255,11 @@ static inline u32 hecc_get_bit(struct ti_hecc_priv *priv, int reg, u32 bit_mask)
> return (hecc_read(priv, reg) & bit_mask) ? 1 : 0;
> }
>
> +static inline u32 hecc_read_stamp(struct ti_hecc_priv *priv, u32 mbxno)
> +{
> + return __raw_readl(priv->hecc_ram + 0x80 + 4 * mbxno);
I've changed this function to use HECC_CANMOTS.
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: kernel panic: stack is corrupted in pointer
From: Dmitry Vyukov @ 2019-07-24 8:30 UTC (permalink / raw)
To: John Fastabend
Cc: syzbot, bpf, David Airlie, alexander.deucher, amd-gfx,
Alexei Starovoitov, christian.koenig, Daniel Borkmann,
david1.zhou, DRI, leo.liu, LKML, netdev, syzkaller-bugs,
Marco Elver
In-Reply-To: <5d37433a832d_3aba2ae4f6ec05bc3a@john-XPS-13-9370.notmuch>
On Tue, Jul 23, 2019 at 7:26 PM John Fastabend <john.fastabend@gmail.com> wrote:
>
> Dmitry Vyukov wrote:
> > On Wed, Jul 17, 2019 at 10:58 AM syzbot
> > <syzbot+79f5f028005a77ecb6bb@syzkaller.appspotmail.com> wrote:
> > >
> > > Hello,
> > >
> > > syzbot found the following crash on:
> > >
> > > HEAD commit: 1438cde7 Add linux-next specific files for 20190716
> > > git tree: linux-next
> > > console output: https://syzkaller.appspot.com/x/log.txt?x=13988058600000
> > > kernel config: https://syzkaller.appspot.com/x/.config?x=3430a151e1452331
> > > dashboard link: https://syzkaller.appspot.com/bug?extid=79f5f028005a77ecb6bb
> > > compiler: gcc (GCC) 9.0.0 20181231 (experimental)
> > > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=111fc8afa00000
> >
> > From the repro it looks like the same bpf stack overflow bug. +John
> > We need to dup them onto some canonical report for this bug, or this
> > becomes unmanageable.
>
> Fixes in bpf tree should fix this. Hopefully, we will squash this once fixes
> percolate up.
>
> #syz test: git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git
Cool! What is the fix?
We don't need to wait for the fix to percolate up (and then down
too!). syzbot gracefully handles when a patch is not yet present
everywhere (it happens all the time).
Btw, this was due to a stack overflow, right? Or something else?
We are trying to make KASAN configuration detect stack overflows too,
so that it does not cause havoc next time. But it turns out to be
non-trivial and our current attempt seems to fail:
https://groups.google.com/forum/#!topic/kasan-dev/IhYv7QYhLfY
> > #syz dup: kernel panic: corrupted stack end in dput
> >
> > > The bug was bisected to:
> > >
> > > commit 96a5d8d4915f3e241ebb48d5decdd110ab9c7dcf
> > > Author: Leo Liu <leo.liu@amd.com>
> > > Date: Fri Jul 13 15:26:28 2018 +0000
> > >
> > > drm/amdgpu: Make sure IB tests flushed after IP resume
> > >
> > > bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=14a46200600000
> > > final crash: https://syzkaller.appspot.com/x/report.txt?x=16a46200600000
> > > console output: https://syzkaller.appspot.com/x/log.txt?x=12a46200600000
> > >
> > > IMPORTANT: if you fix the bug, please add the following tag to the commit:
> > > Reported-by: syzbot+79f5f028005a77ecb6bb@syzkaller.appspotmail.com
> > > Fixes: 96a5d8d4915f ("drm/amdgpu: Make sure IB tests flushed after IP
> > > resume")
> > >
> > > Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in:
> > > pointer+0x702/0x750 lib/vsprintf.c:2187
> > > Shutting down cpus with NMI
> > > Kernel Offset: disabled
> > >
> > >
> > > ---
> > > This bug is generated by a bot. It may contain errors.
> > > See https://goo.gl/tpsmEJ for more information about syzbot.
> > > syzbot engineers can be reached at syzkaller@googlegroups.com.
> > >
> > > syzbot will keep track of this bug report. See:
> > > https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
> > > For information about bisection process see: https://goo.gl/tpsmEJ#bisection
> > > syzbot can test patches for this bug, for details see:
> > > https://goo.gl/tpsmEJ#testing-patches
>
>
> --
> You received this message because you are subscribed to the Google Groups "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller-bugs+unsubscribe@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-bugs/5d37433a832d_3aba2ae4f6ec05bc3a%40john-XPS-13-9370.notmuch.
^ permalink raw reply
* [RFC] performance regression with commit-id<adb03115f459> ("net: get rid of an signed integer overflow in ip_idents_reserve()")
From: Zhangshaokun @ 2019-07-24 8:38 UTC (permalink / raw)
To: Eric Dumazet, Jiri Pirko, netdev, linux-kernel
Cc: David S. Miller, guoyang (C), zhudacai@hisilicon.com
Hi,
I've observed an significant performance regression with the following commit-id <adb03115f459>
("net: get rid of an signed integer overflow in ip_idents_reserve()").
Here are my test scenes:
----Server----
Cmd: iperf3 -s xxx.xxx.xxxx.xxx -p 10000 -i 0 -A 0
Kenel: 4.19.34
Server number: 32
Port: 10000 – 10032
CPU affinity: 0 – 32
CPU architecture: aarch64
NUMA node0 CPU(s): 0-23
NUMA node1 CPU(s): 24-47
----Client----
Cmd: iperf3 -u -c xxx.xxx.xxxx.xxx -p 10000 -l 16 -b 0 -t 0 -i 0 -A 8
Kenel: 4.19.34
Client number: 32
Port: 10000 – 10032
CPU affinity: 0 – 32
CPU architecture: aarch64
NUMA node0 CPU(s): 0-23
NUMA node1 CPU(s): 24-47
Firstly, With patch <adb03115f459> ("net: get rid of an signed integer overflow in ip_idents_reserve()") ,
client’s cpu is 100%, and function ip_idents_reserve() cpu usage is very high, but the result is not good.
03:08:32 AM IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s %ifutil
03:08:33 AM eth0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
03:08:33 AM eth1 0.00 3461296.00 0.00 196049.97 0.00 0.00 0.00 0.00
03:08:33 AM lo 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
Secondly, revert that patch, use atomic_add_return() instead, the result is better, as below:
03:23:24 AM IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s %ifutil
03:23:25 AM lo 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
03:23:25 AM eth1 0.00 12834590.00 0.00 726959.20 0.00 0.00 0.00 0.00
03:23:25 AM eth0 7.00 11.00 0.40 2.95 0.00 0.00 0.00 0.00
Thirdly, atomic is not used in ip_idents_reserve() completely ,while each cpu core allocates its own ID segment,
Such as: cpu core0 allocate ID 0 – 1023, cpu core1 allocate 1024 – 2047, …,etc
the result is the best:
03:27:06 AM IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s %ifutil
03:27:07 AM lo 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
03:27:07 AM eth1 0.00 14275505.00 0.00 808573.53 0.00 0.00 0.00 0.00
03:27:07 AM eth0 0.00 2.00 0.00 0.18 0.00 0.00 0.00 0.00
Because atomic operation performance is bottleneck when cpu core number increase, Can we revert the patch or
use ID segment for each cpu core instead?
Thanks in advance,
Shaokun
^ permalink raw reply
* Re: [PATCH net-next 3/3] net: stmmac: Introducing support for Page Pool
From: Ilias Apalodimas @ 2019-07-24 8:54 UTC (permalink / raw)
To: David Miller
Cc: jonathanh, robin.murphy, Jose.Abreu, lists, Joao.Pinto,
alexandre.torgue, maxime.ripard, netdev, linux-kernel,
linux-stm32, wens, mcoquelin.stm32, linux-tegra, peppe.cavallaro,
linux-arm-kernel
In-Reply-To: <20190723.115112.1824255524103179323.davem@davemloft.net>
Hi David,
> From: Jon Hunter <jonathanh@nvidia.com>
> Date: Tue, 23 Jul 2019 13:09:00 +0100
>
> > Setting "iommu.passthrough=1" works for me. However, I am not sure where
> > to go from here, so any ideas you have would be great.
>
> Then definitely we are accessing outside of a valid IOMMU mapping due
> to the page pool support changes.
Yes. On the netsec driver i did test with and without SMMU to make sure i am not
breaking anything.
Since we map the whole page on the API i think some offset on the driver causes
that. In any case i'll have another look on page_pool to make sure we are not
missing anything.
>
> Such a problem should be spotted with swiommu enabled with debugging.
Thanks
/Ilias
^ permalink raw reply
* Re: [RFC] performance regression with commit-id<adb03115f459> ("net: get rid of an signed integer overflow in ip_idents_reserve()")
From: Eric Dumazet @ 2019-07-24 8:56 UTC (permalink / raw)
To: Zhangshaokun, Eric Dumazet, Jiri Pirko, netdev, linux-kernel
Cc: David S. Miller, guoyang (C), zhudacai@hisilicon.com
In-Reply-To: <051e93d4-0206-7416-e639-376b8d2eb98b@hisilicon.com>
On 7/24/19 10:38 AM, Zhangshaokun wrote:
> Hi,
>
> I've observed an significant performance regression with the following commit-id <adb03115f459>
> ("net: get rid of an signed integer overflow in ip_idents_reserve()").
Yes this UBSAN false positive has been painful
>
> Here are my test scenes:
> ----Server----
> Cmd: iperf3 -s xxx.xxx.xxxx.xxx -p 10000 -i 0 -A 0
> Kenel: 4.19.34
> Server number: 32
> Port: 10000 – 10032
> CPU affinity: 0 – 32
> CPU architecture: aarch64
> NUMA node0 CPU(s): 0-23
> NUMA node1 CPU(s): 24-47
>
> ----Client----
> Cmd: iperf3 -u -c xxx.xxx.xxxx.xxx -p 10000 -l 16 -b 0 -t 0 -i 0 -A 8
> Kenel: 4.19.34
> Client number: 32
> Port: 10000 – 10032
> CPU affinity: 0 – 32
> CPU architecture: aarch64
> NUMA node0 CPU(s): 0-23
> NUMA node1 CPU(s): 24-47
>
> Firstly, With patch <adb03115f459> ("net: get rid of an signed integer overflow in ip_idents_reserve()") ,
> client’s cpu is 100%, and function ip_idents_reserve() cpu usage is very high, but the result is not good.
> 03:08:32 AM IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s %ifutil
> 03:08:33 AM eth0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
> 03:08:33 AM eth1 0.00 3461296.00 0.00 196049.97 0.00 0.00 0.00 0.00
> 03:08:33 AM lo 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
>
> Secondly, revert that patch, use atomic_add_return() instead, the result is better, as below:
> 03:23:24 AM IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s %ifutil
> 03:23:25 AM lo 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
> 03:23:25 AM eth1 0.00 12834590.00 0.00 726959.20 0.00 0.00 0.00 0.00
> 03:23:25 AM eth0 7.00 11.00 0.40 2.95 0.00 0.00 0.00 0.00
>
> Thirdly, atomic is not used in ip_idents_reserve() completely ,while each cpu core allocates its own ID segment,
> Such as: cpu core0 allocate ID 0 – 1023, cpu core1 allocate 1024 – 2047, …,etc
> the result is the best:
Not sure what you mean.
Less entropy in IPv4 ID is not going to help when fragments _are_ needed.
Send 40,000 datagrams of 2000 bytes each, add delays, reorders, and boom, most of the packets will be lost.
This is not because your use case does not need proper IP ID that we can mess with them.
If you need to send packets very fast, maybe use AF_PACKET ?
> 03:27:06 AM IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s %ifutil
> 03:27:07 AM lo 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
> 03:27:07 AM eth1 0.00 14275505.00 0.00 808573.53 0.00 0.00 0.00 0.00
> 03:27:07 AM eth0 0.00 2.00 0.00 0.18 0.00 0.00 0.00 0.00
>
> Because atomic operation performance is bottleneck when cpu core number increase, Can we revert the patch or
> use ID segment for each cpu core instead?
This has been discussed in the past.
https://lore.kernel.org/lkml/b0160f4b-b996-b0ee-405a-3d5f1866272e@gmail.com/
We can revert now UBSAN has been fixed.
Or even use Peter patch : https://lore.kernel.org/lkml/20181101172739.GA3196@hirez.programming.kicks-ass.net/
However, you will still hit badly a shared cache line, not matter what.
Some arches are known to have terrible LL/SC implementation :/
^ permalink raw reply
* pull-request: can-next 2019-07-24
From: Marc Kleine-Budde @ 2019-07-24 9:00 UTC (permalink / raw)
To: netdev; +Cc: davem, kernel, linux-can
[-- Attachment #1.1: Type: text/plain, Size: 7070 bytes --]
Hello David,
this is a pull request for net-next/master consisting of 26 patches.
The first two patches are by me. One adds missing files of the CAN
subsystem to the MAINTAINERS file, while the other sorts the
Makefile/Kconfig of the sja1000 drivers sub directory. In the next patch
Ji-Ze Hong (Peter Hong) provides a driver for the "Fintek PCIE to 2 CAN"
controller, based on the the sja1000 IP core.
Gustavo A. R. Silva's patch for the kvaser_usb driver introduces the use
of struct_size() instead of open coding it. Henning Colliander's patch
adds a driver for the "Kvaser PCIEcan" devices.
Another patch by Gustavo A. R. Silva marks expected switch fall-throughs
properly.
Dan Murphy provides 5 patches for the m_can. After cleanups a framework
is introduced so that the driver can be used from memory mapped IO as
well as SPI attached devices. Finally he adds a driver for the tcan4x5x
which uses this framework.
A series of 5 patches by Appana Durga Kedareswara rao for the xilinx_can
driver, first clean up,then add support for CANFD. Colin Ian King
contributes another cleanup for the xilinx_can driver.
Robert P. J. Day's patch corrects the brief history of the CAN protocol
given in the Kconfig menu entry.
2 patches by Dong Aisheng for the flexcan driver provide PE clock source
select support and dt-bindings description.
2 patches by Sean Nyekjaer for the flexcan driver provide add CAN
wakeup-source property and dt-bindings description.
Jeroen Hofstee's patch converts the ti_hecc driver to make use of the
rx-offload helper fixing a number of outstanding bugs.
The first patch of Oliver Hartkopp removes the now obsolete empty
ioctl() handler for the CAN protocols. The second patch adds SPDX
license identifiers for CAN subsystem.
regards,
Marc
---
The following changes since commit 3e3bb69589e482e0783f28d4cd1d8e56fda0bcbb:
tc-testing: added tdc tests for [b|p]fifo qdisc (2019-07-23 14:08:15 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next.git tags/linux-can-next-for-5.4-20190724
for you to fetch changes up to fba76a58452694b9b13c07e48839fa84c75f57af:
can: Add SPDX license identifiers for CAN subsystem (2019-07-24 10:31:55 +0200)
----------------------------------------------------------------
linux-can-next-for-5.4-20190724
----------------------------------------------------------------
Aisheng Dong (1):
can: flexcan: implement can Runtime PM
Appana Durga Kedareswara rao (5):
can: xilinx_can: Fix style issues
can: xilinx_can: Fix kernel doc warnings
can: xilinx_can: Fix flags field initialization for axi can and canps
can: xilinx_can: Add cantype parameter in xcan_devtype_data struct
can: xilinx_can: Add support for CANFD FD frames
Colin Ian King (1):
can: xilinx_can: clean up indentation issue
Dan Murphy (5):
can: m_can: Fix checkpatch issues on existing code
can: m_can: Create a m_can platform framework
can: m_can: Rename m_can_priv to m_can_classdev
dt-bindings: can: tcan4x5x: Add DT bindings for TCAN4x5X driver
can: tcan4x5x: Add tcan4x5x driver to the kernel
Dong Aisheng (2):
dt-bindings: can: flexcan: add PE clock source property to device tree
can: flexcan: add support for PE clock source select
Gustavo A. R. Silva (2):
can: kvaser_usb: Use struct_size() in alloc_candev()
can: mark expected switch fall-throughs
Henning Colliander (1):
can: kvaser_pciefd: Add driver for Kvaser PCIEcan devices
Jeroen Hofstee (1):
can: ti_hecc: use timestamp based rx-offloading
Ji-Ze Hong (Peter Hong) (1):
can: sja1000: f81601: add Fintek F81601 support
Marc Kleine-Budde (2):
MAINTAINERS: can: add missing files to CAN NETWORK DRIVERS and CAN NETWORK LAYER
can: sja1000: Makefile/Kconfig: sort alphabetically
Oliver Hartkopp (2):
can: remove obsolete empty ioctl() handler
can: Add SPDX license identifiers for CAN subsystem
Robert P. J. Day (1):
can: Kconfig: correct history of the CAN protocol
Sean Nyekjaer (2):
dt-bindings: can: flexcan: add can wakeup property
can: flexcan: add support for DT property 'wakeup-source'
.../devicetree/bindings/net/can/fsl-flexcan.txt | 10 +
.../devicetree/bindings/net/can/tcan4x5x.txt | 37 +
MAINTAINERS | 5 +
drivers/net/can/Kconfig | 13 +
drivers/net/can/Makefile | 1 +
drivers/net/can/at91_can.c | 6 +-
drivers/net/can/flexcan.c | 136 +-
drivers/net/can/kvaser_pciefd.c | 1912 ++++++++++++++++++++
drivers/net/can/m_can/Kconfig | 22 +-
drivers/net/can/m_can/Makefile | 2 +
drivers/net/can/m_can/m_can.c | 1079 +++++------
drivers/net/can/m_can/m_can.h | 110 ++
drivers/net/can/m_can/m_can_platform.c | 202 +++
drivers/net/can/m_can/tcan4x5x.c | 532 ++++++
drivers/net/can/peak_canfd/peak_pciefd_main.c | 2 +-
drivers/net/can/sja1000/Kconfig | 79 +-
drivers/net/can/sja1000/Makefile | 11 +-
drivers/net/can/sja1000/f81601.c | 212 +++
drivers/net/can/spi/mcp251x.c | 3 +-
drivers/net/can/ti_hecc.c | 191 +-
drivers/net/can/usb/kvaser_usb/kvaser_usb_core.c | 3 +-
drivers/net/can/usb/peak_usb/pcan_usb.c | 2 +-
drivers/net/can/xilinx_can.c | 293 ++-
include/linux/can/core.h | 3 +-
include/linux/can/skb.h | 2 +-
net/can/Kconfig | 11 +-
net/can/af_can.c | 10 +-
net/can/af_can.h | 1 +
net/can/bcm.c | 3 +-
net/can/gw.c | 1 +
net/can/proc.c | 1 +
net/can/raw.c | 3 +-
32 files changed, 4098 insertions(+), 800 deletions(-)
create mode 100644 Documentation/devicetree/bindings/net/can/tcan4x5x.txt
create mode 100644 drivers/net/can/kvaser_pciefd.c
create mode 100644 drivers/net/can/m_can/m_can.h
create mode 100644 drivers/net/can/m_can/m_can_platform.c
create mode 100644 drivers/net/can/m_can/tcan4x5x.c
create mode 100644 drivers/net/can/sja1000/f81601.c
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |-
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [RFC PATCH net-next 08/12] drop_monitor: Initialize timer and work item upon tracing enable
From: Jiri Pirko @ 2019-07-24 9:01 UTC (permalink / raw)
To: Ido Schimmel
Cc: netdev, davem, nhorman, dsahern, roopa, nikolay, jakub.kicinski,
toke, andy, f.fainelli, andrew, vivien.didelot, mlxsw,
Ido Schimmel
In-Reply-To: <20190722183134.14516-9-idosch@idosch.org>
Mon, Jul 22, 2019 at 08:31:30PM CEST, idosch@idosch.org wrote:
>From: Ido Schimmel <idosch@mellanox.com>
>
>The timer and work item are currently initialized once during module
>init, but subsequent patches will need to associate different functions
>with the work item, based on the configured alert mode.
>
>Allow subsequent patches to make that change by initializing and
>de-initializing these objects during tracing enable and disable.
>
>This also guarantees that once the request to disable tracing returns,
>no more netlink notifications will be generated.
>
>Signed-off-by: Ido Schimmel <idosch@mellanox.com>
>---
> net/core/drop_monitor.c | 24 +++++++++++++++++++-----
> 1 file changed, 19 insertions(+), 5 deletions(-)
>
>diff --git a/net/core/drop_monitor.c b/net/core/drop_monitor.c
>index e68dafaaebcd..2f56a61c43c6 100644
>--- a/net/core/drop_monitor.c
>+++ b/net/core/drop_monitor.c
>@@ -257,13 +257,20 @@ static void trace_napi_poll_hit(void *ignore, struct napi_struct *napi,
>
> static int net_dm_trace_on_set(struct netlink_ext_ack *extack)
> {
>- int rc;
>+ int cpu, rc;
>
> if (!try_module_get(THIS_MODULE)) {
> NL_SET_ERR_MSG_MOD(extack, "Failed to take reference on module");
> return -ENODEV;
> }
>
>+ for_each_possible_cpu(cpu) {
>+ struct per_cpu_dm_data *data = &per_cpu(dm_cpu_data, cpu);
>+
>+ INIT_WORK(&data->dm_alert_work, send_dm_alert);
>+ timer_setup(&data->send_timer, sched_send_work, 0);
So don't you want to remove this initialization from
init_net_drop_monitor?
>+ }
>+
> rc = register_trace_kfree_skb(trace_kfree_skb_hit, NULL);
> if (rc) {
> NL_SET_ERR_MSG_MOD(extack, "Failed to connect probe to kfree_skb() tracepoint");
[...]
^ permalink raw reply
* Re: [RFC PATCH 2/2] net: phylink: don't start and stop SGMII PHYs in SFP modules twice
From: Russell King - ARM Linux admin @ 2019-07-24 9:01 UTC (permalink / raw)
To: Arseny Solokha; +Cc: Claudiu Manoil, Ioana Ciornei, Andrew Lunn, netdev
In-Reply-To: <20190723151702.14430-3-asolokha@kb.kras.ru>
On Tue, Jul 23, 2019 at 10:17:02PM +0700, Arseny Solokha wrote:
> SFP modules connected using the SGMII interface have their own PHYs which
> are handled by the struct phylink's phydev field. After commit ce0aa27ff3f6
> ("sfp: add sfp-bus to bridge between network devices and sfp cages") an
> sfp-bus attached to the same phylink also gets control over a PHY in an SFP
> module which is actually the same PHY managed by phylink itself. This
> results in WARNs during network interface bringup and shutdown when a
> copper SFP module is connected, as phy_start() and phy_stop() are called
> twice in a row for the same phy_device:
>...
> So, skip explicit calls to phy_start() and phy_stop() when phylink has just
> enabled or disabled an attached SFP module.
I'd prefer if we re-ordered these so phy_start() happens before
sfp_upstream_start() and the reverse for the stop calls.
pl->phydev won't be set at these points, so the calls will be no-ops.
(The reason is when we support mac--phy--sfp setups, having the
phy_start() and phy_stop() here are still necessary.)
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
^ permalink raw reply
* RE: [patch iproute2 1/2] tc: action: fix crash caused by incorrect *argv check
From: David Laight @ 2019-07-24 9:07 UTC (permalink / raw)
To: 'Stephen Hemminger', Jiri Pirko
Cc: netdev@vger.kernel.org, sthemmin@microsoft.com, dsahern@gmail.com,
alexanderk@mellanox.com, mlxsw@mellanox.com
In-Reply-To: <20190723105401.4975396d@hermes.lan>
From: Stephen Hemminger
> Sent: 23 July 2019 18:54
>
> On Tue, 23 Jul 2019 13:25:37 +0200
> Jiri Pirko <jiri@resnulli.us> wrote:
>
> > From: Jiri Pirko <jiri@mellanox.com>
> >
> > One cannot depend on *argv being null in case of no arg is left on the
> > command line. For example in batch mode, this is not always true. Check
> > argc instead to prevent crash.
Hmmm... expecting the increments of argv and decrements of argc to match
it probably wishful thinking....
A lot of parsers don't even look at argc.
> Actually makeargs does NULL terminate the last arg so what input
> to batchmode is breaking this?
The 'usual' problem is an extra increment of argv because the last entry
was something that 'eats' two or more entries.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
^ permalink raw reply
* [PATCH 4.4 stable net] net: tcp: Fix use-after-free in tcp_write_xmit
From: Mao Wenan @ 2019-07-24 9:17 UTC (permalink / raw)
To: davem, gregkh, netdev, linux-kernel; +Cc: Mao Wenan
There is one report about tcp_write_xmit use-after-free with version 4.4.136:
BUG: KASAN: use-after-free in tcp_skb_pcount include/net/tcp.h:796 [inline]
BUG: KASAN: use-after-free in tcp_init_tso_segs net/ipv4/tcp_output.c:1619 [inline]
BUG: KASAN: use-after-free in tcp_write_xmit+0x3fc2/0x4cb0 net/ipv4/tcp_output.c:2056
Read of size 2 at addr ffff8801d6fc87b0 by task syz-executor408/4195
CPU: 0 PID: 4195 Comm: syz-executor408 Not tainted 4.4.136-gfb7e319 #59
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
0000000000000000 7d8f38ecc03be946 ffff8801d73b7710 ffffffff81e0edad
ffffea00075bf200 ffff8801d6fc87b0 0000000000000000 ffff8801d6fc87b0
dffffc0000000000 ffff8801d73b7748 ffffffff815159b6 ffff8801d6fc87b0
Call Trace:
[<ffffffff81e0edad>] __dump_stack lib/dump_stack.c:15 [inline]
[<ffffffff81e0edad>] dump_stack+0xc1/0x124 lib/dump_stack.c:51
[<ffffffff815159b6>] print_address_description+0x6c/0x216 mm/kasan/report.c:252
[<ffffffff81515cd5>] kasan_report_error mm/kasan/report.c:351 [inline]
[<ffffffff81515cd5>] kasan_report.cold.7+0x175/0x2f7 mm/kasan/report.c:408
[<ffffffff814f9784>] __asan_report_load2_noabort+0x14/0x20 mm/kasan/report.c:427
[<ffffffff83286582>] tcp_skb_pcount include/net/tcp.h:796 [inline]
[<ffffffff83286582>] tcp_init_tso_segs net/ipv4/tcp_output.c:1619 [inline]
[<ffffffff83286582>] tcp_write_xmit+0x3fc2/0x4cb0 net/ipv4/tcp_output.c:2056
[<ffffffff83287a40>] __tcp_push_pending_frames+0xa0/0x290 net/ipv4/tcp_output.c:2307
[<ffffffff8328e966>] tcp_send_fin+0x176/0xab0 net/ipv4/tcp_output.c:2883
[<ffffffff8324c0d0>] tcp_close+0xca0/0xf70 net/ipv4/tcp.c:2112
[<ffffffff832f8d0f>] inet_release+0xff/0x1d0 net/ipv4/af_inet.c:435
[<ffffffff82f1a156>] sock_release+0x96/0x1c0 net/socket.c:586
[<ffffffff82f1a296>] sock_close+0x16/0x20 net/socket.c:1037
[<ffffffff81522da5>] __fput+0x235/0x6f0 fs/file_table.c:208
[<ffffffff815232e5>] ____fput+0x15/0x20 fs/file_table.c:244
[<ffffffff8118bd7f>] task_work_run+0x10f/0x190 kernel/task_work.c:115
[<ffffffff81135285>] exit_task_work include/linux/task_work.h:21 [inline]
[<ffffffff81135285>] do_exit+0x9e5/0x26b0 kernel/exit.c:759
[<ffffffff8113b1d1>] do_group_exit+0x111/0x330 kernel/exit.c:889
[<ffffffff8115e5cc>] get_signal+0x4ec/0x14b0 kernel/signal.c:2321
[<ffffffff8100e02b>] do_signal+0x8b/0x1d30 arch/x86/kernel/signal.c:712
[<ffffffff8100360a>] exit_to_usermode_loop+0x11a/0x160 arch/x86/entry/common.c:248
[<ffffffff81006535>] prepare_exit_to_usermode arch/x86/entry/common.c:283 [inline]
[<ffffffff81006535>] syscall_return_slowpath+0x1b5/0x1f0 arch/x86/entry/common.c:348
[<ffffffff838c29b5>] int_ret_from_sys_call+0x25/0xa3
Allocated by task 4194:
[<ffffffff810341d6>] save_stack_trace+0x26/0x50 arch/x86/kernel/stacktrace.c:63
[<ffffffff814f8873>] save_stack+0x43/0xd0 mm/kasan/kasan.c:512
[<ffffffff814f8b57>] set_track mm/kasan/kasan.c:524 [inline]
[<ffffffff814f8b57>] kasan_kmalloc+0xc7/0xe0 mm/kasan/kasan.c:616
[<ffffffff814f9122>] kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:554
[<ffffffff814f4c1e>] slab_post_alloc_hook mm/slub.c:1349 [inline]
[<ffffffff814f4c1e>] slab_alloc_node mm/slub.c:2615 [inline]
[<ffffffff814f4c1e>] slab_alloc mm/slub.c:2623 [inline]
[<ffffffff814f4c1e>] kmem_cache_alloc+0xbe/0x2a0 mm/slub.c:2628
[<ffffffff82f380a6>] kmem_cache_alloc_node include/linux/slab.h:350 [inline]
[<ffffffff82f380a6>] __alloc_skb+0xe6/0x600 net/core/skbuff.c:218
[<ffffffff832466c3>] alloc_skb_fclone include/linux/skbuff.h:856 [inline]
[<ffffffff832466c3>] sk_stream_alloc_skb+0xa3/0x5d0 net/ipv4/tcp.c:833
[<ffffffff83249164>] tcp_sendmsg+0xd34/0x2b00 net/ipv4/tcp.c:1178
[<ffffffff83300ef3>] inet_sendmsg+0x203/0x4d0 net/ipv4/af_inet.c:755
[<ffffffff82f1e1fc>] sock_sendmsg_nosec net/socket.c:625 [inline]
[<ffffffff82f1e1fc>] sock_sendmsg+0xcc/0x110 net/socket.c:635
[<ffffffff82f1eedc>] SYSC_sendto+0x21c/0x370 net/socket.c:1665
[<ffffffff82f21560>] SyS_sendto+0x40/0x50 net/socket.c:1633
[<ffffffff838c2825>] entry_SYSCALL_64_fastpath+0x22/0x9e
Freed by task 4194:
[<ffffffff810341d6>] save_stack_trace+0x26/0x50 arch/x86/kernel/stacktrace.c:63
[<ffffffff814f8873>] save_stack+0x43/0xd0 mm/kasan/kasan.c:512
[<ffffffff814f91a2>] set_track mm/kasan/kasan.c:524 [inline]
[<ffffffff814f91a2>] kasan_slab_free+0x72/0xc0 mm/kasan/kasan.c:589
[<ffffffff814f632e>] slab_free_hook mm/slub.c:1383 [inline]
[<ffffffff814f632e>] slab_free_freelist_hook mm/slub.c:1405 [inline]
[<ffffffff814f632e>] slab_free mm/slub.c:2859 [inline]
[<ffffffff814f632e>] kmem_cache_free+0xbe/0x340 mm/slub.c:2881
[<ffffffff82f3527f>] kfree_skbmem+0xcf/0x100 net/core/skbuff.c:635
[<ffffffff82f372fd>] __kfree_skb+0x1d/0x20 net/core/skbuff.c:676
[<ffffffff83288834>] sk_wmem_free_skb include/net/sock.h:1447 [inline]
[<ffffffff83288834>] tcp_write_queue_purge include/net/tcp.h:1460 [inline]
[<ffffffff83288834>] tcp_connect_init net/ipv4/tcp_output.c:3122 [inline]
[<ffffffff83288834>] tcp_connect+0xb24/0x30c0 net/ipv4/tcp_output.c:3261
[<ffffffff8329b991>] tcp_v4_connect+0xf31/0x1890 net/ipv4/tcp_ipv4.c:246
[<ffffffff832f9ca9>] __inet_stream_connect+0x2a9/0xc30 net/ipv4/af_inet.c:615
[<ffffffff832fa685>] inet_stream_connect+0x55/0xa0 net/ipv4/af_inet.c:676
[<ffffffff82f1eb78>] SYSC_connect+0x1b8/0x300 net/socket.c:1557
[<ffffffff82f214b4>] SyS_connect+0x24/0x30 net/socket.c:1538
[<ffffffff838c2825>] entry_SYSCALL_64_fastpath+0x22/0x9e
Syzkaller reproducer():
r0 = socket$packet(0x11, 0x3, 0x300)
r1 = socket$inet_tcp(0x2, 0x1, 0x0)
bind$inet(r1, &(0x7f0000000300)={0x2, 0x4e21, @multicast1}, 0x10)
connect$inet(r1, &(0x7f0000000140)={0x2, 0x1000004e21, @loopback}, 0x10)
recvmmsg(r1, &(0x7f0000001e40)=[{{0x0, 0x0, &(0x7f0000000100)=[{&(0x7f00000005c0)=""/88, 0x58}], 0x1}}], 0x1, 0x40000000, 0x0)
sendto$inet(r1, &(0x7f0000000000)="e2f7ad5b661c761edf", 0x9, 0x8080, 0x0, 0x0)
r2 = fcntl$dupfd(r1, 0x0, r0)
connect$unix(r2, &(0x7f00000001c0)=@file={0x0, './file0\x00'}, 0x6e)
C repro link: https://syzkaller.appspot.com/text?tag=ReproC&x=14db474f800000
This is because when tcp_connect_init call tcp_write_queue_purge, it will
kfree all the skb in the write_queue, but the sk->sk_send_head forget to set NULL,
then tcp_write_xmit try to send skb, which has freed in tcp_write_queue_purge, UAF happens.
Signed-off-by: Mao Wenan <maowenan@huawei.com>
---
include/net/tcp.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/net/tcp.h b/include/net/tcp.h
index bf8a0dae977a..8f8aace28cf8 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -1457,6 +1457,7 @@ static inline void tcp_write_queue_purge(struct sock *sk)
while ((skb = __skb_dequeue(&sk->sk_write_queue)) != NULL)
sk_wmem_free_skb(sk, skb);
+ sk->sk_send_head = NULL;
sk_mem_reclaim(sk);
tcp_clear_all_retrans_hints(tcp_sk(sk));
inet_csk(sk)->icsk_backoff = 0;
--
2.20.1
^ permalink raw reply related
* Re: [PATCH] can: ti_hecc: use timestamp based rx-offloading
From: Jeroen Hofstee @ 2019-07-24 9:13 UTC (permalink / raw)
To: Marc Kleine-Budde, linux-can@vger.kernel.org
Cc: Anant Gole, AnilKumar Ch, Wolfgang Grandegger, David S. Miller,
open list:NETWORKING DRIVERS, open list
In-Reply-To: <5881cb80-883b-a96b-2939-973150cfc196@pengutronix.de>
Hello Marc,
On 7/24/19 10:26 AM, Marc Kleine-Budde wrote:
> On 4/29/19 2:03 PM, Jeroen Hofstee wrote:
>> As already mentioned in [1] and included in [2], there is an off by one
>> issue since the high bank is already enabled when the _next_ mailbox to
>> be read has index 12, so the mailbox being read was 13. The message can
>> therefore go into mailbox 31 and the driver will be repolled until the
>> mailbox 12 eventually receives a msg. Or the message might end up in the
>> 12th mailbox, but then it would become disabled after reading it and only
>> be enabled again in the next "round" after mailbox 13 was read, which can
>> cause out of order messages, since the lower priority mailboxes can
>> accept messages in the meantime.
>>
>> As mentioned in [3] there is a hardware race condition when changing the
>> CANME register while messages are being received. Even when including a
>> busy poll on reception, like in [2] there are still overflows and out of
>> order messages at times, but less then without the busy loop polling.
>> Unlike what the patch suggests, the polling time is not in the microsecond
>> range, but takes as long as a current CAN bus reception needs to finish,
>> so typically more in the fraction of millisecond range. Since the timeout
>> is in jiffies it won't timeout.
>>
>> Even with these additional fixes the driver is still not able to provide a
>> proper FIFO which doesn't drop packages. So change the driver to use
>> rx-offload and base order on timestamp instead of message box numbers. As
>> a side affect, this also fixes [4] and [5].
>>
>> Before this change messages with a single byte counter were dropped /
>> received out of order at a bitrate of 250kbit/s on an am3517. With this
>> patch that no longer occurs up to and including 1Mbit/s.
>>
>> [1] https://linux-can.vger.kernel.narkive.com/zgO9inVi/patch-can-ti-hecc-fix-rx-wrong-sequence-issue#post6
>> [2] http://arago-project.org/git/projects/?p=linux-omap3.git;a=commit;h=02346892777f07245de4d5af692513ebd852dcb2
>> [3] https://linux-can.vger.kernel.narkive.com/zgO9inVi/patch-can-ti-hecc-fix-rx-wrong-sequence-issue#post5
>> [4] https://patchwork.ozlabs.org/patch/895956/
>> [5] https://www.spinics.net/lists/netdev/msg494971.html
>>
>> Cc: Anant Gole <anantgole@ti.com>
>> Cc: AnilKumar Ch <anilkumar@ti.com>
>> Signed-off-by: Jeroen Hofstee <jhofstee@victronenergy.com>
>> ---
>> drivers/net/can/ti_hecc.c | 189 +++++++++++++---------------------------------
>> 1 file changed, 53 insertions(+), 136 deletions(-)
>>
>> diff --git a/drivers/net/can/ti_hecc.c b/drivers/net/can/ti_hecc.c
>> index db6ea93..fe7ffff 100644
>> --- a/drivers/net/can/ti_hecc.c
>> +++ b/drivers/net/can/ti_hecc.c
>> @@ -5,6 +5,7 @@
>> * specs for the same is available at <http://www.ti.com>
>> *
>> * Copyright (C) 2009 Texas Instruments Incorporated - http://www.ti.com/
>> + * Copyright (C) 2019 Jeroen Hofstee <jhofstee@victronenergy.com>
>> *
>> * This program is free software; you can redistribute it and/or
>> * modify it under the terms of the GNU General Public License as
>> @@ -34,6 +35,7 @@
>> #include <linux/can/dev.h>
>> #include <linux/can/error.h>
>> #include <linux/can/led.h>
>> +#include <linux/can/rx-offload.h>
>>
>> #define DRV_NAME "ti_hecc"
>> #define HECC_MODULE_VERSION "0.7"
>> @@ -63,29 +65,16 @@ MODULE_VERSION(HECC_MODULE_VERSION);
>> #define HECC_TX_PRIO_MASK (MAX_TX_PRIO << HECC_MB_TX_SHIFT)
>> #define HECC_TX_MB_MASK (HECC_MAX_TX_MBOX - 1)
>> #define HECC_TX_MASK ((HECC_MAX_TX_MBOX - 1) | HECC_TX_PRIO_MASK)
>> -#define HECC_TX_MBOX_MASK (~(BIT(HECC_MAX_TX_MBOX) - 1))
>> -#define HECC_DEF_NAPI_WEIGHT HECC_MAX_RX_MBOX
>>
>> /*
>> - * Important Note: RX mailbox configuration
>> - * RX mailboxes are further logically split into two - main and buffer
>> - * mailboxes. The goal is to get all packets into main mailboxes as
>> - * driven by mailbox number and receive priority (higher to lower) and
>> - * buffer mailboxes are used to receive pkts while main mailboxes are being
>> - * processed. This ensures in-order packet reception.
>> - *
>> - * Here are the recommended values for buffer mailbox. Note that RX mailboxes
>> - * start after TX mailboxes:
>> - *
>> - * HECC_MAX_RX_MBOX HECC_RX_BUFFER_MBOX No of buffer mailboxes
>> - * 28 12 8
>> - * 16 20 4
>> + * RX mailbox configuration
>> + * The remaining mailboxes are used for reception and are delivered based on
>> + * their timestamp, to avoid a hardware race when CANME is changed while
>> + * CAN-bus traffix is being received.
>> */
>>
>> #define HECC_MAX_RX_MBOX (HECC_MAX_MAILBOXES - HECC_MAX_TX_MBOX)
>> -#define HECC_RX_BUFFER_MBOX 12 /* as per table above */
>> #define HECC_RX_FIRST_MBOX (HECC_MAX_MAILBOXES - 1)
>> -#define HECC_RX_HIGH_MBOX_MASK (~(BIT(HECC_RX_BUFFER_MBOX) - 1))
>>
>> /* TI HECC module registers */
>> #define HECC_CANME 0x0 /* Mailbox enable */
>> @@ -123,6 +112,8 @@ MODULE_VERSION(HECC_MODULE_VERSION);
>> #define HECC_CANMDL 0x8
>> #define HECC_CANMDH 0xC
>>
>> +#define HECC_CANMOTS 0x100
> It's actually 0x80
>
>> +
>> #define HECC_SET_REG 0xFFFFFFFF
>> #define HECC_CANID_MASK 0x3FF /* 18 bits mask for extended id's */
>> #define HECC_CCE_WAIT_COUNT 100 /* Wait for ~1 sec for CCE bit */
>> @@ -193,7 +184,7 @@ static const struct can_bittiming_const ti_hecc_bittiming_const = {
>>
>> struct ti_hecc_priv {
>> struct can_priv can; /* MUST be first member/field */
>> - struct napi_struct napi;
>> + struct can_rx_offload offload;
>> struct net_device *ndev;
>> struct clk *clk;
>> void __iomem *base;
>> @@ -203,7 +194,6 @@ struct ti_hecc_priv {
>> spinlock_t mbx_lock; /* CANME register needs protection */
>> u32 tx_head;
>> u32 tx_tail;
>> - u32 rx_next;
>> struct regulator *reg_xceiver;
>> };
>>
>> @@ -265,6 +255,11 @@ static inline u32 hecc_get_bit(struct ti_hecc_priv *priv, int reg, u32 bit_mask)
>> return (hecc_read(priv, reg) & bit_mask) ? 1 : 0;
>> }
>>
>> +static inline u32 hecc_read_stamp(struct ti_hecc_priv *priv, u32 mbxno)
>> +{
>> + return __raw_readl(priv->hecc_ram + 0x80 + 4 * mbxno);
> I've changed this function to use HECC_CANMOTS.
>
That is correct. For completeness the HECC_CANMOTS wasn't
even used in the original patch, so there is no functional difference.
Thanks,
Jeroen
^ permalink raw reply
* Re: [PATCH 4.4 stable net] net: tcp: Fix use-after-free in tcp_write_xmit
From: maowenan @ 2019-07-24 9:15 UTC (permalink / raw)
To: davem, gregkh, netdev, linux-kernel
Cc: stable, Wangkefeng (Maro), weiyongjun (A)
In-Reply-To: <20190724091715.137033-1-maowenan@huawei.com>
Add stable@vger.kernel.org.
On 2019/7/24 17:17, Mao Wenan wrote:
> There is one report about tcp_write_xmit use-after-free with version 4.4.136:
>
> BUG: KASAN: use-after-free in tcp_skb_pcount include/net/tcp.h:796 [inline]
> BUG: KASAN: use-after-free in tcp_init_tso_segs net/ipv4/tcp_output.c:1619 [inline]
> BUG: KASAN: use-after-free in tcp_write_xmit+0x3fc2/0x4cb0 net/ipv4/tcp_output.c:2056
> Read of size 2 at addr ffff8801d6fc87b0 by task syz-executor408/4195
>
> CPU: 0 PID: 4195 Comm: syz-executor408 Not tainted 4.4.136-gfb7e319 #59
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
> 0000000000000000 7d8f38ecc03be946 ffff8801d73b7710 ffffffff81e0edad
> ffffea00075bf200 ffff8801d6fc87b0 0000000000000000 ffff8801d6fc87b0
> dffffc0000000000 ffff8801d73b7748 ffffffff815159b6 ffff8801d6fc87b0
> Call Trace:
> [<ffffffff81e0edad>] __dump_stack lib/dump_stack.c:15 [inline]
> [<ffffffff81e0edad>] dump_stack+0xc1/0x124 lib/dump_stack.c:51
> [<ffffffff815159b6>] print_address_description+0x6c/0x216 mm/kasan/report.c:252
> [<ffffffff81515cd5>] kasan_report_error mm/kasan/report.c:351 [inline]
> [<ffffffff81515cd5>] kasan_report.cold.7+0x175/0x2f7 mm/kasan/report.c:408
> [<ffffffff814f9784>] __asan_report_load2_noabort+0x14/0x20 mm/kasan/report.c:427
> [<ffffffff83286582>] tcp_skb_pcount include/net/tcp.h:796 [inline]
> [<ffffffff83286582>] tcp_init_tso_segs net/ipv4/tcp_output.c:1619 [inline]
> [<ffffffff83286582>] tcp_write_xmit+0x3fc2/0x4cb0 net/ipv4/tcp_output.c:2056
> [<ffffffff83287a40>] __tcp_push_pending_frames+0xa0/0x290 net/ipv4/tcp_output.c:2307
> [<ffffffff8328e966>] tcp_send_fin+0x176/0xab0 net/ipv4/tcp_output.c:2883
> [<ffffffff8324c0d0>] tcp_close+0xca0/0xf70 net/ipv4/tcp.c:2112
> [<ffffffff832f8d0f>] inet_release+0xff/0x1d0 net/ipv4/af_inet.c:435
> [<ffffffff82f1a156>] sock_release+0x96/0x1c0 net/socket.c:586
> [<ffffffff82f1a296>] sock_close+0x16/0x20 net/socket.c:1037
> [<ffffffff81522da5>] __fput+0x235/0x6f0 fs/file_table.c:208
> [<ffffffff815232e5>] ____fput+0x15/0x20 fs/file_table.c:244
> [<ffffffff8118bd7f>] task_work_run+0x10f/0x190 kernel/task_work.c:115
> [<ffffffff81135285>] exit_task_work include/linux/task_work.h:21 [inline]
> [<ffffffff81135285>] do_exit+0x9e5/0x26b0 kernel/exit.c:759
> [<ffffffff8113b1d1>] do_group_exit+0x111/0x330 kernel/exit.c:889
> [<ffffffff8115e5cc>] get_signal+0x4ec/0x14b0 kernel/signal.c:2321
> [<ffffffff8100e02b>] do_signal+0x8b/0x1d30 arch/x86/kernel/signal.c:712
> [<ffffffff8100360a>] exit_to_usermode_loop+0x11a/0x160 arch/x86/entry/common.c:248
> [<ffffffff81006535>] prepare_exit_to_usermode arch/x86/entry/common.c:283 [inline]
> [<ffffffff81006535>] syscall_return_slowpath+0x1b5/0x1f0 arch/x86/entry/common.c:348
> [<ffffffff838c29b5>] int_ret_from_sys_call+0x25/0xa3
>
> Allocated by task 4194:
> [<ffffffff810341d6>] save_stack_trace+0x26/0x50 arch/x86/kernel/stacktrace.c:63
> [<ffffffff814f8873>] save_stack+0x43/0xd0 mm/kasan/kasan.c:512
> [<ffffffff814f8b57>] set_track mm/kasan/kasan.c:524 [inline]
> [<ffffffff814f8b57>] kasan_kmalloc+0xc7/0xe0 mm/kasan/kasan.c:616
> [<ffffffff814f9122>] kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:554
> [<ffffffff814f4c1e>] slab_post_alloc_hook mm/slub.c:1349 [inline]
> [<ffffffff814f4c1e>] slab_alloc_node mm/slub.c:2615 [inline]
> [<ffffffff814f4c1e>] slab_alloc mm/slub.c:2623 [inline]
> [<ffffffff814f4c1e>] kmem_cache_alloc+0xbe/0x2a0 mm/slub.c:2628
> [<ffffffff82f380a6>] kmem_cache_alloc_node include/linux/slab.h:350 [inline]
> [<ffffffff82f380a6>] __alloc_skb+0xe6/0x600 net/core/skbuff.c:218
> [<ffffffff832466c3>] alloc_skb_fclone include/linux/skbuff.h:856 [inline]
> [<ffffffff832466c3>] sk_stream_alloc_skb+0xa3/0x5d0 net/ipv4/tcp.c:833
> [<ffffffff83249164>] tcp_sendmsg+0xd34/0x2b00 net/ipv4/tcp.c:1178
> [<ffffffff83300ef3>] inet_sendmsg+0x203/0x4d0 net/ipv4/af_inet.c:755
> [<ffffffff82f1e1fc>] sock_sendmsg_nosec net/socket.c:625 [inline]
> [<ffffffff82f1e1fc>] sock_sendmsg+0xcc/0x110 net/socket.c:635
> [<ffffffff82f1eedc>] SYSC_sendto+0x21c/0x370 net/socket.c:1665
> [<ffffffff82f21560>] SyS_sendto+0x40/0x50 net/socket.c:1633
> [<ffffffff838c2825>] entry_SYSCALL_64_fastpath+0x22/0x9e
>
> Freed by task 4194:
> [<ffffffff810341d6>] save_stack_trace+0x26/0x50 arch/x86/kernel/stacktrace.c:63
> [<ffffffff814f8873>] save_stack+0x43/0xd0 mm/kasan/kasan.c:512
> [<ffffffff814f91a2>] set_track mm/kasan/kasan.c:524 [inline]
> [<ffffffff814f91a2>] kasan_slab_free+0x72/0xc0 mm/kasan/kasan.c:589
> [<ffffffff814f632e>] slab_free_hook mm/slub.c:1383 [inline]
> [<ffffffff814f632e>] slab_free_freelist_hook mm/slub.c:1405 [inline]
> [<ffffffff814f632e>] slab_free mm/slub.c:2859 [inline]
> [<ffffffff814f632e>] kmem_cache_free+0xbe/0x340 mm/slub.c:2881
> [<ffffffff82f3527f>] kfree_skbmem+0xcf/0x100 net/core/skbuff.c:635
> [<ffffffff82f372fd>] __kfree_skb+0x1d/0x20 net/core/skbuff.c:676
> [<ffffffff83288834>] sk_wmem_free_skb include/net/sock.h:1447 [inline]
> [<ffffffff83288834>] tcp_write_queue_purge include/net/tcp.h:1460 [inline]
> [<ffffffff83288834>] tcp_connect_init net/ipv4/tcp_output.c:3122 [inline]
> [<ffffffff83288834>] tcp_connect+0xb24/0x30c0 net/ipv4/tcp_output.c:3261
> [<ffffffff8329b991>] tcp_v4_connect+0xf31/0x1890 net/ipv4/tcp_ipv4.c:246
> [<ffffffff832f9ca9>] __inet_stream_connect+0x2a9/0xc30 net/ipv4/af_inet.c:615
> [<ffffffff832fa685>] inet_stream_connect+0x55/0xa0 net/ipv4/af_inet.c:676
> [<ffffffff82f1eb78>] SYSC_connect+0x1b8/0x300 net/socket.c:1557
> [<ffffffff82f214b4>] SyS_connect+0x24/0x30 net/socket.c:1538
> [<ffffffff838c2825>] entry_SYSCALL_64_fastpath+0x22/0x9e
>
> Syzkaller reproducer():
> r0 = socket$packet(0x11, 0x3, 0x300)
> r1 = socket$inet_tcp(0x2, 0x1, 0x0)
> bind$inet(r1, &(0x7f0000000300)={0x2, 0x4e21, @multicast1}, 0x10)
> connect$inet(r1, &(0x7f0000000140)={0x2, 0x1000004e21, @loopback}, 0x10)
> recvmmsg(r1, &(0x7f0000001e40)=[{{0x0, 0x0, &(0x7f0000000100)=[{&(0x7f00000005c0)=""/88, 0x58}], 0x1}}], 0x1, 0x40000000, 0x0)
> sendto$inet(r1, &(0x7f0000000000)="e2f7ad5b661c761edf", 0x9, 0x8080, 0x0, 0x0)
> r2 = fcntl$dupfd(r1, 0x0, r0)
> connect$unix(r2, &(0x7f00000001c0)=@file={0x0, './file0\x00'}, 0x6e)
>
> C repro link: https://syzkaller.appspot.com/text?tag=ReproC&x=14db474f800000
>
> This is because when tcp_connect_init call tcp_write_queue_purge, it will
> kfree all the skb in the write_queue, but the sk->sk_send_head forget to set NULL,
> then tcp_write_xmit try to send skb, which has freed in tcp_write_queue_purge, UAF happens.
>
> Signed-off-by: Mao Wenan <maowenan@huawei.com>
> ---
> include/net/tcp.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/include/net/tcp.h b/include/net/tcp.h
> index bf8a0dae977a..8f8aace28cf8 100644
> --- a/include/net/tcp.h
> +++ b/include/net/tcp.h
> @@ -1457,6 +1457,7 @@ static inline void tcp_write_queue_purge(struct sock *sk)
>
> while ((skb = __skb_dequeue(&sk->sk_write_queue)) != NULL)
> sk_wmem_free_skb(sk, skb);
> + sk->sk_send_head = NULL;
> sk_mem_reclaim(sk);
> tcp_clear_all_retrans_hints(tcp_sk(sk));
> inet_csk(sk)->icsk_backoff = 0;
>
^ permalink raw reply
* Re: pull-request: can-next 2019-07-24
From: Oliver Hartkopp @ 2019-07-24 9:22 UTC (permalink / raw)
To: Marc Kleine-Budde, netdev; +Cc: davem, kernel, linux-can
In-Reply-To: <93540cba-184a-a9c5-f9d2-b1779a69a36f@pengutronix.de>
Hi Marc,
why didn't you include the CAN FD support for the can-gw?
[PATCH 1/2] can: gw: use struct canfd_frame as internal data structure
https://marc.info/?l=linux-can&m=156388681922741&w=2
[PATCH 2/2] can: gw: add support for CAN FD frames
https://marc.info/?l=linux-can&m=156388682022742&w=2
The patches have already been sent in January as RFC and I did extensive
testing since then.
Regards,
Oliver
On 24.07.19 11:00, Marc Kleine-Budde wrote:
> Hello David,
>
> this is a pull request for net-next/master consisting of 26 patches.
>
> The first two patches are by me. One adds missing files of the CAN
> subsystem to the MAINTAINERS file, while the other sorts the
> Makefile/Kconfig of the sja1000 drivers sub directory. In the next patch
> Ji-Ze Hong (Peter Hong) provides a driver for the "Fintek PCIE to 2 CAN"
> controller, based on the the sja1000 IP core.
>
> Gustavo A. R. Silva's patch for the kvaser_usb driver introduces the use
> of struct_size() instead of open coding it. Henning Colliander's patch
> adds a driver for the "Kvaser PCIEcan" devices.
>
> Another patch by Gustavo A. R. Silva marks expected switch fall-throughs
> properly.
>
> Dan Murphy provides 5 patches for the m_can. After cleanups a framework
> is introduced so that the driver can be used from memory mapped IO as
> well as SPI attached devices. Finally he adds a driver for the tcan4x5x
> which uses this framework.
>
> A series of 5 patches by Appana Durga Kedareswara rao for the xilinx_can
> driver, first clean up,then add support for CANFD. Colin Ian King
> contributes another cleanup for the xilinx_can driver.
>
> Robert P. J. Day's patch corrects the brief history of the CAN protocol
> given in the Kconfig menu entry.
>
> 2 patches by Dong Aisheng for the flexcan driver provide PE clock source
> select support and dt-bindings description.
> 2 patches by Sean Nyekjaer for the flexcan driver provide add CAN
> wakeup-source property and dt-bindings description.
>
> Jeroen Hofstee's patch converts the ti_hecc driver to make use of the
> rx-offload helper fixing a number of outstanding bugs.
>
> The first patch of Oliver Hartkopp removes the now obsolete empty
> ioctl() handler for the CAN protocols. The second patch adds SPDX
> license identifiers for CAN subsystem.
>
> regards,
> Marc
>
> ---
>
> The following changes since commit 3e3bb69589e482e0783f28d4cd1d8e56fda0bcbb:
>
> tc-testing: added tdc tests for [b|p]fifo qdisc (2019-07-23 14:08:15 -0700)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next.git tags/linux-can-next-for-5.4-20190724
>
> for you to fetch changes up to fba76a58452694b9b13c07e48839fa84c75f57af:
>
> can: Add SPDX license identifiers for CAN subsystem (2019-07-24 10:31:55 +0200)
>
> ----------------------------------------------------------------
> linux-can-next-for-5.4-20190724
>
> ----------------------------------------------------------------
> Aisheng Dong (1):
> can: flexcan: implement can Runtime PM
>
> Appana Durga Kedareswara rao (5):
> can: xilinx_can: Fix style issues
> can: xilinx_can: Fix kernel doc warnings
> can: xilinx_can: Fix flags field initialization for axi can and canps
> can: xilinx_can: Add cantype parameter in xcan_devtype_data struct
> can: xilinx_can: Add support for CANFD FD frames
>
> Colin Ian King (1):
> can: xilinx_can: clean up indentation issue
>
> Dan Murphy (5):
> can: m_can: Fix checkpatch issues on existing code
> can: m_can: Create a m_can platform framework
> can: m_can: Rename m_can_priv to m_can_classdev
> dt-bindings: can: tcan4x5x: Add DT bindings for TCAN4x5X driver
> can: tcan4x5x: Add tcan4x5x driver to the kernel
>
> Dong Aisheng (2):
> dt-bindings: can: flexcan: add PE clock source property to device tree
> can: flexcan: add support for PE clock source select
>
> Gustavo A. R. Silva (2):
> can: kvaser_usb: Use struct_size() in alloc_candev()
> can: mark expected switch fall-throughs
>
> Henning Colliander (1):
> can: kvaser_pciefd: Add driver for Kvaser PCIEcan devices
>
> Jeroen Hofstee (1):
> can: ti_hecc: use timestamp based rx-offloading
>
> Ji-Ze Hong (Peter Hong) (1):
> can: sja1000: f81601: add Fintek F81601 support
>
> Marc Kleine-Budde (2):
> MAINTAINERS: can: add missing files to CAN NETWORK DRIVERS and CAN NETWORK LAYER
> can: sja1000: Makefile/Kconfig: sort alphabetically
>
> Oliver Hartkopp (2):
> can: remove obsolete empty ioctl() handler
> can: Add SPDX license identifiers for CAN subsystem
>
> Robert P. J. Day (1):
> can: Kconfig: correct history of the CAN protocol
>
> Sean Nyekjaer (2):
> dt-bindings: can: flexcan: add can wakeup property
> can: flexcan: add support for DT property 'wakeup-source'
>
> .../devicetree/bindings/net/can/fsl-flexcan.txt | 10 +
> .../devicetree/bindings/net/can/tcan4x5x.txt | 37 +
> MAINTAINERS | 5 +
> drivers/net/can/Kconfig | 13 +
> drivers/net/can/Makefile | 1 +
> drivers/net/can/at91_can.c | 6 +-
> drivers/net/can/flexcan.c | 136 +-
> drivers/net/can/kvaser_pciefd.c | 1912 ++++++++++++++++++++
> drivers/net/can/m_can/Kconfig | 22 +-
> drivers/net/can/m_can/Makefile | 2 +
> drivers/net/can/m_can/m_can.c | 1079 +++++------
> drivers/net/can/m_can/m_can.h | 110 ++
> drivers/net/can/m_can/m_can_platform.c | 202 +++
> drivers/net/can/m_can/tcan4x5x.c | 532 ++++++
> drivers/net/can/peak_canfd/peak_pciefd_main.c | 2 +-
> drivers/net/can/sja1000/Kconfig | 79 +-
> drivers/net/can/sja1000/Makefile | 11 +-
> drivers/net/can/sja1000/f81601.c | 212 +++
> drivers/net/can/spi/mcp251x.c | 3 +-
> drivers/net/can/ti_hecc.c | 191 +-
> drivers/net/can/usb/kvaser_usb/kvaser_usb_core.c | 3 +-
> drivers/net/can/usb/peak_usb/pcan_usb.c | 2 +-
> drivers/net/can/xilinx_can.c | 293 ++-
> include/linux/can/core.h | 3 +-
> include/linux/can/skb.h | 2 +-
> net/can/Kconfig | 11 +-
> net/can/af_can.c | 10 +-
> net/can/af_can.h | 1 +
> net/can/bcm.c | 3 +-
> net/can/gw.c | 1 +
> net/can/proc.c | 1 +
> net/can/raw.c | 3 +-
> 32 files changed, 4098 insertions(+), 800 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/net/can/tcan4x5x.txt
> create mode 100644 drivers/net/can/kvaser_pciefd.c
> create mode 100644 drivers/net/can/m_can/m_can.h
> create mode 100644 drivers/net/can/m_can/m_can_platform.c
> create mode 100644 drivers/net/can/m_can/tcan4x5x.c
> create mode 100644 drivers/net/can/sja1000/f81601.c
>
^ permalink raw reply
* RE: pull-request: can-next 2019-07-24
From: Stéphane Grosjean @ 2019-07-24 9:24 UTC (permalink / raw)
To: Marc Kleine-Budde, netdev@vger.kernel.org
Cc: kernel@pengutronix.de, linux-can@vger.kernel.org
In-Reply-To: <93540cba-184a-a9c5-f9d2-b1779a69a36f@pengutronix.de>
[-- Attachment #1: Type: text/plain, Size: 8120 bytes --]
Hello Mark,
I hope you're fine. Did you see the attached patch I've sent earlier this month?
Regards,
— Stéphane
> -----Original Message-----
> From: linux-can-owner@vger.kernel.org <linux-can-
> owner@vger.kernel.org> On Behalf Of Marc Kleine-Budde
> Sent: mercredi 24 juillet 2019 11:00
> To: netdev@vger.kernel.org
> Cc: davem@davemloft.net; kernel@pengutronix.de; linux-
> can@vger.kernel.org
> Subject: pull-request: can-next 2019-07-24
>
> Hello David,
>
> this is a pull request for net-next/master consisting of 26 patches.
>
> The first two patches are by me. One adds missing files of the CAN
> subsystem to the MAINTAINERS file, while the other sorts the
> Makefile/Kconfig of the sja1000 drivers sub directory. In the next patch Ji-Ze
> Hong (Peter Hong) provides a driver for the "Fintek PCIE to 2 CAN"
> controller, based on the the sja1000 IP core.
>
> Gustavo A. R. Silva's patch for the kvaser_usb driver introduces the use of
> struct_size() instead of open coding it. Henning Colliander's patch adds a
> driver for the "Kvaser PCIEcan" devices.
>
> Another patch by Gustavo A. R. Silva marks expected switch fall-throughs
> properly.
>
> Dan Murphy provides 5 patches for the m_can. After cleanups a framework
> is introduced so that the driver can be used from memory mapped IO as well
> as SPI attached devices. Finally he adds a driver for the tcan4x5x which uses
> this framework.
>
> A series of 5 patches by Appana Durga Kedareswara rao for the xilinx_can
> driver, first clean up,then add support for CANFD. Colin Ian King contributes
> another cleanup for the xilinx_can driver.
>
> Robert P. J. Day's patch corrects the brief history of the CAN protocol given in
> the Kconfig menu entry.
>
> 2 patches by Dong Aisheng for the flexcan driver provide PE clock source
> select support and dt-bindings description.
> 2 patches by Sean Nyekjaer for the flexcan driver provide add CAN wakeup-
> source property and dt-bindings description.
>
> Jeroen Hofstee's patch converts the ti_hecc driver to make use of the rx-
> offload helper fixing a number of outstanding bugs.
>
> The first patch of Oliver Hartkopp removes the now obsolete empty
> ioctl() handler for the CAN protocols. The second patch adds SPDX license
> identifiers for CAN subsystem.
>
> regards,
> Marc
>
> ---
>
> The following changes since commit
> 3e3bb69589e482e0783f28d4cd1d8e56fda0bcbb:
>
> tc-testing: added tdc tests for [b|p]fifo qdisc (2019-07-23 14:08:15 -0700)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next.git
> tags/linux-can-next-for-5.4-20190724
>
> for you to fetch changes up to fba76a58452694b9b13c07e48839fa84c75f57af:
>
> can: Add SPDX license identifiers for CAN subsystem (2019-07-24 10:31:55
> +0200)
>
> ----------------------------------------------------------------
> linux-can-next-for-5.4-20190724
>
> ----------------------------------------------------------------
> Aisheng Dong (1):
> can: flexcan: implement can Runtime PM
>
> Appana Durga Kedareswara rao (5):
> can: xilinx_can: Fix style issues
> can: xilinx_can: Fix kernel doc warnings
> can: xilinx_can: Fix flags field initialization for axi can and canps
> can: xilinx_can: Add cantype parameter in xcan_devtype_data struct
> can: xilinx_can: Add support for CANFD FD frames
>
> Colin Ian King (1):
> can: xilinx_can: clean up indentation issue
>
> Dan Murphy (5):
> can: m_can: Fix checkpatch issues on existing code
> can: m_can: Create a m_can platform framework
> can: m_can: Rename m_can_priv to m_can_classdev
> dt-bindings: can: tcan4x5x: Add DT bindings for TCAN4x5X driver
> can: tcan4x5x: Add tcan4x5x driver to the kernel
>
> Dong Aisheng (2):
> dt-bindings: can: flexcan: add PE clock source property to device tree
> can: flexcan: add support for PE clock source select
>
> Gustavo A. R. Silva (2):
> can: kvaser_usb: Use struct_size() in alloc_candev()
> can: mark expected switch fall-throughs
>
> Henning Colliander (1):
> can: kvaser_pciefd: Add driver for Kvaser PCIEcan devices
>
> Jeroen Hofstee (1):
> can: ti_hecc: use timestamp based rx-offloading
>
> Ji-Ze Hong (Peter Hong) (1):
> can: sja1000: f81601: add Fintek F81601 support
>
> Marc Kleine-Budde (2):
> MAINTAINERS: can: add missing files to CAN NETWORK DRIVERS and CAN
> NETWORK LAYER
> can: sja1000: Makefile/Kconfig: sort alphabetically
>
> Oliver Hartkopp (2):
> can: remove obsolete empty ioctl() handler
> can: Add SPDX license identifiers for CAN subsystem
>
> Robert P. J. Day (1):
> can: Kconfig: correct history of the CAN protocol
>
> Sean Nyekjaer (2):
> dt-bindings: can: flexcan: add can wakeup property
> can: flexcan: add support for DT property 'wakeup-source'
>
> .../devicetree/bindings/net/can/fsl-flexcan.txt | 10 +
> .../devicetree/bindings/net/can/tcan4x5x.txt | 37 +
> MAINTAINERS | 5 +
> drivers/net/can/Kconfig | 13 +
> drivers/net/can/Makefile | 1 +
> drivers/net/can/at91_can.c | 6 +-
> drivers/net/can/flexcan.c | 136 +-
> drivers/net/can/kvaser_pciefd.c | 1912 ++++++++++++++++++++
> drivers/net/can/m_can/Kconfig | 22 +-
> drivers/net/can/m_can/Makefile | 2 +
> drivers/net/can/m_can/m_can.c | 1079 +++++------
> drivers/net/can/m_can/m_can.h | 110 ++
> drivers/net/can/m_can/m_can_platform.c | 202 +++
> drivers/net/can/m_can/tcan4x5x.c | 532 ++++++
> drivers/net/can/peak_canfd/peak_pciefd_main.c | 2 +-
> drivers/net/can/sja1000/Kconfig | 79 +-
> drivers/net/can/sja1000/Makefile | 11 +-
> drivers/net/can/sja1000/f81601.c | 212 +++
> drivers/net/can/spi/mcp251x.c | 3 +-
> drivers/net/can/ti_hecc.c | 191 +-
> drivers/net/can/usb/kvaser_usb/kvaser_usb_core.c | 3 +-
> drivers/net/can/usb/peak_usb/pcan_usb.c | 2 +-
> drivers/net/can/xilinx_can.c | 293 ++-
> include/linux/can/core.h | 3 +-
> include/linux/can/skb.h | 2 +-
> net/can/Kconfig | 11 +-
> net/can/af_can.c | 10 +-
> net/can/af_can.h | 1 +
> net/can/bcm.c | 3 +-
> net/can/gw.c | 1 +
> net/can/proc.c | 1 +
> net/can/raw.c | 3 +-
> 32 files changed, 4098 insertions(+), 800 deletions(-) create mode 100644
> Documentation/devicetree/bindings/net/can/tcan4x5x.txt
> create mode 100644 drivers/net/can/kvaser_pciefd.c create mode 100644
> drivers/net/can/m_can/m_can.h create mode 100644
> drivers/net/can/m_can/m_can_platform.c
> create mode 100644 drivers/net/can/m_can/tcan4x5x.c create mode
> 100644 drivers/net/can/sja1000/f81601.c
>
> --
> Pengutronix e.K. | Marc Kleine-Budde |
> Industrial Linux Solutions | Phone: +49-231-2826-924 |
> Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |-
> Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
>
>
>
>
--
PEAK-System Technik GmbH
Sitz der Gesellschaft Darmstadt - HRB 9183
Geschaeftsfuehrung: Alexander Gach / Uwe Wilhelm
Unsere Datenschutzerklaerung mit wichtigen Hinweisen
zur Behandlung personenbezogener Daten finden Sie unter
www.peak-system.com/Datenschutz.483.0.html
[-- Attachment #2: Type: message/rfc822, Size: 5881 bytes --]
From: "Stéphane Grosjean" <s.grosjean@peak-system.com>
To: linux-can Mailing List <linux-can@vger.kernel.org>
Cc: "Stéphane Grosjean" <s.grosjean@peak-system.com>
Subject: [PATCH] can/peak_usb: fix potential double kfree_skb()
Date: Fri, 5 Jul 2019 13:32:16 +0000
Message-ID: <20190705133217.4204-1-s.grosjean@peak-system.com>
When closing the CAN device while tx skbs are inflight, echo skb could be
released twice. By calling close_candev() before unlinking all pending
tx urbs, then the internal echo_skb[] array is fully and correctly cleared
before the USB write callback and, therefore, can_get_echo_skb() are called,
for each aborted URB.
Signed-off-by: Stephane Grosjean <s.grosjean@peak-system.com>
---
drivers/net/can/usb/peak_usb/pcan_usb_core.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/can/usb/peak_usb/pcan_usb_core.c b/drivers/net/can/usb/peak_usb/pcan_usb_core.c
index 611f9d31be5d..740ef47eab01 100644
--- a/drivers/net/can/usb/peak_usb/pcan_usb_core.c
+++ b/drivers/net/can/usb/peak_usb/pcan_usb_core.c
@@ -576,16 +576,16 @@ static int peak_usb_ndo_stop(struct net_device *netdev)
dev->state &= ~PCAN_USB_STATE_STARTED;
netif_stop_queue(netdev);
+ close_candev(netdev);
+
+ dev->can.state = CAN_STATE_STOPPED;
+
/* unlink all pending urbs and free used memory */
peak_usb_unlink_all_urbs(dev);
if (dev->adapter->dev_stop)
dev->adapter->dev_stop(dev);
- close_candev(netdev);
-
- dev->can.state = CAN_STATE_STOPPED;
-
/* can set bus off now */
if (dev->adapter->dev_set_bus) {
int err = dev->adapter->dev_set_bus(dev, 0);
--
2.20.1
--
PEAK-System Technik GmbH
Sitz der Gesellschaft Darmstadt - HRB 9183
Geschaeftsfuehrung: Alexander Gach / Uwe Wilhelm
Unsere Datenschutzerklaerung mit wichtigen Hinweisen
zur Behandlung personenbezogener Daten finden Sie unter
www.peak-system.com/Datenschutz.483.0.html
^ permalink raw reply related
* Re: pull-request: can-next 2019-07-24
From: Marc Kleine-Budde @ 2019-07-24 9:26 UTC (permalink / raw)
To: Oliver Hartkopp, netdev; +Cc: davem, kernel, linux-can
In-Reply-To: <3b3a3c9f-41ac-74a0-4238-ba01799accb6@hartkopp.net>
[-- Attachment #1.1: Type: text/plain, Size: 891 bytes --]
On 7/24/19 11:22 AM, Oliver Hartkopp wrote:
> why didn't you include the CAN FD support for the can-gw?
I wanted to have a look at the patches. But the other patches are
already reviewed.
I'll do another pull-request this week.
> [PATCH 1/2] can: gw: use struct canfd_frame as internal data structure
> https://marc.info/?l=linux-can&m=156388681922741&w=2
>
> [PATCH 2/2] can: gw: add support for CAN FD frames
> https://marc.info/?l=linux-can&m=156388682022742&w=2
>
> The patches have already been sent in January as RFC and I did extensive
> testing since then.
Good.
regards,
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: pull-request: can-next 2019-07-24
From: Marc Kleine-Budde @ 2019-07-24 9:31 UTC (permalink / raw)
To: Stéphane Grosjean, netdev@vger.kernel.org
Cc: kernel@pengutronix.de, linux-can@vger.kernel.org
In-Reply-To: <AM6PR03MB4006F834B65943E49F485FA6D6C60@AM6PR03MB4006.eurprd03.prod.outlook.com>
[-- Attachment #1.1: Type: text/plain, Size: 685 bytes --]
On 7/24/19 11:24 AM, Stéphane Grosjean wrote:
> I hope you're fine.
Yes, the summer holidays of our $CUSTOMERS gave me a bit more time for CAN.
> Did you see the attached patch I've sent earlier this month?
Yes, it will be included in "linux-can-fixes-for-5.3-20190724".
https://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can.git/log/?h=linux-can-fixes-for-5.3-20190724
regards,
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [PATCH] net: key: af_key: Fix possible null-pointer dereferences in pfkey_send_policy_notify()
From: Jia-Ju Bai @ 2019-07-24 9:35 UTC (permalink / raw)
To: steffen.klassert, herbert, davem; +Cc: netdev, linux-kernel, Jia-Ju Bai
In pfkey_send_policy_notify(), there is an if statement on line 3081 to
check whether xp is NULL:
if (xp && xp->type != XFRM_POLICY_TYPE_MAIN)
When xp is NULL, it is used by key_notify_policy() on line 3090:
key_notify_policy(xp, ...)
pfkey_xfrm_policy2msg_prep(xp) -- line 2211
pfkey_xfrm_policy2msg_size(xp) -- line 2046
for (i=0; i<xp->xfrm_nr; i++) -- line 2026
t = xp->xfrm_vec + i; -- line 2027
key_notify_policy(xp, ...)
xp_net(xp) -- line 2231
return read_pnet(&xp->xp_net); -- line 534
Thus, possible null-pointer dereferences may occur.
To fix these bugs, xp is checked before calling key_notify_policy().
These bugs are found by a static analysis tool STCheck written by us.
Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
---
net/key/af_key.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/key/af_key.c b/net/key/af_key.c
index b67ed3a8486c..ced54144d5fd 100644
--- a/net/key/af_key.c
+++ b/net/key/af_key.c
@@ -3087,6 +3087,8 @@ static int pfkey_send_policy_notify(struct xfrm_policy *xp, int dir, const struc
case XFRM_MSG_DELPOLICY:
case XFRM_MSG_NEWPOLICY:
case XFRM_MSG_UPDPOLICY:
+ if (!xp)
+ break;
return key_notify_policy(xp, dir, c);
case XFRM_MSG_FLUSHPOLICY:
if (c->data.type != XFRM_POLICY_TYPE_MAIN)
--
2.17.0
^ permalink raw reply related
* [PATCH] net: ceph: Fix a possible null-pointer dereference in ceph_crypto_key_destroy()
From: Jia-Ju Bai @ 2019-07-24 9:43 UTC (permalink / raw)
To: idryomov, jlayton, sage, davem
Cc: ceph-devel, netdev, linux-kernel, Jia-Ju Bai
In set_secret(), key->tfm is assigned to NULL on line 55, and then
ceph_crypto_key_destroy(key) is executed.
ceph_crypto_key_destroy(key)
crypto_free_sync_skcipher(key->tfm)
crypto_skcipher_tfm(tfm)
return &tfm->base;
Thus, a possible null-pointer dereference may occur.
To fix this bug, key->tfm is checked before calling
crypto_free_sync_skcipher().
This bug is found by a static analysis tool STCheck written by us.
Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
---
net/ceph/crypto.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/ceph/crypto.c b/net/ceph/crypto.c
index 5d6724cee38f..ac28463bcfd8 100644
--- a/net/ceph/crypto.c
+++ b/net/ceph/crypto.c
@@ -136,7 +136,8 @@ void ceph_crypto_key_destroy(struct ceph_crypto_key *key)
if (key) {
kfree(key->key);
key->key = NULL;
- crypto_free_sync_skcipher(key->tfm);
+ if (key->tfm)
+ crypto_free_sync_skcipher(key->tfm);
key->tfm = NULL;
}
}
--
2.17.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox