On Fri, 29 Jan 2021 16:50:40 +0800, Artem Lapkin wrote:
> move _emmc_a ... from /* */ commented area, because cant load wifi fw
> without sd-uhs-sdr50 option on VIM3L
>
> [ 11.686590] brcmfmac: brcmf_chip_cores_check: CPU core not detected
> [ 11.696382] brcmfmac: brcmf_sdio_probe_attach:
On Tue, 2 Feb 2021 02:10:16 +, Christian Hewitt wrote:
> This series fixes minor sort-order issues in the Amlogic bindings yaml and
> dtb Makefile, then converts the existing ODROID-C4 dts into dtsi so we can
> support its new sister product the ODROID-HC4.
>
> I've also given the devices
On Wed, Feb 03, 2021 at 01:26:37PM -0600, Mario Limonciello wrote:
> A user without a Dell system doesn't need to pick any of these
> drivers.
>
> Suggested-by: Andy Shevchenko
> Signed-off-by: Mario Limonciello
You are fast, thanks!
...
> +menuconfig DELL_X86_PLATFORM_DRIVERS
I'm not sure
On Wed, Feb 03, 2021 at 01:49:22PM +0100, Christoph Hellwig wrote:
> On Mon, Jan 18, 2021 at 12:44:58PM +0100, Martin Radev wrote:
> > Your comment makes sense but then that would require the cooperation
> > of these vendors and the cloud providers to agree on something meaningful.
> > I am also
On Mon, Feb 01, 2021 at 12:47:55PM +0100, Michal Hocko wrote:
> On Fri 29-01-21 17:35:31, Uladzislau Rezki wrote:
> > On Fri, Jan 29, 2021 at 09:56:29AM +0100, Michal Hocko wrote:
> > > On Thu 28-01-21 19:02:37, Uladzislau Rezki wrote:
> > > [...]
> > > > >From
The pull request you sent on Wed, 3 Feb 2021 14:08:57 +0100:
> git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux.git
> tags/gpio-fixes-for-v5.11-rc7
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/40615974f88a918d01606ba27d75de2ff50b8d4e
Thank you!
--
The pull request you sent on Wed, 3 Feb 2021 18:44:11 +:
> git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux tags/arm64-fixes
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/3afe9076a7c19140b789d144d0ba1e9be2db4265
Thank you!
--
Deet-doot-dot, I am a
On Wed, Feb 03, 2021 at 11:29:39AM -0800, Andy Lutomirski wrote:
> That function is a lie. It tries to keep the system alive but it
> doesn’t return if it “recovers”. Maybe I should add a comment?
... or rename it?
That schedule() at the end, I dunno if that does anything since we're
going to
On Wed, Feb 03, 2021 at 04:50:07PM +, Richard Fitzgerald wrote:
> The existing code attempted to handle numbers by doing a strto[u]l(),
> ignoring the field width, and then repeatedly dividing to extract the
> field out of the full converted value. If the string contains a run of
> valid
Em Tue, Feb 02, 2021 at 12:09:08PM -0800, kan.li...@linux.intel.com escreveu:
> From: Kan Liang
Hey Joe, heads up on these new fields.
The whole thread is at:
https://lore.kernel.org/lkml/1612296553-21962-1-git-send-email-kan.li...@linux.intel.com/
The kernel cset introducing the support:
On Tue, Feb 02, 2021 at 02:38:20PM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.255 release.
> There are 28 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
On Wed, Feb 3, 2021 at 9:29 PM Daniel Vetter wrote:
>
> On Wed, Feb 3, 2021 at 9:20 PM Suren Baghdasaryan wrote:
> >
> > On Wed, Feb 3, 2021 at 12:52 AM Daniel Vetter
> > wrote:
> > >
> > > On Wed, Feb 3, 2021 at 2:57 AM Matthew Wilcox wrote:
> > > >
> > > > On Tue, Feb 02, 2021 at 04:31:33PM
On Wed, Feb 3, 2021 at 5:42 PM Alex Deucher wrote:
>
> On Wed, Feb 3, 2021 at 9:42 AM Daniel Vetter wrote:
> >
> > On Wed, Feb 3, 2021 at 3:33 PM Bridgman, John wrote:
> > >
> > > >>Uh, that doesn't work. If you want infinite compute queues you need the
> > > amdkfd model with preempt-ctx
Since memcg_shrinker_map_size just can be changed under holding shrinker_rwsem
exclusively, the read side can be protected by holding read lock, so it sounds
superfluous to have a dedicated mutex.
Kirill Tkhai suggested use write lock since:
* We want the assignment to shrinker_maps is visible
On Wed, Feb 3, 2021 at 6:14 PM Daniel Vetter wrote:
>
> On Wed, Feb 3, 2021 at 5:42 PM Alex Deucher wrote:
> >
> > On Wed, Feb 3, 2021 at 9:42 AM Daniel Vetter wrote:
> > >
> > > On Wed, Feb 3, 2021 at 3:33 PM Bridgman, John
> > > wrote:
> > > >
> > > > >>Uh, that doesn't work. If you want
On Wed, Feb 03, 2021 at 05:05:43PM +0100, Pavel Machek wrote:
> On Mon 2021-02-01 11:52:12, Dmitry Vyukov wrote:
> Could we please get common prefix (like syzbot: KASAN:) so that
> the bulk of emails is easier to remove?
There are several bots testing on the kernel, maybe we should give a
ell
>> Date: Tue, 2 Feb 2021 19:49:00 +1100
>> Subject: [PATCH] make is_pinnable_page a macro
>>
>> As it is currently defined before page_to_section() which it needs.
>>
>> Signed-off-by: Stephen Rothwell
>
> I still see the same problem in next-20210203,
On Wed, 3 Feb 2021 at 18:09, Qais Yousef wrote:
>
> On 01/29/21 18:27, Vincent Guittot wrote:
> > The patch below moves the update of the blocked load of CPUs outside
> > newidle_balance().
> >
> > Instead, the update is done with the usual idle load balance update. I'm
> > working on an
> >
Hi Takashi,
On 03.02.2021 17:59, Takashi Iwai wrote:
On Tue, 02 Feb 2021 00:18:09 +0100,
Anton Yakovlev wrote:
+/**
+ * virtsnd_reset_fn() - Kernel worker's function to reset the device.
+ * @work: Reset device work.
+ *
+ * Context: Process context.
+ */
+static void virtsnd_reset_fn(struct
When the driver is compiled as a module and loaded if we try to unload
it, the Kernel shows a crash log. This Kernel crash is due to the
dma_async_device_unregister() call done after deleting the channels,
this patch fixes this issue.
Signed-off-by: Gustavo Pimentel
---
Move struct dentry variable from static definition (dw-edma-v0-debugfs.c)
into dw_edma struct (dw-edma-core.h)
Also the variable was renamed from base_dir to debugfs.
Signed-off-by: Gustavo Pimentel
---
drivers/dma/dw-edma/dw-edma-core.c | 2 +-
drivers/dma/dw-edma/dw-edma-core.h
Linus Torvalds writes:
> On Sun, Jan 31, 2021 at 3:35 PM Linus Torvalds
> wrote:
>>
>> I wonder if the simple solution is to just
>>
>> (a) always set one of the SYSCALL_WORK_EXIT bits on the child in
>> ptrace (exactly to catch the child on system call exit)
>>
>> (b) basically revert
Collect the time when each allocation is freed, to help with memory
analysis with kdump/ramdump. Add the timestamp also in the page_owner
debugfs file and print it in dump_page().
Having another timestamp when we free the page helps for debugging
page migration issues. For example both alloc and
On Wed, Feb 03, 2021 at 04:13:21PM +, Joao Martins wrote:
> If check_and_migrate_movable_pages() is meant to migrate unpinned
> pages, then rather than pinning+unpinning+moving, perhaps it would
> be called in __get_user_pages() place where we are walking page
> tables and know if it's a
On Sat, 9 Jan 2021 at 11:33, Lecopzer Chen wrote:
>
> Linux supports KAsan for VMALLOC since commit 3c5c3cfb9ef4da9
> ("kasan: support backing vmalloc space with real shadow memory")
>
> Acroding to how x86 ported it [1], they early allocated p4d and pgd,
> but in arm64 I just simulate how KAsan
Hi!
On Wed 2021-02-03 19:22:34, Dmitry Vyukov wrote:
> On Wed, Feb 3, 2021 at 6:39 PM bobwxc wrote:
> >
> > On Wed, Feb 03, 2021 at 05:05:43PM +0100, Pavel Machek wrote:
> > > On Mon 2021-02-01 11:52:12, Dmitry Vyukov wrote:
> > > Could we please get common prefix (like syzbot: KASAN:) so
On Sun, Jan 31, 2021 at 09:24:41AM -0800, Andy Lutomirski wrote:
> A SMAP-violating kernel access is not a recoverable condition. Imagine
> kernel code that, outside of a uaccess region, dereferences a pointer to
> the user range by accident. If SMAP is on, this will reliably generate
> as an
On Wed, Feb 03, 2021 at 12:58:41PM -0600, Timur Tabi wrote:
> On 2/3/21 7:31 AM, Petr Mladek wrote:
> > Also please make sure that lib/test_printf.c will work with
> > the new option.
>
> As you suspected, it doesn't work:
>
> [ 206.966478] test_printf: loaded.
> [ 206.966528] test_printf:
On Wed, Feb 03, 2021 at 11:48:40AM -0700, Nathan Chancellor wrote:
> On Tue, Jan 12, 2021 at 12:16:34PM -0700, Nathan Chancellor wrote:
> > On Wed, Dec 30, 2020 at 04:40:40PM +0100, Arnd Bergmann wrote:
> > > From: Arnd Bergmann
> > >
> > > clang cannt evaluate this function argument at compile
Em Tue, Feb 02, 2021 at 12:09:06PM -0800, kan.li...@linux.intel.com escreveu:
> From: Kan Liang
> diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
> index c26ea822..c48f6de 100644
> --- a/tools/perf/util/evsel.c
> +++ b/tools/perf/util/evsel.c
> @@ -2689,6 +2689,9 @@ int
On Wed, Feb 03, 2021 at 12:14:24PM -0800, Andy Lutomirski wrote:
> Hmm. I'm not convinced this is really much better. Maybe it is. Let
> me think about it. I feel like it's somehow too close to the previous
> tangle where too many functions did too many different things.
I know what you mean.
On Wed, 3 Feb 2021 12:02:05 -0800
Kees Cook wrote:
> On Wed, Feb 03, 2021 at 12:58:41PM -0600, Timur Tabi wrote:
> > On 2/3/21 7:31 AM, Petr Mladek wrote:
> > > Also please make sure that lib/test_printf.c will work with
> > > the new option.
> >
> > As you suspected, it doesn't work:
> >
On Wed, Feb 3, 2021 at 3:14 PM wrote:
>
> We can test on x86 PC. We will just need about a week after you release your
> next version.
>
That's great. If you have any suggestions on how I can improve testing
on my end, feel free to reach out.
On Wed, Feb 3, 2021 at 1:08 PM Peter Xu wrote:
>
> This is the last missing piece of the COW-during-fork effort when there're
> pinned pages found. One can reference 70e806e4e645 ("mm: Do early cow for
> pinned pages during fork() for ptes", 2020-09-27) for more information, since
> we do
Em Sun, Jan 31, 2021 at 12:48:40AM +0100, Jiri Olsa escreveu:
> Adding support to put daemon process in the background.
>
> It's now enabled by default and -f option is added to
> keep daemon process on the console for debugging.
>
> Signed-off-by: Jiri Olsa
> ---
> tools/perf/builtin-daemon.c
Changelog
v5 --> v6:
* Rebased on top of
https://lore.kernel.org/linux-mm/1611216029-34397-1-git-send-email-abaci-bug...@linux.alibaba.com/
per Kirill.
* Don't register shrinker idr with NULL and remove idr_replace() per
Vlastimil.
* Move nr_deferred before map to guarantee
The tracepoint's nid should show what node the shrink happens on, the start
tracepoint
uses nid from shrinkctl, but the nid might be set to 0 before end tracepoint if
the
shrinker is not NUMA aware, so the traceing log may show the shrink happens on
one
node but end up on the other node. It
The following patch is going to add nr_deferred into shrinker_map, the change
will
make shrinker_map not only include map anymore, so rename it to
"memcg_shrinker_info".
And this should make the patch adding nr_deferred cleaner and readable and make
review easier. Also remove the "memcg_"
Both memcg_shrinker_map_size and shrinker_nr_max is maintained, but actually the
map size can be calculated via shrinker_nr_max, so it seems unnecessary to keep
both.
Remove memcg_shrinker_map_size since shrinker_nr_max is also used by iterating
the
bit map.
Signed-off-by: Yang Shi
---
Currently registered shrinker is indicated by non-NULL shrinker->nr_deferred.
This approach is fine with nr_deferred at the shrinker level, but the following
patches will move MEMCG_AWARE shrinkers' nr_deferred to memcg level, so their
shrinker->nr_deferred would always be NULL. This would
The shrinker map management is not purely memcg specific, it is at the
intersection
between memory cgroup and shrinkers. It's allocation and assignment of a
structure,
and the only memcg bit is the map is being stored in a memcg structure. So
move the
shrinker_maps handling code into vmscan.c
Now nr_deferred is available on per memcg level for memcg aware shrinkers, so
don't need
allocate shrinker->nr_deferred for such shrinkers anymore.
The prealloc_memcg_shrinker() would return -ENOSYS if !CONFIG_MEMCG or memcg is
disabled
by kernel command line, then shrinker's
Use per memcg's nr_deferred for memcg aware shrinkers. The shrinker's
nr_deferred
will be used in the following cases:
1. Non memcg aware shrinkers
2. !CONFIG_MEMCG
3. memcg is disabled by boot parameter
Signed-off-by: Yang Shi
---
mm/vmscan.c | 94
The number of deferred objects might get windup to an absurd number, and it
results in clamp of slab objects. It is undesirable for sustaining workingset.
So shrink deferred objects proportional to priority and cap nr_deferred to twice
of cache items.
The idea is borrowed fron Dave Chinner's
On Wed, 3 Feb 2021 17:35:55 +0100
Pavel Machek wrote:
> On Wed 2021-02-03 15:39:59, Sven Schuchmann wrote:
> > Hello Pavel,
> >
> > > > In order to use a multicolor-led together with a trigger
> > > > from DT the led needs to have an intensity set to see something.
> > > > The trigger changes
Currently the number of deferred objects are per shrinker, but some slabs, for
example,
vfs inode/dentry cache are per memcg, this would result in poor isolation among
memcgs.
The deferred objects typically are generated by __GFP_NOFS allocations, one
memcg with
excessive __GFP_NOFS
Hi!
> > > If I would not have the default-intensity I would actually see nothing,
> > > since the intensity (which goes from 0-255) of each led is initialized
> > > with 0.
> > >
> > > I hope I could clarify this a little more?
> >
> > Yes, sounds reasonable. Could we get default intensity
Now shrinker's nr_deferred is per memcg for memcg aware shrinkers, add to
parent's
corresponding nr_deferred when memcg offline.
Acked-by: Vlastimil Babka
Signed-off-by: Yang Shi
---
include/linux/memcontrol.h | 1 +
mm/memcontrol.c| 1 +
mm/vmscan.c| 24
On 2/3/21 4:50 AM, Yang Li wrote:
Eliminate the following coccicheck warning:
./drivers/pwm/pwm-lpc18xx-sct.c:292:2-3: Unneeded semicolon
Reported-by: Abaci Robot
Signed-off-by: Yang Li
---
Acked-by: Vladimir Zapolskiy
--
Best wishes,
Vladimir
On 2/3/21 7:15 AM, Bhaskar Chowdhury wrote:
>
> s/initialsation/initialisation/
> s/specifiing/specifying/
>
> Signed-off-by: Bhaskar Chowdhury
Hi,
$Subject has a typo/spello.
The 2 fixes below look good (as explained in the patch description),
but:
can you explain the 3 changes below that
On Wed, Feb 03, 2021, Paolo Bonzini wrote:
> Looks good! I'll wait for a few days of reviews,
I guess I know what I'm doing this afternoon :-)
> but I'd like to queue this for 5.12 and I plan to make it the default in 5.13
> or 5.12-rc (depending on when I can ask Red Hat QE to give it a
Sequence Number api provides interfaces for unsigned atomic up counters
leveraging atomic_t and atomic64_t ops underneath.
Convert seqno atomic counter to use seqnum_ops.
Signed-off-by: Shuah Khan
---
drivers/acpi/apei/ghes.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff
Sequence Number api provides interfaces for unsigned atomic up counters.
There are a number of atomic_t usages in the kernel where atomic_t api
is used for counting sequence numbers and other statistical counters.
Several of these usages, convert atomic_read() and atomic_inc_return()
return
Sequence Number api provides interfaces for unsigned atomic up counters
leveraging atomic_t and atomic64_t ops underneath.
Convert seqno atomic counter to use seqnum_ops.
Signed-off-by: Shuah Khan
---
drivers/acpi/acpi_extlog.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
On Wed, Feb 3, 2021 at 10:10 AM Linus Torvalds
wrote:
>
> On Wed, Feb 3, 2021 at 10:00 AM Gabriel Krisman Bertazi
> wrote:
> >
> > Does the patch below follows your suggestion? I'm setting the
> > SYSCALL_WORK shadowing TIF_SINGLESTEP every time, instead of only when
> > the child is inside a
On Wednesday, February 3, 2021 2:31:08 AM CET Hanjun Guo wrote:
> Hi Rafael,
>
> On 2021/2/3 2:14, Rafael J. Wysocki wrote:
> > From: Rafael J. Wysocki
> >
> > Replace the ACPI_DEBUG_PRINT() and ACPI_EXCEPTION() instances
> > in ac.c with acpi_handle_debug() and acpi_handle_info() calls,
> >
Hey Will,
On Tuesday 02 Feb 2021 at 18:13:08 (+), Will Deacon wrote:
> Hi Quentin,
>
> Sorry for the delay, this one took me a while to grok.
No need to be sorry, thanks for having a look!
> On Fri, Jan 08, 2021 at 12:15:10PM +, Quentin Perret wrote:
> > When memory protection is
On Wed 03 Feb 12:05 CST 2021, Jakub Kicinski wrote:
> On Wed, 03 Feb 2021 09:45:06 +0530 Manivannan Sadhasivam wrote:
> > >> Jakub, Dave, Adding you both to get your reviews on this series. I've
> > >> provided an explanation above and in the previous iteration [1].
> > >
> > >Let's be clear
On 03/02/21 19:31, Ben Gardon wrote:
On Wed, Feb 3, 2021 at 3:26 AM Paolo Bonzini wrote:
On 02/02/21 19:57, Ben Gardon wrote:
+#ifdef CONFIG_LOCKDEP
+ if (shared)
+ lockdep_assert_held_read(>mmu_lock);
+ else
+ lockdep_assert_held_write(>mmu_lock);
+#endif /*
Thank you Bryan. I will prepare a v2 early next week.
Would Microchip be able to donate some time to test v2? My own tests
are certainly not perfect. Various stress tests across architectures
(intel/arm) would help create confidence in the multi-buffer frame
implementation. Perhaps Microchip has
On Wed, Feb 3, 2021 at 8:29 PM Konrad Rzeszutek Wilk wrote:
>
> Hey Dmitry, Rafael, George, please see below..
>
> On Wed, Jan 27, 2021 at 10:10:07PM +0100, Dmitry Vyukov wrote:
> > On Wed, Jan 27, 2021 at 9:01 PM George Kennedy
> > wrote:
> > >
> > > Hi Dmitry,
> > >
> > > On 1/27/2021 1:48 PM,
On 03.02.2021 15:21, Vitaly Kuznetsov wrote:
"Maciej S. Szmigiero" writes:
On 03.02.2021 00:43, Sean Christopherson wrote:
On Tue, Feb 02, 2021, Maciej S. Szmigiero wrote:
On 02.02.2021 02:33, Sean Christopherson wrote:
...
I guess you mean to still turn id_to_index into a hash table,
On Tue, Feb 02, 2021 at 02:38:23PM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.255 release.
> There are 32 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
On Tue, Feb 02, 2021 at 02:38:41PM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.14.219 release.
> There are 30 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
On Tue, Feb 02, 2021 at 02:38:43PM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.19.173 release.
> There are 37 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
Hi Rob, Heiko,
Version 2 without node wrapper.
Is that OK for backwards compatibility?
New SoC rk3568 and rk3566 in the manufacturer tree also seem to use dwc3
usb, so now only a rk3399 node restyle in mainline with conversion to yaml.
On 2/3/21 5:52 PM, Johan Jonker wrote:
> In the past
On Tue, Feb 02, 2021 at 02:36:03PM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.10.13 release.
> There are 142 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
On Tue, Feb 02, 2021 at 02:37:38PM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.4.95 release.
> There are 61 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
Hi!
> From: Johannes Berg
>
> [ Upstream commit 6701317476bbfb1f341aa935ddf75eb73af784f9 ]
>
> There's no reason to use ktime_get() since we don't need any better
> precision than jiffies, and since we no longer disable interrupts
> around this code (when grabbing NIC access), jiffies will
Em Sun, Jan 31, 2021 at 12:48:50AM +0100, Jiri Olsa escreveu:
> Adding man page for perf-daemon usage.
I see you decided to add it at the end, but for consistency, please
consider adding the bare minimum when adding
tools/perf/builtin-daemon.c, then go on adding the options and examples
as the
On Wed, 3 Feb 2021 18:09:27 +0100
Peter Zijlstra wrote:
> On Wed, Feb 03, 2021 at 11:05:31AM -0500, Steven Rostedt wrote:
> > + if (new) {
> > + for (i = 0; old[i].func; i++)
> > + if ((old[i].func != tp_func->func
> > +
On 2021-02-02 15:46, John Garry wrote:
On 02/02/2021 14:48, Marc Zyngier wrote:
Not sure. I also now notice an error for the SAS PCI driver on D06
when nr_cpus < 16, which means number of MSI vectors allocated < 32,
so looks the same problem. There we try to allocate 16 + max(nr
cpus, 16)
On Wed, Feb 03, 2021 at 10:09:01PM +0530, Sameer Pujar wrote:
> On 2/3/2021 9:49 PM, Mark Brown wrote:
> > On Wed, Feb 03, 2021 at 09:39:34PM +0530, Sameer Pujar wrote:
> > > +int graph_remove(struct platform_device *pdev);
> > I think this needs better namespacing if it's going to be exported.
Hi!
> > Yes, sounds reasonable. Could we get default intensity of 100% on all
> > channels if nothing else is specified?
> >
> > Or maybe simply "if intensity is not specified, start with 100%, and
> > use explicit =0 if other color is expected".
> >
> Mh, if someone is already using the led
On 21-02-03 17:15:34, Christoph Hellwig wrote:
> On Tue, Feb 02, 2021 at 10:24:18AM -0800, Ben Widawsky wrote:
> > > > + /* Cap 4000h - CXL_CAP_CAP_ID_MEMDEV */
> > > > + struct {
> > > > + void __iomem *regs;
> > > > + } mem;
> > >
> > > This style looks massively
On Wed, Jan 27, 2021 at 02:25:31PM +0530, Anshuman Khandual wrote:
> From: Suzuki K Poulose
>
> The context associated with an ETM for a given perf event
> includes :
> - handle -> the perf output handle for the AUX buffer.
> - the path for the trace components
> - the buffer config for
On Tue, Feb 2, 2021 at 9:15 AM Lee Jones wrote:
>
> On Mon, 01 Feb 2021, Rafael J. Wysocki wrote:
>
> > On Mon, Feb 1, 2021 at 7:45 PM Andy Shevchenko
> > wrote:
> > >
> > > On Tue, Jan 26, 2021 at 12:39:59PM +0200, Andy Shevchenko wrote:
> > > > On Tue, Jan 26, 2021 at 08:21:01AM +, Lee
On 2021-02-03 6:08 PM, Andy Shevchenko wrote:
On Wed, Feb 3, 2021 at 7:06 PM Andy Shevchenko
wrote:
On Wed, Feb 3, 2021 at 5:53 PM Cezary Rojewski
wrote:
This reverts commit 842067940a3e3fc008a60fee388e000219b32632.
For some solutions e.g. sound/soc/intel/catpt, DW DMA is part of a
On 2021-02-03 6:06 PM, Andy Shevchenko wrote:
On Wed, Feb 3, 2021 at 5:53 PM Cezary Rojewski
wrote:
This reverts commit 842067940a3e3fc008a60fee388e000219b32632.
For some solutions e.g. sound/soc/intel/catpt, DW DMA is part of a
compound device (in that very example, domains: ADSP, SSP0,
This reverts commit 842067940a3e3fc008a60fee388e000219b32632.
For some solutions e.g. sound/soc/intel/catpt, DW DMA is part of a
compound device (in that very example, domains: ADSP, SSP0, SSP1, DMA0
and DMA1 are part of a single entity) rather than being a standalone
one. Driver for said device
On Wed, Feb 03, 2021 at 04:08:08PM +0530, Prathu Baronia wrote:
>Hey Ira,
>I looked at your below-mentioned patch and I agree that the
>above-mentioned functions also need modification similar to
>clear_user_highpage().
>Would it be okay with you if I send your patch again with
On 2/3/21 7:51 AM, Naresh Kamboju wrote:
> Linux next tag 20210203 the mips and sh builds failed due to below errors.
> Following builds failed with gcc-8, gcc-9 and gcc-10,
> - mips (cavium_octeon_defconfig)
> - sh (defconfig)
> - sh (shx3_defconfig)
>
> make --silent
On Fri, Jan 29, 2021 at 06:27:27PM +0100, Vincent Guittot wrote:
[...]
> > update_blocked_averages with preempt and irq off is not a good thing
> > because we don't manage the number of csf_rq to update and I'm going
> > to provide a patchset for this
>
> The patch below moves the update of the
submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Thara-Gopinath/Regression-fixes-clean-ups-in-the-Qualcomm-crypto-engine-driver/20210203-224305
base:
https://git.kernel.org/pub/scm/linux/kernel/git
Em Sun, Jan 31, 2021 at 12:48:34AM +0100, Jiri Olsa escreveu:
> Adding config option and base functionality that takes the option
> argument (if specified) and other system config locations and
> produces 'acting' config file path.
>
> The actual config file processing is coming in following
Em Sun, Jan 31, 2021 at 12:48:35AM +0100, Jiri Olsa escreveu:
> Adding base option allowing user to specify base directory.
> It will have precedence over config file base definition
> coming in following patches.
>
> Signed-off-by: Jiri Olsa
> ---
> tools/perf/builtin-daemon.c | 11 +++
From: Thomas Gleixner
For the upcoming device MSI support a new allocation type is
required.
Signed-off-by: Thomas Gleixner
Signed-off-by: Megha Dey
---
arch/x86/include/asm/hw_irq.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/x86/include/asm/hw_irq.h
From: Thomas Gleixner
For the upcoming device MSI support it's required to have a default
irq_chip::ack implementation (irq_chip_ack_parent) so the drivers do not
need to care.
Signed-off-by: Thomas Gleixner
Signed-off-by: Megha Dey
---
drivers/base/platform-msi.c | 2 ++
1 file changed, 2
Provide support for device specific MSI implementations for devices which
have their own resource management and interrupt chip. These devices are
not related to PCI and contrary to platform MSI they do not share a
common resource and interrupt chip. They provide their own domain specific
resource
From: Thomas Gleixner
Rename it to x86_msi_prepare() and handle the allocation type setup
depending on the device type.
Add a new arch_msi_prepare define which will be utilized by the upcoming
device MSI support. Define it to NULL if not provided by an architecture
in the generic MSI header.
On Tue, Feb 02, 2021 at 10:24:18AM -0800, Ben Widawsky wrote:
> > > + /* Cap 4000h - CXL_CAP_CAP_ID_MEMDEV */
> > > + struct {
> > > + void __iomem *regs;
> > > + } mem;
> >
> > This style looks massively obsfucated. For one the comments look like
> > absolute gibberish, but also what is
On 2/3/21 12:12 PM, Mark Rutland wrote:
On Wed, Feb 03, 2021 at 09:26:45AM +0100, Julien Thierry wrote:
On 2/2/21 11:17 AM, Mark Rutland wrote:
On Wed, Jan 20, 2021 at 06:17:41PM +0100, Julien Thierry wrote:
Aarch64 instruction set encoding and decoding logic can prove useful
for some
On 2/3/21 7:01 AM, Bhaskar Chowdhury wrote:
>
> s/messge/message/ ..two different lines
>
> Signed-off-by: Bhaskar Chowdhury
Acked-by: Randy Dunlap
Thanks.
> ---
> drivers/crypto/qat/qat_common/adf_vf2pf_msg.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git
On 2/3/21 1:07 AM, Chunyan Zhang wrote:
> diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
> index 192ef8f61310..99e7712f3903 100644
> --- a/drivers/iommu/Kconfig
> +++ b/drivers/iommu/Kconfig
> @@ -408,4 +408,16 @@ config VIRTIO_IOMMU
>
> Say Y here if you intend to run this
On Wed, Feb 3, 2021 at 4:40 AM Paolo Bonzini wrote:
>
> On 02/02/21 19:57, Ben Gardon wrote:
> >
> > - write_lock(>kvm->mmu_lock);
> > +
> > + if (is_tdp_mmu_root(vcpu->kvm, vcpu->arch.mmu->root_hpa))
> > + read_lock(>kvm->mmu_lock);
> > + else
> > +
On 1/22/21 2:31 PM, Thiago Jung Bauermann wrote:
Lakshmi Ramasubramanian writes:
IMA allocates kernel virtual memory to carry forward the measurement
list, from the current kernel to the next kernel on kexec system call,
in ima_add_kexec_buffer() function. This buffer is not freed before
On Wed, Feb 3, 2021 at 10:00 AM Gabriel Krisman Bertazi
wrote:
>
> Does the patch below follows your suggestion? I'm setting the
> SYSCALL_WORK shadowing TIF_SINGLESTEP every time, instead of only when
> the child is inside a system call. Is this acceptable?
Looks sane to me.
My main worry
On Wed, Feb 3, 2021 at 10:00 AM Gabriel Krisman Bertazi
wrote:
>
> Linus Torvalds writes:
>
> > On Sun, Jan 31, 2021 at 3:35 PM Linus Torvalds
> > wrote:
> >>
> >> I wonder if the simple solution is to just
> >>
> >> (a) always set one of the SYSCALL_WORK_EXIT bits on the child in
> >> ptrace
On Thu 28-01-21 22:39:46, Randy Dunlap wrote:
> On 1/28/21 9:00 PM, bingjingc wrote:
> > From: BingJing Chang
> >
> > Fix existing issues at the kernel-doc markups
> >
> > Signed-off-by: BingJing Chang
> > ---
> > lib/parser.c | 22 +++---
> > 1 file changed, 11 insertions(+),
Sequence Number api provides interfaces for unsigned atomic up counters.
There are a number of atomic_t usages in the kernel where atomic_t api
is used for counting sequence numbers and other statistical counters.
Several of these usages, convert atomic_read() and atomic_inc_return()
return
101 - 200 of 1611 matches
Mail list logo
