aboutsummaryrefslogtreecommitdiffstats
path: root/include
AgeCommit message (Collapse)AuthorFilesLines
2019-12-17drm/drm_panel: Fix EXPORT of drm_panel_of_backlight() one more timeAndy Shevchenko1-1/+1
The initial commit followed by the fix didn't take into consideration the case: CONFIG_DRM_PANEL=y CONFIG_BACKLIGHT_CLASS_DEVICE=m CONFIG_DRM_I915=y where symbol devm_of_find_backlight() is not reachable from DRM subsystem. Quick fix is to avoid drm_panel_of_backlight() from exporting in such case. Fixes: 907aa265fde6 ("drm/drm_panel: fix EXPORT of drm_panel_of_backlight") Reported-by: Randy Dunlap <rdunlap@infradead.org> Acked-by: Randy Dunlap <rdunlap@infradead.org> # build-tested Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Sean Paul <sean@poorly.run> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Maxime Ripard <mripard@kernel.org> Cc: dri-devel@lists.freedesktop.org Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20191217140721.42432-1-andriy.shevchenko@linux.intel.com
2019-12-17Merge branch 'efi-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds1-5/+5
Pull EFI fixes from Ingo Molnar: "Protect presistent EFI memory reservations from kexec, fix EFIFB early console, EFI stub graphics output fixes and other misc fixes." * 'efi-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: efi: Don't attempt to map RCI2 config table if it doesn't exist efi/earlycon: Remap entire framebuffer after page initialization efi: Fix efi_loaded_image_t::unload type efi/gop: Fix memory leak in __gop_query32/64() efi/gop: Return EFI_SUCCESS if a usable GOP was found efi/gop: Return EFI_NOT_FOUND if there are no usable GOPs efi/memreserve: Register reservations as 'reserved' in /proc/iomem
2019-12-17Merge tag 'drm-next-5.6-2019-12-11' of git://people.freedesktop.org/~agd5f/linux into drm-nextDaniel Vetter1-0/+3
drm-next-5.6-2019-12-11: amdgpu: - Add MST atomic routines - Add support for DMCUB (new helper microengine for displays) - Add OEM i2c support in DC - Use vstartup for vblank events on DCN - Simplify Kconfig for DC - Renoir fixes for DC - Clean up function pointers in DC - Initial support for HDCP 2.x - Misc code cleanups - GFX10 fixes - Rework JPEG engine handling for VCN - Add clock and power gating support for JPEG - BACO support for Arcturus - Cleanup PSP ring handling - Add framework for using BACO with runtime pm to save power - Move core pci state handling out of the driver for pm ops - Allow guest power control in 1 VF case with SR-IOV - SR-IOV fixes - RAS fixes - Support for power metrics on renoir - Golden settings updates for gfx10 - Enable gfxoff on supported navi10 skus - Update MAINTAINERS amdkfd: - Clean up generational gfx code - Fixes for gfx10 - DIQ fixes - Share more code with amdgpu radeon: - PPC DMA fix - Register checker fixes for r1xx/r2xx - Misc cleanups From: Alex Deucher <alexdeucher@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191211223020.7510-1-alexander.deucher@amd.com
2019-12-17bpf: Fix cgroup local storage prog trackingDaniel Borkmann1-4/+4
Recently noticed that we're tracking programs related to local storage maps through their prog pointer. This is a wrong assumption since the prog pointer can still change throughout the verification process, for example, whenever bpf_patch_insn_single() is called. Therefore, the prog pointer that was assigned via bpf_cgroup_storage_assign() is not guaranteed to be the same as we pass in bpf_cgroup_storage_release() and the map would therefore remain in busy state forever. Fix this by using the prog's aux pointer which is stable throughout verification and beyond. Fixes: de9cbbaadba5 ("bpf: introduce cgroup storage maps") Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Cc: Roman Gushchin <guro@fb.com> Cc: Martin KaFai Lau <kafai@fb.com> Link: https://lore.kernel.org/bpf/1471c69eca3022218666f909bc927a92388fd09e.1576580332.git.daniel@iogearbox.net
2019-12-17ARM: OMAP2+: Drop legacy platform data for omap4 aessTony Lindgren1-53/+0
We can now probe devices with ti-sysc interconnect driver and dts data. Let's drop the related platform data and custom ti,hwmods dts property. As we're just dropping data, and the early platform data init is based on the custom ti,hwmods property, we want to drop both the platform data and ti,hwmods property in a single patch. Cc: Keerthy <j-keerthy@ti.com> Cc: Peter Ujfalusi <peter.ujfalusi@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Tested-by: Keerthy <j-keerthy@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-12-17dma-buf: heaps: Use _IOCTL_ for userspace IOCTL identifierAndrew F. Davis1-2/+2
This is more consistent with the DMA and DRM frameworks convention. This patch is only a name change, no logic is changed. Signed-off-by: Andrew F. Davis <afd@ti.com> Acked-by: John Stultz <john.stultz@linaro.org> Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20191216133405.1001-2-afd@ti.com
2019-12-17dmaengine: ti: omap-dma: Add device tree match data and use it for cpu_pmTony Lindgren1-2/+0
With old DMA code disabled for handling DMA requests for device tree based SoCs, we can move omap3 specific context save and restore to the dmaengine driver. Let's do this by adding cpu_pm notifier handling to save and restore context, and enable it based on device tree match data. This way we can use the match data later to configure more SoC specific features later on too. Note that we only clear the channels in use while the platform code also clears reserved channels 0 and 1 on high-security SoCs. Based on testing on n900, this is not needed though and the system idles just fine. With the dmaengine driver handling context save and restore, we must now remove the old custom calls for context save and restore. Cc: Aaro Koskinen <aaro.koskinen@iki.fi> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Peter Ujfalusi <peter.ujfalusi@ti.com> Cc: Russell King <rmk+kernel@armlinux.org.uk> Cc: Vinod Koul <vkoul@kernel.org> Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Tested-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-12-17ARM: OMAP2+: Drop sdma interrupt handling for mach-omap2Tony Lindgren1-4/+0
All device tree probing omap SoCs only have device drivers that are using Linux dmaengine API with the IRQENABLE_L1 interrupts. Only omap1 is still using old legacy dma. This means we can remove the legacy sdma interrupt handling for IRQENABLE_L0, and only rely on the dmaengine driver using IRQENABLE_L1. The legacy code still allocates the channels, but that will be deal with in the following patches. Cc: Aaro Koskinen <aaro.koskinen@iki.fi> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Peter Ujfalusi <peter.ujfalusi@ti.com> Cc: Russell King <rmk+kernel@armlinux.org.uk> Cc: Vinod Koul <vkoul@kernel.org> Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Tested-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-12-17ARM: OMAP2+: Drop unused sdma functionsTony Lindgren1-12/+0
We still have lots of legacy code for sdma, but some of it is now unused. To simplify phasing out the old legacy sdma code, let's first remove all currently unused functions: omap_enable_dma_irq omap_set_dma_write_mode omap_set_dma_params omap_dma_link_lch omap_set_dma_callback omap_dma_set_global_params And with this, omap_dma_set_global_params now becomes static. Cc: Aaro Koskinen <aaro.koskinen@iki.fi> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Peter Ujfalusi <peter.ujfalusi@ti.com> Cc: Russell King <rmk+kernel@armlinux.org.uk> Cc: Vinod Koul <vkoul@kernel.org> Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Tested-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-12-17i2c: remove unneeded 'extern' from function declatationsLuca Ceresoli1-60/+55
According to coding-style.rst, extern should not be specified for exported functions. Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2019-12-17drm/print: introduce new struct drm_device based logging macrosJani Nikula1-0/+65
Add new struct drm_device based logging macros modeled after the core kernel device based logging macros. These would be preferred over the drm printk and struct device based macros in drm code, where possible. We have existing drm specific struct device based logging functions, but they are too verbose to use for two main reasons: * The names are unnecessarily long, for example DRM_DEV_DEBUG_KMS(). * The use of struct device over struct drm_device is too generic for most users, leading to an extra dereference. For example: DRM_DEV_DEBUG_KMS(drm->dev, "Hello, world\n"); vs. drm_dbg_kms(drm, "Hello, world\n"); It's a matter of taste, but the SHOUTING UPPERCASE has been argued to be less readable than lowercase. Some names are changed from old DRM names to be based on the core kernel logging functions. For example, NOTE -> notice, ERROR -> err, DEBUG -> dbg. Due to the conflation of DRM_DEBUG and DRM_DEBUG_DRIVER macro use (DRM_DEBUG is used widely in drivers though it's supposed to be a core debugging category), they are named as drm_dbg_core and drm_dbg, respectively. The drm_err and _once/_ratelimited variants no longer include the function name in order to be able to use the core device based logging macros. Arguably this is not a significant change; error messages should not be so common to be only distinguishable by the function name. Ratelimited debug logging macros are to be added later. Cc: Sam Ravnborg <sam@ravnborg.org> Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Acked-by: Sean Paul <sean@poorly.run> Acked-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191210123050.8799-1-jani.nikula@intel.com
2019-12-17serial_core: Un-ifdef sysrq SUPPORT_SYSRQDmitry Safonov1-34/+43
The SUPPORT_SYSRQ is messy: every .c source should define it before including "serial_core.h" if sysrq is supported or struct uart_port will differ in sizes. Also this prevents moving to serial_core.c functions: uart_handle_sysrq_char(), uart_prepare_sysrq_char(), uart_unlock_and_check_sysrq(). It doesn't save many bytes in the structure, and a better way to reduce it's size would be making rs485 and iso7816 pointers. Introduce `has_sysrq` member to be used by serial line drivers further. Signed-off-by: Dmitry Safonov <dima@arista.com> Link: https://lore.kernel.org/r/20191213000657.931618-4-dima@arista.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-12-17serial: Move sysrq members aboveDmitry Safonov1-5/+6
At the current place members those follow are: : upf_t flags; : upstat_t status; : int hw_stopped; : unsigned int mctrl; : unsigned int timeout; : unsigned int type; : const struct uart_ops *ops; Together, they give (*ops) 8-byte align on 64-bit platforms. And `sysrq_ch` introduces 4-byte padding. On the other side, above: : struct device *dev; : unsigned char hub6; : unsigned char suspended; : unsigned char unused[2]; : const char *name; Adds another 4-byte padding. Moving sysrq members just before `hub6` allows to save 8 bytes per-uart_port on 64-bit platforms: On my gcc, x86_64 sizeof(struct uart_port) goes from 528 to 520. Signed-off-by: Dmitry Safonov <dima@arista.com> Link: https://lore.kernel.org/r/20191213000657.931618-3-dima@arista.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-12-17Merge tag 'asoc-fix-v5.5-rc2' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linusTakashi Iwai1-0/+1
ASoC: Fixes for v5.5 A collection of fixes since the merge window, mostly driver specific but there's a few in the core that clean up fallout from the refactorings done in the last cycle.
2019-12-17Merge tag 'drm-misc-next-2019-12-16' of git://anongit.freedesktop.org/drm/drm-misc into drm-nextDaniel Vetter26-317/+544
drm-misc-next for v5.6: UAPI Changes: - Add support for DMA-BUF HEAPS. Cross-subsystem Changes: - mipi dsi definition updates, pulled into drm-intel as well. - Add lockdep annotations for dma_resv vs mmap_sem and fs_reclaim. - Remove support for dma-buf kmap/kunmap. - Constify fb_ops in all fbdev drivers, including drm drivers and drm-core, and media as well. Core Changes: - Small cleanups to ttm. - Fix SCDC definition. - Assorted cleanups to core. - Add todo to remove load/unload hooks, and use generic fbdev emulation. - Assorted documentation updates. - Use blocking ww lock in ttm fault handler. - Remove drm_fb_helper_fbdev_setup/teardown. - Warning fixes with W=1 for atomic. - Use drm_debug_enabled() instead of drm_debug flag testing in various drivers. - Fallback to nontiled mode in fbdev emulation when not all tiles are present. (Later on reverted) - Various kconfig indentation fixes in core and drivers. - Fix freeing transactions in dp-mst correctly. - Sean Paul is steping down as core maintainer. :-( - Add lockdep annotations for atomic locks vs dma-resv. - Prevent use-after-free for a bad job in drm_scheduler. - Fill out all block sizes in the P01x and P210 definitions. - Avoid division by zero in drm/rect, and fix bounds. - Add drm/rect selftests. - Add aspect ratio and alternate clocks for HDMI 4k modes. - Add todo for drm_framebuffer_funcs and fb_create cleanup. - Drop DRM_AUTH for prime import/export ioctls. - Clear DP-MST payload id tables downstream when initializating. - Fix for DSC throughput definition. - Add extra FEC definitions. - Fix fake offset in drm_gem_object_funs.mmap. - Stop using encoder->bridge in core directly - Handle bridge chaining slightly better. - Add backlight support to drm/panel, and use it in many panel drivers. - Increase max number of y420 modes from 128 to 256, as preparation to add the new modes. Driver Changes: - Small fixes all over. - Fix documentation in vkms. - Fix mmap_sem vs dma_resv in nouveau. - Small cleanup in komeda. - Add page flip support in gma500 for psb/cdv. - Add ddc symlink in the connector sysfs directory for many drivers. - Add support for analogic an6345, and fix small bugs in it. - Add atomic modesetting support to ast. - Fix radeon fault handler VMA race. - Switch udl to use generic shmem helpers. - Unconditional vblank handling for mcde. - Miscellaneous fixes to mcde. - Tweak debug output from komeda using debugfs. - Add gamma and color transform support to komeda for DOU-IPS. - Add support for sony acx424AKP panel. - Various small cleanups to gma500. - Use generic fbdev emulation in udl, and replace udl_framebuffer with generic implementation. - Add support for Logic PD Type 28 panel. - Use drm_panel_* wrapper functions in exynos/tegra/msm. - Add devicetree bindings for generic DSI panels. - Don't include drm_pci.h directly in many drivers. - Add support for begin/end_cpu_access in udmabuf. - Stop using drm_get_pci_dev in gma500 and mga200. - Fixes to UDL damage handling, and use dma_buf_begin/end_cpu_access. - Add devfreq thermal support to panfrost. - Fix hotplug with daisy chained monitors by removing VCPI when disabling topology manager. - meson: Add support for OSD1 plane AFBC commit. - Stop displaying garbage when toggling ast primary plane on/off. - More cleanups and fixes to UDL. - Add D32 suport to komeda. - Remove globle copy of drm_dev in gma500. - Add support for Boe Himax8279d MIPI-DSI LCD panel. - Add support for ingenic JZ4770 panel. - Small null pointer deference fix in ingenic. - Remove support for the special tfp420 driver, as there is a generic way to do it. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/ba73535a-9334-5302-2e1f-5208bd7390bd@linux.intel.com
2019-12-17stop_machine: remove try_stop_cpus helperYangtao Li1-7/+0
try_stop_cpus is not used after this: commit c190c3b16c0f ("rcu: Switch synchronize_sched_expedited() to stop_one_cpu()") So remove it. Signed-off-by: Yangtao Li <tiny.windzz@gmail.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lkml.kernel.org/r/20191214195107.26480-1-tiny.windzz@gmail.com
2019-12-17security: keys: trusted: fix lost handle flushJames Bottomley1-0/+1
The original code, before it was moved into security/keys/trusted-keys had a flush after the blob unseal. Without that flush, the volatile handles increase in the TPM until it becomes unusable and the system either has to be rebooted or the TPM volatile area manually flushed. Fix by adding back the lost flush, which we now have to export because of the relocation of the trusted key code may cause the consumer to be modular. Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com> Fixes: 2e19e10131a0 ("KEYS: trusted: Move TPM2 trusted keys code") Reviewed-by: Jerry Snitselaar <jsnitsel@redhat.com> Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
2019-12-16Merge tag 'mac80211-for-net-2019-10-16' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211David S. Miller1-0/+5
Johannes Berg says: ==================== A handful of fixes: * disable AQL on most drivers, addressing the iwlwifi issues * fix double-free on network namespace changes * fix TID field in frames injected through monitor interfaces * fix ieee80211_calc_rx_airtime() * fix NULL pointer dereference in rfkill (and remove BUG_ON) ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2019-12-16wireguard: global: fix spelling mistakes in commentsJosh Soref1-4/+4
This fixes two spelling errors in source code comments. Signed-off-by: Josh Soref <jsoref@gmail.com> [Jason: rewrote commit message] Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-12-16Merge tag 'armsoc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/socLinus Torvalds1-0/+1
Pull ARM SoC fixes from Olof Johansson: "I didn't get a batch in this weekend, so here's what we queued up last week and today. - A couple of defconfigs add back debugfs -- it used to be implicitly enabled through CONFIG_TRACING, but 0e4a459f56c32d3e ("tracing: Remove unnecessary DEBUG_FS dependency") removed that. - The rest are mostly minor fixlets of the usual kind; some DT tweaks, a headerfile refactor that needs a build fix now, etc" * tag 'armsoc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (30 commits) ARM: bcm: Add missing sentinel to bcm2711_compat[] ARM: shmobile: defconfig: Restore debugfs support bus: ti-sysc: Fix missing reset delay handling ARM: imx: Fix boot crash if ocotp is not found ARM: imx_v6_v7_defconfig: Explicitly restore CONFIG_DEBUG_FS ARM: dts: imx6ul-evk: Fix peripheral regulator arm64: dts: ls1028a: fix reboot node ARM: mmp: include the correct cputype.h ARM: dts: am437x-gp/epos-evm: fix panel compatible arm64: dts: ls1028a: fix typo in TMU calibration data ARM: imx: Correct ocotp id for serial number support of i.MX6ULL/ULZ SoCs ARM: dts: bcm283x: Fix critical trip point ARM: omap2plus_defconfig: Add back DEBUG_FS ARM: omap2plus_defconfig: enable NET_SWITCHDEV ARM: dts: am335x-sancloud-bbe: fix phy mode bus: ti-sysc: Fix missing force mstandby quirk handling reset: Do not register resource data for missing resets reset: Fix {of,devm}_reset_control_array_get kerneldoc return types reset: brcmstb: Remove resource checks dt-bindings: reset: Fix brcmstb-reset example ...
2019-12-16ipv6: Annotate ipv6_addr_is_* bitwise pointer castsSven Eckelmann1-4/+4
The sparse commit 6002ded74587 ("add a flag to warn on casts to/from bitwise pointers") introduced a check for non-direct casts from/to restricted datatypes (when -Wbitwise-pointer is enabled). This triggered a warning in the 64 bit optimized ipv6_addr_is_*() functions because sparse doesn't know that the buffer already points to some data in the correct bitwise integer format. But these were correct and can therefore be marked with __force to signalize sparse an intended cast to a specific bitwise type. Signed-off-by: Sven Eckelmann <sven@narfation.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-12-16ipv6: Annotate bitwise IPv6 dsfield pointer castSven Eckelmann1-1/+1
The sparse commit 6002ded74587 ("add a flag to warn on casts to/from bitwise pointers") introduced a check for non-direct casts from/to restricted datatypes (when -Wbitwise-pointer is enabled). This triggered a warning in ipv6_get_dsfield() because sparse doesn't know that the buffer already points to some data in the correct bitwise integer format. This was already fixed in ipv6_change_dsfield() by the __force attribute and can be fixed here the same way. Signed-off-by: Sven Eckelmann <sven@narfation.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-12-16ptp_qoriq: export extts_clean_up() functionYangbo Lu1-0/+1
Export extts_clean_up() function so that dpaa2-ptp driver is able to reuse it. Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-12-16mm: hugetlb controller for cgroups v2Giuseppe Scrivano1-1/+2
In the effort of supporting cgroups v2 into Kubernetes, I stumped on the lack of the hugetlb controller. When the controller is enabled, it exposes four new files for each hugetlb size on non-root cgroups: - hugetlb.<hugepagesize>.current - hugetlb.<hugepagesize>.max - hugetlb.<hugepagesize>.events - hugetlb.<hugepagesize>.events.local The differences with the legacy hierarchy are in the file names and using the value "max" instead of "-1" to disable a limit. The file .limit_in_bytes is renamed to .max. The file .usage_in_bytes is renamed to .current. .failcnt is not provided as a single file anymore, but its value can be read through the new flat-keyed files .events and .events.local, through the "max" key. Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com> Signed-off-by: Tejun Heo <tj@kernel.org>
2019-12-16bpf: Fix missing prog untrack in release_mapsDaniel Borkmann1-0/+2
Commit da765a2f5993 ("bpf: Add poke dependency tracking for prog array maps") wrongly assumed that in case of prog load errors, we're cleaning up all program tracking via bpf_free_used_maps(). However, it can happen that we're still at the point where we didn't copy map pointers into the prog's aux section such that env->prog->aux->used_maps is still zero, running into a UAF. In such case, the verifier has similar release_maps() helper that drops references to used maps from its env. Consolidate the release code into __bpf_free_used_maps() and call it from all sides to fix it. Fixes: da765a2f5993 ("bpf: Add poke dependency tracking for prog array maps") Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Acked-by: Yonghong Song <yhs@fb.com> Link: https://lore.kernel.org/bpf/1c2909484ca524ae9f55109b06f22b6213e76376.1576514756.git.daniel@iogearbox.net
2019-12-16ASoC: soc-core: remove legacy style of codec_confKuninori Morimoto1-3/+0
Now all driver is using snd_soc_dai_link_component for codec_conf. Let's remove legacy style Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://lore.kernel.org/r/871rt959ic.wl-kuninori.morimoto.gx@renesas.com Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2019-12-16Merge branch 'mmc_pinctrl' into nextUlf Hansson1-0/+6
Merge an immutable pinctrl branch from Linus Walleij's tree, which enables pinctrl code consolidations for mmc. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2019-12-16ASoC: soc-core: support snd_soc_dai_link_component for codec_confKuninori Morimoto1-0/+3
To find codec_conf component, it is using dev_name, of_node. But, we already has this kind of finding component method by snd_soc_dai_link_component, and snd_soc_is_matching_component(). We shouldn't have duplicate implementation to do same things. This patch adds snd_soc_dai_link_component support to find codec_conf component. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://lore.kernel.org/r/87lfrh59kj.wl-kuninori.morimoto.gx@renesas.com Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2019-12-16mmc: renesas_sdhi: remove 4taps as a TMIO flagWolfram Sang1-3/+0
Now that the quirks structure is accessible, we can remove the TMIO flag for HS400 using only 4 taps. This is Renesas specific anyhow. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Link: https://lore.kernel.org/r/20191203200513.1758-5-wsa+renesas@sang-engineering.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2019-12-16drm/modes: parse_cmdline: Add support for specifying panel_orientation (v2)Hans de Goede1-0/+8
Sometimes we want to override a connector's panel_orientation from the kernel commandline. Either for testing and for special cases, e.g. a kiosk like setup which uses a TV mounted in portrait mode. Users can already specify a "rotate" option through a video= kernel cmdline option. But that only supports 0/180 degrees (see drm_client_modeset TODO) and only works for in kernel modeset clients, not for userspace kms users. The "panel-orientation" connector property OTOH does support 90/270 degrees as it leaves dealing with the rotation up to userspace and this does work for userspace kms clients (at least those which support this property). Changes in v2: -Add missing ':' after @panel_orientation (reported by kbuild test robot) BugLink: https://gitlab.freedesktop.org/plymouth/plymouth/merge_requests/83 Acked-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191118155134.30468-9-hdegoede@redhat.com
2019-12-16ACPI: processor: Export function to claim _CST controlRafael J. Wysocki1-0/+6
The intel_idle driver will be modified to use ACPI _CST subsequently and it will need to notify the platform firmware of that if acpi_gbl_FADT.cst_control is set, so add a routine for this purpose, acpi_processor_claim_cst_control(), to acpi_processor.c (so that it is always present which is required by intel_idle) and export it to allow the ACPI processor driver (which is modular) to call it. No intentional functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2019-12-16drm/bridge/synopsys: dsi: driver-specific configuration of phy timingsHeiko Stuebner1-0/+9
The timing values for dw-dsi are often dependent on the used display and according to Philippe Cornu will most likely also depend on the used phy technology in the soc-specific implementation. To solve this and allow specific implementations to define them as needed add a new get_timing callback to phy_ops and call this from the dphy_timing function to retrieve the necessary values for the specific mode. Right now this handles the hs2lp + lp2hs where Rockchip SoCs need handling according to the phy speed, while STM seems to be ok with static values. changes in v5: - rebase on 5.5-rc1 - merge into px30 dsi series to prevent ordering conflicts changes in v4: - rebase to make it directly fit on top of drm-misc-next after all changes in v3: - check existence of phy_ops->get_timing in __dw_mipi_dsi_probe() - emit actual error when get_timing() call fails - add tags from Philippe and Yannick changes in v2: - add driver-specific handling, don't force all bridge users to use the same timings, as suggested by Philippe Suggested-by: Philippe Cornu <philippe.cornu@st.com> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Philippe Cornu <philippe.cornu@st.com> Tested-by: Yannick Fertre <yannick.fertre@st.com> Reviewed-by: Neil Armstrong <narmstrong@baylibre.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191209143130.4553-2-heiko@sntech.de
2019-12-16backlight: bd6107: Convert to use GPIO descriptorLinus Walleij1-1/+0
The Rohm BD6107 driver can pass a fixed GPIO line using the old GPIO API using platform data. As there are no in-tree users of this platform data since 2013, we can convert this to use a GPIO descriptor and require any out-of-tree consumers to pass the GPIO using a machine descriptor table instead. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org> Signed-off-by: Lee Jones <lee.jones@linaro.org>
2019-12-16export.h: reduce __ksymtab_strings string duplication by using "MS" section flagsJessica Yu2-13/+28
Commit c3a6cf19e695 ("export: avoid code duplication in include/linux/export.h") refactors export.h quite nicely, but introduces a slight increase in memory usage due to using the empty string "" instead of NULL to indicate that an exported symbol has no namespace. As mentioned in that commit, this meant an increase of 1 byte per exported symbol without a namespace. For example, if a kernel configuration has about 10k exported symbols, this would mean that the size of __ksymtab_strings would increase by roughly 10kB. We can alleviate this situation by utilizing the SHF_MERGE and SHF_STRING section flags. SHF_MERGE|SHF_STRING indicate to the linker that the data in the section are null-terminated strings that can be merged to eliminate duplication. More specifically, from the binutils documentation - "for sections with both M and S, a string which is a suffix of a larger string is considered a duplicate. Thus "def" will be merged with "abcdef"; A reference to the first "def" will be changed to a reference to "abcdef"+3". Thus, all the empty strings would be merged as well as any strings that can be merged according to the cited method above. For example, "memset" and "__memset" would be merged to just "__memset" in __ksymtab_strings. As of v5.4-rc5, the following statistics were gathered with x86 defconfig with approximately 10.7k exported symbols. Size of __ksymtab_strings in vmlinux: ------------------------------------- v5.4-rc5: 213834 bytes v5.4-rc5 with commit c3a6cf19e695: 224455 bytes v5.4-rc5 with this patch: 205759 bytes So, we already see memory savings of ~8kB compared to vanilla -rc5 and savings of nearly 18.7kB compared to -rc5 with commit c3a6cf19e695 on top. Unfortunately, as of this writing, strings will not get deduplicated for kernel modules, as ld does not do the deduplication for SHF_MERGE|SHF_STRINGS sections for relocatable files (ld -r), which kernel modules are. A patch for ld is currently being worked on to hopefully allow for string deduplication in relocatable files in the future. Suggested-by: Rasmus Villemoes <linux@rasmusvillemoes.dk> Reviewed-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Matthias Maennich <maennich@google.com> Signed-off-by: Jessica Yu <jeyu@kernel.org>
2019-12-16media: v4l2-device.h: Explicitly compare grp{id,mask} to zero in v4l2_device macrosNathan Chancellor1-6/+6
When building with Clang + -Wtautological-constant-compare, several of the ivtv and cx18 drivers warn along the lines of: drivers/media/pci/cx18/cx18-driver.c:1005:21: warning: converting the result of '<<' to a boolean always evaluates to true [-Wtautological-constant-compare] cx18_call_hw(cx, CX18_HW_GPIO_RESET_CTRL, ^ drivers/media/pci/cx18/cx18-cards.h:18:37: note: expanded from macro 'CX18_HW_GPIO_RESET_CTRL' #define CX18_HW_GPIO_RESET_CTRL (1 << 6) ^ 1 warning generated. This warning happens because the shift operation is implicitly converted to a boolean in v4l2_device_mask_call_all before being negated. This can be solved by just comparing the mask result to 0 explicitly so that there is no boolean conversion. The ultimate goal is to enable -Wtautological-compare globally because there are several subwarnings that would be helpful to have. For visual consistency and avoidance of these warnings in the future, all of the implicitly boolean conversions in the v4l2_device macros are converted to explicit ones as well. Link: https://github.com/ClangBuiltLinux/linux/issues/752 Reviewed-by: Ezequiel Garcia <ezequiel@collabora.com> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2019-12-16device.h: move 'struct driver' stuff out to device/driver.hGreg Kroah-Hartman2-271/+293
device.h has everything and the kitchen sink when it comes to struct device things, so split out the struct driver things things to a separate .h file to make things easier to maintain and manage over time. Cc: "Rafael J. Wysocki" <rafael@kernel.org> Cc: Suzuki K Poulose <suzuki.poulose@arm.com> Cc: Saravana Kannan <saravanak@google.com> Cc: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20191209193303.1694546-7-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-12-16device.h: move 'struct class' stuff out to device/class.hGreg Kroah-Hartman2-240/+267
device.h has everything and the kitchen sink when it comes to struct device things, so split out the struct class things things to a separate .h file to make things easier to maintain and manage over time. Cc: "Rafael J. Wysocki" <rafael@kernel.org> Cc: Suzuki K Poulose <suzuki.poulose@arm.com> Cc: Saravana Kannan <saravanak@google.com> Cc: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20191209193303.1694546-6-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-12-16device.h: move 'struct bus' stuff out to device/bus.hGreg Kroah-Hartman2-264/+289
device.h has everything and the kitchen sink when it comes to struct device things, so split out the struct bus things things to a separate .h file to make things easier to maintain and manage over time. Cc: "Rafael J. Wysocki" <rafael@kernel.org> Cc: Suzuki K Poulose <suzuki.poulose@arm.com> Cc: Saravana Kannan <saravanak@google.com> Cc: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20191209193303.1694546-5-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-12-16device.h: move dev_printk()-like functions to dev_printk.hGreg Kroah-Hartman2-216/+236
device.h has everything and the kitchen sink when it comes to struct device things, so split out the printk-specific things to a separate .h file to make things easier to maintain and manage over time. Cc: Suzuki K Poulose <suzuki.poulose@arm.com> Cc: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com> Cc: Saravana Kannan <saravanak@google.com> Cc: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20191209193303.1694546-4-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-12-16device.h: move devtmpfs prototypes out of the fileGreg Kroah-Hartman1-4/+0
The devtmpfs functions do not need to be in device.h as only the driver core uses them, so move them to the private .h file for the driver core. Cc: "Rafael J. Wysocki" <rafael@kernel.org> Cc: Suzuki K Poulose <suzuki.poulose@arm.com> Cc: Saravana Kannan <saravanak@google.com> Cc: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20191209193303.1694546-3-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-12-16Merge 5.5-rc2 into staging-nextGreg Kroah-Hartman20-52/+74
We want the staging driver fixes in here, and this resolves merge issues with the isdn code that was pointed out in linux-next Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-12-16Merge 5.5-rc2 into usb-nextGreg Kroah-Hartman20-52/+74
We need the USB fixes in here as well. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-12-16interconnect: Add a common standard aggregate functionGeorgi Djakov1-0/+8
Currently there is one very standard aggregation method that is used by several drivers. Let's add this as a common function, so that drivers could just point to it, instead of copy/pasting code. Suggested-by: Evan Green <evgreen@chromium.org> Reviewed-by: Brian Masney <masneyb@onstation.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Reviewed-by: Evan Green <evgreen@chromium.org> Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org>
2019-12-16interconnect: Add a common helper for removing all nodesGeorgi Djakov1-0/+6
The removal of all nodes from a provider seem to be a common functionality for all existing users and it would make sense to factor out this into a a common helper function. Suggested-by: Dmitry Osipenko <digetx@gmail.com> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org>
2019-12-15jbd2: fix kernel-doc notation warningRandy Dunlap1-1/+1
Fix kernel-doc warning by inserting a beginning '*' character for the kernel-doc line. ../include/linux/jbd2.h:461: warning: bad line: journal. These are dirty buffers and revoke descriptor blocks. Link: https://lore.kernel.org/r/53e3ce27-ceae-560d-0fd4-f95728a33e12@infradead.org Cc: stable@kernel.org Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2019-12-15libbpf: Support libbpf-provided extern variablesAndrii Nakryiko1-1/+2
Add support for extern variables, provided to BPF program by libbpf. Currently the following extern variables are supported: - LINUX_KERNEL_VERSION; version of a kernel in which BPF program is executing, follows KERNEL_VERSION() macro convention, can be 4- and 8-byte long; - CONFIG_xxx values; a set of values of actual kernel config. Tristate, boolean, strings, and integer values are supported. Set of possible values is determined by declared type of extern variable. Supported types of variables are: - Tristate values. Are represented as `enum libbpf_tristate`. Accepted values are **strictly** 'y', 'n', or 'm', which are represented as TRI_YES, TRI_NO, or TRI_MODULE, respectively. - Boolean values. Are represented as bool (_Bool) types. Accepted values are 'y' and 'n' only, turning into true/false values, respectively. - Single-character values. Can be used both as a substritute for bool/tristate, or as a small-range integer: - 'y'/'n'/'m' are represented as is, as characters 'y', 'n', or 'm'; - integers in a range [-128, 127] or [0, 255] (depending on signedness of char in target architecture) are recognized and represented with respective values of char type. - Strings. String values are declared as fixed-length char arrays. String of up to that length will be accepted and put in first N bytes of char array, with the rest of bytes zeroed out. If config string value is longer than space alloted, it will be truncated and warning message emitted. Char array is always zero terminated. String literals in config have to be enclosed in double quotes, just like C-style string literals. - Integers. 8-, 16-, 32-, and 64-bit integers are supported, both signed and unsigned variants. Libbpf enforces parsed config value to be in the supported range of corresponding integer type. Integers values in config can be: - decimal integers, with optional + and - signs; - hexadecimal integers, prefixed with 0x or 0X; - octal integers, starting with 0. Config file itself is searched in /boot/config-$(uname -r) location with fallback to /proc/config.gz, unless config path is specified explicitly through bpf_object_open_opts' kernel_config_path option. Both gzipped and plain text formats are supported. Libbpf adds explicit dependency on zlib because of this, but this shouldn't be a problem, given libelf already depends on zlib. All detected extern variables, are put into a separate .extern internal map. It, similarly to .rodata map, is marked as read-only from BPF program side, as well as is frozen on load. This allows BPF verifier to track extern values as constants and perform enhanced branch prediction and dead code elimination. This can be relied upon for doing kernel version/feature detection and using potentially unsupported field relocations or BPF helpers in a CO-RE-based BPF program, while still having a single version of BPF program running on old and new kernels. Selftests are validating this explicitly for unexisting BPF helper. Signed-off-by: Andrii Nakryiko <andriin@fb.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Link: https://lore.kernel.org/bpf/20191214014710.3449601-3-andriin@fb.com
2019-12-15Merge tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdmaLinus Torvalds1-0/+5
Pull rdma fixes from Doug Ledford: "A small collection of -rc fixes. Mostly. One API addition, but that's because we wanted to use it in a fix. There's also a bug fix that is going to render the 5.5 kernel's soft-RoCE driver incompatible with all soft-RoCE versions prior, but it's required to actually implement the protocol according to the RoCE spec and required in order for the soft-RoCE driver to be able to successfully work with actual RoCE hardware. Summary: - Update Steve Wise info - Fix for soft-RoCE crc calculations (will break back compatibility, but only with the soft-RoCE driver, which has had this bug since it was introduced and it is an on-the-wire bug, but will make soft-RoCE fully compatible with real RoCE hardware) - cma init fixup - counters oops fix - fix for mlx4 init/teardown sequence - fix for mkx5 steering rules - introduce a cleanup API, which isn't a fix, but we want to use it in the next fix - fix for mlx5 memory management that uses API in previous patch" * tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma: IB/mlx5: Fix device memory flows IB/core: Introduce rdma_user_mmap_entry_insert_range() API IB/mlx5: Fix steering rule of drop and count IB/mlx4: Follow mirror sequence of device add during device removal RDMA/counter: Prevent auto-binding a QP which are not tracked with res rxe: correctly calculate iCRC for unaligned payloads Update mailmap info for Steve Wise RDMA/cma: add missed unregister_pernet_subsys in init failure
2019-12-15Merge branch 'remove-ksys-mount-dup' of git://git.kernel.org/pub/scm/linux/kernel/git/brodo/linuxLinus Torvalds3-5/+4
Pull ksys_mount() and ksys_dup() removal from Dominik Brodowski: "This small series replaces all in-kernel calls to the userspace-focused ksys_mount() and ksys_dup() with calls to kernel-centric functions: For each replacement of ksys_mount() with do_mount(), one needs to verify that the first and third parameter (char *dev_name, char *type) are strings allocated in kernelspace and that the fifth parameter (void *data) is either NULL or refers to a full page (only occurence in init/do_mounts.c::do_mount_root()). The second and fourth parameters (char *dir_name, unsigned long flags) are passed by ksys_mount() to do_mount() unchanged, and therefore do not require particular care. Moreover, instead of pretending to be userspace, the opening of /dev/console as stdin/stdout/stderr can be implemented using in-kernel functions as well. Thereby, ksys_dup() can be removed for good" [ This doesn't get rid of the special "kernel init runs with KERNEL_DS" case, but it at least removes _some_ of the users of "treat kernel pointers as user pointers for our magical init sequence". One day we'll hopefully be rid of it all, and can initialize our init_thread addr_limit to USER_DS. - Linus ] * 'remove-ksys-mount-dup' of git://git.kernel.org/pub/scm/linux/kernel/git/brodo/linux: fs: remove ksys_dup() init: unify opening /dev/console as stdin/stdout/stderr init: use do_mount() instead of ksys_mount() initrd: use do_mount() instead of ksys_mount() devtmpfs: use do_mount() instead of ksys_mount()
2019-12-15iio: adc: ti-ads1015: Get rid of legacy platform dataAndy Shevchenko2-24/+0
Platform data is a legacy interface to supply device properties to the driver. In this case we even don't have in-kernel users for it. Just remove it for good. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-12-15iio: ad7266: Convert to use GPIO descriptorsLinus Walleij1-3/+0
The AD7266 have no in-tree users making use of the platform data mechanism to pass address GPIO lines when not using a fixed address, so we can easily convert this to use GPIO descriptors instead of the platform data integers currently passed. Lowercase the labels "ad0".."ad2" as this will make a better fit for platform descriptions like device tree that prefer lowercase names such as "ad0-gpios" rather than "AD0-gpios". Board files and other static users of this device can pass the same GPIO descriptors using machine descriptor tables if need be. Cc: Alison Schofield <amsfield22@gmail.com> Cc: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>