* [PATCH 2/2] encx24j600: Fix some checkstyle warnings
From: jeroen.de_wachter.ext @ 2016-12-12 13:29 UTC (permalink / raw)
To: David Miller, Jon Ringle; +Cc: Andrew Morton, netdev, Jeroen De Wachter
In-Reply-To: <1481549349-8199-1-git-send-email-jeroen.de_wachter.ext@nokia.com>
From: Jeroen De Wachter <jeroen.de_wachter.ext@nokia.com>
Signed-off-by: Jeroen De Wachter <jeroen.de_wachter.ext@nokia.com>
---
drivers/net/ethernet/microchip/encx24j600-regmap.c | 17 +++++++++++------
drivers/net/ethernet/microchip/encx24j600.c | 16 ++++++++++++++--
2 files changed, 25 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/microchip/encx24j600-regmap.c b/drivers/net/ethernet/microchip/encx24j600-regmap.c
index f3bb905..44bb04d 100644
--- a/drivers/net/ethernet/microchip/encx24j600-regmap.c
+++ b/drivers/net/ethernet/microchip/encx24j600-regmap.c
@@ -26,11 +26,11 @@ static inline bool is_bits_set(int value, int mask)
}
static int encx24j600_switch_bank(struct encx24j600_context *ctx,
- int bank)
+ int bank)
{
int ret = 0;
-
int bank_opcode = BANK_SELECT(bank);
+
ret = spi_write(ctx->spi, &bank_opcode, 1);
if (ret == 0)
ctx->bank = bank;
@@ -39,7 +39,7 @@ static int encx24j600_switch_bank(struct encx24j600_context *ctx,
}
static int encx24j600_cmdn(struct encx24j600_context *ctx, u8 opcode,
- const void *buf, size_t len)
+ const void *buf, size_t len)
{
struct spi_message m;
struct spi_transfer t[2] = { { .tx_buf = &opcode, .len = 1, },
@@ -54,12 +54,14 @@ static int encx24j600_cmdn(struct encx24j600_context *ctx, u8 opcode,
static void regmap_lock_mutex(void *context)
{
struct encx24j600_context *ctx = context;
+
mutex_lock(&ctx->mutex);
}
static void regmap_unlock_mutex(void *context)
{
struct encx24j600_context *ctx = context;
+
mutex_unlock(&ctx->mutex);
}
@@ -128,6 +130,7 @@ static int regmap_encx24j600_sfr_update(struct encx24j600_context *ctx,
if (reg < 0x80) {
int ret = 0;
+
cmd = banked_code | banked_reg;
if ((banked_reg < 0x16) && (ctx->bank != bank))
ret = encx24j600_switch_bank(ctx, bank);
@@ -174,6 +177,7 @@ static int regmap_encx24j600_sfr_write(void *context, u8 reg, u8 *val,
size_t len)
{
struct encx24j600_context *ctx = context;
+
return regmap_encx24j600_sfr_update(ctx, reg, val, len, WCRU, WCRCODE);
}
@@ -228,9 +232,9 @@ int regmap_encx24j600_spi_write(void *context, u8 reg, const u8 *data,
if (reg < 0xc0)
return encx24j600_cmdn(ctx, reg, data, count);
- else
- /* SPI 1-byte command. Ignore data */
- return spi_write(ctx->spi, ®, 1);
+
+ /* SPI 1-byte command. Ignore data */
+ return spi_write(ctx->spi, ®, 1);
}
EXPORT_SYMBOL_GPL(regmap_encx24j600_spi_write);
@@ -495,6 +499,7 @@ static bool encx24j600_phymap_volatile(struct device *dev, unsigned int reg)
.writeable_reg = encx24j600_phymap_writeable,
.volatile_reg = encx24j600_phymap_volatile,
};
+
static struct regmap_bus phymap_encx24j600 = {
.reg_write = regmap_encx24j600_phy_reg_write,
.reg_read = regmap_encx24j600_phy_reg_read,
diff --git a/drivers/net/ethernet/microchip/encx24j600.c b/drivers/net/ethernet/microchip/encx24j600.c
index 5251aa3..fbce616 100644
--- a/drivers/net/ethernet/microchip/encx24j600.c
+++ b/drivers/net/ethernet/microchip/encx24j600.c
@@ -30,7 +30,7 @@
#define DEFAULT_MSG_ENABLE (NETIF_MSG_DRV | NETIF_MSG_PROBE | NETIF_MSG_LINK)
static int debug = -1;
-module_param(debug, int, 0);
+module_param(debug, int, 0000);
MODULE_PARM_DESC(debug, "Debug level (0=none,...,16=all)");
/* SRAM memory layout:
@@ -105,6 +105,7 @@ static u16 encx24j600_read_reg(struct encx24j600_priv *priv, u8 reg)
struct net_device *dev = priv->ndev;
unsigned int val = 0;
int ret = regmap_read(priv->ctx.regmap, reg, &val);
+
if (unlikely(ret))
netif_err(priv, drv, dev, "%s: error %d reading reg %02x\n",
__func__, ret, reg);
@@ -115,6 +116,7 @@ static void encx24j600_write_reg(struct encx24j600_priv *priv, u8 reg, u16 val)
{
struct net_device *dev = priv->ndev;
int ret = regmap_write(priv->ctx.regmap, reg, val);
+
if (unlikely(ret))
netif_err(priv, drv, dev, "%s: error %d writing reg %02x=%04x\n",
__func__, ret, reg, val);
@@ -125,6 +127,7 @@ static void encx24j600_update_reg(struct encx24j600_priv *priv, u8 reg,
{
struct net_device *dev = priv->ndev;
int ret = regmap_update_bits(priv->ctx.regmap, reg, mask, val);
+
if (unlikely(ret))
netif_err(priv, drv, dev, "%s: error %d updating reg %02x=%04x~%04x\n",
__func__, ret, reg, val, mask);
@@ -135,6 +138,7 @@ static u16 encx24j600_read_phy(struct encx24j600_priv *priv, u8 reg)
struct net_device *dev = priv->ndev;
unsigned int val = 0;
int ret = regmap_read(priv->ctx.phymap, reg, &val);
+
if (unlikely(ret))
netif_err(priv, drv, dev, "%s: error %d reading %02x\n",
__func__, ret, reg);
@@ -145,6 +149,7 @@ static void encx24j600_write_phy(struct encx24j600_priv *priv, u8 reg, u16 val)
{
struct net_device *dev = priv->ndev;
int ret = regmap_write(priv->ctx.phymap, reg, val);
+
if (unlikely(ret))
netif_err(priv, drv, dev, "%s: error %d writing reg %02x=%04x\n",
__func__, ret, reg, val);
@@ -164,6 +169,7 @@ static void encx24j600_cmd(struct encx24j600_priv *priv, u8 cmd)
{
struct net_device *dev = priv->ndev;
int ret = regmap_write(priv->ctx.regmap, cmd, 0);
+
if (unlikely(ret))
netif_err(priv, drv, dev, "%s: error %d with cmd %02x\n",
__func__, ret, cmd);
@@ -173,6 +179,7 @@ static int encx24j600_raw_read(struct encx24j600_priv *priv, u8 reg, u8 *data,
size_t count)
{
int ret;
+
mutex_lock(&priv->ctx.mutex);
ret = regmap_encx24j600_spi_read(&priv->ctx, reg, data, count);
mutex_unlock(&priv->ctx.mutex);
@@ -184,6 +191,7 @@ static int encx24j600_raw_write(struct encx24j600_priv *priv, u8 reg,
const u8 *data, size_t count)
{
int ret;
+
mutex_lock(&priv->ctx.mutex);
ret = regmap_encx24j600_spi_write(&priv->ctx, reg, data, count);
mutex_unlock(&priv->ctx.mutex);
@@ -194,6 +202,7 @@ static int encx24j600_raw_write(struct encx24j600_priv *priv, u8 reg,
static void encx24j600_update_phcon1(struct encx24j600_priv *priv)
{
u16 phcon1 = encx24j600_read_phy(priv, PHCON1);
+
if (priv->autoneg == AUTONEG_ENABLE) {
phcon1 |= ANEN | RENEG;
} else {
@@ -328,6 +337,7 @@ static int encx24j600_receive_packet(struct encx24j600_priv *priv,
{
struct net_device *dev = priv->ndev;
struct sk_buff *skb = netdev_alloc_skb(dev, rsv->len + NET_IP_ALIGN);
+
if (!skb) {
pr_err_ratelimited("RX: OOM: packet dropped\n");
dev->stats.rx_dropped++;
@@ -828,6 +838,7 @@ static void encx24j600_set_multicast_list(struct net_device *dev)
static void encx24j600_hw_tx(struct encx24j600_priv *priv)
{
struct net_device *dev = priv->ndev;
+
netif_info(priv, tx_queued, dev, "TX Packet Len:%d\n",
priv->tx_skb->len);
@@ -895,7 +906,6 @@ static void encx24j600_tx_timeout(struct net_device *dev)
dev->stats.tx_errors++;
netif_wake_queue(dev);
- return;
}
static int encx24j600_get_regs_len(struct net_device *dev)
@@ -958,12 +968,14 @@ static int encx24j600_set_settings(struct net_device *dev,
static u32 encx24j600_get_msglevel(struct net_device *dev)
{
struct encx24j600_priv *priv = netdev_priv(dev);
+
return priv->msg_enable;
}
static void encx24j600_set_msglevel(struct net_device *dev, u32 val)
{
struct encx24j600_priv *priv = netdev_priv(dev);
+
priv->msg_enable = val;
}
--
1.8.3.1
^ permalink raw reply related
* [PATCH net-next 2/3] net:dsa:mv88e6xxx: add helper functions to operate on hashtable
From: Volodymyr Bendiuga @ 2016-12-12 13:40 UTC (permalink / raw)
To: andrew, vivien.didelot, f.fainelli, netdev, volodymyr.bendiuga
Cc: Volodymyr Bendiuga
This implementation is similar to rocker driver: drivers/net/ethernet/rocker_ofdpa.c
mv88e6xxx_pvec_tbl_find - iterates through entries in the hashtable
and looks for a match.
mv88e6xxx_pvec_tbl_get - returns en entry if it is found in the
hashtable
mv88e6xxx_pvec_tbl_update - updates the hashtable: inserts new entry,
deletes/modifies existing one.
Signed-off-by: Volodymyr Bendiuga <volodymyr.bendiuga@gmail.com>
---
drivers/net/dsa/mv88e6xxx/chip.c | 61 ++++++++++++++++++++++++++++++++++++++++
1 file changed, 61 insertions(+)
diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index 173ea97..6597f3f 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -2008,6 +2008,67 @@ static int _mv88e6xxx_atu_load(struct mv88e6xxx_chip *chip,
return _mv88e6xxx_atu_cmd(chip, entry->fid, GLOBAL_ATU_OP_LOAD_DB);
}
+static struct pvec_tbl_entry *
+mv88e6xxx_pvec_tbl_find(struct mv88e6xxx_chip *chip, struct pvec_tbl_entry *match)
+{
+ struct pvec_tbl_entry *found;
+
+ hash_for_each_possible(chip->pvec_tbl, found, entry, match->key_crc32)
+ if (memcmp(&found->key, &match->key, sizeof(found->key)) == 0)
+ return found;
+ return NULL;
+}
+
+static int mv88e6xxx_pvec_tbl_update(struct mv88e6xxx_chip *chip, u16 fid,
+ const unsigned char *addr, u16 pvec)
+{
+ struct pvec_tbl_entry *obj;
+ struct pvec_tbl_entry *found;
+ bool remove = pvec ? false : true;
+
+ obj = kzalloc(sizeof(*obj), GFP_KERNEL);
+ if (!obj)
+ return -ENOMEM;
+
+ obj->pvec = pvec;
+ ether_addr_copy(obj->key.addr, addr);
+ obj->key.fid = fid;
+ obj->key_crc32 = crc32(~0, &obj->key, sizeof(obj->key));
+
+ found = mv88e6xxx_pvec_tbl_find(chip, obj);
+
+ if (remove && found) {
+ kfree(obj);
+ hash_del(&found->entry);
+ } else if (!remove && !found) {
+ hash_add(chip->pvec_tbl, &obj->entry, obj->key_crc32);
+ } else if (!remove && found) {
+ kfree(obj);
+ found->pvec = pvec; /* update */
+ } else {
+ kfree(obj);
+ }
+
+ return 0;
+}
+
+static u16 mv88e6xxx_pvec_tbl_get(struct mv88e6xxx_chip *chip,
+ u16 fid, const unsigned char *addr)
+{
+ struct pvec_tbl_entry obj;
+ struct pvec_tbl_entry *found;
+
+ ether_addr_copy(obj.key.addr, addr);
+ obj.key.fid = fid;
+ obj.key_crc32 = crc32(~0, &obj.key, sizeof(obj.key));
+
+ found = mv88e6xxx_pvec_tbl_find(chip, &obj);
+ if (found)
+ return found->pvec;
+
+ return 0;
+}
+
static int _mv88e6xxx_atu_getnext(struct mv88e6xxx_chip *chip, u16 fid,
struct mv88e6xxx_atu_entry *entry);
--
2.7.4
^ permalink raw reply related
* [PATCH 1/2] encx24j600: bugfix - always move ERXTAIL to next packet in encx24j600_rx_packets
From: jeroen.de_wachter.ext @ 2016-12-12 13:29 UTC (permalink / raw)
To: David Miller, Jon Ringle; +Cc: Andrew Morton, netdev, Jeroen De Wachter
From: Jeroen De Wachter <jeroen.de_wachter.ext@nokia.com>
Before, encx24j600_rx_packets did not update encx24j600_priv's next_packet
member when an error occurred during packet handling (either because the
packet's RSV header indicates an error or because the encx24j600_receive_packet
method can't allocate an sk_buff).
If the next_packet member is not updated, the ERXTAIL register will be set to
the same value it had before, which means the bad packet remains in the
component's memory and its RSV header will be read again when a new packet
arrives. If the RSV header indicates a bad packet or if sk_buff allocation
continues to fail, new packets will be stored in the component's memory until
that memory is full, after which packets will be dropped.
The SETPKTDEC command is always executed though, so the encx24j600 hardware has
an incorrect count of the packets in its memory.
To prevent this, the next_packet member should always be updated, allowing the
packet to be skipped (either because it's bad, as indicated in its RSV header,
or because allocating an sk_buff failed). In the allocation failure case, this
does mean dropping a valid packet, but dropping the oldest packet to keep as
much memory as possible available for new packets seems preferable to keeping
old (but valid) packets around while dropping new ones.
Signed-off-by: Jeroen De Wachter <jeroen.de_wachter.ext@nokia.com>
---
drivers/net/ethernet/microchip/encx24j600.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/microchip/encx24j600.c b/drivers/net/ethernet/microchip/encx24j600.c
index b14f030..5251aa3 100644
--- a/drivers/net/ethernet/microchip/encx24j600.c
+++ b/drivers/net/ethernet/microchip/encx24j600.c
@@ -346,7 +346,6 @@ static int encx24j600_receive_packet(struct encx24j600_priv *priv,
/* Maintain stats */
dev->stats.rx_packets++;
dev->stats.rx_bytes += rsv->len;
- priv->next_packet = rsv->next_packet;
netif_rx(skb);
@@ -383,6 +382,8 @@ static void encx24j600_rx_packets(struct encx24j600_priv *priv, u8 packet_count)
encx24j600_receive_packet(priv, &rsv);
}
+ priv->next_packet = rsv.next_packet;
+
newrxtail = priv->next_packet - 2;
if (newrxtail == ENC_RX_BUF_START)
newrxtail = SRAM_SIZE - 2;
--
1.8.3.1
^ permalink raw reply related
* [PATCH net-next 1/3] net:dsa:mv88e6xxx: use hashtable to store multicast entries
From: Volodymyr Bendiuga @ 2016-12-12 13:39 UTC (permalink / raw)
To: andrew, vivien.didelot, f.fainelli, netdev, volodymyr.bendiuga
Cc: Volodymyr Bendiuga
Hashtable will make it extremely faster when inserting fdb entries
into the forwarding database.
Signed-off-by: Volodymyr Bendiuga <volodymyr.bendiuga@gmail.com>
---
drivers/net/dsa/mv88e6xxx/mv88e6xxx.h | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/drivers/net/dsa/mv88e6xxx/mv88e6xxx.h b/drivers/net/dsa/mv88e6xxx/mv88e6xxx.h
index 431e954..407e6db 100644
--- a/drivers/net/dsa/mv88e6xxx/mv88e6xxx.h
+++ b/drivers/net/dsa/mv88e6xxx/mv88e6xxx.h
@@ -15,6 +15,8 @@
#include <linux/if_vlan.h>
#include <linux/irq.h>
#include <linux/gpio/consumer.h>
+#include <linux/crc32.h>
+#include <linux/hashtable.h>
#ifndef UINT64_MAX
#define UINT64_MAX (u64)(~((u64)0))
@@ -672,6 +674,16 @@ struct mv88e6xxx_info {
const struct mv88e6xxx_ops *ops;
};
+struct pvec_tbl_entry {
+ struct hlist_node entry;
+ u32 key_crc32; /* key */
+ u16 pvec;
+ struct pvec_tbl_key {
+ u8 addr[ETH_ALEN];
+ u16 fid;
+ } key;
+};
+
struct mv88e6xxx_atu_entry {
u16 fid;
u8 state;
@@ -736,6 +748,9 @@ struct mv88e6xxx_chip {
struct mv88e6xxx_priv_port ports[DSA_MAX_PORTS];
+ /* This table hold a port vector for each multicast address */
+ DECLARE_HASHTABLE(pvec_tbl, 12);
+
/* A switch may have a GPIO line tied to its reset pin. Parse
* this from the device tree, and use it before performing
* switch soft reset.
--
2.7.4
^ permalink raw reply related
* Re: Soft lockup in tc_classify
From: Daniel Borkmann @ 2016-12-12 13:28 UTC (permalink / raw)
To: Shahar Klein, netdev
Cc: Roi Dayan, David Miller, Cong Wang, Jiri Pirko, John Fastabend,
Or Gerlitz, Hadar Hen Zion
In-Reply-To: <7394f89e-e8a5-5fb2-ee04-63bf1c4ef6e7@mellanox.com>
Hi Shahar,
On 12/12/2016 10:43 AM, Shahar Klein wrote:
> Hi All,
>
> sorry for the spam, the first time was sent with html part and was rejected.
>
> We observed an issue where a classifier instance next member is pointing back to itself, causing a CPU soft lockup.
> We found it by running traffic on many udp connections and then adding a new flower rule using tc.
>
> We added a quick workaround to verify it:
>
> In tc_classify:
>
> for (; tp; tp = rcu_dereference_bh(tp->next)) {
> int err;
> + if (tp == tp->next)
> + RCU_INIT_POINTER(tp->next, NULL);
>
>
> We also had a print here showing tp->next is pointing to tp. With this workaround we are not hitting the issue anymore.
> We are not sure we fully understand the mechanism here - with the rtnl and rcu locks.
> We'll appreciate your help solving this issue.
Note that there's still the RCU fix missing for the deletion race that
Cong will still send out, but you say that the only thing you do is to
add a single rule, but no other operation in involved during that test?
Do you have a script and kernel .config for reproducing this?
Thanks,
Daniel
^ permalink raw reply
* Re: stmmac DT property snps,axi_all
From: Giuseppe CAVALLARO @ 2016-12-12 13:16 UTC (permalink / raw)
To: Alexandre Torgue, Niklas Cassel; +Cc: netdev
In-Reply-To: <6c79e89f-52a2-3ac9-c976-6aa006e5ac38@st.com>
Hello
On 12/9/2016 5:06 PM, Alexandre Torgue wrote:
> Hi Niklas
>
> On 12/09/2016 10:53 AM, Niklas Cassel wrote:
>> On 12/09/2016 10:20 AM, Niklas Cassel wrote:
>>> On 12/08/2016 02:36 PM, Alexandre Torgue wrote:
>>>> Hi Niklas,
>>>>
>>>> On 12/05/2016 05:18 PM, Niklas Cassel wrote:
>>>>> Hello Giuseppe
>>>>>
>>>>>
>>>>> I'm trying to figure out what snps,axi_all is supposed to represent.
>>>>>
>>>>> It appears that the value is saved, but never used in the code.
>>>>>
>>>>> Looking at the register specification, I'm guessing that it represents
>>>>> Address-Aligned Beats, but there is already the property snps,aal
>>>>> for that.
>>>> IMO, it is not useful. Indeed AXI_AAL is a read only bit (in AXI bus
>>>> mode register) and reflects the aal bit in DMA bus register.
>>>> As you know we use "snps,aal" to set aal bit in DMA bus register.
>>>> So "snps,axi_all" entry seems useless. Let's see with Peppe.
>>> Ok, I see. GMAC and GMAC4 is different here.
>>>
>>> For GMAC4 AAL only exists in DMA_SYS_BUS_MODE.
>>> It's not reflected anywhere else.
>>>
>>> The code is correct in the driver.
>>>
>>> If snps,axi_all is just created for a read-only register,
>>> and it is currently never used in the code,
>>> while we have snps,aal, which is correct and works,
>>> I guess it should be ok to remove snps,axi_all.
>>>
>>> I can cook up a patch.
>>>
>>
>> Here we go :)
>>
>> I will send it as a real patch once net-next reopens.
>
> Thanks ;). Just check with Peppe next week (as he added in the past this
> property).
Yes, we can conclude that the axi_all can be safely removed from DT, in
fact on all GMACs the AaL will be set via DMA_BUS_MODE register.
peppe
^ permalink raw reply
* Re: [PATCH net] net: dsa: mv88e6xxx: Fix opps when adding vlan bridge
From: Vivien Didelot @ 2016-12-12 13:15 UTC (permalink / raw)
To: Andrew Lunn, David Miller; +Cc: netdev, Andrew Lunn
In-Reply-To: <1481486839-19502-1-git-send-email-andrew@lunn.ch>
Hi Andrew,
Andrew Lunn <andrew@lunn.ch> writes:
> A port is not necessarily assigned to a netdev. And a port does not
> need to be a member of a bridge. So when iterating over all ports,
> check before using the netdev and bridge_dev for a port. Otherwise we
> dereference a NULL pointer.
>
> Fixes: da9c359e19f0 ("net: dsa: mv88e6xxx: check hardware VLAN in use")
> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Reviewed-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Thanks,
Vivien
^ permalink raw reply
* Re: [PATCH 1/1] Fixed to BUG_ON to WARN_ON def
From: Ozgur Karatas @ 2016-12-12 13:04 UTC (permalink / raw)
To: Leon Romanovsky; +Cc: yishaih@mellanox.com, netdev, linux-kernel
In-Reply-To: <20161212123937.GA6503@mtr-leonro.local>
Dear Romanovsky;
I'm trying to learn english and I apologize for my mistake words and phrases. So, I think the code when call to "sg_set_buf" and next time set memory and buffer. For example, isn't to call "WARN_ON" function, get a error to implicit declaration, right?
Because, you will use to "BUG_ON" get a error implicit declaration of functions.
sg_set_buf(mem, buf, PAGE_SIZE << order);
WARN_ON(mem->offset);
Thanks for information and learn to me.
Regards,
Ozgur Karatas
12.12.2016, 14:39, "Leon Romanovsky" <leon@kernel.org>:
> On Mon, Dec 12, 2016 at 12:58:59PM +0200, Ozgur Karatas wrote:
>> Hello all,
>> I think should be use to "WARN_ON" and checkpatch script give to error, I fixed and I think should don't use "BUG_ON".
>> Regards,
>>
>> Signed-off-by: Ozgur Karatas <okaratas@member.fsf.org>
>
> NAK, Leon Romanovsky <leonro@mellanox.com>
>
> If we put aside commit message issue, which was pointed to you by Stefan, your
> proposed change is incorrect. By chnaging BUG_ONs to be WARN_ONs, you
> will left the driver in improper state.
>
> Thanks
>
>> ---
>> drivers/net/ethernet/mellanox/mlx4/icm.c | 4 ++--
>>
>> diff --git a/drivers/net/ethernet/mellanox/mlx4/icm.c b/drivers/net/ethernet/mellanox/mlx4/icm.c
>> index 2a9dd46..3fde535 100644
>> --- a/drivers/net/ethernet/mellanox/mlx4/icm.c
>> +++ b/drivers/net/ethernet/mellanox/mlx4/icm.c
>> @@ -119,7 +119,7 @@ static int mlx4_alloc_icm_coherent(struct device *dev, struct scatterlist *mem,
>> return -ENOMEM;
>>
>> sg_set_buf(mem, buf, PAGE_SIZE << order);
>> - BUG_ON(mem->offset);
>> + WARN_ON(mem->offset);
>> sg_dma_len(mem) = PAGE_SIZE << order;
>> return 0;
>> }
>> @@ -133,7 +133,7 @@ struct mlx4_icm *mlx4_alloc_icm(struct mlx4_dev *dev, int npages,
>> int ret;
>>
>> /* We use sg_set_buf for coherent allocs, which assumes low memory */
>> - BUG_ON(coherent && (gfp_mask & __GFP_HIGHMEM));
>> + WARN_ON(coherent && (gfp_mask & __GFP_HIGHMEM));
>>
>> icm = kmalloc_node(sizeof(*icm),
>> gfp_mask & ~(__GFP_HIGHMEM | __GFP_NOWARN),
>> --
>> 2.1.4
^ permalink raw reply
* Re: [PATCH net] net: dsa: mv88e6xxx: Fix opps when adding vlan bridge
From: Andrew Lunn @ 2016-12-12 13:04 UTC (permalink / raw)
To: Vivien Didelot; +Cc: David Miller, netdev
In-Reply-To: <87a8c2w55e.fsf@weeman.i-did-not-set--mail-host-address--so-tickle-me>
On Sun, Dec 11, 2016 at 04:02:37PM -0500, Vivien Didelot wrote:
> Hi Andrew,
>
> Andrew Lunn <andrew@lunn.ch> writes:
>
> > @@ -1804,6 +1807,9 @@ static int mv88e6xxx_port_check_hw_vlan(struct dsa_switch *ds, int port,
> > chip->ports[port].bridge_dev)
> > break; /* same bridge, check next VLAN */
> >
> > + if (!chip->ports[i].bridge_dev)
> > + continue;
> > +
>
> The above truncated test:
>
> if (chip->ports[i].bridge_dev ==
> chip->ports[port].bridge_dev)
> break; /* same bridge, check next VLAN */
>
> should handle the case where bridge_dev is NULL, but if you want to
> explicitly test it, I'd move it before this statement.
>
> > netdev_warn(ds->ports[port].netdev,
> > "hardware VLAN %d already used by %s\n",
> > vlan.vid,
Hi Vivien
I don't think you comment is correct. Here is the loop, with my two
additions.
for (i = 0; i < mv88e6xxx_num_ports(chip); ++i) {
if (dsa_is_dsa_port(ds, i) || dsa_is_cpu_port(ds, i))
continue;
if (!ds->ports[port].netdev)
continue;
if (vlan.data[i] ==
GLOBAL_VTU_DATA_MEMBER_TAG_NON_MEMBER)
continue;
if (chip->ports[i].bridge_dev ==
chip->ports[port].bridge_dev)
break; /* same bridge, check next VLAN */
if (!chip->ports[i].bridge_dev)
continue;
netdev_warn(ds->ports[port].netdev,
"hardware VLAN %d already used by %s\n",
vlan.vid,
netdev_name(chip->ports[i].bridge_dev));
err = -EOPNOTSUPP;
goto unlock;
}
The opps was occurring in netdev_name(). I did not check which
one. The obvious one, or the netdev_warn(netdev,... one.
> The above truncated test:
>
> if (chip->ports[i].bridge_dev ==
> chip->ports[port].bridge_dev)
> break; /* same bridge, check next VLAN */
>
> should handle the case where bridge_dev is NULL, but if you want to
> explicitly test it, I'd move it before this statement.
This will not stop chip->ports[i].bridge_dev == NULL from reaching the
netdev_warn().
Andrew
^ permalink raw reply
* Re: [PATCH 1/1] Fixed to BUG_ON to WARN_ON def
From: Leon Romanovsky @ 2016-12-12 12:39 UTC (permalink / raw)
To: Ozgur Karatas; +Cc: yishaih, netdev, linux-kernel
In-Reply-To: <811031481540339@web1j.yandex.ru>
[-- Attachment #1: Type: text/plain, Size: 1471 bytes --]
On Mon, Dec 12, 2016 at 12:58:59PM +0200, Ozgur Karatas wrote:
> Hello all,
> I think should be use to "WARN_ON" and checkpatch script give to error, I fixed and I think should don't use "BUG_ON".
> Regards,
>
> Signed-off-by: Ozgur Karatas <okaratas@member.fsf.org>
NAK, Leon Romanovsky <leonro@mellanox.com>
If we put aside commit message issue, which was pointed to you by Stefan, your
proposed change is incorrect. By chnaging BUG_ONs to be WARN_ONs, you
will left the driver in improper state.
Thanks
> ---
> drivers/net/ethernet/mellanox/mlx4/icm.c | 4 ++--
>
> diff --git a/drivers/net/ethernet/mellanox/mlx4/icm.c b/drivers/net/ethernet/mellanox/mlx4/icm.c
> index 2a9dd46..3fde535 100644
> --- a/drivers/net/ethernet/mellanox/mlx4/icm.c
> +++ b/drivers/net/ethernet/mellanox/mlx4/icm.c
> @@ -119,7 +119,7 @@ static int mlx4_alloc_icm_coherent(struct device *dev, struct scatterlist *mem,
> return -ENOMEM;
>
> sg_set_buf(mem, buf, PAGE_SIZE << order);
> - BUG_ON(mem->offset);
> + WARN_ON(mem->offset);
> sg_dma_len(mem) = PAGE_SIZE << order;
> return 0;
> }
> @@ -133,7 +133,7 @@ struct mlx4_icm *mlx4_alloc_icm(struct mlx4_dev *dev, int npages,
> int ret;
>
> /* We use sg_set_buf for coherent allocs, which assumes low memory */
> - BUG_ON(coherent && (gfp_mask & __GFP_HIGHMEM));
> + WARN_ON(coherent && (gfp_mask & __GFP_HIGHMEM));
>
> icm = kmalloc_node(sizeof(*icm),
> gfp_mask & ~(__GFP_HIGHMEM | __GFP_NOWARN),
> --
> 2.1.4
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [PATCH v4 4/4] vsock: cancel packets when failing to connect
From: Peng Tao @ 2016-12-12 12:21 UTC (permalink / raw)
To: netdev; +Cc: David Miller, Jorgen Hansen, kvm, virtualization, Stefan Hajnoczi
In-Reply-To: <1481545269-18104-4-git-send-email-bergwolf@gmail.com>
Otherwise we'll leave the packets queued until releasing vsock device.
E.g., if guest is slow to start up, resulting ETIMEDOUT on connect, guest
will get the connect requests from failed host sockets.
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Jorgen Hansen <jhansen@vmware.com>
Signed-off-by: Peng Tao <bergwolf@gmail.com>
---
net/vmw_vsock/af_vsock.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/net/vmw_vsock/af_vsock.c b/net/vmw_vsock/af_vsock.c
index 8a398b3..c73b03a 100644
--- a/net/vmw_vsock/af_vsock.c
+++ b/net/vmw_vsock/af_vsock.c
@@ -1101,10 +1101,19 @@ static const struct proto_ops vsock_dgram_ops = {
.sendpage = sock_no_sendpage,
};
+static int vsock_transport_cancel_pkt(struct vsock_sock *vsk)
+{
+ if (!transport->cancel_pkt)
+ return -EOPNOTSUPP;
+
+ return transport->cancel_pkt(vsk);
+}
+
static void vsock_connect_timeout(struct work_struct *work)
{
struct sock *sk;
struct vsock_sock *vsk;
+ int cancel = 0;
vsk = container_of(work, struct vsock_sock, dwork.work);
sk = sk_vsock(vsk);
@@ -1115,8 +1124,11 @@ static void vsock_connect_timeout(struct work_struct *work)
sk->sk_state = SS_UNCONNECTED;
sk->sk_err = ETIMEDOUT;
sk->sk_error_report(sk);
+ cancel = 1;
}
release_sock(sk);
+ if (cancel)
+ vsock_transport_cancel_pkt(vsk);
sock_put(sk);
}
@@ -1223,11 +1235,13 @@ static int vsock_stream_connect(struct socket *sock, struct sockaddr *addr,
err = sock_intr_errno(timeout);
sk->sk_state = SS_UNCONNECTED;
sock->state = SS_UNCONNECTED;
+ vsock_transport_cancel_pkt(vsk);
goto out_wait;
} else if (timeout == 0) {
err = -ETIMEDOUT;
sk->sk_state = SS_UNCONNECTED;
sock->state = SS_UNCONNECTED;
+ vsock_transport_cancel_pkt(vsk);
goto out_wait;
}
--
2.7.4
^ permalink raw reply related
* [PATCH v4 3/4] vsock: add pkt cancel capability
From: Peng Tao @ 2016-12-12 12:21 UTC (permalink / raw)
To: netdev; +Cc: David Miller, Jorgen Hansen, kvm, virtualization, Stefan Hajnoczi
In-Reply-To: <1481545269-18104-3-git-send-email-bergwolf@gmail.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Peng Tao <bergwolf@gmail.com>
---
net/vmw_vsock/virtio_transport.c | 42 ++++++++++++++++++++++++++++++++++++++++
1 file changed, 42 insertions(+)
diff --git a/net/vmw_vsock/virtio_transport.c b/net/vmw_vsock/virtio_transport.c
index 936d7ee..b7b78ce 100644
--- a/net/vmw_vsock/virtio_transport.c
+++ b/net/vmw_vsock/virtio_transport.c
@@ -170,6 +170,47 @@ virtio_transport_send_pkt(struct virtio_vsock_pkt *pkt)
return len;
}
+static int
+virtio_transport_cancel_pkt(struct vsock_sock *vsk)
+{
+ struct virtio_vsock *vsock;
+ struct virtio_vsock_pkt *pkt, *n;
+ int cnt = 0;
+ LIST_HEAD(freeme);
+
+ vsock = virtio_vsock_get();
+ if (!vsock) {
+ return -ENODEV;
+ }
+
+ spin_lock_bh(&vsock->send_pkt_list_lock);
+ list_for_each_entry_safe(pkt, n, &vsock->send_pkt_list, list) {
+ if (pkt->cancel_token != vsk)
+ continue;
+ list_move(&pkt->list, &freeme);
+ }
+ spin_unlock_bh(&vsock->send_pkt_list_lock);
+
+ list_for_each_entry_safe(pkt, n, &freeme, list) {
+ if (pkt->reply)
+ cnt++;
+ list_del(&pkt->list);
+ virtio_transport_free_pkt(pkt);
+ }
+
+ if (cnt) {
+ struct virtqueue *rx_vq = vsock->vqs[VSOCK_VQ_RX];
+ int new_cnt;
+
+ new_cnt = atomic_sub_return(cnt, &vsock->queued_replies);
+ if (new_cnt + cnt >= virtqueue_get_vring_size(rx_vq) &&
+ new_cnt < virtqueue_get_vring_size(rx_vq))
+ queue_work(virtio_vsock_workqueue, &vsock->rx_work);
+ }
+
+ return 0;
+}
+
static void virtio_vsock_rx_fill(struct virtio_vsock *vsock)
{
int buf_len = VIRTIO_VSOCK_DEFAULT_RX_BUF_SIZE;
@@ -419,6 +460,7 @@ static struct virtio_transport virtio_transport = {
.release = virtio_transport_release,
.connect = virtio_transport_connect,
.shutdown = virtio_transport_shutdown,
+ .cancel_pkt = virtio_transport_cancel_pkt,
.dgram_bind = virtio_transport_dgram_bind,
.dgram_dequeue = virtio_transport_dgram_dequeue,
--
2.7.4
^ permalink raw reply related
* [PATCH v4 2/4] vhost-vsock: add pkt cancel capability
From: Peng Tao @ 2016-12-12 12:21 UTC (permalink / raw)
To: netdev; +Cc: virtualization, Stefan Hajnoczi, David Miller, Jorgen Hansen, kvm
In-Reply-To: <1481545269-18104-2-git-send-email-bergwolf@gmail.com>
To allow canceling all packets of a connection.
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Peng Tao <bergwolf@gmail.com>
---
drivers/vhost/vsock.c | 41 +++++++++++++++++++++++++++++++++++++++++
include/net/af_vsock.h | 3 +++
2 files changed, 44 insertions(+)
diff --git a/drivers/vhost/vsock.c b/drivers/vhost/vsock.c
index a504e2e0..fef8808 100644
--- a/drivers/vhost/vsock.c
+++ b/drivers/vhost/vsock.c
@@ -218,6 +218,46 @@ vhost_transport_send_pkt(struct virtio_vsock_pkt *pkt)
return len;
}
+static int
+vhost_transport_cancel_pkt(struct vsock_sock *vsk)
+{
+ struct vhost_vsock *vsock;
+ struct virtio_vsock_pkt *pkt, *n;
+ int cnt = 0;
+ LIST_HEAD(freeme);
+
+ /* Find the vhost_vsock according to guest context id */
+ vsock = vhost_vsock_get(vsk->remote_addr.svm_cid);
+ if (!vsock)
+ return -ENODEV;
+
+ spin_lock_bh(&vsock->send_pkt_list_lock);
+ list_for_each_entry_safe(pkt, n, &vsock->send_pkt_list, list) {
+ if (pkt->cancel_token != vsk)
+ continue;
+ list_move(&pkt->list, &freeme);
+ }
+ spin_unlock_bh(&vsock->send_pkt_list_lock);
+
+ list_for_each_entry_safe(pkt, n, &freeme, list) {
+ if (pkt->reply)
+ cnt++;
+ list_del(&pkt->list);
+ virtio_transport_free_pkt(pkt);
+ }
+
+ if (cnt) {
+ struct vhost_virtqueue *tx_vq = &vsock->vqs[VSOCK_VQ_TX];
+ int new_cnt;
+
+ new_cnt = atomic_sub_return(cnt, &vsock->queued_replies);
+ if (new_cnt + cnt >= tx_vq->num && new_cnt < tx_vq->num)
+ vhost_poll_queue(&tx_vq->poll);
+ }
+
+ return 0;
+}
+
static struct virtio_vsock_pkt *
vhost_vsock_alloc_pkt(struct vhost_virtqueue *vq,
unsigned int out, unsigned int in)
@@ -664,6 +704,7 @@ static struct virtio_transport vhost_transport = {
.release = virtio_transport_release,
.connect = virtio_transport_connect,
.shutdown = virtio_transport_shutdown,
+ .cancel_pkt = vhost_transport_cancel_pkt,
.dgram_enqueue = virtio_transport_dgram_enqueue,
.dgram_dequeue = virtio_transport_dgram_dequeue,
diff --git a/include/net/af_vsock.h b/include/net/af_vsock.h
index f275896..f32ed9a 100644
--- a/include/net/af_vsock.h
+++ b/include/net/af_vsock.h
@@ -100,6 +100,9 @@ struct vsock_transport {
void (*destruct)(struct vsock_sock *);
void (*release)(struct vsock_sock *);
+ /* Cancel all pending packets sent on vsock. */
+ int (*cancel_pkt)(struct vsock_sock *vsk);
+
/* Connections. */
int (*connect)(struct vsock_sock *);
--
2.7.4
^ permalink raw reply related
* [PATCH v4 1/4] vsock: track pkt owner vsock
From: Peng Tao @ 2016-12-12 12:21 UTC (permalink / raw)
To: netdev; +Cc: virtualization, Stefan Hajnoczi, David Miller, Jorgen Hansen, kvm
In-Reply-To: <1481545269-18104-1-git-send-email-bergwolf@gmail.com>
So that we can cancel a queued pkt later if necessary.
Signed-off-by: Peng Tao <bergwolf@gmail.com>
---
include/linux/virtio_vsock.h | 2 ++
net/vmw_vsock/virtio_transport_common.c | 7 +++++++
2 files changed, 9 insertions(+)
diff --git a/include/linux/virtio_vsock.h b/include/linux/virtio_vsock.h
index 9638bfe..193ad3a 100644
--- a/include/linux/virtio_vsock.h
+++ b/include/linux/virtio_vsock.h
@@ -48,6 +48,7 @@ struct virtio_vsock_pkt {
struct virtio_vsock_hdr hdr;
struct work_struct work;
struct list_head list;
+ void *cancel_token; /* only used for cancellation */
void *buf;
u32 len;
u32 off;
@@ -56,6 +57,7 @@ struct virtio_vsock_pkt {
struct virtio_vsock_pkt_info {
u32 remote_cid, remote_port;
+ struct vsock_sock *vsk;
struct msghdr *msg;
u32 pkt_len;
u16 type;
diff --git a/net/vmw_vsock/virtio_transport_common.c b/net/vmw_vsock/virtio_transport_common.c
index a53b3a1..ef94eb8 100644
--- a/net/vmw_vsock/virtio_transport_common.c
+++ b/net/vmw_vsock/virtio_transport_common.c
@@ -57,6 +57,7 @@ virtio_transport_alloc_pkt(struct virtio_vsock_pkt_info *info,
pkt->len = len;
pkt->hdr.len = cpu_to_le32(len);
pkt->reply = info->reply;
+ pkt->cancel_token = info->vsk;
if (info->msg && len > 0) {
pkt->buf = kmalloc(len, GFP_KERNEL);
@@ -180,6 +181,7 @@ static int virtio_transport_send_credit_update(struct vsock_sock *vsk,
struct virtio_vsock_pkt_info info = {
.op = VIRTIO_VSOCK_OP_CREDIT_UPDATE,
.type = type,
+ .vsk = vsk,
};
return virtio_transport_send_pkt_info(vsk, &info);
@@ -519,6 +521,7 @@ int virtio_transport_connect(struct vsock_sock *vsk)
struct virtio_vsock_pkt_info info = {
.op = VIRTIO_VSOCK_OP_REQUEST,
.type = VIRTIO_VSOCK_TYPE_STREAM,
+ .vsk = vsk,
};
return virtio_transport_send_pkt_info(vsk, &info);
@@ -534,6 +537,7 @@ int virtio_transport_shutdown(struct vsock_sock *vsk, int mode)
VIRTIO_VSOCK_SHUTDOWN_RCV : 0) |
(mode & SEND_SHUTDOWN ?
VIRTIO_VSOCK_SHUTDOWN_SEND : 0),
+ .vsk = vsk,
};
return virtio_transport_send_pkt_info(vsk, &info);
@@ -560,6 +564,7 @@ virtio_transport_stream_enqueue(struct vsock_sock *vsk,
.type = VIRTIO_VSOCK_TYPE_STREAM,
.msg = msg,
.pkt_len = len,
+ .vsk = vsk,
};
return virtio_transport_send_pkt_info(vsk, &info);
@@ -581,6 +586,7 @@ static int virtio_transport_reset(struct vsock_sock *vsk,
.op = VIRTIO_VSOCK_OP_RST,
.type = VIRTIO_VSOCK_TYPE_STREAM,
.reply = !!pkt,
+ .vsk = vsk,
};
/* Send RST only if the original pkt is not a RST pkt */
@@ -826,6 +832,7 @@ virtio_transport_send_response(struct vsock_sock *vsk,
.remote_cid = le32_to_cpu(pkt->hdr.src_cid),
.remote_port = le32_to_cpu(pkt->hdr.src_port),
.reply = true,
+ .vsk = vsk,
};
return virtio_transport_send_pkt_info(vsk, &info);
--
2.7.4
^ permalink raw reply related
* [PATCH v4 0/4] vsock: cancel connect packets when failing to connect
From: Peng Tao @ 2016-12-12 12:21 UTC (permalink / raw)
To: netdev; +Cc: virtualization, Stefan Hajnoczi, David Miller, Jorgen Hansen, kvm
Currently, if a connect call fails on a signal or timeout (e.g., guest is still
in the process of starting up), we'll just return to caller and leave the connect
packet queued and they are sent even though the connection is considered a failure,
which can confuse applications with unwanted false connect attempt.
The patchset enables vsock (both host and guest) to cancel queued packets when
a connect attempt is considered to fail.
v4 changelog:
- drop two unnecessary void * cast
- update new callback commnet
v3 changelog:
- define cancel_pkt callback in struct vsock_transport rather than struct virtio_transport
- rename virtio_vsock_pkt->vsk to virtio_vsock_pkt->cancel_token
v2 changelog:
- fix queued_replies counting and resume tx/rx when necessary
Cheers,
Tao
Peng Tao (4):
vsock: track pkt owner vsock
vhost-vsock: add pkt cancel capability
vsock: add pkt cancel capability
vsock: cancel packets when failing to connect
drivers/vhost/vsock.c | 41 ++++++++++++++++++++++++++++++++
include/linux/virtio_vsock.h | 2 ++
include/net/af_vsock.h | 3 +++
net/vmw_vsock/af_vsock.c | 14 +++++++++++
net/vmw_vsock/virtio_transport.c | 42 +++++++++++++++++++++++++++++++++
net/vmw_vsock/virtio_transport_common.c | 7 ++++++
6 files changed, 109 insertions(+)
--
2.7.4
^ permalink raw reply
* (unknown),
From: Brianna Falzone @ 2016-12-12 12:19 UTC (permalink / raw)
My name is Brianna Falzone , I am a United State Army officer, i saw
your mail on google search please reply to me So that we know better.
I hope to read
Thanks and hope to hear from you soon.
Regards
Brianna
^ permalink raw reply
* Re: Re: stmmac driver...
From: Niklas Cassel @ 2016-12-12 12:14 UTC (permalink / raw)
To: Jie Deng, Niklas Cassel
Cc: David Miller, alexandre.torgue, peppe.cavallaro, netdev,
CARLOS.PALMINHA, Joao.Pinto
In-Reply-To: <f64fde7c-9fe5-7ed9-8d01-23702e64f8aa@synopsys.com>
(resend with netdev included)
On 12/09/2016 05:29 PM, Jie Deng wrote:
>
> On 2016/12/9 18:50, Niklas Cassel wrote:
>> Hello Jie Deng
>>
>>
>> In your cover letter you wrote
>>
>> dwc-eth-xxx.x
>> The DWC ethernet core layer (DWC ECL). This layer contains codes
>> can be shared by different DWC series ethernet cores
>>
>> Does this mean that code in dwc-eth-xxx.x is common to all
>> the different Synopsys IPs, GMAC, XGMAC and XLGMAC ?
>>
>>
>> Regards,
>> Niklas
> Yeah, these codes may be reused in the future (due to HW similarities) but it
> would require a lot of refactoring. For the moment I will focus on the driver
> only for XLGMAC.
Ok, thank you for the clarification.
>
> XLGMAC is Synopsys "Enterprise MAC" controller (the product is already public):
> https://www.synopsys.com/dw/ipdir.php?ds=dwc_ether_enterprise_mac
>
> What do you think following strategy:
> - GMAC (QoS): discard drivers/net/ethernet/synopsys/dwc_eth_qos.c and keep
> development under drivers/net/ethernet/stmicro/stmmac/
> - XGMAC: keep development under drivers/net/ethernet/amd/xgbe/
> - XLGMAC: do development under drivers/net/ethernet/synopsys/
I don't have an opinion regarding XLGMAC.
For GMAC, I think it's a good idea that everybody focuses on the same driver (stmmac).
The same thing applies to XGMAC, amd-xgbe and sxgbe, however there I don't know
of any consolidation efforts.
>
> Thanks,
> Jie
>
>> On Fri, Dec 9, 2016 at 11:05 AM, Jie Deng <Jie.Deng1@synopsys.com> wrote:
>>> On 2016/12/8 23:25, David Miller wrote:
>>>> From: Alexandre Torgue <alexandre.torgue@st.com>
>>>> Date: Thu, 8 Dec 2016 14:55:04 +0100
>>>>
>>>>> Maybe I forget some series. Do you have others in mind ?
>>>> Please see the thread titled:
>>>>
>>>> "net: ethernet: Initial driver for Synopsys DWC XLGMAC"
>>>>
>>>> which seems to be discussing consolidation of various drivers
>>>> for the same IP core, of which stmmac is one.
>>>>
>>>> I personally am against any change of the driver name and
>>>> things like this, and wish the people doing that work would
>>>> simply contribute to making whatever changes they need directly
>>>> to the stmmac driver.
>>>>
>>>> You really need to voice your opinion when major changes are being
>>>> proposed for the driver you maintain.
>>>>
>>> Hi David and Alex,
>>>
>>> XLGMAC is not a version of GMAC. Synopsys has several IPs and each IP has
>>> several versions.
>>>
>>> GMAC(QoS): 3.5, 3.7, 4.0, 4.10, 4.20...
>>> XGMAC: 1.00, 1.10, 1.20, 2.00, 2.10, 2.11...
>>> XLGMAC (Synopsys DesignWare Core Enterprise Ethernet): this is a new IP.
>>>
>>> Regards,
>>> Jie
>>>
>
^ permalink raw reply
* [PATCH 1/2] net: ethernet: hisi_femac: Call SET_NETDEV_DEV()
From: Dongpo Li @ 2016-12-12 12:03 UTC (permalink / raw)
To: yisen.zhuang, salil.mehta, davem
Cc: f.fainelli, xuejiancheng, benjamin.chenhao, caizhiyong, netdev,
linux-kernel, Dongpo Li
In-Reply-To: <1481544223-207906-1-git-send-email-lidongpo@hisilicon.com>
The hisi_femac driver calls into PHYLIB which now checks for
net_device->dev.parent, so make sure we do set it before calling into
any MDIO/PHYLIB related function.
Fixes: ec988ad78ed6 ("phy: Don't increment MDIO bus refcount unless it's a different owner")
Signed-off-by: Dongpo Li <lidongpo@hisilicon.com>
---
drivers/net/ethernet/hisilicon/hisi_femac.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/hisilicon/hisi_femac.c b/drivers/net/ethernet/hisilicon/hisi_femac.c
index 4986306..979852d 100644
--- a/drivers/net/ethernet/hisilicon/hisi_femac.c
+++ b/drivers/net/ethernet/hisilicon/hisi_femac.c
@@ -805,6 +805,7 @@ static int hisi_femac_drv_probe(struct platform_device *pdev)
return -ENOMEM;
platform_set_drvdata(pdev, ndev);
+ SET_NETDEV_DEV(ndev, &pdev->dev);
priv = netdev_priv(ndev);
priv->dev = dev;
@@ -882,7 +883,6 @@ static int hisi_femac_drv_probe(struct platform_device *pdev)
ndev->netdev_ops = &hisi_femac_netdev_ops;
ndev->ethtool_ops = &hisi_femac_ethtools_ops;
netif_napi_add(ndev, &priv->napi, hisi_femac_poll, FEMAC_POLL_WEIGHT);
- SET_NETDEV_DEV(ndev, &pdev->dev);
hisi_femac_port_init(priv);
--
2.8.2
^ permalink raw reply related
* [PATCH 2/2] net: ethernet: hip04: Call SET_NETDEV_DEV()
From: Dongpo Li @ 2016-12-12 12:03 UTC (permalink / raw)
To: yisen.zhuang, salil.mehta, davem
Cc: f.fainelli, xuejiancheng, benjamin.chenhao, caizhiyong, netdev,
linux-kernel, Dongpo Li
In-Reply-To: <1481544223-207906-1-git-send-email-lidongpo@hisilicon.com>
The hip04 driver calls into PHYLIB which now checks for
net_device->dev.parent, so make sure we do set it before calling into
any MDIO/PHYLIB related function.
Fixes: ec988ad78ed6 ("phy: Don't increment MDIO bus refcount unless it's a different owner")
Signed-off-by: Dongpo Li <lidongpo@hisilicon.com>
---
drivers/net/ethernet/hisilicon/hip04_eth.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/hisilicon/hip04_eth.c b/drivers/net/ethernet/hisilicon/hip04_eth.c
index 854befd..97b1847 100644
--- a/drivers/net/ethernet/hisilicon/hip04_eth.c
+++ b/drivers/net/ethernet/hisilicon/hip04_eth.c
@@ -828,6 +828,7 @@ static int hip04_mac_probe(struct platform_device *pdev)
priv = netdev_priv(ndev);
priv->ndev = ndev;
platform_set_drvdata(pdev, ndev);
+ SET_NETDEV_DEV(ndev, &pdev->dev);
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
priv->base = devm_ioremap_resource(d, res);
@@ -903,7 +904,6 @@ static int hip04_mac_probe(struct platform_device *pdev)
ndev->priv_flags |= IFF_UNICAST_FLT;
ndev->irq = irq;
netif_napi_add(ndev, &priv->napi, hip04_rx_poll, NAPI_POLL_WEIGHT);
- SET_NETDEV_DEV(ndev, &pdev->dev);
hip04_reset_ppe(priv);
if (priv->phy_mode == PHY_INTERFACE_MODE_MII)
--
2.8.2
^ permalink raw reply related
* [PATCH 0/2] net: ethernet: hisilicon: set dev->dev.parent before PHY connect
From: Dongpo Li @ 2016-12-12 12:03 UTC (permalink / raw)
To: yisen.zhuang, salil.mehta, davem
Cc: f.fainelli, xuejiancheng, benjamin.chenhao, caizhiyong, netdev,
linux-kernel, Dongpo Li
This patch series builds atop:
ec988ad78ed6d184a7f4ca6b8e962b0e8f1de461 ("phy: Don't increment MDIO bus
refcount unless it's a different owner")
I have checked all the hisilicon ethernet driver and found only two drivers
need to be fixed to make sure set dev->dev.parent before PHY connect.
Dongpo Li (2):
net: ethernet: hisi_femac: Call SET_NETDEV_DEV()
net: ethernet: hip04: Call SET_NETDEV_DEV()
drivers/net/ethernet/hisilicon/hip04_eth.c | 2 +-
drivers/net/ethernet/hisilicon/hisi_femac.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
--
2.8.2
^ permalink raw reply
* Re: [PATCH v3 2/4] vhost-vsock: add pkt cancel capability
From: Peng Tao @ 2016-12-12 11:56 UTC (permalink / raw)
To: Jorgen S. Hansen
Cc: netdev@vger.kernel.org, virtualization@lists.linux-foundation.org,
David Miller, Stefan Hajnoczi, kvm@vger.kernel.org
In-Reply-To: <426F96AC-2E7C-4BEC-A3D3-7D8A97FDD51D@vmware.com>
On Mon, Dec 12, 2016 at 6:37 PM, Jorgen S. Hansen <jhansen@vmware.com> wrote:
>
>> On Dec 8, 2016, at 6:12 PM, Peng Tao <bergwolf@gmail.com> wrote:
>>
>> --- a/include/net/af_vsock.h
>> +++ b/include/net/af_vsock.h
>> @@ -100,6 +100,9 @@ struct vsock_transport {
>> void (*destruct)(struct vsock_sock *);
>> void (*release)(struct vsock_sock *);
>>
>> + /* Cancel packets belonging the same vsock */
>
> How about “/* Cancel all pending packets sent on vsock. */“ ?
>
Sure. I'll update it.
Thanks,
Tao
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [iproute2 net-next 3/8] bpf: Add BPF_ macros
From: Daniel Borkmann @ 2016-12-12 11:48 UTC (permalink / raw)
To: Hannes Frederic Sowa, David Ahern, netdev, stephen
In-Reply-To: <88e7eece-be2a-3b11-3dc1-3afa7a9bb14a@stressinduktion.org>
On 12/12/2016 12:28 PM, Hannes Frederic Sowa wrote:
> On 12.12.2016 01:53, David Ahern wrote:
>> Based on version in kernel repo, samples/bpf/libbpf.h
>>
>> Signed-off-by: David Ahern <dsa@cumulusnetworks.com>
>> ---
>> include/bpf_util.h | 179 +++++++++++++++++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 179 insertions(+)
>>
>> diff --git a/include/bpf_util.h b/include/bpf_util.h
>> index 726e34777755..5361dab1933d 100644
>
> Maybe this was already discussed: why are those not part of uapi? They
> get used in the bpf manpage.
The reason why these macros haven't been exposed to uapi header was because
they are not strict part of kernel abi. So really only the very minimum that
had to go there (such as insn opcodes) were placed into the header. That way,
kernel is still free to, for example, change or rename the macros once new
insns would get added, and user space can just define what it really needs.
That way, both don't get into each others way long term. Often it's also not
really needed if you have an elf loader, f.e. iproute2 could live without
them (up to this point).
Just took a look at the man page example, we don't even define BPF_CALL_FUNC()
in the kernel, so it's also not exactly the same. Probably makes sense to
fix/complete that example and in general add a description there wrt opcodes.
Last time I spoke with Michael, he planned to make a bigger revision to the
man page to improve documentation.
Thanks,
Daniel
^ permalink raw reply
* Re: [PATCH 1/1] Fixed to BUG_ON to WARN_ON
From: Ozgur Karatas @ 2016-12-12 11:32 UTC (permalink / raw)
To: Stefan Schmidt, yishaih@mellanox.com; +Cc: netdev, linux-kernel
In-Reply-To: <080dc5cc-3d72-a5db-2f53-5c6ce74837b4@osg.samsung.com>
Dear Stefan;
I'm reading to Documentation/SubmittingPatches and I still apologized for misrepresentations my patches.
I will add a next time good commit message and commit subjects.
Sorry,
Regards
Ozgur Karatas
12.12.2016, 13:20, "Stefan Schmidt" <stefan@osg.samsung.com>:
> Hello.
>
> On 12/12/16 11:58, Ozgur Karatas wrote:
>> Hello all,
>> I think should be use to "WARN_ON" and checkpatch script give to error, I fixed and I think should don't use "BUG_ON".
>> Regards,
>>
>> Signed-off-by: Ozgur Karatas <okaratas@member.fsf.org>
>
> I pointed you already before to the Documentation how to prepare a
> commit subject and commit message. You just replied with that you are
> new to contributing patches. That is all fine and many people are new
> each release. Please take the time to read the provided and pointed out
> docs.
>
> If you keep ignoring such suggestions and docs I would think people will
> keep ignoring your patches.
>
> regards
> Stefan Schmidt
^ permalink raw reply
* [patch net-next] irda: w83977af_ir: cleanup an indent issue
From: Dan Carpenter @ 2016-12-12 11:21 UTC (permalink / raw)
To: Samuel Ortiz, Joe Perches; +Cc: netdev, kernel-janitors
In commit 99d8d2159d7c ("irda: w83977af_ir: Neaten logging"), we
accidentally added an extra tab to these lines.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
diff --git a/drivers/net/irda/w83977af_ir.c b/drivers/net/irda/w83977af_ir.c
index f293d33fb28f..8d5b903d1d9d 100644
--- a/drivers/net/irda/w83977af_ir.c
+++ b/drivers/net/irda/w83977af_ir.c
@@ -517,9 +517,9 @@ static netdev_tx_t w83977af_hard_xmit(struct sk_buff *skb,
mtt = irda_get_mtt(skb);
pr_debug("%s: %ld, mtt=%d\n", __func__, jiffies, mtt);
- if (mtt > 1000)
- mdelay(mtt / 1000);
- else if (mtt)
+ if (mtt > 1000)
+ mdelay(mtt / 1000);
+ else if (mtt)
udelay(mtt);
/* Enable DMA interrupt */
^ permalink raw reply related
* Re: [iproute2 net-next 3/8] bpf: Add BPF_ macros
From: Hannes Frederic Sowa @ 2016-12-12 11:28 UTC (permalink / raw)
To: David Ahern, netdev, stephen
In-Reply-To: <1481503995-24825-4-git-send-email-dsa@cumulusnetworks.com>
On 12.12.2016 01:53, David Ahern wrote:
> Based on version in kernel repo, samples/bpf/libbpf.h
>
> Signed-off-by: David Ahern <dsa@cumulusnetworks.com>
> ---
> include/bpf_util.h | 179 +++++++++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 179 insertions(+)
>
> diff --git a/include/bpf_util.h b/include/bpf_util.h
> index 726e34777755..5361dab1933d 100644
Maybe this was already discussed: why are those not part of uapi? They
get used in the bpf manpage.
Bye,
Hannes
^ permalink raw reply
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