On Thu, 2017-06-22 at 18:43 +0200, Paolo Abeni wrote:
> On Thu, 2017-06-22 at 23:06 +1000, Michael Ellerman wrote:
> > Paolo wrote:
> > > when udp_recvmsg() is executed, on x86_64 and other archs, most skb
> > > fields are on cold cachelines.
> > > If the skb are linear and the kernel don't need to
Hi Kees,
On 22 June 2017 at 18:06, Kees Cook wrote:
> Now that explicitly executed loaders are loaded in the mmap region,
> position PIE binaries lower in the address space to avoid possible
> collisions with mmap or stack regions. For 64-bit, align to 4GB to
> allow runtimes to use the entire 32
On 6/22/2017 7:49 PM, Logan Gunthorpe wrote:
> Now that ioread64 and iowrite64 are always available we don't
> need the ugly ifdefs to change their implementation when they
> are not.
>
Thanks Logan.
Note however this is not equivalent - it changes the behaviour, since
CAAM engine on i.MX6S/SL/D/
On 22/06/17 16:48, Madalin-cristian Bucur wrote:
This means all the QMan portal_isr() are distributed round-robin to all
affine portals. Is there some way to configure the software portal for a
specific network interface, e.g. use processors 0, 1, 2, 3 for one
interface,and 4, 5, 6, 7 for anothe
On Thu, 2017-06-22 at 17:27 -0300, Breno Leitao wrote:
> Currently giveup_all() calls __giveup_fpu(), __giveup_altivec(), and
> __giveup_vsx(). But __giveup_vsx() also calls __giveup_fpu() and
> __giveup_altivec() again, in a redudant manner.
>
> Other than giving up FP and Altivec, __giveup_vsx()
Michal Suchánek writes:
> On Tue, 20 Jun 2017 10:47:47 -0300
> victora wrote:
>
>> Hi Alistair/Jeremy,
>>
>> I am working on a bug related to 1M hugepage size being registered on
>> Linux (Power 8 Baremetal - Garrison).
>>
>> I was checking dmesg and it seems that 1M page size is coming from
Frederic Barrat writes:
>> diff --git a/drivers/misc/cxl/cxllib.c b/drivers/misc/cxl/cxllib.c
>> new file mode 100644
>> index 000..4f4c5ca
>> --- /dev/null
>> +++ b/drivers/misc/cxl/cxllib.c
>> @@ -0,0 +1,246 @@
>> +/*
>> + * Copyright 2017 IBM Corp.
>> + *
>> + * This program is free softwar
On 23/06/17 07:11, Alex Williamson wrote:
> On Thu, 15 Jun 2017 15:48:42 +1000
> Alexey Kardashevskiy wrote:
>
>> Here is a patchset which Yongji was working on before
>> leaving IBM LTC. Since we still want to have this functionality
>> in the kernel (DPDK is the first user), here is a rebase
>>
Hi Michael,
On Fri, 23 Jun 2017 14:10:25 +1000 Michael Ellerman wrote:
>
> Fixed in my next today by:
>
> d4cfb11387ee ("powerpc: Convert VDSO update function to use new
> update_vsyscall interface")
>
> But you must have pulled before I pushed that, so the warning will go
> away tomorrow.
Thomas Gleixner writes:
> On Thu, 22 Jun 2017, Thiago Jung Bauermann wrote:
>> Michael Bringmann provided this information:
>> >> It's not hard to backport both this patch and commit fe5595c07400
>> >> ("stop_machine: Provide stop_machine_cpuslocked()") from branch
>> >> smp/hotplug in tip.git fo
Stephen Rothwell writes:
> Hi all,
>
> [Forgot to cc John]
>
> On Fri, 23 Jun 2017 13:58:34 +1000 Stephen Rothwell
> wrote:
>>
>> Hi all,
>>
>> After merging the tip tree, today's linux-next build (powerpc
>> ppc64_defconfig) produced this warning:
>>
>> kernel/time/timekeeping.c:519:2: warni
Hi all,
[Forgot to cc John]
On Fri, 23 Jun 2017 13:58:34 +1000 Stephen Rothwell
wrote:
>
> Hi all,
>
> After merging the tip tree, today's linux-next build (powerpc
> ppc64_defconfig) produced this warning:
>
> kernel/time/timekeeping.c:519:2: warning: #warning Please contact your
> maintain
Hi all,
After merging the tip tree, today's linux-next build (powerpc
ppc64_defconfig) produced this warning:
kernel/time/timekeeping.c:519:2: warning: #warning Please contact your
maintainers, as GENERIC_TIME_VSYSCALL_OLD compatibity will disappear soon.
[-Wcpp]
#warning Please contact your m
Yes please... Would be helpful
On 22 Jun. 2017 7:50 pm, "Stewart Smith" wrote:
> Michael Neuling writes:
> > On POWER9 the ERAT may be incorrect on wakeup from some stop states
> > that lose state. This causes random segvs and illegal instructions
> > when these stop states are enabled.
> >
>
On Fri, 2017-06-23 at 10:50 +1000, Stewart Smith wrote:
> Michael Neuling writes:
> > On POWER9 the ERAT may be incorrect on wakeup from some stop states
> > that lose state. This causes random segvs and illegal instructions
> > when these stop states are enabled.
> >
> > This patch invalidates t
Michael Neuling writes:
> On POWER9 the ERAT may be incorrect on wakeup from some stop states
> that lose state. This causes random segvs and illegal instructions
> when these stop states are enabled.
>
> This patch invalidates the ERAT on wakeup on POWER9 to prevent this
> from causing a problem.
Hi all,
On Wed, 21 Jun 2017 15:32:39 +0200 Marek Szyprowski
wrote:
>
> On 2017-06-20 15:16, Christoph Hellwig wrote:
> > On Tue, Jun 20, 2017 at 11:04:00PM +1000, Stephen Rothwell wrote:
> >> git://git.linaro.org/people/mszyprowski/linux-dma-mapping.git#dma-mapping-next
> >>
> >> Contacts: Mar
On Thu, Jun 22, 2017, at 22:57, Paolo Abeni wrote:
>
> Can you please check if the following patch fixes the issue? Only
> compiled tested here.
>
> Thanks!!!
> ---
> diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
> index 067a607..80d89fe 100644
> --- a/net/ipv4/udp.c
> +++ b/net/ipv4/udp.c
> @@ -1
On 6/22/2017 3:03 PM, Arnd Bergmann wrote:
Drivers that want a non-atomic variant should include either
include/linux/io-64-nonatomic-hi-lo.h or include/linux/io-64-nonatomic-lo-hi.h
depending on what they need. Drivers that require 64-bit I/O should
probably just depend on CONFIG_64BIT and maybe
On Thu, 2017-06-22 at 23:06 +1000, Michael Ellerman wrote:
> Paolo wrote:
> > when udp_recvmsg() is executed, on x86_64 and other archs, most skb
> > fields are on cold cachelines.
> > If the skb are linear and the kernel don't need to compute the udp
> > csum, only a handful of skb fields are requ
On 6/22/2017 2:36 PM, Alan Cox wrote:
I think that makes sense for the platforms with that problem. I'm not
sure there are many that can't do it for mmio at least. 486SX can't do it
and I guess some ARM32 but I think almost everyone else can including
most 32bit x86.
What's more of a problem is
On Thu, 2017-06-22 at 18:43 +0200, Paolo Abeni wrote:
> On Thu, 2017-06-22 at 23:06 +1000, Michael Ellerman wrote:
> > Paolo wrote:
> > > when udp_recvmsg() is executed, on x86_64 and other archs, most skb
> > > fields are on cold cachelines.
> > > If the skb are linear and the kernel don't need to
On 6/22/2017 2:14 PM, Alan Cox wrote:
If a platform doesn't support 64bit I/O operations from the CPU then you
either need to use some kind of platform/architecture specific interface
if present or accept you don't have one.
Yes, I understand that.
The thing is that every user that's currently
On 6/22/2017 2:08 PM, Alan Cox wrote:
But this does not do the same thing as an ioread64 with regards to
atomicity or side effects on the device. The same is true of the other
hacks. You either have a real 64bit single read/write from MMIO space or
you don't. You can't fake it.
Yes, I know. But
On 6/22/2017 11:29 AM, Stephen Bates wrote:
+#define iowrite64be(v,p) iowrite32(cpu_to_be64(v), (p))
Logan, thanks for taking this cleanup on. I think this should be iowrite64 not
iowrite32?
Yup, good catch. Thanks. I'll fix it in a v2 of this series.
Logan
> +#define iowrite64be(v,p) iowrite32(cpu_to_be64(v), (p))
Logan, thanks for taking this cleanup on. I think this should be iowrite64 not
iowrite32?
Stephen
This is a prep patch for adding a universal iowrite64.
The patch is to prevent compiler warnings when we add iowrite64 that
would occur because there is an unnecessary volatile in this driver.
Signed-off-by: Logan Gunthorpe
Cc: Jyri Sarha
Cc: Tomi Valkeinen
Cc: David Airlie
---
drivers/gpu/d
Now that ioread64 and iowrite64 are always available we don't
need the ugly ifdefs to change their implementation when they
are not.
Signed-off-by: Logan Gunthorpe
Cc: "Horia Geantă"
Cc: Dan Douglass
Cc: Herbert Xu
Cc: "David S. Miller"
---
drivers/crypto/caam/regs.h | 29 ---
Now that we can expect iowrite64 to always exist the hack is no longer
necessary so we just call iowrite64 directly.
Signed-off-by: Logan Gunthorpe
Cc: Jyri Sarha
Cc: Tomi Valkeinen
Cc: David Airlie
---
drivers/gpu/drm/tilcdc/tilcdc_regs.h | 6 --
1 file changed, 6 deletions(-)
diff --gi
Currently, ioread64 and iowrite64 are not impleminted in the generic
iomap implementation. The prototypes are defined if CONFIG_64BIT is set
but there is no actual implementation.
Seeing the functions are not universally available, they are unusable
for driver developers. This leads to ugly hacks
Hi,
Presently, the 64bit IO functions are not very usable in drivers because
they are not universally available in all architectures. This leads to
a bunch of hacks in the kernel to work around this. (See the last 3
patches in this series.) As part of my switchtec_ntb submission which
added anothe
Alpha implements its own io operation and doesn't use the
common library. Thus to make ioread64 and iowrite64 globally
available we need to add implementations for alpha.
For this, we simply use calls that chain two 32-bit operations.
(mostly because I don't really understand the alpha architectur
Now that ioread64 and iowrite64 are available generically we can
remove the hack at the top of ntb_hw_intel.c that patches them in
when they are not available.
Signed-off-by: Logan Gunthorpe
Cc: Jon Mason
Cc: Dave Jiang
Cc: Allen Hubbe
---
drivers/ntb/hw/intel/ntb_hw_intel.c | 30
Currently, ioread64 and iowrite64 are only available io CONFIG_64BIT=y
and CONFIG_GENERIC_IOMAP=n. Thus, seeing the functions are not
universally available, it makes them unusable for driver developers.
This leads to ugly hacks such as those at the top of
drivers/ntb/hw/intel/ntb_hw_intel.c
This
On Thu, 2017-06-22 at 23:06 +1000, Michael Ellerman wrote:
> Paolo wrote:
> > when udp_recvmsg() is executed, on x86_64 and other archs, most skb
> > fields are on cold cachelines.
> > If the skb are linear and the kernel don't need to compute the udp
> > csum, only a handful of skb fields are requ
On Thu, 22 Jun 2017, Thiago Jung Bauermann wrote:
> Michael Bringmann provided this information:
> >> It's not hard to backport both this patch and commit fe5595c07400
> >> ("stop_machine: Provide stop_machine_cpuslocked()") from branch
> >> smp/hotplug in tip.git for stable.
> >
> > Yeah but it's
On Sat, Jun 17, 2017 at 08:54:44AM +1000, Benjamin Herrenschmidt wrote:
> On Fri, 2017-06-16 at 12:15 -0700, Ram Pai wrote:
> > gp_regs size is not changed, nor is the layout. A unused field in
> > the gp_regs is used to fill in the AMR contents. Old binaries will not
> > be knowing about this unus
On 06/22/2017 09:48 AM, Logan Gunthorpe wrote:
Alpha implements its own io operation and doesn't use the
common library. Thus to make ioread64 and iowrite64 globally
available we need to add implementations for alpha.
For this, we simply use calls that chain two 32-bit operations.
(mostly becaus
On Thu, 15 Jun 2017 15:48:42 +1000
Alexey Kardashevskiy wrote:
> Here is a patchset which Yongji was working on before
> leaving IBM LTC. Since we still want to have this functionality
> in the kernel (DPDK is the first user), here is a rebase
> on the current upstream.
>
>
> Current vfio-pci i
On Thu, Jun 22, 2017 at 10:09 PM, Logan Gunthorpe wrote:
> On 6/22/2017 2:08 PM, Alan Cox wrote:
>>
>> But this does not do the same thing as an ioread64 with regards to
>> atomicity or side effects on the device. The same is true of the other
>> hacks. You either have a real 64bit single read/wri
On Thu, 22 Jun 2017 10:48:14 -0600
Logan Gunthorpe wrote:
> Alpha implements its own io operation and doesn't use the
> common library. Thus to make ioread64 and iowrite64 globally
> available we need to add implementations for alpha.
>
> For this, we simply use calls that chain two 32-bit opera
On Thu, 22 Jun 2017 14:24:58 -0600
Logan Gunthorpe wrote:
> On 6/22/2017 2:14 PM, Alan Cox wrote:
> > If a platform doesn't support 64bit I/O operations from the CPU then you
> > either need to use some kind of platform/architecture specific interface
> > if present or accept you don't have one.
Currently giveup_all() calls __giveup_fpu(), __giveup_altivec(), and
__giveup_vsx(). But __giveup_vsx() also calls __giveup_fpu() and
__giveup_altivec() again, in a redudant manner.
Other than giving up FP and Altivec, __giveup_vsx() also disables
MSR_VSX on MSR, but this is already done by __give
On Thu, 22 Jun 2017 10:48:13 -0600
Logan Gunthorpe wrote:
> Currently, ioread64 and iowrite64 are only available io CONFIG_64BIT=y
> and CONFIG_GENERIC_IOMAP=n. Thus, seeing the functions are not
> universally available, it makes them unusable for driver developers.
> This leads to ugly hacks suc
> On Jun 21, 2017, at 9:15 PM, Uma Krishnan wrote:
>
> The cxlflash driver currently lacks host management interface. Future
> devices supported by cxlflash will provide a variety of host-wide
> management functions. Examples include LUN provisioning, hardware debug
> support, and firmware downlo
> On Jun 21, 2017, at 9:15 PM, Uma Krishnan wrote:
>
> To date, CXL flash devices do not support a single command abort operation.
> Instead, the SISLite specification provides a context reset operation to
> cleanup all pending commands for a given context.
>
> When a context reset is successful
> On Jun 21, 2017, at 9:14 PM, Uma Krishnan wrote:
>
> When the AFU is reset in an error path, pending scsi commands can be
> silently dropped without completion or a formal abort. This puts the onus
> on the cxlflash driver to notify mid-layer and indicating that the command
> can be retried.
>
> On Jun 21, 2017, at 9:14 PM, Uma Krishnan wrote:
>
> Currently, there is no book keeping of the pending scsi commands in the
> cxlflash driver. This lack of tracking in-flight requests is too
> restrictive and requires a heavy-hammer reset each time an adapter error is
> encountered. Additional
> On Jun 21, 2017, at 9:14 PM, Uma Krishnan wrote:
>
> AFU sync operations are not currently evaluated for failure. This is
> acceptable for paths where there is not a dependency on the AFU being
> consistent with the host. Examples include link reset events and LUN
> cleanup operations. On paths
> On Jun 21, 2017, at 9:14 PM, Uma Krishnan wrote:
>
> A context reset failure indicates the AFU is in a bad state. At present,
> when such a situation occurs, no further action is taken. This leaves the
> adapter in an unusable state with no recoverable actions.
>
> To avoid this situation, con
> On Jun 21, 2017, at 9:14 PM, Uma Krishnan wrote:
>
> Per the SISLite specification, context_reset() writes 0x1 to the LSB of the
> reset register. When the AFU processes this reset request, it is expected
> to clear the bit after reset is complete. The current implementation simply
> checks tha
> On Jun 21, 2017, at 9:13 PM, Uma Krishnan wrote:
>
> The cxlflash_afu_sync() routine returns a negative one to indicate any kind
> of failure. This makes it impossible to establish why the error occurred.
>
> Update the return codes to clearly indicate the failure cause to the
> caller.
>
> S
> On Jun 21, 2017, at 9:13 PM, Uma Krishnan wrote:
>
> Currently there are separate spin locks for the two supported I/O queueing
> models. This makes it difficult to serialize with paths outside the enqueue
> path.
>
> As a design simplification and to support serialization with enqueue
> opera
Michael Ellerman writes:
> Thiago Jung Bauermann writes:
>
>> Michael Ellerman writes:
>>> Thiago Jung Bauermann writes:
>>>
Calling arch_update_cpu_topology from a CPU hotplug state machine callback
hits a deadlock because the function tries to get a read lock on
cpu_hotplug_l
On 2017/06/22 06:29PM, Masami Hiramatsu wrote:
> On Thu, 22 Jun 2017 00:20:27 +0530
> "Naveen N. Rao" wrote:
>
> > When we derive event names, convert some expected symbols (such as ':'
> > used to specify module:name and '.' present in some symbols) into
> > underscores so that the event name is
On Thu, Jun 22, 2017 at 12:31:35AM +0100, Chris Wilson wrote:
> Quoting Tejun Heo (2017-06-13 14:58:49)
> > Cc'ing David Airlie.
> >
> > This is from drm driver calling in idr_replace() w/ a negative id.
> > Probably a silly bug in error handling path?
>
> No, this is the validation of an invalid
On Thu, Jun 22, 2017 at 07:21:03PM +1000, Balbir Singh wrote:
> On Wed, 2017-06-21 at 18:39 -0700, Ram Pai wrote:
> > Rearrange 64K PTE bits to free up bits 3, 4, 5 and 6,
> > in the 4K backed HPTE pages. These bits continue to be used
> > for 64K backed HPTE pages in this patch, but will be
Now that explicitly executed loaders are loaded in the mmap region,
position PIE binaries lower in the address space to avoid possible
collisions with mmap or stack regions.
Signed-off-by: Kees Cook
---
arch/arm/include/asm/elf.h | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
dif
Now that explicitly executed loaders are loaded in the mmap region,
position PIE binaries lower in the address space to avoid possible
collisions with mmap or stack regions. For 64-bit, align to 4GB to
allow runtimes to use the entire 32-bit address space for 32-bit
pointers.
Signed-off-by: Kees C
Now that explicitly executed loaders are loaded in the mmap region,
position PIE binaries lower in the address space to avoid possible
collisions with mmap or stack regions. For 64-bit, align to 4GB to
allow runtimes to use the entire 32-bit address space for 32-bit
pointers.
Signed-off-by: Kees C
Now that explicitly executed loaders are loaded in the mmap region,
position PIE binaries lower in the address space to avoid possible
collisions with mmap or stack regions. For 64-bit, align to 4GB to
allow runtimes to use the entire 32-bit address space for 32-bit
pointers.
Signed-off-by: Kees C
This is a follow-up to "binfmt_elf: Use ELF_ET_DYN_BASE only for PIE"[1],
which allow ELF_ET_DYN_BASE to be reduced from high in the address space.
That patch only changed x86, and this series changes arm, arm64, powerpc,
and s390.
Since these depend on the mentioned patch (which I'm hoping akpm w
On POWER9 the ERAT may be incorrect on wakeup from some stop states
that lose state. This causes random segvs and illegal instructions
when these stop states are enabled.
This patch invalidates the ERAT on wakeup on POWER9 to prevent this
from causing a problem.
Signed-off-by: Michael Neuling
--
> -Original Message-
> From: linux-...@googlegroups.com [mailto:linux-...@googlegroups.com] On
> Behalf Of Logan Gunthorpe
> Sent: Thursday, June 22, 2017 9:48 AM
> To: linux-ker...@vger.kernel.org; linux-a...@vger.kernel.org;
> linux-...@googlegroups.com; linux-al...@vger.kernel.org; l
On 2017/06/22 06:07PM, Masami Hiramatsu wrote:
> On Thu, 22 Jun 2017 00:20:28 +0530
> "Naveen N. Rao" wrote:
>
> > KPROBES_ON_FTRACE is only available on powerpc64le. Update comment to
> > clarify this.
> >
> > Also, we should use an offset of 8 to ensure that the probe does not
> > fall on ftra
On 2017/06/22 01:48PM, Nicholas Piggin wrote:
> On Thu, 22 Jun 2017 00:08:42 +0530
> "Naveen N. Rao" wrote:
>
> > We can't take traps with relocation off, so blacklist enter_rtas() and
> > rtas_return_loc(). However, instead of blacklisting all of enter_rtas(),
> > introduce a new symbol __enter_
Le 22/06/2017 à 15:07, Christophe Lombard a écrit :
This patch exports a in-kernel 'library' API which can be called by
other drivers to help interacting with an IBM XSL on a POWER9 system.
The XSL (Translation Service Layer) is a stripped down version of the
PSL (Power Service Layer) used in
On Thu, Jun 22, 2017 at 09:15:39AM -0700, frowand.l...@gmail.com wrote:
> From: Frank Rowand
>
> The Devicetree Specification has superseded the ePAPR as the
> base specification for bindings. Update files in Documentation
> to reference the new document.
>
> First reference to ePAPR in Documen
On Thu, Jun 22, 2017 at 02:37:27PM +0530, Anshuman Khandual wrote:
> On 06/17/2017 09:22 AM, Ram Pai wrote:
> > Rearrange 64K PTE bits to free up bits 3, 4, 5 and 6
> > in the 4K backed hpte pages. These bits continue to be used
> > for 64K backed hpte pages in this patch, but will be freed
>
From: Frank Rowand
The Devicetree Specification has superseded the ePAPR as the
base specification for bindings. Update files in Documentation
to reference the new document.
First reference to ePAPR in Documentation/devicetree/bindings/arm/cci.txt
is generic, remove it.
Some files are not upda
On Tue, Jun 20, 2017 at 03:40:53PM -0700, frowand.l...@gmail.com wrote:
> From: Frank Rowand
>
> File dt-object-internal.txt does not exist. Remove a reference to it
> and fix up tags for references to other files.
>
> Reported-by: afaer...@suse.de
> Signed-off-by: Frank Rowand
> ---
> Docume
On Wed, Jun 21, 2017 at 02:57:35PM +1000, Michael Ellerman wrote:
> Hi Frank,
>
> frowand.l...@gmail.com writes:
> > From: Frank Rowand
> >
> > Remove "phandle", "linux,phandle", and "ibm,phandle" properties from
> > the internal device tree. The phandle will still be in the struct
> > device_no
On 2017/06/22 11:14PM, Nicholas Piggin wrote:
> On Thu, 22 Jun 2017 21:14:21 +1000
> Michael Ellerman wrote:
>
> > Nicholas Piggin writes:
> >
> > > On Thu, 22 Jun 2017 00:08:40 +0530
> > > "Naveen N. Rao" wrote:
> > >
> > >> It is actually safe to probe system_call() in entry_64.S, but only
On Mon, Jun 19, 2017 at 03:23:41AM -0700, Frank Rowand wrote:
> On 06/18/17 07:05, Rob Herring wrote:
> > On Tue, Jun 13, 2017 at 07:49:04PM -0700, frowand.l...@gmail.com wrote:
> >> From: Frank Rowand
> >>
> >> The Devicetree Specification has superseded the ePAPR as the
> >> base specification f
Hi Sebastian,
> -Original Message-
> From: Sebastian Huber [mailto:sebastian.hu...@embedded-brains.de]
> Sent: Thursday, June 22, 2017 3:42 PM
> To: linuxppc-dev@lists.ozlabs.org
> Cc: Madalin-cristian Bucur
> Subject: DPAA: Software Portal selection for network interface
>
> Hello,
>
>
On 2017/06/22 11:08PM, Nicholas Piggin wrote:
> On Thu, 22 Jun 2017 21:07:46 +1000
> Michael Ellerman wrote:
>
> > Nicholas Piggin writes:
> >
> > > On Thu, 22 Jun 2017 00:08:39 +0530
> > > "Naveen N. Rao" wrote:
> > >
> > >> Convert some of the symbols into private symbols and blacklist
> >
On 2017/06/22 11:06PM, Nicholas Piggin wrote:
> On Thu, 22 Jun 2017 20:59:49 +1000
> Michael Ellerman wrote:
>
> > Nicholas Piggin writes:
> >
> > > On Thu, 22 Jun 2017 00:08:37 +0530
> > > "Naveen N. Rao" wrote:
> > >
> > >> Currently, we assume that the function pointer we receive in
> > >
On Thu, 22 Jun 2017 21:14:21 +1000
Michael Ellerman wrote:
> Nicholas Piggin writes:
>
> > On Thu, 22 Jun 2017 00:08:40 +0530
> > "Naveen N. Rao" wrote:
> >
> >> It is actually safe to probe system_call() in entry_64.S, but only till
> >> we unset MSR_RI. To allow this, add a new symbol syst
On Tue, 2017-06-20 at 12:34:55 UTC, Michael Ellerman wrote:
> All the callers of slb_miss_realmode currently open code the #ifndef
> CONFIG_RELOCATABLE check and the branch via CTR in the RELOCATABLE case.
> We have a macro to do this, BRANCH_TO_COMMON(), so use it.
>
> Signed-off-by: Michael Elle
On Sun, 2017-05-21 at 13:15:42 UTC, Nicholas Piggin wrote:
> One fewer registers clobbered by this function means the SLB miss
> handler can save one fewer.
>
> Signed-off-by: Nicholas Piggin
Series applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/d59afffdf04c66c09085160706297e
Hello,
as far as I understand the software portal selection for a network
interface is done in
static int dpaa_eth_probe(struct platform_device *pdev)
{
[...]
channel = dpaa_get_channel();
if (channel < 0) {
dev_err(dev, "dpaa_get_channel() failed\n");
err = channel
On Thu, 22 Jun 2017 21:07:46 +1000
Michael Ellerman wrote:
> Nicholas Piggin writes:
>
> > On Thu, 22 Jun 2017 00:08:39 +0530
> > "Naveen N. Rao" wrote:
> >
> >> Convert some of the symbols into private symbols and blacklist
> >> system_call_common() and system_call() from kprobes. We can't
This patch exports a in-kernel 'library' API which can be called by
other drivers to help interacting with an IBM XSL on a POWER9 system.
The XSL (Translation Service Layer) is a stripped down version of the
PSL (Power Service Layer) used in some cards such as the Mellanox CX5.
Like the PSL, it im
Thiago Jung Bauermann writes:
> Michael Ellerman writes:
>> Thiago Jung Bauermann writes:
>>
>>> Calling arch_update_cpu_topology from a CPU hotplug state machine callback
>>> hits a deadlock because the function tries to get a read lock on
>>> cpu_hotplug_lock while the state machine still hol
Paolo wrote:
> when udp_recvmsg() is executed, on x86_64 and other archs, most skb
> fields are on cold cachelines.
> If the skb are linear and the kernel don't need to compute the udp
> csum, only a handful of skb fields are required by udp_recvmsg().
> Since we already use skb->dev_scratch to cac
On Thu, 22 Jun 2017 20:59:49 +1000
Michael Ellerman wrote:
> Nicholas Piggin writes:
>
> > On Thu, 22 Jun 2017 00:08:37 +0530
> > "Naveen N. Rao" wrote:
> >
> >> Currently, we assume that the function pointer we receive in
> >> ppc_function_entry() points to a function descriptor. However, t
On Mon, Jun 19, 2017 at 04:40:04PM +0200, Thomas Breitung wrote:
> The bits of BWC, DAHTS and SAHTS in the DMA mode register must be cleared
> before a new value can be or-ed in.
Applied, thanks
--
~Vinod
Salut Christophe,
Since there's a respin, 2 details below.
diff --git a/drivers/misc/cxl/cxllib.c b/drivers/misc/cxl/cxllib.c
new file mode 100644
index 000..4f4c5ca
--- /dev/null
+++ b/drivers/misc/cxl/cxllib.c
@@ -0,0 +1,246 @@
+/*
+ * Copyright 2017 IBM Corp.
+ *
+ * This program is fre
On Wed, 21 Jun 2017, Thiago Jung Bauermann wrote:
> Michael Ellerman writes:
> >> Notes:
> >> This patch applies on tip/smp/hotplug, it should probably be carried
> >> there.
> >
> > stop_machine_cpuslocked() doesn't exist in mainline so I think it has to
> > be carried there right?
>
> Yes.
On Thu, 2017-06-22 at 11:29 +0200, Cédric Le Goater wrote:
> This is the framework for using XIVE in a PowerVM guest. The support
> is very similar to the native one in a much simpler form.
Looks really good. Minor nits & comments...
> Instead of OPAL calls, a set of Hypervisors call are used to
Le 22/06/2017 à 13:20, Michael Ellerman a écrit :
Christophe Lombard writes:
This patch exports a in-kernel 'library' API which can be called by
other drivers to help interacting with an IBM XSL on a POWER9 system.
The XSL (Translation Service Layer) is a stripped down version of the
PSL (Pow
Christophe Lombard writes:
> This patch exports a in-kernel 'library' API which can be called by
> other drivers to help interacting with an IBM XSL on a POWER9 system.
>
> The XSL (Translation Service Layer) is a stripped down version of the
> PSL (Power Service Layer) used in some cards such as
Benjamin Herrenschmidt writes:
> On Thu, 2017-06-22 at 13:59 +1000, Michael Ellerman wrote:
>> It's unsupported in Linux because it doesn't match the page table
>> geometry.
>>
>> We merged a patch from Aneesh to filter it out in 4.12-rc1:
>>
>> a525108cf1cc ("powerpc/mm/hugetlb: Filter out h
Nicholas Piggin writes:
> On Thu, 22 Jun 2017 00:08:40 +0530
> "Naveen N. Rao" wrote:
>
>> It is actually safe to probe system_call() in entry_64.S, but only till
>> we unset MSR_RI. To allow this, add a new symbol system_call_exit()
>> after the mtmsrd and blacklist that. Though the mtmsrd inst
Nicholas Piggin writes:
> On Thu, 22 Jun 2017 00:08:41 +0530
> "Naveen N. Rao" wrote:
>
>> Blacklist all functions involved while handling a trap. We:
>> - convert some of the symbols into private symbols,
>> - remove the duplicate 'restore' symbol, and
>> - blacklist most functions involved whi
Nicholas Piggin writes:
> On Thu, 22 Jun 2017 00:08:39 +0530
> "Naveen N. Rao" wrote:
>
>> Convert some of the symbols into private symbols and blacklist
>> system_call_common() and system_call() from kprobes. We can't take a
>> trap at parts of these functions as either MSR_RI is unset or the k
On Tue, 20 Jun 2017 10:47:47 -0300
victora wrote:
> Hi Alistair/Jeremy,
>
> I am working on a bug related to 1M hugepage size being registered on
> Linux (Power 8 Baremetal - Garrison).
>
> I was checking dmesg and it seems that 1M page size is coming from
> firmware to Linux.
>
> [0.000
Nicholas Piggin writes:
> On Thu, 22 Jun 2017 00:08:37 +0530
> "Naveen N. Rao" wrote:
>
>> Currently, we assume that the function pointer we receive in
>> ppc_function_entry() points to a function descriptor. However, this is
>> not always the case. In particular, assembly symbols without the ri
Thanks for testing this configuration Abdul.
Abdul Haleem writes:
> Hi Michael,
>
> linux-next booted with warnings on a Power LPAR with CMO feature
> enabled.
>
> Test : boot with CMO enabled
> Kernel: 4.12.0-rc5-next-20170619
> gcc : 4.8.5
> Machine : Power 8 Power VM LPAR (Big Endian)
>
> Ste
Hi,
next-20170621 fails to build on PowerPC bare-metal with gcc 4.8.5
Test : build
Machine : Power 8 bare-metal (BMC)
kernel : 4.12.0-rc6
gcc : 4.8.5
config : Hab-NV-config
$ make -S -j
In file included from drivers/net/ethernet/qlogic/qede/qede.h:43:0,
from drivers/net/ether
1 - 100 of 115 matches
Mail list logo
