MIPS and ARM64 don't implement find_first_{zero}_bit in arch code and
don't enable it in config. It leads to using find_next_bit() which is
less efficient:
It's beneficial to enable GENERIC_FIND_FIRST_BIT as this functionality
is not new at all and well-tested. It provides more optimized code and
On 29/01/2021 12:03, Robin Murphy wrote:
On 2021-01-29 09:48, Leizhen (ThunderTown) wrote:
Currently, we are thinking about the solution to the problem. However,
because the end time of v5.11 is approaching, this patch is sent first.
However, that commit was made for a reason - how do we jus
On Thu, 25 Feb 2021 12:59:20 +,
Will Deacon wrote:
>
> The built-in kernel commandline (CONFIG_CMDLINE) can be configured in
> three different ways:
>
> 1. CMDLINE_FORCE: Use CONFIG_CMDLINE instead of any bootloader args
> 2. CMDLINE_EXTEND: Append the bootloader args to CONFIG_CMDLINE
>
From: Junlin Yang
The variable "delay" is initialized to zero and then returned.
So remove the delay variable and return zero.
Generated by:scripts/coccinelle/misc/returnvar.cocci
Signed-off-by: Junlin Yang
---
drivers/input/serio/i8042.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-
Hi Richard,
Am Di., 23. Feb. 2021 um 17:11 Uhr schrieb Richard Cochran
:
>
> On Tue, Feb 23, 2021 at 04:04:16PM +0100, Heiko Thiery wrote:
> > It is not only the PHC clock that stops. Rather, it is the entire
> > ethernet building block in the SOC that is disabled, including the
> > PHC.
>
> Sure,
On 25.02.21 14:38, Arnd Bergmann wrote:
From: Arnd Bergmann
The inlining logic in clang-13 is rewritten to often not inline
some functions that were inlined by all earlier compilers.
In case of the memblock interfaces, this exposed a harmless bug
of a missing __init annotation:
WARNING: modpo
On Thu, Feb 25, 2021 at 11:10:00AM +0100, Sedat Dilek wrote:
> On Wed, Feb 24, 2021 at 4:38 PM Jiri Olsa wrote:
> >
> > Arnaldo reported issue for following build command:
> >
> > $ rm -rf /tmp/krava; mkdir /tmp/krava; make O=/tmp/krava clean
> > CLEANconfig
> > /bin/sh: line 0: cd: /t
From: Arnd Bergmann
The added device_property_present() call causes a build
failure in some configurations because of the missing header:
drivers/rtc/rtc-tps65910.c:422:7: error: implicit declaration of function
'device_property_present' [-Werror,-Wimplicit-function-declaration]
Fixes: 454ba15
Hi Yang,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on regulator/for-next]
[also build test WARNING on v5.11 next-20210225]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--bas
Document the basic policies of the media subsystem profile.
Signed-off-by: Mauro Carvalho Chehab
---
v2: fix the Documentation/*/media directories
Documentation/driver-api/media/index.rst | 2 +
.../media/maintainer-entry-profile.rst| 161 ++
.../maintainer/main
Building the documentation gives a warning that the KVM_PPC_RESIZE_HPT_PREPARE
label is defined twice. The root cause is that the KVM_PPC_RESIZE_HPT_PREPARE
API is present twice, the second being a mix of the prepare and commit APIs.
Fix it.
Signed-off-by: Paolo Bonzini
---
Documentation/virt/k
From: Arnd Bergmann
Without CPU hotplug, acrn fails to build:
drivers/virt/acrn/hsm.c:389:3: error: implicit declaration of function
'remove_cpu' [-Werror,-Wimplicit-function-declaration]
remove_cpu(cpu);
^
drivers/virt/acrn/hsm.c:402:2: error: implicit declarati
From: Arnd Bergmann
The inlining logic in clang-13 is rewritten to often not inline
some functions that were inlined by all earlier compilers.
In case of the memblock interfaces, this exposed a harmless bug
of a missing __init annotation:
WARNING: modpost: vmlinux.o(.text+0x507c0a): Section mis
Document the basic policies of the media subsystem profile.
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/driver-api/media/index.rst | 2 +
.../media/maintainer-entry-profile.rst| 159 ++
.../maintainer/maintainer-entry-profile.rst | 1 +
3 files chang
From: Heiko Stuebner
The vendor-kernel did increase the minimum voltage for some low frequency
opps to 825mV citing stability reasons. So do that in mainline as well
and also use the ranged notation the vendor-kernel switched to, to give
a bit more flexibility for different regulator setups.
Sig
On Thu, Feb 25, 2021 at 04:06:23PM +0800, Jin, Yao wrote:
> Hi Chris, Arnaldo, Jiri,
>
> We observe the parsing error for "software/xxx/" on some platforms.
>
> For example,
>
> # perf stat -e software/r1a/ -a -- sleep 1
> event syntax error: 'software/r1a/'
> \___ parser er
From: Heiko Stuebner
We're using OPPs with a range now, so the fact that the cpu regulator
on puma can't provide the needed 5mV steps requested in the minimal
voltage values can be handled automatically by the opp framework.
Signed-off-by: Heiko Stuebner
---
arch/arm64/boot/dts/rockchip/rk3399
From: Heiko Stuebner
Similar to the cpu opps, also use opps with a range on the gpu.
(min, preferred, max). The voltage just needs to be higher than
the minimum and this allows the regulator more freedom if it
can't provide the exact voltage specified, but just say 5mV higher,
as can be seen on r
On Thu, Feb 25, 2021 at 10:46:56AM +0100, Peter Zijlstra wrote:
> On Wed, Feb 24, 2021 at 10:29:13AM -0600, Josh Poimboeuf wrote:
> > Standardize the crypto asm to make it resemble compiler-generated code,
> > so that objtool can understand it.
> >
> > This magically enables ORC unwinding from cry
The first patch is a fix that is targeted for stable.
Tom
On 2/25/21 5:07 AM, Gong, Richard wrote:
> Hi Moritz,
>
> Sorry for asking.
>
> When you have chance, can you help review the version 5 patchset submitted on
> 02/09/21?
>
> Regards,
> Richard
>
> -Original Message-
> From: richar
On Thu, Feb 25, 2021 at 11:32:08AM +0100, Daniel Vetter wrote:
> On Thu, Feb 25, 2021 at 11:25:20AM +0100, Gerd Hoffmann wrote:
> > On Thu, Feb 25, 2021 at 10:09:42AM +0100, Daniel Vetter wrote:
> > > On Wed, Feb 24, 2021 at 11:55 AM Sumera Priyadarsini
> > > wrote:
> > > >
> > > > Add a virtual h
According to latest errata of J721e [1], HS400 mode is not supported
in MMCSD0 subsystem (i2024) and SDR104 mode is not supported in MMCSD1/2
subsystems (i2090). Therefore, replace mmc-hs400-1_8v with mmc-hs200-1_8v
in MMCSD0 subsystem and add a sdhci mask to disable SDR104 speed mode.
Also, updat
On Thu, 25 Feb 2021 12:36:07 +0800
Jason Wang wrote:
> On 2021/2/24 7:12 下午, Cornelia Huck wrote:
> > On Wed, 24 Feb 2021 17:29:07 +0800
> > Jason Wang wrote:
> >
> >> On 2021/2/23 6:58 下午, Cornelia Huck wrote:
> >>> On Tue, 23 Feb 2021 18:31:07 +0800
> >>> Jason Wang wrote:
> The pro
When the "struct page size" crosses page boundaries we cannot
make use of this feature. Let free_vmemmap_pages_per_hpage()
return zero if that is the case, most of the functions can be
optimized away.
Signed-off-by: Muchun Song
Reviewed-by: Miaohe Lin
Reviewed-by: Oscar Salvador
---
include/li
For HugeTLB page, there are more metadata to save in the struct page.
But the head struct page cannot meet our needs, so we have to abuse
other tail struct page to store the metadata. In order to avoid
conflicts caused by subsequent use of more tail struct pages, we can
gather these discrete indexe
Because we reuse the first tail vmemmap page frame and remap it
with read-only, we cannot set the PageHWPosion on some tail pages.
So we can use the head[4].private (There are at least 128 struct
page structures associated with the optimized HugeTLB page, so
using head[4].private is safe) to record
All the infrastructure is ready, so we introduce nr_free_vmemmap_pages
field in the hstate to indicate how many vmemmap pages associated with
a HugeTLB page that can be freed to buddy allocator. And initialize it
in the hugetlb_vmemmap_init(). This patch is actual enablement of the
feature.
Signed
Add a kernel parameter hugetlb_free_vmemmap to enable the feature of
freeing unused vmemmap pages associated with each hugetlb page on boot.
We disables PMD mapping of vmemmap pages for x86-64 arch when this
feature is enabled. Because vmemmap_remap_free() depends on vmemmap
being base page mapped
When we free a HugeTLB page to the buddy allocator, we should allocate
the vmemmap pages associated with it. But we may cannot allocate vmemmap
pages when the system is under memory pressure, in this case, we just
refuse to free the HugeTLB page instead of looping forever trying to
allocate the pag
Move bootmem info registration common API to individual bootmem_info.c.
And we will use {get,put}_page_bootmem() to initialize the page for the
vmemmap pages or free the vmemmap pages to buddy in the later patch.
So move them out of CONFIG_MEMORY_HOTPLUG_SPARSE. This is just code
movement without a
Every HugeTLB has more than one struct page structure. We __know__ that
we only use the first 4(HUGETLB_CGROUP_MIN_ORDER) struct page structures
to store metadata associated with each HugeTLB.
There are a lot of struct page structures associated with each HugeTLB
page. For tail pages, the value of
The option HUGETLB_PAGE_FREE_VMEMMAP allows for the freeing of
some vmemmap pages associated with pre-allocated HugeTLB pages.
For example, on X86_64 6 vmemmap pages of size 4KB each can be
saved for each 2MB HugeTLB page. 4094 vmemmap pages of size 4KB
each can be saved for each 1GB HugeTLB page.
Hi all,
This patch series will free some vmemmap pages(struct page structures)
associated with each hugetlbpage when preallocated to save memory.
In order to reduce the difficulty of the first version of code review.
>From this version, we disable PMD/huge page mapping of vmemmap if this
feature
On Thu, Feb 25, 2021 at 12:19:18PM +0100, Fabrice Gasnier wrote:
> On 2/19/21 10:59 AM, William Breathitt Gray wrote:
> > When in SLAVE_MODE_DISABLED mode, the count still increases if the
> > counter is enabled because an internal clock is used. This patch fixes
> > the stm32_count_function_get()
On Thu, Feb 25, 2021 at 1:42 PM Borislav Petkov wrote:
>
> On Thu, Feb 25, 2021 at 01:18:21PM +0100, Arnd Bergmann wrote:
> > Either way works correctly, I don't care much, but picked the __init
> > annotation as it seemed more intuitive. If the compiler decides to
> > make it out-of-line for what
Set the maximum DIE per package variable on Hygon using the
nodes_per_socket value in order to do per-DIE manipulations
by driver such as powercap.
Signed-off-by: Pu Wen
---
arch/x86/kernel/cpu/hygon.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/cpu/hy
Hi Miquel,
On Thu, Feb 25, 2021 at 08:47:02AM +0100, Miquel Raynal wrote:
> Hi Manivannan,
>
> Manivannan Sadhasivam wrote on Thu,
> 25 Feb 2021 09:41:29 +0530:
>
> > On a typical end product, a vendor may choose to secure some regions in
> > the NAND memory which are supposed to stay intact be
Enable Hygon Fam18h RAPL support for the power capping framework.
Signed-off-by: Pu Wen
---
drivers/powercap/intel_rapl_common.c | 1 +
drivers/powercap/intel_rapl_msr.c| 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/powercap/intel_rapl_common.c
b/drivers/powercap/intel_rapl_c
Hi Yang,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on regulator/for-next]
[also build test WARNING on v5.11 next-20210225]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--bas
On Thu, Feb 25, 2021 at 08:08:32PM +0800, Shengjiu Wang wrote:
> If sound card doesn't need specific codec device, just
> dummy codec is enough, then we can link the dummy component
> directly.
This is a big red flag - what circumstances are these? If it's a simple
CODEC with no control then the
On Wed, Feb 24, 2021 at 09:59:12AM -0800, Ira Weiny wrote:
> On Wed, Feb 24, 2021 at 01:30:49PM +0100, David Sterba wrote:
> > On Tue, Feb 23, 2021 at 11:25:06AM -0800, Ira Weiny wrote:
> > > On Tue, Feb 23, 2021 at 09:13:42AM -0800, Linus Torvalds wrote:
> > > > On Tue, Feb 23, 2021 at 7:03 AM Dav
Em Thu, Feb 25, 2021 at 10:10:12AM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Thu, Feb 25, 2021 at 09:49:56AM -0300, Arnaldo Carvalho de Melo escreveu:
> > Em Wed, Feb 24, 2021 at 10:16:55AM -0300, Arnaldo Carvalho de Melo escreveu:
> > > Em Mon, Feb 22, 2021 at 02:43:39PM +0800, Tiezhu Yang es
On Tue, 2021-02-23 at 16:27 +0100, Johannes Berg wrote:
>
> +void unblock_signals_hard(void)
> +{
> + if (!signals_blocked)
> + return;
> +
> + if (signals_pending && signals_enabled) {
> + /* this is a bit inefficient, but that's not really important */
> +
Em Thu, Feb 25, 2021 at 09:49:56AM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Wed, Feb 24, 2021 at 10:16:55AM -0300, Arnaldo Carvalho de Melo escreveu:
> > Em Mon, Feb 22, 2021 at 02:43:39PM +0800, Tiezhu Yang escreveu:
> > > On 02/04/2021 11:35 AM, Tiezhu Yang wrote:
> > > > v2: add R26 and R2
Hi Benjamin,
Thanks for the good work.
On Mon, 2021-02-22 at 13:23 +0100, Benjamin Gaignard wrote:
> The H.265 ITU specification (section 7.4) define the general
> slice segment header semantics.
> Modified/added fields are:
> - video_parameter_set_id: (7.4.3.1) identifies the VPS for
> reference
Hi Moritz,
Sorry for asking.
When you have chance, can you help review the version 5 patchset submitted on
02/09/21?
Regards,
Richard
-Original Message-
From: richard.g...@linux.intel.com
Sent: Tuesday, February 9, 2021 4:20 PM
To: m...@kernel.org; t...@redhat.com; gre...@linuxfounda
From: Arnd Bergmann
With clang-13, some functions only get partially inlined, with
a specialized version referring to a global variable. This
triggers a harmless build-time check for the intel-rng driver:
WARNING: modpost: drivers/char/hw_random/intel-rng.o(.text+0xe): Section
mismatch in refer
The origin is
> > > slightly different from the above kernelci.org report, but the BUG_ON is
> > > the same:
> > >
> > > [2.650447] [ cut here ]
> > > [2.650588] kernel BUG at include/linux/iommu-helper.h:23!
>
Hi Yang,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on powerpc/next]
[also build test WARNING on cryptodev/master crypto/master v5.11 next-20210225]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest
Hi folks,
We recently [1] enabled support for CMDLINE_EXTEND on arm64, however
when I started looking at replacing Android's out-of-tree implementation [2]
with the upstream version, I noticed that the two behave significantly
differently: Android follows the Kconfig help text of appending the
boo
The built-in kernel commandline (CONFIG_CMDLINE) can be configured in
three different ways:
1. CMDLINE_FORCE: Use CONFIG_CMDLINE instead of any bootloader args
2. CMDLINE_EXTEND: Append the bootloader args to CONFIG_CMDLINE
3. CMDLINE_FROM_BOOTLOADER: Only use CONFIG_CMDLINE if there aren't
The Kconfig help text for CMDLINE_EXTEND is sadly duplicated across all
architectures that implement it (arm, arm64, powerpc, riscv and sh), but
they all seem to agree that the bootloader arguments will be appended to
the CONFIG_CMDLINE. For example, on arm64:
| The command-line arguments provid
Am 25.02.21 um 13:52 schrieb Arnd Bergmann:
From: Arnd Bergmann
I noticed a warning from 'nm' when CONFIG_TRIM_UNUSED_KSYMS is set
and IS_REACHABLE(CONFIG_AGP) is false:
drivers/gpu/drm/nouveau/nvkm/subdev/pci/agp.o: no symbols
I later found this is completely harmless and we should find a wa
From: Arnd Bergmann
When CONFIG_SYSTEM_BLACKLIST_KEYRING and CONFIG_INTEGRITY_PLATFORM_KEYRING
are both enabled, the system blacklist tries calling the
pkcs7_validate_trust() function, causing a link failure if the driver
that defines it is disabled or a loadable module:
ld.lld: error: undefined
From: Arnd Bergmann
The alternative implementation of this function in a header file
is declared as a global symbol, and gets added to every .c file
that includes it, which leads to a link error:
arm-linux-gnueabi-ld: drivers/net/ethernet/mellanox/mlx5/core/en_rx.o: in
function `mlx5e_tc_tun_up
From: Arnd Bergmann
Building this file with clang leads to a an unreachable code path
causing a warning from objtool:
drivers/spi/spi-rockchip.o: warning: objtool:
rockchip_spi_transfer_one()+0x2e0: sibling call from callable instruction with
modified stack frame
Use BUG() instead of unreacha
From: Arnd Bergmann
I noticed a warning from 'nm' when CONFIG_TRIM_UNUSED_KSYMS is set
and IS_REACHABLE(CONFIG_AGP) is false:
drivers/gpu/drm/nouveau/nvkm/subdev/pci/agp.o: no symbols
I later found this is completely harmless and we should find a way
to suppress the warning, but at that point I
Em Wed, Feb 24, 2021 at 10:16:55AM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Mon, Feb 22, 2021 at 02:43:39PM +0800, Tiezhu Yang escreveu:
> > On 02/04/2021 11:35 AM, Tiezhu Yang wrote:
> > > v2: add R26 and R27 to the enum perf_event_mips_regs in patch #1
> > >
> > > Tiezhu Yang (3):
> > >
On Thu, 25 Feb 2021 13:14:37 +0100,
Anton Yakovlev wrote:
>
> On 25.02.2021 11:55, Takashi Iwai wrote:
> > On Mon, 22 Feb 2021 16:34:41 +0100,
> > Anton Yakovlev wrote:
> >> +static int virtsnd_pcm_open(struct snd_pcm_substream *substream)
> >> +{
> >> + struct virtio_pcm *vpcm = snd_pcm_subst
On Thu, Feb 25, 2021 at 01:18:21PM +0100, Arnd Bergmann wrote:
> Either way works correctly, I don't care much, but picked the __init
> annotation as it seemed more intuitive. If the compiler decides to
> make it out-of-line for whatever reason,
Well, frankly, I see no good reason for not inlining
On Thu, Feb 25, 2021 at 12:39:30PM +0100, Oscar Salvador wrote:
> On Thu, Feb 25, 2021 at 11:28:18AM +, HORIGUCHI NAOYA(堀口 直也) wrote:
> > Hi Aili,
> >
> > I agree that this set_mce_nospec() is not expected to be called for
> > "already hwpoisoned" page because in the reported case the error
>
On 2/25/2021 3:53 AM, Mike Rapoport wrote:
Hi George,
On 2/24/2021 5:37 AM, Mike Rapoport wrote:
On Tue, Feb 23, 2021 at 04:46:28PM -0500, George Kennedy wrote:
Mike,
Still no luck.
[ 30.193723] iscsi: registered transport (iser)
[ 30.195970] iBFT detected.
[ 30.196571] BUG: unable
* Krzysztof Kozlowski [210224 08:11]:
> On Wed, Feb 24, 2021 at 10:55:52AM +0300, Dan Carpenter wrote:
> > On Tue, Feb 23, 2021 at 07:38:21PM +, Colin King wrote:
> > > From: Colin Ian King
> > >
> > > Currently the array gpmc_cs is indexed by cs before it cs is range checked
> > > and the p
On Wed 2021-02-24 13:27:42, John Ogness wrote:
> On 2021-02-19, Petr Mladek wrote:
> > This is likely beyond the scope of this patchset.
>
> It would be beyond the scope of this patchset because it is not related
> to logbuf_lock removal.
>
> > I am still scratching my head about the synchroniza
If sound card doesn't need specific codec device, just
dummy codec is enough, then we can link the dummy component
directly.
In this case, user needs to specify below setting in
devicetree. Previously the sound-dai is a node of codec,
now we check if it is zero before parsing the node, zero
means
On Thu, Feb 25, 2021 at 04:52:58PM +0530, Sumit Garg wrote:
> Currently the only user for debug heap is kdbnearsym() which can be
> modified to rather ask the caller to supply a buffer for symbol name.
> So do that and modify kdbnearsym() callers to pass a symbol name buffer
> allocated from stack
On Thu, Feb 25, 2021 at 12:45 PM Borislav Petkov wrote:
> On Thu, Feb 25, 2021 at 12:22:41PM +0100, Arnd Bergmann wrote:
> > -static inline void get_smp_config(void)
> > +static inline __init void get_smp_config(void)
>
> __always_inline then I guess.
>
> Not inlining those is just silly.
Either
On Wed, Feb 24, 2021 at 11:29:04PM -0800, Nadav Amit wrote:
> Just as applications can use prefetch instructions to overlap
> computations and memory accesses, applications may want to overlap the
> page-faults and compute or overlap the I/O accesses that are required
> for page-faults of different
On 25/02/21 09:05, Vincent Guittot wrote:
>> One last thing for patch 7: mayhaps we could do a tad better to avoid
>> duplicate updates going through a heapful of leaf cfs rqs, see
>>
>> http://lore.kernel.org/r/jhj4kiht7oh.mog...@arm.com
>
> rq->last_blocked_load_update_tick is there only to fil
On 25.02.2021 11:55, Takashi Iwai wrote:
On Mon, 22 Feb 2021 16:34:41 +0100,
Anton Yakovlev wrote:
+static int virtsnd_pcm_open(struct snd_pcm_substream *substream)
+{
+ struct virtio_pcm *vpcm = snd_pcm_substream_chip(substream);
+ struct virtio_pcm_substream *vss = NULL;
+
+ if (vp
On 23.02.21 18:20, Abel Vesa wrote:
On 21-02-22 17:03:13, Martin Kepplinger wrote:
On 19.02.21 16:59, Abel Vesa wrote:
This has been on my queue for quite some time now. It is more of a
proof-of-concept.
This rework is done with the compatibility of future i.MX platforms in
mind. For example,
On Wed, Feb 10, 2021 at 11:21:32AM +0100, Joerg Roedel wrote:
> From: Joerg Roedel
>
> Add a #VC exception handler which is used when the kernel still executes
> in protected mode. This boot-path already uses CPUID, which will cause #VC
> exceptions in an SEV-ES guest.
>
> Signed-off-by: Joerg R
On Wed, Feb 24, 2021 at 10:22:38PM -0700, Yu Zhao wrote:
> On Thu, Feb 25, 2021 at 03:55:53AM +, Matthew Wilcox wrote:
> > On Wed, Feb 24, 2021 at 04:50:39PM -0700, Yu Zhao wrote:
> > > Let me work out something *conceptually* smaller first, and if you
> > > think folio is absolutely more suita
On Thu, 25 Feb 2021 12:51:36 +0100,
Anton Yakovlev wrote:
>
> > Now I'm wondering whether it's safe to do that from this place.
> > Basically device_reprobe() unbinds the device that releases the full
> > resources once including the devm_* stuff. And this work itself is in
> > a part of devm all
On Thu, Feb 25, 2021 at 2:32 AM elaine.zhang wrote:
>
> Hi, Rafael:
>
> 在 2021/2/25 上午1:53, Rafael J. Wysocki 写道:
> > From: Rafael J. Wysocki
> >
> > Because the PM-runtime status of the device is not updated in
> > __rpm_callback(), attempts to suspend the suppliers of the given
> > device trigg
Hi,
thanks for reporting this, you're right but you've missed the braces
around the if block in your patch, because we really want to exit
only on -ENOMEM. Something like:
if (ret == -ENOMEM) {
of_node_put(child);
return ret;
}
Regards,
Cristian
The AXI ID is an AXI bus configuration for improve bus performance. If
read and write operations use different ID the operations can be
paralleled, whereas when they have the same ID the operations will be
serialized. Right now, the write ID is fixed to 0 but we can set it to
0xff to get auto gener
> > On Feb 24, 2021, at 12:03 AM, wanghongzhe
> wrote:
> >
> > As Kees haved accepted the v2 patch at a381b70a1 which just replaced
> > rmb() with smp_rmb(), this patch will base on that and just adjust the
> > smp_rmb() to the correct position.
> >
> > As the original comment shown (and indeed i
Since the opcodes start from 0xff are group5 instruction group which is
not 2 bytes opcode but the extended opcode determined by the MOD/RM byte.
The commit abd82e533d88 ("x86/kprobes: Do not decode opcode in
resume_execution()")
used insn->opcode.bytes[1], but that is not correct. We have to ref
Since Grp5 far indirect JMP is FF "mod 101 r/m", it should be
(modrm & 0x38) == 0x28, and near indirect JMP is also 0x38 == 0x20.
So we can mask modrm with 0x30 and check 0x20.
This is actually what the original code does, it also doesn't care
the last bit. So the result code is same.
Thus, I thin
Hi,
Here are 2 bugfixes I have found in set_resume_flags().
The [1/2] fixes a bug which I have introduced by commit
abd82e533d88 ("x86/kprobes: Do not decode opcode in
resume_execution()"), and [2/2] has been there in the origin
of the x86 kprobes (before 2.6.12). Anyway, [2/2] is something
like
On Wed, Feb 24, 2021 at 01:34:09PM -0600, Madhavan T. Venkataraman wrote:
> On 2/24/21 6:17 AM, Mark Rutland wrote:
> > On Tue, Feb 23, 2021 at 12:12:43PM -0600, madve...@linux.microsoft.com
> > wrote:
> >> From: "Madhavan T. Venkataraman"
> >>Termination
> >>===
> >>
> >>Curr
On Thursday 25 Feb 2021 at 12:45:06 (+0100), Dietmar Eggemann wrote:
> I.e. since _task_util_est is always >= task_util during wakeup, cpu_util
> must be > cpu_util_est (by more than _task_util_est - task_util).
>
> I can see it for a CPU whose cpu_util has a fair amount of contributions
> from bl
Le 2/25/21 à 5:34 AM, David Hildenbrand a écrit :
| | | |> +
ffc0 | -256 GB | ffc7 | 32 GB | kasan
+ ffcefee0 | -196 GB | ffcefeff | 2 MB | fixmap
+ ffceff00 | -196 GB | ff
From: Yury Norov
Date: Wed, 24 Feb 2021 07:44:16 -0800
> On Wed, Feb 24, 2021 at 11:52:55AM +, Alexander Lobakin wrote:
> > From: Yury Norov
> > Date: Sat, 5 Dec 2020 08:54:06 -0800
> >
> > Hi,
> >
> > > ARM64 doesn't implement find_first_{zero}_bit in arch code and doesn't
> > > enable it i
On 25.02.2021 11:38, Takashi Iwai wrote:
On Mon, 22 Feb 2021 16:34:37 +0100,
Anton Yakovlev wrote:
+static int virtsnd_find_vqs(struct virtio_snd *snd)
+{
+ struct virtio_device *vdev = snd->vdev;
+ vq_callback_t *callbacks[VIRTIO_SND_VQ_MAX] = {
+ [VIRTIO_SND_VQ_EVENT] = vir
you
> > > have a fix.
> >
> > This is also causing boot failures on Jetson AGX Xavier. The origin is
> > slightly different from the above kernelci.org report, but the BUG_ON is
> > the same:
> >
> > [2.650447] [ cut here ]----
> > [2
Uwe Kleine-König writes:
> The driver core ignores the return value of struct bus_type::remove()
> because there is only little that can be done. To simplify the quest to
> make this function return void, let struct vio_driver::remove() return
> void, too. All users already unconditionally return
On Wed, Feb 24, 2021 at 2:30 PM Aditya Srivastava wrote:
>
> Currently, there are 447 files in the kernel tree, which use 'typedef
> struct/union' syntax for defining some struct/union. In total, there
> are ~1290 such occurrences in the kernel tree.
>
> However, kernel-doc does not support it cur
On 25/02/2021 09:36, vincent.donnef...@arm.com wrote:
> From: Vincent Donnefort
>
> The sub_positive local version is saving an explicit load-store and is
> enough for the cpu_util_next() usage.
>
> Signed-off-by: Vincent Donnefort
>
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> i
On Thu, Feb 25, 2021 at 12:22:41PM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> clang-13 sometimes decides to not inline early_get_smp_config(),
> which leads to a link-time warning:
>
> WARNING: modpost: vmlinux.o(.text+0x838cc): Section mismatch in reference
> from the function early
On 25/02/2021 09:36, vincent.donnef...@arm.com wrote:
> From: Vincent Donnefort
[...]
> cpu_util_next() estimates the CPU utilization that would happen if the
> task was placed on dst_cpu as follows:
>
> max(cpu_util + task_util, cpu_util_est + _task_util_est)
>
> The task contribution to th
On Thu, Feb 25, 2021 at 04:03:50PM +0530, Yogesh Lal wrote:
> Hi Greg,
>
>
> On 2/24/2021 6:13 PM, Greg KH wrote:
> > On Wed, Feb 24, 2021 at 05:25:49PM +0530, Yogesh Lal wrote:
> > > Queue deferred driver probes on unbounded workqueue, to allow
> > > scheduler better manage scheduling of long ru
HI Michael,
> -Original Message-
> From: Michael Grzeschik
> Sent: Monday, February 22, 2021 9:01 PM
> To: Manish Narani
> Cc: gre...@linuxfoundation.org; robh...@kernel.org; Michal Simek
> ; ba...@kernel.org; p.za...@pengutronix.de;
> devicet...@vger.kernel.org; linux-...@vger.kernel.or
On 15.02.21 15:19:49, Borislav Petkov wrote:
> From: Borislav Petkov
> Subject: [PATCH] Documentation/submitting-patches: Extend commit message
> layout description
>
> Add more blurb about the level of detail that should be contained in a
> patch's commit message. Extend and make more explicit
On Thu, Feb 25, 2021 at 04:42:28AM +, Lan Zheng (lanzheng) wrote:
> From ba2ec52f170a8e69d6c44238bb578f9518a7e3b7 Mon Sep 17 00:00:00 2001
> From: lanzheng
> Date: Tue, 23 Feb 2021 22:49:34 -0500
Why is this here?
> Subject: [PATCH] This patch adds a kernel build config knob that disallows
>
On Thu, Feb 25, 2021 at 11:28:18AM +, HORIGUCHI NAOYA(堀口 直也) wrote:
> Hi Aili,
>
> I agree that this set_mce_nospec() is not expected to be called for
> "already hwpoisoned" page because in the reported case the error
> page is already contained and no need to resort changing cache mode.
Out
Following warning is found when using W=1 to build kernel:
In function ‘nvkm_udevice_info’,
inlined from ‘nvkm_udevice_mthd’ at
drivers/gpu/drm/nouveau/nvkm/engine/device/user.c:195:10:
drivers/gpu/drm/nouveau/nvkm/engine/device/user.c:164:2: warning: ‘strncpy’
specified bound 16 equals dest
On Thu, Feb 25, 2021 at 11:43:29AM +0800, Aili Yao wrote:
> On Wed, 24 Feb 2021 11:31:55 +0100 Oscar Salvador wrote:
...
>
> > >
> > > 3.The kill_me_maybe will check the return:
> > >
> > > 1244 static void kill_me_maybe(struct callback_head *cb)
> > > 1245 {
> > >
> > > 1254 if (!mem
As a side-node, I didn't pick up the other patches as there is review
feedback and I didn't have strong opinions either way. Patch 3 is curious
though, it probably should be split out and sent separetly but still;
On Wed, Feb 24, 2021 at 07:56:51PM +0100, Jesper Dangaard Brouer wrote:
> Avoid mult
901 - 1000 of 1230 matches
Mail list logo
