- 01 Dec, 2019 40 commits
-
-
Suganath Prabu authored
[ Upstream commit 6cd1bc7b ] If EEDPTagMode field in manufacturing page11 is set then unset it. This is needed to fix a hardware bug only in SAS3/SAS2 cards. So, skipping EEDPTagMode changes in Manufacturing page11 for SAS 3.5 controllers. Signed-off-by:
Suganath Prabu <suganath-prabu.subramani@broadcom.com> Reviewed-by:
Bjorn Helgaas <bhelgaas@google.com> Reviewed-by:
Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Suganath Prabu authored
[ Upstream commit 9029a725 ] This is to fix SYNC CACHE and START STOP command failures with DID_NO_CONNECT during driver unload. In driver's IO submission patch (i.e. in driver's .queuecommand()) driver won't allow any SCSI commands to the IOC when ioc->remove_host flag is set and hence SYNC CACHE commands which are issued to the target drives (where write cache is enabled) during driver unload time is failed with DID_NO_CONNECT status. Now modified the driver to allow SYNC CACHE and START STOP commands to IOC, even when remove_host flag is set. Signed-off-by:
-
Florian Fainelli authored
[ Upstream commit c04a17d2 ] We are binding to the PHY using the SF2 slave MDIO bus that we create, binding involves reading the PHY's MII_PHYSID1/2 which won't be possible if the PHY is turned off. Temporarily turn it on/off for the bus probing to succeeed. This fixes unbind/bind problems where the port connecting to that PHY would be in error since it could not connect to it. Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Shaokun Zhang authored
[ Upstream commit 7d129adf ] RT_TRACE shows REG_MCUFWDL value as a decimal value with a '0x' prefix, which is somewhat misleading. Fix it to print hexadecimal, as was intended. Cc: Ping-Ke Shih <pkshih@realtek.com> Cc: Kalle Valo <kvalo@codeaurora.org> Signed-off-by:
Shaokun Zhang <zhangshaokun@hisilicon.com> Acked-by:
Ping-Ke Shih <pkshih@realtek.com> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org> Signed-off-by:
-
Dan Carpenter authored
[ Upstream commit 3d39e1bb ] It looks like we wanted to print a maximum of BSSList_rid.ssidLen bytes of the ssid, but we accidentally use "%*s" (width) instead of "%.*s" (precision) so if the ssid doesn't have a NUL terminator this could lead to an overflow. Static analysis. Not tested. Fixes: e174961c ("net: convert print_mac to %pM") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Ali MJ Al-Nasrawy authored
[ Upstream commit 96fca788 ] This message greatly spams the log under heavy Tx of frames with BK access class which is especially true when operating as AP. It is also not informative as the "agg'ablity" of TIDs are set once and never change. Fix this by logging only in debug mode. Signed-off-by:
Ali MJ Al-Nasrawy <alimjalnasrawy@gmail.com> Signed-off-by:
-
Gustavo A. R. Silva authored
[ Upstream commit 307b00c5 ] Add missing break statement in order to prevent the code from falling through to the default case. Fixes: 26f1fad2 ("New driver: rtl8xxxu (mac80211)") Signed-off-by:
Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by:
-
Christophe JAILLET authored
[ Upstream commit 3419348a ] We return 0 unconditionally at the end of 'wlcore_vendor_cmd_smart_config_start()'. However, 'ret' is set to some error codes in several error handling paths and we already return some error codes at the beginning of the function. Return 'ret' instead to propagate the error code. Fixes: 80ff8063 ("wlcore: handle smart config vendor commands") Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by:
-
Brian Norris authored
[ Upstream commit 82e60d92 ] Similar to regulator error handling, we should only start tearing down the 'i - 1' clock when clock 'i' fails to enable. Otherwise, we might end up with an unbalanced clock, where we never successfully enabled the clock, but we try to disable it anyway. Fixes: a6a793f9 ("ath10k: vote for hardware resources for WCN3990") Signed-off-by:
Brian Norris <briannorris@chromium.org> Reviewed-by:
Douglas Anderson <dianders@chromium.org> Signed-off-by:
-
Lior David authored
[ Upstream commit dc57731d ] Switch from spin_lock to spin_lock_irqsave, because wmi_ev_lock is used inside interrupt handler. Signed-off-by:
Lior David <liord@codeaurora.org> Signed-off-by:
Maya Erez <merez@codeaurora.org> Signed-off-by:
-
Maya Erez authored
[ Upstream commit 7c69709f ] RGF_CAF_ICR register location has changed in Talyn-MB. Add RGF_CAF_ICR_TALYN_MB to support the new address. Signed-off-by:
-
Maya Erez authored
[ Upstream commit 04de1501 ] L2 RX status errors should not be treated as a bitmap and the actual error values should be checked. Print L2 errors as wil_err_ratelimited for easier debugging when such errors occurs. Signed-off-by:
-
Ahmad Masri authored
[ Upstream commit 84ec040d ] All wil6210 device memory access should be 4 bytes aligned. In io blob wil6210 did not force alignment for read function, this caused alignment fault on some platforms. Fixing that by accessing all 4 lower bytes and return to host the requested data. Signed-off-by:
Ahmad Masri <amasri@codeaurora.org> Signed-off-by:
-
Arnd Bergmann authored
[ Upstream commit 7e17916b ] Note: this patch fixes a problem in a feature outside of btrfs ("kernel hacking: add a config option to disable compiler auto-inlining") and is applied ahead of time due to cross-subsystem dependencies. On 32-bit ARM with gcc-8, I see a link error with the addition of the CONFIG_NO_AUTO_INLINE option: fs/btrfs/super.o: In function `btrfs_statfs': super.c:(.text+0x67b8): undefined reference to `__aeabi_uldivmod' super.c:(.text+0x67fc): undefined reference to `__aeabi_uldivmod' super.c:(.text+0x6858): undefined reference to `__aeabi_uldivmod' super.c:(.text+0x6920): undefined reference to `__aeabi_uldivmod' super.c:(.text+0x693c): undefined reference to `__aeabi_uldivmod' fs/btrfs/super.o:super.c:(.text+0x6958): more undefined references to `__aeabi_uldivmod' follow So far this is the only file that shows the behavior, so I'd propose to just work around it by marking the functions as 'static inline' that normally get inlined here. The reference to __aeabi_uldivmod comes from a div_u64() which has an optimization for a constant division that uses a straight '/' operator when the result should be known to the compiler. My interpretation is that as we turn off inlining, gcc still expects the result to be constant but fails to use that constant value. Link: https://lkml.kernel.org/r/20181103153941.1881966-1-arnd@arndb.deReviewed-by:
Nikolay Borisov <nborisov@suse.com> Reviewed-by:
Changbin Du <changbin.du@gmail.com> Signed-off-by:
Arnd Bergmann <arnd@arndb.de> [ add the note ] Signed-off-by:
David Sterba <dsterba@suse.com> Signed-off-by:
-
Chiranjeevi Rapolu authored
[ Upstream commit 35629182 ] Check for possible null pointer to avoid crash. Signed-off-by:
Chiranjeevi Rapolu <chiranjeevi.rapolu@intel.com> Signed-off-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by:
-
Nickhu authored
[ Upstream commit 9aaafac8 ] There two bitfield bug for perfomance counter in bitfield.h: PFM_CTL_offSEL1 21 --> 16 PFM_CTL_offSEL2 27 --> 22 This commit fix it. Signed-off-by:
Nickhu <nickhu@andestech.com> Acked-by:
Greentime Hu <greentime@andestech.com> Signed-off-by:
-
Taehee Yoo authored
[ Upstream commit 97adadda ] When iptables command is executed, ip_{set/get}sockopt() try to upload bpfilter.ko if bpfilter is enabled. if it couldn't find bpfilter.ko, command is failed. bpfilter.ko is generated if CONFIG_BPFILTER_UMH is enabled. ip_{set/get}sockopt() only checks CONFIG_BPFILTER. So that if CONFIG_BPFILTER is enabled and CONFIG_BPFILTER_UMH is disabled, iptables command is always failed. test config: CONFIG_BPFILTER=y # CONFIG_BPFILTER_UMH is not set test command: %iptables -L iptables: No chain/target/match by that name. Fixes: d2ba09c1 ("net: add skeleton of bpfilter kernel module") Signed-off-by:
Taehee Yoo <ap420073@gmail.com> Signed-off-by:
-
Andrei Vagin authored
[ Upstream commit c34c1287 ] IPPROTO_RAW isn't registred as an inet protocol, so inet_protos[protocol] is always NULL for it. Cc: Cyrill Gorcunov <gorcunov@gmail.com> Cc: Xin Long <lucien.xin@gmail.com> Fixes: bf2ae2e4 ("sock_diag: request _diag module only when the family or proto has been registered") Signed-off-by:
Andrei Vagin <avagin@gmail.com> Reviewed-by:
Cyrill Gorcunov <gorcunov@gmail.com> Signed-off-by:
-
Richard Guy Briggs authored
[ Upstream commit ea956d8b ] Empty executable arguments were being skipped when printing out the list of arguments in an EXECVE record, making it appear they were somehow lost. Include empty arguments as an itemized empty string. Reproducer: autrace /bin/ls "" "/etc" ausearch --start recent -m execve -i | grep EXECVE type=EXECVE msg=audit(10/03/2018 13:04:03.208:1391) : argc=3 a0=/bin/ls a2=/etc With fix: type=EXECVE msg=audit(10/03/2018 21:51:38.290:194) : argc=3 a0=/bin/ls a1= a2=/etc type=EXECVE msg=audit(1538617898.290:194): argc=3 a0="/bin/ls" a1="" a2="/etc" Passes audit-testsuite. GH issue tracker at https://github.com/linux-audit/audit-kernel/issues/99Signed-off-by:
Richard Guy Briggs <rgb@redhat.com> [PM: cleaned up the commit metadata] Signed-off-by:
Paul Moore <paul@paul-moore.com> Signed-off-by:
-
Florian Fainelli authored
[ Upstream commit fb14ada1 ] When the kernel is built with CONFIG_THUMB2_KERNEL we would set the kernel's resume entry point to be a function that is already built as Thumb-2 code while the boot agent doing the resume is in ARM mode, so this does not work. There is a header label defined: cpu_resume_arm which we can use to do the switching for us. Fixes: 0b741b82 ("soc: bcm: brcmstb: Add support for S2/S3/S5 suspend states (ARM)") Signed-off-by:
-
Icenowy Zheng authored
[ Upstream commit 859783d1 ] In the user manual of A64 SoC, the bit 22 and 23 of pll-mipi control register is called "LDO{1,2}_EN", and according to the BSP source code from Allwinner , the LDOs are enabled during the clock's enabling process. The clock failed to generate output if the two LDOs are not enabled. Add the two bits to the clock's gate bits, so that the LDOs are enabled when the PLL is enabled. Fixes: c6a06374 ("clk: sunxi-ng: Add A64 clocks") Signed-off-by:
Icenowy Zheng <icenowy@aosc.io> Signed-off-by:
Maxime Ripard <maxime.ripard@bootlin.com> Signed-off-by:
-
Leonard Crestez authored
[ Upstream commit 1ad9fb75 ] Bindings for "fixed-regulator" only explicitly support "gpio" property, not "gpios". Fix by correcting the property name. The enet PHYs on imx6sx-sdb needs to be explicitly reset after a power cycle, this can be handled by the phy-reset-gpios property. Sadly this is not handled on suspend: the fec driver turns phy-supply off but doesn't assert phy-reset-gpios again on resume. Since additional phy-level work is required to support powering off the phy in suspend fix the problem by just marking the regulator as "boot-on" "always-on" so that it's never turned off. This behavior is equivalent to older releases. Keep the phy-reset-gpios property on fec anyway because it is a correct description of board design. This issue was exposed by commit efdfeb07 ("regulator: fixed: Convert to use GPIO descriptor only") which causes the "gpios" property to also be parsed. Before that commit the "gpios" property had no effect, PHY reset was only handled in the the bootloader. This fixes linux-next boot failures previously reported here: https://lore.kernel.org/patchwork/patch/982437/#1177900 https://lore.kernel.org/patchwork/patch/994091/#1178304Signed-off-by:
Leonard Crestez <leonard.crestez@nxp.com> Signed-off-by:
Shawn Guo <shawnguo@kernel.org> Signed-off-by:
-
Arnd Bergmann authored
[ Upstream commit a277d516 ] When CONFIG_CC_OPTIMIZE_FOR_DEBUGGING is enabled, the compiler fails to optimize out a dead code path, which leads to a link failure: net/openvswitch/conntrack.o: In function `ovs_ct_set_labels': conntrack.c:(.text+0x2e60): undefined reference to `nf_connlabels_replace' In this configuration, we can take a shortcut, and completely remove the contrack label code. This may also help the regular optimization. Signed-off-by:
-
Valentin Schneider authored
[ Upstream commit 3f130a37 ] When load_balance() fails to move some load because of task affinity, we end up increasing sd->balance_interval to delay the next periodic balance in the hopes that next time we look, that annoying pinned task(s) will be gone. However, idle_balance() pays no attention to sd->balance_interval, yet it will still lead to an increase in balance_interval in case of pinned tasks. If we're going through several newidle balances (e.g. we have a periodic task), this can lead to a huge increase of the balance_interval in a very small amount of time. To prevent that, don't increase the balance interval when going through a newidle balance. This is a similar approach to what is done in commit 58b26c4c ("sched: Increment cache_nice_tries only on periodic lb"), where we disregard newidle balance and rely on periodic balance for more stable results. Signed-off-by:
Valentin Schneider <valentin.schneider@arm.com> Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Dietmar.Eggemann@arm.com Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: patrick.bellasi@arm.com Cc: vincent.guittot@linaro.org Link: http://lkml.kernel.org/r/1537974727-30788-2-git-send-email-valentin.schneider@arm.comSigned-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
Peter Zijlstra authored
[ Upstream commit 993f0b05 ] With the addition of the NUMA identity level, we increased @level by one and will run off the end of the array in the distance sort loop. Fixed: 051f3ca0 ("sched/topology: Introduce NUMA identity node sched domain") Signed-off-by:
-
Eric Dumazet authored
[ Upstream commit fe60faa5 ] Before calling dev_hard_start_xmit(), upper layers tried to cook optimal skb list based on BQL budget. Problem is that GSO packets can end up comsuming more than the BQL budget. Breaking the loop is not useful, since requeued packets are ahead of any packets still in the qdisc. It is also more expensive, since next TX completion will push these packets later, while skbs are not in cpu caches. It is also a behavior difference with TSO packets, that can break the BQL limit by a large amount. Note that drivers should use __netdev_tx_sent_queue() in order to have optimal xmit_more support, and avoid useless atomic operations as shown in the following patch. Signed-off-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
-
Larry Chen authored
[ Upstream commit 6194ae42 ] ocfs2_defrag_extent() might leak allocated clusters. When the file system has insufficient space, the number of claimed clusters might be less than the caller wants. If that happens, the original code might directly commit the transaction without returning clusters. This patch is based on code in ocfs2_add_clusters_in_btree(). [akpm@linux-foundation.org: include localalloc.h, reduce scope of data_ac] Link: http://lkml.kernel.org/r/20180904041621.16874-3-lchen@suse.comSigned-off-by:
Larry Chen <lchen@suse.com> Reviewed-by:
Andrew Morton <akpm@linux-foundation.org> Cc: Mark Fasheh <mark@fasheh.com> Cc: Joel Becker <jlbec@evilplan.org> Cc: Junxiao Bi <junxiao.bi@oracle.com> Cc: Joseph Qi <jiangqi903@gmail.com> Cc: Changwei Ge <ge.changwei@h3c.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Changwei Ge authored
[ Upstream commit cf76c785 ] ocfs2_read_blocks() and ocfs2_read_blocks_sync() are both used to read several blocks from disk. Currently, the input argument *bhs* can be NULL or NOT. It depends on the caller's behavior. If the function fails in reading blocks from disk, the corresponding bh will be assigned to NULL and put. Obviously, above process for non-NULL input bh is not appropriate. Because the caller doesn't even know its bhs are put and re-assigned. If buffer head is managed by caller, ocfs2_read_blocks and ocfs2_read_blocks_sync() should not evaluate it to NULL. It will cause caller accessing illegal memory, thus crash. Link: http://lkml.kernel.org/r/HK2PR06MB045285E0F4FBB561F9F2F9B3D5680@HK2PR06MB0452.apcprd06.prod.outlook.comSigned-off-by:
Changwei Ge <ge.changwei@h3c.com> Reviewed-by:
Guozhonghua <guozhonghua@h3c.com> Cc: Mark Fasheh <mark@fasheh.com> Cc: Joel Becker <jlbec@evilplan.org> Cc: Junxiao Bi <junxiao.bi@oracle.com> Cc: Joseph Qi <jiangqi903@gmail.com> Cc: Changwei Ge <ge.changwei@h3c.com> Signed-off-by:
-
Changwei Ge authored
[ Upstream commit 9e985787 ] When -EIOCBQUEUED returns, it means that aio_complete() will be called from dio_complete(), which is an asynchronous progress against write_iter. Generally, IO is a very slow progress than executing instruction, but we still can't take the risk to access a freed iocb. And we do face a BUG crash issue. Using the crash tool, iocb is obviously freed already. crash> struct -x kiocb ffff881a350f5900 struct kiocb { ki_filp = 0xffff881a350f5a80, ki_pos = 0x0, ki_complete = 0x0, private = 0x0, ki_flags = 0x0 } And the backtrace shows: ocfs2_file_write_iter+0xcaa/0xd00 [ocfs2] aio_run_iocb+0x229/0x2f0 do_io_submit+0x291/0x540 SyS_io_submit+0x10/0x20 system_call_fastpath+0x16/0x75 Link: http://lkml.kernel.org/r/1523361653-14439-1-git-send-email-ge.changwei@h3c.comSigned-off-by:
-
Guozhonghua authored
[ Upstream commit 21158ca8 ] During one dead node's recovery by other node, quota recovery work will be queued. We should avoid calling quota when it is not supported, so check the quota flags. Link: http://lkml.kernel.org/r/71604351584F6A4EBAE558C676F37CA401071AC9FB@H3CMLB12-EX.srv.huawei-3com.comSigned-off-by:
Jan Kara <jack@suse.cz> Cc: Mark Fasheh <mark@fasheh.com> Cc: Joel Becker <jlbec@evilplan.org> Cc: Junxiao Bi <junxiao.bi@oracle.com> Cc: Joseph Qi <jiangqi903@gmail.com> Cc: Changwei Ge <ge.changwei@h3c.com> Signed-off-by:
-
Roman Gushchin authored
[ Upstream commit e68599a3 ] Mike Galbraith reported a regression caused by the commit 9b6f7e16 ("mm: rework memcg kernel stack accounting") on a system with "cgroup_disable=memory" boot option: the system panics with the following stack trace: BUG: unable to handle kernel NULL pointer dereference at 00000000000000f8 PGD 0 P4D 0 Oops: 0002 [#1] PREEMPT SMP PTI CPU: 0 PID: 1 Comm: systemd Not tainted 4.19.0-preempt+ #410 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20180531_142017-buildhw-08.phx2.fed4 RIP: 0010:page_counter_try_charge+0x22/0xc0 Code: 41 5d c3 c3 0f 1f 40 00 0f 1f 44 00 00 48 85 ff 0f 84 a7 00 00 00 41 56 48 89 f8 49 89 fe 49 Call Trace: try_charge+0xcb/0x780 memcg_kmem_charge_memcg+0x28/0x80 memcg_kmem_charge+0x8b/0x1d0 copy_process.part.41+0x1ca/0x2070 _do_fork+0xd7/0x3d0 do_syscall_64+0x5a/0x180 entry_SYSCALL_64_after_hwframe+0x49/0xbe The problem occurs because get_mem_cgroup_from_current() returns the NULL pointer if memory controller is disabled. Let's check if this is a case at the beginning of memcg_kmem_charge() and just return 0 if mem_cgroup_disabled() returns true. This is how we handle this case in many other places in the memory controller code. Link: http://lkml.kernel.org/r/20181029215123.17830-1-guro@fb.com Fixes: 9b6f7e16 ("mm: rework memcg kernel stack accounting") Signed-off-by:
Roman Gushchin <guro@fb.com> Reported-by:
Mike Galbraith <efault@gmx.de> Acked-by:
Rik van Riel <riel@surriel.com> Acked-by:
Michal Hocko <mhocko@suse.com> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: Vladimir Davydov <vdavydov.dev@gmail.com> Cc: Shakeel Butt <shakeelb@google.com> Signed-off-by:
-
Len Brown authored
[ Upstream commit 34041551 ] turbostat recently gained a feature adding APIC and X2APIC columns. While they are disabled by-default, they are enabled with --debug or when explicitly requested, eg. $ sudo turbostat --quiet --show Package,Node,Core,CPU,APIC,X2APIC date But these columns erroneously showed zeros on AMD hardware. This patch corrects the APIC and X2APIC [sic] columns on AMD. Signed-off-by:
Len Brown <len.brown@intel.com> Signed-off-by:
-
Victor Kamensky authored
[ Upstream commit 98356eb0 ] After 'a66649da arm64: fix vdso-offsets.h dependency' if one will try to build .i file in case of external kernel module, build fails complaining that prepare0 target is missing. This issue came up with SystemTap when it tries to build variety of .i files for its own generated kernel modules trying to figure given kernel features/capabilities. The issue is that prepare0 is defined in top level Makefile only if KBUILD_EXTMOD is not defined. .i file rule depends on prepare and in case KBUILD_EXTMOD defined top level Makefile contains empty rule for prepare. But after mentioned commit arch/arm64/Makefile would introduce dependency on prepare0 through its own prepare target. Fix it to put proper ifdef KBUILD_EXTMOD around code introduced by mentioned commit. It matches what top level Makefile does. Acked-by:
Kevin Brodsky <kevin.brodsky@arm.com> Signed-off-by:
Victor Kamensky <kamensky@cisco.com> Signed-off-by:
Catalin Marinas <catalin.marinas@arm.com> Signed-off-by:
-
Keith Busch authored
[ Upstream commit 9fe5c59f ] The nvme pci driver had been adding its CMB resource to the P2P DMA subsystem everytime on on a controller reset. This results in the following warning: ------------[ cut here ]------------ nvme 0000:00:03.0: Conflicting mapping in same section WARNING: CPU: 7 PID: 81 at kernel/memremap.c:155 devm_memremap_pages+0xa6/0x380 ... Call Trace: pci_p2pdma_add_resource+0x153/0x370 nvme_reset_work+0x28c/0x17b1 [nvme] ? add_timer+0x107/0x1e0 ? dequeue_entity+0x81/0x660 ? dequeue_entity+0x3b0/0x660 ? pick_next_task_fair+0xaf/0x610 ? __switch_to+0xbc/0x410 process_one_work+0x1cf/0x350 worker_thread+0x215/0x3d0 ? process_one_work+0x350/0x350 kthread+0x107/0x120 ? kthread_park+0x80/0x80 ret_from_fork+0x1f/0x30 ---[ end trace f7ea76ac6ee72727 ]--- nvme nvme0: failed to register the CMB This patch fixes this by registering the CMB with P2P only once. Signed-off-by:
Keith Busch <keith.busch@intel.com> Reviewed-by:
Logan Gunthorpe <logang@deltatee.com> Signed-off-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
Jens Axboe <axboe@kernel.dk> Signed-off-by:
-
Michael Kelley authored
[ Upstream commit 57f01796 ] IRQ_MATRIX_SIZE is the number of longs needed for a bitmap, multiplied by the size of a long, yielding a byte count. But it is used to size an array of longs, which is way more memory than is needed. Change IRQ_MATRIX_SIZE so it is just the number of longs needed and the arrays come out the correct size. Fixes: 2f75d9e1 ("genirq: Implement bitmap matrix allocator") Signed-off-by:
Michael Kelley <mikelley@microsoft.com> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Cc: KY Srinivasan <kys@microsoft.com> Link: https://lkml.kernel.org/r/1541032428-10392-1-git-send-email-mikelley@microsoft.comSigned-off-by:
-
Dave Jiang authored
[ Upstream commit 7756e2b5 ] ndev_vec_mask() should be returning u64 mask value instead of int. Otherwise the mask value returned can be incorrect for larger vectors. Fixes: e26a5843 ("NTB: Split ntb_hw_intel and ntb_transport drivers") Signed-off-by:
Dave Jiang <dave.jiang@intel.com> Tested-by:
Lucas Van <lucas.van@intel.com> Signed-off-by:
Jon Mason <jdmason@kudzu.us> Signed-off-by:
-
Jon Mason authored
[ Upstream commit a861594b ] The tx_time should be in usecs (according to the comment above the variable), but the setting of the timer during the rearming is done in msecs. Change it to match the expected units. Fixes: e74bfeed ("NTB: Add flow control to the ntb_netdev") Suggested-by:
Gerd W. Haeussler <gerd.haeussler@cesys-it.com> Signed-off-by:
-
Huazhong Tan authored
[ Upstream commit 1c124938 ] When there is a PHY, the driver needs to complete some operations through MDIO during reset reinitialization, so HCLGE_STATE_CMD_DISABLE is more suitable than HCLGE_STATE_RST_HANDLING to prevent the MDIO operation from being sent during the hardware reset. Fixes: b50ae26c ("net: hns3: never send command queue message to IMP when reset) Signed-off-by:
Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by:
-
Huazhong Tan authored
[ Upstream commit 6d71ec6c ] The HEAD pointer of the hardware command queue maybe equal to the command queue's next_to_use in the driver, so that does not belong to the invalid HEAD pointer, since the hardware may not process the command in time, causing the HEAD pointer to be too late to update. The variables' name in this function is unreadable, so give them a more readable one. Fixes: 3ff50490 ("net: hns3: fix a dead loop in hclge_cmd_csq_clean") Signed-off-by:
-
Huazhong Tan authored
[ Upstream commit 0d441140 ] The current driver supports handling two vector0 interrupts, reset and mailbox. When the hardware reports an interrupt of another type of interrupt source, if the driver does not process the interrupt, but enables the interrupt, the hardware will repeatedly report the unknown interrupt. Therefore, the driver enables the vector0 interrupt after clearing the known type of interrupt source. Other conditions are not enabled. Fixes: cd8c5c26 ("net: hns3: Fix for hclge_reset running repeatly problem") Signed-off-by:
-
