* Donation Project
From: Mrs. Mary Saleh Saville @ 2013-11-05 18:07 UTC (permalink / raw)
To: net_lm, netcomp3000, netbizpak, netballpk, netabuse, netadmin,
netcourt, netdev, net, netcom_dps, netbizn, net.country,
netcruiser, netcom, netadmin, netbsd-docs-ru, netbehaviour,
netadmin, netbytes, net, netbsd-soccvs, netbeans-info, netadmin,
net, net, netadm, net, netadm, netchatcomp, netbazar, netangels,
net96, net_central, net-abuse, netcontact, netddang, netcom,
net-artidaya, netbank, netannounce, netcell, netbank, net,
netcomp, netabuse, netcompd, netcom, net818, net, net1
Hello,
I am Mrs. Mary Saleh Saville an ageing widow suffering from long time illness. I have some funds I inherited from my late husband, the sum of US$3,500,000.00 and I am in need of a very honest and God fearing person that will use the fund for God's work to help the less privileged out there.
I have mapped out$1,200.000.00 for your personal use in this work. While the rest will be for the work.Please if you would be able to use the funds for the Lord's work kindly reply for further details.
Your full name:
Your full address:
Your telephone/mobile number:
Your fax Number:
Your full company name:
Your age:
Thanks and God bless.
Mrs. Mary Saleh Saville
^ permalink raw reply
* Re: [patch net-next 2/3] netfilter: ip6_tables: use reasm skb for matching
From: Patrick McHardy @ 2013-11-05 18:16 UTC (permalink / raw)
To: Jiri Pirko
Cc: Florian Westphal, netdev, davem, pablo, netfilter-devel, yoshfuji,
kadlec, mleitner, kuznet, jmorris, wensong, horms, ja, edumazet,
pshelar, jasowang, alexander.h.duyck, coreteam
In-Reply-To: <20131105150115.GB2438@minipsycho.orion>
On Tue, Nov 05, 2013 at 04:01:15PM +0100, Jiri Pirko wrote:
> Tue, Nov 05, 2013 at 02:41:19PM CET, kaber@trash.net wrote:
> >On Tue, Nov 05, 2013 at 02:32:05PM +0100, Florian Westphal wrote:
> >> Jiri Pirko <jiri@resnulli.us> wrote:
> >> > This patch fixes for example following situation:
> >> > On HOSTA do:
> >> > ip6tables -I INPUT -p icmpv6 -j DROP
> >> > ip6tables -I INPUT -p icmpv6 -m icmp6 --icmpv6-type 128 -j ACCEPT
> >>
> >> untested:
> >>
> >> -A INPUT -p icmpv6 -m icmp6 --icmpv6-type 128 -j ACCEPT
> >> -A INPUT -p icmpv6 -m conntrack --ctstatus CONFIRMED -j ACCEPT
> >> -A INPUT -p icmpv6 -j DROP
> >>
> >> > and on HOSTB you do:
> >> > ping6 HOSTA -s2000 (MTU is 1500)
> >> >
> >> > Incoming echo requests will be filtered out on HOSTA. This issue does
> >> > not occur with smaller packets than MTU (where fragmentation does not happen).
> >>
> >> Patrick, any reason not to kill the special-casing (ct has assigned helper or
> >> unconfirmed conntrack) in __ipv6_conntrack_in() ?
> >>
> >> This should make ipv6 frag behaviour consistent; right now its rather
> >> confusing from ruleset point of view, especially the first packet
> >> of a connection is always seen as reassembled.
> >>
> >> So with Jiris rules
> >>
> >> -A INPUT -p icmpv6 -m icmp6 --icmpv6-type 128 -j ACCEPT
> >> -A INPUT -p icmpv6 -j DROP
> >>
> >> ping6 -s $bignum works for the first packet but not for subsequent ones
> >> which is quite irritating.
> >
> >Well, the reason was to avoid unnecessary work doing refragmentation
> >unless really required. I know its rather complicated, but IPv6 has
> >always required treating fragments manually or using conntrack state.
> >
> >I'm not objecting to changing this, but the patches as they are are
> >not the way to go. First, moving nfct_frag to struct sk_buff seems
>
> I'm a bit lost. What "nfct_frag" are you reffering to here?
I meant nfct_reasm of course.
> >like a real waste of space for this quite rare case. Also, we can't
> >just use the reassembled packet in ip6tables, when modifying it we
> >will still output the unchanged fragments. An last of all, we'll be
> >executing the rules on the reassembled packet multiple times, one
> >for each fragment.
>
> Reassembled skb would be only used for matching where no changes takes
> place.
That still doesn't work, our matches are not purely passive.
> End even though, the matching is now done for each fragment skb anyway. The
> change is only to do it on different skb. I see no erformance or any
> other problem in that.
Accounting, quota, statistic, limit, ... come to mind. Basically any
match that keeps state.
> >So if someone wants to change this, simply *only* pass the reassembled
> >packet through the netfilter hooks and drop the fragments, as in IPv4.
>
> This is unfortunatelly not possible because in forwarding use case, the
> fragments have to be send out as they come in.
No, the IPv6 NAT patches fixed that, we still do proper refragmentation
and we still respect the original fragment sizes, thus are not responsible
for potentially exceeding the PMTU on the following path.
^ permalink raw reply
* Re: [PATCH 3/7] IBM Akebono: Add support for a new PHY to the IBM emac driver
From: Ben Hutchings @ 2013-11-05 18:16 UTC (permalink / raw)
To: Alistair Popple; +Cc: linuxppc-dev, David S. Miller, netdev
In-Reply-To: <1383629471-16979-3-git-send-email-alistair@popple.id.au>
On Tue, 2013-11-05 at 16:31 +1100, Alistair Popple wrote:
[...]
> --- a/drivers/net/ethernet/ibm/emac/Kconfig
> +++ b/drivers/net/ethernet/ibm/emac/Kconfig
> @@ -55,6 +55,10 @@ config IBM_EMAC_RGMII
> bool
> default n
>
> +config IBM_EMAC_RGMII_WOL
> + bool
> + default n
> +
[...]
So no-one can even build-test this at present!
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [patch net-next 2/3] netfilter: ip6_tables: use reasm skb for matching
From: Patrick McHardy @ 2013-11-05 18:19 UTC (permalink / raw)
To: Florian Westphal
Cc: Jiri Pirko, netdev, davem, pablo, netfilter-devel, yoshfuji,
kadlec, mleitner, kuznet, jmorris, wensong, horms, ja, edumazet,
pshelar, jasowang, alexander.h.duyck, coreteam
In-Reply-To: <20131105153921.GD15370@breakpoint.cc>
On Tue, Nov 05, 2013 at 04:39:21PM +0100, Florian Westphal wrote:
> Jiri Pirko <jiri@resnulli.us> wrote:
> > Tue, Nov 05, 2013 at 02:41:19PM CET, kaber@trash.net wrote:
> > >executing the rules on the reassembled packet multiple times, one
> > >for each fragment.
> >
> [..]
> > End even though, the matching is now done for each fragment skb anyway. The
> > change is only to do it on different skb. I see no erformance or any
> > other problem in that.
>
> One problem that comes to mind is that nfacct or quota match will
> now account num_of_fragments * length_of_reassemled_skb bytes.
indeed. The easiest way to fix all this (and, btw, also the
pskb_expand_head() oops which is currently reported by multiple people)
is to get rid of all the fragmentation handling and simply use the
reassembled skb.
^ permalink raw reply
* Re: [patch net-next 2/3] netfilter: ip6_tables: use reasm skb for matching
From: Jiri Pirko @ 2013-11-05 18:21 UTC (permalink / raw)
To: Patrick McHardy
Cc: Florian Westphal, netdev, davem, pablo, netfilter-devel, yoshfuji,
kadlec, mleitner, kuznet, jmorris, wensong, horms, ja, edumazet,
pshelar, jasowang, alexander.h.duyck, coreteam
In-Reply-To: <20131105181923.GB7435@macbook.localnet>
Tue, Nov 05, 2013 at 07:19:24PM CET, kaber@trash.net wrote:
>On Tue, Nov 05, 2013 at 04:39:21PM +0100, Florian Westphal wrote:
>> Jiri Pirko <jiri@resnulli.us> wrote:
>> > Tue, Nov 05, 2013 at 02:41:19PM CET, kaber@trash.net wrote:
>> > >executing the rules on the reassembled packet multiple times, one
>> > >for each fragment.
>> >
>> [..]
>> > End even though, the matching is now done for each fragment skb anyway. The
>> > change is only to do it on different skb. I see no erformance or any
>> > other problem in that.
>>
>> One problem that comes to mind is that nfacct or quota match will
>> now account num_of_fragments * length_of_reassemled_skb bytes.
>
>indeed. The easiest way to fix all this (and, btw, also the
>pskb_expand_head() oops which is currently reported by multiple people)
>is to get rid of all the fragmentation handling and simply use the
>reassembled skb.
Okay. That will resolve the skb->sk rewrite problem as well. I will
prepare a patch.
^ permalink raw reply
* Re: [PATCH net-next 1/3] net: move pskb_put() to core code
From: Ben Hutchings @ 2013-11-05 18:33 UTC (permalink / raw)
To: Mathias Krause
Cc: David S. Miller, Steffen Klassert, Herbert Xu, Dmitry Tarnyagin,
netdev
In-Reply-To: <5044e9be63b6e0734670654e6249576e3be4279e.1381923854.git.mathias.krause@secunet.com>
On Tue, 2013-11-05 at 14:54 +0100, Mathias Krause wrote:
> This function has usage beside IPsec so move it to the core skbuff code.
> While doing so, give it some documentation and change its return type to
> 'unsigned char *' to be in line with skb_put().
[...]
> --- a/net/core/skbuff.c
> +++ b/net/core/skbuff.c
> @@ -1257,6 +1257,29 @@ free_skb:
> EXPORT_SYMBOL(skb_pad);
>
> /**
> + * pskb_put - add data to the tail of a potentially fragmented buffer
> + * @skb: start of the buffer to use
> + * @tail: tail fragment of the buffer to use
> + * @len: amount of data to add
> + *
> + * This function extends the used data area of the potentially
> + * fragmented buffer. &tail must be the last fragment of &skb -- or
> + * &skb itself. If this would exceed the total buffer size the kernel
Keep using @ to refer to the parameters in this description.
Ben.
> + * will panic. A pointer to the first byte of the extra data is
> + * returned.
> + */
[...]
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* [PATCH] smsc9420: Use netif_<level>
From: Joe Perches @ 2013-11-05 18:34 UTC (permalink / raw)
To: netdev; +Cc: Steve Glendinning, LKML
Use a more standard logging style.
Convert smsc_<level> macros to use netif_<level>.
Remove unused #define PFX
Add pr_fmt and neaten pr_<level> uses.
Signed-off-by: Joe Perches <joe@perches.com>
---
drivers/net/ethernet/smsc/smsc9420.c | 155 +++++++++++++++++------------------
1 file changed, 77 insertions(+), 78 deletions(-)
diff --git a/drivers/net/ethernet/smsc/smsc9420.c b/drivers/net/ethernet/smsc/smsc9420.c
index 059bcaf..f433d97 100644
--- a/drivers/net/ethernet/smsc/smsc9420.c
+++ b/drivers/net/ethernet/smsc/smsc9420.c
@@ -19,6 +19,8 @@
***************************************************************************
*/
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
#include <linux/interrupt.h>
#include <linux/kernel.h>
#include <linux/netdevice.h>
@@ -33,7 +35,6 @@
#include "smsc9420.h"
#define DRV_NAME "smsc9420"
-#define PFX DRV_NAME ": "
#define DRV_MDIONAME "smsc9420-mdio"
#define DRV_DESCRIPTION "SMSC LAN9420 driver"
#define DRV_VERSION "1.01"
@@ -97,21 +98,6 @@ static uint debug = -1;
module_param(debug, uint, 0);
MODULE_PARM_DESC(debug, "debug level");
-#define smsc_dbg(TYPE, f, a...) \
-do { if ((pd)->msg_enable & NETIF_MSG_##TYPE) \
- netdev_dbg((pd)->dev, PFX f "\n", ## a); \
-} while (0)
-
-#define smsc_info(TYPE, f, a...) \
-do { if ((pd)->msg_enable & NETIF_MSG_##TYPE) \
- netdev_info((pd)->dev, PFX f "\n", ## a); \
-} while (0)
-
-#define smsc_warn(TYPE, f, a...) \
-do { if ((pd)->msg_enable & NETIF_MSG_##TYPE) \
- netdev_warn((pd)->dev, PFX f "\n", ## a); \
-} while (0)
-
static inline u32 smsc9420_reg_read(struct smsc9420_pdata *pd, u32 offset)
{
return ioread32(pd->ioaddr + offset);
@@ -140,7 +126,7 @@ static int smsc9420_mii_read(struct mii_bus *bus, int phyaddr, int regidx)
/* confirm MII not busy */
if ((smsc9420_reg_read(pd, MII_ACCESS) & MII_ACCESS_MII_BUSY_)) {
- smsc_warn(DRV, "MII is busy???");
+ netif_warn(pd, drv, pd->dev, "MII is busy???\n");
goto out;
}
@@ -159,7 +145,7 @@ static int smsc9420_mii_read(struct mii_bus *bus, int phyaddr, int regidx)
udelay(10);
}
- smsc_warn(DRV, "MII busy timeout!");
+ netif_warn(pd, drv, pd->dev, "MII busy timeout!\n");
out:
spin_unlock_irqrestore(&pd->phy_lock, flags);
@@ -178,7 +164,7 @@ static int smsc9420_mii_write(struct mii_bus *bus, int phyaddr, int regidx,
/* confirm MII not busy */
if ((smsc9420_reg_read(pd, MII_ACCESS) & MII_ACCESS_MII_BUSY_)) {
- smsc_warn(DRV, "MII is busy???");
+ netif_warn(pd, drv, pd->dev, "MII is busy???\n");
goto out;
}
@@ -200,7 +186,7 @@ static int smsc9420_mii_write(struct mii_bus *bus, int phyaddr, int regidx,
udelay(10);
}
- smsc_warn(DRV, "MII busy timeout!");
+ netif_warn(pd, drv, pd->dev, "MII busy timeout!\n");
out:
spin_unlock_irqrestore(&pd->phy_lock, flags);
@@ -222,7 +208,7 @@ static int smsc9420_eeprom_reload(struct smsc9420_pdata *pd)
BUG_ON(!pd);
if (smsc9420_reg_read(pd, E2P_CMD) & E2P_CMD_EPC_BUSY_) {
- smsc_dbg(DRV, "smsc9420_eeprom_reload: Eeprom busy");
+ netif_dbg(pd, drv, pd->dev, "%s: Eeprom busy\n", __func__);
return -EIO;
}
@@ -235,7 +221,7 @@ static int smsc9420_eeprom_reload(struct smsc9420_pdata *pd)
return 0;
} while (timeout--);
- smsc_warn(DRV, "smsc9420_eeprom_reload: Eeprom timed out");
+ netif_warn(pd, drv, pd->dev, "%s: Eeprom timed out\n", __func__);
return -EIO;
}
@@ -347,9 +333,9 @@ static int smsc9420_eeprom_send_cmd(struct smsc9420_pdata *pd, u32 op)
int timeout = 100;
u32 e2cmd;
- smsc_dbg(HW, "op 0x%08x", op);
+ netif_dbg(pd, hw, pd->dev, "op 0x%08x\n", op);
if (smsc9420_reg_read(pd, E2P_CMD) & E2P_CMD_EPC_BUSY_) {
- smsc_warn(HW, "Busy at start");
+ netif_warn(pd, hw, pd->dev, "Busy at start\n");
return -EBUSY;
}
@@ -362,12 +348,13 @@ static int smsc9420_eeprom_send_cmd(struct smsc9420_pdata *pd, u32 op)
} while ((e2cmd & E2P_CMD_EPC_BUSY_) && (--timeout));
if (!timeout) {
- smsc_info(HW, "TIMED OUT");
+ netif_info(pd, hw, pd->dev, "TIMED OUT\n");
return -EAGAIN;
}
if (e2cmd & E2P_CMD_EPC_TIMEOUT_) {
- smsc_info(HW, "Error occurred during eeprom operation");
+ netif_info(pd, hw, pd->dev,
+ "Error occurred during eeprom operation\n");
return -EINVAL;
}
@@ -380,7 +367,7 @@ static int smsc9420_eeprom_read_location(struct smsc9420_pdata *pd,
u32 op = E2P_CMD_EPC_CMD_READ_ | address;
int ret;
- smsc_dbg(HW, "address 0x%x", address);
+ netif_dbg(pd, hw, pd->dev, "address 0x%x\n", address);
ret = smsc9420_eeprom_send_cmd(pd, op);
if (!ret)
@@ -395,7 +382,7 @@ static int smsc9420_eeprom_write_location(struct smsc9420_pdata *pd,
u32 op = E2P_CMD_EPC_CMD_ERASE_ | address;
int ret;
- smsc_dbg(HW, "address 0x%x, data 0x%x", address, data);
+ netif_dbg(pd, hw, pd->dev, "address 0x%x, data 0x%x\n", address, data);
ret = smsc9420_eeprom_send_cmd(pd, op);
if (!ret) {
@@ -492,7 +479,8 @@ static void smsc9420_check_mac_address(struct net_device *dev)
/* Check if mac address has been specified when bringing interface up */
if (is_valid_ether_addr(dev->dev_addr)) {
smsc9420_set_mac_address(dev);
- smsc_dbg(PROBE, "MAC Address is specified by configuration");
+ netif_dbg(pd, probe, pd->dev,
+ "MAC Address is specified by configuration\n");
} else {
/* Try reading mac address from device. if EEPROM is present
* it will already have been set */
@@ -507,12 +495,14 @@ static void smsc9420_check_mac_address(struct net_device *dev)
if (is_valid_ether_addr(dev->dev_addr)) {
/* eeprom values are valid so use them */
- smsc_dbg(PROBE, "Mac Address is read from EEPROM");
+ netif_dbg(pd, probe, pd->dev,
+ "Mac Address is read from EEPROM\n");
} else {
/* eeprom values are invalid, generate random MAC */
eth_hw_addr_random(dev);
smsc9420_set_mac_address(dev);
- smsc_dbg(PROBE, "MAC Address is set to random");
+ netif_dbg(pd, probe, pd->dev,
+ "MAC Address is set to random\n");
}
}
}
@@ -535,7 +525,7 @@ static void smsc9420_stop_tx(struct smsc9420_pdata *pd)
}
if (!timeout)
- smsc_warn(IFDOWN, "TX DMAC failed to stop");
+ netif_warn(pd, ifdown, pd->dev, "TX DMAC failed to stop\n");
/* ACK Tx DMAC stop bit */
smsc9420_reg_write(pd, DMAC_STATUS, DMAC_STS_TXPS_);
@@ -646,7 +636,8 @@ static void smsc9420_stop_rx(struct smsc9420_pdata *pd)
}
if (!timeout)
- smsc_warn(IFDOWN, "RX DMAC did not stop! timeout.");
+ netif_warn(pd, ifdown, pd->dev,
+ "RX DMAC did not stop! timeout\n");
/* ACK the Rx DMAC stop bit */
smsc9420_reg_write(pd, DMAC_STATUS, DMAC_STS_RXPS_);
@@ -736,7 +727,7 @@ static void smsc9420_dmac_soft_reset(struct smsc9420_pdata *pd)
smsc9420_reg_read(pd, BUS_MODE);
udelay(2);
if (smsc9420_reg_read(pd, BUS_MODE) & BUS_MODE_SWR_)
- smsc_warn(DRV, "Software reset not cleared");
+ netif_warn(pd, drv, pd->dev, "Software reset not cleared\n");
}
static int smsc9420_stop(struct net_device *dev)
@@ -855,7 +846,7 @@ static int smsc9420_alloc_rx_buffer(struct smsc9420_pdata *pd, int index)
PKT_BUF_SZ, PCI_DMA_FROMDEVICE);
if (pci_dma_mapping_error(pd->pdev, mapping)) {
dev_kfree_skb_any(skb);
- smsc_warn(RX_ERR, "pci_map_single failed!");
+ netif_warn(pd, rx_err, pd->dev, "pci_map_single failed!\n");
return -ENOMEM;
}
@@ -1004,7 +995,8 @@ static netdev_tx_t smsc9420_hard_start_xmit(struct sk_buff *skb,
mapping = pci_map_single(pd->pdev, skb->data,
skb->len, PCI_DMA_TODEVICE);
if (pci_dma_mapping_error(pd->pdev, mapping)) {
- smsc_warn(TX_ERR, "pci_map_single failed, dropping packet");
+ netif_warn(pd, tx_err, pd->dev,
+ "pci_map_single failed, dropping packet\n");
return NETDEV_TX_BUSY;
}
@@ -1056,12 +1048,12 @@ static void smsc9420_set_multicast_list(struct net_device *dev)
u32 mac_cr = smsc9420_reg_read(pd, MAC_CR);
if (dev->flags & IFF_PROMISC) {
- smsc_dbg(HW, "Promiscuous Mode Enabled");
+ netif_dbg(pd, hw, pd->dev, "Promiscuous Mode Enabled\n");
mac_cr |= MAC_CR_PRMS_;
mac_cr &= (~MAC_CR_MCPAS_);
mac_cr &= (~MAC_CR_HPFILT_);
} else if (dev->flags & IFF_ALLMULTI) {
- smsc_dbg(HW, "Receive all Multicast Enabled");
+ netif_dbg(pd, hw, pd->dev, "Receive all Multicast Enabled\n");
mac_cr &= (~MAC_CR_PRMS_);
mac_cr |= MAC_CR_MCPAS_;
mac_cr &= (~MAC_CR_HPFILT_);
@@ -1069,7 +1061,7 @@ static void smsc9420_set_multicast_list(struct net_device *dev)
struct netdev_hw_addr *ha;
u32 hash_lo = 0, hash_hi = 0;
- smsc_dbg(HW, "Multicast filter enabled");
+ netif_dbg(pd, hw, pd->dev, "Multicast filter enabled\n");
netdev_for_each_mc_addr(ha, dev) {
u32 bit_num = smsc9420_hash(ha->addr);
u32 mask = 1 << (bit_num & 0x1F);
@@ -1087,7 +1079,7 @@ static void smsc9420_set_multicast_list(struct net_device *dev)
mac_cr &= (~MAC_CR_MCPAS_);
mac_cr |= MAC_CR_HPFILT_;
} else {
- smsc_dbg(HW, "Receive own packets only.");
+ netif_dbg(pd, hw, pd->dev, "Receive own packets only\n");
smsc9420_reg_write(pd, HASHH, 0);
smsc9420_reg_write(pd, HASHL, 0);
@@ -1115,11 +1107,11 @@ static void smsc9420_phy_update_flowcontrol(struct smsc9420_pdata *pd)
else
flow = 0;
- smsc_info(LINK, "rx pause %s, tx pause %s",
- (cap & FLOW_CTRL_RX ? "enabled" : "disabled"),
- (cap & FLOW_CTRL_TX ? "enabled" : "disabled"));
+ netif_info(pd, link, pd->dev, "rx pause %s, tx pause %s\n",
+ cap & FLOW_CTRL_RX ? "enabled" : "disabled",
+ cap & FLOW_CTRL_TX ? "enabled" : "disabled");
} else {
- smsc_info(LINK, "half duplex");
+ netif_info(pd, link, pd->dev, "half duplex\n");
flow = 0;
}
@@ -1137,10 +1129,10 @@ static void smsc9420_phy_adjust_link(struct net_device *dev)
if (phy_dev->duplex != pd->last_duplex) {
u32 mac_cr = smsc9420_reg_read(pd, MAC_CR);
if (phy_dev->duplex) {
- smsc_dbg(LINK, "full duplex mode");
+ netif_dbg(pd, link, pd->dev, "full duplex mode\n");
mac_cr |= MAC_CR_FDPX_;
} else {
- smsc_dbg(LINK, "half duplex mode");
+ netif_dbg(pd, link, pd->dev, "half duplex mode\n");
mac_cr &= ~MAC_CR_FDPX_;
}
smsc9420_reg_write(pd, MAC_CR, mac_cr);
@@ -1152,9 +1144,9 @@ static void smsc9420_phy_adjust_link(struct net_device *dev)
carrier = netif_carrier_ok(dev);
if (carrier != pd->last_carrier) {
if (carrier)
- smsc_dbg(LINK, "carrier OK");
+ netif_dbg(pd, link, pd->dev, "carrier OK\n");
else
- smsc_dbg(LINK, "no carrier");
+ netif_dbg(pd, link, pd->dev, "no carrier\n");
pd->last_carrier = carrier;
}
}
@@ -1173,8 +1165,8 @@ static int smsc9420_mii_probe(struct net_device *dev)
}
phydev = pd->mii_bus->phy_map[1];
- smsc_info(PROBE, "PHY addr %d, phy_id 0x%08X", phydev->addr,
- phydev->phy_id);
+ netif_info(pd, probe, pd->dev, "PHY addr %d, phy_id 0x%08X\n",
+ phydev->addr, phydev->phy_id);
phydev = phy_connect(dev, dev_name(&phydev->dev),
smsc9420_phy_adjust_link, PHY_INTERFACE_MODE_MII);
@@ -1223,12 +1215,12 @@ static int smsc9420_mii_init(struct net_device *dev)
pd->mii_bus->phy_mask = ~(1 << 1);
if (mdiobus_register(pd->mii_bus)) {
- smsc_warn(PROBE, "Error registering mii bus");
+ netif_warn(pd, probe, pd->dev, "Error registering mii bus\n");
goto err_out_free_bus_2;
}
if (smsc9420_mii_probe(dev) < 0) {
- smsc_warn(PROBE, "Error probing mii bus");
+ netif_warn(pd, probe, pd->dev, "Error probing mii bus\n");
goto err_out_unregister_bus_3;
}
@@ -1281,12 +1273,11 @@ static int smsc9420_alloc_rx_ring(struct smsc9420_pdata *pd)
BUG_ON(!pd->rx_ring);
- pd->rx_buffers = kmalloc((sizeof(struct smsc9420_ring_info) *
- RX_RING_SIZE), GFP_KERNEL);
- if (pd->rx_buffers == NULL) {
- smsc_warn(IFUP, "Failed to allocated rx_buffers");
+ pd->rx_buffers = kmalloc_array(RX_RING_SIZE,
+ sizeof(struct smsc9420_ring_info),
+ GFP_KERNEL);
+ if (pd->rx_buffers == NULL)
goto out;
- }
/* initialize the rx ring */
for (i = 0; i < RX_RING_SIZE; i++) {
@@ -1301,7 +1292,8 @@ static int smsc9420_alloc_rx_ring(struct smsc9420_pdata *pd)
/* now allocate the entire ring of skbs */
for (i = 0; i < RX_RING_SIZE; i++) {
if (smsc9420_alloc_rx_buffer(pd, i)) {
- smsc_warn(IFUP, "failed to allocate rx skb %d", i);
+ netif_warn(pd, ifup, pd->dev,
+ "failed to allocate rx skb %d\n", i);
goto out_free_rx_skbs;
}
}
@@ -1310,13 +1302,14 @@ static int smsc9420_alloc_rx_ring(struct smsc9420_pdata *pd)
pd->rx_ring_tail = 0;
smsc9420_reg_write(pd, VLAN1, ETH_P_8021Q);
- smsc_dbg(IFUP, "VLAN1 = 0x%08x", smsc9420_reg_read(pd, VLAN1));
+ netif_dbg(pd, ifup, pd->dev, "VLAN1 = 0x%08x\n",
+ smsc9420_reg_read(pd, VLAN1));
if (pd->rx_csum) {
/* Enable RX COE */
u32 coe = smsc9420_reg_read(pd, COE_CR) | RX_COE_EN;
smsc9420_reg_write(pd, COE_CR, coe);
- smsc_dbg(IFUP, "COE_CR = 0x%08x", coe);
+ netif_dbg(pd, ifup, pd->dev, "COE_CR = 0x%08x\n", coe);
}
smsc9420_reg_write(pd, RX_BASE_ADDR, pd->rx_dma_addr);
@@ -1339,7 +1332,8 @@ static int smsc9420_open(struct net_device *dev)
int result = 0, timeout;
if (!is_valid_ether_addr(dev->dev_addr)) {
- smsc_warn(IFUP, "dev_addr is not a valid MAC address");
+ netif_warn(pd, ifup, pd->dev,
+ "dev_addr is not a valid MAC address\n");
result = -EADDRNOTAVAIL;
goto out_0;
}
@@ -1358,7 +1352,7 @@ static int smsc9420_open(struct net_device *dev)
result = request_irq(irq, smsc9420_isr, IRQF_SHARED, DRV_NAME, pd);
if (result) {
- smsc_warn(IFUP, "Unable to use IRQ = %d", irq);
+ netif_warn(pd, ifup, pd->dev, "Unable to use IRQ = %d\n", irq);
result = -ENODEV;
goto out_0;
}
@@ -1393,7 +1387,7 @@ static int smsc9420_open(struct net_device *dev)
smsc9420_pci_flush_write(pd);
/* test the IRQ connection to the ISR */
- smsc_dbg(IFUP, "Testing ISR using IRQ %d", irq);
+ netif_dbg(pd, ifup, pd->dev, "Testing ISR using IRQ %d\n", irq);
pd->software_irq_signal = false;
spin_lock_irqsave(&pd->int_lock, flags);
@@ -1423,30 +1417,32 @@ static int smsc9420_open(struct net_device *dev)
spin_unlock_irqrestore(&pd->int_lock, flags);
if (!pd->software_irq_signal) {
- smsc_warn(IFUP, "ISR failed signaling test");
+ netif_warn(pd, ifup, pd->dev, "ISR failed signaling test\n");
result = -ENODEV;
goto out_free_irq_1;
}
- smsc_dbg(IFUP, "ISR passed test using IRQ %d", irq);
+ netif_dbg(pd, ifup, pd->dev, "ISR passed test using IRQ %d\n", irq);
result = smsc9420_alloc_tx_ring(pd);
if (result) {
- smsc_warn(IFUP, "Failed to Initialize tx dma ring");
+ netif_warn(pd, ifup, pd->dev,
+ "Failed to Initialize tx dma ring\n");
result = -ENOMEM;
goto out_free_irq_1;
}
result = smsc9420_alloc_rx_ring(pd);
if (result) {
- smsc_warn(IFUP, "Failed to Initialize rx dma ring");
+ netif_warn(pd, ifup, pd->dev,
+ "Failed to Initialize rx dma ring\n");
result = -ENOMEM;
goto out_free_tx_ring_2;
}
result = smsc9420_mii_init(dev);
if (result) {
- smsc_warn(IFUP, "Failed to initialize Phy");
+ netif_warn(pd, ifup, pd->dev, "Failed to initialize Phy\n");
result = -ENODEV;
goto out_free_rx_ring_3;
}
@@ -1547,7 +1543,8 @@ static int smsc9420_resume(struct pci_dev *pdev)
err = pci_enable_wake(pdev, 0, 0);
if (err)
- smsc_warn(IFUP, "pci_enable_wake failed: %d", err);
+ netif_warn(pd, ifup, pd->dev, "pci_enable_wake failed: %d\n",
+ err);
if (netif_running(dev)) {
/* FIXME: gross. It looks like ancient PM relic.*/
@@ -1582,7 +1579,7 @@ smsc9420_probe(struct pci_dev *pdev, const struct pci_device_id *id)
int result = 0;
u32 id_rev;
- pr_info(DRV_DESCRIPTION " version " DRV_VERSION "\n");
+ pr_info("%s version %s\n", DRV_DESCRIPTION, DRV_VERSION);
/* First do the PCI initialisation */
result = pci_enable_device(pdev);
@@ -1605,19 +1602,19 @@ smsc9420_probe(struct pci_dev *pdev, const struct pci_device_id *id)
}
if ((pci_request_regions(pdev, DRV_NAME))) {
- netdev_err(dev, "Cannot obtain PCI resources, aborting.\n");
+ netdev_err(dev, "Cannot obtain PCI resources, aborting\n");
goto out_free_netdev_2;
}
if (pci_set_dma_mask(pdev, DMA_BIT_MASK(32))) {
- netdev_err(dev, "No usable DMA configuration, aborting.\n");
+ netdev_err(dev, "No usable DMA configuration, aborting\n");
goto out_free_regions_3;
}
virt_addr = ioremap(pci_resource_start(pdev, SMSC_BAR),
pci_resource_len(pdev, SMSC_BAR));
if (!virt_addr) {
- netdev_err(dev, "Cannot map device registers, aborting.\n");
+ netdev_err(dev, "Cannot map device registers, aborting\n");
goto out_free_regions_3;
}
@@ -1646,16 +1643,17 @@ smsc9420_probe(struct pci_dev *pdev, const struct pci_device_id *id)
pd->msg_enable = smsc_debug;
pd->rx_csum = true;
- smsc_dbg(PROBE, "lan_base=0x%08lx", (ulong)virt_addr);
+ netif_dbg(pd, probe, pd->dev, "lan_base=0x%08lx\n", (ulong)virt_addr);
id_rev = smsc9420_reg_read(pd, ID_REV);
switch (id_rev & 0xFFFF0000) {
case 0x94200000:
- smsc_info(PROBE, "LAN9420 identified, ID_REV=0x%08X", id_rev);
+ netif_info(pd, probe, pd->dev,
+ "LAN9420 identified, ID_REV=0x%08X\n", id_rev);
break;
default:
- smsc_warn(PROBE, "LAN9420 NOT identified");
- smsc_warn(PROBE, "ID_REV=0x%08X", id_rev);
+ netif_warn(pd, probe, pd->dev, "LAN9420 NOT identified\n");
+ netif_warn(pd, probe, pd->dev, "ID_REV=0x%08X\n", id_rev);
goto out_free_dmadesc_5;
}
@@ -1670,7 +1668,8 @@ smsc9420_probe(struct pci_dev *pdev, const struct pci_device_id *id)
result = register_netdev(dev);
if (result) {
- smsc_warn(PROBE, "error %i registering device", result);
+ netif_warn(pd, probe, pd->dev, "error %i registering device\n",
+ result);
goto out_free_dmadesc_5;
}
^ permalink raw reply related
* Re: [PATCH 3/7] IBM Akebono: Add support for a new PHY to the IBM emac driver
From: Florian Fainelli @ 2013-11-05 18:47 UTC (permalink / raw)
To: Alistair Popple; +Cc: linuxppc-dev, David S. Miller, netdev
In-Reply-To: <1383629471-16979-3-git-send-email-alistair@popple.id.au>
[snip]
> +/* RGMII bridge supports only GMII/TBI and RGMII/RTBI PHYs */
> +static inline int rgmii_valid_mode(int phy_mode)
> +{
> + return phy_mode == PHY_MODE_GMII ||
> + phy_mode == PHY_MODE_MII ||
> + phy_mode == PHY_MODE_RGMII ||
> + phy_mode == PHY_MODE_TBI ||
> + phy_mode == PHY_MODE_RTBI;
> +}
> +
> +static inline const char *rgmii_mode_name(int mode)
> +{
> + switch (mode) {
> + case PHY_MODE_RGMII:
> + return "RGMII";
> + case PHY_MODE_TBI:
> + return "TBI";
> + case PHY_MODE_GMII:
> + return "GMII";
> + case PHY_MODE_MII:
> + return "MII";
> + case PHY_MODE_RTBI:
> + return "RTBI";
> + default:
> + BUG();
> + }
Any reasons why you are duplicating what is available in
drivers/of/of_net.c ::of_get_phy_mode()?
--
Florian
^ permalink raw reply
* Re: [PATCH net-next v2] ipv6: remove old conditions on flow label sharing
From: David Miller @ 2013-11-05 19:41 UTC (permalink / raw)
To: florent.fourcot; +Cc: netdev
In-Reply-To: <1383400507-12604-1-git-send-email-florent.fourcot@enst-bretagne.fr>
From: Florent Fourcot <florent.fourcot@enst-bretagne.fr>
Date: Sat, 2 Nov 2013 14:55:07 +0100
> The code of flow label in Linux Kernel follows
> the rules of RFC 1809 (an informational one) for
> conditions on flow label sharing. There rules are
> not in the last proposed standard for flow label
> (RFC 6437), or in the previous one (RFC 3697).
>
> Since this code does not follow any current or
> old standard, we can remove it.
>
> With this removal, the ipv6_opt_cmp function is
> now a dead code and it can be removed too.
>
> Changelog to v1:
> * add justification for the change
> * remove the condition on IPv6 options
>
> Signed-off-by: Florent Fourcot <florent.fourcot@enst-bretagne.fr>
Applied, but I had to also remove ipv6_hdr_cmp() as that became unused
as well.
Thanks.
^ permalink raw reply
* Re: [PATCH 3/7] IBM Akebono: Add support for a new PHY to the IBM emac driver
From: Benjamin Herrenschmidt @ 2013-11-05 19:54 UTC (permalink / raw)
To: Ben Hutchings; +Cc: Alistair Popple, netdev, linuxppc-dev, David S. Miller
In-Reply-To: <1383675404.2868.8.camel@bwh-desktop.uk.level5networks.com>
On Tue, 2013-11-05 at 18:16 +0000, Ben Hutchings wrote:
> On Tue, 2013-11-05 at 16:31 +1100, Alistair Popple wrote:
> [...]
> > --- a/drivers/net/ethernet/ibm/emac/Kconfig
> > +++ b/drivers/net/ethernet/ibm/emac/Kconfig
> > @@ -55,6 +55,10 @@ config IBM_EMAC_RGMII
> > bool
> > default n
> >
> > +config IBM_EMAC_RGMII_WOL
> > + bool
> > + default n
> > +
> [...]
>
> So no-one can even build-test this at present!
Patch 7/7 adds the select to the platform, isn't that sufficient ?
It's an SoC bit so there's little point making it generally
selectable by the user.
Alistair: The commit name should be different, it's not a PHY you are
adding, it's a PHY interface (the PHY itself is off chip).
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] sh_eth: call phy_scan_fixups() after PHY reset
From: David Miller @ 2013-11-05 20:01 UTC (permalink / raw)
To: sergei.shtylyov
Cc: nobuhiro.iwamatsu.yj, netdev, linux-sh, laurent.pinchart+renesas
In-Reply-To: <52795282.20708@cogentembedded.com>
From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Date: Tue, 05 Nov 2013 23:18:10 +0300
> David, will you ever reply to this mail?
I really haven't had the time with my backlog, and it's been so long ago
that I've forgotten all of the context.
Sorry, someone will have to start the conversation up anew.
^ permalink raw reply
* Re: [PATCH] sh_eth: call phy_scan_fixups() after PHY reset
From: Sergei Shtylyov @ 2013-11-05 20:18 UTC (permalink / raw)
To: David Miller
Cc: nobuhiro.iwamatsu.yj, netdev, linux-sh, laurent.pinchart+renesas
In-Reply-To: <5271712A.6020105@cogentembedded.com>
Hello.
On 10/30/2013 11:50 PM, Sergei Shtylyov wrote:
>>>> Sometimes the PHY reset that sh_eth_phy_start() does effects the PHY
>>>> registers
>>>> registers values of which are vital for the correct functioning of the
>>>> driver.
>>>> Unfortunately, the existing PHY platform fixup mechanism doesn't help
>>>> here as
>>>> it only hooks PHY resets done by ioctl() calls. Calling phy_scan_fixups()
>>>> from
>>>> the driver helps here. With a proper platform fixup, this fixes NFS
>>>> timeouts on
>>>> the SH-Mobile Lager board.
> Timeouts happen because of the sideband ETH_LINK signal connected to PHY's
> LED0 pin -- it bounces on/off after each packet in the default LED mode and
> that seems to hinder packet sending and/or reception...
>> "And sets the PHY LED pins to the desired mode", I should have added.
>>>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>>> The PHY layer is designed to naturally already take care of this kind of
>>> thing. I think that part of the problem is that you're fighting the
>>> natural control flow the PHY layer provides.
>>> When the phy_connect() is performed, what we end up doing is calling
>>> phy_attach_direct() which invokes the ->probe() method of the driver
>>> and then afterwards we do phy_init_hw() which takes care of doing
>>> the fixup calls.
>> Yes, I have studied the code paths beforehand.
>>> So if you really need to do a BMCR reset then run the fixups I'd like
>>> you to look into making that happen within the provided control
>>> flow rather than with an exceptional explicit call to run the fixups.
>> That could change the behavior of many Ethernet drivers in sometimes
>> unpredictable ways I think (due to extended registers the PHYs sometimes have,
>> like in this case) if you meant including the PHY reset into phylib control
>> flows. Anyway, that would have required more complex patches only good for
>> merging at the merge window time while I aimed at a quick fix for a problem at
>> hand (which is NFS timeout/slowdown and LED mode mismatch to what was designed
>> for the board).
>> Some other drivers also do reset the PHYs but usually that's accompanied
>> by a loop polling for reset completion, so a naive code like that one on the
>> phylib's ioctl() path couldn't have helped if I wanted to hook reset writes in
>> the same fashion in phy_write(). In my case reset seems just quick enough for
>> the extended PHY register reads/writes to work correctly without polling the
>> reset bit first...
>> That's why I took an easy way and used already exported phy_scan_fixups()
>> to undo what the PHY reset did to some of the PHY's registers. The question is
>> why it was exported in the first place? It doesn't seem to be used by anything
>> but phylib internally...
> Well, how about I create phy_reset() function (that will care about BMCR
> polling and calling PHY driver/fixups) that those drivers that currently do
> reset their PHYs can call (instead of open coding BMCR reset)? That way it
> seems to be less invasive than embedding PHY reset into phylib's control flow...
>>> I'm willing to be convinced that this is a better or necessary approach
>>> but you'll need to explain it to me.
David, will you ever reply to this mail?
WBR, Sergei
^ permalink raw reply
* Re: [PATCH net-next v6 0/3] The huawei_cdc_ncm driver
From: David Miller @ 2013-11-05 20:22 UTC (permalink / raw)
To: bjorn; +Cc: netdev, linux-usb, mrkiko.rs, oliver
In-Reply-To: <1383555049-24834-1-git-send-email-bjorn@mork.no>
From: Bjørn Mork <bjorn@mork.no>
Date: Mon, 4 Nov 2013 09:50:46 +0100
> Enrico has been kind enough to let me repost his driver with the changes
> requested by Oliver Neukum during the last review of this series.
>
> The changes I have made from Enricos original v5 series to this version
> are:
>
> v6:
> - fix to avoid corrupting drvstate->pmcount
> - fix error return value from huawei_cdc_ncm_suspend()
> - drop redundant testing for subdriver->suspend during resume
> - broke a few lines to keep within the 80 columns recommendation
> - rebased on top of current net-next
>
> Enrico's orginal introduction to the v5 series follows below. It explains
> the background much better than I can.
Looks good, series applied, thanks!
^ permalink raw reply
* Re: [PATCH v2 2/2] ixgbe: enable l2 forwarding acceleration for macvlans
From: John Fastabend @ 2013-11-05 20:34 UTC (permalink / raw)
To: Neil Horman; +Cc: alexander.h.duyck, netdev, andy, davem, jeffrey.t.kirsher
In-Reply-To: <20131105142631.GB14954@hmsreliant.think-freely.org>
On 11/5/2013 6:26 AM, Neil Horman wrote:
> On Mon, Nov 04, 2013 at 11:01:55AM -0800, John Fastabend wrote:
>> Now that l2 acceleration ops are in place from the prior patch,
>> enable ixgbe to take advantage of these operations. Allow it to
>> allocate queues for a macvlan so that when we transmit a frame,
>> we can do the switching in hardware inside the ixgbe card, rather
>> than in software.
>>
>> For now this patch limits the hardware to 8 offloaded macvlan ports.
>> A follow on patch will remove this limitation but to simplify
>> review/validation of the new macvlan offload ops we leave it at 8
>> for now.
>>
>> Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
>> CC: Andy Gospodarek <andy@greyhouse.net>
>> CC: "David S. Miller" <davem@davemloft.net>
>
> A few Nits, since you're going to send a V3 anyway. Comments inline.
>
>> ---
[...]
> Nit: You're using macvlan here, and vsi above. Might be nice to give everything
> a consistent suffix/prefix for clarity. Perhaps dfwd since thats what the new
> ndo_ops uses?
>
using dfwd now.
>> <snip>
>
>> static inline bool ixgbe_is_sfp(struct ixgbe_hw *hw)
>> @@ -4317,6 +4521,8 @@ static void ixgbe_setup_gpie(struct ixgbe_adapter *adapter)
>> static void ixgbe_up_complete(struct ixgbe_adapter *adapter)
>> {
>> struct ixgbe_hw *hw = &adapter->hw;
>> + struct net_device *upper;
>> + struct list_head *iter;
>> int err;
>> u32 ctrl_ext;
>>
>> @@ -4360,6 +4566,16 @@ static void ixgbe_up_complete(struct ixgbe_adapter *adapter)
>> /* enable transmits */
>> netif_tx_start_all_queues(adapter->netdev);
>>
>> + /* enable any upper devices */
>> + netdev_for_each_all_upper_dev_rcu(adapter->netdev, upper, iter) {
>> + if (netif_is_macvlan(upper)) {
>> + struct macvlan_dev *vlan = netdev_priv(upper);
>> +
>> + if (vlan->fwd_priv)
>> + netif_tx_start_all_queues(upper);
>> + }
>> + }
>> +
> I don't think it matters much, but do we want to start the upper devs queues
> here unilaterally? Nominally a network interface starts its queues on dev_open.
> Would it be better to only start those devices if (vlan->fwd_priv &&
> (upper->flags & IFF_UP)? We would then have to listen for NETDEV_UP events as
> well to handle accelerated macvlans comming up after ixgbe does, which is more
> work, but I wanted to mention this in case theres some disadvantage to starting
> the queue early.
>
vlan->fwd_priv is set in macvlan_open() and cleared in macvlan_close()
and serialized with the rtnl lock. So I think anytime you get here and
have vlan->fwd_priv non-null its the same as IFF_UP being set.
The only call sites I see changing the IFF_UP flag are dev_open() and
dev_close() and derivatives. Each calls ndo_open and ndo_close. So
assuming I didn't miss some call sites the above seems correct.
>
> Other than that I think it looks good though. Nice work!
>
Great thanks for looking it over. I should have v3 out here shortly
doing a couple more tests for feature interop.
> Regards
> Neil
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* [PATCH] wcn36xx: Fix logging macro with unnecessary semicolon
From: Joe Perches @ 2013-11-05 20:40 UTC (permalink / raw)
To: Eugene Krasnikov
Cc: John W. Linville, wcn36xx-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
The wcn36xx_err macro should not end in a semicolon as
there are 2 consecutive semicolons in the preprocessed
output.
Remove it.
Neaten the logging macros to use a more common style.
Convert to use pr_debug to enable dynamic debug.
Signed-off-by: Joe Perches <joe-6d6DIl74uiNBDgjK7y7TUQ@public.gmane.org>
---
drivers/net/wireless/ath/wcn36xx/wcn36xx.h | 28 +++++++++++++---------------
1 file changed, 13 insertions(+), 15 deletions(-)
diff --git a/drivers/net/wireless/ath/wcn36xx/wcn36xx.h b/drivers/net/wireless/ath/wcn36xx/wcn36xx.h
index 58b6383..d157bb7 100644
--- a/drivers/net/wireless/ath/wcn36xx/wcn36xx.h
+++ b/drivers/net/wireless/ath/wcn36xx/wcn36xx.h
@@ -53,22 +53,20 @@ enum wcn36xx_debug_mask {
WCN36XX_DBG_ANY = 0xffffffff,
};
-#define wcn36xx_err(fmt, arg...) \
- printk(KERN_ERR pr_fmt("ERROR " fmt), ##arg);
-
-#define wcn36xx_warn(fmt, arg...) \
- printk(KERN_WARNING pr_fmt("WARNING " fmt), ##arg)
-
-#define wcn36xx_info(fmt, arg...) \
- printk(KERN_INFO pr_fmt(fmt), ##arg)
-
-#define wcn36xx_dbg(mask, fmt, arg...) do { \
- if (wcn36xx_dbg_mask & mask) \
- printk(KERN_DEBUG pr_fmt(fmt), ##arg); \
+#define wcn36xx_err(fmt, ...) \
+ pr_err("ERROR " fmt, ##__VA_ARGS__)
+#define wcn36xx_warn(fmt, ...) \
+ pr_warn("WARNING " fmt, ##__VA_ARGS__)
+#define wcn36xx_info(fmt, ...) \
+ pr_info(fmt, ##__VA_ARGS__)
+#define wcn36xx_dbg(mask, fmt, ...) \
+do { \
+ if (wcn36xx_dbg_mask & mask) \
+ pr_debug(fmt, ##__VA_ARGS__); \
} while (0)
^ permalink raw reply related
* Re: [PATCH v2 2/2] ixgbe: enable l2 forwarding acceleration for macvlans
From: Neil Horman @ 2013-11-05 20:52 UTC (permalink / raw)
To: John Fastabend; +Cc: alexander.h.duyck, netdev, andy, davem, jeffrey.t.kirsher
In-Reply-To: <5279566E.6030807@intel.com>
On Tue, Nov 05, 2013 at 12:34:54PM -0800, John Fastabend wrote:
> On 11/5/2013 6:26 AM, Neil Horman wrote:
> >On Mon, Nov 04, 2013 at 11:01:55AM -0800, John Fastabend wrote:
> >>Now that l2 acceleration ops are in place from the prior patch,
> >>enable ixgbe to take advantage of these operations. Allow it to
> >>allocate queues for a macvlan so that when we transmit a frame,
> >>we can do the switching in hardware inside the ixgbe card, rather
> >>than in software.
> >>
> >>For now this patch limits the hardware to 8 offloaded macvlan ports.
> >>A follow on patch will remove this limitation but to simplify
> >>review/validation of the new macvlan offload ops we leave it at 8
> >>for now.
> >>
> >>Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
> >>CC: Andy Gospodarek <andy@greyhouse.net>
> >>CC: "David S. Miller" <davem@davemloft.net>
> >
> >A few Nits, since you're going to send a V3 anyway. Comments inline.
> >
> >>---
>
>
> [...]
>
> >Nit: You're using macvlan here, and vsi above. Might be nice to give everything
> >a consistent suffix/prefix for clarity. Perhaps dfwd since thats what the new
> >ndo_ops uses?
> >
>
> using dfwd now.
>
> >><snip>
> >
> >> static inline bool ixgbe_is_sfp(struct ixgbe_hw *hw)
> >>@@ -4317,6 +4521,8 @@ static void ixgbe_setup_gpie(struct ixgbe_adapter *adapter)
> >> static void ixgbe_up_complete(struct ixgbe_adapter *adapter)
> >> {
> >> struct ixgbe_hw *hw = &adapter->hw;
> >>+ struct net_device *upper;
> >>+ struct list_head *iter;
> >> int err;
> >> u32 ctrl_ext;
> >>
> >>@@ -4360,6 +4566,16 @@ static void ixgbe_up_complete(struct ixgbe_adapter *adapter)
> >> /* enable transmits */
> >> netif_tx_start_all_queues(adapter->netdev);
> >>
> >>+ /* enable any upper devices */
> >>+ netdev_for_each_all_upper_dev_rcu(adapter->netdev, upper, iter) {
> >>+ if (netif_is_macvlan(upper)) {
> >>+ struct macvlan_dev *vlan = netdev_priv(upper);
> >>+
> >>+ if (vlan->fwd_priv)
> >>+ netif_tx_start_all_queues(upper);
> >>+ }
> >>+ }
> >>+
> >I don't think it matters much, but do we want to start the upper devs queues
> >here unilaterally? Nominally a network interface starts its queues on dev_open.
> >Would it be better to only start those devices if (vlan->fwd_priv &&
> >(upper->flags & IFF_UP)? We would then have to listen for NETDEV_UP events as
> >well to handle accelerated macvlans comming up after ixgbe does, which is more
> >work, but I wanted to mention this in case theres some disadvantage to starting
> >the queue early.
> >
>
> vlan->fwd_priv is set in macvlan_open() and cleared in macvlan_close()
> and serialized with the rtnl lock. So I think anytime you get here and
> have vlan->fwd_priv non-null its the same as IFF_UP being set.
>
> The only call sites I see changing the IFF_UP flag are dev_open() and
> dev_close() and derivatives. Each calls ndo_open and ndo_close. So
> assuming I didn't miss some call sites the above seems correct.
>
> >
> >Other than that I think it looks good though. Nice work!
> >
>
> Great thanks for looking it over. I should have v3 out here shortly
> doing a couple more tests for feature interop.
>
Copy that, I'll sign off on that version
Neil
> >Regards
> >Neil
> >
> >--
> >To unsubscribe from this list: send the line "unsubscribe netdev" in
> >the body of a message to majordomo@vger.kernel.org
> >More majordomo info at http://vger.kernel.org/majordomo-info.html
> >
>
>
^ permalink raw reply
* Re: [patch net-next 2/3] netfilter: ip6_tables: use reasm skb for matching
From: Jiri Pirko @ 2013-11-05 20:55 UTC (permalink / raw)
To: Patrick McHardy
Cc: Florian Westphal, netdev, davem, pablo, netfilter-devel, yoshfuji,
kadlec, mleitner, kuznet, jmorris, wensong, horms, ja, edumazet,
pshelar, jasowang, alexander.h.duyck, coreteam
In-Reply-To: <20131105181633.GA7435@macbook.localnet>
Tue, Nov 05, 2013 at 07:16:33PM CET, kaber@trash.net wrote:
>On Tue, Nov 05, 2013 at 04:01:15PM +0100, Jiri Pirko wrote:
>> Tue, Nov 05, 2013 at 02:41:19PM CET, kaber@trash.net wrote:
>> >On Tue, Nov 05, 2013 at 02:32:05PM +0100, Florian Westphal wrote:
>> >> Jiri Pirko <jiri@resnulli.us> wrote:
>> >> > This patch fixes for example following situation:
>> >> > On HOSTA do:
>> >> > ip6tables -I INPUT -p icmpv6 -j DROP
>> >> > ip6tables -I INPUT -p icmpv6 -m icmp6 --icmpv6-type 128 -j ACCEPT
>> >>
>> >> untested:
>> >>
>> >> -A INPUT -p icmpv6 -m icmp6 --icmpv6-type 128 -j ACCEPT
>> >> -A INPUT -p icmpv6 -m conntrack --ctstatus CONFIRMED -j ACCEPT
>> >> -A INPUT -p icmpv6 -j DROP
>> >>
>> >> > and on HOSTB you do:
>> >> > ping6 HOSTA -s2000 (MTU is 1500)
>> >> >
>> >> > Incoming echo requests will be filtered out on HOSTA. This issue does
>> >> > not occur with smaller packets than MTU (where fragmentation does not happen).
>> >>
>> >> Patrick, any reason not to kill the special-casing (ct has assigned helper or
>> >> unconfirmed conntrack) in __ipv6_conntrack_in() ?
>> >>
>> >> This should make ipv6 frag behaviour consistent; right now its rather
>> >> confusing from ruleset point of view, especially the first packet
>> >> of a connection is always seen as reassembled.
>> >>
>> >> So with Jiris rules
>> >>
>> >> -A INPUT -p icmpv6 -m icmp6 --icmpv6-type 128 -j ACCEPT
>> >> -A INPUT -p icmpv6 -j DROP
>> >>
>> >> ping6 -s $bignum works for the first packet but not for subsequent ones
>> >> which is quite irritating.
>> >
>> >Well, the reason was to avoid unnecessary work doing refragmentation
>> >unless really required. I know its rather complicated, but IPv6 has
>> >always required treating fragments manually or using conntrack state.
>> >
>> >I'm not objecting to changing this, but the patches as they are are
>> >not the way to go. First, moving nfct_frag to struct sk_buff seems
>>
>> I'm a bit lost. What "nfct_frag" are you reffering to here?
>
>I meant nfct_reasm of course.
The patch is not moving this to struct sk_buff. It is already there.
>
>> >like a real waste of space for this quite rare case. Also, we can't
>> >just use the reassembled packet in ip6tables, when modifying it we
>> >will still output the unchanged fragments. An last of all, we'll be
>> >executing the rules on the reassembled packet multiple times, one
>> >for each fragment.
>>
>> Reassembled skb would be only used for matching where no changes takes
>> place.
>
>That still doesn't work, our matches are not purely passive.
>
>> End even though, the matching is now done for each fragment skb anyway. The
>> change is only to do it on different skb. I see no erformance or any
>> other problem in that.
>
>Accounting, quota, statistic, limit, ... come to mind. Basically any
>match that keeps state.
Ok. Makes sense.
>
>> >So if someone wants to change this, simply *only* pass the reassembled
>> >packet through the netfilter hooks and drop the fragments, as in IPv4.
>>
>> This is unfortunatelly not possible because in forwarding use case, the
>> fragments have to be send out as they come in.
>
>No, the IPv6 NAT patches fixed that, we still do proper refragmentation
>and we still respect the original fragment sizes, thus are not responsible
>for potentially exceeding the PMTU on the following path.
Ok. So the plan is to remove net/ipv6/netfilter/nf_conntrack_reasm.c
code entirely and use net/ipv6/reassembly.c code directly from
nf_defrag_ipv6. This would result in very similar code currently ipv4
has.
^ permalink raw reply
* Re: [patch v2] mlx5_core: delete some dead code
From: David Miller @ 2013-11-05 20:51 UTC (permalink / raw)
To: dan.carpenter; +Cc: eli, netdev, linux-rdma, kernel-janitors
In-Reply-To: <20131104222056.GA4248@elgon.mountain>
From: Dan Carpenter <dan.carpenter@oracle.com>
Date: Tue, 5 Nov 2013 01:20:56 +0300
> The printk() looks like it is left over debug code. I have removed it.
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
> ---
> v2: Remove the printk instead of moving it infront of the return.
This doesn't apply to the current tree, I suspect some recent changes made
this fix no longer applicable. Please take a look.
Thanks!
^ permalink raw reply
* Re: [patch net-next] ipv6: allow userspace to create address with IFLA_F_TEMPORARY flag
From: Hannes Frederic Sowa @ 2013-11-05 20:57 UTC (permalink / raw)
To: Nicolas Dichtel
Cc: David Laight, David Miller, jiri, vyasevich, netdev, kuznet,
jmorris, yoshfuji, kaber, thaller, stephen
In-Reply-To: <52792499.3030201@6wind.com>
On Tue, Nov 05, 2013 at 06:02:17PM +0100, Nicolas Dichtel wrote:
> Le 29/10/2013 13:40, Hannes Frederic Sowa a écrit :
> >On Tue, Oct 29, 2013 at 09:37:06AM -0000, David Laight wrote:
> >>>Note that you don't even need to put the DHCP protocol core into the
> >>>kernel to fix the promiscuous problem. You just have to use the
> >>>current kernel interfaces correctly.
> >>>
> >>>It used to be the case a very long time ago that you couldn't even
> >>>receive broadcast UDP datagrams on a socket until an address was
> >>>configured on it.
> >>>
> >>>So everyone turns on promiscuous mode and uses RAW sockets or
> >>>AF_PACKET.
> >>>
> >>>Stupid? yes.
> >>
> >>Not only that, but the dhcp client could use a normal UDP socket
> >>to keep the lease renewed - I suspect it has only ever needed
> >>to use the BPF interface (I didn't think it set promiscuous)
> >>when acquiring the initial lease.
> >
> >Yes, this is a very unfortunate situation. From my experience it is not
> >that
> >easy to get a patch merged into isc-dhcp.
> >
> >It seems not that invasive to switch from af_packet to an udp socket with
> >SO_BROADCAST set.
> If I remember well, another problem is to be able to send these packets with
> 0.0.0.0 when another IP address is available on the system:
>
> RFC2131
> 4.1 Constructing and sending DHCP messages
> ...
> DHCP messages broadcast by a client prior to that client obtaining
> its IP address must have the source address field in the IP header
> set to 0.
>
> We made a patch (never proposed upstream) to add a socket option to keep
> this 0.0.0.0 address.
> If people are interested, I can try to port it on net-next.
Yes, this indeed is a problem for a socket only dhcp client. I would make the
appropriate changes to isc-dhcp if you submit such a patch.
Thanks,
Hannes
^ permalink raw reply
* Re: [patch net-next] ipv6: allow userspace to create address with IFLA_F_TEMPORARY flag
From: Hannes Frederic Sowa @ 2013-11-05 21:11 UTC (permalink / raw)
To: David Laight
Cc: nicolas.dichtel, David Miller, jiri, vyasevich, netdev, kuznet,
jmorris, yoshfuji, kaber, thaller, stephen
In-Reply-To: <AE90C24D6B3A694183C094C60CF0A2F6026B73E2@saturn3.aculab.com>
On Tue, Nov 05, 2013 at 05:12:46PM -0000, David Laight wrote:
> > From: Nicolas Dichtel [mailto:nicolas.dichtel@6wind.com]
> ...
> > If I remember well, another problem is to be able to send these packets with
> > 0.0.0.0 when another IP address is available on the system:
> >
> > RFC2131
> > 4.1 Constructing and sending DHCP messages
> > ...
> > DHCP messages broadcast by a client prior to that client obtaining
> > its IP address must have the source address field in the IP header
> > set to 0.
> >
> > We made a patch (never proposed upstream) to add a socket option to keep
> > this 0.0.0.0 address.
> > If people are interested, I can try to port it on net-next.
>
> Really, what dhcp does before the interface has an address doesn't
> really matter - using bpf isn't a problem.
>
> What it needs to do is switch to using a normal socket for the renewals.
>
> Maybe I'll try asking Roy about it on the NetBSD lists.
I would do the full switch to UDP sockets. It is much easier to accomplish
in the isc-dhcp codebase. It is e.g. already implemented and used e.g. by
Solaris. I would just have to wire up Nicolas INADDR_ANY source patch.
By the way:
Although dhclient uses an AF_PACKET socket, it never does request
additional multicast addresses or promisc mode. So the only overhead is
that we have to run the socket filter on each incoming packet.
Greetings,
Hannes
^ permalink raw reply
* [PATCH 2/3] rtlwifi: rtl8192cu: Fix incorrect signal strength for unassociated AP
From: Larry Finger @ 2013-11-05 21:15 UTC (permalink / raw)
To: linville-2XuSBdqkA4R54TAoqtyWWQ
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA, Larry Finger,
netdev-u79uwXL29TY76Z2rM5mHXA, Stable
In-Reply-To: <1383686130-5113-1-git-send-email-Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
The routine that processes received frames was returning the RSSI value for the
signal strength; however, that value is available only for associated APs. As
a result, the strength was the absurd value of 10 dBm. As a result, scans
return incorrect values for the strength, which causes unwanted attempts to roam.
Signed-off-by: Larry Finger <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
Cc: Stable <stable-u79uwXL29TY76Z2rM5mHXA@public.gmane.org> [2.6.39+]
---
drivers/net/wireless/rtlwifi/rtl8192cu/trx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/rtlwifi/rtl8192cu/trx.c b/drivers/net/wireless/rtlwifi/rtl8192cu/trx.c
index 25e50ff..b0c346a 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192cu/trx.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192cu/trx.c
@@ -349,7 +349,7 @@ bool rtl92cu_rx_query_desc(struct ieee80211_hw *hw,
p_drvinfo);
}
/*rx_status->qual = stats->signal; */
- rx_status->signal = stats->rssi + 10;
+ rx_status->signal = stats->recvsignalpower + 10;
return true;
}
--
1.8.4
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 3/3] rtlwifi: rtl8192de: Fix incorrect signal strength for unassociated AP
From: Larry Finger @ 2013-11-05 21:15 UTC (permalink / raw)
To: linville-2XuSBdqkA4R54TAoqtyWWQ
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA, Larry Finger,
netdev-u79uwXL29TY76Z2rM5mHXA, Stable
In-Reply-To: <1383686130-5113-1-git-send-email-Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
The routine that processes received frames was returning the RSSI value for the
signal strength; however, that value is available only for associated APs. As
a result, the strength was the absurd value of 10 dBm. As a result, scans
return incorrect values for the strength, which causes unwanted attempts to roam.
Signed-off-by: Larry Finger <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
Cc: Stable <stable-u79uwXL29TY76Z2rM5mHXA@public.gmane.org> [3.1+]
---
drivers/net/wireless/rtlwifi/rtl8192de/trx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/rtlwifi/rtl8192de/trx.c b/drivers/net/wireless/rtlwifi/rtl8192de/trx.c
index 945ddec..0eb0f4a 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192de/trx.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192de/trx.c
@@ -525,7 +525,7 @@ bool rtl92de_rx_query_desc(struct ieee80211_hw *hw, struct rtl_stats *stats,
p_drvinfo);
}
/*rx_status->qual = stats->signal; */
- rx_status->signal = stats->rssi + 10;
+ rx_status->signal = stats->recvsignalpower + 10;
return true;
}
--
1.8.4
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 0/3] Fix incorrect returned signal strengths
From: Larry Finger @ 2013-11-05 21:15 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Larry Finger, netdev
In rtl8192se, rtl8192cu, and rtl8192du, the routines that process the
received frames get the signal strength from the RSSI value. Unfortunately,
that value is non-zero only if the interface is associated with the AP. As
a result, scans return incorrect values for the strength, which causes
unwanted attempts to roam.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
---
Larry Finger (3):
rtlwifi: rtl8192se: Fix incorrect signal strength for unassociated AP
rtlwifi: rtl8192cu: Fix incorrect signal strength for unassociated AP
rtlwifi: rtl8192de: Fix incorrect signal strength for unassociated AP
drivers/net/wireless/rtlwifi/rtl8192cu/trx.c | 2 +-
drivers/net/wireless/rtlwifi/rtl8192de/trx.c | 2 +-
drivers/net/wireless/rtlwifi/rtl8192se/trx.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
--
1.8.4
^ permalink raw reply
* [PATCH 1/3] rtlwifi: rtl8192se: Fix incorrect signal strength for unassociated AP
From: Larry Finger @ 2013-11-05 21:15 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Larry Finger, netdev, Stable
In-Reply-To: <1383686130-5113-1-git-send-email-Larry.Finger@lwfinger.net>
The routine that processes received frames was returning the RSSI value for the
signal strength; however, that value is available only for associated APs. As
a result, the strength was the absurd value of 10 dBm. As a result, scans
return incorrect values for the strength, which causes unwanted attempts to roam.
This patch fixes https://bugzilla.kernel.org/show_bug.cgi?id=63881.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Reported-by: Matthieu Baerts <matttbe@gmail.com>
Cc: Stable <stable@vger.kernel.org> [3.0 +]
---
drivers/net/wireless/rtlwifi/rtl8192se/trx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/rtlwifi/rtl8192se/trx.c b/drivers/net/wireless/rtlwifi/rtl8192se/trx.c
index 222d2e7..27efbcd 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192se/trx.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192se/trx.c
@@ -329,7 +329,7 @@ bool rtl92se_rx_query_desc(struct ieee80211_hw *hw, struct rtl_stats *stats,
}
/*rx_status->qual = stats->signal; */
- rx_status->signal = stats->rssi + 10;
+ rx_status->signal = stats->recvsignalpower + 10;
return true;
}
--
1.8.4
^ permalink raw reply related
* Re: [PATCH] ipv6: drop the judgement in rt6_alloc_cow()
From: Hannes Frederic Sowa @ 2013-11-05 21:23 UTC (permalink / raw)
To: Duan Jiong; +Cc: David Miller, netdev
In-Reply-To: <5278837D.7030207@cn.fujitsu.com>
On Tue, Nov 05, 2013 at 01:34:53PM +0800, Duan Jiong wrote:
>
> Now rt6_alloc_cow() is only called by ip6_pol_route() when
> rt->rt6i_flags doesn't contain both RTF_NONEXTHOP and RTF_GATEWAY,
> and rt->rt6i_flags hasn't been changed in ip6_rt_copy().
> So there is no neccessary to judge whether rt->rt6i_flags contains
> RTF_GATEWAY or not.
This is ok.
Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Thanks,
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