Ahmad,
On Wed, Mar 17, 2021 at 3:08 PM Ahmad Fatoum wrote:
> TABLE="0 $BLOCKS crypt $ALGO :32:trusted:$KEYNAME 0 $DEV 0 1
> allow_discards"
> echo $TABLE | dmsetup create mydev
> echo $TABLE | dmsetup load mydev
Do you also plan to add support for this to cryptsetup?
David and I
Turbostat fails to correctly collect and display RAPL summary information
on Family 17h and 19h AMD processors. Running turbostat on these processors
returns immediately. If turbostat is working correctly then RAPL summary
data is displayed until the user provided command completes. If a command
On Sun, Mar 28, 2021 at 11:37:23PM +0300, Jarkko Sakkinen wrote:
>
> Unfortunately, TPM trusted keys started this bad security practice, and
> obviously it cannot be fixed without breaking uapi backwards compatibility.
>
The whole point of a randomness source is that it is random. So userspace
On 3/30/21 10:39 PM, Andrii Nakryiko wrote:
On Sun, Mar 28, 2021 at 1:11 AM Kumar Kartikeya Dwivedi
wrote:
On Sun, Mar 28, 2021 at 10:12:40AM IST, Andrii Nakryiko wrote:
Is there some succinct but complete enough documentation/tutorial/etc
that I can reasonably read to understand kernel APIs
Hello,
syzbot found the following issue on:
HEAD commit:93129492 Add linux-next specific files for 20210326
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=1372ce62d0
kernel config: https://syzkaller.appspot.com/x/.config?x=4c9322cd4e3b7a16
dashboard
Turbostat fails to correctly collect and display RAPL summary information
on Family 17h and 19h AMD processors. Running turbostat on these processors
returns immediately. If turbostat is working correctly then RAPL summary
data is displayed until the user provided command completes. If a command
On 3/30/2021 6:39 AM, Ulf Hansson wrote:
On Wed, 24 Mar 2021 at 17:45, Bean Huo wrote:
From: Kimito Sakata
we have been using this erase feature for a while, but it is
still not merged into the upstream mmc-utils. Especially, for
the customer, every time when they update the mmc-utils,
> -Original Message-
> From: yangyicong
> Sent: Wednesday, March 31, 2021 3:19 AM
> To: w...@kernel.org; andriy.shevche...@linux.intel.com;
> linux-...@vger.kernel.org; sergey.se...@baikalelectronics.ru;
> linux-kernel@vger.kernel.org
> Cc: dig...@gmail.com; tred...@nvidia.com;
On 3/30/21 2:30 PM, Aditya Srivastava wrote:
> The opening comment mark '/**' is used for highlighting the beginning of
> kernel-doc comments.
> There are certain files in arch/x86/platform/intel-quark, which follow this
> syntax, but the content inside does not comply with kernel-doc.
> Such
Hi,
On Tue, Mar 30, 2021 at 7:01 AM Ville Syrjälä
wrote:
>
> > @@ -2049,15 +2049,39 @@ struct edid *drm_get_edid(struct drm_connector
> > *connector,
> > struct i2c_adapter *adapter)
> > {
> > struct edid *edid;
> > + size_t old_edid_size;
> > + const
The opening comment mark '/**' is used for highlighting the beginning of
kernel-doc comments.
There are certain files in arch/x86/platform/intel-quark, which follow this
syntax, but the content inside does not comply with kernel-doc.
Such lines were probably not meant for kernel-doc parsing, but
On Tue, Mar 30, 2021 at 11:58:31AM -0700, Roman Gushchin wrote:
> On Tue, Mar 30, 2021 at 11:34:11AM -0700, Shakeel Butt wrote:
> > On Tue, Mar 30, 2021 at 3:20 AM Muchun Song
> > wrote:
> > >
> > > Since the following patchsets applied. All the kernel memory are charged
> > > with the new APIs
Reduce LRU lock contention when inserting shmem pages by staging pages
to be added to the same LRU and adding them en masse.
Signed-off-by: Anthony Yznaga
---
mm/shmem.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/mm/shmem.c b/mm/shmem.c
index
Preserved pages are represented in the memblock reserved list, but page
structs for pages in the reserved list are initialized early while boot
is single threaded which means that a large number of preserved pages
can impact boot time. To mitigate, defer initialization of preserved
pages by
On Mon, Mar 29, 2021 at 2:55 AM Peter Zijlstra wrote:
>
> OK, fixed the fails. My tired head made it unconditionally return the
> cookie-id of 'current' instead of task. Pushed out an update.
I see you have the per-task and prctl stuff pulled into your tree. I
can rebase the compound cookie and
Rather than adding one page at a time to the page cache and taking the
page cache xarray lock each time, where possible add pages in bulk by
first populating an xarray node outside of the page cache before taking
the lock to insert it.
When a group of pages to be inserted will fill an xarray node,
Contention on the xarray lock when multiple threads are adding to the
same xarray can be mitigated by providing a way to add entries in
bulk.
Allow a caller to allocate and populate an xarray node outside of
the target xarray and then only take the xarray lock long enough to
import the node into
On 3/30/21 12:11 PM, Hao Sun wrote:
> Hi
>
> When using Healer(https://github.com/SunHao-0/healer/tree/dev) to fuzz
> the Linux kernel, I found a use-after-free vulnerability in
> macvlan_broadcast.
> Hope the report can help you locate the problem.
>
> Details:
> commit: 5695e5161 Linux
To take advantage of optimizations when adding pages to the page cache
via shmem_insert_pages(), improve the likelihood that the pages array
passed to shmem_insert_pages() starts on an aligned index. Do this
when preserving pages by starting a new pkram_link page when the current
page is aligned
Ahmad,
On Wed, Mar 17, 2021 at 3:03 PM Ahmad Fatoum wrote:
> > I didn't closely follow the previous discussions, but is a module
> > parameter really the right approach?
> > Is there also a way to set it via something like device tree?
>
> Compiled-on sources are considered in the order: tpm,
shmem_insert_pages() currently loops over the array of pages passed
to it and calls shmem_add_to_page_cache() for each one. Prepare
for adding pages to the pagecache in bulk by adding and using a
shmem_add_pages_to_cache() call. For now it just iterates over
an array and adds pages individually,
Implement a new API function, pkram_load_file_pages(), to support
loading pages in bulk. A caller provided buffer not smaller than
PKRAM_PAGES_BUFSIZE is populated with pages pointers that are contiguous
by their original mapping index values. The number of pages in the buffer
and the mapping
Considerable contention on the LRU lock happens when multiple threads
are used to insert pages into a shmem file in parallel. To alleviate this
provide a way for pages to be added to the same LRU to be staged so that
they can be added by splicing lists and updating stats once with the lock
held.
Work around the limitation that shmem pages must be in memory in order
to be preserved by preventing them from being swapped out in the first
place. Do this by marking shmem pages associated with a PKRAM node
as unevictable.
Signed-off-by: Anthony Yznaga
---
mm/shmem.c | 2 ++
1 file changed,
Improve performance by multithreading the work to preserve and restore
shmem pages.
When preserving pages each thread saves non-overlapping ranges of a file
to a pkram_obj until all pages are preserved.
When restoring pages each thread loads pages using a local pkram_access.
Signed-off-by:
Calling shmem_insert_page() to insert one page at a time does
not scale well when multiple threads are inserting pages into
the same shmem segment. This is primarily due to the locking needed
when adding to the pagecache and LRU but also due to contention
on the shmem_inode_info lock. To address
Make use of new interfaces for loading and inserting preserved pages
into a shmem file in bulk.
Signed-off-by: Anthony Yznaga
---
mm/shmem_pkram.c | 23 +--
1 file changed, 17 insertions(+), 6 deletions(-)
diff --git a/mm/shmem_pkram.c b/mm/shmem_pkram.c
index
To support deferred initialization of page structs for preserved pages,
separate memblocks containing preserved pages by setting a new flag
when adding them to the memblock reserved list.
Signed-off-by: Anthony Yznaga
---
include/linux/memblock.h | 6 ++
mm/pkram.c | 2 ++
2
Add and remove pkram_link pages from a pkram_obj atomically to prepare
for multithreading.
Signed-off-by: Anthony Yznaga
---
mm/pkram.c | 39 ---
1 file changed, 24 insertions(+), 15 deletions(-)
diff --git a/mm/pkram.c b/mm/pkram.c
index
The kdump kernel should not preserve or restore pages.
Signed-off-by: Anthony Yznaga
---
mm/pkram.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/mm/pkram.c b/mm/pkram.c
index 8700fd77dc67..aea069cc49be 100644
--- a/mm/pkram.c
+++ b/mm/pkram.c
@@ -1,4 +1,5 @@
//
In order to facilitate fast initialization of page structs for
preserved pages, memblocks with preserved pages must not cross
numa node boundaries and must have a node id assigned to them.
Signed-off-by: Anthony Yznaga
---
mm/pkram.c | 9 +
1 file changed, 9 insertions(+)
diff --git
If shmem_insert_page() is called to insert a page that was preserved
using PKRAM on the current boot (i.e. preserved page is restored without
an intervening kexec boot), the page will still be charged to a memory
cgroup because it is never freed. Don't try to charge it again.
Signed-off-by:
Calling memblock_reserve() repeatedly to add preserved ranges is
inefficient and risks clobbering preserved memory if the memblock
reserved regions array must be resized. Instead, calculate the size
needed to accomodate the preserved ranges, find a suitable range for
a new reserved regions array
When pages have been saved to be preserved by the current boot, set
a magic number on the super block to be validated by the next kernel.
Signed-off-by: Anthony Yznaga
---
mm/pkram.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/mm/pkram.c b/mm/pkram.c
index
To prepare for multithreading the work to preserve a shmem file,
divide the work into subranges of the total index range of the file.
The chunk size is a rather arbitrary 256k indices.
Signed-off-by: Anthony Yznaga
---
mm/shmem_pkram.c | 64
Provide a way for a caller external to numa to ensure memblocks in the
memblock reserved list do not cross node boundaries and have a node id
assigned to them. This will be used by PKRAM to ensure initialization of
page structs for preserved pages can be deferred and multithreaded
efficiently.
This patch illustrates how the PKRAM API can be used for preserving tmpfs.
Two options are added to tmpfs:
The 'pkram=' option specifies the PKRAM node to load/save the
filesystem tree from/to.
The 'preserve' option initiates preservation of a read-only
filesystem tree.
If the
The function inserts a page into a shmem file at a specified offset.
The page can be a regular PAGE_SIZE page or a transparent huge page.
If there is something at the offset (page or swap), the function fails.
The function will be used by the next patch.
Originally-by: Vladimir Davydov
pkram kaslr code can incur multiple page faults when it walks its
preserved ranges list called via mem_avoid_overlap(). The multiple
faults can easily end up using up the small number of pages available
to be allocated for page table pages.
This patch hacks things so that mappings are 1GB which
Explicitly specify the mm to pass to shmem_insert_page() when
the pkram_stream is initialized rather than use the mm of the
current thread. This will allow for multiple kernel threads to
target the same mm when inserting pages in parallel.
Signed-off-by: Anthony Yznaga
---
mm/shmem_pkram.c | 6
Ensure destination ranges of the kexec segments do not overlap
with any kernel pages marked to be preserved across kexec.
For kexec_load, return EADDRNOTAVAIL if overlap is detected.
For kexec_file_load, skip ranges containing preserved pages when
seaching for available ranges to use.
In order to build a new memblock reserved list during boot that
includes ranges preserved by the previous kernel, a list of preserved
ranges is passed to the next kernel via the pkram superblock. The
ranges are stored in ascending order in a linked list of pages. A more
complete memblock list is
To free all space utilized for preserved memory, one can write 0 to
/sys/kernel/pkram. This will destroy all PKRAM nodes that are not
currently being read or written.
Originally-by: Vladimir Davydov
Signed-off-by: Anthony Yznaga
---
mm/pkram.c | 39 ++-
1
Avoid regions of memory that contain preserved pages when computing
slots used to select where to put the decompressed kernel.
Signed-off-by: Anthony Yznaga
---
arch/x86/boot/compressed/Makefile | 3 ++
arch/x86/boot/compressed/kaslr.c | 10 +++-
arch/x86/boot/compressed/misc.h | 10
Later patches in this series will need a way to efficiently identify
physically contiguous ranges of preserved pages independent of their
virtual addresses. To facilitate this all pages to be preserved across
kexec are added to a pseudo identity mapping pagetable.
The pagetable makes use of the
When a kernel is loaded for kexec the address ranges where the kexec
segments will be copied to may conflict with pages already set to be
preserved. Provide a way to determine if preserved pages exist in a
specified range.
Signed-off-by: Anthony Yznaga
---
include/linux/pkram.h | 2 ++
When loading a kernel for kexec, dynamically update the list of physical
ranges that are not to be used for storing preserved pages with the ranges
where kexec segments will be copied to on reboot. This ensures no pages
preserved after the new kernel has been loaded will reside in these ranges
on
Free the pages used to pass the preserved ranges to the new boot.
Signed-off-by: Anthony Yznaga
---
arch/x86/mm/init_64.c | 1 +
include/linux/pkram.h | 2 ++
mm/pkram.c| 20
3 files changed, 23 insertions(+)
diff --git a/arch/x86/mm/init_64.c
Since page structs are used for linking PKRAM nodes and cleared
on boot, organize all PKRAM nodes into a list singly-linked by pfns
before reboot to facilitate restoring the node list in the new kernel.
Originally-by: Vladimir Davydov
Signed-off-by: Anthony Yznaga
---
mm/pkram.c | 50
Preserved memory is divided into nodes which can be saved and loaded
independently of each other. PKRAM nodes are kept on a list and
identified by unique names. Whenever a save operation is initiated by
calling pkram_prepare_save(), a new node is created and linked to the
list. When the save
PKRAM nodes are further divided into a list of objects. After a save
operation has been initiated for a node, a save operation for an object
associated with the node is initiated by calling pkram_prepare_save_obj().
A new object is created and linked to the node. The save operation for
the object
This patch adds the ability to save an arbitrary byte streams to a
a PKRAM object using pkram_write() to be restored later using pkram_read().
Originally-by: Vladimir Davydov
Signed-off-by: Anthony Yznaga
---
include/linux/pkram.h | 11 +
mm/pkram.c| 123
This patchset implements preserved-over-kexec memory storage or PKRAM as a
method for saving memory pages of the currently executing kernel so that
they may be restored after kexec into a new kernel. The patches are adapted
from an RFC patchset sent out in 2013 by Vladimir Davydov [1]. They
Preserved-across-kexec memory or PKRAM is a method for saving memory
pages of the currently executing kernel and restoring them after kexec
boot into a new one. This can be utilized for preserving guest VM state,
large in-memory databases, process memory, etc. across reboot. While
DRAM-as-PMEM or
Using the pkram_save_file_page() function, one can populate PKRAM objects
with in-memory pages which can later be loaded using the pkram_load_file_page()
function. Saving a page to PKRAM is accomplished by recording its pfn and
mapping index and incrementing its refcount so that it will not be
The PKRAM super block is the starting point for restoring preserved
memory. By providing the super block to the new kernel at boot time,
preserved memory can be reserved and made available to be restored.
To point the kernel to the location of the super block, one passes
its pfn via the 'pkram'
Support preserving a transparent hugepage by recording the page order and
a flag indicating it is a THP. Use these values when the page is
restored to reconstruct the THP.
Signed-off-by: Anthony Yznaga
---
mm/pkram.c | 20
1 file changed, 16 insertions(+), 4 deletions(-)
Keep preserved pages from being recycled during boot by adding them
to the memblock reserved list during early boot. If memory reservation
fails (e.g. a region has already been reserved), all preserved pages
are dropped.
Signed-off-by: Anthony Yznaga
---
arch/x86/kernel/setup.c | 3 ++
Not all memory ranges can be used for saving preserved over-kexec data.
For example, a kexec kernel may be loaded before pages are preserved.
The memory regions where the kexec segments will be copied to on kexec
must not contain preserved pages or else they will be clobbered.
Originally-by:
Steve Royer has moved on to a different project and has asked
that Ritu and I take over maintainership of the IBM Power
Virtual Management Channel Driver.
Signed-off-by: Brad Warrum
---
MAINTAINERS | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
On 3/30/21 2:18 PM, Aditya Srivastava wrote:
> The opening comment mark '/**' is used for highlighting the beginning of
> kernel-doc comments.
> There are certain files in arch/x86/kernel/cpu/sgx, which follow this
> syntax, but the content inside does not comply with kernel-doc.
> Such lines were
On Tue, Mar 30, 2021 at 2:29 AM Peter Zijlstra wrote:
> > On Wed, Mar 24, 2021 at 05:40:17PM -0400, Joel Fernandes (Google) wrote:
> > > +
> > > + if (!tg->core_tagged && val) {
> > > + /* Tag is being set. Check ancestors and descendants. */
> > > + if
Hi,
On Wed, Mar 24, 2021 at 10:45 PM Rajendra Nayak wrote:
>
> @@ -111,6 +113,15 @@ static const struct qfprom_soc_compatible_data
> sc7180_qfprom = {
> .nkeepout = ARRAY_SIZE(sc7180_qfprom_keepout)
> };
>
> +static const struct nvmem_keepout sc7280_qfprom_keepout[] = {
> +
The opening comment mark '/**' is used for highlighting the beginning of
kernel-doc comments.
There are certain files in arch/x86/kernel/cpu/sgx, which follow this
syntax, but the content inside does not comply with kernel-doc.
Such lines were probably not meant for kernel-doc parsing, but are
On Mon, Mar 29, 2021 at 08:52:35AM +0700, Quan Nguyen wrote:
> Adds device tree bindings for SMPro drivers found on the Mt.Jade hardware
> reference platform with Ampere's Altra Processor family.
>
> Signed-off-by: Quan Nguyen
> ---
> .../bindings/hwmon/ampere,ac01-hwmon.yaml | 27 ++
>
On Thu, Mar 25, 2021 at 03:30:20PM +0100, Jan Kara wrote:
Sasha, just be aware that this commit was added to help tracking down a
particular syzbot report. As such there's no point in carrying it in
-stable but there's no big harm either... Just one patch more.
Yup, I'd rather keep it to see
On Thu, Mar 25, 2021 at 01:08:02PM +0100, David Sterba wrote:
On Thu, Mar 25, 2021 at 07:24:41AM -0400, Sasha Levin wrote:
From: Qu Wenruo
[ Upstream commit fbf48bb0b197e6894a04c714728c952af7153bf3 ]
There is a piece of weird code in insert_prealloc_file_extent(), which
looks like:
On 12:43 Tue 30 Mar 2021, Robin Murphy wrote:
On 2021-03-29 00:53, Bhaskar Chowdhury wrote:
s/Synopsys/Synopsis/ .two different places.
Erm, that is definitely not a typo... :/
..and for some unknown reason it introduce a empty line deleted and added
back.
Presumably your editor is
On 22:59 Tue 30 Mar 2021, Vinod Koul wrote:
On 29-03-21, 05:23, Bhaskar Chowdhury wrote:
s/transferred/transfered/
This reverts commit a2ddb8aea8106bd5552f8516ad7a8a26b9282a8f.
This is not upstream, why not squash in. Also would make sense to write
sensible changelog and not phrases and use
Andrii Nakryiko writes:
> On Sun, Mar 28, 2021 at 1:11 AM Kumar Kartikeya Dwivedi
> wrote:
>>
>> On Sun, Mar 28, 2021 at 10:12:40AM IST, Andrii Nakryiko wrote:
>> > Is there some succinct but complete enough documentation/tutorial/etc
>> > that I can reasonably read to understand kernel APIs
Hello:
This patch was applied to bpf/bpf-next.git (refs/heads/master):
On Fri, 26 Mar 2021 19:43:48 + you wrote:
> From: Colin Ian King
>
> The variable id is being assigned a value that is never
> read, the assignment is redundant and can be removed.
>
> Addresses-Coverity: ("Unused
On Tue, Mar 30, 2021 at 11:34:11AM -0700, Shakeel Butt wrote:
> On Tue, Mar 30, 2021 at 3:20 AM Muchun Song wrote:
> >
> > Since the following patchsets applied. All the kernel memory are charged
> > with the new APIs of obj_cgroup.
> >
> > [v17,00/19] The new cgroup slab memory
On Tue, Mar 30, 2021 at 03:30:54PM -0400, Johannes Weiner wrote:
> Hi Willy,
>
> On Mon, Mar 29, 2021 at 05:58:32PM +0100, Matthew Wilcox wrote:
> > I'm going to respond to some points in detail below, but there are a
> > couple of overarching themes that I want to bring out up here.
> >
> >
On Tue, Mar 30, 2021 at 12:09 PM Rob Herring wrote:
>
> On Tue, Mar 30, 2021 at 10:31 AM Will Deacon wrote:
> >
> > On Wed, Mar 10, 2021 at 05:08:29PM -0700, Rob Herring wrote:
> > > From: Raphael Gault
> > >
> > > Keep track of event opened with direct access to the hardware counters
> > > and
syzbot has found a reproducer for the following issue on:
HEAD commit:37f368d8 lan743x: remove redundant intializations of point..
git tree: net-next
console output: https://syzkaller.appspot.com/x/log.txt?x=11ede3bed0
kernel config:
On 3/30/21 1:59 PM, Aditya Srivastava wrote:
> The opening comment mark '/**' is used for highlighting the beginning of
> kernel-doc comments.
> The header for arch/arm/mach-omap2/omap_twl.c follows this syntax, but the
> content inside does not comply with kernel-doc.
>
> This line was probably
On 3/30/21 1:53 PM, Aditya Srivastava wrote:
> The opening comment mark '/**' is used for highlighting the beginning of
> kernel-doc comments.
> The header for arch/arm/mach-omap1/timer.c follows this syntax, but the
> content inside does not comply with kernel-doc.
>
> This line was probably not
On 3/30/21 1:44 PM, Aditya Srivastava wrote:
> The opening comment mark '/**' is used for highlighting the beginning of
> kernel-doc comments.
> The header for arch/arm/mach-sa1100/jornada720_ssp.c follows this syntax,
> but the content inside does not comply with kernel-doc.
>
> This line was
On Tue, Mar 30, 2021 at 12:52 PM Jason Gunthorpe wrote:
>
> On Tue, Mar 30, 2021 at 12:43:15PM -0700, Dan Williams wrote:
>
> > Ok, so this is the disagreement. Strict adherence to the model where
> > it does not matter in practice.
>
> The basic problem is that it is hard to know if it does not
Hello:
This patch was applied to bpf/bpf-next.git (refs/heads/master):
On Tue, 30 Mar 2021 02:48:43 + you wrote:
> Remove unused bpf_load_pointer function in filter.h
>
> Signed-off-by: He Fengqing
> ---
> include/linux/filter.h | 9 -
> 1 file changed, 9 deletions(-)
Here is the
The opening comment mark '/**' is used for highlighting the beginning of
kernel-doc comments.
The header for arch/arm/mach-omap2/omap_twl.c follows this syntax, but the
content inside does not comply with kernel-doc.
This line was probably not meant for kernel-doc parsing, but is parsed
due to
For validating the stack offset behavior, report the offset from a given
process's first seen stack address. A quick way to measure the entropy:
for i in $(seq 1 1000); do
echo "REPORT_STACK" >/sys/kernel/debug/provoke-crash/DIRECT
done
offsets=$(dmesg | grep 'Stack offset' | cut -d: -f3
Allow for a randomized stack offset on a per-syscall basis, with roughly
5 bits of entropy. (And include AAPCS rationale AAPCS thanks to Mark
Rutland.)
In order to avoid unconditional stack canaries on syscall entry (due to
the use of alloca()), also disable stack protector to avoid triggering
This provides the ability for architectures to enable kernel stack base
address offset randomization. This feature is controlled by the boot
param "randomize_kstack_offset=on/off", with its default value set by
CONFIG_RANDOMIZE_KSTACK_OFFSET_DEFAULT.
This feature is based on the original idea
The state of CONFIG_INIT_ON_ALLOC_DEFAULT_ON (and ...ON_FREE...) did not
change the assembly ordering of the static branches: they were always out
of line. Use the new jump_label macros to check the CONFIG settings to
default to the "expected" state, which slightly optimizes the resulting
assembly
Allow for a randomized stack offset on a per-syscall basis, with roughly
5-6 bits of entropy, depending on compiler and word size. Since the
method of offsetting uses macros, this cannot live in the common entry
code (the stack offset needs to be retained for the life of the syscall,
which means
v8:
- switch to __this_cpu_*() (tglx)
- improve commit log details, comments, and masking (ingo, tglx)
v7: https://lore.kernel.org/lkml/20210319212835.3928492-1-keesc...@chromium.org/
v6: https://lore.kernel.org/lkml/20210315180229.1224655-1-keesc...@chromium.org/
v5:
As shown in jump_label.h[1], choosing the initial state of static
branches changes the assembly layout. If the condition is expected to
be likely it's inline, and if unlikely it is out of line via a jump. A
few places in the kernel use (or could be using) a CONFIG to choose the
default state,
On 3/30/21 1:25 PM, Chris Packham wrote:
> My bad. I'll send a patch shortly
>
No need. I patched it up already.
Thanks,
Guenter
> On 30/03/21 8:27 pm, Stephen Rothwell wrote:
>> Hi all,
>>
>> After merging the hwmon-staging tree, today's linux-next build (htmldocs)
>> produced this warning:
On Mon, Mar 29, 2021 at 04:41:31PM -0700, Axel Rasmussen wrote:
> Previously, we shared too much of the code with COPY and ZEROPAGE, so we
> manipulated things in various invalid ways:
>
> - Previously, we unconditionally called shmem_inode_acct_block. In the
> continue case, we're looking up
From: Cristian Birsan
This patch adds initial driver support for the new Microchip USB
Type-C Port Controller (TCPC) embedded in sama7g5 SoC.
Signed-off-by: Cristian Birsan
---
drivers/usb/typec/tcpm/Kconfig| 8 +
drivers/usb/typec/tcpm/Makefile | 1 +
From: Cristian Birsan
This patch adds DT bindings for the new Microchip USB Type-C Port
Controller (TCPC) embedded in sama7g5 SoC.
Signed-off-by: Cristian Birsan
---
.../bindings/usb/microchip,sama7g5-tcpc.yaml | 90 +++
1 file changed, 90 insertions(+)
create mode 100644
From: Cristian Birsan
This patch set adds initial driver support for Microchip USB Type-C Port
Controller (TCPC) embedded in sama7g5 SoC.
The controller does not implement power delivery and the driver uses dummy
functions to register the port with TCPM. The current silicon version is
not able
The opening comment mark '/**' is used for highlighting the beginning of
kernel-doc comments.
The header for arch/arm/mach-omap1/timer.c follows this syntax, but the
content inside does not comply with kernel-doc.
This line was probably not meant for kernel-doc parsing, but is parsed
due to the
On 2020-09-10 13:46:27, Bjorn Helgaas wrote:
> On Thu, Sep 10, 2020 at 08:21:06AM -0600, Rob Herring wrote:
> > On Wed, Sep 9, 2020 at 8:07 PM Bjorn Helgaas wrote:
> > >
> > > [+cc Mark, Florian, Rob, Scott]
> > >
> > > On Sat, Aug 01, 2020 at 09:25:49AM +0800, Xingxing Su wrote:
> > > > Do not
New compatible are added, supporting various kind of clkgen-fsyn
used for STiH407, STiH410 and STiH418
Signed-off-by: Alain Volmat
---
Documentation/devicetree/bindings/clock/st/st,quadfs.txt | 3 +++
1 file changed, 3 insertions(+)
diff --git
In order to avoid relying on the old style description via the DT
clock-output-names, add compatible data describing the flexgen
outputs clocks for all STiH407/STiH410 and STiH418 SOCs.
In order to ease transition between the two methods, this commit
introduce the new compatible without removing
New compatible are added, supporting various kind of clkgen-pll
used for STiH407, STiH410 and STiH418
Signed-off-by: Alain Volmat
Acked-by: Rob Herring
---
Documentation/devicetree/bindings/clock/st/st,clkgen-pll.txt | 3 +++
1 file changed, 3 insertions(+)
diff --git
New compatible are added, supporting various kind of flexgen in
STiH407, STiH410 and STiH418
Signed-off-by: Alain Volmat
Acked-by: Rob Herring
---
.../devicetree/bindings/clock/st/st,flexgen.txt| 10 ++
1 file changed, 10 insertions(+)
diff --git
In order to avoid relying on the old style description via the DT
clock-output-names, add compatible data describing the flexgen
outputs clocks for all STiH407/STiH410 and STiH418 SOCs.
In order to ease transition between the two methods, this commit
introduce the new compatible without removing
301 - 400 of 1503 matches
Mail list logo
