The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to
On 21/02/23 18:50, Yury Norov wrote:
> Use node_has_cpus() as more efficient alternative to nr_cpus_node()
> where possible.
>
> Signed-off-by: Yury Norov
Reviewed-by: Valentin Schneider
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to
On 21/02/23 18:50, Yury Norov wrote:
> Currently, to check if NUMA node has CPUs, one has to use the
> nr_cpus_node() macro, which ends up with cpumask_weight. We can do it
> better with cpumask_empty(), because the latter can potentially return
> earlier - as soon as 1st set bit found.
>
> This
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to
On Tue, Mar 14, 2023 at 11:38 PM Andrea Righi
wrote:
>
> On Mon, Mar 13, 2023 at 11:09:31PM +0100, Andrea Righi wrote:
> > On Mon, Mar 13, 2023 at 11:02:34PM +0100, Michal Suchánek wrote:
> > > On Mon, Mar 13, 2023 at 10:53:34PM +0100, Andrea Righi wrote:
> > > > On Mon, Mar 13, 2023 at
On Tue, Dec 06, 2022 at 04:13:35PM -0600, Bjorn Helgaas wrote:
> On Wed, Sep 28, 2022 at 06:59:41PM +0800, Zhuo Chen wrote:
> > lpfc_aer_cleanup_state() requires clearing both fatal and non-fatal
> > uncorrectable error status.
>
> I don't know what the point of lpfc_aer_cleanup_state() is. AER
Commit 21b56c847753 ("iov_iter: get rid of separate bvec and xarray
callbacks") removed the calls to memcpy_page_flushcache().
Remove the unnecessary memcpy_page_flushcache() call.
Cc: Al Viro
Cc: "Dan Williams"
Cc: Catalin Marinas
Cc: Will Deacon
Cc: linux-arm-ker...@lists.infradead.org
Commit 21b56c847753 ("iov_iter: get rid of separate bvec and xarray
callbacks") removed the calls to memcpy_page_flushcache().
Remove the unnecessary memcpy_page_flushcache() call.
Cc: Michael Ellerman
Cc: Nicholas Piggin
Cc: Christophe Leroy
Cc: Al Viro
Cc: "Dan Williams"
Cc:
Dave Hansen wrote:
> On 3/15/23 16:20, Ira Weiny wrote:
> > Commit 21b56c847753 ("iov_iter: get rid of separate bvec and xarray
> > callbacks") removed the calls to memcpy_page_flushcache().
> >
> > kmap_atomic() is deprecated and used in the x86 version of
> > memcpy_page_flushcache().
> >
> >
-20230313 gcc
arm64allyesconfig gcc
arm64 defconfig gcc
arm64randconfig-r002-20230313 gcc
arm64randconfig-r012-20230315 clang
arm64randconfig-r033-20230312 clang
arm64
On Thu, Mar 16, 2023 at 01:18:23AM +0900, Masahiro Yamada wrote:
> On Tue, Mar 14, 2023 at 11:38 PM Andrea Righi
> wrote:
> >
> > On Mon, Mar 13, 2023 at 11:09:31PM +0100, Andrea Righi wrote:
> > > On Mon, Mar 13, 2023 at 11:02:34PM +0100, Michal Suchánek wrote:
> > > > On Mon, Mar 13, 2023 at
On Wed, Sep 28, 2022 at 06:59:38PM +0800, Zhuo Chen wrote:
> In lpfc_aer_cleanup_state(), uncorrectable error status needs to be
> cleared, which can be done by calling pci_aer_clear_nonfatal_status()
> and pci_aer_clear_fatal_status(). Meanwhile they can be combined in
> one function (the same in
On 3/15/23 16:20, Ira Weiny wrote:
> Commit 21b56c847753 ("iov_iter: get rid of separate bvec and xarray
> callbacks") removed the calls to memcpy_page_flushcache().
>
> kmap_atomic() is deprecated and used in the x86 version of
> memcpy_page_flushcache().
>
> Remove the unnecessary
Commit 21b56c847753 ("iov_iter: get rid of separate bvec and xarray
callbacks") removed the calls to memcpy_page_flushcache().
kmap_atomic() is deprecated and used in memcpy_page_flushcache().
Remove the unnecessary memcpy_page_flushcache() call.
Cc: Al Viro
Cc: "Dan Williams"
Cc: Thomas
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git
fixes
branch HEAD: f2c7e3562b4c4f1699acc1538ebf3e75f5cced35 powerpc/mm: Fix false
detection of read faults
elapsed time: 729m
configs tested: 71
configs skipped: 138
The following configs have been built
Andrea Righi writes:
> On Wed, Mar 15, 2023 at 02:30:53PM +1100, Michael Ellerman wrote:
>> Andrea Righi writes:
>> > I'm triggering the following bug when booting my qemu powerpc VM:
>>
>> I'm not seeing that here :/
>>
>> Can you give a bit more detail?
>> - qemu version
>> - qemu command
On Wed, Sep 28, 2022 at 06:59:40PM +0800, Zhuo Chen wrote:
> There is no need to clear error status during init code, so remove it.
>
> Signed-off-by: Zhuo Chen
Can you send this to the NTB folks? It doesn't depend on anything, so
no real reason to merge via the PCI tree.
To help reviewers,
Commit 21b56c847753 ("iov_iter: get rid of separate bvec and xarray
callbacks") removed the calls to memcpy_page_flushcache().
kmap_atomic() is deprecated and used in the x86 version of
memcpy_page_flushcache().
Remove the unnecessary memcpy_page_flushcache() call from all arch's.
Michael Ellerman writes:
> Kautuk Consul writes:
>> On 2023-03-15 15:48:53, Michael Ellerman wrote:
>>> Kautuk Consul writes:
>>> > kvmppc_hv_entry is called from only 2 locations within
>>> > book3s_hv_rmhandlers.S. Both of those locations set r4
>>> > as HSTATE_KVM_VCPU(r13) before calling
Hi,
On 2023-03-16 14:39:08, Michael Ellerman wrote:
> Kautuk Consul writes:
> > On 2023-03-15 15:48:53, Michael Ellerman wrote:
> >> Kautuk Consul writes:
> >> > kvmppc_hv_entry is called from only 2 locations within
> >> > book3s_hv_rmhandlers.S. Both of those locations set r4
> >> > as
On Thu, Mar 16, 2023 at 02:58:04PM +1100, Michael Ellerman wrote:
>
> Although one question I do have for you is what rules, if any, do we
> have for deciding whether crypto code goes in drivers/crypto vs
> arch/*/crypto?
If it's on the CPU then it should probably live under arch. Yes
there have
kvmppc_hv_entry isn't called from anywhere other than
book3s_hv_rmhandlers.S itself. Removing .global scope for
this function and annotating it with SYM_INNER_LABEL.
Signed-off-by: Kautuk Consul
---
arch/powerpc/kvm/book3s_hv_rmhandlers.S | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
kvmppc_hv_entry is called from only 2 locations within
book3s_hv_rmhandlers.S. Both of those locations set r4
as HSTATE_KVM_VCPU(r13) before calling kvmppc_hv_entry.
So, shift the r4 load instruction to kvmppc_hv_entry and
thus modify the calling convention of this function.
Signed-off-by: Kautuk
Hi,
This series adds initial KVM selftests support for powerpc
(64-bit, BookS). It spans 3 maintainers but it does not really
affect arch/powerpc, and it is well contained in selftests
code, just touches some makefiles and a tiny bit headers so
conflicts should be unlikely and trivial.
I guess
Herbert Xu writes:
> On Tue, Mar 14, 2023 at 09:44:52PM +1100, Michael Ellerman wrote:
>>
>> Hmm. Seems none of them were ever Cc'ed to linuxppc-dev. So this is the
>> first I've seen of them.
>
> Sorry, I didn't know that you weren't aware of this change. I
> will be more careful with these ppc
Kautuk Consul writes:
> On 2023-03-15 15:48:53, Michael Ellerman wrote:
>> Kautuk Consul writes:
>> > kvmppc_hv_entry is called from only 2 locations within
>> > book3s_hv_rmhandlers.S. Both of those locations set r4
>> > as HSTATE_KVM_VCPU(r13) before calling kvmppc_hv_entry.
>> > So, shift the
Rob Herring writes:
> It is preferred to use typed property access functions (i.e.
> of_property_read_ functions) rather than low-level
> of_get_property/of_find_property functions for reading properties.
> Convert reading boolean properties to to of_property_read_bool().
>
> Signed-off-by: Rob
Implement KVM selftests support for Book3S-64.
ucalls are implemented with an unsuppored PAPR hcall number which causes
KVM to exit to userspace.
Virtual memory is only implemented for 64K page size and the radix MMU,
and only the base page size is supported for now.
Signed-off-by: Nicholas
Add some tests that exercise basic functions of the kvm selftests
framework, guest creation, ucalls, hcalls, copying data between guest
and host, interrupts and page faults.
These don't test KVM so much, but were useful when developing the
selftests support for powerpc.
Signed-off-by: Nicholas
Hello,
this series adapts the platform drivers below sound/ to use the .remove_new()
callback. Compared to the traditional .remove() callback .remove_new() returns
no value. This is a good thing because the driver core doesn't (and cannot)
cope for errors during remove. The only effect of a
- remove .global scope of kvmppc_hv_entry
- remove r4 argument to kvmppc_hv_entry as it is not required
Changes since v2:
- Add the lwsync instruction before the load to r4 to order
load of vcore before load of vcpu
Kautuk Consul (2):
arch/powerpc/kvm: kvmppc_hv_entry: remove .global scope
On Wed, Mar 15, 2023 at 07:10:25AM +0100, Andrea Righi wrote:
> On Wed, Mar 15, 2023 at 02:30:53PM +1100, Michael Ellerman wrote:
> > Andrea Righi writes:
> > > I'm triggering the following bug when booting my qemu powerpc VM:
> >
> > I'm not seeing that here :/
> >
> > Can you give a bit more
On Wed, Mar 15, 2023 at 01:15:03AM +0100, Vincenzo Palazzo wrote:
> > In practice, this is what I'm testing at the moment:
> >
> > ---
> > diff --git a/arch/powerpc/kernel/module_64.c
> > b/arch/powerpc/kernel/module_64.c
> > index ff045644f13f..ea6c830ed1e7 100644
> > ---
On Wed, Mar 15, 2023 at 02:30:53PM +1100, Michael Ellerman wrote:
> Andrea Righi writes:
> > I'm triggering the following bug when booting my qemu powerpc VM:
>
> I'm not seeing that here :/
>
> Can you give a bit more detail?
> - qemu version
> - qemu command line
> - what userspace are you
Le 15/03/2023 à 06:14, Matthew Wilcox (Oracle) a écrit :
> Add set_ptes(), update_mmu_cache_range() and flush_dcache_folio().
> Change the PG_arch_1 (aka PG_dcache_dirty) flag from being per-page to
> per-folio.
>
> Signed-off-by: Matthew Wilcox (Oracle)
> Cc: Michael Ellerman
> Cc: Nicholas
On Tue, Mar 14, 2023 at 02:14:37PM -0500, Rob Herring wrote:
> On Sat, Mar 11, 2023 at 5:50 AM Simon Horman
> wrote:
> >
> > On Fri, Mar 10, 2023 at 08:47:16AM -0600, Rob Herring wrote:
> > > It is preferred to use typed property access functions (i.e.
> > > of_property_read_ functions) rather
Hi Sean,
I love your patch! Perhaps something to improve:
[auto build test WARNING on shawnguo/for-next]
[also build test WARNING on brgl/gpio/for-next clk/clk-next linus/master
v6.3-rc2 next-20230315]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting
On Wed, Mar 15, 2023 at 05:14:28AM +, Matthew Wilcox (Oracle) wrote:
> Add set_ptes(), update_mmu_cache_range() and flush_dcache_folio().
> Change the PG_arch_1 (aka PG_dcache_dirty) flag from being per-page to
> per-folio.
>
> Signed-off-by: Matthew Wilcox (Oracle)
> Cc: Michael Ellerman
>
Le 15/03/2023 à 10:43, Christophe Leroy a écrit :
>
>
> Le 15/03/2023 à 06:14, Matthew Wilcox (Oracle) a écrit :
>> Add set_ptes(), update_mmu_cache_range() and flush_dcache_folio().
>> Change the PG_arch_1 (aka PG_dcache_dirty) flag from being per-page to
>> per-folio.
>>
>> Signed-off-by:
On Tue, 14 Mar 2023 09:21:57 +0100, Herve Codina wrote:
> The QMC depends on (SOC_FSL && COMPILE_TEST). SOC_FSL does not exist.
>
> Fix the dependency using the correct one: FSL_SOC.
>
>
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next
Thanks!
[1/1]
55 matches
Mail list logo
