[PATCH net-next v2 02/14] octeontx2-af: Add response for RSS flow key cfg message

Added response for nix_rss_flowkey_cfg message to return selected RSS algorithm index. The FLOW_KEY_TYPE* definition is part of the mbox message and it will be used by the other consumers of AF driver hence moving to mbox.h. Also renamed FLOW_* definitions to NIX_FLOW_* to avoid global name

Re: [PATCH v1 net-next 02/14] octeontx2-af: Add response for RSS flow key cfg message

From: Jerin Jacob Date: Sat, 1 Dec 2018 14:43:51 +0530 > +#define FLOW_KEY_TYPE_PORT BIT(0) > +#define FLOW_KEY_TYPE_IPV4 BIT(1) > +#define FLOW_KEY_TYPE_IPV6 BIT(2) > +#define FLOW_KEY_TYPE_TCPBIT(3) > +#define FLOW_KEY_TYPE_UDPBIT(4) > +#define FLOW_KEY_TYPE_SCTP BIT(5) This

[PATCH v1 net-next 02/14] octeontx2-af: Add response for RSS flow key cfg message

From: Jerin Jacob Added response for nix_rss_flowkey_cfg message to return selected RSS algorithm index. The FLOW_KEY_TYPE* definition is part of the mbox message and it will be used by the other consumers of AF driver hence moving to mbox.h. Signed-off-by: Jerin Jacob --- drivers/net

Re: [PATCH net-next 1/8] net: eth: altera: tse_start_xmit ignores tx_buffer call response

On Fri, 2018-11-16 at 20:38 -0800, David Miller wrote: > From: Dalon Westergreen > Date: Wed, 14 Nov 2018 16:50:40 -0800 > > > @@ -202,7 +204,7 @@ int sgdma_tx_buffer(struct altera_tse_private *priv, > struct tse_buffer *buffer) > > /* enqueue the request to the pending transmit queue */ >

Re: [PATCH net-next 1/8] net: eth: altera: tse_start_xmit ignores tx_buffer call response

From: Dalon Westergreen Date: Wed, 14 Nov 2018 16:50:40 -0800 > @@ -202,7 +204,7 @@ int sgdma_tx_buffer(struct altera_tse_private *priv, > struct tse_buffer *buffer) > /* enqueue the request to the pending transmit queue */ > queue_tx(priv, buffer); > > - return 1; > +

Re: [PATCH net-next 1/8] net: eth: altera: tse_start_xmit ignores tx_buffer call response

On 11/14/18 6:50 PM, Dalon Westergreen wrote: From: Dalon Westergreen The return from tx_buffer call in tse_start_xmit is inapropriately ignored. tse_buffer calls should return 0 for success or NETDEV_TX_BUSY. tse_start_xmit should return not report a successful transmit when the tse_buffer

[PATCH net-next 1/8] net: eth: altera: tse_start_xmit ignores tx_buffer call response

From: Dalon Westergreen The return from tx_buffer call in tse_start_xmit is inapropriately ignored. tse_buffer calls should return 0 for success or NETDEV_TX_BUSY. tse_start_xmit should return not report a successful transmit when the tse_buffer call returns an error condition. In addition to

I wait for your prompt response.

properties, hotels and any other viable investment opportunities in your country based on your recommendation will be highly welcomed. Hence your co -operation is highly needed to actualize this investment project I wait for your prompt response. Sincerely yours Mr Aziz Dake.

[PATCH v2 12/17] octeontx2-af: Add LMAC channel info to NIXLF_ALLOC response

From: Stanislaw Kardach Add LMAC channel info like Rx/Tx channel base and count to NIXLF_ALLOC mailbox message response. This info is used by NIXLF attached RVU PF/VF to configure SQ's default channel, TL3_TL2_LINKX_CFG and to install MCAM rules in NPC based on matching ingress channel number

[PATCH 12/17] octeontx2-af: Add LMAC channel info to NIXLF_ALLOC response

From: Stanislaw Kardach Add LMAC channel info like Rx/Tx channel base and count to NIXLF_ALLOC mailbox message response. This info is used by NIXLF attached RVU PF/VF to configure SQ's default channel, TL3_TL2_LINKX_CFG and to install MCAM rules in NPC based on matching ingress channel number

URGENT RESPONSE NEEDED

