* Re: [patch -next] qlcnic: underflow in qlcnic_validate_max_tx_rings()
From: David Miller @ 2013-08-29 5:24 UTC (permalink / raw)
To: dan.carpenter
Cc: himanshu.madhani, rajesh.borundia, shahed.shaikh,
jitendra.kalsaria, sony.chacko, sucheta.chakraborty, linux-driver,
netdev, kernel-janitors
In-Reply-To: <20130827011622.GB17061@elgon.mountain>
From: Dan Carpenter <dan.carpenter@oracle.com>
Date: Tue, 27 Aug 2013 04:16:22 +0300
> This function checks the upper bound but it doesn't check for negative
> numbers:
>
> if (txq > QLCNIC_MAX_TX_RINGS) {
>
> I've solved this by making "txq" a u32 type. I chose that because
> ->tx_count in the ethtool_channels struct is a __u32.
>
> This bug was added in aa4a1f7df7 ('qlcnic: Enable Tx queue changes using
> ethtool for 82xx Series adapter.').
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH v2 net-next 1/2] qlge: Enhance nested VLAN (Q-in-Q) handling.
From: David Miller @ 2013-08-29 5:31 UTC (permalink / raw)
To: jitendra.kalsaria; +Cc: netdev, ron.mercer, Dept_NX_Linux_NIC_Driver
In-Reply-To: <1377751868-1367-2-git-send-email-jitendra.kalsaria@qlogic.com>
From: Jitendra Kalsaria <jitendra.kalsaria@qlogic.com>
Date: Thu, 29 Aug 2013 00:51:07 -0400
> + u16 *tags;
> +
> + if (ib_mac_rsp->flags2 & IB_MAC_IOCB_RSP_V) {
> + tags = (u16 *)page;
> + /* Look for stacked vlan tags in ethertype field */
> + if (tags[6] == htons(ETH_P_8021Q) &&
> + tags[8] == htons(ETH_P_8021Q))
htons() returns a __be16, there is not way that this code doesn't
generate sparse endianness errors.
Also, your change is sacrificing single layered VLAN performance
for the sake of Q-in-Q as far as I can tell. I don't think that's
a very wise tradeoff if so.
^ permalink raw reply
* Re: [PATCH net-next 0/3] pf_packet updates
From: David Miller @ 2013-08-29 5:39 UTC (permalink / raw)
To: dborkman; +Cc: netdev
In-Reply-To: <1377720791-15844-1-git-send-email-dborkman@redhat.com>
From: Daniel Borkmann <dborkman@redhat.com>
Date: Wed, 28 Aug 2013 22:13:08 +0200
> Daniel Borkmann (3):
> net: packet: add random fanout scheduler
> net: packet: use reciprocal_divide in fanout_demux_hash
> net: packet: document available fanout policies
Please add the missing reciprocal_divide.h include to the second
patch, as per Eric Dumazet's feedback, and resubmit this series.
Thanks.
^ permalink raw reply
* Re: pull request: batman-adv 2013-08-28
From: David Miller @ 2013-08-29 5:45 UTC (permalink / raw)
To: ordex-GaUfNO9RBHfsrOwW+9ziJQ
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
b.a.t.m.a.n-ZwoEplunGu2X36UT3dwllkB+6BGkLq7r
In-Reply-To: <1377689291-2412-1-git-send-email-ordex-GaUfNO9RBHfsrOwW+9ziJQ@public.gmane.org>
From: Antonio Quartulli <ordex-GaUfNO9RBHfsrOwW+9ziJQ@public.gmane.org>
Date: Wed, 28 Aug 2013 13:28:07 +0200
> here is a small pull request intended for net-next/linux-3.12.
>
> In this batch you have two really minor things (code rearranging and version
> increment) and two behavioural changes:
> 1) the 'protocol' field of outgoing SKBs is now set according to the type of
> the payload that batman-adv is going to encapsulate;
> 2) a uevent is now sent when a node exits the "GW client" mode. This is done in
> order to tell userspace that a remote "GW server" is not available anymore.
>
> Please pull or let me know of any problem!
Pulled, thanks Antonio.
^ permalink raw reply
* Re: [PATCH net,stable] net: usb: Add HP hs2434 device to ZLP exception table
From: Rob Gardner @ 2013-08-29 5:51 UTC (permalink / raw)
To: David Miller
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, linux-usb-u79uwXL29TY76Z2rM5mHXA,
bjorn-yOkvZcmFvRU, oliver-GvhC2dPhHPQdnm+yROfE0A
In-Reply-To: <20130829.003352.1187611479213752660.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
On Thu, 29 Aug 2013 00:33:52 -0400 (EDT)
David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org> wrote:
> From: Rob Gardner <robmatic-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Date: Wed, 28 Aug 2013 18:40:22 -0600
>
> > The exception list means "usb_device_id entries for specific devices
> > that are known to need the workaround." There are just two such entries.
> > There isn't even a separate list. So maybe we just have a nomenclature
> > problem, and we could simply be calling this a "white list" instead of
> > "exception list". The other possible meaning of whitelist (all devices
> > that *don't* need the workaround) is unthinkable, as that would be a huge
> > list and much more prone to be unmanageable than what we've got now.
>
> Ok I misunderstood. I thought we were discoving that all chips which
> have been thoroughly investigated end up needing the workaround.
>
> I guess it's only a specific family of these chips which seem to all
> have the problem?
Yes. The first one was the Sierra MC7710, and the second is the one
that I discovered, the HP hs2434, which is actually manufactured by
Sierra. So it may be an issue specific to Sierra, but unfortunately the
hs2434 uses HP's manufacturer id (0x3f0) and not Sierra's manufacturer
id (0x1199) so we can't just discriminate based on that.
--
Rob Gardner <robmatic-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" 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
* Re: Pull request: sfc-next 2013-08-28
From: David Miller @ 2013-08-29 5:56 UTC (permalink / raw)
To: bhutchings; +Cc: netdev, linux-net-drivers
In-Reply-To: <1377702837.2264.21.camel@bwh-desktop.uk.level5networks.com>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Wed, 28 Aug 2013 16:13:57 +0100
> 1. Further cleanup and refactoring in preparation for EF10.
> 2. Remove ethtool stats that are always zero on Falcon boards.
> 3. Add an ethtool stat for merged TX completions.
> 4. Prepare to support merged RX completions.
> 5. Prepare to support more hwmon sensors.
> 6. Add support for new events that are generated by EF10 firmware.
> 7. Update MC reboot detection for EF10.
Pulled, thanks Ben.
^ permalink raw reply
* Re: [PATCH net-next 0/3] pf_packet updates
From: Daniel Borkmann @ 2013-08-29 6:20 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Cong Wang
In-Reply-To: <20130829.013938.2144325735677512661.davem@davemloft.net>
On 08/29/2013 07:39 AM, David Miller wrote:
> From: Daniel Borkmann <dborkman@redhat.com>
> Date: Wed, 28 Aug 2013 22:13:08 +0200
>
>> Daniel Borkmann (3):
>> net: packet: add random fanout scheduler
>> net: packet: use reciprocal_divide in fanout_demux_hash
>> net: packet: document available fanout policies
>
> Please add the missing reciprocal_divide.h include to the second
> patch, as per Eric Dumazet's feedback, and resubmit this series.
That is already the case in the first patch of the series. It adds:
...
+#include <linux/reciprocal_div.h>
...
^ permalink raw reply
* Re: [PATCH v5][net-next.git] driver:net:stmmac: Disable DMA store and forward mode if platform data force_thresh_dma_mode is set.
From: Sonic Zhang @ 2013-08-29 6:56 UTC (permalink / raw)
To: Giuseppe CAVALLARO; +Cc: netdev, adi-buildroot-devel, Sonic Zhang
In-Reply-To: <521DE637.6030801@st.com>
Hi Peppe,
When can you send me your fragmented frame patch to solve the tx_coe
problem on Blackfin?
Thanks
Sonic
On Wed, Aug 28, 2013 at 7:59 PM, Giuseppe CAVALLARO
<peppe.cavallaro@st.com> wrote:
> On 8/28/2013 12:55 PM, Sonic Zhang wrote:
>>
>> From: Sonic Zhang <sonic.zhang@analog.com>
>>
>> Some synopsys ip implementation doesn't support DMA store and forward
>> mode,
>> such as BF60x. So, set force_thresh_dma_mode to use DMA thresholds only.
>> Update document and devicetree as well.
>>
>> Signed-off-by: Sonic Zhang <sonic.zhang@analog.com>
>
>
> Acked-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
>
>
>> ---
>> Documentation/devicetree/bindings/net/stmmac.txt | 5 +++++
>> Documentation/networking/stmmac.txt | 3 +++
>> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 4 +++-
>> drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c | 5 +++++
>> include/linux/stmmac.h | 1 +
>> 5 files changed, 17 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/devicetree/bindings/net/stmmac.txt
>> b/Documentation/devicetree/bindings/net/stmmac.txt
>> index 261c563..eba0e5e 100644
>> --- a/Documentation/devicetree/bindings/net/stmmac.txt
>> +++ b/Documentation/devicetree/bindings/net/stmmac.txt
>> @@ -22,6 +22,11 @@ Required properties:
>> - snps,pbl Programmable Burst Length
>> - snps,fixed-burst Program the DMA to use the fixed burst mode
>> - snps,mixed-burst Program the DMA to use the mixed burst mode
>> +- snps,force_thresh_dma_mode Force DMA to use the threshold mode for
>> + both tx and rx
>> +- snps,force_sf_dma_mode Force DMA to use the Store and Forward
>> + mode for both tx and rx. This flag is
>> + ignored if force_thresh_dma_mode is set.
>>
>> Optional properties:
>> - mac-address: 6 bytes, mac address
>> diff --git a/Documentation/networking/stmmac.txt
>> b/Documentation/networking/stmmac.txt
>> index 654d2e5..457b8bb 100644
>> --- a/Documentation/networking/stmmac.txt
>> +++ b/Documentation/networking/stmmac.txt
>> @@ -123,6 +123,7 @@ struct plat_stmmacenet_data {
>> int bugged_jumbo;
>> int pmt;
>> int force_sf_dma_mode;
>> + int force_thresh_dma_mode;
>> int riwt_off;
>> void (*fix_mac_speed)(void *priv, unsigned int speed);
>> void (*bus_setup)(void __iomem *ioaddr);
>> @@ -159,6 +160,8 @@ Where:
>> o pmt: core has the embedded power module (optional).
>> o force_sf_dma_mode: force DMA to use the Store and Forward mode
>> instead of the Threshold.
>> + o force_thresh_dma_mode: force DMA to use the Shreshold mode other than
>> + the Store and Forward mode.
>> o riwt_off: force to disable the RX watchdog feature and switch to NAPI
>> mode.
>> o fix_mac_speed: this callback is used for modifying some syscfg
>> registers
>> (on ST SoCs) according to the link speed negotiated by
>> the
>> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>> b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>> index be40691..8d4ccd3 100644
>> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>> @@ -1224,7 +1224,9 @@ static void free_dma_desc_resources(struct
>> stmmac_priv *priv)
>> */
>> static void stmmac_dma_operation_mode(struct stmmac_priv *priv)
>> {
>> - if (priv->plat->force_sf_dma_mode || priv->plat->tx_coe) {
>> + if (priv->plat->force_thresh_dma_mode)
>> + priv->hw->dma->dma_mode(priv->ioaddr, tc, tc);
>> + else if (priv->plat->force_sf_dma_mode || priv->plat->tx_coe) {
>> /*
>> * In case of GMAC, SF mode can be enabled
>> * to perform the TX COE in HW. This depends on:
>> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
>> b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
>> index da8be6e..74a89a4 100644
>> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
>> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
>> @@ -79,6 +79,11 @@ static int stmmac_probe_config_dt(struct
>> platform_device *pdev,
>> of_property_read_u32(np, "snps,pbl", &dma_cfg->pbl);
>> dma_cfg->fixed_burst = of_property_read_bool(np,
>> "snps,fixed-burst");
>> dma_cfg->mixed_burst = of_property_read_bool(np,
>> "snps,mixed-burst");
>> + plat->force_thresh_dma_mode = of_property_read_bool(np,
>> "snps,force_thresh_dma_mode");
>> + if (plat->force_thresh_dma_mode) {
>> + plat->force_sf_dma_mode = 0;
>> + pr_warn("force_sf_dma_mode is ignored if
>> force_thresh_dma_mode is set.");
>> + }
>>
>> return 0;
>> }
>> diff --git a/include/linux/stmmac.h b/include/linux/stmmac.h
>> index 9e495d31..bb5deb0 100644
>> --- a/include/linux/stmmac.h
>> +++ b/include/linux/stmmac.h
>> @@ -108,6 +108,7 @@ struct plat_stmmacenet_data {
>> int bugged_jumbo;
>> int pmt;
>> int force_sf_dma_mode;
>> + int force_thresh_dma_mode;
>> int riwt_off;
>> void (*fix_mac_speed)(void *priv, unsigned int speed);
>> void (*bus_setup)(void __iomem *ioaddr);
>>
>
^ permalink raw reply
* [iproute2] macvlan: fix typo in macvlan_print_opt()
From: Lutz Jaenicke @ 2013-08-29 7:50 UTC (permalink / raw)
To: netdev; +Cc: Lutz Jaenicke
The mode information is contained in IFLA_MACVLAN_MODE instead
of IFLA_VLAN_ID (both evaluating to "1" in their enums).
Signed-off-by: Lutz Jaenicke <ljaenicke@innominate.com>
---
ip/iplink_macvlan.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/ip/iplink_macvlan.c b/ip/iplink_macvlan.c
index 5b4b868..ec51106 100644
--- a/ip/iplink_macvlan.c
+++ b/ip/iplink_macvlan.c
@@ -79,7 +79,7 @@ static void macvlan_print_opt(struct link_util *lu, FILE *f, struct rtattr *tb[]
RTA_PAYLOAD(tb[IFLA_MACVLAN_MODE]) < sizeof(__u32))
return;
- mode = rta_getattr_u32(tb[IFLA_VLAN_ID]);
+ mode = rta_getattr_u32(tb[IFLA_MACVLAN_MODE]);
fprintf(f, " mode %s ",
mode == MACVLAN_MODE_PRIVATE ? "private"
: mode == MACVLAN_MODE_VEPA ? "vepa"
--
1.7.10.4
^ permalink raw reply related
* Re: [nf-next PATCH] netfilter: Extend SYNPROXY with a --continue option
From: Jesper Dangaard Brouer @ 2013-08-29 8:23 UTC (permalink / raw)
To: Patrick McHardy; +Cc: Pablo Neira Ayuso, netfilter-devel, netdev, mph, as
In-Reply-To: <20130828160038.GA25799@macbook.localnet>
On Wed, 28 Aug 2013 18:00:42 +0200
Patrick McHardy <kaber@trash.net> wrote:
> On Wed, Aug 28, 2013 at 05:26:55PM +0200, Jesper Dangaard Brouer wrote:
> > Packets reaching SYNPROXY are default dropped, as they are most likely
> > invalid (given the state matching). In other configurations it might
> > be beneficial to let packet not consumed by SYNPROXY (SYN and ACK) to
> > continue being processed by the stack.
> >
> > Introducing a --continue option/flag for the SYNPROXY target to allow
> > these unmatched packets to continue being processed. This would also
> > help in debugging the module via LOG.
>
> I don't think we should add an option for this. Just DROP packets consumed
> by the target and have the other ones continue.
I agree. I'll send a new patch, defaulting to XT_CONTINUE.
Self:
Nacked-by: Jesper Dangaard Brouer <brouer@redhat.com>
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Sr. Network Kernel Developer at Red Hat
Author of http://www.iptv-analyzer.org
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* [patch v2] net/fec: cleanup types in fec_get_mac()
From: Dan Carpenter @ 2013-08-29 8:25 UTC (permalink / raw)
To: Grant Likely
Cc: Rob Herring, David S. Miller, Fabio Estevam, Frank Li, Jim Baxter,
Fugang Duan, netdev, Ben Hutchings, devicetree, kernel-janitors
In-Reply-To: <1377261869.3364.3.camel@bwh-desktop.uk.level5networks.com>
My static checker complains that on some arches unsigned longs can be 8
characters which is larger than the buffer is only 6 chars.
Additionally, Ben Hutchings points out that the buffer actually holds
big endian data and the buffer we are reading from is CPU endian.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
---
v2: fix endian annotations and reverse the beXX_to_cpu() calls so that
they say cpu_to_beXX().
diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c
index fdf9307..0b12866 100644
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -1100,10 +1100,10 @@ static void fec_get_mac(struct net_device *ndev)
* 4) FEC mac registers set by bootloader
*/
if (!is_valid_ether_addr(iap)) {
- *((unsigned long *) &tmpaddr[0]) =
- be32_to_cpu(readl(fep->hwp + FEC_ADDR_LOW));
- *((unsigned short *) &tmpaddr[4]) =
- be16_to_cpu(readl(fep->hwp + FEC_ADDR_HIGH) >> 16);
+ *((__be32 *) &tmpaddr[0]) =
+ cpu_to_be32(readl(fep->hwp + FEC_ADDR_LOW));
+ *((__be16 *) &tmpaddr[4]) =
+ cpu_to_be16(readl(fep->hwp + FEC_ADDR_HIGH) >> 16);
iap = &tmpaddr[0];
}
^ permalink raw reply related
* Re: [PATCH net,stable] net: usb: Add HP hs2434 device to ZLP exception table
From: Bjørn Mork @ 2013-08-29 8:32 UTC (permalink / raw)
To: David Miller
Cc: robmatic-Re5JQEeQqe8AvxtiuMwx3w, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA, oliver-GvhC2dPhHPQdnm+yROfE0A
In-Reply-To: <20130829.003352.1187611479213752660.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org> writes:
> From: Rob Gardner <robmatic-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Date: Wed, 28 Aug 2013 18:40:22 -0600
>
>> The exception list means "usb_device_id entries for specific devices
>> that are known to need the workaround." There are just two such entries.
>> There isn't even a separate list. So maybe we just have a nomenclature
>> problem, and we could simply be calling this a "white list" instead of
>> "exception list". The other possible meaning of whitelist (all devices
>> that *don't* need the workaround) is unthinkable, as that would be a huge
>> list and much more prone to be unmanageable than what we've got now.
>
> Ok I misunderstood. I thought we were discoving that all chips which
> have been thoroughly investigated end up needing the workaround.
>
> I guess it's only a specific family of these chips which seem to all
> have the problem?
This driver is a class driver, which means that it deals with a number
of completely independent chip designs from different vendors. We have
so far seen and tested chips from ST-Ericsson, Qualcomm and Mediatek
with this driver. Given that Microsoft requires MBIM, we are likely to
see implementations on all available 3G/LTE chips (if there are any
others?)
Only devices with Qualcomm chips have the bug in question, and so far we
have only observed it in modules made by Sierra Wireless. The firmware
in these modules has a base part made by Qualcomm and an application
part made by Sierra Wireless. We do not know which part of the firmware
is responsible for the bug, but we do know that the Qualcomm base
firmware used by these modules support MBIM framing. Based on this, I
am guessing that the chip vendor Qualcomm is responsible for the bug. If
correct, then the bug is likely to appear in products from many
different module vendors. It would not be the first time we saw that...
I do have a Huawei MBIM device with a Qualcomm chip, but this module
does not have the Qualcomm firmware with MBIM support. The MBIM
implementation is therefore assumed to be made by Huawei and running as
a firmware application on the device. This device does not have the bug.
Now, if we could just identify devices running a Qualcomm base firmware
with MBIM support then we could enable the workaround for all those. But
the driver does not have any way to identify them. It must base its
decision on the USB descriptors, in practice only device ID and product
ID. A module vendor can use chips from different sources (Huawei does
this), and as Rob says: Laptop vendors will often have modules made with
their own vendor ID. Most laptop vendors will also use modules from
different vendors. HP, as a current example, is known to use modules
both from Sierra Wireless (need the workaround) and Ericsson (does not
want the workaround).
This makes any sort of vendor matching difficult, and we end up with
device specific blacklisting or whitelisting as the only option. If it
had been only the two devices we have now, or even only a few tens of
devices, this would not have been a big deal. But I do expect that the
length of this exception list will be comparable to the list of devices
supported by the qmi_wwan driver, i.e. hundreds. And, like that driver,
the list will probably never be complete. Given the difficulties
detecting the need for the workaround, the list is probably going to be
extremely incomplete. Only a small percentage of end users with affected
devices will be able to provide the necessary information.
For the question of the workaround impact on devices without bug: They
will work fine, and the effect will not be user noticable AFAICS. But
it will have a negative impact on the device, most likely causing higher
power consumption. Alexey has explained this much better than I can, as
I do not fully understand the device firmware design and requirements:
http://www.spinics.net/lists/linux-usb/msg78078.html
Quoting part of his explanation (talking about the *device* CPU and
INT - we do not care about the host):
If host decides to send ZLP after full NTB, CPU must handle
additional INT per every full NTB instead of doing useful work.
For FTP transfer with constantly full NTBs you get twice amount of
Interrupts.
I do agree that this is unfortunate. And hurting standard compliant
devices to work around a standard violating bug in other devices does
not feel right. But I do not see any other option.
Bjørn
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" 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
* [patch] mISDN: return -EINVAL on error in dsp_control_req()
From: Dan Carpenter @ 2013-08-29 8:47 UTC (permalink / raw)
To: Karsten Keil
Cc: David S. Miller, Konstantin Khlebnikov, netdev, kernel-janitors
If skb->len is too short then we should return an error. Otherwise we
read beyond the end of skb->data for several bytes.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
diff --git a/drivers/isdn/mISDN/dsp_core.c b/drivers/isdn/mISDN/dsp_core.c
index 22b720e..77025f5 100644
--- a/drivers/isdn/mISDN/dsp_core.c
+++ b/drivers/isdn/mISDN/dsp_core.c
@@ -288,8 +288,10 @@ dsp_control_req(struct dsp *dsp, struct mISDNhead *hh, struct sk_buff *skb)
u8 *data;
int len;
- if (skb->len < sizeof(int))
+ if (skb->len < sizeof(int)) {
printk(KERN_ERR "%s: PH_CONTROL message too short\n", __func__);
+ return -EINVAL;
+ }
cont = *((int *)skb->data);
len = skb->len - sizeof(int);
data = skb->data + sizeof(int);
^ permalink raw reply related
* View the attached file
From: Microsoft Promotion @ 2013-08-29 8:48 UTC (permalink / raw)
In-Reply-To: <1377766100.6238.YahooMailNeo@web5704.biz.mail.ne1.yahoo.com>
[-- Attachment #1: Type: text/plain, Size: 22 bytes --]
View the attached file
[-- Attachment #2: MICROSOFT AWARD PROMOTION.doc --]
[-- Type: application/msword, Size: 109568 bytes --]
^ permalink raw reply
* Question about NBMA tunnels for IPv6
From: Michael Rossberg @ 2013-08-29 9:03 UTC (permalink / raw)
To: netdev
Hi everybody,
Linux offers a so-called NBMA mode for IPv4 tunnels, i.e., one can set the destination
address of a tunnel to 0.0.0.0 and specify the destination on a per packet basis using
the gateway field in routes. For IPv6 tunnels this option seems to be non existing.
Thus, a distinguished tunnel device has to be added for each possible endpoint.
In scenarios with many endpoints this does not scale too well.
Is there any reason for NBMA mode to be not present for v6 (except nobody having
the time to implement it)? If no - is there anything special to look at in order to get
such a feature upstream?
Thanks,
Mick
^ permalink raw reply
* Re: [PATCH stable] ipv6: restrict neighbor entry creation to output flow
From: Jiri Pirko @ 2013-08-29 9:21 UTC (permalink / raw)
To: David Miller; +Cc: ben, netdev, dbanerje, yoshfuji, hannes
In-Reply-To: <20130828141231.GB12353@order.stressinduktion.org>
Wed, Aug 28, 2013 at 04:12:31PM CEST, hannes@stressinduktion.org wrote:
>On Wed, Aug 28, 2013 at 04:09:58PM +0200, Jiri Pirko wrote:
>> Dave, is it possible to see the queue somewhere?
>
>Here: <http://patchwork.ozlabs.org/bundle/davem/stable/?state=*>
>
>Greetings,
>
> Hannes
>
Great. Thanks.
ccing Ben.
Dave, Ben told me he did not receive this patch from you yet and
told me to bug you. So I'm doing that :)
Thanks
Jiri
^ permalink raw reply
* [nf-next PATCH] netfilter: SYNPROXY let unrelated packets continue
From: Jesper Dangaard Brouer @ 2013-08-29 10:18 UTC (permalink / raw)
To: Pablo Neira Ayuso, Patrick McHardy
Cc: netfilter-devel, netdev, mph, as, Jesper Dangaard Brouer
Packets reaching SYNPROXY were default dropped, as they were most
likely invalid (given the recommended state matching). This
patch, changes SYNPROXY target to let packets, not consumed,
continue being processed by the stack.
This will be more in line other target modules. As it will allow
more flexible configurations of handling, logging or matching on
packets in INVALID states.
Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
---
comments:
- This patch depend applying the TCP flags fix patch send earlier
- This replaces my patch: "netfilter: Extend SYNPROXY with a --continue option"
net/ipv4/netfilter/ipt_SYNPROXY.c | 8 ++++++--
net/ipv6/netfilter/ip6t_SYNPROXY.c | 8 ++++++--
2 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/net/ipv4/netfilter/ipt_SYNPROXY.c b/net/ipv4/netfilter/ipt_SYNPROXY.c
index 90e489e..67e17dc 100644
--- a/net/ipv4/netfilter/ipt_SYNPROXY.c
+++ b/net/ipv4/netfilter/ipt_SYNPROXY.c
@@ -285,11 +285,15 @@ synproxy_tg4(struct sk_buff *skb, const struct xt_action_param *par)
XT_SYNPROXY_OPT_ECN);
synproxy_send_client_synack(skb, th, &opts);
- } else if (th->ack && !(th->fin || th->rst || th->syn))
+ return NF_DROP;
+
+ } else if (th->ack && !(th->fin || th->rst || th->syn)) {
/* ACK from client */
synproxy_recv_client_ack(snet, skb, th, &opts, ntohl(th->seq));
+ return NF_DROP;
+ }
- return NF_DROP;
+ return XT_CONTINUE;
}
static unsigned int ipv4_synproxy_hook(unsigned int hooknum,
diff --git a/net/ipv6/netfilter/ip6t_SYNPROXY.c b/net/ipv6/netfilter/ip6t_SYNPROXY.c
index a5af0bf..19cfea8 100644
--- a/net/ipv6/netfilter/ip6t_SYNPROXY.c
+++ b/net/ipv6/netfilter/ip6t_SYNPROXY.c
@@ -300,11 +300,15 @@ synproxy_tg6(struct sk_buff *skb, const struct xt_action_param *par)
XT_SYNPROXY_OPT_ECN);
synproxy_send_client_synack(skb, th, &opts);
- } else if (th->ack && !(th->fin || th->rst || th->syn))
+ return NF_DROP;
+
+ } else if (th->ack && !(th->fin || th->rst || th->syn)) {
/* ACK from client */
synproxy_recv_client_ack(snet, skb, th, &opts, ntohl(th->seq));
+ return NF_DROP;
+ }
- return NF_DROP;
+ return XT_CONTINUE;
}
static unsigned int ipv6_synproxy_hook(unsigned int hooknum,
^ permalink raw reply related
* Re: [nf-next PATCH] netfilter: SYNPROXY let unrelated packets continue
From: Patrick McHardy @ 2013-08-29 10:11 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: Pablo Neira Ayuso, netfilter-devel, netdev, mph, as
In-Reply-To: <20130829101625.14346.41071.stgit@dragon>
On Thu, Aug 29, 2013 at 12:18:46PM +0200, Jesper Dangaard Brouer wrote:
> Packets reaching SYNPROXY were default dropped, as they were most
> likely invalid (given the recommended state matching). This
> patch, changes SYNPROXY target to let packets, not consumed,
> continue being processed by the stack.
>
> This will be more in line other target modules. As it will allow
> more flexible configurations of handling, logging or matching on
> packets in INVALID states.
>
> Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
Acked-by: Patrick McHardy <kaber@trash.net>
> ---
> comments:
> - This patch depend applying the TCP flags fix patch send earlier
> - This replaces my patch: "netfilter: Extend SYNPROXY with a --continue option"
^ permalink raw reply
* Re: [PATCH net-next 0/3] pf_packet updates
From: Eric Dumazet @ 2013-08-29 10:25 UTC (permalink / raw)
To: David Miller; +Cc: dborkman, netdev
In-Reply-To: <20130829.013938.2144325735677512661.davem@davemloft.net>
On Thu, 2013-08-29 at 01:39 -0400, David Miller wrote:
> From: Daniel Borkmann <dborkman@redhat.com>
> Date: Wed, 28 Aug 2013 22:13:08 +0200
>
> > Daniel Borkmann (3):
> > net: packet: add random fanout scheduler
> > net: packet: use reciprocal_divide in fanout_demux_hash
> > net: packet: document available fanout policies
>
> Please add the missing reciprocal_divide.h include to the second
> patch, as per Eric Dumazet's feedback, and resubmit this series.
(It was Cong Wang feedback ;) )
Thanks
^ permalink raw reply
* Re: [nf-next PATCH] netfilter: more strict TCP flag matching in SYNPROXY
From: Patrick McHardy @ 2013-08-29 10:33 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: Pablo Neira Ayuso, netfilter-devel, netdev, mph, as
In-Reply-To: <20130828131438.24364.25004.stgit@dragon>
On Wed, Aug 28, 2013 at 03:14:38PM +0200, Jesper Dangaard Brouer wrote:
> Its seems Patrick missed to incoorporate some of my requested changes
> during review v2 of SYNPROXY netfilter module.
>
> Which were, to avoid SYN+ACK packets to enter the path, meant for the
> ACK packet from the client (from the 3WHS).
>
> Further there were a bug in ip6t_SYNPROXY.c, for matching SYN packets
> that didn't exclude the ACK flag.
>
> Go a step further with SYN packet/flag matching by excluding flags
> ACK+FIN+RST, in both IPv4 and IPv6 modules.
>
>
> The intented usage of SYNPROXY is as follows:
> (gracefully describing usage in commit)
>
> iptables -t raw -A PREROUTING -i eth0 -p tcp --dport 80 --syn -j NOTRACK
> iptables -A INPUT -i eth0 -p tcp --dport 80 -m state UNTRACKED,INVALID \
> -j SYNPROXY --sack-perm --timestamp --mss 1480 --wscale 7 --ecn
>
> echo 0 > /proc/sys/net/netfilter/nf_conntrack_tcp_loose
>
> This does filter SYN flags early, for packets in the UNTRACKED state,
> but packets in the INVALID state with other TCP flags could still
> reach the module, thus this stricter flag matching is still needed.
>
> Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
Acked-by: Patrick McHardy <kaber@trash.net>
^ permalink raw reply
* [net-next v2 00/10][pull request] Intel Wired LAN Driver Updates
From: Jeff Kirsher @ 2013-08-29 10:49 UTC (permalink / raw)
To: davem; +Cc: Jeff Kirsher, netdev, gospo, sassmann
This series contains updates to ixgbe.
Jacob provides a fix for 82599 devices where it can potentially keep link
lights up when the adapter has gone down.
Mark provides a fix to resolve the possible use of uninitialized memory
by checking the return value on EEPROM reads.
Don provides 2 patches, one to fix a issue where we were traversing the
Tx ring with the value of IXGBE_NUM_RX_QUEUES which currently happens
to have the correct value but this is misleading. A change later, could
easily make this no longer correct so when traversing the Tx ring, use
netdev->num_tx_queues. His second patch does some minor clean ups of log
messages.
Emil provides the remaining ixgbe patches. First he fixes the link test
where forcing the laser before the link check can lead to inconsistent
results because it does not guarantee that the link will be negotiated
correctly. Then he initializes the message buffer array to 0 in order
to avoid using random numbers from the memory as a MAC address for the
VF. Emil also fixes the read loop for the I2C data to account for the
offset for SFP+ modules. Lastly, Emil provides several patches to add
support for QSFP modules where 1Gbps support is added as well as support
for older QSFP active direct attach cables which pre-date SFF-8436 v3.6.
v2: Fixed patch 4 description and added blank line based on feedback from
Sergei Shtylyov
The following are changes since commit cc328deac5a5f576aa79d87cfacf01e370e5e03e:
Merge tag 'batman-adv-for-davem' of git://git.open-mesh.org/linux-merge
and are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-next master
Don Skidmore (2):
ixgbe: fix incorrect limit value in ring transverse
ixgbe: cleanup some log messages
Emil Tantilov (6):
ixgbe: fix link test when connected to 1Gbps link partner
ixgbe: zero out mailbox buffer on init
ixgbe: fix SFF data dumps of SFP+ modules from an offset
ixgbe: add 1Gbps support for QSFP+
ixgbe: include QSFP PHY types in ixgbe_is_sfp()
ixgbe: add support for older QSFP active DA cables
Jacob Keller (1):
ixgbe: disable link when adapter goes down
Mark Rustad (1):
ixgbe: Check return value on eeprom reads
drivers/net/ethernet/intel/ixgbe/ixgbe_82599.c | 93 ++++++++++++++++++----
drivers/net/ethernet/intel/ixgbe/ixgbe_common.c | 67 ++++++++++------
drivers/net/ethernet/intel/ixgbe/ixgbe_common.h | 6 +-
drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c | 41 ++++------
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 13 +++-
drivers/net/ethernet/intel/ixgbe/ixgbe_phy.c | 98 +++++++++++++++++++-----
drivers/net/ethernet/intel/ixgbe/ixgbe_phy.h | 5 ++
drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c | 4 +-
drivers/net/ethernet/intel/ixgbe/ixgbe_type.h | 2 +
9 files changed, 239 insertions(+), 90 deletions(-)
--
1.8.3.1
^ permalink raw reply
* [net-next v2 01/10] ixgbe: disable link when adapter goes down
From: Jeff Kirsher @ 2013-08-29 10:49 UTC (permalink / raw)
To: davem; +Cc: Jacob Keller, netdev, gospo, sassmann, Jeff Kirsher
In-Reply-To: <1377773406-24851-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jacob Keller <jacob.e.keller@intel.com>
This patch fixes an issue with the 82599 adapter where it can potentially keep
link lights up when the adapter has gone down. The patch adds a function which
ensures link is disabled, and calls this function when the adapter transitions
to a down state.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/ixgbe/ixgbe_82599.c | 20 ++++++++++++++++++++
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 3 +++
drivers/net/ethernet/intel/ixgbe/ixgbe_type.h | 2 ++
3 files changed, 25 insertions(+)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_82599.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_82599.c
index 207f68f..51ee8ad 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_82599.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_82599.c
@@ -49,6 +49,7 @@ static s32 ixgbe_setup_mac_link_multispeed_fiber(struct ixgbe_hw *hw,
static s32 ixgbe_setup_mac_link_smartspeed(struct ixgbe_hw *hw,
ixgbe_link_speed speed,
bool autoneg_wait_to_complete);
+static void ixgbe_stop_mac_link_on_d3_82599(struct ixgbe_hw *hw);
static s32 ixgbe_start_mac_link_82599(struct ixgbe_hw *hw,
bool autoneg_wait_to_complete);
static s32 ixgbe_setup_mac_link_82599(struct ixgbe_hw *hw,
@@ -432,6 +433,24 @@ out:
}
/**
+ * ixgbe_stop_mac_link_on_d3_82599 - Disables link on D3
+ * @hw: pointer to hardware structure
+ *
+ * Disables link, should be called during D3 power down sequence.
+ *
+ */
+static void ixgbe_stop_mac_link_on_d3_82599(struct ixgbe_hw *hw)
+{
+ u32 autoc2_reg;
+
+ if (!hw->mng_fw_enabled && !hw->wol_enabled) {
+ autoc2_reg = IXGBE_READ_REG(hw, IXGBE_AUTOC2);
+ autoc2_reg |= IXGBE_AUTOC2_LINK_DISABLE_ON_D3_MASK;
+ IXGBE_WRITE_REG(hw, IXGBE_AUTOC2, autoc2_reg);
+ }
+}
+
+/**
* ixgbe_start_mac_link_82599 - Setup MAC link settings
* @hw: pointer to hardware structure
* @autoneg_wait_to_complete: true when waiting for completion is needed
@@ -2477,6 +2496,7 @@ static struct ixgbe_mac_operations mac_ops_82599 = {
.set_lan_id = &ixgbe_set_lan_id_multi_port_pcie,
.read_analog_reg8 = &ixgbe_read_analog_reg8_82599,
.write_analog_reg8 = &ixgbe_write_analog_reg8_82599,
+ .stop_link_on_d3 = &ixgbe_stop_mac_link_on_d3_82599,
.setup_link = &ixgbe_setup_mac_link_82599,
.set_rxpba = &ixgbe_set_rxpba_generic,
.check_link = &ixgbe_check_mac_link_generic,
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index 128d6b8..cf1b41e 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -5292,6 +5292,9 @@ static int __ixgbe_shutdown(struct pci_dev *pdev, bool *enable_wake)
return retval;
#endif
+ if (hw->mac.ops.stop_link_on_d3)
+ hw->mac.ops.stop_link_on_d3(hw);
+
if (wufc) {
ixgbe_set_rx_mode(netdev);
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_type.h b/drivers/net/ethernet/intel/ixgbe/ixgbe_type.h
index 161ff18..6442cf8 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_type.h
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_type.h
@@ -1596,6 +1596,7 @@ enum {
#define IXGBE_AUTOC2_10G_KR (0x0 << IXGBE_AUTOC2_10G_SERIAL_PMA_PMD_SHIFT)
#define IXGBE_AUTOC2_10G_XFI (0x1 << IXGBE_AUTOC2_10G_SERIAL_PMA_PMD_SHIFT)
#define IXGBE_AUTOC2_10G_SFI (0x2 << IXGBE_AUTOC2_10G_SERIAL_PMA_PMD_SHIFT)
+#define IXGBE_AUTOC2_LINK_DISABLE_ON_D3_MASK 0x50000000
#define IXGBE_AUTOC2_LINK_DISABLE_MASK 0x70000000
#define IXGBE_MACC_FLU 0x00000001
@@ -2847,6 +2848,7 @@ struct ixgbe_mac_operations {
void (*disable_tx_laser)(struct ixgbe_hw *);
void (*enable_tx_laser)(struct ixgbe_hw *);
void (*flap_tx_laser)(struct ixgbe_hw *);
+ void (*stop_link_on_d3)(struct ixgbe_hw *);
s32 (*setup_link)(struct ixgbe_hw *, ixgbe_link_speed, bool);
s32 (*check_link)(struct ixgbe_hw *, ixgbe_link_speed *, bool *, bool);
s32 (*get_link_capabilities)(struct ixgbe_hw *, ixgbe_link_speed *,
--
1.8.3.1
^ permalink raw reply related
* [net-next v2 03/10] ixgbe: fix incorrect limit value in ring transverse
From: Jeff Kirsher @ 2013-08-29 10:49 UTC (permalink / raw)
To: davem; +Cc: Don Skidmore, netdev, gospo, sassmann, Jeff Kirsher
In-Reply-To: <1377773406-24851-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Don Skidmore <donald.c.skidmore@intel.com>
We were transversing the tx_ring with IXGBE_NUM_RX_QUEUES. Now this define
happens to have the correct value but this is misleading and a change later
could easily make this no longer true. I updated it to netdev->num_tx_queues
like we use in ixgbe_get_strings().
Signed-off-by: Don Skidmore <donald.c.skidmore@intel.com>
Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
index 50c1e9b..db0dbf6 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
@@ -1049,7 +1049,7 @@ static void ixgbe_get_ethtool_stats(struct net_device *netdev,
data[i] = (ixgbe_gstrings_stats[i].sizeof_stat ==
sizeof(u64)) ? *(u64 *)p : *(u32 *)p;
}
- for (j = 0; j < IXGBE_NUM_RX_QUEUES; j++) {
+ for (j = 0; j < netdev->num_tx_queues; j++) {
ring = adapter->tx_ring[j];
if (!ring) {
data[i] = 0;
--
1.8.3.1
^ permalink raw reply related
* [net-next v2 02/10] ixgbe: Check return value on eeprom reads
From: Jeff Kirsher @ 2013-08-29 10:49 UTC (permalink / raw)
To: davem; +Cc: Mark Rustad, netdev, gospo, sassmann, Jeff Kirsher
In-Reply-To: <1377773406-24851-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Mark Rustad <mark.d.rustad@intel.com>
This patch fixes the possible use of uninitialized memory by checking the
return value on eeprom reads. These issues were identified by static
analysis. In many cases error messages will be produced so that corrupted
eeprom issues will be more visible.
Signed-off-by: Mark Rustad <mark.d.rustad@intel.com>
Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/ixgbe/ixgbe_82599.c | 38 ++++++++++----
drivers/net/ethernet/intel/ixgbe/ixgbe_common.c | 67 +++++++++++++++++--------
drivers/net/ethernet/intel/ixgbe/ixgbe_common.h | 6 ++-
drivers/net/ethernet/intel/ixgbe/ixgbe_phy.c | 35 ++++++++++---
4 files changed, 107 insertions(+), 39 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_82599.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_82599.c
index 51ee8ad..e4f4f4b 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_82599.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_82599.c
@@ -142,11 +142,13 @@ static s32 ixgbe_setup_sfp_modules_82599(struct ixgbe_hw *hw)
goto setup_sfp_out;
}
- hw->eeprom.ops.read(hw, ++data_offset, &data_value);
+ if (hw->eeprom.ops.read(hw, ++data_offset, &data_value))
+ goto setup_sfp_err;
while (data_value != 0xffff) {
IXGBE_WRITE_REG(hw, IXGBE_CORECTL, data_value);
IXGBE_WRITE_FLUSH(hw);
- hw->eeprom.ops.read(hw, ++data_offset, &data_value);
+ if (hw->eeprom.ops.read(hw, ++data_offset, &data_value))
+ goto setup_sfp_err;
}
/* Release the semaphore */
@@ -192,6 +194,17 @@ static s32 ixgbe_setup_sfp_modules_82599(struct ixgbe_hw *hw)
setup_sfp_out:
return ret_val;
+
+setup_sfp_err:
+ /* Release the semaphore */
+ hw->mac.ops.release_swfw_sync(hw, IXGBE_GSSR_MAC_CSR_SM);
+ /* Delay obtaining semaphore again to allow FW access,
+ * semaphore_delay is in ms usleep_range needs us.
+ */
+ usleep_range(hw->eeprom.semaphore_delay * 1000,
+ hw->eeprom.semaphore_delay * 2000);
+ hw_err(hw, "eeprom read at offset %d failed\n", data_offset);
+ return IXGBE_ERR_SFP_SETUP_NOT_COMPLETE;
}
static s32 ixgbe_get_invariants_82599(struct ixgbe_hw *hw)
@@ -2180,6 +2193,7 @@ static s32 ixgbe_verify_fw_version_82599(struct ixgbe_hw *hw)
{
s32 status = IXGBE_ERR_EEPROM_VERSION;
u16 fw_offset, fw_ptp_cfg_offset;
+ u16 offset;
u16 fw_version = 0;
/* firmware check is only necessary for SFI devices */
@@ -2189,29 +2203,35 @@ static s32 ixgbe_verify_fw_version_82599(struct ixgbe_hw *hw)
}
/* get the offset to the Firmware Module block */
- hw->eeprom.ops.read(hw, IXGBE_FW_PTR, &fw_offset);
+ offset = IXGBE_FW_PTR;
+ if (hw->eeprom.ops.read(hw, offset, &fw_offset))
+ goto fw_version_err;
if ((fw_offset == 0) || (fw_offset == 0xFFFF))
goto fw_version_out;
/* get the offset to the Pass Through Patch Configuration block */
- hw->eeprom.ops.read(hw, (fw_offset +
- IXGBE_FW_PASSTHROUGH_PATCH_CONFIG_PTR),
- &fw_ptp_cfg_offset);
+ offset = fw_offset + IXGBE_FW_PASSTHROUGH_PATCH_CONFIG_PTR;
+ if (hw->eeprom.ops.read(hw, offset, &fw_ptp_cfg_offset))
+ goto fw_version_err;
if ((fw_ptp_cfg_offset == 0) || (fw_ptp_cfg_offset == 0xFFFF))
goto fw_version_out;
/* get the firmware version */
- hw->eeprom.ops.read(hw, (fw_ptp_cfg_offset +
- IXGBE_FW_PATCH_VERSION_4),
- &fw_version);
+ offset = fw_ptp_cfg_offset + IXGBE_FW_PATCH_VERSION_4;
+ if (hw->eeprom.ops.read(hw, offset, &fw_version))
+ goto fw_version_err;
if (fw_version > 0x5)
status = 0;
fw_version_out:
return status;
+
+fw_version_err:
+ hw_err(hw, "eeprom read at offset %d failed\n", offset);
+ return IXGBE_ERR_EEPROM_VERSION;
}
/**
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_common.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_common.c
index 50e62a2..b5c434b 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_common.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_common.c
@@ -2740,13 +2740,19 @@ out:
static s32 ixgbe_get_san_mac_addr_offset(struct ixgbe_hw *hw,
u16 *san_mac_offset)
{
+ s32 ret_val;
+
/*
* First read the EEPROM pointer to see if the MAC addresses are
* available.
*/
- hw->eeprom.ops.read(hw, IXGBE_SAN_MAC_ADDR_PTR, san_mac_offset);
+ ret_val = hw->eeprom.ops.read(hw, IXGBE_SAN_MAC_ADDR_PTR,
+ san_mac_offset);
+ if (ret_val)
+ hw_err(hw, "eeprom read at offset %d failed\n",
+ IXGBE_SAN_MAC_ADDR_PTR);
- return 0;
+ return ret_val;
}
/**
@@ -2763,23 +2769,16 @@ s32 ixgbe_get_san_mac_addr_generic(struct ixgbe_hw *hw, u8 *san_mac_addr)
{
u16 san_mac_data, san_mac_offset;
u8 i;
+ s32 ret_val;
/*
* First read the EEPROM pointer to see if the MAC addresses are
* available. If they're not, no point in calling set_lan_id() here.
*/
- ixgbe_get_san_mac_addr_offset(hw, &san_mac_offset);
+ ret_val = ixgbe_get_san_mac_addr_offset(hw, &san_mac_offset);
+ if (ret_val || san_mac_offset == 0 || san_mac_offset == 0xFFFF)
- if ((san_mac_offset == 0) || (san_mac_offset == 0xFFFF)) {
- /*
- * No addresses available in this EEPROM. It's not an
- * error though, so just wipe the local address and return.
- */
- for (i = 0; i < 6; i++)
- san_mac_addr[i] = 0xFF;
-
- goto san_mac_addr_out;
- }
+ goto san_mac_addr_clr;
/* make sure we know which port we need to program */
hw->mac.ops.set_lan_id(hw);
@@ -2787,14 +2786,26 @@ s32 ixgbe_get_san_mac_addr_generic(struct ixgbe_hw *hw, u8 *san_mac_addr)
(hw->bus.func) ? (san_mac_offset += IXGBE_SAN_MAC_ADDR_PORT1_OFFSET) :
(san_mac_offset += IXGBE_SAN_MAC_ADDR_PORT0_OFFSET);
for (i = 0; i < 3; i++) {
- hw->eeprom.ops.read(hw, san_mac_offset, &san_mac_data);
+ ret_val = hw->eeprom.ops.read(hw, san_mac_offset,
+ &san_mac_data);
+ if (ret_val) {
+ hw_err(hw, "eeprom read at offset %d failed\n",
+ san_mac_offset);
+ goto san_mac_addr_clr;
+ }
san_mac_addr[i * 2] = (u8)(san_mac_data);
san_mac_addr[i * 2 + 1] = (u8)(san_mac_data >> 8);
san_mac_offset++;
}
-
-san_mac_addr_out:
return 0;
+
+san_mac_addr_clr:
+ /* No addresses available in this EEPROM. It's not necessarily an
+ * error though, so just wipe the local address and return.
+ */
+ for (i = 0; i < 6; i++)
+ san_mac_addr[i] = 0xFF;
+ return ret_val;
}
/**
@@ -3243,8 +3254,9 @@ s32 ixgbe_get_wwn_prefix_generic(struct ixgbe_hw *hw, u16 *wwnn_prefix,
*wwpn_prefix = 0xFFFF;
/* check if alternative SAN MAC is supported */
- hw->eeprom.ops.read(hw, IXGBE_ALT_SAN_MAC_ADDR_BLK_PTR,
- &alt_san_mac_blk_offset);
+ offset = IXGBE_ALT_SAN_MAC_ADDR_BLK_PTR;
+ if (hw->eeprom.ops.read(hw, offset, &alt_san_mac_blk_offset))
+ goto wwn_prefix_err;
if ((alt_san_mac_blk_offset == 0) ||
(alt_san_mac_blk_offset == 0xFFFF))
@@ -3252,19 +3264,26 @@ s32 ixgbe_get_wwn_prefix_generic(struct ixgbe_hw *hw, u16 *wwnn_prefix,
/* check capability in alternative san mac address block */
offset = alt_san_mac_blk_offset + IXGBE_ALT_SAN_MAC_ADDR_CAPS_OFFSET;
- hw->eeprom.ops.read(hw, offset, &caps);
+ if (hw->eeprom.ops.read(hw, offset, &caps))
+ goto wwn_prefix_err;
if (!(caps & IXGBE_ALT_SAN_MAC_ADDR_CAPS_ALTWWN))
goto wwn_prefix_out;
/* get the corresponding prefix for WWNN/WWPN */
offset = alt_san_mac_blk_offset + IXGBE_ALT_SAN_MAC_ADDR_WWNN_OFFSET;
- hw->eeprom.ops.read(hw, offset, wwnn_prefix);
+ if (hw->eeprom.ops.read(hw, offset, wwnn_prefix))
+ hw_err(hw, "eeprom read at offset %d failed\n", offset);
offset = alt_san_mac_blk_offset + IXGBE_ALT_SAN_MAC_ADDR_WWPN_OFFSET;
- hw->eeprom.ops.read(hw, offset, wwpn_prefix);
+ if (hw->eeprom.ops.read(hw, offset, wwpn_prefix))
+ goto wwn_prefix_err;
wwn_prefix_out:
return 0;
+
+wwn_prefix_err:
+ hw_err(hw, "eeprom read at offset %d failed\n", offset);
+ return 0;
}
/**
@@ -3778,7 +3797,11 @@ s32 ixgbe_init_thermal_sensor_thresh_generic(struct ixgbe_hw *hw)
u8 sensor_index;
u8 sensor_location;
- hw->eeprom.ops.read(hw, (ets_offset + 1 + i), &ets_sensor);
+ if (hw->eeprom.ops.read(hw, ets_offset + 1 + i, &ets_sensor)) {
+ hw_err(hw, "eeprom read at offset %d failed\n",
+ ets_offset + 1 + i);
+ continue;
+ }
sensor_index = ((ets_sensor & IXGBE_ETS_DATA_INDEX_MASK) >>
IXGBE_ETS_DATA_INDEX_SHIFT);
sensor_location = ((ets_sensor & IXGBE_ETS_DATA_LOC_MASK) >>
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_common.h b/drivers/net/ethernet/intel/ixgbe/ixgbe_common.h
index 1315b8a..d259dc7 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_common.h
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_common.h
@@ -143,8 +143,12 @@ s32 ixgbe_init_thermal_sensor_thresh_generic(struct ixgbe_hw *hw);
#define IXGBE_WRITE_FLUSH(a) IXGBE_READ_REG(a, IXGBE_STATUS)
+#define ixgbe_hw_to_netdev(hw) (((struct ixgbe_adapter *)(hw)->back)->netdev)
+
#define hw_dbg(hw, format, arg...) \
- netdev_dbg(((struct ixgbe_adapter *)(hw->back))->netdev, format, ##arg)
+ netdev_dbg(ixgbe_hw_to_netdev(hw), format, ## arg)
+#define hw_err(hw, format, arg...) \
+ netdev_err(ixgbe_hw_to_netdev(hw), format, ## arg)
#define e_dev_info(format, arg...) \
dev_info(&adapter->pdev->dev, format, ## arg)
#define e_dev_warn(format, arg...) \
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_phy.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_phy.c
index 369eef5..6a4a799 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_phy.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_phy.c
@@ -791,6 +791,8 @@ s32 ixgbe_reset_phy_nl(struct ixgbe_hw *hw)
* Read control word from PHY init contents offset
*/
ret_val = hw->eeprom.ops.read(hw, data_offset, &eword);
+ if (ret_val)
+ goto err_eeprom;
control = (eword & IXGBE_CONTROL_MASK_NL) >>
IXGBE_CONTROL_SHIFT_NL;
edata = eword & IXGBE_DATA_MASK_NL;
@@ -803,10 +805,15 @@ s32 ixgbe_reset_phy_nl(struct ixgbe_hw *hw)
case IXGBE_DATA_NL:
hw_dbg(hw, "DATA:\n");
data_offset++;
- hw->eeprom.ops.read(hw, data_offset++,
- &phy_offset);
+ ret_val = hw->eeprom.ops.read(hw, data_offset++,
+ &phy_offset);
+ if (ret_val)
+ goto err_eeprom;
for (i = 0; i < edata; i++) {
- hw->eeprom.ops.read(hw, data_offset, &eword);
+ ret_val = hw->eeprom.ops.read(hw, data_offset,
+ &eword);
+ if (ret_val)
+ goto err_eeprom;
hw->phy.ops.write_reg(hw, phy_offset,
MDIO_MMD_PMAPMD, eword);
hw_dbg(hw, "Wrote %4.4x to %4.4x\n", eword,
@@ -838,6 +845,10 @@ s32 ixgbe_reset_phy_nl(struct ixgbe_hw *hw)
out:
return ret_val;
+
+err_eeprom:
+ hw_err(hw, "eeprom read at offset %d failed\n", data_offset);
+ return IXGBE_ERR_PHY;
}
/**
@@ -1339,7 +1350,11 @@ s32 ixgbe_get_sfp_init_sequence_offsets(struct ixgbe_hw *hw,
sfp_type = ixgbe_sfp_type_srlr_core1;
/* Read offset to PHY init contents */
- hw->eeprom.ops.read(hw, IXGBE_PHY_INIT_OFFSET_NL, list_offset);
+ if (hw->eeprom.ops.read(hw, IXGBE_PHY_INIT_OFFSET_NL, list_offset)) {
+ hw_err(hw, "eeprom read at %d failed\n",
+ IXGBE_PHY_INIT_OFFSET_NL);
+ return IXGBE_ERR_SFP_NO_INIT_SEQ_PRESENT;
+ }
if ((!*list_offset) || (*list_offset == 0xFFFF))
return IXGBE_ERR_SFP_NO_INIT_SEQ_PRESENT;
@@ -1351,12 +1366,14 @@ s32 ixgbe_get_sfp_init_sequence_offsets(struct ixgbe_hw *hw,
* Find the matching SFP ID in the EEPROM
* and program the init sequence
*/
- hw->eeprom.ops.read(hw, *list_offset, &sfp_id);
+ if (hw->eeprom.ops.read(hw, *list_offset, &sfp_id))
+ goto err_phy;
while (sfp_id != IXGBE_PHY_INIT_END_NL) {
if (sfp_id == sfp_type) {
(*list_offset)++;
- hw->eeprom.ops.read(hw, *list_offset, data_offset);
+ if (hw->eeprom.ops.read(hw, *list_offset, data_offset))
+ goto err_phy;
if ((!*data_offset) || (*data_offset == 0xFFFF)) {
hw_dbg(hw, "SFP+ module not supported\n");
return IXGBE_ERR_SFP_NOT_SUPPORTED;
@@ -1366,7 +1383,7 @@ s32 ixgbe_get_sfp_init_sequence_offsets(struct ixgbe_hw *hw,
} else {
(*list_offset) += 2;
if (hw->eeprom.ops.read(hw, *list_offset, &sfp_id))
- return IXGBE_ERR_PHY;
+ goto err_phy;
}
}
@@ -1376,6 +1393,10 @@ s32 ixgbe_get_sfp_init_sequence_offsets(struct ixgbe_hw *hw,
}
return 0;
+
+err_phy:
+ hw_err(hw, "eeprom read at offset %d failed\n", *list_offset);
+ return IXGBE_ERR_PHY;
}
/**
--
1.8.3.1
^ permalink raw reply related
* [net-next v2 04/10] ixgbe: fix link test when connected to 1Gbps link partner
From: Jeff Kirsher @ 2013-08-29 10:50 UTC (permalink / raw)
To: davem; +Cc: Emil Tantilov, netdev, gospo, sassmann, Sergei Shtylyov,
Jeff Kirsher
In-Reply-To: <1377773406-24851-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Emil Tantilov <emil.s.tantilov@intel.com>
This patch is a partial reverse of:
commit dfcc4615f09c33454bc553567f7c7506cae60cb9
Author: Jacob Keller <jacob.e.keller@intel.com>
Date: Thu Nov 8 07:07:08 2012 +0000
ixgbe: ethtool ixgbe_diag_test cleanup
Specifically forcing the laser before the link check can lead to
inconsistent results because it does not guarantee that the link will be
negotiated correctly. Such is the case when dual speed SFP+ module is
connected to a gigabit link partner.
CC: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Signed-off-by: Emil Tantilov <emil.s.tantilov@intel.com>
Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
v2: fixed patch description and added blank line based on feedback from
Sergei Shtylyov
---
drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c | 27 +++++++++---------------
1 file changed, 10 insertions(+), 17 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
index db0dbf6..b6f1592 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
@@ -1885,11 +1885,12 @@ static void ixgbe_diag_test(struct net_device *netdev,
struct ethtool_test *eth_test, u64 *data)
{
struct ixgbe_adapter *adapter = netdev_priv(netdev);
- struct ixgbe_hw *hw = &adapter->hw;
bool if_running = netif_running(netdev);
set_bit(__IXGBE_TESTING, &adapter->state);
if (eth_test->flags == ETH_TEST_FL_OFFLINE) {
+ struct ixgbe_hw *hw = &adapter->hw;
+
if (adapter->flags & IXGBE_FLAG_SRIOV_ENABLED) {
int i;
for (i = 0; i < adapter->num_vfs; i++) {
@@ -1913,21 +1914,18 @@ static void ixgbe_diag_test(struct net_device *netdev,
/* Offline tests */
e_info(hw, "offline testing starting\n");
- if (if_running)
- /* indicate we're in test mode */
- dev_close(netdev);
-
- /* bringing adapter down disables SFP+ optics */
- if (hw->mac.ops.enable_tx_laser)
- hw->mac.ops.enable_tx_laser(hw);
-
/* Link test performed before hardware reset so autoneg doesn't
* interfere with test result
*/
if (ixgbe_link_test(adapter, &data[4]))
eth_test->flags |= ETH_TEST_FL_FAILED;
- ixgbe_reset(adapter);
+ if (if_running)
+ /* indicate we're in test mode */
+ dev_close(netdev);
+ else
+ ixgbe_reset(adapter);
+
e_info(hw, "register testing starting\n");
if (ixgbe_reg_test(adapter, &data[0]))
eth_test->flags |= ETH_TEST_FL_FAILED;
@@ -1964,13 +1962,11 @@ skip_loopback:
clear_bit(__IXGBE_TESTING, &adapter->state);
if (if_running)
dev_open(netdev);
+ else if (hw->mac.ops.disable_tx_laser)
+ hw->mac.ops.disable_tx_laser(hw);
} else {
e_info(hw, "online testing starting\n");
- /* if adapter is down, SFP+ optics will be disabled */
- if (!if_running && hw->mac.ops.enable_tx_laser)
- hw->mac.ops.enable_tx_laser(hw);
-
/* Online tests */
if (ixgbe_link_test(adapter, &data[4]))
eth_test->flags |= ETH_TEST_FL_FAILED;
@@ -1984,9 +1980,6 @@ skip_loopback:
clear_bit(__IXGBE_TESTING, &adapter->state);
}
- /* if adapter was down, ensure SFP+ optics are disabled again */
- if (!if_running && hw->mac.ops.disable_tx_laser)
- hw->mac.ops.disable_tx_laser(hw);
skip_ol_tests:
msleep_interruptible(4 * 1000);
}
--
1.8.3.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox