Re: [PATCH v2 13/29] arch: add split IPC system calls where needed

On Fri, Jan 18, 2019 at 05:18:19PM +0100, Arnd Bergmann wrote: > The IPC system call handling is highly inconsistent across architectures, > some use sys_ipc, some use separate calls, and some use both. We also > have some architectures that require passing IPC_64 in the flags, and > others that s

Re: [PATCH 4/4] powerpc/64s: Support shrinking the SLB for debugging

On Thu, 17 Jan 2019 23:13:28 +1100 Michael Ellerman wrote: > On machines with 1TB segments and a 32-entry SLB it's quite hard to > cause sufficient SLB pressure to trigger bugs caused due to badly > timed SLB faults. > > We have seen this in the past and a few years ago added the > disable_1tb_s

Re: [PATCH v2 00/29] y2038: add time64 syscalls

On 1/18/19 12:14 PM, Arnd Bergmann wrote: On Fri, Jan 18, 2019 at 5:57 PM Dennis Clarke wrote: On 1/18/19 11:18 AM, Arnd Bergmann wrote: This is a minor update of the patches I posted last week, I would like to add this into linux-next now, but would still do changes if there are concerns abo

Re: [PATCH v2 00/29] y2038: add time64 syscalls

On 1/18/19 11:18 AM, Arnd Bergmann wrote: This is a minor update of the patches I posted last week, I would like to add this into linux-next now, but would still do changes if there are concerns about the contents. The first version did not see a lot of replies, which could mean that either every

Re: [PATCH 2/4] powerpc/64s: Add slb_full_bitmap rather than hard-coding U32_MAX

On Fri, Jan 18, 2019 at 11:28:24PM +1100, Michael Ellerman wrote: > Segher Boessenkool writes: > > > On Thu, Jan 17, 2019 at 11:13:26PM +1100, Michael Ellerman wrote: > >> The recent rewrite of the SLB code into C included the assumption that > >> all CPUs we run on have at least 32 SLB entries.

Re: [PATCH] soc: fsl: qbman: avoid race in clearing QMan interrupt

On Fri, Dec 21, 2018 at 8:43 AM Madalin Bucur wrote: > > By clearing all interrupt sources, not only those that > already occurred, the existing code may acknowledge by > mistake interrupts that occurred after the code checks > for them. > > Signed-off-by: Madalin Bucur > Signed-off-by: Roy Pledg

Re: [PATCH v2 00/29] y2038: add time64 syscalls

On Fri, 2019-01-18 at 11:57 -0500, Dennis Clarke wrote: > On 1/18/19 11:18 AM, Arnd Bergmann wrote: > > This is a minor update of the patches I posted last week, I > > would like to add this into linux-next now, but would still do > > changes if there are concerns about the contents. The first > >

Re: [PATCH v2 29/29] y2038: add 64-bit time_t syscalls to all 32-bit architectures

On Fri, Jan 18, 2019 at 8:53 PM Andy Lutomirski wrote: > I think we have two issues if we reuse those numbers for new syscalls. > First, I'd really like to see new syscalls be numbered consistently > everywhere, or at least on all x86 variants, and we can't on x32 > because they mean something els

Re: [PATCH v2 29/29] y2038: add 64-bit time_t syscalls to all 32-bit architectures

On Fri, Jan 18, 2019 at 11:33 AM Arnd Bergmann wrote: > > On Fri, Jan 18, 2019 at 7:50 PM Andy Lutomirski wrote: > > On Fri, Jan 18, 2019 at 8:25 AM Arnd Bergmann wrote: > > > - Once we get to 512, we clash with the x32 numbers (unless > > > we remove x32 support first), and probably have to s

Re: [PATCH v3 0/4] Add NXP AUDMIX device and machine drivers

On Fri, Jan 18, 2019 at 01:16:24PM +, Viorel Suman wrote: > > > 1. Moved "dais" node from machine driver DTS node to device driver > > > DTS node > > >   as suggested by Rob. > > That was not what I suggested. You still have a virtual node which > > looks to me to be unnecessary. > > To me rem

Re: [PATCH v2 29/29] y2038: add 64-bit time_t syscalls to all 32-bit architectures

On Fri, Jan 18, 2019 at 7:50 PM Andy Lutomirski wrote: > On Fri, Jan 18, 2019 at 8:25 AM Arnd Bergmann wrote: > > - Once we get to 512, we clash with the x32 numbers (unless > > we remove x32 support first), and probably have to skip > > a few more. I also considered using the 512..547 space

Re: [PATCH v2 13/29] arch: add split IPC system calls where needed

On Fri, Jan 18, 2019 at 6:20 PM Gabriel Paubert wrote: > > On Fri, Jan 18, 2019 at 05:18:19PM +0100, Arnd Bergmann wrote: > > The IPC system call handling is highly inconsistent across architectures, > > some use sys_ipc, some use separate calls, and some use both. We also > > have some architect

Re: [PATCH v2 29/29] y2038: add 64-bit time_t syscalls to all 32-bit architectures

On Fri, Jan 18, 2019 at 8:25 AM Arnd Bergmann wrote: > > This adds 21 new system calls on each ABI that has 32-bit time_t > today. All of these have the exact same semantics as their existing > counterparts, and the new ones all have macro names that end in 'time64' > for clarification. > > This g

Re: [GIT PULL] Please pull powerpc/linux.git powerpc-5.0-3 tag

The pull request you sent on Fri, 18 Jan 2019 23:45:09 +1100: > https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git > tags/powerpc-5.0-3 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/c5b709804ed7d36c45b5efa170d9e3ea8c29b865 Thank you! -- Deet-doot-do

Re: [PATCH 19/21] treewide: add checks for the return value of memblock_alloc*()

Hi Mike, On Wed, Jan 16, 2019 at 03:44:19PM +0200, Mike Rapoport wrote: > Add check for the return value of memblock_alloc*() functions and call > panic() in case of error. > The panic message repeats the one used by panicing memblock allocators with > adjustment of parameters to include only rele

Re: [PATCH 12/21] arch: use memblock_alloc() instead of memblock_alloc_from(size, align, 0)

Hi Mike, On Wed, Jan 16, 2019 at 03:44:12PM +0200, Mike Rapoport wrote: > The last parameter of memblock_alloc_from() is the lower limit for the > memory allocation. When it is 0, the call is equivalent to > memblock_alloc(). > > Signed-off-by: Mike Rapoport Acked-by: Paul Burton # MIPS part

Re: [PATCH v2 00/29] y2038: add time64 syscalls

On Fri, Jan 18, 2019 at 5:57 PM Dennis Clarke wrote: > > On 1/18/19 11:18 AM, Arnd Bergmann wrote: > > This is a minor update of the patches I posted last week, I > > would like to add this into linux-next now, but would still do > > changes if there are concerns about the contents. The first > >

[PATCH v2 28/29] y2038: rename old time and utime syscalls

The time, stime, utime, utimes, and futimesat system calls are only used on older architectures, and we do not provide y2038 safe variants of them, as they are replaced by clock_gettime64, clock_settime64, and utimensat_time64. However, for consistency it seems better to have the 32-bit architectu

[PATCH v2 23/29] timex: change syscalls to use struct __kernel_timex

From: Deepa Dinamani struct timex is not y2038 safe. Switch all the syscall apis to use y2038 safe __kernel_timex. Note that sys_adjtimex() does not have a y2038 safe solution. C libraries can implement it by calling clock_adjtime(CLOCK_REALTIME, ...). Signed-off-by: Deepa Dinamani Signed-off

[PATCH v2 21/29] sparc64: add custom adjtimex/clock_adjtime functions

sparc64 is the only architecture on Linux that has a 'timeval' definition with a 32-bit tv_usec but a 64-bit tv_sec. This causes problems for sparc32 compat mode when we convert it to use the new __kernel_timex type that has the same layout as all other 64-bit architectures. To avoid adding sparc6

[PATCH v2 29/29] y2038: add 64-bit time_t syscalls to all 32-bit architectures

This adds 21 new system calls on each ABI that has 32-bit time_t today. All of these have the exact same semantics as their existing counterparts, and the new ones all have macro names that end in 'time64' for clarification. This gets us to the point of being able to safely use a C library that ha

[PATCH v2 25/29] y2038: syscalls: rename y2038 compat syscalls

A lot of system calls that pass a time_t somewhere have an implementation using a COMPAT_SYSCALL_DEFINEx() on 64-bit architectures, and have been reworked so that this implementation can now be used on 32-bit architectures as well. The missing step is to redefine them using the regular SYSCALL_DEF

[PATCH v2 26/29] y2038: use time32 syscall names on 32-bit

This is the big flip, where all 32-bit architectures set COMPAT_32BIT_TIME abd use the _time32 system calls from the former compat layer instead of the system calls that take __kernel_timespec and similar arguments. The temporary redirects for __kernel_timespec, __kernel_itimerspec and __kernel_ti

[PATCH v2 24/29] x86/x32: use time64 versions of sigtimedwait and recvmmsg

x32 has always followed the time64 calling conventions of these syscalls, which required a special hack in compat_get_timespec aka get_old_timespec32 to continue working. Since we now have the time64 syscalls, use those explicitly. Signed-off-by: Arnd Bergmann --- arch/x86/entry/syscalls/syscal

[PATCH v2 22/29] timex: use __kernel_timex internally

From: Deepa Dinamani struct timex is not y2038 safe. Replace all uses of timex with y2038 safe __kernel_timex. Note that struct __kernel_timex is an ABI interface definition. We could define a new structure based on __kernel_timex that is only available internally instead. Right now, there isn't

[PATCH v2 20/29] time: fix sys_timer_settime prototype

A small typo has crept into the y2038 conversion of the timer_settime system call. So far this was completely harmless, but once we start using the new version, this has to be fixed. Fixes: 6ff847350702 ("time: Change types to new y2038 safe __kernel_itimerspec") Signed-off-by: Arnd Bergmann ---

[PATCH v2 00/29] y2038: add time64 syscalls

This is a minor update of the patches I posted last week, I would like to add this into linux-next now, but would still do changes if there are concerns about the contents. The first version did not see a lot of replies, which could mean that either everyone is happy with it, or that it was largely

[PATCH v2 27/29] y2038: remove struct definition redirects

We now use 64-bit time_t on all architectures, so the __kernel_timex, __kernel_timeval and __kernel_timespec redirects can be removed after having served their purpose. This makes it all much less confusing, as the __kernel_* types now always refer to the same layout based on 64-bit time_t across

[PATCH v2 05/29] alpha: update syscall macro definitions

Other architectures commonly use __NR_umount2 for sys_umount, only ia64 and alpha use __NR_umount here. In order to synchronize the generated tables, use umount2 like everyone else, and add back the old name from asm/unistd.h for compatibility. For shmat, alpha uses the osf_shmat name, we can do t

[PATCH v2 12/29] ipc: rename old-style shmctl/semctl/msgctl syscalls

The behavior of these system calls is slightly different between architectures, as determined by the CONFIG_ARCH_WANT_IPC_PARSE_VERSION symbol. Most architectures that implement the split IPC syscalls don't set that symbol and only get the modern version, but alpha, arm, microblaze, mips-n32, mips-

[PATCH v2 18/29] time: make adjtime compat handling available for 32 bit

We want to reuse the compat_timex handling on 32-bit architectures the same way we are using the compat handling for timespec when moving to 64-bit time_t. Move all definitions related to compat_timex out of the compat code into the normal timekeeping code, along with a rename to old_timex32, corr

