- 01 Feb, 2019 20 commits
-
-
Gustavo A. R. Silva authored
One of the more common cases of allocation size calculations is finding the size of a structure that has a zero-sized array at the end, along with memory for some number of elements for that array. For example: struct foo { int stuff; struct boo entry[]; }; instance = kmalloc(sizeof(struct foo) + count * sizeof(struct boo), GFP_KERNEL); Instead of leaving these open-coded and prone to type mistakes, we can now use the new struct_size() helper: instance = kmalloc(struct_size(instance, entry, count), GFP_KERNEL); This code was detected with the help of Coccinelle. Signed-off-by:Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Gustavo A. R. Silva authored
One of the more common cases of allocation size calculations is finding the size of a structure that has a zero-sized array at the end, along with memory for some number of elements for that array. For example: struct foo { int stuff; struct boo entry[]; }; instance = kvzalloc(sizeof(struct foo) + count * sizeof(struct boo), GFP_KERNEL); Instead of leaving these open-coded and prone to type mistakes, we can now use the new struct_size() helper: instance = kvzalloc(struct_size(instance, entry, count), GFP_KERNEL); This code was detected with the help of Coccinelle. Signed-off-by: -
Gustavo A. R. Silva authored
One of the more common cases of allocation size calculations is finding the size of a structure that has a zero-sized array at the end, along with memory for some number of elements for that array. For example: struct foo { int stuff; struct boo entry[]; }; instance = kvzalloc(sizeof(struct foo) + count * sizeof(struct boo), GFP_KERNEL); Instead of leaving these open-coded and prone to type mistakes, we can now use the new struct_size() helper: instance = kvzalloc(struct_size(instance, entry, count), GFP_KERNEL); This code was detected with the help of Coccinelle. Signed-off-by: -
Dave Watson authored
Currently we don't zerocopy if the crypto framework async bit is set. However some crypto algorithms (such as x86 AESNI) support async, but in the context of sendmsg, will never run asynchronously. Instead, check for actual EINPROGRESS return code before assuming algorithm is async. Signed-off-by:
Dave Watson <davejwatson@fb.com> Signed-off-by:
-
David S. Miller authored
Dave Watson says: ==================== net: tls: TLS 1.3 support This patchset adds 256bit keys and TLS1.3 support to the kernel TLS socket. TLS 1.3 is requested by passing TLS_1_3_VERSION in the setsockopt call, which changes the framing as required for TLS1.3. 256bit keys are requested by passing TLS_CIPHER_AES_GCM_256 in the sockopt. This is a fairly straightforward passthrough to the crypto framework. 256bit keys work with both TLS 1.2 and TLS 1.3 TLS 1.3 requires a different AAD layout, necessitating some minor refactoring. It also moves the message type byte to the encrypted portion of the message, instead of the cleartext header as it was in TLS1.2. This requires moving the control message handling to after decryption, but is otherwise similar. V1 -> V2 The first two patches were dropped, and sent separately, one as a bugfix to the net tree. ==================== Signed-off-by: -
Dave Watson authored
Change most tests to TLS 1.3, while adding tests for previous TLS 1.2 behavior. Signed-off-by:
-
Dave Watson authored
TLS 1.3 has minor changes from TLS 1.2 at the record layer. * Header now hardcodes the same version and application content type in the header. * The real content type is appended after the data, before encryption (or after decryption). * The IV is xored with the sequence number, instead of concatinating four bytes of IV with the explicit IV. * Zero-padding: No exlicit length is given, we search backwards from the end of the decrypted data for the first non-zero byte, which is the content type. Currently recv supports reading zero-padding, but there is no way for send to add zero padding. Signed-off-by:
-
Dave Watson authored
For TLS 1.3, the control message is encrypted. Handle control message checks after decryption. Signed-off-by:
-
Dave Watson authored
TLS 1.3 has a different AAD size, use a variable in the code to make TLS 1.3 support easy. Signed-off-by:
-
Dave Watson authored
Wire up support for 256 bit keys from the setsockopt to the crypto framework Signed-off-by:
-
git://git.open-mesh.org/linux-mergeDavid S. Miller authored
Simon Wunderlich says: ==================== This feature/cleanup patchset includes the following patches: - bump version strings, by Simon Wunderlich - Add DHCPACKs for DAT snooping, by Linus Luessing - Update copyright years for 2019, by Sven Eckelmann ==================== Signed-off-by: -
David S. Miller authored
Merge tag 'mac80211-next-for-davem-2019-02-01' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next Johannes Berg says: ==================== New features for the wifi stack: * airtime fairness scheduling in mac80211, so we can share * more authentication offloads to userspace - this is for SAE which is part of WPA3 and is hard to do in firmware * documentation fixes * various mesh improvements * various other small improvements/cleanups This also contains the NLA_POLICY_NESTED{,_ARRAY} change we discussed, which affects everyone but there's no other user yet. ==================== Signed-off-by:
-
Dan Carpenter authored
We should return -ENOMEM if the kcalloc() fails. Fixes: d174ea75 ("net: hns3: add statistics for PFC frames and MAC control frame") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Dan Carpenter authored
We recently changed this function in commit f9fc54d3 ("ethtool: check the return value of get_regs_len") such that if "reglen" is zero we return directly. That means we can remove this condition as well. Signed-off-by:
-
Johannes Berg authored
Fix the missing and malformed documentation that kernel-doc and sphinx warn about. While at it, also add some things to the docs to fix missing links. Sadly, the only way I could find to fix this was to add some trailing whitespace. Signed-off-by:Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
Add the missing documentation that kernel-doc continually warns about, to get rid of all that noise. Signed-off-by: -
Johannes Berg authored
In typical cases, there's no need to pass both the maxattr and the policy array pointer, as the maxattr should just be ARRAY_SIZE(policy) - 1. Therefore, to be less error prone, just remove the maxattr argument from the default macros and deduce the size accordingly. Leave the original macros with a leading underscore to use here and in case somebody needs to pass a policy pointer where the policy isn't declared in the same place and thus ARRAY_SIZE() cannot be used. Signed-off-by: -
Johannes Berg authored
Merge net-next so that we get the changes from net, which would otherwise conflict with the NLA_POLICY_NESTED/_ARRAY changes. Signed-off-by: -
Matteo Croce authored
Fix spelling mistake in cfg80211.h: "lenght" -> "length". The typo is also in the special comment block which translates to documentation. Signed-off-by:
Matteo Croce <mcroce@redhat.com> Signed-off-by:
-
Toke Høiland-Jørgensen authored
There was a typo in the documentation for weight_multiplier in mac80211.h, and the doc was missing entirely for airtime and airtime_weight in sta_info.h. Reported-by:
kbuild test robot <lkp@intel.com> Signed-off-by:
Toke Høiland-Jørgensen <toke@redhat.com> Signed-off-by:
-
- 31 Jan, 2019 2 commits
-
-
Heiner Kallweit authored
WoL handling for the RTL8168 family is a little bit tricky because of different types of broken BIOS and/or chip quirks. Two known issues: 1. Network properly resumes from suspend only if WoL is enabled in the chip. 2. Some notebooks wake up immediately if system is suspended and network device is wakeup-enabled. Few patches tried to deal with this: 7edf6d31 ("r8169: disable WOL per default") 18041b52 ("r8169: restore previous behavior to accept BIOS WoL settings") Currently we have the situation that the chip WoL settings as set by the BIOS are respected (to prevent issue 1), but the device doesn't get wakeup-enabled (to prevent issue 2). This leads to another issue: If systemd is told to set WoL it first checks whether the requested settings are active already (and does nothing if yes). Due to the chip WoL flags being set properly systemd assumes that WoL is configured properly in our case. Result is that device doesn't get wakeup-enabled and WoL doesn't work (until it's set e.g. by ethtool). This patch now: - leaves the chip WoL settings as is (to prevent issue 1) - keeps the behavior to not wakeup-enable the device initially (to prevent issue 2) - In addition we report WoL as being disabled in get_wol, matching that device isn't wakeup-enabled. If systemd is told to enable WoL, it will therefore detect that it has to do something and will call set_wol. Of course the user still has the option to override this with e.g. ethtool. v2: - Don't just exclude __rtl8169_get_wol() from compiling, remove it. v3: - adjust commit message Signed-off-by:
Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by:
-
Julian Wiedmann authored
Replace the macvlan_port_exists() macro with its twin from netdevice.h Signed-off-by:
Julian Wiedmann <jwi@linux.ibm.com> Signed-off-by:
-
- 30 Jan, 2019 18 commits
-
-
David S. Miller authored
Huazhong Tan says: ==================== code optimizations & bugfixes for HNS3 driver This patchset includes bugfixes and code optimizations for the HNS3 ethernet controller driver ==================== Signed-off-by: -
Jian Shen authored
In orginal codes, driver always enables flow director when intializing. When user disable flow director with command ethtool -K, the flow director will be enabled again after resetting. This patch fixes it by only enabling it when first initialzing. Fixes: 6871af29 ("net: hns3: Add reset handle for flow director") Signed-off-by:
Jian Shen <shenjian15@huawei.com> Signed-off-by:
Peng Li <lipeng321@huawei.com> Signed-off-by:
Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by:
-
Jian Shen authored
When VF is resetting, it can't communicate to PF with mailbox msg. This patch adds reset state checking before sending keep alive msg to PF. Fixes: a6d818e3 ("net: hns3: Add vport alive state checking support") Signed-off-by:
-
Peng Li authored
HNS3 VF driver support NIC and Roce, hdev stores NIC handle and Roce handle, should use correct parameter for container_of. Signed-off-by:
-
Huazhong Tan authored
While hclge_init_umv_space() failed in the hclge_init_ae_dev(), we should undo all the operation which has been done successfully, the last success operation maybe hclge_mac_mdio_config(), so if hclge_init_umv_space() failed, we also need to undo it. Fixes: 288475b2ad01 ("{topost} net: hns3: refine umv space allocation") Signed-off-by: -
Jian Shen authored
The rss result is more uniform when use recommended hash key from microsoft, instead of the one generated by netdev_rss_key_fill(). Also using hash algorithm "xor" is better than "toeplitz". This patch modifies the default hash key and hash algorithm. Signed-off-by:
-
Huazhong Tan authored
When the driver is unloading, if a global reset occurs, unmap_ring_from_vector() in the hns3_nic_uninit_vector_data() will fail, and hns3_nic_uninit_vector_data() just return. There may be some netif_napi_del() not be done. Since hardware will unmap all ring while resetting, so hns3_nic_uninit_vector_data() should ignore this error, and do the rest uninitialization. Fixes: 76ad4f0e ("net: hns3: Add support of HNS3 Ethernet Driver for hip08 SoC") Signed-off-by:
-
Huazhong Tan authored
When the driver is unloading, if there is a calling of ndo_open occurs between phy_disconnect() and unregister_netdev(), it will end up causing the kernel to eventually hit a NULL deref: [14942.417828] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000048 [14942.529878] Mem abort info: [14942.551166] ESR = 0x96000006 [14942.567070] Exception class = DABT (current EL), IL = 32 bits [14942.623081] SET = 0, FnV = 0 [14942.639112] EA = 0, S1PTW = 0 [14942.643628] Data abort info: [14942.659227] ISV = 0, ISS = 0x00000006 [14942.674870] CM = 0, WnR = 0 [14942.679449] user pgtable: 4k pages, 48-bit VAs, pgdp = 00000000224ad6ad [14942.695595] [0000000000000048] pgd=00000021e6673003, pud=00000021dbf01003, pmd=0000000000000000 [14942.723163] Internal error: Oops: 96000006 [#1] PREEMPT SMP [14942.729358] Modules linked in: hns3(O) hclge(O) pv680_mii(O) hnae3(O) [last unloaded: hclge] [14942.738907] CPU: 1 PID: 26629 Comm: kworker/u4:13 Tainted: G O 4.18.0-rc1-12928-ga960791-dirty #145 [14942.749491] Hardware name: Huawei Technologies Co., Ltd. D05/D05, BIOS Hi1620 FPGA TB BOOT BIOS B763 08/17/2018 [14942.760392] Workqueue: events_power_efficient phy_state_machine [14942.766644] pstate: 80c00009 (Nzcv daif +PAN +UAO) [14942.771918] pc : test_and_set_bit+0x18/0x38 [14942.776589] lr : netif_carrier_off+0x24/0x70 [14942.781033] sp : ffff0000121abd20 [14942.784518] x29: ffff0000121abd20 x28: 0000000000000000 [14942.790208] x27: ffff0000164d3cd8 x26: ffff8021da68b7b8 [14942.795832] x25: 0000000000000000 x24: ffff8021eb407800 [14942.801445] x23: 0000000000000000 x22: 0000000000000000 [14942.807046] x21: 0000000000000001 x20: 0000000000000000 [14942.812672] x19: 0000000000000000 x18: ffff000009781708 [14942.818284] x17: 00000000004970e8 x16: ffff00000816ad48 [14942.823900] x15: 0000000000000000 x14: 0000000000000008 [14942.829528] x13: 0000000000000000 x12: 0000000000000f65 [14942.835149] x11: 0000000000000001 x10: 00000000000009d0 [14942.840753] x9 : ffff0000121abaa0 x8 : 0000000000000000 [14942.846360] x7 : ffff000009781708 x6 : 0000000000000003 [14942.851970] x5 : 0000000000000020 x4 : 0000000000000004 [14942.857575] x3 : 0000000000000002 x2 : 0000000000000001 [14942.863180] x1 : 0000000000000048 x0 : 0000000000000000 [14942.868875] Process kworker/u4:13 (pid: 26629, stack limit = 0x00000000c909dbf3) [14942.876464] Call trace: [14942.879200] test_and_set_bit+0x18/0x38 [14942.883376] phy_link_change+0x38/0x78 [14942.887378] phy_state_machine+0x3dc/0x4f8 [14942.891968] process_one_work+0x158/0x470 [14942.896223] worker_thread+0x50/0x470 [14942.900219] kthread+0x104/0x130 [14942.903905] ret_from_fork+0x10/0x1c [14942.907755] Code: d2800022 8b400c21 f9800031 9ac32044 (c85f7c22) [14942.914185] ---[ end trace 968c9e12eb740b23 ]--- So this patch fixes it by modifying the timing to do phy_connect_direct() and phy_disconnect(). Fixes: 256727da ("net: hns3: Add MDIO support to HNS3 Ethernet driver for hip08 SoC") Signed-off-by:
-
Yunsheng Lin authored
When the VF shares the same TC config as PF, the business running on PF and VF must have samiliar module. For simplicity, we are not considering VF sharing the same tc configuration as PF use case, so this patch removes the support of TC configuration from VF and forcing VF to just use single TC. Signed-off-by:
Yunsheng Lin <linyunsheng@huawei.com> Signed-off-by:
-
Huazhong Tan authored
hnae3_register_ae_dev() may fail, and it should return a error code to its caller, so change hnae3_register_ae_dev() return type to int. Also, when hnae3_register_ae_dev() return error, hns3_probe() should do some error handling and return the error code. Signed-off-by:
-
Peng Li authored
dev_close() stop the netdev and the service base on the netdev will stop. But ndev->netdev_ops->ndo_stop() may only stop HW and stack queue, the service base on the netdev can still work. Fixes: 5668abda ("net: hns3: add support for set_ringparam") Signed-off-by:
-
Jian Shen authored
In original codes, the .get_regs_len and .get_regs were missed assigned. This patch fixes it. Fixes: 1600c3e5 ("net: hns3: Support "ethtool -d" for HNS3 VF driver") Signed-off-by:
-
liyongxin authored
Union l3_hdr_info and l4_hdr_info have already been defined in the hns3_enet.h, so it is unnecessary to define them elsewhere. This patch removes the redundant definition, and reuses the one defined in the hns3_enet.h. Signed-off-by:
liyongxin <liyongxin1@huawei.com> Signed-off-by:
-
David S. Miller authored
Greg Ungerer says: ==================== net: dsa: mt7530: support MT7530 in the MT7621 SoC This is the fourth version of a patch series supporting the MT7530 switch as used in the MediaTek MT7621 SoC. Unlike the MediaTek MT7623 the MT7621 is built around a dual core MIPS CPU architecture. But inside it uses basically the same 7530 switch. This series resolves all issues I had with previous versions, and I can now reliably use the driver on a 7621 SoC platform. These patches were generated against linux-5.0-rc4. The first patch enables support for the existing kernel mediatek ethernet driver on the MT7621 SoC. This support is from Bjørn Mork, with an update and fix by me. Using this driver fixed a number of problems I had (TX checksums, large RX packet drop) over the staging driver (drivers/staging/mt7621-eth). Patch 2 modifies the mt7530 DSA driver to support the 7530 switch as implemented in the Mediatek MT7621 SoC. The last patch updates the devicetree bindings to reflect the new support in the mt7530 driver. There is no real dependencies between the patches, so they can be taken independantly. Creating a new binding for the MT7621 seems like the only viable approach to distinguish between a stand alone 7530 switch, the silicon module in the MT7623 SoC and the silicon in the MT7621. Certainly the 7530 ID register in the MT7623 and MT7621 returns the same value, "0x7530001". Looking at the mt7530.c DSA driver it might make some sense to convert the existing "mediatek,mcm" binding to something like "mediatek,mt7623" to be consistent with this new MT7621 support. As far as I can tell this is the intention of this binding. ==================== Signed-off-by: -
Greg Ungerer authored
Add devicetree binding to support the compatible mt7530 switch as used in the MediaTek MT7621 SoC. Signed-off-by:
Greg Ungerer <gerg@kernel.org> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Reviewed-by:
Florian Fainelli <f.fainelli@gmail.com> Acked-by:
Sean Wang <sean.wang@kernel.org> Signed-off-by:
-
Greg Ungerer authored
The MediaTek MT7621 SoC device contains a 7530 switch, and the existing linux kernel 7530 DSA switch driver can be used with it. The bulk of the changes required stem from the 7621 having different regulator and pad setup. The existing setup of these in the 7530 driver appears to be very specific to its implemtation in the Mediatek 7623 SoC. (Not entirely surprising given the 7623 is a quad core ARM based SoC, and the 7621 is a dual core, dual thread MIPS based SoC). Create a new devicetree type, "mediatek,mt7621", to support the 7530 switch in the 7621 SoC. There appears to be no usable ID register to distinguish it from a 7530 in other hardware at runtime. This is used to carry out the appropriate configuration and setup. Signed-off-by:
-
Bjørn Mork authored
The Mediatek MT7621 SoC contains the same ethernet hardware module as used on a number of other MediaTek SoC parts. There are some minor differences to deal with but we can use the same driver to support them all. This patch is based on work by Bjørn Mork <bjorn@mork.no>, and his original patch is at: https://github.com/bmork/LEDE/commit/3293bc63f5461ca1eb0bbc4ed90145335e7e3404 There is an additional compatible devicetree type added, and the primary change to the code required is to support a single interrupt (for both RX and TX interrupts). Signed-off-by:
Bjørn Mork <bjorn@mork.no> [gerg@kernel.org: rebase to mainline and irq handler fix] Signed-off-by:
-
David S. Miller authored
Ido Schimmel says: ==================== mlxsw: spectrum_acl: Include delta bits into hashtable key The Spectrum-2 ASIC allows multiple rules to use the same mask provided that the difference between their masks is small enough (up to 8 consecutive delta bits). A more detailed explanation is provided in merge commit 756cd366 ("Merge branch 'mlxsw-Introduce-algorithmic-TCAM-support'"). These delta bits are part of the rule's key and therefore rules that only differ in their delta bits can be inserted with the same A-TCAM mask. In case two rules share the same key and only differ in their priority, then the second will spill to the C-TCAM. Current code does not take the delta bits into account when checking for duplicate rules, which leads to unnecessary spillage to the C-TCAM. This may result in reduced scale and performance. Patch #1 includes the delta bits in the rule's key to avoid the above mentioned problem. Patch #2 adds a tracepoint when a rule is inserted into the C-TCAM. Patches #3-#5 add test cases to make sure unnecessary spillage into the C-TCAM does not occur. ==================== Signed-off-by:
-
