On Tue, Mar 7, 2023, at 02:30, Baoquan He wrote:
> On 03/07/23 at 11:58am, Michael Ellerman wrote:
>> "Arnd Bergmann" writes:
>> > On Sun, Mar 5, 2023, at 10:29, Geert Uytterhoeven wrote:
>> >> On Sun, Mar 5, 2023 at 10:23 AM Michael Ellerman
>> >> wrote:
>> >>> Maybe that exact code path is onl
On 3/2/23 8:49 AM, Madhavan Srinivasan wrote:
On 3/2/23 3:35 AM, Benjamin Gray wrote:
On Wed, 2023-03-01 at 22:39 +0530, Kajol Jain wrote:
From: Madhavan Srinivasan
event.h header already includes utlis.h. Avoid including
the same explicitly in the code when event.h included.
Signed-off-b
On Tue, 2023-03-07 at 15:30 +1000, Nicholas Piggin wrote:
> On Mon Nov 28, 2022 at 12:44 PM AEST, Benjamin Gray wrote:
> > The DEXCR Speculative Branch Hint Enable (SBHE) aspect controls
> > whether
> > the hints provided by BO field of Branch instructions are obeyed
> > during
> > speculative exec
On Tue, 2023-03-07 at 15:40 +1000, Nicholas Piggin wrote:
> Might need a bit more time and discussion on the API. Interestingly
> because the hashchk aspect is architectural, we may not be able to
> necessarily sanely enable that, because if it was disabled to start
> out with, our callchain up to
On Mon Nov 28, 2022 at 12:44 PM AEST, Benjamin Gray wrote:
> Describe the DEXCR and document how to interact with it via the
> prctl and sysctl interfaces.
Oh you've got the docs here, sorry. Thanks for that. I don't know enough
yet to give much useful feedback on the API. I think at least all the
On Tue, 2023-03-07 at 15:05 +1000, Nicholas Piggin wrote:
> I think it is not quite per-process? I don't actually know how the
> user
> toolchain side is put together, but I'm thinking we can not give it a
> new
> salt on fork(), but we could on exec(). I think we could actually
> give
> each threa
On Mon Nov 28, 2022 at 12:44 PM AEST, Benjamin Gray wrote:
> The DEXCR Speculative Branch Hint Enable (SBHE) aspect controls whether
> the hints provided by BO field of Branch instructions are obeyed during
> speculative execution.
>
> SBHE behaviour per ISA 3.1B:
>
> 0:The hints provided by BO
On Mon Nov 28, 2022 at 12:44 PM AEST, Benjamin Gray wrote:
> Adds an initial prctl interface implementation. Unprivileged processes
> can query the current prctl setting, including whether an aspect is
> implemented by the hardware or is permitted to be modified by a setter
> prctl. Editable aspect
On Mon Nov 28, 2022 at 12:44 PM AEST, Benjamin Gray wrote:
> Adds the definitions and generic handler for prctl control of the
> PowerPC Dynamic Execution Control Register (DEXCR).
Assuming we'd go with the later prctl patches, this prep patch
is nice way to split out some of the mechanism.
Revie
On Mon Nov 28, 2022 at 12:44 PM AEST, Benjamin Gray wrote:
> 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 value
On Mon Nov 28, 2022 at 12:44 PM AEST, Benjamin Gray wrote:
> 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.
>
> T
On Mon Nov 28, 2022 at 12:44 PM AEST, Benjamin Gray wrote:
> 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
>
On 03/07/23 at 11:58am, Michael Ellerman wrote:
> "Arnd Bergmann" writes:
> > On Sun, Mar 5, 2023, at 10:29, Geert Uytterhoeven wrote:
> >> On Sun, Mar 5, 2023 at 10:23 AM Michael Ellerman
> >> wrote:
> >>> Maybe that exact code path is only reachable on x86/ia64? But if so
> >>> please explain
On Mon, 6 Mar 2023 18:35:22 -0600 (CST)
Timothy Pearson wrote:
> - Original Message -
> > From: "Alex Williamson"
> > To: "Timothy Pearson"
> > Cc: "kvm" , "linuxppc-dev"
> >
> > Sent: Monday, March 6, 2023 5:46:07 PM
> > Subject: Re: [PATCH v2 0/4] Reenable VFIO support on POWER syst
"Arnd Bergmann" writes:
> On Sun, Mar 5, 2023, at 10:29, Geert Uytterhoeven wrote:
>> On Sun, Mar 5, 2023 at 10:23 AM Michael Ellerman wrote:
>>> Maybe that exact code path is only reachable on x86/ia64? But if so
>>> please explain why.
>>>
>>> Otherwise it looks like this series could break tha
The tests currently have a single writer thread updating the system
DSCR with a 1/1000 chance looped only 100 times. So only around one in
10 runs actually do anything.
* Add multiple threads to the dscr_explicit_random_test case.
* Use a barrier to make all the threads start work as simultaneousl
Reducing the time taken by dscr_sysfs_test.c allows restoring the
default timeout, which was removed in
commit 850507f30c38 ("selftests/powerpc: Turn off timeout setting for
benchmarks, dscr, signal, tm") because that test took too long.
Signed-off-by: Benjamin Gray
---
tools/testing/selftests/p
Add new cases to the relevant tests that use explicitly synchronized
threads to test the behaviour across context switches with less
randomness. By locking the participants to the same CPU we guarantee a
context switch occurs each time they make progress, which is a likely
failure point if the kern
Correct a couple of typos while working on other improvements to the
DSCR tests.
Signed-off-by: Benjamin Gray
---
tools/testing/selftests/powerpc/dscr/dscr_explicit_test.c | 4 ++--
tools/testing/selftests/powerpc/dscr/dscr_inherit_test.c | 4 ++--
tools/testing/selftests/powerpc/dscr/dscr_user
This test case is extremely slow, taking around a minute compared to
most of the other DSCR tests taking a second at most. Perf shows most
time is spent by the kernel switching to each CPU it reads in
/sys/devices/system/cpu. This switching is an unavoidable consequnce
of reading all the .../cpuN/d
The randomness based DSCR tests currently have a low probability of doing
any writes to the DSCR, making them inefficient in uncovering bugs.
This series adds lockstep variants to these RNG tests, to ensure the happy
path is always tested, and improves the randomness and size of the RNG
tests.
It
On 07/03/2023 10:46, Alex Williamson wrote:
On Mon, 6 Mar 2023 11:29:53 -0600 (CST)
Timothy Pearson wrote:
This patch series reenables VFIO support on POWER systems. It
is based on Alexey Kardashevskiys's patch series, rebased and
successfully tested under QEMU with a Marvell PCIe SATA con
- Original Message -
> From: "Alex Williamson"
> To: "Timothy Pearson"
> Cc: "kvm" , "linuxppc-dev"
>
> Sent: Monday, March 6, 2023 5:46:07 PM
> Subject: Re: [PATCH v2 0/4] Reenable VFIO support on POWER systems
> On Mon, 6 Mar 2023 11:29:53 -0600 (CST)
> Timothy Pearson wrote:
>
The hypervisor supports user-mode NX from Power10. pseries_vas_dlpar_cpu()
is called from lparcfg_write() to update VAS windows for DLPAR CPU event
and the kernel gets -ENOTSUPP for HCALLs if the user-mode NX is not
supported.
This patch ignores updating VAS capabilities and returns success if t
On Mon, 6 Mar 2023 11:29:53 -0600 (CST)
Timothy Pearson wrote:
> This patch series reenables VFIO support on POWER systems. It
> is based on Alexey Kardashevskiys's patch series, rebased and
> successfully tested under QEMU with a Marvell PCIe SATA controller
> on a POWER9 Blackbird host.
>
> A
Gerald Schaefer writes:
> s390 can do more fine-grained handling of spurious TLB protection faults,
> when there also is the PTE pointer available.
>
> Therefore, pass on the PTE pointer to flush_tlb_fix_spurious_fault() as
> an additional parameter.
>
> This will add no functional change to other
Hi Sean,
thanks for doing this. I never got around to because time.
On Mon, Mar 6, 2023 at 8:16 PM 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. Conso
On Mon, Mar 06, 2023 at 10:50:55PM +0530, Amit Kumar Mahapatra wrote:
> drivers/spi/spi-omap-100k.c | 2 +-
This is also not against -rc1, this file was removed in bcace9c4c9270292
("spi: remove omap 100K driver").
signature.asc
Description: PGP signature
Hi,
On Mon, 6 Mar 2023 at 18:26, Amit Kumar Mahapatra
wrote:
>
> For supporting multiple CS the SPI device need to be aware of all the CS
> values. So, the "chip_select" member in the spi_device structure is now an
> array that holds all the CS values.
>
> spi_device structure now has a "cs_index
On Mon, Mar 06, 2023 at 10:50:55PM +0530, Amit Kumar Mahapatra wrote:
> Supporting multi-cs in spi drivers would require the chip_select & cs_gpiod
> members of struct spi_device to be an array. But changing the type of these
> members to array would break the spi driver functionality. To make the
During GQSPI driver probe set ctlr->multi-cs-cap for enabling multi CS
capability of the controller. In parallel mode the controller can either
split the data between both the flash or can send the same data to both the
flashes, this is determined by the STRIPE bit. While sending commands to
the fl
The current implementation assumes that a maximum of two flashes are
connected in parallel mode. The QSPI controller splits the data evenly
between both the flashes so, both the flashes that are connected in
parallel mode should be identical.
During each operation SPI-NOR sets 0th bit for CS0 & 1st
Each flash that is connected in stacked mode should have a separate
parameter structure. So, the flash parameter member(*params) of the spi_nor
structure is changed to an array (*params[2]). The array is used to store
the parameters of each flash connected in stacked configuration.
The current imp
GQSPI supports two chip select CS0 & CS1. Update the driver to
assert/de-assert the appropriate chip select as per the bits set in
qspi->cs_index_mask.
Signed-off-by: Amit Kumar Mahapatra
---
drivers/spi/spi-zynqmp-gqspi.c | 21 +
1 file changed, 13 insertions(+), 8 deletions
Supporting multi-cs in spi-nor would require the *params member of
struct spi_nor to be an array. To make the transition smoother introduced
spi_nor_get_params() & spi_nor_set_params() APIs to get & set nor->params,
added a new local variable (struct spi_nor_flash_parameter *params) to hold
the ret
In further patches the nor->params references in
spi_nor_otp_region_len(nor) & spi_nor_otp_n_regions(nor) macros will be
replaced with spi_nor_get_params() API. To make the transition smoother,
first converting the macros into static inline functions.
Suggested-by: Michal Simek
Signed-off-by: Ami
For supporting multiple CS the SPI device need to be aware of all the CS
values. So, the "chip_select" member in the spi_device structure is now an
array that holds all the CS values.
spi_device structure now has a "cs_index_mask" member. This acts as an
index to the chip_select array. If nth bit
Supporting multi-cs in spi drivers would require the chip_select & cs_gpiod
members of struct spi_device to be an array. But changing the type of these
members to array would break the spi driver functionality. To make the
transition smoother introduced four new APIs to get/set the
spi->chip_select
Supporting multi-cs in spi drivers would require the chip_select & cs_gpiod
members of struct spi_device to be an array. But changing the type of these
members to array would break the spi driver functionality. To make the
transition smoother introduced four new APIs to get/set the
spi->chip_select
Supporting multi-cs in spi drivers would require the chip_select & cs_gpiod
members of struct spi_device to be an array. But changing the type of these
members to array would break the spi driver functionality. To make the
transition smoother introduced four new APIs to get/set the
spi->chip_select
Supporting multi-cs in spi drivers would require the chip_select & cs_gpiod
members of struct spi_device to be an array. But changing the type of these
members to array would break the spi driver functionality. To make the
transition smoother introduced four new APIs to get/set the
spi->chip_select
Supporting multi-cs in spi drivers would require the chip_select & cs_gpiod
members of struct spi_device to be an array. But changing the type of these
members to array would break the spi driver functionality. To make the
transition smoother introduced four new APIs to get/set the
spi->chip_select
Supporting multi-cs in spi drivers would require the chip_select & cs_gpiod
members of struct spi_device to be an array. But changing the type of these
members to array would break the spi driver functionality. To make the
transition smoother introduced four new APIs to get/set the
spi->chip_select
Supporting multi-cs in spi drivers would require the chip_select & cs_gpiod
members of struct spi_device to be an array. But changing the type of these
members to array would break the spi driver functionality. To make the
transition smoother introduced four new APIs to get/set the
spi->chip_select
Supporting multi-cs in spi drivers would require the chip_select & cs_gpiod
members of struct spi_device to be an array. But changing the type of these
members to array would break the spi driver functionality. To make the
transition smoother introduced four new APIs to get/set the
spi->chip_select
This patch is in the continuation to the discussions which happened on
'commit f89504300e94 ("spi: Stacked/parallel memories bindings")' for
adding dt-binding support for stacked/parallel memories.
This patch series updated the spi-nor, spi core and the spi drivers
to add stacked and parallel memo
From: Nathan Lynch
Add lockdep annotations for the following properties that must hold:
* Any error log retrieval must be atomically coupled with the prior
RTAS call, without a window for another RTAS call to occur before the
error log can be retrieved.
* All users of the core rtas_args par
From: Nathan Lynch
Using memcpy() isn't safe when buf is identical to rtas_err_buf, which
can happen during boot before slab is up. Full context which may not
be obvious from the diff:
if (altbuf) {
buf = altbuf;
} else {
buf = rtas_err_buf;
From: Nathan Lynch
The function name va_rtas_call_unlocked() is confusing: it may be
called with or without rtas_lock held. Rename it to va_rtas_call().
Signed-off-by: Nathan Lynch
---
arch/powerpc/kernel/rtas.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/arch/
From: Nathan Lynch
CHRP and PAPR agree: "In order to make an RTAS call, the operating
system must construct an argument call buffer aligned on an eight byte
boundary in physically contiguous real memory [...]." (7.2.7 Calling
Mechanism and Conventions).
struct rtas_args is the type used for this
Proposed changes for the RTAS subsystem and client code.
Fixes that are subject to backporting are at the front of the queue,
followed by documentation and cleanups, with enhancements at the end.
Noteworthy changes:
* Change sys_rtas() to consume -2/990x statuses instead of returning
them to us
From: Nathan Lynch
The kernel can handle retrying RTAS function calls in response to
-2/990x in the sys_rtas() handler instead of relaying the intermediate
status to user space.
Justifications:
* Currently it's nondeterministic and quite variable in practice
whether a retry status is returned
From: Nathan Lynch
Add documentation for rtas_call_unlocked(), including details on how
it differs from rtas_call().
Signed-off-by: Nathan Lynch
---
arch/powerpc/kernel/rtas.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/arch/powerpc/kernel/rtas.c b/arch/powerpc/kerne
From: Nathan Lynch
Any caller of rtas_call_unlocked() must provide an rtas_args parameter
block distinct from the core rtas_args buffer used by the rtas_call()
path. It's an unlikely error to make, but the potential consequences
are grim, and it's trivial to check.
Signed-off-by: Nathan Lynch
-
From: Nathan Lynch
The 'filter' member is a pointer, not a bool; fix the wording
accordingly.
Signed-off-by: Nathan Lynch
---
arch/powerpc/kernel/rtas.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/rtas.c b/arch/powerpc/kernel/rtas.c
index c73b01d722f
On 3/6/23 15:51, Jonas Gorski wrote:
> Hi,
>
> On Mon, 6 Mar 2023 at 20:16, 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 re
Hi,
On Mon, 6 Mar 2023 at 20:16, 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 comm
On Mon, Feb 27, 2023 at 9:37 AM Suren Baghdasaryan wrote:
>
> From: Laurent Dufour
>
> Attempt VMA lock-based page fault handling first, and fall back to the
> existing mmap_lock-based handling if that fails.
> Copied from "x86/mm: try VMA lock-based page fault handling first"
Hi Andrew,
Laurent
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
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
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
This adds nodes for the SerDes devices. They are disabled by default
to prevent any breakage on existing boards.
Signed-off-by: Sean Anderson
---
Changes in v10:
- Move serdes bindings to SoC dtsi
- Add support for all (ethernet) serdes modes
- Refer to "nodes" instead of "bindings"
- Move compa
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
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
---
Changes in v10:
- New
drivers/phy/freescale/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/phy/freescale/Kconfig b/
This adds nodes for the SerDes devices. They are disabled by default
to prevent any breakage on existing boards.
Signed-off-by: Sean Anderson
---
Changes in v10:
- Move serdes bindings to SoC dtsi
- Add support for all (ethernet) serdes modes
- Refer to "nodes" instead of "bindings"
- Move compa
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
---
Changes in v10:
- New
.../devicetree/bindings/gpio/gpio-mmio.yaml| 14
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 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
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 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, so I
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 based on phy/next, but it requires phylink support. This
is already present
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
Drop the union for the pages_{4k,2m,1g} stats. The union is no longer
necessary now that KVM supports choosing a custom name for stats.
Eliminating the union also would allow future commits to more easily
move pages[] into common code, e.g. if KVM ever gains support for a
common page table code.
Allow custom names to be specified for stats built on KVM_STAT() via a
new inner macro __KVM_STAT(). e.g.
KVM_STAT(VM, CUMULATIVE, NONE, foo),
__KVM_STAT(VM, CUMULATIVE, NONE, bar, "custom_name"),
...
Custom name support enables decoupling the userspace-visible stat names
from their interna
Refactor the various KVM stats macros to reduce the amount of duplicate
macro code. This change also improves readability by spelling out
"CUMULATIVE", "INSTANT", and "PEAK" instead of the previous short-hands
which were less clear ("COUNTER", "ICOUNTER", and "PCOUNTER").
No functional change inte
Refactor the macros that generate struct _kvm_stats_desc designated
initializers to cut down on duplication.
No functional change intended.
Signed-off-by: David Matlack
---
include/linux/kvm_host.h | 75 +++-
1 file changed, 35 insertions(+), 40 deletions(-)
This series refactors the KVM stats macros to reduce duplication and
adds the support for choosing custom names for stats.
Custom name makes it possible to decouple the userspace-visible stat
names from their internal representation in C. This can allow future
commits to refactor the various stats
On Mon, 6 Mar 2023 17:06:44 +
Catalin Marinas wrote:
> On Mon, Mar 06, 2023 at 05:15:48PM +0100, Gerald Schaefer wrote:
> > diff --git a/arch/arm64/include/asm/pgtable.h
> > b/arch/arm64/include/asm/pgtable.h
> > index b6ba466e2e8a..0bd18de9fd97 100644
> > --- a/arch/arm64/include/asm/pgtabl
This patch series reenables VFIO support on POWER systems. It
is based on Alexey Kardashevskiys's patch series, rebased and
successfully tested under QEMU with a Marvell PCIe SATA controller
on a POWER9 Blackbird host.
Alexey Kardashevskiy (3):
powerpc/iommu: Add "borrowing" iommu_table_group_o
PPC64 IOMMU API defines iommu_table_group_ops which handles DMA windows
for PEs: control the ownership, create/set/unset a table the hardware
for dynamic DMA windows (DDW). VFIO uses the API to implement support
on POWER.
So far only PowerNV IODA2 (POWER8 and newer machines) implemented this and
The following patches are going to add dependency/use of iommu_ops which
is initialized in subsys_initcall as well.
This moves pciobios_init() to the next initcall level.
This should not cause behavioral change.
Signed-off-by: Alexey Kardashevskiy
Signed-off-by: Timothy Pearson
---
arch/power
dependent
When introduced, IRQFD resampling worked on POWER8 with XICS. However
KVM on POWER9 has never implemented it - the compatibility mode code
("XICS-on-XIVE") misses the kvm_notify_acked_irq() call and the native
XIVE mode does not handle INTx in KVM at all.
This moved the capability supp
Signed-off-by: Timothy Pearson
---
MAINTAINERS | 5 +
1 file changed, 5 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 8d5bc223f305..876f96e82d66 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9836,6 +9836,11 @@ F: drivers/crypto/vmx/ghash*
F: drivers/crypto/vmx/ppc-xl
allow blocking domains
Up until now 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 added 2 uses of iommu_ops to
the generic VFIO which broke POWER:
- a coherency capability check;
-
On Mon, Mar 6, 2023 at 6:09 AM Laurent Dufour wrote:
>
> On 06/03/2023 15:07:26, David Hildenbrand wrote:
> > On 06.03.23 14:55, Laurent Dufour wrote:
> >> When page fault is tried holding the per VMA lock, bad_access_pkey() and
> >> bad_access() should not be called because it is assuming the mma
On Mon, Mar 06, 2023 at 05:15:48PM +0100, Gerald Schaefer wrote:
> diff --git a/arch/arm64/include/asm/pgtable.h
> b/arch/arm64/include/asm/pgtable.h
> index b6ba466e2e8a..0bd18de9fd97 100644
> --- a/arch/arm64/include/asm/pgtable.h
> +++ b/arch/arm64/include/asm/pgtable.h
> @@ -57,7 +57,7 @@ stat
On Mon, Mar 06, 2023 at 05:17:44PM +0100, Herve Codina wrote:
> Hi,
>
> This series adds support for audio using the QMC controller available in
> some Freescale PowerQUICC SoCs.
>
> This series contains three parts in order to show the different blocks
> hierarchy and their usage in this support
After contributing the component, add myself as the maintainer for the
Freescale QMC audio ASoC component.
Signed-off-by: Herve Codina
Reviewed-by: Christophe Leroy
---
MAINTAINERS | 8
1 file changed, 8 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 5597d402fbd8..a6e6b70c
The QMC audio is an ASoC component which provides DAIs that use the QMC
(QUICC Multichannel Controller) to transfer the audio data.
It provides as many DAIs as the number of QMC channels it references.
Signed-off-by: Herve Codina
Reviewed-by: Christophe Leroy
Tested-by: Christophe Leroy
---
s
The QMC (QUICC mutichannel controller) is a controller present in some
PowerQUICC SoC such as MPC885.
The QMC audio is an ASoC component that uses the QMC controller to
transfer the audio data.
Signed-off-by: Herve Codina
Reviewed-by: Krzysztof Kozlowski
Reviewed-by: Christophe Leroy
---
.../b
After contributing the driver, add myself as the maintainer for the
Freescale QMC controller.
Signed-off-by: Herve Codina
Reviewed-by: Christophe Leroy
---
MAINTAINERS | 8
1 file changed, 8 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index fea9ee7ade8e..5597d402fbd8 100644
-
The QMC (QUICC Multichannel Controller) emulates up to 64
channels within one serial controller using the same TDM
physical interface routed from the TSA.
It is available in some PowerQUICC SoC such as the
MPC885 or MPC866.
It is also available on some Quicc Engine SoCs.
This current version supp
Add support for the QMC (QUICC Multichannel Controller) available in
some PowerQUICC SoC such as MPC885 or MPC866.
Signed-off-by: Herve Codina
Reviewed-by: Krzysztof Kozlowski
Reviewed-by: Christophe Leroy
---
.../soc/fsl/cpm_qe/fsl,cpm1-scc-qmc.yaml | 162 ++
1 file chang
The CPM1 command mask is defined for use with the standard
CPM1 command register as described in the user's manual:
0 |13|47|8 11|12 14| 15|
RST|- |OPCODE|CH_NUM| -|FLG|
In the QMC extension the CPM1 command register is redefined
(QMC supplement user's manue
After contributing the driver, add myself as the maintainer for the
Freescale TSA controller.
Signed-off-by: Herve Codina
Reviewed-by: Christophe Leroy
---
MAINTAINERS | 9 +
1 file changed, 9 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 8d5bc223f305..fea9ee7ade8e 100644
The TSA (Time Slot Assigner) purpose is to route some TDM time-slots to
other internal serial controllers.
It is available in some PowerQUICC SoC such as the MPC885 or MPC866.
It is also available on some Quicc Engine SoCs.
This current version support CPM1 SoCs only and some enhancement are
need
Add support for the time slot assigner (TSA) available in some
PowerQUICC SoC such as MPC885 or MPC866.
Signed-off-by: Herve Codina
Reviewed-by: Christophe Leroy
---
.../bindings/soc/fsl/cpm_qe/fsl,cpm1-tsa.yaml | 205 ++
include/dt-bindings/soc/cpm1-fsl,tsa.h| 13 ++
2
Hi,
This series adds support for audio using the QMC controller available in
some Freescale PowerQUICC SoCs.
This series contains three parts in order to show the different blocks
hierarchy and their usage in this support.
The first one is related to TSA (Time Slot Assigner).
The TSA handles the
s390 can do more fine-grained handling of spurious TLB protection faults,
when there also is the PTE pointer available.
Therefore, pass on the PTE pointer to flush_tlb_fix_spurious_fault() as
an additional parameter.
This will add no functional change to other architectures, but those with
privat
When page fault is tried holding the per VMA lock, bad_access_pkey() and
bad_access() should not be called because it is assuming the mmap_lock is
held.
In the case a bad access is detected, fall back to the default path,
grabbing the mmap_lock to handle the fault and report the error.
Fixes: 169d
1 - 100 of 140 matches
Mail list logo