[PATCH v2 19/29] time: Add struct __kernel_timex

From: Deepa Dinamani struct timex uses struct timeval internally. struct timeval is not y2038 safe. Introduce a new UAPI type struct __kernel_timex that is y2038 safe. struct __kernel_timex uses a timeval type that is similar to struct __kernel_timespec which preserves the same structure size ac

[PATCH v2 17/29] syscalls: remove obsolete __IGNORE_ macros

These are all for ignoring the lack of obsolete system calls, which have been marked the same way in scripts/checksyscall.sh, so these can be removed. Signed-off-by: Arnd Bergmann --- arch/mips/include/asm/unistd.h | 16 arch/parisc/include/asm/unistd.h | 3 --- arch/s390/inc

[PATCH v2 09/29] sh: remove duplicate unistd_32.h file

When I merged this patch, the file was accidentally left intact instead of being removed, which means any changes to syscall.tbl have no effect. Fixes: 2b3c5a99d5f3 ("sh: generate uapi header and syscall table header files") Signed-off-by: Arnd Bergmann --- arch/sh/include/uapi/asm/unistd_32.h |

[PATCH v2 16/29] alpha: add generic get{eg,eu,g,p,u,pp}id() syscalls

Alpha has traditionally followed the OSF1 calling conventions here, with its getxpid, getxuid, getxgid system calls returning two different values in separate registers. Following what glibc has done here, we can define getpid, getuid and getgid to be aliases for getxpid, getxuid and getxgid respe

[PATCH v2 15/29] alpha: add standard statfs64/fstatfs64 syscalls

As Joseph Myers points out, alpha has never had a standard statfs64 interface and instead returns only 32-bit numbers here. While there is an old osf_statfs64 system call that returns additional data, this has some other quirks and does not get used in glibc. I considered making the stat64 struct

[PATCH v2 13/29] arch: add split IPC system calls where needed

The IPC system call handling is highly inconsistent across architectures, some use sys_ipc, some use separate calls, and some use both. We also have some architectures that require passing IPC_64 in the flags, and others that set it implicitly. For the additon of a y2083 safe semtimedop() system

[PATCH v2 14/29] arch: add pkey and rseq syscall numbers everywhere

Most architectures define system call numbers for the rseq and pkey system calls, even when they don't support the features, and perhaps never will. Only a few architectures are missing these, so just define them anyway for consistency. If we decide to add them later to one of these, the system ca

[PATCH v2 08/29] m68k: assign syscall number for seccomp

Most architectures have assigned a numbers for the seccomp syscall even when they do not implement it. m68k is an exception here, so for consistency lets add the number. Unless CONFIG_SECCOMP is implemented, the system call just returns -ENOSYS. Signed-off-by: Arnd Bergmann --- arch/m68k/kernel

[PATCH v2 01/29] ia64: add __NR_umount2 definition

Other architectures commonly use __NR_umount2 for sys_umount, only ia64 and alpha use __NR_umount here. In order to synchronize the generated tables, use umount2 like everyone else, and add back the old name from asm/unistd.h for compatibility. The __IGNORE_* lines are now all obsolete and can be

[PATCH v2 11/29] sparc64: fix sparc_ipc type conversion

__kernel_timespec and timespec are currently the same type, but once they are different, the type cast has to be changed here. Signed-off-by: Arnd Bergmann --- arch/sparc/kernel/sys_sparc_64.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/sparc/kernel/sys_sparc_64.c b/

[PATCH v2 07/29] ARM: add kexec_file_load system call number

A couple of architectures including arm64 already implement the kexec_file_load system call, on many others we have assigned a system call number for it, but not implemented it yet. Adding the number in arch/arm/ lets us use the system call on arm64 systems in compat mode, and also reduces the num

[PATCH v2 03/29] ia64: assign syscall numbers for perf and seccomp

