aboutsummaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2018-02-05drm/i915/breadcrumbs: Drop request reference for the signaler threadChris Wilson2-70/+86
If we remember to cancel the signaler on a request when retiring it (after we know that the request has been signaled), we do not need to carry an additional request in the signaler itself. This prevents an issue whereby the signaler threads may be delayed and hold on to thousands of request references, causing severe memory fragmentation and premature oom (most noticeable on 32b snb due to the limited GFP_KERNEL and frequent use of inter-engine fences). v2: Rename first_signal(), document reads outside of locks. Signed-off-by: Chris Wilson <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Tvrtko Ursulin <[email protected]>
2018-02-05drm/i915: Remove unbannable context spam from resetChris Wilson1-12/+11
During testing, we trigger a lot of resets on an unbannable context leading to massive amounts of irrelevant debug spam. Remove the ban_score accounting and message for the unbannable context so that we improve the signal:noise in the log messages for when the unexpected occurs. Signed-off-by: Chris Wilson <[email protected]> Cc: Mika Kuoppala <[email protected]> Reviewed-by: Mika Kuoppala <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2018-02-05drm/i915/execlists: Remove the startup spamChris Wilson1-1/+0
Execlists is now enabled by default and included in the list of capabilities printed out to dmesg and beyond. We do not need to mention it again, every time we restart the engine, so kill the spam. Signed-off-by: Chris Wilson <[email protected]> Reviewed-by: Mika Kuoppala <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2018-02-05drm/i915: Show the GPU state when declaring wedgedChris Wilson1-0/+7
Dump each engine state when i915_gem_set_wedged() is called to give us some more clues as to why we had to terminate the GPU. Signed-off-by: Chris Wilson <[email protected]> Cc: Joonas Lahtinen <[email protected]> Reviewed-by: Mika Kuoppala <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2018-02-05drm/crc: Add support for polling on the data fd.Maarten Lankhorst1-0/+19
This will make it possible for userspace to know whether reading will block, without blocking on the fd. This makes it possible to drain all queued CRC's in blocking mode, without having to reopen the fd. Signed-off-by: Maarten Lankhorst <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Ville Syrjälä <[email protected]> [mlankhorst: Use POLLIN|POLLRDNORM, based on Ville's suggestion]
2018-02-05drm/i915: Always update the no_fbc_reason when disablingChris Wilson1-7/+10
Provide the reason why we call intel_fbc_deactivate() so that debugging issues with FBC being delayed is clearer. Signed-off-by: Chris Wilson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jani Nikula <[email protected]>
2018-02-05drm/i915: Add some newlines to intel_engine_dump() headersChris Wilson2-2/+2
The headers should be on a separate line for consistency, so add the missing trailing newline in a few intel_engine_dump() callers. Reported-by: Mika Kuoppala <[email protected]> Signed-off-by: Chris Wilson <[email protected]> Cc: Mika Kuoppala <[email protected]> Reviewed-by: Mika Kuoppala <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2018-02-05drm/i915: Report if an unbannable context is involved in a GPU hangChris Wilson2-6/+16
Since unbannable contexts are special and supposed not to be causing GPU hangs in the first place, make it clear when they are implicated in said hang. In practice, most unbannable contexts are those created by igt for the express purpose of throwing untold thousands of hangs at the GPU and wish to keep doing so to finish the test. Normally they are cleaned up, but it's when they or the other unbannable kernel contexts stay stuck in an erroneous state that we need to worry and so need highlighting. Suggested-by: Mika Kuoppala <[email protected]> Signed-off-by: Chris Wilson <[email protected]> Cc: Mika Kuoppala <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Mika Kuoppala <[email protected]>
2018-02-05cpufreq: Skip cpufreq resume if it's not suspendedBo Yan1-0/+3
cpufreq_resume can be called even without preceding cpufreq_suspend. This can happen in following scenario: suspend_devices_and_enter --> dpm_suspend_start --> dpm_prepare --> device_prepare : this function errors out --> dpm_suspend: this is skipped due to dpm_prepare failure this means cpufreq_suspend is skipped over --> goto Recover_platform, due to previous error --> goto Resume_devices --> dpm_resume_end --> dpm_resume --> cpufreq_resume In case schedutil is used as frequency governor, cpufreq_resume will eventually call sugov_start, which does following: memset(sg_cpu, 0, sizeof(*sg_cpu)); .... This effectively erases function pointer for frequency update, causing crash later on. The function pointer would have been set correctly if subsequent cpufreq_add_update_util_hook runs successfully, but that function returns earlier because cpufreq_suspend was not called: if (WARN_ON(per_cpu(cpufreq_update_util_data, cpu))) return; The fix is to check cpufreq_suspended first, if it's false, that means cpufreq_suspend was not called in the first place, so do not resume cpufreq. Signed-off-by: Bo Yan <[email protected]> Acked-by: Viresh Kumar <[email protected]> [ rjw: Dropped printing a message ] Signed-off-by: Rafael J. Wysocki <[email protected]>
2018-02-05s390/cio: fix kernel-doc usageSebastian Ott5-11/+9
Fix the kernel-doc usage in cio to get rid of (W=1) build warnings like: drivers/s390/cio/cio.c:1068: warning: No description found for parameter 'sch' Signed-off-by: Sebastian Ott <[email protected]> Signed-off-by: Martin Schwidefsky <[email protected]>
2018-02-04Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpfDavid S. Miller1-3/+2
Alexei Starovoitov says: ==================== pull-request: bpf 2018-02-02 The following pull-request contains BPF updates for your *net* tree. The main changes are: 1) support XDP attach in libbpf, from Eric. 2) minor fixes, from Daniel, Jakub, Yonghong, Alexei. ==================== Signed-off-by: David S. Miller <[email protected]>
2018-02-04Merge branch 'irq-urgent-for-linus' of ↵Linus Torvalds1-1/+2
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull irq fixes from Thomas Gleixner: "Two small changes: - a fix for a interrupt regression caused by the vector management changes in 4.15 affecting museum pieces which rely on interrupt probing for legacy (e.g. parallel port) devices. One of the startup calls in the autoprobe code was not changed to the new activate_and_startup() function resulting in a warning and as a consequence failing to discover the device interrupt. - a trivial update to the copyright/license header of the STM32 irq chip driver" * 'irq-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: genirq: Make legacy autoprobing work again irqchip/stm32: Fix copyright
2018-02-04Merge tag 'for-linus-20180204' of git://git.kernel.dk/linux-blockLinus Torvalds7-22/+14
Pull more block updates from Jens Axboe: "Most of this is fixes and not new code/features: - skd fix from Arnd, fixing a build error dependent on sla allocator type. - blk-mq scheduler discard merging fixes, one from me and one from Keith. This fixes a segment miscalculation for blk-mq-sched, where we mistakenly think two segments are physically contigious even though the request isn't carrying real data. Also fixes a bio-to-rq merge case. - Don't re-set a bit on the buffer_head flags, if it's already set. This can cause scalability concerns on bigger machines and workloads. From Kemi Wang. - Add BLK_STS_DEV_RESOURCE return value to blk-mq, allowing us to distuingish between a local (device related) resource starvation and a global one. The latter might happen without IO being in flight, so it has to be handled a bit differently. From Ming" * tag 'for-linus-20180204' of git://git.kernel.dk/linux-block: block: skd: fix incorrect linux/slab_def.h inclusion buffer: Avoid setting buffer bits that are already set blk-mq-sched: Enable merging discard bio into request blk-mq: fix discard merge with scheduler attached blk-mq: introduce BLK_STS_DEV_RESOURCE
2018-02-04Merge tag 'ntb-4.16' of git://github.com/jonmason/ntbLinus Torvalds10-1852/+3269
Pull NTB updates from Jon Mason: "Bug fixes galore, removal of the ntb atom driver, and updates to the ntb tools and tests to support the multi-port interface" * tag 'ntb-4.16' of git://github.com/jonmason/ntb: (37 commits) NTB: ntb_perf: fix cast to restricted __le32 ntb_perf: Fix an error code in perf_copy_chunk() ntb_hw_switchtec: Make function switchtec_ntb_remove() static NTB: ntb_tool: fix memory leak on 'buf' on error exit path NTB: ntb_perf: fix printing of resource_size_t NTB: ntb_hw_idt: Set NTB_TOPO_SWITCH topology NTB: ntb_test: Update ntb_perf tests NTB: ntb_test: Update ntb_tool MW tests NTB: ntb_test: Add ntb_tool Message tests NTB: ntb_test: Update ntb_tool Scratchpad tests NTB: ntb_test: Update ntb_tool DB tests NTB: ntb_test: Update ntb_tool link tests NTB: ntb_test: Add ntb_tool port tests NTB: ntb_test: Safely use paths with whitespace NTB: ntb_perf: Add full multi-port NTB API support NTB: ntb_tool: Add full multi-port NTB API support NTB: ntb_pp: Add full multi-port NTB API support NTB: Fix UB/bug in ntb_mw_get_align() NTB: Set dma mask and dma coherent mask to NTB devices NTB: Rename NTB messaging API methods ...
2018-02-04Merge tag 'mailbox-v4.16' of ↵Linus Torvalds2-16/+33
git://git.linaro.org/landing-teams/working/fujitsu/integration Pull mailbox updates from Jassi Brar: "Misc driver changes only: - TI-MsgMgr: Fix print format for a printk - TI-MSgMgr: SPDX license switch for the driver - QCOM-IPC: Convert driver to use regmap - QCOM-IPC: Spawn sibling clock device from mailbox driver" * tag 'mailbox-v4.16' of git://git.linaro.org/landing-teams/working/fujitsu/integration: dt-bindings: mailbox: qcom: Document the APCS clock binding mailbox: qcom: Create APCS child device for clock controller mailbox: qcom: Convert APCS IPC driver to use regmap mailbox: ti-msgmgr: Use %zu for size_t print format mailbox: ti-msgmgr: Switch to SPDX Licensing
2018-02-04Merge branch 'i2c/for-4.16' of ↵Linus Torvalds30-931/+1016
git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux Pull i2c updates from Wolfram Sang: "I2C has the following changes for you: - new flag to mark DMA safe buffers in i2c_msg. Also, some infrastructure around it. And docs. - huge refactoring of the at24 driver led by the new maintainer Bartosz - update I2C bus recovery to send STOP after recovery - conversion from gpio to gpiod for I2C bus recovery - adding a fault-injector to the i2c-gpio driver - lots of small driver improvements, and bigger ones to i2c-sh_mobile" * 'i2c/for-4.16' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux: (99 commits) i2c: mv64xxx: Add myself as maintainer for this driver i2c: mv64xxx: Fix clock resource by adding an optional bus clock i2c: mv64xxx: Remove useless test before clk_disable_unprepare i2c: mxs: use true and false for boolean values i2c: meson: update doc description to fix build warnings i2c: meson: add configurable divider factors dt-bindings: i2c: update documentation for the Meson-AXG i2c: imx-lpi2c: add runtime pm support i2c: rcar: fix some trivial typos in comments i2c: davinci: fix the cpufreq transition i2c: rk3x: add proper kerneldoc header i2c: rk3x: account for const type of of_device_id.data i2c: acorn: remove outdated path from file header i2c: acorn: add MODULE_LICENSE tag i2c: rcar: implement bus recovery i2c: send STOP after successful bus recovery i2c: ensure SDA is released in recovery if SDA is controllable i2c: add 'set_sda' to bus_recovery_info i2c: add identifier in declarations for i2c_bus_recovery i2c: make kerneldoc about bus recovery more precise ...
2018-02-04IB/uverbs: Use the standard kConfig format for experimentalJason Gunthorpe1-1/+1
We really don't want people turning this on just yet, make it very clear with capital letters. Signed-off-by: Jason Gunthorpe <[email protected]> Signed-off-by: Doug Ledford <[email protected]>
2018-02-04IB: Update references to libibverbsJason Gunthorpe1-2/+3
These days the userspace comes from rdma-core, revise references in the kernel to point to the current repository. Signed-off-by: Jason Gunthorpe <[email protected]> Reviewed-by: Leon Romanovsky <[email protected]> Signed-off-by: Doug Ledford <[email protected]>
2018-02-04platform/x86: intel_pmc_core: Special case for CoffeelakeRajneesh Bhardwaj2-0/+16
Intel CoffeeLake SoC uses CPU ID of KabyLake but has Cannonlake PCH, so in this case PMC register details from Cannonlake PCH must be used. In order to identify whether the given platform is Coffeelake, scan for the Sunrisepoint PMC PCI Id. KBL CPUID SPT PCIID ------------------------------------ KBL | Y | Y | ------------------------------------ CFL | Y | N | ------------------------------------ Signed-off-by: Srinivas Pandruvada <[email protected]> Signed-off-by: Rajneesh Bhardwaj <[email protected]> Signed-off-by: Andy Shevchenko <[email protected]>
2018-02-04platform/x86: intel_pmc_core: Add CannonLake PCH supportRajneesh Bhardwaj2-0/+96
This adds support for Cannonlake PCH which is used by Cannonlake and Coffeelake SoCs. Signed-off-by: Srinivas Pandruvada <[email protected]> Signed-off-by: Rajneesh Bhardwaj <[email protected]> Signed-off-by: Andy Shevchenko <[email protected]>
2018-02-04platform/x86: intel_pmc_core: Read base address from LPITSrinivas Pandruvada1-1/+8
Read SLP_S0 address from ACPI LPIT table when present and use PMC specific SLP_S0 offset to get the base address of PMC MMIO. Signed-off-by: Rajneesh Bhardwaj <[email protected]> Signed-off-by: Srinivas Pandruvada <[email protected]> Signed-off-by: Andy Shevchenko <[email protected]>
2018-02-04ACPI / LPIT: Export lpit_read_residency_count_address()Srinivas Pandruvada1-0/+1
Export lpit_read_residency_count_address(), so that it can be used from drivers built as module. With the recent changes, the builtin_pci functionality of the intel_pmc_core driver is removed and now it can be built as a module to read this exported interface to calculate the PMC base address. Cc: Rafael J. Wysocki <[email protected]> Cc: Len Brown <[email protected]> Cc: [email protected] Acked-by: Rafael J. Wysocki <[email protected]> Tested-by: Rajneesh Bhardwaj <[email protected]> Signed-off-by: Srinivas Pandruvada <[email protected]> Signed-off-by: Andy Shevchenko <[email protected]>
2018-02-04ACPI / processor: Set default C1 idle state descriptionYazen Ghannam1-0/+3
The ACPI idle driver will default to ACPI_CSTATE_HALT for C1 if a _CST object for C1 is not defined. However, the description will not be set, so users will see "<null>" when reading the description from sysfs. Set the C1 state description when defaulting to ACPI_CSTATE_HALT. Signed-off-by: Yazen Ghannam <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2018-02-04ACPI / battery: Add quirk for Asus UX360UA and UX410UAKKai Heng Feng1-0/+16
Same issue as other Asus laptops, ACPI incorrectly reports discharging when battery is full and AC is plugged. Use the same battery quirk can workaround the issue. Link: https://bugs.launchpad.net/bugs/1661876 Link: https://bugs.launchpad.net/bugs/1745032 Signed-off-by: Kai-Heng Feng <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2018-02-04ACPI: processor_perflib: Do not send _PPC change notification if not readyChen Yu1-1/+1
The following warning was triggered after resumed from S3 - if all the nonboot CPUs were put offline before suspend: [ 1840.329515] unchecked MSR access error: RDMSR from 0x771 at rIP: 0xffffffff86061e3a (native_read_msr+0xa/0x30) [ 1840.329516] Call Trace: [ 1840.329521] __rdmsr_on_cpu+0x33/0x50 [ 1840.329525] generic_exec_single+0x81/0xb0 [ 1840.329527] smp_call_function_single+0xd2/0x100 [ 1840.329530] ? acpi_ds_result_pop+0xdd/0xf2 [ 1840.329532] ? acpi_ds_create_operand+0x215/0x23c [ 1840.329534] rdmsrl_on_cpu+0x57/0x80 [ 1840.329536] ? cpumask_next+0x1b/0x20 [ 1840.329538] ? rdmsrl_on_cpu+0x57/0x80 [ 1840.329541] intel_pstate_update_perf_limits+0xf3/0x220 [ 1840.329544] ? notifier_call_chain+0x4a/0x70 [ 1840.329546] intel_pstate_set_policy+0x4e/0x150 [ 1840.329548] cpufreq_set_policy+0xcd/0x2f0 [ 1840.329550] cpufreq_update_policy+0xb2/0x130 [ 1840.329552] ? cpufreq_update_policy+0x130/0x130 [ 1840.329556] acpi_processor_ppc_has_changed+0x65/0x80 [ 1840.329558] acpi_processor_notify+0x80/0x100 [ 1840.329561] acpi_ev_notify_dispatch+0x44/0x5c [ 1840.329563] acpi_os_execute_deferred+0x14/0x20 [ 1840.329565] process_one_work+0x193/0x3c0 [ 1840.329567] worker_thread+0x35/0x3b0 [ 1840.329569] kthread+0x125/0x140 [ 1840.329571] ? process_one_work+0x3c0/0x3c0 [ 1840.329572] ? kthread_park+0x60/0x60 [ 1840.329575] ? do_syscall_64+0x67/0x180 [ 1840.329577] ret_from_fork+0x25/0x30 [ 1840.329585] unchecked MSR access error: WRMSR to 0x774 (tried to write 0x0000000000000000) at rIP: 0xffffffff86061f78 (native_write_msr+0x8/0x30) [ 1840.329586] Call Trace: [ 1840.329587] __wrmsr_on_cpu+0x37/0x40 [ 1840.329589] generic_exec_single+0x81/0xb0 [ 1840.329592] smp_call_function_single+0xd2/0x100 [ 1840.329594] ? acpi_ds_create_operand+0x215/0x23c [ 1840.329595] ? cpumask_next+0x1b/0x20 [ 1840.329597] wrmsrl_on_cpu+0x57/0x70 [ 1840.329598] ? rdmsrl_on_cpu+0x57/0x80 [ 1840.329599] ? wrmsrl_on_cpu+0x57/0x70 [ 1840.329602] intel_pstate_hwp_set+0xd3/0x150 [ 1840.329604] intel_pstate_set_policy+0x119/0x150 [ 1840.329606] cpufreq_set_policy+0xcd/0x2f0 [ 1840.329607] cpufreq_update_policy+0xb2/0x130 [ 1840.329610] ? cpufreq_update_policy+0x130/0x130 [ 1840.329613] acpi_processor_ppc_has_changed+0x65/0x80 [ 1840.329615] acpi_processor_notify+0x80/0x100 [ 1840.329617] acpi_ev_notify_dispatch+0x44/0x5c [ 1840.329619] acpi_os_execute_deferred+0x14/0x20 [ 1840.329620] process_one_work+0x193/0x3c0 [ 1840.329622] worker_thread+0x35/0x3b0 [ 1840.329624] kthread+0x125/0x140 [ 1840.329625] ? process_one_work+0x3c0/0x3c0 [ 1840.329626] ? kthread_park+0x60/0x60 [ 1840.329628] ? do_syscall_64+0x67/0x180 [ 1840.329631] ret_from_fork+0x25/0x30 This is because if there's only one online CPU, the MSR_PM_ENABLE (package wide)can not be enabled after resumed, due to intel_pstate_hwp_enable() will only be invoked on AP's online process after resumed - if there's no AP online, the HWP remains disabled after resumed (BIOS has disabled it in S3). Then if there comes a _PPC change notification which touches HWP register during this stage, the warning is triggered. Since we don't call acpi_processor_register_performance() when HWP is enabled, the pr->performance will be NULL. When this is NULL we don't need to do _PPC change notification. Reported-by: Doug Smythies <[email protected]> Suggested-by: Srinivas Pandruvada <[email protected]> Signed-off-by: Yu Chen <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2018-02-04ACPI / scan: Use acpi_bus_get_status() to initialize ACPI_TYPE_DEVICE devsHans de Goede1-3/+17
The acpi_get_bus_status wrapper for acpi_bus_get_status_handle has some code to handle certain device quirks, in some cases we also need this quirk handling for the initial _STA call. Specifically on some devices calling _STA before all _DEP dependencies are met results in errors like these: [ 0.123579] ACPI Error: No handler for Region [ECRM] (00000000ba9edc4c) [GenericSerialBus] (20170831/evregion-166) [ 0.123601] ACPI Error: Region GenericSerialBus (ID=9) has no handler (20170831/exfldio-299) [ 0.123618] ACPI Error: Method parse/execution failed \_SB.I2C1.BAT1._STA, AE_NOT_EXIST (20170831/psparse-550) acpi_get_bus_status already has code to avoid this, so by using it we also silence these errors from the initial _STA call. Note that in order for the acpi_get_bus_status handling for this to work, we initialize dep_unmet to 1 until acpi_device_dep_initialize gets called, this means that battery devices will be instantiated with an initial status of 0. This is not a problem, acpi_bus_attach will get called soon after the instantiation anyways and it will update the status as first point of order. Signed-off-by: Hans de Goede <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2018-02-04ACPI / bus: Do not call _STA on battery devices with unmet dependenciesHans de Goede1-0/+6
The battery code uses acpi_device->dep_unmet to check for unmet deps and if there are unmet deps it does not bind to the device to avoid errors about missing OpRegions when calling ACPI methods on the device. The missing OpRegions when there are unmet deps problem also applies to the _STA method of some battery devices and calling it too early results in errors like these: [ 0.123579] ACPI Error: No handler for Region [ECRM] (00000000ba9edc4c) [GenericSerialBus] (20170831/evregion-166) [ 0.123601] ACPI Error: Region GenericSerialBus (ID=9) has no handler (20170831/exfldio-299) [ 0.123618] ACPI Error: Method parse/execution failed \_SB.I2C1.BAT1._STA, AE_NOT_EXIST (20170831/psparse-550) This commit fixes these errors happening when acpi_get_bus_status gets called by checking dep_unmet for battery devices and reporting a status of 0 until all dependencies are met. Signed-off-by: Hans de Goede <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2018-02-04PCI: acpiphp_ibm: prepare for acpi_get_object_info() no longer returning statusHans de Goede1-1/+4
acpi_get_object_info() is intended for early probe usage and as such should not call any methods which may rely on OpRegions, but it used to also call _STA to get the status, which on some systems does rely on OpRegions, this behavior and the acpi_device_info.current_status member are being removed. This commit prepares the acpiphp_ibm code for this by having it get the status itself using acpi_bus_get_status_handle(). Note no error handling is necessary on any errors acpi_bus_get_status_handle() leaves the value of the passed in current_status at its 0 initialization value. Acked-by: Bjorn Helgaas <[email protected]> Signed-off-by: Hans de Goede <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2018-02-04ACPI: export acpi_bus_get_status_handle()Hans de Goede1-0/+1
Some modular drivers need this, export it. Signed-off-by: Hans de Goede <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2018-02-04ACPI / video: Use true for boolean valueGustavo A. R. Silva1-1/+1
Assign true or false to boolean variables instead of an integer value. This issue was detected with the help of Coccinelle. Signed-off-by: Gustavo A. R. Silva <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2018-02-04mailbox: qcom: Create APCS child device for clock controllerGeorgi Djakov1-0/+11
There is a clock controller functionality provided by the APCS hardware block of msm8916 devices. The device-tree would represent an APCS node with both mailbox and clock provider properties. Create a platform child device for the clock controller functionality so the driver can probe and use APCS as parent. Signed-off-by: Georgi Djakov <[email protected]> Acked-by: Bjorn Andersson <[email protected]> Signed-off-by: Jassi Brar <[email protected]>
2018-02-04mailbox: qcom: Convert APCS IPC driver to use regmapGeorgi Djakov1-5/+19
This hardware block provides more functionalities that just IPC. Convert it to regmap to allow other child platform devices to use the same regmap. Signed-off-by: Georgi Djakov <[email protected]> Acked-by: Bjorn Andersson <[email protected]> Signed-off-by: Jassi Brar <[email protected]>
2018-02-03Merge tag 'usercopy-v4.16-rc1' of ↵Linus Torvalds4-51/+67
git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux Pull hardened usercopy whitelisting from Kees Cook: "Currently, hardened usercopy performs dynamic bounds checking on slab cache objects. This is good, but still leaves a lot of kernel memory available to be copied to/from userspace in the face of bugs. To further restrict what memory is available for copying, this creates a way to whitelist specific areas of a given slab cache object for copying to/from userspace, allowing much finer granularity of access control. Slab caches that are never exposed to userspace can declare no whitelist for their objects, thereby keeping them unavailable to userspace via dynamic copy operations. (Note, an implicit form of whitelisting is the use of constant sizes in usercopy operations and get_user()/put_user(); these bypass all hardened usercopy checks since these sizes cannot change at runtime.) This new check is WARN-by-default, so any mistakes can be found over the next several releases without breaking anyone's system. The series has roughly the following sections: - remove %p and improve reporting with offset - prepare infrastructure and whitelist kmalloc - update VFS subsystem with whitelists - update SCSI subsystem with whitelists - update network subsystem with whitelists - update process memory with whitelists - update per-architecture thread_struct with whitelists - update KVM with whitelists and fix ioctl bug - mark all other allocations as not whitelisted - update lkdtm for more sensible test overage" * tag 'usercopy-v4.16-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux: (38 commits) lkdtm: Update usercopy tests for whitelisting usercopy: Restrict non-usercopy caches to size 0 kvm: x86: fix KVM_XEN_HVM_CONFIG ioctl kvm: whitelist struct kvm_vcpu_arch arm: Implement thread_struct whitelist for hardened usercopy arm64: Implement thread_struct whitelist for hardened usercopy x86: Implement thread_struct whitelist for hardened usercopy fork: Provide usercopy whitelisting for task_struct fork: Define usercopy region in thread_stack slab caches fork: Define usercopy region in mm_struct slab caches net: Restrict unwhitelisted proto caches to size 0 sctp: Copy struct sctp_sock.autoclose to userspace using put_user() sctp: Define usercopy region in SCTP proto slab cache caif: Define usercopy region in caif proto slab cache ip: Define usercopy region in IP proto slab cache net: Define usercopy region in struct proto slab cache scsi: Define usercopy region in scsi_sense_cache slab cache cifs: Define usercopy region in cifs_request slab cache vxfs: Define usercopy region in vxfs_inode slab cache ufs: Define usercopy region in ufs_inode_cache slab cache ...
2018-02-03Merge branch 'dmi-for-linus' of ↵Linus Torvalds2-37/+29
git://git.kernel.org/pub/scm/linux/kernel/git/jdelvare/staging Pull dmi subsystem updates/fixes from Jean Delvare. * 'dmi-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jdelvare/staging: firmware: dmi: handle missing DMI data gracefully firmware: dmi_scan: Fix handling of empty DMI strings firmware: dmi_scan: Drop dmi_initialized firmware: dmi: Optimize dmi_matches
2018-02-03Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/netLinus Torvalds13-33/+60
Pull networking fixes from David Miller: 1) The bnx2x can hang if you give it a GSO packet with a segment size which is too big for the hardware, detect and drop in this case. From Daniel Axtens. 2) Fix some overflows and pointer leaks in xtables, from Dmitry Vyukov. 3) Missing RCU locking in igmp, from Eric Dumazet. 4) Fix RX checksum handling on r8152, it can only checksum UDP and TCP packets. From Hayes Wang. 5) Minor pacing tweak to TCP BBR congestion control, from Neal Cardwell. 6) Missing RCU annotations in cls_u32, from Paolo Abeni. * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: (30 commits) Revert "defer call to mem_cgroup_sk_alloc()" soreuseport: fix mem leak in reuseport_add_sock() net: qlge: use memmove instead of skb_copy_to_linear_data net: qed: use correct strncpy() size net: cxgb4: avoid memcpy beyond end of source buffer cls_u32: add missing RCU annotation. r8152: set rx mode early when linking on r8152: fix wrong checksum status for received IPv4 packets nfp: fix TLV offset calculation net: pxa168_eth: add netconsole support net: igmp: add a missing rcu locking section ibmvnic: fix firmware version when no firmware level has been provided by the VIOS server vmxnet3: remove redundant initialization of pointer 'rq' lan78xx: remove redundant initialization of pointer 'phydev' net: jme: remove unused initialization of 'rxdesc' rtnetlink: remove check for IFLA_IF_NETNSID rocker: fix possible null pointer dereference in rocker_router_fib_event_work inet: Avoid unitialized variable warning in inet_unhash() net: bridge: Fix uninitialized error in br_fdb_sync_static() openvswitch: Remove padding from packet before L3+ conntrack processing ...
2018-02-03Merge tag 'scsi-postmerge' of ↵Linus Torvalds4-141/+186
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi Pull second set of SCSI updates from James Bottomley: "This is a set of three patches that depended on mq and zone changes in the block tree (now upstream)" * tag 'scsi-postmerge' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: scsi: sd: Remove zone write locking scsi: sd_zbc: Initialize device request queue zoned data scsi: scsi-mq-debugfs: Show more information
2018-02-03firmware: dmi: handle missing DMI data gracefullyArd Biesheuvel2-5/+3
Currently, when booting a kernel with DMI support on a platform that has no DMI tables, the following output is emitted into the kernel log: [ 0.128818] DMI not present or invalid. ... [ 1.306659] dmi: Firmware registration failed. ... [ 2.908681] dmi-sysfs: dmi entry is absent. The first one is a pr_info(), but the subsequent ones are pr_err()s that complain about a condition that is not really an error to begin with. So let's clean this up, and give up silently if dma_available is not set. Signed-off-by: Ard Biesheuvel <[email protected]> Acked-by: Martin Hundebøll <[email protected]> Signed-off-by: Jean Delvare <[email protected]>
2018-02-03firmware: dmi_scan: Fix handling of empty DMI stringsJean Delvare1-13/+9
The handling of empty DMI strings looks quite broken to me: * Strings from 1 to 7 spaces are not considered empty. * True empty DMI strings (string index set to 0) are not considered empty, and result in allocating a 0-char string. * Strings with invalid index also result in allocating a 0-char string. * Strings starting with 8 spaces are all considered empty, even if non-space characters follow (sounds like a weird thing to do, but I have actually seen occurrences of this in DMI tables before.) * Strings which are considered empty are reported as 8 spaces, instead of being actually empty. Some of these issues are the result of an off-by-one error in memcmp, the rest is incorrect by design. So let's get it square: missing strings and strings made of only spaces, regardless of their length, should be treated as empty and no memory should be allocated for them. All other strings are non-empty and should be allocated. Signed-off-by: Jean Delvare <[email protected]> Fixes: 79da4721117f ("x86: fix DMI out of memory problems") Cc: Parag Warudkar <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Thomas Gleixner <[email protected]>
2018-02-03firmware: dmi_scan: Drop dmi_initializedJean Delvare1-13/+8
I don't think it makes sense to check for a possible bad initialization order at run time on every system when it is all decided at build time. A more efficient way to make sure developers do not introduce new calls to dmi_check_system() too early in the initialization sequence is to simply document the expected call order. That way, developers have a chance to get it right immediately, without having to test-boot their kernel, wonder why it does not work, and parse the kernel logs for a warning message. And we get rid of the run-time performance penalty as a nice side effect. Signed-off-by: Jean Delvare <[email protected]> Cc: Ingo Molnar <[email protected]>
2018-02-03firmware: dmi: Optimize dmi_matchesJean Delvare1-8/+11
Function dmi_matches can me made a bit faster: * The documented purpose of dmi_initialized is to catch too early calls to dmi_check_system(). I'm not fully convinced it justifies slowing down the initialization of all systems out there, but at least the check should not have been moved from dmi_check_system() to dmi_matches(). dmi_matches() is being called for every entry of the table passed to dmi_check_system(), causing the same redundant check to be performed again and again. So move it back to dmi_check_system(), reverting this specific portion of commit d7b1956fed33 ("DMI: Introduce dmi_first_match to make the interface more flexible"). * Don't check for the exact_match flag again when we already know its value. Signed-off-by: Jean Delvare <[email protected]> Fixes: d7b1956fed33 ("DMI: Introduce dmi_first_match to make the interface more flexible") Cc: Jani Nikula <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: Rafael J. Wysocki <[email protected]> Cc: Jeff Garzik <[email protected]>
2018-02-03Merge branch 'for-4.16/nfit' into libnvdimm-for-nextRoss Zwisler187-874/+2089
2018-02-03Merge branch 'for-4.16/dax' into libnvdimm-for-nextRoss Zwisler758-5085/+8348
2018-02-03libnvdimm, namespace: remove redundant initialization of 'nd_mapping'Colin Ian King1-1/+1
Pointer nd_mapping is being initialized to a value that is never read, instead it is being updated to a new value in all the cases where it is being read afterwards, hence the initialization is redundant and can be removed. Cleans up clang warning: drivers/nvdimm/namespace_devs.c:2411:21: warning: Value stored to 'nd_mapping' during its initialization is never rea Signed-off-by: Colin Ian King <[email protected]> Reviewed-by: Ross Zwisler <[email protected]> Signed-off-by: Ross Zwisler <[email protected]>
2018-02-02net: qlge: use memmove instead of skb_copy_to_linear_dataArnd Bergmann1-2/+1
gcc-8 points out that the skb_copy_to_linear_data() argument points to the skb itself, which makes it run into a problem with overlapping memcpy arguments: In file included from include/linux/ip.h:20, from drivers/net/ethernet/qlogic/qlge/qlge_main.c:26: drivers/net/ethernet/qlogic/qlge/qlge_main.c: In function 'ql_realign_skb': include/linux/skbuff.h:3378:2: error: 'memcpy' source argument is the same as destination [-Werror=restrict] memcpy(skb->data, from, len); It's unclear to me what the best solution is, maybe it ought to use a different helper that adjusts the skb data in a safe way. Simply using memmove() here seems like the easiest workaround. Signed-off-by: Arnd Bergmann <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2018-02-02net: qed: use correct strncpy() sizeArnd Bergmann1-4/+2
passing the strlen() of the source string as the destination length is pointless, and gcc-8 now warns about it: drivers/net/ethernet/qlogic/qed/qed_debug.c: In function 'qed_grc_dump': include/linux/string.h:253: error: 'strncpy' specified bound depends on the length of the source argument [-Werror=stringop-overflow=] This changes qed_grc_dump_big_ram() to instead uses the length of the destination buffer, and use strscpy() to guarantee nul-termination. Signed-off-by: Arnd Bergmann <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2018-02-02net: cxgb4: avoid memcpy beyond end of source bufferArnd Bergmann1-1/+1
Building with link-time-optimizations revealed that the cxgb4 driver does a fixed-size memcpy() from a variable-length constant string into the network interface name: In function 'memcpy', inlined from 'cfg_queues_uld.constprop' at drivers/net/ethernet/chelsio/cxgb4/cxgb4_uld.c:335:2, inlined from 'cxgb4_register_uld.constprop' at drivers/net/ethernet/chelsio/cxgb4/cxgb4_uld.c:719:9: include/linux/string.h:350:3: error: call to '__read_overflow2' declared with attribute error: detected read beyond size of object passed as 2nd parameter __read_overflow2(); ^ I can see two equally workable solutions: either we use a strncpy() instead of the memcpy() to stop at the end of the input, or we make the source buffer fixed length as well. This implements the latter. Signed-off-by: Arnd Bergmann <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2018-02-02r8152: set rx mode early when linking onHayes Wang1-2/+3
Set rx mode before calling netif_wake_queue() when linking on to avoid the device missing the receiving packets. The transmission may start after calling netif_wake_queue(), and the packets of resopnse may reach before calling rtl8152_set_rx_mode() which let the device could receive packets. Then, the packets of response would be missed. Signed-off-by: Hayes Wang <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2018-02-02r8152: fix wrong checksum status for received IPv4 packetsHayes Wang1-5/+3
The device could only check the checksum of TCP and UDP packets. Therefore, for the IPv4 packets excluding TCP and UDP, the check of checksum is necessary, even though the IP checksum is correct. Take ICMP for example, The IP checksum may be correct, but the ICMP checksum may be wrong. Signed-off-by: Hayes Wang <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2018-02-02nfp: fix TLV offset calculationEdwin Peer1-1/+1
The data pointer in the config space TLV parser already includes NFP_NET_CFG_TLV_BASE, it should not be added again. Incorrect offset values were only used in printed user output, rendering the bug merely cosmetic. Fixes: 73a0329b057e ("nfp: add TLV capabilities to the BAR") Signed-off-by: Edwin Peer <[email protected]> Reviewed-by: Jakub Kicinski <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2018-02-02Merge tag 'firewire-updates' of ↵Linus Torvalds2-2/+13
git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394 Pull firewire updates from Stefan Richter - make JMicron JMB38x controllers work with IOMMU-equipped systems - IP-over-1394: allow user-configured MTU of up to 4096 bytes * tag 'firewire-updates' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394: firewire-ohci: work around oversized DMA reads on JMicron controllers firewire: net: max MTU off by one