It tries to check against all zeros and looped for quite a few times. However
after that we'll verify the same page with count_verify, while count_verify can
never be zero. So it means if it's a zero page we'll detect it anyways with
below code.
There's yet another place we conditionally check t
v2:
- rebase to v5.12-rc7-mmots-2021-04-11-20-49
- collect r-bs from Axel
I wanted to cleanup userfaultfd.c fault handling for a long time. If it's not
cleaned, when the new code grows the file it'll also grow the size that needs
to be cleaned... This is my attempt to cleanup the userfaultfd self
> + /* Some internal PHYs don't have a model number. */
> + if (reg == MII_PHYSID2 && !(val & 0x3f0) &&
> + chip->info->family < ARRAY_SIZE(family_prod_id_table)) {
> + prod_id = family_prod_id_table[chip->info->family];
> + if (prod_id)
> +
t match it does not set the gpio-bank as
valid.
The new GPIO driver appears to follow a similar method.
This will break the driver without a correction.
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/pinctrl/pinctrl-rockchip.c?h=next-20210412#n3836
>
> Signed
On 13/04/21 10:52 am, Andy Shevchenko wrote:
> On Mon, Mar 29, 2021 at 4:54 AM Chris Packham
> wrote:
>> Use device managed functions an clean up error handling.
> For the god sake how have you tested this?
> The patch is broken.
I've clearly missed the remove path in my testing. I was focused on
allnoconfig
i386 randconfig-a003-20210412
i386 randconfig-a001-20210412
i386 randconfig-a006-20210412
i386 randconfig-a005-20210412
i386 randconfig-a004-20210412
i386 randconfig-a002-20210412
x86_64
On Mon, 12 Apr 2021, at 16:20, Steven Lee wrote:
> The 04/09/2021 12:14, Andrew Jeffery wrote:
> > Hi Steven,
> >
> > On Thu, 8 Apr 2021, at 11:22, Steven Lee wrote:
> > > AST2600-A2 EVB provides reference design to support toggling signal
> > > voltage between 3.3v and 1.8v by power-switch-gpi
The DSDT and ACPI should be capitalized.
Signed-off-by: Andy Shevchenko
---
v2: split from patch 1 as per Rafael's request
drivers/acpi/utils.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/acpi/utils.c b/drivers/acpi/utils.c
index 60e46efc1bc8..3b54b8fd7396 100
The macro requires to call acpi_dev_put() on each iteration.
Due to this it doesn't tolerate sudden disappearence of the devices.
Document all these nuances to prevent users blindly call it without
understanding the possible issues.
While at it, add the note to the acpi_dev_get_next_match_dev() a
On Mon, Apr 12, 2021 at 10:37:10PM +0200, Thomas Gleixner wrote:
> On Mon, Apr 12 2021 at 12:57, Paul E. McKenney wrote:
> > On Mon, Apr 12, 2021 at 08:54:03PM +0200, Thomas Gleixner wrote:
> >> > I will send a new series out later today, Pacific Time.
> >>
> >> Can you do me a favour and send it
Fix coccicheck warning:
./tools/perf/util/evlist.c:1316:5-8: Unneeded variable: "err". Return "-
ENOMEM" on line 1341
Signed-off-by: Wan Jiabing
---
tools/perf/util/evlist.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.
Dave,
On Tue, Apr 13 2021 at 08:15, Dave Chinner wrote:
> On Mon, Apr 12, 2021 at 05:20:53PM +0200, Thomas Gleixner wrote:
>> On Wed, Apr 07 2021 at 07:22, Dave Chinner wrote:
>> > And, FWIW, I'm also aware of the problems that RT kernels have with
>> > the use of bit spinlocks and being unable to
On Thu, Apr 08, 2021 at 04:43:22PM -0700, Axel Rasmussen wrote:
> +/*
> + * Install PTEs, to map dst_addr (within dst_vma) to page.
> + *
> + * This function handles MCOPY_ATOMIC_CONTINUE (which is always file-backed),
> + * whether or not dst_vma is VM_SHARED. It also handles the more general
> +
Bjorn,
On Mon, Mar 15, 2021 at 1:39 PM Douglas Anderson wrote:
>
> This was present downstream. Add upstream too. NOTE: upstream I
> managed to get some sort of halfway state and got one pinctrl entry in
> the coachz-r1 device tree. Remove that as part of this since it's now
> in the dtsi.
>
> Cc
On Mon, Apr 12, 2021 at 4:10 PM Shakeel Butt wrote:
>
> On Mon, Apr 12, 2021 at 3:55 PM Waiman Long wrote:
> >
> > Most kmem_cache_alloc() calls are from user context. With instrumentation
> > enabled, the measured amount of kmem_cache_alloc() calls from non-task
> > context was about 0.01% of th
On Tue, Apr 13, 2021 at 01:09, Tobias Waldekranz wrote:
> On Tue, Apr 13, 2021 at 00:55, Marek Behun wrote:
>> On Tue, 13 Apr 2021 00:05:51 +0200
>> Tobias Waldekranz wrote:
>>
>>> On Mon, Apr 12, 2021 at 23:50, Marek Behun wrote:
>>> > On Mon, 12 Apr 2021 23:22:45 +0200
>>> > Tobias Waldekranz
On Mon, Apr 12, 2021 at 3:55 PM Waiman Long wrote:
>
> Most kmem_cache_alloc() calls are from user context. With instrumentation
> enabled, the measured amount of kmem_cache_alloc() calls from non-task
> context was about 0.01% of the total.
>
> The irq disable/enable sequence used in this case to
On Mon, Apr 12, 2021 at 3:55 PM Waiman Long wrote:
>
> The object stock data stored in struct memcg_stock_pcp are independent
> of the other page based data stored there. Separating them out into
> their own struct to highlight the independency.
>
> Signed-off-by: Waiman Long
> Acked-by: Roman Gu
On Tue, Apr 13, 2021 at 00:55, Marek Behun wrote:
> On Tue, 13 Apr 2021 00:05:51 +0200
> Tobias Waldekranz wrote:
>
>> On Mon, Apr 12, 2021 at 23:50, Marek Behun wrote:
>> > On Mon, 12 Apr 2021 23:22:45 +0200
>> > Tobias Waldekranz wrote:
>> >
>> >> On Mon, Apr 12, 2021 at 21:30, Marek Behun
On Tue, 13 Apr 2021 01:48:05 +0300
Vladimir Oltean wrote:
> On Tue, Apr 13, 2021 at 12:26:52AM +0200, Tobias Waldekranz wrote:
> > On Tue, Apr 13, 2021 at 01:06, Vladimir Oltean wrote:
> > > On Mon, Apr 12, 2021 at 11:49:22PM +0200, Tobias Waldekranz wrote:
> > >> On Tue, Apr 13, 2021 at 00:
On Mon, Apr 12, 2021 at 3:55 PM Waiman Long wrote:
>
> Before the new slab memory controller with per object byte charging,
> charging and vmstat data update happen only when new slab pages are
> allocated or freed. Now they are done with every kmem_cache_alloc()
> and kmem_cache_free(). This caus
Fix typo in max8925 vendor prefix.
Cc: Lubomir Rintel
Signed-off-by: Sebastian Reichel
---
arch/arm/boot/dts/mmp2-brownstone.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/mmp2-brownstone.dts
b/arch/arm/boot/dts/mmp2-brownstone.dts
index 04f1ae1382e7.
Convert the binding to DT schema format.
I slightly modified the binding by allowing regulator-[0-9] and cable-[0-9]
instead of regulator@[0-9] and cable@[0-9], so that DT compiler does not
complain about missing 'reg' property. The driver actually ignores the
nodename and can handle both styles.
Convert the binding to DT schema format.
The sub-functions of this MFD device do not have their own compatible
string and are thus described directly in the MFD binding document
after being converted to YAML.
Signed-off-by: Sebastian Reichel
---
.../leds/backlight/max8925-backlight.txt |
Hi,
Let's get rid of the remaining three non-YAML power-supply binding files.
1. charger-manager
I initially skipped this, since the binding is quite complex.
It turned out a basic yaml binding is not that complex.
This does not check for supplies matching cm-regulator-name,
but that
Fix interrupt cells in DT AB8500/AB8505 source files. The
compiled DTB files will stay the same.
Signed-off-by: Sebastian Reichel
---
arch/arm/boot/dts/ste-ab8500.dtsi | 26 +-
arch/arm/boot/dts/ste-ab8505.dtsi | 22 +++---
2 files changed, 24 insertions(+
Convert the binding to DT schema format.
I slightly modified the binding by renaming the gpio node from
ab8500-gpio to ab8500-gpiocontroller, since the -gpio suffix
is used for gpio consumers.
Signed-off-by: Sebastian Reichel
---
.../devicetree/bindings/mfd/ab8500.txt| 280 ---
.../
Rename the AB8500 gpio controller node from ab8500-gpio to
ab8500-gpiocontroller, since -gpio is a common suffix for
gpio consumers.
Signed-off-by: Sebastian Reichel
---
arch/arm/boot/dts/ste-ab8500.dtsi | 2 +-
arch/arm/boot/dts/ste-ab8505.dtsi | 2 +-
arch/arm/boot/dts/ste-href-ab850
On Wed, Mar 31, 2021 at 08:43:12PM +0200, Håkon Bugge wrote:
> ib_modify_qp() is an expensive operation on some HCAs running
> virtualized. This series removes two ib_modify_qp() calls from RDS.
>
> I am sending this as a v3, even though it is the first sent to
> net. This because the IB Core comm
On Sat, Apr 10, 2021 at 11:15 PM Wolfram Sang wrote:
>
> On Mon, Mar 29, 2021 at 02:52:06PM +1300, Chris Packham wrote:
> > The fsl-i2c controller will generate an interrupt after every byte
> > transferred. Make use of this interrupt to drive a state machine which
> > allows the next part of a tr
The caller of mod_memcg_lruvec_state() has both memcg and lruvec readily
available. So both of them are now passed to mod_memcg_lruvec_state()
and __mod_memcg_lruvec_state(). The __mod_memcg_lruvec_state() is
updated to allow either of the two parameters to be set to null. This
makes mod_memcg_lruv
The object stock data stored in struct memcg_stock_pcp are independent
of the other page based data stored there. Separating them out into
their own struct to highlight the independency.
Signed-off-by: Waiman Long
Acked-by: Roman Gushchin
---
mm/memcontrol.c | 41 ++-
v2:
- Fix bug found by test robot in patch 5.
- Update cover letter and commit logs.
With the recent introduction of the new slab memory controller, we
eliminate the need for having separate kmemcaches for each memory
cgroup and reduce overall kernel memory usage. However, we also add
additio
On Tue, 13 Apr 2021 00:05:51 +0200
Tobias Waldekranz wrote:
> On Mon, Apr 12, 2021 at 23:50, Marek Behun wrote:
> > On Mon, 12 Apr 2021 23:22:45 +0200
> > Tobias Waldekranz wrote:
> >
> >> On Mon, Apr 12, 2021 at 21:30, Marek Behun wrote:
> >> > On Mon, 12 Apr 2021 14:46:11 +0200
> >> > To
Most kmem_cache_alloc() calls are from user context. With instrumentation
enabled, the measured amount of kmem_cache_alloc() calls from non-task
context was about 0.01% of the total.
The irq disable/enable sequence used in this case to access content
from object stock is slow. To optimize for use
In memcg_slab_free_hook()/pcpu_memcg_free_hook(), obj_cgroup_uncharge()
is followed by mod_objcg_state()/mod_memcg_state(). Each of these
function call goes through a separate irq_save/irq_restore cycle. That
is inefficient. Introduce a new function obj_cgroup_uncharge_mod_state()
that combines th
Before the new slab memory controller with per object byte charging,
charging and vmstat data update happen only when new slab pages are
allocated or freed. Now they are done with every kmem_cache_alloc()
and kmem_cache_free(). This causes additional overhead for workloads
that generate a lot of al
On Tue, Apr 13, 2021 at 1:52 AM Andy Shevchenko
wrote:
>
> On Mon, Mar 29, 2021 at 4:54 AM Chris Packham
> wrote:
> >
> > Use device managed functions an clean up error handling.
>
> For the god sake how have you tested this?
> The patch is broken.
Looking into i2c-next and taking into account w
On Mon, Mar 29, 2021 at 4:54 AM Chris Packham
wrote:
>
> Use device managed functions an clean up error handling.
For the god sake how have you tested this?
The patch is broken.
--
With Best Regards,
Andy Shevchenko
-randconfig-r005-20210412 (attached as .config)
compiler: csky-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
#
https://git.kernel.org/pub/scm
On Mon, Apr 12, 2021 at 04:20:47PM -0400, Tom Talpey wrote:
> So the issue is only in testing all the providers and platforms,
> to be sure this new behavior isn't tickling anything that went
> unnoticed all along, because no RDMA provider ever issued RO.
The mlx5 ethernet driver has run in RO mo
On Tue, Apr 13, 2021 at 12:26:52AM +0200, Tobias Waldekranz wrote:
> On Tue, Apr 13, 2021 at 01:06, Vladimir Oltean wrote:
> > On Mon, Apr 12, 2021 at 11:49:22PM +0200, Tobias Waldekranz wrote:
> >> On Tue, Apr 13, 2021 at 00:34, Vladimir Oltean wrote:
> >> > On Mon, Apr 12, 2021 at 11:22:45PM +0
On Tue, 13 Apr 2021 01:17:21 +0300
Vladimir Oltean wrote:
> On Tue, Apr 13, 2021 at 12:04:57AM +0200, Marek Behun wrote:
> > On Mon, 12 Apr 2021 19:32:11 +0300
> > Vladimir Oltean wrote:
> >
> > > On Mon, Apr 12, 2021 at 11:00:45PM +0800, DENG Qingfang wrote:
> > > > On Sun, Apr 11, 2021 at
From: Aili Yao
When the page is already poisoned, another memory_failure() call in the
same page now returns 0, meaning OK. For nested memory mce handling, this
behavior may lead to one mce looping, Example:
1. When LCME is enabled, and there are two processes A && B running on
different core X
From: Naoya Horiguchi
The previous patch solves the infinite MCE loop issue when multiple
MCE events races. The remaining issue is to make sure that all threads
processing Action Required MCEs send to the current processes the
SIGBUS with the proper virtual address and the error size.
This patc
On Mon, Apr 12, 2021 at 12:42 PM Johannes Berg
wrote:
>
> From: Johannes Berg
>
> With clang-11+, the code is broken due to my kvmalloc() conversion
> (which predated the clang-11 support code) leaving one vmalloc()
> in place. Fix that.
>
> Signed-off-by: Johannes Berg
> ---
> This fixes a clan
From: Tony Luck
There can be races when multiple CPUs consume poison from the same
page. The first into memory_failure() atomically sets the HWPoison
page flag and begins hunting for tasks that map this page. Eventually
it invalidates those mappings and may send a SIGBUS to the affected
tasks.
B
Hi,
I wrote this patchset to materialize what I think is the current
allowable solution mentioned by the previous discussion [1].
I simply borrowed Tony's mutex patch and Aili's return code patch,
then I queued another one to find error virtual address in the best
effort manner. I know that this
On Sun, 2021-04-11 at 02:45 +0100, Salil Mehta wrote:
> If user has explicitly requested the number of {R,T}XQs, then it is
> unnecessary
> to get the count of already available {R,T}XQs from the PF
> avail_{r,t}xqs
> bitmap. This value will get overriden by user specified value in any
s/override
Currently all gpio nodenames are sort of identical to there label.
Nodenames should be of a generic type, so change them all.
Signed-off-by: Johan Jonker
---
arch/arm64/boot/dts/rockchip/px30.dtsi | 8
arch/arm64/boot/dts/rockchip/rk3308.dtsi | 10 +-
arch/arm64/boot/dts/rock
Current dts files with "rockchip,gpio-bank" subnodes
are manually verified. In order to automate this process
the text that describes the compatible in rockchip,pinctrl.txt
is removed and converted to YAML in rockchip,gpio-bank.yaml.
Signed-off-by: Johan Jonker
---
Changed V2:
changed example g
Currently all gpio nodenames are sort of identical to there label.
Nodenames should be of a generic type, so change them all.
Signed-off-by: Johan Jonker
---
arch/arm/boot/dts/rk3036.dtsi | 6 +++---
arch/arm/boot/dts/rk3066a.dtsi | 12 ++--
arch/arm/boot/dts/rk3188.dtsi | 8
On Mar 26, 2021, at 03:30, Borislav Petkov wrote:
> On Thu, Mar 25, 2021 at 09:56:53PM -0700, Andy Lutomirski wrote:
>> We really ought to have a SIGSIGFAIL signal that's sent, double-fault
>> style, when we fail to send a signal.
>
> Yeap, we should be able to tell userspace that we couldn't sen
On Fri, Apr 09, 2021 at 02:36:16PM +1000, Alexey Kardashevskiy wrote:
> On 08/04/2021 19:04, Michael Ellerman wrote:
> +#define QUERY_DDW_PGSIZE_4K 0x01
> +#define QUERY_DDW_PGSIZE_64K 0x02
> +#define QUERY_DDW_PGSIZE_16M 0x04
> +#define QUERY_DDW_PGSIZE_32M 0x08
>
On Mon, 2021-04-12 at 11:20 +0100, Jonathan Cameron wrote:
> On Sun, 11 Apr 2021 09:06:35 -0700
> Srinivas Pandruvada wrote:
>
> > On Sun, 2021-04-11 at 14:56 +0100, Jonathan Cameron wrote:
> > > On Fri, 09 Apr 2021 11:19:12 -0700
> > > Srinivas Pandruvada wrote:
> > >
> > > > On Fri, 2021-04
On Tue, Apr 13, 2021 at 01:06, Vladimir Oltean wrote:
> On Mon, Apr 12, 2021 at 11:49:22PM +0200, Tobias Waldekranz wrote:
>> On Tue, Apr 13, 2021 at 00:34, Vladimir Oltean wrote:
>> > On Mon, Apr 12, 2021 at 11:22:45PM +0200, Tobias Waldekranz wrote:
>> >> On Mon, Apr 12, 2021 at 21:30, Marek Be
Introduce acpi_dev_get() to have a symmetrical API with acpi_dev_put()
and reuse both in ACPI code under drivers/acpi folder.
While at it, use acpi_bus_put_acpi_device() in one place rather than above.
Signed-off-by: Andy Shevchenko
---
v2: made acpi_dev_get() to return pointer as get_device() d
Hi Andrew,
On Mon, Apr 12, 2021 at 1:16 AM Andrew Lunn wrote:
>
> On Sun, Apr 11, 2021 at 10:55:11PM +0200, Martin Blumenstingl wrote:
> > Add support for .get_regs_len and .get_regs so it is easier to find out
> > about the state of the ports on the GSWIP hardware. For this we
> > specifically a
Convert a comment above kvm_io_bus_unregister_dev() into an actual
lockdep assertion, and opportunistically add curly braces to a multi-line
for-loop.
Signed-off-by: Sean Christopherson
---
virt/kvm/kvm_main.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/virt/kvm/kvm
Align line break to match with the open parenthesis.
Issue detected by checkpatch.pl.
It consequently solved a few end lines with a '(',
issue also detected by checkpatch.pl
Signed-off-by: Aline Santana Cordeiro
---
drivers/staging/media/tegra-vde/trace.h | 111 ++--
On Mon, Apr 12, 2021 at 1:42 PM Brendan Higgins
wrote:
>
> On Mon, Apr 12, 2021 at 10:27 AM Daniel Latypov wrote:
> >
> > hOn Fri, Apr 9, 2021 at 9:10 PM David Gow wrote:
> > >
> > > Thanks for writing this: it's good to have these things documented at
> > > last!
> > >
> > > There are definite
Abort the walk of coalesced MMIO zones if kvm_io_bus_unregister_dev()
fails to allocate memory for the new instance of the bus. If it can't
instantiate a new bus, unregister_dev() destroys all devices _except_ the
target device. But, it doesn't tell the caller that it obliterated the
bus and inv
If allocating a new instance of an I/O bus fails when unregistering a
device, wait to destroy the device until after all readers are guaranteed
to see the new null bus. Destroying devices before the bus is nullified
could lead to use-after-free since readers expect the devices on their
reference o
Fix two bugs that are exposed if unregistered a device on an I/O bus fails
due to OOM. Tack on opportunistic cleanup in the related code.
Sean Christopherson (3):
KVM: Destroy I/O bus devices on unregister failure _after_ sync'ing
SRCU
KVM: Stop looking for coalesced MMIO zones if the bu
On Tue, Apr 13, 2021 at 12:04:57AM +0200, Marek Behun wrote:
> On Mon, 12 Apr 2021 19:32:11 +0300
> Vladimir Oltean wrote:
>
> > On Mon, Apr 12, 2021 at 11:00:45PM +0800, DENG Qingfang wrote:
> > > On Sun, Apr 11, 2021 at 09:50:17PM +0300, Vladimir Oltean wrote:
> > > >
> > > > So I'd be tempted t
On Mon, Apr 12, 2021 at 05:20:53PM +0200, Thomas Gleixner wrote:
> Dave,
>
> On Wed, Apr 07 2021 at 07:22, Dave Chinner wrote:
> > On Tue, Apr 06, 2021 at 02:28:34PM +0100, Matthew Wilcox wrote:
> >> On Tue, Apr 06, 2021 at 10:33:43PM +1000, Dave Chinner wrote:
> >> > +++ b/fs/inode.c
> >> > @@ -5
Hi!
On Thu, Apr 08, 2021 at 03:33:45PM +, Christophe Leroy wrote:
> +#define ATOMIC_OP(op, asm_op, dot, sign) \
> static __inline__ void atomic_##op(int a, atomic_t *v)
> \
> {
test_implicit_mprotect_exec_only_memory() hits an assert in
_read_pkey_reg() when DEBUG_LEVEL=2.
test 12 starting with pkey: 2
doing malloc_pkey_anon_huge(size=4096, prot=0x3, pkey=2)
new_nr_records: 1
new_size: 24
sys_mprotect_pkey(0x0x7f44144bb000, 40, prot=3, pkey=2)
mprotect_pkey(0x7f44144
Add little script to generate QT Creator project files, so that parsing
and navigating codebase mostly works.
The important part is to run 'make prepare' before opening project
so that generated headers are picked up and clone&fixup coding style
in the editor to match kernel coding style.
Then ru
[ 27.075563] msr: Write to unrecognized MSR 0x1b0 by x86_energy_perf (pid:
1223).
[ 27.078979] msr: See
https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/about for details.
(aka x86_energy_perf_policy)
on linux-next-20210409 / x86_64.
--
~Randy
On Mon, Apr 12, 2021 at 11:49:22PM +0200, Tobias Waldekranz wrote:
> On Tue, Apr 13, 2021 at 00:34, Vladimir Oltean wrote:
> > On Mon, Apr 12, 2021 at 11:22:45PM +0200, Tobias Waldekranz wrote:
> >> On Mon, Apr 12, 2021 at 21:30, Marek Behun wrote:
> >> > On Mon, 12 Apr 2021 14:46:11 +0200
> >> >
On Mon, Apr 12, 2021 at 10:39:38AM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.4.112 release.
> There are 111 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 kno
On Mon, Apr 12, 2021 at 23:50, Marek Behun wrote:
> On Mon, 12 Apr 2021 23:22:45 +0200
> Tobias Waldekranz wrote:
>
>> On Mon, Apr 12, 2021 at 21:30, Marek Behun wrote:
>> > On Mon, 12 Apr 2021 14:46:11 +0200
>> > Tobias Waldekranz wrote:
>> >
>> >> I agree. Unless you only have a few really
On Mon, Apr 12, 2021 at 10:40:06AM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.19.187 release.
> There are 66 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 kno
Video demonstration: https://youtu.be/3nkvUeB0GSw
How looks kernel traces.
1.
[ 7315.156460] amdgpu :0b:00.0: amdgpu: [mmhub] page fault
(src_id:0 ring:0 vmid:6 pasid:32779, for process obs pid 23963 thread
obs:cs0 pid 23977)
[ 7315.156490] amdgpu :0b:00.0: amdgpu: in page starting at
a
On Mon, 12 Apr 2021 19:32:11 +0300
Vladimir Oltean wrote:
> On Mon, Apr 12, 2021 at 11:00:45PM +0800, DENG Qingfang wrote:
> > On Sun, Apr 11, 2021 at 09:50:17PM +0300, Vladimir Oltean wrote:
> > >
> > > So I'd be tempted to say 'tough luck' if all your ports are not up, and
> > > the ones that
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 89698becf06d341a700913c3d89ce2a914af69a2
commit: 8f28ca6bd8211214faf717677bbffe375c2a6072 iomap: constify ioreadX()
iomem argument (as in generic implementation)
date: 8 months ago
config: x86_64-randconfi
Hi!
On Thu, Apr 08, 2021 at 03:33:44PM +, Christophe Leroy wrote:
> For clear bits, on 32 bits 'rlwinm' can be used instead or 'andc' for
> when all bits to be cleared are consecutive.
Also on 64-bits, as long as both the top and bottom bits are in the low
32-bit half (for 32 bit mode, it can
On Mon, 12 Apr 2021 23:49:22 +0200
Tobias Waldekranz wrote:
> On Tue, Apr 13, 2021 at 00:34, Vladimir Oltean wrote:
> > On Mon, Apr 12, 2021 at 11:22:45PM +0200, Tobias Waldekranz wrote:
> >> On Mon, Apr 12, 2021 at 21:30, Marek Behun wrote:
> >> > On Mon, 12 Apr 2021 14:46:11 +0200
> >> >
On Mon, Apr 12, 2021 at 7:33 PM Palmer Dabbelt wrote:
>
> On Mon, 12 Apr 2021 06:32:27 PDT (-0700), christoph...@gmail.com wrote:
> > On Sun, Apr 11, 2021 at 11:11 PM Palmer Dabbelt wrote:
> >>
> >> On Wed, 24 Mar 2021 05:53:51 PDT (-0700), a...@brainfault.org wrote:
> >> > On Wed, Mar 24, 2021 a
[+cc Matthew for portdrv comment]
On Mon, Apr 12, 2021 at 10:31:02PM +0530, Vidya Sagar wrote:
> Hi
> I'm starting this mail to seek advice on the best approach to be taken to
> add support for the driver of the PCIe root port's DMA engine.
> To give some background, Tegra194's PCIe IPs are dual-m
Hi, Hugh,
On Tue, Apr 06, 2021 at 11:14:30PM -0700, Hugh Dickins wrote:
> > +static int mcopy_atomic_install_ptes(struct mm_struct *dst_mm, pmd_t
> > *dst_pmd,
> > +struct vm_area_struct *dst_vma,
> > +unsigned long dst_addr, struct
kerneljasonx...@gmail.com wrote:
> From: Jason Xing
>
> Re: [PATCH] i40e: fix the panic when running bpf in xdpdrv mode
Please use netdev style subject lines when patching net kernel to
indicate which kernel tree this is targeted at, "net" or "net-next"
[PATCH net v2] i40e: ...
> Fix this by a
On Mon, Apr 12, 2021 at 04:40:01PM -0300, Pedro Tammela wrote:
> Follows the same logic as the hashtable tests.
>
> Signed-off-by: Pedro Tammela
> ---
> .../bpf/map_tests/array_map_batch_ops.c | 110 +-
> 1 file changed, 80 insertions(+), 30 deletions(-)
>
> diff --git a/t
On Mon, 12 Apr 2021 23:22:45 +0200
Tobias Waldekranz wrote:
> On Mon, Apr 12, 2021 at 21:30, Marek Behun wrote:
> > On Mon, 12 Apr 2021 14:46:11 +0200
> > Tobias Waldekranz wrote:
> >
> >> I agree. Unless you only have a few really wideband flows, a LAG will
> >> typically do a great job with
On Tue, Apr 13, 2021 at 00:34, Vladimir Oltean wrote:
> On Mon, Apr 12, 2021 at 11:22:45PM +0200, Tobias Waldekranz wrote:
>> On Mon, Apr 12, 2021 at 21:30, Marek Behun wrote:
>> > On Mon, 12 Apr 2021 14:46:11 +0200
>> > Tobias Waldekranz wrote:
>> >
>> >> I agree. Unless you only have a few rea
When mmaping an extra device region verify that the region index
derived from the mmap offset is valid.
Fixes: a15b1883fee1 ("vfio_pci: Allow mapping extra regions")
Cc: sta...@vger.kernel.org
Signed-off-by: Christian A. Ehrhardt
---
drivers/vfio/pci/vfio_pci.c | 4 +++-
1 file changed, 3 inse
On 4/12/21 10:57 PM, Rob Herring wrote:
> On Sun, 11 Apr 2021 15:10:02 +0200, Johan Jonker wrote:
>> Current dts files with 'pwm' nodes are manually verified.
>> In order to automate this process pwm-rockchip.txt
>> has to be converted to yaml.
>>
>> Signed-off-by: Johan Jonker
>> ---
>> Changed V
On Mon, Apr 12 2021 at 12:56, Mel Gorman wrote:
> On Fri, Apr 09, 2021 at 08:55:39PM +0200, Peter Zijlstra wrote:
> I'll update the changelog and comment accordingly. I'll decide later
> whether to leave it or move the location of the lock at the end of the
> series. If the patch is added, it'll ei
On Fri, Apr 09, 2021, Lai Jiangshan wrote:
> On Fri, Nov 27, 2020 at 7:26 PM Paolo Bonzini wrote:
> >
> > kvm_cpu_accept_dm_intr and kvm_vcpu_ready_for_interrupt_injection are
> > a hodge-podge of conditions, hacked together to get something that
> > more or less works. But what is actually neede
On 3/1/21 11:51 PM, Bard Liao wrote:
> +++ b/drivers/soundwire/dmi-quirks.c
> @@ -0,0 +1,66 @@
> +// SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause)
> +// Copyright(c) 2021 Intel Corporation.
It looks like this is already in intel-next, so this may be moot. But,
is there a specific reason this
On Mon, Apr 12, 2021 at 11:22:45PM +0200, Tobias Waldekranz wrote:
> On Mon, Apr 12, 2021 at 21:30, Marek Behun wrote:
> > On Mon, 12 Apr 2021 14:46:11 +0200
> > Tobias Waldekranz wrote:
> >
> >> I agree. Unless you only have a few really wideband flows, a LAG will
> >> typically do a great job w
Hello:
This patch was applied to netdev/net.git (refs/heads/master):
On Mon, 12 Apr 2021 18:57:39 +0200 you wrote:
> Since commit fee2d546414d ("net: phy: marvell: mv88e6390 temperature
> sensor reading"), Linux reports the temperature of Topaz hwmon as
> constant -75°C.
>
> This is because swit
On 2/12/21 2:22 PM, mgr...@linux.intel.com wrote:
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +# Copyright (c) Intel Corporation. All rights reserved.
> +%YAML 1.2
> +---
> +$id: "http://devicetree.org/schemas/misc/intel,keembay-xlink.yaml#";
> +$schema: "http://devicetree.org/meta-sc
Hi Beatriz,
Thanks for the patch.
On Mon, Apr 12, 2021 at 02:43:01PM +0100, Beatriz Martins de Carvalho wrote:
> Aligns line break with the remaining function arguments
> to the open parenthesis.
> Issue found by checkpatch in file atomisp-gc2235.c
>
> Signed-off-by: Beatriz Martins de Carvalho
On Mon, Apr 12, 2021 at 3:43 AM Marco Elver wrote:
>
> On Sat, 10 Apr 2021 at 13:53, Daniel Latypov wrote:
> > On Sat, Apr 10, 2021 at 12:05 AM David Gow wrote:
> [...]
> > > +
> > > +
> > > +Sanitizers
> > > +==
> > > +
>
> The "sanitizers" have originally been a group of tools that rel
Hi Mitali,
On Mon, Apr 12, 2021 at 07:59:29PM +0530, Mitali Borkar wrote:
> On Mon, Apr 12, 2021 at 12:43:15PM +0300, Sakari Ailus wrote:
> > Hi Mitali,
> >
> > On Mon, Apr 12, 2021 at 04:38:59AM +0530, Mitali Borkar wrote:
> > > This patch fixes the warning identified by checkpatch.pl by replaci
On Mon, Mar 8, 2021 at 2:20 PM mark gross wrote:
>
> On Fri, Mar 05, 2021 at 03:01:40PM -0600, Rob Herring wrote:
> > On Fri, Feb 12, 2021 at 02:22:34PM -0800, mgr...@linux.intel.com wrote:
> > > From: Daniele Alessandrelli
> > >
> > > Add DT binding documentation for the Intel Keem Bay IPC drive
On Tue, Mar 30, 2021 at 2:22 AM Leo Yan wrote:
>
> On Tue, Mar 30, 2021 at 02:48:40PM +0800, Hao Fang wrote:
> > s/Hisilicon/HiSilicon/g.
> > It should use capital S, according to
> > https://www.hisilicon.com/en/terms-of-use.
> >
> > Signed-off-by: Hao Fang
>
> Though the kernel has tons of "His
On Thu, Apr 08, 2021 at 04:03:46PM +0800, Lu Jialin wrote:
> Change hierachy to hierarchy and unrechable to unreachable,
> no functionality changed.
>
> Signed-off-by: Lu Jialin
Applied to cgroup/for-5.13.
Thanks.
--
tejun
301 - 400 of 2283 matches
Mail list logo