Most architectures have assigned numbers for both seccomp and perf_event_open, even when they do not implement either. ia64 is an exception here, so for consistency lets add numbers for both of them. Unless CONFIG_PERF_EVENTS and CONFIG_SECCOMP are implemented, the system calls just return -ENOSYS

[PATCH v2 04/29] alpha: wire up io_pgetevents system call

The io_pgetevents system call was added in linux-4.18 but has no entry for alpha: warning: #warning syscall io_pgetevents not implemented [-Wcpp] Assign a the next system call number here. Cc: sta...@vger.kernel.org Signed-off-by: Arnd Bergmann --- arch/alpha/kernel/syscalls/syscall.tbl | 1 +

[PATCH v2 06/29] ARM: add migrate_pages() system call

The migrate_pages system call has an assigned number on all architectures except ARM. When it got added initially in commit d80ade7b3231 ("ARM: Fix warning: #warning syscall migrate_pages not implemented"), it was intentionally left out based on the observation that there are no 32-bit ARM NUMA sys

[PATCH v2 10/29] sh: add statx system call

statx is available on almost all other architectures but got missed on sh, so add it now. Signed-off-by: Arnd Bergmann --- arch/sh/kernel/syscalls/syscall.tbl | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/sh/kernel/syscalls/syscall.tbl b/arch/sh/kernel/syscalls/syscall.tbl index 21ec

[PATCH v2 02/29] ia64: add statx and io_pgetevents syscalls

All architectures should implement these two, so assign numbers and hook them up on ia64. Signed-off-by: Arnd Bergmann --- arch/ia64/kernel/syscalls/syscall.tbl | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/ia64/kernel/syscalls/syscall.tbl b/arch/ia64/kernel/syscalls/syscall.tbl in

Re: use generic DMA mapping code in powerpc V4

Hello Christoph, I was able to compile 257002094bc5935dd63207a380d9698ab81f0775 from your Git powerpc-dma.6-debug today. Unfortunately I don't see any error messages (kernel ring buffer) and I don't have a RS232 serial null modem cable to get them. Cheers, Christian

Re: [PATCH] powerpc/tm: Limit TM code inside PPC_TRANSACTIONAL_MEM

On Thu, Jan 17, 2019 at 09:49:05AM -0200, Breno Leitao wrote: hi Sasha, On 1/16/19 11:35 AM, Sasha Levin wrote: Hi, [This is an automated email] This commit has been processed because it contains a "Fixes:" tag, fixing commit: e1c3743e1a20 powerpc/tm: Set MSR[TS] just prior to recheckpoint.

[PATCH] powerpc: chrp: Use of_node_is_type to access device_type

Commit 8ce5f8415753 ("of: Remove struct device_node.type pointer") removed struct device_node.type pointer, but the conversion to use of_node_is_type() accessor was missed in chrp_init_IRQ(). Fixes: 8ce5f8415753 ("of: Remove struct device_node.type pointer") Reported-by: kbuild test robot Cc: Ben

Re: [PATCH v3 0/4] Add NXP AUDMIX device and machine drivers

Hi Rob, Nicolin, All, On Jo, 2019-01-17 at 10:18 -0600, Rob Herring wrote: > On Thu, Jan 17, 2019 at 12:46:25PM +, Viorel Suman wrote: > > > > The patchset adds NXP Audio Mixer (AUDMIX) device and machine > > drivers and related DT bindings documentation. > > > > Changes since V2: > > 1. Mov

Re: use generic DMA mapping code in powerpc V4

On Fri, Jan 18, 2019 at 01:46:46PM +0100, Christian Zigotzky wrote: > Sorry, it's not possible to patch > '257002094bc5935dd63207a380d9698ab81f0775' with your patch. I also tried it > manually but without any success. Weird: hch@carbon:~/work/linux$ git checkout 257002094bc5935dd63207a380d9698a

Re: use generic DMA mapping code in powerpc V4

