On Fri, 2022-12-30 at 15:20 +1100, Russell Currey wrote:
> Currently the max object size is handled in the core secvar code with
> an
> entirely OPAL-specific implementation, so create a new max_size() op
> and
> move the existing implementation into the powernv platform. Should
> be
> no
On Tue 03-01-23 16:27:32, Mike Kravetz wrote:
> zap_page_range was originally designed to unmap pages within an address
> range that could span multiple vmas. While working on [1], it was
> discovered that all callers of zap_page_range pass a range entirely within
> a single vma. In addition,
On Wed, 2023-01-04 at 14:57 +1100, Russell Currey wrote:
> > + maxobjlabelsize = be16_to_cpu(config->maxobjlabelsize) -
> > + MAX_LABEL_ATTR_SIZE;
> > + maxobjlabelsize = maxobjlabelsize < 0 ? 0 :
> > maxobjlabelsize;
>
> Isn't a bit of precision lost here?
On Wed, 2023-01-04 at 15:04 +1100, Russell Currey wrote:
> > + if (!rc) {
> > + rc = plpks_confirm_object_flushed(label, auth);
> > + rc = pseries_status_to_err(rc);
>
> Doesn't plpks_confirm_object_flushed() already return a Linux-
> friendly
> error code? If
On Fri, 2022-12-30 at 15:20 +1100, Russell Currey wrote:
> The code that handles the format string in secvar-sysfs.c is entirely
> OPAL specific, so create a new "format" op in secvar_operations to
> make
> the secvar code more generic. No functional change.
>
> Signed-off-by: Russell Currey
On Fri, 2022-12-30 at 15:20 +1100, Russell Currey wrote:
> The secvar format string and object size sysfs files are both ASCII
> text, and should use sysfs_emit(). No functional change.
>
> Suggested-by: Greg Kroah-Hartman
> Signed-off-by: Russell Currey
LGTM
Reviewed-by: Andrew Donnellan
On Fri, 2022-12-30 at 15:20 +1100, Russell Currey wrote:
> The secvar code only supports one consumer at a time.
>
> Multiple consumers aren't possible at this point in time, but we'd
> want
> it to be obvious if it ever could happen.
>
> Signed-off-by: Russell Currey
This seems sensible -
On Mon, 2022-12-26 at 10:51 +0800, Dong Chuanjian wrote:
> remove unnecessary void* type casting.
>
> Signed-off-by: Dong Chuanjian
[+linuxppc-dev, which was misspelled in the original email]
Acked-by: Andrew Donnellan
>
> diff --git a/drivers/misc/ocxl/context.c
>
On Tue, Jan 03, 2023 at 04:32:18PM +0100, Andreas Schwab wrote:
> On Jan 03 2023, Ojaswin Mujoo wrote:
>
> > If version is of the form x.y.z and length(z) == 8, then most probably
> > it is a date [mmdd]. As an approximation, discard the dd and
> > parts and keep the mm part in the
On Wed, Jan 04, 2023 at 10:27:33AM +0530, Rajat Khandelwal wrote:
> Hi Bjorn,
>
> Thanks for the acknowledgement.
>
> On 1/4/2023 12:44 AM, Bjorn Helgaas wrote:
> > [+cc Paul, Sasha, Leon, Frederick]
> >
> > (Please cc folks who have commented on previous versions of your
> > patch.)
> >
> >
Hi Bjorn,
Thanks for the acknowledgement.
On 1/4/2023 12:44 AM, Bjorn Helgaas wrote:
[+cc Paul, Sasha, Leon, Frederick]
(Please cc folks who have commented on previous versions of your
patch.)
On Tue, Jan 03, 2023 at 10:25:48PM +0530, Rajat Khandelwal wrote:
There are many instances where
On Fri, 2022-12-30 at 15:20 +1100, Russell Currey wrote:
> The plpks code converts hypervisor return codes into their Linux
> equivalents so that users can understand them. Having access to the
> original return codes is really useful for debugging, so add a
> pr_debug() so we don't lose
On Tue, 2022-12-20 at 18:16 +1100, Andrew Donnellan wrote:
> From: Nayna Jain
>
> The Platform Keystore provides a signed update interface which can be
> used
> to create, replace or append to certain variables in the PKS in a
> secure
> fashion, with the hypervisor requiring that the update be
On Tue, 2022-12-20 at 18:16 +1100, Andrew Donnellan wrote:
> From: Nayna Jain
>
> The plpks driver uses the H_PKS_GET_CONFIG hcall to retrieve
> configuration
> and status information about the PKS from the hypervisor.
>
> Update _plpks_get_config() to handle some additional fields. Add
>
On Tue, 2022-12-20 at 18:16 +1100, Andrew Donnellan wrote:
> A number of structures and buffers passed to PKS hcalls have
> alignment
> requirements, which could on occasion cause problems:
>
> - Authorisation structures must be 16-byte aligned and must not cross
> a
> page boundary
>
> -
On Tue, 2022-12-20 at 18:16 +1100, Andrew Donnellan wrote:
> plpks_confirm_object_flushed() uses the H_PKS_CONFIRM_OBJECT_FLUSHED
> hcall
> to check whether changes to an object in the Platform KeyStore have
> been
> flushed to non-volatile storage.
>
> The hcall returns two output values, the
The parameter "max" of SOC_SINGLE_SX_TLV() means the number of steps
rather than maximum value. This patch corrects the minimum value to -8
and the number of steps to 15.
Signed-off-by: Chancel Liu
---
sound/soc/fsl/fsl_micfil.c | 16
1 file changed, 8 insertions(+), 8
在 2023/1/3 下午11:42，“Daniel Borkmann” 写入:
On 1/3/23 2:24 PM, x...@infragraf.org wrote:
> From: Tonghao Zhang
>
> The x86_64 can't dump the valid insn in this way. A test BPF prog
> which include subprog:
>
> $ llvm-objdump -d subprog.o
> Disassembly of
zap_page_range was originally designed to unmap pages within an address
range that could span multiple vmas. While working on [1], it was
discovered that all callers of zap_page_range pass a range entirely within
a single vma. In addition, the mmu notification call within zap_page
range does not
> On 3. Jan 2023, at 05:04, Christian Zigotzky wrote:
>
> On 02 January 2023 at 04:32 am, Christian Zigotzky wrote:
>> On 01 January 2023 at 07:11 pm, Sean Anderson wrote:
>>
>> Thank you for testing this. Unfortunately, I have no P-series hardware,
>> so I was unable to test the 10gec/dtsec
On 1/2/23 02:58, Linux kernel regression tracking (#info) wrote:
> [TLDR: I'm adding this report to the list of tracked Linux kernel
> regressions; all text you find below is based on a few templates
> paragraphs you might have encountered already already in similar form.
> See link in footer if
[+cc Paul, Sasha, Leon, Frederick]
(Please cc folks who have commented on previous versions of your
patch.)
On Tue, Jan 03, 2023 at 10:25:48PM +0530, Rajat Khandelwal wrote:
> There are many instances where correctable errors tend to inundate
> the message buffer. We observe such instances
There are many instances where correctable errors tend to inundate
the message buffer. We observe such instances during thunderbolt PCIe
tunneling.
It's true that they are mitigated by the hardware and are non-fatal
but we shouldn't be spamming the logs with such correctable errors as it
confuses
From: Tonghao Zhang
The x86_64 can't dump the valid insn in this way. A test BPF prog
which include subprog:
$ llvm-objdump -d subprog.o
Disassembly of section .text:
:
0: 18 01 00 00 73 75 62 70 00 00 00 00 72 6f 67 00 r1 =
29114459903653235 ll
2: 7b
Commit fdacae8a84024474afff234bdd1dbe19ad597a10 (powerpc: Activate
CONFIG_STRICT_KERNEL_RWX by default) causes ps3_hpte_updateboltedpp()
to be called. Change the panic statment in ps3_hpte_updateboltedpp()
to a pr_info statement so that bootup can continue.
Signed-off-by: Geoff Levand
---
Refresh ps3_defconfig for v6.2.
Signed-off-by: Geoff Levand
---
arch/powerpc/configs/ps3_defconfig | 39 +-
1 file changed, 17 insertions(+), 22 deletions(-)
diff --git a/arch/powerpc/configs/ps3_defconfig
b/arch/powerpc/configs/ps3_defconfig
index
Hi Michael,
This v2 series is just the two PS3 specific patches of the v1 series.
-Geoff
The following changes since commit 88603b6dc419445847923fcb7fe5080067a30f98:
Linux 6.2-rc2 (2023-01-01 13:53:16 -0800)
are available in the Git repository at:
On Tue, Jan 3, 2023 at 10:45 AM Geoff Levand wrote:
>
> Hi Rob,
>
> On 1/2/23 18:03, Rob Herring wrote:
> > On Mon, Jan 2, 2023 at 1:41 PM Geoff Levand wrote:
>
> >> --- a/arch/powerpc/kernel/prom.c
> >> +++ b/arch/powerpc/kernel/prom.c
> >> @@ -761,7 +761,7 @@ void __init
Hi Rob,
On 1/2/23 18:03, Rob Herring wrote:
> On Mon, Jan 2, 2023 at 1:41 PM Geoff Levand wrote:
>> --- a/arch/powerpc/kernel/prom.c
>> +++ b/arch/powerpc/kernel/prom.c
>> @@ -761,7 +761,7 @@ void __init early_init_devtree(void *params)
>> DBG(" -> early_init_devtree(%px)\n", params);
On 1/3/23 2:24 PM, x...@infragraf.org wrote:
From: Tonghao Zhang
The x86_64 can't dump the valid insn in this way. A test BPF prog
which include subprog:
$ llvm-objdump -d subprog.o
Disassembly of section .text:
:
0: 18 01 00 00 73 75 62 70 00 00 00 00 72 6f 67
On Jan 03 2023, Ojaswin Mujoo wrote:
> If version is of the form x.y.z and length(z) == 8, then most probably
> it is a date [mmdd]. As an approximation, discard the dd and
> parts and keep the mm part in the version.
I don't think any part of the date should be mixed into the computed
** The Issue **
The ld_version() function seems to compute the wrong version value for
certain ld versions like the following:
$ ld --version GNU ld (GNU Binutils; SUSE Linux Enterprise 15)
2.37.20211103-150100.7.37
For input 2.37.20211103, the value computed is 20234803 which is way
more
On Fri, Dec 30, 2022 at 03:15:52PM +0100, Andrzej Hajda wrote:
> __xchg will be used for non-atomic xchg macro.
>
> Signed-off-by: Andrzej Hajda
> Reviewed-by: Arnd Bergmann
> ---
> v2: squashed all arch patches into one
> v3: fixed alpha/xchg_local, thx to l...@intel.com
> ---
...
>
From: Jens Axboe
[ Upstream commit 900f0713fdd730fab0f0bfa4a8ca4db2a8985bbe ]
Wire up TIF_NOTIFY_SIGNAL handling for powerpc.
Cc: linuxppc-dev@lists.ozlabs.org
Acked-by: Michael Ellerman
Signed-off-by: Jens Axboe
Signed-off-by: Greg Kroah-Hartman
---
arch/powerpc/include/asm/thread_info.h
34 matches
Mail list logo
