On 04/09/2018 11:51 PM, Michael Ellerman wrote:
Thanks for picking this one up.
I hate to be a pain ... but before we merge this and proliferate these
names, I'd like to change the names of some of these early asm
functions. They're terribly named due to historical reasons.
Indeed :) No worrie
e from the
variable start_here_common to the function .init.text:start_kernel()
The function start_here_common() references
the function __init start_kernel().
This is often because start_here_common lacks a __init
annotation or the annotation of start_kernel is wrong.
Signed-off-by: Maur
ensure safe settings are in place in case the hypercall fail.
Fixes: f636c14790ea ("powerpc/pseries: Set or clear security feature flags")
Signed-off-by: Mauricio Faria de Oliveira
---
arch/powerpc/platforms/pseries/setup.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/ar
This moves the definition of the default security feature flags
(i.e., enabled by default) closer to the security feature flags.
This can be used to restore current flags to the default flags.
Signed-off-by: Mauricio Faria de Oliveira
---
arch/powerpc/include/asm/security_features.h | 8
Hi Michael,
On 03/27/2018 09:01 AM, Michael Ellerman wrote:
+ if (!(result->character & H_CPU_BEHAV_FAVOUR_SECURITY))
+ security_ftr_clear(SEC_FTR_FAVOUR_SECURITY);
+
+ if (!(result->character & H_CPU_BEHAV_L1D_FLUSH_PR))
+ security_ftr_clear(SEC_FTR_L1D_F
ies/spectre_v1
Vulnerable
Fixes: f636c14790ea ("powerpc/pseries: Set or clear security feature flags")
Signed-off-by: Mauricio Faria de Oliveira
---
arch/powerpc/platforms/pseries/setup.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/platforms/pse
Michael,
On 03/16/2018 11:18 AM, Michael Ellerman wrote:
I still think the correct, informative messages are a good way to go:)
Yeah I agree.
We probably want to do both, print what's available at boot, and print
what's actually patched when the patching happens.
Nice. Not sure you had a ch
Hi Murilo and Michal,
On 03/16/2018 05:52 AM, Michal Suchánek wrote:
Do we need to take into account if no_rfi_flush == true?
I think it makes sense you are able to override that using debugfs.
It's interface used for diagnostics and testing.
If this was in sysfs it would be a different sto
360.644291] rfi-flush: patched 8 locations (no flush)
[ 365.300547] rfi-flush: patched 8 locations (mttrig type flush)
Signed-off-by: Mauricio Faria de Oliveira
---
arch/powerpc/kernel/setup_64.c| 29 +
arch/powerpc/platforms/pseries/mobility.c | 4
From: Michael Ellerman
We might have migrated to a machine that uses a different flush type,
or doesn't need flushing at all.
Signed-off-by: Michael Ellerman
Signed-off-by: Mauricio Faria de Oliveira
---
arch/powerpc/platforms/pseries/mobility.c | 3 +++
arch/powerpc/platforms/ps
ichael Ellerman
Signed-off-by: Mauricio Faria de Oliveira
---
P.S.: Michael, you suggested only hunk 1. please feel free to discard
hunk 2 if you don't like it.
arch/powerpc/kernel/setup_64.c| 6 +++---
arch/powerpc/lib/feature-fixups.c | 9 -
2 files changed, 11 insertions(+)
From: Michael Ellerman
This ensures the fallback flush area is always allocated on pseries,
so in case a LPAR is migrated from a patched to an unpatched system,
it is possible to enable the fallback flush in the target system.
Signed-off-by: Michael Ellerman
Signed-off-by: Mauricio Faria de
ned-off-by: Michael Ellerman
Signed-off-by: Mauricio Faria de Oliveira
---
arch/powerpc/include/asm/setup.h | 2 +-
arch/powerpc/kernel/setup_64.c | 6 +-
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/setup.h b/arch/powerpc/include/asm/setup.h
ind
it really belongs.
Signed-off-by: Michael Ellerman
Signed-off-by: Mauricio Faria de Oliveira
---
arch/powerpc/kernel/setup_64.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
index c388cc3..3efc
d8443ef (March 14).
Testcase and results sent as the last email in the series.
v3: add patch 4 to tell flush types are 'available' and not 'Using'.
remove plumbing patch.
v2: add plumbing patch between platforms and setup code to
force init fallback flush.
Mauricio Faria de
On 03/13/2018 03:36 PM, Michal Suchánek wrote:
On Tue, 13 Mar 2018 15:13:11 -0300
Mauricio Faria de Oliveira wrote:
On 03/13/2018 02:59 PM, Michal Suchánek wrote:
Maybe it would make more sense to move the messages to the function
that actually patches in the instructions?
That helps, but
On 03/13/2018 02:59 PM, Michal Suchánek wrote:
Maybe it would make more sense to move the messages to the function
that actually patches in the instructions?
That helps, but if the instructions are not patched (e.g., no_rfi_flush)
then there is no information about what the system actually supp
Hi Michael,
On 03/13/2018 08:39 AM, Michael Ellerman wrote:
I agree; the 'Using fallback displacement flush' message is misleading
(is the system slower/fallback or not? Ô_o)
That message is actually just wrong.
It still prints that even if enable=false.
So we should change all those messag
Hi Michael and Michal,
Got back to this; sorry for the delay.
On 03/06/2018 09:55 AM, Michal Suchánek wrote:
Michael Ellerman wrote:
I*think* the patch below is all we need, as well as some tweaking of
patch 2, are you able to test and repost?
Enabling the fallback flush always looks a
From: Michael Ellerman
We might have migrated to a machine that uses a different flush type,
or doesn't need flushing at all.
Signed-off-by: Michael Ellerman
Signed-off-by: Mauricio Faria de Oliveira
---
arch/powerpc/platforms/pseries/mobility.c | 3 +++
arch/powerpc/platforms/ps
This ensures the fallback flush area is always allocated at boot time
on the pseries platform, so PowerVM migration to an unpatched system
can rely on the fallback flush method.
Signed-off-by: Mauricio Faria de Oliveira
---
arch/powerpc/include/asm/setup.h | 2 +-
arch/powerpc/kernel
ned-off-by: Michael Ellerman
Signed-off-by: Mauricio Faria de Oliveira
---
arch/powerpc/include/asm/setup.h | 2 +-
arch/powerpc/kernel/setup_64.c | 6 +-
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/setup.h b/arch/powerpc/include/asm/setup.h
ind
it really belongs.
Signed-off-by: Michael Ellerman
Signed-off-by: Mauricio Faria de Oliveira
---
arch/powerpc/kernel/setup_64.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
index c388cc3..3efc
lush: Using mttrig type flush
[0.00] rfi-flush: patched 8 locations
[ 23.243564] rfi-flush: Using ori type flush
[ 23.243566] rfi-flush: Using mttrig type flush
[ 23.243570] rfi-flush: patched 8 locations
Mauricio Faria de Oliveira (1):
rfi-flush: Allow pseries to forc
Balbir,
On 03/11/2018 03:23 AM, Balbir Singh wrote:
Looks reasonable, I'd recommend trying to compile with MEMORY_HOTPLUG
and MEMORY_HOTREMOVE enabled/disabled as well
Thanks for reviewing.
I should have mentioned it :) I did that (disable CONFIG_MEMORY_HOTPLUG)
and all the related functions
: Nicholas Piggin
Date: Fri Dec 23 00:14:19 AEDT 2016
Signed-off-by: Mauricio Faria de Oliveira
---
v2: fix missing close parenthesis in conditional (wrong patch file, sorry)
scripts/mod/modpost.c | 22 --
1 file changed, 20 insertions(+), 2 deletions(-)
diff --git a/s
annotation or the annotation of create_physical_mapping is wrong.
...
Signed-off-by: Mauricio Faria de Oliveira
---
arch/powerpc/mm/mem.c | 4 ++--
arch/powerpc/mm/pgtable-book3s64.c | 4 ++--
arch/powerpc/mm/pgtable-radix.c| 12 ++--
3 files changed, 10 insertions
: Nicholas Piggin
Date: Fri Dec 23 00:14:19 AEDT 2016
Signed-off-by: Mauricio Faria de Oliveira
---
scripts/mod/modpost.c | 22 --
1 file changed, 20 insertions(+), 2 deletions(-)
diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
index 9917f92..c65d5e2 100644
---
Hi Michael, Michal,
I got back from vacation. Checking this one.
On 02/20/2018 02:06 PM, Michal Suchánek wrote:
I did it the way I did because otherwise we waste memory on every
system on earth just to support a use case that we don't actually
intend for anyone to ever use - ie. migrating from
Hi Michal and Michael,
On 02/15/2018 05:13 AM, Michal Suchánek wrote:
From: Michael Ellerman
For PowerVM migration we want to be able to call setup_rfi_flush()
again after we've migrated the partition.
To support that we need to check that we're not trying to allocate the
fallback flush area a
Signed-off-by: Mauricio Faria de Oliveira
---
arch/powerpc/kernel/setup_64.c| 8
arch/powerpc/platforms/pseries/mobility.c | 4
2 files changed, 12 insertions(+)
diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
index d692f71..a05b9f4 100644
would complicate the implementation of the
fallback flush, and we don't expect anyone will ever do it.
Signed-off-by: Michael Ellerman
Signed-off-by: Mauricio Faria de Oliveira
---
arch/powerpc/platforms/pseries/mobility.c | 3 +++
arch/powerpc/platforms/pseries/pseries.h | 2 ++
arch/powerpc
't support migrating from a patched to an unpatched machine. Or
we do support it, but there will be no RFI flush enabled on the
destination.
Signed-off-by: Michael Ellerman
Signed-off-by: Mauricio Faria de Oliveira
---
arch/powerpc/include/asm/setup.h | 2 +-
arch/powerpc/kernel/se
This patchset allows for setup_rfi_flush() to be called again
after PowerVM LPM (live partition mobility) aka LPAR migration.
It's originally written by Michael Ellerman; I just rebased it
on top of powerpc/merge as of 2018-02-14 BRST (commit 3f6f556).
I tested it with a debug patch (sending shor
it really belongs.
Signed-off-by: Michael Ellerman
Signed-off-by: Mauricio Faria de Oliveira
---
arch/powerpc/kernel/setup_64.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
index c388cc3..3efc
On 02/05/2018 11:06 PM, Nicholas Piggin wrote:
Does this help?
powerpc/64s/radix: allocate guard-PID for kernel contexts at boot
Yes, the test-case passes:
# strace -e set_robust_list -f ./test
set_robust_list(0x7fff8d453910, 24) = 0
+++ exited with 0 +++
# uname -r
4
Nick, Michael,
On 02/05/2018 10:48 AM, Florian Weimer wrote:
7041 set_robust_list(0x7fff93dc3980, 24) = -1 ENOSYS (Function not
implemented)
The regression was introduced by commit 371b8044 ("powerpc/64s:
Initialize ISAv3 MMU registers before setting partition table").
The problem is Radix
On 09/26/2017 05:40 AM, Stewart Smith wrote:
The simple fix is to bump the length of the array to 32 which "should be
enough for everyone(TM)".
Tested-by: Mauricio Faria de Oliveira
# uname -r
4.14.0-rc3
# dmesg
[0.00] opal: OPAL detected !
[0.00] crashkernel: me
user manual says it's a supported size, but I thought it didn't work
(in hardware) for some reason.
--
Mauricio Faria de Oliveira
IBM Linux Technology Center
On 02/20/2017 11:41 PM, Alexey Kardashevskiy wrote:
Cc: Gavin Shan
Signed-off-by: Alexey Kardashevskiy
Tested-by: Mauricio Faria de Oliveira
P.S.: sorry, late, but for the record.
--
Mauricio Faria de Oliveira
IBM Linux Technology Center
Hi Michael,
On 09/21/2016 11:34 AM, Mauricio Faria de Oliveira wrote:
So, the intent is to have a single/common hack that upstream is OK w/,
then apply that downstream in the multiple distros. Of course, if you
are not OK w/ this patch (which is obviously fair) we'll have to try it
downs
tros. Of course, if you
are not OK w/ this patch (which is obviously fair) we'll have to try it
downstream only, and there we can diverge in the implementations.
Please let me know your thoughts on it.
Thanks!
--
Mauricio Faria de Oliveira
IBM Linux Technology Center
namic debug [1],
(with which I agree/understand nowadays) and suggested us to look for
a different approach.
[1] https://lists.ozlabs.org/pipermail/linuxppc-dev/2016-June/144196.html
--
Mauricio Faria de Oliveira
IBM Linux Technology Center
Michael / Ben,
On 09/01/2016 09:56 AM, Mauricio Faria de Oliveira wrote:
+#define IOMMU_ALLOC_QUIET_LEN 16 /* includes '\0' */
Guilherme suggested MAX_PARAM_PREFIX_LEN for this, which looks
better (a few extra bytes).
Would you mind to s/16/MAX_PARAM_PREFIX_LEN/ if you like that?
null; dmesg -c
# dd if=/dev/zero of=/dev/nvme0n1p1 bs=64k count=128k 2>/dev/null; dmesg -c
# dd if=/dev/zero of=/dev/nvme0n1p1 bs=64k count=128k 2>/dev/null; dmesg -c
# dd if=/dev/zero of=/dev/nvme0n1p1 bs=64k count=128k 2>/dev/null; dmesg -c
Signed-off-by: Mauricio Faria de Oliveir
Donnellan wrote:
Suggested-By: Gavin Shan
Signed-off-by: Mauricio Faria de Oliveira
Reviewed-by: Andrew Donnellan
Tested-by: Andrew Donnellan # cxl
Does this justify a Cc: stable?
I'd think so, since this prevents an oops & crash (w/ panic_on_oops).
Do you agree?
Thanks!
--
Mauri
ch more
interesting patch.
--
Mauricio Faria de Oliveira
IBM Linux Technology Center
is released
[ 933.955977] pcibios_free_controller_deferred: domain 33, dynamic 1
[ 933.955999] rpadlpar_io: slot PHB 33 removed
Suggested-By: Gavin Shan
Signed-off-by: Mauricio Faria de Oliveira
---
Changelog:
- v4: improve usability/design/documentation:
- rename function to pcibio
ibios_host_bridge_release()/pcibios_free_controller_deferred()
-add comments about using _either_ one or another
-pcibios_free_controller_deferred() calls pcibios_free_controller().
--
Mauricio Faria de Oliveira
IBM Linux Technology Center
all
pcibios_free_controller().
Ugh; you're right. I believe the user is expected to use either one way
or another, but now I see it's not that intuitive -- a design fault.
I'll address this w/ the other review/suggestion by Gavin; replying it.
Missing a '---' here :)
Changelog:
Ok, th
On 08/10/2016 06:45 PM, Mauricio Faria de Oliveira wrote:
Changelog:
- v3: different approach: struct pci_host_bridge.release_fn()
- v2: different approach: struct pci_controller.refcount
Oops, the v3 submission has no cover letter, so the subject changed
a bit from what was in v2. This is
On 08/10/2016 10:53 AM, Mauricio Faria de Oliveira wrote:
I'll go down that path for a PATCH v3.
That is,
'powerpc/pseries: use pci_host_bridge.release_fn() to kfree(phb)'
--
Mauricio Faria de Oliveira
IBM Linux Technology Center
ces on bus 0021:01
[ 479.547049] pci_hp_remove_devices:Removing 0021:01:00.0...
...
[ 483.536303] pci_hp_remove_devices:Removing 0021:01:00.1...
...
[ 497.072130] pci_bus 0021:01: busn_res: [bus 01-ff] is released
[ 497.072209] rpadlpar_io: slot PHB 33 removed
# kill -9 $p
that path for a PATCH v3.
--
Mauricio Faria de Oliveira
IBM Linux Technology Center
#x27;
on pseries, but the code uses 'phb = dev->bus->sysdata' (and this
was not null as pci_bus->sysdata was actually set).
--
Mauricio Faria de Oliveira
IBM Linux Technology Center
atch more thoroughly and test it shortly.
That's great; thanks!
--
Mauricio Faria de Oliveira
IBM Linux Technology Center
cking for kref_(get|put)() is
satisfied by the 'pci_rescan_remove_lock' mutex, which is normal
practice for usage of the PCI subsystem - thus already in place.
More details added in comment on pcibios_release_device().
Signed-off-by: Mauricio Faria de Oliveira
---
arch/powerpc/include/a
troller in case of errors just after
the call to pcibios_alloc_controller() (i.e., 'goto error' scenarios).
Signed-off-by: Mauricio Faria de Oliveira
---
arch/powerpc/include/asm/pci-bridge.h | 15 +++
arch/powerpc/kernel/pci-common.c | 47 -
in
order to implement those too, but am not yet sure of all the details (e.g.,
lifetime of eeh_dev, removal of pci_dn, etc) that need to be considered to
kfree() them - will likely ask Gavin & maintainers for RFC after some time.
Links:
[1] https://lists.ozlabs.org/pipermail/linuxppc-dev/2016-July/1452
ps://lists.ozlabs.org/pipermail/linuxppc-dev/2016-July/145624.html
Thanks,
--
Mauricio Faria de Oliveira
IBM Linux Technology Center
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
if they're OK with you?
Thanks!
[1] https://lists.ozlabs.org/pipermail/linuxppc-dev/2016-August/146850.html
--
Mauricio Faria de Oliveira
IBM Linux Technology Center
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlab
Add support for the DMA_ATTR_NO_WARN attribute on powerpc iommu code.
Signed-off-by: Mauricio Faria de Oliveira
---
arch/powerpc/kernel/iommu.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c
index 37d6e74
Use the DMA_ATTR_NO_WARN attribute for the dma_map_sg() call of the nvme
driver that returns BLK_MQ_RQ_QUEUE_BUSY (not for BLK_MQ_RQ_QUEUE_ERROR).
Signed-off-by: Mauricio Faria de Oliveira
Reviewed-by: Gabriel Krisman Bertazi
---
drivers/nvme/host/pci.c | 3 ++-
1 file changed, 2 insertions
tch.pl (line wrapping and typos)
Tested on next-20160801.
Mauricio Faria de Oliveira (3):
dma-mapping: introduce the DMA_ATTR_NO_WARN attribute
powerpc: implement the DMA_ATTR_NO_WARN attribute
nvme: use the DMA_ATTR_NO_WARN attribute
Documentation/DMA-attributes.txt | 17 +
Introduce the DMA_ATTR_NO_WARN attribute, and document it.
Signed-off-by: Mauricio Faria de Oliveira
---
Documentation/DMA-attributes.txt | 17 +
include/linux/dma-mapping.h | 5 +
2 files changed, 22 insertions(+)
diff --git a/Documentation/DMA-attributes.txt b
On 07/12/2016 08:07 PM, Mauricio Faria de Oliveira wrote:
Can you clarify which are the devices that should be tracked w/ krefs to
the PHB?
Last night I had forgotten about the fundamental point of krefs - track
references to pointers - and this answers the question.
I'm looking a
, can you point some interesting places
to look at? I've read much of arch/powerpc/kernel/pci-{common,hotplug}.c
and arch/powerpc/include/asm/pci-bridge.h, and some more in drivers/pci,
but things weren't as obvious to a newcomer in this area.
Thanks,
--
Mauri
Add support for the DMA_ATTR_NO_WARN attribute on powerpc iommu code.
Signed-off-by: Mauricio Faria de Oliveira
---
Changelog:
v3:
- powerpc: none
v2:
- all: address warnings from checkpatch.pl (line wrapping and typos)
arch/powerpc/kernel/iommu.c | 6 --
1 file changed, 4 insertions
Use the DMA_ATTR_NO_WARN attribute on dma_map_sg() calls of nvme driver.
Signed-off-by: Mauricio Faria de Oliveira
Reviewed-by: Gabriel Krisman Bertazi
---
Changelog:
v3:
- nvme: use DMA_ATTR_NO_WARN when ret = BLK_MQ_RQ_QUEUE_BUSY (io will be
requeued) but not when ret
Introduce the DMA_ATTR_NO_WARN attribute, and document it.
Signed-off-by: Mauricio Faria de Oliveira
---
Changelog:
v3:
- dma: none.
v2:
- all: address warnings from checkpatch.pl (line wrapping and typos)
Documentation/DMA-attributes.txt | 17 +
include/linux/dma-attrs.h
gelog:
v3:
- nvme: use DMA_ATTR_NO_WARN when ret = BLK_MQ_RQ_QUEUE_BUSY (io will be
requeued) but not when ret = BLK_MQ_RQ_QUEUE_ERROR (io will be failed).
thanks: Masayoshi Mizuma
v2:
- all: address warnings from checkpatch.pl (line wrapping and typos)
Mauricio Faria de Olive
On 07/08/2016 04:54 AM, Masayoshi Mizuma wrote:
Here, I think the error messages should not be suppressed because
the return value of nvme_map_data() is BLK_MQ_RQ_QUEUE_ERROR, so
the IO returns as -EIO.
Agree; good point. fixed in v3.
Thanks for reviewing.
--
Mauricio Faria de Oliveira
IBM
On 07/06/2016 09:41 PM, Gabriel Krisman Bertazi wrote:
checkpatch.pl complains about line wrapping. Other than that, this
looks good to me.
I'll submit a v2 w/ that and typos fixed.
Thanks for reviewing.
--
Mauricio Faria de Oliveira
IBM Linux Technology C
Add support for the DMA_ATTR_NO_WARN attribute on powerpc iommu code.
Signed-off-by: Mauricio Faria de Oliveira
---
Changelog:
v2:
- address warnings from checkpatch.pl (line wrapping and typos)
arch/powerpc/kernel/iommu.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff
Use the DMA_ATTR_NO_WARN attribute on dma_map_sg() calls of nvme driver.
Signed-off-by: Mauricio Faria de Oliveira
Reviewed-by: Gabriel Krisman Bertazi
---
Changelog:
v2:
- address warnings from checkpatch.pl (line wrapping and typos)
drivers/nvme/host/pci.c | 12 ++--
1 file
Introduce the DMA_ATTR_NO_WARN attribute, and document it.
Signed-off-by: Mauricio Faria de Oliveira
---
Changelog:
v2:
- address warnings from checkpatch.pl (line wrapping and typos)
Documentation/DMA-attributes.txt | 17 +
include/linux/dma-attrs.h| 1 +
2 files
v2:
- address warnings from checkpatch.pl (line wrapping and typos)
Mauricio Faria de Oliveira (3):
dma: introduce DMA_ATTR_NO_WARN
nvme: implement DMA_ATTR_NO_WARN
powerpc: implement DMA_ATTR_NO_WARN
Documentation/DMA-attributes.txt | 17 +
arch/powerpc/kernel/iommu.c
Add support for the DMA_ATTR_NO_WARN attribute on powerpc iommu code.
Signed-off-by: Mauricio Faria de Oliveira
---
arch/powerpc/kernel/iommu.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c
index a8e3490
Use the DMA_ATTR_NO_WARN attribute on dma_map_sg() calls of nvme driver.
Signed-off-by: Mauricio Faria de Oliveira
---
drivers/nvme/host/pci.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c
index d1a8259..c3c3348
Introduce the DMA_ATTR_NO_WARN attribute, and document it.
Signed-off-by: Mauricio Faria de Oliveira
---
Documentation/DMA-attributes.txt | 17 +
include/linux/dma-attrs.h| 1 +
2 files changed, 18 insertions(+)
diff --git a/Documentation/DMA-attributes.txt b
ystem logs
with error messages at least on powerpc: "iommu_alloc failed")
- Patch 3/3 implements support for it on powerpc arch (where this problem
was observed. It's possible to extend support for more archs
if the patchset is welcome).
Mauricio Far
ceptable solution as is, or needs change or to
be implemented in a different way?
Thanks,
--
Mauricio Faria de Oliveira
IBM Linux Technology Center
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
1 ]---
With the patch applied:
# drmgr -w 5 -d 1 -c phb -s 'PHB 33' -r
<...>
pci_bus 0001:01: busn_res: [bus 01-ff] is released
pcibios_free_controller() phb = c001dea2d400
pcibios_free_controller QUIRK! ptr = 0123456789abcdef
rpadlpar_io: slot PHB 33 removed
Ah, yup - ok, now I get it; thanks.
--
Mauricio Faria de Oliveira
IBM Linux Technology Center
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
would be to use a dma_attr for silencing mapping errors
which NVME could use provided it does handle them gracefully ...
Ah, that's new. Interesting. Thanks for suggestion!
--
Mauricio Faria de Oliveira
IBM Linux Technology Center
___
Lin
oblem that needs to be solved
differently.
Ok, I understand your points.
Thanks for the review -- helps in setting another direction.
Kind regards,
--
Mauricio Faria de Oliveira
IBM Linux Technology Center
___
Linuxppc-dev mailing list
Li
0:06.0: iommu_alloc failed, tbl c001fa67c520 vaddr
c000b5c6 npages 16
nvme :00:06.0: iommu_alloc failed, tbl c001fa67c520 vaddr
c000b4b3 npages 16
<...>
Tested on next-20160609.
Signed-off-by: Mauricio Faria de Oliveira
---
arch/powerpc/kernel/iommu.c |
odules] Error 2
Tested on next-20160601.
Changelog:
- v2: include details about the need for this patch with regards
to the architecture-neutral topology API.
Signed-off-by: Mauricio Faria de Oliveira
---
arch/powerpc/kernel/smp.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch
On 06/02/2016 08:03 AM, Michael Ellerman wrote:
Can you send me a v2 with a change log that includes all that detail.
Sure; should have done it. Thanks.
--
Mauricio Faria de Oliveira
IBM Linux Technology Center
___
Linuxppc-dev mailing list
On 06/02/2016 06:00 AM, Mauricio Faria de Oliveira wrote:
I actually use topology_core_id() from in lpfc [1]
Er, .. kinda early here :)
--
Mauricio Faria de Oliveira
IBM Linux Technology Center
___
Linuxppc-dev mailing list
Linuxppc-dev
Hi Michael,
On 06/02/2016 04:41 AM, Michael Ellerman wrote:
On Wed, 2016-06-01 at 17:16 -0300, Mauricio Faria de Oliveira wrote:
Export cpu_to_core_id(). This will be used by the lpfc driver.
Can you explain why?
Yup,
I would have thought there'd be architecture neutral APIs yo
Please ignore the 'PATCH 1/3' in the subject; this is a single patch.
--
Mauricio Faria de Oliveira
IBM Linux Technology Center
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Export cpu_to_core_id(). This will be used by the lpfc driver.
Tested on next-20160601.
Signed-off-by: Mauricio Faria de Oliveira
---
arch/powerpc/kernel/smp.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
index 55c924b..67136e7
93 matches
Mail list logo
