Fix spelling mistakes in brcm80211 and cfg80211: "lenght" -> "length".
The typos are also in the special comment blocks which
translates to documentation.
Signed-off-by: Matteo Croce
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.h | 2 +-
drivers/net/wireless/broadcom/brcm80211/b
This patch adds PCI device IDs to support following cards:
1. Add device id 0x0205 for HINIC 100GE dual port mezz card.
2. Add device id 0x0210 for HINIC 25GE quad port mezz card.
3. Delete device id 0x0201 for HINIC 100GE dual port card, because
this is used by other product.
4. Macro of device i
I've received a bug report of oversized UDP packets sent to the
bnxt_en driver for transmission. There is no check for illegal length
in the driver and it will send a corrupted BD to the NIC if the
non-TSO length exceeds the maximum MTU supported by the driver. This
ultimately causes the driver t
Matteo Croce writes:
> Fix spelling mistakes in brcm80211 and cfg80211: "lenght" -> "length".
> The typos are also in the special comment blocks which
> translates to documentation.
>
> Signed-off-by: Matteo Croce
> ---
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.h | 2 +-
> dri
On Mon, Jan 14, 2019 at 09:29:51AM -0700, David Ahern wrote:
> On 1/14/19 9:05 AM, Stephen Hemminger wrote:
> > On Sat, 12 Jan 2019 12:54:06 -0800
> > Jakub Kicinski wrote:
> >
> >> Kernel ignores the RTM_F_LOOKUP_TABLE flag for all families
> >> but IPv4. Don't set it, otherwise it may fall fou
1) Fix endless loop in nf_tables, from Phil Sutter.
2) Fix cross namespace ip6_gre tunnel hash list corruption, from
Olivier Matz.
3) Don't be too strict in phy_start_aneg() otherwise we might not
allow restarting auto negotiation. From Heiner Kallweit.
4) Fix various KMSAN uninitialize
On 20. Jan (Sunday) v 19:13:59 -0700 2019, Jonathan Corbet wrote:
> On Fri, 18 Jan 2019 21:38:32 +0100
> Otto Sabart wrote:
>
> > Convert scaling document into reStructuredText and add reference to
> > scaling document into main table of contents in network documentation.
> >
> > There are no se
We need to let users check their wrong ELF section name
with proper ELF section names when failed to get a prog/attach type from it.
Because users can't realize libbpf guess prog/attach types from
given ELF section names.
For example, when a 'cgroup' section name of a BPF program is used,
show avai
Next to snooping IGMP/MLD queries RFC4541, section 2.1.1.a) recommends
to snoop multicast router advertisements to detect multicast routers.
Multicast router advertisements are sent to an "all-snoopers"
multicast address. To be able to receive them reliably, we need to
join this group.
Otherwise
With this patch the internal use of the skb_trimmed is reduced to
the ICMPv6/IGMP checksum verification. And for the length checks
the newly introduced helper functions are used instead of calculating
and checking with skb->len directly.
These changes should hopefully make it easier to verify that
When multiple multicast routers are present in a broadcast domain then
only one of them will be detectable via IGMP/MLD query snooping. The
multicast router with the lowest IP address will become the selected and
active querier while all other multicast routers will then refrain from
sending querie
This patch refactors ip_mc_check_igmp(), ipv6_mc_check_mld() and
their callers (more precisely, the Linux bridge) to not rely on
the skb_trimmed parameter anymore.
An skb with its tail trimmed to the IP packet length was initially
introduced for the following three reasons:
1) To be able to verif
We need to let users check their wrong ELF section name
with proper ELF section names when failed to get a prog/attach type from it.
Because users can't realize libbpf guess prog/attach types from
given ELF section names.
For example, when a 'cgroup' section name of a BPF program is used,
show avai
On 12/21/18 11:47 PM, Quentin Monnet wrote:
2018-12-21 22:22 UTC+0900 ~ Taeung Song
We need to let users check their wrong ELF section name
with proper ELF section names when failed to get a prog/attach type from it.
Because users can't realize libbpf guess prog/attach types from
given ELF s
From: Greg Ungerer
The MediaTek MT7621 SoC device contains a 7530 switch, and the existing
linux kernel 7530 DSA switch driver can be used with it.
The bulk of the changes required stem from the 7621 having different
regulator and pad setup. The existing setup of these in the 7530
driver appears
From: Bjørn Mork
The Mediatek MT7621 SoC contains the same ethernet hardware module as
used on a number of other MediaTek SoC parts. There are some minor
differences to deal with but we can use the same driver to support
them all.
This patch is based on work by Bjørn Mork , and his
original patc
Hi,
This patchset adds initial Multicast Router Discovery support to
the Linux bridge (RFC4286). With MRD it is possible to detect multicast
routers and mark bridge ports and forward multicast packets to such routers
accordingly.
So far, multicast routers are detected via IGMP/MLD queries and PIM
From: Greg Ungerer
Add devicetree binding to support the compatible mt7530 switch as used
in the MediaTek MT7621 SoC.
Signed-off-by: Greg Ungerer
---
Documentation/devicetree/bindings/net/dsa/mt7530.txt | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
v1: initial patch
v2: use separ
This is the third version of a patch series supporting the MT7530 switch
as used in the MediaTek MT7621 SoC. Unlike the MediaTek MT7623 the MT7621
is built around a dual core MIPS CPU architecture. But inside it uses
basically the same 7530 switch.
This series resolves all issues I had with prev
Converted to use "imply" instead of "select" for PTP_1588_CLOCK
driver selecting. This could break the hard dependency between
the PTP clock subsystem and ethernet drivers.
This patch also set "default y" for dpaa2 ptp driver building to
provide user an available ptp clock in default.
Signed-off-b
On Fri, Jan 18, 2019 at 04:54:53PM -0500, Bryan Whitehead wrote:
> The LAN743x includes on chip One-Time-Programmable (OTP) memory.
>
> This patch extends the ethtool EEPROM read/write interface to
> access OTP memory space.
>
> This is done by adding the private flag OTP_ACCESS, which is used
>
From: Ido Schimmel
Date: Sun, 20 Jan 2019 06:50:38 +
> Nir says:
>
> In Spectrum-2, HW implementation of layer 3 tunnels differs from
> Spectrum-1 when it comes to the underlay routing table selection.
> Spectrum-2 uses a dedicated RIF that points to the virtual router used
> for forwarding
> + /* Make sure we advertise all the supported modes, and not just the
> + * default one specified in the driver's .features.
> + */
> + linkmode_copy(phydev->advertising, phydev->supported);
We need to look a this. This is something the core should be doing.
Andrew
On Fri, Jan 18, 2019 at 04:23:50PM +0100, Maxime Chevallier wrote:
> As per 802.3bz, if bit 14 of (1.11) "PMA Extended Abilities" indicates
> whether or not we should read register (1.21) "2.52/5G PMA Extended
> Abilities", which contains information on the support of 2.5GBASET and
> 5GBASET.
>
>
On 1/20/19 10:33 AM, Andreas Färber wrote:
> diff --git a/drivers/net/zwave/Makefile b/drivers/net/zwave/Makefile
> new file mode 100644
> index ..1a4171308c79
> --- /dev/null
> +++ b/drivers/net/zwave/Makefile
> @@ -0,0 +1 @@
> +obj-m += zwave.o
Hi,
This will need a Kconfig file and
On Fri, Jan 18, 2019 at 04:23:46PM +0100, Maxime Chevallier wrote:
> Marvell 10G PHY driver has a generic way of initializing the supported
> link modes by reading the PHY's C45 PMA abilities. This can be made
> generic, since these registers are part of the 802.3 specifications.
>
> This commit e
From: Jiri Pirko
Date: Sun, 20 Jan 2019 12:08:50 +0100
> I haven't have time to review this due to travel. I think it was mistake
> to merge this as the buffer api is wrong in my opinion. I would vote for
> revert if possible.
Let's spend a couple days trying to fix things up first.
I cannot ma
The pull request you sent on Sun, 20 Jan 2019 11:14:20 -0500:
> git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git tags/for_linus
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/bb617b9b4519b0cef939c9c8e9c41470749f0d51
Thank you!
--
Deet-doot-dot, I am a bot
Inspired from my LoRa and FSK driver project, I've hacked together a PoC
for an in-kernel Z-Wave driver. Tested with Pine64 Z-Wave module.
The by now SiLabs ZM5304 module exposes a UART interface that this
serdev driver can be attached to, using Device Tree.
There didn't appear to be any schemati
On Fri, Jan 18, 2019 at 11:22:39AM +0100, Thomas Gleixner wrote:
> Michael,
>
> On Thu, 19 Apr 2018, Michael Schmitz wrote:
>
> > --- /dev/null
> > +++ b/drivers/net/phy/asix.c
> > @@ -0,0 +1,63 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/* Driver for Asix PHYs
> > + *
> > + * Author: Micha
On Sat, Jan 19, 2019 at 12:09:39AM +0100, Daniele Orlandi wrote:
>
> Hello,
>
> I am trying to connect a Marvell switch (88E6172) to an AM3352 ethernet
> port.
>
> In the DSA devicetree description the CPU port has to have an "ethernet"
> attribute with a reference to a device node. From which i
This mostly fixes the fallout from the balloon changes.
The following changes since commit 1c7fc5cbc33980acd13d668f1c8f0313d6ae9fd8:
Linux 5.0-rc2 (2019-01-14 10:41:12 +1200)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git tags/for_linus
This patch adds support for the SIOCGHWTSTAMP ioctl which enables user
processes to read the current hwtstamp_config settings
non-destructively.
Signed-off-by: Artem Panfilov
---
drivers/net/ethernet/stmicro/stmmac/stmmac.h | 2 ++
.../net/ethernet/stmicro/stmmac/stmmac_main.c | 36 +++
On Sun, Jan 20, 2019 at 3:43 PM Michael S. Tsirkin wrote:
>
> No not yet. Sorry! Pls send this one in, barrier_data will likely miss
> the next merge window.
No worries! Done.
Cheers,
Miguel
On Sat, Jan 19, 2019 at 07:35:33PM +0100, Miguel Ojeda wrote:
> Hi Michael,
>
> On Wed, Jan 9, 2019 at 3:50 PM Michael S. Tsirkin wrote:
> >
> > On Wed, Jan 09, 2019 at 11:35:52AM +0100, Miguel Ojeda wrote:
> > > Note it would be nice to separate the patch into two (one for the
> > > comments, an
On 2019/01/20 22:30, Dmitry Vyukov wrote:
>> The first messages I want to look at is kernel output. Then, I look at
>> syz-program lines as needed. But current "a self-contained file" is
>> hard to find kernel output.
>
> I think everybody looks at kernel crash first, that's why we provide
> kerne
On Sat, Jan 19, 2019 at 2:10 PM Tetsuo Handa
wrote:
>
> On 2019/01/19 21:16, Dmitry Vyukov wrote:
> >> The question for me is, whether sysbot can detect hash collision with
> >> different
> >> syz-program lines before writing the hash value to /dev/kmsg, and retry by
> >> modifying
> >> syz-prog
Dimitri,
I am so pleased to get some support for fixing this bug that I will let
you manage things as you like.
Please perform necessary actions for proper achievement of our concern.
You have my approbation for any change you think is needed.
Regards,
Bernard
Le 20/01/2019 à 11:32, Dmitry Vyu
Hello,
On Sat, 19 Jan 2019, Matteo Croce wrote:
> Use the new indirect call wrappers in IPVS when calling the TCP or UDP
> protocol specific functions.
> This avoids an indirect calls in IPVS, and reduces the performance
> impact of the Spectre mitigation.
>
> Signed-off-by: Matteo Cro
Hello,
On Sat, 19 Jan 2019, Matteo Croce wrote:
> The function pointer ip_vs_protocol->csum_check is only used in protocol
> specific code, and never in the generic one.
> Remove the function pointer from struct ip_vs_protocol and call the
> checksum functions directly.
> This reduces t
Thu, Jan 17, 2019 at 10:59:11PM CET, era...@mellanox.com wrote:
>Devlink health reporter is an instance for reporting, diagnosing and
>recovering from run time errors discovered by the reporters.
>Define it's data structure and supported operations.
>In addition, expose devlink API to create and de
Want to retouch your photos? Are the photos ready?
We can do white background, sharpen, retouching included all for your
photos.
Unlimited revisions .
Send us a test photo, we will start it.
Thanks,
Sara
Want to retouch your photos? Are the photos ready?
We can do white background, sharpen, retouching included all for your
photos.
Unlimited revisions .
Send us a test photo, we will start it.
Thanks,
Sara
Thu, Jan 17, 2019 at 10:59:16PM CET, era...@mellanox.com wrote:
>Add devlink health diagnose command, in order to run a diagnose
>operation over a specific reporter.
>
>It is expected from driver's callback for diagnose command to fill it
>via the buffer descriptors API. Devlink will parse it and c
Thu, Jan 17, 2019 at 10:59:15PM CET, era...@mellanox.com wrote:
>Add devlink health recover command to the uapi, in order to allow the user
>to execute a recover operation over a specific reporter.
>
>Signed-off-by: Eran Ben Elisha
>Reviewed-by: Moshe Shemesh
Acked-by: Jiri Pirko
Thu, Jan 17, 2019 at 10:59:14PM CET, era...@mellanox.com wrote:
>Add devlink health set command, in order to set configuration parameters
>for a specific reporter.
>Supported parameters are:
>- graceful_period: Time interval between auto recoveries (in msec)
>- auto_recover: Determines if the devli
Thu, Jan 17, 2019 at 10:59:13PM CET, era...@mellanox.com wrote:
>Add devlink health get command to provide reporter/s data for user space.
>Add the ability to get data per reporter or dump data from all available
>reporters.
>
>Signed-off-by: Eran Ben Elisha
>Reviewed-by: Moshe Shemesh
Acked-by:
Thu, Jan 17, 2019 at 10:59:12PM CET, era...@mellanox.com wrote:
[...]
>+
>+TRACE_EVENT(devlink_health_recover_aborted,
>+ TP_PROTO(const struct devlink *devlink, const char *reporter_name,
>+ bool health_state, u64 time_since_last_recover),
>+
>+ TP_ARGS(devlink, reporter_
Thu, Jan 17, 2019 at 10:59:10PM CET, era...@mellanox.com wrote:
>Devlink health buffer is a mechanism to pass descriptors between drivers
>and devlink. The API allows the driver to add objects, object pair,
>value array (nested attributes), value and name.
>
>Driver can use this API to fill the buf
Sun, Jan 20, 2019 at 12:06:18PM CET, era...@mellanox.com wrote:
>
>
>On 1/20/2019 12:03 PM, Jiri Pirko wrote:
>> Thu, Jan 17, 2019 at 10:59:10PM CET, era...@mellanox.com wrote:
>>
>> [...]
>>
>>> +static void
>>> +devlink_health_buffers_destroy(struct devlink_health_buffer **buffers_list,
>>> +
Thu, Jan 17, 2019 at 10:59:18PM CET, era...@mellanox.com wrote:
>Add mlx5e tx reporter to devlink health reporters. This reporter will be
>responsible for diagnosing, reporting and recovering of TX errors.
>This patch declares the TX reporter operations and allocate it using the
>devlink health API
Want to retouch your photos? Are the photos ready?
We can do white background, sharpen, retouching included all for your
photos.
Unlimited revisions .
Send us a test photo, we will start it.
Thanks,
Sara
On 1/20/2019 12:03 PM, Jiri Pirko wrote:
> Thu, Jan 17, 2019 at 10:59:10PM CET, era...@mellanox.com wrote:
>
> [...]
>
>> +static void
>> +devlink_health_buffers_destroy(struct devlink_health_buffer **buffers_list,
>> + u64 size);
>
> Avoid fwd declarations.
>
>
>>
The old non-PCIe chip versions support PCI DAC, however this feature
seems to be fragile, see comment in the PCI error handler. Therefore
it's disabled per default. I think meanwhile it's time remove support
for this legacy feature. This helps to reduce complexity of the driver.
Signed-off-by: Hei
On Sun, Jan 20, 2019 at 10:58 AM f6bvp wrote:
>
> Hi,
>
> Dmitry wrote:
>
> >Please also add:
> >Reported-by: syzbot+1a2c456a1ea08fa5b...@syzkaller.appspotmail.com
>
> I did mention syzbot report but without the exact reference, thanks.
>
> >It's this report we are fixing, right?
> >https://syzkal
Thu, Jan 17, 2019 at 10:59:10PM CET, era...@mellanox.com wrote:
[...]
>+static void
>+devlink_health_buffers_destroy(struct devlink_health_buffer **buffers_list,
>+ u64 size);
Avoid fwd declarations.
>+
>+static struct devlink_health_buffer **
>+devlink_health_buffe
8 years ago, as part of 6f0333b8fde4 ("r8169: use 50% less ram for RX
ring"), the alignment requirement for rx buffers was silently changed
from 8 bytes to 16 bytes. I found nothing explaining this, also the
chip specs I have only mention an 8 byte requirement.
AFAICS kmalloc_node() guarantees allo
Hi,
Dmitry wrote:
>Please also add:
>Reported-by: syzbot+1a2c456a1ea08fa5b...@syzkaller.appspotmail.com
I did mention syzbot report but without the exact reference, thanks.
>It's this report we are fixing, right?
>https://syzkaller.appspot.com/bug?id=fd0b0b00fc26abb4b35663a0e2f1c91d8e6e5725
Ye
Parity errors might happen in the device's memories due to momentary bit
flips which are caused by radiation.
Errors that are not correctable initiate a process kill event, which blocks
the device access towards the host and the network, and a recovery process
is started in the management FW and in
From: Tomer Tayar
This patch adds the detection and handling of a parity error ("process kill
event"), including the update of the protocol drivers, and the prevention
of any HW access that will lead to device access towards the host while
recovery is in progress.
It also provides the means for t
From: Tomer Tayar
This patch adds the error recovery process in the qede driver.
The process includes a partial/customized driver unload and load, which
allows it to look like a short suspend period to the kernel while
preserving the net devices' state.
Signed-off-by: Tomer Tayar
Signed-off-by:
From: Tomer Tayar
Initiating final cleanup after an ungraceful driver unload can lead to bad
PCI accesses towards the host.
This patch revises the load sequence so final cleanup is sent while the
internal master enable is cleared, to prevent the host accesses, and clears
the internal error indica
This patch add support for the following commands:
Devlink health show [DEV reporter REPORTE_NAME],
Devlink health recover DEV reporter REPORTER_NAME,
Devlink health diagnose DEV reporter REPORTER_NAME,
Devlink health dump show DEV reporter REPORTER_NAME,
Devlink health dump clear DEV reporter REPO
Interrupts don't have to be enabled before calling phy_start().
Therefore let's enable them in phy_start(). In a subsequent step
we'll remove enabling interrupts from phy_connect_direct().
Signed-off-by: Heiner Kallweit
---
drivers/net/phy/phy.c | 34 ++
1 file ch
phy_start() should be called from states PHY_READY or PHY_HALTED only.
Check for this to detect misbehaving drivers. Also the state machine
should be started only when being called from one of the valid states.
Signed-off-by: Heiner Kallweit
---
drivers/net/phy/phy.c | 11 +--
1 file cha
Now that we enable the interrupts in phy_start() we don't have to do it
before. Therefore remove enabling interrupts from phy_start_interrupts()
and rename this function to reflect the changed functionality.
v2:
- improve warning to clearly state that we fall back to polling
Signed-off-by: Heiner
The state machine is a no-op before phy_start() has been called.
Therefore let's enable it in phy_start() only. In phy_start()
let's call phy_start_machine() instead of phy_trigger_machine().
phy_start_machine is an alias for phy_trigger_machine but it makes
clearer that we start the state machine
This patch series improves few aspects of starting the PHY.
v2:
- improve a warning in patch 4
Heiner Kallweit (4):
net: phy: start state machine in phy_start only
net: phy: warn if phy_start is called from invalid state
net: phy: start interrupts in phy_start
net: phy: change phy_start_i
On 2019-01-18 23:50, Jason Gunthorpe wrote:
There has been some confusion since checkpatch started warning about
bool
use in structures, and people have been avoiding using it.
Many people feel there is still a legitimate place for bool in
structures,
so provide some guidance on bool usage der
On 20.01.2019 00:43, Florian Fainelli wrote:
>
>
> On January 19, 2019 3:30:05 AM PST, Heiner Kallweit
> wrote:
>> Now that we enable the interrupts in phy_start() we don't have to do it
>> before. Therefore remove enabling interrupts from
>> phy_start_interrupts()
>> and rename this function t
On Thu, Jan 17, 2019 at 01:27:51PM +, Fabrizio Castro wrote:
> Hello Simon,
>
> Thank you for your feedback!
>
> > From: Simon Horman
> > Sent: 17 January 2019 12:00
> > Subject: Re: [PATCH 07/11] arm64: dts: renesas: cat875: Add ethernet support
> >
> > On Wed, Jan 16, 2019 at 06:37:50PM +0
On Thu, Jan 17, 2019 at 01:19:06PM +, Fabrizio Castro wrote:
> Hello Simon,
>
> Thank you for your feedback!
>
> > From: Simon Horman
> > Sent: 17 January 2019 11:12
> > Subject: Re: [PATCH 06/11] arm64: dts: renesas: r8a774c0-cat874: Add uSD
> > support
> >
> > On Wed, Jan 16, 2019 at 06:3
72 matches
Mail list logo
