VMX module")
Cc: sta...@vger.kernel.org # v4.1+
Reported-by: Eric Biggers
Signed-off-by: Daniel Axtens
Acked-by: Ard Biesheuvel
Tested-by: Michael Ellerman
Signed-off-by: Herbert Xu
(backported from commit 357d065a44cdd77ed5ff35155a989f2a763e96ef)
Signed-off-by: Daniel Axtens
---
drivers
Christophe Leroy writes:
> Daniel Axtens a écrit :
>
> Hi
>
> I think you have to mention the upstream commit Id when submitting a
> patch to stable, see
> https://elixir.bootlin.com/linux/v5.2-rc1/source/Documentation/process/stable-kernel-rules.rst
Argh, right, sorr
ach and perform the fallback
operations directly if required.
Fixes: cc333cd68dfa ("crypto: vmx - Adding GHASH routines for VMX module")
Cc: sta...@vger.kernel.org # v4.1+
Reported-by: Eric Biggers
Signed-off-by: Daniel Axtens
Acked-by: Ard Biesheuvel
Tested-by: Michael Ellerman
y structure and data layout being used.
So instead steal the arm64 approach and perform the fallback
operations directly if required.
Fixes: cc333cd68dfa ("crypto: vmx - Adding GHASH routines for VMX module")
Cc: sta...@vger.kernel.org # v4.1+
Reported-by: Eric Biggers
Signed-off-by: Dan
c: sta...@vger.kernel.org # v4.1+
Reported-by: Eric Biggers
Signed-off-by: Daniel Axtens
Acked-by: Ard Biesheuvel
Tested-by: Michael Ellerman
Signed-off-by: Herbert Xu
Signed-off-by: Daniel Axtens
---
v2: do stable backport form correctly.
---
drivers/crypto/vmx/ghash.c | 218 +++-
Hi Nayna,
>> As PowerNV moves towards secure boot, we need a place to put secure
>> variables. One option that has been canvassed is to make our secure
>> variables look like EFI variables. This is an early sketch of another
>> approach where we create a generic firmware variable file system,
>> f
955]
==
Document that a 16-byte buffer is requred, and provide it in udbg.
CC: Dmitry Vyukov
Signed-off-by: Daniel Axtens
---
v2: avoid memcpy, push responsibility to caller.
Solution suggested by mpe.
---
arch/powerpc/platforms/pseries/hvconsole.c | 2 +-
drivers/tty/
Hi Greg,
>> >> As PowerNV moves towards secure boot, we need a place to put secure
>> >> variables. One option that has been canvassed is to make our secure
>> >> variables look like EFI variables. This is an early sketch of another
>> >> approach where we create a generic firmware variable file s
Christophe Leroy writes:
> On 06/03/2019 11:50 PM, Daniel Axtens wrote:
>> Christophe Leroy writes:
>>
>>> Hi,
>>>
>>> Ok, can you share your .config ?
>>
>> Sure! This one is with kasan off as the last build I did was testing to
>&
The CTR code comes from OpenSSL, where it does a 32-bit counter.
The kernel has a 128-bit counter. This difference has lead to
issues.
Document it.
Signed-off-by: Daniel Axtens
---
drivers/crypto/vmx/aesp8-ppc.pl | 22 --
1 file changed, 20 insertions(+), 2 deletions
Nayna Jain writes:
> From: Claudio Carvalho
>
> The X.509 certificates trusted by the platform and other information
> required to secure boot the OS kernel are wrapped in secure variables,
> which are controlled by OPAL.
>
> This patch adds support to read OPAL secure variables through
> OPAL_S
Hi Nayna,
>>> Since OPAL can support different types of backend which can vary in the
>>> variable interpretation, a new OPAL API call named OPAL_SECVAR_BACKEND, is
>>> added to retrieve the supported backend version. This helps the consumer
>>> to know how to interpret the variable.
>>>
>> (First
Pawel Dembicki writes:
> Enable kernel XZ compression option on PPC_85xx. Tested with
> simpleImage on TP-Link TL-WDR4900 (Freescale P1014 processor).
>
> Suggested-by: Christian Lamparter
> Signed-off-by: Pawel Dembicki
> ---
> arch/powerpc/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1
Radu Rendec writes:
> Hi Everyone,
>
> I'm following up on the ptrace() problem that I reported a few days ago.
> I believe my version of the code handles all cases correctly. While the
> problem essentially boils down to dividing the fpidx by 2 on PPC32, it
> becomes tricky when the same code mu
the patch itself makes sense to me and I can
follow how it would fix a problem.
Reviewed-by: Daniel Axtens
Kind regards,
Daniel
Hi Greg,
> Ok, this is like the 3rd or 4th different platform-specific proposal for
> this type of functionality. I think we need to give up on
> platform-specific user/kernel apis on this (random sysfs/securityfs
> files scattered around the tree), and come up with a standard place for
> all of
ed in
sysfs_{create,remove}_group. So I agree that they can be constified.
They also pass all the automated tests:
https://patchwork.ozlabs.org/project/linuxppc-dev/patch/20220210202805.7750-4-rikard.falkeb...@gmail.com/
Reviewed-by: Daniel Axtens
Kind regards,
Daniel
>
> Signed-off-by
Hi Tobin,
> Recently the kernel version on the github
> repository did not match up with the master branch of
>
> https://kernel.googlesource.com/pub/scm/linux/kernel/git/powerpc/linux
>
> Specifically, github was hosting v4.10-rc5 while master had
> v4.10-rc8. All the while Linus' mainline was at
Hi Tobin,
> .llong is an undocumented PPC specific directive. The generic
> equivalent is .quad, but even better (because it's self describing) is
> .8byte.
>
> Convert directives .llong -> .8byte
>
> Signed-off-by: Tobin C. Harding
> ---
>
> Fixes: issue #33 (github)
Thanks for tackling these!
ould it be static?
-/scratch/dja/linux/arch/powerpc/kernel/swsusp.c:31:6: warning: symbol
'restore_processor_state' was not declared. Should it be static?
As such, this patch is:
Reviewed-by: Daniel Axtens
Thanks for fixing this!
Regards,
Daniel
[1] https://github.com/daxtens/smart-s
github.com/antonblanchard/crc32-vpmsum)
That implementation is available under GPLv2+, so we're OK
from a licensing point of view:
https://github.com/antonblanchard/crc32-vpmsum/blob/master/LICENSE.TXT
As CRC32c requires REFLECT, add that #define.
Cc: Anton Blanchard
Signed-off-by: Daniel
T10DIF is a CRC16 used heavily in NVMe.
It turns out we can accelerate it with a CRC32 library and a few
little tricks.
Provide the accelerator based the refactored CRC32 code.
Cc: Anton Blanchard
Thanks-to: Hong Bo Peng
Signed-off-by: Daniel Axtens
---
arch/powerpc/crypto/Makefile
vpmsum implementations often don't kick in for short test vectors.
This is a simple test module that does a configurable number of
random tests, each up to 64kB and each with random offsets.
Both CRC-T10DIF and CRC32C are tested.
Cc: Anton Blanchard
Signed-off-by: Daniel Axtens
--
Not
,
and then #includes the core algorithm file.
Cc: Anton Blanchard
Signed-off-by: Daniel Axtens
--
It's possible at this point to argue that the address
of the constant tables should be passed in to the function,
rather than doing this somewhat unconventional #include.
However, we're ab
Hi David,
> While not part of this change, the unrolled loops look as though
> they just destroy the cpu cache.
> I'd like be convinced that anything does CRC over long enough buffers
> to make it a gain at all.
>
> With modern (not that modern now) superscalar cpus you can often
> get the loop in
> So although this sits in arch/powerpc, it's heavy on the crypto which is
> not my area of expertise (to say the least!), so I think it should
> probably go via Herbert and the crypto tree?
That was my thought as well. Sorry - probably should have put that in
the comments somewhere.
Regards,
Dan
Hi Matt,
> The raid6 Q syndrome check has been optimised using the vpermxor
> instruction. This instruction was made available with POWER8, ISA version
> 2.07. It allows for both vperm and vxor instructions to be done in a single
> instruction. This has been tested for correctness on a ppc64le vm
> In that function, the flow is:
> pagefault_disable();
> enable_kernel_altivec();
>
> pagefault_enable();
>
> There are a few things that it would be nice (but by no means essential)
> to find out:
> - what is the difference between pagefault and prempt enable/disable
> - is it required to
Hi all,
I'm trying to get my head around these patches - at this point I'm just
doing a first pass, so I may have more substantive structural comments
later on. In the mean time - here are some minor C nits:
> + * Copyright (C) 2016 Madhavan Srinivasan, IBM Corporation.
> + * (C) 2016 H
Madhavan Srinivasan writes:
> From: Hemant Kumar
>
> Parse device tree to detect IMC units. Traverse through each IMC unit
> node to find supported events and corresponding unit/scale files (if any).
>
> Here is the DTS file for reference:
>
>
> https://github.com/open-power/ima-catalog/b
Hi,
> + do {
> + pages = PAGE_SIZE * i;
> + pcni->vbase[i++] = (u64)phys_to_virt(pcni->pbase +
> + pages);
> + } while (i < (pcni->size / PAGE_SIZE));
I also just noticed that
Hi,
> +#define IMC_MAX_CHIPS32
> +#define IMC_MAX_PMUS 32
> +#define IMC_MAX_PMU_NAME_LEN 256
I've noticed this is used as both the maximum length for event names and
event value strings. Would another name suit better?
> +
> +#define IMC_NEST_MAX_P
Hi,
> Device tree IMC driver code parses the IMC units and their events. It
> passes the information to IMC pmu code which is placed in powerpc/perf
> as "imc-pmu.c".
>
> This patch creates only event attributes and attribute groups for the
> IMC pmus.
>
> Signed-off-by: Anju T Sudhakar
> Signed-
Hi,
So a major complaint I have is that you're changing prototypes of
functions from earlier patches.
This makes my life a lot harder: I get my head around what a function is
and does and then suddenly the prototype changes, the behaviour changes,
and I have to re-evaluate everything I thought I
Madhavan Srinivasan writes:
> From: Hemant Kumar
>
> Adds cpumask attribute to be used by each IMC pmu. Only one cpu (any
> online CPU) from each chip for nest PMUs is designated to read counters.
>
> On CPU hotplug, dying CPU is checked to see whether it is one of the
> designated cpus, if yes,
ke sure you have spaces
between the beginning/end of a comment and the comment.
> +# ifdef __KERNEL__
> + return (cpu_has_feature(CONFIG_ALTIVEC) &&
> + cpu_has_feature(CPU_FTR_ARCH_207S));
I think CPU_FTR_ARCH_207S implies Altivec? Again, not a real problem,
I don't think it's really worth doing a respin for any of these, so:
Reviewed-by: Daniel Axtens
Thanks for making Power faster!
Regards,
Daniel
Hi Michael,
We'll also need a similar patch for the t10dif code that went in to
Herbert's next.
I will do a patch once I get my development environment up and going
again.
Regards,
Daniel
Michael Ellerman writes:
> In crc32c_vpmsum() we call enable_kernel_altivec() without first
> disabling p
Michael Ellerman writes:
> Matt Brown writes:
>
>> diff --git a/lib/raid6/test/Makefile b/lib/raid6/test/Makefile
>> index 9c333e9..62b26d1 100644
>> --- a/lib/raid6/test/Makefile
>> +++ b/lib/raid6/test/Makefile
>> @@ -44,10 +44,12 @@ else ifeq ($(HAS_NEON),yes)
>> CFLAGS += -DCONFIG_K
Hi Mahesh,
> Fixes: 27ea2c420cad powerpc: Set the correct kernel taint on machine check
> errors.
I notice this Fixes a commit I introduced. Please could you cc me when
you do this? I am likely to miss it otherwise, especially since I have
now left IBM.
Being cced allows me to provide an Ack or
Hi Michael,
> Fixes: b01df1c16c9a ("crypto: powerpc - Add CRC-T10DIF acceleration")
Thank you very much for doing this! (and my apologies for not doing it
myself!)
It all looks good to me.
I think an Ack is appropriate in these circumstances?
Acked-by: Daniel Axtens
Regards,
Daniel
Hi Mahesh,
> diff --git a/arch/powerpc/kernel/mce.c b/arch/powerpc/kernel/mce.c
> index a1475e6..b23b323 100644
> --- a/arch/powerpc/kernel/mce.c
> +++ b/arch/powerpc/kernel/mce.c
> @@ -221,6 +221,8 @@ static void machine_check_process_queued_event(struct
> irq_work *work)
> {
> int index;
Michael Ellerman writes:
> Daniel Axtens writes:
>>> diff --git a/arch/powerpc/kernel/mce.c b/arch/powerpc/kernel/mce.c
>>> index a1475e6..b23b323 100644
>>> --- a/arch/powerpc/kernel/mce.c
>>> +++ b/arch/powerpc/kernel/mc
Hi all,
I've had a look at the API as it was a big thing I didn't like in the
earlier version.
I am much happier with this one.
Some comments:
- I'm no longer subscribed to skiboot but I've had a look at the
patches on that side:
* in patch 9 should opal_imc_counters_init return someth
LE buildroot initrd (per
https://github.com/linuxppc/linux/wiki/Booting-with-Qemu). Sadly I don't
have access to real hardware any more, so I can't say anything more than
that. (ajd - perhaps relevant to your interests?)
Regards,
Daniel
>From 33db928b21e6bcb78f93b7883b423282d65af609 M
rtify prom_init.c for now.
Cc: Kees Cook
Cc: Daniel Micay
Signed-off-by: Daniel Axtens
---
This will need to go in before the main fortify support, but it
doesn't make any sense in the absence of fortify. I think it would
make most sense for Kees to queue this up with the main fortify patch,
w
mp and no panic.
[1] http://openwall.com/lists/kernel-hardening/2017/05/09/2
Suggested-by: Michael Ellerman
Cc: Kees Cook
Cc: Daniel Micay
Signed-off-by: Daniel Axtens
---
arch/powerpc/lib/feature-fixups.c | 180 +++---
1 file changed, 90 insertions(+), 90 delet
. But up
to you, mpe.
Regards,
Daniel
Daniel Axtens (2):
powerpc: Don't fortify prom_init
powerpc: Make feature-fixup tests fortify-safe
arch/powerpc/kernel/prom_init.c | 3 +
arch/powerpc/lib/feature-fixups.c | 180 +++---
2 files changed, 93 inserti
Hi Breno,
Looks good to me.
> Currently tsk->thread.load_tm is not initialized in the task creation
> and can contain garbage on a new task.
>
> This is an undesired behaviour, since it affects the timing to enable
> and disable the transactional memory laziness (disabling and enabling
> the MSR
Hi Ian,
As Andrew said, thanks for everything: CXL enablement was my
introduction to the kernel - it was a great place to start, and it was a
privilege to work with you.
All the best for your future endeavours!
Regards,
Daniel
Ian Munsie writes:
> From: Ian Munsie
>
> I am no longer employed
Hi Matt,
> Currently ppc_md.get_random_seed uses the powernv_get_random_long function.
> A guest calling this function would have to go through the hypervisor. The
> 'darn' instruction, introduced in POWER9, allows us to bypass this by
> directly obtaining a value from the mmio region.
>
> This pa
93656.html
Daniel Axtens (4):
powerpc: simplify and fix VGA default device behaviour
vgaarb: allow non-legacy cards to be marked as default
powerpc: replace vga_fixup() with generic code
arm64: allow non-legacy VGA devices to be default
arch/arm64/Kconfig | 1 +
arch/power
the device the VGA
arbiter picked.
Instead, set a device as default if there is no default device AND
this device decodes.
This will not change behaviour on single-headed systems.
Cc: Brian King
Signed-off-by: Daniel Axtens
---
Tested in TCG (the card provided by qemu doesn't automatically
regi
symbol is selected, add a PCI_FIXUP_CLASS_ENABLE hook,
which will mark the first card that is enabled and that can control
I/O and memory as the default card.
Behaviour is unchanged unless arches opt-in by selecting the
Kconfig option.
Signed-off-by: Daniel Axtens
---
drivers/gpu/vga/Kconfig | 7
Signed-off-by: Daniel Axtens
---
arch/powerpc/Kconfig | 1 +
arch/powerpc/kernel/pci-common.c | 2 ++
drivers/gpu/vga/Kconfig | 8
drivers/gpu/vga/vgaarb.c | 21 +
4 files changed, 32 insertions(+)
diff --git a/arch/powerpc/Kconfig b
Signed-off-by: Daniel Axtens
---
arch/arm64/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index cae4e677a181..e88081b515d2 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -20,6 +20,7 @@ config ARM64
select
marked as default unless a driver enables it.
Cc: Brian King
Signed-off-by: Daniel Axtens
---
Tested with xeyes on qemu TCG, which does use this code path.
---
arch/powerpc/Kconfig | 1 +
arch/powerpc/kernel/pci-common.c | 15 ---
2 files changed, 1 insertion(+), 15
The VGA arbiter only marks a device as default if it can decode
legacy I/O and memory ranges. This is often not the case on arm64,
which doesn't use the legacy ranges.
Enable the VGA arbiter to mark the first enabled VGA card as
default.
Signed-off-by: Daniel Axtens
---
Tested on a D05
Apologies everyone - this got mixed in with another patch set. I'll do a
v2 that isn't completely broken and confusing.
Again, my apologies for the noise.
Regards,
Daniel
Daniel Axtens writes:
> Hi all,
>
> Previously I posted a patch that provided a quirk for a hi
.org/patch/787003/
[1]: https://www.spinics.net/lists/arm-kernel/msg593656.html
Daniel Axtens (4):
powerpc: simplify and fix VGA default device behaviour
vgaarb: allow non-legacy cards to be marked as default
powerpc: replace vga_fixup() with generic code
arm64: allow non-legacy VGA dev
the device the VGA
arbiter picked.
Instead, set a device as default if there is no default device AND
this device decodes.
This will not change behaviour on single-headed systems.
Cc: Brian King
Signed-off-by: Daniel Axtens
---
Tested in TCG (the card provided by qemu doesn't automatically
regi
symbol is selected, add a PCI_FIXUP_CLASS_ENABLE hook,
which will mark the first card that is enabled and that can control
I/O and memory as the default card.
Behaviour is unchanged unless arches opt-in by selecting the
Kconfig option.
Signed-off-by: Daniel Axtens
---
drivers/gpu/vga/Kconfig | 7
marked as default unless a driver enables it.
Cc: Brian King
Signed-off-by: Daniel Axtens
---
Tested with xeyes on qemu TCG, which does use this code path.
---
arch/powerpc/Kconfig | 1 +
arch/powerpc/kernel/pci-common.c | 15 ---
2 files changed, 1 insertion(+), 15
The VGA arbiter only marks a device as default if it can decode
legacy I/O and memory ranges. This is often not the case on arm64,
which doesn't use the legacy ranges.
Enable the VGA arbiter to mark the first enabled VGA card as
default.
Signed-off-by: Daniel Axtens
---
Tested on a D05
Hi Ard,
> (+ Laszlo)
>
> On 19 July 2017 at 02:28, Daniel Axtens wrote:
>> Hi all,
>>
>> Previously I posted a patch that provided a quirk for a hibmc card
>> behind a particular Huawei bridge that allowed it to be marked as the
>> default device i
Hi Bjorn,
> But I think trying to split the "default device" part out from the VGA
> arbiter ends up being overkill and making things more complicated
> instead of simpler.
Fair enough.
> Would something like the following work for you as well as the powerpc
> case? On powerpc, we already use vg
Hi Bjorn,
Yes, this works:
Tested-by: Daniel Axtens # arm64, ppc64-qemu-tcg
Regards,
Daniel
> On Fri, Sep 01, 2017 at 05:27:41PM +1000, Daniel Axtens wrote:
>> This patch set:
>>
>> - splits the default display handling out from VGA arbiter, into its
>>
> + else
> + vgaarb_info(dev, "no bridge control possible\n");
> + }
Initially I wondered if this info printk could be moved into
vga_arbiter_check_bridge_sharing(), but it's been separated out since
3448a19da479b ("vgaarb: use bridges to control VGA routing where
possible."), and upon closer examination, it seems you can't be sure a
device doesn't share a bridge until the end of the process, so this is
indeed correct.
Everything else also looks good to me.
Reviewed-by: Daniel Axtens
Regards,
Daniel
> +
> + vga_arb_select_default_device();
>
> pr_info("loaded\n");
> return rc;
amination, it seems you can't be sure a
>> device doesn't share a bridge until the end of the process, so this is
>> indeed correct.
>>
>> Everything else also looks good to me.
>>
>> Reviewed-by: Daniel Axtens
>
> R-b for both patches? And ok with e
Daniel Vetter writes:
> On Wed, Oct 18, 2017 at 11:24:43AM +1100, Daniel Axtens wrote:
>> Hi Daniel,
>>
>> >> Initially I wondered if this info printk could be moved into
>> >> vga_arbiter_check_bridge_sharing(), but it's been separated out since
Hi Bryant,
A few things:
1) The commit message could probably be trimmed, especially the stack
traces.
2) What exactly are you changing and why does it fix the issue? I
couldn't figure that out from the commit message.
3) Does this need a Fixes: tag?
> }
>
> - netdev->min_mtu = IB
Hi Bryant,
This looks a bit better, but...
> The following patch ensures that the bounce_buffer is not null
> prior to using it within skb_copy_from_linear_data.
How would this occur?
Looking at ibmveth.c, I see bounce_buffer being freed in ibmveth_close()
and allocated in ibmveth_open() only.
>> This moves the prototypes for functions that are only called from
>> assembler code out of asm/asm-prototypes.h into asm/kvm_ppc.h.
>> The prototypes were added in commit ebe4535fbe7a ("KVM: PPC:
>> Book3S HV: sparse: prototypes for functions called from assembler",
>> 2016-10-10), but given tha
macros. This simple series fixes that, squashing over
60 warnings.
Daniel Axtens (3):
powerpc/sparse: constify the address pointer in __get_user_check
powerpc/sparse: constify the address pointer in __get_user_nocheck
powerpc/sparse: constify the address pointer in __get_user_nosleep
arch
In __get_user_check, we create an intermediate pointer for the
user address we're about to fetch. We currently don't tag this
pointer as const. Make it const, as we are simply dereferencing
it, and it's scope is limited to the __get_user_check macro.
Signed-off-by: Daniel Axtens
In __get_user_nocheck, we create an intermediate pointer for the
user address we're about to fetch. We currently don't tag this
pointer as const. Make it const, as we are simply dereferencing
it, and it's scope is limited to the __get_user_nocheck macro.
Signed-off-by: Daniel Axt
In __get_user_nosleep, we create an intermediate pointer for the
user address we're about to fetch. We currently don't tag this
pointer as const. Make it const, as we are simply dereferencing
it, and it's scope is limited to the __get_user_nosleep macro.
Signed-off-by: Daniel Axt
Hi Russell,
This seems to go Power8, Power9, Power7 - is that intentional?
Regards,
Daniel
> .platform = "power8",
...
> + .platform = "power9",
...
> { /* Power7 */
.org
Signed-off-by: Daniel Axtens
---
arch/powerpc/crypto/crc32c-vpmsum_glue.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/crypto/crc32c-vpmsum_glue.c
b/arch/powerpc/crypto/crc32c-vpmsum_glue.c
index 9fa046d56eba..411994551afc 100644
--- a/arch/powerp
Hi,
That matches the SPDX identifier from the top of the file, so:
Reviewed-by: Daniel Axtens
Regards,
Daniel
Larry Finger writes:
> In kernel 4.15, the modprobe step on my PowerBook G5 started complaining that
> there was no module license for ans-lcd.
>
> Signed-off-by:
Michael Ellerman writes:
> This commit adds security feature flags to reflect the settings we
> receive from firmware regarding Spectre/Meltdown mitigations.
>
> The feature names reflect the names we are given by firmware on bare
> metal machines. See the hostboot source for details.
>
> Arguabl
o
> + * userspace).
> + *
So this is the comment from eeh_handle_event. This seems as good a place
as any to put it. (At some point someone should check if it lines up
well with Documentation/powerpc/eeh-pci-error-recovery.txt but it can wait.)
In conclusion:
Reviewed-by: Daniel Axtens
Tha
c - eeh_dev_open() and eeh_dev_release(). I have not yet
wrapped my head around the logic of that.
I suspect the entire logic can have some more simplifications, but this
is definitely a good step.
I also read through your patch and have no other comments, so:
Reviewed-by: Daniel Axtens
Regards,
Daniel
&g
Sam Bobroff writes:
> Remove a test that checks if "frozen_bus" is NULL, because it cannot
> have changed since it was tested at the start of the function and so
> must be true here.
As far as I can tell this was added back in 2012 in 9b3c76f08122f. As
far as I can tell it couldn't be NULL back
Hi,
I have reports from a user who is experiencing intermittent issues
with qemu being unable to allocate memory for the guest HPT. We see:
libvirtError: internal error: process exited while connecting to monitor:
Unexpected error in spapr_alloc_htab() at
/build/qemu-UwnbKa/qemu-2.5+dfsg/hw/ppc
Squash a couple of sparse warnings by making things static.
Build tested.
Signed-off-by: Daniel Axtens
---
arch/powerpc/kvm/book3s_64_mmu_hv.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kvm/book3s_64_mmu_hv.c
b/arch/powerpc/kvm/book3s_64_mmu_hv.c
A bunch of KVM functions are only called from assembler.
Give them prototypes in asm-prototypes.h
This reduces sparse warnings.
Signed-off-by: Daniel Axtens
---
arch/powerpc/include/asm/asm-prototypes.h | 44 +++
arch/powerpc/kvm/book3s_64_vio_hv.c | 1 +
arch
Paul Mackerras writes:
> On Mon, Oct 10, 2016 at 11:31:20AM +1100, Daniel Axtens wrote:
>> A bunch of KVM functions are only called from assembler.
>> Give them prototypes in asm-prototypes.h
>> This reduces sparse warnings.
>>
>> Signed-off-by: Daniel Axtens
This is just a smattering of things picked up by sparse that should
be made static.
Signed-off-by: Daniel Axtens
---
arch/powerpc/kernel/crash.c | 2 +-
arch/powerpc/kernel/sysfs.c | 2 +-
arch/powerpc/platforms/powernv/idle.c | 2 +-
arch
Sparse picked up a number of functions that are implemented in C and
then only referred to in asm code.
This introduces asm-prototypes.h, which provides a place for
prototypes of these functions.
This silences some sparse warnings.
Signed-off-by: Daniel Axtens
---
arch/powerpc/include/asm/asm
Sometimes headers that provide prototypes for functions are
accidentally omitted from the files that define the functions.
Fix a couple of times that occurs.
Signed-off-by: Daniel Axtens
---
arch/powerpc/kernel/smp.c | 1 +
arch/powerpc/platforms/pseries/power.c | 2 ++
2 files
of LE is arbitrary.
Signed-off-by: Daniel Axtens
---
arch/powerpc/kernel/align.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/align.c b/arch/powerpc/kernel/align.c
index 8e7cb8e2b21a..43f745f2cea9 100644
--- a/arch/powerpc/kernel/align.c
+++ b/arch/powe
Yay for tests!
I have a few minor nits, and one more major one (rc == 2 below).
> +/*
> + * Copyright 2015, Cyril Bur, IBM Corp.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * as published by the Fr
I'm trying not to be too nit picky or difficult on tests, so here's a
pre-written commit message for you:
"The kernel sets up two sets of ucontexts if the signal was to be
delivered while the thread was in a transaction. Expected behaviour is
that the currently executing code is in the first and t
> It would be better to fix the sparse compilation so the same endianess
> is set that you get when calling gcc.
I will definitely work on a patch to sparse! I'd still like this or
something like it to go in though, so we can keep working on reducing
the sparse warning count while the sparse patch
werpc/lib/sstep.c:411:32: error: cast from unknown
type
+/scratch/dja/linux/arch/powerpc/lib/sstep.c:411:59: error: using member 'word'
in incomplete struct
So:
Tested-by: Daniel Axtens
(I think the patch also needs your sign-off.)
Regards,
Daniel
__
Hi,
mpe merged this to his next yesterday, and my nightly scripts picked up
the following cppcheck warning:
[arch/powerpc/kernel/pci_dn.c:486]: (error) Memory leak: pdn
That goes to the following function:
static void *add_pdn(struct device_node *dn, void *data)
{
struct pci_controller
tation.
Signed-off-by: Daniel Axtens
---
arch/powerpc/kvm/book3s_64_vio.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/kvm/book3s_64_vio.c b/arch/powerpc/kvm/book3s_64_vio.c
index 18cf6d1f8174..c379ff5a4438 100644
--- a/arch/powerpc/kvm/book3s_64_vio.c
+++ b/a
Sadly, access_process_vm takes an unsigned long, rather than a void
__user *. Worse, it's a generic kernel function: changing it would be
a massive, kernel-wide effort.
So, __force the annotation away.
Signed-off-by: Daniel Axtens
---
arch/powerpc/kernel/ptrace32.c | 4 ++--
1 file chang
Make the cast fully line up with what out_rm8 expects.
Signed-off-by: Daniel Axtens
---
arch/powerpc/sysdev/xics/icp-native.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/sysdev/xics/icp-native.c
b/arch/powerpc/sysdev/xics/icp-native.c
index afdf62f2a695
e we know what we're doing
with __force.
Signed-off-by: Daniel Axtens
---
arch/powerpc/kernel/hw_breakpoint.c | 2 +-
arch/powerpc/kernel/io.c| 16
arch/powerpc/kernel/process.c | 2 +-
3 files changed, 10 insertions(+), 10 deletions(-)
diff --
801 - 900 of 941 matches
Mail list logo
