On 2/4/25 13:52, Sebastian Andrzej Siewior wrote:
Use preempt_model_str() instead of manually conducting the preemption
model. Use pr_emerg() instead of printk() to pass a loglevel.
even on powerpc, i see __die ends up calling show_regs_print_info().
Why print it twice?
Cc: Madhavan Srini
On Tue, 2025-02-04 at 11:28 +0100, Christophe Leroy wrote:
Hi Christophe,
>
> Le 04/02/2025 à 07:39, Kajol Jain a écrit :
> > From: Aboorva Devarajan
> >
> > - Export `boot_tb` for external use, this is useful in perf vpa-dtl
> >interface, where `boot_tb` can be used to convert raw timebas
On Fri, Feb 07, 2025 at 05:37:22PM +0200, Laurent Pinchart wrote:
> I'm tempted to then rename of_find_node_by_name() to
> __of_find_node_by_name() to indicate it's an internal function not meant
> to be called except in special cases. It could all be renamed to
> __of_find_next_node_by_name() to m
The RTAS call ibm,set-dynamic-indicator is used to set the new
indicator state identified by a location code. The current
implementation uses rtas_set_dynamic_indicator() API provided by
librtas library which allocates RMO buffer and issue this RTAS
call in the user space. But /dev/mem access by th
ibm,platform-dump RTAS call in combination with writable mapping
/dev/mem is issued to collect platform dump from the hypervisor
and may need multiple calls to get the complete dump. The current
implementation uses rtas_platform_dump() API provided by librtas
library to issue these RTAS calls. But
The RTAS call ibm,physical-attestation is used to retrieve
information about the trusted boot state of the firmware and
hypervisor on the system, and also Trusted Platform Modules (TPM)
data if the system is TCG 2.0 compliant.
This RTAS interface expects the caller to define different command
stru
The RTAS call ibm,get-dynamic-sensor-state is used to get the
sensor state identified by the location code and the sensor
token. The librtas library provides an API
rtas_get_dynamic_sensor() which uses /dev/mem access for work
area allocation but is restricted under system lockdown.
This patch pro
The RTAS call ibm,get-indices is used to obtain indices and
location codes for a specified indicator or sensor token. The
current implementation uses rtas_get_indices() API provided by
librtas library which allocates RMO buffer and issue this RTAS
call in the user space. But writable mapping /dev/m
To issue ibm,get-indices, ibm,set-dynamic-indicator and
ibm,get-dynamic-sensor-state in the user space, the RMO buffer is
allocated for the work area which is restricted under system
lockdown. So instead of user space execution, the kernel will
provide /dev/papr-indices interface to execute these R
The RTAS call can be normal where retrieves the data form the
hypervisor once or sequence based RTAS call which has to
issue multiple times until the complete data is obtained. For
some of these sequence RTAS calls, the OS should not interleave
calls with different input until the sequence is compl
Several APIs such as rtas_get_indices(), rtas_get_dynamic_sensor(),
rtas_set_dynamic_indicator(), rtas_platform_dump() and
rtas_physical_attestation() provided by librtas library are
implemented in user space using rtas syscall in combination with
writable mappings of /dev/mem. But this implementa
On Fri, Feb 07, 2025 at 09:38:05PM +, Mark Brown wrote:
> On Fri, Feb 07, 2025 at 10:30:17PM +0100, J. Neuschäfer via B4 Relay wrote:
>
> > This is a spin-off of the series titled
> > "powerpc: MPC83xx cleanup and LANCOM NWAPP2 board".
>
> > During the development of that series, it became cl
: 2014c95afecee3e76ca4a56956a936e23283f05b
patch link:
https://lore.kernel.org/r/20250207-ppcyaml-v2-6-8137b0c42526%40posteo.net
patch subject: [PATCH v2 06/12] dt-bindings: pci: Convert fsl,mpc83xx-pcie to
YAML
reproduce:
(https://download.01.org/0day-ci/archive/20250208/202502080922
/devicetree/bindings/memory-controllers/fsl,elbc.example.dtb:
nand@1,0: $nodename:0: 'nand@1,0' does not match '^nand@[a-f0-9]$'
from schema $id:
http://devicetree.org/schemas/mtd/fsl,elbc-fcm-nand.yaml#
doc reference errors (make refcheckdocs):
See
https://patchwork.o
;, 'fsl,elbc-fcm-nand']
doc reference errors (make refcheckdocs):
Warning: Documentation/devicetree/bindings/display/ssd1289fb.txt references a
file that doesn't exist: Documentation/devicetree/bindings/powerpc/fsl/lbc.txt
Documentation/devicetree/bindings/display/ssd1289fb.txt:
Documenta
vicetree/bindings/pci/fsl,mpc8xxx-pci.yaml:
Documentation/devicetree/bindings/pci/fsl,pci.txt
See
https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20250207-ppcyaml-v2-6-8137b0c42...@posteo.net
The base for the series is generally the latest rc1. A different dependency
should be not
On 2/8/25 06:30, J. Neuschäfer via B4 Relay wrote:
> From: "J. Neuschäfer"
>
> Convert the Freescale PowerQUICC SATA controller binding from text form
> to YAML. The list of compatible strings reflects current usage.
>
> To clarify the description, I changed it to mention "each SATA
> controller
From: "J. Neuschäfer"
In some scenarios, such as under the Freescale eLBC bus, there are raw
NAND chips with a unit address that has a comma in it (cs,offset).
Relax the $nodename pattern in raw-nand-chip.yaml to allow such unit
addresses.
Signed-off-by: J. Neuschäfer
---
V2:
- new patch
---
This is a spin-off of the series titled
"powerpc: MPC83xx cleanup and LANCOM NWAPP2 board".
During the development of that series, it became clear that many
devicetree bindings for Freescale MPC8xxx platforms are still in the old
plain-text format, or don't exist at all, and in any case don't ment
On Fri, Feb 07, 2025 at 10:30:17PM +0100, J. Neuschäfer via B4 Relay wrote:
> This is a spin-off of the series titled
> "powerpc: MPC83xx cleanup and LANCOM NWAPP2 board".
> During the development of that series, it became clear that many
> devicetree bindings for Freescale MPC8xxx platforms are
From: "J. Neuschäfer"
Formalize the binding already supported by the fsl_elbc_nand.c driver
and used in several device trees in arch/powerpc/boot/dts/.
Signed-off-by: J. Neuschäfer
---
V2:
- split out from fsl,elbc binding patch
- constrain #address-cells and #size-cells
- add a general descri
From: "J. Neuschäfer"
The devicetree bindings for Freescale DMA engines have so far existed as
a text file. This patch converts them to YAML, and specifies all the
compatible strings currently in use in arch/powerpc/boot/dts.
Signed-off-by: J. Neuschäfer
---
V2:
- remove unnecessary multiline
From: "J. Neuschäfer"
Convert mpc83xx-wdt.txt to YAML to enable automatic schema validation.
Reviewed-by: Rob Herring (Arm)
Signed-off-by: J. Neuschäfer
---
V2:
- trim subject line (remove "binding")
- fix property order to comply with dts coding style
---
.../devicetree/bindings/watchdog/mp
From: "J. Neuschäfer"
fsl-spi.txt contains the bindings for the fsl,spi and fsl,espi
contollers. Convert them to YAML.
Signed-off-by: J. Neuschäfer
---
V2:
- add missing end-of-document ("...") markers
- add missing constraints to interrupts, fsl,espi-num-chipselects,
fsl,csbef and fsl,csaft
From: "J. Neuschäfer"
Convert the Freescale security engine (crypto accelerator) binding from
text form to YAML. The list of compatible strings reflects what was
previously described in prose; not all combinations occur in existing
devicetrees.
Signed-off-by: J. Neuschäfer
---
V2:
- several im
From: "J. Neuschäfer"
Formalize the binding already supported by the uio_fsl_elbc_gpcm.c
driver.
Signed-off-by: J. Neuschäfer
---
V2:
- split out from fsl,elbc patch
- add description
- remove "device_type" property
- move to bindings/memory-controllers
---
.../memory-controllers/fsl,elbc-gpc
From: "J. Neuschäfer"
Formalise the binding for the PCI controllers in the Freescale MPC8xxx
chip family. Information about PCI-X-specific properties was taken from
fsl,pci.txt. The examples were taken from mpc8315erdb.dts and
xpedite5200_xmon.dts.
Signed-off-by: J. Neuschäfer
---
V2:
- merge
From: "J. Neuschäfer"
Convert the Freescale PowerQUICC SATA controller binding from text form
to YAML. The list of compatible strings reflects current usage.
To clarify the description, I changed it to mention "each SATA
controller" instead of each port.
Reviewed-by: Rob Herring (Arm)
Signed-o
From: "J. Neuschäfer"
Add a new binding for MPC83xx platforms, describing the board compatible
strings used in currently existing device trees.
Note that the SoC bus is called immr@... in many existing devicetrees,
but this contradicts the simple-bus binding.
Reviewed-by: Rob Herring (Arm)
Sig
From: "J. Neuschäfer"
Convert mcu-mpc8349emitx.txt to YAML and list the compatible strings
currently in use.
Reviewed-by: Rob Herring (Arm)
Signed-off-by: J. Neuschäfer
---
V2:
- trim subject line (remove "binding")
- fix property order to comply with dts coding style
---
.../bindings/mfd/fs
From: "J. Neuschäfer"
Convert the Freescale localbus controller bindings from text form to
YAML. The updated list of compatible strings reflects current usage
in arch/powerpc/boot/dts/, except that many existing device trees
erroneously specify "simple-bus" in addition to fsl,*elbc.
Changes comp
Move some tests into `bitmap_test_cases` and parameterize
`test_bitmap_print_buf`. This gives us nicer output in the event of a
failure.
Signed-off-by: Tamir Duberstein
---
lib/bitmap_kunit.c | 182 ++---
1 file changed, 89 insertions(+), 93 deleti
Convert the bitmap() self-test to a KUnit test.
In the interest of keeping the patch reasonably-sized this doesn't
refactor the tests into proper parameterized tests - it's all one big
test case.
Signed-off-by: Tamir Duberstein
---
MAINTAINERS | 2 +-
arch/m68k/confi
This has been unused since commit 3aa56885e516 ("bitmap: replace
bitmap_{from,to}_u32array") in 2018. Remove it to avoid the need to port
it to KUnit in this series.
Signed-off-by: Tamir Duberstein
---
lib/test_bitmap.c | 28
1 file changed, 28 deletions(-)
diff --g
I find
no evidence that bitmap in particular is actually testing the running
kernel; it is a unit test of the bitmap functions, which is also stated
in the config help text.
David Gow made many of the same points in his final reply[4], which was
never replied to.
Link:
https://lore.kernel.org
PCIe r6.0 added Flit mode that mainly alters HW behavior but some OS
visible changes are also because of it. The OS visible changes include
differences in the layout of some capabilities and interpretation of
the TLP headers (in diagnostics situations).
To be able to determine which mode the PCIe
Flit mode introduced in PCIe r6.0 alters how the TLP Header Log is
presented through AER and DPC Capability registers. The TLP Prefix Log
Register is not present with Flit mode and the register becomes
extension for TLP Header Log (PCIe r6.1 secs 7.8.4.12 & 7.9.14.13).
Adapt pcie_read_tlp_log() an
This series adds support for Flit Mode (PCIe6).
v2:
- Rebased
Ilpo Järvinen (2):
PCI: Track Flit Mode Status & print it with link status
PCI: Handle TLP Log in Flit mode
drivers/pci/hotplug/pciehp_hpc.c | 5 +--
drivers/pci/pci.c| 12 ---
drivers/pci/pci.h
On Thu, Feb 6, 2025 at 7:22 PM David Hildenbrand wrote:
>
> On 06.02.25 15:59, Albert Esteve wrote:
> > Hi!
> >
> > On Thu, Feb 6, 2025 at 3:30 PM Stefan Hajnoczi wrote:
> >>
> >> On Thu, Feb 06, 2025 at 08:37:07AM -0500, Vivek Goyal wrote:
> >>> And then there are challenges at QEMU level. virti
Hi Zekun,
On Fri, Feb 07, 2025 at 07:28:23PM +0800, zhangzekun (A) wrote:
> 在 2025/2/7 16:24, Oleksij Rempel 写道:
> > On Fri, Feb 07, 2025 at 09:31:09AM +0800, Zhang Zekun wrote:
> >> There are many drivers use of_find_node_by_name() with a not-NULL
> >> device_node pointer, and a number of callers
On Thu, Feb 06, 2025 at 06:12:47PM +0530, Mukesh Kumar Savaliya wrote:
> neat: subject: since binding is already mentioned in the prefix of the
> subject, no need to add bindings word again.
Sounds reasonable, thanks
J. Neuschäfer
在 2025/2/7 16:24, Oleksij Rempel 写道:
On Fri, Feb 07, 2025 at 09:31:09AM +0800, Zhang Zekun wrote:
There are many drivers use of_find_node_by_name() with a not-NULL
device_node pointer, and a number of callers would require a call to
of_node_get() before using it. There are also some drivers w
On Thu, 2025-02-06 at 11:59 +0100, Thomas Weißschuh wrote:
> On Thu, Feb 06, 2025 at 09:31:42AM +, David Woodhouse wrote:
> > On Tue, 2025-02-04 at 13:05 +0100, Thomas Weißschuh wrote:
> > > Currently each architecture defines the setup of the vDSO data page on
> > > its own, mostly through cop
The irq handler is registered for error port which recevie DPC
interrupt. Rename pdev to err_port.
No functional changes.
Signed-off-by: Shuai Xue
---
drivers/pci/pcie/dpc.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/pci/pcie/dpc.c b/drivers/pci/pcie/
changes since v2:
- moving the "err_port" rename to a separate patch per Sathyanarayanan
- rewrite comments of dpc_process_error per Sathyanarayanan
- remove NULL initialization for err_dev per Sathyanarayanan
changes since v1:
- rewrite commit log per Bjorn
- refactor aer_get_device_error_info to
The AER driver has historically avoided reading the configuration space of
an endpoint or RCiEP that reported a fatal error, considering the link to
that device unreliable. Consequently, when a fatal error occurs, the AER
and DPC drivers do not report specific error types, resulting in logs like:
The current implementation of pcie_do_recovery() assumes that the
recovery process is executed on the device that detected the error.
However, the DPC driver currently passes the error port that experienced
the DPC event to pcie_do_recovery().
Use the SOURCE ID register to correctly identify the d
acpi_dpc_port_get() locate the port that experienced the containment
event. Rename edev to err_port for clear so that later patch will avoid
misused err_port in pcie_do_recovery().
No functional changes.
Suggested-by: Sathyanarayanan Kuppuswamy
Signed-off-by: Shuai Xue
---
drivers/pci/pcie/e
Hi Oleksij,
On Fri, Feb 07, 2025 at 09:24:10AM +0100, Oleksij Rempel wrote:
> On Fri, Feb 07, 2025 at 09:31:09AM +0800, Zhang Zekun wrote:
> > There are many drivers use of_find_node_by_name() with a not-NULL
> > device_node pointer, and a number of callers would require a call to
> > of_node_get(
On Fri, Feb 07, 2025 at 09:31:09AM +0800, Zhang Zekun wrote:
> There are many drivers use of_find_node_by_name() with a not-NULL
> device_node pointer, and a number of callers would require a call to
> of_node_get() before using it. There are also some drivers who forget
> to call of_node_get() whi
50 matches
Mail list logo
