At the time being, KASAN_SHADOW_END is 0x1, which
is 0 in 32 bits representation.
This leads to a couple of issues:
- kasan_remap_early_shadow_ro() does nothing because the comparison
k_cur < k_end is always false.
- In ptdump, address comparison for markers display fails and the
marker's
The main purpose of this big series is to:
- reorganise huge page handling to avoid using mm_slices.
- use huge pages to map kernel memory on the 8xx.
The 8xx supports 4 page sizes: 4k, 16k, 512k and 8M.
It uses 2 Level page tables, PGD having 1024 entries, each entry
covering 4M address space.
In case (k_start & PAGE_MASK) doesn't equal (kstart), 'va' will never be
NULL allthough 'block' is NULL
Check the return of memblock_alloc() directly instead of
the resulting address in the loop.
Fixes: 509cd3f2b473 ("powerpc/32: Simplify KASAN init")
Signed-off-by: Christophe Leroy
---
On Tuesday, 19 May 2020 2:04:51 PM AEST Jordan Niethe wrote:
> On Tue, May 19, 2020 at 10:39 AM Alistair Popple
wrote:
> > Newer ISA versions are enabled by clearing all bits in the PCR
> > associated with previous versions of the ISA. Enable ISA v3.1 support
> > by updating the PCR mask to
Hi Dan,
Apologies for the delay in response. I was waiting for feedback from
hardware team before responding to this email.
Dan Williams writes:
> On Tue, May 12, 2020 at 8:47 PM Aneesh Kumar K.V
> wrote:
>>
>> Architectures like ppc64 provide persistent memory specific barriers
>> that
Le 19/05/2020 à 06:05, Michael Ellerman a écrit :
Jordan Niethe writes:
On Sun, May 17, 2020 at 4:39 AM Christophe Leroy
wrote:
Le 06/05/2020 à 05:40, Jordan Niethe a écrit :
Prefixed instructions will mean there are instructions of different
length. As a result dereferencing a pointer
This gives us OF_PMEM which is useful in mambo.
This adds 153K to the text of ppc64le_defconfig which 0.8% of the
total text.
LIBNVDIMM text databss dec hex
Without 18574833 5518150 1539240 25632223 1871ddf
With 18727834 5546206 1539368 25813408 189e1a0
Jordan Niethe writes:
> On Sun, May 17, 2020 at 4:39 AM Christophe Leroy
> wrote:
>>
>> Le 06/05/2020 à 05:40, Jordan Niethe a écrit :
>> > Prefixed instructions will mean there are instructions of different
>> > length. As a result dereferencing a pointer to an instruction will not
>> >
On Tue, May 19, 2020 at 10:39 AM Alistair Popple wrote:
>
> Newer ISA versions are enabled by clearing all bits in the PCR
> associated with previous versions of the ISA. Enable ISA v3.1 support
> by updating the PCR mask to include ISA v3.0. This ensures all PCR
> bits corresponding to earlier
On Tue, May 19, 2020 at 10:48 AM Alistair Popple wrote:
>
> PVR value of 0x0F06 means we are arch v3.1 compliant (i.e. POWER10).
> This is used by phyp and kvm when booting as a pseries guest to detect
> the presence of new P10 features and to enable the appropriate hwcap and
> facility bits.
On 2020/5/19 6:19, Gustavo A. R. Silva wrote:
> -Original Message-
> From: Gustavo A. R. Silva
> Sent: 2020年5月19日 6:19
> To: Qiang Zhao ; Leo Li
> Cc: linuxppc-dev@lists.ozlabs.org; linux-arm-ker...@lists.infradead.org;
> linux-ker...@vger.kernel.org; Gustavo A. R. Silva ;
> Kees Cook
On Tue, 2020-05-19 at 10:31 +1000, Alistair Popple wrote:
> POWER10 introduces two new architectural features - ISAv3.1 and matrix
> multiply accumulate (MMA) instructions. Userspace detects the presence
> of these features via two HWCAP bits introduced in this patch. These
> bits have been agreed
Hi Ira,
On 5/18/20 5:03 PM, Ira Weiny wrote:
> On Sun, May 17, 2020 at 09:29:32PM -0700, Guenter Roeck wrote:
>> On Sun, May 17, 2020 at 08:49:39PM -0700, Ira Weiny wrote:
>>> On Sat, May 16, 2020 at 03:33:06PM -0700, Guenter Roeck wrote:
On Thu, May 07, 2020 at 07:59:55AM -0700,
PVR value of 0x0F06 means we are arch v3.1 compliant (i.e. POWER10).
This is used by phyp and kvm when booting as a pseries guest to detect
the presence of new P10 features and to enable the appropriate hwcap and
facility bits.
Signed-off-by: Alistair Popple
Signed-off-by: Cédric Le Goater
Matrix multiple accumulate (MMA) is a new feature added to ISAv3.1 and
POWER10. Support on powernv can be selected via a firmware CPU device
tree feature which enables it via a PCR bit.
Signed-off-by: Alistair Popple
---
arch/powerpc/include/asm/reg.h| 3 ++-
Prefix instructions have their own FSCR bit which needs to be enabled
via a CPU feature. The kernel will save the FSCR for problem state but
it needs to be enabled initially.
Signed-off-by: Alistair Popple
---
arch/powerpc/kernel/dt_cpu_ftrs.c | 1 +
1 file changed, 1 insertion(+)
diff --git
Setting the FSCR bit directly in the SPR only sets it during the initial
boot and early init of the kernel but not for the init process or any
subsequent kthreads. This is because the thread_struct for those is
copied from the current thread_struct setup at boot which doesn't
reflect any changes
On powernv hardware support for ISAv3.1 is advertised via a cpu feature
bit in the device tree. This patch enables the associated HWCAP bit if
the device tree indicates ISAv3.1 is available.
Signed-off-by: Alistair Popple
---
arch/powerpc/kernel/dt_cpu_ftrs.c | 6 ++
1 file changed, 6
Newer ISA versions are enabled by clearing all bits in the PCR
associated with previous versions of the ISA. Enable ISA v3.1 support
by updating the PCR mask to include ISA v3.0. This ensures all PCR
bits corresponding to earlier architecture versions get cleared
thereby enabling ISA v3.1 if
POWER10 introduces two new architectural features - ISAv3.1 and matrix
multiply accumulate (MMA) instructions. Userspace detects the presence
of these features via two HWCAP bits introduced in this patch. These
bits have been agreed to by the compiler and binutils team.
Signed-off-by: Alistair
This series brings together several previously posted patches required for
POWER10 support and introduces a new patch enabling POWER10 architected
mode to enable booting as a POWER10 pseries guest.
It includes support for enabling facilities related to MMA and prefix
instructions.
Changes from
Currently, if printk lock (logbuf_lock) is held by other thread during
crash, there is a chance of deadlocking the crash on next printk, and
blocking a possibly desired kdump.
At the start of default_machine_crash_shutdown, make printk enter
NMI context, as it will use per-cpu buffers to store
powerpc allyesconfig
powerpc rhel-kconfig
powerpc allmodconfig
powerpc allnoconfig
i386 randconfig-a006-20200518
i386 randconfig-a005-20200518
i386
On Sun, May 17, 2020 at 09:29:32PM -0700, Guenter Roeck wrote:
> On Sun, May 17, 2020 at 08:49:39PM -0700, Ira Weiny wrote:
> > On Sat, May 16, 2020 at 03:33:06PM -0700, Guenter Roeck wrote:
> > > On Thu, May 07, 2020 at 07:59:55AM -0700, ira.we...@intel.com wrote:
> > > > From: Ira Weiny
> > > >
Implement rtas_call_reentrant() for reentrant rtas-calls:
"ibm,int-on", "ibm,int-off",ibm,get-xive" and "ibm,set-xive".
On LoPAPR Version 1.1 (March 24, 2016), from 7.3.10.1 to 7.3.10.4,
items 2 and 3 say:
2 - For the PowerPC External Interrupt option: The * call must be
reentrant to the number
In order to get any rtas* struct into other headers, including rtas.h
may cause a lot of errors, regarding include dependency needed for
inline functions.
Create rtas-types.h and move there all type/struct definitions
from rtas.h, then include rtas-types.h into rtas.h.
Also, as suggested by
Patch 2 implement rtas_call_reentrant() for reentrant rtas-calls:
"ibm,int-on", "ibm,int-off",ibm,get-xive" and "ibm,set-xive",
according to LoPAPR Version 1.1 (March 24, 2016).
For that, it's necessary that every call uses a different
rtas buffer (rtas_args). Paul Mackerras suggested using the
allyesconfig
powerpc rhel-kconfig
powerpc allmodconfig
powerpc allnoconfig
i386 randconfig-a006-20200518
i386 randconfig-a005-20200518
i386 randconfig
On Sat, 2020-05-16 at 17:36 +1000, Nicholas Piggin wrote:
> Good, I think this should work as you want now. Can you allocate it like
> lppacas? Put it under PSERIES (and in the paca) and check for !HV?
Sure, I will do that.
> Oh and while there, could you prefix the name with rtas_?
Sure,
On Mon, May 18, 2020 at 04:45:32PM -0600, Rob Herring wrote:
> On Fri, May 15, 2020 at 12:44 PM Kees Cook wrote:
> >
> > From: Pavel Tatashin
>
> Subject still has 'max_reason'.
>
> >
> > Currently, it is possible to dump kmsges for panic, or oops.
> > With max_reason it is possible to dump
On Mon, May 18, 2020 at 05:19:04PM -0500, Gustavo A. R. Silva wrote:
> The current codebase makes use of one-element arrays in the following
> form:
>
> struct something {
> int length;
> u8 data[1];
> };
>
> struct something *instance;
>
> instance = kmalloc(sizeof(*instance) + size,
On Fri, May 15, 2020 at 12:44 PM Kees Cook wrote:
>
> From: Pavel Tatashin
Subject still has 'max_reason'.
>
> Currently, it is possible to dump kmsges for panic, or oops.
> With max_reason it is possible to dump messages for other
And here.
> kmesg_dump events, for example reboot, halt,
The current codebase makes use of one-element arrays in the following
form:
struct something {
int length;
u8 data[1];
};
struct something *instance;
instance = kmalloc(sizeof(*instance) + size, GFP_KERNEL);
instance->length = size;
memcpy(instance->data, source, size);
but the
Hi Mike and Baoquan,
On 4/22/20 6:13 PM, Baoquan He wrote:
On 04/12/20 at 10:48pm, Mike Rapoport wrote:
From: Mike Rapoport
The commit f47ac088c406 ("mm: memmap_init: iterate over memblock regions
This commit id should be a temporary one, will be changed when merged
into maintainer's tree
On 5/12/20 4:09 PM, Rob Herring wrote:
On Mon, May 04, 2020 at 01:38:28PM -0700, Prakhar Srivastava wrote:
Introduce a device tree layer for to read and store ima buffer
from the reserved memory section of a device tree.
But why do I need 'a layer of abstraction'? I don't like them.
This
On 5/12/20 4:05 PM, Rob Herring wrote:
On Wed, May 06, 2020 at 10:50:04PM -0700, Prakhar Srivastava wrote:
Hi Mark,
Please don't top post.
This patch set currently only address the Pure DT implementation.
EFI and ACPI implementations will be posted in subsequent patchsets.
The logs are
From: Ira Weiny
The kunmap_atomic clean up failed to remove one set of pagefault/preempt
enables when vaddr is not in the fixmap.
Fixes: bee2128a09e6 ("arch/kunmap_atomic: consolidate duplicate code")
Signed-off-by: Ira Weiny
---
arch/microblaze/mm/highmem.c | 5 +
arch/mips/mm/highmem.c
On Fri, 2020-05-15 at 16:36 +0200, Christoph Hellwig wrote:
> C6x needs almost no cache flushing routines of its own. Rely on
> asm-generic/cacheflush.h for the defaults.
>
> Signed-off-by: Christoph Hellwig
> ---
> arch/c6x/include/asm/cacheflush.h | 19 +--
> 1 file changed,
On Sun, May 17, 2020 at 10:37:22AM -0700, Guenter Roeck wrote:
> Hi,
>
> On Thu, May 07, 2020 at 07:59:58AM -0700, ira.we...@intel.com wrote:
> > From: Ira Weiny
> >
> > To support kmap_atomic_prot(), all architectures need to support
> > protections passed to their kmap_atomic_high() function.
On Sun, May 17, 2020 at 09:29:32PM -0700, Guenter Roeck wrote:
> On Sun, May 17, 2020 at 08:49:39PM -0700, Ira Weiny wrote:
> > On Sat, May 16, 2020 at 03:33:06PM -0700, Guenter Roeck wrote:
> > > On Thu, May 07, 2020 at 07:59:55AM -0700, ira.we...@intel.com wrote:
> > > > From: Ira Weiny
> > > >
This causes a build error with CONFIG_WALNUT because kb_cs and kb_data
were removed in commit 917f0af9e5a9 ("powerpc: Remove arch/ppc and
include/asm-ppc").
ld.lld: error: undefined symbol: kb_cs
> referenced by i8042-ppcio.h:28 (drivers/input/serio/i8042-ppcio.h:28)
>
On Mon, 18 May 2020 at 18:15, Christophe Leroy
wrote:
>
> Yeah I discovered recently that the way swap is implemented on powerpc
> expects RW and other important bits not be one of the 3 least
> significant bits (see __pte_to_swp_entry() )
I see, you get the swap entry by shifting the PTE right
Le 18/05/2020 à 17:19, Rui Salvaterra a écrit :
Hi again, Christophe,
On Mon, 18 May 2020 at 15:03, Christophe Leroy
wrote:
Can you try reverting 697ece78f8f749aeea40f2711389901f0974017a ? It may
have broken swap.
Yeah, that was a good call. :) Linux 5.7-rc1 with the revert on top
On Mon, 18 May 2020 19:00:40 +0800, Tang Bin wrote:
> Delete unused initialized value of 'ret', because it will
> be assigned by the function fsl_micfil_set_mclk_rate().
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-5.8
Thanks!
[1/1] ASoC: fsl_micfil: Fix
On Mon, 18 May 2020 18:59:51 +0800, Tang Bin wrote:
> In the function fsl_micfil_startup(), the two lines of dev_err()
> can be shortened to one line.
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-5.8
Thanks!
[1/1] ASoC: fsl_micfil: Fix indentation to put
On Sun, May 17, 2020 at 08:49:39PM -0700, Ira Weiny wrote:
[ ... ]
> >
> > ---
> > # bad: [bdecf38f228bcca73b31ada98b5b7ba1215eb9c9] Add linux-next specific
> > files for 20200515
> > # good: [2ef96a5bb12be62ef75b5828c0aab838ebb29cb8] Linux 5.7-rc5
> > git bisect start 'HEAD' 'v5.7-rc5'
> > #
Hi again, Christophe,
On Mon, 18 May 2020 at 15:03, Christophe Leroy
wrote:
>
> Can you try reverting 697ece78f8f749aeea40f2711389901f0974017a ? It may
> have broken swap.
Yeah, that was a good call. :) Linux 5.7-rc1 with the revert on top
survives the beating. I'll be happy to test a
Hi
On 05/18/2020 01:25 PM, Rui Salvaterra wrote:
Hi, Christophe,
On Mon, 18 May 2020 at 12:50, Christophe Leroy
wrote:
Can you provide your .config, tell which GCC version you are using, and
tell a bit more about your config: amount of RAM, is there swap, etc ...
Ok, so this laptop has
On Mai 18 2020, Michael Ellerman wrote:
> The old drivers may be crufty but they presumably have been tested by
> people and at least somewhat work.
I can confirm that the nvidia fbdev driver is working perfectly fine.
> I gave it a quick spin on a G5 I have access to and dmesg has a bunch of
>
[ Cc += linuxppc-dev ]
Nathan Chancellor writes:
> On Thu, May 14, 2020 at 08:13:48AM +0800, kbuild test robot wrote:
>> tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
>> master
>> head: 24085f70a6e1b0cb647ec92623284641d8270637
>> commit:
On Mon, 18 May 2020 at 13:48, Bartlomiej Zolnierkiewicz
wrote:
>
>
> On 5/18/20 1:19 PM, Emil Velikov wrote:
> > Hi Michael,
> >
> > On Mon, 18 May 2020 at 08:30, Michael Ellerman wrote:
> >>
> >> Emil Velikov writes:
> >>> As mentioned in earlier commit, the riva and nvidia fbdev drivers have
+++ Christoph Hellwig [15/05/20 16:36 +0200]:
flush_icache_range generally operates on kernel addresses, but for some
reason m68k needed a set_fs override. Move that into the m68k code
insted of keeping it in the module loader.
Signed-off-by: Christoph Hellwig
Reviewed-by: Geert Uytterhoeven
On 5/18/20 1:19 PM, Emil Velikov wrote:
> Hi Michael,
>
> On Mon, 18 May 2020 at 08:30, Michael Ellerman wrote:
>>
>> Emil Velikov writes:
>>> As mentioned in earlier commit, the riva and nvidia fbdev drivers have
>>> seen no love over the years, are short on features and overall below par
On Mon, 2020-05-18 at 12:19 +0100, Emil Velikov wrote:
>
> - attempted out-of-bound attempts to read the vbios
So on these things, the actual ROM doesn't contain what you want, but
the device-tree has a property "NVDA,BMP" that contains some kind of
mini-BIOS (around 2.4KB) which should contain
On Mon, 2020-05-18 at 12:00 +0100, Emil Velikov wrote:
> I believe you reported issues due to different page size for the CPU/GPU.
> Have you tried nouveau recently, there has been a handful of patches
> on the topic since your report.
>
> Alternatively, it would make sense you rebase, cleanup
Hi!
On Mon, May 18, 2020 at 04:35:22PM +1000, Michael Ellerman wrote:
> Nicholas Piggin writes:
> > Provide an option to build big-endian kernels using the ELF V2 ABI. This
> > works
> > on GCC and clang (since about 2014). it is is not officially supported by
> > the
> > GNU toolchain, but it
Add documentation for the following sysfs files:
/sys/devices/hv_24x7/interface/chipspersocket,
/sys/devices/hv_24x7/interface/sockets,
/sys/devices/hv_24x7/interface/coresperchip
Signed-off-by: Kajol Jain
---
.../sysfs-bus-event_source-devices-hv_24x7| 21 +++
1 file
To expose the system dependent parameter like total number of
sockets and numbers of chips per socket, patch adds two sysfs files.
"sockets" and "chips" are added to /sys/devices/hv_24x7/interface/
of the "hv_24x7" pmu.
Signed-off-by: Kajol Jain
---
arch/powerpc/perf/hv-24x7.c | 24
Function 'read_sys_info_pseries()' is added to get system parameter
values like number of sockets and chips per socket.
and it gets these details via rtas_call with token
"PROCESSOR_MODULE_INFO".
Incase lpar migrate from one system to another, system
parameter details like chips per sockets or
For hv_24x7 socket/chip level events, specific chip-id to which
the data requested should be added as part of pmu events.
But number of chips/socket in the system details are not exposed.
Patch implements read_sys_info_pseries() to get system
parameter values like number of sockets, cores per
Commit 2b206ee6b0df ("powerpc/perf/hv-24x7: Display change in counter
values")' added to print _change_ in the counter value rather then raw
value for 24x7 counters. Incase of transactions, the event count
is set to 0 at the beginning of the transaction. It also sets
the event's prev_count to the
Patchset fixes the inconsistent results we are getting when
we run multiple 24x7 events.
"hv_24x7" pmu interface events needs system dependent parameter
like socket/chip/core. For example, hv_24x7 chip level events needs
specific chip-id to which the data is requested should be added as part
of
Hi,
Le 18/05/2020 à 13:20, Rui Salvaterra a écrit :
[Resending since I messed up the subject, sorry]
Hi, everyone,
Something went wrong between Linux 5.6 and 5.7-rc1. This is an iBook
G4 laptop with 1.5 GiB of RAM running the Debian powerpc port. I
haven't bisected yet, since it's going to
Jiri Kosina writes:
> On Mon, 18 May 2020, Jiri Kosina wrote:
>> > > Include linux/io.h into fsl_85xx_cache_sram.c to fix the
>> > > implicit-declaration compile errors when building Cache-Sram.
>> > >
>> > > arch/powerpc/sysdev/fsl_85xx_cache_sram.c: In function
>> > > ‘instantiate_cache_sram’:
Hi, everyone,
I strongly suspect something went wrong between Linux 5.6 and 5.7-rc1.
This is an iBook G4 laptop with 1.5 GiB of RAM running the Debian
powerpc port. I haven't bisected yet, since it's going to take quite a
bit of time, so I'm sending this mostly as a heads-up (and to see if
Hi Michael,
On Mon, 18 May 2020 at 08:30, Michael Ellerman wrote:
>
> Emil Velikov writes:
> > As mentioned in earlier commit, the riva and nvidia fbdev drivers have
> > seen no love over the years, are short on features and overall below par
> >
> > Users are encouraged to switch to the
[Resending since I messed up the subject, sorry]
Hi, everyone,
Something went wrong between Linux 5.6 and 5.7-rc1. This is an iBook
G4 laptop with 1.5 GiB of RAM running the Debian powerpc port. I
haven't bisected yet, since it's going to take quite a bit of time, so
I'm sending this mostly as a
Delete unused initialized value of 'ret', because it will
be assigned by the function fsl_micfil_set_mclk_rate().
Signed-off-by: Tang Bin
---
sound/soc/fsl/fsl_micfil.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/fsl/fsl_micfil.c b/sound/soc/fsl/fsl_micfil.c
This patch adds support for retrieving a singled NVDIMM performance
stat from PHYP via PDSM GET_PERF_STAT_VERSION. A new uapi 'struct
nd_pdsm_get_perf_stat' is introduced that holds a single performance
stat and is populated by newly introduced papr_scm_get_perf_stat() by
issuing an
Implement support for pdsm READ_PERF_STATS to be used by libndctl to
fetch all NVDIMM performance statistics. The stats are to be exchanged
via newly introduced 'struct nd_pdsm_get_perf_stats' which is
allocated and sent by libndctl to papr_scm. The struct contains
members 'in_offset' and
Add support for pdsm PAPR_SCM_PDSM_FETCH_PERF_STATS that issues HCALL
H_SCM_PERFORMANCE_STATS to PHYP to fetch all the NVDIMM performance
stats and store them in per nvdimm 'struct papr_scm_priv' as member
'perf_stats'. A further PDSM request (introduced later) is needed to
read the contents of
The patch-set proposes to add support for fetching and reporting
performance statistics for PAPR compliant NVDIMMs as described in
documentation for H_SCM_PERFORMANCE_STATS hcall Ref[1]. The patch-set
also implements mechanisms to expose NVDIMM performance stats via
sysfs and newly introduced
Update papr_scm.c to query dimm performance statistics from PHYP via
H_SCM_PERFORMANCE_STATS hcall and export them to userspace as PAPR
specific NVDIMM attribute 'perf_stats' in sysfs. The patch also
provide a sysfs ABI documentation for the stats being reported and
their meanings.
During NVDIMM
Hi Benjamin,
On Mon, 18 May 2020 at 01:45, Benjamin Herrenschmidt
wrote:
>
> On Sun, 2020-05-17 at 23:05 +0100, Emil Velikov wrote:
> > As mentioned in earlier commit, the riva and nvidia fbdev drivers
> > have
> > seen no love over the years, are short on features and overall below
> > par
> >
In the function fsl_micfil_startup(), the two lines of dev_err()
can be shortened to one line.
Signed-off-by: Tang Bin
---
sound/soc/fsl/fsl_micfil.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/sound/soc/fsl/fsl_micfil.c b/sound/soc/fsl/fsl_micfil.c
index
On 2020/5/18 18:25, Mark Brown wrote:
On Mon, May 18, 2020 at 03:44:05PM +0800, Tang Bin wrote:
In the function fsl_micfil_startup(), the two lines of dev_err()
can be shortened to one line. And delete unused initialized value
of 'ret', because it will be assigned by the function
Le 18/05/2020 à 12:32, Jiri Kosina a écrit :
On Mon, 18 May 2020, Jiri Kosina wrote:
Include linux/io.h into fsl_85xx_cache_sram.c to fix the
implicit-declaration compile errors when building Cache-Sram.
arch/powerpc/sysdev/fsl_85xx_cache_sram.c: In function
‘instantiate_cache_sram’:
On Mon, 18 May 2020, Jiri Kosina wrote:
> > > Include linux/io.h into fsl_85xx_cache_sram.c to fix the
> > > implicit-declaration compile errors when building Cache-Sram.
> > >
> > > arch/powerpc/sysdev/fsl_85xx_cache_sram.c: In function
> > > ‘instantiate_cache_sram’:
> > >
On Mon, 2 Mar 2020, Christophe Leroy wrote:
> > Include linux/io.h into fsl_85xx_cache_sram.c to fix the
> > implicit-declaration compile errors when building Cache-Sram.
> >
> > arch/powerpc/sysdev/fsl_85xx_cache_sram.c: In function
> > ‘instantiate_cache_sram’:
> >
On Mon, May 18, 2020 at 03:44:05PM +0800, Tang Bin wrote:
> In the function fsl_micfil_startup(), the two lines of dev_err()
> can be shortened to one line. And delete unused initialized value
> of 'ret', because it will be assigned by the function
> fsl_micfil_set_mclk_rate().
This is two
On Mon, Apr 13, 2020 at 12:06:45PM -0700, Nathan Chancellor wrote:
> A 0day randconfig uncovered an error with clang, trimmed for brevity:
>
> arch/powerpc/platforms/embedded6xx/wii.c:195:7: error: attribute
> declaration must precede definition [-Werror,-Wignored-attributes]
> if
In the function fsl_micfil_startup(), the two lines of dev_err()
can be shortened to one line. And delete unused initialized value
of 'ret', because it will be assigned by the function
fsl_micfil_set_mclk_rate().
Signed-off-by: Tang Bin
---
sound/soc/fsl/fsl_micfil.c | 5 ++---
1 file changed,
Emil Velikov writes:
> As mentioned in earlier commit, the riva and nvidia fbdev drivers have
> seen no love over the years, are short on features and overall below par
>
> Users are encouraged to switch to the nouveau drm driver instead.
>
> v2: Split configs to separate patch, enable nouveau
OK, thanks.
> On 18. May 2020, at 04:40, Michael Ellerman wrote:
>
> Christian Zigotzky writes:
>> Hi All,
>>
>> This patch wasn't included in the PowerPC fixes 5.7-4. Please add it.
>
> It's not an important bug. I'll take the patch for v5.8
>
> cheers
>
>>> On 29 April 2020 at 09:02
Nicholas Piggin writes:
> Provide an option to build big-endian kernels using the ELF V2 ABI. This works
> on GCC and clang (since about 2014). it is is not officially supported by the
> GNU toolchain, but it can give big-endian kernels some useful advantages of
> the V2 ABI (e.g., less stack
Nicholas Piggin writes:
> Excerpts from Aneesh Kumar K.V's message of May 13, 2020 1:06 pm:
>> With a 64K page size flush with start and end value as below
>> (start, end) = (721f680d, 721f680e) results in
>> (hstart, hend) = (721f6820, 721f6800)
>>
>> Avoid doing a
Geoff Levand writes:
> Hi Michael,
>
> On 5/14/20 7:02 PM, Michael Ellerman wrote:
>> Geoff Levand writes:
> ...
>>> +# The ps3's flash loader has a size limit of 16 MiB for the
>>> uncompressed
>>> +# image. If a compressed image that exceeded this limit is written to
>>> +# flash
87 matches
Mail list logo
