[PATCH v3 13/14] bfq: remove unnecessary initialization logic

[brookxu]

From: Chunguang Xu 

Since we will initialize sched_data.service_tree[] in
bfq_init_root_group(), bfq_create_group_hierarchy() can
ignore this part of the initialization, which can avoid
repeated initialization.

Signed-off-by: Chunguang Xu 
---
 block/bfq-cgroup.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/block/bfq-cgroup.c b/block/bfq-cgroup.c
index ab4bc41..05054e1 100644
--- a/block/bfq-cgroup.c
+++ b/block/bfq-cgroup.c
@@ -1514,15 +1514,11 @@ void bfqg_and_blkg_put(struct bfq_group *bfqg) {}
 struct bfq_group *bfq_create_group_hierarchy(struct bfq_data *bfqd, int node)
 {
struct bfq_group *bfqg;
-   int i;
 
bfqg = kmalloc_node(sizeof(*bfqg), GFP_KERNEL | __GFP_ZERO, node);
if (!bfqg)
return NULL;
 
-   for (i = 0; i < BFQ_IOPRIO_CLASSES; i++)
-   bfqg->sched_data.service_tree[i] = BFQ_SERVICE_TREE_INIT;
-
return bfqg;
 }
 #endif /* CONFIG_BFQ_GROUP_IOSCHED */
-- 
1.8.3.1

[PATCH v3 14/14] bfq: optimize the calculation of bfq_weight_to_ioprio()

[brookxu]

From: Chunguang Xu 

The value range of ioprio is [0, 7], but the result of
bfq_weight_to_ioprio() may exceed this range, so simple
optimization is required.

Signed-off-by: Chunguang Xu 
---
 block/bfq-wf2q.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/block/bfq-wf2q.c b/block/bfq-wf2q.c
index b477a9b..1b91c8b 100644
--- a/block/bfq-wf2q.c
+++ b/block/bfq-wf2q.c
@@ -586,8 +586,9 @@ unsigned short bfq_ioprio_to_weight(int ioprio)
  */
 static unsigned short bfq_weight_to_ioprio(int weight)
 {
-   return max_t(int, 0,
-IOPRIO_BE_NR * BFQ_WEIGHT_CONVERSION_COEFF - weight);
+   int ioprio = IOPRIO_BE_NR  - weight / BFQ_WEIGHT_CONVERSION_COEFF;
+
+   return ioprio < 0 ? 0 : min_t(int, ioprio, IOPRIO_BE_NR - 1);
 }
 
 static void bfq_get_entity(struct bfq_entity *entity)
-- 
1.8.3.1

[PATCH v3 12/14] bfq: disable merging between different groups under better_fairness

[brookxu]

From: Chunguang Xu 

In order to better guarantee the Qos for each group, we do not
allow queues of different groups to be merged.

Signed-off-by: Chunguang Xu 
---
 block/bfq-iosched.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c
index 5aa9c2c..f4a99f9 100644
--- a/block/bfq-iosched.c
+++ b/block/bfq-iosched.c
@@ -2665,6 +2665,9 @@ static bool bfq_may_be_close_cooperator(struct bfq_queue 
*bfqq,
if (!bfq_bfqq_sync(bfqq) || !bfq_bfqq_sync(new_bfqq))
return false;
 
+   if (!bfq_bfqq_may_inject(bfqq, new_bfqq))
+   return false;
+
return true;
 }
 
-- 
1.8.3.1

[PATCH v3 11/14] bfq: disable idle for prio_expire under better_fairness

[brookxu]

From: Chunguang Xu 

Under better_fairness, if higher priority queue is waiting
for service，disable queue idle, so that a schedule can be
invoked in time. In addition to CLASS_IDLE, other queues
allow idle, so that we can better control buffer IO too.

Signed-off-by: Chunguang Xu 
---
 block/bfq-iosched.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c
index be5b1e3..5aa9c2c 100644
--- a/block/bfq-iosched.c
+++ b/block/bfq-iosched.c
@@ -4307,6 +4307,14 @@ static bool bfq_better_to_idle(struct bfq_queue *bfqq)
return true;
 
/*
+* In better_fairness mode, we also put emphasis on Qos. The main
+* purpose of allowing idle here is to ensure better isolation
+* of Buffer IO.
+*/
+   if (unlikely(bfqd->better_fairness))
+   return !(bfqd->bfq_slice_idle == 0 || bfq_class_idle(bfqq));
+
+   /*
 * Idling is performed only if slice_idle > 0. In addition, we
 * do not idle if
 * (a) bfqq is async
@@ -4318,6 +4326,9 @@ static bool bfq_better_to_idle(struct bfq_queue *bfqq)
   bfq_class_idle(bfqq))
return false;
 
+   if (bfq_may_expire_in_serv_for_prio(&bfqq->entity))
+   return false;
+
idling_boosts_thr_with_no_issue =
idling_boosts_thr_without_issues(bfqd, bfqq);
 
-- 
1.8.3.1

[PATCH v3 10/14] bfq: optimize IO injection under better_fairness

[brookxu]

From: Chunguang Xu 

In order to ensure better Qos of tasks of different groups
and different classes under better_fairness, we only allow
the queues of the same class in the same group can be
injected.

Signed-off-by: Chunguang Xu 
---
 block/bfq-iosched.c | 28 +++-
 1 file changed, 27 insertions(+), 1 deletion(-)

diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c
index 51192bd..be5b1e3 100644
--- a/block/bfq-iosched.c
+++ b/block/bfq-iosched.c
@@ -1900,6 +1900,27 @@ static void bfq_reset_inject_limit(struct bfq_data *bfqd,
bfqq->decrease_time_jif = jiffies;
 }
 
+static bool bfq_bfqq_may_inject(struct bfq_queue *bfqq, struct bfq_queue 
*new_bfqq)
+{
+   struct bfq_data *bfqd = bfqq->bfqd;
+   bool ret = true;
+
+   if (unlikely(bfqd->better_fairness)) {
+   /*
+* In addition to throughput, better_fairness also pays
+* attention to Qos. In the container scenario, in order
+* to ensure the Qos of each group we only allow tasks
+* of the same class in the same group to be injected.
+*/
+   if (bfq_class(bfqq) != bfq_class(new_bfqq))
+   ret = false;
+
+   if (bfqq_group(bfqq) != bfqq_group(new_bfqq))
+   ret = false;
+   }
+   return ret;
+}
+
 static void bfq_update_io_intensity(struct bfq_queue *bfqq, u64 now_ns)
 {
u64 tot_io_time = now_ns - bfqq->io_start_time;
@@ -1985,7 +2006,8 @@ static void bfq_check_waker(struct bfq_data *bfqd, struct 
bfq_queue *bfqq,
bfqd->last_completed_rq_bfqq == bfqq ||
bfq_bfqq_has_short_ttime(bfqq) ||
now_ns - bfqd->last_completion >= 4 * NSEC_PER_MSEC ||
-   bfqd->last_completed_rq_bfqq == bfqq->waker_bfqq)
+   bfqd->last_completed_rq_bfqq == bfqq->waker_bfqq ||
+   !bfq_bfqq_may_inject(bfqq, bfqd->last_completed_rq_bfqq))
return;
 
if (bfqd->last_completed_rq_bfqq !=
@@ -4415,6 +4437,9 @@ static bool bfq_bfqq_must_idle(struct bfq_queue *bfqq)
else
limit = in_serv_bfqq->inject_limit;
 
+   if (!bfq_bfqq_may_inject(in_serv_bfqq, bfqq))
+   continue;
+
if (bfqd->rq_in_driver < limit) {
bfqd->rqs_injected = true;
return bfqq;
@@ -4590,6 +4615,7 @@ static struct bfq_queue *bfq_select_queue(struct bfq_data 
*bfqd)
 * happen to be served only after other queues.
 */
if (async_bfqq &&
+   !(bfqd->better_fairness && !bfq_class_idx(&bfqq->entity)) &&
icq_to_bic(async_bfqq->next_rq->elv.icq) == bfqq->bic &&
bfq_serv_to_charge(async_bfqq->next_rq, async_bfqq) <=
bfq_bfqq_budget_left(async_bfqq))
-- 
1.8.3.1

[PATCH v3 09/14] bfq: expire in_serv_queue for prio_expire under better_fairness

[brookxu]

From: Chunguang Xu 

Traverse all schedule domains upward, if there are higher
priority tasks waiting for service, mark in_service_queue
prio_expire and then expire it, so the So RT tasks can be
scheduled in time.

Signed-off-by: Chunguang Xu 
---
 block/bfq-iosched.c |  7 +++
 block/bfq-iosched.h |  1 +
 block/bfq-wf2q.c| 60 +
 3 files changed, 64 insertions(+), 4 deletions(-)

diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c
index 6e19b5a..51192bd 100644
--- a/block/bfq-iosched.c
+++ b/block/bfq-iosched.c
@@ -4736,10 +4736,9 @@ static struct request *bfq_dispatch_rq_from_bfqq(struct 
bfq_data *bfqd,
 * belongs to CLASS_IDLE and other queues are waiting for
 * service.
 */
-   if (!(bfq_tot_busy_queues(bfqd) > 1 && bfq_class_idle(bfqq)))
-   goto return_rq;
-
-   bfq_bfqq_expire(bfqd, bfqq, false, BFQQE_BUDGET_EXHAUSTED);
+   if ((bfq_tot_busy_queues(bfqd) > 1 && bfq_class_idle(bfqq)) ||
+   bfq_bfqq_prio_expire(bfqq))
+   bfq_bfqq_expire(bfqd, bfqq, false, BFQQE_BUDGET_EXHAUSTED);
 
 return_rq:
return rq;
diff --git a/block/bfq-iosched.h b/block/bfq-iosched.h
index 8af5ac0..1406398 100644
--- a/block/bfq-iosched.h
+++ b/block/bfq-iosched.h
@@ -989,6 +989,7 @@ void bfq_bfqq_expire(struct bfq_data *bfqd, struct 
bfq_queue *bfqq,
 void bfq_release_process_ref(struct bfq_data *bfqd, struct bfq_queue *bfqq);
 void bfq_schedule_dispatch(struct bfq_data *bfqd);
 void bfq_put_async_queues(struct bfq_data *bfqd, struct bfq_group *bfqg);
+bool bfq_may_expire_in_serv_for_prio(struct bfq_entity *entity);
 
 /*  end of main algorithm interface -- */
 
diff --git a/block/bfq-wf2q.c b/block/bfq-wf2q.c
index 1f8f3c5..b477a9b 100644
--- a/block/bfq-wf2q.c
+++ b/block/bfq-wf2q.c
@@ -161,6 +161,51 @@ struct bfq_group *bfq_bfqq_to_bfqg(struct bfq_queue *bfqq)
return bfq_entity_to_bfqg(group_entity);
 }
 
+bool bfq_may_expire_in_serv_for_prio(struct bfq_entity *entity)
+{
+   struct bfq_sched_data *sd;
+   struct bfq_queue *bfqq;
+   struct bfq_group *bfqg;
+   bool ret = false;
+
+   sd = entity->sched_data;
+   bfqg = container_of(sd, struct bfq_group, sched_data);
+
+   if (likely(!bfqg->bfqd->better_fairness))
+   return false;
+
+   bfqq = bfqg->bfqd->in_service_queue;
+   if (bfqq) {
+   struct bfq_entity *next_in_serv;
+
+   /*
+* Traverse the upper-level scheduling domain for
+* prio preemption, and expire in_service_queue
+* if necessary.
+*/
+   entity = &bfqq->entity;
+   for_each_entity(entity) {
+   sd = entity->sched_data;
+   next_in_serv = sd->next_in_service;
+
+   if (!next_in_serv)
+   continue;
+
+   /*
+* Expire bfqq, if next_in_serv belongs to
+* a higher class.
+*/
+   if (bfq_class_idx(next_in_serv) <
+   bfq_class_idx(entity)) {
+   bfq_mark_bfqq_prio_expire(bfqq);
+   ret = true;
+   break;
+   }
+   }
+   }
+   return ret;
+}
+
 /*
  * Returns true if this budget changes may let next_in_service->parent
  * become the next_in_service entity for its parent entity.
@@ -244,6 +289,11 @@ struct bfq_group *bfq_bfqq_to_bfqg(struct bfq_queue *bfqq)
return bfqq->bfqd->root_group;
 }
 
+bool bfq_may_expire_in_serv_for_prio(struct bfq_entity *entity)
+{
+   return false;
+}
+
 static bool bfq_update_parent_budget(struct bfq_entity *next_in_service)
 {
return false;
@@ -1162,6 +1212,7 @@ static void bfq_activate_requeue_entity(struct bfq_entity 
*entity,
bool non_blocking_wait_rq,
bool requeue, bool expiration)
 {
+   struct bfq_entity *old_entity = entity;
struct bfq_sched_data *sd;
 
for_each_entity(entity) {
@@ -1172,6 +1223,15 @@ static void bfq_activate_requeue_entity(struct 
bfq_entity *entity,
!requeue)
break;
}
+
+   /*
+* Expire in_service_queue, if a task belongs to higher class
+* is added to the upper-level scheduling domain, we should
+* initiate a new schedule. But here is just to mark bfqq
+* prio_expire, the real schedule occurs in
+* bfq_dispatch_rq_from_bfqq().
+*/
+   bfq_may_expire_in_serv_for_prio(old_entity);
 }
 
 /**
-- 
1.8.3.1

[PATCH v3 08/14] bfq: introduce prio_expire flag for bfq_queue

[brookxu]

From: Chunguang Xu 

When in_service_queue needs to be preempted by task with
a higher priority, we will mark it with prio_expire flag,
and then expire it on the IO dispatch path. Here add
prio_expire flag only.

Signed-off-by: Chunguang Xu 
---
 block/bfq-iosched.c | 2 ++
 block/bfq-iosched.h | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c
index e7bc5e2..6e19b5a 100644
--- a/block/bfq-iosched.c
+++ b/block/bfq-iosched.c
@@ -153,6 +153,7 @@
 BFQ_BFQQ_FNS(wait_request);
 BFQ_BFQQ_FNS(non_blocking_wait_rq);
 BFQ_BFQQ_FNS(fifo_expire);
+BFQ_BFQQ_FNS(prio_expire);
 BFQ_BFQQ_FNS(has_short_ttime);
 BFQ_BFQQ_FNS(sync);
 BFQ_BFQQ_FNS(IO_bound);
@@ -2986,6 +2987,7 @@ static void __bfq_set_in_service_queue(struct bfq_data 
*bfqd,
 {
if (bfqq) {
bfq_clear_bfqq_fifo_expire(bfqq);
+   bfq_clear_bfqq_prio_expire(bfqq);
 
bfqd->budgets_assigned = (bfqd->budgets_assigned * 7 + 256) / 8;
 
diff --git a/block/bfq-iosched.h b/block/bfq-iosched.h
index 674de8b..8af5ac0 100644
--- a/block/bfq-iosched.h
+++ b/block/bfq-iosched.h
@@ -777,6 +777,7 @@ enum bfqq_state_flags {
 * without idling the device
 */
BFQQF_fifo_expire,  /* FIFO checked in this slice */
+   BFQQF_prio_expire,  /* should expire for higher prio queue*/
BFQQF_has_short_ttime,  /* queue has a short think time */
BFQQF_sync, /* synchronous queue */
BFQQF_IO_bound, /*
@@ -806,6 +807,7 @@ enum bfqq_state_flags {
 BFQ_BFQQ_FNS(wait_request);
 BFQ_BFQQ_FNS(non_blocking_wait_rq);
 BFQ_BFQQ_FNS(fifo_expire);
+BFQ_BFQQ_FNS(prio_expire);
 BFQ_BFQQ_FNS(has_short_ttime);
 BFQ_BFQQ_FNS(sync);
 BFQ_BFQQ_FNS(IO_bound);
-- 
1.8.3.1

[PATCH v3 05/14] bfq: limit the IO depth of CLASS_IDLE to 1

[brookxu]

From: Chunguang Xu 

The IO depth of queues belong to CLASS_IDLE is limited to 1,
so that it can avoid introducing a larger tail latency under
a device with a larger IO depth. Although limiting the IO
depth may reduce the performance of idle_class, it is
generally not a big problem, because idle_class usually does
not have strict performance requirements.

Signed-off-by: Chunguang Xu 
---
 block/bfq-iosched.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c
index 5f7a0cc..8eaf0eb 100644
--- a/block/bfq-iosched.c
+++ b/block/bfq-iosched.c
@@ -4831,6 +4831,17 @@ static struct request *__bfq_dispatch_request(struct 
blk_mq_hw_ctx *hctx)
if (!bfqq)
goto exit;
 
+   /*
+* Here, the IO depth of queues belong to CLASS_IDLE is limited
+* to 1, so that it can avoid introducing a larger tail latency
+* under a device with a larger IO depth. Although limiting the
+* IO depth may reduce the performance of idle_class, it is
+* generally not a big problem, because idle_class usually
+* does not have strict performance requirements.
+*/
+   if (bfq_class_idle(bfqq) && bfqq->dispatched)
+   goto exit;
+
rq = bfq_dispatch_rq_from_bfqq(bfqd, bfqq);
 
if (rq) {
-- 
1.8.3.1

[PATCH v3 06/14] bfq: keep the minimun bandwidth for CLASS_BE

[brookxu]

From: Chunguang Xu 

CLASS_RT will preempt other classes, which may starve. At
present, CLASS_IDLE has alleviated the starvation problem
through the minimum bandwidth mechanism. Similarly, we
should do the same for CLASS_BE.

Signed-off-by: Chunguang Xu 
---
 block/bfq-iosched.c |  6 --
 block/bfq-iosched.h | 11 ++
 block/bfq-wf2q.c| 59 ++---
 3 files changed, 53 insertions(+), 23 deletions(-)

diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c
index 8eaf0eb..ee8c457 100644
--- a/block/bfq-iosched.c
+++ b/block/bfq-iosched.c
@@ -6560,9 +6560,11 @@ static void bfq_init_root_group(struct bfq_group 
*root_group,
root_group->bfqd = bfqd;
 #endif
root_group->rq_pos_tree = RB_ROOT;
-   for (i = 0; i < BFQ_IOPRIO_CLASSES; i++)
+   for (i = 0; i < BFQ_IOPRIO_CLASSES; i++) {
root_group->sched_data.service_tree[i] = BFQ_SERVICE_TREE_INIT;
-   root_group->sched_data.bfq_class_idle_last_service = jiffies;
+   root_group->sched_data.bfq_class_last_service[i] = jiffies;
+   }
+   root_group->sched_data.class_timeout_last_check = jiffies;
 }
 
 static int bfq_init_queue(struct request_queue *q, struct elevator_type *e)
diff --git a/block/bfq-iosched.h b/block/bfq-iosched.h
index 29a56b8..f9ed1da 100644
--- a/block/bfq-iosched.h
+++ b/block/bfq-iosched.h
@@ -13,7 +13,7 @@
 #include "blk-cgroup-rwstat.h"
 
 #define BFQ_IOPRIO_CLASSES 3
-#define BFQ_CL_IDLE_TIMEOUT(HZ/5)
+#define BFQ_CLASS_TIMEOUT  (HZ/5)
 
 #define BFQ_MIN_WEIGHT 1
 #define BFQ_MAX_WEIGHT 1000
@@ -97,9 +97,12 @@ struct bfq_sched_data {
struct bfq_entity *next_in_service;
/* array of service trees, one per ioprio_class */
struct bfq_service_tree service_tree[BFQ_IOPRIO_CLASSES];
-   /* last time CLASS_IDLE was served */
-   unsigned long bfq_class_idle_last_service;
-
+   /* last time the class was served */
+   unsigned long bfq_class_last_service[BFQ_IOPRIO_CLASSES];
+   /* last time class timeout was checked */
+   unsigned long class_timeout_last_check;
+   /* next index to check class timeout */
+   unsigned int next_class_index;
 };
 
 /**
diff --git a/block/bfq-wf2q.c b/block/bfq-wf2q.c
index c91109e..1f8f3c5 100644
--- a/block/bfq-wf2q.c
+++ b/block/bfq-wf2q.c
@@ -1188,6 +1188,7 @@ bool __bfq_deactivate_entity(struct bfq_entity *entity, 
bool ins_into_idle_tree)
 {
struct bfq_sched_data *sd = entity->sched_data;
struct bfq_service_tree *st;
+   int idx = bfq_class_idx(entity);
bool is_in_service;
 
if (!entity->on_st_or_in_serv) /*
@@ -1227,6 +1228,7 @@ bool __bfq_deactivate_entity(struct bfq_entity *entity, 
bool ins_into_idle_tree)
else
bfq_idle_insert(st, entity);
 
+   sd->bfq_class_last_service[idx] = jiffies;
return true;
 }
 
@@ -1455,6 +1457,45 @@ static struct bfq_entity *bfq_first_active_entity(struct 
bfq_service_tree *st,
return entity;
 }
 
+static int bfq_select_next_class(struct bfq_sched_data *sd)
+{
+   struct bfq_service_tree *st = sd->service_tree;
+   unsigned long last_check, last_serve;
+   int i, class_idx, next_class = 0;
+   bool found = false;
+
+   /*
+* we needed to guarantee a minimum bandwidth for each class (if
+* there is some active entity in this class). This should also
+* mitigate priority-inversion problems in case a low priority
+* task is holding file system resources.
+*/
+   last_check = sd->class_timeout_last_check;
+   if (time_is_after_jiffies(last_check + BFQ_CLASS_TIMEOUT))
+   return next_class;
+
+   sd->class_timeout_last_check = jiffies;
+   for (i = 0; i < BFQ_IOPRIO_CLASSES; i++) {
+   class_idx = (sd->next_class_index + i) % BFQ_IOPRIO_CLASSES;
+   last_serve = sd->bfq_class_last_service[class_idx];
+
+   if (time_is_after_jiffies(last_serve + BFQ_CLASS_TIMEOUT))
+   continue;
+
+   if (!RB_EMPTY_ROOT(&(st + class_idx)->active)) {
+   if (found)
+   continue;
+
+   next_class = class_idx++;
+   class_idx %= BFQ_IOPRIO_CLASSES;
+   sd->next_class_index = class_idx;
+   found = true;
+   }
+   sd->bfq_class_last_service[class_idx] = jiffies;
+   }
+   return next_class;
+}
+
 /**
  * bfq_lookup_next_entity - return the first eligible entity in @sd.
  * @sd: the sched_data.
@@ -1468,24 +1509,8 @@ static struct bfq_entity *bfq_lookup_next_entity(struct 
bfq_sched_data *sd,
 bool expiration)
 {
struct bfq_service_tree *st = sd->service_tree;
-   struct bfq_service_tree *idle_class_st = st + (BFQ_IOPRIO_CLASSES - 1);
str

[PATCH v3 07/14] bfq: introduce better_fairness for container scene

[brookxu]

From: Chunguang Xu 

In the container scenario, in addition to throughput, we
also pay attention to Qos. In order to better support this
scenario, we introduce the better_fairness mode here. In
this mode, we expect to control the Qos of each group
according to its priority better. Only add configuration
interface here

Signed-off-by: Chunguang Xu 
---
 block/bfq-iosched.c | 22 ++
 block/bfq-iosched.h | 10 ++
 2 files changed, 32 insertions(+)

diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c
index ee8c457..e7bc5e2 100644
--- a/block/bfq-iosched.c
+++ b/block/bfq-iosched.c
@@ -6745,6 +6745,7 @@ static ssize_t __FUNC(struct elevator_queue *e, char 
*page)   \
 SHOW_FUNCTION(bfq_max_budget_show, bfqd->bfq_user_max_budget, 0);
 SHOW_FUNCTION(bfq_timeout_sync_show, bfqd->bfq_timeout, 1);
 SHOW_FUNCTION(bfq_strict_guarantees_show, bfqd->strict_guarantees, 0);
+SHOW_FUNCTION(bfq_better_fairness_show, bfqd->better_fairness, 0);
 SHOW_FUNCTION(bfq_low_latency_show, bfqd->low_latency, 0);
 #undef SHOW_FUNCTION
 
@@ -6886,6 +6887,26 @@ static ssize_t bfq_strict_guarantees_store(struct 
elevator_queue *e,
return count;
 }
 
+static ssize_t bfq_better_fairness_store(struct elevator_queue *e,
+const char *page, size_t count)
+{
+   struct bfq_data *bfqd = e->elevator_data;
+   unsigned long __data;
+   int ret;
+
+   ret = bfq_var_store(&__data, (page));
+   if (ret)
+   return ret;
+
+   if (__data > 1)
+   __data = 1;
+   if (__data == 0 && bfqd->better_fairness != 0)
+   bfq_end_wr(bfqd);
+   bfqd->better_fairness = __data;
+
+   return count;
+}
+
 static ssize_t bfq_low_latency_store(struct elevator_queue *e,
 const char *page, size_t count)
 {
@@ -6919,6 +6940,7 @@ static ssize_t bfq_low_latency_store(struct 
elevator_queue *e,
BFQ_ATTR(max_budget),
BFQ_ATTR(timeout_sync),
BFQ_ATTR(strict_guarantees),
+   BFQ_ATTR(better_fairness),
BFQ_ATTR(low_latency),
__ATTR_NULL
 };
diff --git a/block/bfq-iosched.h b/block/bfq-iosched.h
index f9ed1da..674de8b 100644
--- a/block/bfq-iosched.h
+++ b/block/bfq-iosched.h
@@ -672,6 +672,16 @@ struct bfq_data {
bool strict_guarantees;
 
/*
+* If there is no prio preemption, we force the device to
+* idle to ensure Qos. IO inject also has some additional
+* restrictions. The inject/merge queue should come from the
+* same class in the same group. Doing so will reduce the
+* throughput of the system, but it can better guarantee
+* the Qos of each group and real-time tasks.
+*/
+   bool better_fairness;
+
+   /*
 * Last time at which a queue entered the current burst of
 * queues being activated shortly after each other; for more
 * details about this and the following parameters related to
-- 
1.8.3.1

[PATCH v3 02/14] bfq: convert the type of bfq_group.bfqd to bfq_data*

[brookxu]

From: Chunguang Xu 

Setting bfq_group.bfqd to void* type does not seem to make much sense.
This will cause unnecessary type conversion. Perhaps it would be better
to change it to bfq_data* type.

Signed-off-by: Chunguang Xu 
---
 block/bfq-cgroup.c  | 2 +-
 block/bfq-iosched.h | 2 +-
 block/bfq-wf2q.c| 6 +++---
 3 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/block/bfq-cgroup.c b/block/bfq-cgroup.c
index a5f544a..50d06c7 100644
--- a/block/bfq-cgroup.c
+++ b/block/bfq-cgroup.c
@@ -224,7 +224,7 @@ void bfqg_stats_update_io_add(struct bfq_group *bfqg, 
struct bfq_queue *bfqq,
 {
blkg_rwstat_add(&bfqg->stats.queued, op, 1);
bfqg_stats_end_empty_time(&bfqg->stats);
-   if (!(bfqq == ((struct bfq_data *)bfqg->bfqd)->in_service_queue))
+   if (!(bfqq == bfqg->bfqd->in_service_queue))
bfqg_stats_set_start_group_wait_time(bfqg, bfqq_group(bfqq));
 }
 
diff --git a/block/bfq-iosched.h b/block/bfq-iosched.h
index a6f98e9..28d8590 100644
--- a/block/bfq-iosched.h
+++ b/block/bfq-iosched.h
@@ -914,7 +914,7 @@ struct bfq_group {
struct bfq_entity entity;
struct bfq_sched_data sched_data;
 
-   void *bfqd;
+   struct bfq_data *bfqd;
 
struct bfq_queue *async_bfqq[2][IOPRIO_BE_NR];
struct bfq_queue *async_idle_bfqq;
diff --git a/block/bfq-wf2q.c b/block/bfq-wf2q.c
index 5ff0028..276f225 100644
--- a/block/bfq-wf2q.c
+++ b/block/bfq-wf2q.c
@@ -498,7 +498,7 @@ static void bfq_active_insert(struct bfq_service_tree *st,
 #ifdef CONFIG_BFQ_GROUP_IOSCHED
sd = entity->sched_data;
bfqg = container_of(sd, struct bfq_group, sched_data);
-   bfqd = (struct bfq_data *)bfqg->bfqd;
+   bfqd = bfqg->bfqd;
 #endif
if (bfqq)
list_add(&bfqq->bfqq_list, &bfqq->bfqd->active_list);
@@ -597,7 +597,7 @@ static void bfq_active_extract(struct bfq_service_tree *st,
 #ifdef CONFIG_BFQ_GROUP_IOSCHED
sd = entity->sched_data;
bfqg = container_of(sd, struct bfq_group, sched_data);
-   bfqd = (struct bfq_data *)bfqg->bfqd;
+   bfqd = bfqg->bfqd;
 #endif
if (bfqq)
list_del(&bfqq->bfqq_list);
@@ -743,7 +743,7 @@ struct bfq_service_tree *
else {
sd = entity->my_sched_data;
bfqg = container_of(sd, struct bfq_group, sched_data);
-   bfqd = (struct bfq_data *)bfqg->bfqd;
+   bfqd = bfqg->bfqd;
}
 #endif
 
-- 
1.8.3.1

[PATCH v3 04/14] bfq: introduce bfq_ioprio_class to get ioprio class

[brookxu]

From: Chunguang Xu 

Since the tasks inside the container itself have different
ioprio, in order to be compatible with the actual production
environment, when scheduling within a group, we use the task
ioprio class, but outside the group, we use the group ioprio
class. For example, when counting busy_queues, tasks from
the CLASS_IDLE group, regardless of their ioprio, are always
treated as CLASS_IDLE tasks.

Signed-off-by: Chunguang Xu 
---
 block/bfq-iosched.c | 29 ++---
 block/bfq-iosched.h |  1 +
 block/bfq-wf2q.c|  4 ++--
 3 files changed, 29 insertions(+), 5 deletions(-)

diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c
index ec482e6..5f7a0cc 100644
--- a/block/bfq-iosched.c
+++ b/block/bfq-iosched.c
@@ -428,7 +428,30 @@ void bfq_schedule_dispatch(struct bfq_data *bfqd)
}
 }
 
-#define bfq_class_idle(bfqq)   ((bfqq)->ioprio_class == IOPRIO_CLASS_IDLE)
+unsigned short bfq_ioprio_class(struct bfq_entity *entity)
+{
+   struct bfq_queue *bfqq = bfq_entity_to_bfqq(entity);
+   unsigned short class = BFQ_DEFAULT_GRP_CLASS;
+#ifdef CONFIG_BFQ_GROUP_IOSCHED
+   struct bfq_group *bfqg;
+
+   if (bfqq) {
+   bfqg = bfqq_group(bfqq);
+   class = bfqg->ioprio_class?:bfqq->ioprio_class;
+   } else {
+   bfqg = bfq_entity_to_bfqg(entity);
+   class = bfqg->ioprio_class?:BFQ_DEFAULT_GRP_CLASS;
+   }
+#else
+   if (bfqq)
+   class = bfqq->ioprio_class;
+#endif
+   return class;
+}
+
+#define bfq_class(bfq) (bfq_ioprio_class(&bfq->entity))
+#define bfq_class_rt(bfq)  (bfq_ioprio_class(&bfq->entity) == 
IOPRIO_CLASS_RT)
+#define bfq_class_idle(bfq)(bfq_ioprio_class(&bfq->entity) == 
IOPRIO_CLASS_IDLE)
 
 #define bfq_sample_valid(samples)  ((samples) > 80)
 
@@ -1635,7 +1658,7 @@ static bool bfq_bfqq_higher_class_or_weight(struct 
bfq_queue *bfqq,
 {
int bfqq_weight, in_serv_weight;
 
-   if (bfqq->ioprio_class < in_serv_bfqq->ioprio_class)
+   if (bfq_class(bfqq) < bfq_class(in_serv_bfqq))
return true;
 
if (in_serv_bfqq->entity.parent == bfqq->entity.parent) {
@@ -2600,7 +2623,7 @@ static bool bfq_may_be_close_cooperator(struct bfq_queue 
*bfqq,
return false;
 
if (bfq_class_idle(bfqq) || bfq_class_idle(new_bfqq) ||
-   (bfqq->ioprio_class != new_bfqq->ioprio_class))
+   (bfq_class(bfqq) != bfq_class(new_bfqq)))
return false;
 
/*
diff --git a/block/bfq-iosched.h b/block/bfq-iosched.h
index 3416a75..29a56b8 100644
--- a/block/bfq-iosched.h
+++ b/block/bfq-iosched.h
@@ -1071,6 +1071,7 @@ void bfq_requeue_bfqq(struct bfq_data *bfqd, struct 
bfq_queue *bfqq,
 void bfq_del_bfqq_busy(struct bfq_data *bfqd, struct bfq_queue *bfqq,
   bool expiration);
 void bfq_add_bfqq_busy(struct bfq_data *bfqd, struct bfq_queue *bfqq);
+unsigned short bfq_ioprio_class(struct bfq_entity *entity);
 
 /* --- end of interface of B-WF2Q+  */
 
diff --git a/block/bfq-wf2q.c b/block/bfq-wf2q.c
index 7405be9..c91109e 100644
--- a/block/bfq-wf2q.c
+++ b/block/bfq-wf2q.c
@@ -1702,7 +1702,7 @@ void bfq_del_bfqq_busy(struct bfq_data *bfqd, struct 
bfq_queue *bfqq,
 
bfq_clear_bfqq_busy(bfqq);
 
-   bfqd->busy_queues[bfqq->ioprio_class - 1]--;
+   bfqd->busy_queues[bfq_ioprio_class(&bfqq->entity) - 1]--;
 
if (bfqq->wr_coeff > 1)
bfqd->wr_busy_queues--;
@@ -1725,7 +1725,7 @@ void bfq_add_bfqq_busy(struct bfq_data *bfqd, struct 
bfq_queue *bfqq)
bfq_activate_bfqq(bfqd, bfqq);
 
bfq_mark_bfqq_busy(bfqq);
-   bfqd->busy_queues[bfqq->ioprio_class - 1]++;
+   bfqd->busy_queues[bfq_ioprio_class(&bfqq->entity) - 1]++;
 
if (!bfqq->dispatched)
if (bfqq->wr_coeff == 1)
-- 
1.8.3.1

[PATCH v3 03/14] bfq: introduce bfq.ioprio for cgroup

[brookxu]

From: Chunguang Xu 

Now the ioprio class of all groups is CLASS_BE, which is not very
friendly to the container scene. Therefore, we introduce the bfq.ioprio
interface to allow users to configure the ioprio class and ioprio of
the group, which can meet more priority requirements.

The bfq.ioprio interface now is available for cgroup v1 and cgroup
v2. Users can configure the ioprio for cgroup through this interface,
as shown below:

echo "1 2"> blkio.bfq.ioprio

The above two values respectively represent the values of ioprio
class and ioprio for cgroup. When necessary, we can disable this
feature by:

echo "0 0" > bfq.ioprio.

Signed-off-by: Chunguang Xu 
---
 block/bfq-cgroup.c  | 87 -
 block/bfq-iosched.h |  8 +
 block/bfq-wf2q.c| 30 +++---
 3 files changed, 119 insertions(+), 6 deletions(-)

diff --git a/block/bfq-cgroup.c b/block/bfq-cgroup.c
index 50d06c7..ab4bc41 100644
--- a/block/bfq-cgroup.c
+++ b/block/bfq-cgroup.c
@@ -489,7 +489,7 @@ static struct bfq_group_data *cpd_to_bfqgd(struct 
blkcg_policy_data *cpd)
return cpd ? container_of(cpd, struct bfq_group_data, pd) : NULL;
 }
 
-static struct bfq_group_data *blkcg_to_bfqgd(struct blkcg *blkcg)
+struct bfq_group_data *blkcg_to_bfqgd(struct blkcg *blkcg)
 {
return cpd_to_bfqgd(blkcg_to_cpd(blkcg, &blkcg_policy_bfq));
 }
@@ -553,6 +553,16 @@ static void bfq_pd_init(struct blkg_policy_data *pd)
bfqg->bfqd = bfqd;
bfqg->active_entities = 0;
bfqg->rq_pos_tree = RB_ROOT;
+
+   bfqg->new_ioprio_class = IOPRIO_PRIO_CLASS(d->ioprio);
+   bfqg->new_ioprio = IOPRIO_PRIO_DATA(d->ioprio);
+   bfqg->ioprio_class = bfqg->new_ioprio_class;
+   bfqg->ioprio = bfqg->new_ioprio;
+
+   if (d->ioprio) {
+   entity->new_weight = bfq_ioprio_to_weight(bfqg->ioprio);
+   entity->weight = entity->new_weight;
+   }
 }
 
 static void bfq_pd_free(struct blkg_policy_data *pd)
@@ -981,6 +991,20 @@ static int bfq_io_show_weight(struct seq_file *sf, void *v)
return 0;
 }
 