Sorry, it's not possible to patch '257002094bc5935dd63207a380d9698ab81f0775' with your patch. I also tried it manually but without any success. -- Christian On 18 January 2019 at 1:18PM, Christoph Hellwig wrote: On Fri, Jan 18, 2019 at 01:07:54PM +0100, Christian Zigotzky wrote: git clone gi

[GIT PULL] Please pull powerpc/linux.git powerpc-5.0-3 tag

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Linus, Please pull some more powerpc fixes for 5.0: The following changes since commit bfeffd155283772bbe78c6a05dec7c0128ee500c: Linux 5.0-rc1 (2019-01-06 17:08:20 -0800) are available in the git repository at: https://git.kernel.org/pub/sc

Re: [PATCH 2/4] powerpc/64s: Add slb_full_bitmap rather than hard-coding U32_MAX

Segher Boessenkool writes: > On Thu, Jan 17, 2019 at 11:13:26PM +1100, Michael Ellerman wrote: >> The recent rewrite of the SLB code into C included the assumption that >> all CPUs we run on have at least 32 SLB entries. This is currently >> true but a bit fragile as the SLB size is actually defi

Re: use generic DMA mapping code in powerpc V4

On Fri, Jan 18, 2019 at 01:07:54PM +0100, Christian Zigotzky wrote: > git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.6 a > > git checkout 257002094bc5935dd63207a380d9698ab81f0775 > > > I get the following error message with your patch: Hmm. Did I attached the wrong patch? He

Re: use generic DMA mapping code in powerpc V4

git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.6 a git checkout 257002094bc5935dd63207a380d9698ab81f0775 I get the following error message with your patch: patching file a/kernel/dma/direct.c Hunk #1 FAILED at 118. Hunk #2 FAILED at 139. 2 out of 2 hunks FAILED -- saving r

[PATCH 2/3] dma-mapping: don't BUG when calling dma_map_resource on RAM

Use WARN_ON_ONCE to print a stack trace and return a proper error code instead. Signed-off-by: Christoph Hellwig Reviewed-by: Robin Murphy --- include/linux/dma-mapping.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mappin

[PATCH 3/3] videobuf2: replace a layering violation with dma_map_resource

vb2_dc_get_userptr pokes into arm direct mapping details to get the resemblance of a dma address for a a physical address that does is not backed by a page struct. Not only is this not portable to other architectures with dma direct mapping offsets, but also not to uses of IOMMUs of any kind. Swi

fix a layering violation in videobuf2 and improve dma_map_resource v2

Hi all, this series fixes a rather gross layering violation in videobuf2, which pokes into arm DMA mapping internals to get a DMA address for memory that does not have a page structure, and to do so fixes up the dma_map_resource implementation to not provide a somewhat dangerous default and improv

[PATCH 1/3] dma-mapping: remove the default map_resource implementation

Instead provide a proper implementation in the direct mapping code, and also wire it up for arm and powerpc, leaving an error return for all the IOMMU or virtual mapping instances for which we'd have to wire up an actual implementation Signed-off-by: Christoph Hellwig --- arch/arm/mm/dma-mapping

Re: use generic DMA mapping code in powerpc V4

On Fri, Jan 18, 2019 at 12:10:26PM +0100, Christian Zigotzky wrote: > For which commit? On top of 257002094bc5935dd63207a380d9698ab81f0775, that is the first one you identified as breaking the detection of the SATA disks.

Re: use generic DMA mapping code in powerpc V4

For which commit? -- Christian On 18 January 2019 at 09:35AM, Christoph Hellwig wrote: Hi Christian, can you check if the debug printks in this patch trigger? diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c index 355d16acee6d..e46c9b64ec0d 100644 --- a/kernel/dma/direct.c +++ b/kernel/

Re: [PATCH] media: fsl-viu: Use proper check for presence of {out, in}_be32()

