> On 29-Jul-2021, at 9:43 PM, Will Deacon wrote:
>
> On Wed, Jul 28, 2021 at 10:35:34AM -0700, Nathan Chancellor wrote:
>> On Wed, Jul 28, 2021 at 01:31:06PM +0530, Sachin Sant wrote:
>>> next-20210723 was good. The boot failure seems to have been introduced with
>>> next-20210726.
>>>
>>>
The powernv-rng driver has 2 users - the bare metal powernv platform and
the KVM's H_RANDOM hcall. The hcall handler works fine when it is L0 KVM
but fails in L1 KVM as there is no support for the HW registers in L1 VMs
and such support is not advertised either (== no "ibm,power-rng" in
the FDT).
-20210729
x86_64 randconfig-a011-20210729
x86_64 randconfig-a014-20210729
x86_64 randconfig-a013-20210729
x86_64 randconfig-a012-20210729
x86_64 randconfig-a015-20210729
i386 randconfig-a016-20210728
i386
randconfig-a005-20210728
i386 randconfig-a003-20210728
i386 randconfig-a004-20210728
i386 randconfig-a002-20210728
i386 randconfig-a001-20210728
i386 randconfig-a006-20210728
x86_64 randconfig-a016-20210729
x86_64
randconfig-a003-20210728
i386 randconfig-a004-20210728
i386 randconfig-a002-20210728
i386 randconfig-a001-20210728
i386 randconfig-a006-20210728
x86_64 randconfig-a016-20210729
x86_64 randconfig
randconfig-a004-20210728
i386 randconfig-a002-20210728
i386 randconfig-a001-20210728
i386 randconfig-a006-20210728
x86_64 randconfig-a016-20210729
x86_64 randconfig-a011-20210729
x86_64 randconfig-a014-20210729
This prepares removing the driver member of struct pci_dev which holds the
same information than struct pci_dev::dev->driver.
Signed-off-by: Uwe Kleine-König
---
arch/powerpc/include/asm/ppc-pci.h| 3 +-
arch/powerpc/kernel/eeh_driver.c | 12 ---
Hello,
struct pci_dev tracks the bound pci driver twice. This series is about
removing this duplication.
The first two patches are just cleanups. The third patch introduces a
wrapper that abstracts access to struct pci_dev->driver. In the next
patch (hopefully) all users are converted to use the
On Thu, Jul 29, 2021 at 6:42 AM Paul Menzel wrote:
>
> Dear Michael,
>
>
> Am 29.07.21 um 15:12 schrieb Michael Ellerman:
> > The Go runtime uses r30 for some special value called 'g'. It assumes
> > that value will remain unchanged even when calling VDSO functions.
> > Although r30 is
From: Martin Oliveira
The .map_sg() op now expects an error code instead of zero on failure.
pci_map_single_1() can fail for different reasons, but since the only
supported type of error return is DMA_MAPPING_ERROR, we coalesce those
errors into EIO.
ENOMEM is returned when no page tables can
Setting the ->dma_address to DMA_MAPPING_ERROR is not part of the
->map_sg calling convention, so remove it.
Link: https://lore.kernel.org/linux-mips/20210716063241.gc13...@lst.de/
Suggested-by: Christoph Hellwig
Signed-off-by: Logan Gunthorpe
Cc: Russell King
Cc: Thomas Bogendoerfer
---
From: Martin Oliveira
The .map_sg() op now expects an error code instead of zero on failure.
In the case of a DMA_MAPPING_ERROR, -EIO is returned. Otherwise,
-ENOMEM or -EINVAL is returned depending on the error from
__map_sg_chunk().
Signed-off-by: Martin Oliveira
Signed-off-by: Logan
From: Martin Oliveira
The .map_sg() op now expects an error code instead of zero on failure.
Propagate the error up if vio_dma_iommu_map_sg() fails.
ppc_iommu_map_sg() may fail either because of iommu_range_alloc() or
because of tbl->it_ops->set(). The former only supports returning an
error
From: Martin Oliveira
The .map_sg() op now expects an error code instead of zero on failure.
In the case of a dma_mapping_error() return -EIO as the actual cause
is opaque here.
sba_coalesce_chunks() may only presently fail if sba_alloc_range()
fails, which in turn only fails if the iommu is
Setting the ->dma_address to DMA_MAPPING_ERROR is not part of
the ->map_sg calling convention, so remove it.
Link: https://lore.kernel.org/linux-mips/20210716063241.gc13...@lst.de/
Suggested-by: Christoph Hellwig
Signed-off-by: Logan Gunthorpe
Cc: Michael Ellerman
Cc: Benjamin Herrenschmidt
From: Martin Oliveira
The .map_sg() op now expects an error code instead of zero on failure.
vdma_alloc() may fail for different reasons, but since it only supports
indicating an error via a return of DMA_MAPPING_ERROR, we coalesce the
different reasons into -EIO as is documented on
Setting the ->dma_address to DMA_MAPPING_ERROR is not part of
the ->map_sg calling convention, so remove it.
Link: https://lore.kernel.org/linux-mips/20210716063241.gc13...@lst.de/
Suggested-by: Christoph Hellwig
Signed-off-by: Logan Gunthorpe
Cc: Niklas Schnelle
Cc: Gerald Schaefer
Cc: Heiko
From: Martin Oliveira
The .map_sg() op now expects an error code instead of zero on failure.
So propagate the error from __s390_dma_map_sg() up. __s390_dma_map_sg()
returns either -ENOMEM on allocation failure or -EINVAL which is
the same as what's expected by dma_map_sgtable().
Signed-off-by:
From: Martin Oliveira
The .map_sg() op now expects an error code instead of zero on failure.
Returning an errno from __sbus_iommu_map_sg() results in
sbus_iommu_map_sg_gflush() and sbus_iommu_map_sg_pflush() returning an
errno, as those functions are wrappers around __sbus_iommu_map_sg().
From: Martin Oliveira
The .map_sg() op now expects an error code instead of zero on failure.
Return -EINVAL if the ioc cannot be obtained.
Signed-off-by: Martin Oliveira
Signed-off-by: Logan Gunthorpe
Cc: "James E.J. Bottomley"
Cc: Helge Deller
---
drivers/parisc/ccio-dma.c | 2 +-
Setting the ->dma_address to DMA_MAPPING_ERROR is not part of
the ->map_sg calling convention, so remove it.
Link: https://lore.kernel.org/linux-mips/20210716063241.gc13...@lst.de/
Suggested-by: Christoph Hellwig
Signed-off-by: Logan Gunthorpe
Cc: "David S. Miller"
Cc: Niklas Schnelle
Cc:
Setting the ->dma_address to DMA_MAPPING_ERROR is not part of
the ->map_sg calling convention, so remove it.
Link: https://lore.kernel.org/linux-mips/20210716063241.gc13...@lst.de/
Suggested-by: Christoph Hellwig
Signed-off-by: Logan Gunthorpe
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav
From: Martin Oliveira
The .map_sg() op now expects an error code instead of zero on failure.
So make __dma_map_cont() return a valid errno (which is then propagated
to gart_map_sg() via dma_map_cont()) and return it in case of failure.
Also, return -EINVAL in case of invalid nents.
Hi,
This v3 of the series is spun out and expanded from my work to add
P2PDMA support to DMA map operations[1]. v2 is at [2]. The main changes
in v1 are to more carefully define the meaning of the error codes for
dma_map_sgtable().
The P2PDMA work requires distinguishing different error
Allow dma_map_sgtable() to pass errors from the map_sg() ops. This
will be required for returning appropriate error codes when mapping
P2PDMA memory.
Introduce __dma_map_sg_attrs() which will return the raw error code
from the map_sg operation (whether it be negative or zero). Then add a
Now that the map_sg() op expects error codes instead of return zero on
error, convert dma_direct_map_sg() to return an error code. Per the
documentation for dma_map_sgtable(), -EIO is returned due to an
DMA_MAPPING_ERROR with unknown cause.
Signed-off-by: Logan Gunthorpe
---
kernel/dma/direct.c
Return appropriate error codes EINVAL or ENOMEM from
iommup_dma_map_sg(). If lower level code returns ENOMEM, then we
return it, other errors are coalesced into EINVAL.
iommu_dma_map_sg_swiotlb() returns -EIO as its an unknown error
from a call that returns DMA_MAPPING_ERROR.
Signed-off-by:
Now that all the .map_sg operations have been converted to returning
proper error codes, drop the code to handle a zero return value,
add a warning if a zero is returned.
Signed-off-by: Logan Gunthorpe
---
kernel/dma/mapping.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff
From: Martin Oliveira
The .map_sg() op now expects an error code instead of zero on failure.
xen_swiotlb_map_sg() may only fail if xen_swiotlb_map_page() fails, but
xen_swiotlb_map_page() only supports returning errors as
DMA_MAPPING_ERROR. So coalesce all errors into EIO per the documentation
Convert to ssize_t return code so the return code from __iommu_map()
can be returned all the way down through dma_iommu_map_sg().
Signed-off-by: Logan Gunthorpe
Cc: Joerg Roedel
Cc: Will Deacon
---
drivers/iommu/iommu.c | 15 +++
include/linux/iommu.h | 22 +++---
From: Martin Oliveira
The .map_sg() op now expects an error code instead of zero on failure.
The only errno to return is -EINVAL in the case when DMA is not
supported.
Signed-off-by: Martin Oliveira
Signed-off-by: Logan Gunthorpe
---
kernel/dma/dummy.c | 2 +-
1 file changed, 1
On 7/29/2021 9:35 AM, Konrad Rzeszutek Wilk wrote:
On Thu, Jul 29, 2021 at 05:13:36PM +0100, Will Deacon wrote:
On Wed, Jul 28, 2021 at 10:35:34AM -0700, Nathan Chancellor wrote:
On Wed, Jul 28, 2021 at 01:31:06PM +0530, Sachin Sant wrote:
next-20210723 was good. The boot failure seems to
commit 7c6986ade69e ("powerpc/stacktrace: Fix spurious "stale" traces in
raise_backtrace_ipi()")
introduces udelay() call without including the linux/delay.h header.
This may happen to work on master but the header that declares the
functionshould be included nonetheless.
Fixes: 7c6986ade69e
On Thu, Jul 29, 2021 at 05:13:36PM +0100, Will Deacon wrote:
> On Wed, Jul 28, 2021 at 10:35:34AM -0700, Nathan Chancellor wrote:
> > On Wed, Jul 28, 2021 at 01:31:06PM +0530, Sachin Sant wrote:
> > > next-20210723 was good. The boot failure seems to have been introduced
> > > with next-20210726.
On Wed, Jul 28, 2021 at 10:35:34AM -0700, Nathan Chancellor wrote:
> On Wed, Jul 28, 2021 at 01:31:06PM +0530, Sachin Sant wrote:
> > next-20210723 was good. The boot failure seems to have been introduced with
> > next-20210726.
> >
> > I have attached the boot log.
>
> I noticed this with
Currently, the install target in arch/powerpc/Makefile descends into
arch/powerpc/boot/Makefile to invoke the shell script, but there is no
good reason to do so.
arch/powerpc/Makefile can run the shell script directly.
Signed-off-by: Masahiro Yamada
---
arch/powerpc/Makefile | 3 ++-
Commit c913e5f95e54 ("powerpc/boot: Don't install zImage.* from make
install") added the zInstall target to arch/powerpc/boot/Makefile,
but you cannot use it since the corresponding hook is missing in
arch/powerpc/Makefile.
It has never worked since its addition. Nobody has complained about
it
The install target should not depend on any build artifact.
The reason is explained in commit 19514fc665ff ("arm, kbuild: make
"make install" not depend on vmlinux").
Change the PowerPC installation code in a similar way.
Signed-off-by: Masahiro Yamada
---
arch/powerpc/boot/Makefile | 2
On 7/28/21 8:22 AM, Christoph Hellwig wrote:
> On Tue, Jul 27, 2021 at 05:26:05PM -0500, Tom Lendacky via iommu wrote:
>> Introduce an x86 version of the prot_guest_has() function. This will be
>> used in the more generic x86 code to replace vendor specific calls like
>> sev_active(), etc.
>>
>>
Dear Michael,
Am 29.07.21 um 15:12 schrieb Michael Ellerman:
The Go runtime uses r30 for some special value called 'g'. It assumes
that value will remain unchanged even when calling VDSO functions.
Although r30 is non-volatile across function calls, the callee is free
to use it, as long as the
The Go runtime uses r30 for some special value called 'g'. It assumes
that value will remain unchanged even when calling VDSO functions.
Although r30 is non-volatile across function calls, the callee is free
to use it, as long as the callee saves the value and restores it before
returning.
It
Paul Menzel writes:
> Am 29.07.21 um 09:41 schrieb Michael Ellerman:
>> Paul Menzel writes:
>
>>> Am 28.07.21 um 14:43 schrieb Michael Ellerman:
Paul Menzel writes:
> Am 28.07.21 um 01:14 schrieb Benjamin Herrenschmidt:
>> On Tue, 2021-07-27 at 10:45 +0200, Paul Menzel wrote:
>
Replace the 'unsigned' with 'unsigned int' which is more accurate.
Signed-off-by: Jason Wang
---
arch/powerpc/perf/hv-24x7.c | 38 ++---
1 file changed, 19 insertions(+), 19 deletions(-)
diff --git a/arch/powerpc/perf/hv-24x7.c b/arch/powerpc/perf/hv-24x7.c
On 2021/7/29 12:05, Steven Rostedt wrote:
On Thu, 29 Jul 2021 10:00:51 +0800
Kefeng Wang wrote:
On 2021/7/28 23:28, Steven Rostedt wrote:
On Wed, 28 Jul 2021 16:13:18 +0800
Kefeng Wang wrote:
The is_kernel[_text]() function check the address whether or not
in kernel[_text] ranges,
On Jul 29 2021, Michael Ellerman wrote:
> I haven't been able to reproduce the crash by following the instructions
> in your bug report, I have go1.13.8, I guess the crash is only in newer
> versions?
Yes, only go1.14 and later are affected.
Dear Michael,
Am 29.07.21 um 09:41 schrieb Michael Ellerman:
Paul Menzel writes:
Am 28.07.21 um 14:43 schrieb Michael Ellerman:
Paul Menzel writes:
Am 28.07.21 um 01:14 schrieb Benjamin Herrenschmidt:
On Tue, 2021-07-27 at 10:45 +0200, Paul Menzel wrote:
On ppc64le Go 1.16.2 from
Dear Linux folks,
I just wanted to make you aware that building Linux for ppc64le with
clang/lld.ld fails with [1]:
ld.lld: error: can't create dynamic relocation R_PPC64_ADDR64
against symbol: empty_zero_page in readonly segment; recompile object
files with -fPIC or pass
Paul Menzel writes:
> Dear Michael,
>
>
> Am 28.07.21 um 14:43 schrieb Michael Ellerman:
>> Paul Menzel writes:
>>> Am 28.07.21 um 01:14 schrieb Benjamin Herrenschmidt:
On Tue, 2021-07-27 at 10:45 +0200, Paul Menzel wrote:
>>>
> On ppc64le Go 1.16.2 from Ubuntu 21.04 terminates with a
Looks good:
Reviewed-by: Christoph Hellwig
With Commit c9f3401313a5 ("powerpc: Always enable queued spinlocks for
64s, disable for others") CONFIG_PPC_QUEUED_SPINLOCKS is always
enabled on ppc64le, external modules that use spinlock APIs are
failing.
ERROR: modpost: GPL-incompatible module XXX.ko uses GPL-only symbol
'shared_processor'
50 matches
Mail list logo
