- 11 10月, 2017 1 次提交
-
-
When figuring out the size of the DIMMs and the cluster mode is SNC2 or SNC4 the current algorithm ignores the contribution of some of the channels resulting in EDAC never knowing of the existence of some DIMMs attached to such channels (thus sysfs is not populated). Instead of selectively iterating from 0 to interlv_ways when looking for all the participants in the interleave, do an exhaustive search and iterate from 0 to KNL_MAX_CHANNELS. The algorithm is already smart enough to consider participants only one time. This works fine in all KNL cluster modes and even when there are missing DIMMs as the contribution of those channels is 0. Signed-off-by: NLuis Felipe Sandoval Castro <luis.felipe.sandoval.castro@intel.com> Acked-by: NTony Luck <tony.luck@intel.com> Cc: Mauro Carvalho Chehab <mchehab@kernel.org> Cc: arozansk@redhat.com Cc: linux-edac <linux-edac@vger.kernel.org> Cc: qiuxu.zhuo@intel.com Link: http://lkml.kernel.org/r/1506606882-90521-1-git-send-email-luis.felipe.sandoval.castro@intel.comSigned-off-by: NBorislav Petkov <bp@suse.de>
-
- 29 9月, 2017 1 次提交
-
-
由 Tony Luck 提交于
Large systems separate their PCI busses into segments since the limit of only 256 PCI busses can be too restrictive. Extend this driver to check whether <segment, bus-number> matches when deciding how to group memory controller PCI devices to CPU sockets. Signed-off-by: NTony Luck <tony.luck@intel.com> Cc: Aristeu Rozanski <arozansk@redhat.com> Cc: Charles Rose <charles.rose@dell.com> Cc: Mauro Carvalho Chehab <mchehab@osg.samsung.com> Cc: Qiuxu Zhuo <qiuxu.zhuo@intel.com> Cc: linux-edac <linux-edac@vger.kernel.org> Link: http://lkml.kernel.org/r/f58abfd10bf73c8bc5adc1fe4de7408128b00625.1506358467.git.tony.luck@intel.com [ Make skx_dev.seg an int. ] Signed-off-by: NBorislav Petkov <bp@suse.de>
-
- 27 9月, 2017 3 次提交
-
-
由 Jan Glauber 提交于
The memory controller on ThunderX/OcteonTX systems does not support power management. Therefore remove the suspend/resume callbacks. Signed-off-by: NJan Glauber <jglauber@cavium.com> Cc: David Daney <david.daney@cavium.com> Cc: Jan Glauber <jglauber@cavium.com> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Mauro Carvalho Chehab <mchehab@kernel.org> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Suzuki K Poulose <Suzuki.Poulose@arm.com> Cc: Will Deacon <will.deacon@arm.com> Cc: Zhangshaokun <zhangshaokun@hisilicon.com> Cc: linux-arm-kernel@lists.infradead.org Cc: linux-edac <linux-edac@vger.kernel.org> Cc: linux-mips@linux-mips.org Link: http://lkml.kernel.org/r/20170925123502.17289-2-jglauber@cavium.comSigned-off-by: NBorislav Petkov <bp@suse.de>
-
由 Charles Rose 提交于
Single-rank DIMMs did not get detected on Skylake/Kabylake systems due to wrong limit check. The single rank DIMM check is a simple typo. "0" is a legal value in this field meaning single rank. Signed-off-by: NCharles Rose <charles.rose@dell.com> Cc: Aristeu Rozanski <arozansk@redhat.com> Cc: Mauro Carvalho Chehab <mchehab@kernel.org> Cc: Qiuxu Zhuo <qiuxu.zhuo@intel.com> Cc: linux-edac <linux-edac@vger.kernel.org> Link: http://lkml.kernel.org/r/66df72d327c265fbf92fe25df96daa228a35f076.1506358467.git.tony.luck@intel.com [ Also fix debug message to print number of ranks. ] Signed-off-by: NTony Luck <tony.luck@intel.com> [ Expand commit message. ] Signed-off-by: NBorislav Petkov <bp@suse.de>
-
由 Qiuxu Zhuo 提交于
Yi Zhang reported the following failure on a 2-socket Haswell (E5-2603v3) server (DELL PowerEdge 730xd): EDAC sbridge: Some needed devices are missing EDAC MC: Removed device 0 for sb_edac.c Haswell SrcID#0_Ha#0: DEV 0000:7f:12.0 EDAC MC: Removed device 1 for sb_edac.c Haswell SrcID#1_Ha#0: DEV 0000:ff:12.0 EDAC sbridge: Couldn't find mci handler EDAC sbridge: Couldn't find mci handler EDAC sbridge: Failed to register device with error -19. The refactored sb_edac driver creates the IMC1 (the 2nd memory controller) if any IMC1 device is present. In this case only HA1_TA of IMC1 was present, but the driver expected to find HA1/HA1_TM/HA1_TAD[0-3] devices too, leading to the above failure. The document [1] says the 'E5-2603 v3' CPU has 4 memory channels max. Yi Zhang inserted one DIMM per channel for each CPU, and did random error address injection test with this patch: 4024 addresses fell in TOLM hole area 12715 addresses fell in CPU_SrcID#0_Ha#0_Chan#0_DIMM#0 12774 addresses fell in CPU_SrcID#0_Ha#0_Chan#1_DIMM#0 12798 addresses fell in CPU_SrcID#0_Ha#0_Chan#2_DIMM#0 12913 addresses fell in CPU_SrcID#0_Ha#0_Chan#3_DIMM#0 12674 addresses fell in CPU_SrcID#1_Ha#0_Chan#0_DIMM#0 12686 addresses fell in CPU_SrcID#1_Ha#0_Chan#1_DIMM#0 12882 addresses fell in CPU_SrcID#1_Ha#0_Chan#2_DIMM#0 12934 addresses fell in CPU_SrcID#1_Ha#0_Chan#3_DIMM#0 106400 addresses were injected totally. The test result shows that all the 4 channels belong to IMC0 per CPU, so the server really only has one IMC per CPU. In the 1st page of chapter 2 in datasheet [2], it also says 'E5-2600 v3' implements either one or two IMCs. For CPUs with one IMC, IMC1 is not used and should be ignored. Thus, do not create a second memory controller if the key HA1 is absent. [1] http://ark.intel.com/products/83349/Intel-Xeon-Processor-E5-2603-v3-15M-Cache-1_60-GHz [2] https://www.intel.com/content/dam/www/public/us/en/documents/datasheets/xeon-e5-v3-datasheet-vol-2.pdfReported-and-tested-by: NYi Zhang <yizhan@redhat.com> Signed-off-by: NQiuxu Zhuo <qiuxu.zhuo@intel.com> Cc: Tony Luck <tony.luck@intel.com> Cc: linux-edac <linux-edac@vger.kernel.org> Fixes: e2f747b1 ("EDAC, sb_edac: Assign EDAC memory controller per h/w controller") Link: http://lkml.kernel.org/r/20170913104214.7325-1-qiuxu.zhuo@intel.com [ Massage commit message. ] Signed-off-by: NBorislav Petkov <bp@suse.de>
-
- 25 9月, 2017 5 次提交
-
-
由 Toshi Kani 提交于
Change x86 EDAC platform drivers to verify the module owner at the beginning of their module init functions. This allows them to fail their init immediately when ghes_edac is enabled. Similar change can be made to other edac drivers if necessary. Also, remove ".c" from module names of pnp2_edac, sb_edac, and skx_edac. Signed-off-by: NToshi Kani <toshi.kani@hpe.com> Suggested-by: NBorislav Petkov <bp@alien8.de> Cc: Mauro Carvalho Chehab <mchehab@kernel.org> Cc: Tony Luck <tony.luck@intel.com> Cc: linux-edac <linux-edac@vger.kernel.org> Link: http://lkml.kernel.org/r/20170823225447.15608-6-toshi.kani@hpe.comSigned-off-by: NBorislav Petkov <bp@suse.de>
-
由 Toshi Kani 提交于
Only a single EDAC platform driver can be loaded. When ghes_edac is enabled, an EDAC platform driver still attempts to register itself and fails in edac_mc_add_mc(). Add edac_get_owner() so that EDAC platform drivers can check the owner first. Signed-off-by: NToshi Kani <toshi.kani@hpe.com> Suggested-by: NBorislav Petkov <bp@alien8.de> Cc: Mauro Carvalho Chehab <mchehab@kernel.org> Cc: Tony Luck <tony.luck@intel.com> Cc: linux-edac <linux-edac@vger.kernel.org> Link: http://lkml.kernel.org/r/20170823225447.15608-5-toshi.kani@hpe.com [ Massage commit message. ] Signed-off-by: NBorislav Petkov <bp@suse.de>
-
由 Toshi Kani 提交于
The ghes_edac driver was introduced in 2013 [1], but it has not been enabled by any distro yet. This driver obtains error info from firmware interfaces (APEI), which are not properly implemented on many platforms, as the driver says on load: This EDAC driver relies on BIOS to enumerate memory and get error reports. Unfortunately, not all BIOSes reflect the memory layout correctly. So, the end result of using this driver varies from vendor to vendor. If you find incorrect reports, please contact your hardware vendor to correct its BIOS. To get out from this situation, add a platform check to selectively enable the driver on platforms that are known to have proper APEI firmware implementation. "ghes_edac.force_load=1" skips this platform check. [1]: https://lkml.kernel.org/r/cover.1360931635.git.mchehab@redhat.comSigned-off-by: NToshi Kani <toshi.kani@hpe.com> Cc: Mauro Carvalho Chehab <mchehab@kernel.org> Cc: Tony Luck <tony.luck@intel.com> Cc: linux-acpi@vger.kernel.org Cc: linux-edac <linux-edac@vger.kernel.org> Link: http://lkml.kernel.org/r/20170823225447.15608-4-toshi.kani@hpe.comSigned-off-by: NBorislav Petkov <bp@suse.de>
-
由 Borislav Petkov 提交于
We're enumerating the DIMMs through a DMI walk and since we can't get any more detailed topological information about which DIMMs belong to which memory controller, convert it to a single, logical controller which contains all the DIMMs. The error reporting path from GHES ghes_edac_report_mem_error() doesn't get called in NMI context but add a warning about it to catch any changes in the future as if so, our locking scheme will be insufficient then. Signed-off-by: NBorislav Petkov <bp@suse.de>
-
由 Borislav Petkov 提交于
They're called from builtin code so no need for the exports. Signed-off-by: NBorislav Petkov <bp@suse.de>
-
- 21 9月, 2017 1 次提交
-
-
由 Arvind Yadav 提交于
kasprintf() can fail and we must check its return value. Signed-off-by: NArvind Yadav <arvind.yadav.cs@gmail.com> Cc: linux-edac@vger.kernel.org [ Merged into a single patch, small formatting fixups. ] Signed-off-by: NBorislav Petkov <bp@suse.de>
-
- 17 9月, 2017 2 次提交
-
-
由 Markus Trippelsdorf 提交于
Commit 5620a0d1 ("firmware: delete in-kernel firmware") removed the entire firmware directory. Unfortunately it thereby also removed the support for built-in firmware. This restores the ability to build firmware directly into the kernel by pruning the original Makefile to the necessary minimum. The default for EXTRA_FIRMWARE_DIR is now the standard directory /lib/firmware/. Fixes: 5620a0d1 ("firmware: delete in-kernel firmware") Signed-off-by: NMarkus Trippelsdorf <markus@trippelsdorf.de> Acked-by: NGreg K-H <gregkh@linuxfoundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Ido Schimmel 提交于
The driver doesn't support events from address families other than IPv4 and IPv6, so ignore them. Otherwise, we risk queueing a work item before it's initialized. This can happen in case a VRF is configured when MROUTE_MULTIPLE_TABLES is enabled, as the VRF driver will try to add an l3mdev rule for the IPMR family. Fixes: 65e65ec1 ("mlxsw: spectrum_router: Don't ignore IPv6 notifications") Signed-off-by: NIdo Schimmel <idosch@mellanox.com> Reported-by: NAndreas Rammhold <andreas@rammhold.de> Reported-by: NFlorian Klink <flokli@flokli.de> Signed-off-by: NJiri Pirko <jiri@mellanox.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 16 9月, 2017 6 次提交
-
-
由 Stephen Hemminger 提交于
The default receive buffer size was reduced by recent change to a value which was appropriate for 10G and Windows Server 2016. But the value is too small for full performance with 40G on Azure. Increase the default back to maximum supported by host. Fixes: 8b532797 ("netvsc: allow controlling send/recv buffer size") Signed-off-by: NStephen Hemminger <sthemmin@microsoft.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Geert Uytterhoeven 提交于
If the network interface is kept running during suspend, the net core may call net_device_ops.ndo_start_xmit() while the Ethernet device is still suspended, which may lead to a system crash. E.g. on sh73a0/kzm9g and r8a73a4/ape6evm, the external Ethernet chip is driven by a PM controlled clock. If the Ethernet registers are accessed while the clock is not running, the system will crash with an imprecise external abort. As this is a race condition with a small time window, it is not so easy to trigger at will. Using pm_test may increase your chances: # echo 0 > /sys/module/printk/parameters/console_suspend # echo platform > /sys/power/pm_test # echo mem > /sys/power/state To fix this, make sure the network interface is quietened during suspend. Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Florian Fainelli 提交于
We can enter a deadlock situation because there is no sufficient protection when ndo_get_stats64() runs in process context to guard against RX or TX NAPI contexts running in softirq, this can lead to the following lockdep splat and actual deadlock was experienced as well with an iperf session in the background and a while loop doing ifconfig + ethtool. [ 5.780350] ================================ [ 5.784679] WARNING: inconsistent lock state [ 5.789011] 4.13.0-rc7-02179-g32fae27c725d #70 Not tainted [ 5.794561] -------------------------------- [ 5.798890] inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage. [ 5.804971] swapper/0/0 [HC0[0]:SC1[1]:HE0:SE0] takes: [ 5.810175] (&syncp->seq#2){+.?...}, at: [<c0768a28>] bcm_sysport_tx_reclaim+0x30/0x54 [ 5.818327] {SOFTIRQ-ON-W} state was registered at: [ 5.823278] bcm_sysport_get_stats64+0x17c/0x258 [ 5.828053] dev_get_stats+0x38/0xac [ 5.831776] rtnl_fill_stats+0x30/0x118 [ 5.835761] rtnl_fill_ifinfo+0x538/0xe24 [ 5.839921] rtmsg_ifinfo_build_skb+0x6c/0xd8 [ 5.844430] rtmsg_ifinfo_event.part.5+0x14/0x44 [ 5.849201] rtmsg_ifinfo+0x20/0x28 [ 5.852837] register_netdevice+0x628/0x6b8 [ 5.857171] register_netdev+0x14/0x24 [ 5.861051] bcm_sysport_probe+0x30c/0x438 [ 5.865280] platform_drv_probe+0x50/0xb0 [ 5.869418] driver_probe_device+0x2e8/0x450 [ 5.873817] __driver_attach+0x104/0x120 [ 5.877871] bus_for_each_dev+0x7c/0xc0 [ 5.881834] bus_add_driver+0x1b0/0x270 [ 5.885797] driver_register+0x78/0xf4 [ 5.889675] do_one_initcall+0x54/0x190 [ 5.893646] kernel_init_freeable+0x144/0x1d0 [ 5.898135] kernel_init+0x8/0x110 [ 5.901665] ret_from_fork+0x14/0x2c [ 5.905363] irq event stamp: 24263 [ 5.908804] hardirqs last enabled at (24262): [<c08eecf0>] net_rx_action+0xc4/0x4e4 [ 5.916624] hardirqs last disabled at (24263): [<c0a7da00>] _raw_spin_lock_irqsave+0x1c/0x98 [ 5.925143] softirqs last enabled at (24258): [<c022a7fc>] irq_enter+0x84/0x98 [ 5.932524] softirqs last disabled at (24259): [<c022a918>] irq_exit+0x108/0x16c [ 5.939985] [ 5.939985] other info that might help us debug this: [ 5.946576] Possible unsafe locking scenario: [ 5.946576] [ 5.952556] CPU0 [ 5.955031] ---- [ 5.957506] lock(&syncp->seq#2); [ 5.960955] <Interrupt> [ 5.963604] lock(&syncp->seq#2); [ 5.967227] [ 5.967227] *** DEADLOCK *** [ 5.967227] [ 5.973222] 1 lock held by swapper/0/0: [ 5.977092] #0: (&(&ring->lock)->rlock){..-...}, at: [<c0768a18>] bcm_sysport_tx_reclaim+0x20/0x54 So just remove the u64_stats_update_begin()/end() pair in ndo_get_stats64() since it does not appear to be useful for anything. No inconsistency was observed with either ifconfig or ethtool, global TX counts equal the sum of per-queue TX counts on a 32-bit architecture. Fixes: 10377ba7 ("net: systemport: Support 64bit statistics") Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Arnd Bergmann 提交于
When building an allmodconfig kernel with gcc-4.6, we get a rather odd warning: drivers/net/vrf.c: In function ‘vrf_ip6_input_dst’: drivers/net/vrf.c:964:3: error: initialized field with side-effects overwritten [-Werror] drivers/net/vrf.c:964:3: error: (near initialization for ‘fl6’) [-Werror] I have no idea what this warning is even trying to say, but it does seem like a false positive. Reordering the initialization in to match the structure definition gets rid of the warning, and might also avoid whatever gcc thinks is wrong here. Fixes: 9ff74384 ("net: vrf: Handle ipv6 multicast and link-local addresses") Signed-off-by: NArnd Bergmann <arnd@arndb.de> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Himanshu Jha 提交于
call to memset to assign 0 value immediately after allocating memory with kzalloc is unnecesaary as kzalloc allocates the memory filled with 0 value. Semantic patch used to resolve this issue: @@ expression e,e2; constant c; statement S; @@ e = kzalloc(e2, c); if(e == NULL) S - memset(e, 0, e2); Signed-off-by: NHimanshu Jha <himanshujha199640@gmail.com> Signed-off-by: NHimanshu Jha <himanshujha199640@gmail.com> Acked-by: NSudarsana Kalluru <sudarsana.kalluru@cavium.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Kai-Heng Feng 提交于
Similar to other Gigabyte laptops, the touchpad on P57 requires a keyboard reset to detect Elantech touchpad correctly. BugLink: https://bugs.launchpad.net/bugs/1594214Signed-off-by: NKai-Heng Feng <kai.heng.feng@canonical.com> Cc: stable@vger.kernel.org Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
-
- 15 9月, 2017 2 次提交
-
-
由 Bjorn Helgaas 提交于
This reverts commit 40f11adc. Jens found that iwlwifi firmware loading failed on a Lenovo X1 Carbon, gen4: iwlwifi 0000:04:00.0: Direct firmware load for iwlwifi-8000C-34.ucode failed with error -2 iwlwifi 0000:04:00.0: Direct firmware load for iwlwifi-8000C-33.ucode failed with error -2 iwlwifi 0000:04:00.0: Direct firmware load for iwlwifi-8000C-32.ucode failed with error -2 iwlwifi 0000:04:00.0: loaded firmware version 31.532993.0 op_mode iwlmvm iwlwifi 0000:04:00.0: Detected Intel(R) Dual Band Wireless AC 8260, REV=0x208 ... iwlwifi 0000:04:00.0: Failed to load firmware chunk! iwlwifi 0000:04:00.0: Could not load the [0] uCode section iwlwifi 0000:04:00.0: Failed to start INIT ucode: -110 iwlwifi 0000:04:00.0: Failed to run INIT ucode: -110 He bisected it to 40f11adc ("PCI: Avoid race while enabling upstream bridges"). Revert that commit to fix the regression. Link: http://lkml.kernel.org/r/4bcbcbc1-7c79-09f0-5071-bc2f53bf6574@kernel.dk Fixes: 40f11adc ("PCI: Avoid race while enabling upstream bridges") Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> CC: Srinath Mannam <srinath.mannam@broadcom.com> CC: Jens Axboe <axboe@kernel.dk> CC: Luca Coelho <luca@coelho.fi> CC: Johannes Berg <johannes@sipsolutions.net> CC: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
-
由 Colin Ian King 提交于
tnapi is being initialized and then immediately updated and hence the initialiation is redundant. Clean up the warning by moving the declaration and initialization to the inside of the for-loop. Cleans up clang scan-build warning: warning: Value stored to 'tnapi' during its initialization is never read Signed-off-by: NColin Ian King <colin.king@canonical.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 14 9月, 2017 16 次提交
-
-
由 Pierre-Yves MORDRET 提交于
This patch adds initial support for the STM32F7 I2C controller. Signed-off-by: NM'boumba Cedric Madianga <cedric.madianga@gmail.com> Signed-off-by: NPierre-Yves MORDRET <pierre-yves.mordret@st.com> Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
-
由 Pierre-Yves MORDRET 提交于
This patch uses a more generic definition of speed enum for i2c-stm32f4 driver. Signed-off-by: NM'boumba Cedric Madianga <cedric.madianga@gmail.com> Signed-off-by: NPierre-Yves MORDRET <pierre-yves.mordret@st.com> Reviewed-by: NLudovic BARRE <ludovic.barre@st.com> Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
-
由 Christoph Hellwig 提交于
... and __initconst if applicable. Based on similar work for an older kernel in the Grsecurity patch. [JD: fix toshiba-wmi build] [JD: add htcpen] [JD: move __initconst where checkscript wants it] Signed-off-by: NChristoph Hellwig <hch@lst.de> Signed-off-by: NJean Delvare <jdelvare@suse.de>
-
由 Michal Hocko 提交于
GFP_TEMPORARY was introduced by commit e12ba74d ("Group short-lived and reclaimable kernel allocations") along with __GFP_RECLAIMABLE. It's primary motivation was to allow users to tell that an allocation is short lived and so the allocator can try to place such allocations close together and prevent long term fragmentation. As much as this sounds like a reasonable semantic it becomes much less clear when to use the highlevel GFP_TEMPORARY allocation flag. How long is temporary? Can the context holding that memory sleep? Can it take locks? It seems there is no good answer for those questions. The current implementation of GFP_TEMPORARY is basically GFP_KERNEL | __GFP_RECLAIMABLE which in itself is tricky because basically none of the existing caller provide a way to reclaim the allocated memory. So this is rather misleading and hard to evaluate for any benefits. I have checked some random users and none of them has added the flag with a specific justification. I suspect most of them just copied from other existing users and others just thought it might be a good idea to use without any measuring. This suggests that GFP_TEMPORARY just motivates for cargo cult usage without any reasoning. I believe that our gfp flags are quite complex already and especially those with highlevel semantic should be clearly defined to prevent from confusion and abuse. Therefore I propose dropping GFP_TEMPORARY and replace all existing users to simply use GFP_KERNEL. Please note that SLAB users with shrinkers will still get __GFP_RECLAIMABLE heuristic and so they will be placed properly for memory fragmentation prevention. I can see reasons we might want some gfp flag to reflect shorterm allocations but I propose starting from a clear semantic definition and only then add users with proper justification. This was been brought up before LSF this year by Matthew [1] and it turned out that GFP_TEMPORARY really doesn't have a clear semantic. It seems to be a heuristic without any measured advantage for most (if not all) its current users. The follow up discussion has revealed that opinions on what might be temporary allocation differ a lot between developers. So rather than trying to tweak existing users into a semantic which they haven't expected I propose to simply remove the flag and start from scratch if we really need a semantic for short term allocations. [1] http://lkml.kernel.org/r/20170118054945.GD18349@bombadil.infradead.org [akpm@linux-foundation.org: fix typo] [akpm@linux-foundation.org: coding-style fixes] [sfr@canb.auug.org.au: drm/i915: fix up] Link: http://lkml.kernel.org/r/20170816144703.378d4f4d@canb.auug.org.au Link: http://lkml.kernel.org/r/20170728091904.14627-1-mhocko@kernel.orgSigned-off-by: NMichal Hocko <mhocko@suse.com> Signed-off-by: NStephen Rothwell <sfr@canb.auug.org.au> Acked-by: NMel Gorman <mgorman@suse.de> Acked-by: NVlastimil Babka <vbabka@suse.cz> Cc: Matthew Wilcox <willy@infradead.org> Cc: Neil Brown <neilb@suse.de> Cc: "Theodore Ts'o" <tytso@mit.edu> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Arnd Bergmann 提交于
gcc-7 points out that a negative port_num value would overflow the string buffer: drivers/infiniband/hw/mlx4/sysfs.c: In function 'mlx4_ib_device_register_sysfs': drivers/infiniband/hw/mlx4/sysfs.c:251:16: error: 'sprintf' may write a terminating nul past the end of the destination [-Werror=format-overflow=] drivers/infiniband/hw/mlx4/sysfs.c:251:2: note: 'sprintf' output between 2 and 11 bytes into a destination of size 10 drivers/infiniband/hw/mlx4/sysfs.c:303:17: error: 'sprintf' may write a terminating nul past the end of the destination [-Werror=format-overflow=] drivers/infiniband/hw/mlx4/sysfs.c:303:3: note: 'sprintf' output between 2 and 11 bytes into a destination of size 10 While we should be able to assume that port_num is positive here, making the buffer one byte longer has no downsides and avoids the warning. Fixes: c1e7e466 ("IB/mlx4: Add iov directory in sysfs under the ib device") Link: http://lkml.kernel.org/r/20170714120720.906842-23-arnd@arndb.deSigned-off-by: NArnd Bergmann <arnd@arndb.de> Reviewed-by: NLeon Romanovsky <leonro@mellanox.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Andrew Morton 提交于
gcc-4.4.4 has issues with initialization of anonymous unions: drivers/media/cec/cec-adap.c: In function 'cec_queue_msg_fh': drivers/media/cec/cec-adap.c:184: error: unknown field 'lost_msgs' specified in initializer work around this. Fixes: 6b2bbb08 ("media: cec: rework the cec event handling") Acked-by: NGeert Uytterhoeven <geert@linux-m68k.org> Cc: Hans Verkuil <hans.verkuil@cisco.com> Cc: Maxime Ripard <maxime.ripard@free-electrons.com> Cc: Mauro Carvalho Chehab <mchehab@s-opensource.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Thor Thayer 提交于
Add driver support for the Altera I2C Controller. The I2C controller is soft IP for use in FPGAs. Signed-off-by: NThor Thayer <thor.thayer@linux.intel.com> Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
-
由 Jakub Kicinski 提交于
The control process (NSP) may take some time to complete its initialization. This is not a problem on most servers, but on very fast-booting machines it may not be ready for operation when driver probes the device. There is also a version of the flash in the wild where NSP tries to train the links as part of init. To wait for NSP initialization we should make sure its resource has already been added to the resource table. NSP adds itself there as last step of init. Signed-off-by: NJakub Kicinski <jakub.kicinski@netronome.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Jakub Kicinski 提交于
Board state informs us which low-level initialization stages the card has completed. We should wait for the card to be fully initialized before trying to communicate with it, not only before we configure passing traffic. Signed-off-by: NJakub Kicinski <jakub.kicinski@netronome.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Pieter Jansen van Vuuren 提交于
Previously we did not check the flow dissector against a list of allowed and supported flow key dissectors. This patch introduces such a list and correctly rejects unsupported flow keys. Fixes: 43f84b72 ("nfp: add metadata to each flow offload") Signed-off-by: NPieter Jansen van Vuuren <pieter.jansenvanvuuren@netronome.com> Reviewed-by: NSimon Horman <simon.horman@netronome.com> Reviewed-by: NJakub Kicinski <jakub.kicinski@netronome.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Uwe Kleine-König 提交于
Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: NRichard Weinberger <richard@nod.at>
-
由 Colin Ian King 提交于
Trivial fix to spelling mistake in ubi_err error message Signed-off-by: NColin Ian King <colin.king@canonical.com> Reviewed-by: NBoris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by: NRichard Weinberger <richard@nod.at>
-
由 Ben Dooks 提交于
In build.c, the following pr_err calls should be terminated with a new-line to avoid other messages being concatenated onto the end. Signed-off-by: NBen Dooks <ben.dooks@codethink.co.uk> Signed-off-by: NRichard Weinberger <richard@nod.at>
-
由 Ben Dooks 提交于
In ubi_attach_mtd_dev() the pr_err() calls should have their messgaes terminated with a new-line to avoid other messages being concatenated onto the end. Signed-off-by: NBen Dooks <ben.dooks@codethink.co.uk> Signed-off-by: NRichard Weinberger <richard@nod.at>
-
由 Ben Dooks 提交于
The ubi_init() function has a few error paths that use the pr_err() to output errors. These should have new lines on them as pr_err() does not automatically do this. This fixes issues where if multiple mtd fail to bind to ubi the console output starts wrapping around. Signed-off-by: NBen Dooks <ben.dooks@codethink.co.uk> Signed-off-by: NRichard Weinberger <richard@nod.at>
-
由 Suresh Reddy 提交于
IPv6 TSO requests with extension hdrs are a problem to the Lancer and BEx chips. Workaround is to disable TSO6 feature for such packets. Also in Lancer chips, MSS less than 256 was resulting in TX stall. Fix this by disabling GSO when MSS less than 256. Signed-off-by: NSuresh Reddy <suresh.reddy@broadcom.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 13 9月, 2017 3 次提交
-
-
由 Arnd Bergmann 提交于
A randconfig build caused a compile failure: drivers/net/ethernet/nuvoton/w90p910_ether.c: In function 'w90p910_ether_close': drivers/net/ethernet/nuvoton/w90p910_ether.c:580:2: error: implicit declaration of function 'free_irq'; did you mean 'free_uid'? [-Werror=implicit-function-declaration] Adding the correct include fixes the problem. Signed-off-by: NArnd Bergmann <arnd@arndb.de> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Nikolay Aleksandrov 提交于
Commit 8b426dc5 ("bonding: remove hardcoded value") changed the default value for tlb_dynamic_lb which lead to either broken ALB mode (since tlb_dynamic_lb can be changed only in TLB) or setting TLB mode with tlb_dynamic_lb equal to 0. The first issue was recently fixed by setting tlb_dynamic_lb to 1 always when switching to ALB mode, but the default value is still wrong and we'll enter TLB mode with tlb_dynamic_lb equal to 0 if the mode is changed via netlink or sysfs. In order to restore the previous behaviour and default value simply remove the mode check around the default param initialization for tlb_dynamic_lb which will always set it to 1 as before. Fixes: 8b426dc5 ("bonding: remove hardcoded value") Signed-off-by: NNikolay Aleksandrov <nikolay@cumulusnetworks.com> Acked-by: NMahesh Bandewar <maheshb@google.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Yuval Mintz 提交于
When removing the offloading of mirred actions under matchall classifiers, mlxsw would find the destination port associated with the offloaded action and utilize it for undoing the configuration. Depending on the order by which ports are removed, it's possible that the destination port would get removed before the source port. In such a scenario, when actions would be flushed for the source port mlxsw would perform an illegal dereference as the destination port is no longer listed. Since the only item necessary for undoing the configuration on the destination side is the port-id and that in turn is already maintained by mlxsw on the source-port, simply stop trying to access the destination port and use the port-id directly instead. Fixes: 763b4b70 ("mlxsw: spectrum: Add support in matchall mirror TC offloading") Signed-off-by: NYuval Mintz <yuvalm@mellanox.com> Signed-off-by: NJiri Pirko <jiri@mellanox.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-