Revision 3dea30ca5bef0e013abe857057a952a9d6757fe5 authored by Vineet Gupta on 19 February 2016, 02:27:41 UTC, committed by Vineet Gupta on 24 February 2016, 05:37:31 UTC
ARConnect/MCIP IPI sending has a retry-wait loop in case caller had not seen a previous such interrupt. Turns out that it is not needed at all. Linux cross core calling allows coalescing multiple IPIs to same receiver - it is fine as long as there is one. This logic is built into upper layer already, at a higher level of abstraction. ipi_send_msg_one() sets the actual msg payload, but it only calls MCIP IPI sending if msg holder was empty (using atomic-set-new-and-get-old construct). Thus it is unlikely that the retry-wait looping was ever getting exercised at all. Cc: Chuck Jordan <cjordan@synopsys.com> Cc: Peter Zijlstra <peterz@infradead.org> Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
1 parent 9681787
| File | Mode | Size |
|---|---|---|
| apparmor | ||
| integrity | ||
| keys | ||
| selinux | ||
| smack | ||
| tomoyo | ||
| yama | ||
| Kconfig | -rw-r--r-- | 5.6 KB |
| Makefile | -rw-r--r-- | 900 bytes |
| commoncap.c | -rw-r--r-- | 31.3 KB |
| device_cgroup.c | -rw-r--r-- | 21.0 KB |
| inode.c | -rw-r--r-- | 6.5 KB |
| lsm_audit.c | -rw-r--r-- | 9.9 KB |
| min_addr.c | -rw-r--r-- | 1.3 KB |
| security.c | -rw-r--r-- | 53.3 KB |
Computing file changes ...