Hello my dear. Did you receive my email message to you? Please, get back to me ASAP as the matter is becoming late. Expecting your urgent response. Sean.

[PATCH v3] rxrpc: use correct kvec num while send response packet in rxrpc_reject_packets

Fixes gcc '-Wunused-but-set-variable' warning: net/rxrpc/output.c: In function 'rxrpc_reject_packets': net/rxrpc/output.c:527:11: warning: variable 'ioc' set but not used [-Wunused-but-set-variable] 'ioc' is the correct kvec num while send response packet. Fixes: ece64fec164f ("rxrpc:

Re: [PATCH v2] rxrpc: use correct kvec num while send response packet in rxrpc_reject_packets

' set but not used [-Wunused-but-set-variable] >> >> 'ioc' is the correct kvec num while send response packet. >> >> Fixes: commit ece64fec164f ("rxrpc: Emit BUSY packets when supposed to >> rather than > ABORTs") > >"commit" not needed here. Thank you for review. > >> Signed-off-by: YueHaibing > [...] > > MBR, Sergei > > >

Re: [PATCH v2] rxrpc: use correct kvec num while send response packet in rxrpc_reject_packets

orrect kvec num while send response packet. > > Fixes: commit ece64fec164f ("rxrpc: Emit BUSY packets when supposed to rather > than ABORTs") "commit" not needed here. > Signed-off-by: YueHaibing [...] MBR, Sergei

[PATCH v2] rxrpc: use correct kvec num while send response packet in rxrpc_reject_packets

Fixes gcc '-Wunused-but-set-variable' warning: net/rxrpc/output.c: In function 'rxrpc_reject_packets': net/rxrpc/output.c:527:11: warning: variable 'ioc' set but not used [-Wunused-but-set-variable] 'ioc' is the correct kvec num while send response packet. Fixes: commit ece64fec164f ("

Re: [PATCH iproute2] lib/libnetlink: fix response seq check

and a message is sent with nlmsg_seq == 43. If > > a response with nlmsg_seq of 42 is received, the condition being fixed > > in this patch would incorrectly accept it. > > > > Fixes: 72a2ff3916e5 ("lib/libnetlink: Add a new function rtnl_talk_iov") > > Signed-of

Re: [PATCH iproute2] lib/libnetlink: fix response seq check

Hi, On Fri, Sep 28, 2018 at 10:14 AM wrote: > > From: Vlad Dumitrescu > > Taking a one-iovec example, with rtnl->seq at 42. iovlen == 1, seq > becomes 43 on line 604, and a message is sent with nlmsg_seq == 43. If > a response with nlmsg_seq of 42 is received, the

[PATCH iproute2] lib/libnetlink: fix response seq check

From: Vlad Dumitrescu Taking a one-iovec example, with rtnl->seq at 42. iovlen == 1, seq becomes 43 on line 604, and a message is sent with nlmsg_seq == 43. If a response with nlmsg_seq of 42 is received, the condition being fixed in this patch would incorrectly accept it. Fixes: 72a2ff391

I wait for your prompt response.

properties, hotels and any other viable investment opportunities in your country based on your recommendation will be highly welcomed. Hence your co -operation is highly needed to actualize this investment project I wait for your prompt response. Sincerely yours Mr Aziz Dake.

Re: [PATCH net-next 0/4] liquidio: improve soft command/response handling

From: Felix Manlunas Date: Tue, 28 Aug 2018 18:50:58 -0700 > From: Weilin Chang > > Change soft command handling to fix the possible race condition when the > process handles a response of a soft command that was already freed by an > application which got timeout for this r

[PATCH net-next 0/4] liquidio: improve soft command/response handling

From: Weilin Chang Change soft command handling to fix the possible race condition when the process handles a response of a soft command that was already freed by an application which got timeout for this request. Weilin Chang (4): liquidio: improve soft command handling liquidio: make soft

Re: [PATCH iproute2] iplink_vrf: Save device index from response for return code

On Fri, Jun 01, 2018 at 08:50:16AM -0700, dsah...@kernel.org wrote: > From: David Ahern > > A recent commit changed rtnl_talk_* to return the response message in > allocated memory so callers need to free it. The change to name_is_vrf > did not save the device index which is point

Re: [PATCH iproute2] iplink_vrf: Save device index from response for return code

On Fri, Jun 01, 2018 at 08:50:16AM -0700, dsah...@kernel.org wrote: > From: David Ahern > > A recent commit changed rtnl_talk_* to return the response message in > allocated memory so callers need to free it. The change to name_is_vrf > did not save the device index which is point

[PATCH iproute2] iplink_vrf: Save device index from response for return code

From: David Ahern A recent commit changed rtnl_talk_* to return the response message in allocated memory so callers need to free it. The change to name_is_vrf did not save the device index which is pointing to a struct inside the now allocated and freed memory resulting in garbage getting

[PATCH rdma-next 2/3] IB/mlx5: Refactor CQE compression response

From: Yonatan Cohen <yonat...@mellanox.com> Refactor CQE compression response to be fully set only when it`s really supported. There is no change from user perspective because anyway resp.cqe_comp_caps.max_num was set to zero. Reviewed-by: Yishai Hadas <yish...@mellanox.com>

RESPONSE

response. Faithfully, Ms.Ella Golan

Re: [Xen-devel] [PATCH 2/6] xen-netfront: copy response out of shared buffer before accessing it

On 05/01/2018 12:01 AM, Marek Marczykowski-Górecki wrote: Make local copy of the response, otherwise backend might modify it while frontend is already processing it - leading to time of check / time of use issue. This is complementary to XSA155. Cc: sta...@vger.kernel.org Signed-off-by: Marek

Re: [Xen-devel] [PATCH 4/6] xen-netfront: add range check for Tx response id

On Mon, Apr 30, 2018 at 11:01:48PM +0200, Marek Marczykowski-Górecki wrote: > Tx response ID is fetched from shared page, so make sure it is sane > before using it as an array index. > > CC: sta...@vger.kernel.org > Signed-off-by: Marek Marczykowski-Górecki <marma...@invi

[PATCH 2/6] xen-netfront: copy response out of shared buffer before accessing it

Make local copy of the response, otherwise backend might modify it while frontend is already processing it - leading to time of check / time of use issue. This is complementary to XSA155. Cc: sta...@vger.kernel.org Signed-off-by: Marek Marczykowski-Górecki <marma...@invisiblethingslab.

[PATCH 4/6] xen-netfront: add range check for Tx response id

Tx response ID is fetched from shared page, so make sure it is sane before using it as an array index. CC: sta...@vger.kernel.org Signed-off-by: Marek Marczykowski-Górecki <marma...@invisiblethingslab.com> --- drivers/net/xen-netfront.c | 1 + 1 file changed, 1 insertion(+) diff --git a/d

[PATCH net-next 10/16] bnxt_en: Improve valid bit checking in firmware response message.

When firmware sends a DMA response to the driver, the last byte of the message will be set to 1 to indicate that the whole response is valid. The driver waits for the message to be valid before reading the message. The firmware spec allows these response messages to increase in length by adding

[PATCH bpf-next 14/14] nfp: bpf: improve wrong FW response warnings

When FW responds with a message of wrong size or type make sure the type is checked first and included in the wrong size message. This makes it easier to figure out which FW command failed. Signed-off-by: Jakub Kicinski Reviewed-by: Quentin Monnet

Re: HW question: i210 vs. BCM5461S over SGMII: no response from PHY to MDIO requests?

... yes I've just noticed Russell's patch mentioning mvneta, and found the phylink patches to mvneta in net-next (until then I'd been reading the vanilla, where they haven't landed yet). https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/tre

Re: HW question: i210 vs. BCM5461S over SGMII: no response from PHY to MDIO requests?

> Looking at the i2c dumps, and some past dumps from the igb driver, > it's dawning on me on me that the igb driver, without much hacking, > would try to read the PHY ID from the DMI/DDM block - a case which > the drivers/net/phy/mdio-i2c.c specifically avoids :-) It avoids if for a very good

Re: HW question: i210 vs. BCM5461S over SGMII: no response from PHY to MDIO requests?

> I was also wondering if someone has written any kernel-space support > for the SFP's. Sure enough, I've found lots of code by Russell King > under drivers/net/phy. I started reading from sfp.c, went on to > sfp-bus.c, next the phylink stuff... Answers lots of my questions. > Clearly someone

Re: HW question: i210 vs. BCM5461S over SGMII: no response from PHY to MDIO requests?

On 21 Mar 2018 at 11:47, Andrew Lunn , net...@vger.ker wrote: > Another question is, how to write the driver's initialization > sequence, for it to correctly decide if the SFP is SERDES or SGMII or > what. I could just follow the config obtained from the i210 EEPROM. > Alternatively, or somehow

Re: HW question: i210 vs. BCM5461S over SGMII: no response from PHY to MDIO requests?

Just another follow-up: With specs on SFP MSA, DDM/DMI and MII in hand, I have determined: 0x50 (a.k.a. 0xA0 in SFP MSA spec) = the module's SPD "EEPROM" 0x51 (a.k.a. 0xA2 in SFP MSA spec) = diagnostics (DMI/DDM) 0x56 = MII management access over i2C Using eeprog (reading each offset twice to

Re: HW question: i210 vs. BCM5461S over SGMII: no response from PHY to MDIO requests?

On 20 Mar 2018 at 13:09, Andrew Lunn wrote: > > i2cdetect has found three i2c slaves (identical layout in both SFP's) > > at addresses 0x50, 0x51 and 0x56. > > What are they? EEPROM, DDM and "MDIO over i2c" ? > > The SFP's likely lack a proper SFP MSA data structure. > > 0x50 and 0x51 are EEPROM

Re: HW question: i210 vs. BCM5461S over SGMII: no response from PHY to MDIO requests?

> i2cdetect has found three i2c slaves (identical layout in both SFP's) > at addresses 0x50, 0x51 and 0x56. > What are they? EEPROM, DDM and "MDIO over i2c" ? > The SFP's likely lack a proper SFP MSA data structure. 0x50 and 0x51 are EEPROM like. See drivers/net/phy/sfp.c. The standard at24

Re: HW question: i210 vs. BCM5461S over SGMII: no response from PHY to MDIO requests?

I've taken a look inside the two SFP's. http://support.fccps.cz/download/adv/frr/ptp/inside_sfps.zip The uglier, bigger and likely older model (my SFP#2) contains two PCB's sandwiched, and the key chips are inside the sandwich. Thus, the photoes don't show much. The sexier SFP#1 = the one with

Re: HW question: i210 vs. BCM5461S over SGMII: no response from PHY to MDIO requests?

> I'm not getting an ACK from the SFP, probably because I've got the > address and offset wrong and because I'd better use indirect access. > There's some more work awaiting me... Try address 0x50. i2detect will probe all addresses for you, if you have a standard Linux i2c bus. Andrew

Re: HW question: i210 vs. BCM5461S over SGMII: no response from PHY to MDIO requests?

> > > Right now I've modded igb_init_i2c() to engage the bit-banging > > > i2c driver for the i210 too > > > > I don't think that will work. The datasheet for the i210 talks about > > two registers for I2C/MDIO which are not bit-banging. Only the i350 > > uses bit-banging. > > > From the i210

Re: HW question: i210 vs. BCM5461S over SGMII: no response from PHY to MDIO requests?

On 17 Mar 2018 at 15:50, Andrew Lunn wrote: > On Sat, Mar 17, 2018 at 08:39:00AM +0100, Frantisek Rysanek wrote: > > On 16 Mar 2018 at 22:02, Andrew Lunn wrote: > > > > > > Does ethtool -m show anything useful? > > > > > > > Not much. "unsupported". > > static int igb_get_module_info(struct

Re: HW question: i210 vs. BCM5461S over SGMII: no response from PHY to MDIO requests?

On Sat, Mar 17, 2018 at 08:39:00AM +0100, Frantisek Rysanek wrote: > On 16 Mar 2018 at 22:02, Andrew Lunn wrote: > > > > Does ethtool -m show anything useful? > > > > Not much. "unsupported". static int igb_get_module_info(struct net_device *netdev, struct

Re: HW question: i210 vs. BCM5461S over SGMII: no response from PHY to MDIO requests?

On 16 Mar 2018 at 22:02, Andrew Lunn wrote: > > Does ethtool -m show anything useful? > Not much. "unsupported". Probably the ioctl() is not implemented or something, I haven't investigated. Maybe I should. Right now I've modded igb_init_i2c() to engage the bit-banging i2c driver for the i210

Re: HW question: i210 vs. BCM5461S over SGMII: no response from PHY to MDIO requests?

> The DeLock board is this beauty: > http://www.delock.de/produkte/G_89481/merkmale.html?setLanguage=en > DeLock techsupport were so kind as to provide me with a schematic > snippet, showing the wiring of the i210 fiber SKU's dedicated > I2C/MDIO pins to the SFP socket's standard I2C pins. There

Re: HW question: i210 vs. BCM5461S over SGMII: no response from PHY to MDIO requests?

gt; does not have this capability. > > Can you tell us the exact make/model of the DeLock card and the SFP > modules. > > Andrew > Hello Andrew, thanks for your polite response. The DeLock board is this beauty: http://www.delock.de/produkte/G_89481/merkmale.html?setLanguage=

Re: HW question: i210 vs. BCM5461S over SGMII: no response from PHY to MDIO requests?

On Fri, Mar 16, 2018 at 05:48:20PM +0100, Frantisek Rysanek wrote: > Dear polite inhabitants of the "netdev" mailing list, > > this is for a skunkworks project at the fringe of my job... > More of a DIY hobby thing :-) I'm tinkering and having fun. > > The wizards from linux-ptp have taught me

HW question: i210 vs. BCM5461S over SGMII: no response from PHY to MDIO requests?

Dear polite inhabitants of the "netdev" mailing list, this is for a skunkworks project at the fringe of my job... More of a DIY hobby thing :-) I'm tinkering and having fun. The wizards from linux-ptp have taught me how to use the i210 for precise timestamping, which works fine at all copper

WAITING FOR YOUR URGENT AND IMMEDIATE RESPONSE.

Benson, A banker by profession. Please, I want to transfer the sum of ($10.5.million) dollars into your bank account. This business is 100% risk free. Your share will be 40% while 60% for me. Full details will be send to you on the receipt of your urgent response by forwarding the following

Your response is important

Hello, I am contacting you to be my foreign partner in a financial transaction in my Corporation with the objective of investing the fund in your country. Thanks in anticipation of your response. Mr.Jeddy

response

response. Faithfully, Ms.Ella Golan

response

response. Faithfully, Ms.Ella Golan

response

response. Faithfully, Ms.Ella Golan

Re: [PATCH net] ibmvnic: Wait for device response when changing MAC

From: Thomas Falcon <tlfal...@linux.vnet.ibm.com> Date: Mon, 29 Jan 2018 13:45:05 -0600 > Wait for a response from the VNIC server before exiting after setting > the MAC address. The resolves an issue with bonding a VNIC client in > ALB or TLB modes. The bonding driver was c

[PATCH net] ibmvnic: Wait for device response when changing MAC

Wait for a response from the VNIC server before exiting after setting the MAC address. The resolves an issue with bonding a VNIC client in ALB or TLB modes. The bonding driver was changing the MAC address more rapidly than the device could respond, causing the following errors. "bond0: t

[PATCH net-next 13/20] net: hns3: Fix a response data read error of tqp statistics query

From: Jian Shen The result of tqp statistics query was read with an error position, fix it according to the user manual. Fixes: 46a3df9f9718 ("net: hns3: Add HNS3 Acceleration Engine & Compatibility Layer Support") Signed-off-by: Jian Shen

Re: [PATCH V2] staging: rtl8188eu: Fix incorrect response to SIOCGIWESSID

On Sat, Nov 25, 2017 at 01:32:38PM -0600, Larry Finger wrote: > When not associated with an AP, wifi device drivers should respond to the > SIOCGIWESSID ioctl with a zero-length string for the SSID, which is the > behavior expected by dhcpcd. > > Currently, this driver returns an error code (-1)

[PATCH V2] staging: rtl8188eu: Fix incorrect response to SIOCGIWESSID

When not associated with an AP, wifi device drivers should respond to the SIOCGIWESSID ioctl with a zero-length string for the SSID, which is the behavior expected by dhcpcd. Currently, this driver returns an error code (-1) from the ioctl call, which causes dhcpcd to assume that the device is

Re: [PATCH net-next 2/2] net/ncsi: Don't return error on normal response

From: Samuel Mendoza-Jonas <s...@mendozajonas.com> Date: Wed, 8 Nov 2017 16:30:45 +1100 > Several response handlers return EBUSY if the data corresponding to the > command/response pair is already set. There is no reason to return an > error here; the channel is advertising somet

Urgent response !!!

Greetings, I have a business proposal I would love to discuss with you. please reply me for more details Yours Sincerely, miss.melisa.mehmet

[PATCH net-next 2/2] net/ncsi: Don't return error on normal response

Several response handlers return EBUSY if the data corresponding to the command/response pair is already set. There is no reason to return an error here; the channel is advertising something as enabled because we told it to enable it, and it's possible that the feature has been enabled previously

Your Response Required from Sgt.Monica Lin Brown

I am Sgt.Monica Lin Brown, originally from Lake Jackson Texas USA.I personally made a special research on Internet address book and I came across your information. I am presently writing this mail to you from U.S Military base Kabul Afghanistan I have a secured business proposal for you.Reply

I wait for your prompt response.

properties, hotels and any other viable investment opportunities in your country based on your recommendation will be highly welcomed. Hence your co -operation is highly needed to actualize this investment project I wait for your prompt response. Sincerely yours Mr Sam Azada.

Re: [PATCH net 5/5] net/ncsi: Fix length of GVI response packet

From: Samuel Mendoza-Jonas <s...@mendozajonas.com> Date: Thu, 19 Oct 2017 13:43:09 +1100 > From: Gavin Shan <gws...@linux.vnet.ibm.com> > > The length of GVI (GetVersionInfo) response packet should be 40 instead > of 36. This issue was found from /sys/kern

[PATCH net 5/5] net/ncsi: Fix length of GVI response packet

From: Gavin Shan <gws...@linux.vnet.ibm.com> The length of GVI (GetVersionInfo) response packet should be 40 instead of 36. This issue was found from /sys/kernel/debug/ncsi/eth0/stats. # ethtool --ncsi eth0 swstats : RESPONSE OK TIMEOUT

[PATCH net 5/6] bnxt_en: Fix possible corrupted NVRAM parameters from firmware response.

In bnxt_find_nvram_item(), it is copying firmware response data after releasing the mutex. This can cause the firmware response data to be corrupted if the next firmware response overwrites the response buffer. The rare problem shows up when running ethtool -i repeatedly. Fix it by calling

Waiting for your response to my numerous un-replied emails to you concerning your family inheritance fund ($7.5 million dollars). I seek your assistance and I assured of your capability to champion th

Waiting for your response to my numerous un-replied emails to you concerning your family inheritance fund ($7.5 million dollars). I seek your assistance and I assured of your capability to champion th

Waiting for your response to my numerous un-replied emails to you concerning your family inheritance fund ($7.5 million dollars). I seek your assistance and I assured of your capability to champion th

I am waiting for your response to my numerous un-replied emails to you concerning your family inheritance fund ($7.5 million dollars). I seek your assistance and I assured of your capability to champi

[PATCH net-next v2 08/13] nfp: support variable NSP response lengths

We want to support extendable commands, where newer versions of the management FW may provide more information. Zero out the communication buffer before passing control to NSP. This way if management FW is old and only fills in first N bytes, the remaining ones will be zeros which extended ABI

[PATCH net-next 07/12] nfp: support variable NSP response lengths

We want to support extendable commands, where newer versions of the management FW may provide more information. Zero out the communication buffer before passing control to NSP. This way if management FW is old and only fills in first N bytes, the remaining ones will be zeros which extended ABI

Process phantom ECN event in TCP without CWR response

I'm trying to generate phantom ECN events to (manually) decrease the transmission rate/throughput. The signals is meant to be generated and received on a single host. I don't want the ECN event to generate a CWR (Congestion Window Reduced) response to the sender. I'm trying to think of ways

Process phantom ECN event in TCP without CWR response

I'm trying to generate phantom ECN events to (manually) decrease the transmission rate/throughput. The signals is meant to be generated and received on a single host. I don't want the ECN event to generate a CWR (Congestion Window Reduced) response to the sender. I'm trying to think of ways

[PATCH v4 net-next 09/10] net/ncsi: No error report on DP response to non-existing package

The issue was found from /sys/kernel/debug/ncsi/eth0/stats. The first step in NCSI package/channel enumeration is deselect all packages by sending DP (Deselect Package) commands. The remote NIC replies with response while the corresponding package isn't populated yet and it is treated as an error

[PATCH v4 net-next 10/10] net/ncsi: Fix length of GVI response packet

The length of GVI (GetVersionInfo) response packet should be 40 instead of 36. This issue was found from /sys/kernel/debug/ncsi/eth0/stats. # ethtool --ncsi eth0 swstats : RESPONSE OK TIMEOUT ERROR === GVI 002

Re: [PATCH] net/ncsi: fix checksum validation in response packet

cksum" is in big-endian. > I want to know how Cédric thinks it's a problem. I guess he might > encounter the issue on the emulated NCSI channel by QEMU. yes exactly. my bad. After a second look this is correct. Sorry for the noise. > On BCM5718 or BCM5719, the checksum in AEN and response packet > are zero'd, meaning the software shouldn't validate it at all. Interesting. Thanks, C.

[PATCH v3 net-next 8/8] net/ncsi: Fix length of GVI response packet

The length of GVI (GetVersionInfo) response packet should be 40 instead of 36. This issue was found from /sys/kernel/debug/ncsi/eth0/stats. # cat /sys/kernel/debug/ncsi/eth0/stats : RSP OK TIMEOUT ERROR === GVI 002

[PATCH v3 net-next 7/8] net/ncsi: No error report on DP response to non-existing package

The issue was found from /sys/kernel/debug/ncsi/eth0/stats. The first step in NCSI package/channel enumeration is deselect all packages by sending DP (Deselect Package) commands. The remote NIC replies with response while the corresponding package isn't populated yet and it is treated as an error

Re: [PATCH] net/ncsi: fix checksum validation in response packet

encounter the issue on the emulated NCSI channel by QEMU. On BCM5718 or BCM5719, the checksum in AEN and response packet are zero'd, meaning the software shouldn't validate it at all. Thanks, Gavin

Re: [PATCH] net/ncsi: fix checksum validation in response packet

From: Cédric Le Goater Date: Fri, 14 Apr 2017 10:56:37 +0200 > htonl was used instead of ntohl. Surely a typo. > > Signed-off-by: Cédric Le Goater I don't think so, "checksum" is of type "u32" thus is in host byte order. Therefore "htonl()" is correct.

[PATCH] net/ncsi: fix checksum validation in response packet

htonl was used instead of ntohl. Surely a typo. Signed-off-by: Cédric Le Goater --- net/ncsi/ncsi-rsp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/ncsi/ncsi-rsp.c b/net/ncsi/ncsi-rsp.c index 087db775b3dc..d375286b79f2 100644 --- a/net/ncsi/ncsi-rsp.c

[PATCH v2 net-next 7/8] net/ncsi: No error report on DP response to non-existing package

The issue was found from /sys/kernel/debug/ncsi/eth0/stats. The first step in NCSI package/channel enumeration is deselect all packages by sending DP (Deselect Package) commands. The remote NIC replies with response while the corresponding package isn't populated yet and it is treated as an error

[PATCH v2 net-next 8/8] net/ncsi: Fix length of GVI response packet

The length of GVI (GetVersionInfo) response packet should be 40 instead of 36. This issue was found from /sys/kernel/debug/ncsi/eth0/stats. # cat /sys/kernel/debug/ncsi/eth0/stats : RSP OK TIMEOUT ERROR === GVI 002

[PATCH net-next 7/8] net/ncsi: No error report on DP response to non-existing package

The issue was found from /proc/ncsi/eth0/stats. The first step in NCSI package/channel enumeration is deselect all packages by sending DP (Deselect Package) commands. The remote NIC replies with response while the corresponding package isn't populated yet and it is treated as an error wrongly

[PATCH net-next 8/8] net/ncsi: Fix length of GVI response packet

The length of GVI (GetVersionInfo) response packet should be 40 instead of 36. This issue was found from /proc/ncsi/eth0/stats. # cat /proc/ncsi/eth0/stats : RSP OK TIMEOUT ERROR === GVI 002 With this applied

Re: [PATCHv2 net-next 0/7] sctp: add receiver-side procedures for stream reconf asoc reset and add streams and response

ULL in patch 4/7. > - remove the stream alloc when sending addstrm inreq, and the process in > peer will response it by sending a addstrm out request back in patch 5/7. > - adjust the process of addstrm in resp to fit in the codes that only alloc > streams through addstrm outreq in patch 6/7. Series applied, thanks.

Re: [PATCHv2 net-next 0/7] sctp: add receiver-side procedures for stream reconf asoc reset and add streams and response

On Fri, Mar 10, 2017 at 12:11 PM, Xin Long wrote: > Patch 2/7, 4/7, 5/7, 6/7 are to implement the process of asoc reset request, > add streams requests and all kinds of responses. > > Patch 1/7 and 3/7 are ahead of 2/7 and 4/7 to add two event notification > for asoc reset

[PATCHv2 net-next 6/7] sctp: implement receiver-side procedures for the Reconf Response Parameter

This patch is to implement Receiver-Side Procedures for the Re-configuration Response Parameter in rfc6525 section 5.2.7. sctp_process_strreset_resp would process the response for any kind of reconf request, and the stream reconf is applied only when the response result is success. Signed-off

[PATCHv2 net-next 0/7] sctp: add receiver-side procedures for stream reconf asoc reset and add streams and response

ove sctp_chunk_lookup_strreset_param and reuse it in patch 4/7. - process addstrm outreq as the ack of in addstrm inreq if strreset_chunk is not NULL in patch 4/7. - remove the stream alloc when sending addstrm inreq, and the process in peer will response it by sending a addstrm out request back in patch

Re: [PATCH] net: ipv4: fix table id in getroute response

From: David Ahern Date: Wed, 11 Jan 2017 15:42:17 -0800 > rtm_table is an 8-bit field while table ids are allowed up to u32. Commit > 709772e6e065 ("net: Fix routing tables with id > 255 for legacy software") > added the preference to set rtm_table in dumps to

[PATCH] net: ipv4: fix table id in getroute response

rtm_table is an 8-bit field while table ids are allowed up to u32. Commit 709772e6e065 ("net: Fix routing tables with id > 255 for legacy software") added the preference to set rtm_table in dumps to RT_TABLE_COMPAT if the table id is > 255. The table id returned on get route requests should do the

[PATCHv2 net-next 4/5] sctp: add support for generating stream reconf response chunk

This patch is to define Re-configuration Response Parameter described in rfc6525 section 4.4. As optional fields are only for SSN/TSN Reset Request Parameter, it uses another function to make that. Signed-off-by: Xin Long <lucien@gmail.com> --- include/linux/sctp.h

Your response Is highly appreciated!

I am Mr. Saeed Bin Salem from the National Commercial Bank Libya. I have a secured business proposition for you.

Haster Response.//..

Mr. Steve Bhatti, Drift / regionsjef Santander Bank Plc, 47-48 Piccadilly PICCADILLY W1J0DT London, Storbritannia Hei, Jeg er Steve Bhatti, fra Harlesden North West London, leder for regnskap Revisjonen og formell senior programmerer sjef hos Deutsche bank, her i England (Santander Bank Plc).

Re: [PATCH] net: tcp response should set oif only if it is L3 master

From: David Ahern Date: Wed, 9 Nov 2016 09:07:26 -0800 > Lorenzo noted an Android unit test failed due to e0d56fdd7342: > "The expectation in the test was that the RST replying to a SYN sent to a > closed port should be generated with oif=0. In other words it should

Re: [PATCH] net: tcp response should set oif only if it is L3 master

On Thu, Nov 10, 2016 at 2:07 AM, David Ahern wrote: > Revert the change to ip_send_unicast_reply and tcp_v6_send_response such > that the oif in the flow is set to the skb_iif only if skb_iif is an L3 > master. This fixes the IPv4 and IPv6 tests, thanks! Tested-by:

[PATCH] net: tcp response should set oif only if it is L3 master

Lorenzo noted an Android unit test failed due to e0d56fdd7342: "The expectation in the test was that the RST replying to a SYN sent to a closed port should be generated with oif=0. In other words it should not prefer the interface where the SYN came in on, but instead should follow whatever the

[PATCH net 06/13] rxrpc: Fix loss of PING RESPONSE ACK production due to PING ACKs

Separate the output of PING ACKs from the output of other sorts of ACK so that if we receive a PING ACK and schedule transmission of a PING RESPONSE ACK, the response doesn't get cancelled by a PING ACK we happen to be scheduling transmission of at the same time. If a PING RESPONSE gets lost

  1   2   >