On 4/16/21 12:37 PM, Willy Tarreau wrote:
> Hi Miguel,
>
> On Fri, Apr 16, 2021 at 07:10:17PM +0200, Miguel Ojeda wrote:
>> And by having the compiler enforce this safe-unsafe split, you can
>> review safe code without having to constantly worry about UB; and be
>> extra alert when dealing with
On Thu, Apr 15, 2021 at 09:27:39PM +0800, peng@oss.nxp.com wrote:
> From: Peng Fan
>
> To i.MX7ULP, M4 is the master to control everything, no need to provide
> clk from Linux side. So make clk optional when method is IMX_RPROC_NONE.
>
> Signed-off-by: Peng Fan
> ---
>
On Fri, Apr 16, 2021 at 10:35:20PM +0530, Anirudh Rayabharam wrote:
> On Fri, Apr 16, 2021 at 11:27:34AM -0400, Alan Stern wrote:
> > Actually, I wanted to move this emulation code into a new subroutine and
> > then call that subroutine from _both_ places. Would you like to write
>
> Does it
On Thu, Apr 15, 2021 at 09:27:38PM +0800, peng@oss.nxp.com wrote:
> From: Peng Fan
>
> Add three methods IMX_RPROC_NONE(no need start/stop), IMX_RPROC_MMIO
> (start/stop through mmio) and IMX_RPROC_SMC(start/stop through ARM SMCCC).
>
> The current SoCs supported are all using
> so linux...@kvack.org would be better IMO.
Thank you, I will try this message there instead.
> [7] tells me:
> SyntaxError: JSON.parse: unexpected non-whitespace character after JSON data
> at line 1 column 16 of the JSON data
I'll put my log up on another paste host, thanks again.
On Thu, Apr 15, 2021 at 09:27:37PM +0800, peng@oss.nxp.com wrote:
> From: Peng Fan
>
> Parse fsl,auto-boot to indicate whether need remoteproc framework
> auto boot or not.
>
> When remote processor is booted before Linux Kernel up, do not parse
> fsl,auto-boot, so only need to parse the
On 16.04.2021 19:31, Mark Brown wrote:
> On Fri, Apr 16, 2021 at 04:03:05PM +, codrin.ciubota...@microchip.com
> wrote:
>
>> Thank you for the links! So basically the machine driver disappears and
>> all the components will be visible in user-space.
>
> Not entirely - you still need
Maybe when the cable is disconnected the DP phy should be shutdown and
some bit in the phy could effectively "cut off" the aux channel and then
NAKs would start coming through here in the DP controller I/O register
space. This patch have DP aux channel read/write to return NAK immediately
if DP
Initialize audio_comp when audio starts and wait for audio_comp at
dp_display_disable(). This will take care of both dongle unplugged
and display off (suspend) cases.
Changes in v2:
-- add dp_display_signal_audio_start()
Changes in v3:
-- restore dp_display_handle_plugged_change() at
Hi Miguel,
On Fri, Apr 16, 2021 at 07:10:17PM +0200, Miguel Ojeda wrote:
> And by having the compiler enforce this safe-unsafe split, you can
> review safe code without having to constantly worry about UB; and be
> extra alert when dealing with `unsafe` blocks.
I do appreciate this safe/unsafe
On Thu, Apr 15, 2021 at 05:37:54PM +0300, Andy Shevchenko wrote:
> Strictly speaking the comparison between guid_t and raw buffer
> is not correct. Return to plain memcmp() since the data structures
> haven't changed to use uuid_t / guid_t the current state of affairs
> is inconsistent. Either it
I am seeing missed wakeups which ultimately lead to a deadlock when I am
using virtiofs with DAX enabled and running "make -j". I had to mount
virtiofs as rootfs and also reduce to dax window size to 32M to reproduce
the problem consistently.
This is not a complete patch. I am just proposing this
On Sat, Apr 17, 2021 at 01:20:12AM +0800, Chung-Chiang Cheng wrote:
> hfsplus uses the case-insensitive filenames by default, but VFS negative
> dentries are incompatible with case-insensitive. For example, the
> following instructions will get a cached filename 'aaa' which isn't
> expected. There
On Fri, Apr 16, 2021 at 3:38 PM Peter Zijlstra wrote:
>
> So if I read all this right, rust compiles to .o and, like any other .o
> file is then fed into objtool (for x86_64). Did you have any problems
> with objtool? Does it generate correct ORC unwind information?
I opened an issue a while ago
On Tue, Apr 13, 2021 at 02:06:04PM +0100, Khaled ROMDHANI wrote:
> The variable zone is not initialized. It
> may causes a failed assertion.
Failed assertion means the 2nd one checking that the result still fits
to 32bit type. That would mean that none of the cases were hit, but all
callers pass
On Fri, Apr 16, 2021 at 09:15:34AM -0700, Dan Williams wrote:
> On Fri, Apr 16, 2021 at 1:58 AM Andy Shevchenko
> wrote:
> > On Fri, Apr 16, 2021 at 8:28 AM Dan Williams
> > wrote:
> > > On Thu, Apr 15, 2021 at 6:59 AM Andy Shevchenko
> > > wrote:
> > > >
> > > > Strictly speaking the
Currently the proactive compaction order is fixed to
COMPACTION_HPAGE_ORDER(9), it's OK in most machines with lots of
normal 4KB memory, but it's too high for the machines with small
normal memory, for example the machines with most memory configured
as 1GB hugetlbfs huge pages. In these machines
Thanks!
Madhavan
On 4/16/21 11:17 AM, Mark Brown wrote:
> On Thu, Apr 01, 2021 at 10:24:04PM -0500, madve...@linux.microsoft.com wrote:
>
>> Reliable stacktracing requires that we identify when a stacktrace is
>> terminated early. We can do this by ensuring all tasks have a final
>> frame
On 4/16/21 10:29 AM, Randy Dunlap wrote:
> On 4/16/21 10:20 AM, Drew Abbott wrote:
>> Hello,
>>
>> I have been troubleshooting problems with the vanilla and lts linux kernels
>> for a couple of weeks now and saw this mailing list in MAINTAINERS for
>> problems with mm.h; apologies if this is the
On Thu, 15 Apr 2021 16:48:07 +0200, Greg Kroah-Hartman
wrote:
> This is the start of the stable review cycle for the 5.11.15 release.
> There are 23 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.
>
On Fri, Apr 16, 2021, Kirill A. Shutemov wrote:
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 1b404e4d7dd8..f8183386abe7 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -8170,6 +8170,12 @@ int kvm_emulate_hypercall(struct kvm_vcpu *vcpu)
>
On Wed, 14 Apr 2021 19:10:53 +0100
Lee Jones wrote:
> Also demote kernel-doc abuses
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/staging/iio/frequency/ad9834.c:87: warning: Function parameter or
> member 'devid' not described in 'ad9834_state'
>
On Thu, Apr 15, 2021 at 03:54:26PM -0400, Waiman Long wrote:
> The handling of sysrq key can be activated by echoing the key to
> /proc/sysrq-trigger or via the magic key sequence typed into a terminal
> that is connected to the system in some way (serial, USB or other mean).
> In the former case,
On 4/16/21 10:20 AM, Drew Abbott wrote:
> Hello,
>
> I have been troubleshooting problems with the vanilla and lts linux kernels
> for a couple of weeks now and saw this mailing list in MAINTAINERS for
> problems with mm.h; apologies if this is the wrong place to ask. I have
MAINTAINERS file
From: "Steven Rostedt (VMware)"
The func_repeats event shows the output of the function tracer followed by
a count of the number of repeats the previous function had made, as well
as the timestamp of the last function that was repeated.
The printing of the function should be the same as is for
From: "Yordan Karadzhov (VMware)"
If the option is activated the function tracing record gets
consolidated in the cases when a single function is called number
of times consecutively. Instead of having an identical record for
each call of the function we will record only the first call
following
From: "Yordan Karadzhov (VMware)"
Currently the logic for dealing with the options for function tracing
has two different implementations. One is used when we set the flags
(in "static int func_set_flag()") and another used when we initialize
the tracer (in "static int function_trace_init()").
From: "Yordan Karadzhov (VMware)"
This patch only provides the implementation of the method.
Later we will used it in a combination with a new option for
function tracing.
Link: https://lkml.kernel.org/r/20210415181854.147448-5-y.kar...@gmail.com
Signed-off-by: Yordan Karadzhov (VMware)
From: "Yordan Karadzhov (VMware)"
The field is used to keep track of the consecutive (on the same CPU) calls
of a single function. This information is needed in order to consolidate
the function tracing record in the cases when a single function is called
number of times.
Link:
From: "Yordan Karadzhov (VMware)"
The part of the code that prints the time of the trace record in
"int trace_print_context()" gets extracted in a static function. This
is done as a preparation for a following patch, in which we will define
a new ftrace event called "func_repeats". The new
From: "Yordan Karadzhov (VMware)"
The event aims to consolidate the function tracing record in the cases
when a single function is called number of times consecutively.
while (cond)
do_func();
This may happen in various scenarios (busy waiting for example).
The new
Steven Rostedt (VMware) , Yordan Karadzhov (VMware)
git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git
for-next
Head SHA1: e1db6338d6fa0d409e45cf20ab5aeaca704f68e7
Steven Rostedt (VMware) (1):
ftrace: Reuse the output of the function tracer for func_repeats
Yordan
On Fri, Apr 16, 2021 at 06:51:10PM +0800, Xu, Yanfei wrote:
>
>
> On 4/16/21 1:07 AM, Paul E. McKenney wrote:
> > [Please note: This e-mail is from an EXTERNAL e-mail address]
> >
> > On Fri, Apr 16, 2021 at 12:18:42AM +0800, Xu, Yanfei wrote:
> > >
> > >
> > > On 4/15/21 11:43 PM, Paul E.
On 4/16/2021 5:04 AM, Vitaly Kuznetsov wrote:
Vineeth Pillai writes:
+#if IS_ENABLED(CONFIG_HYPERV)
+static void hv_init_vmcb(struct vmcb *vmcb)
+{
+ struct hv_enlightenments *hve = >hv_enlightenments;
+
+ if (npt_enabled &&
+ ms_hyperv.nested_features &
On Fri, Apr 16, 2021 at 11:11:04AM -0400, Johannes Weiner wrote:
> On Fri, Apr 16, 2021 at 08:32:16PM +0530, Charan Teja Reddy wrote:
> > psi_group_cpu->tasks, represented by the unsigned int, stores the number
> > of tasks that could be stalled on a psi resource(io/mem/cpu).
> > Decrementing
The create_date field of inode in hfsplus is corresponding to kstat.btime
and could be reported in statx.
Signed-off-by: Chung-Chiang Cheng
---
fs/hfsplus/inode.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/fs/hfsplus/inode.c b/fs/hfsplus/inode.c
index 078c5c8a5156..aab3388a0fd7
On Thu, Apr 15, 2021 at 2:29 PM Luis Chamberlain wrote:
>
> On Thu, Apr 15, 2021 at 02:17:58PM -0400, Josef Bacik wrote:
> > There's a lot of larger things that need to
> > be addressed in general to support the volume approach inside file systems
> > that is going to require a lot of work inside
Hi Alex,
On Fri, 16 Apr 2021 09:45:47 -0600, Alex Williamson
wrote:
> On Fri, 16 Apr 2021 06:12:58 -0700
> Jacob Pan wrote:
>
> > Hi Jason,
> >
> > On Thu, 15 Apr 2021 20:07:32 -0300, Jason Gunthorpe
> > wrote:
> > > On Thu, Apr 15, 2021 at 03:11:19PM +0200, Auger Eric wrote:
> > > >
On Wed, Apr 14, 2021 at 3:38 AM Lee Jones wrote:
>
> On Fri, 09 Apr 2021, satya priya wrote:
>
> > Convert pm8xxx bindings from .txt to .yaml format. Also,
> > split this binding into two: parent binding(qcom-pm8xxx.yaml)
> > and child node RTC binding(qcom-pm8xxx-rtc.yaml).
> >
> >
hfsplus uses the case-insensitive filenames by default, but VFS negative
dentries are incompatible with case-insensitive. For example, the
following instructions will get a cached filename 'aaa' which isn't
expected. There is no such problem in macOS.
touch aaa
rm aaa
touch AAA
This patch
On Fri, Apr 16, 2021 at 07:10:17PM +0200, Miguel Ojeda wrote:
> Of course, UB is only a subset of errors, but it is a major one, and
> particularly critical for privileged code.
I've seen relatively few UBSAN warnings that weren't due to UBSAN being
broken.
Hello,
I have been troubleshooting problems with the vanilla and lts linux kernels
for a couple of weeks now and saw this mailing list in MAINTAINERS for
problems with mm.h; apologies if this is the wrong place to ask. I have
been experiencing many freezes and panics with this hardware:
From: Colin Ian King
The variable agaw is initialized with a value that is never
read and it is being updated later with a new value as a
counter in a for-loop. The initialization is redundant and
can be removed.
Addresses-Coverity: ("Unused value")
Signed-off-by: Colin Ian King
---
The following commit has been merged into the perf/core branch of tip:
Commit-ID: de5bc7b425d4c27ae5faa00ea7eb6b9780b9a355
Gitweb:
https://git.kernel.org/tip/de5bc7b425d4c27ae5faa00ea7eb6b9780b9a355
Author:Nathan Chancellor
AuthorDate:Wed, 14 Apr 2021 17:11:11 -07:00
The following commit has been merged into the perf/core branch of tip:
Commit-ID: 5deac80d4571dffb51f452f0027979d72259a1b9
Gitweb:
https://git.kernel.org/tip/5deac80d4571dffb51f452f0027979d72259a1b9
Author:Nathan Chancellor
AuthorDate:Wed, 14 Apr 2021 17:11:12 -07:00
The following commit has been merged into the perf/core branch of tip:
Commit-ID: d0d1dd628527c77db2391ce0293c1ed344b2365f
Gitweb:
https://git.kernel.org/tip/d0d1dd628527c77db2391ce0293c1ed344b2365f
Author:Namhyung Kim
AuthorDate:Wed, 10 Feb 2021 17:33:26 +09:00
The following commit has been merged into the perf/core branch of tip:
Commit-ID: 7c8056bb366b1b2dc8e4a3cc0b876e15a8ebca2c
Gitweb:
https://git.kernel.org/tip/7c8056bb366b1b2dc8e4a3cc0b876e15a8ebca2c
Author:Namhyung Kim
AuthorDate:Wed, 10 Feb 2021 17:33:25 +09:00
On Fri, Apr 16, 2021 at 08:58:33PM +0530, Pratik Sampat wrote:
> Hello Dennis,
>
> I apologize for the clutter of logs before, I'm pasting the logs of before and
> after the percpu test in the case of the patchset being applied on 5.12-rc6
> and
> the vanilla kernel 5.12-rc6.
>
> On 16/04/21
Hi, all,
On Fri, Apr 16, 2021 at 01:00:23PM -0300, Marcelo Tosatti wrote:
>
> Setting the realtime clock triggers an IPI to all CPUs to reprogram
> the clock event device.
>
> However, only realtime and TAI clocks have their offsets updated
> (and therefore potentially require a reprogram).
>
> -Original Message-
> From: Stephen Hemminger
> Sent: Friday, April 16, 2021 12:40 PM
> To: Dexuan Cui
> Cc: da...@davemloft.net; k...@kernel.org; KY Srinivasan
> ; Haiyang Zhang ; Stephen
> Hemminger ; wei@kernel.org; Wei Liu
> ; net...@vger.kernel.org; l...@kernel.org;
>
On Fri, Apr 16, 2021 at 6:14 PM Willy Tarreau wrote:
>
> I'm really afraid by languages which force developers to do this or that.
> Many bugs in C come from casts because developers know their use case
> better than the compiler's developers, and result in lack of warnings
> when the code
On Fri, 16 Apr 2021 16:27:55 +0100
Matthew Wilcox wrote:
> On Thu, Apr 15, 2021 at 08:08:32PM +0200, Jesper Dangaard Brouer wrote:
> > See below patch. Where I swap32 the dma address to satisfy
> > page->compound having bit zero cleared. (It is the simplest fix I could
> > come up with).
>
>
The pull request you sent on Fri, 16 Apr 2021 09:57:52 -0700 (PDT):
> git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git
> tags/riscv-for-linus-5.12-rc8
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/151501160401e2dc669ea7dac2c599b53f220c33
Thank you!
--
On 4/16/2021 4:58 AM, Vitaly Kuznetsov wrote:
+
+#if IS_ENABLED(CONFIG_HYPERV)
+struct __packed hv_enlightenments {
+ struct __packed hv_enlightenments_control {
+ u32 nested_flush_hypercall:1;
+ u32 msr_bitmap:1;
+ u32 enlightened_npt_tlb: 1;
On Fri, Apr 16, 2021 at 11:27:34AM -0400, Alan Stern wrote:
> On Fri, Apr 16, 2021 at 11:10:35AM +0530, Anirudh Rayabharam wrote:
> > On Tue, Apr 13, 2021 at 12:13:11PM -0400, Alan Stern wrote:
> > > Maybe we can test this reasoning by putting a delay just before the call
> > > to
On Fri, Apr 16, 2021 at 6:38 AM Peter Zijlstra wrote:
>
> AFAICT rust has try/throw/catch exception handling (like
> C++/Java/others) which is typically implemented with stack unwinding of
> its own.
I was assuming that the kernel side would never do that.
There's some kind of "catch_unwind()"
On Fri, 2021-04-16 at 18:51 +0200, Christophe JAILLET wrote:
> Le 16/04/2021 à 18:11, Joe Perches a écrit :
> > On Fri, 2021-04-16 at 17:58 +0200, Christophe JAILLET wrote:
> > > The devm_ variant of 'kcalloc()' and 'kmalloc_array()' are not tested
> > > Add the corresponding check.
> > []
> > >
On 16/04/2021 13:04, Ruifeng Zhang wrote:
> Dietmar Eggemann 于2021年4月16日周五 下午6:39写道：
>>
>> On 16/04/2021 11:32, Valentin Schneider wrote:
>>> On 16/04/21 15:47, Ruifeng Zhang wrote:
[...]
>> I'm confused. Do you have the MT bit set to 1 then? So the issue that
>> the mpidr handling in arm32's
The following changes since commit e49d033bddf5b565044e2abe4241353959bc9120:
Linux 5.12-rc6 (2021-04-04 14:15:36 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git
tags/riscv-for-linus-5.12-rc8
for you to fetch changes up to
From: Matthew Gerlach
This patch adds a Device Feature List (DFL) bus driver for the
Altera SPI Master controller. The SPI master is connected to an
Intel SPI Slave to Avalon Bridge inside an Intel MAX10
BMC Chip.
Signed-off-by: Matthew Gerlach
---
v3: Instantiate SPI device instead of
From: Matthew Gerlach
This patch set adds Device Feature List (DFL) bus support for
the Altera SPI Master controller.
Patch 1 separates spi-altera.c into spi-altera-core.c and
spi-altera-platform.c.
Patch 2 adds spi-altera-dfl.c.
Matthew Gerlach (2):
spi: altera: separate core code from
From: Matthew Gerlach
In preparation of adding support for a new bus type,
separate the core spi-altera code from the platform
driver code.
Signed-off-by: Matthew Gerlach
---
drivers/spi/Kconfig | 9 +-
drivers/spi/Makefile | 3 +-
drivers/spi/spi-altera-core.c
The pull request you sent on Fri, 16 Apr 2021 17:24:55 +0100:
> git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux tags/arm64-fixes
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/06c2aac4014c38247256fe49c61b7f55890271e7
Thank you!
--
Deet-doot-dot, I am a
I've edited the thing to look like so. I'll go queue it for
locking/urgent.
---
Subject: locking/qrwlock: Fix ordering in queued_write_lock_slowpath()
From: Ali Saidi
Date: Thu, 15 Apr 2021 17:27:11 +
From: Ali Saidi
While this code is executed with the wait_lock held, a reader can
Le 16/04/2021 à 18:11, Joe Perches a écrit :
On Fri, 2021-04-16 at 17:58 +0200, Christophe JAILLET wrote:
The devm_ variant of 'kcalloc()' and 'kmalloc_array()' are not tested
Add the corresponding check.
[]
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
[]
@@ -7006,9 +7006,9 @@
On Fri, 16 Apr 2021 10:12:58 -0500
Josh Poimboeuf wrote:
> Adding Steven Rostedt (ftrace maintainer).
Thanks.
>
> On Fri, Apr 16, 2021 at 01:39:28PM +0800, zhaoxiao wrote:
> > In preparation for x86 supporting ftrace built on other compiler
> > options, let's have the x86 Makefiles remove the
On Fri, Apr 16, 2021 at 06:40:53PM +0300, Kirill A. Shutemov wrote:
> TDX integrity check failures may lead to system shutdown host kernel must
> not allow any writes to TD-private memory. This requirment clashes with
> KVM design: KVM expects the guest memory to be mapped into host userspace
>
On Fri, Apr 16, 2021 at 03:01:48PM -, tip-bot2 for Kan Liang wrote:
> @@ -2331,6 +2367,9 @@ static void x86_pmu_event_unmapped(struct perf_event
> *event, struct mm_struct *m
> if (!(event->hw.flags & PERF_X86_EVENT_RDPMC_ALLOWED))
> return;
>
> + if
From: Jisheng Zhang
HAVE_MOVE_PUD enables remapping pages at the PUD level if both the source
and destination addresses are PUD-aligned.
HAVE_MOVE_PMD does similar speedup on the PMD level.
With HAVE_MOVE_PUD enabled, there is about a 143x improvement on qemu
With HAVE_MOVE_PMD enabled, there
On Fri, Apr 16, 2021 at 10:42 PM Matthias Brugger
wrote:
>
>
>
> On 15/04/2021 11:35, Hsin-Yi Wang wrote:
> > Kenzo is known as Acer Chromebook 311.
> >
> > Signed-off-by: Hsin-Yi Wang
> > ---
> > Documentation/devicetree/bindings/arm/mediatek.yaml | 6 --
> > 1 file changed, 4
Willow is known as Acer Chromebook 311 (C722/C722T)
Signed-off-by: Hsin-Yi Wang
Reviewed-by: Enric Balletbo i Serra
---
arch/arm64/boot/dts/mediatek/Makefile | 2 ++
.../mt8183-kukui-jacuzzi-willow-sku0.dts | 13 +
.../mt8183-kukui-jacuzzi-willow-sku1.dts | 12
Kenzo is known as Acer Chromebook 311.
Signed-off-by: Hsin-Yi Wang
Reviewed-by: Enric Balletbo i Serra
---
arch/arm64/boot/dts/mediatek/Makefile| 1 +
.../boot/dts/mediatek/mt8183-kukui-jacuzzi-kenzo.dts | 12
2 files changed, 13 insertions(+)
create mode 100644
Burnet is known as HP Chromebook x360 11MK G3 EE
Signed-off-by: Hsin-Yi Wang
Reviewed-by: Enric Balletbo i Serra
---
arch/arm64/boot/dts/mediatek/Makefile | 1 +
.../mediatek/mt8183-kukui-jacuzzi-burnet.dts | 33 +++
2 files changed, 34 insertions(+)
create mode
Kappa is known as HP Chromebook 11a
Signed-off-by: Hsin-Yi Wang
Reviewed-by: Enric Balletbo i Serra
---
arch/arm64/boot/dts/mediatek/Makefile| 1 +
.../dts/mediatek/mt8183-kukui-jacuzzi-kappa.dts | 16
2 files changed, 17 insertions(+)
create mode 100644
Kenzo is known as Acer Chromebook 311.
Signed-off-by: Hsin-Yi Wang
Reviewed-by: Enric Balletbo i Serra
---
Documentation/devicetree/bindings/arm/mediatek.yaml | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/mediatek.yaml
Burnet is known as HP Chromebook x360 11MK G3 EE.
Signed-off-by: Hsin-Yi Wang
Reviewed-by: Enric Balletbo i Serra
---
Documentation/devicetree/bindings/arm/mediatek.yaml | 4
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/mediatek.yaml
Willow is known as Acer Chromebook 311 (C722/C722T).
Signed-off-by: Hsin-Yi Wang
Reviewed-by: Enric Balletbo i Serra
---
Documentation/devicetree/bindings/arm/mediatek.yaml | 7 +++
1 file changed, 7 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/mediatek.yaml
Kappa is known as HP Chromebook 11a.
Signed-off-by: Hsin-Yi Wang
Reviewed-by: Enric Balletbo i Serra
---
Documentation/devicetree/bindings/arm/mediatek.yaml | 4
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/mediatek.yaml
On Thu, 15 Apr 2021 23:07:05 -0700
Dexuan Cui wrote:
> diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c
> index 7349a70af083..f682a5572d84 100644
> --- a/drivers/net/hyperv/netvsc_drv.c
> +++ b/drivers/net/hyperv/netvsc_drv.c
> @@ -2297,6 +2297,7 @@ static struct
On 4/16/2021 4:36 AM, Vitaly Kuznetsov wrote:
struct kvm_vm_stat {
diff --git a/arch/x86/kvm/hyperv.c b/arch/x86/kvm/hyperv.c
index 58fa8c029867..614b4448a028 100644
--- a/arch/x86/kvm/hyperv.c
+++ b/arch/x86/kvm/hyperv.c
I still think that using arch/x86/kvm/hyperv.[ch] for
> From: Casey Schaufler [mailto:ca...@schaufler-ca.com]
> Sent: Thursday, April 15, 2021 10:44 PM
> On 4/15/2021 3:04 AM, Roberto Sassu wrote:
> > This patch set depends on:
> >
> > https://lore.kernel.org/linux-integrity/20210409114313.4073-1-
> roberto.sa...@huawei.com/
> >
On Sat, Apr 17, 2021 at 12:31:44AM +0800, Quanyang Wang wrote:
> Sorry for any confusion caused.
No worries, it's mainly just an issue for anyone doing stable backports
- hopefully they'll figure things out.
signature.asc
Description: PGP signature
On Fri, 16 Apr 2021 03:47:19 PDT (-0700), a...@ghiti.fr wrote:
Hi Anup,
Le 4/16/21 à 6:41 AM, Anup Patel a écrit :
On Thu, Apr 15, 2021 at 4:34 PM Alexandre Ghiti wrote:
If CONFIG_STRICT_KERNEL_RWX is not set, we cannot set different permissions
to the kernel data and text sections, so make
On Fri, Apr 16, 2021 at 04:03:05PM +, codrin.ciubota...@microchip.com wrote:
> Thank you for the links! So basically the machine driver disappears and
> all the components will be visible in user-space.
Not entirely - you still need something to say how they're wired
together but it'll be a
Hi Mark,
Sorry for any confusion caused.
Thanks,
Quanyang
On 4/17/21 12:01 AM, Mark Brown wrote:
On Fri, 16 Apr 2021 22:20:42 +0800, quanyang.w...@windriver.com wrote:
V2:
Remove all "Fixes:" tags since they base on some patches are not
with "Fixes:".
V1:
This series fix some issues that
Hi Linus,
A recent commit (2decad92f473, "arm64: mte: Ensure TIF_MTE_ASYNC_FAULT
is set atomically") broke the kernel build when using the LLVM
integrated assembly (only noticeable with clang-12 as MTE is not
supported by earlier versions and the code in question not compiled).
The Fixes: tag in
On Thu, Apr 15, 2021 at 04:30:22PM +0800, Jiapeng Chong wrote:
> Fix the following clang warning:
>
> drivers/pci/hotplug/shpchp_hpc.c:177:20: warning: unused function
> 'shpc_writeb' [-Wunused-function].
>
> Reported-by: Abaci Robot
> Signed-off-by: Jiapeng Chong
Applied to pci/hotplug for
On 4/16/21 8:40 AM, Kirill A. Shutemov wrote:
> Mirror SEV, use SWIOTLB always if KVM memory protection is enabled.
...
> arch/x86/mm/mem_encrypt.c | 44 ---
> arch/x86/mm/mem_encrypt_common.c | 48 ++
The changelog need to at least
On Fri, Apr 16, 2021 at 02:18:10PM +, Dennis Zhou wrote:
> Hello,
>
> On Fri, Apr 16, 2021 at 06:26:15PM +0530, Pratik Sampat wrote:
> > Hello Roman,
> >
> > I've tried the v3 patch series on a POWER9 and an x86 KVM setup.
> >
> > My results of the percpu_test are as follows:
> > Intel KVM
On Fri, Apr 16, 2021 at 5:43 PM Peter Zijlstra wrote:
>
> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2659.htm
>
> That's just not making any damn sense what so ever. That seems to be
> about sprinkling abort() all over the place, which is just total
> rubbish.
No, it is not about that. It
On Fri, Apr 16, 2021 at 11:58:05AM -0400, Theodore Ts'o wrote:
> Another fairly common use case is a lockless, racy test of a
> particular field, as an optimization before we take the lock before we
> test it for realsies. In this particular case, we can't allocate
> memory while holding a
On Thu, Apr 01, 2021 at 10:24:04PM -0500, madve...@linux.microsoft.com wrote:
> Reliable stacktracing requires that we identify when a stacktrace is
> terminated early. We can do this by ensuring all tasks have a final
> frame record at a known location on their task stack, and checking
> that
On Fri, Apr 16, 2021 at 1:58 AM Andy Shevchenko
wrote:
>
> On Fri, Apr 16, 2021 at 8:28 AM Dan Williams wrote:
> >
> > On Thu, Apr 15, 2021 at 6:59 AM Andy Shevchenko
> > wrote:
> > >
> > > Strictly speaking the comparison between guid_t and raw buffer
> > > is not correct. Import GUID to
On Fri, Apr 16, 2021 at 04:33:51PM +0100, Wedson Almeida Filho wrote:
> On Fri, Apr 16, 2021 at 04:19:07PM +0200, Peter Zijlstra wrote:
> > Does this also not prohibit constructs where modification must be done
> > while holding two locks, but reading can be done while holding either
> > lock?
>
Add support for probing the pinctrl-ingenic driver on the
JZ4775 SoC from Ingenic.
Signed-off-by: 周琰杰 (Zhou Yanjie)
Reviewed-by: Andy Shevchenko
---
Notes:
v3:
New patch.
v3->v4:
1.Split lcd pins into several groups.
2.Drop "lcd-no-pins" which is pointless.
Add support for probing the pinctrl-ingenic driver on the
X2000 SoC from Ingenic.
Signed-off-by: 周琰杰 (Zhou Yanjie)
Reviewed-by: Andy Shevchenko
---
Notes:
v3:
New patch.
v3->v4:
1.Split lcd pins into several groups.
2.Drop "lcd-no-pins" which is pointless.
Add support for probing the pinctrl-ingenic driver on the
JZ4755 SoC from Ingenic.
Signed-off-by: 周琰杰 (Zhou Yanjie)
Reviewed-by: Andy Shevchenko
---
Notes:
v3:
New patch.
v3->v4:
1.Split lcd pins into several groups.
2.Drop "lcd-no-pins" which is pointless.
Add support for probing the pinctrl-ingenic driver on the
JZ4730 SoC from Ingenic.
This driver is derived from Paul Boddie. It is worth to
noting that the JZ4730 SoC is special in having two control
registers (upper/lower), so add code to handle the JZ4730
specific register offsets and some
Add support for probing the pinctrl-ingenic driver on the
JZ4750 SoC from Ingenic.
Signed-off-by: 周琰杰 (Zhou Yanjie)
Reviewed-by: Andy Shevchenko
---
Notes:
v3:
New patch.
v3->v4:
1.Use "lcd-special" and "lcd-generic" instead "lcd-18bit-tft".
2.Drop "lcd-no-pins" which
1.Move the "INGENIC_PIN_GROUP_FUNCS" to the macro definition section.
2.Add tabs before values to align the code in the macro definition section.
Signed-off-by: 周琰杰 (Zhou Yanjie)
Reviewed-by: Andy Shevchenko
Reviewed-by: Paul Cercueil
---
Notes:
v2:
New patch.
v2->v3:
Add
401 - 500 of 1309 matches
Mail list logo
