01 Apr, 2020
2 commits
-
Pull networking updates from David Miller:
"Highlights:1) Fix the iwlwifi regression, from Johannes Berg.
2) Support BSS coloring and 802.11 encapsulation offloading in
hardware, from John Crispin.3) Fix some potential Spectre issues in qtnfmac, from Sergey
Matyukevich.4) Add TTL decrement action to openvswitch, from Matteo Croce.
5) Allow paralleization through flow_action setup by not taking the
RTNL mutex, from Vlad Buslov.6) A lot of zero-length array to flexible-array conversions, from
Gustavo A. R. Silva.7) Align XDP statistics names across several drivers for consistency,
from Lorenzo Bianconi.8) Add various pieces of infrastructure for offloading conntrack, and
make use of it in mlx5 driver, from Paul Blakey.9) Allow using listening sockets in BPF sockmap, from Jakub Sitnicki.
10) Lots of parallelization improvements during configuration changes
in mlxsw driver, from Ido Schimmel.11) Add support to devlink for generic packet traps, which report
packets dropped during ACL processing. And use them in mlxsw
driver. From Jiri Pirko.12) Support bcmgenet on ACPI, from Jeremy Linton.
13) Make BPF compatible with RT, from Thomas Gleixnet, Alexei
Starovoitov, and your's truly.14) Support XDP meta-data in virtio_net, from Yuya Kusakabe.
15) Fix sysfs permissions when network devices change namespaces, from
Christian Brauner.16) Add a flags element to ethtool_ops so that drivers can more simply
indicate which coalescing parameters they actually support, and
therefore the generic layer can validate the user's ethtool
request. Use this in all drivers, from Jakub Kicinski.17) Offload FIFO qdisc in mlxsw, from Petr Machata.
18) Support UDP sockets in sockmap, from Lorenz Bauer.
19) Fix stretch ACK bugs in several TCP congestion control modules,
from Pengcheng Yang.20) Support virtual functiosn in octeontx2 driver, from Tomasz
Duszynski.21) Add region operations for devlink and use it in ice driver to dump
NVM contents, from Jacob Keller.22) Add support for hw offload of MACSEC, from Antoine Tenart.
23) Add support for BPF programs that can be attached to LSM hooks,
from KP Singh.24) Support for multiple paths, path managers, and counters in MPTCP.
From Peter Krystad, Paolo Abeni, Florian Westphal, Davide Caratti,
and others.25) More progress on adding the netlink interface to ethtool, from
Michal Kubecek"* git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next: (2121 commits)
net: ipv6: rpl_iptunnel: Fix potential memory leak in rpl_do_srh_inline
cxgb4/chcr: nic-tls stats in ethtool
net: dsa: fix oops while probing Marvell DSA switches
net/bpfilter: remove superfluous testing message
net: macb: Fix handling of fixed-link node
net: dsa: ksz: Select KSZ protocol tag
netdevsim: dev: Fix memory leak in nsim_dev_take_snapshot_write
net: stmmac: add EHL 2.5Gbps PCI info and PCI ID
net: stmmac: add EHL PSE0 & PSE1 1Gbps PCI info and PCI ID
net: stmmac: create dwmac-intel.c to contain all Intel platform
net: dsa: bcm_sf2: Support specifying VLAN tag egress rule
net: dsa: bcm_sf2: Add support for matching VLAN TCI
net: dsa: bcm_sf2: Move writing of CFP_DATA(5) into slicing functions
net: dsa: bcm_sf2: Check earlier for FLOW_EXT and FLOW_MAC_EXT
net: dsa: bcm_sf2: Disable learning for ASP port
net: dsa: b53: Deny enslaving port 7 for 7278 into a bridge
net: dsa: b53: Prevent tagged VLAN on port 7 for 7278
net: dsa: b53: Restore VLAN entries upon (re)configuration
net: dsa: bcm_sf2: Fix overflow checks
hv_netvsc: Remove unnecessary round_up for recv_completion_cnt
... -
Pull arm64 updates from Catalin Marinas:
"The bulk is in-kernel pointer authentication, activity monitors and
lots of asm symbol annotations. I also queued the sys_mremap() patch
commenting the asymmetry in the address untagging.Summary:
- In-kernel Pointer Authentication support (previously only offered
to user space).- ARM Activity Monitors (AMU) extension support allowing better CPU
utilisation numbers for the scheduler (frequency invariance).- Memory hot-remove support for arm64.
- Lots of asm annotations (SYM_*) in preparation for the in-kernel
Branch Target Identification (BTI) support.- arm64 perf updates: ARMv8.5-PMU 64-bit counters, refactoring the
PMU init callbacks, support for new DT compatibles.- IPv6 header checksum optimisation.
- Fixes: SDEI (software delegated exception interface) double-lock on
hibernate with shared events.- Minor clean-ups and refactoring: cpu_ops accessor,
cpu_do_switch_mm() converted to C, cpufeature finalisation helper.- sys_mremap() comment explaining the asymmetric address untagging
behaviour"* tag 'arm64-upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux: (81 commits)
mm/mremap: Add comment explaining the untagging behaviour of mremap()
arm64: head: Convert install_el2_stub to SYM_INNER_LABEL
arm64: Introduce get_cpu_ops() helper function
arm64: Rename cpu_read_ops() to init_cpu_ops()
arm64: Declare ACPI parking protocol CPU operation if needed
arm64: move kimage_vaddr to .rodata
arm64: use mov_q instead of literal ldr
arm64: Kconfig: verify binutils support for ARM64_PTR_AUTH
lkdtm: arm64: test kernel pointer authentication
arm64: compile the kernel with ptrauth return address signing
kconfig: Add support for 'as-option'
arm64: suspend: restore the kernel ptrauth keys
arm64: __show_regs: strip PAC from lr in printk
arm64: unwind: strip PAC from kernel addresses
arm64: mask PAC bits of __builtin_return_address
arm64: initialize ptrauth keys for kernel booting task
arm64: initialize and switch ptrauth kernel keys
arm64: enable ptrauth earlier
arm64: cpufeature: handle conflicts based on capability
arm64: cpufeature: Move cpu capability helpers inside C file
...
31 Mar, 2020
5 commits
-
Pull core SMP updates from Thomas Gleixner:
"CPU (hotplug) updates:- Support for locked CSD objects in smp_call_function_single_async()
which allows to simplify callsites in the scheduler core and MIPS- Treewide consolidation of CPU hotplug functions which ensures the
consistency between the sysfs interface and kernel state. The low
level functions cpu_up/down() are now confined to the core code and
not longer accessible from random code"* tag 'smp-core-2020-03-30' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (22 commits)
cpu/hotplug: Ignore pm_wakeup_pending() for disable_nonboot_cpus()
cpu/hotplug: Hide cpu_up/down()
cpu/hotplug: Move bringup of secondary CPUs out of smp_init()
torture: Replace cpu_up/down() with add/remove_cpu()
firmware: psci: Replace cpu_up/down() with add/remove_cpu()
xen/cpuhotplug: Replace cpu_up/down() with device_online/offline()
parisc: Replace cpu_up/down() with add/remove_cpu()
sparc: Replace cpu_up/down() with add/remove_cpu()
powerpc: Replace cpu_up/down() with add/remove_cpu()
x86/smp: Replace cpu_up/down() with add/remove_cpu()
arm64: hibernate: Use bringup_hibernate_cpu()
cpu/hotplug: Provide bringup_hibernate_cpu()
arm64: Use reboot_cpu instead of hardconding it to 0
arm64: Don't use disable_nonboot_cpus()
ARM: Use reboot_cpu instead of hardcoding it to 0
ARM: Don't use disable_nonboot_cpus()
ia64: Replace cpu_down() with smp_shutdown_nonboot_cpus()
cpu/hotplug: Create a new function to shutdown nonboot cpus
cpu/hotplug: Add new {add,remove}_cpu() functions
sched/core: Remove rq.hrtick_csd_pending
... -
Pull power management updates from Rafael Wysocki:
"These clean up and rework the PM QoS API, address a suspend-to-idle
wakeup regression on some ACPI-based platforms, clean up and extend a
few cpuidle drivers, update multiple cpufreq drivers and cpufreq
documentation, and fix a number of issues in devfreq and several other
things all over.Specifics:
- Clean up and rework the PM QoS API to simplify the code and reduce
the size of it (Rafael Wysocki).- Fix a suspend-to-idle wakeup regression on Dell XPS13 9370 and
similar platforms where the USB plug/unplug events are handled by
the EC (Rafael Wysocki).- CLean up the intel_idle and PSCI cpuidle drivers (Rafael Wysocki,
Ulf Hansson).- Extend the haltpoll cpuidle driver so that it can be forced to run
on some systems where it refused to load (Maciej Szmigiero).- Convert several cpufreq documents to the .rst format and move the
legacy driver documentation into one common file (Mauro Carvalho
Chehab, Rafael Wysocki).- Update several cpufreq drivers:
* Extend and fix the imx-cpufreq-dt driver (Anson Huang).
* Improve the -EPROBE_DEFER handling and fix unwanted CPU
overclocking on i.MX6ULL in imx6q-cpufreq (Anson Huang,
Christoph Niedermaier).* Add support for Krait based SoCs to the qcom driver (Ansuel
Smith).* Add support for OPP_PLUS to ti-cpufreq (Lokesh Vutla).
* Add platform specific intermediate callbacks support to
cpufreq-dt and update the imx6q driver (Peng Fan).* Simplify and consolidate some pieces of the intel_pstate
driver and update its documentation (Rafael Wysocki, Alex
Hung).- Fix several devfreq issues:
* Remove unneeded extern keyword from a devfreq header file and
use the DEVFREQ_GOV_UPDATE_INTERNAL event name instead of
DEVFREQ_GOV_INTERNAL (Chanwoo Choi).* Fix the handling of dev_pm_qos_remove_request() result
(Leonard Crestez).* Use constant name for userspace governor (Pierre Kuo).
* Get rid of doc warnings and fix a typo (Christophe JAILLET).
- Use built-in RCU list checking in some places in the PM core to
avoid false-positive RCU usage warnings (Madhuparna Bhowmik).- Add explicit READ_ONCE()/WRITE_ONCE() annotations to low-level PM
QoS routines (Qian Cai).- Fix removal of wakeup sources to avoid NULL pointer dereferences in
a corner case (Neeraj Upadhyay).- Clean up the handling of hibernate compat ioctls and fix the
related documentation (Eric Biggers).- Update the idle_inject power capping driver to use variable-length
arrays instead of zero-length arrays (Gustavo Silva).- Fix list format in a PM QoS document (Randy Dunlap).
- Make the cpufreq stats module use scnprintf() to avoid potential
buffer overflows (Takashi Iwai).- Add pm_runtime_get_if_active() to PM-runtime API (Sakari Ailus).
- Allow no domain-idle-states DT property in generic PM domains (Ulf
Hansson).- Fix a broken y-axis scale in the intel_pstate_tracer utility (Doug
Smythies)"* tag 'pm-5.7-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: (78 commits)
cpufreq: intel_pstate: Simplify intel_pstate_cpu_init()
tools/power/x86/intel_pstate_tracer: fix a broken y-axis scale
ACPI: PM: s2idle: Refine active GPEs check
ACPICA: Allow acpi_any_gpe_status_set() to skip one GPE
PM: sleep: wakeup: Skip wakeup_source_sysfs_remove() if device is not there
PM / devfreq: Get rid of some doc warnings
PM / devfreq: Fix handling dev_pm_qos_remove_request result
PM / devfreq: Fix a typo in a comment
PM / devfreq: Change to DEVFREQ_GOV_UPDATE_INTERVAL event name
PM / devfreq: Remove unneeded extern keyword
PM / devfreq: Use constant name of userspace governor
ACPI: PM: s2idle: Fix comment in acpi_s2idle_prepare_late()
cpufreq: qcom: Add support for krait based socs
cpufreq: imx6q-cpufreq: Improve the logic of -EPROBE_DEFER handling
cpufreq: Use scnprintf() for avoiding potential buffer overflow
cpuidle: psci: Split psci_dt_cpu_init_idle()
PM / Domains: Allow no domain-idle-states DT property in genpd when parsing
PM / hibernate: Remove unnecessary compat ioctl overrides
PM: hibernate: fix docs for ioctls that return loff_t via pointer
Documentation: intel_pstate: update links for references
... -
Pull driver core updates from Greg KH:
"Here is the "big" set of driver core changes for 5.7-rc1.Nothing huge in here, just lots of little firmware core changes and
use of new apis, a libfs fix, a debugfs api change, and some driver
core deferred probe rework.All of these have been in linux-next for a while with no reported
issues"* tag 'driver-core-5.7-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: (44 commits)
Revert "driver core: Set fw_devlink to "permissive" behavior by default"
driver core: Set fw_devlink to "permissive" behavior by default
driver core: Replace open-coded list_last_entry()
driver core: Read atomic counter once in driver_probe_done()
libfs: fix infoleak in simple_attr_read()
driver core: Add device links from fwnode only for the primary device
platform/x86: touchscreen_dmi: Add info for the Chuwi Vi8 Plus tablet
platform/x86: touchscreen_dmi: Add EFI embedded firmware info support
Input: icn8505 - Switch to firmware_request_platform for retreiving the fw
Input: silead - Switch to firmware_request_platform for retreiving the fw
selftests: firmware: Add firmware_request_platform tests
test_firmware: add support for firmware_request_platform
firmware: Add new platform fallback mechanism and firmware_request_platform()
Revert "drivers: base: power: wakeup.c: Use built-in RCU list checking"
drivers: base: power: wakeup.c: Use built-in RCU list checking
component: allow missing unbind callback
debugfs: remove return value of debugfs_create_file_size()
debugfs: Check module state before warning in {full/open}_proxy_open()
firmware: fix a double abort case with fw_load_sysfs_fallback
arch_topology: Fix putting invalid cpu clk
... -
Pull USB / PHY updates from Greg KH:
"Here are the big set of USB and PHY driver patches for 5.7-rc1.Nothing huge here, some new PHY drivers, loads of USB gadget fixes and
updates, xhci updates, usb-serial driver updates and new device ids,
and other minor things. Full details in the shortlog.All have been in linux-next for a while with no reported issues"
* tag 'usb-5.7-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (239 commits)
USB: cdc-acm: restore capability check order
usb: cdns3: make signed 1 bit bitfields unsigned
usb: gadget: fsl: remove unused variable 'driver_desc'
usb: gadget: f_fs: Fix use after free issue as part of queue failure
usb: typec: Correct the documentation for typec_cable_put()
USB: serial: io_edgeport: fix slab-out-of-bounds read in edge_interrupt_callback
USB: serial: option: add Wistron Neweb D19Q1
USB: serial: option: add BroadMobi BM806U
USB: serial: option: add support for ASKEY WWHC050
usb: core: Add ACPI support for USB interface devices
driver core: platform: Reimplement devm_platform_ioremap_resource
usb: dwc2: convert to devm_platform_get_and_ioremap_resource
usb: host: hisilicon: convert to devm_platform_get_and_ioremap_resource
usb: host: xhci-plat: convert to devm_platform_get_and_ioremap_resource
drivers: provide devm_platform_get_and_ioremap_resource()
phy: qcom-qusb2: Add new overriding tuning parameters in QUSB2 V2 PHY
phy: qcom-qusb2: Add support for overriding tuning parameters in QUSB2 V2 PHY
dt-bindings: phy: qcom-qusb2: Add support for overriding Phy tuning parameters
phy: qcom-qusb2: Add generic QUSB2 V2 PHY support
dt-bindings: phy: qcom,qusb2: Add compatibles for QUSB2 V2 phy and SC7180
... -
Pull media updates from Mauro Carvalho Chehab:
- New sensor driver: imx219
- Support for some new pixelformats
- Support for Sun8i SoC
- Added more codecs to meson vdec driver
- Prepare for removing the legacy usbvision driver by moving it to
staging. This driver has issues and use legacy core APIs. If nobody
steps up to address those, it is time for its retirement.- Several cleanups and improvements on drivers, with the addition of
new supported boards* tag 'media/v5.7-1' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media: (236 commits)
media: venus: firmware: Ignore secure call error on first resume
media: mtk-vpu: load vpu firmware from the new location
media: i2c: video-i2c: fix build errors due to 'imply hwmon'
media: MAINTAINERS: add myself to co-maintain Hantro G1/G2 for i.MX8MQ
media: hantro: add initial i.MX8MQ support
media: dt-bindings: Document i.MX8MQ VPU bindings
media: vivid: fix incorrect PA assignment to HDMI outputs
media: hantro: Add linux-rockchip mailing list to MAINTAINERS
media: cedrus: h264: Fix 4K decoding on H6
media: siano: Use scnprintf() for avoiding potential buffer overflow
media: rc: Use scnprintf() for avoiding potential buffer overflow
media: allegro: create new struct for channel parameters
media: allegro: move mail definitions to separate file
media: allegro: pass buffers through firmware
media: allegro: verify source and destination buffer in VCU response
media: allegro: handle dependency of bitrate and bitrate_peak
media: allegro: read bitrate mode directly from control
media: allegro: make QP configurable
media: allegro: make frame rate configurable
media: allegro: skip filler data if possible
...
30 Mar, 2020
3 commits
-
* pm-core:
PM: runtime: Add pm_runtime_get_if_active()* pm-sleep:
PM: sleep: wakeup: Skip wakeup_source_sysfs_remove() if device is not there
PM / hibernate: Remove unnecessary compat ioctl overrides
PM: hibernate: fix docs for ioctls that return loff_t via pointer
PM: sleep: wakeup: Use built-in RCU list checking
PM: sleep: core: Use built-in RCU list checking* pm-acpi:
ACPI: PM: s2idle: Refine active GPEs check
ACPICA: Allow acpi_any_gpe_status_set() to skip one GPE
ACPI: PM: s2idle: Fix comment in acpi_s2idle_prepare_late()* pm-domains:
cpuidle: psci: Split psci_dt_cpu_init_idle()
PM / Domains: Allow no domain-idle-states DT property in genpd when parsing -
Minor comment conflict in mac80211.
Signed-off-by: David S. Miller
-
We see multiple issues with the implementation/interface to compute
whether a memory block can be offlined (exposed via
/sys/devices/system/memory/memoryX/removable) and would like to simplify
it (remove the implementation).1. It runs basically lockless. While this might be good for performance,
we see possible races with memory offlining that will require at
least some sort of locking to fix.2. Nowadays, more false positives are possible. No arch-specific checks
are performed that validate if memory offlining will not be denied
right away (and such check will require locking). For example, arm64
won't allow to offline any memory block that was added during boot -
which will imply a very high error rate. Other archs have other
constraints.3. The interface is inherently racy. E.g., if a memory block is detected
to be removable (and was not a false positive at that time), there is
still no guarantee that offlining will actually succeed. So any
caller already has to deal with false positives.4. It is unclear which performance benefit this interface actually
provides. The introducing commit 5c755e9fd813 ("memory-hotplug: add
sysfs removable attribute for hotplug memory remove") mentioned"A user-level agent must be able to identify which sections
of memory are likely to be removable before attempting the
potentially expensive operation."However, no actual performance comparison was included.
Known users:
- lsmem: Will group memory blocks based on the "removable" property. [1]
- chmem: Indirect user. It has a RANGE mode where one can specify
removable ranges identified via lsmem to be offlined. However,
it also has a "SIZE" mode, which allows a sysadmin to skip the
manual "identify removable blocks" step. [2]- powerpc-utils: Uses the "removable" attribute to skip some memory
blocks right away when trying to find some to offline+remove.
However, with ballooning enabled, it already skips this
information completely (because it once resulted in many false
negatives). Therefore, the implementation can deal with false
positives properly already. [3]According to Nathan Fontenot, DLPAR on powerpc is nowadays no longer
driven from userspace via the drmgr command (powerpc-utils). Nowadays
it's managed in the kernel - including onlining/offlining of memory
blocks - triggered by drmgr writing to /sys/kernel/dlpar. So the
affected legacy userspace handling is only active on old kernels. Only
very old versions of drmgr on a new kernel (unlikely) might execute
slower - totally acceptable.With CONFIG_MEMORY_HOTREMOVE, always indicating "removable" should not
break any user space tool. We implement a very bad heuristic now.
Without CONFIG_MEMORY_HOTREMOVE we cannot offline anything, so report
"not removable" as before.Original discussion can be found in [4] ("[PATCH RFC v1] mm:
is_mem_section_removable() overhaul").Other users of is_mem_section_removable() will be removed next, so that
we can remove is_mem_section_removable() completely.[1] http://man7.org/linux/man-pages/man1/lsmem.1.html
[2] http://man7.org/linux/man-pages/man8/chmem.8.html
[3] https://github.com/ibm-power-utilities/powerpc-utils
[4] https://lkml.kernel.org/r/20200117105759.27905-1-david@redhat.comAlso, this patch probably fixes a crash reported by Steve.
http://lkml.kernel.org/r/CAPcyv4jpdaNvJ67SkjyUJLBnBnXXQv686BiVW042g03FUmWLXw@mail.gmail.comReported-by: "Scargall, Steve"
Suggested-by: Michal Hocko
Signed-off-by: David Hildenbrand
Signed-off-by: Andrew Morton
Reviewed-by: Nathan Fontenot
Acked-by: Michal Hocko
Cc: Dan Williams
Cc: Greg Kroah-Hartman
Cc: "Rafael J. Wysocki"
Cc: Badari Pulavarty
Cc: Robert Jennings
Cc: Heiko Carstens
Cc: Karel Zak
Cc:
Link: http://lkml.kernel.org/r/20200128093542.6908-1-david@redhat.com
Signed-off-by: Linus Torvalds
27 Mar, 2020
1 commit
-
This reverts commit c442a0d18744d4a5857d513f171d68ed6a54df5b as it
breaks some of the Raspberry Pi devices. Marek writes:
This patch has just landed in linux-next 20200326. Sadly it
breaks booting of the Raspberry Pi3b and Pi4 boards, either in
32bit or 64bit mode. There is no warning nor panic message, just
a silent freeze. The last message shown on the earlycon is:[ 0.893217] Serial: 8250/16550 driver, 1 ports, IRQ sharing enabled
so revert it for now and let's try again and add it to linux-next after
5.7-rc1 is out so that we can try to get more debugging/testing
happening.Reported-by: Marek Szyprowski
Cc: Rob Herring
Cc: Frank Rowand
Cc: Saravana Kannan
Signed-off-by: Greg Kroah-Hartman
25 Mar, 2020
2 commits
-
Use separate functions for the device core to bring a CPU up and down.
Users outside the device core must use add/remove_cpu() which will take
care of extra housekeeping work like keeping sysfs in sync.Make cpu_up/down() static and replace the extra layer of indirection.
[ tglx: Removed the extra wrapper functions and adjusted function names ]
Signed-off-by: Qais Yousef
Signed-off-by: Thomas Gleixner
Link: https://lkml.kernel.org/r/20200323135110.30522-18-qais.yousef@arm.com -
Skip wakeup_source_sysfs_remove() to fix a NULL pinter dereference via
ws->dev, if the wakeup source is unregistered before registering the
wakeup class from device_add().Fixes: 2ca3d1ecb8c4 ("PM / wakeup: Register wakeup class kobj after device is added")
Signed-off-by: Neeraj Upadhyay
Cc: 5.4+ # 5.4+
[ rjw: Subject & changelog, white space ]
Signed-off-by: Rafael J. Wysocki
24 Mar, 2020
5 commits
-
Set fw_devlink to "permissive" behavior by default so that device links
are automatically created (with DL_FLAG_SYNC_STATE_ONLY) by scanning the
firmware.This ensures suppliers get their sync_state() calls only after all their
consumers have probed successfully. Without this, suppliers will get
their sync_state() calls at late_initcall_sync() even if their consuerIdeally, we'd want to set fw_devlink to "on" or "rpm" by default. But
that needs more testing as it's known to break some corner case
drivers/platforms.Cc: Rob Herring
Cc: Frank Rowand
Cc: devicetree@vger.kernel.org
Signed-off-by: Saravana Kannan
Link: https://lore.kernel.org/r/20200321210305.28937-1-saravanak@google.com
Signed-off-by: Greg Kroah-Hartman -
There is a place in the code where open-coded version of list entry accessors
list_last_entry() is used.Replace that with the standard macro.
Signed-off-by: Andy Shevchenko
Link: https://lore.kernel.org/r/20200324122023.9649-3-andriy.shevchenko@linux.intel.com
Signed-off-by: Greg Kroah-Hartman -
Between printing the debug message and actual check atomic counter can be
altered. For better debugging experience read atomic counter value only once.Signed-off-by: Andy Shevchenko
Tested-by: Ferry Toth
Link: https://lore.kernel.org/r/20200324122023.9649-2-andriy.shevchenko@linux.intel.com
Signed-off-by: Greg Kroah-Hartman -
Reimplement devm_platform_ioremap_resource() by calling
devm_platform_ioremap_and_get_resource() with res = NULL to
simplify the code.Suggested-by: Geert Uytterhoeven
Reviewed-by: Geert Uytterhoeven
Signed-off-by: Dejin Zheng
Link: https://lore.kernel.org/r/20200323160612.17277-6-zhengdejin5@gmail.com
Signed-off-by: Greg Kroah-Hartman -
Since commit "drivers: provide devm_platform_ioremap_resource()",
it was wrap platform_get_resource() and devm_ioremap_resource() as
single helper devm_platform_ioremap_resource(). but now, many drivers
still used platform_get_resource() and devm_ioremap_resource()
together in the kernel tree. The reason can not be replaced is they
still need use the resource variables obtained by platform_get_resource().
so provide this helper.Suggested-by: Geert Uytterhoeven
Suggested-by: Sergei Shtylyov
Reviewed-by: Geert Uytterhoeven
Signed-off-by: Dejin Zheng
Link: https://lore.kernel.org/r/20200323160612.17277-2-zhengdejin5@gmail.com
Signed-off-by: Greg Kroah-Hartman
23 Mar, 2020
1 commit
-
We need the USB fixes in here as well.
Signed-off-by: Greg Kroah-Hartman
21 Mar, 2020
1 commit
-
Sometimes, more than one (generally two) device can point to the same
fwnode. However, only one device is set as the fwnode's device
(fwnode->dev) and can be looked up from the fwnode.Typically, only one of these devices actually have a driver and actually
probe. If we create device links for all these devices, then the
suppliers' of these devices (with the same fwnode) will never get a
sync_state() call because one of their consumer devices will never probe
(because they don't have a driver).So, create device links only for the device that is considered as the
fwnode's device.One such example of this is the PCI bridge platform_device and the
corresponding pci_bus device. Both these devices will have the same
fwnode. It's the platform_device that is registered first and is set as
the fwnode's device. Also the platform_device is the one that actually
probes. Without this patch none of the suppliers of a PCI bridge
platform_device would get a sync_state() callback.Cc: Bjorn Helgaas
Cc: linux-pci@vger.kernel.org
Reviewed-by: Rafael J. Wysocki
Signed-off-by: Saravana Kannan
Link: https://lore.kernel.org/r/20200321045448.15192-1-saravanak@google.com
Signed-off-by: Greg Kroah-Hartman
20 Mar, 2020
1 commit
-
In some cases the platform's main firmware (e.g. the UEFI fw) may contain
an embedded copy of device firmware which needs to be (re)loaded into the
peripheral. Normally such firmware would be part of linux-firmware, but in
some cases this is not feasible, for 2 reasons:1) The firmware is customized for a specific use-case of the chipset / use
with a specific hardware model, so we cannot have a single firmware file
for the chipset. E.g. touchscreen controller firmwares are compiled
specifically for the hardware model they are used with, as they are
calibrated for a specific model digitizer.2) Despite repeated attempts we have failed to get permission to
redistribute the firmware. This is especially a problem with customized
firmwares, these get created by the chip vendor for a specific ODM and the
copyright may partially belong with the ODM, so the chip vendor cannot
give a blanket permission to distribute these.This commit adds a new platform fallback mechanism to the firmware loader
which will try to lookup a device fw copy embedded in the platform's main
firmware if direct filesystem lookup fails.Drivers which need such embedded fw copies can enable this fallback
mechanism by using the new firmware_request_platform() function.Note that for now this is only supported on EFI platforms and even on
these platforms firmware_fallback_platform() only works if
CONFIG_EFI_EMBEDDED_FIRMWARE is enabled (this gets selected by drivers
which need this), in all other cases firmware_fallback_platform() simply
always returns -ENOENT.Reported-by: Dave Olsthoorn
Suggested-by: Peter Jones
Acked-by: Luis Chamberlain
Signed-off-by: Hans de Goede
Link: https://lore.kernel.org/r/20200115163554.101315-5-hdegoede@redhat.com
Signed-off-by: Greg Kroah-Hartman
19 Mar, 2020
1 commit
-
This reverts commit 8ba88804bb3b877c841bc1864a8605111580cd0b as a better
version is already in Rafael's tree, sorry about that.Reported-by: "Rafael J. Wysocki"
Cc: Madhuparna Bhowmik
Signed-off-by: Greg Kroah-Hartman
18 Mar, 2020
4 commits
-
Pass cond argument to list_for_each_entry_rcu() to fix the
following false positive lockdep warning and other uses of
list_for_each_entry_rcu() in wakeup.c.[ 331.934648] =============================
[ 331.934650] WARNING: suspicious RCU usage
[ 331.934653] 5.6.0-rc1+ #5 Not tainted
[ 331.934655] -----------------------------
[ 331.934657] drivers/base/power/wakeup.c:408 RCU-list traversed in non-reader section!![ 333.025156] =============================
[ 333.025161] WARNING: suspicious RCU usage
[ 333.025168] 5.6.0-rc1+ #5 Not tainted
[ 333.025173] -----------------------------
[ 333.025180] drivers/base/power/wakeup.c:424 RCU-list traversed in non-reader section!!Cc: "Rafael J. Wysocki"
Signed-off-by: Madhuparna Bhowmik
Link: https://lore.kernel.org/r/20200228174745.9308-1-madhuparnabhowmik10@gmail.com
Signed-off-by: Greg Kroah-Hartman -
The component framework reuses the devres managed functions. There is no
need to specify an unbind() callback if the driver only wants to release
the devres managed resources. The bind/unbind is like the probe/remove
pair. The bind/probe is necessary and the unbind/remove is optional.Signed-off-by: Marco Felsch
Reviewed-by: Philipp Zabel
Link: https://lore.kernel.org/r/20200227104547.30085-1-m.felsch@pengutronix.de
Signed-off-by: Greg Kroah-Hartman -
fw_sysfs_wait_timeout may return err with -ENOENT
at fw_load_sysfs_fallback and firmware is already
in abort status, no need to abort again, so skip it.This issue is caused by concurrent situation like below:
when thread 1# wait firmware loading, thread 2# may write
-1 to abort loading and wakeup thread 1# before it timeout.
so wait_for_completion_killable_timeout of thread 1# would
return remaining time which is != 0 with fw_st->status
FW_STATUS_ABORTED.And the results would be converted into
err -ENOENT in __fw_state_wait_common and transfered to
fw_load_sysfs_fallback in thread 1#.
The -ENOENT means firmware status is already at ABORTED,
so fw_load_sysfs_fallback no need to get mutex to abort again.
-----------------------------
thread 1#,wait for loading
fw_load_sysfs_fallback
->fw_sysfs_wait_timeout
->__fw_state_wait_common
->wait_for_completion_killable_timeoutin __fw_state_wait_common,
...
93 ret = wait_for_completion_killable_timeout(&fw_st->completion, timeout);
94 if (ret != 0 && fw_st->status == FW_STATUS_ABORTED)
95 return -ENOENT;
96 if (!ret)
97 return -ETIMEDOUT;
98
99 return ret < 0 ? ret : 0;
-----------------------------
thread 2#, write -1 to abort loading
firmware_loading_store
->fw_load_abort
->__fw_load_abort
->fw_state_aborted
->__fw_state_set
->complete_allin __fw_state_set,
...
111 if (status == FW_STATUS_DONE || status == FW_STATUS_ABORTED)
112 complete_all(&fw_st->completion);
-------------------------------------------
BTW,the double abort issue would not cause kernel panic or create an issue,
but slow down it sometimes.The change is just a minor optimization.Signed-off-by: Junyong Sun
Acked-by: Luis Chamberlain
Link: https://lore.kernel.org/r/1583202968-28792-1-git-send-email-sunjunyong@xiaomi.com
Signed-off-by: Greg Kroah-Hartman -
Add a sanity check before putting the cpu clk.
Fixes: b8fe128dad8f (“arch_topology: Adjust initial CPU capacities with current freq")
Signed-off-by: Jeffy Chen
Link: https://lore.kernel.org/r/20200317063308.23209-1-jeffy.chen@rock-chips.com
Signed-off-by: Greg Kroah-Hartman
16 Mar, 2020
1 commit
-
This makes it possible to take advantage of the function in
the device drivers.Signed-off-by: Heikki Krogerus
Acked-by: Rafael J. Wysocki
Link: https://lore.kernel.org/r/20200302135353.56659-8-heikki.krogerus@linux.intel.com
Signed-off-by: Greg Kroah-Hartman
14 Mar, 2020
1 commit
-
Commit 2c361684803e ("PM / Domains: Don't treat zero found compatible idle
states as an error"), moved of_genpd_parse_idle_states() towards allowing
none compatible idle state to be found for the device node, rather than
returning an error code.However, it didn't consider that the "domain-idle-states" DT property may
be missing as it's optional, which makes of_count_phandle_with_args() to
return -ENOENT. Let's fix this to make the behaviour consistent.Fixes: 2c361684803e ("PM / Domains: Don't treat zero found compatible idle states as an error")
Reported-by: Benjamin Gaignard
Cc: 4.20+ # 4.20+
Reviewed-by: Sudeep Holla
Signed-off-by: Ulf Hansson
Signed-off-by: Rafael J. Wysocki
13 Mar, 2020
1 commit
-
Minor overlapping changes, nothing serious.
Signed-off-by: David S. Miller
12 Mar, 2020
1 commit
-
This does three inter-related things to clarify the usage of the
platform device dma_mask field. In the process, fix the bug introduced
by cdfee5623290 ("driver core: initialize a default DMA mask for
platform device") that caused Artem Tashkinov's laptop to not boot with
newer Fedora kernels.This does:
- First off, rename the field to "platform_dma_mask" to make it
greppable.We have way too many different random fields called "dma_mask" in
various data structures, where some of them are actual masks, and
some of them are just pointers to the mask. And the structures all
have pointers to each other, or embed each other inside themselves,
and "pdev" sometimes means "platform device" and sometimes it means
"PCI device".So to make it clear in the code when you actually use this new field,
give it a unique name (it really should be something even more unique
like "platform_device_dma_mask", since it's per platform device, not
per platform, but that gets old really fast, and this is unique
enough in context).To further clarify when the field gets used, initialize it when we
actually start using it with the default value.- Then, use this field instead of the random one-off allocation in
platform_device_register_full() that is now unnecessary since we now
already have a perfectly fine allocation for it in the platform
device structure.- The above then allows us to fix the actual bug, where the error path
of platform_device_register_full() would unconditionally free the
platform device DMA allocation with 'kfree()'.That kfree() was dont regardless of whether the allocation had been
done earlier with the (now removed) kmalloc, or whether
setup_pdev_dma_masks() had already been used and the dma_mask pointer
pointed to the mask that was part of the platform device.It seems most people never triggered the error path, or only triggered
it from a call chain that set an explicit pdevinfo->dma_mask value (and
thus caused the unnecessary allocation that was "cleaned up" in the
error path) before calling platform_device_register_full().Robin Murphy points out that in Artem's case the wdat_wdt driver failed
in platform_device_add(), and that was the one that had called
platform_device_register_full() with pdevinfo.dma_mask = 0, and would
have caused that kfree() of pdev.dma_mask corrupting the heap.A later unrelated kmalloc() then oopsed due to the heap corruption.
Fixes: cdfee5623290 ("driver core: initialize a default DMA mask for platform device")
Reported-bisected-and-tested-by: Artem S. Tashkinov
Reviewed-by: Robin Murphy
Cc: Greg Kroah-Hartman
Signed-off-by: Christoph Hellwig
Signed-off-by: Linus Torvalds
11 Mar, 2020
4 commits
-
Currently there are only 10 bytes to store the cpu-topology 'name'
information. Only 10 bytes copied into cluster/thread/core names.If the cluster ID exceeds 2-digit number, it will result in the data
corruption, and ending up in a dead loop in the parsing routines. The
same applies to the thread names with more that 3-digit number.This issue was found using the boundary tests under virtualised
environment like QEMU.Let us increase the buffer to fix such potential issues.
Reviewed-by: Sudeep Holla
Signed-off-by: Zeng TaoLink: https://lore.kernel.org/r/1583294092-5929-1-git-send-email-prime.zeng@hisilicon.com
Signed-off-by: Greg Kroah-Hartman -
The CPU freqs are not supposed to change before cpufreq policies
properly registered, meaning that they should be used to calculate the
initial CPU capacities.Doing this helps choosing the best CPU during early boot, especially
for the initramfs decompressing.There's no functional changes for non-clk CPU DVFS mechanism.
Signed-off-by: Jeffy Chen
Link: https://lore.kernel.org/r/20200113034815.25924-1-jeffy.chen@rock-chips.com
Signed-off-by: Greg Kroah-Hartman -
Use the simpler sprintf() instead of snprintf() or scnprintf() in a
single-shot sysfs output callbacks where you are very sure that it
won't go over PAGE_SIZE buffer limit.Signed-off-by: Takashi Iwai
Link: https://lore.kernel.org/r/20200311080207.12046-3-tiwai@suse.de
Signed-off-by: Greg Kroah-Hartman -
Since snprintf() returns the would-be-output size instead of the
actual output size, the succeeding calls may go beyond the given
buffer limit. Fix it by replacing with scnprintf().Signed-off-by: Takashi Iwai
Link: https://lore.kernel.org/r/20200311080207.12046-2-tiwai@suse.de
Signed-off-by: Greg Kroah-Hartman
10 Mar, 2020
1 commit
-
We need the USB fixes in here as well.
Signed-off-by: Greg Kroah-Hartman
09 Mar, 2020
1 commit
-
We need the driver core and debugfs changes in here as well.
Signed-off-by: Greg Kroah-Hartman
08 Mar, 2020
1 commit
-
Pull driver core and debugfs fixes from Greg KH:
"Here are four small driver core / debugfs patches for 5.6-rc3:- debugfs api cleanup now that all debugfs_create_regset32() callers
have been fixed up. This was waiting until after the -rc1 merge as
these fixes came in through different trees- driver core sync state fixes based on reports of minor issues found
in the featureAll of these have been in linux-next with no reported issues"
* tag 'driver-core-5.6-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core:
driver core: Skip unnecessary work when device doesn't have sync_state()
driver core: Add dev_has_sync_state()
driver core: Call sync_state() even if supplier has no consumers
debugfs: remove return value of debugfs_create_regset32()
07 Mar, 2020
1 commit
-
The Frequency Invariance Engine (FIE) is providing a frequency
scaling correction factor that helps achieve more accurate
load-tracking.So far, for arm and arm64 platforms, this scale factor has been
obtained based on the ratio between the current frequency and the
maximum supported frequency recorded by the cpufreq policy. The
setting of this scale factor is triggered from cpufreq drivers by
calling arch_set_freq_scale. The current frequency used in computation
is the frequency requested by a governor, but it may not be the
frequency that was implemented by the platform.This correction factor can also be obtained using a core counter and a
constant counter to get information on the performance (frequency based
only) obtained in a period of time. This will more accurately reflect
the actual current frequency of the CPU, compared with the alternative
implementation that reflects the request of a performance level from
the OS.Therefore, implement arch_scale_freq_tick to use activity monitors, if
present, for the computation of the frequency scale factor.The use of AMU counters depends on:
- CONFIG_ARM64_AMU_EXTN - depents on the AMU extension being present
- CONFIG_CPU_FREQ - the current frequency obtained using counter
information is divided by the maximum frequency obtained from the
cpufreq policy.While it is possible to have a combination of CPUs in the system with
and without support for activity monitors, the use of counters for
frequency invariance is only enabled for a CPU if all related CPUs
(CPUs in the same frequency domain) support and have enabled the core
and constant activity monitor counters. In this way, there is a clear
separation between the policies for which arch_set_freq_scale (cpufreq
based FIE) is used, and the policies for which arch_scale_freq_tick
(counter based FIE) is used to set the frequency scale factor. For
this purpose, a late_initcall_sync is registered to trigger validation
work for policies that will enable or disable the use of AMU counters
for frequency invariance. If CONFIG_CPU_FREQ is not defined, the use
of counters is enabled on all CPUs only if all possible CPUs correctly
support the necessary counters.Signed-off-by: Ionela Voinescu
Reviewed-by: Lukasz Luba
Acked-by: Sudeep Holla
Cc: Sudeep Holla
Cc: Will Deacon
Cc: Catalin Marinas
Signed-off-by: Catalin Marinas
05 Mar, 2020
2 commits
-
Fixes: 8375e74f2bca ("driver core: Add fw_devlink kernel commandline option")
Signed-off-by: kbuild test robot
Acked-by: Saravana Kannan
Link: https://lore.kernel.org/r/20200305020916.GA14234@3143ef58ba07
Signed-off-by: Greg Kroah-Hartman -
This reverts commit 3df85a1ae51f6b256982fe9d17c2dc5bfb4cc402.
The reverted commit says "It's possible to release the node ID
immediately when fwnode_remove_software_node() is called, no need to
wait for software_node_release() with that." However, releasing the node
ID before waiting for software_node_release() to be called causes the
node ID to be released before the kobject and the underlying sysfs
entry; this means there is a period of time where a sysfs entry exists
that is associated with an unallocated node ID.Once consequence of this is that there is a race condition where it is
possible to call fwnode_create_software_node() with no parent node
specified (NULL) and have it fail with -EEXIST because the node ID that
was assigned is still associated with a stale sysfs entry that hasn't
been cleaned up yet.Although it is difficult to reproduce this race condition under normal
conditions, it can be deterministically reproduced with the following
minconfig on UML:CONFIG_KUNIT_DRIVER_PE_TEST=y
CONFIG_DEBUG_KERNEL=y
CONFIG_DEBUG_OBJECTS=y
CONFIG_DEBUG_OBJECTS_TIMERS=y
CONFIG_DEBUG_KOBJECT_RELEASE=y
CONFIG_KUNIT=yRunning the tests with this configuration causes the following failure:
kobject: 'node0' ((____ptrval____)): kobject_release, parent (____ptrval____) (delayed 400)
ok 1 - pe_test_uints
sysfs: cannot create duplicate filename '/kernel/software_nodes/node0'
CPU: 0 PID: 28 Comm: kunit_try_catch Not tainted 5.6.0-rc3-next-20200227 #14kobject_add_internal failed for node0 with -EEXIST, don't try to register things with the same name in the same directory.
kobject: 'node0' ((____ptrval____)): kobject_release, parent (____ptrval____) (delayed 100)
# pe_test_uint_arrays: ASSERTION FAILED at drivers/base/test/property-entry-test.c:123
Expected node is not error, but is: -17
not ok 2 - pe_test_uint_arraysReported-by: Heidi Fahim
Signed-off-by: Brendan Higgins
Reviewed-by: Heikki Krogerus
Cc: 5.3+ # 5.3+
Signed-off-by: Rafael J. Wysocki
