DEBUG_PAGEALLOC only manages RW data.
Text and RO data can still be mapped with BATs.
In order to map with BATs, also enforce data alignment. Set
by default to 256M which is a good compromise for keeping
enough BATs for also KASAN and IMMR.
Signed-off-by: Christophe Leroy
---
arch/powerpc/Kcon
On 2020/5/6 23:52, Greg KH wrote:
On Wed, May 06, 2020 at 11:30:22PM +0800, Jia-Ju Bai wrote:
On 2020/5/6 19:07, Greg KH wrote:
On Wed, May 06, 2020 at 06:13:01PM +0800, Jia-Ju Bai wrote:
I have never modified DMA memory in the real world, but an attacker can use
a malicious device to do t
Map the IMMR area with a single 512k huge page.
Signed-off-by: Christophe Leroy
---
arch/powerpc/mm/nohash/8xx.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/mm/nohash/8xx.c b/arch/powerpc/mm/nohash/8xx.c
index 570ab2114a73..fb31a0c1c2a4 100644
--- a/a
Map linear memory space with 512k and 8M pages whenever
possible.
Three mappings are performed:
- One for kernel text
- One for RO data
- One for the rest
Separating the mappings is done to be able to update the
protection later when using STRICT_KERNEL_RWX.
The ITLB miss handler now need to als
PPC_PIN_TLB options are dedicated to the 8xx, move them into
the 8xx Kconfig.
While we are at it, add some text to explain what it does.
Signed-off-by: Christophe Leroy
---
arch/powerpc/Kconfig | 20 ---
arch/powerpc/platforms/8xx/Kconfig | 41 +
Up to now, linear and IMMR mappings are managed via huge TLB entries
through specific code directly in TLB miss handlers. This implies
some patching of the TLB miss handlers at startup, and a lot of
dedicated code.
Remove all this specific dedicated code.
For now we are back to normal handling vi
Only 40x still uses PTE_ATOMIC_UPDATES.
40x cannot not select CONFIG_PTE64_BIT.
Drop handling of PTE_ATOMIC_UPDATES:
- In nohash/64
- In nohash/32 for CONFIG_PTE_64BIT
Keep PTE_ATOMIC_UPDATES only for nohash/32 for !CONFIG_PTE_64BIT
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/
Now that linear and IMMR dedicated TLB handling is gone, kernel
boundary address comparison is similar in ITLB miss handler and
in DTLB miss handler.
Create a macro named compare_to_kernel_boundary.
When TASK_SIZE is strictly below 0x8000 and PAGE_OFFSET is
above 0x8000, it is enough to c
Display the size of areas mapped with BATs.
For that, the size display for pages is refactorised.
Signed-off-by: Christophe Leroy
---
v2: Add missing include of linux/seq_file.h (Thanks to kbuild test robot)
---
arch/powerpc/mm/ptdump/bats.c | 4
arch/powerpc/mm/ptdump/ptdump.c | 23 +++
Add a function to early map kernel memory using huge pages.
For 512k pages, just use standard page table and map in using 512k
pages.
For 8M pages, create a hugepd table and populate the two PGD
entries with it.
This function can only be used to create page tables at startup. Once
the regular SL
CONFIG_8xx_COPYBACK was there to help disabling copyback cache mode
for debuging hardware. But nobody will design new boards with 8xx now.
All 8xx platforms select it, so make it the default and remove
the option.
Also remove the Mx_RESETVAL values which are pretty useless and hide
the real value
DEBUG_PAGEALLOC only manages RW data.
Text and RO data can still be mapped with hugepages and pinned TLB.
In order to map with hugepages, also enforce a 512kB data alignment
minimum. That's a trade-off between size of speed, taking into
account that DEBUG_PAGEALLOC is a debug option. Anyway the a
Display BAT flags the same way as page flags: rwx and wimg
Signed-off-by: Christophe Leroy
---
arch/powerpc/mm/ptdump/bats.c | 37 ++-
1 file changed, 15 insertions(+), 22 deletions(-)
diff --git a/arch/powerpc/mm/ptdump/bats.c b/arch/powerpc/mm/ptdump/bats.c
ind
As the 8xx now manages 512k pages in standard page tables,
it doesn't need CONFIG_PPC_MM_SLICES anymore.
Don't select it anymore and remove all related code.
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/nohash/32/mmu-8xx.h | 64
arch/powerpc/include/asm/noha
Similar to PPC64, accept to map RO data as ROX as a trade off between
between security and memory usage.
Having RO data executable is not a high risk as RO data can't be
modified to forge an exploit.
Signed-off-by: Christophe Leroy
---
arch/powerpc/Kconfig | 26
Only early debug requires IMMR to be mapped early.
No need to set it up and pin it in assembly. Map it
through page tables at udbg init when necessary.
If CONFIG_PIN_TLB_IMMR is selected, pin it once we
don't need the 32 Mb pinned RAM anymore.
Signed-off-by: Christophe Leroy
---
v2: Disable TLB
Implement a kasan_init_region() dedicated to book3s/32 that
allocates KASAN regions using BATs.
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/kasan.h | 1 +
arch/powerpc/mm/kasan/Makefile| 1 +
arch/powerpc/mm/kasan/book3s_32.c | 57 +++
Setting init mem to NX shall depend on sinittext being mapped by
block, not on stext being mapped by block.
Setting text and rodata to RO shall depend on stext being mapped by
block, not on sinittext being mapped by block.
Fixes: 63b2bc619565 ("powerpc/mm/32s: Use BATs for STRICT_KERNEL_RWX")
Cc:
In order to alloc sub-arches to alloc KASAN regions using optimised
methods (Huge pages on 8xx, BATs on BOOK3S, ...), declare
kasan_init_region() weak.
Also make kasan_init_shadow_page_tables() accessible from outside,
so that it can be called from the specific kasan_init_region()
functions if nee
At the time being, 512k huge pages are handled through hugepd page
tables. The PMD entry is flagged as a hugepd pointer and it
means that only 512k hugepages can be managed in that 4M block.
However, the hugepd table has the same size as a normal page
table, and 512k entries can therefore be nested
When CONFIG_PTE_64BIT is set, pte_update() operates on
'unsigned long long'
When CONFIG_PTE_64BIT is not set, pte_update() operates on
'unsigned long'
In asm/page.h, we have pte_basic_t which is 'unsigned long long'
when CONFIG_PTE_64BIT is set and 'unsigned long' otherwise.
Refactor pte_update()
kasan_remap_early_shadow_ro() and kasan_unmap_early_shadow_vmalloc()
are both updating the early shadow mapping: the first one sets
the mapping read-only while the other clears the mapping.
Refactor and create kasan_update_early_region()
Signed-off-by: Christophe Leroy
---
arch/powerpc/mm/kasan
512k pages are now standard pages, so only 8M pages
are hugepte.
No more handling of normal page tables through hugepd allocation
and freeing, and hugepte helpers can also be simplified.
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/nohash/32/hugetlb-8xx.h | 7 +++
arch/powe
Em Thu, Apr 23, 2020 at 08:00:54PM +0900, Masami Hiramatsu escreveu:
> Hi,
>
> Here is a series of fixes related to __init function and
> blacklist checking routines. Arnaldo noticed me some cases
> which don't check the __init function checking. I found that
> the blacklist checking is also not w
Allocate static page tables for the fixmap area. This allows
setting mappings through page tables before memblock is ready.
That's needed to use early_ioremap() early and to use standard
page mappings with fixmap.
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/fixmap.h | 4
a
Prepare ITLB handler to handle _PAGE_HUGE when CONFIG_HUGETLBFS
is enabled. This means that the L1 entry has to be kept in r11
until L2 entry is read, in order to insert _PAGE_HUGE into it.
Also move pgd_offset helpers before pte_update() as they
will be needed there in next patch.
Signed-off-by:
PPC64 takes 3 additional parameters compared to PPC32:
- mm
- address
- huge
These 3 parameters will be needed in order to perform different
action depending on the page size on the 8xx.
Make pte_update() prototype identical for PPC32 and PPC64.
This allows dropping an #ifdef in huge_ptep_get_an
Mapping RO data as ROX is not an issue since that data
cannot be modified to introduce an exploit.
PPC64 accepts to have RO data mapped ROX, as a trade off
between kernel size and strictness of protection.
On PPC32, kernel size is even more critical as amount of
memory is usually small.
Dependin
When CONFIG_PTE_64BIT is set, pte_update() operates on
'unsigned long long'
When CONFIG_PTE_64BIT is not set, pte_update() operates on
'unsigned long'
In asm/page.h, we have pte_basic_t which is 'unsigned long long'
when CONFIG_PTE_64BIT is set and 'unsigned long' otherwise.
Refactor pte_update()
pte_update() is a bit special for the 8xx. At the time
being, that's an #ifdef inside the nohash/32 pte_update().
As we are going to make it even more special in the coming
patches, create a dedicated version for pte_update() for 8xx.
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm
The 8xx is about to map kernel linear space and IMMR using huge
pages.
In order to display those pages properly, ptdump needs to handle
hugepd tables at PGD level.
For the time being do it only at PGD level. Further patches may
add handling of hugepd tables at lower level for other platforms
when
On Mon, May 4, 2020 at 1:52 PM Alexei Starovoitov
wrote:
>
> On Thu, Apr 30, 2020 at 11:03 AM Alexei Starovoitov
> wrote:
> >
> > Hi Ingo,
> >
> > I'd like to pull
> > commit 980737282232 ("capabilities: Introduce CAP_PERFMON to kernel
> > and user space")
> > into bpf-next to base my CAP_BPF wor
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
---
arch/po
On PPC32, __ptep_test_and_clear_young() takes the mm->context.id
In preparation of standardising pte_update() params between PPC32 and
PPC64, __ptep_test_and_clear_young() need mm instead of mm->context.id
Replace context param by mm.
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/as
Doing kasan pages allocation in MMU_init is too early, kernel doesn't
have access yet to the entire memory space and memblock_alloc() fails
when the kernel is a bit big.
Do it from kasan_init() instead.
Fixes: 2edb16efc899 ("powerpc/32: Add KASAN support")
Cc: sta...@vger.kernel.org
Signed-off-by
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
Reorder flags in a more logical way:
- Page size (huge) first
- User
- RWX
- Present
- WIMG
- Special
- Dirty and Accessed
Signed-off-by: Christophe Leroy
---
arch/powerpc/mm/ptdump/8xx.c| 30 +++---
arch/powerpc/mm/ptdump/shared.c | 30 +++---
Hi Eizan,
Thank you for the patch.
Missatge de Eizan Miyamoto del dia dc., 6 de maig
2020 a les 10:41:
>
> Broadly, this patch (1) adds a driver for various MTK MDP components to
> go alongside the main MTK MDP driver, and (2) hooks them all together
> using the component framework.
>
> (1) Up u
Hi Nick,
> Ilie, may I put your authorship and signed off by tag on the V2?
Yes, of course. With the current global situation I took some time off
and didn't follow the latest discussion.
Feel free to credit/rework the code as you see fit.
Thanks,
I.H.
On Tue, May 05, 2020 at 03:54:03PM +0200, Thomas Gleixner wrote:
> From: Thomas Gleixner
>
> Convert various hypervisor vectors to IDTENTRY_SYSVEC
> - Implement the C entry point with DEFINE_IDTENTRY_SYSVEC
> - Emit the ASM stub with DECLARE_IDTENTRY_SYSVEC
> - Remove the ASM idtentries in
On Wed, 6 May 2020 at 18:03, Valentin Schneider
wrote:
>
>
> On 06/05/20 14:45, Vincent Guittot wrote:
> >> But then we may skip an update if we goto abort, no? Imagine we have just
> >> NOHZ_STATS_KICK, so we don't call any rebalance_domains(), and then as we
> >> go through the last NOHZ CPU in
On Mon, Apr 27, 2020 at 09:18:00AM +0200, Thierry Reding wrote:
> On Tue, Apr 07, 2020 at 12:05:20PM +0200, Thierry Reding wrote:
> > On Wed, Dec 04, 2019 at 03:21:38PM +0530, Viresh Kumar wrote:
> > > On 04-12-19, 10:33, Thierry Reding wrote:
> > > > Yeah, the code that registers this device is in
On Thu, Mar 19, 2020 at 10:02:17PM +0300, Dmitry Osipenko wrote:
> Hello,
>
> This series moves intermediate-clk handling from tegra20-cpufreq into
> tegra-clk driver. This allows us to switch to generic cpufreq-dt driver
> which brings voltage scaling, per-hardware OPPs and Tegra30 support out
>
From: Ilie Halip
It turns out that if your config tickles __builtin_constant_p via
differences in choices to inline or not, this now produces invalid
assembly:
$ cat foo.c
long a(long b, long c) {
asm("orb\t%1, %0" : "+q"(c): "r"(b));
return c;
}
$ gcc foo.c
foo.c: Assembler messages:
foo.c:
On Tue, May 05, 2020 at 07:10:20PM +0530, Calvin Johnson wrote:
> fwnode_find_reference() doesn't return NULL and hence that check
> should be avoided.
>
> Signed-off-by: Calvin Johnson
> ---
>
> drivers/hwtracing/coresight/coresight-cti-platform.c | 4 ++--
> 1 file changed, 2 insertions(+), 2
06.05.2020 19:41, Sam Ravnborg пишет:
> On Sat, Apr 18, 2020 at 08:06:59PM +0300, Dmitry Osipenko wrote:
>> When graph isn't defined in a device-tree, the of_graph_get_remote_node()
>> prints a noisy error message, telling that port node is not found. This is
>> undesirable behaviour in our case be
Peter Zijlstra writes:
> On Wed, May 06, 2020 at 09:08:31AM -0700, Sean Christopherson wrote:
>> On Tue, May 05, 2020 at 03:16:22PM +0200, Thomas Gleixner wrote:
>> > Provide also a set of markers: instr_begin()/end()
>> >
>> > These are used to mark code inside a noinstr function which calls
>>
On 6/05/20 5:34 pm, Veerabhadrarao Badiganti wrote:
> In the request completion path with CQE, request type is being checked
> after the request is getting completed. This is resulting in returning
> the wrong request type and leading to the IO hang issue.
>
> ASYNC request type is getting returne
Hi Eizan,
Thank you for the patch.
Missatge de Eizan Miyamoto del dia dc., 6 de maig
2020 a les 10:42:
>
> Without this change, the MDP components are not fully integrated into
> the runtime power management subsystem, and the MDP driver does not
> work.
>
> For each of the component device driv
On Wed, 2020-05-06 at 13:51 +0300, Andy Shevchenko wrote:
> On Wed, May 6, 2020 at 8:46 AM Lukas Bulwahn wrote:
> > Hi Pierre,
> >
> > with your commit de267a7c71ba ("s390/pci: Documentation for zPCI"),
> > visible on next-20200505, ./scripts/checkpatch.pl -f MAINTAINERS
> > complains:
> >
> > W
On 5/5/20 3:16 PM, Thomas Gleixner wrote:
From: Paul E. McKenney
The rcu_nmi_enter_common() and rcu_nmi_exit_common() functions take an
"irq" parameter that indicates whether these functions are invoked from
an irq handler (irq==true) or an NMI handler (irq==false). However,
recent changes h
Wei Liu writes:
>> --- a/arch/x86/entry/entry_32.S
>> +++ b/arch/x86/entry/entry_32.S
>> @@ -1342,20 +1342,6 @@ BUILD_INTERRUPT3(xen_hvm_callback_vector
>> xen_evtchn_do_upcall)
>> #endif
>>
>
> You seem to have missed the Xen entry.
See the next patch ...
Alexei Starovoitov writes:
>
> I'd like to pull
> commit 980737282232 ("capabilities: Introduce CAP_PERFMON to kernel
> and user space")
> into bpf-next to base my CAP_BPF work on top of it.
> could you please prepare a stable tag for me to pull ?
> Last release cycle Thomas did a tag for bpf+rt p
On Wed, 6 May 2020 08:39:47 +0200 Bartosz Golaszewski wrote:
> wt., 5 maj 2020 o 19:31 Jakub Kicinski napisał(a):
> >
> > On Tue, 5 May 2020 16:02:25 +0200 Bartosz Golaszewski wrote:
> > > From: Bartosz Golaszewski
> > >
> > > Provide devm_register_netdev() - a device resource managed variant
On Fri, Apr 17, 2020 at 07:05:37PM +0200, Thierry Reding wrote:
> From: Thierry Reding
>
> When the XUDC device is idle (i.e. powergated), care must be taken not
> to access any registers because that would lead to a crash.
>
> Move the call to tegra_xudc_device_mode_off() into the same conditio
Changes in v2:
- renamed resume and pause commands to enable and disable ones, renamed
CTL_CMD_RESUME and CTL_CMD_PAUSE to CTL_CMD_ENABLE and CTL_CMD_DISABLE
to fit to the appropriate ioctls and avoid mixing up with PAUSE_OUTPUT
ioctl;
- factored out event handling loop into a handle_events
On Wed, May 6, 2020 at 6:51 AM Peter Zijlstra wrote:
>
> I was hoping for:
>
> bar:# @bar
> movl%edi, .L_x$local(%rip)
> retq
> ponies: # @ponies
> movq.Lfoo$
On 05/06, Steven Rostedt wrote:
>
> As this is in the kernel/events/ directory, I'm guessing it should be taken
> through the tip tree?
this would be great, thanks Steven.
Oleg.
> -Original Message-
> From: Kishon Vijay Abraham I
> Sent: 17 April 2020 12:43
> To: Tom Joseph ; Bjorn Helgaas
> ; Rob Herring ; Lorenzo
> Pieralisi ; Andrew Murray
>
> Cc: linux-...@vger.kernel.org; devicet...@vger.kernel.org; linux-
> ker...@vger.kernel.org
> Subject: [PATCH v2 0/4]
On Tue, May 05, 2020 at 06:47:39PM +0200, Michał Mirosław wrote:
> On Tue, May 05, 2020 at 05:52:28PM +0200, Wolfram Sang wrote:
[...]
> > > BTW, I found this comment in i2c-core.h:
> > >
> > > * We only allow atomic transfers for very late communication, e.g. to
> > > send
> > > * the powerdow
On Tue, May 5, 2020 at 10:52 PM Jiaxun Yang wrote:
>
> Subject: [PATCH v6] MIPS: Truncate link address into 32bit for 32bit kernel
> In-Reply-To: <20200413062651.3992652-1-jiaxun.y...@flygoat.com>
>
> LLD failed to link vmlinux with 64bit load address for 32bit ELF
> while bfd will strip 64bit add
On Wed, 6 May 2020 09:09:52 +0200 Bartosz Golaszewski wrote:
> > > +}
> >
> > Why do you clean the TX ring from a work rather than from the NAPI
> > context?
>
> So this was unclear to me, that's why I went with a workqueue. The
> budget argument in napi poll is for RX. Should I put some cap on
On Wed, 6 May 2020 07:51:36 +0200 (CEST) Lukas Bulwahn wrote:
> Hi Jakub,
>
> with your commit 9b038086f06b ("docs: networking: convert DIM to RST"),
> visible on next-20200505, ./scripts/checkpatch.pl -f MAINTAINERS
> complains:
>
> WARNING: Misordered MAINTAINERS entry - list file patterns in
A user is not required to set a new address when using
MREMAP_DONTUNMAP as it can be used without MREMAP_FIXED.
When doing so the remap event will use new_addr which may not
have been set and we didn't propagate it back other then
in the return value of remap_to.
Because ret is always the new addr
Hi Wei,
Thank you for your patch.
On 6/5/20 16:13, Wei Yongjun wrote:
> Add the missing platform_device_unregister() before return
> from mtk_mmsys_probe() in the error handling case.
>
> Fixes: 667c769246b0 ("soc / drm: mediatek: Fix mediatek-drm device probing")
> Signed-off-by: Wei Yongjun
On Fri, May 01, 2020 at 10:29:03PM +0200, Peter Zijlstra wrote:
> +++ b/arch/x86/include/asm/static_call.h
> @@ -30,4 +30,14 @@
> ".size " STATIC_CALL_TRAMP_STR(name) ", . - "
> STATIC_CALL_TRAMP_STR(name) " \n" \
> ".popsection\n")
>
>
The pull request you sent on Wed, 6 May 2020 15:10:06 +1000:
> git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6.git linus
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/3c40cdb0e93ec166f1fa4fee1eb62d45b5451515
Thank you!
--
Deet-doot-dot, I am a bot.
The following commit has been merged into the x86/cpu branch of tip:
Commit-ID: 3e2c1fd2022ccce96b6a05a6ab519d65769ee320
Gitweb:
https://git.kernel.org/tip/3e2c1fd2022ccce96b6a05a6ab519d65769ee320
Author:Kim Phillips
AuthorDate:Fri, 17 Apr 2020 09:33:56 -05:00
Committer:
On Wed, May 6, 2020 at 1:22 PM Brian Geffon wrote:
>
> A user is not required to set a new address when using
> MREMAP_DONTUNMAP as it can be used without MREMAP_FIXED.
> When doing so the remap event will use new_addr which may not
> have been set and we didn't propagate it back other then
> in t
Le 06/05/2020 à 12:38, Andy Shevchenko a écrit :
On Wed, May 6, 2020 at 6:55 AM Christophe JAILLET
wrote:
This looks really unusual to have a 'get_device()' hidden in a 'dev_err()'
call.
Remove it.
While at it add a missing \n at the end of the message.
It should have Fixes tag because it
On Fri, May 01, 2020 at 10:28:49PM +0200, Peter Zijlstra wrote:
> static_call(), is the idea of static_branch() applied to indirect function
> calls. Remove a data load (indirection) by modifying the text.
>
> The inline implementation still relies on objtool to generate the
> .static_call_sites s
It hasn't landed in a stable kernel yet, 5.7 is rc4 so I don't think
it needs to cc stable, right?
Andrew, I'd be happy to mail a new patch if necessary, otherwise here
is the fixes:
Fixes: e346b38 ("mm/mremap: add MREMAP_DONTUNMAP to mremap()")
Brian
On Wed, May 6, 2020 at 10:28 AM Joel Ferna
Hi Murali,
Murali Karicheri writes:
> Fix following sparse checker warning:-
>
> net/hsr/hsr_slave.c:38:18: warning: incorrect type in assignment (different
> base types)
> net/hsr/hsr_slave.c:38:18:expected unsigned short [unsigned] [usertype]
> protocol
> net/hsr/hsr_slave.c:38:18:go
On 2020-05-06, Nick Desaulniers wrote:
On Wed, May 6, 2020 at 8:46 AM 'Fangrui Song' via Clang Built Linux
wrote:
Created https://reviews.llvm.org/D79495 to allow the function attribute
'patchable_function_entry' on aarch64_be.
I think -fpatchable-function-entry= just works.
Note, LLD does not
On 5/6/20 12:30 PM, John Stultz wrote:
> On Wed, May 6, 2020 at 9:04 AM Andrew F. Davis wrote:
>> On 5/4/20 4:50 AM, Brian Starkey wrote:
>>> On Fri, May 01, 2020 at 11:40:16AM -0700, John Stultz wrote:
So the name we expose is the CMA name itself. So with dt it will be
the name of the r
Hi,
On Wed, May 6, 2020 at 9:42 AM Daniel Thompson
wrote:
>
> Currently there is a small window where a badly timed migration could
> cause in_dbg_master() to spuriously return true. Specifically if we
> migrate to a new core after reading the processor id and the previous
> core takes a breakpoi
On Wed, May 06, 2020 at 12:22:37PM -0400, Qian Cai wrote:
> == task struck leaks ==
> There are leaks from task struct from time to time where someone forgot to
> call put_task_struct() somewhere leading to leaks. For example,
>
> https://lore.kernel.org/lkml/c1ccbdac-a453-4ff2-908f-0b6e35622...@
On Wed, Apr 22, 2020 at 03:18:26PM +0800, Jason Yan wrote:
> Fix the following coccicheck warning:
>
> drivers/video/fbdev/i810/i810_main.c:1969:3-7: WARNING: Assignment of
> 0/1 to bool variable
> drivers/video/fbdev/i810/i810_main.c:1971:3-8: WARNING: Assignment of
> 0/1 to bool variable
> drive
From: Serge Semin
It's a Cluster Power Controller embedded into the MIPS IP cores.
Currently the corresponding dts node is supposed to have compatible
and reg properties.
Signed-off-by: Serge Semin
Cc: Alexey Malahov
Cc: Thomas Bogendoerfer
Cc: Paul Burton
Cc: Ralf Baechle
Cc: Arnd Bergmann
From: Serge Semin
According to the MIPS32 InterAptiv software manual error codes 24 - 26
of CM2 indicate L2 ECC/parity error with switching to a corresponding
errors info fields. This patch provides these errors parsing code,
which handles the read/write uncorrectable and correctable ECC/parity
e
From: Serge Semin
This is a first patchset of a series of about 25 ones, which are intended to
add the full Baikal-T1 SoC [1] support to the Linux kernel. Since they will
concern various kernel subsystems, I decided to split the whole work up into
the patchesets in accordance with the subsystems/
From: Serge Semin
Add "BAIKAL ELECTRONICS, JSC" to the list of devicetree vendor prefixes
as "baikal".
Website: http://www.baikalelectronics.com
Signed-off-by: Serge Semin
Cc: Alexey Malahov
Cc: Thomas Bogendoerfer
Cc: Paul Burton
Cc: Ralf Baechle
Cc: Arnd Bergmann
Cc: linux-m...@vger.ker
From: Serge Semin
CP0 config register may indicate whether write-through merging
is allowed. Currently there are two types of the merging available:
SysAD Valid and Full modes. Whether each of them are supported by
the core is implementation dependent. Moreover whether the ability
to change the m
From: Serge Semin
Commit 1aeba347b3a9 ("MIPS: Hardcode cpu_has_mips* where target ISA
allows") updated the cpu_has_mips* macro to be replaced with a constant
expression where it's possible. By mistake it wasn't done correctly
for cpu_has_mips64r1/cpu_has_mips64r2 macro. They are defined to
be rep
On Thu, May 07, 2020 at 12:48:47AM +0800, Jia-Ju Bai wrote:
>
>
> On 2020/5/6 23:52, Greg KH wrote:
> > On Wed, May 06, 2020 at 11:30:22PM +0800, Jia-Ju Bai wrote:
> > >
> > > On 2020/5/6 19:07, Greg KH wrote:
> > > > On Wed, May 06, 2020 at 06:13:01PM +0800, Jia-Ju Bai wrote:
> > > > > I have n
From: Serge Semin
There are bit fields which persist in the MIPS CONFIG and CONFIG6
registers, but haven't been described in the generic mipsregs.h
header so far. In particular, the generic CONFIG bitfields are
BE - endian mode, BM - burst mode, SB - SimpleBE, OCP interface mode
indicator, UDI -
From: Serge Semin
This is a MIPS32 Release 5 based IP core with XPA, EVA, dual/quad issue
exec pipes, MMU with two-levels TLB, UCA, MSA, MDU core level features
and system level features like up to six P5600 calculation cores, CM2
with L2 cache, IOCU/IOMMU (though might be unused depending on the
From: Serge Semin
There are five MIPS32/64 architecture releases currently available:
from 1 to 6 except fourth one, which was intentionally skipped.
Three of them can be called as major: 1st, 2nd and 6th, that not only
have some system level alterations, but also introduced significant
core/ISA
From: Serge Semin
Commit 3885c2b463f6 ("MIPS: CM: Add support for reporting CM cache
errors") adds cm2_causes[] array with map of error type ID and
pointers to the short description string. There is a mistake in
the table, since according to MIPS32 manual CM2_ERROR_TYPE = {17,18}
correspond to IN
From: Serge Semin
It's a Common Device Memory Map controller embedded into the MIPS IP
cores, which dts node is supposed to have compatible and reg properties.
Signed-off-by: Serge Semin
Cc: Alexey Malahov
Cc: Thomas Bogendoerfer
Cc: Paul Burton
Cc: Ralf Baechle
Cc: Arnd Bergmann
Cc: linux
On Tue, May 5, 2020 at 11:22 PM Christoph Hellwig wrote:
>
> This matches the convention of always having _unsafe as a suffix, as
> well as match the naming of strncpy_from_user_unsafe.
Hmm. While renaming them, can we perhaps clarify what the rules are?
We now have two different kinds of "unsaf
From: Serge Semin
Since having and mapping the CDMM block is platform specific, then
instead of just returning a zero-address, lets make the default CDMM
base address search method (mips_cdmm_phys_base()) to do something
useful. For instance to find the address in a dedicated dtb-node in
order to
From: Serge Semin
Indeed according to the P5600/P6000 manual the MAAR pair register
address field either takes [12:31] bits for 32-bits non-XPA systems
and [12:35] otherwise. In any case the current address mask is just
wrong for 64-bit and 32-bits XPA chips. So lets extend it to 39-bits
value. T
From: Serge Semin
When XPA mode is enabled the normally 32-bits MAAR pair registers
are extended to be of 64-bits width as in pure 64-bits MIPS
architecture. In this case the MAAR registers can enable the
speculative loads/stores for addresses of up to 39-bits width.
But in this case the process
From: Serge Semin
Some platforms may prohibit to access the IO-memory with instructions
of certain memory widths. For instance Bailal-T1 has devices placed
behind memory OCP port (which also the reason of DMA accesses being
incoherent) and can't be accessed through CCA uncacheable memory with
oth
From: Serge Semin
Due to being embedded into the CPU cores MIPS count/compare timer
frequency is changed together with the CPU clocks alteration.
In case if frequency really changes the kernel clockevent framework
must be notified, otherwise the kernel timers won't work correctly.
Fix this by cal
From: Serge Semin
Similar to commit 8e5c62e38a88 ("mips: early_printk_8250: Use offset-sized
IO-mem accessors") the IO-memory might require to use a proper load/store
instructions (like Bailal-T1 IO-memory). To fix the cps-vec UART debug
printout lets use the memory access instructions in accorda
From: Serge Semin
Loops-per-jiffies is a special number which represents a number of
noop-loop cycles per CPU-scheduler quantum - jiffies. As you
understand aside from CPU-specific implementation it depends on
the CPU frequency. So when a platform has the CPU frequency fixed,
we have no problem a
From: Serge Semin
Recent commit e61a41256edf ("cpufreq: dev_pm_qos_update_request() can
return 1 on success") fixed a problem when active policies traverse
was falsely stopped due to invalidly treating the non-zero return value
from freq_qos_update_request() method as an error. Yes, that function
From: Serge Semin
CDMM may be available not only MIPS R2 architectures, but also in
newer MIPS R5 chips. For instance our P5600 chip has one. Lets mark
the CDMM bus being supported for that MIPS arch too.
Co-developed-by: Alexey Malahov
Signed-off-by: Alexey Malahov
Signed-off-by: Serge Semin
801 - 900 of 1502 matches
Mail list logo
