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 consi
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 consi
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
> http
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.
Applicatio
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. We
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
>发件人: Michael Ellerman
>发送时间: 2022年6月14日 18:45
>收件人: Wang Wenhu ; gre...@linuxfoundation.org
>; christophe.le...@csgroup.eu
>
>抄送: linuxppc-dev@lists.ozlabs.org ;
>linux-ker...@vger.kernel.org ; Wang Wenhu
>
>主题: Re: [PATCH 1/2] powerpc:mm: export symbol ioremap_coherent
>
>Wang Wenhu write
> On 3 Jun 2022, at 7:04 pm, Arnd Bergmann wrote:
>
> On Wed, Jun 1, 2022 at 7:48 AM Rohan McLure wrote:
>>
>> Syscall wrapper implemented as per s390, x86, arm64, providing the
>> option for gprs to be cleared on entry to the kernel, reducing caller
>> influence influence on speculation within
arndb.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, da...@dave
arndb.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, da...@dave
arndb.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, da...@dave
arndb.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, da...@dave
rtualizat...@lists.linux-foundation.org>,
"james.bottom...@hansenpartnership.com"
, "jcmvb...@gmail.com"
, "thierry.red...@gmail.com" ,
"ker...@xen0n.name" , "quic_neer...@quicinc.com"
, linux-s390 ,
"vschn...@redhat.com" , "john.ogn...@linutronix.de"
, "ys...@users.sourceforge.jp"
, "feste
arndb.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, da...@dave
arndb.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, da...@dave
arndb.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, da...@dave
arndb.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, da...@dave
arndb.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, da...@dave
arndb.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, da...@dave
arndb.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, da...@dave
.com, yury.no...@gmail.com, ulli.kr...@googlemail.com, vgu...@kernel.org,
linux-...@vger.kernel.org, mon...@monstr.eu, 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,
da...@davemloft.net
arndb.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, da...@dave
� ��W(�
b�ڶ���+!��b�Z %{�J֫��"��ڲ� �w����YCy�(���G���h���b����Z���*��G���h�Z�I(I�$�w���䒊k���&I��N�ojw��ojw���
��(�֯y��E�'j�zڢX�����&1�ܠIoz࢈%y�&)�
�$��r�$r�+�����ޝ,��m��-y�`��f��+�֭��
��zYh�vz�ޖ��1���0���xzZ+�+��Z��ۥ�bz x^ũ�z�
�ނ�ޝ��{�d�
luxnic.net" , "ebied...@xmission.com"
, "aneesh.ku...@linux.ibm.com"
, "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, Jarkko" ,
"samitol
kkinen , Sami Tolvanen , "Naveen
N. Rao" , Marco Elver , Kees Cook
, Steven Rostedt , Nathan
Chancellor , "Russell King \(Oracle\)"
, Mark Brown , Borislav Petkov
, Alexander Egorenkov , Thomas
Bogendoerfer , linux-par...@vger.kernel.org,
Nathaniel McCallum , Dmitry Torokhov
, "David S. Mil
@kernel.org>, 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 , linux-par...@vger.kernel.org,
Nathaniel McCallum , Dmitry Torokhov
,
arndb.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, da...@dave
l...@kernel.org>, Masahiro Yamada , Jarkko Sakkinen
, Sami Tolvanen , "Naveen N. Rao"
, Marco Elver , Kees Cook
, Steven Rostedt , Nathan
Chancellor , "Russell King \(Oracle\)"
, Mark Brown , Borislav Petkov
, Alexander Egorenkov , Thomas
Bogendoerfer , Parisc List
, Nathaniel McCallum ,
D
On 6/10/2022 4:35 PM, ira.we...@intel.com wrote:
diff --git a/tools/testing/selftests/vm/protection_keys.c
b/tools/testing/selftests/vm/protection_keys.c
index d0183c381859..43e47de19c0d 100644
--- a/tools/testing/selftests/vm/protection_keys.c
+++ b/tools/testing/selftests/vm/protection_keys.c
On 6/10/2022 4:35 PM, ira.we...@intel.com wrote:
Add command line options for debug level and number of iterations.
$ ./protection_keys_64 -h
Usage: ./protection_keys_64 [-h,-d,-i ]
--help,-h This help
--debug,-d Increase debug level for each -d
Is this mechanism (of count
On 6/10/2022 4:35 PM, ira.we...@intel.com wrote:
glibc says it returns ENOSYS if the system does not support pkeys but I don't
see where ENOSYS is returned? AFAICS it just returns what the kernel returns.
So it is probably up to user of glibc.
Implementation of the pkeys system calls is arc
On Wed, Jun 8, 2022 at 7:52 AM Michael Ellerman wrote:
> Donald Zickus writes:
> > Hi Michael,
> >
> > I am working on two packaging issues with Fedora and CKI that I am hoping
> > you can give me some guidance on.
> >
> > 1 - Fedora has always packaged an eu-strip'd vmlinux file for powerpc.
>
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, da...@davem
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, da...@davem
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, da...@davem
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, da...@davem
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, da...@davem
�ۚ�,ڶ*'�+-�X���wZ�*'�� jg��m�i^�j�gz�!��(���z�h��&��j{ ��w���r��rkۑ�
���r��rkۑ� ���r���'��*�v)�f���&�yا�
��W(�G���qz}'��z\^�I�jg��''y�ڎꮉȧq�&�蜝�j;��'"��(�X��7�Ib��l��/���z�ޖ���!�蝭�aj�(�� �w�v\�h�z
��,�)'�^��g�
�b��k�x�u�j�.��첋�q����+���z�,���y�+���}�-z�f���&}�-z
com, Arnd Bergmann , ulli.kr...@googlemail.com,
vgu...@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, da...@davemloft.net, dal...
Em Tue, Jun 14, 2022 at 07:38:55AM -0700, Ian Rogers escreveu:
> On Fri, Jun 10, 2022 at 7:00 AM Athira Rajeev
> wrote:
> >
> > commit cfd7092c31ae ("perf test session topology: Fix test to
> > skip the test in guest environment") added check to skip the
> > testcase if the socket_id can't be fetc
PREEMPT_RT preempts softirqs and the current implementation avoids
do_softirq_own_stack() and only uses __do_softirq().
Disable the unused softirqs stacks on PREEMPT_RT to safe some memory and
ensure that do_softirq_own_stack() is not used bwcause it is not
expected.
Signed-off-by: Sebastian Andr
The kvm_trace_symbol_hcall macro is missing several of the hypercalls
defined in hvcall.h.
Add the most common ones that are issued during guest lifetime,
including the ones that are only used by QEMU and SLOF.
Signed-off-by: Fabiano Rosas
---
arch/powerpc/include/asm/hvcall.h | 8
ar
On 6/14/22 06:49, Andrew Donnellan wrote:
> Add a special case to block_rtas_call() to allow the ibm,platform-dump RTAS
> call through the RTAS filter if the buffer address is 0.
>
> According to PAPR, ibm,platform-dump is called with a null buffer address
> to notify the platform firmware that pr
Andrew Donnellan writes:
> Add a special case to block_rtas_call() to allow the ibm,platform-dump RTAS
> call through the RTAS filter if the buffer address is 0.
>
> According to PAPR, ibm,platform-dump is called with a null buffer address
> to notify the platform firmware that processing of a par
Le 14/06/2022 à 16:40, Wenhu Wang a écrit :
I looked at that patch.
I don't think you can just drop the #ifdef in function
__access_remote_vm() in mm/memory.c
You have to replace it with something like:
if (!IS_ENABLED(CONFIG_HAVE_IOREMAP_PROT))
UIO seems like the wrong kind of interface for this. Why isn't this
a simple character device?
On Tue, Jun 14, 2022 at 08:45:25PM +1000, Michael Ellerman wrote:
> Wang Wenhu writes:
> > The function ioremap_coherent may be called by modules such as
> > fsl_85xx_cache_sram. So export it for access in other modules.
>
> ioremap_coherent() is powerpc specific, and only has one other caller,
>
>>>
>>> I looked at that patch.
>>>
>>> I don't think you can just drop the #ifdef in function
>>> __access_remote_vm() in mm/memory.c
>>>
>>> You have to replace it with something like:
>>>
>>> if (!IS_ENABLED(CONFIG_HAVE_IOREMAP_PROT))
>>> break;
>>>
>>
>>
>>Another thing in that pa
Hi Erhard,
This is presumably caused by:
52b1b46c39ae ("of: Create platform devices for OF framebuffers")
Can you try the patch below?
cheers
diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index 3507095a69f6..a70ff9df5cb9 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platf
On Fri, 2022-06-03 at 08:39 +, Christophe Leroy wrote:
>
>
> Le 03/06/2022 à 09:09, Andrew Donnellan a écrit :
> > On Fri, 2022-06-03 at 13:24 +1000, Rohan McLure wrote:
> > > The implementation of ppc_personality can be immediately reworked
> > > to
> > > call ksys_personality, but I can’t d
In some cricunstances it may be interesting to reconfigure the watchdog
from inside the kernel.
On PowerPC, this may helpful before and after a LPAR migration (LPM) is
initiated, because it implies some latencies, watchdog, and especially NMI
watchdog is expected to be triggered during this operat
In pseries_migration_partition(), loop until the memory transfer is
complete. This way the calling drmgr process will not exit earlier,
allowing callbacks to be run only once the migration is fully completed.
If reading the VASI state is done after the hypervisor has completed the
migration, the H
During a LPM, while the memory transfer is in progress on the arrival side,
some latencies is generated when accessing not yet transferred pages on the
arrival side. Thus, the NMI watchdog may be triggered too frequently, which
increases the risk to hit a NMI interrupt in a bad place in the kernel,
Introduce a factor which would apply to the NMI watchdog timeout.
This factor is a percentage added to the watchdog_tresh value. The value is
set under the watchdog_mutex protection and lockup_detector_reconfigure()
is called to recompute wd_panic_timeout_tb.
Once the factor is set, it remains un
When a partition is transferred, once it arrives at the destination node,
the partition is active but much of its memory must be transferred from the
start node.
It depends on the activity in the partition, but the more CPU the partition
has, the more memory to be transferred is likely to be. This
Add a special case to block_rtas_call() to allow the ibm,platform-dump RTAS
call through the RTAS filter if the buffer address is 0.
According to PAPR, ibm,platform-dump is called with a null buffer address
to notify the platform firmware that processing of a particular dump is
finished.
Without
From: Sebastian Andrzej Siewior
> Sent: 14 June 2022 14:26
...
> > These changes seem to drop the priority from above that of the
> > highest priority RT process down to that of a default priority
> > user process.
> > There is no real guarantee that the latter will run 'any time soon'.
>
> Not su
On 2022-06-09 15:46:04 [+], David Laight wrote:
> From: Sebastian Andrzej Siewior
> > Sent: 09 June 2022 16:03
> >
> > On 2022-05-30 16:15:11 [-0700], Davidlohr Bueso wrote:
> > > Tasklets have long been deprecated as being too heavy on the system
> > > by running in irq context - and this is
On Tue, Jun 14, 2022 at 02:31:01PM +1000, Michael Ellerman wrote:
> Segher Boessenkool writes:
> > On Sat, Jun 11, 2022 at 08:42:27AM +, Christophe Leroy wrote:
> >> I'd have a preference for using a verb, for instance ZEROISE_REGS or
> >> CLEAR_REGS
> >
> > "Zero" is a verb as well (as well
Wang Wenhu writes:
> The function ioremap_coherent may be called by modules such as
> fsl_85xx_cache_sram. So export it for access in other modules.
ioremap_coherent() is powerpc specific, and only has one other caller,
I'd like to remove it.
Does ioremap_cache() work for you?
cheers
> diff --
Always set an IBAT covering up to _einittext during init because when
CONFIG_MODULES is not selected there is no reason to have an exception
handler for kernel instruction TLB misses.
It implies DBAT and IBAT are now totaly independent, IBATs are set
by setibat() and DBAT by setbat().
This allows
mark_initmem_nx() calls either mmu_mark_initmem_nx() or
set_memory_attr() based on return from v_block_mapped()
of _sinittext.
But we can now handle text and data independently, so that
text may be mapped by block even when data is mapped by pages.
On the 8xx for instance, at startup 32Mbytes of
Mapping without BATs doesn't bring any added value to the user.
Remove that option.
Signed-off-by: Christophe Leroy
---
Documentation/admin-guide/kernel-parameters.txt | 3 ---
arch/powerpc/mm/book3s32/mmu.c | 2 +-
arch/powerpc/mm/init_32.c | 11 ---
__map_without_ltlbs is used only for 40x, and only when
STRICT_KERNEL_RWX, KFENCE or DEBUG_PAGEALLOC is active.
Do the verification directly in 40x version of mmu_mapin_ram()
and remove __map_without_ltlbs from core ppc32.
Signed-off-by: Christophe Leroy
---
arch/powerpc/mm/init_32.c| 23 --
Mapping without large TLBs has no added value on the 8xx.
Mapping without large TLBs is still necessary on 40x when
selecting CONFIG_KFENCE or CONFIG_DEBUG_PAGEALLOC or
CONFIG_STRICT_KERNEL_RWX, but this is done automatically
and doesn't require user selection.
Remove 'noltlbs' kernel parameter,
On Sun, 2022-06-05 at 10:00 +0400, Miaoqian Lin wrote:
> of_get_next_parent() returns a node pointer with refcount
> incremented,
> we should use of_node_put() on it when not need anymore.
> This function only calls of_node_put() in normal path,
> missing it in the error path.
> Add missing of_node
>On Tue, Jun 14, 2022 at 07:53:46AM +, Wenhu Wang wrote:
>> >> >> +
>> >> >> +struct mpc85xx_l2ctlr {
>> >> >> + u32 ctl;/* 0x000 - L2 control */
>> >> >
>> >> >What is the endian of these u32 values? You map them directly to
>> >> >memory, so they must be specified some wa
On Tue, Jun 14, 2022 at 07:53:46AM +, Wenhu Wang wrote:
> >> >> +
> >> >> +struct mpc85xx_l2ctlr {
> >> >> + u32 ctl;/* 0x000 - L2 control */
> >> >
> >> >What is the endian of these u32 values? You map them directly to
> >> >memory, so they must be specified some way, righ
>> >> +
>> >> +struct mpc85xx_l2ctlr {
>> >> + u32 ctl;/* 0x000 - L2 control */
>> >
>> >What is the endian of these u32 values? You map them directly to
>> >memory, so they must be specified some way, right? Please make it
>> >obvious what they are.
>> >
>>
>> Surely, the val
Le 14/06/2022 à 09:18, Christophe Leroy a écrit :
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_
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
> https://lk
Le 14/06/2022 à 08:34, Greg KH a écrit :
> On Tue, Jun 14, 2022 at 06:09:35AM +, Wenhu Wang wrote:
>>>
>>> Odd indentation, did you use checkpatch.pl on your patch?
>>>
>>
>> Actually, I checked with the scripts, and there was no warning here.
>> I also checked in text editors and vim, if I t
75 matches
Mail list logo
