On 7/8/22 15:00, Alexey Kardashevskiy wrote:
On 7/8/22 01:10, Jason Gunthorpe wrote:
On Thu, Jul 07, 2022 at 11:55:52PM +1000, Alexey Kardashevskiy wrote:
Historically PPC64 managed to avoid using iommu_ops. The VFIO driver
uses a SPAPR TCE sub-driver and all iommu_ops uses were kept in
th
On Fri, Jun 24, 2022 at 11:27:24PM +1000, Michael Ellerman wrote:
> Hi Scott,
>
> A few comments below ...
>
> Scott Cheloha writes:
> >
> > [...]
> >
> > diff --git a/Documentation/watchdog/watchdog-parameters.rst
> > b/Documentation/watchdog/watchdog-parameters.rst
> > index 223c99361a30..2
On 7/8/22 01:10, Jason Gunthorpe wrote:
On Thu, Jul 07, 2022 at 11:55:52PM +1000, Alexey Kardashevskiy wrote:
Historically PPC64 managed to avoid using iommu_ops. The VFIO driver
uses a SPAPR TCE sub-driver and all iommu_ops uses were kept in
the Type1 VFIO driver. Recent development though h
undation.org, keyri...@vger.kernel.org, net...@vger.kernel.org,
k...@vger.kernel.org, da...@lists.linux.dev, linux...@kvack.org,
accessrunner-gene...@lists.sourceforge.net,
linux1394-de...@lists.sourceforge.net, linux-l...@vger.kernel.org,
rds-de...@oss.oracle.com, linux-...@vger.kernel.org, d.
When RDRAND was introduced, there was much discussion on whether it
should be trusted and how the kernel should handle that. Initially, two
mechanisms cropped up, CONFIG_ARCH_RANDOM, a compile time switch, and
"nordrand", a boot-time switch.
Later the thinking evolved. With a properly designed RNG
Hi Christophe,
I love your patch! Yet something to improve:
[auto build test ERROR on powerpc/next]
[also build test ERROR on mkp-scsi/for-next jejb-scsi/for-next linus/master
v5.19-rc5 next-20220707]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting
Hi Christophe,
I love your patch! Perhaps something to improve:
[auto build test WARNING on powerpc/next]
[also build test WARNING on mkp-scsi/for-next jejb-scsi/for-next linus/master
v5.19-rc5 next-20220707]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when
On Fri, 24 Jun 2022 17:52:23 +0200, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> The virt_to_bus/bus_to_virt interface has been deprecated for
> decades. After Jakub Kicinski put a lot of work into cleaning out the
> network drivers using them, there are only a couple of other drivers
> left,
Hi Christophe,
I love your patch! Yet something to improve:
[auto build test ERROR on powerpc/next]
[also build test ERROR on mkp-scsi/for-next jejb-scsi/for-next linus/master
v5.19-rc5 next-20220707]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting
Refactor IMA buffer related functions to make them reusable for carrying
TPM logs across kexec.
Signed-off-by: Stefan Berger
Cc: Rob Herring
Cc: Frank Rowand
Cc: Mimi Zohar
---
v6:
- Add __init to get_kexec_buffer as suggested by Jonathan
v5:
- Rebased on Jonathan McDowell's commit "b69a2a
From: Vaibhav Jain
Presently ima_get_kexec_buffer() doesn't check if the previous kernel's
ima-kexec-buffer lies outside the addressable memory range. This can result
in a kernel panic if the new kernel is booted with 'mem=X' arg and the
ima-kexec-buffer was allocated beyond that range by the pre
The memory area of the TPM measurement log is currently not properly
duplicated for carrying it across kexec when an Open Firmware
Devicetree is used. Therefore, the contents of the log get corrupted.
Fix this for the kexec_file_load() syscall by allocating a buffer and
copying the contents of the
Simplify tpm_read_log_of() by moving reusable parts of the code into
an inline function that makes it commonly available so it can be
used also for kexec support. Call the new of_tpm_get_sml_parameters()
function from the TPM Open Firmware driver.
Signed-off-by: Stefan Berger
Cc: Jarkko Sakkinen
From: Jonathan McDowell
On kexec file load, the Integrity Measurement Architecture (IMA)
subsystem may verify the IMA signature of the kernel and initramfs, and
measure it. The command line parameters passed to the kernel in the
kexec call may also be measured by IMA.
A remote attestation servic
From: Palmer Dabbelt
RISC-V recently added kexec_file() support, which uses enables kexec
IMA. We're the first 32-bit platform to support this, so we found a
build bug.
Acked-by: Rob Herring
Signed-off-by: Palmer Dabbelt
Reviewed-by: Mimi Zohar
---
drivers/of/kexec.c | 4 ++--
1 file change
The of-tree subsystem does not currently preserve the IBM vTPM 1.2 and
vTPM 2.0 measurement logs across a kexec on PowerVM and PowerKVM. This
series fixes this for the kexec_file_load() syscall using the flattened
device tree (fdt) to carry the TPM measurement log's buffer across kexec.
Stefan
On 7/7/22 10:47, Jonathan McDowell wrote:
On Wed, Jul 06, 2022 at 11:23:28AM -0400, Stefan Berger wrote:
Refactor IMA buffer related functions to make them reusable for carrying
TPM logs across kexec.
Signed-off-by: Stefan Berger
Cc: Rob Herring
Cc: Frank Rowand
Cc: Mimi Zohar
---
v5:
On Fri, Jun 24, 2022 at 11:27:36PM +1000, Michael Ellerman wrote:
> Nathan Lynch writes:
> > Scott Cheloha writes:
> >> PAPR v2.12 defines a new hypercall, H_WATCHDOG. The hypercall permits
> >> guest control of one or more virtual watchdog timers.
> ...
> >
> > Seems like we don't need pseries_
On Fri, Jun 24, 2022 at 11:51:01PM +1000, Michael Ellerman wrote:
> Scott Cheloha writes:
> ...
> > +
> > +static struct platform_driver pseries_wdt_driver = {
> > + .driver = {
> > + .name = DRV_NAME,
> > + .owner = THIS_MODULE,
>
> That owner assignment is not required.
>
On Thu, Jul 07, 2022 at 11:55:52PM +1000, Alexey Kardashevskiy wrote:
> Historically PPC64 managed to avoid using iommu_ops. The VFIO driver
> uses a SPAPR TCE sub-driver and all iommu_ops uses were kept in
> the Type1 VFIO driver. Recent development though has added a coherency
> capability check
We have PPC_INST_SETB then build the 'setb' instruction in the
user.
Instead, define PPC_RAW_SETB() and use it.
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/ppc-opcode.h | 2 +-
arch/powerpc/lib/test_emulate_step.c | 9 +++--
2 files changed, 4 insertions(+), 7 deletions(-)
Add and use PPC_RAW_TRAP() instead of opencoding.
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/ppc-opcode.h | 2 ++
arch/powerpc/include/asm/probes.h | 3 ++-
arch/powerpc/xmon/xmon.c | 2 +-
3 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/arch/pow
ppc_opcode_t is just an u32. There is no point in hiding u32
behind such a typedef. Remove it.
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/kprobes.h | 2 +-
arch/powerpc/include/asm/probes.h | 1 -
arch/powerpc/include/asm/uprobes.h | 2 +-
3 files changed, 2 insertions(+), 3 d
From: Rashmica Gupta
Currently the perf CPU backend drivers detect what CPU they're on using
cur_cpu_spec->oprofile_cpu_type.
Although that works, it's a bit crufty to be using oprofile related fields,
especially seeing as oprofile is more or less unused these days.
It also means perf is relian
Commit 9850b6c69356 ("arch: powerpc: Remove oprofile") removed
oprofile.
Remove all remaining parts of it.
Signed-off-by: Christophe Leroy
Acked-by: Viresh Kumar
---
arch/powerpc/include/asm/cputable.h | 3 -
arch/powerpc/kernel/cputable.c| 67 +--
arch/p
Remove all headers included from asm/prom.h which are not used
by asm/prom.h itself.
Declare struct device_node and struct property locally to
avoid including of.h
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/prom.h | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-
asm/pci.h and asm/mpc52xx.h don't need asm/prom.h
Declare struct device_node locally to avoid including of.h
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/mpc52xx.h | 3 ++-
arch/powerpc/include/asm/pci.h | 1 -
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/a
powerpc's asm/prom.h brings some headers that it doesn't need itself.
Once those headers are removed from asm/prom.h, the following
errors occur:
CC [M] drivers/scsi/cxlflash/ocxl_hw.o
drivers/scsi/cxlflash/ocxl_hw.c: In function 'afu_map_irq':
drivers/scsi/cxlflash/ocxl_hw.c:195:16: error: im
A lot of drivers were getting platform and of headers
indirectly via headers like asm/pci.h or asm/prom.h
Most of them were fixed during 5.19 cycle but a newissue was
introduced by commit 52b1b46c39ae ("of: Create platform devices
for OF framebuffers")
Include missing platform_device.h to allow c
__do_IRQ() doesn't switch on hardirq stack if we are on softirq stack.
do_softirq() bail out early without doing anything when already in
an interrupt.
invoke_softirq() is on task_stack when it calls do_softirq_own_stack().
So there are neither situation where we switch from hardirq stack to
sof
Historically PPC64 managed to avoid using iommu_ops. The VFIO driver
uses a SPAPR TCE sub-driver and all iommu_ops uses were kept in
the Type1 VFIO driver. Recent development though has added a coherency
capability check to the generic part of VFIO and essentially disabled
VFIO on PPC64; the simila
On Thu, Jul 7, 2022 at 1:20 PM Christophe Leroy
wrote:
>
>
>
> Le 17/08/2021 à 15:02, Jan Stancek a écrit :
> > gcov and kasan rely on compiler generated constructor code.
> > For modules, gcc-8 with gcov enabled generates .init_array section,
> > but on ppc64le it doesn't get executed. find_modul
Hi Jason,
On Thu, 7 Jul 2022 12:52:54 +0200 "Jason A. Donenfeld" wrote:
>
> Oh darn. Any clever tricks to prevent the merge conflict from
> happening? Or is this trivial enough that we'll let Linus deal with
> it?
Just leave it for Linus, its pretty trivial.
--
Cheers,
Stephen Rothwell
pgpmV
Le 17/08/2021 à 15:02, Jan Stancek a écrit :
gcov and kasan rely on compiler generated constructor code.
For modules, gcc-8 with gcov enabled generates .init_array section,
but on ppc64le it doesn't get executed. find_module_sections() never
finds .init_array section, because module_frob_arch_
https://bugzilla.kernel.org/show_bug.cgi?id=213079
--- Comment #19 from Erhard F. (erhar...@mailbox.org) ---
(Luckily) I am no longer able to reproduce this. Re-tested on 5.19-rc5.
Perhaps the problem was also specific for this specific NVMe SSD. I swapped it
for another one and now I have not se
https://bugzilla.kernel.org/show_bug.cgi?id=213837
--- Comment #21 from Erhard F. (erhar...@mailbox.org) ---
(Luckily) I am no longer able to reproduce this. Re-tested on 5.19-rc5.
I'll keep an eye on it and will close here if it stays like that for the next
few stable kernels.
--
You may reply
org, net...@vger.kernel.org, k...@vger.kernel.org, da...@lists.linux.dev,
linux...@kvack.org, accessrunner-gene...@lists.sourceforge.net,
linux1394-de...@lists.sourceforge.net, linux-l...@vger.kernel.org,
rds-de...@oss.oracle.com, linux-...@vger.kernel.org, d...@vger.kernel.org,
intel-wired-..
org, net...@vger.kernel.org, k...@vger.kernel.org, da...@lists.linux.dev,
linux...@kvack.org, accessrunner-gene...@lists.sourceforge.net,
linux1394-de...@lists.sourceforge.net, linux-l...@vger.kernel.org,
rds-de...@oss.oracle.com, linux-...@vger.kernel.org, d...@vger.kernel.org,
intel-wired-...
l.org, da...@lists.linux.dev, Linux Memory Management List
, accessrunner-gene...@lists.sourceforge.net,
linux1394-de...@lists.sourceforge.net, linux-l...@vger.kernel.org,
rds-de...@oss.oracle.com, linux-...@vger.kernel.org, d...@vger.kernel.org,
intel-wired-...@lists.osuosl.org, linux-ser...@v
On Thursday 07 July 2022 09:56:04 Christophe Leroy wrote:
> Le 04/07/2022 à 15:43, Arnd Bergmann a écrit :
> > On Mon, Jul 4, 2022 at 3:29 PM Pali Rohár wrote:
> >>
> >> And still what to do with 4bf4f42a2feb ("powerpc/kbuild: Set default
> >> generic machine type for 32-bit compile")? I'm somehow
Le 04/07/2022 à 15:43, Arnd Bergmann a écrit :
> On Mon, Jul 4, 2022 at 3:29 PM Pali Rohár wrote:
>>
>> And still what to do with 4bf4f42a2feb ("powerpc/kbuild: Set default
>> generic machine type for 32-bit compile")? I'm somehow lost there...
>
> As far as I can tell, that is not needed, as l
Le 06/12/2018 à 12:31, Gautham R. Shenoy a écrit :
> From: "Gautham R. Shenoy"
>
> Currently running DLPAR offline/online operations in a loop on a
> POWER9 system with SMT=off results in the following crash:
>
> [ 223.321032] cpu 112 (hwid 112) Ready to die...
> [ 223.355963] Querying DEAD?
Le 31/08/2018 à 09:30, Pingfan Liu a écrit :
If no start address is specified for crashkernel, the current program hard
code as: crashk_res.start = min(0x800ULL, (ppc64_rma_size / 2));
This limits the candidate memory region, and may cause failure while there
is enough mem for crashkernel.
Hi
Le 16/03/2017 à 07:17, Gavin Shan a écrit :
With OPAL msglog driver, there are two interfaces to retrieve the
firmware (skiboot) logs: /sys/firmware/opal/msglog and xmon "do"
command. The memory console header (descritpor) and output buffer
are resident in memory blocks whose addresses are gr
Use arg->size directly may be better for code readability.Because, the
variable of size has not been found for special purpose at present.
Also,We can reduce the use of a variable.
Signed-off-by: Deming Wang
---
arch/powerpc/kvm/book3s_64_vio.c | 6 +++---
1 file changed, 3 insertions(+), 3 del
Le 12/06/2022 à 23:34, Uwe Kleine-König a écrit :
> Returning an error code (here -EBUSY) from a remove callback doesn't
> prevent the driver from being unloaded. The only effect is that an error
> message is emitted and the driver is removed anyhow.
>
> So instead drop the remove function (whic
Le 07/07/2022 à 08:14, Uwe Kleine-König a écrit :
> pmc_dev is only assigned in .probe(), otherwise the variable is unused.
> So drop this pointer that serves no purpose.
>
> Signed-off-by: Uwe Kleine-König
Reviewed-by: Christophe Leroy
> ---
> arch/powerpc/platforms/83xx/suspend.c | 2 --
Le 07/07/2022 à 08:14, Uwe Kleine-König a écrit :
> Returning an error in .remove() doesn't prevent a driver from being
> unloaded. On unbind this only results in an error message, but the
> device is remove anyhow.
>
> I guess the author's idea of just returning -EPERM in .remove() was to
> pre
Le 07/07/2022 à 08:14, Uwe Kleine-König a écrit :
> By moving up pmc_types and pmc_match, the forward declaration for pmc_match
> can be dropped.
>
> Signed-off-by: Uwe Kleine-König
Reviewed-by: Christophe Leroy
> ---
> arch/powerpc/platforms/83xx/suspend.c | 43 +--
Since commit 591b4b268435 ("powerpc/code-patching: Pre-map patch area")
the patch area is premapped so intermediate page tables are already
allocated.
Use __set_pte_at() directly instead of the heavy map_kernel_page(),
at for unmapping just do a pte_clear() followed by a flush.
__set_pte_at() can
Hi all,
Today's linux-next merge of the random tree got a conflict in:
arch/powerpc/Kconfig
between commit:
cea9d62b64c9 ("powerpc: Kconfig: Replace tabs with whitespaces")
from the powerpc tree and commit:
a2ff4b7600cd ("random: remove CONFIG_ARCH_RANDOM")
from the random tree.
I fix
51 matches
Mail list logo
