[tip:objtool/core] BUILD SUCCESS 14db1f0a93331d0958e90da522c429ff0890d2d6
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git objtool/core branch HEAD: 14db1f0a93331d0958e90da522c429ff0890d2d6 objtool: Ignore unreachable trap after call to noreturn functions elapsed time: 725m configs tested: 140 configs skipped: 2 The following configs have been built successfully. More configs may be tested in the coming days. gcc tested configs: arm defconfig arm64allyesconfig arm64 defconfig arm allyesconfig arm allmodconfig arm eseries_pxa_defconfig armxcep_defconfig powerpc acadia_defconfig mips decstation_r4k_defconfig arc nsimosci_hs_defconfig powerpc ep88xc_defconfig powerpc g5_defconfig shapsh4ad0a_defconfig arm orion5x_defconfig c6xevmc6474_defconfig xtensa cadence_csp_defconfig parisc alldefconfig powerpc mgcoge_defconfig arm palmz72_defconfig arm pxa168_defconfig powerpc kilauea_defconfig arm sunxi_defconfig powerpc ps3_defconfig mips bmips_be_defconfig mipsbcm47xx_defconfig arm ixp4xx_defconfig arm colibri_pxa300_defconfig mips malta_kvm_defconfig mipsar7_defconfig arcnsim_700_defconfig shhp6xx_defconfig arm exynos_defconfig sh se7343_defconfig powerpc tqm8540_defconfig arm pxa910_defconfig m68k alldefconfig armpleb_defconfig arm footbridge_defconfig x86_64 defconfig mipsnlm_xlr_defconfig h8300allyesconfig sh landisk_defconfig mips loongson1b_defconfig powerpc tqm8548_defconfig powerpc makalu_defconfig s390 debug_defconfig c6x dsk6455_defconfig mipsvocore2_defconfig sh se7721_defconfig ia64 allmodconfig ia64defconfig ia64 allyesconfig m68k allmodconfig m68kdefconfig m68k allyesconfig nios2 defconfig arc allyesconfig nds32 allnoconfig c6x allyesconfig nds32 defconfig nios2allyesconfig cskydefconfig alpha defconfig alphaallyesconfig xtensa allyesconfig arc defconfig sh allmodconfig parisc defconfig s390 allyesconfig parisc allyesconfig s390defconfig i386 allyesconfig sparcallyesconfig sparc defconfig i386defconfig mips allyesconfig mips allmodconfig powerpc allyesconfig powerpc allmodconfig powerpc allnoconfig x86_64 randconfig-a005-20200920 x86_64 randconfig-a003-20200920 x86_64 randconfig-a004-20200920 x86_64 randconfig-a002-20200920 x86_64 randconfig-a006-20200920 x86_64 randconfig-a001-20200920 i386 randconfig-a002-20200920 i386 randconfig-a006-20200920 i386 randconfig-a003-20200920 i386 randconfig-a004-20200920 i386 randconfig-a005-20200920 i386 randconfig-a001-20200920 i386 randconfig-a002-20200921 i386 randconfig-a006-20200921 i386 randconfig-a003-20200921 i386 randconfig-a004-20200921 i386 randconfig-a005-20200921 i386 randconfig-a001-20200921 x86_64 randconfig-a011-20200921 x86_64 randconfig-a013-20200921 x86_64
Re: [Patch v2] arm64: dts: layerscape: correct watchdog clocks for LS1088A
On Tue, Sep 22, 2020 at 11:31:46AM +0800, Qiang Zhao wrote: > From: Zhao Qiang > > On LS1088A, watchdog clk are divided by 16, correct it in dts. > > Signed-off-by: Zhao Qiang Applied, thanks.
Re: [PATCH] net/mlx5: remove unreachable return
On Mon, 2020-09-21 at 13:41 +0200, Pavel Machek wrote: > The last return statement is unreachable code. I'm not sure if it > will > provoke any warnings, but it looks ugly. > > Signed-off-by: Pavel Machek (CIP) > > Applied to net-next-mlx5. Thanks, Saeed.
Re: [PATCH v18 24/32] mm/pgdat: remove pgdat lru_lock
On Mon, 24 Aug 2020, Alex Shi wrote:
> Now pgdat.lru_lock was replaced by lruvec lock. It's not used anymore.
>
> Signed-off-by: Alex Shi
> Reviewed-by: Alexander Duyck
I don't take pleasure in spoiling your celebrations and ceremonies,
but I strongly agree with AlexD that this should simply be merged
into the big one, 20/32. That can be ceremony enough.
> Cc: Andrew Morton
> Cc: Konstantin Khlebnikov
> Cc: Hugh Dickins
> Cc: Johannes Weiner
> Cc: linux...@kvack.org
> Cc: linux-kernel@vger.kernel.org
> Cc: cgro...@vger.kernel.org
> ---
> include/linux/mmzone.h | 1 -
> mm/page_alloc.c| 1 -
> 2 files changed, 2 deletions(-)
>
> diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
> index f0596e634863..0ed520954843 100644
> --- a/include/linux/mmzone.h
> +++ b/include/linux/mmzone.h
> @@ -758,7 +758,6 @@ struct deferred_split {
>
> /* Write-intensive fields used by page reclaim */
> ZONE_PADDING(_pad1_)
> - spinlock_t lru_lock;
>
> #ifdef CONFIG_DEFERRED_STRUCT_PAGE_INIT
> /*
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index fab5e97dc9ca..775120fcc869 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -6733,7 +6733,6 @@ static void __meminit pgdat_init_internals(struct
> pglist_data *pgdat)
> init_waitqueue_head(>pfmemalloc_wait);
>
> pgdat_page_ext_init(pgdat);
> - spin_lock_init(>lru_lock);
> lruvec_init(>__lruvec);
> }
>
> --
> 1.8.3.1
Re: [PATCH -next] net/mlx5: simplify the return expression of mlx5_ec_init()
On Mon, 2020-09-21 at 21:10 +0800, Qinglang Miao wrote: > Simplify the return expression. > > Signed-off-by: Qinglang Miao > --- > drivers/net/ethernet/mellanox/mlx5/core/ecpf.c | 6 +- > 1 file changed, 1 insertion(+), 5 deletions(-) > > Applied to net-next-mlx5. Thanks.
[PATCH] drm/amd/display: Simplify condition in try_disable_dsc
Clang warns:
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_mst_types.c:637:8:
warning: logical not is only applied to the left hand side of this
comparison [-Wlogical-not-parentheses]
&& !params[i].clock_force_enable ==
DSC_CLK_FORCE_DEFAULT) {
^ ~~
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_mst_types.c:637:8:
note: add parentheses after the '!' to evaluate the comparison first
&& !params[i].clock_force_enable ==
DSC_CLK_FORCE_DEFAULT) {
^
(
)
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_mst_types.c:637:8:
note: add parentheses around left hand side expression to silence this
warning
&& !params[i].clock_force_enable ==
DSC_CLK_FORCE_DEFAULT) {
^
()
1 warning generated.
The expression "!a == 0" can be more simply written as "a", which makes
it easier to reason about the logic and prevents the warning.
Fixes: 0749ddeb7d6c ("drm/amd/display: Add DSC force disable to dsc_clock_en
debugfs entry")
Link: https://github.com/ClangBuiltLinux/linux/issues/1158
Signed-off-by: Nathan Chancellor
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
index 9d7333a36fac..0852a24ee392 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
@@ -634,7 +634,7 @@ static void try_disable_dsc(struct drm_atomic_state *state,
for (i = 0; i < count; i++) {
if (vars[i].dsc_enabled
&& vars[i].bpp_x16 ==
params[i].bw_range.max_target_bpp_x16
- && !params[i].clock_force_enable ==
DSC_CLK_FORCE_DEFAULT) {
+ && params[i].clock_force_enable) {
kbps_increase[i] = params[i].bw_range.stream_kbps -
params[i].bw_range.max_kbps;
tried[i] = false;
remaining_to_try += 1;
base-commit: 6651cdf3bfeeaeb499db11668313666bf756579a
--
2.28.0
Re: [PATCH v18 23/32] mm/lru: revise the comments of lru_lock
On Mon, 24 Aug 2020, Alex Shi wrote: > From: Hugh Dickins > > Since we changed the pgdat->lru_lock to lruvec->lru_lock, it's time to > fix the incorrect comments in code. Also fixed some zone->lru_lock comment > error from ancient time. etc. > > Signed-off-by: Hugh Dickins > Signed-off-by: Alex Shi I'm not the right person to be Acking this one; but when I scanned through, I did notice some wording had been added that I want to change. I should just send you a new version, but not tonight. > Cc: Andrew Morton > Cc: Tejun Heo > Cc: Andrey Ryabinin > Cc: Jann Horn > Cc: Mel Gorman > Cc: Johannes Weiner > Cc: Matthew Wilcox > Cc: Hugh Dickins > Cc: cgro...@vger.kernel.org > Cc: linux-kernel@vger.kernel.org > Cc: linux...@kvack.org > --- > Documentation/admin-guide/cgroup-v1/memcg_test.rst | 15 +++ > Documentation/admin-guide/cgroup-v1/memory.rst | 21 + > Documentation/trace/events-kmem.rst| 2 +- > Documentation/vm/unevictable-lru.rst | 22 > -- > include/linux/mm_types.h | 2 +- > include/linux/mmzone.h | 3 +-- > mm/filemap.c | 4 ++-- > mm/memcontrol.c| 2 +- > mm/rmap.c | 4 ++-- > mm/vmscan.c| 12 > 10 files changed, 36 insertions(+), 51 deletions(-) > > diff --git a/Documentation/admin-guide/cgroup-v1/memcg_test.rst > b/Documentation/admin-guide/cgroup-v1/memcg_test.rst > index 3f7115e07b5d..0b9f91589d3d 100644 > --- a/Documentation/admin-guide/cgroup-v1/memcg_test.rst > +++ b/Documentation/admin-guide/cgroup-v1/memcg_test.rst > @@ -133,18 +133,9 @@ Under below explanation, we assume > CONFIG_MEM_RES_CTRL_SWAP=y. > > 8. LRU > == > -Each memcg has its own private LRU. Now, its handling is under global > - VM's control (means that it's handled under global pgdat->lru_lock). > - Almost all routines around memcg's LRU is called by global LRU's > - list management functions under pgdat->lru_lock. > - > - A special function is mem_cgroup_isolate_pages(). This scans > - memcg's private LRU and call __isolate_lru_page() to extract a page > - from LRU. > - > - (By __isolate_lru_page(), the page is removed from both of global and > - private LRU.) > - > + Each memcg has its own vector of LRUs (inactive anon, active anon, > + inactive file, active file, unevictable) of pages from each node, > + each LRU handled under a single lru_lock for that memcg and node. > > 9. Typical Tests. > = > diff --git a/Documentation/admin-guide/cgroup-v1/memory.rst > b/Documentation/admin-guide/cgroup-v1/memory.rst > index 12757e63b26c..24450696579f 100644 > --- a/Documentation/admin-guide/cgroup-v1/memory.rst > +++ b/Documentation/admin-guide/cgroup-v1/memory.rst > @@ -285,20 +285,17 @@ When oom event notifier is registered, event will be > delivered. > 2.6 Locking > --- > > - lock_page_cgroup()/unlock_page_cgroup() should not be called under > - the i_pages lock. > +Lock order is as follows: > > - Other lock order is following: > + Page lock (PG_locked bit of page->flags) > +mm->page_table_lock or split pte_lock > + lock_page_memcg (memcg->move_lock) > +mapping->i_pages lock > + lruvec->lru_lock. > > - PG_locked. > - mm->page_table_lock > - pgdat->lru_lock > -lock_page_cgroup. > - > - In many cases, just lock_page_cgroup() is called. > - > - per-zone-per-cgroup LRU (cgroup's private LRU) is just guarded by > - pgdat->lru_lock, it has no lock of its own. > +Per-node-per-memcgroup LRU (cgroup's private LRU) is guarded by > +lruvec->lru_lock; PG_lru bit of page->flags is cleared before > +isolating a page from its LRU under lruvec->lru_lock. > > 2.7 Kernel Memory Extension (CONFIG_MEMCG_KMEM) > --- > diff --git a/Documentation/trace/events-kmem.rst > b/Documentation/trace/events-kmem.rst > index 555484110e36..68fa75247488 100644 > --- a/Documentation/trace/events-kmem.rst > +++ b/Documentation/trace/events-kmem.rst > @@ -69,7 +69,7 @@ When pages are freed in batch, the also > mm_page_free_batched is triggered. > Broadly speaking, pages are taken off the LRU lock in bulk and > freed in batch with a page list. Significant amounts of activity here could > indicate that the system is under memory pressure and can also indicate > -contention on the zone->lru_lock. > +contention on the lruvec->lru_lock. > > 4. Per-CPU Allocator Activity > = > diff --git a/Documentation/vm/unevictable-lru.rst > b/Documentation/vm/unevictable-lru.rst > index 17d0861b0f1d..0e1490524f53 100644 > --- a/Documentation/vm/unevictable-lru.rst > +++ b/Documentation/vm/unevictable-lru.rst > @@ -33,7
Re: [PATCH v18 22/32] mm/vmscan: use relock for move_pages_to_lru
On Mon, 24 Aug 2020, Alex Shi wrote:
> From: Hugh Dickins
>
> Use the relock function to replace relocking action. And try to save few
> lock times.
>
> Signed-off-by: Hugh Dickins
> Signed-off-by: Alex Shi
> Reviewed-by: Alexander Duyck
NAK. Who wrote this rubbish? Oh, did I? Maybe something you extracted
from my tarball. No, we don't need any of this now, as explained when
going through 20/32.
> Cc: Andrew Morton
> Cc: Tejun Heo
> Cc: Andrey Ryabinin
> Cc: Jann Horn
> Cc: Mel Gorman
> Cc: Johannes Weiner
> Cc: Matthew Wilcox
> Cc: Hugh Dickins
> Cc: cgro...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: linux...@kvack.org
> ---
> mm/vmscan.c | 17 ++---
> 1 file changed, 6 insertions(+), 11 deletions(-)
>
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index 2c94790d4cb1..04ef94190530 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -1848,15 +1848,15 @@ static unsigned noinline_for_stack
> move_pages_to_lru(struct lruvec *lruvec,
> enum lru_list lru;
>
> while (!list_empty(list)) {
> - struct lruvec *new_lruvec = NULL;
> -
> page = lru_to_page(list);
> VM_BUG_ON_PAGE(PageLRU(page), page);
> list_del(>lru);
> if (unlikely(!page_evictable(page))) {
> - spin_unlock_irq(>lru_lock);
> + if (lruvec) {
> + spin_unlock_irq(>lru_lock);
> + lruvec = NULL;
> + }
> putback_lru_page(page);
> - spin_lock_irq(>lru_lock);
> continue;
> }
>
> @@ -1871,12 +1871,7 @@ static unsigned noinline_for_stack
> move_pages_to_lru(struct lruvec *lruvec,
>* list_add(>lru,)
>*list_add(>lru,)
>*/
> - new_lruvec = mem_cgroup_page_lruvec(page, page_pgdat(page));
> - if (new_lruvec != lruvec) {
> - if (lruvec)
> - spin_unlock_irq(>lru_lock);
> - lruvec = lock_page_lruvec_irq(page);
> - }
> + lruvec = relock_page_lruvec_irq(page, lruvec);
> SetPageLRU(page);
>
> if (unlikely(put_page_testzero(page))) {
> @@ -1885,8 +1880,8 @@ static unsigned noinline_for_stack
> move_pages_to_lru(struct lruvec *lruvec,
>
> if (unlikely(PageCompound(page))) {
> spin_unlock_irq(>lru_lock);
> + lruvec = NULL;
> destroy_compound_page(page);
> - spin_lock_irq(>lru_lock);
> } else
> list_add(>lru, _to_free);
>
> --
> 1.8.3.1
Re: [PATCH v18 21/32] mm/lru: introduce the relock_page_lruvec function
On Mon, 24 Aug 2020, Alex Shi wrote:
> From: Alexander Duyck
>
> Use this new function to replace repeated same code, no func change.
>
> When testing for relock we can avoid the need for RCU locking if we simply
> compare the page pgdat and memcg pointers versus those that the lruvec is
> holding. By doing this we can avoid the extra pointer walks and accesses of
> the memory cgroup.
>
> In addition we can avoid the checks entirely if lruvec is currently NULL.
>
> Signed-off-by: Alexander Duyck
> Signed-off-by: Alex Shi
Again, I'll wait to see __munlock_pagevec() fixed before Acking this
one, but that's the only issue. And I've suggested that you use
lruvec_holds_page_lru_lock() in mm/vmscan.c move_pages_to_lru(),
to replace the uglier and less efficient VM_BUG_ON_PAGE there.
Oh, there is one other issue: 0day robot did report (2020-06-19)
that sparse doesn't understand relock_page_lruvec*(): I've never
got around to working out how to write what it needs, conditional
__release plus __acquire in some form, I imagine. I've never got
into sparse annotations before, I'll give it a try, but if anyone
beats me that will be welcome: and there are higher priorities -
I do not think you should wait for the sparse warning to be fixed
before reposting.
> Cc: Johannes Weiner
> Cc: Andrew Morton
> Cc: Thomas Gleixner
> Cc: Andrey Ryabinin
> Cc: Matthew Wilcox
> Cc: Mel Gorman
> Cc: Konstantin Khlebnikov
> Cc: Hugh Dickins
> Cc: Tejun Heo
> Cc: linux-kernel@vger.kernel.org
> Cc: cgro...@vger.kernel.org
> Cc: linux...@kvack.org
> ---
> include/linux/memcontrol.h | 52
> ++
> mm/mlock.c | 9 +---
> mm/swap.c | 33 +++--
> mm/vmscan.c| 8 +--
> 4 files changed, 61 insertions(+), 41 deletions(-)
>
> diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
> index 7b170e9028b5..ee6ef2d8ad52 100644
> --- a/include/linux/memcontrol.h
> +++ b/include/linux/memcontrol.h
> @@ -488,6 +488,22 @@ static inline struct lruvec *mem_cgroup_lruvec(struct
> mem_cgroup *memcg,
>
> struct lruvec *mem_cgroup_page_lruvec(struct page *, struct pglist_data *);
>
> +static inline bool lruvec_holds_page_lru_lock(struct page *page,
> + struct lruvec *lruvec)
> +{
> + pg_data_t *pgdat = page_pgdat(page);
> + const struct mem_cgroup *memcg;
> + struct mem_cgroup_per_node *mz;
> +
> + if (mem_cgroup_disabled())
> + return lruvec == >__lruvec;
> +
> + mz = container_of(lruvec, struct mem_cgroup_per_node, lruvec);
> + memcg = page->mem_cgroup ? : root_mem_cgroup;
> +
> + return lruvec->pgdat == pgdat && mz->memcg == memcg;
> +}
> +
> struct mem_cgroup *mem_cgroup_from_task(struct task_struct *p);
>
> struct mem_cgroup *get_mem_cgroup_from_mm(struct mm_struct *mm);
> @@ -1023,6 +1039,14 @@ static inline struct lruvec
> *mem_cgroup_page_lruvec(struct page *page,
> return >__lruvec;
> }
>
> +static inline bool lruvec_holds_page_lru_lock(struct page *page,
> + struct lruvec *lruvec)
> +{
> + pg_data_t *pgdat = page_pgdat(page);
> +
> + return lruvec == >__lruvec;
> +}
> +
> static inline struct mem_cgroup *parent_mem_cgroup(struct mem_cgroup *memcg)
> {
> return NULL;
> @@ -1469,6 +1493,34 @@ static inline void
> unlock_page_lruvec_irqrestore(struct lruvec *lruvec,
> spin_unlock_irqrestore(>lru_lock, flags);
> }
>
> +/* Don't lock again iff page's lruvec locked */
> +static inline struct lruvec *relock_page_lruvec_irq(struct page *page,
> + struct lruvec *locked_lruvec)
> +{
> + if (locked_lruvec) {
> + if (lruvec_holds_page_lru_lock(page, locked_lruvec))
> + return locked_lruvec;
> +
> + unlock_page_lruvec_irq(locked_lruvec);
> + }
> +
> + return lock_page_lruvec_irq(page);
> +}
> +
> +/* Don't lock again iff page's lruvec locked */
> +static inline struct lruvec *relock_page_lruvec_irqsave(struct page *page,
> + struct lruvec *locked_lruvec, unsigned long *flags)
> +{
> + if (locked_lruvec) {
> + if (lruvec_holds_page_lru_lock(page, locked_lruvec))
> + return locked_lruvec;
> +
> + unlock_page_lruvec_irqrestore(locked_lruvec, *flags);
> + }
> +
> + return lock_page_lruvec_irqsave(page, flags);
> +}
> +
> #ifdef CONFIG_CGROUP_WRITEBACK
>
> struct wb_domain *mem_cgroup_wb_domain(struct bdi_writeback *wb);
> diff --git a/mm/mlock.c b/mm/mlock.c
> index 177d2588e863..0448409184e3 100644
> --- a/mm/mlock.c
> +++ b/mm/mlock.c
> @@ -302,17 +302,10 @@ static void __munlock_pagevec(struct pagevec *pvec,
> struct zone *zone)
> /* Phase 1: page isolation */
> for (i = 0; i < nr; i++) {
> struct page *page = pvec->pages[i];
> - struct lruvec
[PATCH v1 2/2] scsi: ufs: Fix a racing problem between ufshcd_abort and eh_work
In current task abort routine, if task abort happens to the device W-LU,
the code directly jumps to ufshcd_eh_host_reset_handler() to perform a
full reset and restore then returns FAIL or SUCCESS. Commands sent to the
device W-LU are most likely the SSU cmds sent during UFS PM operations. If
such SSU cmd enters task abort routine, when ufshcd_eh_host_reset_handler()
flushes eh_work, there will be racing because err_handler is serialized
with any PM operations.
Since the main idea of aborting one cmd to the device W-LU is to perform
a full reset and restore, in order to resolve the racing problem, we merely
clean up the lrb taken by this cmd, queue the eh_work and abort the cmd.
Since the cmd has been aborted, the PM operation which sends the cmd simply
errors out, thus err_handler will not be blocked by ongoing PM operations
and err_handler can also recover PM error if any, which comes as another
benefit of this change.
Because such cmd is aborted even before it is actually cleared from HW, set
the lrb->in_use flag to prevent subsequent cmds, including SCSI cmds and
dev cmds, from taking the lrb released by this cmd. Flag lrb->in_use shall
evetually be cleared in __ufshcd_transfer_req_compl() invoked by the full
reset and restore from err_handler.
Signed-off-by: Can Guo
---
drivers/scsi/ufs/ufshcd.c | 58 +--
drivers/scsi/ufs/ufshcd.h | 2 ++
2 files changed, 48 insertions(+), 12 deletions(-)
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 7e764e8..e4cb994 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -2539,6 +2539,14 @@ static int ufshcd_queuecommand(struct Scsi_Host *host,
struct scsi_cmnd *cmd)
(hba->clk_gating.state != CLKS_ON));
lrbp = >lrb[tag];
+ if (unlikely(lrbp->in_use)) {
+ if (hba->pm_op_in_progress)
+ set_host_byte(cmd, DID_BAD_TARGET);
+ else
+ err = SCSI_MLQUEUE_HOST_BUSY;
+ ufshcd_release(hba);
+ goto out;
+ }
WARN_ON(lrbp->cmd);
lrbp->cmd = cmd;
@@ -2781,6 +2789,11 @@ static int ufshcd_exec_dev_cmd(struct ufs_hba *hba,
init_completion();
lrbp = >lrb[tag];
+ if (unlikely(lrbp->in_use)) {
+ err = -EBUSY;
+ goto out;
+ }
+
WARN_ON(lrbp->cmd);
err = ufshcd_compose_dev_cmd(hba, lrbp, cmd_type, tag);
if (unlikely(err))
@@ -2797,6 +2810,7 @@ static int ufshcd_exec_dev_cmd(struct ufs_hba *hba,
err = ufshcd_wait_for_dev_cmd(hba, lrbp, timeout);
+out:
ufshcd_add_query_upiu_trace(hba, tag,
err ? "query_complete_err" : "query_complete");
@@ -4932,6 +4946,7 @@ static void __ufshcd_transfer_req_compl(struct ufs_hba
*hba,
for_each_set_bit(index, _reqs, hba->nutrs) {
lrbp = >lrb[index];
+ lrbp->in_use = false;
lrbp->compl_time_stamp = ktime_get();
cmd = lrbp->cmd;
if (cmd) {
@@ -6374,8 +6389,12 @@ static int ufshcd_issue_devman_upiu_cmd(struct ufs_hba
*hba,
init_completion();
lrbp = >lrb[tag];
- WARN_ON(lrbp->cmd);
+ if (unlikely(lrbp->in_use)) {
+ err = -EBUSY;
+ goto out;
+ }
+ WARN_ON(lrbp->cmd);
lrbp->cmd = NULL;
lrbp->sense_bufflen = 0;
lrbp->sense_buffer = NULL;
@@ -6447,6 +6466,7 @@ static int ufshcd_issue_devman_upiu_cmd(struct ufs_hba
*hba,
}
}
+out:
blk_put_request(req);
out_unlock:
up_read(>clk_scaling_lock);
@@ -6696,16 +6716,6 @@ static int ufshcd_abort(struct scsi_cmnd *cmd)
BUG();
}
- /*
-* Task abort to the device W-LUN is illegal. When this command
-* will fail, due to spec violation, scsi err handling next step
-* will be to send LU reset which, again, is a spec violation.
-* To avoid these unnecessary/illegal step we skip to the last error
-* handling stage: reset and restore.
-*/
- if (lrbp->lun == UFS_UPIU_UFS_DEVICE_WLUN)
- return ufshcd_eh_host_reset_handler(cmd);
-
ufshcd_hold(hba, false);
reg = ufshcd_readl(hba, REG_UTP_TRANSFER_REQ_DOOR_BELL);
/* If command is already aborted/completed, return SUCCESS */
@@ -6726,7 +6736,7 @@ static int ufshcd_abort(struct scsi_cmnd *cmd)
* to reduce repeated printouts. For other aborted requests only print
* basic details.
*/
- scsi_print_command(hba->lrb[tag].cmd);
+ scsi_print_command(cmd);
if (!hba->req_abort_count) {
ufshcd_update_reg_hist(>ufs_stats.task_abort, 0);
ufshcd_print_host_regs(hba);
@@ -6745,6 +6755,30 @@ static int ufshcd_abort(struct scsi_cmnd *cmd)
goto cleanup;
}
+ /*
+* Task
RE: [PATCH V2 0/2] add QoS support for cpuidle system
Hi Sean, Any comments? Best Regards, Joakim Zhang > -Original Message- > From: Joakim Zhang > Sent: 2020年9月19日 2:17 > To: mche...@kernel.org; robh...@kernel.org; s...@mess.org > Cc: linux-me...@vger.kernel.org; devicet...@vger.kernel.org; > linux-kernel@vger.kernel.org; dl-linux-imx > Subject: [PATCH V2 0/2] add QoS support for cpuidle system > > Add QoS support for cpuidle system. > > Joakim Zhang (2): > bindings: media: gpio-ir-receiver: add linux,autosuspend-period > property > media: rc: gpio-ir-recv: add QoS support for cpuidle system > > .../bindings/media/gpio-ir-receiver.txt | 3 ++ > drivers/media/rc/gpio-ir-recv.c | 50 +++ > 2 files changed, 53 insertions(+) > > -- > 2.17.1
[PATCH v1 1/2] scsi: ufs: Serialize eh_work with system PM events and async scan
Serialize eh_work with system PM events and async scan to make sure eh_work
does not run in parallel with them.
Change-Id: I33012c68e2ea443950313c59a4a46ad88cf3c82d
Signed-off-by: Can Guo
---
drivers/scsi/ufs/ufshcd.c | 64 +--
drivers/scsi/ufs/ufshcd.h | 1 +
2 files changed, 41 insertions(+), 24 deletions(-)
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 1d8134e..7e764e8 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -5597,7 +5597,9 @@ static inline void ufshcd_schedule_eh_work(struct ufs_hba
*hba)
static void ufshcd_err_handling_prepare(struct ufs_hba *hba)
{
pm_runtime_get_sync(hba->dev);
- if (pm_runtime_suspended(hba->dev)) {
+ if (pm_runtime_status_suspended(hba->dev) || hba->is_sys_suspended) {
+ enum ufs_pm_op pm_op;
+
/*
* Don't assume anything of pm_runtime_get_sync(), if
* resume fails, irq and clocks can be OFF, and powers
@@ -5612,7 +5614,8 @@ static void ufshcd_err_handling_prepare(struct ufs_hba
*hba)
if (!ufshcd_is_clkgating_allowed(hba))
ufshcd_setup_clocks(hba, true);
ufshcd_release(hba);
- ufshcd_vops_resume(hba, UFS_RUNTIME_PM);
+ pm_op = hba->is_sys_suspended ? UFS_RUNTIME_PM : UFS_SYSTEM_PM;
+ ufshcd_vops_resume(hba, pm_op);
} else {
ufshcd_hold(hba, false);
if (hba->clk_scaling.is_allowed) {
@@ -5633,7 +5636,7 @@ static void ufshcd_err_handling_unprepare(struct ufs_hba
*hba)
static inline bool ufshcd_err_handling_should_stop(struct ufs_hba *hba)
{
- return (hba->ufshcd_state == UFSHCD_STATE_ERROR ||
+ return (!hba->is_powered || hba->ufshcd_state == UFSHCD_STATE_ERROR ||
(!(hba->saved_err || hba->saved_uic_err || hba->force_reset ||
ufshcd_is_link_broken(hba;
}
@@ -5646,6 +5649,7 @@ static void ufshcd_recover_pm_error(struct ufs_hba *hba)
struct request_queue *q;
int ret;
+ hba->is_sys_suspended = false;
/*
* Set RPM status of hba device to RPM_ACTIVE,
* this also clears its runtime error.
@@ -5704,11 +5708,13 @@ static void ufshcd_err_handler(struct work_struct *work)
hba = container_of(work, struct ufs_hba, eh_work);
+ down(>eh_sem);
spin_lock_irqsave(hba->host->host_lock, flags);
if (ufshcd_err_handling_should_stop(hba)) {
if (hba->ufshcd_state != UFSHCD_STATE_ERROR)
hba->ufshcd_state = UFSHCD_STATE_OPERATIONAL;
spin_unlock_irqrestore(hba->host->host_lock, flags);
+ up(>eh_sem);
return;
}
ufshcd_set_eh_in_progress(hba);
@@ -5716,20 +5722,18 @@ static void ufshcd_err_handler(struct work_struct *work)
ufshcd_err_handling_prepare(hba);
spin_lock_irqsave(hba->host->host_lock, flags);
ufshcd_scsi_block_requests(hba);
- /*
-* A full reset and restore might have happened after preparation
-* is finished, double check whether we should stop.
-*/
- if (ufshcd_err_handling_should_stop(hba)) {
- if (hba->ufshcd_state != UFSHCD_STATE_ERROR)
- hba->ufshcd_state = UFSHCD_STATE_OPERATIONAL;
- goto out;
- }
hba->ufshcd_state = UFSHCD_STATE_RESET;
/* Complete requests that have door-bell cleared by h/w */
ufshcd_complete_requests(hba);
+ /*
+* A full reset and restore might have happened after preparation
+* is finished, double check whether we should stop.
+*/
+ if (ufshcd_err_handling_should_stop(hba))
+ goto skip_err_handling;
+
if (hba->dev_quirks & UFS_DEVICE_QUIRK_RECOVERY_FROM_DL_NAC_ERRORS) {
bool ret;
@@ -5737,17 +5741,10 @@ static void ufshcd_err_handler(struct work_struct *work)
/* release the lock as ufshcd_quirk_dl_nac_errors() may sleep */
ret = ufshcd_quirk_dl_nac_errors(hba);
spin_lock_irqsave(hba->host->host_lock, flags);
- if (!ret && !hba->force_reset && ufshcd_is_link_active(hba))
+ if (!ret && ufshcd_err_handling_should_stop(hba))
goto skip_err_handling;
}
- if (hba->force_reset || ufshcd_is_link_broken(hba) ||
- ufshcd_is_saved_err_fatal(hba) ||
- ((hba->saved_err & UIC_ERROR) &&
-(hba->saved_uic_err & (UFSHCD_UIC_DL_NAC_RECEIVED_ERROR |
- UFSHCD_UIC_DL_TCx_REPLAY_ERROR
- needs_reset = true;
-
if ((hba->saved_err & (INT_FATAL_ERRORS | UFSHCD_UIC_HIBERN8_MASK)) ||
(hba->saved_uic_err &&
(hba->saved_uic_err != UFSHCD_UIC_PA_GENERIC_ERROR))) {
@@ -5767,8 +5764,14 @@
Re: [PATCH v2 31/32] auxdisplay: charlcd: Do not print chars at end of line
On Mon, Sep 21, 2020 at 04:46:43PM +0200, poesc...@lemonage.de wrote: > From: Lars Poeschel > > Skip printing characters at the end of a display line. This fits to the > behaviour we already had, that the cursor is nailed to last position of > a line. Just very old memories, but wasn't this used with the ability to shift the display ? IIRC the HD44780 has a 2x64 chars buffer and you can make the buffered characters appear when you shift the display. That's akin to seeing the display as an adjustable window over the buffer. I don't remember having used that feature, so if it didn't previously work, please disregard my comment, I just want to be sure we don't break a feature others might be relying on. Willy
Re: [PATCH v2 28/32] auxdisplay: hd44780: Remove clear_fast
Hi Lars, On Mon, Sep 21, 2020 at 04:46:40PM +0200, poesc...@lemonage.de wrote: > From: Lars Poeschel > > We remove the hd44780_clear_fast (display) clear implementation. charlcd > will fall back to use hd44780_common_clear_display then, which is much > much faster. I might have got confused, but it looks to me like patches 27 and 28 basically undo patch 26: in 26 you moved code to hd44780 and wrote a fallback, just to later delete that code. I seem to remember that the reason for the clear_fast() implementation is that the default clear_display() is quite slow for small displays, compared to what can be achieved by just filling the display with spaces (in the order of tens of milliseconds vs hundreds of microseconds). But I could be mistaken given how old this is, so please take my comment with a grain of salt. Willy
Re: [PATCH v38 10/24] mm: Add vm_ops->mprotect()
On Tue, Sep 22, 2020 at 08:30:06AM +0300, Jarkko Sakkinen wrote:
> On Mon, Sep 21, 2020 at 02:18:49PM -0700, Sean Christopherson wrote:
> > On Tue, Sep 22, 2020 at 12:07:36AM +0300, Jarkko Sakkinen wrote:
> > > On Mon, Sep 21, 2020 at 09:57:58AM -0700, Sean Christopherson wrote:
> > > > On Mon, Sep 21, 2020 at 03:49:46PM +0300, Jarkko Sakkinen wrote:
> > > > > On Fri, Sep 18, 2020 at 04:53:37PM -0700, Sean Christopherson wrote:
> > > > > > a noexec filesystem by loading code into an enclave, and to give
> > > > > > the kernel the
> > > > > > option of adding enclave specific LSM policies in the future.
> > > > > >
> > > > > > The source file (if one exists) for the enclave is long gone when
> > > > > > the enclave
> > > > > > is actually mmap()'d and mprotect()'d. To enforce noexec, the
> > > > > > requested
> > > > > > permissions for a given page are snapshotted when the page is added
> > > > > > to the
> > > > > > enclave, i.e. when the enclave is built. Enclave pages that will
> > > > > > be executable
> > > > > > must originate from an a MAYEXEC VMA, e.g. the source page can't
> > > > > > come from a
> > > > > > noexec file system.
> > > > >
> > > > > noexec check is done in __sgx_encl_add_page(), not in this callback.
> > > > > sgx_vma_mprotect() calls sgx_encl_may_map(), which iterates the
> > > > > addresses, checks that permissions are not surpassed and there are
> > > > > no holes.
> > > >
> > > > Yes, that's what I said.
> > >
> > > sgx_encl_add_page() will remove such page. The callback does not
> > > interact with this process as such pages never get to the enclave.
> >
> > I think we're in violent agreement, mostly.
> >
> > Userspace can add the page without EXEC permissions in the EPCM, and thus
> > avoid the noexec/VM_MAYEXEC check. The enclave can then do EMODPE to gain
> > EXEC permissions in the EPMC. Without the ->mprotect() hook, we wouldn't
> > be able to detect/prevent such shenanigans.
>
> Right, the VM_MAYEXEC in the code is nested under VM_EXEC check.
>
> I'm only wondering why not block noexec completely with any permissions,
> i.e. why not just have unconditional VM_MAYEXEC check?
I.e. why not this:
static int __sgx_encl_add_page(struct sgx_encl *encl,
struct sgx_encl_page *encl_page,
struct sgx_epc_page *epc_page,
struct sgx_secinfo *secinfo, unsigned long src)
{
struct sgx_pageinfo pginfo;
struct vm_area_struct *vma;
struct page *src_page;
int ret;
vma = find_vma(current->mm, src);
if (!vma)
return -EFAULT;
if (!(vma->vm_flags & VM_MAYEXEC))
return -EACCES;
I'm not seeing the reason for "partial support" for noexec partitions.
If there is a good reason, fine, let's just then document it.
/Jarkko
Re: [PATCH v2 00/33] Make charlcd device independent
Hi Lars, On Mon, Sep 21, 2020 at 04:46:12PM +0200, poesc...@lemonage.de wrote: > This tries to make charlcd device independent. At the moment hd44780 > device specific code is contained deep in charlcd. This moves this out > into a hd44780_common module, where the two hd44780 drivers we have at > the moment (hd44780 and panel) can use this from. The goal is that at > the end other drivers can use the charlcd interface. > I add one such driver at the end with the last patch. > I submitted this already some time ago [1], where the wish was so split > this into smaller chunks what I try to do with this new patchset. > Most of the patches pick one specific function in charlcd and move the > device specific code into hd44780_common. Regardless of my two comments, this series looks very clean to me, nice job! For 1..32, feel free to add: Reviewed-by: Willy Tarreau Just be careful in your commit messages, I spotted a few "it's own" instead of "its own", but that's a very minor detail :-) Willy
Re: [PATCH 5/6] scsi: ufs: show ufs part info in error case
On 2020-09-18 12:13, Jaegeuk Kim wrote:
On 09/17, Can Guo wrote:
On 2020-09-17 00:05, Jaegeuk Kim wrote:
> On 09/16, Bean Huo wrote:
> > On Tue, 2020-09-15 at 13:45 -0700, Jaegeuk Kim wrote:
> > > Cc: Avri Altman
> > > Signed-off-by: Jaegeuk Kim
> > > ---
> > > drivers/scsi/ufs/ufshcd.c | 8
> > > 1 file changed, 8 insertions(+)
> > >
> > > diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
> > > index bdc82cc3824aa..b81c116b976ff 100644
> > > --- a/drivers/scsi/ufs/ufshcd.c
> > > +++ b/drivers/scsi/ufs/ufshcd.c
> > > @@ -500,6 +500,14 @@ static void ufshcd_print_tmrs(struct ufs_hba
> > > *hba, unsigned long bitmap)
> > > static void ufshcd_print_host_state(struct ufs_hba *hba)
> > > {
> > > dev_err(hba->dev, "UFS Host state=%d\n", hba->ufshcd_state);
> > > + if (hba->sdev_ufs_device) {
> > > + dev_err(hba->dev, " vendor = %.8s\n",
> > > + hba->sdev_ufs_device-
> > > >vendor);
> > > + dev_err(hba->dev, " model = %.16s\n",
> > > + hba->sdev_ufs_device->model);
> > > + dev_err(hba->dev, " rev = %.4s\n",
> > > + hba->sdev_ufs_device->rev);
> > > + }
> >
> > Hi Jaegeuk
> > these prints have been added since this change:
> >
> > commit 3f8af6044713 ("scsi: ufs: Add some debug information to
> > ufshcd_print_host_state()")
> >
> > https://patchwork.kernel.org/patch/11694371/
>
> Cool, thank you for pointing this out. BTW, which branch can I see the
> -next
> patches?
>
Hi Jaegeuk,
This patch comes from a series of changes trying to fix and simplify
the UFS error handling. You can find the whole series here - they are
picked up on scsi-queue-5.10
https://lore.kernel.org/linux-scsi/1596975355-39813-10-git-send-email-c...@codeaurora.org/
Besides, several more fixes for error handling based on above series
are
https://lore.kernel.org/patchwork/patch/1290405/
&
https://lore.kernel.org/linux-scsi/159961731708.5787.8825955850640714260.b4...@oracle.com/
I've mainline all above changes to Android12-5.4 and Android11-5.4.
I've seen the patches in Android branches. Thank you for the
explanation.
Moreover, there are 2 more fixes on the way for error handling, I
will push them soon.
BTW, could you please take a look at these patches?
Thanks,
Sure, but since I am not in your cc or to list, so I don't know which
patches. Maybe you can add me when you push the next version? Thanks.
Regards,
Can Guo.
Thanks,
Can Guo.
> >
> > Thanks,
> > Bean
Re: [PATCH v38 10/24] mm: Add vm_ops->mprotect()
On Mon, Sep 21, 2020 at 02:18:49PM -0700, Sean Christopherson wrote: > On Tue, Sep 22, 2020 at 12:07:36AM +0300, Jarkko Sakkinen wrote: > > On Mon, Sep 21, 2020 at 09:57:58AM -0700, Sean Christopherson wrote: > > > On Mon, Sep 21, 2020 at 03:49:46PM +0300, Jarkko Sakkinen wrote: > > > > On Fri, Sep 18, 2020 at 04:53:37PM -0700, Sean Christopherson wrote: > > > > > a noexec filesystem by loading code into an enclave, and to give the > > > > > kernel the > > > > > option of adding enclave specific LSM policies in the future. > > > > > > > > > > The source file (if one exists) for the enclave is long gone when the > > > > > enclave > > > > > is actually mmap()'d and mprotect()'d. To enforce noexec, the > > > > > requested > > > > > permissions for a given page are snapshotted when the page is added > > > > > to the > > > > > enclave, i.e. when the enclave is built. Enclave pages that will be > > > > > executable > > > > > must originate from an a MAYEXEC VMA, e.g. the source page can't come > > > > > from a > > > > > noexec file system. > > > > > > > > noexec check is done in __sgx_encl_add_page(), not in this callback. > > > > sgx_vma_mprotect() calls sgx_encl_may_map(), which iterates the > > > > addresses, checks that permissions are not surpassed and there are > > > > no holes. > > > > > > Yes, that's what I said. > > > > sgx_encl_add_page() will remove such page. The callback does not > > interact with this process as such pages never get to the enclave. > > I think we're in violent agreement, mostly. > > Userspace can add the page without EXEC permissions in the EPCM, and thus > avoid the noexec/VM_MAYEXEC check. The enclave can then do EMODPE to gain > EXEC permissions in the EPMC. Without the ->mprotect() hook, we wouldn't > be able to detect/prevent such shenanigans. Right, the VM_MAYEXEC in the code is nested under VM_EXEC check. I'm only wondering why not block noexec completely with any permissions, i.e. why not just have unconditional VM_MAYEXEC check? /Jarkko
[RFC PATCH v2] tools/x86: add kcpuid tool to show raw CPU features
End users frequently want to know what features their processor supports, independent of what the kernel supports. /proc/cpuinfo is great. It is omnipresent and since it is provided by the kernel it is always as up to date as the kernel. But, it could be ambiguous about processor features which can be disabled by the kernel at boot-time or compile-time. There are some user space tools showing more raw features, but they are not bound with kernel, and go with distros. Many end users are still using old distros with new kernels (upgraded by themselves), and may not upgrade the distros only to get a newer tool. So here arise the need for a new tool, which * Shows raw cpu features got from running cpuid * Be easier to obtain updates for compared to existing userspace tooling (perhaps distributed like perf) * Inherits "modern" kernel development process, in contrast to some of the existing userspace cpuid tools which are still being developed without git and distributed in tarballs from non-https sites. * Can produce output consistent with /proc/cpuinfo to make comparison easier. * Be in-kernel, could leverage kernel enabling, and even theoretically consume arch/x86/boot/cpustr.h so it could pick up new features directly from one-line X86_FEATURE_* definitions. This RFC is an early prototype, and would get community's opinion on whether it's the right thing to do, and what functions it should also support. It contains one .c core file and one text file which shows the bits definition of all CPUID output data, while in v1, a specific data structure is defined for each eax/ebx/ecx/edx output of each leaf and subleaf, which is less expandable [1]. The supported options are: Usage: kcpuid [-adfhr] [-l leaf] [-s subleaf] -a|--allShow info of all CPUID leafs and subleafs(default on) -d|--detail Show details of the flag/fields -f|--flags Show boolean flags only -h|--help Show usage info -l|--leaf=index Specify the leaf -r|--rawShow raw cpuid data -s|--subleaf=subSpecify the subleaf Current RFC version only shows limited number of cpu features, and will be completed This is based on the prototype code from Borislav Petkov [2]. output of the tool (output cut version) --- #kcpuid -r Basic Leafs: 0x: EAX=0x000d, EBX=0x756e6547, ECX=0x6c65746e, EDX=0x49656e69 0x0001: EAX=0x000206d7, EBX=0x0a200800, ECX=0x1fbee3ff, EDX=0xbfebfbff 0x0004: subleafs: 0: EAX=0x3c004121, EBX=0x01c0003f, ECX=0x003f, EDX=0x 1: EAX=0x3c004122, EBX=0x01c0003f, ECX=0x003f, EDX=0x 2: EAX=0x3c004143, EBX=0x01c0003f, ECX=0x01ff, EDX=0x Extended Leafs : 0x8000: EAX=0x8008, EBX=0x, ECX=0x, EDX=0x 0x8001: EAX=0x, EBX=0x, ECX=0x0001, EDX=0x2c100800 0x8002: EAX=0x20202020, EBX=0x49202020, ECX=0x6c65746e, EDX=0x20295228 ... #kcpuid -d max_basic_leafs : 0xd - Max input value for supported subleafs stepping: 0x7 - Stepping ID model : 0xd - Model family : 0x6 - Family ID processor : 0x0 - Processor Type sse3 - Streaming SIMD Extensions 3(SSE3) pclmulqdq- Support PCLMULQDQ instruction dtes64 - DS area uses 64-bit layout mwait- MONITOR/MWAIT supported ds_cpl - CPL Qualified Debug Store, which allows for branch message storage qualified by CPL vmx - Virtual Machine Extensions supported smx - Safer Mode Extension supported ... #kcpuid -f sse3 pclmulqdq dtes64 mwait ds_cpl vmx smx eist tm2 ... #kcpuid -l 0x1 stepping: 0x7 model : 0xd family : 0x6 processor : 0x0 clflush_size: 0x8 max_cpu_id : 0x20 apic_id : 0xf sse3 pclmulqdq dtes64 mwait ds_cpl ... [1]. https://lore.kernel.org/lkml/1598514543-90152-1-git-send-email-feng.t...@intel.com/ [2]. http://sr71.net/~dave/intel/stupid-cpuid.c Originally-by: Borislav Petkov Suggested-by: Dave Hansen Suggested-by: Borislav Petkov Signed-off-by: Feng Tang --- Changelog: v2: * use a new text file to store all the bits definition of each CPUID leaf/subleafs, which is easier for future expansion, as the core .c file
Re: [PATCH v18 20/32] mm/lru: replace pgdat lru_lock with lruvec lock
On Mon, 24 Aug 2020, Alex Shi wrote:
> This patch moves per node lru_lock into lruvec, thus bring a lru_lock for
> each of memcg per node. So on a large machine, each of memcg don't
> have to suffer from per node pgdat->lru_lock competition. They could go
> fast with their self lru_lock.
>
> After move memcg charge before lru inserting, page isolation could
> serialize page's memcg, then per memcg lruvec lock is stable and could
> replace per node lru lock.
>
> In func isolate_migratepages_block, compact_unlock_should_abort is
> opend, and lock_page_lruvec logical is embedded for tight process.
Hard to understand: perhaps:
In func isolate_migratepages_block, compact_unlock_should_abort and
lock_page_lruvec_irqsave are open coded to work with compact_control.
> Also add a debug func in locking which may give some clues if there are
> sth out of hands.
>
> According to Daniel Jordan's suggestion, I run 208 'dd' with on 104
> containers on a 2s * 26cores * HT box with a modefied case:
> https://git.kernel.org/pub/scm/linux/kernel/git/wfg/vm-scalability.git/tree/case-lru-file-readtwice
s/modeified/modified/
lruv19 has an lkml.org link there, please substitute
https://lore.kernel.org/lkml/01ed6e45-3853-dcba-61cb-b429a49a7...@linux.alibaba.com/
>
> With this and later patches, the readtwice performance increases
> about 80% within concurrent containers.
>
> On a large machine with memcg enabled but not used, the page's lruvec
> seeking pass a few pointers, that may lead to lru_lock holding time
> increase and a bit regression.
>
> Hugh Dickins helped on patch polish, thanks!
>
> Reported-by: kernel test robot
Eh? It may have reported some locking bugs somewhere, but this
is the main patch of your per-memcg lru_lock: I don't think the
kernel test robot inspired your whole design, did it? Delete that.
> Signed-off-by: Alex Shi
I can't quite Ack this one yet, because there are several functions
(mainly __munlock_pagevec and check_move_unevictable_pages) which are
not right in this v18 version, and a bit tricky to correct: I already
suggested what to do in other mail, but this patch comes before
relock_page_lruvec, so must look different from the final result;
I need to look at a later version, perhaps already there in your
github tree, before I can Ack: but it's not far off.
Comments below.
> Cc: Hugh Dickins
> Cc: Andrew Morton
> Cc: Johannes Weiner
> Cc: Michal Hocko
> Cc: Vladimir Davydov
> Cc: Yang Shi
> Cc: Matthew Wilcox
> Cc: Konstantin Khlebnikov
> Cc: Tejun Heo
> Cc: linux-kernel@vger.kernel.org
> Cc: linux...@kvack.org
> Cc: cgro...@vger.kernel.org
> ---
> include/linux/memcontrol.h | 58 +
> include/linux/mmzone.h | 2 +
> mm/compaction.c| 56 +++-
> mm/huge_memory.c | 11 ++---
> mm/memcontrol.c| 60 +-
> mm/mlock.c | 47 +---
> mm/mmzone.c| 1 +
> mm/swap.c | 105
> +
> mm/vmscan.c| 70 +-
> 9 files changed, 279 insertions(+), 131 deletions(-)
>
> diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
> index d0b036123c6a..7b170e9028b5 100644
> --- a/include/linux/memcontrol.h
> +++ b/include/linux/memcontrol.h
> @@ -494,6 +494,19 @@ static inline struct lruvec *mem_cgroup_lruvec(struct
> mem_cgroup *memcg,
>
> struct mem_cgroup *get_mem_cgroup_from_page(struct page *page);
>
> +struct lruvec *lock_page_lruvec(struct page *page);
> +struct lruvec *lock_page_lruvec_irq(struct page *page);
> +struct lruvec *lock_page_lruvec_irqsave(struct page *page,
> + unsigned long *flags);
> +
> +#ifdef CONFIG_DEBUG_VM
> +void lruvec_memcg_debug(struct lruvec *lruvec, struct page *page);
> +#else
> +static inline void lruvec_memcg_debug(struct lruvec *lruvec, struct page
> *page)
> +{
> +}
> +#endif
> +
> static inline
> struct mem_cgroup *mem_cgroup_from_css(struct cgroup_subsys_state *css){
> return css ? container_of(css, struct mem_cgroup, css) : NULL;
> @@ -1035,6 +1048,31 @@ static inline void mem_cgroup_put(struct mem_cgroup
> *memcg)
> {
> }
>
> +static inline struct lruvec *lock_page_lruvec(struct page *page)
> +{
> + struct pglist_data *pgdat = page_pgdat(page);
> +
> + spin_lock(>__lruvec.lru_lock);
> + return >__lruvec;
> +}
> +
> +static inline struct lruvec *lock_page_lruvec_irq(struct page *page)
> +{
> + struct pglist_data *pgdat = page_pgdat(page);
> +
> + spin_lock_irq(>__lruvec.lru_lock);
> + return >__lruvec;
> +}
> +
> +static inline struct lruvec *lock_page_lruvec_irqsave(struct page *page,
> + unsigned long *flagsp)
> +{
> + struct pglist_data *pgdat = page_pgdat(page);
> +
> + spin_lock_irqsave(>__lruvec.lru_lock, *flagsp);
> + return >__lruvec;
> +}
> +
> static inline
Re: [PATCH v2 13/13] x86/platform/uv: Update Copyrights to conform to HPE standards
On Mon, Sep 21, 2020 at 09:25:04PM -0500, Russ Anderson wrote: > On Thu, Sep 17, 2020 at 09:54:29AM +0200, Greg Kroah-Hartman wrote: > > On Wed, Sep 16, 2020 at 02:20:39PM -0500, Mike Travis wrote: > > > Add Copyrights to those files that have been updated for UV5 changes. > > > > > > Signed-off-by: Mike Travis > > > --- > > > arch/x86/include/asm/uv/bios.h | 1 + > > > arch/x86/include/asm/uv/uv_hub.h| 1 + > > > arch/x86/include/asm/uv/uv_mmrs.h | 1 + > > > arch/x86/kernel/apic/x2apic_uv_x.c | 1 + > > > arch/x86/platform/uv/bios_uv.c | 1 + > > > arch/x86/platform/uv/uv_nmi.c | 1 + > > > arch/x86/platform/uv/uv_time.c | 1 + > > > drivers/misc/sgi-gru/grufile.c | 1 + > > > drivers/misc/sgi-xp/xp.h| 1 + > > > drivers/misc/sgi-xp/xp_main.c | 1 + > > > drivers/misc/sgi-xp/xp_uv.c | 1 + > > > drivers/misc/sgi-xp/xpc_main.c | 1 + > > > drivers/misc/sgi-xp/xpc_partition.c | 1 + > > > drivers/misc/sgi-xp/xpnet.c | 1 + > > > 14 files changed, 14 insertions(+) > > > > > > diff --git a/arch/x86/include/asm/uv/bios.h > > > b/arch/x86/include/asm/uv/bios.h > > > index 97ac595ebc6a..08b3d810dfba 100644 > > > --- a/arch/x86/include/asm/uv/bios.h > > > +++ b/arch/x86/include/asm/uv/bios.h > > > @@ -5,6 +5,7 @@ > > > /* > > > * UV BIOS layer definitions. > > > * > > > + * (C) Copyright 2020 Hewlett Packard Enterprise Development LP > > > * Copyright (C) 2007-2017 Silicon Graphics, Inc. All rights reserved. > > > * Copyright (c) Russ Anderson > > > > Gotta love the different ways of text here :( > > > > Anyway, much better than before, thanks. > > The HPE copyright text is different than the old SGI copyright text. > We could update the SGI copyright line to be consistent, change > "Copyright (C)" to "(C) Copyright", if that is desired. > > The HPE lawyers said the old SGI copyrights do not need to be > updated as far as they are concerned, because HPE owns the SGI > copyrights, but they can. So the two lines could be combined to > > * (C) Copyright 2007-2017, 2020 Hewlett Packard Enterprise Development LP > > I will do whatever the lawyers and community want as far as format. What you did here is fine, it's just "fun" to see lawyers change their minds over time as to what the "correct" way to write these lines are. For extra fun, it turns out none of these lines are actually needed, it's just a real-world case of lawyer cargo-cult behavior :) thanks, greg k-h
Re: [PATCH] mm/shmem.c: Fix the missing unaccount on the failed path
On 9/21/20 2:49 AM, Hugh Dickins wrote:
On Mon, 21 Sep 2020, Tianjia Zhang wrote:
In function __shmem_file_setup(), shmem_unacct_size() is forgotten
on the failed path, so add it.
Fixes: 93dec2da7b234 ("... and switch shmem_file_setup() to
alloc_file_pseudo()")
Cc: Al Viro
Signed-off-by: Tianjia Zhang
---
mm/shmem.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/mm/shmem.c b/mm/shmem.c
index 8e2b35ba93ad..591410dc3541 100644
--- a/mm/shmem.c
+++ b/mm/shmem.c
@@ -4200,8 +4200,10 @@ static struct file *__shmem_file_setup(struct vfsmount
*mnt, const char *name, l
if (!IS_ERR(res))
res = alloc_file_pseudo(inode, mnt, name, O_RDWR,
_file_operations);
- if (IS_ERR(res))
+ if (IS_ERR(res)) {
iput(inode);
+ shmem_unacct_size(flags, size);
+ }
return res;
}
--
2.19.1.3.ge56e4f7
Looks mistaken to me.
Is this something you noticed by source inspection,
or something you have observed in practice?
I haven't tried exercising this path while injecting errors into
alloc_file_pseudo(); but what I'd expect to happen is that the
iput(inode), which you see already on that error path, will get
to evict the inode, which will entail calling shmem_evict_inode(),
which does that shmem_unacct_size() itself.
Hugh
I noticed by looking at the code. you are right, I neglected this point,
thanks for your explanation.
Thanks,
Tianjia
[PATCH] KVM: x86: emulate wait-for-SIPI and SIPI-VMExit
From: Yadong Qi
Background: We have a lightweight HV, it needs INIT-VMExit and
SIPI-VMExit to wake-up APs for guests since it do not monitor
the Local APIC. But currently virtual wait-for-SIPI(WFS) state
is not supported in nVMX, so when running on top of KVM, the L1
HV cannot receive the INIT-VMExit and SIPI-VMExit which cause
the L2 guest cannot wake up the APs.
According to Intel SDM Chapter 25.2 Other Causes of VM Exits,
SIPIs cause VM exits when a logical processor is in
wait-for-SIPI state.
In this patch:
1. introduce SIPI exit reason,
2. introduce wait-for-SIPI state for nVMX,
3. advertise wait-for-SIPI support to guest.
When L1 hypervisor is not monitoring Local APIC, L0 need to emulate
INIT-VMExit and SIPI-VMExit to L1 to emulate INIT-SIPI-SIPI for
L2. L2 LAPIC write would be traped by L0 Hypervisor(KVM), L0 should
emulate the INIT/SIPI vmexit to L1 hypervisor to set proper state
for L2's vcpu state.
Handle procdure:
Source vCPU:
L2 write LAPIC.ICR(INIT).
L0 trap LAPIC.ICR write(INIT): inject a latched INIT event to target
vCPU.
Target vCPU:
L0 emulate an INIT VMExit to L1 if is guest mode.
L1 set guest VMCS, guest_activity_state=WAIT_SIPI, vmresume.
L0 set vcpu.mp_state to INIT_RECEIVED if (vmcs12.guest_activity_state
== WAIT_SIPI).
Source vCPU:
L2 write LAPIC.ICR(SIPI).
L0 trap LAPIC.ICR write(INIT): inject a latched SIPI event to traget
vCPU.
Target vCPU:
L0 emulate an SIPI VMExit to L1 if (vcpu.mp_state == INIT_RECEIVED).
L1 set CS:IP, guest_activity_state=ACTIVE, vmresume.
L0 resume to L2.
L2 start-up.
Signed-off-by: Yadong Qi
---
arch/x86/include/asm/vmx.h | 1 +
arch/x86/include/uapi/asm/vmx.h | 2 ++
arch/x86/kvm/lapic.c| 5 ++--
arch/x86/kvm/vmx/nested.c | 53 -
4 files changed, 45 insertions(+), 16 deletions(-)
diff --git a/arch/x86/include/asm/vmx.h b/arch/x86/include/asm/vmx.h
index cd7de4b401fe..bff06dc64c52 100644
--- a/arch/x86/include/asm/vmx.h
+++ b/arch/x86/include/asm/vmx.h
@@ -113,6 +113,7 @@
#define VMX_MISC_PREEMPTION_TIMER_RATE_MASK0x001f
#define VMX_MISC_SAVE_EFER_LMA 0x0020
#define VMX_MISC_ACTIVITY_HLT 0x0040
+#define VMX_MISC_ACTIVITY_WAIT_SIPI0x0100
#define VMX_MISC_ZERO_LEN_INS 0x4000
#define VMX_MISC_MSR_LIST_MULTIPLIER 512
diff --git a/arch/x86/include/uapi/asm/vmx.h b/arch/x86/include/uapi/asm/vmx.h
index b8ff9e8ac0d5..ada955c5ebb6 100644
--- a/arch/x86/include/uapi/asm/vmx.h
+++ b/arch/x86/include/uapi/asm/vmx.h
@@ -32,6 +32,7 @@
#define EXIT_REASON_EXTERNAL_INTERRUPT 1
#define EXIT_REASON_TRIPLE_FAULT2
#define EXIT_REASON_INIT_SIGNAL3
+#define EXIT_REASON_SIPI_SIGNAL 4
#define EXIT_REASON_INTERRUPT_WINDOW7
#define EXIT_REASON_NMI_WINDOW 8
@@ -94,6 +95,7 @@
{ EXIT_REASON_EXTERNAL_INTERRUPT,"EXTERNAL_INTERRUPT" }, \
{ EXIT_REASON_TRIPLE_FAULT, "TRIPLE_FAULT" }, \
{ EXIT_REASON_INIT_SIGNAL, "INIT_SIGNAL" }, \
+ { EXIT_REASON_SIPI_SIGNAL, "SIPI_SIGNAL" }, \
{ EXIT_REASON_INTERRUPT_WINDOW, "INTERRUPT_WINDOW" }, \
{ EXIT_REASON_NMI_WINDOW,"NMI_WINDOW" }, \
{ EXIT_REASON_TASK_SWITCH, "TASK_SWITCH" }, \
diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
index 5ccbee7165a2..d04ac7dc6adf 100644
--- a/arch/x86/kvm/lapic.c
+++ b/arch/x86/kvm/lapic.c
@@ -2839,7 +2839,7 @@ void kvm_apic_accept_events(struct kvm_vcpu *vcpu)
/*
* INITs are latched while CPU is in specific states
-* (SMM, VMX non-root mode, SVM with GIF=0).
+* (SMM, SVM with GIF=0).
* Because a CPU cannot be in these states immediately
* after it has processed an INIT signal (and thus in
* KVM_MP_STATE_INIT_RECEIVED state), just eat SIPIs
@@ -2847,7 +2847,8 @@ void kvm_apic_accept_events(struct kvm_vcpu *vcpu)
*/
if (kvm_vcpu_latch_init(vcpu)) {
WARN_ON_ONCE(vcpu->arch.mp_state == KVM_MP_STATE_INIT_RECEIVED);
- if (test_bit(KVM_APIC_SIPI, >pending_events))
+ if (test_bit(KVM_APIC_SIPI, >pending_events) &&
+ !is_guest_mode(vcpu))
clear_bit(KVM_APIC_SIPI, >pending_events);
return;
}
diff --git a/arch/x86/kvm/vmx/nested.c b/arch/x86/kvm/vmx/nested.c
index 1bb6b31eb646..fe3bb68df987 100644
--- a/arch/x86/kvm/vmx/nested.c
+++ b/arch/x86/kvm/vmx/nested.c
@@ -2946,7 +2946,8 @@ static int nested_vmx_check_vmcs_link_ptr(struct kvm_vcpu
*vcpu,
static int nested_check_guest_non_reg_state(struct vmcs12 *vmcs12)
{
if (CC(vmcs12->guest_activity_state != GUEST_ACTIVITY_ACTIVE &&
- vmcs12->guest_activity_state != GUEST_ACTIVITY_HLT))
+ vmcs12->guest_activity_state != GUEST_ACTIVITY_HLT
Re: [PATCH 2/2] net/mlx5e: Use kfree() to free fd->g in accel_fs_tcp_create_groups()
On Mon, 2020-09-21 at 19:23 +0300, Denis Efremov wrote: > Memory ft->g in accel_fs_tcp_create_groups() is allocaed with > kcalloc(). > It's excessive to free ft->g with kvfree(). Use kfree() instead. > > Signed-off-by: Denis Efremov > --- > series applied to net-next-mlx5
Re: [PATCH RFT/RFC 01/49] staging: media: Revert "media: zoran: remove deprecated driver"
> + fh->buffers.buffer[i].v4l.fbuffer = mem; > + fh->buffers.buffer[i].v4l.fbuffer_phys = virt_to_phys(mem); > + fh->buffers.buffer[i].v4l.fbuffer_bus = virt_to_bus(mem); > + for (off = 0; off < fh->buffers.buffer_size; > + off += PAGE_SIZE) > + SetPageReserved(virt_to_page(mem + off)); This messing with SetPageReserved needs to go away before we bring back the driver, even for staging.
Re: general protection fault in perf_misc_flags
On Mon, Sep 21, 2020 at 10:59 PM 'Nick Desaulniers' via syzkaller-bugs wrote: > > On Mon, Sep 21, 2020 at 1:09 AM 'Dmitry Vyukov' via Clang Built Linux > wrote: > > > > On Mon, Sep 21, 2020 at 7:54 AM Dmitry Vyukov wrote: > > > > > > On Sat, Sep 19, 2020 at 1:08 PM Borislav Petkov wrote: > > > > > > > > On Sat, Sep 19, 2020 at 01:32:14AM -0700, syzbot wrote: > > > > > Hello, > > > > > > > > > > syzbot found the following issue on: > > > > > > > > > > HEAD commit:92ab97ad Merge tag 'sh-for-5.9-part2' of > > > > > git://git.libc.or.. > > > > > git tree: upstream > > > > > console output: > > > > > https://syzkaller.appspot.com/x/log.txt?x=1069669b90 > > > > > kernel config: > > > > > https://syzkaller.appspot.com/x/.config?x=cd992d74d6c7e62 > > > > > dashboard link: > > > > > https://syzkaller.appspot.com/bug?extid=ce179bc99e64377c24bc > > > > > compiler: clang version 10.0.0 > > > > > (https://github.com/llvm/llvm-project/ > > > > > c2443155a0fb245c8f17f2c1c72b6ea391e86e81) > > > > > > > > > > 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+ce179bc99e64377c2...@syzkaller.appspotmail.com > > > > > > > > > > general protection fault, probably for non-canonical address > > > > > 0x518084501e28: [#1] PREEMPT SMP KASAN > > > > > KASAN: maybe wild-memory-access in range > > > > > [0xfffaac042280f140-0xfffaac042280f147] > > > > > CPU: 0 PID: 17449 Comm: syz-executor.5 Not tainted > > > > > 5.9.0-rc5-syzkaller #0 > > > > > Hardware name: Google Google Compute Engine/Google Compute Engine, > > > > > BIOS Google 01/01/2011 > > > > > RIP: 0010:perf_misc_flags+0x125/0x150 arch/x86/events/core.c:2638 > > > > > Code: e4 48 83 e6 03 41 0f 94 c4 31 ff e8 95 fa 73 00 bb 02 00 00 00 > > > > > 4c 29 e3 49 81 c6 90 00 00 00 4c 89 f0 48 c1 e8 00 00 00 00 38 <00> > > > > > 74 08 4c 89 f7 e8 40 c0 b3 00 41 8b 06 83 e0 08 48 c1 e0 0b 48 > > > > > > > > Hmm, so converting this back to opcodes with decodecode gives: > > > > > > > > Code: e4 48 83 e6 03 41 0f 94 c4 31 ff e8 95 fa 73 00 bb 02 00 00 00 4c > > > > 29 e3 49 81 c6 90 00 00 00 4c 89 f0 48 c1 e8 00 00 00 00 38 <00> 74 08 > > > > 4c 89 f7 e8 40 c0 b3 00 41 8b 06 83 e0 08 48 c1 e0 0b 48 > > > > All code > > > > > > > >0: e4 48 in $0x48,%al > > > >2: 83 e6 03and$0x3,%esi > > > >5: 41 0f 94 c4 sete %r12b > > > >9: 31 ff xor%edi,%edi > > > >b: e8 95 fa 73 00 callq 0x73faa5 > > > > 10: bb 02 00 00 00 mov$0x2,%ebx > > > > 15: 4c 29 e3sub%r12,%rbx > > > > 18: 49 81 c6 90 00 00 00add$0x90,%r14 > > > > 1f: 4c 89 f0mov%r14,%rax > > > > 22: 48 c1 e8 00 shr$0x0,%rax > > > > 26: 00 00 add%al,(%rax) > > > > 28: 00 38 add%bh,(%rax) > > > > 2a:* 00 74 08 4c add%dh,0x4c(%rax,%rcx,1) > > > > <-- trapping instruction > > > > 2e: 89 f7 mov%esi,%edi > > > > 30: e8 40 c0 b3 00 callq 0xb3c075 > > > > 35: 41 8b 06mov(%r14),%eax > > > > 38: 83 e0 08and$0x8,%eax > > > > 3b: 48 c1 e0 0b shl$0xb,%rax > > > > 3f: 48 rex.W > > > > > > > > and those ADDs before the rIP look real strange. Just as if something > > > > wrote 4 bytes of 0s there. And building your config with clang-10 gives > > > > around that area: > > > > > > > > 8101177c: 48 83 e6 03 and$0x3,%rsi > > > > 81011780: 41 0f 94 c4 sete %r12b > > > > 81011784: 31 ff xor%edi,%edi > > > > 81011786: e8 05 c9 73 00 callq 8174e090 > > > > <__sanitizer_cov_trace_const_cmp8> > > > > 8101178b: bb 02 00 00 00 mov$0x2,%ebx > > > > 81011790: 4c 29 e3sub%r12,%rbx > > > > 81011793: 49 81 c6 90 00 00 00add$0x90,%r14 > > > > 8101179a: 4c 89 f0mov%r14,%rax > > > > 8101179d: 48 c1 e8 03 shr$0x3,%rax > > > > 810117a1: 42 80 3c 38 00 cmpb > > > > $0x0,(%rax,%r15,1) > > > > 810117a6: 74 08 je 810117b0 > > > > > > > > 810117a8: 4c 89 f7mov%r14,%rdi > > > > 810117ab: e8 20 75 b3 00 callq 81b48cd0 > > > > <__asan_report_load8_noabort> > > > > 810117b0: 41 8b 06mov(%r14),%eax > > > > 810117b3: 83 e0 08and$0x8,%eax > > > > 810117b6: 48 c1 e0 0b
[PATCH v3 1/3] dt-bindings: vendor-prefixes: Add an entry for Plymovent
Add "ply" entry for Plymovent Group BV: https://www.plymovent.com/ Signed-off-by: Oleksij Rempel --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 2baee2c817c1..60b59ca04066 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -818,6 +818,8 @@ patternProperties: description: PLDA "^plx,.*": description: Broadcom Corporation (formerly PLX Technology) + "^ply,.*": +description: Plymovent Group BV "^pni,.*": description: PNI Sensor Corporation "^pocketbook,.*": -- 2.28.0
[PATCH v3 0/3] mainline Plymovent M2M board
changes v3: - use old style copyright text changes v2: - fsl.yaml: reorder ply,plym2m - imx6dl-plym2m.dts: use hyphen instead of underscore in phy-clock Oleksij Rempel (3): dt-bindings: vendor-prefixes: Add an entry for Plymovent dt-bindings: arm: fsl: add Plymovent M2M board ARM: dts: add Plymovent M2M board .../devicetree/bindings/arm/fsl.yaml | 1 + .../devicetree/bindings/vendor-prefixes.yaml | 2 + arch/arm/boot/dts/Makefile| 1 + arch/arm/boot/dts/imx6dl-plym2m.dts | 396 ++ 4 files changed, 400 insertions(+) create mode 100644 arch/arm/boot/dts/imx6dl-plym2m.dts -- 2.28.0
[PATCH v3 3/3] ARM: dts: add Plymovent M2M board
Plymovent M2M is a control interface produced for the Plymovent filter
systems.
Signed-off-by: David Jander
Signed-off-by: Oleksij Rempel
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/imx6dl-plym2m.dts | 396
2 files changed, 397 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6dl-plym2m.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 4572db3fa5ae..3c3811fd8613 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -455,6 +455,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
imx6dl-pico-hobbit.dtb \
imx6dl-pico-nymph.dtb \
imx6dl-pico-pi.dtb \
+ imx6dl-plym2m.dtb \
imx6dl-prtrvt.dtb \
imx6dl-prtvt7.dtb \
imx6dl-rex-basic.dtb \
diff --git a/arch/arm/boot/dts/imx6dl-plym2m.dts
b/arch/arm/boot/dts/imx6dl-plym2m.dts
new file mode 100644
index ..42b970c2dd74
--- /dev/null
+++ b/arch/arm/boot/dts/imx6dl-plym2m.dts
@@ -0,0 +1,396 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/*
+ * Copyright (c) 2014 Protonic Holland
+ * Copyright (c) 2020 Oleksij Rempel , Pengutronix
+ */
+
+/dts-v1/;
+#include
+#include
+#include "imx6dl.dtsi"
+
+/ {
+ model = "Plymovent M2M board";
+ compatible = "ply,plym2m", "fsl,imx6dl";
+
+ chosen {
+ stdout-path =
+ };
+
+ backlight: backlight {
+ compatible = "pwm-backlight";
+ pwms = < 0 50 0>;
+ brightness-levels = <0 1000>;
+ num-interpolated-steps = <20>;
+ default-brightness-level = <19>;
+ power-supply = <_12v0>;
+ };
+
+ display {
+ compatible = "fsl,imx-parallel-display";
+ pinctrl-0 = <_ipu1_disp>;
+ pinctrl-names = "default";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ display_in: endpoint {
+ remote-endpoint = <_di0_disp0>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ display_out: endpoint {
+ remote-endpoint = <_in>;
+ };
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <_leds>;
+
+ led-debug {
+ function = LED_FUNCTION_STATUS;
+ gpios = < 8 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "heartbeat";
+ };
+ };
+
+ panel {
+ compatible = "edt,etm0700g0bdh6";
+ backlight = <>;
+ power-supply = <_3v3>;
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <_out>;
+ };
+ };
+ };
+
+ clk50m_phy: phy-clock {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <5000>;
+ };
+
+ reg_3v3: regulator-3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "3v3";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ };
+
+ reg_5v0: regulator-5v0 {
+ compatible = "regulator-fixed";
+ regulator-name = "5v0";
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ };
+
+ reg_12v0: regulator-12v0 {
+ compatible = "regulator-fixed";
+ regulator-name = "12v0";
+ regulator-min-microvolt = <1200>;
+ regulator-max-microvolt = <1200>;
+ };
+};
+
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_can1>;
+ xceiver-supply = <_5v0>;
+ status = "okay";
+};
+
+ {
+ cs-gpios = < 19 GPIO_ACTIVE_LOW>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_ecspi1>;
+ status = "okay";
+
+ flash@0 {
+ compatible = "jedec,spi-nor";
+ reg = <0>;
+ spi-max-frequency = <2000>;
+ };
+};
+
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_enet>;
+ phy-mode = "rmii";
+ clocks = < IMX6QDL_CLK_ENET>,
+< IMX6QDL_CLK_ENET>,
+<_phy>;
+ clock-names = "ipg", "ahb", "ptp";
+ status = "okay";
+
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* Microchip KSZ8081RNA PHY */
+ rgmii_phy: ethernet-phy@0 {
+ reg = <0>;
+ interrupts-extended = < 23 IRQ_TYPE_LEVEL_LOW>;
+ reset-gpios = < 22
Re: general protection fault in perf_misc_flags
On Mon, Sep 21, 2020 at 10:59 PM 'Nick Desaulniers' via syzkaller-bugs wrote: > > On Mon, Sep 21, 2020 at 1:09 AM 'Dmitry Vyukov' via Clang Built Linux > wrote: > > > > On Mon, Sep 21, 2020 at 7:54 AM Dmitry Vyukov wrote: > > > > > > On Sat, Sep 19, 2020 at 1:08 PM Borislav Petkov wrote: > > > > > > > > On Sat, Sep 19, 2020 at 01:32:14AM -0700, syzbot wrote: > > > > > Hello, > > > > > > > > > > syzbot found the following issue on: > > > > > > > > > > HEAD commit:92ab97ad Merge tag 'sh-for-5.9-part2' of > > > > > git://git.libc.or.. > > > > > git tree: upstream > > > > > console output: > > > > > https://syzkaller.appspot.com/x/log.txt?x=1069669b90 > > > > > kernel config: > > > > > https://syzkaller.appspot.com/x/.config?x=cd992d74d6c7e62 > > > > > dashboard link: > > > > > https://syzkaller.appspot.com/bug?extid=ce179bc99e64377c24bc > > > > > compiler: clang version 10.0.0 > > > > > (https://github.com/llvm/llvm-project/ > > > > > c2443155a0fb245c8f17f2c1c72b6ea391e86e81) > > > > > > > > > > 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+ce179bc99e64377c2...@syzkaller.appspotmail.com > > > > > > > > > > general protection fault, probably for non-canonical address > > > > > 0x518084501e28: [#1] PREEMPT SMP KASAN > > > > > KASAN: maybe wild-memory-access in range > > > > > [0xfffaac042280f140-0xfffaac042280f147] > > > > > CPU: 0 PID: 17449 Comm: syz-executor.5 Not tainted > > > > > 5.9.0-rc5-syzkaller #0 > > > > > Hardware name: Google Google Compute Engine/Google Compute Engine, > > > > > BIOS Google 01/01/2011 > > > > > RIP: 0010:perf_misc_flags+0x125/0x150 arch/x86/events/core.c:2638 > > > > > Code: e4 48 83 e6 03 41 0f 94 c4 31 ff e8 95 fa 73 00 bb 02 00 00 00 > > > > > 4c 29 e3 49 81 c6 90 00 00 00 4c 89 f0 48 c1 e8 00 00 00 00 38 <00> > > > > > 74 08 4c 89 f7 e8 40 c0 b3 00 41 8b 06 83 e0 08 48 c1 e0 0b 48 > > > > > > > > Hmm, so converting this back to opcodes with decodecode gives: > > > > > > > > Code: e4 48 83 e6 03 41 0f 94 c4 31 ff e8 95 fa 73 00 bb 02 00 00 00 4c > > > > 29 e3 49 81 c6 90 00 00 00 4c 89 f0 48 c1 e8 00 00 00 00 38 <00> 74 08 > > > > 4c 89 f7 e8 40 c0 b3 00 41 8b 06 83 e0 08 48 c1 e0 0b 48 > > > > All code > > > > > > > >0: e4 48 in $0x48,%al > > > >2: 83 e6 03and$0x3,%esi > > > >5: 41 0f 94 c4 sete %r12b > > > >9: 31 ff xor%edi,%edi > > > >b: e8 95 fa 73 00 callq 0x73faa5 > > > > 10: bb 02 00 00 00 mov$0x2,%ebx > > > > 15: 4c 29 e3sub%r12,%rbx > > > > 18: 49 81 c6 90 00 00 00add$0x90,%r14 > > > > 1f: 4c 89 f0mov%r14,%rax > > > > 22: 48 c1 e8 00 shr$0x0,%rax > > > > 26: 00 00 add%al,(%rax) > > > > 28: 00 38 add%bh,(%rax) > > > > 2a:* 00 74 08 4c add%dh,0x4c(%rax,%rcx,1) > > > > <-- trapping instruction > > > > 2e: 89 f7 mov%esi,%edi > > > > 30: e8 40 c0 b3 00 callq 0xb3c075 > > > > 35: 41 8b 06mov(%r14),%eax > > > > 38: 83 e0 08and$0x8,%eax > > > > 3b: 48 c1 e0 0b shl$0xb,%rax > > > > 3f: 48 rex.W > > > > > > > > and those ADDs before the rIP look real strange. Just as if something > > > > wrote 4 bytes of 0s there. And building your config with clang-10 gives > > > > around that area: > > > > > > > > 8101177c: 48 83 e6 03 and$0x3,%rsi > > > > 81011780: 41 0f 94 c4 sete %r12b > > > > 81011784: 31 ff xor%edi,%edi > > > > 81011786: e8 05 c9 73 00 callq 8174e090 > > > > <__sanitizer_cov_trace_const_cmp8> > > > > 8101178b: bb 02 00 00 00 mov$0x2,%ebx > > > > 81011790: 4c 29 e3sub%r12,%rbx > > > > 81011793: 49 81 c6 90 00 00 00add$0x90,%r14 > > > > 8101179a: 4c 89 f0mov%r14,%rax > > > > 8101179d: 48 c1 e8 03 shr$0x3,%rax > > > > 810117a1: 42 80 3c 38 00 cmpb > > > > $0x0,(%rax,%r15,1) > > > > 810117a6: 74 08 je 810117b0 > > > > > > > > 810117a8: 4c 89 f7mov%r14,%rdi > > > > 810117ab: e8 20 75 b3 00 callq 81b48cd0 > > > > <__asan_report_load8_noabort> > > > > 810117b0: 41 8b 06mov(%r14),%eax > > > > 810117b3: 83 e0 08and$0x8,%eax > > > > 810117b6: 48 c1 e0 0b
[PATCH v3 2/3] dt-bindings: arm: fsl: add Plymovent M2M board
Add Plymovent Group BV M2M iMX6dl based board Signed-off-by: Oleksij Rempel --- Documentation/devicetree/bindings/arm/fsl.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml index 6da9d734cdb7..e94a455eeab9 100644 --- a/Documentation/devicetree/bindings/arm/fsl.yaml +++ b/Documentation/devicetree/bindings/arm/fsl.yaml @@ -174,6 +174,7 @@ properties: - fsl,imx6dl-sabreauto # i.MX6 DualLite/Solo SABRE Automotive Board - fsl,imx6dl-sabresd# i.MX6 DualLite SABRE Smart Device Board - kontron,imx6dl-samx6i # Kontron i.MX6 Solo SMARC Module + - ply,plym2m# Plymovent M2M board - prt,prtrvt# Protonic RVT board - prt,prtvt7# Protonic VT7 board - technexion,imx6dl-pico-dwarf # TechNexion i.MX6DL Pico-Dwarf -- 2.28.0
Re: [PATCH RFT/RFC 06/49] staging: media: zoran: unsplit lines
On Mon, Sep 21, 2020 at 10:19:41AM +, Corentin Labbe wrote: > This patch un-split some lines. > Signed-off-by: Corentin Labbe Just don't do this. This is a purious change going over 80 chars for absolutely no reason, and you'd still need a very good reason for that.
Re: [PATCH RFT/RFC 24/49] staging: media: zoran: Use DMA coherent for stat_com
On Mon, Sep 21, 2020 at 10:19:59AM +, Corentin Labbe wrote:
> Instead of using a fragile virt_to_bus, let's use proper DMA coherent
> for the stat_com entry.
>
> Signed-off-by: Corentin Labbe
> ---
> drivers/staging/media/zoran/zoran.h| 2 ++
> drivers/staging/media/zoran/zoran_card.c | 20 +---
> drivers/staging/media/zoran/zoran_device.c | 3 +--
> 3 files changed, 16 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/staging/media/zoran/zoran.h
> b/drivers/staging/media/zoran/zoran.h
> index aa2a8f688a01..8f3faa4eb60f 100644
> --- a/drivers/staging/media/zoran/zoran.h
> +++ b/drivers/staging/media/zoran/zoran.h
> @@ -351,6 +351,8 @@ struct zoran {
> unsigned long frame_num;
>
> wait_queue_head_t test_q;
> +
> + dma_addr_t p_sc;
> };
>
> static inline struct zoran *to_zoran(struct v4l2_device *v4l2_dev)
> diff --git a/drivers/staging/media/zoran/zoran_card.c
> b/drivers/staging/media/zoran/zoran_card.c
> index 3a7895be3341..a8d23bf126c3 100644
> --- a/drivers/staging/media/zoran/zoran_card.c
> +++ b/drivers/staging/media/zoran/zoran_card.c
> @@ -931,11 +931,15 @@ static int zr36057_init(struct zoran *zr)
> zoran_open_init_params(zr);
>
> /* allocate memory *before* doing anything to the hardware in case
> allocation fails */
> - zr->stat_com = kzalloc(BUZ_NUM_STAT_COM * 4, GFP_KERNEL);
> zr->video_dev = video_device_alloc();
> - if (!zr->stat_com || !zr->video_dev) {
> + if (!zr->video_dev) {
> err = -ENOMEM;
> - goto exit_free;
> + goto exit;
> + }
> + zr->stat_com = dma_alloc_coherent(>pci_dev->dev, BUZ_NUM_STAT_COM *
> sizeof(u32), >p_sc, GFP_KERNEL);
Again, don't write junk coe like this. Stick to the 80 lines unless
you have a very good reason.
Re: NVFS XFS metadata (was: [PATCH] pmem: export the symbols __copy_user_flushcache and __copy_from_user_flushcache)
Hi Mikulas, I'll say up front that I think you're barking up the wrong tree trying to knock down XFS and ext4 to justify NVFS. NVFS will stand or fall on it's own merits, not on how you think it's better than other filesystems... I have some fundamental concerns about the NVFS integrity model, they came out as I wrote this response to your characterisations of XFS and journalling filesysetms. Maybe I'm missing something about NVFS that isn't clearly explained On Mon, Sep 21, 2020 at 12:20:42PM -0400, Mikulas Patocka wrote: > On Wed, 16 Sep 2020, Mikulas Patocka wrote: > > On Wed, 16 Sep 2020, Dan Williams wrote: > > > On Wed, Sep 16, 2020 at 10:24 AM Mikulas Patocka > > > wrote: > > > > > > > > > My first question about nvfs is how it compares to a daxfs with > > > > > executables and other binaries configured to use page cache with the > > > > > new per-file dax facility? > > > > > > > > nvfs is faster than dax-based filesystems on metadata-heavy operations > > > > because it doesn't have the overhead of the buffer cache and bios. See > > > > this: http://people.redhat.com/~mpatocka/nvfs/BENCHMARKS > > > > > > ...and that metadata problem is intractable upstream? Christoph poked > > > at bypassing the block layer for xfs metadata operations [1], I just > > > have not had time to carry that further. > > > > > > [1]: "xfs: use dax_direct_access for log writes", although it seems > > > he's dropped that branch from his xfs.git > > > > XFS is very big. I wanted to create something small. > > And the another difference is that XFS metadata are optimized for disks > and SSDs. Ah, that old chestnut. :) > On disks and SSDs, reading one byte is as costly as reading a full block. > So we must put as much information to a block as possible. XFS uses > b+trees for file block mapping and for directories - it is reasonable > decision because b+trees minimize the number of disk accesses. Actually, no, that wasn't why XFS was implemented using btrees. The btrees are an implementation detail, not a design requirement to minimise the number of disk accesses. XFS was intended for huge disk arrays (hundreds to thousands on individual spindles) and so no attempt was made in the design to minimise disk accesses. There was -always- going to be a huge number of IOPS available in the intended large scale deployments, so concurrency and *efficiency at scale* was far more important at the design level than minimising the number of disk ops for any given operation. To that end, simulations were done that showed that extent based trees were much more CPU, memory and IO efficient than bitmaps, hybrid tree-bitmaps or multi-layer indirect block referencing when trying to index and access large amounts of data. To be efficient at scale, all operations need to be O(log N) or better, and extent based encoding is much, more compact than direct block indexing. Extent trees are also much more effective for finding exact fits, identifying large contiguous spaces, and manipulating large ranges of indexed data than other filesystem indexing mechanisms. They are also not bound by alignment restrictions like hierarchical binary/buddy bitmap schemes are, and their maximum size is bounded and can be calculated at runtime. IOWs, extent based trees were chosen because of scalability, efficiency, and flexibility reasons before the actual tree structure that it would be implemented with was decided on. b+trees were used in the implementation because one tree implementation could do everything as all that needed to change btree trees was the pointer and record format. The result of this is that we have made -zero- changes to the XFS structure and algorithms for SSDs. We don't do different things based on the blkdev rotational flag, or anything like that. XFS behaves exactly the same on spinning disks as it does SSDs as it does PMEM and it performs well on all of them. And that performance doesn't drop away as you increase the scale and capability of the underlying storage. That's what happens when storage algorithms are designed for concurrency and efficiency at scale rather than optimising for a specific storage characteristic. NVFS is optimised for a specific storage characteristic (i.e. low latency synchronous storage), so I would absolutely expect it to be faster than XFS on that specific storage. However, claims like this: > On persistent memory, each access has its own cost, so NVFS uses metadata > structures that minimize the number of cache lines accessed (rather than > the number of blocks accessed). For block mapping, NVFS uses the classic > unix dierct/indirect blocks - if a file block is mapped by a 3-rd level > indirect block, we do just three memory accesses and we are done. If we > used b+trees, the number of accesses would be much larger than 3 (we would > have to do binary search in the b+tree nodes). ... are kinda naive, because you're clearly optimising the wrong aspect of block mapping. Extents
Re: [PATCH v18 19/32] mm/swap.c: serialize memcg changes in pagevec_lru_move_fn
在 2020/9/22 上午8:42, Hugh Dickins 写道:
> On Mon, 24 Aug 2020, Alex Shi wrote:
>
>> Hugh Dickins' found a memcg change bug on original version:
>> If we want to change the pgdat->lru_lock to memcg's lruvec lock, we have
>> to serialize mem_cgroup_move_account during pagevec_lru_move_fn. The
>> possible bad scenario would like:
>>
>> cpu 0 cpu 1
>> lruvec = mem_cgroup_page_lruvec()
>> if (!isolate_lru_page())
>> mem_cgroup_move_account
>>
>> spin_lock_irqsave(>lru_lock <== wrong lock.
>>
>> So we need the ClearPageLRU to block isolate_lru_page(), that serializes
>
> s/the ClearPageLRU/TestClearPageLRU/
Thanks, will change it.
>
>> the memcg change. and then removing the PageLRU check in move_fn callee
>> as the consequence.
>
> Deserves another paragraph about __pagevec_lru_add():
> "__pagevec_lru_add_fn() is different from the others, because the pages
> it deals with are, by definition, not yet on the lru. TestClearPageLRU
> is not needed and would not work, so __pagevec_lru_add() goes its own way."
Thanks for comments! will add it into new commit log.
>
>>
>> Reported-by: Hugh Dickins
>
> True.
>
>> Signed-off-by: Hugh Dickins
>
> I did provide some lines, but I think it's just
> Acked-by: Hugh Dickins
> to go below your Signed-off-by.
Thanks!
>
>> Signed-off-by: Alex Shi
>> Cc: Andrew Morton
>> Cc: linux...@kvack.org
>> Cc: linux-kernel@vger.kernel.org
>> ---
>> mm/swap.c | 44 +++-
>> 1 file changed, 35 insertions(+), 9 deletions(-)
>
> In your lruv19 branch, this patch got renamed (s/moveing/moving/):
> but I think it's better with the old name used here in v18, and without
> those mm/vmscan.c mods to check_move_unevictable_pages() tacked on:
> please move those back to 16/32, which already makes changes to vmscan.c.
>
Yes, will move that part there.
Thanks!
Alex
>>
>> diff --git a/mm/swap.c b/mm/swap.c
>> index 446ffe280809..2d9a86bf93a4 100644
>> --- a/mm/swap.c
>> +++ b/mm/swap.c
>> @@ -221,8 +221,14 @@ static void pagevec_lru_move_fn(struct pagevec *pvec,
>> spin_lock_irqsave(>lru_lock, flags);
>> }
>>
>> +/* block memcg migration during page moving between lru */
>> +if (!TestClearPageLRU(page))
>> +continue;
>> +
>> lruvec = mem_cgroup_page_lruvec(page, pgdat);
>> (*move_fn)(page, lruvec);
>> +
>> +SetPageLRU(page);
>> }
>> if (pgdat)
>> spin_unlock_irqrestore(>lru_lock, flags);
>> @@ -232,7 +238,7 @@ static void pagevec_lru_move_fn(struct pagevec *pvec,
>>
>> static void pagevec_move_tail_fn(struct page *page, struct lruvec *lruvec)
>> {
>> -if (PageLRU(page) && !PageUnevictable(page)) {
>> +if (!PageUnevictable(page)) {
>> del_page_from_lru_list(page, lruvec, page_lru(page));
>> ClearPageActive(page);
>> add_page_to_lru_list_tail(page, lruvec, page_lru(page));
>> @@ -306,7 +312,7 @@ void lru_note_cost_page(struct page *page)
>>
>> static void __activate_page(struct page *page, struct lruvec *lruvec)
>> {
>> -if (PageLRU(page) && !PageActive(page) && !PageUnevictable(page)) {
>> +if (!PageActive(page) && !PageUnevictable(page)) {
>> int lru = page_lru_base_type(page);
>> int nr_pages = thp_nr_pages(page);
>>
>> @@ -362,7 +368,8 @@ void activate_page(struct page *page)
>>
>> page = compound_head(page);
>> spin_lock_irq(>lru_lock);
>> -__activate_page(page, mem_cgroup_page_lruvec(page, pgdat));
>> +if (PageLRU(page))
>> +__activate_page(page, mem_cgroup_page_lruvec(page, pgdat));
>> spin_unlock_irq(>lru_lock);
>> }
>> #endif
>
> Every time I look at this, I wonder if that's right, or an unnecessary
> optimization strayed in, or whatever. For the benefit of others looking
> at this patch, yes it is right: this is the !CONFIG_SMP alternative
> version of activate_page(), and needs that PageLRU check to compensate
> for the check that has now been removed from __activate_page() itself.
>
>> @@ -521,9 +528,6 @@ static void lru_deactivate_file_fn(struct page *page,
>> struct lruvec *lruvec)
>> bool active;
>> int nr_pages = thp_nr_pages(page);
>>
>> -if (!PageLRU(page))
>> -return;
>> -
>> if (PageUnevictable(page))
>> return;
>>
>> @@ -564,7 +568,7 @@ static void lru_deactivate_file_fn(struct page *page,
>> struct lruvec *lruvec)
>>
>> static void lru_deactivate_fn(struct page *page, struct lruvec *lruvec)
>> {
>> -if (PageLRU(page) && PageActive(page) && !PageUnevictable(page)) {
>> +if (PageActive(page) && !PageUnevictable(page)) {
>> int lru = page_lru_base_type(page);
>> int nr_pages = thp_nr_pages(page);
>>
>> @@ -581,7 +585,7 @@ static void
Re: [PATCH 5.8 000/118] 5.8.11-rc1 review
On Mon, 21 Sep 2020 at 22:14, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 5.8.11 release. > There are 118 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Wed, 23 Sep 2020 16:20:12 +. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.8.11-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-5.8.y > and the diffstat can be found below. > > thanks, > > greg k-h > Results from Linaro’s test farm. No regressions on arm64, arm, x86_64, and i386. Tested-by: Linux Kernel Functional Testing Summary kernel: 5.8.11-rc1 git repo: https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc git branch: linux-5.8.y git commit: f2ae9d9cdf48e015834ce21030249793bf0c44f5 git describe: v5.8.9-296-gf2ae9d9cdf48 Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.8.y/build/v5.8.9-296-gf2ae9d9cdf48 No regressions (compared to build v5.8.9-178-g337aafeeb4cd) No fixes (compared to build v5.8.9-178-g337aafeeb4cd) Ran 36879 total tests in the following environments and test suites. Environments -- - dragonboard-410c - hi6220-hikey - i386 - juno-r2 - juno-r2-compat - juno-r2-kasan - nxp-ls2088 - qemu_arm - qemu_arm64 - qemu_i386 - qemu_x86_64 - x15 - x86 - x86-kasan Test Suites --- * libhugetlbfs * linux-log-parser * ltp-cap_bounds-tests * ltp-commands-tests * ltp-containers-tests * ltp-controllers-tests * ltp-cpuhotplug-tests * ltp-crypto-tests * ltp-cve-tests * ltp-dio-tests * ltp-fcntl-locktests-tests * ltp-filecaps-tests * ltp-fs_bind-tests * ltp-fs_perms_simple-tests * ltp-fsx-tests * ltp-hugetlb-tests * ltp-io-tests * ltp-ipc-tests * ltp-math-tests * ltp-mm-tests * ltp-nptl-tests * ltp-pty-tests * ltp-sched-tests * ltp-securebits-tests * ltp-syscalls-tests * v4l2-compliance * ltp-fs-tests * ltp-open-posix-tests * ltp-tracing-tests * network-basic-tests * kselftest-vsyscall-mode-native * kselftest-vsyscall-mode-native/drivers * kselftest-vsyscall-mode-native/filesystems * kselftest-vsyscall-mode-native/net * kselftest-vsyscall-mode-none * kselftest-vsyscall-mode-none/drivers * kselftest-vsyscall-mode-none/filesystems * kselftest-vsyscall-mode-none/net -- Linaro LKFT https://lkft.linaro.org
Re: [PATCH v18 17/32] mm/compaction: do page isolation first in compaction
在 2020/9/22 上午7:49, Hugh Dickins 写道:
> On Mon, 24 Aug 2020, Alex Shi wrote:
>
>> Currently, compaction would get the lru_lock and then do page isolation
>> which works fine with pgdat->lru_lock, since any page isoltion would
>> compete for the lru_lock. If we want to change to memcg lru_lock, we
>> have to isolate the page before getting lru_lock, thus isoltion would
>> block page's memcg change which relay on page isoltion too. Then we
>> could safely use per memcg lru_lock later.
>>
>> The new page isolation use previous introduced TestClearPageLRU() +
>> pgdat lru locking which will be changed to memcg lru lock later.
>>
>> Hugh Dickins fixed following bugs in this patch's
>> early version:
>>
>> Fix lots of crashes under compaction load: isolate_migratepages_block()
>> must clean up appropriately when rejecting a page, setting PageLRU again
>> if it had been cleared; and a put_page() after get_page_unless_zero()
>> cannot safely be done while holding locked_lruvec - it may turn out to
>> be the final put_page(), which will take an lruvec lock when PageLRU.
>> And move __isolate_lru_page_prepare back after get_page_unless_zero to
>> make trylock_page() safe:
>> trylock_page() is not safe to use at this time: its setting PG_locked
>> can race with the page being freed or allocated ("Bad page"), and can
>> also erase flags being set by one of those "sole owners" of a freshly
>> allocated page who use non-atomic __SetPageFlag().
>>
>> Suggested-by: Johannes Weiner
>> Signed-off-by: Hugh Dickins
>> Signed-off-by: Alex Shi
>
> Okay, whatever. I was about to say
> Acked-by: Hugh Dickins
Thanks!
> With my signed-off-by there, someone will ask if it should say
> "From: Hugh ..." at the top: no, it should not, this is Alex's patch,
> but I proposed some fixes to it, as you already acknowledged.
I guess you prefer to remove your signed off here, don't you?
>
> A couple of comments below on the mm/vmscan.c part of it.
>
>> Cc: Andrew Morton
>> Cc: Matthew Wilcox
>> Cc: linux-kernel@vger.kernel.org
>> Cc: linux...@kvack.org
>> ---
>> include/linux/swap.h | 2 +-
>> mm/compaction.c | 42 +-
>> mm/vmscan.c | 46 ++
>> 3 files changed, 60 insertions(+), 30 deletions(-)
>>
>> diff --git a/include/linux/swap.h b/include/linux/swap.h
>> index 43e6b3458f58..550fdfdc3506 100644
>> --- a/include/linux/swap.h
>> +++ b/include/linux/swap.h
>> @@ -357,7 +357,7 @@ extern void lru_cache_add_inactive_or_unevictable(struct
>> page *page,
>> extern unsigned long zone_reclaimable_pages(struct zone *zone);
>> extern unsigned long try_to_free_pages(struct zonelist *zonelist, int order,
>> gfp_t gfp_mask, nodemask_t *mask);
>> -extern int __isolate_lru_page(struct page *page, isolate_mode_t mode);
>> +extern int __isolate_lru_page_prepare(struct page *page, isolate_mode_t
>> mode);
>> extern unsigned long try_to_free_mem_cgroup_pages(struct mem_cgroup *memcg,
>>unsigned long nr_pages,
>>gfp_t gfp_mask,
>> diff --git a/mm/compaction.c b/mm/compaction.c
>> index 4e2c66869041..253382d99969 100644
>> --- a/mm/compaction.c
>> +++ b/mm/compaction.c
>> @@ -887,6 +887,7 @@ static bool too_many_isolated(pg_data_t *pgdat)
>> if (!valid_page && IS_ALIGNED(low_pfn, pageblock_nr_pages)) {
>> if (!cc->ignore_skip_hint && get_pageblock_skip(page)) {
>> low_pfn = end_pfn;
>> +page = NULL;
>> goto isolate_abort;
>> }
>> valid_page = page;
>> @@ -968,6 +969,21 @@ static bool too_many_isolated(pg_data_t *pgdat)
>> if (!(cc->gfp_mask & __GFP_FS) && page_mapping(page))
>> goto isolate_fail;
>>
>> +/*
>> + * Be careful not to clear PageLRU until after we're
>> + * sure the page is not being freed elsewhere -- the
>> + * page release code relies on it.
>> + */
>> +if (unlikely(!get_page_unless_zero(page)))
>> +goto isolate_fail;
>> +
>> +if (__isolate_lru_page_prepare(page, isolate_mode) != 0)
>> +goto isolate_fail_put;
>> +
>> +/* Try isolate the page */
>> +if (!TestClearPageLRU(page))
>> +goto isolate_fail_put;
>> +
>> /* If we already hold the lock, we can skip some rechecking */
>> if (!locked) {
>> locked = compact_lock_irqsave(>lru_lock,
>> @@ -980,10 +996,6 @@ static bool too_many_isolated(pg_data_t *pgdat)
>> goto isolate_abort;
>> }
>>
>> -/* Recheck PageLRU and PageCompound under lock */
>> -
Re: [PATCH v2 1/2] PM / Domains: Add GENPD_FLAG_NO_SUSPEND/RESUME flags
On 2020-09-22 01:26, Stephen Boyd wrote: Quoting Rafael J. Wysocki (2020-09-21 09:18:17) On Fri, Aug 21, 2020 at 10:49 PM Sibi Sankar wrote: > > Add GENPD_FLAG_NO_SUSPEND/RESUME flags to instruct genpd to keep the > status of the PM domain unaltered during suspend/resume respectively. > The flags are aimed at power domains coupled to co-processors which > enter low-power modes independent to that of the application processor. > > Specifically the flags are to be used by the power domains exposed > by the AOSS QMP driver linked to modem, adsp, cdsp remoteprocs. These > power domains are used to notify the Always on Subsystem (AOSS) that > a particular co-processor is up. AOSS uses this information to wait > for the co-processors to suspend before starting its sleep sequence. > The application processor powers off these power domains only if the > co-processor has crashed or powered off and remains unaltered during > system suspend/resume. > > Signed-off-by: Sibi Sankar Applied with the Ulf's R-by along with the [2/2] as 5.10 material, thanks! There was a bunch of discussion on this patch series and I thought the consensus was to not apply these patches and instead implement a custom qcom specific API that does this instead. https://lore.kernel.org/lkml/20200913034603.GV3715@yoga/ The power domains which were targeted to use the flags will be replaced by custom qcom specific API. So let's not pick up the patch series. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.
Re: [PATCH v3 2/2] arm64: dts: qcom: Switch sc7180-trogdor to control SPI CS via GPIO
On 9/22/2020 2:57 AM, Douglas Anderson wrote:
As talked about in the patch ("arm64: dts: qcom: sc7180: Provide
pinconf for SPI to use GPIO for CS"), on some boards it makes much
more sense (and is much more efficient) to think of the SPI Chip
Select as a GPIO. Trogdor is one such board where the SPI parts don't
run in GSI mode and we do a lot of SPI traffic.
Signed-off-by: Douglas Anderson
Reviewed-by: Stephen Boyd
Reviewed-by: Akash Asthana
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,\na
Linux Foundation Collaborative Project
[PATCH v4] powercap: include header to fix -Wmissing-prototypes
Include the linux/idle_inject.h header to fix W=1 build warning: drivers/powercap/idle_inject.c:152:6: warning: no previous prototype for ‘idle_inject_set_duration’ [-Wmissing-prototypes] drivers/powercap/idle_inject.c:167:6: warning: no previous prototype for ‘idle_inject_get_duration’ [-Wmissing-prototypes] drivers/powercap/idle_inject.c:179:6: warning: no previous prototype for ‘idle_inject_set_latency’ [-Wmissing-prototypes] drivers/powercap/idle_inject.c:195:5: warning: no previous prototype for ‘idle_inject_start’ [-Wmissing-prototypes] drivers/powercap/idle_inject.c:227:6: warning: no previous prototype for ‘idle_inject_stop’ [-Wmissing-prototypes] drivers/powercap/idle_inject.c:299:28: warning: no previous prototype for ‘idle_inject_register’ [-Wmissing-prototypes] drivers/powercap/idle_inject.c:345:6: warning: no previous prototype for ‘idle_inject_unregister’ [-Wmissing-prototypes] Signed-off-by: Pujin Shi --- drivers/powercap/idle_inject.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/powercap/idle_inject.c b/drivers/powercap/idle_inject.c index 4310901a074e..6e1a0043c411 100644 --- a/drivers/powercap/idle_inject.c +++ b/drivers/powercap/idle_inject.c @@ -43,6 +43,7 @@ #include #include #include +#include #include -- 2.25.4
Re: [PATCH v3 1/2] arm64: dts: qcom: sc7180: Provide pinconf for SPI to use GPIO for CS
On 9/22/2020 2:57 AM, Douglas Anderson wrote: When the chip select line is controlled by the QUP, changing CS is a time consuming operation. We have to send a command over to the geni and wait for it to Ack us every time we want to change (both making it high and low). To send this command we have to make a choice in software when we want to control the chip select, we have to either: A) Wait for the Ack via interrupt which slows down all SPI transfers (and incurrs extra processing associated with interrupts). B) Sit in a loop and poll, waiting for the Ack. Neither A) nor B) is a great option. We can avoid all of this by realizing that, at least on some boards, there is no advantage of considering this line to be a geni line. While it's true that geni _can_ control the line, it's also true that the line can be a GPIO and there is no downside of viewing it that way. Setting a GPIO is a simple MMIO operation. This patch provides definitions so a board can easily select the GPIO mode. NOTE: apparently, it's possible to run the geni in "GSI" mode. In GSI the SPI port is allowed to be controlled by more than one user (like firmware and Linux) and also the port can operate sequences of operations in one go. In GSI mode it _would_ be invalid to look at the chip select as a GPIO because that would prevent other users from using it. In theory GSI mode would also avoid some overhead by allowing us to sequence the chip select better. However, I'll argue GSI is not relevant for all boards (and certainly not any boards supported by mainline today). Why? - Apparently to run a SPI chip in GSI mode you need to initialize it (in the bootloader) with a different firmware and then it will always run in GSI mode. Since there is no support for GSI mode in the current Linux driver, it must be that existing boards don't have firmware that's doing that. Note that the kernel device tree describes hardware but also firmware, so it is legitimate to make the assumption that we don't have GSI firmware in a given dts file. - Some boards with sc7180 have SPI connected to the Chrome OS EC or security chip (Cr50). The protocols for talking to cros_ec and cr50 are extremely complex. Both drivers in Linux fully lock the bus across several distinct SPI transfers. While I am not an expert on GSI mode it feels highly unlikely to me that we'd ever be able to enable GSI mode for these devices. From a testing perspective, running "flashrom -p ec -r /tmp/foo.bin" in a loop after this patch shows almost no reduction in time, but the number of interrupts per command goes from 32357 down to 30611 (about a 5% reduction). Signed-off-by: Douglas Anderson Reviewed-by: Stephen Boyd --- Reviewed-by: Akash Asthana -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,\na Linux Foundation Collaborative Project
Re: remove set_fs for riscv v2
Given tht we've not made much progress with the common branch, are you fine just picking this up through the riscv tree for 5.10? I'll defer other architectures that depend on the common changes to 5.11 then. On Wed, Sep 09, 2020 at 08:55:15AM +0200, Christoph Hellwig wrote: > now that we've sorted out a remaining issue base.set_fs should not > be rebased any more, so you could pull it into the riscv tree or a topic > branch. > > The first four patch should go into base.set_fs, though. Arnd, can you > re-review the updated patches? ---end quoted text---
[PATCH v3] arm64: dts: marvell: espressobin: Get rid of duplicate serial aliases
The included armada-37xx.dtsi already defines these two aliases.
Signed-off-by: Andre Heider
Reviewed-by: Pali Rohár
---
v3: really fix filename, sorry for the spam... too early, not enough coffee
v2: fix filename in commit message
This goes on top of Pali's patch:
"arm64: dts: marvell: espressobin: Add ethernet switch aliases"
The resulting .dtb files are the same.
arch/arm64/boot/dts/marvell/armada-3720-espressobin.dtsi | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm64/boot/dts/marvell/armada-3720-espressobin.dtsi
b/arch/arm64/boot/dts/marvell/armada-3720-espressobin.dtsi
index 0775c16e0ec8..3169a820558f 100644
--- a/arch/arm64/boot/dts/marvell/armada-3720-espressobin.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-3720-espressobin.dtsi
@@ -17,8 +17,6 @@ aliases {
ethernet1 =
ethernet2 =
ethernet3 =
- serial0 =
- serial1 =
};
chosen {
--
2.28.0
[PATCH v2] arm64: dts: marvell: espressobin: Get rid of duplicate serial aliases
The included armada-3xxx.dtsi already defines these two aliases.
Signed-off-by: Andre Heider
Reviewed-by: Pali Rohár
---
v2: fix filename in commit message
This goes on top of Pali's patch:
"arm64: dts: marvell: espressobin: Add ethernet switch aliases"
The resulting .dtb files are the same.
arch/arm64/boot/dts/marvell/armada-3720-espressobin.dtsi | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm64/boot/dts/marvell/armada-3720-espressobin.dtsi
b/arch/arm64/boot/dts/marvell/armada-3720-espressobin.dtsi
index 0775c16e0ec8..3169a820558f 100644
--- a/arch/arm64/boot/dts/marvell/armada-3720-espressobin.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-3720-espressobin.dtsi
@@ -17,8 +17,6 @@ aliases {
ethernet1 =
ethernet2 =
ethernet3 =
- serial0 =
- serial1 =
};
chosen {
--
2.28.0
Re: [PATCH] mm/memcontrol: Add the drop_cache interface for cgroup v2
On Mon, Sep 21, 2020 at 7:36 PM Michal Hocko wrote:
>
> On Mon 21-09-20 19:23:01, Yafang Shao wrote:
> > On Mon, Sep 21, 2020 at 7:05 PM Michal Hocko wrote:
> > >
> > > On Mon 21-09-20 18:55:40, Yafang Shao wrote:
> > > > On Mon, Sep 21, 2020 at 4:12 PM Michal Hocko wrote:
> > > > >
> > > > > On Mon 21-09-20 16:02:55, zangchun...@bytedance.com wrote:
> > > > > > From: Chunxin Zang
> > > > > >
> > > > > > In the cgroup v1, we have 'force_mepty' interface. This is very
> > > > > > useful for userspace to actively release memory. But the cgroup
> > > > > > v2 does not.
> > > > > >
> > > > > > This patch reuse cgroup v1's function, but have a new name for
> > > > > > the interface. Because I think 'drop_cache' may be is easier to
> > > > > > understand :)
> > > > >
> > > > > This should really explain a usecase. Global drop_caches is a terrible
> > > > > interface and it has caused many problems in the past. People have
> > > > > learned to use it as a remedy to any problem they might see and cause
> > > > > other problems without realizing that. This is the reason why we even
> > > > > log each attempt to drop caches.
> > > > >
> > > > > I would rather not repeat the same mistake on the memcg level unless
> > > > > there is a very strong reason for it.
> > > > >
> > > >
> > > > I think we'd better add these comments above the function
> > > > mem_cgroup_force_empty() to explain why we don't want to expose this
> > > > interface in cgroup2, otherwise people will continue to send this
> > > > proposal without any strong reason.
> > >
> > > I do not mind people sending this proposal. "V1 used to have an
> > > interface, we need it in v2 as well" is not really viable without
> > > providing more reasoning on the specific usecase.
> > >
> > > _Any_ patch should have a proper justification. This is nothing really
> > > new to the process and I am wondering why this is coming as a surprise.
> > >
> >
> > Container users always want to drop cache in a specific container,
> > because they used to use drop_caches to fix memory pressure issues.
>
> This is exactly the kind of problems we have seen in the past. There
> should be zero reason to addre potential reclaim problems by dropping
> page cache on the floor. There is a huge cargo cult about this
> procedure and I have seen numerous reports when people complained about
> performance afterwards just to learn that the dropped page cache was one
> of the resons for that.
>
> > Although drop_caches can cause some unexpected issues, it could also
> > fix some issues.
>
> "Some issues" is way too general. We really want to learn about those
> issues and address them properly.
>
One use case in our production environment is that some of our tasks
become very latency sensitive from 7am to 10am, so before these tasks
become active we will use drop_caches to drop page caches generated by
other tasks at night to avoid these tasks triggering direct reclaim.
The best way to do it is to fix the latency in direct reclaim, but it
will take great effort. while drop_caches give us an easier way to
achieve the same goal.
IOW, drop_caches give the users an option to achieve their goal before
they find a better solution.
> > So container users want to use it in containers as
> > well.
> > If this feature is not implemented in cgroup, they will ask you why
> > but there is no explanation in the kernel.
>
> There is no usecase that would really require it so far.
>
> > Regarding the memory.high, it is not perfect as well, because you have
> > to set it to 0 to drop_caches, and the processes in the containers
> > have to reclaim pages as well because they reach the memory.high, but
> > memory.force_empty won't make other processes to reclaim.
>
> Since 536d3bf261a2 ("mm: memcontrol: avoid workload stalls when lowering
> memory.high") the limit is set after the reclaim so the race window when
> somebody would be pushed to high limit reclaim is reduced. But I do
> agree this is just a workaround.
>
> > That doesn't mean I agree to add this interface, while I really mean
> > that if we discard one feature we'd better explain why.
>
> We need to understand why somebody wants an interface because once it is
> added it will have to be maintained for ever.
> --
> Michal Hocko
> SUSE Labs
--
Thanks
Yafang
Re: [PATCH -next] phy: fix USB_LGM_PHY warning & build errors
Hi Randy, Thank you for the report, surely will fix it. Regards Vadivel On 21/9/2020 11:45 pm, Randy Dunlap wrote: Ping. Still seeing this in linux-next. On 9/17/20 10:51 AM, Randy Dunlap wrote: From: Randy Dunlap Fix a Kconfig warning that is causing lots of build errors when USB_SUPPORT is not set. USB_PHY depends on USB_SUPPORT but "select" doesn't care about dependencies, so this driver should also depend on USB_SUPPORT. It should not select USB_SUPPORT. WARNING: unmet direct dependencies detected for USB_PHY Depends on [n]: USB_SUPPORT [=n] Selected by [m]: - USB_LGM_PHY [=m] Signed-off-by: Randy Dunlap Cc: Li Yin Cc: Vadivel Murugan R Cc: Kishon Vijay Abraham I Cc: Vinod Koul --- drivers/phy/Kconfig |1 + 1 file changed, 1 insertion(+) --- linux-next-20200917.orig/drivers/phy/Kconfig +++ linux-next-20200917/drivers/phy/Kconfig @@ -51,6 +51,7 @@ config PHY_XGENE config USB_LGM_PHY tristate "INTEL Lightning Mountain USB PHY Driver" + depends on USB_SUPPORT select USB_PHY select REGULATOR select REGULATOR_FIXED_VOLTAGE
Re: UBSAN: array-index-out-of-bounds in arch_uprobe_analyze_insn
syzbot has bisected this issue to:
commit 4b2bd5fec007a4fd3fc82474b9199af25013de4c
Author: John Stultz
Date: Sat Oct 8 00:02:33 2016 +
proc: fix timerslack_ns CAP_SYS_NICE check when adjusting self
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=1697348d90
start commit: 325d0eab Merge branch 'akpm' (patches from Andrew)
git tree: upstream
final oops: https://syzkaller.appspot.com/x/report.txt?x=1597348d90
console output: https://syzkaller.appspot.com/x/log.txt?x=1197348d90
kernel config: https://syzkaller.appspot.com/x/.config?x=b12e84189082991c
dashboard link: https://syzkaller.appspot.com/bug?extid=9b64b619f10f19d19a7c
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1573a8ad90
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=164ee6c590
Reported-by: syzbot+9b64b619f10f19d19...@syzkaller.appspotmail.com
Fixes: 4b2bd5fec007 ("proc: fix timerslack_ns CAP_SYS_NICE check when adjusting
self")
For information about bisection process see: https://goo.gl/tpsmEJ#bisection
Re: [PATCH] mmap_lock: add tracepoints around lock acquisition
On Tue, Sep 22, 2020 at 12:53 AM Axel Rasmussen
wrote:
>
> On Sun, Sep 20, 2020 at 9:58 PM Yafang Shao wrote:
> >
> > On Fri, Sep 18, 2020 at 2:13 AM Axel Rasmussen
> > wrote:
> > >
> > > The goal of these tracepoints is to be able to debug lock contention
> > > issues. This lock is acquired on most (all?) mmap / munmap / page fault
> > > operations, so a multi-threaded process which does a lot of these can
> > > experience significant contention.
> > >
> > > We trace just before we start acquisition, when the acquisition returns
> > > (whether it succeeded or not), and when the lock is released (or
> > > downgraded). The events are broken out by lock type (read / write).
> > >
> > > The events are also broken out by memcg path. For container-based
> > > workloads, users often think of several processes in a memcg as a single
> > > logical "task", so collecting statistics at this level is useful.
> > >
> > > These events *do not* include latency bucket information, which means
> > > for a proper latency histogram users will need to use BPF instead of
> > > event histograms. The benefit we get from this is simpler code.
> > >
> > > This patch is a no-op if the Kconfig option is not enabled. If it is,
> > > tracepoints are still disabled by default (configurable at runtime);
> > > the only fixed cost here is un-inlining a few functions. As best as
> > > I've been able to measure, the overhead this introduces is a small
> > > fraction of 1%. Actually hooking up the tracepoints to BPF introduces
> > > additional overhead, depending on exactly what the BPF program is
> > > collecting.
> >
> > Are there any methods to avoid un-inlining these wrappers ?
> >
> > For example,
> > // include/linux/mmap_lock.h
> >
> > void mmap_lock_start_trace_wrapper();
> > void mmap_lock_acquire_trace_wrapper();
> >
> > static inline void mmap_write_lock(struct mm_struct *mm)
> > {
> > mmap_lock_start_trace_wrapper();
> > down_write(>mmap_lock);
> > mmap_lock_acquire_trace_wrapper();
> > }
> >
> > // mm/mmap_lock.c
> > void mmap_lock_start_trace_wrapper()
> > {
> > trace_mmap_lock_start();
> > }
> >
> > void mmap_lock_start_trace_wrapper()
> > {
> > trace_mmap_lock_acquired();
> > }
>
> We can do something like that, but I don't think it would end up being better.
>
> At the end of the day, because the trace stuff cannot be in the
> header, we have to add an extra function call one way or the other.
> This would just move the call one step further down the call stack.
> So, I don't think it would affect performance in the
> CONFIG_MMAP_LOCK_STATS + tracepoints not enabled at runtime case.
>
Right, it seems we have to add an extra function call.
> Also the wrappers aren't quite so simple as this, they need some
> parameters to work. (the struct mm_struct, whether it was a read or a
> write lock, and whether or not the lock operation succeeded), so it
> would mean adding more inlined code, which I think adds up to be a
> nontrivial amount since these wrappers are called so often in the
> kernel.
>
> If you feel strongly, let me know and I can send a version as you
> describe and we can compare the two.
>
These tracepoints will be less useful if we have to turn on the config
to enable it.
I don't mind implementing it that way if we can't optimize it.
Maybe Steven can give some suggestions, Steven ?
> >
> >
> >
> > > ---
> > > include/linux/mmap_lock.h| 28 +++-
> > > include/trace/events/mmap_lock.h | 73 ++
> > > mm/Kconfig | 17 +++
> > > mm/Makefile | 1 +
> > > mm/mmap_lock.c | 224 +++
> > > 5 files changed, 342 insertions(+), 1 deletion(-)
> > > create mode 100644 include/trace/events/mmap_lock.h
> > > create mode 100644 mm/mmap_lock.c
> > >
> > > diff --git a/include/linux/mmap_lock.h b/include/linux/mmap_lock.h
> > > index 0707671851a8..d12aa2ff6c05 100644
> > > --- a/include/linux/mmap_lock.h
> > > +++ b/include/linux/mmap_lock.h
> > > @@ -1,11 +1,35 @@
> > > #ifndef _LINUX_MMAP_LOCK_H
> > > #define _LINUX_MMAP_LOCK_H
> > >
> > > +#include
> > > +#include
> > > #include
> > > +#include
> > > +#include
> > >
> > > #define MMAP_LOCK_INITIALIZER(name) \
> > > .mmap_lock = __RWSEM_INITIALIZER((name).mmap_lock),
> > >
> > > +#ifdef CONFIG_MMAP_LOCK_STATS
> > > +
> > > +void mmap_init_lock(struct mm_struct *mm);
> > > +void mmap_write_lock(struct mm_struct *mm);
> > > +void mmap_write_lock_nested(struct mm_struct *mm, int subclass);
> > > +int mmap_write_lock_killable(struct mm_struct *mm);
> > > +bool mmap_write_trylock(struct mm_struct *mm);
> > > +void mmap_write_unlock(struct mm_struct *mm);
> > > +void mmap_write_downgrade(struct mm_struct *mm);
> > > +void mmap_read_lock(struct mm_struct *mm);
> > > +int mmap_read_lock_killable(struct mm_struct *mm);
> > > +bool mmap_read_trylock(struct mm_struct *mm);
> > > +void mmap_read_unlock(struct mm_struct *mm);
> > > +bool
Re: [PATCH bpf-next v3 3/5] bpf: add 'bpf_mptcp_sock' structure and helper
On Fri, Sep 18, 2020 at 02:10:42PM +0200, Nicolas Rybowski wrote:
> +
> +BPF_CALL_1(bpf_mptcp_sock, struct sock *, sk)
> +{
> + if (sk_fullsock(sk) && sk->sk_protocol == IPPROTO_TCP &&
> sk_is_mptcp(sk)) {
> + struct mptcp_subflow_context *mptcp_sfc = mptcp_subflow_ctx(sk);
Could you add !sk check here as well?
See commit 8c33dadc3e0e ("bpf: Bpf_skc_to_* casting helpers require a NULL
check on sk")
It's not strictly necessary yet, but see below.
Also this new helper is not exercised from C test. Only from asm.
Could you update patch 4 with such additional logic?
> +
> + return (unsigned long)mptcp_sfc->conn;
I think we shouldn't extend the verifier with PTR_TO_MPTCP_SOCK and similar
concept anymore.
This approach doesn't scale and we have better way to handle such field access
with BTF.
> + }
> + return (unsigned long)NULL;
> +}
> +
> +const struct bpf_func_proto bpf_mptcp_sock_proto = {
> + .func = bpf_mptcp_sock,
> + .gpl_only = false,
> + .ret_type = RET_PTR_TO_MPTCP_SOCK_OR_NULL,
In this particular case you can do:
+ .ret_type = RET_PTR_TO_BTF_ID_OR_NULL,
Then bpf_mptcp_sock_convert_ctx_access() will no longer be necessary
and bpf prog will be able to access all mptcp_sock fields right away.
Will that work for your use case?
Re: [PATCH] scsi: target: remove redundant assignment to variable 'ret'
On Mon, 14 Sep 2020 10:32:07 +0800, Jing Xiangfeng wrote: > The variable ret has been initialized with a value '0'. The assignment > in switch-case is redundant. So remove it. Applied to 5.10/scsi-queue, thanks! [1/1] scsi: target: Remove redundant assignment to variable 'ret' https://git.kernel.org/mkp/scsi/c/1c370903d12d -- Martin K. Petersen Oracle Linux Engineering
Re: [mm/debug_vm_pgtable/locks] e2aad6f1d2: BUG:unable_to_handle_page_fault_for_address
On 9/21/20 2:51 PM, kernel test robot wrote:
Greeting,
FYI, we noticed the following commit (built with gcc-9):
commit: e2aad6f1d232b457ea6a3194992dd4c0a83534a5 ("mm/debug_vm_pgtable/locks: take
correct page table lock")
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git master
in testcase: trinity
version: trinity-i386
with following parameters:
runtime: 300s
test-description: Trinity is a linux system call fuzz tester.
test-url: http://codemonkey.org.uk/projects/trinity/
on test machine: qemu-system-i386 -enable-kvm -cpu SandyBridge -smp 2 -m 8G
caused below changes (please refer to attached dmesg/kmsg for entire
log/backtrace):
+--+++
| |
c50eb1ed65 | e2aad6f1d2 |
+--+++
| boot_successes | 0
| 0 |
| boot_failures| 61
| 17 |
| BUG:workqueue_lockup-pool| 1
||
| BUG:sleeping_function_called_from_invalid_context_at_mm/page_alloc.c | 60
| 17 |
| BUG:unable_to_handle_page_fault_for_address | 0
| 17 |
| Oops:#[##] | 0
| 17 |
| EIP:ptep_get | 0
| 17 |
| Kernel_panic-not_syncing:Fatal_exception | 0
| 17 |
+--+++
If you fix the issue, kindly add following tag
Reported-by: kernel test robot
[ 28.726464] BUG: sleeping function called from invalid context at
mm/page_alloc.c:4822
[ 28.727835] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1, name:
swapper
[ 28.729221] no locks held by swapper/1.
[ 28.729954] CPU: 0 PID: 1 Comm: swapper Not tainted
5.9.0-rc3-00324-ge2aad6f1d232b4 #1
[ 28.731484] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.12.0-1 04/01/2014
[ 28.732891] Call Trace:
[ 28.733295] ? show_stack+0x48/0x50
[ 28.733943] dump_stack+0x1b/0x1d
[ 28.734569] ___might_sleep+0x205/0x219
[ 28.735292] __might_sleep+0x106/0x10f
[ 28.736022] __alloc_pages_nodemask+0xe0/0x2c8
[ 28.736845] swap_migration_tests+0x62/0x295
[ 28.737639] debug_vm_pgtable+0x587/0x9b5
[ 28.738374] ? pte_advanced_tests+0x267/0x267
[ 28.739318] do_one_initcall+0x129/0x31c
[ 28.740023] ? rcu_read_lock_sched_held+0x46/0x74
[ 28.740944] kernel_init_freeable+0x201/0x250
[ 28.741763] ? rest_init+0xf8/0xf8
[ 28.742401] kernel_init+0xe/0x15d
[ 28.743040] ? rest_init+0xf8/0xf8
[ 28.743694] ret_from_fork+0x1c/0x30
This should be fixed by
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/mm/debug_vm_pgtable.c?id=3a4f9a45eadb6ed5fc04686e8db4dc7bb1caec44
[ 28.744364] BUG: unable to handle page fault for address: fffbbea4
[ 28.745465] #PF: supervisor read access in kernel mode
[ 28.746373] #PF: error_code(0x) - not-present page
[ 28.747275] *pde = 0492b067 *pte =
[ 28.748054] Oops: [#1]
[ 28.748548] CPU: 0 PID: 1 Comm: swapper Tainted: GW
5.9.0-rc3-00324-ge2aad6f1d232b4 #1
[ 28.750188] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.12.0-1 04/01/2014
[ 28.751641] EIP: ptep_get+0x0/0x3
[ 28.752226] Code: 5d fc c9 c3 55 c1 e8 1a 89 e5 53 31 db 83 f8 1f 6a 00 0f 94 c3
b8 80 67 02 c4 31 c9 89 da e8 16 5c f1 ff 89 d8 8b 5d fc c9 c3 <8b> 00 c3 55 31
c9 89 e5 57 56 53 8b 70 04 89 c3 b8 10 68 02 c4 6a
[ 28.755465] EAX: fffbbea4 EBX: fffbbea4 ECX: 47bd EDX: fffbbea4
[ 28.756418] ESI: 47bd EDI: 0025 EBP: f406bed8 ESP: f406bebc
[ 28.757522] DS: 007b ES: 007b FS: GS: SS: 0068 EFLAGS: 00010286
[ 28.758739] CR0: 80050033 CR2: fffbbea4 CR3: 04928000 CR4: 000406d0
[ 28.759828] Call Trace:
[ 28.760235] ? hugetlb_advanced_tests+0x2a/0x27f
[ 28.761099] ? do_raw_spin_unlock+0xd7/0x112
[ 28.761872] debug_vm_pgtable+0x927/0x9b5
[ 28.762578] ? pte_advanced_tests+0x267/0x267
[ 28.763462] do_one_initcall+0x129/0x31c
[ 28.764134] ? rcu_read_lock_sched_held+0x46/0x74
[ 28.764948] kernel_init_freeable+0x201/0x250
[ 28.765654] ? rest_init+0xf8/0xf8
[ 28.766277] kernel_init+0xe/0x15d
[ 28.766878] ? rest_init+0xf8/0xf8
[ 28.767488] ret_from_fork+0x1c/0x30
[ 28.768052] Modules linked in:
[ 28.768532] CR2: fffbbea4
[ 28.769065] ---[ end trace 9c4395cf49c7b3e7 ]---
IIUC, Anshuman is reworking the test to follow the page table update rules.
To reproduce:
# build kernel
Re: [PATCH v4] scsi: libfc: Fix passing zero to 'PTR_ERR' warning
On Wed, 9 Sep 2020 21:54:32 +0800, YueHaibing wrote: > drivers/scsi/libfc/fc_disc.c:304 > fc_disc_error() warn: passing zero to 'PTR_ERR' > > fp maybe NULL in fc_disc_error(), use PTR_ERR_OR_ZERO to handle this. Applied to 5.10/scsi-queue, thanks! [1/1] scsi: libfc: Fix passing zero to 'PTR_ERR' warning https://git.kernel.org/mkp/scsi/c/a9e81c2922bf -- Martin K. Petersen Oracle Linux Engineering
Re: [PATCH 1/2] dyndbg: dont panic over bad input
On Mon, Sep 21, 2020 at 1:29 PM Joe Perches wrote:
>
> On Mon, 2020-09-21 at 13:04 -0600, Jim Cromie wrote:
> > This BUG_ON, from 2009, caught the impossible case of a word-char both
> > starting and ending a string (loosely speaking). A bad (reverted)
> > patch finally hit this case, but even "impossibly bad input" is no
> > reason to panic the kernel. Instead pr_err and return -EINVAL.
> []
> > diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
> []
> > @@ -259,7 +259,10 @@ static int ddebug_tokenize(char *buf, char *words[],
> > int maxwords)
> > } else {
> > for (end = buf; *end && !isspace(*end); end++)
> > ;
> > - BUG_ON(end == buf);
> > + if (end == buf) {
> > + pr_err("expected non-empty bareword");
>
> missing newline
>
> This message is also unintelligible.
> What is a non-empty bareword?
>
>
hmm, I borrowed the term from perl
en.wiktionary.org › wiki › bareword
(programming, chiefly Perl) A sequence of text characters in source
code that do not form a keyword nor part of a quoted string, and may
potentially be interpreted ...
basically, a not-quoted word, a keyword or not-quoted-value
Im open that there might be better terminology.
have any suggestions ?
Re: [PATCH -next] scsi: aic94xx: Remove unused inline function
On Wed, 9 Sep 2020 21:57:11 +0800, YueHaibing wrote: > There is no caller in tree, so can remove it. Applied to 5.10/scsi-queue, thanks! [1/1] scsi: aic94xx: Remove unused inline function https://git.kernel.org/mkp/scsi/c/3f4fee002b00 -- Martin K. Petersen Oracle Linux Engineering
Re: [PATCH] scsi: target: tcmu: add a missing newline when printing parameters
On Thu, 3 Sep 2020 19:29:33 +0800, Xiongfeng Wang wrote: > When I cat module paramter 'global_max_data_area_mb' by sysfs, it > displays as follows. It's better to add a newline for easy reading. > > root@(none):/# cat > /sys/module/target_core_user/parameters/global_max_data_area_mb > 2048noneroot@(none):/# Applied to 5.10/scsi-queue, thanks! [1/1] scsi: target: tcmu: Add missing newline when printing parameters https://git.kernel.org/mkp/scsi/c/6d70cb343484 -- Martin K. Petersen Oracle Linux Engineering
Re: [PATCH] scsi: ufs: Fix NOP OUT timeout value
On Wed, 02 Sep 2020 11:58:52 +0900, Daejun Park wrote: > In some Samsung UFS devices, there is some booting fail issue with > low-power UFS device. The reason of this issue is the UFS device has a > little bit longer latency for NOP OUT response. It causes booting fail > because NOP OUT command is issued during initialization to check whether > the device transport protocol is ready or not. This issue is resolved by > releasing NOP_OUT_TIMEOUT value. > > [...] Applied to 5.10/scsi-queue, thanks! [1/1] scsi: ufs: Fix NOP OUT timeout value https://git.kernel.org/mkp/scsi/c/782e2efb749f -- Martin K. Petersen Oracle Linux Engineering
Re: [PATCH] Rescan the entire target on transport reset when LUN is 0
On Fri, 28 Aug 2020 12:21:35 +, Matej Genci wrote: > VirtIO 1.0 spec says > The removed and rescan events ... when sent for LUN 0, they MAY > apply to the entire target so the driver can ask the initiator > to rescan the target to detect this. > > This change introduces the behaviour described above by scanning the > entire scsi target when LUN is set to 0. This is both a functional and a > performance fix. It aligns the driver with the spec and allows control > planes to hotplug targets with large numbers of LUNs without having to > request a RESCAN for each one of them. Applied to 5.10/scsi-queue, thanks! [1/1] scsi: virtio_scsi: Rescan the entire target on transport reset when LUN is 0 https://git.kernel.org/mkp/scsi/c/beef6fd02b90 -- Martin K. Petersen Oracle Linux Engineering
Re: [PATCH] scsi: aic7xxx: Use kmemdup in two places
On Wed, 9 Sep 2020 19:58:55 +0100, Alex Dewar wrote: > kmemdup can be used instead of kmalloc+memcpy. Replace two occurrences > of this pattern. > > Issue identified with Coccinelle. Applied to 5.10/scsi-queue, thanks! [1/1] scsi: aic7xxx: Use kmemdup() in two places https://git.kernel.org/mkp/scsi/c/f97e6e1eabbf -- Martin K. Petersen Oracle Linux Engineering
Re: [PATCH V2] scsi: ufs-pci: Add LTR support for Intel controllers
On Thu, 27 Aug 2020 10:20:30 +0300, Adrian Hunter wrote: > Intel host controllers support the setting of latency tolerance. > Accordingly, implement the PM QoS ->set_latency_tolerance() callback. The > raw register values are also exposed via debugfs. Applied to 5.10/scsi-queue, thanks! [1/1] scsi: ufs-pci: Add LTR support for Intel controllers https://git.kernel.org/mkp/scsi/c/247f99445938 -- Martin K. Petersen Oracle Linux Engineering
Re: [PATCH v18 16/32] mm/lru: introduce TestClearPageLRU
在 2020/9/22 上午7:16, Hugh Dickins 写道:
> On Mon, 24 Aug 2020, Alex Shi wrote:
>
>> Currently lru_lock still guards both lru list and page's lru bit, that's
>> ok. but if we want to use specific lruvec lock on the page, we need to
>> pin down the page's lruvec/memcg during locking. Just taking lruvec
>> lock first may be undermined by the page's memcg charge/migration. To
>> fix this problem, we could clear the lru bit out of locking and use
>> it as pin down action to block the page isolation in memcg changing.
>>
>> So now a standard steps of page isolation is following:
>> 1, get_page(); #pin the page avoid to be free
>> 2, TestClearPageLRU(); #block other isolation like memcg change
>> 3, spin_lock on lru_lock; #serialize lru list access
>> 4, delete page from lru list;
>> The step 2 could be optimzed/replaced in scenarios which page is
>> unlikely be accessed or be moved between memcgs.
>>
>> This patch start with the first part: TestClearPageLRU, which combines
>> PageLRU check and ClearPageLRU into a macro func TestClearPageLRU. This
>> function will be used as page isolation precondition to prevent other
>> isolations some where else. Then there are may !PageLRU page on lru
>> list, need to remove BUG() checking accordingly.
>>
>> There 2 rules for lru bit now:
>> 1, the lru bit still indicate if a page on lru list, just in some
>>temporary moment(isolating), the page may have no lru bit when
>>it's on lru list. but the page still must be on lru list when the
>>lru bit set.
>> 2, have to remove lru bit before delete it from lru list.
>>
>> Hugh Dickins pointed that when a page is in free path and no one is
>> possible to take it, non atomic lru bit clearing is better, like in
>> __page_cache_release and release_pages.
>> And no need get_page() before lru bit clear in isolate_lru_page,
>> since it '(1) Must be called with an elevated refcount on the page'.
>
> Delete that paragraph: you're justifying changes made during the
> course of earlier review, but not needed here. If we start to
> comment on everything that is not done...!
>
Will delete it!
>>
>> As Andrew Morton mentioned this change would dirty cacheline for page
>> isn't on LRU. But the lost would be acceptable with Rong Chen
>> report:
>> https://lkml.org/lkml/2020/3/4/173
>
> Please use a lore link instead, lkml.org is nice but unreliable:
> https://lore.kernel.org/lkml/20200304090301.GB5972@shao2-debian/
Yes, will replace the link.
>
>>
>> Suggested-by: Johannes Weiner
>> Signed-off-by: Alex Shi
>
> Acked-by: Hugh Dickins
> when you make the changes suggested above and below.
Thanks!
>
> I still have long-standing reservations about this TestClearPageLRU
> technique (it's hard to reason about, and requires additional atomic ops
> in some places); but it's working, so I'd like it to go in, then later
> we can experiment with whether lock_page_memcg() does a better job, or
> rechecking memcg when getting the lru_lock (my original technique).
>
>> Cc: Hugh Dickins
>> Cc: Johannes Weiner
>> Cc: Michal Hocko
>> Cc: Vladimir Davydov
>> Cc: Andrew Morton
>> Cc: linux-kernel@vger.kernel.org
>> Cc: cgro...@vger.kernel.org
>> Cc: linux...@kvack.org
>> ---
>> include/linux/page-flags.h | 1 +
>> mm/mlock.c | 3 +--
>> mm/swap.c | 5 ++---
>> mm/vmscan.c| 18 +++---
>> 4 files changed, 11 insertions(+), 16 deletions(-)
>>
>> diff --git a/include/linux/page-flags.h b/include/linux/page-flags.h
>> index 6be1aa559b1e..9554ed1387dc 100644
>> --- a/include/linux/page-flags.h
>> +++ b/include/linux/page-flags.h
>> @@ -326,6 +326,7 @@ static inline void page_init_poison(struct page *page,
>> size_t size)
>> PAGEFLAG(Dirty, dirty, PF_HEAD) TESTSCFLAG(Dirty, dirty, PF_HEAD)
>> __CLEARPAGEFLAG(Dirty, dirty, PF_HEAD)
>> PAGEFLAG(LRU, lru, PF_HEAD) __CLEARPAGEFLAG(LRU, lru, PF_HEAD)
>> +TESTCLEARFLAG(LRU, lru, PF_HEAD)
>> PAGEFLAG(Active, active, PF_HEAD) __CLEARPAGEFLAG(Active, active, PF_HEAD)
>> TESTCLEARFLAG(Active, active, PF_HEAD)
>> PAGEFLAG(Workingset, workingset, PF_HEAD)
>> diff --git a/mm/mlock.c b/mm/mlock.c
>> index 93ca2bf30b4f..3762d9dd5b31 100644
>> --- a/mm/mlock.c
>> +++ b/mm/mlock.c
>> @@ -107,13 +107,12 @@ void mlock_vma_page(struct page *page)
>> */
>> static bool __munlock_isolate_lru_page(struct page *page, bool getpage)
>> {
>> -if (PageLRU(page)) {
>> +if (TestClearPageLRU(page)) {
>> struct lruvec *lruvec;
>>
>> lruvec = mem_cgroup_page_lruvec(page, page_pgdat(page));
>> if (getpage)
>> get_page(page);
>> -ClearPageLRU(page);
>> del_page_from_lru_list(page, lruvec, page_lru(page));
>> return true;
>> }
>> diff --git a/mm/swap.c b/mm/swap.c
>> index f80ccd6f3cb4..446ffe280809 100644
>> --- a/mm/swap.c
>> +++ b/mm/swap.c
>> @@ -83,10 +83,9 @@ static void
Re: [PATCH v2 13/13] x86/platform/uv: Update Copyrights to conform to HPE standards
On Thu, Sep 17, 2020 at 09:54:29AM +0200, Greg Kroah-Hartman wrote: > On Wed, Sep 16, 2020 at 02:20:39PM -0500, Mike Travis wrote: > > Add Copyrights to those files that have been updated for UV5 changes. > > > > Signed-off-by: Mike Travis > > --- > > arch/x86/include/asm/uv/bios.h | 1 + > > arch/x86/include/asm/uv/uv_hub.h| 1 + > > arch/x86/include/asm/uv/uv_mmrs.h | 1 + > > arch/x86/kernel/apic/x2apic_uv_x.c | 1 + > > arch/x86/platform/uv/bios_uv.c | 1 + > > arch/x86/platform/uv/uv_nmi.c | 1 + > > arch/x86/platform/uv/uv_time.c | 1 + > > drivers/misc/sgi-gru/grufile.c | 1 + > > drivers/misc/sgi-xp/xp.h| 1 + > > drivers/misc/sgi-xp/xp_main.c | 1 + > > drivers/misc/sgi-xp/xp_uv.c | 1 + > > drivers/misc/sgi-xp/xpc_main.c | 1 + > > drivers/misc/sgi-xp/xpc_partition.c | 1 + > > drivers/misc/sgi-xp/xpnet.c | 1 + > > 14 files changed, 14 insertions(+) > > > > diff --git a/arch/x86/include/asm/uv/bios.h b/arch/x86/include/asm/uv/bios.h > > index 97ac595ebc6a..08b3d810dfba 100644 > > --- a/arch/x86/include/asm/uv/bios.h > > +++ b/arch/x86/include/asm/uv/bios.h > > @@ -5,6 +5,7 @@ > > /* > > * UV BIOS layer definitions. > > * > > + * (C) Copyright 2020 Hewlett Packard Enterprise Development LP > > * Copyright (C) 2007-2017 Silicon Graphics, Inc. All rights reserved. > > * Copyright (c) Russ Anderson > > Gotta love the different ways of text here :( > > Anyway, much better than before, thanks. The HPE copyright text is different than the old SGI copyright text. We could update the SGI copyright line to be consistent, change "Copyright (C)" to "(C) Copyright", if that is desired. The HPE lawyers said the old SGI copyrights do not need to be updated as far as they are concerned, because HPE owns the SGI copyrights, but they can. So the two lines could be combined to * (C) Copyright 2007-2017, 2020 Hewlett Packard Enterprise Development LP I will do whatever the lawyers and community want as far as format. For what it's worth, the r...@sgi.com email still works, as does r...@hpe.com. Thanks. -- Russ Anderson, SuperDome Flex Linux Kernel Group Manager HPE - Hewlett Packard Enterprise (formerly SGI) r...@hpe.com
RE: [PATCH] arm64: dts: layerscape: correct watchdog clocks for LS1088A
On Mon, Sep 14, 2020 at 03:52:02PM +0800, Qiang Zhao wrote: > -Original Message- > From: Shawn Guo > Sent: 2020年9月22日 10:18 > To: Qiang Zhao > Cc: robh...@kernel.org; linux-kernel@vger.kernel.org; > devicet...@vger.kernel.org > Subject: Re: [PATCH] arm64: dts: layerscape: correct watchdog clocks for > LS1088A > > On Mon, Sep 14, 2020 at 03:52:02PM +0800, Qiang Zhao wrote: > > From: Zhao Qiang > > > > On LS1088A, watchdog clk are divided by 16, correct it in dts. > > > > Signed-off-by: Zhao Qiang > > It doesn't apply to my imx/dt64 branch. > > Shawn > Have pushed version 2 to rebase. Best Regards Qiang Zhao
Re: [PATCH v18 15/32] mm/lru: move lock into lru_note_cost
在 2020/9/22 上午6:03, Hugh Dickins 写道: >> Acked-by: Hugh Dickins >> >> In your lruv19 github tree, you have merged 14/32 into this one: thanks. > Grr, I've only just started, and already missed some of my notes. > > I wanted to point out that this patch does introduce an extra unlock+lock > in shrink_inactive_list(), even in a !CONFIG_MEMCG build. I think you've > done the right thing for now, keeping it simple, and maybe nobody will > notice the extra overhead; but I expect us to replace lru_note_cost() > by lru_note_cost_unlock_irq() later on, expecting the caller to do the > initial lock_irq(). > > lru_note_cost_page() looks redundant to me, but you're right not to > delete it here, unless Johannes asks you to add that in: that's his > business, and it may be dependent on the XXX at its callsite. > Thanks for comments! And got your point. so I will leave this patch alone. Thanks!
[Patch v2] arm64: dts: layerscape: correct watchdog clocks for LS1088A
From: Zhao Qiang
On LS1088A, watchdog clk are divided by 16, correct it in dts.
Signed-off-by: Zhao Qiang
---
Changes for v2:
- rebase
arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
index c909ad1..80448b4 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
@@ -675,56 +675,56 @@
cluster1_core0_watchdog: wdt@c00 {
compatible = "arm,sp805-wdt", "arm,primecell";
reg = <0x0 0xc00 0x0 0x1000>;
- clocks = < 4 3>, < 4 3>;
+ clocks = < 4 15>, < 4 15>;
clock-names = "wdog_clk", "apb_pclk";
};
cluster1_core1_watchdog: wdt@c01 {
compatible = "arm,sp805-wdt", "arm,primecell";
reg = <0x0 0xc01 0x0 0x1000>;
- clocks = < 4 3>, < 4 3>;
+ clocks = < 4 15>, < 4 15>;
clock-names = "wdog_clk", "apb_pclk";
};
cluster1_core2_watchdog: wdt@c02 {
compatible = "arm,sp805-wdt", "arm,primecell";
reg = <0x0 0xc02 0x0 0x1000>;
- clocks = < 4 3>, < 4 3>;
+ clocks = < 4 15>, < 4 15>;
clock-names = "wdog_clk", "apb_pclk";
};
cluster1_core3_watchdog: wdt@c03 {
compatible = "arm,sp805-wdt", "arm,primecell";
reg = <0x0 0xc03 0x0 0x1000>;
- clocks = < 4 3>, < 4 3>;
+ clocks = < 4 15>, < 4 15>;
clock-names = "wdog_clk", "apb_pclk";
};
cluster2_core0_watchdog: wdt@c10 {
compatible = "arm,sp805-wdt", "arm,primecell";
reg = <0x0 0xc10 0x0 0x1000>;
- clocks = < 4 3>, < 4 3>;
+ clocks = < 4 15>, < 4 15>;
clock-names = "wdog_clk", "apb_pclk";
};
cluster2_core1_watchdog: wdt@c11 {
compatible = "arm,sp805-wdt", "arm,primecell";
reg = <0x0 0xc11 0x0 0x1000>;
- clocks = < 4 3>, < 4 3>;
+ clocks = < 4 15>, < 4 15>;
clock-names = "wdog_clk", "apb_pclk";
};
cluster2_core2_watchdog: wdt@c12 {
compatible = "arm,sp805-wdt", "arm,primecell";
reg = <0x0 0xc12 0x0 0x1000>;
- clocks = < 4 3>, < 4 3>;
+ clocks = < 4 15>, < 4 15>;
clock-names = "wdog_clk", "apb_pclk";
};
cluster2_core3_watchdog: wdt@c13 {
compatible = "arm,sp805-wdt", "arm,primecell";
reg = <0x0 0xc13 0x0 0x1000>;
- clocks = < 4 3>, < 4 3>;
+ clocks = < 4 15>, < 4 15>;
clock-names = "wdog_clk", "apb_pclk";
};
--
2.7.4
Re: [PATCH v18 15/32] mm/lru: move lock into lru_note_cost
在 2020/9/22 上午5:36, Hugh Dickins 写道: > >> We have to move lru_lock into lru_note_cost, since it cycle up on memcg >> tree, for future per lruvec lru_lock replace. It's a bit ugly and may >> cost a bit more locking, but benefit from multiple memcg locking could >> cover the lost. >> >> Signed-off-by: Alex Shi > Acked-by: Hugh Dickins Thanks!
Re: [RFC-PATCH 2/4] mm: Add __rcu_alloc_page_lockless() func.
On Mon, Sep 21, 2020 at 06:03:18PM +0200, Michal Hocko wrote: > On Mon 21-09-20 08:45:58, Paul E. McKenney wrote: > > On Mon, Sep 21, 2020 at 09:47:16AM +0200, Michal Hocko wrote: > > > On Fri 18-09-20 21:48:15, Uladzislau Rezki (Sony) wrote: > > > [...] > > > > Proposal > > > > > > > > Introduce a lock-free function that obtain a page from the per-cpu-lists > > > > on current CPU. It returns NULL rather than acquiring any non-raw > > > > spinlock. > > > > > > I was not happy about this solution when we have discussed this > > > last time and I have to say I am still not happy. This is exposing > > > an internal allocator optimization and allows a hard to estimate > > > consumption of pcp free pages. IIUC this run on pcp cache can be > > > controled directly from userspace (close(open) loop IIRC) which makes it > > > even bigger no-no. > > > > Yes, I do well remember that you are unhappy with this approach. > > Unfortunately, thus far, there is no solution that makes all developers > > happy. You might be glad to hear that we are also looking into other > > solutions, each of which makes some other developers unhappy. So we > > are at least not picking on you alone. :-/ > > No worries I do not feel like a whipping boy here. But do expect me to > argue against the approach. I would also appreciate it if there was some > more information on other attempts, why they have failed. E.g. why > pre-allocation is not an option that works well enough in most > reasonable workloads. I would also appreciate some more thoughts why we > need to optimize for heavy abusers of RCU (like close(open) extremes). Not optimizing for them, but rather defending against them. Uladzislau gave the example of low-memory phones. And we have quite the array of defenses against other userspace bugs including MMUs, the "limit" command, and so on. There have been quite a few successful attempts, starting from the introduction of blimit and RCU-bh more than 15 years ago, continuing through making call_rcu() jump-start grace periods, IPIing reluctant CPUs, tuning RCU callback offloading, and many others. But these prior approaches have only taken us so far. Other approaches under consideration include making CONFIG_PREEMPT_COUNT unconditional and thus allowing call_rcu() and kvfree_rcu() to determine whether direct calls to the allocator are safe (some guy named Linus doesn't like this one), preallocation (Uladzislau covered this, and the amount that would need to be preallocated is excessive), deferring allocation to RCU_SOFTIRQ (this would also need CONFIG_PREEMPT_COUNT), and deferring to some clean context (which is the best we can do within the confines of RCU, but which can have issues with delay). So it is not the need to address this general problem that is new. Far from it! What is new is the need for changes outside of RCU. > > > I strongly agree with Thomas > > > http://lkml.kernel.org/r/87tux4kefm@nanos.tec.linutronix.de > > > that this optimization is not aiming at reasonable workloads. Really, go > > > with pre-allocated buffer and fallback to whatever slow path you have > > > already. Exposing more internals of the allocator is not going to do any > > > good for long term maintainability. > > > > I suggest that you carefully re-read the thread following that email. > > I clearly remember Thomas not being particularly happy that you optimize > for a corner case. I do not remember there being a consensus that this > is the right approach. There was some consensus that this is better than > a gfp flag. Still quite bad though if you ask me. Again, this "optimization" is for robustness more than raw speed. > > Given a choice between making users unhappy and making developers > > unhappy, I will side with the users each and every time. > > Well, let me rephrase. It is not only about me (as a developer) being > unhappy but also all the side effects this would have for users when > performance of their favorite workload declines for no apparent reason > just because pcp caches are depleted by an unrelated process. But in the close(open()) case, wouldn't the allocations on the open() side refill those caches? Yes, cases where one CPU is doing the allocating and another the call_rcu()/kvfree_rcu() need additional help, but as Uladzislau noted, we do have patches that ensure that the refilling happens. Thanx, Paul
linux-next: manual merge of the drm-misc tree with the drm-intel tree
Hi all,
Today's linux-next merge of the drm-misc tree got a conflict in:
drivers/gpu/drm/i915/selftests/mock_gem_device.c
between commit:
9f9f4101fc98 ("drm/i915/selftests: Push the fake iommu device from the stack
to data")
from the drm-intel tree and commit:
cd01269d11a3 ("drm/i915/selftests: align more to real device lifetimes")
from the drm-misc tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/gpu/drm/i915/selftests/mock_gem_device.c
index 397c313a8b69,c207d2239791..
--- a/drivers/gpu/drm/i915/selftests/mock_gem_device.c
+++ b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
@@@ -118,12 -116,11 +116,11 @@@ static struct dev_pm_domain pm_domain
struct drm_i915_private *mock_gem_device(void)
{
- struct drm_i915_private *i915;
- struct pci_dev *pdev;
#if IS_ENABLED(CONFIG_IOMMU_API) && defined(CONFIG_INTEL_IOMMU)
- struct dev_iommu iommu;
+ static struct dev_iommu fake_iommu = { .priv = (void *)-1 };
#endif
+ struct drm_i915_private *i915;
+ struct pci_dev *pdev;
- int err;
pdev = kzalloc(sizeof(*pdev), GFP_KERNEL);
if (!pdev)
@@@ -141,11 -132,28 +132,26 @@@
dma_coerce_mask_and_coherent(>dev, DMA_BIT_MASK(64));
#if IS_ENABLED(CONFIG_IOMMU_API) && defined(CONFIG_INTEL_IOMMU)
- /* HACK HACK HACK to disable iommu for the fake device; force identity
mapping */
- memset(, 0, sizeof(iommu));
- iommu.priv = (void *)-1;
- pdev->dev.iommu =
+ /* HACK to disable iommu for the fake device; force identity mapping */
+ pdev->dev.iommu = _iommu;
#endif
+ if (!devres_open_group(>dev, NULL, GFP_KERNEL)) {
+ put_device(>dev);
+ return NULL;
+ }
+
+ i915 = devm_drm_dev_alloc(>dev, _driver,
+ struct drm_i915_private, drm);
+ if (IS_ERR(i915)) {
+ pr_err("Failed to allocate mock GEM device: err=%ld\n",
PTR_ERR(i915));
+ devres_release_group(>dev, NULL);
+ put_device(>dev);
+
+ return NULL;
+ }
pci_set_drvdata(pdev, i915);
+ i915->drm.pdev = pdev;
dev_pm_domain_set(>dev, _domain);
pm_runtime_enable(>dev);
pgp_LFf_K5vBd.pgp
Description: OpenPGP digital signature
RE: [EXT] Re: [PATCH 2/5] arm64: dts: lx2160a-rdb: remove useless property of rtc
>
>
>
> > -Original Message-
> > From: Biwen Li
> > Sent: Monday, September 21, 2020 10:13 PM
> > To: Shawn Guo ; Biwen Li (OSS)
> >
> > Cc: alexandre.bell...@bootlin.com; Leo Li ;
> > robh...@kernel.org; mark.rutl...@arm.com; devicet...@vger.kernel.org;
> > linux-kernel@vger.kernel.org; Jiafei Pan ; linux-
> > r...@vger.kernel.org
> > Subject: RE: [EXT] Re: [PATCH 2/5] arm64: dts: lx2160a-rdb: remove
> > useless property of rtc
> >
> > >
> > > Caution: EXT Email
> > >
> > > On Tue, Sep 15, 2020 at 03:32:10PM +0800, Biwen Li wrote:
> > > > From: Biwen Li
> > > >
> > > > Remove useless property interrupts of rtc
> > > >
> > > > Signed-off-by: Biwen Li
> > > > ---
> > > > arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts | 2 --
> > > > 1 file changed, 2 deletions(-)
> > > >
> > > > diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts
> > > > b/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts
> > > > index dce79018d397..e9e982176e07 100644
> > > > --- a/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts
> > > > +++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts
> > > > @@ -171,8 +171,6 @@
> > > > rtc@51 {
> > > > compatible = "nxp,pcf2129";
> > > > reg = <0x51>;
> > > > - // IRQ10_B
> > > > - interrupts = <0 150 0x4>;
> > >
> > > If it's a correct description of hardware, I do not see why we would
> > > need to remove it.
> > Hi Shawn,
> >
> > Don't need use the interrupt, only read time from rtc.
>
> User probably will choose to use the alarm feature of the RTC and need the
> interrupt property. Is there any issue when the interrupt property is
> present?
Generic interrupt controller on layerscape only support IRQ_TYPE_LEVEL_HIGH
and IRQ_TYPE_EDGE_RISING(except SoC LS1043A, LS1046A),
Not support IRQ_TYPE_LEVEL_LOW,
In drivers/rtc/rtc-pcf2127.c
ret = devm_request_threaded_irq(dev, alarm_irq, NULL,
pcf2127_rtc_irq,
IRQF_TRIGGER_LOW | IRQF_ONESHOT,
dev_name(dev), dev);
>
> >
> > Best Regards,
> > Biwen Li
> > >
> > > Shawn
> > >
> > > > };
> > > > };
> > > >
> > > > --
> > > > 2.17.1
> > > >
RE: [EXT] Re: [PATCH 2/5] arm64: dts: lx2160a-rdb: remove useless property of rtc
> -Original Message-
> From: Biwen Li
> Sent: Monday, September 21, 2020 10:13 PM
> To: Shawn Guo ; Biwen Li (OSS)
>
> Cc: alexandre.bell...@bootlin.com; Leo Li ;
> robh...@kernel.org; mark.rutl...@arm.com; devicet...@vger.kernel.org;
> linux-kernel@vger.kernel.org; Jiafei Pan ; linux-
> r...@vger.kernel.org
> Subject: RE: [EXT] Re: [PATCH 2/5] arm64: dts: lx2160a-rdb: remove useless
> property of rtc
>
> >
> > Caution: EXT Email
> >
> > On Tue, Sep 15, 2020 at 03:32:10PM +0800, Biwen Li wrote:
> > > From: Biwen Li
> > >
> > > Remove useless property interrupts of rtc
> > >
> > > Signed-off-by: Biwen Li
> > > ---
> > > arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts | 2 --
> > > 1 file changed, 2 deletions(-)
> > >
> > > diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts
> > > b/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts
> > > index dce79018d397..e9e982176e07 100644
> > > --- a/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts
> > > +++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts
> > > @@ -171,8 +171,6 @@
> > > rtc@51 {
> > > compatible = "nxp,pcf2129";
> > > reg = <0x51>;
> > > - // IRQ10_B
> > > - interrupts = <0 150 0x4>;
> >
> > If it's a correct description of hardware, I do not see why we would
> > need to remove it.
> Hi Shawn,
>
> Don't need use the interrupt, only read time from rtc.
User probably will choose to use the alarm feature of the RTC and need the
interrupt property. Is there any issue when the interrupt property is present?
>
> Best Regards,
> Biwen Li
> >
> > Shawn
> >
> > > };
> > > };
> > >
> > > --
> > > 2.17.1
> > >
Re: [PATCH] kbuild: Try up to eight kallsyms link passes
On Thu, Sep 10, 2020 at 08:32:04AM -0700, Guenter Roeck wrote:
> Since v5.8, powerpc:allmodconfig often fails to build with the following
> error message.
>
> Inconsistent kallsyms data
> Try make KALLSYMS_EXTRA_PASS=1 as a workaround
>
> Setting KALLSYMS_EXTRA_PASS=1 does not help. As it turns out, the build
> currently needs up to four link passes to succeed.
>
> Similar problems have been observed over time for other architectures.
>
> Make the number of link passes dynamic to solve the problem. Try up to
> eight passes before giving up. If KALLSYMS_EXTRA_PASS is set, add one
> additional pass after succeeding.
>
> Suggested-by: Geert Uytterhoeven
> Cc: Geert Uytterhoeven
> Signed-off-by: Guenter Roeck
I still see a build failure for powerpc:allmodconfig due to this problem.
Feedback/comments/thoughts ? Does anyone have a better idea ?
Thanks,
Guenter
> ---
> scripts/link-vmlinux.sh | 31 +++
> 1 file changed, 19 insertions(+), 12 deletions(-)
>
> diff --git a/scripts/link-vmlinux.sh b/scripts/link-vmlinux.sh
> index e6e2d9e5ff48..72abdee0e649 100755
> --- a/scripts/link-vmlinux.sh
> +++ b/scripts/link-vmlinux.sh
> @@ -316,11 +316,10 @@ if [ -n "${CONFIG_KALLSYMS}" ]; then
> # From here, we generate a correct .tmp_kallsyms2.o
> # 3) That link may have expanded the kernel image enough that
> # more linker branch stubs / trampolines had to be added, which
> - # introduces new names, which further expands kallsyms. Do another
> - # pass if that is the case. In theory it's possible this results
> - # in even more stubs, but unlikely.
> - # KALLSYMS_EXTRA_PASS=1 may also used to debug or work around
> - # other bugs.
> + # introduces new names, which further expands kallsyms. Try up
> + # to eight passes to handle that situation before giving up.
> + # KALLSYMS_EXTRA_PASS=1 may be used to add an extra step
> + # for debugging or to work around other bugs.
> # 4) The correct ${kallsymso} is linked into the final vmlinux.
> #
> # a) Verify that the System.map from vmlinux matches the map from
> @@ -329,13 +328,21 @@ if [ -n "${CONFIG_KALLSYMS}" ]; then
> kallsyms_step 1
> kallsyms_step 2
>
> - # step 3
> - size1=$(${CONFIG_SHELL} "${srctree}/scripts/file-size.sh"
> ${kallsymso_prev})
> - size2=$(${CONFIG_SHELL} "${srctree}/scripts/file-size.sh" ${kallsymso})
> -
> - if [ $size1 -ne $size2 ] || [ -n "${KALLSYMS_EXTRA_PASS}" ]; then
> - kallsyms_step 3
> - fi
> + # step n
> + step=3
> + while [ $step -le 8 ]; do
> + size1=$(${CONFIG_SHELL} "${srctree}/scripts/file-size.sh"
> ${kallsymso_prev})
> + size2=$(${CONFIG_SHELL} "${srctree}/scripts/file-size.sh"
> ${kallsymso})
> +
> + if [ $size1 -eq $size2 ]; then
> + if [ -z "${KALLSYMS_EXTRA_PASS}" ]; then
> + break
> + fi
> + KALLSYMS_EXTRA_PASS=""
> + fi
> + kallsyms_step $step
> + step="$(expr $step + 1)"
> + done
> fi
>
> vmlinux_link vmlinux "${kallsymso}" ${btf_vmlinux_bin_o}
> --
> 2.17.1
>
Re: [RFC][PATCH 1/4] acpi: Use CPUIDLE_FLAG_TIMER_STOP
On Tue, Sep 15, 2020 at 12:31:58PM +0200, Peter Zijlstra wrote:
> Make acpi_processor_idle use the common broadcast code, there's no
> reason not to. This also removes some RCU usage after
> rcu_idle_enter().
>
> Signed-off-by: Peter Zijlstra (Intel)
> Acked-by: Rafael J. Wysocki
> Reported-by: Borislav Petkov
> Tested-by: Borislav Petkov
> ---
> drivers/acpi/processor_idle.c | 49
> +-
> 1 file changed, 16 insertions(+), 33 deletions(-)
>
> --- a/drivers/acpi/processor_idle.c
> +++ b/drivers/acpi/processor_idle.c
> @@ -161,18 +161,10 @@ static void lapic_timer_propagate_broadc
> }
>
> /* Power(C) State timer broadcast control */
> -static void lapic_timer_state_broadcast(struct acpi_processor *pr,
> -struct acpi_processor_cx *cx,
> -int broadcast)
> -{
> - int state = cx - pr->power.states;
> -
> - if (state >= pr->power.timer_broadcast_on_state) {
> - if (broadcast)
> - tick_broadcast_enter();
> - else
> - tick_broadcast_exit();
> - }
> +static bool lapic_timer_needs_broadcast(struct acpi_processor *pr,
> + struct acpi_processor_cx *cx)
> +{
> + return cx - pr->power.states >= pr->power.timer_broadcast_on_state;
> }
>
> #else
> @@ -180,9 +172,9 @@ static void lapic_timer_state_broadcast(
> static void lapic_timer_check_state(int state, struct acpi_processor *pr,
> struct acpi_processor_cx *cstate) { }
> static void lapic_timer_propagate_broadcast(struct acpi_processor *pr) { }
> -static void lapic_timer_state_broadcast(struct acpi_processor *pr,
> -struct acpi_processor_cx *cx,
> -int broadcast)
> +
> +static bool lapic_timer_needs_broadcast(struct acpi_processor *pr,
> + struct acpi_processor_cx *cx)
> {
> }
drivers/acpi/processor_idle.c: In function 'lapic_timer_needs_broadcast':
drivers/acpi/processor_idle.c:179:1: warning: no return statement in function
returning non-void [-Wreturn-type]
Should this return true or false ?
Guenter
>
> @@ -568,21 +560,13 @@ static DEFINE_RAW_SPINLOCK(c3_lock);
> * acpi_idle_enter_bm - enters C3 with proper BM handling
> * @pr: Target processor
> * @cx: Target state context
> - * @timer_bc: Whether or not to change timer mode to broadcast
> */
> static void acpi_idle_enter_bm(struct acpi_processor *pr,
> -struct acpi_processor_cx *cx, bool timer_bc)
> +struct acpi_processor_cx *cx)
> {
> acpi_unlazy_tlb(smp_processor_id());
>
> /*
> - * Must be done before busmaster disable as we might need to
> - * access HPET !
> - */
> - if (timer_bc)
> - lapic_timer_state_broadcast(pr, cx, 1);
> -
> - /*
>* disable bus master
>* bm_check implies we need ARB_DIS
>* bm_control implies whether we can do ARB_DIS
> @@ -609,9 +593,6 @@ static void acpi_idle_enter_bm(struct ac
> c3_cpu_count--;
> raw_spin_unlock(_lock);
> }
> -
> - if (timer_bc)
> - lapic_timer_state_broadcast(pr, cx, 0);
> }
>
> static int acpi_idle_enter(struct cpuidle_device *dev,
> @@ -630,7 +611,7 @@ static int acpi_idle_enter(struct cpuidl
> cx = per_cpu(acpi_cstate[index], dev->cpu);
> } else if (cx->type == ACPI_STATE_C3 && pr->flags.bm_check) {
> if (cx->bm_sts_skip || !acpi_idle_bm_check()) {
> - acpi_idle_enter_bm(pr, cx, true);
> + acpi_idle_enter_bm(pr, cx);
> return index;
> } else if (drv->safe_state_index >= 0) {
> index = drv->safe_state_index;
> @@ -642,15 +623,11 @@ static int acpi_idle_enter(struct cpuidl
> }
> }
>
> - lapic_timer_state_broadcast(pr, cx, 1);
> -
> if (cx->type == ACPI_STATE_C3)
> ACPI_FLUSH_CPU_CACHE();
>
> acpi_idle_do_entry(cx);
>
> - lapic_timer_state_broadcast(pr, cx, 0);
> -
> return index;
> }
>
> @@ -666,7 +643,7 @@ static int acpi_idle_enter_s2idle(struct
> return 0;
>
> if (pr->flags.bm_check) {
> - acpi_idle_enter_bm(pr, cx, false);
> + acpi_idle_enter_bm(pr, cx);
> return 0;
> } else {
> ACPI_FLUSH_CPU_CACHE();
> @@ -682,6 +659,7 @@ static int acpi_processor_setup_cpuidle_
> {
> int i, count = ACPI_IDLE_STATE_START;
> struct acpi_processor_cx *cx;
> + struct cpuidle_state *state;
>
> if (max_cstate == 0)
> max_cstate = 1;
> @@ -694,6 +672,11 @@ static int
Re: [PATCH v4] mtd: parsers: bcm63xx: simplify CFE detection
On 9/21/20 8:18 PM, Naresh Kamboju wrote:
> On Fri, 14 Aug 2020 at 14:26, Guenter Roeck wrote:
>>
>> On Mon, Jun 15, 2020 at 11:17:40AM +0200, Álvaro Fernández Rojas wrote:
>>> Instead of trying to parse CFE version string, which is customized by some
>>> vendors, let's just check that "CFE1" was passed on argument 3.
>>>
>>> Signed-off-by: Álvaro Fernández Rojas
>>> Signed-off-by: Jonas Gorski
>>> Reviewed-by: Florian Fainelli
>>
>
> We still see mips: allmodconfig build failure on Linus tree
>
Yes, same here.
Guenter
> make -sk KBUILD_BUILD_USER=TuxBuild -C/linux ARCH=mips
> CROSS_COMPILE=mips-linux-gnu- HOSTCC=gcc CC="sccache
> mips-linux-gnu-gcc" O=build allmodconfig
>
> make -sk KBUILD_BUILD_USER=TuxBuild -C/linux -j16 ARCH=mips
> CROSS_COMPILE=mips-linux-gnu- HOSTCC=gcc CC="sccache
> mips-linux-gnu-gcc" O=build
>
>
>> mips:allmodconfig:
>>
>> ERROR: modpost: "fw_arg3" [drivers/mtd/parsers/bcm63xxpart.ko] undefined!
>
> ERROR: modpost: "fw_arg3" [drivers/mtd/parsers/bcm63xxpart.ko] undefined!
>
> Reported-by: Naresh Kamboju
>
> Full build link,
> https://builds.tuxbuild.com/Sm59_9tjFMpIvT27qf5kNA/build.log
>
>>
>> This is not surprising, since fw_arg3 is not exported.
>>
>> Guenter
>>
>>> ---
>>> v4: shorten conditional compilation part as suggested by Miquèl.
>>> v3: keep COMPILE_TEST compatibility by adding a new function that only
>>> checks
>>> fw_arg3 when CONFIG_MIPS is defined.
>>> v2: use CFE_EPTSEAL definition and avoid using an additional function.
>>>
>>> drivers/mtd/parsers/bcm63xxpart.c | 32 ---
>>> 1 file changed, 12 insertions(+), 20 deletions(-)
>>>
>>> diff --git a/drivers/mtd/parsers/bcm63xxpart.c
>>> b/drivers/mtd/parsers/bcm63xxpart.c
>>> index 78f90c6c18fd..b15bdadaedb5 100644
>>> --- a/drivers/mtd/parsers/bcm63xxpart.c
>>> +++ b/drivers/mtd/parsers/bcm63xxpart.c
>>> @@ -22,6 +22,11 @@
>>> #include
>>> #include
>>>
>>> +#ifdef CONFIG_MIPS
>>> +#include
>>> +#include
>>> +#endif /* CONFIG_MIPS */
>>> +
>>> #define BCM963XX_CFE_BLOCK_SIZE SZ_64K /* always at least
>>> 64KiB */
>>>
>>> #define BCM963XX_CFE_MAGIC_OFFSET0x4e0
>>> @@ -32,28 +37,15 @@
>>> #define STR_NULL_TERMINATE(x) \
>>> do { char *_str = (x); _str[sizeof(x) - 1] = 0; } while (0)
>>>
>>> -static int bcm63xx_detect_cfe(struct mtd_info *master)
>>> +static inline int bcm63xx_detect_cfe(void)
>>> {
>>> - char buf[9];
>>> - int ret;
>>> - size_t retlen;
>>> + int ret = 0;
>>>
>>> - ret = mtd_read(master, BCM963XX_CFE_VERSION_OFFSET, 5, ,
>>> -(void *)buf);
>>> - buf[retlen] = 0;
>>> +#ifdef CONFIG_MIPS
>>> + ret = (fw_arg3 == CFE_EPTSEAL);
>>> +#endif /* CONFIG_MIPS */
>>>
>>> - if (ret)
>>> - return ret;
>>> -
>>> - if (strncmp("cfe-v", buf, 5) == 0)
>>> - return 0;
>>> -
>>> - /* very old CFE's do not have the cfe-v string, so check for magic */
>>> - ret = mtd_read(master, BCM963XX_CFE_MAGIC_OFFSET, 8, ,
>>> -(void *)buf);
>>> - buf[retlen] = 0;
>>> -
>>> - return strncmp("CFE1CFE1", buf, 8);
>>> + return ret;
>>> }
>>>
>>> static int bcm63xx_read_nvram(struct mtd_info *master,
>>> @@ -138,7 +130,7 @@ static int bcm63xx_parse_cfe_partitions(struct mtd_info
>>> *master,
>>> struct bcm963xx_nvram *nvram = NULL;
>>> int ret;
>>>
>>> - if (bcm63xx_detect_cfe(master))
>>> + if (!bcm63xx_detect_cfe())
>>> return -EINVAL;
>>>
>>> nvram = vzalloc(sizeof(*nvram));
Re: [RFC] fpga: dfl: a prototype uio driver
On Mon, Sep 21, 2020 at 12:32:16PM -0700, Tom Rix wrote: > > On 9/21/20 1:55 AM, Xu Yilun wrote: > > On Sat, Sep 19, 2020 at 09:51:13AM -0700, t...@redhat.com wrote: > >> From: Tom Rix > >> > >> I following up on Moritz asking for early RFC's by showing how this > >> could be done with the concrete example of around > >> > >> [PATCH 0/3] add VFIO mdev support for DFL devices > >> > >> I hacked this together, it barely works. Do not expect that this > >> patch to apply anywhere. It has enough to show where I want > >> to go and people can comment without me having invested a lot of > >> effort. I am not expecting to carry this forward, it only > >> addresses the issues I had with the origin patch. > >> > >> This change adds a uio driver for any unclaimed dfl feature > >> > >> During the normal matching of feature id's to drivers, some > >> of the features are not claimed because there neither a > >> builtin driver nor a module driver that matches the feature > >> id. For these unclaimed features, provide a uio driver to a > >> possible user space driver. > > I think we don't have to setup UIO interfaces for all unclaimed > > features. It could be the decision of the user whether the UIO > > device is needed for a feature. My opinion is that, the > > driver_override sysfs is still generic enough for user's to switch > > between kernel device drivers and dfl uio driver. > > Instead of a string, could there just be a 'use_uio' flag ? > > How does the 'driver_override' work when there is no starting driver ? Now we have a dfl bus_type, we could add the 'driver_override' to each dfl device on dfl bus. It is the same as 'feature_id' & 'type'. Actually the 'driver_override' also exists in various bus type (platform, pci ...). > > > > > There may be cases the dfl device driver modules are not inserted > > during dfl-fme/port initialization, but they are to be inserted > > manually. If the features are all registered to uio, then there will > > be problems when dfl device drivers module are inserted. > > How does this manual loading work ? The driver list for the features > > seems to only be used during the card probe time. > > To change the order the dfl-pci needs to be unloaded and that will > > destroy all the uio devices as well as usual feature drivers attached to > > the pci driver. After we have introduced the dfl bus patches. The initialization flow is: 1. dfl-fme/port initializes its core private features (listed in fme/port_feature_drvs array), these private features are part of the dfl-fme/port module. They cannot be exposed as uio devices cause they are managed by the dfl-fme/afu kernel driver. 2. The rest of the private features are added as dfl devices. They can be matched by independent dfl driver modules. dfl-n3000-nios is the first use case. The dfl-n3000-nios.ko may not be loaded when dfl-fme probe, but later user loads the module manually by "insmod drivers/fpga/dfl-n3000-nios.ko". If we create uio interfaces for all unclaimed features on dfl-fme/port probe, then I can see problem when user insmod dfl-n3000-nios.ko For these dfl devices, we could give users an option to manage them by userspace I/O access. The flow I suggest is like: a) load the uio-dfl.ko, it will not match any dfl device now. # modprobe uio-dfl b) unbind the kernel driver for the specific dfl device # echo dfl_dev.0 > /sys/bus/dfl/drivers/n3000-nios/unbind c) assign the uio driver for the dfl device. Please note this will not trigger any driver matching. # echo uio-dfl > /sys/bus/dfl/devices/dfl_dev.0/driver_override d) actually trigger the driver matching, then the uio-dfl module takes function. # echo dfl_dev.0 > /sys/bus/dfl/drivers_probe > > > > > > > >> I have doubts that a uio for an afu feature is approptiate as these > >> can be any device. > > I think generally afu could also be as uio device if we don't concern > > about dma isolation. > > I am thinking about afu with its own pci id. > > So there could be a conflict with some other driver that responds to the pci > id. I think 'driver_override' mechanism solves the problem, it ensures no other driver could be matched to the device except your assigned one. > > > > > But now seems not possible to match afu to uio driver, cause now in DFL > > framework AFU is managed by dfl-afu.ko > > > >> Another possible problem is if the number of interrupts for the > >> feature is greater than 1. Uio seems to only support 1. My guess > >> is this would need some hackery in the open() to add to the > >> interrupt handler. > > I think it may not possible for UIO to support multiple interrupts if > > user cannot access the interrupt enable/pending registers. The uio > > device have just one /dev/uioX node for interrupt. So I tend to > > accept the limitation. And for now we don't have board specific > > features that needs multiple interrupts. For PAC N3000, no interrupt is > > needed. > Maybe uio
[PATCH v2 0/2] perf: Update CascadelakeX and SkylakeX events list
This patchset updates CascadelakeX events to v1.08 and updates SkylakeX events to v1.21. The events have been tested on CascadelakeX and SkylakeX servers with latest perf/core branch. The first version was posted a few months ago and now just resend the patchset with minor update. v2: - Change 'MB/sec' to 'MB' in UNC_M_PMM_BANDWIDTH. Jin Yao (2): perf vendor events: Update CascadelakeX events to v1.08 perf vendor events: Update SkylakeX events to v1.21 .../arch/x86/cascadelakex/cache.json | 28 +- .../arch/x86/cascadelakex/clx-metrics.json| 153 +- .../arch/x86/cascadelakex/frontend.json | 34 + .../arch/x86/cascadelakex/memory.json | 704 ++--- .../arch/x86/cascadelakex/other.json | 1100 .../arch/x86/cascadelakex/pipeline.json | 10 - .../arch/x86/cascadelakex/uncore-memory.json | 12 +- .../arch/x86/cascadelakex/uncore-other.json | 21 + .../pmu-events/arch/x86/skylakex/cache.json | 2348 + .../arch/x86/skylakex/floating-point.json | 96 +- .../arch/x86/skylakex/frontend.json | 656 ++--- .../pmu-events/arch/x86/skylakex/memory.json | 1977 +++--- .../pmu-events/arch/x86/skylakex/other.json | 172 +- .../arch/x86/skylakex/pipeline.json | 1206 + .../arch/x86/skylakex/skx-metrics.json| 141 +- .../arch/x86/skylakex/uncore-memory.json | 26 +- .../arch/x86/skylakex/uncore-other.json | 730 - .../arch/x86/skylakex/virtual-memory.json | 358 +-- 18 files changed, 5204 insertions(+), 4568 deletions(-) -- 2.17.1
Re: [PATCH v4] mtd: parsers: bcm63xx: simplify CFE detection
On Fri, 14 Aug 2020 at 14:26, Guenter Roeck wrote:
>
> On Mon, Jun 15, 2020 at 11:17:40AM +0200, Álvaro Fernández Rojas wrote:
> > Instead of trying to parse CFE version string, which is customized by some
> > vendors, let's just check that "CFE1" was passed on argument 3.
> >
> > Signed-off-by: Álvaro Fernández Rojas
> > Signed-off-by: Jonas Gorski
> > Reviewed-by: Florian Fainelli
>
We still see mips: allmodconfig build failure on Linus tree
make -sk KBUILD_BUILD_USER=TuxBuild -C/linux ARCH=mips
CROSS_COMPILE=mips-linux-gnu- HOSTCC=gcc CC="sccache
mips-linux-gnu-gcc" O=build allmodconfig
make -sk KBUILD_BUILD_USER=TuxBuild -C/linux -j16 ARCH=mips
CROSS_COMPILE=mips-linux-gnu- HOSTCC=gcc CC="sccache
mips-linux-gnu-gcc" O=build
> mips:allmodconfig:
>
> ERROR: modpost: "fw_arg3" [drivers/mtd/parsers/bcm63xxpart.ko] undefined!
ERROR: modpost: "fw_arg3" [drivers/mtd/parsers/bcm63xxpart.ko] undefined!
Reported-by: Naresh Kamboju
Full build link,
https://builds.tuxbuild.com/Sm59_9tjFMpIvT27qf5kNA/build.log
>
> This is not surprising, since fw_arg3 is not exported.
>
> Guenter
>
> > ---
> > v4: shorten conditional compilation part as suggested by Miquèl.
> > v3: keep COMPILE_TEST compatibility by adding a new function that only
> > checks
> > fw_arg3 when CONFIG_MIPS is defined.
> > v2: use CFE_EPTSEAL definition and avoid using an additional function.
> >
> > drivers/mtd/parsers/bcm63xxpart.c | 32 ---
> > 1 file changed, 12 insertions(+), 20 deletions(-)
> >
> > diff --git a/drivers/mtd/parsers/bcm63xxpart.c
> > b/drivers/mtd/parsers/bcm63xxpart.c
> > index 78f90c6c18fd..b15bdadaedb5 100644
> > --- a/drivers/mtd/parsers/bcm63xxpart.c
> > +++ b/drivers/mtd/parsers/bcm63xxpart.c
> > @@ -22,6 +22,11 @@
> > #include
> > #include
> >
> > +#ifdef CONFIG_MIPS
> > +#include
> > +#include
> > +#endif /* CONFIG_MIPS */
> > +
> > #define BCM963XX_CFE_BLOCK_SIZE SZ_64K /* always at least
> > 64KiB */
> >
> > #define BCM963XX_CFE_MAGIC_OFFSET0x4e0
> > @@ -32,28 +37,15 @@
> > #define STR_NULL_TERMINATE(x) \
> > do { char *_str = (x); _str[sizeof(x) - 1] = 0; } while (0)
> >
> > -static int bcm63xx_detect_cfe(struct mtd_info *master)
> > +static inline int bcm63xx_detect_cfe(void)
> > {
> > - char buf[9];
> > - int ret;
> > - size_t retlen;
> > + int ret = 0;
> >
> > - ret = mtd_read(master, BCM963XX_CFE_VERSION_OFFSET, 5, ,
> > -(void *)buf);
> > - buf[retlen] = 0;
> > +#ifdef CONFIG_MIPS
> > + ret = (fw_arg3 == CFE_EPTSEAL);
> > +#endif /* CONFIG_MIPS */
> >
> > - if (ret)
> > - return ret;
> > -
> > - if (strncmp("cfe-v", buf, 5) == 0)
> > - return 0;
> > -
> > - /* very old CFE's do not have the cfe-v string, so check for magic */
> > - ret = mtd_read(master, BCM963XX_CFE_MAGIC_OFFSET, 8, ,
> > -(void *)buf);
> > - buf[retlen] = 0;
> > -
> > - return strncmp("CFE1CFE1", buf, 8);
> > + return ret;
> > }
> >
> > static int bcm63xx_read_nvram(struct mtd_info *master,
> > @@ -138,7 +130,7 @@ static int bcm63xx_parse_cfe_partitions(struct mtd_info
> > *master,
> > struct bcm963xx_nvram *nvram = NULL;
> > int ret;
> >
> > - if (bcm63xx_detect_cfe(master))
> > + if (!bcm63xx_detect_cfe())
> > return -EINVAL;
> >
> > nvram = vzalloc(sizeof(*nvram));
Re: [PATCH v3] memory: dfl-emif: add the DFL EMIF private feature driver
Hi Krzysztof, On Mon, Sep 21, 2020 at 10:46:45PM +0200, Krzysztof Kozlowski wrote: > WhOn Mon, 21 Sep 2020 at 22:31, Moritz Fischer wrote: > > > > Hi Krzysztof, > > > > On Mon, Sep 21, 2020 at 09:23:11AM +0200, Krzysztof Kozlowski wrote: > > > On Mon, Sep 21, 2020 at 01:31:20PM +0800, Xu Yilun wrote: > > > > This driver is for the EMIF private feature implemented under FPGA > > > > Device Feature List (DFL) framework. It is used to expose memory > > > > interface status information as well as memory clearing control. > > > > > > > > The purpose of memory clearing block is to zero out all private memory > > > > when FPGA is to be reprogrammed. This gives users a reliable method to > > > > prevent potential data leakage. > > > > > > > > Signed-off-by: Xu Yilun > > > > Signed-off-by: Russ Weight > > > > --- > > > > v2: Adjust the position of this driver in Kconfig. > > > > Improves the name of the Kconfig option. > > > > Change the include dfl-bus.h to dfl.h, cause the previous patchset > > > > renames the file. > > > > Some minor fixes and comment improvement. > > > > v3: Adjust the position of the driver in Makefile. > > > > --- > > > > .../ABI/testing/sysfs-bus-dfl-devices-emif | 25 +++ > > > > drivers/memory/Kconfig | 9 + > > > > drivers/memory/Makefile| 2 + > > > > drivers/memory/dfl-emif.c | 207 > > > > + > > > > 4 files changed, 243 insertions(+) > > > > create mode 100644 Documentation/ABI/testing/sysfs-bus-dfl-devices-emif > > > > create mode 100644 drivers/memory/dfl-emif.c > > > > > > > > > > Hi Moritz, > > > > > > Since this depends on dfl patches, I would need a stable tag with them > > > or you can take it directly: > > > Acked-by: Krzysztof Kozlowski > > > > > > Best regards, > > > Krzysztof > > > > The FPGA patches go through Greg's tree. For the time being it's > > probably easiest if I take the changes through my tree once Greg pulled > > my tree. > > Yes. > > > > > Do you have any feedback to better handle this sort of subsystem > > spanning changesets for me? > > The easiest through a separate branch. Assuming that such need for > sharing patches is known. > > If the patches touch generic things, which could be used by other > drivers/subsystems, or if it is known that there will be someone > depending on them, the easiest is to put them on separate branch which > you later merge into your for-next. You send to Greg your for-next. If > these patches are needed by someone else, e.g. me, you prepare a tag > on them and send a pull request with that tag. I pull it and send > these (and only these!) along with other patches. No duplication of > commits, only two merges. > > Recent example was here: > https://lore.kernel.org/lkml/20200819191722.ga38...@sirena.org.uk/ > where Mark Brown wanted these through his tree, but later work on > Samsung ARM depended on them. > > Best regards, > Krzysztof Appreciate the explanation, that makes sense. Thanks for taking the time. I'll do this moving forward. Cheers, Moritz
Re: [RFC][Patch v1 1/3] sched/isolation: API to get num of hosekeeping CPUs
On 9/21/20 7:40 PM, Frederic Weisbecker wrote:
> On Wed, Sep 09, 2020 at 11:08:16AM -0400, Nitesh Narayan Lal wrote:
>> +/*
>> + * num_housekeeping_cpus() - Read the number of housekeeping CPUs.
>> + *
>> + * This function returns the number of available housekeeping CPUs
>> + * based on __num_housekeeping_cpus which is of type atomic_t
>> + * and is initialized at the time of the housekeeping setup.
>> + */
>> +unsigned int num_housekeeping_cpus(void)
>> +{
>> +unsigned int cpus;
>> +
>> +if (static_branch_unlikely(_overridden)) {
>> +cpus = atomic_read(&__num_housekeeping_cpus);
>> +/* We should always have at least one housekeeping CPU */
>> +BUG_ON(!cpus);
>> +return cpus;
>> +}
>> +return num_online_cpus();
>> +}
>> +EXPORT_SYMBOL_GPL(num_housekeeping_cpus);
>> +
>> int housekeeping_any_cpu(enum hk_flags flags)
>> {
>> int cpu;
>> @@ -131,6 +153,7 @@ static int __init housekeeping_setup(char *str, enum
>> hk_flags flags)
>>
>> housekeeping_flags |= flags;
>>
>> +atomic_set(&__num_housekeeping_cpus, cpumask_weight(housekeeping_mask));
> So the problem here is that it takes the whole cpumask weight but you're only
> interested in the housekeepers who take the managed irq duties I guess
> (HK_FLAG_MANAGED_IRQ ?).
IMHO we should also consider the cases where we only have nohz_full.
Otherwise, we may run into the same situation on those setups, do you agree?
>
>> free_bootmem_cpumask_var(non_housekeeping_mask);
>>
>> return 1;
>> --
>> 2.27.0
>>
--
Thanks
Nitesh
signature.asc
Description: OpenPGP digital signature
[PATCH 0/2] perf stat: Unbreak perf stat with ARMv8 PMU events
Currently, perf-stat with armv8_pmu events with a workload is broken. This patch set just fixes that. Before the patch set: [root@localhost hulk]# tools/perf/perf stat -e armv8_pmuv3_0/ll_cache_rd/,armv8_pmuv3_0/ll_cache_miss_rd/ ls > /dev/null Segmentation fault After the patch set: [root@localhost hulk]# tools/perf/perf stat -e armv8_pmuv3_0/ll_cache_rd/,armv8_pmuv3_0/ll_cache_miss_rd/ ls > /dev/null Performance counter stats for 'ls': 39,882 armv8_pmuv3_0/ll_cache_rd/ 9,639 armv8_pmuv3_0/ll_cache_miss_rd/ 0.001416690 seconds time elapsed 0.001469000 seconds user 0.0 seconds sys Wei Li (2): perf stat: Fix segfault when counting armv8 PMU events perf stat: Unbreak perf stat with armv8 PMU events tools/lib/perf/include/internal/evlist.h | 1 + tools/perf/builtin-stat.c| 37 tools/perf/util/evlist.c | 23 ++- 3 files changed, 48 insertions(+), 13 deletions(-) -- 2.17.1
[PATCH 1/2] perf stat: Fix segfault when counting armv8_pmu events
When executing perf stat with armv8_pmu events with a workload, it will
report a segfault as result.
(gdb) bt
#0 0x00603fc8 in perf_evsel__close_fd_cpu (evsel=,
cpu=) at evsel.c:122
#1 perf_evsel__close_cpu (evsel=evsel@entry=0x716e950, cpu=7) at evsel.c:156
#2 0x004d4718 in evlist__close (evlist=0x70a7cb0) at util/evlist.c:1242
#3 0x00453404 in __run_perf_stat (argc=3, argc@entry=1, argv=0x30,
argv@entry=0xfaea2f90, run_idx=119, run_idx@entry=1701998435)
at builtin-stat.c:929
#4 0x00455058 in run_perf_stat (run_idx=1701998435,
argv=0xfaea2f90,
argc=1) at builtin-stat.c:947
#5 cmd_stat (argc=1, argv=0xfaea2f90) at builtin-stat.c:2357
#6 0x004bb888 in run_builtin (p=p@entry=0x9764b8 ,
argc=argc@entry=4, argv=argv@entry=0xfaea2f90) at perf.c:312
#7 0x004bbb54 in handle_internal_command (argc=argc@entry=4,
argv=argv@entry=0xfaea2f90) at perf.c:364
#8 0x00435378 in run_argv (argcp=,
argv=) at perf.c:408
#9 main (argc=4, argv=0xfaea2f90) at perf.c:538
After debugging, i found the root reason is that the xyarray fd is created
by evsel__open_per_thread() ignoring the cpu passed in
create_perf_stat_counter(), while the evsel' cpumap is assigned as the
corresponding PMU's cpumap in __add_event(). Thus, the xyarray fd is created
with ncpus of dummy cpumap and an out of bounds 'cpu' index will be used in
perf_evsel__close_fd_cpu().
To address this, add a flag to mark this situation and avoid using the
affinity technique when closing/enabling/disabling events.
Fixes: 7736627b865d ("perf stat: Use affinity for closing file descriptors")
Fixes: 704e2f5b700d ("perf stat: Use affinity for enabling/disabling events")
Signed-off-by: Wei Li
---
tools/lib/perf/include/internal/evlist.h | 1 +
tools/perf/builtin-stat.c| 3 +++
tools/perf/util/evlist.c | 23 ++-
3 files changed, 26 insertions(+), 1 deletion(-)
diff --git a/tools/lib/perf/include/internal/evlist.h
b/tools/lib/perf/include/internal/evlist.h
index 2d0fa02b036f..c02d7e583846 100644
--- a/tools/lib/perf/include/internal/evlist.h
+++ b/tools/lib/perf/include/internal/evlist.h
@@ -17,6 +17,7 @@ struct perf_evlist {
struct list_head entries;
int nr_entries;
bool has_user_cpus;
+ bool open_per_thread;
struct perf_cpu_map *cpus;
struct perf_cpu_map *all_cpus;
struct perf_thread_map *threads;
diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index fddc97cac984..6e6ceacce634 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -725,6 +725,9 @@ static int __run_perf_stat(int argc, const char **argv, int
run_idx)
if (group)
perf_evlist__set_leader(evsel_list);
+ if (!(target__has_cpu() && !target__has_per_thread()))
+ evsel_list->core.open_per_thread = true;
+
if (affinity__setup() < 0)
return -1;
diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
index e3fa3bf7498a..bf8a3ccc599f 100644
--- a/tools/perf/util/evlist.c
+++ b/tools/perf/util/evlist.c
@@ -383,6 +383,15 @@ void evlist__disable(struct evlist *evlist)
int cpu, i, imm = 0;
bool has_imm = false;
+ if (evlist->core.open_per_thread) {
+ evlist__for_each_entry(evlist, pos) {
+ if (pos->disabled || !evsel__is_group_leader(pos) ||
!pos->core.fd)
+ continue;
+ evsel__disable(pos);
+ }
+ goto out;
+ }
+
if (affinity__setup() < 0)
return;
@@ -414,6 +423,7 @@ void evlist__disable(struct evlist *evlist)
pos->disabled = true;
}
+out:
evlist->enabled = false;
}
@@ -423,6 +433,15 @@ void evlist__enable(struct evlist *evlist)
struct affinity affinity;
int cpu, i;
+ if (evlist->core.open_per_thread) {
+ evlist__for_each_entry(evlist, pos) {
+ if (!evsel__is_group_leader(pos) || !pos->core.fd)
+ continue;
+ evsel__enable(pos);
+ }
+ goto out;
+ }
+
if (affinity__setup() < 0)
return;
@@ -444,6 +463,7 @@ void evlist__enable(struct evlist *evlist)
pos->disabled = false;
}
+out:
evlist->enabled = true;
}
@@ -1223,9 +1243,10 @@ void evlist__close(struct evlist *evlist)
/*
* With perf record core.cpus is usually NULL.
+* Or perf stat may open events per-thread.
* Use the old method to handle this for now.
*/
- if (!evlist->core.cpus) {
+ if (evlist->core.open_per_thread || !evlist->core.cpus) {
[PATCH 2/2] perf stat: Unbreak perf stat with armv8_pmu events
After the segfault is fixed, perf-stat with armv8_pmu events with a
workload is still broken:
[root@localhost hulk]# tools/perf/perf stat -e
armv8_pmuv3_0/ll_cache_rd/,armv8_pmuv3_0/ll_cache_miss_rd/ ls > /dev/null
Performance counter stats for 'ls':
armv8_pmuv3_0/ll_cache_rd/
(0.00%)
armv8_pmuv3_0/ll_cache_miss_rd/
(0.00%)
0.002052670 seconds time elapsed
0.0 seconds user
0.002086000 seconds sys
In fact, while the event will be opened per-thread,
create_perf_stat_counter() is called as many times as the count of cpu
in the evlist's cpumap, and lost all the file descriptors except the
last one. If this counter is not scheduled during the period of time,
it will be "not counted".
Add the process to don't open the needless events in such situation.
Fixes: 4804e0111662 ("perf stat: Use affinity for opening events")
Signed-off-by: Wei Li
---
tools/perf/builtin-stat.c | 36 +++-
1 file changed, 23 insertions(+), 13 deletions(-)
diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index 6e6ceacce634..9a43b3de26d1 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -712,6 +712,7 @@ static int __run_perf_stat(int argc, const char **argv, int
run_idx)
struct affinity affinity;
int i, cpu;
bool second_pass = false;
+ bool open_per_thread = false;
if (forks) {
if (perf_evlist__prepare_workload(evsel_list, , argv,
is_pipe,
@@ -726,16 +727,17 @@ static int __run_perf_stat(int argc, const char **argv,
int run_idx)
perf_evlist__set_leader(evsel_list);
if (!(target__has_cpu() && !target__has_per_thread()))
- evsel_list->core.open_per_thread = true;
+ evsel_list->core.open_per_thread = open_per_thread = true;
if (affinity__setup() < 0)
return -1;
evlist__for_each_cpu (evsel_list, i, cpu) {
- affinity__set(, cpu);
+ if (!open_per_thread)
+ affinity__set(, cpu);
evlist__for_each_entry(evsel_list, counter) {
- if (evsel__cpu_iter_skip(counter, cpu))
+ if (!open_per_thread && evsel__cpu_iter_skip(counter,
cpu))
continue;
if (counter->reset_group || counter->errored)
continue;
@@ -753,7 +755,8 @@ static int __run_perf_stat(int argc, const char **argv, int
run_idx)
if ((errno == EINVAL || errno == EBADF) &&
counter->leader != counter &&
counter->weak_group) {
-
perf_evlist__reset_weak_group(evsel_list, counter, false);
+
perf_evlist__reset_weak_group(evsel_list, counter,
+ open_per_thread);
assert(counter->reset_group);
second_pass = true;
continue;
@@ -773,6 +776,9 @@ static int __run_perf_stat(int argc, const char **argv, int
run_idx)
}
counter->supported = true;
}
+
+ if (open_per_thread)
+ break;
}
if (second_pass) {
@@ -782,20 +788,22 @@ static int __run_perf_stat(int argc, const char **argv,
int run_idx)
*/
evlist__for_each_cpu(evsel_list, i, cpu) {
- affinity__set(, cpu);
- /* First close errored or weak retry */
- evlist__for_each_entry(evsel_list, counter) {
- if (!counter->reset_group && !counter->errored)
- continue;
- if (evsel__cpu_iter_skip_no_inc(counter, cpu))
- continue;
- perf_evsel__close_cpu(>core,
counter->cpu_iter);
+ if (!open_per_thread) {
+ affinity__set(, cpu);
+ /* First close errored or weak retry */
+ evlist__for_each_entry(evsel_list, counter) {
+ if (!counter->reset_group &&
!counter->errored)
+ continue;
+ if
(evsel__cpu_iter_skip_no_inc(counter, cpu))
+ continue;
+ perf_evsel__close_cpu(>core,
counter->cpu_iter);
+ }
}
/* Now
Re: [PATCH 2/2] mm,swap: skip swap readahead if page was obtained instantaneously
On Tue, Sep 22, 2020 at 10:02 AM Rik van Riel wrote:
>
> Check whether a swap page was obtained instantaneously, for example
> because it is in zswap, or on a very fast IO device which uses busy
> waiting, and we did not wait on IO to swap in this page.
> If no IO was needed to get the swap page we want, kicking off readahead
> on surrounding swap pages is likely to be counterproductive, because the
> extra loads will cause additional latency, use up extra memory, and chances
> are the surrounding pages in swap are just as fast to load as this one,
> making readahead pointless.
>
> Signed-off-by: Rik van Riel
> ---
> mm/swap_state.c | 14 +++---
> 1 file changed, 11 insertions(+), 3 deletions(-)
>
> diff --git a/mm/swap_state.c b/mm/swap_state.c
> index aacb9ba53f63..6919f9d5fe88 100644
> --- a/mm/swap_state.c
> +++ b/mm/swap_state.c
> @@ -637,6 +637,7 @@ static struct page *swap_cluster_read_one(swp_entry_t
> entry,
> struct page *swap_cluster_readahead(swp_entry_t entry, gfp_t gfp_mask,
> struct vm_fault *vmf)
Why not do this for swap_vma_readahead() too? swap_cluster_read_one()
can be used in swap_vma_readahead() too.
> {
> + struct page *page;
> unsigned long entry_offset = swp_offset(entry);
> unsigned long offset = entry_offset;
> unsigned long start_offset, end_offset;
> @@ -668,11 +669,18 @@ struct page *swap_cluster_readahead(swp_entry_t entry,
> gfp_t gfp_mask,
> end_offset = si->max - 1;
>
> blk_start_plug();
> + /* If we read the page without waiting on IO, skip readahead. */
> + page = swap_cluster_read_one(entry, offset, gfp_mask, vma, addr,
> false);
> + if (page && PageUptodate(page))
> + goto skip_unplug;
> +
> + /* Ok, do the async read-ahead now. */
> for (offset = start_offset; offset <= end_offset ; offset++) {
> - /* Ok, do the async read-ahead now */
> - swap_cluster_read_one(entry, offset, gfp_mask, vma, addr,
> - offset != entry_offset);
> + if (offset == entry_offset)
> + continue;
> + swap_cluster_read_one(entry, offset, gfp_mask, vma, addr,
> true);
> }
> +skip_unplug:
> blk_finish_plug();
>
> lru_add_drain();/* Push any new pages onto the LRU now */
Best Regards,
Huang, Ying
RE: [EXT] Re: [PATCH 2/5] arm64: dts: lx2160a-rdb: remove useless property of rtc
>
> Caution: EXT Email
>
> On Tue, Sep 15, 2020 at 03:32:10PM +0800, Biwen Li wrote:
> > From: Biwen Li
> >
> > Remove useless property interrupts of rtc
> >
> > Signed-off-by: Biwen Li
> > ---
> > arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts | 2 --
> > 1 file changed, 2 deletions(-)
> >
> > diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts
> > b/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts
> > index dce79018d397..e9e982176e07 100644
> > --- a/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts
> > +++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts
> > @@ -171,8 +171,6 @@
> > rtc@51 {
> > compatible = "nxp,pcf2129";
> > reg = <0x51>;
> > - // IRQ10_B
> > - interrupts = <0 150 0x4>;
>
> If it's a correct description of hardware, I do not see why we would need to
> remove it.
Hi Shawn,
Don't need use the interrupt, only read time from rtc.
Best Regards,
Biwen Li
>
> Shawn
>
> > };
> > };
> >
> > --
> > 2.17.1
> >
Re: [RFC][Patch v1 2/3] i40e: limit msix vectors based on housekeeping CPUs
On 9/21/20 6:58 PM, Frederic Weisbecker wrote: > On Thu, Sep 17, 2020 at 11:23:59AM -0700, Jesse Brandeburg wrote: >> Nitesh Narayan Lal wrote: >> >>> In a realtime environment, it is essential to isolate unwanted IRQs from >>> isolated CPUs to prevent latency overheads. Creating MSIX vectors only >>> based on the online CPUs could lead to a potential issue on an RT setup >>> that has several isolated CPUs but a very few housekeeping CPUs. This is >>> because in these kinds of setups an attempt to move the IRQs to the >>> limited housekeeping CPUs from isolated CPUs might fail due to the per >>> CPU vector limit. This could eventually result in latency spikes because >>> of the IRQ threads that we fail to move from isolated CPUs. >>> >>> This patch prevents i40e to add vectors only based on available >>> housekeeping CPUs by using num_housekeeping_cpus(). >>> >>> Signed-off-by: Nitesh Narayan Lal >> The driver changes are straightforward, but this isn't the only driver >> with this issue, right? I'm sure ixgbe and ice both have this problem >> too, you should fix them as well, at a minimum, and probably other >> vendors drivers: >> >> $ rg -c --stats num_online_cpus drivers/net/ethernet >> ... >> 50 files contained matches > Ouch, I was indeed surprised that these MSI vector allocations were done > at the driver level and not at some $SUBSYSTEM level. > > The logic is already there in the driver so I wouldn't oppose to this very > patch > but would a shared infrastructure make sense for this? Something that would > also handle hotplug operations? > > Does it possibly go even beyond networking drivers? >From a generic solution perspective, I think it makes sense to come up with a shared infrastructure. Something that can be consumed by all the drivers and maybe hotplug operations as well (I will have to further explore the hotplug part). However, there are RT workloads that are getting affected because of this issue, so does it make sense to go ahead with this per-driver basis approach for now? Since a generic solution will require a fair amount of testing and understanding of different drivers. Having said that, I can definetly start looking in that direction. Thanks for reviewing. > Thanks. > >> for this patch i40e >> Acked-by: Jesse Brandeburg -- Nitesh signature.asc Description: OpenPGP digital signature
[PATCH v7 1/4] dt-bindings: Add vendor prefix for Caninos Loucos
The Caninos Loucos Program develops Single Board Computers with an open structure. The Program wants to form a community of developers to use IoT technologies and disseminate the learning of embedded systems in Brazil. It is an initiative of the Technological Integrated Systems Laboratory (LSI-TEC) with the support of Polytechnic School of the University of São Paulo (Poli-USP) and Jon "Maddog" Hall. Signed-off-by: Matheus Castello Acked-by: Rob Herring Reviewed-by: Andreas Färber --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 63996ab03521..aac0dc3caf3b 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -179,6 +179,8 @@ patternProperties: description: CALAO Systems SAS "^calxeda,.*": description: Calxeda + "^caninos,.*": +description: Caninos Loucos Program "^capella,.*": description: Capella Microsystems, Inc "^cascoda,.*": -- 2.28.0
[PATCH v7 4/4] arm64: dts: Add Caninos Loucos Labrador v3
Add Device Trees for Caninos Loucos Labrador CoM Core v3 and base board
M v2. Based on the work of Andreas Färber on Cubieboard 7 device tree.
Signed-off-by: Matheus Castello
---
arch/arm64/boot/dts/actions/Makefile | 2 +
.../dts/actions/s700-labrador-base-m2.dts | 34 +
.../boot/dts/actions/s700-labrador-v3.dtsi| 122 ++
3 files changed, 158 insertions(+)
create mode 100644 arch/arm64/boot/dts/actions/s700-labrador-base-m2.dts
create mode 100644 arch/arm64/boot/dts/actions/s700-labrador-v3.dtsi
diff --git a/arch/arm64/boot/dts/actions/Makefile
b/arch/arm64/boot/dts/actions/Makefile
index b57fd2372ecd..3765697fa91e 100644
--- a/arch/arm64/boot/dts/actions/Makefile
+++ b/arch/arm64/boot/dts/actions/Makefile
@@ -2,4 +2,6 @@
dtb-$(CONFIG_ARCH_ACTIONS) += s700-cubieboard7.dtb
+dtb-$(CONFIG_ARCH_ACTIONS) += s700-labrador-base-m2.dtb
+
dtb-$(CONFIG_ARCH_ACTIONS) += s900-bubblegum-96.dtb
diff --git a/arch/arm64/boot/dts/actions/s700-labrador-base-m2.dts
b/arch/arm64/boot/dts/actions/s700-labrador-base-m2.dts
new file mode 100644
index ..63bbca46475b
--- /dev/null
+++ b/arch/arm64/boot/dts/actions/s700-labrador-base-m2.dts
@@ -0,0 +1,34 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2020 Matheus Castello
+ */
+
+/dts-v1/;
+
+#include "s700-labrador-v3.dtsi"
+
+/ {
+ compatible = "caninos,labrador-base-m2",
+"caninos,labrador-v3", "actions,s700";
+ model = "Caninos Labrador Core v3 on Labrador Base-M v2";
+
+ aliases {
+ serial3 =
+ };
+
+ chosen {
+ stdout-path = "serial3:115200n8";
+ };
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
diff --git a/arch/arm64/boot/dts/actions/s700-labrador-v3.dtsi
b/arch/arm64/boot/dts/actions/s700-labrador-v3.dtsi
new file mode 100644
index ..91addba6382b
--- /dev/null
+++ b/arch/arm64/boot/dts/actions/s700-labrador-v3.dtsi
@@ -0,0 +1,122 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2020 Matheus Castello
+ */
+
+#include "s700.dtsi"
+
+/ {
+ compatible = "caninos,labrador-v3", "actions,s700";
+ model = "Caninos Labrador Core v3.1";
+
+ memory@0 {
+ device_type = "memory";
+ reg = <0x0 0x0 0x0 0x8000>;
+ };
+
+ memory@1,e000 {
+ device_type = "memory";
+ reg = <0x1 0xe000 0x0 0x0>;
+ };
+
+ /* Labrador v3 firmware does not support PSCI */
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu0: cpu@0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53";
+ reg = <0x0>;
+ enable-method = "spin-table";
+ cpu-release-addr = <0 0x1f20>;
+ next-level-cache = <>;
+ };
+
+ cpu1: cpu@1 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53";
+ reg = <0x1>;
+ enable-method = "spin-table";
+ cpu-release-addr = <0 0x1f20>;
+ next-level-cache = <>;
+ };
+
+ cpu2: cpu@2 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53";
+ reg = <0x2>;
+ enable-method = "spin-table";
+ cpu-release-addr = <0 0x1f20>;
+ next-level-cache = <>;
+ };
+
+ cpu3: cpu@3 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53";
+ reg = <0x3>;
+ enable-method = "spin-table";
+ cpu-release-addr = <0 0x1f20>;
+ next-level-cache = <>;
+ };
+ };
+
+ L2: l2-cache {
+ compatible = "cache";
+ cache-level = <2>;
+ };
+};
+
+ {
+ clocks = <>;
+};
+
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_default>;
+};
+
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_default>;
+};
+
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_default>;
+};
+
+ {
+ i2c0_default: i2c0_default {
+ pinmux {
+ groups = "i2c0_mfp";
+ function = "i2c0";
+ };
+ pinconf {
+ pins = "i2c0_sclk", "i2c0_sdata";
+ bias-pull-up;
+ };
+ };
+
+ i2c1_default: i2c1_default {
+ pinmux {
+ groups = "i2c1_dummy";
+ function = "i2c1";
+ };
+ pinconf {
+
[PATCH v7 2/4] dt-bindings: arm: actions: Document Caninos Loucos Labrador
Update the documentation to add the Caninos Loucos Labrador. Labrador project consists of the computer on module Core v2 based on the Actions Semi S500, computer on module Core v3 based on the Actions Semi S700 and the Labrador base boards. Signed-off-by: Matheus Castello Acked-by: Rob Herring --- Documentation/devicetree/bindings/arm/actions.yaml | 10 ++ 1 file changed, 10 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/actions.yaml b/Documentation/devicetree/bindings/arm/actions.yaml index ace3fdaa8396..1cc66803ce2a 100644 --- a/Documentation/devicetree/bindings/arm/actions.yaml +++ b/Documentation/devicetree/bindings/arm/actions.yaml @@ -19,6 +19,11 @@ properties: - allo,sparky # Allo.com Sparky - cubietech,cubieboard6 # Cubietech CubieBoard6 - const: actions,s500 + - items: + - enum: + - caninos,labrador-base-m # Labrador Base Board M v1 + - const: caninos,labrador-v2 # Labrador Core v2 + - const: actions,s500 - items: - enum: - lemaker,guitar-bb-rev-b # LeMaker Guitar Base Board rev. B @@ -26,6 +31,11 @@ properties: - const: actions,s500 # The Actions Semi S700 is a quad-core ARM Cortex-A53 SoC. + - items: + - enum: + - caninos,labrador-base-m2 # Labrador Base Board M v2 + - const: caninos,labrador-v3 # Labrador Core v3 + - const: actions,s700 - items: - enum: - cubietech,cubieboard7 # Cubietech CubieBoard7 -- 2.28.0
[PATCH v7 3/4] ARM: dts: Add Caninos Loucos Labrador v2
Add Device Trees for Caninos Loucos Labrador CoM Core v2 and base board
M v1. Based on the work of Andreas Färber on Lemaker Guitar device tree.
Signed-off-by: Matheus Castello
Reviewed-by: Manivannan Sadhasivam
Reviewed-by: Andreas Färber
---
arch/arm/boot/dts/Makefile| 1 +
.../arm/boot/dts/owl-s500-labrador-base-m.dts | 35 +++
arch/arm/boot/dts/owl-s500-labrador-v2.dtsi | 22
3 files changed, 58 insertions(+)
create mode 100644 arch/arm/boot/dts/owl-s500-labrador-base-m.dts
create mode 100644 arch/arm/boot/dts/owl-s500-labrador-v2.dtsi
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 4572db3fa5ae..5d5e370af290 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -868,6 +868,7 @@ dtb-$(CONFIG_ARCH_ORION5X) += \
dtb-$(CONFIG_ARCH_ACTIONS) += \
owl-s500-cubieboard6.dtb \
owl-s500-guitar-bb-rev-b.dtb \
+ owl-s500-labrador-base-m.dtb \
owl-s500-sparky.dtb
dtb-$(CONFIG_ARCH_PRIMA2) += \
prima2-evb.dtb
diff --git a/arch/arm/boot/dts/owl-s500-labrador-base-m.dts
b/arch/arm/boot/dts/owl-s500-labrador-base-m.dts
new file mode 100644
index ..c92f8bdcb331
--- /dev/null
+++ b/arch/arm/boot/dts/owl-s500-labrador-base-m.dts
@@ -0,0 +1,35 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Caninos Labrador Base Board
+ *
+ * Copyright (c) 2019-2020 Matheus Castello
+ */
+
+/dts-v1/;
+
+#include "owl-s500-labrador-v2.dtsi"
+
+/ {
+ model = "Caninos Labrador Core v2 on Labrador Base-M v1";
+ compatible = "caninos,labrador-base-m",
+"caninos,labrador-v2", "actions,s500";
+
+ aliases {
+ serial3 =
+ };
+
+ chosen {
+ stdout-path = "serial3:115200n8";
+ };
+
+ uart3_clk: uart3-clk {
+ compatible = "fixed-clock";
+ clock-frequency = <921600>;
+ #clock-cells = <0>;
+ };
+};
+
+ {
+ status = "okay";
+ clocks = <_clk>;
+};
diff --git a/arch/arm/boot/dts/owl-s500-labrador-v2.dtsi
b/arch/arm/boot/dts/owl-s500-labrador-v2.dtsi
new file mode 100644
index ..883ff2f9886d
--- /dev/null
+++ b/arch/arm/boot/dts/owl-s500-labrador-v2.dtsi
@@ -0,0 +1,22 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Caninos Labrador SoM V2
+ *
+ * Copyright (c) 2019-2020 Matheus Castello
+ */
+
+#include "owl-s500.dtsi"
+
+/ {
+ model = "Caninos Labrador Core V2.1";
+ compatible = "caninos,labrador-v2", "actions,s500";
+
+ memory@0 {
+ device_type = "memory";
+ reg = <0x0 0x8000>;
+ };
+};
+
+ {
+ clocks = <>;
+};
--
2.28.0
[PATCH v7 0/4] Add Caninos Loucos Labrador CoM and Base Board Device Tree
I'm adding to the series the new Labrador v3, since it uses the same vendor prefix. Thanks Andreas, Mani and Rob for your time reviewing it. Changes since v6: - Add new caninos,labrador-v3 CoM and caninos,labrador-base-m2 base board - Improve Model description Changes since v5: (Suggested by Andreas Färber) - Put caninos,labrador-v2 as const one level down Matheus Castello (4): dt-bindings: Add vendor prefix for Caninos Loucos dt-bindings: arm: actions: Document Caninos Loucos Labrador ARM: dts: Add Caninos Loucos Labrador v2 arm64: dts: Add Caninos Loucos Labrador v3 .../devicetree/bindings/arm/actions.yaml | 10 ++ .../devicetree/bindings/vendor-prefixes.yaml | 2 + arch/arm/boot/dts/Makefile| 1 + .../arm/boot/dts/owl-s500-labrador-base-m.dts | 35 + arch/arm/boot/dts/owl-s500-labrador-v2.dtsi | 22 arch/arm64/boot/dts/actions/Makefile | 2 + .../dts/actions/s700-labrador-base-m2.dts | 34 + .../boot/dts/actions/s700-labrador-v3.dtsi| 122 ++ 8 files changed, 228 insertions(+) create mode 100644 arch/arm/boot/dts/owl-s500-labrador-base-m.dts create mode 100644 arch/arm/boot/dts/owl-s500-labrador-v2.dtsi create mode 100644 arch/arm64/boot/dts/actions/s700-labrador-base-m2.dts create mode 100644 arch/arm64/boot/dts/actions/s700-labrador-v3.dtsi -- 2.28.0
Re: [PATCH 2/5] arm64: dts: lx2160a-rdb: remove useless property of rtc
On Tue, Sep 15, 2020 at 03:32:10PM +0800, Biwen Li wrote:
> From: Biwen Li
>
> Remove useless property interrupts of rtc
>
> Signed-off-by: Biwen Li
> ---
> arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts
> b/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts
> index dce79018d397..e9e982176e07 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts
> +++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts
> @@ -171,8 +171,6 @@
> rtc@51 {
> compatible = "nxp,pcf2129";
> reg = <0x51>;
> - // IRQ10_B
> - interrupts = <0 150 0x4>;
If it's a correct description of hardware, I do not see why we would
need to remove it.
Shawn
> };
> };
>
> --
> 2.17.1
>
Re: [PATCH v10 11/13] arm64: dts: freescale: sl28: enable LED support
On Mon, Sep 14, 2020 at 11:43:39PM +0200, Michael Walle wrote:
> Now that we have support for GPIO lines of the SMARC connector, enable
> LED support on the KBox A-230-LS. There are two LEDs without fixed
> functions, one is yellow and one is green. Unfortunately, it is just one
> multi-color LED, thus while it is possible to enable both at the same
> time it is hard to tell the difference between "yellow only" and "yellow
> and green".
>
> Signed-off-by: Michael Walle
> Acked-by: Pavel Machek
> ---
> Changes since v9:
> - none
>
> Changes since v8:
> - none
>
> Changes since v7:
> - use new "function" and "color" properties instead of a label
> - added default-on trigger for the power-led
>
> Changes since v6:
> - none
>
> Changes since v5:
> - changed the label, suggested by Pavel Machek
>
> Changes since v4:
> - none
>
> Changes since v3:
> - see cover letter
>
> .../fsl-ls1028a-kontron-kbox-a-230-ls.dts | 18 ++
> 1 file changed, 18 insertions(+)
>
> diff --git
> a/arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-kbox-a-230-ls.dts
> b/arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-kbox-a-230-ls.dts
> index 4b4cc6a1573d..dd516c0efd8b 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-kbox-a-230-ls.dts
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-kbox-a-230-ls.dts
> @@ -11,11 +11,29 @@
>
> /dts-v1/;
> #include "fsl-ls1028a-kontron-sl28-var4.dts"
> +#include
>
> / {
> model = "Kontron KBox A-230-LS";
> compatible = "kontron,kbox-a-230-ls", "kontron,sl28-var4",
>"kontron,sl28", "fsl,ls1028a";
> +
> + leds {
> + compatible = "gpio-leds";
> +
> + alarm-led {
> + function = LED_FUNCTION_ALARM;
> + color = ;
> + gpios = <_gpio0 0 0>;
> + };
> +
> + power-led {
> + linux,default-trigger = "default-on";
> + function = LED_FUNCTION_POWER;
> + color = ;
> + gpios = <_gpio1 3 0>;
Use GPIO_ACTIVE_HIGH for polarity to improve the readability.
I fixed them up and applied patch #9 ~ #13.
Shawn
> + };
> + };
> };
>
> _mdio_pf3 {
> --
> 2.20.1
>
Re: [PATCH] soc: mediatek: Check if power domains can be powered on at boot time
Hi,
On Tue, Sep 22, 2020 at 1:07 AM Matthias Brugger wrote:
>
> Hi Nicolas,
>
> Thanks for the patch.
>
> On 30/07/2020 06:01, Nicolas Boichat wrote:
> > In the error case, where a power domain cannot be powered on
> > successfully at boot time (in mtk_register_power_domains),
> > pm_genpd_init would still be called with is_off=false, and the
> > system would later try to disable the power domain again, triggering
> > warnings as disabled clocks are disabled again (and other potential
> > issues).
> >
> > Fixes: c84e358718a66f7 ("soc: Mediatek: Add SCPSYS power domain driver")
> > Signed-off-by: Nicolas Boichat
> >
> > ---
> >
> > drivers/soc/mediatek/mtk-scpsys.c | 5 +++--
> > 1 file changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/soc/mediatek/mtk-scpsys.c
> > b/drivers/soc/mediatek/mtk-scpsys.c
> > index f669d3754627dad..0055a52a49733d5 100644
> > --- a/drivers/soc/mediatek/mtk-scpsys.c
> > +++ b/drivers/soc/mediatek/mtk-scpsys.c
> > @@ -524,6 +524,7 @@ static void mtk_register_power_domains(struct
> > platform_device *pdev,
> > for (i = 0; i < num; i++) {
> > struct scp_domain *scpd = >domains[i];
> > struct generic_pm_domain *genpd = >genpd;
> > + bool on;
> >
> > /*
> >* Initially turn on all domains to make the domains usable
> > @@ -531,9 +532,9 @@ static void mtk_register_power_domains(struct
> > platform_device *pdev,
> >* software. The unused domains will be switched off during
> >* late_init time.
> >*/
> > - genpd->power_on(genpd);
> > + on = genpd->power_on(genpd) >= 0;
>
> Is this something we expect? On probing we realize that some domains can't be
> turned on?
>
> I understand that this would be a bug in the driver. Therefore we should at
> most
> provide a warning instead of working around the bug, hiding it. Or do I got
> this
> wrong?
No, you get this right. That's a bug (we see this on unreleased HW),
and we will fix it.
Now, we already get this (somewhat subtle) error message on boot:
mtk-scpsys 10006000.power-controller: Failed to power on domain adsp
But without this patch, there is an unbalance later on (that is
possibly a bit confusing):
[6.510811] [ cut here ]
[6.515417] adsp_sel already disabled
[6.519089] WARNING: CPU: 5 PID: 180 at drivers/clk/clk.c:958
clk_core_disable+0x1ec/0x22c
...
[6.658393] clk_core_disable+0x1ec/0x22c
[6.662395] clk_disable+0x34/0x48
[6.665791] scpsys_clk_disable+0x34/0x58
[6.669791] scpsys_power_off+0x374/0x3ec
[6.673790] _genpd_power_off+0x40/0x98
[6.677616] genpd_power_off+0x168/0x208
[6.681530] genpd_power_off_work_fn+0x38/0x54
[6.685964] process_one_work+0x208/0x3c8
[6.689964] worker_thread+0x23c/0x3e8
[6.693703] kthread+0x11c/0x12c
[6.696923] ret_from_fork+0x10/0x18
[6.700487] ---[ end trace 91ddada49c4d717c ]---
But I get your point, we should probably add something like
WARN_ON(!on) to make it clearer, at the time when the issue occurs,
that something is not right...
Thanks,
> Regards,
> Matthias
>
> >
> > - pm_genpd_init(genpd, NULL, false);
> > + pm_genpd_init(genpd, NULL, !on);
> > }
> >
> > /*
> >
Re: [PATCH v17 00/20] iommu/arm-smmu + drm/msm: per-process GPU pgtables
On Mon, Sep 21, 2020 at 10:30:57PM +0100, Will Deacon wrote: > On Sat, Sep 05, 2020 at 01:04:06PM -0700, Rob Clark wrote: > > From: Rob Clark > > > > NOTE: I have re-ordered the series, and propose that we could merge this > > series in the following order: > > > >1) 01-11 - merge via drm / msm-next > >2) 12-15 - merge via iommu, no dependency on msm-next pull req > > Thanks, I've queued 12-15 in the smmu tree. > > https://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git/log/?h=for-joerg/arm-smmu/updates > > Will Will, thanks for your help and patience in getting these merged. Jordan -- The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
[PATCH v9 16/20] tools: gpio: rename nlines to num_lines
Rename nlines to num_lines to be consistent with other usage for fields
describing the number of entries in an array.
Signed-off-by: Kent Gibson
---
tools/gpio/gpio-hammer.c | 26 +-
tools/gpio/gpio-utils.c | 20 ++--
tools/gpio/gpio-utils.h | 6 +++---
3 files changed, 26 insertions(+), 26 deletions(-)
diff --git a/tools/gpio/gpio-hammer.c b/tools/gpio/gpio-hammer.c
index 9fd926e8cb52..a2c7577fad5c 100644
--- a/tools/gpio/gpio-hammer.c
+++ b/tools/gpio/gpio-hammer.c
@@ -22,7 +22,7 @@
#include
#include "gpio-utils.h"
-int hammer_device(const char *device_name, unsigned int *lines, int nlines,
+int hammer_device(const char *device_name, unsigned int *lines, int num_lines,
unsigned int loops)
{
struct gpiohandle_data data;
@@ -33,7 +33,7 @@ int hammer_device(const char *device_name, unsigned int
*lines, int nlines,
unsigned int iteration = 0;
memset(, 0, sizeof(data.values));
- ret = gpiotools_request_linehandle(device_name, lines, nlines,
+ ret = gpiotools_request_linehandle(device_name, lines, num_lines,
GPIOHANDLE_REQUEST_OUTPUT, ,
"gpio-hammer");
if (ret < 0)
@@ -46,15 +46,15 @@ int hammer_device(const char *device_name, unsigned int
*lines, int nlines,
goto exit_close_error;
fprintf(stdout, "Hammer lines [");
- for (i = 0; i < nlines; i++) {
+ for (i = 0; i < num_lines; i++) {
fprintf(stdout, "%d", lines[i]);
- if (i != (nlines - 1))
+ if (i != (num_lines - 1))
fprintf(stdout, ", ");
}
fprintf(stdout, "] on %s, initial states: [", device_name);
- for (i = 0; i < nlines; i++) {
+ for (i = 0; i < num_lines; i++) {
fprintf(stdout, "%d", data.values[i]);
- if (i != (nlines - 1))
+ if (i != (num_lines - 1))
fprintf(stdout, ", ");
}
fprintf(stdout, "]\n");
@@ -63,7 +63,7 @@ int hammer_device(const char *device_name, unsigned int
*lines, int nlines,
j = 0;
while (1) {
/* Invert all lines so we blink */
- for (i = 0; i < nlines; i++)
+ for (i = 0; i < num_lines; i++)
data.values[i] = !data.values[i];
ret = gpiotools_set_values(fd, );
@@ -81,9 +81,9 @@ int hammer_device(const char *device_name, unsigned int
*lines, int nlines,
j = 0;
fprintf(stdout, "[");
- for (i = 0; i < nlines; i++) {
+ for (i = 0; i < num_lines; i++) {
fprintf(stdout, "%d: %d", lines[i], data.values[i]);
- if (i != (nlines - 1))
+ if (i != (num_lines - 1))
fprintf(stdout, ", ");
}
fprintf(stdout, "]\r");
@@ -121,7 +121,7 @@ int main(int argc, char **argv)
const char *device_name = NULL;
unsigned int lines[GPIOHANDLES_MAX];
unsigned int loops = 0;
- int nlines;
+ int num_lines;
int c;
int i;
@@ -158,11 +158,11 @@ int main(int argc, char **argv)
return -1;
}
- nlines = i;
+ num_lines = i;
- if (!device_name || !nlines) {
+ if (!device_name || !num_lines) {
print_usage();
return -1;
}
- return hammer_device(device_name, lines, nlines, loops);
+ return hammer_device(device_name, lines, num_lines, loops);
}
diff --git a/tools/gpio/gpio-utils.c b/tools/gpio/gpio-utils.c
index 16a5d9cb9da2..d527980bcb94 100644
--- a/tools/gpio/gpio-utils.c
+++ b/tools/gpio/gpio-utils.c
@@ -38,7 +38,7 @@
* such as "gpiochip0"
* @lines: An array desired lines, specified by offset
* index for the associated GPIO device.
- * @nline: The number of lines to request.
+ * @num_lines: The number of lines to request.
* @flag: The new flag for requsted gpio. Reference
* "linux/gpio.h" for the meaning of flag.
* @data: Default value will be set to gpio when flag is
@@ -56,7 +56,7 @@
* On failure return the errno.
*/
int gpiotools_request_linehandle(const char *device_name, unsigned int *lines,
-unsigned int nlines, unsigned int flag,
+unsigned int num_lines, unsigned int flag,
struct gpiohandle_data *data,
const char *consumer_label)
{
@@ -78,12 +78,12 @@ int gpiotools_request_linehandle(const char *device_name,
unsigned int *lines,
goto exit_free_name;
}
- for (i = 0; i < nlines; i++)
+
[PATCH v9 15/20] tools: gpio: port gpio-watch to v2 uAPI
Port the gpio-watch tool to the latest GPIO uAPI.
Signed-off-by: Kent Gibson
---
tools/gpio/gpio-watch.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/tools/gpio/gpio-watch.c b/tools/gpio/gpio-watch.c
index 5cea24fddfa7..f229ec62301b 100644
--- a/tools/gpio/gpio-watch.c
+++ b/tools/gpio/gpio-watch.c
@@ -21,8 +21,8 @@
int main(int argc, char **argv)
{
- struct gpioline_info_changed chg;
- struct gpioline_info req;
+ struct gpio_v2_line_info_changed chg;
+ struct gpio_v2_line_info req;
struct pollfd pfd;
int fd, i, j, ret;
char *event, *end;
@@ -40,11 +40,11 @@ int main(int argc, char **argv)
for (i = 0, j = 2; i < argc - 2; i++, j++) {
memset(, 0, sizeof(req));
- req.line_offset = strtoul(argv[j], , 0);
+ req.offset = strtoul(argv[j], , 0);
if (*end != '\0')
goto err_usage;
- ret = ioctl(fd, GPIO_GET_LINEINFO_WATCH_IOCTL, );
+ ret = ioctl(fd, GPIO_V2_GET_LINEINFO_WATCH_IOCTL, );
if (ret) {
perror("unable to set up line watch");
return EXIT_FAILURE;
@@ -71,13 +71,13 @@ int main(int argc, char **argv)
}
switch (chg.event_type) {
- case GPIOLINE_CHANGED_REQUESTED:
+ case GPIO_V2_LINE_CHANGED_REQUESTED:
event = "requested";
break;
- case GPIOLINE_CHANGED_RELEASED:
+ case GPIO_V2_LINE_CHANGED_RELEASED:
event = "released";
break;
- case GPIOLINE_CHANGED_CONFIG:
+ case GPIO_V2_LINE_CHANGED_CONFIG:
event = "config changed";
break;
default:
@@ -87,7 +87,7 @@ int main(int argc, char **argv)
}
printf("line %u: %s at %llu\n",
- chg.info.line_offset, event, chg.timestamp);
+ chg.info.offset, event, chg.timestamp_ns);
}
}
--
2.28.0
[PATCH v9 17/20] tools: gpio: port gpio-hammer to v2 uAPI
Port the gpio-hammer tool to the latest GPIO uAPI.
Signed-off-by: Kent Gibson
---
tools/gpio/gpio-hammer.c | 32 +---
tools/gpio/gpio-utils.c | 164 ---
tools/gpio/gpio-utils.h | 46 ++-
3 files changed, 197 insertions(+), 45 deletions(-)
diff --git a/tools/gpio/gpio-hammer.c b/tools/gpio/gpio-hammer.c
index a2c7577fad5c..54fdf59dd320 100644
--- a/tools/gpio/gpio-hammer.c
+++ b/tools/gpio/gpio-hammer.c
@@ -25,23 +25,30 @@
int hammer_device(const char *device_name, unsigned int *lines, int num_lines,
unsigned int loops)
{
- struct gpiohandle_data data;
+ struct gpio_v2_line_values values;
+ struct gpio_v2_line_config config;
char swirr[] = "-\\|/";
int fd;
int ret;
int i, j;
unsigned int iteration = 0;
- memset(, 0, sizeof(data.values));
- ret = gpiotools_request_linehandle(device_name, lines, num_lines,
- GPIOHANDLE_REQUEST_OUTPUT, ,
- "gpio-hammer");
+ memset(, 0, sizeof(config));
+ config.flags = GPIO_V2_LINE_FLAG_OUTPUT;
+
+ ret = gpiotools_request_line(device_name, lines, num_lines,
+, "gpio-hammer");
if (ret < 0)
goto exit_error;
else
fd = ret;
- ret = gpiotools_get_values(fd, );
+ values.mask = 0;
+ values.bits = 0;
+ for (i = 0; i < num_lines; i++)
+ gpiotools_set_bit(, i);
+
+ ret = gpiotools_get_values(fd, );
if (ret < 0)
goto exit_close_error;
@@ -53,7 +60,7 @@ int hammer_device(const char *device_name, unsigned int
*lines, int num_lines,
}
fprintf(stdout, "] on %s, initial states: [", device_name);
for (i = 0; i < num_lines; i++) {
- fprintf(stdout, "%d", data.values[i]);
+ fprintf(stdout, "%d", gpiotools_test_bit(values.bits, i));
if (i != (num_lines - 1))
fprintf(stdout, ", ");
}
@@ -64,14 +71,14 @@ int hammer_device(const char *device_name, unsigned int
*lines, int num_lines,
while (1) {
/* Invert all lines so we blink */
for (i = 0; i < num_lines; i++)
- data.values[i] = !data.values[i];
+ gpiotools_change_bit(, i);
- ret = gpiotools_set_values(fd, );
+ ret = gpiotools_set_values(fd, );
if (ret < 0)
goto exit_close_error;
/* Re-read values to get status */
- ret = gpiotools_get_values(fd, );
+ ret = gpiotools_get_values(fd, );
if (ret < 0)
goto exit_close_error;
@@ -82,7 +89,8 @@ int hammer_device(const char *device_name, unsigned int
*lines, int num_lines,
fprintf(stdout, "[");
for (i = 0; i < num_lines; i++) {
- fprintf(stdout, "%d: %d", lines[i], data.values[i]);
+ fprintf(stdout, "%d: %d", lines[i],
+ gpiotools_test_bit(values.bits, i));
if (i != (num_lines - 1))
fprintf(stdout, ", ");
}
@@ -97,7 +105,7 @@ int hammer_device(const char *device_name, unsigned int
*lines, int num_lines,
ret = 0;
exit_close_error:
- gpiotools_release_linehandle(fd);
+ gpiotools_release_line(fd);
exit_error:
return ret;
}
diff --git a/tools/gpio/gpio-utils.c b/tools/gpio/gpio-utils.c
index d527980bcb94..37187e056c8b 100644
--- a/tools/gpio/gpio-utils.c
+++ b/tools/gpio/gpio-utils.c
@@ -100,20 +100,87 @@ int gpiotools_request_linehandle(const char *device_name,
unsigned int *lines,
free(chrdev_name);
return ret < 0 ? ret : req.fd;
}
+
+/**
+ * gpiotools_request_line() - request gpio lines in a gpiochip
+ * @device_name: The name of gpiochip without prefix "/dev/",
+ * such as "gpiochip0"
+ * @lines: An array desired lines, specified by offset
+ * index for the associated GPIO device.
+ * @num_lines: The number of lines to request.
+ * @config:The new config for requested gpio. Reference
+ * "linux/gpio.h" for config details.
+ * @consumer: The name of consumer, such as "sysfs",
+ * "powerkey". This is useful for other users to
+ * know who is using.
+ *
+ * Request gpio lines through the ioctl provided by chardev. User
+ * could call gpiotools_set_values() and gpiotools_get_values() to
+ * read and write respectively through the returned fd. Call
+ * gpiotools_release_line() to release these lines after that.
+ *
+ * Return: On success return the fd;
+ * On failure return
[PATCH v9 20/20] tools: gpio: add debounce support to gpio-event-mon
Add support for debouncing monitored lines to gpio-event-mon.
Signed-off-by: Kent Gibson
---
tools/gpio/gpio-event-mon.c | 20 +---
1 file changed, 17 insertions(+), 3 deletions(-)
diff --git a/tools/gpio/gpio-event-mon.c b/tools/gpio/gpio-event-mon.c
index 0c34f18f511c..90c3155f05b1 100644
--- a/tools/gpio/gpio-event-mon.c
+++ b/tools/gpio/gpio-event-mon.c
@@ -148,11 +148,12 @@ void print_usage(void)
" -s Set line as open source\n"
" -r Listen for rising edges\n"
" -f Listen for falling edges\n"
+ " -b Debounce the line with period n microseconds\n"
" [-c ]Do loops (optional, infinite loop if not
stated)\n"
" -? This helptext\n"
"\n"
"Example:\n"
- "gpio-event-mon -n gpiochip0 -o 4 -r -f\n"
+ "gpio-event-mon -n gpiochip0 -o 4 -r -f -b 1\n"
);
}
@@ -167,11 +168,12 @@ int main(int argc, char **argv)
unsigned int num_lines = 0;
unsigned int loops = 0;
struct gpio_v2_line_config config;
- int c;
+ int c, attr, i;
+ unsigned long debounce_period_us = 0;
memset(, 0, sizeof(config));
config.flags = GPIO_V2_LINE_FLAG_INPUT;
- while ((c = getopt(argc, argv, "c:n:o:dsrf?")) != -1) {
+ while ((c = getopt(argc, argv, "c:n:o:b:dsrf?")) != -1) {
switch (c) {
case 'c':
loops = strtoul(optarg, NULL, 10);
@@ -187,6 +189,9 @@ int main(int argc, char **argv)
lines[num_lines] = strtoul(optarg, NULL, 10);
num_lines++;
break;
+ case 'b':
+ debounce_period_us = strtoul(optarg, NULL, 10);
+ break;
case 'd':
config.flags |= GPIO_V2_LINE_FLAG_OPEN_DRAIN;
break;
@@ -205,6 +210,15 @@ int main(int argc, char **argv)
}
}
+ if (debounce_period_us) {
+ attr = config.num_attrs;
+ config.num_attrs++;
+ for (i = 0; i < num_lines; i++)
+ gpiotools_set_bit([attr].mask, i);
+ config.attrs[attr].attr.id = GPIO_V2_LINE_ATTR_ID_DEBOUNCE;
+ config.attrs[attr].attr.debounce_period_us = debounce_period_us;
+ }
+
if (!device_name || num_lines == 0) {
print_usage();
return -1;
--
2.28.0
[PATCH v9 19/20] tools: gpio: add multi-line monitoring to gpio-event-mon
Extend gpio-event-mon to support monitoring multiple lines.
This would require multiple lineevent requests to implement using uAPI v1,
but can be performed with a single line request using uAPI v2.
Signed-off-by: Kent Gibson
---
tools/gpio/gpio-event-mon.c | 45 -
1 file changed, 34 insertions(+), 11 deletions(-)
diff --git a/tools/gpio/gpio-event-mon.c b/tools/gpio/gpio-event-mon.c
index b230af889f26..0c34f18f511c 100644
--- a/tools/gpio/gpio-event-mon.c
+++ b/tools/gpio/gpio-event-mon.c
@@ -26,7 +26,8 @@
#include "gpio-utils.h"
int monitor_device(const char *device_name,
- unsigned int line,
+ unsigned int *lines,
+ unsigned int num_lines,
struct gpio_v2_line_config *config,
unsigned int loops)
{
@@ -47,7 +48,7 @@ int monitor_device(const char *device_name,
goto exit_free_name;
}
- ret = gpiotools_request_line(device_name, , 1, config,
+ ret = gpiotools_request_line(device_name, lines, num_lines, config,
"gpio-event-mon");
if (ret < 0)
goto exit_device_close;
@@ -55,8 +56,10 @@ int monitor_device(const char *device_name,
lfd = ret;
/* Read initial states */
- values.mask = 1;
+ values.mask = 0;
values.bits = 0;
+ for (i = 0; i < num_lines; i++)
+ gpiotools_set_bit(, i);
ret = gpiotools_get_values(lfd, );
if (ret < 0) {
fprintf(stderr,
@@ -65,9 +68,23 @@ int monitor_device(const char *device_name,
goto exit_line_close;
}
- fprintf(stdout, "Monitoring line %d on %s\n", line, device_name);
- fprintf(stdout, "Initial line value: %d\n",
- gpiotools_test_bit(values.bits, 0));
+ if (num_lines == 1) {
+ fprintf(stdout, "Monitoring line %d on %s\n", lines[0],
device_name);
+ fprintf(stdout, "Initial line value: %d\n",
+ gpiotools_test_bit(values.bits, 0));
+ } else {
+ fprintf(stdout, "Monitoring lines %d", lines[0]);
+ for (i = 1; i < num_lines - 1; i++)
+ fprintf(stdout, ", %d", lines[i]);
+ fprintf(stdout, " and %d on %s\n", lines[i], device_name);
+ fprintf(stdout, "Initial line values: %d",
+ gpiotools_test_bit(values.bits, 0));
+ for (i = 1; i < num_lines - 1; i++)
+ fprintf(stdout, ", %d",
+ gpiotools_test_bit(values.bits, i));
+ fprintf(stdout, " and %d\n",
+ gpiotools_test_bit(values.bits, i));
+ }
while (1) {
struct gpio_v2_line_event event;
@@ -126,7 +143,7 @@ void print_usage(void)
fprintf(stderr, "Usage: gpio-event-mon [options]...\n"
"Listen to events on GPIO lines, 0->1 1->0\n"
" -n Listen on GPIOs on a named device (must be
stated)\n"
- " -o Offset to monitor\n"
+ " -o Offset of line to monitor (may be repeated)\n"
" -d Set line as open drain\n"
" -s Set line as open source\n"
" -r Listen for rising edges\n"
@@ -146,7 +163,8 @@ void print_usage(void)
int main(int argc, char **argv)
{
const char *device_name = NULL;
- unsigned int line = -1;
+ unsigned int lines[GPIO_V2_LINES_MAX];
+ unsigned int num_lines = 0;
unsigned int loops = 0;
struct gpio_v2_line_config config;
int c;
@@ -162,7 +180,12 @@ int main(int argc, char **argv)
device_name = optarg;
break;
case 'o':
- line = strtoul(optarg, NULL, 10);
+ if (num_lines >= GPIO_V2_LINES_MAX) {
+ print_usage();
+ return -1;
+ }
+ lines[num_lines] = strtoul(optarg, NULL, 10);
+ num_lines++;
break;
case 'd':
config.flags |= GPIO_V2_LINE_FLAG_OPEN_DRAIN;
@@ -182,7 +205,7 @@ int main(int argc, char **argv)
}
}
- if (!device_name || line == -1) {
+ if (!device_name || num_lines == 0) {
print_usage();
return -1;
}
@@ -191,5 +214,5 @@ int main(int argc, char **argv)
"falling edges\n");
config.flags |= EDGE_FLAGS;
}
- return monitor_device(device_name, line, , loops);
+ return monitor_device(device_name, lines, num_lines, , loops);
}
--
2.28.0
[PATCH v9 18/20] tools: gpio: port gpio-event-mon to v2 uAPI
Port the gpio-event-mon tool to the latest GPIO uAPI.
Signed-off-by: Kent Gibson
---
tools/gpio/gpio-event-mon.c | 91 +++--
1 file changed, 47 insertions(+), 44 deletions(-)
diff --git a/tools/gpio/gpio-event-mon.c b/tools/gpio/gpio-event-mon.c
index 1a303a81aeef..b230af889f26 100644
--- a/tools/gpio/gpio-event-mon.c
+++ b/tools/gpio/gpio-event-mon.c
@@ -23,17 +23,16 @@
#include
#include
#include
+#include "gpio-utils.h"
int monitor_device(const char *device_name,
unsigned int line,
- uint32_t handleflags,
- uint32_t eventflags,
+ struct gpio_v2_line_config *config,
unsigned int loops)
{
- struct gpioevent_request req;
- struct gpiohandle_data data;
+ struct gpio_v2_line_values values;
char *chrdev_name;
- int fd;
+ int cfd, lfd;
int ret;
int i = 0;
@@ -41,44 +40,39 @@ int monitor_device(const char *device_name,
if (ret < 0)
return -ENOMEM;
- fd = open(chrdev_name, 0);
- if (fd == -1) {
+ cfd = open(chrdev_name, 0);
+ if (cfd == -1) {
ret = -errno;
fprintf(stderr, "Failed to open %s\n", chrdev_name);
goto exit_free_name;
}
- req.lineoffset = line;
- req.handleflags = handleflags;
- req.eventflags = eventflags;
- strcpy(req.consumer_label, "gpio-event-mon");
-
- ret = ioctl(fd, GPIO_GET_LINEEVENT_IOCTL, );
- if (ret == -1) {
- ret = -errno;
- fprintf(stderr, "Failed to issue GET EVENT "
- "IOCTL (%d)\n",
- ret);
- goto exit_close_error;
- }
+ ret = gpiotools_request_line(device_name, , 1, config,
+"gpio-event-mon");
+ if (ret < 0)
+ goto exit_device_close;
+ else
+ lfd = ret;
/* Read initial states */
- ret = ioctl(req.fd, GPIOHANDLE_GET_LINE_VALUES_IOCTL, );
- if (ret == -1) {
- ret = -errno;
- fprintf(stderr, "Failed to issue GPIOHANDLE GET LINE "
- "VALUES IOCTL (%d)\n",
+ values.mask = 1;
+ values.bits = 0;
+ ret = gpiotools_get_values(lfd, );
+ if (ret < 0) {
+ fprintf(stderr,
+ "Failed to issue GPIO LINE GET VALUES IOCTL (%d)\n",
ret);
- goto exit_close_error;
+ goto exit_line_close;
}
fprintf(stdout, "Monitoring line %d on %s\n", line, device_name);
- fprintf(stdout, "Initial line value: %d\n", data.values[0]);
+ fprintf(stdout, "Initial line value: %d\n",
+ gpiotools_test_bit(values.bits, 0));
while (1) {
- struct gpioevent_data event;
+ struct gpio_v2_line_event event;
- ret = read(req.fd, , sizeof(event));
+ ret = read(lfd, , sizeof(event));
if (ret == -1) {
if (errno == -EAGAIN) {
fprintf(stderr, "nothing available\n");
@@ -96,12 +90,14 @@ int monitor_device(const char *device_name,
ret = -EIO;
break;
}
- fprintf(stdout, "GPIO EVENT %llu: ", event.timestamp);
+ fprintf(stdout, "GPIO EVENT at %llu on line %d (%d|%d) ",
+ event.timestamp_ns, event.offset, event.line_seqno,
+ event.seqno);
switch (event.id) {
- case GPIOEVENT_EVENT_RISING_EDGE:
+ case GPIO_V2_LINE_EVENT_RISING_EDGE:
fprintf(stdout, "rising edge");
break;
- case GPIOEVENT_EVENT_FALLING_EDGE:
+ case GPIO_V2_LINE_EVENT_FALLING_EDGE:
fprintf(stdout, "falling edge");
break;
default:
@@ -114,8 +110,11 @@ int monitor_device(const char *device_name,
break;
}
-exit_close_error:
- if (close(fd) == -1)
+exit_line_close:
+ if (close(lfd) == -1)
+ perror("Failed to close line file");
+exit_device_close:
+ if (close(cfd) == -1)
perror("Failed to close GPIO character device file");
exit_free_name:
free(chrdev_name);
@@ -140,15 +139,20 @@ void print_usage(void)
);
}
+#define EDGE_FLAGS \
+ (GPIO_V2_LINE_FLAG_EDGE_RISING | \
+GPIO_V2_LINE_FLAG_EDGE_FALLING)
+
int main(int argc, char **argv)
{
const char *device_name = NULL;
unsigned int line = -1;
unsigned int loops = 0;
- uint32_t handleflags = GPIOHANDLE_REQUEST_INPUT;
- uint32_t eventflags = 0;
+ struct gpio_v2_line_config config;
int c;
+ memset(,
[PATCH v9 09/20] gpiolib: cdev: support edge detection for uAPI v2
Add support for edge detection to lines requested using
GPIO_V2_GET_LINE_IOCTL.
The edge detector implementation is based on the v1 lineevent
implementation.
Unlike the v1 implementation, an overflow of the event buffer results
in discarding older events, rather than the most recent, so the final
event in a burst will correspond to the current state of the line.
Signed-off-by: Kent Gibson
---
The linereq_put_event() helper is only used once here, but is re-used in
subsequent patches, and so is pre-emptively split out.
edge_detector_stop() is extended in subsequent patches, and is strucured
to suit those additions.
drivers/gpio/gpiolib-cdev.c | 275
drivers/gpio/gpiolib.c | 2 +
drivers/gpio/gpiolib.h | 2 +
3 files changed, 279 insertions(+)
diff --git a/drivers/gpio/gpiolib-cdev.c b/drivers/gpio/gpiolib-cdev.c
index d3857113f58c..145bda2151fb 100644
--- a/drivers/gpio/gpiolib-cdev.c
+++ b/drivers/gpio/gpiolib-cdev.c
@@ -404,9 +404,33 @@ static int linehandle_create(struct gpio_device *gdev,
void __user *ip)
/**
* struct line - contains the state of a requested line
* @desc: the GPIO descriptor for this line.
+ * @req: the corresponding line request
+ * @irq: the interrupt triggered in response to events on this GPIO
+ * @eflags: the edge flags, GPIO_V2_LINE_FLAG_EDGE_RISING and/or
+ * GPIO_V2_LINE_FLAG_EDGE_FALLING, indicating the edge detection applied
+ * @timestamp_ns: cache for the timestamp storing it between hardirq and
+ * IRQ thread, used to bring the timestamp close to the actual event
+ * @req_seqno: the seqno for the current edge event in the sequence of
+ * events for the corresponding line request. This is drawn from the @req.
+ * @line_seqno: the seqno for the current edge event in the sequence of
+ * events for this line.
*/
struct line {
struct gpio_desc *desc;
+ /*
+* -- edge detector specific fields --
+*/
+ struct linereq *req;
+ unsigned int irq;
+ u64 eflags;
+ /*
+* timestamp_ns and req_seqno are accessed only by
+* edge_irq_handler() and edge_irq_thread(), which are themselves
+* mutually exclusive, so no additional protection is necessary.
+*/
+ u64 timestamp_ns;
+ u32 req_seqno;
+ u32 line_seqno;
};
/**
@@ -414,12 +438,22 @@ struct line {
* @gdev: the GPIO device the line request pertains to
* @label: consumer label used to tag GPIO descriptors
* @num_lines: the number of lines in the lines array
+ * @wait: wait queue that handles blocking reads of events
+ * @event_buffer_size: the number of elements allocated in @events
+ * @events: KFIFO for the GPIO events
+ * @seqno: the sequence number for edge events generated on all lines in
+ * this line request. Note that this is not used when @num_lines is 1, as
+ * the line_seqno is then the same and is cheaper to calculate.
* @lines: the lines held by this line request, with @num_lines elements.
*/
struct linereq {
struct gpio_device *gdev;
const char *label;
u32 num_lines;
+ wait_queue_head_t wait;
+ u32 event_buffer_size;
+ DECLARE_KFIFO_PTR(events, struct gpio_v2_line_event);
+ atomic_t seqno;
struct line lines[];
};
@@ -436,12 +470,150 @@ struct linereq {
(GPIO_V2_LINE_FLAG_OPEN_DRAIN | \
GPIO_V2_LINE_FLAG_OPEN_SOURCE)
+#define GPIO_V2_LINE_EDGE_FLAGS \
+ (GPIO_V2_LINE_FLAG_EDGE_RISING | \
+GPIO_V2_LINE_FLAG_EDGE_FALLING)
+
#define GPIO_V2_LINE_VALID_FLAGS \
(GPIO_V2_LINE_FLAG_ACTIVE_LOW | \
GPIO_V2_LINE_DIRECTION_FLAGS | \
GPIO_V2_LINE_DRIVE_FLAGS | \
+GPIO_V2_LINE_EDGE_FLAGS | \
GPIO_V2_LINE_BIAS_FLAGS)
+static void linereq_put_event(struct linereq *lr,
+ struct gpio_v2_line_event *le)
+{
+ bool overflow = false;
+
+ spin_lock(>wait.lock);
+ if (kfifo_is_full(>events)) {
+ overflow = true;
+ kfifo_skip(>events);
+ }
+ kfifo_in(>events, le, 1);
+ spin_unlock(>wait.lock);
+ if (!overflow)
+ wake_up_poll(>wait, EPOLLIN);
+ else
+ pr_debug_ratelimited("event FIFO is full - event dropped\n");
+}
+
+static irqreturn_t edge_irq_thread(int irq, void *p)
+{
+ struct line *line = p;
+ struct linereq *lr = line->req;
+ struct gpio_v2_line_event le;
+
+ /* Do not leak kernel stack to userspace */
+ memset(, 0, sizeof(le));
+
+ /*
+* We may be running from a nested threaded interrupt in which case
+* we didn't get the timestamp from edge_irq_handler().
+*/
+ if (!line->timestamp_ns) {
+ le.timestamp_ns = ktime_get_ns();
+ if (lr->num_lines != 1)
+ line->req_seqno = atomic_inc_return(>seqno);
+ } else {
+ le.timestamp_ns = line->timestamp_ns;
+ }
+
[PATCH v9 10/20] gpiolib: cdev: support GPIO_V2_LINE_SET_CONFIG_IOCTL
Add support for GPIO_V2_LINE_SET_CONFIG_IOCTL, the uAPI v2
line set config ioctl.
Signed-off-by: Kent Gibson
---
drivers/gpio/gpiolib-cdev.c | 88 +
1 file changed, 88 insertions(+)
diff --git a/drivers/gpio/gpiolib-cdev.c b/drivers/gpio/gpiolib-cdev.c
index 145bda2151fb..debd3b277523 100644
--- a/drivers/gpio/gpiolib-cdev.c
+++ b/drivers/gpio/gpiolib-cdev.c
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -444,6 +445,8 @@ struct line {
* @seqno: the sequence number for edge events generated on all lines in
* this line request. Note that this is not used when @num_lines is 1, as
* the line_seqno is then the same and is cheaper to calculate.
+ * @config_mutex: mutex for serializing ioctl() calls to ensure consistency
+ * of configuration, particularly multi-step accesses to desc flags.
* @lines: the lines held by this line request, with @num_lines elements.
*/
struct linereq {
@@ -454,6 +457,7 @@ struct linereq {
u32 event_buffer_size;
DECLARE_KFIFO_PTR(events, struct gpio_v2_line_event);
atomic_t seqno;
+ struct mutex config_mutex;
struct line lines[];
};
@@ -573,6 +577,8 @@ static void edge_detector_stop(struct line *line)
free_irq(line->irq, line);
line->irq = 0;
}
+
+ line->eflags = 0;
}
static int edge_detector_setup(struct line *line,
@@ -614,6 +620,17 @@ static int edge_detector_setup(struct line *line,
return 0;
}
+static int edge_detector_update(struct line *line, u64 eflags,
+ bool polarity_change)
+{
+ if ((line->eflags == eflags) && !polarity_change)
+ return 0;
+
+ edge_detector_stop(line);
+
+ return edge_detector_setup(line, eflags);
+}
+
static u64 gpio_v2_line_config_flags(struct gpio_v2_line_config *lc,
unsigned int line_idx)
{
@@ -796,6 +813,74 @@ static long linereq_get_values(struct linereq *lr, void
__user *ip)
return 0;
}
+static long linereq_set_config_unlocked(struct linereq *lr,
+ struct gpio_v2_line_config *lc)
+{
+ struct gpio_desc *desc;
+ unsigned int i;
+ u64 flags;
+ bool polarity_change;
+ int ret;
+
+ for (i = 0; i < lr->num_lines; i++) {
+ desc = lr->lines[i].desc;
+ flags = gpio_v2_line_config_flags(lc, i);
+ polarity_change =
+ (test_bit(FLAG_ACTIVE_LOW, >flags) !=
+((flags & GPIO_V2_LINE_FLAG_ACTIVE_LOW) != 0));
+
+ gpio_v2_line_config_flags_to_desc_flags(flags, >flags);
+ /*
+* Lines have to be requested explicitly for input
+* or output, else the line will be treated "as is".
+*/
+ if (flags & GPIO_V2_LINE_FLAG_OUTPUT) {
+ int val = gpio_v2_line_config_output_value(lc, i);
+
+ edge_detector_stop(>lines[i]);
+ ret = gpiod_direction_output(desc, val);
+ if (ret)
+ return ret;
+ } else if (flags & GPIO_V2_LINE_FLAG_INPUT) {
+ ret = gpiod_direction_input(desc);
+ if (ret)
+ return ret;
+
+ ret = edge_detector_update(>lines[i],
+ flags & GPIO_V2_LINE_EDGE_FLAGS,
+ polarity_change);
+ if (ret)
+ return ret;
+ }
+
+ blocking_notifier_call_chain(>gdev->notifier,
+GPIO_V2_LINE_CHANGED_CONFIG,
+desc);
+ }
+ return 0;
+}
+
+static long linereq_set_config(struct linereq *lr, void __user *ip)
+{
+ struct gpio_v2_line_config lc;
+ int ret;
+
+ if (copy_from_user(, ip, sizeof(lc)))
+ return -EFAULT;
+
+ ret = gpio_v2_line_config_validate(, lr->num_lines);
+ if (ret)
+ return ret;
+
+ mutex_lock(>config_mutex);
+
+ ret = linereq_set_config_unlocked(lr, );
+
+ mutex_unlock(>config_mutex);
+
+ return ret;
+}
+
static long linereq_ioctl(struct file *file, unsigned int cmd,
unsigned long arg)
{
@@ -804,6 +889,8 @@ static long linereq_ioctl(struct file *file, unsigned int
cmd,
if (cmd == GPIO_V2_LINE_GET_VALUES_IOCTL)
return linereq_get_values(lr, ip);
+ else if (cmd == GPIO_V2_LINE_SET_CONFIG_IOCTL)
+ return linereq_set_config(lr, ip);
return -EINVAL;
}
@@ -964,6 +1051,7 @@ static int linereq_create(struct gpio_device *gdev, void
__user *ip)
}
}
+
