Hi Bjorn,
> -Original Message-
> From: Bjorn Helgaas
> Sent: Thursday, September 24, 2020 2:08 AM
> To: Athani Nadeem Ladkhan
> Cc: Tom Joseph ; lorenzo.pieral...@arm.com;
> r...@kernel.org; bhelg...@google.com; linux-...@vger.kernel.org; linux-
> ker...@vger.kernel.org; kis...@ti.com; M
On Wed 30-09-20 13:36:37, Matthew Wilcox wrote:
> On Wed, Sep 30, 2020 at 02:15:12PM +0200, Jan Kara wrote:
> > On Mon 14-09-20 14:00:42, Matthew Wilcox (Oracle) wrote:
> > > All callers now expect head (and base) pages, and can handle multiple
> > > head pages in a single batch, so make find_get_e
Hi!
> In the error path of the for_each_available_child_of_node loop in
> aw2013_probe_dt, add missing call to of_node_put to avoid leaking the
> iterator.
>
> Fixes: 59ea3c9faf32 ("leds: add aw2013 driver")
> Signed-off-by: Tobias Jordan
This failed to apply to my -for-next tree.
Best regards
Hi Mark,
On Wed, Sep 30, 2020 at 2:59 AM Mark Rutland wrote:
>
> Hi Sami,
>
> On Tue, Sep 29, 2020 at 02:46:11PM -0700, Sami Tolvanen wrote:
> > Select FTRACE_MCOUNT_USE_PATCHABLE_FUNCTION_ENTRY to disable
> > recordmcount when DYNAMIC_FTRACE_WITH_REGS is selected.
>
> Could you please add an exp
Hi Kishon,
> -Original Message-
> From: Kishon Vijay Abraham I
> Sent: Thursday, September 24, 2020 9:45 AM
> To: Athani Nadeem Ladkhan ; Tom Joseph
> ; lorenzo.pieral...@arm.com; r...@kernel.org;
> bhelg...@google.com; linux-...@vger.kernel.org; linux-
> ker...@vger.kernel.org
> Cc: Mili
Hi!
> > In one of the error paths of the for_each_child_of_node loop in
> > tlc591xx_probe, add missing call to of_node_put.
> >
> > Fixes: 1ab4531ad132 ("leds: tlc591xx: simplify driver by using the
> > managed led API")
> >
> > Signed-off-by: Tobias Jordan
>
> Reviewed-by: Marek Behún
Than
On Wed, Sep 30, 2020 at 02:18:59PM +0100, Will Deacon wrote:
> diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
> index f07333e86c2f..a696a7921da4 100644
> --- a/arch/arm64/mm/fault.c
> +++ b/arch/arm64/mm/fault.c
> @@ -218,7 +218,9 @@ int ptep_set_access_flags(struct vm_area_struct *vma,
On Wed, Sep 30, 2020 at 11:10:36AM -0500, Segher Boessenkool wrote:
> Since this variable is a local register asm, on entry to the asm the
> compiler guarantees that the value lives in the assigned register (the
> "r8" hardware register in this case). This all works completely fine.
> This is the
hi,
currently we support only one storage size (20 bytes) for build
ids. That fits for SHA1 build ids, but there can in theory be
any size. The gcc linker supports also MD5, which is 16 bytes.
Currently the MD5 build id will be stored in .debug cache with
additional zeros, like:
$ find ~/.debug
Passing build_id object to filename__read_build_id function,
so it can populate the size of the build_id object.
Changing filename__read_build_id code for both elf/non-elf
code.
Signed-off-by: Jiri Olsa
---
tools/perf/builtin-buildid-cache.c | 25 +++---
tools/perf/builtin-injec
Replace build_id byte array with struct build_id
object and all the code that references it.
The objective is to carry size together with build
id array, so it's better to keep both together.
This is preparatory change for following patches,
and there's no functional change.
Signed-off-by: Jiri
On Wed, Sep 30, 2020 at 08:22:23AM +0300, Alexandru Ardelean wrote:
> On Tue, Sep 29, 2020 at 6:30 PM Moritz Fischer wrote:
> >
> > Hi Alexandru,
> >
> > On Tue, Sep 29, 2020 at 05:44:15PM +0300, Alexandru Ardelean wrote:
> > > From: Mathias Tausen
> > >
> > > Since axi-clkgen is now supported on
Passing build id object to sysfs__read_build_id function,
so it can populate the size of the build_id object.
Signed-off-by: Jiri Olsa
---
tools/perf/util/build-id.c | 6 +++---
tools/perf/util/dso.c| 6 ++
tools/perf/util/symbol-elf.c | 11 +--
tools/perf/uti
We do not store size with build ids in perf data,
but there's enough space to do it. Adding misc bit
PERF_RECORD_MISC_BUILD_ID_SIZE to mark build id event
with size.
With this fix the dso with md5 build id will have correct
build id data and will be usable for debuginfod processing
if needed (comi
Adding test for build id cache that adds binary
with sha1 and md5 build ids and verifies it's
added properly.
The test updates build id cache with perf record
and perf buildid-cache -a.
Signed-off-by: Jiri Olsa
---
tools/perf/Makefile.perf | 14 +
tools/perf/tests/shell/buildid.sh
Add and export the function drm_gem_cma_create_noalloc(), which is just
__drm_gem_cma_create() renamed.
This function can be used by drivers that need to create a GEM object
without allocating the backing memory.
Signed-off-by: Paul Cercueil
---
drivers/gpu/drm/drm_gem_cma_helper.c | 11 ++-
Passing build_id object to dso__build_id_equal, so we can
properly check build id with different size than sha1.
Signed-off-by: Jiri Olsa
---
tools/perf/util/dso.c| 5 +++--
tools/perf/util/dso.h| 2 +-
tools/perf/util/symbol-elf.c | 8 ++--
tools/perf/util/symbol.c | 2 +
The DMA API changed at the same time commit 37054fc81443 ("gpu/drm:
ingenic: Add option to mmap GEM buffers cached") was added. Rework the
code to work with the new DMA API.
Signed-off-by: Paul Cercueil
---
drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 24 +++
1 file changed, 7
Passing build_id object to build_id__sprintf function,
so it can operate with the proper size of build id.
This will create proper md5 build id readable names,
like following:
a50e350e97c43b4708d09bcd85ebfff7
instead of:
a50e350e97c43b4708d09bcd85ebfff7
Signed-off-by: Jiri Olsa
---
It turns out that if you want to mmap GEM buffers fully cached, then
they should be allocated as such as well. Who would have known?
Introduce a custom .dumb_create callback, that will behave just like
drm_gem_cma_dumb_create(), except that it will allocate the GEM buffer
using dma_alloc_noncohere
On Wed, Sep 30, 2020 at 7:48 AM Dave Hansen wrote:
>
> On 9/30/20 7:42 AM, Liang, Kan wrote:
> >> When I tested on my kernel, it panicked because I suspect
> >> current->active_mm could be NULL. Adding a check for NULL avoided the
> >> problem. But I suspect this is not the correct solution.
> >
>
With shorter md5 build ids we need to align their
paths properly with other build ids:
$ perf buildid-list
17f4e448cc746582ea1881528deb549f7fdb3fd5 [kernel.kallsyms]
a50e350e97c43b4708d09bcd85ebfff7 .../tools/perf/buildid-ex-md5
1805c738c8f3ec0f47b7ea09080c28f34d18a82b /usr/lib64/l
On Wed 30-09-20 13:03:29, Joel Fernandes wrote:
> On Wed, Sep 30, 2020 at 12:48 PM Michal Hocko wrote:
> >
> > On Wed 30-09-20 11:25:17, Joel Fernandes wrote:
> > > On Fri, Sep 25, 2020 at 05:47:41PM +0200, Michal Hocko wrote:
> > > > On Fri 25-09-20 17:31:29, Uladzislau Rezki wrote:
> > > > > > >
Passing build_id object to dso__set_build_id, so it's easier
to initialize dos's build id object.
Signed-off-by: Jiri Olsa
---
tools/perf/util/dso.c| 4 ++--
tools/perf/util/dso.h| 2 +-
tools/perf/util/header.c | 4 +++-
tools/perf/util/symbol-minimal.c | 2 +-
t
On Wed, Sep 30, 2020 at 12:31 AM Dave Chinner wrote:
>
> On Sat, Sep 26, 2020 at 01:31:36PM -0700, Yang Shi wrote:
> > Hi Dave,
> >
> > I was exploring to make the "nr_deferred" per memcg. I looked into and
> > had some prototypes for two approaches so far:
> > 1. Have per memcg data structure for
On Wed, Sep 30, 2020 at 07:08:07PM +0200, Jan Kara wrote:
> On Wed 30-09-20 13:36:37, Matthew Wilcox wrote:
> > On Wed, Sep 30, 2020 at 02:15:12PM +0200, Jan Kara wrote:
> > > On Mon 14-09-20 14:00:42, Matthew Wilcox (Oracle) wrote:
> > > > All callers now expect head (and base) pages, and can hand
Good day,
My name are Mrs. Susan Carter an America but a United Kingdom Citizen, I???m 57
years old, widow, married to late Eng Martins Carter who is a British, who
until his death worked with Dutch Filtration for Twenty-Six years before he
died in the year 2015 after a brief illness that laste
Hi Niklas,
[+ Samuel]
On 2020-09-30 17:27, Niklas Söderlund wrote:
Hi Marc,
I'm afraid this commit breaks booting my rk3399 device.
I bisected the problem to this patch merged as [1]. I'm testing on a
Scarlet device and I'm using the unmodified upstream
rk3399-gru-scarlet-inx.dtb for my tests
On 30/09/20 7:08 pm, Coly Li wrote:
> In mmc_queue_setup_discard() the mmc driver queue's discard_granularity
> might be set as 0 (when card->pref_erase > max_discard) while the mmc
> device still declares to support discard operation. This is buggy and
> triggered the following kernel warning mess
Hi,
On Wed, Sep 30, 2020 at 8:48 AM Rajendra Nayak wrote:
>
>
> On 9/30/2020 7:34 PM, Lukasz Luba wrote:
> >
> >
> > On 9/30/20 11:55 AM, Rajendra Nayak wrote:
> >>
> >> On 9/30/2020 1:55 PM, Lukasz Luba wrote:
> >>> Hi Douglas,
> >>>
> >>> On 9/30/20 12:53 AM, Doug Anderson wrote:
> Hi,
> >
Hi!
> > > +__attribute__((nonnull))
> > >
> > > static int led_pwm_add(struct device *dev, struct led_pwm_priv *priv,
> > >
> > > struct led_pwm *led, struct fwnode_handle *fwnode)
> > >
> > > {
> >
> > This normally goes elsewhere -- right? I'd expect:
> >
> >
> > sta
Hi Thomas/Jason,
On 9/30/2020 8:20 AM, Thomas Gleixner wrote:
On Wed, Sep 30 2020 at 08:43, Jason Gunthorpe wrote:
On Wed, Sep 30, 2020 at 08:41:48AM +0200, Thomas Gleixner wrote:
On Tue, Sep 29 2020 at 16:03, Megha Dey wrote:
On 8/26/2020 4:16 AM, Thomas Gleixner wrote:
#9 is obviously
Does anyone know who's behind postmas...@vger.kernel.org? Maybe I can
email them directly if perhaps they don't check this email often?
(Benefit of the doubt)
On Tue, Sep 15, 2020 at 1:49 PM Nick Desaulniers
wrote:
>
> Hello postmaster,
> Any thoughts on linux-toolcha...@vger.kernel.org?
>
> On
On Wed, Sep 30, 2020 at 9:23 AM David Hildenbrand wrote:
>
> On 25.09.20 21:12, Dan Williams wrote:
> > Towards removing the mode specific @dax_kmem_res attribute from the
> > generic 'struct dev_dax', and preparing for multi-range support, change
> > the kmem driver to use the idiomatic release_m
On Sat, Sep 19, 2020 at 11:41:19PM +0200, Michał Mirosław wrote:
> This series cleans up the driver a bit and implements changes needed to
> support EKTF3624-based touchscreen used in Asus TF300T, Google Nexus 7
> and similar Tegra3-based tablets.
[...]
Ping? Should I resend? This got only cosmeti
On Wed, Sep 30, 2020 at 07:48:48AM -0700, Dave Hansen wrote:
> On 9/30/20 7:42 AM, Liang, Kan wrote:
> >> When I tested on my kernel, it panicked because I suspect
> >> current->active_mm could be NULL. Adding a check for NULL avoided the
> >> problem. But I suspect this is not the correct solution
...
>> I don't think that the MC driver will stay built-in forever, although
>> its modularization is complicated right now. Hence something shall keep
>> the reference to the MC device resources while they are in use and this
>> patch takes care of doing that.
>
> It looks to me like all the othe
On Tue, Sep 29, 2020 at 08:02:38PM -0700, Sowjanya Komatineni wrote:
> This patch adds COMPILE_TEST option to Kconfig to allow building
> it with COMPILE_TEST option.
Does it build without TEGRA_HOST1X selected? Isn't the previous patch
enough to allow the build with COMPILE_TEST?
Best Regards,
M
Currently, pick_next_entity(...) has the following structure
(simplified):
[...]
if (last_buddy_ok())
result = last_buddy;
if (next_buddy_ok())
result = next_buddy;
[...]
The intended behavior is to prefer next buddy over last buddy;
the current code somewhat obfuscates this, and also wastes
On Wed, Sep 30, 2020 at 10:25:40AM -0700, Nick Desaulniers wrote:
> Does anyone know who's behind postmas...@vger.kernel.org? Maybe I can
> email them directly if perhaps they don't check this email often?
> (Benefit of the doubt)
davem iirc.
On 30/09/20 18:37, Sean Christopherson wrote:
>> +ret = page_fault_handle_target_level(vcpu, write, map_writable,
>> + as_id, &iter, pfn, prefault);
>> +
>> +/* If emulating, flush this vcpu's TLB. */
> Why? It's obvious _what_ the code is doing, the
Hi Marc,
On 2020-09-30 18:23:21 +0100, Marc Zyngier wrote:
> Hi Niklas,
>
> [+ Samuel]
>
> On 2020-09-30 17:27, Niklas Söderlund wrote:
> > Hi Marc,
> >
> > I'm afraid this commit breaks booting my rk3399 device.
> >
> > I bisected the problem to this patch merged as [1]. I'm testing on a
> >
On 30/09/20 18:57, Sean Christopherson wrote:
>> +
>> +static bool __read_mostly tdp_mmu_enabled = true;
>> +module_param_named(tdp_mmu, tdp_mmu_enabled, bool, 0644);
> This param should not exist until the TDP MMU is fully functional, e.g.
> running
> KVM against "kvm: mmu: Support zapping SPTEs
syzbot has found a reproducer for the following issue on:
HEAD commit:2b3e981a Merge branch 'mptcp-Fix-for-32-bit-DATA_FIN'
git tree: net
console output: https://syzkaller.appspot.com/x/log.txt?x=1653724790
kernel config: https://syzkaller.appspot.com/x/.config?x=99a7c78965c75e07
da
On Wed, Sep 30, 2020 at 1:22 PM Michal Hocko wrote:
> > > > I think documenting is useful.
> > > >
> > > > Could it be more explicit in what the issue is? Something like:
> > > >
> > > > * Even with GFP_ATOMIC, calls to the allocator can sleep on PREEMPT_RT
> > > > systems. Therefore, the current
On Fri, Sep 25, 2020 at 02:22:54PM -0700, Ben Gardon wrote:
> @@ -1945,12 +1944,24 @@ static void rmap_recycle(struct kvm_vcpu *vcpu, u64
> *spte, gfn_t gfn)
>
> int kvm_age_hva(struct kvm *kvm, unsigned long start, unsigned long end)
> {
> - return kvm_handle_hva_range(kvm, start, end, 0,
Add a proper helper to remap PFNs into kernel virtual space so that
drivers don't have to abuse alloc_vm_area and open coded PTE
manipulation for it.
Signed-off-by: Christoph Hellwig
---
include/linux/vmalloc.h | 1 +
mm/Kconfig | 3 +++
mm/vmalloc.c| 45 ++
Besides calling the callback on each page, apply_to_page_range also has
the effect of pre-faulting all PTEs for the range. To support callers
that only need the pre-faulting, make the callback optional.
Based on a patch from Minchan Kim .
Signed-off-by: Christoph Hellwig
---
mm/memory.c | 16 +
From: "Matthew Wilcox (Oracle)"
* Document that you can call vfree() on an address returned from vmap()
* Remove the note about the minimum size -- the minimum size of a vmalloc
allocation is one page
* Add a Context: section
* Fix capitalisation
* Reword the prohibition on calling from N
i915_gem_object_map implements fairly low-level vmap functionality in
a driver. Split it into two helpers, one for remapping kernel memory
which can use vmap, and one for I/O memory that uses vmap_pfn.
The only practical difference is that alloc_vm_area prefeaults the
vmalloc area PTEs, which doe
The property #pinctrl-cells can either be 1 or 2:
- if #pinctrl-cells = <1>, then pinctrl_spec.args_count = 2
- if #pinctrl-cells = <2>, then pinctrl_spec.args_count = 3
All other values of pinctrl_spec.args_count are incorrect. This fix
checks the upper bound instead of just the lower bound.
F
Replacing alloc_vm_area with get_vm_area_caller + apply_page_range
allows to fill put the phys_addr values directly instead of doing
another loop over all addresses.
Signed-off-by: Christoph Hellwig
Reviewed-by: Boris Ostrovsky
---
drivers/xen/xenbus/xenbus_client.c | 30 ---
All users are gone now.
Signed-off-by: Christoph Hellwig
---
include/linux/vmalloc.h | 5 +
mm/nommu.c | 7 --
mm/vmalloc.c| 48 -
3 files changed, 1 insertion(+), 59 deletions(-)
diff --git a/include/linux/vmalloc.h b/i
Just manually pre-fault the PTEs using apply_to_page_range.
Co-developed-by: Minchan Kim
Signed-off-by: Christoph Hellwig
---
mm/zsmalloc.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c
index c36fdff9a37131..918c7b019b3d78 100644
--
Hi Andrew,
this series removes alloc_vm_area, which was left over from the big
vmalloc interface rework. It is a rather arkane interface, basicaly
the equivalent of get_vm_area + actually faulting in all PTEs in
the allocated area. It was originally addeds for Xen (which isn't
modular to start w
shmem_pin_map somewhat awkwardly reimplements vmap using
alloc_vm_area and manual pte setup. The only practical difference
is that alloc_vm_area prefeaults the vmalloc area PTEs, which doesn't
seem to be required here (and could be added to vmap using a flag if
actually required). Switch to use v
Replace the last call to alloc_vm_area with an open coded version using
an iterator in struct gnttab_vm_area instead of the triple indirection
magic in alloc_vm_area.
Signed-off-by: Christoph Hellwig
Reviewed-by: Boris Ostrovsky
---
arch/x86/xen/grant-table.c | 27 ---
1
Add a flag so that vmap takes ownership of the passed in page array.
When vfree is called on such an allocation it will put one reference
on each page, and free the page array itself.
Signed-off-by: Christoph Hellwig
---
include/linux/vmalloc.h | 1 +
mm/vmalloc.c| 9 +++--
2 fil
On Wed, Sep 30, 2020 at 08:16:59AM +0300, Tony Lindgren wrote:
> * Linus Walleij [200929 12:51]:
> > On Sun, Sep 13, 2020 at 11:17 PM Drew Fustini wrote:
> >
> > > The property #pinctrl-cells can either be 2 or 3. There is currently
> > > only a check to make sure that #pinctrl-cells is 2 or gr
On 9/30/20 10:34 AM, Michał Mirosław wrote:
On Tue, Sep 29, 2020 at 08:02:38PM -0700, Sowjanya Komatineni wrote:
This patch adds COMPILE_TEST option to Kconfig to allow building
it with COMPILE_TEST option.
Does it build without TEGRA_HOST1X selected? Isn't the previous patch
enough to allow
On Wed, Sep 30 2020 at 19:03, Peter Zijlstra wrote:
> On Wed, Sep 30, 2020 at 05:40:08PM +0200, Thomas Gleixner wrote:
> Also, that preempt_disable() in there doesn't actually do anything.
> Worse, preempt_disable(); for_each_cpu(); is an anti-pattern. It mixes
> static_cpu_has() and boot_cpu_has()
Hi,
> On Wed, Sep 30, 2020 at 7:44 AM Rob Herring wrote:
> >
> > We already have hubs in DT. See [1][2][3][4]. What's new here?
After I sent my response I kept thinking about this and I realized
that I have prior art I can point out too! :-) Check out
"smsc,usb3503a". That is describing a USB
onfig
mips allyesconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
i386 randconfig-a003-20200930
i386 randc
On Fri, Sep 25, 2020 at 02:22:57PM -0700, Ben Gardon wrote:
> +/*
> + * Remove write access from all the SPTEs mapping GFNs in the memslot. If
> + * skip_4k is set, SPTEs that map 4k pages, will not be write-protected.
> + * Returns true if an SPTE has been changed and the TLBs need to be flushed.
On Fri, Sep 25, 2020 at 02:22:59PM -0700, Ben Gardon wrote:
> diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
> index 12892fc4f146d..e6f5093ba8f6f 100644
> --- a/arch/x86/kvm/mmu/mmu.c
> +++ b/arch/x86/kvm/mmu/mmu.c
> @@ -1667,6 +1667,11 @@ bool kvm_mmu_slot_gfn_write_protect(struct kv
On Wed, Sep 30, 2020 at 06:57:56PM +0200, David Sterba wrote:
> On Sun, Sep 20, 2020 at 07:12:14AM -0700, syzbot wrote:
> > Hello,
> >
> > syzbot found the following issue on:
> >
> > HEAD commit:eb5f95f1 Merge tag 's390-5.9-6' of git://git.kernel.org/pu..
> > git tree: upstream
> > con
On Wed, Sep 30, 2020 at 06:34:40PM +0200, Andrew Lunn wrote:
> > @@ -2866,7 +2888,15 @@ EXPORT_SYMBOL_GPL(device_phy_find_device);
> > */
> > struct fwnode_handle *fwnode_get_phy_node(struct fwnode_handle *fwnode)
> > {
> > - return fwnode_find_reference(fwnode, "phy-handle", 0);
> > + stru
On 30/09/20 20:04, Sean Christopherson wrote:
>> +for_each_tdp_mmu_root(kvm, root) {
>> +root_as_id = kvm_mmu_page_as_id(root);
>> +if (root_as_id != slot->as_id)
>> +continue;
> This pattern pops up quite a few times, probably worth adding
>
> #defi
On Fri, Sep 25, 2020 at 08:12:03PM +0200, Corentin Labbe wrote:
> On Tue, Mar 03, 2020 at 04:31:11PM -0500, Daniel Jordan wrote:
> > On Tue, Mar 03, 2020 at 08:48:19AM +0100, Corentin Labbe wrote:
> > > The patch fix the issue. Thanks!
> >
> > Thanks for trying it!
> >
> > > So you could add:
> >
On Wed, Sep 30, 2020 at 10:42 AM syzbot
wrote:
>
> syzbot has found a reproducer for the following issue on:
>
> HEAD commit:2b3e981a Merge branch 'mptcp-Fix-for-32-bit-DATA_FIN'
> git tree: net
> console output: https://syzkaller.appspot.com/x/log.txt?x=1653724790
> kernel config:
Megha,
On Wed, Sep 30 2020 at 10:25, Megha Dey wrote:
> On 9/30/2020 8:20 AM, Thomas Gleixner wrote:
Your IMS patches? Why do you need something special again?
>
> By IMS patches, I meant your IMS driver patch that was updated (as it
> was untested, it had some compile errors and we removed
On Thu, Sep 17, 2020 at 01:16:46PM -0400, Steven Rostedt wrote:
> Hi Peter,
>
> I ran my tests on a series of patches on top of 5.9-rc4, and hit the
> following splat:
>
> [ cut here ]
> WARNING: CPU: 0 PID: 2557 at kernel/rcu/tree.c:1058 rcu_irq_enter+0x15/0x20
> RIP:
Hi Thomas,
For the last couple years we've been using mb2q tool to normalize patches
and it worked wonderfully.
Recently we've hit few bugs:
curl -s https://patchwork.kernel.org/patch/11807443/mbox/ >
/tmp/mbox.i; ~/bin/mb2q --mboxout mbox.o /tmp/mbox.i
Drop Message w/o Message-ID: No subject
No p
Hi Sasha,
On 9/21/20 07:54, Sasha Levin wrote:
>
> NOTE: The patch will not be queued to stable trees until it is upstream.
>
> How should we proceed with this patch?
>
This patch should not go to -stable.
The author has resent it without the _stable_ stag.
Thanks
--
Gustavo
On Wed, Jul 29, 2020 at 09:00:06PM +0530, Sivaprakash Murugesan wrote:
> Add support for PCIe Gen3 port found in ipq8074 devices.
>
> Signed-off-by: Sivaprakash Murugesan
> ---
> drivers/pci/controller/dwc/pcie-qcom.c | 177
> -
> 1 file changed, 176 insertions(+
On Fri, Sep 25, 2020 at 02:23:00PM -0700, Ben Gardon wrote:
> +/*
> + * Clear non-leaf SPTEs and free the page tables they point to, if those
> SPTEs
> + * exist in order to allow execute access on a region that would otherwise be
> + * mapped as a large page.
> + */
> +void kvm_tdp_mmu_recover_nx
On Wed, 02 Sep 2020 16:43:44 +0200, Pali Rohár wrote:
> Old ATF automatically power on pcie phy and does not provide SMC call for
> phy power on functionality which leads to aardvark initialization failure:
>
> [0.330134] mvebu-a3700-comphy d0018300.phy: unsupported SMC call, try
> updating y
On Wed, 02 Sep 2020 16:43:43 +0200, Pali Rohár wrote:
> Driver ->power_on and ->power_off callbacks leaks internal SMCC firmware
> return codes to phy caller. This patch converts SMCC error codes to
> standard linux errno codes. Include file linux/arm-smccc.h already provides
> defines for SMCC err
On Fri, Sep 25, 2020 at 02:23:01PM -0700, Ben Gardon wrote:
> In order to support MMIO, KVM must be able to walk the TDP paging
Probably worth clarifying that this is for emulated MMIO, as opposed to
mapping MMIO host addresses.
> structures to find mappings for a given GFN. Support this walk for
On Wed, Sep 30, 2020 at 07:07:25PM +0100, Russell King - ARM Linux admin wrote:
> On Wed, Sep 30, 2020 at 06:34:40PM +0200, Andrew Lunn wrote:
> > > @@ -2866,7 +2888,15 @@ EXPORT_SYMBOL_GPL(device_phy_find_device);
> > > */
> > > struct fwnode_handle *fwnode_get_phy_node(struct fwnode_handle *fw
On 9/29/20 9:49 AM, Vijay Balakrishna wrote:
> When memory is hotplug added or removed the min_free_kbytes should be
> recalculated based on what is expected by khugepaged. Currently
> after hotplug, min_free_kbytes will be set to a lower default and higher
> default set when THP enabled is lost.
Cadence controller will not initiate autonomous speed change if strapped
as Gen2. The Retrain Link bit is set as quirk to enable this speed change.
Signed-off-by: Nadeem Athani
---
Changes in v3:
- To set retrain link bit,checking device capability & link status.
- 32bit read in place of 8bit.
-
On Sun, 06 Sep 2020 20:51:27 +0100, Alex Dewar wrote:
> Currently the Keystone driver can only be compile-tested on ARM, but
> this restriction seems unnecessary. Get rid of it to increase test
> coverage.
>
> Build-tested with allyesconfig on x86, ppc, mips and riscv.
>
> Signed-off-by: Alex Dew
On Tue, Sep 15 2020 at 16:27, Dave Jiang wrote:
> From: Thomas Gleixner
> +config IMS_MSI_ARRAY
> + bool "IMS Interrupt Message Storm MSI controller for device memory
> storage arrays"
Hehe, you missed a Message Storm :)
> + depends on PCI
> + select IMS_MSI
> + select GENERIC_M
On Wed, Sep 30, 2020 at 03:14:07PM +0200, Gioh Kim wrote:
> From: Gioh Kim
>
> list field is not used anywhere
>
> Signed-off-by: Gioh Kim
> Acked-by: Jack Wang
> ---
> drivers/infiniband/ulp/rtrs/rtrs-pri.h | 1 -
> 1 file changed, 1 deletion(-)
Applied to for-next, thanks
Jason
CalledProcessError stores the output of the failed process as `bytes`,
not a `str`.
So when we log it on build error, the make output is all crammed into
one line with "\n" instead of actually printing new lines.
After this change, we get readable output with new lines, e.g.
> CC lib/kunit
On Tue, Sep 15 2020 at 16:27, Dave Jiang wrote:
> @@ -1303,9 +1303,10 @@ static void intel_irq_remapping_prepare_irte(struct
> intel_ir_data *data,
> case X86_IRQ_ALLOC_TYPE_HPET:
> case X86_IRQ_ALLOC_TYPE_PCI_MSI:
> case X86_IRQ_ALLOC_TYPE_PCI_MSIX:
> + case X86_IRQ_ALLOC_TY
On Wed, 2020-09-30 at 08:40 -0700, Joe Perches wrote:
> On Tue, 2020-09-29 at 13:25 -0700, Nick Desaulniers wrote:
> > And I don't remember what ever happened to Joe's script for treewide
> > conversion of __section.
>
> Nor do I but here (attached) is the script.
>
> My recollection is there was
On Wed, Sep 30, 2020 at 08:00:59PM +0200, Thomas Gleixner wrote:
> On Wed, Sep 30 2020 at 19:03, Peter Zijlstra wrote:
> > On Wed, Sep 30, 2020 at 05:40:08PM +0200, Thomas Gleixner wrote:
> > Also, that preempt_disable() in there doesn't actually do anything.
> > Worse, preempt_disable(); for_each_
On Tue, Sep 15 2020 at 16:28, Dave Jiang wrote:
>
> +#define INT_HANDLE_IMS_TABLE 0x1
> +int idxd_device_request_int_handle(struct idxd_device *idxd, int idx,
> +int *handle, enum idxd_interrupt_type
> irq_type)
New lines exist for a reason and this glued tog
On Wed, Sep 30, 2020 at 4:48 PM Christoph Hellwig wrote:
>
> On Tue, Sep 29, 2020 at 03:43:30PM +0300, Joonas Lahtinen wrote:
> > Hmm, those are both committed after our last -next pull request, so they
> > would normally only target next merge window. drm-next closes the merge
> > window around -
On Tue, Sep 29, 2020 at 10:35 PM Sean Christopherson
wrote:
>
> Nit on all the shortlogs, can you use "KVM: x86/mmu" instead of "kvm: mmu"?
Will do.
>
> On Fri, Sep 25, 2020 at 02:22:43PM -0700, Ben Gardon wrote:
> > diff --git a/arch/x86/kvm/mmu/tdp_mmu.c b/arch/x86/kvm/mmu/tdp_mmu.c
> > new fi
The following series of patches provides implementation of the
kexec_file_load() system call form the arm architecture. zImage and uImage
(legacy format) files are supported. Like on arm64, there
Add kexec_image_info to print detailed information about a kexec image.
Signed-off-by: Łukasz Stelmach
---
arch/arm/kernel/machine_kexec.c | 28
1 file changed, 28 insertions(+)
diff --git a/arch/arm/kernel/machine_kexec.c b/arch/arm/kernel/machine_kexec.c
index 5d8
This is kexec_file_load implementation for ARM. It loads zImage and
initrd from file descripters and resuses DTB.
Most code is derived from arm64 kexec_file_load implementation
and from kexec-tools.
Cc: AKASHI Takahiro
Signed-off-by: Łukasz Stelmach
---
arch/arm/Kconfig |
This structure will be used later by kexec_file loader.
Signed-off-by: Łukasz Stelmach
---
arch/arm/boot/compressed/head.S| 3 +-
arch/arm/boot/compressed/vmlinux.lds.S | 13 ++-
arch/arm/include/asm/image.h | 50 ++
3 files changed, 55 insertions(+
Add DCSZ tag which holds dynamic memory (stack, bss, malloc pool)
requirements of the decompressor code.
Signed-off-by: Łukasz Stelmach
---
arch/arm/boot/compressed/vmlinux.lds.S | 9 -
arch/arm/include/asm/image.h | 3 +++
2 files changed, 11 insertions(+), 1 deletion(-)
diff
Hi Axel,
On Tue, 2020-09-29 at 14:56 -0700, Axel Rasmussen wrote:
> On Tue, Sep 29, 2020 at 1:33 PM Tom Zanussi
> wrote:
> >
> > synth_field_size() returns either the size or an error. However,
> > the
> > code assigns the return val to ssize_t which is unsigned, and then
> > tests whether it's
Currently, sythetic events only support static string fields such as:
# echo 'test_latency u64 lat; char somename[32]' >
/sys/kernel/debug/tracing/synthetic_events
Which is fine, but wastes a lot of space in the event.
It also prevents the most commonly-defined strings in the existing
trace e
32 is too small for this value, and anyway it makes more sense to use
MAX_FILTER_STR_VAL, as this is also the value used for variable-length
__strings.
Signed-off-by: Tom Zanussi
---
kernel/trace/trace_synth.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/trace/trace
701 - 800 of 1591 matches
Mail list logo
