aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2020-04-15arm64: vdso: don't free unallocated pagesMark Rutland1-12/+1
The aarch32_vdso_pages[] array never has entries allocated in the C_VVAR or C_VDSO slots, and as the array is zero initialized these contain NULL. However in __aarch32_alloc_vdso_pages() when aarch32_alloc_kuser_vdso_page() fails we attempt to free the page whose struct page is at NULL, which is obviously nonsensical. This patch removes the erroneous page freeing. Fixes: 7c1deeeb0130 ("arm64: compat: VDSO setup for compat layer") Cc: <[email protected]> # 5.3.x- Cc: Vincenzo Frascino <[email protected]> Acked-by: Will Deacon <[email protected]> Signed-off-by: Mark Rutland <[email protected]> Signed-off-by: Catalin Marinas <[email protected]>
2020-04-15i2c: remove i2c_new_probed_device APIWolfram Sang2-19/+0
All in-tree users have been converted to the new i2c_new_scanned_device function, so remove this deprecated one. Signed-off-by: Wolfram Sang <[email protected]> Signed-off-by: Wolfram Sang <[email protected]>
2020-04-15i2c: altera: use proper variable to hold errnoWolfram Sang1-5/+4
device_property_read_u32() returns errno or 0, so we should use the integer variable 'ret' and not the u32 'val' to hold the retval. Fixes: 0560ad576268 ("i2c: altera: Add Altera I2C Controller driver") Signed-off-by: Wolfram Sang <[email protected]> Reviewed-by: Thor Thayer <[email protected]> Signed-off-by: Wolfram Sang <[email protected]>
2020-04-15i2c: designware: platdrv: Remove DPM_FLAG_SMART_SUSPEND flag on BYT and CHTHans de Goede1-4/+10
We already set DPM_FLAG_SMART_PREPARE, so we completely skip all callbacks (other then prepare) where possible, quoting from dw_i2c_plat_prepare(): /* * If the ACPI companion device object is present for this device, it * may be accessed during suspend and resume of other devices via I2C * operation regions, so tell the PM core and middle layers to avoid * skipping system suspend/resume callbacks for it in that case. */ return !has_acpi_companion(dev); Also setting the DPM_FLAG_SMART_SUSPEND will cause acpi_subsys_suspend() to leave the controller runtime-suspended even if dw_i2c_plat_prepare() returned 0. Leaving the controller runtime-suspended normally, when the I2C controller is suspended during the suspend_late phase, is not an issue because the pm_runtime_get_sync() done by i2c_dw_xfer() will (runtime-)resume it. But for dw I2C controllers on Bay- and Cherry-Trail devices acpi_lpss.c leaves the controller alive until the suspend_noirq phase, because it may be used by the _PS3 ACPI methods of PCI devices and PCI devices are left powered on until the suspend_noirq phase. Between the suspend_late and resume_early phases runtime-pm is disabled. So for any ACPI I2C OPRegion accesses done after the suspend_late phase, the pm_runtime_get_sync() done by i2c_dw_xfer() is a no-op and the controller is left runtime-suspended. i2c_dw_xfer() has a check to catch this condition (rather then waiting for the I2C transfer to timeout because the controller is suspended). acpi_subsys_suspend() leaving the controller runtime-suspended in combination with an ACPI I2C OPRegion access done after the suspend_late phase triggers this check, leading to the following error being logged on a Bay Trail based Lenovo Thinkpad 8 tablet: [ 93.275882] i2c_designware 80860F41:00: Transfer while suspended [ 93.275993] WARNING: CPU: 0 PID: 412 at drivers/i2c/busses/i2c-designware-master.c:429 i2c_dw_xfer+0x239/0x280 ... [ 93.276252] Workqueue: kacpi_notify acpi_os_execute_deferred [ 93.276267] RIP: 0010:i2c_dw_xfer+0x239/0x280 ... [ 93.276340] Call Trace: [ 93.276366] __i2c_transfer+0x121/0x520 [ 93.276379] i2c_transfer+0x4c/0x100 [ 93.276392] i2c_acpi_space_handler+0x219/0x510 [ 93.276408] ? up+0x40/0x60 [ 93.276419] ? i2c_acpi_notify+0x130/0x130 [ 93.276433] acpi_ev_address_space_dispatch+0x1e1/0x252 ... So since on BYT and CHT platforms we want ACPI I2c OPRegion accesses to work until the suspend_noirq phase, we need the controller to be runtime-resumed during the suspend phase if it is runtime-suspended suspended at that time. This means that we must not set the DPM_FLAG_SMART_SUSPEND on these platforms. On BYT and CHT we already have a special ACCESS_NO_IRQ_SUSPEND flag to make sure the controller stays functional until the suspend_noirq phase. This commit makes the driver not set the DPM_FLAG_SMART_SUSPEND flag when that flag is set. Cc: [email protected] Fixes: b30f2f65568f ("i2c: designware: Set IRQF_NO_SUSPEND flag for all BYT and CHT controllers") Signed-off-by: Hans de Goede <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Acked-by: Rafael J. Wysocki <[email protected]> Acked-by: Jarkko Nikula <[email protected]> Signed-off-by: Wolfram Sang <[email protected]>
2020-04-15x86/umip: Make umip_insns staticJason Yan1-1/+1
Fix the following sparse warning: arch/x86/kernel/umip.c:84:12: warning: symbol 'umip_insns' was not declared. Should it be static? Reported-by: Hulk Robot <[email protected]> Signed-off-by: Jason Yan <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Acked-by: Ricardo Neri <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
2020-04-15sched/vtime: Work around an unitialized variable warningBorislav Petkov1-2/+2
Work around this warning: kernel/sched/cputime.c: In function ‘kcpustat_field’: kernel/sched/cputime.c:1007:6: warning: ‘val’ may be used uninitialized in this function [-Wmaybe-uninitialized] because GCC can't see that val is used only when err is 0. Acked-by: Peter Zijlstra <[email protected]> Signed-off-by: Borislav Petkov <[email protected]> Signed-off-by: Ingo Molnar <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-04-15sched/isolation: Allow "isolcpus=" to skip unknown sub-parametersPeter Xu1-2/+19
The "isolcpus=" parameter allows sub-parameters before the cpulist is specified, and if the parser detects an unknown sub-parameters the whole parameter will be ignored. This design is incompatible with itself when new sub-parameters are added. An older kernel will not recognize the new sub-parameter and will invalidate the whole parameter so the CPU isolation will not take effect. It emits a warning: isolcpus: Error, unknown flag The better and compatible way is to allow "isolcpus=" to skip unknown sub-parameters, so that even if new sub-parameters are added an older kernel will still be able to behave as usual even if with the new sub-parameter specified on the command line. Ideally this should have been there when the first sub-parameter for "isolcpus=" was introduced. Suggested-by: Thomas Gleixner <[email protected]> Signed-off-by: Peter Xu <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
2020-04-15clone3: add build-time CLONE_ARGS_SIZE_VER* validity checksEugene Syromiatnikov1-0/+8
CLONE_ARGS_SIZE_VER* macros are defined explicitly and not via the offsets of the relevant struct clone_args fields, which makes it rather error-prone, so it probably makes sense to add some compile-time checks for them (including the one that breaks on struct clone_args extension as a reminder to add a relevant size macro and a similar check). Function copy_clone_args_from_user seems to be a good place for such checks. Signed-off-by: Eugene Syromiatnikov <[email protected]> Acked-by: Christian Brauner <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Christian Brauner <[email protected]>
2020-04-15clone3: add a check for the user struct size if CLONE_INTO_CGROUP is setEugene Syromiatnikov1-1/+2
Passing CLONE_INTO_CGROUP with an under-sized structure (that doesn't properly contain cgroup field) seems like garbage input, especially considering the fact that fd 0 is a valid descriptor. Signed-off-by: Eugene Syromiatnikov <[email protected]> Acked-by: Christian Brauner <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Christian Brauner <[email protected]>
2020-04-15clone3: fix cgroup argument sanity checkEugene Syromiatnikov1-1/+1
Checking that cgroup field value of struct clone_args is less than 0 is useless, as it is defined as unsigned 64-bit integer. Moreover, it doesn't catch the situations where its higher bits are lost during the assignment to the cgroup field of the cgroup field of the internal struct kernel_clone_args (where it is declared as signed 32-bit integer), so it is still possible to pass garbage there. A check against INT_MAX solves both these issues. Fixes: ef2c41cf38a7559b ("clone3: allow spawning processes into cgroups") Signed-off-by: Eugene Syromiatnikov <[email protected]> Acked-by: Christian Brauner <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Christian Brauner <[email protected]>
2020-04-15mac80211: fix channel switch trigger from unknown mesh peerTamizh chelvam1-4/+7
Previously mesh channel switch happens if beacon contains CSA IE without checking the mesh peer info. Due to that channel switch happens even if the beacon is not from its own mesh peer. Fixing that by checking if the CSA originated from the same mesh network before proceeding for channel switch. Signed-off-by: Tamizh chelvam <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Johannes Berg <[email protected]>
2020-04-15mac80211: fix race in ieee80211_register_hw()Sumit Garg1-11/+13
A race condition leading to a kernel crash is observed during invocation of ieee80211_register_hw() on a dragonboard410c device having wcn36xx driver built as a loadable module along with a wifi manager in user-space waiting for a wifi device (wlanX) to be active. Sequence diagram for a particular kernel crash scenario: user-space ieee80211_register_hw() ieee80211_tasklet_handler() ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ | | | |<---phy0----wiphy_register() | |-----iwd if_add---->| | | |<---IRQ----(RX packet) | Kernel crash | | due to unallocated | | workqueue. | | | | | alloc_ordered_workqueue() | | | | | Misc wiphy init. | | | | | ieee80211_if_add() | | | | As evident from above sequence diagram, this race condition isn't specific to a particular wifi driver but rather the initialization sequence in ieee80211_register_hw() needs to be fixed. So re-order the initialization sequence and the updated sequence diagram would look like: user-space ieee80211_register_hw() ieee80211_tasklet_handler() ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ | | | | alloc_ordered_workqueue() | | | | | Misc wiphy init. | | | | |<---phy0----wiphy_register() | |-----iwd if_add---->| | | |<---IRQ----(RX packet) | | | | ieee80211_if_add() | | | | Cc: [email protected] Signed-off-by: Sumit Garg <[email protected]> Link: https://lore.kernel.org/r/[email protected] [Johannes: fix rtnl imbalances] Signed-off-by: Johannes Berg <[email protected]>
2020-04-14tracing: Fix the race between registering 'snapshot' event trigger and ↵Xiao Yang1-7/+3
triggering 'snapshot' operation Traced event can trigger 'snapshot' operation(i.e. calls snapshot_trigger() or snapshot_count_trigger()) when register_snapshot_trigger() has completed registration but doesn't allocate buffer for 'snapshot' event trigger. In the rare case, 'snapshot' operation always detects the lack of allocated buffer so make register_snapshot_trigger() allocate buffer first. trigger-snapshot.tc in kselftest reproduces the issue on slow vm: ----------------------------------------------------------- cat trace ... ftracetest-3028 [002] .... 236.784290: sched_process_fork: comm=ftracetest pid=3028 child_comm=ftracetest child_pid=3036 <...>-2875 [003] .... 240.460335: tracing_snapshot_instance_cond: *** SNAPSHOT NOT ALLOCATED *** <...>-2875 [003] .... 240.460338: tracing_snapshot_instance_cond: *** stopping trace here! *** ----------------------------------------------------------- Link: http://lkml.kernel.org/r/[email protected] Cc: [email protected] Fixes: 93e31ffbf417a ("tracing: Add 'snapshot' event trigger command") Signed-off-by: Xiao Yang <[email protected]> Signed-off-by: Steven Rostedt (VMware) <[email protected]>
2020-04-14io_uring: don't count rqs failed after current onePavel Begunkov1-3/+3
When checking for draining with __req_need_defer(), it tries to match how many requests were sent before a current one with number of already completed. Dropped SQEs are included in req->sequence, and they won't ever appear in CQ. To compensate for that, __req_need_defer() substracts ctx->cached_sq_dropped. However, what it should really use is number of SQEs dropped __before__ the current one. In other words, any submitted request shouldn't shouldn't affect dequeueing from the drain queue of previously submitted ones. Instead of saving proper ctx->cached_sq_dropped in each request, substract from req->sequence it at initialisation, so it includes number of properly submitted requests. note: it also changes behaviour of timeouts, but 1. it's already diverge from the description because of using SQ 2. the description is ambiguous regarding dropped SQEs Signed-off-by: Pavel Begunkov <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2020-04-14io_uring: kill already cached timeout.seq_offsetPavel Begunkov1-6/+3
req->timeout.count and req->io->timeout.seq_offset store the same value, which is sqe->off. Kill the second one Signed-off-by: Pavel Begunkov <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2020-04-14io_uring: fix cached_sq_head in io_timeout()Pavel Begunkov1-7/+8
io_timeout() can be executed asynchronously by a worker and without holding ctx->uring_lock 1. using ctx->cached_sq_head there is racy there 2. it should count events from a moment of timeout's submission, but not execution Use req->sequence. Signed-off-by: Pavel Begunkov <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2020-04-14Merge branch 'Fix-88x3310-leaving-power-save-mode'David S. Miller1-3/+33
Russell King says: ==================== Fix 88x3310 leaving power save mode This series fixes a problem with the 88x3310 PHY on Macchiatobin coming out of powersave mode noticed by Matteo Croce. It seems that certain PHY firmwares do not properly exit powersave mode, resulting in a fibre link not coming up. The solution appears to be to soft-reset the PHY after clearing the powersave bit. We add support for reporting the PHY firmware version to the kernel log, and use it to trigger this new behaviour if we have v0.3.x.x or more recent firmware on the PHY. This, however, is a guess as the firmware revision documentation does not mention this issue, and we know that v0.2.1.0 works without this fix but v0.3.3.0 and later does not. ==================== Signed-off-by: David S. Miller <[email protected]>
2020-04-14net: marvell10g: soft-reset the PHY when coming out of low powerRussell King1-3/+13
Soft-reset the PHY when coming out of low power mode, which seems to be necessary with firmware versions 0.3.3.0 and 0.3.10.0. This depends on ("net: marvell10g: report firmware version") Fixes: c9cc1c815d36 ("net: phy: marvell10g: place in powersave mode at probe") Reported-by: Matteo Croce <[email protected]> Tested-by: Matteo Croce <[email protected]> Reviewed-by: Andrew Lunn <[email protected]> Signed-off-by: Russell King <[email protected]> Reviewed-by: Florian Fainelli <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-04-14net: marvell10g: report firmware versionRussell King1-0/+20
Report the firmware version when probing the PHY to allow issues attributable to firmware to be diagnosed. Tested-by: Matteo Croce <[email protected]> Signed-off-by: Russell King <[email protected]> Reviewed-by: Andrew Lunn <[email protected]> Reviewed-by: Florian Fainelli <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-04-14net/cxgb4: Check the return from t4_query_params properlyJason Gunthorpe1-1/+1
Positive return values are also failures that don't set val, although this probably can't happen. Fixes gcc 10 warning: drivers/net/ethernet/chelsio/cxgb4/t4_hw.c: In function ‘t4_phy_fw_ver’: drivers/net/ethernet/chelsio/cxgb4/t4_hw.c:3747:14: warning: ‘val’ may be used uninitialized in this function [-Wmaybe-uninitialized] 3747 | *phy_fw_ver = val; Fixes: 01b6961410b7 ("cxgb4: Add PHY firmware support for T420-BT cards") Signed-off-by: Jason Gunthorpe <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-04-14net: stmmac: socfpga: Allow all RGMII modesAtsushi Nemoto1-0/+2
Allow all the RGMII modes to be used. (Not only "rgmii", "rgmii-id" but "rgmii-txid", "rgmii-rxid") Signed-off-by: Atsushi Nemoto <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-04-14Merge branch 'mv88e6xxx-fixed-link-fixes'David S. Miller2-3/+9
Andrew Lunn says: ==================== mv88e6xxx fixed link fixes Recent changes for how the MAC is configured broke fixed links, as used by CPU/DSA ports, and for SFPs when phylink cannot be used. The first fix is unchanged from v1. The second fix takes a different solution than v1. If a CPU or DSA port is known to have a PHYLINK instance, configure the port down before instantiating the PHYLINK, so it is in the down state as expected by PHYLINK. ==================== Signed-off-by: David S. Miller <[email protected]>
2020-04-14net: dsa: Down cpu/dsa ports phylink will controlAndrew Lunn1-1/+6
DSA and CPU ports can be configured in two ways. By default, the driver should configure such ports to there maximum bandwidth. For most use cases, this is sufficient. When this default is insufficient, a phylink instance can be bound to such ports, and phylink will configure the port, e.g. based on fixed-link properties. phylink assumes the port is initially down. Given that the driver should have already configured it to its maximum speed, ask the driver to down the port before instantiating the phylink instance. Fixes: 30c4a5b0aad8 ("net: mv88e6xxx: use resolved link config in mac_link_up()") Signed-off-by: Andrew Lunn <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-04-14net: dsa: mv88e6xxx: Configure MAC when using fixed linkAndrew Lunn1-2/+3
The 88e6185 is reporting it has detected a PHY, when a port is connected to an SFP. As a result, the fixed-phy configuration is not being applied. That then breaks packet transfer, since the port is reported as being down. Add additional conditions to check the interface mode, and if it is fixed always configure the port on link up/down, independent of the PPU status. Fixes: 30c4a5b0aad8 ("net: mv88e6xxx: use resolved link config in mac_link_up()") Signed-off-by: Andrew Lunn <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-04-14Merge branch 'ionic-address-automated-build-complaints'David S. Miller1-1/+2
Shannon Nelson says: ==================== ionic: address automated build complaints Kernel build checks found a couple of things to improve. ==================== Signed-off-by: David S. Miller <[email protected]>
2020-04-14ionic: fix unused assignmentShannon Nelson1-1/+1
Remove an unused initialized value. Fixes: 7e4d47596b68 ("ionic: replay filters after fw upgrade") Reported-by: kbuild test robot <[email protected]> Signed-off-by: Shannon Nelson <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-04-14ionic: add dynamic_debug headerShannon Nelson1-0/+1
Add the appropriate header for using dynamic_hex_dump(), which seems to be incidentally included in some configurations but not all. Fixes: 7e4d47596b68 ("ionic: replay filters after fw upgrade") Reported-by: Randy Dunlap <[email protected]> Signed-off-by: Shannon Nelson <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-04-14rxrpc: Fix DATA Tx to disable nofrag for UDP on AF_INET6 socketDavid Howells2-41/+12
Fix the DATA packet transmission to disable nofrag for UDPv4 on an AF_INET6 socket as well as UDPv6 when trying to transmit fragmentably. Without this, packets filled to the normal size used by the kernel AFS client of 1412 bytes be rejected by udp_sendmsg() with EMSGSIZE immediately. The ->sk_error_report() notification hook is called, but rxrpc doesn't generate a trace for it. This is a temporary fix; a more permanent solution needs to involve changing the size of the packets being filled in accordance with the MTU, which isn't currently done in AF_RXRPC. The reason for not doing so was that, barring the last packet in an rx jumbo packet, jumbos can only be assembled out of 1412-byte packets - and the plan was to construct jumbos on the fly at transmission time. Also, there's no point turning on IPV6_MTU_DISCOVER, since IPv6 has to engage in this anyway since fragmentation is only done by the sender. We can then condense the switch-statement in rxrpc_send_data_packet(). Fixes: 75b54cb57ca3 ("rxrpc: Add IPv6 support") Signed-off-by: David Howells <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-04-14net: phy: micrel: use genphy_read_status for KSZ9131Atsushi Nemoto1-1/+1
KSZ9131 will not work with some switches due to workaround for KSZ9031 introduced in commit d2fd719bcb0e83cb39cfee22ee800f98a56eceb3 ("net/phy: micrel: Add workaround for bad autoneg"). Use genphy_read_status instead of dedicated ksz9031_read_status. Fixes: bff5b4b37372 ("net: phy: micrel: add Microchip KSZ9131 initial driver") Signed-off-by: Atsushi Nemoto <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-04-14Merge branch 'opp/linux-next' of ↵Rafael J. Wysocki1-0/+14
git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm Merge an operating performance points (OPP) framework update for 5.7-rc2 from Viresh Kumar: "This contains a single patch that lets the OPP core to be used by several IO drivers without making a lot of changes in them for the case where the same driver may be used by a platform with an OPP table or a clock node on another one. I am looking to get this into 5.7 release itself, which will enable other users (in multiple frameworks) to get merged without waiting for the dependency to get resolved." * 'opp/linux-next' of git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm: opp: Manage empty OPP tables with clk handle
2020-04-14docs: dt: rockchip,dwc3.txt: fix a pointer to a renamed fileMauro Carvalho Chehab1-1/+1
phy-rockchip-inno-usb2.txt was converted to yaml. Fix the corresponding reference. Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Rob Herring <[email protected]>
2020-04-14docs: dt: fix a broken reference for a file converted to jsonMauro Carvalho Chehab1-1/+1
Changeset 32ced09d7903 ("dt-bindings: serial: Convert slave-device bindings to json-schema") moved a binding to json and updated the links. Yet, one link was not changed, due to a merge conflict. Update this one too. Fixes: 32ced09d7903 ("dt-bindings: serial: Convert slave-device bindings to json-schema") Reviewed-by: Geert Uytterhoeven <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Rob Herring <[email protected]>
2020-04-14docs: dt: qcom,dwc3.txt: fix cross-reference for a converted fileMauro Carvalho Chehab1-2/+2
The qcom-qusb2-phy.txt file was converted and renamed to yaml. Update cross-reference accordingly. Fixes: 8ce65d8d38df ("dt-bindings: phy: qcom,qusb2: Convert QUSB2 phy bindings to yaml") Reviewed-by: Stephen Boyd <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Rob Herring <[email protected]>
2020-04-14docs: dt: fix broken reference to phy-cadence-torrent.yamlMauro Carvalho Chehab1-1/+1
This file was removed, and another file was added instead of it, on two separate commits. Splitting a single logical change (doc conversion) on two patches is a bad thing, as it makes harder to discover what crap happened. Anyway, this patch fixes the broken reference, making it pointing to the new location of the file. Fixes: 922003733d42 ("dt-bindings: phy: Remove Cadence MHDP PHY dt binding") Fixes: c6d8eef38b7f ("dt-bindings: phy: Add Cadence MHDP PHY bindings in YAML format.") Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Rob Herring <[email protected]>
2020-04-14dt-bindings: interrupt-controller: Fix loongson,parent_int_map property schemaRob Herring1-3/+2
'loongson,parent_int_map' is an array, but the schema is defining a matrix resulting in the follow warnings: Documentation/devicetree/bindings/interrupt-controller/loongson,liointc.example.dt.yaml: interrupt-controller@3ff01400: loongson,parent_int_map:0: [4043309055] is too short Documentation/devicetree/bindings/interrupt-controller/loongson,liointc.example.dt.yaml: interrupt-controller@3ff01400: loongson,parent_int_map:1: [251658240] is too short Documentation/devicetree/bindings/interrupt-controller/loongson,liointc.example.dt.yaml: interrupt-controller@3ff01400: loongson,parent_int_map:2: [0] is too short Documentation/devicetree/bindings/interrupt-controller/loongson,liointc.example.dt.yaml: interrupt-controller@3ff01400: loongson,parent_int_map:3: [0] is too short The correct way to define an array is a list in 'items' and/or a size defined by 'minItems' and 'maxItems'. Cc: Thomas Gleixner <[email protected]> Cc: Jason Cooper <[email protected]> Cc: Marc Zyngier <[email protected]> Signed-off-by: Rob Herring <[email protected]>
2020-04-14dt-bindings: hwmon: Fix incorrect $id pathsRob Herring2-2/+2
Fix the path warnings in the adi,axi-fan-control and adt7475 bindings: Documentation/devicetree/bindings/hwmon/adt7475.yaml: $id: relative path/filename doesn't match actual path or filename expected: http://devicetree.org/schemas/hwmon/adt7475.yaml# Documentation/devicetree/bindings/hwmon/adi,axi-fan-control.yaml: $id: relative path/filename doesn't match actual path or filename expected: http://devicetree.org/schemas/hwmon/adi,axi-fan-control.yaml# Cc: Jean Delvare <[email protected]> Cc: [email protected] Acked-by: Guenter Roeck <[email protected]> Acked-by: Nuno Sá <[email protected]> Signed-off-by: Rob Herring <[email protected]>
2020-04-14dt-bindings: Fix dtc warnings on reg and ranges in examplesRob Herring8-23/+35
A recent update to dtc and changes to the default warnings introduced some new warnings in the DT binding examples: Documentation/devicetree/bindings/arm/sunxi/allwinner,sun4i-a10-mbus.example.dts:23.13-61: Warning (dma_ranges_format): /example-0/dram-controller@1c01000:dma-ranges: "dma-ranges" property has invalid length (12 bytes) (parent #address-cells == 1, child #address-cells == 2, #size-cells == 1) Documentation/devicetree/bindings/hwmon/adi,axi-fan-control.example.dts:17.22-28.11: Warning (unit_address_vs_reg): /example-0/fpga-axi@0: node has a unit name, but no reg or ranges property Documentation/devicetree/bindings/memory-controllers/nvidia,tegra186-mc.example.dts:34.13-54: Warning (dma_ranges_format): /example-0/memory-controller@2c00000:dma-ranges: "dma-ranges" property has invalid length (24 bytes) (parent #address-cells == 1, child #address-cells == 2, #size-cells == 2) Documentation/devicetree/bindings/mfd/st,stpmic1.example.dts:19.15-79.11: Warning (unit_address_vs_reg): /example-0/i2c@0: node has a unit name, but no reg or ranges property Documentation/devicetree/bindings/net/qcom,ipq8064-mdio.example.dts:28.23-31.15: Warning (unit_address_vs_reg): /example-0/mdio@37000000/switch@10: node has a unit name, but no reg or ranges property Documentation/devicetree/bindings/rng/brcm,bcm2835.example.dts:17.5-21.11: Warning (unit_address_vs_reg): /example-0/rng: node has a reg or ranges property, but no unit name Documentation/devicetree/bindings/spi/qcom,spi-qcom-qspi.example.dts:20.20-43.11: Warning (unit_address_vs_reg): /example-0/soc@0: node has a unit name, but no reg or ranges property Documentation/devicetree/bindings/usb/ingenic,musb.example.dts:18.28-21.11: Warning (unit_address_vs_reg): /example-0/usb-phy@0: node has a unit name, but no reg or ranges property Cc: Maxime Ripard <[email protected]> Cc: Chen-Yu Tsai <[email protected]> Cc: "Nuno Sá" <[email protected]> Cc: Jean Delvare <[email protected]> Cc: Thierry Reding <[email protected]> Cc: Jonathan Hunter <[email protected]> Cc: Lee Jones <[email protected]> Cc: "David S. Miller" <[email protected]> Cc: Matt Mackall <[email protected]> Cc: Herbert Xu <[email protected]> Cc: Nicolas Saenz Julienne <[email protected]> Cc: Florian Fainelli <[email protected]> Cc: Ray Jui <[email protected]> Cc: Scott Branden <[email protected]> Cc: [email protected] Cc: Mark Brown <[email protected]> Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Acked-by: Guenter Roeck <[email protected]> Reviewed-by: Bjorn Andersson <[email protected]> Signed-off-by: Rob Herring <[email protected]>
2020-04-14dt-bindings: BD718x7 - add missing I2C bus propertiesMatti Vaittinen2-2/+6
The DT example needs #address-cells and #size-cells for I2C bus or validity checker will generate warnings. Add these properties in BD71837 and BD71847 binding examples. Signed-off-by: Matti Vaittinen <[email protected]> Signed-off-by: Rob Herring <[email protected]>
2020-04-14dt-bindings: clock: syscon-icst: Remove unneeded unit nameFabio Estevam1-1/+1
The following warnings are seen with 'make dt_binding_check': Documentation/devicetree/bindings/clock/arm,syscon-icst.example.dts:17.16-24.11: Warning (unit_address_vs_reg): /example-0/clock@00: node has a unit name, but no reg or ranges property Documentation/devicetree/bindings/clock/arm,syscon-icst.example.dts:17.16-24.11: Warning (unit_address_format): /example-0/clock@00: unit name should not have leading 0s Fix them by removing the unneeded clock unit name. Signed-off-by: Fabio Estevam <[email protected]> Signed-off-by: Rob Herring <[email protected]>
2020-04-14dt-bindings: touchscreen: edt-ft5x06: Remove unneeded I2C unit nameFabio Estevam1-1/+1
The following warnings are seen with 'make dt_binding_check': Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.example.dts:19.22-30.11: Warning (unit_address_vs_reg): /example-0/i2c@00000000: node has a unit name, but no reg or ranges property Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.example.dts:19.22-30.11: Warning (unit_address_format): /example-0/i2c@00000000: unit name should not have leading 0s Fix it by removing the unneeded i2c unit name. Signed-off-by: Fabio Estevam <[email protected]> Signed-off-by: Rob Herring <[email protected]>
2020-04-14dt-bindings: iio: dac: ad5770r: Fix the file pathFabio Estevam1-1/+1
The following warning is seen with 'make dt_binding_check': Documentation/devicetree/bindings/iio/dac/adi,ad5770r.yaml: $id: relative path/filename doesn't match actual path or filename Fix it by removing the "bindings" directory from the file path. Signed-off-by: Fabio Estevam <[email protected]> Signed-off-by: Rob Herring <[email protected]>
2020-04-14dt-bindings: iio: dac: ad5770r: Add vendor to compatible stringFabio Estevam1-1/+1
The compatible string in the example misses the vendor information. Pass the "adi" vendor to fix it. Signed-off-by: Fabio Estevam <[email protected]> Acked-by: Rob Herring <[email protected]> Signed-off-by: Rob Herring <[email protected]>
2020-04-14Merge tag 'wireless-drivers-2020-04-14' of ↵David S. Miller3-9/+14
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers Kalle Valo says: ==================== wireless-drivers fixes for v5.7 First set of fixes for v5.6. Fixes for a crash and for two compiler warnings. brcmfmac * fix a crash related to monitor interface ath11k * fix compiler warnings without CONFIG_THERMAL rtw88 * fix compiler warnings related to suspend and resume functions ==================== Signed-off-by: David S. Miller <[email protected]>
2020-04-14bpf: remove unneeded conversion to bool in __mark_reg_unknownZou Wei1-2/+1
This issue was detected by using the Coccinelle software: kernel/bpf/verifier.c:1259:16-21: WARNING: conversion to bool not needed here The conversion to bool is unneeded, remove it. Reported-by: Hulk Robot <[email protected]> Signed-off-by: Zou Wei <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Acked-by: Song Liu <[email protected]> Link: https://lore.kernel.org/bpf/[email protected]
2020-04-14xdp: Reset prog in dev_change_xdp_fd when fd is negativeDavid Ahern1-1/+2
The commit mentioned in the Fixes tag reuses the local prog variable when looking up an expected_fd. The variable is not reset when fd < 0 causing a detach with the expected_fd set to actually call dev_xdp_install for the existing program. The end result is that the detach does not happen. Fixes: 92234c8f15c8 ("xdp: Support specifying expected existing program when attaching XDP") Signed-off-by: David Ahern <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Reviewed-by: Jakub Kicinski <[email protected]> Reviewed-by: Toke Høiland-Jørgensen <[email protected]> Link: https://lore.kernel.org/bpf/[email protected]
2020-04-14tools, bpftool: Fix struct_ops command invalid pointer freeDaniel T. Lee1-1/+3
In commit 65c93628599d ("bpftool: Add struct_ops support") a new type of command named struct_ops has been added. This command requires a kernel with CONFIG_DEBUG_INFO_BTF=y set and for retrieving BTF info in bpftool, the helper get_btf_vmlinux() is used. When running this command on kernel without BTF debug info, this will lead to 'btf_vmlinux' variable being an invalid(error) pointer. And by this, btf_free() causes a segfault when executing 'bpftool struct_ops'. This commit adds pointer validation with IS_ERR not to free invalid pointer, and this will fix the segfault issue. Fixes: 65c93628599d ("bpftool: Add struct_ops support") Signed-off-by: Daniel T. Lee <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Acked-by: Martin KaFai Lau <[email protected]> Link: https://lore.kernel.org/bpf/[email protected]
2020-04-14selftests/bpf: Validate frozen map contents stays frozenAndrii Nakryiko1-2/+60
Test that frozen and mmap()'ed BPF map can't be mprotect()'ed as writable or executable memory. Also validate that "downgrading" from writable to read-only doesn't screw up internal writable count accounting for the purposes of map freezing. Signed-off-by: Andrii Nakryiko <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Link: https://lore.kernel.org/bpf/[email protected]
2020-04-14bpf: Prevent re-mmap()'ing BPF map as writable for initially r/o mappingAndrii Nakryiko1-9/+7
VM_MAYWRITE flag during initial memory mapping determines if already mmap()'ed pages can be later remapped as writable ones through mprotect() call. To prevent user application to rewrite contents of memory-mapped as read-only and subsequently frozen BPF map, remove VM_MAYWRITE flag completely on initially read-only mapping. Alternatively, we could treat any memory-mapping on unfrozen map as writable and bump writecnt instead. But there is little legitimate reason to map BPF map as read-only and then re-mmap() it as writable through mprotect(), instead of just mmap()'ing it as read/write from the very beginning. Also, at the suggestion of Jann Horn, drop unnecessary refcounting in mmap operations. We can just rely on VMA holding reference to BPF map's file properly. Fixes: fc9702273e2e ("bpf: Add mmap() support for BPF_MAP_TYPE_ARRAY") Reported-by: Jann Horn <[email protected]> Signed-off-by: Andrii Nakryiko <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Reviewed-by: Jann Horn <[email protected]> Link: https://lore.kernel.org/bpf/[email protected]
2020-04-14arm, bpf: Fix offset overflow for BPF_MEM BPF_DWLuke Nelson1-16/+24
This patch fixes an incorrect check in how immediate memory offsets are computed for BPF_DW on arm. For BPF_LDX/ST/STX + BPF_DW, the 32-bit arm JIT breaks down an 8-byte access into two separate 4-byte accesses using off+0 and off+4. If off fits in imm12, the JIT emits a ldr/str instruction with the immediate and avoids the use of a temporary register. While the current check off <= 0xfff ensures that the first immediate off+0 doesn't overflow imm12, it's not sufficient for the second immediate off+4, which may cause the second access of BPF_DW to read/write the wrong address. This patch fixes the problem by changing the check to off <= 0xfff - 4 for BPF_DW, ensuring off+4 will never overflow. A side effect of simplifying the check is that it now allows using negative immediate offsets in ldr/str. This means that small negative offsets can also avoid the use of a temporary register. This patch introduces no new failures in test_verifier or test_bpf.c. Fixes: c5eae692571d6 ("ARM: net: bpf: improve 64-bit store implementation") Fixes: ec19e02b343db ("ARM: net: bpf: fix LDX instructions") Co-developed-by: Xi Wang <[email protected]> Signed-off-by: Xi Wang <[email protected]> Signed-off-by: Luke Nelson <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Link: https://lore.kernel.org/bpf/[email protected]
2020-04-14Merge tag 'hyperv-fixes-signed' of ↵Linus Torvalds7-24/+67
git://git.kernel.org/pub/scm/linux/kernel/git/hyperv/linux Pull hyperv fixes from Wei Liu: - a series from Tianyu Lan to fix crash reporting on Hyper-V - three miscellaneous cleanup patches * tag 'hyperv-fixes-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/hyperv/linux: x86/Hyper-V: Report crash data in die() when panic_on_oops is set x86/Hyper-V: Report crash register data when sysctl_record_panic_msg is not set x86/Hyper-V: Report crash register data or kmsg before running crash kernel x86/Hyper-V: Trigger crash enlightenment only once during system crash. x86/Hyper-V: Free hv_panic_page when fail to register kmsg dump x86/Hyper-V: Unload vmbus channel in hv panic callback x86: hyperv: report value of misc_features hv_debugfs: Make hv_debug_root static hv: hyperv_vmbus.h: Replace zero-length array with flexible-array member
Powered by cgit, Gruvboxed by Blaster4385.