On certain QTI chipsets some GPIOs are direct-connect interrupts to the
GIC to be used as regular interrupt lines. When the GPIOs are not used
for interrupt generation the interrupt line is disabled. But disabling
the interrupt at GIC does not prevent the interrupt to be reported as
pending at GIC_ISPEND. Later, when drivers call enable_irq() on the
interrupt, an unwanted interrupt occurs.
Introduce get and set methods for irqchip's parent to clear it's pending
irq state. This then can be invoked by the GPIO interrupt controller on
the parents in it hierarchy to clear the interrupt before enabling the
interrupt.
Signed-off-by: Maulik Shah <mkshah@codeaurora.org>
[updated commit text and minor code fixes]
Signed-off-by: Lina Iyer <ilina@codeaurora.org>
BUG: 141169320
TEST: Build and boot
Change-Id: I8c849f89bebca892fc8a5c94f1ca9492f2a9d49c
Signed-off-by: Maulik Shah <mkshah@codeaurora.org>
Link: https://patchwork.kernel.org/patch/11145351
GPIOs that can be configured as wakeup are routed to the PDC wakeup
interrupt controller and from there to the GIC interrupt controller. On
some QCOM SoCs, the interface to the GIC for wakeup capable GPIOs have
additional hardware registers that need to be configured as well to
match the trigger type of the GPIO. This register interfaces the PDC to
the GIC and therefore updated from the PDC driver.
Typically, the firmware intializes the interface registers for the
wakeup capable GPIOs with commonly used GPIO trigger type, but it is
possible that a platform may want to use the GPIO differently. So, in
addition to configuring the PDC, configure the interface registers as
well.
Signed-off-by: Lina Iyer <ilina@codeaurora.org>
BUG: 141169320
TEST: Build and boot
Change-Id: I73250a04f67549dbf75c40b3672b6b1b78ff8adb
Signed-off-by: Maulik Shah <mkshah@codeaurora.org>
Link: https://patchwork.kernel.org/patch/11145353
In addition to configuring the PDC, additional registers that interface
the GIC have to be configured to match the GPIO type. The registers on
some QCOM SoCs are access restricted, while on other SoCs are not. They
SoCs with access restriction to these SPI registers need to be written
from the firmware using the SCM interface. Add a flag to indicate if the
register is to be written using SCM interface.
Cc: devicetree@vger.kernel.org
Signed-off-by: Lina Iyer <ilina@codeaurora.org>
Reviewed-by: Rob Herring <robh@kernel.org>
BUG: 141169320
TEST: Build and boot
Change-Id: I0f6dfc11fc4df4b0744b7c9372eaf4c7be3a82d6
Signed-off-by: Maulik Shah <mkshah@codeaurora.org>
Link: https://patchwork.kernel.org/patch/11145355
Introduce a new domain for wakeup capable GPIOs. The domain can be
requested using the bus token DOMAIN_BUS_WAKEUP. In the following
patches, we will specify PDC as the wakeup-parent for the TLMM GPIO
irqchip. Requesting a wakeup GPIO will setup the GPIO and the
corresponding PDC interrupt as its parent.
Co-developed-by: Stephen Boyd <swboyd@chromium.org>
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
Signed-off-by: Lina Iyer <ilina@codeaurora.org>
BUG: 141169320
TEST: Build and boot
Change-Id: Iaec0f39c86776d3f8cebe869c4ccaaba541c7ad5
Signed-off-by: Maulik Shah <mkshah@codeaurora.org>
Link: https://patchwork.kernel.org/patch/11145357
When an interrupt is to be serviced, the convention is to mask the
interrupt at the chip and unmask after servicing the interrupt. Enabling
and disabling the interrupt at the PDC irqchip causes an interrupt storm
due to the way dual edge interrupts are handled in hardware.
Skip configuring the PDC when the IRQ is masked and unmasked, instead
use the irq_enable/irq_disable callbacks to toggle the IRQ_ENABLE
register at the PDC. The PDC's IRQ_ENABLE register is only used during
the monitoring mode when the system is asleep and is not needed for
active mode detection.
Signed-off-by: Lina Iyer <ilina@codeaurora.org>
BUG: 141169320
TEST: Build and boot
Change-Id: Ia5827a509bfb47aaa18ed0ea8f61c74f643fa91f
Signed-off-by: Maulik Shah <mkshah@codeaurora.org>
Link: https://patchwork.kernel.org/patch/11145361
Newer SoCs have increased the number of interrupts routed to the PDC
interrupt controller. Update the definition of max PDC interrupts.
Signed-off-by: Lina Iyer <ilina@codeaurora.org>
BUG: 141169320
TEST: Build and boot
Change-Id: I97f548fcd42a5fef63b8f8cbea9470e83f5e8e3e
Signed-off-by: Maulik Shah <mkshah@codeaurora.org>
Link: https://patchwork.kernel.org/patch/11145363
A single controller can handle normal interrupts and wake-up interrupts
independently, with a different numbering space. It is thus crucial to
allow the driver for such a controller discriminate between the two.
A simple way to do so is to tag the wake-up irqdomain with a "bus token"
that indicates the wake-up domain. This slightly abuses the notion of
bus, but also radically simplifies the design of such a driver. Between
two evils, we choose the least damaging.
Suggested-by: Stephen Boyd <swboyd@chromium.org>
Signed-off-by: Lina Iyer <ilina@codeaurora.org>
BUG: 141169320
TEST: Build and boot
Change-Id: I0fd6ccc288d1aa840d88392e5f57197c1e8d1afb
Signed-off-by: Maulik Shah <mkshah@codeaurora.org>
Link: https://patchwork.kernel.org/patch/11145365
This is only valid in repo checkouts and caused issues when rebasing on
top. Hence drop it for now until a better solution can be found.
Change-Id: If06560c131a57f2e6d82966f9adf3ca628b2468a
Signed-off-by: Matthias Maennich <maennich@google.com>
Use the fscrypt key removal notifier chain to make sdcardfs evict its
dentries when an fscrypt key is about to be removed. This is needed for
the FS_IOC_REMOVE_ENCRYPTION_KEY ioctl to properly "lock" the encrypted
files underneath sdcardfs when an Android user is stopped.
Test: pm create-user 10
am start-user 10
find /data/media/10/ # filenames are in plaintext form
am stop-user 10
find /data/media/10/ # filenames are in ciphertext form
(But currently the kernel and vold still warn about other files
still being open, due to b/140762419)
Bug: 120446149
Bug: 142275883
Change-Id: I83b451a2bc40c72fcd01d24aa5c34ad8de427534
Signed-off-by: Eric Biggers <ebiggers@google.com>
Add a notifier chain so that sdcardfs can evict its dentries when an
fscrypt key is about to be removed. This is needed for the
FS_IOC_REMOVE_ENCRYPTION_KEY ioctl to properly "lock" the encrypted
files underneath sdcardfs when an Android user is stopped.
This is meant to be a temporary patch carried as part of the sdcardfs
patchset until either we stop using sdcardfs, we get sdcardfs upstream,
or we find a way to provide what sdcardfs needs while also benefitting a
user upstream.
Bug: 120446149
Bug: 142275883
Test: see I83b451a2bc40c72fcd01d24aa5c34ad8de427534
Change-Id: Iec79775a71057d05a371d77da4a6541cb8e09cb7
Signed-off-by: Eric Biggers <ebiggers@google.com>
It causes BUG because remove_proc_entry may sleep while holding spinlock.
BUG: scheduling while atomic: ip6tables-resto/887/0x00000202
[<c0f03f00>] (wait_for_completion) from [<c031b8c8>] (proc_entry_rundown+0x74/0xd0)
[<c031b854>] (proc_entry_rundown) from [<c03225c4>] (remove_proc_entry+0xc0/0x18c)
[<c0322504>] (remove_proc_entry) from [<c0d656e0>] (quota_mt2_destroy+0x88/0xa8)
[<c0d65658>] (quota_mt2_destroy) from [<c0e405f0>] (cleanup_entry+0x6c/0xf0)
[<c0e40584>] (cleanup_entry) from [<c0e41400>] (do_replace.constprop.2+0x314/0x438)
[<c0e410ec>] (do_replace.constprop.2) from [<c0e41640>] (do_ip6t_set_ctl+0x11c/0x238)
[<c0e41524>] (do_ip6t_set_ctl) from [<c0d2e7ec>] (nf_setsockopt+0xd4/0xf0)
[<c0d2e718>] (nf_setsockopt) from [<c0e16bb8>] (ipv6_setsockopt+0x90/0xb8)
[<c0e16b28>] (ipv6_setsockopt) from [<c0e1e908>] (rawv6_setsockopt+0x54/0x22c)
[<c0e1e8b4>] (rawv6_setsockopt) from [<c0cb48dc>] (sock_common_setsockopt+0x28/0x30)
[<c0cb48b4>] (sock_common_setsockopt) from [<c0cb3ac8>] (SyS_setsockopt+0xb8/0x110)
[<c0cb3a10>] (SyS_setsockopt) from [<c01094e0>] (ret_fast_syscall+0x0/0x48)
This is a fix for an Android specific feature which was imported
from unofficial upstream (xtables-addons), which also has the same issue:
https://sourceforge.net/p/xtables-addons/xtables-addons/ci/master/tree/extensions/xt_quota2.c#l235
After this change the proc entry may now be removed later, when we're already
adding another one, potentially with the same name, this will simply
fail during creation, see error path for this at:
https://sourceforge.net/p/xtables-addons/xtables-addons/ci/master/tree/extensions/xt_quota2.c#l179
Bug: 143092160
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Signed-off-by: DongJoo Kim <micomx@gmail.com>
Change-Id: I3ff3883738353785f5792c5f06bf6b72985c4c68
SND_PCM_ELD is used by DRM drivers for HDMI audio,
so add it to the HIDDEN_DRM configs.
Bug: 142268770
Change-Id: I914beef34b2cf5174da76a5d1a4d443117f1b687
Signed-off-by: John Stultz <john.stultz@linaro.org>
Re-add "x86/uaccess: Dont leak the AC flag into __put_user() argument evaluation"
This reverts commit 2c7164851e.
Bug: 120440614
Bug: 132629930
Signed-off-by: Ram Muthiah <rammuthiah@google.com>
Change-Id: I74ea8dcb2f5c3661dc1657eb53872375aa9e6753
Re-add "x86/uaccess: Don't leak the AC flag into __put_user() value evaluation"
This reverts commit a4bd9e975e.
Bug: 120440614
Bug: 132629930
Signed-off-by: Ram Muthiah <rammuthiah@google.com>
Change-Id: Iebfe5df8e2e09b6eeeaae343ec6deeda7f45c975
This reverts commit e070355664, reversing
changes made to 8808cf8cbc.
Introducing symbol-namespaces into the kernel has caused issues with
respect to the ABI checker. Hence, revert the changes until a valid
fix is available. The revert was done based off of 5.4-rc1.
Change-Id: I529ced269661f457ce667a76eb383843002f0a7d
Signed-off-by: Raghavendra Rao Ananta <rananta@codeaurora.org>
Add support for parsing iommus DT property to create device links
between IOMMU suppliers and their consumers.
Bug: 140290589
Signed-off-by: Saravana Kannan <saravanak@google.com>
Change-Id: I7aa1b4315010fa5f3dc49c0903d164478ecdd1a7
Filter out all modifications to arch/*/configs/*cuttlefish_defconfig and
build.config.cuttlefish.*. They got deleted eventually. No need to
maintain them in the series any longer.
Change-Id: I288ddab3482f8e23e3745d0e8972612a1a413f47
Signed-off-by: Matthias Maennich <maennich@google.com>
up to 06dc94f19d ("ANDROID: sched: Honor sync flag for energy-aware wakeups")
Change-Id: Ic808532ca712428d0716b9fd6cc5fd168d9d0db1
Signed-off-by: Matthias Maennich <maennich@google.com>
Since we don't do energy-aware wakeups when we are overutilized, always
honoring sync wakeups in this state does not prevent wake-wide mechanics
overruling the flag as normal.
Having the check for (cpu_rq(cpu)->nr_running == 1) in the test condition
means that we only bypass the energy model for sync wakeups where the
cpu is about to become idle. This matches the use of this flag in Binder
which is the main place where sync wakeups come from in Android.
This patch is based upon previous work to build EAS for android products.
It replaces
commit 79e3a4a27e ("ANDROID: sched: Unconditionally honor sync flag
for energy-aware wakeups")
in what's considered to be 'EAS'.
sync-hint code taken from wahoo
https://android.googlesource.com/kernel/msm/+/4a5e890ec60d
written by Juri Lelli <juri.lelli@arm.com>
Change-Id: I4b3d79141fc8e53dc51cd63ac11096c2e3cb10f5
Signed-off-by: Chris Redpath <chris.redpath@arm.com>
(cherry-picked from commit f1ec666a62de)
[ Moved the feature to find_energy_efficient_cpu() and removed the
sysctl knob ]
Signed-off-by: Quentin Perret <quentin.perret@arm.com>
[ Add 'cpu_rq(cpu)->nr_running == 1' to the condition and remove the
word 'Unconditionally' from the patch name ]
Signed-off-by: Dietmar Eggemann <dietmar.eggemann@arm.com>
These modules are not required for GKI.
Bug: 139431025
Signed-off-by: Ram Muthiah <rammuthiah@google.com>
Change-Id: I9a82010eb326b0a336725037e0356a63a0c9f053
The generic kernel image must have module signing disabled so it can
load kernel modules from all vendors. Unfortunately loading a signed
kernel module into a kernel with module signing disabled will fail
because struct module_layout (which appears in kernel modules) contains
struct module, and struct module contains the sig_ok field, which is
conditionally compiled depending on CONFIG_MODULE_SIG (module signing).
Unconditionally compile the sig_ok field to work around this problem.
Bug: 135940219
Test: load a signed kernel module with module signing disabled
Change-Id: I5cc437c806f74f89c0e45ce4135136ca0c70738e
Signed-off-by: Steve Muckle <smuckle@google.com>
Programmatically regenerate the quilt series for consistency.
Also, this programmatically cleans up the patches as they are freshly
extracted from git and committed without any further modification.
Change-Id: I7e972756b002b6b9966bf0c8a0f3d7a58117206e
Signed-off-by: Matthias Maennich <maennich@google.com>
Soc framework exposed sysfs entries are not sufficient for some
of the h/w platforms. Currently there is no interface where soc
drivers can expose further information about their SoCs via soc
framework. This change address this limitation where clients can
pass their custom entries as attribute group and soc framework
would expose them as sysfs properties.
Bug: 141190076
Signed-off-by: Murali Nalajala <mnalajal@codeaurora.org>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Link: https://lore.kernel.org/r/1570480662-25252-1-git-send-email-mnalajal@codeaurora.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry-picked from c31e73121f)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Ia1c8d697e29052b4503da7c4b30c2c97d3b697f7
fs-verity will be used for APK verification in R.
Bug: 142494008
Change-Id: Ia18eb35fcdbccabab47de5fb26daba455fc1eb77
Signed-off-by: Eric Biggers <ebiggers@google.com>
There are scenarios where a rate change could result in a configuration
change for both the targeted clock and its parent.
For example, setting the rate for a clock could require both slewing its parent
PLL as well as adjusting the clock's divider values. Due to the fact that
rate change propagation always occurs from parent to child, we could exceed
the allowed operating frequencies for the clock as the parent slews to a higher
frequency before increasing the downstream divider.
Add a pre change call back which allows the clock to adjust its divider
appropriately before any rate change has occurred from its parents to ensure
that the clock's requirements are always within safe frequencies during parent
rate changes. The symmetrical post change call back handles the scenario where
the divider adjusts to a lower value and can only be safely adjusted after the
parent rate changes.
Change-Id: I4f8cf9df6fc256d065599de86a34cf99eae4d853
Signed-off-by: David Dai <daidavid1@codeaurora.org>
Pull tracing fixes from Steven Rostedt:
"A few tracing fixes:
- Remove lockdown from tracefs itself and moved it to the trace
directory. Have the open functions there do the lockdown checks.
- Fix a few races with opening an instance file and the instance
being deleted (Discovered during the lockdown updates). Kept
separate from the clean up code such that they can be backported to
stable easier.
- Clean up and consolidated the checks done when opening a trace
file, as there were multiple checks that need to be done, and it
did not make sense having them done in each open instance.
- Fix a regression in the record mcount code.
- Small hw_lat detector tracer fixes.
- A trace_pipe read fix due to not initializing trace_seq"
* tag 'trace-v5.4-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace:
tracing: Initialize iter->seq after zeroing in tracing_read_pipe()
tracing/hwlat: Don't ignore outer-loop duration when calculating max_latency
tracing/hwlat: Report total time spent in all NMIs during the sample
recordmcount: Fix nop_mcount() function
tracing: Do not create tracefs files if tracefs lockdown is in effect
tracing: Add locked_down checks to the open calls of files created for tracefs
tracing: Add tracing_check_open_get_tr()
tracing: Have trace events system open call tracing_open_generic_tr()
tracing: Get trace_array reference for available_tracers files
ftrace: Get a reference counter for the trace_array on filter files
tracefs: Revert ccbd54ff54 ("tracefs: Restrict tracefs when the kernel is locked down")
Pull hwmon fixes from Guenter Roeck:
- Update/fix inspur-ipsps1 and k10temp Documentation
- Fix nct7904 driver
- Fix HWMON_P_MIN_ALARM mask in hwmon core
* tag 'hwmon-for-v5.4-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging:
hwmon: docs: Extend inspur-ipsps1 title underline
hwmon: (nct7904) Add array fan_alarm and vsen_alarm to store the alarms in nct7904_data struct.
docs: hwmon: Include 'inspur-ipsps1.rst' into docs
hwmon: Fix HWMON_P_MIN_ALARM mask
hwmon: (k10temp) Update documentation and add temp2_input info
hwmon: (nct7904) Fix the incorrect value of vsen_mask in nct7904_data struct
Pull MTD fixes from Richard Weinberger:
"Two fixes for MTD:
- spi-nor: Fix for a regression in write_sr()
- rawnand: Regression fix for the au1550nd driver"
* tag 'fixes-for-5.4-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux:
mtd: rawnand: au1550nd: Fix au_read_buf16() prototype
mtd: spi-nor: Fix direction of the write_sr() transfer
Pull io_uring fix from Jens Axboe:
"Single small fix for a regression in the sequence logic for linked
commands"
* tag 'for-linus-20191012' of git://git.kernel.dk/linux-block:
io_uring: fix sequence logic for timeout requests
A customer reported the following softlockup:
[899688.160002] NMI watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [test.sh:16464]
[899688.160002] CPU: 0 PID: 16464 Comm: test.sh Not tainted 4.12.14-6.23-azure #1 SLE12-SP4
[899688.160002] RIP: 0010:up_write+0x1a/0x30
[899688.160002] Kernel panic - not syncing: softlockup: hung tasks
[899688.160002] RIP: 0010:up_write+0x1a/0x30
[899688.160002] RSP: 0018:ffffa86784d4fde8 EFLAGS: 00000257 ORIG_RAX: ffffffffffffff12
[899688.160002] RAX: ffffffff970fea00 RBX: 0000000000000001 RCX: 0000000000000000
[899688.160002] RDX: ffffffff00000001 RSI: 0000000000000080 RDI: ffffffff970fea00
[899688.160002] RBP: ffffffffffffffff R08: ffffffffffffffff R09: 0000000000000000
[899688.160002] R10: 0000000000000000 R11: 0000000000000000 R12: ffff8b59014720d8
[899688.160002] R13: ffff8b59014720c0 R14: ffff8b5901471090 R15: ffff8b5901470000
[899688.160002] tracing_read_pipe+0x336/0x3c0
[899688.160002] __vfs_read+0x26/0x140
[899688.160002] vfs_read+0x87/0x130
[899688.160002] SyS_read+0x42/0x90
[899688.160002] do_syscall_64+0x74/0x160
It caught the process in the middle of trace_access_unlock(). There is
no loop. So, it must be looping in the caller tracing_read_pipe()
via the "waitagain" label.
Crashdump analyze uncovered that iter->seq was completely zeroed
at this point, including iter->seq.seq.size. It means that
print_trace_line() was never able to print anything and
there was no forward progress.
The culprit seems to be in the code:
/* reset all but tr, trace, and overruns */
memset(&iter->seq, 0,
sizeof(struct trace_iterator) -
offsetof(struct trace_iterator, seq));
It was added by the commit 53d0aa7730 ("ftrace:
add logic to record overruns"). It was v2.6.27-rc1.
It was the time when iter->seq looked like:
struct trace_seq {
unsigned char buffer[PAGE_SIZE];
unsigned int len;
};
There was no "size" variable and zeroing was perfectly fine.
The solution is to reinitialize the structure after or without
zeroing.
Link: http://lkml.kernel.org/r/20191011142134.11997-1-pmladek@suse.com
Signed-off-by: Petr Mladek <pmladek@suse.com>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
nmi_total_ts is supposed to record the total time spent in *all* NMIs
that occur on the given CPU during the (active portion of the)
sampling window. However, the code seems to be overwriting this
variable for each NMI, thereby only recording the time spent in the
most recent NMI. Fix it by accumulating the duration instead.
Link: http://lkml.kernel.org/r/157073343544.17189.13911783866738671133.stgit@srivatsa-ubuntu
Fixes: 7b2c862501 ("tracing: Add NMI tracing in hwlat detector")
Cc: stable@vger.kernel.org
Signed-off-by: Srivatsa S. Bhat (VMware) <srivatsa@csail.mit.edu>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
The removal of the longjmp code in recordmcount.c mistakenly made the return
of make_nop() being negative an exit of nop_mcount(). It should not exit the
routine, but instead just not process that part of the code. By exiting with
an error code, it would cause the update of recordmcount to fail some files
which would fail the build if ftrace function tracing was enabled.
Link: http://lkml.kernel.org/r/20191009110538.5909fec6@gandalf.local.home
Reported-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Tested-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Fixes: 3f1df12019 ("recordmcount: Rewrite error/success handling")
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
