- 01 Dec, 2018 40 commits
-
-
Steven Rostedt (VMware) authored
commit 896bbb25 upstream. When priority inheritance was added back in 2.6.18 to sched_setscheduler(), it added a path to taking an rt-mutex wait_lock, which is not IRQ safe. As PI is not a common occurrence, lockdep will likely never trigger if sched_setscheduler was called from interrupt context. A BUG_ON() was added to trigger if __sched_setscheduler() was ever called from interrupt context because there was a possibility to take the wait_lock. Today the wait_lock is irq safe, but the path to taking it in sched_setscheduler() is the same as the path to taking it from normal context. The wait_lock is taken with raw_spin_lock_irq() and released with raw_spin_unlock_irq() which will indiscriminately enable interrupts, which would be bad in interrupt context. The problem is that normalize_rt_tasks, which is called by triggering the sysrq nice-all-RT-tasks was changed to call __sched_setscheduler(), and this is done from interrupt context! Now __sched_setscheduler() takes a "pi" parameter that is used to know if the priority inheritance should be called or not. As the BUG_ON() only cares about calling the PI code, it should only bug if called from interrupt context with the "pi" parameter set to true. Reported-by:
Laurent Dufour <ldufour@linux.vnet.ibm.com> Tested-by:
Steven Rostedt (VMware) <rostedt@goodmis.org> Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Andrew Morton <akpm@osdl.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Fixes: dbc7f069 ("sched: Use replace normalize_task() with __sched_setscheduler()") Link: http://lkml.kernel.org/r/20170308124654.10e598f2@gandalf.local.homeSigned-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Aaron Ma authored
commit 958c0bd8 upstream. Realtek USB3.0 Card Reader [0bda:0328] reports wrong port status on Cannon lake PCH USB3.1 xHCI [8086:a36d] after resume from S3, after clear port reset it works fine. Since this device is registered on USB3 roothub at boot, when port status reports not superspeed, xhci_get_port_status will call an uninitialized completion in bus_state[0]. Kernel will hang because of NULL pointer. Restrict the USB2 resume status check in USB2 roothub to fix hang issue. Cc: stable@vger.kernel.org Signed-off-by:
Aaron Ma <aaron.ma@canonical.com> Signed-off-by:
Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by:
-
Greg Kroah-Hartman authored
commit b97b3d9f upstream. If we are not echoing the data to userspace or the console is in icanon mode, then perhaps it is a "secret" so we should wipe it once we are done with it. This mirrors the logic that the audit code has. Reported-by:
aszlig <aszlig@nix.build> Tested-by:
Milan Broz <gmazyland@gmail.com> Tested-by:
Daniel Zatovic <daniel.zatovic@gmail.com> Tested-by:
-
Linus Torvalds authored
commit c9a8e5fc upstream. After we are done with the tty buffer, zero it out. Reported-by:
-
Sebastien Boisvert authored
commit 4d54954a upstream. Tracing the event "fs_dax:dax_pmd_insert_mapping" with perf produces this warning: [fs_dax:dax_pmd_insert_mapping] unknown op '~' It is printed in process_op (tools/lib/traceevent/event-parse.c) because '~' is parsed as a binary operator. perf reads the format of fs_dax:dax_pmd_insert_mapping ("print fmt") from /sys/kernel/debug/tracing/events/fs_dax/dax_pmd_insert_mapping/format . The format contains: ~(((u64) ~(~(((1UL) << 12)-1))) ^ \ interpreted as a binary operator by process_op(). This part is generated in the declaration of the event class dax_pmd_insert_mapping_class in include/trace/events/fs_dax.h : __print_flags_u64(__entry->pfn_val & PFN_FLAGS_MASK, "|", PFN_FLAGS_TRACE), This patch adds a pair of parentheses in the declaration of PFN_FLAGS_MASK to make sure that '~' is parsed as a unary operator by perf. The part of the format that was problematic is now: ~(((u64) (~(~(((1UL) << 12)-1)))) Now, all the '~' are parsed as unary operators. Link: http://lkml.kernel.org/r/20181021145939.8760-1-sebhtml@videotron.qc.caSigned-off-by:
Sebastien Boisvert <sebhtml@videotron.qc.ca> Acked-by:
Dan Williams <dan.j.williams@intel.com> Cc: "Steven Rostedt (VMware)" <rostedt@goodmis.org> Cc: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: "Tzvetomir Stoyanov (VMware)" <tz.stoyanov@gmail.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Ross Zwisler <zwisler@kernel.org> Cc: Elenie Godzaridis <arangradient@gmail.com> Cc: <stable@vger.kerenl.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Subhash Jadavani authored
commit afa3dfd4 upstream. If ufshcd pltfrm/pci driver's probe fails for some reason then ensure that scsi host is released to avoid memory leak but managed memory allocations (via devm_* calls) need not to be freed explicitly on probe failure as memory allocated with these functions is automatically freed on driver detach. Reviewed-by:
Sahitya Tummala <stummala@codeaurora.org> Signed-off-by:
Subhash Jadavani <subhashj@codeaurora.org> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
Amit Pundir <amit.pundir@linaro.org> Signed-off-by:
-
Subhash Jadavani authored
commit 30fc33f1 upstream. UFS devfreq clock scaling work may require clocks to be ON if it need to execute some UFS commands hence it may request for clock hold before issuing the command. But if UFS clock gating work is already running in parallel, ungate work would end up waiting for the clock gating work to finish and as clock gating work would also wait for the clock scaling work to finish, we would enter in deadlock state. Here is the call trace during this deadlock state: Workqueue: devfreq_wq devfreq_monitor __switch_to __schedule schedule schedule_timeout wait_for_common wait_for_completion flush_work ufshcd_hold ufshcd_send_uic_cmd ufshcd_dme_get_attr ufs_qcom_set_dme_vs_core_clk_ctrl_clear_div ufs_qcom_clk_scale_notify ufshcd_scale_clks ufshcd_devfreq_target update_devfreq devfreq_monitor process_one_work worker_thread kthread ret_from_fork Workqueue: events ufshcd_gate_work __switch_to __schedule schedule schedule_preempt_disabled __mutex_lock_slowpath mutex_lock devfreq_monitor_suspend devfreq_simple_ondemand_handler devfreq_suspend_device ufshcd_gate_work process_one_work worker_thread kthread ret_from_fork Workqueue: events ufshcd_ungate_work __switch_to __schedule schedule schedule_timeout wait_for_common wait_for_completion flush_work __cancel_work_timer cancel_delayed_work_sync ufshcd_ungate_work process_one_work worker_thread kthread ret_from_fork This change fixes this deadlock by doing this in devfreq work (devfreq_wq): Try cancelling clock gating work. If we are able to cancel gating work or it wasn't scheduled, hold the clock reference count until scaling is in progress. If gate work is already running in parallel, let's skip the frequecy scaling at this time and it will be retried once next scaling window expires. Reviewed-by:
-
Venkat Gopalakrishnan authored
commit f2a785ac upstream. The ungate work turns on the clock before it exits hibern8, if the link was put in hibern8 during clock gating work. There occurs a race condition when clock scaling work calls ufshcd_hold() to make sure low power states cannot be entered, but that returns by checking only whether the clocks are on. This causes the clock scaling work to issue UIC commands when the link is in hibern8 causing failures. Make sure we exit hibern8 state before returning from ufshcd_hold(). Callstacks for race condition: ufshcd_scale_gear ufshcd_devfreq_scale ufshcd_devfreq_target update_devfreq devfreq_monitor process_one_work worker_thread kthread ret_from_fork ufshcd_uic_hibern8_exit ufshcd_ungate_work process_one_work worker_thread kthread ret_from_fork Signed-off-by:
Venkat Gopalakrishnan <venkatg@codeaurora.org> Signed-off-by:
-
Yaniv Gardi authored
commit e3ce73d6 upstream. In this change there are a few fixes of possible NULL pointer access and possible access to index that exceeds array boundaries. Signed-off-by:
Yaniv Gardi <ygardi@codeaurora.org> Signed-off-by:
-
Karthik D A authored
commit 3d8bd85c upstream. Marvell p2p device disappears from the list of p2p peers on the other p2p device after disconnection. It happens due to a bug in driver. When interface is changed from p2p to station, certain variables(bss_type, bss_role etc.) aren't correctly updated. This patch corrects them to fix the issue. Signed-off-by:
Karthik D A <karthida@marvell.com> Signed-off-by:
Amitkumar Karwar <akarwar@marvell.com> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org> Signed-off-by:
-
Amitkumar Karwar authored
commit c44c0403 upstream. At couple of places in cleanup path, we are just going through the skb queue and freeing them without unlinking. This leads to a crash when other thread tries to do skb_dequeue() and use already freed node. The problem is freed by unlinking skb before freeing it. Signed-off-by:
-
Amitkumar Karwar authored
commit 5190f2e4 upstream. When host_sleep_config command fails, we should return an error to PCIe, instead of continuing (and possibly panicking, when we try to keep processing a timed-out ioctl after we return "successfully" from suspend). Signed-off-by:
Brian Norris <briannorris@chromium.org> Tested-by:
-
Amitkumar Karwar authored
commit ec815dd2 upstream. Following is mwifiex driver-firmware host sleep handshake. It involves three threads. suspend handler, interrupt handler, interrupt processing in main work queue. 1) Enter suspend handler 2) Download HS_CFG command 3) Response from firmware for HS_CFG 4) Suspend thread waits until handshake completes(i.e hs_activate becomes true) 5) SLEEP from firmware 6) SLEEP confirm downloaded to firmware. 7) SLEEP confirm response from firmware 8) Driver processes SLEEP confirm response and set hs_activate to wake up suspend thread 9) Exit suspend handler 10) Read sleep cookie in loop and wait until it indicates firmware is sleep. 11) After processing SLEEP confirm response, we are at the end of interrupt processing routine. Recheck if there are interrupts received while we were processing them. During suspend-resume stress test, it's been observed that we may end up acessing PCIe hardware(in 10 and 11) when PCIe bus is closed which leads to a kernel crash. This patch solves the problem with below changes. a) action 10 above can be done before 8 b) Skip 11 if hs_activated is true. SLEEP confirm response is the last interrupt from firmware. No need to recheck for pending interrupts. c) Add flush_workqueue() in suspend handler. Signed-off-by:
-
Johannes Thumshirn authored
commit 9afdd612 upstream. The call to krealloc() in wsm_buf_reserve() directly assigns the newly returned memory to buf->begin. This is all fine except when krealloc() failes we loose the ability to free the old memory pointed to by buf->begin. If we just create a temporary variable to assign memory to and assign the memory to it we can mitigate the memory leak. Signed-off-by:
Johannes Thumshirn <jthumshirn@suse.de> Cc: Johannes Berg <johannes@sipsolutions.net> Signed-off-by:
-
Ramses Ramírez authored
[ Upstream commit 9735082a ] The "Xbox One PDP Wired Controller - Camo series" has a different product-id than the regular PDP controller and the PDP stealth series, but it uses the same initialization sequence. This patch adds the product-id of the camo series to the structures that handle the other PDP Xbox One controllers. Signed-off-by:
Ramses Ramírez <ramzeto@gmail.com> Cc: stable@vger.kernel.org Signed-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Enno Boland authored
[ Upstream commit dd6bee81 ] This fixes using the controller with SDL2. SDL2 has a naive algorithm to apply the correct settings to a controller. For X-Box compatible controllers it expects that the controller name contains a variation of a 'XBOX'-string. This patch changes the identifier to contain "X-Box" as substring. Tested with Steam and C-Dogs-SDL which both detect the controller properly after adding this patch. Fixes: c1ba0839 ("Input: xpad - add GPD Win 2 Controller USB IDs") Cc: stable@vger.kernel.org Signed-off-by:
Enno Boland <gottox@voidlinux.eu> Signed-off-by:
-
Ethan Lee authored
[ Upstream commit c1ba0839 ] GPD Win 2 Website: http://www.gpd.hk/gpdwin2.asp Tested on a unit from the first production run sent to Indiegogo backers Signed-off-by:
Ethan Lee <flibitijibibo@gmail.com> Cc: stable@vger.kernel.org Signed-off-by:
-
Marcus Folkesson authored
[ Upstream commit a0130803 ] input_set_capability() and input_set_abs_param() will do it for you. Signed-off-by:
Marcus Folkesson <marcus.folkesson@gmail.com> Signed-off-by:
-
Leo Sperling authored
[ Upstream commit 68c78d01 ] Fix some coding style issues reported by checkpatch.pl. Mostly brackets in macros, spacing and comment style. Signed-off-by:
Leo Sperling <leosperling97@gmail.com> Signed-off-by:
-
Francis Therien authored
[ Upstream commit c6c84857 ] Adds support for a PDP Xbox One controller with device ID (0x06ef:0x02a4). The Product string for this device is "PDP Wired Controller for Xbox One - Stealth Series | Phantom Black". Signed-off-by:
Francis Therien <frtherien@gmail.com> Signed-off-by:
-
Mark Furneaux authored
[ Upstream commit e5c9c6a8 ] Adds support for the current lineup of Xbox One controllers from PDP (Performance Designed Products). These controllers are very picky with their initialization sequence and require an additional 2 packets before they send any input reports. Signed-off-by:
Mark Furneaux <mark@furneaux.ca> Reviewed-by:
Cameron Gutman <aicommander@gmail.com> Cc: stable@vger.kernel.org Signed-off-by:
-
Cameron Gutman authored
[ Upstream commit 122d6a34 ] We should only see devices with interrupt endpoints. Ignore any other endpoints that we find, so we don't send try to send them interrupt URBs and trigger a WARN down in the USB stack. Reported-by:
Andrey Konovalov <andreyknvl@google.com> Tested-by:
-
Cameron Gutman authored
[ Upstream commit f5308d1b ] The PowerA gamepad initialization quirk worked with the PowerA wired gamepad I had around (0x24c6:0x543a), but a user reported [0] that it didn't work for him, even though our gamepads shared the same vendor and product IDs. When I initially implemented the PowerA quirk, I wanted to avoid actually triggering the rumble action during init. My tests showed that my gamepad would work correctly even if it received a rumble of 0 intensity, so that's what I went with. Unfortunately, this apparently isn't true for all models (perhaps a firmware difference?). This non-working gamepad seems to require the real magic rumble packet that the Microsoft driver sends, which actually vibrates the gamepad. To counteract this effect, I still send the old zero-rumble PowerA quirk packet which cancels the rumble effect before the motors can spin up enough to vibrate. [0]: https://github.com/paroj/xpad/issues/48#issuecomment-313904867Reported-by:
Kyle Beauchamp <kyleabeauchamp@gmail.com> Tested-by:
-
Arvind Yadav authored
[ Upstream commit 94aef061 ] usb_device_id are not supposed to change at runtime. All functions working with usb_device_id provided by <linux/usb.h> work with const usb_device_id. So mark the non-const structs as const. Signed-off-by:
Arvind Yadav <arvind.yadav.cs@gmail.com> Signed-off-by:
-
Benjamin Valentin authored
[ Upstream commit be19788c ] XBCD [0][1] is an OpenSource driver for Xbox controllers on Windows. Later it also started supporting Xbox360 controllers (presumably before the official Windows driver was released). It contains a couple device IDs unknown to the Linux driver, so I extracted those from xbcd.inf and added them to our list. It has a special type for Wheels and I have the feeling they might need some extra handling. They all have 'Wheel' in their name, so that information is available for future improvements. [0] https://www.s-config.com/xbcd-original-xbox-controllers-win10/ [1] http://www.redcl0ud.com/xbcd.htmlReviewed-by:
Benjamin Valentin <benpicco@googlemail.com> Signed-off-by:
-
Benjamin Valentin authored
[ Upstream commit c225370e ] 360Controller [0] is an OpenSource driver for Xbox/Xbox360/XboxOne controllers on macOS. It contains a couple device IDs unknown to the Linux driver, so I wrote a small Python script [1] to extract them and feed them into my previous script [2] to compare them with the IDs known to Linux. For most devices, this information is not really needed as xpad is able to automatically detect the type of an unknown Xbox Controller at run-time. I've therefore stripped all the generic/vague entries. I've excluded the Logitech G920, it's handled by a HID driver already. I've also excluded the Scene It! Big Button IR, it's handled by an out-of-tree driver. [3] [0] https://github.com/360Controller/360Controller [1] http://codepad.org/v9GyLKMq [2] http://codepad.org/qh7jclpD [3] https://github.com/micolous/xbox360bbReviewed-by:
-
Benjamin Valentin authored
[ Upstream commit 4706aa07 ] Add USB IDs for two more Xbox 360 controllers. I found them in the pull requests for the xboxdrv userspace driver, which seems abandoned. Thanks to psychogony and mkaito for reporting the IDs there! Signed-off-by:
-
Benjamin Valentin authored
[ Upstream commit 44bc7225 ] The userspace xboxdrv driver [0] contains some USB IDs unknown to the kernel driver. I have created a simple script [1] to extract the missing devices and add them to xpad. A quick google search confirmed that all the new devices called Fightstick/pad are Arcade-type devices [2] where the MAP_TRIGGERS_TO_BUTTONS option should apply. There are some similar devices in the existing device table where this flag is not set, but I did refrain from changing those. [0] https://github.com/xboxdrv/xboxdrv/blob/stable/src/xpad_device.cpp [1] http://codepad.org/CHV98BNH [2] https://www.google.com/search?q=SFxT+Fightstick+Pro&tbm=ischSigned-off-by:
-
Benjamin Valentin authored
[ Upstream commit 873cb582 ] Some entries in the table of supported devices are out of order. To not create a mess when adding new ones using a script, sort them first. Signed-off-by:
-
Cameron Gutman authored
[ Upstream commit 81093c98 ] There are several quirky Xbox One pads that depend on initialization packets that the Microsoft pads don't require. To deal with these, I've added a mechanism for issuing device-specific initialization packets using a VID/PID-based quirks list. For the initial set of init quirks, I have added quirk handling from Valve's Steam Link xpad driver[0] and the 360Controller project[1] for macOS to enable some new pads to work properly. This should enable full functionality on the following quirky pads: 0x0e6f:0x0165 - Titanfall 2 gamepad (previously fully non-functional) 0x0f0d:0x0067 - Hori Horipad (analog sticks previously non-functional) 0x24c6:0x541a - PowerA Xbox One pad (previously fully non-functional) 0x24c6:0x542a - PowerA Xbox One pad (previously fully non-functional) 0x24c6:0x543a - PowerA Xbox One pad (previously fully non-functional) [0]: https://github.com/ValveSoftware/steamlink-sdk/blob/master/kernel/drivers/input/joystick/xpad.c [1]: https://github.com/360Controller/360ControllerSigned-off-by:
-
Cameron Gutman authored
[ Upstream commit a1fbf5bb ] Set the LED_CORE_SUSPENDRESUME flag on our LED device so the LED state will be automatically restored by LED core on resume. Since Xbox One pads stop flashing only when reinitialized, we'll send them the initialization packet so they calm down too. Signed-off-by:
-
Cameron Gutman authored
[ Upstream commit 57b8443d ] The Xbox One S requires an ack to its mode button report, otherwise it continuously retransmits the report. This makes the mode button appear to be stuck down after it is pressed for the first time. Signed-off-by:
-
Cameron Gutman authored
[ Upstream commit c01b5e74 ] The order of endpoints is well defined on official Xbox pads, but we have found at least one 3rd-party pad that doesn't follow the standard ("Titanfall 2 Xbox One controller" 0e6f:0165). Fortunately, we get lucky with this specific pad because it uses endpoint addresses that differ only by direction. We know that there are other pads out where this is not true, so let's go ahead and fix this. Signed-off-by:
-
Pavel Rojtberg authored
[ Upstream commit a8c34e27 ] Replace first goto with simple returns as we really are just returning one error code. Signed-off-by:
Pavel Rojtberg <rojtberg@gmail.com> Signed-off-by:
-
Daniel Tobias authored
[ Upstream commit 4f88476c ] xbox one was the only device that has a *_process_buttons routine. Signed-off-by:
-
Daniel Tobias authored
[ Upstream commit c02fc1d9 ] Signed-off-by:
Daniel Tobias <dan.g.tob@gmail.com> Signed-off-by:
-
Cameron Gutman authored
[ Upstream commit ae3b4469 ] Unlike previous Xbox pads, the Xbox One pad doesn't have "sticky" rumble packets. The duration is encoded into the command and expiration is handled by the pad firmware. ff-memless needs pseudo-sticky behavior for rumble effects to behave properly for long duration effects. We already specify the maximum rumble on duration in the command packets, but it's still only good for about 2.5 seconds of rumble. This is easily reproducible running fftest's sine vibration test. It turns out there's a repeat count encoded in the rumble command. We can abuse that to get the pseudo-sticky behavior needed for rumble to behave as expected for effects with long duration. By my math, this change should allow a single ff_effect to rumble for 10 minutes straight, which should be more than enough for most needs. Signed-off-by:
-
Cameron Gutman authored
[ Upstream commit 599b8c09 ] This is the new gamepad that ships with the Xbox One S which includes Bluetooth functionality. Signed-off-by:
-
Vasanthakumar Thiagarajan authored
commit ebaa4b16 upstream. arvifs list is traversed within data_lock spin_lock in tasklet context to fill channel information from the corresponding vif. This means any access to arvifs list for add/del operations should also be protected with the same spin_lock to avoid the race. Fix this by performing list add/del on arvfis within the data_lock. This could fix kernel panic something like the below. LR is at ath10k_htt_rx_pktlog_completion_handler+0x100/0xb6c [ath10k_core] PC is at ath10k_htt_rx_pktlog_completion_handler+0x1c0/0xb6c [ath10k_core] Internal error: Oops: 17 [#1] PREEMPT SMP ARM [<bf4857f4>] (ath10k_htt_rx_pktlog_completion_handler+0x2f4/0xb6c [ath10k_core]) [<bf487540>] (ath10k_htt_txrx_compl_task+0x8b4/0x1188 [ath10k_core]) [<c00312d4>] (tasklet_action+0x8c/0xec) [<c00309a8>] (__do_softirq+0xdc/0x208) [<c0030d6c>] (irq_exit+0x84/0xe0) [<c005db04>] (__handle_domain_irq+0x80/0xa0) [<c00085c4>] (gic_handle_irq+0x38/0x5c) [<c0009640>] (__irq_svc+0x40/0x74) (gdb) list *(ath10k_htt_rx_pktlog_completion_handler+0x1c0) 0x136c0 is in ath10k_htt_rx_h_channel (drivers/net/wireless/ath/ath10k/htt_rx.c:769) 764 struct cfg80211_chan_def def; 765 766 lockdep_assert_held(&ar->data_lock); 767 768 list_for_each_entry(arvif, &ar->arvifs, list) { 769 if (arvif->vdev_id == vdev_id && 770 ath10k_mac_vif_chan(arvif->vif, &def) == 0) 771 return def.chan; 772 } 773 Signed-off-by:
Vasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com> Signed-off-by:
Kalle Valo <kvalo@qca.qualcomm.com> Signed-off-by:
-
Greg Hackmann authored
(commit 1a381d4a upstream) Linking the ARM64 defconfig kernel with LLVM lld fails with the error: ld.lld: error: unknown argument: -p Makefile:1015: recipe for target 'vmlinux' failed Without this flag, the ARM64 defconfig kernel successfully links with lld and boots on Dragonboard 410c. After digging through binutils source and changelogs, it turns out that -p is only relevant to ancient binutils installations targeting 32-bit ARM. binutils accepts -p for AArch64 too, but it's always been undocumented and silently ignored. A comment in ld/emultempl/aarch64elf.em explains that it's "Only here for backwards compatibility". Since this flag is a no-op on ARM64, we can safely drop it. Acked-by:
Will Deacon <will.deacon@arm.com> Reviewed-by:
Nick Desaulniers <ndesaulniers@google.com> Signed-off-by:
Greg Hackmann <ghackmann@google.com> Signed-off-by:
Catalin Marinas <catalin.marinas@arm.com> Signed-off-by:
-
