On Friday, October 14, 2016 11:23:09 AM CEST Jiri Slaby wrote:
> 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
Convert rocker to the new dev walk API. This is just a code conversion;
no functional change is intended.
Signed-off-by: David Ahern
---
drivers/net/ethernet/rocker/rocker_main.c | 31 ---
1 file changed, 24 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethe
Lower list should be empty just like upper.
Signed-off-by: David Ahern
---
net/core/dev.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/net/core/dev.c b/net/core/dev.c
index a012c7266230..99a1cb432945 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -5225,6 +5225,20 @@
Only direct adjacencies are maintained. All upper or lower devices can
be learned via the new walk API which recursively walks the adj_list for
upper devices or lower devices.
Signed-off-by: David Ahern
---
include/linux/netdevice.h | 25 -
net/core/dev.c| 229 +-
Convert mlxsw users to new dev walk API. This is just a code conversion;
no functional change is intended.
Signed-off-by: David Ahern
---
drivers/net/ethernet/mellanox/mlxsw/spectrum.c | 37 --
1 file changed, 23 insertions(+), 14 deletions(-)
diff --git a/drivers/net/et
Convert ixgbe users to new dev walk API. This is just a code conversion;
no functional change is intended.
Signed-off-by: David Ahern
---
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 132 --
1 file changed, 82 insertions(+), 50 deletions(-)
diff --git a/drivers/net/et
Adjacency code only has debugs for the insert case. Add debugs for
the remove path and make both consistently worded to make it easier
to follow the insert and removal with reference counts.
In addition, change the BUG to a WARN_ON. A missing adjacency at
removal time is not cause for a panic.
Si
This patch introduces netdev_walk_all_upper_dev_rcu,
netdev_walk_all_lower_dev and netdev_walk_all_lower_dev_rcu. These
functions recursively walk the adj_list of devices to determine all upper
and lower devices.
The functions take a callback function that is invoked for each device
in the list. I
Convert ipoib_get_net_dev_match_addr to the new upper device walk API.
This is just a code conversion; no functional change is intended.
Signed-off-by: David Ahern
---
drivers/infiniband/ulp/ipoib/ipoib_main.c | 37 +--
1 file changed, 25 insertions(+), 12 deletions(-
Convert alb_send_learning_packets and bond_has_this_ip to use the new
netdev_walk_all_upper_dev_rcu API. In both cases this is just a code
conversion; no functional change is intended.
Signed-off-by: David Ahern
---
drivers/net/bonding/bond_alb.c | 82 ++---
Convert rdma_is_upper_dev_rcu, handle_netdev_upper and
ipoib_get_net_dev_match_addr to the new upper device walk API.
This is just a code conversion; no functional change is intended.
Signed-off-by: David Ahern
---
drivers/infiniband/core/core_priv.h | 9 +--
drivers/infiniband/core/roc
Commit 93409033ae65 ("net: Add netdev all_adj_list refcnt propagation to
fix panic") propagated the refnr to insert and remove functions tracking
the netdev adjacency graph. However, for the insert path the refnr can
only be 1. Accordingly, remove the refnr argument to make that clear.
ie., the ref
The netdev adjacency tracking is failing to create proper dependencies
for some topologies. For example this topology
++
| myvrf |
++
||
| +-+
| | macvlan |
| +-+
||
+---
From: Vlad Tsyrklevich
Date: Fri, 14 Oct 2016 11:59:18 +0200
> enic_get_ethtool_stats()
Looknig merely at this shows the real problem.
We don't propagate and handle errors for this method.
And that's what we should fix, making the get_ethtool_stats() method
return an integer error.
Then ethto
sunbmac uses '__u32' for dma handle while invoking kernel DMA APIs,
instead of using dma_addr_t. This hasn't caused any 'incompatible
pointer type' warning on SPARC because until now dma_addr_t is of
type u32. However, recent changes in SPARC ATU (iommu) enables 64bit
DMA and therefore dma_addr_t b
Recently, ATU (iommu) changes are submitted to linux-sparc that
enables 64bit DMA on SPARC. However, this change also makes
'incompatible pointer type' compiler warnings inevitable on sunqe
and sunbmac driver.
The two patches in series fix compiler warnings.
Tushar Dave (2):
sunqe: Fix compiler
sunqe uses '__u32' for dma handle while invoking kernel DMA APIs,
instead of using dma_addr_t. This hasn't caused any 'incompatible
pointer type' warning on SPARC because until now dma_addr_t is of
type u32. However, recent changes in SPARC ATU (iommu) enables 64bit
DMA and therefore dma_addr_t bec
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 netwo
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 Et
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(&hw_addr[reg]);
> +trace_igb(80
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
> >> >
> >> > The operation of destroying netns is heavy and it is execute
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 Dri
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 set explicitly. This
> results
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
> ...
> .../uapi/linux/ethtool.h:123:28: warning:
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,
> otherwise smaller impact fixes
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 timeout is 5 seconds, and
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
I am getting warnings about sign missmatch.
Maybe make SPEED_UNKNOWN be ((__u32)(0x)) ?
from ethtool.h:
#define SPEED_UNKNOWN -1
static inline int ethtool_validate_speed(__u32 speed)
{
return speed <= INT_MAX || speed == SPEED_UNKNOWN;
}
Thanks,
Ben
--
Ben Greear
C
Currently, socket lookups for l3mdev (vrf) use cases can match a socket
that is bound to a port but not a device (ie., a global socket). If the
sysctl tcp_l3mdev_accept is not set this leads to ack packets going out
based on the main table even though the packet came in from an L3 domain.
The end r
PTR_ERR(NULL) is success. We have to preserve the error code earlier.
Fixes: 7086605a6ab5 ("stmmac: fix error check when init ptp")
Signed-off-by: Dan Carpenter
---
Applies to net.git tree.
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.c
b/drivers/net/ethernet/stmicro/stmmac/stmm
There is a race condition that can occur if EMAC interrupts are
enabled when phy_disconnect() is called. phy_disconnect() sets
adjust_link to NULL. When an interrupt occurs, the ISR might
call phy_mac_interrupt(), which wakes up the workqueue function
phy_state_machine(). This function might ref
Hi David,
I'm really sorry if I messed up, or is not following the protocol...
But you have applied it already:
http://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/commit/?id=4f58e6dceb0e44ca8f21568ed81e1df24e55964c
> commit 4f58e6dceb0e44ca8f21568ed81e1df24e55964c
> Author: Allan
Andrew Lunn wrote:
It is normal to get the phy-mode from device tree. I've no idea what
ACPI is supposed to do. Setting it to PHY_INTERFACE_MODE_NA means you
assume the boot loader has correctly setup the hardware. You ACPI
firmware might of done this, but there is no guarantee a device tree
bas
Add a dst_cache to ila_lwt structure. This holds a cached route for the
translated address. In ila_output we now perform a route lookup after
translation and if possible (destination in original route is full 128
bits) we set the dst_cache. Subsequent calls to ila_output can then use
the cache to a
Users of lwt tunnels may set up some secondary state in build_state
function. Add a corresponding destroy_state function to allow users to
clean up state. This destroy state function is called from lwstate_free.
Also, we now free lwstate using kfree_rcu so user can assume structure
is not freed bef
Add a dst_cache to ila_lwt structure. This holds a cached route for the
translated address. In ila_output we now perform a route lookup after
translation and if possible (destination in original route is full 128
bits) we set the dst_cache. Subsequent calls to ila_output can then use
the cache to a
On Fri, Oct 14, 2016 at 11:57:29AM -0500, Timur Tabi wrote:
> Andrew Lunn wrote:
> >That is a basic assumption of the code. If you cannot read the IDs how
> >are you supposed to know what device it is, and what quirks you need
> >to work around its broken features...
> >
> >Does the datasheet say a
Andrew Lunn wrote:
That is a basic assumption of the code. If you cannot read the IDs how
are you supposed to know what device it is, and what quirks you need
to work around its broken features...
Does the datasheet say anything about this?
I would say for this device, suspend() is too aggressi
> -Original Message-
> From: Sowmini Varadhan [mailto:sowmini.varad...@oracle.com]
> Sent: Thursday, October 13, 2016 8:49 PM
> To: Duyck, Alexander H
> Cc: netdev@vger.kernel.org
> Subject: Re: bug in ixgbe_atr
>
> On (10/14/16 02:06), Duyck, Alexander H wrote:
> > > + case ETH_P_IP:
>
From: Taku Izumi
Date: Fri, 14 Oct 2016 20:25:44 +0900
> 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 (t
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 enhancement.
>
> Please c
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: 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 space between "void" and
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 config DEFAULT_TCP_CONG choic
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
> ntended for 'net'] - it's based on
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 will
> lead to a double-f
From: Tom Herbert
Date: Thu, 13 Oct 2016 12:29:46 -0700
> On Thu, Oct 13, 2016 at 12:17 PM, David Miller wrote:
>> This socket lookup is very heavy handed, and I realize that you
>> need this because we no longer store the encapsulation socket in
>> skb->sk these days.
>>
> I don't quite underst
From: "Allan W. Nielsen"
Date: Thu, 13 Oct 2016 20:21:30 +0200
> Edge-Rate cleanup include the following:
> - Updated device tree bindings documentation for edge-rate
> - The edge-rate is now specified as a "slowdown", meaning that it is now
> being specified as positive values instead of negat
From: Jiri Bohac
Date: Thu, 13 Oct 2016 18:52:15 +0200
> The IPv6 temporary address generation uses a variable called DESYNC_FACTOR
> to prevent hosts updating the addresses at the same time. Quoting RFC 4941:
>
>... The value DESYNC_FACTOR is a random value (different for each
>client)
From: Jiri Bohac
Date: Thu, 13 Oct 2016 18:50:02 +0200
> The randomized interface identifier (rndid) was periodically updated from
> the regen_timer timer. Simplify the code by updating the rndid only when
> needed by ipv6_try_regen_rndid().
>
> This makes the follow-up DESYNC_FACTOR fix much si
From: Paolo Abeni
Date: Thu, 13 Oct 2016 18:26:56 +0200
> After the commit 9207f9d45b0a ("net: preserve IP control block
> during GSO segmentation"), the GSO CB and the IPoIB CB conflict.
> That destroy the IPoIB address information cached there,
> causing a severe performance regression, as bett
On Fri, 2016-10-14 at 13:23 +0300, Or Gerlitz wrote:
>
> Paolo,
>
> Is this fix backportable to any kernel since the breakage?
yes, AFAIK this is beck-portable.
> AFAIR,
> Roland mentioned
> that a 2nd change introduced in 4.7-rc1 changed things a bit more such
> that the fix
> he had in his h
From: David Howells
Date: Thu, 13 Oct 2016 17:12:09 +0100
>
> This set of patches contains a bunch of fixes:
>
> (1) Fix use of kunmap() after change from kunmap_atomic() within AFS.
>
> (2) Don't use of ERR_PTR() with an always zero value.
>
> (3) Check the right error when using ip6_rout
From: Alexander Alemayhu
Date: Thu, 13 Oct 2016 17:09:51 +0200
> This fixes the following errors when trying to clone the urls:
>
> Cloning into 'net'...
> fatal: repository
> 'http://git.kernel.org/cgit/linux/kernel/git/davem/net.git/' not found
> Cloning into 'net-next'...
> fatal: repository
From: Shmulik Ladkani
Date: Thu, 13 Oct 2016 09:06:40 +0300
> This patch series implements action mirred 'ingress' actions
> TCA_INGRESS_REDIR and TCA_INGRESS_MIRROR.
>
> This allows attaching filters whose target is to hand matching skbs into
> the rx processing of a specified device.
>
> v4:
> On 14 Oct 2016, at 14:46, Johannes Berg wrote:
>
>
>>
>> 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.
>
>> Exa
From: David Ahern
Date: Wed, 12 Oct 2016 13:51:48 -0700
> The netdev adjacency tracking is failing to create proper dependencies
> for some topologies. For example this topology
>
> ++
> | myvrf |
> ++
> ||
> | +-+
>
From: Javier Martinez Canillas
Date: Wed, 12 Oct 2016 15:55:41 -0300
> When the device is registered via OF, the OF table is used to match the
> driver instead of the SPI device ID table, but the entries in the later
> are used as aliasses to load the module if the driver was not built-in.
>
> T
From: Javier Martinez Canillas
Date: Wed, 12 Oct 2016 15:55:40 -0300
> If the driver is built as a module, module alias information isn't filled
> so the module won't be autoloaded. Add a SPI device ID table and use the
> MODULE_DEVICE_TABLE() macro so the information is exported in the module.
>
From: Javier Martinez Canillas
Date: Wed, 12 Oct 2016 16:05:59 -0300
> The driver only has runtime but no build time dependency with FSL_SOC ||
> ARCH_MXC || ARCH_LAYERSCAPE. So it can be built for testing purposes if
> the COMPILE_TEST option is enabled.
>
> This is useful to have more build c
From: Nicolas Dichtel
Date: Wed, 12 Oct 2016 10:10:40 +0200
> The goal of the patch is to fix this scenario:
> ip link add dummy1 type dummy
> ip link set dummy1 up
> ip link set lo down ; ip link set lo up
>
> After that sequence, the local route to the link layer address of dummy1 is
> not
From: ebied...@xmission.com (Eric W. Biederman)
Date: Thu, 13 Oct 2016 22:06:28 -0500
> Oh that is a surprise. We can definitely skip genenerating uevents for
> network namespaces that are exiting because by definition no one can see
> those network namespaces. If a socket existed that could see
From: Stephen Hemminger
Date: Tue, 11 Oct 2016 13:04:09 -0700
>
> This reverts commit 6ae23ad36253a8033c5714c52b691b84456487c5.
>
> The code has been in kernel since 4.4 but there are no in tree
> code that uses. Unused code is broken code, remove it.
>
> Signed-off-by: Stephen Hemminger
App
From: Vadim Fedorenko
Date: Tue, 11 Oct 2016 22:47:20 +0300
> The commit ea3dc9601bda ("ip6_tunnel: Add support for wildcard tunnel
> endpoints.") introduces support for wildcards in tunnels endpoints,
> but in some rare circumstances ip6_tnl_lookup selects wrong tunnel
> interface relying only o
> 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 separately, and so the coherent
> 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 separately, and so the coherent
>
> 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
>
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 i
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 B_0/
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
r81
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
>>> Date: Fri, 14 Oct 2016 12:39:30 +0100
>>>
PCI devices that are 64-bit DMA capable should set th
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 architectures,
>> these are managed separately, and so the co
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 capable should set the coherent
>>> DMA mask as well as the streaming DMA mask. O
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, Inc
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 at its default value of 32
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 buffer,
>> and copies aad[] i
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
> >f
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 other problem, i.e.,
>> the fac
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.
joha
> 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
>
Some CCM implementations (such as the generic CCM wrapper in crypto/)
use scatterlists to map fields of struct aead_req. This means these
data structures cannot live in the vmalloc area, which means that in
the near future, they can no longer live on the stack either.
Given that these data structu
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
function?
The problem I'm experiencing is with ACPI, so I can't use any
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 s
> 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()?
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 Fo
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 corres
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 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 automatically changes
> its 100
On Fri, Oct 14, 2016 at 06:38:47AM -0500, Timur Tabi wrote:
> 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_res
> 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 the MDINT (active low) pin.
Is
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 provides an automatic link spee
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 speed after
a configured number
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 provided clocksource cycles to system
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
Signed-off-by: Allan W. Nielsen
---
.../device
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
---
drivers/net/fjes/
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
+++ b/drivers/net/fjes/fjes_main.c
@@ -30,7 +
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
r81
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 --
1 - 100 of 152 matches
Mail list logo