+static int bfq_io_show_ioprio(struct seq_file *sf, void *v)
+{
+   struct blkcg *blkcg = css_to_blkcg(seq_css(sf));
+   struct bfq_group_data *bfqgd = blkcg_to_bfqgd(blkcg);
+   unsigned int val = 0;
+
+   if (bfqgd)
+   val = bfqgd->ioprio;
+
+   seq_printf(sf, "%u %lu\n", IOPRIO_PRIO_CLASS(val), 
IOPRIO_PRIO_DATA(val));
+
+   return 0;
+}
+
 static void bfq_group_set_weight(struct bfq_group *bfqg, u64 weight, u64 
dev_weight)
 {
weight = dev_weight ?: weight;
@@ -1098,6 +1122,55 @@ static ssize_t bfq_io_set_weight(struct kernfs_open_file 
*of,
return bfq_io_set_device_weight(of, buf, nbytes, off);
 }
 
+static ssize_t bfq_io_set_ioprio(struct kernfs_open_file *of, char *buf,
+size_t nbytes, loff_t off)
+{
+   struct cgroup_subsys_state *css = of_css(of);
+   struct blkcg *blkcg = css_to_blkcg(css);
+   struct bfq_group_data *bfqgd = blkcg_to_bfqgd(blkcg);
+   struct blkcg_gq *blkg;
+   unsigned int class, data;
+   char *endp;
+
+   buf = strstrip(buf);
+
+   class = simple_strtoul(buf, &endp, 10);
+   if (*endp != ' ')
+   return -EINVAL;
+   buf = endp + 1;
+
+   data = simple_strtoul(buf, &endp, 10);
+   if ((*endp != ' ') && (*endp != '\0'))
+   return -EINVAL;
+
+   if (class > IOPRIO_CLASS_IDLE || data >= IOPRIO_BE_NR)
+   return -EINVAL;
+
+   spin_lock_irq(&blkcg->lock);
+   bfqgd->ioprio = IOPRIO_PRIO_VALUE(class, data);
+   hlist_for_each_entry(blkg, &blkcg->blkg_list, blkcg_node) {
+   struct bfq_group *bfqg = blkg_to_bfqg(blkg);
+
+   if (bfqg) {
+   if ((bfqg->ioprio_class != class) ||
+   (bfqg->ioprio != data)) {
+   unsigned short weight;
+
+   weight = class ? bfq_ioprio_to_weight(data) :
+   BFQ_WEIGHT_LEGACY_DFL;
+
+   bfqg->new_ioprio_class = class;
+   bfqg->new_ioprio = data;
+   bfqg->entity.new_weight = weight;
+   bfqg->entity.prio_changed = 1;
+   }
+   }
+   }
+   spin_unlock_irq(&blkcg->lock);
+
+   return nbytes;
+}
+
 static int bfqg_print_rwstat(struct seq_file *sf, void *v)
 {
blkcg_print_blkgs(sf, css_to_blkcg(seq_css(sf)), blkg_prfill_rwstat,
@@ -1264,6 +1337,12 @@ struct cftype bfq_blkcg_legacy_files[] = {
.seq_show = bfq_io_show_weight,
.write = bfq_io_set_weight,
},
+   {
+   .name = "bfq.ioprio",
+   .flags = CFTYPE_NOT_ON_ROOT,
+   .seq_show = bfq_io_show_ioprio,
+   .write = bfq_io_set_ioprio,
+   },
 

[PATCH v3 01/14] bfq: introduce bfq_entity_to_bfqg helper method

[brookxu]

From: Chunguang Xu 

Introduce bfq_entity_to_bfqg() to make it easier to obtain the
bfq_group corresponding to the entity.

Signed-off-by: Chunguang Xu 
---
 block/bfq-cgroup.c  |  6 ++
 block/bfq-iosched.h |  1 +
 block/bfq-wf2q.c| 16 
 3 files changed, 15 insertions(+), 8 deletions(-)

diff --git a/block/bfq-cgroup.c b/block/bfq-cgroup.c
index b791e20..a5f544a 100644
--- a/block/bfq-cgroup.c
+++ b/block/bfq-cgroup.c
@@ -309,8 +309,7 @@ struct bfq_group *bfqq_group(struct bfq_queue *bfqq)
 {
struct bfq_entity *group_entity = bfqq->entity.parent;
 
-   return group_entity ? container_of(group_entity, struct bfq_group,
-  entity) :
+   return group_entity ? bfq_entity_to_bfqg(group_entity) :
  bfqq->bfqd->root_group;
 }
 
@@ -610,8 +609,7 @@ struct bfq_group *bfq_find_set_group(struct bfq_data *bfqd,
 */
entity = &bfqg->entity;
for_each_entity(entity) {
-   struct bfq_group *curr_bfqg = container_of(entity,
-   struct bfq_group, entity);
+   struct bfq_group *curr_bfqg = bfq_entity_to_bfqg(entity);
if (curr_bfqg != bfqd->root_group) {
parent = bfqg_parent(curr_bfqg);
if (!parent)
diff --git a/block/bfq-iosched.h b/block/bfq-iosched.h
index b8e793c..a6f98e9 100644
--- a/block/bfq-iosched.h
+++ b/block/bfq-iosched.h
@@ -941,6 +941,7 @@ struct bfq_group {
 #endif
 
 struct bfq_queue *bfq_entity_to_bfqq(struct bfq_entity *entity);
+struct bfq_group *bfq_entity_to_bfqg(struct bfq_entity *entity);
 
 /* --- main algorithm interface - */
 
diff --git a/block/bfq-wf2q.c b/block/bfq-wf2q.c
index 070e34a..5ff0028 100644
--- a/block/bfq-wf2q.c
+++ b/block/bfq-wf2q.c
@@ -149,7 +149,7 @@ struct bfq_group *bfq_bfqq_to_bfqg(struct bfq_queue *bfqq)
if (!group_entity)
group_entity = &bfqq->bfqd->root_group->entity;
 
-   return container_of(group_entity, struct bfq_group, entity);
+   return bfq_entity_to_bfqg(group_entity);
 }
 
 /*
@@ -208,7 +208,7 @@ static bool bfq_no_longer_next_in_service(struct bfq_entity 
*entity)
if (bfq_entity_to_bfqq(entity))
return true;
 
-   bfqg = container_of(entity, struct bfq_group, entity);
+   bfqg = bfq_entity_to_bfqg(entity);
 
/*
 * The field active_entities does not always contain the
@@ -266,6 +266,15 @@ struct bfq_queue *bfq_entity_to_bfqq(struct bfq_entity 
*entity)
return bfqq;
 }
 
+struct bfq_group *bfq_entity_to_bfqg(struct bfq_entity *entity)
+{
+   struct bfq_group *bfqg = NULL;
+
+   if (entity->my_sched_data)
+   bfqg = container_of(entity, struct bfq_group, entity);
+
+   return bfqg;
+}
 
 /**
  * bfq_delta - map service into the virtual time domain.
@@ -1001,8 +1010,7 @@ static void __bfq_activate_entity(struct bfq_entity 
*entity,
 
 #ifdef CONFIG_BFQ_GROUP_IOSCHED
if (!bfq_entity_to_bfqq(entity)) { /* bfq_group */
-   struct bfq_group *bfqg =
-   container_of(entity, struct bfq_group, entity);
+   struct bfq_group *bfqg = bfq_entity_to_bfqg(entity);
struct bfq_data *bfqd = bfqg->bfqd;
 
if (!entity->in_groups_with_pending_reqs) {
-- 
1.8.3.1

[PATCH v3 00/14] bfq: introduce bfq.ioprio for cgroup

[brookxu]

From: Chunguang Xu 

Any suggestions or discussions are welcome, thank you every much.

BACKGROUND:
In the container scenario, in addition to throughput, we also pay
attention to Qos of each group. Based on hierarchical scheduling,
EMQ, IO Injection, bfq.weight and other mechanisms, we can achieve
better IO isolation, better throughput, better avoiding priority
inversion. However, we still have something to be optimized.

OPTIMIZATION:

We try to do something to make bfq work better in the container scene.

1. Introduce bfq.ioprio
Tasks in the production environment can be roughly divided into
three categories: emergency, ordinary and offline. Emergency tasks
need to be scheduled in real time, such as system agents. Offline
tasks do not need to guarantee QoS, but can improve system resource
utilization during system idle periods, such as background tasks.

At present, we can use weights to simulate IO preemption, but since
weights are more of a share concept, they cannot be simulated well.
Using ioprio class for group, we can solve the above problems more
easier. In this way, in hierarchical scheduling, we can ensure that
RT and IDLE group can be scheduled correctly. In addition, we also
introduce ioprio for group, so we realize a weight value through
ioprio class and ioprio. In scenarios where only simple weights are
needed, we can achieve IO preemption and weight isolation only
through bfq.ioprio. 

After the introduction of bfq.ioprio, in order to better adapt to
the actual container environment. When scheduling within a group,
we use task ioprio class. But outside of group, we use group ioprio
class. For example, when counting bfqd->busy_queues[], tasks from the
CLASS_IDLE group are always regarded as CLASS_IDLE, and the ioprio
class of the task is ignored.

2. Introduce better_faireness mode
Better Qos control needs to sacrifice throughput, and this is not
suitable for all scenarios. For this, we added a switch called
better_fairness. After better_fairness is enabled, we will make
the following restrictions:

Guarantee group Qos:
1. Cooperator queue can only come from the same group and the same class.
2. Waker queue can only come from the same group and the same class.
3. Inject queue can only come from the same group of the same class.

Guarantee RT tasks Qos:
1. Async_queue cannot inject RT queue.
2. Traverse the upper schedule domain to determine whether
   in_service_queue needs to be preempted.
3. If in_service_queue marked prio_expire, disable idle.

Better Buffer IO control:
1. Except for the CLASS_IDLE queue, other queues allow idle by default.

INTERFACE:

The bfq.ioprio interface now is available for cgroup v1 and cgroup
v2. Users can configure the ioprio for cgroup through this
interface, as shown below:

echo "1 2"> blkio.bfq.ioprio

The above two values respectively represent the values of ioprio
class and ioprio for cgroup.

EXPERIMENT:

The test process is as follows:
# prepare data disk
mount /dev/sdb /data1

# prepare IO scheduler
echo bfq > /sys/block/sdb/queue/scheduler
echo 0 > /sys/block/sdb/queue/iosched/low_latency
echo 1 > /sys/block/sdb/queue/iosched/better_fairness

It is worth noting here that nr_requests limits the number of
requests, and it does not perceive priority. If nr_requests is
too small, it may cause a serious priority inversion problem.
Therefore, we can increase the size of nr_requests based on
the actual situation.

# create cgroup v1 hierarchy
cd /sys/fs/cgroup/blkio
mkdir rt be0 be1 be2 idle

# prepare cgroup
echo "1 0" > rt/blkio.bfq.ioprio
echo "2 0" > be0/blkio.bfq.ioprio
echo "2 4" > be1/blkio.bfq.ioprio
echo "2 7" > be2/blkio.bfq.ioprio
echo "3 0" > idle/blkio.bfq.ioprio

# run fio test
fio fio.ini

# generate svg graph
fio_generate_plots res

The contents of fio.ini are as follows:
[global]
ioengine=libaio
group_reporting=1
log_avg_msec=3000
direct=1
time_based=1
iodepth=16
size=100M
rw=write
bs=1M
[rt]
name=rt
write_bw_log=rt
write_lat_log=rt
write_iops_log=rt
filename=/data1/rt.bin
cgroup=rt
runtime=30s
nice=-10
[be0]
name=be0
write_bw_log=be0
write_lat_log=be0
write_iops_log=be0
filename=/data1/be0.bin
cgroup=be0
runtime=60s
[be1]
name=be1
write_bw_log=be1
write_lat_log=be1
write_iops_log=be1
filename=/data1/be1.bin
cgroup=be1
runtime=60s
[be2]
name=be2
write_bw_log=be2
write_lat_log=be2
write_iops_log=be2
filename=/data1/be2.bin
cgroup=be2
runtime=60s
[idle]
name=idle
write_bw_log=idle
write_lat_log=idle
write_iops_log=idle
filename=/data1/idle.bin
cgroup=idle
runtime=90s

V3:
1. introdule prio_expire for bfqq.
2. introduce better_fairness mode.
3. optimize the processing of task ioprio and group ioprio. 
4. optimize some small points

V2:
1. Optmise bfq_select_next_class().
2. Introduce bfq_group [] to track the number of groups for each CLASS.
3. Optimse IO injection, EMQ and Idle mechanism for CLASS_RT.

Chunguang Xu (14):
  bfq: introduce bfq_entity_to_bfqg helper method
  bfq: convert the type of bfq_group.bfqd to bfq_data*
  bfq: introduce bf

[PATCH] docs: livepatch: Fix a typo

[Bhaskar Chowdhury]

s/varibles/variables/

Signed-off-by: Bhaskar Chowdhury 
---
 Documentation/livepatch/shadow-vars.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/livepatch/shadow-vars.rst 
b/Documentation/livepatch/shadow-vars.rst
index c05715aeafa4..8464866d18ba 100644
--- a/Documentation/livepatch/shadow-vars.rst
+++ b/Documentation/livepatch/shadow-vars.rst
@@ -165,7 +165,7 @@ In-flight parent objects

 Sometimes it may not be convenient or possible to allocate shadow
 variables alongside their parent objects.  Or a livepatch fix may
-require shadow varibles to only a subset of parent object instances.  In
+require shadow variables to only a subset of parent object instances.  In
 these cases, the klp_shadow_get_or_alloc() call can be used to attach
 shadow variables to parents already in-flight.

--
2.30.1

[PATCH RESEND v5 11/12] arm: dts: mt7623: harmonize node names and compatibles

[Chunfeng Yun]

This is used to fix dtbs_check warning

Signed-off-by: Chunfeng Yun 
---
v2~v5: no changes
---
 arch/arm/boot/dts/mt7623.dtsi  | 26 ++
 arch/arm/boot/dts/mt7623n.dtsi |  4 ++--
 2 files changed, 16 insertions(+), 14 deletions(-)

diff --git a/arch/arm/boot/dts/mt7623.dtsi b/arch/arm/boot/dts/mt7623.dtsi
index aea6809500d7..3c11f7cfcc40 100644
--- a/arch/arm/boot/dts/mt7623.dtsi
+++ b/arch/arm/boot/dts/mt7623.dtsi
@@ -787,8 +787,9 @@
};
};
 
-   pcie0_phy: pcie-phy@1a149000 {
-   compatible = "mediatek,generic-tphy-v1";
+   pcie0_phy: t-phy@1a149000 {
+   compatible = "mediatek,mt7623-tphy",
+"mediatek,generic-tphy-v1";
reg = <0 0x1a149000 0 0x0700>;
#address-cells = <2>;
#size-cells = <2>;
@@ -804,8 +805,9 @@
};
};
 
-   pcie1_phy: pcie-phy@1a14a000 {
-   compatible = "mediatek,generic-tphy-v1";
+   pcie1_phy: t-phy@1a14a000 {
+   compatible = "mediatek,mt7623-tphy",
+"mediatek,generic-tphy-v1";
reg = <0 0x1a14a000 0 0x0700>;
#address-cells = <2>;
#size-cells = <2>;
@@ -823,7 +825,7 @@
 
usb1: usb@1a1c {
compatible = "mediatek,mt7623-xhci",
-"mediatek,mt8173-xhci";
+"mediatek,mtk-xhci";
reg = <0 0x1a1c 0 0x1000>,
  <0 0x1a1c4700 0 0x0100>;
reg-names = "mac", "ippc";
@@ -836,9 +838,9 @@
status = "disabled";
};
 
-   u3phy1: usb-phy@1a1c4000 {
-   compatible = "mediatek,mt7623-u3phy",
-"mediatek,mt2701-u3phy";
+   u3phy1: t-phy@1a1c4000 {
+   compatible = "mediatek,mt7623-tphy",
+"mediatek,generic-tphy-v1";
reg = <0 0x1a1c4000 0 0x0700>;
#address-cells = <2>;
#size-cells = <2>;
@@ -864,7 +866,7 @@
 
usb2: usb@1a24 {
compatible = "mediatek,mt7623-xhci",
-"mediatek,mt8173-xhci";
+"mediatek,mtk-xhci";
reg = <0 0x1a24 0 0x1000>,
  <0 0x1a244700 0 0x0100>;
reg-names = "mac", "ippc";
@@ -877,9 +879,9 @@
status = "disabled";
};
 
-   u3phy2: usb-phy@1a244000 {
-   compatible = "mediatek,mt7623-u3phy",
-"mediatek,mt2701-u3phy";
+   u3phy2: t-phy@1a244000 {
+   compatible = "mediatek,mt7623-tphy",
+"mediatek,generic-tphy-v1";
reg = <0 0x1a244000 0 0x0700>;
#address-cells = <2>;
#size-cells = <2>;
diff --git a/arch/arm/boot/dts/mt7623n.dtsi b/arch/arm/boot/dts/mt7623n.dtsi
index 1880ac9e32cf..bcb0846e29fd 100644
--- a/arch/arm/boot/dts/mt7623n.dtsi
+++ b/arch/arm/boot/dts/mt7623n.dtsi
@@ -246,7 +246,7 @@
status = "disabled";
};
 
-   mipi_tx0: mipi-dphy@1001 {
+   mipi_tx0: dsi-phy@1001 {
compatible = "mediatek,mt7623-mipi-tx",
 "mediatek,mt2701-mipi-tx";
reg = <0 0x1001 0 0x90>;
@@ -265,7 +265,7 @@
status = "disabled";
};
 
-   hdmi_phy: phy@10209100 {
+   hdmi_phy: hdmi-phy@10209100 {
compatible = "mediatek,mt7623-hdmi-phy",
 "mediatek,mt2701-hdmi-phy";
reg = <0 0x10209100 0 0x24>;
-- 
2.18.0

[PATCH RESEND v5 02/12] dt-bindings: phy: mediatek: hdmi-phy: modify compatible items

[Chunfeng Yun]

mt7623-hdmi-tx is compatible to mt2701-hdmi-tx, and the compatible
"mediatek,mt7623-hdmi-tx" is not supported in driver, in fact uses
"mediatek,mt2701-hdmi-tx" instead on MT7623, so changes the
compatible items to make dependence clear.

Cc: Chun-Kuang Hu 
Cc: Philipp Zabel 
Acked-by: Chun-Kuang Hu 
Reviewed-by: Rob Herring 
Signed-off-by: Chunfeng Yun 
---
v5: no changes
v4: add acked-by CK and Reviewed-by Rob
v3: modify commit message
v2: no changes
---
 .../devicetree/bindings/phy/mediatek,hdmi-phy.yaml| 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/Documentation/devicetree/bindings/phy/mediatek,hdmi-phy.yaml 
b/Documentation/devicetree/bindings/phy/mediatek,hdmi-phy.yaml
index 4752517a1446..0d94950b84ca 100644
--- a/Documentation/devicetree/bindings/phy/mediatek,hdmi-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/mediatek,hdmi-phy.yaml
@@ -21,10 +21,13 @@ properties:
 pattern: "^hdmi-phy@[0-9a-f]+$"
 
   compatible:
-enum:
-  - mediatek,mt2701-hdmi-phy
-  - mediatek,mt7623-hdmi-phy
-  - mediatek,mt8173-hdmi-phy
+oneOf:
+  - items:
+  - enum:
+  - mediatek,mt7623-hdmi-phy
+  - const: mediatek,mt2701-hdmi-phy
+  - const: mediatek,mt2701-hdmi-phy
+  - const: mediatek,mt8173-hdmi-phy
 
   reg:
 maxItems: 1
-- 
2.18.0

[PATCH RESEND v5 08/12] arm64: dts: mediatek: mt7622: harmonize node names and compatibles

[Chunfeng Yun]

This is used to fix dtbs_check warning

Signed-off-by: Chunfeng Yun 
---
v2~v5: no changes
---
 arch/arm64/boot/dts/mediatek/mt7622.dtsi | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/boot/dts/mediatek/mt7622.dtsi 
b/arch/arm64/boot/dts/mediatek/mt7622.dtsi
index 7c6d871538a6..890a942ec608 100644
--- a/arch/arm64/boot/dts/mediatek/mt7622.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt7622.dtsi
@@ -742,8 +742,8 @@
status = "disabled";
};
 
-   u3phy: usb-phy@1a0c4000 {
-   compatible = "mediatek,mt7622-u3phy",
+   u3phy: t-phy@1a0c4000 {
+   compatible = "mediatek,mt7622-tphy",
 "mediatek,generic-tphy-v1";
reg = <0 0x1a0c4000 0 0x700>;
#address-cells = <2>;
@@ -877,8 +877,9 @@
status = "disabled";
};
 
-   sata_phy: sata-phy@1a243000 {
-   compatible = "mediatek,generic-tphy-v1";
+   sata_phy: t-phy@1a243000 {
+   compatible = "mediatek,mt7622-tphy",
+"mediatek,generic-tphy-v1";
#address-cells = <2>;
#size-cells = <2>;
ranges;
-- 
2.18.0

[PATCH RESEND v5 06/12] arm64: dts: mediatek: mt2712: harmonize node names

[Chunfeng Yun]

This is used to fix dtbs_check warning.

Signed-off-by: Chunfeng Yun 
---
v2~v5: no changes
---
 arch/arm64/boot/dts/mediatek/mt2712e.dtsi | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/boot/dts/mediatek/mt2712e.dtsi 
b/arch/arm64/boot/dts/mediatek/mt2712e.dtsi
index db17d0a4ed57..a9cca9c146fd 100644
--- a/arch/arm64/boot/dts/mediatek/mt2712e.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt2712e.dtsi
@@ -805,7 +805,7 @@
ranges;
status = "disabled";
 
-   usb_host0: xhci@1127 {
+   usb_host0: usb@1127 {
compatible = "mediatek,mt2712-xhci",
 "mediatek,mtk-xhci";
reg = <0 0x1127 0 0x1000>;
@@ -818,7 +818,7 @@
};
};
 
-   u3phy0: usb-phy@1129 {
+   u3phy0: t-phy@1129 {
compatible = "mediatek,mt2712-tphy",
 "mediatek,generic-tphy-v2";
#address-cells = <1>;
@@ -869,7 +869,7 @@
ranges;
status = "disabled";
 
-   usb_host1: xhci@112c {
+   usb_host1: usb@112c {
compatible = "mediatek,mt2712-xhci",
 "mediatek,mtk-xhci";
reg = <0 0x112c 0 0x1000>;
@@ -882,7 +882,7 @@
};
};
 
-   u3phy1: usb-phy@112e {
+   u3phy1: t-phy@112e {
compatible = "mediatek,mt2712-tphy",
 "mediatek,generic-tphy-v2";
#address-cells = <1>;
-- 
2.18.0

[PATCH RESEND v5 01/12] dt-bindings: phy: mediatek: dsi-phy: modify compatible dependence

[Chunfeng Yun]

mt7623-mipi-tx is compatible to mt2701-mipi-tx, and use
"mediatek,mt2701-mipi-tx" instead on MT7623, so modify
the compatible items to make dependence clear.

Cc: Chun-Kuang Hu 
Cc: Philipp Zabel 
Acked-by: Chun-Kuang Hu 
Reviewed-by: Rob Herring 
Signed-off-by: Chunfeng Yun 
---
v5: no changes
v4: add acked-by CK, and reviewed-by Rob
v3: modify commit message suggested by CK
v2: separate two patches suggested by CK
---
 .../devicetree/bindings/phy/mediatek,dsi-phy.yaml   | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/Documentation/devicetree/bindings/phy/mediatek,dsi-phy.yaml 
b/Documentation/devicetree/bindings/phy/mediatek,dsi-phy.yaml
index 71d4acea1f66..6e4d795f9b02 100644
--- a/Documentation/devicetree/bindings/phy/mediatek,dsi-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/mediatek,dsi-phy.yaml
@@ -19,11 +19,14 @@ properties:
 pattern: "^dsi-phy@[0-9a-f]+$"
 
   compatible:
-enum:
-  - mediatek,mt2701-mipi-tx
-  - mediatek,mt7623-mipi-tx
-  - mediatek,mt8173-mipi-tx
-  - mediatek,mt8183-mipi-tx
+oneOf:
+  - items:
+  - enum:
+  - mediatek,mt7623-mipi-tx
+  - const: mediatek,mt2701-mipi-tx
+  - const: mediatek,mt2701-mipi-tx
+  - const: mediatek,mt8173-mipi-tx
+  - const: mediatek,mt8183-mipi-tx
 
   reg:
 maxItems: 1
-- 
2.18.0

[PATCH RESEND v5 03/12] dt-bindings: phy: mediatek: tphy: change patternProperties

[Chunfeng Yun]

The phy may be named as pcie-phy when the T-PHY only supports
PCIe mode, it's also the similar case for SATA, named as
sata-phy.

Reviewed-by: Rob Herring 
Signed-off-by: Chunfeng Yun 
---
v5: no changes
v4: add reviewed-by Rob
v2~v3: no changes
---
 Documentation/devicetree/bindings/phy/mediatek,tphy.yaml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml 
b/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml
index 602e6ff45785..4f1733fd9a55 100644
--- a/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml
+++ b/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml
@@ -117,7 +117,7 @@ properties:
 
 # Required child node:
 patternProperties:
-  "^usb-phy@[0-9a-f]+$":
+  "^(usb|pcie|sata)-phy@[0-9a-f]+$":
 type: object
 description:
   A sub-node is required for each port the controller provides.
-- 
2.18.0

[PATCH RESEND v5 05/12] arm64: dts: mediatek: mt8173: fix dtbs_check warning

[Chunfeng Yun]

Harmonize nodes names, compatibles and remove unused property.

Signed-off-by: Chunfeng Yun 
---
v2~v5: no changes
---
 arch/arm64/boot/dts/mediatek/mt8173-evb.dts |  4 +---
 arch/arm64/boot/dts/mediatek/mt8173.dtsi| 13 +++--
 2 files changed, 8 insertions(+), 9 deletions(-)

diff --git a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts 
b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
index 6dffada2e66b..0ce81c4fe81e 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
+++ b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
@@ -516,10 +516,8 @@
extcon = <&extcon_usb>;
dr_mode = "otg";
wakeup-source;
-   pinctrl-names = "default", "id_float", "id_ground";
+   pinctrl-names = "default";
pinctrl-0 = <&usb_id_pins_float>;
-   pinctrl-1 = <&usb_id_pins_float>;
-   pinctrl-2 = <&usb_id_pins_ground>;
status = "okay";
 };
 
diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi 
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index ecb37a7e6870..003a5653c505 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -631,7 +631,7 @@
#mbox-cells = <2>;
};
 
-   mipi_tx0: mipi-dphy@10215000 {
+   mipi_tx0: dsi-phy@10215000 {
compatible = "mediatek,mt8173-mipi-tx";
reg = <0 0x10215000 0 0x1000>;
clocks = <&clk26m>;
@@ -641,7 +641,7 @@
status = "disabled";
};
 
-   mipi_tx1: mipi-dphy@10216000 {
+   mipi_tx1: dsi-phy@10216000 {
compatible = "mediatek,mt8173-mipi-tx";
reg = <0 0x10216000 0 0x1000>;
clocks = <&clk26m>;
@@ -926,7 +926,7 @@
};
 
ssusb: usb@11271000 {
-   compatible = "mediatek,mt8173-mtu3";
+   compatible = "mediatek,mt8173-mtu3", "mediatek,mtu3";
reg = <0 0x11271000 0 0x3000>,
  <0 0x11280700 0 0x0100>;
reg-names = "mac", "ippc";
@@ -943,8 +943,9 @@
ranges;
status = "disabled";
 
-   usb_host: xhci@1127 {
-   compatible = "mediatek,mt8173-xhci";
+   usb_host: usb@1127 {
+   compatible = "mediatek,mt8173-xhci",
+"mediatek,mtk-xhci";
reg = <0 0x1127 0 0x1000>;
reg-names = "mac";
interrupts = ;
@@ -955,7 +956,7 @@
};
};
 
-   u3phy: usb-phy@1129 {
+   u3phy: t-phy@1129 {
compatible = "mediatek,mt8173-u3phy";
reg = <0 0x1129 0 0x800>;
#address-cells = <2>;
-- 
2.18.0

[PATCH RESEND v5 07/12] arm64: dts: mediatek: mt8516: harmonize node names and compatibles

[Chunfeng Yun]

This is used to fix dtbs_check warning:
  harmonize node names and compatibles;
  add property "usb-role-switch" for connector dependence.

Signed-off-by: Chunfeng Yun 
---
v2~v5: no changes
---
 arch/arm64/boot/dts/mediatek/mt8516.dtsi | 9 +
 arch/arm64/boot/dts/mediatek/pumpkin-common.dtsi | 1 +
 2 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/boot/dts/mediatek/mt8516.dtsi 
b/arch/arm64/boot/dts/mediatek/mt8516.dtsi
index b80e95574bef..bbe5a1419eff 100644
--- a/arch/arm64/boot/dts/mediatek/mt8516.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8516.dtsi
@@ -480,7 +480,7 @@
};
 
usb0: usb@1110 {
-   compatible = "mediatek,mtk-musb";
+   compatible = "mediatek,mt8516-musb", 
"mediatek,mtk-musb";
reg = <0 0x1110 0 0x1000>;
interrupts = ;
interrupt-names = "mc";
@@ -493,7 +493,7 @@
};
 
usb1: usb@1119 {
-   compatible = "mediatek,mtk-musb";
+   compatible = "mediatek,mt8516-musb", 
"mediatek,mtk-musb";
reg = <0 0x1119 0 0x1000>;
interrupts = ;
interrupt-names = "mc";
@@ -506,8 +506,9 @@
status = "disabled";
};
 
-   usb_phy: usb@ {
-   compatible = "mediatek,generic-tphy-v1";
+   usb_phy: t-phy@ {
+   compatible = "mediatek,mt8516-tphy",
+"mediatek,generic-tphy-v1";
reg = <0 0x 0 0x800>;
#address-cells = <2>;
#size-cells = <2>;
diff --git a/arch/arm64/boot/dts/mediatek/pumpkin-common.dtsi 
b/arch/arm64/boot/dts/mediatek/pumpkin-common.dtsi
index 63fd70086bb8..7d738f01cf8d 100644
--- a/arch/arm64/boot/dts/mediatek/pumpkin-common.dtsi
+++ b/arch/arm64/boot/dts/mediatek/pumpkin-common.dtsi
@@ -188,6 +188,7 @@
 &usb0 {
status = "okay";
dr_mode = "peripheral";
+   usb-role-switch;
 
usb_con: connector {
compatible = "usb-c-connector";
-- 
2.18.0

[PATCH RESEND v5 09/12] arm64: dts: mediatek: mt8183: fix dtbs_check warning

[Chunfeng Yun]

Harmonize node names, compatibles and properties.

Signed-off-by: Chunfeng Yun 
---
v4~v5: no changes
v3: remove property clock-names suggested by CK
v2: no changes
---
 arch/arm64/boot/dts/mediatek/mt8183.dtsi | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi 
b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
index 80519a145f13..8882d35ac6ab 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
@@ -880,7 +880,7 @@
ranges;
status = "disabled";
 
-   usb_host: xhci@1120 {
+   usb_host: usb@1120 {
compatible = "mediatek,mt8183-xhci",
 "mediatek,mtk-xhci";
reg = <0 0x1120 0 0x1000>;
@@ -923,11 +923,10 @@
status = "disabled";
};
 
-   mipi_tx0: mipi-dphy@11e5 {
+   mipi_tx0: dsi-phy@11e5 {
compatible = "mediatek,mt8183-mipi-tx";
reg = <0 0x11e5 0 0x1000>;
clocks = <&apmixedsys CLK_APMIXED_MIPID0_26M>;
-   clock-names = "ref_clk";
#clock-cells = <0>;
#phy-cells = <0>;
clock-output-names = "mipi_tx0_pll";
@@ -946,11 +945,10 @@
};
};
 
-   u3phy: usb-phy@11f4 {
+   u3phy: t-phy@11f4 {
compatible = "mediatek,mt8183-tphy",
 "mediatek,generic-tphy-v2";
#address-cells = <1>;
-   #phy-cells = <1>;
#size-cells = <1>;
ranges = <0 0 0x11f4 0x1000>;
status = "okay";
-- 
2.18.0

[PATCH RESEND v5 04/12] arm64: dts: mt8173: fix property typo of 'phys' in dsi node

[Chunfeng Yun]

Use 'phys' instead of 'phy'.

Fixes: 81ad4dbaf7af ("arm64: dts: mt8173: Add display subsystem related nodes")
Cc: stable 
Reviewed-by: Chun-Kuang Hu 
Signed-off-by: Chunfeng Yun 
---
v5: merged into this series, add Reviewed-by CK
---
 arch/arm64/boot/dts/mediatek/mt8173.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi 
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index 7fa870e4386a..ecb37a7e6870 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -1235,7 +1235,7 @@
 <&mmsys CLK_MM_DSI1_DIGITAL>,
 <&mipi_tx1>;
clock-names = "engine", "digital", "hs";
-   phy = <&mipi_tx1>;
+   phys = <&mipi_tx1>;
phy-names = "dphy";
status = "disabled";
};
-- 
2.18.0

[PATCH RESEND v5 12/12] arm: dts: mt2701: harmonize node names and compatibles

[Chunfeng Yun]

This is used to fix dtbs_check warning

Signed-off-by: Chunfeng Yun 
---
v2~v5: no changes
---
 arch/arm/boot/dts/mt2701.dtsi | 19 +++
 1 file changed, 11 insertions(+), 8 deletions(-)

diff --git a/arch/arm/boot/dts/mt2701.dtsi b/arch/arm/boot/dts/mt2701.dtsi
index fade14284017..4776f85d6d5b 100644
--- a/arch/arm/boot/dts/mt2701.dtsi
+++ b/arch/arm/boot/dts/mt2701.dtsi
@@ -607,7 +607,7 @@
};
 
usb0: usb@1a1c {
-   compatible = "mediatek,mt8173-xhci";
+   compatible = "mediatek,mt2701-xhci", "mediatek,mtk-xhci";
reg = <0 0x1a1c 0 0x1000>,
  <0 0x1a1c4700 0 0x0100>;
reg-names = "mac", "ippc";
@@ -620,8 +620,9 @@
status = "disabled";
};
 
-   u3phy0: usb-phy@1a1c4000 {
-   compatible = "mediatek,mt2701-u3phy";
+   u3phy0: t-phy@1a1c4000 {
+   compatible = "mediatek,mt2701-tphy",
+"mediatek,generic-tphy-v1";
reg = <0 0x1a1c4000 0 0x0700>;
#address-cells = <2>;
#size-cells = <2>;
@@ -646,7 +647,7 @@
};
 
usb1: usb@1a24 {
-   compatible = "mediatek,mt8173-xhci";
+   compatible = "mediatek,mt2701-xhci", "mediatek,mtk-xhci";
reg = <0 0x1a24 0 0x1000>,
  <0 0x1a244700 0 0x0100>;
reg-names = "mac", "ippc";
@@ -659,8 +660,9 @@
status = "disabled";
};
 
-   u3phy1: usb-phy@1a244000 {
-   compatible = "mediatek,mt2701-u3phy";
+   u3phy1: t-phy@1a244000 {
+   compatible = "mediatek,mt2701-tphy",
+"mediatek,generic-tphy-v1";
reg = <0 0x1a244000 0 0x0700>;
#address-cells = <2>;
#size-cells = <2>;
@@ -700,8 +702,9 @@
status = "disabled";
};
 
-   u2phy0: usb-phy@1121 {
-   compatible = "mediatek,generic-tphy-v1";
+   u2phy0: t-phy@1121 {
+   compatible = "mediatek,mt2701-tphy",
+"mediatek,generic-tphy-v1";
reg = <0 0x1121 0 0x0800>;
#address-cells = <2>;
#size-cells = <2>;
-- 
2.18.0

Re: [PATCH] PCI: Allow drivers to claim exclusive access to config regions

[Greg Kroah-Hartman]

On Wed, Mar 24, 2021 at 06:23:54PM -0700, Dan Williams wrote:
> The PCIE Data Object Exchange (DOE) mailbox is a protocol run over
> configuration cycles. It assumes one initiator at a time is
> reading/writing the data registers.

That sounds like a horrible protocol for a multi-processor system.
Where is it described and who can we go complain to for creating such a
mess?

> If userspace reads from the response
> data payload it may steal data that a kernel driver was expecting to
> read. If userspace writes to the request payload it may corrupt the
> request a driver was trying to send.

Fun!  So you want to keep root in userspace from doing this?  I thought
we already do that today?

> Introduce pci_{request,release}_config_region() for a driver to exclude
> the possibility of userspace induced corruption while accessing the DOE
> mailbox. Likely there are other configuration state assumptions that a
> driver may want to assert are under its exclusive control, so this
> capability is not limited to any specific configuration range.

As you do not have a user for these functions, it's hard to see how they
would be used.  We also really can't add new apis with no in-tree users,
so do you have a patch series that requires this functionality
somewhere?

> Since writes are targeted and are already prepared for failure the
> entire request is failed. The same can not be done for reads as the
> device completely disappears from lspci output if any configuration
> register in the request is exclusive. Instead skip the actual
> configuration cycle on a per-access basis and return all f's as if the
> read had failed.

returning all ff is a huge hint to many drivers that the device is gone,
not that it just failed.  So what happens to code that thinks that and
then tears stuff down as if the device has been removed?

Trying to protect drivers from userspace here feels odd, what userspace
tools are trying to access these devices while they are under
"exclusive" control from the kernel?  lspci not running as root should
not be doing anything crazy, but if you want to run it as root,
shouldn't you be allowed to access it properly?

What hardware has this problem that we need to claim exclusive ownership
over that differs from the old hardware we used to have that would do
crazy things when reading from from userspace?  We had this problem a
long time ago and lived with it, what changed now?

thanks,

greg k-h

[PATCH RESEND v5 10/12] arm: dts: mt7629: harmonize node names and compatibles

[Chunfeng Yun]

This is used to fix dtbs_check warning

Signed-off-by: Chunfeng Yun 
---
v2~v5: no changes
---
 arch/arm/boot/dts/mt7629.dtsi | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/arch/arm/boot/dts/mt7629.dtsi b/arch/arm/boot/dts/mt7629.dtsi
index 5cbb3d244c75..874043f0490d 100644
--- a/arch/arm/boot/dts/mt7629.dtsi
+++ b/arch/arm/boot/dts/mt7629.dtsi
@@ -329,8 +329,9 @@
status = "disabled";
};
 
-   u3phy0: usb-phy@1a0c4000 {
-   compatible = "mediatek,generic-tphy-v2";
+   u3phy0: t-phy@1a0c4000 {
+   compatible = "mediatek,mt7629-tphy",
+"mediatek,generic-tphy-v2";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0 0x1a0c4000 0xe00>;
@@ -413,14 +414,15 @@
};
};
 
-   pciephy1: pcie-phy@1a14a000 {
-   compatible = "mediatek,generic-tphy-v2";
+   pciephy1: t-phy@1a14a000 {
+   compatible = "mediatek,mt7629-tphy",
+"mediatek,generic-tphy-v2";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0 0x1a14a000 0x1000>;
status = "disabled";
 
-   pcieport1: port1phy@0 {
+   pcieport1: pcie-phy@0 {
reg = <0 0x1000>;
clocks = <&clk20m>;
clock-names = "ref";
-- 
2.18.0

Re: [PATCH] drm/vkms: fix misuse of WARN_ON

[Dmitry Vyukov]

On Wed, Mar 24, 2021 at 11:00 PM Melissa Wen  wrote:
>
> On 03/20, Dmitry Vyukov wrote:
> > vkms_vblank_simulate() uses WARN_ON for timing-dependent condition
> > (timer overrun). This is a mis-use of WARN_ON, WARN_ON must be used
> > to denote kernel bugs. Use pr_warn() instead.
> >
> > Signed-off-by: Dmitry Vyukov 
> > Reported-by: syzbot+4fc21a003c8332eb0...@syzkaller.appspotmail.com
> > Cc: Rodrigo Siqueira 
> > Cc: Melissa Wen 
> > Cc: Haneen Mohammed 
> > Cc: Daniel Vetter 
> > Cc: David Airlie 
> > Cc: dri-de...@lists.freedesktop.org
> > Cc: linux-kernel@vger.kernel.org
> > Change-Id: I7f01c288092bc7e472ec63af198f93ce3d8c49f7
> > ---
> >  drivers/gpu/drm/vkms/vkms_crtc.c | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/vkms/vkms_crtc.c 
> > b/drivers/gpu/drm/vkms/vkms_crtc.c
> > index 0443b7deeaef6..758d8a98d96b3 100644
> > --- a/drivers/gpu/drm/vkms/vkms_crtc.c
> > +++ b/drivers/gpu/drm/vkms/vkms_crtc.c
> > @@ -18,7 +18,8 @@ static enum hrtimer_restart vkms_vblank_simulate(struct 
> > hrtimer *timer)
> >
> >   ret_overrun = hrtimer_forward_now(&output->vblank_hrtimer,
> > output->period_ns);
> > - WARN_ON(ret_overrun != 1);
> > + if (ret_overrun != 1)
> > + pr_warn("%s: vblank timer overrun\n", __func__);
>
> Hi Dmitry,
>
> Thanks for your patch.
>
> Looks good to me.
> The Change-Id tag just seems a little noisy to me, but can be
> fixed while applying.

Yes, please drop Change-Id when applying if possible. Sorry for that.
Thanks for the review, Melissa.

> Acked-by: Melissa Wen 
>
> >
> >   spin_lock(&output->lock);
> >   ret = drm_crtc_handle_vblank(crtc);
> >
> > base-commit: e94c55b8e0a0bbe9a026250cf31e2fa45957d776
> > --
> > 2.31.0.291.g576ba9dcdaf-goog
> >

[PATCH] include: scsi: scsi_host_cmd_pool is declared twice

[Wan Jiabing]

struct scsi_host_cmd_pool has been declared. Remove the duplicate.

Signed-off-by: Wan Jiabing 
---
 include/scsi/scsi_host.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/include/scsi/scsi_host.h b/include/scsi/scsi_host.h
index e30fd963b97d..5fa8f6a78d05 100644
--- a/include/scsi/scsi_host.h
+++ b/include/scsi/scsi_host.h
@@ -19,7 +19,6 @@ struct scsi_device;
 struct scsi_host_cmd_pool;
 struct scsi_target;
 struct Scsi_Host;
-struct scsi_host_cmd_pool;
 struct scsi_transport_template;
 
 
-- 
2.25.1

Re: [PATCH v1 0/3] drivers/char: remove /dev/kmem for good

[Greg Kroah-Hartman]

On Thu, Mar 25, 2021 at 09:58:12AM +1100, Balbir Singh wrote:
> On Wed, Mar 24, 2021 at 12:24:12PM -0700, Andrew Morton wrote:
> > 
> > > Let's remove /dev/kmem, which is unused and obsolete.
> > 
> > I grabbed these.  Silently - the cc list is amazing ;)
> > 
> > I was wondering if it would be better to permanently disable /dev/kmem
> > in Kconfig along with a comment "if you really want this thing then
> > email peeps@places with a very good reason why".  Let that ride for a
> > year or three then blam.
> > 
> > But this is so much more attractive, and it certainly sounds like it's
> > worth any damage it might cause.
> > 
> > We do tend to think about distros.  I bet there are a number of weird
> > embedded type systems using /dev/kmem - it's amazing what sorts of
> > hacks those people will put up with the get something out the door. 
> > But those systems tend to carry a lot of specialized changes anyway, so
> > they can just add "revert David's patch" to their pile.
> >
> 
> 
> I wonder if we should have the opposite of driver/staging and call it
> outgoing, with a big thank you to the users and developers and also
> to indicate this feature will be removed in the next (few) merge(s)
> cycles. I guess not all code can be accumulated under a single
> hierarchy. May not be worth the effort, just thinking out loud.

That is exactly what drivers/staging/ is being used for, for stuff on
the way out of the kernel.  wimax just left the kernel that way a week
or so ago, we've been doing this for many years now, the fact that no
one has noticed is good as that means that no one has needed the code
removed that way :)

thanks,

greg k-h

Re: [PATCH v1 0/3] drivers/char: remove /dev/kmem for good

[Greg Kroah-Hartman]

On Wed, Mar 24, 2021 at 12:24:12PM -0700, Andrew Morton wrote:
> 
> > Let's remove /dev/kmem, which is unused and obsolete.
> 
> I grabbed these.  Silently - the cc list is amazing ;)

Thanks, I was going to do so, but your tree is fine with me:

Acked-by: Greg Kroah-Hartman 

[V2][PATCH] cpufreq: dt: check the -EPROBE_DEFER error returned by dev_pm_opp_of_cpumask_add_table

[quanyang . wang]

From: Quanyang Wang 

The function dev_pm_opp_of_cpumask_add_table may return -EPROBE_DEFER
which comes from clk_get(dev, NULL) in _update_opp_table_clk. Ignoring
this error and call the next function  dev_pm_opp_of_cpumask_add_table
may cause dt_cpufreq_probe return -ENODEV instead of -EPROBE_DEFER.
And this will result cpufreq-dt driver probe failure.

Add check condition to fix this issue.

Signed-off-by: Quanyang Wang 
---
 drivers/cpufreq/cpufreq-dt.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/cpufreq/cpufreq-dt.c b/drivers/cpufreq/cpufreq-dt.c
index b1e1bdc63b01..25e46df92941 100644
--- a/drivers/cpufreq/cpufreq-dt.c
+++ b/drivers/cpufreq/cpufreq-dt.c
@@ -257,7 +257,12 @@ static int dt_cpufreq_early_init(struct device *dev, int 
cpu)
 *
 * OPPs might be populated at runtime, don't check for error here.
 */
-   if (!dev_pm_opp_of_cpumask_add_table(priv->cpus))
+   ret = dev_pm_opp_of_cpumask_add_table(priv->cpus);
+   if (ret) {
+   /* Return the -EPROBE_DEFER error to trigger the deferred 
probe. */
+   if (ret == -EPROBE_DEFER)
+   goto out;
+   } else
priv->have_static_opps = true;
 
/*
-- 
2.25.1

[V2][PATCH] cpufreq: dt: check the -EPROBE_DEFER error returned by dev_pm_opp_of_cpumask_add_table

[quanyang . wang]

From: Quanyang Wang 

The function dev_pm_opp_of_cpumask_add_table may return -EPROBE_DEFER
which comes from clk_get(dev, NULL) in _update_opp_table_clk. Ignoring
this error and call the next function  dev_pm_opp_of_cpumask_add_table
may cause dt_cpufreq_probe return -ENODEV instead of -EPROBE_DEFER.
And this will result cpufreq-dt driver probe failure.

Add check condition to fix this issue.

Signed-off-by: Quanyang Wang 
---
 drivers/cpufreq/cpufreq-dt.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/cpufreq/cpufreq-dt.c b/drivers/cpufreq/cpufreq-dt.c
index b1e1bdc63b01..25e46df92941 100644
--- a/drivers/cpufreq/cpufreq-dt.c
+++ b/drivers/cpufreq/cpufreq-dt.c
@@ -257,7 +257,12 @@ static int dt_cpufreq_early_init(struct device *dev, int 
cpu)
 *
 * OPPs might be populated at runtime, don't check for error here.
 */
-   if (!dev_pm_opp_of_cpumask_add_table(priv->cpus))
+   ret = dev_pm_opp_of_cpumask_add_table(priv->cpus);
+   if (ret) {
+   /* Return the -EPROBE_DEFER error to trigger the deferred 
probe. */
+   if (ret == -EPROBE_DEFER)
+   goto out;
+   } else
priv->have_static_opps = true;
 
/*
-- 
2.25.1

[PATCH] drivers: net: wireless: struct lbs_private is declared duplicately

[Wan Jiabing]

struct lbs_private has been declared at 22nd line.
Remove the duplicate.

Signed-off-by: Wan Jiabing 
---
 drivers/net/wireless/marvell/libertas/decl.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/net/wireless/marvell/libertas/decl.h 
b/drivers/net/wireless/marvell/libertas/decl.h
index 5d1e30e0c5db..c1e0388ef01d 100644
--- a/drivers/net/wireless/marvell/libertas/decl.h
+++ b/drivers/net/wireless/marvell/libertas/decl.h
@@ -23,7 +23,6 @@ struct lbs_private;
 typedef void (*lbs_fw_cb)(struct lbs_private *priv, int ret,
const struct firmware *helper, const struct firmware *mainfw);
 
-struct lbs_private;
 struct sk_buff;
 struct net_device;
 struct cmd_ds_command;
-- 
2.25.1

Re: [PATCH v4 2/4] dt-bindings: power: rockchip: Convert to json-schema

[elaine.zhang]

Hi,Heiko:

在 2021/3/24 下午9:31, Heiko Stübner 写道:

Am Mittwoch, 24. März 2021, 11:32:42 CET schrieb Enric Balletbo i Serra:

On 24/3/21 11:25, Enric Balletbo i Serra wrote:

Hi Elaine,

On 24/3/21 11:18, elaine.zhang wrote:

Hi,  Enric

在 2021/3/24 下午5:56, Enric Balletbo i Serra 写道:

Hi Elaine,

This is not the exact version I sent, and you reintroduced a "problem" that were
already solved/discussed on previous versions. See below:

On 24/3/21 8:16, Elaine Zhang wrote:

Convert the soc/rockchip/power_domain.txt binding document to
json-schema and move to the power bindings directory.

Signed-off-by: Enric Balletbo i Serra 

If you do significant is a good practice shortly describe them within [] here.


Signed-off-by: Elaine Zhang 

Note that my last version already had the

Reviewed-by: Rob Herring 

Which should be fine for merging (with probably only minor changes) and you
could maintain if you don't do significant changes, but that's not the case, as
I said, you are reintroducing one problem. Please review the comments already
received on this patchset or similar patchsets to avoid this.


---
   .../power/rockchip,power-controller.yaml  | 284 ++
   .../bindings/soc/rockchip/power_domain.txt| 136 -
   2 files changed, 284 insertions(+), 136 deletions(-)
   create mode 100644
Documentation/devicetree/bindings/power/rockchip,power-controller.yaml
   delete mode 100644
Documentation/devicetree/bindings/soc/rockchip/power_domain.txt

diff --git
a/Documentation/devicetree/bindings/power/rockchip,power-controller.yaml
b/Documentation/devicetree/bindings/power/rockchip,power-controller.yaml
new file mode 100644
index ..a220322c5139
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/rockchip,power-controller.yaml
@@ -0,0 +1,284 @@
+# SPDX-License-Identifier: GPL-2.0-only
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/power/rockchip,power-controller.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Rockchip Power Domains
+
+maintainers:
+  - Elaine Zhang 
+  - Rob Herring 

Up to Rob, but I don't think Rob would like to be the maintainer. I think you
can only include yourself and Heiko.



+  - Heiko Stuebner 
+
+description: |
+  Rockchip processors include support for multiple power domains which can be
+  powered up/down by software based on different application scenarios to
save power.
+
+  Power domains contained within power-controller node are generic power domain
+  providers documented in
Documentation/devicetree/bindings/power/power-domain.yaml.
+
+  IP cores belonging to a power domain should contain a "power-domains"
+  property that is a phandle for the power domain node representing the domain.
+
+properties:
+  $nodename:
+const: power-controller
+
+  compatible:
+enum:
+  - rockchip,px30-power-controller
+  - rockchip,rk3036-power-controller
+  - rockchip,rk3066-power-controller
+  - rockchip,rk3128-power-controller
+  - rockchip,rk3188-power-controller
+  - rockchip,rk3228-power-controller
+  - rockchip,rk3288-power-controller
+  - rockchip,rk3328-power-controller
+  - rockchip,rk3366-power-controller
+  - rockchip,rk3368-power-controller
+  - rockchip,rk3399-power-controller
+
+  "#power-domain-cells":
+const: 1
+
+  "#address-cells":
+const: 1
+
+  "#size-cells":
+const: 0
+
+patternProperties:
+  "^pd_[0-9a-z_]{2,10}@[0-9a-f]+$":
+type: object
+description: |
+  Represents the power domains within the power controller node as
documented
+  in Documentation/devicetree/bindings/power/power-domain.yaml.
+

The node names must be generic, as this is power-domain must be in the form:

+patternProperties:
+  "^power-domain@[0-9a-f]+$":

In this way, dtbs_check cannot be passed, and all the usage methods in dts of
Rockchip need to be corrected, which I think is a bigger change.

Well, the problem is in the Rockchip dtbs, so needs to be fixed there. The
bindings must describe hardware in a generic way, not describe the actual dtbs
to not report errors.


FWIW I remember I did something regarding this but never sent to upstream, feel
free to pick if you find useful.

*
https://gitlab.collabora.com/eballetbo/linux/-/commit/12499f223e3d33602449b9102404fe573fb804f5
*
https://gitlab.collabora.com/eballetbo/linux/-/commit/12499f223e3d33602449b9102404fe573fb804f5
*
https://gitlab.collabora.com/eballetbo/linux/-/commit/492bf2213c341152a1c2423242c5634b9e53ff27

looks good that way. I did look at the power-domain driver and
we're (of course) not doing anything with the name in front of the @ :-) .

So I'd be happy to get these.

Heiko


I still don't want to modify this,  I think the PD summary will become 
less intuitive.


Now:

domain  status  slaves
    /device runtime status
--
pd_pipe

Re: linux-next: build warning after merge of the net-next tree

[Stephen Rothwell]

Hi all,

On Thu, 25 Mar 2021 17:23:50 +1100 Stephen Rothwell  
wrote:
>
> After merging the net-next tree, today's linux-next build (htmldocs)
> produced this warning:
> 
> Sphinx parallel build error:
> docutils.utils.SystemMessage: 
> /home/sfr/next/next/Documentation/networking/nf_flowtable.rst:176: (SEVERE/4) 
> Unexpected section title.
> 
> }
> ...
> 
> Introduced by commit
> 
>   143490cde566 ("docs: nf_flowtable: update documentation with enhancements")

This is actually a build error and fails the htmldocs build - well,
actually causes it to hang.

-- 
Cheers,
Stephen Rothwell


pgptFAoPiakXH.pgp
Description: OpenPGP digital signature

Re: [PATCH] tools: usbip: list.h: fix kernel-doc for list_del()

[Greg KH]

On Wed, Mar 24, 2021 at 06:35:01PM -0700, Randy Dunlap wrote:
> On 3/24/21 4:32 PM, Shuah Khan wrote:
> > On 3/23/21 6:02 PM, Randy Dunlap wrote:
> >> In list.h, the kernel-doc for list_del() should be immediately
> >> preceding the implementation and not separated from it by
> >> another function implementation.
> >>
> >> Eliminates this kernel-doc error:
> >> list.h:1: warning: 'list_del' not found
> >>
> >> Signed-off-by: Randy Dunlap 
> >> Cc: Valentina Manea 
> >> Cc: Shuah Khan 
> >> Cc: Shuah Khan 
> >> Cc: linux-...@vger.kernel.org
> >> ---
> >>   tools/usb/usbip/libsrc/list.h |   10 +-
> >>   1 file changed, 5 insertions(+), 5 deletions(-)
> >>
> >> --- linux-next-20210323.orig/tools/usb/usbip/libsrc/list.h
> >> +++ linux-next-20210323/tools/usb/usbip/libsrc/list.h
> >> @@ -77,17 +77,17 @@ static inline void __list_del(struct lis
> >>   #define LIST_POISON1  ((void *) 0x00100100 + POISON_POINTER_DELTA)
> >>   #define LIST_POISON2  ((void *) 0x00200200 + POISON_POINTER_DELTA)
> >>   +static inline void __list_del_entry(struct list_head *entry)
> >> +{
> >> +    __list_del(entry->prev, entry->next);
> >> +}
> >> +
> >>   /**
> >>    * list_del - deletes entry from list.
> >>    * @entry: the element to delete from the list.
> >>    * Note: list_empty() on entry does not return true after this, the 
> >> entry is
> >>    * in an undefined state.
> >>    */
> >> -static inline void __list_del_entry(struct list_head *entry)
> >> -{
> >> -    __list_del(entry->prev, entry->next);
> >> -}
> >> -
> >>   static inline void list_del(struct list_head *entry)
> >>   {
> >>   __list_del(entry->prev, entry->next);
> >>
> > 
> > Thank you for fixing this.
> > 
> > Acked-by: Shuah Khan 
> 
> 
> Thanks. Who do you think should merge this patch?

I can :)

[PATCH -next 2/5] net: core: Fix a typo in dev_addr_lists.c

[Lu Wei]

Modify "funciton" to "function" in net/core/dev_addr_lists.c.

Reported-by: Hulk Robot 
Signed-off-by: Lu Wei 
---
 net/core/dev_addr_lists.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/core/dev_addr_lists.c b/net/core/dev_addr_lists.c
index fa1c37ec40c9..1e5bde241185 100644
--- a/net/core/dev_addr_lists.c
+++ b/net/core/dev_addr_lists.c
@@ -228,7 +228,7 @@ EXPORT_SYMBOL(__hw_addr_unsync);
  *  @sync: function to call if address should be added
  *  @unsync: function to call if address should be removed
  *
- *  This funciton is intended to be called from the ndo_set_rx_mode
+ *  This function is intended to be called from the ndo_set_rx_mode
  *  function of devices that require explicit address add/remove
  *  notifications.  The unsync function may be NULL in which case
  *  the addresses requiring removal will simply be removed without
-- 
2.17.1

[PATCH -next 3/5] net: decnet: Fix a typo in dn_nsp_in.c

[Lu Wei]

Modify "erronous" to "erroneous" in net/decnet/dn_nsp_in.c.

Reported-by: Hulk Robot 
Signed-off-by: Lu Wei 
---
 net/decnet/dn_nsp_in.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/decnet/dn_nsp_in.c b/net/decnet/dn_nsp_in.c
index c97bdca5ec30..1a12912b88d6 100644
--- a/net/decnet/dn_nsp_in.c
+++ b/net/decnet/dn_nsp_in.c
@@ -520,7 +520,7 @@ static void dn_nsp_linkservice(struct sock *sk, struct 
sk_buff *skb)
fcval = *ptr;
 
/*
-* Here we ignore erronous packets which should really
+* Here we ignore erroneous packets which should really
 * should cause a connection abort. It is not critical
 * for now though.
 */
-- 
2.17.1

[PATCH -next 4/5] net: dsa: Fix a typo in tag_rtl4_a.c

[Lu Wei]

Modify "Apparantly" to "Apparently" in net/dsa/tag_rtl4_a.c..

Reported-by: Hulk Robot 
Signed-off-by: Lu Wei 
---
 net/dsa/tag_rtl4_a.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/dsa/tag_rtl4_a.c b/net/dsa/tag_rtl4_a.c
index e9176475bac8..cf8ac316f4c7 100644
--- a/net/dsa/tag_rtl4_a.c
+++ b/net/dsa/tag_rtl4_a.c
@@ -79,7 +79,7 @@ static struct sk_buff *rtl4a_tag_rcv(struct sk_buff *skb,
 
/* The RTL4 header has its own custom Ethertype 0x8899 and that
 * starts right at the beginning of the packet, after the src
-* ethernet addr. Apparantly skb->data always points 2 bytes in,
+* ethernet addr. Apparently skb->data always points 2 bytes in,
 * behind the Ethertype.
 */
tag = skb->data - 2;
-- 
2.17.1

[PATCH -next 5/5] net: ipv4: Fix some typos

[Lu Wei]

Modify "accomodate" to "accommodate" in net/ipv4/esp4.c.

Reported-by: Hulk Robot 
Signed-off-by: Lu Wei 
---
 net/ipv4/esp4.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/net/ipv4/esp4.c b/net/ipv4/esp4.c
index a3271ec3e162..1ae920b93f39 100644
--- a/net/ipv4/esp4.c
+++ b/net/ipv4/esp4.c
@@ -309,7 +309,7 @@ static struct ip_esp_hdr *esp_output_set_extra(struct 
sk_buff *skb,
   struct esp_output_extra *extra)
 {
/* For ESN we move the header forward by 4 bytes to
-* accomodate the high bits.  We will move it back after
+* accommodate the high bits.  We will move it back after
 * encryption.
 */
if ((x->props.flags & XFRM_STATE_ESN)) {
@@ -854,7 +854,7 @@ static void esp_input_set_header(struct sk_buff *skb, 
__be32 *seqhi)
struct ip_esp_hdr *esph;
 
/* For ESN we move the header forward by 4 bytes to
-* accomodate the high bits.  We will move it back after
+* accommodate the high bits.  We will move it back after
 * decryption.
 */
if ((x->props.flags & XFRM_STATE_ESN)) {
-- 
2.17.1

[PATCH -next 1/5] net: ceph: Fix a typo in osdmap.c

[Lu Wei]

Modify "inital" to "initial" in net/ceph/osdmap.c.

Reported-by: Hulk Robot 
Signed-off-by: Lu Wei 
---
 net/ceph/osdmap.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/ceph/osdmap.c b/net/ceph/osdmap.c
index 2b1dd252f231..c959320c4775 100644
--- a/net/ceph/osdmap.c
+++ b/net/ceph/osdmap.c
@@ -1069,7 +1069,7 @@ static struct crush_work *get_workspace(struct 
workspace_manager *wsm,
 
/*
 * Do not return the error but go back to waiting.  We
-* have the inital workspace and the CRUSH computation
+* have the initial workspace and the CRUSH computation
 * time is bounded so we will get it eventually.
 */
WARN_ON(atomic_read(&wsm->total_ws) < 1);
-- 
2.17.1

[PATCH -next 0/5]Fix some typos

[Lu Wei]

Lu Wei (5):
  net: ceph: Fix a typo in osdmap.c
  net: core: Fix a typo in dev_addr_lists.c
  net: decnet: Fix a typo in dn_nsp_in.c
  net: dsa: Fix a typo in tag_rtl4_a.c
  net: ipv4: Fix some typos

 net/ceph/osdmap.c | 2 +-
 net/core/dev_addr_lists.c | 2 +-
 net/decnet/dn_nsp_in.c| 2 +-
 net/dsa/tag_rtl4_a.c  | 2 +-
 net/ipv4/esp4.c   | 4 ++--
 5 files changed, 6 insertions(+), 6 deletions(-)

-- 
2.17.1

[PATCH] drivers: net: ethernet: struct sk_buff is declared duplicately

[Wan Jiabing]

struct sk_buff has been declared. Remove the duplicate.

Signed-off-by: Wan Jiabing 
---
 drivers/net/ethernet/netronome/nfp/nfp_app.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/net/ethernet/netronome/nfp/nfp_app.h 
b/drivers/net/ethernet/netronome/nfp/nfp_app.h
index 76d13af46a7a..3e9baff07100 100644
--- a/drivers/net/ethernet/netronome/nfp/nfp_app.h
+++ b/drivers/net/ethernet/netronome/nfp/nfp_app.h
@@ -18,7 +18,6 @@ struct netdev_bpf;
 struct netlink_ext_ack;
 struct pci_dev;
 struct sk_buff;
-struct sk_buff;
 struct nfp_app;
 struct nfp_cpp;
 struct nfp_pf;
-- 
2.25.1

[PATCH] drivers: staging: _adapter is declared twice

[Wan Jiabing]

struct _adapter has been declared at 23rd line. 
Remove the duplicate.

Signed-off-by: Wan Jiabing 
---
 drivers/staging/rtl8712/drv_types.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/staging/rtl8712/drv_types.h 
b/drivers/staging/rtl8712/drv_types.h
index 0c4325073c63..976d19cdcf87 100644
--- a/drivers/staging/rtl8712/drv_types.h
+++ b/drivers/staging/rtl8712/drv_types.h
@@ -36,7 +36,6 @@ enum _NIC_VERSION {
RTL8716_NIC
 };
 
-struct _adapter;
 
 struct qos_priv{
/* bit mask option: u-apsd, s-apsd, ts, block ack... */
-- 
2.25.1

linux-next: build warning after merge of the net-next tree

[Stephen Rothwell]

Hi all,

After merging the net-next tree, today's linux-next build (htmldocs)
produced this warning:

Sphinx parallel build error:
docutils.utils.SystemMessage: 
/home/sfr/next/next/Documentation/networking/nf_flowtable.rst:176: (SEVERE/4) 
Unexpected section title.

}
...

Introduced by commit

  143490cde566 ("docs: nf_flowtable: update documentation with enhancements")

-- 
Cheers,
Stephen Rothwell


pgpX14519hqBb.pgp
Description: OpenPGP digital signature

[PATCH -next] f2fs: fix a typo in inode.c

[Ruiqi Gong]

Do a trivial typo fix.
s/runing/running

Reported-by: Hulk Robot 
Signed-off-by: Ruiqi Gong 
---
 fs/f2fs/inode.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/f2fs/inode.c b/fs/f2fs/inode.c
index 349d9cb933ee..5d2253d53f17 100644
--- a/fs/f2fs/inode.c
+++ b/fs/f2fs/inode.c
@@ -698,7 +698,7 @@ int f2fs_write_inode(struct inode *inode, struct 
writeback_control *wbc)
 
/*
 * We need to balance fs here to prevent from producing dirty node pages
-* during the urgent cleaning time when runing out of free sections.
+* during the urgent cleaning time when running out of free sections.
 */
f2fs_update_inode_page(inode);
if (wbc && wbc->nr_to_write)
-- 
2.17.1

Re: [question] insert ko failed because count_plts return 0 when CONFIG_RANDOMIZE_BASE is not set

[chenjun (AM)]

在 2021/3/24 16:29, Ard Biesheuvel 写道:
> On Wed, 24 Mar 2021 at 08:27, chenjun (AM)  wrote:
>>
>> Hi
>>
>> I make a Image for arm64 (without CONFIG_RANDOMIZE_BASE). And a ko (13M)
>> can not be inserted.
>>
> 
> How many large modules have you loaded already? The module region is
> only 128 MB, so if your modules are huge, you may run out of space.
> 
> Please check the kernel VA address and the load address of the module,
> and check whether they are more than 128 MB apart.
>

Thanks Ard

I will check it.

One more question, why is CONFIG_ARM64_MODULE_PLTS depended on 
CONFIG_RANDOMIZE_BASE?

> 
>> WARNING: CPU: 2 PID: 1998 at arch/arm64/kernel/module-plts.c:39
>> module_emit_plt_entry+0x100/0x118
>> ...
>> Call trace:
>> module_emit_plt_entry+0x100/0x118
>> apply_relocate_add+0x34c/0x570
>> ...
>>
>> I think the problem is that:
>> in apply_relocate_add:
>>case R_AARCH64_CALL26:
>>ovf = reloc_insn_imm(RELOC_OP_PREL, loc, val, 2, 26,
>> AARCH64_INSN_IMM_26);
>>
>>if (IS_ENABLED(CONFIG_ARM64_MODULE_PLTS) &&
>>ovf == -ERANGE) {
>>val = module_emit_plt_entry(me, sechdrs,
>> loc, &rel[i], sym); realoc_insn_imm return -ERANGE (because the ko is
>> too big?)
>>
>> in module_emit_plt_entry:
>> WARN_ON(pltsec->plt_num_entries > pltsec->plt_max_entries)
>> pltsec->plt_max_entries is 0 if CONFIG_RANDOMIZE_BASE is not be set.
>>
>> a257e02 arm64/kernel: don't ban ADRP to work around Cortex-A53 erratum
>> #843419
>> static unsigned int count_plts(Elf64_Sym *syms, Elf64_Rela *rela, int
>> num,
>> -  Elf64_Word dstidx)
>> +  Elf64_Word dstidx, Elf_Shdr *dstsec)
>> {
>> ...
>>switch (ELF64_R_TYPE(rela[i].r_info)) {
>>case R_AARCH64_JUMP26:
>>case R_AARCH64_CALL26:
>> +   if (!IS_ENABLED(CONFIG_RANDOMIZE_BASE))
>> +   break;
>> +
>>
>> Why we need break if !IS_ENABLED(CONFIG_RANDOMIZE_BASE)? or any
>> restrictions on ko?
>>
>> I comment out this part of the code. the ko could be inserted, and seems
>> to work well. So is it a accepted way? or any solution for my case?
>>
>> --
>> Regards
>> Chen Jun
>>
> 


-- 
Regards
Chen Jun

Re: [PATCH 2/2] streamline_config.pl: Add softtabstop=4 for vim users

[Masahiro Yamada]

On Wed, Mar 24, 2021 at 10:54 PM Steven Rostedt  wrote:
>
> On Wed, 24 Mar 2021 15:01:13 +0900
> Masahiro Yamada  wrote:
>
> > On Tue, Mar 23, 2021 at 6:40 AM Steven Rostedt  wrote:
> > >
> > > From: "Steven Rostedt (VMware)" 
> > >
> > > The tab stop for Perl files is by default (at least in emacs) to be 4
> > > spaces, where a tab is used for all 8 spaces. Add a local variable comment
> > > to make vim do the same by default, and this will help keep the file
> > > consistent in the future when others edit it via vim and not emacs.
> > >
> > > Signed-off-by: Steven Rostedt (VMware) 
> >
> >
> > Documentation/process/coding-style.rst says "do not do this".
>
> I take that file more as for C code, never took it for Perl ;-)
>
> >
> > Rather, I want to remove this ugly stuff entirely.
> > https://lore.kernel.org/patchwork/patch/1401439/
>
> And I totally agree it does not belong in C code.
>
> >
> > Adding .editorconfig seems OK to me, but
> > Doing this in individual files in an editor-specific
> > manner is a horror.
>
> Is there a way to add this for the directory?
>
> The reason I added this was because of the different ways that vim and
> emacs handle Perl files. I just added this to ktest.pl because I want it to
> be consistent.
>
> The emacs way to edit Perl is to have 4 space indentation, but use tabs for
> every 8 spaces. That is, you have:
>
> (4 spaces)
> (1 tab)
> (1 tab and 4 spaces)
> (2 tabs)
> (2 tabs and 4 spaces)
>
> etc.


The root cause of inconsistency is that
you mix up space-indentation and tab-indentation.
I do not know if it is a standard way either.

For example, scripts/checkpatch.pl uses only tabs,
which I think is more robust.

Unfortunately, we do not have standardized indentation style
for scripts yet, and people can go in any direction.

The editorconfig patch [1] proposed to always use 4-space
indentation for *.pl files.
(that is, do not replace 8 spaces with a tab).

I do not know whether the kernel will adopt .editorconfig or not,
but if that patch is applied, your 1/2 will be a step backward.

My got-feeling is, you will never reach the goal as long as
you adopt a strange indentation style, which is obscure
to other contributors.

Not all people use vim.
I am not interested in 1/2 either.

If you insist on this patch set, apply it to your tree
and send a pull request by yourself.


[1]: https://lore.kernel.org/lkml/20200703073143.423557-1-da...@kdrag0n.dev/



>
> What I found from people who edit Perl code is that they will either just
> indent 8 (with tabs), or just use all spaces. Then you have:
>
> (1 tab and 4 spaces)
> (followed by 12 spaces!)
>
> The way to make vim work the same is to add the softtabspace=4 command.
>
> We can not add this, but then have to either police the patches coming in,
> or constantly clean up the code after the fact.
>
> This code doesn't change much, so I'm fine with that. But for ktest.pl, I'm
> adding it.
>
> -- Steve



-- 
Best Regards
Masahiro Yamada

[PATCH] drivers: gpu: drm: xen_drm_front_drm_info is declared twice

[Wan Jiabing]

struct xen_drm_front_drm_info has been declared. 
Remove the duplicate.

Signed-off-by: Wan Jiabing 
---
 drivers/gpu/drm/xen/xen_drm_front_conn.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/xen/xen_drm_front_conn.h 
b/drivers/gpu/drm/xen/xen_drm_front_conn.h
index 3adacba9a23b..e5f4314899ee 100644
--- a/drivers/gpu/drm/xen/xen_drm_front_conn.h
+++ b/drivers/gpu/drm/xen/xen_drm_front_conn.h
@@ -16,7 +16,6 @@
 struct drm_connector;
 struct xen_drm_front_drm_info;
 
-struct xen_drm_front_drm_info;
 
 int xen_drm_front_conn_init(struct xen_drm_front_drm_info *drm_info,
struct drm_connector *connector);
-- 
2.25.1

[PATCH v5 7/9] ARM: stm32: Add a new SOC - STM32H750

[dillon . minfei]

From: dillon min 

The STM32H750 is a Cortex-M7 MCU running at 480MHz
and containing 128KBytes internal flash, 1MiB SRAM.

Signed-off-by: dillon min 
---

v5: no changes

 arch/arm/mach-stm32/board-dt.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-stm32/board-dt.c b/arch/arm/mach-stm32/board-dt.c
index 011d57b488c2..a766310d8dca 100644
--- a/arch/arm/mach-stm32/board-dt.c
+++ b/arch/arm/mach-stm32/board-dt.c
@@ -17,6 +17,7 @@ static const char *const stm32_compat[] __initconst = {
"st,stm32f746",
"st,stm32f769",
"st,stm32h743",
+   "st,stm32h750",
"st,stm32mp157",
NULL
 };
-- 
2.7.4

[PATCH v5 9/9] dt-bindings: serial: stm32: Use 'type: object' instead of false for 'additionalProperties'

[dillon . minfei]

From: dillon min 

To use additional properties 'bluetooth' on serial, need replace false with
'type: object' for 'additionalProperties' to make it as a node, else will
run into dtbs_check warnings.

'arch/arm/boot/dts/stm32h750i-art-pi.dt.yaml: serial@40004800:
'bluetooth' does not match any of the regexes: 'pinctrl-[0-9]+'

Fixes: af1c2d81695b ("dt-bindings: serial: Convert STM32 UART to json-schema")
Reported-by: kernel test robot 
Tested-by: Valentin Caron 
Signed-off-by: dillon min 
---

v5: accroding to rob's suggestion, replace false with 'type: object'
of 'additionalProperties'.

 Documentation/devicetree/bindings/serial/st,stm32-uart.yaml | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/serial/st,stm32-uart.yaml 
b/Documentation/devicetree/bindings/serial/st,stm32-uart.yaml
index 8631678283f9..865be05083c3 100644
--- a/Documentation/devicetree/bindings/serial/st,stm32-uart.yaml
+++ b/Documentation/devicetree/bindings/serial/st,stm32-uart.yaml
@@ -80,7 +80,8 @@ required:
   - interrupts
   - clocks
 
-additionalProperties: false
+additionalProperties:
+  type: object
 
 examples:
   - |
-- 
2.7.4

[PATCH v5 8/9] pinctrl: stm32: Add STM32H750 MCU pinctrl support

[dillon . minfei]

From: dillon min 

This patch adds STM32H750 pinctrl and GPIO support
since stm32h750 has the same pin alternate functions
with stm32h743, so just reuse the stm32h743's pinctrl
driver

Signed-off-by: dillon min 
---

v5: no changes

 drivers/pinctrl/stm32/Kconfig | 2 +-
 drivers/pinctrl/stm32/pinctrl-stm32h743.c | 3 +++
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/pinctrl/stm32/Kconfig b/drivers/pinctrl/stm32/Kconfig
index f36f29113370..fb1ffc94c57f 100644
--- a/drivers/pinctrl/stm32/Kconfig
+++ b/drivers/pinctrl/stm32/Kconfig
@@ -35,7 +35,7 @@ config PINCTRL_STM32F769
select PINCTRL_STM32
 
 config PINCTRL_STM32H743
-   bool "STMicroelectronics STM32H743 pin control" if COMPILE_TEST && 
!MACH_STM32H743
+   bool "STMicroelectronics STM32H743/STM32H750 pin control" if 
COMPILE_TEST && !MACH_STM32H743
depends on OF && HAS_IOMEM
default MACH_STM32H743
select PINCTRL_STM32
diff --git a/drivers/pinctrl/stm32/pinctrl-stm32h743.c 
b/drivers/pinctrl/stm32/pinctrl-stm32h743.c
index ffe7b5271506..700206c7bc11 100644
--- a/drivers/pinctrl/stm32/pinctrl-stm32h743.c
+++ b/drivers/pinctrl/stm32/pinctrl-stm32h743.c
@@ -1966,6 +1966,9 @@ static const struct of_device_id stm32h743_pctrl_match[] 
= {
.compatible = "st,stm32h743-pinctrl",
.data = &stm32h743_match_data,
},
+   {   .compatible = "st,stm32h750-pinctrl",
+   .data = &stm32h743_match_data,
+   },
{ }
 };
 
-- 
2.7.4

[PATCH v5 6/9] ARM: dts: stm32: add support for art-pi board based on stm32h750xbh6

[dillon . minfei]

From: dillon min 

This patchset has following changes:

- introduce stm32h750.dtsi to support stm32h750 value line
- add stm32h750i-art-pi.dtb (arch/arm/boot/dts/Makefile)
- add dts binding usart3 for bt, uart4 for console
  usart3/uart4 pinctrl in stm32h7-pinctrl.dtsi
  usart3/uart4 register in stm32h743.dtsi
- add dts binding sdmmc2 for wifi
  sdmmc2 pinctrl in stm32h7-pinctrl.dtsi
  sdmmc2 register in stm32h743.dtsi
- add spi1 pinctrl in stm32h7-pinctrl.dtsi for spi flash
- add stm32h750-art-pi.dts to support art-pi board
- add pinctrl: pin-controller@5802 {} to fix dtbs_check warrnings

art-pi board component:
- 8MiB qspi flash
- 16MiB spi flash
- 32MiB sdram
- ap6212 wifi&bt&fm

the detail board information can be found at:
https://art-pi.gitee.io/website/

Signed-off-by: dillon min 
---

v5: no changes

 arch/arm/boot/dts/Makefile  |   1 +
 arch/arm/boot/dts/stm32h743.dtsi| 153 -
 arch/arm/boot/dts/stm32h750.dtsi|   6 +
 arch/arm/boot/dts/stm32h750i-art-pi.dts | 229 
 4 files changed, 387 insertions(+), 2 deletions(-)
 create mode 100644 arch/arm/boot/dts/stm32h750.dtsi
 create mode 100644 arch/arm/boot/dts/stm32h750i-art-pi.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 8e5d4ab4e75e..a19c5ab9df84 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -1071,6 +1071,7 @@ dtb-$(CONFIG_ARCH_STM32) += \
stm32746g-eval.dtb \
stm32h743i-eval.dtb \
stm32h743i-disco.dtb \
+   stm32h750i-art-pi.dtb \
stm32mp153c-dhcom-drc02.dtb \
stm32mp157a-avenger96.dtb \
stm32mp157a-dhcor-avenger96.dtb \
diff --git a/arch/arm/boot/dts/stm32h743.dtsi b/arch/arm/boot/dts/stm32h743.dtsi
index 4ebffb0a45a3..4379063d36a2 100644
--- a/arch/arm/boot/dts/stm32h743.dtsi
+++ b/arch/arm/boot/dts/stm32h743.dtsi
@@ -135,6 +135,22 @@
clocks = <&rcc USART2_CK>;
};
 
+   usart3: serial@40004800 {
+   compatible = "st,stm32h7-uart";
+   reg = <0x40004800 0x400>;
+   interrupts = <39>;
+   status = "disabled";
+   clocks = <&rcc USART3_CK>;
+   };
+
+   uart4: serial@40004c00 {
+   compatible = "st,stm32h7-uart";
+   reg = <0x40004c00 0x400>;
+   interrupts = <52>;
+   status = "disabled";
+   clocks = <&rcc UART4_CK>;
+   };
+
i2c1: i2c@40005400 {
compatible = "st,stm32f7-i2c";
#address-cells = <1>;
@@ -159,7 +175,7 @@
status = "disabled";
};
 
-   i2c3: i2c@40005C00 {
+   i2c3: i2c@40005c00 {
compatible = "st,stm32f7-i2c";
#address-cells = <1>;
#size-cells = <0>;
@@ -368,6 +384,20 @@
max-frequency = <12000>;
};
 
+   sdmmc2: mmc@48022400 {
+   compatible = "arm,pl18x", "arm,primecell";
+   arm,primecell-periphid = <0x10153180>;
+   reg = <0x48022400 0x400>;
+   interrupts = <124>;
+   interrupt-names = "cmd_irq";
+   clocks = <&rcc SDMMC2_CK>;
+   clock-names = "apb_pclk";
+   resets = <&rcc STM32H7_AHB2_RESET(SDMMC2)>;
+   cap-sd-highspeed;
+   cap-mmc-highspeed;
+   max-frequency = <12000>;
+   };
+
exti: interrupt-controller@5800 {
compatible = "st,stm32h7-exti";
interrupt-controller;
@@ -392,7 +422,7 @@
status = "disabled";
};
 
-   i2c4: i2c@58001C00 {
+   i2c4: i2c@58001c00 {
compatible = "st,stm32f7-i2c";
#address-cells = <1>;
#size-cells = <0>;
@@ -555,6 +585,125 @@
snps,pbl = <8>;
status = "disabled";
};
+
+   pinctrl: pin-controller@5802 {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges = <0 0x5802 0x3000>;
+   interrupt-parent = <&exti>;
+   st,syscfg = <&syscfg 0x8>;
+   pins-are-numbered;
+
+   gpioa: gpio@5802 {
+   gpio-controller;
+   #gpio-cells = <2>;
+   reg = <0x0 0x400>;
+   clocks = <&rcc GPIOA_CK>;
+   

[PATCH v5 4/9] ARM: dts: stm32: introduce stm32h7-pinctrl.dtsi to support stm32h750

[dillon . minfei]

From: dillon min 

This patch is intend to add support stm32h750 value line,
just add stm32h7-pinctrl.dtsi for extending, with following changes:

- rename stm32h743-pinctrl.dtsi to stm32h7-pinctrl.dtsi
- move compatible string "st,stm32h743-pinctrl" from stm32h7-pinctrl.dtsi
  to stm32h743-pinctrl.dtsi
- move 'pin-controller' from stm32h7-pinctrl.dtsi to stm32h743.dtsi, to
  fix make dtbs_check warrnings
  arch/arm/boot/dts/stm32h750i-art-pi.dt.yaml: soc: 'i2c@40005C00',
  'i2c@58001C00' do not match any of the regexes:
  '@(0|[1-9a-f][0-9a-f]*)$', '^[^@]+$', 'pinctrl-[0-9]+'

Signed-off-by: dillon min 
---

v5: no changes

 arch/arm/boot/dts/stm32h7-pinctrl.dtsi   | 274 +++
 arch/arm/boot/dts/stm32h743-pinctrl.dtsi | 307 +--
 2 files changed, 280 insertions(+), 301 deletions(-)
 create mode 100644 arch/arm/boot/dts/stm32h7-pinctrl.dtsi

diff --git a/arch/arm/boot/dts/stm32h7-pinctrl.dtsi 
b/arch/arm/boot/dts/stm32h7-pinctrl.dtsi
new file mode 100644
index ..fbab41a01af5
--- /dev/null
+++ b/arch/arm/boot/dts/stm32h7-pinctrl.dtsi
@@ -0,0 +1,274 @@
+/*
+ * Copyright 2017 - Alexandre Torgue 
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include 
+
+&pinctrl {
+   i2c1_pins_a: i2c1-0 {
+   pins {
+   pinmux = , /* I2C1_SCL */
+; /* I2C1_SDA */
+   bias-disable;
+   drive-open-drain;
+   slew-rate = <0>;
+   };
+   };
+
+   ethernet_rmii: rmii-0 {
+   pins {
+   pinmux = ,
+,
+,
+,
+,
+,
+,
+,
+;
+   slew-rate = <2>;
+   };
+   };
+
+   sdmmc1_b4_pins_a: sdmmc1-b4-0 {
+   pins {
+   pinmux = , /* SDMMC1_D0 */
+, /* SDMMC1_D1 */
+, /* SDMMC1_D2 */
+, /* SDMMC1_D3 */
+, /* SDMMC1_CK */
+; /* SDMMC1_CMD */
+   slew-rate = <3>;
+   drive-push-pull;
+   bias-disable;
+   };
+   };
+
+   sdmmc1_b4_od_pins_a: sdmmc1-b4-od-0 {
+   pins1 {
+   pinmux = , /* SDMMC1_D0 */
+, /* SDMMC1_D1 */
+, /* SDMMC1_D2 */
+, /* SDMMC1_D3 */
+; /* SDMMC1_CK */
+   slew-rate = <3>;
+   drive-push-pull;
+   bias-disable;
+   };
+   pins2{
+   pinmux = ; /* SDMMC1_CMD */
+  

[PATCH v5 5/9] ARM: dts: stm32: add stm32h750-pinctrl.dtsi

[dillon . minfei]

From: dillon min 

This patch add stm32h750-pinctrl.dtsi which just
reference stm32h7-pinctrl.dtsi

Signed-off-by: dillon min 
---

v5: no changes

 arch/arm/boot/dts/stm32h750-pinctrl.dtsi | 12 
 1 file changed, 12 insertions(+)
 create mode 100644 arch/arm/boot/dts/stm32h750-pinctrl.dtsi

diff --git a/arch/arm/boot/dts/stm32h750-pinctrl.dtsi 
b/arch/arm/boot/dts/stm32h750-pinctrl.dtsi
new file mode 100644
index ..ef8c4d881dba
--- /dev/null
+++ b/arch/arm/boot/dts/stm32h750-pinctrl.dtsi
@@ -0,0 +1,12 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause)
+/*
+ * Copyright (C) STMicroelectronics 2021 - All Rights Reserved
+ * Author: Dillon Min   for STMicroelectronics.
+ */
+
+#include "stm32h7-pinctrl.dtsi"
+
+&pinctrl{
+   compatible = "st,stm32h750-pinctrl";
+};
+
-- 
2.7.4

[PATCH v5 1/9] Documentation: arm: stm32: Add stm32h750 value line doc

[dillon . minfei]

From: dillon min 

This patchset add support for soc stm32h750, stm32h750 has mirror
different from stm32h743

itemstm32h743 stm32h750
flash size: 2MiB  128KiB
adc:none  3
crypto-hash:none  aes/hamc/des/tdes/md5/sha

detail information can be found at:
https://www.st.com/en/microcontrollers-microprocessors/stm32h750-value-line.html

Signed-off-by: dillon min 
---

v5: no changes

 Documentation/arm/index.rst|  1 +
 Documentation/arm/stm32/stm32h750-overview.rst | 34 ++
 2 files changed, 35 insertions(+)
 create mode 100644 Documentation/arm/stm32/stm32h750-overview.rst

diff --git a/Documentation/arm/index.rst b/Documentation/arm/index.rst
index b4bea32472b6..d4f34ae9e6f4 100644
--- a/Documentation/arm/index.rst
+++ b/Documentation/arm/index.rst
@@ -52,6 +52,7 @@ SoC-specific documents
stm32/stm32f746-overview
stm32/overview
stm32/stm32h743-overview
+   stm32/stm32h750-overview
stm32/stm32f769-overview
stm32/stm32f429-overview
stm32/stm32mp157-overview
diff --git a/Documentation/arm/stm32/stm32h750-overview.rst 
b/Documentation/arm/stm32/stm32h750-overview.rst
new file mode 100644
index ..0e51235c9547
--- /dev/null
+++ b/Documentation/arm/stm32/stm32h750-overview.rst
@@ -0,0 +1,34 @@
+==
+STM32H750 Overview
+==
+
+Introduction
+
+
+The STM32H750 is a Cortex-M7 MCU aimed at various applications.
+It features:
+
+- Cortex-M7 core running up to @480MHz
+- 128K internal flash, 1MBytes internal RAM
+- FMC controller to connect SDRAM, NOR and NAND memories
+- Dual mode QSPI
+- SD/MMC/SDIO support
+- Ethernet controller
+- USB OTFG FS & HS controllers
+- I2C, SPI, CAN busses support
+- Several 16 & 32 bits general purpose timers
+- Serial Audio interface
+- LCD controller
+- HDMI-CEC
+- SPDIFRX
+- DFSDM
+
+Resources
+-
+
+Datasheet and reference manual are publicly available on ST website 
(STM32H750_).
+
+.. _STM32H750: 
https://www.st.com/en/microcontrollers-microprocessors/stm32h750-value-line.html
+
+:Authors: Dillon Min 
+
-- 
2.7.4

[PATCH v5 0/9] ARM: STM32: add art-pi(stm32h750xbh6) board support

[dillon . minfei]

From: dillon min 

This patchset intend to add art-pi board support, this board developed
by rt-thread(https://www.rt-thread.org/).

Board resources:
8MiB QSPI flash
16MiB SPI flash
32MiB SDRAM
AP6212 wifi,bt,fm comb

sw context:
- as stm32h750 just has 128k bytes internal flash, so running a fw on
  internal flash to download u-boot/kernel to qspi flash, boot
  u-boot/kernel from qspi flash. this fw is based on rt-thread.
- kernel can be xip on qspi flash or load to sdram
- root filesystem is jffs2(created by buildroot), stored on spi flash

to support the boad, add following changes.
- fix r0-r3, r12 register restore failed after svc call,
- add dts binding
- update yaml doc

---
changes in v5:
- accroding to rob's suggestion, replace false with 'type: object'
  of 'additionalProperties'.
- add Tested-by: Valentin Caron 

changes in v4:
- use unevaluatedProperties: false to fix dtbs_check warrnings instead of
  add 'bluetooth' in st,stm32-uart.yaml

changes in v3:
- fix dtbs_check warrning: (8002cbd78fd5 and 4bc21d3dd678)
  >> arch/arm/boot/dts/stm32h743i-eval.dt.yaml: soc: pin-controller:
 {'type': 'object'} is not allowed for {'#address-cells': [[1]], 
'#size-cells':
 [[1]], 'ranges': [[0,

  >> arch/arm/boot/dts/stm32h743i-eval.dt.yaml: soc: 'i2c@40005C00',
 'i2c@58001C00' do not match any of the regexes: '@(0|[1-9a-f][0-9a-f]*)$',
 '^[^@]+$', 'pinctrl-[0-9]+'
  >> arch/arm/boot/dts/stm32h750i-art-pi.dt.yaml: serial@40004800:
 'bluetooth' does not match any of the regexes: 'pinctrl-[0-9]+'

changes in v2:
- reorganize the pinctrl device tree about
  stm32h7-pinctrl/stm32h743/750-pinctrl
  stm32h7-pinctrl.dtsi --> stm32h743-pinctrl.dtsi --> stm32h743i-disco.dts
 |  |-> stm32h743i-eval.dts
 |-> stm32h750-pinctrl.dtsi --> stm32h750i-art-pi.dts
  same to the stm32f7/f4's pinctrl style
- fix author name/copyright mistake
- add compatible string st,stm32h750-pinctrl to pinctl-stm32h743.c as they
  have same pin alternate functions, update Kconfig description
- make item in stm32h750i-art-pi.dts sort by letter

*** BLURB HERE ***

dillon min (9):
  Documentation: arm: stm32: Add stm32h750 value line doc
  dt-bindings: arm: stm32: Add compatible strings for ART-PI board
  dt-bindings: pinctrl: stm32: Add stm32h750 pinctrl
  ARM: dts: stm32: introduce stm32h7-pinctrl.dtsi to support stm32h750
  ARM: dts: stm32: add stm32h750-pinctrl.dtsi
  ARM: dts: stm32: add support for art-pi board based on stm32h750xbh6
  ARM: stm32: Add a new SOC - STM32H750
  pinctrl: stm32: Add STM32H750 MCU pinctrl support
  dt-bindings: serial: stm32: Use 'type: object' instead of false for
'additionalProperties'

 Documentation/arm/index.rst|   1 +
 Documentation/arm/stm32/stm32h750-overview.rst |  34 +++
 .../devicetree/bindings/arm/stm32/stm32.yaml   |   4 +
 .../bindings/pinctrl/st,stm32-pinctrl.yaml |   1 +
 .../devicetree/bindings/serial/st,stm32-uart.yaml  |   3 +-
 arch/arm/boot/dts/Makefile |   1 +
 arch/arm/boot/dts/stm32h7-pinctrl.dtsi | 274 ++
 arch/arm/boot/dts/stm32h743-pinctrl.dtsi   | 307 +
 arch/arm/boot/dts/stm32h743.dtsi   | 153 +-
 arch/arm/boot/dts/stm32h750-pinctrl.dtsi   |  12 +
 arch/arm/boot/dts/stm32h750.dtsi   |   6 +
 arch/arm/boot/dts/stm32h750i-art-pi.dts| 229 +++
 arch/arm/mach-stm32/board-dt.c |   1 +
 drivers/pinctrl/stm32/Kconfig  |   2 +-
 drivers/pinctrl/stm32/pinctrl-stm32h743.c  |   3 +
 15 files changed, 726 insertions(+), 305 deletions(-)
 create mode 100644 Documentation/arm/stm32/stm32h750-overview.rst
 create mode 100644 arch/arm/boot/dts/stm32h7-pinctrl.dtsi
 create mode 100644 arch/arm/boot/dts/stm32h750-pinctrl.dtsi
 create mode 100644 arch/arm/boot/dts/stm32h750.dtsi
 create mode 100644 arch/arm/boot/dts/stm32h750i-art-pi.dts

-- 
2.7.4

Re: [PATCH v7 00/14] Tegra XHCI controller ELPG support

[Vinod Koul]

On 24-03-21, 14:32, Thierry Reding wrote:
> On Wed, Mar 24, 2021 at 01:39:32PM +0100, Thierry Reding wrote:
> > On Fri, Feb 05, 2021 at 05:22:29PM +0100, Greg KH wrote:
> > > On Fri, Feb 05, 2021 at 05:15:21PM +0100, Thierry Reding wrote:
> > > > On Wed, Jan 20, 2021 at 03:34:00PM +0800, JC Kuo wrote:
> > > > > Tegra XHCI controler can be placed in ELPG (Engine Level PowerGated)
> > > > > state for power saving when all of the connected USB devices are in
> > > > > suspended state. This patch series includes clk, phy and pmc changes
> > > > > that are required for properly place controller in ELPG and bring
> > > > > controller out of ELPG.
> > > > > 
> > > > > JC Kuo (14):
> > > > >   clk: tegra: Add PLLE HW power sequencer control
> > > > >   clk: tegra: Don't enable PLLE HW sequencer at init
> > > > >   phy: tegra: xusb: Move usb3 port init for Tegra210
> > > > >   phy: tegra: xusb: Rearrange UPHY init on Tegra210
> > > > >   phy: tegra: xusb: Add Tegra210 lane_iddq operation
> > > > >   phy: tegra: xusb: Add sleepwalk and suspend/resume
> > > > >   soc/tegra: pmc: Provide USB sleepwalk register map
> > > > >   arm64: tegra210: XUSB PADCTL add "nvidia,pmc" prop
> > > > >   dt-bindings: phy: tegra-xusb: Add nvidia,pmc prop
> > > > >   phy: tegra: xusb: Add wake/sleepwalk for Tegra210
> > > > >   phy: tegra: xusb: Tegra210 host mode VBUS control
> > > > >   phy: tegra: xusb: Add wake/sleepwalk for Tegra186
> > > > >   usb: host: xhci-tegra: Unlink power domain devices
> > > > >   xhci: tegra: Enable ELPG for runtime/system PM
> > > > > 
> > > > >  .../phy/nvidia,tegra124-xusb-padctl.txt   |1 +
> > > > >  arch/arm64/boot/dts/nvidia/tegra210.dtsi  |1 +
> > > > >  drivers/clk/tegra/clk-pll.c   |   12 -
> > > > >  drivers/clk/tegra/clk-tegra210.c  |   53 +-
> > > > >  drivers/phy/tegra/xusb-tegra186.c |  558 -
> > > > >  drivers/phy/tegra/xusb-tegra210.c | 1889 
> > > > > +
> > > > >  drivers/phy/tegra/xusb.c  |   92 +-
> > > > >  drivers/phy/tegra/xusb.h  |   22 +-
> > > > >  drivers/soc/tegra/pmc.c   |   94 +
> > > > >  drivers/usb/host/xhci-tegra.c |  613 --
> > > > >  include/linux/clk/tegra.h |4 +-
> > > > >  include/linux/phy/tegra/xusb.h|   10 +-
> > > > >  12 files changed, 2784 insertions(+), 565 deletions(-)
> > > > > 
> > > > > v5 "phy: tegra: xusb: tegra210: Do not reset UPHY PLL" is moved
> > > > > into v6 "phy: tegra: xusb: Rearrange UPHY init on Tegra210"
> > > > 
> > > > Mike, Stephen,
> > > > 
> > > > could you guys take a look at the two clk patches here and give an
> > > > Acked-by? There's build-time dependencies throughout the series, so it'd
> > > > be good if they can all go through either the PHY or USB trees.
> > > > 
> > > > Kishon, Greg,
> > > > 
> > > > any comments on these patches? Unfortunately, the USB patches in this
> > > > series have a build-time dependency on the PHY patches, so this should
> > > > all go through one tree. Since this all culminates in the XHCI driver,
> > > > merging this through the USB tree might be best, provided that Kishon
> > > > provides his Acked-by on the PHY patches.
> > > > 
> > > > Alternatively, I can create a set of branches with the correct
> > > > dependencies and send out pull requests for the three subsystems if
> > > > that's preferrable.
> > > 
> > > I have no objection for the usb patches to go through your tree as they
> > > are hardware-specific.
> > 
> > Kishon,
> > 
> > I haven't heard back from you on this yet. We missed v5.12 but I'd like
> > to get this into v5.13 since it's the last missing piece to get suspend
> > and resume working properly on a number of boards.
> > 
> > Are you okay if I take this through the Tegra tree to satisfy the
> > interdependencies between clk, PHY and USB patches? I've already got
> > Acked-by's from the clock and USB maintainers.
> > 
> > I want to tentatively take this into linux-next to give it a bit of soak
> > time before the ARM SoC -rc6 cut-off. Please let me know if you'd prefer
> > to apply these to your tree so I can back them out of the Tegra tree
> > again.
> 
> Also adding Vinod for visibility and in case Kishon's too busy.

Yes please CC me on all things phy (MAINTAINERS should have told you so)

If you can resend me and cc linux-...@lists.infradead.org, I would take
a look. FWIW since this goes thru Greg, the window closes earlier than
merge window

-- 
~Vinod

Re: [RESEND PATCH V6 2/2] PCI: sprd: Add support for Unisoc SoCs' PCIe controller

[Chunyan Zhang]

Hi Bjorn,

On Wed, 24 Mar 2021 at 04:30, Bjorn Helgaas  wrote:
>
> On Mon, Mar 22, 2021 at 05:18:31PM +0800, Chunyan Zhang wrote:
> > From: Hongtao Wu 
> >
> > This series adds PCIe controller driver for Unisoc SoCs.
> > This controller is based on DesignWare PCIe IP.
> >
> > Signed-off-by: Hongtao Wu 
> > Signed-off-by: Chunyan Zhang 
> > ---
> >  drivers/pci/controller/dwc/Kconfig |  12 +
> >  drivers/pci/controller/dwc/Makefile|   1 +
> >  drivers/pci/controller/dwc/pcie-sprd.c | 292 +
> >  3 files changed, 305 insertions(+)
> >  create mode 100644 drivers/pci/controller/dwc/pcie-sprd.c
> >
> > diff --git a/drivers/pci/controller/dwc/Kconfig 
> > b/drivers/pci/controller/dwc/Kconfig
> > index 22c5529e9a65..61f0b79f963d 100644
> > --- a/drivers/pci/controller/dwc/Kconfig
> > +++ b/drivers/pci/controller/dwc/Kconfig
> > @@ -318,4 +318,16 @@ config PCIE_AL
> > required only for DT-based platforms. ACPI platforms with the
> > Annapurna Labs PCIe controller don't need to enable this.
> >
> > +config PCIE_SPRD
>
> Maybe you want PCIE_SPRD_HOST for this one so there's room for a
> PCIE_SPRD_EP someday?

yes, it makes sense, will address.

>
> > + tristate "Unisoc PCIe controller - Host Mode"
> > + depends on ARCH_SPRD || COMPILE_TEST
> > + depends on PCI_MSI_IRQ_DOMAIN
> > + select PCIE_DW_HOST
> > + help
> > +   Unisoc PCIe controller uses the DesignWare core. It can be 
> > configured
> > +   as an Endpoint (EP) or a Root complex (RC). In order to enable host
> > +   mode (the controller works as RC), PCIE_SPRD must be selected.
> > +   Say Y or M here if you want to PCIe RC controller support on Unisoc
> > +   SoCs.
> > +
> >  endmenu
> > diff --git a/drivers/pci/controller/dwc/Makefile 
> > b/drivers/pci/controller/dwc/Makefile
> > index a751553fa0db..eb546e97c14a 100644
> > --- a/drivers/pci/controller/dwc/Makefile
> > +++ b/drivers/pci/controller/dwc/Makefile
> > @@ -20,6 +20,7 @@ obj-$(CONFIG_PCI_MESON) += pci-meson.o
> >  obj-$(CONFIG_PCIE_TEGRA194) += pcie-tegra194.o
> >  obj-$(CONFIG_PCIE_UNIPHIER) += pcie-uniphier.o
> >  obj-$(CONFIG_PCIE_UNIPHIER_EP) += pcie-uniphier-ep.o
> > +obj-$(CONFIG_PCIE_SPRD) += pcie-sprd.o
> >
> >  # The following drivers are for devices that use the generic ACPI
> >  # pci_root.c driver but don't support standard ECAM config access.
> > diff --git a/drivers/pci/controller/dwc/pcie-sprd.c 
> > b/drivers/pci/controller/dwc/pcie-sprd.c
> > new file mode 100644
> > index ..2ccb99eda24f
> > --- /dev/null
> > +++ b/drivers/pci/controller/dwc/pcie-sprd.c
> > @@ -0,0 +1,292 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * PCIe host controller driver for Unisoc SoCs
> > + *
> > + * Copyright (C) 2020-2021 Unisoc, Inc.
> > + *
> > + * Author: Hongtao Wu 
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#include "pcie-designware.h"
> > +
> > +/* aon apb syscon */
> > +#define IPA_ACCESS_CFG   0xcd8
> > +#define  AON_ACCESS_PCIE_EN  BIT(1)
> > +
> > +/* pmu apb syscon */
> > +#define SNPS_PCIE3_SLP_CTRL  0xac
> > +#define  PERST_N_ASSERT  BIT(1)
> > +#define  PERST_N_AUTO_EN BIT(0)
> > +#define PD_PCIE_CFG_00x3e8
> > +#define  PCIE_FORCE_SHUTDOWN BIT(25)
> > +
> > +#define PCIE_SS_REG_BASE 0xE00
>
> Pick uppercase or lowercase for your hex constants and use it
> consistently.
>
> > +#define APB_CLKFREQ_TIMEOUT  0x4
> > +#define  BUSERR_EN   BIT(12)
> > +#define  APB_TIMER_DIS   BIT(10)
> > +#define  APB_TIMER_LIMIT GENMASK(31, 16)
> > +
> > +#define PE0_GEN_CTRL_3   0x58
> > +#define  LTSSM_ENBIT(0)
> > +
> > +struct sprd_pcie_soc_data {
> > + u32 syscon_offset;
> > +};
> > +
> > +static const struct sprd_pcie_soc_data ums9520_syscon_data = {
> > + .syscon_offset = 0x1000,/* The offset of set/clear register */
> > +};
> > +
> > +struct sprd_pcie {
> > + u32 syscon_offset;
> > + struct device   *dev;
> > + struct dw_pcie  *pci;
> > + struct regmap   *aon_map;
> > + struct regmap   *pmu_map;
> > + const struct sprd_pcie_soc_data *socdata;
> > +};
> > +
> > +enum sprd_pcie_syscon_type {
> > + normal_syscon,  /* it's not a set/clear register */
> > + set_syscon, /* set a set/clear register */
> > + clr_syscon, /* clear a set/clear register */
> > +};
> > +
> > +static void sprd_pcie_buserr_enable(struct dw_pcie *pci)
> > +{
> > + u32 val;
> > +
> > + val = dw_pcie_readl_dbi(pci, PCIE_SS_REG_BASE + APB_CLKFREQ_TIMEOUT);
> > + val &= ~APB_TIMER_DIS;
> > + val |= BUSERR_EN;
> > + val |= APB_TIMER_LIMIT & (0x1f4 << 16);
> > + dw_pcie_writel_dbi(pci, PCIE_SS_REG_BASE + APB_CLKFREQ_TIMEOUT, val);
> > +}
>

Re: [PATCH 2/3] dt-bindings: input: pm8941-pwrkey: Convert power key bindings to yaml

[skakit]

Hi Rob,

On 2021-03-05 20:10, Rob Herring wrote:

On Fri, Mar 05, 2021 at 11:08:40AM +0530, satya priya wrote:

Convert power key bindings from .txt to .yaml format.

Signed-off-by: satya priya 
---
 .../bindings/input/qcom,pm8941-pwrkey.txt  | 53 
---
 .../bindings/input/qcom,pm8941-pwrkey.yaml | 76 
++

 2 files changed, 76 insertions(+), 53 deletions(-)
 delete mode 100644 
Documentation/devicetree/bindings/input/qcom,pm8941-pwrkey.txt
 create mode 100644 
Documentation/devicetree/bindings/input/qcom,pm8941-pwrkey.yaml


You need to convert the main pm8941 binding first if not done already
and then reference this binding from it.



Okay.


And let's have 1 complete example instead of fragments.



Sure.



diff --git 
a/Documentation/devicetree/bindings/input/qcom,pm8941-pwrkey.txt 
b/Documentation/devicetree/bindings/input/qcom,pm8941-pwrkey.txt

deleted file mode 100644
index 34ab576..000
--- a/Documentation/devicetree/bindings/input/qcom,pm8941-pwrkey.txt
+++ /dev/null
@@ -1,53 +0,0 @@
-Qualcomm PM8941 PMIC Power Key
-
-PROPERTIES
-
-- compatible:
-   Usage: required
-   Value type: 
-   Definition: must be one of:
-   "qcom,pm8941-pwrkey"
-   "qcom,pm8941-resin"
-
-- reg:
-   Usage: required
-   Value type: 
-   Definition: base address of registers for block
-
-- interrupts:
-   Usage: required
-   Value type: 
-   Definition: key change interrupt; The format of the specifier is
-   defined by the binding document describing the node's
-   interrupt parent.
-
-- debounce:
-   Usage: optional
-   Value type: 
-	Definition: time in microseconds that key must be pressed or 
released

-   for state change interrupt to trigger.
-
-- bias-pull-up:
-   Usage: optional
-   Value type: 
-	Definition: presence of this property indicates that the KPDPWR_N 
pin

-   should be configured for pull up.
-
-- linux,code:
-   Usage: optional
-   Value type: 
-   Definition: The input key-code associated with the power key.
-   Use the linux event codes defined in
-   include/dt-bindings/input/linux-event-codes.h
-   When property is omitted KEY_POWER is assumed.
-
-EXAMPLE
-
-   pwrkey@800 {
-   compatible = "qcom,pm8941-pwrkey";
-   reg = <0x800>;
-   interrupts = <0x0 0x8 0 IRQ_TYPE_EDGE_BOTH>;
-   debounce = <15625>;
-   bias-pull-up;
-   linux,code = ;
-   };
diff --git 
a/Documentation/devicetree/bindings/input/qcom,pm8941-pwrkey.yaml 
b/Documentation/devicetree/bindings/input/qcom,pm8941-pwrkey.yaml

new file mode 100644
index 000..302866d
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/qcom,pm8941-pwrkey.yaml
@@ -0,0 +1,76 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/input/qcom,pm8941-pwrkey.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm PM8941 PMIC Power Key
+
+maintainers:
+ - Courtney Cavin 
+ - Vinod Koul 
+
+properties:
+  compatible:
+enum:
+  - qcom,pm8941-pwrkey
+  - qcom,pm8941-resin
+
+  interrupts:
+description: |
+  Key change interrupt; The format of the specifier is
+  defined by the binding document describing the node's
+  interrupt parent.
+
+  debounce:
+description: |
+  Time in microseconds that key must be pressed or
+  released for state change interrupt to trigger.
+$ref: /schemas/types.yaml#/definitions/uint32
+
+  bias-pull-up:
+description: |
+   Presence of this property indicates that the KPDPWR_N
+   pin should be configured for pull up.
+$ref: /schemas/types.yaml#/definitions/flag
+
+  linux,code:
+description: |
+   The input key-code associated with the power key.
+   Use the linux event codes defined in
+   include/dt-bindings/input/linux-event-codes.h
+   When property is omitted KEY_POWER is assumed.
+$ref: /schemas/types.yaml#/definitions/uint32


Already has a type definition. Need to reference input.yaml.



Okay.


+
+required:
+ - compatible
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+   #include 
+   #include 
+   #include 
+   spmi_bus: spmi@c44 {
+ reg = <0x0c44 0x1100>;
+ #address-cells = <2>;
+ #size-cells = <0>;
+ pmk8350: pmic@0 {
+   reg = <0x0 SPMI_USID>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   pmk8350_pon: pon_hlos@1300 {
+ reg = <0x1300>;
+ pwrkey {
+compatible = "qcom,pm8941-pwrkey";
+interrupts = < 0x0 0x8 0 IRQ_TYPE_EDGE_BOTH >;
+debounce = <15625>;
+bias-pull-up;
+linux,code = ;
+ };
+   };
+ };
+   };
+...
--
QUALCOMM

Re: [PATCH] dt-bindings: mailbox: Add compatible for SM8350 IPCC

[Vinod Koul]

On 12-03-21, 11:28, Bjorn Andersson wrote:
> On Thu 11 Mar 23:12 CST 2021, Vinod Koul wrote:
> 
> Adding Jassi as recipient. Please let Vinod know if you want him to
> resend this patch to you. (I send a patch for MAINTAINERS yesterday)

Jassi, should I resend or you can pick from lore?
> 
> > Add the compatible string for SM8350 IPCC block on this SoC
> > 
> 
> Reviewed-by: Bjorn Andersson 
> 
> Regards,
> Bjorn
> 
> > Signed-off-by: Vinod Koul 
> > ---
> >  Documentation/devicetree/bindings/mailbox/qcom-ipcc.yaml | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/mailbox/qcom-ipcc.yaml 
> > b/Documentation/devicetree/bindings/mailbox/qcom-ipcc.yaml
> > index 168beeb7e9f7..fe17ba9b84f2 100644
> > --- a/Documentation/devicetree/bindings/mailbox/qcom-ipcc.yaml
> > +++ b/Documentation/devicetree/bindings/mailbox/qcom-ipcc.yaml
> > @@ -25,6 +25,7 @@ properties:
> >  items:
> >- enum:
> >- qcom,sm8250-ipcc
> > +  - qcom,sm8350-ipcc
> >- const: qcom,ipcc
> >  
> >reg:
> > -- 
> > 2.26.2
> > 

-- 
~Vinod

Re: [PATCH 1/2] leds: leds-multi-gpio: Add multiple GPIOs LED driver

[Hermes Zhang]

Hi Marek,

On 3/24/21 5:34 PM, Marek Behun wrote:
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
> Why do you include slab.h?
Yeah, I will clean it in next commit.
>> +
>> +
>> +static void multi_gpio_led_set(struct led_classdev *led_cdev,
>> +enum led_brightness value)
>> +{
>> +struct multi_gpio_led_priv *priv;
>> +int idx;
>> +
>> +DECLARE_BITMAP(values, MAX_GPIO_NUM);
>> +
>> +priv = container_of(led_cdev, struct multi_gpio_led_priv, cdev);
>> +
>> +idx = (value - LED_OFF) * priv->nr_states / (LED_FULL + 1);
> LED_FULL / LED_OFF are deprecated, don't use them.

Then could I use just 0 (instead LED_OFF) and led_cdev->max_brightness

(instead of LED_FULL) here? The idea here is map the states defined in dts

to the full brightness range.

> +
> + priv->nr_states = ret;
> + priv->states = devm_kzalloc(dev, sizeof(*priv->states) * 
> priv->nr_states, GFP_KERNEL);
> + if (!priv->states)
> + return -ENOMEM;
> +
> + ret = of_property_read_u8_array(node, "led-states", priv->states, 
> priv->nr_states);
> + if (ret)
> + return ret;
> +
> + priv->cdev.max_brightness = LED_FULL;
>  max_brightness is not 255 (= LED_FULL). max_brightness must be
> derived from the led-states property.

Yeah, I will fix this. the max-brightness should for the whole LED,
right? So

it will at same level with led-states.

Re: WARNING: AMDGPU DRM warning in 5.11.9

[Ilkka Prusi]

On 24.3.2021 16.16, Chris Rankin wrote:

Hi,

Theee warnings ares not present in my dmesg log from 5.11.8:

[   43.390159] [ cut here ]
[   43.393574] WARNING: CPU: 2 PID: 1268 at
drivers/gpu/drm/ttm/ttm_bo.c:517 ttm_bo_release+0x172/0x282 [ttm]
[   43.401940] Modules linked in: nf_nat_ftp nf_conntrack_ftp cfg80211


Changing WARN_ON to WARN_ON_ONCE in drivers/gpu/drm/ttm/ttm_bo.c 
ttm_bo_release() reduces the flood of messages into single splat.


This warning appears to come from 57fcd550eb15bce ("drm/ttm: Warn on 
pinning without holding a reference)" and reverting it might be one choice.





There are others, but I am assuming there is a common cause here.

Cheers,
Chris



diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index a76eb2c14e8c..50b53355b265 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -514,7 +514,7 @@ static void ttm_bo_release(struct kref *kref)
 * shrinkers, now that they are queued for
 * destruction.
 */
-   if (WARN_ON(bo->pin_count)) {
+   if (WARN_ON_ONCE(bo->pin_count)) {
bo->pin_count = 0;
ttm_bo_del_from_lru(bo);
ttm_bo_add_mem_to_lru(bo, &bo->mem);



--
 - Ilkka

RE: [PATCH v6 04/10] scsi: ufshpb: Make eviction depends on region's reads

[Avri Altman]

> 
> On 2021-03-22 16:10, Avri Altman wrote:
> > In host mode, eviction is considered an extreme measure.
> > verify that the entering region has enough reads, and the exiting
> > region has much less reads.
> >
> > Signed-off-by: Avri Altman 
> > ---
> >  drivers/scsi/ufs/ufshpb.c | 18 +-
> >  1 file changed, 17 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/scsi/ufs/ufshpb.c b/drivers/scsi/ufs/ufshpb.c
> > index a1519cbb4ce0..5e757220d66a 100644
> > --- a/drivers/scsi/ufs/ufshpb.c
> > +++ b/drivers/scsi/ufs/ufshpb.c
> > @@ -17,6 +17,7 @@
> >  #include "../sd.h"
> >
> >  #define ACTIVATION_THRESHOLD 8 /* 8 IOs */
> > +#define EVICTION_THRESHOLD (ACTIVATION_THRESHOLD << 5) /* 256 IOs
> */
> >
> >  /* memory management */
> >  static struct kmem_cache *ufshpb_mctx_cache;
> > @@ -1047,6 +1048,13 @@ static struct ufshpb_region
> > *ufshpb_victim_lru_info(struct ufshpb_lu *hpb)
> >   if (ufshpb_check_srgns_issue_state(hpb, rgn))
> >   continue;
> >
> > + /*
> > +  * in host control mode, verify that the exiting region
> > +  * has less reads
> > +  */
> > + if (hpb->is_hcm && rgn->reads > (EVICTION_THRESHOLD >> 1))
> > + continue;
> > +
> >   victim_rgn = rgn;
> >   break;
> >   }
> > @@ -1219,7 +1227,7 @@ static int ufshpb_issue_map_req(struct ufshpb_lu
> > *hpb,
> >
> >  static int ufshpb_add_region(struct ufshpb_lu *hpb, struct
> > ufshpb_region *rgn)
> >  {
> > - struct ufshpb_region *victim_rgn;
> > + struct ufshpb_region *victim_rgn = NULL;
> >   struct victim_select_info *lru_info = &hpb->lru_info;
> >   unsigned long flags;
> >   int ret = 0;
> > @@ -1246,7 +1254,15 @@ static int ufshpb_add_region(struct ufshpb_lu
> > *hpb, struct ufshpb_region *rgn)
> >* It is okay to evict the least recently used region,
> >* because the device could detect this region
> >* by not issuing HPB_READ
> > +  *
> > +  * in host control mode, verify that the entering
> > +  * region has enough reads
> >*/
> > + if (hpb->is_hcm && rgn->reads < EVICTION_THRESHOLD) {
> > + ret = -EACCES;
> > + goto out;
> > + }
> > +
> 
> I cannot understand the logic behind this. A rgn which host chooses to
> activate,
> is in INACTIVE state now, if its rgn->reads < 256, then don't activate
> it.
> Could you please elaborate?
I am re-citing the commit log:
"In host mode, eviction is considered an extreme measure.
verify that the entering region has enough reads, and the exiting
region has much less reads."

Here comes to play the reads counter as a comparative index.
Max-active-regions has crossed, and to activate a region, you need to evict 
another region.
But the activation threshold is relatively low, how do you know that you will 
benefit more,
>From the new region, than from the one you choose to evict?

Not to arbitrarily evict the "first" (LRU) region, like in device mode, we are 
looking for a solid
Reason for the new region to enter, and for the existing region to leave.
Otherwise, you will find yourself entering and existing the same region over 
and over,
Just threshing the active-list creating an unnecessary overhead by keep sending 
map requests.
For example, say the entering region has 4 reads, but the LRU region has 200, 
and its reads keeps coming.
Is it the "correct" decision to evict a 200-reads region for a 4-reads region?
If you indeed evict this 200-reads region, you will evict another to put it 
right back,
Over and over.

On the other hand, we are not hanging-on to "cold" regions, and inactivate them 
if there are no recent
Reads to that region - see the patch with the "Cold" timeout.

I agree that this can be elaborate to a more sophisticated policies - which we 
tried.
For now, let's go with the simplest one - use thresholds for both the entering 
and exiting regions.

Thanks,
Avri
> 
> Thanks,
> Can Guo.
> 
> >   victim_rgn = ufshpb_victim_lru_info(hpb);
> >   if (!victim_rgn) {
> >   dev_warn(&hpb->sdev_ufs_lu->sdev_dev,

Re: [PATCH v5 0/6] KVM: arm64: Add VLPI migration support on GICv4.1

[Shenming Lu]

On 2021/3/25 2:19, Marc Zyngier wrote:
> On Mon, 22 Mar 2021 14:01:52 +0800, Shenming Lu wrote:
>> In GICv4.1, migration has been supported except for (directly-injected)
>> VLPI. And GICv4.1 Spec explicitly gives a way to get the VLPI's pending
>> state (which was crucially missing in GICv4.0). So we make VLPI migration
>> capable on GICv4.1 in this series.
>>
>> In order to support VLPI migration, we need to save and restore all
>> required configuration information and pending states of VLPIs. But
>> in fact, the configuration information of VLPIs has already been saved
>> (or will be reallocated on the dst host...) in vgic(kvm) migration.
>> So we only have to migrate the pending states of VLPIs specially.
>>
>> [...]
> 
> Applied to next, thanks!

Thanks a lot again for all the comments and suggestions. :-)

Shenming

> 
> [1/6] irqchip/gic-v3-its: Add a cache invalidation right after vPE unmapping
>   commit: 301beaf19739cb6e640ed44e630e7da993f0ecc8
> [2/6] irqchip/gic-v3-its: Drop the setting of PTZ altogether
>   commit: c21bc068cdbe5613d3319ae171c3f2eb9f321352
> [3/6] KVM: arm64: GICv4.1: Add function to get VLPI state
>   commit: 80317fe4a65375fae668672a1398a0fb73eb9023
> [4/6] KVM: arm64: GICv4.1: Try to save VLPI state in save_pending_tables
>   commit: f66b7b151e00427168409f8c1857970e926b1e27
> [5/6] KVM: arm64: GICv4.1: Restore VLPI pending state to physical side
>   commit: 12df7429213abbfa9632ab7db94f629ec309a58b
> [6/6] KVM: arm64: GICv4.1: Give a chance to save VLPI state
>   commit: 8082d50f4817ff6a7e08f4b7e9b18e5f8bfa290d
> 
> Cheers,
> 
>   M.
> 

[PATCH 2/2] nvmem: qfprom: Add support for fuse blowing on sc7280

[Rajendra Nayak]

Handle the differences across LDO voltage needed for blowing fuses,
and the blow timer value, identified using a minor version of 15
on sc7280.

Signed-off-by: Rajendra Nayak 
Signed-off-by: Ravi Kumar Bokka 
---
Applies on top of https://lore.kernel.org/patchwork/patch/1376175/

 drivers/nvmem/qfprom.c | 27 +--
 1 file changed, 25 insertions(+), 2 deletions(-)

diff --git a/drivers/nvmem/qfprom.c b/drivers/nvmem/qfprom.c
index 100d69d..d6d3f24 100644
--- a/drivers/nvmem/qfprom.c
+++ b/drivers/nvmem/qfprom.c
@@ -45,11 +45,13 @@ MODULE_PARM_DESC(read_raw_data, "Read raw instead of 
corrected data");
  * @qfprom_blow_timer_value: The timer value of qfprom when doing efuse blow.
  * @qfprom_blow_set_freq:The frequency required to set when we start the
  *   fuse blowing.
+ * @qfprom_blow_uV:  LDO voltage to be set when doing efuse blow
  */
 struct qfprom_soc_data {
u32 accel_value;
u32 qfprom_blow_timer_value;
u32 qfprom_blow_set_freq;
+   int qfprom_blow_uV;
 };
 
 /**
@@ -111,6 +113,15 @@ static const struct qfprom_soc_compatible_data 
sc7180_qfprom = {
.nkeepout = ARRAY_SIZE(sc7180_qfprom_keepout)
 };
 
+static const struct nvmem_keepout sc7280_qfprom_keepout[] = {
+   {.start = 0x128, .end = 0x148},
+   {.start = 0x238, .end = 0x248}
+};
+
+static const struct qfprom_soc_compatible_data sc7280_qfprom = {
+   .keepout = sc7280_qfprom_keepout,
+   .nkeepout = ARRAY_SIZE(sc7280_qfprom_keepout)
+};
 /**
  * qfprom_disable_fuse_blowing() - Undo enabling of fuse blowing.
  * @priv: Our driver data.
@@ -168,6 +179,7 @@ static int qfprom_enable_fuse_blowing(const struct 
qfprom_priv *priv,
  struct qfprom_touched_values *old)
 {
int ret;
+   int qfprom_blow_uV = priv->soc_data->qfprom_blow_uV;
 
ret = clk_prepare_enable(priv->secclk);
if (ret) {
@@ -187,9 +199,9 @@ static int qfprom_enable_fuse_blowing(const struct 
qfprom_priv *priv,
 * a rail shared do don't specify a max--regulator constraints
 * will handle.
 */
-   ret = regulator_set_voltage(priv->vcc, 180, INT_MAX);
+   ret = regulator_set_voltage(priv->vcc, qfprom_blow_uV, INT_MAX);
if (ret) {
-   dev_err(priv->dev, "Failed to set 1.8 voltage\n");
+   dev_err(priv->dev, "Failed to set %duV\n", qfprom_blow_uV);
goto err_clk_rate_set;
}
 
@@ -311,6 +323,14 @@ static const struct qfprom_soc_data qfprom_7_8_data = {
.accel_value = 0xD10,
.qfprom_blow_timer_value = 25,
.qfprom_blow_set_freq = 480,
+   .qfprom_blow_uV = 180,
+};
+
+static const struct qfprom_soc_data qfprom_7_15_data = {
+   .accel_value = 0xD08,
+   .qfprom_blow_timer_value = 24,
+   .qfprom_blow_set_freq = 480,
+   .qfprom_blow_uV = 190,
 };
 
 static int qfprom_probe(struct platform_device *pdev)
@@ -379,6 +399,8 @@ static int qfprom_probe(struct platform_device *pdev)
 
if (major_version == 7 && minor_version == 8)
priv->soc_data = &qfprom_7_8_data;
+   if (major_version == 7 && minor_version == 15)
+   priv->soc_data = &qfprom_7_15_data;
 
priv->vcc = devm_regulator_get(&pdev->dev, "vcc");
if (IS_ERR(priv->vcc))
@@ -405,6 +427,7 @@ static int qfprom_probe(struct platform_device *pdev)
 static const struct of_device_id qfprom_of_match[] = {
{ .compatible = "qcom,qfprom",},
{ .compatible = "qcom,sc7180-qfprom", .data = &sc7180_qfprom},
+   { .compatible = "qcom,sc7280-qfprom", .data = &sc7280_qfprom},
{/* sentinel */},
 };
 MODULE_DEVICE_TABLE(of, qfprom_of_match);
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

[PATCH 1/2] dt-bindings: nvmem: Add SoC compatible for sc7280

[Rajendra Nayak]

Document SoC compatible for sc7280

Signed-off-by: Rajendra Nayak 
---
 Documentation/devicetree/bindings/nvmem/qcom,qfprom.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/nvmem/qcom,qfprom.yaml 
b/Documentation/devicetree/bindings/nvmem/qcom,qfprom.yaml
index 992777c..861b205 100644
--- a/Documentation/devicetree/bindings/nvmem/qcom,qfprom.yaml
+++ b/Documentation/devicetree/bindings/nvmem/qcom,qfprom.yaml
@@ -24,6 +24,7 @@ properties:
   - qcom,msm8998-qfprom
   - qcom,qcs404-qfprom
   - qcom,sc7180-qfprom
+  - qcom,sc7280-qfprom
   - qcom,sdm845-qfprom
   - const: qcom,qfprom
 
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

Re: [PATCH v3 9/9] dt-bindings: serial: stm32: add phandle 'bluetooth' to fix dtbs_check warrning

[dillon min]

Hi Rob,

Thanks for the suggestion.


On Thu, Mar 25, 2021 at 1:45 AM Rob Herring  wrote:
>
> On Fri, Mar 19, 2021 at 07:13:27PM +0800, dillon min wrote:
> > Hi Alexandre,
> >
> > Thanks for the reply.
> >
> > On Fri, Mar 19, 2021 at 4:38 PM Alexandre TORGUE
> >  wrote:
> > >
> > > Hi Dillon
> > >
> > > On 3/19/21 5:28 AM, dillon min wrote:
> > > > No changes, Just loop lkp in.
> > > >
> > > >
> > > > Hi lkp,
> > > >
> > > > Sorry for the late reply, thanks for your report.
> > > > This patch is to fix the build warning message.
> > > >
> > > > Thanks.
> > > > Regards
> > > >
> > > > On Mon, Mar 15, 2021 at 5:45 PM  wrote:
> > > >>
> > > >> From: dillon min 
> > > >>
> > > >> when run make dtbs_check with 'bluetoothi brcm,bcm43438-bt'
> > > >> dts enabled on stm32h7, there is a warrning popup:
> > > >>
> > >  arch/arm/boot/dts/stm32h750i-art-pi.dt.yaml: serial@40004800: 
> > >  'bluetooth'
> > > >> does not match any of the regexes: 'pinctrl-[0-9]+'
> > > >>
> > > >> to make dtbs_check happy, so add a phandle bluetooth
> > > >>
> > > >> Fixes: 500cdb23d608 ("ARM: dts: stm32: Add STM32H743 MCU and 
> > > >> STM32H743i-EVAL board")
> > > >> Signed-off-by: dillon min 
> > > >> Reported-by: kernel test robot 
> > > >> ---
> > > >>   Documentation/devicetree/bindings/serial/st,stm32-uart.yaml | 5 +
> > > >>   1 file changed, 5 insertions(+)
> > > >>
> > > >> diff --git 
> > > >> a/Documentation/devicetree/bindings/serial/st,stm32-uart.yaml 
> > > >> b/Documentation/devicetree/bindings/serial/st,stm32-uart.yaml
> > > >> index 8631678283f9..5e674840e62d 100644
> > > >> --- a/Documentation/devicetree/bindings/serial/st,stm32-uart.yaml
> > > >> +++ b/Documentation/devicetree/bindings/serial/st,stm32-uart.yaml
> > > >> @@ -50,6 +50,11 @@ properties:
> > > >>   minItems: 1
> > > >>   maxItems: 2
> > > >>
> > > >> +  bluetooth:
> > > >> +type: object
> > > >> +description: |
> > > >> +  phandles to the usart controller and bluetooth
> > > >> +
> > >
> > > Do we really need to add this "generic" property here ? You could test
> > > without the "AditionalProperties:False".
> > Yes, indeed. we have no reason to add a generic 'bluetooth' property
> > into specific soc's interface yaml.
> > I can't just remove "AditionalProperties:False", else make
> > O=../kernel-art/ dtbs dtbs_check will run into
> >
> > /home/fmin/linux/Documentation/devicetree/bindings/serial/st,stm32-uart.yaml:
> > 'oneOf' conditional failed, one must be fixed:
> > 'unevaluatedProperties' is a required property
> > 'additionalProperties' is a required property
> > ...
> >
> > So , i will replace "AditionalProperties:False". with
> > unevaluatedProperties: false, do you agree with this?
>
> This is okay as long as 'serial.yaml' is referenced, but will eventually
> fail if not (unevaluatedProperties isn't actually implemented yet).
>
> > If so, i will send patch v4 later.
>
> Or you can do this:
>
> addtionalProperties:
>   type: object
>
> Which means any other property has to be a node.
>
Okay, I just test your patch, it's fixed dtbs_check warrning as well.
I will merge it to next submit, thanks.

Hi, Valentin CARON，
Could you help to double check it, after my v5 submit ? thanks so much.

Regards.

Valent
> Rob

Re: [PATCH] cpufreq: dt: check the error returned by dev_pm_opp_of_cpumask_add_table

[quanyang.wang]

Hi Viresh,

On 3/25/21 1:24 PM, Viresh Kumar wrote:

On 25-03-21, 13:15, quanyang.wang wrote:

Thank you for pointing it out.  Do you mean that even if
dev_pm_opp_of_cpumask_add_table returns

an error, dev_pm_opp_get_opp_count may still return count > 0 because
someone may call dev_pm_opp_add

to add OPP to cpu succcessfully at somewhere else?

Yes.

There are two ways we can add OPPs today:

- Statically via device tree. This is what
   dev_pm_opp_of_cpumask_add_table() tries to do.

- Dynamically via call to dev_pm_opp_add(), which I described earlier.

What failed here is the static way of adding OPPs, we still need to
check if OPPs were added dynamically.


Thank you for shedding light on this.

I will send a V2 patch which only check the return error -EPROBE_DEFER.

Thanks,

Quanyang

Re: [PATCH v6 04/10] scsi: ufshpb: Make eviction depends on region's reads

[Can Guo]

On 2021-03-22 16:10, Avri Altman wrote:

In host mode, eviction is considered an extreme measure.
verify that the entering region has enough reads, and the exiting
region has much less reads.

Signed-off-by: Avri Altman 
---
 drivers/scsi/ufs/ufshpb.c | 18 +-
 1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/drivers/scsi/ufs/ufshpb.c b/drivers/scsi/ufs/ufshpb.c
index a1519cbb4ce0..5e757220d66a 100644
--- a/drivers/scsi/ufs/ufshpb.c
+++ b/drivers/scsi/ufs/ufshpb.c
@@ -17,6 +17,7 @@
 #include "../sd.h"

 #define ACTIVATION_THRESHOLD 8 /* 8 IOs */
+#define EVICTION_THRESHOLD (ACTIVATION_THRESHOLD << 5) /* 256 IOs */

 /* memory management */
 static struct kmem_cache *ufshpb_mctx_cache;
@@ -1047,6 +1048,13 @@ static struct ufshpb_region
*ufshpb_victim_lru_info(struct ufshpb_lu *hpb)
if (ufshpb_check_srgns_issue_state(hpb, rgn))
continue;

+   /*
+* in host control mode, verify that the exiting region
+* has less reads
+*/
+   if (hpb->is_hcm && rgn->reads > (EVICTION_THRESHOLD >> 1))
+   continue;
+
victim_rgn = rgn;
break;
}
@@ -1219,7 +1227,7 @@ static int ufshpb_issue_map_req(struct ufshpb_lu 
*hpb,


 static int ufshpb_add_region(struct ufshpb_lu *hpb, struct 
ufshpb_region *rgn)

 {
-   struct ufshpb_region *victim_rgn;
+   struct ufshpb_region *victim_rgn = NULL;
struct victim_select_info *lru_info = &hpb->lru_info;
unsigned long flags;
int ret = 0;
@@ -1246,7 +1254,15 @@ static int ufshpb_add_region(struct ufshpb_lu
*hpb, struct ufshpb_region *rgn)
 * It is okay to evict the least recently used region,
 * because the device could detect this region
 * by not issuing HPB_READ
+*
+* in host control mode, verify that the entering
+* region has enough reads
 */
+   if (hpb->is_hcm && rgn->reads < EVICTION_THRESHOLD) {
+   ret = -EACCES;
+   goto out;
+   }
+


I cannot understand the logic behind this. A rgn which host chooses to 
activate,
is in INACTIVE state now, if its rgn->reads < 256, then don't activate 
it.

Could you please elaborate?

Thanks,
Can Guo.


victim_rgn = ufshpb_victim_lru_info(hpb);
if (!victim_rgn) {
dev_warn(&hpb->sdev_ufs_lu->sdev_dev,

Re: [PATCH 2/2] dt-binding: leds: Document leds-multi-gpio bindings

[Vesa Jääskeläinen]

Hi,

See below.

On 24.3.2021 9.56, Hermes Zhang wrote:

From: Hermes Zhang 

Document the device tree bindings of the multiple GPIOs LED driver
Documentation/devicetree/bindings/leds/leds-multi-gpio.yaml.

Signed-off-by: Hermes Zhang 
---
  .../bindings/leds/leds-multi-gpio.yaml| 50 +++
  1 file changed, 50 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/leds/leds-multi-gpio.yaml

diff --git a/Documentation/devicetree/bindings/leds/leds-multi-gpio.yaml 
b/Documentation/devicetree/bindings/leds/leds-multi-gpio.yaml
new file mode 100644
index ..6f2b47487b90
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/leds-multi-gpio.yaml
@@ -0,0 +1,50 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/leds/leds-multi-gpio.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Multiple GPIOs LED driver
+
+maintainers:
+  - Hermes Zhang 
+
+description:
+  This will support some LED made of multiple GPIOs and the brightness of the
+  LED could map to different states of the GPIOs.
+
+properties:
+  compatible:
+const: multi-gpio-led
+
+  led-gpios:
+description: Array of one or more GPIOs pins used to control the LED.
+minItems: 1
+maxItems: 8  # Should be enough


We also have a case with multi color LEDs (which is probably a more 
common than multi intensity LED. So I am wondering how these both could 
co-exist.


From: 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/leds/leds-gpio.yaml?h=v5.12-rc4#n58


led-0 {
gpios = <&mcu_pio 0 GPIO_ACTIVE_LOW>;
linux,default-trigger = "disk-activity";
function = LED_FUNCTION_DISK;
};

Now 'gpios' (and in LED context) and 'led-gpios' is very close to each 
other and could easily be confused.


Perhaps this could be something like:

intensity-gpios = ...

or even simplified then just to gpios = <...>


+
+  led-states:
+description: |
+  The array list the supported states here which will map to brightness
+  from 0 to maximum. Each item in the array will present all the GPIOs
+  value by bit.
+$ref: /schemas/types.yaml#/definitions/uint8-array
+minItems: 1
+maxItems: 16 # Should be enough
+
+required:
+  - compatible
+  - led-gpios
+  - led-states
+
+additionalProperties: false
+
+examples:
+  - |
+gpios-led {
+  compatible = "multi-gpio-led";
+
+  led-gpios = <&gpio0 23 0x1>,
+  <&gpio0 24 0x1>;
+  led-states = /bits/ 8 <0x00 0x01 0x02 0x03>;
+};
+...



From: 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/leds/leds-lp55xx.yaml?h=v5.12-rc4#n196


There is example of multi color LED configuration. In example below I 
used two-color LED with red and green as an example (which what we seem 
to have most in use).


Then if try to combine these into something like:

# Multi color LED with single GPIO line per color
multi-led@2 {
  compatible = "gpio-leds";
  color = ;
  led@0 {
color = ;
gpios = <&mcu_pio 0 GPIO_ACTIVE_LOW>;
  };

  led@1 {
color = ;
gpios = <&mcu_pio 1 GPIO_ACTIVE_LOW>;
  };
};

# And with intensity GPIOs:
multi-led@2 {
  compatible = "gpio-leds";
  color = ;

  led@0 {
color = ;
gpios = <&gpio0 23 0x1>,
<&gpio0 24 0x1>;
... see below
  };

  led@1 {
color = ;
gpios = <&gpio0 25 0x1>,
<&gpio0 26 0x1>;
... see below
  };
};

# And then single GPIO with intensity GPIOs:
led@2 {
  compatible = "gpio-leds";
  gpios = <&gpio0 23 0x1>,
  <&gpio0 24 0x1>;
  gpios-brightness-levels = <0 1 2 3>
};

I changed 'led-states' to 'gpios-brightness-levels' as it describe more 
that this is about brightness and not some other state information.


How would this sound?

Thanks,
Vesa Jääskeläinen

Re: [PATCH v1 3/3] KEYS: trusted: Introduce support for NXP CAAM-based trusted keys

[Sumit Garg]

On Wed, 24 Mar 2021 at 19:37, Ahmad Fatoum  wrote:
>
> Hello Sumit,
>
> On 24.03.21 11:47, Sumit Garg wrote:
> > On Wed, 24 Mar 2021 at 14:56, Ahmad Fatoum  wrote:
> >>
> >> Hello Mimi,
> >>
> >> On 23.03.21 19:07, Mimi Zohar wrote:
> >>> On Tue, 2021-03-23 at 17:35 +0100, Ahmad Fatoum wrote:
>  On 21.03.21 21:48, Horia Geantă wrote:
> > caam has random number generation capabilities, so it's worth using that
> > by implementing .get_random.
> 
>  If the CAAM HWRNG is already seeding the kernel RNG, why not use the 
>  kernel's?
> 
>  Makes for less code duplication IMO.
> >>>
> >>> Using kernel RNG, in general, for trusted keys has been discussed
> >>> before.   Please refer to Dave Safford's detailed explanation for not
> >>> using it [1].
> >>
> >> The argument seems to boil down to:
> >>
> >>  - TPM RNG are known to be of good quality
> >>  - Trusted keys always used it so far
> >>
> >> Both are fine by me for TPMs, but the CAAM backend is new code and neither 
> >> point
> >> really applies.
> >>
> >> get_random_bytes_wait is already used for generating key material 
> >> elsewhere.
> >> Why shouldn't new trusted key backends be able to do the same thing?
> >>
> >
> > Please refer to documented trusted keys behaviour here [1]. New
> > trusted key backends should align to this behaviour and in your case
> > CAAM offers HWRNG so we should be better using that.
>
> Why is it better?
>
> Can you explain what benefit a CAAM user would have if the trusted key
> randomness comes directly out of the CAAM instead of indirectly from
> the kernel entropy pool that is seeded by it?

IMO, user trust in case of trusted keys comes from trusted keys
backend which is CAAM here. If a user doesn't trust that CAAM would
act as a reliable source for RNG then CAAM shouldn't be used as a
trust source in the first place.

And I think building user's trust for kernel RNG implementation with
multiple entropy contributions is pretty difficult when compared with
CAAM HWRNG implementation.

-Sumit

>
> > Also, do update documentation corresponding to CAAM as a trusted keys 
> > backend.
>
> Yes. The documentation should be updated for CAAM and it should describe
> how the key material is derived. Will do so for v2.
>
> Cheers,
> Ahmad
>
> >
> > [1] 
> > https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd.git/tree/Documentation/security/keys/trusted-encrypted.rst#n87
> >
> > -Sumit
> >
> >> Cheers,
> >> Ahmad
> >>
> >>>
> >>> thanks,
> >>>
> >>> Mimi
> >>>
> >>> [1]
> >>> https://lore.kernel.org/linux-integrity/bca04d5d9a3b764c9b7405bba4d4a3c035f2a...@alpmbapa12.e2k.ad.ge.com/
> >>>
> >>>
> >>>
> >>
> >> --
> >> Pengutronix e.K.   | |
> >> Steuerwalder Str. 21   | http://www.pengutronix.de/  |
> >> 31137 Hildesheim, Germany  | Phone: +49-5121-206917-0|
> >> Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
> >
>
> --
> Pengutronix e.K.   | |
> Steuerwalder Str. 21   | http://www.pengutronix.de/  |
> 31137 Hildesheim, Germany  | Phone: +49-5121-206917-0|
> Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

Re: [PATCH 2/5] cifsd: add server-side procedures for SMB3

[Sebastian Gottschall]

Am 23.03.2021 um 08:19 schrieb Dan Carpenter:

On Tue, Mar 23, 2021 at 08:17:47AM +0900, Namjae Jeon wrote:

+
+static int
+compare_oid(unsigned long *oid1, unsigned int oid1len,
+   unsigned long *oid2, unsigned int oid2len) {
+   unsigned int i;
+
+   if (oid1len != oid2len)
+   return 0;
+
+   for (i = 0; i < oid1len; i++) {
+   if (oid1[i] != oid2[i])
+   return 0;
+   }
+   return 1;
+}

Call this oid_eq()?

Why not compare_oid()? This code is come from cifs.
I need clear reason to change both cifs/cifsd...


Boolean functions should tell you what they are testing in the name.
Without any context you can't know what if (compare_oid(one, two)) {
means, but if (oid_equal(one, two)) { is readable.

regards,
dan carpenter

ahm just a pointless comment. but
return !memcmp(oid1,oid2, sizeof(long*)*oid1len);
looks much more efficient than this "for" loop

Re: [PATCH] cpufreq: dt: check the error returned by dev_pm_opp_of_cpumask_add_table

[Viresh Kumar]

On 25-03-21, 13:15, quanyang.wang wrote:
> Thank you for pointing it out.  Do you mean that even if
> dev_pm_opp_of_cpumask_add_table returns
> 
> an error, dev_pm_opp_get_opp_count may still return count > 0 because
> someone may call dev_pm_opp_add
> 
> to add OPP to cpu succcessfully at somewhere else?

Yes.

There are two ways we can add OPPs today:

- Statically via device tree. This is what
  dev_pm_opp_of_cpumask_add_table() tries to do.

- Dynamically via call to dev_pm_opp_add(), which I described earlier.

What failed here is the static way of adding OPPs, we still need to
check if OPPs were added dynamically.

-- 
viresh

[no subject]

[Kayla Manthey]

Hej min kære, jeg vil gerne vide, om du har min tidligere besked, tak.

Re: [PATCH] arm64: dts: qcom: sc7280: Add PMIC peripherals for SC7280

[skakit]

Hi Matthias,

On 2021-03-22 23:04, Matthias Kaehlcke wrote:

Hi Satya,

On Mon, Mar 22, 2021 at 06:50:47PM +0530, ska...@codeaurora.org wrote:

Hi Matthias,

On 2021-03-13 02:10, Matthias Kaehlcke wrote:
> Hi Satya,
>
> On Thu, Mar 11, 2021 at 04:10:29PM +0530, satya priya wrote:
> > Add PM7325/PM8350C/PMK8350/PMR735A peripherals such as PON,
> > GPIOs, RTC and other PMIC infra modules for SC7280.
> >
> > Signed-off-by: satya priya 
> > ---
> > This patch depends on base DT and board files for SC7280 to merge
> > first
> > https://lore.kernel.org/patchwork/project/lkml/list/?series=487403
> >
> >  arch/arm64/boot/dts/qcom/pm7325.dtsi  |  60 
> >  arch/arm64/boot/dts/qcom/pm8350c.dtsi |  60 
> >  arch/arm64/boot/dts/qcom/pmk8350.dtsi | 104
> > ++
> >  arch/arm64/boot/dts/qcom/pmr735a.dtsi |  60 
> >  arch/arm64/boot/dts/qcom/sc7280.dtsi  |   8 +++
> >  5 files changed, 292 insertions(+)
> >  create mode 100644 arch/arm64/boot/dts/qcom/pm7325.dtsi
> >  create mode 100644 arch/arm64/boot/dts/qcom/pm8350c.dtsi
> >  create mode 100644 arch/arm64/boot/dts/qcom/pmk8350.dtsi
> >  create mode 100644 arch/arm64/boot/dts/qcom/pmr735a.dtsi
> >
> > diff --git a/arch/arm64/boot/dts/qcom/pm7325.dtsi
> > b/arch/arm64/boot/dts/qcom/pm7325.dtsi
> > new file mode 100644
> > index 000..393b256
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/qcom/pm7325.dtsi
> > @@ -0,0 +1,60 @@
>
> ...
>
> > + polling-delay-passive = <100>;
> > + polling-delay = <0>;
>
> Are you sure that no polling delay is needed? How does the thermal
> framework
> detect that the temperatures is >= the passive trip point and that it
> should
> start polling at 'polling-delay-passive' rate?
>

As the temp-alarm has interrupt support, whenever preconfigured 
threshold
violates it notifies thermal framework, so I think the polling delay 
is not

needed here.


From the documentation I found it's not clear to me how exactly these
interrupts work. Is a single interrupt triggered when the threshold is
violated or are there periodic (?) interrupts as long as the 
temperature

is above the stage 0 threshold?

Why is 'polling-delay-passive' passive needed if there are interrupts? 
Maybe
to detect that the zone should transition from passive to no cooling 
when the

temperature drops below the stage 0 threshold?


The PMIC TEMP_ALARM peripheral maintains an internal over-temperature 
stage: 0, 1, 2, or 3.  Stage 0 is normal operation below the lowest 
(stage 1) threshold [usually 95 C].  When in stage 1, the temperature is 
between the stage 1 and 2 thresholds [stage 2 threshold is usually 115 
C].  Upon hitting the stage 3 threshold [usually 145 C], the PMIC 
hardware will automatically shut down the system.


The TEMP_ALARM IRQ fires on stage 0 -> 1 and 1 -> 0 transitions.  We 
therefore set polling-delay = <0> since there is no need for software to 
monitor the temperature periodically when operating in stage 0.  Upon 
crossing the stage 1 threshold, SW receives the IRQ and the thermal 
framework hits its first trip changing the thermal zone to passive mode. 
 This then engages the 100 ms polling enabled via polling-delay-passive 
= <100>.  If the temperate keeps climbing and passes the stage 2 
threshold, the thermal framework hits the second trip (which is 
critical) and it initiates an orderly shutdown.  If the temperature 
drops below the stage 1 threshold, then the thermal framework exits 
passive mode and stops polling.  This approach reduces/eliminates the 
software overhead when not at an elevated temperature.


Thanks,
Satya Priya

Re: [PATCH] fs: Improve eventpoll logging to stop indicting timerfd

[Manish Varma]

Hi Thomas,

On Mon, Mar 22, 2021 at 2:40 PM Thomas Gleixner  wrote:
>
> Manish,
>
> On Mon, Mar 22 2021 at 10:15, Manish Varma wrote:
> > On Thu, Mar 18, 2021 at 6:04 AM Thomas Gleixner  wrote:
> >> > +static atomic_t instance_count = ATOMIC_INIT(0);
> >>
> >> instance_count is misleading as it does not do any accounting of
> >> instances as the name suggests.
> >>
> >
> > Not sure if I am missing a broader point here, but the objective of this
> > patch is to:
> > A. To help find the process a given timerfd associated with, and
> > B. one step further, if there are multiple fds created by a single
> > process then label each instance using monotonically increasing integer
> > i.e. "instance_count" to help identify each of them separately.
> >
> > So, instance_count in my mind helps with "B", i.e. to keep track and
> > identify each instance of timerfd individually.
>
> I know what you want to do. The point is that instance_count is the
> wrong name as it suggests that it counts instances, and that in most
> cases implies active instances.
>
> It's not a counter, it's a token generator which allows you to create
> unique ids. The fact that it is just incrementing once per created file
> descriptor does not matter. That's just an implementation detail.
>
> Name it something like timerfd_create_id or timerfd_session_id which
> clearly tells that this is not counting any thing. It immediately tells
> the purpose of generating an id.
>
> Naming matters when reading code, really.
>

Noted, and thanks for the clarification!

> >> > + snprintf(file_name_buf, sizeof(file_name_buf), "[timerfd%d:%s]",
> >> > +  instance, task_comm_buf);
> >> > + ufd = anon_inode_getfd(file_name_buf, &timerfd_fops, ctx,
> >> >  O_RDWR | (flags & TFD_SHARED_FCNTL_FLAGS));
> >> >   if (ufd < 0)
> >> >   kfree(ctx);
> >>
> >> I actually wonder, whether this should be part of anon_inode_get*().
> >>
> >
> > I am curious (and open at the same time) if that will be helpful..
> > In the case of timerfd, I could see it adds up value by stuffing more
> > context to the file descriptor name as eventpoll is using the same file
> > descriptor names as wakesource name, and hence the cost of slightly
> > longer file descriptor name justifies. But I don't have a solid reason
> > if this additional cost (of longer file descriptor names) will be
> > helpful in general with other file descriptors.
>
> Obviously you want to make that depend on a flag handed to anon_...().

Unfortunately, changing file descriptor names does not seem to be a viable
option here (more details in my answer in the next section), and
hence changes in anon_...() does not seem to be required.

>
> The point is that there will be the next anonfd usecase which needs
> unique identification at some point. That is going to copy&pasta that
> timerfd code and then make it slightly different just because and then
> userspace needs to parse yet another format.
>
> >> Aside of that this is a user space visible change both for eventpoll and
> >> timerfd.
>
> Not when done right.
>
> >> Have you carefully investigated whether there is existing user space
> >> which might depend on the existing naming conventions?
> >>
> > I am not sure how I can confirm that for all userspace, but open for
> > suggestions if you can share some ideas.
> >
> > However, I have verified and can confirm for Android userspace that
> > there is no dependency on existing naming conventions for timerfd and
> > eventpoll wakesource names, if that helps.
>
> Well, there is a world outside Android and you're working for a company
> which should have tools to search for '[timerfd]' usage in a gazillion of
> projects. The obvious primary targets are distros of all sorts. I'm sure
> there are ways to figure this out without doing it manually.
>
> Not that I expect any real dependencies on it, but as always the devil
> is in the details.
>

Right, there are some userspace which depends on "[timerfd]" string
https://codesearch.debian.net/search?q=%22%5Btimerfd%5D%22&literal=1

So, modifying file descriptor names at-least for timerfd will definitely
break those.

With that said, I am now thinking about leaving alone the file descriptor
names as is, and instead, adding those extra information about the
associated processes (i.e. process name or rather PID of the
process) along with token ID directly into wakesource name, at the
time of creating new wakesource i.e. in ep_create_wakeup_source().

So, the wakesource names, that currently named as "[timerfd]", will be
named something like:
"epollitem:.[timerfd]"

Where N is the number of wakesource created since boot.

This way we can still associate the process with the wakesource
name and also distinguish multiple instances of wakesources using
the integer identifier.

Please share your thoughts!

> Thanks,
>
> tglx

Thanks,
Manish
--
Manish Varma | Software Engineer | var...@google.com | 650-686-0858

Re: [PATCH] cpufreq: dt: check the error returned by dev_pm_opp_of_cpumask_add_table

[quanyang.wang]

Hi Viresh,

On 3/25/21 12:45 PM, Viresh Kumar wrote:

On 25-03-21, 12:31, quanyang.w...@windriver.com wrote:

From: Quanyang Wang 

The function dev_pm_opp_of_cpumask_add_table may return zero or an
error. When it returns an error, this means that no OPP table is
added for the cpumask because _dev_pm_opp_cpumask_remove_table is
called to free all OPPs associated with the cpu devices in the error
label "remove_table". So continuing to run the next function
dev_pm_opp_get_opp_count is meaningless since it always return the
count value as 0.

There is another reason why we should check the error returned by
dev_pm_opp_of_cpumask_add_table is that it may return -EPROBE_DEFER
which comes from clk_get(dev, NULL) in _update_opp_table_clk. When
the clk for cpu device isn't ready, dt_cpufreq_probe should be deferred
and wait to be called again. But if we ignore the return error of
dev_pm_opp_of_cpumask_add_table, dt_cpufreq_probe will return -ENODEV
because dev_pm_opp_get_opp_count returns the count value as 0,
the cpufreq-dt driver will fail with the error log as below:

[0.724069] cpu cpu0: OPP table can't be empty

Signed-off-by: Quanyang Wang 
---
  drivers/cpufreq/cpufreq-dt.c | 12 +---
  1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/cpufreq/cpufreq-dt.c b/drivers/cpufreq/cpufreq-dt.c
index b1e1bdc63b01..f24359f47b1a 100644
--- a/drivers/cpufreq/cpufreq-dt.c
+++ b/drivers/cpufreq/cpufreq-dt.c
@@ -255,10 +255,16 @@ static int dt_cpufreq_early_init(struct device *dev, int 
cpu)
 * before updating priv->cpus. Otherwise, we will end up creating
 * duplicate OPPs for the CPUs.
 *
-* OPPs might be populated at runtime, don't check for error here.

As the comment (which you removed) clearly says, the OPPs maybe added
at runtime, don't check for error here.

When we say runtime, we mean someone may have called dev_pm_opp_add()
for the devices.


Thank you for pointing it out.  Do you mean that even if 
dev_pm_opp_of_cpumask_add_table returns


an error, dev_pm_opp_get_opp_count may still return count > 0 because 
someone may call dev_pm_opp_add


to add OPP to cpu succcessfully at somewhere else?

Thanks,

Quanyang




+* We need check the return value here, if it is non-zero, there is
+* need to go on.
 */
-   if (!dev_pm_opp_of_cpumask_add_table(priv->cpus))
-   priv->have_static_opps = true;
+   ret = dev_pm_opp_of_cpumask_add_table(priv->cpus);
+   if (ret) {
+   dev_err(cpu_dev, "Failed to add OPP table for CPUs\n");
+   goto out;
+   }
+
+   priv->have_static_opps = true;
  
  	/*

 * The OPP table must be initialized, statically or dynamically, by this

Re: [PATCH v4] audit: log nftables configuration change events once per table

[kernel test robot]

Hi Richard,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on nf/master]
[also build test WARNING on nf-next/master pcmoore-audit/next v5.12-rc4 
next-20210324]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:
https://github.com/0day-ci/linux/commits/Richard-Guy-Briggs/audit-log-nftables-configuration-change-events-once-per-table/20210325-115438
base:   https://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf.git master
config: arc-allyesconfig (attached as .config)
compiler: arceb-elf-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# 
https://github.com/0day-ci/linux/commit/e2632994acb2553a22a739b3a876a091d04f446c
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review 
Richard-Guy-Briggs/audit-log-nftables-configuration-change-events-once-per-table/20210325-115438
git checkout e2632994acb2553a22a739b3a876a091d04f446c
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=arc 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All warnings (new ones prefixed by >>):

>> net/netfilter/nf_tables_api.c:7993:5: warning: no previous prototype for 
>> 'nf_tables_commit_audit_alloc' [-Wmissing-prototypes]
7993 | int nf_tables_commit_audit_alloc(struct list_head *adl,
 | ^~~~
>> net/netfilter/nf_tables_api.c:8011:6: warning: no previous prototype for 
>> 'nf_tables_commit_audit_collect' [-Wmissing-prototypes]
8011 | void nf_tables_commit_audit_collect(struct list_head *adl,
 |  ^~
>> net/netfilter/nf_tables_api.c:8030:6: warning: no previous prototype for 
>> 'nf_tables_commit_audit_log' [-Wmissing-prototypes]
8030 | void nf_tables_commit_audit_log(struct list_head *adl, u32 
generation)
 |  ^~


vim +/nf_tables_commit_audit_alloc +7993 net/netfilter/nf_tables_api.c

  7992  
> 7993  int nf_tables_commit_audit_alloc(struct list_head *adl,
  7994   struct nft_table *table)
  7995  {
  7996  struct nft_audit_data *adp;
  7997  
  7998  list_for_each_entry(adp, adl, list) {
  7999  if (adp->table == table)
  8000  return 0;
  8001  }
  8002  adp = kzalloc(sizeof(*adp), GFP_KERNEL);
  8003  if (!adp)
  8004  return -ENOMEM;
  8005  adp->table = table;
  8006  INIT_LIST_HEAD(&adp->list);
  8007  list_add(&adp->list, adl);
  8008  return 0;
  8009  }
  8010  
> 8011  void nf_tables_commit_audit_collect(struct list_head *adl,
  8012  struct nft_table *table, u32 op)
  8013  {
  8014  struct nft_audit_data *adp;
  8015  
  8016  list_for_each_entry(adp, adl, list) {
  8017  if (adp->table == table)
  8018  goto found;
  8019  }
  8020  WARN_ONCE("table=%s not expected in commit list", table->name);
  8021  return;
  8022  found:
  8023  adp->entries++;
  8024  if (!adp->op || adp->op > op)
  8025  adp->op = op;
  8026  }
  8027  
  8028  #define AUNFTABLENAMELEN (NFT_TABLE_MAXNAMELEN + 22)
  8029  
> 8030  void nf_tables_commit_audit_log(struct list_head *adl, u32 generation)
  8031  {
  8032  struct nft_audit_data *adp, *adn;
  8033  char aubuf[AUNFTABLENAMELEN];
  8034  
  8035  list_for_each_entry_safe(adp, adn, adl, list) {
  8036  snprintf(aubuf, AUNFTABLENAMELEN, "%s:%u", 
adp->table->name,
  8037   generation);
  8038  audit_log_nfcfg(aubuf, adp->table->family, adp->entries,
  8039  nft2audit_op[adp->op], GFP_KERNEL);
  8040  list_del(&adp->list);
  8041  kfree(adp);
  8042  }
  8043  }
  8044  

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org


.config.gz
Description: application/gzip

Re: [PATCH v4 14/22] x86/fpu/xstate: Expand the xstate buffer on the first use of dynamic user state

[Liu, Jing2]

On 3/25/2021 5:09 AM, Len Brown wrote:

On Tue, Mar 23, 2021 at 11:15 PM Liu, Jing2  wrote:


IMO, the problem with AVX512 state
is that we guaranteed it will be zero for XINUSE=0.
That means we have to write 0's on saves.

why "we have to write 0's on saves" when XINUSE=0.

Since due to SDM, if XINUSE=0, the XSAVES will *not* save the data and
xstate_bv bit is 0; if use XSAVE, it need save the state but
xstate_bv bit is also 0.

   It would be better
to be able to skip the write -- even if we can't save the space
we can save the data transfer.  (This is what we did for AMX).

With XFD feature that XFD=1, XSAVE command still has to save INIT state
to the area. So it seems with XINUSE=0 and XFD=1, the XSAVE(S) commands
do the same that both can help save the data transfer.

Hi Jing, Good observation!

There are 3 cases.

Hi Len, thanks for your reply.


1. Task context switch save into the context switch buffer.
Here we use XSAVES, and as you point out, XSAVES includes
the compaction optimization feature tracked by XINUSE.
So when AMX is enabled, but clean, XSAVES doesn't write zeros.
Further, it omits the buffer space for AMX in the destination altogether!
However, since XINUSE=1 is possible, we have to *allocate* a buffer
large enough to handle the dirty data for when XSAVES can not
employ that optimization.

Yes, I agree with you about the first case.


2. Entry into user signal handler saves into the user space sigframe.
Here we use XSAVE, and so the hardware will write zeros for XINUSE=0,
and for AVX512, we save neither time or space.

My understanding that for application compatibility, we can *not* compact
the destination buffer that user-space sees.  This is because existing code
may have adopted fixed size offsets.  (which is unfortunate).



And so, for AVX512, we both reserve the space, and we write zeros
for clean AVX512 state.
By XSAVE, I think this is true if we assume setting EDX:EAX AVX512 bits 
as 1,
which means XSAVE will write zeros when XINUSE=0. Is this the same 
assumption

with yours?...

For AMX, we must still reserve the space, but we are not going to write zeros
for clean state.  We so this in software by checking XINUSE=0, and clearing
the xstate_bf for the XSAVE.  As a result, for XINUSE=0, we can skip
writing the zeros, even though we can't compress the space.

So my understanding is that clearing xstate_bv will not help prevent saving
zeros, but only not masking EDX:EAX, since the following logic. Not sure if
this is just what you mean. :)

RFBM ← XCR0 AND EDX:EAX; /* bitwise logical AND */
OLD_BV ← XSTATE_BV field from XSAVE header;
...
FOR i ← 2 TO 62
IF RFBM[i] = 1
THEN save XSAVE state component i at offset n from base of XSAVE area;
FI;
ENDFOR;

XSTATE_BV field in XSAVE header ← (OLD_BV AND NOT RFBM) OR (XINUSE AND 
RFBM);



3. user space always uses fully uncompacted XSAVE buffers.


The reason I'm interested in XINUSE denotation is that it might be helpful
for the XFD MSRs context switch cost during vmexit and vmenter.

As the guest OS may be using XFD, the VMM can not use it for itself.
Rather, the VMM must context switch it when it switches between guests.
(or not expose it to guests at all)


My understand is that KVM cannot assume that userspace qemu uses XFD or not,
so KVM need context switch XFD between vcpu threads when vmexit/vmenter.

That's why I am thinking about detecting XINUSE when vmexit, otherwise, a
wrong armed IA32_XFD will impact XSAVES/XRSTORS causing guest AMX states
lost.

Thanks,
Jing


cheers,
-Len


cheers,
Len Brown, Intel Open Source Technology Center

[PATCH] usb: typec: Fix a typo

[Bhaskar Chowdhury]

s/Acknowlege/Acknowledge/

Signed-off-by: Bhaskar Chowdhury 
---
 drivers/usb/typec/ucsi/ucsi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/typec/ucsi/ucsi.c b/drivers/usb/typec/ucsi/ucsi.c
index 244270755ae6..282c3c825c13 100644
--- a/drivers/usb/typec/ucsi/ucsi.c
+++ b/drivers/usb/typec/ucsi/ucsi.c
@@ -63,7 +63,7 @@ static int ucsi_read_error(struct ucsi *ucsi)
u16 error;
int ret;

-   /* Acknowlege the command that failed */
+   /* Acknowledge the command that failed */
ret = ucsi_acknowledge_command(ucsi);
if (ret)
return ret;
--
2.30.1

Re: [PATCH v1] usb: dwc3: core: Add shutdown callback for dwc3

[Sandeep Maheswaram]

On 3/24/2021 9:01 AM, Stephen Boyd wrote:

Quoting Sandeep Maheswaram (2021-03-23 12:27:32)

This patch adds a shutdown callback to USB DWC core driver to ensure that
it is properly shutdown in reboot/shutdown path. This is required
where SMMU address translation is enabled like on SC7180
SoC and few others. If the hardware is still accessing memory after
SMMU translation is disabled as part of SMMU shutdown callback in
system reboot or shutdown path, then IOVAs(I/O virtual address)
which it was using will go on the bus as the physical addresses which
might result in unknown crashes (NoC/interconnect errors).

Previously this was added in dwc3 qcom glue driver.
https://patchwork.kernel.org/project/linux-arm-msm/list/?series=382449
But observed kernel panic as glue driver shutdown getting called after
iommu shutdown. As we are adding iommu nodes in dwc core node
in device tree adding shutdown callback in core driver seems correct.

Signed-off-by: Sandeep Maheswaram 
---
  drivers/usb/dwc3/core.c | 26 +++---
  1 file changed, 19 insertions(+), 7 deletions(-)

diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 94fdbe5..777b2b5 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -1634,11 +1634,9 @@ static int dwc3_probe(struct platform_device *pdev)
 return ret;
  }
  
-static int dwc3_remove(struct platform_device *pdev)

+static void __dwc3_teardown(struct dwc3 *dwc)
  {
-   struct dwc3 *dwc = platform_get_drvdata(pdev);
-
-   pm_runtime_get_sync(&pdev->dev);
+   pm_runtime_get_sync(dwc->dev);
  
 dwc3_debugfs_exit(dwc);

 dwc3_core_exit_mode(dwc);
@@ -1646,19 +1644,32 @@ static int dwc3_remove(struct platform_device *pdev)
 dwc3_core_exit(dwc);
 dwc3_ulpi_exit(dwc);
  
-   pm_runtime_disable(&pdev->dev);

-   pm_runtime_put_noidle(&pdev->dev);
-   pm_runtime_set_suspended(&pdev->dev);
+   pm_runtime_disable(dwc->dev);
+   pm_runtime_put_noidle(dwc->dev);
+   pm_runtime_set_suspended(dwc->dev);
  
 dwc3_free_event_buffers(dwc);

 dwc3_free_scratch_buffers(dwc);
  
 if (dwc->usb_psy)

 power_supply_put(dwc->usb_psy);
+}
+
+static int dwc3_remove(struct platform_device *pdev)
+{
+   struct dwc3 *dwc = platform_get_drvdata(pdev);
+
+   __dwc3_teardown(dwc);
  
 return 0;

  }
  
+static void dwc3_shutdown(struct platform_device *pdev)

+{
+   struct dwc3 *dwc = platform_get_drvdata(pdev);
+
+   __dwc3_teardown(dwc);
+}

Can't this be

static void dwc3_shutdown(struct platform_device *pdev)
{
   dwc3_remove(pdev);
}

and then there's nothing else to change? Basically ignore return value
of dwc3_remove() to make shutdown and remove harmonize. I also wonder if
this is more common than we think and a struct driver flag could be set
to say "call remove for shutdown" and then have driver core swizzle on
that and save some duplicate functions.


I was referring to similar patch 
https://patchwork.kernel.org/project/linux-usb/patch/20190817174140.6394-1-vice...@gmail.com/



  #ifdef CONFIG_PM
  static int dwc3_core_init_for_resume(struct dwc3 *dwc)
  {
@@ -1976,6 +1987,7 @@ MODULE_DEVICE_TABLE(acpi, dwc3_acpi_match);
  static struct platform_driver dwc3_driver = {
 .probe  = dwc3_probe,
 .remove = dwc3_remove,
+   .shutdown   = dwc3_shutdown,

Re: Re: [PATCH] fuse: Fix a potential double free in virtio_fs_get_tree

[lyl2019]

> -原始邮件-
> 发件人: "Vivek Goyal" 
> 发送时间: 2021-03-24 01:10:03 (星期三)
> 收件人: "Lv Yunlong" 
> 抄送: stefa...@redhat.com, mik...@szeredi.hu, 
> virtualizat...@lists.linux-foundation.org, linux-fsde...@vger.kernel.org, 
> linux-kernel@vger.kernel.org
> 主题: Re: [PATCH] fuse: Fix a potential double free in virtio_fs_get_tree
> 
> On Mon, Mar 22, 2021 at 10:18:31PM -0700, Lv Yunlong wrote:
> > In virtio_fs_get_tree, fm is allocated by kzalloc() and
> > assigned to fsc->s_fs_info by fsc->s_fs_info=fm statement.
> > If the kzalloc() failed, it will goto err directly, so that
> > fsc->s_fs_info must be non-NULL and fm will be freed.
> 
> sget_fc() will either consume fsc->s_fs_info in case a new super
> block is allocated and set fsc->s_fs_info. In that case we don't
> free fc or fm.
> 
> Or, sget_fc() will return with fsc->s_fs_info set in case we already
> found a super block. In that case we need to free fc and fm.
> 
> In case of error from sget_fc(), fc/fm need to be freed first and
> then error needs to be returned to caller.
> 
> if (IS_ERR(sb))
> return PTR_ERR(sb);
> 
> 
> If we allocated a new super block in sget_fc(), then next step is
> to initialize it.
> 
> if (!sb->s_root) {
> err = virtio_fs_fill_super(sb, fsc);
>   }
> 
> If we run into errors here, then fc/fm need to be freed.
> 
> So current code looks fine to me.
> 
> Vivek
> 
> > 
> > But later fm is freed again when virtio_fs_fill_super() fialed.
> > I think the statement if (fsc->s_fs_info) {kfree(fm);} is
> > misplaced.
> > 
> > My patch puts this statement in the correct palce to avoid
> > double free.
> > 
> > Signed-off-by: Lv Yunlong 
> > ---
> >  fs/fuse/virtio_fs.c | 10 ++
> >  1 file changed, 6 insertions(+), 4 deletions(-)
> > 
> > diff --git a/fs/fuse/virtio_fs.c b/fs/fuse/virtio_fs.c
> > index 8868ac31a3c0..727cf436828f 100644
> > --- a/fs/fuse/virtio_fs.c
> > +++ b/fs/fuse/virtio_fs.c
> > @@ -1437,10 +1437,7 @@ static int virtio_fs_get_tree(struct fs_context *fsc)
> >  
> > fsc->s_fs_info = fm;
> > sb = sget_fc(fsc, virtio_fs_test_super, set_anon_super_fc);
> > -   if (fsc->s_fs_info) {
> > -   fuse_conn_put(fc);
> > -   kfree(fm);
> > -   }
> > +
> > if (IS_ERR(sb))
> > return PTR_ERR(sb);
> >  
> > @@ -1457,6 +1454,11 @@ static int virtio_fs_get_tree(struct fs_context *fsc)
> > sb->s_flags |= SB_ACTIVE;
> > }
> >  
> > +   if (fsc->s_fs_info) {
> > +   fuse_conn_put(fc);
> > +   kfree(fm);
> > +   }
> > +
> > WARN_ON(fsc->root);
> > fsc->root = dget(sb->s_root);
> > return 0;
> > -- 
> > 2.25.1
> > 
> > 
> 


Ok, thanks.
It should be a false positive.

[PATCH] drivers: gpu: drm: Remove repeated declaration

[Wan Jiabing]

struct drm_i915_private, struct intel_crtc_state and
struct intel_crtc have been declared before. 
Remove the duplicate.

Signed-off-by: Wan Jiabing 
---
 drivers/gpu/drm/i915/display/intel_crt.h | 1 -
 drivers/gpu/drm/i915/display/intel_display.h | 1 -
 drivers/gpu/drm/i915/display/intel_vrr.h | 1 -
 3 files changed, 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_crt.h 
b/drivers/gpu/drm/i915/display/intel_crt.h
index 1b3fba359efc..6c5c44600cbd 100644
--- a/drivers/gpu/drm/i915/display/intel_crt.h
+++ b/drivers/gpu/drm/i915/display/intel_crt.h
@@ -11,7 +11,6 @@
 enum pipe;
 struct drm_encoder;
 struct drm_i915_private;
-struct drm_i915_private;
 
 bool intel_crt_port_enabled(struct drm_i915_private *dev_priv,
i915_reg_t adpa_reg, enum pipe *pipe);
diff --git a/drivers/gpu/drm/i915/display/intel_display.h 
b/drivers/gpu/drm/i915/display/intel_display.h
index 76f8a805b0a3..29cb6d84ed70 100644
--- a/drivers/gpu/drm/i915/display/intel_display.h
+++ b/drivers/gpu/drm/i915/display/intel_display.h
@@ -48,7 +48,6 @@ struct i915_ggtt_view;
 struct intel_atomic_state;
 struct intel_crtc;
 struct intel_crtc_state;
-struct intel_crtc_state;
 struct intel_digital_port;
 struct intel_dp;
 struct intel_encoder;
diff --git a/drivers/gpu/drm/i915/display/intel_vrr.h 
b/drivers/gpu/drm/i915/display/intel_vrr.h
index fac01bf4ab50..96f9c9c27ab9 100644
--- a/drivers/gpu/drm/i915/display/intel_vrr.h
+++ b/drivers/gpu/drm/i915/display/intel_vrr.h
@@ -15,7 +15,6 @@ struct intel_crtc;
 struct intel_crtc_state;
 struct intel_dp;
 struct intel_encoder;
-struct intel_crtc;
 
 bool intel_vrr_is_capable(struct drm_connector *connector);
 void intel_vrr_check_modeset(struct intel_atomic_state *state);
-- 
2.25.1

Re: [PATCH] tee: optee: fix build error caused by recent optee tracepoints feature

[Guenter Roeck]

On Thu, Mar 25, 2021 at 12:06:01PM +0800, Jisheng Zhang wrote:
> If build kernel without "O=dir", below error will be seen:
> 
> In file included from drivers/tee/optee/optee_trace.h:67,
>  from drivers/tee/optee/call.c:18:
> ./include/trace/define_trace.h:95:42: fatal error: ./optee_trace.h: No such 
> file or directory
>95 | #include TRACE_INCLUDE(TRACE_INCLUDE_FILE)
>   |  ^
> compilation terminated.
> 
> Fix it by adding below line to Makefile:
> CFLAGS_call.o := -I$(src)
> 
> Tested with and without "O=dir", both can build successfully.
> 
> Reported-by: Guenter Roeck 
> Suggested-by: Steven Rostedt 
> Signed-off-by: Jisheng Zhang 

Tested-by: Guenter Roeck 

> ---
>  drivers/tee/optee/Makefile | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/tee/optee/Makefile b/drivers/tee/optee/Makefile
> index 56263ae3b1d7..3aa33ea9e6a6 100644
> --- a/drivers/tee/optee/Makefile
> +++ b/drivers/tee/optee/Makefile
> @@ -6,3 +6,6 @@ optee-objs += rpc.o
>  optee-objs += supp.o
>  optee-objs += shm_pool.o
>  optee-objs += device.o
> +
> +# for tracing framework to find optee_trace.h
> +CFLAGS_call.o := -I$(src)
> -- 
> 2.31.0
> 

[PATCH] ARM: imx: Fix a typo

[Bhaskar Chowdhury]

s/confgiured/configured/

Signed-off-by: Bhaskar Chowdhury 
---
 arch/arm/mach-imx/pm-imx5.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-imx/pm-imx5.c b/arch/arm/mach-imx/pm-imx5.c
index e9962b48e30c..2e3af2bc7758 100644
--- a/arch/arm/mach-imx/pm-imx5.c
+++ b/arch/arm/mach-imx/pm-imx5.c
@@ -45,7 +45,7 @@
  * This is also the lowest power state possible without affecting
  * non-cpu parts of the system.  For these reasons, imx5 should default
  * to always using this state for cpu idling.  The PM_SUSPEND_STANDBY also
- * uses this state and needs to take no action when registers remain confgiured
+ * uses this state and needs to take no action when registers remain configured
  * for this state.
  */
 #define IMX5_DEFAULT_CPU_IDLE_STATE WAIT_UNCLOCKED_POWER_OFF
--
2.30.1

RE: [PATCH v9 1/7] smccc: Add HVC call variant with result registers other than 0 thru 3

[Michael Kelley]

From: Mark Rutland  Sent: Wednesday, March 24, 2021 9:55 
AM
> 
> Hi Michael,
> 
> On Mon, Mar 08, 2021 at 11:57:13AM -0800, Michael Kelley wrote:
> > Hypercalls to Hyper-V on ARM64 may return results in registers other
> > than X0 thru X3, as permitted by the SMCCC spec version 1.2 and later.
> > Accommodate this by adding a variant of arm_smccc_1_1_hvc that allows
> > the caller to specify which 3 registers are returned in addition to X0.
> >
> > Signed-off-by: Michael Kelley 
> > ---
> > There are several ways to support returning results from registers
> > other than X0 thru X3, and Hyper-V usage should be compatible with
> > whatever the maintainers prefer.  What's implemented in this patch
> > may be the most flexible, but it has the downside of not being a
> > true function interface in that args 0 thru 2 must be fixed strings,
> > and not general "C" expressions.
> 
> For the benefit of others here, SMCCCv1.2 allows:
> 
> * SMC64/HVC64 to use all of x1-x17 for both parameters and return values
> * SMC32/HVC32 to use all of r1-r7 for both parameters and return values
> 
> The rationale for this was to make it possible to pass a large number of
> arguments in one call without the hypervisor/firmware needing to access
> the memory of the caller.
> 
> My preference would be to add arm_smccc_1_2_{hvc,smc}() assembly
> functions which read all the permitted argument registers from a struct,
> and write all the permitted result registers to a struct, leaving it to
> callers to set those up and decompose them.
> 
> That way we only have to write one implementation that all callers can
> use, which'll be far easier to maintain. I suspect that in general the
> cost of temporarily bouncing the values through memory will be dominated
> by whatever the hypervisor/firmware is going to do, and if it's not we
> can optimize that away in future.
> 

Thanks for the feedback, and I'm working on implementing this approach.
But I've hit a snag in that gcc limits the "asm" statement to 30 arguments,
which gives us 15 registers as parameters and 15 registers as return
values, instead of the 18 each allowed by SMCCC v1.2.  I will continue
with the 15 register limit for now, unless someone knows a way to exceed
that.  The alternative would be to go to pure assembly language.

I'll post a standalone RFC patch when I have something that works.  My
C pre-processor wizardry is limited, so others will probably know some
tricks that can improve on my first cut.

Michael

Re: [PATCH 1/2] extcon: extcon-gpio: Log error if work-queue init fails

[Vaittinen, Matti]

On Thu, 2021-03-25 at 09:49 +0900, Chanwoo Choi wrote:
> On 3/24/21 6:51 PM, Vaittinen, Matti wrote:
> > Hello Hans, Chanwoo, Greg,
> > 
> > On Wed, 2021-03-24 at 10:25 +0100, Hans de Goede wrote:
> > > Hi,
> > > 
> > > On 3/24/21 10:21 AM, Matti Vaittinen wrote:
> > > > Add error print for probe failure when resource managed work-
> > > > queue
> > > > initialization fails.
> > > > 
> > > > Signed-off-by: Matti Vaittinen <
> > > > matti.vaitti...@fi.rohmeurope.com>
> > > > Suggested-by: Chanwoo Choi 
> > > > ---
> > > >  drivers/extcon/extcon-gpio.c | 4 +++-
> > > >  1 file changed, 3 insertions(+), 1 deletion(-)
> > > > 
> > > > diff --git a/drivers/extcon/extcon-gpio.c
> > > > b/drivers/extcon/extcon-
> > > > gpio.c
> > > > index 4105df74f2b0..8ea2cda8f7f3 100644
> > > > --- a/drivers/extcon/extcon-gpio.c
> > > > +++ b/drivers/extcon/extcon-gpio.c
> > > > @@ -114,8 +114,10 @@ static int gpio_extcon_probe(struct
> > > > platform_device *pdev)
> > > > return ret;
> > > >  
> > > > ret = devm_delayed_work_autocancel(dev, &data->work,
> > > > gpio_extcon_work);
> > > > -   if (ret)
> > > > +   if (ret) {
> > > > +   dev_err(dev, "Failed to initialize
> > > > delayed_work");
> > > > return ret;
> > > > +   }
> > > 
> > > The only ret which we can have here is -ENOMEM and as a rule we
> > > don't
> > > log
> > > errors for those, because the kernel memory-management code
> > > already
> > > complains
> > > loudly when this happens.
> > 
> > I know. This is why I originally omitted the print. Besides, if the
> > memory is so low that devres adding fails - then we probably have
> > plenty of other complaints as well... But as Chanwoo maintains the
> > driver and wanted to have the print - I do not have objections to
> > that
> > either. Maybe someone some-day adds another error path to wq
> > initialization in which case seeing it failed could make sense.
> > 
> > > So IMHO this patch should be dropped.
> > Fine for me - as well as keeping it. I have no strong opinion on
> > this.
> 
> If it is the same handling way for -ENOMEM, don't need to add log ss
> Hans said. 
> Thanks for Hans.

So be it :)
Greg, can you just apply the patch 2/2 and drop this one? (There should
be no dependency between these) or do you want me to resend 2/2 alone?

> > Br,
> > Matti
> > 
> 
> 

[PATCH] drivers: gpu: drm: Remove duplicate declaration

[Wan Jiabing]

struct dss_device has been declared at 51st line. 
Remove the duplicate.

Signed-off-by: Wan Jiabing 
---
 drivers/gpu/drm/omapdrm/dss/omapdss.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/omapdrm/dss/omapdss.h 
b/drivers/gpu/drm/omapdrm/dss/omapdss.h
index a40abeafd2e9..2658aadee09a 100644
--- a/drivers/gpu/drm/omapdrm/dss/omapdss.h
+++ b/drivers/gpu/drm/omapdrm/dss/omapdss.h
@@ -52,7 +52,6 @@ struct dss_device;
 struct omap_drm_private;
 struct omap_dss_device;
 struct dispc_device;
-struct dss_device;
 struct dss_lcd_mgr_config;
 struct snd_aes_iec958;
 struct snd_cea_861_aud_if;
-- 
2.25.1

Re: [PATCH 01/13] kconfig: split randconfig setup code into set_randconfig_seed()

[Masahiro Yamada]

On Sun, Mar 14, 2021 at 4:48 AM Masahiro Yamada  wrote:
>
> This code is too big to be placed in the switch statement.
>
> Move the code into a new helper function. I slightly refactor the code
> without changing the behavior.
>
> Signed-off-by: Masahiro Yamada 
> ---

All applied to linux-kbuild/kconfig.




>  scripts/kconfig/conf.c | 54 --
>  1 file changed, 31 insertions(+), 23 deletions(-)
>
> diff --git a/scripts/kconfig/conf.c b/scripts/kconfig/conf.c
> index 957d2a0832f7..063c9e7a34c1 100644
> --- a/scripts/kconfig/conf.c
> +++ b/scripts/kconfig/conf.c
> @@ -82,6 +82,36 @@ static void xfgets(char *str, int size, FILE *in)
> printf("%s", str);
>  }
>
> +static void set_randconfig_seed(void)
> +{
> +   unsigned int seed;
> +   char *env;
> +   bool seed_set = false;
> +
> +   env = getenv("KCONFIG_SEED");
> +   if (env && *env) {
> +   char *endp;
> +
> +   seed = strtol(env, &endp, 0);
> +   if (*endp == '\0')
> +   seed_set = true;
> +   }
> +
> +   if (!seed_set) {
> +   struct timeval now;
> +
> +   /*
> +* Use microseconds derived seed, compensate for systems 
> where it may
> +* be zero.
> +*/
> +   gettimeofday(&now, NULL);
> +   seed = (now.tv_sec + 1) * (now.tv_usec + 1);
> +   }
> +
> +   printf("KCONFIG_SEED=0x%X\n", seed);
> +   srand(seed);
> +}
> +
>  static int conf_askvalue(struct symbol *sym, const char *def)
>  {
> if (!sym_has_value(sym))
> @@ -515,30 +545,8 @@ int main(int ac, char **av)
> defconfig_file = optarg;
> break;
> case randconfig:
> -   {
> -   struct timeval now;
> -   unsigned int seed;
> -   char *seed_env;
> -
> -   /*
> -* Use microseconds derived seed,
> -* compensate for systems where it may be zero
> -*/
> -   gettimeofday(&now, NULL);
> -   seed = (unsigned int)((now.tv_sec + 1) * (now.tv_usec 
> + 1));
> -
> -   seed_env = getenv("KCONFIG_SEED");
> -   if( seed_env && *seed_env ) {
> -   char *endp;
> -   int tmp = (int)strtol(seed_env, &endp, 0);
> -   if (*endp == '\0') {
> -   seed = tmp;
> -   }
> -   }
> -   fprintf( stderr, "KCONFIG_SEED=0x%X\n", seed );
> -   srand(seed);
> +   set_randconfig_seed();
> break;
> -   }
> case oldaskconfig:
> case oldconfig:
> case allnoconfig:
> --
> 2.27.0
>


-- 
Best Regards
Masahiro Yamada

Re: [PATCH] kconfig: use true and false for bool variable

[Masahiro Yamada]

On Mon, Mar 15, 2021 at 3:55 PM Yang Li  wrote:
>
> fixed the following coccicheck:
> ./scripts/kconfig/confdata.c:36:9-10: WARNING: return of 0/1 in function
> 'is_dir' with return type bool
>
> Reported-by: Abaci Robot 
> Signed-off-by: Yang Li 
> ---

Applied. Thanks.




>  scripts/kconfig/confdata.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/scripts/kconfig/confdata.c b/scripts/kconfig/confdata.c
> index 2568dbe..b65b8c3 100644
> --- a/scripts/kconfig/confdata.c
> +++ b/scripts/kconfig/confdata.c
> @@ -33,7 +33,7 @@ static bool is_dir(const char *path)
> struct stat st;
>
> if (stat(path, &st))
> -   return 0;
> +   return false;
>
> return S_ISDIR(st.st_mode);
>  }
> --
> 1.8.3.1
>


-- 
Best Regards
Masahiro Yamada

Re: [PATCH] cpufreq: dt: check the error returned by dev_pm_opp_of_cpumask_add_table

[Viresh Kumar]

On 25-03-21, 12:31, quanyang.w...@windriver.com wrote:
> From: Quanyang Wang 
> 
> The function dev_pm_opp_of_cpumask_add_table may return zero or an
> error. When it returns an error, this means that no OPP table is
> added for the cpumask because _dev_pm_opp_cpumask_remove_table is
> called to free all OPPs associated with the cpu devices in the error
> label "remove_table". So continuing to run the next function
> dev_pm_opp_get_opp_count is meaningless since it always return the
> count value as 0.
> 
> There is another reason why we should check the error returned by
> dev_pm_opp_of_cpumask_add_table is that it may return -EPROBE_DEFER
> which comes from clk_get(dev, NULL) in _update_opp_table_clk. When
> the clk for cpu device isn't ready, dt_cpufreq_probe should be deferred
> and wait to be called again. But if we ignore the return error of
> dev_pm_opp_of_cpumask_add_table, dt_cpufreq_probe will return -ENODEV
> because dev_pm_opp_get_opp_count returns the count value as 0,
> the cpufreq-dt driver will fail with the error log as below:
> 
> [0.724069] cpu cpu0: OPP table can't be empty
> 
> Signed-off-by: Quanyang Wang 
> ---
>  drivers/cpufreq/cpufreq-dt.c | 12 +---
>  1 file changed, 9 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/cpufreq/cpufreq-dt.c b/drivers/cpufreq/cpufreq-dt.c
> index b1e1bdc63b01..f24359f47b1a 100644
> --- a/drivers/cpufreq/cpufreq-dt.c
> +++ b/drivers/cpufreq/cpufreq-dt.c
> @@ -255,10 +255,16 @@ static int dt_cpufreq_early_init(struct device *dev, 
> int cpu)
>* before updating priv->cpus. Otherwise, we will end up creating
>* duplicate OPPs for the CPUs.
>*
> -  * OPPs might be populated at runtime, don't check for error here.

As the comment (which you removed) clearly says, the OPPs maybe added
at runtime, don't check for error here.

When we say runtime, we mean someone may have called dev_pm_opp_add()
for the devices.

> +  * We need check the return value here, if it is non-zero, there is
> +  * need to go on.
>*/
> - if (!dev_pm_opp_of_cpumask_add_table(priv->cpus))
> - priv->have_static_opps = true;
> + ret = dev_pm_opp_of_cpumask_add_table(priv->cpus);
> + if (ret) {
> + dev_err(cpu_dev, "Failed to add OPP table for CPUs\n");
> + goto out;
> + }
> +
> + priv->have_static_opps = true;
>  
>   /*
>* The OPP table must be initialized, statically or dynamically, by this

-- 
viresh

[PATCH V4] kbuild: Add rule to build .dt.yaml files for overlays

[Viresh Kumar]

The overlay source files are named with .dtso extension now, add a new
rule to generate .dt.yaml for them.

Reviewed-by: Geert Uytterhoeven 
Tested-by: Geert Uytterhoeven 
Signed-off-by: Viresh Kumar 
---
V4:
- Rebase over Frank's cleanup patch:

  https://lore.kernel.org/lkml/20210324223713.1334666-1-frowand.l...@gmail.com/

- Drop changes to drivers/of/unittest-data/Makefile.
- Drop modifications to the rule that builds .dtbo files (as it is
  already updated by Frank).

 scripts/Makefile.lib | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index 814b430b407e..a682869d8f4b 100644
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -376,6 +376,9 @@ endef
 $(obj)/%.dt.yaml: $(src)/%.dts $(DTC) $(DT_TMP_SCHEMA) FORCE
$(call if_changed_rule,dtc,yaml)
 
+$(obj)/%.dt.yaml: $(src)/%.dtso $(DTC) $(DT_TMP_SCHEMA) FORCE
+   $(call if_changed_rule,dtc,yaml)
+
 dtc-tmp = $(subst $(comma),_,$(dot-target).dts.tmp)
 
 # Bzip2
-- 
2.25.0.rc1.19.g042ed3e048af

[PATCH] tools: perf: util: Remove duplicate declaration

[Wan Jiabing]

struct evlist has been declared at 10th line.
struct comm has been declared at 15th line.
Remove the duplicate.

Signed-off-by: Wan Jiabing 
---
 tools/perf/util/metricgroup.h  | 1 -
 tools/perf/util/thread-stack.h | 1 -
 2 files changed, 2 deletions(-)

diff --git a/tools/perf/util/metricgroup.h b/tools/perf/util/metricgroup.h
index ed1b9392e624..026bbf416c48 100644
--- a/tools/perf/util/metricgroup.h
+++ b/tools/perf/util/metricgroup.h
@@ -9,7 +9,6 @@
 
 struct evlist;
 struct evsel;
-struct evlist;
 struct option;
 struct rblist;
 struct pmu_events_map;
diff --git a/tools/perf/util/thread-stack.h b/tools/perf/util/thread-stack.h
index 3bc47a42af8e..b3cd09beb62f 100644
--- a/tools/perf/util/thread-stack.h
+++ b/tools/perf/util/thread-stack.h
@@ -16,7 +16,6 @@ struct comm;
 struct ip_callchain;
 struct symbol;
 struct dso;
-struct comm;
 struct perf_sample;
 struct addr_location;
 struct call_path;
-- 
2.25.1

[PATCH] Bluetooth: L2CAP: Rudimentary typo fixes

[Bhaskar Chowdhury]

s/minium/minimum/
s/procdure/procedure/

Signed-off-by: Bhaskar Chowdhury 
---
 net/bluetooth/l2cap_core.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
index 72c2f5226d67..b38e80a0e819 100644
--- a/net/bluetooth/l2cap_core.c
+++ b/net/bluetooth/l2cap_core.c
@@ -1690,7 +1690,7 @@ static void l2cap_le_conn_ready(struct l2cap_conn *conn)
smp_conn_security(hcon, hcon->pending_sec_level);

/* For LE slave connections, make sure the connection interval
-* is in the range of the minium and maximum interval that has
+* is in the range of the minimum and maximum interval that has
 * been configured for this connection. If not, then trigger
 * the connection update procedure.
 */
@@ -7542,7 +7542,7 @@ static void l2cap_data_channel(struct l2cap_conn *conn, 
u16 cid,
BT_DBG("chan %p, len %d", chan, skb->len);

/* If we receive data on a fixed channel before the info req/rsp
-* procdure is done simply assume that the channel is supported
+* procedure is done simply assume that the channel is supported
 * and mark it as ready.
 */
if (chan->chan_type == L2CAP_CHAN_FIXED)
--
2.30.1

Re: [RFC] mm: activate access-more-than-once page via NUMA balancing

[Huang, Ying]

Hi, Mel,

Thanks for comment!

Mel Gorman  writes:

> On Wed, Mar 24, 2021 at 04:32:09PM +0800, Huang Ying wrote:
>> One idea behind the LRU page reclaiming algorithm is to put the
>> access-once pages in the inactive list and access-more-than-once pages
>> in the active list.  This is true for the file pages that are accessed
>> via syscall (read()/write(), etc.), but not for the pages accessed via
>> the page tables.  We can only activate them via page reclaim scanning
>> now.  This may cause some problems.  For example, even if there are
>> only hot file pages accessed via the page tables in the inactive list,
>> we will enable the cache trim mode incorrectly to scan only the hot
>> file pages instead of cold anon pages.
>> 
>
> I caution against this patch.
>
> It's non-deterministic for a number of reasons. As it requires NUMA
> balancing to be enabled, the pageout behaviour of a system changes when
> NUMA balancing is active. If this led to pages being artificially and
> inappropriately preserved, NUMA balancing could be disabled for the
> wrong reasons.  It only applies to pages that have no target node so
> memory policies affect which pages are activated differently. Similarly,
> NUMA balancing does not scan all VMAs and some pages may never trap a
> NUMA fault as a result. The timing of when an address space gets scanned
> is driven by the locality of pages and so the timing of page activation
> potentially becomes linked to whether pages are local or need to migrate
> (although not right now for this patch as it only affects pages with a
> target nid of NUMA_NO_NODE). In other words, changes in NUMA balancing
> that affect migration potentially affect the aging rate.  Similarly,
> the activate rate of a process with a single thread and multiple threads
> potentially have different activation rates.
>
> Finally, the NUMA balancing scan algorithm is sub-optimal. It potentially
> scans the entire address space even though only a small number of pages
> are scanned. This is particularly problematic when a process has a lot
> of threads because threads are redundantly scanning the same regions. If
> NUMA balancing ever introduced range tracking of faulted pages to limit
> how much scanning it has to do, it would inadvertently cause a change in
> page activation rate.
>
> NUMA balancing is about page locality, it should not get conflated with
> page aging.

I understand your concerns about binding the NUMA balancing and page
reclaiming.  The requirement of the page locality and page aging is
different, so the policies need to be different.  This is the wrong part
of the patch.

>From another point of view, it's still possible to share some underlying
mechanisms (and code) between them.  That is, scanning the page tables
to make pages unaccessible and capture the page accesses via the page
fault.  Now these page accessing information is used for the page
locality.  Do you think it's a good idea to use these information for
the page aging too (but with a different policy as you pointed out)?

>From yet another point of view :-), in current NUMA balancing
implementation, it's assumed that the node private pages can fit in the
accessing node.  But this may be not always true.  Is it a valid
optimization to migrate the hot private pages first?

Best Regards,
Huang, Ying

[PATCH] cpufreq: dt: check the error returned by dev_pm_opp_of_cpumask_add_table

[quanyang . wang]

From: Quanyang Wang 

The function dev_pm_opp_of_cpumask_add_table may return zero or an
error. When it returns an error, this means that no OPP table is
added for the cpumask because _dev_pm_opp_cpumask_remove_table is
called to free all OPPs associated with the cpu devices in the error
label "remove_table". So continuing to run the next function
dev_pm_opp_get_opp_count is meaningless since it always return the
count value as 0.

There is another reason why we should check the error returned by
dev_pm_opp_of_cpumask_add_table is that it may return -EPROBE_DEFER
which comes from clk_get(dev, NULL) in _update_opp_table_clk. When
the clk for cpu device isn't ready, dt_cpufreq_probe should be deferred
and wait to be called again. But if we ignore the return error of
dev_pm_opp_of_cpumask_add_table, dt_cpufreq_probe will return -ENODEV
because dev_pm_opp_get_opp_count returns the count value as 0,
the cpufreq-dt driver will fail with the error log as below:

[0.724069] cpu cpu0: OPP table can't be empty

Signed-off-by: Quanyang Wang 
---
 drivers/cpufreq/cpufreq-dt.c | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/cpufreq/cpufreq-dt.c b/drivers/cpufreq/cpufreq-dt.c
index b1e1bdc63b01..f24359f47b1a 100644
--- a/drivers/cpufreq/cpufreq-dt.c
+++ b/drivers/cpufreq/cpufreq-dt.c
@@ -255,10 +255,16 @@ static int dt_cpufreq_early_init(struct device *dev, int 
cpu)
 * before updating priv->cpus. Otherwise, we will end up creating
 * duplicate OPPs for the CPUs.
 *
-* OPPs might be populated at runtime, don't check for error here.
+* We need check the return value here, if it is non-zero, there is
+* need to go on.
 */
-   if (!dev_pm_opp_of_cpumask_add_table(priv->cpus))
-   priv->have_static_opps = true;
+   ret = dev_pm_opp_of_cpumask_add_table(priv->cpus);
+   if (ret) {
+   dev_err(cpu_dev, "Failed to add OPP table for CPUs\n");
+   goto out;
+   }
+
+   priv->have_static_opps = true;
 
/*
 * The OPP table must be initialized, statically or dynamically, by this
-- 
2.25.1