Introduce mailbox controller driver for ZynqMP IPI(Inter-processor
interrupt) IP core.
As the device tree bindings have been updated. Do not have "Reviewed-by"
nor "Acked-by" in the dt-bindings commit.
v6:
- dts-binding, remove compatible property from IPI subnode
v5:
- fix check patch
Hi Thomas
We have a class of machines that appear to be exhausting the vector
space on cpus 0 and 1 which causes some breakage later on when trying to
set the affinity. The boxes are running the 4.14 LTS kernel.
I instrumented 4.14 and here's what I see:
[ 28.328849] __assign_irq_vector:
On Mon, Nov 19, 2018 at 09:44:00AM +0530, Anshuman Khandual wrote:
> On 11/15/2018 04:19 AM, Keith Busch wrote:
> > System memory may have side caches to help improve access speed. While
> > the system provided cache is transparent to the software accessing
> > these memory ranges, applications
When we called regulator_enable() on a regulator we'd end up
propagating that call all the way up the chain every time. This is a
bit of a waste of time. A child regulator already refcounts its own
enables so it should avoid passing on to its parent unless the
refcount transitioned between 0 and
Now that consumers all keep track of their own enable count, let's add
it into the regulator_summary.
Signed-off-by: Douglas Anderson
---
drivers/regulator/core.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index
In general when the consumer of a regulator requests that the
regulator be disabled it no longer will be drawing much load from the
regulator--it should just be the leakage current and that should be
very close to 0.
Up to this point the regulator framework has continued to count a
consumer's
On 11/19/18 9:26 AM, Greg Kroah-Hartman wrote:
--
NOTE, this is going to be the last 4.18.y release. After this one it is
end-of-life, please move to 4.19.y at this point in time.
--
This is the start of the stable review cycle for the 4.18.20 release.
There are
At boot sometimes regulators (like qcom-rpmh-regulator) will return
-EINVAL if we don't know the enable state of the regulator. We
shouldn't take this to mean that the regulator is an always-on
regulator, but that was what was happening since "-EINVAL" is non-zero
and a few places in the code
The "requested_microamps" sysfs attribute was only being exposed for
"current" regulators. This didn't make sense. Allow it to be exposed
always.
Signed-off-by: Douglas Anderson
---
drivers/regulator/core.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/regulator/core.c
In the commit f8702f9e4aa7 ("regulator: core: Use ww_mutex for
regulators locking") disabling of the supply was moved into
_regulator_disable(). That means regulator_disable_work() shouldn't
be disabling since that double-disables the supply.
Fixes: f8702f9e4aa7 ("regulator: core: Use ww_mutex
In regulator_force_disable() there was a strange loop that looked like:
while (rdev->open_count--)
regulator_disable(rdev->supply);
I'm not totally sure what the goal was for this loop, but it seems
wrong to me. If anything I think maybe we should have been looping
over our use_count, but
> I'm not taking that stuff without proper documentation.
Ok can you just revert Jiri's code then instead?
This is after all mainly an emergency fixup patch for that disaster,
which got fast tracked without any of these considerations
which now suddenly appear. Requiring new documentation for
From: Jiri Olsa
Date: Mon, 19 Nov 2018 13:20:04 +0100
> David reported issues with perf top loosing side band events
> so we moved mmap reading and hists processing into separated
> threads.
>
> This patchset also adds dropping sample logic when the processing
> falls behind the reader thread.
Convert ocelot-serdes PHY driver to use recently introduced
PHY_MODE_ETHERNET and phy_set_mode_ext().
Cc: Quentin Schulz
Signed-off-by: Grygorii Strashko
---
drivers/net/ethernet/mscc/ocelot.c | 9 ++---
drivers/phy/mscc/phy-ocelot-serdes.c | 22 --
2 files changed,
Convert mvebu-cp110-comphy PHY driver to use recently introduced
PHY_MODE_ETHERNET and phy_set_mode_ext().
Cc: Russell King - ARM Linux
Cc: Maxime Chevallier
Cc: Antoine Tenart
Signed-off-by: Grygorii Strashko
---
drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 19 +-
Currently the attempt to add support for Ethernet interface mode PHY
(MII/GMII/RGMII) will lead to the necessity of extending enum phy_mode and
duplicate there values from phy_interface_t enum (or introduce more PHY
callbacks) [1]. Both approaches are ineffective and would lead to fast
bloating of
Hi, Shawn
Best Regards!
Anson Huang
> -Original Message-
> From: Shawn Guo [mailto:shawn...@kernel.org]
> Sent: 2018年11月19日 21:46
> To: Anson Huang
> Cc: robh...@kernel.org; mark.rutl...@arm.com; s.ha...@pengutronix.de;
> ker...@pengutronix.de; Fabio Estevam ;
>
On Mon, Nov 19, 2018 at 01:20:09PM +0100, Jiri Olsa wrote:
> We can't display the UI box saying that we are slow in reader
> thread. That will make perf top even slower and user even more
> angry ;-)
>
> Moving the UI box message out of the reader thread into UI thread
> and changing it into
Hi Wengang,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v4.20-rc3 next-20181119]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day
On Mon, Nov 19, 2018 at 10:59:58PM +0530, Manivannan Sadhasivam wrote:
> On Mon, Nov 19, 2018 at 06:22:02PM +0100, Andreas Färber wrote:
> > Am 19.11.18 um 18:09 schrieb Manivannan Sadhasivam:
> > > From: Andreas Färber
> > >
> > > RDA Microelectronics is a Chinese SoC manufacturer.
> > >
> > >
On 2018-11-19, Daniel Colascione wrote:
> On Mon, Nov 19, 2018 at 1:21 PM, Christian Brauner
> wrote:
> > That can be done without a loop by comparing the level counter for the
> > two pid namespaces.
> >
> >>
> >> And you can rewrite pidns_get_parent to use it. So you would instead be
> >>
On Mon, Nov 19, 2018 at 08:39:41PM +0100, Jiri Kosina wrote:
> On Mon, 19 Nov 2018, Andrea Arcangeli wrote:
>
> > Generally speaking the untrusted code that would try to use spectrev2
> > to attack the other processes is more likely to run inside SECCOMP
> > jail than outside, so if SECCOMP
On Sun, Nov 18, 2018 at 4:56 PM Guenter Roeck wrote:
>
> On 11/17/18 7:29 AM, Rob Herring wrote:
> > On Fri, Nov 09, 2018 at 11:56:06AM +1300, Chris Packham wrote:
> >> With the addition of the invert-pwm property the adt7475 needs its own
> >> binding documentation rather being captured under
On Mon, Nov 19, 2018 at 1:37 PM Christian Brauner wrote:
>
> On Mon, Nov 19, 2018 at 01:26:22PM -0800, Daniel Colascione wrote:
> > On Mon, Nov 19, 2018 at 1:21 PM, Christian Brauner
> > wrote:
> > > That can be done without a loop by comparing the level counter for the
> > > two pid
On 20.11.2018 1:09, Dmitry Osipenko wrote:
> On 20.11.2018 0:34, Jon Hunter wrote:
>>
>> On 30/08/2018 19:54, Dmitry Osipenko wrote:
>>> The DRAM refresh-interval is getting erroneously set to "1" on exiting
>>> from memory self-refreshing mode. The clobbered interval causes the
>>> "refresh
On Mon, Nov 19, 2018 at 9:12 AM Vokáč Michal wrote:
>
> On 12.11.2018 17:55, Rob Herring wrote:
> > On Fri, Nov 02, 2018 at 02:56:35PM +, Vokáč Michal wrote:
> >> The SSD130x OLED display reset signal is active low. Now the reset
> >> sequence is implemented in such a way that DTS authors are
On Mon, Nov 19, 2018 at 02:49:22PM -0800, Daniel Colascione wrote:
> On Mon, Nov 19, 2018 at 2:40 PM Tycho Andersen wrote:
> > Can I just register an objection here that I think using a syscall
> > just for this is silly?
>
> Yes, you can argue that the bikeshed should be ioctl-colored and not
>
On Tue, 20 Nov 2018, Thomas Gleixner wrote:
> What? IBPB makes tons of sense even without STIBP.
On non-SMT, yes. But this patchset ties those two the other (sensible) way
around AFAICS ("STIBP iff (IBPB && SMT)").
--
Jiri Kosina
SUSE Labs
On Tue, Nov 20, 2018 at 12:15:17AM +0100, Jason A. Donenfeld wrote:
> Hi Eric,
>
> On Mon, Nov 19, 2018 at 11:54 PM Eric Biggers wrote:
> > Will v9 include a documentation file for Zinc in Documentation/crypto/?
> > That's been suggested several times.
>
> I had started writing that there, but
On Mon, 19 Nov 2018, Dave Hansen wrote:
> > What? IBPB makes tons of sense even without STIBP.
>
> I'm lost. :)
>
> I don't think anyone is talking about using STIBP *everywhere* that IBPB
> is in-use.
>
> We're just guessing that, if anybody is paranoid enough to ask for IBPB,
> *and* they
On Mon, Nov 19, 2018 at 3:43 PM Dave Hansen wrote:
>
> On 11/19/18 3:19 PM, Dan Williams wrote:
> > Andy wondered why a path that can sleep was using __flush_tlb_all() [1]
> > and Dave confirmed the expectation for TLB flush is for modifying /
> > invalidating existing pte entries, but not
On Tue, 20 Nov 2018, Jiri Kosina wrote:
> On Mon, 19 Nov 2018, Dave Hansen wrote:
>
> > > What? IBPB makes tons of sense even without STIBP.
> >
> > I'm lost. :)
> >
> > I don't think anyone is talking about using STIBP *everywhere* that IBPB
> > is in-use.
> >
> > We're just guessing that, if
On 11/19/18 9:27 AM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.14.82 release.
There are 124 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be
On Mon, Nov 19, 2018 at 4:33 PM Christian Brauner wrote:
>
> On Mon, Nov 19, 2018 at 04:27:49PM -0800, Andy Lutomirski wrote:
> > On Mon, Nov 19, 2018 at 3:07 PM Tycho Andersen wrote:
> > > > These tools also care about ioctls. Adding a system call is a pain,
> > > > but the solution is to make
On 20.11.2018 3:26, Douglas Anderson wrote:
> In the commit f8702f9e4aa7 ("regulator: core: Use ww_mutex for
> regulators locking") disabling of the supply was moved into
> _regulator_disable(). That means regulator_disable_work() shouldn't
> be disabling since that double-disables the supply.
>
Let $(CC) compile objects into normal files *.o instead of .tmp_*.o
whether CONFIG_MODVERSIONS is enabled or not. With this, the input
file for objtool is always *.o so objtool_o can go away.
I guess the reason of using .tmp_*.o for intermediate objects was
to avoid leaving incomplete *.o file (,
On Mon, 2018-11-19 at 10:41 +0100, Stefan Agner wrote:
> Define the length of the DBI registers. This makes sure that
> the kernel does not access registers beyond that point, avoiding
> the following abort on a i.MX 6Quad:
> # cat
>
Currently, fixdep writes dependencies to .*.tmp, which is renamed to
.*.cmd after everything succeeds. This is a very safe way to avoid
corrupted .*.cmd files. The if_changed_dep has carried this safety
mechanism since it was added in 2002.
If fixdep fails for some reasons or a user terminates
My main motivation of this commit is to clean up scripts/Kbuild.include
and scripts/Makefile.build.
Currently, CONFIG_TRIM_UNUSED_KSYMS works with a tricky gimmick;
possibly exported symbols are detected by letting $(CPP) replace
EXPORT_SYMBOL* with a special string '=== __KSYM_*===', which is
This is executed inside the if_changed_rule, which already sets
'set -e'.
Signed-off-by: Masahiro Yamada
---
Changes in v2: None
scripts/Makefile.build | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/Makefile.build b/scripts/Makefile.build
index c909588..032ca24
The 'define' ... 'endef' directive can describe a recipe that consists
of multiple lines. For example,
all:
@echo hello
@echo world
... can be written as:
define greeting
@echo hello
@echo world
endif
all:
$(greeting)
With the change of rule_cc_o_c / rule_as_o_S in the last commit, each
command is executed in a separate subshell. Rip off unneeded semicolons.
Signed-off-by: Masahiro Yamada
---
Changes in v2:
- Clean up cmd_and_fixdep as well
scripts/Kbuild.include | 2 +-
scripts/Makefile.build | 16
'@set -e; $(echo-cmd) $(cmd_$(1)' can be replaced with '$(cmd)'.
Signed-off-by: Masahiro Yamada
---
Changes in v2: None
scripts/Kbuild.include | 9 +++--
scripts/Makefile.build | 4 ++--
2 files changed, 5 insertions(+), 8 deletions(-)
diff --git a/scripts/Kbuild.include
These three cmd_* are invoked in the $(call cmd,*) form.
Now that 'set -e' moved to the 'cmd' macro, they do not need to
explicitly give 'set -e'.
Signed-off-by: Masahiro Yamada
---
Changes in v2: None
scripts/Makefile.build | 2 --
scripts/package/Makefile | 1 -
2 files changed, 3
On Mon, Nov 19, 2018 at 02:11:27PM -0800, Hugh Dickins wrote:
> On Sun, 18 Nov 2018, Yu Zhao wrote:
>
> > We used to have a single swap address space with swp_entry_t.val
> > as its radix tree index. This is not the case anymore. Now Each
> > swp_type() has its own address space and should use
>
> Decleare struct tpm_header that replaces struct tpm_input_header and
Typo
> struct tpm_output_header.
>
> Signed-off-by: Jarkko Sakkinen
> Reviewed-by: Stefan Berger
> ---
> drivers/char/tpm/tpm-interface.c | 9 -
> drivers/char/tpm/tpm.h| 27
Xilinx ZynqMP IPI(Inter Processor Interrupt) is a hardware block
in ZynqMP SoC used for the communication between various processor
systems.
Signed-off-by: Wendy Liang
---
.../bindings/mailbox/xlnx,zynqmp-ipi-mailbox.txt | 127 +
1 file changed, 127 insertions(+)
create
On Mon, Nov 19, 2018 at 1:21 PM, Christian Brauner wrote:
> That can be done without a loop by comparing the level counter for the
> two pid namespaces.
>
>>
>> And you can rewrite pidns_get_parent to use it. So you would instead be
>> doing:
>>
>> if (pidns_is_descendant(proc_pid_ns,
On 11/19/18 11:32 AM, Andrea Arcangeli wrote:
> The specs don't say if by making it immune from BTB mistraining, it
> also could prevent to mistrain the BTB in order to attack what's
> outside the SECCOMP jail. Probably it won't and I doubt we can rely on
> it even if some implementation could do
On Sat, 2018-11-10 at 14:55 +0100, Peter Zijlstra wrote:
> On Fri, Nov 09, 2018 at 03:46:44PM -0800, Bart Van Assche wrote:
> > The lock validator forces to categorize multiple instances of a lock object
> > as the same lock class because it requires that struct lockdep_map and
> > struct
> >
From: "H.J. Lu"
When Intel indirect branch tracking is enabled, functions in vDSO which
may be called indirectly must have endbr32 or endbr64 as the first
instruction. Compiler must support -fcf-protection=branch so that it
can be used to compile vDSO.
Signed-off-by: H.J. Lu
---
Update ARCH_X86_CET_STATUS and ARCH_X86_CET_DISABLE to include
Indirect Branch Tracking features.
Introduce:
arch_prctl(ARCH_X86_CET_SET_LEGACY_BITMAP, unsigned long *addr)
Enable the Indirect Branch Tracking legacy code bitmap.
The parameter 'addr' is a pointer to a user buffer that
From: "H.J. Lu"
Add ENDBR64 to vsyscall entry points.
Signed-off-by: H.J. Lu
---
arch/x86/entry/vsyscall/vsyscall_emu_64.S | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/x86/entry/vsyscall/vsyscall_emu_64.S
b/arch/x86/entry/vsyscall/vsyscall_emu_64.S
index
The previous version of CET Branch Tracking/PTRACE patches is at the following
link:
https://lkml.org/lkml/2018/10/11/662
Summary of changes from v5:
Remove the legacy code bitmap allocation from kernel. Now GLIBC
allocates the bitmap and passes it to the kernel.
Some small fixes.
Look in .note.gnu.property of an ELF file and check if Indirect
Branch Tracking needs to be enabled for the task.
Signed-off-by: H.J. Lu
Signed-off-by: Yu-cheng Yu
---
arch/x86/include/uapi/asm/elf_property.h | 1 +
arch/x86/kernel/elf.c| 5 +
2 files changed, 6
On Sun, Nov 11, 2018 at 01:07:55PM +0800, Leo Yan wrote:
> The perf sample data contains flags to indicate the hardware trace data
> is belonging to which type branch instruction, thus this can be used to
> print out the human readable string. Arm CoreSight ETM sample data is
> missed to set
This series is a whole bunch of page fault cleanups, plus a couple
of OOPS diagnostic improvements. The overall goals are to clean up
handling of the faulting CPL, the USER bit in the error_code, and
the log messages generated by #PF OOPSes.
This series can also be seen as CET preparation. CET
Currently, if a user program somehow triggers an implicit supervisor
access to a user address (e.g. if the kernel somehow sets LDTR to a
user address), it will be incorrectly detected as a SMAP violation
if AC is clear and SMAP is enabled. This is incorrect -- the error
has nothing to do with
All of the fault handling code now corrently checks user_mode(regs)
as needed, and nothing depends on the X86_PF_USER bit being munged.
Get rid of the sw_error code and use hw_error_code everywhere.
Signed-off-by: Andy Lutomirski
---
arch/x86/mm/fault.c | 52
The error code in a page fault on a kernel address indicates
whether that address is mapped, which should not be revealed in a signal.
The normal code path for a page fault on a kernel address sanitizes the bit,
but the paths for vsyscall emulation and SIGBUS do not. Both are
harmless, but for
On 11/19/2018 12:21 PM, Thomas Gleixner wrote:
> On Fri, 16 Nov 2018, Tim Chen wrote:
>> +static enum spectre_v2_app2app_mitigation_cmd __init
>> +spectre_v2_parse_app2app_cmdline(enum spectre_v2_mitigation_cmd
>> v2_cmd)
>> +{
>> +enum spectre_v2_app2app_mitigation_cmd cmd;
>> +
Rather than hardcoding 6 with a comment, use the defined constants.
Signed-off-by: Andy Lutomirski
---
arch/x86/entry/vsyscall/vsyscall_64.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/entry/vsyscall/vsyscall_64.c
b/arch/x86/entry/vsyscall/vsyscall_64.c
index
Hi1
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -4364,6 +4353,15 @@ __alloc_pages_nodemask(gfp_t gfp_mask, unsigned
> int order, int preferred_nid,
> gfp_t alloc_mask; /* The gfp_t that was actually used for
> allocation */
> struct
Hi!
> Some of Huawei laptops come with a LED in the micmute key. This patch
> enables and disable this LED accordingly.
>
> Signed-off-by: Ayman Bagabas
NAK.
We already have a LED subsystem.
> +#if IS_ENABLED(CONFIG_HUAWEI_LAPTOP)
> +#include
> +
> +static int
This should never have been defined in the arch tree to begin with,
and now uapi/linux/audit.h header is going to use EM_UNICORE
in order to define AUDIT_ARCH_UNICORE which is needed to implement
syscall_get_arch() which in turn is required to extend
the generic ptrace API with
These should never have been defined in the arch tree to begin with, and
now uapi/linux/audit.h header is going to use EM_ARCOMPACT and EM_ARCV2
in order to define AUDIT_ARCH_ARCOMPACT and AUDIT_ARCH_ARCV2 which are
needed to implement syscall_get_arch() which in turn is required to
extend the
This should never have been defined in the arch tree to begin with,
and now uapi/linux/audit.h header is going to use EM_HEXAGON
in order to define AUDIT_ARCH_HEXAGON which is needed to implement
syscall_get_arch() which in turn is required to extend
the generic ptrace API with
The uapi/linux/audit.h header is going to use EM_XTENSA in order
to define AUDIT_ARCH_XTENSA which is needed to implement
syscall_get_arch() which in turn is required to extend
the generic ptrace API with PTRACE_GET_SYSCALL_INFO request.
The value for EM_XTENSA has been taken from
syscall_get_arch() is required to be implemented on all architectures
in order to extend the generic ptrace API with PTRACE_GET_SYSCALL_INFO
request.
Signed-off-by: Dmitry V. Levin
---
v2: unchanged since v1
arch/m68k/include/asm/syscall.h | 12
1 file changed, 12 insertions(+)
The uapi/linux/audit.h header is going to use EM_NDS32 in order
to define AUDIT_ARCH_NDS32 which is needed to implement
syscall_get_arch() which in turn is required to extend
the generic ptrace API with PTRACE_GET_SYSCALL_INFO request.
The value for EM_NDS32 has been taken from
Hello,
Thank you for applying my patch and sorry for mistake...
On 2018年11月19日 22:43, Heiko Stuebner wrote:
Am Sonntag, 18. November 2018, 05:18:02 CET schrieb Katsuhiro Suzuki:
This patch fixes mistakes in HCLK_I2S1_8CH for running I2S1
successfully.
Signed-off-by: Katsuhiro Suzuki
---
Hi Philipp,
On Thu, Oct 18, 2018 at 1:02 AM Philipp Zabel wrote:
>
> Hi Maxime,
>
> On Fri, 2018-10-12 at 15:46 +0200, Maxime Ripard wrote:
> > On Fri, Oct 12, 2018 at 12:05:16PM +0200, Philipp Zabel wrote:
> [...]
> > > What I would like better would be to let the consumers keep their reset-
>
This fixes compiling regulator drivers that use these function when
these drivers are built as kernel modules.
Fixes: f8702f9e4aa7 ("regulator: core: Use ww_mutex for regulators locking")
Signed-off-by: Dmitry Osipenko
---
drivers/regulator/core.c | 2 ++
1 file changed, 2 insertions(+)
diff
On 30/08/2018 19:54, Dmitry Osipenko wrote:
> The memory interface configuration and re-calibration interval are left
> unassigned on resume from LP1 because these registers are shadowed and
> require latching after being adjusted.
>
> Signed-off-by: Dmitry Osipenko
> ---
>
Hello,
syzbot found the following crash on:
HEAD commit:bae4e109837b mlxsw: spectrum: Expose discard counters via ..
git tree: net-next
console output: https://syzkaller.appspot.com/x/log.txt?x=11b5e77b40
kernel config: https://syzkaller.appspot.com/x/.config?x=d86f24333880b605
On 30/08/2018 19:54, Dmitry Osipenko wrote:
> Two interrupts are raised on resume from LP1 on Tegra30+: first is the
> clock change completed interrupt which is set after updating timing
> configuration, second is DLL alarm interrupt which is set when DLL
> starts re-calibration after being
On Sun, 18 Nov 2018, Yu Zhao wrote:
> We used to have a single swap address space with swp_entry_t.val
> as its radix tree index. This is not the case anymore. Now Each
> swp_type() has its own address space and should use swp_offset()
> as radix tree index.
>
> Signed-off-by: Yu Zhao
This fix
On 11/19/2018 04:21 PM, Boris Brezillon wrote:
> On Mon, 19 Nov 2018 16:12:41 +0100
> Marek Vasut wrote:
>
>> On 11/19/2018 03:43 PM, Boris Brezillon wrote:
>>> On Mon, 19 Nov 2018 15:14:07 +0100
>>> Marek Vasut wrote:
>>>
On 11/19/2018 03:10 PM, Boris Brezillon wrote:
> On Mon,
On Sun, Nov 11, 2018 at 01:07:56PM +0800, Leo Yan wrote:
> We have prepared the flags in the packet structure, so need to copy
> the related value into sample structure thus perf tool can facilitate
> sample flags.
>
> The PREV_PACKET contains the branch instruction flags and PACKET
> actually
Hi Christian,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v4.20-rc3]
[cannot apply to next-20181119]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url
On 11/19/18 3:01 PM, Thomas Gleixner wrote:
>> Yes, it wouldn't make sense for having just one of those if a task
>> is worried about attack from user space.
>>
>> I'll document it.
> What? IBPB makes tons of sense even without STIBP.
I'm lost. :)
I don't think anyone is talking about using
On Mon, 19 Nov 2018, Tim Chen wrote:
> On 11/19/2018 05:32 AM, Thomas Gleixner wrote:
> > On Fri, 16 Nov 2018, Tim Chen wrote:
> >> The protection mode can be specified by the spectre_v2_app2app
> >> boot parameter with the following semantics:
> >>
> >> spectre_v2_app2app=
> >>off- Turn
On 11/19/18 9:25 AM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.19.3 release.
There are 205 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be
On Mon, Nov 19, 2018 at 04:27:49PM -0800, Andy Lutomirski wrote:
> On Mon, Nov 19, 2018 at 3:07 PM Tycho Andersen wrote:
> > > These tools also care about ioctls. Adding a system call is a pain,
> > > but the solution is to make adding system calls less of a pain, not to
> > > permanently make
egulator_unlock" [drivers/regulator/da9210-regulator.ko] undefined!
ERROR: "regulator_lock" [drivers/regulator/da9210-regulator.ko] undefined!
Caused by commit
f8702f9e4aa7 ("regulator: core: Use ww_mutex for regulators locking")
I have used the regulator tree from next
Hi Dava:
How about just change the ptdump_fops and ptdump_open?
Yours,
Yangtao
On Tue, Nov 20, 2018 at 1:06 AM Dave Hansen wrote:
>
> On 11/19/18 7:43 AM, Yangtao Li wrote:
> > -static const struct file_operations ptdump_curusr_fops = {
> > - .owner = THIS_MODULE,
> > -
On Mon, Nov 19, 2018 at 4:28 PM Andy Lutomirski wrote:
>
> On Mon, Nov 19, 2018 at 3:07 PM Tycho Andersen wrote:
> > > These tools also care about ioctls. Adding a system call is a pain,
> > > but the solution is to make adding system calls less of a pain, not to
> > > permanently make the Linux
On Mon, 2018-11-19 at 15:43 -0800, Dave Hansen wrote:
> On 11/19/18 3:19 PM, Dan Williams wrote:
> > Andy wondered why a path that can sleep was using __flush_tlb_all()
> > [1]
> > and Dave confirmed the expectation for TLB flush is for modifying /
> > invalidating existing pte entries, but not
On Tue, 20 Nov 2018, Jiri Kosina wrote:
> On Tue, 20 Nov 2018, Thomas Gleixner wrote:
>
> > What? IBPB makes tons of sense even without STIBP.
>
> On non-SMT, yes. But this patchset ties those two the other (sensible) way
> around AFAICS ("STIBP iff (IBPB && SMT)").
Errm. No.
The patches
e4aa7 ("regulator: core: Use ww_mutex for regulators locking")
>
> I have used the regulator tree from next-20181119 for today.
>
My bad, forgot to export these functions. That's the same issue that was
reporter by the build robot earlier. Will send the fix, sorry for the
inconvenience.
Hi Nicolas,
On Sat, Nov 17, 2018 at 2:50 AM Nicolas Pitre wrote:
> > > > diff --git a/scripts/Makefile.build b/scripts/Makefile.build
> > > > index 7f3ca6e..e5ba9b1 100644
> > > > --- a/scripts/Makefile.build
> > > > +++ b/scripts/Makefile.build
> > > > @@ -254,9 +254,18 @@ objtool_dep =
On Mon, Nov 19, 2018 at 10:12:57AM +0100, Jiri Olsa wrote:
> On Mon, Nov 19, 2018 at 02:26:03PM +0900, Namhyung Kim wrote:
> > Hi Jirka
> >
> > Sorry for late!
> >
> > On Tue, Nov 06, 2018 at 12:54:36PM +0100, Jiri Olsa wrote:
> > > On Mon, Nov 05, 2018 at 08:53:42PM -0800, David Miller wrote:
>
On 11/19/2018 04:30 PM, Thomas Gleixner wrote:
>
> What has spectre_v2=on to do with spectre_v2_app2app=on?
>
> Exactly nothing. You can have 'on' for both. The only side effect of
> spectre_v2=on is that it also forces spectre_v2_app2app to 'on'
> irrespective of what eventually was added for
On Tue, Nov 20, 2018 at 3:02 AM Nick Desaulniers
wrote:
>
> On Mon, Nov 19, 2018 at 4:37 AM Luc Van Oostenryck
> wrote:
> >
> > On Mon, Nov 19, 2018 at 07:31:43PM +0900, Masahiro Yamada wrote:
> > > The introduction of these dummy BUILD_BUG_ON stubs dates back to
> > > commit 903c0c7cdc21
Heb je een lening nodig voor welk doel dan ook??
wij verlenen lening at 3% belangen tarief jaarlijks
Ik kan u helpen met het financieren van leningen voor elk doel
(zolang er geen sprake is van enige vorm van illegaliteit),
van € 5.000 (vijfduizend euro) tot slechts € 20 miljoen euro.
Alle
On Tue, 2018-11-13 at 11:31 -0800, Nicolas Boichat wrote:
> (not a complete review...)
>
> On Mon, Nov 5, 2018 at 10:42 PM Weiyi Lu wrote:
> >
> > From: Owen Chen
> >
> > Both MT8183 & MT6765 add more bus protect node than previous project,
> > therefore we add two more register for setup bus
On 2018-11-19, Christian Brauner wrote:
> On Tue, Nov 20, 2018 at 08:18:10AM +1100, Aleksa Sarai wrote:
> > On 2018-11-19, Christian Brauner wrote:
> > > On Tue, Nov 20, 2018 at 07:28:57AM +1100, Aleksa Sarai wrote:
> > > > On 2018-11-19, Christian Brauner wrote:
> > > > > + if (info) {
> >
>
> The error logging for tpm2_commit_space() is in a wrong place. This commit
> moves it inside that function.
>
> Cc: James Bottomley
> Signed-off-by: Jarkko Sakkinen
> Reviewed-by: Stefan Berger
> ---
> drivers/char/tpm/tpm-interface.c | 2 --
> drivers/char/tpm/tpm2-space.c| 9
Allow printk time stamps/sched_clock() to be available from the early
boot.
Signed-off-by: Pavel Tatashin
---
arch/arm64/kernel/setup.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
index f4fc1e0544b7..4df41a66b403
I made early boot time stamps available for SPARC and X86.
x86:
https://lore.kernel.org/lkml/20180719205545.16512-1-pasha.tatas...@oracle.com
sparc:
https://www.spinics.net/lists/sparclinux/msg18063.html
As discussed at plumbers, I would like to add the same for arm64. The
implementation does
1 - 100 of 3448 matches
Mail list logo
