> Le 01/06/2022 à 10:29, Christophe Leroy a écrit :
>> Le 01/06/2022 à 07:48, Rohan McLure a écrit :
>>> [Vous ne recevez pas souvent de courriers de la part de
>>> rmcl...@linux.ibm.com. Découvrez pourquoi cela peut être important à
>>> l'adresse https://aka.ms/LearnAboutSenderIdentification.]
Hi Baoquan,
On Wed, 15 Jun 2022 19:03:53 -0700 Baoquan He wrote
> On 06/14/22 at 10:04pm, Li Chen wrote:
> > From: Li Chen
> >
> > We already have struct range, so just use it.
>
> Looks good, have you tested it?
No, I don't have ppc machine, just pass compile on x86.
On 06/14/22 at 10:04pm, Li Chen wrote:
> From: Li Chen
>
> We already have struct range, so just use it.
Looks good, have you tested it?
>
> Signed-off-by: Li Chen
> ---
> arch/powerpc/kexec/file_load_64.c | 2 +-
> arch/powerpc/kexec/ranges.c | 8
> include/linux/kexec.h
et>, "ebied...@xmission.com" ,
"aneesh.ku...@linux.ibm.com" , "Edgecombe, Rick P"
, "bris...@redhat.com" ,
"wangkefeng.w...@huawei.com" , "ker...@esmil.dk"
, "jniet...@gmail.com" ,
"paul.walms...@sifive.com" , "a...@kernel.org"
, "w...@kernel.org" , "masahi...@kernel.org"
, "Sakkinen,
r...@esmil.dk>, Jordan Niethe , Atish Patra
, Alexei Starovoitov , Will Deacon
, Masahiro Yamada , Jarkko Sakkinen
, Sami Tolvanen , "Naveen N. Rao"
, Marco Elver , Kees Cook
, Steven Rostedt , Nathan
Chancellor , Mark Brown , Borislav
Petkov , Alexander Egorenkov , Thomas
Bogendoerfer ,
In mpc5121_clk_init(), of_find_compatible_node() will return a
node pointer with refcount incremented. We should use of_node_put()
when it is not used anymore.
Signed-off-by: Liang He
---
arch/powerpc/platforms/512x/clock-commonclk.c | 2 ++
1 file changed, 2 insertions(+)
diff --git
Tested-by: Sumit Dubey2 mailto:sumit.dub...@ibm.com>>
Signed-off-by: Liang He
---
arch/powerpc/platforms/85xx/sgy_cts1000.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/powerpc/platforms/85xx/sgy_cts1000.c
b/arch/powerpc/platforms/85xx/sgy_cts1000.c
index 98ae64075193..2a45b30852b2 100644
---
luxnic.net" , "ebied...@xmission.com"
, "aneesh.ku...@linux.ibm.com"
, "Edgecombe, Rick P" ,
"bris...@redhat.com" , "wangkefeng.w...@huawei.com"
, "ker...@esmil.dk" ,
"jniet...@gmail.com" , "paul.walms...@sifive.com"
, "a...@kernel.org" ,
"w...@kernel.org" , "masahi...@kernel.org"
,
ry.no...@gmail.com, ulli.kr...@googlemail.com, vgu...@kernel.org,
linux-...@vger.kernel.org, mon...@monstr.eu, rost...@goodmis.org,
r...@vger.kernel.org, b...@alien8.de, bc...@quicinc.com,
tsbog...@alpha.franken.de, linux-par...@vger.kernel.org, sudeep.ho...@arm.com,
shawn...@kernel.org,
linux.intel.com, Arnd Bergmann , ulli.kr...@googlemail.com,
vgu...@kernel.org, linux-...@vger.kernel.org, j...@joshtriplett.org,
rost...@goodmis.org, r...@vger.kernel.org, b...@alien8.de, bc...@quicinc.com,
tsbog...@alpha.franken.de, linux-par...@vger.kernel.org, sudeep.ho...@arm.com,
From: Li Chen
We already have struct range, so just use it.
Signed-off-by: Li Chen
---
arch/powerpc/kexec/file_load_64.c | 2 +-
arch/powerpc/kexec/ranges.c | 8
include/linux/kexec.h | 7 ++-
kernel/kexec_file.c | 2 +-
4 files changed, 8
, Arnd Bergmann , ulli.kr...@googlemail.com, vgu...@kernel.org,
linux-...@vger.kernel.org, j...@joshtriplett.org, rost...@goodmis.org,
r...@vger.kernel.org, b...@alien8.de, bc...@quicinc.com,
tsbog...@alpha.franken.de, linux-par...@vger.kernel.org, sudeep.ho...@arm.com,
shawn...@kernel.org,
rndb.de>, ulli.kr...@googlemail.com, vgu...@kernel.org,
linux-...@vger.kernel.org, j...@joshtriplett.org, rost...@goodmis.org,
r...@vger.kernel.org, b...@alien8.de, bc...@quicinc.com,
tsbog...@alpha.franken.de, linux-par...@vger.kernel.org, sudeep.ho...@arm.com,
shawn...@kernel.org,
Hi,
I tried this series out with mainline QEMU built with Alexey's patch [1]
and I wasn't able to get it to work. I'm using a simple QEMU command line
booting a fedora36 guest in a Power9 boston host:
sudo ./qemu-system-ppc64 \
-M
__do_IRQ() doesn't switch on hardirq stack if we are on softirq stack.
do_softirq() bail out early without doing anything when already in
an interrupt.
invoke_softirq() is on task_stack when it calls do_softirq_own_stack().
So there are neither situation where we switch from hardirq stack to
Le 25/05/2022 à 20:12, Sathvika Vasireddy a écrit :
>
> On 25/05/22 23:09, Christophe Leroy wrote:
>> Hi Sathvika,
>>
>> Le 25/05/2022 à 12:14, Sathvika Vasireddy a écrit :
>>> Hi Christophe,
>>>
>>> On 24/05/22 18:47, Christophe Leroy wrote:
This draft series adds PPC32 support to
On Wed, Jun 15, 2022 at 8:57 AM Christoph Hellwig wrote:
>
> On Tue, Jun 14, 2022 at 08:18:14PM +0200, Sebastian Andrzej Siewior wrote:
> > Disable the unused softirqs stacks on PREEMPT_RT to safe some memory and
>
> s/safe/save/
Applied to the asm-generic tree with the above fixup, thanks!
Perfect Petr, thanks for your feedback!
I'll be out for some weeks, but after that what I'm doing is to split
the series in 2 parts:
(a) The general fixes, which should be reviewed by subsystem maintainers
and even merged individually by them.
(b) The proper panic refactor, which includes the
On Wed, Jun 15, 2022 at 3:47 AM Rohan McLure wrote:
> > On 3 Jun 2022, at 7:04 pm, Arnd Bergmann wrote:
> > On Wed, Jun 1, 2022 at 7:48 AM Rohan McLure wrote:
> > What is the benefit of having a separate set of macros for this? I think
> > that
> > adds more complexity than it saves in the
On Tue, Jun 14, 2022 at 08:18:14PM +0200, Sebastian Andrzej Siewior wrote:
> Disable the unused softirqs stacks on PREEMPT_RT to safe some memory and
s/safe/save/
Le 15/06/2022 à 07:57, Wang Wenhu a écrit :
> Freescale mpc85xx l2-cache could be optionally configured as SRAM partly
> or fully. Users can make use of it as a block of independent memory that
> offers special usage, such as for debuging or other critical status info
> storage, which keeps
Did you verify that all architectures actually provide a ioremap_prot
prototype?
The header situation for ioremap* is a mess unfortunately.
Le 15/06/2022 à 07:57, Wang Wenhu a écrit :
> Freescale mpc85xx l2-cache could be optionally configured as SRAM partly
> or fully. Users can make use of it as a block of independent memory that
> offers special usage, such as for debuging or other critical status info
> storage, which keeps
As pointed out last time: uio is the wrong interface to expose sram,
and any kind of ioremap is the wrong way to map it.
Le 14/06/2022 à 08:09, Wenhu Wang a écrit :
>>> +
>>> +static const struct vm_operations_struct uio_cache_sram_vm_ops = {
>>> +#ifdef CONFIG_HAVE_IOREMAP_PROT
>>
>> Same here.
>>
>
> I tried to eliminate it in mainline
> See: [PATCH v2] mm: eliminate ifdef of HAVE_IOREMAP_PROT in .c files
>
Freescale mpc85xx l2-cache could be optionally configured as SRAM partly
or fully. Users can make use of it as a block of independent memory that
offers special usage, such as for debuging or other critical status info
storage, which keeps consistently even when the whole system crashed.
It is recommended in the "Conditional Compilation" chapter of kernel
coding-style documentation that preprocessor conditionals should not
be used in .c files wherever possible.
As for the macro CONFIG_HAVE_IOREMAP_PROT, now it's a proper chance
to eliminate it in .c files which are referencers.
This series try to push an uio driver which works on freescale mpc85xx
to configure its l2-cache-sram as a block of SRAM and enable user level
application access of the SRAM.
1/2: For coding-style consideration of macro CONFIG_HAVE_IOREMAP_PORT;
2/2: Implementation of the uio driver.
This is the
29 matches
Mail list logo
