These parameters can be computed inside of the function from the
Table parameter.
Link: https://github.com/acpica/acpica/commit/3ba6fa55 Signed-off-by: Erik Kaneda <erik.kaneda@intel.com> Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Linus Torvalds [Fri, 14 Feb 2020 20:34:30 +0000 (12:34 -0800)]
Merge tag 'pm-5.6-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull power management fixes from Rafael Wysocki:
"Fix three issues related to the handling of wakeup events signaled
through the ACPI SCI while suspended to idle (Rafael Wysocki) and
unexport an internal cpufreq variable (Yangtao Li)"
* tag 'pm-5.6-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
ACPI: PM: s2idle: Prevent spurious SCIs from waking up the system
ACPICA: Introduce acpi_any_gpe_status_set()
ACPI: PM: s2idle: Avoid possible race related to the EC GPE
ACPI: EC: Fix flushing of pending work
cpufreq: Make cpufreq_global_kobject static
Linus Torvalds [Fri, 14 Feb 2020 20:27:54 +0000 (12:27 -0800)]
Merge tag 'sound-5.6-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
Pull sound fixes from Takashi Iwai:
"The only common change is the regression fix of the previous PCM fix
patch for managed buffers while the rest are usual suspects, USB-audio
and HD-audio device-specific quirks.
The change for UAC2 clock validation workaround became a bit big, but
the changes are fairly straightforward"
* tag 'sound-5.6-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
ALSA: pcm: Fix double hw_free calls
ALSA: usb-audio: Add clock validity quirk for Denon MC7000/MCX8000
ALSA: hda/realtek - Fix silent output on MSI-GL73
ALSA: hda/realtek - Add more codec supported Headset Button
ALSA: usb-audio: Apply sample rate quirk for Audioengine D1
ALSA: usb-audio: Fix UAC2/3 effect unit parsing
ALSA: usb-audio: Apply 48kHz fixed rate playback for Jabra Evolve 65 headset
Linus Torvalds [Fri, 14 Feb 2020 20:23:16 +0000 (12:23 -0800)]
Merge tag 'drm-fixes-2020-02-14' of git://anongit.freedesktop.org/drm/drm
Pull drm fixes from Dave Airlie:
"The core has a build fix for edid code on certain compilers/arches/,
one MST fix and one vgem fix. Regular amdgpu fixes, and a couple of
small driver fixes.
The i915 fixes are bit larger than normal for this stage, but they
were having CI issues last week, and they hadn't sent any fixes last
week due to this.
core:
- edid build fix
mst:
- fix NULL ptr deref
vgem:
- fix close after free
msm:
- better dma-api usage
sun4i:
- disable allow_fb_modifiers
amdgpu:
- Additional OD fixes for navi
- Misc display fixes
- VCN 2.5 DPG fix
- Prevent build errors on PowerPC on some configs
- GDS EDC fix
* tag 'drm-fixes-2020-02-14' of git://anongit.freedesktop.org/drm/drm: (50 commits)
drm/i915: Mark the removal of the i915_request from the sched.link
drm/i915/execlists: Reclaim the hanging virtual request
drm/i915/execlists: Take a reference while capturing the guilty request
drm/i915/execlists: Offline error capture
drm/i915/gt: Allow temporary suspension of inflight requests
drm/i915: Keep track of request among the scheduling lists
drm/i915/gem: Tighten checks and acquiring the mmap object
drm/i915: Fix preallocated barrier list append
drm/i915/gt: Acquire ce->active before ce->pin_count/ce->pin_mutex
drm/i915: Tighten atomicity of i915_active_acquire vs i915_active_release
drm/i915: Stub out i915_gpu_coredump_put
drm/amdgpu:/navi10: use the ODCAP enum to index the caps array
drm/amdgpu: update smu_v11_0_pptable.h
drm/amdgpu: correct comment to clear up the confusion
drm/amd/display: DCN2.x Do not program DPPCLK if same value
drm/amd/display: Don't map ATOM_ENABLE to ATOM_INIT
drm/amdgpu/vcn2.5: fix warning
drm/amdgpu: limit GDS clearing workaround in cold boot sequence
drm/amdgpu: fix amdgpu pmu to use hwc->config instead of hwc->conf
amdgpu: Prevent build errors regarding soft/hard-float FP ABI tags
...
Dave Airlie [Fri, 14 Feb 2020 03:03:51 +0000 (13:03 +1000)]
Merge tag 'drm-intel-next-fixes-2020-02-13' of git://anongit.freedesktop.org/drm/drm-intel into drm-fixes
drm/i915 fixes for v5.6-rc2
Most of these were aimed at a "next fixes" pull already during the merge
window, but there were issues with the baseline I used, which resulted
in a lot of issues in CI. I've regenerated this stuff piecemeal now,
adding gradually to it, and it seems healthy now.
Due to the issues this is much bigger than I'd like. But it was
obviously necessary to take the time to ensure it's not garbage...
Dave Airlie [Fri, 14 Feb 2020 02:52:49 +0000 (12:52 +1000)]
Merge tag 'drm-misc-fixes-2020-02-07' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes
Fixes for v5.6:
- Revert allow_fb_modifiers in sun4i, as it causes a regression for DE2 and DE3.
- Fix null pointer deref in drm_dp_mst_process_up_req().
Linus Torvalds [Thu, 13 Feb 2020 22:36:57 +0000 (14:36 -0800)]
Merge tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux
Pull arm64 fixes from Will Deacon:
"Summary below, but it's all reasonably straightforward. There are some
more fixes on the horizon, but nothing disastrous yet.
Summary:
- Fix build when KASLR is enabled but CONFIG_ARCH_RANDOM is not set
- Fix context-switching of SSBS state on systems that implement it
- Fix spinlock compiler warning introduced during the merge window
- Use SYSCTL_{ZERO,ONE} instead of rolling our own static variables
- Don't scream if optional SMMUv3 PMU irq is missing
- Remove some unused function prototypes"
* tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux:
arm64: time: Replace <linux/clk-provider.h> by <linux/of_clk.h>
arm64: Fix CONFIG_ARCH_RANDOM=n build
perf/smmuv3: Use platform_get_irq_optional() for wired interrupt
arm64/spinlock: fix a -Wunused-function warning
arm64: ssbs: Fix context-switch when SSBS is present on all CPUs
arm64: use shared sysctl constants
arm64: Drop do_el0_ia_bp_hardening() & do_sp_pc_abort() declarations
Linus Torvalds [Thu, 13 Feb 2020 22:34:58 +0000 (14:34 -0800)]
Merge tag 'gpio-v5.6-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio
Pull GPIO fixes from Linus Walleij:
- Revert two patches to gpio_do_set_config() and implement the proper
solution that works, also drop an unecessary call in set_config()
- Fix up the lockdep class for hierarchical IRQ domains.
- Remove some bridge code for line directions.
- Fix a register access bug in the Xilinx driver.
* tag 'gpio-v5.6-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio:
gpio: sifive: fix static checker warning
spmi: pmic-arb: Set lockdep class for hierarchical irq domains
gpio: xilinx: Fix bug where the wrong GPIO register is written to
gpiolib: remove unnecessary argument from set_config call
gpio: bd71828: Remove unneeded defines for GPIO_LINE_DIRECTION_IN/OUT
MAINTAINERS: Sort entries in database for GPIO
gpiolib: fix gpio_do_set_config()
Revert "gpiolib: remove set but not used variable 'config'"
Revert "gpiolib: Remove duplicated function gpio_do_set_config()"
Takashi Iwai [Thu, 13 Feb 2020 06:03:49 +0000 (07:03 +0100)]
ALSA: pcm: Fix double hw_free calls
The commit 66f2d19f8116 ("ALSA: pcm: Fix memory leak at closing a
stream without hw_free") tried to fix the regression wrt the missing
hw_free call at closing without SNDRV_PCM_IOCTL_HW_FREE ioctl.
However, the code change dropped mistakenly the state check, resulting
in calling hw_free twice when SNDRV_PCM_IOCTL_HW_FRE got called
beforehand. For most drivers, this is almost harmless, but the
drivers like SOF show another regression now.
This patch adds the state condition check before calling do_hw_free()
at releasing the stream for avoiding the double hw_free calls.
Alexander Tsoy [Wed, 12 Feb 2020 23:54:50 +0000 (02:54 +0300)]
ALSA: usb-audio: Add clock validity quirk for Denon MC7000/MCX8000
It should be safe to ignore clock validity check result if the following
conditions are met:
- only one single sample rate is supported;
- the terminal is directly connected to the clock source;
- the clock type is internal.
This is to deal with some Denon DJ controllers that always reports that
clock is invalid.
Randy Dunlap [Mon, 10 Feb 2020 03:36:14 +0000 (19:36 -0800)]
linux/pipe_fs_i.h: fix kernel-doc warnings after @wait was split
Fix kernel-doc warnings in struct pipe_inode_info after @wait was
split into @rd_wait and @wr_wait.
include/linux/pipe_fs_i.h:66: warning: Function parameter or member 'rd_wait' not described in 'pipe_inode_info'
include/linux/pipe_fs_i.h:66: warning: Function parameter or member 'wr_wait' not described in 'pipe_inode_info'
Fixes: 0ddad21d3e99 ("pipe: use exclusive waits when reading or writing") Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Linus Torvalds [Wed, 12 Feb 2020 18:28:42 +0000 (10:28 -0800)]
Merge tag 'kbuild-fixes-v5.6' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild
Pull Kbuild fixes from Masahiro Yamada:
- fix memory corruption in scripts/kallsyms
- fix the vmlinux link stage to correctly update compile.h
* tag 'kbuild-fixes-v5.6' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild:
kbuild: fix mismatch between .version and include/generated/compile.h
scripts/kallsyms: fix memory corruption caused by write over-run
Chris Wilson [Wed, 22 Jan 2020 14:02:43 +0000 (14:02 +0000)]
drm/i915: Mark the removal of the i915_request from the sched.link
Keep the rq->fence.flags consistent with the status of the
rq->sched.link, and clear the associated bits when decoupling the link
on retirement (as we may wish to inspect those flags independent of
other state).
Chris Wilson [Wed, 22 Jan 2020 14:02:42 +0000 (14:02 +0000)]
drm/i915/execlists: Reclaim the hanging virtual request
If we encounter a hang on a virtual engine, as we process the hang the
request may already have been moved back to the virtual engine (we are
processing the hang on the physical engine). We need to reclaim the
request from the virtual engine so that the locking is consistent and
local to the real engine on which we will hold the request for error
state capturing.
v2: Pull the reclamation into execlists_hold() and assert that cannot be
called from outside of the reset (i.e. with the tasklet disabled).
v3: Added selftest
v4: Drop the reference owned by the virtual engine
Chris Wilson [Wed, 22 Jan 2020 14:02:41 +0000 (14:02 +0000)]
drm/i915/execlists: Take a reference while capturing the guilty request
Thanks to preempt-to-busy, we leave the request on the HW as we submit
the preemption request. This means that the request may complete at any
moment as we process HW events, and in particular the request may be
retired as we are planning to capture it for a preemption timeout.
Be more careful while obtaining the request to capture after a
preemption timeout, and check to see if it completed before we were able
to put it on the on-hold list. If we do see it did complete just before
we capture the request, proclaim the preemption-timeout a false positive
and pardon the reset as we should hit an arbitration point momentarily
and so be able to process the preemption.
Note that even after we move the request to be on hold it may be retired
(as the reset to stop the HW comes after), so we do require to hold our
own reference as we work on the request for capture (and all of the
peeking at state within the request needs to be carefully protected).
Chris Wilson [Thu, 16 Jan 2020 18:47:54 +0000 (18:47 +0000)]
drm/i915/execlists: Offline error capture
Currently, we skip error capture upon forced preemption. We apply forced
preemption when there is a higher priority request that should be
running but is being blocked, and we skip inline error capture so that
the preemption request is not further delayed by a user controlled
capture -- extending the denial of service.
However, preemption reset is also used for heartbeats and regular GPU
hangs. By skipping the error capture, we remove the ability to debug GPU
hangs.
In order to capture the error without delaying the preemption request
further, we can do an out-of-line capture by removing the guilty request
from the execution queue and scheduling a worker to dump that request.
When removing a request, we need to remove the entire context and all
descendants from the execution queue, so that they do not jump past.
Closes: https://gitlab.freedesktop.org/drm/intel/issues/738 Fixes: 3a7a92aba8fb ("drm/i915/execlists: Force preemption") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200116184754.2860848-3-chris@chris-wilson.co.uk
(cherry picked from commit 748317386afb235e11616098d2c7772e49776b58) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Chris Wilson [Thu, 16 Jan 2020 18:47:53 +0000 (18:47 +0000)]
drm/i915/gt: Allow temporary suspension of inflight requests
In order to support out-of-line error capture, we need to remove the
active request from HW and put it to one side while a worker compresses
and stores all the details associated with that request. (As that
compression may take an arbitrary user-controlled amount of time, we
want to let the engine continue running on other workloads while the
hanging request is dumped.) Not only do we need to remove the active
request, but we also have to remove its context and all requests that
were dependent on it (both in flight, queued and future submission).
Finally once the capture is complete, we need to be able to resubmit the
request and its dependents and allow them to execute.
v2: Replace stack recursion with a simple list.
v3: Check all the parents, not just the first, when searching for a
stuck ancestor!
Chris Wilson [Thu, 16 Jan 2020 18:47:52 +0000 (18:47 +0000)]
drm/i915: Keep track of request among the scheduling lists
If we keep track of when the i915_request.sched.link is on the HW
runlist, or in the priority queue we can simplify our interactions with
the request (such as during rescheduling). This also simplifies the next
patch where we introduce a new in-between list, for requests that are
ready but neither on the run list or in the queue.
v2: Update i915_sched_node.link explanation for current usage where it
is a link on both the queue and on the runlists.
Only the first and the last nodes were being added to
ref->preallocated_barriers.
Renaming variables to make it more easy to read.
Fixes: 841350223816 ("drm/i915/gt: Drop mutex serialisation between context pin/unpin") Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20200129232345.84512-1-jose.souza@intel.com
(cherry picked from commit d4c3c0b8221a72107eaf35c80c40716b81ca463e) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Chris Wilson [Mon, 27 Jan 2020 15:28:29 +0000 (15:28 +0000)]
drm/i915/gt: Acquire ce->active before ce->pin_count/ce->pin_mutex
Similar to commit ac0e331a628b ("drm/i915: Tighten atomicity of
i915_active_acquire vs i915_active_release") we have the same race of
trying to pin the context underneath a mutex while allowing the
decrement to be atomic outside of that mutex. This leads to the problem
where two threads may simultaneously try to pin the context and the
second not notice that they needed to repin the context.
Chris Wilson [Sun, 26 Jan 2020 10:23:43 +0000 (10:23 +0000)]
drm/i915: Tighten atomicity of i915_active_acquire vs i915_active_release
As we use a mutex to serialise the first acquire (as it may be a lengthy
operation), but only an atomic decrement for the release, we have to
be careful in case a second thread races and completes both
acquire/release as the first finishes its acquire.
So thread A has acquired the ref->active_count but since the ref was
still active at the time, it did not initialise it. By switching the
check inside the mutex to an atomic increment only if already active, we
close the race.
Takashi Iwai [Wed, 12 Feb 2020 08:10:47 +0000 (09:10 +0100)]
ALSA: hda/realtek - Fix silent output on MSI-GL73
MSI-GL73 laptop with ALC1220 codec requires a similar workaround for
Clevo laptops to enforce the DAC/mixer connection path. Set up a
quirk entry for that.
Linus Torvalds [Wed, 12 Feb 2020 00:52:08 +0000 (16:52 -0800)]
Merge tag 'dax-fixes-5.6-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm
Pull dax fixes from Dan Williams:
"A fix for an xfstest failure and some and an update that removes an
fsdax dependency on block devices.
Summary:
- Fix RWF_NOWAIT writes to properly return -EAGAIN
- Clean up an unused helper
- Update dax_writeback_mapping_range to not need a block_device
argument"
* tag 'dax-fixes-5.6-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm:
dax: pass NOWAIT flag to iomap_apply
dax: Get rid of fs_dax_get_by_host() helper
dax: Pass dax_dev instead of bdev to dax_writeback_mapping_range()
ACPI: PM: s2idle: Prevent spurious SCIs from waking up the system
If the platform triggers a spurious SCI even though the status bit
is not set for any GPE when the system is suspended to idle, it will
be treated as a genuine wakeup, so avoid that by checking if any GPEs
are active at all before returning 'true' from acpi_s2idle_wake().
Link: https://bugzilla.kernel.org/show_bug.cgi?id=206413 Fixes: 56b991849009 ("PM: sleep: Simplify suspend-to-idle control flow") Reported-by: Tsuchiya Yuto <kitakar@gmail.com> Cc: 5.4+ <stable@vger.kernel.org> # 5.4+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Alex Deucher [Thu, 6 Feb 2020 19:53:06 +0000 (14:53 -0500)]
drm/amdgpu:/navi10: use the ODCAP enum to index the caps array
Rather than the FEATURE_ID flags. Avoids a possible reading past
the end of the array.
Reviewed-by: Evan Quan <evan.quan@amd.com> Reported-by: Aleksandr Mezin <mezin.alexander@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org # 5.5.x
Guchun Chen [Tue, 11 Feb 2020 04:10:44 +0000 (12:10 +0800)]
drm/amdgpu: correct comment to clear up the confusion
Former comment looks to be one intended behavior in code,
actually it's not. So correct it.
Suggested-by: Christian König <christian.koenig@amd.com> Signed-off-by: Guchun Chen <guchun.chen@amd.com> Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
drm/amd/display: Don't map ATOM_ENABLE to ATOM_INIT
[Why]
In DCN hardware sequencer we do actually call ATOM_INIT correctly per
pipe. The workaround is not necessary for command table offloading.
[How]
Drop the workaround since it's not needed.
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by: Chris Park <Chris.Park@amd.com> Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Guchun Chen [Sun, 9 Feb 2020 08:21:09 +0000 (16:21 +0800)]
drm/amdgpu: limit GDS clearing workaround in cold boot sequence
GDS clear workaround will cause gfx failure in suspend/resume case.
[ 98.679559] [drm:amdgpu_device_ip_late_init [amdgpu]] *ERROR* late_init of IP block <gfx_v9_0> failed -110
[ 98.679561] PM: dpm_run_callback(): pci_pm_resume+0x0/0xa0 returns -110
[ 98.679562] PM: Device 0000:03:00.0 failed to resume async: error -110
As this workaround is specific to the HW bug of GDS's ECC error
existing in cold boot up, so bypass this workaround in suspend/
resume case after booting up.
Jonathan Kim [Thu, 6 Feb 2020 16:57:11 +0000 (11:57 -0500)]
drm/amdgpu: fix amdgpu pmu to use hwc->config instead of hwc->conf
hwc->conf was designated specifically for AMD APU IOMMU purposes. This
could cause problems in performance and/or function since APU IOMMU
implementation is elsewhere. Also hwc->conf and hwc->config are
different members of an anonymous union so hwc->conf aliases as
hw->last_tag.
Signed-off-by: Jonathan Kim <Jonathan.Kim@amd.com> Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Daniel Kolesa [Thu, 6 Feb 2020 19:14:35 +0000 (20:14 +0100)]
amdgpu: Prevent build errors regarding soft/hard-float FP ABI tags
On PowerPC, the compiler will tag object files with whether they
use hard or soft float FP ABI and whether they use 64 or 128-bit
long double ABI. On systems with 64-bit long double ABI, a tag
will get emitted whenever a double is used, as on those systems
a long double is the same as a double. This will prevent linkage
as other files are being compiled with hard-float.
On ppc64, this code will never actually get used for the time
being, as the only currently existing hardware using it are the
Renoir APUs. Therefore, until this is testable and can be fixed
properly, at least make sure the build will not fail.
Signed-off-by: Daniel Kolesa <daniel@octaforge.org> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Isabel Zhang [Mon, 27 Jan 2020 15:57:16 +0000 (10:57 -0500)]
drm/amd/display: Add initialitions for PLL2 clock source
[Why]
Starting from 14nm, the PLL is built into the PHY and the PLL is mapped
to PHY on 1 to 1 basis. In the code, the DP port is mapped to a PLL that was not
initialized. This causes DP to HDMI dongle to not light up the display.
[How]
Initializations added for PLL2 when creating resources.
Signed-off-by: Isabel Zhang <isabel.zhang@amd.com> Reviewed-by: Eric Yang <eric.yang2@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Yongqiang Sun [Thu, 23 Jan 2020 21:30:15 +0000 (16:30 -0500)]
drm/amd/display: Limit minimum DPPCLK to 100MHz.
[Why]
Underflow is observed when plug in a 4K@60 monitor with
1366x768 eDP due to DPPCLK is too low.
[How]
Limit minimum DPPCLK to 100MHz.
Signed-off-by: Yongqiang Sun <yongqiang.sun@amd.com> Reviewed-by: Eric Yang <eric.yang2@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Arvind Sankar [Tue, 11 Feb 2020 16:22:35 +0000 (11:22 -0500)]
ALSA: usb-audio: Apply sample rate quirk for Audioengine D1
The Audioengine D1 (0x2912:0x30c8) does support reading the sample rate,
but it returns the rate in byte-reversed order.
When setting sampling rate, the driver produces these warning messages:
[168840.944226] usb 3-2.2: current rate 4500480 is different from the runtime rate 44100
[168854.930414] usb 3-2.2: current rate 8436480 is different from the runtime rate 48000
[168905.185825] usb 3-2.1.2: current rate 30465 is different from the runtime rate 96000
As can be seen from the hexadecimal conversion, the current rate read
back is byte-reversed from the rate that was set.
Sung Lee [Mon, 20 Jan 2020 23:58:45 +0000 (18:58 -0500)]
drm/amd/display: Use dcfclk to populate watermark ranges
[WHY & HOW]
Previously drain clk was unconstrained and fill clk was constrained on fclk.
We want to change it to fill clk unconstrained and drain clock constrained
to dcfclk.
Signed-off-by: Sung Lee <sung.lee@amd.com> Reviewed-by: Tony Cheng <Tony.Cheng@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Sung Lee [Wed, 15 Jan 2020 16:55:06 +0000 (11:55 -0500)]
drm/amd/display: Do not set optimized_require to false after plane disable
[WHY]
The optimized_require flag is needed to set watermarks and clocks lower
in certain conditions. This flag is set to true and then set to false
while programming front end in dcn20.
[HOW]
Do not set the flag to false while disabling plane.
Signed-off-by: Sung Lee <sung.lee@amd.com> Reviewed-by: Tony Cheng <Tony.Cheng@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Roman Li [Tue, 14 Jan 2020 18:56:08 +0000 (13:56 -0500)]
drm/amd/display: Fix psr static frames calculation
[Why]
Driver crash with psr feature enabled due to divide-by-zero error.
This is a regression after rework to calculate static screen frame
number entry time.
[How]
Correct order of operations to avoid divide-by-zero.
Signed-off-by: Roman Li <roman.li@amd.com> Reviewed-by: Zhan Liu <Zhan.Liu@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Takashi Iwai [Tue, 11 Feb 2020 16:05:21 +0000 (17:05 +0100)]
ALSA: usb-audio: Fix UAC2/3 effect unit parsing
We've got a regression report about M-Audio Fast Track C400 device,
and the git bisection resulted in the commit e0ccdef92653 ("ALSA:
usb-audio: Clean up check_input_term()"). This commit was about the
rewrite of the input terminal parser, and it's not too obvious from
the change what really broke. The answer is: it's the interpretation
of UAC2/3 effect units.
In the original code, UAC2 effect unit is as if through UAC1
processing unit because both UAC1 PU and UAC2/3 EU share the same
number (0x07). The old code went through a complex switch-case
fallthrough, finally bailing out in the middle:
if (protocol == UAC_VERSION_2 &&
hdr[2] == UAC2_EFFECT_UNIT) {
/* UAC2/UAC1 unit IDs overlap here in an
* uncompatible way. Ignore this unit for now.
*/
return 0;
}
... and this special handling was missing in the new code; the new
code treats UAC2/3 effect unit as if it were equivalent with the
processing unit.
Actually, the old code was too confusing. The effect unit has an
incompatible unit description with the processing unit, so we
shouldn't have dealt with EU in the same way.
This patch addresses the regression by changing the effect unit
handling to the own parser function. The own parser function makes
the clear distinct with PU, so it improves the readability, too.
The EU parser just sets the type and the id like the old kernels.
Once when the proper effect unit support is added, we can revisit this
parser function, but for now, let's keep this simple setup as is.
Jabra Evolve 65 headset appears as if supporting lower rates than
48kHz, but it actually doesn't work but with 48kHz for playback.
This patch applies a workaround to enforce the 48kHz like LINE6
devices already did. The workaround is put in a unified helper
function, set_fixed_rate(), to be called from both places now.
Chris Wilson [Thu, 23 Jan 2020 22:44:58 +0000 (22:44 +0000)]
drm/i915: Check activity on i915_vma after confirming pin_count==0
Only assert that the i915_vma is now idle if and only if no other pins
are present. If another user has the i915_vma pinned, they may submit
more work to the i915_vma skipping the vm->mutex used to serialise the
unbind. We need to wait again, if we want to continue and unbind this
vma.
However, if we own the i915_vma (we hold the vm->mutex for the unbind
and the pin_count is 0), we can assert that the vma remains idle as we
unbind.
Chris Wilson [Mon, 20 Jan 2020 10:49:22 +0000 (10:49 +0000)]
drm/i915/gem: Store mmap_offsets in an rbtree rather than a plain list
Currently we create a new mmap_offset for every call to
mmap_offset_ioctl. This exposes ourselves to an abusive client that may
simply create new mmap_offsets ad infinitum, which will exhaust physical
memory and the virtual address space. In addition to the exhaustion, a
very long linear list of mmap_offsets causes other clients using the
object to incur long list walks -- these long lists can also be
generated by simply having many clients generate their own mmap_offset.
However, we can simply use the drm_vma_node itself to manage the file
association (allow/revoke) dropping our need to keep an mmo per-file.
Then if we keep a small rbtree of per-type mmap_offsets, we can lookup
duplicate requests quickly.
Chris Wilson [Wed, 15 Jan 2020 17:58:29 +0000 (17:58 +0000)]
drm/i915/execlists: Leave resetting ring to intel_ring
We need to allow concurrent intel_context_unpin, which means avoiding
doing destructive operations like intel_ring_reset(). This was already
fixed for intel_ring_unpin() in commit 0725d9a31869 ("drm/i915/gt: Make
intel_ring_unpin() safe for concurrent pint"), but I overlooked that
execlists_context_unpin() also made the same mistake.
Reported-by: Matthew Brost <matthew.brost@intel.com> Fixes: 841350223816 ("drm/i915/gt: Drop mutex serialisation between context pin/unpin")
References: 0725d9a31869 ("drm/i915/gt: Make intel_ring_unpin() safe for concurrent pint") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Matthew Auld <matthew.auld@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200115175829.2761329-1-chris@chris-wilson.co.uk
(cherry picked from commit f3c0efc9fe7a4e61544034f525348a3aa86ac5aa) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Robin Murphy [Mon, 10 Feb 2020 19:21:01 +0000 (19:21 +0000)]
arm64: Fix CONFIG_ARCH_RANDOM=n build
The entire asm/archrandom.h header is generically included via
linux/archrandom.h only when CONFIG_ARCH_RANDOM is already set, so the
stub definitions of __arm64_rndr() and __early_cpu_has_rndr() are only
visible to KASLR if it explicitly includes the arch-internal header.
Acked-by: Mark Brown <broonie@kernel.org> Signed-off-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Will Deacon <will@kernel.org>
ACPI: PM: s2idle: Avoid possible race related to the EC GPE
It is theoretically possible for the ACPI EC GPE to be set after the
s2idle_ops->wake() called from s2idle_loop() has returned and before
the subsequent pm_wakeup_pending() check is carried out. If that
happens, the resulting wakeup event will cause the system to resume
even though it may be a spurious one.
To avoid that race, first make the ->wake() callback in struct
platform_s2idle_ops return a bool value indicating whether or not
to let the system resume and rearrange s2idle_loop() to use that
value instad of the direct pm_wakeup_pending() call if ->wake() is
present.
Next, rework acpi_s2idle_wake() to process EC events and check
pm_wakeup_pending() before re-arming the SCI for system wakeup
to prevent it from triggering prematurely and add comments to
that function to explain the rationale for the new code flow.
Fixes: 56b991849009 ("PM: sleep: Simplify suspend-to-idle control flow") Cc: 5.4+ <stable@vger.kernel.org> # 5.4+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Commit 016b87ca5c8c ("ACPI: EC: Rework flushing of pending work")
introduced a subtle bug into the flushing of pending EC work while
suspended to idle, which may cause the EC driver to fail to
re-enable the EC GPE after handling a non-wakeup event (like a
battery status change event, for example).
The problem is that the work item flushed by flush_scheduled_work()
in __acpi_ec_flush_work() may disable the EC GPE and schedule another
work item expected to re-enable it, but that new work item is not
flushed, so __acpi_ec_flush_work() returns with the EC GPE disabled
and the CPU running it goes into an idle state subsequently. If all
of the other CPUs are in idle states at that point, the EC GPE won't
be re-enabled until at least one CPU is woken up by another interrupt
source, so system wakeup events that would normally come from the EC
then don't work.
This is reproducible on a Dell XPS13 9360 in my office which
sometimes stops reacting to power button and lid events (triggered
by the EC on that machine) after switching from AC power to battery
power or vice versa while suspended to idle (each of those switches
causes the EC GPE to trigger for several times in a row, but they
are not system wakeup events).
To avoid this problem, it is necessary to drain the workqueue
entirely in __acpi_ec_flush_work(), but that cannot be done with
respect to system_wq, because work items may be added to it from
other places while __acpi_ec_flush_work() is running. For this
reason, make the EC driver use a dedicated workqueue for EC events
processing (let that workqueue be ordered so that EC events are
processed sequentially) and use drain_workqueue() on it in
__acpi_ec_flush_work().
Fixes: 016b87ca5c8c ("ACPI: EC: Rework flushing of pending work") Cc: 5.4+ <stable@vger.kernel.org> # 5.4+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tom Zanussi [Mon, 10 Feb 2020 23:06:50 +0000 (17:06 -0600)]
tracing: Consolidate trace() functions
Move the checking, buffer reserve and buffer commit code in
synth_event_trace_start/end() into inline functions
__synth_event_trace_start/end() so they can also be used by
synth_event_trace() and synth_event_trace_array(), and then have all
those functions use them.
Also, change synth_event_trace_state.enabled to disabled so it only
needs to be set if the event is disabled, which is not normally the
case.
Tom Zanussi [Mon, 10 Feb 2020 23:06:49 +0000 (17:06 -0600)]
tracing: Don't return -EINVAL when tracing soft disabled synth events
There's no reason to return -EINVAL when tracing a synthetic event if
it's soft disabled - treat it the same as if it were hard disabled and
return normally.
Have synth_event_trace() and synth_event_trace_array() just return
normally, and have synth_event_trace_start set the trace state to
disabled and return.
Tom Zanussi [Mon, 10 Feb 2020 23:06:48 +0000 (17:06 -0600)]
tracing: Add missing nest end to synth_event_trace_start() error case
If the ring_buffer reserve in synth_event_trace_start() fails, the
matching ring_buffer_nest_end() should be called in the error code,
since nothing else will ever call it in this case.
Linus Torvalds [Tue, 11 Feb 2020 01:07:05 +0000 (17:07 -0800)]
Merge branch 'for-5.6-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup
Pull cgroup fix from Tejun Heo:
"I made a mistake while removing cgroup task list lazy init
optimization making the root cgroup.procs show entries for the
init_tasks. The zero entries doesn't cause critical failures but does
make systemd print out warning messages during boot.
Fix it by omitting init_tasks as they should be"
* 'for-5.6-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup:
cgroup: init_tasks shouldn't be linked to the root cgroup
Linus Torvalds [Tue, 11 Feb 2020 00:51:35 +0000 (16:51 -0800)]
Merge tag 'selinux-pr-20200210' of git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/selinux
Pull SELinux fixes from Paul Moore:
"Two small fixes: one fixes a locking problem in the recently merged
label translation code, the other fixes an embarrassing 'binderfs' /
'binder' filesystem name check"
* tag 'selinux-pr-20200210' of git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/selinux:
selinux: fix sidtab string cache locking
selinux: fix typo in filesystem name
Suppress non-error messages when applying new bootconfig
to initrd image. To enable it, replace printf for error
message with pr_err() macro.
This also adds a testcase for this fix.
Masahiro Yamada [Mon, 10 Feb 2020 20:06:34 +0000 (05:06 +0900)]
kbuild: fix mismatch between .version and include/generated/compile.h
Since commit 56d589361572 ("kbuild: do not create orphan built-in.a or
obj-y objects"), scripts/link-vmlinux.sh does nothing when descending
into init/.
Once the version number becomes out of sync between .version and
include/generated/compile.h, it is not self-healing.
[How to reproduce]
$ echo 100 > .version
$ make
You will see the number in the .version is always bigger than that in
compile.h by one. After this, every time you run 'make', the vmlinux is
re-linked even when none of source files is updated.
Fixes: 56d589361572 ("kbuild: do not create orphan built-in.a or obj-y objects") Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
John Garry [Mon, 10 Feb 2020 16:50:17 +0000 (00:50 +0800)]
perf/smmuv3: Use platform_get_irq_optional() for wired interrupt
Even though a SMMUv3 PMCG implementation may use an MSI as the form of
interrupt source, the kernel would still complain that it does not find
the wired (GSIV) interrupt in this case:
root@(none)$ dmesg | grep arm-smmu-v3-pmcg | grep "not found"
[ 59.237219] arm-smmu-v3-pmcg arm-smmu-v3-pmcg.8.auto: IRQ index 0 not found
[ 59.322841] arm-smmu-v3-pmcg arm-smmu-v3-pmcg.9.auto: IRQ index 0 not found
[ 59.422155] arm-smmu-v3-pmcg arm-smmu-v3-pmcg.10.auto: IRQ index 0 not found
[ 59.539014] arm-smmu-v3-pmcg arm-smmu-v3-pmcg.11.auto: IRQ index 0 not found
[ 59.640329] arm-smmu-v3-pmcg arm-smmu-v3-pmcg.12.auto: IRQ index 0 not found
[ 59.743112] arm-smmu-v3-pmcg arm-smmu-v3-pmcg.13.auto: IRQ index 0 not found
[ 59.880577] arm-smmu-v3-pmcg arm-smmu-v3-pmcg.14.auto: IRQ index 0 not found
[ 60.017528] arm-smmu-v3-pmcg arm-smmu-v3-pmcg.15.auto: IRQ index 0 not found
Use platform_get_irq_optional() to silence the warning.
If neither interrupt source is found, then the driver will still warn that
IRQ setup errored and the probe will fail.
Reviewed-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: John Garry <john.garry@huawei.com> Signed-off-by: Will Deacon <will@kernel.org>
bootconfig: Use parse_args() to find bootconfig and '--'
The current implementation does a naive search of "bootconfig" on the kernel
command line. But this could find "bootconfig" that is part of another
option in quotes (although highly unlikely). But it also needs to find '--'
on the kernel command line to know if it should append a '--' or not when a
bootconfig in the initrd file has an "init" section. The check uses the
naive strstr() to find to see if it exists. But this can return a false
positive if it exists in an option and then the "init" section in the initrd
will not be appended properly.
Using parse_args() to find both of these will solve both of these problems.
Link: https://lore.kernel.org/r/202002070954.C18E7F58B@keescook Fixes: 7495e0926fdf3 ("bootconfig: Only load bootconfig if "bootconfig" is on the kernel cmdline") Fixes: 1319916209ce8 ("bootconfig: init: Allow admin to use bootconfig for init command line") Reported-by: Kees Cook <keescook@chromium.org> Reviewed-by: Kees Cook <keescook@chromium.org> Acked-by: Masami Hiramatsu <mhiramat@kernel.org> Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Since there is no user except CONFIG_BOOT_CONFIG and no plan
to use it from other functions, CONFIG_LIBXBC can be removed
and we can use CONFIG_BOOT_CONFIG directly.
Since printk() wrapper macro uses __VA_ARGS__ without "##" prefix, it causes
a build error if there is no variable arguments (e.g. only fmt is
specified.) To fix this error, use ##__VA_ARGS__ instead of __VAR_ARGS__.
Link: http://lkml.kernel.org/r/158108370130.2758.10893830923800978011.stgit@devnote2 Fixes: 950313ebf79c ("tools: bootconfig: Add bootconfig command") Reported-by: Michael Ellerman <mpe@ellerman.id.au> Tested-by: Michael Ellerman <mpe@ellerman.id.au> Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org> Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Ville Syrjälä [Fri, 10 Jan 2020 18:32:23 +0000 (20:32 +0200)]
drm/i915: Make a copy of the ggtt view for slave plane
intel_prepare_plane_fb() will always pin plane_state->hw.fb whenever
it is present. We copy that from the master plane to the slave plane,
but we fail to copy the corresponding ggtt view. Thus when it comes time
to pin the slave plane's fb we use some stale ggtt view left over from
the last time the plane was used as a non-slave plane. If that previous
use involved 90/270 degree rotation or remapping we'll try to shuffle
the pages of the new fb around accordingingly. However the new
fb may be backed by a bo with less pages than what the ggtt view
rotation/remapped info requires, and so we we trip a GEM_BUG().
Steps to reproduce on icl:
1. plane 1: whatever
plane 6: largish !NV12 fb + 90 degree rotation
2. plane 1: smallish NV12 fb
plane 6: make invisible so it gets slaved to plane 1
3. GEM_BUG()
Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Closes: https://gitlab.freedesktop.org/drm/intel/issues/951 Fixes: 1f594b209fe1 ("drm/i915: Remove special case slave handling during hw programming, v3.") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200110183228.8199-1-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
(cherry picked from commit 103605e0d1e77cfb5d0f5a9e8aba7d97f1b49339) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Chris Wilson [Mon, 13 Jan 2020 15:45:55 +0000 (15:45 +0000)]
drm/i915/gem: Take local vma references for the parser
Take and hold a reference to each of the vma (and their objects) as we
process them with the cmdparser. This stops them being freed during the
work if the GEM execbuf is interrupted and the request we expected to
keep the objects alive is incomplete.
Chris Wilson [Tue, 14 Jan 2020 10:56:47 +0000 (10:56 +0000)]
drm/i915/pmu: Correct the rc6 offset upon enabling
The rc6 residency starts ticking from 0 from BIOS POST, but the kernel
starts measuring the time from its boot. If we start measuruing
I915_PMU_RC6_RESIDENCY while the GT is idle, we start our sampling from
0 and then upon first activity (park/unpark) add in all the rc6
residency since boot. After the first park with the sampler engaged, the
sleep/active counters are aligned.
Stephen Boyd [Tue, 21 Jan 2020 18:37:48 +0000 (10:37 -0800)]
spmi: pmic-arb: Set lockdep class for hierarchical irq domains
I see the following lockdep splat in the qcom pinctrl driver when
attempting to suspend the device.
WARNING: possible recursive locking detected
5.4.11 #3 Tainted: G W
--------------------------------------------
cat/3074 is trying to acquire lock: ffffff81f49804c0 (&irq_desc_lock_class){-.-.}, at: __irq_get_desc_lock+0x64/0x94
but task is already holding lock: ffffff81f1cc10c0 (&irq_desc_lock_class){-.-.}, at: __irq_get_desc_lock+0x64/0x94
other info that might help us debug this:
Possible unsafe locking scenario:
Paul Thomas [Sat, 25 Jan 2020 22:14:10 +0000 (17:14 -0500)]
gpio: xilinx: Fix bug where the wrong GPIO register is written to
Care is taken with "index", however with the current version
the actual xgpio_writereg is using index for data but
xgpio_regoffset(chip, i) for the offset. And since i is already
incremented it is incorrect. This patch fixes it so that index
is used for the offset too.
Linus Walleij [Mon, 10 Feb 2020 11:47:26 +0000 (12:47 +0100)]
Merge tag 'gpio-fixes-for-v5.6-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux into fixes
gpio fixes for v5.6-rc2
- fix a regression introduced by gpio_do_set_config()
- sort GPIO entries in MAINTAINERS
- remove leftover defines in gpio-bd71828
- remove an redundant switch case in gpio_set_config()
Qian Cai [Thu, 23 Jan 2020 20:20:51 +0000 (15:20 -0500)]
arm64/spinlock: fix a -Wunused-function warning
The commit f5bfdc8e3947 ("locking/osq: Use optimized spinning loop for
arm64") introduced a warning from Clang because vcpu_is_preempted() is
compiled away,
kernel/locking/osq_lock.c:25:19: warning: unused function 'node_cpu'
[-Wunused-function]
static inline int node_cpu(struct optimistic_spin_node *node)
^
1 warning generated.
Fix it by converting vcpu_is_preempted() to a static inline function.
Fixes: f5bfdc8e3947 ("locking/osq: Use optimized spinning loop for arm64") Acked-by: Waiman Long <longman@redhat.com> Signed-off-by: Qian Cai <cai@lca.pw> Signed-off-by: Will Deacon <will@kernel.org>
Will Deacon [Thu, 6 Feb 2020 10:42:58 +0000 (10:42 +0000)]
arm64: ssbs: Fix context-switch when SSBS is present on all CPUs
When all CPUs in the system implement the SSBS extension, the SSBS field
in PSTATE is the definitive indication of the mitigation state. Further,
when the CPUs implement the SSBS manipulation instructions (advertised
to userspace via an HWCAP), EL0 can toggle the SSBS field directly and
so we cannot rely on any shadow state such as TIF_SSBD at all.
Avoid forcing the SSBS field in context-switch on such a system, and
simply rely on the PSTATE register instead.
Cc: <stable@vger.kernel.org> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Srinivas Ramana <sramana@codeaurora.org> Fixes: cbdf8a189a66 ("arm64: Force SSBS on context switch") Reviewed-by: Marc Zyngier <maz@kernel.org> Signed-off-by: Will Deacon <will@kernel.org>
Matteo Croce [Fri, 24 Jan 2020 15:51:27 +0000 (16:51 +0100)]
arm64: use shared sysctl constants
Use shared sysctl variables for zero and one constants, as in
commit eec4844fae7c ("proc/sysctl: add shared variables for range check")
Fixes: 63f0c6037965 ("arm64: Introduce prctl() options to control the tagged user addresses ABI") Signed-off-by: Matteo Croce <mcroce@redhat.com> Signed-off-by: Will Deacon <will@kernel.org>
arm64: Drop do_el0_ia_bp_hardening() & do_sp_pc_abort() declarations
There is a redundant do_sp_pc_abort() declaration in exceptions.h which can
be removed. Also do_el0_ia_bp_hardening() as been already been dropped with
the commit bfe298745afc ("arm64: entry-common: don't touch daif before
bp-hardening") and hence does not need a declaration any more. This should
not introduce any functional change.
Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will@kernel.org> Cc: James Morse <james.morse@arm.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-kernel@vger.kernel.org Acked-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com> Signed-off-by: Will Deacon <will@kernel.org>
Kent Gibson [Mon, 20 Jan 2020 10:46:26 +0000 (18:46 +0800)]
gpiolib: remove unnecessary argument from set_config call
Remove unnecessary argument when setting PIN_CONFIG_BIAS_DISABLE. No
argument is expected by pinctrl, so removing it should be harmless.
Fixes: 2148ad7790ea ("gpiolib: add support for disabling line bias") Signed-off-by: Kent Gibson <warthog618@gmail.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Commit d90f36851d65 ("gpiolib: have a single place of calling
set_config()") introduced a regression where we don't pass the right
variable as argument to the set_config() callback of gpio driver from
gpio_set_config(). After reverting two additional patches that came
on top of it - this addresses the issue by changing the type of the last
argument of gpio_do_set_config() to unsigned long and making sure the
packed config variable is actually used in gpio_set_config().
Fixes: d90f36851d65 ("gpiolib: have a single place of calling set_config()") Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Tested-by: Guenter Roeck <linux@roeck-us.net>
Igor Druzhinin [Wed, 22 Jan 2020 20:10:24 +0000 (20:10 +0000)]
drm/i915/gvt: fix high-order allocation failure on late load
If the module happens to be loaded later at runtime there is a chance
memory is already fragmented enough to fail allocation of firmware
blob storage and consequently GVT init. Since it doesn't seem to be
necessary to have the blob contiguous, use vmalloc() instead to avoid
the issue.
Linus Torvalds [Mon, 10 Feb 2020 00:05:50 +0000 (16:05 -0800)]
Merge tag 'kbuild-v5.6-2' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild
Pull more Kbuild updates from Masahiro Yamada:
- fix randconfig to generate a sane .config
- rename hostprogs-y / always to hostprogs / always-y, which are more
natual syntax.
- optimize scripts/kallsyms
- fix yes2modconfig and mod2yesconfig
- make multiple directory targets ('make foo/ bar/') work
* tag 'kbuild-v5.6-2' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild:
kbuild: make multiple directory targets work
kconfig: Invalidate all symbols after changing to y or m.
kallsyms: fix type of kallsyms_token_table[]
scripts/kallsyms: change table to store (strcut sym_entry *)
scripts/kallsyms: rename local variables in read_symbol()
kbuild: rename hostprogs-y/always to hostprogs/always-y
kbuild: fix the document to use extra-y for vmlinux.lds
kconfig: fix broken dependency in randconfig-generated .config
Linus Torvalds [Sun, 9 Feb 2020 23:51:46 +0000 (15:51 -0800)]
Merge tag 'zonefs-5.6-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/dlemoal/zonefs
Pull new zonefs file system from Damien Le Moal:
"Zonefs is a very simple file system exposing each zone of a zoned
block device as a file.
Unlike a regular file system with native zoned block device support
(e.g. f2fs or the on-going btrfs effort), zonefs does not hide the
sequential write constraint of zoned block devices to the user. As a
result, zonefs is not a POSIX compliant file system. Its goal is to
simplify the implementation of zoned block devices support in
applications by replacing raw block device file accesses with a richer
file based API, avoiding relying on direct block device file ioctls
which may be more obscure to developers.
One example of this approach is the implementation of LSM
(log-structured merge) tree structures (such as used in RocksDB and
LevelDB) on zoned block devices by allowing SSTables to be stored in a
zone file similarly to a regular file system rather than as a range of
sectors of a zoned device. The introduction of the higher level
construct "one file is one zone" can help reducing the amount of
changes needed in the application while at the same time allowing the
use of zoned block devices with various programming languages other
than C.
Zonefs IO management implementation uses the new iomap generic code.
Zonefs has been successfully tested using a functional test suite
(available with zonefs userland format tool on github) and a prototype
implementation of LevelDB on top of zonefs"
* tag 'zonefs-5.6-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/dlemoal/zonefs:
zonefs: Add documentation
fs: New zonefs file system
projects / mirror_ubuntu-hirsute-kernel.git / log