Some architectures like powerpc support both endianness, it's
therefore not possible to fix the endianness via arch/endianness.h
because there is no easy way to get the target endianness at
build time.
Use the endianness recorded in the file objtool is working on.
Signed-off-by: Christophe Leroy
On Thu, Mar 31, 2022 at 12:19:52PM -0300, Murilo Opsfelder Araújo wrote:
> My understanding is that the default cpu type for -mcpu=powerpc64 can
> change.
Different subtargets (Linux, AIX, Darwin, the various BSDs, bare ELF,
etc.) have different default CPUs. It also can be set at configure
On Wed, Mar 30, 2022 at 11:05:19PM -0300, Murilo Opsfelder Araújo wrote:
> I think it was a fortunate coincidence that the default cpu type of your
> gcc is
> compatible with your system. If the distro gcc moves its default to a
> newer cpu
> type than your system, this bug would happen again.
On Wed, Mar 30, 2022 at 11:39:13AM +, Joel Stanley wrote:
> Last one wins as far as -mcpu lines goes, from a quick test.
This is true yes. It is true for GCC options in general.
Segher
-Original Message-
From: Andy Shevchenko
Sent: Sunday, March 27, 2022 1:00 PM
To: Benjamin Stürz
Cc: Andrew Lunn ; Sebastian Hesselbarth
; Gregory Clement
; Russell King - ARM Linux
; li...@simtec.co.uk; Krzysztof Kozlowski
; Alim Akhtar ; Thomas Gleixner
; Ingo Molnar ; Borislav
On 3/27/22 3:04 AM, Leon Romanovsky wrote:
> On Sat, Mar 26, 2022 at 05:58:58PM +0100, Benjamin Stürz wrote:
>> This replaces comments with C99's designated
>> initializers because the kernel supports them now.
>>
>> Signed-off-by: Benjamin Stürz
>> ---
>> drivers/infiniband/sw/rdmavt/rc.c | 62
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: fdcbcd1348f4ef713668bae1b0fa9774e1811205 Add linux-next specific
files for 20220331
Error/Warning reports:
https://lore.kernel.org/lkml/202204010033.oeila4qb-...@intel.com
https
Hi, Joel.
On 3/31/22 02:01, Joel Stanley wrote:
On Thu, 31 Mar 2022 at 02:05, Murilo Opsfelder Araújo
wrote:
Hi, Joel.
On 3/30/22 08:24, Joel Stanley wrote:
Currently the boot wrapper lacks a -mcpu option, so it will be built for
the toolchain's default cpu. This is a problem if the
On Thu, Mar 31, 2022 at 11:39:45PM +1100, Michael Ellerman wrote:
> Greg Kroah-Hartman writes:
> > There are currently 2 ways to create a set of sysfs files for a
> > kobj_type, through the default_attrs field, and the default_groups
> > field. Move the pseries vas sysfs code to use
Greg Kroah-Hartman writes:
> There are currently 2 ways to create a set of sysfs files for a
> kobj_type, through the default_attrs field, and the default_groups
> field. Move the pseries vas sysfs code to use default_groups field
> which has been the preferred way since aa30f47cf666 ("kobject:
Since commit 8a4ab218ef70 ("powerpc/85xx: Change deprecated binding
for 85xx-based boards"), those bindings are not used anymore.
A comment in drivers/edac/mpc85xx_edac.c say they are to be removed
with kernel 2.6.30.
Remove them now.
Signed-off-by: Christophe Leroy
---
CONFIG_FSL_85XX_CACHE_SRAM is an option that is not
user selectable and which is not selected by any driver
nor any defconfig.
Remove it and all associated code.
Signed-off-by: Christophe Leroy
---
.../bindings/powerpc/fsl/cache_sram.txt | 20 --
On 25/03/22 22:34, Laurent Dufour wrote:
On 21/03/2022, 09:04:17, Sourabh Jain wrote:
This patch series implements the crash hotplug handler on PowerPC introduced
by https://lkml.org/lkml/2022/3/3/674 patch series.
Hi Sourabh,
That's a great idea!
The Problem:
Post
Hi Laurent,
On 25/03/22 23:33, Laurent Dufour wrote:
On 21/03/2022, 09:04:21, Sourabh Jain wrote:
Two major changes are done to enable the crash CPU hotplug handler.
Firstly, updated the kexec_load path to prepare kimage for hotplug
changes and secondly, implemented the crash hotplug handler
Le 31/03/2022 à 10:08, Peter Zijlstra a écrit :
> On Thu, Mar 31, 2022 at 09:52:07AM +0200, Christophe Leroy wrote:
>> Some architectures like powerpc support both endianness, it's
>> therefore not possible to fix the endianness via arch/endianness.h
>> because there is no easy way to get the
On Thu, Mar 31, 2022 at 09:52:07AM +0200, Christophe Leroy wrote:
> Some architectures like powerpc support both endianness, it's
> therefore not possible to fix the endianness via arch/endianness.h
> because there is no easy way to get the target endianness at
> build time.
>
> Use the
Some architectures like powerpc support both endianness, it's
therefore not possible to fix the endianness via arch/endianness.h
because there is no easy way to get the target endianness at
build time.
Use the endianness recorded in the file objtool is working on.
Signed-off-by: Christophe Leroy
https://bugzilla.kernel.org/show_bug.cgi?id=215781
--- Comment #4 from Christophe Leroy (christophe.le...@csgroup.eu) ---
This problem was introduced in 5.15 by commit 602946ec2f90 ("powerpc: Set
max_mapnr correctly")
A similar issue has been opened at
18 matches
Mail list logo
