"Aneesh Kumar K.V" writes:
> ndctl utility requires the ndbus to have unique names. If not while
> enumerating the bus in userspace it drops bus with similar names.
> This results in us not listing devices beneath the bus.
>
> Signed-off-by: Aneesh Kumar K.V
> ---
> drivers/nvdimm/of_pmem.c |
On Tue, Aug 6, 2019 at 9:17 PM Aneesh Kumar K.V
wrote:
>
> On 8/7/19 9:43 AM, Dan Williams wrote:
> > On Tue, Aug 6, 2019 at 9:00 PM Aneesh Kumar K.V
> > wrote:
> >>
> >> ndctl utility requires the ndbus to have unique names. If not while
> >> enumerating the bus in userspace it drops bus with
On 8/7/19 9:43 AM, Dan Williams wrote:
On Tue, Aug 6, 2019 at 9:00 PM Aneesh Kumar K.V
wrote:
ndctl utility requires the ndbus to have unique names. If not while
enumerating the bus in userspace it drops bus with similar names.
This results in us not listing devices beneath the bus.
It
On Tue, Aug 6, 2019 at 9:00 PM Aneesh Kumar K.V
wrote:
>
> ndctl utility requires the ndbus to have unique names. If not while
> enumerating the bus in userspace it drops bus with similar names.
> This results in us not listing devices beneath the bus.
It does?
>
> Signed-off-by: Aneesh Kumar
ndctl utility requires the ndbus to have unique names. If not while
enumerating the bus in userspace it drops bus with similar names.
This results in us not listing devices beneath the bus.
Signed-off-by: Aneesh Kumar K.V
---
drivers/nvdimm/of_pmem.c | 2 +-
1 file changed, 1 insertion(+), 1
Convert existing messages, where appropriate, to use the eeh_edev_*
logging macros.
The only effect should be minor adjustments to the log messages, apart
from:
- A new message in pseries_eeh_probe() "Probing device" to match the
powernv case.
- The "Probing device" message in pnv_eeh_probe() is
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.
Move the EEH enabled message into it's own function so that it can be
called from multiple places.
Note
From: Oliver O'Halloran
Preparation for removing pci_dn from the powernv EEH code. The only
thing we really use pci_dn for is to get the bdfn of the device for
config space accesses, so adding that information to eeh_dev reduces
the need to carry around the pci_dn.
Signed-off-by: Oliver
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
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 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 struct eeh_dev includes the BDFN of it's PCI device, make use
of it to replace eeh_edev_info() with a set of dev_dbg()-style macros
that only need a struct edev.
With the BDFN available without the struct pci_dev, eeh_pci_name() is
now unnecessary, so remove it.
While only the "info"
Hi all,
Here is v4, with only a fix for a warning when CONFIG_IOV isn't defined.
Cover letter:
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
Also remove useless comment.
Signed-off-by: Sam Bobroff
Reviewed-by: Alexey Kardashevskiy
---
arch/powerpc/kernel/eeh.c| 2 +-
arch/powerpc/platforms/powernv/eeh-powernv.c | 14
arch/powerpc/platforms/pseries/eeh_pseries.c | 23 +++-
3 files
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
On 2019/8/6 15:59, Christophe Leroy wrote:
Le 05/08/2019 à 08:43, Jason Yan a écrit :
One may want to disable kaslr when boot, so provide a cmdline parameter
'nokaslr' to support this.
Signed-off-by: Jason Yan
Cc: Diana Craciun
Cc: Michael Ellerman
Cc: Christophe Leroy
Cc: Benjamin
On 2019/8/6 15:56, Christophe Leroy wrote:
Le 05/08/2019 à 08:43, Jason Yan a écrit :
After we have the basic support of relocate the kernel in some
appropriate place, we can start to randomize the offset now.
Entropy is derived from the banner and timer, which will change every
build and
Sourabh Jain writes:
> Add a sys interface to allow querying the memory reserved by fadump
> for saving the crash dump.
>
> Signed-off-by: Sourabh Jain
> ---
> Documentation/powerpc/firmware-assisted-dump.rst | 5 +
> arch/powerpc/kernel/fadump.c | 14 ++
>
Hello Christoph,
Thanks for your review.
Christoph Hellwig writes:
> On Tue, Aug 06, 2019 at 02:22:34AM -0300, Thiago Jung Bauermann wrote:
>> @@ -1318,7 +1319,10 @@ void iommu_init_early_pSeries(void)
>> of_reconfig_notifier_register(_reconfig_nb);
>>
From: John Hubbard
For pages that were retained via get_user_pages*(), release those pages
via the new put_user_page*() routines, instead of via put_page() or
release_pages().
This is part a tree-wide conversion, as described in commit fc1d8e7cca2d
("mm: introduce put_user_page*(), placeholder
On Wed, Aug 07, 2019 at 09:08:11AM +0900, Masami Hiramatsu wrote:
> On Tue, 6 Aug 2019 18:00:12 +0800
> Leo Yan wrote:
>
> > This small patch set is to add support for function error injection;
> > this can be used to eanble more advanced debugging feature, e.g.
> > CONFIG_BPF_KPROBE_OVERRIDE.
On Wed, 2019-08-07 at 11:13 +1000, Michael Ellerman wrote:
> Chris Packham writes:
> >
> > On Tue, 2019-08-06 at 21:32 +1000, Michael Ellerman wrote:
> > >
> > > Chris Packham writes:
> > > >
> > > > On Mon, 2019-08-05 at 14:06 +1200, Chris Packham wrote:
> > > > >
> > > > >
> > > > > Hi
Chris Packham writes:
> On Tue, 2019-08-06 at 21:32 +1000, Michael Ellerman wrote:
>> Chris Packham writes:
>> > On Mon, 2019-08-05 at 14:06 +1200, Chris Packham wrote:
>> > >
>> > > Hi All,
>> > >
>> > > I have a custom board that uses the Freescale/NXP T2080 SoC.
>> > >
>> > > The board
On Tue, 6 Aug 2019 18:00:12 +0800
Leo Yan wrote:
> This small patch set is to add support for function error injection;
> this can be used to eanble more advanced debugging feature, e.g.
> CONFIG_BPF_KPROBE_OVERRIDE.
>
> The patch 01/03 is to consolidate the function definition which can be
>
On Tue, 2019-08-06 at 21:32 +1000, Michael Ellerman wrote:
> Chris Packham writes:
> >
> > On Mon, 2019-08-05 at 14:06 +1200, Chris Packham wrote:
> > >
> > > Hi All,
> > >
> > > I have a custom board that uses the Freescale/NXP T2080 SoC.
> > >
> > > The board boots fine using v4.19.60 but
KASAN support on powerpc64 is interesting:
- We want to be able to support inline instrumentation so as to be
able to catch global and stack issues.
- We run a lot of code at boot in real mode. This includes stuff like
printk(), so it's not feasible to just disable instrumentation
In KASAN development I noticed that the powerpc-specific bitops
were not being picked up by the KASAN test suite.
Instrumentation is done via the bitops-instrumented.h header. It
requies that arch-specific versions of bitop functions are renamed
to arch_*. Do this renaming.
For
Currently bitops-instrumented.h assumes that the architecture provides
both the atomic and non-atomic versions of the bitops (e.g. both
set_bit and __set_bit). This is true on x86, but is not always true:
there is a generic bitops/non-atomic.h header that provides generic
non-atomic versions.
powerpc supports several different MMUs. In particular, book3s
machines support both a hash-table based MMU and a radix MMU.
These MMUs support different numbers of entries per directory
level: the PTES_PER_* defines evaluate to variables, not constants.
This leads to complier errors as global
Building on the work of Christophe, Aneesh and Balbir, I've ported
KASAN to 64-bit Book3S kernels running on the Radix MMU.
It builds on top Christophe's work on 32bit. It also builds on my
generic KASAN_VMALLOC series, available at:
On Tue, 6 Aug 2019 11:23:08 -0500, Thomas Falcon wrote:
> Reported ethtool link settings for the ibmveth driver are currently
> hardcoded and no longer reflect the actual capabilities of supported
> hardware. There is no interface designed for retrieving this information
> from device firmware
From: "Aneesh Kumar K.V"
[ Upstream commit da1115fdbd6e86c62185cdd2b4bf7add39f2f82b ]
Currently, nvdimm subsystem expects the device numa node for SCM device to be
an online node. It also doesn't try to bring the device numa node online. Hence
if we use a non-online numa node as device node we
https://bugzilla.kernel.org/show_bug.cgi?id=204371
--- Comment #8 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 284243
--> https://bugzilla.kernel.org/attachment.cgi?id=284243=edit
kernel .config (PowerMac G5 11,2, kernel 5.3-rc3)
--
You are receiving this mail because:
You are
https://bugzilla.kernel.org/show_bug.cgi?id=204371
--- Comment #7 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 284241
--> https://bugzilla.kernel.org/attachment.cgi?id=284241=edit
dmesg (PowerMac G5 11,2, kernel 5.3-rc3)
--
You are receiving this mail because:
You are on the
https://bugzilla.kernel.org/show_bug.cgi?id=204371
--- Comment #6 from Erhard F. (erhar...@mailbox.org) ---
On Wed, 31 Jul 2019 12:09:54 +
bugzilla-dae...@bugzilla.kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=204371
>
> --- Comment #4 from m...@ellerman.id.au ---
>
On 8/5/19 10:01 AM, Christoph Hellwig wrote:
diff --git a/include/linux/dma-noncoherent.h b/include/linux/dma-noncoherent.h
index 3813211a9aad..9ae5cee543c4 100644
--- a/include/linux/dma-noncoherent.h
+++ b/include/linux/dma-noncoherent.h
@@ -42,13 +42,8 @@ void arch_dma_free(struct device
When a vCPU is brought done, the XIVE VP is first disabled and then
the event notification queues are freed. When freeing the queues, we
check for possible escalation interrupts and free them also.
But when a XIVE VP is disabled, the underlying XIVE ENDs also are
disabled in OPAL. When an END is
On Tue, Aug 06, 2019 at 05:08:54PM +0100, Will Deacon wrote:
> On Sat, Aug 03, 2019 at 08:48:12AM +0200, Christoph Hellwig wrote:
> > On Fri, Aug 02, 2019 at 11:38:03AM +0100, Will Deacon wrote:
> > >
> > > So this boils down to a terminology mismatch. The Arm architecture
> > > doesn't have
> >
On Tue, Aug 06, 2019 at 05:45:03PM +0100, Russell King - ARM Linux admin wrote:
> On Tue, Aug 06, 2019 at 05:08:54PM +0100, Will Deacon wrote:
> > On Sat, Aug 03, 2019 at 08:48:12AM +0200, Christoph Hellwig wrote:
> > > On Fri, Aug 02, 2019 at 11:38:03AM +0100, Will Deacon wrote:
> > > >
> > > >
Hi Thomas,
On 7/15/19 11:43 AM, Thomas Gleixner wrote:
> On Thu, 11 Jul 2019, Hoan Tran OS wrote:
>
>> Remove CONFIG_NODES_SPAN_OTHER_NODES as it's enabled
>> by default with NUMA.
>
> As I told you before this does not mention that the option is now enabled
> even for x86(32bit)
Reported ethtool link settings for the ibmveth driver are currently
hardcoded and no longer reflect the actual capabilities of supported
hardware. There is no interface designed for retrieving this information
from device firmware nor is there any way to update current settings
to reflect observed
On Sat, Aug 03, 2019 at 08:48:12AM +0200, Christoph Hellwig wrote:
> On Fri, Aug 02, 2019 at 11:38:03AM +0100, Will Deacon wrote:
> >
> > So this boils down to a terminology mismatch. The Arm architecture doesn't
> > have
> > anything called "write combine", so in Linux we instead provide what
On Tue, Aug 06, 2019 at 10:14:27PM +1000, Michael Ellerman wrote:
> Christopher M Riedl writes:
> > Yep, and that's no good. Hmm, executing the barrier() in the
> > non-shared-processor
> > case probably hurts performance here?
>
> It's only a "compiler barrier", so it shouldn't generate any
This patch implements arm specific functions regs_set_return_value() and
override_function_with_return() to support function error injection.
In the exception flow, it updates pt_regs::ARM_pc with pt_regs::ARM_lr
so can override the probed function return.
Signed-off-by: Leo Yan
---
Inspired by the commit 7cd01b08d35f ("powerpc: Add support for function
error injection"), this patch supports function error injection for
Arm64.
This patch mainly support two functions: one is regs_set_return_value()
which is used to overwrite the return value; the another function is
The function override_function_with_return() is defined separately for
each architecture and every architecture's definition is almost same
with each other. E.g. x86 and powerpc both define function in its own
asm/error-injection.h header and override_function_with_return() has
the same
This small patch set is to add support for function error injection;
this can be used to eanble more advanced debugging feature, e.g.
CONFIG_BPF_KPROBE_OVERRIDE.
The patch 01/03 is to consolidate the function definition which can be
suared cross architectures, patches 02,03/03 are used for
On 8/6/19 5:25 AM, Michael Ellerman wrote:
Thomas Falcon writes:
Reported ethtool link settings for the ibmveth driver are currently
hardcoded and no longer reflect the actual capabilities of supported
hardware. There is no interface designed for retrieving this information
from device
> On August 6, 2019 at 7:14 AM Michael Ellerman wrote:
>
>
> Christopher M Riedl writes:
> >> On August 2, 2019 at 6:38 AM Michael Ellerman wrote:
> >> "Christopher M. Riedl" writes:
> >>
> >> This leaves us with a double test of is_shared_processor() doesn't it?
> >
> > Yep, and that's
Christopher M Riedl writes:
>> On August 2, 2019 at 6:38 AM Michael Ellerman wrote:
>> "Christopher M. Riedl" writes:
>> > diff --git a/arch/powerpc/include/asm/spinlock.h
>> > b/arch/powerpc/include/asm/spinlock.h
>> > index 0a8270183770..6aed8a83b180 100644
>> > ---
"Christopher M. Riedl" writes:
> Xmon should be either fully or partially disabled depending on the
> kernel lockdown state.
>
> Put xmon into read-only mode for lockdown=integrity and completely
> disable xmon when lockdown=confidentiality. Xmon checks the lockdown
> state and takes appropriate
Chris Packham writes:
> On Mon, 2019-08-05 at 14:06 +1200, Chris Packham wrote:
>> Hi All,
>>
>> I have a custom board that uses the Freescale/NXP T2080 SoC.
>>
>> The board boots fine using v4.19.60 but when I use v5.1.21 it locks
>> up
>> waiting for the other CPUs to come online (earlyprintk
On 8/6/19 8:42 AM, Sourabh Jain wrote:
> Add a sys interface to allow querying the memory reserved by fadump
> for saving the crash dump.
>
> Signed-off-by: Sourabh Jain
Looks good to me.
Reviewed-by: Mahesh Salgaonkar
Thanks,
-Mahesh.
> ---
>
Thomas Falcon writes:
> Reported ethtool link settings for the ibmveth driver are currently
> hardcoded and no longer reflect the actual capabilities of supported
> hardware. There is no interface designed for retrieving this information
> from device firmware nor is there any way to update
Le 05/08/2019 à 08:43, Jason Yan a écrit :
One may want to disable kaslr when boot, so provide a cmdline parameter
'nokaslr' to support this.
Signed-off-by: Jason Yan
Cc: Diana Craciun
Cc: Michael Ellerman
Cc: Christophe Leroy
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Nicholas
Le 05/08/2019 à 08:43, Jason Yan a écrit :
After we have the basic support of relocate the kernel in some
appropriate place, we can start to randomize the offset now.
Entropy is derived from the banner and timer, which will change every
build and boot. This not so much safe so additionally
Le 05/08/2019 à 08:43, Jason Yan a écrit :
This patch add support to boot kernel from places other than KERNELBASE.
Since CONFIG_RELOCATABLE has already supported, what we need to do is
map or copy kernel to a proper place and relocate. Freescale Book-E
parts expect lowmem to be mapped by
Add support for the LS1028a PCIe controller.
Signed-off-by: Xiaowei Bao
Signed-off-by: Hou Zhiqiang
---
v2:
- no change.
v3:
- Reuse the ls2088 driver data structurt.
drivers/pci/controller/dwc/pci-layerscape.c | 1 +
1 file changed, 1 insertion(+)
diff --git
LS1028a implements 2 PCIe 3.0 controllers.
Signed-off-by: Xiaowei Bao
Signed-off-by: Hou Zhiqiang
---
v2:
- Fix up the legacy INTx allocate failed issue.
v3:
- no change.
arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi | 52 ++
1 file changed, 52 insertions(+)
diff
Add the PCIe compatible string for LS1028A
Signed-off-by: Xiaowei Bao
Signed-off-by: Hou Zhiqiang
---
v2:
- no change.
v3:
- no change.
Documentation/devicetree/bindings/pci/layerscape-pci.txt | 1 +
1 file changed, 1 insertion(+)
diff --git
On Tue, 06 Aug 2019 07:29:49 +0200,
Christoph Hellwig wrote:
>
> On Mon, Aug 05, 2019 at 11:22:03AM +0200, Takashi Iwai wrote:
> > This won't work as expected, unfortunately. It's a bit tricky check,
> > since the driver may have its own mmap implementation via
> > substream->ops->mmap, and the
On Tue, Aug 06, 2019 at 02:22:34AM -0300, Thiago Jung Bauermann wrote:
> @@ -1318,7 +1319,10 @@ void iommu_init_early_pSeries(void)
> of_reconfig_notifier_register(_reconfig_nb);
> register_memory_notifier(_mem_nb);
>
> - set_pci_dma_ops(_iommu_ops);
> + if
From: Ryan Grimm
Enables running as a secure guest in platforms with an Ultravisor.
Signed-off-by: Ryan Grimm
Signed-off-by: Ram Pai
Signed-off-by: Thiago Jung Bauermann
---
arch/powerpc/configs/ppc64_defconfig | 1 +
arch/powerpc/configs/pseries_defconfig | 1 +
2 files changed, 2
63 matches
Mail list logo
