On 1/27/2021 2:13 PM, Peter Zijlstra wrote:
On Wed, Jan 27, 2021 at 07:38:43AM -0800, kan.li...@linux.intel.com wrote:
From: Kan Liang
Current perf doesn't check the index of a Topdown metrics event before
updating the event. A perf tool user may get a value from an unsupported
Topdown metr
On Thu, Jan 28, 2021 at 01:31:00AM +0800, Kai-Heng Feng wrote:
> Commit 50310600ebda ("iommu/vt-d: Enable PCI ACS for platform opt in
> hint") enables ACS, and some platforms lose its NVMe after resume from
> firmware:
> [ 50.947816] pcieport :00:1b.0: DPC: containment event, status:0x1f01
>
Hello Nikita,
On Wed, 2021-01-27 at 13:46 +0300, Nikita Shubin wrote:
> Separate IRQ's setup for port A,B,F.
Somehow I don't feel that moving "FIXME" code around makes much
sense. Maybe the anticipated conversion to hierarhical IRQ chip
will result in a cleanup automatically?
> Signed-off-by: Ni
Hi Dmitry,
On 1/27/2021 1:48 PM, Dmitry Vyukov wrote:
> On Wed, Jan 27, 2021 at 7:44 PM Konrad Rzeszutek Wilk
> wrote:
>> On Tue, Jan 26, 2021 at 01:03:21PM -0500, George Kennedy wrote:
>>> During boot of kernel with CONFIG_KASAN the following KASAN false
>>> positive failure will occur when ibft
Tomas,
- Ursprüngliche Mail -
> Von: "Tomas Winkler"
> An: "Miquel Raynal" , "richard" ,
> "Vignesh Raghavendra" ,
> "linux-mtd" , "linux-kernel"
>
> CC: "Tomas Winkler"
> Gesendet: Mittwoch, 27. Januar 2021 21:03:19
> Betreff: [PATCH] mtd: use refcount to prevent corruption
> When u
On Tue, Jan 26, 2021 at 08:44:49AM +0100, Michal Hocko wrote:
> On Mon 25-01-21 11:33:36, Minchan Kim wrote:
> > On Mon, Jan 25, 2021 at 02:12:00PM +0100, Michal Hocko wrote:
> > > On Thu 21-01-21 09:55:00, Minchan Kim wrote:
> > > > Contiguous memory allocation can be stalled due to waiting
> > >
This is something that Dan Williams and I discussed off the mailing
list sometime ago, but I want to have a broader discussion about this
problem so I could send out a fix that would be acceptable.
We have a 2G pmem device that is carved out of regular memory that we
use to pass data across reboot
From: Alexander Sverdlin
This will save one SYNCW on Octeon and improve tight
uncontended spinlock loop performance by 17%.
Signed-off-by: Alexander Sverdlin
---
arch/mips/include/asm/atomic.h | 3 +++
arch/mips/include/asm/cmpxchg.h | 2 ++
2 files changed, 5 insertions(+)
diff --git a/arch
From: Alexander Sverdlin
On Octeon mmiowb() is SYNCW, which is already contained in
smp_store_release(). Removing superfluous barrier brings around 10%
performance on uncontended tight spinlock loops.
Signed-off-by: Alexander Sverdlin
---
arch/mips/include/asm/spinlock.h | 2 ++
1 file changed
From: Alexander Sverdlin
The switch to qspinlock brought a massive regression in spinlocks on
Octeon. Even after applying this series (and a patch in the
ARCH-independent code [1]) tight contended (6 cores, 1 thread per core)
spinlock loop is still 50% slower as previous ticket-based implementati
From: Alexander Sverdlin
It makes no sense to fold smp_mb__before_llsc()/smp_llsc_mb() again and
again, leave only one barrier pair in the outer function.
This removes one SYNCW from __xchg_small() and brings around 10%
performance improvement in a tight spinlock loop with 6 threads on a 6 core
From: Alexander Sverdlin
On Octeon smp_mb() translates to SYNC while wmb+rmb translates to SYNCW
only. This brings around 10% performance on tight uncontended spinlock
loops.
Refer to commit 500c2e1fdbcc ("MIPS: Optimize spinlocks.") and the link
below.
On 6-core Octeon machine:
sysbench --test
From: Alexander Sverdlin
This has the effect of removing one redundant SYNCW from
queued_spin_lock_slowpath() on Octeon.
Signed-off-by: Alexander Sverdlin
---
arch/mips/include/asm/atomic.h | 2 ++
arch/mips/include/asm/cmpxchg.h | 4
2 files changed, 6 insertions(+)
diff --git a/arch/m
From: Alexander Sverdlin
Flushing the write buffer brings aroung 10% performace on the tight
uncontended spinlock loops on Octeon. Refer to commit 500c2e1fdbcc
("MIPS: Optimize spinlocks.").
Signed-off-by: Alexander Sverdlin
---
arch/mips/include/asm/spinlock.h | 3 +++
1 file changed, 3 inser
On Wed, Jan 27, 2021 at 4:02 AM Hariprasad Kelam wrote:
>
> From: Christina Jacob
>
> CGX LMAC, the physical interface support link configuration parameters
> like speed, auto negotiation, duplex etc. Firmware saves these into
> memory region shared between firmware and this driver.
>
> This pat
On Wed, Jan 27, 2021 at 4:03 AM Hariprasad Kelam wrote:
>
> From: Christina Jacob
>
> Add ethtool support to configure fec modes baser/rs and
> support to fecth FEC stats from CGX as well PHY.
>
> Configure fec mode
> - ethtool --set-fec eth0 encoding rs/baser/off/auto
> Query fec mode
>
On Wed, Jan 27, 2021 at 2:14 AM David Laight wrote:
>
> If I read this correctly it adds a (potentially big) queue between the
> LAPB code that adds the sequence numbers to the frames and the hardware
> that actually sends them.
Yes. The actual number of outgoing LAPB frames being queued depends
On 1/27/21 11:30 AM, Randy Dunlap wrote:
> On 1/27/21 11:08 AM, Randy Dunlap wrote:
>> On 1/27/21 6:44 AM, Stephen Rothwell wrote:
>>> Hi all,
>>>
>>> Note: the patch file has failed to upload :-(
>>>
>>> Changes since 20210125:
>>>
>>
>> on x86_64:
>>
>> ../drivers/gpu/drm/i915/i915_gem.c: In func
STIMER0 interrupts are most naturally modeled as per-cpu IRQs. But
because x86/x64 doesn't have per-cpu IRQs, the core STIMER0 interrupt
handling machinery is done in code under arch/x86 and Linux IRQs are
not used. Adding support for ARM64 means adding equivalent code
using per-cpu IRQs under arch
On x86/x64, the TSC clocksource is available in a Hyper-V VM only if
Hyper-V provides the TSC_INVARIANT flag. The rating on the Hyper-V
Reference TSC page clocksource is currently set so that it will not
override the TSC clocksource in this case. Alternatively, if the TSC
clocksource is not availa
While the Hyper-V Reference TSC code is architecture neutral, the
pv_ops.time.sched_clock() function is implemented for x86/x64, but not
for ARM64. Current code calls a utility function under arch/x86 (and
coming, under arch/arm64) to handle the difference.
Change this approach to handle the diffe
On Mon, Jan 25, 2021 at 11:07 PM John Stultz wrote:
>
> On Thu, Jan 21, 2021 at 9:55 AM Minchan Kim wrote:
> > .../reserved-memory/dma_heap_chunk.yaml | 56 +++
> > 1 file changed, 56 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/reserved-memo
VMbus interrupts are most naturally modelled as per-cpu IRQs. But
because x86/x64 doesn't have per-cpu IRQs, the core VMbus interrupt
handling machinery is done in code under arch/x86 and Linux IRQs are
not used. Adding support for ARM64 means adding equivalent code
using per-cpu IRQs under arch/
While the driver for the Hyper-V Reference TSC and STIMERs is architecture
neutral, vDSO is implemented for x86/x64, but not for ARM64. Current code
calls into utility functions under arch/x86 (and coming, under arch/arm64)
to handle the difference.
Change this approach to handle the difference i
The definition of enum hv_message_type includes arch neutral and
x86/x64-specific values. Ideally there would be a way to put the
arch neutral values in an arch neutral module, and the arch
specific values in an arch specific module. But C doesn't provide
a way to extend enum types. As a compromise
On 1/27/2021 3:09 AM, Alexander A Sverdlin wrote:
> From: Alexander Sverdlin
>
> No functional change, later it will be re-used in several files.
>
> Signed-off-by: Alexander Sverdlin
Tested-by: Florian Fainelli
--
Florian
Current code defines a separate get and set macro for each Hyper-V
synthetic MSR used by the VMbus driver. Furthermore, the get macro
can't be converted to a standard function because the second argument
is modified in place, which is somewhat bad form.
Redo this by providing a single get and a si
On x86/x64, Hyper-V provides a flag to indicate auto EOI functionality,
but it doesn't on ARM64. Handle this quirk inline instead of calling
into code under arch/x86 (and coming, under arch/arm64).
No functional change.
Signed-off-by: Michael Kelley
---
arch/x86/include/asm/mshyperv.h | 3 ---
The Hyper-V page allocator functions are implemented in an architecture
neutral way. Move them into the architecture neutral VMbus module so
a separate implementation for ARM64 is not needed.
No functional change.
Signed-off-by: Michael Kelley
---
arch/x86/hyperv/hv_init.c | 22 -
To support Linux guests on Hyper-V on multiple architectures, the original
approach factored out all differences between Hyper-V on x86/x64 and
Hyper-V on ARM64 into functions or #defines under arch/x86 and
arch/arm64. Some of these differences are truly related to the
architecture, but others are
With the new Hyper-V MSR set function, hyperv_report_panic_msg() can be
architecture neutral, so move it out from under arch/x86 and merge into
hv_kmsg_dump(). This move also avoids needing a separate implementation
under arch/arm64.
No functional change.
Signed-off-by: Michael Kelley
---
arch/
From: Alexander Lobakin
Date: Mon, 25 Jan 2021 16:46:48 +
> page_is_pfmemalloc() is used mostly by networking drivers. It doesn't
> write anything to the struct page itself, so constify its argument and
> a bunch of callers and wrappers around this function in drivers.
> In Page Pool core cod
On Fri, Jan 22, 2021 at 7:47 PM John Stultz wrote:
> +static int system_heap_clear_pages(struct page **pages, int num, pgprot_t
> pgprot)
> +{
> + void *addr = vmap(pages, num, VM_MAP, pgprot);
> +
> + if (!addr)
> + return -ENOMEM;
> + memset(addr, 0, PAGE_SIZE *
On 1/27/21 6:44 AM, Stephen Rothwell wrote:
> Hi all,
>
> Note: the patch file has failed to upload :-(
>
> Changes since 20210125:
>
on i386:
WARNING: unmet direct dependencies detected for NETFS_SUPPORT
Depends on [n]: NETWORK_FILESYSTEMS [=n]
Selected by [y]:
- FSCACHE [=y]
Full rand
On Tue, Jan 26, 2021 at 11:12:14AM -0800, Minchan Kim wrote:
> On Tue, Jan 26, 2021 at 08:38:08AM +0100, Michal Hocko wrote:
> > On Mon 25-01-21 11:42:34, Minchan Kim wrote:
> > > On Mon, Jan 25, 2021 at 02:07:01PM +0100, Michal Hocko wrote:
> > > > On Thu 21-01-21 09:54:59, Minchan Kim wrote:
> >
On Wed, Jan 27, 2021 at 4:04 AM Hariprasad Kelam wrote:
>
> From: Felix Manlunas
>
> This patch adds support to fetch fec stats from PHY. The stats are
> put in the shared data struct fwdata. A PHY driver indicates
> that it has FEC stats by setting the flag fwdata.phy.misc.has_fec_stats
>
> Bes
If an error occurs after a successful 'of_icc_get()' call, it must be
undone by a corresponding 'icc_put()' call.
Add it in the error handling path of the probe function as already done in
the remove function.
Fixes: 32f0a6ddc8c9 ("media: venus: Use on-chip interconnect API")
Signed-off-by: Chris
On 1/26/2021 5:06 PM, Lorenzo Carletti wrote:
> In the rtl8366rb driver there are some jam tables which contain
> undocumented values.
> While trying to understand what these tables actually do,
> I noticed a discrepancy in how one of those was treated.
> Most of them were plain u16 arrays, whil
On 1/27/2021 12:06 PM, Lorenzo Carletti wrote:
> Many thanks for telling me that and for showing me how this works.
> I find both very useful.
> I'll be sure to follow the guidelines more carefully next time.
One of those guidelines is no top-posting and make sure you use a
plaintext format for
- On Jan 27, 2021, at 2:16 PM, rostedt rost...@goodmis.org wrote:
> On Wed, 27 Jan 2021 13:13:22 -0500 (EST)
> Mathieu Desnoyers wrote:
>
>> > Thanks for bringing that up.
>>
>> Requiring an RCU synchronize on element removal is quite intrusive, and can
>> be problematic if tracepoint remov
On Wed, Jan 27, 2021 at 4:05 AM Hariprasad Kelam wrote:
>
> From: Christina Jacob
>
> CGX block supports forward error correction modes baseR
> and RS. This patch adds support to set encoding mode
> and to read corrected/uncorrected block counters
>
> Adds new mailbox handlers set_fec to configur
On 1/25/21 9:19 PM, a...@linux-foundation.org wrote:
> The mm-of-the-moment snapshot 2021-01-25-21-18 has been uploaded to
>
>https://www.ozlabs.org/~akpm/mmotm/
>
> mmotm-readme.txt says
>
> README for mm-of-the-moment:
>
> https://www.ozlabs.org/~akpm/mmotm/
>
> This is a snapshot of my
pool_page_reusable() is a leftover from pre-NUMA-aware times. For now,
this function is just a redundant wrapper over page_is_pfmemalloc(),
so Inline it into its sole call site.
Signed-off-by: Alexander Lobakin
Acked-by: Jesper Dangaard Brouer
Reviewed-by: Ilias Apalodimas
---
net/core/page_po
On Mon, Jan 25, 2021 at 01:45:25PM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> I ran into a couple of problems with kunit tests taking too much stack
> space, sometimes dangerously so. These the the three instances that
> cause an increase over the warning limit of some architectures:
>
A bunch of drivers test the page before reusing/recycling for two
common conditions:
- if a page was allocated under memory pressure (pfmemalloc page);
- if a page was allocated at a distant memory node (to exclude
slowdowns).
Introduce and use a new common function for doing this and elimina
The function doesn't write anything to the page struct itself,
so this argument can be const.
Misc: align second argument to the brace while at it.
Signed-off-by: Alexander Lobakin
---
include/linux/skbuff.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/linux/s
page_is_pfmemalloc() is used mostly by networking drivers to test
if a page can be considered for reusing/recycling.
It doesn't write anything to the struct page itself, so its sole
argument can be constified, as well as the first argument of
skb_propagate_pfmemalloc().
In Page Pool core code, it c
The function only tests for page->index, so its argument should be
const.
Signed-off-by: Alexander Lobakin
---
include/linux/mm.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/mm.h b/include/linux/mm.h
index ecdf8a8cd6ae..078633d43af9 100644
--- a/include/linu
On Tue, Jan 26, 2021 at 12:48 PM Paolo Bonzini wrote:
>
> On 26/01/21 19:11, Ben Gardon wrote:
> > When I did a strict replacement I found ~10% worse memory population
> > performance.
> > Running dirty_log_perf_test -v 96 -b 3g -i 5 with the TDP MMU
> > disabled, I got 119 sec to populate memory
> On Jan 26, 2021, at 2:42 AM, Jiapeng Zhong
> wrote:
>
> Fix the following coccicheck warnings:
>
> ./drivers/scsi/qla2xxx/qla_nvme.c:288:24-26: WARNING !A || A && B is
> equivalent to !A || B.
>
> Reported-by: Abaci Robot
> Signed-off-by: Jiapeng Zhong
> ---
> drivers/scsi/qla2xxx/qla_n
When underlying device is removed mtd core will crash
in case user space is still holding an open handle to a mtd device node.
A proper refcounting is needed so device is release only when a
partition has no active users. The current simple counter is not
sufficient.
Signed-off-by: Tomas Winkler
On Thu, 2021-01-28 at 00:05 +0900, Tomoyuki Matsushita wrote:
> Signed-off-by: Tomoyuki Matsushita
checkpatch is pretty stupid so whatever it recommends needs to
be looked at carefully by a human and fixed appropriately.
> diff --git a/net/bluetooth/af_bluetooth.c b/net/bluetooth/af_bluetooth.c
From: Alexander Sverdlin
Drop smp_wmb in arch_mcs_spin_lock_contended() after adding in into
ARCH-independent code.
Signed-off-by: Alexander Sverdlin
---
arch/arm/include/asm/mcs_spinlock.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm/include/asm/mcs_spinlock.h
b/arch/arm/inc
From: Alexander Sverdlin
Ensure writes are pushed out of core write buffer to prevent waiting code
on another cores from spinning longer than necessary.
6 threads running tight spinlock loop competing for the same lock
on 6 cores on MIPS/Octeon do 100 iterations...
before the patch in:4
On Tue, 19 Jan 2021 18:52:03 +0800, Yong Wu wrote:
> The commit e0d072782c73 ("dma-mapping: introduce DMA range map,
> supplanting dma_pfn_offset") always update dma_range_map even though it was
> already set, like in the sunxi_mbus driver. the issue is reported at [1].
> This patch avoid this(Upda
On Tue, Jan 26, 2021 at 2:46 PM Vincenzo Frascino
wrote:
>
> This patchset implements the asynchronous mode support for ARMv8.5-A
> Memory Tagging Extension (MTE), which is a debugging feature that allows
> to detect with the help of the architecture the C and C++ programmatic
> memory errors like
Adding support for Cinterion device MV31 for enumeration with
PID 0x00B3 and 0x00B7.
usb-devices output for 0x00B3
T: Bus=04 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 6 Spd=5000 MxCh= 0
D: Ver= 3.20 Cls=ef(misc ) Sub=02 Prot=01 MxPS= 9 #Cfgs= 1
P: Vendor=1e2d ProdID=00b3 Rev=04.14
S: Manufacturer=
Em Thu, Jan 21, 2021 at 05:37:52AM -0800, kan.li...@linux.intel.com escreveu:
> From: Kan Liang
>
> The Topdown Microarchitecture Analysis (TMA) Method is a structured
> analysis methodology to identify critical performance bottlenecks in
> out-of-order processors. From the Ice Lake and later pla
On 1/27/21 2:30 AM, Paul Durrant wrote:
> From: Paul Durrant
>
> Prior to commit 4a8c31a1c6f5 ("xen/blkback: rework connect_ring() to avoid
> inconsistent xenstore 'ring-page-order' set by malicious blkfront"), the
> behaviour of xen-blkback when connecting to a frontend was:
>
> - read 'ring
I found a corner-case which is not well handled, e.g.
* layer1 only restricts X access and allows X access for /a
-> X is allowed for /a
* layer2 only restricts Y access and allows Y access for /a/b
-> X is not allowed for /a anymore because now the path walk for /a
doesn't encounter a layer 2 rule
Hi Jassi,
The following series extends the OMAP Mailbox driver to enable the
Mailbox IP present on the most recent TI K3 AM64x SoCs [1]. AM64x is
a 64-bit system, and the Mailbox IP is a cut-down version of the one
present on previous TI K3 SoCs like AM65x and J721E.
DT nodes will be posted separ
The AM64x SoC contains a Mailbox IP instance with multiple clusters
in the MAIN domain, and is a variant of the IP on current AM65x and
J721E SoCs. The AM64x SoC has only 8 clusters with no interrupts
routed to the A53 core on the first 2 clusters. The interrupt outputs
from the IP do not go throug
On Wed, Jan 27, 2021 at 8:43 PM Dmitry Vyukov wrote:
> > > > > > > This happens on arm64 instance with mte enabled.
> > > > > > > There is a GPF in reiserfs_xattr_init on x86_64 reported:
> > > > > > > https://syzkaller.appspot.com/bug?id=8abaedbdeb32c861dc5340544284167dd0e46cde
> > > > > > > so I
Update the existing OMAP Mailbox binding to include the info for
AM64x SoCs. There are some minor IP integration differences between
the AM64x SoCs and the previous AM65x and J721E SoC families.
Signed-off-by: Suman Anna
---
.../bindings/mailbox/omap-mailbox.txt | 22 +++
> > Currently a non-root process can create directories, but cannot
> > create stuff in the directories it creates.
>
> Isn't that on purpose?
Is it? What's the use case of being able to create empty directories
you can't use?
Why allow their creation in the first place then?
> > + (
On Wed, Jan 27, 2021 at 6:44 PM Mark Brown wrote:
>
> On Wed, Jan 27, 2021 at 06:14:13PM +0100, Dmitry Vyukov wrote:
> > On Wed, Jan 27, 2021 at 5:58 PM syzbot
> > wrote:
> > >
> > > Hello,
> > >
> > > syzbot found the following issue on:
> > >
> > > HEAD commit:2ab38c17 mailmap: remove the "
On Wed, Jan 27, 2021 at 10:18:31AM +1100, Stephen Rothwell wrote:
> Hi all,
>
> After merging the btrfs tree, today's linux-next build (powerpc
> ppc64_defconfig) produced this warning:
>
> fs/btrfs/space-info.c:1373: warning: Function parameter or member 'start_ns'
> not described in 'handle_re
On Wed, Jan 27, 2021 at 02:49:21PM +0100, gre...@linuxfoundation.org wrote:
> On Thu, Jan 21, 2021 at 09:38:28PM +, Song Bao Hua (Barry Song) wrote:
> > Hi Thomas, Greg, Dmitry, Marc,
> > Any further comment on this new API?
>
> It's not my subsystem, I'll let the irq maintainers handle it :)
On Wed, Jan 27, 2021 at 8:16 PM 'Andrey Konovalov' via syzkaller-bugs
wrote:
>
> On Wed, Jan 27, 2021 at 7:57 PM Dmitry Vyukov wrote:
> >
> > On Wed, Jan 27, 2021 at 7:46 PM 'Andrey Konovalov' via syzkaller-bugs
> > wrote:
> > >
> > > On Wed, Jan 27, 2021 at 6:24 PM Dmitry Vyukov wrote:
> > > >
This patch adapts the panfrost pre-defined thresholds change [0] to the
lima driver to improve real-world performance. The upthreshold value has
been set to ramp GPU frequency to max freq faster (compared to panfrost)
to compensate for the lower overall performance of utgard devices.
[0]
https://
The following commit has been merged into the efi/core branch of tip:
Commit-ID: 3e1e00c00e2b9b5c9a2f47f1c67720a5d430e4d0
Gitweb:
https://git.kernel.org/tip/3e1e00c00e2b9b5c9a2f47f1c67720a5d430e4d0
Author:Ard Biesheuvel
AuthorDate:Tue, 19 Jan 2021 15:16:27 +01:00
Committer
The following commit has been merged into the efi/core branch of tip:
Commit-ID: cdec91c034a2c99331b62a5f417bf7527fa6d490
Gitweb:
https://git.kernel.org/tip/cdec91c034a2c99331b62a5f417bf7527fa6d490
Author:Ard Biesheuvel
AuthorDate:Mon, 02 Nov 2020 10:04:39 +01:00
Committer
Hi Andre,
On Wed, Jan 27, 2021 at 05:24:45PM +, Andre Przywara wrote:
> On at least one board (Orangepi Zero2) the AXP305 PMIC does not have its
> interrupt line connected to the CPU (mostly because the H616 SoC does
> not feature an NMI pin anymore).
> After allowing the AXP driver to proceed
The following commit has been merged into the efi/core branch of tip:
Commit-ID: 3820749ddcee694abfd5ae6cabc18aaab11eab34
Gitweb:
https://git.kernel.org/tip/3820749ddcee694abfd5ae6cabc18aaab11eab34
Author:Ard Biesheuvel
AuthorDate:Mon, 02 Nov 2020 11:51:10 +01:00
Committer
On 1/27/2021 3:09 AM, Alexander A Sverdlin wrote:
> From: Alexander Sverdlin
>
> Teach ftrace_make_call() and ftrace_make_nop() about PLTs.
> Teach PLT code about FTRACE and all its callbacks.
> Otherwise the following might happen:
>
> [ cut here ]
> WARNING: CPU: 14
Hi Mathieu,
On Wed, 27 Jan 2021 at 18:32, Mathieu Poirier
wrote:
>
> On Wed, Jan 27, 2021 at 05:53:50PM +, Mike Leach wrote:
> > The current fixed metadata version format (version 0), means that adding
> > metadata parameter items renders files from a previous version of perf
> > unreadable.
On 2021-01-27 19:09, Rob Herring wrote:
On Wed, Jan 27, 2021 at 7:13 AM Robin Murphy wrote:
[ + Christoph, Marek ]
On 2021-01-27 13:00, Paul Kocialkowski wrote:
Hi,
On Tue 19 Jan 21, 18:52, Yong Wu wrote:
The commit e0d072782c73 ("dma-mapping: introduce DMA range map,
supplanting dma_pfn_o
> On 27 Jan 2021, at 3:11 pm, Lukasz Luba wrote:
>
> On 1/27/21 10:24 AM, Lukasz Luba wrote:
>> Hi Christian,
>> On 1/25/21 8:18 AM, Christian Hewitt wrote:
>>> This patch adapts the panfrost pre-defined thresholds change [0] to the
>>> lima driver to improve real-world performance. The upthres
On 1/25/21 9:19 PM, a...@linux-foundation.org wrote:
> The mm-of-the-moment snapshot 2021-01-25-21-18 has been uploaded to
>
>https://www.ozlabs.org/~akpm/mmotm/
>
> mmotm-readme.txt says
>
> README for mm-of-the-moment:
>
> https://www.ozlabs.org/~akpm/mmotm/
>
> This is a snapshot of my
The following commit has been merged into the efi/core branch of tip:
Commit-ID: 8ff059b8531f3b98e14f0461859fc7cdd95823e4
Gitweb:
https://git.kernel.org/tip/8ff059b8531f3b98e14f0461859fc7cdd95823e4
Author:Ard Biesheuvel
AuthorDate:Mon, 18 Jan 2021 13:38:42 +01:00
Committer
The following commit has been merged into the locking/core branch of tip:
Commit-ID: 59ea5f1508e15cecddd8e2ca828f7962ea37adab
Gitweb:
https://git.kernel.org/tip/59ea5f1508e15cecddd8e2ca828f7962ea37adab
Author:Alex Shi
AuthorDate:Fri, 13 Nov 2020 16:58:11 +08:00
Committer:
[ Participants list changed - syzbot thought this was networking and
p9, but it really looks entirely like a slub internal bug. I left the
innocent people on the list just to let them know they are innocent ]
On Wed, Jan 27, 2021 at 6:27 AM syzbot
wrote:
>
> The issue was bisected to:
>
> commit
The following commit has been merged into the locking/core branch of tip:
Commit-ID: cfb8364aec4317f8e0695e4c9779b3413ce36ef4
Gitweb:
https://git.kernel.org/tip/cfb8364aec4317f8e0695e4c9779b3413ce36ef4
Author:Jangwoong Kim <6812sk...@gmail.com>
AuthorDate:Wed, 30 Dec 2020 2
On Wed, Jan 27, 2021 at 02:22:08PM +, David Howells wrote:
>
> I've pulled this into my keys-next branch.
David, please drop them because there are issues with the Crypto API
bits.
Thanks,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.
On Wed, Jan 27, 2021 at 07:33:49AM -0500, Stefan Berger wrote:
>
> +static struct akcipher_alg ecc_nist_p256 = {
> + .verify = ecdsa_verify,
> + .set_pub_key = ecc_set_pub_key,
> + .max_size = ecc_nist_p256_max_size,
> + .init = ecc_nist_p256_init_tfm,
> + .exit = ecc_exit_tfm,
The following commit has been merged into the x86/misc branch of tip:
Commit-ID: 02a16aa13574c8526beadfc9ae8cc9b66315fa2d
Gitweb:
https://git.kernel.org/tip/02a16aa13574c8526beadfc9ae8cc9b66315fa2d
Author:Misono Tomohiro
AuthorDate:Wed, 27 Jan 2021 21:24:56 +09:00
Committe
The following commit has been merged into the locking/core branch of tip:
Commit-ID: 3018a0840135536817507dd14c2a7c4ffa69
Gitweb:
https://git.kernel.org/tip/3018a0840135536817507dd14c2a7c4ffa69
Author:Alejandro Colomar
AuthorDate:Sat, 28 Nov 2020 13:39:46 +01:00
Co
The following commit has been merged into the efi/urgent branch of tip:
Commit-ID: 355845b738e76445c8522802552146d96cb4afa7
Gitweb:
https://git.kernel.org/tip/355845b738e76445c8522802552146d96cb4afa7
Author:Lukas Wunner
AuthorDate:Thu, 31 Dec 2020 06:10:32 +01:00
Committer
On 2021-01-27 19:07, Rob Herring wrote:
On Tue, Jan 19, 2021 at 4:52 AM Yong Wu wrote:
The commit e0d072782c73 ("dma-mapping: introduce DMA range map,
supplanting dma_pfn_offset") always update dma_range_map even though it was
already set, like in the sunxi_mbus driver. the issue is reported a
The following commit has been merged into the efi/core branch of tip:
Commit-ID: 1c761ee9da1ac6ba7e40d14457fac94c87eaff35
Gitweb:
https://git.kernel.org/tip/1c761ee9da1ac6ba7e40d14457fac94c87eaff35
Author:Mark Brown
AuthorDate:Wed, 20 Jan 2021 16:38:10
Committer: Ard
The following commit has been merged into the efi/core branch of tip:
Commit-ID: 2f196059864fb0fe8f60c14a2cb214055b283e08
Gitweb:
https://git.kernel.org/tip/2f196059864fb0fe8f60c14a2cb214055b283e08
Author:Ard Biesheuvel
AuthorDate:Mon, 02 Nov 2020 17:11:49 +01:00
Committer
The following commit has been merged into the efi/core branch of tip:
Commit-ID: 514b1a8477d25a157f65bf52a443f8ffcc2eb54e
Gitweb:
https://git.kernel.org/tip/514b1a8477d25a157f65bf52a443f8ffcc2eb54e
Author:Ard Biesheuvel
AuthorDate:Tue, 19 Jan 2021 15:05:40 +01:00
Committer
Fiddling some more with a TLA+ model of set_cpus_allowed_ptr() & friends
unearthed one more outstanding issue. This doesn't even involve
migrate_disable(), but rather affinity changes and execution of the stopper
racing with each other.
My own interpretation of the (lengthy) TLA+ splat (note the p
Hi,
Sorry for the delay. I had time to do a full system upgrade yesterday
evening and fortunately Archlinux already ships 5.10.10, today I used
my computer as usual to test it. I haven't experienced the symptoms,
but since I disabled transparent huge pages it showed up sporadically.
If I face it ag
On 1/27/21 11:08 AM, Randy Dunlap wrote:
> On 1/27/21 6:44 AM, Stephen Rothwell wrote:
>> Hi all,
>>
>> Note: the patch file has failed to upload :-(
>>
>> Changes since 20210125:
>>
>
> on x86_64:
>
> ../drivers/gpu/drm/i915/i915_gem.c: In function ‘i915_gem_freeze_late’:
> ../drivers/gpu/drm/i9
Hi Greg,
This is habanalabs pull request for the merge window of kernel 5.12.
It contains changes and new features, support for new firmware.
Details are in the tag.
Thanks,
Oded
The following changes since commit 0fc99422bc034de018607ef6b70f92d4bc4a236d:
firmware: xilinx: Remove PM_API_MAX v
27.01.2021 13:16, Viresh Kumar пишет:
> There is no point calling dev_pm_opp_set_clkname() with the "name"
> parameter set to NULL, this is already done by the OPP core at setup
> time and should work as it is.
>
> Signed-off-by: Viresh Kumar
>
> ---
> V2: Update tegra124 as well.
>
> Krzysztof
On Wed, 27 Jan 2021, Vlastimil Babka wrote:
> The boot param and config determine the value of memcg_sysfs_enabled, which is
> unused since commit 10befea91b61 ("mm: memcg/slab: use a single set of
> kmem_caches for all allocations") as there are no per-memcg kmem caches
> anymore.
>
> Signed-off
Hi Mike,
Great ! it seems to work well - I have built a valila kernel v5.11-rc5
with your patch and it boots properly.
Full log available here:
https://gist.github.com/semihalf-majczak-lukasz/ea89bf52f6fad7907a18d1870e7ce9bd
Best regards,
Lukasz
śr., 27 sty 2021 o 19:27 Mike Rapoport napisał(a)
On Wed, Jan 27, 2021 at 03:05:24PM +0800, Boqun Feng wrote:
> On Tue, Jan 26, 2021 at 08:40:24PM -0800, Paul E. McKenney wrote:
> > On Wed, Jan 27, 2021 at 10:42:35AM +0800, Boqun Feng wrote:
> > > Hi Paul,
> > >
> > > On Tue, Jan 19, 2021 at 08:32:33PM -0800, paul...@kernel.org wrote:
> > > > Fro
601 - 700 of 1636 matches
Mail list logo
