On 2023-03-21 10:24:36, Kautuk Consul wrote:
> > Is r4 there only used for CONFIG_KVM_BOOK3S_HV_P8_TIMING? Could put it
> > under there. Although you then lose the barrier if it's disabled, that
> > is okay if you're sure that's the only memory operation being ordered.
> r4 is also used by the seco
Date: Tue, 21 Mar 2023 11:26:32 +0100
A few update suggestions were taken into account
from static source code analysis.
Markus Elfring (2):
Do not pass an error pointer to of_node_put()
Fix exception handling
arch/powerpc/platforms/pseries/reconfig.c | 26 ---
1 file ch
Timothy Pearson writes:
> - Original Message -
>> From: "Timothy Pearson"
>> To: "Michael Ellerman"
>> Cc: "Timothy Pearson" , "kvm"
>> , "linuxppc-dev"
>>
>> Sent: Thursday, March 9, 2023 1:28:20 PM
>> Subject: Re: [PATCH v2 0/4] Reenable VFIO support on POWER systems
>
>> - Origi
Date: Tue, 21 Mar 2023 10:30:23 +0100
It can be determined in the implementation of the function
“pSeries_reconfig_add_node” that an error code would occasionally
be provided by a call of a function like pseries_of_derive_parent().
This error indication was passed to an of_node_put() call accordin
Date: Tue, 21 Mar 2023 10:50:08 +0100
The label “out_err” was used to jump to another pointer check despite of
the detail in the implementation of the function “pSeries_reconfig_add_node”
that it was determined already that the corresponding variable contained
a null pointer (because of a failed f
DT-based MIPS doesn't use OF_DMA_DEFAULT_COHERENT, but
might override the system-wide default at runtime.
Use dma_default_coherent to override default coherence for
MIPS.
Signed-off-by: Jiaxun Yang
---
drivers/of/address.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/of/a
Hi all,
This series split out second half of my previous series
"[PATCH 0/4] MIPS DMA coherence fixes".
It intends to use dma_default_coherent to determine the default coherency of
devicetree probed devices instead of hardcoding it with Kconfig options.
For some MIPS systems, dma_default_coheren
dma_default_coherent was decleared unconditionally at kernel/dma/mapping.c
but only decleared when any of non-coherent options is enabled in
dma-map-ops.h.
Guard the declaration in mapping.c with non-coherent options and provide
a fallback definition.
Signed-off-by: Jiaxun Yang
---
v3: Style fix
Provide a kconfig option to allow arches to manipulate default
value of dma_default_coherent in Kconfig.
Signed-off-by: Jiaxun Yang
---
v3: Add comments
---
kernel/dma/Kconfig | 7 +++
kernel/dma/mapping.c | 2 +-
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/kernel/dma/Kco
As for now all arches have dma_default_coherent reflecting default
DMA coherency for of devices, so there is no need to have a standalone
config option.
Signed-off-by: Jiaxun Yang
---
v3: Squash setting ARCH_DMA_DEFAULT_COHERENT into this patch.
---
arch/powerpc/Kconfig | 2 +-
arch/riscv/Kconf
- Original Message -
> From: "Michael Ellerman"
> To: "Timothy Pearson" , "Timothy Pearson"
>
> Cc: "kvm" , "linuxppc-dev"
>
> Sent: Tuesday, March 21, 2023 5:33:57 AM
> Subject: Re: [PATCH v2 0/4] Reenable VFIO support on POWER systems
> Timothy Pearson writes:
>> - Original
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: f3594f0204b756638267242e26d9de611435c3ba Add linux-next specific
files for 20230321
Error/Warning reports:
https://lore.kernel.org/oe-kbuild-all/202303082135.njdx1bij-...@intel.com
https
This adds support for the Lynx 10G SerDes found on the QorIQ T-series
and Layerscape series. Due to limited time and hardware, only support
for the LS1046ARDB and LS1088ARDB is added in this initial series.
This series is ready for review by the phy maintainers. I have addressed
all known feedback
This adds some modes necessary for Lynx 10G support. 2500BASE-X, also
known as 2.5G SGMII, is 1000BASE-X/SGMII overclocked to 3.125 GHz, with
autonegotiation disabled. 10GBASE-R, also known as XFI, is the protocol
spoken between the PMA and PMD ethernet layers for 10GBASE-T and
10GBASE-S/L/E. It is
This adds a binding for the SerDes module found on QorIQ processors.
Each phy is a subnode of the top-level device, possibly supporting
multiple lanes and protocols. This "thick" #phy-cells is used due to
allow for better organization of parameters. Note that the particular
parameters necessary to
This adds ids for the Lynx 10g SerDes's internal PLLs. These may be used
with assigned-clock* to specify a particular frequency to use. For
example, to set the second PLL (at offset 0x20)'s frequency, use
LYNX10G_PLLa(1). These are for use only in the device tree, and are not
otherwise used by the
NXP has a "QIXIS" FPGA on several of their reference design boards. On
the LS1088ARDB there are several registers which control GPIOs. These
can be modeled with the MMIO GPIO driver.
Signed-off-by: Sean Anderson
Reviewed-by: Rob Herring
---
(no changes since v10)
Changes in v10:
- New
.../de
This adds support for the Lynx 10G "SerDes" devices found on various NXP
QorIQ SoCs. There may be up to four SerDes devices on each SoC, each
supporting up to eight lanes. Protocol support for each SerDes is highly
heterogeneous, with each SoC typically having a totally different
selection of suppo
This is a generic binding for simple MMIO GPIO controllers. Although we
have a single driver for these controllers, they were previously spread
over several files. Consolidate them. The register descriptions are
adapted from the comments in the source. There is no set order for the
registers, and s
This adds support for the PLLs found in Lynx 10G "SerDes" devices found on
various NXP QorIQ SoCs. There are two PLLs in each SerDes. This driver has
been split from the main PHY driver to allow for better review, even though
these PLLs are not present anywhere else besides the SerDes. An auxiliary
The next few patches will break ethernet if the serdes is not enabled,
so enable the serdes driver by default on Layerscape.
Signed-off-by: Sean Anderson
---
(no changes since v10)
Changes in v10:
- New
drivers/phy/freescale/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/
This adds nodes for the SerDes devices. They are disabled by default
to prevent any breakage on existing boards.
Signed-off-by: Sean Anderson
---
(no changes since v10)
Changes in v10:
- Move serdes bindings to SoC dtsi
- Add support for all (ethernet) serdes modes
- Refer to "nodes" instead of
This adds appropriate descriptions for the macs which use the SerDes. The
156.25MHz fixed clock is a crystal. The 100MHz clocks (there are
actually 3) come from a Renesas 6V49205B at address 69 on i2c0. There is
no driver for this device (and as far as I know all you can do with the
100MHz clocks i
This adds nodes for the SerDes devices. They are disabled by default
to prevent any breakage on existing boards.
Signed-off-by: Sean Anderson
---
(no changes since v10)
Changes in v10:
- Move serdes bindings to SoC dtsi
- Add support for all (ethernet) serdes modes
- Refer to "nodes" instead of
This adds serdes support to the LS1088ARDB. I have tested the QSGMII
ports as well as the two 10G ports. The SFP slot is now fully supported,
instead of being modeled as a fixed-link.
Linux hangs around when the serdes is initialized if the si5341 is
enabled with the in-tree driver, so I have mode
The internal PCSs are not always accessible during boot (such as if the
serdes has deselected the appropriate link mode). Give them appropriate
compatible strings so they don't automatically (fail to) probe as
genphys.
Signed-off-by: Sean Anderson
---
(no changes since v8)
Changes in v8:
- New
On 3/21/23 16:13, Sean Anderson wrote:
> This is a generic binding for simple MMIO GPIO controllers. Although we
> have a single driver for these controllers, they were previously spread
> over several files. Consolidate them. The register descriptions are
> adapted from the comments in the source.
On Wed, 15 Mar 2023 16:04:52 +0100, Uwe Kleine-König wrote:
> this series adapts the platform drivers below sound/ to use the .remove_new()
> callback. Compared to the traditional .remove() callback .remove_new() returns
> no value. This is a good thing because the driver core doesn't (and cannot)
Timothy Pearson writes:
> - Original Message -
>> From: "Michael Ellerman"
>> To: "Timothy Pearson" , "Timothy Pearson"
>>
>> Cc: "kvm" , "linuxppc-dev"
>>
>> Sent: Tuesday, March 21, 2023 5:33:57 AM
>> Subject: Re: [PATCH v2 0/4] Reenable VFIO support on POWER systems
>
>> Timothy Pe
On Tue, 21 Mar 2023 16:13:02 -0400, Sean Anderson wrote:
> This is a generic binding for simple MMIO GPIO controllers. Although we
> have a single driver for these controllers, they were previously spread
> over several files. Consolidate them. The register descriptions are
> adapted from the com
In mpc5xxx_fwnode_get_bus_frequency(), we should add
fwnode_handle_put() when break out of the iteration
fwnode_for_each_parent_node() as it will automatically
increase and decrease the refcounter.
Fixes: de06fba62af6 ("powerpc/mpc5xxx: Switch mpc5xxx_get_bus_frequency() to
use fwnode")
Signed-of
fail_iommu_setup() registers the fail_iommu_bus_notifier struct to both
PCI and VIO buses. struct notifier_block is a linked list node, so this
causes any notifiers later registered to either bus type to also be
registered to the other since they share the same node.
This causes issues in (at lea
This series is a partial iteration of the RFC [1]. It strips out the dynamic
support and just adds the supporting infrastructure and static DEXCR
configuration. It should therefore not be introducing any new userspace ABI.
I could keep iterating and refactoring, but I figure there's enough
here to
The ISA 3.1B hashst and hashchk instructions use a per-cpu SPR HASHKEYR
to hold a key used in the hash calculation. This key should be different
for each process to make it harder for a malicious process to recreate
valid hash values for a victim process.
Add support for storing a per-thread hash
ISA 3.1B introduces the Dynamic Execution Control Register (DEXCR). It
is a per-cpu register that allows control over various CPU behaviours
including branch hint usage, indirect branch speculation, and
hashst/hashchk support.
Add some definitions and basic support for the DEXCR in the kernel.
Rig
Recognise and pass the appropriate signal to the user program when a
hashchk instruction triggers. This is independent of allowing
configuration of DEXCR[NPHIE], as a hypervisor can enforce this aspect
regardless of the kernel.
The signal mirrors how ARM reports their similar check failure. For
ex
The functions here use struct thread_struct fields, so need to import
the full definition from . The header
that defines current only forward declares struct thread_struct.
Failing to include this header leads to a compilation
error when a translation unit does not also include
indirectly.
Sig
Describe the DEXCR and document how to configure it.
Signed-off-by: Benjamin Gray
---
v1: * Remove the dynamic control docs, describe the static config
option
This documentation is a little bare for now, but will be expanded on
when dynamic DEXCR control is added.
---
Documentat
* Include unistd.h for _exit()
* Include stdio.h for fprintf()
* Adds _MSG assertion variants to provide more context behind why a
failure occurred.
* Move ARRAY_SIZE macro to utils.h
The _MSG variants and ARRAY_SIZE will be used by the following
DEXCR selftests.
Signed-off-by: Benjamin Gray
Add a utility 'lsdexcr' to print the current DEXCR status. Useful for
quickly checking the status such as when debugging test failures or
verifying the new default DEXCR does what you want (for userspace at
least). Example output:
# ./lsdexcr
uDEXCR: 0400 (NPHIE)
HDEXCR:
Test the kernel DEXCR[NPHIE] interface and hashchk exception handling.
Introduces with it a DEXCR utils library for common DEXCR operations.
Volatile is used to prevent the compiler optimising away the signal
tests.
Signed-off-by: Benjamin Gray
---
v1: * Clean up dexcr makefile
* I
Make the DEXCR value configurable at config time. Intentionally don't
limit possible values to support future aspects without needing kernel
updates.
The default config value enables hashst/hashchk in problem state.
This should be safe, as generally software needs to request these
instructions be
On Wed, 2023-03-22 at 14:53 +1100, Russell Currey wrote:
> fail_iommu_setup() registers the fail_iommu_bus_notifier struct to
> both
> PCI and VIO buses. struct notifier_block is a linked list node, so
> this
> causes any notifiers later registered to either bus type to also be
> registered to the
43 matches
Mail list logo
