Re: [RFC 00/20] TLB batching consolidation and enhancements
> On Jan 30, 2021, at 7:30 PM, Nicholas Piggin wrote:
>
> Excerpts from Nadav Amit's message of January 31, 2021 10:11 am:
>> From: Nadav Amit
>>
>> There are currently (at least?) 5 different TLB batching schemes in the
>> kernel:
>>
>> 1. Using mmu_gather (e.g., zap_page_range()).
>>
>> 2. Using {inc|dec}_tlb_flush_pending() to inform other threads on the
>> ongoing deferred TLB flush and flushing the entire range eventually
>> (e.g., change_protection_range()).
>>
>> 3. arch_{enter|leave}_lazy_mmu_mode() for sparc and powerpc (and Xen?).
>>
>> 4. Batching per-table flushes (move_ptes()).
>>
>> 5. By setting a flag on that a deferred TLB flush operation takes place,
>> flushing when (try_to_unmap_one() on x86).
>>
>> It seems that (1)-(4) can be consolidated. In addition, it seems that
>> (5) is racy. It also seems there can be many redundant TLB flushes, and
>> potentially TLB-shootdown storms, for instance during batched
>> reclamation (using try_to_unmap_one()) if at the same time mmu_gather
>> defers TLB flushes.
>>
>> More aggressive TLB batching may be possible, but this patch-set does
>> not add such batching. The proposed changes would enable such batching
>> in a later time.
>>
>> Admittedly, I do not understand how things are not broken today, which
>> frightens me to make further batching before getting things in order.
>> For instance, why is ok for zap_pte_range() to batch dirty-PTE flushes
>> for each page-table (but not in greater granularity). Can't
>> ClearPageDirty() be called before the flush, causing writes after
>> ClearPageDirty() and before the flush to be lost?
>
> Because it's holding the page table lock which stops page_mkclean from
> cleaning the page. Or am I misunderstanding the question?
Thanks. I understood this part. Looking again at the code, I now understand
my confusion: I forgot that the reverse mapping is removed after the PTE is
zapped.
Makes me wonder whether it is ok to defer the TLB flush to tlb_finish_mmu(),
by performing set_page_dirty() for the batched pages when needed in
tlb_finish_mmu() [ i.e., by marking for each batched page whether
set_page_dirty() should be issued for that page while collecting them ].
> I'll go through the patches a bit more closely when they all come
> through. Sparc and powerpc of course need the arch lazy mode to get
> per-page/pte information for operations that are not freeing pages,
> which is what mmu gather is designed for.
IIUC you mean any PTE change requires a TLB flush. Even setting up a new PTE
where no previous PTE was set, right?
> I wouldn't mind using a similar API so it's less of a black box when
> reading generic code, but it might not quite fit the mmu gather API
> exactly (most of these paths don't want a full mmu_gather on stack).
I see your point. It may be possible to create two mmu_gather structs: a
small one that only holds the flush information and another that also holds
the pages.
>> This patch-set therefore performs the following changes:
>>
>> 1. Change mprotect, task_mmu and mapping_dirty_helpers to use mmu_gather
>> instead of {inc|dec}_tlb_flush_pending().
>>
>> 2. Avoid TLB flushes if PTE permission is not demoted.
>>
>> 3. Cleans up mmu_gather to be less arch-dependant.
>>
>> 4. Uses mm's generations to track in finer granularity, either per-VMA
>> or per page-table, whether a pending mmu_gather operation is
>> outstanding. This should allow to avoid some TLB flushes when KSM or
>> memory reclamation takes place while another operation such as
>> munmap() or mprotect() is running.
>>
>> 5. Changes try_to_unmap_one() flushing scheme, as the current seems
>> broken to track in a bitmap which CPUs have outstanding TLB flushes
>> instead of having a flag.
>
> Putting fixes first, and cleanups and independent patches (like #2) next
> would help with getting stuff merged and backported.
I tried to do it mostly this way. There are some theoretical races which
I did not manage (or try hard enough) to create, so I did not include in
the “fixes” section. I will restructure the patch-set according to the
feedback.
Thanks,
Nadav
Re: [PATCH v4 1/2] x86/setup: always add the beginning of RAM as memblock.memory
On Sat, Jan 30, 2021 at 04:37:54PM -0800, Linus Torvalds wrote: > On Sat, Jan 30, 2021 at 2:10 PM Mike Rapoport wrote: > > > > In either case, e820__memblock_setup() won't add the range 0x - 0x1000 > > to memblock.memory and later during memory map initialization this range is > > left outside any zone. > > Honestly, this just sounds like memblock being stupid in the first place. > > Why aren't these zones padded to sane alignments? The implicit alignment of zones would be a guess. What alignment would be sane here? 1M? MAX_ORDER? pageblock_order? I'm not sure that if an architecture reports its memory at X and we use, say, round_down(X, 1M) for node[0]->node_start_pfn and zone[0]->zone_start_pfn it wouldn't cause boot failure on some system out there in the wild. > This patch smells like working around the memblock code being fragile > rather than a real fix. > > That's *particularly* true when the very line above it did a > "memblock_reserve()" of the exact same range that the memblock_add() > "adds". The most correct thing to do would have been to memblock_add(0, end_of_first_memory_bank); Somewhere at e820__memblock_setup(). But that would mean we also must change the way e820__memblock_setup() reserves memory and that seemed to me like really asking for troubles so I've limited the registration of memory to the range that's for sure reserved. A part of the problem is that x86 adds only usable memory to memblock.memory omitting holes and reserved areas, while free_area_init() presumes that memblock.memory covers populated physical memory. I've tried implicitly adding ranges from memblock.reserved to memblock.memory if they were not there and it had broken some arm machines: https://lore.kernel.org/lkml/127999c4-7d56-0c36-7f88-8e1a5c934...@collabora.com I do feel that free_area_init() is fragile and no doubt there is a room for improvement there. But I think the safer way forward is to reduce inconsistencies between arch and generic code, so that we won't need to guess what is the memory layout at free_area_init() time. > Linus -- Sincerely yours, Mike.
[PATCH] staging:rtl8712: remove unused enum WIFI_STATUS_CODE
Improve readability.
Signed-off-by: Ivan Safonov
---
drivers/staging/rtl8712/wifi.h | 14 --
1 file changed, 14 deletions(-)
diff --git a/drivers/staging/rtl8712/wifi.h b/drivers/staging/rtl8712/wifi.h
index 601d4ff607bc..1b32b3510093 100644
--- a/drivers/staging/rtl8712/wifi.h
+++ b/drivers/staging/rtl8712/wifi.h
@@ -101,20 +101,6 @@ enum WIFI_REASON_CODE {
_RSON_PMK_NOT_AVAILABLE_= 24,
};
-enum WIFI_STATUS_CODE {
- _STATS_SUCCESSFUL_ = 0,
- _STATS_FAILURE_ = 1,
- _STATS_CAP_FAIL_= 10,
- _STATS_NO_ASOC_ = 11,
- _STATS_OTHER_ = 12,
- _STATS_NO_SUPP_ALG_ = 13,
- _STATS_OUT_OF_AUTH_SEQ_ = 14,
- _STATS_CHALLENGE_FAIL_ = 15,
- _STATS_AUTH_TIMEOUT_= 16,
- _STATS_UNABLE_HANDLE_STA_ = 17,
- _STATS_RATE_FAIL_ = 18,
-};
-
enum WIFI_REG_DOMAIN {
DOMAIN_FCC = 1,
DOMAIN_IC = 2,
--
2.26.2
[PATCH] staging:r8188eu: replace enum WIFI_STATUS_CODE with native kernel definitions
Driver and kernel definitions are equal.
Avoid code duplication, improve readability.
Signed-off-by: Ivan Safonov
---
drivers/staging/rtl8188eu/core/rtw_mlme_ext.c | 44 +--
drivers/staging/rtl8188eu/include/wifi.h | 14 --
2 files changed, 22 insertions(+), 36 deletions(-)
diff --git a/drivers/staging/rtl8188eu/core/rtw_mlme_ext.c
b/drivers/staging/rtl8188eu/core/rtw_mlme_ext.c
index 8794907a39f4..ebd9b96a8211 100644
--- a/drivers/staging/rtl8188eu/core/rtw_mlme_ext.c
+++ b/drivers/staging/rtl8188eu/core/rtw_mlme_ext.c
@@ -779,7 +779,7 @@ static void issue_auth(struct adapter *padapter, struct
sta_info *psta,
/* setting auth algo number */
val16 = (u16)psta->authalg;
- if (status != _STATS_SUCCESSFUL_)
+ if (status != WLAN_STATUS_SUCCESS)
val16 = 0;
if (val16) {
@@ -2675,13 +2675,13 @@ static unsigned int OnAuth(struct adapter *padapter,
DBG_88E("auth rejected due to bad alg [alg=%d, auth_mib=%d]
%02X%02X%02X%02X%02X%02X\n",
algorithm, auth_mode, sa[0], sa[1], sa[2], sa[3],
sa[4], sa[5]);
- status = _STATS_NO_SUPP_ALG_;
+ status = WLAN_STATUS_NOT_SUPPORTED_AUTH_ALG;
goto auth_fail;
}
if (!rtw_access_ctrl(padapter, sa)) {
- status = _STATS_UNABLE_HANDLE_STA_;
+ status = WLAN_STATUS_AP_UNABLE_TO_HANDLE_NEW_STA;
goto auth_fail;
}
@@ -2692,7 +2692,7 @@ static unsigned int OnAuth(struct adapter *padapter,
pstat = rtw_alloc_stainfo(pstapriv, sa);
if (!pstat) {
DBG_88E(" Exceed the upper limit of supported
clients...\n");
- status = _STATS_UNABLE_HANDLE_STA_;
+ status = WLAN_STATUS_AP_UNABLE_TO_HANDLE_NEW_STA;
goto auth_fail;
}
@@ -2724,7 +2724,7 @@ static unsigned int OnAuth(struct adapter *padapter,
if ((pstat->auth_seq + 1) != seq) {
DBG_88E("(1)auth rejected because out of seq [rx_seq=%d,
exp_seq=%d]!\n",
seq, pstat->auth_seq + 1);
- status = _STATS_OUT_OF_AUTH_SEQ_;
+ status = WLAN_STATUS_UNKNOWN_AUTH_TRANSACTION;
goto auth_fail;
}
@@ -2737,7 +2737,7 @@ static unsigned int OnAuth(struct adapter *padapter,
} else {
DBG_88E("(2)auth rejected because out of seq
[rx_seq=%d, exp_seq=%d]!\n",
seq, pstat->auth_seq + 1);
- status = _STATS_OUT_OF_AUTH_SEQ_;
+ status = WLAN_STATUS_UNKNOWN_AUTH_TRANSACTION;
goto auth_fail;
}
} else { /* shared system or auto authentication */
@@ -2757,7 +2757,7 @@ static unsigned int OnAuth(struct adapter *padapter,
if (!p || ie_len <= 0) {
DBG_88E("auth rejected because challenge
failure!(1)\n");
- status = _STATS_CHALLENGE_FAIL_;
+ status = WLAN_STATUS_CHALLENGE_FAIL;
goto auth_fail;
}
@@ -2768,13 +2768,13 @@ static unsigned int OnAuth(struct adapter *padapter,
pstat->expire_to = pstapriv->assoc_to;
} else {
DBG_88E("auth rejected because challenge
failure!\n");
- status = _STATS_CHALLENGE_FAIL_;
+ status = WLAN_STATUS_CHALLENGE_FAIL;
goto auth_fail;
}
} else {
DBG_88E("(3)auth rejected because out of seq
[rx_seq=%d, exp_seq=%d]!\n",
seq, pstat->auth_seq + 1);
- status = _STATS_OUT_OF_AUTH_SEQ_;
+ status = WLAN_STATUS_UNKNOWN_AUTH_TRANSACTION;
goto auth_fail;
}
}
@@ -2782,7 +2782,7 @@ static unsigned int OnAuth(struct adapter *padapter,
/* Now, we are going to issue_auth... */
pstat->auth_seq = seq + 1;
- issue_auth(padapter, pstat, (unsigned short)(_STATS_SUCCESSFUL_));
+ issue_auth(padapter, pstat, (unsigned short)(WLAN_STATUS_SUCCESS));
if (pstat->state & WIFI_FW_AUTH_SUCCESS)
pstat->auth_seq = 0;
@@ -2892,7 +2892,7 @@ static unsigned int OnAssocReq(struct adapter *padapter,
int i, wpa_ie_len, left;
unsigned char supportRate[16];
int supportRateNum;
- unsigned short status = _STATS_SUCCESSFUL_;
+ unsigned short status = WLAN_STATUS_SUCCESS;
unsigned short frame_type, ie_offset = 0;
struct mlme_priv *pmlmepriv = &padapter->mlmepriv;
[PATCH 3/3] MIPS: ftrace: Add DYNAMIC_FTRACE_WITH_REGS support
In the past, we have always used the address of _mcount as the address of
ftrace_caller. It reduces one ftrace_modify_code operation when do ftrace
on modules on 64Bit platform in this way. In order to provide
DYNAMIC_FTRACE_WITH_REGS, we have to take _mcount out of ftrace_caller and
add a new definition of _mcount. It is necessary to modify 2 instructions.
Also add the definition of ftrace_regs_caller. ftrace_regs_caller will
store and restore more registers. Of course, some functions in ftrace.c
also need to consider ftrace_regs_caller. Modify these functions and add
the related code of ftrace_regs_caller.
Signed-off-by: Jinyang He
---
arch/mips/Kconfig | 1 +
arch/mips/include/asm/ftrace.h | 5 ++
arch/mips/kernel/ftrace.c | 159 -
arch/mips/kernel/mcount.S | 137 +--
4 files changed, 229 insertions(+), 73 deletions(-)
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 62475fc..00d36dd 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -58,6 +58,7 @@ config MIPS
select HAVE_DEBUG_STACKOVERFLOW
select HAVE_DMA_CONTIGUOUS
select HAVE_DYNAMIC_FTRACE
+ select HAVE_DYNAMIC_FTRACE_WITH_REGS
select HAVE_EBPF_JIT if 64BIT && !CPU_MICROMIPS && TARGET_ISA_REV >= 2
select HAVE_EXIT_THREAD
select HAVE_FAST_GUP
diff --git a/arch/mips/include/asm/ftrace.h b/arch/mips/include/asm/ftrace.h
index 636c640..8afd1bc 100644
--- a/arch/mips/include/asm/ftrace.h
+++ b/arch/mips/include/asm/ftrace.h
@@ -76,6 +76,11 @@ do { \
#ifdef CONFIG_DYNAMIC_FTRACE
+
+#ifdef CONFIG_DYNAMIC_FTRACE_WITH_REGS
+#define ARCH_SUPPORTS_FTRACE_OPS 1
+#endif
+
static inline unsigned long ftrace_call_adjust(unsigned long addr)
{
return addr;
diff --git a/arch/mips/kernel/ftrace.c b/arch/mips/kernel/ftrace.c
index fd6d1da..890429a 100644
--- a/arch/mips/kernel/ftrace.c
+++ b/arch/mips/kernel/ftrace.c
@@ -49,40 +49,89 @@ void arch_ftrace_update_code(int command)
#define DONT_SET 0x
static struct ftrace_insn jal_ftrace_caller __read_mostly;
-static struct ftrace_insn la_mcount __read_mostly;
+static struct ftrace_insn la_ftrace_caller __read_mostly;
static struct ftrace_insn nop_kernel __read_mostly;
static struct ftrace_insn nop_module __read_mostly;
+#ifdef CONFIG_DYNAMIC_FTRACE_WITH_REGS
+static struct ftrace_insn jal_ftrace_regs_caller __read_mostly;
+static struct ftrace_insn la_ftrace_regs_caller __read_mostly;
+#endif
+
#ifdef CONFIG_FUNCTION_GRAPH_TRACER
static struct ftrace_insn j_ftrace_graph_caller __read_mostly;
#endif
+/*
+ * The details about the calling site of mcount on MIPS
+ *
+ * 1. For kernel:
+ *
+ * move at, ra
+ * jal _mcount --> nop
+ * sub sp, sp, 8 --> nop (CONFIG_32BIT)
+ *
+ * 2. For modules:
+ *
+ * 2.1 For KBUILD_MCOUNT_RA_ADDRESS and CONFIG_32BIT
+ *
+ * lui v1, hi_16bit_of_mcount --> b 1f (0x1005)
+ * addiu v1, v1, low_16bit_of_mcount --> nop (CONFIG_32BIT)
+ * move at, ra
+ * move $12, ra_address
+ * jalr v1
+ * sub sp, sp, 8
+ * 1: offset = 5 instructions
+ * 2.2 For the Other situations
+ *
+ * lui v1, hi_16bit_of_mcount --> b 1f (0x1004)
+ * addiu v1, v1, low_16bit_of_mcount --> nop (CONFIG_32BIT)
+ * move at, ra
+ * jalr v1
+ * nop | move $12, ra_address | sub sp, sp, 8
+ * 1: offset = 4 instructions
+ */
+
static inline void ftrace_dyn_arch_init_insns(void)
{
u32 *buf;
unsigned int v1 = 3;
- /* la v1, _mcount */
- buf = (u32 *)&la_mcount;
- UASM_i_LA(&buf, v1, MCOUNT_ADDR);
-#ifdef CONFIG_64BIT
- la_mcount.code[1] = DONT_SET;
-#endif
+ /* la v1, ftrace_caller */
+ buf = (u32 *)&la_ftrace_caller;
+ UASM_i_LA(&buf, v1, FTRACE_ADDR);
- /* jal (ftrace_caller + 8), jump over the first two instruction */
buf = (u32 *)&jal_ftrace_caller;
- uasm_i_jal(&buf, (FTRACE_ADDR + 8) & JUMP_RANGE_MASK);
+#ifdef CONFIG_32BIT
+ /* jal (ftrace_caller + 4), jump over the sp restore instruction */
+ uasm_i_jal(&buf, (FTRACE_ADDR + 4) & JUMP_RANGE_MASK);
+#else
+ uasm_i_jal(&buf, FTRACE_ADDR & JUMP_RANGE_MASK);
+#endif
jal_ftrace_caller.code[1] = DONT_SET;
nop_kernel.code[0] = INSN_NOP;
- nop_module.code[0] = INSN_B_1F;
-
#ifdef CONFIG_64BIT
nop_kernel.code[1] = DONT_SET;
- nop_module.code[1] = DONT_SET;
#else
nop_kernel.code[1] = INSN_NOP;
+#endif
+ nop_module.code[0] = INSN_B_1F;
nop_module.code[1] = INSN_NOP;
+
+#ifdef CONFIG_DYNAMIC_FTRACE_WITH_REGS
+ /* la v1, ftrace_regs_caller */
+ buf = (u32 *)&la_ftrace_regs_caller;
+ UASM_i_LA(&buf, v1, FTRACE_REGS_ADDR);
+
+ /* jal ftrace_regs_caller */
+ buf = (u32 *)&jal_ftrace_regs_caller;
+#ifdef CONFIG_32BIT
+ uasm_i_jal(&buf, (FTRACE_REGS_ADDR + 4)
[PATCH 1/3] MIPS: ftrace: Fix N32 save registers
CONFIG_64BIT is confusing. N32 also pass parameters by a0~a7. Signed-off-by: Jinyang He --- arch/mips/kernel/mcount.S | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/mips/kernel/mcount.S b/arch/mips/kernel/mcount.S index cff52b2..808257a 100644 --- a/arch/mips/kernel/mcount.S +++ b/arch/mips/kernel/mcount.S @@ -27,7 +27,7 @@ PTR_S a1, PT_R5(sp) PTR_S a2, PT_R6(sp) PTR_S a3, PT_R7(sp) -#ifdef CONFIG_64BIT +#if _MIPS_SIM == _MIPS_SIM_ABI64 || _MIPS_SIM == _MIPS_SIM_NABI32 PTR_S a4, PT_R8(sp) PTR_S a5, PT_R9(sp) PTR_S a6, PT_R10(sp) @@ -42,7 +42,7 @@ PTR_L a1, PT_R5(sp) PTR_L a2, PT_R6(sp) PTR_L a3, PT_R7(sp) -#ifdef CONFIG_64BIT +#if _MIPS_SIM == _MIPS_SIM_ABI64 || _MIPS_SIM == _MIPS_SIM_NABI32 PTR_L a4, PT_R8(sp) PTR_L a5, PT_R9(sp) PTR_L a6, PT_R10(sp) -- 2.1.0
Re: [RFC 00/20] TLB batching consolidation and enhancements
> On Jan 30, 2021, at 11:57 PM, Nadav Amit wrote:
>
>> On Jan 30, 2021, at 7:30 PM, Nicholas Piggin wrote:
>>
>> Excerpts from Nadav Amit's message of January 31, 2021 10:11 am:
>>> From: Nadav Amit
>>>
>>> There are currently (at least?) 5 different TLB batching schemes in the
>>> kernel:
>>>
>>> 1. Using mmu_gather (e.g., zap_page_range()).
>>>
>>> 2. Using {inc|dec}_tlb_flush_pending() to inform other threads on the
>>> ongoing deferred TLB flush and flushing the entire range eventually
>>> (e.g., change_protection_range()).
>>>
>>> 3. arch_{enter|leave}_lazy_mmu_mode() for sparc and powerpc (and Xen?).
>>>
>>> 4. Batching per-table flushes (move_ptes()).
>>>
>>> 5. By setting a flag on that a deferred TLB flush operation takes place,
>>> flushing when (try_to_unmap_one() on x86).
>>>
>>> It seems that (1)-(4) can be consolidated. In addition, it seems that
>>> (5) is racy. It also seems there can be many redundant TLB flushes, and
>>> potentially TLB-shootdown storms, for instance during batched
>>> reclamation (using try_to_unmap_one()) if at the same time mmu_gather
>>> defers TLB flushes.
>>>
>>> More aggressive TLB batching may be possible, but this patch-set does
>>> not add such batching. The proposed changes would enable such batching
>>> in a later time.
>>>
>>> Admittedly, I do not understand how things are not broken today, which
>>> frightens me to make further batching before getting things in order.
>>> For instance, why is ok for zap_pte_range() to batch dirty-PTE flushes
>>> for each page-table (but not in greater granularity). Can't
>>> ClearPageDirty() be called before the flush, causing writes after
>>> ClearPageDirty() and before the flush to be lost?
>>
>> Because it's holding the page table lock which stops page_mkclean from
>> cleaning the page. Or am I misunderstanding the question?
>
> Thanks. I understood this part. Looking again at the code, I now understand
> my confusion: I forgot that the reverse mapping is removed after the PTE is
> zapped.
>
> Makes me wonder whether it is ok to defer the TLB flush to tlb_finish_mmu(),
> by performing set_page_dirty() for the batched pages when needed in
> tlb_finish_mmu() [ i.e., by marking for each batched page whether
> set_page_dirty() should be issued for that page while collecting them ].
Correcting myself (I hope): no we cannot do so, since the buffers might be
remove from the page at that point.
[PATCH 2/3] MIPS: ftrace: Combine ftrace_modify_code* into one function
Behavior of ftrace_modify_code_2r() is similar to ftrace_modify_code_2(),
just the order of modification changed. Add a new struct ftrace_insn
to combine ftrace_modify_code with above two functions. The function is
same with the original ftrace_modify_code when ftrace_insn.code[1]
is DONT_SET.
Signed-off-by: Jinyang He
---
arch/mips/include/asm/ftrace.h | 3 +
arch/mips/kernel/ftrace.c | 157 +
2 files changed, 68 insertions(+), 92 deletions(-)
diff --git a/arch/mips/include/asm/ftrace.h b/arch/mips/include/asm/ftrace.h
index b463f2a..636c640 100644
--- a/arch/mips/include/asm/ftrace.h
+++ b/arch/mips/include/asm/ftrace.h
@@ -84,6 +84,9 @@ static inline unsigned long ftrace_call_adjust(unsigned long
addr)
struct dyn_arch_ftrace {
};
+struct ftrace_insn {
+ unsigned int code[2];
+};
#endif /* CONFIG_DYNAMIC_FTRACE */
#endif /* __ASSEMBLY__ */
#endif /* CONFIG_FUNCTION_TRACER */
diff --git a/arch/mips/kernel/ftrace.c b/arch/mips/kernel/ftrace.c
index f57e68f..fd6d1da 100644
--- a/arch/mips/kernel/ftrace.c
+++ b/arch/mips/kernel/ftrace.c
@@ -44,89 +44,70 @@ void arch_ftrace_update_code(int command)
#define INSN_NOP 0x/* nop */
#define INSN_JAL(addr) \
((unsigned int)(JAL | (((addr) >> 2) & ADDR_MASK)))
+#define INSN_B_1F (0x1000 | MCOUNT_OFFSET_INSNS)
+
+#define DONT_SET 0x
+
+static struct ftrace_insn jal_ftrace_caller __read_mostly;
+static struct ftrace_insn la_mcount __read_mostly;
+static struct ftrace_insn nop_kernel __read_mostly;
+static struct ftrace_insn nop_module __read_mostly;
-static unsigned int insn_jal_ftrace_caller __read_mostly;
-static unsigned int insn_la_mcount[2] __read_mostly;
-static unsigned int insn_j_ftrace_graph_caller __maybe_unused __read_mostly;
+#ifdef CONFIG_FUNCTION_GRAPH_TRACER
+static struct ftrace_insn j_ftrace_graph_caller __read_mostly;
+#endif
static inline void ftrace_dyn_arch_init_insns(void)
{
u32 *buf;
- unsigned int v1;
+ unsigned int v1 = 3;
/* la v1, _mcount */
- v1 = 3;
- buf = (u32 *)&insn_la_mcount[0];
+ buf = (u32 *)&la_mcount;
UASM_i_LA(&buf, v1, MCOUNT_ADDR);
+#ifdef CONFIG_64BIT
+ la_mcount.code[1] = DONT_SET;
+#endif
/* jal (ftrace_caller + 8), jump over the first two instruction */
- buf = (u32 *)&insn_jal_ftrace_caller;
+ buf = (u32 *)&jal_ftrace_caller;
uasm_i_jal(&buf, (FTRACE_ADDR + 8) & JUMP_RANGE_MASK);
+ jal_ftrace_caller.code[1] = DONT_SET;
+
+ nop_kernel.code[0] = INSN_NOP;
+ nop_module.code[0] = INSN_B_1F;
+
+#ifdef CONFIG_64BIT
+ nop_kernel.code[1] = DONT_SET;
+ nop_module.code[1] = DONT_SET;
+#else
+ nop_kernel.code[1] = INSN_NOP;
+ nop_module.code[1] = INSN_NOP;
+#endif
#ifdef CONFIG_FUNCTION_GRAPH_TRACER
/* j ftrace_graph_caller */
- buf = (u32 *)&insn_j_ftrace_graph_caller;
+ buf = (u32 *)&j_ftrace_graph_caller;
uasm_i_j(&buf, (unsigned long)ftrace_graph_caller & JUMP_RANGE_MASK);
+ j_ftrace_graph_caller.code[1] = DONT_SET;
#endif
}
-static int ftrace_modify_code(unsigned long ip, unsigned int new_code)
-{
- int faulted;
- mm_segment_t old_fs;
-
- /* *(unsigned int *)ip = new_code; */
- safe_store_code(new_code, ip, faulted);
-
- if (unlikely(faulted))
- return -EFAULT;
-
- old_fs = get_fs();
- set_fs(KERNEL_DS);
- flush_icache_range(ip, ip + 8);
- set_fs(old_fs);
-
- return 0;
-}
-
-#ifndef CONFIG_64BIT
-static int ftrace_modify_code_2(unsigned long ip, unsigned int new_code1,
- unsigned int new_code2)
-{
- int faulted;
- mm_segment_t old_fs;
-
- safe_store_code(new_code1, ip, faulted);
- if (unlikely(faulted))
- return -EFAULT;
-
- ip += 4;
- safe_store_code(new_code2, ip, faulted);
- if (unlikely(faulted))
- return -EFAULT;
-
- ip -= 4;
- old_fs = get_fs();
- set_fs(KERNEL_DS);
- flush_icache_range(ip, ip + 8);
- set_fs(old_fs);
-
- return 0;
-}
-
-static int ftrace_modify_code_2r(unsigned long ip, unsigned int new_code1,
-unsigned int new_code2)
+static int ftrace_modify_code(unsigned long ip, struct ftrace_insn insns)
{
int faulted;
mm_segment_t old_fs;
- ip += 4;
- safe_store_code(new_code2, ip, faulted);
- if (unlikely(faulted))
- return -EFAULT;
+ if (insns.code[1] != DONT_SET) {
+ ip += 4;
+ safe_store_code(insns.code[1], ip, faulted);
+ if (unlikely(faulted))
+ return -EFAULT;
+ ip -= 4;
+ }
- ip -= 4;
- safe_store_code(new_code1, ip, faulted);
+ /* *(unsigned int *)ip = insns.code[0]; */
+ safe_store_code(insns.code[0], ip, faulted);
if (unlik
Re: [PATCH] tee: optee: remove need_resched() before cond_resched()
Hi Jens,
On 29.01.21 14:29, Jens Wiklander wrote:
Hi Rouven and Sumit,
On Mon, Jan 25, 2021 at 10:58 AM Jens Wiklander via OP-TEE
wrote:
Hi Rouven and Sumit,
On Mon, Jan 25, 2021 at 10:55 AM Jens Wiklander
wrote:
Testing need_resched() before cond_resched() is not needed as an
equivalent test is done internally in cond_resched(). So drop the
need_resched() test.
Fixes: dcb3b06d9c34 ("tee: optee: replace might_sleep with cond_resched")
Signed-off-by: Jens Wiklander
---
drivers/tee/optee/call.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
Can you please test to see that this works in your setups too?
Does this work for you? I'd like to get this patch ready for v5.12.
Yes it does. I also looked at it right after Arnds mail, so for future
reference:
cond_resched()
_cond_resched() (ifndef CONFIG_PREEMPTION)
should_resched(0)
tif_need_resched() (+ preempt_count == 0 for current thread)
while:
need_resched()
tif_need_resched()
You can add my
Reviewed-by: Rouven Czerwinski
I also retested on the STM32-DK2 and the problem remains fixed:
Tested-by: Rouven Czerwinski
Regrads and thanks for the patch,
Rouven
Re: [PATCH] openrisc: use device tree to determine present cpus
On 31/01/2021 00:03, Stafford Horne wrote: This looks good, one small comment below. Can you send the next patch as a v2? Using 'git format-patch -v2 ...' Sorry, was not aware of that, will do better next time! Should we warn on the else case? I think it is fine for the kernel to have room for more CPUs than are actually present (i.e. NR_CPUs > present_cpus is OK). Other Archs do not show a warning in this case either, therefore I also omitted it. Gruss Jan smime.p7s Description: S/MIME Cryptographic Signature
corrupted pvqspinlock in htab_map_update_elem
Hi, I am testing the following the program: https://gist.github.com/dvyukov/e5c0a8ef220ef856363c1080b0936a9e on the latest upstream 6642d600b541b81931fb1ab0c041b0d68f77be7e and getting the following crash. Config is: https://gist.github.com/dvyukov/16d9905e5ef35e44285451f1d330ddbc The program updates a bpf map from a program called on hw breakpoint hit. Not sure if it's a bpf issue or a perf issue. This time it is not a fuzzer workload, I am trying to do something useful :) [ cut here ] pvqspinlock: lock 0x8f371d80 has corrupted value 0x0! WARNING: CPU: 3 PID: 8771 at kernel/locking/qspinlock_paravirt.h:498 __pv_queued_spin_unlock_slowpath+0x22e/0x2b0 kernel/locking/qspinlock_paravirt.h:498 Modules linked in: CPU: 3 PID: 8771 Comm: a.out Not tainted 5.11.0-rc5+ #71 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-44-g88ab0c15525c-prebuilt.qemu.org 04/01/2014 RIP: 0010:__pv_queued_spin_unlock_slowpath+0x22e/0x2b0 kernel/locking/qspinlock_paravirt.h:498 Code: ea 03 0f b6 14 02 4c 89 e8 83 e0 07 83 c0 03 38 d0 7c 04 84 d2 75 62 41 8b 55 00 4c 89 ee 48 c7 c7 20 6b 4c 89 e8 72 d3 5f 07 <0f> 0b e9 6cc RSP: 0018:fe0c17b0 EFLAGS: 00010086 RAX: RBX: 8f3b5660 RCX: RDX: 8880150222c0 RSI: 815b624d RDI: fbc182e8 RBP: 0001 R08: 0001 R09: R10: 817de94f R11: R12: 8880150222c0 R13: 8f371d80 R14: 8880181fead8 R15: FS: 7fa5b51f0700() GS:88802cf8() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 02286908 CR3: 15b24000 CR4: 00750ee0 DR0: 004cb3d4 DR1: DR2: DR3: DR6: 0ff0 DR7: 0400 PKRU: 5554 Call Trace: <#DB> __raw_callee_save___pv_queued_spin_unlock_slowpath+0x11/0x20 .slowpath+0x9/0xe pv_queued_spin_unlock arch/x86/include/asm/paravirt.h:559 [inline] queued_spin_unlock arch/x86/include/asm/qspinlock.h:56 [inline] lockdep_unlock+0x10e/0x290 kernel/locking/lockdep.c:124 debug_locks_off_graph_unlock kernel/locking/lockdep.c:165 [inline] print_usage_bug kernel/locking/lockdep.c:3710 [inline] verify_lock_unused kernel/locking/lockdep.c:5374 [inline] lock_acquire kernel/locking/lockdep.c:5433 [inline] lock_acquire+0x471/0x720 kernel/locking/lockdep.c:5407 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0x39/0x50 kernel/locking/spinlock.c:159 htab_lock_bucket kernel/bpf/hashtab.c:175 [inline] htab_map_update_elem+0x1f0/0x790 kernel/bpf/hashtab.c:1023 bpf_prog_60236c52b8017ad1+0x8e/0xab4 bpf_dispatcher_nop_func include/linux/bpf.h:651 [inline] bpf_overflow_handler+0x192/0x5b0 kernel/events/core.c:9755 __perf_event_overflow+0x13c/0x370 kernel/events/core.c:8979 perf_swevent_overflow kernel/events/core.c:9055 [inline] perf_swevent_event+0x347/0x550 kernel/events/core.c:9083 perf_bp_event+0x1a2/0x1c0 kernel/events/core.c:9932 hw_breakpoint_handler arch/x86/kernel/hw_breakpoint.c:535 [inline] hw_breakpoint_exceptions_notify+0x18a/0x3b0 arch/x86/kernel/hw_breakpoint.c:567 notifier_call_chain+0xb5/0x200 kernel/notifier.c:83 atomic_notifier_call_chain+0x8d/0x170 kernel/notifier.c:217 notify_die+0xda/0x170 kernel/notifier.c:548 notify_debug+0x20/0x30 arch/x86/kernel/traps.c:842 exc_debug_kernel arch/x86/kernel/traps.c:902 [inline] exc_debug+0x103/0x140 arch/x86/kernel/traps.c:998 asm_exc_debug+0x19/0x30 arch/x86/include/asm/idtentry.h:598 RIP: 0010:copy_user_generic_unrolled+0xa2/0xc0 arch/x86/lib/copy_user_64.S:102 Code: ff c9 75 b6 89 d1 83 e2 07 c1 e9 03 74 12 4c 8b 06 4c 89 07 48 8d 76 08 48 8d 7f 08 ff c9 75 ee 21 d2 74 10 89 d1 8a 06 88 07 <48> ff c6 484 RSP: 0018:c9d67af0 EFLAGS: 00040202 RAX: 0001 RBX: 0001 RCX: 0001 RDX: 0001 RSI: 88801341d001 RDI: 004cb3d4 RBP: 004cb3d4 R08: R09: 88801341d001 R10: ed1002683a00 R11: R12: 88801341d001 R13: 004cb3d5 R14: R15: 0001 copy_user_generic arch/x86/include/asm/uaccess_64.h:37 [inline] raw_copy_to_user arch/x86/include/asm/uaccess_64.h:58 [inline] copyout.part.0+0xe4/0x110 lib/iov_iter.c:148 copyout lib/iov_iter.c:182 [inline] copy_page_to_iter_iovec lib/iov_iter.c:219 [inline] copy_page_to_iter+0x416/0xed0 lib/iov_iter.c:926 pipe_read+0x4a4/0x13a0 fs/pipe.c:290 call_read_iter include/linux/fs.h:1895 [inline] new_sync_read+0x5b7/0x6e0 fs/read_write.c:415 vfs_read+0x35c/0x570 fs/read_write.c:496 ksys_read+0x1ee/0x250 fs/read_write.c:634 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x406c1c Code: ec 28 48 89 54 24 18 48 89 74 24 10 89 7c 24 08 e8 f9 fc ff ff 48 8b 54 24 18 48 8b 74 24 10 41 89 c0 8b 7c 24 08 31 c0 0
Re: [PATCH 1/2] ALSA: ac97: Constify static struct attribute_group
On Sun, 31 Jan 2021 01:12:40 +0100, Rikard Falkeborn wrote: > > The only usage of ac97_adapter_attr_group is to put its address in an > array of pointers to const attribute_group structs. Make it const to > allow the compiler to put it in read-only memory. > > Signed-off-by: Rikard Falkeborn Thanks, applied. Takashi
Re: [PATCH 2/2] ALSA: hda: Constify static attribute_group
On Sun, 31 Jan 2021 01:12:41 +0100, Rikard Falkeborn wrote: > > The only usage of hdac_dev_attr_group is to put its address in an array > of pointers to const attribute_group structs. Make it const to allow the > compiler to put it in read-only memory. > > Signed-off-by: Rikard Falkeborn Thanks, applied. Takashi
Re: [RFC PATCH v2] taskstats: add /proc/taskstats to fetch pid/tgid status
On Wed, Jan 27, 2021 at 7:13 PM Balbir Singh wrote: > > On Fri, Jan 22, 2021 at 10:07:50PM +0800, Weiping Zhang wrote: > > Hello Balbir Singh, > > > > Could you help review this patch, thanks > > > > On Mon, Dec 28, 2020 at 10:10 PM Weiping Zhang wrote: > > > > > > Hi David, > > > > > > Could you help review this patch ? > > > > > > thanks > > > > > > On Fri, Dec 18, 2020 at 1:24 AM Weiping Zhang > > > wrote: > > > > > > > > If a program needs monitor lots of process's status, it needs two > > > > syscalls for every process. The first one is telling kernel which > > > > pid/tgid should be monitored by send a command(write socket) to kernel. > > > > The second one is read the statistics by read socket. This patch add > > > > a new interface /proc/taskstats to reduce two syscalls to one ioctl. > > > > The user just set the target pid/tgid to the struct taskstats.ac_pid, > > > > then kernel will collect statistics for that pid/tgid. > > > > > > > > Signed-off-by: Weiping Zhang > > Could you elaborate on the overhead your seeing for the syscalls? I am not > in favour of adding new IOCTL's. > > Balbir Singh. Hello Balbir Singh, Sorry for late reply, I do a performance test between netlink mode and ioctl mode, monitor 1000 and 1 sleep processes, the netlink mode cost more time than ioctl mode, that is to say ioctl mode can save some cpu resource and has a quickly reponse especially when monitor lot of process. proccess-countnetlink ioctl - 1000 0.004446851 0.001553733 1 0.047024986 0.023290664 you can get the test demo code from the following link https://github.com/dublio/tools/tree/master/c/taskstat Thanks Weiping
INFO: task can't die in iget5_locked
Hello, syzbot found the following issue on: HEAD commit:b01f250d Add linux-next specific files for 20210129 git tree: linux-next console output: https://syzkaller.appspot.com/x/log.txt?x=1340da08d0 kernel config: https://syzkaller.appspot.com/x/.config?x=725bc96dc234fda7 dashboard link: https://syzkaller.appspot.com/bug?extid=1732f7c4545ff63c9119 compiler: gcc (GCC) 10.1.0-syz 20200507 Unfortunately, I don't have any reproducer for this issue yet. IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+1732f7c4545ff63c9...@syzkaller.appspotmail.com INFO: task syz-executor.4:15223 can't die for more than 143 seconds. task:syz-executor.4 state:R running task stack:25736 pid:15223 ppid: 8430 flags:0x4006 Call Trace: context_switch kernel/sched/core.c:4326 [inline] __schedule+0x90c/0x21a0 kernel/sched/core.c:5077 preempt_schedule_common+0x45/0xc0 kernel/sched/core.c:5237 preempt_schedule_thunk+0x16/0x18 arch/x86/entry/thunk_64.S:35 __raw_spin_unlock include/linux/spinlock_api_smp.h:152 [inline] _raw_spin_unlock+0x36/0x40 kernel/locking/spinlock.c:183 spin_unlock include/linux/spinlock.h:394 [inline] ilookup5_nowait fs/inode.c:1336 [inline] ilookup5 fs/inode.c:1364 [inline] iget5_locked+0xcc/0x2d0 fs/inode.c:1145 fuse_iget+0x271/0x610 fs/fuse/inode.c:342 fuse_lookup_name+0x447/0x630 fs/fuse/dir.c:439 fuse_lookup.part.0+0xdf/0x390 fs/fuse/dir.c:469 fuse_lookup+0x70/0x90 fs/fuse/dir.c:465 __lookup_slow+0x24c/0x480 fs/namei.c:1625 lookup_slow fs/namei.c:1642 [inline] walk_component+0x418/0x6a0 fs/namei.c:1939 lookup_last fs/namei.c:2396 [inline] path_lookupat+0x1ba/0x830 fs/namei.c:2420 filename_lookup+0x19f/0x560 fs/namei.c:2453 unix_find_other+0xd1/0x720 net/unix/af_unix.c:935 unix_dgram_sendmsg+0xc73/0x1a80 net/unix/af_unix.c:1696 sock_sendmsg_nosec net/socket.c:654 [inline] sock_sendmsg+0xcf/0x120 net/socket.c:674 sys_sendmsg+0x331/0x810 net/socket.c:2350 ___sys_sendmsg+0xf3/0x170 net/socket.c:2404 __sys_sendmmsg+0x195/0x470 net/socket.c:2494 __do_sys_sendmmsg net/socket.c:2523 [inline] __se_sys_sendmmsg net/socket.c:2520 [inline] __x64_sys_sendmmsg+0x99/0x100 net/socket.c:2520 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x45e219 RSP: 002b:7f20a7119c68 EFLAGS: 0246 ORIG_RAX: 0133 RAX: ffda RBX: 0004 RCX: 0045e219 RDX: 0002 RSI: 20008600 RDI: 0006 RBP: 0119bfc8 R08: R09: R10: R11: 0246 R12: 0119bf8c R13: 7ffcb7b513ef R14: 7f20a711a9c0 R15: 0119bf8c INFO: task syz-executor.4:15230 can't die for more than 144 seconds. task:syz-executor.4 state:D stack:27056 pid:15230 ppid: 8430 flags:0x0004 Call Trace: context_switch kernel/sched/core.c:4326 [inline] __schedule+0x90c/0x21a0 kernel/sched/core.c:5077 schedule+0xcf/0x270 kernel/sched/core.c:5156 rwsem_down_write_slowpath+0x7e5/0x1200 kernel/locking/rwsem.c:1106 __down_write_common kernel/locking/rwsem.c:1261 [inline] __down_write_common kernel/locking/rwsem.c:1258 [inline] __down_write kernel/locking/rwsem.c:1270 [inline] down_write+0x132/0x150 kernel/locking/rwsem.c:1407 inode_lock include/linux/fs.h:775 [inline] lock_mount+0x8a/0x2e0 fs/namespace.c:2216 do_new_mount_fc fs/namespace.c:2846 [inline] do_new_mount fs/namespace.c:2905 [inline] path_mount+0x14d6/0x1f90 fs/namespace.c:3233 do_mount fs/namespace.c:3246 [inline] __do_sys_mount fs/namespace.c:3454 [inline] __se_sys_mount fs/namespace.c:3431 [inline] __x64_sys_mount+0x27f/0x300 fs/namespace.c:3431 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x45e219 RSP: 002b:7f20a70f8c68 EFLAGS: 0246 ORIG_RAX: 00a5 RAX: ffda RBX: 0005 RCX: 0045e219 RDX: 20002100 RSI: 200020c0 RDI: RBP: 0119c078 R08: 20002140 R09: R10: R11: 0246 R12: 0119c034 R13: 7ffcb7b513ef R14: 7f20a70f99c0 R15: 0119c034 INFO: task syz-executor.4:15230 blocked for more than 144 seconds. Not tainted 5.11.0-rc5-next-20210129-syzkaller #0 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:syz-executor.4 state:D stack:27056 pid:15230 ppid: 8430 flags:0x0004 Call Trace: context_switch kernel/sched/core.c:4326 [inline] __schedule+0x90c/0x21a0 kernel/sched/core.c:5077 schedule+0xcf/0x270 kernel/sched/core.c:5156 rwsem_down_write_slowpath+0x7e5/0x1200 kernel/locking/rwsem.c:1106 __down_write_common kernel/locking/rwsem.c:1261 [inline] __down_write_common kernel/locking/rwsem.c:1258 [inline] __down_write kernel/locking/rwsem.c:1270 [inline] down_write+0x132/0x150 kernel/locking/rwsem.c:1407 inode_lock include/linux/fs.h:
[GIT PULL] LEDs chagnes for v5.11-rc
This pull is due to "leds: trigger: fix potential deadlock with libata" -- people find the warn annoying. It also contains new driver (still should be okay late in -rcs, right?) and two trivial fixes. Best regards, Pavel The following changes since commit 5c8fe583cce542aa0b84adc939ce85293de36e5e: Linux 5.11-rc1 (2020-12-27 15:30:22 -0800) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/pavel/linux-leds.git/ for-rc-5.11 for you to fetch changes up to e1c6edcbea13de025c3406645b4cce4ac3baf973: leds: rt8515: Add Richtek RT8515 LED driver (2021-01-31 10:38:03 +0100) Andrea Righi (1): leds: trigger: fix potential deadlock with libata Linus Walleij (2): dt-bindings: leds: Add DT binding for Richtek RT8515 leds: rt8515: Add Richtek RT8515 LED driver Zheng Yongjun (2): leds: leds-lm3533: convert comma to semicolon leds: leds-ariel: convert comma to semicolon .../devicetree/bindings/leds/richtek,rt8515.yaml | 111 ++ drivers/leds/Kconfig | 3 + drivers/leds/Makefile | 3 + drivers/leds/flash/Kconfig | 15 + drivers/leds/flash/Makefile| 3 + drivers/leds/flash/leds-rt8515.c | 397 + drivers/leds/led-triggers.c| 10 +- drivers/leds/leds-ariel.c | 6 +- drivers/leds/leds-lm3533.c | 2 +- 9 files changed, 542 insertions(+), 8 deletions(-) create mode 100644 Documentation/devicetree/bindings/leds/richtek,rt8515.yaml create mode 100644 drivers/leds/flash/Kconfig create mode 100644 drivers/leds/flash/Makefile create mode 100644 drivers/leds/flash/leds-rt8515.c -- http://www.livejournal.com/~pavelmachek signature.asc Description: PGP signature
[PATCH v6 net-next 01/18] doc: marvell: add cm3-mem device tree bindings description
From: Stefan Chulski Signed-off-by: Stefan Chulski --- Documentation/devicetree/bindings/net/marvell-pp2.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/net/marvell-pp2.txt b/Documentation/devicetree/bindings/net/marvell-pp2.txt index b783976..f9f8cc6 100644 --- a/Documentation/devicetree/bindings/net/marvell-pp2.txt +++ b/Documentation/devicetree/bindings/net/marvell-pp2.txt @@ -37,6 +37,7 @@ Required properties (port): GOP (Group Of Ports) point of view. This ID is used to index the per-port registers in the second register area. - phy-mode: See ethernet.txt file in the same directory +- cm3-mem: phandle to CM3 SRAM definitions Optional properties (port): -- 1.9.1
[PATCH v6 net-next 04/18] doc: marvell: add PPv2.3 description to marvell-pp2.txt
From: Stefan Chulski Signed-off-by: Stefan Chulski --- Documentation/devicetree/bindings/net/marvell-pp2.txt | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/net/marvell-pp2.txt b/Documentation/devicetree/bindings/net/marvell-pp2.txt index f9f8cc6..df80cff 100644 --- a/Documentation/devicetree/bindings/net/marvell-pp2.txt +++ b/Documentation/devicetree/bindings/net/marvell-pp2.txt @@ -1,5 +1,6 @@ * Marvell Armada 375 Ethernet Controller (PPv2.1) Marvell Armada 7K/8K Ethernet Controller (PPv2.2) + Marvell CN913X Ethernet Controller (PPv2.3) Required properties: @@ -12,7 +13,7 @@ Required properties: - common controller registers - LMS registers - one register area per Ethernet port - For "marvell,armada-7k-pp2", must contain the following register + For "marvell,armada-7k-pp2" used by 7K/8K and CN913X, must contain the following register sets: - packet processor registers - networking interfaces registers -- 1.9.1
[PATCH v6 net-next 03/18] net: mvpp2: add CM3 SRAM memory map
From: Stefan Chulski
This patch adds CM3 memory map and CM3 read/write callbacks.
No functionality changes.
Signed-off-by: Stefan Chulski
---
drivers/net/ethernet/marvell/mvpp2/mvpp2.h | 7 +++
drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 63 +++-
2 files changed, 67 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
b/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
index 6bd7e40..aec9179 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
@@ -748,6 +748,9 @@
#define MVPP2_TX_FIFO_THRESHOLD(kb)\
((kb) * 1024 - MVPP2_TX_FIFO_THRESHOLD_MIN)
+/* MSS Flow control */
+#define MSS_SRAM_SIZE 0x800
+
/* RX buffer constants */
#define MVPP2_SKB_SHINFO_SIZE \
SKB_DATA_ALIGN(sizeof(struct skb_shared_info))
@@ -925,6 +928,7 @@ struct mvpp2 {
/* Shared registers' base addresses */
void __iomem *lms_base;
void __iomem *iface_base;
+ void __iomem *cm3_base;
/* On PPv2.2, each "software thread" can access the base
* register through a separate address space, each 64 KB apart
@@ -996,6 +1000,9 @@ struct mvpp2 {
/* page_pool allocator */
struct page_pool *page_pool[MVPP2_PORT_MAX_RXQ];
+
+ /* CM3 SRAM pool */
+ struct gen_pool *sram_pool;
};
struct mvpp2_pcpu_stats {
diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
index a07cf60..307f9fd 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -6846,6 +6847,44 @@ static int mvpp2_init(struct platform_device *pdev,
struct mvpp2 *priv)
return 0;
}
+static int mvpp2_get_sram(struct platform_device *pdev,
+ struct mvpp2 *priv)
+{
+ struct device_node *dn = pdev->dev.of_node;
+ static bool defer_once;
+ struct resource *res;
+
+ if (has_acpi_companion(&pdev->dev)) {
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 2);
+ if (!res) {
+ dev_warn(&pdev->dev, "ACPI is too old, Flow control not
supported\n");
+ return 0;
+ }
+ priv->cm3_base = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(priv->cm3_base))
+ return PTR_ERR(priv->cm3_base);
+ } else {
+ priv->sram_pool = of_gen_pool_get(dn, "cm3-mem", 0);
+ if (!priv->sram_pool) {
+ if (!defer_once) {
+ defer_once = true;
+ /* Try defer once */
+ return -EPROBE_DEFER;
+ }
+ dev_warn(&pdev->dev, "DT is too old, Flow control not
supported\n");
+ return -ENOMEM;
+ }
+ /* cm3_base allocated with offset zero into the SRAM since
mapping size
+* is equal to requested size.
+*/
+ priv->cm3_base = (void __iomem *)gen_pool_alloc(priv->sram_pool,
+ MSS_SRAM_SIZE);
+ if (!priv->cm3_base)
+ return -ENOMEM;
+ }
+ return 0;
+}
+
static int mvpp2_probe(struct platform_device *pdev)
{
const struct acpi_device_id *acpi_id;
@@ -6902,6 +6941,13 @@ static int mvpp2_probe(struct platform_device *pdev)
priv->iface_base = devm_ioremap_resource(&pdev->dev, res);
if (IS_ERR(priv->iface_base))
return PTR_ERR(priv->iface_base);
+
+ /* Map CM3 SRAM */
+ err = mvpp2_get_sram(pdev, priv);
+ if (err == -EPROBE_DEFER)
+ return err;
+ else if (err)
+ dev_warn(&pdev->dev, "Fail to alloc CM3 SRAM\n");
}
if (priv->hw_version == MVPP22 && dev_of_node(&pdev->dev)) {
@@ -6947,11 +6993,13 @@ static int mvpp2_probe(struct platform_device *pdev)
if (dev_of_node(&pdev->dev)) {
priv->pp_clk = devm_clk_get(&pdev->dev, "pp_clk");
- if (IS_ERR(priv->pp_clk))
- return PTR_ERR(priv->pp_clk);
+ if (IS_ERR(priv->pp_clk)) {
+ err = PTR_ERR(priv->pp_clk);
+ goto err_cm3;
+ }
err = clk_prepare_enable(priv->pp_clk);
if (err < 0)
- return err;
+ goto err_cm3;
priv->gop_clk = devm_clk_get(&pdev->dev, "gop_clk");
if (IS_ERR(priv->gop_clk)) {
@@ -7087,6 +7135,11 @@ static int mvpp2_probe(struct platform_device *pdev)
clk_disable_u
[PATCH v6 net-next 08/18] net: mvpp2: increase RXQ size to 1024 descriptors
From: Stefan Chulski RXQ size increased to support Firmware Flow Control. Minimum depletion thresholds to support FC is 1024 buffers. Default set to 1024 descriptors and maximum size to 2048. Signed-off-by: Stefan Chulski --- drivers/net/ethernet/marvell/mvpp2/mvpp2.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2.h b/drivers/net/ethernet/marvell/mvpp2/mvpp2.h index 8dc669d..cac9885 100644 --- a/drivers/net/ethernet/marvell/mvpp2/mvpp2.h +++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2.h @@ -715,8 +715,8 @@ #define MVPP2_PORT_MAX_RXQ 32 /* Max number of Rx descriptors */ -#define MVPP2_MAX_RXD_MAX 1024 -#define MVPP2_MAX_RXD_DFLT 128 +#define MVPP2_MAX_RXD_MAX 2048 +#define MVPP2_MAX_RXD_DFLT 1024 /* Max number of Tx descriptors */ #define MVPP2_MAX_TXD_MAX 2048 -- 1.9.1
[PATCH v6 net-next 09/18] net: mvpp2: add FCA periodic timer configurations
From: Stefan Chulski
Flow Control periodic timer would be used if port in
XOFF to transmit periodic XOFF frames.
Signed-off-by: Stefan Chulski
---
drivers/net/ethernet/marvell/mvpp2/mvpp2.h | 13 +-
drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 45
2 files changed, 57 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
b/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
index cac9885..73f087c 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
@@ -596,6 +596,15 @@
#define MVPP22_MPCS_CLK_RESET_DIV_RATIO(n) ((n) << 4)
#define MVPP22_MPCS_CLK_RESET_DIV_SET BIT(11)
+/* FCA registers. PPv2.2 and PPv2.3 */
+#define MVPP22_FCA_BASE(port) (0x7600 + (port) * 0x1000)
+#define MVPP22_FCA_REG_SIZE16
+#define MVPP22_FCA_REG_MASK0x
+#define MVPP22_FCA_CONTROL_REG 0x0
+#define MVPP22_FCA_ENABLE_PERIODIC BIT(11)
+#define MVPP22_PERIODIC_COUNTER_LSB_REG(0x110)
+#define MVPP22_PERIODIC_COUNTER_MSB_REG(0x114)
+
/* XPCS registers. PPv2.2 and PPv2.3 */
#define MVPP22_XPCS_BASE(port) (0x7400 + (port) * 0x1000)
#define MVPP22_XPCS_CFG0 0x0
@@ -752,7 +761,9 @@
((kb) * 1024 - MVPP2_TX_FIFO_THRESHOLD_MIN)
/* MSS Flow control */
-#define MSS_SRAM_SIZE 0x800
+#define MSS_SRAM_SIZE 0x800
+#define FC_QUANTA 0x
+#define FC_CLK_DIVIDER 100
/* RX buffer constants */
#define MVPP2_SKB_SHINFO_SIZE \
diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
index d80947a..6e59d07 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
@@ -1281,6 +1281,49 @@ static void mvpp22_gop_init_10gkr(struct mvpp2_port
*port)
writel(val, mpcs + MVPP22_MPCS_CLK_RESET);
}
+static void mvpp22_gop_fca_enable_periodic(struct mvpp2_port *port, bool en)
+{
+ struct mvpp2 *priv = port->priv;
+ void __iomem *fca = priv->iface_base + MVPP22_FCA_BASE(port->gop_id);
+ u32 val;
+
+ val = readl(fca + MVPP22_FCA_CONTROL_REG);
+ val &= ~MVPP22_FCA_ENABLE_PERIODIC;
+ if (en)
+ val |= MVPP22_FCA_ENABLE_PERIODIC;
+ writel(val, fca + MVPP22_FCA_CONTROL_REG);
+}
+
+static void mvpp22_gop_fca_set_timer(struct mvpp2_port *port, u32 timer)
+{
+ struct mvpp2 *priv = port->priv;
+ void __iomem *fca = priv->iface_base + MVPP22_FCA_BASE(port->gop_id);
+ u32 lsb, msb;
+
+ lsb = timer & MVPP22_FCA_REG_MASK;
+ msb = timer >> MVPP22_FCA_REG_SIZE;
+
+ writel(lsb, fca + MVPP22_PERIODIC_COUNTER_LSB_REG);
+ writel(msb, fca + MVPP22_PERIODIC_COUNTER_MSB_REG);
+}
+
+/* Set Flow Control timer x100 faster than pause quanta to ensure that link
+ * partner won't send traffic if port is in XOFF mode.
+ */
+static void mvpp22_gop_fca_set_periodic_timer(struct mvpp2_port *port)
+{
+ u32 timer;
+
+ timer = (port->priv->tclk / (USEC_PER_SEC * FC_CLK_DIVIDER))
+ * FC_QUANTA;
+
+ mvpp22_gop_fca_enable_periodic(port, false);
+
+ mvpp22_gop_fca_set_timer(port, timer);
+
+ mvpp22_gop_fca_enable_periodic(port, true);
+}
+
static int mvpp22_gop_init(struct mvpp2_port *port)
{
struct mvpp2 *priv = port->priv;
@@ -1325,6 +1368,8 @@ static int mvpp22_gop_init(struct mvpp2_port *port)
val |= GENCONF_SOFT_RESET1_GOP;
regmap_write(priv->sysctrl_base, GENCONF_SOFT_RESET1, val);
+ mvpp22_gop_fca_set_periodic_timer(port);
+
unsupported_conf:
return 0;
--
1.9.1
[PATCH v6 net-next 16/18] net: mvpp2: set 802.3x GoP Flow Control mode
From: Stefan Chulski
This patch fix GMAC TX flow control autoneg.
Flow control autoneg wrongly were disabled with enabled TX
flow control.
Signed-off-by: Stefan Chulski
---
drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
index afa61cc..7632810 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
@@ -6282,7 +6282,7 @@ static void mvpp2_gmac_config(struct mvpp2_port *port,
unsigned int mode,
old_ctrl4 = ctrl4 = readl(port->base + MVPP22_GMAC_CTRL_4_REG);
ctrl0 &= ~MVPP2_GMAC_PORT_TYPE_MASK;
- ctrl2 &= ~(MVPP2_GMAC_INBAND_AN_MASK | MVPP2_GMAC_PCS_ENABLE_MASK);
+ ctrl2 &= ~(MVPP2_GMAC_INBAND_AN_MASK | MVPP2_GMAC_PCS_ENABLE_MASK |
MVPP2_GMAC_FLOW_CTRL_MASK);
/* Configure port type */
if (phy_interface_mode_is_8023z(state->interface)) {
--
1.9.1
[PATCH v6 net-next 06/18] net: mvpp2: always compare hw-version vs MVPP21
From: Stefan Chulski
Currently we have PP2v1 and PP2v2 hw-versions, with some different
handlers depending upon condition hw_version = MVPP21/MVPP22.
In a future there will be also PP2v3. Let's use now the generic
"if equal/notEqual MVPP21" for all cases instead of "if MVPP22".
This patch does not change any functionality.
It is not intended to introduce PP2v3.
It just modifies MVPP21/MVPP22 check-condition
bringing it to generic and unified form correct for new-code
introducing and PP2v3 net-next generation.
Signed-off-by: Stefan Chulski
---
drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 36 ++--
1 file changed, 18 insertions(+), 18 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
index 11c56d2..d80947a 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
@@ -320,7 +320,7 @@ static int mvpp2_get_nrxqs(struct mvpp2 *priv)
{
unsigned int nrxqs;
- if (priv->hw_version == MVPP22 && queue_mode == MVPP2_QDIST_SINGLE_MODE)
+ if (priv->hw_version != MVPP21 && queue_mode == MVPP2_QDIST_SINGLE_MODE)
return 1;
/* According to the PPv2.2 datasheet and our experiments on
@@ -447,7 +447,7 @@ static void mvpp2_bm_bufs_get_addrs(struct device *dev,
struct mvpp2 *priv,
MVPP2_BM_PHY_ALLOC_REG(bm_pool->id));
*phys_addr = mvpp2_thread_read(priv, thread, MVPP2_BM_VIRT_ALLOC_REG);
- if (priv->hw_version == MVPP22) {
+ if (priv->hw_version != MVPP21) {
u32 val;
u32 dma_addr_highbits, phys_addr_highbits;
@@ -743,7 +743,7 @@ static inline void mvpp2_bm_pool_put(struct mvpp2_port
*port, int pool,
if (test_bit(thread, &port->priv->lock_map))
spin_lock_irqsave(&port->bm_lock[thread], flags);
- if (port->priv->hw_version == MVPP22) {
+ if (port->priv->hw_version != MVPP21) {
u32 val = 0;
if (sizeof(dma_addr_t) == 8)
@@ -1200,7 +1200,7 @@ static bool mvpp2_port_supports_xlg(struct mvpp2_port
*port)
static bool mvpp2_port_supports_rgmii(struct mvpp2_port *port)
{
- return !(port->priv->hw_version == MVPP22 && port->gop_id == 0);
+ return !(port->priv->hw_version != MVPP21 && port->gop_id == 0);
}
/* Port configuration routines */
@@ -1818,7 +1818,7 @@ static void mvpp2_mac_reset_assert(struct mvpp2_port
*port)
MVPP2_GMAC_PORT_RESET_MASK;
writel(val, port->base + MVPP2_GMAC_CTRL_2_REG);
- if (port->priv->hw_version == MVPP22 && port->gop_id == 0) {
+ if (port->priv->hw_version != MVPP21 && port->gop_id == 0) {
val = readl(port->base + MVPP22_XLG_CTRL0_REG) &
~MVPP22_XLG_CTRL0_MAC_RESET_DIS;
writel(val, port->base + MVPP22_XLG_CTRL0_REG);
@@ -1831,7 +1831,7 @@ static void mvpp22_pcs_reset_assert(struct mvpp2_port
*port)
void __iomem *mpcs, *xpcs;
u32 val;
- if (port->priv->hw_version != MVPP22 || port->gop_id != 0)
+ if (port->priv->hw_version == MVPP21 || port->gop_id != 0)
return;
mpcs = priv->iface_base + MVPP22_MPCS_BASE(port->gop_id);
@@ -1852,7 +1852,7 @@ static void mvpp22_pcs_reset_deassert(struct mvpp2_port
*port)
void __iomem *mpcs, *xpcs;
u32 val;
- if (port->priv->hw_version != MVPP22 || port->gop_id != 0)
+ if (port->priv->hw_version == MVPP21 || port->gop_id != 0)
return;
mpcs = priv->iface_base + MVPP22_MPCS_BASE(port->gop_id);
@@ -4189,7 +4189,7 @@ static void mvpp2_start_dev(struct mvpp2_port *port)
/* Enable interrupts on all threads */
mvpp2_interrupts_enable(port);
- if (port->priv->hw_version == MVPP22)
+ if (port->priv->hw_version != MVPP21)
mvpp22_mode_reconfigure(port);
if (port->phylink) {
@@ -4405,7 +4405,7 @@ static int mvpp2_open(struct net_device *dev)
valid = true;
}
- if (priv->hw_version == MVPP22 && port->port_irq) {
+ if (priv->hw_version != MVPP21 && port->port_irq) {
err = request_irq(port->port_irq, mvpp2_port_isr, 0,
dev->name, port);
if (err) {
@@ -6053,7 +6053,7 @@ static int mvpp2__mac_prepare(struct phylink_config
*config, unsigned int mode,
MVPP2_GMAC_PORT_RESET_MASK,
MVPP2_GMAC_PORT_RESET_MASK);
- if (port->priv->hw_version == MVPP22) {
+ if (port->priv->hw_version != MVPP21) {
mvpp22_gop_mask_irq(port);
phy_power_off(port->comphy);
@@ -6107,7 +6107,7 @@ static int mvpp2_mac_finish(struct phylink_config
*config, unsigned int mode,
{
struct mvpp2_port *port = mvpp2_phylink_to_port(config);
-
[PATCH v6 net-next 18/18] net: mvpp2: add TX FC firmware check
From: Stefan Chulski
Patch check that TX FC firmware is running in CM3.
If not, global TX FC would be disabled.
Signed-off-by: Stefan Chulski
---
drivers/net/ethernet/marvell/mvpp2/mvpp2.h | 1 +
drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 42
2 files changed, 36 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
b/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
index 9947385..25013a4 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
@@ -829,6 +829,7 @@
#define MSS_THRESHOLD_STOP 768
#define MSS_THRESHOLD_START1024
+#define MSS_FC_MAX_TIMEOUT 5000
/* RX buffer constants */
#define MVPP2_SKB_SHINFO_SIZE \
diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
index 98849b0..0273134 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
@@ -932,6 +932,34 @@ static void mvpp2_bm_pool_update_fc(struct mvpp2_port
*port,
spin_unlock_irqrestore(&port->priv->mss_spinlock, flags);
}
+static int mvpp2_enable_global_fc(struct mvpp2 *priv)
+{
+ int val, timeout = 0;
+
+ /* Enable global flow control. In this stage global
+* flow control enabled, but still disabled per port.
+*/
+ val = mvpp2_cm3_read(priv, MSS_FC_COM_REG);
+ val |= FLOW_CONTROL_ENABLE_BIT;
+ mvpp2_cm3_write(priv, MSS_FC_COM_REG, val);
+
+ /* Check if Firmware running and disable FC if not*/
+ val |= FLOW_CONTROL_UPDATE_COMMAND_BIT;
+ mvpp2_cm3_write(priv, MSS_FC_COM_REG, val);
+
+ while (timeout < MSS_FC_MAX_TIMEOUT) {
+ val = mvpp2_cm3_read(priv, MSS_FC_COM_REG);
+
+ if (!(val & FLOW_CONTROL_UPDATE_COMMAND_BIT))
+ return 0;
+ usleep_range(10, 20);
+ timeout++;
+ }
+
+ priv->global_tx_fc = false;
+ return -EOPNOTSUPP;
+}
+
/* Release buffer to BM */
static inline void mvpp2_bm_pool_put(struct mvpp2_port *port, int pool,
dma_addr_t buf_dma_addr,
@@ -7281,7 +7309,7 @@ static int mvpp2_probe(struct platform_device *pdev)
struct resource *res;
void __iomem *base;
int i, shared;
- int err, val;
+ int err;
priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
if (!priv)
@@ -7509,13 +7537,13 @@ static int mvpp2_probe(struct platform_device *pdev)
goto err_port_probe;
}
- /* Enable global flow control. In this stage global
-* flow control enabled, but still disabled per port.
-*/
if (priv->global_tx_fc && priv->hw_version != MVPP21) {
- val = mvpp2_cm3_read(priv, MSS_FC_COM_REG);
- val |= FLOW_CONTROL_ENABLE_BIT;
- mvpp2_cm3_write(priv, MSS_FC_COM_REG, val);
+ err = mvpp2_enable_global_fc(priv);
+ if (err) {
+ dev_warn(&pdev->dev, "CM3 firmware not running, version
should be higher than 18.09 ");
+ dev_warn(&pdev->dev, "and chip revision B0\n");
+ dev_warn(&pdev->dev, "Flow control not supported\n");
+ }
}
mvpp2_dbgfs_init(priv, pdev->name);
--
1.9.1
[PATCH v6 net-next 10/18] net: mvpp2: add FCA RXQ non occupied descriptor threshold
From: Stefan Chulski
The firmware needs to monitor the RX Non-occupied descriptor
bits for flow control to move to XOFF mode.
These bits need to be unmasked to be functional, but they will
not raise interrupts as we leave the RX exception summary
bit in MVPP2_ISR_RX_TX_MASK_REG clear.
Signed-off-by: Stefan Chulski
---
drivers/net/ethernet/marvell/mvpp2/mvpp2.h | 3 ++
drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 44
2 files changed, 40 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
b/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
index 73f087c..ca84995 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
@@ -295,6 +295,8 @@
#define MVPP2_PON_CAUSE_TXP_OCCUP_DESC_ALL_MASK0x3fc0
#define MVPP2_PON_CAUSE_MISC_SUM_MASK BIT(31)
#define MVPP2_ISR_MISC_CAUSE_REG 0x55b0
+#define MVPP2_ISR_RX_ERR_CAUSE_REG(port) (0x5520 + 4 * (port))
+#define MVPP2_ISR_RX_ERR_CAUSE_NONOCC_MASK 0x00ff
/* Buffer Manager registers */
#define MVPP2_BM_POOL_BASE_REG(pool) (0x6000 + ((pool) * 4))
@@ -764,6 +766,7 @@
#define MSS_SRAM_SIZE 0x800
#define FC_QUANTA 0x
#define FC_CLK_DIVIDER 100
+#define MSS_THRESHOLD_STOP 768
/* RX buffer constants */
#define MVPP2_SKB_SHINFO_SIZE \
diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
index 6e59d07..19a3f38 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
@@ -1134,14 +1134,19 @@ static inline void mvpp2_qvec_interrupt_disable(struct
mvpp2_queue_vector *qvec)
static void mvpp2_interrupts_mask(void *arg)
{
struct mvpp2_port *port = arg;
+ int cpu = smp_processor_id();
+ u32 thread;
/* If the thread isn't used, don't do anything */
- if (smp_processor_id() > port->priv->nthreads)
+ if (cpu >= port->priv->nthreads)
return;
- mvpp2_thread_write(port->priv,
- mvpp2_cpu_to_thread(port->priv, smp_processor_id()),
+ thread = mvpp2_cpu_to_thread(port->priv, cpu);
+
+ mvpp2_thread_write(port->priv, thread,
MVPP2_ISR_RX_TX_MASK_REG(port->id), 0);
+ mvpp2_thread_write(port->priv, thread,
+ MVPP2_ISR_RX_ERR_CAUSE_REG(port->id), 0);
}
/* Unmask the current thread's Rx/Tx interrupts.
@@ -1151,20 +1156,25 @@ static void mvpp2_interrupts_mask(void *arg)
static void mvpp2_interrupts_unmask(void *arg)
{
struct mvpp2_port *port = arg;
- u32 val;
+ int cpu = smp_processor_id();
+ u32 val, thread;
/* If the thread isn't used, don't do anything */
- if (smp_processor_id() > port->priv->nthreads)
+ if (cpu >= port->priv->nthreads)
return;
+ thread = mvpp2_cpu_to_thread(port->priv, cpu);
+
val = MVPP2_CAUSE_MISC_SUM_MASK |
MVPP2_CAUSE_RXQ_OCCUP_DESC_ALL_MASK(port->priv->hw_version);
if (port->has_tx_irqs)
val |= MVPP2_CAUSE_TXQ_OCCUP_DESC_ALL_MASK;
- mvpp2_thread_write(port->priv,
- mvpp2_cpu_to_thread(port->priv, smp_processor_id()),
+ mvpp2_thread_write(port->priv, thread,
MVPP2_ISR_RX_TX_MASK_REG(port->id), val);
+ mvpp2_thread_write(port->priv, thread,
+ MVPP2_ISR_RX_ERR_CAUSE_REG(port->id),
+ MVPP2_ISR_RX_ERR_CAUSE_NONOCC_MASK);
}
static void
@@ -1189,6 +1199,9 @@ static void mvpp2_interrupts_unmask(void *arg)
mvpp2_thread_write(port->priv, v->sw_thread_id,
MVPP2_ISR_RX_TX_MASK_REG(port->id), val);
+ mvpp2_thread_write(port->priv, v->sw_thread_id,
+ MVPP2_ISR_RX_ERR_CAUSE_REG(port->id),
+ MVPP2_ISR_RX_ERR_CAUSE_NONOCC_MASK);
}
}
@@ -2394,6 +2407,20 @@ static void mvpp2_txp_max_tx_size_set(struct mvpp2_port
*port)
}
}
+/* Set the number of non-occupied descriptors threshold */
+static void mvpp2_set_rxq_free_tresh(struct mvpp2_port *port,
+struct mvpp2_rx_queue *rxq)
+{
+ u32 val;
+
+ mvpp2_write(port->priv, MVPP2_RXQ_NUM_REG, rxq->id);
+
+ val = mvpp2_read(port->priv, MVPP2_RXQ_THRESH_REG);
+ val &= ~MVPP2_RXQ_NON_OCCUPIED_MASK;
+ val |= MSS_THRESHOLD_STOP << MVPP2_RXQ_NON_OCCUPIED_OFFSET;
+ mvpp2_write(port->priv, MVPP2_RXQ_THRESH_REG, val);
+}
+
/* Set the number of packets that will be received before Rx interrupt
* will be generated by HW.
*/
@@ -2649,6 +2676,9 @@ static int mvpp2_rxq_init(struct mvpp2_port *port,
mvpp2_rx_pkts_coal_set(port, rxq);
mvpp2_rx_time_coal_set(port, rxq);
+ /* Se
[PATCH v6 net-next 11/18] net: mvpp2: enable global flow control
From: Stefan Chulski
This patch enables global flow control in FW and in the
phylink validate mask.
Signed-off-by: Stefan Chulski
---
drivers/net/ethernet/marvell/mvpp2/mvpp2.h | 13 ++---
drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 30 +++-
2 files changed, 38 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
b/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
index ca84995..e010410 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
@@ -763,10 +763,12 @@
((kb) * 1024 - MVPP2_TX_FIFO_THRESHOLD_MIN)
/* MSS Flow control */
-#define MSS_SRAM_SIZE 0x800
-#define FC_QUANTA 0x
-#define FC_CLK_DIVIDER 100
-#define MSS_THRESHOLD_STOP 768
+#define MSS_SRAM_SIZE 0x800
+#define MSS_FC_COM_REG 0
+#define FLOW_CONTROL_ENABLE_BITBIT(0)
+#define FC_QUANTA 0x
+#define FC_CLK_DIVIDER 100
+#define MSS_THRESHOLD_STOP 768
/* RX buffer constants */
#define MVPP2_SKB_SHINFO_SIZE \
@@ -1021,6 +1023,9 @@ struct mvpp2 {
/* CM3 SRAM pool */
struct gen_pool *sram_pool;
+
+ /* Global TX Flow Control config */
+ bool global_tx_fc;
};
struct mvpp2_pcpu_stats {
diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
index 19a3f38..770f45a 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
@@ -92,6 +92,16 @@ static inline u32 mvpp2_cpu_to_thread(struct mvpp2 *priv,
int cpu)
return cpu % priv->nthreads;
}
+static void mvpp2_cm3_write(struct mvpp2 *priv, u32 offset, u32 data)
+{
+ writel(data, priv->cm3_base + offset);
+}
+
+static u32 mvpp2_cm3_read(struct mvpp2 *priv, u32 offset)
+{
+ return readl(priv->cm3_base + offset);
+}
+
static struct page_pool *
mvpp2_create_page_pool(struct device *dev, int num, int len,
enum dma_data_direction dma_dir)
@@ -5951,6 +5961,11 @@ static void mvpp2_phylink_validate(struct phylink_config
*config,
phylink_set(mask, Autoneg);
phylink_set_port_modes(mask);
+ if (port->priv->global_tx_fc) {
+ phylink_set(mask, Pause);
+ phylink_set(mask, Asym_Pause);
+ }
+
switch (state->interface) {
case PHY_INTERFACE_MODE_10GBASER:
case PHY_INTERFACE_MODE_XAUI:
@@ -6969,7 +6984,7 @@ static int mvpp2_probe(struct platform_device *pdev)
struct resource *res;
void __iomem *base;
int i, shared;
- int err;
+ int err, val;
priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
if (!priv)
@@ -7023,6 +7038,10 @@ static int mvpp2_probe(struct platform_device *pdev)
return err;
else if (err)
dev_warn(&pdev->dev, "Fail to alloc CM3 SRAM\n");
+
+ /* Enable global Flow Control only if handler to SRAM not NULL
*/
+ if (priv->cm3_base)
+ priv->global_tx_fc = true;
}
if (priv->hw_version != MVPP21 && dev_of_node(&pdev->dev)) {
@@ -7190,6 +7209,15 @@ static int mvpp2_probe(struct platform_device *pdev)
goto err_port_probe;
}
+ /* Enable global flow control. In this stage global
+* flow control enabled, but still disabled per port.
+*/
+ if (priv->global_tx_fc && priv->hw_version != MVPP21) {
+ val = mvpp2_cm3_read(priv, MSS_FC_COM_REG);
+ val |= FLOW_CONTROL_ENABLE_BIT;
+ mvpp2_cm3_write(priv, MSS_FC_COM_REG, val);
+ }
+
mvpp2_dbgfs_init(priv, pdev->name);
platform_set_drvdata(pdev, priv);
--
1.9.1
[PATCH v6 net-next 07/18] net: mvpp2: increase BM pool size to 2048 buffers
From: Stefan Chulski
BM pool size increased to support Firmware Flow Control.
Minimum depletion thresholds to support FC is 1024 buffers.
BM pool size increased to 2048 to have some 1024 buffers
space between depletion thresholds and BM pool size.
Jumbo frames require a 9888B buffer, so memory requirements
for data buffers increased from 7MB to 24MB.
Signed-off-by: Stefan Chulski
---
drivers/net/ethernet/marvell/mvpp2/mvpp2.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
b/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
index 89b3ede..8dc669d 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
@@ -851,8 +851,8 @@ enum mvpp22_ptp_packet_format {
#define MVPP22_PTP_TIMESTAMPQUEUESELECTBIT(18)
/* BM constants */
-#define MVPP2_BM_JUMBO_BUF_NUM 512
-#define MVPP2_BM_LONG_BUF_NUM 1024
+#define MVPP2_BM_JUMBO_BUF_NUM 2048
+#define MVPP2_BM_LONG_BUF_NUM 2048
#define MVPP2_BM_SHORT_BUF_NUM 2048
#define MVPP2_BM_POOL_SIZE_MAX (16*1024 - MVPP2_BM_POOL_PTR_ALIGN/4)
#define MVPP2_BM_POOL_PTR_ALIGN128
--
1.9.1
Re: [RFC 13/20] mm/tlb: introduce tlb_start_ptes() and tlb_end_ptes()
On Sat, 30. Jan 16:11, Nadav Amit wrote:
> From: Nadav Amit
>
> Introduce tlb_start_ptes() and tlb_end_ptes() which would be called
> before and after PTEs are updated and TLB flushes are deferred. This
> will be later be used for fine granualrity deferred TLB flushing
> detection.
>
> In the meanwhile, move flush_tlb_batched_pending() into
> tlb_start_ptes(). It was not called from mapping_dirty_helpers by
> wp_pte() and clean_record_pte(), which might be a bug.
>
> No additional functional change is intended.
>
> Signed-off-by: Nadav Amit
> Cc: Andrea Arcangeli
> Cc: Andrew Morton
> Cc: Andy Lutomirski
> Cc: Dave Hansen
> Cc: Peter Zijlstra
> Cc: Thomas Gleixner
> Cc: Will Deacon
> Cc: Yu Zhao
> Cc: Nick Piggin
> Cc: x...@kernel.org
> ---
> fs/proc/task_mmu.c | 2 ++
> include/asm-generic/tlb.h | 18 ++
> mm/madvise.c | 6 --
> mm/mapping_dirty_helpers.c | 15 +--
> mm/memory.c| 2 ++
> mm/mprotect.c | 3 ++-
> 6 files changed, 41 insertions(+), 5 deletions(-)
>
> diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
> index 4cd048ffa0f6..d0cce961fa5c 100644
> --- a/fs/proc/task_mmu.c
> +++ b/fs/proc/task_mmu.c
> @@ -1168,6 +1168,7 @@ static int clear_refs_pte_range(pmd_t *pmd, unsigned
> long addr,
> return 0;
>
> pte = pte_offset_map_lock(vma->vm_mm, pmd, addr, &ptl);
> + tlb_start_ptes(&cp->tlb);
> for (; addr != end; pte++, addr += PAGE_SIZE) {
> ptent = *pte;
>
> @@ -1190,6 +1191,7 @@ static int clear_refs_pte_range(pmd_t *pmd, unsigned
> long addr,
> tlb_flush_pte_range(&cp->tlb, addr, PAGE_SIZE);
> ClearPageReferenced(page);
> }
> + tlb_end_ptes(&cp->tlb);
> pte_unmap_unlock(pte - 1, ptl);
> cond_resched();
> return 0;
> diff --git a/include/asm-generic/tlb.h b/include/asm-generic/tlb.h
> index 041be2ef4426..10690763090a 100644
> --- a/include/asm-generic/tlb.h
> +++ b/include/asm-generic/tlb.h
> @@ -58,6 +58,11 @@
> *Defaults to flushing at tlb_end_vma() to reset the range; helps when
> *there's large holes between the VMAs.
> *
> + * - tlb_start_ptes() / tlb_end_ptes; makr the start / end of PTEs change.
Hello Nadav,
short nid makr/mark
Damian
> + *
> + *Does internal accounting to allow fine(r) granularity checks for
> + *pte_accessible() on certain configuration.
> + *
> * - tlb_remove_table()
> *
> *tlb_remove_table() is the basic primitive to free page-table
> directories
> @@ -373,6 +378,10 @@ static inline void tlb_flush(struct mmu_gather *tlb)
> flush_tlb_range(tlb->vma, tlb->start, tlb->end);
> }
> }
> +#endif
> +
> +#if __is_defined(tlb_flush) ||
> \
> + IS_ENABLED(CONFIG_ARCH_WANT_AGGRESSIVE_TLB_FLUSH_BATCHING)
>
> static inline void
> tlb_update_vma(struct mmu_gather *tlb, struct vm_area_struct *vma)
> @@ -523,6 +532,15 @@ static inline void mark_mm_tlb_gen_done(struct mm_struct
> *mm, u64 gen)
>
> #endif /* CONFIG_ARCH_HAS_TLB_GENERATIONS */
>
> +#define tlb_start_ptes(tlb) \
> + do {\
> + struct mmu_gather *_tlb = (tlb);\
> + \
> + flush_tlb_batched_pending(_tlb->mm);\
> + } while (0)
> +
> +static inline void tlb_end_ptes(struct mmu_gather *tlb) { }
> +
> /*
> * tlb_flush_{pte|pmd|pud|p4d}_range() adjust the tlb->start and tlb->end,
> * and set corresponding cleared_*.
> diff --git a/mm/madvise.c b/mm/madvise.c
> index 0938fd3ad228..932c1c2eb9a3 100644
> --- a/mm/madvise.c
> +++ b/mm/madvise.c
> @@ -392,7 +392,7 @@ static int madvise_cold_or_pageout_pte_range(pmd_t *pmd,
> #endif
> tlb_change_page_size(tlb, PAGE_SIZE);
> orig_pte = pte = pte_offset_map_lock(vma->vm_mm, pmd, addr, &ptl);
> - flush_tlb_batched_pending(mm);
> + tlb_start_ptes(tlb);
> arch_enter_lazy_mmu_mode();
> for (; addr < end; pte++, addr += PAGE_SIZE) {
> ptent = *pte;
> @@ -468,6 +468,7 @@ static int madvise_cold_or_pageout_pte_range(pmd_t *pmd,
> }
>
> arch_leave_lazy_mmu_mode();
> + tlb_end_ptes(tlb);
> pte_unmap_unlock(orig_pte, ptl);
> if (pageout)
> reclaim_pages(&page_list);
> @@ -588,7 +589,7 @@ static int madvise_free_pte_range(pmd_t *pmd, unsigned
> long addr,
>
> tlb_change_page_size(tlb, PAGE_SIZE);
> orig_pte = pte = pte_offset_map_lock(mm, pmd, addr, &ptl);
> - flush_tlb_batched_pending(mm);
> + tlb_start_ptes(tlb);
> arch_enter_lazy_mmu_mode();
> for (; addr != end; pte++, addr += PAGE_SIZE) {
> ptent = *pte;
> @@ -692,6 +693,7 @@ static int madvise_free_pte_range(pmd_t *pmd, unsigned
> l
[PATCH v6 net-next 12/18] net: mvpp2: add RXQ flow control configurations
From: Stefan Chulski
This patch add RXQ flow control configurations.
Patch do not enable flow control itself, flow control
disabled by default.
Signed-off-by: Stefan Chulski
---
drivers/net/ethernet/marvell/mvpp2/mvpp2.h | 35 +-
drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 114
2 files changed, 148 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
b/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
index e010410..0f27be0 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
@@ -766,9 +766,36 @@
#define MSS_SRAM_SIZE 0x800
#define MSS_FC_COM_REG 0
#define FLOW_CONTROL_ENABLE_BITBIT(0)
+#define FLOW_CONTROL_UPDATE_COMMAND_BITBIT(31)
#define FC_QUANTA 0x
#define FC_CLK_DIVIDER 100
-#define MSS_THRESHOLD_STOP 768
+
+#define MSS_RXQ_TRESH_BASE 0x200
+#define MSS_RXQ_TRESH_OFFS 4
+#define MSS_RXQ_TRESH_REG(q, fq) (MSS_RXQ_TRESH_BASE + (((q) + (fq)) \
+ * MSS_RXQ_TRESH_OFFS))
+
+#define MSS_RXQ_TRESH_START_MASK 0x
+#define MSS_RXQ_TRESH_STOP_MASK(0x <<
MSS_RXQ_TRESH_STOP_OFFS)
+#define MSS_RXQ_TRESH_STOP_OFFS16
+
+#define MSS_RXQ_ASS_BASE 0x80
+#define MSS_RXQ_ASS_OFFS 4
+#define MSS_RXQ_ASS_PER_REG4
+#define MSS_RXQ_ASS_PER_OFFS 8
+#define MSS_RXQ_ASS_PORTID_OFFS0
+#define MSS_RXQ_ASS_PORTID_MASK0x3
+#define MSS_RXQ_ASS_HOSTID_OFFS2
+#define MSS_RXQ_ASS_HOSTID_MASK0x3F
+
+#define MSS_RXQ_ASS_Q_BASE(q, fq) q) + (fq)) % MSS_RXQ_ASS_PER_REG)
\
+ * MSS_RXQ_ASS_PER_OFFS)
+#define MSS_RXQ_ASS_PQ_BASE(q, fq) q) + (fq)) / MSS_RXQ_ASS_PER_REG) \
+ * MSS_RXQ_ASS_OFFS)
+#define MSS_RXQ_ASS_REG(q, fq) (MSS_RXQ_ASS_BASE + MSS_RXQ_ASS_PQ_BASE(q, fq))
+
+#define MSS_THRESHOLD_STOP 768
+#define MSS_THRESHOLD_START1024
/* RX buffer constants */
#define MVPP2_SKB_SHINFO_SIZE \
@@ -1026,6 +1053,9 @@ struct mvpp2 {
/* Global TX Flow Control config */
bool global_tx_fc;
+
+ /* Spinlocks for CM3 shared memory configuration */
+ spinlock_t mss_spinlock;
};
struct mvpp2_pcpu_stats {
@@ -1188,6 +1218,9 @@ struct mvpp2_port {
bool rx_hwtstamp;
enum hwtstamp_tx_types tx_hwtstamp_type;
struct mvpp2_hwtstamp_queue tx_hwtstamp_queue[2];
+
+ /* Firmware TX flow control */
+ bool tx_fc;
};
/* The mvpp2_tx_desc and mvpp2_rx_desc structures describe the
diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
index 770f45a..cb2d0c5 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
@@ -742,6 +742,110 @@ static void *mvpp2_buf_alloc(struct mvpp2_port *port,
return data;
}
+/* Routine enable flow control for RXQs condition */
+static void mvpp2_rxq_enable_fc(struct mvpp2_port *port)
+{
+ int val, cm3_state, host_id, q;
+ int fq = port->first_rxq;
+ unsigned long flags;
+
+ spin_lock_irqsave(&port->priv->mss_spinlock, flags);
+
+ /* Remove Flow control enable bit to prevent race between FW and Kernel
+* If Flow control were enabled, it would be re-enabled.
+*/
+ val = mvpp2_cm3_read(port->priv, MSS_FC_COM_REG);
+ cm3_state = (val & FLOW_CONTROL_ENABLE_BIT);
+ val &= ~FLOW_CONTROL_ENABLE_BIT;
+ mvpp2_cm3_write(port->priv, MSS_FC_COM_REG, val);
+
+ /* Set same Flow control for all RXQs */
+ for (q = 0; q < port->nrxqs; q++) {
+ /* Set stop and start Flow control RXQ thresholds */
+ val = MSS_THRESHOLD_START;
+ val |= (MSS_THRESHOLD_STOP << MSS_RXQ_TRESH_STOP_OFFS);
+ mvpp2_cm3_write(port->priv, MSS_RXQ_TRESH_REG(q, fq), val);
+
+ val = mvpp2_cm3_read(port->priv, MSS_RXQ_ASS_REG(q, fq));
+ /* Set RXQ port ID */
+ val &= ~(MSS_RXQ_ASS_PORTID_MASK << MSS_RXQ_ASS_Q_BASE(q, fq));
+ val |= (port->id << MSS_RXQ_ASS_Q_BASE(q, fq));
+ val &= ~(MSS_RXQ_ASS_HOSTID_MASK << (MSS_RXQ_ASS_Q_BASE(q, fq)
+ + MSS_RXQ_ASS_HOSTID_OFFS));
+
+ /* Calculate RXQ host ID:
+* In Single queue mode: Host ID equal to Host ID used for
+* shared RX interrupt
+* In Multi queue mode: Host ID equal to number of
+* RXQ ID / number of CoS queues
+* In Single resource mode: Host ID always equal to 0
+*/
+ if (queue_mode == MVPP2_QDIST_SINGLE_MODE)
+ host_id = port->nqvecs;
+
[PATCH v6 net-next 14/18] net: mvpp2: add BM protection underrun feature support
From: Stefan Chulski
Feature double size of BPPI by decreasing number of pools from 16 to 8.
Increasing of BPPI size protect BM drop from BPPI underrun.
Underrun could occurred due to stress on DDR and as result slow buffer
transition from BPPE to BPPI.
New BPPI threshold recommended by spec is:
BPPI low threshold - 640 buffers
BPPI high threshold - 832 buffers
Supported only in PPv23.
Signed-off-by: Stefan Chulski
---
drivers/net/ethernet/marvell/mvpp2/mvpp2.h | 8 +
drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 35 +++-
2 files changed, 42 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
b/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
index 9071ab6..1967493 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
@@ -324,6 +324,10 @@
#define MVPP2_BM_HIGH_THRESH_MASK 0x7f
#define MVPP2_BM_HIGH_THRESH_VALUE(val)((val) << \
MVPP2_BM_HIGH_THRESH_OFFS)
+#define MVPP2_BM_BPPI_HIGH_THRESH 0x1E
+#define MVPP2_BM_BPPI_LOW_THRESH 0x1C
+#define MVPP23_BM_BPPI_HIGH_THRESH 0x34
+#define MVPP23_BM_BPPI_LOW_THRESH 0x28
#define MVPP2_BM_INTR_CAUSE_REG(pool) (0x6240 + ((pool) * 4))
#define MVPP2_BM_RELEASED_DELAY_MASK BIT(0)
#define MVPP2_BM_ALLOC_FAILED_MASK BIT(1)
@@ -352,6 +356,10 @@
#define MVPP2_OVERRUN_ETH_DROP 0x7000
#define MVPP2_CLS_ETH_DROP 0x7020
+#define MVPP22_BM_POOL_BASE_ADDR_HIGH_REG 0x6310
+#define MVPP22_BM_POOL_BASE_ADDR_HIGH_MASK 0xff
+#define MVPP23_BM_8POOL_MODE BIT(8)
+
/* Hit counters registers */
#define MVPP2_CTRS_IDX 0x7040
#define MVPP22_CTRS_TX_CTR(port, txq) ((txq) | ((port) << 3) | BIT(7))
diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
index 1d4d5a8..c7517b1f 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
@@ -70,6 +70,11 @@ enum mvpp2_bm_pool_log_num {
module_param(queue_mode, int, 0444);
MODULE_PARM_DESC(queue_mode, "Set queue_mode (single=0, multi=1)");
+static int bm_underrun_protect = 1;
+
+module_param(bm_underrun_protect, int, 0444);
+MODULE_PARM_DESC(bm_underrun_protect, "Set BM underrun protect feature (0-1),
def=1");
+
/* Utility/helper methods */
void mvpp2_write(struct mvpp2 *priv, u32 offset, u32 data)
@@ -424,6 +429,21 @@ static int mvpp2_bm_pool_create(struct device *dev, struct
mvpp2 *priv,
val = mvpp2_read(priv, MVPP2_BM_POOL_CTRL_REG(bm_pool->id));
val |= MVPP2_BM_START_MASK;
+
+ val &= ~MVPP2_BM_LOW_THRESH_MASK;
+ val &= ~MVPP2_BM_HIGH_THRESH_MASK;
+
+ /* Set 8 Pools BPPI threshold if BM underrun protection feature
+* were enabled
+*/
+ if (priv->hw_version == MVPP23 && bm_underrun_protect) {
+ val |= MVPP2_BM_LOW_THRESH_VALUE(MVPP23_BM_BPPI_LOW_THRESH);
+ val |= MVPP2_BM_HIGH_THRESH_VALUE(MVPP23_BM_BPPI_HIGH_THRESH);
+ } else {
+ val |= MVPP2_BM_LOW_THRESH_VALUE(MVPP2_BM_BPPI_LOW_THRESH);
+ val |= MVPP2_BM_HIGH_THRESH_VALUE(MVPP2_BM_BPPI_HIGH_THRESH);
+ }
+
mvpp2_write(priv, MVPP2_BM_POOL_CTRL_REG(bm_pool->id), val);
bm_pool->size = size;
@@ -592,6 +612,16 @@ static int mvpp2_bm_pools_init(struct device *dev, struct
mvpp2 *priv)
return err;
}
+/* Routine enable PPv23 8 pool mode */
+static void mvpp23_bm_set_8pool_mode(struct mvpp2 *priv)
+{
+ int val;
+
+ val = mvpp2_read(priv, MVPP22_BM_POOL_BASE_ADDR_HIGH_REG);
+ val |= MVPP23_BM_8POOL_MODE;
+ mvpp2_write(priv, MVPP22_BM_POOL_BASE_ADDR_HIGH_REG, val);
+}
+
static int mvpp2_bm_init(struct device *dev, struct mvpp2 *priv)
{
enum dma_data_direction dma_dir = DMA_FROM_DEVICE;
@@ -645,6 +675,9 @@ static int mvpp2_bm_init(struct device *dev, struct mvpp2
*priv)
if (!priv->bm_pools)
return -ENOMEM;
+ if (priv->hw_version == MVPP23 && bm_underrun_protect)
+ mvpp23_bm_set_8pool_mode(priv);
+
err = mvpp2_bm_pools_init(dev, priv);
if (err < 0)
return err;
@@ -6489,7 +6522,7 @@ static void mvpp2_mac_link_up(struct phylink_config
*config,
val);
}
- if (port->priv->global_tx_fc) {
+ if (port->priv->global_tx_fc && bm_underrun_protect) {
port->tx_fc = tx_pause;
if (tx_pause)
mvpp2_rxq_enable_fc(port);
--
1.9.1
[PATCH v6 net-next 15/18] net: mvpp2: add PPv23 RX FIFO flow control
From: Stefan Chulski
New FIFO flow control feature were added in PPv23.
PPv2 FIFO polled by HW and trigger pause frame if FIFO
fill level is below threshold.
FIFO HW flow control enabled with CM3 RXQ&BM flow
control with ethtool.
Current FIFO thresholds is:
9KB for port with maximum speed 10Gb/s port
4KB for port with maximum speed 5Gb/s port
2KB for port with maximum speed 1Gb/s port
Signed-off-by: Stefan Chulski
---
drivers/net/ethernet/marvell/mvpp2/mvpp2.h | 15 ++
drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 53
2 files changed, 68 insertions(+)
diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
b/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
index 1967493..9947385 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
@@ -770,6 +770,18 @@
#define MVPP2_TX_FIFO_THRESHOLD(kb)\
((kb) * 1024 - MVPP2_TX_FIFO_THRESHOLD_MIN)
+/* RX FIFO threshold in 1KB granularity */
+#define MVPP23_PORT0_FIFO_TRSH (9 * 1024)
+#define MVPP23_PORT1_FIFO_TRSH (4 * 1024)
+#define MVPP23_PORT2_FIFO_TRSH (2 * 1024)
+
+/* RX Flow Control Registers */
+#define MVPP2_RX_FC_REG(port) (0x150 + 4 * (port))
+#define MVPP2_RX_FC_EN BIT(24)
+#define MVPP2_RX_FC_TRSH_OFFS 16
+#define MVPP2_RX_FC_TRSH_MASK (0xFF << MVPP2_RX_FC_TRSH_OFFS)
+#define MVPP2_RX_FC_TRSH_UNIT 256
+
/* MSS Flow control */
#define MSS_SRAM_SIZE 0x800
#define MSS_FC_COM_REG 0
@@ -1502,6 +1514,8 @@ struct mvpp2_bm_pool {
void mvpp2_dbgfs_cleanup(struct mvpp2 *priv);
+void mvpp23_rx_fifo_fc_en(struct mvpp2 *priv, int port, bool en);
+
#ifdef CONFIG_MVPP2_PTP
int mvpp22_tai_probe(struct device *dev, struct mvpp2 *priv);
void mvpp22_tai_tstamp(struct mvpp2_tai *tai, u32 tstamp,
@@ -1534,4 +1548,5 @@ static inline bool mvpp22_rx_hwtstamping(struct
mvpp2_port *port)
{
return IS_ENABLED(CONFIG_MVPP2_PTP) && port->rx_hwtstamp;
}
+
#endif
diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
index c7517b1f..afa61cc 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
@@ -6535,6 +6535,8 @@ static void mvpp2_mac_link_up(struct phylink_config
*config,
mvpp2_bm_pool_update_fc(port, port->pool_long,
tx_pause);
mvpp2_bm_pool_update_fc(port, port->pool_short,
tx_pause);
}
+ if (port->priv->hw_version == MVPP23)
+ mvpp23_rx_fifo_fc_en(port->priv, port->id, tx_pause);
}
mvpp2_port_enable(port);
@@ -7003,6 +7005,55 @@ static void mvpp22_rx_fifo_init(struct mvpp2 *priv)
mvpp2_write(priv, MVPP2_RX_FIFO_INIT_REG, 0x1);
}
+/* Configure Rx FIFO Flow control thresholds */
+static void mvpp23_rx_fifo_fc_set_tresh(struct mvpp2 *priv)
+{
+ int port, val;
+
+ /* Port 0: maximum speed -10Gb/s port
+* required by spec RX FIFO threshold 9KB
+* Port 1: maximum speed -5Gb/s port
+* required by spec RX FIFO threshold 4KB
+* Port 2: maximum speed -1Gb/s port
+* required by spec RX FIFO threshold 2KB
+*/
+
+ /* Without loopback port */
+ for (port = 0; port < (MVPP2_MAX_PORTS - 1); port++) {
+ if (port == 0) {
+ val = (MVPP23_PORT0_FIFO_TRSH / MVPP2_RX_FC_TRSH_UNIT)
+ << MVPP2_RX_FC_TRSH_OFFS;
+ val &= MVPP2_RX_FC_TRSH_MASK;
+ mvpp2_write(priv, MVPP2_RX_FC_REG(port), val);
+ } else if (port == 1) {
+ val = (MVPP23_PORT1_FIFO_TRSH / MVPP2_RX_FC_TRSH_UNIT)
+ << MVPP2_RX_FC_TRSH_OFFS;
+ val &= MVPP2_RX_FC_TRSH_MASK;
+ mvpp2_write(priv, MVPP2_RX_FC_REG(port), val);
+ } else {
+ val = (MVPP23_PORT2_FIFO_TRSH / MVPP2_RX_FC_TRSH_UNIT)
+ << MVPP2_RX_FC_TRSH_OFFS;
+ val &= MVPP2_RX_FC_TRSH_MASK;
+ mvpp2_write(priv, MVPP2_RX_FC_REG(port), val);
+ }
+ }
+}
+
+/* Configure Rx FIFO Flow control thresholds */
+void mvpp23_rx_fifo_fc_en(struct mvpp2 *priv, int port, bool en)
+{
+ int val;
+
+ val = mvpp2_read(priv, MVPP2_RX_FC_REG(port));
+
+ if (en)
+ val |= MVPP2_RX_FC_EN;
+ else
+ val &= ~MVPP2_RX_FC_EN;
+
+ mvpp2_write(priv, MVPP2_RX_FC_REG(port), val);
+}
+
static void mvpp22_tx_fifo_set_hw(struct mvpp2 *priv, int port, int size)
{
int threshold = MVPP2_TX_FIFO_THRESHOLD(size);
@@ -7154,6 +7205,8 @@ static int mvpp2_init(struct platform_device *pdev,
struct mvpp2 *priv)
} else {
mvpp22_rx_fifo_init(priv);
[PATCH v6 net-next 13/18] net: mvpp2: add ethtool flow control configuration support
From: Stefan Chulski
This patch add ethtool flow control configuration support.
Tx flow control retrieved correctly by ethtool get function.
FW per port ethtool configuration capability added.
Patch also takes care about mtu change procedure, if PPv2 switch
BM pools during mtu change.
Signed-off-by: Stefan Chulski
---
drivers/net/ethernet/marvell/mvpp2/mvpp2.h | 13 +++
drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 98
2 files changed, 111 insertions(+)
diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
b/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
index 0f27be0..9071ab6 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
@@ -775,6 +775,19 @@
#define MSS_RXQ_TRESH_REG(q, fq) (MSS_RXQ_TRESH_BASE + (((q) + (fq)) \
* MSS_RXQ_TRESH_OFFS))
+#define MSS_BUF_POOL_BASE 0x40
+#define MSS_BUF_POOL_OFFS 4
+#define MSS_BUF_POOL_REG(id) (MSS_BUF_POOL_BASE \
+ + (id) * MSS_BUF_POOL_OFFS)
+
+#define MSS_BUF_POOL_STOP_MASK 0xFFF
+#define MSS_BUF_POOL_START_MASK(0xFFF <<
MSS_BUF_POOL_START_OFFS)
+#define MSS_BUF_POOL_START_OFFS12
+#define MSS_BUF_POOL_PORTS_MASK(0xF << MSS_BUF_POOL_PORTS_OFFS)
+#define MSS_BUF_POOL_PORTS_OFFS24
+#define MSS_BUF_POOL_PORT_OFFS(id) (0x1 << \
+ ((id) + MSS_BUF_POOL_PORTS_OFFS))
+
#define MSS_RXQ_TRESH_START_MASK 0x
#define MSS_RXQ_TRESH_STOP_MASK(0x <<
MSS_RXQ_TRESH_STOP_OFFS)
#define MSS_RXQ_TRESH_STOP_OFFS16
diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
index cb2d0c5..1d4d5a8 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
@@ -846,6 +846,59 @@ static void mvpp2_rxq_disable_fc(struct mvpp2_port *port)
spin_unlock_irqrestore(&port->priv->mss_spinlock, flags);
}
+/* Routine disable/enable flow control for BM pool condition */
+static void mvpp2_bm_pool_update_fc(struct mvpp2_port *port,
+ struct mvpp2_bm_pool *pool,
+ bool en)
+{
+ int val, cm3_state;
+ unsigned long flags;
+
+ spin_lock_irqsave(&port->priv->mss_spinlock, flags);
+
+ /* Remove Flow control enable bit to prevent race between FW and Kernel
+* If Flow control were enabled, it would be re-enabled.
+*/
+ val = mvpp2_cm3_read(port->priv, MSS_FC_COM_REG);
+ cm3_state = (val & FLOW_CONTROL_ENABLE_BIT);
+ val &= ~FLOW_CONTROL_ENABLE_BIT;
+ mvpp2_cm3_write(port->priv, MSS_FC_COM_REG, val);
+
+ /* Check if BM pool should be enabled/disable */
+ if (en) {
+ /* Set BM pool start and stop thresholds per port */
+ val = mvpp2_cm3_read(port->priv, MSS_BUF_POOL_REG(pool->id));
+ val |= MSS_BUF_POOL_PORT_OFFS(port->id);
+ val &= ~MSS_BUF_POOL_START_MASK;
+ val |= (MSS_THRESHOLD_START << MSS_BUF_POOL_START_OFFS);
+ val &= ~MSS_BUF_POOL_STOP_MASK;
+ val |= MSS_THRESHOLD_STOP;
+ mvpp2_cm3_write(port->priv, MSS_BUF_POOL_REG(pool->id), val);
+ } else {
+ /* Remove BM pool from the port */
+ val = mvpp2_cm3_read(port->priv, MSS_BUF_POOL_REG(pool->id));
+ val &= ~MSS_BUF_POOL_PORT_OFFS(port->id);
+
+ /* Zero BM pool start and stop thresholds to disable pool
+* flow control if pool empty (not used by any port)
+*/
+ if (!pool->buf_num) {
+ val &= ~MSS_BUF_POOL_START_MASK;
+ val &= ~MSS_BUF_POOL_STOP_MASK;
+ }
+
+ mvpp2_cm3_write(port->priv, MSS_BUF_POOL_REG(pool->id), val);
+ }
+
+ /* Notify Firmware that Flow control config space ready for update */
+ val = mvpp2_cm3_read(port->priv, MSS_FC_COM_REG);
+ val |= FLOW_CONTROL_UPDATE_COMMAND_BIT;
+ val |= cm3_state;
+ mvpp2_cm3_write(port->priv, MSS_FC_COM_REG, val);
+
+ spin_unlock_irqrestore(&port->priv->mss_spinlock, flags);
+}
+
/* Release buffer to BM */
static inline void mvpp2_bm_pool_put(struct mvpp2_port *port, int pool,
dma_addr_t buf_dma_addr,
@@ -1176,6 +1229,16 @@ static int mvpp2_bm_update_mtu(struct net_device *dev,
int mtu)
new_long_pool = MVPP2_BM_LONG;
if (new_long_pool != port->pool_long->id) {
+ if (port->tx_fc) {
+ if (pkt_size > MVPP2_BM_LONG_PKT_SIZE)
+ mvpp2_bm_pool_update_fc(port,
+
[PATCH 1/2] drm/bridge: dw-hdmi: Add DT binding to disable hotplug detect
Add "disable-hpd" boolean binding for the device tree. When this option
is turned on HPD-related IRQ is disabled and it is assumed that the HDMI
connector is connected all the time. This may be useful in systems where
it is impossible or undesirable to connect the HPD pin, or the
connection is broken.
Signed-off-by: Mykyta Poturai
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index 0c79a9ba48bb..4ca0ac130beb 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -194,6 +194,7 @@ struct dw_hdmi {
unsigned int audio_cts;
unsigned int audio_n;
bool audio_enable;
+ bool disable_hpd;
unsigned int reg_shift;
struct regmap *regm;
@@ -1559,7 +1560,7 @@ static void dw_hdmi_phy_disable(struct dw_hdmi *hdmi,
void *data)
enum drm_connector_status dw_hdmi_phy_read_hpd(struct dw_hdmi *hdmi,
void *data)
{
- return hdmi_readb(hdmi, HDMI_PHY_STAT0) & HDMI_PHY_HPD ?
+ return hdmi_readb(hdmi, HDMI_PHY_STAT0) & HDMI_PHY_HPD ||
hdmi->disable_hpd ?
connector_status_connected : connector_status_disconnected;
}
EXPORT_SYMBOL_GPL(dw_hdmi_phy_read_hpd);
@@ -1585,6 +1586,10 @@ void dw_hdmi_phy_setup_hpd(struct dw_hdmi *hdmi, void
*data)
* Configure the PHY RX SENSE and HPD interrupts polarities and clear
* any pending interrupt.
*/
+
+ if (hdmi->disable_hpd)
+ return;
+
hdmi_writeb(hdmi, HDMI_PHY_HPD | HDMI_PHY_RX_SENSE, HDMI_PHY_POL0);
hdmi_writeb(hdmi, HDMI_IH_PHY_STAT0_HPD | HDMI_IH_PHY_STAT0_RX_SENSE,
HDMI_IH_PHY_STAT0);
@@ -3212,6 +3217,10 @@ struct dw_hdmi *dw_hdmi_probe(struct platform_device
*pdev,
mutex_init(&hdmi->cec_notifier_mutex);
spin_lock_init(&hdmi->audio_lock);
+ if (of_property_read_bool(np, "disable-hpd")) {
+ dev_info(hdmi->dev, "Disabling HPD\n");
+ hdmi->disable_hpd = true;
+ }
ddc_node = of_parse_phandle(np, "ddc-i2c-bus", 0);
if (ddc_node) {
hdmi->ddc = of_get_i2c_adapter_by_node(ddc_node);
--
2.30.0
Re: Process-wide watchpoints
On Thu, Nov 12, 2020 at 11:43 AM Dmitry Vyukov wrote:
> > > for sampling race detection),
> > > number of threads in the process can be up to, say, ~~10K and the
> > > watchpoint is intended to be set for a very brief period of time
> > > (~~few ms).
> >
> > Performance is a consideration here, doing lots of IPIs in such a short
> > window, on potentially large machines is a DoS risk.
> >
> > > This can be done today with both perf_event_open and ptrace.
> > > However, the problem is that both APIs work on a single thread level
> > > (? perf_event_open can be inherited by children, but not for existing
> > > siblings). So doing this would require iterating over, say, 10K
> >
> > One way would be to create the event before the process starts spawning
> > threads and keeping it disabled. Then every thread will inherit it, but
> > it'll be inactive.
> >
> > > I see at least one potential problem: what do we do if some sibling
> > > thread already has all 4 watchpoints consumed?
> >
> > That would be immediately avoided by this, since it will have the
> > watchpoint reserved per inheriting the event.
> >
> > Then you can do ioctl(PERF_EVENT_IOC_{MODIFY_ATTRIBUTES,ENABLE,DISABLE})
> > to update the watch location and enable/disable it. This _will_ indeed
> > result in a shitload of IPIs if the threads are active, but it should
> > work.
>
> Aha! That's the possibility I missed.
> We will try to prototype this and get back with more questions if/when
> we have them.
> Thanks!
Hi Peter,
I've tested this approach and it works, but only in half.
PERF_EVENT_IOC_{ENABLE,DISABLE} work as advertised.
However, PERF_EVENT_IOC_MODIFY_ATTRIBUTES does not work for inherited
child events.
Does something like this make any sense to you? Are you willing to
accept such change?
diff --git a/kernel/events/core.c b/kernel/events/core.c
index 55d18791a72d..f6974807a32c 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -3174,7 +3174,7 @@ int perf_event_refresh(struct perf_event *event,
int refresh)
}
EXPORT_SYMBOL_GPL(perf_event_refresh);
-static int perf_event_modify_breakpoint(struct perf_event *bp,
+static int _perf_event_modify_breakpoint(struct perf_event *bp,
struct perf_event_attr *attr)
{
int err;
@@ -3189,6 +3189,28 @@ static int perf_event_modify_breakpoint(struct
perf_event *bp,
return err;
}
+static int perf_event_modify_breakpoint(struct perf_event *bp,
+ struct perf_event_attr *attr)
+{
+ struct perf_event *child;
+ int err;
+
+ WARN_ON_ONCE(bp->ctx->parent_ctx);
+
+ mutex_lock(&bp->child_mutex);
+ err = _perf_event_modify_breakpoint(bp, attr);
+ if (err)
+ goto unlock;
+ list_for_each_entry(child, &bp->child_list, child_list) {
+ err = _perf_event_modify_breakpoint(child, attr);
+ if (err)
+ goto unlock;
+ }
+unlock:
+ mutex_unlock(&bp->child_mutex);
+ return err;
+}
+
static int perf_event_modify_attr(struct perf_event *event,
struct perf_event_attr *attr)
Re: [PATCH] riscv: virt_addr_valid must check the address belongs to linear mapping
On Fri, Jan 29, 2021 at 6:31 PM Alexandre Ghiti wrote:
>
> virt_addr_valid macro checks that a virtual address is valid, ie that
> the address belongs to the linear mapping and that the corresponding
> physical page exists.
>
> Add the missing check that ensures the virtual address belongs to the
> linear mapping, otherwise __virt_to_phys, when compiled with
> CONFIG_DEBUG_VIRTUAL enabled, raises a WARN that is interpreted as a
> kernel bug by syzbot.
Thanks, Alexandre. Much appreciated.
> Signed-off-by: Alexandre Ghiti
> ---
> arch/riscv/include/asm/page.h | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/arch/riscv/include/asm/page.h b/arch/riscv/include/asm/page.h
> index 2d50f76efe48..64a675c5c30a 100644
> --- a/arch/riscv/include/asm/page.h
> +++ b/arch/riscv/include/asm/page.h
> @@ -135,7 +135,10 @@ extern phys_addr_t __phys_addr_symbol(unsigned long x);
>
> #endif /* __ASSEMBLY__ */
>
> -#define virt_addr_valid(vaddr) (pfn_valid(virt_to_pfn(vaddr)))
> +#define virt_addr_valid(vaddr) ({
> \
> + unsigned long _addr = (unsigned long)vaddr;
> \
> + (unsigned long)(_addr) >= PAGE_OFFSET &&
> pfn_valid(virt_to_pfn(_addr)); \
> +})
>
> #define VM_DATA_DEFAULT_FLAGS VM_DATA_FLAGS_NON_EXEC
>
> --
> 2.20.1
>
[PATCH 2/2] dt-bindings: display: Add "disable-hpd" binding
Add the "disable-hpd" binding, used to disable hotplug detected functionality in the driver. When it's enabled the driver assumes that the connector is always connected and disables the hotplug detect related IRQ. Signed-off-by: Mykyta Poturai --- .../devicetree/bindings/display/bridge/renesas,dw-hdmi.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt b/Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt index 3f6072651182..b2b899f46b86 100644 --- a/Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt +++ b/Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt @@ -39,6 +39,7 @@ Optional properties: - power-domains: Shall reference the power domain that contains the DWC HDMI, if any. +- disable-hpd: Disables the hotplug detect feature Example: -- 2.30.0
Re: [RFC 13/20] mm/tlb: introduce tlb_start_ptes() and tlb_end_ptes()
On Sat, 30. Jan 16:11, Nadav Amit wrote:
> From: Nadav Amit
>
> Introduce tlb_start_ptes() and tlb_end_ptes() which would be called
> before and after PTEs are updated and TLB flushes are deferred. This
> will be later be used for fine granualrity deferred TLB flushing
> detection.
>
> In the meanwhile, move flush_tlb_batched_pending() into
> tlb_start_ptes(). It was not called from mapping_dirty_helpers by
> wp_pte() and clean_record_pte(), which might be a bug.
>
> No additional functional change is intended.
>
> Signed-off-by: Nadav Amit
> Cc: Andrea Arcangeli
> Cc: Andrew Morton
> Cc: Andy Lutomirski
> Cc: Dave Hansen
> Cc: Peter Zijlstra
> Cc: Thomas Gleixner
> Cc: Will Deacon
> Cc: Yu Zhao
> Cc: Nick Piggin
> Cc: x...@kernel.org
> ---
> fs/proc/task_mmu.c | 2 ++
> include/asm-generic/tlb.h | 18 ++
> mm/madvise.c | 6 --
> mm/mapping_dirty_helpers.c | 15 +--
> mm/memory.c| 2 ++
> mm/mprotect.c | 3 ++-
> 6 files changed, 41 insertions(+), 5 deletions(-)
>
> diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
> index 4cd048ffa0f6..d0cce961fa5c 100644
> --- a/fs/proc/task_mmu.c
> +++ b/fs/proc/task_mmu.c
> @@ -1168,6 +1168,7 @@ static int clear_refs_pte_range(pmd_t *pmd, unsigned
> long addr,
> return 0;
>
> pte = pte_offset_map_lock(vma->vm_mm, pmd, addr, &ptl);
> + tlb_start_ptes(&cp->tlb);
> for (; addr != end; pte++, addr += PAGE_SIZE) {
> ptent = *pte;
>
> @@ -1190,6 +1191,7 @@ static int clear_refs_pte_range(pmd_t *pmd, unsigned
> long addr,
> tlb_flush_pte_range(&cp->tlb, addr, PAGE_SIZE);
> ClearPageReferenced(page);
> }
> + tlb_end_ptes(&cp->tlb);
> pte_unmap_unlock(pte - 1, ptl);
> cond_resched();
> return 0;
> diff --git a/include/asm-generic/tlb.h b/include/asm-generic/tlb.h
> index 041be2ef4426..10690763090a 100644
> --- a/include/asm-generic/tlb.h
> +++ b/include/asm-generic/tlb.h
> @@ -58,6 +58,11 @@
> *Defaults to flushing at tlb_end_vma() to reset the range; helps when
> *there's large holes between the VMAs.
> *
> + * - tlb_start_ptes() / tlb_end_ptes; makr the start / end of PTEs change.
Hello Nadav,
short nid makr/mark
Damian
> + *
> + *Does internal accounting to allow fine(r) granularity checks for
> + *pte_accessible() on certain configuration.
> + *
> * - tlb_remove_table()
> *
> *tlb_remove_table() is the basic primitive to free page-table
> directories
> @@ -373,6 +378,10 @@ static inline void tlb_flush(struct mmu_gather *tlb)
> flush_tlb_range(tlb->vma, tlb->start, tlb->end);
> }
> }
> +#endif
> +
> +#if __is_defined(tlb_flush) ||
> \
> + IS_ENABLED(CONFIG_ARCH_WANT_AGGRESSIVE_TLB_FLUSH_BATCHING)
>
> static inline void
> tlb_update_vma(struct mmu_gather *tlb, struct vm_area_struct *vma)
> @@ -523,6 +532,15 @@ static inline void mark_mm_tlb_gen_done(struct mm_struct
> *mm, u64 gen)
>
> #endif /* CONFIG_ARCH_HAS_TLB_GENERATIONS */
>
> +#define tlb_start_ptes(tlb) \
> + do {\
> + struct mmu_gather *_tlb = (tlb);\
> + \
> + flush_tlb_batched_pending(_tlb->mm);\
> + } while (0)
> +
> +static inline void tlb_end_ptes(struct mmu_gather *tlb) { }
> +
> /*
> * tlb_flush_{pte|pmd|pud|p4d}_range() adjust the tlb->start and tlb->end,
> * and set corresponding cleared_*.
> diff --git a/mm/madvise.c b/mm/madvise.c
> index 0938fd3ad228..932c1c2eb9a3 100644
> --- a/mm/madvise.c
> +++ b/mm/madvise.c
> @@ -392,7 +392,7 @@ static int madvise_cold_or_pageout_pte_range(pmd_t *pmd,
> #endif
> tlb_change_page_size(tlb, PAGE_SIZE);
> orig_pte = pte = pte_offset_map_lock(vma->vm_mm, pmd, addr, &ptl);
> - flush_tlb_batched_pending(mm);
> + tlb_start_ptes(tlb);
> arch_enter_lazy_mmu_mode();
> for (; addr < end; pte++, addr += PAGE_SIZE) {
> ptent = *pte;
> @@ -468,6 +468,7 @@ static int madvise_cold_or_pageout_pte_range(pmd_t *pmd,
> }
>
> arch_leave_lazy_mmu_mode();
> + tlb_end_ptes(tlb);
> pte_unmap_unlock(orig_pte, ptl);
> if (pageout)
> reclaim_pages(&page_list);
> @@ -588,7 +589,7 @@ static int madvise_free_pte_range(pmd_t *pmd, unsigned
> long addr,
>
> tlb_change_page_size(tlb, PAGE_SIZE);
> orig_pte = pte = pte_offset_map_lock(mm, pmd, addr, &ptl);
> - flush_tlb_batched_pending(mm);
> + tlb_start_ptes(tlb);
> arch_enter_lazy_mmu_mode();
> for (; addr != end; pte++, addr += PAGE_SIZE) {
> ptent = *pte;
> @@ -692,6 +693,7 @@ static int madvise_free_pte_range(pmd_t *pmd, unsigned
> lo
[PATCH v6 net-next 05/18] net: mvpp2: add PPv23 version definition
From: Stefan Chulski
This patch add PPv23 version definition.
PPv23 is new packet processor in CP115.
Everything that supported by PPv22, also supported by PPv23.
No functional changes in this stage.
Signed-off-by: Stefan Chulski
---
drivers/net/ethernet/marvell/mvpp2/mvpp2.h | 24
drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 17 +-
2 files changed, 25 insertions(+), 16 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
b/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
index aec9179..89b3ede 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
@@ -60,6 +60,9 @@
/* Top Registers */
#define MVPP2_MH_REG(port) (0x5040 + 4 * (port))
#define MVPP2_DSA_EXTENDED BIT(5)
+#define MVPP2_VER_ID_REG 0x50b0
+#define MVPP2_VER_PP22 0x10
+#define MVPP2_VER_PP23 0x11
/* Parser Registers */
#define MVPP2_PRS_INIT_LOOKUP_REG 0x1000
@@ -469,7 +472,7 @@
#define MVPP22_GMAC_INT_SUM_MASK_LINK_STAT BIT(1)
#defineMVPP22_GMAC_INT_SUM_MASK_PTPBIT(2)
-/* Per-port XGMAC registers. PPv2.2 only, only for GOP port 0,
+/* Per-port XGMAC registers. PPv2.2 and PPv2.3, only for GOP port 0,
* relative to port->base.
*/
#define MVPP22_XLG_CTRL0_REG 0x100
@@ -506,7 +509,7 @@
#define MVPP22_XLG_CTRL4_MACMODSELECT_GMAC BIT(12)
#define MVPP22_XLG_CTRL4_EN_IDLE_CHECK BIT(14)
-/* SMI registers. PPv2.2 only, relative to priv->iface_base. */
+/* SMI registers. PPv2.2 and PPv2.3, relative to priv->iface_base. */
#define MVPP22_SMI_MISC_CFG_REG0x1204
#define MVPP22_SMI_POLLING_EN BIT(10)
@@ -582,7 +585,7 @@
#define MVPP2_QUEUE_NEXT_DESC(q, index) \
(((index) < (q)->last_desc) ? ((index) + 1) : 0)
-/* XPCS registers. PPv2.2 only */
+/* XPCS registers.PPv2.2 and PPv2.3 */
#define MVPP22_MPCS_BASE(port) (0x7000 + (port) * 0x1000)
#define MVPP22_MPCS_CTRL 0x14
#define MVPP22_MPCS_CTRL_FWD_ERR_CONN BIT(10)
@@ -593,7 +596,7 @@
#define MVPP22_MPCS_CLK_RESET_DIV_RATIO(n) ((n) << 4)
#define MVPP22_MPCS_CLK_RESET_DIV_SET BIT(11)
-/* XPCS registers. PPv2.2 only */
+/* XPCS registers. PPv2.2 and PPv2.3 */
#define MVPP22_XPCS_BASE(port) (0x7400 + (port) * 0x1000)
#define MVPP22_XPCS_CFG0 0x0
#define MVPP22_XPCS_CFG0_RESET_DIS BIT(0)
@@ -930,15 +933,16 @@ struct mvpp2 {
void __iomem *iface_base;
void __iomem *cm3_base;
- /* On PPv2.2, each "software thread" can access the base
+ /* On PPv2.2 and PPv2.3, each "software thread" can access the base
* register through a separate address space, each 64 KB apart
* from each other. Typically, such address spaces will be
* used per CPU.
*/
void __iomem *swth_base[MVPP2_MAX_THREADS];
- /* On PPv2.2, some port control registers are located into the system
-* controller space. These registers are accessible through a regmap.
+ /* On PPv2.2 and PPv2.3, some port control registers are located into
+* the system controller space. These registers are accessible
+* through a regmap.
*/
struct regmap *sysctrl_base;
@@ -980,7 +984,7 @@ struct mvpp2 {
u32 tclk;
/* HW version */
- enum { MVPP21, MVPP22 } hw_version;
+ enum { MVPP21, MVPP22, MVPP23 } hw_version;
/* Maximum number of RXQs per port */
unsigned int max_port_rxqs;
@@ -1227,7 +1231,7 @@ struct mvpp21_rx_desc {
__le32 reserved8;
};
-/* HW TX descriptor for PPv2.2 */
+/* HW TX descriptor for PPv2.2 and PPv2.3 */
struct mvpp22_tx_desc {
__le32 command;
u8 packet_offset;
@@ -1239,7 +1243,7 @@ struct mvpp22_tx_desc {
__le64 buf_cookie_misc;
};
-/* HW RX descriptor for PPv2.2 */
+/* HW RX descriptor for PPv2.2 and PPv2.3 */
struct mvpp22_rx_desc {
__le32 status;
__le16 reserved1;
diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
index 307f9fd..11c56d2 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
@@ -385,7 +385,7 @@ static int mvpp2_bm_pool_create(struct device *dev, struct
mvpp2 *priv,
if (!IS_ALIGNED(size, 16))
return -EINVAL;
- /* PPv2.1 needs 8 bytes per buffer pointer, PPv2.2 needs 16
+ /* PPv2.1 needs 8 bytes per buffer pointer, PPv2.2 and PPv2.3 needs 16
* bytes per buffer pointer
*/
if (priv->hw_version == MVPP21)
@@ -1173,7 +1173,7 @@ static void mvpp2_interrupts_unmask(void *arg)
u32 val;
int i;
- if (port->priv->hw_version != MVPP22)
+ if
[PATCH] ALSA: intel8x0: Fix missing check in snd_intel8x0m_create
When device_type == DEVICE_ALI, we should also check the return
value of pci_iomap() to avoid potential null pointer dereference.
Signed-off-by: Dinghao Liu
---
sound/pci/intel8x0m.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/sound/pci/intel8x0m.c b/sound/pci/intel8x0m.c
index 1b7df0c4e57c..19872cecc9d2 100644
--- a/sound/pci/intel8x0m.c
+++ b/sound/pci/intel8x0m.c
@@ -1129,13 +1129,14 @@ static int snd_intel8x0m_create(struct snd_card *card,
chip->bmaddr = pci_iomap(pci, 3, 0);
else
chip->bmaddr = pci_iomap(pci, 1, 0);
+
+port_inited:
if (!chip->bmaddr) {
dev_err(card->dev, "Controller space ioremap problem\n");
snd_intel8x0m_free(chip);
return -EIO;
}
- port_inited:
/* initialize offsets */
chip->bdbars_count = 2;
tbl = intel_regs;
--
2.17.1
[PATCH] arm64: dts: mt8183: Fix GCE include path
From: Matthias Brugger
The header file of GCE should be for MT8183 SoC instead of MT8173.
Fixes: 91f9c963ce79 ("arm64: dts: mt8183: Add display nodes for MT8183")
Reported-by: CK Hu
Signed-off-by: Matthias Brugger
---
arch/arm64/boot/dts/mediatek/mt8183.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
index 5b782a4769e7..80e466ce99f1 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
@@ -6,7 +6,7 @@
*/
#include
-#include
+#include
#include
#include
#include
--
2.30.0
Re: [PATCH v3 1/2] dt-bindings: power: Add MT8167 power domains
On 09/12/2020 14:32, Fabien Parent wrote: > Add power domains dt-bindings for MT8167. > > Signed-off-by: Fabien Parent > Acked-by: Rob Herring Both patches applied to v5.11-next/soc Thanks! > --- > This patch was made on top of > https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux.git/log/?h=v5.10-next/soc > > v3: > * Remove MT8167_POWER_DOMAIN_DISP since it was an alias for > MT8167_POWER_DOMAIN_MM > v2: > * Implement on top of new SCPSYS PM domains driver > > .../power/mediatek,power-controller.yaml| 2 ++ > include/dt-bindings/power/mt8167-power.h| 17 + > 2 files changed, 19 insertions(+) > create mode 100644 include/dt-bindings/power/mt8167-power.h > > diff --git > a/Documentation/devicetree/bindings/power/mediatek,power-controller.yaml > b/Documentation/devicetree/bindings/power/mediatek,power-controller.yaml > index fd12bafe3548..ad6db377f943 100644 > --- a/Documentation/devicetree/bindings/power/mediatek,power-controller.yaml > +++ b/Documentation/devicetree/bindings/power/mediatek,power-controller.yaml > @@ -23,6 +23,7 @@ properties: > >compatible: > enum: > + - mediatek,mt8167-power-controller >- mediatek,mt8173-power-controller >- mediatek,mt8183-power-controller >- mediatek,mt8192-power-controller > @@ -59,6 +60,7 @@ patternProperties: >reg: > description: | >Power domain index. Valid values are defined in: > + "include/dt-bindings/power/mt8167-power.h" - for MT8167 type > power domain. >"include/dt-bindings/power/mt8173-power.h" - for MT8173 type > power domain. >"include/dt-bindings/power/mt8183-power.h" - for MT8183 type > power domain. >"include/dt-bindings/power/mt8192-power.h" - for MT8192 type > power domain. > diff --git a/include/dt-bindings/power/mt8167-power.h > b/include/dt-bindings/power/mt8167-power.h > new file mode 100644 > index ..c8ec9983a4bc > --- /dev/null > +++ b/include/dt-bindings/power/mt8167-power.h > @@ -0,0 +1,17 @@ > +/* SPDX-License-Identifier: GPL-2.0 > + * > + * Copyright (c) 2020 MediaTek Inc. > + */ > + > +#ifndef _DT_BINDINGS_POWER_MT8167_POWER_H > +#define _DT_BINDINGS_POWER_MT8167_POWER_H > + > +#define MT8167_POWER_DOMAIN_MM 0 > +#define MT8167_POWER_DOMAIN_VDEC 1 > +#define MT8167_POWER_DOMAIN_ISP 2 > +#define MT8167_POWER_DOMAIN_CONN 3 > +#define MT8167_POWER_DOMAIN_MFG_ASYNC4 > +#define MT8167_POWER_DOMAIN_MFG_2D 5 > +#define MT8167_POWER_DOMAIN_MFG 6 > + > +#endif /* _DT_BINDINGS_POWER_MT8167_POWER_H */ >
Re: [PATCH v2] tpm_tis: Add missing tpm_request/relinquish_locality calls
Jarkko Sakkinen writes:
> On Thu, 2021-01-28 at 14:07 +0100, Lukasz Majczak wrote:
>> There is a missing call to tpm_request_locality before the call to
>> the tpm_get_timeouts() and tpm_tis_probe_irq_single(). As the current
>> approach might work for tpm2, it fails for tpm1.x - in that case
>> call to tpm_get_timeouts() or tpm_tis_probe_irq_single()
>> without locality fails and in turn causes tpm_tis_core_init() to fail.
>> Tested on Samsung Chromebook Pro (Caroline).
>>
>> Signed-off-by: Lukasz Majczak
>
> Is it possible that you test against linux-next and see if any
> problems still arise? I've applied the locality fixes from James.
I tested current linux-next and the warning still appears,
unfortunately.
I then incrementally applied further patches from James' series [1] and
after "[PATCH v2 4/5] tpm_tis: fix IRQ probing" the warning has gone:
# dmesg | grep tpm
[7.220410] tpm_tis STM0125:00: 2.0 TPM (device-id 0x0, rev-id 78)
[7.322564] Modules linked in: iwlmvm(+) btusb btrtl btbcm btintel mac80211
amdgpu(+) iwlwifi drm_ttm_helper tpm_crb sdhci_pci ttm cqhci gpu_sched sdhci
ccp cfg80211 rng_core tpm_tis tpm_tis_core tpm thinkpad_acpi(+) wmi nvram
pinctrl_amd
You might notice there is another warning but that is rtc related and I
still have to find out if that is something I should report.
Dirk
[1]
https://lore.kernel.org/linux-integrity/20201001180925.13808-1-james.bottom...@hansenpartnership.com/
>> ---
>> Jarkko, James, Guenter
>>
>> I’m aware about the other thread, but it seems to be dead for a few months.
>> Here is the small patch as fixing this specific issue
>> would allow us to unblock the ChromeOs development.
>> We want to upstream all of our patches,
>> so the ChromeOs will not diverge even more,
>> so I'm hoping this could be applied, if you see it neat enough.
>
> The usual approach is that you construct a series picking the pre-existing
> fixes and on top of that create your own, if any required.
>
>> Best regards,
>> Lukasz
>
> /Jarkko
>
>>
>> v1 -> v2:
>> - fixed typos
>> - as there is no need to enable clock, switched to
>> use only tpm_request/relinquish_locality calls
>> - narrowed down boundaries of tpm_request/relinquish_locality calls
>>
>> drivers/char/tpm/tpm-chip.c | 4 ++--
>> drivers/char/tpm/tpm-interface.c | 11 +--
>> drivers/char/tpm/tpm.h | 2 ++
>> drivers/char/tpm/tpm_tis_core.c | 12 ++--
>> 4 files changed, 23 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/char/tpm/tpm-chip.c b/drivers/char/tpm/tpm-chip.c
>> index ddaeceb7e109..5351963a4b19 100644
>> --- a/drivers/char/tpm/tpm-chip.c
>> +++ b/drivers/char/tpm/tpm-chip.c
>> @@ -32,7 +32,7 @@ struct class *tpm_class;
>> struct class *tpmrm_class;
>> dev_t tpm_devt;
>>
>> -static int tpm_request_locality(struct tpm_chip *chip)
>> +int tpm_request_locality(struct tpm_chip *chip)
>> {
>> int rc;
>>
>> @@ -47,7 +47,7 @@ static int tpm_request_locality(struct tpm_chip *chip)
>> return 0;
>> }
>>
>> -static void tpm_relinquish_locality(struct tpm_chip *chip)
>> +void tpm_relinquish_locality(struct tpm_chip *chip)
>> {
>> int rc;
>>
>> diff --git a/drivers/char/tpm/tpm-interface.c
>> b/drivers/char/tpm/tpm-interface.c
>> index 1621ce818705..69309b2bea6a 100644
>> --- a/drivers/char/tpm/tpm-interface.c
>> +++ b/drivers/char/tpm/tpm-interface.c
>> @@ -243,8 +243,15 @@ int tpm_get_timeouts(struct tpm_chip *chip)
>>
>> if (chip->flags & TPM_CHIP_FLAG_TPM2)
>> return tpm2_get_timeouts(chip);
>> - else
>> - return tpm1_get_timeouts(chip);
>> + else {
>> + ssize_t ret = tpm_request_locality(chip);
>> +
>> + if (ret)
>> + return ret;
>> + ret = tpm1_get_timeouts(chip);
>> + tpm_relinquish_locality(chip);
>> + return ret;
>> + }
>> }
>> EXPORT_SYMBOL_GPL(tpm_get_timeouts);
>>
>> diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h
>> index 947d1db0a5cc..8c13008437dd 100644
>> --- a/drivers/char/tpm/tpm.h
>> +++ b/drivers/char/tpm/tpm.h
>> @@ -193,6 +193,8 @@ static inline void tpm_msleep(unsigned int delay_msec)
>>
>> int tpm_chip_start(struct tpm_chip *chip);
>> void tpm_chip_stop(struct tpm_chip *chip);
>> +int tpm_request_locality(struct tpm_chip *chip);
>> +void tpm_relinquish_locality(struct tpm_chip *chip);
>> struct tpm_chip *tpm_find_get_ops(struct tpm_chip *chip);
>> __must_check int tpm_try_get_ops(struct tpm_chip *chip);
>> void tpm_put_ops(struct tpm_chip *chip);
>> diff --git a/drivers/char/tpm/tpm_tis_core.c
>> b/drivers/char/tpm/tpm_tis_core.c
>> index 92c51c6cfd1b..0ae675e8cf2f 100644
>> --- a/drivers/char/tpm/tpm_tis_core.c
>> +++ b/drivers/char/tpm/tpm_tis_core.c
>> @@ -754,9 +754,17 @@ static int tpm_tis_gen_interrupt(struct tpm_chip *chip)
>>
>> if (chip->flags & TPM_CHIP_FLAG_TPM2)
>> return tpm2_get
Re: [PATCH v3 2/2] arm64: dts: mediatek: mt8516: add support for APDMA
On 09/12/2020 12:47, Fabien Parent wrote:
> Add support the APDMA IP on MT8516. APDMA is a DMA controller
> for UARTs.
>
> Signed-off-by: Fabien Parent
> ---
>
Applied to v5.11-next/dts64
Thanks a lot!
> V3: remove unicode symbol that slips into patch summary
> V2: Add missing dma-names properties on uart nodes
>
> arch/arm64/boot/dts/mediatek/mt8516.dtsi | 30
> 1 file changed, 30 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/mediatek/mt8516.dtsi
> b/arch/arm64/boot/dts/mediatek/mt8516.dtsi
> index e6e4d9d60094..b80e95574bef 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8516.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8516.dtsi
> @@ -276,6 +276,27 @@ gic: interrupt-controller@1031 {
> (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
> };
>
> + apdma: dma-controller@11000480 {
> + compatible = "mediatek,mt8516-uart-dma",
> + "mediatek,mt6577-uart-dma";
> + reg = <0 0x11000480 0 0x80>,
> + <0 0x11000500 0 0x80>,
> + <0 0x11000580 0 0x80>,
> + <0 0x11000600 0 0x80>,
> + <0 0x11000980 0 0x80>,
> + <0 0x11000a00 0 0x80>;
> + interrupts = ,
> + ,
> + ,
> + ,
> + ,
> + ;
> + dma-requests = <6>;
> + clocks = <&topckgen CLK_TOP_APDMA>;
> + clock-names = "apdma";
> + #dma-cells = <1>;
> + };
> +
> uart0: serial@11005000 {
> compatible = "mediatek,mt8516-uart",
>"mediatek,mt6577-uart";
> @@ -284,6 +305,9 @@ uart0: serial@11005000 {
> clocks = <&topckgen CLK_TOP_UART0_SEL>,
><&topckgen CLK_TOP_UART0>;
> clock-names = "baud", "bus";
> + dmas = <&apdma 0
> + &apdma 1>;
> + dma-names = "tx", "rx";
> status = "disabled";
> };
>
> @@ -295,6 +319,9 @@ uart1: serial@11006000 {
> clocks = <&topckgen CLK_TOP_UART1_SEL>,
><&topckgen CLK_TOP_UART1>;
> clock-names = "baud", "bus";
> + dmas = <&apdma 2
> + &apdma 3>;
> + dma-names = "tx", "rx";
> status = "disabled";
> };
>
> @@ -306,6 +333,9 @@ uart2: serial@11007000 {
> clocks = <&topckgen CLK_TOP_UART2_SEL>,
><&topckgen CLK_TOP_UART2>;
> clock-names = "baud", "bus";
> + dmas = <&apdma 4
> + &apdma 5>;
> + dma-names = "tx", "rx";
> status = "disabled";
> };
>
>
Re: Process-wide watchpoints
On Sun, Jan 31, 2021 at 11:04 AM Dmitry Vyukov wrote:
>
> On Thu, Nov 12, 2020 at 11:43 AM Dmitry Vyukov wrote:
> > > > for sampling race detection),
> > > > number of threads in the process can be up to, say, ~~10K and the
> > > > watchpoint is intended to be set for a very brief period of time
> > > > (~~few ms).
> > >
> > > Performance is a consideration here, doing lots of IPIs in such a short
> > > window, on potentially large machines is a DoS risk.
> > >
> > > > This can be done today with both perf_event_open and ptrace.
> > > > However, the problem is that both APIs work on a single thread level
> > > > (? perf_event_open can be inherited by children, but not for existing
> > > > siblings). So doing this would require iterating over, say, 10K
> > >
> > > One way would be to create the event before the process starts spawning
> > > threads and keeping it disabled. Then every thread will inherit it, but
> > > it'll be inactive.
> > >
> > > > I see at least one potential problem: what do we do if some sibling
> > > > thread already has all 4 watchpoints consumed?
> > >
> > > That would be immediately avoided by this, since it will have the
> > > watchpoint reserved per inheriting the event.
> > >
> > > Then you can do ioctl(PERF_EVENT_IOC_{MODIFY_ATTRIBUTES,ENABLE,DISABLE})
> > > to update the watch location and enable/disable it. This _will_ indeed
> > > result in a shitload of IPIs if the threads are active, but it should
> > > work.
> >
> > Aha! That's the possibility I missed.
> > We will try to prototype this and get back with more questions if/when
> > we have them.
> > Thanks!
>
> Hi Peter,
>
> I've tested this approach and it works, but only in half.
> PERF_EVENT_IOC_{ENABLE,DISABLE} work as advertised.
> However, PERF_EVENT_IOC_MODIFY_ATTRIBUTES does not work for inherited
> child events.
> Does something like this make any sense to you? Are you willing to
> accept such change?
>
> diff --git a/kernel/events/core.c b/kernel/events/core.c
> index 55d18791a72d..f6974807a32c 100644
> --- a/kernel/events/core.c
> +++ b/kernel/events/core.c
> @@ -3174,7 +3174,7 @@ int perf_event_refresh(struct perf_event *event,
> int refresh)
> }
> EXPORT_SYMBOL_GPL(perf_event_refresh);
>
> -static int perf_event_modify_breakpoint(struct perf_event *bp,
> +static int _perf_event_modify_breakpoint(struct perf_event *bp,
> struct perf_event_attr *attr)
> {
> int err;
> @@ -3189,6 +3189,28 @@ static int perf_event_modify_breakpoint(struct
> perf_event *bp,
> return err;
> }
>
> +static int perf_event_modify_breakpoint(struct perf_event *bp,
> + struct perf_event_attr *attr)
> +{
> + struct perf_event *child;
> + int err;
> +
> + WARN_ON_ONCE(bp->ctx->parent_ctx);
> +
> + mutex_lock(&bp->child_mutex);
> + err = _perf_event_modify_breakpoint(bp, attr);
> + if (err)
> + goto unlock;
> + list_for_each_entry(child, &bp->child_list, child_list) {
> + err = _perf_event_modify_breakpoint(child, attr);
> + if (err)
> + goto unlock;
> + }
> +unlock:
> + mutex_unlock(&bp->child_mutex);
> + return err;
> +}
> +
> static int perf_event_modify_attr(struct perf_event *event,
> struct perf_event_attr *attr)
Not directly related to the above question, but related to my use case.
Could we extend bpf_perf_event_data with some more data re breakpoint events?
struct bpf_perf_event_data {
bpf_user_pt_regs_t regs;
__u64 sample_period;
__u64 addr;
};
Ideally, I would like to have an actual access address, size and
read/write type (may not match bp addr/size). Is that info easily
available at the point of bpf hook call?
Or, if that's not available at least breakpoint bp_type/bp_size.
Is it correct that we can materialize in bpf_perf_event_data anything
that's available in bpf_perf_event_data_kern (if it makes sense in the
public interface of course)?
struct bpf_perf_event_data_kern {
bpf_user_pt_regs_t *regs;
struct perf_sample_data *data;
struct perf_event *event;
};
Unfortunately I don't see perf_event_attr.bp_type/bp_size
stored/accessible anywhere in bpf_perf_event_data_kern. What would be
the right way to expose them in bpf_perf_event_data?
Thanks
Re: [PATCH v2] iio: adc: stm32-adc: enable timestamping for non-DMA usage
On Mon, 25 Jan 2021 12:21:35 +0100
Ahmad Fatoum wrote:
> Hello Jonathan,
>
> On 24.01.21 16:22, Jonathan Cameron wrote:
> > On Fri, 22 Jan 2021 12:33:55 +0100
> > Ahmad Fatoum wrote:
> >
> >> For non-DMA usage, we have an easy way to associate a timestamp with a
> >> sample: iio_pollfunc_store_time stores a timestamp in the primary
> >> trigger IRQ handler and stm32_adc_trigger_handler runs in the IRQ thread
> >> to push out the buffer along with the timestamp.
> >>
> >> For this to work, the driver needs to register an IIO_TIMESTAMP channel.
> >> Do this.
> >>
> >> For DMA, it's not as easy, because we don't push the buffers out of
> >> stm32_adc_trigger, but out of stm32_adc_dma_buffer_done, which runs in
> >> a tasklet scheduled after a DMA completion.
> >>
> >> Preferably, the DMA controller would copy us the timestamp into that buffer
> >> as well. Until this is implemented, restrict timestamping support to
> >> only PIO. For low-frequency sampling, PIO is probably good enough.
> >>
> >> Cc: Holger Assmann
> >> Acked-by: Fabrice Gasnier
> >> Signed-off-by: Ahmad Fatoum
> >
> > This patch itself is fine, but it will expose a potential bug.
> >
> > The buffer passed to iio_push_to_buffers_with_timestamp needs to be suitably
> > aligned to take an 8 byte timestamp and large enough to do so.
> > Currently, in this driver it isn't.
> > u16 buffer[STM32_ADC_MAX_SQ];
> > Appears to be the same length as the channel count, and isn't 8 byte
> > aligned. (add __aligned(8) to fix that)
> >
> > Could you add that fix to this patch as well?
>
> Just done so, thanks. But I think it's very surprising API to expect a void *
> to have a specific alignment. Should this perhaps be encoded into
> the function signature? e.g.
>
> typedef void __aligned_u64_void __aligned(8);
> static inline int iio_push_to_buffers_with_timestamp(struct iio_dev
> *indio_dev,
> __aligned_u64_void *data, int64_t timestamp);
>
Hmm. Didn't realise you could put __aligned() on a parameter. May well make
sense
but we can't do it yet. There are a few left over drivers that don't yet
guarantee the alignment. On some architectures that's fine. Once we've
done a final pass and fixed those up, we can tidy this up.
Note that we had this problem for a good 5-10 years before one report of
actually
running into a problem.
> [I assume put_unaligned_* isn't used for performance reasons?)
No, it's actually about expectations of where that buffer might go. There
are lots of potential consumers and many of them can assume a fixed
structure and hence assume alignment.
I agree, it's a very odd ABI requirement :(
Would probably have done things differently if we'd registered the built in
alignment issue earlier.
Jonathan
>
> Cheers,
> Ahmad
>
> >
> > Thanks,
> >
> > Jonathan
> >
> >
> >> ---
> >> v1 -> v2:
> >> - Added comment about timestamping being PIO only (Fabrice)
> >> - Added missing DMA resource clean up in error path (Fabrice)
> >> - Added Fabrice's Acked-by
> >> ---
> >> drivers/iio/adc/stm32-adc.c | 35 +--
> >> 1 file changed, 29 insertions(+), 6 deletions(-)
> >>
> >> diff --git a/drivers/iio/adc/stm32-adc.c b/drivers/iio/adc/stm32-adc.c
> >> index c067c994dae2..885bb514503c 100644
> >> --- a/drivers/iio/adc/stm32-adc.c
> >> +++ b/drivers/iio/adc/stm32-adc.c
> >> @@ -1718,7 +1718,7 @@ static void stm32_adc_chan_init_one(struct iio_dev
> >> *indio_dev,
> >>}
> >> }
> >>
> >> -static int stm32_adc_chan_of_init(struct iio_dev *indio_dev)
> >> +static int stm32_adc_chan_of_init(struct iio_dev *indio_dev, bool
> >> timestamping)
> >> {
> >>struct device_node *node = indio_dev->dev.of_node;
> >>struct stm32_adc *adc = iio_priv(indio_dev);
> >> @@ -1766,6 +1766,9 @@ static int stm32_adc_chan_of_init(struct iio_dev
> >> *indio_dev)
> >>return -EINVAL;
> >>}
> >>
> >> + if (timestamping)
> >> + num_channels++;
> >> +
> >>channels = devm_kcalloc(&indio_dev->dev, num_channels,
> >>sizeof(struct iio_chan_spec), GFP_KERNEL);
> >>if (!channels)
> >> @@ -1816,6 +1819,19 @@ static int stm32_adc_chan_of_init(struct iio_dev
> >> *indio_dev)
> >>stm32_adc_smpr_init(adc, channels[i].channel, smp);
> >>}
> >>
> >> + if (timestamping) {
> >> + struct iio_chan_spec *timestamp = &channels[scan_index];
> >> +
> >> + timestamp->type = IIO_TIMESTAMP;
> >> + timestamp->channel = -1;
> >> + timestamp->scan_index = scan_index;
> >> + timestamp->scan_type.sign = 's';
> >> + timestamp->scan_type.realbits = 64;
> >> + timestamp->scan_type.storagebits = 64;
> >> +
> >> + scan_index++;
> >> + }
> >> +
> >>indio_dev->num_channels = scan_index;
> >>indio_dev->channels = channels;
> >>
> >> @@ -1875,6 +1891,7 @@ static int stm32_adc_probe(struct platform_device
> >> *pdev)
> >>struct
Re: [PATCH v2 resend] iio: imu: bmi160: add mutex_lock for avoiding race
On Mon, 25 Jan 2021 09:53:44 +0800
Guoqing Chi wrote:
> From: chiguoqing
>
> Adding mutex_lock, when read and write reg need to use this lock to
> avoid race.
>
> Signed-off-by: Guoqing Chi
> Reviewed-by: Tom Rix
Hi. Looking at this again, I'm not entirely sure I understand what the
race is. Could you give any example?
Individual regmap accesses have their own internal protections
against races. We don't have an read modify write cycles that
I can see here, so I don't think there are any races.
On another note however, there is a regmap_bulk_read into
a variable on the stack which is a problem for spi. Unlike i2c
the spi patch in regmap for bulk_reads can be zero copy which
means that the variable on the stack can be dma'd into. That's
a potential issue for some systems in which you can end up wiping
out whatever else gets changed in the same cacheline.
To fix that, the variable should be in it's own cacheline. Either
do that by using kmalloc etc to put it on the stack, or add a
suitable buffer to priv, marked ___cacheline_aligned. Though once
you do that you will need locks to protect it as you've done
here.
Jonathan
> ---
> v2:Follow write function to fix read function.
> Adding mutex init in core probe function.
> Adding break in switch case at read and write function.
>
> drivers/iio/imu/bmi160/bmi160.h | 2 ++
> drivers/iio/imu/bmi160/bmi160_core.c | 34 +++-
> 2 files changed, 25 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/iio/imu/bmi160/bmi160.h b/drivers/iio/imu/bmi160/bmi160.h
> index 32c2ea2d7112..0c189a8b5b53 100644
> --- a/drivers/iio/imu/bmi160/bmi160.h
> +++ b/drivers/iio/imu/bmi160/bmi160.h
> @@ -3,9 +3,11 @@
> #define BMI160_H_
>
> #include
> +#include
> #include
>
> struct bmi160_data {
> + struct mutex lock;
> struct regmap *regmap;
> struct iio_trigger *trig;
> struct regulator_bulk_data supplies[2];
> diff --git a/drivers/iio/imu/bmi160/bmi160_core.c
> b/drivers/iio/imu/bmi160/bmi160_core.c
> index 290b5ef83f77..e303378f4841 100644
> --- a/drivers/iio/imu/bmi160/bmi160_core.c
> +++ b/drivers/iio/imu/bmi160/bmi160_core.c
> @@ -452,26 +452,32 @@ static int bmi160_read_raw(struct iio_dev *indio_dev,
> int ret;
> struct bmi160_data *data = iio_priv(indio_dev);
>
> + mutex_lock(&data->lock);
> switch (mask) {
> case IIO_CHAN_INFO_RAW:
> ret = bmi160_get_data(data, chan->type, chan->channel2, val);
> - if (ret)
> - return ret;
> - return IIO_VAL_INT;
> + if (!ret)
> + ret = IIO_VAL_INT;
> + break;
> case IIO_CHAN_INFO_SCALE:
> *val = 0;
> ret = bmi160_get_scale(data,
> bmi160_to_sensor(chan->type), val2);
> - return ret ? ret : IIO_VAL_INT_PLUS_MICRO;
> + if (!ret)
> + ret = IIO_VAL_INT_PLUS_MICRO;
> + break;
> case IIO_CHAN_INFO_SAMP_FREQ:
> ret = bmi160_get_odr(data, bmi160_to_sensor(chan->type),
>val, val2);
> - return ret ? ret : IIO_VAL_INT_PLUS_MICRO;
> + if (!ret)
> + ret = IIO_VAL_INT_PLUS_MICRO;
> + break;
> default:
> - return -EINVAL;
> + ret = -EINVAL;
> }
> + mutex_unlock(&data->lock);
>
> - return 0;
> + return ret;
> }
>
> static int bmi160_write_raw(struct iio_dev *indio_dev,
> @@ -479,19 +485,24 @@ static int bmi160_write_raw(struct iio_dev *indio_dev,
> int val, int val2, long mask)
> {
> struct bmi160_data *data = iio_priv(indio_dev);
> + int result;
>
> + mutex_lock(&data->lock);
> switch (mask) {
> case IIO_CHAN_INFO_SCALE:
> - return bmi160_set_scale(data,
> + result = bmi160_set_scale(data,
> bmi160_to_sensor(chan->type), val2);
> + break;
> case IIO_CHAN_INFO_SAMP_FREQ:
> - return bmi160_set_odr(data, bmi160_to_sensor(chan->type),
> + result = bmi160_set_odr(data, bmi160_to_sensor(chan->type),
> val, val2);
> + break;
> default:
> - return -EINVAL;
> + result = -EINVAL;
> }
> + mutex_unlock(&data->lock);
>
> - return 0;
> + return result;
> }
>
> static
> @@ -838,6 +849,7 @@ int bmi160_core_probe(struct device *dev, struct regmap
> *regmap,
> return -ENOMEM;
>
> data = iio_priv(indio_dev);
> + mutex_init(&data->lock);
> dev_set_drvdata(dev, indio_dev);
> data->regmap = regmap;
>
Re: [Linux-stm32] [PATCH] iio: adc: stm32-adc: fix erroneous handling of spurious IRQs
On Tue, 26 Jan 2021 16:52:37 +0100
Fabrice Gasnier wrote:
> On 1/22/21 1:18 PM, Ahmad Fatoum wrote:
> > Hello Fabrice,
> >
> > On 19.01.21 18:56, Fabrice Gasnier wrote:
> >> On 1/18/21 12:42 PM, Ahmad Fatoum wrote:
> >>> Hello Jonathan,
> >>>
> >>> On 16.01.21 18:53, Jonathan Cameron wrote:
> On Tue, 12 Jan 2021 16:24:42 +0100
> Ahmad Fatoum wrote:
>
> > 1c6c69525b40 ("genirq: Reject bogus threaded irq requests") makes sure
> > that threaded IRQs either
> > - have IRQF_ONESHOT set
> > - don't have the default just return IRQ_WAKE_THREAD primary handler
> >
> > This is necessary because level-triggered interrupts need to be masked,
> > either at device or irqchip, to avoid an interrupt storm.
> >
> > For spurious interrupts, the STM32 ADC driver still does this bogus
> > request though:
> > - It doesn't set IRQF_ONESHOT
> > - Its primary handler just returns IRQ_WAKE_THREAD if the interrupt
> > is unexpected, i.e. !(status & enabled_mask)
> This seems 'unusual'. If this is a spurious interrupt we should be
> returning IRQ_NONE and letting the spurious interrupt protection
> stuff kick in.
>
> The only reason I can see that it does this is print an error message.
> I'm not sure why we need to go into the thread to do that given
> it's not supposed to happen. If we need that message at all, I'd
> suggest doing it in the interrupt handler then return IRQ_NONE;
> >>> As described, I run into the spurious IRQ case, so I think the message is
> >>> still useful (until that's properly fixed), but yes, it should've returned
> >>> IRQ_NONE in that case.
> >>>
> >>> With these changes, IRQF_ONESHOT shouldn't be necessary, but in practice
> >>> the driver doesn't function correctly with the primary IRQ handler
> >>> threaded.
> >>>
> >>> Olivier, Fabrice: Are you aware of this problem?
> >>
> >>
> >> Hi Ahmad, Jonathan,
> >>
> >> I wasn't aware of this up to now. I confirm we've the same behavior at
> >> our end with threadirqs=1.
> >>
> >> Olivier and I started to look at this. Indeed, the IRQF_ONESHOT makes
> >> the issue to disappear.
> >> I'm not sure 100% that's for the above reasons. Please let me share some
> >> piece of logs, analysis and thoughts.
> >
> > Thanks for looking at this.
> >
> >> I may miss it but, the patch "genirq: Reject bogus threaded irq
> >> requests" seems to handle the case where no HW handler is provided, but
> >> only the threaded part?
> >
> > There is still a primary handler, but that one does only do IRQ_WAKE_THREAD,
> > so I assumed that would be equivalent to what the driver is doing in the
> > spurious IRQ case.
> >
> >> In the stm32-adc both are provided. Also the IRQ domain in
> >> stm32-adc-core maybe a key here ?
> >
> > Oh, missed completely that the stm32-adc-core does the interrupt routing.
>
> Hi Ahmad, Jonathan,
>
> The interrupt routing is done in the core by using "dummy_irq_chip".
>
> Currently (with threadirqs=1), irq_mask and irq_unmask callbacks are
> called, but this makes a "noop":
> struct irq_chip dummy_irq_chip = {
> ...
> .irq_mask= noop,
> .irq_unmask= noop,
> ...
>
> That's the reason for the hw irq storm until the primary threaded
> handler can run.
>
> I see no easy way to mask the irq from the core driver. e.g. enable bits
> are in "child" registers.
> The child adc driver already clear/set them at will (in IER: EOC/OVR bits).
>
> Please find other considerations here after
>
> >
> >> We did some testing, ftrace and observed following behavior for one
> >> capture (a single cat in_voltage..._raw) :
> >>
> >> in stm32-adc-core, as IRQ source is still active until the IRQ thread
> >> can execute:
> >> - stm32_adc_irq_handler <-- generic_handle_irq
> >> - stm32_adc_irq_handler <-- generic_handle_irq
> >> - stm32_adc_irq_handler <-- generic_handle_irq
> >> ...
> >>
> >> - sched_switch to the 1st IRQ thread
> >> - stm32_adc_irq_handler <-- generic_handle_irq (again until DR get read)
> >>
> >> - stm32_adc_isr <-- irq_forced_thread_fn (from stm32-adc)
> >> DR read, clears the active flag
> >> - stm32_adc_isr <-- irq_forced_thread_fn
> >> wakes the 2nd IRQ thread to print an error (unexpected...)
> >>
> >> sched_switch to the 2nd IRQ thread that prints the message.
> >>
> >> - stm32_adc_threaded_isr <-- irq_thread_fn
> >>
> >>
> >> So my understanding is: the cause seems to be the concurrency between
> >>
> >> - stm32_adc_irq_handler() storm calls in stm32-adc-core
> >> - stm32_adc_isr() call to clear the cause (forced into a thread with
> >> threadirqs=1).
> >
> > I can't follow here. Where does stm32_adc_isr() clear the IRQ cause?
>
> The 'eoc' end of conversion flag is cleared by reading data register.
>
> > I assumed it can't be isr_ovr.mask, because that's checked in the
> > primary handler.
> >
> >> To properly work, the stm32_adc_irq_handler() should be masked in b
Re: [PATCH 3/3] iio: proximity: Add a ChromeOS EC MKBP proximity driver
... > > > + > > > +#ifdef CONFIG_OF > > > > As a general rule, we are trying to clear out protections on CONFIG_OF etc > > and use of of_match_ptr() on the basis they don't really gain us anything > > and prevent use of some other firmware types. Here I guess you know what > > your firmware looks like, but I'm still keen to drop it in the interests > > of there being fewer places to copy it from. > > > > It may be a good idea to give this a more specific name as well given > > we already have cros-ec-prox as a platform device id from > > the cros_ec_light_prox driver. > > Alright. I renamed it to cros_ec_mkbp_proximity throughout this driver. > I'm concerned about dropping CONFIG_OF because of_match_ptr() and > CONFIG_OF=n makes it unused but I suppose that will be OK as long as > compilation passes. It's a trivial overhead + note that it can be used by certain ACPI tables. Lookup the delights of PRP0001 which lets ACPI use device-tree descriptions. It may well be that no one uses that for this driver, but it's nice not to exclude it and that works with CONFIG_OF=n. Jonathan
[PATCH v6 net-next 17/18] net: mvpp2: limit minimum ring size to 1024 descriptors
From: Stefan Chulski To support Flow Control ring size should be at least 1024 descriptors. Signed-off-by: Stefan Chulski --- drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c index 7632810..98849b0 100644 --- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c +++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c @@ -4543,6 +4543,8 @@ static int mvpp2_check_ringparam_valid(struct net_device *dev, if (ring->rx_pending > MVPP2_MAX_RXD_MAX) new_rx_pending = MVPP2_MAX_RXD_MAX; + else if (ring->rx_pending < MSS_THRESHOLD_START) + new_rx_pending = MSS_THRESHOLD_START; else if (!IS_ALIGNED(ring->rx_pending, 16)) new_rx_pending = ALIGN(ring->rx_pending, 16); -- 1.9.1
[PATCH v6 net-next 02/18] dts: marvell: add CM3 SRAM memory to cp115 ethernet device tree
From: Konstantin Porotchkin
CM3 SRAM address space would be used for Flow Control configuration.
Signed-off-by: Stefan Chulski
Signed-off-by: Konstantin Porotchkin
---
arch/arm64/boot/dts/marvell/armada-cp11x.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm64/boot/dts/marvell/armada-cp11x.dtsi
b/arch/arm64/boot/dts/marvell/armada-cp11x.dtsi
index 9dcf16b..359cf42 100644
--- a/arch/arm64/boot/dts/marvell/armada-cp11x.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-cp11x.dtsi
@@ -69,6 +69,8 @@
status = "disabled";
dma-coherent;
+ cm3-mem = <&CP11X_LABEL(cm3_sram)>;
+
CP11X_LABEL(eth0): eth0 {
interrupts = <39 IRQ_TYPE_LEVEL_HIGH>,
<43 IRQ_TYPE_LEVEL_HIGH>,
@@ -211,6 +213,14 @@
};
};
+ CP11X_LABEL(cm3_sram): cm3@22 {
+ compatible = "mmio-sram";
+ reg = <0x22 0x800>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 0x22 0x800>;
+ };
+
CP11X_LABEL(rtc): rtc@284000 {
compatible = "marvell,armada-8k-rtc";
reg = <0x284000 0x20>, <0x284080 0x24>;
--
1.9.1
Re: [PATCH v1] arm64: dts: mt8192: add nor_flash device node
On 10/12/2020 09:34, Bayi Cheng wrote:
> From: bayi cheng
>
> add nor_flash device node
>
> Signed-off-by: bayi cheng
> ---
> arch/arm64/boot/dts/mediatek/mt8192.dtsi | 13 +
> 1 file changed, 13 insertions(+)
>
Applied to v5.11-next/dts64
Thanks
> diff --git a/arch/arm64/boot/dts/mediatek/mt8192.dtsi
> b/arch/arm64/boot/dts/mediatek/mt8192.dtsi
> index e12e024..b15b0d3 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8192.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8192.dtsi
> @@ -379,6 +379,19 @@
> status = "disabled";
> };
>
> + nor_flash: spi@11234000 {
> + compatible = "mediatek,mt8173-nor";
> + reg = <0 0x11234000 0 0xe0>;
> + interrupts = ;
> + clocks = <&clk26m>,
> + <&clk26m>,
> + <&clk26m>;
> + clock-names = "spi", "sf", "axi";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "disable";
> + };
> +
> i2c3: i2c3@11cb {
> compatible = "mediatek,mt8192-i2c";
> reg = <0 0x11cb 0 0x1000>,
>
Re: [PATCH 1/1] iommu/vt-d: Add qi_submit trace event
Lu Baolu writes:
> This adds a new trace event to track the submissions of requests to the
> invalidation queue. This event will provide the information like:
> - IOMMU name
> - Invalidation type
> - Descriptor raw data
>
> A sample output like:
> | qi_submit: iotlb_inv dmar1: 0x100e2 0x0 0x0 0x0
> | qi_submit: dev_tlb_inv dmar1: 0x13 0x7001 0x0 0x0
> | qi_submit: iotlb_inv dmar2: 0x800f2 0xf9a5 0x0 0x0
>
> This will be helpful for queued invalidation related debugging.
>
> Signed-off-by: Lu Baolu
While compiling current linux-next for some other test I noticed a
compiler error because of this patch:
drivers/iommu/intel/dmar.c: In function ‘qi_submit_sync’:
drivers/iommu/intel/dmar.c:1311:3: error: implicit declaration of function
‘trace_qi_submit’ [-Werror=implicit-function-declaration]
1311 | trace_qi_submit(iommu, desc[i].qw0, desc[i].qw1,
| ^~~
cc1: some warnings being treated as errors
On my machine CONFIG_INTEL_IOMMU is not set so
#include cannot provide the prototype for
that function.
Dirk
> ---
> drivers/iommu/intel/dmar.c | 3 +++
> include/trace/events/intel_iommu.h | 37 ++
> 2 files changed, 40 insertions(+)
>
> diff --git a/drivers/iommu/intel/dmar.c b/drivers/iommu/intel/dmar.c
> index 004feaed3c72..bd51f33642e0 100644
> --- a/drivers/iommu/intel/dmar.c
> +++ b/drivers/iommu/intel/dmar.c
> @@ -31,6 +31,7 @@
> #include
> #include
> #include
> +#include
>
> #include "../irq_remapping.h"
>
> @@ -1307,6 +1308,8 @@ int qi_submit_sync(struct intel_iommu *iommu, struct
> qi_desc *desc,
> offset = ((index + i) % QI_LENGTH) << shift;
> memcpy(qi->desc + offset, &desc[i], 1 << shift);
> qi->desc_status[(index + i) % QI_LENGTH] = QI_IN_USE;
> + trace_qi_submit(iommu, desc[i].qw0, desc[i].qw1,
> + desc[i].qw2, desc[i].qw3);
> }
> qi->desc_status[wait_index] = QI_IN_USE;
>
> diff --git a/include/trace/events/intel_iommu.h
> b/include/trace/events/intel_iommu.h
> index 112bd06487bf..aad2ff0c1e2e 100644
> --- a/include/trace/events/intel_iommu.h
> +++ b/include/trace/events/intel_iommu.h
> @@ -135,6 +135,43 @@ DEFINE_EVENT(dma_map_sg, bounce_map_sg,
>struct scatterlist *sg),
> TP_ARGS(dev, index, total, sg)
> );
> +
> +TRACE_EVENT(qi_submit,
> + TP_PROTO(struct intel_iommu *iommu, u64 qw0, u64 qw1, u64 qw2, u64 qw3),
> +
> + TP_ARGS(iommu, qw0, qw1, qw2, qw3),
> +
> + TP_STRUCT__entry(
> + __field(u64, qw0)
> + __field(u64, qw1)
> + __field(u64, qw2)
> + __field(u64, qw3)
> + __string(iommu, iommu->name)
> + ),
> +
> + TP_fast_assign(
> + __assign_str(iommu, iommu->name);
> + __entry->qw0 = qw0;
> + __entry->qw1 = qw1;
> + __entry->qw2 = qw2;
> + __entry->qw3 = qw3;
> + ),
> +
> + TP_printk("%s %s: 0x%llx 0x%llx 0x%llx 0x%llx",
> + __print_symbolic(__entry->qw0 & 0xf,
> +{ QI_CC_TYPE,"cc_inv" },
> +{ QI_IOTLB_TYPE, "iotlb_inv" },
> +{ QI_DIOTLB_TYPE,"dev_tlb_inv" },
> +{ QI_IEC_TYPE, "iec_inv" },
> +{ QI_IWD_TYPE, "inv_wait" },
> +{ QI_EIOTLB_TYPE,"p_iotlb_inv" },
> +{ QI_PC_TYPE,"pc_inv" },
> +{ QI_DEIOTLB_TYPE, "p_dev_tlb_inv" },
> +{ QI_PGRP_RESP_TYPE, "page_grp_resp" }),
> + __get_str(iommu),
> + __entry->qw0, __entry->qw1, __entry->qw2, __entry->qw3
> + )
> +);
> #endif /* _TRACE_INTEL_IOMMU_H */
>
> /* This part must be outside protection */
RE: [EXT] Re: [PATCH v5 net-next 00/18] net: mvpp2: Add TX Flow Control support
> > Hi Stefan, looks like patchwork and lore didn't get all the emails: > > https://urldefense.proofpoint.com/v2/url?u=https- > 3A__lore.kernel.org_r_1611858682-2D9845-2D1-2Dgit-2Dsend-2Demail- > 2Dstefanc- > 40marvell.com&d=DwICAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=DDQ3dKwkTIx > KAl6_Bs7GMx4zhJArrXKN2mDMOXGh7lg&m=AFp2yfjV7t2l3c7dCM9lllj7Mz1V > - > 57354rTjjMB9_o&s=TK5AoswsdBLZNKNMI_rMiQQFtoLZf9UqEGQ40u7OHGI& > e= > https://urldefense.proofpoint.com/v2/url?u=https- > 3A__patchwork.kernel.org_project_netdevbpf_list_-3Fseries- > 3D423983&d=DwICAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=DDQ3dKwkTIxKAl6_ > Bs7GMx4zhJArrXKN2mDMOXGh7lg&m=AFp2yfjV7t2l3c7dCM9lllj7Mz1V- > 57354rTjjMB9_o&s=BC2VcCRP0O0r4wywUHOgkqvleArWUsCGaT3Ue1- > O6VE&e= > > Unless it fixes itself soon - please repost. Reposted. Best Regards, Stefan.
[PATCH v6 net-next 00/18] net: mvpp2: Add TX Flow Control support
From: Stefan Chulski Armada hardware has a pause generation mechanism in GOP (MAC). The GOP generate flow control frames based on an indication programmed in Ports Control 0 Register. There is a bit per port. However assertion of the PortX Pause bits in the ports control 0 register only sends a one time pause. To complement the function the GOP has a mechanism to periodically send pause control messages based on periodic counters. This mechanism ensures that the pause is effective as long as the Appropriate PortX Pause is asserted. Problem is that Packet Processor that actually can drop packets due to lack of resources not connected to the GOP flow control generation mechanism. To solve this issue Armada has firmware running on CM3 CPU dedicated for Flow Control support. Firmware monitors Packet Processor resources and asserts XON/XOFF by writing to Ports Control 0 Register. MSS shared SRAM memory used to communicate between CM3 firmware and PP2 driver. During init PP2 driver informs firmware about used BM pools, RXQs, congestion and depletion thresholds. The pause frames are generated whenever congestion or depletion in resources is detected. The back pressure is stopped when the resource reaches a sufficient level. So the congestion/depletion and sufficient level implement a hysteresis that reduces the XON/XOFF toggle frequency. Packet Processor v23 hardware introduces support for RX FIFO fill level monitor. Patch "add PPv23 version definition" to differ between v23 and v22 hardware. Patch "add TX FC firmware check" verifies that CM3 firmware supports Flow Control monitoring. v5 --> v6 - No change v4 --> v5 - Add missed Signed-off - Fix warnings in patches 3 and 12 - Add revision requirement to warning message - Move mss_spinlock into RXQ flow control configurations patch - Improve FCA RXQ non occupied descriptor threshold commit message v3 --> v4 - Remove RFC tag v2 --> v3 - Remove inline functions - Add PPv2.3 description into marvell-pp2.txt - Improve mvpp2_interrupts_mask/unmask procedure - Improve FC enable/disable procedure - Add priv->sram_pool check - Remove gen_pool_destroy call - Reduce Flow Control timer to x100 faster v1 --> v2 - Add memory requirements information - Add EPROBE_DEFER if of_gen_pool_get return NULL - Move Flow control configuration to mvpp2_mac_link_up callback - Add firmware version info with Flow control support Konstantin Porotchkin (1): dts: marvell: add CM3 SRAM memory to cp115 ethernet device tree Stefan Chulski (17): doc: marvell: add cm3-mem device tree bindings description net: mvpp2: add CM3 SRAM memory map doc: marvell: add PPv2.3 description to marvell-pp2.txt net: mvpp2: add PPv23 version definition net: mvpp2: always compare hw-version vs MVPP21 net: mvpp2: increase BM pool size to 2048 buffers net: mvpp2: increase RXQ size to 1024 descriptors net: mvpp2: add FCA periodic timer configurations net: mvpp2: add FCA RXQ non occupied descriptor threshold net: mvpp2: enable global flow control net: mvpp2: add RXQ flow control configurations net: mvpp2: add ethtool flow control configuration support net: mvpp2: add BM protection underrun feature support net: mvpp2: add PPv23 RX FIFO flow control net: mvpp2: set 802.3x GoP Flow Control mode net: mvpp2: limit minimum ring size to 1024 descriptors net: mvpp2: add TX FC firmware check Documentation/devicetree/bindings/net/marvell-pp2.txt | 4 +- arch/arm64/boot/dts/marvell/armada-cp11x.dtsi | 10 + drivers/net/ethernet/marvell/mvpp2/mvpp2.h| 128 - drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 563 ++-- 4 files changed, 655 insertions(+), 50 deletions(-) -- 1.9.1
[PULL REQUEST] i2c for 5.11
Linus, one I2C driver update this time. Please pull. Thanks, Wolfram The following changes since commit 6ee1d745b7c9fd573fba142a2efdad76a9f1cb04: Linux 5.11-rc5 (2021-01-24 16:47:14 -0800) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git i2c/for-current for you to fetch changes up to de96c3943f591018727b862f51953c1b6c55bcc3: i2c: mediatek: Move suspend and resume handling to NOIRQ phase (2021-01-28 10:54:45 +0100) Qii Wang (1): i2c: mediatek: Move suspend and resume handling to NOIRQ phase drivers/i2c/busses/i2c-mt65xx.c | 19 --- 1 file changed, 16 insertions(+), 3 deletions(-) signature.asc Description: PGP signature
[GIT PULL] x86/entry for v5.11-rc6
Hi Linus, please pull x86/entry for v5.11-rc6. This was originally going to go during the merge window but people can already trigger a build error with binutils-2.36 which doesn't emit section symbols - something which objtool relies on - so let's expedite it. Thx. --- The following changes since commit 7c53f6b671f4aba70ff15e1b05148b10d58c2837: Linux 5.11-rc3 (2021-01-10 14:34:50 -0800) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git tags/x86_entry_for_v5.11_rc6 for you to fetch changes up to 0bab9cb2d980d7c075cffb9216155f7835237f98: x86/entry: Remove put_ret_addr_in_rdi THUNK macro argument (2021-01-19 11:06:14 +0100) A single fix for objtool to generate proper unwind info for newer toolchains which do not generate section symbols anymore. And a cleanup ontop. Borislav Petkov (1): x86/entry: Remove put_ret_addr_in_rdi THUNK macro argument Nick Desaulniers (1): x86/entry: Emit a symbol for register restoring thunk Documentation/asm-annotations.rst | 5 + arch/x86/entry/thunk_64.S | 15 +-- include/linux/linkage.h | 5 + 3 files changed, 15 insertions(+), 10 deletions(-) -- Regards/Gruss, Boris. SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer, HRB 36809, AG Nürnberg
Re: [RFC PATCH v3 1/1] iio/scmi: Adding support for IIO SCMI Based Sensors
On Sat, 30 Jan 2021 21:21:41 + Cristian Marussi wrote: > Hi Jyoti, > > On Fri, Jan 29, 2021 at 02:43:13PM -0800, Jyoti Bhayana wrote: > > Hi Christian, > > > > I have addressed your feedback in v4 of the patch. Please find below > > the answers to some of your questions: > > >The initial sensor_config ORed here is NOT initialized nor zeroed. > > > > There is no need to initialize as it is already initialized to 0 when > > defined. > > > > True for the sensor_config in scmi_iio_buffer_postdisable(), BUT it is > not indeed zero-initialized at definition time in the other similar > function scmi_iio_buffer_preenable(), that is what the above comment was > referred to. > > > > being not so familiar with IIO, may I ask when and how much frequently > > > these ops are called ? (given they include a register/unregister + > > > enable/disable every time) > > > > These are called whenever the sensor is enabled/disabled by writing > > to buffer/enable sysfs node > > > > Ok, thanks. > > > >AFAIU this is called during IIO init and derives a modifier from the name > > >of the sensors which are passed by the platform fw with sensor descriptors, > > >so I would not trust them to be weell formed (:D) and try to be picky about > > >*name as it was user-input to validate. > > > > The SCMI specification has mentioned the naming convention for the > > axis as below . > > "A NULL terminated UTF-8 format string with the sensor axis name, of > > up to 16 bytes. It is recommended that the name ends with ‘_’ followed > > by the axis of the sensor in uppercase. For example, the name for the > > x-axis of a triaxial accelerometer could be “acc_X” or “_X” > > > > If there is any other better way to get the modifier, please let me know. > > > > What I was trying to say was simply that, despite what the spec says, > you cannot trust the fw/platform produced values (fw buggy ? data on channel > corrupted ? malicious pkt injections ? fuzzing ? ) and so you should be picky > and validate them also against any possible out-of-spec data, since the Kernel > must not crash even if presented with unreasonable out-of-spec garbage-like > data, thing that indeed you did in v4 by adding the check for NULL against > name param. :D (the other case of a malformed name like "acc_" seemed to > me handled properly already by the kernel strcmp) > > > > why not a break to a final 'return ret;' (with ret properly set) ? > > > > According to Jonathan, direct returns are preferred. > > > > Ok > > > >Not familiar with IIO, but is it fine to setup ops and modes AFTER > > >having attached the buffer to the scmi_iiodev ? > > >Is is not 'racy-possible' that the buffer is already operational without > > >any ops immediately after being attached ? > > > > I have looked at other IIO drivers and they all do it this way. > > > > Ok. There is a good logical flow in setting the ops before attaching, but in reality it doesn't matter because all that attach is actually doing is connecting up some internals for the iio_device_register() to act on later. Until that's called no access to the buffer ops can be made (there are no userspace or inkernel interfaces available). Jonathan > > Thanks, I'll have a look at v4. > > Cristian > > > Thanks, > > Jyoti > > > > > > > > > > > > > > > > On Fri, Jan 22, 2021 at 5:37 AM Cristian Marussi > > wrote: > > > > > > Hi Jyoti, > > > > > > a few remarks below. > > > > > > On Thu, Jan 21, 2021 at 11:21:47PM +, Jyoti Bhayana wrote: > > > > This change provides ARM SCMI Protocol based IIO device. > > > > This driver provides support for Accelerometer and Gyroscope using > > > > new SCMI Sensor Protocol defined by the upcoming SCMIv3.0 > > > > > > I'd say: > > > > > > new SCMI Sensor Protocol extension added by the upcoming SCMIv3.0 > > > > > > given that SCMI Sensor existed already in SCMIv2.0 > > > > > > > ARM specification > > > > > > > > Signed-off-by: Jyoti Bhayana > > > > --- > > > > MAINTAINERS| 6 + > > > > drivers/iio/common/Kconfig | 1 + > > > > drivers/iio/common/Makefile| 1 + > > > > drivers/iio/common/scmi_sensors/Kconfig| 18 + > > > > drivers/iio/common/scmi_sensors/Makefile | 5 + > > > > drivers/iio/common/scmi_sensors/scmi_iio.c | 736 + > > > > 6 files changed, 767 insertions(+) > > > > create mode 100644 drivers/iio/common/scmi_sensors/Kconfig > > > > create mode 100644 drivers/iio/common/scmi_sensors/Makefile > > > > create mode 100644 drivers/iio/common/scmi_sensors/scmi_iio.c > > > > > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > > > index b516bb34a8d5..ccf37d43ab41 100644 > > > > --- a/MAINTAINERS > > > > +++ b/MAINTAINERS > > > > @@ -8567,6 +8567,12 @@ S: Maintained > > > > F: > > > > Documentation/devicetree/bindings/iio/multiplexer/io-channel-mux.txt > > > > F: drivers/iio/multiplexer/iio-mux.c > > > > > > > > +I
[PATCH v3 net-next 2/5] skbuff: constify skb_propagate_pfmemalloc() "page" argument
The function doesn't write anything to the page struct itself,
so this argument can be const.
Misc: align second argument to the brace while at it.
Signed-off-by: Alexander Lobakin
Reviewed-by: Jesse Brandeburg
Acked-by: David Rientjes
---
include/linux/skbuff.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 9313b5aaf45b..b027526da4f9 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -2943,8 +2943,8 @@ static inline struct page *dev_alloc_page(void)
* @page: The page that was allocated from skb_alloc_page
* @skb: The skb that may need pfmemalloc set
*/
-static inline void skb_propagate_pfmemalloc(struct page *page,
-struct sk_buff *skb)
+static inline void skb_propagate_pfmemalloc(const struct page *page,
+ struct sk_buff *skb)
{
if (page_is_pfmemalloc(page))
skb->pfmemalloc = true;
--
2.30.0
Re: [PATCH 8/8] perf arm-spe: Set thread TID
Hi James,
On Tue, Jan 19, 2021 at 04:46:58PM +0200, James Clark wrote:
> From: Leo Yan
>
> Set thread TID for SPE samples. Now that the context ID is saved
> in each record it can be used to set the TID for a sample.
>
> The context ID is only present in SPE data if the kernel is
> compiled with CONFIG_PID_IN_CONTEXTIDR and perf record is
> run as root. Otherwise the PID of the first process is assigned
> to each SPE sample.
I tested this patch series on Hisilicon D06, it outputs the result as
expected. I am comfortable for the testing result based our two sides
on two different platforms.
Based on the discussion in the thread [1], IIUC, there have concern for
using CONTEXTIDR for non-root namespace. Thus the patch 08/08 is
limited to support PID tracing in the root namespace, so we have two
options:
Option 1: by merging patches 07/08 and 08/08, we can firstly support PID
tracing for root namespace, and later we can extend to support PID
tracing in container (and in VMs).
Option 2: we can use the software method to establish PID for SPE
trace, which can base on kernel's events PERF_RECORD_SWITCH /
PERF_RECORD_SWITCH_CPU_WIDE and check context switch ip.
To be honest, I am a bit concern for option 1 for later might
introduce regression when later support PID for containers (and VMs).
If you have a plan for option 1, I think it's good to record current
limitation and the plan for next step in the commit log, so we can merge
this patch at this time and later extend for containers.
Otherwise, we need to consider how to implement the PID tracing with
option 2. If it is the case, we should firstly only merge patches
01 ~ 06 for data source enabling. How about you think for this?
> Signed-off-by: Leo Yan
> Signed-off-by: James Clark
Besides for techinical question, you could add your "Co-developed-by"
tags for patches 06, 07, 08/08, which you have took time to refin them.
Thanks you for kindly efforts.
[1] https://lore.kernel.org/patchwork/patch/1353286/
> Cc: Peter Zijlstra
> Cc: Ingo Molnar
> Cc: Arnaldo Carvalho de Melo
> Cc: Mark Rutland
> Cc: Alexander Shishkin
> Cc: Jiri Olsa
> Cc: Namhyung Kim
> Cc: John Garry
> Cc: Will Deacon
> Cc: Mathieu Poirier
> Cc: Al Grant
> Cc: Andre Przywara
> Cc: Wei Li
> Cc: Tan Xiaojun
> Cc: Adrian Hunter
> ---
> tools/perf/util/arm-spe.c | 75 ++-
> 1 file changed, 50 insertions(+), 25 deletions(-)
>
> diff --git a/tools/perf/util/arm-spe.c b/tools/perf/util/arm-spe.c
> index 27a0b9dfe22d..9828fad7e516 100644
> --- a/tools/perf/util/arm-spe.c
> +++ b/tools/perf/util/arm-spe.c
> @@ -223,6 +223,46 @@ static inline u8 arm_spe_cpumode(struct arm_spe *spe,
> u64 ip)
> PERF_RECORD_MISC_USER;
> }
>
> +static void arm_spe_set_pid_tid_cpu(struct arm_spe *spe,
> + struct auxtrace_queue *queue)
> +{
> + struct arm_spe_queue *speq = queue->priv;
> + pid_t tid;
> +
> + tid = machine__get_current_tid(spe->machine, speq->cpu);
> + if (tid != -1) {
> + speq->tid = tid;
> + thread__zput(speq->thread);
> + } else
> + speq->tid = queue->tid;
> +
> + if ((!speq->thread) && (speq->tid != -1)) {
> + speq->thread = machine__find_thread(spe->machine, -1,
> + speq->tid);
> + }
> +
> + if (speq->thread) {
> + speq->pid = speq->thread->pid_;
> + if (queue->cpu == -1)
> + speq->cpu = speq->thread->cpu;
> + }
> +}
> +
> +static int arm_spe_set_tid(struct arm_spe_queue *speq, pid_t tid)
> +{
> + int err;
> + struct arm_spe *spe = speq->spe;
> + struct auxtrace_queue *queue;
> +
> + err = machine__set_current_tid(spe->machine, speq->cpu, tid, tid);
> + if (err)
> + return err;
> +
> + queue = &speq->spe->queues.queue_array[speq->queue_nr];
> + arm_spe_set_pid_tid_cpu(speq->spe, queue);
> + return 0;
> +}
> +
> static void arm_spe_prep_sample(struct arm_spe *spe,
> struct arm_spe_queue *speq,
> union perf_event *event,
> @@ -431,6 +471,7 @@ static int arm_spe_sample(struct arm_spe_queue *speq)
> static int arm_spe_run_decoder(struct arm_spe_queue *speq, u64 *timestamp)
> {
> struct arm_spe *spe = speq->spe;
> + const struct arm_spe_record *record;
> int ret;
>
> if (!spe->kernel_start)
> @@ -450,6 +491,11 @@ static int arm_spe_run_decoder(struct arm_spe_queue
> *speq, u64 *timestamp)
> if (ret < 0)
> continue;
>
> + record = &speq->decoder->record;
> + ret = arm_spe_set_tid(speq, record->context_id);
> + if (ret)
> + return ret;
> +
> ret = arm_spe_sample(speq);
> if (ret)
> return ret;
> @@ -500,6 +546,10 @@ static int arm_spe__setup_queue(s
[PATCH v3 net-next 4/5] net: use the new dev_page_is_reusable() instead of private versions
Now we can remove a bunch of identical functions from the drivers and
make them use common dev_page_is_reusable(). All {,un}likely() checks
are omitted since it's already present in this helper.
Also update some comments near the call sites.
Suggested-by: David Rientjes
Suggested-by: Jakub Kicinski
Cc: John Hubbard
Signed-off-by: Alexander Lobakin
---
drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 17 ++---
drivers/net/ethernet/intel/fm10k/fm10k_main.c | 13 -
drivers/net/ethernet/intel/i40e/i40e_txrx.c | 15 +--
drivers/net/ethernet/intel/iavf/iavf_txrx.c | 15 +--
drivers/net/ethernet/intel/ice/ice_txrx.c | 13 ++---
drivers/net/ethernet/intel/igb/igb_main.c | 9 ++---
drivers/net/ethernet/intel/igc/igc_main.c | 9 ++---
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 9 ++---
.../net/ethernet/intel/ixgbevf/ixgbevf_main.c | 9 ++---
drivers/net/ethernet/mellanox/mlx5/core/en_rx.c | 7 +--
10 files changed, 23 insertions(+), 93 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
index 512080640cbc..f39f5b1c4cec 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
@@ -2800,12 +2800,6 @@ static void hns3_nic_alloc_rx_buffers(struct
hns3_enet_ring *ring,
writel(i, ring->tqp->io_base + HNS3_RING_RX_RING_HEAD_REG);
}
-static bool hns3_page_is_reusable(struct page *page)
-{
- return page_to_nid(page) == numa_mem_id() &&
- !page_is_pfmemalloc(page);
-}
-
static bool hns3_can_reuse_page(struct hns3_desc_cb *cb)
{
return (page_count(cb->priv) - cb->pagecnt_bias) == 1;
@@ -2823,10 +2817,11 @@ static void hns3_nic_reuse_page(struct sk_buff *skb,
int i,
skb_add_rx_frag(skb, i, desc_cb->priv, desc_cb->page_offset + pull_len,
size - pull_len, truesize);
- /* Avoid re-using remote pages, or the stack is still using the page
-* when page_offset rollback to zero, flag default unreuse
+ /* Avoid re-using remote and pfmemalloc pages, or the stack is still
+* using the page when page_offset rollback to zero, flag default
+* unreuse
*/
- if (unlikely(!hns3_page_is_reusable(desc_cb->priv)) ||
+ if (!dev_page_is_reusable(desc_cb->priv) ||
(!desc_cb->page_offset && !hns3_can_reuse_page(desc_cb))) {
__page_frag_cache_drain(desc_cb->priv, desc_cb->pagecnt_bias);
return;
@@ -3083,8 +3078,8 @@ static int hns3_alloc_skb(struct hns3_enet_ring *ring,
unsigned int length,
if (length <= HNS3_RX_HEAD_SIZE) {
memcpy(__skb_put(skb, length), va, ALIGN(length, sizeof(long)));
- /* We can reuse buffer as-is, just make sure it is local */
- if (likely(hns3_page_is_reusable(desc_cb->priv)))
+ /* We can reuse buffer as-is, just make sure it is reusable */
+ if (dev_page_is_reusable(desc_cb->priv))
desc_cb->reuse_flag = 1;
else /* This page cannot be reused so discard it */
__page_frag_cache_drain(desc_cb->priv,
diff --git a/drivers/net/ethernet/intel/fm10k/fm10k_main.c
b/drivers/net/ethernet/intel/fm10k/fm10k_main.c
index 99b8252eb969..247f44f4cb30 100644
--- a/drivers/net/ethernet/intel/fm10k/fm10k_main.c
+++ b/drivers/net/ethernet/intel/fm10k/fm10k_main.c
@@ -194,17 +194,12 @@ static void fm10k_reuse_rx_page(struct fm10k_ring
*rx_ring,
DMA_FROM_DEVICE);
}
-static inline bool fm10k_page_is_reserved(struct page *page)
-{
- return (page_to_nid(page) != numa_mem_id()) || page_is_pfmemalloc(page);
-}
-
static bool fm10k_can_reuse_rx_page(struct fm10k_rx_buffer *rx_buffer,
struct page *page,
unsigned int __maybe_unused truesize)
{
- /* avoid re-using remote pages */
- if (unlikely(fm10k_page_is_reserved(page)))
+ /* avoid re-using remote and pfmemalloc pages */
+ if (!dev_page_is_reusable(page))
return false;
#if (PAGE_SIZE < 8192)
@@ -265,8 +260,8 @@ static bool fm10k_add_rx_frag(struct fm10k_rx_buffer
*rx_buffer,
if (likely(size <= FM10K_RX_HDR_LEN)) {
memcpy(__skb_put(skb, size), va, ALIGN(size, sizeof(long)));
- /* page is not reserved, we can reuse buffer as-is */
- if (likely(!fm10k_page_is_reserved(page)))
+ /* page is reusable, we can reuse buffer as-is */
+ if (dev_page_is_reusable(page))
return true;
/* this page cannot be reused so discard it */
diff --git a/drivers/net/ethernet/intel/i40e/i40e_txrx.c
b/drivers/net/ethernet/intel/i40e/i40e_txrx.c
index 2574e78f7597..8d2ea4293d69
Re: Migration to trusted keys: sealing user-provided key?
On Sat, 2021-01-30 at 19:53 +0200, Jarkko Sakkinen wrote: > On Thu, 2021-01-28 at 18:31 +0100, Ahmad Fatoum wrote: > > Hello, > > > > I've been looking into how a migration to using trusted/encrypted keys > > would look like (particularly with dm-crypt). > > > > Currently, it seems the the only way is to re-encrypt the partitions > > because trusted/encrypted keys always generate their payloads from > > RNG. > > > > If instead there was a key command to initialize a new trusted/encrypted > > key with a user provided value, users could use whatever mechanism they > > used beforehand to get a plaintext key and use that to initialize a new > > trusted/encrypted key. From there on, the key will be like any other > > trusted/encrypted key and not be disclosed again to userspace. > > > > What are your thoughts on this? Would an API like > > > > keyctl add trusted dmcrypt-key 'set ' # user-supplied content > > > > be acceptable? > > Maybe it's the lack of knowledge with dm-crypt, but why this would be > useful? Just want to understand the bottleneck, that's all. We upstreamed "trusted" & "encrypted" keys together in order to address this sort of problem. Instead of directly using a "trusted" key for persistent file signatures being stored as xattrs, the "encrypted" key provides one level of indirection. The "encrypted" key may be encrypted/decrypted with either a TPM based "trusted" key or with a "user" type symmetric key[1]. Instead of modifying "trusted" keys, use a "user" type "encrypted" key. Mimi [1] The ima-evm-utils README contains EVM examples of "trusted" and "user" based "encrypted" keys.
Re: [PATCH v3 2/2] counter: add GPIO based pulse counters
On Tue, 26 Jan 2021 09:07:57 +0100
Oleksij Rempel wrote:
> Hi Jonathan,
>
> On Sun, Jan 24, 2021 at 02:47:37PM +, Jonathan Cameron wrote:
> > On Fri, 22 Jan 2021 12:24:34 +0100
> > Oleksij Rempel wrote:
> >
> > > Add simple GPIO base pulse counter. This device is used to measure
> > > rotation speed of some agricultural devices, so no high frequency on the
> > > counter pin is expected.
> > >
> > > The maximal measurement frequency depends on the CPU and system load. On
> > > the idle iMX6S I was able to measure up to 20kHz without count drops.
> > >
> > > Signed-off-by: Oleksij Rempel
> >
> > Hi Oleksij,
> >
> > A few comments inline.
> >
> > Thanks,
> >
> > Jonathan
> >
> > > ---
> > > drivers/counter/Kconfig | 9 ++
> > > drivers/counter/Makefile | 1 +
> > > drivers/counter/gpio-pulse-cnt.c | 244 +++
> > > 3 files changed, 254 insertions(+)
> > > create mode 100644 drivers/counter/gpio-pulse-cnt.c
> > >
> > > diff --git a/drivers/counter/Kconfig b/drivers/counter/Kconfig
> > > index 2de53ab0dd25..9ad1d9d49dd1 100644
> > > --- a/drivers/counter/Kconfig
> > > +++ b/drivers/counter/Kconfig
> > > @@ -29,6 +29,15 @@ config 104_QUAD_8
> > > The base port addresses for the devices may be configured via the base
> > > array module parameter.
> > >
> > > +config GPIO_PULSE_CNT
> > > + tristate "GPIO pulse counter driver"
> > > + depends on GPIOLIB
> > > + help
> > > + Select this option to enable GPIO pulse counter driver.
> > > +
> > > + To compile this driver as a module, choose M here: the
> > > + module will be called gpio-pulse-cnt.
> > > +
> > > config STM32_TIMER_CNT
> > > tristate "STM32 Timer encoder counter driver"
> > > depends on MFD_STM32_TIMERS || COMPILE_TEST
> > > diff --git a/drivers/counter/Makefile b/drivers/counter/Makefile
> > > index 0a393f71e481..6a5c3fc6f2a0 100644
> > > --- a/drivers/counter/Makefile
> > > +++ b/drivers/counter/Makefile
> > > @@ -6,6 +6,7 @@
> > > obj-$(CONFIG_COUNTER) += counter.o
> > >
> > > obj-$(CONFIG_104_QUAD_8) += 104-quad-8.o
> > > +obj-$(CONFIG_GPIO_PULSE_CNT) += gpio-pulse-cnt.o
> > > obj-$(CONFIG_STM32_TIMER_CNT)+= stm32-timer-cnt.o
> > > obj-$(CONFIG_STM32_LPTIMER_CNT) += stm32-lptimer-cnt.o
> > > obj-$(CONFIG_TI_EQEP)+= ti-eqep.o
> > > diff --git a/drivers/counter/gpio-pulse-cnt.c
> > > b/drivers/counter/gpio-pulse-cnt.c
> > > new file mode 100644
> > > index ..9454345c77ad
> > > --- /dev/null
> > > +++ b/drivers/counter/gpio-pulse-cnt.c
> > > @@ -0,0 +1,244 @@
> > > +// SPDX-License-Identifier: GPL-2.0
> > > +/*
> > > + * Copyright (c) 2021 Pengutronix, Oleksij Rempel
> > > + */
> > > +
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> >
> > why of_device.h? Probably want mod_devicetable.h instead.
>
> done
>
> > > +#include
> > > +
> > > +#define GPIO_PULSE_NAME "gpio-pulse-counter"
> > > +
> > > +struct gpio_pulse_priv {
> > > + struct counter_device counter;
> > > + struct gpio_desc *gpio;
> > > + int irq;
> > > + bool enabled;
> > > + atomic_t count;
> > > +};
> > > +
> > > +static irqreturn_t gpio_pulse_irq_isr(int irq, void *dev_id)
> > > +{
> > > + struct gpio_pulse_priv *priv = dev_id;
> > > +
> > > + if (!priv->enabled)
> > > + return IRQ_NONE;
> > > +
> > > + atomic_inc(&priv->count);
> > > +
> > > + return IRQ_HANDLED;
> > > +}
> > > +
> > > +static ssize_t gpio_pulse_count_enable_read(struct counter_device
> > > *counter,
> > > + struct counter_count *count,
> > > + void *private, char *buf)
> > > +{
> > > + struct gpio_pulse_priv *priv = counter->priv;
> > > +
> > > + return sysfs_emit(buf, "%d\n", priv->enabled);
> > > +}
> > > +
> > > +static ssize_t gpio_pulse_count_enable_write(struct counter_device
> > > *counter,
> > > + struct counter_count *count,
> > > + void *private,
> > > + const char *buf, size_t len)
> > > +{
> > > + struct gpio_pulse_priv *priv = counter->priv;
> > > + bool enable;
> > > + ssize_t ret;
> > > +
> > > + ret = kstrtobool(buf, &enable);
> > > + if (ret)
> > > + return ret;
> > > +
> > > + if (priv->enabled == enable)
> > > + return len;
> > > +
> > > + priv->enabled = enable;
> > > +
> > > + if (enable)
> > > + enable_irq(priv->irq);
> > > + else
> > > + disable_irq(priv->irq);
> >
> > As pointed out by Ahmad, this is all racy.
> > Personally I'd just let the race happen, and don't
> > bother with the priv->enabled at all.
>
> yes, i forgot about existence of IRQ_NOAUTOEN
>
> > We aren't going to be dealing with shared interrupts
> > here so if we get a race, it's between userspace write
> > getting through to enable / disable the interrupt and
> > a pulse coming in. The userspace part is so unpre
[GIT PULL] Please pull powerpc/linux.git powerpc-5.11-6 tag
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi Linus, Please pull another powerpc fix for 5.11: The following changes since commit 08685be7761d69914f08c3d6211c543a385a5b9c: powerpc/64s: fix scv entry fallback flush vs interrupt (2021-01-20 15:58:19 +1100) are available in the git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git tags/powerpc-5.11-6 for you to fetch changes up to 4025c784c573cab7e3f84746cc82b8033923ec62: powerpc/64s: prevent recursive replay_soft_interrupts causing superfluous interrupt (2021-01-24 22:27:24 +1100) - -- powerpc fixes for 5.11 #6 One fix for a bug in our soft interrupt masking, which could lead to interrupt replaying recursing, causing spurious interrupts. Thanks to: Nicholas Piggin. - -- Nicholas Piggin (1): powerpc/64s: prevent recursive replay_soft_interrupts causing superfluous interrupt arch/powerpc/kernel/irq.c | 28 +++- 1 file changed, 16 insertions(+), 12 deletions(-) -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEJFGtCPCthwEv2Y/bUevqPMjhpYAFAmAWmTMACgkQUevqPMjh pYDsLBAAoGKn8ZsTEYHm/sRJ7Bsl+H+AvokytjpU9aZPOiqPgAQiUBNXDJy2ykmp uzBWDp0J9J6waoaRxFsjHt2nOIkPwWMzvbE2QRfbmisNW4OVSvxjMncRhHVhBdpf 9bnrRI37DYVSDEx1E8RD6v5rRCrZv/CNEXwSVyf8EBcd8ExZGZy1zL01gC9F9Iwy 09JiNrqAvHay13V04GPRPCzYYUb3asCl1Im/OLKfoIKzx3cI7qYvcLh215dP7QnU p621aLIkGw3R3Fsol2wMT4/KZljsoMXFzUp/IXoLBZUM9GeV6XRYRLRdjCO5xpoD hVP7i7l7B468fJaOflr+qn26YvFtQsqZB3/B6NoWiDZhb/LrTieV5d6ogMO1teRu TsAmZrXiocP7K3NiAHjRx8cdJnUhTikPCnyOMILqBoXWfPbRCJdVp5yTIcJ2ho+G GwJ4/gXaqbCMKSctzxAzSdGaXbo3okpBRVPpYcx2/mmju9NGhFxB4+Jod4vZQnPY /Bj5l5CJF9XzbfNSvWZ6/Q0AuhEszhhL73SrU8uh4DuhoVShr8D/Lwp+zSmdvhAf t1YmvugpymG+GlVW5dVjHUqbVyDe5ZDprT/xwqhh51yuxMDnmmXs6tFgr4RQbBqU St0g5NgUa44SQ//bBYVuUrRpEeqSJXg/sQ8GDp4b32oaq2db/kc= =XoZ/ -END PGP SIGNATURE-
Re: [RFC PATCH v3 1/1] iio/scmi: Adding support for IIO SCMI Based Sensors
On Fri, 29 Jan 2021 14:50:20 -0800
Jyoti Bhayana wrote:
> Hi Peter,
>
> I have modified the comments in v4 of that patch. Regarding your
> suggestion of this driver handling a greater value range
> by adjusting the scale accordingly, it would also require the driver
> to change the sensor readings as well based on the updated scale and
> the accuracy of the sensor reading will be lost as the sensor readings
> are 64 bit integers and not float.
> If the IIO driver needs to support a 64 bit sensor range, then I would
> prefer to add a new IIO val type for 64 bit fractional value which
> takes 4 int vals: val_high,val_low, val2_high and val2_low.
The problem with that sort of change is that you have to make
all various users of callbacks in the kernel deal with more parameters.
read_raw gets called form a lot of places.
I'm really not keen to do that. It means making a big mess to deal
with this one case of too many layers of abstraction and values claiming
considerably more precision than they actually have. We decided on
an integer pair a long time back as it provides more than enough precision
for any real sensor.
Given that you are using fractional values to generate a sysfs string
(for direct exposure to userspace anyway), just do the maths inside
the driver to fit it into a INT_PLUS_MICRO or similar.
Jonathan
>
> Thanks,
> Jyoti
>
> On Tue, Jan 26, 2021 at 7:29 AM Peter Hilber
> wrote:
> >
> > On 22.01.21 00:21, Jyoti Bhayana wrote:
> >
> >
> >
> > > +
> > > +static int scmi_iio_get_sensor_max_range(struct iio_dev *iio_dev, int
> > > *val,
> > > + int *val2)
> > > +{
> > > + struct scmi_iio_priv *sensor = iio_priv(iio_dev);
> > > + int max_range_high, max_range_low;
> > > + long long max_range;
> > > +
> > > + /*
> > > + * All the axes are supposed to have the same value for max range.
> > > + * We are just using the values from the Axis 0 here.
> > > + */
> > > + if (sensor->sensor_info->axis[0].extended_attrs) {
> > > + max_range = sensor->sensor_info->axis[0].attrs.max_range;
> > > + max_range_high = H32(max_range);
> > > + max_range_low = L32(max_range);
> > > +
> > > + /*
> > > + * As IIO Val types have no provision for 64 bit values,
> > > + * and currently there are no known sensors using 64 bit
> > > + * for the range, this driver only supports sensor with
> > > + * 32 bit range value.
> > > + */
> > This comment and the corresponding one in
> > scmi_iio_get_sensor_min_range() seem to be misleading to me. The extrema
> > will probably exceed 32 bits even for physical sensors which do have
> > less than 32 bits of resolution. The reason is that the SCMI sensor
> > management protocol does not transmit a `scale' value as used by IIO.
> > Instead, SCMI transmits an exponent with base ten.
> >
> > So, an SCMI sensor with a unit/LSB value which is not a power of ten
> > will have its unit/LSB value split into an exponent (with base ten) and
> > a mantissa.
> >
> > The SCMI platform (which exposes the physical sensor) will have to
> > incorporate the mantissa into the sensor value. The simplest approach is
> > to just multiply the mantissa with the raw physical sensor value, which
> > will use more bits than the raw physical sensor value, depending on the
> > unit/LSB value (and on the split of the unit/LSB value into exponent and
> > mantissa).
> >
> > So I think the comment should at least make clear that the overflow may
> > also happen for physical sensors with less than 32 bit of resolution,
> > since it cannot be assumed that SCMI platforms will, without any
> > apparent need, restrict the values to 32 bits, when that would mean
> > additional complexity and potential loss of accuracy. (And in the long
> > term this driver could IMHO try to handle a greater value range by
> > adjusting the `scale' value accordingly.)
> >
> > Best regards,
> >
> > Peter
> >
> > > + if (max_range_high != 0)
> > > + return -EINVAL;
> > > +
> > > + *val = max_range_low;
> > > + *val2 = 1;
> > > + }
> > > + return 0;
> > > +}
> > > +
> > > +static void scmi_iio_get_sensor_resolution(struct iio_dev *iio_dev, int
> > > *val,
> > > +int *val2)
> > > +{
> > > + struct scmi_iio_priv *sensor = iio_priv(iio_dev);
> > > +
> > > + /*
> > > + * All the axes are supposed to have the same value for resolution
> > > + * and exponent. We are just using the values from the Axis 0 here.
> > > + */
> > > + if (sensor->sensor_info->axis[0].extended_attrs) {
> > > + uint resolution = sensor->sensor_info->axis[0].resolution;
> > > + s8 exponent = sensor->sensor_info->axis[0].exponent;
> > > + s8 scale = sensor->sensor_info->axis[0].scale;
> > > +
> > > + /*
Re: [PATCH v2 3/3] arm64: dts: mediatek: mt8183: Add domain supply for mfg
On 29/01/2021 11:12, Hsin-Yi Wang wrote:
> Add domain supply node.
>
> Signed-off-by: Hsin-Yi Wang
> ---
Applied to v5.11-next/dts64
Thanks
> arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi | 4
> arch/arm64/boot/dts/mediatek/mt8183.dtsi | 2 +-
> 2 files changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
> b/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
> index bf2ad1294dd30..ebd53755d538a 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
> @@ -709,6 +709,10 @@ cros_ec {
> };
> };
>
> +&mfg {
> + domain-supply = <&mt6358_vgpu_reg>;
> +};
> +
> &soc_data {
> status = "okay";
> };
> diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> index 5b782a4769e7e..bda283fa92452 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> @@ -360,7 +360,7 @@ power-domain@MT8183_POWER_DOMAIN_MFG_ASYNC {
> #size-cells = <0>;
> #power-domain-cells = <1>;
>
> - power-domain@MT8183_POWER_DOMAIN_MFG {
> + mfg:
> power-domain@MT8183_POWER_DOMAIN_MFG {
> reg = ;
> #address-cells = <1>;
> #size-cells = <0>;
>
Re: [PATCH v2 1/3] dt-bindings: power: Add domain regulator supply
On 29/01/2021 11:12, Hsin-Yi Wang wrote: > Some power domains (eg. mfg) needs to turn on power supply before power > on. > > Signed-off-by: Hsin-Yi Wang > Reviewed-by: Rob Herring > Reviewed-by: Enric Balletbo i Serra Applied to v5.11-next/soc Thanks > --- > .../bindings/power/mediatek,power-controller.yaml| 9 + > 1 file changed, 9 insertions(+) > > diff --git > a/Documentation/devicetree/bindings/power/mediatek,power-controller.yaml > b/Documentation/devicetree/bindings/power/mediatek,power-controller.yaml > index d14cb9bac8497..e529586af5a12 100644 > --- a/Documentation/devicetree/bindings/power/mediatek,power-controller.yaml > +++ b/Documentation/devicetree/bindings/power/mediatek,power-controller.yaml > @@ -82,6 +82,9 @@ patternProperties: >be specified by order, adding first the BASIC clocks followed by > the >SUSBSYS clocks. > > + domain-supply: > +description: domain regulator supply. > + >mediatek,infracfg: > $ref: /schemas/types.yaml#/definitions/phandle > description: phandle to the device containing the INFRACFG register > range. > @@ -130,6 +133,9 @@ patternProperties: >be specified by order, adding first the BASIC clocks followed > by the >SUSBSYS clocks. > > + domain-supply: > +description: domain regulator supply. > + >mediatek,infracfg: > $ref: /schemas/types.yaml#/definitions/phandle > description: phandle to the device containing the INFRACFG > register range. > @@ -178,6 +184,9 @@ patternProperties: >be specified by order, adding first the BASIC clocks > followed by the >SUSBSYS clocks. > > + domain-supply: > +description: domain regulator supply. > + >mediatek,infracfg: > $ref: /schemas/types.yaml#/definitions/phandle > description: phandle to the device containing the INFRACFG > register range. >
Re: [PATCH v2 2/3] soc: mediatek: pm-domains: Add domain regulator supply
On 29/01/2021 11:12, Hsin-Yi Wang wrote:
> Some power domains (eg. mfg) needs to turn on power supply before power
> on.
>
> Signed-off-by: Hsin-Yi Wang
> Reviewed-by: Nicolas Boichat
> Reviewed-by: Enric Balletbo i Serra
Applied to v5.11-next/soc
Thanks
> ---
> drivers/soc/mediatek/mt8183-pm-domains.h | 1 +
> drivers/soc/mediatek/mtk-pm-domains.c| 42 +++-
> drivers/soc/mediatek/mtk-pm-domains.h| 1 +
> 3 files changed, 43 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/soc/mediatek/mt8183-pm-domains.h
> b/drivers/soc/mediatek/mt8183-pm-domains.h
> index 8d996c5d2682d..aa5230e6c12f8 100644
> --- a/drivers/soc/mediatek/mt8183-pm-domains.h
> +++ b/drivers/soc/mediatek/mt8183-pm-domains.h
> @@ -38,6 +38,7 @@ static const struct scpsys_domain_data
> scpsys_domain_data_mt8183[] = {
> .ctl_offs = 0x0338,
> .sram_pdn_bits = GENMASK(8, 8),
> .sram_pdn_ack_bits = GENMASK(12, 12),
> + .caps = MTK_SCPD_DOMAIN_SUPPLY,
> },
> [MT8183_POWER_DOMAIN_MFG_CORE0] = {
> .sta_mask = BIT(7),
> diff --git a/drivers/soc/mediatek/mtk-pm-domains.c
> b/drivers/soc/mediatek/mtk-pm-domains.c
> index fb70cb3b07b36..1e0a65fbce1db 100644
> --- a/drivers/soc/mediatek/mtk-pm-domains.c
> +++ b/drivers/soc/mediatek/mtk-pm-domains.c
> @@ -13,6 +13,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> #include "mt8173-pm-domains.h"
> @@ -40,6 +41,7 @@ struct scpsys_domain {
> struct clk_bulk_data *subsys_clks;
> struct regmap *infracfg;
> struct regmap *smi;
> + struct regulator *supply;
> };
>
> struct scpsys {
> @@ -187,6 +189,16 @@ static int scpsys_bus_protect_disable(struct
> scpsys_domain *pd)
> return _scpsys_bus_protect_disable(pd->data->bp_infracfg, pd->infracfg);
> }
>
> +static int scpsys_regulator_enable(struct regulator *supply)
> +{
> + return supply ? regulator_enable(supply) : 0;
> +}
> +
> +static int scpsys_regulator_disable(struct regulator *supply)
> +{
> + return supply ? regulator_disable(supply) : 0;
> +}
> +
> static int scpsys_power_on(struct generic_pm_domain *genpd)
> {
> struct scpsys_domain *pd = container_of(genpd, struct scpsys_domain,
> genpd);
> @@ -194,10 +206,14 @@ static int scpsys_power_on(struct generic_pm_domain
> *genpd)
> bool tmp;
> int ret;
>
> - ret = clk_bulk_enable(pd->num_clks, pd->clks);
> + ret = scpsys_regulator_enable(pd->supply);
> if (ret)
> return ret;
>
> + ret = clk_bulk_enable(pd->num_clks, pd->clks);
> + if (ret)
> + goto err_reg;
> +
> /* subsys power on */
> regmap_set_bits(scpsys->base, pd->data->ctl_offs, PWR_ON_BIT);
> regmap_set_bits(scpsys->base, pd->data->ctl_offs, PWR_ON_2ND_BIT);
> @@ -232,6 +248,8 @@ static int scpsys_power_on(struct generic_pm_domain
> *genpd)
> clk_bulk_disable(pd->num_subsys_clks, pd->subsys_clks);
> err_pwr_ack:
> clk_bulk_disable(pd->num_clks, pd->clks);
> +err_reg:
> + scpsys_regulator_disable(pd->supply);
> return ret;
> }
>
> @@ -267,6 +285,8 @@ static int scpsys_power_off(struct generic_pm_domain
> *genpd)
>
> clk_bulk_disable(pd->num_clks, pd->clks);
>
> + scpsys_regulator_disable(pd->supply);
> +
> return 0;
> }
>
> @@ -275,6 +295,7 @@ generic_pm_domain *scpsys_add_one_domain(struct scpsys
> *scpsys, struct device_no
> {
> const struct scpsys_domain_data *domain_data;
> struct scpsys_domain *pd;
> + struct device_node *root_node = scpsys->dev->of_node;
> struct property *prop;
> const char *clk_name;
> int i, ret, num_clks;
> @@ -307,6 +328,25 @@ generic_pm_domain *scpsys_add_one_domain(struct scpsys
> *scpsys, struct device_no
> pd->data = domain_data;
> pd->scpsys = scpsys;
>
> + if (MTK_SCPD_CAPS(pd, MTK_SCPD_DOMAIN_SUPPLY)) {
> + /*
> + * Find regulator in current power domain node.
> + * devm_regulator_get() finds regulator in a node and its child
> + * node, so set of_node to current power domain node then change
> + * back to original node after regulator is found for current
> + * power domain node.
> + */
> + scpsys->dev->of_node = node;
> + pd->supply = devm_regulator_get(scpsys->dev, "domain");
> + scpsys->dev->of_node = root_node;
> + if (IS_ERR(pd->supply)) {
> + dev_err_probe(scpsys->dev, PTR_ERR(pd->supply),
> + "%pOF: failed to get power supply.\n",
> + node);
> + return ERR_CAST(pd->supply);
> + }
> + }
> +
> pd->infracfg = syscon_regmap_lookup_by_phandle_optional(node,
> "mediatek,infracfg");
> if (IS_ERR(pd->infracfg))
> return ERR_CAST(pd->infracfg);
> di
Re: [PATCH 1/2] iio:adc:ti-ads124s08: Fix start stop conversion command
On Thu, 21 Jan 2021 13:14:30 -0600
Dan Murphy wrote:
> Fix start and stop conversion commands. The proper command is not be
> sent.
>
> Fixes: ("e717f8c6dfec iio: adc: Add the TI ads124s08 ADC code")
That's not the right format for a fixes, tag. I fixed it whilst applying.
> Signed-off-by: Dan Murphy
I've not applied this because there is another START_CONV in the
driver and I'm not sure that one is right either. It looks to be
a very similar code path to the one you are fixing here.
Thanks,
Jonathan
> ---
> drivers/iio/adc/ti-ads124s08.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/iio/adc/ti-ads124s08.c b/drivers/iio/adc/ti-ads124s08.c
> index b4a128b19188..f05d4e0e1c9d 100644
> --- a/drivers/iio/adc/ti-ads124s08.c
> +++ b/drivers/iio/adc/ti-ads124s08.c
> @@ -237,7 +237,7 @@ static int ads124s_read_raw(struct iio_dev *indio_dev,
> goto out;
> }
>
> - ret = ads124s_write_cmd(indio_dev, ADS124S08_START_CONV);
> + ret = ads124s_write_cmd(indio_dev, ADS124S08_CMD_START);
> if (ret) {
> dev_err(&priv->spi->dev, "Start conversions failed\n");
> goto out;
> @@ -251,7 +251,7 @@ static int ads124s_read_raw(struct iio_dev *indio_dev,
>
> *val = ret;
>
> - ret = ads124s_write_cmd(indio_dev, ADS124S08_STOP_CONV);
> + ret = ads124s_write_cmd(indio_dev, ADS124S08_CMD_STOP);
> if (ret) {
> dev_err(&priv->spi->dev, "Stop conversions failed\n");
> goto out;
Re: [PATCH v13 0/8] drm/mediatek: add support for mediatek SOC MT8183
On 29/01/2021 10:22, Hsin-Yi Wang wrote: > This series is based on kernel/git/chunkuang.hu/linux.git mediatek-drm-next > The series is tested on a mt8183 krane device. > > Change since v12 > - fix mtk_dither_config > > Change since v10, v11 > - fix review comments in v9 > > Change since v9 > - change several function to rebase to mediatek-drm-next > > Change since v8 > - fix some review comment in v8 > - separate gamma module for mt8183 has no dither function in gamma > - enable dither function for 5 or 6 bpc panel display > - separate ddp mutex patch from the whole Soc patch > > Change since v7 > - add dt-binding for mt8183 display > - base mmsys patch > https://patchwork.kernel.org/project/linux-mediatek/cover/1607506379-10998-1-git-send-email-yongqiang@mediatek.com/ > - base dts patch > https://patchwork.kernel.org/project/linux-mediatek/cover/20201127104930.1981497-1-enric.balle...@collabora.com/ These are already upstream since v5.11, right? Please drop reference in further versions, it confused me :) Regards, Matthias > - add mt8183 function call for setting the routing registers > - add RDMA fifo size error handle > > Change since v6 > - move ddp component define into mtk_mmsys.h > - add mmsys private data to support different ic path connection > - add mt8183-mmsys.c to support 8183 path connection > - fix reviewed issue in v6 > > Change since v5 > - fix reviewed issue in v5 > base https://patchwork.kernel.org/project/linux-mediatek/list/?series=213219 > > Change since v4 > - fix reviewed issue in v4 > > Change since v3 > - fix reviewed issue in v3 > - fix type error in v3 > - fix conflict with iommu patch > > Change since v2 > - fix reviewed issue in v2 > - add mutex node into dts file > > Changes since v1: > - fix reviewed issue in v1 > - add dts for mt8183 display nodes > - adjust display clock control flow in patch 22 > - add vmap support for mediatek drm in patch 23 > - fix page offset issue for mmap function in patch 24 > - enable allow_fb_modifiers for mediatek drm in patch 25 > > Hsin-Yi Wang (1): > drm/mediatek: add mtk_dither_set_common() function > > Yongqiang Niu (7): > arm64: dts: mt8183: rename rdma fifo size > arm64: dts: mt8183: refine gamma compatible name > drm/mediatek: separate gamma module > drm/mediatek: add has_dither private data for gamma > drm/mediatek: enable dither function > soc: mediatek: add mtk mutex support for MT8183 > drm/mediatek: add support for mediatek SOC MT8183 > > arch/arm64/boot/dts/mediatek/mt8183.dtsi| 7 +- > drivers/gpu/drm/mediatek/Makefile | 1 + > drivers/gpu/drm/mediatek/mtk_disp_drv.h | 14 ++ > drivers/gpu/drm/mediatek/mtk_disp_gamma.c | 198 > drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 18 ++ > drivers/gpu/drm/mediatek/mtk_disp_rdma.c| 6 + > drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 111 --- > drivers/gpu/drm/mediatek/mtk_drm_drv.c | 49 - > drivers/gpu/drm/mediatek/mtk_drm_drv.h | 1 + > drivers/soc/mediatek/mtk-mutex.c| 50 + > 10 files changed, 379 insertions(+), 76 deletions(-) > create mode 100644 drivers/gpu/drm/mediatek/mtk_disp_gamma.c >
Re: [PATCH V2] rtc: mc146818: Detect and handle broken RTCs
Thomas Gleixner writes:
> The recent fix for handling the UIP bit unearthed another issue in the RTC
> code. If the RTC is advertised but the readout is straight 0xFF because
> it's not available, the old code just proceeded with crappy values, but the
> new code hangs because it waits for the UIP bit to become low.
>
> Add a sanity check in the RTC CMOS probe function which reads the RTC_VALID
> register (Register D) which should have bit 0-6 cleared. If that's not the
> case then fail to register the CMOS.
>
> Add the same check to mc146818_get_time(), warn once when the condition
> is true and invalidate the rtc_time data.
In case it is helpful: on my hardware this patch triggers a warning
(attached below).
Without it the rtc messages look like this:
[2.783386] rtc_cmos 00:01: RTC can wake from S4
[2.784302] rtc_cmos 00:01: registered as rtc0
[2.785036] rtc_cmos 00:01: setting system clock to 2021-01-31T10:13:40 UTC
(1612088020)
[2.785713] rtc_cmos 00:01: alarms up to one month, y3k, 114 bytes nvram,
hpet irqs
Dirk
[7.258410] [ cut here ]
[7.258414] WARNING: CPU: 2 PID: 0 at drivers/rtc/rtc-mc146818-lib.c:25
mc146818_get_time+0x2b/0x1e5
[7.258420] Modules linked in: iwlmvm(+) mac80211 iwlwifi sdhci_pci
amdgpu(+) drm_ttm_helper cfg80211 ttm cqhci gpu_sched sdhci ccp
thinkpad_acpi(+) rng_core nvram tpm_tis(+) tpm_tis_core wmi tpm pinctrl_amd
[7.258432] CPU: 2 PID: 0 Comm: swapper/2 Tainted: GW
5.11.0-rc5-next-20210129-x86_64 #180
[7.258434] Hardware name: LENOVO 20U50008GE/20U50008GE, BIOS R19ET26W (1.10
) 06/22/2020
[7.258435] RIP: 0010:mc146818_get_time+0x2b/0x1e5
[7.258437] Code: 56 41 55 45 31 ed 41 54 55 53 48 89 fb 48 c7 c7 bc d9 eb
82 e8 26 d8 36 00 bf 0d 00 00 00 48 89 c5 e8 6d d1 8f ff a8 7f 74 24 <0f> 0b 48
c7 c7 bc d9 eb 82 48 89 ee e8 bc d6 36 00 b0 ff b9 24 00
[7.258438] RSP: 0018:c922cef0 EFLAGS: 00010002
[7.258440] RAX: 0031 RBX: c922cf24 RCX:
[7.258441] RDX: 0001 RSI: 888105607000 RDI: 000d
[7.258441] RBP: 0046 R08: c922cf24 R09:
[7.258442] R10: R11: R12: 888105607000
[7.258443] R13: R14: c922cfa4 R15:
[7.258444] FS: () GS:88840ec8()
knlGS:
[7.258445] CS: 0010 DS: ES: CR0: 80050033
[7.258446] CR2: 7f2ed26c4160 CR3: 0480a000 CR4: 00350ee0
[7.258447] Call Trace:
[7.258449]
[7.258450] hpet_rtc_interrupt+0xd3/0x1a3
[7.258454] __handle_irq_event_percpu+0x6b/0x12e
[7.258457] handle_irq_event_percpu+0x2c/0x6f
[7.258459] handle_irq_event+0x23/0x43
[7.258461] handle_edge_irq+0x9e/0xbb
[7.258463] asm_call_irq_on_stack+0x12/0x20
[7.258467]
[7.258467] common_interrupt+0x9a/0x123
[7.258470] asm_common_interrupt+0x1e/0x40
[7.258472] RIP: 0010:cpuidle_enter_state+0x13e/0x1fe
[7.258475] Code: 49 89 c4 e8 bd fd ff ff 31 ff e8 3e 80 92 ff 45 84 ff 74
12 9c 58 0f ba e0 09 73 03 0f 0b fa 31 ff e8 13 16 96 ff fb 45 85 f6 <0f> 88 97
00 00 00 49 63 d6 4c 2b 24 24 48 6b ca 68 48 6b c2 30 4c
[7.258476] RSP: 0018:c9167eb0 EFLAGS: 0206
[7.258477] RAX: 88840eca8240 RBX: 888101e0d400 RCX: 0001b0a24b16
[7.258478] RDX: 0002 RSI: 0002 RDI:
[7.258478] RBP: 0003 R08: R09:
[7.258479] R10: 88810083c4a8 R11: R12: 0001b0a24b48
[7.258480] R13: 8299cc60 R14: 0003 R15:
[7.258482] cpuidle_enter+0x2b/0x37
[7.258483] do_idle+0x126/0x184
[7.258485] cpu_startup_entry+0x18/0x1a
[7.258486] secondary_startup_64_no_verify+0xb0/0xbb
[7.258489] ---[ end trace 9da59c3696ed99d8 ]---
> Reported-by: Mickaël Salaün
> Signed-off-by: Thomas Gleixner
> Tested-by: Mickaël Salaün
> ---
> V2: Fixed the sizeof() as spotted by Mickaël
> ---
> drivers/rtc/rtc-cmos.c |8
> drivers/rtc/rtc-mc146818-lib.c |7 +++
> 2 files changed, 15 insertions(+)
>
> --- a/drivers/rtc/rtc-cmos.c
> +++ b/drivers/rtc/rtc-cmos.c
> @@ -805,6 +805,14 @@ cmos_do_probe(struct device *dev, struct
>
> spin_lock_irq(&rtc_lock);
>
> + /* Ensure that the RTC is accessible. Bit 0-6 must be 0! */
> + if ((CMOS_READ(RTC_VALID) & 0x7f) != 0) {
> + spin_unlock_irq(&rtc_lock);
> + dev_warn(dev, "not accessible\n");
> + retval = -ENXIO;
> + goto cleanup1;
> + }
> +
> if (!(flags & CMOS_RTC_FLAGS_NOFREQ)) {
> /* force periodic irq to CMOS reset default of 1024Hz;
>*
> --- a/drivers/rtc/rtc-mc146818-lib.c
> +++ b/drivers/rtc/rtc-mc146818-lib.c
> @@ -21,6 +21,13 @@ u
Re: [PATCH v2] arm64: dts: mt8192: add nor_flash device node
On 23/12/2020 05:22, Bayi Cheng wrote:
> From: bayi cheng
>
> add nor_flash device node
>
> Change-Id: I79f0228529bd8a33e5f354b7a861a4ec8d92e9ba
Applied to v5.11-next/dts64
I dropped the Change-Id. In the future please make sure to not include this tag
in upstream submissions.
Thanks!
> Signed-off-by: bayi cheng
> ---
> Change in v2:
> 1: add dependent patch of arm soc
> 2: change compatible name
>
> Depends on:
> https://patchwork.kernel.org/patch/11713559/
> [v4,1/3] arm64: dts: Add Mediatek SoC MT8192 and evaluation board dts and
> Makefile
> ---
> arch/arm64/boot/dts/mediatek/mt8192.dtsi | 13 +
> 1 file changed, 13 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/mediatek/mt8192.dtsi
> b/arch/arm64/boot/dts/mediatek/mt8192.dtsi
> index e12e024..751c877 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8192.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8192.dtsi
> @@ -379,6 +379,19 @@
> status = "disabled";
> };
>
> + nor_flash: spi@11234000 {
> + compatible = "mediatek,mt8192-nor";
> + reg = <0 0x11234000 0 0xe0>;
> + interrupts = ;
> + clocks = <&clk26m>,
> + <&clk26m>,
> + <&clk26m>;
> + clock-names = "spi", "sf", "axi";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "disable";
> + };
> +
> i2c3: i2c3@11cb {
> compatible = "mediatek,mt8192-i2c";
> reg = <0 0x11cb 0 0x1000>,
>
Re: [PATCH] soc: mediatek: cmdq: Remove cmdq_pkt_flush()
On 30/01/2021 10:45, Chun-Kuang Hu wrote:
> Hi, Matthias:
>
> Chun-Kuang Hu 於 2021年1月10日 週日 上午6:59寫道：
>>
>> Hi, Matthias:
>>
>> Chun-Kuang Hu 於 2020年12月3日 週四 上午7:59寫道：
>>>
>>> rx_callback is a standard mailbox callback mechanism and could
>>> cover the function of proprietary cmdq_task_cb, so it is better
>>> to use the standard one instead of the proprietary one. But
>>> register rx_callback should before mbox_request_channel(),
>>> so remove cmdq_pkt_flush() and let client driver implement
>>> its own synchronous flush.
>>
>> How do you think about this patch? This patch is derived from [1]
>> according to Jassi's suggestion [2].
>>
>> [1]
>> https://patchwork.kernel.org/project/linux-mediatek/patch/20200927230422.11610-3-chunkuang...@kernel.org/
>> [2]
>> https://patchwork.kernel.org/project/linux-mediatek/cover/20200927230422.11610-1-chunkuang...@kernel.org/
>
> Just a ping.
>
Applied now to v5.11-next/soc
Sorry for the delay.
Matthias
> Regards,
> Chun-Kuang.
>
>>
>> Regards,
>> Chun-Kuang.
>>
>>>
>>> Signed-off-by: Chun-Kuang Hu
>>> ---
>>> drivers/soc/mediatek/mtk-cmdq-helper.c | 32 --
>>> include/linux/soc/mediatek/mtk-cmdq.h | 12 --
>>> 2 files changed, 44 deletions(-)
>>>
>>> diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c
>>> b/drivers/soc/mediatek/mtk-cmdq-helper.c
>>> index 505651b0d715..fd3bc39538a1 100644
>>> --- a/drivers/soc/mediatek/mtk-cmdq-helper.c
>>> +++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
>>> @@ -502,36 +502,4 @@ int cmdq_pkt_flush_async(struct cmdq_pkt *pkt,
>>> cmdq_async_flush_cb cb,
>>> }
>>> EXPORT_SYMBOL(cmdq_pkt_flush_async);
>>>
>>> -struct cmdq_flush_completion {
>>> - struct completion cmplt;
>>> - bool err;
>>> -};
>>> -
>>> -static void cmdq_pkt_flush_cb(struct cmdq_cb_data data)
>>> -{
>>> - struct cmdq_flush_completion *cmplt;
>>> -
>>> - cmplt = (struct cmdq_flush_completion *)data.data;
>>> - if (data.sta != CMDQ_CB_NORMAL)
>>> - cmplt->err = true;
>>> - else
>>> - cmplt->err = false;
>>> - complete(&cmplt->cmplt);
>>> -}
>>> -
>>> -int cmdq_pkt_flush(struct cmdq_pkt *pkt)
>>> -{
>>> - struct cmdq_flush_completion cmplt;
>>> - int err;
>>> -
>>> - init_completion(&cmplt.cmplt);
>>> - err = cmdq_pkt_flush_async(pkt, cmdq_pkt_flush_cb, &cmplt);
>>> - if (err < 0)
>>> - return err;
>>> - wait_for_completion(&cmplt.cmplt);
>>> -
>>> - return cmplt.err ? -EFAULT : 0;
>>> -}
>>> -EXPORT_SYMBOL(cmdq_pkt_flush);
>>> -
>>> MODULE_LICENSE("GPL v2");
>>> diff --git a/include/linux/soc/mediatek/mtk-cmdq.h
>>> b/include/linux/soc/mediatek/mtk-cmdq.h
>>> index 960704d75994..2c6aa84c0e80 100644
>>> --- a/include/linux/soc/mediatek/mtk-cmdq.h
>>> +++ b/include/linux/soc/mediatek/mtk-cmdq.h
>>> @@ -288,16 +288,4 @@ int cmdq_pkt_finalize(struct cmdq_pkt *pkt);
>>> int cmdq_pkt_flush_async(struct cmdq_pkt *pkt, cmdq_async_flush_cb cb,
>>> void *data);
>>>
>>> -/**
>>> - * cmdq_pkt_flush() - trigger CMDQ to execute the CMDQ packet
>>> - * @pkt: the CMDQ packet
>>> - *
>>> - * Return: 0 for success; else the error code is returned
>>> - *
>>> - * Trigger CMDQ to execute the CMDQ packet. Note that this is a
>>> - * synchronous flush function. When the function returned, the recorded
>>> - * commands have been done.
>>> - */
>>> -int cmdq_pkt_flush(struct cmdq_pkt *pkt);
>>> -
>>> #endif /* __MTK_CMDQ_H__ */
>>> --
>>> 2.17.1
>>>
Re: [PATCH] soc: qcom: ocmem: don't return NULL in of_get_ocmem
On Sat, Jan 30, 2021 at 03:23:49PM +0100, Luca Weiss wrote:
> If ocmem probe fails for whatever reason, of_get_ocmem returned NULL.
> Without this, users must check for both NULL and IS_ERR on the returned
> pointer - which didn't happen in drivers/gpu/drm/msm/adreno/adreno_gpu.c
> leading to a NULL pointer dereference.
>
> Fixes: 88c1e9404f1d ("soc: qcom: add OCMEM driver")
> Signed-off-by: Luca Weiss
Reviewed-by: Brian Masney
extended bpf_send_signal_thread with argument
Hi, I would like to send a signal from a bpf program invoked from a perf_event. There is: // kernel/trace/bpf_trace.c BPF_CALL_1(bpf_send_signal_thread, u32, sig) which is nice, but it does not allow me to pass any arguments. I can use a bpf map indexed by pid to "pass" some additional info, but it's messy and slow (and may cause some synchronization issues, I am not sure yet). Signals allow to pass additional arguments, it would be nice to expose this to bpf programs as well. Any objections? Do you see any potential issues with this? On the implementation side it seems to be almost trivial to add something like this: BPF_CALL_2(bpf_send_signal_thread_ex, u32, sig, uintptr_t sival) However, siginfo_t is way larger and allows to pass a whole lot of info, and the latest user-space APIs pidfd_send_signal just directly accepts siginfo_t (and rt_tgsigqueueinfo as well). But I am not sure how to expose it according to bpf rules. Could we do something like (pass whatever you want, it's your business)? BPF_CALL_2(bpf_send_signal_thread_ex, u32, sig, char siginfo[sizeof(siginfo_t)]) Does it make sense? If yes, what would be the best way to expose this? Thanks
Re: [PATCH RESEND v5 8/8] arm64: dts: mt6359: add PMIC MT6359 related nodes
On 29/01/2021 10:49, Hsin-Hsiung Wang wrote:
> From: Wen Su
>
> add PMIC MT6359 related nodes which is for MT6779 platform
>
> Signed-off-by: Wen Su
> Signed-off-by: Hsin-Hsiung Wang
> ---
> changes since v4:
> - add pmic MT6359 support in the MT8192 evb dts.
> ---
> arch/arm64/boot/dts/mediatek/mt6359.dtsi| 298
> arch/arm64/boot/dts/mediatek/mt8192-evb.dts | 1 +
> 2 files changed, 299 insertions(+)
> create mode 100644 arch/arm64/boot/dts/mediatek/mt6359.dtsi
>
> diff --git a/arch/arm64/boot/dts/mediatek/mt6359.dtsi
> b/arch/arm64/boot/dts/mediatek/mt6359.dtsi
> new file mode 100644
> index ..4bd85e33a4c9
> --- /dev/null
> +++ b/arch/arm64/boot/dts/mediatek/mt6359.dtsi
> @@ -0,0 +1,298 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2020 MediaTek Inc.
> + */
> +
> +&pwrap {
> + pmic: pmic {
> + compatible = "mediatek,mt6359";
> + interrupt-controller;
> + #interrupt-cells = <2>;
> +
> + mt6359codec: mt6359codec {
> + };
I understand that the dmic-mode and mic-type-X depends on the actual board on
which it is used. In that case I think we should add mt6359codec node in the dts
instead of dtsi file. I'd advise to set these properties as well as otherwise we
get a (slightly misleading) warning in the driver.
I'm adding Jiaxin Yu and Tzung-Bi Shih to the thread so that they can judge if
the warning message is appropriate for a optional property.
Regards,
Matthias
> +
> + mt6359regulator: regulators {
> + mt6359_vs1_buck_reg: buck_vs1 {
> + regulator-name = "vs1";
> + regulator-min-microvolt = <80>;
> + regulator-max-microvolt = <220>;
> + regulator-enable-ramp-delay = <0>;
> + regulator-always-on;
> + };
> + mt6359_vgpu11_buck_reg: buck_vgpu11 {
> + regulator-name = "vgpu11";
> + regulator-min-microvolt = <40>;
> + regulator-max-microvolt = <1193750>;
> + regulator-ramp-delay = <5000>;
> + regulator-enable-ramp-delay = <200>;
> + regulator-allowed-modes = <0 1 2>;
> + };
> + mt6359_vmodem_buck_reg: buck_vmodem {
> + regulator-name = "vmodem";
> + regulator-min-microvolt = <40>;
> + regulator-max-microvolt = <110>;
> + regulator-ramp-delay = <10760>;
> + regulator-enable-ramp-delay = <200>;
> + };
> + mt6359_vpu_buck_reg: buck_vpu {
> + regulator-name = "vpu";
> + regulator-min-microvolt = <40>;
> + regulator-max-microvolt = <1193750>;
> + regulator-ramp-delay = <5000>;
> + regulator-enable-ramp-delay = <200>;
> + regulator-allowed-modes = <0 1 2>;
> + };
> + mt6359_vcore_buck_reg: buck_vcore {
> + regulator-name = "vcore";
> + regulator-min-microvolt = <40>;
> + regulator-max-microvolt = <130>;
> + regulator-ramp-delay = <5000>;
> + regulator-enable-ramp-delay = <200>;
> + regulator-allowed-modes = <0 1 2>;
> + };
> + mt6359_vs2_buck_reg: buck_vs2 {
> + regulator-name = "vs2";
> + regulator-min-microvolt = <80>;
> + regulator-max-microvolt = <160>;
> + regulator-enable-ramp-delay = <0>;
> + regulator-always-on;
> + };
> + mt6359_vpa_buck_reg: buck_vpa {
> + regulator-name = "vpa";
> + regulator-min-microvolt = <50>;
> + regulator-max-microvolt = <365>;
> + regulator-enable-ramp-delay = <300>;
> + };
> + mt6359_vproc2_buck_reg: buck_vproc2 {
> + regulator-name = "vproc2";
> + regulator-min-microvolt = <40>;
> + regulator-max-microvolt = <1193750>;
> + regulator-ramp-delay = <7500>;
> + regulator-enable-ramp-delay = <200>;
> + regulato
[PATCH 1/1] vsock: fix the race conditions in multi-transport support
There are multiple similar bugs implicitly introduced by the
commit c0cfa2d8a788fcf4 ("vsock: add multi-transports support") and
commit 6a2c0962105ae8ce ("vsock: prevent transport modules unloading").
The bug pattern:
[1] vsock_sock.transport pointer is copied to a local variable,
[2] lock_sock() is called,
[3] the local variable is used.
VSOCK multi-transport support introduced the race condition:
vsock_sock.transport value may change between [1] and [2].
Let's copy vsock_sock.transport pointer to local variables after
the lock_sock() call.
Signed-off-by: Alexander Popov
---
net/vmw_vsock/af_vsock.c | 17 -
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/net/vmw_vsock/af_vsock.c b/net/vmw_vsock/af_vsock.c
index d10916ab4526..28edac1f9aa6 100644
--- a/net/vmw_vsock/af_vsock.c
+++ b/net/vmw_vsock/af_vsock.c
@@ -997,9 +997,12 @@ static __poll_t vsock_poll(struct file *file, struct
socket *sock,
mask |= EPOLLOUT | EPOLLWRNORM | EPOLLWRBAND;
} else if (sock->type == SOCK_STREAM) {
- const struct vsock_transport *transport = vsk->transport;
+ const struct vsock_transport *transport = NULL;
+
lock_sock(sk);
+ transport = vsk->transport;
+
/* Listening sockets that have connections in their accept
* queue can be read.
*/
@@ -1082,10 +1085,11 @@ static int vsock_dgram_sendmsg(struct socket *sock,
struct msghdr *msg,
err = 0;
sk = sock->sk;
vsk = vsock_sk(sk);
- transport = vsk->transport;
lock_sock(sk);
+ transport = vsk->transport;
+
err = vsock_auto_bind(vsk);
if (err)
goto out;
@@ -1544,10 +1548,11 @@ static int vsock_stream_setsockopt(struct socket *sock,
err = 0;
sk = sock->sk;
vsk = vsock_sk(sk);
- transport = vsk->transport;
lock_sock(sk);
+ transport = vsk->transport;
+
switch (optname) {
case SO_VM_SOCKETS_BUFFER_SIZE:
COPY_IN(val);
@@ -1680,7 +1685,6 @@ static int vsock_stream_sendmsg(struct socket *sock,
struct msghdr *msg,
sk = sock->sk;
vsk = vsock_sk(sk);
- transport = vsk->transport;
total_written = 0;
err = 0;
@@ -1689,6 +1693,8 @@ static int vsock_stream_sendmsg(struct socket *sock,
struct msghdr *msg,
lock_sock(sk);
+ transport = vsk->transport;
+
/* Callers should not provide a destination with stream sockets. */
if (msg->msg_namelen) {
err = sk->sk_state == TCP_ESTABLISHED ? -EISCONN : -EOPNOTSUPP;
@@ -1823,11 +1829,12 @@ vsock_stream_recvmsg(struct socket *sock, struct msghdr
*msg, size_t len,
sk = sock->sk;
vsk = vsock_sk(sk);
- transport = vsk->transport;
err = 0;
lock_sock(sk);
+ transport = vsk->transport;
+
if (!transport || sk->sk_state != TCP_ESTABLISHED) {
/* Recvmsg is supposed to return 0 if a peer performs an
* orderly shutdown. Differentiate between that case and when a
--
2.26.2
Re: [RFC 03/20] mm/mprotect: do not flush on permission promotion
On 31/01/2021 02:59, Andy Lutomirski wrote:
diff --git a/arch/x86/include/asm/tlbflush.h
b/arch/x86/include/asm/tlbflush.h
index 8c87a2e0b660..a617dc0a9b06 100644
--- a/arch/x86/include/asm/tlbflush.h
+++ b/arch/x86/include/asm/tlbflush.h
@@ -255,6 +255,50 @@ static inline void arch_tlbbatch_add_mm(struct
arch_tlbflush_unmap_batch *batch,
extern void arch_tlbbatch_flush(struct arch_tlbflush_unmap_batch *batch);
+static inline bool pte_may_need_flush(pte_t oldpte, pte_t newpte)
+{
+ const pteval_t ignore_mask = _PAGE_SOFTW1 | _PAGE_SOFTW2 |
+_PAGE_SOFTW3 | _PAGE_ACCESSED;
>>> Why is accessed ignored? Surely clearing the accessed bit needs a
>>> flush if the old PTE is present.
>> I am just following the current scheme in the kernel (x86):
>>
>> int ptep_clear_flush_young(struct vm_area_struct *vma,
>>unsigned long address, pte_t *ptep)
>> {
>> /*
>> * On x86 CPUs, clearing the accessed bit without a TLB flush
>> * doesn't cause data corruption. [ It could cause incorrect
>> * page aging and the (mistaken) reclaim of hot pages, but the
>> * chance of that should be relatively low. ]
>> *
> If anyone ever implements the optimization of skipping the flush when
> unmapping a !accessed page, then this will cause data corruption.
>
> If nothing else, this deserves a nice comment in the new code.
Architecturally, access bits get as part of a pagewalk, and before the
TLB entry is made. Once an access bit has been set, you know for
certain that a mapping for the address is, or was, present in a TLB
somewhere.
I can't help but feel that this "optimisation" is shooting itself in the
foot. It does cause incorrect page aging, and TLBs are getting bigger,
so the chance of reclamating hot pages is getting worse and worse.
~Andrew
[PATCH] ARM: dts: imx6qdl-wandboard: add scl/sda gpios definitions for i2c bus recovery
The i2c bus on imx6qdl-wandboard has intermittent issues where SDA can freeze
on low level at the end of transaction so the bus can no longer work. This
impacts reading of EDID data leading to incorrect TV resolution and no audio.
This scenario is improved by adding scl/sda gpios definitions to implement the
i2c bus recovery mechanism.
Signed-off-by: Dima Azarkin
---
arch/arm/boot/dts/imx6qdl-wandboard.dtsi | 24 ++--
1 file changed, 22 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/imx6qdl-wandboard.dtsi
b/arch/arm/boot/dts/imx6qdl-wandboard.dtsi
index c070893c509e..b62a0dbb033f 100644
--- a/arch/arm/boot/dts/imx6qdl-wandboard.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-wandboard.dtsi
@@ -97,15 +97,21 @@
&i2c1 {
clock-frequency = <10>;
- pinctrl-names = "default";
+ pinctrl-names = "default", "gpio";
pinctrl-0 = <&pinctrl_i2c1>;
+ pinctrl-1 = <&pinctrl_i2c1_gpio>;
+ scl-gpios = <&gpio3 21 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ sda-gpios = <&gpio3 28 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
status = "okay";
};
&i2c2 {
clock-frequency = <10>;
- pinctrl-names = "default";
+ pinctrl-names = "default", "gpio";
pinctrl-0 = <&pinctrl_i2c2>;
+ pinctrl-1 = <&pinctrl_i2c2_gpio>;
+ scl-gpios = <&gpio4 12 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ sda-gpios = <&gpio4 13 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
status = "okay";
codec: sgtl5000@a {
@@ -185,6 +191,13 @@
>;
};
+ pinctrl_i2c1_gpio: i2c1gpiogrp {
+ fsl,pins = <
+ MX6QDL_PAD_EIM_D21__GPIO3_IO21
0x4001b8b0
+ MX6QDL_PAD_EIM_D28__GPIO3_IO28
0x4001b8b0
+ >;
+ };
+
pinctrl_i2c2: i2c2grp {
fsl,pins = <
MX6QDL_PAD_KEY_COL3__I2C2_SCL
0x4001b8b1
@@ -192,6 +205,13 @@
>;
};
+ pinctrl_i2c2_gpio: i2c2gpiogrp {
+ fsl,pins = <
+ MX6QDL_PAD_KEY_COL3__GPIO4_IO12
0x4001b8b0
+ MX6QDL_PAD_KEY_ROW3__GPIO4_IO13
0x4001b8b0
+ >;
+ };
+
pinctrl_mclk: mclkgrp {
fsl,pins = <
MX6QDL_PAD_GPIO_0__CCM_CLKO10x130b0
--
2.17.1
Re: [PATCH v13 1/8] arm64: dts: mt8183: rename rdma fifo size
Hi Hsin-Yi,
On 29/01/2021 10:22, Hsin-Yi Wang wrote:
> From: Yongqiang Niu
>
> property name must include only lowercase and '-'
>
> Fixes: 91f9c963ce79 ("arm64: dts: mt8183: Add display nodes for MT8183")
> Signed-off-by: Yongqiang Niu
> Signed-off-by: Hsin-Yi Wang
> Reviewed-by: Chun-Kuang Hu
> Reviewed-by: Enric Balletbo i Serra
> ---
I applied 1/8 and 2/8 already, so please drop them for v14.
Thanks,
Matthias
> arch/arm64/boot/dts/mediatek/mt8183.dtsi | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> index 5b782a4769e7e..6c84ccb709af6 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> @@ -1011,7 +1011,7 @@ rdma0: rdma@1400b000 {
> clocks = <&mmsys CLK_MM_DISP_RDMA0>;
> iommus = <&iommu M4U_PORT_DISP_RDMA0>;
> mediatek,larb = <&larb0>;
> - mediatek,rdma_fifo_size = <5120>;
> + mediatek,rdma-fifo-size = <5120>;
> mediatek,gce-client-reg = <&gce SUBSYS_1400 0xb000
> 0x1000>;
> };
>
> @@ -1023,7 +1023,7 @@ rdma1: rdma@1400c000 {
> clocks = <&mmsys CLK_MM_DISP_RDMA1>;
> iommus = <&iommu M4U_PORT_DISP_RDMA1>;
> mediatek,larb = <&larb0>;
> - mediatek,rdma_fifo_size = <2048>;
> + mediatek,rdma-fifo-size = <2048>;
> mediatek,gce-client-reg = <&gce SUBSYS_1400 0xc000
> 0x1000>;
> };
>
>
[GIT PULL] efi/urgent for v5.11-rc6
Hi Linus, please pull a (forwarded) single EFI urgent fix for v5.11-rc6. Thx. --- The following changes since commit 5c8fe583cce542aa0b84adc939ce85293de36e5e: Linux 5.11-rc1 (2020-12-27 15:30:22 -0800) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git tags/efi-urgent-for-v5.11 for you to fetch changes up to 355845b738e76445c8522802552146d96cb4afa7: efi/apple-properties: Reinstate support for boolean properties (2020-12-31 10:28:53 +0100) A single EFI fix from Lukas: - handle boolean device properties imported from Apple firmware correctly. Lukas Wunner (1): efi/apple-properties: Reinstate support for boolean properties drivers/firmware/efi/apple-properties.c | 13 + 1 file changed, 9 insertions(+), 4 deletions(-) -- Regards/Gruss, Boris. SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer, HRB 36809, AG Nürnberg
Re: [PATCH v1] arm64: dts: mt8192: add nor_flash device node
On 31/01/2021 11:26, Matthias Brugger wrote:
>
>
> On 10/12/2020 09:34, Bayi Cheng wrote:
>> From: bayi cheng
>>
>> add nor_flash device node
>>
>> Signed-off-by: bayi cheng
>> ---
>> arch/arm64/boot/dts/mediatek/mt8192.dtsi | 13 +
>> 1 file changed, 13 insertions(+)
>>
>
> Applied to v5.11-next/dts64
reverted and replaced with v2.
Thanks!
>
> Thanks
>
>> diff --git a/arch/arm64/boot/dts/mediatek/mt8192.dtsi
>> b/arch/arm64/boot/dts/mediatek/mt8192.dtsi
>> index e12e024..b15b0d3 100644
>> --- a/arch/arm64/boot/dts/mediatek/mt8192.dtsi
>> +++ b/arch/arm64/boot/dts/mediatek/mt8192.dtsi
>> @@ -379,6 +379,19 @@
>> status = "disabled";
>> };
>>
>> +nor_flash: spi@11234000 {
>> +compatible = "mediatek,mt8173-nor";
>> +reg = <0 0x11234000 0 0xe0>;
>> +interrupts = ;
>> +clocks = <&clk26m>,
>> + <&clk26m>,
>> + <&clk26m>;
>> +clock-names = "spi", "sf", "axi";
>> +#address-cells = <1>;
>> +#size-cells = <0>;
>> +status = "disable";
>> +};
>> +
>> i2c3: i2c3@11cb {
>> compatible = "mediatek,mt8192-i2c";
>> reg = <0 0x11cb 0 0x1000>,
>>
Re: [PATCH v3 net-next 3/5] net: introduce common dev_page_is_reusable()
On Sun, Jan 31, 2021 at 12:11:52PM +, Alexander Lobakin wrote:
> A bunch of drivers test the page before reusing/recycling for two
> common conditions:
> - if a page was allocated under memory pressure (pfmemalloc page);
> - if a page was allocated at a distant memory node (to exclude
>slowdowns).
>
> Introduce a new common inline for doing this, with likely() already
> folded inside to make driver code a bit simpler.
I don't see the need for the 'dev_' prefix. That actually confuses me
because it makes me think this is tied to ZONE_DEVICE or some such.
So how about calling it just 'page_is_reusable' and putting it in mm.h
with page_is_pfmemalloc() and making the comment a little less network-centric?
Or call it something like skb_page_is_recyclable() since it's only used
by networking today. But I bet it could/should be used more widely.
> +/**
> + * dev_page_is_reusable - check whether a page can be reused for network Rx
> + * @page: the page to test
> + *
> + * A page shouldn't be considered for reusing/recycling if it was allocated
> + * under memory pressure or at a distant memory node.
> + *
> + * Returns false if this page should be returned to page allocator, true
> + * otherwise.
> + */
> +static inline bool dev_page_is_reusable(const struct page *page)
> +{
> + return likely(page_to_nid(page) == numa_mem_id() &&
> + !page_is_pfmemalloc(page));
> +}
> +
Re: [PATCH 3/3] iio: proximity: Add a ChromeOS EC MKBP proximity driver
...
> > > > > > +static const struct of_device_id cros_ec_proximity_of_match[] = {
> > > > > > + { .compatible = "google,cros-ec-proximity" },
> > > > > > + {}
> > > > > > +};
> > > > > > +MODULE_DEVICE_TABLE(of, cros_ec_proximity_of_match);
> > > > > > +#endif
> > > > > > +
> > > > > > +static struct platform_driver cros_ec_proximity_driver = {
> > > > > > + .driver = {
> > > > > > + .name = "cros-ec-proximity",
> > > > > > + .of_match_table =
> > > > > > of_match_ptr(cros_ec_proximity_of_match),
> > > > Add a ACPI match table to match.
> > >
> > > I don't have an ACPI system in hand. What should the ACPI table look
> > > like? Can ACPI use the of_match_table logic?
> > AFAIK, ACPI uses .acpi_match_table, see
> > drivers/iio/magnetometer/ak8975.c for a simple example.
>
> Ok. I'm leaning towards punting on this. I don't have an ACPI system to
> test and I don't know what the ACPI match table should have in it. If
> you can tell me what to put in the acpi_match_table then I can add it.
Unless we have a known ACPI ID don't add support. We let a few of those
in in the past, (mostly because I didn't know better) and they are a pain
to clean up, particularly as there may be platforms that started using
them because the Linux driver supported them.
Jonathan
Re: [PATCH 2/3] hid-sensor-common: Add relative sensitivity check
On Fri, 29 Jan 2021 00:35:49 +0800
"Ye, Xiang" wrote:
> Hi Srinivas andd Jonathan
>
> Thanks for the review.
>
> On Sun, Jan 24, 2021 at 08:20:12AM -0800, Srinivas Pandruvada wrote:
> > On Sun, 2021-01-24 at 13:14 +, Jonathan Cameron wrote:
> > > On Wed, 20 Jan 2021 15:47:05 +0800
> > > Ye Xiang wrote:
> > >
> > > > Some hid sensors may use relative sensitivity such as als sensor.
> > > > This patch add relative sensitivity check for all hid-sensors.
> > > >
> > > > Signed-off-by: Ye Xiang
> > > > ---
> > > > .../iio/common/hid-sensors/hid-sensor-attributes.c| 11
> > > > ++-
> > > > include/linux/hid-sensor-ids.h| 1 +
> > > > 2 files changed, 11 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/iio/common/hid-sensors/hid-sensor-attributes.c
> > > > b/drivers/iio/common/hid-sensors/hid-sensor-attributes.c
> > > > index d349ace2e33f..b685c292a179 100644
> > > > --- a/drivers/iio/common/hid-sensors/hid-sensor-attributes.c
> > > > +++ b/drivers/iio/common/hid-sensors/hid-sensor-attributes.c
> > > > @@ -480,7 +480,7 @@ int hid_sensor_parse_common_attributes(struct
> > > > hid_sensor_hub_device *hsdev,
> > > >
> > > > /*
> > > > * Set Sensitivity field ids, when there is no individual
> > > > modifier, will
> > > > -* check absolute sensitivity of data field
> > > > +* check absolute sensitivity and relative sensitivity of data
> > > > field
> > > > */
> > > > for (i = 0; i < sensitivity_addresses_len && st-
> > > > >sensitivity.index < 0; i++) {
> > > > sensor_hub_input_get_attribute_info(hsdev,
> > > > @@ -488,6 +488,15 @@ int hid_sensor_parse_common_attributes(struct
> > > > hid_sensor_hub_device *hsdev,
> > > > HID_USAGE_SENSOR_DATA_MOD_CHANGE_SENSIT
> > > > IVITY_ABS |
> > > > sensitivity_addresses[i],
> > > > &st->sensitivity);
> > > > +
> > > > + if (st->sensitivity.index >= 0)
> > > > + break;
> > > > +
> > > > + sensor_hub_input_get_attribute_info(hsdev,
> > > > + HID_FEATURE_REPORT, usage_id,
> > > > + HID_USAGE_SENSOR_DATA_MOD_CHANGE_SENSIT
> > > > IVITY_REL_PCT |
> > > > + sensitivity_addresses[i],
> > > > + &st->sensitivity);
> > >
> > > We can't provide the value to userspace without reflecting the
> > > difference between
> > > the two ways of expressing it.
> > >
> > > It seems there are 3 ways sensitivity is expressed.
> > > 1. Raw value in same units as the measurement (easy one and what is
> > > currently reported)
> > > 2. Percentage of range - also relatively easy to transform into the
> > > same as 1.
> > > 3. Percentage of prior reading.. This one doesn't fit in any
> > > existing ABI, so
> > >unfortunately we'll have to invent something new along the lines
> > > of
> > >*_hysteresis_relative
>
> yes, the 3th version sensitivity (Percentage of prior reading) is what we
> are using for als sensor now. the 1th version sensitivity is common used
> by other hid sensors. Do you have suggestion or reference about
> how to add *_hysteresis_relative field to iio model?
Follow through how elements of iio_chan_info_enum in
include/linux/iio/types.h are used and you should see how to add a new
one (basically add an entry to that and also the string to the
right array in industrialio-core.c + document it in
Documentation/ABI/testing/sysfs-bus-iio.
The issue with putting this in is we are going to be 'fixing' the ABI for
that ALS sensor which is going to cause problems for any userspace users
of that interface... I have no idea how commonly this is used, but it is
possible we'll have to leave that one as incorrect :(
>
> >
> > This is why it was not added before when I developed. But later few
> > years back there was a patch to add this by one of our developer. There
> > was some discussion, I thought it was decided it is OK to add.
> >
> > But I agree, we should add new ABI as you suggested. Now almost every
> > laptop has HID sensors, better to address this.
> >
>
> I think the add relative hystersis patch should be separated into a
> independent
> patch series, for it's a independent function and need more effort for coding
> and
> testing. And I can submit the other two patch in this patch series first.
Sure, if they are independent that should be fine.
Thanks,
Jonathan
>
> > >
> > >
> > >
> > > > }
> > > >
> > > > st->raw_hystersis = -1;
> > > > diff --git a/include/linux/hid-sensor-ids.h b/include/linux/hid-
> > > > sensor-ids.h
> > > > index 3bbdbccc5805..ac631159403a 100644
> > > > --- a/include/linux/hid-sensor-ids.h
> > > > +++ b/include/linux/hid-sensor-ids.h
> > > > @@ -149,6 +149,7 @@
> > > > /* Per data f
[PATCH v3 net-next 5/5] net: page_pool: simplify page recycling condition tests
pool_page_reusable() is a leftover from pre-NUMA-aware times. For now,
this function is just a redundant wrapper over page_is_pfmemalloc(),
so inline it into its sole call site.
Signed-off-by: Alexander Lobakin
Acked-by: Jesper Dangaard Brouer
Reviewed-by: Ilias Apalodimas
Reviewed-by: Jesse Brandeburg
Acked-by: David Rientjes
---
net/core/page_pool.c | 14 --
1 file changed, 4 insertions(+), 10 deletions(-)
diff --git a/net/core/page_pool.c b/net/core/page_pool.c
index f3c690b8c8e3..ad8b0707af04 100644
--- a/net/core/page_pool.c
+++ b/net/core/page_pool.c
@@ -350,14 +350,6 @@ static bool page_pool_recycle_in_cache(struct page *page,
return true;
}
-/* page is NOT reusable when:
- * 1) allocated when system is under some pressure. (page_is_pfmemalloc)
- */
-static bool pool_page_reusable(struct page_pool *pool, struct page *page)
-{
- return !page_is_pfmemalloc(page);
-}
-
/* If the page refcnt == 1, this will try to recycle the page.
* if PP_FLAG_DMA_SYNC_DEV is set, we'll try to sync the DMA area for
* the configured size min(dma_sync_size, pool->max_len).
@@ -373,9 +365,11 @@ __page_pool_put_page(struct page_pool *pool, struct page
*page,
* regular page allocator APIs.
*
* refcnt == 1 means page_pool owns page, and can recycle it.
+*
+* page is NOT reusable when allocated when system is under
+* some pressure. (page_is_pfmemalloc)
*/
- if (likely(page_ref_count(page) == 1 &&
- pool_page_reusable(pool, page))) {
+ if (likely(page_ref_count(page) == 1 && !page_is_pfmemalloc(page))) {
/* Read barrier done in page_ref_count / READ_ONCE */
if (pool->p.flags & PP_FLAG_DMA_SYNC_DEV)
--
2.30.0
Re: [PATCH] iio: fix typo
On Thu, 28 Jan 2021 10:19:05 +0800
zuoqil...@163.com wrote:
> From: zuoqilin
>
> change 'regster' to 'register'
>
> Signed-off-by: zuoqilin
Applied.
thanks,
Jonathan
> ---
> drivers/iio/dac/ad5791.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/iio/dac/ad5791.c b/drivers/iio/dac/ad5791.c
> index e3ffa4b..615d72c 100644
> --- a/drivers/iio/dac/ad5791.c
> +++ b/drivers/iio/dac/ad5791.c
> @@ -76,7 +76,7 @@ struct ad5791_chip_info {
> * @chip_info: chip model specific constants
> * @vref_mv: actual reference voltage used
> * @vref_neg_mv: voltage of the negative supply
> - * @ctrl:control regster cache
> + * @ctrl:control register cache
> * @pwr_down_mode: current power down mode
> * @pwr_down:true if device is powered down
> * @data:spi transfer buffers
Re: [PATCH v8 2/2] iio: accel: Add support for the Bosch-Sensortec BMI088
On Mon, 25 Jan 2021 16:07:32 +0100
Mike Looijmans wrote:
> The BMI088 is a combined module with both accelerometer and gyroscope.
> This adds the accelerometer driver support for the SPI interface.
> The gyroscope part is already supported by the BMG160 driver.
>
> Signed-off-by: Mike Looijmans
Hi Mike,
I'll drop the include as no acpi stuff in
here that I can see.
Otherwise, looks good to me. Will give a bit of time for Rob or
anyone else to take another look at this and the binding patch.
Thanks,
Jonathan
>
> ---
>
> Changes in v8:
> include order asm/ after linux/
> Suspend/resume redesigned, use runtime PM for both cases. Removed the
> pm wrappers and let runtime PM handle power up/down. This also removed
> the need for an internal mutex, thus reducing code further.
>
> Changes in v7:
> Change bmi088_accel to bmi088-accel
> Order includes alphabetically
> Suspend and disable on remove
> Make bmi088_regmap_spi_{read|write} static
>
> Changes in v6:
> Hope you have good memory - v5 was almost a year ago now
> Remove superfluous *val=0
> Make sample_frequency selection into read_avail list
>
> Changes in v5:
> Add includes and forward defines in header
> BIT(7) instead of 0x80
> Reset already sets defaults, do not set them again
> Remove now unused bmi088_accel_set_bw
> Remove unused AXIS_MAX
> Use MASK define for ODR setting
> Explain buffer use and alignment
> Split bmi088_accel_set_power_state into "on" and "off" parts
> Cosmetic changes to improve readability
>
> Changes in v4:
> Remove unused #include directives
> Remove unused #defines for event and irq
> Replace (ret < 0) with (ret) for all regmap calls
> Consistent checking of IO errors in probe and init
> Removed #ifdef CONFIG_PM guard
> Use bitops for set_frequency instead of loop with shift
> s/__s16/s16/g
> Remove excess blank lines
> Don't return -EAGAIN in pm_runtime
>
> Changes in v3:
> Processed comments from Jonathan Cameron and Lars-Peter Clausen
> implement runtime PM (tested by code tracing) and sleep
> fix scale and offset factors for accel and temperature and
> return raw values instead of pre-scaled ones
> Use iio_device_{claim,release}_direct_mode
> Remove unused code and structs
> Use a cache-aligned buffer for bulk read
> Configure and enable caching register values
>
> Changes in v2:
> Remove unused typedefs and variables
> Fix error return when iio_device_register fails
>
> drivers/iio/accel/Kconfig | 18 +
> drivers/iio/accel/Makefile| 2 +
> drivers/iio/accel/bmi088-accel-core.c | 570 ++
> drivers/iio/accel/bmi088-accel-spi.c | 83
> drivers/iio/accel/bmi088-accel.h | 18 +
> 5 files changed, 691 insertions(+)
> create mode 100644 drivers/iio/accel/bmi088-accel-core.c
> create mode 100644 drivers/iio/accel/bmi088-accel-spi.c
> create mode 100644 drivers/iio/accel/bmi088-accel.h
>
> diff --git a/drivers/iio/accel/Kconfig b/drivers/iio/accel/Kconfig
> index 2e0c62c39155..cceda3cecbcf 100644
> --- a/drivers/iio/accel/Kconfig
> +++ b/drivers/iio/accel/Kconfig
> @@ -157,6 +157,24 @@ config BMC150_ACCEL_SPI
> tristate
> select REGMAP_SPI
>
> +config BMI088_ACCEL
> + tristate "Bosch BMI088 Accelerometer Driver"
> + depends on SPI
> + select IIO_BUFFER
> + select IIO_TRIGGERED_BUFFER
> + select REGMAP
> + select BMI088_ACCEL_SPI
> + help
> + Say yes here to build support for the Bosch BMI088 accelerometer.
> +
> + This is a combo module with both accelerometer and gyroscope. This
> + driver only implements the accelerometer part, which has its own
> + address and register map. BMG160 provides the gyroscope driver.
> +
> +config BMI088_ACCEL_SPI
> + tristate
> + select REGMAP_SPI
> +
> config DA280
> tristate "MiraMEMS DA280 3-axis 14-bit digital accelerometer driver"
> depends on I2C
> diff --git a/drivers/iio/accel/Makefile b/drivers/iio/accel/Makefile
> index 4f6c1ebe13b0..32cd1342a31a 100644
> --- a/drivers/iio/accel/Makefile
> +++ b/drivers/iio/accel/Makefile
> @@ -20,6 +20,8 @@ obj-$(CONFIG_BMA400_SPI) += bma400_spi.o
> obj-$(CONFIG_BMC150_ACCEL) += bmc150-accel-core.o
> obj-$(CONFIG_BMC150_ACCEL_I2C) += bmc150-accel-i2c.o
> obj-$(CONFIG_BMC150_ACCEL_SPI) += bmc150-accel-spi.o
> +obj-$(CONFIG_BMI088_ACCEL) += bmi088-accel-core.o
> +obj-$(CONFIG_BMI088_ACCEL_SPI) += bmi088-accel-spi.o
> obj-$(CONFIG_DA280) += da280.o
> obj-$(CONFIG_DA311) += da311.o
> obj-$(CONFIG_DMARD06)+= dmard06.o
> diff --git a/drivers/iio/accel/bmi088-accel-core.c
> b/drivers/iio/accel/bmi088-accel-core.c
> new file mode 100644
> index ..f86010a3cda3
> --- /dev/null
> +++ b/drivers/iio/accel/bmi088-accel-core.c
> @@ -0,0 +1,570 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * 3-axis accelerometer driver supporting following Bosch-Sensortec chips:
> + * - BMI088
> + *
> + * Copyright (c) 2018-2021, Topic Embedded Products
> + */
> +
> +#include
Why
Re: [PATCH v3 net-next 1/5] mm: constify page_is_pfmemalloc() argument
On Sun, Jan 31, 2021 at 12:11:30PM +, Alexander Lobakin wrote: > The function only tests for page->index, so its argument should be > const. > > Signed-off-by: Alexander Lobakin > Reviewed-by: Jesse Brandeburg > Acked-by: David Rientjes Reviewed-by: Matthew Wilcox (Oracle)
[GIT pull] core/urgent for v5.11-rc6
Linus,
please pull the latest core/urgent branch from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
core-urgent-2021-01-31
up to: 41c1a06d1d15: entry: Unbreak single step reporting behaviour
A single fix for the single step reporting regression caused by getting the
condition wrong when moving SYSCALL_EMU away from TIF flags.
Thanks,
tglx
-->
Yuxuan Shui (1):
entry: Unbreak single step reporting behaviour
kernel/entry/common.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/entry/common.c b/kernel/entry/common.c
index 378341642f94..6dd82be60df8 100644
--- a/kernel/entry/common.c
+++ b/kernel/entry/common.c
@@ -222,7 +222,7 @@ static inline bool report_single_step(unsigned long work)
*/
static inline bool report_single_step(unsigned long work)
{
- if (!(work & SYSCALL_WORK_SYSCALL_EMU))
+ if (work & SYSCALL_WORK_SYSCALL_EMU)
return false;
return !!(current_thread_info()->flags & _TIF_SINGLESTEP);
[GIT pull] timers/urgent for v5.11-rc6
Linus,
please pull the latest timers/urgent branch from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
timers-urgent-2021-01-31
up to: 211e5db19d15: rtc: mc146818: Detect and handle broken RTCs
A fix for handling advertised, but non-existent 146818 RTCs correctly. With
the recent UIP handling changes the time readout of non-existent RTCs hangs
forever as the read returns always 0xFF which means the UIP bit is
set. Sanity check the RTC before registering by checking the RTC_VALID
register for correctness.
Thanks,
tglx
-->
Thomas Gleixner (1):
rtc: mc146818: Detect and handle broken RTCs
drivers/rtc/rtc-cmos.c | 8
drivers/rtc/rtc-mc146818-lib.c | 7 +++
2 files changed, 15 insertions(+)
diff --git a/drivers/rtc/rtc-cmos.c b/drivers/rtc/rtc-cmos.c
index 51e80bc70d42..68a9ac6f2fe1 100644
--- a/drivers/rtc/rtc-cmos.c
+++ b/drivers/rtc/rtc-cmos.c
@@ -805,6 +805,14 @@ cmos_do_probe(struct device *dev, struct resource *ports,
int rtc_irq)
spin_lock_irq(&rtc_lock);
+ /* Ensure that the RTC is accessible. Bit 0-6 must be 0! */
+ if ((CMOS_READ(RTC_VALID) & 0x7f) != 0) {
+ spin_unlock_irq(&rtc_lock);
+ dev_warn(dev, "not accessible\n");
+ retval = -ENXIO;
+ goto cleanup1;
+ }
+
if (!(flags & CMOS_RTC_FLAGS_NOFREQ)) {
/* force periodic irq to CMOS reset default of 1024Hz;
*
diff --git a/drivers/rtc/rtc-mc146818-lib.c b/drivers/rtc/rtc-mc146818-lib.c
index 972a5b9a629d..f83c13818af3 100644
--- a/drivers/rtc/rtc-mc146818-lib.c
+++ b/drivers/rtc/rtc-mc146818-lib.c
@@ -21,6 +21,13 @@ unsigned int mc146818_get_time(struct rtc_time *time)
again:
spin_lock_irqsave(&rtc_lock, flags);
+ /* Ensure that the RTC is accessible. Bit 0-6 must be 0! */
+ if (WARN_ON_ONCE((CMOS_READ(RTC_VALID) & 0x7f) != 0)) {
+ spin_unlock_irqrestore(&rtc_lock, flags);
+ memset(time, 0xff, sizeof(*time));
+ return 0;
+ }
+
/*
* Check whether there is an update in progress during which the
* readout is unspecified. The maximum update time is ~2ms. Poll
Re: [PATCH 1/3] MIPS: ftrace: Fix N32 save registers
On Sun, Jan 31, 2021, at 4:14 PM, Jinyang He wrote: > CONFIG_64BIT is confusing. N32 also pass parameters by a0~a7. Do we have NEW kernel build? CONFIG_64BIT assumed N64 as kernel ABI. -Jiaxun > > Signed-off-by: Jinyang He > --- > arch/mips/kernel/mcount.S | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/arch/mips/kernel/mcount.S b/arch/mips/kernel/mcount.S > index cff52b2..808257a 100644 > --- a/arch/mips/kernel/mcount.S > +++ b/arch/mips/kernel/mcount.S > @@ -27,7 +27,7 @@ > PTR_S a1, PT_R5(sp) > PTR_S a2, PT_R6(sp) > PTR_S a3, PT_R7(sp) > -#ifdef CONFIG_64BIT > +#if _MIPS_SIM == _MIPS_SIM_ABI64 || _MIPS_SIM == _MIPS_SIM_NABI32 > PTR_S a4, PT_R8(sp) > PTR_S a5, PT_R9(sp) > PTR_S a6, PT_R10(sp) > @@ -42,7 +42,7 @@ > PTR_L a1, PT_R5(sp) > PTR_L a2, PT_R6(sp) > PTR_L a3, PT_R7(sp) > -#ifdef CONFIG_64BIT > +#if _MIPS_SIM == _MIPS_SIM_ABI64 || _MIPS_SIM == _MIPS_SIM_NABI32 > PTR_L a4, PT_R8(sp) > PTR_L a5, PT_R9(sp) > PTR_L a6, PT_R10(sp) > -- > 2.1.0 > > -- - Jiaxun
Re: [PATCH v10] cpufreq: mediatek-hw: Add support for Mediatek cpufreq HW driver
On 29/12/2020 07:17, Hector Yuan wrote: > The CPUfreq HW present in some Mediatek chipsets offloads the steps necessary > for changing the frequency of CPUs. > The driver implements the cpufreq driver interface for this hardware engine. > This patch depends on MT6779 DTS patchset[1] submitted by Hanks Chen. This dependency got resolved, the patch is mainline since v5.11. Please delete it in further revisions of the patch set to minimize confusion. Thanks! > > From v8 to v9, there are three more modifications. > 1. Based on patchset[2], align binding with scmi for performance domain. > 2. Add the CPUFREQ fast switch function support and define DVFS latency. > 3. Based on patchser[3], add energy model API parameter for mW. > > From v7 to v8, there are three more patches based on patchset v8[4]. > This patchset is about to register power table to Energy model for EAS and > thermal usage. > 1. EM CPU power table > - Register energy model table for EAS and thermal cooling device usage. > - Read the coresponding LUT for power table. > 2. SVS initialization > - The SVS(Smart Voltage Scaling) engine is a hardware which is > used to calculate optimized voltage values for CPU power domain. > DVFS driver could apply those optimized voltage values to reduce power > consumption. > - Driver will polling if HW engine is done for SVS initialization. > After that, driver will read power table and register it to EAS. > - CPUs must be in power on state when doing SVS. Use pm_qos to block cpu-idle > state for SVS initializing. > 3. Cooling device flag > - Add cooling device flag for thermal > > [1] https://lkml.org/lkml/2020/8/4/1094 > [2] > https://lore.kernel.org/lkml/20201116181356.804590-1-sudeep.ho...@arm.com/ > [3] > https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git/commit/?h=linux-next&id=c250d50fe2ce627ca9805d9c8ac11cbbf922a4a6 > [4] https://lkml.org/lkml/2020/9/23/384 > > > Hector.Yuan (2): > cpufreq: mediatek-hw: Add support for CPUFREQ HW > dt-bindings: cpufreq: add bindings for MediaTek cpufreq HW > > .../bindings/cpufreq/cpufreq-mediatek-hw.yaml | 116 ++ > drivers/cpufreq/Kconfig.arm| 12 + > drivers/cpufreq/Makefile |1 + > drivers/cpufreq/mediatek-cpufreq-hw.c | 370 > > 4 files changed, 499 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek-hw.yaml > create mode 100644 drivers/cpufreq/mediatek-cpufreq-hw.c >
Re: [PATCH v8 00/14] Move Hisilicon 6421v600 SPMI and USB drivers out of staging
On Fri, Jan 29, 2021 at 08:51:46PM +0100, Mauro Carvalho Chehab wrote: > Hi Greg/Mark/Lee/Vinod, > > Another rebase , also the top of staging-testing. > > This series contain the remaining patches for USB to start working, > except for a final DTS patch. > > Patches 1 and 2 convert the SPMI and regulator > drivers to use regmap and simplifies the logic by using > regmap helpers. > > Patches 3 to 9 address some issues pointed by Lee at the MFD driver. > > I guess the best would be if Greg could apply patches 1 to 9 > via the staging tree. I've taken these first 9 patches in my staging tree. If any other subsystem maintainer wants to ack the move of the files out of staging to their respective subsystems, I'll gladly apply those patches here as well. thanks, greg k-h
Re: [PATCH v3 2/3] dt-bindings: iio: Add cros ec proximity yaml doc
On Thu, 28 Jan 2021 09:11:32 -0800
Stephen Boyd wrote:
> Quoting Enric Balletbo Serra (2021-01-28 01:44:23)
> > Missatge de Stephen Boyd del dia dj., 28 de gen.
> > 2021 a les 9:45:
> > > +
> > > + label:
> > > +description: Name for proximity sensor
> > > +
> > > +required:
> > > + - compatible
> > > +
> > > +unevaluatedProperties: false
> > > +additionalProperties: false
> > > +
> > > +examples:
> > > + - |
> >
> > For this kind of devices it is preferred to see a complete example
> > rather than pieces spread around different yaml. This helps proper
> > binding parsing.
> >
> > spi0 {
> > #address-cells = <1>;
> > #size-cells = <0>;
> >
> > cros_ec: ec@0 {
> > compatible = "google,cros-ec-spi";
> > reg = <0>;
>
> What if it isn't on spi bus though? I'd rather leave it as is and let
> the google,cros-ec.yaml binding indicate that it is a child of the EC
> node.
It's an example. So definitely doesn't rule out other options than spi.
I think I'd also prefer to see the full example here to exercise more
of the relevant bindings when doing tests.
Mind you this is Rob's area, so I'll defer to Rob for preference.
@Rob?
>
> >
> > > +proximity {
> > > +compatible = "google,cros-ec-mkbp-proximity";
> > > +label = "proximity-wifi-lte";
> > > +};
> > > diff --git a/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml
> > > b/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml
> > > index 76bf16ee27ec..479a9f15de32 100644
> > > --- a/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml
> > > +++ b/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml
> > > @@ -94,6 +94,9 @@ properties:
> > >keyboard-controller:
> > > $ref: "/schemas/input/google,cros-ec-keyb.yaml#"
> > >
> > > + proximity:
> > > +$ref: "/schemas/iio/proximity/google,cros-ec-mkbp-proximity.yaml#"
> > > +
> > >codecs:
> > > type: object
> > > additionalProperties: false
Re: [PATCH v3 net-next 5/5] net: page_pool: simplify page recycling condition tests
On Sun, Jan 31, 2021 at 12:12:11PM +, Alexander Lobakin wrote:
> pool_page_reusable() is a leftover from pre-NUMA-aware times. For now,
> this function is just a redundant wrapper over page_is_pfmemalloc(),
> so inline it into its sole call site.
Why doesn't this want to use {dev_}page_is_reusable()?
drivers/usb/host/fhci-hcd.c:59:16: sparse: sparse: cast to restricted __be16
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 6642d600b541b81931fb1ab0c041b0d68f77be7e commit: 5a35435ef4e6e4bd2aabd6706b146b298a9cffe5 soc: fsl: qe: remove PPC32 dependency from CONFIG_QUICC_ENGINE date: 1 year, 2 months ago config: powerpc-randconfig-s031-20210131 (attached as .config) compiler: powerpc64-linux-gcc (GCC) 9.3.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # apt-get install sparse # sparse version: v0.6.3-215-g0fb77bb6-dirty # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5a35435ef4e6e4bd2aabd6706b146b298a9cffe5 git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout 5a35435ef4e6e4bd2aabd6706b146b298a9cffe5 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=powerpc If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot "sparse warnings: (new ones prefixed by >>)" drivers/usb/host/fhci-hcd.c:39:23: sparse: sparse: incorrect type in argument 1 (different base types) @@ expected unsigned short volatile [noderef] [usertype] *addr @@ got restricted __be16 [noderef] * @@ drivers/usb/host/fhci-hcd.c:39:23: sparse: expected unsigned short volatile [noderef] [usertype] *addr drivers/usb/host/fhci-hcd.c:39:23: sparse: got restricted __be16 [noderef] * drivers/usb/host/fhci-hcd.c:41:23: sparse: sparse: incorrect type in argument 1 (different base types) @@ expected unsigned short volatile [noderef] [usertype] *addr @@ got restricted __be16 [noderef] * @@ drivers/usb/host/fhci-hcd.c:41:23: sparse: expected unsigned short volatile [noderef] [usertype] *addr drivers/usb/host/fhci-hcd.c:41:23: sparse: got restricted __be16 [noderef] * drivers/usb/host/fhci-hcd.c:59:16: sparse: sparse: incorrect type in argument 1 (different base types) @@ expected unsigned short const volatile [noderef] [usertype] *addr @@ got restricted __be16 [noderef] * @@ drivers/usb/host/fhci-hcd.c:59:16: sparse: expected unsigned short const volatile [noderef] [usertype] *addr drivers/usb/host/fhci-hcd.c:59:16: sparse: got restricted __be16 [noderef] * >> drivers/usb/host/fhci-hcd.c:59:16: sparse: sparse: cast to restricted __be16 drivers/usb/host/fhci-hcd.c:89:36: sparse: sparse: incorrect type in argument 1 (different base types) @@ expected unsigned short volatile [noderef] [usertype] *addr @@ got restricted __be16 [noderef] * @@ drivers/usb/host/fhci-hcd.c:89:36: sparse: expected unsigned short volatile [noderef] [usertype] *addr drivers/usb/host/fhci-hcd.c:89:36: sparse: got restricted __be16 [noderef] * drivers/usb/host/fhci-hcd.c:90:36: sparse: sparse: incorrect type in argument 1 (different base types) @@ expected unsigned short volatile [noderef] [usertype] *addr @@ got restricted __be16 [noderef] * @@ drivers/usb/host/fhci-hcd.c:90:36: sparse: expected unsigned short volatile [noderef] [usertype] *addr drivers/usb/host/fhci-hcd.c:90:36: sparse: got restricted __be16 [noderef] * drivers/usb/host/fhci-hcd.c:110:36: sparse: sparse: incorrect type in argument 1 (different base types) @@ expected unsigned short volatile [noderef] [usertype] *addr @@ got restricted __be16 [noderef] * @@ drivers/usb/host/fhci-hcd.c:110:36: sparse: expected unsigned short volatile [noderef] [usertype] *addr drivers/usb/host/fhci-hcd.c:110:36: sparse: got restricted __be16 [noderef] * drivers/usb/host/fhci-hcd.c:120:28: sparse: sparse: incorrect type in argument 1 (different base types) @@ expected unsigned short volatile [noderef] [usertype] *addr @@ got restricted __be16 [noderef] * @@ drivers/usb/host/fhci-hcd.c:120:28: sparse: expected unsigned short volatile [noderef] [usertype] *addr drivers/usb/host/fhci-hcd.c:120:28: sparse: got restricted __be16 [noderef] * drivers/usb/host/fhci-hcd.c:121:28: sparse: sparse: incorrect type in argument 1 (different base types) @@ expected unsigned short volatile [noderef] [usertype] *addr @@ got restricted __be16 [noderef] * @@ drivers/usb/host/fhci-hcd.c:121:28: sparse: expected unsigned short volatile [noderef] [usertype] *addr drivers/usb/host/fhci-hcd.c:121:28: sparse: got restricted __be16 [noderef] * drivers/usb/host/fhci-hcd.c:275:23: sparse: sparse: incorrect type in argument 1 (different base types) @@ expected unsigned short volatile [noderef] [usertype] *addr @@ got restricted __be16 [noderef] * @@
Re: [PATCH v3 3/3] iio: proximity: Add a ChromeOS EC MKBP proximity driver
On Thu, 28 Jan 2021 00:40:11 -0800
Stephen Boyd wrote:
> Add support for a ChromeOS EC proximity driver that exposes a "front"
> proximity sensor via the IIO subsystem. The EC decides when front
> proximity is near and sets an MKBP switch 'EC_MKBP_FRONT_PROXIMITY' to
> notify the kernel of proximity. Similarly, when proximity detects
> something far away it sets the switch bit to 0. For now this driver
> exposes a single sensor, but it could be expanded in the future via more
> MKBP bits if desired.
>
> Cc: Dmitry Torokhov
> Cc: Benson Leung
> Cc: Guenter Roeck
> Cc: Douglas Anderson
> Cc: Gwendal Grignou
> Signed-off-by: Stephen Boyd
>From a final look through, just one trivial request for a comment on
lock scope. Otherwise looks good to me.
Jonathan
> ---
>
> Changes from v2:
> * Get clock base and use iio time if not boottime
>
> Changes from v1:
> * Sorted includes
> * Renamed to have MKBP everywhere
> * Use last_event_time for timestamp
> * Dropped claim calls
> * Dropped useless dev assignment
>
> drivers/iio/proximity/Kconfig | 11 +
> drivers/iio/proximity/Makefile| 1 +
> .../iio/proximity/cros_ec_mkbp_proximity.c| 245 ++
> 3 files changed, 257 insertions(+)
> create mode 100644 drivers/iio/proximity/cros_ec_mkbp_proximity.c
>
> diff --git a/drivers/iio/proximity/Kconfig b/drivers/iio/proximity/Kconfig
> index 12672a0e89ed..7c7203ca3ac6 100644
> --- a/drivers/iio/proximity/Kconfig
> +++ b/drivers/iio/proximity/Kconfig
> @@ -21,6 +21,17 @@ endmenu
>
> menu "Proximity and distance sensors"
>
> +config CROS_EC_MKBP_PROXIMITY
> + tristate "ChromeOS EC MKBP Proximity sensor"
> + depends on CROS_EC
> + help
> + Say Y here to enable the proximity sensor implemented via the
> ChromeOS EC MKBP
> + switches protocol. You must enable one bus option (CROS_EC_I2C or
> CROS_EC_SPI)
> + to use this.
> +
> + To compile this driver as a module, choose M here: the
> + module will be called cros_ec_mkbp_proximity.
> +
> config ISL29501
> tristate "Intersil ISL29501 Time Of Flight sensor"
> depends on I2C
> diff --git a/drivers/iio/proximity/Makefile b/drivers/iio/proximity/Makefile
> index 9c1aca1a8b79..cbdac09433eb 100644
> --- a/drivers/iio/proximity/Makefile
> +++ b/drivers/iio/proximity/Makefile
> @@ -5,6 +5,7 @@
>
> # When adding new entries keep the list in alphabetical order
> obj-$(CONFIG_AS3935) += as3935.o
> +obj-$(CONFIG_CROS_EC_MKBP_PROXIMITY) += cros_ec_mkbp_proximity.o
> obj-$(CONFIG_ISL29501) += isl29501.o
> obj-$(CONFIG_LIDAR_LITE_V2) += pulsedlight-lidar-lite-v2.o
> obj-$(CONFIG_MB1232) += mb1232.o
> diff --git a/drivers/iio/proximity/cros_ec_mkbp_proximity.c
> b/drivers/iio/proximity/cros_ec_mkbp_proximity.c
> new file mode 100644
> index ..c8f33cf11b42
> --- /dev/null
> +++ b/drivers/iio/proximity/cros_ec_mkbp_proximity.c
> @@ -0,0 +1,245 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Driver for cros-ec proximity sensor exposed through MKBP switch
> + *
> + * Copyright 2021 Google LLC.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +
> +#include
> +
> +struct cros_ec_mkbp_proximity_data {
> + struct cros_ec_device *ec;
> + struct iio_dev *indio_dev;
> + struct mutex lock;
Totally trivial, but please add a comment documenting the
scope of this lock. If nothing else, one of the static analysers
tends to complain about this so we'll end up adding one later :)
> + struct notifier_block notifier;
> + bool enabled;
> +};
> +
[PATCH] ARM: dts: imx6qdl-wandboard: add scl/sda gpios definitions for i2c bus recovery
The i2c bus on imx6qdl-wandboard has intermittent issues where SDA can freeze
on low level at the end of transaction so the bus can no longer work. This
impacts reading of EDID data leading to incorrect TV resolution and no audio.
This scenario is improved by adding scl/sda gpios definitions to implement the
i2c bus recovery mechanism.
Signed-off-by: Dima Azarkin
---
arch/arm/boot/dts/imx6qdl-wandboard.dtsi | 24 ++--
1 file changed, 22 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/imx6qdl-wandboard.dtsi
b/arch/arm/boot/dts/imx6qdl-wandboard.dtsi
index c070893c509e..b62a0dbb033f 100644
--- a/arch/arm/boot/dts/imx6qdl-wandboard.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-wandboard.dtsi
@@ -97,15 +97,21 @@
&i2c1 {
clock-frequency = <10>;
- pinctrl-names = "default";
+ pinctrl-names = "default", "gpio";
pinctrl-0 = <&pinctrl_i2c1>;
+ pinctrl-1 = <&pinctrl_i2c1_gpio>;
+ scl-gpios = <&gpio3 21 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ sda-gpios = <&gpio3 28 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
status = "okay";
};
&i2c2 {
clock-frequency = <10>;
- pinctrl-names = "default";
+ pinctrl-names = "default", "gpio";
pinctrl-0 = <&pinctrl_i2c2>;
+ pinctrl-1 = <&pinctrl_i2c2_gpio>;
+ scl-gpios = <&gpio4 12 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ sda-gpios = <&gpio4 13 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
status = "okay";
codec: sgtl5000@a {
@@ -185,6 +191,13 @@
>;
};
+ pinctrl_i2c1_gpio: i2c1gpiogrp {
+ fsl,pins = <
+ MX6QDL_PAD_EIM_D21__GPIO3_IO21
0x4001b8b0
+ MX6QDL_PAD_EIM_D28__GPIO3_IO28
0x4001b8b0
+ >;
+ };
+
pinctrl_i2c2: i2c2grp {
fsl,pins = <
MX6QDL_PAD_KEY_COL3__I2C2_SCL
0x4001b8b1
@@ -192,6 +205,13 @@
>;
};
+ pinctrl_i2c2_gpio: i2c2gpiogrp {
+ fsl,pins = <
+ MX6QDL_PAD_KEY_COL3__GPIO4_IO12
0x4001b8b0
+ MX6QDL_PAD_KEY_ROW3__GPIO4_IO13
0x4001b8b0
+ >;
+ };
+
pinctrl_mclk: mclkgrp {
fsl,pins = <
MX6QDL_PAD_GPIO_0__CCM_CLKO10x130b0
--
2.17.1
Re: [PATCH] serial: 8250: add option to disable registration of legacy ISA ports
On Thu, Jan 28, 2021 at 05:22:44PM +, Mans Rullgard wrote: > On systems that do not have the traditional PC ISA serial ports, the > 8250 driver still creates non-functional device nodes. This change > makes only ports that actually exist (PCI, DT, ...) get device nodes. > > Signed-off-by: Mans Rullgard > --- > drivers/tty/serial/8250/8250_core.c | 26 -- > drivers/tty/serial/8250/Kconfig | 5 + > 2 files changed, 25 insertions(+), 6 deletions(-) > > diff --git a/drivers/tty/serial/8250/8250_core.c > b/drivers/tty/serial/8250/8250_core.c > index cae61d1ebec5..49695dd3677c 100644 > --- a/drivers/tty/serial/8250/8250_core.c > +++ b/drivers/tty/serial/8250/8250_core.c > @@ -555,6 +555,7 @@ static void __init serial8250_isa_init_ports(void) > } > } > > +#ifdef CONFIG_SERIAL_8250_ISA This is just making a mess of the code. To do this right, pull the isa code out into a separate file and put the #ifdef in a .h file, so we can properly maintain and support this code over time. This change as-is is not going to make that any easier :( > +config SERIAL_8250_ISA > + bool "8250/16550 ISA device support" if EXPERT So, no one will set this? What userspace visable change will be caused by this? Will ports get renumbered? What harm is this causing systems today without this change? thanks, greg k-h
Re: [PATCH v3 net-next 5/5] net: page_pool: simplify page recycling condition tests
From: Matthew Wilcox
Date: Sun, 31 Jan 2021 12:23:48 +
> On Sun, Jan 31, 2021 at 12:12:11PM +, Alexander Lobakin wrote:
> > pool_page_reusable() is a leftover from pre-NUMA-aware times. For now,
> > this function is just a redundant wrapper over page_is_pfmemalloc(),
> > so inline it into its sole call site.
>
> Why doesn't this want to use {dev_}page_is_reusable()?
Page Pool handles NUMA on its own. Replacing plain page_is_pfmemalloc()
with dev_page_is_reusable() will only add a completely redundant and
always-false check on the fastpath.
Al
