Hi Sathvika,
(Sorry didn't include list in earlier email.)
On Mon, Feb 20, 2023 at 12:35:09PM +0530, Sathvika Vasireddy wrote:
> Hi Kautuk,
>
> On 20/02/23 10:53, Kautuk Consul wrote:
> > kvmppc_hv_entry isn't called from anywhere other than
> > book3s_hv_rmhandlers.S itself. Removing .global
Le 25/01/2023 à 08:40, Christophe Leroy a écrit :
Le 22/01/2023 à 12:19, Pali Rohár a écrit :
On Saturday 24 December 2022 18:44:52 Pali Rohár wrote:
On Thursday 08 December 2022 19:57:39 Christophe Leroy wrote:
Le 08/12/2022 à 20:16, Pali Rohár a écrit :
With "[PATCH v1] powerpc/64:
Hi Kautuk,
On 20/02/23 10:53, Kautuk Consul wrote:
kvmppc_hv_entry isn't called from anywhere other than
book3s_hv_rmhandlers.S itself. Removing .global scope for
this function.
Signed-off-by: Kautuk Consul
---
arch/powerpc/kvm/book3s_hv_rmhandlers.S | 1 -
1 file changed, 1 deletion(-)
kvmppc_hv_entry is called from only 2 locations within
book3s_hv_rmhandlers.S. Both of those locations set r4
as HSTATE_KVM_VCPU(r13) before calling kvmppc_hv_entry.
So, shift the r4 load instruction to kvmppc_hv_entry and
thus modify the calling convention of this function.
Signed-off-by: Kautuk
kvmppc_hv_entry isn't called from anywhere other than
book3s_hv_rmhandlers.S itself. Removing .global scope for
this function.
Signed-off-by: Kautuk Consul
---
arch/powerpc/kvm/book3s_hv_rmhandlers.S | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/powerpc/kvm/book3s_hv_rmhandlers.S
- remove .global scope of kvmppc_hv_entry
- remove r4 argument to kvmppc_hv_entry as it is not required
Kautuk Consul (2):
arch/powerpc/kvm: kvmppc_hv_entry: remove .global scope
arch/powerpc/kvm: kvmppc_hv_entry: remove r4 argument
arch/powerpc/kvm/book3s_hv_rmhandlers.S | 10 --
1
Nathan Chancellor writes:
> Currently, CONFIG_PPC64_BIG_ENDIAN_ELF_ABI_V2 is not selectable with
> ld.lld because of an explicit dependency on GNU ld, due to lack of
> testing with LLVM.
>
> Erhard was kind enough to test this option on his hardware with LLVM 15,
> which ran without any issues.
Christophe Leroy writes:
> Le 17/02/2023 à 00:23, Rohan McLure a écrit :
>>> On 16 Feb 2023, at 6:14 pm, Christophe Leroy
>>> wrote:
>>> Le 16/02/2023 à 06:09, Rohan McLure a écrit :
Enable HAVE_ARCH_KCSAN on all powerpc platforms, permitting use of the
kernel concurrency sanitiser
Christophe Leroy writes:
> cpu-as-y is there to force assembler building options.
> But there is no need for that. Gcc is passed the necessary
> options and it automatically pass the appropriate option to
> GAS.
>
> GCC is given -maltivec when relevant, so no need
> for -Wa,-maltivec in addition
> On 16-Feb-2023, at 1:38 PM, Athira Rajeev wrote:
>
> Add a function dt_find_by_name_substr() that returns the child node if
> it matches till first occurence at "@" of a given name, otherwise NULL.
> This is helpful for cases with node name like: "name@addr". In
> scenarios where nodes are
On Mon, 19 Dec 2022 19:45:56 +0100, Christophe Leroy wrote:
> Since 0069f3d14e7a ("powerpc/64e: Tie PPC_BOOK3E_64 to PPC_E500MC"), the
> only possible BOOK3E/64 are E500, so no need of a default CPU over the
> E5500.
>
> When the user selects book3e, they must have an e500 compatible
> compiler,
On Fri, 17 Feb 2023 10:02:26 +0530, Sathvika Vasireddy wrote:
> objtool throws the following warning:
> arch/powerpc/kernel/head_64.o: warning: objtool: .text+0x6128:
> unannotated intra-function call
>
> Fix the warning by annotating start_initialization_book3s symbol with the
>
On Fri, 16 Dec 2022 17:57:08 +0530, Sourabh Jain wrote:
> Print the FDT error description along with the error message if failed
> to set the "linux,drconf-usable-memory" property in the kdump kernel's
> FDT.
>
>
Applied to powerpc/next.
[1/1] powerpc/kexec_file: print error string on usable
On Mon, 13 Feb 2023 13:23:51 -0600, Nathan Lynch wrote:
> machine_is() can't provide correct results before probe_machine() has
> run. Warn when it's used too early in boot, placing the WARN_ON() in a
> helper function so the reported file:line indicates exactly what went
> wrong.
>
> checkpatch
On Wed, 15 Feb 2023 10:12:12 -0700, Nathan Chancellor wrote:
> Clang warns:
>
> drivers/macintosh/windfarm_lm75_sensor.c:63:14: error: implicit truncation
> from 'int' to a one-bit wide bit-field changes value from 1 to -1
> [-Werror,-Wsingle-bit-bitfield-constant-conversion]
>
On Thu, 16 Feb 2023 22:29:15 +1100, Michael Ellerman wrote:
> When using the LLVM integrated assembler (llvm-as), the book3e build
> fails with:
>
> arch/powerpc/mm/nohash/tlb_low_64e.S:354:2: error: invalid instruction
>tlbilxva 0,%r15
>^
>
> [...]
Applied to powerpc/next.
[1/1]
On Mon, 13 Feb 2023 22:23:22 +1100, Michael Ellerman wrote:
> With bintils >= 2.38 the ppc64_book3e_allmodconfig build fails:
>
> {standard input}: Assembler messages:
> {standard input}:196: Error: unrecognized opcode: `lbarx'
> {standard input}:196: Error: unrecognized opcode: `stbcx.'
>
On Thu, 9 Feb 2023 16:26:49 +0530, Ganesh Goudar wrote:
> When a PCI error is encountered 6th time in an hour we
> set the channel state to perm_failure and notify the
> driver about the permanent failure.
>
> However, after upstream commit 38ddc011478e ("powerpc/eeh:
> Make permanently failed
On Wed, 10 Aug 2022 13:43:18 +0200, Anders Roxell wrote:
> Clang warns:
>
> arch/powerpc/mm/book3s64/radix_tlb.c:1191:23: error: variable 'hstart' is
> uninitialized when used here [-Werror,-Wuninitialized]
> __tlbiel_va_range(hstart, hend, pid,
>
On Thu, 16 Feb 2023 18:09:03 +1100, Andrew Donnellan wrote:
> When a user updates a variable through the PLPKS secvar interface, we take
> the first 8 bytes of the data written to the update attribute to pass
> through to the H_PKS_SIGNED_UPDATE hcall as flags. These bytes are always
> written in
On Fri, 17 Feb 2023 12:14:34 +1100, Benjamin Gray wrote:
> In the fix reconnecting hash__tlb_flush() to tlb_flush() the
> void return on radix__tlb_flush() was not restored and subsequently
> falls through to the restored hash__tlb_flush().
>
> Guard hash__tlb_flush() under an else to prevent
Rick Edgecombe writes:
> The x86 Control-flow Enforcement Technology (CET) feature includes a new
> type of memory called shadow stack. This shadow stack memory has some
> unusual properties, which requires some core mm changes to function
> properly.
...
> ---
> Hi Non-x86 Arch’s,
>
> x86 has a
Pali Rohár writes:
> On Thursday 09 February 2023 01:10:21 Pali Rohár wrote:
>> On Monday 26 December 2022 12:45:13 Pali Rohár wrote:
>> > Due to CPLD firmware bugs, set CPLD syscon-reboot priority level to 64
>> > (between rstcr and watchdog) to ensure that rstcr's global-utilities reset
>> >
Joe Perches writes:
> On Sat, 2023-02-18 at 10:15 +0100, Christophe Leroy wrote:
>> Many places have:
>>
>> if (ppc.md_progress)
>> ppc.md_progress();
>>
>> Use ppc_md_progress() instead.
>>
>> Note that checkpatch complains about using function names,
>> but this is not a
Linus Torvalds writes:
> On Fri, Feb 17, 2023 at 2:40 PM Michael Ellerman wrote:
>>
>> Thanks to: Benjamin Gray, "Erhard F.".
>
> That just looks _odd_.
Yeah true. My scripts just take it verbatim from the From: line of the
email.
> It's not like the full name wasn't already elsewhere in the
On Sat, Feb 18, 2023 at 01:14:05PM -0800, Rick Edgecombe wrote:
> The x86 Control-flow Enforcement Technology (CET) feature includes a new
> type of memory called shadow stack. This shadow stack memory has some
> unusual properties, which requires some core mm changes to function
> properly.
>
>
On Sun, 5 Feb 2023, Maciej W. Rozycki wrote:
> This is v6 of the change to work around a PCIe link training phenomenon
> where a pair of devices both capable of operating at a link speed above
> 2.5GT/s seems unable to negotiate the link speed and continues training
> indefinitely with the
27 matches
Mail list logo
