Re: [PATCH v1 00/24] Opt-in always-on nVHE hypervisor
On Mon, Nov 09, 2020 at 11:32:09AM +, David Brazdil wrote: > As we progress towards being able to keep guest state private to the > host running nVHE hypervisor, this series allows the hypervisor to > install itself on newly booted CPUs before the host is allowed to run > on them. Why? I thought we were trying to kill nVHE off now that newer CPUs provide the saner virtualization extensions?
[PATCH v8 2/6] Bluetooth: Interleave with allowlist scan
This patch implements the interleaving between allowlist scan and
no-filter scan. It'll be used to save power when at least one monitor is
registered and at least one pending connection or one device to be
scanned for.
The durations of the allowlist scan and the no-filter scan are
controlled by MGMT command: Set Default System Configuration. The
default values are set randomly for now.
Signed-off-by: Howard Chung
Reviewed-by: Alain Michaud
Reviewed-by: Manish Mandlik
---
Changes in v8:
- Simplified logic in __hci_update_interleaved_scan
- remove hdev->name when calling bt_dev_dbg
- remove 'default' in hci_req_add_le_interleaved_scan switch block
- remove {} around :1915
include/net/bluetooth/hci_core.h | 10 +++
net/bluetooth/hci_core.c | 4 +
net/bluetooth/hci_request.c | 128 +--
net/bluetooth/mgmt_config.c | 10 +++
4 files changed, 145 insertions(+), 7 deletions(-)
diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
index 9873e1c8cd163..cfede18709d8f 100644
--- a/include/net/bluetooth/hci_core.h
+++ b/include/net/bluetooth/hci_core.h
@@ -361,6 +361,8 @@ struct hci_dev {
__u8ssp_debug_mode;
__u8hw_error_code;
__u32 clock;
+ __u16 advmon_allowlist_duration;
+ __u16 advmon_no_filter_duration;
__u16 devid_source;
__u16 devid_vendor;
@@ -542,6 +544,14 @@ struct hci_dev {
struct delayed_work rpa_expired;
bdaddr_trpa;
+ enum {
+ INTERLEAVE_SCAN_NONE,
+ INTERLEAVE_SCAN_NO_FILTER,
+ INTERLEAVE_SCAN_ALLOWLIST
+ } interleave_scan_state;
+
+ struct delayed_work interleave_scan;
+
#if IS_ENABLED(CONFIG_BT_LEDS)
struct led_trigger *power_led;
#endif
diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index 502552d6e9aff..65b7b74baba4c 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -3592,6 +3592,10 @@ struct hci_dev *hci_alloc_dev(void)
hdev->cur_adv_instance = 0x00;
hdev->adv_instance_timeout = 0;
+ /* The default values will be chosen in the future */
+ hdev->advmon_allowlist_duration = 300;
+ hdev->advmon_no_filter_duration = 500;
+
hdev->sniff_max_interval = 800;
hdev->sniff_min_interval = 80;
diff --git a/net/bluetooth/hci_request.c b/net/bluetooth/hci_request.c
index 048d4db9d4ea5..2fd56ee21d31f 100644
--- a/net/bluetooth/hci_request.c
+++ b/net/bluetooth/hci_request.c
@@ -378,6 +378,53 @@ void __hci_req_write_fast_connectable(struct hci_request
*req, bool enable)
hci_req_add(req, HCI_OP_WRITE_PAGE_SCAN_TYPE, 1, &type);
}
+static void start_interleave_scan(struct hci_dev *hdev)
+{
+ hdev->interleave_scan_state = INTERLEAVE_SCAN_NO_FILTER;
+ queue_delayed_work(hdev->req_workqueue,
+ &hdev->interleave_scan, 0);
+}
+
+static bool is_interleave_scanning(struct hci_dev *hdev)
+{
+ return hdev->interleave_scan_state != INTERLEAVE_SCAN_NONE;
+}
+
+static void cancel_interleave_scan(struct hci_dev *hdev)
+{
+ bt_dev_dbg(hdev, "cancelling interleave scan");
+
+ cancel_delayed_work_sync(&hdev->interleave_scan);
+
+ hdev->interleave_scan_state = INTERLEAVE_SCAN_NONE;
+}
+
+/* Return true if interleave_scan wasn't started until exiting this function,
+ * otherwise, return false
+ */
+static bool __hci_update_interleaved_scan(struct hci_dev *hdev)
+{
+ /* If there is at least one ADV monitors and one pending LE connection
+* or one device to be scanned for, we should alternate between
+* allowlist scan and one without any filters to save power.
+*/
+ bool should_interleaving = hci_is_adv_monitoring(hdev) &&
+ !(list_empty(&hdev->pend_le_conns) &&
+list_empty(&hdev->pend_le_reports));
+ bool is_interleaving = is_interleave_scanning(hdev);
+
+ if (should_interleaving && !is_interleaving) {
+ start_interleave_scan(hdev);
+ bt_dev_dbg(hdev, "starting interleave scan");
+ return true;
+ }
+
+ if (!should_interleaving && is_interleaving)
+ cancel_interleave_scan(hdev);
+
+ return false;
+}
+
/* This function controls the background scanning based on hdev->pend_le_conns
* list. If there are pending LE connection we start the background scanning,
* otherwise we stop it.
@@ -450,8 +497,7 @@ static void __hci_update_background_scan(struct hci_request
*req)
hci_req_add_le_scan_disable(req, false);
hci_req_add_le_passive_scan(req);
-
- BT_DBG("%s starting background scanning", hdev->name);
+ bt_dev_dbg(hdev, "starting background scanning");
}
}
@@ -848,12 +894,17 @@
[PATCH v8 6/6] Bluetooth: Add toggle to switch off interleave scan
This patch add a configurable parameter to switch off the interleave
scan feature.
Reviewed-by: Alain Michaud
Signed-off-by: Howard Chung
---
(no changes since v6)
Changes in v6:
- Set EnableAdvMonInterleaveScan to 1 byte long
Changes in v4:
- Set EnableAdvMonInterleaveScan default to Disable
- Fix 80 chars limit in mgmt_config.c
include/net/bluetooth/hci_core.h | 1 +
net/bluetooth/hci_core.c | 1 +
net/bluetooth/hci_request.c | 3 ++-
net/bluetooth/mgmt_config.c | 41 +---
4 files changed, 37 insertions(+), 9 deletions(-)
diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
index cfede18709d8f..63c6d656564a1 100644
--- a/include/net/bluetooth/hci_core.h
+++ b/include/net/bluetooth/hci_core.h
@@ -363,6 +363,7 @@ struct hci_dev {
__u32 clock;
__u16 advmon_allowlist_duration;
__u16 advmon_no_filter_duration;
+ __u8enable_advmon_interleave_scan;
__u16 devid_source;
__u16 devid_vendor;
diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index 65b7b74baba4c..b7cb7bfe250bd 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -3595,6 +3595,7 @@ struct hci_dev *hci_alloc_dev(void)
/* The default values will be chosen in the future */
hdev->advmon_allowlist_duration = 300;
hdev->advmon_no_filter_duration = 500;
+ hdev->enable_advmon_interleave_scan = 0x00; /* Default to disable */
hdev->sniff_max_interval = 800;
hdev->sniff_min_interval = 80;
diff --git a/net/bluetooth/hci_request.c b/net/bluetooth/hci_request.c
index 172ccbf4f0cd2..28520c4d2d229 100644
--- a/net/bluetooth/hci_request.c
+++ b/net/bluetooth/hci_request.c
@@ -1057,7 +1057,8 @@ void hci_req_add_le_passive_scan(struct hci_request *req)
&own_addr_type))
return;
- if (__hci_update_interleaved_scan(hdev))
+ if (hdev->enable_advmon_interleave_scan &&
+ __hci_update_interleaved_scan(hdev))
return;
bt_dev_dbg(hdev, "interleave state %d", hdev->interleave_scan_state);
diff --git a/net/bluetooth/mgmt_config.c b/net/bluetooth/mgmt_config.c
index 282fbf82f3192..3cdcb66ccac38 100644
--- a/net/bluetooth/mgmt_config.c
+++ b/net/bluetooth/mgmt_config.c
@@ -17,12 +17,24 @@
__le16 value; \
} __packed _param_name_
+#define HDEV_PARAM_U8(_param_name_) \
+ struct {\
+ struct mgmt_tlv entry; \
+ __u8 value; \
+ } __packed _param_name_
+
#define TLV_SET_U16(_param_code_, _param_name_) \
{ \
{ cpu_to_le16(_param_code_), sizeof(__u16) }, \
cpu_to_le16(hdev->_param_name_) \
}
+#define TLV_SET_U8(_param_code_, _param_name_) \
+ { \
+ { cpu_to_le16(_param_code_), sizeof(__u8) }, \
+ hdev->_param_name_ \
+ }
+
#define TLV_SET_U16_JIFFIES_TO_MSECS(_param_code_, _param_name_) \
{ \
{ cpu_to_le16(_param_code_), sizeof(__u16) }, \
@@ -65,6 +77,7 @@ int read_def_system_config(struct sock *sk, struct hci_dev
*hdev, void *data,
HDEV_PARAM_U16(def_le_autoconnect_timeout);
HDEV_PARAM_U16(advmon_allowlist_duration);
HDEV_PARAM_U16(advmon_no_filter_duration);
+ HDEV_PARAM_U8(enable_advmon_interleave_scan);
} __packed rp = {
TLV_SET_U16(0x, def_page_scan_type),
TLV_SET_U16(0x0001, def_page_scan_int),
@@ -97,6 +110,7 @@ int read_def_system_config(struct sock *sk, struct hci_dev
*hdev, void *data,
def_le_autoconnect_timeout),
TLV_SET_U16(0x001d, advmon_allowlist_duration),
TLV_SET_U16(0x001e, advmon_no_filter_duration),
+ TLV_SET_U8(0x001f, enable_advmon_interleave_scan),
};
bt_dev_dbg(hdev, "sock %p", sk);
@@ -109,6 +123,7 @@ int read_def_system_config(struct sock *sk, struct hci_dev
*hdev, void *data,
#define TO_TLV(x) ((struct mgmt_tlv *)(x))
#define TLV_GET_LE16(tlv) le16_to_cpu(*((__le16 *)(TO_TLV(tlv)->value)))
+#define TLV_GET_LE8(tlv) le16_to_cpu(*((__u8 *)(TO_TLV(tlv)->value)))
int set_def_system_config(struct sock *sk, struct hci_dev *hdev, void *data,
u16 data_len)
@@ -125,6 +140,7 @@ int set_def_system_config(struct sock *sk, struct hci_dev
*hdev, void *data,
/* First pass to validate the tlv */
while (buffer_left >= sizeof(struct mgmt_tlv)) {
const u8 len = TO_TLV(buffer)->length;
+ u8 exp_type_len;
const u16 exp_len = sizeof(struct mgmt_tlv) +
len;
const u16 type = le16_to_cpu(TO_TLV(buffer)->type);
@@ -170,20 +186,26 @@ int set_def_system_
[PATCH v8 1/6] Bluetooth: Replace BT_DBG with bt_dev_dbg in HCI request
This replaces the BT_DBG function to bt_dev_dbg as it is cleaner to show
the controller index in the debug message.
Signed-off-by: Howard Chung
---
Changes in v8:
- Simplified logic in __hci_update_interleaved_scan
- Remove hdev->name when calling bt_dev_dbg
- Remove 'default' in hci_req_add_le_interleaved_scan switch block
- Remove {} around :1915
- Update commit message and title in v7 4/5
- Add a cleanup patch for replacing BT_DBG with bt_dev_dbg
Changes in v7:
- Fix bt_dev_warn argument type warning
Changes in v6:
- Set parameter EnableAdvMonInterleaveScan to 1 byte long
Changes in v5:
- Rename 'adv_monitor' from many functions/variables
- Move __hci_update_interleaved_scan into hci_req_add_le_passive_scan
- Update the logic of update_adv_monitor_scan_state
Changes in v4:
- Rebase to bluetooth-next/master (previous 2 patches are applied)
- Fix over 80 chars limit in mgmt_config.c
- Set EnableAdvMonInterleaveScan default to Disable
Changes in v3:
- Remove 'Bluez' prefix
Changes in v2:
- remove 'case 0x001c' in mgmt_config.c
net/bluetooth/hci_request.c | 52 ++---
1 file changed, 26 insertions(+), 26 deletions(-)
diff --git a/net/bluetooth/hci_request.c b/net/bluetooth/hci_request.c
index 6a74097c50d34..048d4db9d4ea5 100644
--- a/net/bluetooth/hci_request.c
+++ b/net/bluetooth/hci_request.c
@@ -58,7 +58,7 @@ static int req_run(struct hci_request *req,
hci_req_complete_t complete,
struct sk_buff *skb;
unsigned long flags;
- BT_DBG("length %u", skb_queue_len(&req->cmd_q));
+ bt_dev_dbg(hdev, "length %u", skb_queue_len(&req->cmd_q));
/* If an error occurred during request building, remove all HCI
* commands queued on the HCI request queue.
@@ -102,7 +102,7 @@ int hci_req_run_skb(struct hci_request *req,
hci_req_complete_skb_t complete)
static void hci_req_sync_complete(struct hci_dev *hdev, u8 result, u16 opcode,
struct sk_buff *skb)
{
- BT_DBG("%s result 0x%2.2x", hdev->name, result);
+ bt_dev_dbg(hdev, "result 0x%2.2x", result);
if (hdev->req_status == HCI_REQ_PEND) {
hdev->req_result = result;
@@ -115,7 +115,7 @@ static void hci_req_sync_complete(struct hci_dev *hdev, u8
result, u16 opcode,
void hci_req_sync_cancel(struct hci_dev *hdev, int err)
{
- BT_DBG("%s err 0x%2.2x", hdev->name, err);
+ bt_dev_dbg(hdev, "err 0x%2.2x", err);
if (hdev->req_status == HCI_REQ_PEND) {
hdev->req_result = err;
@@ -131,7 +131,7 @@ struct sk_buff *__hci_cmd_sync_ev(struct hci_dev *hdev, u16
opcode, u32 plen,
struct sk_buff *skb;
int err = 0;
- BT_DBG("%s", hdev->name);
+ bt_dev_dbg(hdev, "");
hci_req_init(&req, hdev);
@@ -167,7 +167,7 @@ struct sk_buff *__hci_cmd_sync_ev(struct hci_dev *hdev, u16
opcode, u32 plen,
skb = hdev->req_skb;
hdev->req_skb = NULL;
- BT_DBG("%s end: err %d", hdev->name, err);
+ bt_dev_dbg(hdev, "end: err %d", err);
if (err < 0) {
kfree_skb(skb);
@@ -196,7 +196,7 @@ int __hci_req_sync(struct hci_dev *hdev, int (*func)(struct
hci_request *req,
struct hci_request req;
int err = 0;
- BT_DBG("%s start", hdev->name);
+ bt_dev_dbg(hdev, "start");
hci_req_init(&req, hdev);
@@ -260,7 +260,7 @@ int __hci_req_sync(struct hci_dev *hdev, int (*func)(struct
hci_request *req,
hdev->req_skb = NULL;
hdev->req_status = hdev->req_result = 0;
- BT_DBG("%s end: err %d", hdev->name, err);
+ bt_dev_dbg(hdev, "end: err %d", err);
return err;
}
@@ -300,7 +300,7 @@ struct sk_buff *hci_prepare_cmd(struct hci_dev *hdev, u16
opcode, u32 plen,
if (plen)
skb_put_data(skb, param, plen);
- BT_DBG("skb len %d", skb->len);
+ bt_dev_dbg(hdev, "skb len %d", skb->len);
hci_skb_pkt_type(skb) = HCI_COMMAND_PKT;
hci_skb_opcode(skb) = opcode;
@@ -315,7 +315,7 @@ void hci_req_add_ev(struct hci_request *req, u16 opcode,
u32 plen,
struct hci_dev *hdev = req->hdev;
struct sk_buff *skb;
- BT_DBG("%s opcode 0x%4.4x plen %d", hdev->name, opcode, plen);
+ bt_dev_dbg(hdev, "opcode 0x%4.4x plen %d", opcode, plen);
/* If an error occurred during request building, there is no point in
* queueing the HCI command. We can simply return.
@@ -413,8 +413,8 @@ static void __hci_update_background_scan(struct hci_request
*req)
*/
hci_discovery_filter_clear(hdev);
- BT_DBG("%s ADV monitoring is %s", hdev->name,
- hci_is_adv_monitoring(hdev) ? "on" : "off");
+ bt_dev_dbg(hdev, "ADV monitoring is %s",
+ hci_is_adv_monitoring(hdev) ? "on" : "off");
if (list_empty(&hdev->pend_le_conns) &&
list_empty(&hdev->pend_le_reports) &&
@@ -430,7 +430,7 @@ static void __hci_update_background_scan(st
[PATCH v8 5/6] Bluetooth: Refactor read default sys config for various types
Refactor read default system configuration function so that it's capable
of returning different types than u16
Signed-off-by: Howard Chung
---
Changes in v8:
- Update the commit title and message
net/bluetooth/mgmt_config.c | 140 +---
1 file changed, 84 insertions(+), 56 deletions(-)
diff --git a/net/bluetooth/mgmt_config.c b/net/bluetooth/mgmt_config.c
index 2d3ad288c78ac..282fbf82f3192 100644
--- a/net/bluetooth/mgmt_config.c
+++ b/net/bluetooth/mgmt_config.c
@@ -11,72 +11,100 @@
#include "mgmt_util.h"
#include "mgmt_config.h"
-#define HDEV_PARAM_U16(_param_code_, _param_name_) \
-{ \
- { cpu_to_le16(_param_code_), sizeof(__u16) }, \
- { cpu_to_le16(hdev->_param_name_) } \
-}
+#define HDEV_PARAM_U16(_param_name_) \
+ struct {\
+ struct mgmt_tlv entry; \
+ __le16 value; \
+ } __packed _param_name_
-#define HDEV_PARAM_U16_JIFFIES_TO_MSECS(_param_code_, _param_name_) \
-{ \
- { cpu_to_le16(_param_code_), sizeof(__u16) }, \
- { cpu_to_le16(jiffies_to_msecs(hdev->_param_name_)) } \
-}
+#define TLV_SET_U16(_param_code_, _param_name_) \
+ { \
+ { cpu_to_le16(_param_code_), sizeof(__u16) }, \
+ cpu_to_le16(hdev->_param_name_) \
+ }
+
+#define TLV_SET_U16_JIFFIES_TO_MSECS(_param_code_, _param_name_) \
+ { \
+ { cpu_to_le16(_param_code_), sizeof(__u16) }, \
+ cpu_to_le16(jiffies_to_msecs(hdev->_param_name_)) \
+ }
int read_def_system_config(struct sock *sk, struct hci_dev *hdev, void *data,
u16 data_len)
{
- struct {
- struct mgmt_tlv entry;
- union {
- /* This is a simplification for now since all values
-* are 16 bits. In the future, this code may need
-* refactoring to account for variable length values
-* and properly calculate the required buffer size.
-*/
- __le16 value;
- };
- } __packed params[] = {
+ int ret;
+ struct mgmt_rp_read_def_system_config {
/* Please see mgmt-api.txt for documentation of these values */
- HDEV_PARAM_U16(0x, def_page_scan_type),
- HDEV_PARAM_U16(0x0001, def_page_scan_int),
- HDEV_PARAM_U16(0x0002, def_page_scan_window),
- HDEV_PARAM_U16(0x0003, def_inq_scan_type),
- HDEV_PARAM_U16(0x0004, def_inq_scan_int),
- HDEV_PARAM_U16(0x0005, def_inq_scan_window),
- HDEV_PARAM_U16(0x0006, def_br_lsto),
- HDEV_PARAM_U16(0x0007, def_page_timeout),
- HDEV_PARAM_U16(0x0008, sniff_min_interval),
- HDEV_PARAM_U16(0x0009, sniff_max_interval),
- HDEV_PARAM_U16(0x000a, le_adv_min_interval),
- HDEV_PARAM_U16(0x000b, le_adv_max_interval),
- HDEV_PARAM_U16(0x000c, def_multi_adv_rotation_duration),
- HDEV_PARAM_U16(0x000d, le_scan_interval),
- HDEV_PARAM_U16(0x000e, le_scan_window),
- HDEV_PARAM_U16(0x000f, le_scan_int_suspend),
- HDEV_PARAM_U16(0x0010, le_scan_window_suspend),
- HDEV_PARAM_U16(0x0011, le_scan_int_discovery),
- HDEV_PARAM_U16(0x0012, le_scan_window_discovery),
- HDEV_PARAM_U16(0x0013, le_scan_int_adv_monitor),
- HDEV_PARAM_U16(0x0014, le_scan_window_adv_monitor),
- HDEV_PARAM_U16(0x0015, le_scan_int_connect),
- HDEV_PARAM_U16(0x0016, le_scan_window_connect),
- HDEV_PARAM_U16(0x0017, le_conn_min_interval),
- HDEV_PARAM_U16(0x0018, le_conn_max_interval),
- HDEV_PARAM_U16(0x0019, le_conn_latency),
- HDEV_PARAM_U16(0x001a, le_supv_timeout),
- HDEV_PARAM_U16_JIFFIES_TO_MSECS(0x001b,
- def_le_autoconnect_timeout),
- HDEV_PARAM_U16(0x001d, advmon_allowlist_duration),
- HDEV_PARAM_U16(0x001e, advmon_no_filter_duration),
+ HDEV_PARAM_U16(def_page_scan_type);
+ HDEV_PARAM_U16(def_page_scan_int);
+ HDEV_PARAM_U16(def_page_scan_window);
+ HDEV_PARAM_U16(def_inq_scan_type);
+ HDEV_PARAM_U16(def_inq_scan_int);
+ HDEV_PARAM_U16(def_inq_scan_window);
+ HDEV_PARAM_U16(def_br_lsto);
+ HDEV_PARAM_U16(def_page_timeout);
+ HDEV_PARAM_U16(sniff_min_interval);
+ HDEV_PARAM_U16(sniff_max_interval);
+ HDEV_PARAM_U16(le_adv_min_interval);
+ HDEV_PARAM_U16(le_adv_max_interval);
+ HDEV_PARAM_U16(def_multi_adv_rotation_duration);
+ HDEV_PARAM_U16(le_scan_interval);
+ HDEV_PARAM_U16(le_scan_window);
+
[PATCH v8 4/6] Bluetooth: Handle active scan case
This patch adds code to handle the active scan during interleave
scan. The interleave scan will be canceled when users start active scan,
and it will be restarted after active scan stopped.
Signed-off-by: Howard Chung
Reviewed-by: Alain Michaud
Reviewed-by: Manish Mandlik
---
(no changes since v1)
net/bluetooth/hci_request.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/net/bluetooth/hci_request.c b/net/bluetooth/hci_request.c
index d943ad2885aa0..172ccbf4f0cd2 100644
--- a/net/bluetooth/hci_request.c
+++ b/net/bluetooth/hci_request.c
@@ -3099,8 +3099,10 @@ static int active_scan(struct hci_request *req, unsigned
long opt)
* running. Thus, we should temporarily stop it in order to set the
* discovery scanning parameters.
*/
- if (hci_dev_test_flag(hdev, HCI_LE_SCAN))
+ if (hci_dev_test_flag(hdev, HCI_LE_SCAN)) {
hci_req_add_le_scan_disable(req, false);
+ cancel_interleave_scan(hdev);
+ }
/* All active scans will be done with either a resolvable private
* address (when privacy feature has been enabled) or non-resolvable
--
2.29.2.222.g5d2a92d10f8-goog
[PATCH v8 3/6] Bluetooth: Handle system suspend resume case
This patch adds code to handle the system suspension during interleave
scan. The interleave scan will be canceled when the system is going to
sleep, and will be restarted after waking up.
Signed-off-by: Howard Chung
Reviewed-by: Alain Michaud
Reviewed-by: Manish Mandlik
Reviewed-by: Abhishek Pandit-Subedi
Reviewed-by: Miao-chen Chou
---
(no changes since v5)
Changes in v5:
- Remove the change in hci_req_config_le_suspend_scan
net/bluetooth/hci_request.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/net/bluetooth/hci_request.c b/net/bluetooth/hci_request.c
index 2fd56ee21d31f..d943ad2885aa0 100644
--- a/net/bluetooth/hci_request.c
+++ b/net/bluetooth/hci_request.c
@@ -1293,8 +1293,10 @@ void hci_req_prepare_suspend(struct hci_dev *hdev, enum
suspended_state next)
hci_req_add(&req, HCI_OP_WRITE_SCAN_ENABLE, 1, &page_scan);
/* Disable LE passive scan if enabled */
- if (hci_dev_test_flag(hdev, HCI_LE_SCAN))
+ if (hci_dev_test_flag(hdev, HCI_LE_SCAN)) {
+ cancel_interleave_scan(hdev);
hci_req_add_le_scan_disable(&req, false);
+ }
/* Mark task needing completion */
set_bit(SUSPEND_SCAN_DISABLE, hdev->suspend_tasks);
--
2.29.2.222.g5d2a92d10f8-goog
Re: [PATCH v7 07/22] perf arm-spe: Consolidate arm_spe_pkt_desc()'s return value
On Mon, Nov 09, 2020 at 04:52:35PM +, André Przywara wrote:
> On 06/11/2020 01:41, Leo Yan wrote:
> > arm_spe_pkt_desc() returns the length of consumed the buffer for
> > the success case; otherwise, it delivers the return value from
> > arm_spe_pkt_snprintf(), and returns the last return value if there have
> > multiple calling arm_spe_pkt_snprintf().
> >
> > Since arm_spe_pkt_snprintf() has the same semantics with vsnprintf() for
> > the return value, and vsnprintf() might return value equals to or bigger
> > than the parameter 'size' to indicate the truncation. Because the
> > return value is >= 0 when the string is truncated, this condition will
> > be returned up the stack as "success".
> >
> > This patch simplifies the return value for arm_spe_pkt_desc(): '0' means
> > success and other values mean an error has occurred. To realize this,
> > it relies on arm_spe_pkt_snprintf()'s parameter 'err', the 'err' is a
> > cumulative value, returns its final value if printing buffer is called
> > for one time or multiple times.
> >
> > To unify the error value generation, this patch handles error in a
> > central place, rather than directly bailing out in switch-cases,
> > it returns error at the end of arm_spe_pkt_desc().
>
> And the but-last hunk means it will basically always return 0?
Yes, if the buffer is overflow, the last chunk code tries to rollback
to dump the packet name, payload's raw data nd packet index. So in
theory, it should always return 0.
> Just checking, it's probably fine (and I don't want to review a v8 ;-)
> > This patch changes the caller arm_spe_dump() to respect the updated
> > return value semantics of arm_spe_pkt_desc().
> >
> > Suggested-by: Dave Martin
> > Signed-off-by: Leo Yan
>
> One tiny thing below ...
>
> > ---
> > .../arm-spe-decoder/arm-spe-pkt-decoder.c | 128 +-
> > tools/perf/util/arm-spe.c | 2 +-
> > 2 files changed, 68 insertions(+), 62 deletions(-)
> >
> > diff --git a/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c
> > b/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c
> > index 1970686f7020..33baef0c2c0b 100644
> > --- a/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c
> > +++ b/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c
> > @@ -301,9 +301,10 @@ static int arm_spe_pkt_snprintf(int *err, char
> > **buf_p, size_t *blen,
> > int arm_spe_pkt_desc(const struct arm_spe_pkt *packet, char *buf,
> > size_t buf_len)
> > {
> > - int ret, ns, el, idx = packet->index;
> > + int ns, el, idx = packet->index;
> > unsigned long long payload = packet->payload;
> > const char *name = arm_spe_pkt_name(packet->type);
> > + char *buf_orig = buf;
> > size_t blen = buf_len;
> > int err = 0;
> >
> > @@ -311,82 +312,76 @@ int arm_spe_pkt_desc(const struct arm_spe_pkt
> > *packet, char *buf,
> > case ARM_SPE_BAD:
> > case ARM_SPE_PAD:
> > case ARM_SPE_END:
> > - return arm_spe_pkt_snprintf(&err, &buf, &blen, "%s", name);
> > + arm_spe_pkt_snprintf(&err, &buf, &blen, "%s", name);
> > + break;
> > case ARM_SPE_EVENTS:
> > - ret = arm_spe_pkt_snprintf(&err, &buf, &blen, "EV");
> > + arm_spe_pkt_snprintf(&err, &buf, &blen, "EV");
> >
> > if (payload & 0x1)
> > - ret = arm_spe_pkt_snprintf(&err, &buf, &blen, "
> > EXCEPTION-GEN");
> > + arm_spe_pkt_snprintf(&err, &buf, &blen, "
> > EXCEPTION-GEN");
> > if (payload & 0x2)
> > - ret = arm_spe_pkt_snprintf(&err, &buf, &blen, "
> > RETIRED");
> > + arm_spe_pkt_snprintf(&err, &buf, &blen, " RETIRED");
> > if (payload & 0x4)
> > - ret = arm_spe_pkt_snprintf(&err, &buf, &blen, "
> > L1D-ACCESS");
> > + arm_spe_pkt_snprintf(&err, &buf, &blen, " L1D-ACCESS");
> > if (payload & 0x8)
> > - ret = arm_spe_pkt_snprintf(&err, &buf, &blen, "
> > L1D-REFILL");
> > + arm_spe_pkt_snprintf(&err, &buf, &blen, " L1D-REFILL");
> > if (payload & 0x10)
> > - ret = arm_spe_pkt_snprintf(&err, &buf, &blen, "
> > TLB-ACCESS");
> > + arm_spe_pkt_snprintf(&err, &buf, &blen, " TLB-ACCESS");
> > if (payload & 0x20)
> > - ret = arm_spe_pkt_snprintf(&err, &buf, &blen, "
> > TLB-REFILL");
> > + arm_spe_pkt_snprintf(&err, &buf, &blen, " TLB-REFILL");
> > if (payload & 0x40)
> > - ret = arm_spe_pkt_snprintf(&err, &buf, &blen, "
> > NOT-TAKEN");
> > + arm_spe_pkt_snprintf(&err, &buf, &blen, " NOT-TAKEN");
> > if (payload & 0x80)
> > - ret = arm_spe_pkt_snprintf(&err, &buf, &blen, "
> > MISPRED");
> > + arm_spe_pkt_snprintf(&err, &buf, &blen, " MISPRED");
> > if (idx > 1) {
> >
Re: [PATCH v36 00/13] /dev/random - a new approach
Am Montag, 19. Oktober 2020, 21:28:50 CET schrieb Stephan Müller: Hi, > > * Performance > > - Faster by up to 75% in the critical code path of the interrupt handler >depending on data collection size configurable at kernel compile time - >the default is about equal in performance with existing /dev/random as >outlined in [2] section 4.2. By streamlining the implementation a bit, the LRNG interrupt handler now operates about 130% faster than the existing /dev/random (average of 97 cycles of the existing /dev/random code vs. an average of 42 cycles of the LRNG). This fast operation is the default now due to patch [2]. The conceptual data handling outlined in [3] section 2.2 remains unchanged. Even the addition of health tests applied to the noise source data would still result in a faster interrupt handling code (average of 97 cycles of the existing /dev/random code vs on average 78 cycles of the LRNG). [1] https://github.com/smuellerDD/lrng/commit/ 10b74b242950371273e38df78060e258d9d3ea40 [2] https://github.com/smuellerDD/lrng/commit/ 383b087653c21cf20984f5508befa57e96f685ba [3] https://chronox.de/lrng/doc/lrng.pdf Ciao Stephan
[PATCH 2/2] phy: stm32: defer probe for reset controller
Change stm32-usbphyc driver to defer its probe when the expected reset
control has its probe operation deferred.
Signed-off-by: Etienne Carriere
Signed-off-by: Amelie Delaunay
---
drivers/phy/st/phy-stm32-usbphyc.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/phy/st/phy-stm32-usbphyc.c
b/drivers/phy/st/phy-stm32-usbphyc.c
index fe3085eec201..f3f582a3ccdb 100644
--- a/drivers/phy/st/phy-stm32-usbphyc.c
+++ b/drivers/phy/st/phy-stm32-usbphyc.c
@@ -342,6 +342,10 @@ static int stm32_usbphyc_probe(struct platform_device
*pdev)
reset_control_assert(usbphyc->rst);
udelay(2);
reset_control_deassert(usbphyc->rst);
+ } else {
+ ret = PTR_ERR(usbphyc->rst);
+ if (ret == -EPROBE_DEFER)
+ goto clk_disable;
}
usbphyc->switch_setup = -EINVAL;
--
2.17.1
[PATCH 1/2] phy: stm32: don't print an error on probe deferral
Change stm32-usbphyc driver to not print an error message when the device
probe operation is deferred.
Signed-off-by: Etienne Carriere
Signed-off-by: Amelie Delaunay
---
drivers/phy/st/phy-stm32-usbphyc.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/phy/st/phy-stm32-usbphyc.c
b/drivers/phy/st/phy-stm32-usbphyc.c
index 2b3639cba51a..fe3085eec201 100644
--- a/drivers/phy/st/phy-stm32-usbphyc.c
+++ b/drivers/phy/st/phy-stm32-usbphyc.c
@@ -328,11 +328,8 @@ static int stm32_usbphyc_probe(struct platform_device
*pdev)
return PTR_ERR(usbphyc->base);
usbphyc->clk = devm_clk_get(dev, NULL);
- if (IS_ERR(usbphyc->clk)) {
- ret = PTR_ERR(usbphyc->clk);
- dev_err(dev, "clk get failed: %d\n", ret);
- return ret;
- }
+ if (IS_ERR(usbphyc->clk))
+ dev_err_probe(dev, PTR_ERR(usbphyc->clk), "clk get_failed\n");
ret = clk_prepare_enable(usbphyc->clk);
if (ret) {
--
2.17.1
[PATCH v2 2/3] dt-bindings: arm: stm32: add extra SiP compatible for lxa,stm32mp157c-mc1
The Linux Automation MC-1 is built around an OSD32MP15x SiP with CPU, RAM, PMIC, Oscillator and EEPROM. Adjust the binding, so the SiP compatible is contained as well. This allows boot firmware to match against it to apply fixups if necessary. Signed-off-by: Ahmad Fatoum --- v1 -> v2: - split up binding and device tree change --- Documentation/devicetree/bindings/arm/stm32/stm32.yaml | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/arm/stm32/stm32.yaml b/Documentation/devicetree/bindings/arm/stm32/stm32.yaml index 009b424e456e..9127094f0208 100644 --- a/Documentation/devicetree/bindings/arm/stm32/stm32.yaml +++ b/Documentation/devicetree/bindings/arm/stm32/stm32.yaml @@ -40,7 +40,6 @@ properties: - items: - enum: - arrow,stm32mp157a-avenger96 # Avenger96 - - lxa,stm32mp157c-mc1 - shiratech,stm32mp157a-iot-box # IoT Box - shiratech,stm32mp157a-stinger96 # Stinger96 - st,stm32mp157c-ed1 @@ -52,6 +51,13 @@ properties: - const: st,stm32mp157c-ev1 - const: st,stm32mp157c-ed1 - const: st,stm32mp157 + - description: Octavo OSD32MP15x System-in-Package based boards +items: + - enum: + - lxa,stm32mp157c-mc1 # Linux Automation MC-1 + - const: oct,stm32mp15xx-osd32 + - enum: + - st,stm32mp157 - description: Odyssey STM32MP1 SoM based Boards items: - enum: -- 2.28.0
Re: [PATCH] phy: phylink: Fix CuSFP issue in phylink
On Tue, Nov 10, 2020 at 11:06:42AM +0100, Bjarni Jonasson wrote: > There is an issue with the current phylink driver and CuSFPs which > results in a callback to the phylink validate function without any > advertisement capabilities. The workaround (in this changeset) > is to assign capabilities if a 1000baseT SFP is identified. How does this happen? Which PHY is being used? -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
[PATCH v2 1/3] dt-bindings: vendor-prefixes: document Octavo Systems oct prefix
Octavo Systems is an American company specializing in design and manufacturing of System-in-Package devices. The prefix is already in use for the Octavo Systems OSD3358-SM-RED device tree, but was so far undocumented. Fix this. Cc: Neeraj Dantu Signed-off-by: Ahmad Fatoum --- v1 -> v2: - new patch, suggested by Rob --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index a682f88f9a56..ff7a8abe5590 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -762,6 +762,8 @@ patternProperties: description: NXP Semiconductors "^oceanic,.*": description: Oceanic Systems (UK) Ltd. + "^oct,.*": +description: Octavo Systems LLC "^okaya,.*": description: Okaya Electric America, Inc. "^oki,.*": -- 2.28.0
[PATCH v2 3/3] ARM: dts: stm32: lxa-mc1: add OSD32MP15x to list of compatibles
Earlier commit modified the binding, so the SiP is to be specified
as well. Adjust the device tree accordingly.
Signed-off-by: Ahmad Fatoum
---
v1 -> v2:
- split up binding and device tree change
---
arch/arm/boot/dts/stm32mp157c-lxa-mc1.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/stm32mp157c-lxa-mc1.dts
b/arch/arm/boot/dts/stm32mp157c-lxa-mc1.dts
index 1e5333fd437f..cda8e871f999 100644
--- a/arch/arm/boot/dts/stm32mp157c-lxa-mc1.dts
+++ b/arch/arm/boot/dts/stm32mp157c-lxa-mc1.dts
@@ -15,7 +15,7 @@
/ {
model = "Linux Automation MC-1 board";
- compatible = "lxa,stm32mp157c-mc1", "st,stm32mp157";
+ compatible = "lxa,stm32mp157c-mc1", "oct,stm32mp15xx-osd32",
"st,stm32mp157";
aliases {
ethernet0 = ðernet0;
--
2.28.0
Re: [PATCH v1] dt-bindings: arm: stm32: lxa,stm32mp157c-mc1: add extra SiP compatible
Hello Rob, On 11/9/20 5:37 PM, Rob Herring wrote: > On Wed, Nov 04, 2020 at 12:39:31PM +0100, Ahmad Fatoum wrote: >> I know that bindings and device tree patches should be separate. Does >> this apply here as well? Should I split the dts change into a follow-up >> commit? > > Yes. > >> Is it ok that dtbs_check will report an intermittent breakage? > > If the binding comes first, it won't break. > > But generally, 'dtbs_check' being warning free is not yet a requirement. > That will probably first have to be per platform. here the old binding is deleted, so between the patches, there will be a dtbs_check warning, which is why I asked. I've now split it up with binding first. >> + - const: oct,stm32mp15xx-osd32 > > 'oct' is not docuemnted in vendor-prefixes.yaml. Huh, I only checked whether it's in use, not if it's documented. I just sent out a v2 with your points addressed. Thanks for review, Ahmad -- 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 v4 06/17] PCI: add SIOV and IMS capability detection
Ashok, On Mon, Nov 09 2020 at 21:14, Ashok Raj wrote: > On Mon, Nov 09, 2020 at 11:42:29PM +0100, Thomas Gleixner wrote: >> On Mon, Nov 09 2020 at 13:30, Jason Gunthorpe wrote: > Approach to IMS is more of a phased approach. > > #1 Allow physical device to scale beyond limits of PCIe MSIx >Follows current methodology for guest interrupt programming and >evolutionary changes rather than drastic. Trapping MSI[X] writes is there because it allows to hand a device to an unmodified guest OS and to handle the case where the MSI[X] entries storage cannot be mapped exclusively to the guest. But aside of this, it's not required if the storage can be mapped exclusively, the guest is hypervisor aware and can get a host composed message via a hypercall. That works for physical functions and SRIOV, but not for SIOV. > #2 Long term we should work together on enabling IMS in guest which >requires changes in both HW and SW eco-system. > > For #1, the immediate need is to find a way to limit guest from using IMS > due to current limitations. We have couple options. > > a) CPUID based method to disallow IMS when running in a guest OS. Limiting >use to existing virtual MSIx to guest devices. (Both you/Jason alluded) > b) We can extend DMAR table to have a flag for opt-out. So in real platform >this flag is clear and in guest VMM will ensure vDMAR will have this flag >set. Along the lines as Jason alluded, platform level and via ACPI >methods. We have similar use for x2apic_optout today. > > Think a) is probably more generic. But incomplete as I explained before. If the VMM does not set the hypervisor bit in CPUID then the guest OS assumes to run on bare metal. It needs more than just relying on CPUID. Aside of that neither Jason nor myself said that IMS cannot be supported in a guest. PF and VF IMS can and has to be supported. SIOV is a different story due to the PASID requirement which obviously needs to be managed host side and needs HW changes. > From SW improvements: > > - Hypercall to retrieve addr/data from host You need to have that even for the non SIOV case in order to hand in a full device which has the IMS storage in queue memory. > Devices such as idxd that do not have these entries on page-boundaries for > isolation to permit direct programming from GuestOS will continue to use > trap-emulate as used today. That's a restriction of that particular hardware. > Until then, IMS will be restricted to host VMM only, and we can use the > methods above to prevent IMS in guest and continue to use the legacy > virtual MSIx. SIOV IMS. But as things stand now not even PF/VF pass through are possible. This might not be an issue for IDXD, but it's an issue in general and this want's the be thought of _now_ before we put a lot of infrastructure in to place which needs then to be ripped apart again. >> The current specification puts massive restrictions on IMS storage which >> are _not_ allowing to optimize it in a device specific manner as >> demonstrated in this discussion. > > IMS doesn't restrict this optimization, but to allow it requires more > OS support as you had mentioned. Right, IMS per se does not put an restriction on it. The specification and the HW limitations on the remapping unit put that restriction into place. OS support is an obvious requirement, but OS support cannot make the restrictions of HW go away magically. But again, we need to think about the path forward _now_. Just slapping some 'works for IDXD' solution into place can severly restrict the options for going beyond these limitations simply because we have to support that 'works for IDXD thing' forever. Thanks, tglx
Re: [PATCH 4.9 000/117] 4.9.242-rc1 review
On Mon, 9 Nov 2020 at 18:30, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.9.242 release. > There are 117 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Wed, 11 Nov 2020 12:50:04 +. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.242-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.9.y > and the diffstat can be found below. > > thanks, > > greg k-h > Results from Linaro’s test farm. No regressions on arm64, arm, x86_64, and i386. Tested-by: Linux Kernel Functional Testing Summary kernel: 4.9.242-rc1 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-4.9.y git commit: 8c35ccda0e15d9e502046f5a33f6a1e0fdea56d5 git describe: v4.9.241-118-g8c35ccda0e15 Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-4.9.y/build/v4.9.241-118-g8c35ccda0e15 No regressions (compared to build v4.9.241) No fixes (compared to build v4.9.241) Ran 29032 total tests in the following environments and test suites. Environments -- - dragonboard-410c - arm64 - hi6220-hikey - arm64 - i386 - juno-r2 - arm64 - juno-r2-compat - juno-r2-kasan - qemu-arm64-kasan - qemu-x86_64-kasan - qemu_arm - qemu_arm64 - qemu_arm64-compat - qemu_i386 - qemu_x86_64 - qemu_x86_64-compat - x15 - arm - x86_64 - x86-kasan Test Suites --- * build * install-android-platform-tools-r2600 * libhugetlbfs * linux-log-parser * ltp-cap_bounds-tests * ltp-commands-tests * ltp-containers-tests * ltp-controllers-tests * ltp-cpuhotplug-tests * ltp-crypto-tests * ltp-dio-tests * ltp-fcntl-locktests-tests * ltp-filecaps-tests * ltp-fs-tests * ltp-fs_bind-tests * ltp-fs_perms_simple-tests * ltp-fsx-tests * ltp-hugetlb-tests * ltp-io-tests * ltp-ipc-tests * ltp-math-tests * ltp-mm-tests * ltp-nptl-tests * ltp-pty-tests * ltp-sched-tests * ltp-securebits-tests * perf * ltp-cve-tests * network-basic-tests * v4l2-compliance * ltp-open-posix-tests * ltp-syscalls-tests * ltp-tracing-tests * kvm-unit-tests -- Linaro LKFT https://lkft.linaro.org
Re: [PATCH v2 1/2] dt-bindings: arm: stm32: add simple-mfd compatible for tamp node
Hello Alex, On 10/27/20 1:15 PM, Rob Herring wrote: > On Mon, Oct 26, 2020 at 4:30 PM Ahmad Fatoum wrote: >> >> Hello Rob, >> >> On 10/26/20 3:36 PM, Rob Herring wrote: >>> On Wed, Oct 21, 2020 at 12:28:55PM +0200, Ahmad Fatoum wrote: The stm32mp1 TAMP (Tamper and backup registers) does tamper detection and features 32 backup registers that, being in the RTC domain, may survive even with Vdd switched off. This makes it suitable for use to communicate a reboot mode from OS to bootloader via the syscon-reboot-mode binding. Add a "simple-mfd" to support probing such a child node. The actual reboot mode node could then be defined in a board.dts or fixed up by the bootloader. >>> >>> 'simple-mfd' implies there is no dependency on the parent node for the >>> child (such as the regmap perhaps). Is that the case here? >> >> No, there's a dependency and the Linux driver does syscon_node_to_regmap >> on the device tree node's parent but that's how the syscon-reboot-mode >> binding >> is documented: >> >> The SYSCON mapped register is retrieved from the >> parental dt-node plus the offset. So the SYSCON reboot-mode node >> should be represented as a sub-node of a "syscon", "simple-mfd" node. >> >> How would you prefer this being done instead? > > Well, probably the syscon driver could just probe any children, but > I'm not sure if that would break anyone. So I guess fine as-is. > > Reviewed-by: Rob Herring Gentle ping. > > Rob > -- 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/3] docs: media: Document CLL and Mastering display
On 11/10/20 11:50 AM, Hans Verkuil wrote: > On 09/11/2020 18:31, Stanimir Varbanov wrote: >> Document Content light level and Mastering display colour volume. >> >> Signed-off-by: Stanimir Varbanov >> --- >> .../media/v4l/ext-ctrls-codec.rst | 61 +++ >> 1 file changed, 61 insertions(+) >> >> diff --git a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst >> b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst >> index ce728c757eaf..39d0aab5ca3d 100644 >> --- a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst >> +++ b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst >> @@ -4382,3 +4382,64 @@ enum v4l2_mpeg_video_hevc_size_of_length_field - >>- Selecting this value specifies that HEVC slices are expected >> to be prefixed by Annex B start codes. According to :ref:`hevc` >> valid start codes can be 3-bytes 0x01 or 4-bytes 0x0001. >> + >> +``V4L2_CID_MPEG_VIDEO_HEVC_CLL_INFO (struct)`` >> +The Content Light Level defines upper bounds for the nominal target >> +brightness light level of the pictures. >> + >> +.. c:type:: v4l2_ctrl_hevc_cll_info >> + >> +.. cssclass:: longtable >> + >> +.. flat-table:: struct v4l2_ctrl_hevc_cll_info >> +:header-rows: 0 >> +:stub-columns: 0 >> +:widths: 1 1 2 >> + >> +* - __u16 >> + - ``max_content_light_level`` >> + - An upper bound on the maximum light level among all individual >> +samples for the pictures of coded video sequence, cd/m2. >> +* - __u16 >> + - ``max_pic_average_light_level`` >> + - An upper bound on the maximum average light level among the >> +samples for any idividual picture of coded video sequence, cd/m2. > > idividual -> individual > > In the CTA-861-G spec value 0 is used to indicate that this information is > not present. How is that handled here? Can it be 0 as well in an HEVC stream? ITU-T Rec. H265 says: When equal to 0, no such upper bound is indicated by max_content_light_level. So, the meaning is the same as in CTA-861-G. > > Same for the next control. > >> + >> +``V4L2_CID_MPEG_VIDEO_HEVC_MASTERING_DISPLAY (struct)`` >> +The mastering display defines the colour volume (the colour primaries, >> +white point and luminance range) of a display considered to be the >> +mastering display for current video content. >> + >> +.. c:type:: v4l2_ctrl_hevc_mastering_display >> + >> +.. cssclass:: longtable >> + >> +.. flat-table:: struct v4l2_ctrl_hevc_mastering_display >> +:header-rows: 0 >> +:stub-columns: 0 >> +:widths: 1 1 2 >> + >> +* - __u16 >> + - ``display_primaries_x[3]`` >> + - Specifies the normalized x chromaticity coordinate of the colour >> +primary component of the mastering display. > > CTA-861-G defines this as: "coded as unsigned 16-bit values in units > of 0.2, where 0x represents zero and 0xC350 represents 1.." > > Is that true here as well? If so, then this should be documented because > "normalized x chromaticity coordinate" doesn't say anything meaningful. Yes, it is the same. Will document that in next version. > >> +* - __u16 >> + - ``display_primaries_y[3]`` >> + - Specifies the normalized y chromaticity coordinate of the colour >> +primary component of the mastering display. >> +* - __u16 >> + - ``white_point_x`` >> + - Specifies the normalized x chromaticity coordinate of the white >> +point of the mastering display. >> +* - __u16 >> + - ``white_point_y`` >> + - Specifies the normalized y chromaticity coordinate of the white >> +point of the mastering display. >> +* - __u32 >> + - ``max_luminance`` >> + - Specifies the nominal maximum display luminance of the mastering >> +display. > > In CTA-861-G this is in 1 cd/m^2 units. In Rec. H265 max_luminance is in the range of 50 000 to 100 000 000 and units of 0.0001 cd/m2. > >> +* - __u32 >> + - ``min_luminance`` >> + - specifies the nominal minimum display luminance of the mastering >> +display. > > And this in units of 0.0001 cd/m^2. min_luminance - range of 1 to 50 000 and units of 0.0001 cd/m2. I will update all these in next patchset version. > > Regards, > > Hans > -- regards, Stan
Re: [PATCH] MIPS: reserve the memblock right after the kernel
Hello Thomas, On 10/11/2020 10:55, Thomas Bogendoerfer wrote: Linux doesn't own the memory immediately after the kernel image. On Octeon bootloader places a shared structure right close after the kernel _end, refer to "struct cvmx_bootinfo *octeon_bootinfo" in cavium-octeon/setup.c. If check_kernel_sections_mem() rounds the PFNs up, first memblock_alloc() inside early_init_dt_alloc_memory_arch() <= device_tree_init() returns memory block overlapping with the above octeon_bootinfo structure, which is being overwritten afterwards. >>> as this special for Octeon how about added the memblock_reserve >>> in octen specific code ? >> while the shared structure which is being corrupted is indeed >> Octeon-specific, >> the wrong assumption that the memory right after the kernel can be allocated >> by memblock >> allocator and re-used somewhere in Linux is in MIPS-generic >> check_kernel_sections_mem(). > ok, I see your point. IMHO this whole check_kernel_sections_mem() should > be removed. IMHO memory adding should only be done my memory detection code. > > Could you send a patch, which removes check_kernel_section_mem completly ? this will expose one issue: platforms usually do it in a sane way, like it was done last 15 years, namely add kernel image without non-complete pages on the boundaries. This will lead to the situation, that request_resource() will fail at least for .bss section of the kernel and it will not be properly displayed under /proc/iomem (and probably same problem will appear, which initially motivated the creation of check_kernel_section_mem()). As I understood, the issue is that memblock API operates internally on the page granularity (at least there are many ROUND_DOWN() inside for the size or upper boundary), so for request_resource() to success one has to claim the rest of the .bss last page. And with current memblock API memblock_reserve() must appear somewhere, being this ARCH or platform code. -- Best regards, Alexander Sverdlin.
Re: [RFC PATCH 6/7] preempt/dynamic: Provide irqentry_exit_cond_resched() static call
On Tue, Nov 10, 2020 at 01:56:08AM +0100, Frederic Weisbecker wrote:
> [convert from static key to static call, only define static call when
> PREEMPT_DYNAMIC]
> noinstr void irqentry_exit(struct pt_regs *regs, irqentry_state_t state)
> {
> @@ -383,8 +386,13 @@ noinstr void irqentry_exit(struct pt_regs *regs,
> irqentry_state_t state)
> }
>
> instrumentation_begin();
> - if (IS_ENABLED(CONFIG_PREEMPTION))
> + if (IS_ENABLED(CONFIG_PREEMPTION)) {
> +#ifdef CONFIG_PREEMT_DYNAMIC
> + static_call(irqentry_exit_cond_resched)();
> +#else
> irqentry_exit_cond_resched();
> +#endif
> + }
> /* Covers both tracing and lockdep */
> trace_hardirqs_on();
> instrumentation_end();
The reason I had this a static_branch() is that because if you look at
the code-gen of this function, you'll find it will inline the call.
Not sure it matters much, but it avoids a CALL+RET.
Re: [PATCH v6 1/2] kunit: Support for Parameterized Testing
On Tue, 10 Nov 2020 at 08:21, David Gow wrote: [...] > > > > > > The previous attempt [1] at something similar failed because it seems > > > we'd need to teach kunit-tool new tricks [2], too. > > > [1] https://lkml.kernel.org/r/20201105195503.ga2399...@elver.google.com > > > [2] https://lkml.kernel.org/r/20201106123433.ga3563...@elver.google.com > > > > > > So if we go with a different format, we might need a patch before this > > > one to make kunit-tool compatible with that type of diagnostic. > > > > > > Currently I think we have the following proposals for a format: > > > > > > 1. The current "# [test_case->name]: param-[index] [ok|not ok]" -- > > > this works well, because no changes to kunit-tool are required, and it > > > also picks up the diagnostic context for the case and displays that on > > > test failure. > > > > > > 2. Your proposed "# [ok|not ok] - [test_case->name]:param-[index]". > > > As-is, this needs a patch for kunit-tool as well. I just checked, and > > > if we change it to "# [ok|not ok] - [test_case->name]: param-[index]" > > > (note the space after ':') it works without changing kunit-tool. ;-) > > > > > > 3. Something like "# [ok|not ok] param-[index] - [test_case->name]", > > > which I had played with earlier but kunit-tool is definitely not yet > > > happy with. > > > > > > So my current preference is (2) with the extra space (no change to > > > kunit-tool required). WDYT? > > > > > Hmm… that failure in kunit_tool is definitely a bug: we shouldn't care > what comes after the comment character except if it's an explicit > subtest declaration or a crash. I'll try to put a patch together to > fix it, but I'd rather not delay this just for that. > > In any thought about this a bit more, It turns out that the proposed > KTAP spec[1] discourages the use of ':', except as part of a subtest > declaration, or perhaps an as-yet-unspecified fully-qualified test > name. The latter is what I was going for, but if it's actively > breaking kunit_tool, we might want to hold off on it. > > If we were to try to treat these as subtests in accordance with that > spec, the way we'd want to use one of these options: > A) "[ok|not ok] [index] - param-[index]" -- This doesn't mention the > test case name, but otherwise treats things exactly the same way we > treat existing subtests. > > B) "[ok|not ok] [index] - [test_case->name]" -- This doesn't name the > "subtest", just gives repeated results with the same name. > > C) "[ok|not ok] [index] - [test_case->name][separator]param-[index]" > -- This is equivalent to my suggestion with a separator of ":", or 2 > above with a separator of ": ". The in-progress spec doesn't yet > specify how these fully-qualified names would work, other than that > they'd use a colon somewhere, and if we comment it out, ": " is > required. > > > > > Which format do we finally go with? > > > > I'm actually going to make another wild suggestion for this, which is > a combination of (1) and (A): > "# [test_case->name]: [ok|not ok] [index] - param-[index]" > > This gives us a KTAP-compliant result line, except prepended with "# > [test_case->name]: ", which makes it formally a diagnostic line, > rather than an actual subtest. Putting the test name at the start > matches what kunit_tool is expecting at the moment. If we then want to > turn it into a proper subtest, we can just get rid of that prefix (and > add the appropriate counts elsewhere). > > Does that sound good? Sounds reasonable to me! The repetition of [index] seems unnecessary for now, but I think if we at some point have a way to get a string representation of a param, we can substitute param-[index] with a string that represents the param. Note that once we want to make it a real subtest, we'd need to run the generator twice, once to get the number of params and then to run the tests. If we require that param generators are deterministic in the number of params generated, this is not a problem. Thanks, -- Marco
Re: [PATCH 4.4 00/86] 4.4.242-rc1 review
On Mon, 9 Nov 2020 at 18:32, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.4.242 release. > There are 86 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Wed, 11 Nov 2020 12:50:04 +. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.242-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.4.y > and the diffstat can be found below. > > thanks, > > greg k-h Results from Linaro’s test farm. No regressions on arm64, arm, x86_64, and i386. Tested-by: Linux Kernel Functional Testing Summary kernel: 4.4.242-rc1 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-4.4.y git commit: cbe5dd8b360451802fb7f6b2491f6a67688e50c8 git describe: v4.4.241-87-gcbe5dd8b3604 Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-4.4.y/build/v4.4.241-87-gcbe5dd8b3604 No regressions (compared to build v4.4.241) No fixes (compared to build v4.4.241) Ran 18073 total tests in the following environments and test suites. Environments -- - i386 - juno-r2 - arm64 - juno-r2-kasan - qemu-arm64-kasan - qemu-x86_64-kasan - qemu_arm - qemu_arm64 - qemu_arm64-compat - qemu_i386 - qemu_x86_64 - qemu_x86_64-compat - x15 - arm - x86_64 - x86-kasan Test Suites --- * build * libhugetlbfs * linux-log-parser * ltp-cap_bounds-tests * ltp-commands-tests * ltp-containers-tests * ltp-controllers-tests * ltp-cpuhotplug-tests * ltp-crypto-tests * ltp-cve-tests * ltp-dio-tests * ltp-fcntl-locktests-tests * ltp-filecaps-tests * ltp-fs-tests * ltp-fs_bind-tests * ltp-fs_perms_simple-tests * ltp-fsx-tests * ltp-hugetlb-tests * ltp-io-tests * ltp-ipc-tests * ltp-math-tests * ltp-mm-tests * ltp-nptl-tests * ltp-open-posix-tests * ltp-pty-tests * ltp-sched-tests * ltp-securebits-tests * ltp-syscalls-tests * ltp-tracing-tests * network-basic-tests * perf * v4l2-compliance * install-android-platform-tools-r2600 * kvm-unit-tests Summary kernel: 4.4.242-rc1 git repo: https://git.linaro.org/lkft/arm64-stable-rc.git git branch: 4.4.242-rc1-hikey-20201109-853 git commit: d32ad0aa87e9a15f22c90c3ea1ea1355264954ef git describe: 4.4.242-rc1-hikey-20201109-853 Test details: https://qa-reports.linaro.org/lkft/linaro-hikey-stable-rc-4.4-oe/build/4.4.242-rc1-hikey-20201109-853 No regressions (compared to build 4.4.242-rc1-hikey-20201108-851) No fixes (compared to build 4.4.242-rc1-hikey-20201108-851) Ran 1730 total tests in the following environments and test suites. Environments -- - hi6220-hikey - arm64 Test Suites --- * build * install-android-platform-tools-r2600 * libhugetlbfs * linux-log-parser * ltp-cap_bounds-tests * ltp-commands-tests * ltp-containers-tests * ltp-cpuhotplug-tests * ltp-cve-tests * ltp-fcntl-locktests-tests * ltp-filecaps-tests * ltp-fs-tests * ltp-fs_bind-tests * ltp-fs_perms_simple-tests * ltp-fsx-tests * ltp-hugetlb-tests * ltp-io-tests * ltp-ipc-tests * ltp-math-tests * ltp-mm-tests * ltp-nptl-tests * ltp-pty-tests * ltp-sched-tests * ltp-securebits-tests * ltp-syscalls-tests * perf * spectre-meltdown-checker-test * v4l2-compliance -- Linaro LKFT https://lkft.linaro.org
Re: [PATCH 3/3] arm64: allwinner: dts: a64: add DT for PineTab developer sample
On Sat, Nov 07, 2020 at 08:53:32PM +0800, Icenowy Zheng wrote:
> Some developers received PineTab samples that used an old LCD panel.
>
> Add device tree for these samples.
>
> Signed-off-by: Icenowy Zheng
> ---
> arch/arm64/boot/dts/allwinner/Makefile| 1 +
> .../dts/allwinner/sun50i-a64-pinetab-dev.dts | 28 +++
> 2 files changed, 29 insertions(+)
> create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab-dev.dts
>
> diff --git a/arch/arm64/boot/dts/allwinner/Makefile
> b/arch/arm64/boot/dts/allwinner/Makefile
> index 211d1e9d4701..a221dcebfad4 100644
> --- a/arch/arm64/boot/dts/allwinner/Makefile
> +++ b/arch/arm64/boot/dts/allwinner/Makefile
> @@ -13,6 +13,7 @@ dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinephone-1.0.dtb
> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinephone-1.1.dtb
> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinephone-1.2.dtb
> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinetab.dtb
> +dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinetab-dev.dtb
> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-sopine-baseboard.dtb
> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-teres-i.dtb
> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a100-allwinner-perf1.dtb
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab-dev.dts
> b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab-dev.dts
> new file mode 100644
> index ..3a4153890f3e
> --- /dev/null
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab-dev.dts
> @@ -0,0 +1,28 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright (C) 2020 Icenowy Zheng
> + *
> + */
> +
> +/dts-v1/;
> +
> +#include "sun50i-a64-pinetab.dts"
> +
> +/ {
> + model = "PineTab Developer Sample";
> + compatible = "pine64,pinetab-dev", "allwinner,sun50i-a64";
> +};
Changing the DT and the compatible half-way through it isn't ok. Please
add a new DT with the newer revision like we did for the pinephone
Maxime
signature.asc
Description: PGP signature
Re: [PATCH V8 2/5] mfd: Intel Platform Monitoring Technology support
Hi David,
On Sat, Oct 3, 2020 at 3:32 AM David E. Box wrote:
> Intel Platform Monitoring Technology (PMT) is an architecture for
> enumerating and accessing hardware monitoring facilities. PMT supports
> multiple types of monitoring capabilities. This driver creates platform
> devices for each type so that they may be managed by capability specific
> drivers (to be introduced). Capabilities are discovered using PCIe DVSEC
> ids. Support is included for the 3 current capability types, Telemetry,
> Watcher, and Crashlog. The features are available on new Intel platforms
> starting from Tiger Lake for which support is added. This patch adds
> support for Tiger Lake (TGL), Alder Lake (ADL), and Out-of-Band Management
> Services Module (OOBMSM).
>
> Also add a quirk mechanism for several early hardware differences and bugs.
> For Tiger Lake and Alder Lake, do not support Watcher and Crashlog
> capabilities since they will not be compatible with future product. Also,
> fix use a quirk to fix the discovery table offset.
>
> Co-developed-by: Alexander Duyck
> Signed-off-by: Alexander Duyck
> Signed-off-by: David E. Box
> Reviewed-by: Andy Shevchenko
Thanks for your patch, which is now commit 4f8217d5b0ca8ace ("mfd: Intel
Platform Monitoring Technology support") in the mfd/for-mfd-next.
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -670,6 +670,16 @@ config MFD_INTEL_PMC_BXT
> Register and P-unit access. In addition this creates devices
> for iTCO watchdog and telemetry that are part of the PMC.
>
> +config MFD_INTEL_PMT
> + tristate "Intel Platform Monitoring Technology (PMT) support"
> + depends on PCI
Does this need a "depend on X86 || COMPILE_TEST", to prevent the
question from showing up on platforms where the PMT cannot be present?
I see the TGL and ADL PCI IDs are also referenced from
drivers/platform/x86/intel_pmt_telemetry.c, which suggests this is X86-only.
Perhaps the OOBMSM is a PCI device that can be used on non-X86 platforms?
> + select MFD_CORE
> + help
> + The Intel Platform Monitoring Technology (PMT) is an interface that
> + provides access to hardware monitor registers. This driver supports
> + Telemetry, Watcher, and Crashlog PMT capabilities/devices for
> + platforms starting from Tiger Lake.
> +
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [RFC PATCH 4/7] preempt/dynamic: Provide cond_resched() and might_resched() static calls
On Tue, Nov 10, 2020 at 01:56:06AM +0100, Frederic Weisbecker wrote: > +#ifdef CONFIG_PREEMPT_DYNAMIC > +DEFINE_STATIC_CALL(cond_resched, __static_call_return0); > +EXPORT_STATIC_CALL(cond_resched); > + > +DEFINE_STATIC_CALL(might_resched, __static_call_return0); > +EXPORT_STATIC_CALL(might_resched); > #endif I suppose we want the below and change the above to use EXPORT_STATIC_CALL_TRAMP(). --- Subject: static_call: EXPORT_STATIC_CALL_TRAMP() From: Peter Zijlstra Date: Tue Nov 10 11:37:48 CET 2020 For when we want to allow modules to call the static_call() but not change it. Signed-off-by: Peter Zijlstra (Intel) --- include/linux/static_call.h | 23 +++ 1 file changed, 19 insertions(+), 4 deletions(-) --- a/include/linux/static_call.h +++ b/include/linux/static_call.h @@ -160,13 +160,19 @@ extern int static_call_text_reserved(voi #define static_call_cond(name) (void)__static_call(name) +#define EXPORT_STATIC_CALL_TRAMP(name) \ + EXPORT_SYMBOL(STATIC_CALL_TRAMP(name)) + #define EXPORT_STATIC_CALL(name) \ EXPORT_SYMBOL(STATIC_CALL_KEY(name)); \ - EXPORT_SYMBOL(STATIC_CALL_TRAMP(name)) + EXPORT_STATIC_CALL_TRAMP(name) + +#define EXPORT_STATIC_CALL_TRAMP_GPL(name) \ + EXPORT_SYMBOL_GPL(STATIC_CALL_TRAMP(name)) #define EXPORT_STATIC_CALL_GPL(name) \ EXPORT_SYMBOL_GPL(STATIC_CALL_KEY(name)); \ - EXPORT_SYMBOL_GPL(STATIC_CALL_TRAMP(name)) + EXPORT_STATIC_CALL_TRAMP_GPL(name) #elif defined(CONFIG_HAVE_STATIC_CALL) @@ -206,13 +212,19 @@ static inline int static_call_text_reser return 0; } +#define EXPORT_STATIC_CALL_TRAMP(name) \ + EXPORT_SYMBOL(STATIC_CALL_TRAMP(name)) + #define EXPORT_STATIC_CALL(name) \ EXPORT_SYMBOL(STATIC_CALL_KEY(name)); \ - EXPORT_SYMBOL(STATIC_CALL_TRAMP(name)) + EXPORT_STATIC_CALL_TRAMP(name) + +#define EXPORT_STATIC_CALL_TRAMP_GPL(name) \ + EXPORT_SYMBOL_GPL(STATIC_CALL_TRAMP(name)) #define EXPORT_STATIC_CALL_GPL(name) \ EXPORT_SYMBOL_GPL(STATIC_CALL_KEY(name)); \ - EXPORT_SYMBOL_GPL(STATIC_CALL_TRAMP(name)) + EXPORT_STATIC_CALL_TRAMP_GPL(name) #else /* Generic implementation */ @@ -269,6 +281,9 @@ static inline int static_call_text_reser return 0; } +#define EXPORT_STATIC_CALL_TRAMP(name) +#define EXPORT_STATIC_CALL_TRAMP_GPL(name) + #define EXPORT_STATIC_CALL(name) EXPORT_SYMBOL(STATIC_CALL_KEY(name)) #define EXPORT_STATIC_CALL_GPL(name) EXPORT_SYMBOL_GPL(STATIC_CALL_KEY(name))
Re: [PATCH] x86/mce: Check for hypervisor before enabling additional error logging
On 10/11/20 10:56, Borislav Petkov wrote: On Tue, Nov 10, 2020 at 09:50:43AM +0100, Paolo Bonzini wrote: 1) ignore_msrs _cannot_ be on by default. You cannot know in advance that for all non-architectural MSRs it's okay for them to read as zero and eat writes. For some non-architectural MSR which never reads as zero on real hardware, who knows that there isn't some code using the contents of the MSR as a divisor, and causing a division by zero exception with ignore_msrs=1? So if you're emulating a certain type of hardware - say a certain CPU model - then what are you saying? That you're emulating it but not really all of it, just some bits? We try to emulate all that is described in the SDM as architectural, as long as we expose the corresponding CPUID leaves. However, f/m/s mean nothing when running virtualized. First, trying to derive any non-architectural property from the f/m/s is going to fail. Second, even the host can be anything as long as it's newer than the f/m/s that the VM reports (i.e. you can get a Sandy Bridge model and model name even if running on Skylake). Also, X86_FEATURE_HYPERVISOR might be clear even if running virtualized. (Thank you nVidia for using it to play market segmentation games). Because this is what happens - the kernel checks that it runs on a certain CPU type and this tells it that those MSRs are there. But then comes virt and throws all assumptions out. So if it emulates a CPU model and the kernel tries to access those MSRs, then the HV should ignore those MSR accesses if it doesn't know about them. Why should the kernel change everytime some tool or virtualization has shortcomings? See above: how can the hypervisor know a safe value for all MSRs, possibly including the undocumented ones? 3) because of (1) and (2), the solution is very simple. If the MSR is architectural, its absence is a KVM bug and we'll fix it in all stable versions. If the MSR is not architectural (and 17Fh isn't; not only it's not mentioned in the SDM, It is mentioned in the SDM. Oh right they moved the MSRs to a separate manual; found it now. Still, it's not architectural. But maybe we should have a choice and maybe qemu/kvm should have a way to ignore certain MSRs for certain CPU types, regardless of them being architectural or not. If it makes sense to emulate certain non-architectural MSRs we can add them. Supporting the error control MSR wouldn't even be hard, but I'm not sure it makes sense: 1) that MSR has not been there on current processors for several years (and therefore Intel has clearly no intention of making architectural). For what we know, even current processors might not provide any of that extended information at all (and still the VM could present Sandy Bridge f/m/s). 2) it would only present extended error info if the host itself enables the bit, so one might question the wisdom of backporting that support this to stable kernels 3) It's unclear whether the guest would be able to use the extended error information at all (and in some cases the description in the manual is not even proper English: "allows the iMC to log first device error when corrected error is detected during normal read"?). 4) other hypervisors, including older distros, would likely have the same issue. Paolo
Re: [PATCH 3/3] arm64: allwinner: dts: a64: add DT for PineTab developer sample
于 2020年11月10日 GMT+08:00 下午6:39:25, Maxime Ripard 写到:
>On Sat, Nov 07, 2020 at 08:53:32PM +0800, Icenowy Zheng wrote:
>> Some developers received PineTab samples that used an old LCD panel.
>>
>> Add device tree for these samples.
>>
>> Signed-off-by: Icenowy Zheng
>> ---
>> arch/arm64/boot/dts/allwinner/Makefile| 1 +
>> .../dts/allwinner/sun50i-a64-pinetab-dev.dts | 28
>+++
>> 2 files changed, 29 insertions(+)
>> create mode 100644
>arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab-dev.dts
>>
>> diff --git a/arch/arm64/boot/dts/allwinner/Makefile
>b/arch/arm64/boot/dts/allwinner/Makefile
>> index 211d1e9d4701..a221dcebfad4 100644
>> --- a/arch/arm64/boot/dts/allwinner/Makefile
>> +++ b/arch/arm64/boot/dts/allwinner/Makefile
>> @@ -13,6 +13,7 @@ dtb-$(CONFIG_ARCH_SUNXI) +=
>sun50i-a64-pinephone-1.0.dtb
>> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinephone-1.1.dtb
>> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinephone-1.2.dtb
>> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinetab.dtb
>> +dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinetab-dev.dtb
>> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-sopine-baseboard.dtb
>> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-teres-i.dtb
>> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a100-allwinner-perf1.dtb
>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab-dev.dts
>b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab-dev.dts
>> new file mode 100644
>> index ..3a4153890f3e
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab-dev.dts
>> @@ -0,0 +1,28 @@
>> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
>> +/*
>> + * Copyright (C) 2020 Icenowy Zheng
>> + *
>> + */
>> +
>> +/dts-v1/;
>> +
>> +#include "sun50i-a64-pinetab.dts"
>> +
>> +/ {
>> +model = "PineTab Developer Sample";
>> +compatible = "pine64,pinetab-dev", "allwinner,sun50i-a64";
>> +};
>
>Changing the DT and the compatible half-way through it isn't ok. Please
>add a new DT with the newer revision like we did for the pinephone
We did this on Pine H64.
>
>Maxime
[PATCH] docs: thermal: time_in_state is displayed in msec and not usertime
The sysfs stats for cooling devices shows the time_in_state in msec, remove the unwanted usertime comment. Signed-off-by: Viresh Kumar --- Documentation/driver-api/thermal/sysfs-api.rst | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/Documentation/driver-api/thermal/sysfs-api.rst b/Documentation/driver-api/thermal/sysfs-api.rst index b40b1f839148..e7520cb439ac 100644 --- a/Documentation/driver-api/thermal/sysfs-api.rst +++ b/Documentation/driver-api/thermal/sysfs-api.rst @@ -654,8 +654,7 @@ stats/reset The amount of time spent by the cooling device in various cooling states. The output will have " " pair in each line, which will mean this cooling device spent msec of time at . - Output will have one line for each of the supported states. usertime - units here is 10mS (similar to other time exported in /proc). + Output will have one line for each of the supported states. RO, Required -- 2.25.0.rc1.19.g042ed3e048af
Re: [External] Re: [PATCH v3 09/21] mm/hugetlb: Free the vmemmap pages associated with each hugetlb page
On Tue, Nov 10, 2020 at 5:48 PM Oscar Salvador wrote:
>
> On Tue, Nov 10, 2020 at 02:40:54PM +0800, Muchun Song wrote:
> > Only the first HugeTLB page should split the PMD to PTE. The other 63
> > HugeTLB pages
> > do not need to split. Here I want to make sure we are the first.
>
> I think terminology is loosing me here.
>
> Say you allocate a 2MB HugeTLB page at ea000410.
>
> The vmemmap range that the represents this is ea000400 -
> ea000420.
> That is a 2MB chunk PMD-mapped.
> So, in order to free some of those vmemmap pages, we need to break down
> that area, remapping it to PTE-based.
> I know what you mean, but we are not really splitting hugetlg pages, but
> the memmap range they are represented with.
Yeah, you are right. We are splitting the vmemmap instead of hugetlb.
Sorry for the confusion.
>
> About:
>
> "Only the first HugeTLB page should split the PMD to PTE. The other 63
> HugeTLB pages
> do not need to split. Here I want to make sure we are the first."
>
> That only refers to gigantic pages, right?
Yeah, now it only refers to gigantic pages. Originally, I also wanted to merge
vmemmap PTE to PMD for normal 2MB HugeTLB pages. So I introduced
those macros(e.g. freed_vmemmap_hpage). For 2MB HugeTLB pages, I
haven't found an elegant solution. Hopefully, when you or someone have
read all of the patch series, we can come up with an elegant solution to
merge PTE.
Thanks.
>
> > > > +static void free_huge_page_vmemmap(struct hstate *h, struct page *head)
> > > > +{
> > > > + pmd_t *pmd;
> > > > + spinlock_t *ptl;
> > > > + LIST_HEAD(free_pages);
> > > > +
> > > > + if (!free_vmemmap_pages_per_hpage(h))
> > > > + return;
> > > > +
> > > > + pmd = vmemmap_to_pmd(head);
> > > > + ptl = vmemmap_pmd_lock(pmd);
> > > > + if (vmemmap_pmd_huge(pmd)) {
> > > > + VM_BUG_ON(!pgtable_pages_to_prealloc_per_hpage(h));
> > >
> > > I think that checking for free_vmemmap_pages_per_hpage is enough.
> > > In the end, pgtable_pages_to_prealloc_per_hpage uses
> > > free_vmemmap_pages_per_hpage.
> >
> > The free_vmemmap_pages_per_hpage is not enough. See the comments above.
>
> My comment was about the VM_BUG_ON.
Sorry, yeah, we can drop it. Thanks.
>
>
> --
> Oscar Salvador
> SUSE L3
--
Yours,
Muchun
Re: [PATCH v3 19/26] coresight: etm4x: Detect access early on the target CPU
On 11/6/20 8:46 PM, Mathieu Poirier wrote:
On Wed, Oct 28, 2020 at 10:09:38PM +, Suzuki K Poulose wrote:
In preparation to detect the support for system instruction
support, move the detection of the device access to the target
CPU.
Signed-off-by: Suzuki K Poulose
---
.../coresight/coresight-etm4x-core.c | 45 ---
1 file changed, 40 insertions(+), 5 deletions(-)
diff --git a/drivers/hwtracing/coresight/coresight-etm4x-core.c
b/drivers/hwtracing/coresight/coresight-etm4x-core.c
index f038bb10bc78..308674ab746c 100644
--- a/drivers/hwtracing/coresight/coresight-etm4x-core.c
+++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c
@@ -56,6 +56,11 @@ static u64 etm4_get_access_type(struct etmv4_config *config);
static enum cpuhp_state hp_online;
+struct etm_init_arg {
+ struct etmv4_drvdata*drvdata;
+ struct csdev_access *csa;
+};
+
u64 etm4x_sysreg_read(struct csdev_access *csa,
u32 offset,
bool _relaxed,
@@ -669,6 +674,22 @@ static const struct coresight_ops etm4_cs_ops = {
.source_ops = &etm4_source_ops,
};
+static bool etm_init_iomem_access(struct etmv4_drvdata *drvdata,
+ struct csdev_access *csa)
+{
+ *csa = CSDEV_ACCESS_IOMEM(drvdata->base);
+ return true;
+}
+
+static bool etm_init_csdev_access(struct etmv4_drvdata *drvdata,
+ struct csdev_access *csa)
+{
+ if (drvdata->base)
+ return etm_init_iomem_access(drvdata, csa);
+
+ return false;
+}
I would also prefix the above two functions with "etm4_" rather than "etm_" to
follow what is already done in this file.
sure, will do.
suzuki
Re: [RFC PATCH 4/7] preempt/dynamic: Provide cond_resched() and might_resched() static calls
On Tue, Nov 10, 2020 at 11:39:09AM +0100, Peter Zijlstra wrote: > Subject: static_call: EXPORT_STATIC_CALL_TRAMP() > From: Peter Zijlstra > Date: Tue Nov 10 11:37:48 CET 2020 > > For when we want to allow modules to call the static_call() but not > change it. > > Signed-off-by: Peter Zijlstra (Intel) > --- > @@ -269,6 +281,9 @@ static inline int static_call_text_reser > return 0; > } > > +#define EXPORT_STATIC_CALL_TRAMP(name) > +#define EXPORT_STATIC_CALL_TRAMP_GPL(name) > + > #define EXPORT_STATIC_CALL(name) EXPORT_SYMBOL(STATIC_CALL_KEY(name)) > #define EXPORT_STATIC_CALL_GPL(name) EXPORT_SYMBOL_GPL(STATIC_CALL_KEY(name)) Hurmph, this hunk is wrong, it should export the KEY in both cases :/ That's unfortunate but unavoidable I suppose.
Re: [PATCH v2 1/2] usb: typec: Add number of altmodes partner attr
On Mon, Nov 09, 2020 at 10:15:34PM -0800, Prashant Malani wrote:
> Add a user-visible attribute for the number of alternate modes available
> in a partner. This allows userspace to determine whether there are any
> remaining alternate modes left to be registered by the kernel driver. It
> can begin executing any policy state machine after all available
> alternate modes have been registered with the connector class framework.
>
> This value is set to "-1" initially, signifying that a valid number of
> alternate modes haven't been set for the partner.
>
> Also add a sysfs file which exposes this attribute. The file remains
> hidden as long as the attribute value is -1.
>
> Cc: Benson Leung
> Cc: Heikki Krogerus
> Signed-off-by: Prashant Malani
Reviewed-by: Heikki Krogerus
> ---
>
> Changes in v2:
> - Added ABI/testing documentation entry for added sysfs file.
> - Changed name of the sysfs file to "number_of_alternate_modes" based on
> review comments.
> - Added is_visible() logic suggested by Heikki in the comments of v1.
> - Updated commit message.
>
> v1:
> https://lore.kernel.org/lkml/20200701003149.3101219-1-pmal...@chromium.org/
>
> Documentation/ABI/testing/sysfs-class-typec | 8 +++
> drivers/usb/typec/class.c | 66 -
> include/linux/usb/typec.h | 1 +
> 3 files changed, 74 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/ABI/testing/sysfs-class-typec
> b/Documentation/ABI/testing/sysfs-class-typec
> index b834671522d6..73ac7b461ae5 100644
> --- a/Documentation/ABI/testing/sysfs-class-typec
> +++ b/Documentation/ABI/testing/sysfs-class-typec
> @@ -134,6 +134,14 @@ Description:
> Shows if the partner supports USB Power Delivery communication:
> Valid values: yes, no
>
> +What:
> /sys/class/typec/-partner/number_of_alternate_modes
> +Date:November 2020
> +Contact: Prashant Malani
> +Description:
> + Shows the number of alternate modes which are advertised by the
> partner
> + during Power Delivery discovery. This file remains hidden until
> a value
> + greater than or equal to 0 is set by Type C port driver.
> +
> What:/sys/class/typec/-partner>/identity/
> Date:April 2017
> Contact: Heikki Krogerus
> diff --git a/drivers/usb/typec/class.c b/drivers/usb/typec/class.c
> index 35eec707cb51..c7412ddbd311 100644
> --- a/drivers/usb/typec/class.c
> +++ b/drivers/usb/typec/class.c
> @@ -33,6 +33,7 @@ struct typec_partner {
> struct usb_pd_identity *identity;
> enum typec_accessoryaccessory;
> struct ida mode_ids;
> + int num_altmodes;
> };
>
> struct typec_port {
> @@ -532,12 +533,43 @@ static ssize_t supports_usb_power_delivery_show(struct
> device *dev,
> }
> static DEVICE_ATTR_RO(supports_usb_power_delivery);
>
> +static ssize_t number_of_alternate_modes_show(struct device *dev, struct
> device_attribute *attr,
> + char *buf)
> +{
> + struct typec_partner *p = to_typec_partner(dev);
> +
> + return sysfs_emit(buf, "%d\n", p->num_altmodes);
> +}
> +static DEVICE_ATTR_RO(number_of_alternate_modes);
> +
> static struct attribute *typec_partner_attrs[] = {
> &dev_attr_accessory_mode.attr,
> &dev_attr_supports_usb_power_delivery.attr,
> + &dev_attr_number_of_alternate_modes.attr,
> + NULL
> +};
> +
> +static umode_t typec_partner_attr_is_visible(struct kobject *kobj, struct
> attribute *attr, int n)
> +{
> + struct typec_partner *partner = to_typec_partner(kobj_to_dev(kobj));
> +
> + if (attr == &dev_attr_number_of_alternate_modes.attr) {
> + if (partner->num_altmodes < 0)
> + return 0;
> + }
> +
> + return attr->mode;
> +}
> +
> +static struct attribute_group typec_partner_group = {
> + .is_visible = typec_partner_attr_is_visible,
> + .attrs = typec_partner_attrs
> +};
> +
> +static const struct attribute_group *typec_partner_groups[] = {
> + &typec_partner_group,
> NULL
> };
> -ATTRIBUTE_GROUPS(typec_partner);
>
> static void typec_partner_release(struct device *dev)
> {
> @@ -570,6 +602,37 @@ int typec_partner_set_identity(struct typec_partner
> *partner)
> }
> EXPORT_SYMBOL_GPL(typec_partner_set_identity);
>
> +/**
> + * typec_partner_set_num_altmodes - Set the number of available partner
> altmodes
> + * @partner: The partner to be updated.
> + * @num_alt_modes: The number of altmodes we want to specify as available.
> + *
> + * This routine is used to report the number of alternate modes supported by
> the
> + * partner. This value is *not* enforced in alternate mode registration
> routines.
> + *
> + * @partner.num_altmodes is set to -1 on partner registration, denoting that
> + * a valid value has not been set for it yet.
> + *
Re: [v9 2/2] i2c: imx: select I2C_SLAVE by default
Hi, it makes no sense to have separate patch for it On Mon, Nov 02, 2020 at 04:21:02PM +0800, Biwen Li wrote: > From: Biwen Li > > Select I2C_SLAVE by default > > Signed-off-by: Biwen Li > --- > Change in v9: > - none > > drivers/i2c/busses/Kconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig > index a4f473ef4e5c..d3d9a61db76e 100644 > --- a/drivers/i2c/busses/Kconfig > +++ b/drivers/i2c/busses/Kconfig > @@ -675,6 +675,7 @@ config I2C_IMG > config I2C_IMX > tristate "IMX I2C interface" > depends on ARCH_MXC || ARCH_LAYERSCAPE || COLDFIRE > + select I2C_SLAVE > help > Say Y here if you want to use the IIC bus controller on > the Freescale i.MX/MXC, Layerscape or ColdFire processors. > -- > 2.17.1 > > -- 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- |
drivers/crypto/allwinner/sun8i-ce/sun8i-ce-hash.c:412 sun8i_ce_hash_run() warn: possible memory leak of 'result'
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 407ab579637ced6dc32cfb2295afb7259cca4b22
commit: 56f6d5aee88d129b2424902cd630f10794550763 crypto: sun8i-ce - support
hash algorithms
config: x86_64-randconfig-m001-20201109 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-15) 9.3.0
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
Reported-by: Dan Carpenter
smatch warnings:
drivers/crypto/allwinner/sun8i-ce/sun8i-ce-hash.c:412 sun8i_ce_hash_run() warn:
possible memory leak of 'result'
vim +/result +412 drivers/crypto/allwinner/sun8i-ce/sun8i-ce-hash.c
56f6d5aee88d129 Corentin Labbe 2020-09-18 249 int sun8i_ce_hash_run(struct
crypto_engine *engine, void *breq)
56f6d5aee88d129 Corentin Labbe 2020-09-18 250 {
56f6d5aee88d129 Corentin Labbe 2020-09-18 251 struct ahash_request
*areq = container_of(breq, struct ahash_request, base);
56f6d5aee88d129 Corentin Labbe 2020-09-18 252 struct crypto_ahash
*tfm = crypto_ahash_reqtfm(areq);
56f6d5aee88d129 Corentin Labbe 2020-09-18 253 struct ahash_alg *alg =
__crypto_ahash_alg(tfm->base.__crt_alg);
56f6d5aee88d129 Corentin Labbe 2020-09-18 254 struct
sun8i_ce_hash_reqctx *rctx = ahash_request_ctx(areq);
56f6d5aee88d129 Corentin Labbe 2020-09-18 255 struct
sun8i_ce_alg_template *algt;
56f6d5aee88d129 Corentin Labbe 2020-09-18 256 struct sun8i_ce_dev *ce;
56f6d5aee88d129 Corentin Labbe 2020-09-18 257 struct sun8i_ce_flow
*chan;
56f6d5aee88d129 Corentin Labbe 2020-09-18 258 struct ce_task *cet;
56f6d5aee88d129 Corentin Labbe 2020-09-18 259 struct scatterlist *sg;
56f6d5aee88d129 Corentin Labbe 2020-09-18 260 int nr_sgs, flow, err;
56f6d5aee88d129 Corentin Labbe 2020-09-18 261 unsigned int len;
56f6d5aee88d129 Corentin Labbe 2020-09-18 262 u32 common;
56f6d5aee88d129 Corentin Labbe 2020-09-18 263 u64 byte_count;
56f6d5aee88d129 Corentin Labbe 2020-09-18 264 __le32 *bf;
56f6d5aee88d129 Corentin Labbe 2020-09-18 265 void *buf;
56f6d5aee88d129 Corentin Labbe 2020-09-18 266 int j, i, todo;
56f6d5aee88d129 Corentin Labbe 2020-09-18 267 int nbw = 0;
56f6d5aee88d129 Corentin Labbe 2020-09-18 268 u64 fill, min_fill;
56f6d5aee88d129 Corentin Labbe 2020-09-18 269 __be64 *bebits;
56f6d5aee88d129 Corentin Labbe 2020-09-18 270 __le64 *lebits;
56f6d5aee88d129 Corentin Labbe 2020-09-18 271 void *result;
56f6d5aee88d129 Corentin Labbe 2020-09-18 272 u64 bs;
56f6d5aee88d129 Corentin Labbe 2020-09-18 273 int digestsize;
56f6d5aee88d129 Corentin Labbe 2020-09-18 274 dma_addr_t addr_res,
addr_pad;
56f6d5aee88d129 Corentin Labbe 2020-09-18 275
56f6d5aee88d129 Corentin Labbe 2020-09-18 276 algt =
container_of(alg, struct sun8i_ce_alg_template, alg.hash);
56f6d5aee88d129 Corentin Labbe 2020-09-18 277 ce = algt->ce;
56f6d5aee88d129 Corentin Labbe 2020-09-18 278
56f6d5aee88d129 Corentin Labbe 2020-09-18 279 bs =
algt->alg.hash.halg.base.cra_blocksize;
56f6d5aee88d129 Corentin Labbe 2020-09-18 280 digestsize =
algt->alg.hash.halg.digestsize;
56f6d5aee88d129 Corentin Labbe 2020-09-18 281 if (digestsize ==
SHA224_DIGEST_SIZE)
56f6d5aee88d129 Corentin Labbe 2020-09-18 282 digestsize =
SHA256_DIGEST_SIZE;
56f6d5aee88d129 Corentin Labbe 2020-09-18 283 if (digestsize ==
SHA384_DIGEST_SIZE)
56f6d5aee88d129 Corentin Labbe 2020-09-18 284 digestsize =
SHA512_DIGEST_SIZE;
56f6d5aee88d129 Corentin Labbe 2020-09-18 285
56f6d5aee88d129 Corentin Labbe 2020-09-18 286 /* the padding could be
up to two block. */
56f6d5aee88d129 Corentin Labbe 2020-09-18 287 buf = kzalloc(bs * 2,
GFP_KERNEL | GFP_DMA);
^
"buf" is leaked as well.
56f6d5aee88d129 Corentin Labbe 2020-09-18 288 if (!buf)
56f6d5aee88d129 Corentin Labbe 2020-09-18 289 return -ENOMEM;
56f6d5aee88d129 Corentin Labbe 2020-09-18 290 bf = (__le32 *)buf;
56f6d5aee88d129 Corentin Labbe 2020-09-18 291
56f6d5aee88d129 Corentin Labbe 2020-09-18 292 result =
kzalloc(digestsize, GFP_KERNEL | GFP_DMA);
^
56f6d5aee88d129 Corentin Labbe 2020-09-18 293 if (!result)
56f6d5aee88d129 Corentin Labbe 2020-09-18 294 return -ENOMEM;
56f6d5aee88d129 Corentin Labbe 2020-09-18 295
56f6d5aee88d129 Corentin Labbe 2020-09-18 296 flow = rctx->flow;
56f6d5aee88d129 Corentin Labbe 2020-09-18 297 chan =
&ce->chanlist[flow];
56f6d5aee88d129 Corentin Labbe 2020-09-18 298
56f6d5aee88d129 Corentin Labbe 2020-09-18 299 #ifdef
CONFIG_CRYPTO_DEV_SUN8I_CE_DEBUG
56f6d5aee88d129 Co
Re: [PATCH] clk: mediatek: fix mtk_clk_register_mux() as static function
On 10/11/2020 02:38, Weiyi Lu wrote:
On Mon, 2020-11-09 at 11:20 +0100, Greg KH wrote:
On Mon, Nov 09, 2020 at 05:37:07PM +0800, Weiyi Lu wrote:
mtk_clk_register_mux() should be a static function
Fixes: a3ae549917f16 ("clk: mediatek: Add new clkmux register API")
Cc:
Why is this for stable trees?
Hi Greg,
My Mistake. Indeed, this is not a bug fix for stable tree.
And there are simple questions.
Will I be allowed to keep the fixes tag in this patch to indicate the
mistakes we made in previous commit if it's not a bug fix for stable
tree?
And all I need to do now is to remove stable tree from cc list. Is it
correct?
That's my understanding, yes. Keep fixes tag but delete cc to stable.
Regards,
Matthias
Re: [PATCH v2 2/2] platform/chrome: cros_ec_typec: Set partner num_altmodes
On Mon, Nov 09, 2020 at 10:15:36PM -0800, Prashant Malani wrote:
> Set the number of altmodes available for a registered partner using the
> Type C connector class framework routine.
>
> Signed-off-by: Prashant Malani
Reviewed-by: Heikki Krogerus
> ---
>
> Changes in v2:
> - Patch introduced for the first time in v2.
>
> drivers/platform/chrome/cros_ec_typec.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/platform/chrome/cros_ec_typec.c
> b/drivers/platform/chrome/cros_ec_typec.c
> index ce031a10eb1b..743a28426f98 100644
> --- a/drivers/platform/chrome/cros_ec_typec.c
> +++ b/drivers/platform/chrome/cros_ec_typec.c
> @@ -621,6 +621,7 @@ static int cros_typec_register_altmodes(struct
> cros_typec_data *typec, int port_
> struct cros_typec_altmode_node *node;
> struct typec_altmode_desc desc;
> struct typec_altmode *amode;
> + int num_altmodes = 0;
> int ret = 0;
> int i, j;
>
> @@ -647,9 +648,16 @@ static int cros_typec_register_altmodes(struct
> cros_typec_data *typec, int port_
>
> node->amode = amode;
> list_add_tail(&node->list, &port->partner_mode_list);
> + num_altmodes++;
> }
> }
>
> + ret = typec_partner_set_num_altmodes(port->partner, num_altmodes);
> + if (ret < 0) {
> + dev_err(typec->dev, "Unable to set partner num_altmodes for
> port: %d\n", port_num);
> + goto err_cleanup;
> + }
> +
> return 0;
>
> err_cleanup:
> --
> 2.29.2.222.g5d2a92d10f8-goog
thanks,
--
heikki
Re: [PATCH v3 25/26] coresight: etm4x: Add support for sysreg only devices
On 11/9/20 8:46 PM, Mathieu Poirier wrote:
On Wed, Oct 28, 2020 at 10:09:44PM +, Suzuki K Poulose wrote:
Add support for devices with system instruction access only.
They don't have a memory mapped interface and thus are not
AMBA devices.
Cc: Mathieu Poirier
Cc: Mike Leach
Signed-off-by: Suzuki K Poulose
---
.../coresight/coresight-etm4x-core.c | 50 +--
1 file changed, 45 insertions(+), 5 deletions(-)
diff --git a/drivers/hwtracing/coresight/coresight-etm4x-core.c
b/drivers/hwtracing/coresight/coresight-etm4x-core.c
index 25fab5513604..50a574228866 100644
--- a/drivers/hwtracing/coresight/coresight-etm4x-core.c
+++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c
@@ -26,6 +26,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -1623,9 +1624,6 @@ static int etm4_probe(struct device *dev, void __iomem
*base)
return -ENOMEM;
}
- if (fwnode_property_present(dev_fwnode(dev), "qcom,skip-power-up"))
- drvdata->skip_power_up = true;
-
drvdata->base = base;
spin_lock_init(&drvdata->spinlock);
@@ -1648,6 +1646,11 @@ static int etm4_probe(struct device *dev, void __iomem
*base)
if (!drvdata->arch)
return -EINVAL;
+ /* Skip programming TRCPDCR for system instructions. */
It would be nice to mention that TRCPDCR is not available in system instruction
mode.
Sure.
+ if (!desc.access.io_mem ||
+ fwnode_property_present(dev_fwnode(dev), "qcom,skip-power-up"))
+ drvdata->skip_power_up = true;
+
etm4_init_trace_id(drvdata);
etm4_set_default(&drvdata->config);
@@ -1706,6 +1709,20 @@ static int etm4_probe_amba(struct amba_device *adev, const struct amba_id *id)
return ret;
}
+static int etm4_probe_platform_dev(struct platform_device *pdev)
+{
+ int ret;
+
+ pm_runtime_get_noresume(&pdev->dev);
+ pm_runtime_set_active(&pdev->dev);
+ pm_runtime_enable(&pdev->dev);
+
+ ret = etm4_probe(&pdev->dev, NULL);
+
+ pm_runtime_put(&pdev->dev);
+ return ret;
+}
+
static struct amba_cs_uci_id uci_id_etm4[] = {
{
/* ETMv4 UCI data */
@@ -1781,6 +1798,20 @@ static struct amba_driver etm4x_amba_driver = {
.id_table = etm4_ids,
};
+static const struct of_device_id etm_sysreg_match[] = {
s/etm_sysreg_match/etm4_sysreg_match
+ { .compatible = "arm,coresight-etm-sysreg" },
See my comment in the next patch.
With the above:
Reviewed-by: Mathieu Poirier
Thanks
Suzuki
Re: [PATCH v3 26/26] dts: bindings: coresight: ETM system register access only units
On 11/9/20 8:50 PM, Mathieu Poirier wrote: On Wed, Oct 28, 2020 at 10:09:45PM +, Suzuki K Poulose wrote: Document the bindings for ETMs with system register accesses. Cc: devicet...@vger.kernel.org Cc: Mathieu Poirier Cc: Mike Leach Cc: Rob Herring Signed-off-by: Suzuki K Poulose --- Documentation/devicetree/bindings/arm/coresight.txt | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/arm/coresight.txt b/Documentation/devicetree/bindings/arm/coresight.txt index d711676b4a51..bff96a550102 100644 --- a/Documentation/devicetree/bindings/arm/coresight.txt +++ b/Documentation/devicetree/bindings/arm/coresight.txt @@ -34,9 +34,12 @@ its hardware characteristcs. Program Flow Trace Macrocell: "arm,coresight-etm3x", "arm,primecell"; - - Embedded Trace Macrocell (version 4.x): + - Embedded Trace Macrocell (version 4.x), with memory mapped access. "arm,coresight-etm4x", "arm,primecell"; + - Embedded Trace Macrocell with system register access only. + "arm,coresight-etm-sysreg"; Please make this "arm,coresight-etm4x-sysreg". Up to now all reference of "etm" without a version related to ETMv3/PTM1.1. If we start mixing things it will be come insanely confusing. Agreed. will rename it. Suzuki
Re: [PATCH v3 1/2] usb: typec: Consolidate syfs ABI documentation
On Fri, Oct 23, 2020 at 02:43:26PM -0700, Prashant Malani wrote:
> Both partner and cable have identity VDOs. These are listed separately
> in the Documentation/ABI/testing/sysfs-class-typec. Factor these out
> into a common location to avoid the duplication.
>
> Signed-off-by: Prashant Malani
I don't have a problem with this change. FWIW:
Acked-by: Heikki Krogerus
> ---
>
> Patch first introduced in v3.
>
> Documentation/ABI/testing/sysfs-class-typec | 59 ++---
> 1 file changed, 17 insertions(+), 42 deletions(-)
>
> diff --git a/Documentation/ABI/testing/sysfs-class-typec
> b/Documentation/ABI/testing/sysfs-class-typec
> index b834671522d6..0f839fd022f1 100644
> --- a/Documentation/ABI/testing/sysfs-class-typec
> +++ b/Documentation/ABI/testing/sysfs-class-typec
> @@ -134,42 +134,6 @@ Description:
> Shows if the partner supports USB Power Delivery communication:
> Valid values: yes, no
>
> -What:/sys/class/typec/-partner>/identity/
> -Date:April 2017
> -Contact: Heikki Krogerus
> -Description:
> - This directory appears only if the port device driver is capable
> - of showing the result of Discover Identity USB power delivery
> - command. That will not always be possible even when USB power
> - delivery is supported, for example when USB power delivery
> - communication for the port is mostly handled in firmware. If the
> - directory exists, it will have an attribute file for every VDO
> - in Discover Identity command result.
> -
> -What:/sys/class/typec/-partner/identity/id_header
> -Date:April 2017
> -Contact: Heikki Krogerus
> -Description:
> - ID Header VDO part of Discover Identity command result. The
> - value will show 0 until Discover Identity command result becomes
> - available. The value can be polled.
> -
> -What:/sys/class/typec/-partner/identity/cert_stat
> -Date:April 2017
> -Contact: Heikki Krogerus
> -Description:
> - Cert Stat VDO part of Discover Identity command result. The
> - value will show 0 until Discover Identity command result becomes
> - available. The value can be polled.
> -
> -What:/sys/class/typec/-partner/identity/product
> -Date:April 2017
> -Contact: Heikki Krogerus
> -Description:
> - Product VDO part of Discover Identity command result. The value
> - will show 0 until Discover Identity command result becomes
> - available. The value can be polled.
> -
>
> USB Type-C cable devices (eg. /sys/class/typec/port0-cable/)
>
> @@ -196,17 +160,28 @@ Description:
> - type-c
> - captive
>
> -What:/sys/class/typec/-cable/identity/
> +
> +USB Type-C partner/cable Power Delivery Identity objects
> +
> +NOTE: The following attributes will be applicable to both
> +partner (e.g /sys/class/typec/port0-partner/) and
> +cable (e.g /sys/class/typec/port0-cable/) devices. Consequently, the example
> file
> +paths below are prefixed with "/sys/class/typec/-{partner|cable}/" to
> +reflect this.
> +
> +What:/sys/class/typec/-{partner|cable}/identity/
> Date:April 2017
> Contact: Heikki Krogerus
> Description:
> This directory appears only if the port device driver is capable
> of showing the result of Discover Identity USB power delivery
> command. That will not always be possible even when USB power
> - delivery is supported. If the directory exists, it will have an
> - attribute for every VDO returned by Discover Identity command.
> + delivery is supported, for example when USB power delivery
> + communication for the port is mostly handled in firmware. If the
> + directory exists, it will have an attribute file for every VDO
> + in Discover Identity command result.
>
> -What:/sys/class/typec/-cable/identity/id_header
> +What:
> /sys/class/typec/-{partner|cable}/identity/id_header
> Date:April 2017
> Contact: Heikki Krogerus
> Description:
> @@ -214,7 +189,7 @@ Description:
> value will show 0 until Discover Identity command result becomes
> available. The value can be polled.
>
> -What:/sys/class/typec/-cable/identity/cert_stat
> +What:
> /sys/class/typec/-{partner|cable}/identity/cert_stat
> Date:April 2017
> Contact: Heikki Krogerus
> Description:
> @@ -222,7 +197,7 @@ Description:
> value will show 0 until Discover Identity command result becomes
> available. The value can be polled.
>
> -What:/sys/class/type
Re: [BUG] Error applying setting, reverse things back on lot of devices
Hello, On 11/8/20 6:08 PM, Michał Mirosław wrote: > On Thu, Nov 05, 2020 at 10:11:30AM +0100, Ahmad Fatoum wrote: > It seems that final regulator_resolve_supply() is spinning recursively. > Is the regulator name the same as its supply_name? Can you try the patch > below to verify this? Indeed that seems to be the case: [1.299103] stpmic1 1-0033: PMIC Chip Version: 0x10 [1.307872] vddcore: 1200 <--> 1350 mV at 1200 mV, enabled [1.312173] stpmic1-regulator 5c002000.i2c:stpmic@33:regulators: Resolving supply buck1 for BUCK1 [1.321083] stpmic1-regulator 5c002000.i2c:stpmic@33:regulators: Looking up buck1-supply from device tree [1.330838] stpmic1-regulator 5c002000.i2c:stpmic@33:regulators: Looking up buck1-supply property in node /soc/i2c@5c002000/stpmic@33/regulators failed [1.344650] vddcore: supplied by regulator-dummy [1.352016] vdd_ddr: 1350 mV, enabled [1.354421] stpmic1-regulator 5c002000.i2c:stpmic@33:regulators: Resolving supply buck2 for BUCK2 [1.363341] stpmic1-regulator 5c002000.i2c:stpmic@33:regulators: Looking up buck2-supply from device tree [1.373124] stpmic1-regulator 5c002000.i2c:stpmic@33:regulators: Looking up buck2-supply property in node /soc/i2c@5c002000/stpmic@33/regulators failed [1.386921] vdd_ddr: supplied by regulator-dummy [1.394230] vdd: 3300 mV, enabled [1.396307] stpmic1-regulator 5c002000.i2c:stpmic@33:regulators: Resolving supply buck3 for BUCK3 [1.405186] stpmic1-regulator 5c002000.i2c:stpmic@33:regulators: Looking up buck3-supply from device tree [1.414962] stpmic1-regulator 5c002000.i2c:stpmic@33:regulators: Looking up buck3-supply property in node /soc/i2c@5c002000/stpmic@33/regulators failed [1.428790] vdd: supplied by regulator-dummy [1.435880] v3v3: 3300 mV, enabled [1.438008] stpmic1-regulator 5c002000.i2c:stpmic@33:regulators: Resolving supply buck4 for BUCK4 [1.446934] stpmic1-regulator 5c002000.i2c:stpmic@33:regulators: Looking up buck4-supply from device tree [1.456681] v3v3: supplied by 5V2 [1.462533] v1v8_audio: 1800 mV, enabled [1.465218] stpmic1-regulator 5c002000.i2c:stpmic@33:regulators: Resolving supply ldo1 for LDO1 [1.473906] stpmic1-regulator 5c002000.i2c:stpmic@33:regulators: Looking up ldo1-supply from device tree [1.483611] v1v8_audio: supplied by v3v3 [1.490978] v3v3_hdmi: 3300 mV, enabled [1.493551] stpmic1-regulator 5c002000.i2c:stpmic@33:regulators: Resolving supply ldo2 for LDO2 [1.502309] stpmic1-regulator 5c002000.i2c:stpmic@33:regulators: Looking up ldo2-supply from device tree [1.511959] v3v3_hdmi: supplied by 5V2 [1.516320] vtt_ddr: override max_uV, 75 -> 50 [1.523538] vtt_ddr: 500 mV, enabled [1.525881] stpmic1-regulator 5c002000.i2c:stpmic@33:regulators: Resolving supply ldo3 for LDO3 [1.534555] stpmic1-regulator 5c002000.i2c:stpmic@33:regulators: Looking up ldo3-supply from device tree [1.544285] stpmic1-regulator 5c002000.i2c:stpmic@33:regulators: Looking up ldo3-supply property in node /soc/i2c@5c002000/stpmic@33/regulators failed [1.558017] vtt_ddr: supplied by regulator-dummy [1.562874] vdd_usb: 3300 mV, enabled [1.566585] stpmic1-regulator 5c002000.i2c:stpmic@33:regulators: Resolving supply ldo4 for LDO4 [1.575297] stpmic1-regulator 5c002000.i2c:stpmic@33:regulators: Looking up ldo4-supply from device tree [1.585031] stpmic1-regulator 5c002000.i2c:stpmic@33:regulators: Looking up ldo4-supply property in node /soc/i2c@5c002000/stpmic@33/regulators failed [1.598716] vdd_usb: supplied by regulator-dummy [1.605030] edt_ft5x06 0-0038: touchscreen probe failed [1.606247] vdda: 2900 mV, enabled [1.612496] stpmic1-regulator 5c002000.i2c:stpmic@33:regulators: Resolving supply ldo5 for LDO5 [1.621251] stpmic1-regulator 5c002000.i2c:stpmic@33:regulators: Looking up ldo5-supply from device tree [1.630888] vdda: supplied by 5V2 [1.637155] v1v2_hdmi: 1200 mV, enabled [1.639742] stpmic1-regulator 5c002000.i2c:stpmic@33:regulators: Resolving supply ldo6 for LDO6 [1.648473] stpmic1-regulator 5c002000.i2c:stpmic@33:regulators: Looking up ldo6-supply from device tree [1.658143] v1v2_hdmi: supplied by v3v3 [1.664926] vref_ddr: at 500 mV, enabled [1.667597] stpmic1-regulator 5c002000.i2c:stpmic@33:regulators: Resolving supply vref_ddr for VREF_DDR [1.677055] stpmic1-regulator 5c002000.i2c:stpmic@33:regulators: Looking up vref_ddr-supply from device tree [1.687091] stpmic1-regulator 5c002000.i2c:stpmic@33:regulators: Looking up vref_ddr-supply property in node /soc/i2c@5c002000/stpmic@33/regulators failed [1.701181] stpmic1-regulator 5c002000.i2c:stpmic@33:regulators: Supply for VREF_DDR (vref_ddr) resolved to itself [1.711713] vref_ddr: unable to resolve supply [1.716413] bst_out: at 5000 mV, disabled [1.720445] stpmic1-regulator 5c002000.i2c:stpmic@33:regulators: Resolving supply vref_ddr for
Re: [PATCH V3] sched/rt, powerpc: Prepare for PREEMPT_RT
Le 10/11/2020 à 09:53, Wang Qing a écrit :
PREEMPT_RT is a separate preemption model, CONFIG_PREEMPT will
be disabled when CONFIG_PREEMPT_RT is enabled, so we need
to add CONFIG_PREEMPT_RT output to __die().
Signed-off-by: Wang Qing
Reviewed-by: Christophe Leroy
Changes in v3:
- Fix typo issue.
Changes in v2:
- Modify as Christophe suggested.
---
arch/powerpc/kernel/traps.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
index 5006dcb..dec7b81
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -262,10 +262,11 @@ static int __die(const char *str, struct pt_regs *regs,
long err)
{
printk("Oops: %s, sig: %ld [#%d]\n", str, err, ++die_counter);
- printk("%s PAGE_SIZE=%luK%s%s%s%s%s%s %s\n",
+ printk("%s PAGE_SIZE=%luK%s%s%s%s%s%s%s %s\n",
IS_ENABLED(CONFIG_CPU_LITTLE_ENDIAN) ? "LE" : "BE",
PAGE_SIZE / 1024, get_mmu_str(),
IS_ENABLED(CONFIG_PREEMPT) ? " PREEMPT" : "",
+ IS_ENABLED(CONFIG_PREEMPT_RT) ? " PREEMPT_RT" : "",
IS_ENABLED(CONFIG_SMP) ? " SMP" : "",
IS_ENABLED(CONFIG_SMP) ? (" NR_CPUS=" __stringify(NR_CPUS)) : "",
debug_pagealloc_enabled() ? " DEBUG_PAGEALLOC" : "",
Re: [PATCH] kunit: kunit_tool: Correctly parse diagnostic messages
On Tue, 10 Nov 2020 at 08:29, David Gow wrote: > > Currently, kunit_tool expects all diagnostic lines in test results to > contain ": " somewhere, as both the subtest header and the crash report > do. Fix this to accept any line starting with (minus indent) "# " as > being a valid diagnostic line. > > This matches what the TAP spec[1] and the draft KTAP spec[2] are > expecting. > > [1]: http://testanything.org/tap-specification.html > [2]: > https://lore.kernel.org/linux-kselftest/cy4pr13mb1175b804e31e502221bc8163fd...@cy4pr13mb1175.namprd13.prod.outlook.com/T/ > > Signed-off-by: David Gow Acked-by: Marco Elver Thanks! > --- > tools/testing/kunit/kunit_parser.py | 7 --- > 1 file changed, 4 insertions(+), 3 deletions(-) > > diff --git a/tools/testing/kunit/kunit_parser.py > b/tools/testing/kunit/kunit_parser.py > index 84a1af2581f5..dab4cfa05b74 100644 > --- a/tools/testing/kunit/kunit_parser.py > +++ b/tools/testing/kunit/kunit_parser.py > @@ -134,8 +134,8 @@ def parse_ok_not_ok_test_case(lines: List[str], > test_case: TestCase) -> bool: > else: > return False > > -SUBTEST_DIAGNOSTIC = re.compile(r'^[\s]+# .*?: (.*)$') > -DIAGNOSTIC_CRASH_MESSAGE = 'kunit test case crashed!' > +SUBTEST_DIAGNOSTIC = re.compile(r'^[\s]+# (.*)$') > +DIAGNOSTIC_CRASH_MESSAGE = re.compile(r'^[\s]+# .*?: kunit test case > crashed!$') > > def parse_diagnostic(lines: List[str], test_case: TestCase) -> bool: > save_non_diagnositic(lines, test_case) > @@ -145,7 +145,8 @@ def parse_diagnostic(lines: List[str], test_case: > TestCase) -> bool: > match = SUBTEST_DIAGNOSTIC.match(line) > if match: > test_case.log.append(lines.pop(0)) > - if match.group(1) == DIAGNOSTIC_CRASH_MESSAGE: > + crash_match = DIAGNOSTIC_CRASH_MESSAGE.match(line) > + if crash_match: > test_case.status = TestStatus.TEST_CRASHED > return True > else: > -- > 2.29.2.222.g5d2a92d10f8-goog >
How to enable auto-suspend by default
Hey, systemd has been shipping this script to enable auto-suspend on a number of USB and PCI devices: https://github.com/systemd/systemd/blob/master/tools/chromiumos/gen_autosuspend_rules.py The problem here is twofold. First, the list of devices is updated from ChromeOS, and the original list obviously won't be updated by ChromeOS developers unless a device listed exists in a ChromeBook computer, which means a number of devices that do support autosuspend aren't listed. The other problem is that this list needs to exist at all, and that it doesn't seem possible for device driver developers (at various levels of the stack) to opt-in to auto-suspend when all the variants of the device (or at least detectable ones) support auto-suspend. So the question is: how can we make it easier for device drivers to implicitly allow autosuspend *unless they opt-out*, especially for frameworks where the device's transport layer isn't directly available (eg. HID devices)? If that can't be done in the kernel drivers directly, would it be possible for the kernel to ship with a somewhat canonical list that systemd (or its replacement on other "Linuxes") could use to generate those user-space quirks? Ideally, for example, all new "iwlwifi" or all tested "iwlwifi" devices should have autosuspend enabled by the developers adding support for them, as in the script above, rather than downstreams (systemd upstream included) having to chase new PCI IDs. Cheers
Re: [RFC, v0 1/3] vfio/platform: add support for msi
Hi Eric,
On Mon, Nov 9, 2020 at 8:35 PM Auger Eric wrote:
>
> Hi Vikas,
>
> On 11/6/20 3:54 AM, Vikas Gupta wrote:
> > Hi Alex,
> >
> > On Thu, Nov 5, 2020 at 12:38 PM Alex Williamson
> > wrote:
> >>
> >> On Thu, 5 Nov 2020 11:32:55 +0530
> >> Vikas Gupta wrote:
> >>
> >>> diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
> >>> index 2f313a238a8f..aab051e8338d 100644
> >>> --- a/include/uapi/linux/vfio.h
> >>> +++ b/include/uapi/linux/vfio.h
> >>> @@ -203,6 +203,7 @@ struct vfio_device_info {
> >>> #define VFIO_DEVICE_FLAGS_AP (1 << 5)/* vfio-ap device */
> >>> #define VFIO_DEVICE_FLAGS_FSL_MC (1 << 6)/* vfio-fsl-mc device */
> >>> #define VFIO_DEVICE_FLAGS_CAPS (1 << 7)/* Info supports
> >>> caps */
> >>> +#define VFIO_DEVICE_FLAGS_MSI(1 << 8)/* Device supports
> >>> msi */
> >>> __u32 num_regions;/* Max region index + 1 */
> >>> __u32 num_irqs; /* Max IRQ index + 1 */
> >>> __u32 cap_offset; /* Offset within info struct of first cap */
> >>
> >> This doesn't make any sense to me, MSIs are just edge triggered
> >> interrupts to userspace, so why isn't this fully described via
> >> VFIO_DEVICE_GET_IRQ_INFO? If we do need something new to describe it,
> >> this seems incomplete, which indexes are MSI (IRQ_INFO can describe
> >> that)? We also already support MSI with vfio-pci, so a global flag for
> >> the device advertising this still seems wrong. Thanks,
> >>
> >> Alex
> >>
> > Since VFIO platform uses indexes for IRQ numbers so I think MSI(s)
> > cannot be described using indexes.
> > In the patch set there is no difference between MSI and normal
> > interrupt for VFIO_DEVICE_GET_IRQ_INFO.
> in vfio_platform_irq_init() we first iterate on normal interrupts using
> get_irq(). Can't we add an MSI index at the end of this list with
> vdev->irqs[i].count > 1 and set vdev->num_irqs accordingly?
Yes, I think MSI can be added to the end of list with setting
vdev->irqs[i].count > 1.
I`ll consider changing in the next patch set.
Thanks,
Vikas
>
> Thanks
>
> Eric
> > The patch set adds MSI(s), say as an extension, to the normal
> > interrupts and handled accordingly. Do you see this is a violation? If
> > yes, then we`ll think of other possible ways to support MSI for the
> > platform devices.
> > Macro VFIO_DEVICE_FLAGS_MSI can be changed to any other name if it
> > collides with an already supported vfio-pci or if not necessary, we
> > can remove this flag.
> >
> > Thanks,
> > Vikas
> >
>
smime.p7s
Description: S/MIME Cryptographic Signature
Re: [PATCH v1 3/4] phy: Add Sparx5 ethernet serdes PHY driver
Hi Steen,
I love your patch! Perhaps something to improve:
[auto build test WARNING on robh/for-next]
[also build test WARNING on linus/master phy/next linux/master v5.10-rc3
next-20201110]
[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/Steen-Hegelund/Adding-the-Sparx5-Serdes-driver/20201105-224623
base: https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
config: h8300-randconfig-r023-20201109 (attached as .config)
compiler: h8300-linux-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/cf09fd205f64b7c78c3078d3888f54baccf102e4
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Steen-Hegelund/Adding-the-Sparx5-Serdes-driver/20201105-224623
git checkout cf09fd205f64b7c78c3078d3888f54baccf102e4
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross
ARCH=h8300
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
In file included from include/linux/init.h:5,
from include/linux/printk.h:6,
from drivers/phy/microchip/sparx5_serdes.c:9:
include/linux/scatterlist.h: In function 'sg_set_buf':
include/asm-generic/page.h:93:50: warning: ordered comparison of pointer
with null pointer [-Wextra]
93 | #define virt_addr_valid(kaddr) (((void *)(kaddr) >= (void
*)PAGE_OFFSET) && \
| ^~
include/linux/compiler.h:78:42: note: in definition of macro 'unlikely'
78 | # define unlikely(x) __builtin_expect(!!(x), 0)
| ^
include/linux/scatterlist.h:143:2: note: in expansion of macro 'BUG_ON'
143 | BUG_ON(!virt_addr_valid(buf));
| ^~
include/linux/scatterlist.h:143:10: note: in expansion of macro
'virt_addr_valid'
143 | BUG_ON(!virt_addr_valid(buf));
| ^~~
drivers/phy/microchip/sparx5_serdes.c: In function
'sparx5_sd25g28_get_params':
>> drivers/phy/microchip/sparx5_serdes.c:821:33: warning: initialized field
>> overwritten [-Woverride-init]
821 | .cfg_rx_reserve_15_8= 0x61,
| ^~~~
drivers/phy/microchip/sparx5_serdes.c:821:33: note: (near initialization for
'init.cfg_rx_reserve_15_8')
drivers/phy/microchip/sparx5_serdes.c:828:33: warning: initialized field
overwritten [-Woverride-init]
828 | .cfg_pi_en = 1,
| ^
drivers/phy/microchip/sparx5_serdes.c:828:33: note: (near initialization for
'init.cfg_pi_en')
drivers/phy/microchip/sparx5_serdes.c:843:33: warning: initialized field
overwritten [-Woverride-init]
843 | .cfg_cdrck_en = 1,
| ^
drivers/phy/microchip/sparx5_serdes.c:843:33: note: (near initialization for
'init.cfg_cdrck_en')
drivers/phy/microchip/sparx5_serdes.c: In function
'sparx5_sd10g28_get_params':
drivers/phy/microchip/sparx5_serdes.c:949:34: warning: initialized field
overwritten [-Woverride-init]
949 | .cfg_cdrck_en= 1,
| ^
drivers/phy/microchip/sparx5_serdes.c:949:34: note: (near initialization for
'init.cfg_cdrck_en')
vim +821 drivers/phy/microchip/sparx5_serdes.c
738
739 static void sparx5_sd25g28_get_params(struct sparx5_serdes_macro *macro,
740 struct sparx5_sd25g28_media_preset
*media,
741 struct sparx5_sd25g28_mode_preset
*mode,
742 struct sparx5_sd25g28_args *args,
743 struct sparx5_sd25g28_params
*params)
744 {
745 struct sparx5_sd25g28_params init = {
746 .r_d_width_ctrl_2_0 =
sd25g28_get_iw_setting(mode->bitwidth),
747 .r_txfifo_ck_div_pmad_2_0 = mode->fifo_ck_div,
748 .r_rxfifo_ck_div_pmad_2_0 = mode->fifo_ck_div,
749 .cfg_vco_div_mode_1_0 = mode->vco_div_mode,
750 .cfg_pre_divsel_1_0 = mode->pre_divsel,
751 .cfg_sel_div_3_0= mode->sel_div,
752 .cfg_vc
[PATCH] soc: ti: omap-prm: Do not check rstst bit on deassert if already deasserted
If a rstctrl reset bit is already deasserted, we can just bail out early
not wait for rstst to clear. Otherwise we can have deassert fail for
already deasserted resets.
Fixes: c5117a78dd88 ("soc: ti: omap-prm: poll for reset complete during
de-assert")
Signed-off-by: Tony Lindgren
---
I found this with the genpd conversion, probably can wait for the merge
window and be merged together with the other pending omap_prm.c changes
I have posted.
---
drivers/soc/ti/omap_prm.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/soc/ti/omap_prm.c b/drivers/soc/ti/omap_prm.c
--- a/drivers/soc/ti/omap_prm.c
+++ b/drivers/soc/ti/omap_prm.c
@@ -484,6 +484,10 @@ static int omap_reset_deassert(struct reset_controller_dev
*rcdev,
struct ti_prm_platform_data *pdata = dev_get_platdata(reset->dev);
int ret = 0;
+ /* Nothing to do if the reset is already deasserted */
+ if (!omap_reset_status(rcdev, id))
+ return 0;
+
has_rstst = reset->prm->data->rstst ||
(reset->prm->data->flags & OMAP_PRM_HAS_RSTST);
--
2.29.2
[PATCH] bus: ti-sysc: Assert reset only after disabling clocks
The rstctrl reset must be asserted after gating the module clock as
described in the TRM at least for IVA. Otherwise the rstctrl reset
done with module clock enabled can hang the system.
Note that this issue is has been only seen with related IVA changes
that we do not currently have merged. So probably no need to apply
this patch as a fix.
Signed-off-by: Tony Lindgren
---
This can probably wait for merge window and be merged along with
the other genpd related changes I have been posting. At least I
have not seen this issue except with IVA resets so far.
---
drivers/bus/ti-sysc.c | 24 +---
1 file changed, 13 insertions(+), 11 deletions(-)
diff --git a/drivers/bus/ti-sysc.c b/drivers/bus/ti-sysc.c
--- a/drivers/bus/ti-sysc.c
+++ b/drivers/bus/ti-sysc.c
@@ -1222,10 +1222,10 @@ static int __maybe_unused sysc_runtime_suspend(struct
device *dev)
ddata->enabled = false;
err_allow_idle:
- reset_control_assert(ddata->rsts);
-
sysc_clkdm_allow_idle(ddata);
+ reset_control_assert(ddata->rsts);
+
return error;
}
@@ -1945,6 +1945,7 @@ static int sysc_reset(struct sysc *ddata)
*/
static int sysc_init_module(struct sysc *ddata)
{
+ bool rstctrl_deasserted = false;
int error = 0;
error = sysc_clockdomain_init(ddata);
@@ -1969,6 +1970,7 @@ static int sysc_init_module(struct sysc *ddata)
error = reset_control_deassert(ddata->rsts);
if (error)
goto err_main_clocks;
+ rstctrl_deasserted = true;
}
ddata->revision = sysc_read_revision(ddata);
@@ -1978,13 +1980,13 @@ static int sysc_init_module(struct sysc *ddata)
if (ddata->legacy_mode) {
error = sysc_legacy_init(ddata);
if (error)
- goto err_reset;
+ goto err_main_clocks;
}
if (!ddata->legacy_mode) {
error = sysc_enable_module(ddata->dev);
if (error)
- goto err_reset;
+ goto err_main_clocks;
}
error = sysc_reset(ddata);
@@ -1994,10 +1996,6 @@ static int sysc_init_module(struct sysc *ddata)
if (error && !ddata->legacy_mode)
sysc_disable_module(ddata->dev);
-err_reset:
- if (error && !(ddata->cfg.quirks & SYSC_QUIRK_NO_RESET_ON_INIT))
- reset_control_assert(ddata->rsts);
-
err_main_clocks:
if (error)
sysc_disable_main_clocks(ddata);
@@ -2008,6 +2006,10 @@ static int sysc_init_module(struct sysc *ddata)
sysc_clkdm_allow_idle(ddata);
}
+ if (error && rstctrl_deasserted &&
+ !(ddata->cfg.quirks & SYSC_QUIRK_NO_RESET_ON_INIT))
+ reset_control_assert(ddata->rsts);
+
return error;
}
@@ -2975,9 +2977,6 @@ static int sysc_probe(struct platform_device *pdev)
}
/* Balance use counts as PM runtime should have enabled these all */
- if (!(ddata->cfg.quirks & SYSC_QUIRK_NO_RESET_ON_INIT))
- reset_control_assert(ddata->rsts);
-
if (!(ddata->cfg.quirks &
(SYSC_QUIRK_NO_IDLE | SYSC_QUIRK_NO_IDLE_ON_INIT))) {
sysc_disable_main_clocks(ddata);
@@ -2985,6 +2984,9 @@ static int sysc_probe(struct platform_device *pdev)
sysc_clkdm_allow_idle(ddata);
}
+ if (!(ddata->cfg.quirks & SYSC_QUIRK_NO_RESET_ON_INIT))
+ reset_control_assert(ddata->rsts);
+
sysc_show_registers(ddata);
ddata->dev->type = &sysc_device_type;
--
2.29.2
Re: [RFC, v0 1/3] vfio/platform: add support for msi
Hi Alex,
On Mon, Nov 9, 2020 at 8:58 PM Alex Williamson
wrote:
>
> On Mon, 9 Nov 2020 12:11:15 +0530
> Vikas Gupta wrote:
>
> > Hi Alex,
> >
> > On Fri, Nov 6, 2020 at 8:42 AM Alex Williamson
> > wrote:
> > >
> > > On Fri, 6 Nov 2020 08:24:26 +0530
> > > Vikas Gupta wrote:
> > >
> > > > Hi Alex,
> > > >
> > > > On Thu, Nov 5, 2020 at 12:38 PM Alex Williamson
> > > > wrote:
> > > > >
> > > > > On Thu, 5 Nov 2020 11:32:55 +0530
> > > > > Vikas Gupta wrote:
> > > > >
> > > > > > diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
> > > > > > index 2f313a238a8f..aab051e8338d 100644
> > > > > > --- a/include/uapi/linux/vfio.h
> > > > > > +++ b/include/uapi/linux/vfio.h
> > > > > > @@ -203,6 +203,7 @@ struct vfio_device_info {
> > > > > > #define VFIO_DEVICE_FLAGS_AP (1 << 5)/* vfio-ap device */
> > > > > > #define VFIO_DEVICE_FLAGS_FSL_MC (1 << 6)/* vfio-fsl-mc device
> > > > > > */
> > > > > > #define VFIO_DEVICE_FLAGS_CAPS (1 << 7)/* Info
> > > > > > supports caps */
> > > > > > +#define VFIO_DEVICE_FLAGS_MSI(1 << 8)/* Device
> > > > > > supports msi */
> > > > > > __u32 num_regions;/* Max region index + 1 */
> > > > > > __u32 num_irqs; /* Max IRQ index + 1 */
> > > > > > __u32 cap_offset; /* Offset within info struct of first
> > > > > > cap */
> > > > >
> > > > > This doesn't make any sense to me, MSIs are just edge triggered
> > > > > interrupts to userspace, so why isn't this fully described via
> > > > > VFIO_DEVICE_GET_IRQ_INFO? If we do need something new to describe it,
> > > > > this seems incomplete, which indexes are MSI (IRQ_INFO can describe
> > > > > that)? We also already support MSI with vfio-pci, so a global flag
> > > > > for
> > > > > the device advertising this still seems wrong. Thanks,
> > > > >
> > > > > Alex
> > > > >
> > > > Since VFIO platform uses indexes for IRQ numbers so I think MSI(s)
> > > > cannot be described using indexes.
> > >
> > > That would be news for vfio-pci which has been describing MSIs with
> > > sub-indexes within indexes since vfio started.
> > >
> > > > In the patch set there is no difference between MSI and normal
> > > > interrupt for VFIO_DEVICE_GET_IRQ_INFO.
> > >
> > > Then what exactly is a global device flag indicating? Does it indicate
> > > all IRQs are MSI?
> >
> > No, it's not indicating that all are MSI.
> > The rationale behind adding the flag to tell user-space that platform
> > device supports MSI as well. As you mentioned recently added
> > capabilities can help on this, I`ll go through that.
>
>
> It still seems questionable to me to use a device info capability to
> describe an interrupt index specific feature. The scope seems wrong.
> Why does userspace need to know that this IRQ is MSI rather than
> indicating it's simply an edge triggered interrupt? That can be done
> using only vfio_irq_info.flags.
Ok. In the next patch set I`ll remove the device flag (VFIO_DEVICE_FLAGS_MSI) as
vfio_irq_info.flags should have enough information for edge triggered interrupt.
>
>
> > > > The patch set adds MSI(s), say as an extension, to the normal
> > > > interrupts and handled accordingly.
> > >
> > > So we have both "normal" IRQs and MSIs? How does the user know which
> > > indexes are which?
> >
> > With this patch set, I think this is missing and user space cannot
> > know that particular index is MSI interrupt.
> > For platform devices there is no such mechanism, like index and
> > sub-indexes to differentiate between legacy, MSI or MSIX as it’s there
> > in PCI.
>
> Indexes and sub-indexes are a grouping mechanism of vfio to describe
> related interrupts. That terminology doesn't exist on PCI either, it's
> meant to be used generically. It's left to the vfio bus driver how
> userspace associates a given index to a device feature.
>
> > I believe for a particular IRQ index if the flag
> > VFIO_IRQ_INFO_NORESIZE is used then user space can know which IRQ
> > index has MSI(s). Does it make sense?
>
>
> No, no-resize is an implementation detail, not an indication of the
> interrupt mechanism. It's still not clear to me why it's important to
> expose to userspace that a given interrupt is MSI versus simply
> exposing it as an edge interrupt (ie. automasked = false). If it is
> necessary, the most direct approach might be to expose a capability
> extension in the vfio_irq_info structure to describe it. Even then
> though, I don't think simply exposing a index as MSI is very
> meaningful. What is userspace intended to do differently based on this
> information? Thanks,
The current patch set is not setting VFIO_IRQ_INFO_AUTOMASKED
(automasked=false) for MSIs so I believe this much is information
enough for user space to know that this is an edge triggered
interrupt.
I agree that exposing an index as MSI is not meaningful as user space
has nothing special to do with this information.
>
> Alex
>
smime.p7s
Description: S/MIME Cryptogr
Re: [PATCH 3/4] powercap/drivers/dtpm: Add API for dynamic thermal power management
Actually I've found one issue when I have been trying to clean
my testing branch with modified scmi-cpufreq.c.
On 11/10/20 9:59 AM, Lukasz Luba wrote:
Hi Daniel,
I've experimented with the patch set and went through the code again.
It looks good, only a few minor comments.
On 10/6/20 1:20 PM, Daniel Lezcano wrote:
On the embedded world, the complexity of the SoC leads to an
increasing number of hotspots which need to be monitored and mitigated
as a whole in order to prevent the temperature to go above the
normative and legally stated 'skin temperature'.
[snip]
diff --git a/include/linux/dtpm.h b/include/linux/dtpm.h
new file mode 100644
index ..6696bdcfdb87
--- /dev/null
+++ b/include/linux/dtpm.h
@@ -0,0 +1,73 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (C) 2020 Linaro Ltd
+ *
+ * Author: Daniel Lezcano
+ */
+#ifndef ___DTPM_H__
+#define ___DTPM_H__
+
+#include
+#include
+
+#define MAX_DTPM_DESCR 8
+#define MAX_DTPM_CONSTRAINTS 1
+
+struct dtpm {
+ struct powercap_zone zone;
+ struct dtpm *parent;
+ struct list_head sibling;
+ struct list_head children;
+ spinlock_t lock;
+ u64 power_limit;
+ u64 power_max;
+ u64 power_min;
+ int weight;
+ void *private;
+};
+
+struct dtpm_descr;
+
+typedef int (*dtpm_init_t)(struct dtpm_descr *);
+
+struct dtpm_descr {
+ struct dtpm *parent;
+ const char *name;
+ dtpm_init_t init;
+};
+
+/* Init section thermal table */
+extern struct dtpm_descr *__dtpm_table[];
+extern struct dtpm_descr *__dtpm_table_end[];
+
+#define DTPM_TABLE_ENTRY(name) \
+ static typeof(name) *__dtpm_table_entry_##name \
+ __used __section(__dtpm_table) = &name
I had to change the section name to string, to pass compilation:
__used __section("__dtpm_table") = &name
I don't know if it's my compiler or configuration.
I've tried to register this DTPM in scmi-cpufreq.c with macro
proposed in patch 4/4 commit message, but I might missed some
important includes there...
+
+#define DTPM_DECLARE(name) DTPM_TABLE_ENTRY(name)
+
+#define for_each_dtpm_table(__dtpm) \
+ for (__dtpm = __dtpm_table; \
+ __dtpm < __dtpm_table_end; \
+ __dtpm++)
+
+static inline struct dtpm *to_dtpm(struct powercap_zone *zone)
+{
+ return container_of(zone, struct dtpm, zone);
+}
+
+int dtpm_update_power(struct dtpm *dtpm, u64 power_min, u64 power_max);
+
+int dtpm_release_zone(struct powercap_zone *pcz);
+
+struct dtpm *dtpm_alloc(void);
+
+void dtpm_unregister(struct dtpm *dtpm);
+
+int dtpm_register_parent(const char *name, struct dtpm *dtpm,
+ struct dtpm *parent);
+
+int dtpm_register(const char *name, struct dtpm *dtpm, struct dtpm
*parent,
+ struct powercap_zone_ops *ops, int nr_constraints,
+ struct powercap_zone_constraint_ops *const_ops);
This header is missing
#ifdef CONFIG_DTPM with static inline functions and empty DTPM_DECLARE()
macro.
I got these issues, when my testing code in scmi-cpufreq.c was compiled
w/o CONFIG_DTPM and DTPM_CPU
/usr/bin/aarch64-linux-gnu-ld: warning: orphan section `__dtpm_table'
from `drivers/cpufreq/scmi-cpufreq.o' being placed in section
`__dtpm_table'.
/usr/bin/aarch64-linux-gnu-ld: Unexpected GOT/PLT entries detected!
/usr/bin/aarch64-linux-gnu-ld: Unexpected run-time procedure linkages
detected!
drivers/cpufreq/scmi-cpufreq.o: In function `dtpm_register_pkg':
/data/linux/drivers/cpufreq/scmi-cpufreq.c:272: undefined reference to
`dtpm_alloc'
/data/linux/drivers/cpufreq/scmi-cpufreq.c:276: undefined reference to
`dtpm_register_parent'
/data/linux/drivers/cpufreq/scmi-cpufreq.c:280: undefined reference to
`dtpm_register_cpu'
Makefile:1164: recipe for target 'vmlinux' failed
The diff bellow fixed my issues. Then I had one for patch 4/4
for static inline int dtpm_register_cpu() function. I've followed the
thermal.h scheme with -ENODEV, but you can choose different approach.
--8<-
diff --git a/include/linux/dtpm.h b/include/linux/dtpm.h
index 6696bdcfdb87..0ef784ca5d0b 100644
--- a/include/linux/dtpm.h
+++ b/include/linux/dtpm.h
@@ -40,6 +40,7 @@ struct dtpm_descr {
extern struct dtpm_descr *__dtpm_table[];
extern struct dtpm_descr *__dtpm_table_end[];
+#ifdef CONFIG_DTPM
#define DTPM_TABLE_ENTRY(name) \
static typeof(name) *__dtpm_table_entry_##name \
__used __section(__dtpm_table) = &name
@@ -70,4 +71,36 @@ int dtpm_register_parent(const char *name, struct
dtpm *dtpm,
int dtpm_register(const char *name, struct dtpm *dtpm, struct dtpm
*parent,
struct powercap_zone_ops *ops, int nr_constraints,
struct powercap_zone_constraint_ops *const_ops);
-#endif
+#else
+#define DTPM_DECLARE(name)
+static inline
+int dtpm_update_power(struct dtpm *dtpm, u64 power_min, u64 power_max)
+{
+ return -ENODEV;
+}
+static inline int dtpm_release_zone(struct powercap_zone *pc
[PATCH] cpufreq: stats: Switch to ktime and msec instead of jiffies and usertime
The cpufreq and thermal core, both provide sysfs statistics to help
userspace learn about the behavior of frequencies and cooling states.
This is how they look:
/sys/devices/system/cpu/cpufreq/policy0/stats/time_in_state:208000 11
/sys/devices/system/cpu/cpufreq/policy0/stats/time_in_state:432000 147
/sys/devices/system/cpu/cpufreq/policy0/stats/time_in_state:729000 1600
/sys/devices/system/cpu/cpufreq/policy0/stats/time_in_state:96 879
/sys/devices/system/cpu/cpufreq/policy0/stats/time_in_state:120 399
/sys/class/thermal/cooling_device0/stats/time_in_state_ms:state0 4097
/sys/class/thermal/cooling_device0/stats/time_in_state_ms:state1 8932
/sys/class/thermal/cooling_device0/stats/time_in_state_ms:state2 15868
/sys/class/thermal/cooling_device0/stats/time_in_state_ms:state3 1384
/sys/class/thermal/cooling_device0/stats/time_in_state_ms:state4 103
Here, state0 of thermal corresponds to the highest frequency of the CPU,
i.e. 120 and state4 to the lowest one.
While both of these try to show similar kind of data (which can still be
very much different from each other), the values looked different (by a
factor of 10, i.e. thermal's time_in_state is almost 10 times that of
cpufreq time_in_state).
This comes from the fact that cpufreq core displays the time in usertime
units (10 ms).
It would be better if both the frameworks displayed times in the same
unit as the users may need to correlate between them and different
scales just make it awkward. And the choice of thermal core for that
(msec) seems to be a better choice as it is easier to read.
The thermal core also does the stats calculations using ktime, which is
much more accurate as compared to jiffies used by cpufreq core.
This patch updates the cpufreq core to use ktime for the internal
calculations and changes the units of time_in_state to msec.
The results look like this after this commit:
/sys/devices/system/cpu/cpufreq/policy0/stats/time_in_state:208000 13
/sys/devices/system/cpu/cpufreq/policy0/stats/time_in_state:432000 790
/sys/devices/system/cpu/cpufreq/policy0/stats/time_in_state:729000 12492
/sys/devices/system/cpu/cpufreq/policy0/stats/time_in_state:96 13259
/sys/devices/system/cpu/cpufreq/policy0/stats/time_in_state:120 3830
/sys/class/thermal/cooling_device0/stats/time_in_state_ms:state0 3888
/sys/class/thermal/cooling_device0/stats/time_in_state_ms:state1 13432
/sys/class/thermal/cooling_device0/stats/time_in_state_ms:state2 12336
/sys/class/thermal/cooling_device0/stats/time_in_state_ms:state3 740
/sys/class/thermal/cooling_device0/stats/time_in_state_ms:state4 0
FWIW, tools/power/cpupower/ does consume the time_in_state values from
the sysfs files but it is independent of the unit of the time and didn't
require an update.
Signed-off-by: Viresh Kumar
---
Documentation/cpu-freq/cpufreq-stats.rst | 5 +--
drivers/cpufreq/cpufreq_stats.c | 47 +---
2 files changed, 28 insertions(+), 24 deletions(-)
diff --git a/Documentation/cpu-freq/cpufreq-stats.rst
b/Documentation/cpu-freq/cpufreq-stats.rst
index 9ad695b1c7db..9f94012a882f 100644
--- a/Documentation/cpu-freq/cpufreq-stats.rst
+++ b/Documentation/cpu-freq/cpufreq-stats.rst
@@ -64,9 +64,8 @@ need for a reboot.
This gives the amount of time spent in each of the frequencies supported by
this CPU. The cat output will have " " pair in each line,
which
-will mean this CPU spent usertime units of time at . Output
-will have one line for each of the supported frequencies. usertime units here
-is 10mS (similar to other time exported in /proc).
+will mean this CPU spent msec of time at . Output will have
+one line for each of the supported frequencies.
::
diff --git a/drivers/cpufreq/cpufreq_stats.c b/drivers/cpufreq/cpufreq_stats.c
index 6cd5c8ab5d49..e054ada291e7 100644
--- a/drivers/cpufreq/cpufreq_stats.c
+++ b/drivers/cpufreq/cpufreq_stats.c
@@ -14,35 +14,38 @@
struct cpufreq_stats {
unsigned int total_trans;
- unsigned long long last_time;
+ ktime_t last_time;
unsigned int max_state;
unsigned int state_num;
unsigned int last_index;
- u64 *time_in_state;
+ ktime_t *time_in_state;
unsigned int *freq_table;
unsigned int *trans_table;
/* Deferred reset */
unsigned int reset_pending;
- unsigned long long reset_time;
+ ktime_t reset_time;
};
-static void cpufreq_stats_update(struct cpufreq_stats *stats,
-unsigned long long time)
+static void cpufreq_stats_update(struct cpufreq_stats *stats, ktime_t time)
{
- unsigned long long cur_time = get_jiffies_64();
+ ktime_t cur_time = ktime_get(), delta;
- stats->time_in_state[stats->last_index] += cur_time - time;
+ delta = ktime_sub(cur_time, time);
+ stats->time_in_state[stats->last_index] =
+ ktime_add(stats->time_in_state[stats->last_index], delta);
stats->last_time = cur_time;
}
sta
Re: [PATCH v1 3/4] bus: mhi: core: Add support to pause or resume channel data transfers
Hi Bhaumik,
On Mon, 9 Nov 2020 at 23:44, Bhaumik Bhatt wrote:
>
> Some MHI clients may want to request for pausing or resuming of the
> data transfers for their channels. Enable them to do so using the new
> APIs provided for the same.
>
> Signed-off-by: Bhaumik Bhatt
> ---
> drivers/bus/mhi/core/main.c | 41 +
> include/linux/mhi.h | 16
> 2 files changed, 57 insertions(+)
>
> diff --git a/drivers/bus/mhi/core/main.c b/drivers/bus/mhi/core/main.c
> index 1226933..01845c6 100644
> --- a/drivers/bus/mhi/core/main.c
> +++ b/drivers/bus/mhi/core/main.c
> @@ -1560,6 +1560,47 @@ void mhi_unprepare_from_transfer(struct mhi_device
> *mhi_dev)
> }
> EXPORT_SYMBOL_GPL(mhi_unprepare_from_transfer);
>
> +static int mhi_update_transfer_state(struct mhi_device *mhi_dev,
> +enum mhi_ch_state_type to_state)
> +{
> + struct mhi_controller *mhi_cntrl = mhi_dev->mhi_cntrl;
> + struct mhi_chan *mhi_chan;
> + int dir, ret;
> +
> + for (dir = 0; dir < 2; dir++) {
> + mhi_chan = dir ? mhi_dev->ul_chan : mhi_dev->dl_chan;
> +
> + if (!mhi_chan)
> + continue;
> +
> + /*
> +* Bail out if one of the channels fail as client will reset
> +* both upon failure
> +*/
> + mutex_lock(&mhi_chan->mutex);
> + ret = mhi_update_channel_state(mhi_cntrl, mhi_chan, to_state);
> + if (ret) {
> + mutex_unlock(&mhi_chan->mutex);
> + return ret;
> + }
> + mutex_unlock(&mhi_chan->mutex);
> + }
> +
> + return 0;
> +}
> +
> +int mhi_pause_transfer(struct mhi_device *mhi_dev)
> +{
> + return mhi_update_transfer_state(mhi_dev, MHI_CH_STATE_TYPE_STOP);
> +}
> +EXPORT_SYMBOL_GPL(mhi_pause_transfer);
> +
> +int mhi_resume_transfer(struct mhi_device *mhi_dev)
> +{
> + return mhi_update_transfer_state(mhi_dev, MHI_CH_STATE_TYPE_START);
> +}
> +EXPORT_SYMBOL_GPL(mhi_resume_transfer);
Look like it is stop and start, not pause and resume?
TBH maybe we should rework/clarify MHI core and having well-defined
states, maybe something like that:
1. When MHI core detects device for a driver, MHI core resets and
initializes the channel(s), then call client driver probe function
=> channel UNKNOWN->DISABLED state
=> channel DISABLED->ENABLED state
2. When driver is ready for sending data, drivers calls mhi_start_transfer
=> Channel is ENABLED->RUNNING state
3. Driver performs normal data transfers
4. The driver can suspend/resume transfer, it stops (suspend) the channel, can
=> Channel is RUNNING->STOP
=> Channel is STOP->RUNNING
...
5. When device is removed, MHI core reset the channel
=> channel is (RUNNING|STOP) -> DISABLED
Today mhi_prepare_for_transfer performs both ENABLE and RUNNING
transition, the idea would be to keep channel enabling/disabling in
the MHI core (before/after driver probe/remove) and channel start/stop
managed by the client driver.
Regards,
Loic
Re: [PATCH v1 00/24] Opt-in always-on nVHE hypervisor
On 2020-11-10 10:15, Christoph Hellwig wrote: On Mon, Nov 09, 2020 at 11:32:09AM +, David Brazdil wrote: As we progress towards being able to keep guest state private to the host running nVHE hypervisor, this series allows the hypervisor to install itself on newly booted CPUs before the host is allowed to run on them. Why? I thought we were trying to kill nVHE off now that newer CPUs provide the saner virtualization extensions? We can't kill nVHE at all, because that is the only game in town. You can't even buy a decent machine with VHE, no matter how much money you put on the table. nVHE is here for the foreseeable future, and we even use its misfeatures to our advantage in order to offer confidential VMs. See Will's presentation at KVM forum a couple of weeks ago for the gory details. Thanks, M. -- Jazz is not dead. It just smells funny...
Re: [PATCH 1/2] dccp: ccid: move timers to struct dccp_sock
On Mon, Nov 09, 2020 at 02:15:53PM -0800, Jakub Kicinski wrote: > On Mon, 9 Nov 2020 18:31:34 -0300 Thadeu Lima de Souza Cascardo wrote: > > > Which paths are those (my memory of this code is waning)? I thought > > > disconnect is only called from the user space side (shutdown syscall). > > > The only other way to terminate the connection is to close the socket, > > > which Eric already fixed by postponing the destruction of ccid in that > > > case. > > > > dccp_v4_do_rcv -> dccp_rcv_established -> dccp_parse_options -> > > dccp_feat_parse_options -> dccp_feat_handle_nn_established -> > > dccp_feat_activate -> __dccp_feat_activate -> dccp_hdlr_ccid -> > > ccid_hc_tx_delete > > Well, that's not a disconnect path. > > There should be no CCID on a disconnected socket, tho, right? Otherwise > if we can switch from one active CCID to another then reusing a single > timer in struct dccp_sock for both is definitely not safe as I > explained in my initial email. Yeah, I agree with your initial email. The patch I submitted for that fix needs rework, which is what I tried and failed so far. I need to get back to some testing of my latest fix and find out what needs fixing there. But I am also saying that simply doing a del_timer_sync on disconnect paths won't do, because there are non-disconnect paths where there is a CCID that we will remove and replace and that will still trigger a timer UAF. So I have been working on a fix that involves a refcnt on ccid itself. But I want to test that it really fixes the problem and I have spent most of the time finding out a way to trigger the timer in a race with the disconnect path. And that same test has showed me that this timer UAF will happen regardless of commit 2677d20677314101293e6da0094ede7b5526d2b1, which led me into stating that reverting it should be done in any case. I think I can find some time this week to work a little further on the fix for the time UAF. Thanks. Cascardo.
[PATCH] powerpc/powernv/sriov: fix unsigned int win compared to less than zero
From: Kaixu Xia
Fix coccicheck warning:
./arch/powerpc/platforms/powernv/pci-sriov.c:443:7-10: WARNING: Unsigned
expression compared with zero: win < 0
./arch/powerpc/platforms/powernv/pci-sriov.c:462:7-10: WARNING: Unsigned
expression compared with zero: win < 0
Reported-by: Tosk Robot
Signed-off-by: Kaixu Xia
---
arch/powerpc/platforms/powernv/pci-sriov.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/platforms/powernv/pci-sriov.c
b/arch/powerpc/platforms/powernv/pci-sriov.c
index c4434f20f42f..92fc861c528f 100644
--- a/arch/powerpc/platforms/powernv/pci-sriov.c
+++ b/arch/powerpc/platforms/powernv/pci-sriov.c
@@ -422,7 +422,7 @@ static int pnv_pci_vf_assign_m64(struct pci_dev *pdev, u16
num_vfs)
{
struct pnv_iov_data *iov;
struct pnv_phb*phb;
- unsigned int win;
+ intwin;
struct resource *res;
inti, j;
int64_trc;
--
2.20.0
[PATCH 1/9] ARM: OMAP2+: Check for inited flag
If we have no hwmods configured and omap_hwmod_init() is not called,
we don't want to call omap_hwmod_setup_all() as it will fail with
checks for configured MPU at least.
Signed-off-by: Tony Lindgren
---
arch/arm/mach-omap2/omap_hwmod.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -627,6 +627,9 @@ static struct clockdomain *_get_clkdm(struct omap_hwmod *oh)
{
struct clk_hw_omap *clk;
+ if (!oh)
+ return NULL;
+
if (oh->clkdm) {
return oh->clkdm;
} else if (oh->_clk) {
@@ -3677,6 +3680,9 @@ static void __init omap_hwmod_setup_earlycon_flags(void)
*/
static int __init omap_hwmod_setup_all(void)
{
+ if (!inited)
+ return 0;
+
_ensure_mpu_hwmod_is_setup(NULL);
omap_hwmod_for_each(_init, NULL);
--
2.29.2
[PATCH 4/9] bus: ti-sysc: Support modules without control registers
Some modules like MPU have a powerdomain and functional clock but not
necessarily any control registers. Let's allow configuring interconnect
target modules with no control registers.
Signed-off-by: Tony Lindgren
---
drivers/bus/ti-sysc.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/bus/ti-sysc.c b/drivers/bus/ti-sysc.c
--- a/drivers/bus/ti-sysc.c
+++ b/drivers/bus/ti-sysc.c
@@ -853,8 +853,12 @@ static int sysc_ioremap(struct sysc *ddata)
*/
static int sysc_map_and_check_registers(struct sysc *ddata)
{
+ struct device_node *np = ddata->dev->of_node;
int error;
+ if (!of_get_property(np, "reg", NULL))
+ return 0;
+
error = sysc_parse_and_check_child_range(ddata);
if (error)
return error;
@@ -2911,6 +2915,9 @@ static int sysc_probe(struct platform_device *pdev)
if (!ddata)
return -ENOMEM;
+ ddata->offsets[SYSC_REVISION] = -ENODEV;
+ ddata->offsets[SYSC_SYSCONFIG] = -ENODEV;
+ ddata->offsets[SYSC_SYSSTATUS] = -ENODEV;
ddata->dev = &pdev->dev;
platform_set_drvdata(pdev, ddata);
--
2.29.2
[PATCH 2/9] ARM: OMAP2+: Probe PRCM first to probe l4_wkup with simple-pm-bus
In preparation for probing the interconnects with simple-pm-bus to
make use of genpd, we need to probe the always-on PRCM first for the
clocks needed by l4_wkup instance.
Signed-off-by: Tony Lindgren
---
arch/arm/mach-omap2/pdata-quirks.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm/mach-omap2/pdata-quirks.c
b/arch/arm/mach-omap2/pdata-quirks.c
--- a/arch/arm/mach-omap2/pdata-quirks.c
+++ b/arch/arm/mach-omap2/pdata-quirks.c
@@ -580,6 +580,8 @@ static void pdata_quirks_check(struct pdata_init *quirks)
void __init pdata_quirks_init(const struct of_device_id *omap_dt_match_table)
{
+ struct device_node *np;
+
/*
* We still need this for omap2420 and omap3 PM to work, others are
* using drivers/misc/sram.c already.
@@ -591,6 +593,15 @@ void __init pdata_quirks_init(const struct of_device_id
*omap_dt_match_table)
if (of_machine_is_compatible("ti,omap3"))
omap3_mcbsp_init();
pdata_quirks_check(auxdata_quirks);
+
+ /* Populate always-on PRCM in l4_wkup to probe l4_wkup */
+ np = of_find_node_by_name(NULL, "prcm");
+ if (!np)
+ np = of_find_node_by_name(NULL, "prm");
+ if (np)
+ of_platform_populate(np, omap_dt_match_table,
+omap_auxdata_lookup, NULL);
+
of_platform_populate(NULL, omap_dt_match_table,
omap_auxdata_lookup, NULL);
pdata_quirks_check(pdata_quirks);
--
2.29.2
[PATCHv2 0/9] Genpd related code changes to drop am335x pdata
Hi all, Here's v2 set of changes for v5.11 merge window to drop the remaining am335x platform data. Changes since v1: - Simplify wkup_m3_rproc.c changes as suggested by Philipp Zabel - Do not configure pm_clk for omap_prm.c except for simple-pm-bus These patches depend on: [PATCH 2/4] ARM: OMAP2+: Fix missing select PM_GENERIC_DOMAINS_OF And the related device tree changes have been posted as: [PATCH 00/18] Drop remaining pdata for am335x and use genpd Regards, Tony Tero Kristo (1): soc: ti: omap-prm: am3: add genpd support for remaining PRM instances Tony Lindgren (8): ARM: OMAP2+: Check for inited flag ARM: OMAP2+: Probe PRCM first to probe l4_wkup with simple-pm-bus clk: ti: am33xx: Keep am3 l3 main clock always on for genpd bus: ti-sysc: Support modules without control registers bus: ti-sysc: Implement GPMC debug quirk to drop platform data soc: ti: omap-prm: Add pm_clk for genpd soc: ti: pm33xx: Enable basic PM runtime support for genpd remoteproc/wkup_m3: Use reset control driver if available arch/arm/mach-omap2/omap_hwmod.c | 6 ++ arch/arm/mach-omap2/pdata-quirks.c| 11 drivers/bus/ti-sysc.c | 17 ++ drivers/clk/ti/clk-33xx.c | 2 + drivers/remoteproc/wkup_m3_rproc.c| 41 +- drivers/soc/ti/omap_prm.c | 80 ++- drivers/soc/ti/pm33xx.c | 17 +- include/linux/platform_data/ti-sysc.h | 1 + 8 files changed, 157 insertions(+), 18 deletions(-) -- 2.29.2
Re: [PATCH v2 03/10] usb: cdns3: Moves reusable code to separate module
On 20-11-10 09:20:54, Pawel Laszczak wrote: > Hi, > > >> > >> int cdns3_hw_role_switch(struct cdns3 *cdns); > >> -int cdns3_init(struct cdns3 *cdns); > >> -int cdns3_remove(struct cdns3 *cdns); > >> +extern int cdns3_init(struct cdns3 *cdns); > >> +extern int cdns3_remove(struct cdns3 *cdns); > > > >Why add "extern" here and below? > > > > These functions are the API between cdnsp and cdns3 modules. > It's looks like a common approach in kernel. > Many or even most of API function in kernel has "extern". > Even you have not written "extern" keyword, the "extern" is added implicitly by compiler. Usually, we use "extern" for variable or the function is defined at assembly. You could see some "extern" keyword use cases at include/linux/device.h. Never mind, it is not a issue. Peter > Of course, here we have little different situation because these API functions > are limited only to cdns3 directory. > > was not sure about that, but I think that this extern is the > information that these functions are used, or can be used > by other modules. > > Am I right ? > > >> > >> #ifdef CONFIG_PM_SLEEP > >> -int cdns3_resume(struct cdns3 *cdns, u8 set_active); > >> -int cdns3_suspend(struct cdns3 *cdns); > >> +extern int cdns3_resume(struct cdns3 *cdns, u8 set_active); > >> +extern int cdns3_suspend(struct cdns3 *cdns); > >> #endif /* CONFIG_PM_SLEEP */ > >> #endif /* __LINUX_CDNS3_CORE_H */ > >> diff --git a/drivers/usb/cdns3/drd.c b/drivers/usb/cdns3/drd.c > >> index ed8cde91a02c..1874dc6018f0 100644 > >> --- a/drivers/usb/cdns3/drd.c > >> +++ b/drivers/usb/cdns3/drd.c > >> @@ -15,7 +15,6 @@ > >> #include > >> #include > >> > >> -#include "gadget.h" > >> #include "drd.h" > >> #include "core.h" > >> > >> @@ -226,6 +225,7 @@ int cdns3_drd_gadget_on(struct cdns3 *cdns) > >>phy_set_mode(cdns->usb3_phy, PHY_MODE_USB_DEVICE); > >>return 0; > >> } > >> +EXPORT_SYMBOL_GPL(cdns3_drd_gadget_on); > >> > >> /** > >> * cdns3_drd_gadget_off - stop gadget. > >> @@ -249,6 +249,7 @@ void cdns3_drd_gadget_off(struct cdns3 *cdns) > >> 1, 200); > >>phy_set_mode(cdns->usb3_phy, PHY_MODE_INVALID); > >> } > >> +EXPORT_SYMBOL_GPL(cdns3_drd_gadget_off); > >> > >> /** > >> * cdns3_init_otg_mode - initialize drd controller > >> diff --git a/drivers/usb/cdns3/drd.h b/drivers/usb/cdns3/drd.h > >> index d752d8806a38..972aba8a40b6 100644 > >> --- a/drivers/usb/cdns3/drd.h > >> +++ b/drivers/usb/cdns3/drd.h > >> @@ -209,8 +209,8 @@ int cdns3_get_vbus(struct cdns3 *cdns); > >> int cdns3_drd_init(struct cdns3 *cdns); > >> int cdns3_drd_exit(struct cdns3 *cdns); > >> int cdns3_drd_update_mode(struct cdns3 *cdns); > >> -int cdns3_drd_gadget_on(struct cdns3 *cdns); > >> -void cdns3_drd_gadget_off(struct cdns3 *cdns); > >> +extern int cdns3_drd_gadget_on(struct cdns3 *cdns); > >> +extern void cdns3_drd_gadget_off(struct cdns3 *cdns); > >> int cdns3_drd_host_on(struct cdns3 *cdns); > >> void cdns3_drd_host_off(struct cdns3 *cdns); > >> > >> -- > >> 2.17.1 > >> > > -- > Thanks > Pawel Laszczak -- Thanks, Peter Chen
[PATCH 5/9] bus: ti-sysc: Implement GPMC debug quirk to drop platform data
We need to enable no-reset-on-init quirk for GPMC if the config
option for CONFIG_OMAP_GPMC_DEBUG is set. Otherwise the GPMC
driver code is unable to show the bootloader configured timings.
Signed-off-by: Tony Lindgren
---
drivers/bus/ti-sysc.c | 10 ++
include/linux/platform_data/ti-sysc.h | 1 +
2 files changed, 11 insertions(+)
diff --git a/drivers/bus/ti-sysc.c b/drivers/bus/ti-sysc.c
--- a/drivers/bus/ti-sysc.c
+++ b/drivers/bus/ti-sysc.c
@@ -1383,6 +1383,8 @@ static const struct sysc_revision_quirk
sysc_revision_quirks[] = {
SYSC_QUIRK_CLKDM_NOAUTO),
SYSC_QUIRK("dwc3", 0x488c, 0, 0x10, -ENODEV, 0x500a0200, 0x,
SYSC_QUIRK_CLKDM_NOAUTO),
+ SYSC_QUIRK("gpmc", 0, 0, 0x10, 0x14, 0x0060, 0x,
+ SYSC_QUIRK_GPMC_DEBUG),
SYSC_QUIRK("hdmi", 0, 0, 0x10, -ENODEV, 0x50030200, 0x,
SYSC_QUIRK_OPT_CLKS_NEEDED),
SYSC_QUIRK("hdq1w", 0, 0, 0x14, 0x18, 0x0006, 0x,
@@ -1818,6 +1820,14 @@ static void sysc_init_module_quirks(struct sysc *ddata)
return;
}
+#ifdef CONFIG_OMAP_GPMC_DEBUG
+ if (ddata->cfg.quirks & SYSC_QUIRK_GPMC_DEBUG) {
+ ddata->cfg.quirks |= SYSC_QUIRK_NO_RESET_ON_INIT;
+
+ return;
+ }
+#endif
+
if (ddata->cfg.quirks & SYSC_MODULE_QUIRK_I2C) {
ddata->pre_reset_quirk = sysc_pre_reset_quirk_i2c;
ddata->post_reset_quirk = sysc_post_reset_quirk_i2c;
diff --git a/include/linux/platform_data/ti-sysc.h
b/include/linux/platform_data/ti-sysc.h
--- a/include/linux/platform_data/ti-sysc.h
+++ b/include/linux/platform_data/ti-sysc.h
@@ -50,6 +50,7 @@ struct sysc_regbits {
s8 emufree_shift;
};
+#define SYSC_QUIRK_GPMC_DEBUG BIT(26)
#define SYSC_MODULE_QUIRK_ENA_RESETDONEBIT(25)
#define SYSC_MODULE_QUIRK_PRUSSBIT(24)
#define SYSC_MODULE_QUIRK_DSS_RESETBIT(23)
--
2.29.2
[PATCH 6/9] soc: ti: omap-prm: Add pm_clk for genpd
In order to probe l3 and l4 interconnects with simple-pm-bus, we want
genpd to manage the clocks for the interconnects. For interconnect target
modules, we already have ti-sysc manage the clocks so let's skipe managing
clocks for ti-sysc modules.
Cc: Santosh Shilimkar
Signed-off-by: Tony Lindgren
---
drivers/soc/ti/omap_prm.c | 44 +++
1 file changed, 44 insertions(+)
diff --git a/drivers/soc/ti/omap_prm.c b/drivers/soc/ti/omap_prm.c
--- a/drivers/soc/ti/omap_prm.c
+++ b/drivers/soc/ti/omap_prm.c
@@ -7,6 +7,7 @@
*/
#include
+#include
#include
#include
#include
@@ -14,6 +15,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -41,6 +43,7 @@ struct omap_prm_domain {
u16 pwrstst;
const struct omap_prm_domain_map *cap;
u32 pwrstctrl_saved;
+ unsigned int uses_pm_clk:1;
};
struct omap_rst_map {
@@ -325,6 +328,38 @@ static int omap_prm_domain_power_off(struct
generic_pm_domain *domain)
return 0;
}
+/*
+ * Note that ti-sysc already manages the module clocks separately so
+ * no need to manage those. Interconnect instances need clocks managed
+ * for simple-pm-bus.
+ */
+static int omap_prm_domain_attach_clock(struct device *dev,
+ struct omap_prm_domain *prmd)
+{
+ struct device_node *np = dev->of_node;
+ int error;
+
+ if (!of_device_is_compatible(np, "simple-pm-bus"))
+ return 0;
+
+ if (!of_property_read_bool(np, "clocks"))
+ return 0;
+
+ error = pm_clk_create(dev);
+ if (error)
+ return error;
+
+ error = of_pm_clk_add_clks(dev);
+ if (error < 0) {
+ pm_clk_destroy(dev);
+ return error;
+ }
+
+ prmd->uses_pm_clk = 1;
+
+ return 0;
+}
+
static int omap_prm_domain_attach_dev(struct generic_pm_domain *domain,
struct device *dev)
{
@@ -349,6 +384,10 @@ static int omap_prm_domain_attach_dev(struct
generic_pm_domain *domain,
genpd_data = dev_gpd_data(dev);
genpd_data->data = NULL;
+ ret = omap_prm_domain_attach_clock(dev, prmd);
+ if (ret)
+ return ret;
+
return 0;
}
@@ -356,7 +395,11 @@ static void omap_prm_domain_detach_dev(struct
generic_pm_domain *domain,
struct device *dev)
{
struct generic_pm_domain_data *genpd_data;
+ struct omap_prm_domain *prmd;
+ prmd = genpd_to_prm_domain(domain);
+ if (prmd->uses_pm_clk)
+ pm_clk_destroy(dev);
genpd_data = dev_gpd_data(dev);
genpd_data->data = NULL;
}
@@ -393,6 +436,7 @@ static int omap_prm_domain_init(struct device *dev, struct
omap_prm *prm)
prmd->pd.power_off = omap_prm_domain_power_off;
prmd->pd.attach_dev = omap_prm_domain_attach_dev;
prmd->pd.detach_dev = omap_prm_domain_detach_dev;
+ prmd->pd.flags = GENPD_FLAG_PM_CLK;
pm_genpd_init(&prmd->pd, NULL, true);
error = of_genpd_add_provider_simple(np, &prmd->pd);
--
2.29.2
[PATCH 3/9] clk: ti: am33xx: Keep am3 l3 main clock always on for genpd
In order for suspend and resume to work with genpd on am3, we must keep
l3 main clock always on. Otherwise prm_omap driver will shut down the l3
main clock on suspend when simple-pm-bus and GENPD_FLAG_PM_CLK are used.
Note that we already keep the l3 main clock always on with the legacy
platform code.
Later on we may want to start managing the l3 main clock with a dedicated
interconnect driver instead of using simple-pm-bus and GENPD_FLAG_PM_CLK.
Cc: linux-...@vger.kernel.org
Cc: Michael Turquette
Cc: Stephen Boyd
Cc: Tero Kristo
Signed-off-by: Tony Lindgren
---
drivers/clk/ti/clk-33xx.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/clk/ti/clk-33xx.c b/drivers/clk/ti/clk-33xx.c
--- a/drivers/clk/ti/clk-33xx.c
+++ b/drivers/clk/ti/clk-33xx.c
@@ -266,6 +266,8 @@ static const char *enable_init_clks[] = {
"dpll_ddr_m2_ck",
"dpll_mpu_m2_ck",
"l3_gclk",
+ /* AM3_L3_L3_MAIN_CLKCTRL, needed during suspend */
+ "l3-clkctrl:00bc:0",
"l4hs_gclk",
"l4fw_gclk",
"l4ls_gclk",
--
2.29.2
Re: [PATCH] mm/zsmalloc: include sparsemem.h for MAX_PHYSMEM_BITS
On Tue, Nov 10, 2020 at 10:58 AM Mike Rapoport wrote:
> > >
> > > asm/sparsemem.h is not available on some architectures.
> > > It's better to use linux/mmzone.h instead.
Ah, I missed that, too.
> > Hm, linux/mmzone.h only includes asm/sparsemem.h when CONFIG_SPARSEMEM
> > is enabled. However, on ARM at least I can have configurations without
> > CONFIG_SPARSEMEM and physical address extension on (e.g.
> > multi_v7_defconfig + CONFIG_LPAE + CONFIG_ZSMALLOC).
> >
> > While sparsemem seems to be a good idea with LPAE it really seems not
> > required (see also https://lore.kernel.org/patchwork/patch/567589/).
> >
> > There seem to be also other architectures which define MAX_PHYSMEM_BITS
> > only when SPARSEMEM is enabled, e.g.
> > arch/riscv/include/asm/sparsemem.h...
> >
> > Not sure how to get out of this.. Maybe make ZSMALLOC dependent on
> > SPARSEMEM? It feels a bit silly restricting ZSMALLOC selection only due
> > to a compile time define...
>
> I think we can define MAX_POSSIBLE_PHYSMEM_BITS in one of
> arch/arm/inclide/asm/pgtable-{2,3}level-*.h headers to values supported
> by !LPAE and LPAE.
Good idea. I wonder what other architectures need the same though.
Here are some I found:
$ git grep -l PHYS_ADDR_T_64BIT arch | grep Kconfig
arch/arc/Kconfig
arch/arm/mm/Kconfig
arch/mips/Kconfig
arch/powerpc/platforms/Kconfig.cputype
arch/x86/Kconfig
arch/arc has a CONFIG_ARC_HAS_PAE40 option
arch/riscv has 34-bit addressing in rv32 mode
arch/mips has up to 40 bits with mips32r3 XPA, but I don't know what
supports that
arch/powerpc has this:
config PHYS_64BIT
bool 'Large physical address support' if E500 || PPC_86xx
depends on (44x || E500 || PPC_86xx) && !PPC_83xx && !PPC_82xx
Apparently all three (4xx, e500v2, mpc86xx/e600) do 36-bit physical
addressing, but each one has a different page table format.
Microblaze has physical address extensions, but neither those nor
64-bit mode have so far made it into the kernel.
To be on the safe side, we could provoke a compile-time error
when CONFIG_PHYS_ADDR_T_64BIT is set on a 32-bit
architecture, but MAX_POSSIBLE_PHYSMEM_BITS is not set.
> That's what x86 does:
>
> $ git grep -w MAX_POSSIBLE_PHYSMEM_BITS arch/
> arch/x86/include/asm/pgtable-3level_types.h:#define MAX_POSSIBLE_PHYSMEM_BITS
> 36
Doesn't x86 also support a 40-bit addressing mode? I suppose
those machines that actually used it are long gone.
> arch/x86/include/asm/pgtable_64_types.h:#define MAX_POSSIBLE_PHYSMEM_BITS
> 52
>
> It seems that actual numbers would be 36 for !LPAE and 40 for LPAE, but
> I'm not sure about that.
Close enough, yes.
The 36-bit addressing is on !LPAE is only used for early static mappings,
so I think we can pretend it's always 32-bit. I checked the ARMv8 reference,
and it says that ARMv8-Aarch32 actually supports 40 bit physical addressing
both with non-LPAE superpages (short descriptor format) and LPAE (long
descriptor format), but Linux only does 36-bit addressing on superpages
as specified for ARMv6/ARMv7 short descriptors.
Arnd
[PATCH 8/9] soc: ti: pm33xx: Enable basic PM runtime support for genpd
To prepare for moving to use genpd, let's enable basic PM
runtime support.
Cc: Dave Gerlach
Cc: Santosh Shilimkar
Cc: Suman Anna
Signed-off-by: Tony Lindgren
---
drivers/soc/ti/pm33xx.c | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/drivers/soc/ti/pm33xx.c b/drivers/soc/ti/pm33xx.c
--- a/drivers/soc/ti/pm33xx.c
+++ b/drivers/soc/ti/pm33xx.c
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -555,16 +556,26 @@ static int am33xx_pm_probe(struct platform_device *pdev)
suspend_wfi_flags |= WFI_FLAG_WAKE_M3;
#endif /* CONFIG_SUSPEND */
+ pm_runtime_enable(dev);
+ ret = pm_runtime_get_sync(dev);
+ if (ret < 0) {
+ pm_runtime_put_noidle(dev);
+ goto err_pm_runtime_disable;
+ }
+
ret = pm_ops->init(am33xx_do_sram_idle);
if (ret) {
dev_err(dev, "Unable to call core pm init!\n");
ret = -ENODEV;
- goto err_put_wkup_m3_ipc;
+ goto err_pm_runtime_put;
}
return 0;
-err_put_wkup_m3_ipc:
+err_pm_runtime_put:
+ pm_runtime_put_sync(dev);
+err_pm_runtime_disable:
+ pm_runtime_disable(dev);
wkup_m3_ipc_put(m3_ipc);
err_free_sram:
am33xx_pm_free_sram();
@@ -574,6 +585,8 @@ static int am33xx_pm_probe(struct platform_device *pdev)
static int am33xx_pm_remove(struct platform_device *pdev)
{
+ pm_runtime_put_sync(&pdev->dev);
+ pm_runtime_disable(&pdev->dev);
if (pm_ops->deinit)
pm_ops->deinit();
suspend_set_ops(NULL);
--
2.29.2
[PATCH 7/9] soc: ti: omap-prm: am3: add genpd support for remaining PRM instances
From: Tero Kristo
Add genpd support for per, wkup, mpu, rtc and cefuse instances.
Cc: Santosh Shilimkar
Signed-off-by: Tero Kristo
Signed-off-by: Tony Lindgren
---
drivers/soc/ti/omap_prm.c | 36 +---
1 file changed, 33 insertions(+), 3 deletions(-)
diff --git a/drivers/soc/ti/omap_prm.c b/drivers/soc/ti/omap_prm.c
--- a/drivers/soc/ti/omap_prm.c
+++ b/drivers/soc/ti/omap_prm.c
@@ -124,6 +124,10 @@ static const struct omap_prm_domain_map
omap_prm_onoff_noauto = {
.statechange = 1,
};
+static const struct omap_prm_domain_map omap_prm_alwon = {
+ .usable_modes = BIT(OMAP_PRMD_ON_ACTIVE),
+};
+
static const struct omap_rst_map rst_map_0[] = {
{ .rst = 0, .st = 0 },
{ .rst = -1 },
@@ -190,14 +194,40 @@ static const struct omap_rst_map am3_wkup_rst_map[] = {
};
static const struct omap_prm_data am3_prm_data[] = {
- { .name = "per", .base = 0x44e00c00, .rstctrl = 0x0, .rstmap =
am3_per_rst_map, .flags = OMAP_PRM_HAS_RSTCTRL, .clkdm_name = "pruss_ocp" },
- { .name = "wkup", .base = 0x44e00d00, .rstctrl = 0x0, .rstst = 0xc,
.rstmap = am3_wkup_rst_map, .flags = OMAP_PRM_HAS_RSTCTRL |
OMAP_PRM_HAS_NO_CLKDM },
- { .name = "device", .base = 0x44e00f00, .rstctrl = 0x0, .rstst = 0x8,
.rstmap = rst_map_01, .flags = OMAP_PRM_HAS_RSTCTRL | OMAP_PRM_HAS_NO_CLKDM },
+ {
+ .name = "per", .base = 0x44e00c00,
+ .pwrstctrl = 0xc, .pwrstst = 0x8, .dmap = &omap_prm_noinact,
+ .rstctrl = 0x0, .rstmap = am3_per_rst_map,
+ .flags = OMAP_PRM_HAS_RSTCTRL, .clkdm_name = "pruss_ocp"
+ },
+ {
+ .name = "wkup", .base = 0x44e00d00,
+ .pwrstctrl = 0x4, .pwrstst = 0x4, .dmap = &omap_prm_alwon,
+ .rstctrl = 0x0, .rstst = 0xc, .rstmap = am3_wkup_rst_map,
+ .flags = OMAP_PRM_HAS_RSTCTRL | OMAP_PRM_HAS_NO_CLKDM
+ },
+ {
+ .name = "mpu", .base = 0x44e00e00,
+ .pwrstctrl = 0x0, .pwrstst = 0x4, .dmap = &omap_prm_noinact,
+ },
+ {
+ .name = "device", .base = 0x44e00f00,
+ .rstctrl = 0x0, .rstst = 0x8, .rstmap = rst_map_01,
+ .flags = OMAP_PRM_HAS_RSTCTRL | OMAP_PRM_HAS_NO_CLKDM
+ },
+ {
+ .name = "rtc", .base = 0x44e01000,
+ .pwrstctrl = 0x0, .pwrstst = 0x4, .dmap = &omap_prm_alwon,
+ },
{
.name = "gfx", .base = 0x44e01100,
.pwrstctrl = 0, .pwrstst = 0x10, .dmap = &omap_prm_noinact,
.rstctrl = 0x4, .rstst = 0x14, .rstmap = rst_map_0, .clkdm_name
= "gfx_l3",
},
+ {
+ .name = "cefuse", .base = 0x44e01200,
+ .pwrstctrl = 0x0, .pwrstst = 0x4, .dmap =
&omap_prm_onoff_noauto,
+ },
{ },
};
--
2.29.2
[PATCH 9/9] remoteproc/wkup_m3: Use reset control driver if available
In order to move wkup_m3 to probe without platform data, let's add
support for using optional reset control driver if configured in the
dts. With this change and the related dts change, we can start
dropping the platform data for am335x.
And once wkup_m3 no longer needs platform data, we can simply drop the
related legacy reset platform data callbacks from wkup_m3 driver later
on after also am437x no longer depends on it.
Cc: linux-remotep...@vger.kernel.org
Cc: Bjorn Andersson
Cc: Dave Gerlach
Cc: Philipp Zabel
Cc: Suman Anna
Signed-off-by: Tony Lindgren
---
Please review and ack if no issues. If you guys instead want to set up an
immutable remoteproc branch with just this patch in it against v5.10-rc1
that works too :)
---
drivers/remoteproc/wkup_m3_rproc.c | 41 --
1 file changed, 28 insertions(+), 13 deletions(-)
diff --git a/drivers/remoteproc/wkup_m3_rproc.c
b/drivers/remoteproc/wkup_m3_rproc.c
--- a/drivers/remoteproc/wkup_m3_rproc.c
+++ b/drivers/remoteproc/wkup_m3_rproc.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include
@@ -43,11 +44,13 @@ struct wkup_m3_mem {
* @rproc: rproc handle
* @pdev: pointer to platform device
* @mem: WkupM3 memory information
+ * @rsts: reset control
*/
struct wkup_m3_rproc {
struct rproc *rproc;
struct platform_device *pdev;
struct wkup_m3_mem mem[WKUPM3_MEM_MAX];
+ struct reset_control *rsts;
};
static int wkup_m3_rproc_start(struct rproc *rproc)
@@ -56,13 +59,16 @@ static int wkup_m3_rproc_start(struct rproc *rproc)
struct platform_device *pdev = wkupm3->pdev;
struct device *dev = &pdev->dev;
struct wkup_m3_platform_data *pdata = dev_get_platdata(dev);
+ int error = 0;
- if (pdata->deassert_reset(pdev, pdata->reset_name)) {
+ error = reset_control_deassert(wkupm3->rsts);
+
+ if (!wkupm3->rsts && pdata->deassert_reset(pdev, pdata->reset_name)) {
dev_err(dev, "Unable to reset wkup_m3!\n");
- return -ENODEV;
+ error = -ENODEV;
}
- return 0;
+ return error;
}
static int wkup_m3_rproc_stop(struct rproc *rproc)
@@ -71,13 +77,16 @@ static int wkup_m3_rproc_stop(struct rproc *rproc)
struct platform_device *pdev = wkupm3->pdev;
struct device *dev = &pdev->dev;
struct wkup_m3_platform_data *pdata = dev_get_platdata(dev);
+ int error = 0;
- if (pdata->assert_reset(pdev, pdata->reset_name)) {
+ error = reset_control_assert(wkupm3->rsts);
+
+ if (!wkupm3->rsts && pdata->assert_reset(pdev, pdata->reset_name)) {
dev_err(dev, "Unable to assert reset of wkup_m3!\n");
- return -ENODEV;
+ error = -ENODEV;
}
- return 0;
+ return error;
}
static void *wkup_m3_rproc_da_to_va(struct rproc *rproc, u64 da, size_t len)
@@ -132,12 +141,6 @@ static int wkup_m3_rproc_probe(struct platform_device
*pdev)
int ret;
int i;
- if (!(pdata && pdata->deassert_reset && pdata->assert_reset &&
- pdata->reset_name)) {
- dev_err(dev, "Platform data missing!\n");
- return -ENODEV;
- }
-
ret = of_property_read_string(dev->of_node, "ti,pm-firmware",
&fw_name);
if (ret) {
@@ -165,6 +168,18 @@ static int wkup_m3_rproc_probe(struct platform_device
*pdev)
wkupm3->rproc = rproc;
wkupm3->pdev = pdev;
+ wkupm3->rsts = devm_reset_control_get_optional_shared(dev, "rstctrl");
+ if (IS_ERR(wkupm3->rsts))
+ return PTR_ERR(wkupm3->rsts);
+ if (!wkupm3->rsts) {
+ if (!(pdata && pdata->deassert_reset && pdata->assert_reset &&
+ pdata->reset_name)) {
+ dev_err(dev, "Platform data missing!\n");
+ ret = -ENODEV;
+ goto err_put_rproc;
+ }
+ }
+
for (i = 0; i < ARRAY_SIZE(mem_names); i++) {
res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
mem_names[i]);
@@ -173,7 +188,7 @@ static int wkup_m3_rproc_probe(struct platform_device *pdev)
dev_err(&pdev->dev, "devm_ioremap_resource failed for
resource %d\n",
i);
ret = PTR_ERR(wkupm3->mem[i].cpu_addr);
- goto err;
+ goto err_put_rproc;
}
wkupm3->mem[i].bus_addr = res->start;
wkupm3->mem[i].size = resource_size(res);
--
2.29.2
[tip: sched/core] sched/fair: Reorder throttle_cfs_rq() path
The following commit has been merged into the sched/core branch of tip:
Commit-ID: b6d37a764a5b852db63101b3f2db0e699574b903
Gitweb:
https://git.kernel.org/tip/b6d37a764a5b852db63101b3f2db0e699574b903
Author:Peng Wang
AuthorDate:Tue, 10 Nov 2020 10:11:59 +08:00
Committer: Ingo Molnar
CommitterDate: Tue, 10 Nov 2020 12:20:12 +01:00
sched/fair: Reorder throttle_cfs_rq() path
As commit:
39f23ce07b93 ("sched/fair: Fix unthrottle_cfs_rq() for leaf_cfs_rq list")
does in unthrottle_cfs_rq(), throttle_cfs_rq() can also use the same
pattern as dequeue_task_fair().
No functional changes.
Signed-off-by: Peng Wang
Signed-off-by: Ingo Molnar
Cc: Vincent Guittot
Cc: Peter Zijlstra (Intel)
Cc: Phil Auld
Cc: Ben Segall
Link:
https://lore.kernel.org/r/f11dd2e3ab35cc538e2eb57bf0c99b6eaffce127.1604973978.git.rock...@linux.alibaba.com
---
kernel/sched/fair.c | 34 +++---
1 file changed, 23 insertions(+), 11 deletions(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 52cacfc..2755a7e 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -4788,25 +4788,37 @@ static bool throttle_cfs_rq(struct cfs_rq *cfs_rq)
struct cfs_rq *qcfs_rq = cfs_rq_of(se);
/* throttled entity or throttle-on-deactivate */
if (!se->on_rq)
- break;
+ goto done;
- if (dequeue) {
- dequeue_entity(qcfs_rq, se, DEQUEUE_SLEEP);
- } else {
- update_load_avg(qcfs_rq, se, 0);
- se_update_runnable(se);
- }
+ dequeue_entity(qcfs_rq, se, DEQUEUE_SLEEP);
qcfs_rq->h_nr_running -= task_delta;
qcfs_rq->idle_h_nr_running -= idle_task_delta;
- if (qcfs_rq->load.weight)
- dequeue = 0;
+ if (qcfs_rq->load.weight) {
+ /* Avoid re-evaluating load for this entity: */
+ se = parent_entity(se);
+ break;
+ }
}
- if (!se)
- sub_nr_running(rq, task_delta);
+ for_each_sched_entity(se) {
+ struct cfs_rq *qcfs_rq = cfs_rq_of(se);
+ /* throttled entity or throttle-on-deactivate */
+ if (!se->on_rq)
+ goto done;
+
+ update_load_avg(qcfs_rq, se, 0);
+ se_update_runnable(se);
+ qcfs_rq->h_nr_running -= task_delta;
+ qcfs_rq->idle_h_nr_running -= idle_task_delta;
+ }
+
+ /* At this point se is NULL and we are at root level*/
+ sub_nr_running(rq, task_delta);
+
+done:
/*
* Note: distribution will already see us throttled via the
* throttled-list. rq->lock protects completion.
Re: How to enable auto-suspend by default
On Tue, Nov 10, 2020 at 11:57:07AM +0100, Bastien Nocera wrote: > Hey, > > systemd has been shipping this script to enable auto-suspend on a > number of USB and PCI devices: > https://github.com/systemd/systemd/blob/master/tools/chromiumos/gen_autosuspend_rules.py > > The problem here is twofold. First, the list of devices is updated from > ChromeOS, and the original list obviously won't be updated by ChromeOS > developers unless a device listed exists in a ChromeBook computer, > which means a number of devices that do support autosuspend aren't > listed. > > The other problem is that this list needs to exist at all, and that it > doesn't seem possible for device driver developers (at various levels > of the stack) to opt-in to auto-suspend when all the variants of the > device (or at least detectable ones) support auto-suspend. A driver can say they support autosuspend today, but I think you are concerned about the devices that are controlled by class-compliant drivers, right? And for those, no, we can't do this in the kernel as there are just too many broken devices out there. As proof of this, look at other operating systems. They had to implement the same type of "allowed devices" list that we do. In fact, we did this for Linux because they did this, which means that when hardware manufacturers test their device, they only test with other operating systems and not Linux and so, we need to match what those other OSes do as well. Sorry, greg k-h
[PATCH] drm/amd/pm: Use kmemdup instead of kmalloc and memcpy
Fixes coccicheck warning: drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega12_processpptables.c:255: 36-43: WARNING opportunity for kmemdup Signed-off-by: Tian Tao --- drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega12_processpptables.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega12_processpptables.c b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega12_processpptables.c index 740e2fc..1e79baa 100644 --- a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega12_processpptables.c +++ b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega12_processpptables.c @@ -252,12 +252,11 @@ static int init_powerplay_table_information( phm_copy_clock_limits_array(hwmgr, &pptable_information->power_saving_clock_max, powerplay_table->PowerSavingClockMax, ATOM_VEGA12_PPCLOCK_COUNT); phm_copy_clock_limits_array(hwmgr, &pptable_information->power_saving_clock_min, powerplay_table->PowerSavingClockMin, ATOM_VEGA12_PPCLOCK_COUNT); - pptable_information->smc_pptable = kmalloc(sizeof(PPTable_t), GFP_KERNEL); + pptable_information->smc_pptable = kmemdup(&(powerplay_table->smcPPTable), + sizeof(PPTable_t), GFP_KERNEL); if (pptable_information->smc_pptable == NULL) return -ENOMEM; - memcpy(pptable_information->smc_pptable, &(powerplay_table->smcPPTable), sizeof(PPTable_t)); - result = append_vbios_pptable(hwmgr, (pptable_information->smc_pptable)); return result; -- 2.7.4
Re: [PATCH 1/3] dt-bindings: gpio: sunxi：create a DT header for Allwinner pin controller
On Wed, Oct 28, 2020 at 08:15:45PM +0800, Frank Lee wrote:
> On Wed, Jul 29, 2020 at 9:06 PM Maxime Ripard wrote:
> >
> > Hi,
> >
> > On Sat, Jul 25, 2020 at 02:18:39PM -0500, Samuel Holland wrote:
> > > On 7/17/20 11:07 AM, Maxime Ripard wrote:
> > > > Hi!
> > > >
> > > > On Wed, Jul 15, 2020 at 07:54:12PM +0800, Frank Lee wrote:
> > > >> From: Yangtao Li
> > > >>
> > > >> The sunxi gpio binding defines a few custom cells for its gpio
> > > >> specifier.
> > > >> Provide bank name for those.
> > > >>
> > > >> Signed-off-by: Yangtao Li
> > > >
> > > > Thanks for working on this, I wanted to do it at some point but it kept
> > > > getting pushed further into my todo list.
> > > >
> > > >> ---
> > > >> include/dt-bindings/gpio/sunxi-gpio.h | 29 +++
> > > >> 1 file changed, 29 insertions(+)
> > > >> create mode 100644 include/dt-bindings/gpio/sunxi-gpio.h
> > > >>
> > > >> diff --git a/include/dt-bindings/gpio/sunxi-gpio.h
> > > >> b/include/dt-bindings/gpio/sunxi-gpio.h
> > > >> new file mode 100644
> > > >> index ..c692b4360da6
> > > >> --- /dev/null
> > > >> +++ b/include/dt-bindings/gpio/sunxi-gpio.h
> > > >
> > > > So generally we've been using the compatible name as the file name. You
> > > > should follow that convention too, and since it was added with the A10,
> > > > using the A10 compatible.
> > > >
> > > >> @@ -0,0 +1,29 @@
> > > >> +/* SPDX-License-Identifier: GPL-2.0 */
> > > >> +/*
> > > >> + * GPIO definitions for Allwinner SoCs
> > > >> + *
> > > >> + * Copyright (C) 2020 Yangtao Li
> > > >> + */
> > > >> +
> > > >> +#ifndef _DT_BINDINGS_SUNXI_GPIO_H
> > > >> +#define _DT_BINDINGS_SUNXI_GPIO_H
> > > >> +
> > > >> +#include
> > > >> +
> > > >> +/* pio */
> > > >> +#define PA0
> > > >> +#define PB1
> > > >> +#define PC2
> > > >> +#define PD3
> > > >> +#define PE4
> > > >> +#define PF5
> > > >> +#define PG6
> > > >> +#define PH7
> > > >> +#define PI8
> > > >> +
> > > >> +/* r-pio */
> > > >> +#define PL0
> > > >> +#define PM1
> > > >> +#define PN2
> > > >> +
> > > >> +#endif /* _DT_BINDINGS_SUNXI_GPIO_H */
> > > >
> > > > Maybe we can go one step further and use a macro to have something like
> > > > PIN(A, 12) ?
> > >
> > > Since we have separate cells for the bank and pin, I don't think it would
> > > be
> > > appropriate to have a single macro generating both.
> >
> > Yeah, but it's "just" an encoding issue though, it's not a major concern
> > if it makes our life easier.
> >
> > > And I'm not sure what the benefit of the macro would be, if all it
> > > does is forward its arguments. Are you concerned that P[A-M] could
> > > conflict with something else in the device tree?
> >
> > There's indeed a bunch of names that are fairly generic and could be
> > conflicting with others (PD for power domain is the first one that comes
> > to my mind). Using a prefix would make the GPIO descriptors pretty long,
> > so it wasn't ideal either. A macro makes it readable without increasing
> > too much the risks of conflicts
>
> I tried to use macros, but failed.
>
> I have a look at some other GPIO macros, which have a prefix in front of them.
> Maybe we can do the same? It's all numbers. It's not intuitive.
This works
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-olinuxino.dts
b/arch/arm64/boot/dts/allwinner/sun50i-a64-olinuxino.dts
index f3f8e177ab61..3a66d1102a78 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-olinuxino.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-olinuxino.dts
@@ -8,6 +8,9 @@
#include
+#define SUNXI_PE 4
+#define SUNXI_PIN(bank, pin)SUNXI_##bank pin
+
/ {
model = "Olimex A64-Olinuxino";
compatible = "olimex,a64-olinuxino", "allwinner,sun50i-a64";
@@ -37,7 +40,7 @@ leds {
led-0 {
label = "a64-olinuxino:red:user";
- gpios = <&pio 4 17 GPIO_ACTIVE_HIGH>; /* PE17 */
+ gpios = <&pio SUNXI_PIN(PE, 17) GPIO_ACTIVE_HIGH>;
};
};
Maxime
signature.asc
Description: PGP signature
arch/sh/mm/cache-sh2.c:65:15: sparse: sparse: incorrect type in argument 1 (different base types)
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 407ab579637ced6dc32cfb2295afb7259cca4b22
commit: e5fc436f06eef54ef512ea55a9db8eb9f2e76959 sparse: use static inline for
__chk_{user,io}_ptr()
date: 2 months ago
config: sh-randconfig-s032-20201109 (attached as .config)
compiler: sh4-linux-gcc (GCC) 9.3.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# apt-get install sparse
# sparse version: v0.6.3-76-gf680124b-dirty
#
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e5fc436f06eef54ef512ea55a9db8eb9f2e76959
git remote add linus
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout e5fc436f06eef54ef512ea55a9db8eb9f2e76959
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1
CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=sh
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
"sparse warnings: (new ones prefixed by >>)"
arch/sh/mm/cache-sh2.c:30:47: sparse: sparse: incorrect type in argument 1
(different base types) @@ expected void const volatile [noderef] __iomem
*ptr @@ got unsigned long @@
arch/sh/mm/cache-sh2.c:30:47: sparse: expected void const volatile
[noderef] __iomem *ptr
arch/sh/mm/cache-sh2.c:30:47: sparse: got unsigned long
arch/sh/mm/cache-sh2.c:33:33: sparse: sparse: incorrect type in argument 1
(different base types) @@ expected void const volatile [noderef] __iomem
*ptr @@ got unsigned long @@
arch/sh/mm/cache-sh2.c:33:33: sparse: expected void const volatile
[noderef] __iomem *ptr
arch/sh/mm/cache-sh2.c:33:33: sparse: got unsigned long
arch/sh/mm/cache-sh2.c:49:17: sparse: sparse: incorrect type in argument 1
(different base types) @@ expected void const volatile [noderef] __iomem
*ptr @@ got unsigned long @@
arch/sh/mm/cache-sh2.c:49:17: sparse: expected void const volatile
[noderef] __iomem *ptr
arch/sh/mm/cache-sh2.c:49:17: sparse: got unsigned long
>> arch/sh/mm/cache-sh2.c:65:15: sparse: sparse: incorrect type in argument 1
>> (different base types) @@ expected void const volatile [noderef] __iomem
>> *ptr @@ got unsigned int @@
arch/sh/mm/cache-sh2.c:65:15: sparse: expected void const volatile
[noderef] __iomem *ptr
arch/sh/mm/cache-sh2.c:65:15: sparse: got unsigned int
arch/sh/mm/cache-sh2.c:67:9: sparse: sparse: incorrect type in argument 1
(different base types) @@ expected void const volatile [noderef] __iomem
*ptr @@ got unsigned int @@
arch/sh/mm/cache-sh2.c:67:9: sparse: expected void const volatile
[noderef] __iomem *ptr
arch/sh/mm/cache-sh2.c:67:9: sparse: got unsigned int
--
drivers/firewire/core-cdev.c:1088:21: sparse: sparse: incorrect type in
initializer (different address spaces) @@ expected unsigned int const
*__gu_addr @@ got unsigned int [noderef] __user * @@
drivers/firewire/core-cdev.c:1088:21: sparse: expected unsigned int
const *__gu_addr
drivers/firewire/core-cdev.c:1088:21: sparse: got unsigned int [noderef]
__user *
>> drivers/firewire/core-cdev.c:1088:21: sparse: sparse: incorrect type in
>> argument 1 (different address spaces) @@ expected void const volatile
>> [noderef] __user *ptr @@ got unsigned int const *__gu_addr @@
>> drivers/firewire/core-cdev.c:1088:21: sparse: expected void const
>> volatile [noderef] __user *ptr
drivers/firewire/core-cdev.c:1088:21: sparse: got unsigned int const
*__gu_addr
--
drivers/md/md.c:7693:21: sparse: sparse: incorrect type in initializer
(different address spaces) @@ expected int const *__gu_addr @@ got int
[noderef] __user * @@
drivers/md/md.c:7693:21: sparse: expected int const *__gu_addr
drivers/md/md.c:7693:21: sparse: got int [noderef] __user *
>> drivers/md/md.c:7693:21: sparse: sparse: incorrect type in argument 1
>> (different address spaces) @@ expected void const volatile [noderef]
>> __user *ptr @@ got int const *__gu_addr @@
>> drivers/md/md.c:7693:21: sparse: expected void const volatile [noderef]
>> __user *ptr
drivers/md/md.c:7693:21: sparse: got int const *__gu_addr
--
>> drivers/spi/spi-lp8841-rtc.c:112:17: sparse: sparse: incorrect type in
>> argument 1 (different address spaces) @@ expected void const volatile
>> [noderef] __iomem *ptr @@ got void *iomem @@
>> drivers/spi/spi-lp8841-rtc.c:112:17: sparse: expected void const
>> volatile [noderef] __iomem *ptr
drivers/spi/spi-lp8841-rtc.c:112:17: sparse: got void *iomem
drivers/spi/spi-lp8841-rtc.c:121:17: sparse: sparse: incorrect type in
argument 1 (different address spaces) @@ expect
Re: [PATCH] cpufreq: stats: Switch to ktime and msec instead of jiffies and usertime
On 11/10/20 11:07 AM, Viresh Kumar wrote:
The cpufreq and thermal core, both provide sysfs statistics to help
userspace learn about the behavior of frequencies and cooling states.
This is how they look:
/sys/devices/system/cpu/cpufreq/policy0/stats/time_in_state:208000 11
/sys/devices/system/cpu/cpufreq/policy0/stats/time_in_state:432000 147
/sys/devices/system/cpu/cpufreq/policy0/stats/time_in_state:729000 1600
/sys/devices/system/cpu/cpufreq/policy0/stats/time_in_state:96 879
/sys/devices/system/cpu/cpufreq/policy0/stats/time_in_state:120 399
/sys/class/thermal/cooling_device0/stats/time_in_state_ms:state0 4097
/sys/class/thermal/cooling_device0/stats/time_in_state_ms:state1 8932
/sys/class/thermal/cooling_device0/stats/time_in_state_ms:state2 15868
/sys/class/thermal/cooling_device0/stats/time_in_state_ms:state3 1384
/sys/class/thermal/cooling_device0/stats/time_in_state_ms:state4 103
Here, state0 of thermal corresponds to the highest frequency of the CPU,
i.e. 120 and state4 to the lowest one.
While both of these try to show similar kind of data (which can still be
very much different from each other), the values looked different (by a
factor of 10, i.e. thermal's time_in_state is almost 10 times that of
cpufreq time_in_state).
This comes from the fact that cpufreq core displays the time in usertime
units (10 ms).
It would be better if both the frameworks displayed times in the same
unit as the users may need to correlate between them and different
scales just make it awkward. And the choice of thermal core for that
(msec) seems to be a better choice as it is easier to read.
The thermal core also does the stats calculations using ktime, which is
much more accurate as compared to jiffies used by cpufreq core.
This patch updates the cpufreq core to use ktime for the internal
calculations and changes the units of time_in_state to msec.
The results look like this after this commit:
/sys/devices/system/cpu/cpufreq/policy0/stats/time_in_state:208000 13
/sys/devices/system/cpu/cpufreq/policy0/stats/time_in_state:432000 790
/sys/devices/system/cpu/cpufreq/policy0/stats/time_in_state:729000 12492
/sys/devices/system/cpu/cpufreq/policy0/stats/time_in_state:96 13259
/sys/devices/system/cpu/cpufreq/policy0/stats/time_in_state:120 3830
/sys/class/thermal/cooling_device0/stats/time_in_state_ms:state0 3888
/sys/class/thermal/cooling_device0/stats/time_in_state_ms:state1 13432
/sys/class/thermal/cooling_device0/stats/time_in_state_ms:state2 12336
/sys/class/thermal/cooling_device0/stats/time_in_state_ms:state3 740
/sys/class/thermal/cooling_device0/stats/time_in_state_ms:state4 0
FWIW, tools/power/cpupower/ does consume the time_in_state values from
the sysfs files but it is independent of the unit of the time and didn't
require an update.
Signed-off-by: Viresh Kumar
---
Documentation/cpu-freq/cpufreq-stats.rst | 5 +--
drivers/cpufreq/cpufreq_stats.c | 47 +---
2 files changed, 28 insertions(+), 24 deletions(-)
diff --git a/Documentation/cpu-freq/cpufreq-stats.rst
b/Documentation/cpu-freq/cpufreq-stats.rst
index 9ad695b1c7db..9f94012a882f 100644
--- a/Documentation/cpu-freq/cpufreq-stats.rst
+++ b/Documentation/cpu-freq/cpufreq-stats.rst
@@ -64,9 +64,8 @@ need for a reboot.
This gives the amount of time spent in each of the frequencies supported by
this CPU. The cat output will have " " pair in each line,
which
-will mean this CPU spent usertime units of time at . Output
-will have one line for each of the supported frequencies. usertime units here
-is 10mS (similar to other time exported in /proc).
+will mean this CPU spent msec of time at . Output will have
+one line for each of the supported frequencies.
::
diff --git a/drivers/cpufreq/cpufreq_stats.c b/drivers/cpufreq/cpufreq_stats.c
index 6cd5c8ab5d49..e054ada291e7 100644
--- a/drivers/cpufreq/cpufreq_stats.c
+++ b/drivers/cpufreq/cpufreq_stats.c
@@ -14,35 +14,38 @@
struct cpufreq_stats {
unsigned int total_trans;
- unsigned long long last_time;
+ ktime_t last_time;
unsigned int max_state;
unsigned int state_num;
unsigned int last_index;
- u64 *time_in_state;
+ ktime_t *time_in_state;
unsigned int *freq_table;
unsigned int *trans_table;
/* Deferred reset */
unsigned int reset_pending;
- unsigned long long reset_time;
+ ktime_t reset_time;
};
-static void cpufreq_stats_update(struct cpufreq_stats *stats,
-unsigned long long time)
+static void cpufreq_stats_update(struct cpufreq_stats *stats, ktime_t time)
{
- unsigned long long cur_time = get_jiffies_64();
+ ktime_t cur_time = ktime_get(), delta;
- stats->time_in_state[stats->last_index] += cur_time - time;
+ delta = ktime_sub(cur_time, time);
+ stats->time_in_state[stats->last_index] =
+ ktime_add(stats->time_in_state[stats->last_inde
5.10 regression, many XHCI swiotlb buffer is full / DMAR: Device bounce map failed errors on thunderbolt connected XHCI controller
Hi All, Not sure if this is a XHCI driver problem at all, but I needed to start somewhere with reporting this so I went with: scripts/get_maintainer.pl -f drivers/usb/host/xhci-pci.c And added a Cc: linux-...@vger.kernel.org as bonus. I'm seeing the following errors and very slow network performance with the USB NIC in a Lenovo Thunderbolt gen 2 dock. Note that the USB NIC is connected to the XHCI controller which is embedded inside the dock and is connected over thunderbolt! So the errors are: [ 1148.744205] swiotlb_tbl_map_single: 6 callbacks suppressed [ 1148.744210] xhci_hcd :0a:00.0: swiotlb buffer is full (sz: 8192 bytes), total 32768 (slots), used 16 (slots) [ 1148.744218] xhci_hcd :0a:00.0: DMAR: Device bounce map: 16ea@1411c dir 1 --- failed [ 1148.744226] r8152 4-2.1.2:1.0 ens1u2u1u2: failed tx_urb -11 [ 1148.744368] xhci_hcd :0a:00.0: swiotlb buffer is full (sz: 8192 bytes), total 32768 (slots), used 16 (slots) [ 1148.744375] xhci_hcd :0a:00.0: DMAR: Device bounce map: 16ea@10aabc000 dir 1 --- failed [ 1148.744381] r8152 4-2.1.2:1.0 ens1u2u1u2: failed tx_urb -11 [ 1148.745141] xhci_hcd :0a:00.0: swiotlb buffer is full (sz: 8192 bytes), total 32768 (slots), used 16 (slots) [ 1148.745148] xhci_hcd :0a:00.0: DMAR: Device bounce map: 118e@1411c dir 1 --- failed [ 1148.745155] r8152 4-2.1.2:1.0 ens1u2u1u2: failed tx_urb -11 [ 1148.951282] xhci_hcd :0a:00.0: swiotlb buffer is full (sz: 8192 bytes), total 32768 (slots), used 16 (slots) [ 1148.951388] xhci_hcd :0a:00.0: DMAR: Device bounce map: 118e@140988000 dir 1 --- failed [ 1148.951420] r8152 4-2.1.2:1.0 ens1u2u1u2: failed tx_urb -11 [ 1151.013342] xhci_hcd :0a:00.0: swiotlb buffer is full (sz: 8192 bytes), total 32768 (slots), used 16 (slots) [ 1151.013357] xhci_hcd :0a:00.0: DMAR: Device bounce map: 1d2a@1411c dir 1 --- failed [ 1151.013373] r8152 4-2.1.2:1.0 ens1u2u1u2: failed tx_urb -11 [ 1151.018660] xhci_hcd :0a:00.0: swiotlb buffer is full (sz: 8192 bytes), total 32768 (slots), used 18 (slots) [ 1151.018696] xhci_hcd :0a:00.0: DMAR: Device bounce map: 11da@1411c dir 1 --- failed [ 1151.018711] r8152 4-2.1.2:1.0 ens1u2u1u2: failed tx_urb -11 [ 1151.223022] xhci_hcd :0a:00.0: swiotlb buffer is full (sz: 8192 bytes), total 32768 (slots), used 16 (slots) [ 1151.223102] xhci_hcd :0a:00.0: DMAR: Device bounce map: 11da@10aabc000 dir 1 --- failed [ 1151.223133] r8152 4-2.1.2:1.0 ens1u2u1u2: failed tx_urb -11 [ 1151.228810] xhci_hcd :0a:00.0: swiotlb buffer is full (sz: 8192 bytes), total 32768 (slots), used 16 (slots) [ 1151.228870] xhci_hcd :0a:00.0: DMAR: Device bounce map: 11da@10aabc000 dir 1 --- failed [ 1151.228898] r8152 4-2.1.2:1.0 ens1u2u1u2: failed tx_urb -11 [ 1151.234792] xhci_hcd :0a:00.0: swiotlb buffer is full (sz: 8192 bytes), total 32768 (slots), used 16 (slots) [ 1151.234852] xhci_hcd :0a:00.0: DMAR: Device bounce map: 11da@10aabc000 dir 1 --- failed [ 1151.234882] r8152 4-2.1.2:1.0 ens1u2u1u2: failed tx_urb -11 etc. This happens as soon as I generate any serious amount of outgoing network traffic. E.g. rsyncing files to another machine. Regards, Hans
Re: drivers/mtd/maps/physmap-bt1-rom.c:78:18: sparse: sparse: cast removes address space '__iomem' of expression
Hello Miquel,
A situation noted by the warning below won't cause any problem because
the casting is done to a non-dereferenced variable. It is utilized
as a pointer bias later in that function. Shall we just ignore the
warning or still fix it somehow?
-Sergey
On Mon, Nov 02, 2020 at 12:42:57PM +0800, kernel test robot wrote:
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> master
> head: 3cea11cd5e3b00d91caf0b4730194039b45c5891
> commit: b3e79e7682e075326df8041b826b03453acacd0a mtd: physmap: Add Baikal-T1
> physically mapped ROM support
> date: 4 weeks ago
> config: sparc64-randconfig-s032-20201031 (attached as .config)
> compiler: sparc64-linux-gcc (GCC) 9.3.0
> reproduce:
> wget
> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
> ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # apt-get install sparse
> # sparse version: v0.6.3-76-gf680124b-dirty
> #
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b3e79e7682e075326df8041b826b03453acacd0a
> git remote add linus
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> git fetch --no-tags linus master
> git checkout b3e79e7682e075326df8041b826b03453acacd0a
> # save the attached .config to linux build tree
> COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1
> CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=sparc64
>
> If you fix the issue, kindly add following tag as appropriate
> Reported-by: kernel test robot
>
>
> "sparse warnings: (new ones prefixed by >>)"
> >> drivers/mtd/maps/physmap-bt1-rom.c:78:18: sparse: sparse: cast removes
> >> address space '__iomem' of expression
>
> vim +/__iomem +78 drivers/mtd/maps/physmap-bt1-rom.c
>
> 57
> 58static void __xipram bt1_rom_map_copy_from(struct map_info *map,
> 59 void *to, unsigned
> long from,
> 60 ssize_t len)
> 61{
> 62void __iomem *src = map->virt + from;
> 63ssize_t shift, chunk;
> 64u32 data;
> 65
> 66if (len <= 0 || from >= map->size)
> 67return;
> 68
> 69/* Make sure we don't go over the map limit. */
> 70len = min_t(ssize_t, map->size - from, len);
> 71
> 72/*
> 73 * Since requested data size can be pretty big we have
> to implement
> 74 * the copy procedure as optimal as possible. That's
> why it's split
> 75 * up into the next three stages: unaligned head,
> aligned body,
> 76 * unaligned tail.
> 77 */
> > 78shift = (ssize_t)src & 0x3;
> 79if (shift) {
> 80chunk = min_t(ssize_t, 4 - shift, len);
> 81data = readl_relaxed(src - shift);
> 82memcpy(to, &data + shift, chunk);
> 83src += chunk;
> 84to += chunk;
> 85len -= chunk;
> 86}
> 87
> 88while (len >= 4) {
> 89data = readl_relaxed(src);
> 90memcpy(to, &data, 4);
> 91src += 4;
> 92to += 4;
> 93len -= 4;
> 94}
> 95
> 96if (len) {
> 97data = readl_relaxed(src);
> 98memcpy(to, &data, len);
> 99}
>100}
>101
>
> ---
> 0-DAY CI Kernel Test Service, Intel Corporation
> https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
Re: [PATCH v2 03/10] usb: cdns3: Moves reusable code to separate module
On Tue, Nov 10, 2020 at 11:21:22AM +, Peter Chen wrote: > On 20-11-10 09:20:54, Pawel Laszczak wrote: > > Hi, > > > > >> > > >> int cdns3_hw_role_switch(struct cdns3 *cdns); > > >> -int cdns3_init(struct cdns3 *cdns); > > >> -int cdns3_remove(struct cdns3 *cdns); > > >> +extern int cdns3_init(struct cdns3 *cdns); > > >> +extern int cdns3_remove(struct cdns3 *cdns); > > > > > >Why add "extern" here and below? > > > > > > > These functions are the API between cdnsp and cdns3 modules. > > It's looks like a common approach in kernel. > > Many or even most of API function in kernel has "extern". > > > > Even you have not written "extern" keyword, the "extern" is > added implicitly by compiler. Usually, we use "extern" for variable > or the function is defined at assembly. You could see some > "extern" keyword use cases at include/linux/device.h. We are moving away from using this keyword for functions now, if at all possible please. Only use it for variables, I think checkpatch now catches it as well. thanks, greg k-h
[PATCH 0/2] genirq: Move prio assignment into the newly created thread
Mike reported [0] a lockdep splat triggered by the nouveau driver together
with enabled threaded interrupts.
I can't easily tell if moving / changing locking within nouveau does not
break anything and does not create the same lockchain in another path.
Mike did confirm that the lockdep splat can be avoided by by moving
`request_irq()' out of the picture [1]. He also tested the two patches
which are scattered in the thread.
Mike is betting on commit
710da3c8ea7df ("sched/core: Prevent race condition between cpuset and
__sched_setscheduler()")
as the source change that introduce that problem assuming that locking
within the nouveau remained unchanged. He did confirm that this splat
exists also in a v5.4 stable kernel [2] which is where the change was
introduced.
[0]
https://lkml.kernel.org/r/a23a826af7c108ea5651e73b8fbae5e653f16e86.ca...@gmx.de
[1]
https://lkml.kernel.org/r/431e81699f2310eabfe5af0a3de400ab99d9323b.ca...@gmx.de
[2]
https://lkml.kernel.org/r/f7e43b369c7d168c2ff04bfd91dfdf3afd0da12c.ca...@gmx.de
Sebastian
[PATCH 1/2] kthread: Move prio/affinite change into the newly created thread
With enabled threaded interrupts the nouveau driver reported the
following:
| Chain exists of:
| &mm->mmap_lock#2 --> &device->mutex --> &cpuset_rwsem
|
| Possible unsafe locking scenario:
|
|CPU0CPU1
|
| lock(&cpuset_rwsem);
|lock(&device->mutex);
|lock(&cpuset_rwsem);
| lock(&mm->mmap_lock#2);
The device->mutex is nvkm_device::mutex.
Unblocking the lockchain at `cpuset_rwsem' is probably the easiest thing
to do.
Move the priority reset to the start of the newly created thread.
Fixes: 710da3c8ea7df ("sched/core: Prevent race condition between cpuset and
__sched_setscheduler()")
Reported-by: Mike Galbraith
Signed-off-by: Sebastian Andrzej Siewior
Link:
https://lkml.kernel.org/r/a23a826af7c108ea5651e73b8fbae5e653f16e86.ca...@gmx.de
---
kernel/kthread.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/kernel/kthread.c b/kernel/kthread.c
index 933a625621b8d..4a31127c6efbf 100644
--- a/kernel/kthread.c
+++ b/kernel/kthread.c
@@ -243,6 +243,7 @@ EXPORT_SYMBOL_GPL(kthread_parkme);
static int kthread(void *_create)
{
+ static const struct sched_param param = { .sched_priority = 0 };
/* Copy data: it's on kthread's stack */
struct kthread_create_info *create = _create;
int (*threadfn)(void *data) = create->threadfn;
@@ -273,6 +274,13 @@ static int kthread(void *_create)
init_completion(&self->parked);
current->vfork_done = &self->exited;
+ /*
+* The new thread inherited kthreadd's priority and CPU mask. Reset
+* back to default in case they have been changed.
+*/
+ sched_setscheduler_nocheck(current, SCHED_NORMAL, ¶m);
+ set_cpus_allowed_ptr(current, housekeeping_cpumask(HK_FLAG_KTHREAD));
+
/* OK, tell user we're spawned, wait for stop or wakeup */
__set_current_state(TASK_UNINTERRUPTIBLE);
create->result = current;
@@ -370,7 +378,6 @@ struct task_struct *__kthread_create_on_node(int
(*threadfn)(void *data),
}
task = create->result;
if (!IS_ERR(task)) {
- static const struct sched_param param = { .sched_priority = 0 };
char name[TASK_COMM_LEN];
/*
@@ -379,13 +386,6 @@ struct task_struct *__kthread_create_on_node(int
(*threadfn)(void *data),
*/
vsnprintf(name, sizeof(name), namefmt, args);
set_task_comm(task, name);
- /*
-* root may have changed our (kthreadd's) priority or CPU mask.
-* The kernel thread should not inherit these properties.
-*/
- sched_setscheduler_nocheck(task, SCHED_NORMAL, ¶m);
- set_cpus_allowed_ptr(task,
-housekeeping_cpumask(HK_FLAG_KTHREAD));
}
kfree(create);
return task;
--
2.29.2
[PATCH 2/2] genirq: Move prio assignment into the newly created thread
From: Thomas Gleixner
With enabled threaded interrupts the nouveau driver reported the
following:
| Chain exists of:
| &mm->mmap_lock#2 --> &device->mutex --> &cpuset_rwsem
|
| Possible unsafe locking scenario:
|
|CPU0CPU1
|
| lock(&cpuset_rwsem);
|lock(&device->mutex);
|lock(&cpuset_rwsem);
| lock(&mm->mmap_lock#2);
The device->mutex is nvkm_device::mutex.
Unblocking the lockchain at `cpuset_rwsem' is probably the easiest thing
to do.
Move the priority assignment to the start of the newly created thread.
Fixes: 710da3c8ea7df ("sched/core: Prevent race condition between cpuset and
__sched_setscheduler()")
Reported-by: Mike Galbraith
Signed-off-by: Thomas Gleixner
[bigeasy: Patch description]
Signed-off-by: Sebastian Andrzej Siewior
Link:
https://lkml.kernel.org/r/a23a826af7c108ea5651e73b8fbae5e653f16e86.ca...@gmx.de
---
kernel/irq/manage.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c
index c460e0496006e..079688d122a70 100644
--- a/kernel/irq/manage.c
+++ b/kernel/irq/manage.c
@@ -1155,6 +1155,8 @@ static int irq_thread(void *data)
irqreturn_t (*handler_fn)(struct irq_desc *desc,
struct irqaction *action);
+ sched_set_fifo(current);
+
if (force_irqthreads && test_bit(IRQTF_FORCED_THREAD,
&action->thread_flags))
handler_fn = irq_forced_thread_fn;
@@ -1320,8 +1322,6 @@ setup_irq_thread(struct irqaction *new, unsigned int irq,
bool secondary)
if (IS_ERR(t))
return PTR_ERR(t);
- sched_set_fifo(t);
-
/*
* We keep the reference to the task struct even if
* the thread dies to avoid that the interrupt code
--
2.29.2
Re: [PATCH 10/24] x86/resctrl: Move the schema names into struct resctrl_schema
Hi James,
On Fri, Oct 30, 2020 at 04:11:06PM +, James Morse wrote:
> Move the names used for the schemata file out of the resource and
> into struct resctrl_schema. This allows one resource to have two
> different names, based on the other schema properties.
>
> This patch copies the names, eventually resctrl will generate them.
>
> Remove the arch code's max_name_width, this is now resctrl's
> problem.
>
> Signed-off-by: James Morse
> ---
> arch/x86/kernel/cpu/resctrl/core.c| 9 ++---
> arch/x86/kernel/cpu/resctrl/ctrlmondata.c | 10 +++---
> arch/x86/kernel/cpu/resctrl/internal.h| 2 +-
> arch/x86/kernel/cpu/resctrl/rdtgroup.c| 17 -
> include/linux/resctrl.h | 7 +++
> 5 files changed, 25 insertions(+), 20 deletions(-)
...
> diff --git a/arch/x86/kernel/cpu/resctrl/internal.h
> b/arch/x86/kernel/cpu/resctrl/internal.h
> index 27671a654f8b..5294ae0c3ed9 100644
> --- a/arch/x86/kernel/cpu/resctrl/internal.h
> +++ b/arch/x86/kernel/cpu/resctrl/internal.h
> @@ -248,7 +248,7 @@ struct rdtgroup {
> /* List of all resource groups */
> extern struct list_head rdt_all_groups;
>
> -extern int max_name_width, max_data_width;
> +extern int max_data_width;
>
> int __init rdtgroup_init(void);
> void __exit rdtgroup_exit(void);
> diff --git a/arch/x86/kernel/cpu/resctrl/rdtgroup.c
> b/arch/x86/kernel/cpu/resctrl/rdtgroup.c
> index 311a3890bc53..48f4d6783647 100644
> --- a/arch/x86/kernel/cpu/resctrl/rdtgroup.c
> +++ b/arch/x86/kernel/cpu/resctrl/rdtgroup.c
> @@ -1440,8 +1440,8 @@ static int rdtgroup_size_show(struct kernfs_open_file
> *of,
> rdt_last_cmd_puts("Cache domain offline\n");
> ret = -ENODEV;
> } else {
> - seq_printf(s, "%*s:", max_name_width,
> -rdtgrp->plr->s->res->name);
> + seq_printf(s, "%*s:", RESCTRL_NAME_LEN,
> +rdtgrp->plr->s->name);
> size = rdtgroup_cbm_to_size(rdtgrp->plr->s->res,
> rdtgrp->plr->d,
> rdtgrp->plr->cbm);
> @@ -1454,7 +1454,7 @@ static int rdtgroup_size_show(struct kernfs_open_file
> *of,
> r = schema->res;
>
> sep = false;
> - seq_printf(s, "%*s:", max_name_width, r->name);
> + seq_printf(s, "%*s:", RESCTRL_NAME_LEN, schema->name);
> list_for_each_entry(d, &r->domains, list) {
> hw_dom = resctrl_to_arch_dom(d);
> if (sep)
> @@ -1827,7 +1827,7 @@ static int rdtgroup_create_info_dir(struct kernfs_node
> *parent_kn)
> list_for_each_entry(s, &resctrl_all_schema, list) {
> r = s->res;
> fflags = r->fflags | RF_CTRL_INFO;
> - ret = rdtgroup_mkdir_info_resdir(s, r->name, fflags);
> + ret = rdtgroup_mkdir_info_resdir(s, s->name, fflags);
> if (ret)
> goto out_destroy;
> }
> @@ -2140,6 +2140,7 @@ static int create_schemata_list(void)
> {
> struct resctrl_schema *s;
> struct rdt_resource *r;
> + int ret;
>
> for_each_alloc_enabled_rdt_resource(r) {
> s = kzalloc(sizeof(*s), GFP_KERNEL);
> @@ -2150,6 +2151,12 @@ static int create_schemata_list(void)
> s->num_closid = resctrl_arch_get_num_closid(r);
> s->conf_type = resctrl_to_arch_res(r)->conf_type;
>
> + ret = snprintf(s->name, sizeof(s->name), r->name);
> + if (ret >= sizeof(s->name)) {
> + kfree(s);
> + return -EINVAL;
> + }
> +
How about:
+ ret = strscpy(s->name, r->name, sizeof(s->name));
+ if (ret < 0)) {
+ kfree(s);
+ return -EINVAL;
+ }
So that there isn't a non-constant format specifier that'll trip
Coverity+friends up later?
Thanks,
Jamie
RE: [PATCH v3 22/26] coresight: etm4x: Add necessary synchronization for sysreg access
On 11/10/20 10:11 AM, Suzuki K Poulose wrote: > On 11/9/20 6:32 PM, Mathieu Poirier wrote: >> On Wed, Oct 28, 2020 at 10:09:41PM +, Suzuki K Poulose wrote: >>> As per the specification any update to the TRCPRGCTLR must be >>> synchronized by a context synchronization event (in our case an >>> explicist ISB) before the TRCSTATR is checked. >>> >>> Cc: Mike Leach >>> Cc: Mathieu Poirier >>> Signed-off-by: Suzuki K Poulose >>> --- >>> drivers/hwtracing/coresight/coresight-etm4x-core.c | 13 + >>> 1 file changed, 13 insertions(+) >>> >>> diff --git a/drivers/hwtracing/coresight/coresight-etm4x-core.c >>> b/drivers/hwtracing/coresight/coresight-etm4x-core.c >>> index e36bc1c722c7..4bc2f15b6332 100644 >>> --- a/drivers/hwtracing/coresight/coresight-etm4x-core.c >>> +++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c >>> @@ -178,6 +178,15 @@ static int etm4_enable_hw(struct etmv4_drvdata >>> *drvdata) >>> /* Disable the trace unit before programming trace registers */ >>> etm4x_relaxed_write32(csa, 0, TRCPRGCTLR); >>> >>> + /* >>> +* If we use system instructions, we need to synchronize the >>> +* write to the TRCPRGCTLR, before accessing the TRCSTATR. >>> +* See ARM IHI0064F, section >>> +* "4.3.7 Synchronization of register updates" >>> +*/ >>> + if (!csa->io_mem) >>> + isb(); >>> + >> >> When I first read the documentation on system instruction section >> 4.3.7 really got me thinking... >> >> At the very top, right after the title "Synchronization of register >> updates" one can read "Software running on the PE...". Later in the >> text, when specifying the synchronisation rules, the term "trace >> analyzer" is used. _Typically_ a trace analyzer is an external box. >> > >Very good point. The trace analyzer could still use the system register to >program the ETM and causing a context synchronization event is tricky from >within the trace analyzer. And I agree that there is a bit of confusion >around the synchronization from a self-hosted point of view. >I believe this is true for the self-hosted case too and should be clarified >in the TRM. > The ETM architecture uses "trace analyzer" to mean self-hosted software and an external debugger. It's a useful term that generically covers "the thing that's in charge of tracing" and "the thing that's capturing and/or decoding the trace", regardless of whether either of these are external or self-hosted (or even a mixture!). So in 4.3.7, yes this does mean that context synchronization events are needed to synchronize register updates when using system instructions to program the trace unit. I'll take a look at what we can improve here :-) Cheers, John. >> Arm documentation is precise and usually doesn't overlook that kind of >> detail. >> The question is to understand if a context synchronisation event is >> also needed when programming is done on the PE. If so I think the >> documentation should be amended. >> >> In that case: >> >> Reviewed-by: Mathieu Poirier >> > >Thanks >Suzuki >___ >CoreSight mailing list >coresi...@lists.linaro.org >https://lists.linaro.org/mailman/listinfo/coresight
Re: [PATCH] net/xdp: remove unused macro REG_STATE_NEW
On Mon, 09 Nov 2020 13:44:48 -0800 John Fastabend wrote: > Alex Shi wrote: > > > > > > 在 2020/11/7 上午12:13, Jesper Dangaard Brouer 写道: > > > Hmm... REG_STATE_NEW is zero, so it is implicitly set via memset zero. > > > But it is true that it is technically not directly used or referenced. > > > > > > It is mentioned in a comment, so please send V2 with this additional > > > change: > > > > Hi Jesper, > > > > Thanks a lot for comments. here is the v2: > > > > From 2908d25bf2e1c90ad71a83ba056743f45da283e8 Mon Sep 17 00:00:00 2001 > > From: Alex Shi > > Date: Fri, 6 Nov 2020 13:41:58 +0800 > > Subject: [PATCH v2] net/xdp: remove unused macro REG_STATE_NEW > > > > To tame gcc warning on it: > > net/core/xdp.c:20:0: warning: macro "REG_STATE_NEW" is not used > > [-Wunused-macros] > > And change related comments as Jesper Dangaard Brouer suggested. > > > > Signed-off-by: Alex Shi > > --- > > > net/core/xdp.c | 3 +-- > > 1 file changed, 1 insertion(+), 2 deletions(-) > > > > diff --git a/net/core/xdp.c b/net/core/xdp.c > > index 48aba933a5a8..0df5ee5682d9 100644 > > --- a/net/core/xdp.c > > +++ b/net/core/xdp.c > > @@ -19,7 +19,6 @@ > > #include > > #include > > > > -#define REG_STATE_NEW 0x0 > > #define REG_STATE_REGISTERED 0x1 > > #define REG_STATE_UNREGISTERED 0x2 > > #define REG_STATE_UNUSED 0x3 > > I think having the define there makes it more readable and clear what > the zero state is. But if we run with unused-macros I guess its even > uglier to try and mark it with unused attribute. I agree having the define there makes it more readable and clear what the zero state is. We can also add code that replace the comment, that check/use these defines. It is slow-path code, so it doesn't hurt to add this extra code. Generally I find it strange to "fix" these kind of warnings, but also don't care that we do fix them if it helps someone else spot code where it actually matters. > Acked-by: John Fastabend > > > @@ -175,7 +174,7 @@ int xdp_rxq_info_reg(struct xdp_rxq_info *xdp_rxq, > > return -ENODEV; > > } > > > > - /* State either UNREGISTERED or NEW */ > > + /* State either UNREGISTERED or zero */ > > xdp_rxq_info_init(xdp_rxq); > > xdp_rxq->dev = dev; > > xdp_rxq->queue_index = queue_index; > > -- > > 1.8.3.1 > > > > -- Best regards, Jesper Dangaard Brouer MSc.CS, Principal Kernel Engineer at Red Hat LinkedIn: http://www.linkedin.com/in/brouer
RE: [PATCH v2 03/10] usb: cdns3: Moves reusable code to separate module
> >On Tue, Nov 10, 2020 at 11:21:22AM +, Peter Chen wrote: >> On 20-11-10 09:20:54, Pawel Laszczak wrote: >> > Hi, >> > >> > >> >> > >> int cdns3_hw_role_switch(struct cdns3 *cdns); >> > >> -int cdns3_init(struct cdns3 *cdns); >> > >> -int cdns3_remove(struct cdns3 *cdns); >> > >> +extern int cdns3_init(struct cdns3 *cdns); >> > >> +extern int cdns3_remove(struct cdns3 *cdns); >> > > >> > >Why add "extern" here and below? >> > > >> > >> > These functions are the API between cdnsp and cdns3 modules. >> > It's looks like a common approach in kernel. >> > Many or even most of API function in kernel has "extern". >> > >> >> Even you have not written "extern" keyword, the "extern" is >> added implicitly by compiler. Usually, we use "extern" for variable >> or the function is defined at assembly. You could see some >> "extern" keyword use cases at include/linux/device.h. > >We are moving away from using this keyword for functions now, if at all >possible please. Only use it for variables, I think checkpatch now >catches it as well. > Ok, I will remove all extern from driver. Removing it also will remove checkpatch.pl warmings. Thanks Pawel
Re: [PATCH 2/2] ASoC: Add ADAU1372 audio CODEC support
Hi Alexandre, I love your patch! Perhaps something to improve: [auto build test WARNING on asoc/for-next] [also build test WARNING on v5.10-rc3 next-20201110] [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/Alexandre-Belloni/dt-bindings-sound-adau1372-Add-bindings-documentation/20201105-041438 base: https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next config: x86_64-randconfig-a013-20201109 (attached as .config) compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project 09ec07827b1128504457a93dee80b2ceee1af600) 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 # install x86_64 cross compiling tool for clang build # apt-get install binutils-x86-64-linux-gnu # https://github.com/0day-ci/linux/commit/f483771e450f4bb74b8e585ab5d7fb63ba557b29 git remote add linux-review https://github.com/0day-ci/linux git fetch --no-tags linux-review Alexandre-Belloni/dt-bindings-sound-adau1372-Add-bindings-documentation/20201105-041438 git checkout f483771e450f4bb74b8e585ab5d7fb63ba557b29 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All warnings (new ones prefixed by >>): >> sound/soc/codecs/adau1372.c:161:29: warning: unused variable >> 'adau1372_bias_mic_enum' [-Wunused-const-variable] static SOC_ENUM_SINGLE_DECL(adau1372_bias_mic_enum, ^ 1 warning generated. vim +/adau1372_bias_mic_enum +161 sound/soc/codecs/adau1372.c 148 149 static SOC_ENUM_SINGLE_DECL(adau1372_bias_hp_enum, 150 ADAU1372_REG_BIAS_CTRL0, 6, adau1372_bias_text); 151 static SOC_ENUM_SINGLE_DECL(adau1372_bias_afe0_1_enum, 152 ADAU1372_REG_BIAS_CTRL0, 4, adau1372_bias_text); 153 static SOC_VALUE_ENUM_SINGLE_DECL(adau1372_bias_adc2_3_enum, 154 ADAU1372_REG_BIAS_CTRL0, 2, 0x3, adau1372_bias_adc_text, 155 adau1372_bias_adc_values); 156 static SOC_VALUE_ENUM_SINGLE_DECL(adau1372_bias_adc0_1_enum, 157 ADAU1372_REG_BIAS_CTRL0, 0, 0x3, adau1372_bias_adc_text, 158 adau1372_bias_adc_values); 159 static SOC_ENUM_SINGLE_DECL(adau1372_bias_afe2_3_enum, 160 ADAU1372_REG_BIAS_CTRL1, 4, adau1372_bias_text); > 161 static SOC_ENUM_SINGLE_DECL(adau1372_bias_mic_enum, 162 ADAU1372_REG_BIAS_CTRL1, 2, adau1372_bias_text); 163 static SOC_ENUM_SINGLE_DECL(adau1372_bias_dac_enum, 164 ADAU1372_REG_BIAS_CTRL1, 0, adau1372_bias_dac_text); 165 --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org .config.gz Description: application/gzip
[PATCH] bpf: Fix unsigned 'datasec_id' compared with zero in check_pseudo_btf_id
From: Kaixu Xia
The unsigned variable datasec_id is assigned a return value from the call
to check_pseudo_btf_id(), which may return negative error code.
Fixes coccicheck warning:
./kernel/bpf/verifier.c:9616:5-15: WARNING: Unsigned expression compared with
zero: datasec_id > 0
Reported-by: Tosk Robot
Signed-off-by: Kaixu Xia
---
kernel/bpf/verifier.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index 6200519582a6..e9d8d4309bb4 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -9572,7 +9572,7 @@ static int check_pseudo_btf_id(struct bpf_verifier_env
*env,
struct bpf_insn *insn,
struct bpf_insn_aux_data *aux)
{
- u32 datasec_id, type, id = insn->imm;
+ s32 datasec_id, type, id = insn->imm;
const struct btf_var_secinfo *vsi;
const struct btf_type *datasec;
const struct btf_type *t;
--
2.20.0
Re: [PATCH v2 2/2] mm: prevent gup_fast from racing with COW during fork
On Wed, Nov 04, 2020 at 04:17:11AM +0100, Ahmed S. Darwish wrote:
> On Tue, Nov 03, 2020 at 06:01:30PM -0800, John Hubbard wrote:
> > On 11/3/20 5:32 PM, Ahmed S. Darwish wrote:
> ...
> > > #define __read_seqcount_retry(s, start)
> > > \
> > > - __read_seqcount_t_retry(__seqcount_ptr(s), start)
> > > + __do___read_seqcount_retry(__seqcount_ptr(s), start)
> >
> ...
> > A nit: while various numbers of leading underscores are sometimes used,
> > it's a lot
> > less common to use, say, 3 consecutive underscores (as above) *within* the
> > name. And
> > I don't think you need it for uniqueness, at least from a quick look around
> > here.
> >
> ...
> > But again, either way, I think "do" is helping a *lot* here (as is getting
> > rid
> > of the _t_ idea).
>
> The three underscores are needed because there's a do_ version for
> read_seqcount_retry(), and another for __read_seqcount_retry().
>
> Similarly for {__,}read_seqcount_begin(). You want to be very careful
> with this, and never mistaknely mix the two, because it affects some VFS
> hot paths.
>
> Nonetheless, as you mentioned in the later (dropped) part of your
> message, I think do_ is better than __do_, so the final result will be:
>
> do___read_seqcount_retry()
> do_read_seqcount_retry()
> do_raw_write_seqcount_begin()
> do_raw_write_seqcount_end()
> do_write_seqcount_begin()
> ...
>
> and so on.
>
> I'll wait for some further feedback on the two patches (possibly from
> Linus or PeterZ), then send a mini patch series.
I'm Ok with that. The change I have issues with is:
-#define __seqcount_lock_preemptible(s) __seqprop(s, preemptible)
+#define __seqcount_associated_lock_exists_and_is_preemptible(s)
__seqprop(s, preemptible)
That's just _reay_ long.
Would something like the below make it easier to follow?
seqprop_preemptible() is 'obviously' related to __seqprop_preemptible()
without having to follow through the _Generic token pasting maze.
---
diff --git a/include/linux/seqlock.h b/include/linux/seqlock.h
index 8d8552474c64..576594add921 100644
--- a/include/linux/seqlock.h
+++ b/include/linux/seqlock.h
@@ -307,10 +307,10 @@ SEQCOUNT_LOCKNAME(ww_mutex, struct ww_mutex, true,
&s->lock->base, ww_mu
__seqprop_case((s), mutex, prop), \
__seqprop_case((s), ww_mutex, prop))
-#define __seqcount_ptr(s) __seqprop(s, ptr)
-#define __seqcount_sequence(s) __seqprop(s, sequence)
-#define __seqcount_lock_preemptible(s) __seqprop(s, preemptible)
-#define __seqcount_assert_lock_held(s) __seqprop(s, assert)
+#define seqprop_ptr(s) __seqprop(s, ptr)
+#define seqprop_sequence(s)__seqprop(s, sequence)
+#define seqprop_preemptible(s) __seqprop(s, preemptible)
+#define seqprop_assert(s) __seqprop(s, assert)
/**
* __read_seqcount_begin() - begin a seqcount_t read section w/o barrier
@@ -330,7 +330,7 @@ SEQCOUNT_LOCKNAME(ww_mutex, struct ww_mutex, true,
&s->lock->base, ww_mu
({ \
unsigned __seq; \
\
- while ((__seq = __seqcount_sequence(s)) & 1)\
+ while ((__seq = seqprop_sequence(s)) & 1) \
cpu_relax();\
\
kcsan_atomic_next(KCSAN_SEQLOCK_REGION_MAX);\
@@ -359,7 +359,7 @@ SEQCOUNT_LOCKNAME(ww_mutex, struct ww_mutex, true,
&s->lock->base, ww_mu
*/
#define read_seqcount_begin(s) \
({ \
- seqcount_lockdep_reader_access(__seqcount_ptr(s)); \
+ seqcount_lockdep_reader_access(seqprop_ptr(s)); \
raw_read_seqcount_begin(s); \
})
@@ -376,7 +376,7 @@ SEQCOUNT_LOCKNAME(ww_mutex, struct ww_mutex, true,
&s->lock->base, ww_mu
*/
#define raw_read_seqcount(s) \
({ \
- unsigned __seq = __seqcount_sequence(s);\
+ unsigned __seq = seqprop_sequence(s); \
\
smp_rmb(); \
kcsan_atomic_next(KCSAN_SEQLOCK_REGION_MAX);\
@@ -425,7 +425,7 @@ SEQCOUNT_LOCKNAME(ww_mutex, struct ww_mutex, true,
&s->lock->base, ww_mu
* Return: true if a read section retry is required, else false
*/
#define __read_seqcount_retry(s, start)
Re: [PATCH 03/24] perf: Add build id data in mmap2 event
Em Tue, Nov 10, 2020 at 09:07:16AM +0100, Peter Zijlstra escreveu:
> On Mon, Nov 09, 2020 at 10:53:54PM +0100, Jiri Olsa wrote:
> > Adding support to carry build id data in mmap2 event.
> >
> > The build id data replaces maj/min/ino/ino_generation
> > fields, whichc are also used to identify map's binary,
> > so it's ok to replace them with build id data:
> >
> > union {
> > struct {
> > u32 maj;
> > u32 min;
> > u64 ino;
> > u64 ino_generation;
> > };
> > struct {
> > u8build_id[20];
> > u8build_id_size;
>
> What's the purpose of a size field for a fixed size array? Also, I'd
> flip the order of these fields, first have the size and then the array.
There can be different types of build-ids, with different sizes,
flipping the order of the fields is indeed sensible, as we could then
support even larger build_ids if the need arises :)
- Arnaldo
> > u8__reserved_1;
> > u16 __reserved_2;
> > };
> > };
> >
> > Replaced maj/min/ino/ino_generation fields give us size
> > of 24 bytes. We use 20 bytes for build id data, 1 byte
> > for size and rest is unused.
--
- Arnaldo
Re: [PATCH v3 2/2] usb: typec: Expose Product Type VDOs via sysfs
On Fri, Oct 23, 2020 at 02:43:28PM -0700, Prashant Malani wrote:
> A PD-capable device can return up to 3 Product Type VDOs as part of its
> DiscoverIdentity Response (USB PD Spec, Rev 3.0, Version 2.0, Section
> 6.4.4.3.1). Add sysfs attributes to expose these to userspace.
>
> Cc: Benson Leung
> Cc: Heikki Krogerus
> Signed-off-by: Prashant Malani
> ---
>
> Changes in v3:
> - Split each product type VDO into a separate attribute.
> - Changed sprintf() to sysfs_emit().
> - Changed ABI documentation based on consolidation of identity VDO
> descriptions in the previous patch (1/2).
>
> Changes in v2:
> - Added sysfs_notify() call for the attribute.
> - Added description for the attribute in
> Documentation/ABI/testing/sysfs-class-typec.
>
> Documentation/ABI/testing/sysfs-class-typec | 24 +++
> drivers/usb/typec/class.c | 33 +
> 2 files changed, 57 insertions(+)
>
> diff --git a/Documentation/ABI/testing/sysfs-class-typec
> b/Documentation/ABI/testing/sysfs-class-typec
> index 0f839fd022f1..0ac144bc5927 100644
> --- a/Documentation/ABI/testing/sysfs-class-typec
> +++ b/Documentation/ABI/testing/sysfs-class-typec
> @@ -205,6 +205,30 @@ Description:
> will show 0 until Discover Identity command result becomes
> available. The value can be polled.
>
> +What:
> /sys/class/typec/-{partner|cable}/identity/product_type_vdo1
> +Date:October 2020
> +Contact: Prashant Malani
> +Description:
> + 1st Product Type VDO of Discover Identity command result.
> + The value will show 0 until Discover Identity command result
> becomes
> + available and a valid Product Type VDO is returned.
> +
> +What:
> /sys/class/typec/-{partner|cable}/identity/product_type_vdo2
> +Date:October 2020
> +Contact: Prashant Malani
> +Description:
> + 2nd Product Type VDO of Discover Identity command result.
> + The value will show 0 until Discover Identity command result
> becomes
> + available and a valid Product Type VDO is returned.
> +
> +What:
> /sys/class/typec/-{partner|cable}/identity/product_type_vdo3
> +Date:October 2020
> +Contact: Prashant Malani
> +Description:
> + 3rd Product Type VDO of Discover Identity command result.
> + The value will show 0 until Discover Identity command result
> becomes
> + available and a valid Product Type VDO is returned.
> +
>
> USB Type-C port alternate mode devices.
>
> diff --git a/drivers/usb/typec/class.c b/drivers/usb/typec/class.c
> index 35eec707cb51..a2c88594b044 100644
> --- a/drivers/usb/typec/class.c
> +++ b/drivers/usb/typec/class.c
> @@ -122,10 +122,40 @@ static ssize_t product_show(struct device *dev, struct
> device_attribute *attr,
> }
> static DEVICE_ATTR_RO(product);
>
> +static ssize_t product_type_vdo1_show(struct device *dev, struct
> device_attribute *attr,
> + char *buf)
> +{
> + struct usb_pd_identity *id = get_pd_identity(dev);
> +
> + return sysfs_emit(buf, "0x%08x\n", id->vdo[0]);
> +}
> +static DEVICE_ATTR_RO(product_type_vdo1);
> +
> +static ssize_t product_type_vdo2_show(struct device *dev, struct
> device_attribute *attr,
> + char *buf)
> +{
> + struct usb_pd_identity *id = get_pd_identity(dev);
> +
> + return sysfs_emit(buf, "0x%08x\n", id->vdo[1]);
> +}
> +static DEVICE_ATTR_RO(product_type_vdo2);
> +
> +static ssize_t product_type_vdo3_show(struct device *dev, struct
> device_attribute *attr,
> + char *buf)
> +{
> + struct usb_pd_identity *id = get_pd_identity(dev);
> +
> + return sysfs_emit(buf, "0x%08x\n", id->vdo[2]);
> +}
> +static DEVICE_ATTR_RO(product_type_vdo3);
> +
> static struct attribute *usb_pd_id_attrs[] = {
> &dev_attr_id_header.attr,
> &dev_attr_cert_stat.attr,
> &dev_attr_product.attr,
> + &dev_attr_product_type_vdo1.attr,
> + &dev_attr_product_type_vdo2.attr,
> + &dev_attr_product_type_vdo3.attr,
> NULL
> };
>
> @@ -144,6 +174,9 @@ static void typec_report_identity(struct device *dev)
> sysfs_notify(&dev->kobj, "identity", "id_header");
> sysfs_notify(&dev->kobj, "identity", "cert_stat");
> sysfs_notify(&dev->kobj, "identity", "product");
> + sysfs_notify(&dev->kobj, "identity", "product_type_vdo1");
> + sysfs_notify(&dev->kobj, "identity", "product_type_vdo2");
> + sysfs_notify(&dev->kobj, "identity", "product_type_vdo3");
> }
I've now come to the conclusion that this is not the correct approach.
Instead, the whole identity, all six VDOs, should be supplied
separately with a "raw" sysfs attribute file after all.
The three attribute files that we already have - so id_header,
cert_stat and product - can always supply the actual VDO
Re: [PATCH v6 0/2] Modify documentation and machine driver for SC7180 sound card
On Tue, Nov 10, 2020 at 05:40:40PM +0800, Ajye Huang wrote: > Hi, Mark > > Could you please kindly review the series patch v6? And may I get your > approval if the review is done. Please don't send content free pings and please allow a reasonable time for review. People get busy, go on holiday, attend conferences and so on so unless there is some reason for urgency (like critical bug fixes) please allow at least a couple of weeks for review. If there have been review comments then people may be waiting for those to be addressed. Sending content free pings adds to the mail volume (if they are seen at all) which is often the problem and since they can't be reviewed directly if something has gone wrong you'll have to resend the patches anyway, so sending again is generally a better approach though there are some other maintainers who like them - if in doubt look at how patches for the subsystem are normally handled. signature.asc Description: PGP signature
Re: [PATCH] drivers: amdgpu: amdgpu_display: Fixed the spelling of falg to flag
Am 09.11.20 um 22:07 schrieb Bhaskar Chowdhury: s/falg/flag/p Signed-off-by: Bhaskar Chowdhury Reviewed-by: Christian König --- drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c index 2e8a8b57639f..9223502c1e5b 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c @@ -509,7 +509,7 @@ uint32_t amdgpu_display_supported_domains(struct amdgpu_device *adev, * to avoid hang caused by placement of scanout BO in GTT on certain * APUs. So force the BO placement to VRAM in case this architecture * will not allow USWC mappings. -* Also, don't allow GTT domain if the BO doens't have USWC falg set. +* Also, don't allow GTT domain if the BO doens't have USWC flag set. */ if ((bo_flags & AMDGPU_GEM_CREATE_CPU_GTT_USWC) && amdgpu_bo_support_uswc(bo_flags) && -- 2.26.2
Re: [PATCH v2] clk: hisilicon: Free clk_data and unmap region obtained by of_iomap
On 2020/11/10 1:54, Markus Elfring wrote: > … >> +++ b/drivers/clk/hisilicon/clk-hi3620.c > … >> @@ -478,6 +478,10 @@ static void __init hi3620_mmc_clk_init(struct >> device_node *node) >> >> clk_data->clk_num = num; >> of_clk_add_provider(node, of_clk_src_onecell_get, clk_data); >> +free_clk_data: >> +kfree(clk_data); > … > > * Should any system resources be kept allocated if the execution > of this function implementation succeeded? > > * How do you think about to add the statement “return;” > after the call of the function “of_clk_add_provider”? > > * Should another return value be also checked here? sure. > > See also: > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/clk/clk.c?id=f8394f232b1eab649ce2df5c5f15b0e528c92091#n4414 > https://elixir.bootlin.com/linux/v5.10-rc2/source/drivers/clk/clk.c#L4414 > > * Would you like to use the function “of_clk_add_hw_provider” instead? How about we still use of_clk_add_provider()? It doesn't seem to make difference using of_clk_add_hw_provider(). > > Regards, > Markus
Re: [PATCH] mm/filemap: add static for function __add_to_page_cache_locked
在 2020/11/10 上午11:09, Souptick Joarder 写道: > On Fri, Nov 6, 2020 at 4:55 PM Alex Shi wrote: >> >> Otherwise it cause gcc warning: >> ^~~ >> ../mm/filemap.c:830:14: warning: no previous prototype for >> ‘__add_to_page_cache_locked’ [-Wmissing-prototypes] >> noinline int __add_to_page_cache_locked(struct page *page, >> ^~ > > Is CONFIG_DEBUG_INFO_BTF enabled in your .config ? Sorry, I tried to buld the configure with bzImage, but failed on pahole version too low, and compiled pahole still can not run in git://git.kernel.org/pub/scm/devel/pahole/pahole.git #pahole pahole: symbol lookup error: pahole: undefined symbol: tabs > >> >> Signed-off-by: Alex Shi >> Cc: Andrew Morton >> Cc: linux...@kvack.org >> Cc: linux-kernel@vger.kernel.org >> --- >> mm/filemap.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/mm/filemap.c b/mm/filemap.c >> index d90614f501da..249cf489f5df 100644 >> --- a/mm/filemap.c >> +++ b/mm/filemap.c >> @@ -827,7 +827,7 @@ int replace_page_cache_page(struct page *old, struct >> page *new, gfp_t gfp_mask) >> } >> EXPORT_SYMBOL_GPL(replace_page_cache_page); >> >> -noinline int __add_to_page_cache_locked(struct page *page, >> +static noinline int __add_to_page_cache_locked(struct page *page, >> struct address_space *mapping, >> pgoff_t offset, gfp_t gfp, >> void **shadowp) >> -- >> 1.8.3.1 >> >>
Re: [PATCH 08/19] drm/omapdrm/omap_gem: Fix misnamed and missing parameter descriptions
On 06/11/2020 23:49, Lee Jones wrote: > Fixes the following W=1 kernel build warning(s): > > drivers/gpu/drm/omapdrm/omap_gem.c:593: warning: Function parameter or > member 'file' not described in 'omap_gem_dumb_create' > drivers/gpu/drm/omapdrm/omap_gem.c:593: warning: Excess function parameter > 'drm_file' description in 'omap_gem_dumb_create' > drivers/gpu/drm/omapdrm/omap_gem.c:619: warning: Function parameter or > member 'offset' not described in 'omap_gem_dumb_map_offset' > > Cc: Tomi Valkeinen > Cc: David Airlie > Cc: Daniel Vetter > Cc: Sumit Semwal > Cc: "Christian König" > Cc: Rob Clark > Cc: dri-de...@lists.freedesktop.org > Cc: linux-me...@vger.kernel.org > Cc: linaro-mm-...@lists.linaro.org > Signed-off-by: Lee Jones > --- > drivers/gpu/drm/omapdrm/omap_gem.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) Thanks! I'll pick this one and the next to drm-misc-next. Tomi -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Re: [RFC PATCH v1 00/26] Make reporting-bugs easier to grasp and yet more detailed
Am 09.11.20 um 19:21 schrieb Jonathan Corbet: On Mon, 9 Nov 2020 12:01:56 +0100 Thorsten Leemhuis wrote: @Jon: I'd be really appreciate to hear your thoughts on this. Seems like it's time to post a new version with all of your feedback so far reflected, and we'll go from there? Will do, just give me a day to two. Ciao, Thorsten P.S.: BTW, @Randy, thx for yesterdays clarification in another mail of this subthread!
Re: [PATCH] powerpc/powernv/sriov: fix unsigned int win compared to less than zero
On 10/11/20 10:19 pm, xiakaixu1...@gmail.com wrote:
From: Kaixu Xia
Fix coccicheck warning:
./arch/powerpc/platforms/powernv/pci-sriov.c:443:7-10: WARNING: Unsigned
expression compared with zero: win < 0
./arch/powerpc/platforms/powernv/pci-sriov.c:462:7-10: WARNING: Unsigned
expression compared with zero: win < 0
Reported-by: Tosk Robot
Signed-off-by: Kaixu Xia
This seems like the right fix, the value assigned to win can indeed be
-1 so it should be signed. Thanks for sending the patch.
Reviewed-by: Andrew Donnellan
---
arch/powerpc/platforms/powernv/pci-sriov.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/platforms/powernv/pci-sriov.c
b/arch/powerpc/platforms/powernv/pci-sriov.c
index c4434f20f42f..92fc861c528f 100644
--- a/arch/powerpc/platforms/powernv/pci-sriov.c
+++ b/arch/powerpc/platforms/powernv/pci-sriov.c
@@ -422,7 +422,7 @@ static int pnv_pci_vf_assign_m64(struct pci_dev *pdev, u16
num_vfs)
{
struct pnv_iov_data *iov;
struct pnv_phb*phb;
- unsigned int win;
+ intwin;
struct resource *res;
inti, j;
int64_trc;
--
Andrew Donnellan OzLabs, ADL Canberra
a...@linux.ibm.com IBM Australia Limited
Re: [v9 1/2] i2c: imx: support slave mode for imx I2C driver
Hi,
On Mon, Nov 02, 2020 at 04:21:01PM +0800, Biwen Li wrote:
> From: Biwen Li
>
> The patch supports slave mode for imx I2C driver
>
> Signed-off-by: Biwen Li
> ---
> Change in v9:
> - remove #ifdef after select I2C_SLAVE by default
>
> Change in v8:
> - fix build issue
>
> Change in v7:
> - support auto switch mode between master and slave
> - enable interrupt when idle in slave mode
> - remove #ifdef
>
> Change in v6:
> - delete robust logs and comments
> - not read status register again in master isr.
>
> Change in v5:
> - fix a bug that cannot determine in what mode(master mode or
> slave mode)
>
> Change in v4:
> - add MACRO CONFIG_I2C_SLAVE to fix compilation issue
>
> Change in v3:
> - support layerscape and i.mx platform
>
> Change in v2:
> - remove MACRO CONFIG_I2C_SLAVE
>
> drivers/i2c/busses/i2c-imx.c | 213 ---
> 1 file changed, 199 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c
> index c98529c76348..098e2c8a0fc7 100644
> --- a/drivers/i2c/busses/i2c-imx.c
> +++ b/drivers/i2c/busses/i2c-imx.c
> @@ -17,6 +17,7 @@
> * Copyright (C) 2008 Darius Augulis
> *
> * Copyright 2013 Freescale Semiconductor, Inc.
> + * Copyright 2020 NXP
> *
> */
>
> @@ -72,6 +73,7 @@
> #define IMX_I2C_I2CR 0x02/* i2c control */
> #define IMX_I2C_I2SR 0x03/* i2c status */
> #define IMX_I2C_I2DR 0x04/* i2c transfer data */
> +#define IMX_I2C_IBIC 0x05/* i2c transfer data */
This register is not documented in the imx6sdl or imx8mm. Which chip
support this register? If all, please provide more descriptive and
correct comment "i2c transfer data" seems to be just copy/paste
artifact.
>
> #define IMX_I2C_REGSHIFT 2
> #define VF610_I2C_REGSHIFT 0
> @@ -91,6 +93,7 @@
> #define I2CR_MSTA0x20
> #define I2CR_IIEN0x40
> #define I2CR_IEN 0x80
> +#define IBIC_BIIE0x80 // Bus idle interrupt enable
Please use C style comments.
If it is "Bus idle interrupt enable", then we should handle this
interrupt some how?
>
> /* register bits different operating codes definition:
> * 1) I2SR: Interrupt flags clear operation differ between SoCs:
> @@ -201,6 +204,7 @@ struct imx_i2c_struct {
> struct pinctrl_state *pinctrl_pins_gpio;
>
> struct imx_i2c_dma *dma;
> + struct i2c_client *slave;
> };
>
> static const struct imx_i2c_hwdata imx1_i2c_hwdata = {
> @@ -277,6 +281,14 @@ static inline unsigned char imx_i2c_read_reg(struct
> imx_i2c_struct *i2c_imx,
> return readb(i2c_imx->base + (reg << i2c_imx->hwdata->regshift));
> }
>
> +/* Set up i2c controller register and i2c status register to default value.
> */
> +static void i2c_imx_reset_regs(struct imx_i2c_struct *i2c_imx)
> +{
> + imx_i2c_write_reg(i2c_imx->hwdata->i2cr_ien_opcode ^ I2CR_IEN,
> + i2c_imx, IMX_I2C_I2CR);
> + imx_i2c_write_reg(i2c_imx->hwdata->i2sr_clr_opcode, i2c_imx,
> IMX_I2C_I2SR);
i.MX and Vybrid have different IMX_I2C_I2SR logic. w1c vs w0c.
Please apply your patches on top of this patch set:
https://lkml.org/lkml/2020/10/2/607
> +}
> +
> /* Functions for DMA support */
> static void i2c_imx_dma_request(struct imx_i2c_struct *i2c_imx,
> dma_addr_t phy_addr)
> @@ -614,20 +626,188 @@ static void i2c_imx_stop(struct imx_i2c_struct
> *i2c_imx, bool atomic)
> imx_i2c_write_reg(temp, i2c_imx, IMX_I2C_I2CR);
> }
>
> +/*
> + * Enable bus idle interrupts
Please provide more information, which datasheet was used, which SoC is
supporting this bits and why we do not need to handle this interrupts.
> + * Note: IBIC register will be cleared after disabled i2c module.
> + */
> +static void i2c_imx_enable_bus_idle(struct imx_i2c_struct *i2c_imx)
> +{
> + unsigned int temp;
> +
> + temp = imx_i2c_read_reg(i2c_imx, IMX_I2C_IBIC);
> + temp |= IBIC_BIIE;
> + imx_i2c_write_reg(temp, i2c_imx, IMX_I2C_IBIC);
> +}
> +
> +static void i2c_imx_clr_if_bit(unsigned int status, struct imx_i2c_struct
> *i2c_imx)
> +{
> + status &= ~I2SR_IIF;
> + status |= (i2c_imx->hwdata->i2sr_clr_opcode & I2SR_IIF);
> + imx_i2c_write_reg(status, i2c_imx, IMX_I2C_I2SR);
This code will accidentally clear I2SR_IAL bit on Vybrid
> +}
> +
> +/* Clear arbitration lost bit */
> +static void i2c_imx_clr_al_bit(unsigned int status, struct imx_i2c_struct
> *i2c_imx)
> +{
> + status &= ~I2SR_IAL;
> + status |= (i2c_imx->hwdata->i2sr_clr_opcode & I2SR_IAL);
> + imx_i2c_write_reg(status, i2c_imx, IMX_I2C_I2SR);
This code will accidentally clear I2SR_IIF bit on Vybrid
> +}
> +
> +static irqreturn_t i2c_imx_slave_isr(struct imx_i2c_struct *i2c_imx,
> + unsigned int status, unsigned int ctl)
> +{
> + u8 value;
> +
> + if (status & I2SR_IAL) { /* Arbitration lost */
Re: [PATCH 2/3] arm: introduce IRQ stacks
* Arnd Bergmann [201110 10:04]: > On Tue, Nov 10, 2020 at 10:19 AM Tony Lindgren wrote: > > * Arnd Bergmann [201109 19:10]: > > > On Mon, Nov 9, 2020 at 3:45 PM Tony Lindgren wrote: > > > > > > I know it works, my point was that I'm not sure anyone cares > > > any more ;-) > > > > Well for example whatever Linux running ARMv6 LTE modems out there might > > need to be supported for quite some time. Not sure how many of them are > > able to update kernels though. Certainly network security related issues > > would be a good reason to update the kernels. > > While I agree they should update their kernels, I suspect none of those > modems do. I am however certain that none of them are running an > SMP-enabled multiplatform kernel on an ARM1136r0! Nope, AFAIK all the SMP parts are ARMv6K :) > Are these actually ARMv6? Most ARM11 cores you'd come across > in practice are ARMv6K (ARM1136r1, ARM1167, ARM11MPCore), > in particular every SoC that has any mainline support except for > the ARM1136r0 based OMAP2 and i.MX3. I've been only using smp_on_up for the ARMv6 ARM1136r0 variants for omap2, no SMP on those. Regards, Tony
Re: [PATCHv7 6/7] iommu: arm-smmu-impl: Use table to list QCOM implementations
On Fri, Oct 30, 2020 at 02:53:13PM +0530, Sai Prakash Ranjan wrote: > Use table and of_match_node() to match qcom implementation > instead of multiple of_device_compatible() calls for each > QCOM SMMU implementation. > > Signed-off-by: Sai Prakash Ranjan > --- > drivers/iommu/arm/arm-smmu/arm-smmu-impl.c | 9 + > drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 21 - > drivers/iommu/arm/arm-smmu/arm-smmu.h | 1 - > 3 files changed, 17 insertions(+), 14 deletions(-) Acked-by: Will Deacon Will
Re: [PATCHv7 7/7] iommu: arm-smmu-impl: Add a space before open parenthesis
On Fri, Oct 30, 2020 at 02:53:14PM +0530, Sai Prakash Ranjan wrote:
> Fix the checkpatch warning for space required before the open
> parenthesis.
>
> Signed-off-by: Sai Prakash Ranjan
> ---
> drivers/iommu/arm/arm-smmu/arm-smmu-impl.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-impl.c
> b/drivers/iommu/arm/arm-smmu/arm-smmu-impl.c
> index ffaf3f91ba52..f16da4a21270 100644
> --- a/drivers/iommu/arm/arm-smmu/arm-smmu-impl.c
> +++ b/drivers/iommu/arm/arm-smmu/arm-smmu-impl.c
> @@ -12,7 +12,7 @@
>
> static int arm_smmu_gr0_ns(int offset)
> {
> - switch(offset) {
> + switch (offset) {
> case ARM_SMMU_GR0_sCR0:
> case ARM_SMMU_GR0_sACR:
> case ARM_SMMU_GR0_sGFSR:
Whatever...
Acked-by: Will Deacon
Will
