-mprofile-kernel is an optimised calling convention for mcount that
Linux has only implemented with the ELFv2 ABI, so it was disabled for
big endian kernels. However it does work with ELFv2 big endian, so let's
allow that if the compiler supports it.
Cc: Naveen N. Rao
Suggested-by: Christophe Le
When CONFIG_SMP is not set, CONFIG_BROKEN_ON_SMP is set, and
CONFIG_PCI is not set, there can be a kconfig warning:
WARNING: unmet direct dependencies detected for PPC_INDIRECT_PCI
Depends on [n]: PCI [=n]
Selected by [y]:
- MPC10X_BRIDGE [=y]
To fix that, make the selects of MPC10X_BRIDGE
Hi Nick,
+ our mailing list, helps with review and making sure that we are not
missing anything :)
On Fri, May 05, 2023 at 05:18:47PM +1000, Nicholas Piggin wrote:
> The LLVM linker does not support ELFv1 at all, so BE kernels must be
> built with ELFv2. The LLD version check was added to be cons
From: Greg Joyce
Generic functions have been defined for accessing SED Opal keys.
The generic functions are defined as weak so that they may be superseded
by keystore specific versions.
PowerPC/pseries versions of these functions provide read/write access
to SED Opal keys in the PLPKS keystore.
From: Greg Joyce
Define operations for SED Opal to read/write keys
from POWER LPAR Platform KeyStore(PLPKS). This allows
non-volatile storage of SED Opal keys.
Signed-off-by: Greg Joyce
Reviewed-by: Jonathan Derrick
---
arch/powerpc/platforms/pseries/Makefile | 1 +
.../powerpc/platfo
From: Greg Joyce
Changes to the PLPKS API require minor updates to the SED Opal
PLPKS keystore code.
Signed-off-by: Greg Joyce
---
arch/powerpc/platforms/pseries/Kconfig| 6 +
arch/powerpc/platforms/pseries/Makefile | 2 +-
.../powerpc/platforms/pseries/plpks_sed_ops.c | 22
From: Greg Joyce
Allow for permanent SED authentication keys by
reading/writing to the SED Opal non-volatile keystore.
Signed-off-by: Greg Joyce
Reviewed-by: Jonathan Derrick
---
block/sed-opal.c | 18 --
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/block/sed
From: Greg Joyce
Add read and write functions that allow SED Opal keys to stored
in a permanent keystore.
Signed-off-by: Greg Joyce
Reviewed-by: Jonathan Derrick
---
block/Makefile | 2 +-
block/sed-opal-key.c | 24
include/linux/sed-opal-key.h
From: Greg Joyce
Extend the SED block driver so it can alternatively
obtain a key from a sed-opal kernel keyring. The SED
ioctls will indicate the source of the key, either
directly in the ioctl data or from the keyring.
This allows the use of SED commands in scripts such as
udev scripts so that
From: Greg Joyce
Add IOC_OPAL_DISCOVERY ioctl to return raw discovery data to a SED Opal
application. This allows the application to display drive capabilities
and state.
Signed-off-by: Greg Joyce
Reviewed-by: Christoph Hellwig
Reviewed-by: Jonathan Derrick
---
block/sed-opal.c
From: Greg Joyce
This is used in conjunction with IOC_OPAL_REVERT_TPR to return a drive to
Original Factory State without erasing the data. If IOC_OPAL_REVERT_LSP
is called with opal_revert_lsp.options bit OPAL_PRESERVE set prior
to calling IOC_OPAL_REVERT_TPR, the drive global locking range will
From: Greg Joyce
TCG SED Opal is a specification from The Trusted Computing Group
that allows self encrypting storage devices (SED) to be locked at
power on and require an authentication key to unlock the drive.
The current SED Opal implementation in the block driver
requires that authentication
On Mon, Apr 24, 2023 at 01:52:48PM +0800, Kai-Heng Feng wrote:
> PCIe service that shares IRQ with PME may cause spurious wakeup on
> system suspend.
>
> PCIe Base Spec 5.0, section 5.2 "Link State Power Management" states
> that TLP and DLLP transmission is disabled for a Link in L2/L3 Ready
> (D
For an SR-IOV device, while enabling DDW, a new table is created and added
at index 1 in the group. In the below 2 scenarios, the table is incorrectly
referenced at index 0 (which is where the table is for default DMA window).
1. When adding DDW
This issue is exposed with "slub_debug". Er
Freescale PCIe controllers on their PCIe Root Ports do not have any
mappable PCI BAR allocate from PCIe MEM.
Information about 1MB window on BAR0 of PCIe Root Port was misleading
because Freescale PCIe controllers have at BAR0 position different register
PEXCSRBAR, and kernel correctly skipts BAR0
Commit e4ab08be5b49 ("powerpc/isa-bridge: Remove open coded "ranges"
parsing") broke PASemi Nemo board booting. The issue is the ISA I/O
range was not getting mapped as the logic to handle no "ranges" was
inverted. If phb_io_base_phys is non-zero, then the ISA range defaults
to the first 64K of the
Hi,
On Thu, May 4, 2023 at 8:07 PM Nicholas Piggin wrote:
>
> On Fri May 5, 2023 at 8:13 AM AEST, Douglas Anderson wrote:
> > Do a search and replace of:
> > - NMI_WATCHDOG_ENABLED => HARD_WATCHDOG_ENABLED
> > - watchdog_nmi_ => watchdog_hardlockup_
>
> These are just making prefixes inconsistent
Hi,
On Thu, May 4, 2023 at 8:02 PM Nicholas Piggin wrote:
>
> On Fri May 5, 2023 at 8:13 AM AEST, Douglas Anderson wrote:
> > These are tiny style changes:
> > - Add a blank line before a "return".
> > - Renames two globals to use the "watchdog_hld" prefix.
>
> Particularly static ones don't real
Hi,
On Thu, May 4, 2023 at 7:58 PM Nicholas Piggin wrote:
>
> On Fri May 5, 2023 at 8:13 AM AEST, Douglas Anderson wrote:
> > The perf hardlockup detector works by looking at interrupt counts and
> > seeing if they change from run to run. The interrupt counts are
> > managed by the common watchdo
Hi,
On Thu, May 4, 2023 at 7:51 PM Nicholas Piggin wrote:
>
> On Fri May 5, 2023 at 8:13 AM AEST, Douglas Anderson wrote:
> > In preparation for the buddy hardlockup detector, rename
> > touch_nmi_watchdog() to touch_hardlockup_watchdog() to make it clear
> > that it will touch whatever hardlocku
Hi,
On Thu, May 4, 2023 at 7:36 PM Nicholas Piggin wrote:
>
> On Fri May 5, 2023 at 8:13 AM AEST, Douglas Anderson wrote:
> > From: Colin Cross
> >
> > Implement a hardlockup detector that doesn't doesn't need any extra
> > arch-specific support code to detect lockups. Instead of using
> > somet
From: Michael Ellerman
> Sent: 05 May 2023 04:51
>
> Since commit 1ba3cbf3ec3b ("mm: kfence: improve the performance of
> __kfence_alloc() and __kfence_free()"), kfence reports failures in
> random places at boot on big endian machines.
>
> The problem is that the new KFENCE_CANARY_PATTERN_U64 en
On Mon, 24 Apr 2023 13:52:47 +0800
Kai-Heng Feng wrote:
> There are many places that enable and disable AER interrput, so move
interrupt
> them into helpers.
Otherwise looks like a good clean up to me.
FWIW
Reviewed-by: Jonathan Cameron
>
> Reviewed-by: Mika Westerberg
> Reviewed-by: Kuppu
Michael Ellerman wrote:
Christophe Leroy writes:
Le 05/05/2023 à 09:18, Nicholas Piggin a écrit :
This series has the steps to remove ELFv1 from the kernel build.
Patch 1 is a build fix, 2 defaults everything to ELFv2, 3 is
really a separate issue that concerns userspace. 4 removes v1
support.
On Thu, May 4, 2023 at 11:52 PM Christian Zigotzky
wrote:
>
> On 03 May 2023 at 08:15 pm, Rob Herring wrote:
> > On Wed, May 3, 2023 at 12:40 PM Christian Zigotzky
> > wrote:
> >>
> >>
> >>> On 3. May 2023, at 18:51, Rob Herring wrote:
> >>>
> >>> On Wed, May 3, 2023 at 11:27 AM Christophe Lero
On Fri, May 5, 2023, at 07:47, Guo Ren wrote:
> On Mon, Mar 27, 2023 at 8:15 PM Arnd Bergmann wrote:
>>
>> riscv also invalidates the caches before the transfer, which does
>> not appear to serve any purpose.
> Yes, we can't guarantee the CPU pre-load cache lines randomly during
> dma working.
>
On Mon, May 01, 2023 at 09:54:43PM +0200, Ricardo Ribalda wrote:
> On Mon, 1 May 2023 at 19:41, Conor Dooley wrote:
> > On Mon, May 01, 2023 at 02:38:22PM +0200, Ricardo Ribalda wrote:
> > > If PGO is enabled, the purgatory ends up with multiple .text sections.
> > > This is not supported by kexec
Christophe Leroy writes:
> Le 05/05/2023 à 09:18, Nicholas Piggin a écrit :
>> This series has the steps to remove ELFv1 from the kernel build.
>> Patch 1 is a build fix, 2 defaults everything to ELFv2, 3 is
>> really a separate issue that concerns userspace. 4 removes v1
>> support.
>
> I see CON
Marco Elver writes:
> On Fri, 5 May 2023 at 05:51, Michael Ellerman wrote:
>>
>> Since commit 1ba3cbf3ec3b ("mm: kfence: improve the performance of
>> __kfence_alloc() and __kfence_free()"), kfence reports failures in
>> random places at boot on big endian machines.
>>
>> The problem is that the
On Fri, May 5, 2023 at 5:51 AM Michael Ellerman wrote:
> Since commit 1ba3cbf3ec3b ("mm: kfence: improve the performance of
> __kfence_alloc() and __kfence_free()"), kfence reports failures in
> random places at boot on big endian machines.
>
> The problem is that the new KFENCE_CANARY_PATTERN_U6
Le 05/05/2023 à 09:18, Nicholas Piggin a écrit :
> This series has the steps to remove ELFv1 from the kernel build.
> Patch 1 is a build fix, 2 defaults everything to ELFv2, 3 is
> really a separate issue that concerns userspace. 4 removes v1
> support.
I see CONFIG_MPROFILE_KERNEL is restricted
Le 05/05/2023 à 09:18, Nicholas Piggin a écrit :
> User code must still support ELFv1, e.g., see is_elf2_task().
>
> This one should wait a while until ELFv2 fallout settles, so
> just posting it out of interest.
Can't ELFv1 user code run on an ELFv2 kernel ?
Christophe
>
> Thanks,
> Nick
>
On i.MX8MP, the sai MCLK is bound with TX/RX enable bit,
which means the TX/RE enable bit need to be enabled then
MCLK can be output on PAD.
Some codec (for example: WM8962) needs the MCLK output
earlier, otherwise there will be issue for codec
configuration.
Add new soc data "mclk_with_tere" for
On Fri, 5 May 2023 at 05:51, Michael Ellerman wrote:
>
> Since commit 1ba3cbf3ec3b ("mm: kfence: improve the performance of
> __kfence_alloc() and __kfence_free()"), kfence reports failures in
> random places at boot on big endian machines.
>
> The problem is that the new KFENCE_CANARY_PATTERN_U64
User code must still support ELFv1, e.g., see is_elf2_task().
This one should wait a while until ELFv2 fallout settles, so
just posting it out of interest.
Thanks,
Nick
---
arch/powerpc/Kconfig | 19 --
arch/powerpc/Makefile| 15 +
arch/powerpc/boo
ELFv2 was introduced together with little-endian. ELFv1 with LE has
never been a thing. The GNU toolchain can create such a beast, but
anyone doing that is a maniac who needs to be stopped so I consider
this patch a feature.
Signed-off-by: Nicholas Piggin
---
arch/powerpc/include/asm/elf.h
All supported toolchains now support ELFv2 on big-endian, so flip the
default on this and hide the option behind EXPERT for the purpose of
bug hunting.
Signed-off-by: Nicholas Piggin
---
arch/powerpc/Kconfig | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/Kc
The LLVM linker does not support ELFv1 at all, so BE kernels must be
built with ELFv2. The LLD version check was added to be conservative,
but previous LLD versions would simply fail to link ELFv1 entirely. The
only would be to require LLD >= 15 for BE builds, but let's instead
remove that restrict
This series has the steps to remove ELFv1 from the kernel build.
Patch 1 is a build fix, 2 defaults everything to ELFv2, 3 is
really a separate issue that concerns userspace. 4 removes v1
support.
Would like to try getting patch 1 in as a fix, then 2,3 merged in
the next merge window.
Thanks,
Nic
39 matches
Mail list logo
