On Wed, Mar 20, 2019 at 3:21 PM Masahiro Yamada
wrote:
>
> Commit 60a3cdd06394 ("x86: add optimized inlining") introduced
> CONFIG_OPTIMIZE_INLINING, but it has been available only for x86.
>
> The idea is obviously arch-agnostic although we need some code fixups.
> This commit moves the config en
On Wed, Mar 20, 2019 at 5:06 PM Alexey Kardashevskiy wrote:
>
>
>
> On 20/03/2019 13:58, Sam Bobroff wrote:
> > Move the EEH enabled message into it's own function so that future
> > work can call it from multiple places.
> >
> > Signed-off-by: Sam Bobroff
> > ---
> > arch/powerpc/include/asm/ee
Commit 60a3cdd06394 ("x86: add optimized inlining") introduced
CONFIG_OPTIMIZE_INLINING, but it has been available only for x86.
The idea is obviously arch-agnostic although we need some code fixups.
This commit moves the config entry from arch/x86/Kconfig.debug to
lib/Kconfig.debug so that all ar
On 20/03/2019 13:58, Sam Bobroff wrote:
> Now that EEH support for all devices (on PowerNV and pSeries) is
> provided by the pcibios bus add device hooks, eeh_probe_devices() and
> eeh_addr_cache_build() are redundant and can be removed.
>
> Note that previously on pSeries, useless EEH sysfs fi
On Tue, Mar 19, 2019 at 10:36:19AM -0600, Alex Williamson wrote:
> On Fri, 15 Mar 2019 19:18:35 +1100
> Alexey Kardashevskiy wrote:
>
> > The NVIDIA V100 SXM2 GPUs are connected to the CPU via PCIe links and
> > (on POWER9) NVLinks. In addition to that, GPUs themselves have direct
> > peer to pee
On 20/03/2019 13:58, Sam Bobroff wrote:
> The pcibios_init() function for 64 bit PowerPC currently calls
> pci_bus_add_devices() before pcibios_resource_survey(), which seems
> incorrect because it adds devices and attempts to bind their drivers
> before allocating their resources (although no p
On 20/03/2019 13:58, Sam Bobroff wrote:
> The EEH_DEV_NO_HANDLER flag is used by the EEH system to prevent the
> use of driver callbacks in drivers that have been bound part way
> through the recovery process. This is necessary to prevent later stage
> handlers from being called when the earlier
On 20/03/2019 13:58, Sam Bobroff wrote:
> The PHB flag, PNV_PHB_FLAG_EEH, is set (on PowerNV) individually on
> each PHB once the EEH subsystem is ready. It is the only use of the
> flags member of the phb struct.
Then why to keep pnv_phb::flags?
> However there is no need to store this separ
On 20/03/2019 13:58, Sam Bobroff wrote:
> Also remove useless comment.
Reviewed-by: Alexey Kardashevskiy
>
> Signed-off-by: Sam Bobroff
> ---
> arch/powerpc/kernel/eeh.c| 2 +-
> arch/powerpc/platforms/powernv/eeh-powernv.c | 14
> arch/powerpc/platforms/p
On 20/03/2019 13:58, Sam Bobroff wrote:
> Move the EEH enabled message into it's own function so that future
> work can call it from multiple places.
>
> Signed-off-by: Sam Bobroff
> ---
> arch/powerpc/include/asm/eeh.h | 3 +++
> arch/powerpc/kernel/eeh.c | 16 +++-
> 2 fil
On 20/03/2019 13:58, Sam Bobroff wrote:
> The EEH address cache is currently initialized and populated by a
> single function: eeh_addr_cache_build(). While the initial population
> of the cache can only be done once resources are allocated,
> initialization (just setting up a spinlock) could b
On 20/03/2019 13:58, Sam Bobroff wrote:
> On PowerNV and pSeries, devices currently acquire EEH support from
> several different places: Boot-time devices from eeh_probe_devices()
> and eeh_addr_cache_build(), Virtual Function devices from the pcibios
> bus add device hooks and hot plugged devic
From: Alastair D'Silva
The 'extern' keyword adds no value here.
Signed-off-by: Alastair D'Silva
---
drivers/misc/ocxl/ocxl_internal.h | 54 +++
include/misc/ocxl.h | 36 ++---
2 files changed, 44 insertions(+), 46 deletions(-)
diff --g
From: Alastair D'Silva
Some minor cleanups for the OpenCAPI driver as a prerequisite
for an ocxl driver refactoring to allow the driver core to
be utilised by external drivers.
Changelog:
V3:
- Add missed header in 'ocxl: Remove some unused exported symbols'.
This addresses the introduced
From: Alastair D'Silva
Remove some unused exported symbols.
Signed-off-by: Alastair D'Silva
---
drivers/misc/ocxl/config.c| 2 --
drivers/misc/ocxl/ocxl_internal.h | 23 +++
include/misc/ocxl.h | 23 ---
3 files changed, 23 inserti
From: Alastair D'Silva
No need for a return value in read_pasid as it only returns 0.
Signed-off-by: Alastair D'Silva
Reviewed-by: Greg Kurz
---
drivers/misc/ocxl/config.c | 9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/misc/ocxl/config.c b/drivers/misc/oc
From: Alastair D'Silva
Use %# instead of using a literal '0x'
Signed-off-by: Alastair D'Silva
---
drivers/misc/ocxl/config.c | 6 +++---
drivers/misc/ocxl/context.c | 2 +-
drivers/misc/ocxl/trace.h | 10 +-
3 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/mi
From: Alastair D'Silva
The term 'link' is ambiguous (especially when the struct is used for a
list), so rename it for clarity.
Signed-off-by: Alastair D'Silva
Reviewed-by: Greg Kurz
---
drivers/misc/ocxl/file.c | 5 ++---
drivers/misc/ocxl/link.c | 36 ++--
2
From: Alastair D'Silva
External drivers that communicate via OpenCAPI will need to make
MMIO calls to interact with the devices.
Signed-off-by: Alastair D'Silva
Reviewed-by: Greg Kurz
---
drivers/misc/ocxl/Makefile | 2 +-
drivers/misc/ocxl/mmio.c | 234 +++
From: Alastair D'Silva
Event_fd is only used in the driver frontend, so it does not
need to exist in the backend code. Relocate it to the frontend
and provide an opaque mechanism for consumers instead.
Signed-off-by: Alastair D'Silva
---
drivers/misc/ocxl/afu_irq.c | 69 +
From: Alastair D'Silva
The use of offsets is required only in the frontend, so alter
the IRQ API to only work with IRQ IDs in the backend.
Signed-off-by: Alastair D'Silva
---
drivers/misc/ocxl/afu_irq.c | 34 +++
drivers/misc/ocxl/context.c | 7 +--
From: Alastair D'Silva
Most OpenCAPI operations require a valid context, so
exposing these functions to external drivers is necessary.
Signed-off-by: Alastair D'Silva
Reviewed-by: Greg Kurz
---
drivers/misc/ocxl/context.c | 9 +--
drivers/misc/ocxl/file.c | 2 +-
drivers/
From: Alastair D'Silva
The OCXL driver contains both frontend code for interacting with userspace,
as well as backend code for interacting with the hardware.
This patch separates the backend code from the frontend so that it can be
used by other device drivers that communicate via OpenCAPI.
Rel
From: Alastair D'Silva
This data is already available in a struct
Signed-off-by: Alastair D'Silva
---
drivers/misc/ocxl/core.c | 38 +-
1 file changed, 21 insertions(+), 17 deletions(-)
diff --git a/drivers/misc/ocxl/core.c b/drivers/misc/ocxl/core.c
index
From: Alastair D'Silva
In preparation for making core code available for external drivers,
move the core code out of pci.c and into core.c
Signed-off-by: Alastair D'Silva
---
drivers/misc/ocxl/Makefile| 1 +
drivers/misc/ocxl/core.c | 517 ++
driv
From: Alastair D'Silva
This series reworks the OpenCAPI driver to split frontend
(driver interactions) from backend (hardware interactions).
This allows external drivers to utilise the core of the
generic OpenCAPI driver to communicate with specific
OpenCAPI hardware.
Changelog:
V2:
- Reorder
Add documentation for 'MAX_PHYSMEM_BITS' variable being added to
vmcoreinfo.
'MAX_PHYSMEM_BITS' defines the maximum supported physical address
space memory.
Cc: Boris Petkov
Cc: Ingo Molnar
Cc: Thomas Gleixner
Cc: James Morse
Cc: Will Deacon
Cc: Michael Ellerman
Cc: Paul Mackerras
Cc: Benj
Right now user-space tools like 'makedumpfile' and 'crash' need to rely
on a best-guess method of determining value of 'MAX_PHYSMEM_BITS'
supported by underlying kernel.
This value is used in user-space code to calculate the bit-space
required to store a section for SPARESMEM (similar to the exist
Changes since v2:
- v2 can be seen here:
http://lists.infradead.org/pipermail/kexec/2019-March/022531.html
- Protected 'MAX_PHYSMEM_BITS' vmcoreinfo variable under CONFIG_SPARSEMEM
ifdef sections, as suggested by Kazu.
- Updated vmcoreinfo documentation to add description about
On Tue, Mar 19, 2019 at 04:47:20PM +0100, Cédric Le Goater wrote:
> On 3/19/19 5:54 AM, David Gibson wrote:
> > On Mon, Mar 18, 2019 at 03:12:10PM +0100, Cédric Le Goater wrote:
> >> On 3/18/19 4:23 AM, David Gibson wrote:
> >>> On Fri, Mar 15, 2019 at 01:05:58PM +0100, Cédric Le Goater wrote:
> >>
On PowerNV and pSeries, devices currently acquire EEH support from
several different places: Boot-time devices from eeh_probe_devices()
and eeh_addr_cache_build(), Virtual Function devices from the pcibios
bus add device hooks and hot plugged devices from pci_hp_add_devices()
(with other platforms
Now that EEH support for all devices (on PowerNV and pSeries) is
provided by the pcibios bus add device hooks, eeh_probe_devices() and
eeh_addr_cache_build() are redundant and can be removed.
Note that previously on pSeries, useless EEH sysfs files were created
for some devices that did not have E
The EEH_DEV_NO_HANDLER flag is used by the EEH system to prevent the
use of driver callbacks in drivers that have been bound part way
through the recovery process. This is necessary to prevent later stage
handlers from being called when the earlier stage handlers haven't,
which can be confusing for
Also remove useless comment.
Signed-off-by: Sam Bobroff
---
arch/powerpc/kernel/eeh.c| 2 +-
arch/powerpc/platforms/powernv/eeh-powernv.c | 14
arch/powerpc/platforms/pseries/eeh_pseries.c | 23 +++-
3 files changed, 28 insertions(+), 11 deletion
Hi all,
This patch set adds support for EEH recovery of hot plugged devices on pSeries
machines. Specifically, devices discovered by PCI rescanning using
/sys/bus/pci/rescan, which includes devices hotplugged by QEMU's device_add
command. (pSeries doesn't currently use slot power control for hotpl
The PHB flag, PNV_PHB_FLAG_EEH, is set (on PowerNV) individually on
each PHB once the EEH subsystem is ready. It is the only use of the
flags member of the phb struct.
However there is no need to store this separately on each PHB, so
convert it to a global flag. For symmetry, the flag is now also
Move the EEH enabled message into it's own function so that future
work can call it from multiple places.
Signed-off-by: Sam Bobroff
---
arch/powerpc/include/asm/eeh.h | 3 +++
arch/powerpc/kernel/eeh.c | 16 +++-
2 files changed, 14 insertions(+), 5 deletions(-)
diff --git a/
The EEH address cache is currently initialized and populated by a
single function: eeh_addr_cache_build(). While the initial population
of the cache can only be done once resources are allocated,
initialization (just setting up a spinlock) could be done much
earlier.
So move the initialization st
The pcibios_init() function for 64 bit PowerPC currently calls
pci_bus_add_devices() before pcibios_resource_survey(), which seems
incorrect because it adds devices and attempts to bind their drivers
before allocating their resources (although no problems seem to be
apparent).
So move the call to
On 20/03/2019 03:36, Alex Williamson wrote:
> On Fri, 15 Mar 2019 19:18:35 +1100
> Alexey Kardashevskiy wrote:
>
>> The NVIDIA V100 SXM2 GPUs are connected to the CPU via PCIe links and
>> (on POWER9) NVLinks. In addition to that, GPUs themselves have direct
>> peer to peer NVLinks in groups o
On Fri, 2019-03-15 at 14:56 +0100, Greg Kurz wrote:
> On Wed, 13 Mar 2019 15:15:21 +1100
> "Alastair D'Silva" wrote:
>
> > From: Alastair D'Silva
> >
> > The use of offsets is required only in the frontend, so alter
> > the IRQ API to only work with IRQ IDs in the backend.
> >
> > Signed-off-b
This is a mass convert of the config files to use the new
generic cmdline.
The command used to convert is as follows,
sed -i 's/CONFIG_CMDLINE=/CONFIG_CMDLINE_PREPEND=/g'
Cc: xe-linux-exter...@cisco.com
Cc: Daniel Walker
Signed-off-by: Daniel Walker
Change-Id: Idf7cae45ef5f8afebcb1ee7e025aaf
This code allows architectures to use a generic builtin command line.
The state of the builtin command line options across architecture is
diverse. On x86 and mips they have pretty much the same code and the
code prepends the builtin command line onto the boot loader provided
one. On powerpc there
This adds support for the generic command line implementation into the
device tree code. This allows some platforms to use the original
CONFIG_CMDLINE implementation, but powerpc platforms can used the newer
generic command line code. As platforms support the generic command line
code they can simp
This updates the powerpc code to use the CONFIG_GENERIC_CMDLINE
option.
[maksym.kok...@globallogic.com: add strlcat to prom_init_check.sh
whitelist]
Cc: Daniel Walker
Cc: Daniel Walker
Cc: xe-linux-exter...@cisco.com
Signed-off-by: Daniel Walker
Signed-off-by: Maksym Kokhan
---
arch/powerpc/K
Hi all,
new in -v2
* Updated with some changes to adding spaces from Christophe Leroy.
* Added OF support with comments from Rob on my 2015 submission which
he reviewed.
(https://lore.kernel.org/patchwork/patch/604997/)
Christophe and Rob suggested to hav
On Sun, 17 Mar 2019 11:34:31 -0700 ira.we...@intel.com wrote:
> Resending after rebasing to the latest mm tree.
>
> HFI1, qib, and mthca, use get_user_pages_fast() due to it performance
> advantages. These pages can be held for a significant time. But
> get_user_pages_fast() does not protect ag
From: Yue Haibing
Date: Tue, 19 Mar 2019 22:42:37 +0800
> From: YueHaibing
>
> Fix sparse warning:
> drivers/net/ethernet/ibm/ibmveth.c:96:21:
> warning: symbol 'ibmveth_stats' was not declared. Should it be static?
>
> Signed-off-by: YueHaibing
Applied.
On Mon, Mar 04, 2019 at 03:26:59PM +0100, Christophe Leroy wrote:
>
>
> Le 01/03/2019 à 20:44, Daniel Walker a écrit :
> > This updates the powerpc code to use the CONFIG_GENERIC_CMDLINE
> > option.
>
> Please explain more in details how each powerpc option is replaced by one of
> the generic op
On Tue, Mar 19, 2019 at 06:42:35PM +0100, Christophe Leroy wrote:
> Well, that's what I started with, but at the end my main worry has been that
> you bring a non exciting set of complicated macros and code to replace
> simple code, and you break something out of generic OF code to a new brand
> ne
Hi Daniel,
Le 19/03/2019 à 16:38, Daniel Walker a écrit :
On Tue, Mar 19, 2019 at 12:18:03PM +1100, Michael Ellerman wrote:
Hi Daniel,
Daniel Walker writes:
Here are the generic command line changes for powerpc.
These changes have been in linux-next for two cycles, with few problems
report
On 03/19, Oleg Nesterov wrote:
>
> Well, personally I see no point... Again, after the trivial simplification
> x86 does
>
> if (work & (_TIF_SYSCALL_EMU | _TIF_SYSCALL_TRACE)) {
> ret = tracehook_report_syscall_entry(regs);
> if (ret || (work & _TIF_SYSCALL_EMU))
On 03/18, Sudeep Holla wrote:
>
> On Mon, Mar 18, 2019 at 06:33:41PM +0100, Oleg Nesterov wrote:
> > On 03/18, Sudeep Holla wrote:
> > >
> > > On Mon, Mar 18, 2019 at 06:20:24PM +0100, Oleg Nesterov wrote:
> > > >
> > > > Again, to me this patch just makes the code look worse. Honestly, I
> > > >
On Fri, 15 Mar 2019 19:18:35 +1100
Alexey Kardashevskiy wrote:
> The NVIDIA V100 SXM2 GPUs are connected to the CPU via PCIe links and
> (on POWER9) NVLinks. In addition to that, GPUs themselves have direct
> peer to peer NVLinks in groups of 2 to 4 GPUs. At the moment the POWERNV
> platform puts
On 3/19/19 5:54 AM, David Gibson wrote:
> On Mon, Mar 18, 2019 at 03:12:10PM +0100, Cédric Le Goater wrote:
>> On 3/18/19 4:23 AM, David Gibson wrote:
>>> On Fri, Mar 15, 2019 at 01:05:58PM +0100, Cédric Le Goater wrote:
These controls will be used by the H_INT_SET_QUEUE_CONFIG and
H_INT_
On Tue, Mar 19, 2019 at 12:18:03PM +1100, Michael Ellerman wrote:
> Hi Daniel,
>
> Daniel Walker writes:
> > Here are the generic command line changes for powerpc.
> >
> > These changes have been in linux-next for two cycles, with few problems
> > reported.
> > It's also been used at Cisco Syst
On Tue, Mar 19, 2019 at 1:45 AM Kirill A. Shutemov wrote:
>
> On Wed, Mar 13, 2019 at 09:07:13AM -0700, Dan Williams wrote:
> > On Wed, Mar 6, 2019 at 4:46 AM Aneesh Kumar K.V
> > wrote:
> > >
> > > On 3/6/19 5:14 PM, Michal Suchánek wrote:
> > > > On Wed, 06 Mar 2019 14:47:33 +0530
> > > > "Anee
From: YueHaibing
Fix sparse warning:
drivers/rtc/rtc-opal.c:227:5:
warning: symbol 'opal_tpo_alarm_irq_enable' was not declared. Should it be
static?
Signed-off-by: YueHaibing
---
drivers/rtc/rtc-opal.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/rtc/rtc-opal
From: YueHaibing
Fix sparse warning:
drivers/net/ethernet/ibm/ibmveth.c:96:21:
warning: symbol 'ibmveth_stats' was not declared. Should it be static?
Signed-off-by: YueHaibing
---
drivers/net/ethernet/ibm/ibmveth.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/ne
Hi Qian,
On Wed, Mar 13, 2019 at 10:57:17AM -0400, Qian Cai wrote:
> @@ -1531,7 +1547,14 @@ static void kmemleak_scan(void)
>
> /* data/bss scanning */
> scan_large_block(_sdata, _edata);
> - scan_large_block(__bss_start, __bss_stop);
> +
> + if (bss_hole_start) {
> +
On 3/19/19 9:45 AM, Christophe Leroy wrote:
> Hi,
>
> Le 19/03/2019 à 08:10, Mark Cave-Ayland a écrit :
>> Hi all,
>>
>> Whilst building the latest git master on my G4 I noticed the following shift
>> overflow
>> warnings in the build log for arch/powerpc/boot/addnote.c:
>
> I guess the problem
On 3/19/19 5:21 AM, Christophe Leroy wrote:
> Is there a reason for resending ? AFAICS, both are identical and still marked
> new in patchwork:
> https://patchwork.ozlabs.org/project/linuxppc-dev/list/?submitter=76055
>
"RESEND" because of no maintainer response for more than one week.
> Inde
Is there a reason for resending ? AFAICS, both are identical and still
marked new in patchwork:
https://patchwork.ozlabs.org/project/linuxppc-dev/list/?submitter=76055
Indeed, the resend has an issue in the commit log and fails the
checkpatch (a :: in Reviewed-by::)
Christophe
Le 17/03/2019
Hi Michael,
as it seems good now, could you pick up this patch for merging?
Thanks,
Laurent
On 13/03/2019 11:25, Laurent Vivier wrote:
> resize_hpt_for_hotplug() reports a warning when it cannot
> resize the hash page table ("Unable to resize hash page
> table to target order") but in some cases
Hi,
Le 19/03/2019 à 08:10, Mark Cave-Ayland a écrit :
Hi all,
Whilst building the latest git master on my G4 I noticed the following shift
overflow
warnings in the build log for arch/powerpc/boot/addnote.c:
I guess the problem must have been there for some time. I get the exact
same on 4.14
On Wed, Mar 13, 2019 at 09:07:13AM -0700, Dan Williams wrote:
> On Wed, Mar 6, 2019 at 4:46 AM Aneesh Kumar K.V
> wrote:
> >
> > On 3/6/19 5:14 PM, Michal Suchánek wrote:
> > > On Wed, 06 Mar 2019 14:47:33 +0530
> > > "Aneesh Kumar K.V" wrote:
> > >
> > >> Dan Williams writes:
> > >>
> > >>> On
Hi all,
Whilst building the latest git master on my G4 I noticed the following shift
overflow
warnings in the build log for arch/powerpc/boot/addnote.c:
arch/powerpc/boot/addnote.c: In function ‘main’:
arch/powerpc/boot/addnote.c:75:47: warning: right shift count >= width of type
[-Wshift-count
67 matches
Mail list logo
