RE: [PATCH v4 06/17] PCI: add SIOV and IMS capability detection
> From: Raj, Ashok > Sent: Monday, November 9, 2020 7:59 AM > > Hi Thomas, > > [-] Jing, She isn't working at Intel anymore. > > Now this is getting compiled as a book :-).. Thanks a ton! > > One question on the hypercall case that isn't immediately > clear to me. > > On Sun, Nov 08, 2020 at 07:47:24PM +0100, Thomas Gleixner wrote: > > > > > > Now if we look at the virtualization scenario and device hand through > > then the structure in the guest view is not any different from the basic > > case. This works with PCI-MSI[X] and the IDXD IMS variant because the > > hypervisor can trap the access to the storage and translate the message: > > > >| > >| > > [CPU]-- [Bri | dge] -- Bus -- [Device] > >| > > Alloc + > > Compose Store Use > > | > > | Trap > > v > > Hypervisor translates and stores > > > > The above case, VMM is responsible for writing to the message > store. In both cases if its IMS or Legacy MSI/MSIx. VMM handles > the writes to the device interrupt region and to the IRTE tables. > > > But obviously with an IMS storage location which is software controlled > > by the guest side driver (the case Jason is interested in) the above > > cannot work for obvious reasons. > > > > That means the guest needs a way to ask the hypervisor for a proper > > translation, i.e. a hypercall. Now where to do that? Looking at the > > above remapping case it's pretty obvious: > > > > > > | > > | > > [CPU] -- [VI | RT] -- [Bridge] --Bus-- [Device] > > | > > Alloc "Compose" Store Use > > > > Vectordomain HCALLdomainBusdomain > > |^ > > || > > v| > > Hypervisor > >Alloc + Compose > > > > Why? Because it reflects the boundaries and leaves the busdomain part > > agnostic as it should be. And it works for _all_ variants of Busdomains. > > > > Now the question which I can't answer is whether this can work correctly > > in terms of isolation. If the IMS storage is in guest memory (queue > > storage) then the guest driver can obviously write random crap into it > > which the device will happily send. (For MSI and IDXD style IMS it > > still can trap the store). > > The isolation problem is not just the guest memory being used as interrrupt > store right? If the Store to device region is not trapped and controlled by > VMM, there is no gaurantee the guest OS has done the right thing? > > > Thinking about it, guest memory might be more problematic since its not > trappable and VMM can't enforce what is written. This is something that > needs more attension. But for now the devices supporting memory on device > the trap and store by VMM seems to satisfy the security properties you > highlight here. > Just want to clarify the trap part. Guest memory is not trappable in Jason's example, which has queue/IMS storage swapped between device/memory and requires special command to sync the state. But there is also other forms of in-memory IMS implementation. e.g. Some devices serve work requests based on command buffers instead of HW work queues. The command buffers are linked in per-process contexts (both in memory) thus similarly IMS could be stored in each context too. There is no swap per se. The context is allocated by the driver and then registered to the device through a mgmt. interface. When the mgmt. interface is mediated, the hypervisor knows the IMS location and could mark it as read-only in EPT page table to enable trapping of guest writes. Of course this approach is awkward if the complexity is paid just for virtualizing IMS. Thanks Kevin
[PATCH v7 3/5] 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 b615b981be9d6..396960ef54a13 100644
--- a/net/bluetooth/hci_request.c
+++ b/net/bluetooth/hci_request.c
@@ -3092,8 +3092,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 v7 4/5] mgmt: Add supports of variable length parameter in mgmt_config
This adds support of variable length parameter in mgmt_config.
Signed-off-by: Howard Chung
---
(no changes since v1)
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..b735e59c7fd51 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);
+ HDEV_PARAM_U16(le_scan_int_suspend);
+
[PATCH v7 5/5] 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
---
Changes in v7:
- Fix bt_dev_warn arguemnt type warning
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 396960ef54a13..85948c73c72b3 100644
--- a/net/bluetooth/hci_request.c
+++ b/net/bluetooth/hci_request.c
@@ -1059,7 +1059,8 @@ void hci_req_add_le_passive_scan(struct hci_request *req)
_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 b735e59c7fd51..a3dfcdcb3b78d 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;
+ size_t exp_type_len;
const u16 exp_len = sizeof(struct mgmt_tlv) +
len;
const u16 type = le16_to_cpu(TO_TLV(buffer)->type);
@@
[PATCH v7 1/5] 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 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
include/net/bluetooth/hci_core.h | 10 +++
net/bluetooth/hci_core.c | 4 +
net/bluetooth/hci_request.c | 136 +--
net/bluetooth/mgmt_config.c | 10 +++
4 files changed, 153 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 6f12bab4d2fa6..70ea126f56282 100644
--- a/net/bluetooth/hci_request.c
+++ b/net/bluetooth/hci_request.c
@@ -378,6 +378,58 @@ void __hci_req_write_fast_connectable(struct hci_request
*req, bool enable)
hci_req_add(req, HCI_OP_WRITE_PAGE_SCAN_TYPE, 1, );
}
+static void start_interleave_scan(struct hci_dev *hdev)
+{
+ hdev->interleave_scan_state = INTERLEAVE_SCAN_NO_FILTER;
+ queue_delayed_work(hdev->req_workqueue,
+ >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, "%s cancelling interleave scan", hdev->name);
+
+ cancel_delayed_work_sync(>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 (hci_is_adv_monitoring(hdev) &&
+ !(list_empty(>pend_le_conns) &&
+ list_empty(>pend_le_reports))) {
+ if (!is_interleave_scanning(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.
+*/
+ start_interleave_scan(hdev);
+ bt_dev_dbg(hdev, "%s starting interleave scan",
+ hdev->name);
+ return true;
+ }
+ }
+
+ if (is_interleave_scanning(hdev)) {
+ /* If the interleave condition no longer holds, cancel
+* the existed interleave scan.
+*/
+ cancel_interleave_scan(hdev);
+ }
+
+ return false;
[PATCH v7 2/5] 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.
Commit-changes 5:
- Remove the change in hci_req_config_le_suspend_scan
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 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 70ea126f56282..b615b981be9d6 100644
--- a/net/bluetooth/hci_request.c
+++ b/net/bluetooth/hci_request.c
@@ -1284,8 +1284,10 @@ void hci_req_prepare_suspend(struct hci_dev *hdev, enum
suspended_state next)
hci_req_add(, HCI_OP_WRITE_SCAN_ENABLE, 1, _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(, false);
+ }
/* Mark task needing completion */
set_bit(SUSPEND_SCAN_DISABLE, hdev->suspend_tasks);
--
2.29.2.222.g5d2a92d10f8-goog
[PATCH] gpio: sifive: To get gpio irq offset from device tree data
We can get hwirq number of the gpio by its irq_data->hwirq so that we don't
need to add more macros for different platforms. This patch is tested in
SiFive Unleashed board and SiFive Unmatched board.
Signed-off-by: Greentime Hu
---
drivers/gpio/gpio-sifive.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/gpio/gpio-sifive.c b/drivers/gpio/gpio-sifive.c
index c54dd08f2cbf..bfb915bf5d78 100644
--- a/drivers/gpio/gpio-sifive.c
+++ b/drivers/gpio/gpio-sifive.c
@@ -29,7 +29,6 @@
#define SIFIVE_GPIO_OUTPUT_XOR 0x40
#define SIFIVE_GPIO_MAX32
-#define SIFIVE_GPIO_IRQ_OFFSET 7
struct sifive_gpio {
void __iomem*base;
@@ -37,7 +36,7 @@ struct sifive_gpio {
struct regmap *regs;
unsigned long irq_state;
unsigned inttrigger[SIFIVE_GPIO_MAX];
- unsigned intirq_parent[SIFIVE_GPIO_MAX];
+ unsigned intirq_number[SIFIVE_GPIO_MAX];
};
static void sifive_gpio_set_ie(struct sifive_gpio *chip, unsigned int offset)
@@ -144,8 +143,10 @@ static int sifive_gpio_child_to_parent_hwirq(struct
gpio_chip *gc,
unsigned int *parent,
unsigned int *parent_type)
{
+ struct sifive_gpio *chip = gpiochip_get_data(gc);
+ struct irq_data *d = irq_get_irq_data(chip->irq_number[child]);
+ *parent = irqd_to_hwirq(d);
*parent_type = IRQ_TYPE_NONE;
- *parent = child + SIFIVE_GPIO_IRQ_OFFSET;
return 0;
}
@@ -165,7 +166,7 @@ static int sifive_gpio_probe(struct platform_device *pdev)
struct irq_domain *parent;
struct gpio_irq_chip *girq;
struct sifive_gpio *chip;
- int ret, ngpio;
+ int ret, ngpio, i;
chip = devm_kzalloc(dev, sizeof(*chip), GFP_KERNEL);
if (!chip)
@@ -200,6 +201,9 @@ static int sifive_gpio_probe(struct platform_device *pdev)
return -ENODEV;
}
+ for (i = 0; i < ngpio; i++)
+ chip->irq_number[i] = platform_get_irq(pdev, i);
+
ret = bgpio_init(>gc, dev, 4,
chip->base + SIFIVE_GPIO_INPUT_VAL,
chip->base + SIFIVE_GPIO_OUTPUT_VAL,
--
2.29.2
Re: [PATCH 5.9 639/757] random32: make prandom_u32() output unpredictable
On Mon, Nov 09, 2020 at 08:54:13AM +0200, Amit Klein wrote: > Unfortunately, I'm just a security researcher, not a kernel developer... > > Does that mean you don't plan to back-port the patch? I could possibly have a look, but quite frankly I'm not convinced that we need to backport this at all. I think that what we've done is mostly to be future-proof and that the likelihood of practical attacks against live systems with the previous fix are close to zero. Cheers, Willy
ld: drivers/gpu/drm/bridge/sil-sii8620.c:2191: undefined reference to `extcon_register_notifier'
Hi Masahiro, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: f8394f232b1eab649ce2df5c5f15b0e528c92091 commit: def2fbffe62c00c330c7f41584a356001179c59c kconfig: allow symbols implied by y to become m date: 8 months ago config: i386-randconfig-r022-20201106 (attached as .config) compiler: gcc-9 (Debian 9.3.0-15) 9.3.0 reproduce (this is a W=1 build): # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=def2fbffe62c00c330c7f41584a356001179c59c git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout def2fbffe62c00c330c7f41584a356001179c59c # save the attached .config to linux build tree make W=1 ARCH=i386 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>): ld: drivers/gpu/drm/bridge/sil-sii8620.o: in function `sii8620_remove': drivers/gpu/drm/bridge/sil-sii8620.c:2355: undefined reference to `extcon_unregister_notifier' ld: drivers/gpu/drm/bridge/sil-sii8620.o: in function `sii8620_extcon_init': drivers/gpu/drm/bridge/sil-sii8620.c:2179: undefined reference to `extcon_find_edev_by_node' >> ld: drivers/gpu/drm/bridge/sil-sii8620.c:2191: undefined reference to >> `extcon_register_notifier' ld: drivers/gpu/drm/bridge/sil-sii8620.o: in function `sii8620_extcon_work': drivers/gpu/drm/bridge/sil-sii8620.c:2139: undefined reference to `extcon_get_state' --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org .config.gz Description: application/gzip
Re: [PATCH v2] mm/gup_test: GUP_TEST depends on DEBUG_FS
On 11/8/20 11:45 PM, John Hubbard wrote: > On 11/8/20 12:37 AM, Barry Song wrote: >> Without DEBUG_FS, all the code in gup_test becomes meaningless. For sure >> kernel provides debugfs stub while DEBUG_FS is disabled, but the point >> here is that GUP_TEST can do nothing without DEBUG_FS. >> >> Cc: John Hubbard >> Cc: Ralph Campbell >> Cc: Randy Dunlap >> Suggested-by: John Garry >> Signed-off-by: Barry Song >> --- >> -v2: >> add comment as a prompt to users as commented by John and Randy, thanks! >> >> mm/Kconfig | 4 >> 1 file changed, 4 insertions(+) > > Thanks for suffering through a lot of discussion about this! > > Reviewed-by: John Hubbard > > > thanks, Acked-by: Randy Dunlap thanks. -- ~Randy
Re: [PATCH rfc] workqueue: honour cond_resched() more effectively.
On Mon 09-11-20 13:54:59, Neil Brown wrote: > > If a worker task for a normal (bound, non-CPU-intensive) calls > cond_resched(), this allows other non-workqueue processes to run, but > does *not* allow other workqueue workers to run. This is because > workqueue will only attempt to run one task at a time on each CPU, > unless the current task actually sleeps. > > This is already a problem for should_reclaim_retry() in mm/page_alloc.c, > which inserts a small sleep just to convince workqueue to allow other > workers to run. > > It can also be a problem for NFS when closing a very large file (e.g. > 100 million pages in memory). NFS can call the final iput() from a > workqueue, which can then take long enough to trigger a workqueue-lockup > warning, and long enough for performance problems to be observed. > > I added a WARN_ON_ONCE() in cond_resched() to report when it is run from > a workqueue, and got about 20 hits during boot, many of system_wq (aka > "events") which suggests there is a real chance that worker are being > delayed unnecessarily be tasks which are written to politely relinquish > the CPU. > > I think that once a worker calls cond_resched(), it should be treated as > though it was run from a WQ_CPU_INTENSIVE queue, because only cpu-intensive > tasks need to call cond_resched(). This would allow other workers to be > scheduled. > > The following patch achieves this I believe. I cannot really judge the implementation because my understanding of the WQ concurrency control is very superficial but I echo that the existing behavior is really nonintuitive. It certainly burnt me for the oom situations where the page allocator cannot make much progress to reclaim memory and it has to retry really hard. Having to handle worker context explicitly/differently is error prone and as your example of final iput in NFS shows that the allocator is not the only path affected so having a general solution is better. That being said I would really love to see cond_resched to work transparently. Thanks! -- Michal Hocko SUSE Labs
Re: [PATCH 2/4] arm64: dts: ti: k3-j721e*: Cleanup disabled nodes at SoC dtsi level
On 06/11/2020 23.46, Nishanth Menon wrote: > On 13:32-20201106, Peter Ujfalusi wrote: > [...] >>> > default power management functionality etc Right, so how does that helps with devices present in the SoC, but no node at all? First thing which comes to mind is AASRC, we don't have Linux driver for it (and no DT binding document), but that does not mean that it is not present. How PM would take that into account? >>> >>> I think we are mixing topics here -> I was stating the motivation why >>> devicetree chose such as default. >> >> I don't question the fact that 'okay' is the default status if it is not >> explicitly present. There is no better default than that. > > ^^ -> Alright, that is all we are trying to do here: defaults in the > SoC.dtsi and specific cleanups (firmware reserved / board unused > disables) be done in a common board.dtsi (for now, there is no such > specific need, I guess). The default is what it is: default choice which suits most of the nodes. If the node is not complete in it's present form then it is not in it's default state. imho. >>> Alright - what do we suggest we do? >> >> Not sure, I'm 'whatever' after [1] makes it to mainline or next. > [] >> [1] >> https://lore.kernel.org/alsa-devel/20201106072551.689-1-peter.ujfal...@ti.com/ > > > I don't see the relationship between the series.. I think this series > brings no change in dtb, hence with OR without your driver cleanup > series, there is no practical regressions. This series opens up the possibility of nodes leaking to dtb with known broken state and the driver should have a better strategy than 'works by luck' to handle it ;) >> >>> Tony, Rob - I need some guidance here. >> >> I'm fine whatever way we take, but I think it is up to you to make the >> call as the maintainer of the TI dts files... ;) > > Yep - I have'nt seen a reason yet that must cause us to change from the > Device tree default approach in our debates. Imho 'disabled' is the default for nodes like McASP as it is: "Indicates that the device is not presently operational, but it might become operational in the future" (for example, needed properties added to the node). There is no such a tag, but: whatever-by: Peter Ujfalusi >>> >>> OK - I have no idea how B4 or patchworks pick that one as :D >> >> If we take this road, than I'm okay with it, but I'm going to take >> silent protest (not sending acked-by or revired-by). >> That should not stop you doing what you believe is best for the future! > > OK - thanks for your review and the discussions, always appreciate > getting our views out there. > > if there are no other comments, I will try and post a v2 over the > weekend. OK - Péter Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Re: [PATCH 0/2] AMD-TEE driver bug fixes
Hi Rijo, On Wed, Nov 4, 2020 at 7:26 AM Rijo Thomas wrote: > > AMD-TEE driver keeps track of shared memory buffers and their > corresponding buffer id's in a global linked list. These buffers are > used to share data between x86 and AMD Secure Processor. This patchset > fixes issues related to maintaining mapped buffers in a shared linked > list. > > Rijo Thomas (2): > tee: amdtee: fix memory leak due to reset of global shm list > tee: amdtee: synchronize access to shm list > > drivers/tee/amdtee/amdtee_private.h | 8 > drivers/tee/amdtee/core.c | 26 +++--- > 2 files changed, 23 insertions(+), 11 deletions(-) This series looks good. I'll pick it up. Thanks, Jens
Re: [PATCH v2] mm/gup_test: GUP_TEST depends on DEBUG_FS
On 11/8/20 12:37 AM, Barry Song wrote: Without DEBUG_FS, all the code in gup_test becomes meaningless. For sure kernel provides debugfs stub while DEBUG_FS is disabled, but the point here is that GUP_TEST can do nothing without DEBUG_FS. Cc: John Hubbard Cc: Ralph Campbell Cc: Randy Dunlap Suggested-by: John Garry Signed-off-by: Barry Song --- -v2: add comment as a prompt to users as commented by John and Randy, thanks! mm/Kconfig | 4 1 file changed, 4 insertions(+) Thanks for suffering through a lot of discussion about this! Reviewed-by: John Hubbard thanks, -- John Hubbard NVIDIA diff --git a/mm/Kconfig b/mm/Kconfig index 01b0ae0cd9d3..a7ff0d31afd5 100644 --- a/mm/Kconfig +++ b/mm/Kconfig @@ -836,6 +836,7 @@ config PERCPU_STATS config GUP_TEST bool "Enable infrastructure for get_user_pages()-related unit tests" + depends on DEBUG_FS help Provides /sys/kernel/debug/gup_test, which in turn provides a way to make ioctl calls that can launch kernel-based unit tests for @@ -853,6 +854,9 @@ config GUP_TEST See tools/testing/selftests/vm/gup_test.c +comment "GUP_TEST needs to have DEBUG_FS enabled" + depends on !GUP_TEST && !DEBUG_FS + config GUP_GET_PTE_LOW_HIGH bool
Re: [PATCH v8 1/7] RISC-V: Move DT mapping outof fixmap
Atish Patra 於 2020年9月18日 週五 上午6:37寫道：
>
> From: Anup Patel
>
> Currently, RISC-V reserves 1MB of fixmap memory for device tree. However,
> it maps only single PMD (2MB) space for fixmap which leaves only < 1MB space
> left for other kernel features such as early ioremap which requires fixmap
> as well. The fixmap size can be increased by another 2MB but it brings
> additional complexity and changes the virtual memory layout as well.
> If we require some additional feature requiring fixmap again, it has to be
> moved again.
>
> Technically, DT doesn't need a fixmap as the memory occupied by the DT is
> only used during boot. That's why, We map device tree in early page table
> using two consecutive PGD mappings at lower addresses (< PAGE_OFFSET).
> This frees lot of space in fixmap and also makes maximum supported
> device tree size supported as PGDIR_SIZE. Thus, init memory section can be
> used
> for the same purpose as well. This simplifies fixmap implementation.
>
> Signed-off-by: Anup Patel
> Signed-off-by: Atish Patra
> Reviewed-by: Palmer Dabbelt
> Signed-off-by: Palmer Dabbelt
> ---
> arch/riscv/include/asm/fixmap.h | 3 ---
> arch/riscv/include/asm/pgtable.h | 1 +
> arch/riscv/kernel/head.S | 1 -
> arch/riscv/kernel/head.h | 2 --
> arch/riscv/kernel/setup.c| 9 +++--
> arch/riscv/mm/init.c | 26 --
> 6 files changed, 20 insertions(+), 22 deletions(-)
>
> diff --git a/arch/riscv/include/asm/fixmap.h b/arch/riscv/include/asm/fixmap.h
> index 1ff075a8dfc7..11613f38228a 100644
> --- a/arch/riscv/include/asm/fixmap.h
> +++ b/arch/riscv/include/asm/fixmap.h
> @@ -22,9 +22,6 @@
> */
> enum fixed_addresses {
> FIX_HOLE,
> -#define FIX_FDT_SIZE SZ_1M
> - FIX_FDT_END,
> - FIX_FDT = FIX_FDT_END + FIX_FDT_SIZE / PAGE_SIZE - 1,
> FIX_PTE,
> FIX_PMD,
> FIX_TEXT_POKE1,
> diff --git a/arch/riscv/include/asm/pgtable.h
> b/arch/riscv/include/asm/pgtable.h
> index eaea1f717010..815f8c959dd4 100644
> --- a/arch/riscv/include/asm/pgtable.h
> +++ b/arch/riscv/include/asm/pgtable.h
> @@ -464,6 +464,7 @@ static inline void __kernel_map_pages(struct page *page,
> int numpages, int enabl
> #define kern_addr_valid(addr) (1) /* FIXME */
>
> extern void *dtb_early_va;
> +extern uintptr_t dtb_early_pa;
> void setup_bootmem(void);
> void paging_init(void);
>
> diff --git a/arch/riscv/kernel/head.S b/arch/riscv/kernel/head.S
> index 0a4e81b8dc79..c6a37e8231a8 100644
> --- a/arch/riscv/kernel/head.S
> +++ b/arch/riscv/kernel/head.S
> @@ -259,7 +259,6 @@ clear_bss_done:
> #endif
> /* Start the kernel */
> call soc_early_init
> - call parse_dtb
> tail start_kernel
>
> .Lsecondary_start:
> diff --git a/arch/riscv/kernel/head.h b/arch/riscv/kernel/head.h
> index 105fb0496b24..b48dda3d04f6 100644
> --- a/arch/riscv/kernel/head.h
> +++ b/arch/riscv/kernel/head.h
> @@ -16,6 +16,4 @@ asmlinkage void __init setup_vm(uintptr_t dtb_pa);
> extern void *__cpu_up_stack_pointer[];
> extern void *__cpu_up_task_pointer[];
>
> -void __init parse_dtb(void);
> -
> #endif /* __ASM_HEAD_H */
> diff --git a/arch/riscv/kernel/setup.c b/arch/riscv/kernel/setup.c
> index 2c6dd329312b..edea7ef88402 100644
> --- a/arch/riscv/kernel/setup.c
> +++ b/arch/riscv/kernel/setup.c
> @@ -48,8 +48,9 @@ atomic_t hart_lottery __section(.sdata);
> unsigned long boot_cpu_hartid;
> static DEFINE_PER_CPU(struct cpu, cpu_devices);
>
> -void __init parse_dtb(void)
> +static void __init parse_dtb(void)
> {
> + /* Early scan of device tree from init memory */
> if (early_init_dt_scan(dtb_early_va))
> return;
>
> @@ -62,6 +63,7 @@ void __init parse_dtb(void)
>
> void __init setup_arch(char **cmdline_p)
> {
> + parse_dtb();
> init_mm.start_code = (unsigned long) _stext;
> init_mm.end_code = (unsigned long) _etext;
> init_mm.end_data = (unsigned long) _edata;
> @@ -76,7 +78,10 @@ void __init setup_arch(char **cmdline_p)
> #if IS_ENABLED(CONFIG_BUILTIN_DTB)
> unflatten_and_copy_device_tree();
> #else
> - unflatten_device_tree();
> + if (early_init_dt_verify(__va(dtb_early_pa)))
> + unflatten_device_tree();
> + else
> + pr_err("No DTB found in kernel mappings\n");
> #endif
>
> #ifdef CONFIG_SWIOTLB
> diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c
> index 787c75f751a5..2b651f63f5c4 100644
> --- a/arch/riscv/mm/init.c
> +++ b/arch/riscv/mm/init.c
> @@ -28,7 +28,9 @@ unsigned long empty_zero_page[PAGE_SIZE / sizeof(unsigned
> long)]
> EXPORT_SYMBOL(empty_zero_page);
>
> extern char _start[];
> -void *dtb_early_va;
> +#define DTB_EARLY_BASE_VA PGDIR_SIZE
> +void *dtb_early_va __initdata;
> +uintptr_t dtb_early_pa __initdata;
>
> static void __init zone_sizes_init(void)
> {
> @@ -141,8 +143,6 @@ static void __init setup_initrd(void)
> }
> #endif /* CONFIG_BLK_DEV_INITRD
Re: [tip: perf/kprobes] locking/atomics: Regenerate the atomics-check SHA1's
On Sun, Nov 08, 2020 at 09:35:38AM -0800, Linus Torvalds wrote: > So while we try to mark scripts executable, we then actually generally > execute them using an explicit interpreter invocation anyway (ie using > > $(CONFIG_SHELL) "some-script-path" > > or similar). Thanks for explaining! -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette
Re: [PATCH] ARM: boot: Quote aliased symbol names in string.c
On Mon, 9 Nov 2020 at 01:19, Nathan Chancellor wrote:
>
> Patch "treewide: Remove stringification from __alias macro definition"
> causes arguments to __alias to no longer be quoted automatically, which
> breaks CONFIG_KASAN on ARM after commit d6d51a96c7d6 ("ARM: 9014/2:
> Replace string mem* functions for KASan"):
>
> arch/arm/boot/compressed/string.c:24:1: error: attribute 'alias' argument not
> a string
>24 | void *__memcpy(void *__dest, __const void *__src, size_t __n)
> __alias(memcpy);
> | ^~~~
> arch/arm/boot/compressed/string.c:25:1: error: attribute 'alias' argument not
> a string
>25 | void *__memmove(void *__dest, __const void *__src, size_t count)
> __alias(memmove);
> | ^~~~
> arch/arm/boot/compressed/string.c:26:1: error: attribute 'alias' argument not
> a string
>26 | void *__memset(void *s, int c, size_t count) __alias(memset);
> | ^~~~
> make[3]: *** [scripts/Makefile.build:283: arch/arm/boot/compressed/string.o]
> Error 1
>
> Quote the names like the treewide patch does so there is no more error.
>
> Reported-by: Naresh Kamboju
> Reported-by: Valdis Klētnieks
> Signed-off-by: Nathan Chancellor
Acked-by: Ard Biesheuvel
> ---
>
> Hi Andrew,
>
> Stephen said I should send this along to you so that it can be applied
> as part of the post -next series. Please let me know if you need any
> more information or clarification, I tried to document it succinctly in
> the commit message.
>
> Cheers,
> Nathan
>
> arch/arm/boot/compressed/string.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/boot/compressed/string.c
> b/arch/arm/boot/compressed/string.c
> index 8c0fa276d994..cc6198f8a348 100644
> --- a/arch/arm/boot/compressed/string.c
> +++ b/arch/arm/boot/compressed/string.c
> @@ -21,9 +21,9 @@
> #undef memcpy
> #undef memmove
> #undef memset
> -void *__memcpy(void *__dest, __const void *__src, size_t __n)
> __alias(memcpy);
> -void *__memmove(void *__dest, __const void *__src, size_t count)
> __alias(memmove);
> -void *__memset(void *s, int c, size_t count) __alias(memset);
> +void *__memcpy(void *__dest, __const void *__src, size_t __n)
> __alias("memcpy");
> +void *__memmove(void *__dest, __const void *__src, size_t count)
> __alias("memmove");
> +void *__memset(void *s, int c, size_t count) __alias("memset");
> #endif
>
> void *memcpy(void *__dest, __const void *__src, size_t __n)
> --
> 2.29.2
>
Re: [PATCH] mm: introduce oom_kill_disable sysctl knob
On Fri 06-11-20 12:32:38, Minchan Kim wrote: > It's hard to have some tests to be supposed to work under heavy > memory pressure(e.g., injecting some memory hogger) because > out-of-memory killer easily kicks out one of processes so system > is broken or system loses the memory pressure state since it has > plenty of free memory soon so. I do not follow the reasoning here. So you want to test for a close to no memory available situation and the oom killer stands in the way because it puts a relief? > Even though we could mark existing process's oom_adj to -1000, > it couldn't cover upcoming processes to be forked for the job. Why? > This knob is handy to keep system memory pressure. This sounds like a very dubious reason to introduce a knob to cripple the system. I can see some reason to control the oom handling policy because the effect of the oom killer is really disruptive but a global on/off switch sounds like a too coarse interface. Really what kind of production environment would ever go with oom killer disabled completely? -- Michal Hocko SUSE Labs
RE: [PATCH v4 06/17] PCI: add SIOV and IMS capability detection
> From: Jason Gunthorpe > Sent: Monday, November 9, 2020 7:24 AM > > On Sun, Nov 08, 2020 at 07:47:24PM +0100, Thomas Gleixner wrote: > > > > That means the guest needs a way to ask the hypervisor for a proper > > translation, i.e. a hypercall. Now where to do that? Looking at the > > above remapping case it's pretty obvious: > > > > > > | > > | > > [CPU] -- [VI | RT] -- [Bridge] --Bus-- [Device] > > | > > Alloc "Compose" Store Use > > > > Vectordomain HCALLdomainBusdomain > > |^ > > || > > v| > > Hypervisor > >Alloc + Compose > > Yes, this will describes what I have been thinking Agree > > > Now the question which I can't answer is whether this can work correctly > > in terms of isolation. If the IMS storage is in guest memory (queue > > storage) then the guest driver can obviously write random crap into it > > which the device will happily send. (For MSI and IDXD style IMS it > > still can trap the store). > > There are four cases of interest here: > > 1) Bare metal, PF and VF devices just deliver whatever addr/data pairs > to the APIC. IMS works perfectly with > pci_subdevice_msi_create_irq_domain() > > 2) SRIOV VF assigned to the guest. > > The guest can cause any MemWr TLP to any addr/data pair > and the iommu/platform/vmm is supposed to use the > Bus/device/function to isolate & secure the interrupt address > range. > > IMS can work in the guest if the guest knows the details of the > address range and can make hypercalls to setup routing. So > pci_subdevice_msi_create_irq_domain() works if the hypercalls > exist and fails if they don't. > > 3) SIOV sub device assigned to the guest. > > The difference between SIOV and SRIOV is the device must attach a > PASID to every TLP triggered by the guest. Logically we'd expect > when IMS is used in this situation the interrupt MemWr is tagged > with bus/device/function/PASID to uniquly ID the guest and the same > security protection scheme from #2 applies. Unfortunately no. Intel VT-d only treats MemWr w/o PASID to 0xFEEx as interrupt request. MemWr w/ PASID, even to 0xFEE, is translated normally through DMA remapping page table. I don't know other IOMMU vendors. But at least on Intel platform such device would not get the desired effect, since the IOMMU only guarantees interrupt isolation in BDF-level. Does your device already implement such capability? We can bring this request back to the hardware team. > > 4) SIOV sub device assigned to the guest, but with emulation. > > This SIOV device cannot tag interrupts with PASID so cannot do #2 > (or the platform cannot recieve a PASID tagged interrupt message). > > Since the interrupts are being delivered with TLPs pointing at the > hypervisor the only solution is for the hypervisor to exclusively > control the interrupt table. MSI table like emulation for IMS is > needed and the hypervisor will use > pci_subdevice_msi_create_irq_domain() > to get the real interrupts. > > pci_subdevice_msi_create_irq_domain() needs to return the 'fake' > addr/data pairs which are actually an ABI between the guest and > hypervisor carried in the hidden hypercall of the emulation. > (ie it works like MSI works today) > > IDXD is worring about case #4, I think, but I didn't follow in that > whole discussion about the IMS table layout if they PASID tag the IMS > MemWr or not?? Ashok can you clarify? > > > Is the IOMMU/Interrupt remapping unit able to catch such messages which > > go outside the space to which the guest is allowed to signal to? If yes, > > problem solved. If no, then IMS storage in guest memory can't ever work. > > Right. Only PASID on the interrupt messages can resolve this securely. > > > So in case that the HCALL domain is missing, the Vector domain needs > > return an error code on domain creation. If the HCALL domain is there > > then the domain creation works and in case of actual interrupt > > allocation the hypercall either returns a valid composed message or an > > appropriate error code. > > Yes > > > But there's a catch: > > > > This only works when the guest OS actually knows that it runs in a > > VM. If the guest can't figure that out, i.e. via CPUID, this cannot be > > solved because from the guest OS view that's the same as running on bare > > metal. Obviously on bare metal the Vector domain can and must handle > > this. > > Yes > > The flip side is today, the way pci_subdevice_msi_create_irq_domain() > works a VF using it on baremetal will succeed and if that same VF is > assigned to a guest then pci_subdevice_msi_create_irq_domain() > succeeds but the interrupt never comes - so the driver is broken. Yes, this is the main worry
Re: [PATCH] drm/msm: dsi: Constify dsi_host_ops
On Sun, Nov 08, 2020 at 11:37:38PM +0100, Rikard Falkeborn wrote: > The only usage of dsi_host_ops is to assign its address to the ops field > in the mipi_dsi_host struct, which is a const pointer. Make it const to > allow the compiler to put it in read-only memory. > > Signed-off-by: Rikard Falkeborn Reviewed-by: Sam Ravnborg With this patch all struct mipi_dsi_host_ops are const - good. I expect the msm folks to pick it up. Sam
Re: [PATCH] video: fbdev: riva: remove some unused varibles
Hi Alex, On Sun, Nov 08, 2020 at 04:01:59PM +0800, Alex Shi wrote: > Couple of variables are actually useless, remove them to save some gcc > warning: > drivers/video/fbdev/riva/riva_hw.c:250:21: warning: variable ‘mlwm’ set > but not used [-Wunused-but-set-variable] > drivers/video/fbdev/riva/riva_hw.c:665:15: warning: variable ‘vraw’ set > but not used [-Wunused-but-set-variable] > drivers/video/fbdev/riva/riva_hw.c:665:9: warning: variable ‘craw’ set > but not used [-Wunused-but-set-variable] > drivers/video/fbdev/riva/riva_hw.c:659:73: warning: variable ‘align’ set > but not used [-Wunused-but-set-variable] > drivers/video/fbdev/riva/riva_hw.c:659:50: warning: variable > ‘color_key_enable’ set but not used [-Wunused-but-set-variable] > > Signed-off-by: Alex Shi > Cc: Antonino Daplas > Cc: linux-fb...@vger.kernel.org > Cc: dri-de...@lists.freedesktop.org > Cc: linux-kernel@vger.kernel.org Thanks, applied to drm-misc-next. The fix will appear in -next in a week or so. Sam
[PATCH v8] hwmon:Driver for Delta power supplies Q54SJ108A2
From: "xiao.ma" The driver supports Q54SJ108A2 series modules of Delta. Standard attributes are in the sysfs, and other attributes are in the debugfs. Signed-off-by: xiao.ma --- Notes: Patch v2 changelog: Add delta.rst in Documentation/hwmon. Tristate "DELTA" in Kconfig is changed to "DELTA_POWER_SUPPLIED". Modify code: drop the excessive empty lines, correct the comment content, adjust indent, remove extra brackets. Patch v3 changelog: Add delta.rst to Documentation/hwmon/index.rst. Tristate "DELTA_POWER_SUPPLES" in Kconfig is changed to "Delta Power Supplies". Patch v4 changelog: Correct the spelling "Temperature" in the delta.rst. Add Write_protect when write command VOUT_OV_RESPONSE and IOUT_OC_FAULT_RESPONSE. Patch v5 changelog: Add some non-standard attributes in sysfs system. Patch v6 changelog: delta.c and delta.rst are renamed to q54sj108a2.c and q54sj108a2.rst. Add q54sj108a2 to index.rst. Tristate in Kconfig is changed to "Delta Power Supplies Q54SJ108A2". The non-standard attributes are added to debugfs. Patch v7 changelog: Use standard fuctions bin2hex and hex2bin. The return of debugfs write is changed to count. Drop the error checking of debugfs functions. Use probe_new fuction. Remove the .remove fuction. Patch v8 changelog: Use kstrtou8_from_user instead of hex2bin. Remove included head files which are not used. Done label in debugfs_read fuction is deleted. Change email to send the patch. Documentation/hwmon/index.rst | 1 + Documentation/hwmon/q54sj108a2.rst | 52 drivers/hwmon/pmbus/Kconfig| 9 + drivers/hwmon/pmbus/Makefile | 1 + drivers/hwmon/pmbus/q54sj108a2.c | 422 + 5 files changed, 485 insertions(+) create mode 100644 Documentation/hwmon/q54sj108a2.rst create mode 100755 drivers/hwmon/pmbus/q54sj108a2.c diff --git a/Documentation/hwmon/index.rst b/Documentation/hwmon/index.rst index b797db738225..4bb680b3c7ea 100644 --- a/Documentation/hwmon/index.rst +++ b/Documentation/hwmon/index.rst @@ -148,6 +148,7 @@ Hardware Monitoring Kernel Drivers powr1220 pxe1610 pwm-fan + q54sj108a2 raspberrypi-hwmon sch5627 sch5636 diff --git a/Documentation/hwmon/q54sj108a2.rst b/Documentation/hwmon/q54sj108a2.rst new file mode 100644 index ..a575bdfa7c18 --- /dev/null +++ b/Documentation/hwmon/q54sj108a2.rst @@ -0,0 +1,52 @@ +Kernel driver q54sj108a2 += + +Supported chips: + + * DELTA Q54SJ108A2NCAH, Q54SJ108A2NCDH, Q54SJ108A2NCPG, Q54SJ108A2NCPH + +Prefix: 'Q54SJ108A2' + +Addresses scanned: - + +Datasheet: https://filecenter.delta-china.com.cn/products/download/01/0102/datasheet/DS_Q54SJ108A2.pdf + +Authors: +Xiao.ma + + +Description +--- + +This driver implements support for DELTA Q54SJ108A2NCAH, Q54SJ108A2NCDH, +Q54SJ108A2NCPG, and Q54SJ108A2NCPH 1/4 Brick DC/DC Regulated Power Module +with PMBus support. + +The driver is a client driver to the core PMBus driver. +Please see Documentation/hwmon/pmbus.rst for details on PMBus client drivers. + + +Usage Notes +--- + +This driver does not auto-detect devices. You will have to instantiate the +devices explicitly. Please see Documentation/i2c/instantiating-devices.rst for +details. + + +Sysfs entries +- + += = == +curr1_alarm ROOutput current alarm +curr1_input ROOutput current +curr1_label RO'iout1' +in1_alarm ROInput voltage alarm +in1_input ROInput voltage +in1_label RO'vin' +in2_alarm ROOutput voltage alarm +in2_input ROOutput voltage +in2_label RO'vout1' +temp1_alarm ROTemperature alarm +temp1_input ROChip temperature += = == diff --git a/drivers/hwmon/pmbus/Kconfig b/drivers/hwmon/pmbus/Kconfig index a25faf69fce3..01de280820ee 100644 --- a/drivers/hwmon/pmbus/Kconfig +++ b/drivers/hwmon/pmbus/Kconfig @@ -229,6 +229,15 @@ config SENSORS_PXE1610 This driver can also be built as a module. If so, the module will be called pxe1610. +config SENSORS_Q54SJ108A2 + tristate "Delta Power Supplies Q54SJ108A2" + help + If you say yes here you get hardware monitoring support for Delta + Q54SJ108A2 series Power Supplies. + + This driver can also be built as a module. If so, the module will + be called q54sj108a2. + config SENSORS_TPS40422 tristate "TI TPS40422" help diff --git a/drivers/hwmon/pmbus/Makefile b/drivers/hwmon/pmbus/Makefile index 4c97ad0bd791..a50122cd455b 100644 ---
Re: [PATCH v1] ARM: vfp: Use long jump to fix THUMB2 kernel compilation error
On Tue, 3 Nov 2020 at 09:43, Dmitry Osipenko wrote: > > 03.11.2020 10:24, Ard Biesheuvel пишет: > > Still broken today > > > > https://kernelci.org/build/id/5fa0c1a74bdb1ea4063fe7e4/ > > Still broken today https://kernelci.org/build/id/5fa898baa00b5f3167db8857/ > > So the options are > > > > a) merge my patch that adds 2 bytes of opcode to the Thumb2 build > > b) merge Dmitry's patch that adds an unconditional literal load to all > > builds > > c) remove kernel mode handling from vfp_support_entry() [my other patch] > > d) move sections around so that vfp_kmode_exception is guaranteed to > > be in range. > > e) do nothing > > > > Given the lack of reports about this issue, it is pretty clear that > > few people use the Thumb2 build (which I find odd, tbh, since it > > really is much smaller). > > I waited for about a month, hoping that somebody will fix this problem > before bothering with bisection, which took quite some time and effort > because intermediate commits were broken, and then with creating and > sending a patch :) > > Thumb2 usually is untested by CI farms and in a case of personal use > it's easier to wait for a fix. Hence no much reports, I suppose. > > > However, that means that a) is a reasonable > > fix, since nobody will notice the potential performance hit either, > > and it can easily be backported to wherever the breakage was > > introduced. (Note that eff8728fe698, which created the problem is > > marked cc:stable itself). > > The performance argument is questionable to me, to be honest. In > practice the performance difference should be absolutely negligible for > either of the proposed options, it should stay in a noise even if > somebody thoroughly counting cycles, IMO. > > I'm still thinking that the best option will be to apply a). > Can we take that as an acked-by? > > Going forward, I can refine d) so that we can get rid of the kernel > > mode path entirely. > > And then improve it using d).
Re: [PATCH] checkpatch: add fix for BAD_SIGN_OFF
On 9/11/20 1:27 am, Joe Perches wrote:
> On Sun, 2020-11-08 at 19:13 +0530, Aditya Srivastava wrote:
>> Currently, checkpatch warns us if the author of the commit signs-off
>> as co-developed-by.
> []
>> A quick manual check found out that all fixes were correct in those
>> cases.
> []
>> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> []
>> @@ -2827,8 +2827,11 @@ sub process {
>> # Check Co-developed-by: immediately followed by Signed-off-by: with same
>> name and email
>> if ($sign_off =~ /^co-developed-by:$/i) {
>> if ($email eq $author) {
>> -WARN("BAD_SIGN_OFF",
>> - "Co-developed-by: should not be
>> used to attribute nominal patch author '$author'\n" . "$here\n" . $rawline);
>> +if (WARN("BAD_SIGN_OFF",
>> + "Co-developed-by: should not
>> be used to attribute nominal patch author '$author'\n" . "$here\n" .
>> $rawline) &&
>> +$fix) {
>> +fix_delete_line($fixlinenr,
>> $rawline);
>> +}
>> }
>> if (!defined $lines[$linenr]) {
>> WARN("BAD_SIGN_OFF",
>
> Looks OK to me.
>
> Another option might be to add a Signed-off-by: line derived from
> any "From:" line when:
>
> if ($is_patch && $has_commit_log && $chk_signoff) {
> if ($signoff == 0) {
> ERROR("MISSING_SIGN_OFF",
> "Missing Signed-off-by: line(s)\n");
>
> etc...
>
Yes, I just noticed. Thanks for the suggestion. Will do.
Thanks
Aditya
Re: [PATCH v14 10/13] KVM: x86: Enable CET virtualization for VMX and advertise CET to userspace
Hi Yang, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on tip/master] [also build test WARNING on linus/master v5.10-rc3 next-20201106] [cannot apply to vhost/linux-next kvm/linux-next linux/master] [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/Yang-Weijiang/Introduce-support-for-guest-CET-feature/20201106-090915 base: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 6f72faf4a32303c8bdc6491186b79391e9cf0c7e config: i386-randconfig-r022-20201109 (attached as .config) compiler: gcc-9 (Debian 9.3.0-15) 9.3.0 reproduce (this is a W=1 build): # https://github.com/0day-ci/linux/commit/34e06718bac59b9ecb835d2c4a04ae9378067819 git remote add linux-review https://github.com/0day-ci/linux git fetch --no-tags linux-review Yang-Weijiang/Introduce-support-for-guest-CET-feature/20201106-090915 git checkout 34e06718bac59b9ecb835d2c4a04ae9378067819 # save the attached .config to linux build tree make W=1 ARCH=i386 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 arch/x86/kvm/cpuid.h:5, from arch/x86/kvm/mmu.h:7, from arch/x86/kvm/x86.c:22: arch/x86/kvm/x86.h: In function 'kvm_cet_supported': arch/x86/kvm/x86.h:291:25: error: 'XFEATURE_MASK_CET_USER' undeclared (first use in this function); did you mean 'XFEATURE_MASK_SSE'? 291 | return supported_xss & XFEATURE_MASK_CET_USER; | ^~ | XFEATURE_MASK_SSE arch/x86/kvm/x86.h:291:25: note: each undeclared identifier is reported only once for each function it appears in In file included from include/linux/kvm_host.h:36, from arch/x86/kvm/x86.c:19: arch/x86/kvm/x86.c: At top level: arch/x86/include/asm/kvm_host.h:104:8: error: 'X86_CR4_CET' undeclared here (not in a function); did you mean 'X86_CR4_DE'? 104 | | X86_CR4_CET)) |^~~ arch/x86/kvm/x86.c:101:46: note: in expansion of macro 'CR4_RESERVED_BITS' 101 | static u64 __read_mostly cr4_reserved_bits = CR4_RESERVED_BITS; | ^ arch/x86/kvm/x86.c:1251:2: error: 'MSR_IA32_U_CET' undeclared here (not in a function); did you mean 'MSR_IA32_PMC0'? 1251 | MSR_IA32_U_CET, MSR_IA32_S_CET, MSR_IA32_INT_SSP_TAB, MSR_KVM_GUEST_SSP, | ^~ | MSR_IA32_PMC0 arch/x86/kvm/x86.c:1251:18: error: 'MSR_IA32_S_CET' undeclared here (not in a function); did you mean 'MSR_IA32_PMC0'? 1251 | MSR_IA32_U_CET, MSR_IA32_S_CET, MSR_IA32_INT_SSP_TAB, MSR_KVM_GUEST_SSP, | ^~ | MSR_IA32_PMC0 arch/x86/kvm/x86.c:1251:34: error: 'MSR_IA32_INT_SSP_TAB' undeclared here (not in a function) 1251 | MSR_IA32_U_CET, MSR_IA32_S_CET, MSR_IA32_INT_SSP_TAB, MSR_KVM_GUEST_SSP, | ^~~~ arch/x86/kvm/x86.c:1252:2: error: 'MSR_IA32_PL0_SSP' undeclared here (not in a function); did you mean 'MSR_IA32_MCG_ESP'? 1252 | MSR_IA32_PL0_SSP, MSR_IA32_PL1_SSP, MSR_IA32_PL2_SSP, MSR_IA32_PL3_SSP, | ^~~~ | MSR_IA32_MCG_ESP arch/x86/kvm/x86.c:1252:20: error: 'MSR_IA32_PL1_SSP' undeclared here (not in a function); did you mean 'MSR_IA32_MCG_ESP'? 1252 | MSR_IA32_PL0_SSP, MSR_IA32_PL1_SSP, MSR_IA32_PL2_SSP, MSR_IA32_PL3_SSP, |^~~~ |MSR_IA32_MCG_ESP arch/x86/kvm/x86.c:1252:38: error: 'MSR_IA32_PL2_SSP' undeclared here (not in a function); did you mean 'MSR_IA32_MCG_ESP'? 1252 | MSR_IA32_PL0_SSP, MSR_IA32_PL1_SSP, MSR_IA32_PL2_SSP, MSR_IA32_PL3_SSP, | ^~~~ | MSR_IA32_MCG_ESP arch/x86/kvm/x86.c:1252:56: error: 'MSR_IA32_PL3_SSP' undeclared here (not in a function); did you mean 'MSR_IA32_MCG_ESP'? 1252 | MSR_IA32_PL0_SSP, MSR_IA32_PL1_SSP, MSR_IA32_PL2_SSP, MSR_IA32_PL3_SSP, | ^~~~ | MSR_IA32_MCG_ESP arch/x86/kvm/x86.c: In function 'is_xsaves_msr': arch/x86/kvm/x86.c:3591:15: warning: comparison between pointer and integer 3591 | return index == MSR_IA32_U_CET || | ^~ arch/x86/kvm/x86.c:3592:16: warning: comparison between pointer and integer 3592 | (index >= MSR_IA32_PL0_SSP && index <= MSR_IA32_PL3_SSP);
Re: [PATCH v1] video: hyperv_fb: include vmalloc.h
Hi Olaf.
On Fri, Nov 06, 2020 at 07:39:41PM +0100, Olaf Hering wrote:
> hvfb_getmem uses vzalloc, therefore vmalloc.h should be included.
>
> Fixes commit d21987d709e807ba7bbf47044deb56a3c02e8be4 ("video: hyperv:
> hyperv_fb: Support deferred IO for Hyper-V frame buffer driver")
>
> Signed-off-by: Olaf Hering
Thanks.
Applied to drm-misc-fixes - as it smells like a build fix in some
configurations.
Sam
linux-next: Tree for Nov 9
Hi all, Changes since 20201106: The drivers-memory tree gained a build failure for which I applied a patch. The mfd tree lost its build failure. The tip tree gained conflicts against the block tree. The akpm-current tree gained a conflict against the tip tree. Non-merge commits (relative to Linus' tree): 3825 4227 files changed, 411869 insertions(+), 68215 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc and sparc64 defconfig and htmldocs. And finally, a simple boot test of the powerpc pseries_le_defconfig kernel in qemu (with and without kvm enabled). Below is a summary of the state of the merge. I am currently merging 326 trees (counting Linus' and 85 trees of bug fix patches pending for the current merge release). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (15f5d201c177 Merge tag 'driver-core-5.10-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core) Merging fixes/fixes (9123e3a74ec7 Linux 5.9-rc1) Merging kbuild-current/fixes (d1889589a4f5 builddeb: Fix rootless build in setuid/setgid directory) Merging arc-current/for-curr (3b57533b460c ARC: [plat-hsdk] Remap CCMs super early in asm boot trampoline) Merging arm-current/fixes (9fa2e7af3d53 ARM: 9019/1: kprobes: Avoid fortify_panic() when copying optprobe template) Merging arm64-fixes/for-next/fixes (108aa503657e arm64: kexec_file: try more regions if loading segments fails) Merging arm-soc-fixes/arm/fixes (3d696f42c7f4 soc: ti: ti_sci_pm_domains: check for proper args count in xlate) Merging drivers-memory-fixes/fixes (3650b228f83a Linux 5.10-rc1) Merging m68k-current/for-linus (50c5feeea0af ide/macide: Convert Mac IDE driver to platform driver) Merging powerpc-fixes/fixes (01776f070ffc powerpc/32s: Use relocation offset when setting early hash table) Merging s390-fixes/fixes (0b2ca2c7d0c9 s390/pci: fix hot-plug of PCI function missing bus) Merging sparc/master (0a95a6d1a4cd sparc: use for_each_child_of_node() macro) Merging fscrypt-current/for-stable (92cfcd030e4b fscrypt: remove reachable WARN in fscrypt_setup_iv_ino_lblk_32_key()) Merging net/master (4e0396c59559 net: marvell: prestera: fix compilation with CONFIG_BRIDGE=m) Merging bpf/master (86bbf01977b4 Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf) Merging ipsec/master (a779d91314ca net: xfrm: fix a race condition during allocing spi) Merging netfilter/master (fea07a487c6d net: openvswitch: silence suspicious RCU usage warning) Merging ipvs/master (fea07a487c6d net: openvswitch: silence suspicious RCU usage warning) Merging wireless-drivers/master (d85b4b2bf2d4 MAINTAINERS: update maintainers list for Cypress) Merging mac80211/master (2aaf09a0e784 r8169: work around short packet hw bug on RTL8125) Merging rdma-fixes/for-rc (21fcdeec09ff RDMA/srpt: Fix typo in srpt_unregister_mad_agent docstring) Merging sound-current/for-linus (446b8185f0c3 ALSA: hda/realtek - Add supported for Lenovo ThinkPad Headset Button) Merging sound-asoc-fixes/for-linus (e12790cadfdd Merge remote-tracking branch 'asoc/for-5.10' into asoc-linus) Merging regmap-fixes/for-linus (780f88b04704 Merge remote-tracking branch 'regmap/for-5.10' into regmap-linus) Merging regulator-fixes/for-linus (cf1ad559a20d regulator: defer probe when trying to get voltage from unresolved supply) Merging spi-fixes/for-linus (ce6f3a0f9c85 Merge remote-tracking branch 'spi/for-5.10' into spi-linus) Merging pci-current/for-linus (832ea234277a PCI: mvebu: Fix duplicate resource requests) Merging driver-core.current/driver-core-linus (d181bfe36715
Re: [PATCH] drm/panel: simple: Add flags to boe_nv133fhm_n61
Hi Stephen
On Fri, Nov 06, 2020 at 10:23:33AM -0800, Stephen Boyd wrote:
> Reading the EDID of this panel shows that these flags should be set. Set
> them so that we match what is in the EDID.
>
> Cc: Douglas Anderson
> Cc: Bjorn Andersson
> Fixes: b0c664cc80e8 ("panel: simple: Add BOE NV133FHM-N61")
> Signed-off-by: Stephen Boyd
Applied to drm-misc-next as I could not see this was needed in mainline.
Or at least not urgently.
Let me know if this should be expeditet to current -rc
Sam
[PATCH] sysctl: move local variable in proc_do_large_bitmap() to proper scope
make clang-analyzer caught my attention with:
kernel/sysctl.c:1511:4: warning: Value stored to 'first' is never read \
[clang-analyzer-deadcode.DeadStores]
first = 0;
^
Commit 9f977fb7ae9d ("sysctl: add proc_do_large_bitmap") introduced
proc_do_large_bitmap(), where the variable first is only effectively used
when write is false; when write is true, the variable first is only used in
a dead assignment.
So, simply remove this dead assignment and put the variable in local scope.
As compilers will detect this unneeded assignment and optimize this anyway,
the resulting object code is identical before and after this change.
No functional change. No change to object code.
Signed-off-by: Lukas Bulwahn
---
applies cleanly on v5.10-rc3 and next-20201106
Luis, Kees, Iurii, please pick this minor non-urgent clean-up patch.
kernel/sysctl.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index ce75c67572b9..cc274a431d91 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -1423,7 +1423,6 @@ int proc_do_large_bitmap(struct ctl_table *table, int
write,
void *buffer, size_t *lenp, loff_t *ppos)
{
int err = 0;
- bool first = 1;
size_t left = *lenp;
unsigned long bitmap_len = table->maxlen;
unsigned long *bitmap = *(unsigned long **) table->data;
@@ -1508,12 +1507,12 @@ int proc_do_large_bitmap(struct ctl_table *table, int
write,
}
bitmap_set(tmp_bitmap, val_a, val_b - val_a + 1);
- first = 0;
proc_skip_char(, , '\n');
}
left += skipped;
} else {
unsigned long bit_a, bit_b = 0;
+ bool first = 1;
while (left) {
bit_a = find_next_bit(bitmap, bitmap_len, bit_b);
--
2.17.1
Re: [PATCH 8/8] acpi: fix NONE coordination for domain mapping failure
On 05-11-20, 12:55, Ionela Voinescu wrote:
> For errors parsing the _PSD domains, a separate domain is returned for
> each CPU in the failed _PSD domain with no coordination (as per previous
> comment). But contrary to the intention, the code was setting
> CPUFREQ_SHARED_TYPE_ALL as coordination type.
>
> Change shared_type to CPUFREQ_SHARED_TYPE_NONE in case of errors parsing
> the domain information. The function still return the error and the caller
> is free to bail out the domain initialisation altogether in that case.
>
> Given that both functions return domains with a single CPU, this change
> does not affect the functionality, but clarifies the intention.
>
> Signed-off-by: Ionela Voinescu
> Cc: Rafael J. Wysocki
> Cc: Len Brown
> Cc: Viresh Kumar
> ---
> drivers/acpi/cppc_acpi.c | 2 +-
> drivers/acpi/processor_perflib.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/acpi/cppc_acpi.c b/drivers/acpi/cppc_acpi.c
> index 75e36b909ae6..e1e46cc66eeb 100644
> --- a/drivers/acpi/cppc_acpi.c
> +++ b/drivers/acpi/cppc_acpi.c
> @@ -477,7 +477,7 @@ int acpi_get_psd_map(unsigned int cpu, struct psd_data
> *domain)
> /* Assume no coordination on any error parsing domain info */
> cpumask_clear(domain->shared_cpu_map);
> cpumask_set_cpu(cpu, domain->shared_cpu_map);
> - domain->shared_type = CPUFREQ_SHARED_TYPE_ALL;
> + domain->shared_type = CPUFREQ_SHARED_TYPE_NONE;
>
> return -EFAULT;
> }
> diff --git a/drivers/acpi/processor_perflib.c
> b/drivers/acpi/processor_perflib.c
> index 5909e8fa4013..5ce638537791 100644
> --- a/drivers/acpi/processor_perflib.c
> +++ b/drivers/acpi/processor_perflib.c
> @@ -710,7 +710,7 @@ int acpi_processor_preregister_performance(
> if (retval) {
> cpumask_clear(pr->performance->shared_cpu_map);
> cpumask_set_cpu(i, pr->performance->shared_cpu_map);
> - pr->performance->shared_type = CPUFREQ_SHARED_TYPE_ALL;
> + pr->performance->shared_type = CPUFREQ_SHARED_TYPE_NONE;
> }
> pr->performance = NULL; /* Will be set for real in register */
> }
Acked-by: Viresh Kumar
--
viresh
Re: [PATCH 7/8] cppc_cpufreq: expose information on frequency domains
On 05-11-20, 12:55, Ionela Voinescu wrote:
> Use the existing sysfs attribute "freqdomain_cpus" to expose
> information to userspace about CPUs in the same frequency domain.
>
> Signed-off-by: Ionela Voinescu
> Cc: Rafael J. Wysocki
> Cc: Viresh Kumar
> ---
> Documentation/ABI/testing/sysfs-devices-system-cpu | 3 ++-
> drivers/cpufreq/cppc_cpufreq.c | 14 ++
> 2 files changed, 16 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/ABI/testing/sysfs-devices-system-cpu
> b/Documentation/ABI/testing/sysfs-devices-system-cpu
> index 1a04ca8162ad..0eee30b27ab6 100644
> --- a/Documentation/ABI/testing/sysfs-devices-system-cpu
> +++ b/Documentation/ABI/testing/sysfs-devices-system-cpu
> @@ -264,7 +264,8 @@ Description: Discover CPUs in the same CPU frequency
> coordination domain
> attribute is useful for user space DVFS controllers to get
> better
> power/performance results for platforms using acpi-cpufreq.
>
> - This file is only present if the acpi-cpufreq driver is in use.
> + This file is only present if the acpi-cpufreq or the
> cppc-cpufreq
> + drivers are in use.
>
>
> What:
> /sys/devices/system/cpu/cpu*/cache/index3/cache_disable_{0,1}
> diff --git a/drivers/cpufreq/cppc_cpufreq.c b/drivers/cpufreq/cppc_cpufreq.c
> index 60ac7f8049b5..b4edeeb57d04 100644
> --- a/drivers/cpufreq/cppc_cpufreq.c
> +++ b/drivers/cpufreq/cppc_cpufreq.c
> @@ -483,6 +483,19 @@ static int cppc_cpufreq_set_boost(struct cpufreq_policy
> *policy, int state)
> return 0;
> }
>
> +static ssize_t show_freqdomain_cpus(struct cpufreq_policy *policy, char *buf)
> +{
> + struct cppc_cpudata *cpu_data = policy->driver_data;
> +
> + return cpufreq_show_cpus(cpu_data->domain->shared_cpu_map, buf);
> +}
> +cpufreq_freq_attr_ro(freqdomain_cpus);
> +
> +static struct freq_attr *cppc_cpufreq_attr[] = {
> + _cpus,
> + NULL,
> +};
> +
> static struct cpufreq_driver cppc_cpufreq_driver = {
> .flags = CPUFREQ_CONST_LOOPS,
> .verify = cppc_verify_policy,
> @@ -491,6 +504,7 @@ static struct cpufreq_driver cppc_cpufreq_driver = {
> .init = cppc_cpufreq_cpu_init,
> .stop_cpu = cppc_cpufreq_stop_cpu,
> .set_boost = cppc_cpufreq_set_boost,
> + .attr = cppc_cpufreq_attr,
> .name = "cppc_cpufreq",
> };
Acked-by: Viresh Kumar
--
viresh
Re: [PATCH] net/mlx4: Assign boolean values to a bool variable
On 2020/11/8 16:20, Tariq Toukan wrote: > > > On 11/7/2020 8:53 AM, xiakaixu1...@gmail.com wrote: >> From: Kaixu Xia >> >> Fix the following coccinelle warnings: >> > > Hi Kaixu, > > Which coccinelle version gave this warning? Hi Tariq, The version is coccinelle-1.0.7. Thanks, Kaixu > > >> ./drivers/net/ethernet/mellanox/mlx4/en_rx.c:687:1-17: WARNING: Assignment >> of 0/1 to bool variable >> >> Reported-by: Tosk Robot >> Signed-off-by: Kaixu Xia >> --- >> drivers/net/ethernet/mellanox/mlx4/en_rx.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/drivers/net/ethernet/mellanox/mlx4/en_rx.c >> b/drivers/net/ethernet/mellanox/mlx4/en_rx.c >> index 502d1b97855c..b0f79a5151cf 100644 >> --- a/drivers/net/ethernet/mellanox/mlx4/en_rx.c >> +++ b/drivers/net/ethernet/mellanox/mlx4/en_rx.c >> @@ -684,7 +684,7 @@ int mlx4_en_process_rx_cq(struct net_device *dev, struct >> mlx4_en_cq *cq, int bud >> xdp_prog = rcu_dereference(ring->xdp_prog); >> xdp.rxq = >xdp_rxq; >> xdp.frame_sz = priv->frag_info[0].frag_stride; >> - doorbell_pending = 0; >> + doorbell_pending = false; >> /* We assume a 1:1 mapping between CQEs and Rx descriptors, so Rx >> * descriptor offset can be deduced from the CQE index instead of >> > -- kaixuxia
Re: [PATCH 6/8] cppc_cpufreq: clarify support for coordination types
On 05-11-20, 12:55, Ionela Voinescu wrote:
> The previous coordination type handling in the cppc_cpufreq init code
> created some confusion: the comment mentioned "Support only SW_ANY for
> now" while only the SW_ALL/ALL case resulted in a failure. The other
> coordination types (HW_ALL/HW, NONE) were silently supported.
>
> Clarify support for coordination types while describing in comments the
> intended behavior.
>
> Signed-off-by: Ionela Voinescu
> Cc: Rafael J. Wysocki
> Cc: Viresh Kumar
> ---
> drivers/cpufreq/cppc_cpufreq.c | 19 +++
> 1 file changed, 15 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/cpufreq/cppc_cpufreq.c b/drivers/cpufreq/cppc_cpufreq.c
> index fd2daeb59b49..60ac7f8049b5 100644
> --- a/drivers/cpufreq/cppc_cpufreq.c
> +++ b/drivers/cpufreq/cppc_cpufreq.c
> @@ -363,11 +363,22 @@ static int cppc_cpufreq_cpu_init(struct cpufreq_policy
> *policy)
> policy->transition_delay_us = cppc_cpufreq_get_transition_delay_us(cpu);
> policy->shared_type = domain->shared_type;
>
> - if (policy->shared_type == CPUFREQ_SHARED_TYPE_ANY) {
> + switch (policy->shared_type) {
> + case CPUFREQ_SHARED_TYPE_HW:
> + case CPUFREQ_SHARED_TYPE_NONE:
> + /* Nothing to be done - we'll have a policy for each CPU */
> + break;
> + case CPUFREQ_SHARED_TYPE_ANY:
> + /*
> + * All CPUs in the domain will share a policy and all cpufreq
> + * operations will use a single cppc_cpudata structure stored
> + * in policy->driver_data.
> + */
> cpumask_copy(policy->cpus, domain->shared_cpu_map);
> - } else if (policy->shared_type == CPUFREQ_SHARED_TYPE_ALL) {
> - /* Support only SW_ANY for now. */
> - pr_debug("Unsupported CPU co-ord type\n");
> + break;
> + default:
> + pr_info("Unsupported cpufreq CPU co-ord type: %d\n",
> + policy->shared_type);
> return -EFAULT;
> }
>
Acked-by: Viresh Kumar
--
viresh
Re: [PATCH 5/8] cppc_cpufreq: use policy->cpu as driver of frequency setting
On 05-11-20, 12:55, Ionela Voinescu wrote:
> Considering only the currently supported coordination types (ANY, HW,
> NONE), this change only makes a difference for the ANY type, when
> policy->cpu is hotplugged out. In that case the new policy->cpu will
> be different from ((struct cppc_cpudata *)policy->driver_data)->cpu.
>
> While in this case the controls of *ANY* CPU could be used to drive
> frequency changes, it's more consistent to use policy->cpu as the
> leading CPU, as used in all other cppc_cpufreq functions. Additionally,
> the debug prints in cppc_set_perf() would no longer create confusion
> when referring to a CPU that is hotplugged out.
>
> Signed-off-by: Ionela Voinescu
> Cc: Rafael J. Wysocki
> Cc: Viresh Kumar
> ---
> drivers/cpufreq/cppc_cpufreq.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/cpufreq/cppc_cpufreq.c b/drivers/cpufreq/cppc_cpufreq.c
> index ac95b4424a2e..fd2daeb59b49 100644
> --- a/drivers/cpufreq/cppc_cpufreq.c
> +++ b/drivers/cpufreq/cppc_cpufreq.c
> @@ -150,6 +150,7 @@ static int cppc_cpufreq_set_target(struct cpufreq_policy
> *policy,
>
> {
> struct cppc_cpudata *cpu_data = policy->driver_data;
> + unsigned int cpu = policy->cpu;
> struct cpufreq_freqs freqs;
> u32 desired_perf;
> int ret = 0;
> @@ -164,12 +165,12 @@ static int cppc_cpufreq_set_target(struct
> cpufreq_policy *policy,
> freqs.new = target_freq;
>
> cpufreq_freq_transition_begin(policy, );
> - ret = cppc_set_perf(cpu_data->cpu, _data->perf_ctrls);
> + ret = cppc_set_perf(cpu, _data->perf_ctrls);
> cpufreq_freq_transition_end(policy, , ret != 0);
>
> if (ret)
> pr_debug("Failed to set target on CPU:%d. ret:%d\n",
> - cpu_data->cpu, ret);
> + cpu, ret);
>
> return ret;
> }
Acked-by: Viresh Kumar
--
viresh
[PATCH] net: sched: fix misspellings using misspell-fixer tool
From: Menglong Dong
Some typos are found out by misspell-fixer tool:
$ misspell-fixer -rnv ./net/sched/
./net/sched/act_api.c:686
./net/sched/act_bpf.c:68
./net/sched/cls_rsvp.h:241
./net/sched/em_cmp.c:44
./net/sched/sch_pie.c:408
Fix typos found by misspell-fixer.
Signed-off-by: Menglong Dong
---
net/sched/act_api.c | 2 +-
net/sched/act_bpf.c | 2 +-
net/sched/cls_rsvp.h | 2 +-
net/sched/em_cmp.c | 2 +-
net/sched/sch_pie.c | 2 +-
5 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/net/sched/act_api.c b/net/sched/act_api.c
index 1341c59c2f40..60e1572ba606 100644
--- a/net/sched/act_api.c
+++ b/net/sched/act_api.c
@@ -683,7 +683,7 @@ static struct tc_action_ops *tc_lookup_action(struct nlattr
*kind)
return res;
}
-/*TCA_ACT_MAX_PRIO is 32, there count upto 32 */
+/*TCA_ACT_MAX_PRIO is 32, there count up to 32 */
#define TCA_ACT_MAX_PRIO_MASK 0x1FF
int tcf_action_exec(struct sk_buff *skb, struct tc_action **actions,
int nr_actions, struct tcf_result *res)
diff --git a/net/sched/act_bpf.c b/net/sched/act_bpf.c
index a4c7ba35a343..e48e980c3b93 100644
--- a/net/sched/act_bpf.c
+++ b/net/sched/act_bpf.c
@@ -65,7 +65,7 @@ static int tcf_bpf_act(struct sk_buff *skb, const struct
tc_action *act,
* In case a different well-known TC_ACT opcode has been
* returned, it will overwrite the default one.
*
-* For everything else that is unkown, TC_ACT_UNSPEC is
+* For everything else that is unknown, TC_ACT_UNSPEC is
* returned.
*/
switch (filter_res) {
diff --git a/net/sched/cls_rsvp.h b/net/sched/cls_rsvp.h
index d36949d9382c..2e288f88ff02 100644
--- a/net/sched/cls_rsvp.h
+++ b/net/sched/cls_rsvp.h
@@ -238,7 +238,7 @@ static void rsvp_replace(struct tcf_proto *tp, struct
rsvp_filter *n, u32 h)
}
}
- /* Something went wrong if we are trying to replace a non-existant
+ /* Something went wrong if we are trying to replace a non-existent
* node. Mind as well halt instead of silently failing.
*/
BUG_ON(1);
diff --git a/net/sched/em_cmp.c b/net/sched/em_cmp.c
index a4d09b1fb66a..f17b049ea530 100644
--- a/net/sched/em_cmp.c
+++ b/net/sched/em_cmp.c
@@ -41,7 +41,7 @@ static int em_cmp_match(struct sk_buff *skb, struct
tcf_ematch *em,
break;
case TCF_EM_ALIGN_U32:
- /* Worth checking boundries? The branching seems
+ /* Worth checking boundaries? The branching seems
* to get worse. Visit again.
*/
val = get_unaligned_be32(ptr);
diff --git a/net/sched/sch_pie.c b/net/sched/sch_pie.c
index c65077f0c0f3..5a457ff61acd 100644
--- a/net/sched/sch_pie.c
+++ b/net/sched/sch_pie.c
@@ -405,7 +405,7 @@ void pie_calculate_probability(struct pie_params *params,
struct pie_vars *vars,
/* We restart the measurement cycle if the following conditions are met
* 1. If the delay has been low for 2 consecutive Tupdate periods
* 2. Calculated drop probability is zero
-* 3. If average dq_rate_estimator is enabled, we have atleast one
+* 3. If average dq_rate_estimator is enabled, we have at least one
*estimate for the avg_dq_rate ie., is a non-zero value
*/
if ((vars->qdelay < params->target / 2) &&
--
2.25.1
Re: [PATCH 3/8] cppc_cpufreq: simplify use of performance capabilities
On 05-11-20, 12:55, Ionela Voinescu wrote: > The CPPC performance capabilities are used significantly throughout > the driver. Simplify the use of them by introducing a local pointer > "caps" to point to cpu_data->perf_caps, in functions that access > performance capabilities often. > > Signed-off-by: Ionela Voinescu > Cc: Rafael J. Wysocki > Cc: Viresh Kumar > --- > drivers/cpufreq/cppc_cpufreq.c | 40 +++--- > 1 file changed, 23 insertions(+), 17 deletions(-) Acked-by: Viresh Kumar -- viresh
[PATCH bpf] tools: bpftool: Add missing close before bpftool net attach exit
progfd is created by prog_parse_fd(), before 'bpftool net attach' exit,
it should be closed.
Fixes: 04949ccc273e ("tools: bpftool: add net attach command to attach XDP on
interface")
Signed-off-by: Wang Hai
---
tools/bpf/bpftool/net.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tools/bpf/bpftool/net.c b/tools/bpf/bpftool/net.c
index 910e7bac6e9e..3e9b40e64fb0 100644
--- a/tools/bpf/bpftool/net.c
+++ b/tools/bpf/bpftool/net.c
@@ -600,12 +600,14 @@ static int do_attach(int argc, char **argv)
if (err < 0) {
p_err("interface %s attach failed: %s",
attach_type_strings[attach_type], strerror(-err));
+ close(progfd);
return err;
}
if (json_output)
jsonw_null(json_wtr);
+ close(progfd);
return 0;
}
--
2.17.1
Re: [PATCH 2/8] cppc_cpufreq: clean up cpu, cpu_num and cpunum variable use
On 05-11-20, 12:55, Ionela Voinescu wrote: > In order to maintain the typical naming convention in the cpufreq > framework: > - replace the use of "cpu" variable name for cppc_cpudata pointers >with "cpu_data" > - replace variable names "cpu_num" and "cpunum" with "cpu" > - make cpu variables unsigned int > > Where pertinent, also move the initialisation of cpu_data variable to > its declaration and make consistent use of the local "cpu" variable. > > Signed-off-by: Ionela Voinescu > Cc: Rafael J. Wysocki > Cc: Viresh Kumar > --- > drivers/cpufreq/cppc_cpufreq.c | 143 - > 1 file changed, 69 insertions(+), 74 deletions(-) Acked-by: Viresh Kumar -- viresh
Re: [PATCH 1/8] cppc_cpufreq: fix misspelling, code style and readability issues
On 05-11-20, 12:55, Ionela Voinescu wrote: > Fix a few trivial issues in the cppc_cpufreq driver: > > - indentation of function arguments > - consistent use of tabs (vs space) in defines > - spelling: s/Offest/Offset, s/trasition/transition > - order of local variables, from long pointers to structures to >short ret and i (index) variables, to improve readability > > Signed-off-by: Ionela Voinescu > Cc: Rafael J. Wysocki > Cc: Viresh Kumar > --- > drivers/cpufreq/cppc_cpufreq.c | 32 > 1 file changed, 16 insertions(+), 16 deletions(-) Acked-by: Viresh Kumar -- viresh
Re: [PATCH v3 3/3] [RFC] CPUFreq: Add support for cpu-perf-dependencies
On 06-11-20, 11:14, Lukasz Luba wrote: > I also had similar doubts, because if we make frequency requests > independently for each CPU, why not having N cooling devs, which > will set independently QoS max freq for them... > > What convinced me: > EAS and FIE would know the 'real' frequency of the cluster, IPA > can use it also and have only one cooling device per cluster. > > We would like to keep this old style 'one cooling device per cpuset'. > I don't have strong opinion and if it would appear that there are > some errors in freq estimation for cluster, then maybe it does make > more sense to have cdev per CPU... Let me rephrase my question. What is it that doesn't work _correctly_ with cdev per cpufreq policy in your case? What doesn't work well if the thermal stuff keeps looking at only the related_cpus thing and not the cpu-perf-dependencies thing? -- viresh
[RESEND PATCH v2] net/x25: Fix null-ptr-deref in x25_connect
This fixes a regression for blocking connects introduced by commit
4becb7ee5b3d ("net/x25: Fix x25_neigh refcnt leak when x25 disconnect").
The x25->neighbour is already set to "NULL" by x25_disconnect() now,
while a blocking connect is waiting in
x25_wait_for_connection_establishment(). Therefore x25->neighbour must
not be accessed here again and x25->state is also already set to
X25_STATE_0 by x25_disconnect().
Fixes: 4becb7ee5b3d ("net/x25: Fix x25_neigh refcnt leak when x25 disconnect")
Signed-off-by: Martin Schiller
---
Change from v1:
also handle interrupting signals correctly
---
net/x25/af_x25.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/x25/af_x25.c b/net/x25/af_x25.c
index 0bbb283f23c9..046d3fee66a9 100644
--- a/net/x25/af_x25.c
+++ b/net/x25/af_x25.c
@@ -825,7 +825,7 @@ static int x25_connect(struct socket *sock, struct sockaddr
*uaddr,
sock->state = SS_CONNECTED;
rc = 0;
out_put_neigh:
- if (rc) {
+ if (rc && x25->neighbour) {
read_lock_bh(_list_lock);
x25_neigh_put(x25->neighbour);
x25->neighbour = NULL;
--
2.20.1
net/ipv6/ip6mr.c:1837:13: sparse: sparse: incorrect type in argument 1 (different address spaces)
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: f8394f232b1eab649ce2df5c5f15b0e528c92091
commit: e5fc436f06eef54ef512ea55a9db8eb9f2e76959 sparse: use static inline for
__chk_{user,io}_ptr()
date: 2 months ago
config: sh-randconfig-s032-20201103 (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 >>)"
net/ipv6/ip6mr.c:1837:13: sparse: sparse: incorrect type in initializer
(different address spaces) @@ expected int const *__gu_addr @@ got int
[noderef] __user *optlen @@
net/ipv6/ip6mr.c:1837:13: sparse: expected int const *__gu_addr
net/ipv6/ip6mr.c:1837:13: sparse: got int [noderef] __user *optlen
>> net/ipv6/ip6mr.c:1837:13: sparse: sparse: incorrect type in argument 1
>> (different address spaces) @@ expected void const volatile [noderef]
>> __user *ptr @@ got int const *__gu_addr @@
>> net/ipv6/ip6mr.c:1837:13: sparse: expected void const volatile [noderef]
>> __user *ptr
net/ipv6/ip6mr.c:1837:13: sparse: got int const *__gu_addr
net/ipv6/ip6mr.c:405:13: sparse: sparse: context imbalance in
'ip6mr_vif_seq_start' - different lock contexts for basic block
net/ipv6/ip6mr.c: note: in included file (through include/linux/mroute6.h):
include/linux/mroute_base.h:427:31: sparse: sparse: context imbalance in
'mr_mfc_seq_stop' - unexpected unlock
--
net/atm/common.c:795:13: sparse: sparse: incorrect type in initializer
(different address spaces) @@ expected int const *__gu_addr @@ got int
[noderef] __user *optlen @@
net/atm/common.c:795:13: sparse: expected int const *__gu_addr
net/atm/common.c:795:13: sparse: got int [noderef] __user *optlen
>> net/atm/common.c:795:13: sparse: sparse: incorrect type in argument 1
>> (different address spaces) @@ expected void const volatile [noderef]
>> __user *ptr @@ got int const *__gu_addr @@
>> net/atm/common.c:795:13: sparse: expected void const volatile [noderef]
>> __user *ptr
net/atm/common.c:795:13: sparse: got int const *__gu_addr
--
net/atm/resources.c:203:13: sparse: sparse: incorrect type in initializer
(different address spaces) @@ expected int const *__gu_addr @@ got int
[noderef] __user *iobuf_len @@
net/atm/resources.c:203:13: sparse: expected int const *__gu_addr
net/atm/resources.c:203:13: sparse: got int [noderef] __user *iobuf_len
>> net/atm/resources.c:203:13: sparse: sparse: incorrect type in argument 1
>> (different address spaces) @@ expected void const volatile [noderef]
>> __user *ptr @@ got int const *__gu_addr @@
>> net/atm/resources.c:203:13: sparse: expected void const volatile
>> [noderef] __user *ptr
net/atm/resources.c:203:13: sparse: got int const *__gu_addr
net/atm/resources.c:236:13: sparse: sparse: incorrect type in initializer
(different address spaces) @@ expected int const *__gu_addr @@ got int
[noderef] __user *sioc_len @@
net/atm/resources.c:236:13: sparse: expected int const *__gu_addr
net/atm/resources.c:236:13: sparse: got int [noderef] __user *sioc_len
net/atm/resources.c:236:13: sparse: sparse: incorrect type in argument 1
(different address spaces) @@ expected void const volatile [noderef] __user
*ptr @@ got int const *__gu_addr @@
net/atm/resources.c:236:13: sparse: expected void const volatile
[noderef] __user *ptr
net/atm/resources.c:236:13: sparse: got int const *__gu_addr
--
drivers/usb/class/usbtmc.c:584:13: sparse: sparse: incorrect type in
initializer (different address spaces) @@ expected unsigned int const
*__gu_addr @@ got unsigned int [noderef] [usertype] __user *arg @@
drivers/usb/class/usbtmc.c:584:13: sparse: expected unsigned int const
*__gu_addr
drivers/usb/class/usbtmc.c:584:13: sparse: got unsigned int [noderef]
[usertype] __user *arg
>> drivers/usb/class/usbtmc.c:584:13: sparse: sparse: incorrect type in
>> argument 1 (different address spaces) @@ expected void const volatile
>> [noderef] __user *ptr @@ got unsigned int const *__gu_addr @@
RE: [PATCH] samples/bpf: remove duplicate include
menglong8.dong@ wrote: > From: Menglong Dong > > Obviously, 'bpf/bpf.h' in 'samples/bpf/hbm.c' is duplicated. > > Signed-off-by: Menglong Dong > --- Acked-by: John Fastabend
Re: [PATCH v6 1/2] kunit: Support for Parameterized Testing
On 07/11/20 3:36 pm, Marco Elver wrote:
> On Sat, 7 Nov 2020 at 05:58, David Gow wrote:
>> On Sat, Nov 7, 2020 at 3:22 AM Arpitha Raghunandan <98.a...@gmail.com> wrote:
>>>
>>> Implementation of support for parameterized testing in KUnit.
>>> This approach requires the creation of a test case using the
>>> KUNIT_CASE_PARAM macro that accepts a generator function as input.
>>> This generator function should return the next parameter given the
>>> previous parameter in parameterized tests. It also provides
>>> a macro to generate common-case generators.
>>>
>>> Signed-off-by: Arpitha Raghunandan <98.a...@gmail.com>
>>> Co-developed-by: Marco Elver
>>> Signed-off-by: Marco Elver
>>> ---
>>
>> This looks good to me! A couple of minor thoughts about the output
>> format below, but I'm quite happy to have this as-is regardless.
>>
>> Reviewed-by: David Gow
>>
>> Cheers,
>> -- David
>>
>>> Changes v5->v6:
>>> - Fix alignment to maintain consistency
>>> Changes v4->v5:
>>> - Update kernel-doc comments.
>>> - Use const void* for generator return and prev value types.
>>> - Add kernel-doc comment for KUNIT_ARRAY_PARAM.
>>> - Rework parameterized test case execution strategy: each parameter is
>>> executed
>>> as if it was its own test case, with its own test initialization and
>>> cleanup
>>> (init and exit are called, etc.). However, we cannot add new test cases
>>> per TAP
>>> protocol once we have already started execution. Instead, log the result
>>> of
>>> each parameter run as a diagnostic comment.
>>> Changes v3->v4:
>>> - Rename kunit variables
>>> - Rename generator function helper macro
>>> - Add documentation for generator approach
>>> - Display test case name in case of failure along with param index
>>> Changes v2->v3:
>>> - Modifictaion of generator macro and method
>>> Changes v1->v2:
>>> - Use of a generator method to access test case parameters
>>>
>>> include/kunit/test.h | 36 ++
>>> lib/kunit/test.c | 46 +++-
>>> 2 files changed, 69 insertions(+), 13 deletions(-)
>>>
>>> diff --git a/include/kunit/test.h b/include/kunit/test.h
>>> index db1b0ae666c4..16616d3974f9 100644
>>> --- a/include/kunit/test.h
>>> +++ b/include/kunit/test.h
>>> @@ -107,6 +107,7 @@ struct kunit;
> [...]
>>> - kunit_suite_for_each_test_case(suite, test_case)
>>> - kunit_run_case_catch_errors(suite, test_case);
>>> + kunit_suite_for_each_test_case(suite, test_case) {
>>> + struct kunit test = { .param_value = NULL, .param_index = 0
>>> };
>>> + bool test_success = true;
>>> +
>>> + if (test_case->generate_params)
>>> + test.param_value = test_case->generate_params(NULL);
>>> +
>>> + do {
>>> + kunit_run_case_catch_errors(suite, test_case,
>>> );
>>> + test_success &= test_case->success;
>>> +
>>> + if (test_case->generate_params) {
>>> + kunit_log(KERN_INFO, ,
>>> + KUNIT_SUBTEST_INDENT
>>> + "# %s: param-%d %s",
>>
>> Would it make sense to have this imitate the TAP format a bit more?
>> So, have "# [ok|not ok] - [name]" as the format? [name] could be
>> something like "[test_case->name]:param-[index]" or similar.
>> If we keep it commented out and don't indent it further, it won't
>> formally be a nested test (though if we wanted to support those later,
>> it'd be easy to add), but I think it would be nicer to be consistent
>> here.
>
> 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?
>
Which format do we finally go with?
>> My other suggestion -- albeit one
Re: [PATCH 3/3] hwmon: (ltc2945): add support for sense resistor
On Fri, Nov 6, 2020 at 3:17 PM Guenter Roeck wrote:
>
> On Fri, Nov 06, 2020 at 12:18:25PM +0200, Alexandru Ardelean wrote:
> > The sense resistor is a parameter of the board. It should be configured in
> > the driver via a device-tree / ACPI property, so that the proper current
> > measurements can be done in the driver.
> >
> > It shouldn't be necessary that userspace need to know about the value of
> > the resistor. It makes things a bit harder to make the application code
> > portable from one board to another.
> >
> > This change implements support for the sense resistor to be configured from
> > DT/ACPI and used in current calculations.
> >
>
> This will require a matching deevicetree document.
Ack
Will create a dt binding schema doc.
Are you fine with being added as maintainer in the DT doc?
Seeing as you are the original author of the driver.
>
> > Signed-off-by: Alexandru Ardelean
> > ---
> > drivers/hwmon/ltc2945.c | 48 ++---
> > 1 file changed, 21 insertions(+), 27 deletions(-)
> >
> > diff --git a/drivers/hwmon/ltc2945.c b/drivers/hwmon/ltc2945.c
> > index 75d997d31e01..500401a82c49 100644
> > --- a/drivers/hwmon/ltc2945.c
> > +++ b/drivers/hwmon/ltc2945.c
> > @@ -61,9 +61,11 @@
> > /**
> > * struct ltc2945_state - driver instance specific data
> > * @regmap regmap object to access device registers
> > + * @r_sense_uohm current sense resistor value
> > */
> > struct ltc2945_state {
> > struct regmap *regmap;
> > + u32 r_sense_uohm;
> > };
> >
> > static inline bool is_power_reg(u8 reg)
> > @@ -101,9 +103,8 @@ static long long ltc2945_reg_to_val(struct device *dev,
> > u8 reg)
> > case LTC2945_MAX_POWER_THRES_H:
> > case LTC2945_MIN_POWER_THRES_H:
> > /*
> > - * Convert to uW by assuming current is measured with
> > - * an 1mOhm sense resistor, similar to current
> > - * measurements.
> > + * Convert to uW by and scale it with the configured
> > + * sense resistor, similar to current measurements.
> >* Control register bit 0 selects if voltage at SENSE+/VDD
> >* or voltage at ADIN is used to measure power.
> >*/
> > @@ -112,10 +113,10 @@ static long long ltc2945_reg_to_val(struct device
> > *dev, u8 reg)
> > return ret;
> > if (control & CONTROL_MULT_SELECT) {
> > /* 25 mV * 25 uV = 0.625 uV resolution. */
> > - val *= 625LL;
> > + val = DIV_ROUND_CLOSEST_ULL(val * 625LL * 1000,
> > st->r_sense_uohm);
> > } else {
> > /* 0.5 mV * 25 uV = 0.0125 uV resolution. */
> > - val = (val * 25LL) >> 1;
> > + val = DIV_ROUND_CLOSEST_ULL(val * 25LL * 1000,
> > st->r_sense_uohm) >> 1;
> > }
> > break;
> > case LTC2945_VIN_H:
> > @@ -140,13 +141,10 @@ static long long ltc2945_reg_to_val(struct device
> > *dev, u8 reg)
> > case LTC2945_MAX_SENSE_THRES_H:
> > case LTC2945_MIN_SENSE_THRES_H:
> > /*
> > - * 25 uV resolution. Convert to current as measured with
> > - * an 1 mOhm sense resistor, in mA. If a different sense
> > - * resistor is installed, calculate the actual current by
> > - * dividing the reported current by the sense resistor value
> > - * in mOhm.
> > + * 25 uV resolution. Convert to current and scale it
> > + * with the value of the sense resistor.
> >*/
> > - val *= 25;
> > + val = DIV_ROUND_CLOSEST_ULL(val * 25 * 1000,
> > st->r_sense_uohm);
> > break;
> > default:
> > return -EINVAL;
> > @@ -169,9 +167,8 @@ static int ltc2945_val_to_reg(struct device *dev, u8
> > reg,
> > case LTC2945_MAX_POWER_THRES_H:
> > case LTC2945_MIN_POWER_THRES_H:
> > /*
> > - * Convert to register value by assuming current is measured
> > - * with an 1mOhm sense resistor, similar to current
> > - * measurements.
> > + * Convert to register value, scale it with the configured
> > sense
> > + * resistor value, similar to current measurements.
> >* Control register bit 0 selects if voltage at SENSE+/VDD
> >* or voltage at ADIN is used to measure power, which in turn
> >* determines register calculations.
> > @@ -181,14 +178,10 @@ static int ltc2945_val_to_reg(struct device *dev, u8
> > reg,
> > return ret;
> > if (control & CONTROL_MULT_SELECT) {
> > /* 25 mV * 25 uV = 0.625 uV resolution. */
> > - val = DIV_ROUND_CLOSEST_ULL(val, 625);
> > + val
Re: [RFC, v0 1/3] vfio/platform: add support for msi
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.
>
> > 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.
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?
Suggestions on this would be helpful.
Thanks,
Vikas
>
> > Do you see this is a violation? If
>
> Seems pretty unclear and dubious use of a global device flag.
>
> > 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.
>
> If nothing else you're using a global flag to describe a platform
> device specific augmentation. We've recently added capabilities on the
> device info return that would be more appropriate for this, but
> fundamentally I don't understand why the irq info isn't sufficient.
> Thanks,
>
> Alex
>
smime.p7s
Description: S/MIME Cryptographic Signature
Re: [PATCH 2/3] docs: hwmon: (ltc2945): change type of val to ULL in ltc2945_val_to_reg()
On Fri, Nov 6, 2020 at 3:14 PM Guenter Roeck wrote:
>
> On Fri, Nov 06, 2020 at 12:18:24PM +0200, Alexandru Ardelean wrote:
> > In order to account for any potential overflows that could occur.
> >
> > Signed-off-by: Alexandru Ardelean
> > ---
> > drivers/hwmon/ltc2945.c | 14 +++---
> > 1 file changed, 7 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/hwmon/ltc2945.c b/drivers/hwmon/ltc2945.c
> > index 1cea710df668..75d997d31e01 100644
> > --- a/drivers/hwmon/ltc2945.c
> > +++ b/drivers/hwmon/ltc2945.c
> > @@ -155,7 +155,7 @@ static long long ltc2945_reg_to_val(struct device *dev,
> > u8 reg)
> > }
> >
> > static int ltc2945_val_to_reg(struct device *dev, u8 reg,
> > - unsigned long val)
> > + unsigned long long val)
> > {
> > struct ltc2945_state *st = dev_get_drvdata(dev);
> > struct regmap *regmap = st->regmap;
> > @@ -181,14 +181,14 @@ static int ltc2945_val_to_reg(struct device *dev, u8
> > reg,
> > return ret;
> > if (control & CONTROL_MULT_SELECT) {
> > /* 25 mV * 25 uV = 0.625 uV resolution. */
> > - val = DIV_ROUND_CLOSEST(val, 625);
> > + val = DIV_ROUND_CLOSEST_ULL(val, 625);
> > } else {
> > /*
> >* 0.5 mV * 25 uV = 0.0125 uV resolution.
> >* Divide first to avoid overflow;
> >* accept loss of accuracy.
> >*/
> > - val = DIV_ROUND_CLOSEST(val, 25) * 2;
> > + val = DIV_ROUND_CLOSEST_ULL(val, 25) * 2;
> > }
> > break;
> > case LTC2945_VIN_H:
> > @@ -197,7 +197,7 @@ static int ltc2945_val_to_reg(struct device *dev, u8
> > reg,
> > case LTC2945_MAX_VIN_THRES_H:
> > case LTC2945_MIN_VIN_THRES_H:
> > /* 25 mV resolution. */
> > - val /= 25;
> > + val = div_u64(val, 25);
> > break;
> > case LTC2945_ADIN_H:
> > case LTC2945_MAX_ADIN_H:
> > @@ -219,7 +219,7 @@ static int ltc2945_val_to_reg(struct device *dev, u8
> > reg,
> >* dividing the reported current by the sense resistor value
> >* in mOhm.
> >*/
> > - val = DIV_ROUND_CLOSEST(val, 25);
> > + val = DIV_ROUND_CLOSEST_ULL(val, 25);
> > break;
> > default:
> > return -EINVAL;
> > @@ -247,13 +247,13 @@ static ssize_t ltc2945_value_store(struct device *dev,
> > struct ltc2945_state *st = dev_get_drvdata(dev);
> > struct regmap *regmap = st->regmap;
> > u8 reg = attr->index;
> > - unsigned long val;
> > + unsigned long long val;
> > u8 regbuf[3];
> > int num_regs;
> > int regval;
> > int ret;
> >
> > - ret = kstrtoul(buf, 10, );
> > + ret = kstrtoull(buf, 10, );
>
> This part of the change is unnecessary. Just keep 'val' as-is.
> ltc2945_val_to_reg() can still accept ull.
Ack
>
> Guenter
>
> > if (ret)
> > return ret;
> >
> > --
> > 2.27.0
> >
Re: [PATCH 15/20] input: touchscreen: cyttsp4_core: Move 'cyttsp4_tch_abs_string' to the only file that references it
On Wed, Nov 04, 2020 at 04:24:22PM +, Lee Jones wrote:
> Fixes the following W=1 kernel build warning(s):
>
> In file included from drivers/input/touchscreen/cyttsp_i2c_common.c:24:
> drivers/input/touchscreen/cyttsp4_core.h:236:27: warning:
> ‘cyttsp4_tch_abs_string’ defined but not used [-Wunused-const-variable=]
> 236 | static const char const cyttsp4_tch_abs_string[] = {
> | ^~
> In file included from drivers/input/touchscreen/cyttsp4_i2c.c:17:
> drivers/input/touchscreen/cyttsp4_core.h:236:27: warning:
> ‘cyttsp4_tch_abs_string’ defined but not used [-Wunused-const-variable=]
> 236 | static const char * const cyttsp4_tch_abs_string[] = {
> | ^~
> In file included from drivers/input/touchscreen/cyttsp4_spi.c:17:
> drivers/input/touchscreen/cyttsp4_core.h:236:27: warning:
> ‘cyttsp4_tch_abs_string’ defined but not used [-Wunused-const-variable=]
> 236 | static const char * const cyttsp4_tch_abs_string[] = {
> | ^~
>
> Cc: Ferruh Yigit
> Cc: Dmitry Torokhov
> Cc: "at www.cypress.com"
> Cc: linux-in...@vger.kernel.org
> Signed-off-by: Lee Jones
Applied, thank you.
--
Dmitry
Re: Question: gadget: How to realize uvc and uac composite function?
On Mon, Nov 09, 2020 at 02:03:11AM +, Tim Li wrote: > This email and any attachments thereto may contain private, confidential, and > privileged material for the sole use of the intended recipient. Any review, > copying, or distribution of this email (or any attachments thereto) by others > is strictly prohibited. If you are not the intended recipient, please contact > the sender immediately and permanently delete the original and any copies of > this email and any attachments thereto. Now deleted.
Re: [PATCH v12 01/11] perf/x86: Fix variable types for LBR registers
On Sat, Jun 13, 2020 at 04:09:46PM +0800, Like Xu wrote: > From: Wei Wang > > The MSR variable type can be 'unsigned int', which uses less memory than > the longer 'unsigned long'. Fix 'struct x86_pmu' for that. The lbr_nr won't > be a negative number, so make it 'unsigned int' as well. Hi, What's the status of this patchkit? It would be quite useful to me (and various other people) to use LBRs in guest. I reviewed it earlier and the patches all looked good to me. But i don't see it in any -next tree. Reviewed-by: Andi Kleen Could it please be merged? Thanks, -Andi
Re: [PATCH 09/20] input: touchscreen: resistive-adc-touch: Struct headers should start with 'struct '
On Wed, Nov 04, 2020 at 04:24:16PM +, Lee Jones wrote: > Fixes the following W=1 kernel build warning(s): > > drivers/input/touchscreen/resistive-adc-touch.c:34: warning: cannot > understand function prototype: 'struct grts_state ' > > Cc: Eugen Hristev > Cc: Dmitry Torokhov > Cc: linux-in...@vger.kernel.org > Signed-off-by: Lee Jones Applied, thank you. -- Dmitry
Re: [PATCH 03/20] input: mouse: cyapa_gen5: Fix obvious abuse of kernel-doc format
On Wed, Nov 04, 2020 at 04:24:10PM +, Lee Jones wrote: > Fixes the following W=1 kernel build warning(s): > > drivers/input/mouse/cyapa_gen5.c:392: warning: Function parameter or member > 'cyapa' not described in 'cyapa_i2c_pip_write' > drivers/input/mouse/cyapa_gen5.c:392: warning: Function parameter or member > 'buf' not described in 'cyapa_i2c_pip_write' > drivers/input/mouse/cyapa_gen5.c:392: warning: Function parameter or member > 'size' not described in 'cyapa_i2c_pip_write' > drivers/input/mouse/cyapa_gen5.c:444: warning: Function parameter or member > 'cyapa' not described in 'cyapa_empty_pip_output_data' > drivers/input/mouse/cyapa_gen5.c:444: warning: Function parameter or member > 'buf' not described in 'cyapa_empty_pip_output_data' > drivers/input/mouse/cyapa_gen5.c:444: warning: Function parameter or member > 'len' not described in 'cyapa_empty_pip_output_data' > drivers/input/mouse/cyapa_gen5.c:444: warning: Function parameter or member > 'func' not described in 'cyapa_empty_pip_output_data' > > Cc: Dmitry Torokhov > Cc: Henrik Rydberg > Cc: "Gustavo A. R. Silva" > Cc: Dudley Du > Cc: linux-in...@vger.kernel.org > Signed-off-by: Lee Jones Applied, thank you. -- Dmitry
Re: [PATCH 04/20] input: misc: ab8500-ponkey: Fix incorrect name in 'ab8500_ponkey' doc header
On Wed, Nov 04, 2020 at 04:24:11PM +, Lee Jones wrote: > Fixes the following W=1 kernel build warning(s): > > drivers/input/misc/ab8500-ponkey.c:32: warning: Function parameter or member > 'idev' not described in 'ab8500_ponkey' > > Cc: Dmitry Torokhov > Cc: Sundar Iyer > Cc: linux-in...@vger.kernel.org > Signed-off-by: Lee Jones Applied, thank you. -- Dmitry
Re: [PATCH 02/20] input: mouse: cyapa: Fix misnaming of 'cyapa_i2c_write's 'reg' param
On Wed, Nov 04, 2020 at 04:24:09PM +, Lee Jones wrote: > Fixes the following W=1 kernel build warning(s): > > drivers/input/mouse/cyapa.c:130: warning: Function parameter or member 'reg' > not described in 'cyapa_i2c_write' > drivers/input/mouse/cyapa.c:130: warning: Excess function parameter 'ret' > description in 'cyapa_i2c_write' > > Cc: Dmitry Torokhov > Cc: Henrik Rydberg > Cc: Dudley Du > Cc: Daniel Kurtz > Cc: Benson Leung > Cc: linux-in...@vger.kernel.org > Signed-off-by: Lee Jones Applied, thank you. -- Dmitry
[PATCH v3 2/2] pinctrl: qcom: Add SDX55 pincontrol driver
From: Jeevan Shriram
Add initial Qualcomm SDX55 pinctrl driver to support pin configuration
with pinctrl framewor for SDX55 SoC.
Signed-off-by: Jeevan Shriram
Reviewed-by: Bjorn Andersson
[ported from downstream and tidy up]
Signed-off-by: Vinod Koul
---
drivers/pinctrl/qcom/Kconfig |9 +
drivers/pinctrl/qcom/Makefile|1 +
drivers/pinctrl/qcom/pinctrl-sdx55.c | 1018 ++
3 files changed, 1028 insertions(+)
create mode 100644 drivers/pinctrl/qcom/pinctrl-sdx55.c
diff --git a/drivers/pinctrl/qcom/Kconfig b/drivers/pinctrl/qcom/Kconfig
index 5fe7b8aaf69d..a84961d415fa 100644
--- a/drivers/pinctrl/qcom/Kconfig
+++ b/drivers/pinctrl/qcom/Kconfig
@@ -218,6 +218,15 @@ config PINCTRL_SDM845
Qualcomm Technologies Inc TLMM block found on the Qualcomm
Technologies Inc SDM845 platform.
+config PINCTRL_SDX55
+ tristate "Qualcomm Technologies Inc SDX55 pin controller driver"
+ depends on GPIOLIB && OF
+ select PINCTRL_MSM
+ help
+This is the pinctrl, pinmux, pinconf and gpiolib driver for the
+Qualcomm Technologies Inc TLMM block found on the Qualcomm
+Technologies Inc SDX55 platform.
+
config PINCTRL_SM8150
tristate "Qualcomm Technologies Inc SM8150 pin controller driver"
depends on GPIOLIB && OF
diff --git a/drivers/pinctrl/qcom/Makefile b/drivers/pinctrl/qcom/Makefile
index 9e3d9c91a444..2f9e5bbadeda 100644
--- a/drivers/pinctrl/qcom/Makefile
+++ b/drivers/pinctrl/qcom/Makefile
@@ -26,5 +26,6 @@ obj-$(CONFIG_PINCTRL_QCOM_SSBI_PMIC) += pinctrl-ssbi-mpp.o
obj-$(CONFIG_PINCTRL_SC7180) += pinctrl-sc7180.o
obj-$(CONFIG_PINCTRL_SDM660) += pinctrl-sdm660.o
obj-$(CONFIG_PINCTRL_SDM845) += pinctrl-sdm845.o
+obj-$(CONFIG_PINCTRL_SDX55) += pinctrl-sdx55.o
obj-$(CONFIG_PINCTRL_SM8150) += pinctrl-sm8150.o
obj-$(CONFIG_PINCTRL_SM8250) += pinctrl-sm8250.o
diff --git a/drivers/pinctrl/qcom/pinctrl-sdx55.c
b/drivers/pinctrl/qcom/pinctrl-sdx55.c
new file mode 100644
index ..2b5b0e2b03ad
--- /dev/null
+++ b/drivers/pinctrl/qcom/pinctrl-sdx55.c
@@ -0,0 +1,1018 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2018-2020, The Linux Foundation. All rights reserved.
+ */
+
+#include
+#include
+#include
+#include
+
+#include "pinctrl-msm.h"
+
+#define FUNCTION(fname)\
+ [msm_mux_##fname] = { \
+ .name = #fname, \
+ .groups = fname##_groups, \
+ .ngroups = ARRAY_SIZE(fname##_groups), \
+ }
+
+#define REG_SIZE 0x1000
+
+#define PINGROUP(id, f1, f2, f3, f4, f5, f6, f7, f8, f9) \
+ { \
+ .name = "gpio" #id, \
+ .pins = gpio##id##_pins,\
+ .npins = (unsigned int)ARRAY_SIZE(gpio##id##_pins), \
+ .funcs = (int[]){ \
+ msm_mux_gpio, /* gpio mode */ \
+ msm_mux_##f1, \
+ msm_mux_##f2, \
+ msm_mux_##f3, \
+ msm_mux_##f4, \
+ msm_mux_##f5, \
+ msm_mux_##f6, \
+ msm_mux_##f7, \
+ msm_mux_##f8, \
+ msm_mux_##f9\
+ }, \
+ .nfuncs = 10, \
+ .ctl_reg = REG_SIZE * id, \
+ .io_reg = 0x4 + REG_SIZE * id, \
+ .intr_cfg_reg = 0x8 + REG_SIZE * id,\
+ .intr_status_reg = 0xc + REG_SIZE * id, \
+ .intr_target_reg = 0x8 + REG_SIZE * id, \
+ .mux_bit = 2, \
+ .pull_bit = 0, \
+ .drv_bit = 6, \
+ .oe_bit = 9,\
+ .in_bit = 0,\
+ .out_bit = 1, \
+ .intr_enable_bit = 0, \
+ .intr_status_bit = 0, \
+ .intr_target_bit = 5, \
+ .intr_target_kpss_val = 3, \
+ .intr_raw_status_bit = 4, \
+ .intr_polarity_bit = 1, \
+ .intr_detection_bit = 2,\
+ .intr_detection_width = 2, \
+ }
+
+#define SDC_PINGROUP(pg_name, ctl, pull, drv) \
+ { \
+ .name = #pg_name, \
+ .pins = pg_name##_pins, \
+ .npins
[PATCH v3 1/2] dt-bindings: pinctrl: qcom: Add SDX55 pinctrl bindings
Add device tree binding Documentation details for Qualcomm SDX55 pinctrl driver. Reviewed-by: Bjorn Andersson Signed-off-by: Vinod Koul --- .../bindings/pinctrl/qcom,sdx55-pinctrl.yaml | 154 ++ 1 file changed, 154 insertions(+) create mode 100644 Documentation/devicetree/bindings/pinctrl/qcom,sdx55-pinctrl.yaml diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sdx55-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sdx55-pinctrl.yaml new file mode 100644 index ..112dd59ce7ed --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/qcom,sdx55-pinctrl.yaml @@ -0,0 +1,154 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/qcom,sdx55-pinctrl.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Technologies, Inc. SDX55 TLMM block + +maintainers: + - Vinod Koul + +description: | + This binding describes the Top Level Mode Multiplexer block found in the + SDX55 platform. + +properties: + compatible: +const: qcom,sdx55-pinctrl + + reg: +description: Specifies the base address and size of the TLMM register space +maxItems: 1 + + interrupts: +description: Specifies the TLMM summary IRQ +maxItems: 1 + + interrupt-controller: true + + '#interrupt-cells': +description: Specifies the PIN numbers and Flags, as defined in + include/dt-bindings/interrupt-controller/irq.h +const: 2 + + gpio-controller: true + + '#gpio-cells': +description: Specifying the pin number and flags, as defined in + include/dt-bindings/gpio/gpio.h +const: 2 + + gpio-ranges: +maxItems: 1 + + gpio-reserved-ranges: +maxItems: 1 + +#PIN CONFIGURATION NODES +patternProperties: + '-pins$': +type: object +description: + Pinctrl node's client devices use subnodes for desired pin configuration. + Client device subnodes use below standard properties. +$ref: "/schemas/pinctrl/pincfg-node.yaml" + +properties: + pins: +description: + List of gpio pins affected by the properties specified in this subnode. +items: + oneOf: +- pattern: "^gpio([0-9]|[1-9][0-9]|1[0-1][0-6])$" +- enum: [ sdc1_clk, sdc1_cmd, sdc1_data, sdc2_clk, sdc2_cmd, sdc2_data ] +minItems: 1 +maxItems: 36 + + function: +description: + Specify the alternative function to be configured for the specified + pins. Functions are only valid for gpio pins. +enum: [ adsp_ext, atest, audio_ref, bimc_dte0, bimc_dte1, blsp_i2c1, +blsp_i2c2, blsp_i2c3, blsp_i2c4, blsp_spi1, blsp_spi2, +blsp_spi3, blsp_spi4, blsp_uart1, blsp_uart2, blsp_uart3, +blsp_uart4, char_exec, coex_uart, coex_uart2, cri_trng, +cri_trng0, cri_trng1, dbg_out, ddr_bist, ddr_pxi0, +ebi0_wrcdc, ebi2_a, ebi2_lcd, emac_gcc0, emac_gcc1, +emac_pps0, emac_pps1, ext_dbg, gcc_gp1, gcc_gp2, gcc_gp3, +gcc_plltest, gpio, i2s_mclk, jitter_bist, ldo_en, ldo_update, +mgpi_clk, m_voc, native_char, native_char0, native_char1, +native_char2, native_char3, native_tsens, native_tsense, +nav_gpio, pa_indicator, pcie_clkreq, pci_e, pll_bist, pll_ref, +pll_test, pri_mi2s, prng_rosc, qdss_cti, qdss_gpio, +qdss_gpio0, qdss_gpio1, qdss_gpio2, qdss_gpio3, qdss_gpio4, +qdss_gpio5, qdss_gpio6, qdss_gpio7, qdss_gpio8, qdss_gpio9, +qdss_gpio10, qdss_gpio11, qdss_gpio12, qdss_gpio13, +qdss_gpio14, qdss_gpio15, qdss_stm0, qdss_stm1, qdss_stm2, +qdss_stm3, qdss_stm4, qdss_stm5, qdss_stm6, qdss_stm7, +qdss_stm8, qdss_stm9, qdss_stm10, qdss_stm11, qdss_stm12, +qdss_stm13, qdss_stm14, qdss_stm15, qdss_stm16, qdss_stm17, +qdss_stm18, qdss_stm19, qdss_stm20, qdss_stm21, qdss_stm22, +qdss_stm23, qdss_stm24, qdss_stm25, qdss_stm26, qdss_stm27, +qdss_stm28, qdss_stm29, qdss_stm30, qdss_stm31, qlink0_en, +qlink0_req, qlink0_wmss, qlink1_en, qlink1_req, qlink1_wmss, +spmi_coex, sec_mi2s, spmi_vgi, tgu_ch0, uim1_clk, uim1_data, +uim1_present, uim1_reset, uim2_clk, uim2_data, uim2_present, +uim2_reset, usb2phy_ac, vsense_trigger ] + + drive-strength: +enum: [2, 4, 6, 8, 10, 12, 14, 16] +default: 2 +description: + Selects the drive strength for the specified pins, in mA. + + bias-pull-down: true + + bias-pull-up: true + + bias-disable: true + + output-high: true + + output-low: true + +required: + - pins + - function + +additionalProperties: false + +required: + - compatible + - reg + - interrupts + - interrupt-controller + -
Re: [PATCH 12/20] input: mouse: elantech: Demote obvious abuse of kernel-doc header
On Wed, Nov 04, 2020 at 04:24:19PM +, Lee Jones wrote: > Fixes the following W=1 kernel build warning(s): > > drivers/input/mouse/elantech.c:1837: warning: Function parameter or member > 'psmouse' not described in 'elantech_setup_smbus' > drivers/input/mouse/elantech.c:1837: warning: Function parameter or member > 'info' not described in 'elantech_setup_smbus' > drivers/input/mouse/elantech.c:1837: warning: Function parameter or member > 'leave_breadcrumbs' not described in 'elantech_setup_smbus' > > Cc: Dmitry Torokhov > Cc: Henrik Rydberg > Cc: Arjan Opmeer > Cc: linux-in...@vger.kernel.org > Signed-off-by: Lee Jones Applied, thank you. -- Dmitry
[PATCH v3 0/2] pinctrl: qcom: Add binding and driver for SDX55 pincontrol
This series add device tree binding documentation and driver for SDX55 SOC pincontroller. Changes in v3: - Add ack by Bjorn - Fix dt_binding_check errors - Add gpio ranges in binding Changes in v2: - merge the functional groups together - move pins to single line for readability Jeevan Shriram (1): pinctrl: qcom: Add SDX55 pincontrol driver Vinod Koul (1): dt-bindings: pinctrl: qcom: Add SDX55 pinctrl bindings .../bindings/pinctrl/qcom,sdx55-pinctrl.yaml | 154 +++ drivers/pinctrl/qcom/Kconfig |9 + drivers/pinctrl/qcom/Makefile |1 + drivers/pinctrl/qcom/pinctrl-sdx55.c | 1018 + 4 files changed, 1182 insertions(+) create mode 100644 Documentation/devicetree/bindings/pinctrl/qcom,sdx55-pinctrl.yaml create mode 100644 drivers/pinctrl/qcom/pinctrl-sdx55.c -- 2.26.2
Re: [PATCH 11/20] input: keyboard: gpio_keys: Fix misnamed function parameter 'dev'
On Wed, Nov 04, 2020 at 04:24:18PM +, Lee Jones wrote: > Fixes the following W=1 kernel build warning(s): > > drivers/input/keyboard/gpio_keys.c:119: warning: Function parameter or > member 'dev' not described in 'get_bm_events_by_type' > drivers/input/keyboard/gpio_keys.c:119: warning: Excess function parameter > 'input' description in 'get_bm_events_by_type' > > Cc: Dmitry Torokhov > Cc: "Gustavo A. R. Silva" > Cc: David Jander > Cc: Phil Blundell > Cc: linux-in...@vger.kernel.org > Signed-off-by: Lee Jones Applied, thank you. -- Dmitry
Re: [PATCH] sched/rt, powerpc: Prepare for PREEMPT_RT
On Mon, Nov 09, 2020 at 11:40:08AM +0800, Wang Qing wrote: > Add PREEMPT_RT output to die(). That says what you did, but not why you are doing this. Why are you doing this? That needs to go into the changelog text. greg k-h
[RFC v3] cpuidle : Add support for pseudo-cpuidle driver
This option adds support for a testing cpuidle driver, which allows
user to define custom idle states with their respective latencies and
residencies. This is useful for testing the behaviour of governors on
customized set of idle states.
This can be used as of now by specifying a customized set of cpuidle
states in the driver by the user. Will add the capability of this
driver to be used as a module in subsequent patches.
Original idea and discussion for this patch can be found at:
https://lkml.org/lkml/2019/12/17/655
Signed-off-by: Abhishek Goel
---
v1->v2 : Changes adapted from reviews of Randy, Dan and Nathan.
There was a divergence from expected behaviour of idle loop
in v1. That has been fixed.
v2->v3 : Added simulated latency while entering into idle states.
drivers/cpuidle/Kconfig| 9 +
drivers/cpuidle/Makefile | 1 +
drivers/cpuidle/cpuidle-test.c | 289 +
3 files changed, 299 insertions(+)
create mode 100644 drivers/cpuidle/cpuidle-test.c
diff --git a/drivers/cpuidle/Kconfig b/drivers/cpuidle/Kconfig
index c0aeedd66f02..1a0f227d61d6 100644
--- a/drivers/cpuidle/Kconfig
+++ b/drivers/cpuidle/Kconfig
@@ -71,6 +71,15 @@ config HALTPOLL_CPUIDLE
before halting in the guest (more efficient than polling in the
host via halt_poll_ns for some scenarios).
+config TEST_CPUIDLE
+ tristate "cpuidle test driver"
+ default n
+ help
+ This option enables a testing cpuidle driver, which allows the user
+ to define custom idle states with their respective latencies &
residencies.
+ This is useful for testing the behaviour of governors on different
+ sets of idle states.
+
endif
config ARCH_NEEDS_CPU_IDLE_COUPLED
diff --git a/drivers/cpuidle/Makefile b/drivers/cpuidle/Makefile
index f07800cbb43f..68ea7dc257b5 100644
--- a/drivers/cpuidle/Makefile
+++ b/drivers/cpuidle/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED) += coupled.o
obj-$(CONFIG_DT_IDLE_STATES) += dt_idle_states.o
obj-$(CONFIG_ARCH_HAS_CPU_RELAX) += poll_state.o
obj-$(CONFIG_HALTPOLL_CPUIDLE) += cpuidle-haltpoll.o
+obj-$(CONFIG_TEST_CPUIDLE) += cpuidle-test.o
##
# ARM SoC drivers
diff --git a/drivers/cpuidle/cpuidle-test.c b/drivers/cpuidle/cpuidle-test.c
new file mode 100644
index ..17ffce11cafc
--- /dev/null
+++ b/drivers/cpuidle/cpuidle-test.c
@@ -0,0 +1,289 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * cpuidle-test - Test driver for cpuidle.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define CPUIDLE_STATE_MAX 10
+#define MAX_PARAM_LENGTH 100
+
+static unsigned int nr_states = 4;
+static unsigned int sim_type = 1;
+static char name[MAX_PARAM_LENGTH];
+static char latency_us[MAX_PARAM_LENGTH];
+static char residency_us[MAX_PARAM_LENGTH];
+
+
+module_param(nr_states, uint, 0644);
+module_param(sim_type, uint, 0644);
+module_param_string(name, name, MAX_PARAM_LENGTH, 0644);
+module_param_string(latency_us, latency_us, MAX_PARAM_LENGTH, 0644);
+module_param_string(residency_us, residency_us, MAX_PARAM_LENGTH, 0644);
+
+static struct cpuidle_driver test_cpuidle_driver = {
+ .name = "test_cpuidle",
+ .owner = THIS_MODULE,
+};
+
+static struct cpuidle_state *cpuidle_state_table __read_mostly;
+
+static struct cpuidle_device __percpu *test_cpuidle_devices;
+static enum cpuhp_state test_hp_idlestate;
+
+
+static int __cpuidle idle_loop(struct cpuidle_device *dev,
+ struct cpuidle_driver *drv,
+ int index)
+{
+ u64 time_start;
+
+ local_irq_enable();
+
+ time_start = local_clock();
+ /*
+* Simulating entry latency into idle state.
+*/
+ while (local_clock() - time_start < drv->states[index].exit_latency) {
+ }
+
+ if (!current_set_polling_and_test()) {
+ while (!need_resched())
+ cpu_relax();
+ }
+
+ time_start = local_clock();
+ /*
+* Simulating exit latency from idle state.
+*/
+ while (local_clock() - time_start < drv->states[index].exit_latency) {
+ }
+
+ current_clr_polling();
+
+ return index;
+}
+
+ /*
+* Defining user specified custome set of idle states.
+*/
+static struct cpuidle_state cpuidle_states[CPUIDLE_STATE_MAX] = {
+ { .name = "snooze",
+ .exit_latency = 0,
+ .target_residency = 0,
+ .enter = idle_loop },
+};
+
+static struct cpuidle_state cpuidle_states_ppc[] = {
+ { .name = "snooze",
+ .exit_latency = 0,
+ .target_residency = 0,
+ .enter = idle_loop },
+ {
+
Re: [PATCH 5.9 639/757] random32: make prandom_u32() output unpredictable
On Mon, Nov 09, 2020 at 07:16:25AM +0200, Amit Klein wrote: > Dear all > > Quick question: what's the plan for back-porting this security patch to LTS > branches? If you have working and tested backports, to older kernels, I'll be glad to accept them if you think they are needed. thanks, greg k-h
Re: [PATCH 19/20] input: keyboard: nomadik-ske-keypad: Provide some missing struct member docs
On Wed, Nov 04, 2020 at 04:24:26PM +, Lee Jones wrote: > Fixes the following W=1 kernel build warning(s): > > drivers/input/keyboard/nomadik-ske-keypad.c:71: warning: Function parameter > or member 'pclk' not described in 'ske_keypad' > drivers/input/keyboard/nomadik-ske-keypad.c:71: warning: Function parameter > or member 'ske_keypad_lock' not described in 'ske_keypad' > > Cc: Dmitry Torokhov > Cc: Kumar G > Cc: Sundar Iyer > Cc: linux-in...@vger.kernel.org > Signed-off-by: Lee Jones Applied, thank you. -- Dmitry
Re: [PATCH v2 1/2] arm64: dts: broadcom: clear the warnings caused by empty dma-ranges
Hi, everybody: How do we deal with this problem? I updated the kernel to the latest and the problem still persists. make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -j24 dtbs 2>err.txt vim err.txt arch/arm64/boot/dts/qcom/ipq6018.dtsi:185.3-14: Warning (dma_ranges_format): /soc:dma-ranges: empty "dma-ranges" property but its #address-cells (1) differs from / (2) arch/arm64/boot/dts/qcom/ipq6018.dtsi:185.3-14: Warning (dma_ranges_format): /soc:dma-ranges: empty "dma-ranges" property but its #size-cells (1) differs from / (2) arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #address-cells (1) differs from / (2) arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #size-cells (1) differs from / (2) arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #address-cells (1) differs from / (2) arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #size-cells (1) differs from / (2) arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #address-cells (1) differs from / (2) arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #size-cells (1) differs from / (2) On 2020/10/26 10:21, Leizhen (ThunderTown) wrote: > > > On 2020/10/23 15:17, Arnd Bergmann wrote: >> On Sun, Oct 18, 2020 at 4:10 AM Leizhen (ThunderTown) >> wrote: >>> On 2020/10/17 3:27, Florian Fainelli wrote: On 10/16/20 11:23 AM, Arnd Bergmann wrote: > On Fri, Oct 16, 2020 at 6:48 PM Florian Fainelli > wrote: >> On 10/16/20 4:01 AM, Arnd Bergmann wrote: >>> On Fri, Oct 16, 2020 at 11:09 AM Zhen Lei >>> wrote: Suggested-by: Arnd Bergmann Signed-off-by: Zhen Lei >>> >>> Acked-by: Arnd Bergmann >>> >>> I see that at least the 'bcd' and 'xhci' devices in fact try to >>> use 64-bit DMA. It would be good to test this on actual >>> hardware to ensure that it works correctly when this is enabled. >>> >>> Ideally avoiding the swiotlb bounce buffering should only >>> make it faster here, but there are many chips on which >>> 64-bit DMA is broken in some form. >> >> Is this change really an improvement though? This 'usb' pseudo bus node >> could just keep being defined with #address-cells = <1> and #size-cells >> = <1> so as to satisfy the 'reg' definition however we could just adjust >> dma-ranges to indicate full 64-bit addressing capability. Would not that >> work? > > When #address-cells is '1', you cannot specify dma-ranges that > go beyond a 32-bit address range. Would not it be enough to remove the 'dma-ranges' property though? Sorry for being slow here. >>> >>> Remove the 'dma-ranges' property should also work. After all, it is >>> equivalent >>> to the original empty dma-ranges scheme. In addition, since the IOMMU nodes >>> are >>> defined, it should be enabled. >> >> Are you sure? I was expecting the IOMMU not to get used here since >> the devices do contain list an 'iommus' property. > > OK，If the SMMU maybe disabled, then your proposal is necessary. > >> >> Arnd >> >> . >>
Re: [PATCH 18/20] input: misc: drv2667: Fix formatting and add missing member docs
On Wed, Nov 04, 2020 at 04:24:25PM +, Lee Jones wrote: > Fixes the following W=1 kernel build warning(s): > > drivers/input/misc/drv2667.c:109: warning: Function parameter or member > 'input_dev' not described in 'drv2667_data' > drivers/input/misc/drv2667.c:109: warning: Function parameter or member > 'client' not described in 'drv2667_data' > drivers/input/misc/drv2667.c:109: warning: Function parameter or member > 'regmap' not described in 'drv2667_data' > drivers/input/misc/drv2667.c:109: warning: Function parameter or member > 'work' not described in 'drv2667_data' > drivers/input/misc/drv2667.c:109: warning: Function parameter or member > 'regulator' not described in 'drv2667_data' > drivers/input/misc/drv2667.c:109: warning: Function parameter or member > 'page' not described in 'drv2667_data' > drivers/input/misc/drv2667.c:109: warning: Function parameter or member > 'magnitude' not described in 'drv2667_data' > drivers/input/misc/drv2667.c:109: warning: Function parameter or member > 'frequency' not described in 'drv2667_data' > > Cc: Dmitry Torokhov > Cc: Dan Murphy > Cc: linux-in...@vger.kernel.org > Signed-off-by: Lee Jones Applied, thank you. -- Dmitry
Re: [PATCH 17/20] input: misc: drv2665: Fix formatting expected by kernel-doc
On Wed, Nov 04, 2020 at 04:24:24PM +, Lee Jones wrote: > Fixes the following W=1 kernel build warning(s): > > drivers/input/misc/drv2665.c:59: warning: Function parameter or member > 'input_dev' not described in 'drv2665_data' > drivers/input/misc/drv2665.c:59: warning: Function parameter or member > 'client' not described in 'drv2665_data' > drivers/input/misc/drv2665.c:59: warning: Function parameter or member > 'regmap' not described in 'drv2665_data' > drivers/input/misc/drv2665.c:59: warning: Function parameter or member > 'work' not described in 'drv2665_data' > drivers/input/misc/drv2665.c:59: warning: Function parameter or member > 'regulator' not described in 'drv2665_data' > > Cc: Dmitry Torokhov > Cc: Dan Murphy > Cc: linux-in...@vger.kernel.org > Signed-off-by: Lee Jones Applied, thank you. -- Dmitry
Re: [PATCH 16/20] input: misc: drv260x: Fix kernel-doc formatting and remove one abuse
On Wed, Nov 04, 2020 at 04:24:23PM +, Lee Jones wrote:
> Fixes the following W=1 kernel build warning(s):
>
> drivers/input/misc/drv260x.c:194: warning: Function parameter or member
> 'input_dev' not described in 'drv260x_data'
> drivers/input/misc/drv260x.c:194: warning: Function parameter or member
> 'client' not described in 'drv260x_data'
> drivers/input/misc/drv260x.c:194: warning: Function parameter or member
> 'regmap' not described in 'drv260x_data'
> drivers/input/misc/drv260x.c:194: warning: Function parameter or member
> 'work' not described in 'drv260x_data'
> drivers/input/misc/drv260x.c:194: warning: Function parameter or member
> 'enable_gpio' not described in 'drv260x_data'
> drivers/input/misc/drv260x.c:194: warning: Function parameter or member
> 'regulator' not described in 'drv260x_data'
> drivers/input/misc/drv260x.c:194: warning: Function parameter or member
> 'magnitude' not described in 'drv260x_data'
> drivers/input/misc/drv260x.c:194: warning: Function parameter or member
> 'mode' not described in 'drv260x_data'
> drivers/input/misc/drv260x.c:194: warning: Function parameter or member
> 'library' not described in 'drv260x_data'
> drivers/input/misc/drv260x.c:194: warning: Function parameter or member
> 'rated_voltage' not described in 'drv260x_data'
> drivers/input/misc/drv260x.c:194: warning: Function parameter or member
> 'overdrive_voltage' not described in 'drv260x_data'
> drivers/input/misc/drv260x.c:244: warning: Function parameter or member
> 'voltage' not described in 'drv260x_calculate_voltage'
>
> Cc: Dmitry Torokhov
> Cc: Dan Murphy
> Cc: linux-in...@vger.kernel.org
> Signed-off-by: Lee Jones
> ---
> drivers/input/misc/drv260x.c | 26 +-
> 1 file changed, 13 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/input/misc/drv260x.c b/drivers/input/misc/drv260x.c
> index 79d7fa710a714..fabe106d499d4 100644
> --- a/drivers/input/misc/drv260x.c
> +++ b/drivers/input/misc/drv260x.c
> @@ -167,17 +167,17 @@
>
> /**
> * struct drv260x_data -
> - * @input_dev - Pointer to the input device
> - * @client - Pointer to the I2C client
> - * @regmap - Register map of the device
> - * @work - Work item used to off load the enable/disable of the vibration
> - * @enable_gpio - Pointer to the gpio used for enable/disabling
> - * @regulator - Pointer to the regulator for the IC
> - * @magnitude - Magnitude of the vibration event
> - * @mode - The operating mode of the IC (LRA_NO_CAL, ERM or LRA)
> - * @library - The vibration library to be used
> - * @rated_voltage - The rated_voltage of the actuator
> - * @overdriver_voltage - The over drive voltage of the actuator
> + * @input_dev: Pointer to the input device
> + * @client: Pointer to the I2C client
> + * @regmap: Register map of the device
> + * @work: Work item used to off load the enable/disable of the vibration
> + * @enable_gpio: Pointer to the gpio used for enable/disabling
> + * @regulator: Pointer to the regulator for the IC
> + * @magnitude: Magnitude of the vibration event
> + * @mode: The operating mode of the IC (LRA_NO_CAL, ERM or LRA)
> + * @library: The vibration library to be used
> + * @rated_voltage: The rated_voltage of the actuator
> + * @overdriver_voltage: The over drive voltage of the actuator
Applied with this typo fixed as well.
> **/
> struct drv260x_data {
> struct input_dev *input_dev;
> @@ -234,12 +234,12 @@ static const struct reg_default drv260x_reg_defs[] = {
> #define DRV260X_DEF_RATED_VOLT 0x90
> #define DRV260X_DEF_OD_CLAMP_VOLT0x90
>
> -/**
> +/*
> * Rated and Overdriver Voltages:
> * Calculated using the formula r = v * 255 / 5.6
> * where r is what will be written to the register
> * and v is the rated or overdriver voltage of the actuator
> - **/
> + */
> static int drv260x_calculate_voltage(unsigned int voltage)
> {
> return (voltage * 255 / 5600);
> --
> 2.25.1
>
Thanks.
--
Dmitry
drivers/gpu/drm/bridge/sil-sii8620.c:2355: undefined reference to `extcon_unregister_notifier'
Hi Masahiro,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: f8394f232b1eab649ce2df5c5f15b0e528c92091
commit: def2fbffe62c00c330c7f41584a356001179c59c kconfig: allow symbols implied
by y to become m
date: 8 months ago
config: i386-randconfig-r022-20201106 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-15) 9.3.0
reproduce (this is a W=1 build):
#
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=def2fbffe62c00c330c7f41584a356001179c59c
git remote add linus
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout def2fbffe62c00c330c7f41584a356001179c59c
# save the attached .config to linux build tree
make W=1 ARCH=i386
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
ld: drivers/gpu/drm/bridge/sil-sii8620.o: in function `sii8620_remove':
>> drivers/gpu/drm/bridge/sil-sii8620.c:2355: undefined reference to
>> `extcon_unregister_notifier'
ld: drivers/gpu/drm/bridge/sil-sii8620.o: in function `sii8620_extcon_init':
>> drivers/gpu/drm/bridge/sil-sii8620.c:2179: undefined reference to
>> `extcon_find_edev_by_node'
ld: drivers/gpu/drm/bridge/sil-sii8620.c:2191: undefined reference to
`extcon_register_notifier'
ld: drivers/gpu/drm/bridge/sil-sii8620.o: in function `sii8620_extcon_work':
>> drivers/gpu/drm/bridge/sil-sii8620.c:2139: undefined reference to
>> `extcon_get_state'
vim +2355 drivers/gpu/drm/bridge/sil-sii8620.c
688838442147d9d Maciej Purski2018-02-27 2162
688838442147d9d Maciej Purski2018-02-27 2163 static int
sii8620_extcon_init(struct sii8620 *ctx)
688838442147d9d Maciej Purski2018-02-27 2164 {
688838442147d9d Maciej Purski2018-02-27 2165 struct extcon_dev *edev;
688838442147d9d Maciej Purski2018-02-27 2166 struct device_node
*musb, *muic;
688838442147d9d Maciej Purski2018-02-27 2167 int ret;
688838442147d9d Maciej Purski2018-02-27 2168
688838442147d9d Maciej Purski2018-02-27 2169 /* get micro-USB
connector node */
688838442147d9d Maciej Purski2018-02-27 2170 musb =
of_graph_get_remote_node(ctx->dev->of_node, 1, -1);
688838442147d9d Maciej Purski2018-02-27 2171 /* next get micro-USB
Interface Controller node */
688838442147d9d Maciej Purski2018-02-27 2172 muic =
of_get_next_parent(musb);
688838442147d9d Maciej Purski2018-02-27 2173
688838442147d9d Maciej Purski2018-02-27 2174 if (!muic) {
688838442147d9d Maciej Purski2018-02-27 2175
dev_info(ctx->dev, "no extcon found, switching to 'always on' mode\n");
688838442147d9d Maciej Purski2018-02-27 2176 return 0;
688838442147d9d Maciej Purski2018-02-27 2177 }
688838442147d9d Maciej Purski2018-02-27 2178
688838442147d9d Maciej Purski2018-02-27 @2179 edev =
extcon_find_edev_by_node(muic);
688838442147d9d Maciej Purski2018-02-27 2180 of_node_put(muic);
688838442147d9d Maciej Purski2018-02-27 2181 if (IS_ERR(edev)) {
688838442147d9d Maciej Purski2018-02-27 2182 if
(PTR_ERR(edev) == -EPROBE_DEFER)
688838442147d9d Maciej Purski2018-02-27 2183 return
-EPROBE_DEFER;
688838442147d9d Maciej Purski2018-02-27 2184
dev_err(ctx->dev, "Invalid or missing extcon\n");
688838442147d9d Maciej Purski2018-02-27 2185 return
PTR_ERR(edev);
688838442147d9d Maciej Purski2018-02-27 2186 }
688838442147d9d Maciej Purski2018-02-27 2187
688838442147d9d Maciej Purski2018-02-27 2188 ctx->extcon = edev;
688838442147d9d Maciej Purski2018-02-27 2189
ctx->extcon_nb.notifier_call = sii8620_extcon_notifier;
688838442147d9d Maciej Purski2018-02-27 2190
INIT_WORK(>extcon_wq, sii8620_extcon_work);
688838442147d9d Maciej Purski2018-02-27 2191 ret =
extcon_register_notifier(edev, EXTCON_DISP_MHL, >extcon_nb);
688838442147d9d Maciej Purski2018-02-27 2192 if (ret) {
688838442147d9d Maciej Purski2018-02-27 2193
dev_err(ctx->dev, "failed to register notifier for MHL\n");
688838442147d9d Maciej Purski2018-02-27 2194 return ret;
688838442147d9d Maciej Purski2018-02-27 2195 }
688838442147d9d Maciej Purski2018-02-27 2196
688838442147d9d Maciej Purski2018-02-27 2197 return 0;
688838442147d9d Maciej Purski2018-02-27 2198 }
688838442147d9d Maciej Purski2018-02-27 2199
ce6e153f414a73a Andrzej Hajda2016-10-10 2200 static inline struct sii8620
*bridge_to_sii8620(struct drm_bridge *bridge)
ce6e153f414a73a Andrzej Hajda2016-10-10 2201 {
ce6e153f414a73a Andrzej Hajda2016-10-10 2202 return
container_of(bridge,
Re: [RFC PATCH v3] sched/fair: select idle cpu from idle cpumask for task wakeup
On 2020/11/6 15:58, Vincent Guittot wrote:
> On Wed, 21 Oct 2020 at 17:05, Aubrey Li wrote:
>>
>> From: Aubrey Li
>>
>> Added idle cpumask to track idle cpus in sched domain. When a CPU
>> enters idle, its corresponding bit in the idle cpumask will be set,
>> and when the CPU exits idle, its bit will be cleared.
>>
>> When a task wakes up to select an idle cpu, scanning idle cpumask
>> has low cost than scanning all the cpus in last level cache domain,
>> especially when the system is heavily loaded.
>>
>> v2->v3:
>> - change setting idle cpumask to every idle entry, otherwise schbench
>> has a regression of 99th percentile latency.
>> - change clearing idle cpumask to nohz_balancer_kick(), so updating
>> idle cpumask is ratelimited in the idle exiting path.
>> - set SCHED_IDLE cpu in idle cpumask to allow it as a wakeup target.
>>
>> v1->v2:
>> - idle cpumask is updated in the nohz routines, by initializing idle
>> cpumask with sched_domain_span(sd), nohz=off case remains the original
>> behavior.
>>
>> Cc: Mel Gorman
>> Cc: Vincent Guittot
>> Cc: Qais Yousef
>> Cc: Valentin Schneider
>> Cc: Jiang Biao
>> Cc: Tim Chen
>> Signed-off-by: Aubrey Li
>> ---
>> include/linux/sched/topology.h | 13 ++
>> kernel/sched/fair.c| 45 +-
>> kernel/sched/idle.c| 1 +
>> kernel/sched/sched.h | 1 +
>> kernel/sched/topology.c| 3 ++-
>> 5 files changed, 61 insertions(+), 2 deletions(-)
>>
>> diff --git a/include/linux/sched/topology.h b/include/linux/sched/topology.h
>> index fb11091129b3..43a641d26154 100644
>> --- a/include/linux/sched/topology.h
>> +++ b/include/linux/sched/topology.h
>> @@ -65,8 +65,21 @@ struct sched_domain_shared {
>> atomic_tref;
>> atomic_tnr_busy_cpus;
>> int has_idle_cores;
>> + /*
>> +* Span of all idle CPUs in this domain.
>> +*
>> +* NOTE: this field is variable length. (Allocated dynamically
>> +* by attaching extra space to the end of the structure,
>> +* depending on how many CPUs the kernel has booted up with)
>> +*/
>> + unsigned long idle_cpus_span[];
>> };
>>
>> +static inline struct cpumask *sds_idle_cpus(struct sched_domain_shared *sds)
>> +{
>> + return to_cpumask(sds->idle_cpus_span);
>> +}
>> +
>> struct sched_domain {
>> /* These fields must be setup */
>> struct sched_domain __rcu *parent; /* top domain must be null
>> terminated */
>> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
>> index 6b3b59cc51d6..088d1995594f 100644
>> --- a/kernel/sched/fair.c
>> +++ b/kernel/sched/fair.c
>> @@ -6023,6 +6023,38 @@ void __update_idle_core(struct rq *rq)
>> rcu_read_unlock();
>> }
>>
>> +static DEFINE_PER_CPU(bool, cpu_idle_state);
>> +/*
>> + * Update cpu idle state and record this information
>> + * in sd_llc_shared->idle_cpus_span.
>> + */
>> +void update_idle_cpumask(struct rq *rq, bool idle_state)
>> +{
>> + struct sched_domain *sd;
>> + int cpu = cpu_of(rq);
>> +
>> + /*
>> +* No need to update idle cpumask if the state
>> +* does not change.
>> +*/
>> + if (per_cpu(cpu_idle_state, cpu) == idle_state)
>> + return;
>> +
>> + per_cpu(cpu_idle_state, cpu) = idle_state;
>> +
>> + rcu_read_lock();
>> +
>> + sd = rcu_dereference(per_cpu(sd_llc, cpu));
>> + if (!sd || !sd->shared)
>> + goto unlock;
>> + if (idle_state)
>> + cpumask_set_cpu(cpu, sds_idle_cpus(sd->shared));
>> + else
>> + cpumask_clear_cpu(cpu, sds_idle_cpus(sd->shared));
>> +unlock:
>> + rcu_read_unlock();
>> +}
>> +
>> /*
>> * Scan the entire LLC domain for idle cores; this dynamically switches off
>> if
>> * there are no idle cores left in the system; tracked through
>> @@ -6136,7 +6168,12 @@ static int select_idle_cpu(struct task_struct *p,
>> struct sched_domain *sd, int t
>>
>> time = cpu_clock(this);
>>
>> - cpumask_and(cpus, sched_domain_span(sd), p->cpus_ptr);
>> + /*
>> +* sched_domain_shared is set only at shared cache level,
>> +* this works only because select_idle_cpu is called with
>> +* sd_llc.
>> +*/
>> + cpumask_and(cpus, sds_idle_cpus(sd->shared), p->cpus_ptr);
>>
>> for_each_cpu_wrap(cpu, cpus, target) {
>> if (!--nr)
>> @@ -10070,6 +10107,12 @@ static void nohz_balancer_kick(struct rq *rq)
>> if (unlikely(rq->idle_balance))
>> return;
>>
>> + /* The CPU is not in idle, update idle cpumask */
>> + if (unlikely(sched_idle_cpu(cpu))) {
>> + /* Allow SCHED_IDLE cpu as a wakeup target */
>> + update_idle_cpumask(rq, true);
>> + } else
>> + update_idle_cpumask(rq, false);
>
> update_idle_cpumask(rq, sched_idle_cpu(cpu)); ?
This looks
Re: [PATCH virtio] virtio: virtio_console: fix DMA memory allocation for rproc serial
On 2020/11/5 下午8:22, Alexander Lobakin wrote:
From: Jason Wang
Date: Thu, 5 Nov 2020 11:10:24 +0800
Hi Jason,
On 2020/11/4 下午11:31, Alexander Lobakin wrote:
Since commit 086d08725d34 ("remoteproc: create vdev subdevice with
specific dma memory pool"), every remoteproc has a DMA subdevice
("remoteprocX#vdevYbuffer") for each virtio device, which inherits
DMA capabilities from the corresponding platform device. This allowed
to associate different DMA pools with each vdev, and required from
virtio drivers to perform DMA operations with the parent device
(vdev->dev.parent) instead of grandparent (vdev->dev.parent->parent).
virtio_rpmsg_bus was already changed in the same merge cycle with
commit d999b622fcfb ("rpmsg: virtio: allocate buffer from parent"),
but virtio_console did not. In fact, operations using the grandparent
worked fine while the grandparent was the platform device, but since
commit c774ad010873 ("remoteproc: Fix and restore the parenting
hierarchy for vdev") this was changed, and now the grandparent device
is the remoteproc device without any DMA capabilities.
So, starting v5.8-rc1 the following warning is observed:
[2.483925] [ cut here ]
[2.489148] WARNING: CPU: 3 PID: 101 at kernel/dma/mapping.c:427 0x80e7eee8
[2.489152] Modules linked in: virtio_console(+)
[2.503737] virtio_rpmsg_bus rpmsg_core
[2.508903]
[2.528898]
[2.913043]
[2.914907] ---[ end trace 93ac8746beab612c ]---
[2.920102] virtio-ports vport1p0: Error allocating inbufs
kernel/dma/mapping.c:427 is:
WARN_ON_ONCE(!dev->coherent_dma_mask);
obviously because the grandparent now is remoteproc dev without any
DMA caps:
[3.104943] Parent: remoteproc0#vdev1buffer, grandparent: remoteproc0
Fix this the same way as it was for virtio_rpmsg_bus, using just the
parent device (vdev->dev.parent, "remoteprocX#vdevYbuffer") for DMA
operations.
This also allows now to reserve DMA pools/buffers for rproc serial
via Device Tree.
Fixes: c774ad010873 ("remoteproc: Fix and restore the parenting hierarchy for
vdev")
Cc: sta...@vger.kernel.org # 5.1+
Signed-off-by: Alexander Lobakin
---
drivers/char/virtio_console.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/char/virtio_console.c b/drivers/char/virtio_console.c
index a2da8f768b94..1836cc56e357 100644
--- a/drivers/char/virtio_console.c
+++ b/drivers/char/virtio_console.c
@@ -435,12 +435,12 @@ static struct port_buffer *alloc_buf(struct virtio_device
*vdev, size_t buf_size
/*
* Allocate DMA memory from ancestor. When a virtio
* device is created by remoteproc, the DMA memory is
-* associated with the grandparent device:
-* vdev => rproc => platform-dev.
+* associated with the parent device:
+* virtioY => remoteprocX#vdevYbuffer.
*/
- if (!vdev->dev.parent || !vdev->dev.parent->parent)
+ buf->dev = vdev->dev.parent;
+ if (!buf->dev)
goto free_buf;
- buf->dev = vdev->dev.parent->parent;
I wonder it could be the right time to introduce dma_dev for virtio
instead of depending on something magic via parent.
This patch are meant to hit RC window and stable trees as a fix of
the bug that is present since v5.8-rc1. So any new features are out
of scope of this particular fix.
Right.
The idea of DMAing through "dev->parent" is that "virtioX" itself is a
logical dev, not the real one, but its parent *is*. This logic is used
across the whole tree -- every subsystem creates its own logical device,
but drivers should always use the backing PCI/platform/etc. devices for
DMA operations, which represent the real hardware.
Yes, so what I meant is to use different variables for DMA and
hierarchy. So it's the responsibility of the lower layer to pass a
correct "dma_dev" to the upper layer instead of depending parent.
Anyway for this patch.
Acked-by: Jason Wang
Thanks
(Btw I don't even notice that there's transport specific code in virtio
console, it's better to avoid it)
Thanks
Thanks,
Al
/* Increase device refcnt to avoid freeing it */
get_device(buf->dev);
Re: [PATCH v8 -tip 00/26] Core scheduling
On 2020/11/7 1:54, Joel Fernandes wrote: > On Fri, Nov 06, 2020 at 10:58:58AM +0800, Li, Aubrey wrote: > >>> >>> -- workload D, new added syscall workload, performance drop in cs_on: >>> +--+--+---+ >>> | | ** | will-it-scale * 192 | >>> | | | (pipe based context_switch) | >>> +==+==+===+ >>> | cgroup | ** | cg_will-it-scale | >>> +--+--+---+ >>> | record_item | ** | threads_avg | >>> +--+--+---+ >>> | coresched_normalized | ** | 0.2 | >>> +--+--+---+ >>> | default_normalized | ** | 1 | >>> +--+--+---+ >>> | smtoff_normalized| ** | 0.89 | >>> +--+--+---+ >> >> will-it-scale may be a very extreme case. The story here is, >> - On one sibling reader/writer gets blocked and tries to schedule another >> reader/writer in. >> - The other sibling tries to wake up reader/writer. >> >> Both CPUs are acquiring rq->__lock, >> >> So when coresched off, they are two different locks, lock stat(1 second >> delta) below: >> >> class namecon-bouncescontentions waittime-min waittime-max >> waittime-total waittime-avgacq-bounces acquisitions holdtime-min >> holdtime-max holdtime-total holdtime-avg >> >__lock: 210210 0.10 3.04 >> 180.87 0.86797 79165021 0.03 >> 20.6960650198.34 0.77 >> >> But when coresched on, they are actually one same lock, lock stat(1 second >> delta) below: >> >> class namecon-bouncescontentions waittime-min waittime-max >> waittime-total waittime-avgacq-bounces acquisitions holdtime-min >> holdtime-max holdtime-total holdtime-avg >> >__lock: 64794596484857 0.05 216.46 >> 60829776.85 9.388346319 15399739 0.03 >> 95.5681119515.38 5.27 >> >> This nature of core scheduling may degrade the performance of similar >> workloads with frequent context switching. > > When core sched is off, is SMT off as well? From the above table, it seems to > be. So even for core sched off, there will be a single lock per physical CPU > core (assuming SMT is also off) right? Or did I miss something? > The table includes 3 cases: - default: SMT on, coresched off - coresched:SMT on, coresched on - smtoff: SMT off, coresched off I was comparing the default(coresched off & SMT on) case with (coresched on & SMT on) case. If SMT off, then reader and writer on the different cores have different rq->lock, so the lock contention is not that serious. class namecon-bouncescontentions waittime-min waittime-max waittime-total waittime-avgacq-bounces acquisitions holdtime-min holdtime-max holdtime-total holdtime-avg >__lock: 60 60 0.11 1.92 41.33 0.69127 67184172 0.03 22.9533160428.37 0.49 Does this address your concern? Thanks, -Aubrey
linux-next: manual merge of the akpm-current tree with the tip tree
Hi all,
Today's linux-next merge of the akpm-current tree got a conflict in:
arch/arc/Kconfig
between commit:
39cac191ff37 ("arc/mm/highmem: Use generic kmap atomic implementation")
from the tip tree and commit:
b41c56d2a9e6 ("arc: use FLATMEM with freeing of unused memory map instead of
DISCONTIGMEM")
from the akpm-current tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc arch/arc/Kconfig
index 1a1ee5c4c2e7,c874f8ab0341..
--- a/arch/arc/Kconfig
+++ b/arch/arc/Kconfig
@@@ -505,8 -507,7 +506,8 @@@ config LINUX_RAM_BAS
config HIGHMEM
bool "High Memory Support"
- select ARCH_DISCONTIGMEM_ENABLE
+ select HAVE_ARCH_PFN_VALID
+ select KMAP_LOCAL
help
With ARC 2G:2G address split, only upper 2G is directly addressable by
kernel. Enable this to potentially allow access to rest of 2G and PAE
pgpHQ1nYBwbXl.pgp
Description: OpenPGP digital signature
Re: [PATCH v1 17/30] mmc: sdhci-tegra: Support OPP and core voltage scaling
On 09-11-20, 08:44, Dmitry Osipenko wrote: > 09.11.2020 08:35, Viresh Kumar пишет: > > On 09-11-20, 08:19, Dmitry Osipenko wrote: > >> Thanks, I made it in a different way by simply adding helpers to the > >> pm_opp.h which use devm_add_action_or_reset(). This doesn't require to > >> add new kernel symbols. > > > > I will prefer to add it in core.c itself, and yes > > devm_add_action_or_reset() looks better. But I am still not sure for > > which helpers do we need the devm_*() variants, as this is only useful > > for non-CPU devices. But if we have users that we can add right now, > > why not. > > All current non-CPU drivers (devfreq, mmc, memory, etc) can benefit from it. > > For Tegra drivers we need these variants: > > devm_pm_opp_set_supported_hw() > devm_pm_opp_set_regulators() [if we won't use GENPD] > devm_pm_opp_set_clkname() > devm_pm_opp_of_add_table() I tried to look earlier for the stuff already merged in and didn't find a lot of stuff where the devm_* could be used, maybe I missed some of it. Frank, would you like to refresh your series based on suggestions from Dmitry and make other drivers adapt to the new APIs ? -- viresh
Re: [PATCH] touchscreen: use kobj_to_dev() API
On Mon, Nov 09, 2020 at 11:43:54AM +0800, Wang Qing wrote: > Use kobj_to_dev() instead of container_of(). > > Signed-off-by: Wang Qing Applied, thank you. -- Dmitry
RE: [PATCH v5 10/14] clk: imx: Add generic blk-ctl driver
> -Original Message-
> From: Abel Vesa [mailto:abel.v...@nxp.com]
> Sent: Tuesday, November 3, 2020 7:18 PM
> To: Mike Turquette ; Stephen Boyd
> ; Adam Ford ; Marek Vasut
> ; Lucas Stach ; Rob
> Herring ; Shawn Guo ; Sascha
> Hauer ; Fabio Estevam ;
> Anson Huang ; Jacky Bai ; Peng
> Fan ; Aisheng Dong
> Cc: dl-linux-imx ; linux-arm-ker...@lists.infradead.org;
> Linux Kernel Mailing List ;
> linux-...@vger.kernel.org; devicet...@vger.kernel.org; Abel Vesa
>
> Subject: [PATCH v5 10/14] clk: imx: Add generic blk-ctl driver
>
> The i.MX8MP platform introduces a new type of IP which is called BLK_CTL in
> RM and usually is comprised of some GPRs that are considered too generic to
> be part of any dedicated IP from that specific subsystem.
>
> In general, some of the GPRs have some clock bits, some have reset bits, so in
> order to be able to use the imx clock API, this needs to be in a clock driver.
> From there it can use the reset controller API and leave the rest to the
> syscon.
>
From the test I did internally, this blk ctrl implementation will have system
deadlock risk due to the clock prepare mutex.
Please make sure it can works without deadlock.
BR
Jacky Bai
> Signed-off-by: Abel Vesa
> ---
> drivers/clk/imx/Makefile | 2 +-
> drivers/clk/imx/clk-blk-ctl.c | 302
> ++
> drivers/clk/imx/clk-blk-ctl.h | 80 +++
> 3 files changed, 383 insertions(+), 1 deletion(-) create mode 100644
> drivers/clk/imx/clk-blk-ctl.c create mode 100644
> drivers/clk/imx/clk-blk-ctl.h
>
> diff --git a/drivers/clk/imx/Makefile b/drivers/clk/imx/Makefile index
> dd6a737..3d6d9cb 100644
> --- a/drivers/clk/imx/Makefile
> +++ b/drivers/clk/imx/Makefile
> @@ -23,7 +23,7 @@ obj-$(CONFIG_MXC_CLK) += mxc-clk.o
>
> obj-$(CONFIG_CLK_IMX8MM) += clk-imx8mm.o
> obj-$(CONFIG_CLK_IMX8MN) += clk-imx8mn.o
> -obj-$(CONFIG_CLK_IMX8MP) += clk-imx8mp.o
> +obj-$(CONFIG_CLK_IMX8MP) += clk-imx8mp.o clk-blk-ctl.o
> obj-$(CONFIG_CLK_IMX8MQ) += clk-imx8mq.o
>
> obj-$(CONFIG_MXC_CLK_SCU) += clk-imx-scu.o clk-imx-lpcg-scu.o diff --git
> a/drivers/clk/imx/clk-blk-ctl.c b/drivers/clk/imx/clk-blk-ctl.c new file mode
> 100644 index ..9ac0ed0
> --- /dev/null
> +++ b/drivers/clk/imx/clk-blk-ctl.c
> @@ -0,0 +1,302 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright 2020 NXP.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "clk.h"
> +#include "clk-blk-ctl.h"
> +
> +struct imx_reset_hw {
> + u32 offset;
> + u32 shift;
> + u32 mask;
> + unsigned long asserted;
> +};
> +
> +struct imx_pm_safekeep_info {
> + uint32_t *regs_values;
> + uint32_t *regs_offsets;
> + uint32_t regs_num;
> +};
> +
> +struct imx_blk_ctl_drvdata {
> + void __iomem *base;
> + struct reset_controller_dev rcdev;
> + struct imx_reset_hw *rst_hws;
> + struct imx_pm_safekeep_info pm_info;
> +
> + spinlock_t lock;
> +};
> +
> +static void __maybe_unused imx_blk_ctl_read_write(struct device *dev,
> + bool write)
> +{
> + struct imx_blk_ctl_drvdata *drvdata = dev_get_drvdata(dev);
> + struct imx_pm_safekeep_info *pm_info = >pm_info;
> + void __iomem *base = drvdata->base;
> + int i;
> +
> + if (!pm_info->regs_num)
> + return;
> +
> + for (i = 0; i < pm_info->regs_num; i++) {
> + u32 offset = pm_info->regs_offsets[i];
> +
> + if (write)
> + writel(pm_info->regs_values[i], base + offset);
> + else
> + pm_info->regs_values[i] = readl(base + offset);
> + }
> +
> +}
> +
> +static int __maybe_unused imx_blk_ctl_runtime_suspend(struct device
> +*dev) {
> + imx_blk_ctl_read_write(dev, false);
> +
> + return 0;
> +}
> +
> +static int __maybe_unused imx_blk_ctl_runtime_resume(struct device
> +*dev) {
> + imx_blk_ctl_read_write(dev, true);
> +
> + return 0;
> +}
> +
> +const struct dev_pm_ops imx_blk_ctl_pm_ops = {
> + SET_RUNTIME_PM_OPS(imx_blk_ctl_runtime_suspend,
> +imx_blk_ctl_runtime_resume, NULL)
> + SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
> +pm_runtime_force_resume)
> +};
> +EXPORT_SYMBOL_GPL(imx_blk_ctl_pm_ops);
> +
> +static int imx_blk_ctl_reset_set(struct reset_controller_dev *rcdev,
> + unsigned long id, bool assert)
> +{
> + struct imx_blk_ctl_drvdata *drvdata = container_of(rcdev,
> + struct imx_blk_ctl_drvdata, rcdev);
> + unsigned int offset = drvdata->rst_hws[id].offset;
> + unsigned int shift = drvdata->rst_hws[id].shift;
> + unsigned int mask = drvdata->rst_hws[id].mask;
> + void __iomem *reg_addr = drvdata->base + offset;
> + unsigned long flags;
> + u32 reg;
> +
> +
Re: [PATCH v1 17/30] mmc: sdhci-tegra: Support OPP and core voltage scaling
09.11.2020 08:35, Viresh Kumar пишет: > On 09-11-20, 08:19, Dmitry Osipenko wrote: >> Thanks, I made it in a different way by simply adding helpers to the >> pm_opp.h which use devm_add_action_or_reset(). This doesn't require to >> add new kernel symbols. > > I will prefer to add it in core.c itself, and yes > devm_add_action_or_reset() looks better. But I am still not sure for > which helpers do we need the devm_*() variants, as this is only useful > for non-CPU devices. But if we have users that we can add right now, > why not. All current non-CPU drivers (devfreq, mmc, memory, etc) can benefit from it. For Tegra drivers we need these variants: devm_pm_opp_set_supported_hw() devm_pm_opp_set_regulators() [if we won't use GENPD] devm_pm_opp_set_clkname() devm_pm_opp_of_add_table()
linux-next: build warning after merge of the mac80211-next tree
Hi all,
After merging the mac80211-next tree, today's linux-next build (htmldocs)
produced this warning:
Documentation/driver-api/80211/cfg80211:48: include/net/cfg80211.h:1014:
WARNING: Unexpected indentation.
Documentation/driver-api/80211/cfg80211:48: include/net/cfg80211.h:1016:
WARNING: Block quote ends without a blank line; unexpected unindent.
Documentation/driver-api/80211/cfg80211:48: include/net/cfg80211.h:1019:
WARNING: Unexpected indentation.
Introduced by commit
9f0ffa418483 ("cfg80211: Add support to configure SAE PWE value to drivers")
--
Cheers,
Stephen Rothwell
pgpSMw9hYjmGb.pgp
Description: OpenPGP digital signature
[RFC PATCH 2/2] clk: sunxi-ng: a64: disable mux and pll notifiers for CPUX reclocking
After the dividers of PLL-CPUX disabled, there's no need for PLL-CPUX to
be gated when tweaking the clock of CPUX, thus reparenting CPUX to
osc24M is also now not needed.
Remove these notifiers.
Preventing reparenting CPUX is said to be able to help solving the issue
that the timer jumps backward according to Ondrej Jirman.
Signed-off-by: Icenowy Zheng
---
drivers/clk/sunxi-ng/ccu-sun50i-a64.c | 14 +-
1 file changed, 1 insertion(+), 13 deletions(-)
diff --git a/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
b/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
index 6108d150a0e3..67d570efe5bd 100644
--- a/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
+++ b/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
@@ -943,7 +943,6 @@ static int sun50i_a64_ccu_probe(struct platform_device
*pdev)
struct resource *res;
void __iomem *reg;
u32 val;
- int ret;
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
reg = devm_ioremap_resource(>dev, res);
@@ -1029,18 +1028,7 @@ static int sun50i_a64_ccu_probe(struct platform_device
*pdev)
writel(val, reg + SUN50I_A64_CPUX_AXI_REG);
}
- ret = sunxi_ccu_probe(pdev->dev.of_node, reg, _a64_ccu_desc);
- if (ret)
- return ret;
-
- /* Gate then ungate PLL CPU after any rate changes */
- ccu_pll_notifier_register(_a64_pll_cpu_nb);
-
- /* Reparent CPU during PLL CPU rate changes */
- ccu_mux_notifier_register(pll_cpux_clk.common.hw.clk,
- _a64_cpu_nb);
-
- return 0;
+ return sunxi_ccu_probe(pdev->dev.of_node, reg, _a64_ccu_desc);
}
static const struct of_device_id sun50i_a64_ccu_ids[] = {
--
2.28.0
Re: [PATCH v1 17/30] mmc: sdhci-tegra: Support OPP and core voltage scaling
On 09-11-20, 08:19, Dmitry Osipenko wrote:
> Thanks, I made it in a different way by simply adding helpers to the
> pm_opp.h which use devm_add_action_or_reset(). This doesn't require to
> add new kernel symbols.
I will prefer to add it in core.c itself, and yes
devm_add_action_or_reset() looks better. But I am still not sure for
which helpers do we need the devm_*() variants, as this is only useful
for non-CPU devices. But if we have users that we can add right now,
why not.
> static inline int devm_pm_opp_of_add_table(struct device *dev)
> {
> int err;
>
> err = dev_pm_opp_of_add_table(dev);
> if (err)
> return err;
>
> err = devm_add_action_or_reset(dev, (void*)dev_pm_opp_remove_table,
> dev);
> if (err)
> return err;
>
> return 0;
> }
--
viresh
[RFC PATCH 1/2] clk: sunxi-ng: a64: disable dividers in PLL-CPUX
According to the user manual, PLL-CPUX have two dividers, in which P is
only allowed when the desired rate is less than 240MHz. As the CCU
framework have no such feature yet and the clock rate that allows P is
much lower than where we normally operate, disallow the usage of P
factor now.
M is not restricted in the user manual, however according to the BSP PLL
setup table (see [1]), it's not used at all. To follow what the BSP
does, disable this factor too.
Disabling the dividers will make it possible to remove the need to
switch to osc24M when doing frequency scaling on PLL-CPUX.
In order to prevent boot-time usage of dividers (current known mainline
U-Boot implementation use m = 2), tweaking of the factors are done when
probing CCU driver.
Signed-off-by: Icenowy Zheng
---
drivers/clk/sunxi-ng/ccu-sun50i-a64.c | 79 ++-
1 file changed, 77 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
b/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
index 5f66bf879772..6108d150a0e3 100644
--- a/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
+++ b/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
@@ -4,6 +4,7 @@
*/
#include
+#include
#include
#include
#include
@@ -23,13 +24,14 @@
#include "ccu-sun50i-a64.h"
+#define SUN50I_A64_PLL_CPUX_REG0x000
static struct ccu_nkmp pll_cpux_clk = {
.enable = BIT(31),
.lock = BIT(28),
.n = _SUNXI_CCU_MULT(8, 5),
.k = _SUNXI_CCU_MULT(4, 2),
- .m = _SUNXI_CCU_DIV(0, 2),
- .p = _SUNXI_CCU_DIV_MAX(16, 2, 4),
+ .m = _SUNXI_CCU_DIV_MAX(16, 2, 1),
+ .p = _SUNXI_CCU_DIV_MAX(0, 2, 1),
.common = {
.reg= 0x000,
.hw.init= CLK_HW_INIT("pll-cpux",
@@ -215,6 +217,7 @@ static SUNXI_CCU_NM_WITH_GATE_LOCK(pll_ddr1_clk, "pll-ddr1",
BIT(28), /* lock */
CLK_SET_RATE_UNGATE);
+#define SUN50I_A64_CPUX_AXI_REG0x050
static const char * const cpux_parents[] = { "osc32k", "osc24M",
"pll-cpux", "pll-cpux" };
static SUNXI_CCU_MUX(cpux_clk, "cpux", cpux_parents,
@@ -954,6 +957,78 @@ static int sun50i_a64_ccu_probe(struct platform_device
*pdev)
writel(0x515, reg + SUN50I_A64_PLL_MIPI_REG);
+ /* Disable any possible dividers on PLL-CPUX */
+ val = readl(reg + SUN50I_A64_PLL_CPUX_REG);
+ if (val & (GENMASK(17, 16) | GENMASK(1, 0))) {
+ unsigned int n, k, m, p;
+
+ n = ((val & GENMASK(12, 8)) >> 8) + 1;
+ k = ((val & GENMASK(5, 4)) >> 4) + 1;
+ m = (val & GENMASK(1, 0)) + 1;
+ p = 1 << ((val & GENMASK(17, 16)) >> 16);
+
+ /*
+* Known mainline U-Boot revisions never uses
+* divider p, and it will only use m when k = 3 or 4.
+* Specially judge for these cases, to satisfy
+* what will most possibly happen.
+* For m = 2 and k = 3, fractional change will be
+* applied to n, to mostly keep the clock rate.
+* For m = 2 and k = 4, just change to m = 1 and k = 2.
+* For other cases, just try to divide it from N.
+*/
+ if (p >= 2) {
+ n /= p;
+ p = 1;
+ }
+
+ if (m == 2) {
+ if (k == 3) {
+ k = 2;
+ n = n * 3 / 4;
+ m = 1;
+ }
+ if (k == 4) {
+ k = 2;
+ m = 1;
+ }
+ }
+
+ if (m >= 2) {
+ n /= m;
+ m = 1;
+ }
+
+ /* The user manual constrains n*k >= 10 */
+ if (n * k < 10) {
+ n = 10;
+ k = 1;
+ }
+
+ /* Switch CPUX clock to osc24M temporarily */
+ val = readl(reg + SUN50I_A64_CPUX_AXI_REG);
+ val &= ~GENMASK(17, 16);
+ val |= (1 << 16);
+ writel(val, reg + SUN50I_A64_CPUX_AXI_REG);
+ udelay(1);
+
+ /* Setup PLL-CPUX with new factors */
+ val = ((n - 1) << 8) | ((k - 1) << 4);
+ writel(val, reg + SUN50I_A64_PLL_CPUX_REG);
+ val |= BIT(31);
+ writel(val, reg + SUN50I_A64_PLL_CPUX_REG);
+ do {
+ /* Wait the PLL to lock */
+ val = readl(reg + SUN50I_A64_PLL_CPUX_REG);
+ } while (!(val & BIT(28)));
+
+ /* Switch CPUX clock back to PLL-CPUX
Re: [PATCH v2] x86/xen: don't unbind uninitialized lock_kicker_irq
On 07.11.20 02:11, Brian Masney wrote: When booting a hyperthreaded system with the kernel parameter 'mitigations=auto,nosmt', the following warning occurs: WARNING: CPU: 0 PID: 1 at drivers/xen/events/events_base.c:1112 unbind_from_irqhandler+0x4e/0x60 ... Hardware name: Xen HVM domU, BIOS 4.2.amazon 08/24/2006 ... Call Trace: xen_uninit_lock_cpu+0x28/0x62 xen_hvm_cpu_die+0x21/0x30 takedown_cpu+0x9c/0xe0 ? trace_suspend_resume+0x60/0x60 cpuhp_invoke_callback+0x9a/0x530 _cpu_up+0x11a/0x130 cpu_up+0x7e/0xc0 bringup_nonboot_cpus+0x48/0x50 smp_init+0x26/0x79 kernel_init_freeable+0xea/0x229 ? rest_init+0xaa/0xaa kernel_init+0xa/0x106 ret_from_fork+0x35/0x40 The secondary CPUs are not activated with the nosmt mitigations and only the primary thread on each CPU core is used. In this situation, xen_hvm_smp_prepare_cpus(), and more importantly xen_init_lock_cpu(), is not called, so the lock_kicker_irq is not initialized for the secondary CPUs. Let's fix this by exiting early in xen_uninit_lock_cpu() if the irq is not set to avoid the warning from above for each secondary CPU. Signed-off-by: Brian Masney Reviewed-by: Juergen Gross Juergen OpenPGP_0xB0DE9DD628BF132F.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
[RFC PATCH 0/2] clk: sunxi-ng: a64: Remove CPUX mux switching
According to Ondrej Jirman, switching of the mux of CPUX clock is one of the sources of timer jumps on A64 (and maybe this will also lead to timer jump on H3). This patchset tries to remove this mux by disabling the dividers in PLL-CPUX. Both the lack of reparent when relocking and the prevention of PLL-CPUX dividers are behaviors of the BSP kernel. Icenowy Zheng (2): clk: sunxi-ng: a64: disable dividers in PLL-CPUX clk: sunxi-ng: a64: disable mux and pll notifiers for CPUX reclocking drivers/clk/sunxi-ng/ccu-sun50i-a64.c | 93 ++- 1 file changed, 78 insertions(+), 15 deletions(-) -- 2.28.0
Re: [PATCH 2/2] opp: Don't create an OPP table from dev_pm_opp_get_opp_table()
09.11.2020 07:57, Viresh Kumar пишет: > On 09-11-20, 07:41, Dmitry Osipenko wrote: >> 09.11.2020 07:34, Viresh Kumar пишет: >>> On 06-11-20, 16:18, Dmitry Osipenko wrote: 06.11.2020 09:24, Viresh Kumar пишет: > It has been found that some users (like cpufreq-dt and others on LKML) > have abused the helper dev_pm_opp_get_opp_table() to create the OPP > table instead of just finding it, which is the wrong thing to do. This > routine was meant for OPP core's internal working and exposed the whole > functionality by mistake. > > Change the scope of dev_pm_opp_get_opp_table() to only finding the > table. The internal helpers _opp_get_opp_table*() are thus renamed to > _add_opp_table*(), dev_pm_opp_get_opp_table_indexed() is removed (as we > don't need the index field for finding the OPP table) and so the only > user, genpd, is updated. > > Note that the prototype of _add_opp_table() was already left in opp.h by > mistake when it was removed earlier and so we weren't required to add it > now. Hello Viresh, It looks like this is not an entirely correct change because previously it was possible to get an empty opp_table in order to use it for the dev_pm_opp_set_rate(), which would fall back to clk_set_rate if table is empty. Now it's not possible to get an empty table and dev_pm_opp_of_add_table() would error out if OPPs are missing in a device-tree. Hence it's not possible to implement a fall back without abusing opp_set_regulators() or opp_set_supported_hw() for getting the empty table. Or am I missing something? >>> >>> For that case you were always required to call >>> dev_pm_opp_set_clkname(), otherwise how would the OPP core know which >>> clock to set ? And the same shall work now as well. >> >> Why _allocate_opp_table() grabs the first default clk of a device and >> assigns it to the created table? > > Right, it was there so everybody isn't required to call > dev_pm_opp_set_clkname() if they don't need to pass a connection id > while getting the clock. But for the case of supporting empty OPP > tables for cases where we just want dev_pm_opp_set_rate() to act as > clk_set_rate() (in order for the drivers to avoid supporting two > different ways of doing so), we do need that call to be made. > > We need to add the OPP table explicitly and what happened with > dev_pm_opp_get_opp_table() was accidental and not what I wanted. > > drivers/mmc/host/sdhci-msm.c has an example of how this is done. > Alright, thank you for the clarification.
RE: [PATCH v4 06/17] PCI: add SIOV and IMS capability detection
> -Original Message- > From: Thomas Gleixner > Sent: Saturday, November 7, 2020 8:32 AM > To: Tian, Kevin ; Jason Gunthorpe > Cc: Jiang, Dave ; Bjorn Helgaas ; > vk...@kernel.org; Dey, Megha ; m...@kernel.org; > bhelg...@google.com; alex.william...@redhat.com; Pan, Jacob jun > ; Raj, Ashok ; Liu, Yi L > ; Lu, Baolu ; Kumar, Sanjay K > ; Luck, Tony ; > jing@intel.com; Williams, Dan J ; > kwankh...@nvidia.com; eric.au...@redhat.com; pa...@mellanox.com; > raf...@kernel.org; netan...@mellanox.com; shah...@mellanox.com; > yan.y.z...@linux.intel.com; pbonz...@redhat.com; Ortiz, Samuel > ; Hossain, Mona ; > dmaeng...@vger.kernel.org; linux-kernel@vger.kernel.org; linux- > p...@vger.kernel.org; k...@vger.kernel.org > Subject: RE: [PATCH v4 06/17] PCI: add SIOV and IMS capability detection > > On Fri, Nov 06 2020 at 09:48, Kevin Tian wrote: > >> From: Jason Gunthorpe > >> On Wed, Nov 04, 2020 at 01:34:08PM +, Tian, Kevin wrote: > >> The interrupt controller is responsible to create an addr/data pair > >> for an interrupt message. It sets the message format and ensures it > >> routes to the proper CPU interrupt handler. Everything about the > >> addr/data pair is owned by the platform interrupt controller. > >> > >> Devices do not create interrupts. They only trigger the addr/data pair > >> the platform gives them. > > > > I guess that we may just view it from different angles. On x86 platform, > > a MSI/IMS capable device directly composes interrupt messages, with > > addr/data pair filled by OS. If there is no IOMMU remapping enabled in > > the middle, the message just hits the CPU. Your description possibly > > is from software side, e.g. describing the hierarchical IRQ domain > > concept? > > No. The device composes nothing. If the interrupt is raised in the > device then the MSI block sends the message which was composed by the OS > and stored in the device's message store. For PCI/MSI that's the MSI or > MSIX table and for IMS that's either on device memory (as IDXD uses) or > some completely different location which Jason described. Sorry being inaccurate here. I actually meant the same thing as you described since I did mention addr/data pair filled by OS. Unfortunately I mistakenly thought that 'compose' has similar meaning to 'send' in English but clearly it's not and instead it's just about the message content. and for sure I also agree with your other clarifications regarding to architecture independent manner. Thanks Kevin > > This has absolutely nothing to do with the X86 platform. MSI is a > architecture independent mechanism: Send whatever the OS put into the > storage to raise an interrupt in the CPU. The device does neither know > whether that message is going to be intercepted by an interrupt > remapping unit or not. > > Stop claiming that any of this has anything to do with x86. It has > absolutely nothing to do with x86 and looking at MSI from an x86 > perspective instead of looking at it from the architecture agnostic > technical reality of MSI is the reason why we have this discussion at > all. > > We had a similar discussion vs. the way how IMS interrupts have to be > dealt with in terms of irq domains. Can you finally stop looking at > everything as a big x86/intel/platform lump and understand that things > are very well structured and seperated both at the hardware and at the > software level? > > > Do you mind providing the link? There were lots of discussions between > > you and Thomas. I failed to locate the exact mail when searching above > > keywords. > > In this thread: 20200821002424.119492...@linutronix.de and you were on > Cc > > Thanks, > > tglx >
Re: [PATCH v1 17/30] mmc: sdhci-tegra: Support OPP and core voltage scaling
09.11.2020 08:10, Viresh Kumar пишет:
> On 09-11-20, 08:08, Dmitry Osipenko wrote:
>> 09.11.2020 08:00, Viresh Kumar пишет:
>>> On 06-11-20, 21:41, Frank Lee wrote:
On Fri, Nov 6, 2020 at 9:18 PM Dmitry Osipenko wrote:
>
> 06.11.2020 09:15, Viresh Kumar пишет:
>> Setting regulators for count as 0 doesn't sound good to me.
>>
>> But, I understand that you don't want to have that if (have_regulator)
>> check, and it is a fair request. What I will instead do is, allow all
>> dev_pm_opp_put*() API to start accepting a NULL pointer for the OPP
>> table and fail silently. And so you won't be required to have this
>> unwanted check. But you will be required to save the pointer returned
>> back by dev_pm_opp_set_regulators(), which is the right thing to do
>> anyways.
>
> Perhaps even a better variant could be to add a devm versions of the OPP
> API functions, then drivers won't need to care about storing the
> opp_table pointer if it's unused by drivers.
I think so. The consumer may not be so concerned about the status of
these OPP tables.
If the driver needs to manage the release, it needs to add a pointer
to their driver global structure.
Maybe it's worth having these devm interfaces for opp.
>>>
>>> Sure if there are enough users of this, I am all for it. I was fine
>>> with the patches you sent, just that there were not a lot of users of
>>> it and so I pushed them back. If we find that we have more users of it
>>> now, we can surely get that back.
>>>
>>
>> There was already attempt to add the devm? Could you please give me a
>> link to the patches?
>>
>> I already prepared a patch which adds the devm helpers. It helps to keep
>> code cleaner and readable.
>
> https://lore.kernel.org/lkml/20201012135517.19468-1-fr...@allwinnertech.com/
>
Thanks, I made it in a different way by simply adding helpers to the
pm_opp.h which use devm_add_action_or_reset(). This doesn't require to
add new kernel symbols.
static inline int devm_pm_opp_of_add_table(struct device *dev)
{
int err;
err = dev_pm_opp_of_add_table(dev);
if (err)
return err;
err = devm_add_action_or_reset(dev, (void*)dev_pm_opp_remove_table,
dev);
if (err)
return err;
return 0;
}
Re: [PATCHv7 0/7] System Cache support for GPU and required SMMU support
On 2020-10-30 14:53, Sai Prakash Ranjan wrote: Some hardware variants contain a system cache or the last level cache(llc). This cache is typically a large block which is shared by multiple clients on the SOC. GPU uses the system cache to cache both the GPU data buffers(like textures) as well the SMMU pagetables. This helps with improved render performance as well as lower power consumption by reducing the bus traffic to the system memory. The system cache architecture allows the cache to be split into slices which then be used by multiple SOC clients. This patch series is an effort to enable and use two of those slices preallocated for the GPU, one for the GPU data buffers and another for the GPU SMMU hardware pagetables. Patch 1 - Patch 5 adds system cache support in SMMU and GPU driver. Patch 6 and 7 are minor cleanups for arm-smmu impl. Changes in v7: * Squash Jordan's patch to support MMU500 targets * Rebase on top of for-joerg/arm-smmu/updates and Jordan's short series for adreno-smmu impl Changes in v6: * Move table to arm-smmu-qcom (Robin) Changes in v5: * Drop cleanup of blank lines since it was intentional (Robin) * Rebase again on top of msm-next-pgtables as it moves pretty fast Changes in v4: * Drop IOMMU_SYS_CACHE prot flag * Rebase on top of https://gitlab.freedesktop.org/drm/msm/-/tree/msm-next-pgtables Changes in v3: * Fix domain attribute setting to before iommu_attach_device() * Fix few code style and checkpatch warnings * Rebase on top of Jordan's latest split pagetables and per-instance pagetables support Changes in v2: * Addressed review comments and rebased on top of Jordan's split pagetables series Jordan Crouse (1): drm/msm/a6xx: Add support for using system cache on MMU500 based targets Sai Prakash Ranjan (4): iommu/io-pgtable-arm: Add support to use system cache iommu/arm-smmu: Add domain attribute for system cache iommu: arm-smmu-impl: Use table to list QCOM implementations iommu: arm-smmu-impl: Add a space before open parenthesis Sharat Masetty (2): drm/msm: rearrange the gpu_rmw() function drm/msm/a6xx: Add support for using system cache(LLC) Hi, Gentle Ping! Thanks, Sai -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
Re: [PATCH v1 00/30] Introduce core voltage scaling for NVIDIA Tegra20/30 SoCs
On 09-11-20, 08:10, Dmitry Osipenko wrote: > 09.11.2020 07:47, Dmitry Osipenko пишет: > > 09.11.2020 07:43, Viresh Kumar пишет: > >> On 08-11-20, 15:19, Dmitry Osipenko wrote: > >>> I took a detailed look at the GENPD and tried to implement it. Here is > >>> what was found: > >>> > >>> 1. GENPD framework doesn't aggregate performance requests from the > >>> attached devices. This means that if deviceA requests performance state > >>> 10 and then deviceB requests state 3, then framework will set domain's > >>> state to 3 instead of 10. > >> > >> It does. Look at _genpd_reeval_performance_state(). > >> > > > > Thanks, I probably had a bug in the quick prototype and then overlooked > > that function. > > > > If a non-hardware device-tree node is okay to have for the domain, then > I can try again. > > What I also haven't mentioned is that GENPD adds some extra complexity > to some drivers (3d, video decoder) because we will need to handle both > new GENPD and legacy Tegra specific pre-genpd era domains. > > I'm also not exactly sure how the topology of domains should look like > because Tegra has a power-controller (PMC) which manages power rail of a > few hardware units. Perhaps it should be > > device -> PMC domain -> CORE domain > > but not exactly sure for now. I am also confused on if it should be a domain or regulator, but that is for Ulf to tell :) -- viresh
Re: [PATCH v1 00/30] Introduce core voltage scaling for NVIDIA Tegra20/30 SoCs
09.11.2020 07:47, Dmitry Osipenko пишет: > 09.11.2020 07:43, Viresh Kumar пишет: >> On 08-11-20, 15:19, Dmitry Osipenko wrote: >>> I took a detailed look at the GENPD and tried to implement it. Here is >>> what was found: >>> >>> 1. GENPD framework doesn't aggregate performance requests from the >>> attached devices. This means that if deviceA requests performance state >>> 10 and then deviceB requests state 3, then framework will set domain's >>> state to 3 instead of 10. >> >> It does. Look at _genpd_reeval_performance_state(). >> > > Thanks, I probably had a bug in the quick prototype and then overlooked > that function. > If a non-hardware device-tree node is okay to have for the domain, then I can try again. What I also haven't mentioned is that GENPD adds some extra complexity to some drivers (3d, video decoder) because we will need to handle both new GENPD and legacy Tegra specific pre-genpd era domains. I'm also not exactly sure how the topology of domains should look like because Tegra has a power-controller (PMC) which manages power rail of a few hardware units. Perhaps it should be device -> PMC domain -> CORE domain but not exactly sure for now.
Re: [PATCH v1 17/30] mmc: sdhci-tegra: Support OPP and core voltage scaling
On 09-11-20, 08:08, Dmitry Osipenko wrote: > 09.11.2020 08:00, Viresh Kumar пишет: > > On 06-11-20, 21:41, Frank Lee wrote: > >> On Fri, Nov 6, 2020 at 9:18 PM Dmitry Osipenko wrote: > >>> > >>> 06.11.2020 09:15, Viresh Kumar пишет: > Setting regulators for count as 0 doesn't sound good to me. > > But, I understand that you don't want to have that if (have_regulator) > check, and it is a fair request. What I will instead do is, allow all > dev_pm_opp_put*() API to start accepting a NULL pointer for the OPP > table and fail silently. And so you won't be required to have this > unwanted check. But you will be required to save the pointer returned > back by dev_pm_opp_set_regulators(), which is the right thing to do > anyways. > >>> > >>> Perhaps even a better variant could be to add a devm versions of the OPP > >>> API functions, then drivers won't need to care about storing the > >>> opp_table pointer if it's unused by drivers. > >> > >> I think so. The consumer may not be so concerned about the status of > >> these OPP tables. > >> If the driver needs to manage the release, it needs to add a pointer > >> to their driver global structure. > >> > >> Maybe it's worth having these devm interfaces for opp. > > > > Sure if there are enough users of this, I am all for it. I was fine > > with the patches you sent, just that there were not a lot of users of > > it and so I pushed them back. If we find that we have more users of it > > now, we can surely get that back. > > > > There was already attempt to add the devm? Could you please give me a > link to the patches? > > I already prepared a patch which adds the devm helpers. It helps to keep > code cleaner and readable. https://lore.kernel.org/lkml/20201012135517.19468-1-fr...@allwinnertech.com/ -- viresh
Re: [PATCH v1 17/30] mmc: sdhci-tegra: Support OPP and core voltage scaling
09.11.2020 08:00, Viresh Kumar пишет: > On 06-11-20, 21:41, Frank Lee wrote: >> On Fri, Nov 6, 2020 at 9:18 PM Dmitry Osipenko wrote: >>> >>> 06.11.2020 09:15, Viresh Kumar пишет: Setting regulators for count as 0 doesn't sound good to me. But, I understand that you don't want to have that if (have_regulator) check, and it is a fair request. What I will instead do is, allow all dev_pm_opp_put*() API to start accepting a NULL pointer for the OPP table and fail silently. And so you won't be required to have this unwanted check. But you will be required to save the pointer returned back by dev_pm_opp_set_regulators(), which is the right thing to do anyways. >>> >>> Perhaps even a better variant could be to add a devm versions of the OPP >>> API functions, then drivers won't need to care about storing the >>> opp_table pointer if it's unused by drivers. >> >> I think so. The consumer may not be so concerned about the status of >> these OPP tables. >> If the driver needs to manage the release, it needs to add a pointer >> to their driver global structure. >> >> Maybe it's worth having these devm interfaces for opp. > > Sure if there are enough users of this, I am all for it. I was fine > with the patches you sent, just that there were not a lot of users of > it and so I pushed them back. If we find that we have more users of it > now, we can surely get that back. > There was already attempt to add the devm? Could you please give me a link to the patches? I already prepared a patch which adds the devm helpers. It helps to keep code cleaner and readable.
Re: [PATCH v1 17/30] mmc: sdhci-tegra: Support OPP and core voltage scaling
On 06-11-20, 21:41, Frank Lee wrote: > On Fri, Nov 6, 2020 at 9:18 PM Dmitry Osipenko wrote: > > > > 06.11.2020 09:15, Viresh Kumar пишет: > > > Setting regulators for count as 0 doesn't sound good to me. > > > > > > But, I understand that you don't want to have that if (have_regulator) > > > check, and it is a fair request. What I will instead do is, allow all > > > dev_pm_opp_put*() API to start accepting a NULL pointer for the OPP > > > table and fail silently. And so you won't be required to have this > > > unwanted check. But you will be required to save the pointer returned > > > back by dev_pm_opp_set_regulators(), which is the right thing to do > > > anyways. > > > > Perhaps even a better variant could be to add a devm versions of the OPP > > API functions, then drivers won't need to care about storing the > > opp_table pointer if it's unused by drivers. > > I think so. The consumer may not be so concerned about the status of > these OPP tables. > If the driver needs to manage the release, it needs to add a pointer > to their driver global structure. > > Maybe it's worth having these devm interfaces for opp. Sure if there are enough users of this, I am all for it. I was fine with the patches you sent, just that there were not a lot of users of it and so I pushed them back. If we find that we have more users of it now, we can surely get that back. -- viresh
Re: [PATCH v4] inotify: Increase default inotify.max_user_watches limit to 1048576
On Mon, Nov 9, 2020 at 6:00 AM Waiman Long wrote:
>
> The default value of inotify.max_user_watches sysctl parameter was set
> to 8192 since the introduction of the inotify feature in 2005 by
> commit 0eeca28300df ("[PATCH] inotify"). Today this value is just too
> small for many modern usage. As a result, users have to explicitly set
> it to a larger value to make it work.
>
> After some searching around the web, these are the
> inotify.max_user_watches values used by some projects:
> - vscode: 524288
> - dropbox support: 10
> - users on stackexchange: 12228
> - lsyncd user: 200
> - code42 support: 1048576
> - monodevelop: 16384
> - tectonic: 524288
> - openshift origin: 65536
>
> Each watch point adds an inotify_inode_mark structure to an inode to
> be watched. It also pins the watched inode.
>
> Modeled after the epoll.max_user_watches behavior to adjust the default
> value according to the amount of addressable memory available, make
> inotify.max_user_watches behave in a similar way to make it use no more
> than 1% of addressable memory within the range [8192, 1048576].
>
> For 64-bit archs, inotify_inode_mark plus 2 vfs inode have a size that
> is a bit over 1 kbytes (1284 bytes with my x86-64 config).
The sentence above seems out of context (where did the 2 vfs inodes
come from?). Perhaps the comment in the patch should go here above.
> That means
> a system with 128GB or more memory will likely have the maximum value
> of 1048576 for inotify.max_user_watches. This default should be big
> enough for most use cases.
>
> [v3: increase inotify watch cost as suggested by Amir and Honza]
That patch change log usually doesn't belong in the git commit
because it adds little value in git log perspective.
If you think that the development process is relevant to understanding
the patch (like the discussion leading to the formula of the cost)
then a Link: to the discussion on lore.kernel.org would serve the
commit better.
>
> Signed-off-by: Waiman Long
Apart from this minor nits,
Reviewed-by: Amir Goldstein
> ---
> fs/notify/inotify/inotify_user.c | 23 ++-
> 1 file changed, 22 insertions(+), 1 deletion(-)
>
> diff --git a/fs/notify/inotify/inotify_user.c
> b/fs/notify/inotify/inotify_user.c
> index 186722ba3894..24d17028375e 100644
> --- a/fs/notify/inotify/inotify_user.c
> +++ b/fs/notify/inotify/inotify_user.c
> @@ -37,6 +37,15 @@
>
> #include
>
> +/*
> + * An inotify watch requires allocating an inotify_inode_mark structure as
> + * well as pinning the watched inode. Doubling the size of a VFS inode
> + * should be more than enough to cover the additional filesystem inode
> + * size increase.
> + */
> +#define INOTIFY_WATCH_COST (sizeof(struct inotify_inode_mark) + \
> +2 * sizeof(struct inode))
> +
> /* configurable via /proc/sys/fs/inotify/ */
> static int inotify_max_queued_events __read_mostly;
>
> @@ -801,6 +810,18 @@ SYSCALL_DEFINE2(inotify_rm_watch, int, fd, __s32, wd)
> */
> static int __init inotify_user_setup(void)
> {
> + unsigned long watches_max;
> + struct sysinfo si;
> +
> + si_meminfo();
> + /*
> +* Allow up to 1% of addressable memory to be allocated for inotify
> +* watches (per user) limited to the range [8192, 1048576].
> +*/
> + watches_max = (((si.totalram - si.totalhigh) / 100) << PAGE_SHIFT) /
> + INOTIFY_WATCH_COST;
> + watches_max = clamp(watches_max, 8192UL, 1048576UL);
> +
> BUILD_BUG_ON(IN_ACCESS != FS_ACCESS);
> BUILD_BUG_ON(IN_MODIFY != FS_MODIFY);
> BUILD_BUG_ON(IN_ATTRIB != FS_ATTRIB);
> @@ -827,7 +848,7 @@ static int __init inotify_user_setup(void)
>
> inotify_max_queued_events = 16384;
> init_user_ns.ucount_max[UCOUNT_INOTIFY_INSTANCES] = 128;
> - init_user_ns.ucount_max[UCOUNT_INOTIFY_WATCHES] = 8192;
> + init_user_ns.ucount_max[UCOUNT_INOTIFY_WATCHES] = watches_max;
>
> return 0;
> }
> --
> 2.18.1
>
Re: [PATCH 2/2] opp: Don't create an OPP table from dev_pm_opp_get_opp_table()
On 09-11-20, 07:41, Dmitry Osipenko wrote: > 09.11.2020 07:34, Viresh Kumar пишет: > > On 06-11-20, 16:18, Dmitry Osipenko wrote: > >> 06.11.2020 09:24, Viresh Kumar пишет: > >>> It has been found that some users (like cpufreq-dt and others on LKML) > >>> have abused the helper dev_pm_opp_get_opp_table() to create the OPP > >>> table instead of just finding it, which is the wrong thing to do. This > >>> routine was meant for OPP core's internal working and exposed the whole > >>> functionality by mistake. > >>> > >>> Change the scope of dev_pm_opp_get_opp_table() to only finding the > >>> table. The internal helpers _opp_get_opp_table*() are thus renamed to > >>> _add_opp_table*(), dev_pm_opp_get_opp_table_indexed() is removed (as we > >>> don't need the index field for finding the OPP table) and so the only > >>> user, genpd, is updated. > >>> > >>> Note that the prototype of _add_opp_table() was already left in opp.h by > >>> mistake when it was removed earlier and so we weren't required to add it > >>> now. > >> > >> Hello Viresh, > >> > >> It looks like this is not an entirely correct change because previously > >> it was possible to get an empty opp_table in order to use it for the > >> dev_pm_opp_set_rate(), which would fall back to clk_set_rate if table is > >> empty. > >> > >> Now it's not possible to get an empty table and > >> dev_pm_opp_of_add_table() would error out if OPPs are missing in a > >> device-tree. Hence it's not possible to implement a fall back without > >> abusing opp_set_regulators() or opp_set_supported_hw() for getting the > >> empty table. Or am I missing something? > > > > For that case you were always required to call > > dev_pm_opp_set_clkname(), otherwise how would the OPP core know which > > clock to set ? And the same shall work now as well. > > Why _allocate_opp_table() grabs the first default clk of a device and > assigns it to the created table? Right, it was there so everybody isn't required to call dev_pm_opp_set_clkname() if they don't need to pass a connection id while getting the clock. But for the case of supporting empty OPP tables for cases where we just want dev_pm_opp_set_rate() to act as clk_set_rate() (in order for the drivers to avoid supporting two different ways of doing so), we do need that call to be made. We need to add the OPP table explicitly and what happened with dev_pm_opp_get_opp_table() was accidental and not what I wanted. drivers/mmc/host/sdhci-msm.c has an example of how this is done. -- viresh
RE: [PATCH] scsi: bnx2fc: fix comparison to bool warning
Hi,
> -Original Message-
> From: xiakaixu1...@gmail.com
> Sent: Saturday, November 7, 2020 10:22 PM
> To: j...@linux.ibm.com; martin.peter...@oracle.com
> Cc: linux-s...@vger.kernel.org; linux-kernel@vger.kernel.org; Kaixu Xia
>
> Subject: [PATCH] scsi: bnx2fc: fix comparison to bool warning
>
> From: Kaixu Xia
>
> Fix the following coccicheck warning:
>
> ./drivers/scsi/bnx2fc/bnx2fc_fcoe.c:2089:5-23: WARNING: Comparison to bool
> ./drivers/scsi/bnx2fc/bnx2fc_fcoe.c:2187:5-23: WARNING: Comparison to bool
>
> Reported-by: Tosk Robot
> Signed-off-by: Kaixu Xia
> ---
> drivers/scsi/bnx2fc/bnx2fc_fcoe.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/scsi/bnx2fc/bnx2fc_fcoe.c
> b/drivers/scsi/bnx2fc/bnx2fc_fcoe.c
> index 6890bbe04a8c..b612f5ea647e 100644
> --- a/drivers/scsi/bnx2fc/bnx2fc_fcoe.c
> +++ b/drivers/scsi/bnx2fc/bnx2fc_fcoe.c
> @@ -2086,7 +2086,7 @@ static int __bnx2fc_disable(struct fcoe_ctlr *ctlr)
> {
> struct bnx2fc_interface *interface = fcoe_ctlr_priv(ctlr);
>
> - if (interface->enabled == true) {
> + if (interface->enabled) {
> if (!ctlr->lp) {
> pr_err(PFX "__bnx2fc_disable: lport not found\n");
> return -ENODEV;
> @@ -2184,7 +2184,7 @@ static int __bnx2fc_enable(struct fcoe_ctlr *ctlr)
> struct cnic_fc_npiv_tbl *npiv_tbl;
> struct fc_lport *lport;
>
> - if (interface->enabled == false) {
> + if (!interface->enabled) {
> if (!ctlr->lp) {
> pr_err(PFX "__bnx2fc_enable: lport not found\n");
> return -ENODEV;
>
Thanks for a patch.
Acked-by: Saurav Kashyap
Thanks,
~Saurav
--
> 2.20.0
Re: [PATCH v1 00/30] Introduce core voltage scaling for NVIDIA Tegra20/30 SoCs
09.11.2020 07:43, Viresh Kumar пишет: > On 08-11-20, 15:19, Dmitry Osipenko wrote: >> I took a detailed look at the GENPD and tried to implement it. Here is >> what was found: >> >> 1. GENPD framework doesn't aggregate performance requests from the >> attached devices. This means that if deviceA requests performance state >> 10 and then deviceB requests state 3, then framework will set domain's >> state to 3 instead of 10. > > It does. Look at _genpd_reeval_performance_state(). > Thanks, I probably had a bug in the quick prototype and then overlooked that function.
Re: [PATCH v1 00/30] Introduce core voltage scaling for NVIDIA Tegra20/30 SoCs
On 08-11-20, 15:19, Dmitry Osipenko wrote: > I took a detailed look at the GENPD and tried to implement it. Here is > what was found: > > 1. GENPD framework doesn't aggregate performance requests from the > attached devices. This means that if deviceA requests performance state > 10 and then deviceB requests state 3, then framework will set domain's > state to 3 instead of 10. It does. Look at _genpd_reeval_performance_state(). -- viresh
[PATCH 0/2] ARM/ARM64: Enable SCMI in default configurations
This patch series enables support for the ARM SCMI and the various drivers provided (cpufreq, clock, sensors, reset) since these are utilized by Broadcom STB platforms. Please let me know if you would like me to carry those patches through the ARM SoC pull requests for v5.11 or if you would like to see those applied differently. Thanks! Florian Fainelli (2): ARM: multi_v7_defconfig: Enable ARM SCMI protocol and drivers arm64: defconfig: Enable ARM SCMI protocol and drivers arch/arm/configs/multi_v7_defconfig | 4 arch/arm64/configs/defconfig| 4 2 files changed, 8 insertions(+) -- 2.25.1
[PATCH 2/2] arm64: defconfig: Enable ARM SCMI protocol and drivers
Enable the ARM SCMI protocol and the common clock, cpufreq, reset and sensors drivers. Broadcom STB platforms (ARCH_BRCMSTB) implement SCMI to provide support for CPU frequency scaling, clock configuration and temperature and current sensors. Signed-off-by: Florian Fainelli --- arch/arm64/configs/defconfig | 4 1 file changed, 4 insertions(+) diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index 5cfe3cf6f2ac..5fcd09e505b4 100644 --- a/arch/arm64/configs/defconfig +++ b/arch/arm64/configs/defconfig @@ -93,8 +93,10 @@ CONFIG_ARM_IMX_CPUFREQ_DT=m CONFIG_ARM_QCOM_CPUFREQ_NVMEM=y CONFIG_ARM_QCOM_CPUFREQ_HW=y CONFIG_ARM_RASPBERRYPI_CPUFREQ=m +CONFIG_ARM_SCMI_CPUFREQ=y CONFIG_ARM_TEGRA186_CPUFREQ=y CONFIG_QORIQ_CPUFREQ=y +CONFIG_ARM_SCMI_PROTOCOL=y CONFIG_ARM_SCPI_PROTOCOL=y CONFIG_RASPBERRYPI_FIRMWARE=y CONFIG_INTEL_STRATIX10_SERVICE=y @@ -522,6 +524,7 @@ CONFIG_POWER_RESET_SYSCON=y CONFIG_SYSCON_REBOOT_MODE=y CONFIG_BATTERY_SBS=m CONFIG_BATTERY_BQ27XXX=y +CONFIG_SENSORS_ARM_SCMI=y CONFIG_SENSORS_ARM_SCPI=y CONFIG_SENSORS_LM90=m CONFIG_SENSORS_PWM_FAN=m @@ -865,6 +868,7 @@ CONFIG_CROS_EC=y CONFIG_CROS_EC_I2C=y CONFIG_CROS_EC_SPI=y CONFIG_CROS_EC_CHARDEV=m +CONFIG_COMMON_CLK_SCMI=y CONFIG_COMMON_CLK_RK808=y CONFIG_COMMON_CLK_SCPI=y CONFIG_COMMON_CLK_CS2000_CP=y -- 2.25.1
[PATCH 1/2] ARM: multi_v7_defconfig: Enable ARM SCMI protocol and drivers
Enable the ARM SCMI protocol and the common clock, cpufreq and sensors drivers. Broadcom STB platforms (ARCH_BRCMSTB) implement SCMI to provide support for CPU frequency scaling, clock configuration and temperature and current sensors. Signed-off-by: Florian Fainelli --- arch/arm/configs/multi_v7_defconfig | 4 1 file changed, 4 insertions(+) diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig index a611b0c1e540..10facef5558c 100644 --- a/arch/arm/configs/multi_v7_defconfig +++ b/arch/arm/configs/multi_v7_defconfig @@ -109,6 +109,7 @@ CONFIG_CPU_FREQ_GOV_CONSERVATIVE=m CONFIG_CPU_FREQ_GOV_SCHEDUTIL=y CONFIG_CPUFREQ_DT=y CONFIG_ARM_IMX6Q_CPUFREQ=y +CONFIG_ARM_SCMI_CPUFREQ=y CONFIG_ARM_RASPBERRYPI_CPUFREQ=y CONFIG_QORIQ_CPUFREQ=y CONFIG_CPU_IDLE=y @@ -117,6 +118,7 @@ CONFIG_ARM_ZYNQ_CPUIDLE=y CONFIG_ARM_EXYNOS_CPUIDLE=y CONFIG_ARM_TEGRA_CPUIDLE=y CONFIG_KERNEL_MODE_NEON=y +CONFIG_ARM_SCMI_PROTOCOL=y CONFIG_RASPBERRYPI_FIRMWARE=y CONFIG_TRUSTED_FOUNDATIONS=y CONFIG_BCM47XX_NVRAM=y @@ -488,6 +490,7 @@ CONFIG_CHARGER_MAX77693=m CONFIG_CHARGER_MAX8997=m CONFIG_CHARGER_MAX8998=m CONFIG_CHARGER_TPS65090=y +CONFIG_SENSORS_ARM_SCMI=y CONFIG_SENSORS_ASPEED=m CONFIG_SENSORS_IIO_HWMON=y CONFIG_SENSORS_LM90=y @@ -959,6 +962,7 @@ CONFIG_CROS_EC_I2C=m CONFIG_CROS_EC_SPI=m CONFIG_COMMON_CLK_MAX77686=y CONFIG_COMMON_CLK_RK808=m +CONFIG_COMMON_CLK_SCMI=y CONFIG_COMMON_CLK_S2MPS11=m CONFIG_CLK_RASPBERRYPI=y CONFIG_COMMON_CLK_QCOM=y -- 2.25.1
Re: [PATCH 2/2] opp: Don't create an OPP table from dev_pm_opp_get_opp_table()
09.11.2020 07:34, Viresh Kumar пишет: > On 06-11-20, 16:18, Dmitry Osipenko wrote: >> 06.11.2020 09:24, Viresh Kumar пишет: >>> It has been found that some users (like cpufreq-dt and others on LKML) >>> have abused the helper dev_pm_opp_get_opp_table() to create the OPP >>> table instead of just finding it, which is the wrong thing to do. This >>> routine was meant for OPP core's internal working and exposed the whole >>> functionality by mistake. >>> >>> Change the scope of dev_pm_opp_get_opp_table() to only finding the >>> table. The internal helpers _opp_get_opp_table*() are thus renamed to >>> _add_opp_table*(), dev_pm_opp_get_opp_table_indexed() is removed (as we >>> don't need the index field for finding the OPP table) and so the only >>> user, genpd, is updated. >>> >>> Note that the prototype of _add_opp_table() was already left in opp.h by >>> mistake when it was removed earlier and so we weren't required to add it >>> now. >> >> Hello Viresh, >> >> It looks like this is not an entirely correct change because previously >> it was possible to get an empty opp_table in order to use it for the >> dev_pm_opp_set_rate(), which would fall back to clk_set_rate if table is >> empty. >> >> Now it's not possible to get an empty table and >> dev_pm_opp_of_add_table() would error out if OPPs are missing in a >> device-tree. Hence it's not possible to implement a fall back without >> abusing opp_set_regulators() or opp_set_supported_hw() for getting the >> empty table. Or am I missing something? > > For that case you were always required to call > dev_pm_opp_set_clkname(), otherwise how would the OPP core know which > clock to set ? And the same shall work now as well. Why _allocate_opp_table() grabs the first default clk of a device and assigns it to the created table?
