* Re: [PATCH net] net/sched: cls_flower: Set egress_dev mark when calling into the HW driver
From: Sergei Shtylyov @ 2017-10-18 8:09 UTC (permalink / raw)
To: Or Gerlitz; +Cc: Linux Netdev List
In-Reply-To: <CAJ3xEMjWCL3kSvfenCaLYnbvmGfyS2-zig7MhVMa1+oUMCLpbA@mail.gmail.com>
Hello!
On 10/18/2017 10:14 AM, Or Gerlitz wrote:
>>> Commit 7091d8c '(net/sched: cls_flower: Add offload support using egress
>>
>> At least 12 digits are needed.
>
> Also on such a spot (e.g not on the Fixes line)?
Yes.
[...]
MBR, Sergei
^ permalink raw reply
* Re: [PATCH net] sock_diag: request _diag module only when the family or proto has been registered
From: kbuild test robot @ 2017-10-18 8:33 UTC (permalink / raw)
To: Xin Long
Cc: kbuild-all, network dev, davem, Marcelo Ricardo Leitner,
Sabrina Dubroca
In-Reply-To: <69c0824505548e733f2f7be3ff288f2c4e461afa.1508217236.git.lucien.xin@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 731 bytes --]
Hi Xin,
[auto build test ERROR on net/master]
url: https://github.com/0day-ci/linux/commits/Xin-Long/sock_diag-request-_diag-module-only-when-the-family-or-proto-has-been-registered/20171018-152434
config: i386-randconfig-a0-201742 (attached as .config)
compiler: gcc-5 (Debian 5.4.1-2) 5.4.1 20160904
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
net/core/sock_diag.o: In function `sock_diag_request_module':
>> sock_diag.c:(.text+0x5a5): undefined reference to `inet_protos'
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 24738 bytes --]
^ permalink raw reply
* [PATCH net-next] net: sched: cls_u32: use hash_ptr() for tc_u_hash
From: Arnd Bergmann @ 2017-10-18 8:33 UTC (permalink / raw)
To: Jamal Hadi Salim, Cong Wang, Jiri Pirko, David S. Miller
Cc: Arnd Bergmann, netdev, linux-kernel
After the change to the tp hash, we now get a build warning
on 32-bit architectures:
net/sched/cls_u32.c: In function 'tc_u_hash':
net/sched/cls_u32.c:338:17: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
return hash_64((u64) tp->chain->block, U32_HASH_SHIFT);
Using hash_ptr() instead of hash_64() lets us drop the cast
and fixes the warning while still resulting in the same hash
value.
Fixes: 7fa9d974f3c2 ("net: sched: cls_u32: use block instead of q in tc_u_common")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
net/sched/cls_u32.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/sched/cls_u32.c b/net/sched/cls_u32.c
index b6d46065f661..49d96b45a8ce 100644
--- a/net/sched/cls_u32.c
+++ b/net/sched/cls_u32.c
@@ -335,7 +335,7 @@ static struct hlist_head *tc_u_common_hash;
static unsigned int tc_u_hash(const struct tcf_proto *tp)
{
- return hash_64((u64) tp->chain->block, U32_HASH_SHIFT);
+ return hash_ptr(tp->chain->block, U32_HASH_SHIFT);
}
static struct tc_u_common *tc_u_common_find(const struct tcf_proto *tp)
--
2.9.0
^ permalink raw reply related
* Re: [net-next V8 PATCH 1/5] bpf: introduce new bpf cpu map type BPF_MAP_TYPE_CPUMAP
From: Jesper Dangaard Brouer @ 2017-10-18 8:38 UTC (permalink / raw)
To: Yann Ylavic
Cc: Linux Kernel Network Developers, jakub.kicinski,
Michael S. Tsirkin, pavel.odintsov, Jason Wang, mchan,
John Fastabend, peter.waskiewicz.jr, ast, Daniel Borkmann,
Alexei Starovoitov, Andy Gospodarek, brouer
In-Reply-To: <CAKQ1sVMH-h36UWwuKhcVC=ZN+L=y3y3apayye_yKYKXTbqMGTQ@mail.gmail.com>
On Mon, 16 Oct 2017 12:19:28 +0200 Jesper Dangaard Brouer <brouer@redhat.com> wrote:
> +static struct bpf_map *cpu_map_alloc(union bpf_attr *attr)
> +{
> + struct bpf_cpu_map *cmap;
> + int err = -ENOMEM;
Notice err is set to -ENOMEM.
> + u64 cost;
> + int ret;
> +
> + if (!capable(CAP_SYS_ADMIN))
> + return ERR_PTR(-EPERM);
> +
> + /* check sanity of attributes */
> + if (attr->max_entries == 0 || attr->key_size != 4 ||
> + attr->value_size != 4 || attr->map_flags & ~BPF_F_NUMA_NODE)
> + return ERR_PTR(-EINVAL);
> +
> + cmap = kzalloc(sizeof(*cmap), GFP_USER);
> + if (!cmap)
> + return ERR_PTR(-ENOMEM);
> +
> + /* mandatory map attributes */
> + cmap->map.map_type = attr->map_type;
> + cmap->map.key_size = attr->key_size;
> + cmap->map.value_size = attr->value_size;
> + cmap->map.max_entries = attr->max_entries;
> + cmap->map.map_flags = attr->map_flags;
> + cmap->map.numa_node = bpf_map_attr_numa_node(attr);
> +
> + /* Pre-limit array size based on NR_CPUS, not final CPU check */
> + if (cmap->map.max_entries > NR_CPUS) {
> + err = -E2BIG;
> + goto free_cmap;
> + }
> +
> + /* make sure page count doesn't overflow */
> + cost = (u64) cmap->map.max_entries * sizeof(struct bpf_cpu_map_entry *);
> + cost += cpu_map_bitmap_size(attr) * num_possible_cpus();
> + if (cost >= U32_MAX - PAGE_SIZE)
> + goto free_cmap;
> + cmap->map.pages = round_up(cost, PAGE_SIZE) >> PAGE_SHIFT;
> +
> + /* Notice returns -EPERM on if map size is larger than memlock limit */
[... continued below ...]
On Wed, 18 Oct 2017 09:45:59 +0200 Yann Ylavic <ylavic.dev@gmail.com> wrote:
> On Mon, Oct 16, 2017 at 12:19 PM, Jesper Dangaard Brouer
> <brouer@redhat.com> wrote:
> > +
> > + /* Notice returns -EPERM on if map size is larger than memlock limit */
> > + ret = bpf_map_precharge_memlock(cmap->map.pages);
> > + if (ret) {
> > + err = ret;
> > + goto free_cmap;
> > + }
> > +
> > + /* A per cpu bitfield with a bit per possible CPU in map */
> > + cmap->flush_needed = __alloc_percpu(cpu_map_bitmap_size(attr),
> > + __alignof__(unsigned long));
> > + if (!cmap->flush_needed)
> > + goto free_cmap;
> > +
> > + /* Alloc array for possible remote "destination" CPUs */
> > + cmap->cpu_map = bpf_map_area_alloc(cmap->map.max_entries *
> > + sizeof(struct bpf_cpu_map_entry *),
> > + cmap->map.numa_node);
> > + if (!cmap->cpu_map)
>
> ret = -ENOMEM; ?
Did you notice that "err" already is = -ENOMEM at this point?
> > + goto free_percpu;
> > +
> > + return &cmap->map;
> > +free_percpu:
> > + free_percpu(cmap->flush_needed);
> > +free_cmap:
> > + kfree(cmap);
> > + return ERR_PTR(err);
> > +}
>
>
> Regards,
> Yann.
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* Re: [PATCH net-next] net: sched: cls_u32: use hash_ptr() for tc_u_hash
From: Jiri Pirko @ 2017-10-18 8:39 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Jamal Hadi Salim, Cong Wang, David S. Miller, netdev,
linux-kernel
In-Reply-To: <20171018083403.3236142-1-arnd@arndb.de>
Wed, Oct 18, 2017 at 10:33:37AM CEST, arnd@arndb.de wrote:
>After the change to the tp hash, we now get a build warning
>on 32-bit architectures:
>
>net/sched/cls_u32.c: In function 'tc_u_hash':
>net/sched/cls_u32.c:338:17: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
> return hash_64((u64) tp->chain->block, U32_HASH_SHIFT);
>
>Using hash_ptr() instead of hash_64() lets us drop the cast
>and fixes the warning while still resulting in the same hash
>value.
>
>Fixes: 7fa9d974f3c2 ("net: sched: cls_u32: use block instead of q in tc_u_common")
>Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Jiri Pirko <jiri@mellanox.com>
Thanks.
^ permalink raw reply
* Re: [PATCH net] sock_diag: request _diag module only when the family or proto has been registered
From: kbuild test robot @ 2017-10-18 9:38 UTC (permalink / raw)
To: Xin Long
Cc: kbuild-all, network dev, davem, Marcelo Ricardo Leitner,
Sabrina Dubroca
In-Reply-To: <69c0824505548e733f2f7be3ff288f2c4e461afa.1508217236.git.lucien.xin@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 725 bytes --]
Hi Xin,
[auto build test ERROR on net/master]
url: https://github.com/0day-ci/linux/commits/Xin-Long/sock_diag-request-_diag-module-only-when-the-family-or-proto-has-been-registered/20171018-152434
config: x86_64-randconfig-a0-10181611 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
net/core/sock_diag.o: In function `sock_diag_request_module':
>> (.text+0x685): undefined reference to `inet_protos'
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 25418 bytes --]
^ permalink raw reply
* pull-request: wireless-drivers-next 2017-10-18
From: Kalle Valo @ 2017-10-18 9:42 UTC (permalink / raw)
To: David Miller; +Cc: linux-wireless, netdev, linux-kernel
Hi Dave,
this for 4.15 stream to net-next tree. Please let me know if there are
any problems.
Kalle
The following changes since commit 3e747fa18202896b5be66b88478352d5880fb8eb:
Merge ath-current from ath.git (2017-09-25 10:06:12 +0300)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git tags/wireless-drivers-next-for-davem-2017-10-18
for you to fetch changes up to 66cc044249603e12e1dbba347f03bdbc9f171fdf:
bcma: use bcma_debug and pr_cont in MIPS driver (2017-10-17 17:22:07 +0300)
----------------------------------------------------------------
wireless-drivers-next patches for 4.15
The first pull request for 4.15, unusually late this time but still
relatively small. Also includes merge from wireless-drivers to fix
conflicts in iwlwifi.
Major changes:
rsi
* add P2P mode support
* sdio suspend and resume support
iwlwifi
* A fix and an addition for PCI devices for the A000 family
* Dump PCI registers when an error occurs, to make it easier to debug
rtlwifi
* add support for 64 bit DMA, enabled with a module parameter
* add module parameter to enable ASPM
----------------------------------------------------------------
Adam Borowski (1):
rtl8xxxu: Don't printk raw binary if serial number is not burned in.
Allen Pais (1):
brcmfmac: use setup_timer() helper
Andrey Konovalov (1):
p54: don't unregister leds when they are not initialized
Arnd Bergmann (2):
brcmsmac: make some local variables 'static const' to reduce stack size
rsi: fix integer overflow warning
Chaya Rachel Ivgi (2):
iwlwifi: nvm: set the correct offsets to 3168 series
iwlwifi: remove redundant reading from NVM file
Christoph Böhmwalder (1):
iwlwifi: fix minor code style issues
Christos Gkekas (1):
rtlwifi: Remove unused cur_rfstate variables
Colin Ian King (8):
rsi: fix a dereference on adapter before it has been null checked
b43: fix unitialized reads of ret by initializing the array to zero
b43legacy: fix unitialized reads of ret by initializing the array to zero
mwifiex: make const arrays static to shink object code size
brcmsmac: make const array ucode_ofdm_rates static, reduces object code size
mwifiex: make const array tos_to_ac static, reduces object code size
iwlegacy: make const array static to shink object code size
b43: make const arrays static, reduces object code size
Dan Carpenter (1):
rtlwifi: silence underflow warning
David Spinadel (1):
iwlwifi: mvm: Add new quota command API
Douglas Anderson (2):
mwifiex: kill useless list_empty checks
mwifiex: minor cleanups w/ sta_list_spinlock in cfg80211.c
Emmanuel Grumbach (3):
iwlwifi: mvm: remove support for Link Quality Measurements
iwlwifi: mvm: support firmware debug trigger on frame reorder timeout
iwlwifi: mvm: don't send identical PHY_CTXT_CMD
Ganapathi Bhat (4):
mwifiex: notify cfg80211 about scan abort
mwifiex: check for mfg_mode in add_virtual_intf
mwifiex: avoid storing random_mac in private
mwifiex: use get_random_mask_addr() helper
Golan Ben Ami (1):
iwlwifi: stop dbgc recording before stopping DMA
Himanshu Jha (2):
mwifiex: remove unnecessary call to memset
mwifiex: Use put_unaligned_le32
Igor Mitsyanko (17):
qtnfmac: convert channel width from bitfiled to simple enum
qtnfmac: make "Channel change" event report full channel info
qtnfmac: retrieve current channel info from EP
qtnfmac: do not cache channel info from "connect" command
qtnfmac: let wifi card handle channel switch request to the same chan
qtnfmac: pass VIF info to SendChannel command
qtnfmac: do not cache CSA chandef info
qtnfmac: remove unused mac::status field
qtnfmac: do not report channel changes until wiphy is registered
qtnfmac: do not cache AP settings in driver structures
qtnfmac: pass all AP settings to wireless card for processing
qtnfmac: pass channel definition to WiFi card on START_AP command
qtnfmac: get rid of QTNF_STATE_AP_CONFIG
qtnfmac: get rid of QTNF_STATE_AP_START flag
qtnfmac: do not cache BSS state in per-VIF structure
qtnfmac: make encryption info a part of CONNECT command.
qtnfmac: do not cache current channel info in driver's state
Ilan Peer (1):
iwlwifi: Add few debug prints to the WRT dump flow
Johannes Berg (4):
iwlwifi: nvm-parse: unify channel flags printing
iwlwifi: fw: api: remove excess enum value documentation
iwlwifi: fix indentation in a000 family configuration
iwlwifi: mvm: warn on invalid statistics size
Kalle Valo (3):
Merge tag 'iwlwifi-for-kalle-2017-10-06' of git://git.kernel.org/.../iwlwifi/iwlwifi-fixes
Merge tag 'iwlwifi-next-for-kalle-2017-10-06-2' of git://git.kernel.org/.../iwlwifi/iwlwifi-next
Merge git://git.kernel.org/.../kvalo/wireless-drivers.git
Karthik Ananthapadmanabha (1):
mwifiex: Random MAC address during scanning
Karun Eagalapati (1):
rsi: sdio suspend and resume support
Kevin Cernekee (3):
brcmfmac: Add check for short event packets
brcmfmac: Avoid possible out-of-bounds read
brcmfmac: Delete redundant length check
Larry Finger (4):
rtlwifi: btcoexist: 23b 1ant: fix duplicated code for different branches
rtlwifi: rtl8192ee: Fix memory leak when loading firmware
rtlwifi: rtl8821ae: Fix connection lost problem
rtlwifi: Fix typo in if ... else if ... else construct
Liad Kaufman (1):
iwlwifi: mvm: add dbgfs entry for fw info
Luca Coelho (12):
iwlwifi: mvm: return -ENODATA when reading the temperature with the FW down
iwlwifi: trans: move ref/unref code to the common part of the transport
iwlwifi: acpi: add common code to read from ACPI
iwlwifi: acpi: move ACPI method definitions to acpi.h
iwlwifi: acpi: move ACPI-related definitions to acpi.h
iwlwifi: acpi: generalize iwl_mvm_sar_find_wifi_pkg()
iwlwifi: acpi: use iwl_acpi_get_wifi_pkg when reading reading SPLC
iwlwifi: acpi: make iwl_get_bios_mcc() use the common acpi functions
iwlwifi: acpi: remove a couple of unnecessary ifdefs
iwlwifi: acpi: move function to get mcc into acpi code
iwlwifi: acpi: move code that reads SPLC to acpi
iwlwifi: remove dflt_pwr_limit from the transport
Mordechay Goodstein (1):
iwlwifi: mvm: add marker cmd response struct.
Oren Givon (2):
iwlwifi: fix wrong struct for a000 device
iwlwifi: add a new a000 device
Pavani Muthyala (1):
rsi: add version information
Ping-Ke Shih (10):
rtlwifi: Fix MAX MPDU of VHT capability
rtlwifi: Remove redundant semicolon in wifi.h.
rtlwifi: rtl8192ee: Make driver support 64bits DMA.
rtlwifi: Implement rtl_get_tx_hw_rate to yield correct hw_rate
rtlwifi: Add rtl_get_hal_edca_param() to generate register's format of EDCA.
rtlwifi: Add TX/RX throughput statistics in period
rtlwifi: Add RSSI and RF type to wifi.h for phydm
rtlwifi: Remove BAND_NUM and related fields
rtlwifi: Add bw_update parameter for RA mask update.
rtlwifi: Add module parameter ASPM
Prameela Rani Garnepudi (8):
rsi: add p2p support parameters to mac80211
rsi: add/remove interface enhancements for p2p
rsi: add support for p2p listen
rsi: handle peer connection and disconnection in p2p mode
rsi: tx and rx path enhancements for p2p mode
rsi: disallow power save config when AP vap running
rsi: aggregation changes for p2p mode
rsi: miscellaneous changes for p2p mode
Rafał Miłecki (1):
bcma: use bcma_debug and pr_cont in MIPS driver
Rajat Jain (1):
iwlwifi: pcie: dump registers when HW becomes inaccessible
Randy Dunlap (1):
bcma: keep *config menu together
Rohit Fule (1):
mwifiex: double the size of chan_stats array in adapter
Sara Sharon (1):
iwlwifi: mvm: change warning to warn_once()
Shahar S Matityahu (1):
iwlwifi: pcie: dynamic Tx command queue size
Shaul Triebitz (1):
iwlwifi: mvm: do not print security error in monitor mode
drivers/bcma/Kconfig | 18 +-
drivers/bcma/driver_mips.c | 7 +-
drivers/net/wireless/broadcom/b43/phy_g.c | 2 +-
drivers/net/wireless/broadcom/b43/phy_ht.c | 6 +-
drivers/net/wireless/broadcom/b43legacy/radio.c | 2 +-
.../wireless/broadcom/brcm80211/brcmfmac/fweh.c | 8 +-
.../net/wireless/broadcom/brcm80211/brcmfmac/p2p.c | 3 +-
.../wireless/broadcom/brcm80211/brcmfmac/sdio.c | 6 +-
.../broadcom/brcm80211/brcmsmac/phy/phy_cmn.c | 2 +-
.../broadcom/brcm80211/brcmsmac/phy/phy_n.c | 197 +++++----
drivers/net/wireless/intel/iwlegacy/4965-mac.c | 2 +-
drivers/net/wireless/intel/iwlwifi/Makefile | 1 +
drivers/net/wireless/intel/iwlwifi/cfg/7000.c | 1 +
drivers/net/wireless/intel/iwlwifi/cfg/8000.c | 2 +-
drivers/net/wireless/intel/iwlwifi/cfg/9000.c | 2 +-
drivers/net/wireless/intel/iwlwifi/cfg/a000.c | 105 ++---
drivers/net/wireless/intel/iwlwifi/fw/acpi.c | 210 ++++++++++
drivers/net/wireless/intel/iwlwifi/fw/acpi.h | 138 +++++++
.../net/wireless/intel/iwlwifi/fw/api/binding.h | 41 +-
.../net/wireless/intel/iwlwifi/fw/api/commands.h | 1 +
drivers/net/wireless/intel/iwlwifi/fw/api/debug.h | 9 +
.../net/wireless/intel/iwlwifi/fw/api/mac-cfg.h | 67 ----
.../net/wireless/intel/iwlwifi/fw/api/nvm-reg.h | 2 +
drivers/net/wireless/intel/iwlwifi/fw/api/power.h | 3 +-
drivers/net/wireless/intel/iwlwifi/fw/api/sta.h | 4 -
drivers/net/wireless/intel/iwlwifi/fw/dbg.c | 22 +-
drivers/net/wireless/intel/iwlwifi/fw/dbg.h | 15 +
drivers/net/wireless/intel/iwlwifi/fw/file.h | 3 +
drivers/net/wireless/intel/iwlwifi/iwl-config.h | 19 +-
drivers/net/wireless/intel/iwlwifi/iwl-debug.h | 1 +
drivers/net/wireless/intel/iwlwifi/iwl-drv.c | 7 +-
drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c | 228 +++--------
drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.h | 17 -
drivers/net/wireless/intel/iwlwifi/iwl-trans.c | 16 +
drivers/net/wireless/intel/iwlwifi/iwl-trans.h | 16 +-
drivers/net/wireless/intel/iwlwifi/mvm/d3.c | 16 +-
.../net/wireless/intel/iwlwifi/mvm/debugfs-vif.c | 76 ----
drivers/net/wireless/intel/iwlwifi/mvm/debugfs.c | 32 ++
drivers/net/wireless/intel/iwlwifi/mvm/fw.c | 207 ++--------
drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c | 59 ++-
drivers/net/wireless/intel/iwlwifi/mvm/mvm.h | 67 ++--
drivers/net/wireless/intel/iwlwifi/mvm/nvm.c | 24 +-
drivers/net/wireless/intel/iwlwifi/mvm/ops.c | 22 +-
drivers/net/wireless/intel/iwlwifi/mvm/phy-ctxt.c | 1 +
drivers/net/wireless/intel/iwlwifi/mvm/quota.c | 59 +--
drivers/net/wireless/intel/iwlwifi/mvm/rx.c | 11 +-
drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c | 12 +-
drivers/net/wireless/intel/iwlwifi/mvm/sta.c | 1 +
drivers/net/wireless/intel/iwlwifi/mvm/tt.c | 2 +-
drivers/net/wireless/intel/iwlwifi/mvm/utils.c | 96 ++---
.../net/wireless/intel/iwlwifi/pcie/ctxt-info.c | 2 +-
drivers/net/wireless/intel/iwlwifi/pcie/drv.c | 100 +----
drivers/net/wireless/intel/iwlwifi/pcie/internal.h | 4 +
drivers/net/wireless/intel/iwlwifi/pcie/trans.c | 89 ++++
drivers/net/wireless/intel/iwlwifi/pcie/tx-gen2.c | 8 +-
drivers/net/wireless/intel/iwlwifi/pcie/tx.c | 23 +-
drivers/net/wireless/intersil/p54/main.c | 7 +-
drivers/net/wireless/marvell/mwifiex/11n.c | 9 -
.../net/wireless/marvell/mwifiex/11n_rxreorder.c | 6 -
drivers/net/wireless/marvell/mwifiex/cfg80211.c | 76 ++--
drivers/net/wireless/marvell/mwifiex/cmdevt.c | 10 +-
drivers/net/wireless/marvell/mwifiex/fw.h | 1 +
drivers/net/wireless/marvell/mwifiex/init.c | 4 -
drivers/net/wireless/marvell/mwifiex/main.h | 1 -
drivers/net/wireless/marvell/mwifiex/scan.c | 5 +-
drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c | 6 +-
drivers/net/wireless/marvell/mwifiex/sta_event.c | 6 +-
drivers/net/wireless/marvell/mwifiex/tdls.c | 7 -
drivers/net/wireless/marvell/mwifiex/wmm.c | 3 +-
drivers/net/wireless/quantenna/qtnfmac/cfg80211.c | 173 ++------
drivers/net/wireless/quantenna/qtnfmac/commands.c | 215 ++++++----
drivers/net/wireless/quantenna/qtnfmac/commands.h | 6 +-
drivers/net/wireless/quantenna/qtnfmac/core.h | 30 +-
drivers/net/wireless/quantenna/qtnfmac/event.c | 48 +--
drivers/net/wireless/quantenna/qtnfmac/qlink.h | 137 +++++--
.../net/wireless/quantenna/qtnfmac/qlink_util.c | 113 +++++-
.../net/wireless/quantenna/qtnfmac/qlink_util.h | 7 +
.../net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192e.c | 5 +-
drivers/net/wireless/realtek/rtlwifi/base.c | 104 ++++-
drivers/net/wireless/realtek/rtlwifi/base.h | 4 +
.../realtek/rtlwifi/btcoexist/halbtc8723b1ant.c | 13 +-
drivers/net/wireless/realtek/rtlwifi/core.c | 8 +-
drivers/net/wireless/realtek/rtlwifi/pci.c | 49 ++-
drivers/net/wireless/realtek/rtlwifi/pci.h | 10 +-
.../net/wireless/realtek/rtlwifi/rtl8188ee/dm.c | 3 +-
.../net/wireless/realtek/rtlwifi/rtl8188ee/hw.c | 11 +-
.../net/wireless/realtek/rtlwifi/rtl8188ee/hw.h | 3 +-
.../net/wireless/realtek/rtlwifi/rtl8188ee/sw.c | 6 +-
.../net/wireless/realtek/rtlwifi/rtl8188ee/trx.c | 5 +-
.../net/wireless/realtek/rtlwifi/rtl8188ee/trx.h | 3 +-
.../net/wireless/realtek/rtlwifi/rtl8192ce/hw.c | 6 +-
.../net/wireless/realtek/rtlwifi/rtl8192ce/hw.h | 5 +-
.../net/wireless/realtek/rtlwifi/rtl8192ce/sw.c | 6 +-
.../net/wireless/realtek/rtlwifi/rtl8192ce/trx.c | 5 +-
.../net/wireless/realtek/rtlwifi/rtl8192ce/trx.h | 3 +-
.../net/wireless/realtek/rtlwifi/rtl8192cu/hw.c | 6 +-
.../net/wireless/realtek/rtlwifi/rtl8192cu/hw.h | 2 +-
.../net/wireless/realtek/rtlwifi/rtl8192de/fw.c | 2 +-
.../net/wireless/realtek/rtlwifi/rtl8192de/hw.c | 6 +-
.../net/wireless/realtek/rtlwifi/rtl8192de/hw.h | 3 +-
.../net/wireless/realtek/rtlwifi/rtl8192de/sw.c | 6 +-
.../net/wireless/realtek/rtlwifi/rtl8192de/trx.c | 3 +-
.../net/wireless/realtek/rtlwifi/rtl8192de/trx.h | 3 +-
.../net/wireless/realtek/rtlwifi/rtl8192ee/dm.c | 3 +-
.../net/wireless/realtek/rtlwifi/rtl8192ee/fw.c | 6 +-
.../net/wireless/realtek/rtlwifi/rtl8192ee/hw.c | 40 +-
.../net/wireless/realtek/rtlwifi/rtl8192ee/hw.h | 3 +-
.../net/wireless/realtek/rtlwifi/rtl8192ee/sw.c | 9 +-
.../net/wireless/realtek/rtlwifi/rtl8192ee/trx.c | 49 ++-
.../net/wireless/realtek/rtlwifi/rtl8192ee/trx.h | 140 ++-----
.../net/wireless/realtek/rtlwifi/rtl8192se/dm.c | 3 +-
.../net/wireless/realtek/rtlwifi/rtl8192se/hw.c | 6 +-
.../net/wireless/realtek/rtlwifi/rtl8192se/hw.h | 2 +-
.../net/wireless/realtek/rtlwifi/rtl8192se/sw.c | 8 +-
.../net/wireless/realtek/rtlwifi/rtl8192se/trx.c | 3 +-
.../net/wireless/realtek/rtlwifi/rtl8192se/trx.h | 3 +-
.../net/wireless/realtek/rtlwifi/rtl8723ae/hw.c | 11 +-
.../net/wireless/realtek/rtlwifi/rtl8723ae/hw.h | 3 +-
.../net/wireless/realtek/rtlwifi/rtl8723ae/sw.c | 6 +-
.../net/wireless/realtek/rtlwifi/rtl8723ae/trx.c | 5 +-
.../net/wireless/realtek/rtlwifi/rtl8723ae/trx.h | 3 +-
.../net/wireless/realtek/rtlwifi/rtl8723be/dm.c | 3 +-
.../net/wireless/realtek/rtlwifi/rtl8723be/hw.c | 13 +-
.../net/wireless/realtek/rtlwifi/rtl8723be/hw.h | 2 +-
.../net/wireless/realtek/rtlwifi/rtl8723be/sw.c | 6 +-
.../net/wireless/realtek/rtlwifi/rtl8723be/trx.c | 5 +-
.../net/wireless/realtek/rtlwifi/rtl8723be/trx.h | 3 +-
.../realtek/rtlwifi/rtl8723com/fw_common.c | 3 +-
.../net/wireless/realtek/rtlwifi/rtl8821ae/dm.c | 2 +-
.../net/wireless/realtek/rtlwifi/rtl8821ae/hw.c | 15 +-
.../net/wireless/realtek/rtlwifi/rtl8821ae/hw.h | 2 +-
.../net/wireless/realtek/rtlwifi/rtl8821ae/sw.c | 6 +-
.../net/wireless/realtek/rtlwifi/rtl8821ae/trx.c | 5 +-
.../net/wireless/realtek/rtlwifi/rtl8821ae/trx.h | 3 +-
drivers/net/wireless/realtek/rtlwifi/wifi.h | 60 +--
drivers/net/wireless/rsi/rsi_91x_core.c | 33 +-
drivers/net/wireless/rsi/rsi_91x_debugfs.c | 19 +-
drivers/net/wireless/rsi/rsi_91x_hal.c | 86 ++--
drivers/net/wireless/rsi/rsi_91x_mac80211.c | 446 ++++++++++++++++-----
drivers/net/wireless/rsi/rsi_91x_main.c | 34 +-
drivers/net/wireless/rsi/rsi_91x_mgmt.c | 46 ++-
drivers/net/wireless/rsi/rsi_91x_ps.c | 15 +-
drivers/net/wireless/rsi/rsi_91x_sdio.c | 128 +++++-
drivers/net/wireless/rsi/rsi_91x_usb.c | 4 +-
drivers/net/wireless/rsi/rsi_common.h | 4 +-
drivers/net/wireless/rsi/rsi_hal.h | 6 +-
drivers/net/wireless/rsi/rsi_main.h | 24 +-
drivers/net/wireless/rsi/rsi_mgmt.h | 21 +-
drivers/net/wireless/rsi/rsi_ps.h | 7 +-
drivers/net/wireless/rsi/rsi_sdio.h | 2 +
150 files changed, 2639 insertions(+), 1911 deletions(-)
create mode 100644 drivers/net/wireless/intel/iwlwifi/fw/acpi.c
create mode 100644 drivers/net/wireless/intel/iwlwifi/fw/acpi.h
^ permalink raw reply
* Re: [RFC] sctp: suspicious rcu_read_lock() in sctp_packet_config()
From: Marcelo Ricardo Leitner @ 2017-10-18 10:01 UTC (permalink / raw)
To: Xin Long
Cc: Eric Dumazet, Eric Dumazet, Vlad Yasevich, Neil Horman, netdev,
Wei Wang, linux-sctp
In-Reply-To: <CADvbK_d70=HmQ6Dk6rh92tF0DWxKK-WZ7uyXwybLHtcigwB=6A@mail.gmail.com>
On Wed, Oct 18, 2017 at 01:33:46AM +0800, Xin Long wrote:
> On Wed, Oct 18, 2017 at 1:27 AM, Marcelo Ricardo Leitner
> <marcelo.leitner@gmail.com> wrote:
> > On Tue, Oct 17, 2017 at 10:20:58AM -0700, Eric Dumazet wrote:
> >> On Tue, Oct 17, 2017 at 10:01 AM, Marcelo Ricardo Leitner
> >> <marcelo.leitner@gmail.com> wrote:
> >> > On Tue, Oct 17, 2017 at 09:44:10AM -0700, Eric Dumazet wrote:
> >> >> On Tue, Oct 17, 2017 at 9:28 AM, Marcelo Ricardo Leitner
> >> >> <marcelo.leitner@gmail.com> wrote:
> >> >> > On Tue, Oct 17, 2017 at 11:31:30PM +0800, Xin Long wrote:
> >> >> >> On Tue, Oct 17, 2017 at 9:45 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> >> >> >> > SCTP experts.
> >> >> >> >
> >> >> >> > syszkaller reported a few crashes in sctp_packet_config() with invalid
> >> >> >> > access to a deleted dst.
> >> >> >> >
> >> >> >> > The rcu_read_lock() in sctp_packet_config() is suspect.
> >> >> >> >
> >> >> >> > It does not protect anything at the moment.
> >> >> >> >
> >> >> >> > If we expect tp->dst to be manipulated/changed by another cpu/thread,
> >> >> >> > then we need proper rcu protection.
> >> >> >> >
> >> >> >> > Following patch to show what would be a minimal change (but obviously
> >> >> >> > bigger changes are needed, like sctp_transport_pmtu_check() and
> >> >> >> > sctp_transport_dst_check(), and proper sparse annotations)
> >> >> >> will check all places accessing tp->dst in sctp.
> >> >> >
> >> >> > I checked some and sctp_transport_dst_check() should be fine because
> >> >> > by then we are holding a reference on dst. Same goes to
> >> >> > sctp_transport_pmtu_check().
> >> >>
> >> >> Really ?
> >> >>
> >> >
> >> > Yes,
> >> >
> >> >> What about sctp_v4_err() -> sctp_icmp_redirect() -> sctp_transport_dst_check()
> >> >>
> >> >> It seems quite possible that the BH handler can access it, while
> >> >> socket is owned by user.
> >> >
> >> > hidden here:
> >> > sctp_v4_err() {
> >> > ...
> >> > sk = sctp_err_lookup(net, AF_INET, skb, sctp_hdr(skb), &asoc,
> >> > &transport);
> >> > ...
> >> > out_unlock:
> >> > sctp_err_finish(sk, transport);
> >> > }
> >> >
> >> > sctp_err_lookup() {
> >> > ...
> >> > bh_lock_sock(sk);
> >> >
> >> > /* If too many ICMPs get dropped on busy
> >> > * servers this needs to be solved differently.
> >> > */
> >> > if (sock_owned_by_user(sk)) [A]
> >> > __NET_INC_STATS(net, LINUX_MIB_LOCKDROPPEDICMPS);
> >> >
> >> > *app = asoc;
> >> > *tpp = transport;
> >> > return sk;
> >> > ...
> >> > }
> >> >
> >> > Though that if() on [A] should be bailing out without returning
> >> > nothing. That's a bug. More like:
> >> >
> >> > if (sock_owned_by_user(sk)) {
> >> > __NET_INC_STATS(net, LINUX_MIB_LOCKDROPPEDICMPS);
> >> > goto out;
> >> > }
> >> >
> >>
> >> So why sctp_v4_err() is doing this test ?
> >>
> >> if (!sock_owned_by_user(sk) && inet->recverr) {
> >>
> >> It looks like socket can be owned by the user, and [A] check only
> >> increments an SNMP counter,
> >> that wont help to solve the tp->dst use after free.
> >
> > Hah, missed that. Though the semantics on that counter still looks
> > confusing. It may be incremented when we actually handled the icmp.
> > The other icmp handling in there will postpone in case the socket is
> > locked by the user, and so will the timer callbacks too.
> Maybe that check should be done in sctp_icmp_redirect(), as
> in sctp_icmp_frag_needed(), as well as in tcp_v4_err().
>
> @@ -421,7 +421,7 @@ void sctp_icmp_redirect(struct sock *sk, struct
> sctp_transport *t,
> {
> struct dst_entry *dst;
>
> - if (!t)
> + if (sock_owned_by_user(sk) || !t)
> return;
Looks like it.
^ permalink raw reply
* Re: [PATCH] mac80211: use constant time comparison with keys
From: Johannes Berg @ 2017-10-18 10:17 UTC (permalink / raw)
To: Jason A. Donenfeld, David Miller, netdev, linux-wireless
In-Reply-To: <20171017183207.23124-1-Jason@zx2c4.com>
On Tue, 2017-10-17 at 20:32 +0200, Jason A. Donenfeld wrote:
> Otherwise we risk leaking information via timing side channel.
>
Applied.
johannes
^ permalink raw reply
* Re: [PATCH net-next v2 1/2] dt-bindings: net: add DT bindings for Socionext UniPhier AVE
From: Kunihiko Hayashi @ 2017-10-18 10:23 UTC (permalink / raw)
To: Masahiro Yamada
Cc: netdev, Andrew Lunn, Florian Fainelli, Rob Herring, Mark Rutland,
linux-arm-kernel, Linux Kernel Mailing List, devicetree,
Masami Hiramatsu, Jassi Brar
In-Reply-To: <CAK7LNATkHsbr4cOh_F6u0Fznui3BFXfWJXgKwCk0EZANSmk0pg@mail.gmail.com>
On Sat, 14 Oct 2017 01:41:12 +0900 <yamada.masahiro@socionext.com> wrote:
> 2017-10-13 9:35 GMT+09:00 Kunihiko Hayashi <hayashi.kunihiko@socionext.com>:
> > DT bindings for the AVE ethernet controller found on Socionext's
> > UniPhier platforms.
> >
> > Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
> > Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
> > ---
> > .../bindings/net/socionext,uniphier-ave4.txt | 53 ++++++++++++++++++++++
> > 1 file changed, 53 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/net/socionext,uniphier-ave4.txt
> >
> > diff --git a/Documentation/devicetree/bindings/net/socionext,uniphier-ave4.txt b/Documentation/devicetree/bindings/net/socionext,uniphier-ave4.txt
> > new file mode 100644
> > index 0000000..25f4d92
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/net/socionext,uniphier-ave4.txt
> > @@ -0,0 +1,53 @@
> > +* Socionext AVE ethernet controller
> > +
> > +This describes the devicetree bindings for AVE ethernet controller
> > +implemented on Socionext UniPhier SoCs.
> > +
> > +Required properties:
> > + - compatible: Should be
> > + - "socionext,uniphier-pro4-ave4" : for Pro4 SoC
> > + - "socionext,uniphier-pxs2-ave4" : for PXs2 SoC
> > + - "socionext,uniphier-ld20-ave4" : for LD20 SoC
> > + - "socionext,uniphier-ld11-ave4" : for LD11 SoC
>
> Nit. LD11, LD20, in this order please.
I'll fix it. And also the SoC-dependent structures of the driver.
> > + - reg: Address where registers are mapped and size of region.
> > + - interrupts: Should contain the MAC interrupt.
> > + - phy-mode: See ethernet.txt in the same directory. Allow to choose
> > + "rgmii", "rmii", or "mii" according to the PHY.
> > + - pinctrl-names: List of assigned state names, see pinctrl
> > + binding documentation.
> > + - pinctrl-0: List of phandles to configure the GPIO pin,
>
>
> configure the GPIO pin?
>
> git-grep found this phrase.
>
>
> $ git grep "List of phandles to configure the GPIO"
> Documentation/devicetree/bindings/net/microchip,enc28j60.txt:-
> pinctrl-0: List of phandles to configure the GPIO pin used as
> interrupt line,
>
>
>
>
>
> > + see pinctrl binding documentation. Choose this appropriately
> > + according to phy-mode.
> > + - <&pinctrl_ether_rgmii> if phy-mode is "rgmii".
> > + - <&pinctrl_ether_rmii> if phy-mode is "rmii".
> > + - <&pinctrl_ether_mii> if phy-mode is "mii".
>
> pinctrl_ether_rgmii is just a label
> you just happened to write in your DT file.
>
> This information is totally unrelated to hardware specification.
> It is not stable, either.
Surely this driver is independent from the pinctrl.
I'll remove the descriptions about the pinctrl.
> > + - phy-handle: Should point to the external phy device.
> > + See ethernet.txt file in the same directory.
> > + - mdio subnode: Should be device tree subnode with the following required
> > + properties:
> > + - #address-cells: Must be <1>.
> > + - #size-cells: Must be <0>.
> > + - reg: phy ID number, usually a small integer.
>
>
> Are you talking about "Required subnode" in the "Required properties"?
It might be confused description. The subnode is separated from the properties.
> > +Optional properties:
> > + - local-mac-address: See ethernet.txt in the same directory.
In addition, I'll add "clocks" and "resets" according to another mail.
> > +
> > +Example:
> > +
> > + ether: ethernet@65000000 {
> > + compatible = "socionext,uniphier-ld20-ave4";
> > + reg = <0x65000000 0x8500>;
> > + interrupts = <0 66 4>;
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_ether_rgmii>;
> > + phy-mode = "rgmii";
> > + phy-handle = <ðphy>;
> > + local-mac-address = [00 00 00 00 00 00];
> > + mdio {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + ethphy: ethphy@1 {
> > + reg = <1>;
> > + };
> > + };
> > + };
> > --
> > 2.7.4
> >
>
>
>
> --
> Best Regards
> Masahiro Yamada
---
Best Regards,
Kunihiko Hayashi
^ permalink raw reply
* Re: [PATCH net-next v2 2/2] net: ethernet: socionext: add AVE ethernet driver
From: Kunihiko Hayashi @ 2017-10-18 10:23 UTC (permalink / raw)
To: Masahiro Yamada
Cc: netdev, Andrew Lunn, Florian Fainelli, Rob Herring, Mark Rutland,
linux-arm-kernel, Linux Kernel Mailing List, devicetree,
Masami Hiramatsu, Jassi Brar
In-Reply-To: <CAK7LNAR0Dy0aUjQKw7YxSbXZkpjn=1B7_knkSed6=EDVzL6v9w@mail.gmail.com>
On Mon, 16 Oct 2017 00:08:21 +0900 <yamada.masahiro@socionext.com> wrote:
> 2017-10-13 9:35 GMT+09:00 Kunihiko Hayashi <hayashi.kunihiko@socionext.com>:
> > +static int ave_probe(struct platform_device *pdev)
> > +{
> > + struct device *dev = &pdev->dev;
> > + struct device_node *np = dev->of_node;
> > + u32 ave_id;
> > + struct ave_private *priv;
> > + const struct ave_soc_data *data;
> > + phy_interface_t phy_mode;
> > + struct net_device *ndev;
> > + struct resource *res;
> > + void __iomem *base;
> > + int irq, ret = 0;
> > + char buf[ETHTOOL_FWVERS_LEN];
> > + const void *mac_addr;
> > +
> > + data = of_device_get_match_data(dev);
> > + if (WARN_ON(!data))
> > + return -EINVAL;
> > +
> > + phy_mode = of_get_phy_mode(np);
> > + if (phy_mode < 0) {
> > + dev_err(dev, "phy-mode not found\n");
> > + return -EINVAL;
> > + }
> > + if ((!phy_interface_mode_is_rgmii(phy_mode)) &&
> > + phy_mode != PHY_INTERFACE_MODE_RMII &&
> > + phy_mode != PHY_INTERFACE_MODE_MII) {
> > + dev_err(dev, "phy-mode is invalid\n");
> > + return -EINVAL;
> > + }
> > +
> > + irq = platform_get_irq(pdev, 0);
> > + if (irq < 0) {
> > + dev_err(dev, "IRQ not found\n");
> > + return irq;
> > + }
> > +
> > + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > + base = devm_ioremap_resource(dev, res);
> > + if (IS_ERR(base))
> > + return PTR_ERR(base);
> > +
> > + /* alloc netdevice */
> > + ndev = alloc_etherdev(sizeof(struct ave_private));
> > + if (!ndev) {
> > + dev_err(dev, "can't allocate ethernet device\n");
> > + return -ENOMEM;
> > + }
> > +
> > + ndev->netdev_ops = &ave_netdev_ops;
> > + ndev->ethtool_ops = &ave_ethtool_ops;
> > + SET_NETDEV_DEV(ndev, dev);
> > +
> > + /* support hardware checksum */
> > + ndev->features |= (NETIF_F_IP_CSUM | NETIF_F_RXCSUM);
> > + ndev->hw_features |= (NETIF_F_IP_CSUM | NETIF_F_RXCSUM);
> > +
> > + ndev->max_mtu = AVE_MAX_ETHFRAME - (ETH_HLEN + ETH_FCS_LEN);
> > +
> > + /* get mac address */
> > + mac_addr = of_get_mac_address(np);
> > + if (mac_addr)
> > + ether_addr_copy(ndev->dev_addr, mac_addr);
> > +
> > + /* if the mac address is invalid, use random mac address */
> > + if (!is_valid_ether_addr(ndev->dev_addr)) {
> > + eth_hw_addr_random(ndev);
> > + dev_warn(dev, "Using random MAC address: %pM\n",
> > + ndev->dev_addr);
> > + }
> > +
> > + priv = netdev_priv(ndev);
> > + priv->base = base;
> > + priv->irq = irq;
> > + priv->ndev = ndev;
> > + priv->msg_enable = netif_msg_init(-1, AVE_DEFAULT_MSG_ENABLE);
> > + priv->phy_mode = phy_mode;
> > + priv->data = data;
> > +
> > + if (IS_DESC_64BIT(priv)) {
> > + priv->desc_size = AVE_DESC_SIZE_64;
> > + priv->tx.daddr = AVE_TXDM_64;
> > + priv->rx.daddr = AVE_RXDM_64;
> > + } else {
> > + priv->desc_size = AVE_DESC_SIZE_32;
> > + priv->tx.daddr = AVE_TXDM_32;
> > + priv->rx.daddr = AVE_RXDM_32;
> > + }
> > + priv->tx.ndesc = AVE_NR_TXDESC;
> > + priv->rx.ndesc = AVE_NR_RXDESC;
> > +
> > + u64_stats_init(&priv->stats_rx.syncp);
> > + u64_stats_init(&priv->stats_tx.syncp);
> > +
> > + /* get clock */
>
> Please remove this super-obvious comment.
I'll check comments out and remove them unnecessary.
> > + priv->clk = clk_get(dev, NULL);
>
> Missing clk_put() in the failure path.
>
> Why don't you use devm?
>
>
>
> > + if (IS_ERR(priv->clk))
> > + priv->clk = NULL;
>
> So, clk is optional, but
> you need to check EPROBE_DEFER.
>
>
>
>
> > + /* get reset */
>
> Remove.
>
>
> > + priv->rst = reset_control_get(dev, NULL);
> > + if (IS_ERR(priv->rst))
> > + priv->rst = NULL;
>
>
> reset_control_get() is deprecated. Do not use it in a new driver.
>
> Again, missing reset_control_put(). devm?
>
>
> The reset seems optional (again, ignoring EPROBE_DEFER)
> but you did not use reset_control_get_optional, why?
>
> From your code, this reset is used as shared.
>
>
> priv->rst = devm_reset_control_get_optional_shared(dev, NULL);
> if (IS_ERR(priv->rst))
> return PTR_ERR(priv->rst);
The clk and reset are optional in the driver.
Referring to your suggested method, I'll fix the part of clk and reset.
>
>
> --
> Best Regards
> Masahiro Yamada
---
Best Regards,
Kunihiko Hayashi
^ permalink raw reply
* Re: [PATCH] mac80211: aggregation: Convert timers to use timer_setup()
From: Johannes Berg @ 2017-10-18 10:29 UTC (permalink / raw)
To: Kees Cook, linux-wireless; +Cc: David S. Miller, netdev, linux-kernel
In-Reply-To: <20171017202545.GA115810@beast>
Hi,
[quoting your other email:]
> This has been the least trivial timer conversion yet. Given the use of
> RCU and other things I may not even know about, I'd love to get a close
> look at this. I *think* this is correct, as it will re-lookup the tid
> entries when firing the timer.
I'm not really sure why you're doing the lookup again? That seems
pointless, since you already have the right structure, and already rely
on it being valid. You can't really get a new struct assigned to the
same TID without the old one being destroyed.
> -static void sta_rx_agg_session_timer_expired(unsigned long data)
> +static void sta_rx_agg_session_timer_expired(struct timer_list *t)
> {
> - /* not an elegant detour, but there is no choice as the timer passes
> - * only one argument, and various sta_info are needed here, so init
> - * flow in sta_info_create gives the TID as data, while the timer_to_id
> - * array gives the sta through container_of */
> - u8 *ptid = (u8 *)data;
> - u8 *timer_to_id = ptid - *ptid;
> - struct sta_info *sta = container_of(timer_to_id, struct sta_info,
> - timer_to_tid[0]);
> + struct tid_ampdu_rx *tid_rx_timer =
> + from_timer(tid_rx_timer, t, session_timer);
> + struct sta_info *sta = tid_rx_timer->sta;
> + u16 tid = tid_rx_timer->tid;
> struct tid_ampdu_rx *tid_rx;
> unsigned long timeout;
>
> rcu_read_lock();
> - tid_rx = rcu_dereference(sta->ampdu_mlme.tid_rx[*ptid]);
> + tid_rx = rcu_dereference(sta->ampdu_mlme.tid_rx[tid]);
> if (!tid_rx) {
> rcu_read_unlock();
So through all of this, I'm pretty sure we can just use tid_rx_timer
instead of tid_rx.
(Same for TX)
Anyway, the change here looks correct to me, so I'll apply it and then
perhaps clean up more. I've only changed "u16 tid" to "u8 tid" since
the valid range is 0-15 (in theory, in practice 0-7).
johannes
^ permalink raw reply
* Re: [net-next V8 PATCH 1/5] bpf: introduce new bpf cpu map type BPF_MAP_TYPE_CPUMAP
From: Yann Ylavic @ 2017-10-18 10:47 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: Linux Kernel Network Developers, jakub.kicinski,
Michael S. Tsirkin, pavel.odintsov, Jason Wang, mchan,
John Fastabend, peter.waskiewicz.jr, ast, Daniel Borkmann,
Alexei Starovoitov, Andy Gospodarek
In-Reply-To: <20171018103807.367e91ee@redhat.com>
On Wed, Oct 18, 2017 at 10:38 AM, Jesper Dangaard Brouer
<brouer@redhat.com> wrote:
>
> On Wed, 18 Oct 2017 09:45:59 +0200 Yann Ylavic <ylavic.dev@gmail.com> wrote:
>
>> On Mon, Oct 16, 2017 at 12:19 PM, Jesper Dangaard Brouer
>> <brouer@redhat.com> wrote:
>> > +
>> > + /* Notice returns -EPERM on if map size is larger than memlock limit */
>> > + ret = bpf_map_precharge_memlock(cmap->map.pages);
>> > + if (ret) {
>> > + err = ret;
>> > + goto free_cmap;
>> > + }
>> > +
>> > + /* A per cpu bitfield with a bit per possible CPU in map */
>> > + cmap->flush_needed = __alloc_percpu(cpu_map_bitmap_size(attr),
>> > + __alignof__(unsigned long));
>> > + if (!cmap->flush_needed)
>> > + goto free_cmap;
>> > +
>> > + /* Alloc array for possible remote "destination" CPUs */
>> > + cmap->cpu_map = bpf_map_area_alloc(cmap->map.max_entries *
>> > + sizeof(struct bpf_cpu_map_entry *),
>> > + cmap->map.numa_node);
>> > + if (!cmap->cpu_map)
>>
>> ret = -ENOMEM; ?
>
> Did you notice that "err" already is = -ENOMEM at this point?
My bad, I was confused by the use of "ret"...
>
>
>> > + goto free_percpu;
>> > +
>> > + return &cmap->map;
>> > +free_percpu:
>> > + free_percpu(cmap->flush_needed);
>> > +free_cmap:
>> > + kfree(cmap);
>> > + return ERR_PTR(err);
.. while actually "err" is returned.
Sorry for wasting your time.
>> > +}
>>
>>
>> Regards,
>> Yann.
^ permalink raw reply
* [PATCH net-next 0/2] net: dsa: lan9303: Add fdb/mdb methods
From: Egil Hjelmeland @ 2017-10-18 10:59 UTC (permalink / raw)
To: andrew, vivien.didelot, f.fainelli, netdev, linux-kernel; +Cc: Egil Hjelmeland
This series add support for accessing and managing the lan9303 ALR
(Address Logic Resolution).
The first patch add low level functions for accessing the ALR, along
with port_fast_age and port_fdb_dump methods.
The second patch add functions for managing ALR entires, along with
remaining fdb/mdb methods.
Note I have have a question in the second patch, in lan9303_alr_del_port.
Note that to complete STP support, a special ALR entry with the STP eth
address must be added too. This must be addressed later.
Comments welcome!
Egil Hjelmeland (2):
net: dsa: lan9303: Add port_fast_age and port_fdb_dump methods
net: dsa: lan9303: Add fdb/mdb manipulation
drivers/net/dsa/lan9303-core.c | 334 +++++++++++++++++++++++++++++++++++++++++
drivers/net/dsa/lan9303.h | 11 ++
2 files changed, 345 insertions(+)
--
2.11.0
^ permalink raw reply
* [PATCH net-next 2/2] net: dsa: lan9303: Add fdb/mdb manipulation
From: Egil Hjelmeland @ 2017-10-18 10:59 UTC (permalink / raw)
To: andrew, vivien.didelot, f.fainelli, netdev, linux-kernel; +Cc: Egil Hjelmeland
In-Reply-To: <20171018105935.12489-1-privat@egil-hjelmeland.no>
Add functions for managing the lan9303 ALR (Address Logic
Resolution).
Implement DSA methods: port_fdb_add, port_fdb_del, port_mdb_prepare,
port_mdb_add and port_mdb_del.
Since the lan9303 do not offer reading specific ALR entry, the driver
caches all static entries - in a flat table.
Signed-off-by: Egil Hjelmeland <privat@egil-hjelmeland.no>
---
drivers/net/dsa/lan9303-core.c | 175 +++++++++++++++++++++++++++++++++++++++++
drivers/net/dsa/lan9303.h | 9 +++
2 files changed, 184 insertions(+)
diff --git a/drivers/net/dsa/lan9303-core.c b/drivers/net/dsa/lan9303-core.c
index 8b5202f3c0b0..4177e9d2e8ae 100644
--- a/drivers/net/dsa/lan9303-core.c
+++ b/drivers/net/dsa/lan9303-core.c
@@ -19,6 +19,7 @@
#include <linux/mii.h>
#include <linux/phy.h>
#include <linux/if_bridge.h>
+#include <linux/etherdevice.h>
#include "lan9303.h"
@@ -499,6 +500,37 @@ static int lan9303_detect_phy_setup(struct lan9303 *chip)
static const int alrport_2_portmap[] = {1, 2, 4, 0, 3, 5, 6, 7 };
static const int portmap_2_alrport[] = {3, 0, 1, 4, 2, 5, 6, 7 };
+/* ALR: Cache static entries: mac address + port bitmap */
+
+/* Return pointer to first free ALR cache entry, return NULL if none */
+static struct lan9303_alr_cache_entry *
+lan9303_alr_cache_find_free(struct lan9303 *chip)
+{
+ int i;
+ struct lan9303_alr_cache_entry *entr = chip->alr_cache;
+
+ for (i = 0; i < LAN9303_NUM_ALR_RECORDS; i++, entr++)
+ if (entr->port_map == 0)
+ return entr;
+ return NULL;
+}
+
+/* Return pointer to ALR cache entry matching MAC address */
+static struct lan9303_alr_cache_entry *
+lan9303_alr_cache_find_mac(struct lan9303 *chip, const u8 *mac_addr)
+{
+ int i;
+ struct lan9303_alr_cache_entry *entr = chip->alr_cache;
+
+ BUILD_BUG_ON_MSG(sizeof(struct lan9303_alr_cache_entry) & 1,
+ "ether_addr_equal require u16 alignment");
+
+ for (i = 0; i < LAN9303_NUM_ALR_RECORDS; i++, entr++)
+ if (ether_addr_equal(entr->mac_addr, mac_addr))
+ return entr;
+ return NULL;
+}
+
/* ALR: Actual register access functions */
/* This function will wait a while until mask & reg == value */
@@ -610,6 +642,76 @@ static void alr_loop_cb_fdb_port_dump(struct lan9303 *chip, u32 dat0,
dump_ctx->cb(mac, 0, is_static, dump_ctx->data);
}
+/* ALR: Add/modify/delete ALR entries */
+
+/* Set a static ALR entry. Delete entry if port_map is zero */
+static void lan9303_alr_set_entry(struct lan9303 *chip, const u8 *mac,
+ u8 port_map, bool stp_override)
+{
+ u32 dat0, dat1, alr_port;
+
+ dev_dbg(chip->dev, "%s(%pM, %d)\n", __func__, mac, port_map);
+ dat1 = ALR_DAT1_STATIC;
+ if (port_map)
+ dat1 |= ALR_DAT1_VALID; /* otherwise no ports: delete entry */
+ if (stp_override)
+ dat1 |= ALR_DAT1_AGE_OVERRID;
+
+ alr_port = portmap_2_alrport[port_map & 7];
+ dat1 &= ~ALR_DAT1_PORT_MASK;
+ dat1 |= alr_port << ALR_DAT1_PORT_BITOFFS;
+
+ dat0 = 0;
+ dat0 |= (mac[0] << 0);
+ dat0 |= (mac[1] << 8);
+ dat0 |= (mac[2] << 16);
+ dat0 |= (mac[3] << 24);
+
+ dat1 |= (mac[4] << 0);
+ dat1 |= (mac[5] << 8);
+
+ lan9303_alr_make_entry_raw(chip, dat0, dat1);
+}
+
+/* Add port to static ALR entry, create new static entry if needed */
+static int lan9303_alr_add_port(struct lan9303 *chip, const u8 *mac,
+ int port, bool stp_override)
+{
+ struct lan9303_alr_cache_entry *entr;
+
+ entr = lan9303_alr_cache_find_mac(chip, mac);
+ if (!entr) { /*New entry */
+ entr = lan9303_alr_cache_find_free(chip);
+ if (!entr)
+ return -ENOSPC;
+ ether_addr_copy(entr->mac_addr, mac);
+ }
+ entr->port_map |= BIT(port);
+ entr->stp_override = stp_override;
+ lan9303_alr_set_entry(chip, mac, entr->port_map, stp_override);
+ return 0;
+}
+
+/* Delete static port from ALR entry, delete entry if last port */
+static int lan9303_alr_del_port(struct lan9303 *chip, const u8 *mac,
+ int port)
+{
+ struct lan9303_alr_cache_entry *entr;
+
+ entr = lan9303_alr_cache_find_mac(chip, mac);
+ if (!entr)
+ return 0; /* no static entry found */
+ /* Question: Should we delete any learned entry?
+ * { lan9303_alr_set_entry(chip, mac, 0, false); return 0; }
+ */
+
+ entr->port_map &= ~BIT(port);
+ if (entr->port_map == 0) /* zero means its free again */
+ eth_zero_addr(&entr->port_map);
+ lan9303_alr_set_entry(chip, mac, entr->port_map, entr->stp_override);
+ return 0;
+}
+
/* --------------------- Various chip setup ----------------------*/
static int lan9303_disable_processing_port(struct lan9303 *chip,
@@ -1065,6 +1167,30 @@ static void lan9303_port_fast_age(struct dsa_switch *ds, int port)
lan9303_alr_loop(chip, alr_loop_cb_del_port_learned, &port);
}
+static int lan9303_port_fdb_add(struct dsa_switch *ds, int port,
+ const unsigned char *addr, u16 vid)
+{
+ struct lan9303 *chip = ds->priv;
+
+ dev_dbg(chip->dev, "%s(%d, %pM, %d)\n", __func__, port, addr, vid);
+ if (vid)
+ return -EOPNOTSUPP;
+ return lan9303_alr_add_port(chip, addr, port, false);
+}
+
+static int lan9303_port_fdb_del(struct dsa_switch *ds, int port,
+ const unsigned char *addr, u16 vid)
+
+{
+ struct lan9303 *chip = ds->priv;
+
+ dev_dbg(chip->dev, "%s(%d, %pM, %d)\n", __func__, port, addr, vid);
+ if (vid)
+ return -EOPNOTSUPP;
+ lan9303_alr_del_port(chip, addr, port);
+ return 0;
+}
+
static int lan9303_port_fdb_dump(struct dsa_switch *ds, int port,
dsa_fdb_dump_cb_t *cb, void *data)
{
@@ -1080,6 +1206,50 @@ static int lan9303_port_fdb_dump(struct dsa_switch *ds, int port,
return 0;
}
+static int lan9303_port_mdb_prepare(
+ struct dsa_switch *ds, int port,
+ const struct switchdev_obj_port_mdb *mdb,
+ struct switchdev_trans *trans)
+{
+ struct lan9303 *chip = ds->priv;
+
+ dev_dbg(chip->dev, "%s(%d, %pM, %d)\n", __func__, port, mdb->addr,
+ mdb->vid);
+ if (mdb->vid)
+ return -EOPNOTSUPP;
+ if (lan9303_alr_cache_find_mac(chip, mdb->addr))
+ return 0;
+ if (!lan9303_alr_cache_find_free(chip))
+ return -ENOSPC;
+ return 0;
+}
+
+static void lan9303_port_mdb_add(
+ struct dsa_switch *ds, int port,
+ const struct switchdev_obj_port_mdb *mdb,
+ struct switchdev_trans *trans)
+{
+ struct lan9303 *chip = ds->priv;
+
+ dev_dbg(chip->dev, "%s(%d, %pM, %d)\n", __func__, port, mdb->addr,
+ mdb->vid);
+ lan9303_alr_add_port(chip, mdb->addr, port, false);
+}
+
+static int lan9303_port_mdb_del(
+ struct dsa_switch *ds, int port,
+ const struct switchdev_obj_port_mdb *mdb)
+{
+ struct lan9303 *chip = ds->priv;
+
+ dev_dbg(chip->dev, "%s(%d, %pM, %d)\n", __func__, port, mdb->addr,
+ mdb->vid);
+ if (mdb->vid)
+ return -EOPNOTSUPP;
+ lan9303_alr_del_port(chip, mdb->addr, port);
+ return 0;
+}
+
static const struct dsa_switch_ops lan9303_switch_ops = {
.get_tag_protocol = lan9303_get_tag_protocol,
.setup = lan9303_setup,
@@ -1095,7 +1265,12 @@ static const struct dsa_switch_ops lan9303_switch_ops = {
.port_bridge_leave = lan9303_port_bridge_leave,
.port_stp_state_set = lan9303_port_stp_state_set,
.port_fast_age = lan9303_port_fast_age,
+ .port_fdb_add = lan9303_port_fdb_add,
+ .port_fdb_del = lan9303_port_fdb_del,
.port_fdb_dump = lan9303_port_fdb_dump,
+ .port_mdb_prepare = lan9303_port_mdb_prepare,
+ .port_mdb_add = lan9303_port_mdb_add,
+ .port_mdb_del = lan9303_port_mdb_del,
};
static int lan9303_register_switch(struct lan9303 *chip)
diff --git a/drivers/net/dsa/lan9303.h b/drivers/net/dsa/lan9303.h
index 4db323d65741..d807b1be35f2 100644
--- a/drivers/net/dsa/lan9303.h
+++ b/drivers/net/dsa/lan9303.h
@@ -12,6 +12,11 @@ struct lan9303_phy_ops {
};
#define LAN9303_NUM_ALR_RECORDS 512
+struct lan9303_alr_cache_entry {
+ u8 mac_addr[ETH_ALEN];
+ u8 port_map; /* Bitmap of ports. Zero if unused entry */
+ u8 stp_override; /* non zero if set ALR_DAT1_AGE_OVERRID */
+};
struct lan9303 {
struct device *dev;
@@ -25,6 +30,10 @@ struct lan9303 {
const struct lan9303_phy_ops *ops;
bool is_bridged; /* true if port 1 and 2 are bridged */
u32 swe_port_state; /* remember SWE_PORT_STATE while not bridged */
+ /* LAN9303 do not offer reading specific ALR entry. Cache all
+ * static entries in a flat table
+ **/
+ struct lan9303_alr_cache_entry alr_cache[LAN9303_NUM_ALR_RECORDS];
};
extern const struct regmap_access_table lan9303_register_set;
--
2.11.0
^ permalink raw reply related
* [PATCH net-next 1/2] net: dsa: lan9303: Add port_fast_age and port_fdb_dump methods
From: Egil Hjelmeland @ 2017-10-18 10:59 UTC (permalink / raw)
To: andrew, vivien.didelot, f.fainelli, netdev, linux-kernel; +Cc: Egil Hjelmeland
In-Reply-To: <20171018105935.12489-1-privat@egil-hjelmeland.no>
Add DSA method port_fast_age as a step to STP support.
Add low level functions for accessing the lan9303 ALR (Address Logic
Resolution).
Added DSA method port_fdb_dump
Signed-off-by: Egil Hjelmeland <privat@egil-hjelmeland.no>
---
drivers/net/dsa/lan9303-core.c | 159 +++++++++++++++++++++++++++++++++++++++++
drivers/net/dsa/lan9303.h | 2 +
2 files changed, 161 insertions(+)
diff --git a/drivers/net/dsa/lan9303-core.c b/drivers/net/dsa/lan9303-core.c
index fecfe1fe67ea..8b5202f3c0b0 100644
--- a/drivers/net/dsa/lan9303-core.c
+++ b/drivers/net/dsa/lan9303-core.c
@@ -124,6 +124,21 @@
#define LAN9303_MAC_RX_CFG_2 0x0c01
#define LAN9303_MAC_TX_CFG_2 0x0c40
#define LAN9303_SWE_ALR_CMD 0x1800
+# define ALR_CMD_MAKE_ENTRY BIT(2)
+# define ALR_CMD_GET_FIRST BIT(1)
+# define ALR_CMD_GET_NEXT BIT(0)
+#define LAN9303_SWE_ALR_WR_DAT_0 0x1801
+#define LAN9303_SWE_ALR_WR_DAT_1 0x1802
+# define ALR_DAT1_VALID BIT(26)
+# define ALR_DAT1_END_OF_TABL BIT(25)
+# define ALR_DAT1_AGE_OVERRID BIT(25)
+# define ALR_DAT1_STATIC BIT(24)
+# define ALR_DAT1_PORT_BITOFFS 16
+# define ALR_DAT1_PORT_MASK (7 << ALR_DAT1_PORT_BITOFFS)
+#define LAN9303_SWE_ALR_RD_DAT_0 0x1805
+#define LAN9303_SWE_ALR_RD_DAT_1 0x1806
+#define LAN9303_SWE_ALR_CMD_STS 0x1808
+# define ALR_STS_MAKE_PEND BIT(0)
#define LAN9303_SWE_VLAN_CMD 0x180b
# define LAN9303_SWE_VLAN_CMD_RNW BIT(5)
# define LAN9303_SWE_VLAN_CMD_PVIDNVLAN BIT(4)
@@ -478,6 +493,125 @@ static int lan9303_detect_phy_setup(struct lan9303 *chip)
return 0;
}
+/* ----------------- Address Logic Resolution (ALR)------------------*/
+
+/* Map ALR-port bits to port bitmap, and back*/
+static const int alrport_2_portmap[] = {1, 2, 4, 0, 3, 5, 6, 7 };
+static const int portmap_2_alrport[] = {3, 0, 1, 4, 2, 5, 6, 7 };
+
+/* ALR: Actual register access functions */
+
+/* This function will wait a while until mask & reg == value */
+/* Otherwise, return timeout */
+static int lan9303_csr_reg_wait(struct lan9303 *chip, int regno,
+ int mask, char value)
+{
+ int i;
+
+ for (i = 0; i < 0x1000; i++) {
+ u32 reg;
+
+ lan9303_read_switch_reg(chip, regno, ®);
+ if ((reg & mask) == value)
+ return 0;
+ usleep_range(1000, 2000);
+ }
+ return -ETIMEDOUT;
+}
+
+static int lan9303_alr_make_entry_raw(struct lan9303 *chip, u32 dat0, u32 dat1)
+{
+ lan9303_write_switch_reg(
+ chip, LAN9303_SWE_ALR_WR_DAT_0, dat0);
+ lan9303_write_switch_reg(
+ chip, LAN9303_SWE_ALR_WR_DAT_1, dat1);
+ lan9303_write_switch_reg(
+ chip, LAN9303_SWE_ALR_CMD, ALR_CMD_MAKE_ENTRY);
+ lan9303_csr_reg_wait(
+ chip, LAN9303_SWE_ALR_CMD_STS, ALR_STS_MAKE_PEND, 0);
+ lan9303_write_switch_reg(chip, LAN9303_SWE_ALR_CMD, 0);
+ return 0;
+}
+
+typedef void alr_loop_cb_t(struct lan9303 *chip, u32 dat0, u32 dat1,
+ int portmap, void *ctx);
+
+static void lan9303_alr_loop(struct lan9303 *chip, alr_loop_cb_t *cb, void *ctx)
+{
+ int i;
+
+ lan9303_write_switch_reg(chip, LAN9303_SWE_ALR_CMD, ALR_CMD_GET_FIRST);
+ lan9303_write_switch_reg(chip, LAN9303_SWE_ALR_CMD, 0);
+
+ for (i = 1; i < LAN9303_NUM_ALR_RECORDS; i++) {
+ u32 dat0, dat1;
+ int alrport, portmap;
+
+ lan9303_read_switch_reg(chip, LAN9303_SWE_ALR_RD_DAT_0, &dat0);
+ lan9303_read_switch_reg(chip, LAN9303_SWE_ALR_RD_DAT_1, &dat1);
+ if (dat1 & ALR_DAT1_END_OF_TABL)
+ break;
+
+ alrport = (dat1 & ALR_DAT1_PORT_MASK) >> ALR_DAT1_PORT_BITOFFS;
+ portmap = alrport_2_portmap[alrport];
+
+ cb(chip, dat0, dat1, portmap, ctx);
+
+ lan9303_write_switch_reg(
+ chip, LAN9303_SWE_ALR_CMD, ALR_CMD_GET_NEXT);
+ lan9303_write_switch_reg(chip, LAN9303_SWE_ALR_CMD, 0);
+ }
+}
+
+/* ALR: lan9303_alr_loop callback functions */
+
+static void alr_reg_to_mac(u32 dat0, u32 dat1, u8 mac[6])
+{
+ mac[0] = (dat0 >> 0) & 0xff;
+ mac[1] = (dat0 >> 8) & 0xff;
+ mac[2] = (dat0 >> 16) & 0xff;
+ mac[3] = (dat0 >> 24) & 0xff;
+ mac[4] = (dat1 >> 0) & 0xff;
+ mac[5] = (dat1 >> 8) & 0xff;
+}
+
+/* Clear learned (non-static) entry on given port */
+static void alr_loop_cb_del_port_learned(struct lan9303 *chip, u32 dat0,
+ u32 dat1, int portmap, void *ctx)
+{
+ int *port = ctx;
+
+ if (((BIT(*port) & portmap) == 0) || (dat1 & ALR_DAT1_STATIC))
+ return;
+
+ /* learned entries has only one port, we can just delete */
+ dat1 &= ~ALR_DAT1_VALID; /* delete entry */
+ lan9303_alr_make_entry_raw(chip, dat0, dat1);
+}
+
+struct port_fdb_dump_ctx {
+ int port;
+ void *data;
+ dsa_fdb_dump_cb_t *cb;
+};
+
+static void alr_loop_cb_fdb_port_dump(struct lan9303 *chip, u32 dat0,
+ u32 dat1, int portmap, void *ctx)
+{
+ struct port_fdb_dump_ctx *dump_ctx = ctx;
+ u8 mac[ETH_ALEN];
+ bool is_static;
+
+ if ((BIT(dump_ctx->port) & portmap) == 0)
+ return;
+
+ alr_reg_to_mac(dat0, dat1, mac);
+ is_static = !!(dat1 & ALR_DAT1_STATIC);
+ dump_ctx->cb(mac, 0, is_static, dump_ctx->data);
+}
+
+/* --------------------- Various chip setup ----------------------*/
+
static int lan9303_disable_processing_port(struct lan9303 *chip,
unsigned int port)
{
@@ -923,6 +1057,29 @@ static void lan9303_port_stp_state_set(struct dsa_switch *ds, int port,
/* else: touching SWE_PORT_STATE would break port separation */
}
+static void lan9303_port_fast_age(struct dsa_switch *ds, int port)
+{
+ struct lan9303 *chip = ds->priv;
+
+ dev_dbg(chip->dev, "%s(%d)\n", __func__, port);
+ lan9303_alr_loop(chip, alr_loop_cb_del_port_learned, &port);
+}
+
+static int lan9303_port_fdb_dump(struct dsa_switch *ds, int port,
+ dsa_fdb_dump_cb_t *cb, void *data)
+{
+ struct lan9303 *chip = ds->priv;
+ struct port_fdb_dump_ctx dump_ctx = {
+ .port = port,
+ .data = data,
+ .cb = cb,
+ };
+
+ dev_dbg(chip->dev, "%s(%d)\n", __func__, port);
+ lan9303_alr_loop(chip, alr_loop_cb_fdb_port_dump, &dump_ctx);
+ return 0;
+}
+
static const struct dsa_switch_ops lan9303_switch_ops = {
.get_tag_protocol = lan9303_get_tag_protocol,
.setup = lan9303_setup,
@@ -937,6 +1094,8 @@ static const struct dsa_switch_ops lan9303_switch_ops = {
.port_bridge_join = lan9303_port_bridge_join,
.port_bridge_leave = lan9303_port_bridge_leave,
.port_stp_state_set = lan9303_port_stp_state_set,
+ .port_fast_age = lan9303_port_fast_age,
+ .port_fdb_dump = lan9303_port_fdb_dump,
};
static int lan9303_register_switch(struct lan9303 *chip)
diff --git a/drivers/net/dsa/lan9303.h b/drivers/net/dsa/lan9303.h
index 68ecd544b658..4db323d65741 100644
--- a/drivers/net/dsa/lan9303.h
+++ b/drivers/net/dsa/lan9303.h
@@ -11,6 +11,8 @@ struct lan9303_phy_ops {
int regnum, u16 val);
};
+#define LAN9303_NUM_ALR_RECORDS 512
+
struct lan9303 {
struct device *dev;
struct regmap *regmap;
--
2.11.0
^ permalink raw reply related
* RE: [PATCH net-next 1/3] ibmvnic: Enable scatter-gather support
From: David Laight @ 2017-10-18 11:04 UTC (permalink / raw)
To: 'Thomas Falcon', netdev@vger.kernel.org
In-Reply-To: <1508261816-3145-2-git-send-email-tlfalcon@linux.vnet.ibm.com>
From: Thomas Falcon
> Sent: 17 October 2017 18:37
> This patch enables scatter gather support. Since there is no
> HW/FW scatter-gather support at this time, the driver needs to
> loop through each fragment and copy it to a contiguous, pre-mapped
> buffer entry.
...
> offset = index * adapter->req_mtu;
> dst = tx_pool->long_term_buff.buff + offset;
You should be able to treat the pre-allocated data area as a
big ring buffer.
So it can hold a lot of small frames or a few big ones.
This slightly complicates the 'is there enough space for
this packet' check since you need buffer space as well
as a ring entry.
You also really want to align each tx buffer on a 4n+2
boundary so that most of the copy is aligned.
> memset(dst, 0, adapter->req_mtu);
Seems unnecessary.
David
^ permalink raw reply
* Re: [PATCH] wanxl: use m68k-linux-gnu-as if available
From: David Miller @ 2017-10-18 11:08 UTC (permalink / raw)
To: kilobyte; +Cc: khc, netdev
In-Reply-To: <20171012232434.15890-1-kilobyte@angband.pl>
From: Adam Borowski <kilobyte@angband.pl>
Date: Fri, 13 Oct 2017 01:24:34 +0200
> This fixes build failure on Debian based systems: GNU as is the only m68k
> assembler available in the archive (package binutils-m68k-linux-gnu).
>
> Signed-off-by: Adam Borowski <kilobyte@angband.pl>
The Kconfig help text for the config option controlling the build
firmware is extremely clear what the requirements are for enabling
that option.
And that is: "It requires as68k, ld68k and hexdump programs."
^ permalink raw reply
* Re: [PATCH v3] net: ftgmac100: Request clock and set speed
From: David Miller @ 2017-10-18 11:09 UTC (permalink / raw)
To: joel; +Cc: benh, netdev, linux-kernel, andrew
In-Reply-To: <20171013041638.30763-1-joel@jms.id.au>
From: Joel Stanley <joel@jms.id.au>
Date: Fri, 13 Oct 2017 12:16:38 +0800
> According to the ASPEED datasheet, gigabit speeds require a clock of
> 100MHz or higher. Other speeds require 25MHz or higher. This patch
> configures a 100MHz clock if the system has a direct-attached
> PHY, or 25MHz if the system is running NC-SI which is limited to 100MHz.
>
> There appear to be no other upstream users of the FTGMAC100 driver it is
> hard to know the clocking requirements of other platforms. Therefore a
> conservative approach was taken with enabling clocks. If the platform is
> not ASPEED, both requesting the clock and configuring the speed is
> skipped.
>
> Signed-off-by: Joel Stanley <joel@jms.id.au>
Applied to net-next, thanks.
^ permalink raw reply
* Re: [net-next V8 PATCH 0/5] New bpf cpumap type for XDP_REDIRECT
From: David Miller @ 2017-10-18 11:12 UTC (permalink / raw)
To: brouer
Cc: netdev, jakub.kicinski, mst, pavel.odintsov, jasowang, mchan,
john.fastabend, peter.waskiewicz.jr, ast, borkmann,
alexei.starovoitov, andy
In-Reply-To: <150814913767.1806.3470498528707259987.stgit@firesoul>
From: Jesper Dangaard Brouer <brouer@redhat.com>
Date: Mon, 16 Oct 2017 12:19:23 +0200
> Introducing a new way to redirect XDP frames. Notice how no driver
> changes are necessary given the design of XDP_REDIRECT.
Series applied, thanks Jesper.
^ permalink raw reply
* Re: [PATCH net-next v2 2/2] net: add skb_memcpy_to[from]_msg() to optimize skb code
From: David Miller @ 2017-10-18 11:18 UTC (permalink / raw)
To: cugyly; +Cc: netdev, Linyu.Yuan
In-Reply-To: <1508155873-23752-1-git-send-email-cugyly@163.com>
From: yuan linyu <cugyly@163.com>
Date: Mon, 16 Oct 2017 20:11:13 +0800
> From: yuan linyu <Linyu.Yuan@alcatel-sbell.com.cn>
>
> add these two wrappers in skbuff.h which is better named
> than previous and only used for skb.
>
> Signed-off-by: yuan linyu <Linyu.Yuan@alcatel-sbell.com.cn>
Doing the skb_put() inside of the helper function makes code less
intuitive.
If someone is auditing code it's easier to see the skb_put() and
understand what is happening when it's at the call site rather than
buried in some helper.
Sorry, I don't see these changes as an improvement and will not apply
them.
Thank you.
^ permalink raw reply
* Re: [patch net] mlxsw: core: Fix possible deadlock
From: David Miller @ 2017-10-18 11:21 UTC (permalink / raw)
To: jiri; +Cc: netdev, idosch, mlxsw
In-Reply-To: <20171016142828.2742-1-jiri@resnulli.us>
From: Jiri Pirko <jiri@resnulli.us>
Date: Mon, 16 Oct 2017 16:28:28 +0200
> From: Ido Schimmel <idosch@mellanox.com>
>
> When an EMAD is transmitted, a timeout work item is scheduled with a
> delay of 200ms, so that another EMAD will be retried until a maximum of
> five retries.
>
> In certain situations, it's possible for the function waiting on the
> EMAD to be associated with a work item that is queued on the same
> workqueue (`mlxsw_core`) as the timeout work item. This results in
> flushing a work item on the same workqueue.
>
> According to commit e159489baa71 ("workqueue: relax lockdep annotation
> on flush_work()") the above may lead to a deadlock in case the workqueue
> has only one worker active or if the system in under memory pressure and
> the rescue worker is in use. The latter explains the very rare and
> random nature of the lockdep splats we have been seeing:
...
> Fix this by creating another workqueue for EMAD timeouts, thereby
> preventing the situation of a work item trying to flush a work item
> queued on the same workqueue.
>
> Fixes: caf7297e7ab5f ("mlxsw: core: Introduce support for asynchronous EMAD register access")
> Signed-off-by: Ido Schimmel <idosch@mellanox.com>
> Reported-by: Jiri Pirko <jiri@mellanox.com>
> Signed-off-by: Jiri Pirko <jiri@mellanox.com>
Applied.
^ permalink raw reply
* Re: [PATCH] netlink: use NETLINK_CB(in_skb).sk instead of looking it up
From: David Miller @ 2017-10-18 11:21 UTC (permalink / raw)
To: johannes-cdvu00un1VgdHxzADdlk8Q
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, ebiederman-1v8oiQdgUNlBDgjK7y7TUQ,
johannes.berg-ral2JQCrhuEAvxtiuMwx3w
In-Reply-To: <20171016145749.31793-1-johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
From: Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
Date: Mon, 16 Oct 2017 16:57:49 +0200
> From: Johannes Berg <johannes.berg-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
>
> When netlink_ack() reports an allocation error to the sending
> socket, there's no need to look up the sending socket since
> it's available in the SKB's CB. Use that instead of going to
> the trouble of looking it up.
>
> Note that the pointer is only available since Eric Biederman's
> commit 3fbc290540a1 ("netlink: Make the sending netlink socket availabe in NETLINK_CB")
> which is far newer than the original lookup code (Oct 2003)
> (though the field was called 'ssk' in that commit and only got
> renamed to 'sk' later, I'd actually argue 'ssk' was better - or
> perhaps it should've been 'source_sk' - since there are so many
> different 'sk's involved.)
>
> Signed-off-by: Johannes Berg <johannes.berg-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Applied to net-next.
^ permalink raw reply
* Re: [PATCH net] ibmvnic: Fix calculation of number of TX header descriptors
From: David Miller @ 2017-10-18 11:21 UTC (permalink / raw)
To: tlfalcon; +Cc: netdev
In-Reply-To: <1508166131-5141-1-git-send-email-tlfalcon@linux.vnet.ibm.com>
From: Thomas Falcon <tlfalcon@linux.vnet.ibm.com>
Date: Mon, 16 Oct 2017 10:02:11 -0500
> This patch correctly sets the number of additional header descriptors
> that will be sent in an indirect SCRQ entry.
>
> Signed-off-by: Thomas Falcon <tlfalcon@linux.vnet.ibm.com>
Applied.
^ permalink raw reply
* Re: [PATCH] netlink: fix netlink_ack() extack race
From: David Miller @ 2017-10-18 11:23 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, netdev, johannes.berg
In-Reply-To: <20171016150953.17612-1-johannes@sipsolutions.net>
From: Johannes Berg <johannes@sipsolutions.net>
Date: Mon, 16 Oct 2017 17:09:53 +0200
> From: Johannes Berg <johannes.berg@intel.com>
>
> It seems that it's possible to toggle NETLINK_F_EXT_ACK
> through setsockopt() while another thread/CPU is building
> a message inside netlink_ack(), which could then trigger
> the WARN_ON()s I added since if it goes from being turned
> off to being turned on between allocating and filling the
> message, the skb could end up being too small.
>
> Avoid this whole situation by storing the value of this
> flag in a separate variable and using that throughout the
> function instead.
>
> Fixes: 2d4bc93368f5 ("netlink: extended ACK reporting")
> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Applied and queued up for -stable.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox