Hi Archie,
> When receiving connection, we only check whether the link has been
> encrypted, but not the encryption key size of the link.
>
> This patch adds check for encryption key size, and reject L2CAP
> connection which size is below the specified threshold (default 7)
> with security block.
Hi Howard,
> This patch implements the interleaving between allowlist scan and
> no-filter scan. It'll be used to save power when at least one monitor is
> registered and at least one pending connection or one device to be
> scanned for.
>
> The durations of the allowlist scan and the no-filter s
Hi Howard,
> This fixes the count of Adv monitor upon monitor removal.
>
> The following test was performed.
> - Start two btmgmt consoles, issue a btmgmt advmon-remove command on one
> console and observe a MGMT_EV_ADV_MONITOR_REMOVED event on the other.
>
> Signed-off-by: Miao-chen Chou
> Sig
Hi Howard,
> Set scan parameters when there is at least one Advertisement monitor.
>
> Signed-off-by: Howard Chung
> Reviewed-by: Alain Michaud
> Reviewed-by: Manish Mandlik
> Reviewed-by: Abhishek Pandit-Subedi
> Reviewed-by: Miao-chen Chou
> ---
>
> (no changes since v1)
>
> net/bluetoot
If BTF data is missing or removed from the ELF section it is still exported
via sysfs as a zero-length file:
root@OpenWrt:/# ls -l /sys/kernel/btf/vmlinux
-r--r--r--1 rootroot0 Jul 18 02:59 /sys/kernel/btf/vmlinux
Moreover, reads from this file succeed and leak kernel data:
roo
Hello,
I've been experimenting with BPF and BTF on small, emebedded platforms
requiring cross-compilation to varying archs, word-sizes, and endianness.
These environments are not the most common for the majority of eBPF users,
and have exposed multiple problems with basic functionality. This patch
Systems with memory or disk constraints often reduce the kernel footprint
by configuring LD_DEAD_CODE_DATA_ELIMINATION. However, this can result in
removal of any BTF information.
Use the KEEP() macro to preserve the BTF data as done with other important
sections, while still allowing for smaller
Code in btf__parse_raw() fails to detect raw BTF of non-native endianness
and assumes it must be ELF data, which then fails to parse as ELF and
yields a misleading error message:
root:/# bpftool btf dump file /sys/kernel/btf/vmlinux
libbpf: failed to get EHDR from /sys/kernel/btf/vmlinux
For
On Sun, Sep 20, 2020 at 4:03 AM Andrew Lunn wrote:
>
> There is a movement to make the code base compile clean with W=1. Some
> subsystems are already clean. In order to keep them clean, we need
> developers to build new code with W=1 by default in these subsystems.
>
> This patchset refactors the
On Sat, Sep 19, 2020 at 05:14:41PM -0700, Andy Lutomirski wrote:
> > 2) have you counted the syscalls that do and do not need that?
>
> No.
Might be illuminating...
> > 3) how many of those realistically *can* be unified with their
> > compat counterparts? [hint: ioctl(2) cannot]
>
> There wo
On 9/19/2020 6:47 PM, Vladimir Oltean wrote:
This series attempts to make DSA VLANs work in the presence of a master
interface that is:
- filtering, so it drops VLANs that aren't explicitly added to its
filter list
- offloading, so the old assumptions in the tagging code about there
bein
On 9/19/2020 6:47 PM, Vladimir Oltean wrote:
The whole purpose of tag_8021q is to send VLAN-tagged traffic to the
CPU, from which the driver can decode the source port and switch id.
Currently this only works if the VLAN filtering on the master is
disabled. Change that by explicitly adding co
On 9/19/2020 6:47 PM, Vladimir Oltean wrote:
Most DSA switch tags shift the EtherType to the right, causing the
master to not parse the VLAN as VLAN.
However, not all switches do that (example: tail tags, tag_8021q etc),
and if the DSA master has "rx-vlan-filter: on" in ethtool -k, then we
hav
On 9/19/2020 6:47 PM, Vladimir Oltean wrote:
Check whether there is any hwaccel VLAN tag on RX, and if there is,
treat it as the tag_8021q header.
Signed-off-by: Vladimir Oltean
Reviewed-by: Florian Fainelli
--
Florian
On 9/19/2020 6:47 PM, Vladimir Oltean wrote:
When the bridge has VLAN awareness disabled there isn't any duplication
of functionality, since the bridge does not process VLAN. Don't deny
adding 8021q uppers to DSA switch ports in that case. The switch is
supposed to simply pass traffic leaving
On 9/19/2020 6:47 PM, Vladimir Oltean wrote:
The current logic beats me a little bit. The comment that "bridge skips
-EOPNOTSUPP, so skip the prepare phase" was introduced in commit
fb2dabad69f0 ("net: dsa: support VLAN filtering switchdev attr").
I'm not sure:
(a) ok, the bridge skips -EOPNO
On 9/19/2020 6:47 PM, Vladimir Oltean wrote:
This is checking for the following order of operations, and makes sure
to deny that configuration:
ip link add link swp2 name swp2.100 type vlan id 100
ip link add br0 type bridge vlan_filtering 1
ip link set swp2 master br0
bridge vlan add dev swp
On 9/19/2020 6:47 PM, Vladimir Oltean wrote:
DSA tries to prevent having a VLAN added by a bridge and by an 802.1Q
upper at the same time. It does that by checking the VID in
.ndo_vlan_rx_add_vid(), since that's something that the 8021q module
calls, via vlan_vid_add(). When a VLAN matches in
On 9/19/2020 6:47 PM, Vladimir Oltean wrote:
We'll be adding a new check in the PRECHANGEUPPER notifier, where we'll
need to check some VLAN uppers. It is hard to do that when there is
already a function named dsa_slave_upper_vlan_check. So rename this one.
Not to mention that this function p
On 9/19/2020 6:47 PM, Vladimir Oltean wrote:
There doesn't seem to be any strong technical reason for doing it this
way, but we'll be adding more checks for invalid upper device
configurations, and it will be easier to have them all grouped under
PRECHANGEUPPER.
Tested that it still works:
ip
DSA tries to prevent having a VLAN added by a bridge and by an 802.1Q
upper at the same time. It does that by checking the VID in
.ndo_vlan_rx_add_vid(), since that's something that the 8021q module
calls, via vlan_vid_add(). When a VLAN matches in both subsystems, this
check returns -EBUSY.
Howev
This is checking for the following order of operations, and makes sure
to deny that configuration:
ip link add link swp2 name swp2.100 type vlan id 100
ip link add br0 type bridge vlan_filtering 1
ip link set swp2 master br0
bridge vlan add dev swp2 vid 100
Instead of using vlan_for_each(), which
There doesn't seem to be any strong technical reason for doing it this
way, but we'll be adding more checks for invalid upper device
configurations, and it will be easier to have them all grouped under
PRECHANGEUPPER.
Tested that it still works:
ip link set br0 type bridge vlan_filtering 1
ip link
We'll be adding a new check in the PRECHANGEUPPER notifier, where we'll
need to check some VLAN uppers. It is hard to do that when there is
already a function named dsa_slave_upper_vlan_check. So rename this one.
Not to mention that this function probably shouldn't have started with
"dsa_slave_" i
The whole purpose of tag_8021q is to send VLAN-tagged traffic to the
CPU, from which the driver can decode the source port and switch id.
Currently this only works if the VLAN filtering on the master is
disabled. Change that by explicitly adding code to tag_8021q.c to add
the VLANs corresponding t
The current logic beats me a little bit. The comment that "bridge skips
-EOPNOTSUPP, so skip the prepare phase" was introduced in commit
fb2dabad69f0 ("net: dsa: support VLAN filtering switchdev attr").
I'm not sure:
(a) ok, the bridge skips -EOPNOTSUPP, but, so what, where are we
returning -E
This series attempts to make DSA VLANs work in the presence of a master
interface that is:
- filtering, so it drops VLANs that aren't explicitly added to its
filter list
- offloading, so the old assumptions in the tagging code about there
being a VLAN tag in the skb are not necessarily true any
Most DSA switch tags shift the EtherType to the right, causing the
master to not parse the VLAN as VLAN.
However, not all switches do that (example: tail tags, tag_8021q etc),
and if the DSA master has "rx-vlan-filter: on" in ethtool -k, then we
have a problem.
Therefore, we could populate the VLA
When the bridge has VLAN awareness disabled there isn't any duplication
of functionality, since the bridge does not process VLAN. Don't deny
adding 8021q uppers to DSA switch ports in that case. The switch is
supposed to simply pass traffic leaving the VLAN tag as-is, and the
stack will happily str
Check whether there is any hwaccel VLAN tag on RX, and if there is,
treat it as the tag_8021q header.
Signed-off-by: Vladimir Oltean
---
net/dsa/tag_sja1105.c | 21 +
1 file changed, 17 insertions(+), 4 deletions(-)
diff --git a/net/dsa/tag_sja1105.c b/net/dsa/tag_sja1105.c
On Sun, Sep 20, 2020 at 02:39:39AM +0200, ansuels...@gmail.com wrote:
>
>
> > -Messaggio originale-
> > Da: Andrew Lunn
> > Inviato: domenica 20 settembre 2020 02:31
> > A: Ansuel Smith
> > Cc: Miquel Raynal ; Richard Weinberger
> > ; Vignesh Raghavendra ; Rob Herring
> > ; David S. Mil
> -Messaggio originale-
> Da: Andrew Lunn
> Inviato: domenica 20 settembre 2020 02:31
> A: Ansuel Smith
> Cc: Miquel Raynal ; Richard Weinberger
> ; Vignesh Raghavendra ; Rob Herring
> ; David S. Miller ; Jakub
> Kicinski ; Heiner Kallweit ;
> Russell King ; Frank Rowand
> ; Boris Brez
> + mac-address-increment:
> +description:
> + The MAC address can optionally be increased (or decreased using
> + negative values) from the original value readed (from a nvmem cell
Read is irregular, there is no readed, just read.
> + for example). This can be used if the mac
> +
> +/* 0 = Clause 22, 1 = Clause 45 */
> +#define MDIO_MODE_BITBIT(8)
How about calling this MDIO_MODE_C45
> + /* Enter Clause 45 mode */
> + data = readl(priv->membase + MDIO_MODE_REG);
> +
> + data |= MDIO_MODE_BIT;
> +
> +
On Sat, Sep 19, 2020 at 4:24 PM Al Viro wrote:
>
> On Sat, Sep 19, 2020 at 03:53:40PM -0700, Andy Lutomirski wrote:
>
> > > It would not be a win - most of the syscalls don't give a damn
> > > about 32bit vs. 64bit...
> >
> > Any reasonable implementation would optimize it out for syscalls that do
> static int rtl8366rb_setup(struct dsa_switch *ds)
> {
> struct realtek_smi *smi = ds->priv;
> + struct rtl8366rb *rb = smi->chip_data;
> const u16 *jam_table;
> u32 chip_ver = 0;
> u32 chip_id = 0;
Hi Linus
Reverse Christmas tree means you need to do the assignment
From: Dan Murphy
Date: Fri, 18 Sep 2020 14:14:50 -0500
> As per patch https://lore.kernel.org/patchwork/patch/1300241/ the link
> modes for 100base FX full and half duplex modes did not exist. Adding these
> link modes to the core and ethtool allow devices like the DP83822, DP83869 and
> Broadco
From: David Awogbemila
Date: Fri, 18 Sep 2020 11:07:19 -0700
> @@ -514,11 +516,11 @@ int gve_adminq_describe_device(struct gve_priv *priv)
> mac = descriptor->mac;
> dev_info(&priv->pdev->dev, "MAC addr: %pM\n", mac);
> priv->tx_pages_per_qpl = be16_to_cpu(descriptor->tx_pages_p
From: David Awogbemila
Date: Fri, 18 Sep 2020 11:07:18 -0700
> @@ -514,10 +517,54 @@ int gve_adminq_describe_device(struct gve_priv *priv)
> priv->rx_pages_per_qpl = be16_to_cpu(descriptor->rx_pages_per_qpl);
> if (priv->rx_pages_per_qpl < priv->rx_desc_cnt) {
> dev_err(
From: sa...@kernel.org
Date: Fri, 18 Sep 2020 10:28:24 -0700
> ('net/mlx5e: Protect encap route dev from concurrent release')
I'm being asked to queue this up for -stable, but this change does not
exist in this pull request.
Please sort this out and resubmit.
Thank you.
From: Xie He
Date: Fri, 18 Sep 2020 06:56:16 -0700
> skb->nh.raw has been renamed as skb->network_header in 2007, in
> commit b0e380b1d8a8 ("[SK_BUFF]: unions of just one member don't get
> anything done, kill them")
>
> So here we change it to the new name.
>
> Cc: Willem
From: Arnd Bergmann
Date: Fri, 18 Sep 2020 14:05:18 +0200
> --- a/net/ethtool/ioctl.c
> +++ b/net/ethtool/ioctl.c
...
> +static inline bool ethtool_translate_compat(void)
> +{
Please don't use the inline keyword in foo.c files.
Thank you.
On Sat, Sep 19, 2020 at 03:53:40PM -0700, Andy Lutomirski wrote:
> > It would not be a win - most of the syscalls don't give a damn
> > about 32bit vs. 64bit...
>
> Any reasonable implementation would optimize it out for syscalls that don’t
> care. Or it could be explicit:
>
> DEFINE_MULTIARCH
> On Sep 19, 2020, at 3:41 PM, Al Viro wrote:
>
> On Sat, Sep 19, 2020 at 03:23:54PM -0700, Andy Lutomirski wrote:
>>
On Sep 19, 2020, at 3:09 PM, Al Viro wrote:
>>>
>>> On Fri, Sep 18, 2020 at 05:16:15PM +0200, Christoph Hellwig wrote:
> On Fri, Sep 18, 2020 at 02:58:22PM +0100,
On Sat, Sep 19, 2020 at 03:23:54PM -0700, Andy Lutomirski wrote:
>
> > On Sep 19, 2020, at 3:09 PM, Al Viro wrote:
> >
> > On Fri, Sep 18, 2020 at 05:16:15PM +0200, Christoph Hellwig wrote:
> >>> On Fri, Sep 18, 2020 at 02:58:22PM +0100, Al Viro wrote:
> >>> Said that, why not provide a variant
Lots of embedded devices use the mac-address of other interface
extracted from nvmem cells and increments it by one or two. Add two
bindings to integrate this and directly use the right mac-address for
the interface. Some example are some routers that use the gmac
mac-address stored in the art part
Two new bindings are now supported by the of_net driver to increase (or
decrease) a mac-address. This can be very useful in case where the
system extract the mac-address for the device from a dedicated partition
and have a generic mac-address that needs to be incremented based on the
device number.
Document the use of this 2 new bindings, nvmem-provider and nvmem-cell,
used to describe the nvmem cell that the subpartition provide to the
nvmem api and the system. Nvmem cell are direct subnode of the
subpartition and are skipped by the 'fixed-partitions' parser if they
contain the 'nvmem-cell'
The mtd support for the nvmem api has been stalled from 2018 with a patch
half pushed hoping that a scheme is found for the mtd name later. This
pathset try to address this and add a very needed feature for the
mac-address.
My solution to the already discussed problem here [1] is to keep it simple
Introduce 2 new bindings for the mtd structure.
Mtd partitions can be set as 'nvmem-provider' and any subpartition defined
with the tag 'nvmem-cell' are skipped by the 'fixed-partitions' parser
and registred as a nvmem cell by the nvmem api.
Signed-off-by: Ansuel Smith
---
drivers/mtd/mtdcore.c
> On Sep 19, 2020, at 3:09 PM, Al Viro wrote:
>
> On Fri, Sep 18, 2020 at 05:16:15PM +0200, Christoph Hellwig wrote:
>>> On Fri, Sep 18, 2020 at 02:58:22PM +0100, Al Viro wrote:
>>> Said that, why not provide a variant that would take an explicit
>>> "is it compat" argument and use it there?
> On Sep 19, 2020, at 2:16 PM, Arnd Bergmann wrote:
>
> On Sat, Sep 19, 2020 at 6:21 PM Andy Lutomirski wrote:
>>> On Fri, Sep 18, 2020 at 8:16 AM Christoph Hellwig wrote:
>>> On Fri, Sep 18, 2020 at 02:58:22PM +0100, Al Viro wrote:
Said that, why not provide a variant that would take a
On Fri, Sep 18, 2020 at 05:16:15PM +0200, Christoph Hellwig wrote:
> On Fri, Sep 18, 2020 at 02:58:22PM +0100, Al Viro wrote:
> > Said that, why not provide a variant that would take an explicit
> > "is it compat" argument and use it there? And have the normal
> > one pass in_compat_syscall() to t
On Sat, 19 Sep 2020, Arnd Bergmann wrote:
> On Sat, Sep 19, 2020 at 6:21 PM Andy Lutomirski wrote:
> > On Fri, Sep 18, 2020 at 8:16 AM Christoph Hellwig wrote:
> > > On Fri, Sep 18, 2020 at 02:58:22PM +0100, Al Viro wrote:
> > > > Said that, why not provide a variant that would take an explicit
The MTU setting for this DSA switch is global so we need
to keep track of the MTU set for each port, then as soon
as any MTU changes, roof the MTU to the biggest common
denominator and poke that into the switch MTU setting.
To achieve this we need a per-chip-variant state container
for the RTL8366
Two new bindings are now supported by the of_net driver to increase (or
decrease) a mac-address. This can be very useful in case where the
system extract the mac-address for the device from a dedicated partition
and have a generic mac-address that needs to be incremented based on the
device number.
The mtd support for the nvmem api has been stalled from 2018 with a patch
half pushed hoping that a scheme is found for the mtd name later. This
pathset try to address this and add a very needed feature for the
mac-address.
My solution to the already discussed problem here [1] is to keep it simple
Document the use of this 2 new bindings, nvmem-provider and nvmem-cell,
used to describe the nvmem cell that the subpartition provide to the
nvmem api and the system. Nvmem cell are direct subnode of the
subpartition and are skipped by the 'fixed-partitions' parser if they
contain the 'nvmem-cell'
Lots of embedded devices use the mac-address of other interface
extracted from nvmem cells and increments it by one or two. Add two
bindings to integrate this and directly use the right mac-address for
the interface. Some example are some routers that use the gmac
mac-address stored in the art part
Introduce 2 new bindings for the mtd structure.
Mtd partitions can be set as 'nvmem-provider' and any subpartition defined
with the tag 'nvmem-cell' are skipped by the 'fixed-partitions' parser
and registred as a nvmem cell by the nvmem api.
Signed-off-by: Ansuel Smith
---
drivers/mtd/mtdcore.c
From: Jason Yan
Date: Sat, 19 Sep 2020 15:45:56 +0800
> This addresses the following coccinelle warning:
>
> drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:15415:1-26: WARNING:
> Assignment of 0/1 to bool variable
> drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:12393:2-17: WARNING:
> Assign
From: Jason Yan
Date: Sat, 19 Sep 2020 15:46:09 +0800
> This addresses the following coccinelle warning:
>
> drivers/net/ethernet/realtek/8139too.c:981:2-8: WARNING: Assignment of
> 0/1 to bool variable
>
> Reported-by: Hulk Robot
> Signed-off-by: Jason Yan
Applied.
From: Jason Yan
Date: Sat, 19 Sep 2020 15:46:17 +0800
> This addresses the following coccinelle warning:
>
> drivers/net/ethernet/ti/cpsw.c:1599:2-17: WARNING: Assignment of 0/1 to
> bool variable
> drivers/net/ethernet/ti/cpsw.c:1300:2-17: WARNING: Assignment of 0/1 to
> bool variable
>
> Repo
From: Jason Yan
Date: Sat, 19 Sep 2020 15:45:27 +0800
> This addresses the following coccinelle warning:
>
> drivers/net/ethernet/broadcom/b44.c:2213:6-20: WARNING: Assignment of
> 0/1 to bool variable
> drivers/net/ethernet/broadcom/b44.c:2218:2-16: WARNING: Assignment of
> 0/1 to bool variable
From: Jason Yan
Date: Sat, 19 Sep 2020 15:45:43 +0800
> This addresses the following coccinelle warning:
>
> drivers/net/ethernet/qlogic/qed/qed_rdma.c:1465:2-13: WARNING:
> Assignment of 0/1 to bool variable
> drivers/net/ethernet/qlogic/qed/qed_rdma.c:1468:2-14: WARNING:
> Assignment of 0/1 to
From: Zheng Yongjun
Date: Sat, 19 Sep 2020 15:40:47 +0800
> @@ -179,7 +175,7 @@ enum vxge_hw_status vxge_hw_vpath_intr_disable(
> (u32)VXGE_HW_INTR_MASK_ALL,
> &vp_reg->vpath_general_int_mask);
>
> - val64 = VXGE_HW_TIM_CLR_INT_EN_VP(1 << (16 - vpath->vp_id));
>
On Sat, Sep 19, 2020 at 6:21 PM Andy Lutomirski wrote:
> On Fri, Sep 18, 2020 at 8:16 AM Christoph Hellwig wrote:
> > On Fri, Sep 18, 2020 at 02:58:22PM +0100, Al Viro wrote:
> > > Said that, why not provide a variant that would take an explicit
> > > "is it compat" argument and use it there? An
From: Zheng Yongjun
Date: Sat, 19 Sep 2020 10:32:35 +0800
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/net/ethernet/micrel/ksz884x.c: In function rx_proc:
> drivers/net/ethernet/micrel/ksz884x.c:4981:6: warning: variable ‘rx_status’
> set but not used [-Wunused-but-set-variable]
From: Zheng Yongjun
Date: Sat, 19 Sep 2020 10:05:50 +0800
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/net/ethernet/marvell/pxa168_eth.c: In function pxa168_eth_change_mtu:
> drivers/net/ethernet/marvell/pxa168_eth.c:1190:6: warning: variable ‘retval’
> set but not used [-Wunuse
From: Zheng Yongjun
Date: Sat, 19 Sep 2020 09:50:20 +0800
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/net/ethernet/intel/e1000/e1000_hw.c: In function
> e1000_phy_init_script:
> drivers/net/ethernet/intel/e1000/e1000_hw.c:132:6: warning: variable
> ‘ret_val’ set but not used [
From: Zheng Yongjun
Date: Sat, 19 Sep 2020 09:31:23 +0800
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/net/ethernet/cavium/liquidio/octeon_device.c: In function
> lio_pci_readq:
> drivers/net/ethernet/cavium/liquidio/octeon_device.c:1327:6: warning:
> variable ‘val32’ set but n
From: zhengyongjun
Date: Sat, 19 Sep 2020 03:02:39 +
> This is the bad patch, please ignore it, thank you very much.
Please do not quote your entire patch when you reply like this.
It makes the reply look like a brand new patch to our patchwork
tracking system, which makes more work for us.
From: Zheng Yongjun
Date: Sat, 19 Sep 2020 10:46:44 +0800
> @@ -1226,8 +1226,8 @@ static int ns83820_get_link_ksettings(struct net_device
> *ndev,
>
> /* read current configuration */
> cfg = readl(dev->base + CFG) ^ SPDSTS_POLARITY;
> - tanar = readl(dev->base + TANAR);
>
From: Zheng Yongjun
Date: Sat, 19 Sep 2020 10:37:32 +0800
> `ret` is never used, so remove it.
You are not removing it:
> @@ -3053,7 +3053,7 @@ static int lan743x_pm_suspend(struct device *dev)
> /* Host sets PME_En, put D3hot */
> ret = pci_prepare_to_sleep(pdev);
>
> - retur
From: Zheng Yongjun
Date: Sat, 19 Sep 2020 10:39:09 +0800
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/net/ethernet/microchip/lan743x_main.c: In function lan743x_pm_suspend:
> drivers/net/ethernet/microchip/lan743x_main.c:3041:6: warning: variable ‘ret’
> set but not used [-Wunu
In mt7531_cpu_port_config(), if the variable port is neither 5 nor 6,
then variable interface will be used uninitialised. Change the function
to return -EINVAL in this case.
As the return value of mt7531_cpu_port_config() is never checked
(even though it returns an int) add a check in the correct
On Sat, Sep 19, 2020 at 07:27:30PM +0200, Greg Kroah-Hartman wrote:
> > It's probably heresy, but why do I need to integrate into the RDMA
> > subsystem ?
> > I understand your reasoning about networking (Ethernet) as the driver
> > connects to the kernel networking stack (netdev), but with RDMA t
There is a desire that subtrees can enable W=1 by default. To make
this possible, put the extra compiler flags into an exported variable,
so other Makefiles can make use of them.
Signed-off-by: Andrew Lunn
---
scripts/Makefile.extrawarn | 33 ++---
1 file changed, 18
There is a movement to make the code base compile clean with W=1. Some
subsystems are already clean. In order to keep them clean, we need
developers to build new code with W=1 by default in these subsystems.
This patchset refactors the core Makefile warning code to allow the
additional warnings W=
Add to the subdirectory ccflags variable the additional compiler
warnings which W=1 adds at the top level when enabled.
Signed-off-by: Andrew Lunn
---
drivers/net/mdio/Makefile | 3 +++
drivers/net/pcs/Makefile | 3 +++
drivers/net/phy/Makefile | 3 +++
3 files changed, 9 insertions(+)
diff -
On Sat, Sep 19, 2020 at 07:43:28PM +0300, Oded Gabbay wrote:
> It's probably heresy, but why do I need to integrate into the RDMA subsystem ?
Hi Oded
I don't know the RDMA subsystem at all. So i will give a more generic
answer. Are you reinventing things which a subsystem core already has?
The su
On Sat, Sep 19, 2020 at 07:43:28PM +0300, Oded Gabbay wrote:
> On Sat, Sep 19, 2020 at 11:30 AM Greg Kroah-Hartman
> wrote:
> >
> > On Sat, Sep 19, 2020 at 11:20:03AM +0300, Leon Romanovsky wrote:
> > > On Sat, Sep 19, 2020 at 08:40:20AM +0200, Greg Kroah-Hartman wrote:
> > > > On Fri, Sep 18, 202
On Sat, Sep 19, 2020 at 11:30 AM Greg Kroah-Hartman
wrote:
>
> On Sat, Sep 19, 2020 at 11:20:03AM +0300, Leon Romanovsky wrote:
> > On Sat, Sep 19, 2020 at 08:40:20AM +0200, Greg Kroah-Hartman wrote:
> > > On Fri, Sep 18, 2020 at 03:19:05PM +0300, Leon Romanovsky wrote:
> > > > > So we do have an
On Fri, Sep 18, 2020 at 8:16 AM Christoph Hellwig wrote:
>
> On Fri, Sep 18, 2020 at 02:58:22PM +0100, Al Viro wrote:
> > Said that, why not provide a variant that would take an explicit
> > "is it compat" argument and use it there? And have the normal
> > one pass in_compat_syscall() to that...
On Fri, 18 Sep 2020 22:52:56 -0600
David Ahern wrote:
> On 9/18/20 9:48 AM, Jakub Kicinski wrote:
> > On Fri, 18 Sep 2020 09:44:35 -0600 David Ahern wrote:
> >> On 9/16/20 1:42 PM, Jakub Kicinski wrote:
> >>> 2: eth0: mtu 1500 qdisc mq state UP
> >>> mode DEFAULT group default qlen 1000
> >
Hi Lukas,
On Thu, Aug 27, 2020 at 10:55:03AM +0200, Lukas Wunner wrote:
[...]
> Overall, performance improves with this commit if neither netfilter nor
> traffic control is used. However it degrades a little if only traffic
> control is used, due to the "noinline", the additional outer static key
Hi Daniel,
Long time no see, unfortunately this complicated situation is keeping
us away from personal reach, that's unfortunate. Now, looking into
this topic...
On Fri, Sep 18, 2020 at 10:31:09PM +0200, Daniel Borkmann wrote:
> [...] That is if there is an opt-in to such data path being used, th
Lukoil Overseas Gh. Ltd.
Oil & Gas Extraction Companies
No. 68 Mankralo Street
East Cantonments
Accra Ghana.
Dear: Sir
My name is Engr: Kofi Koduah Sarpong.
I am the Chief Executive Officer of Lukoil Overseas Gh. Ltd Ghana.
I will be retiring from my work by June next year. I write to inform
you
Lukoil Overseas Gh. Ltd.
Oil & Gas Extraction Companies
No. 68 Mankralo Street
East Cantonments
Accra Ghana.
Dear: Reem Awwaad
My name is Engr: Kofi Koduah Sarpong.
I am the Chief Executive Officer of Lukoil Overseas Gh. Ltd Ghana.
I will be retiring from my work by June next year. I write to inf
From: Al Viro
> Sent: 18 September 2020 14:58
>
> On Fri, Sep 18, 2020 at 03:44:06PM +0200, Christoph Hellwig wrote:
> > On Fri, Sep 18, 2020 at 02:40:12PM +0100, Al Viro wrote:
> > > > /* Vector 0x110 is LINUX_32BIT_SYSCALL_TRAP */
> > > > - return pt_regs_trap_type(current_pt_regs(
Add a devlink region to return the per port registers.
Signed-off-by: Andrew Lunn
---
drivers/net/dsa/mv88e6xxx/chip.c| 8
drivers/net/dsa/mv88e6xxx/devlink.c | 61 +
drivers/net/dsa/mv88e6xxx/devlink.h | 6 ++-
3 files changed, 74 insertions(+), 1 deletion
This patchset extends devlink regions to support per port regions, and
them makes use of them to support the ports of the mv88e6xxx switches.
root@rap:~# devlink region show
mdio_bus/gpio-0:00/global1: size 64 snapshot []
mdio_bus/gpio-0:00/global2: size 64 snapshot []
mdio_bus/gpio-0:00/atu: size
Allow DSA drivers to make use of devlink port regions, via simple
wrappers.
Signed-off-by: Andrew Lunn
---
include/net/dsa.h | 5 +
net/core/devlink.c | 3 +--
net/dsa/dsa.c | 14 ++
3 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/include/net/dsa.h b/inclu
Hide away from DSA drivers how devlink works.
Signed-off-by: Andrew Lunn
---
include/net/dsa.h | 14 ++
1 file changed, 14 insertions(+)
diff --git a/include/net/dsa.h b/include/net/dsa.h
index 01da896b2998..a24d5158ee0c 100644
--- a/include/net/dsa.h
+++ b/include/net/dsa.h
@@ -685
Allow regions to be registered to a devlink port. The same netlink API
is used, but the port index is provided to indicate when a region is a
port region as opposed to a device region.
Signed-off-by: Andrew Lunn
---
include/net/devlink.h | 27 +
net/core/devlink.c| 251 +
From: Christoph Hellwig
> Sent: 18 September 2020 13:45
>
> this series changes import_iovec to transparently deal with comat iovec
> structures, and then cleanups up a lot of code dupliation. But to get
> there it first has to fix the pre-existing bug that io_uring compat
> contexts don't trigge
On 9/19/20 12:23 AM, Chuck Lever wrote:
>
>> On Sep 18, 2020, at 8:50 AM, zhe...@windriver.com wrote:
>>
>> From: He Zhe
>>
>> commit ca07eda33e01 ("SUNRPC: Refactor svc_recvfrom()") introduces
>> svc_flush_bvec to after sock_recvmsg, but sometimes we receive less than we
>> seek, which trigger
From: Jiri Olsa
Adding test that setup following program:
SEC("classifier/test_pkt_md_access")
int test_pkt_md_access(struct __sk_buff *skb)
with its extension:
SEC("freplace/test_pkt_md_access")
int test_pkt_md_access_new(struct __sk_buff *skb)
and tracing that extension with:
SEC
From: Toke Høiland-Jørgensen
In preparation for allowing multiple attachments of freplace programs, move
the references to the target program and trampoline into the
bpf_tracing_link structure when that is created. To do this atomically,
introduce a new mutex in prog->aux to protect writing to th
From: Toke Høiland-Jørgensen
The check_attach_btf_id() function really does three things:
1. It performs a bunch of checks on the program to ensure that the
attachment is valid.
2. It stores a bunch of state about the attachment being requested in
the verifier environment and struct bpf_p
1 - 100 of 134 matches
Mail list logo
