Kerneldoc expects attributes/parameters to be in '@*.: ' format and
gets confused if the variable does not follow the type/attribute
definitions.
Fixes the following W=1 kernel build warning(s):
drivers/net/wireless/intel/iwlwifi/dvm/devices.c:66: warning: Function
parameter or member 'priv' no
Fixes the following W=1 kernel build warning(s):
drivers/net/wireless/ath/wil6210/wmi.c:52: warning: Incorrect use of
kernel-doc format: * Addressing - theory of operations
drivers/net/wireless/ath/wil6210/wmi.c:70: warning: Incorrect use of
kernel-doc format: * @sparrow_fw_mapping provides
Fixes the following W=1 kernel build warning(s):
drivers/net/wireless/ath/ath9k/ar9001_initvals.h:462:18: warning:
‘ar5416Bank6_9100’ defined but not used [-Wunused-const-variable=]
Cc: QCA ath9k Development
Cc: Kalle Valo
Cc: "David S. Miller"
Cc: Jakub Kicinski
Cc: linux-wirel...@vger.ker
Tue, Sep 08, 2020 at 08:27:13PM CEST, tlfal...@linux.ibm.com wrote:
>On 9/4/20 5:37 PM, Jakub Kicinski wrote:
>> On Fri, 4 Sep 2020 10:31:41 +0200 Jiri Pirko wrote:
>> > Thu, Sep 03, 2020 at 07:59:45PM CEST, tlfal...@linux.ibm.com wrote:
>> > > Hello, I am trying to expose MAC/VLAN ACL and pvid set
Fixes the following W=1 kernel build warning(s):
drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_lcn.c:361:25:
warning: unused variable 'lcnphy_rx_iqcomp_table_rev0' [-Wunused-const-variable]
struct lcnphy_rx_iqcomp lcnphy_rx_iqcomp_table_rev0[] = {
^
Signed-of
Fixes the following W=1 kernel build warning(s):
drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phytbl_lcn.c:108:18:
warning: unused variable 'dot11lcn_gain_tbl_rev1' [-Wunused-const-variable]
static const u32 dot11lcn_gain_tbl_rev1[] = {
Signed-off-by: Lee Jones
---
.../brcm80211/brcm
Hi Andy,
On Fri, Sep 04, 2020 at 10:41:17PM +0300, Andy Shevchenko wrote:
> On Fri, Sep 4, 2020 at 7:52 PM Vadym Kochan wrote:
> >
> > The following features are supported:
> >
> > - VLAN-aware bridge offloading
> > - VLAN-unaware bridge offloading
> > - FDB offloading (learning, agei
Fixes the following W=1 kernel build warning(s):
drivers/net/wireless/ath/ath9k/ar5008_initvals.h:627:18: warning:
‘ar5416Bank7’ defined but not used [-Wunused-const-variable=]
627 | static const u32 ar5416Bank7[][2] = {
| ^~~
drivers/net/wireless/ath/ath9k/ar5008_initvals.h:548:18: w
Fixes the following W=1 kernel build warning(s):
drivers/net/wireless/ath/ath9k/ar5008_initvals.h:553:18: warning:
‘ar5416Bank6’ defined but not used [-Wunused-const-variable=]
Cc: QCA ath9k Development
Cc: Kalle Valo
Cc: "David S. Miller"
Cc: Jakub Kicinski
Cc: linux-wirel...@vger.kernel.o
Fixes the following W=1 kernel build warning(s):
drivers/net/wireless/ath/ath6kl/wmi.c: In function
‘ath6kl_wmi_bitrate_reply_rx’:
drivers/net/wireless/ath/ath6kl/wmi.c:1204:6: warning: variable ‘rate’ set but
not used [-Wunused-but-set-variable]
Cc: Kalle Valo
Cc: "David S. Miller"
Cc: Jak
Fixes the following W=1 kernel build warning(s):
drivers/net/wireless/ath/wil6210/wmi.c:279: warning: Function parameter or
member 'ptr_' not described in 'wmi_buffer_block'
drivers/net/wireless/ath/wil6210/wmi.c:279: warning: Excess function parameter
'ptr' description in 'wmi_buffer_block'
Fixes the following W=1 kernel build warning(s):
drivers/net/wireless/ath/ath9k/ar9002_initvals.h:900:18: warning:
‘ar9280PciePhy_clkreq_off_L1_9280’ defined but not used
[-Wunused-const-variable=]
Cc: QCA ath9k Development
Cc: Kalle Valo
Cc: "David S. Miller"
Cc: Jakub Kicinski
Cc: linux-
There has been no attempt to document any of the function parameters
here.
Fixes the following W=1 kernel build warning(s):
drivers/net/wireless/ath/wil6210/wil_platform.c:27: warning: Function
parameter or member 'dev' not described in 'wil_platform_init'
drivers/net/wireless/ath/wil6210/wil_
Fixes the following W=1 kernel build warning(s):
drivers/net/wireless/ath/wil6210/pmc.c:43: warning: Function parameter or
member 'wil' not described in 'wil_pmc_alloc'
drivers/net/wireless/ath/wil6210/pmc.c:43: warning: Function parameter or
member 'num_descriptors' not described in 'wil_pmc_
None of these headers provide any parameter documentation.
Fixes the following W=1 kernel build warning(s):
drivers/net/wireless/ath/wil6210/txrx.c:259: warning: Function parameter or
member 'wil' not described in 'wil_vring_alloc_skb'
drivers/net/wireless/ath/wil6210/txrx.c:259: warning: Func
Fixes the following W=1 kernel build warning(s):
drivers/net/wireless/intel/iwlwifi/mvm/tx.c:1379: warning: Function parameter
or member 'rate_n_flags' not described in 'iwl_mvm_hwrate_to_tx_status'
drivers/net/wireless/intel/iwlwifi/mvm/tx.c:1379: warning: Function parameter
or member 'info'
Fixes the following W=1 kernel build warning(s):
drivers/net/wireless/ath/wil6210/txrx_edma.c:155: warning: Function parameter
or member 'wil' not described in 'wil_ring_alloc_skb_edma'
drivers/net/wireless/ath/wil6210/txrx_edma.c:155: warning: Function parameter
or member 'ring' not described
Fixes the following W=1 kernel build warning(s):
drivers/net/wireless/ath/wil6210/interrupt.c:652: warning: Function parameter
or member 'irq' not described in 'wil6210_thread_irq'
drivers/net/wireless/ath/wil6210/interrupt.c:652: warning: Function parameter
or member 'cookie' not described in
Fixes the following W=1 kernel build warning(s):
drivers/net/wireless/intel/iwlwifi/dvm/rxon.c:695: warning: bad line:
drivers/net/wireless/intel/iwlwifi/dvm/rxon.c:701: warning: Function parameter
or member 'priv' not described in 'iwl_set_rxon_channel'
drivers/net/wireless/intel/iwlwifi/dvm/
2 of which do not attempt to document their parameters, 1 does a poor job.
Fixes the following W=1 kernel build warning(s):
drivers/net/wireless/intel/iwlwifi/dvm/scan.c:193: warning: Function parameter
or member 'priv' not described in 'iwl_scan_cancel'
drivers/net/wireless/intel/iwlwifi/dvm/
Looks as if it's never been used.
Fixes the following W=1 kernel build warning(s):
drivers/net/wireless/intel/iwlwifi/mvm/ops.c:466:36: warning:
‘iwl_mvm_debug_names’ defined but not used [-Wunused-const-variable=]
Cc: Johannes Berg
Cc: Emmanuel Grumbach
Cc: Luca Coelho
Cc: Intel Linux Wire
Kerneldoc expects attributes/parameters to be in '@*.: ' format and
gets confused if the variable does not follow the type/attribute
definitions.
Fixes the following W=1 kernel build warning(s):
drivers/net/wireless/ath/wil6210/debugfs.c:456: warning: Function parameter or
member 'wil' not desc
Fixes the following W=1 kernel build warning(s):
drivers/net/wireless/intel/iwlwifi/dvm/sta.c:244: warning: Function parameter
or member 'priv' not described in 'iwl_prep_station'
drivers/net/wireless/intel/iwlwifi/dvm/sta.c:244: warning: Function parameter
or member 'ctx' not described in 'iw
None of these headers attempt to document any function parameters.
Fixes the following W=1 kernel build warning(s):
drivers/net/wireless/intel/iwlwifi/dvm/tx.c:811: warning: Function parameter
or member 'priv' not described in 'iwlagn_hwrate_to_tx_control'
drivers/net/wireless/intel/iwlwifi/dv
None of these headers attempt to document any function parameters.
Fixes the following W=1 kernel build warning(s):
drivers/net/wireless/intel/iwlwifi/dvm/rs.c:165: warning: cannot understand
function prototype: 'const u16 expected_tpt_legacy[IWL_RATE_COUNT] = '
drivers/net/wireless/intel/iwlw
This is a rebased/re-worked set of patches which have been
previously posted to the mailing list(s).
This set is part of a larger effort attempting to clean-up W=1
kernel builds, which are currently overwhelmingly riddled with
niggly little warnings.
There are quite a few W=1 warnings in the Wire
The delay was intended to be configured to "simulate" a high(er) BDP
link. As such, it needs to be set as part of the loss-configuration and
not as part of the netem reordering configuration.
The reordering-config also requires a delay but that delay is the
reordering-extend. So, a good approach i
From: Björn Töpel
For AF_XDP sockets, there was a discrepancy between the number of of
pinned pages and the size of the umem region.
The size of the umem region is used to validate the AF_XDP descriptor
addresses. The logic that pinned the pages covered by the region only
took whole pages into c
On Thu, Sep 10, 2020 at 1:32 PM Dmitry Vyukov wrote:
>
> On Thu, Sep 10, 2020 at 9:20 AM Anant Thazhemadam
> wrote:
> > Looks like this bug is no longer valid. I'm not sure which commit seems to
> > have fixed it. Can this be marked as invalid or closed yet?
>
> You can see on the dashboard (or
On Fri, Sep 04, 2020 at 10:12:07PM +0300, Andy Shevchenko wrote:
> On Fri, Sep 4, 2020 at 7:52 PM Vadym Kochan wrote:
> >
> > Marvell Prestera 98DX326x integrates up to 24 ports of 1GbE with 8
> > ports of 10GbE uplinks or 2 ports of 40Gbps stacking for a largely
> > wireless SMB deployment.
> >
>
From: Magnus Karlsson
Fix the sending of a single packet (or small burst) in xdpsock when
executing in copy mode. Currently, the l2fwd application in xdpsock
only transmits the packets after a batch of them has been received,
which might be confusing if you only send one packet and expect that
it
From: Magnus Karlsson
Fix a possible deadlock in the l2fwd application in xdpsock that can
occur when there is no space in the Tx ring. There are two ways to get
the kernel to consume entries in the Tx ring: calling sendto() to make
it send packets and freeing entries from the completion ring, as
From: Magnus Karlsson
Add a quiet option (-Q) that disables the statistics print outs of
xdpsock. This is good to have when measuring 0% loss rate performance
as it will be quite terrible if the application uses printfs.
Signed-off-by: Magnus Karlsson
---
samples/bpf/xdpsock_user.c | 19 ++
This small series improves/fixes three things in the xdpsock sample
application. Details can be found in the individual commit messages,
but a brief summary follows:
Patch 1: fix one packet sending in xdpsock
Patch 2: fix possible deadlock in xdpsock
Patch 3: add quiet option to xdpsock
This patc
On Thu, Sep 10, 2020 at 7:44 AM Xie He wrote:
>
> The difference between hard_header_len and needed_headroom has long been
> confusing to driver developers. Let's clarify it.
>
> The understanding on this issue in this patch is based on the following
> reasons:
>
> 1.
>
> In af_packet.c, the funct
On Thursday 10 September 2020 14:04:02 Joseph Hwang wrote:
> This patch defines new getsockopt options BT_SNDMTU/BT_RCVMTU
> for SCO socket to be compatible with other bluetooth sockets.
> These new options return the same value as option SCO_OPTIONS
> which is already present on existing kernels.
On Thursday 10 September 2020 14:04:01 Joseph Hwang wrote:
> It is desirable to define the HCI packet payload sizes of
> USB alternate settings so that they can be exposed to user
> space.
>
> Reviewed-by: Alain Michaud
> Reviewed-by: Abhishek Pandit-Subedi
> Signed-off-by: Joseph Hwang
> ---
>
Since commit 8d7017fd621d ("blackhole_netdev: use blackhole_netdev to
invalidate dst entries"), we use blackhole_netdev to invalidate dst entries
instead of loopback device anymore.
Signed-off-by: Miaohe Lin
---
net/core/dst.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/n
Hi,
Joe Perches writes:
> drivers/usb/dwc3/core.c | 2 +-
> drivers/usb/gadget/legacy/inode.c | 2 +-
> drivers/usb/gadget/udc/pxa25x_udc.c | 4 ++--
> drivers/usb/phy/phy-fsl-usb.c |
Remove the weird space inside the NETIF_F_CSUM_MASK.
Signed-off-by: Miaohe Lin
---
include/linux/netdev_features.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/netdev_features.h b/include/linux/netdev_features.h
index 2cc3cf80b49a..0b17c4322b09 100644
--- a/i
Hello,
syzbot found the following issue on:
HEAD commit:f5499c67 nfc: pn533/usb.c: fix spelling of "functions"
git tree: net-next
console output: https://syzkaller.appspot.com/x/log.txt?x=1641505590
kernel config: https://syzkaller.appspot.com/x/.config?x=2b946b3cd0adc99
dashboard
Wait until the QDIO data connection is severed. Otherwise the device
might still be processing the buffers, and end up accessing skb data
that we already freed.
Fixes: 8b5026bc1693 ("s390/qeth: fix qdio teardown after early init error")
Signed-off-by: Julian Wiedmann
---
drivers/s390/net/qeth_l2
Release first buffer as last one since it contains references
to subsequent fragments. This code will be optimized introducing
multi-buffer bit in xdp_buff structure.
Fixes: ca0e014609f05 ("net: mvneta: move skb build after descriptors
processing")
Signed-off-by: Lorenzo Bianconi
---
drivers/ne
On 9/9/20 10:06 PM, Joe Perches wrote:
fallthrough to a separate case/default label break; isn't very readable.
Convert pseudo-keyword fallthrough; statements to a simple break; when
the next label is case or default and the only statement in the next
label block is break;
Found using:
$ grep-
>
> From: Björn Töpel
>
> For AF_XDP sockets, there was a discrepancy between the number of of
> pinned pages and the size of the umem region.
>
> The size of the umem region is used to validate the AF_XDP descriptor
> addresses. The logic that pinned the pages covered by the region only
> took
On Wed, 9 Sep 2020 at 19:26, David Miller wrote:
>
> From: Paul Barker
> Date: Wed, 9 Sep 2020 11:04:13 +0100
>
> > These changes were made while debugging the ksz9477 driver for use on a
> > custom board which uses the ksz9893 switch supported by this driver. The
> > patches have been runtime t
On Wed, Sep 9, 2020 at 10:10 PM Joe Perches wrote:
>
> fallthrough to a separate case/default label break; isn't very readable.
>
> Convert pseudo-keyword fallthrough; statements to a simple break; when
> the next label is case or default and the only statement in the next
> label block is break;
Hello,
syzbot found the following issue on:
HEAD commit:7fb5eefd selftests/bpf: Fix test_sysctl_loop{1, 2} failure..
git tree: bpf-next
console output: https://syzkaller.appspot.com/x/log.txt?x=1424fdb390
kernel config: https://syzkaller.appspot.com/x/.config?x=b6856d16f78d8fa9
das
Hello,
syzbot found the following issue on:
HEAD commit:34d4ddd3 Merge tag 'linux-kselftest-5.9-rc5' of git://git...
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=13db7cdd90
kernel config: https://syzkaller.appspot.com/x/.config?x=8f5c353182ed6199
das
Alexei Starovoitov writes:
> On Wed, Sep 9, 2020 at 8:30 PM David Ahern wrote:
>> >
>> > I think the packets modification (edit dst mac, add vlan tag, etc) should
>> > be
>> > done on egress, which rely on David's XDP egress support.
>>
>> agreed. The DEVMAP used for redirect can have programs
syzbot has found a reproducer for the following issue on:
HEAD commit:746f534a tools/libbpf: Avoid counting local symbols in ABI..
git tree: bpf
console output: https://syzkaller.appspot.com/x/log.txt?x=1317f55990
kernel config: https://syzkaller.appspot.com/x/.config?x=a0437fdd630b
Hi Jens,
Thanks for your feedback,
Yes, blk_flush_plug_list() is only caller of blk_mq_flush_plug_list().
So I checked the callers of blk_flush_plug_list(), found below code path will
call blk_flush_plug_list():
io_schedule_prepare/sched_submit_work->blk_schedule_flush_plug
writeba
This patch-set is to add MC APIs of 1588 one-step timestamping, and
support one-step timestamping for PTP Sync packet on DPAA2.
Before egress, one-step timestamping enablement needs,
- Enabling timestamp and FAS (Frame Annotation Status) in
dpni buffer layout.
- Write timestamp to frame annota
This patch is a preparation for next hardware one-step timestamping
support. For DPAA2, the one step timestamping configuration on
hardware registers has to be done when there is no one-step timestamping
packet in flight. So we will have to use workqueue and skb queue
for such packets transmitting,
Define a global ptp_qoriq structure pointer, and export to use.
The ptp clock operations will be used in dpaa2-eth driver.
For example, supporting one step timestamping needs to write
current time to hardware frame annotation before sending and
then hardware inserts the delay time on frame during s
This patch is to add PTP sync packet one-step timestamping support.
Before egress, one-step timestamping enablement needs,
- Enabling timestamp and FAS (Frame Annotation Status) in
dpni buffer layout.
- Write timestamp to frame annotation and set PTP bit in
FAS to mark as one-step timestampin
Invoke dpaa2_eth_enable_tx_tstamp() once in code after building FD,
rather than calling it in dpaa2_eth_build_single_fd(),
dpaa2_eth_build_sg_fd_single_buf(), and dpaa2_eth_build_sg_fd().
Signed-off-by: Yangbo Lu
---
drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c | 31
This patch is to add APIs of 1588 single step timestamping.
- dpni_set_single_step_cfg
- dpni_get_single_step_cfg
Signed-off-by: Yangbo Lu
---
drivers/net/ethernet/freescale/dpaa2/dpni-cmd.h | 21 +++
drivers/net/ethernet/freescale/dpaa2/dpni.c | 73 +
drivers/ne
Jiri Olsa writes:
> On Wed, Sep 09, 2020 at 05:54:58PM +0200, Toke Høiland-Jørgensen wrote:
>> Jiri Olsa writes:
>>
>> > Eelco reported we can't properly access arguments if the tracing
>> > program is attached to extension program.
>> >
>> > Having following program:
>> >
>> > SEC("classif
Allow using 32bit netlink attribute for packet number when creating or
updating SA in an XPN link.
Now utilities like iproute2's `ip` do not have to know the link type
(XPN or not) when setting the packet number field of an SA.
Signed-off-by: Era Mayflower
---
drivers/net/macsec.c | 95 +
On Wed, Sep 09, 2020 at 03:18:11PM -0700, Jakub Kicinski wrote:
> Add support for the new show-tunnels command. Support dump.
>
> # ethtool --show-tunnels \*
> Tunnel information for eth0:
> UDP port table 0:
> Size: 4
> Types: vxlan
> No entries
> UDP port table 1:
> Size: 4
On 09/09/2020 22:06, Joe Perches wrote:
diff --git a/drivers/net/wireless/mediatek/mt7601u/dma.c
b/drivers/net/wireless/mediatek/mt7601u/dma.c
index 09f931d4598c..778be26d329f 100644
--- a/drivers/net/wireless/mediatek/mt7601u/dma.c
+++ b/drivers/net/wireless/mediatek/mt7601u/dma.c
@@ -193,11
This patch is to add APIs of 1588 single step timestamping.
- dpni_set_single_step_cfg
- dpni_get_single_step_cfg
Signed-off-by: Yangbo Lu
---
Changes for v2:
- None.
---
drivers/net/ethernet/freescale/dpaa2/dpni-cmd.h | 21 +++
drivers/net/ethernet/freescale/dpaa2/dpni.c | 73 +
This patch is to add PTP sync packet one-step timestamping support.
Before egress, one-step timestamping enablement needs,
- Enabling timestamp and FAS (Frame Annotation Status) in
dpni buffer layout.
- Write timestamp to frame annotation and set PTP bit in
FAS to mark as one-step timestampin
This patch-set is to add MC APIs of 1588 one-step timestamping, and
support one-step timestamping for PTP Sync packet on DPAA2.
Before egress, one-step timestamping enablement needs,
- Enabling timestamp and FAS (Frame Annotation Status) in
dpni buffer layout.
- Write timestamp to frame annota
This patch is a preparation for next hardware one-step timestamping
support. For DPAA2, the one step timestamping configuration on
hardware registers has to be done when there is no one-step timestamping
packet in flight. So we will have to use workqueue and skb queue
for such packets transmitting,
Define a global ptp_qoriq structure pointer, and export to use.
The ptp clock operations will be used in dpaa2-eth driver.
For example, supporting one step timestamping needs to write
current time to hardware frame annotation before sending and
then hardware inserts the delay time on frame during s
Invoke dpaa2_eth_enable_tx_tstamp() once in code after building FD,
rather than calling it in dpaa2_eth_build_single_fd(),
dpaa2_eth_build_sg_fd_single_buf(), and dpaa2_eth_build_sg_fd().
Signed-off-by: Yangbo Lu
---
Changes for v2:
- None.
---
drivers/net/ethernet/freescale/dpaa2/dpaa2-
When dumping outer maps or prog_array maps, and on lookup failure,
bpftool simply skips the entry with no error message. This is because
the kernel returns non-zero when no value is found for the provided key,
which frequently happen for those maps if they have not been filled.
When such a case oc
This series makes bpftool able to create outer maps (maps of types
array-of-maps and hash-of-maps). This is done by passing the relevant
inner_map_fd, which we do through a new command-line keyword.
The first two patches also clean up the function related to dumping map
elements.
v3:
- Add a chec
There is no support for creating maps of types array-of-map or
hash-of-map in bpftool. This is because the kernel needs an inner_map_fd
to collect metadata on the inner maps to be supported by the new map,
but bpftool does not provide a way to pass this file descriptor.
Add a new optional "inner_m
The function used to dump a map entry in bpftool is a bit difficult to
follow, as a consequence to earlier refactorings. There is a variable
("num_elems") which does not appear to be necessary, and the error
handling would look cleaner if moved to its own function. Let's clean it
up. No functional
> Subject: [v2, 5/5] dpaa2-eth: support PTP Sync packet one-step timestamping
>
> This patch is to add PTP sync packet one-step timestamping support.
> Before egress, one-step timestamping enablement needs,
>
> - Enabling timestamp and FAS (Frame Annotation Status) in
> dpni buffer layout.
>
>
On Thu, Sep 10, 2020 at 10:04:24AM +0530, Anmol Karn wrote:
> Prevent hci_phy_link_complete_evt() from dereferencing 'hcon->amp_mgr'
> as NULL. Fix it by adding pointer check for it.
>
> Reported-and-tested-by: syzbot+0bef568258653cff2...@syzkaller.appspotmail.com
> Link: https://syzkaller.appspot
On Tue, 8 Sep 2020 at 21:45, Rob Herring wrote:
>
> On Sun, 06 Sep 2020 17:36:46 +0200, Krzysztof Kozlowski wrote:
> > Convert the Samsung S3FWRN5 NCI NFC controller bindings to dtschema.
> > This is conversion only so it includes properties with invalid prefixes
> > (s3fwrn5,en-gpios) which shoul
From: Ido Schimmel
Test that an upper device of netdevs with different parent IDs can be
enslaved to a bridge.
The test fails without previous commit.
Signed-off-by: Ido Schimmel
Reviewed-by: Jiri Pirko
Reviewed-by: Nikolay Aleksandrov
---
tools/testing/selftests/net/rtnetlink.sh | 47 +
From: Ido Schimmel
When a netdev is enslaved to a bridge, its parent identifier is queried.
This is done so that packets that were already forwarded in hardware
will not be forwarded again by the bridge device between netdevs
belonging to the same hardware instance.
The operation fails when the
From: Ido Schimmel
Patch #1 fixes an issue in which an upper netdev cannot be enslaved to a
bridge when it has multiple netdevs with different parent identifiers
beneath it.
Patch #2 adds a test case using two netdevsim instances.
Ido Schimmel (2):
net: Fix bridge enslavement failure
selfte
On Mon, 2020-08-03 at 07:44 +0200, Michael Grzeschik wrote:
> This series adds support for the ksz88x3 driver family to the dsa
> based ksz
> drivers. The driver is making use of the already available ksz8795
> driver and
> moves it to an generic driver for the ksz8 based chips which have
> similar
The function referred to (of_mdiobus_link_mdiodev()) is only built when
CONFIG_OF_MDIO is enabled, which is again, a DT specific thing, and would
not work in case of ACPI.
Given that it is a static function so renamed of_mdiobus_link_mdiodev()
as mdiobus_link_mdiodev() and did necessary changes, fi
For DT case, auto-probe of c45 devices with extended scanning in xgmac_mdio
works well but scanning and registration of these devices (PHY's) fails in
case of ACPI mainly because of MDIO bus "fwnode" is not set appropriately.
This patch is based on https://www.spinics.net/lists/netdev/msg662173.htm
On Thu, Sep 10, 2020 at 11:25 AM Vadym Kochan wrote:
> On Fri, Sep 04, 2020 at 10:12:07PM +0300, Andy Shevchenko wrote:
> > On Fri, Sep 4, 2020 at 7:52 PM Vadym Kochan
> > wrote:
> > > + .param = {.admin_state = admin_state}
> >
> > + white spaces? Whatever you choose, just be co
The parameter passed via DCB_ATTR_DCB_BUFFER is a struct dcbnl_buffer. The
field prio2buffer is an array of IEEE_8021Q_MAX_PRIORITIES bytes, where
each value is a number of a buffer to direct that priority's traffic to.
That value is however never validated to lie within the bounds set by
DCBX_MAX_
Hi!
> names are not suited for this, since in some situations a PHY device
> name can look like this
> d0032004.mdio-mii:01
> or even like this
> /soc/internal-regs@d000/mdio@32004/switch0@10/mdio:08
> Clearly this cannot be used as the `device` part of a LED name.
>
> Signed-off-by: Mare
Some kernels builds might inline vfs_getattr call within
fstat syscall code path, so fentry/vfs_getattr trampoline
is not called.
I'm not sure how to handle this in some generic way other
than use some other function, but that might get inlined at
some point as well.
Adding flags that indicate tr
On Wed 2020-09-09 18:25:50, Marek Behún wrote:
> This patch uses the new API for HW controlled LEDs to add support for
> probing and control of LEDs connected to an ethernet PHY chip.
>
> A PHY driver wishing to utilize this API needs to implement the methods
> in struct hw_controlled_led_ops and
Hi!
> Add nodes for the green and yellow LEDs that are connected to the
> ethernet PHY chip on Turris MOX A.
>
> Signed-off-by: Marek Behún
> ---
> .../dts/marvell/armada-3720-turris-mox.dts| 23 +++
> 1 file changed, 23 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/ma
Joe,
Please drop this chunk: it's a successive controller version number
which are all backward compatible with "fallthrough" on each case so
removing from this last one makes it inconsistent.
In sort: NACK for atmel-mci.
Best regards,
Nicolas
On 09/09/2020 at 22:06, Joe Perches wrote:
>
From: Toke Høiland-Jørgensen
In preparation for moving code around, change a bunch of references to
env->log (and the verbose() logging helper) to use bpf_log() and a direct
pointer to struct bpf_verifier_log. While we're touching the function
signature, mark the 'prog' argument to bpf_check_type
From: Sameeh Jubran
The new metrics provide granular visibility along multiple network
dimensions and enable troubleshooting and remediation of issues caused
by instances exceeding network performance allowances.
The new statistics can be queried using ethtool command.
Signed-off-by: Guy Tzalik
On Thu, Sep 10, 2020 at 05:13:03PM +0530, Vikas Singh wrote:
> The function referred to (of_mdiobus_link_mdiodev()) is only built when
> CONFIG_OF_MDIO is enabled, which is again, a DT specific thing, and would
> not work in case of ACPI.
Vikas
How are you describing the MDIO bus in ACPI? Do you
On Thu, Sep 10, 2020 at 02:23:41PM +0200, Pavel Machek wrote:
> On Wed 2020-09-09 18:25:51, Marek Behún wrote:
> > This patch adds support for controlling the LEDs connected to several
> > families of Marvell PHYs via the PHY HW LED trigger API. These families
> > are: 88E1112, 88E1121R, 88E1240, 8
Fixes the following warning when using W=1 to build kernel:
drivers/net/ethernet/smsc/smc91x.c: In function ‘smc_phy_configure’:
drivers/net/ethernet/smsc/smc91x.c:1039:6: warning: variable ‘status’ set but
not used [-Wunused-but-set-variable]
int status;
Signed-off-by: Luo Jiaxing
---
drive
From: Toke Høiland-Jørgensen
This adds a selftest for attaching an freplace program to multiple targets
simultaneously.
Signed-off-by: Toke Høiland-Jørgensen
---
.../selftests/bpf/prog_tests/fexit_bpf2bpf.c | 171
.../selftests/bpf/progs/freplace_get_constant.c|
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
This adds support for supplying a target fd and btf ID for the
raw_tracepoint_open() BPF operation, using a new bpf_raw_tracepoint_opts
structure. This can be used for attaching freplace programs to multiple
destinations.
Signed-off-by: Toke Høiland-Jørgensen
---
t
On Thu, Sep 10, 2020 at 05:22:10PM +0530, Vikas Singh wrote:
> For DT case, auto-probe of c45 devices with extended scanning in xgmac_mdio
> works well but scanning and registration of these devices (PHY's) fails in
> case of ACPI mainly because of MDIO bus "fwnode" is not set appropriately.
> This
Fixes coccicheck warning:
drivers/net/wireless/realtek/rtlwifi/rtl8723ae/rf.c:52:5-22: WARNING:
Comparison to bool
drivers/net/wireless/realtek/rtlwifi/rtl8723ae/rf.c:482:6-14: WARNING:
Comparison to bool
Signed-off-by: Zheng Bin
---
drivers/net/wireless/realtek/rtlwifi/rtl8723ae/rf.c | 4 ++-
Fixes coccicheck warning:
drivers/net/wireless/realtek/rtlwifi/rtl8723ae/phy.c:191:5-13: WARNING:
Comparison to bool
drivers/net/wireless/realtek/rtlwifi/rtl8723ae/phy.c:205:5-13: WARNING:
Comparison to bool
drivers/net/wireless/realtek/rtlwifi/rtl8723ae/phy.c:211:5-13: WARNING:
Comparison to b
Fixes coccicheck warning:
drivers/net/wireless/realtek/rtlwifi/rtl8723ae/trx.c:592:5-9: WARNING:
Comparison to bool
drivers/net/wireless/realtek/rtlwifi/rtl8723ae/trx.c:633:5-9: WARNING:
Comparison to bool
Signed-off-by: Zheng Bin
---
drivers/net/wireless/realtek/rtlwifi/rtl8723ae/trx.c | 4 +
1 - 100 of 471 matches
Mail list logo