Hi Hans, On Fri, Jan 18, 2019 at 11:08 AM Hans Verkuil wrote: > This patch is still in my patchwork todo list, and I wonder who will pick > this up, > especially the change to arch/powerpc/include/asm/io.h. I think the powerpc tree makes most sense. > Wouldn't it be easier to just fix this in

Re: [PATCH] media: fsl-viu: Use proper check for presence of {out,in}_be32()

Hi Geert, This patch is still in my patchwork todo list, and I wonder who will pick this up, especially the change to arch/powerpc/include/asm/io.h. Wouldn't it be easier to just fix this in fsl-viu.c only by doing this: #ifndef CONFIG_PPC #ifndef out_be32 #define out_be32(v, a) iowrite32be(a,

Re: G5 Quad hangs early on 4.20.2 / 5.0-rc2+

On Fri, Jan 18, 2019 at 1:53 AM Tobias Ulmer wrote: > > On Fri, Jan 18, 2019 at 09:32:07AM +1100, Benjamin Herrenschmidt wrote: > > On Thu, 2019-01-17 at 10:42 +0100, Tobias Ulmer wrote: > > > On Wed, Jan 16, 2019 at 12:15:14PM +1100, Benjamin Herrenschmidt wrote: > > > > On Tue, 2019-01-15 at 23:

Re: [PATCH] powerpc/powernv: Remove duplicate header

On Thu, Jan 17, 2019 at 9:40 PM Sabyasachi Gupta wrote: > > Remove linux/printk.h which is included more than once. > > Signed-off-by: Sabyasachi Gupta Acked-by: Souptick Joarder > --- > arch/powerpc/platforms/powernv/opal.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/arch/powerpc

Re: G5 Quad hangs early on 4.20.2 / 5.0-rc2+

On Fri, Jan 18, 2019 at 01:22:41PM +1100, Paul Mackerras wrote: > On Tue, Jan 15, 2019 at 11:49:45PM +0100, Tobias Ulmer wrote: > > Hi, > > > > both the latest stable 4.20.2 and 5.0 rc2+ hang early on the G5 Quad. > > Interesting, I just built v4.20 with g5_defconfig for my quad and it > booted j

Re: [PATCH 3/3] videobuf2: replace a layering violation with dma_map_resource

Hi Christoph, On 2019-01-17 18:21, Christoph Hellwig wrote: > On Mon, Jan 14, 2019 at 01:42:26PM +0100, Marek Szyprowski wrote: >> On 2019-01-11 19:17, Christoph Hellwig wrote: >>> vb2_dc_get_userptr pokes into arm direct mapping details to get the >>> resemblance of a dma address for a a physical

Re: [PATCH 19/21] treewide: add checks for the return value of memblock_alloc*()

On Wed, Jan 16, 2019 at 03:44:19PM +0200, Mike Rapoport wrote: > Add check for the return value of memblock_alloc*() functions and call > panic() in case of error. > The panic message repeats the one used by panicing memblock allocators with > adjustment of parameters to include only relevant ones.

Re: [PATCH 21/21] memblock: drop memblock_alloc_*_nopanic() variants

On Wed, Jan 16, 2019 at 03:44:21PM +0200, Mike Rapoport wrote: > As all the memblock allocation functions return NULL in case of error > rather than panic(), the duplicates with _nopanic suffix can be removed. > > Signed-off-by: Mike Rapoport > --- > arch/arc/kernel/unwind.c | 3 +-- > ar

Re: use generic DMA mapping code in powerpc V4

Hi Christian, can you check if the debug printks in this patch trigger? diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c index 355d16acee6d..e46c9b64ec0d 100644 --- a/kernel/dma/direct.c +++ b/kernel/dma/direct.c @@ -118,8 +118,11 @@ struct page *__dma_direct_alloc_pages(struct device *dev,

Re: ptrace compile failure with gcc-8.2 on 32-bit powerpc

> Yeah I noticed this just yesterday. Just FYI this has been accepted as regression in gcc, and fixed is provided for GCC 9.0: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88273