Frederic Barrat writes:
> diff --git a/arch/powerpc/include/asm/opal-api.h
> b/arch/powerpc/include/asm/opal-api.h
> index 7df005965634..2f52182a4c63 100644
> --- a/arch/powerpc/include/asm/opal-api.h
> +++ b/arch/powerpc/include/asm/opal-api.h
> @@ -193,7 +193,13 @@
> #define OPAL_IMC_COUNTERS
Zhao Qiang writes:
> QEIC was supported on PowerPC, and dependent on PPC,
> Now it is supported on other platforms, so remove PPCisms.
>
> Signed-off-by: Zhao Qiang
> ---
> arch/powerpc/platforms/83xx/km83xx.c | 1 -
> arch/powerpc/platforms/83xx/misc.c| 1 -
> arch/pow
Daniel Axtens writes:
> Currently, we do a PCI fixup to mark a default card so that Xorg
> autoconfiguration works.
>
> There is a new generic method to do this sort of vga fixup, and
> it occurs by default.
>
> Drop our old method.
>
> This method is different:
> - it will only mark a card as d
This is a followup for "[PATCH kernel v4 0/6] vfio-pci: Add support for
mmapping MSI-X table"
http://www.spinics.net/lists/kvm/msg152232.html
This time it is using "caps" in IOMMU groups. The main question is if PCI
bus flags or IOMMU domains are still better (and which one).
Here is some bac
This sets IOMMU_GROUP_CAP_ISOLATE_MSIX to a group if IRQ remapping
is enabled. For Intel, this checks disable_sourceid_checking in addition;
AMD ignores the "nosid" kernel parameters.
Here is some background on how the isolation works:
On Intel VT-d [1], there is an Interrupt Remapping Table, one
This introduces capabilities to IOMMU groups. The first defined
capability is IOMMU_GROUP_CAP_ISOLATE_MSIX which tells the IOMMU
group users that a particular IOMMU group is capable of MSIX message
filtering; this is useful when deciding whether or not to allow mapping
of MSIX table to the userspac
This sets IOMMU_GROUP_CAP_ISOLATE_MSIX to a group if MSI remapping is
enabled on an IRQ domain; this is expected to set the capability
on ARM.
Signed-off-by: Alexey Kardashevskiy
---
drivers/iommu/iommu.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/iommu/iommu.c b/drivers/
This sets IOMMU_GROUP_CAP_ISOLATE_MSIX to a group unconditionally as
there is no IOMMU-capable hardware without such a feature.
On IBM POWERPC (POWER8) [1], PCI host bridge maintains BFDN-to-PE
translation (PE stands for "partitionable endpoint"), and PE index is used
to look at Interrupt Vector T
On Mon, 7 Aug 2017 11:12:42 +0530
"Gautham R. Shenoy" wrote:
> From: "Gautham R. Shenoy"
>
> Hi,
>
> This is the fourth iteration of the patchset to enable exploitation of
> stop4 idle state on POWER9 via cpuidle.
These look good to me, thanks. I think the SPR saving is moving in the
right d
Some devices have a MSIX BAR not aligned to the system page size
greater than 4K (like 64k for ppc64) which at the moment prevents
such MMIO pages from being mapped to the userspace for the sake of
the MSIX BAR content protection. If such page happens to share
the same system page with some frequen
This fixes a couple more bits of fallout when enabling the hardlockup
detector for 64e.
It restores the required hw_nmi_get_sample_period() function for the
perf watchdog, and restores disabling of the watchdog there. It also
removes API definitions that are only defined for 64s.
Fixes: 2104180a5
Gautham R Shenoy writes:
> On Tue, Aug 01, 2017 at 08:56:18PM +1000, Michael Ellerman wrote:
>> "Gautham R. Shenoy" writes:
>> >
>> > Subject: [v3 PATCH 1/2] powernv/powerpc:Save/Restore additional SPRs for
>> > stop4 cpuidle
>>
>> I know it's not a big deal, but can we agree on the subject for
Nicholas Piggin writes:
> On Fri, 04 Aug 2017 21:54:57 +0200
> Andreas Schwab wrote:
>
>> No, this is really a 4.13-rc1 regression.
>>
>> Andreas.
>>
>
> SLB miss with MSR[RI]=0 on
>
> lbz r0,THREAD+THREAD_LOAD_FP(r7)
>
> Caused by bc4f65e4cf9d6cc43e0e9ba0b8648cf9201cd55f
Ah of course. No
On Mon, 07 Aug 2017 19:56:28 +1000
Michael Ellerman wrote:
> Nicholas Piggin writes:
>
> > On Fri, 04 Aug 2017 21:54:57 +0200
> > Andreas Schwab wrote:
> >
> >> No, this is really a 4.13-rc1 regression.
> >>
> >> Andreas.
> >>
> >
> > SLB miss with MSR[RI]=0 on
> >
> > lbz r0,THREAD+
Michael Ellerman writes:
> Matt Brown writes:
>> On Sat, Aug 5, 2017 at 3:06 AM, Tyrel Datwyler
>> wrote:
>>> On 08/03/2017 06:12 PM, Matt Brown wrote:
@@ -135,8 +152,9 @@ static __init int rng_create(struct device_node *dn)
@@ -150,6 +168,21 @@ static __init int rng_init(void)
On Aug 07 2017, Michael Ellerman wrote:
> Ah of course. Not sure why I haven't seen it in any of my testing :/
It took me a whole gcc bootstrap to trigger it.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now fo
On Thu, 2017-01-12 at 09:09:06 UTC, Rui Teng wrote:
> The offset of hugepage block will not be 16G, if the expected
> page is more than one. Calculate the totol size instead of the
> hardcode value.
>
> Signed-off-by: Rui Teng
> Tested-by: Anshuman Khandual
Applied to powerpc next, thanks.
htt
On Wed, 2017-07-19 at 04:49:04 UTC, Benjamin Herrenschmidt wrote:
> The PWC flush only needs a single set call, just like the
> full (RIC=2) flush.
>
> This will allow us to get rid of the dedicated _tlbiel_pwc()
>
> Signed-off-by: Benjamin Herrenschmidt
> Reviewed-by: Aneesh Kumar K.V
Series
On Wed, 2017-07-19 at 04:49:23 UTC, Benjamin Herrenschmidt wrote:
> This will allow simplifying the returns from do_page_fault
>
> Signed-off-by: Benjamin Herrenschmidt
Series applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/7afad422ac61067473d5f3d20bbd54
cheers
On Thu, 2017-07-20 at 17:26:06 UTC, victora wrote:
> Replaced __this_cpu_read function call by raw_cpu_read in
> iommu_range_alloc function.
> Preemption doesn't need to be disabled since any CPU can safely
> use IOMMU pool.
>
> Signed-off-by: Victor Aoqui
Applied to powerpc next, thanks.
https
On Fri, 2017-07-21 at 10:41:37 UTC, "Gautham R. Shenoy" wrote:
> From: "Gautham R. Shenoy"
>
> The stop4 idle state on POWER9 is a deep idle state which loses
> hypervisor resources, but whose latency is low enough that it can be
> exposed via cpuidle.
>
> Until now, the deep idle states which l
On Mon, 2017-07-24 at 12:50:45 UTC, Michael Ellerman wrote:
> Although pretty much everyone using powernv is running little endian,
> we should still test we can build for big endian. So add a
> powernv_be_defconfig, which is autogenerated by flipping the endian
> symbol in powernv_defconfig.
>
>
On Mon, 2017-07-24 at 14:10:15 UTC, Michael Ellerman wrote:
> For debugging very early boot problems we have CONFIG_PPC_EARLY_DEBUG,
> which allows configuring the kernel such that it unconditionally writes
> to a particular type of console, regardless of whether that console
> exists or not. This
From: Markus Elfring
Date: Mon, 7 Aug 2017 12:37:01 +0200
Omit an extra message for a memory allocation failure in this function.
This issue was detected by using the Coccinelle software.
Link:
http://events.linuxfoundation.org/sites/events/files/slides/LCJ16-Refactor_Strings-WSang_0.pdf
Signe
Andreas Schwab writes:
> On Aug 07 2017, Michael Ellerman wrote:
>
>> Ah of course. Not sure why I haven't seen it in any of my testing :/
>
> It took me a whole gcc bootstrap to trigger it.
OK. I tried a few kernel builds, but I guess a GCC bootstrap takes a
while longer ;)
The other thing is
Nicholas Piggin writes:
> On Mon, 07 Aug 2017 19:56:28 +1000
> Michael Ellerman wrote:
>> Nicholas Piggin writes:
>> > On Fri, 04 Aug 2017 21:54:57 +0200
>> > Andreas Schwab wrote:
>> >
>> >> No, this is really a 4.13-rc1 regression.
>> >
>> > SLB miss with MSR[RI]=0 on
>> >
>> > lbz r0,T
On 07/29/2017 05:09 PM, Balbir Singh wrote:
> This is the first attempt to implement KASAN for radix
> on powerpc64. Aneesh Kumar implemented KASAN for hash 64
> in limited mode (support only for kernel linear mapping)
> (https://lwn.net/Articles/655642/)
>
> This patch does the following:
> 1. De
Hi!
> Hi! Find below my second regression report for Linux 4.13. It lists 10
> regressions I'm currently aware of (albeit in one case it's not entirely
> clear yet if it's a regression in 4.13). One regression got fixed since
> last weeks report. You can also find the report at
> http://bit.ly/lnx
On Mon, Aug 07, 2017 at 06:26:44PM +1000, Michael Ellerman wrote:
> Gautham R Shenoy writes:
> > On Tue, Aug 01, 2017 at 08:56:18PM +1000, Michael Ellerman wrote:
> >> "Gautham R. Shenoy" writes:
> >> >
> >> > Subject: [v3 PATCH 1/2] powernv/powerpc:Save/Restore additional SPRs for
> >> > stop4
On 08/07/2017 03:52 AM, SF Markus Elfring wrote:
> From: Markus Elfring
> Date: Mon, 7 Aug 2017 12:37:01 +0200
>
> Omit an extra message for a memory allocation failure in this function.
>
> This issue was detected by using the Coccinelle software.
NACK
When a user asks me for help I would cer
On Mon, 2017-08-07 at 08:10 -0700, Geoff Levand wrote:
> On 08/07/2017 03:52 AM, SF Markus Elfring wrote:
> > Omit an extra message for a memory allocation failure in this function.
> NACK
>
> When a user asks me for help I would certainly like to get
> 'Could not allocate cache tags' as apposed
>> Omit an extra message for a memory allocation failure in this function.
>>
>> This issue was detected by using the Coccinelle software.
>
> NACK
>
> When a user asks me for help I would certainly like to get
> 'Could not allocate cache tags' as apposed to nothing,
Do you find the default all
Le 07/08/2017 à 12:41, Michael Ellerman a écrit :
On Wed, 2017-07-19 at 04:49:23 UTC, Benjamin Herrenschmidt wrote:
This will allow simplifying the returns from do_page_fault
Signed-off-by: Benjamin Herrenschmidt
Series applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/7af
Brian,
> Fixes the following lockdep warning that can occur when scsi-mq is
> enabled with ipr due to ipr calling scsi_unblock_requests from irq
> context. The fix is to move the call to scsi_unblock_requests to ipr's
> existing workqueue.
Applied to 4.13/scsi-fixes. Thank you!
--
Martin K. Pe
On 08/07/2017 09:27 AM, SF Markus Elfring wrote:
>>> Omit an extra message for a memory allocation failure in this function.
>>>
>>> This issue was detected by using the Coccinelle software.
>>
>> NACK
>>
>> When a user asks me for help I would certainly like to get
>> 'Could not allocate cache ta
>> Do you find the default allocation failure report insufficient?
>
> The default is OK.
Thanks for this information.
> I didn't consider one would be triggered by the kzalloc failure.
Do you reconsider any special system settings for further
software evolution then?
Regards,
Markus
On 08/07/2017 11:34 AM, SF Markus Elfring wrote:
>> I didn't consider one would be triggered by the kzalloc failure.
>
> Do you reconsider any special system settings for further
> software evolution then?
Sorry, I don't quite understand your question.
I think your original patch is OK, and I wo
>>> I didn't consider one would be triggered by the kzalloc failure.
>>
>> Do you reconsider any special system settings for further
>> software evolution then?
>
> Sorry, I don't quite understand your question.
Do you try to configure the Linux error reporting to any special needs?
> I think y
Hi Michael,
A few very minor updates for PS3. Please apply.
-Geoff
The following changes since commit aae4e7a8bc44722fe70d58920a36916b1043195e:
Linux 4.13-rc4 (2017-08-06 18:44:49 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/geoff/ps3-linux
From: Markus Elfring
Omit an extra message for a memory allocation failure in this function.
This issue was detected by using the Coccinelle software.
Link:
http://events.linuxfoundation.org/sites/events/files/slides/LCJ16-Refactor_Strings-WSang_0.pdf
Signed-off-by: Markus Elfring
Cc: Jim Pa
Signed-off-by: Geoff Levand
---
arch/powerpc/configs/ps3_defconfig | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/powerpc/configs/ps3_defconfig
b/arch/powerpc/configs/ps3_defconfig
index ee0ec5a682fc..378382683180 100644
--- a/arch/powerpc/configs/ps3_defconfig
+++ b/arch/powerpc/conf
Cc: Markus Elfring
Cc: Jim Paris
Cc: Jens Axboe
Signed-off-by: Geoff Levand
---
drivers/block/ps3vram.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/block/ps3vram.c b/drivers/block/ps3vram.c
index ba97d037279e..6a55959cbf78 100644
--- a/drivers/block/ps3vram
On 08/07/2017 12:04 PM, SF Markus Elfring wrote:
>> I think your original patch is OK,
>
> How does this feedback fit to the initial response “Not Applicable”?
> https://patchwork.ozlabs.org/patch/798575/
I submitted your patch and a fix to ps3vram_probe() with
the other patches in my queue. Tha
Soon vmemmap_alloc_block() will no longer zero the block, so zero memory
at its call sites for everything except struct pages. Struct page memory
is zero'd by struct page initialization.
Signed-off-by: Pavel Tatashin
Reviewed-by: Steven Sistare
Reviewed-by: Daniel Jordan
Reviewed-by: Bob Picco
Changelog:
v6 - v4
- Fixed ARM64 + kasan code, as reported by Ard Biesheuvel
- Tested ARM64 code in qemu and found few more issues, that I fixed in this
iteration
- Added page roundup/rounddown to x86 and arm zeroing routines to zero the
whole allocated range, instead of only provided address r
A new variant of memblock_virt_alloc_* allocations:
memblock_virt_alloc_try_nid_raw()
- Does not zero the allocated memory
- Does not panic if request cannot be satisfied
Signed-off-by: Pavel Tatashin
Reviewed-by: Steven Sistare
Reviewed-by: Daniel Jordan
Reviewed-by: Bob Picco
---
in
To optimize the performance of struct page initialization,
vmemmap_populate() will no longer zero memory.
We must explicitly zero the memory that is allocated by vmemmap_populate()
for kasan, as this memory does not go through struct page initialization
path.
Signed-off-by: Pavel Tatashin
Review
Replace allocators in sprase-vmemmap to use the non-zeroing version. So,
we will get the performance improvement by zeroing the memory in parallel
when struct pages are zeroed.
Signed-off-by: Pavel Tatashin
Reviewed-by: Steven Sistare
Reviewed-by: Daniel Jordan
Reviewed-by: Bob Picco
---
mm/s
Without deferred struct page feature (CONFIG_DEFERRED_STRUCT_PAGE_INIT),
flags and other fields in "struct page"es are never changed prior to first
initializing struct pages by going through __init_single_page().
With deferred struct page feature enabled there is a case where we set some
fields pr
To optimize the performance of struct page initialization,
vmemmap_populate() will no longer zero memory.
We must explicitly zero the memory that is allocated by vmemmap_populate()
for kasan, as this memory does not go through struct page initialization
path.
Signed-off-by: Pavel Tatashin
Review
Remove duplicating code by using common functions
vmemmap_pud_populate and vmemmap_pgd_populate.
Signed-off-by: Pavel Tatashin
Reviewed-by: Steven Sistare
Reviewed-by: Daniel Jordan
Reviewed-by: Bob Picco
---
arch/sparc/mm/init_64.c | 23 ++-
1 file changed, 6 insertions(+
There is existing use after free bug when deferred struct pages are
enabled:
The memblock_add() allocates memory for the memory array if more than
128 entries are needed. See comment in e820__memblock_setup():
* The bootstrap memblock region count maximum is 128 entries
* (INIT_MEMBLOCK_REGI
Without deferred struct page feature (CONFIG_DEFERRED_STRUCT_PAGE_INIT),
flags and other fields in "struct page"es are never changed prior to first
initializing struct pages by going through __init_single_page().
With deferred struct page feature enabled there is a case where we set some
fields pr
Struct pages are initialized by going through __init_single_page(). Since
the existing physical memory in memblock is represented in memblock.memory
list, struct page for every page from this list goes through
__init_single_page().
The second memblock list: memblock.reserved, manages the allocated
Add an optimized mm_zero_struct_page(), so struct page's are zeroed without
calling memset(). We do eight to tent regular stores based on the size of
struct page. Compiler optimizes out the conditions of switch() statement.
Signed-off-by: Pavel Tatashin
Reviewed-by: Steven Sistare
Reviewed-by: D
When CONFIG_DEBUG_VM is enabled, this patch sets all the memory that is
returned by memblock_virt_alloc_try_nid_raw() to ones to ensure that no
places excpect zeroed memory.
Signed-off-by: Pavel Tatashin
Reviewed-by: Steven Sistare
Reviewed-by: Daniel Jordan
Reviewed-by: Bob Picco
---
mm/memb
Add struct page zeroing as a part of initialization of other fields in
__init_single_page().
Signed-off-by: Pavel Tatashin
Reviewed-by: Steven Sistare
Reviewed-by: Daniel Jordan
Reviewed-by: Bob Picco
---
include/linux/mm.h | 9 +
mm/page_alloc.c| 1 +
2 files changed, 10 insertio
In deferred_init_memmap() where all deferred struct pages are initialized
we have a check like this:
if (page->flags) {
VM_BUG_ON(page_zone(page) != zone);
goto free_range;
}
This way we are checking if the current deferred page has already been
initialized. It wor
Clients can call alloc_large_system_hash() with flag: HASH_ZERO to specify
that memory that was allocated for system hash needs to be zeroed,
otherwise the memory does not need to be zeroed, and client will initialize
it.
If memory does not need to be zero'd, call the new
memblock_virt_alloc_raw()
On Fri, Aug 04, 2017 at 05:29:10PM +0200, Boris Brezillon wrote:
> We are planning to share more code between different NAND based
> devices (SPI NAND, OneNAND and raw NANDs), but before doing that
> we need to move the existing include/linux/mtd/nand.h file into
> include/linux/mtd/rawnand.h so we
On 08/04/2017 10:29 AM, Boris Brezillon wrote:
> We are planning to share more code between different NAND based
> devices (SPI NAND, OneNAND and raw NANDs), but before doing that
> we need to move the existing include/linux/mtd/nand.h file into
> include/linux/mtd/rawnand.h so we can later creat
On Friday, August 04, 2017 8:29 AM, Boris Brezillon wrote:
> We are planning to share more code between different NAND based
> devices (SPI NAND, OneNAND and raw NANDs), but before doing that
> we need to move the existing include/linux/mtd/nand.h file into
> include/linux/mtd/rawnand.h so we can l
Hi Boris,
On 08/04/2017 04:29 PM, Boris Brezillon wrote:
[...]
drivers/mtd/nand/jz4780_nand.c | 2 +-
[...]
For JZ4780,
Acked-By: Harvey Hunt
Michael Ellerman writes:
> Daniel Axtens writes:
>
>> Currently, we do a PCI fixup to mark a default card so that Xorg
>> autoconfiguration works.
>>
>> There is a new generic method to do this sort of vga fixup, and
>> it occurs by default.
>>
>> Drop our old method.
>>
>> This method is differ
On Tue, Jul 25, 2017 at 4:44 PM, Rob Herring wrote:
> This series is the last steps to remove storing the full path for every
> DT node. Instead, we can create full path strings dynamically as needed
> with printf %pOF specifiers (commit ce4fecf1fe15). There are a number of
> remaining direct user
Now that we have a custom printf format specifier, convert users of
full_name to use %pOF instead. This is preparation to remove storing
of the full path string for each node.
Signed-off-by: Rob Herring
Cc: Timur Tabi
Cc: Nicolin Chen
Cc: Xiubo Li
Cc: Fabio Estevam
Cc: Liam Girdwood
Cc: Mark
Now that we have a custom printf format specifier, convert users of
full_name to use %pOF instead. This is preparation to remove storing
of the full path string for each node.
Signed-off-by: Rob Herring
Cc: Johannes Berg
Cc: Jaroslav Kysela
Cc: Takashi Iwai
Cc: linuxppc-dev@lists.ozlabs.org
Cc
On Mon, Aug 7, 2017 at 10:30 PM, Andrey Ryabinin
wrote:
> On 07/29/2017 05:09 PM, Balbir Singh wrote:
>> This is the first attempt to implement KASAN for radix
>> on powerpc64. Aneesh Kumar implemented KASAN for hash 64
>> in limited mode (support only for kernel linear mapping)
>> (https://lwn.ne
SF Markus Elfring writes:
I didn't consider one would be triggered by the kzalloc failure.
>>>
>>> Do you reconsider any special system settings for further
>>> software evolution then?
>>
>> Sorry, I don't quite understand your question.
>
> Do you try to configure the Linux error reportin
Christophe LEROY writes:
> Le 07/08/2017 à 12:41, Michael Ellerman a écrit :
>> On Wed, 2017-07-19 at 04:49:23 UTC, Benjamin Herrenschmidt wrote:
>>> This will allow simplifying the returns from do_page_fault
>>>
>>> Signed-off-by: Benjamin Herrenschmidt
>>
>> Series applied to powerpc next, th
Rob Herring writes:
> On Tue, Jul 25, 2017 at 4:44 PM, Rob Herring wrote:
>> This series is the last steps to remove storing the full path for every
>> DT node. Instead, we can create full path strings dynamically as needed
>> with printf %pOF specifiers (commit ce4fecf1fe15). There are a number
On Mon, Aug 07, 2017 at 06:29:18PM -0500, Rob Herring wrote:
> Now that we have a custom printf format specifier, convert users of
> full_name to use %pOF instead. This is preparation to remove storing
> of the full path string for each node.
>
> Signed-off-by: Rob Herring
> Cc: Timur Tabi
> Cc:
On Mon 8/7/2017 3:02 PM, Michael Ellerman wrote:
> -Original Message-
> From: Michael Ellerman [mailto:m...@ellerman.id.au]
> Sent: Monday, August 07, 2017 3:02 PM
> To: Qiang Zhao ; t...@linutronix.de
> Cc: o...@buserror.net; Qiang Zhao ; linuxppc-
> d...@lists.ozlabs.org; Xiaobo Xie ; l
commit d300627c6a536 ("powerpc/6xx: Handle DABR match before
calling do_page_fault") breaks non 6xx platforms.
[6.029556] Failed to execute /init (error -14)
[6.034623] Starting init: /bin/sh exists but couldn't execute it
(error -14)
[6.041489] Kernel panic - not syncing: No working i
Currently we build the 47x cputable entries even when CONFIG_PPC_47x is
disabled. That means a kernel built without CONFIG_PPC_47x will claim to
support a 47x CPU and start booting, only to break somewhere later
because it doesn't have 47x support compiled in.
So guard the 47x cputable entries wit
The entire 44x directory is omitted if CONFIG_44x is not enabled, so
within the 44x/Makefile CONFIG_44x is always y. So convert
obj-$(CONFIG_44x) to the more obvious obj-y.
Signed-off-by: Michael Ellerman
---
arch/powerpc/platforms/44x/Makefile | 4 ++--
1 file changed, 2 insertions(+), 2 deleti
We have several 44x machine check handlers defined in traps.c. It would
be preferable if they were split out with the platforms that use them.
Do that.
In the process, drop get_mc_reason() and instead just open code the
lookup of reason from regs->dsisr. This avoids a pointless layer of
abstractio
We have a lot of code in sysdev for supporting 4xx, ie. either 40x or
44x. Instead it would be cleaner if it was all in platforms/4xx.
This is slightly odd in that we don't actually define any machines in
the 4xx platform, as is usual for a platform directory. But still it
seems like a better resu
Now that we have 4xx platform directory we can move the 4xx machine
check handler in there. Again we drop get_mc_reason() and replace it
with regs->dsisr directly (which is actually SPRN_ESR).
Signed-off-by: Michael Ellerman
---
arch/powerpc/kernel/traps.c| 18 +-
get_mc_reason() no longer provides (if it ever really did) any
meaningful abstraction, so remove it.
Signed-off-by: Michael Ellerman
---
arch/powerpc/kernel/traps.c | 14 --
1 file changed, 4 insertions(+), 10 deletions(-)
diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kern
Make it clear that the fallback version of machine_check_generic() is
only used on 32-bit configs.
Signed-off-by: Michael Ellerman
---
arch/powerpc/kernel/traps.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
index a
We already have mce.c which is built for 64bit and contains other parts
of the machine check code, so move these bits in there too.
Signed-off-by: Michael Ellerman
---
arch/powerpc/kernel/mce.c | 33 +
arch/powerpc/kernel/traps.c | 33 ---
Currently we open code the reason codes for program checks. Instead use
the existing SRR1 defines.
Signed-off-by: Michael Ellerman
---
arch/powerpc/include/asm/reg.h | 1 +
arch/powerpc/kernel/traps.c| 10 +-
2 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/arch/powerp
Le 08/08/2017 à 04:16, Michael Ellerman a écrit :
Christophe LEROY writes:
Le 07/08/2017 à 12:41, Michael Ellerman a écrit :
On Wed, 2017-07-19 at 04:49:23 UTC, Benjamin Herrenschmidt wrote:
This will allow simplifying the returns from do_page_fault
Signed-off-by: Benjamin Herrenschmidt
84 matches
Mail list logo
