The pseries platform can support dynamic secure boot (i.e. secure boot
using user-defined keys) using variables contained with the PowerVM LPAR
Platform KeyStore (PLPKS). Using the powerpc secvar API, expose the
relevant variables for pseries dynamic secure boot through the existing
secvar
The forthcoming pseries consumer of the secvar API wants to expose a
number of config variables. Allowing secvar implementations to provide
their own sysfs attributes makes it easy for consumers to expose what
they need to.
This is not being used by the OPAL secvar implementation at present, and
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 functional change.
Signed-off-by: Russell Currey
---
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
---
arch/powerpc/include/asm/secvar.h| 1 +
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
---
v2: new
arch/powerpc/kernel/secvar-sysfs.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
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
---
arch/powerpc/kernel/secvar-ops.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
Changes in v2:
Remove unnecessary config vars from sysfs and document the others,
thanks to review from Greg. If we end up needing to expose more, we
can add them later and update the docs.
Use sysfs_emit() instead of sprintf() for all sysfs strings
Change the size of the
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 information from the conversion.
Signed-off-by: Russell Currey
---
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
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:
-
This adds bindings for the SerDes devices. They are disabled by default
to prevent any breakage on existing boards.
Signed-off-by: Sean Anderson
---
(no changes since v4)
Changes in v4:
- Convert to new bindings
Changes in v3:
- New
arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi | 18
This adds appropriate bindings 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 is
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
This adds bindings for the SerDes devices. They are disabled by default
to prevent any breakage on existing boards.
Signed-off-by: Sean Anderson
---
(no changes since v4)
Changes in v4:
- Convert to new bindings
Changes in v3:
- Describe modes in device tree
Changes in v2:
- Use one phy cell
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
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
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
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 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
On 12/28/22 12:22, Marc Zyngier wrote:
Queued, thanks. I will leave this in kvm/queue after testing everything
else and moving it to kvm/next; this way, we can wait for test results
on other architectures.
Can you please make this a topic branch, and if possible based
on a released -rc? It
On Wed, Dec 28, 2022 at 03:51:29PM +0100, Uwe Kleine-König wrote:
> The four exported functions mpc52xx_lpbfifo_submit(),
> mpc52xx_lpbfifo_abort(), mpc52xx_lpbfifo_poll(), and
> mpc52xx_lpbfifo_start_xfer() are not used. So they can be dropped and the
> definitions needed to call them can be
On Fri, 16 Dec 2022 11:20:12 PST (-0800), mike.krav...@oracle.com 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
On Thu, 22 Dec 2022 03:46:29 PST (-0800), andrzej.ha...@intel.com wrote:
__xchg will be used for non-atomic xchg macro.
Signed-off-by: Andrzej Hajda
---
arch/riscv/include/asm/atomic.h | 2 +-
arch/riscv/include/asm/cmpxchg.h | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff
On Wed, 21 Dec 2022 15:51:47 PST (-0800), mask...@google.com wrote:
The actual intention is that no dynamic relocation exists. However, some
GNU ld ports produce unneeded R_*_NONE. (If a port fails to determine
the exact .rel[a].dyn size, the trailing zeros become R_*_NONE
relocations. E.g. ld's
__xchg will be used for non-atomic xchg macro.
Signed-off-by: Andrzej Hajda
Reviewed-by: Arnd Bergmann
---
arch/alpha/include/asm/cmpxchg.h | 6 +++---
arch/arc/include/asm/cmpxchg.h | 4 ++--
arch/arm/include/asm/cmpxchg.h | 4 ++--
arch/arm64/include/asm/cmpxchg.h | 4
Forgive me late response - Holidays,
On 22.12.2022 18:21, Andrew Morton wrote:
On Thu, 22 Dec 2022 12:46:16 +0100 Andrzej Hajda
wrote:
Hi all,
I hope there will be place for such tiny helper in kernel.
Quick cocci analyze shows there is probably few thousands places
where it could be
On Thu, Dec 22, 2022, at 12:46, Andrzej Hajda wrote:
> __xchg will be used for non-atomic xchg macro.
>
> Signed-off-by: Andrzej Hajda
> ---
> arch/arc/include/asm/cmpxchg.h | 4 ++--
Reviewed-by: Arnd Bergmann
for all the arch/*/include/asm/cmpxchg.h changes.
Since these patches are all the
27 matches
Mail list logo
