From: Guenter Roeck
Date: Thu, 13 Oct 2016 16:43:16 -0700
> Check answers from USB stack and avoid re-sending the request
> multiple times if the device does not respond.
>
> This fixes the following problem, observed with a probably flaky adapter.
...
> Since the USB
From: Jesse Brandeburg
Date: Thu, 13 Oct 2016 16:13:55 -0700
> Sparse was complaining when we went to prototype some code
> using ethtool_cmd_speed_set and SPEED_10, which uses
> the upper 16 bits of __u32 speed for the first time.
>
> CHECK
> ...
>
On Thu, Oct 13, 2016 at 10:06:28PM -0500, Eric W. Biederman wrote:
> Andrei Vagin writes:
>
> > On Thu, Oct 13, 2016 at 10:49:38AM -0500, Eric W. Biederman wrote:
> >> Andrei Vagin writes:
> >>
> >> > From: Andrey Vagin
> >> >
> >> >
On Fri, Oct 14, 2016 at 08:58:22AM +, Koehrer Mathias (ETAS/ESW5) wrote:
> Hi Julia,
>
> > Have you tested on a vanilla (non-RT) kernel? I doubt there is anything RT
> > specific
> > about what you are seeing, but it might be nice to get confirmation. Also,
> > bisection
> > would probably
Ard Biesheuvel :
> PCI devices that are 64-bit DMA capable should set the coherent
> DMA mask as well as the streaming DMA mask. On some architectures,
> these are managed separately, and so the coherent DMA mask will be
> left at its default value of 32 if it is not
vmxnet3_set_mc() checks new_table_pa returned by dma_map_single()
with dma_mapping_error(), but even there it assumes zero is invalid pa
(it assumes dma_mapping_error(...,0) returns true if new_table is NULL).
The patch adds an explicit variable to track status of new_table_pa.
Found by Linux
From: Kalle Valo
Date: Fri, 14 Oct 2016 10:18:42 +0300
> first wireless-drivers pull request for 4.9 and this time we have
> unusually many fixes even before -rc1 is released. Most important here
> are the wlcore and rtlwifi commits which fix critical regressions,
>
On Fri, Oct 14, 2016 at 08:58:22AM +, Koehrer Mathias (ETAS/ESW5) wrote:
> @@ -753,7 +756,9 @@ u32 igb_rd32(struct e1000_hw *hw, u32 re
> if (E1000_REMOVED(hw_addr))
> return ~value;
>
> +trace_igb(801);
> value = readl(_addr[reg]);
> +
From: Jesse Brandeburg
> Sent: 14 October 2016 00:14
> Sparse was complaining when we went to prototype some code
> using ethtool_cmd_speed_set and SPEED_10, which uses
> the upper 16 bits of __u32 speed for the first time.
...
> Reported-by: Preethi Banala
>
On Fri, Oct 14, 2016 at 12:37:26PM +0200, Florian Westphal wrote:
> Nicolas Dichtel wrote:
> > Le 13/10/2016 à 22:43, Florian Westphal a écrit :
[...]
> > > (Or cause too many useless scans)
> > >
> > > Another idea worth trying might be to get rid of the max cap and
>
On Thu, 2016-10-13 at 14:49 -0700, Andy Lutomirski wrote:
>
> It's failing before that. With CONFIG_VMAP_STACK=y, the stack may
> not be physically contiguous and can't be used for DMA, so putting it
> in a scatterlist is bogus in general, and the crypto code mostly
> wants a scatterlist.
I
Hi Julia,
> Have you tested on a vanilla (non-RT) kernel? I doubt there is anything RT
> specific
> about what you are seeing, but it might be nice to get confirmation. Also,
> bisection
> would probably be easier if you confirm on a vanilla kernel.
>
> I find it unlikely that it's a kernel
On Fri, 2016-10-14 at 10:05 +0100, Ard Biesheuvel wrote:
>
> Indeed. And the decrypt path does the same for auth_tag[].
Hadn't gotten that far, due to the BUG_ON() in CONFIG_DEBUG_SG in the
encrypt path :)
> But that still means there are two separate problems here, one which
> affects the WPA
On Fri, Oct 14, 2016 at 04:32:22PM +1030, Joel Stanley wrote:
>Hi Gavin,
>
>On Fri, Oct 14, 2016 at 1:23 PM, Gavin Shan wrote:
>> This splits out the code that handles ncsi_dev_state_suspend_select
>> so that we can add more code to the handler in subsequent patch.
>>
On Fri, 2016-10-14 at 09:41 +0100, Ard Biesheuvel wrote:
> > I assume the stack buffer itself is not the problem here, but aad,
> > which is allocated on the stack one frame up.
> > Do we really need to revert the whole patch to fix that?
>
> Ah never mind, this is about 'odata'. Apologies,
On Thu, 13 Oct 2016 17:57:42 -0700, Tom Herbert wrote:
> @@ -43,13 +44,11 @@ struct lwtunnel_encap_ops {
> int (*get_encap_size)(struct lwtunnel_state *lwtstate);
> int (*cmp_encap)(struct lwtunnel_state *a, struct lwtunnel_state *b);
> int (*xmit)(struct sk_buff *skb);
> +
> 1. revert that patch (doing so would need some major adjustments now,
> since it's pretty old and a number of new things were added in the
> meantime)
This it will have to be, I guess.
> 2. allocate a per-CPU buffer for all the things that we put on the
> stack and use
i want to subscribe this mail, thank you very much.
subscribe linux-kernel
On 14 October 2016 at 10:10, Johannes Berg wrote:
> On Fri, 2016-10-14 at 10:05 +0100, Ard Biesheuvel wrote:
>>
>> Indeed. And the decrypt path does the same for auth_tag[].
>
> Hadn't gotten that far, due to the BUG_ON() in CONFIG_DEBUG_SG in the
> encrypt path :)
>
>>
On Thu, Oct 13, 2016 at 7:26 PM, Paolo Abeni wrote:
> After the commit 9207f9d45b0a ("net: preserve IP control block
> during GSO segmentation"), the GSO CB and the IPoIB CB conflict.
the commit --> commit (remove the word "the" to make the sentence a
bit more clear)
> That
From: Rafał Miłecki
This simplifies debugging. Format %s (%u) comes from similar debugging
message in brcmf_fweh_event_worker.
Signed-off-by: Rafał Miłecki
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 3 ++-
On (10/13/16 14:49), Andy Lutomirski wrote:
[..]
> > > FAIL: 412cba02 > c900802cba02 || 1 -> (412cba02
> > > >> 39) == 130
> >
> > Yeah, we already know that in this function the aad variable is on the
> > stack, it explicitly is.
> >
> > The question, though, is why precisely
On Thu, 13 Oct 2016 23:22:14 -0700, Roopa Prabhu wrote:
> This removes the last and only user of lwt orig_output. we can drop it
> subsequently. But since orig_input is still in use, probably better to keep it
> around for symmetry and for other uses in the future.
If it's no longer used, let's
> So why is the performance hit acceptable for ESP but not for WPA? We
> could easily implement the same thing, i.e.,
> kmalloc(GFP_ATOMIC)/kfree the aead_req struct rather than allocate it
> on the stack
Yeah, maybe we should. It's likely a much bigger allocation, but I
don't actually know if
Hi Dave,
first wireless-drivers pull request for 4.9 and this time we have
unusually many fixes even before -rc1 is released. Most important here
are the wlcore and rtlwifi commits which fix critical regressions,
otherwise smaller impact fixes and one new sdio id for ath6kl.
Please let me know
While playing with BBR I noticed that it was missing in the list of
possible config DEFAULT_TCP_CONG choices. Fixed thusly.
Signed-off-by: Markus Trippelsdorf
diff --git a/net/ipv4/Kconfig b/net/ipv4/Kconfig
index 300b06888fdf..b54b3ca939db 100644
--- a/net/ipv4/Kconfig
On 14 October 2016 at 09:28, Johannes Berg wrote:
>
>>1. revert that patch (doing so would need some major adjustments now,
>> since it's pretty old and a number of new things were added in the
>> meantime)
>
> This it will have to be, I guess.
>
>>
On 14 October 2016 at 09:42, Johannes Berg wrote:
> On Fri, 2016-10-14 at 09:41 +0100, Ard Biesheuvel wrote:
>
>> > I assume the stack buffer itself is not the problem here, but aad,
>> > which is allocated on the stack one frame up.
>> > Do we really need to revert the
On Fri, 2016-10-14 at 17:39 +0900, Sergey Senozhatsky wrote:
>
> given that we have a known issue shouldn't VMAP_STACK be
> disabled for now, or would you rather prefer to mark MAC80211
> as incompatible: "depends on CFG80211 && !VMAP_STACK"?
Yeah. It's a bit complicated by the fact that most
Le 13/10/2016 à 22:43, Florian Westphal a écrit :
> Nicolas Dichtel wrote:
>> Le 10/10/2016 à 16:04, Florian Westphal a écrit :
>>> Nicolas Dichtel wrote:
After commit b87a2f9199ea ("netfilter: conntrack: add gc worker to remove
On Fri, Oct 14, 2016 at 04:32:28PM +1030, Joel Stanley wrote:
>On Fri, Oct 14, 2016 at 1:23 PM, Gavin Shan wrote:
>> The issue was found on BCM5718 which has two NCSI channels in one
>> package: C0 and C1. Both of them are connected to different LANs,
>> means they are
Nicolas Dichtel wrote:
> Le 13/10/2016 à 22:43, Florian Westphal a écrit :
> > Nicolas Dichtel wrote:
> >> Le 10/10/2016 à 16:04, Florian Westphal a écrit :
> >>> Nicolas Dichtel wrote:
> After commit
Dear David,
> -Original Message-
> From: David Miller [mailto:da...@davemloft.net]
> Sent: Thursday, October 13, 2016 11:20 PM
> To: Izumi, Taku/泉 拓
> Cc: netdev@vger.kernel.org
> Subject: Re: [PATCH 4/6] fjes: Implement debug mode for fjes driver
>
> From: Taku Izumi
On Fri, 2016-10-14 at 09:47 +0100, Ard Biesheuvel wrote:
>
> Do you have a reference for the sg_set_buf() call on odata?
> crypto/ccm.c does not seem to have it (afaict),
It's indirect - crypto_ccm_encrypt() calls crypto_ccm_init_crypt()
which does it.
> and the same problem
> does not exist
On Fri, 2016-10-14 at 10:21 +0100, Ard Biesheuvel wrote:
> It is annotated with a TODO, though :-)
>
> 38320c70d282b (Herbert Xu 2008-01-28 19:35:05
> -0800 41)
> * TODO: Use spare space in skb for this where possible.
I saw that, but I don't think generally there will be spare
gcc 7 complains:
drivers/net/wireless/intersil/p54/fwio.c: In function 'p54_scan':
drivers/net/wireless/intersil/p54/fwio.c:491:4: warning: 'memset' used with
length equal to number of elements without multiplication by element size
[-Wmemset-elt-size]
Fix that by passing the correct size to
Zero allocations before they're passed to drivers to be filled out with
statistics. While many drivers always correctly fill out the entire
allocated space, under some failure conditions some drivers will not
clear the allocated space appropriately. Unprivileged users could
induce some of these
From: Yuval Mintz
Malicious VFs might be caught in several different methods:
- Misusing their bar permission and being blocked by hardware.
- Misusing their fastpath logic and being blocked by firmware.
- Misusing their interaction with their PF via
From: Manish Chopra
This patch adds GSO support for GRE and UDP tunnels
where outer checksums are enabled.
Signed-off-by: Manish Chopra
Signed-off-by: Yuval Mintz
---
From: Manish Chopra
Due to hardware limitation, when transmitting a geneve-encapsulated
packet with more than 32 bytes worth of geneve options the hardware
would not be able to crack the packet and consider it a regular UDP
packet.
This implements the
From: Yuval Mintz
Some hypervisors can support MAC hints to their VFs.
Even though we don't have such a hypervisor API in linux, we add
sufficient logic for the VF to be able to receive such hints and
set the mac accordingly - as long as the VF has not been set
From: Yuval Mintz
Whenever a ramrod is being sent for some device configuration,
the driver is going to sleep at least 5ms between each iteration
of polling on the completion of the ramrod.
However, in almost every configuration scenario the firmware
would be
From: Yuval Mintz
Apparently qede fails to set IFF_UNICAST_FLT, and as a result is not
actually performing unicast MAC filtering.
While we're at it - relax a hard-coded limitation that limits each
interface into using at most 15 unicast MAC addresses before
From: Manish Chopra
Hi David,
There are several new additions in this series;
Most are connected to either Tx offloading or Rx classifications
[either fastpath changes or supporting configuration].
In addition, there's a single IOV enhancement.
Please
From: Manish Chopra
While handling SPQ ramrod completion, there is a possible race
where driver might not read updated fw return code based on
ramrod completion done. This patch ensures that fw return code
is written first and then completion done flag is
On Fri, Oct 14, 2016 at 04:32:36PM +1030, Joel Stanley wrote:
>On Fri, Oct 14, 2016 at 1:23 PM, Gavin Shan wrote:
>> The issue was found on BCM5718 which has two NCSI channels in one
>> package: C0 and C1. C0 is in link-up state while C1 is in link-down
>> state. C0 is
On Fri, 2016-10-14 at 09:33 +0200, Markus Trippelsdorf wrote:
> While playing with BBR I noticed that it was missing in the list of
> possible config DEFAULT_TCP_CONG choices. Fixed thusly.
>
> Signed-off-by: Markus Trippelsdorf
>
> diff --git a/net/ipv4/Kconfig
On 2016.10.14 at 09:43 +0200, Eric Dumazet wrote:
> On Fri, 2016-10-14 at 09:33 +0200, Markus Trippelsdorf wrote:
> > While playing with BBR I noticed that it was missing in the list of
> > possible config DEFAULT_TCP_CONG choices. Fixed thusly.
> >
> > Signed-off-by: Markus Trippelsdorf
On 14 October 2016 at 09:39, Ard Biesheuvel wrote:
> On 14 October 2016 at 09:28, Johannes Berg wrote:
>>
>>>1. revert that patch (doing so would need some major adjustments now,
>>> since it's pretty old and a number of new things
For reference, this was my patch moving the mac80211 buffers to percpu.
diff --git a/net/mac80211/aes_ccm.c b/net/mac80211/aes_ccm.c
index 7663c28ba353..c3709ddf71e9 100644
--- a/net/mac80211/aes_ccm.c
+++ b/net/mac80211/aes_ccm.c
@@ -29,6 +29,8 @@ void ieee80211_aes_ccm_encrypt(struct
On 14 October 2016 at 09:55, Johannes Berg wrote:
> On Fri, 2016-10-14 at 09:47 +0100, Ard Biesheuvel wrote:
>>
>> Do you have a reference for the sg_set_buf() call on odata?
>> crypto/ccm.c does not seem to have it (afaict),
>
> It's indirect - crypto_ccm_encrypt()
On 14 October 2016 at 10:25, Johannes Berg wrote:
> On Fri, 2016-10-14 at 10:21 +0100, Ard Biesheuvel wrote:
>
>> It is annotated with a TODO, though :-)
>>
>> 38320c70d282b (Herbert Xu 2008-01-28 19:35:05
>> -0800 41)
>> * TODO: Use spare space in skb
When using a layer 2 GREv6 tunnel (ip6gretap), I am using a Linux
bridge to push Ethernet frames from an Ethernet port to the GREv6
device.
Here is an example of the topology:
PC -> eth0 -> grebridge -> gre6dev -> (internet) -> GRE endpoint -> Remote host
In this case, the PC connected to the
On (10/14/16 16:09), Duyck, Alexander H wrote:
> Sorry I was thinking of a different piece of code. In the case of the
> atr code it would be hdr.network, not hdr.raw. Basically the thought
> was to validate that there is enough data in skb_headlen() that we can
> verify that from where the
This patch adds implementation of supporting
ethtool -d for fjes driver. By using ethtool -d,
you can get registers dump of Exetnded socket device.
# ethtool -d es0
Offset Values
-- --
0x: 01 00 00 00 08 00 00 00 00 00 00 00 00 00 00 00
0x0010: 00
This patchset updates FUJITSU Extended Socket network driver into version 1.2.
This includes the following enhancements:
- ethtool -d support
- ethtool -S enhancement
- ethtool -w/-W support
- Add some debugging feature (tracepoints etc)
v1 -> v2:
- Use u64 instead of phys_addr_t as
From: Raju Lakkaraju
VSC8531 Fast Link Failure 2 feature enables the PHY to indicate the
onset of a potential link failure in < 100 usec for 100BASE-TX
operation. FLF2 is supported through the MDINT (active low) pin.
Signed-off-by: Raju Lakkaraju
From: Raju Lakkaraju
This series adds support to the Speed downshift, Fast Link Failure 2,
set drivers for Microsemi PHYs.
Patch 1/4: Link Speed downshift:
For operation in cabling environments that are incompatible with
1000BAST-T, VSC8531 device
Andrew Lunn wrote:
Please can you tell us what PHY which is, and how it is put to sleep
and woken up.
It's the at803x driver.
http://lxr.free-electrons.com/source/drivers/net/phy/at803x.c
It goes to sleep in its at803x_suspend() function, which is called by
phy_suspend().
There is a
From: Ard Biesheuvel
Date: Fri, 14 Oct 2016 12:39:30 +0100
> PCI devices that are 64-bit DMA capable should set the coherent
> DMA mask as well as the streaming DMA mask. On some architectures,
> these are managed separately, and so the coherent DMA mask will be
> left
> So use kzalloc
Do we really need kzalloc()? We have things on the stack right now, and
don't initialize, so surely we don't really need to zero things?
> This only addresses one half of the problem. The other problem, i.e.,
> the fact that the aad[] array lives on the stack of the caller, is
On Fri, Oct 14, 2016 at 08:03:18AM -0500, Timur Tabi wrote:
> Andrew Lunn wrote:
> >Have you tried using the ethernet-phy-id device tree property? It
> >looks like that will allow you to skip get_phy_device and just create
> >the phy device. You can then bring the phy out of sleep in the probe
>
On 14 October 2016 at 14:15, Johannes Berg wrote:
> On Fri, 2016-10-14 at 14:13 +0100, Ard Biesheuvel wrote:
>>
>> > But if we allocate things anyway, is it worth expending per-CPU
>> > buffers on these?
>>
>> Ehmm, maybe not. I could spin a v2 that allocates a bigger
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Christopher S. Hall
commit 6bd58f09e1d8cc6c50a824c00bf0d617919986a1 upstream.
The timekeeping code does not currently provide a way to translate
externally
> On Fri, Oct 14, 2016 at 05:10:33PM +0530, Raju Lakkaraju wrote:
> From: Raju Lakkaraju
>
> VSC8531 Fast Link Failure 2 feature enables the PHY to indicate the
> onset of a potential link failure in < 100 usec for 100BASE-TX
> operation. FLF2 is supported through
Andrew Lunn wrote:
So are you seeing that the reads to MII_PHYSID1 and MII_PHYSID2 return
0x, when called from get_phy_id()?
Yes.
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the
Code Aurora Forum, hosted by The Linux
> It's the at803x driver.
The at803x_resume() just does normal MDIO transactions. Which suggests
the MDIO bus side of the device is still away. Or at least, the
MII_BMCR register is.
So are you seeing that the reads to MII_PHYSID1 and MII_PHYSID2 return
0x, when called from get_phy_id()?
From: Of Ard Biesheuvel
> Sent: 14 October 2016 14:41
> PCI devices that are 64-bit DMA capable should set the coherent
> DMA mask as well as the streaming DMA mask. On some architectures,
> these are managed separately, and so the coherent DMA mask will be
> left at its default value of 32 if it
>
> Is the aad[] actually reused? I would assume it only affects the mac
> on encryption, and the verification on decryption but I don't think
> we actually need it back from the crypto routines.
I don't think it's reused.
> Exactly what you said above :-) My patch only touches CCM but as you
Pablo Neira Ayuso wrote:
> I would prefer not to expose sysctl knobs, if we don't really know
> what good default values are good, then we cannot expect our users to
> know this for us.
>
> I would go tune this in a way that this resembles to the previous
> behaviour.
I do
On 14 October 2016 at 14:31, David Miller wrote:
> From: Ard Biesheuvel
> Date: Fri, 14 Oct 2016 12:39:30 +0100
>
>> PCI devices that are 64-bit DMA capable should set the coherent
>> DMA mask as well as the streaming DMA mask. On some
From: Ard Biesheuvel
Date: Fri, 14 Oct 2016 14:32:24 +0100
> On 14 October 2016 at 14:31, David Miller wrote:
>> From: Ard Biesheuvel
>> Date: Fri, 14 Oct 2016 12:39:30 +0100
>>
>>> PCI devices that are 64-bit DMA
PCI devices that are 64-bit DMA capable should set the coherent
DMA mask as well as the streaming DMA mask. On some architectures,
these are managed separately, and so the coherent DMA mask will be
left at its default value of 32 if it is not set explicitly. This
results in errors such as
On Sat, Aug 20, 2016 at 3:51 PM, Baozeng Ding wrote:
> Hello all,
> The following program triggers stack-out-of-bounds in memcmp. The kernel
> version is 4.8.0-rc1+ (on Aug 13 commit
> 118253a593bd1c57de2d1193df1ccffe1abe745b). Thanks.
...
>
> #define _GNU_SOURCE
>
> -Original Message-
> From: Manish Chopra [mailto:manish.cho...@qlogic.com]
> Sent: Thursday, October 13, 2016 4:53 PM
> To: da...@davemloft.net
> Cc: netdev@vger.kernel.org; yuval.mi...@qlogic.com; Chopra, Manish
>
> Subject: [PATCH v2 net-next 0/7] qed*:
Andrew Lunn wrote:
Normally, a sleeping PHY does respond to MDIO. Otherwise, how do you
wake it?
So i assume this phy has some other means to wake it. What is this
means?
I'm guessing that someone has to call phy_resume() before/during the
call to mdiobus_register, but I don't see how that's
This patch adds debugfs entry to show EP status information.
You can get each EP's status information like the following:
# cat /sys/kernel/debug/fjes/fjes.0/status
EPIDSTATUS SAME_ZONECONNECTED
ep0 shared YY
ep1 --
This patch adds tracepoints in fjes driver.
This is useful for debugging purpose.
Signed-off-by: Taku Izumi
---
drivers/net/fjes/Makefile | 2 +-
drivers/net/fjes/fjes_hw.c| 25 +++-
drivers/net/fjes/fjes_main.c | 5 +
drivers/net/fjes/fjes_trace.c | 30
This patch adds implementation of supporting
ethtool -w and -W for fjes driver.
You can enable and disable firmware debug mode by
using ethtool -W, and also retrieve firmware
activity information by using ethtool -w.
This is useful for debugging.
Signed-off-by: Taku Izumi
This patch enhances ethtool -S for fjes driver so that
EP related statistics can be retrieved.
The following statistics can be displayed via ethtool -S:
ep%d_com_regist_buf_exec
ep%d_com_unregist_buf_exec
ep%d_send_intr_rx
ep%d_send_intr_unshare
ep%d_send_intr_zoneupdate
Signed-off-by: Taku Izumi
---
drivers/net/fjes/fjes_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/fjes/fjes_main.c b/drivers/net/fjes/fjes_main.c
index 359e7a5..f36eb4a 100644
--- a/drivers/net/fjes/fjes_main.c
+++
PCI devices that are 64-bit DMA capable should set the coherent
DMA mask as well as the streaming DMA mask. On some architectures,
these are managed separately, and so the coherent DMA mask will be
left at its default value of 32 if it is not set explicitly. This
results in errors such as
From: Raju Lakkaraju
For operation in cabling environments that are incompatible with
1000BAST-T, VSC8531 device provides an automatic link speed
downshift operation. When enabled, the device automatically changes
its 1000BAST-T auto-negotiation to the next slower
On Fri, 2016-10-14 at 15:10 +0200, Johannes Berg wrote:
> >
> > So use kzalloc
>
> Do we really need kzalloc()? We have things on the stack right now,
> and don't initialize, so surely we don't really need to zero things?
Err, never mind, I'm an idiot - we *do* initialize to 0, of course.
On 14 October 2016 at 14:10, Johannes Berg wrote:
>
>> So use kzalloc
>
> Do we really need kzalloc()? We have things on the stack right now, and
> don't initialize, so surely we don't really need to zero things?
>
>> This only addresses one half of the problem. The
On 14 October 2016 at 14:34, David Miller wrote:
> From: Ard Biesheuvel
> Date: Fri, 14 Oct 2016 14:32:24 +0100
>
>> On 14 October 2016 at 14:31, David Miller wrote:
>>> From: Ard Biesheuvel
>>>
> On 14 Oct 2016, at 14:42, David Laight wrote:
>
> From: Of Ard Biesheuvel
>> Sent: 14 October 2016 14:41
>> PCI devices that are 64-bit DMA capable should set the coherent
>> DMA mask as well as the streaming DMA mask. On some architectures,
>> these are managed
From: Brenden Blanco
Date: Thu, 13 Oct 2016 13:13:11 -0700
> In cases where the number of tx rings is not a multiple of the number of
> rx rings, the tx completion event will be handled on a different core
> from the transmit and population of the ring. Races on the ring
From: Markus Trippelsdorf
Date: Fri, 14 Oct 2016 10:07:16 +0200
> On 2016.10.14 at 09:43 +0200, Eric Dumazet wrote:
>> On Fri, 2016-10-14 at 09:33 +0200, Markus Trippelsdorf wrote:
>> > While playing with BBR I noticed that it was missing in the list of
>> > possible
From: Tom Herbert
Date: Thu, 13 Oct 2016 17:57:42 -0700
> @@ -130,6 +130,19 @@ int lwtunnel_build_state(struct net_device *dev, u16
> encap_type,
> }
> EXPORT_SYMBOL(lwtunnel_build_state);
>
> +void lwtstate_free(struct lwtunnel_state *lws)
There should only be one
On 14 October 2016 at 11:00, Johannes Berg wrote:
>
>> So why is the performance hit acceptable for ESP but not for WPA? We
>> could easily implement the same thing, i.e.,
>> kmalloc(GFP_ATOMIC)/kfree the aead_req struct rather than allocate it
>> on the stack
>
> Yeah,
On Fri, Oct 14, 2016 at 05:10:32PM +0530, Raju Lakkaraju wrote:
> From: Raju Lakkaraju
>
> For operation in cabling environments that are incompatible with
> 1000BAST-T, VSC8531 device provides an automatic link speed
> downshift operation. When enabled, the device
On 10/14/16 12:33 AM, Eric Dumazet wrote:
> There is a catch here.
> TCP moves IP6CB() in a different location.
>
> Reference :
>
> 971f10eca186 ("tcp: better TCP_SKB_CB layout to reduce cache line misses")
thanks for the reference.
> Problem is that the lookup can happen from IP early demux,
On Fri, Oct 14, 2016 at 07:49:56AM -0500, Timur Tabi wrote:
> Andrew Lunn wrote:
> >So are you seeing that the reads to MII_PHYSID1 and MII_PHYSID2 return
> >0x, when called from get_phy_id()?
Have you tried using the ethernet-phy-id device tree property? It
looks like that will allow you to
Andrew Lunn wrote:
Does the datasheet say anything about this?
I would say for this device, suspend() is too aggressive.
I'll have to find the datasheet. Let me do some research and get back
to you. Thanks for your help so far.
--
Sent by an employee of the Qualcomm Innovation Center,
On Fri, 2016-10-14 at 14:13 +0100, Ard Biesheuvel wrote:
>
> > But if we allocate things anyway, is it worth expending per-CPU
> > buffers on these?
>
> Ehmm, maybe not. I could spin a v2 that allocates a bigger buffer,
> and copies aad[] into it as well
Copies in/out, I guess. Also there's
From: Yuval Mintz
Date: Thu, 13 Oct 2016 22:57:00 +0300
> The first patch in this series follows Dan Carpenter's reports about
> Smatch warnings for recent qed additions and fixes those.
>
> The second patch is the most significant one [and the reason this is
>
On 10/14/16 6:21 AM, David Ahern wrote:
>> So you might need to let the caller pass IP6CB(skb)->flags (or
>> TCP_SKB_CB(skb)->header.h6.flags ) instead of skb since
>> inet6_exact_dif_match() does not know where to fetch the flags.
>>
>> Same issue for IPv4.
>
> I'll update the match functions to
From: Manish Chopra
Date: Fri, 14 Oct 2016 05:19:16 -0400
> There are several new additions in this series;
> Most are connected to either Tx offloading or Rx classifications
> [either fastpath changes or supporting configuration].
>
> In addition, there's a single IOV
1 - 100 of 159 matches
Mail list logo