On Mon, Feb 04, 2019 at 12:09:00PM -0800, David Miller wrote:
> From: Gregory Rose
> Date: Mon, 4 Feb 2019 11:41:29 -0800
>
> >
> > On 2/3/2019 1:12 AM, Eli Britstein wrote:
> >> Declare ovs key structures using macros as a pre-step towards to
> >> enable retrieving fields information, as a work
On Thu, Feb 07, 2019 at 09:46:23AM -0800, Yizhuo wrote:
> In function sun8i_dwmac_set_syscon(), local variable "val" could
> be uninitialized if function regmap_read() returns -EINVAL.
> However, it will be used directly in the if statement, which
> is potentially unsafe.
>
> Signed-off-by: Yizhuo
On Thu, Feb 07, 2019 at 04:40:11PM -0800, David Ahern wrote:
> On 2/6/19 11:42 AM, Ido Schimmel wrote:
> > Create a new FIB entry type for blackhole routes and set it in case the
> > type of the notified route is 'RTN_BLACKHOLE'.
> >
> > Program such routes with a discard action and mark them as o
Fri, Feb 08, 2019 at 04:42:41AM CET, gust...@embeddedor.com wrote:
>One of the more common cases of allocation size calculations is finding
>the size of a structure that has a zero-sized array at the end, along
>with memory for some number of elements for that array. For example:
>
>struct foo {
>
Bit 0 in register 1.5 doesn't represent a device but is a flag that
Clause 22 registers are present. Therefore disregard this bit when
populating the device list. If code needs this information it
should read register 1.5 directly instead of accessing the device
list. Because this bit doesn't repre
On Thu, Feb 07, 2019 at 11:53:40PM +, Nunley, Nicholas D wrote:
> > > @@ -5390,7 +5438,19 @@ static int do_perqueue(struct cmd_context *ctx)
> > > if (i < 0)
> > > exit_bad_args();
> > >
> > > - /* no sub_command support yet */
> > > + if (strstr(args[i].opts, "--show-coalesce") !=
Sander Eikelenboom wrote:
> L.S.,
>
> While trying out a 5.0-RC5 kernel I seem to have stumbled over a regression
> with NAT.
> (using an nftables firewall with NAT and connection tracking).
>
> Unfortunately it isn't too obvious since no errors are logged, but on clients
> it
> causes symptom
On Thu, Feb 07, 2019 at 11:37:19PM +, Nunley, Nicholas D wrote:
> From: Michal Kubecek [mailto:mkube...@suse.cz]
> > On Tue, Feb 05, 2019 at 04:01:03PM -0800, Jeff Kirsher wrote:
> > > Introduce a new ioctl for setting per-queue parameters.
> > > Users can apply commands to specific queues by s
On Thu, Feb 07, 2019 at 11:21:41PM +0100, Daniel Borkmann wrote:
> On 02/07/2019 08:27 AM, Martin Lau wrote:
> [...]
> > Following up the discussion in the iovisor conf call.
> >
> > One of discussion was about:
> > other than tw, can __sk_buff->sk always return a
> > fullsock (PTR_TO_SOCKET_OR_NU
Hi all,
After commit 8c5ad0dae93c ("igc: Add ethtool support"), Clang warns:
drivers/net/ethernet/intel/igc/igc_ethtool.c:9:19: warning: variable
'igc_priv_flags_strings' is not needed and will not be emitted
[-Wunneeded-internal-declaration]
static const char igc_priv_flags_strings[][ETH_GSTRI
net/core/ethtool.c:3023:19: warning: address of array
'ext_m_spec->h_dest' will always evaluate to 'true'
[-Wpointer-bool-conversion]
if (ext_m_spec->h_dest) {
~~ ^~
h_dest is an array, it can't be null so remove this check.
Fixes: eca4205f9ec3 ("e
One of the more common cases of allocation size calculations is finding
the size of a structure that has a zero-sized array at the end, along
with memory for some number of elements for that array. For example:
struct foo {
int stuff;
struct boo entry[];
};
size = sizeof(struct foo) + cou
One of the more common cases of allocation size calculations is finding
the size of a structure that has a zero-sized array at the end, along
with memory for some number of elements for that array. For example:
struct foo {
int stuff;
struct boo entry[];
};
size = sizeof(struct foo) + cou
One of the more common cases of allocation size calculations is finding
the size of a structure that has a zero-sized array at the end, along
with memory for some number of elements for that array. For example:
struct foo {
int stuff;
struct boo entry[];
};
size = sizeof(struct foo) + cou
Currently the only way to clear the mfc cache was to delete the entries
one by one using the MRT_DEL_MFC socket option or to destroy and
recreate the socket.
Create a new socket option which will clear the multicast forwarding
cache on the socket without destroying the socket. The new socket optio
Created a way to clear the multicast forwarding cache on a socket
without having to either remove the entries manually using the delete
entry socket option or destroy and recreate the multicast socket.
Using the flags MRT_FLUSH_ENTRIES and MRT_FLUSH_VIFS, all multicast
entries can be cleared, all
From: Tristram Ha
Remove unnecessary header include lines.
Signed-off-by: Tristram Ha
---
drivers/net/dsa/microchip/ksz9477.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/net/dsa/microchip/ksz9477.c
b/drivers/net/dsa/microchip/ksz9477.c
index 8391b9e..7c51edd 100644
--- a/dr
On 2/7/19 10:00 PM, Joe Perches wrote:
> On Thu, 2019-02-07 at 18:28 -0600, Gustavo A. R. Silva wrote:
>> One of the more common cases of allocation size calculations is finding
>> the size of a structure that has a zero-sized array at the end, along
>> with memory for some number of elements fo
From: Tristram Ha
Replace register polling functions using timeout with readx_poll_time call.
Signed-off-by: Tristram Ha
---
drivers/net/dsa/microchip/ksz9477.c | 91 +++--
1 file changed, 27 insertions(+), 64 deletions(-)
diff --git a/drivers/net/dsa/microchip
From: Tristram Ha
This series of patches is to modify the KSZ9477 DSA driver to read MIB
counters periodically to avoid overflow.
v1
- Use readx_poll_time
- Do not clear MIB counters when port is enabled
- Do not advertise 1000 half-duplex mode when port is enabled
- Do not use freeze function a
From: Tristram Ha
Add MIB counter reading support.
Signed-off-by: Tristram Ha
---
drivers/net/dsa/microchip/ksz9477.c| 139 +++--
drivers/net/dsa/microchip/ksz_common.c | 96 +++
drivers/net/dsa/microchip/ksz_common.h | 2 +
drivers/net/ds
From: Tristram Ha
Prepare PHY for proper advertisement and get link status for the port.
Signed-off-by: Tristram Ha
---
drivers/net/dsa/microchip/ksz9477.c| 17 -
drivers/net/dsa/microchip/ksz_common.c | 19 ++-
drivers/net/dsa/microchip/ksz_common.h | 4 ++
From: Tristram Ha
The flag offload_fwd_mark is set as the switch can forward frames by
itself.
This can be considered a fix to a problem introduced in commit
c2e866911e254067 where the port membership are not set in sync. The flag
offload_fwd_mark just needs to be set in tag_ksz.c to prevent th
On Thu, 2019-02-07 at 18:40 -0600, Gustavo A. R. Silva wrote:
> Make use of the struct_size() helper instead of an open-coded version
> in order to avoid any potential type mistakes, in particular in the
> context in which this code is being used.
>
> So, change the following form:
>
> sizeof(*ev
On Thu, 2019-02-07 at 18:28 -0600, Gustavo A. R. Silva wrote:
> One of the more common cases of allocation size calculations is finding
> the size of a structure that has a zero-sized array at the end, along
> with memory for some number of elements for that array. For example:
>
> struct foo {
>
One of the more common cases of allocation size calculations is finding
the size of a structure that has a zero-sized array at the end, along
with memory for some number of elements for that array. For example:
struct foo {
int stuff;
struct boo entry[];
};
size = sizeof(struct foo) + cou
One of the more common cases of allocation size calculations is finding
the size of a structure that has a zero-sized array at the end, along
with memory for some number of elements for that array. For example:
struct foo {
int stuff;
struct boo entry[];
};
size = sizeof(struct foo) + cou
On 1/31/19 8:11 AM, Chuck Lever wrote:
>
>
>> On Jan 30, 2019, at 7:46 PM, Gustavo A. R. Silva
>> wrote:
>>
>> One of the more common cases of allocation size calculations is finding
>> the size of a structure that has a zero-sized array at the end, along
>> with memory for some number of el
One of the more common cases of allocation size calculations is finding
the size of a structure that has a zero-sized array at the end, along
with memory for some number of elements for that array. For example:
struct foo {
int stuff;
void *entry[];
};
size = sizeof(struct foo) + count *
One of the more common cases of allocation size calculations is finding
the size of a structure that has a zero-sized array at the end, along
with memory for some number of elements for that array. For example:
struct foo {
int stuff;
struct boo entry[];
};
size = sizeof(struct foo) + cou
One of the more common cases of allocation size calculations is finding
the size of a structure that has a zero-sized array at the end, along
with memory for some number of elements for that array. For example:
struct foo {
int stuff;
void *entry[];
};
size = sizeof(struct foo) + count *
One of the more common cases of allocation size calculations is finding
the size of a structure that has a zero-sized array at the end, along
with memory for some number of elements for that array. For example:
struct foo {
int stuff;
struct boo entry[];
};
size = sizeof(struct foo) + cou
One of the more common cases of allocation size calculations is finding
the size of a structure that has a zero-sized array at the end, along
with memory for some number of elements for that array. For example:
struct foo {
int stuff;
void *entry[];
};
instance = alloc(sizeof(struct foo)
One of the more common cases of allocation size calculations is finding
the size of a structure that has a zero-sized array at the end, along
with memory for some number of elements for that array. For example:
struct foo {
int stuff;
void *entry[];
};
instance = alloc(sizeof(struct foo)
This patch changes struct btf_ext to retain original data in sequential
block of memory, which makes it possible to expose
btf_ext__get_raw_data() interface, that's similar to
btf__get_raw_data(), allowing users of libbpf to get access to raw
representation of .BTF.ext section.
Signed-off-by: Andr
Now that we have btf__get_raw_data() it's trivial for tests to iterate
over all strings for testing purposes, which eliminates the need for
btf__get_strings() API.
Signed-off-by: Andrii Nakryiko
---
tools/lib/bpf/btf.c| 7 -
tools/lib/bpf/btf.h| 2 --
This patchset introduces a set of new APIs that make it possible to work with
BTF
more effectively (and without involving kernel) for applications like pahole
that
need to manipulate .BTF and .BTF.ext data.
Patch #1 changes existing btf__new() API call to only load and initialize
struct btf, w
This patch exposes new API btf__get_raw_data() that allows to get a copy
of raw BTF data out of struct btf. This is useful for external programs
that need to manipulate raw data, e.g., pahole using btf__dedup() to
deduplicate BTF type info and then writing it back to file.
Signed-off-by: Andrii Na
This change splits out previous btf__new functionality of constructing
struct btf and loading it into kernel into two:
- btf__new() just creates and initializes struct btf
- btf__load() attempts to load existing struct btf into kernel
btf__free will still close BTF fd, if it was ever loaded succes
On Thu, Feb 07, 2019 at 09:34:51AM -0800, Yonghong Song wrote:
> The kernel verifier has three levels of logs:
> 0: no logs
> 1: logs mostly useful
> > 1: verbose
>
> Current libbpf API functions bpf_load_program_xattr() and
> bpf_load_program() cannot specify log_level.
> The bcc, howev
On Thu, Feb 07, 2019 at 11:29:24AM -0800, Andrii Nakryiko wrote:
> Few files in libbpf are using bzero() function (defined in strings.h header),
> but
> don't include corresponding header. When libbpf is added as a dependency to
> pahole,
> this undeterministically causes warnings on some machine
From: Arun Parameswaran
Date: Thu, 7 Feb 2019 16:01:18 -0800
> Fixes the issues with non BCM58XX chips in the b53 driver
> failing, when the irq is not specified in the device tree.
>
> Removed the check for BCM58XX in b53_srab_prepare_irq(),
> so the 'port->irq' will be set to '-EXIO' if the i
From: Heiner Kallweit
Date: Thu, 7 Feb 2019 21:41:46 +0100
> Let genphy_c45_read_link manage the devices to check, this removes
> overhead from callers. Add C22EXT to the list of excluded devices
> because it doesn't implement the status register. According to the
> 802.3 clause 45 spec registers
From: Moritz Fischer
Date: Thu, 7 Feb 2019 12:14:55 -0800
> Add fixed_phy_register_with_gpiod() API. It lets users create a
> fixed_phy instance that uses a GPIO descriptor which was obtained
> externally e.g. through platform data.
> This enables platform devices (non-DT based) to use GPIOs for
From: Russell King - ARM Linux admin
Date: Thu, 7 Feb 2019 16:18:25 +
> This series adds support for the comphy for Armada 38x, which allows
> these SoCs to use 2500BASE-X mode with appropriate SFP modules.
>
> Tested on SolidRun Clearfog after updating for the 5.0 merge window
> changes.
S
From: Ursula Braun
Date: Thu, 7 Feb 2019 15:56:13 +0100
> here are patches for SMC:
> * patches 1, 3, and 6 are cleanups without functional change
> * patch 2 postpones closing of internal clcsock
> * patches 4 and 5 improve link group creation locking
> * patch 7 restores AF_SMC as diag_family
One of the more common cases of allocation size calculations is finding
the size of a structure that has a zero-sized array at the end, along
with memory for some number of elements for that array. For example:
struct foo {
int stuff;
struct boo entry[];
};
size = sizeof(struct foo) + cou
One of the more common cases of allocation size calculations is finding
the size of a structure that has a zero-sized array at the end, along
with memory for some number of elements for that array. For example:
struct foo {
int stuff;
struct boo entry[];
};
instance = alloc(sizeof(struct
One of the more common cases of allocation size calculations is finding
the size of a structure that has a zero-sized array at the end, along
with memory for some number of elements for that array. For example:
struct foo {
int stuff;
struct boo entry[];
};
size = sizeof(struct foo) + cou
Make use of the struct_size() helper instead of an open-coded version
in order to avoid any potential type mistakes, in particular in the
context in which this code is being used.
So, change the following form:
sizeof(*ev) + ev->num_hndl * sizeof(struct hci_comp_pkts_info)
to :
struct_size(ev,
One of the more common cases of allocation size calculations is finding
the size of a structure that has a zero-sized array at the end, along
with memory for some number of elements for that array. For example:
struct foo {
int stuff;
struct boo entry[];
};
size = sizeof(struct foo) + cou
One of the more common cases of allocation size calculations is finding
the size of a structure that has a zero-sized array at the end, along
with memory for some number of elements for that array. For example:
struct foo {
int stuff;
void *entry[];
};
size = sizeof(struct foo) + count *
One of the more common cases of allocation size calculations is finding
the size of a structure that has a zero-sized array at the end, along
with memory for some number of elements for that array. For example:
struct foo {
int stuff;
struct boo entry[];
};
size = sizeof(struct foo) + cou
On 2/6/19 11:42 AM, Ido Schimmel wrote:
> Create a new FIB entry type for blackhole routes and set it in case the
> type of the notified route is 'RTN_BLACKHOLE'.
>
> Program such routes with a discard action and mark them as offloaded
> since the device is dropping the packets instead of the kern
One of the more common cases of allocation size calculations is finding
the size of a structure that has a zero-sized array at the end, along
with memory for some number of elements for that array. For example:
struct foo {
int stuff;
struct boo entry[];
};
size = sizeof(struct foo) + cou
On Thu, 7 Feb 2019 14:05:27 +0100
Phil Sutter wrote:
> Commit 50b9950dd9011 ("link dump filter") accidentally broke listing of
> links in the old alias interface notation:
>
> | % ip link show eth0:1
> | RTNETLINK answers: No such device
> | Cannot send link get request: No such device
>
> Pri
Hi all,
Today's linux-next merge of the net-next tree got a conflict in:
drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
between commit:
218d05ce326f ("net/mlx5e: Don't overwrite pedit action when multiple pedit
used")
from the net tree and commit:
c500c86b0c75 ("net/mlx5e: support for
On 2/7/19 4:01 PM, Arun Parameswaran wrote:
> Fixes the issues with non BCM58XX chips in the b53 driver
> failing, when the irq is not specified in the device tree.
>
> Removed the check for BCM58XX in b53_srab_prepare_irq(),
> so the 'port->irq' will be set to '-EXIO' if the irq is not
> specifie
Fixes the issues with non BCM58XX chips in the b53 driver
failing, when the irq is not specified in the device tree.
Removed the check for BCM58XX in b53_srab_prepare_irq(),
so the 'port->irq' will be set to '-EXIO' if the irq is not
specified in the device tree.
Fixes: 16994374a6fc ("net: dsa: b
> -Original Message-
> From: Michal Kubecek [mailto:mkube...@suse.cz]
> Sent: Wednesday, February 6, 2019 5:22 AM
> To: netdev@vger.kernel.org
> Cc: Kirsher, Jeffrey T ; linvi...@tuxdriver.com;
> Nunley, Nicholas D ; nhor...@redhat.com;
> sassm...@redhat.com
> Subject: Re: [PATCH v2 4/6] et
On Thu, Feb 07, 2019 at 10:49:36AM +0100, Maxime Chevallier wrote:
> The Marvell Alaska family of PHYs supports 2.5GBaseT and 5GBaseT modes,
> as defined in the 802.3bz specification.
>
> When the link partner requests a 2.5GBASET link, the PHY will
> reconfigure it's MII interface to 2500BASEX.
>
> -Original Message-
> From: Michal Kubecek [mailto:mkube...@suse.cz]
> Sent: Wednesday, February 6, 2019 4:43 AM
> To: netdev@vger.kernel.org
> Cc: Kirsher, Jeffrey T ; linvi...@tuxdriver.com;
> Nunley, Nicholas D ; nhor...@redhat.com;
> sassm...@redhat.com
> Subject: Re: [PATCH v2 3/6] et
> -Original Message-
> From: Michal Kubecek [mailto:mkube...@suse.cz]
> Sent: Wednesday, February 6, 2019 2:33 AM
> To: netdev@vger.kernel.org
> Cc: Kirsher, Jeffrey T ; linvi...@tuxdriver.com;
> Nunley, Nicholas D ; nhor...@redhat.com;
> sassm...@redhat.com
> Subject: Re: [PATCH v2 3/6] et
On Mon, Jan 28, 2019 at 03:26:21PM +0100, Maxime Chevallier wrote:
> Hello Russell,
>
> On Mon, 21 Jan 2019 13:00:30 +
> Russell King - ARM Linux admin wrote:
>
> >On Mon, Jan 21, 2019 at 01:29:45PM +0100, Maxime Chevallier wrote:
> >> Hello Russell,
> >>
> >> On Mon, 21 Jan 2019 10:52:06 +
> -Original Message-
> From: Michal Kubecek [mailto:mkube...@suse.cz]
> Sent: Wednesday, February 6, 2019 1:19 AM
> To: netdev@vger.kernel.org
> Cc: Kirsher, Jeffrey T ; linvi...@tuxdriver.com;
> Nunley, Nicholas D ; nhor...@redhat.com;
> sassm...@redhat.com
> Subject: Re: [PATCH v2 3/6]
Hi Christoph,
On Fri, Feb 01, 2019 at 09:47:44AM +0100, Christoph Hellwig wrote:
> The DMA API generally relies on a struct device to work properly, and
> only barely works without one for legacy reasons. Pass the easily
> available struct device from the platform_device to remedy this.
>
> Also
On Wed, Feb 6, 2019 at 10:44 PM Pankaj Bansal wrote:
>
>
>
> > -Original Message-
> > From: Li Yang [mailto:leoyang...@nxp.com]
> > Sent: Thursday, 7 February, 2019 05:09 AM
> > To: Andrew Lunn
> > Cc: Pankaj Bansal ; Shawn Guo
> > ; Florian Fainelli ;
> > netdev@vger.kernel.org; linux-ar
L.S.,
While trying out a 5.0-RC5 kernel I seem to have stumbled over a regression
with NAT.
(using an nftables firewall with NAT and connection tracking).
Unfortunately it isn't too obvious since no errors are logged, but on clients it
causes symptoms like firefox intermittently not being able t
On 02/07/2019 08:27 AM, Martin Lau wrote:
[...]
> Following up the discussion in the iovisor conf call.
>
> One of discussion was about:
> other than tw, can __sk_buff->sk always return a
> fullsock (PTR_TO_SOCKET_OR_NULL). In request_sock case,
> it is doable because it can trace back to the lis
On Thu, Feb 07, 2019 at 10:54:51PM +0100, Heiner Kallweit wrote:
> On 07.02.2019 21:50, Andrew Lunn wrote:
> >> Thanks, Andrew. Right, the Aquantia PHY doesn't seem to have the C22EXT
> >> MMD. Because the Aquantia PHY has no device 29 in its package the code
> >> should work.
> >
> > It lists dev
On 07.02.2019 22:54, Heiner Kallweit wrote:
> On 07.02.2019 21:50, Andrew Lunn wrote:
>>> Thanks, Andrew. Right, the Aquantia PHY doesn't seem to have the C22EXT
>>> MMD. Because the Aquantia PHY has no device 29 in its package the code
>>> should work.
>>
>> It lists device 29 in its devices in pa
On Fri, Feb 08, 2019 at 05:48:34AM +0800, Herbert Xu wrote:
>
> > > Could you please show me who is doing this so I can review that
> > > to see whether it's a legitimate use of this API?
> >
> > I'm sure you'll say it's not legitimate, but it still exists ;-)
> >
> > mesh_plink_broken() gets cal
On Thu, Feb 7, 2019 at 7:43 PM Saeed Mahameed wrote:
>
> On Thu, Feb 7, 2019 at 2:17 AM Ian Kumlien wrote:
> >
> > On Thu, Feb 7, 2019 at 2:01 AM Saeed Mahameed
> > wrote:
> > > On Wed, Feb 6, 2019 at 3:00 PM Ian Kumlien wrote:
> > > > It changes directly after the first hw checksum failure, I
On Fri, 2019-02-08 at 05:48 +0800, Herbert Xu wrote:
> On Thu, Feb 07, 2019 at 02:50:54PM +0100, Johannes Berg wrote:
> >
> > > This interface wasn't designed for use in softirq contexts.
> >
> > Well, it clearly was used there. You even gave it a gfp_t argument in
> > rhashtable_walk_init(), so
On 07.02.2019 21:50, Andrew Lunn wrote:
>> Thanks, Andrew. Right, the Aquantia PHY doesn't seem to have the C22EXT
>> MMD. Because the Aquantia PHY has no device 29 in its package the code
>> should work.
>
> It lists device 29 in its devices in package. So the current code does
> look there.
>
I
On Thu, Feb 07, 2019 at 02:50:54PM +0100, Johannes Berg wrote:
>
> > This interface wasn't designed for use in softirq contexts.
>
> Well, it clearly was used there. You even gave it a gfp_t argument in
> rhashtable_walk_init(), so you can't really claim it wasn't designed for
> this. I see now t
Hi Matthew,
On Thu, Feb 07, 2019 at 01:34:00PM -0800, Matthew Wilcox wrote:
> On Thu, Feb 07, 2019 at 01:25:19PM -0800, David Miller wrote:
> > From: Ilias Apalodimas
> > Date: Thu, 7 Feb 2019 17:20:34 +0200
> >
> > > Well updating struct page is the final goal, hence the comment. I am
> > > mo
On Wed, Feb 06, 2019 at 11:41:28PM +0100, Ian Kumlien wrote:
> On Wed, Feb 6, 2019 at 11:38 PM Cong Wang wrote:
> > On Wed, Feb 6, 2019 at 2:15 PM Ian Kumlien wrote:
> > > Could we please schedule this for 4.19 and 4.20 - it's kinda breaking
> > > things
> >
> > It doesn't break anything, packet
Hi David,
On Thu, Feb 07, 2019 at 01:25I:19PM -0800, David Miller wrote:
> From: Ilias Apalodimas
> Date: Thu, 7 Feb 2019 17:20:34 +0200
>
> > Well updating struct page is the final goal, hence the comment. I am mostly
> > looking for opinions here since we are trying to store dma addresses whic
On Thu, Feb 07, 2019 at 01:25:19PM -0800, David Miller wrote:
> From: Ilias Apalodimas
> Date: Thu, 7 Feb 2019 17:20:34 +0200
>
> > Well updating struct page is the final goal, hence the comment. I am mostly
> > looking for opinions here since we are trying to store dma addresses which
> > are
>
From: David Miller
Date: Thu, 07 Feb 2019 13:22:35 -0800 (PST)
> From: Sudarsana Reddy Kalluru
> Date: Thu, 7 Feb 2019 06:20:10 -0800
>
>> SmartAN feature detects the peer/cable capabilities and establishes the
>> link in the best possible configuration.
>> The patch series adds support for que
From: Ilias Apalodimas
Date: Thu, 7 Feb 2019 17:20:34 +0200
> Well updating struct page is the final goal, hence the comment. I am mostly
> looking for opinions here since we are trying to store dma addresses which are
> irrelevant to pages. Having dma_addr_t definitions in mm-related headers is
From: Sudarsana Reddy Kalluru
Date: Thu, 7 Feb 2019 06:20:10 -0800
> SmartAN feature detects the peer/cable capabilities and establishes the
> link in the best possible configuration.
> The patch series adds support for querying the capability. Please consider
> applying it net-next.
Series appl
On Thu, Feb 07, 2019 at 09:41:46PM +0100, Heiner Kallweit wrote:
> Let genphy_c45_read_link manage the devices to check, this removes
> overhead from callers. Add C22EXT to the list of excluded devices
> because it doesn't implement the status register. According to the
> 802.3 clause 45 spec regis
> Thanks, Andrew. Right, the Aquantia PHY doesn't seem to have the C22EXT
> MMD. Because the Aquantia PHY has no device 29 in its package the code
> should work.
It lists device 29 in its devices in package. So the current code does
look there.
> So it seems we have to exclude device C22EXT in ge
Let genphy_c45_read_link manage the devices to check, this removes
overhead from callers. Add C22EXT to the list of excluded devices
because it doesn't implement the status register. According to the
802.3 clause 45 spec registers 29.0 - 29.4 are reserved.
At the moment we have very few clause 45
Attempting to avoid cloning the skb when broadcasting by inflating
the refcount with sock_hold/sock_put while under RCU lock is dangerous
and violates RCU principles. It leads to subtle race conditions when
attempting to free the SKB, as we may reference sockets that have
already been freed by the
On Thu, Feb 7, 2019 at 12:27 PM Eric Dumazet wrote:
>
> netif_rx() must be called under a strict contract.
>
> At device dismantle phase, core networking clears IFF_UP
> and flush_all_backlogs() is called after rcu grace period
> to make sure no incoming packet might be in a cpu backlog
> and stil
netif_rx() must be called under a strict contract.
At device dismantle phase, core networking clears IFF_UP
and flush_all_backlogs() is called after rcu grace period
to make sure no incoming packet might be in a cpu backlog
and still referencing the device.
Most drivers call netif_rx() from their
On 07.02.2019 20:57, Andrew Lunn wrote:
> On Thu, Feb 07, 2019 at 08:05:55PM +0100, Heiner Kallweit wrote:
>> Let genphy_c45_read_link manage the devices to check, this removes
>> overhead from callers. Devices VEND1 and VEND2 will never be checked,
>> for now adopt the logic of the Marvell driver
Add fixed_phy_register_with_gpiod() API. It lets users create a
fixed_phy instance that uses a GPIO descriptor which was obtained
externally e.g. through platform data.
This enables platform devices (non-DT based) to use GPIOs for link
status.
Reviewed-by: Florian Fainelli
Signed-off-by: Moritz F
On Thu, Feb 7, 2019 at 11:21 AM Andrii Nakryiko
wrote:
>
> On Tue, Feb 5, 2019 at 10:25 PM Alexei Starovoitov
> wrote:
> >
> > On Tue, Feb 05, 2019 at 09:46:14PM -0800, Andrii Nakryiko wrote:
> > > On Tue, Feb 5, 2019 at 7:07 PM Alexei Starovoitov
> > > wrote:
> > > >
> > > > On Tue, Feb 05, 201
On Thu, Feb 07, 2019 at 08:05:55PM +0100, Heiner Kallweit wrote:
> Let genphy_c45_read_link manage the devices to check, this removes
> overhead from callers. Devices VEND1 and VEND2 will never be checked,
> for now adopt the logic of the Marvell driver to also exclude PHY XS.
>
> At the moment we
On Thu, 7 Feb 2019 06:20:10 -0800, Sudarsana Reddy Kalluru wrote:
> SmartAN feature detects the peer/cable capabilities and establishes the
> link in the best possible configuration.
It sounds familiar, I need to check with FW team, but I think we may be
doing a similar thing, and adding a common
From: Willem de Bruijn
bpf_skb_change_proto and bpf_skb_adjust_room change skb header length.
For GSO packets they adjust gso_size to maintain the same MTU.
The gso size can only be safely adjusted on bytestream protocols.
Commit d02f51cbcf12 ("bpf: fix bpf_skb_adjust_net/bpf_skb_proto_xlat
to d
Hi Guys,
i can confirm better performance with 4.14.29
- ~900 MBits with iperf2 in one way
-~ 500 - 600MBits with iperf2 in duplex in both directions
This wasnt the case with 4.17.9, not with 4.18, 4.19 or the 5.0 series.
How can i help further ?
regards,
Simon
Am 06.02.2019 um 11:36
Few files in libbpf are using bzero() function (defined in strings.h header),
but
don't include corresponding header. When libbpf is added as a dependency to
pahole,
this undeterministically causes warnings on some machines:
bpf.c:225:2: warning: implicit declaration of function ‘bzero’
[-Wimpl
On Thu, Feb 7, 2019 at 11:21 AM Arnaldo Carvalho de Melo
wrote:
>
> Em Thu, Feb 07, 2019 at 09:50:27AM -0800, Andrii Nakryiko escreveu:
> > Few files in libbpf are using bzero() function (defined in strings.h
> > header), but
> > don't include corresponding header. When libbpf is added as a depen
The link status register latches link-down events. Therefore, if link
is reported as being up, there's no need for a second read.
Signed-off-by: Heiner Kallweit
---
drivers/net/phy/phy-c45.c| 2 ++
drivers/net/phy/phy_device.c | 6 +-
2 files changed, 7 insertions(+), 1 deletion(-)
diff
On Tue, Feb 5, 2019 at 10:25 PM Alexei Starovoitov
wrote:
>
> On Tue, Feb 05, 2019 at 09:46:14PM -0800, Andrii Nakryiko wrote:
> > On Tue, Feb 5, 2019 at 7:07 PM Alexei Starovoitov
> > wrote:
> > >
> > > On Tue, Feb 05, 2019 at 04:29:49PM -0800, Andrii Nakryiko wrote:
> > > > This patch exposes t
1 - 100 of 237 matches
Mail list logo
