This patch provides guarantee to the sysadmin that when TFA is disabled, no PMU
event is using PMC3 when the echo command returns. Vice-Versa, when TFA
is enabled, PMU can use PMC3 immediately (to eliminate possible multiplexing).
$ perf stat -a -I 1000 --no-merge -e
This patch add perf_ctx_resched() a global function that can be called
to force rescheduling of events based on event types. The function locks
both cpuctx and task_ctx internally. This will be used by a subsequent patch.
Signed-off-by: Stephane Eranian
Change-Id:
This short patch series improves the TFA patch series by adding a
guarantee to users each time the allow_force_tsx_abort (TFA) sysctl
control knob is modified.
The current TFA support in perf_events operates as follow:
- TFA=1
The PMU has priority over TSX, if PMC3 is needed, then TSX
On Mon, 8 Apr 2019, Konstantin Khlebnikov wrote:
>
> I suppose your solution will wait for wakeup from shmem_evict_inode()?
No, it's the other way round: shmem_unuse() gets on with its work without
delay, shmem_evict_inode() waits until the stop_eviction count has gone
down to zero, saying
- On Apr 8, 2019, at 1:10 PM, paulmck paul...@linux.ibm.com wrote:
> On Mon, Apr 08, 2019 at 01:06:56PM -0400, Mathieu Desnoyers wrote:
>> - On Apr 8, 2019, at 11:21 AM, paulmck paul...@linux.ibm.com wrote:
>>
>> > On Mon, Apr 08, 2019 at 10:57:50PM +0800, Rong Chen wrote:
>> >> On Mon,
On Mon, Apr 8, 2019 at 9:58 AM John Johansen
wrote:
> > +/* Can only be set before AppArmor is initialized (i.e. on boot cmdline).
> > */
> > +static int param_set_aaintbool(const char *val, const struct kernel_param
> > *kp)
> > +{
> > + struct kernel_param kp_local;
> > + bool value;
Hi,
On Thu, 21 Feb 2019 21:25:06 +0100
Anatolij Gustschin ag...@denx.de wrote:
...
> .../ABI/testing/sysfs-driver-ftdi-fifo-fpp| 7 +
> drivers/fpga/Kconfig | 7 +
> drivers/fpga/Makefile | 1 +
> drivers/fpga/ftdi-fifo-fpp.c
On Mon, Apr 08, 2019 at 05:51:27PM +0800, Chris Chiu wrote:
> The touchpad of the ASUS laptops E403NA, X540NA, X541NA are not
> responsive after suspend/resume. The following error message
> shows after resume.
> i2c_hid i2c-ELAN1200:00: failed to reset device.
>
> On these laptops, the touchpad
On Fri, Mar 29, 2019 at 02:46:12PM +0800, Andrew-sh Cheng wrote:
> This adds a devfreq driver for the Cache Coherent Interconnect (CCI)
> of the Mediatek MT8183.
>
> On the MT8183 the CCI is supplied by the same regulator as the LITTLE
> cores. The driver is notified when the regulator voltage
On Mon, Apr 08, 2019 at 11:31:31AM +1000, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the audit tree got conflicts in:
>
> arch/mips/kernel/ptrace.c
> kernel/seccomp.c
>
> between commit:
>
> b35f549df1d7 ("syscalls: Remove start and number from
>
Hi Nava,
On Tue, Apr 02, 2019 at 06:01:21PM +0530, Nava kishore Manne wrote:
> This Patch Adds fpga API's to support the Bitstream loading
> by using firmware interface.
>
> Signed-off-by: Nava kishore Manne
> ---
> Changes for v4:
> -None.
>
> Chnages for v3:
>
This fixes the various compiler warnings when building the msgque
selftest. The primary change is using sys/msg.h instead of linux/msg.h
directly to gain the API declarations.
Fixes: 3a665531a3b7 ("selftests: IPC message queue copy feature test")
Signed-off-by: Kees Cook
---
On Mon, Apr 08, 2019 at 01:06:56PM -0400, Mathieu Desnoyers wrote:
> - On Apr 8, 2019, at 11:21 AM, paulmck paul...@linux.ibm.com wrote:
>
> > On Mon, Apr 08, 2019 at 10:57:50PM +0800, Rong Chen wrote:
> >> On Mon, Apr 08, 2019 at 07:30:37AM -0700, Paul E. McKenney wrote:
> >> > On Mon, Apr
Hi,
I'm seeing the Oops below when trying to boot 5.1.0-rc4 on an ARM PXA3xx
platform. v5.0 did not show this effect with the same cmdline.
Relevant bits from the config are:
CONFIG_NFS_FS=y
CONFIG_NFS_V2=y
CONFIG_NFS_V3=y
# CONFIG_NFS_V3_ACL is not set
# CONFIG_NFS_V4 is not set
#
On Wed, 3 Apr 2019, Sebastian Andrzej Siewior wrote:
> This is a refurbished series originally started by by Rik van Riel. The
> goal is load the FPU registers on return to userland and not on every
> context switch. By this optimisation we can:
> - avoid loading the registers if the task stays
On Fri, Apr 5, 2019 at 11:36 PM Rajat Jain wrote:
>
> Add code to instantiate the pmc_core platform device and thus attach to
> the driver, if the ACPI device for the same ("INT33A1") is not present
> in a system where it should be. This was discussed here:
>
- On Apr 8, 2019, at 11:21 AM, paulmck paul...@linux.ibm.com wrote:
> On Mon, Apr 08, 2019 at 10:57:50PM +0800, Rong Chen wrote:
>> On Mon, Apr 08, 2019 at 07:30:37AM -0700, Paul E. McKenney wrote:
>> > On Mon, Apr 08, 2019 at 09:56:10PM +0800, kernel test robot wrote:
>> > > FYI, we noticed
On Wed, 3 Apr 2019, Sebastian Andrzej Siewior wrote:
> The previous commits refactor the restoration of the FPU registers so
> that they can be loaded from in-kernel memory. This overhead can be
> avoided if the load can be performed without a pagefault.
>
> Attempt to restore FPU registers by
On 4/8/19 12:12 PM, Gustavo A. R. Silva wrote:
> Fix file descriptor leaks by closing fp before return.
>
> Addresses-Coverity-ID: 1444591 ("Resource leak")
> Addresses-Coverity-ID: 1444592 ("Resource leak")
> Fixes: 5ea7647b333f ("tools/power turbostat: Warn on bad ACPI LPIT data")
>
On Fri, Apr 5, 2019 at 11:36 PM Rajat Jain wrote:
>
> Add a module parameter which when enabled, will check on resume, if the
> last S0ix attempt was successful. If not, the driver would warn and provide
> helpful debug information (which gets latched during the failed suspend
> attempt) to debug
Quoting Matti Vaittinen (2019-04-08 03:49:41)
> On Fri, Apr 05, 2019 at 01:37:24PM -0700, Stephen Boyd wrote:
> > Quoting Vaittinen, Matti (2019-04-04 23:51:43)
> > > On Thu, 2019-04-04 at 14:53 -0700, Stephen Boyd wrote:
> > > > We recently introduced a change to support devm clk lookups. That
>
Currently perf callchain is not working properly with ORC unwinder,
and sampling event from trace point. We'll get useless in kernel
callchain like this:
perf 6429 [000]22.498450: kmem:mm_page_alloc: page=0x176a17
pfn=1534487 order=0 migratetype=0 gfp_flags=GFP_KERNEL
This document misses a title. Add it, in order to follow
the documentation standard.
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/clearing-warn-once.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/clearing-warn-once.txt
b/Documentation/clearing-warn-once.txt
On Mon, Apr 08, 2019 at 04:46:31PM +, Gary R Hook wrote:
> My reasoning (not arguing): the file has been touched exactly one time
> in 4 years, by Thomas. Doesn't appear to be a candidate for constant
> modification, so this approach doesn't seem risky to me. I could be wrong.
The problem,
On 4/8/19 9:07 AM, Kees Cook wrote:
> Before commit c5459b829b71 ("LSM: Plumb visibility into optional "enabled"
> state"), /sys/module/apparmor/parameters/enabled would show "Y" or "N"
> since it was using the "bool" handler. After being changed to "int",
> this switched to "1" or "0", breaking
From: Chen-Yu Tsai
The A83T SoC has a camera sensor interface (known as CSI in Allwinner
lingo), which is similar to the one found on the A64 and H3. The only
difference seems to be that support of MIPI CSI through a connected
MIPI CSI-2 bridge.
Add a device node for it, and pinctrl nodes for
From: Chen-Yu Tsai
The A83T SoC has a camera sensor interface (known as CSI in Allwinner
lingo), which is similar to the one found on the A64 and H3. The only
difference seems to be that support of MIPI CSI through a connected
MIPI CSI-2 bridge.
Add a compatible string for this variant.
From: Chen-Yu Tsai
Hi everyone,
This series adds support for the camera sensor interface controller
found on the Allwinner A83T SoC. The controller is similar to the one
found on the H3, with the addition of a MIPI CSI-2 interface. However,
this series only supports parallel and BT.656
Nit: For future reference, wrapping the warning text with quotes in the
shortlog would be helpful. I initially read it as "fix a warning by
using a plain integer as a NULL pointer". E.g.:
KVM: x86: fix warning "Using plain integer as NULL pointer"
On Sat, Apr 06, 2019 at
On Fri, Apr 5, 2019 at 11:36 PM Rajat Jain wrote:
>
> Convert the intel_pmc_core driver to a platform driver, and attach using
> the ACPI enumeration method (via the ACPI device "INT33A1").
>
> Signed-off-by: Rajat Jain
> -static const struct x86_cpu_id intel_pmc_core_ids[] = {
> -
On 08.04.19 13:16, Morris Ku wrote:
> +> There are 10's of examples available. Please take a look around some
> +> of the existing drivers to see how their functionality is split.
> +
>
> Could you please clearly tell me the name of driver for reference.
drivers/platform/x86/pcengines-apuv2.c
Hi Michal,
On Mon, Apr 08, 2019 at 04:36:15PM +0200, Michal Simek wrote:
> On 08. 04. 19 16:17, Alan Tull wrote:
> > On Mon, Apr 8, 2019 at 7:39 AM Nava kishore Manne wrote:
> >>
> >> Hi Alan,
> >>
> >> Thanks for look into it and providing the ACK.
> >> I got one minor comments from Moritz
Get the reset control for the QSPI controller and bring it out of reset.
Suggested-by: Tien-Fong Chee
Signed-off-by: Dinh Nguyen
---
drivers/mtd/spi-nor/cadence-quadspi.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/mtd/spi-nor/cadence-quadspi.c
* Tony Lindgren [190325 22:00]:
> @@ -200,6 +278,12 @@ static int sysc_get_clocks(struct sysc *ddata)
> if (ddata->nr_clocks < 1)
> return 0;
>
> + if ((ddata->cfg.quirks & SYSC_QUIRK_EXT_OPT_CLOCK)) {
> + error = sysc_init_ext_opt_clock(ddata, NULL);
> +
Hi Florian,
On Sun, Apr 07, 2019 at 02:34:22PM -0700, Florian Fainelli wrote:
> The Cortex-A72 supports all ARMv8 recommended events up to the
> RC_ST_SPEC (0x91) event, create an appropriate JSON file for mapping
> those events and update the mapfile.csv for matching the Cortex-A72 MIDR
> to
On 4/4/19 3:42 PM, Thomas Gleixner wrote:
> On Thu, 4 Apr 2019, Hook, Gary wrote:
>
>> Enablement of AMD's Secure Memory Encryption feature is determined
>> very early in the boot cycle. Part of this procedure involves scanning
>> the command line for the paramater 'mem_encrypt'.
>>
>> To
On Wed, Apr 3, 2019 at 7:46 PM Heikki Krogerus
wrote:
>
> Now that the software nodes support references, and the
> device connection API support parsing fwnode references,
> replacing the old connection descriptions with software node
> references. Relying on device names when matching the
>
On Mon, 8 Apr 2019, Andy Lutomirski wrote:
> On Sun, Apr 7, 2019 at 11:46 PM Thomas Gleixner wrote:
> >
> > On Sun, 7 Apr 2019, Andy Lutomirski wrote:
> > > On Sun, Apr 7, 2019 at 3:44 PM Thomas Gleixner wrote:
> > > > Actually we have: save_stack_trace()
> > > >
> > >
> > > Like I did here:
> >
On Wed, Apr 3, 2019 at 7:46 PM Heikki Krogerus
wrote:
>
> Supplying also external devices - the DisplayPort connector
> and the USB role switch - software fwnodes. After this the
> driver has access to all the components tied to the USB
> Type-C connector and can start creating software node
>
Fix file descriptor leaks by closing fp before return.
Addresses-Coverity-ID: 1444591 ("Resource leak")
Addresses-Coverity-ID: 1444592 ("Resource leak")
Fixes: 5ea7647b333f ("tools/power turbostat: Warn on bad ACPI LPIT data")
Signed-off-by: Gustavo A. R. Silva
---
On Mon, Apr 08, 2019 at 09:18:00AM -0700, Andy Lutomirski wrote:
> On Sun, Apr 7, 2019 at 11:46 PM Thomas Gleixner wrote:
> >
> > On Sun, 7 Apr 2019, Andy Lutomirski wrote:
> > > On Sun, Apr 7, 2019 at 3:44 PM Thomas Gleixner wrote:
> > > > Actually we have: save_stack_trace()
> > > >
> > >
> >
On 06.04.19 02:09, Alexander Duyck wrote:
> So I am starting this thread as a spot to collect my thoughts on the
> current guest free page hinting design as well as point out a few
> possible things we could do to improve upon it.
>
> 1. The current design isn't likely going to scale well to
in the previous case, initrd_start and initrd_end can be successfully
returned either (base < memblock_start_of_DRAM()) or (base + size >
memblock_start_of_DRAM() + linear_region_size).
That means even linear mapping range check fail for initrd_start and
initrd_end, it still can get virtual
The following is schematic diagram of the program before and after the
modification.
Before:
if (memstart_addr + linear_region_size < memblock_end_of_DRAM()) {} --(a)
if (memory_limit != PHYS_ADDR_MAX) {} --(b)
if (IS_ENABLED(CONFIG_BLK_DEV_INITRD) &&
Hi Rob,
the following patch has been pushed in 2016 by commit 51f0aeb2d21f1.
Being able to specify which timer should act as a clocksource or a
clockevent is often requested. Doing this from the driver itself forces
to do some assumption in the timer definition ordering in the DT.
That
On Mon, Apr 08, 2019 at 12:25:17PM -0400, Liang, Kan wrote:
>
> > > @@ -963,40 +963,42 @@ static u64 pebs_update_adaptive_cfg(stru
> > > u64 pebs_data_cfg = 0;
> > > bool gprs, tsx_weight;
> > > - if ((sample_type & ~(PERF_SAMPLE_IP|PERF_SAMPLE_TIME)) ||
> > > -
In case memory resources for *buf* and *paths* were allocated,
jump to *out* and release them before return.
Addresses-Coverity-ID: 1444328 ("Resource leak")
Fixes: 6f3da20e151f ("perf report: Support builtin perf script in scripts menu")
Signed-off-by: Gustavo A. R. Silva
---
hi Will:
>
> Maybe, but I don't think we've seen a patch which accomplishes that. I think
> I'll go ahead and commit the basic one-liner, then we can always improve it
> afterwards if somebody sends a patch. It's not like this is a fastpath.
Sorry for not showing the patches I try to explain to
On Fri, Apr 05, 2019 at 09:50:47AM -0700, Florian Fainelli wrote:
> Broadcom's Brahma-B53 CPUs support the same type of events that the
> Cortex-A53 supports, recognize its CPUID and map it to the cortex-a53
> events.
>
> Signed-off-by: Florian Fainelli
> ---
>
@@ -963,40 +963,42 @@ static u64 pebs_update_adaptive_cfg(stru
u64 pebs_data_cfg = 0;
bool gprs, tsx_weight;
- if ((sample_type & ~(PERF_SAMPLE_IP|PERF_SAMPLE_TIME)) ||
- attr->precise_ip < 2) {
+ if (!(sample_type & ~(PERF_SAMPLE_IP|PERF_SAMPLE_TIME)) &&
+
On Mon, Apr 8, 2019 at 6:31 AM Reshetova, Elena
wrote:
> Originally I was thinking that in-stack randomization makes sense
> only for x86_64, since this is what VMAP stack on x86 depends on.
> Without VMAP stack and guard pages, there are easier ways to attack,
> so hardening there does not
On Sun, Apr 7, 2019 at 11:46 PM Thomas Gleixner wrote:
>
> On Sun, 7 Apr 2019, Andy Lutomirski wrote:
> > On Sun, Apr 7, 2019 at 3:44 PM Thomas Gleixner wrote:
> > > Actually we have: save_stack_trace()
> > >
> >
> > Like I did here:
> >
> >
Hi,
* Masahiro Yamada [190408 07:56]:
> is only generated and included
> by arch/arm/mach-omap2/, so it does not need to reside in the
> globally visible include/generated/.
>
> I moved and renamed it to arch/arm/mach-omap2/pm-asm-offsets.h
> since the prefix 'omap2-' is just redundant in
On Fri, Apr 5, 2019 at 10:55 PM Maxime Ripard wrote:
>
> Hi,
>
> On Fri, Apr 05, 2019 at 06:24:55AM -0400, Yangtao Li wrote:
> > Allwinner Process Voltage Scaling Tables defines the voltage and
> > frequency value based on the speedbin blown in the efuse combination.
> > The sunxi-cpufreq-nvmem
On Wed, Apr 3, 2019 at 7:46 PM Heikki Krogerus
wrote:
>
> In ACPI, and now also in DT, the USB connectors usually have
> their own device nodes. In case of USB Type-C, those
> connector (port) nodes are child nodes of the controller or
> PHY device, in our case the fusb302. The software fwnodes
>
On 4/7/19 10:41 PM, Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20190405:
>
on i386 or x86_64:
modular:
ERROR: "is_stm32_timer_trigger" [drivers/iio/adc/stm32-dfsdm-adc.ko] undefined!
or builtin:
ld: drivers/iio/adc/stm32-dfsdm-adc.o: in function `stm32_dfsdm_postenable':
On Wed, Apr 3, 2019 at 7:46 PM Heikki Krogerus
wrote:
>
> Software nodes provide two features that we will need later.
> 1) Software nodes can have references to other software nodes.
> 2) Software nodes can exist before a device entry is created.
> #include
> #include
> #include
>
On Mon, Apr 8, 2019 at 5:47 AM Daniel Bristot de Oliveira
wrote:
>
> On 4/4/19 2:01 AM, Andy Lutomirski wrote:
> >> To resolve this problem, the set/unset of the IRQ/NMI context needs to
> >> be done before the execution of the first C execution, and after its
> >> return. By doing so, and using
On Mon, Apr 08, 2019 at 04:49:07PM +0100, Marc Zyngier wrote:
> Instead of always going via arch_counter_get_cntvct_stable to
> access the counter workaround, let's have arch_timer_read_counter
> to point to the right method.
Nit: s/to point/point/
> For that, we need to track whether any CPU in
Before commit c5459b829b71 ("LSM: Plumb visibility into optional "enabled"
state"), /sys/module/apparmor/parameters/enabled would show "Y" or "N"
since it was using the "bool" handler. After being changed to "int",
this switched to "1" or "0", breaking the userspace AppArmor detection
of
On 4/8/2019 11:41 AM, Peter Zijlstra wrote:
I currently have something like the below on top, is that correct?
Yes, it's correct.
If so, I'll fold it back in.
Thanks. It's really appreciated.
Kan
--- a/arch/x86/events/core.c
+++ b/arch/x86/events/core.c
@@ -563,16 +563,17 @@ int
On Mon, Apr 08, 2019 at 04:49:06PM +0100, Marc Zyngier wrote:
> The use of a static key in a hotplug path has proved to be a real
> nightmare, and makes it impossible to have scream-free lockdep
> kernel.
>
> Let's remove the static key altogether, and focus on something saner.
>
>
On Fri, Feb 1, 2019 at 9:13 AM Thomas Garnier wrote:
>
> On Thu, Jan 31, 2019 at 6:31 PM Christopher Lameter wrote:
> >
> > On Thu, 31 Jan 2019, Thomas Garnier wrote:
> >
> > > The per-cpu symbols are in a section that is zero based to create
> > > offsets. The compiler doesn't see them as
On Mon, Apr 08, 2019 at 04:49:05PM +0100, Marc Zyngier wrote:
> Let's start with the removal of the arch_timer_read_ool_enabled
> static key in arch_timer_reg_read_stable. IT is not a fast path,
Nit: s/IT/It/
> and we can simplify things a bit.
>
> Signed-off-by: Marc Zyngier
Acked-by: Mark
On Mon, Apr 08, 2019 at 04:49:04PM +0100, Marc Zyngier wrote:
> When a given timer is affected by an erratum and requires an
> alternative implementation of set_next_event, we do a rather
> complicated dance to detect and call the workaround on each
> set_next_event call.
>
> This is clearly
On 08/04/2019 10:07, David Abdurachmanov wrote:
> This is only used on arm and arm64 platforms. Add COMPILE_TEST option.
>
> Tested with 5.1-rc3+ on Fedora/RISCV. CONFIG_ARM_TIMER_SP804 no more shows
> up in riscv config.
>
> Signed-off-by: David Abdurachmanov
Applied for 5.2
Thanks
--
On 2019-04-08 8:45 a.m., Wesley Sheng wrote:
> Joey Zhang (2):
> ntb_hw_switchtec: Remove redundant steps of
> switchtec_ntb_reinit_peer() function
> ntb_hw_switchtec: Fix setup MW with failure bug
>
> Wesley Sheng (1):
> ntb_hw_switchtec: Skip unnecessary re-setup of shared memory
On 2019-04-08 8:34 a.m., Wesley Sheng wrote:
> Wesley Sheng (2):
> switchtec: Fix false maximum supported PCIe function number issue
> switchtec: Fix unintended mask of MRPC event
This series looks good to me:
Reviewed-by: Logan Gunthorpe
Thanks,
Logan
On Mon, Apr 08, 2019 at 04:49:03PM +0100, Marc Zyngier wrote:
> Only arch_timer_read_counter will guarantee that workarounds are
> applied. So let's use this one instead of arch_counter_get_cntvct.
>
> Signed-off-by: Marc Zyngier
Acked-by: Mark Rutland
Mark.
> ---
>
On Mon, Apr 08, 2019 at 04:49:02PM +0100, Marc Zyngier wrote:
> Only arch_timer_read_counter will guarantee that workarounds are
> applied. So let's use this one instead of arch_counter_get_cntvct.
>
> Signed-off-by: Marc Zyngier
Acked-by: Mark Rutland
Mark.
> ---
>
On Mon, Apr 08, 2019 at 04:49:01PM +0100, Marc Zyngier wrote:
> THe VDSO code uses the kernel helper that was originally designed
Nit: s/THe/The/
> to abstract the access between 32 and 64bit systems. It worked so
> far because this function is declared as 'inline'.
>
> As we're about to revamp
Pavel
Thanks for the review
On 4/7/19 5:17 PM, Pavel Machek wrote:
> Hi!
>
>> Changes since v1:
>>
>> - synchronized DT label properties in DT bindings with what has been agreed
>> for the patch "ARM: dts: omap4-droid4: Update backlight dt properties"
>>
>> The following changes since commit
Hi Enrico,
Many thanks to send this upstream.
On 4/4/19 18:00, Jett ✈ Rink wrote:
> Reviewed-by: Jett Rink
>
> On Wed, Apr 3, 2019 at 4:40 PM wrote:
>>
>> From: Enrico Granata
>>
>> As new transfer mechanisms are added to the EC codebase, they may
>> not support v2 of the EC protocol.
>>
>>
Instead of always going via arch_counter_get_cntvct_stable to
access the counter workaround, let's have arch_timer_read_counter
to point to the right method.
For that, we need to track whether any CPU in the system has a
workaround for the counter. This is done by having an atomic
variable
Only arch_timer_read_counter will guarantee that workarounds are
applied. So let's use this one instead of arch_counter_get_cntvct.
Signed-off-by: Marc Zyngier
---
arch/arm64/kernel/traps.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/kernel/traps.c
When a given timer is affected by an erratum and requires an
alternative implementation of set_next_event, we do a rather
complicated dance to detect and call the workaround on each
set_next_event call.
This is clearly idiotic, as we can perfectly detect whether
this CPU requires a workaround
The use of a static key in a hotplug path has proved to be a real
nightmare, and makes it impossible to have scream-free lockdep
kernel.
Let's remove the static key altogether, and focus on something saner.
Signed-off-by: Marc Zyngier
---
arch/arm64/include/asm/arch_timer.h | 4
Let's start with the removal of the arch_timer_read_ool_enabled
static key in arch_timer_reg_read_stable. IT is not a fast path,
and we can simplify things a bit.
Signed-off-by: Marc Zyngier
---
arch/arm64/include/asm/arch_timer.h | 42 +++--
1 file changed, 28
The static key used to deal with the errata workaround that plague a
significant number of arm64 systems (who thought that building a timer
was that hard?) has proved to be a disaster when dealing with
lockdep. We try to activate it in contexts that were never expected,
and things break pretty
THe VDSO code uses the kernel helper that was originally designed
to abstract the access between 32 and 64bit systems. It worked so
far because this function is declared as 'inline'.
As we're about to revamp that part of the code, the VDSO would
break. Let's fix it by doing what should have been
Only arch_timer_read_counter will guarantee that workarounds are
applied. So let's use this one instead of arch_counter_get_cntvct.
Signed-off-by: Marc Zyngier
---
drivers/watchdog/sbsa_gwdt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/watchdog/sbsa_gwdt.c
On Mon, Apr 08, 2019 at 10:49:32AM -0400, Mathieu Desnoyers wrote:
> - On Apr 8, 2019, at 10:22 AM, paulmck paul...@linux.ibm.com wrote:
>
> > On Mon, Apr 08, 2019 at 09:05:34AM -0400, Mathieu Desnoyers wrote:
> >> - On Apr 7, 2019, at 10:27 PM, paulmck paul...@linux.ibm.com wrote:
> >>
From: Guo Ren
Before this patch csky-linux need CONFIG_RAM_BASE to determine start
physical address. Now we use phys_offset variable to replace the macro
of PHYS_OFFSET and we setup phys_offset with real physical address which
is determined during startup in head.S.
With this patch we needn't
On 4/8/2019 11:06 AM, Peter Zijlstra wrote:
On Tue, Apr 02, 2019 at 12:45:05PM -0700, kan.li...@linux.intel.com wrote:
+static struct event_constraint *
+icl_get_event_constraints(struct cpu_hw_events *cpuc, int idx,
+ struct perf_event *event)
+{
+ /*
+
Hi
On 4/7/19 5:50 PM, Pavel Machek wrote:
> Hi!
>
>>> Changes since v1:
>>>
>>> - synchronized DT label properties in DT bindings with what has been agreed
>>> for the patch "ARM: dts: omap4-droid4: Update backlight dt properties"
>>>
>>> The following changes since commit
On Sat, Apr 06, 2019 at 09:12:22PM -0400, Qian Cai wrote:
> The commit 665ac7e92757 ("acpi/hmat: Register processor domain to its
> memory") introduced an uninitialized "struct memory_target" that could
> cause an incorrect branching.
Thanks for the catch. We do have another patch submitted a few
On Mon, Apr 08, 2019 at 08:18:35AM -0700, Alexander Duyck wrote:
> On Mon, Apr 8, 2019 at 5:24 AM Nitesh Narayan Lal wrote:
> >
> >
> > On 4/5/19 8:09 PM, Alexander Duyck wrote:
> > > So I am starting this thread as a spot to collect my thoughts on the
> > > current guest free page hinting design
Hi Lee,
On 2/4/19 6:06, Lee Jones wrote:
> On Fri, 08 Mar 2019, Enric Balletbo i Serra wrote:
>
>> From: Vincent Palatin
>>
>> Allow to poll on the cros_ec device to receive the MKBP events.
>>
>> The /dev/cros_[ec|fp|..] file operations now implements the poll
>> operation. The userspace can
I currently have something like the below on top, is that correct?
If so, I'll fold it back in.
--- a/arch/x86/events/core.c
+++ b/arch/x86/events/core.c
@@ -563,16 +563,17 @@ int x86_pmu_hw_config(struct perf_event
/* sample_regs_user never support XMM registers */
if
On Mon, Mar 11, 2019 at 12:49:46PM +0100, Torsten Duwe wrote:
> On Wed, Feb 13, 2019 at 11:11:04AM +, Julien Thierry wrote:
> > Hi Torsten,
> >
> > On 08/02/2019 15:08, Torsten Duwe wrote:
> > > Patch series v8, as discussed.
> > > The whole series applies cleanly on 5.0-rc5
>
> So what's
On 2/8/19 6:10 PM, Torsten Duwe wrote:
> In preparation for arm64 supporting ftrace built on other compiler
> options, let's have makefiles remove the $(CC_FLAGS_FTRACE)
> flags, whatever these may be, rather than assuming '-pg'.
>
> There should be no functional change as a result of
On Fri, Feb 08, 2019 at 04:10:14PM +0100, Torsten Duwe wrote:
> In preparation for arm64 supporting ftrace built on other compiler
> options, let's have makefiles remove the $(CC_FLAGS_FTRACE)
> flags, whatever these may be, rather than assuming '-pg'.
>
> There should be no functional
Document devicetree bindings for stm32mp1 pwr regulators.
Signed-off-by: Pascal Paillet
---
.../bindings/regulator/st,stm32mp1-pwr-reg.txt | 43 ++
1 file changed, 43 insertions(+)
create mode 100644
Documentation/devicetree/bindings/regulator/st,stm32mp1-pwr-reg.txt
The POWER block of the STM32MP1 integrates 3 fixed regulators with a ready
status bit for each one. The goal of this patchset is to add support those
regulators.
Pascal Paillet (2):
dt-bindings: regulator: Add stm32mp1 pwr regulators
regulator: Add support for stm32 power regulators
Add support for 1V1 1V8 USB3V3 power regulators.
Signed-off-by: Pascal Paillet
---
drivers/regulator/Kconfig | 7 ++
drivers/regulator/Makefile| 1 +
drivers/regulator/stm32-pwr.c | 193 ++
3 files changed, 201 insertions(+)
create mode
Add an info message for the PXA2xx device driver start-up,
with the indication of the transfer mode used (DMA or GPIO).
This info is useful to individuate the timing when
the module starts.
Signed-off-by: Flavio Suligoi
---
drivers/spi/spi-pxa2xx.c | 3 +++
1 file changed, 3 insertions(+)
On 4/8/19 4:06 AM, Peng Ma wrote:
> Hi axboe,
>
> If you have no comments on these paths, please merge.
> Thank you very much.
> Patch link:
> http://patchwork.ozlabs.org/patch/1055028/
> http://patchwork.ozlabs.org/patch/1054189/
Can you resend, it's not clear which is which here, and what
On Mon, Apr 8, 2019 at 8:05 AM Enric Balletbo i Serra
wrote:
>
> When calling debugfs functions, there is no need to ever check the
> return value. The function can work or not, but the code logic should
> never do something different based on this.
>
> Cc: Greg Kroah-Hartman
> Signed-off-by:
> Il giorno 8 apr 2019, alle ore 17:13, Jens Axboe ha scritto:
>
> On 4/8/19 9:08 AM, Johannes Thumshirn wrote:
>> On Mon, Apr 08, 2019 at 09:05:19AM -0600, Jens Axboe wrote:
>>> I did consider that, and that would be doable. But honestly, I'm having a
>>> hard time seeing what issue we are
On Mon, Apr 8, 2019 at 5:24 AM Nitesh Narayan Lal wrote:
>
>
> On 4/5/19 8:09 PM, Alexander Duyck wrote:
> > So I am starting this thread as a spot to collect my thoughts on the
> > current guest free page hinting design as well as point out a few
> > possible things we could do to improve upon
301 - 400 of 749 matches
Mail list logo
