RE: [PATCH 3/8] scsi: ufshpb: Add region's reads counter
> > On Mon, Feb 01, 2021 at 07:12:53AM +, Avri Altman wrote: > > > > +#define WORK_PENDING 0 > > > > +#define ACTIVATION_THRSHLD 4 /* 4 IOs */ > > > Rather than fixing it with macro, how about using sysfs and make it > > > configurable? > > Yes. > > I will add a patch making all the logic configurable. > > As all those are hpb-related parameters, I think module parameters are > more adequate. > > No, this is not the 1990's, please never add new module parameters to > drivers. If not for the basic problem of they do not work on a > per-device basis, but on a per-driver basis, which is what you almost > never want. OK. > > But why would you want to change this value, why can't the driver "just > work" and not need manual intervention? It is. But those are a knobs each vendor may want to tweak, So it'll be optimized with its internal device's implementation. Tweaking the parameters, as well as the entire logic, is really an endless task. Some logic works better for some scenarios, while falling behind on others. How about leaving it for now, to be elaborated it in the future? Maybe even can be a part of a scheme, to make the logic proprietary?
[PATCH] ceph: Replace DEFINE_SIMPLE_ATTRIBUTE with DEFINE_DEBUGFS_ATTRIBUTE
Fix the following coccicheck warning: ./fs/ceph/debugfs.c:347:0-23: WARNING: congestion_kb_fops should be defined with DEFINE_DEBUGFS_ATTRIBUTE. Reported-by: Abaci Robot Signed-off-by: Jiapeng Chong --- fs/ceph/debugfs.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/ceph/debugfs.c b/fs/ceph/debugfs.c index 66989c8..617327e 100644 --- a/fs/ceph/debugfs.c +++ b/fs/ceph/debugfs.c @@ -344,8 +344,8 @@ static int congestion_kb_get(void *data, u64 *val) return 0; } -DEFINE_SIMPLE_ATTRIBUTE(congestion_kb_fops, congestion_kb_get, - congestion_kb_set, "%llu\n"); +DEFINE_DEBUGFS_ATTRIBUTE(congestion_kb_fops, congestion_kb_get, + congestion_kb_set, "%llu\n"); void ceph_fs_debugfs_cleanup(struct ceph_fs_client *fsc) -- 1.8.3.1
[PATCH] PM: hibernate: add sanity check on power_kobj
The @power_kobj is initialized in pm_init() which is the same
initcall level as pm_disk_init(). Although this dependency is
guaranteed based on the current initcall serial execution model,
it would still be better do a cost-less sanity check to avoid
oops once the dependency is broken.
Signed-off-by: Abel Wu
---
kernel/power/hibernate.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/kernel/power/hibernate.c b/kernel/power/hibernate.c
index da0b41914177..060089cc261d 100644
--- a/kernel/power/hibernate.c
+++ b/kernel/power/hibernate.c
@@ -1262,6 +1262,9 @@ static const struct attribute_group attr_group = {
static int __init pm_disk_init(void)
{
+ if (!power_kobj)
+ return -EINVAL;
+
return sysfs_create_group(power_kobj, _group);
}
--
2.27.0
[PATCH] treewide: remove unneeded semicolon
Eliminate the following coccicheck warning: ./tools/virtio/virtio-trace/trace-agent-ctl.c:78:2-3: Unneeded semicolon Reported-by: Abaci Robot Signed-off-by: Yang Li --- tools/virtio/virtio-trace/trace-agent-ctl.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/virtio/virtio-trace/trace-agent-ctl.c b/tools/virtio/virtio-trace/trace-agent-ctl.c index 73d253d..39860be 100644 --- a/tools/virtio/virtio-trace/trace-agent-ctl.c +++ b/tools/virtio/virtio-trace/trace-agent-ctl.c @@ -75,7 +75,7 @@ static int wait_order(int ctl_fd) if (ret) break; - }; + } return ret; -- 1.8.3.1
Re: [PATCH v3] misc: bcm-vk: only support ttyVK if CONFIG_TTY is set
On Sun, Jan 31, 2021 at 03:30:49PM -0800, Scott Branden wrote: > Correct compile issue if CONFIG_TTY is not set by > only adding ttyVK devices if CONFIG_BCM_VK_TTY is set. > > Reported-by: Randy Dunlap > Signed-off-by: Scott Branden > > --- > Changes since v2: > - add CONFIG_BCM_VK_TTY > - add function and stub for bcm_vk_tty_set_irq_enabled > Changes since v1: > - add function stubs rather than compiling out code > --- > drivers/misc/bcm-vk/Kconfig | 16 > drivers/misc/bcm-vk/Makefile | 4 +-- > drivers/misc/bcm-vk/bcm_vk.h | 42 +--- > drivers/misc/bcm-vk/bcm_vk_dev.c | 5 ++-- > drivers/misc/bcm-vk/bcm_vk_tty.c | 6 + > 5 files changed, 65 insertions(+), 8 deletions(-) > > diff --git a/drivers/misc/bcm-vk/Kconfig b/drivers/misc/bcm-vk/Kconfig > index 052f6f28b540..16ce98c964b8 100644 > --- a/drivers/misc/bcm-vk/Kconfig > +++ b/drivers/misc/bcm-vk/Kconfig > @@ -15,3 +15,19 @@ config BCM_VK > accelerators via /dev/bcm-vk.N devices. > > If unsure, say N. > + > +if BCM_VK No need for this, just put it on the depends line, right? > + > +config BCM_VK_TTY > + bool "Enable ttyVK" Better config help text to explain what this is? > + depends on TTY > + default y Default y is only there if your system can not boot without it, please remove it. > + help > + Select this option to enable ttyVK support to allow console > + access to VK cards from host. Again, more help text, what is a "VK"? thanks, greg k-h
[PATCH] fault_inject: Replace DEFINE_SIMPLE_ATTRIBUTE with DEFINE_DEBUGFS_ATTRIBUTE
Fix the following coccicheck warning: ./lib/fault-inject.c:187:0-23: WARNING: fops_stacktrace_depth should be defined with DEFINE_DEBUGFS_ATTRIBUTE. ./lib/fault-inject.c:169:0-23: WARNING: fops_ul should be defined with DEFINE_DEBUGFS_ATTRIBUTE. Reported-by: Abaci Robot Signed-off-by: Jiapeng Chong --- lib/fault-inject.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/lib/fault-inject.c b/lib/fault-inject.c index ce12621..cb7ea22 100644 --- a/lib/fault-inject.c +++ b/lib/fault-inject.c @@ -166,7 +166,7 @@ static int debugfs_ul_get(void *data, u64 *val) return 0; } -DEFINE_SIMPLE_ATTRIBUTE(fops_ul, debugfs_ul_get, debugfs_ul_set, "%llu\n"); +DEFINE_DEBUGFS_ATTRIBUTE(fops_ul, debugfs_ul_get, debugfs_ul_set, "%llu\n"); static void debugfs_create_ul(const char *name, umode_t mode, struct dentry *parent, unsigned long *value) @@ -184,8 +184,8 @@ static int debugfs_stacktrace_depth_set(void *data, u64 val) return 0; } -DEFINE_SIMPLE_ATTRIBUTE(fops_stacktrace_depth, debugfs_ul_get, - debugfs_stacktrace_depth_set, "%llu\n"); +DEFINE_DEBUGFS_ATTRIBUTE(fops_stacktrace_depth, debugfs_ul_get, + debugfs_stacktrace_depth_set, "%llu\n"); static void debugfs_create_stacktrace_depth(const char *name, umode_t mode, struct dentry *parent, -- 1.8.3.1
[PATCH 1/3] iio: Add relative sensitivity support
Some hid sensors may use relative sensitivity such as als sensor.
This patch adds relative sensitivity checking for all hid sensors.
Signed-off-by: Ye Xiang
---
.../hid-sensors/hid-sensor-attributes.c | 75 ++-
drivers/iio/industrialio-core.c | 1 +
include/linux/hid-sensor-hub.h| 5 ++
include/linux/hid-sensor-ids.h| 1 +
include/linux/iio/types.h | 1 +
5 files changed, 79 insertions(+), 4 deletions(-)
diff --git a/drivers/iio/common/hid-sensors/hid-sensor-attributes.c
b/drivers/iio/common/hid-sensors/hid-sensor-attributes.c
index d349ace2e33f..7a555262ff9a 100644
--- a/drivers/iio/common/hid-sensors/hid-sensor-attributes.c
+++ b/drivers/iio/common/hid-sensors/hid-sensor-attributes.c
@@ -263,6 +263,30 @@ int hid_sensor_read_raw_hyst_value(struct
hid_sensor_common *st,
}
EXPORT_SYMBOL(hid_sensor_read_raw_hyst_value);
+int hid_sensor_read_raw_hyst_rel_value(struct hid_sensor_common *st, int *val1,
+ int *val2)
+{
+ s32 value;
+ int ret;
+
+ ret = sensor_hub_get_feature(st->hsdev,
+st->sensitivity_rel.report_id,
+st->sensitivity_rel.index, sizeof(value),
+);
+ if (ret < 0 || value < 0) {
+ *val1 = *val2 = 0;
+ return -EINVAL;
+ } else {
+ convert_from_vtf_format(value, st->sensitivity_rel.size,
+ st->sensitivity_rel.unit_expo,
+ val1, val2);
+ }
+
+ return IIO_VAL_INT_PLUS_MICRO;
+}
+EXPORT_SYMBOL(hid_sensor_read_raw_hyst_rel_value);
+
+
int hid_sensor_write_raw_hyst_value(struct hid_sensor_common *st,
int val1, int val2)
{
@@ -294,6 +318,37 @@ int hid_sensor_write_raw_hyst_value(struct
hid_sensor_common *st,
}
EXPORT_SYMBOL(hid_sensor_write_raw_hyst_value);
+int hid_sensor_write_raw_hyst_rel_value(struct hid_sensor_common *st,
+ int val1, int val2)
+{
+ s32 value;
+ int ret;
+
+ if (val1 < 0 || val2 < 0)
+ return -EINVAL;
+
+ value = convert_to_vtf_format(st->sensitivity_rel.size,
+ st->sensitivity_rel.unit_expo,
+ val1, val2);
+ ret = sensor_hub_set_feature(st->hsdev, st->sensitivity_rel.report_id,
+st->sensitivity_rel.index, sizeof(value),
+);
+ if (ret < 0 || value < 0)
+ return -EINVAL;
+
+ ret = sensor_hub_get_feature(st->hsdev,
+st->sensitivity_rel.report_id,
+st->sensitivity_rel.index, sizeof(value),
+);
+ if (ret < 0 || value < 0)
+ return -EINVAL;
+
+ st->raw_hystersis = value;
+
+ return 0;
+}
+EXPORT_SYMBOL(hid_sensor_write_raw_hyst_rel_value);
+
/*
* This fuction applies the unit exponent to the scale.
* For example:
@@ -478,16 +533,28 @@ int hid_sensor_parse_common_attributes(struct
hid_sensor_hub_device *hsdev,
HID_USAGE_SENSOR_PROP_SENSITIVITY_ABS,
>sensitivity);
+ sensor_hub_input_get_attribute_info(hsdev,
+ HID_FEATURE_REPORT, usage_id,
+ HID_USAGE_SENSOR_PROP_SENSITIVITY_REL_PCT,
+ >sensitivity_rel);
/*
* Set Sensitivity field ids, when there is no individual modifier, will
-* check absolute sensitivity of data field
+* check absolute sensitivity and relative sensitivity of data field
*/
- for (i = 0; i < sensitivity_addresses_len && st->sensitivity.index < 0;
i++) {
- sensor_hub_input_get_attribute_info(hsdev,
- HID_FEATURE_REPORT, usage_id,
+ for (i = 0; i < sensitivity_addresses_len; i++) {
+ if (st->sensitivity.index < 0)
+ sensor_hub_input_get_attribute_info(
+ hsdev, HID_FEATURE_REPORT, usage_id,
HID_USAGE_SENSOR_DATA_MOD_CHANGE_SENSITIVITY_ABS |
sensitivity_addresses[i],
>sensitivity);
+
+ if (st->sensitivity_rel.index < 0)
+ sensor_hub_input_get_attribute_info(
+ hsdev, HID_FEATURE_REPORT, usage_id,
+
HID_USAGE_SENSOR_DATA_MOD_CHANGE_SENSITIVITY_REL_PCT |
+ sensitivity_addresses[i],
+ >sensitivity_rel);
}
st->raw_hystersis = -1;
diff --git a/drivers/iio/industrialio-core.c
[PATCH 3/3] iio: Add relative hysteresis in ABI documentation
Add relative hysteresis in ABI documentation. Signed-off-by: Ye Xiang --- Documentation/ABI/testing/sysfs-bus-iio | 8 1 file changed, 8 insertions(+) diff --git a/Documentation/ABI/testing/sysfs-bus-iio b/Documentation/ABI/testing/sysfs-bus-iio index d957f5da5c04..1c51db7eb8ef 100644 --- a/Documentation/ABI/testing/sysfs-bus-iio +++ b/Documentation/ABI/testing/sysfs-bus-iio @@ -1823,3 +1823,11 @@ Description: hinge, keyboard, screen. It means the three channels each correspond respectively to hinge angle, keyboard angle, and screen angle. + +What: /sys/bus/iio/devices/iio:deviceX/in_Y_hysteresis_relative +KernelVersion: 5.12 +Contact: linux-...@vger.kernel.org +Description: + Specify the percent relative to the current sensor channel + Y absolute value that a data field should change before an event + is generated. Units are a percentage of the prior reading. -- 2.17.1
[PATCH 2/3] iio: hid-sensor-als: Add relative hysteresis support
Hid sensor als uses relative hysteresis, this patch adds the support.
Signed-off-by: Ye Xiang
---
drivers/iio/light/hid-sensor-als.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/iio/light/hid-sensor-als.c
b/drivers/iio/light/hid-sensor-als.c
index afcdb424bfb8..85c8a05b73cb 100644
--- a/drivers/iio/light/hid-sensor-als.c
+++ b/drivers/iio/light/hid-sensor-als.c
@@ -54,7 +54,8 @@ static const struct iio_chan_spec als_channels[] = {
.info_mask_shared_by_type = BIT(IIO_CHAN_INFO_OFFSET) |
BIT(IIO_CHAN_INFO_SCALE) |
BIT(IIO_CHAN_INFO_SAMP_FREQ) |
- BIT(IIO_CHAN_INFO_HYSTERESIS),
+ BIT(IIO_CHAN_INFO_HYSTERESIS) |
+ BIT(IIO_CHAN_INFO_HYSTERESIS_RELATIVE),
.scan_index = CHANNEL_SCAN_INDEX_INTENSITY,
},
{
@@ -63,7 +64,8 @@ static const struct iio_chan_spec als_channels[] = {
.info_mask_shared_by_type = BIT(IIO_CHAN_INFO_OFFSET) |
BIT(IIO_CHAN_INFO_SCALE) |
BIT(IIO_CHAN_INFO_SAMP_FREQ) |
- BIT(IIO_CHAN_INFO_HYSTERESIS),
+ BIT(IIO_CHAN_INFO_HYSTERESIS) |
+ BIT(IIO_CHAN_INFO_HYSTERESIS_RELATIVE),
.scan_index = CHANNEL_SCAN_INDEX_ILLUM,
},
IIO_CHAN_SOFT_TIMESTAMP(CHANNEL_SCAN_INDEX_TIMESTAMP)
@@ -141,6 +143,10 @@ static int als_read_raw(struct iio_dev *indio_dev,
ret_type = hid_sensor_read_raw_hyst_value(
_state->common_attributes, val, val2);
break;
+ case IIO_CHAN_INFO_HYSTERESIS_RELATIVE:
+ ret_type = hid_sensor_read_raw_hyst_rel_value(
+ _state->common_attributes, val, val2);
+ break;
default:
ret_type = -EINVAL;
break;
@@ -168,6 +174,10 @@ static int als_write_raw(struct iio_dev *indio_dev,
ret = hid_sensor_write_raw_hyst_value(
_state->common_attributes, val, val2);
break;
+ case IIO_CHAN_INFO_HYSTERESIS_RELATIVE:
+ ret = hid_sensor_write_raw_hyst_rel_value(
+ _state->common_attributes, val, val2);
+ break;
default:
ret = -EINVAL;
}
--
2.17.1
[PATCH 0/3] Add relative hysteresis support for hid sensors
Currently, hid sensor als are using the relative hysteresis. This patch series add the relative hysteresis for hid sensors. Ye Xiang (3): iio: Add relative sensitivity support iio: hid-sensor-als: Add relative hysteresis support iio: Add relative hysteresis in ABI documentation Documentation/ABI/testing/sysfs-bus-iio | 8 ++ .../hid-sensors/hid-sensor-attributes.c | 75 ++- drivers/iio/industrialio-core.c | 1 + drivers/iio/light/hid-sensor-als.c| 14 +++- include/linux/hid-sensor-hub.h| 5 ++ include/linux/hid-sensor-ids.h| 1 + include/linux/iio/types.h | 1 + 7 files changed, 99 insertions(+), 6 deletions(-) -- 2.17.1
Re: [PATCH] serial: 8250: add option to disable registration of legacy ISA ports
On Sun, Jan 31, 2021 at 09:25:33PM +0200, Andy Shevchenko wrote: > On Thursday, January 28, 2021, Mans Rullgard wrote: > > > On systems that do not have the traditional PC ISA serial ports, the > > 8250 driver still creates non-functional device nodes. This change > > makes only ports that actually exist (PCI, DT, ...) get device nodes. > > > > > > This is kinda ABI breakage. At least this will break x86 platforms with > HSUARTs (all modern ones) that are used in embedded systems. > > I think you would rather need an option to disable this and select it by > the platforms where it is known not to break anything. This option is behind CONFIG_EXPERT, if you set it, you know what you are doing, so that's fine. thanks, greg k-h
[PATCH] perf metricgroup: remove unneeded semicolon
Eliminate the following coccicheck warning: ./tools/perf/util/metricgroup.c:382:3-4: Unneeded semicolon Reported-by: Abaci Robot Signed-off-by: Yang Li --- tools/perf/util/metricgroup.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/perf/util/metricgroup.c b/tools/perf/util/metricgroup.c index e6d3452..26c990e 100644 --- a/tools/perf/util/metricgroup.c +++ b/tools/perf/util/metricgroup.c @@ -379,7 +379,7 @@ static int metricgroup__setup_events(struct list_head *groups, metric_refs[i].metric_expr = ref->metric_expr; i++; } - }; + } expr->metric_refs = metric_refs; expr->metric_expr = m->metric_expr; -- 1.8.3.1
Re: [PATCH 1/4] perf/core: Add support to exclude kernel mode instruction tracing
Hi Peter, On 2021-01-30 01:00, Peter Zijlstra wrote: On Sat, Jan 30, 2021 at 12:35:10AM +0530, Sai Prakash Ranjan wrote: Here the idea is to protect such important information from all users including root users since root privileges does not have to mean full control over the kernel [1] and root compromise does not have to be the end of the world. And yet, your thing lacks: I guess you mean this lacks an explanation as to why this only applies to ITRACE and not others? See below. +config EXCLUDE_KERNEL_HW_ITRACE + bool "Exclude kernel mode hardware assisted instruction tracing" + depends on PERF_EVENTS depends on SECURITY_LOCKDOWN or whatever the appropriate symbol is. Ok I suppose you mean CONFIG_SECURITY_LOCKDOWN_LSM? But I don't see how this new config has to depend on that? This can work independently whether complete lockdown is enforced or not since it applies to only hardware instruction tracing. Ideally this depends on several hardware tracing configs such as ETMs and others but we don't need them because we are already exposing PERF_PMU_CAP_ITRACE check in the events core. + help + Exclude kernel mode instruction tracing by hardware tracing + family such as ARM Coresight ETM, Intel PT and so on. + + This option allows to disable kernel mode instruction tracing + offered by hardware assisted tracing for all users(including root) + especially for production systems where only userspace tracing might + be preferred for security reasons. Also, colour me unconvinced, pretty much all kernel level PMU usage can be employed to side-channel / infer crypto keys, why focus on ITRACE over others? Here ITRACE is not just instruction trace, it is meant for hardware assisted instruction trace such as Intel PT, Intel BTS, ARM coresight etc. These provide much more capabilities than normal instruction tracing whether its kernel level or userspace. More specifically, these provide more accurate branch trace like Intel PT LBR (Last Branch Record), Intel BTS(Branch Trace Store) which can be used to decode the program flow more accurately with timestamps in real time than other PMUs. Also there is cycle accurate tracing which can theoretically be used for some speculative execution based attacks. Which other kernel level PMUs can be used to get a full branch trace that is not locked down? If there is one, then this should probably be applied to it as well. 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] memory: tegra186-emc: Replace DEFINE_SIMPLE_ATTRIBUTE with DEFINE_DEBUGFS_ATTRIBUTE
On Mon, Feb 01, 2021 at 03:00:40PM +0800, Jiapeng Chong wrote: > Fix the following coccicheck warning: > > ./drivers/memory/tegra/tegra186-emc.c:158:0-23: WARNING: > tegra186_emc_debug_max_rate_fops should be defined with > DEFINE_DEBUGFS_ATTRIBUTE. > > ./drivers/memory/tegra/tegra186-emc.c:128:0-23: WARNING: > tegra186_emc_debug_min_rate_fops should be defined with > DEFINE_DEBUGFS_ATTRIBUTE. Please strip unrelated parts of the paths (./). > > Reported-by: Abaci Robot Where could I find the report? I did not get anything on my mail. Best regards, Krzysztof > Signed-off-by: Jiapeng Chong > --- > drivers/memory/tegra/tegra186-emc.c | 12 ++-- > 1 file changed, 6 insertions(+), 6 deletions(-)
Re: [PATCH] Revert "bfq: Fix computation of shallow depth"
Hi, it seems that this patch was blocked by linux mailist servers, so ping
again.
Based on
https://patchwork.kernel.org/project/linux-block/patch/20201210094433.25491-1-j...@suse.cz/,
it looks like we have made a consensus about bfqd->word_depths[2][2]'s
changing, so now the
computation codes for bfq's word_depths array are not necessary and one
variable is enough.
But IMHO async depth limitation for slow drivers is essential, which is what we
always did in cfq age.
On 1/29/21 19:18, Lin Feng wrote:
This reverts commit 6d4d273588378c65915acaf7b2ee74e9dd9c130a.
bfq.limit_depth passes word_depths[] as shallow_depth down to sbitmap core
sbitmap_get_shallow, which uses just the number to limit the scan depth of
each bitmap word, formula:
scan_percentage_for_each_word = shallow_depth / (1 << sbimap->shift) * 100%
That means the comments's percentiles 50%, 75%, 18%, 37% of bfq are correct.
But after commit patch 'bfq: Fix computation of shallow depth', we use
sbitmap.depth instead, as a example in following case:
sbitmap.depth = 256, map_nr = 4, shift = 6; sbitmap_word.depth = 64.
The resulsts of computed bfqd->word_depths[] are {128, 192, 48, 96}, and
three of the numbers exceed core dirver's 'sbitmap_word.depth=64' limit
nothing. Do we really don't want limit depth for such workloads, or we
just want to bump up the percentiles to 100%?
Please correct me if I miss something, thanks.
Signed-off-by: Lin Feng
---
block/bfq-iosched.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c
index 9e4eb0fc1c16..9e81d1052091 100644
--- a/block/bfq-iosched.c
+++ b/block/bfq-iosched.c
@@ -6332,13 +6332,13 @@ static unsigned int bfq_update_depths(struct bfq_data
*bfqd,
* limit 'something'.
*/
/* no more than 50% of tags for async I/O */
- bfqd->word_depths[0][0] = max(bt->sb.depth >> 1, 1U);
+ bfqd->word_depths[0][0] = max((1U << bt->sb.shift) >> 1, 1U);
/*
* no more than 75% of tags for sync writes (25% extra tags
* w.r.t. async I/O, to prevent async I/O from starving sync
* writes)
*/
- bfqd->word_depths[0][1] = max((bt->sb.depth * 3) >> 2, 1U);
+ bfqd->word_depths[0][1] = max(((1U << bt->sb.shift) * 3) >> 2, 1U);
/*
* In-word depths in case some bfq_queue is being weight-
@@ -6348,9 +6348,9 @@ static unsigned int bfq_update_depths(struct bfq_data
*bfqd,
* shortage.
*/
/* no more than ~18% of tags for async I/O */
- bfqd->word_depths[1][0] = max((bt->sb.depth * 3) >> 4, 1U);
+ bfqd->word_depths[1][0] = max(((1U << bt->sb.shift) * 3) >> 4, 1U);
/* no more than ~37% of tags for sync writes (~20% extra tags) */
- bfqd->word_depths[1][1] = max((bt->sb.depth * 6) >> 4, 1U);
+ bfqd->word_depths[1][1] = max(((1U << bt->sb.shift) * 6) >> 4, 1U);
for (i = 0; i < 2; i++)
for (j = 0; j < 2; j++)
Re: [RFC 01/20] mm/tlb: fix fullmm semantics
> On Jan 30, 2021, at 6:57 PM, Andy Lutomirski wrote: > > On Sat, Jan 30, 2021 at 5:19 PM Nadav Amit wrote: >>> On Jan 30, 2021, at 5:02 PM, Andy Lutomirski wrote: >>> >>> On Sat, Jan 30, 2021 at 4:16 PM Nadav Amit wrote: From: Nadav Amit fullmm in mmu_gather is supposed to indicate that the mm is torn-down (e.g., on process exit) and can therefore allow certain optimizations. However, tlb_finish_mmu() sets fullmm, when in fact it want to say that the TLB should be fully flushed. >>> >>> Maybe also rename fullmm? >> >> Possible. How about mm_torn_down? > > Sure. Or mm_exiting, perhaps? mm_exiting indeed sounds better.
Re: [PATCH 3/8] scsi: ufshpb: Add region's reads counter
On Mon, Feb 01, 2021 at 07:12:53AM +, Avri Altman wrote: > > > +#define WORK_PENDING 0 > > > +#define ACTIVATION_THRSHLD 4 /* 4 IOs */ > > Rather than fixing it with macro, how about using sysfs and make it > > configurable? > Yes. > I will add a patch making all the logic configurable. > As all those are hpb-related parameters, I think module parameters are more > adequate. No, this is not the 1990's, please never add new module parameters to drivers. If not for the basic problem of they do not work on a per-device basis, but on a per-driver basis, which is what you almost never want. But why would you want to change this value, why can't the driver "just work" and not need manual intervention? thanks, greg k-h
[PATCH] misc: rtsx: Remove unneeded return variable
This patch removes unneeded return variables, using only '0' instead. It fixes the following warning detected by coccinelle: ./drivers/misc/cardreader/rtsx_pcr.c:1808:5-8: Unneeded variable: "ret". Return "0" on line 1833. Reported-by: Abaci Robot Signed-off-by: Yang Li --- drivers/misc/cardreader/rtsx_pcr.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/misc/cardreader/rtsx_pcr.c b/drivers/misc/cardreader/rtsx_pcr.c index 5a491d2..7dc7780 100644 --- a/drivers/misc/cardreader/rtsx_pcr.c +++ b/drivers/misc/cardreader/rtsx_pcr.c @@ -1805,7 +1805,6 @@ static int rtsx_pci_runtime_resume(struct device *device) struct pci_dev *pcidev = to_pci_dev(device); struct pcr_handle *handle; struct rtsx_pcr *pcr; - int ret = 0; handle = pci_get_drvdata(pcidev); pcr = handle->pcr; @@ -1830,7 +1829,7 @@ static int rtsx_pci_runtime_resume(struct device *device) schedule_delayed_work(>idle_work, msecs_to_jiffies(200)); mutex_unlock(>pcr_mutex); - return ret; + return 0; } #else /* CONFIG_PM */ -- 1.8.3.1
Re: [PATCH v2] nvme-multipath: Early exit if no path is available
On 2/1/21 3:16 AM, Chao Leng wrote:
On 2021/1/29 17:20, Hannes Reinecke wrote:
On 1/29/21 9:46 AM, Chao Leng wrote:
On 2021/1/29 16:33, Hannes Reinecke wrote:
On 1/29/21 8:45 AM, Chao Leng wrote:
On 2021/1/29 15:06, Hannes Reinecke wrote:
On 1/29/21 4:07 AM, Chao Leng wrote:
On 2021/1/29 9:42, Sagi Grimberg wrote:
You can't see exactly where it dies but I followed the
assembly to
nvme_round_robin_path(). Maybe it's not the initial
nvme_next_ns(head,
old) which returns NULL but nvme_next_ns() is returning NULL
eventually
(list_next_or_null_rcu()).
So there is other bug cause nvme_next_ns abormal.
I review the code about head->list and head->current_path, I
find 2 bugs
may cause the bug:
First, I already send the patch. see:
https://lore.kernel.org/linux-nvme/20210128033351.22116-1-lengc...@huawei.com/
Second, in nvme_ns_remove, list_del_rcu is before
nvme_mpath_clear_current_path. This may cause "old" is deleted
from the
"head", but still use "old". I'm not sure there's any other
consideration here, I will check it and try to fix it.
The reason why we first remove from head->list and only then clear
current_path is because the other way around there is no way
to guarantee that that the ns won't be assigned as current_path
again (because it is in head->list).
ok, I see.
nvme_ns_remove fences continue of deletion of the ns by
synchronizing
the srcu such that for sure the current_path clearance is visible.
The list will be like this:
head->next = ns1;
ns1->next = head;
old->next = ns1;
Where does 'old' pointing to?
This may cause infinite loop in nvme_round_robin_path.
for (ns = nvme_next_ns(head, old);
ns != old;
ns = nvme_next_ns(head, ns))
The ns will always be ns1, and then infinite loop.
No. nvme_next_ns() will return NULL.
If there is just one path(the "old") and the "old" is deleted,
nvme_next_ns() will return NULL.
The list like this:
head->next = head;
old->next = head;
If there is two or more path and the "old" is deleted,
"for" will be infinite loop. because nvme_next_ns() will return
the path which in the list except the "old", check condition will
be true for ever.
But that will be caught by the statement above:
if (list_is_singular(>list))
no?
Two path just a sample example.
If there is just two path, will enter it, may cause no path but there is
actually one path. It is falsely assumed that the "old" must be not
deleted.
If there is more than two path, will cause infinite loop.
So you mean we'll need something like this?
diff --git a/drivers/nvme/host/multipath.c
b/drivers/nvme/host/multipath.c
index 71696819c228..8ffccaf9c19a 100644
--- a/drivers/nvme/host/multipath.c
+++ b/drivers/nvme/host/multipath.c
@@ -202,10 +202,12 @@ static struct nvme_ns *__nvme_find_path(struct
nvme_ns_head *head, int node)
static struct nvme_ns *nvme_next_ns(struct nvme_ns_head *head,
struct nvme_ns *ns)
{
- ns = list_next_or_null_rcu(>list, >siblings, struct
nvme_ns,
- siblings);
- if (ns)
- return ns;
+ if (ns) {
+ ns = list_next_or_null_rcu(>list, >siblings,
+ struct nvme_ns, siblings);
+ if (ns)
+ return ns;
+ }
No, in the scenario, ns should not be NULL.
Why not? 'ns == NULL' is precisely the corner-case this is trying to fix...
May be we can do like this:
diff --git a/drivers/nvme/host/multipath.c b/drivers/nvme/host/multipath.c
index 282b7a4ea9a9..b895011a2cbd 100644
--- a/drivers/nvme/host/multipath.c
+++ b/drivers/nvme/host/multipath.c
@@ -199,30 +199,24 @@ static struct nvme_ns *__nvme_find_path(struct
nvme_ns_head *head, int node)
return found;
}
-static struct nvme_ns *nvme_next_ns(struct nvme_ns_head *head,
- struct nvme_ns *ns)
-{
- ns = list_next_or_null_rcu(>list, >siblings, struct
nvme_ns,
- siblings);
- if (ns)
- return ns;
- return list_first_or_null_rcu(>list, struct nvme_ns,
siblings);
-}
+#define nvme_next_ns_condition(head, current, condition) \
+({ \
+ struct nvme_ns *__ptr = list_next_or_null_rcu(&(head)->list, \
+ &(current)->siblings, struct nvme_ns, siblings); \
+ __ptr ? __ptr : (condition) ? (condition) = false, \
+ list_first_or_null_rcu(&(head)->list, struct nvme_ns, \
+ siblings) : NULL; \
+})
Urgh. Please, no. That is well impossible to debug.
Can you please open-code it to demonstrate where the difference to the
current (and my fixed) versions is?
I'm still not clear where the problem is once we applied both patches.
Cheers,
Hannes
--
Dr. Hannes ReineckeKernel Storage Architect
h...@suse.de +49 911 74053 688
SUSE Software Solutions GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), Geschäftsführer: Felix Imendörffer
Re: [RFC 13/20] mm/tlb: introduce tlb_start_ptes() and tlb_end_ptes()
> On Jan 31, 2021, at 2:07 AM, Damian Tometzki wrote:
>
> On Sat, 30. Jan 16:11, Nadav Amit wrote:
>> From: Nadav Amit
>>
>> Introduce tlb_start_ptes() and tlb_end_ptes() which would be called
>> before and after PTEs are updated and TLB flushes are deferred. This
>> will be later be used for fine granualrity deferred TLB flushing
>> detection.
>>
>> In the meanwhile, move flush_tlb_batched_pending() into
>> tlb_start_ptes(). It was not called from mapping_dirty_helpers by
>> wp_pte() and clean_record_pte(), which might be a bug.
>>
>> No additional functional change is intended.
>>
>> Signed-off-by: Nadav Amit
>> Cc: Andrea Arcangeli
>> Cc: Andrew Morton
>> Cc: Andy Lutomirski
>> Cc: Dave Hansen
>> Cc: Peter Zijlstra
>> Cc: Thomas Gleixner
>> Cc: Will Deacon
>> Cc: Yu Zhao
>> Cc: Nick Piggin
>> Cc: x...@kernel.org
>> ---
>> fs/proc/task_mmu.c | 2 ++
>> include/asm-generic/tlb.h | 18 ++
>> mm/madvise.c | 6 --
>> mm/mapping_dirty_helpers.c | 15 +--
>> mm/memory.c| 2 ++
>> mm/mprotect.c | 3 ++-
>> 6 files changed, 41 insertions(+), 5 deletions(-)
>>
>> diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
>> index 4cd048ffa0f6..d0cce961fa5c 100644
>> --- a/fs/proc/task_mmu.c
>> +++ b/fs/proc/task_mmu.c
>> @@ -1168,6 +1168,7 @@ static int clear_refs_pte_range(pmd_t *pmd, unsigned
>> long addr,
>> return 0;
>>
>> pte = pte_offset_map_lock(vma->vm_mm, pmd, addr, );
>> +tlb_start_ptes(>tlb);
>> for (; addr != end; pte++, addr += PAGE_SIZE) {
>> ptent = *pte;
>>
>> @@ -1190,6 +1191,7 @@ static int clear_refs_pte_range(pmd_t *pmd, unsigned
>> long addr,
>> tlb_flush_pte_range(>tlb, addr, PAGE_SIZE);
>> ClearPageReferenced(page);
>> }
>> +tlb_end_ptes(>tlb);
>> pte_unmap_unlock(pte - 1, ptl);
>> cond_resched();
>> return 0;
>> diff --git a/include/asm-generic/tlb.h b/include/asm-generic/tlb.h
>> index 041be2ef4426..10690763090a 100644
>> --- a/include/asm-generic/tlb.h
>> +++ b/include/asm-generic/tlb.h
>> @@ -58,6 +58,11 @@
>> *Defaults to flushing at tlb_end_vma() to reset the range; helps when
>> *there's large holes between the VMAs.
>> *
>> + * - tlb_start_ptes() / tlb_end_ptes; makr the start / end of PTEs change.
>
> Hello Nadav,
>
> short nid makr/mark
Thanks! I will fix it.
Re: [RFC 08/20] mm: store completed TLB generation
> On Jan 31, 2021, at 12:32 PM, Andy Lutomirski wrote:
>
> On Sat, Jan 30, 2021 at 4:16 PM Nadav Amit wrote:
>> From: Nadav Amit
>>
>> To detect deferred TLB flushes in fine granularity, we need to keep
>> track on the completed TLB flush generation for each mm.
>>
>> Add logic to track for each mm the tlb_gen_completed, which tracks the
>> completed TLB generation. It is the arch responsibility to call
>> mark_mm_tlb_gen_done() whenever a TLB flush is completed.
>>
>> Start the generation numbers from 1 instead of 0. This would allow later
>> to detect whether flushes of a certain generation were completed.
>
> Can you elaborate on how this helps?
I guess it should have gone to patch 15.
The relevant code it interacts with is in read_defer_tlb_flush_gen(). It
allows to use a single check to see “outdated” deferred TLB gen. Initially
tlb->defer_gen is zero. We are going to do inc_mm_tlb_gen() both on the
first time we defer TLB entries and whenever we see mm_gen is newer than
tlb->defer_gen:
+ mm_gen = atomic64_read(>tlb_gen);
+
+ /*
+* This condition checks for both first deferred TLB flush and for other
+* TLB pending or executed TLB flushes after the last table that we
+* updated. In the latter case, we are going to skip a generation, which
+* would lead to a full TLB flush. This should therefore not cause
+* correctness issues, and should not induce overheads, since anyhow in
+* TLB storms it is better to perform full TLB flush.
+*/
+ if (mm_gen != tlb->defer_gen) {
+ VM_BUG_ON(mm_gen < tlb->defer_gen);
+
+ tlb->defer_gen = inc_mm_tlb_gen(mm);
+ }
>
> I think you should document that tlb_gen_completed only means that no
> outdated TLB entries will be observably used. In the x86
> implementation it's possible for older TLB entries to still exist,
> unused, in TLBs of cpus running other mms.
You mean entries that be later flushed during switch_mm_irqs_off(), right? I
think that overall my comments need some work. Yes.
> How does this work with arch_tlbbatch_flush()?
completed_gen is not updated by arch_tlbbatch_flush(), since I couldn’t find
a way to combine them. completed_gen might not catch up with tlb_gen in this
case until another TLB flush takes place. I do not see correctness issue,
but it might result in redundant TLB flush.
>> Signed-off-by: Nadav Amit
>> Cc: Andrea Arcangeli
>> Cc: Andrew Morton
>> Cc: Andy Lutomirski
>> Cc: Dave Hansen
>> Cc: Peter Zijlstra
>> Cc: Thomas Gleixner
>> Cc: Will Deacon
>> Cc: Yu Zhao
>> Cc: Nick Piggin
>> Cc: x...@kernel.org
>> ---
>> arch/x86/mm/tlb.c | 10 ++
>> include/asm-generic/tlb.h | 33 +
>> include/linux/mm_types.h | 15 ++-
>> 3 files changed, 57 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/x86/mm/tlb.c b/arch/x86/mm/tlb.c
>> index 7ab21430be41..d17b5575531e 100644
>> --- a/arch/x86/mm/tlb.c
>> +++ b/arch/x86/mm/tlb.c
>> @@ -14,6 +14,7 @@
>> #include
>> #include
>> #include
>> +#include
>>
>> #include "mm_internal.h"
>>
>> @@ -915,6 +916,9 @@ void flush_tlb_mm_range(struct mm_struct *mm, unsigned
>> long start,
>>if (cpumask_any_but(mm_cpumask(mm), cpu) < nr_cpu_ids)
>>flush_tlb_others(mm_cpumask(mm), info);
>>
>> + /* Update the completed generation */
>> + mark_mm_tlb_gen_done(mm, new_tlb_gen);
>> +
>>put_flush_tlb_info();
>>put_cpu();
>> }
>> @@ -1147,6 +1151,12 @@ void arch_tlbbatch_flush(struct
>> arch_tlbflush_unmap_batch *batch)
>>
>>cpumask_clear(>cpumask);
>>
>> + /*
>> +* We cannot call mark_mm_tlb_gen_done() since we do not know which
>> +* mm's should be flushed. This may lead to some unwarranted TLB
>> +* flushes, but not to correction problems.
>> +*/
>> +
>>put_cpu();
>> }
>>
>> diff --git a/include/asm-generic/tlb.h b/include/asm-generic/tlb.h
>> index 517c89398c83..427bfcc6cdec 100644
>> --- a/include/asm-generic/tlb.h
>> +++ b/include/asm-generic/tlb.h
>> @@ -513,6 +513,39 @@ static inline void tlb_end_vma(struct mmu_gather *tlb,
>> struct vm_area_struct *vm
>> }
>> #endif
>>
>> +#ifdef CONFIG_ARCH_HAS_TLB_GENERATIONS
>> +
>> +/*
>> + * Helper function to update a generation to have a new value, as long as
>> new
>> + * value is greater or equal to gen.
>> + */
>
> I read this a couple of times, and I don't understand it. How about:
>
> Helper function to atomically set *gen = max(*gen, new_gen)
>
>> +static inline void tlb_update_generation(atomic64_t *gen, u64 new_gen)
>> +{
>> + u64 cur_gen = atomic64_read(gen);
>> +
>> + while (cur_gen < new_gen) {
>> + u64 old_gen = atomic64_cmpxchg(gen, cur_gen, new_gen);
>> +
>> + /* Check if we succeeded in the cmpxchg */
>> + if (likely(cur_gen == old_gen))
>> + break;
>> +
>> +
Re: linux-next: build warning after merge of the akpm tree
On 1/28/2021 2:16 PM, Stephen Rothwell wrote:
> Hi all,
>
> After merging the akpm tree, today's linux-next build (x86_64
> allmodconfig) produced this warning:
>
> lib/stackdepot.c: In function 'is_stack_depot_disabled':
> lib/stackdepot.c:154:2: warning: ignoring return value of 'kstrtobool'
> declared with attribute 'warn_unused_result' [-Wunused-result]
> 154 | kstrtobool(str, _depot_disable);
> | ^
>
> Introduced by commit
>
> b9779abb09a8 ("lib: stackdepot: add support to disable stack depot")
>
> Interestingly, we have 2 declarations of kstrtobool - one in
> linux/kernel.h (which has __must_check) and one in linux/strings.h
> (which doesn't).
>
I have sent out the fix to lkml, Copied it below for your reference.
Please Feel free to apply or squash it to the original commit.
Thanks,
Vijay
--
From: Vijayanand Jitta
fix the below ignoring return value warning for kstrtobool
in is_stack_depot_disabled function.
lib/stackdepot.c: In function 'is_stack_depot_disabled':
lib/stackdepot.c:154:2: warning: ignoring return value of 'kstrtobool'
declared with attribute 'warn_unused_result' [-Wunused-result]
Fixes: b9779abb09a8 ("lib: stackdepot: add support to disable stack depot")
Signed-off-by: Vijayanand Jitta
---
lib/stackdepot.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/lib/stackdepot.c b/lib/stackdepot.c
index cc21116..49f67a0 100644
--- a/lib/stackdepot.c
+++ b/lib/stackdepot.c
@@ -151,8 +151,10 @@ static struct stack_record **stack_table;
static int __init is_stack_depot_disabled(char *str)
{
- kstrtobool(str, _depot_disable);
- if (stack_depot_disable) {
+ int ret;
+
+ ret = kstrtobool(str, _depot_disable);
+ if (!ret && stack_depot_disable) {
pr_info("Stack Depot is disabled\n");
stack_table = NULL;
}
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
member of Code Aurora Forum, hosted by The Linux Foundation
Re: [PATCH v6 1/4] crypto: Add support for ECDSA signature verification
在 2021/2/1 7:32, Stefan Berger 写道: +/** + * ecc_get_curve() - Get a curve given its curve_id + * + * @curve_id: Id of the curve + * + * Returns pointer to the curve data, NULL if curve is not available + */ +const struct ecc_curve *ecc_get_curve(unsigned int curve_id); + /** * ecc_is_key_valid() - Validate a given ECDH private key Shall we move this definition to 'include/crypto'? Other drivers may also want to use it.
Re: [PATCH 2/2] vdpa/mlx5: Restore the hardware used index after change map
On 2021/2/1 下午2:38, Eli Cohen wrote:
On Mon, Feb 01, 2021 at 02:00:35PM +0800, Jason Wang wrote:
On 2021/2/1 下午1:52, Eli Cohen wrote:
On Mon, Feb 01, 2021 at 11:36:23AM +0800, Jason Wang wrote:
On 2021/2/1 上午2:55, Eli Cohen wrote:
On Fri, Jan 29, 2021 at 11:49:45AM +0800, Jason Wang wrote:
On 2021/1/28 下午9:41, Eli Cohen wrote:
When a change of memory map occurs, the hardware resources are destroyed
and then re-created again with the new memory map. In such case, we need
to restore the hardware available and used indices. The driver failed to
restore the used index which is added here.
Fixes 1a86b377aa21 ("vdpa/mlx5: Add VDPA driver for supported mlx5 devices")
Signed-off-by: Eli Cohen
A question. Does this mean after a vq is suspended, the hw used index is not
equal to vq used index?
Surely there is just one "Used index" for a VQ. What I was trying to say
is that after the VQ is suspended, I read the used index by querying the
hardware. The read result is the used index that the hardware wrote to
memory.
Just to make sure I understand here. So it looks to me we had two index. The
first is the used index which is stored in the memory/virtqueue, the second
is the one that is stored by the device.
It is the structures defined in the virtio spec in 2.6.6 for the
available ring and 2.6.8 for the used ring. As you know these the
available ring is written to by the driver and read by the device. The
opposite happens for the used index.
Right, so for used index it was wrote by device. And the device should have
an internal used index value that is used to write to the used ring. And the
code is used to sync the device internal used index if I understand this
correctly.
The reason I need to restore the last known indices is for the new
hardware objects to sync on the last state and take over from there.
Right, after the vq suspending, the questions are:
1) is hardware internal used index might not be the same with the used index
in the virtqueue?
Generally the answer is no because the hardware is the only one writing
it. New objects start up with the initial value configured to them upon
creation. This value was zero before this change.
You could argue that since the hardware has access to virtqueue memory,
it could just read the value from there but it does not.
I see.
or
2) can we simply sync the virtqueue's used index to the hardware's used
index?
Theoretically it could be done but that's not how the hardware works.
One reason is that is not supposed to read from that area. But it is
really hardware implementation detail.
I get you now.
So
Acked-by: Jason Wang
Thanks
After the I create the new hardware object, I need to tell it
what is the used index (and the available index) as a way to sync it
with the existing VQ.
For avail index I understand that the hardware index is not synced with the
avail index stored in the memory/virtqueue. The question is used index, if
the hardware one is not synced with the one in the virtqueue. It means after
vq is suspended, some requests is not completed by the hardware (e.g the
buffer were not put to used ring).
This may have implications to live migration, it means those unaccomplished
requests needs to be migrated to the destination and resubmitted to the
device. This looks not easy.
Thanks
This sync is especially important when a change of map occurs while the
VQ was already used (hence the indices are likely to be non zero). This
can be triggered by hot adding memory after the VQs have been used.
Thanks
---
drivers/vdpa/mlx5/net/mlx5_vnet.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/vdpa/mlx5/net/mlx5_vnet.c
b/drivers/vdpa/mlx5/net/mlx5_vnet.c
index 549ded074ff3..3fc8588cecae 100644
--- a/drivers/vdpa/mlx5/net/mlx5_vnet.c
+++ b/drivers/vdpa/mlx5/net/mlx5_vnet.c
@@ -87,6 +87,7 @@ struct mlx5_vq_restore_info {
u64 device_addr;
u64 driver_addr;
u16 avail_index;
+ u16 used_index;
bool ready;
struct vdpa_callback cb;
bool restore;
@@ -121,6 +122,7 @@ struct mlx5_vdpa_virtqueue {
u32 virtq_id;
struct mlx5_vdpa_net *ndev;
u16 avail_idx;
+ u16 used_idx;
int fw_state;
/* keep last in the struct */
@@ -804,6 +806,7 @@ static int create_virtqueue(struct mlx5_vdpa_net *ndev,
struct mlx5_vdpa_virtque
obj_context = MLX5_ADDR_OF(create_virtio_net_q_in, in, obj_context);
MLX5_SET(virtio_net_q_object, obj_context, hw_available_index,
mvq->avail_idx);
+ MLX5_SET(virtio_net_q_object, obj_context, hw_used_index,
mvq->used_idx);
MLX5_SET(virtio_net_q_object, obj_context, queue_feature_bit_mask_12_3,
get_features_12_3(ndev->mvdev.actual_features));
vq_ctx = MLX5_ADDR_OF(virtio_net_q_object, obj_context,
virtio_q_context);
@@ -1022,6 +1025,7 @@ static int connect_qps(struct mlx5_vdpa_net *ndev, struct
mlx5_vdpa_virtqueue *m
struct
Re: [PATCH] x86/fault: Send SIGBUS to user process always for hwpoison page access.
On Fri, 29 Jan 2021 14:55:29 -0800 "Luck, Tony" wrote: > Thanks for the explanation and test code. I think I see better what > is going on here. > > [I took your idea for using madvise(...MADV_HWPOISON) and added a new "-S" > option to my einj_mem_uc test program to use madvise instead of ACPI/EINJ > for injections. Update pushed here: > git://git.kernel.org/pub/scm/linux/kernel/git/aegl/ras-tools.git ] > > There have been some small changes to arch/x86/mm/fault.c since you wrote > the patch. Can you rebase to v5.11-rc5? Yes, I will rebase it to newest version. > Also maybe this might be a case to use IS_ENABLED() instead of #ifdef to > make the code a little less ugly. At least for the 2nd hunk in your patch > this would work well: > > if (IS_ENABLED(CONFIG_MEMORY_FAILURE) && > (fault & (VM_FAULT_HWPOISON|VM_FAULT_HWPOISON_LARGE))) > no_context(regs, error_code, address, SIGBUS, BUS_MCEERR_AR); > else > no_context(regs, error_code, address, SIGBUS, BUS_ADRERR); > > The first hunk might need a bit more thought. > Do you mean the force_sig_mceerr and force_sig_fault difference? I see a hwpoison related comment there, but it's better to follow the usual way force_sig_mceerr, I will modify this in a v2 patch. Or something other, you may post a better one. Thanks -- Best Regards! Aili Yao
RE: [PATCH 6/8] scsi: ufshpb: Add hpb dev reset response
> > Hi Avri, > > > + list_for_each_entry_safe(rgn, next_rgn, _info->lh_lru_rgn, > > + list_lru_rgn) > How about replace list_for_each_entry_safe to list_for_each_entry? Done. Can also use the relaxed version in the timeout handler as well (patch 7/8). Thanks, Avri
Re: [PATCH 2/2] soc: mediatek: pm-domains: Add domain_supply cap for mfg_async PD
Hi Bilal,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on soc/for-next]
[also build test ERROR on clk/clk-next linux/master next-20210125]
[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/Bilal-Wasim/Misc-bug-fixes-in-mtk-power-domain-driver/20210201-135519
base: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git for-next
config: arc-randconfig-r006-20210201 (attached as .config)
compiler: arceb-elf-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
#
https://github.com/0day-ci/linux/commit/75afc46e31ee3d523fd11e48a5b9127b8d6a3718
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Bilal-Wasim/Misc-bug-fixes-in-mtk-power-domain-driver/20210201-135519
git checkout 75afc46e31ee3d523fd11e48a5b9127b8d6a3718
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=arc
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
In file included from drivers/soc/mediatek/mtk-pm-domains.c:18:
>> drivers/soc/mediatek/mt8173-pm-domains.h:66:11: error:
>> 'MTK_SCPD_DOMAIN_SUPPLY' undeclared here (not in a function)
66 | .caps = MTK_SCPD_DOMAIN_SUPPLY,
| ^~
vim +/MTK_SCPD_DOMAIN_SUPPLY +66 drivers/soc/mediatek/mt8173-pm-domains.h
8
9 /*
10 * MT8173 power domain support
11 */
12
13 static const struct scpsys_domain_data scpsys_domain_data_mt8173[] = {
14 [MT8173_POWER_DOMAIN_VDEC] = {
15 .sta_mask = PWR_STATUS_VDEC,
16 .ctl_offs = SPM_VDE_PWR_CON,
17 .sram_pdn_bits = GENMASK(11, 8),
18 .sram_pdn_ack_bits = GENMASK(12, 12),
19 },
20 [MT8173_POWER_DOMAIN_VENC] = {
21 .sta_mask = PWR_STATUS_VENC,
22 .ctl_offs = SPM_VEN_PWR_CON,
23 .sram_pdn_bits = GENMASK(11, 8),
24 .sram_pdn_ack_bits = GENMASK(15, 12),
25 },
26 [MT8173_POWER_DOMAIN_ISP] = {
27 .sta_mask = PWR_STATUS_ISP,
28 .ctl_offs = SPM_ISP_PWR_CON,
29 .sram_pdn_bits = GENMASK(11, 8),
30 .sram_pdn_ack_bits = GENMASK(13, 12),
31 },
32 [MT8173_POWER_DOMAIN_MM] = {
33 .sta_mask = PWR_STATUS_DISP,
34 .ctl_offs = SPM_DIS_PWR_CON,
35 .sram_pdn_bits = GENMASK(11, 8),
36 .sram_pdn_ack_bits = GENMASK(12, 12),
37 .bp_infracfg = {
38
BUS_PROT_UPDATE_TOPAXI(MT8173_TOP_AXI_PROT_EN_MM_M0 |
39
MT8173_TOP_AXI_PROT_EN_MM_M1),
40 },
41 },
42 [MT8173_POWER_DOMAIN_VENC_LT] = {
43 .sta_mask = PWR_STATUS_VENC_LT,
44 .ctl_offs = SPM_VEN2_PWR_CON,
45 .sram_pdn_bits = GENMASK(11, 8),
46 .sram_pdn_ack_bits = GENMASK(15, 12),
47 },
48 [MT8173_POWER_DOMAIN_AUDIO] = {
49 .sta_mask = PWR_STATUS_AUDIO,
50 .ctl_offs = SPM_AUDIO_PWR_CON,
51 .sram_pdn_bits = GENMASK(11, 8),
52 .sram_pdn_ack_bits = GENMASK(15, 12),
53 },
54 [MT8173_POWER_DOMAIN_USB] = {
55 .sta_mask = PWR_STATUS_USB,
56 .ctl_offs = SPM_USB_PWR_CON,
57 .sram_pdn_bits = GENMASK(11, 8),
58 .sram_pdn_ack_bits = GENMASK(15, 12),
59 .caps = MTK_SCPD_ACTIVE_WAKEUP,
60 },
61 [MT8173_POWER_DOMAIN_MFG_ASYNC] = {
62 .sta_mask = PWR_STATUS_MFG_ASYNC,
63 .ctl_offs = SPM_MFG_ASYNC_PWR_CON,
64 .sram_pdn_bits = GENMASK(11, 8),
65 .sram_pdn_ack_bits = 0,
> 66 .caps = MTK_SCPD_DOMAIN_SUPPLY,
67 },
68 [MT8173_POWER_DOMAIN_MFG_2D] = {
69 .sta_mask = PWR_STATUS_MFG_2D,
70 .ctl_offs = SPM_MFG_2D_PWR_CON,
71 .sram_pdn_bits = GENMASK(11, 8),
72 .sram_pdn_ack_bits = GENMASK(13, 12),
73 },
74 [MT8173_POWER_DOMAIN_MFG] = {
75
Re: [PATCH v4 1/2] bio: limit bio max size
On Mon, Feb 01, 2021 at 11:52:48AM +0900, Changheun Lee wrote: > > On Fri, Jan 29, 2021 at 12:49:08PM +0900, Changheun Lee wrote: > > > bio size can grow up to 4GB when muli-page bvec is enabled. > > > but sometimes it would lead to inefficient behaviors. > > > in case of large chunk direct I/O, - 32MB chunk read in user space - > > > all pages for 32MB would be merged to a bio structure if the pages > > > physical addresses are contiguous. it makes some delay to submit > > > until merge complete. bio max size should be limited to a proper size. > > > > > > When 32MB chunk read with direct I/O option is coming from userspace, > > > kernel behavior is below now. it's timeline. > > > > > > | bio merge for 32MB. total 8,192 pages are merged. > > > | total elapsed time is over 2ms. > > > |-- ... --->| > > > | 8,192 pages merged a > > > bio. > > > | at this time, first > > > bio submit is done. > > > | 1 bio is split to 32 > > > read request and issue. > > > |---> > > > |---> > > >|---> > > > .. > > > > > > |---> > > > > > > |--->| > > > total 19ms elapsed to complete 32MB read done > > > from device. | > > > > > > If bio max size is limited with 1MB, behavior is changed below. > > > bio_iov_iter_get_pages> > > | bio merge for 1MB. 256 pages are merged for each bio. > > > | total 32 bio will be made. > > > | total elapsed time is over 2ms. it's same. > > > | but, first bio submit timing is fast. about 100us. > > > |--->|--->|--->|---> ... -->|--->|--->|--->|--->| > > > | 256 pages merged a bio. > > > | at this time, first bio submit is done. > > > | and 1 read request is issued for 1 bio. > > > |---> > > >|---> > > > |---> > > > .. > > > |---> > > > |--->| > > > total 17ms elapsed to complete 32MB read done from device. | > > > > Can you share us if enabling THP in your application can avoid this issue? > > BTW, you > > need to make the 32MB buffer aligned with huge page size. IMO, THP > > perfectly fits > > your case. > > > > THP is enabled already like as below in my environment. It has no effect. > > cat /sys/kernel/mm/transparent_hugepage/enabled > [always] madvise never The 32MB user buffer needs to be huge page size aligned. If your system supports bcc/bpftrace, it is quite easy to check if the buffer is aligned. > > This issue was reported from performance benchmark application in open market. > I can't control application's working in open market. > It's not only my own case. This issue might be occured in many mobile > environment. > At least, I checked this problem in exynos, and qualcomm chipset. You just said it takes 2ms for building 32MB bio, but you never investigate the reason. I guess it is from get_user_pages_fast(), but maybe others. Can you dig further for the reason? Maybe it is one arm64 specific issue. BTW, bio_iov_iter_get_pages() just takes ~200us on one x86_64 VM with THP, which is observed via bcc/funclatency when running the following workload: [root@ktest-01 test]# cat fio.job [global] bs=32768k rw=randread iodepth=1 ioengine=psync direct=1 runtime=20 time_based group_reporting=0 ramp_time=5 [diotest] filename=/dev/sde [root@ktest-01 func]# /usr/share/bcc/tools/funclatency bio_iov_iter_get_pages Tracing 1 functions for "bio_iov_iter_get_pages"... Hit Ctrl-C to end. ^C nsecs : count distribution 0 -> 1 : 0|| 2 -> 3 : 0|| 4 -> 7 : 0|| 8 -> 15 : 0|| 16 -> 31 : 0|| 32 -> 63 : 0|| 64 -> 127: 0|| 128 -> 255: 0|| 256 -> 511: 0|| 512 -> 1023 : 0|
RE: [PATCH 1/1] clk: aspeed: modify some default clks are critical
> -Original Message- > From: Andrew Jeffery > Sent: Monday, January 25, 2021 8:47 AM > To: Ryan Chen ; Samuel Holland > ; Stephen Boyd ; Joel Stanley > > Cc: BMC-SW ; linux-aspeed > ; Michael Turquette > ; Linux Kernel Mailing List > ; linux-...@vger.kernel.org; Linux ARM > > Subject: Re: [PATCH 1/1] clk: aspeed: modify some default clks are critical > > > > On Fri, 22 Jan 2021, at 18:45, Ryan Chen wrote: > > Hello, > > How about this patch progress? > > It does impact a lot of machine that when BMC boot at u-boot. > > SUART is work for Host. But after boot into kernel, due to the clk > > disabled. > > The SUART is not work for Host anymore. > > Maybe it's worth taking Ryan's patch for now, and when the protected-clocks > binding gets merged we can rip out the CLK_IS_CRITICAL flags and convert the > Aspeed devicetrees to use protected-clocks instead? > > The only issue I see with that plan is it becomes ambiguous as to which clock > each platform considers crititical/in-need-of-protection. > Hello Joel, Will you take this patch? Or you have another approach I may modify for it. Regards, Ryan > > > -Original Message- > > > From: Samuel Holland > > > Sent: Thursday, October 29, 2020 10:25 AM > > > To: Stephen Boyd ; Joel Stanley > > > Cc: Andrew Jeffery ; Michael Turquette > > > ; Ryan Chen ; > > > BMC-SW ; Linux ARM > > > ; linux-aspeed > > > ; linux-...@vger.kernel.org; Linux > > > Kernel Mailing List > > > Subject: Re: Re: [PATCH 1/1] clk: aspeed: modify some default clks > > > are critical > > > > > > Stephen, > > > > > > On 10/14/20 12:16 PM, Stephen Boyd wrote: > > > > Quoting Joel Stanley (2020-10-13 22:28:00) > > > >> On Wed, 14 Oct 2020 at 02:50, Stephen Boyd > wrote: > > > >>> > > > >>> Quoting Ryan Chen (2020-09-28 00:01:08) > > > In ASPEED SoC LCLK is LPC clock for all SuperIO device, > > > UART1/UART2 are default for Host SuperIO UART device, eSPI clk > > > for Host eSPI bus access eSPI slave channel, those clks can't > > > be disable should keep default, otherwise will affect Host side > > > access SuperIO and SPI slave > > > device. > > > > > > Signed-off-by: Ryan Chen > > > --- > > > >>> > > > >>> Is there resolution on this thread? > > > >> > > > >> Not yet. > > > >> > > > >> We have a system where the BMC (management controller) controls > > > >> some clocks, but the peripherals that it's clocking are outside > > > >> the BMC's control. In this case, the host processor us using some > > > >> UARTs and what not independent of any code running on the BMC. > > > >> > > > >> Ryan wants to have them marked as critical so the BMC never > > > >> powers them > > > down. > > > >> > > > >> However, there are systems that don't use this part of the soc, > > > >> so for those implementations they are not critical and Linux on > > > >> the BMC can turn them off. > > > >> > > > >> Do you have any thoughts? Has anyone solved a similar problem > already? > > > >> > > > > > > > > Is this critical clocks in DT? Where we want to have different DT > > > > for different device configurations to indicate that some clks > > > > should be marked critical so they're never turned off and other > > > > times they aren't so they're turned off? > > > > > > > > It also sounds sort of like the protected-clocks binding. Where > > > > you don't want to touch certain clks depending on the usage > > > > configuration of the SoC. There is a patch to make that generic > > > > that I haven't applied because it looks wrong at first glance[1]. > > > > Maybe not registering those clks to the framework on the > > > > configuration that Ryan has is > > > good enough? > > > > > > Could you please be more specific than the patch "looks wrong"? I'm > > > more than happy to update the patch to address your concerns, but I > > > cannot do that unless I know what your concerns are. > > > > > > Regards, > > > Samuel > > > > > > > [1] > > > > https://lore.kernel.org/r/20200903040015.5627-2-sam...@sholland.or > > > > g > > ___ > > linux-arm-kernel mailing list > > linux-arm-ker...@lists.infradead.org > > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > >
Re: [PATCH 00/15] dmaengine: dw-edma: HDMA support
On 15-12-20, 18:30, Gustavo Pimentel wrote: > This patch series adds the HDMA support, as long the IP design has set > the compatible register map parameter, which allows compatibility at > some degree for the existing Synopsys DesignWare eDMA driver that is > already available on the Kernel. > > The HDMA "Hyper-DMA" IP is an enhancement of the eDMA "embedded-DMA" IP. > > This new improvement comes with a PCI DVSEC that allows to the driver > recognize and switch behavior if it's an eDMA or an HDMA, becoming > retrocompatible, in the absence of this DVSEC, the driver will assume > that is an eDMA IP. > > It also adds the interleaved support, since it will be similar to the > current scatter-gather implementation. > > As well fixes/improves some abnormal behaviors not detected before, such as: > - crash on loading/unloading driver > - memory space definition for the data area and for the linked list space > - scatter-gather address calculation on 32 bits platforms > - minor comment and variable reordering > > Cc: Vinod Koul > Cc: Dan Williams > Cc: Bjorn Helgaas > Cc: dmaeng...@vger.kernel.org > Cc: linux-kernel@vger.kernel.org > Cc: linux-...@vger.kernel.org > > Gustavo Pimentel (15): > dmaengine: dw-edma: Add writeq() and readq() for 64 bits architectures > dmaengine: dw-edma: Fix comments offset characters' alignment > dmaengine: dw-edma: Add support for the HDMA feature > PCI: Add pci_find_vsec_capability() to find a specific VSEC Had this been picked up.. I see we have dependency on pci patch for this series.. > dmaengine: dw-edma: Add PCIe VSEC data retrieval support > dmaengine: dw-edma: Add device_prep_interleave_dma() support > dmaengine: dw-edma: Improve number of channels check > dmaengine: dw-edma: Reorder variables to keep consistency > dmaengine: dw-edma: Improve the linked list and data blocks definition > dmaengine: dw-edma: Change linked list and data blocks offset and > sizes > dmaengine: dw-edma: Move struct dentry variable from static definition > into dw_edma struct > dmaengine: dw-edma: Fix crash on loading/unloading driver > dmaengine: dw-edma: Change DMA abreviation from lower into upper case > dmaengine: dw-edma: Revert fix scatter-gather address calculation > dmaengine: dw-edma: Add pcim_iomap_table return checker > > drivers/dma/dw-edma/dw-edma-core.c | 178 +++--- > drivers/dma/dw-edma/dw-edma-core.h | 37 ++-- > drivers/dma/dw-edma/dw-edma-pcie.c | 275 +--- > drivers/dma/dw-edma/dw-edma-v0-core.c| 300 > --- > drivers/dma/dw-edma/dw-edma-v0-core.h| 2 +- > drivers/dma/dw-edma/dw-edma-v0-debugfs.c | 77 > drivers/dma/dw-edma/dw-edma-v0-debugfs.h | 4 +- > drivers/dma/dw-edma/dw-edma-v0-regs.h| 291 +++--- > drivers/pci/pci.c| 29 +++ > include/linux/pci.h | 1 + > include/uapi/linux/pci_regs.h| 5 + > 11 files changed, 844 insertions(+), 355 deletions(-) > > -- > 2.7.4 -- ~Vinod
Re: short-circuit and over-current IRQs
On Sat, 2021-01-30 at 16:43 +0100, AngeloGioacchino Del Regno wrote: > Il 29/01/21 10:14, Matti Vaittinen ha scritto: > > On Thu, 2021-01-28 at 12:10 +, Mark Brown wrote: > > > On Thu, Jan 28, 2021 at 09:23:08AM +, Vaittinen, Matti wrote: > > > > On Wed, 2021-01-27 at 16:32 +, Mark Brown wrote: > > > > > limits (one for initiating potential SW recovery - other for > > > > > HW > > > > to > > > > forcing protection) actually make sense. So does implementing > > > > notifiers > > > > / error statuses for events where SW recovery is potentially > > > > helpful. > > > > But whether the existing event notifications / error flags are > > > > correct > > > > for these is something I can't decide :) Here I ask guidance > > > > for > > > > Mark & > > > > others who know what is the idea behind existing error- > > > > flags/events. > > > > > > It's not that we shouldn't implement support for warnings, it's > > > that > > > they're not the common case for hardware and so won't line up > > > with > > > behaviour for other users. > > but anyway, I have no idea what would you do when a warning is > triggered: make a good example, please... Unfortunately, I typically lost the visibility to final solutions :( I guess that's the prize I must pay for working for a component vendor nowadays. I've heard "word of mouth" that some setup had issues with graphics accelerator heating - which was solved by cutting the power from this IC (via regulator control) when things went wrong. Sure the video playing was 'stopped' - but rest of the device remained usable and no data was lost. But as I said, this is what I heard of - not what I've done. OTOH. I never stop being surprized by what people invent when they have a problem to work around. I've seen a phone-like device which had start-up problems at times - and which did 'secret reboot' by keeping display running while rebooting - and due to fast reboot this resulted actually a good user experience. My point? I am positive that by giving the tools to invent work-around for problem - there will be a work- around using that tool :) > > For regulator framework that would mean supporting the warning > > level > > events (and regulator_get_error_flags warning-flags?) too. > > > > For (my) driver this would mean getting the information from > > device- > > tree. I didn't yet check the existing DT properties (if any for > > these > > levels) - but I think we should have something like: > > > > regulator-over-voltage-protection-microvolt = <>; > > regulator-over-voltage-error-microvolt = <>; > > regulator-over-voltage-warning-microvolt = <>; > > > > *-protection-* would be point where HW (or driver) shuts down the > > outputs w/o asking questions. (if HW based protection limit can not > > be > > set but protection can be enabled/disabled then value '1' would > > mean > > enable, zero would mean disable). > > > > regulator-over-voltage-protection; > ^^^ that would look better, since we already have a > "regulator-over-current-protection" property to enable OCP. > > Then, my suggestion would be: > regulator-over-voltage-max-microvolt = ; > > And to signal that the hardware will auto-shutdown the rail: > regulator-over-voltage-auto-shutdown; This would prevent having limits for both the protection and error at same time, right? I would like to have separate property for HW- specific shut-down (or shutdown by driver W/O any consumer driver actions - which seems like HW originated shut-down). This is why I wanted to have *-protection-* and *-error-*. Most of the ROHM ICs actually provide the 'protection' - although the limit is rarely configurable. (I am unsure if it is configurable on any ROHM PMIC I've worked with) I still think allowing limit would be Ok in order to keep all of the properties "looking" the same. Few ICs (like the BD9576MUF) additionally support the 'notification IRQ' with configurable limit - and this is where we can allow board designer to set this as error or warning. I am thinking that for BD9576 we should allow setting: 'protection'(disable/enable) "HW originated shutdown" and additionally either 'error' (limit/disable/enable) "existing err notification" or 'warning' (limit/disable/enable) "new warning notification" So - we would need separate properties for all 3 levels. As I said, I would like to add the 'limit' also for protection to keep it identical to error and warning levels. The thing that bugs me with these limit properties and actually with many other 'safety related' properties (like charger current/voltage limits/thresholds at battery nodes) is that when the parsing is left for IC drivers - then we see no warning when property is given but driver does not care about it. This is why I think parsing these properties should be left for the regulator core - and IC drivers should only fill the enable/disable/set-limit callbacks in ops. The core could spill a warning if DT defines these limits but the IC driver does not
RE: [PATCH 4/8] scsi: ufshpb: Make eviction depends on region's reads
> > > Hi Avri, > > > + /* > > + * in host control mode, verify that the exiting region > > + * has less reads > > + */ > > + if (ufshpb_mode == HPB_HOST_CONTROL && > > + atomic64_read(>reads) > (EVICTION_THRSHLD >> 1)) > Why we use shifted value to verify less read? I think we should use another > value to verify. Yes. Will make every logic parameters configurable.
RE: [PATCH 3/8] scsi: ufshpb: Add region's reads counter
> > +#define WORK_PENDING 0
> > +#define ACTIVATION_THRSHLD 4 /* 4 IOs */
> Rather than fixing it with macro, how about using sysfs and make it
> configurable?
Yes.
I will add a patch making all the logic configurable.
As all those are hpb-related parameters, I think module parameters are more
adequate.
>
> > @@ -306,12 +325,39 @@ void ufshpb_prep(struct ufs_hba *hba, struct
> ufshcd_lrb *lrbp)
> > ufshpb_set_ppn_dirty(hpb, rgn_idx, srgn_idx, srgn_offset,
> >transfer_len);
> > spin_unlock_irqrestore(>rgn_state_lock, flags);
> > +
> > + if (ufshpb_mode == HPB_HOST_CONTROL)
> > + atomic64_set(>reads, 0);
> > +
> > return;
> > }
> >
> > + if (ufshpb_mode == HPB_HOST_CONTROL)
> > + reads = atomic64_inc_return(>reads);
> > +
> > if (!ufshpb_is_support_chunk(transfer_len))
> > return; <- *this*
> >
> > + if (ufshpb_mode == HPB_HOST_CONTROL) {
> > + /*
> > + * in host control mode, reads are the main source for
> > + * activation trials.
> > + */
> > + if (reads == ACTIVATION_THRSHLD) {
> If the chunk size is not supported, we can not active this region
> permanently. It may be returned before get this statement.
Yes.
I already noticed that replying to Greg.
Fixed that when I dropped the use of atomic variables.
>
> > diff --git a/drivers/scsi/ufs/ufshpb.h b/drivers/scsi/ufs/ufshpb.h
> > index 8a34b0f42754..b0e78728af38 100644
> > --- a/drivers/scsi/ufs/ufshpb.h
> > +++ b/drivers/scsi/ufs/ufshpb.h
> > @@ -115,6 +115,9 @@ struct ufshpb_region {
> > /* below information is used by lru */
> > struct list_head list_lru_rgn;
> > unsigned long rgn_flags;
> > +
> > + /* region reads - for host mode */
> > + atomic64_t reads;
> I think 32 bits are suitable, because it is normalized by worker on every
> specific time.
Done.
[PATCH] mwifiex: Report connected BSS with cfg80211_connect_bss()
When a network is moved or reconfigured on the different channel, there
can be multiple BSSes with the same BSSID and SSID in scan result
before the old one expires. Then, it can cause cfg80211_connect_result
to map current_bss to a bss with the wrong channel.
Let mwifiex_cfg80211_assoc return the selected BSS and then the caller
can report it cfg80211_connect_bss.
Signed-off-by: Yen-lin Lai
---
.../net/wireless/marvell/mwifiex/cfg80211.c | 35 ++-
1 file changed, 26 insertions(+), 9 deletions(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/cfg80211.c
b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
index a6b9dc6700b1..4bae83e47e9e 100644
--- a/drivers/net/wireless/marvell/mwifiex/cfg80211.c
+++ b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
@@ -2173,7 +2173,8 @@ static int
mwifiex_cfg80211_assoc(struct mwifiex_private *priv, size_t ssid_len,
const u8 *ssid, const u8 *bssid, int mode,
struct ieee80211_channel *channel,
- struct cfg80211_connect_params *sme, bool privacy)
+ struct cfg80211_connect_params *sme, bool privacy,
+ struct cfg80211_bss **sel_bss)
{
struct cfg80211_ssid req_ssid;
int ret, auth_type = 0;
@@ -2307,17 +2308,31 @@ mwifiex_cfg80211_assoc(struct mwifiex_private *priv,
size_t ssid_len,
}
}
+ if (bss)
+ cfg80211_ref_bss(priv->adapter->wiphy, bss);
+
ret = mwifiex_bss_start(priv, bss, _ssid);
if (ret)
- return ret;
+ goto cleanup;
if (mode == NL80211_IFTYPE_ADHOC) {
/* Inform the BSS information to kernel, otherwise
* kernel will give a panic after successful assoc */
- if (mwifiex_cfg80211_inform_ibss_bss(priv))
- return -EFAULT;
+ if (mwifiex_cfg80211_inform_ibss_bss(priv)) {
+ ret = -EFAULT;
+ goto cleanup;
+ }
}
+ /* Pass the selected BSS entry to caller. */
+ if (sel_bss) {
+ *sel_bss = bss;
+ bss = NULL;
+ }
+
+cleanup:
+ if (bss)
+ cfg80211_put_bss(priv->adapter->wiphy, bss);
return ret;
}
@@ -2334,6 +2349,7 @@ mwifiex_cfg80211_connect(struct wiphy *wiphy, struct
net_device *dev,
{
struct mwifiex_private *priv = mwifiex_netdev_get_priv(dev);
struct mwifiex_adapter *adapter = priv->adapter;
+ struct cfg80211_bss *bss = NULL;
int ret;
if (GET_BSS_ROLE(priv) != MWIFIEX_BSS_ROLE_STA) {
@@ -2369,11 +2385,12 @@ mwifiex_cfg80211_connect(struct wiphy *wiphy, struct
net_device *dev,
cfg80211_sched_scan_stopped_rtnl(priv->wdev.wiphy, 0);
ret = mwifiex_cfg80211_assoc(priv, sme->ssid_len, sme->ssid, sme->bssid,
-priv->bss_mode, sme->channel, sme, 0);
+priv->bss_mode, sme->channel, sme, 0,
+);
if (!ret) {
- cfg80211_connect_result(priv->netdev, priv->cfg_bssid, NULL, 0,
- NULL, 0, WLAN_STATUS_SUCCESS,
- GFP_KERNEL);
+ cfg80211_connect_bss(priv->netdev, priv->cfg_bssid, bss, NULL,
+0, NULL, 0, WLAN_STATUS_SUCCESS,
+GFP_KERNEL, NL80211_TIMEOUT_UNSPECIFIED);
mwifiex_dbg(priv->adapter, MSG,
"info: associated to bssid %pM successfully\n",
priv->cfg_bssid);
@@ -2504,7 +2521,7 @@ mwifiex_cfg80211_join_ibss(struct wiphy *wiphy, struct
net_device *dev,
ret = mwifiex_cfg80211_assoc(priv, params->ssid_len, params->ssid,
params->bssid, priv->bss_mode,
params->chandef.chan, NULL,
-params->privacy);
+params->privacy, NULL);
done:
if (!ret) {
cfg80211_ibss_joined(priv->netdev, priv->cfg_bssid,
--
2.30.0.365.g02bc693789-goog
Re: [PATCH v3 03/34] mailbox: vpu-ipc-mailbox: Add support for Intel VPU IPC mailbox
On Fri, Jan 29, 2021 at 8:21 PM wrote:
>
> From: Daniele Alessandrelli
>
> Add mailbox controller enabling inter-processor communication (IPC)
> between the CPU (aka, the Application Processor - AP) and the VPU on
> Intel Movidius SoCs like Keem Bay.
>
> The controller uses HW FIFOs to enable such communication. Specifically,
> there are two FIFOs, one for the CPU and one for VPU. Each FIFO can hold
> 128 entries (messages) of 32-bit each (but only 26 bits are actually
> usable, since the 6 least-significant bits are reserved).
>
> When the Linux kernel on the AP needs to send messages to the VPU
> firmware, it writes them to the VPU FIFO; similarly, when the VPU
> firmware needs to send messages to the AP, it writes them to the CPU
> FIFO.
>
> The AP is notified of pending messages in the CPU FIFO by means of the
> 'FIFO-not-empty' interrupt, which is generated by the CPU FIFO while not
> empty. This interrupt is cleared automatically once all messages have
> been read from the FIFO (i.e., the FIFO has been emptied).
>
> The hardware doesn't provide an TX done IRQ (i.e., an IRQ that allows
> the VPU firmware to notify the AP that the message put into the VPU FIFO
> has been received); however the AP can ensure that the message has been
> successfully put into the VPU FIFO (and therefore transmitted) by
> checking the VPU FIFO status register to ensure that writing the message
> didn't cause the FIFO to overflow.
>
> Therefore, the mailbox controller is configured as capable of tx_done
> IRQs and a tasklet is used to simulate the tx_done IRQ. The tasklet is
> activated by send_data() right after the message has been put into the
> VPU FIFO and the VPU FIFO status registers has been checked. If an
> overflow is reported by the status register, the tasklet passes -EBUSY
> to mbox_chan_txdone(), to notify the mailbox client of the failed TX.
>
> The client should therefore register a tx_done() callback to properly
> handle failed transmissions.
>
> Note: the 'txdone_poll' mechanism cannot be used because it doesn't
> provide a way to report a failed transmission.
>
txdone means the last submitted transfer has been done with --
successfully or not.
So I think we can do without the tasklet as explained below
> +static int vpu_ipc_mailbox_send_data(struct mbox_chan *chan, void *data)
> +{
> + struct vpu_ipc_mbox *vpu_ipc_mbox = chan->con_priv;
> + u32 entry, overflow;
> +
> + entry = *((u32 *)data);
> +
Are all messages max 32bits wide?
Usually the controller specifies a packet format (more than just a
word but of course that's not mandatory) that a client submits the
data to be transmitted in. Esp when it has deep FIFOs.
> + /* Ensure last 6-bits of entry are not used. */
> + if (unlikely(entry & IPC_FIFO_ENTRY_RSVD_MASK)) {
> + vpu_ipc_mbox->txdone_result = -EINVAL;
> + goto exit;
> + }
> +
> + /* Add processor ID to entry. */
> + entry |= IPC_FIFO_ID_CPU & IPC_FIFO_ENTRY_RSVD_MASK;
> +
> + /* Write entry to VPU FIFO. */
> + iowrite32(entry, vpu_ipc_mbox->vpu_fifo_base + IPC_FIFO);
> +
> + /* Check if we overflew the VPU FIFO. */
> + overflow = ioread32(vpu_ipc_mbox->vpu_fifo_base + IPC_FIFO_OF_FLAG0) &
> + BIT(IPC_FIFO_ID_CPU);
> + if (unlikely(overflow)) {
> + /* Reset overflow register. */
> + iowrite32(BIT(IPC_FIFO_ID_CPU),
> + vpu_ipc_mbox->vpu_fifo_base + IPC_FIFO_OF_FLAG0);
> + vpu_ipc_mbox->txdone_result = -EBUSY;
> + goto exit;
> + }
> + vpu_ipc_mbox->txdone_result = 0;
> +
> +exit:
> + /* Schedule tasklet to call mbox_chan_txdone(). */
> + tasklet_schedule(_ipc_mbox->txdone_tasklet);
> +
> + return 0;
> +}
> +
Maybe set txdone_poll and implement last_tx_done() where you can wait
for FIFO to have enough space for another message, so that the next
submitted request will never return -EBUSY.
thanks
[PATCH] lib: stackdepot: fix ignoring return value warning
From: Vijayanand Jitta
fix the below ignoring return value warning for kstrtobool
in is_stack_depot_disabled function.
lib/stackdepot.c: In function 'is_stack_depot_disabled':
lib/stackdepot.c:154:2: warning: ignoring return value of 'kstrtobool'
declared with attribute 'warn_unused_result' [-Wunused-result]
Fixes: b9779abb09a8 ("lib: stackdepot: add support to disable stack depot")
Signed-off-by: Vijayanand Jitta
---
lib/stackdepot.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/lib/stackdepot.c b/lib/stackdepot.c
index cc21116..49f67a0 100644
--- a/lib/stackdepot.c
+++ b/lib/stackdepot.c
@@ -151,8 +151,10 @@ static struct stack_record **stack_table;
static int __init is_stack_depot_disabled(char *str)
{
- kstrtobool(str, _depot_disable);
- if (stack_depot_disable) {
+ int ret;
+
+ ret = kstrtobool(str, _depot_disable);
+ if (!ret && stack_depot_disable) {
pr_info("Stack Depot is disabled\n");
stack_table = NULL;
}
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of
Code Aurora Forum, hosted by The Linux Foundation
2.7.4
[PATCH next v3 09/16] arm64: dts: mediatek: mt8173: fix dtbs_check warning
Harmonize nodes names, compatibles and remove unused property.
Signed-off-by: Chunfeng Yun
---
v2~v3: no changes
---
arch/arm64/boot/dts/mediatek/mt8173-evb.dts | 4 +---
arch/arm64/boot/dts/mediatek/mt8173.dtsi| 13 +++--
2 files changed, 8 insertions(+), 9 deletions(-)
diff --git a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
index 6dffada2e66b..0ce81c4fe81e 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
+++ b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
@@ -516,10 +516,8 @@
extcon = <_usb>;
dr_mode = "otg";
wakeup-source;
- pinctrl-names = "default", "id_float", "id_ground";
+ pinctrl-names = "default";
pinctrl-0 = <_id_pins_float>;
- pinctrl-1 = <_id_pins_float>;
- pinctrl-2 = <_id_pins_ground>;
status = "okay";
};
diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index 7fa870e4386a..75040a820f0d 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -631,7 +631,7 @@
#mbox-cells = <2>;
};
- mipi_tx0: mipi-dphy@10215000 {
+ mipi_tx0: dsi-phy@10215000 {
compatible = "mediatek,mt8173-mipi-tx";
reg = <0 0x10215000 0 0x1000>;
clocks = <>;
@@ -641,7 +641,7 @@
status = "disabled";
};
- mipi_tx1: mipi-dphy@10216000 {
+ mipi_tx1: dsi-phy@10216000 {
compatible = "mediatek,mt8173-mipi-tx";
reg = <0 0x10216000 0 0x1000>;
clocks = <>;
@@ -926,7 +926,7 @@
};
ssusb: usb@11271000 {
- compatible = "mediatek,mt8173-mtu3";
+ compatible = "mediatek,mt8173-mtu3", "mediatek,mtu3";
reg = <0 0x11271000 0 0x3000>,
<0 0x11280700 0 0x0100>;
reg-names = "mac", "ippc";
@@ -943,8 +943,9 @@
ranges;
status = "disabled";
- usb_host: xhci@1127 {
- compatible = "mediatek,mt8173-xhci";
+ usb_host: usb@1127 {
+ compatible = "mediatek,mt8173-xhci",
+"mediatek,mtk-xhci";
reg = <0 0x1127 0 0x1000>;
reg-names = "mac";
interrupts = ;
@@ -955,7 +956,7 @@
};
};
- u3phy: usb-phy@1129 {
+ u3phy: t-phy@1129 {
compatible = "mediatek,mt8173-u3phy";
reg = <0 0x1129 0 0x800>;
#address-cells = <2>;
--
2.18.0
[PATCH next v3 13/16] arm64: dts: mediatek: mt8183: fix dtbs_check warning
Harmonize node names, compatibles and properties.
Signed-off-by: Chunfeng Yun
---
v3: remove property clock-names suggested by CK
v2: no changes
---
arch/arm64/boot/dts/mediatek/mt8183.dtsi | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
index 5b782a4769e7..12a3c7f03e1a 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
@@ -865,7 +865,7 @@
ranges;
status = "disabled";
- usb_host: xhci@1120 {
+ usb_host: usb@1120 {
compatible = "mediatek,mt8183-xhci",
"mediatek,mtk-xhci";
reg = <0 0x1120 0 0x1000>;
@@ -908,11 +908,10 @@
status = "disabled";
};
- mipi_tx0: mipi-dphy@11e5 {
+ mipi_tx0: dsi-phy@11e5 {
compatible = "mediatek,mt8183-mipi-tx";
reg = <0 0x11e5 0 0x1000>;
clocks = < CLK_APMIXED_MIPID0_26M>;
- clock-names = "ref_clk";
#clock-cells = <0>;
#phy-cells = <0>;
clock-output-names = "mipi_tx0_pll";
@@ -931,11 +930,10 @@
};
};
- u3phy: usb-phy@11f4 {
+ u3phy: t-phy@11f4 {
compatible = "mediatek,mt8183-tphy",
"mediatek,generic-tphy-v2";
#address-cells = <1>;
- #phy-cells = <1>;
#size-cells = <1>;
ranges = <0 0 0x11f4 0x1000>;
status = "okay";
--
2.18.0
[PATCH next v3 08/16] dt-bindings: usb: mediatek: musb: add mt8516 compatbile
Add support mt8516 compatbile Signed-off-by: Chunfeng Yun --- v2~v3: no changes --- Documentation/devicetree/bindings/usb/mediatek,musb.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/usb/mediatek,musb.yaml b/Documentation/devicetree/bindings/usb/mediatek,musb.yaml index a515c9f30b96..e02d8f5d53dc 100644 --- a/Documentation/devicetree/bindings/usb/mediatek,musb.yaml +++ b/Documentation/devicetree/bindings/usb/mediatek,musb.yaml @@ -17,6 +17,7 @@ properties: compatible: items: - enum: + - mediatek,mt8516-musb - mediatek,mt2701-musb - const: mediatek,mtk-musb -- 2.18.0
[PATCH next v3 03/16] dt-bindings: phy: mediatek: dsi-phy: modify compatible dependence
mt7623-mipi-tx is compatible to mt2701-mipi-tx, and use "mediatek,mt2701-mipi-tx" instead on MT7623, so modify the compatible items to make dependence clear. Cc: Chun-Kuang Hu Cc: Philipp Zabel Signed-off-by: Chunfeng Yun --- v3: modify commit message suggested by CK v2: separate two patches suggested by CK --- .../devicetree/bindings/phy/mediatek,dsi-phy.yaml | 13 - 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/Documentation/devicetree/bindings/phy/mediatek,dsi-phy.yaml b/Documentation/devicetree/bindings/phy/mediatek,dsi-phy.yaml index 71d4acea1f66..6e4d795f9b02 100644 --- a/Documentation/devicetree/bindings/phy/mediatek,dsi-phy.yaml +++ b/Documentation/devicetree/bindings/phy/mediatek,dsi-phy.yaml @@ -19,11 +19,14 @@ properties: pattern: "^dsi-phy@[0-9a-f]+$" compatible: -enum: - - mediatek,mt2701-mipi-tx - - mediatek,mt7623-mipi-tx - - mediatek,mt8173-mipi-tx - - mediatek,mt8183-mipi-tx +oneOf: + - items: + - enum: + - mediatek,mt7623-mipi-tx + - const: mediatek,mt2701-mipi-tx + - const: mediatek,mt2701-mipi-tx + - const: mediatek,mt8173-mipi-tx + - const: mediatek,mt8183-mipi-tx reg: maxItems: 1 -- 2.18.0
[PATCH next v3 11/16] arm64: dts: mediatek: mt8516: harmonize node names and compatibles
This is used to fix dtbs_check warning:
harmonize node names and compatibles;
add property "usb-role-switch" for connector dependence.
Signed-off-by: Chunfeng Yun
---
v2~v3: no changes
---
arch/arm64/boot/dts/mediatek/mt8516.dtsi | 9 +
arch/arm64/boot/dts/mediatek/pumpkin-common.dtsi | 1 +
2 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/mediatek/mt8516.dtsi
b/arch/arm64/boot/dts/mediatek/mt8516.dtsi
index e6e4d9d60094..70c9c7423bd4 100644
--- a/arch/arm64/boot/dts/mediatek/mt8516.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8516.dtsi
@@ -450,7 +450,7 @@
};
usb0: usb@1110 {
- compatible = "mediatek,mtk-musb";
+ compatible = "mediatek,mt8516-musb",
"mediatek,mtk-musb";
reg = <0 0x1110 0 0x1000>;
interrupts = ;
interrupt-names = "mc";
@@ -463,7 +463,7 @@
};
usb1: usb@1119 {
- compatible = "mediatek,mtk-musb";
+ compatible = "mediatek,mt8516-musb",
"mediatek,mtk-musb";
reg = <0 0x1119 0 0x1000>;
interrupts = ;
interrupt-names = "mc";
@@ -476,8 +476,9 @@
status = "disabled";
};
- usb_phy: usb@ {
- compatible = "mediatek,generic-tphy-v1";
+ usb_phy: t-phy@ {
+ compatible = "mediatek,mt8516-tphy",
+"mediatek,generic-tphy-v1";
reg = <0 0x 0 0x800>;
#address-cells = <2>;
#size-cells = <2>;
diff --git a/arch/arm64/boot/dts/mediatek/pumpkin-common.dtsi
b/arch/arm64/boot/dts/mediatek/pumpkin-common.dtsi
index 63fd70086bb8..7d738f01cf8d 100644
--- a/arch/arm64/boot/dts/mediatek/pumpkin-common.dtsi
+++ b/arch/arm64/boot/dts/mediatek/pumpkin-common.dtsi
@@ -188,6 +188,7 @@
{
status = "okay";
dr_mode = "peripheral";
+ usb-role-switch;
usb_con: connector {
compatible = "usb-c-connector";
--
2.18.0
[PATCH next v3 12/16] arm64: dts: mediatek: mt7622: harmonize node names and compatibles
This is used to fix dtbs_check warning
Signed-off-by: Chunfeng Yun
---
v2~v3: no changes
---
arch/arm64/boot/dts/mediatek/mt7622.dtsi | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/mediatek/mt7622.dtsi
b/arch/arm64/boot/dts/mediatek/mt7622.dtsi
index 5b9ec032ce8d..4cfa09b0ca3c 100644
--- a/arch/arm64/boot/dts/mediatek/mt7622.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt7622.dtsi
@@ -740,8 +740,8 @@
status = "disabled";
};
- u3phy: usb-phy@1a0c4000 {
- compatible = "mediatek,mt7622-u3phy",
+ u3phy: t-phy@1a0c4000 {
+ compatible = "mediatek,mt7622-tphy",
"mediatek,generic-tphy-v1";
reg = <0 0x1a0c4000 0 0x700>;
#address-cells = <2>;
@@ -875,8 +875,9 @@
status = "disabled";
};
- sata_phy: sata-phy@1a243000 {
- compatible = "mediatek,generic-tphy-v1";
+ sata_phy: t-phy@1a243000 {
+ compatible = "mediatek,mt7622-tphy",
+"mediatek,generic-tphy-v1";
#address-cells = <2>;
#size-cells = <2>;
ranges;
--
2.18.0
[PATCH next v3 15/16] arm: dts: mt7623: harmonize node names and compatibles
This is used to fix dtbs_check warning
Signed-off-by: Chunfeng Yun
---
v2~v3: no changes
---
arch/arm/boot/dts/mt7623.dtsi | 26 ++
arch/arm/boot/dts/mt7623n.dtsi | 4 ++--
2 files changed, 16 insertions(+), 14 deletions(-)
diff --git a/arch/arm/boot/dts/mt7623.dtsi b/arch/arm/boot/dts/mt7623.dtsi
index aea6809500d7..3c11f7cfcc40 100644
--- a/arch/arm/boot/dts/mt7623.dtsi
+++ b/arch/arm/boot/dts/mt7623.dtsi
@@ -787,8 +787,9 @@
};
};
- pcie0_phy: pcie-phy@1a149000 {
- compatible = "mediatek,generic-tphy-v1";
+ pcie0_phy: t-phy@1a149000 {
+ compatible = "mediatek,mt7623-tphy",
+"mediatek,generic-tphy-v1";
reg = <0 0x1a149000 0 0x0700>;
#address-cells = <2>;
#size-cells = <2>;
@@ -804,8 +805,9 @@
};
};
- pcie1_phy: pcie-phy@1a14a000 {
- compatible = "mediatek,generic-tphy-v1";
+ pcie1_phy: t-phy@1a14a000 {
+ compatible = "mediatek,mt7623-tphy",
+"mediatek,generic-tphy-v1";
reg = <0 0x1a14a000 0 0x0700>;
#address-cells = <2>;
#size-cells = <2>;
@@ -823,7 +825,7 @@
usb1: usb@1a1c {
compatible = "mediatek,mt7623-xhci",
-"mediatek,mt8173-xhci";
+"mediatek,mtk-xhci";
reg = <0 0x1a1c 0 0x1000>,
<0 0x1a1c4700 0 0x0100>;
reg-names = "mac", "ippc";
@@ -836,9 +838,9 @@
status = "disabled";
};
- u3phy1: usb-phy@1a1c4000 {
- compatible = "mediatek,mt7623-u3phy",
-"mediatek,mt2701-u3phy";
+ u3phy1: t-phy@1a1c4000 {
+ compatible = "mediatek,mt7623-tphy",
+"mediatek,generic-tphy-v1";
reg = <0 0x1a1c4000 0 0x0700>;
#address-cells = <2>;
#size-cells = <2>;
@@ -864,7 +866,7 @@
usb2: usb@1a24 {
compatible = "mediatek,mt7623-xhci",
-"mediatek,mt8173-xhci";
+"mediatek,mtk-xhci";
reg = <0 0x1a24 0 0x1000>,
<0 0x1a244700 0 0x0100>;
reg-names = "mac", "ippc";
@@ -877,9 +879,9 @@
status = "disabled";
};
- u3phy2: usb-phy@1a244000 {
- compatible = "mediatek,mt7623-u3phy",
-"mediatek,mt2701-u3phy";
+ u3phy2: t-phy@1a244000 {
+ compatible = "mediatek,mt7623-tphy",
+"mediatek,generic-tphy-v1";
reg = <0 0x1a244000 0 0x0700>;
#address-cells = <2>;
#size-cells = <2>;
diff --git a/arch/arm/boot/dts/mt7623n.dtsi b/arch/arm/boot/dts/mt7623n.dtsi
index 1880ac9e32cf..bcb0846e29fd 100644
--- a/arch/arm/boot/dts/mt7623n.dtsi
+++ b/arch/arm/boot/dts/mt7623n.dtsi
@@ -246,7 +246,7 @@
status = "disabled";
};
- mipi_tx0: mipi-dphy@1001 {
+ mipi_tx0: dsi-phy@1001 {
compatible = "mediatek,mt7623-mipi-tx",
"mediatek,mt2701-mipi-tx";
reg = <0 0x1001 0 0x90>;
@@ -265,7 +265,7 @@
status = "disabled";
};
- hdmi_phy: phy@10209100 {
+ hdmi_phy: hdmi-phy@10209100 {
compatible = "mediatek,mt7623-hdmi-phy",
"mediatek,mt2701-hdmi-phy";
reg = <0 0x10209100 0 0x24>;
--
2.18.0
[PATCH] memory: tegra186-emc: Replace DEFINE_SIMPLE_ATTRIBUTE with DEFINE_DEBUGFS_ATTRIBUTE
Fix the following coccicheck warning:
./drivers/memory/tegra/tegra186-emc.c:158:0-23: WARNING:
tegra186_emc_debug_max_rate_fops should be defined with
DEFINE_DEBUGFS_ATTRIBUTE.
./drivers/memory/tegra/tegra186-emc.c:128:0-23: WARNING:
tegra186_emc_debug_min_rate_fops should be defined with
DEFINE_DEBUGFS_ATTRIBUTE.
Reported-by: Abaci Robot
Signed-off-by: Jiapeng Chong
---
drivers/memory/tegra/tegra186-emc.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/memory/tegra/tegra186-emc.c
b/drivers/memory/tegra/tegra186-emc.c
index fa8af17..d65e7c2 100644
--- a/drivers/memory/tegra/tegra186-emc.c
+++ b/drivers/memory/tegra/tegra186-emc.c
@@ -125,9 +125,9 @@ static int tegra186_emc_debug_min_rate_set(void *data, u64
rate)
return 0;
}
-DEFINE_SIMPLE_ATTRIBUTE(tegra186_emc_debug_min_rate_fops,
- tegra186_emc_debug_min_rate_get,
- tegra186_emc_debug_min_rate_set, "%llu\n");
+DEFINE_DEBUGFS_ATTRIBUTE(tegra186_emc_debug_min_rate_fops,
+ tegra186_emc_debug_min_rate_get,
+ tegra186_emc_debug_min_rate_set, "%llu\n");
static int tegra186_emc_debug_max_rate_get(void *data, u64 *rate)
{
@@ -155,9 +155,9 @@ static int tegra186_emc_debug_max_rate_set(void *data, u64
rate)
return 0;
}
-DEFINE_SIMPLE_ATTRIBUTE(tegra186_emc_debug_max_rate_fops,
- tegra186_emc_debug_max_rate_get,
- tegra186_emc_debug_max_rate_set, "%llu\n");
+DEFINE_DEBUGFS_ATTRIBUTE(tegra186_emc_debug_max_rate_fops,
+ tegra186_emc_debug_max_rate_get,
+ tegra186_emc_debug_max_rate_set, "%llu\n");
static int tegra186_emc_probe(struct platform_device *pdev)
{
--
1.8.3.1
[PATCH next v3 02/16] dt-bindings: usb: mediatek: fix yamllint check warning
Fix warning: "too many spaces inside brackets" Signed-off-by: Chunfeng Yun --- v2~v3: no changes --- .../devicetree/bindings/usb/mediatek,mtk-xhci.yaml | 2 +- Documentation/devicetree/bindings/usb/mediatek,mtu3.yaml| 6 +++--- Documentation/devicetree/bindings/usb/mediatek,musb.yaml| 4 ++-- 3 files changed, 6 insertions(+), 6 deletions(-) diff --git a/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml b/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml index 38b1fe18aa79..a3817f3af59d 100644 --- a/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml +++ b/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml @@ -139,7 +139,7 @@ patternProperties: description: The hard wired USB devices. dependencies: - wakeup-source: [ 'mediatek,syscon-wakeup' ] + wakeup-source: ['mediatek,syscon-wakeup'] required: - compatible diff --git a/Documentation/devicetree/bindings/usb/mediatek,mtu3.yaml b/Documentation/devicetree/bindings/usb/mediatek,mtu3.yaml index f5c04b9d2de9..66d78f534722 100644 --- a/Documentation/devicetree/bindings/usb/mediatek,mtu3.yaml +++ b/Documentation/devicetree/bindings/usb/mediatek,mtu3.yaml @@ -172,9 +172,9 @@ patternProperties: example if the host mode is enabled. dependencies: - connector: [ 'usb-role-switch' ] - port: [ 'usb-role-switch' ] - wakeup-source: [ 'mediatek,syscon-wakeup' ] + connector: ['usb-role-switch'] + port: ['usb-role-switch'] + wakeup-source: ['mediatek,syscon-wakeup'] required: - compatible diff --git a/Documentation/devicetree/bindings/usb/mediatek,musb.yaml b/Documentation/devicetree/bindings/usb/mediatek,musb.yaml index 790efe8b6274..a515c9f30b96 100644 --- a/Documentation/devicetree/bindings/usb/mediatek,musb.yaml +++ b/Documentation/devicetree/bindings/usb/mediatek,musb.yaml @@ -66,8 +66,8 @@ properties: type: object dependencies: - usb-role-switch: [ 'connector' ] - connector: [ 'usb-role-switch' ] + usb-role-switch: ['connector'] + connector: ['usb-role-switch'] required: - compatible -- 2.18.0
[PATCH next v3 16/16] arm: dts: mt2701: harmonize node names and compatibles
This is used to fix dtbs_check warning
Signed-off-by: Chunfeng Yun
---
v2~v3: no changes
---
arch/arm/boot/dts/mt2701.dtsi | 19 +++
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/arch/arm/boot/dts/mt2701.dtsi b/arch/arm/boot/dts/mt2701.dtsi
index fade14284017..4776f85d6d5b 100644
--- a/arch/arm/boot/dts/mt2701.dtsi
+++ b/arch/arm/boot/dts/mt2701.dtsi
@@ -607,7 +607,7 @@
};
usb0: usb@1a1c {
- compatible = "mediatek,mt8173-xhci";
+ compatible = "mediatek,mt2701-xhci", "mediatek,mtk-xhci";
reg = <0 0x1a1c 0 0x1000>,
<0 0x1a1c4700 0 0x0100>;
reg-names = "mac", "ippc";
@@ -620,8 +620,9 @@
status = "disabled";
};
- u3phy0: usb-phy@1a1c4000 {
- compatible = "mediatek,mt2701-u3phy";
+ u3phy0: t-phy@1a1c4000 {
+ compatible = "mediatek,mt2701-tphy",
+"mediatek,generic-tphy-v1";
reg = <0 0x1a1c4000 0 0x0700>;
#address-cells = <2>;
#size-cells = <2>;
@@ -646,7 +647,7 @@
};
usb1: usb@1a24 {
- compatible = "mediatek,mt8173-xhci";
+ compatible = "mediatek,mt2701-xhci", "mediatek,mtk-xhci";
reg = <0 0x1a24 0 0x1000>,
<0 0x1a244700 0 0x0100>;
reg-names = "mac", "ippc";
@@ -659,8 +660,9 @@
status = "disabled";
};
- u3phy1: usb-phy@1a244000 {
- compatible = "mediatek,mt2701-u3phy";
+ u3phy1: t-phy@1a244000 {
+ compatible = "mediatek,mt2701-tphy",
+"mediatek,generic-tphy-v1";
reg = <0 0x1a244000 0 0x0700>;
#address-cells = <2>;
#size-cells = <2>;
@@ -700,8 +702,9 @@
status = "disabled";
};
- u2phy0: usb-phy@1121 {
- compatible = "mediatek,generic-tphy-v1";
+ u2phy0: t-phy@1121 {
+ compatible = "mediatek,mt2701-tphy",
+"mediatek,generic-tphy-v1";
reg = <0 0x1121 0 0x0800>;
#address-cells = <2>;
#size-cells = <2>;
--
2.18.0
[PATCH next v3 14/16] arm: dts: mt7629: harmonize node names and compatibles
This is used to fix dtbs_check warning
Signed-off-by: Chunfeng Yun
---
v2~v3: no changes
---
arch/arm/boot/dts/mt7629.dtsi | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/arch/arm/boot/dts/mt7629.dtsi b/arch/arm/boot/dts/mt7629.dtsi
index 5cbb3d244c75..874043f0490d 100644
--- a/arch/arm/boot/dts/mt7629.dtsi
+++ b/arch/arm/boot/dts/mt7629.dtsi
@@ -329,8 +329,9 @@
status = "disabled";
};
- u3phy0: usb-phy@1a0c4000 {
- compatible = "mediatek,generic-tphy-v2";
+ u3phy0: t-phy@1a0c4000 {
+ compatible = "mediatek,mt7629-tphy",
+"mediatek,generic-tphy-v2";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0 0x1a0c4000 0xe00>;
@@ -413,14 +414,15 @@
};
};
- pciephy1: pcie-phy@1a14a000 {
- compatible = "mediatek,generic-tphy-v2";
+ pciephy1: t-phy@1a14a000 {
+ compatible = "mediatek,mt7629-tphy",
+"mediatek,generic-tphy-v2";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0 0x1a14a000 0x1000>;
status = "disabled";
- pcieport1: port1phy@0 {
+ pcieport1: pcie-phy@0 {
reg = <0 0x1000>;
clocks = <>;
clock-names = "ref";
--
2.18.0
[PATCH next v3 01/16] dt-bindings: usb: fix yamllint check warning
Fix warning: "missing starting space in comment" Signed-off-by: Chunfeng Yun --- v2~v3: no changes --- Documentation/devicetree/bindings/usb/usb-device.yaml | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Documentation/devicetree/bindings/usb/usb-device.yaml b/Documentation/devicetree/bindings/usb/usb-device.yaml index 7bb25a45427d..23e76cfb2066 100644 --- a/Documentation/devicetree/bindings/usb/usb-device.yaml +++ b/Documentation/devicetree/bindings/usb/usb-device.yaml @@ -82,9 +82,9 @@ required: additionalProperties: true examples: - #hub connected to port 1 - #device connected to port 2 - #device connected to port 3 + # hub connected to port 1 + # device connected to port 2 + # device connected to port 3 #interface 0 of configuration 1 #interface 0 of configuration 2 - | -- 2.18.0
[PATCH next v3 10/16] arm64: dts: mediatek: mt2712: harmonize node names
This is used to fix dtbs_check warning.
Signed-off-by: Chunfeng Yun
---
v2~v3: no changes
---
arch/arm64/boot/dts/mediatek/mt2712e.dtsi | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/mediatek/mt2712e.dtsi
b/arch/arm64/boot/dts/mediatek/mt2712e.dtsi
index db17d0a4ed57..a9cca9c146fd 100644
--- a/arch/arm64/boot/dts/mediatek/mt2712e.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt2712e.dtsi
@@ -805,7 +805,7 @@
ranges;
status = "disabled";
- usb_host0: xhci@1127 {
+ usb_host0: usb@1127 {
compatible = "mediatek,mt2712-xhci",
"mediatek,mtk-xhci";
reg = <0 0x1127 0 0x1000>;
@@ -818,7 +818,7 @@
};
};
- u3phy0: usb-phy@1129 {
+ u3phy0: t-phy@1129 {
compatible = "mediatek,mt2712-tphy",
"mediatek,generic-tphy-v2";
#address-cells = <1>;
@@ -869,7 +869,7 @@
ranges;
status = "disabled";
- usb_host1: xhci@112c {
+ usb_host1: usb@112c {
compatible = "mediatek,mt2712-xhci",
"mediatek,mtk-xhci";
reg = <0 0x112c 0 0x1000>;
@@ -882,7 +882,7 @@
};
};
- u3phy1: usb-phy@112e {
+ u3phy1: t-phy@112e {
compatible = "mediatek,mt2712-tphy",
"mediatek,generic-tphy-v2";
#address-cells = <1>;
--
2.18.0
[PATCH next v3 05/16] dt-bindings: phy: mediatek: tphy: change patternProperties
The phy may be named as pcie-phy when the T-PHY only supports PCIe mode, it's also the similar case for SATA, named as sata-phy. Signed-off-by: Chunfeng Yun --- v2~v3: no changes --- Documentation/devicetree/bindings/phy/mediatek,tphy.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml b/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml index 602e6ff45785..4f1733fd9a55 100644 --- a/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml +++ b/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml @@ -117,7 +117,7 @@ properties: # Required child node: patternProperties: - "^usb-phy@[0-9a-f]+$": + "^(usb|pcie|sata)-phy@[0-9a-f]+$": type: object description: A sub-node is required for each port the controller provides. -- 2.18.0
[PATCH next v3 04/16] dt-bindings: phy: mediatek: hdmi-phy: modify compatible items
mt7623-hdmi-tx is compatible to mt2701-hdmi-tx, and the compatible "mediatek,mt7623-hdmi-tx" is not supported in driver, in fact uses "mediatek,mt2701-hdmi-tx" instead on MT7623, so changes the compatible items to make dependence clear. Cc: Chun-Kuang Hu Cc: Philipp Zabel Signed-off-by: Chunfeng Yun --- v3: modify commit message v2: no changes --- .../devicetree/bindings/phy/mediatek,hdmi-phy.yaml| 11 +++ 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/Documentation/devicetree/bindings/phy/mediatek,hdmi-phy.yaml b/Documentation/devicetree/bindings/phy/mediatek,hdmi-phy.yaml index 4752517a1446..0d94950b84ca 100644 --- a/Documentation/devicetree/bindings/phy/mediatek,hdmi-phy.yaml +++ b/Documentation/devicetree/bindings/phy/mediatek,hdmi-phy.yaml @@ -21,10 +21,13 @@ properties: pattern: "^hdmi-phy@[0-9a-f]+$" compatible: -enum: - - mediatek,mt2701-hdmi-phy - - mediatek,mt7623-hdmi-phy - - mediatek,mt8173-hdmi-phy +oneOf: + - items: + - enum: + - mediatek,mt7623-hdmi-phy + - const: mediatek,mt2701-hdmi-phy + - const: mediatek,mt2701-hdmi-phy + - const: mediatek,mt8173-hdmi-phy reg: maxItems: 1 -- 2.18.0
[PATCH next v3 06/16] dt-bindings: usb: mtk-xhci: add optional assigned clock properties
Add optional property "assigned-clock" and "assigned-clock-parents" used by mt7629. Signed-off-by: Chunfeng Yun --- v3: no changes v2: separate compatible out of the patch --- .../devicetree/bindings/usb/mediatek,mtk-xhci.yaml| 8 1 file changed, 8 insertions(+) diff --git a/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml b/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml index a3817f3af59d..5eb8d7cd8155 100644 --- a/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml +++ b/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml @@ -67,6 +67,14 @@ properties: - const: dma_ck - const: xhci_ck + assigned-clocks: +minItems: 1 +maxItems: 5 + + assigned-clock-parents: +minItems: 1 +maxItems: 5 + phys: description: List of all PHYs used on this HCD, it's better to keep PHYs in order -- 2.18.0
[PATCH next v3 07/16] dt-bindings: usb: mtk-xhci: add compatible for mt2701 and mt7623
Add two compatible for mt2701 and mt7623; Signed-off-by: Chunfeng Yun --- v3: no changes v2: new patch separated from [6/15] --- Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml b/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml index 5eb8d7cd8155..46fe3a189359 100644 --- a/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml +++ b/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml @@ -23,8 +23,10 @@ properties: compatible: items: - enum: + - mediatek,mt2701-xhci - mediatek,mt2712-xhci - mediatek,mt7622-xhci + - mediatek,mt7623-xhci - mediatek,mt7629-xhci - mediatek,mt8173-xhci - mediatek,mt8183-xhci -- 2.18.0
linux-next: build warning after merge of the net-next tree
Hi all,
After merging the net-next tree, today's linux-next build (htmldocs)
produced this warning:
Documentation/networking/device_drivers/ethernet/mellanox/mlx5.rst:16: WARNING:
Unknown target name: "mlx5 port function".
Introduced by commit
142d93d12dc1 ("net/mlx5: Add devlink subfunction port documentation")
--
Cheers,
Stephen Rothwell
pgpzLMlQ3f_wA.pgp
Description: OpenPGP digital signature
[PATCH v14 07/11] KVM: vmx/pmu: Reduce the overhead of LBR pass-through or cancellation
When the LBR records msrs has already been pass-through, there is no
need to call vmx_update_intercept_for_lbr_msrs() again and again, and
vice versa.
Signed-off-by: Like Xu
Reviewed-by: Andi Kleen
---
arch/x86/kvm/vmx/pmu_intel.c | 13 +
arch/x86/kvm/vmx/vmx.h | 3 +++
2 files changed, 16 insertions(+)
diff --git a/arch/x86/kvm/vmx/pmu_intel.c b/arch/x86/kvm/vmx/pmu_intel.c
index 287fc14f0445..60f395e18446 100644
--- a/arch/x86/kvm/vmx/pmu_intel.c
+++ b/arch/x86/kvm/vmx/pmu_intel.c
@@ -550,6 +550,7 @@ static void intel_pmu_init(struct kvm_vcpu *vcpu)
vcpu->arch.perf_capabilities = 0;
lbr_desc->records.nr = 0;
lbr_desc->event = NULL;
+ lbr_desc->msr_passthrough = false;
}
static void intel_pmu_reset(struct kvm_vcpu *vcpu)
@@ -596,12 +597,24 @@ static void vmx_update_intercept_for_lbr_msrs(struct
kvm_vcpu *vcpu, bool set)
static inline void vmx_disable_lbr_msrs_passthrough(struct kvm_vcpu *vcpu)
{
+ struct lbr_desc *lbr_desc = vcpu_to_lbr_desc(vcpu);
+
+ if (!lbr_desc->msr_passthrough)
+ return;
+
vmx_update_intercept_for_lbr_msrs(vcpu, true);
+ lbr_desc->msr_passthrough = false;
}
static inline void vmx_enable_lbr_msrs_passthrough(struct kvm_vcpu *vcpu)
{
+ struct lbr_desc *lbr_desc = vcpu_to_lbr_desc(vcpu);
+
+ if (lbr_desc->msr_passthrough)
+ return;
+
vmx_update_intercept_for_lbr_msrs(vcpu, false);
+ lbr_desc->msr_passthrough = true;
}
/*
diff --git a/arch/x86/kvm/vmx/vmx.h b/arch/x86/kvm/vmx/vmx.h
index 863bb3fe73d4..4d6a2624a204 100644
--- a/arch/x86/kvm/vmx/vmx.h
+++ b/arch/x86/kvm/vmx/vmx.h
@@ -90,6 +90,9 @@ struct lbr_desc {
* The records may be inaccurate if the host reclaims the LBR.
*/
struct perf_event *event;
+
+ /* True if LBRs are marked as not intercepted in the MSR bitmap */
+ bool msr_passthrough;
};
/*
--
2.29.2
Re: [PATCH] dmaengine: qcom: bam_dma: Add LOCK and UNLOCK flag bit support
On 01-02-21, 11:52, mda...@codeaurora.org wrote:
> On 2021-02-01 11:35, Vinod Koul wrote:
> > On 27-01-21, 23:56, mda...@codeaurora.org wrote:
> > > The actual LOCK/UNLOCK flag should be set on hardware command
> > > descriptor.
> > > so this flag setting should be done in DMA engine driver. The user
> > > of the
> > > DMA
> > > driver like (in case of IPQ5018) Crypto can use flag
> > > "DMA_PREP_LOCK" &
> > > "DMA_PREP_UNLOCK"
> > > while preparing CMD descriptor before submitting to the DMA
> > > engine. In DMA
> > > engine driver
> > > we are checking these flasgs on CMD descriptor and setting actual
> > > LOCK/UNLOCK flag on hardware
> > > descriptor.
> >
> >
> > I am not sure I comprehend this yet.. when is that we would need to do
> > this... is this for each txn submitted to dmaengine.. or something
> > else..
>
> Its not for each transaction submitted to dmaengine. We have to set this
> only
> once on CMD descriptor. So when A53 crypto driver need to change the crypto
> configuration
> then first it will lock the all other pipes using setting the LOCK flag bit
> on CMD
> descriptor and then it can start the transaction , on data descriptor this
> flag will
> not get set once all transaction will be completed the A53 crypto driver
> release the lock on
> all other pipes using UNLOCK flag on CMD descriptor. So LOCK/UNLOCK will be
> only once and not for
> the each transaction.
Okay so why cant the bam driver check cmd descriptor and do lock/unlock
as below, why do we need users to do this.
if (flags & DMA_PREP_CMD) {
do_lock_bam();
The point here is that this seems to be internal to dma and should be
handled by dma driver.
Also if we do this, it needs to be done for specific platforms..
Thanks
--
~Vinod
Re: [PATCH] nbd: Fix NULL pointer in flush_workqueue
hi，Markus
在 2021/1/29 3:42, Markus Elfring 写道:
…
+++ b/drivers/block/nbd.c
@@ -2011,12 +2011,20 @@ static int nbd_genl_disconnect(struct sk_buff *skb,
struct genl_info *info)
index);
return -EINVAL;
}
+ mutex_lock(>config_lock);
if (!refcount_inc_not_zero(>refs)) {
mutex_unlock(_index_mutex);
+ mutex_unlock(>config_lock);
Can an other function call order become relevant for the unlocking of these
mutexes?
Do you think the nbd->config_lock mutex here is useless?
printk(KERN_ERR "nbd: device at index %d is going down\n",
index);
May such an error message be moved into the lock scope?
Sure.
return -EINVAL;
}
+ if (!nbd->recv_workq) {
+ mutex_unlock(>config_lock);
+ mutex_unlock(_index_mutex);
+ return -EINVAL;
+ }
How do you think about to connect the code from this if branch
with a jump target like “unlock” so that such statements would be shareable
for the desired exception handling?
OK, I will improve it in V2 patch.
+ mutex_unlock(>config_lock);
mutex_unlock(_index_mutex);
if (!refcount_inc_not_zero(>config_refs)) {
nbd_put(nbd);
Regards,
Markus
.
Re: [PATCH 2/2] vdpa/mlx5: Restore the hardware used index after change map
On Mon, Feb 01, 2021 at 02:00:35PM +0800, Jason Wang wrote:
>
> On 2021/2/1 下午1:52, Eli Cohen wrote:
> > On Mon, Feb 01, 2021 at 11:36:23AM +0800, Jason Wang wrote:
> > > On 2021/2/1 上午2:55, Eli Cohen wrote:
> > > > On Fri, Jan 29, 2021 at 11:49:45AM +0800, Jason Wang wrote:
> > > > > On 2021/1/28 下午9:41, Eli Cohen wrote:
> > > > > > When a change of memory map occurs, the hardware resources are
> > > > > > destroyed
> > > > > > and then re-created again with the new memory map. In such case, we
> > > > > > need
> > > > > > to restore the hardware available and used indices. The driver
> > > > > > failed to
> > > > > > restore the used index which is added here.
> > > > > >
> > > > > > Fixes 1a86b377aa21 ("vdpa/mlx5: Add VDPA driver for supported mlx5
> > > > > > devices")
> > > > > > Signed-off-by: Eli Cohen
> > > > > A question. Does this mean after a vq is suspended, the hw used index
> > > > > is not
> > > > > equal to vq used index?
> > > > Surely there is just one "Used index" for a VQ. What I was trying to say
> > > > is that after the VQ is suspended, I read the used index by querying the
> > > > hardware. The read result is the used index that the hardware wrote to
> > > > memory.
> > >
> > > Just to make sure I understand here. So it looks to me we had two index.
> > > The
> > > first is the used index which is stored in the memory/virtqueue, the
> > > second
> > > is the one that is stored by the device.
> > >
> > It is the structures defined in the virtio spec in 2.6.6 for the
> > available ring and 2.6.8 for the used ring. As you know these the
> > available ring is written to by the driver and read by the device. The
> > opposite happens for the used index.
>
>
> Right, so for used index it was wrote by device. And the device should have
> an internal used index value that is used to write to the used ring. And the
> code is used to sync the device internal used index if I understand this
> correctly.
>
>
> > The reason I need to restore the last known indices is for the new
> > hardware objects to sync on the last state and take over from there.
>
>
> Right, after the vq suspending, the questions are:
>
> 1) is hardware internal used index might not be the same with the used index
> in the virtqueue?
>
Generally the answer is no because the hardware is the only one writing
it. New objects start up with the initial value configured to them upon
creation. This value was zero before this change.
You could argue that since the hardware has access to virtqueue memory,
it could just read the value from there but it does not.
> or
>
> 2) can we simply sync the virtqueue's used index to the hardware's used
> index?
>
Theoretically it could be done but that's not how the hardware works.
One reason is that is not supposed to read from that area. But it is
really hardware implementation detail.
> >
> > > >After the I create the new hardware object, I need to tell it
> > > > what is the used index (and the available index) as a way to sync it
> > > > with the existing VQ.
> > >
> > > For avail index I understand that the hardware index is not synced with
> > > the
> > > avail index stored in the memory/virtqueue. The question is used index, if
> > > the hardware one is not synced with the one in the virtqueue. It means
> > > after
> > > vq is suspended, some requests is not completed by the hardware (e.g the
> > > buffer were not put to used ring).
> > >
> > > This may have implications to live migration, it means those
> > > unaccomplished
> > > requests needs to be migrated to the destination and resubmitted to the
> > > device. This looks not easy.
> > >
> > > Thanks
> > >
> > >
> > > > This sync is especially important when a change of map occurs while the
> > > > VQ was already used (hence the indices are likely to be non zero). This
> > > > can be triggered by hot adding memory after the VQs have been used.
> > > >
> > > > > Thanks
> > > > >
> > > > >
> > > > > > ---
> > > > > > drivers/vdpa/mlx5/net/mlx5_vnet.c | 7 +++
> > > > > > 1 file changed, 7 insertions(+)
> > > > > >
> > > > > > diff --git a/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > > > > > b/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > > > > > index 549ded074ff3..3fc8588cecae 100644
> > > > > > --- a/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > > > > > +++ b/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > > > > > @@ -87,6 +87,7 @@ struct mlx5_vq_restore_info {
> > > > > > u64 device_addr;
> > > > > > u64 driver_addr;
> > > > > > u16 avail_index;
> > > > > > + u16 used_index;
> > > > > > bool ready;
> > > > > > struct vdpa_callback cb;
> > > > > > bool restore;
> > > > > > @@ -121,6 +122,7 @@ struct mlx5_vdpa_virtqueue {
> > > > > > u32 virtq_id;
> > > > > > struct mlx5_vdpa_net *ndev;
> > > > > > u16 avail_idx;
> > > > > > + u16 used_idx;
> > > > > > int fw_state;
> > > > > >
Re: [PATCH RFC v2 06/10] vdpa_sim: cleanup kiovs in vdpasim_free()
On 2021/1/28 下午10:41, Stefano Garzarella wrote:
vringh_getdesc_iotlb() allocates memory to store the kvec, that
is freed with vringh_kiov_cleanup().
vringh_getdesc_iotlb() is able to reuse a kvec previously allocated,
so in order to avoid to allocate the kvec for each request, we are
not calling vringh_kiov_cleanup() when we finished to handle a
request, but we should call it when we free the entire device.
Signed-off-by: Stefano Garzarella
Acked-by: Jason Wang
---
drivers/vdpa/vdpa_sim/vdpa_sim.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/vdpa/vdpa_sim/vdpa_sim.c b/drivers/vdpa/vdpa_sim/vdpa_sim.c
index 53238989713d..a7aeb5d01c3e 100644
--- a/drivers/vdpa/vdpa_sim/vdpa_sim.c
+++ b/drivers/vdpa/vdpa_sim/vdpa_sim.c
@@ -562,8 +562,15 @@ static int vdpasim_dma_unmap(struct vdpa_device *vdpa, u64
iova, u64 size)
static void vdpasim_free(struct vdpa_device *vdpa)
{
struct vdpasim *vdpasim = vdpa_to_sim(vdpa);
+ int i;
cancel_work_sync(>work);
+
+ for (i = 0; i < vdpasim->dev_attr.nvqs; i++) {
+ vringh_kiov_cleanup(>vqs[i].out_iov);
+ vringh_kiov_cleanup(>vqs[i].in_iov);
+ }
+
put_iova_domain(>iova);
iova_cache_put();
kvfree(vdpasim->buffer);
[PATCH v10 0/2] UIO support for dfl devices
This patchset supports some dfl device drivers written in userspace. In the patchset v1, the "driver_override" interface should be used to bind the DFL UIO driver to DFL devices. But there is concern that the "driver_override" interface is not OK itself. In v2, we use a new matching algorithem. The "driver_override" interface is abandoned, the DFL UIO driver matches any DFL device which could not be handled by other DFL drivers. So the DFL UIO driver could be used for new DFL devices which are not supported by kernel. The concern is the UIO may not be suitable as a default/generic driver for all dfl features, such as features with multiple interrupts. In v4, we specify each matching device in the id_table of the UIO driver, just the same as other dfl drivers do. Now the UIO driver supports Ether Group feature. To support more DFL features, their feature ids should be added to the driver's id_table. Before v9, we create a "uio_pdrv_genirq" platform device using DFL devices' resources. Then we leverage the uio_pdrv_genirq driver for UIO support. It is suggested that we implement a driver in drivers/uio that directly calls UIO framework APIs. So we implement the uio_dfl driver in v9. The driver now only binds the ether group feature, which has no irq. So the irq support is not implemented yet. Main changes from v1: - switch to the new matching algorithem. It matches DFL devices which could not be handled by other DFL drivers. - refacor the code about device resources filling. - add the documentation. Main changes from v2: - split the match ops changes in dfl.c to an independent patch. - move the declarations needed for dfl-uio-pdev from include/linux/dfl.h to driver/fpga/dfl.h - some minor fixes. Main changes from v3: - switch to specifying each matching device in the driver's id_table. - refactor the irq handling code. Main changes from v4: - refactor the irq handling code. Main changes from v5: - fix the res[] zero initialization issue. - improve the return code for probe(). - some doc improvement. Main changes from v6: - use platform_device_register_resndata() for pdev creation. Main changes from v7: - some doc fixes. Main changes from v8: - switch to add a uio driver in drivers/uio Main changes from v9: - add this source file in MAINTAINERS - improve the Kconfig, add more descriptive Kconfig header, add detailed path for opae uio example in Kconfig. Xu Yilun (2): uio: uio_dfl: add userspace i/o driver for DFL bus Documentation: fpga: dfl: Add description for DFL UIO support Documentation/fpga/dfl.rst | 23 MAINTAINERS| 1 + drivers/uio/Kconfig| 17 drivers/uio/Makefile | 1 + drivers/uio/uio_dfl.c | 66 ++ 5 files changed, 108 insertions(+) create mode 100644 drivers/uio/uio_dfl.c -- 2.7.4
Re: [PATCH RFC v2 05/10] vringh: add vringh_kiov_length() helper
On 2021/1/28 下午10:41, Stefano Garzarella wrote:
This new helper returns the total number of bytes covered by
a vringh_kiov.
Suggested-by: Jason Wang
Signed-off-by: Stefano Garzarella
Acked-by: Jason Wang
---
include/linux/vringh.h | 11 +++
1 file changed, 11 insertions(+)
diff --git a/include/linux/vringh.h b/include/linux/vringh.h
index 755211ebd195..84db7b8f912f 100644
--- a/include/linux/vringh.h
+++ b/include/linux/vringh.h
@@ -199,6 +199,17 @@ static inline void vringh_kiov_cleanup(struct vringh_kiov
*kiov)
kiov->iov = NULL;
}
+static inline size_t vringh_kiov_length(struct vringh_kiov *kiov)
+{
+ size_t len = 0;
+ int i;
+
+ for (i = kiov->i; i < kiov->used; i++)
+ len += kiov->iov[i].iov_len;
+
+ return len;
+}
+
void vringh_kiov_advance(struct vringh_kiov *kiov, size_t len);
int vringh_getdesc_kern(struct vringh *vrh,
[Patch v3 net-next 5/7] octeontx2-af: advertised link modes support on cgx
From: Christina Jacob
CGX supports setting advertised link modes on physical link.
This patch adds support to derive cgx mode from ethtool
link mode and pass it to firmware to configure the same.
Signed-off-by: Christina Jacob
Signed-off-by: Sunil Goutham
Signed-off-by: Hariprasad Kelam
---
drivers/net/ethernet/marvell/octeontx2/af/cgx.c| 114 -
.../net/ethernet/marvell/octeontx2/af/cgx_fw_if.h | 32 +-
drivers/net/ethernet/marvell/octeontx2/af/mbox.h | 3 +-
3 files changed, 146 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/marvell/octeontx2/af/cgx.c
b/drivers/net/ethernet/marvell/octeontx2/af/cgx.c
index 5b7d858..9c62129 100644
--- a/drivers/net/ethernet/marvell/octeontx2/af/cgx.c
+++ b/drivers/net/ethernet/marvell/octeontx2/af/cgx.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -646,6 +647,7 @@ static inline void cgx_link_usertable_init(void)
cgx_speed_mbps[CGX_LINK_25G] = 25000;
cgx_speed_mbps[CGX_LINK_40G] = 4;
cgx_speed_mbps[CGX_LINK_50G] = 5;
+ cgx_speed_mbps[CGX_LINK_80G] = 8;
cgx_speed_mbps[CGX_LINK_100G] = 10;
cgx_lmactype_string[LMAC_MODE_SGMII] = "SGMII";
@@ -693,6 +695,110 @@ static int cgx_link_usertable_index_map(int speed)
return CGX_LINK_NONE;
}
+static void set_mod_args(struct cgx_set_link_mode_args *args,
+u32 speed, u8 duplex, u8 autoneg, u64 mode)
+{
+ /* Fill default values incase of user did not pass
+* valid parameters
+*/
+ if (args->duplex == DUPLEX_UNKNOWN)
+ args->duplex = duplex;
+ if (args->speed == SPEED_UNKNOWN)
+ args->speed = speed;
+ if (args->an == AUTONEG_UNKNOWN)
+ args->an = autoneg;
+ args->mode = mode;
+ args->ports = 0;
+}
+
+static void otx2_map_ethtool_link_modes(u64 bitmask,
+ struct cgx_set_link_mode_args *args)
+{
+ switch (bitmask) {
+ case ETHTOOL_LINK_MODE_10baseT_Half_BIT:
+ set_mod_args(args, 10, 1, 1, BIT_ULL(CGX_MODE_SGMII));
+ break;
+ case ETHTOOL_LINK_MODE_10baseT_Full_BIT:
+ set_mod_args(args, 10, 0, 1, BIT_ULL(CGX_MODE_SGMII));
+ break;
+ case ETHTOOL_LINK_MODE_100baseT_Half_BIT:
+ set_mod_args(args, 100, 1, 1, BIT_ULL(CGX_MODE_SGMII));
+ break;
+ case ETHTOOL_LINK_MODE_100baseT_Full_BIT:
+ set_mod_args(args, 100, 0, 1, BIT_ULL(CGX_MODE_SGMII));
+ break;
+ case ETHTOOL_LINK_MODE_1000baseT_Half_BIT:
+ set_mod_args(args, 1000, 1, 1, BIT_ULL(CGX_MODE_SGMII));
+ break;
+ case ETHTOOL_LINK_MODE_1000baseT_Full_BIT:
+ set_mod_args(args, 1000, 0, 1, BIT_ULL(CGX_MODE_SGMII));
+ break;
+ case ETHTOOL_LINK_MODE_1000baseX_Full_BIT:
+ set_mod_args(args, 1000, 0, 0, BIT_ULL(CGX_MODE_1000_BASEX));
+ break;
+ case ETHTOOL_LINK_MODE_1baseT_Full_BIT:
+ set_mod_args(args, 1000, 0, 1, BIT_ULL(CGX_MODE_QSGMII));
+ break;
+ case ETHTOOL_LINK_MODE_1baseSR_Full_BIT:
+ set_mod_args(args, 1, 0, 0, BIT_ULL(CGX_MODE_10G_C2C));
+ break;
+ case ETHTOOL_LINK_MODE_1baseLR_Full_BIT:
+ set_mod_args(args, 1, 0, 0, BIT_ULL(CGX_MODE_10G_C2M));
+ break;
+ case ETHTOOL_LINK_MODE_1baseKR_Full_BIT:
+ set_mod_args(args, 1, 0, 1, BIT_ULL(CGX_MODE_10G_KR));
+ break;
+ case ETHTOOL_LINK_MODE_25000baseSR_Full_BIT:
+ set_mod_args(args, 25000, 0, 0, BIT_ULL(CGX_MODE_25G_C2C));
+ break;
+ case ETHTOOL_LINK_MODE_25000baseCR_Full_BIT:
+ set_mod_args(args, 25000, 0, 1, BIT_ULL(CGX_MODE_25G_CR));
+ break;
+ case ETHTOOL_LINK_MODE_25000baseKR_Full_BIT:
+ set_mod_args(args, 25000, 0, 1, BIT_ULL(CGX_MODE_25G_KR));
+ break;
+ case ETHTOOL_LINK_MODE_4baseSR4_Full_BIT:
+ set_mod_args(args, 4, 0, 0, BIT_ULL(CGX_MODE_40G_C2C));
+ break;
+ case ETHTOOL_LINK_MODE_4baseLR4_Full_BIT:
+ set_mod_args(args, 4, 0, 0, BIT_ULL(CGX_MODE_40G_C2M));
+ break;
+ case ETHTOOL_LINK_MODE_4baseCR4_Full_BIT:
+ set_mod_args(args, 4, 0, 1, BIT_ULL(CGX_MODE_40G_CR4));
+ break;
+ case ETHTOOL_LINK_MODE_4baseKR4_Full_BIT:
+ set_mod_args(args, 4, 0, 1, BIT_ULL(CGX_MODE_40G_KR4));
+ break;
+ case ETHTOOL_LINK_MODE_5baseSR_Full_BIT:
+ set_mod_args(args, 5, 0, 0, BIT_ULL(CGX_MODE_50G_C2C));
+ break;
+ case ETHTOOL_LINK_MODE_5baseLR_ER_FR_Full_BIT:
+
Re: [PATCH RFC v2 03/10] vringh: reset kiov 'consumed' field in __vringh_iov()
On 2021/1/28 下午10:41, Stefano Garzarella wrote:
__vringh_iov() overwrites the contents of riov and wiov, in fact it
resets the 'i' and 'used' fields, but also the consumed field should
be reset to avoid an inconsistent state.
Signed-off-by: Stefano Garzarella
I had a question(I remember we had some discussion like this but I
forget the conclusion):
I see e.g in vringh_getdesc_kern() it has the following comment:
/*
* Note that you may need to clean up riov and wiov, even on error!
*/
So it looks to me the correct way is to call vringh_kiov_cleanup() before?
Thanks
---
drivers/vhost/vringh.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/vhost/vringh.c b/drivers/vhost/vringh.c
index f68122705719..bee63d68201a 100644
--- a/drivers/vhost/vringh.c
+++ b/drivers/vhost/vringh.c
@@ -290,9 +290,9 @@ __vringh_iov(struct vringh *vrh, u16 i,
return -EINVAL;
if (riov)
- riov->i = riov->used = 0;
+ riov->i = riov->used = riov->consumed = 0;
if (wiov)
- wiov->i = wiov->used = 0;
+ wiov->i = wiov->used = wiov->consumed = 0;
for (;;) {
void *addr;
[Patch v3 net-next 4/7] octeontx2-af: Physical link configuration support
From: Christina Jacob
CGX LMAC, the physical interface support link configuration parameters
like speed, auto negotiation, duplex etc. Firmware saves these into
memory region shared between firmware and this driver.
This patch adds mailbox handler set_link_mode, fw_data_get to
configure and read these parameters.
Signed-off-by: Christina Jacob
Signed-off-by: Sunil Goutham
Signed-off-by: Hariprasad Kelam
---
drivers/net/ethernet/marvell/octeontx2/af/cgx.c| 58 +-
drivers/net/ethernet/marvell/octeontx2/af/cgx.h| 2 +
.../net/ethernet/marvell/octeontx2/af/cgx_fw_if.h | 18 ++-
drivers/net/ethernet/marvell/octeontx2/af/mbox.h | 21
.../net/ethernet/marvell/octeontx2/af/rvu_cgx.c| 17 +++
5 files changed, 113 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/marvell/octeontx2/af/cgx.c
b/drivers/net/ethernet/marvell/octeontx2/af/cgx.c
index b636341..5b7d858 100644
--- a/drivers/net/ethernet/marvell/octeontx2/af/cgx.c
+++ b/drivers/net/ethernet/marvell/octeontx2/af/cgx.c
@@ -660,6 +660,39 @@ static inline void cgx_link_usertable_init(void)
cgx_lmactype_string[LMAC_MODE_USXGMII] = "USXGMII";
}
+static int cgx_link_usertable_index_map(int speed)
+{
+ switch (speed) {
+ case SPEED_10:
+ return CGX_LINK_10M;
+ case SPEED_100:
+ return CGX_LINK_100M;
+ case SPEED_1000:
+ return CGX_LINK_1G;
+ case SPEED_2500:
+ return CGX_LINK_2HG;
+ case SPEED_5000:
+ return CGX_LINK_5G;
+ case SPEED_1:
+ return CGX_LINK_10G;
+ case SPEED_2:
+ return CGX_LINK_20G;
+ case SPEED_25000:
+ return CGX_LINK_25G;
+ case SPEED_4:
+ return CGX_LINK_40G;
+ case SPEED_5:
+ return CGX_LINK_50G;
+ case 8:
+ return CGX_LINK_80G;
+ case SPEED_10:
+ return CGX_LINK_100G;
+ case SPEED_UNKNOWN:
+ return CGX_LINK_NONE;
+ }
+ return CGX_LINK_NONE;
+}
+
static inline void link_status_user_format(u64 lstat,
struct cgx_link_user_info *linfo,
struct cgx *cgx, u8 lmac_id)
@@ -669,6 +702,7 @@ static inline void link_status_user_format(u64 lstat,
linfo->link_up = FIELD_GET(RESP_LINKSTAT_UP, lstat);
linfo->full_duplex = FIELD_GET(RESP_LINKSTAT_FDUPLEX, lstat);
linfo->speed = cgx_speed_mbps[FIELD_GET(RESP_LINKSTAT_SPEED, lstat)];
+ linfo->an = FIELD_GET(RESP_LINKSTAT_AN, lstat);
linfo->fec = FIELD_GET(RESP_LINKSTAT_FEC, lstat);
linfo->lmac_type_id = cgx_get_lmac_type(cgx, lmac_id);
lmac_string = cgx_lmactype_string[linfo->lmac_type_id];
@@ -697,6 +731,9 @@ static inline void cgx_link_change_handler(u64 lstat,
lmac->link_info = event.link_uinfo;
linfo = >link_info;
+ if (err_type == CGX_ERR_SPEED_CHANGE_INVALID)
+ return;
+
/* Ensure callback doesn't get unregistered until we finish it */
spin_lock(>event_cb_lock);
@@ -725,7 +762,8 @@ static inline bool cgx_cmdresp_is_linkevent(u64 event)
id = FIELD_GET(EVTREG_ID, event);
if (id == CGX_CMD_LINK_BRING_UP ||
- id == CGX_CMD_LINK_BRING_DOWN)
+ id == CGX_CMD_LINK_BRING_DOWN ||
+ id == CGX_CMD_MODE_CHANGE)
return true;
else
return false;
@@ -840,6 +878,24 @@ int cgx_get_fwdata_base(u64 *base)
return err;
}
+int cgx_set_link_mode(void *cgxd, struct cgx_set_link_mode_args args,
+ int cgx_id, int lmac_id)
+{
+ struct cgx *cgx = cgxd;
+ u64 req = 0, resp;
+
+ if (!cgx)
+ return -ENODEV;
+
+ req = FIELD_SET(CMDREG_ID, CGX_CMD_MODE_CHANGE, req);
+ req = FIELD_SET(CMDMODECHANGE_SPEED,
+ cgx_link_usertable_index_map(args.speed), req);
+ req = FIELD_SET(CMDMODECHANGE_DUPLEX, args.duplex, req);
+ req = FIELD_SET(CMDMODECHANGE_AN, args.an, req);
+ req = FIELD_SET(CMDMODECHANGE_PORT, args.ports, req);
+ req = FIELD_SET(CMDMODECHANGE_FLAGS, args.flags, req);
+ return cgx_fwi_cmd_generic(req, , cgx, lmac_id);
+}
int cgx_set_fec(u64 fec, int cgx_id, int lmac_id)
{
u64 req = 0, resp;
diff --git a/drivers/net/ethernet/marvell/octeontx2/af/cgx.h
b/drivers/net/ethernet/marvell/octeontx2/af/cgx.h
index c5294b7..b458ad0 100644
--- a/drivers/net/ethernet/marvell/octeontx2/af/cgx.h
+++ b/drivers/net/ethernet/marvell/octeontx2/af/cgx.h
@@ -155,5 +155,7 @@ u8 cgx_lmac_get_p2x(int cgx_id, int lmac_id);
int cgx_set_fec(u64 fec, int cgx_id, int lmac_id);
int cgx_get_fec_stats(void *cgxd, int lmac_id, struct cgx_fec_stats_rsp *rsp);
int cgx_get_phy_fec_stats(void *cgxd, int lmac_id);
+int cgx_set_link_mode(void *cgxd, struct
[PATCH v14 11/11] selftests: kvm/x86: add test for pmu msr MSR_IA32_PERF_CAPABILITIES
This test will check the effect of various CPUID settings on the
MSR_IA32_PERF_CAPABILITIES MSR, check that whatever user space writes
with KVM_SET_MSR is _not_ modified from the guest and can be retrieved
with KVM_GET_MSR, and check that invalid LBR formats are rejected.
Signed-off-by: Like Xu
---
tools/testing/selftests/kvm/.gitignore| 1 +
tools/testing/selftests/kvm/Makefile | 1 +
.../selftests/kvm/x86_64/vmx_pmu_msrs_test.c | 149 ++
3 files changed, 151 insertions(+)
create mode 100644 tools/testing/selftests/kvm/x86_64/vmx_pmu_msrs_test.c
diff --git a/tools/testing/selftests/kvm/.gitignore
b/tools/testing/selftests/kvm/.gitignore
index ce8f4ad39684..28b71efe52a0 100644
--- a/tools/testing/selftests/kvm/.gitignore
+++ b/tools/testing/selftests/kvm/.gitignore
@@ -25,6 +25,7 @@
/x86_64/vmx_set_nested_state_test
/x86_64/vmx_tsc_adjust_test
/x86_64/xss_msr_test
+/x86_64/vmx_pmu_msrs_test
/demand_paging_test
/dirty_log_test
/dirty_log_perf_test
diff --git a/tools/testing/selftests/kvm/Makefile
b/tools/testing/selftests/kvm/Makefile
index fe41c6a0fa67..cf8737828dd4 100644
--- a/tools/testing/selftests/kvm/Makefile
+++ b/tools/testing/selftests/kvm/Makefile
@@ -59,6 +59,7 @@ TEST_GEN_PROGS_x86_64 += x86_64/vmx_tsc_adjust_test
TEST_GEN_PROGS_x86_64 += x86_64/xss_msr_test
TEST_GEN_PROGS_x86_64 += x86_64/debug_regs
TEST_GEN_PROGS_x86_64 += x86_64/tsc_msrs_test
+TEST_GEN_PROGS_x86_64 += x86_64/vmx_pmu_msrs_test
TEST_GEN_PROGS_x86_64 += demand_paging_test
TEST_GEN_PROGS_x86_64 += dirty_log_test
TEST_GEN_PROGS_x86_64 += dirty_log_perf_test
diff --git a/tools/testing/selftests/kvm/x86_64/vmx_pmu_msrs_test.c
b/tools/testing/selftests/kvm/x86_64/vmx_pmu_msrs_test.c
new file mode 100644
index ..b3ad63e6ff12
--- /dev/null
+++ b/tools/testing/selftests/kvm/x86_64/vmx_pmu_msrs_test.c
@@ -0,0 +1,149 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * VMX-pmu related msrs test
+ *
+ * Copyright (C) 2021 Intel Corporation
+ *
+ * Test to check the effect of various CPUID settings
+ * on the MSR_IA32_PERF_CAPABILITIES MSR, and check that
+ * whatever we write with KVM_SET_MSR is _not_ modified
+ * in the guest and test it can be retrieved with KVM_GET_MSR.
+ *
+ * Test to check that invalid LBR formats are rejected.
+ */
+
+#define _GNU_SOURCE /* for program_invocation_short_name */
+#include
+
+#include "kvm_util.h"
+#include "vmx.h"
+
+#define VCPU_ID 0
+
+#define X86_FEATURE_PDCM (1<<15)
+#define PMU_CAP_FW_WRITES (1ULL << 13)
+#define PMU_CAP_LBR_FMT0x3f
+
+union cpuid10_eax {
+ struct {
+ unsigned int version_id:8;
+ unsigned int num_counters:8;
+ unsigned int bit_width:8;
+ unsigned int mask_length:8;
+ } split;
+ unsigned int full;
+};
+
+union perf_capabilities {
+ struct {
+ u64 lbr_format:6;
+ u64 pebs_trap:1;
+ u64 pebs_arch_reg:1;
+ u64 pebs_format:4;
+ u64 smm_freeze:1;
+ u64 full_width_write:1;
+ u64 pebs_baseline:1;
+ u64 perf_metrics:1;
+ u64 pebs_output_pt_available:1;
+ u64 anythread_deprecated:1;
+ };
+ u64 capabilities;
+};
+
+uint64_t rdmsr_on_cpu(uint32_t reg)
+{
+ uint64_t data;
+ int fd;
+ char msr_file[64];
+
+ sprintf(msr_file, "/dev/cpu/%d/msr", 0);
+ fd = open(msr_file, O_RDONLY);
+ if (fd < 0)
+ exit(KSFT_SKIP);
+
+ if (pread(fd, , sizeof(data), reg) != sizeof(data))
+ exit(KSFT_SKIP);
+
+ close(fd);
+ return data;
+}
+
+static void guest_code(void)
+{
+ wrmsr(MSR_IA32_PERF_CAPABILITIES, PMU_CAP_LBR_FMT);
+}
+
+int main(int argc, char *argv[])
+{
+ struct kvm_cpuid2 *cpuid;
+ struct kvm_cpuid_entry2 *entry_1_0;
+ struct kvm_cpuid_entry2 *entry_a_0;
+ bool pdcm_supported = false;
+ struct kvm_vm *vm;
+ int ret;
+ union cpuid10_eax eax;
+ union perf_capabilities host_cap;
+
+ host_cap.capabilities = rdmsr_on_cpu(MSR_IA32_PERF_CAPABILITIES);
+ host_cap.capabilities &= (PMU_CAP_FW_WRITES | PMU_CAP_LBR_FMT);
+
+ /* Create VM */
+ vm = vm_create_default(VCPU_ID, 0, guest_code);
+ cpuid = kvm_get_supported_cpuid();
+
+ if (kvm_get_cpuid_max_basic() >= 0xa) {
+ entry_1_0 = kvm_get_supported_cpuid_index(1, 0);
+ entry_a_0 = kvm_get_supported_cpuid_index(0xa, 0);
+ pdcm_supported = entry_1_0 && !!(entry_1_0->ecx &
X86_FEATURE_PDCM);
+ eax.full = entry_a_0->eax;
+ }
+ if (!pdcm_supported) {
+ print_skip("MSR_IA32_PERF_CAPABILITIES is not supported by the
vCPU");
+ exit(KSFT_SKIP);
+ }
+ if (!eax.split.version_id) {
+ print_skip("PMU is not
[Patch v3 net-next 0/7] ethtool support for fec and link configuration
This series of patches add support for forward error correction(fec) and physical link configuration. Patches 1&2 adds necessary mbox handlers for fec mode configuration request and to fetch stats. Patch 3 registers driver callbacks for fec mode configuration and display. Patch 4&5 adds support of mbox handlers for configuring link parameters like speed/duplex and autoneg etc. Patche 6&7 registers driver callbacks for physical link configuration. Change-log: v2: - Fixed review comments - Corrected indentation issues - Return -ENOMEM incase of mbox allocation failure - added validation for input fecparams bitmask values - added more comments V3: - Removed inline functions - Make use of ethtool helpers APIs to display supported advertised modes - corrected indentation issues - code changes such that return early in case of failure to aid branch prediction Christina Jacob (6): octeontx2-af: forward error correction configuration octeontx2-pf: ethtool fec mode support octeontx2-af: Physical link configuration support octeontx2-af: advertised link modes support on cgx octeontx2-pf: ethtool physical link status octeontx2-pf: ethtool physical link configuration Felix Manlunas (1): octeontx2-af: Add new CGX_CMD to get PHY FEC statistics drivers/net/ethernet/marvell/octeontx2/af/cgx.c| 258 - drivers/net/ethernet/marvell/octeontx2/af/cgx.h| 10 + .../net/ethernet/marvell/octeontx2/af/cgx_fw_if.h | 70 +++- drivers/net/ethernet/marvell/octeontx2/af/mbox.h | 87 - drivers/net/ethernet/marvell/octeontx2/af/rvu.h| 4 + .../net/ethernet/marvell/octeontx2/af/rvu_cgx.c| 80 + .../ethernet/marvell/octeontx2/nic/otx2_common.c | 20 ++ .../ethernet/marvell/octeontx2/nic/otx2_common.h | 6 + .../ethernet/marvell/octeontx2/nic/otx2_ethtool.c | 399 - .../net/ethernet/marvell/octeontx2/nic/otx2_pf.c | 3 + 10 files changed, 930 insertions(+), 7 deletions(-) -- 2.7.4
[Patch v3 net-next 1/7] octeontx2-af: forward error correction configuration
From: Christina Jacob
CGX block supports forward error correction modes baseR
and RS. This patch adds support to set encoding mode
and to read corrected/uncorrected block counters
Adds new mailbox handlers set_fec to configure encoding modes
and fec_stats to read counters and also increase mbox timeout
to accomdate firmware command response timeout.
Along with new CGX_CMD_SET_FEC command add other commands to
sync with kernel enum list with firmware.
Signed-off-by: Christina Jacob
Signed-off-by: Sunil Goutham
Signed-off-by: Hariprasad Kelam
---
drivers/net/ethernet/marvell/octeontx2/af/cgx.c| 76 ++
drivers/net/ethernet/marvell/octeontx2/af/cgx.h| 7 ++
.../net/ethernet/marvell/octeontx2/af/cgx_fw_if.h | 17 -
drivers/net/ethernet/marvell/octeontx2/af/mbox.h | 22 ++-
.../net/ethernet/marvell/octeontx2/af/rvu_cgx.c| 31 +
5 files changed, 151 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/marvell/octeontx2/af/cgx.c
b/drivers/net/ethernet/marvell/octeontx2/af/cgx.c
index 84a9123..fe5512d 100644
--- a/drivers/net/ethernet/marvell/octeontx2/af/cgx.c
+++ b/drivers/net/ethernet/marvell/octeontx2/af/cgx.c
@@ -340,6 +340,60 @@ int cgx_get_tx_stats(void *cgxd, int lmac_id, int idx, u64
*tx_stat)
return 0;
}
+static int cgx_set_fec_stats_count(struct cgx_link_user_info *linfo)
+{
+ if (!linfo->fec)
+ return 0;
+
+ switch (linfo->lmac_type_id) {
+ case LMAC_MODE_SGMII:
+ case LMAC_MODE_XAUI:
+ case LMAC_MODE_RXAUI:
+ case LMAC_MODE_QSGMII:
+ return 0;
+ case LMAC_MODE_10G_R:
+ case LMAC_MODE_25G_R:
+ case LMAC_MODE_100G_R:
+ case LMAC_MODE_USXGMII:
+ return 1;
+ case LMAC_MODE_40G_R:
+ return 4;
+ case LMAC_MODE_50G_R:
+ if (linfo->fec == OTX2_FEC_BASER)
+ return 2;
+ else
+ return 1;
+ default:
+ return 0;
+ }
+}
+
+int cgx_get_fec_stats(void *cgxd, int lmac_id, struct cgx_fec_stats_rsp *rsp)
+{
+ int stats, fec_stats_count = 0;
+ int corr_reg, uncorr_reg;
+ struct cgx *cgx = cgxd;
+
+ if (!cgx || lmac_id >= cgx->lmac_count)
+ return -ENODEV;
+ fec_stats_count =
+ cgx_set_fec_stats_count(>lmac_idmap[lmac_id]->link_info);
+ if (cgx->lmac_idmap[lmac_id]->link_info.fec == OTX2_FEC_BASER) {
+ corr_reg = CGXX_SPUX_LNX_FEC_CORR_BLOCKS;
+ uncorr_reg = CGXX_SPUX_LNX_FEC_UNCORR_BLOCKS;
+ } else {
+ corr_reg = CGXX_SPUX_RSFEC_CORR;
+ uncorr_reg = CGXX_SPUX_RSFEC_UNCORR;
+ }
+ for (stats = 0; stats < fec_stats_count; stats++) {
+ rsp->fec_corr_blks +=
+ cgx_read(cgx, lmac_id, corr_reg + (stats * 8));
+ rsp->fec_uncorr_blks +=
+ cgx_read(cgx, lmac_id, uncorr_reg + (stats * 8));
+ }
+ return 0;
+}
+
int cgx_lmac_rx_tx_enable(void *cgxd, int lmac_id, bool enable)
{
struct cgx *cgx = cgxd;
@@ -615,6 +669,7 @@ static inline void link_status_user_format(u64 lstat,
linfo->link_up = FIELD_GET(RESP_LINKSTAT_UP, lstat);
linfo->full_duplex = FIELD_GET(RESP_LINKSTAT_FDUPLEX, lstat);
linfo->speed = cgx_speed_mbps[FIELD_GET(RESP_LINKSTAT_SPEED, lstat)];
+ linfo->fec = FIELD_GET(RESP_LINKSTAT_FEC, lstat);
linfo->lmac_type_id = cgx_get_lmac_type(cgx, lmac_id);
lmac_string = cgx_lmactype_string[linfo->lmac_type_id];
strncpy(linfo->lmac_type, lmac_string, LMACTYPE_STR_LEN - 1);
@@ -785,6 +840,27 @@ int cgx_get_fwdata_base(u64 *base)
return err;
}
+int cgx_set_fec(u64 fec, int cgx_id, int lmac_id)
+{
+ u64 req = 0, resp;
+ struct cgx *cgx;
+ int err = 0;
+
+ cgx = cgx_get_pdata(cgx_id);
+ if (!cgx)
+ return -ENXIO;
+
+ req = FIELD_SET(CMDREG_ID, CGX_CMD_SET_FEC, req);
+ req = FIELD_SET(CMDSETFEC, fec, req);
+ err = cgx_fwi_cmd_generic(req, , cgx, lmac_id);
+ if (err)
+ return err;
+
+ cgx->lmac_idmap[lmac_id]->link_info.fec =
+ FIELD_GET(RESP_LINKSTAT_FEC, resp);
+ return cgx->lmac_idmap[lmac_id]->link_info.fec;
+}
+
static int cgx_fwi_link_change(struct cgx *cgx, int lmac_id, bool enable)
{
u64 req = 0;
diff --git a/drivers/net/ethernet/marvell/octeontx2/af/cgx.h
b/drivers/net/ethernet/marvell/octeontx2/af/cgx.h
index bcfc3e5..1824e95 100644
--- a/drivers/net/ethernet/marvell/octeontx2/af/cgx.h
+++ b/drivers/net/ethernet/marvell/octeontx2/af/cgx.h
@@ -56,6 +56,11 @@
#define CGXX_SCRATCH1_REG 0x1058
#define CGX_CONST 0x2000
#define CGXX_SPUX_CONTROL1 0x1
+#define CGXX_SPUX_LNX_FEC_CORR_BLOCKS 0x10700
+#define CGXX_SPUX_LNX_FEC_UNCORR_BLOCKS0x10800
[Patch v3 net-next 2/7] octeontx2-af: Add new CGX_CMD to get PHY FEC statistics
From: Felix Manlunas
This patch adds support to fetch fec stats from PHY. The stats are
put in the shared data struct fwdata. A PHY driver indicates
that it has FEC stats by setting the flag fwdata.phy.misc.has_fec_stats
Besides CGX_CMD_GET_PHY_FEC_STATS, also add CGX_CMD_PRBS and
CGX_CMD_DISPLAY_EYE to enum cgx_cmd_id so that Linux's enum list is in sync
with firmware's enum list.
Signed-off-by: Felix Manlunas
Signed-off-by: Christina Jacob
Signed-off-by: Sunil Kovvuri Goutham
Signed-off-by: Hariprasad Kelam
---
drivers/net/ethernet/marvell/octeontx2/af/cgx.c| 12 ++
drivers/net/ethernet/marvell/octeontx2/af/cgx.h| 1 +
.../net/ethernet/marvell/octeontx2/af/cgx_fw_if.h | 5 +++
drivers/net/ethernet/marvell/octeontx2/af/mbox.h | 43 ++
drivers/net/ethernet/marvell/octeontx2/af/rvu.h| 4 ++
.../net/ethernet/marvell/octeontx2/af/rvu_cgx.c| 32
6 files changed, 97 insertions(+)
diff --git a/drivers/net/ethernet/marvell/octeontx2/af/cgx.c
b/drivers/net/ethernet/marvell/octeontx2/af/cgx.c
index fe5512d..b636341 100644
--- a/drivers/net/ethernet/marvell/octeontx2/af/cgx.c
+++ b/drivers/net/ethernet/marvell/octeontx2/af/cgx.c
@@ -861,6 +861,18 @@ int cgx_set_fec(u64 fec, int cgx_id, int lmac_id)
return cgx->lmac_idmap[lmac_id]->link_info.fec;
}
+int cgx_get_phy_fec_stats(void *cgxd, int lmac_id)
+{
+ struct cgx *cgx = cgxd;
+ u64 req = 0, resp;
+
+ if (!cgx)
+ return -ENODEV;
+
+ req = FIELD_SET(CMDREG_ID, CGX_CMD_GET_PHY_FEC_STATS, req);
+ return cgx_fwi_cmd_generic(req, , cgx, lmac_id);
+}
+
static int cgx_fwi_link_change(struct cgx *cgx, int lmac_id, bool enable)
{
u64 req = 0;
diff --git a/drivers/net/ethernet/marvell/octeontx2/af/cgx.h
b/drivers/net/ethernet/marvell/octeontx2/af/cgx.h
index 1824e95..c5294b7 100644
--- a/drivers/net/ethernet/marvell/octeontx2/af/cgx.h
+++ b/drivers/net/ethernet/marvell/octeontx2/af/cgx.h
@@ -154,5 +154,6 @@ void cgx_lmac_ptp_config(void *cgxd, int lmac_id, bool
enable);
u8 cgx_lmac_get_p2x(int cgx_id, int lmac_id);
int cgx_set_fec(u64 fec, int cgx_id, int lmac_id);
int cgx_get_fec_stats(void *cgxd, int lmac_id, struct cgx_fec_stats_rsp *rsp);
+int cgx_get_phy_fec_stats(void *cgxd, int lmac_id);
#endif /* CGX_H */
diff --git a/drivers/net/ethernet/marvell/octeontx2/af/cgx_fw_if.h
b/drivers/net/ethernet/marvell/octeontx2/af/cgx_fw_if.h
index 3485596..65f832a 100644
--- a/drivers/net/ethernet/marvell/octeontx2/af/cgx_fw_if.h
+++ b/drivers/net/ethernet/marvell/octeontx2/af/cgx_fw_if.h
@@ -89,6 +89,11 @@ enum cgx_cmd_id {
CGX_CMD_SET_AN,
CGX_CMD_GET_ADV_LINK_MODES,
CGX_CMD_GET_ADV_FEC,
+ CGX_CMD_GET_PHY_MOD_TYPE, /* line-side modulation type: NRZ or PAM4 */
+ CGX_CMD_SET_PHY_MOD_TYPE,
+ CGX_CMD_PRBS,
+ CGX_CMD_DISPLAY_EYE,
+ CGX_CMD_GET_PHY_FEC_STATS,
};
/* async event ids */
diff --git a/drivers/net/ethernet/marvell/octeontx2/af/mbox.h
b/drivers/net/ethernet/marvell/octeontx2/af/mbox.h
index a59a355..204040e 100644
--- a/drivers/net/ethernet/marvell/octeontx2/af/mbox.h
+++ b/drivers/net/ethernet/marvell/octeontx2/af/mbox.h
@@ -151,6 +151,8 @@ M(CGX_CFG_PAUSE_FRM,0x20E, cgx_cfg_pause_frm,
cgx_pause_frm_cfg,\
cgx_pause_frm_cfg) \
M(CGX_FEC_SET, 0x210, cgx_set_fec_param, fec_mode, fec_mode) \
M(CGX_FEC_STATS, 0x211, cgx_fec_stats, msg_req, cgx_fec_stats_rsp) \
+M(CGX_GET_PHY_FEC_STATS, 0x212, cgx_get_phy_fec_stats, msg_req, msg_rsp) \
+M(CGX_FW_DATA_GET, 0x213, cgx_get_aux_link_info, msg_req, cgx_fw_data) \
/* NPA mbox IDs (range 0x400 - 0x5FF) */ \
/* NPA mbox IDs (range 0x400 - 0x5FF) */ \
M(NPA_LF_ALLOC,0x400, npa_lf_alloc,
\
@@ -411,6 +413,47 @@ struct fec_mode {
int fec;
};
+struct sfp_eeprom_s {
+#define SFP_EEPROM_SIZE 256
+ u16 sff_id;
+ u8 buf[SFP_EEPROM_SIZE];
+ u64 reserved;
+};
+
+struct phy_s {
+ struct {
+ u64 can_change_mod_type:1;
+ u64 mod_type:1;
+ u64 has_fec_stats:1;
+ } misc;
+ struct fec_stats_s {
+ u32 rsfec_corr_cws;
+ u32 rsfec_uncorr_cws;
+ u32 brfec_corr_blks;
+ u32 brfec_uncorr_blks;
+ } fec_stats;
+};
+
+struct cgx_lmac_fwdata_s {
+ u16 rw_valid;
+ u64 supported_fec;
+ u64 supported_an;
+ u64 supported_link_modes;
+ /* only applicable if AN is supported */
+ u64 advertised_fec;
+ u64 advertised_link_modes;
+ /* Only applicable if SFP/QSFP slot is present */
+ struct sfp_eeprom_s sfp_eeprom;
+ struct phy_s phy;
+#define LMAC_FWDATA_RESERVED_MEM 1021
+ u64 reserved[LMAC_FWDATA_RESERVED_MEM];
+};
+
+struct cgx_fw_data {
+ struct mbox_msghdr
[PATCH v14 10/11] KVM: vmx/pmu: Expose LBR_FMT in the MSR_IA32_PERF_CAPABILITIES
Userspace could enable guest LBR feature when the exactly supported
LBR format value is initialized to the MSR_IA32_PERF_CAPABILITIES
and the LBR is also compatible with vPMU version and host cpu model.
The LBR could be enabled on the guest if host perf supports LBR
(checked via x86_perf_get_lbr()) and the vcpu model is compatible
with the host one.
Signed-off-by: Like Xu
---
arch/x86/kvm/vmx/capabilities.h | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kvm/vmx/capabilities.h b/arch/x86/kvm/vmx/capabilities.h
index 57b940c613ab..c49f3ee8eca8 100644
--- a/arch/x86/kvm/vmx/capabilities.h
+++ b/arch/x86/kvm/vmx/capabilities.h
@@ -374,11 +374,18 @@ static inline bool vmx_pt_mode_is_host_guest(void)
static inline u64 vmx_get_perf_capabilities(void)
{
+ u64 perf_cap;
+
+ if (boot_cpu_has(X86_FEATURE_PDCM))
+ rdmsrl(MSR_IA32_PERF_CAPABILITIES, perf_cap);
+
+ perf_cap &= PMU_CAP_LBR_FMT;
+
/*
* Since counters are virtualized, KVM would support full
* width counting unconditionally, even if the host lacks it.
*/
- return PMU_CAP_FW_WRITES;
+ return PMU_CAP_FW_WRITES | perf_cap;
}
static inline u64 vmx_supported_debugctl(void)
--
2.29.2
[PATCH v14 08/11] KVM: vmx/pmu: Emulate legacy freezing LBRs on virtual PMI
The current vPMU only supports Architecture Version 2. According to
Intel SDM "17.4.7 Freezing LBR and Performance Counters on PMI", if
IA32_DEBUGCTL.Freeze_LBR_On_PMI = 1, the LBR is frozen on the virtual
PMI and the KVM would emulate to clear the LBR bit (bit 0) in
IA32_DEBUGCTL. Also, guest needs to re-enable IA32_DEBUGCTL.LBR
to resume recording branches.
Signed-off-by: Like Xu
Reviewed-by: Andi Kleen
---
arch/x86/kvm/pmu.c | 5 -
arch/x86/kvm/pmu.h | 1 +
arch/x86/kvm/vmx/capabilities.h | 4 +++-
arch/x86/kvm/vmx/pmu_intel.c| 30 ++
arch/x86/kvm/vmx/vmx.c | 2 +-
5 files changed, 39 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kvm/pmu.c b/arch/x86/kvm/pmu.c
index 67741d2a0308..405890c723a1 100644
--- a/arch/x86/kvm/pmu.c
+++ b/arch/x86/kvm/pmu.c
@@ -383,8 +383,11 @@ int kvm_pmu_rdpmc(struct kvm_vcpu *vcpu, unsigned idx, u64
*data)
void kvm_pmu_deliver_pmi(struct kvm_vcpu *vcpu)
{
- if (lapic_in_kernel(vcpu))
+ if (lapic_in_kernel(vcpu)) {
+ if (kvm_x86_ops.pmu_ops->deliver_pmi)
+ kvm_x86_ops.pmu_ops->deliver_pmi(vcpu);
kvm_apic_local_deliver(vcpu->arch.apic, APIC_LVTPC);
+ }
}
bool kvm_pmu_is_valid_msr(struct kvm_vcpu *vcpu, u32 msr)
diff --git a/arch/x86/kvm/pmu.h b/arch/x86/kvm/pmu.h
index 067fef51760c..742a4e98df8c 100644
--- a/arch/x86/kvm/pmu.h
+++ b/arch/x86/kvm/pmu.h
@@ -39,6 +39,7 @@ struct kvm_pmu_ops {
void (*refresh)(struct kvm_vcpu *vcpu);
void (*init)(struct kvm_vcpu *vcpu);
void (*reset)(struct kvm_vcpu *vcpu);
+ void (*deliver_pmi)(struct kvm_vcpu *vcpu);
};
static inline u64 pmc_bitmask(struct kvm_pmc *pmc)
diff --git a/arch/x86/kvm/vmx/capabilities.h b/arch/x86/kvm/vmx/capabilities.h
index 62aa7a701ebb..57b940c613ab 100644
--- a/arch/x86/kvm/vmx/capabilities.h
+++ b/arch/x86/kvm/vmx/capabilities.h
@@ -21,6 +21,8 @@ extern int __read_mostly pt_mode;
#define PMU_CAP_FW_WRITES (1ULL << 13)
#define PMU_CAP_LBR_FMT0x3f
+#define DEBUGCTLMSR_LBR_MASK (DEBUGCTLMSR_LBR |
DEBUGCTLMSR_FREEZE_LBRS_ON_PMI)
+
struct nested_vmx_msrs {
/*
* We only store the "true" versions of the VMX capability MSRs. We
@@ -384,7 +386,7 @@ static inline u64 vmx_supported_debugctl(void)
u64 debugctl = DEBUGCTLMSR_BTF;
if (vmx_get_perf_capabilities() & PMU_CAP_LBR_FMT)
- debugctl |= DEBUGCTLMSR_LBR;
+ debugctl |= DEBUGCTLMSR_LBR_MASK;
return debugctl;
}
diff --git a/arch/x86/kvm/vmx/pmu_intel.c b/arch/x86/kvm/vmx/pmu_intel.c
index 60f395e18446..51edd9c1adfa 100644
--- a/arch/x86/kvm/vmx/pmu_intel.c
+++ b/arch/x86/kvm/vmx/pmu_intel.c
@@ -579,6 +579,35 @@ static void intel_pmu_reset(struct kvm_vcpu *vcpu)
intel_pmu_release_guest_lbr_event(vcpu);
}
+/*
+ * Emulate LBR_On_PMI behavior for 1 < pmu.version < 4.
+ *
+ * If Freeze_LBR_On_PMI = 1, the LBR is frozen on PMI and
+ * the KVM emulates to clear the LBR bit (bit 0) in IA32_DEBUGCTL.
+ *
+ * Guest needs to re-enable LBR to resume branches recording.
+ */
+static void intel_pmu_legacy_freezing_lbrs_on_pmi(struct kvm_vcpu *vcpu)
+{
+ u64 data = vmcs_read64(GUEST_IA32_DEBUGCTL);
+
+ if (data & DEBUGCTLMSR_FREEZE_LBRS_ON_PMI) {
+ data &= ~DEBUGCTLMSR_LBR;
+ vmcs_write64(GUEST_IA32_DEBUGCTL, data);
+ }
+}
+
+static void intel_pmu_deliver_pmi(struct kvm_vcpu *vcpu)
+{
+ u8 version = vcpu_to_pmu(vcpu)->version;
+
+ if (!intel_pmu_lbr_is_enabled(vcpu))
+ return;
+
+ if (version > 1 && version < 4)
+ intel_pmu_legacy_freezing_lbrs_on_pmi(vcpu);
+}
+
static void vmx_update_intercept_for_lbr_msrs(struct kvm_vcpu *vcpu, bool set)
{
struct x86_pmu_lbr *lbr = vcpu_to_lbr_records(vcpu);
@@ -665,4 +694,5 @@ struct kvm_pmu_ops intel_pmu_ops = {
.refresh = intel_pmu_refresh,
.init = intel_pmu_init,
.reset = intel_pmu_reset,
+ .deliver_pmi = intel_pmu_deliver_pmi,
};
diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
index 40fdeb394328..5389032ca4ad 100644
--- a/arch/x86/kvm/vmx/vmx.c
+++ b/arch/x86/kvm/vmx/vmx.c
@@ -1963,7 +1963,7 @@ static u64 vcpu_supported_debugctl(struct kvm_vcpu *vcpu)
u64 debugctl = vmx_supported_debugctl();
if (!intel_pmu_lbr_is_enabled(vcpu))
- debugctl &= ~DEBUGCTLMSR_LBR;
+ debugctl &= ~DEBUGCTLMSR_LBR_MASK;
return debugctl;
}
--
2.29.2
[GIT PULL 1/2] drivers: soc: Keystone update for v5.12
The following changes since commit 5c8fe583cce542aa0b84adc939ce85293de36e5e: Linux 5.11-rc1 (2020-12-27 15:30:22 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux-keystone.git tags/drivers_soc_for_5.12 for you to fetch changes up to a8fc8e5b8e42c4401d009143a5fd822ef3d0c9df: soc: ti: k3-ringacc: Use of_device_get_match_data() (2021-01-31 20:58:49 -0800) drivers: soc: Keystone update for v5.12 Updates include: - Navigator refcount correction - probe fix in pm driver - fix clock init for PRUSS - PRUSS binding doc update - of_device_get_match_data() use in ringacc Christophe JAILLET (1): soc: ti: pm33xx: Fix some resource leak in the error handling paths of the probe function Grzegorz Jaszczyk (1): dt-bindings: soc: ti: Update TI PRUSS bindings about schemas to include Suman Anna (3): soc: ti: pruss: Correct the pruss_clk_init error trace text soc: ti: pruss: Refactor the CFG sub-module init soc: ti: k3-ringacc: Use of_device_get_match_data() Vasyl Gomonovych (1): soc: ti: knav_qmss: Put refcount for dev node in failure case .../devicetree/bindings/soc/ti/ti,pruss.yaml | 76 ++ drivers/soc/ti/k3-ringacc.c| 7 +- drivers/soc/ti/knav_dma.c | 1 + drivers/soc/ti/knav_qmss_queue.c | 3 + drivers/soc/ti/pm33xx.c| 5 +- drivers/soc/ti/pruss.c | 91 -- 6 files changed, 137 insertions(+), 46 deletions(-)
[PATCH] mm: workingset: clarify eviction order and distance calculation
The premise of the refault distance is that it can be seen as a deficit of the inactive list space, so that if the inactive list would have had (R - E) more slots, the page would not have been evicted but promoted to the active list instead. However, the way the code is ordered right now set us to be off by one, so the real number of slots would be (R - E) + 1. I stumbled upon this when trying to understand the code and it puzzled me that the comments did not match what the code did. This it not an issue at all since evictions and refaults tend to happen in a number large enough that being off-by-one does not have any impact - and since the compiler and CPUs are free to rearrange the execution sequence anyway. But as Johannes says, it is better to re-arrange the code in the proper order since otherwise would be misleading to somebody who is actively reading and trying to understand the logic of the code - like it happened to me. Signed-off-by: Oscar Salvador Acked-by: Johannes Weiner --- mm/workingset.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mm/workingset.c b/mm/workingset.c index 10e96de945b3..0201aa1ff320 100644 --- a/mm/workingset.c +++ b/mm/workingset.c @@ -263,10 +263,10 @@ void *workingset_eviction(struct page *page, struct mem_cgroup *target_memcg) VM_BUG_ON_PAGE(!PageLocked(page), page); lruvec = mem_cgroup_lruvec(target_memcg, pgdat); - workingset_age_nonresident(lruvec, thp_nr_pages(page)); /* XXX: target_memcg can be NULL, go through lruvec */ memcgid = mem_cgroup_id(lruvec_memcg(lruvec)); eviction = atomic_long_read(>nonresident_age); + workingset_age_nonresident(lruvec, thp_nr_pages(page)); return pack_shadow(memcgid, pgdat, eviction, PageWorkingset(page)); } -- 2.26.2
Re: [PATCH] add chan->cl check in mbox_chan_received_data()
On Thu, Jan 7, 2021 at 5:53 AM haidong yao wrote: > > Hi Jassi Brar > > Thank you very much for your reply. > > Look at the function sprd_mbox_outbox_isr . > > Chan is !NULL. > > chan->cl is NULL when the client driver not loaded, the controller > driver don't know the client driver loaded successfully, so, I do not > use mbox_free_channel. > > Here,How do you know chan->cl is ok? > The channel is supposed to get/send data _only_ if it is being used by a client. Which you can mark in .startup() and .shutdown(). Checking for chan->cl will make your symptoms disappear but that is not the right fix for the issue. The right fix is to EITHER not cause Rx/Tx interrupt on a channel not being used, OR not send it to upper layers. thanks.
[PATCH] powerpc/603: Fix protection of user pages mapped with PROT_NONE
On book3s/32, page protection is defined by the PP bits in the PTE
which provide the following protection depending on the access
keys defined in the matching segment register:
- PP 00 means RW with key 0 and N/A with key 1.
- PP 01 means RW with key 0 and RO with key 1.
- PP 10 means RW with both key 0 and key 1.
- PP 11 means RO with both key 0 and key 1.
Since the implementation of kernel userspace access protection,
PP bits have been set as follows:
- PP00 for pages without _PAGE_USER
- PP01 for pages with _PAGE_USER and _PAGE_RW
- PP11 for pages with _PAGE_USER and without _PAGE_RW
For kernelspace segments, kernel accesses are performed with key 0
and user accesses are performed with key 1. As PP00 is used for
non _PAGE_USER pages, user can't access kernel pages not flagged
_PAGE_USER while kernel can.
For userspace segments, both kernel and user accesses are performed
with key 0, therefore pages not flagged _PAGE_USER are still
accessible to the user.
This shouldn't be an issue, because userspace is expected to be
accessible to the user. But unlike most other architectures, powerpc
implements PROT_NONE protection by removing _PAGE_USER flag instead of
flagging the page as not valid. This means that pages in userspace
that are not flagged _PAGE_USER shall remain inaccessible.
To get the expected behaviour, just mimic other architectures in the
TLB miss handler by checking _PAGE_USER permission on userspace
accesses as if it was the _PAGE_PRESENT bit.
Note that this problem only is only for 603 cores. The 604+ have
an hash table, and hash_page() function already implement the
verification of _PAGE_USER permission on userspace pages.
Reported-by: Christoph Plattner
Fixes: f342adca3afc ("powerpc/32s: Prepare Kernel Userspace Access Protection")
Cc: sta...@vger.kernel.org
Signed-off-by: Christophe Leroy
---
arch/powerpc/kernel/head_book3s_32.S | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/kernel/head_book3s_32.S
b/arch/powerpc/kernel/head_book3s_32.S
index 858fbc8b19f3..0004e8a6a58e 100644
--- a/arch/powerpc/kernel/head_book3s_32.S
+++ b/arch/powerpc/kernel/head_book3s_32.S
@@ -453,11 +453,12 @@ InstructionTLBMiss:
cmplw 0,r1,r3
#endif
mfspr r2, SPRN_SDR1
- li r1,_PAGE_PRESENT | _PAGE_ACCESSED | _PAGE_EXEC
+ li r1,_PAGE_PRESENT | _PAGE_ACCESSED | _PAGE_EXEC | _PAGE_USER
rlwinm r2, r2, 28, 0xf000
#ifdef CONFIG_MODULES
bgt-112f
lis r2, (swapper_pg_dir - PAGE_OFFSET)@ha /* if kernel address,
use */
+ li r1,_PAGE_PRESENT | _PAGE_ACCESSED | _PAGE_EXEC
addir2, r2, (swapper_pg_dir - PAGE_OFFSET)@l/* kernel page
table */
#endif
112: rlwimi r2,r3,12,20,29 /* insert top 10 bits of address */
@@ -516,10 +517,11 @@ DataLoadTLBMiss:
lis r1, TASK_SIZE@h /* check if kernel address */
cmplw 0,r1,r3
mfspr r2, SPRN_SDR1
- li r1, _PAGE_PRESENT | _PAGE_ACCESSED
+ li r1, _PAGE_PRESENT | _PAGE_ACCESSED | _PAGE_USER
rlwinm r2, r2, 28, 0xf000
bgt-112f
lis r2, (swapper_pg_dir - PAGE_OFFSET)@ha /* if kernel address,
use */
+ li r1, _PAGE_PRESENT | _PAGE_ACCESSED
addir2, r2, (swapper_pg_dir - PAGE_OFFSET)@l/* kernel page
table */
112: rlwimi r2,r3,12,20,29 /* insert top 10 bits of address */
lwz r2,0(r2)/* get pmd entry */
@@ -593,10 +595,11 @@ DataStoreTLBMiss:
lis r1, TASK_SIZE@h /* check if kernel address */
cmplw 0,r1,r3
mfspr r2, SPRN_SDR1
- li r1, _PAGE_RW | _PAGE_DIRTY | _PAGE_PRESENT | _PAGE_ACCESSED
+ li r1, _PAGE_RW | _PAGE_DIRTY | _PAGE_PRESENT | _PAGE_ACCESSED |
_PAGE_USER
rlwinm r2, r2, 28, 0xf000
bgt-112f
lis r2, (swapper_pg_dir - PAGE_OFFSET)@ha /* if kernel address,
use */
+ li r1, _PAGE_RW | _PAGE_DIRTY | _PAGE_PRESENT | _PAGE_ACCESSED
addir2, r2, (swapper_pg_dir - PAGE_OFFSET)@l/* kernel page
table */
112: rlwimi r2,r3,12,20,29 /* insert top 10 bits of address */
lwz r2,0(r2)/* get pmd entry */
--
2.25.0
Re: [PATCH RFC v2 02/10] vringh: add 'iotlb_lock' to synchronize iotlb accesses
On 2021/1/29 下午5:18, Stefano Garzarella wrote:
On Fri, Jan 29, 2021 at 03:43:40PM +0800, Jason Wang wrote:
On 2021/1/28 下午10:41, Stefano Garzarella wrote:
Usually iotlb accesses are synchronized with a spinlock.
Let's request it as a new parameter in vringh_set_iotlb() and
hold it when we navigate the iotlb in iotlb_translate() to avoid
race conditions with any new additions/deletions of ranges from
the ioltb.
Patch looks fine but I wonder if this is the best approach comparing
to do locking by the caller.
Initially I tried to hold the lock in the vdpasim_blk_work(), but since
we have a lot of different functions for vringh, I opted to take the
lock at the beginning and release it at the end.
Also because several times I went to see if that call used
iotlb_translate or not.
This could be a problem for example if we have multiple workers to
handle multiple queues.
Also, some functions are quite long (e.g. vringh_getdesc_iotlb) and
holding the lock for that long could reduce parallelism.
For these reasons I thought it was better to hide everything from the
caller who doesn't have to worry about which function calls
iotlb_translate() and thus hold the lock.
Fine with me.
Acked-by: Jason Wang
Thanks
Thanks,
Stefano
Thanks
Signed-off-by: Stefano Garzarella
---
include/linux/vringh.h | 6 +-
drivers/vdpa/vdpa_sim/vdpa_sim.c | 3 ++-
drivers/vhost/vringh.c | 9 -
3 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/include/linux/vringh.h b/include/linux/vringh.h
index 59bd50f99291..9c077863c8f6 100644
--- a/include/linux/vringh.h
+++ b/include/linux/vringh.h
@@ -46,6 +46,9 @@ struct vringh {
/* IOTLB for this vring */
struct vhost_iotlb *iotlb;
+ /* spinlock to synchronize IOTLB accesses */
+ spinlock_t *iotlb_lock;
+
/* The function to call to notify the guest about added buffers */
void (*notify)(struct vringh *);
};
@@ -258,7 +261,8 @@ static inline __virtio64 cpu_to_vringh64(const
struct vringh *vrh, u64 val)
#if IS_REACHABLE(CONFIG_VHOST_IOTLB)
-void vringh_set_iotlb(struct vringh *vrh, struct vhost_iotlb *iotlb);
+void vringh_set_iotlb(struct vringh *vrh, struct vhost_iotlb *iotlb,
+ spinlock_t *iotlb_lock);
int vringh_init_iotlb(struct vringh *vrh, u64 features,
unsigned int num, bool weak_barriers,
diff --git a/drivers/vdpa/vdpa_sim/vdpa_sim.c
b/drivers/vdpa/vdpa_sim/vdpa_sim.c
index 2183a833fcf4..53238989713d 100644
--- a/drivers/vdpa/vdpa_sim/vdpa_sim.c
+++ b/drivers/vdpa/vdpa_sim/vdpa_sim.c
@@ -284,7 +284,8 @@ struct vdpasim *vdpasim_create(struct
vdpasim_dev_attr *dev_attr)
goto err_iommu;
for (i = 0; i < dev_attr->nvqs; i++)
- vringh_set_iotlb(>vqs[i].vring, vdpasim->iommu);
+ vringh_set_iotlb(>vqs[i].vring, vdpasim->iommu,
+ >iommu_lock);
ret = iova_cache_get();
if (ret)
diff --git a/drivers/vhost/vringh.c b/drivers/vhost/vringh.c
index 85d85faba058..f68122705719 100644
--- a/drivers/vhost/vringh.c
+++ b/drivers/vhost/vringh.c
@@ -1074,6 +1074,8 @@ static int iotlb_translate(const struct vringh
*vrh,
int ret = 0;
u64 s = 0;
+ spin_lock(vrh->iotlb_lock);
+
while (len > s) {
u64 size, pa, pfn;
@@ -1103,6 +1105,8 @@ static int iotlb_translate(const struct vringh
*vrh,
++ret;
}
+ spin_unlock(vrh->iotlb_lock);
+
return ret;
}
@@ -1262,10 +1266,13 @@ EXPORT_SYMBOL(vringh_init_iotlb);
* vringh_set_iotlb - initialize a vringh for a ring with IOTLB.
* @vrh: the vring
* @iotlb: iotlb associated with this vring
+ * @iotlb_lock: spinlock to synchronize the iotlb accesses
*/
-void vringh_set_iotlb(struct vringh *vrh, struct vhost_iotlb *iotlb)
+void vringh_set_iotlb(struct vringh *vrh, struct vhost_iotlb *iotlb,
+ spinlock_t *iotlb_lock)
{
vrh->iotlb = iotlb;
+ vrh->iotlb_lock = iotlb_lock;
}
EXPORT_SYMBOL(vringh_set_iotlb);
Re: [PATCH] dmaengine: qcom: bam_dma: Add LOCK and UNLOCK flag bit support
On 2021-02-01 11:35, Vinod Koul wrote: On 27-01-21, 23:56, mda...@codeaurora.org wrote: On 2021-01-19 22:15, Vinod Koul wrote: > On 18-01-21, 09:21, mda...@codeaurora.org wrote: > > On 2021-01-15 11:28, Vinod Koul wrote: > > > On 14-01-21, 01:20, mda...@codeaurora.org wrote: > > > > On 2021-01-12 15:40, Vinod Koul wrote: > > > > > On 12-01-21, 15:01, mda...@codeaurora.org wrote: > > > > > > On 2020-12-21 23:03, mda...@codeaurora.org wrote: > > > > > > > On 2020-12-21 14:53, Vinod Koul wrote: > > > > > > > > Hello, > > > > > > > > > > > > > > > > On 17-12-20, 20:07, Md Sadre Alam wrote: > > > > > > > > > This change will add support for LOCK & UNLOCK flag bit support > > > > > > > > > on CMD descriptor. > > > > > > > > > > > > > > > > > > If DMA_PREP_LOCK flag passed in prep_slave_sg then requester of this > > > > > > > > > transaction wanted to lock the DMA controller for this transaction so > > > > > > > > > BAM driver should set LOCK bit for the HW descriptor. > > > > > > > > > > > > > > > > > > If DMA_PREP_UNLOCK flag passed in prep_slave_sg then requester > > > > > > > > > of this > > > > > > > > > transaction wanted to unlock the DMA controller.so BAM driver > > > > > > > > > should set > > > > > > > > > UNLOCK bit for the HW descriptor. > > > > > > > > > > > > > > > > Can you explain why would we need to first lock and then unlock..? How > > > > > > > > would this be used in real world. > > > > > > > > > > > > > > > > I have read a bit of documentation but is unclear to me. Also should > > > > > > > > this be exposed as an API to users, sounds like internal to driver..? > > > > > > > > > > > > > > > > > > > > > > IPQ5018 SoC having only one Crypto Hardware Engine. This Crypto Hardware > > > > > > > Engine > > > > > > > will be shared between A53 core & ubi32 core. There is two separate > > > > > > > driver dedicated > > > > > > > to A53 core and ubi32 core. So to use Crypto Hardware Engine > > > > > > > parallelly for encryption/description > > > > > > > we need bam locking mechanism. if one driver will submit the request > > > > > > > for encryption/description > > > > > > > to Crypto then first it has to set LOCK flag bit on command descriptor > > > > > > > so that other pipes will > > > > > > > get locked. > > > > > > > > > > > > > > The Pipe Locking/Unlocking will be only on command-descriptor. Upon > > > > > > > encountering a command descriptor > > > > > > > > > > Can you explain what is a cmd descriptor? > > > > > > > > In BAM pipe descriptor structure there is a field called CMD > > > > (Command > > > > descriptor). > > > > CMD allows the SW to create descriptors of type Command which does > > > > not > > > > generate any data transmissions > > > > but configures registers in the Peripheral (write operations, and > > > > read > > > > registers operations ). > > > > Using command descriptor enables the SW to queue new configurations > > > > between data transfers in advance. > > > > > > What and when is the CMD descriptor used for..? > > > > CMD descriptor is mainly used for configuring controller register. > > We can read/write controller register via BAM using CMD descriptor > > only. > > CMD descriptor use command pipe for the transaction. > > In which use cases would you need to issue cmd descriptors..? In IPQ5018 there is only one Crypto engine and it will get shared between UBI32 core & A53 core. So here we need to use command descriptor in-order to perform LOCKING/UNLOCKING mechanism. Since LOCK/ULOCK flag we can set only on CMD descriptor. So when will lock/unlock be performed? Can you please explain that.. LOCK/UNLOCK will be performed when two different driver wanted to use the same HW. eg. In IPQ5018 there is only one Crypto engine and it will be shared b/w UBI32 core driver and A53 core driver. When A53 core wanted to submit request to crypto engine via BAM then first it has to LOCK all other pipes (pipe dedicated to UBI32 core) and then trigger the transaction start. Once all the transaction will be completed the A53 core crypto driver will release the LOCK from all the pipes. Same sequence will be applicable for UBI32 core crypto driver as well. It depends whose request will come first to the crypto HW. > > > > > > > > > > > > > > > > with LOCK bit set, The BAM will lock all other pipes not related to > > > > > > > the current pipe group, and keep > > > > > > > handling the current pipe only until it sees the UNLOCK set then it > > > > > > > will release all locked pipes. > > > > > > > locked pipe will not fetch new descriptors even if it got event/events > > > > > > > adding more descriptors for > > > > > > > this pipe (locked pipe). > > > > > > > > > > > > > > No need to expose as an API to user because its internal to driver, so > > > > > > > while preparing command descriptor > > > > > > > just we have to update the LOCK/UNLOCK flag. > > > > > > > > > > So IIUC, no api right? it would be internal to
Re: usb: dwc3: gadget: skip pullup and set_speed after suspend
On Sun, Jan 24, 2021 at 05:31:57PM +0200, Felipe Balbi wrote: > > Hi, > > Daehwan Jung writes: > > Sometimes dwc3_gadget_pullup and dwc3_gadget_set_speed are called after > > entering suspend. That's why it needs to check whether suspend > > > > 1. dwc3 sends disconnect uevent and turn off. (suspend) > > 2. Platform side causes pullup or set_speed(e.g., adbd closes ffs node) > > 3. It causes unexpected behavior like ITMON error. > > please collect dwc3 trace events showing this problem. > > -- > balbi Hi, balbi I'm sorry for late reply. I pulled in belo patch and that issue didn't occur usb: dwc3: gadget: Restart DWC3 gadget when enabling pullup @ Wesley cheng But, I think it needs to modify pm_rumtime_put to pm_runtime_put_sync_suspend for syncronization. pm_rumtime_put calls rumtime_idle not runtime_suspend Please check it. usb: dwc3: gadget: Allow runtime suspend if UDC unbinded Best Regards, Jung Daehwan
Re: [RFC 03/20] mm/mprotect: do not flush on permission promotion
> On Jan 31, 2021, at 4:10 AM, Andrew Cooper wrote: > > On 31/01/2021 01:07, Andy Lutomirski wrote: >> Adding Andrew Cooper, who has a distressingly extensive understanding >> of the x86 PTE magic. > > Pretty sure it is all learning things the hard way... > >> On Sat, Jan 30, 2021 at 4:16 PM Nadav Amit wrote: >>> diff --git a/mm/mprotect.c b/mm/mprotect.c >>> index 632d5a677d3f..b7473d2c9a1f 100644 >>> --- a/mm/mprotect.c >>> +++ b/mm/mprotect.c >>> @@ -139,7 +139,8 @@ static unsigned long change_pte_range(struct mmu_gather >>> *tlb, >>>ptent = pte_mkwrite(ptent); >>>} >>>ptep_modify_prot_commit(vma, addr, pte, oldpte, >>> ptent); >>> - tlb_flush_pte_range(tlb, addr, PAGE_SIZE); >>> + if (pte_may_need_flush(oldpte, ptent)) >>> + tlb_flush_pte_range(tlb, addr, PAGE_SIZE); > > You're choosing to avoid the flush, based on A/D bits read ahead of the > actual modification of the PTE. > > In this example, another thread can write into the range (sets A and D), > and get a suitable TLB entry which goes unflushed while the rest of the > kernel thinks the memory is write-protected and clean. > > The only safe way to do this is to use XCHG/etc to modify the PTE, and > base flush calculations on the results. Atomic operations are ordered > with A/D updates from pagewalks on other CPUs, even on AMD where A > updates are explicitly not ordered with regular memory reads, for > performance reasons. Thanks Andrew for the feedback, but I think the patch does it exactly in this safe manner that you describe (at least on native x86, but I see a similar path elsewhere as well): oldpte = ptep_modify_prot_start() -> __ptep_modify_prot_start() -> ptep_get_and_clear -> native_ptep_get_and_clear() -> xchg() Note that the xchg() will clear the PTE (i.e., making it non-present), and no further updates of A/D are possible until ptep_modify_prot_commit() is called. On non-SMP setups this is not atomic (no xchg), but since we hold the lock, we should be safe. I guess you are right and a pte_may_need_flush() deserves a comment to clarify that oldpte must be obtained by an atomic operation to ensure no A/D bits are lost (as you say). Yet, I do not see a correctness problem. Am I missing something?
[PATCH v14 11/11] selftests: kvm/x86: add test for pmu msr MSR_IA32_PERF_CAPABILITIES
This test will check the effect of various CPUID settings on the
MSR_IA32_PERF_CAPABILITIES MSR, check that whatever user space writes
with KVM_SET_MSR is _not_ modified from the guest and can be retrieved
with KVM_GET_MSR, and check that invalid LBR formats are rejected.
Signed-off-by: Like Xu
---
tools/testing/selftests/kvm/.gitignore| 1 +
tools/testing/selftests/kvm/Makefile | 1 +
.../selftests/kvm/x86_64/vmx_pmu_msrs_test.c | 149 ++
3 files changed, 151 insertions(+)
create mode 100644 tools/testing/selftests/kvm/x86_64/vmx_pmu_msrs_test.c
diff --git a/tools/testing/selftests/kvm/.gitignore
b/tools/testing/selftests/kvm/.gitignore
index ce8f4ad39684..28b71efe52a0 100644
--- a/tools/testing/selftests/kvm/.gitignore
+++ b/tools/testing/selftests/kvm/.gitignore
@@ -25,6 +25,7 @@
/x86_64/vmx_set_nested_state_test
/x86_64/vmx_tsc_adjust_test
/x86_64/xss_msr_test
+/x86_64/vmx_pmu_msrs_test
/demand_paging_test
/dirty_log_test
/dirty_log_perf_test
diff --git a/tools/testing/selftests/kvm/Makefile
b/tools/testing/selftests/kvm/Makefile
index fe41c6a0fa67..cf8737828dd4 100644
--- a/tools/testing/selftests/kvm/Makefile
+++ b/tools/testing/selftests/kvm/Makefile
@@ -59,6 +59,7 @@ TEST_GEN_PROGS_x86_64 += x86_64/vmx_tsc_adjust_test
TEST_GEN_PROGS_x86_64 += x86_64/xss_msr_test
TEST_GEN_PROGS_x86_64 += x86_64/debug_regs
TEST_GEN_PROGS_x86_64 += x86_64/tsc_msrs_test
+TEST_GEN_PROGS_x86_64 += x86_64/vmx_pmu_msrs_test
TEST_GEN_PROGS_x86_64 += demand_paging_test
TEST_GEN_PROGS_x86_64 += dirty_log_test
TEST_GEN_PROGS_x86_64 += dirty_log_perf_test
diff --git a/tools/testing/selftests/kvm/x86_64/vmx_pmu_msrs_test.c
b/tools/testing/selftests/kvm/x86_64/vmx_pmu_msrs_test.c
new file mode 100644
index ..b3ad63e6ff12
--- /dev/null
+++ b/tools/testing/selftests/kvm/x86_64/vmx_pmu_msrs_test.c
@@ -0,0 +1,149 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * VMX-pmu related msrs test
+ *
+ * Copyright (C) 2021 Intel Corporation
+ *
+ * Test to check the effect of various CPUID settings
+ * on the MSR_IA32_PERF_CAPABILITIES MSR, and check that
+ * whatever we write with KVM_SET_MSR is _not_ modified
+ * in the guest and test it can be retrieved with KVM_GET_MSR.
+ *
+ * Test to check that invalid LBR formats are rejected.
+ */
+
+#define _GNU_SOURCE /* for program_invocation_short_name */
+#include
+
+#include "kvm_util.h"
+#include "vmx.h"
+
+#define VCPU_ID 0
+
+#define X86_FEATURE_PDCM (1<<15)
+#define PMU_CAP_FW_WRITES (1ULL << 13)
+#define PMU_CAP_LBR_FMT0x3f
+
+union cpuid10_eax {
+ struct {
+ unsigned int version_id:8;
+ unsigned int num_counters:8;
+ unsigned int bit_width:8;
+ unsigned int mask_length:8;
+ } split;
+ unsigned int full;
+};
+
+union perf_capabilities {
+ struct {
+ u64 lbr_format:6;
+ u64 pebs_trap:1;
+ u64 pebs_arch_reg:1;
+ u64 pebs_format:4;
+ u64 smm_freeze:1;
+ u64 full_width_write:1;
+ u64 pebs_baseline:1;
+ u64 perf_metrics:1;
+ u64 pebs_output_pt_available:1;
+ u64 anythread_deprecated:1;
+ };
+ u64 capabilities;
+};
+
+uint64_t rdmsr_on_cpu(uint32_t reg)
+{
+ uint64_t data;
+ int fd;
+ char msr_file[64];
+
+ sprintf(msr_file, "/dev/cpu/%d/msr", 0);
+ fd = open(msr_file, O_RDONLY);
+ if (fd < 0)
+ exit(KSFT_SKIP);
+
+ if (pread(fd, , sizeof(data), reg) != sizeof(data))
+ exit(KSFT_SKIP);
+
+ close(fd);
+ return data;
+}
+
+static void guest_code(void)
+{
+ wrmsr(MSR_IA32_PERF_CAPABILITIES, PMU_CAP_LBR_FMT);
+}
+
+int main(int argc, char *argv[])
+{
+ struct kvm_cpuid2 *cpuid;
+ struct kvm_cpuid_entry2 *entry_1_0;
+ struct kvm_cpuid_entry2 *entry_a_0;
+ bool pdcm_supported = false;
+ struct kvm_vm *vm;
+ int ret;
+ union cpuid10_eax eax;
+ union perf_capabilities host_cap;
+
+ host_cap.capabilities = rdmsr_on_cpu(MSR_IA32_PERF_CAPABILITIES);
+ host_cap.capabilities &= (PMU_CAP_FW_WRITES | PMU_CAP_LBR_FMT);
+
+ /* Create VM */
+ vm = vm_create_default(VCPU_ID, 0, guest_code);
+ cpuid = kvm_get_supported_cpuid();
+
+ if (kvm_get_cpuid_max_basic() >= 0xa) {
+ entry_1_0 = kvm_get_supported_cpuid_index(1, 0);
+ entry_a_0 = kvm_get_supported_cpuid_index(0xa, 0);
+ pdcm_supported = entry_1_0 && !!(entry_1_0->ecx &
X86_FEATURE_PDCM);
+ eax.full = entry_a_0->eax;
+ }
+ if (!pdcm_supported) {
+ print_skip("MSR_IA32_PERF_CAPABILITIES is not supported by the
vCPU");
+ exit(KSFT_SKIP);
+ }
+ if (!eax.split.version_id) {
+ print_skip("PMU is not
[PATCH v14 08/11] KVM: vmx/pmu: Emulate legacy freezing LBRs on virtual PMI
The current vPMU only supports Architecture Version 2. According to
Intel SDM "17.4.7 Freezing LBR and Performance Counters on PMI", if
IA32_DEBUGCTL.Freeze_LBR_On_PMI = 1, the LBR is frozen on the virtual
PMI and the KVM would emulate to clear the LBR bit (bit 0) in
IA32_DEBUGCTL. Also, guest needs to re-enable IA32_DEBUGCTL.LBR
to resume recording branches.
Signed-off-by: Like Xu
Reviewed-by: Andi Kleen
---
arch/x86/kvm/pmu.c | 5 -
arch/x86/kvm/pmu.h | 1 +
arch/x86/kvm/vmx/capabilities.h | 4 +++-
arch/x86/kvm/vmx/pmu_intel.c| 30 ++
arch/x86/kvm/vmx/vmx.c | 2 +-
5 files changed, 39 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kvm/pmu.c b/arch/x86/kvm/pmu.c
index 67741d2a0308..405890c723a1 100644
--- a/arch/x86/kvm/pmu.c
+++ b/arch/x86/kvm/pmu.c
@@ -383,8 +383,11 @@ int kvm_pmu_rdpmc(struct kvm_vcpu *vcpu, unsigned idx, u64
*data)
void kvm_pmu_deliver_pmi(struct kvm_vcpu *vcpu)
{
- if (lapic_in_kernel(vcpu))
+ if (lapic_in_kernel(vcpu)) {
+ if (kvm_x86_ops.pmu_ops->deliver_pmi)
+ kvm_x86_ops.pmu_ops->deliver_pmi(vcpu);
kvm_apic_local_deliver(vcpu->arch.apic, APIC_LVTPC);
+ }
}
bool kvm_pmu_is_valid_msr(struct kvm_vcpu *vcpu, u32 msr)
diff --git a/arch/x86/kvm/pmu.h b/arch/x86/kvm/pmu.h
index 067fef51760c..742a4e98df8c 100644
--- a/arch/x86/kvm/pmu.h
+++ b/arch/x86/kvm/pmu.h
@@ -39,6 +39,7 @@ struct kvm_pmu_ops {
void (*refresh)(struct kvm_vcpu *vcpu);
void (*init)(struct kvm_vcpu *vcpu);
void (*reset)(struct kvm_vcpu *vcpu);
+ void (*deliver_pmi)(struct kvm_vcpu *vcpu);
};
static inline u64 pmc_bitmask(struct kvm_pmc *pmc)
diff --git a/arch/x86/kvm/vmx/capabilities.h b/arch/x86/kvm/vmx/capabilities.h
index 62aa7a701ebb..57b940c613ab 100644
--- a/arch/x86/kvm/vmx/capabilities.h
+++ b/arch/x86/kvm/vmx/capabilities.h
@@ -21,6 +21,8 @@ extern int __read_mostly pt_mode;
#define PMU_CAP_FW_WRITES (1ULL << 13)
#define PMU_CAP_LBR_FMT0x3f
+#define DEBUGCTLMSR_LBR_MASK (DEBUGCTLMSR_LBR |
DEBUGCTLMSR_FREEZE_LBRS_ON_PMI)
+
struct nested_vmx_msrs {
/*
* We only store the "true" versions of the VMX capability MSRs. We
@@ -384,7 +386,7 @@ static inline u64 vmx_supported_debugctl(void)
u64 debugctl = DEBUGCTLMSR_BTF;
if (vmx_get_perf_capabilities() & PMU_CAP_LBR_FMT)
- debugctl |= DEBUGCTLMSR_LBR;
+ debugctl |= DEBUGCTLMSR_LBR_MASK;
return debugctl;
}
diff --git a/arch/x86/kvm/vmx/pmu_intel.c b/arch/x86/kvm/vmx/pmu_intel.c
index 60f395e18446..51edd9c1adfa 100644
--- a/arch/x86/kvm/vmx/pmu_intel.c
+++ b/arch/x86/kvm/vmx/pmu_intel.c
@@ -579,6 +579,35 @@ static void intel_pmu_reset(struct kvm_vcpu *vcpu)
intel_pmu_release_guest_lbr_event(vcpu);
}
+/*
+ * Emulate LBR_On_PMI behavior for 1 < pmu.version < 4.
+ *
+ * If Freeze_LBR_On_PMI = 1, the LBR is frozen on PMI and
+ * the KVM emulates to clear the LBR bit (bit 0) in IA32_DEBUGCTL.
+ *
+ * Guest needs to re-enable LBR to resume branches recording.
+ */
+static void intel_pmu_legacy_freezing_lbrs_on_pmi(struct kvm_vcpu *vcpu)
+{
+ u64 data = vmcs_read64(GUEST_IA32_DEBUGCTL);
+
+ if (data & DEBUGCTLMSR_FREEZE_LBRS_ON_PMI) {
+ data &= ~DEBUGCTLMSR_LBR;
+ vmcs_write64(GUEST_IA32_DEBUGCTL, data);
+ }
+}
+
+static void intel_pmu_deliver_pmi(struct kvm_vcpu *vcpu)
+{
+ u8 version = vcpu_to_pmu(vcpu)->version;
+
+ if (!intel_pmu_lbr_is_enabled(vcpu))
+ return;
+
+ if (version > 1 && version < 4)
+ intel_pmu_legacy_freezing_lbrs_on_pmi(vcpu);
+}
+
static void vmx_update_intercept_for_lbr_msrs(struct kvm_vcpu *vcpu, bool set)
{
struct x86_pmu_lbr *lbr = vcpu_to_lbr_records(vcpu);
@@ -665,4 +694,5 @@ struct kvm_pmu_ops intel_pmu_ops = {
.refresh = intel_pmu_refresh,
.init = intel_pmu_init,
.reset = intel_pmu_reset,
+ .deliver_pmi = intel_pmu_deliver_pmi,
};
diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
index 40fdeb394328..5389032ca4ad 100644
--- a/arch/x86/kvm/vmx/vmx.c
+++ b/arch/x86/kvm/vmx/vmx.c
@@ -1963,7 +1963,7 @@ static u64 vcpu_supported_debugctl(struct kvm_vcpu *vcpu)
u64 debugctl = vmx_supported_debugctl();
if (!intel_pmu_lbr_is_enabled(vcpu))
- debugctl &= ~DEBUGCTLMSR_LBR;
+ debugctl &= ~DEBUGCTLMSR_LBR_MASK;
return debugctl;
}
--
2.29.2
Re: [PATCH RFC v2 09/10] vdpa_sim_blk: implement ramdisk behaviour
On 2021/1/28 下午10:41, Stefano Garzarella wrote:
The previous implementation wrote only the status of each request.
This patch implements a more accurate block device simulator,
providing a ramdisk-like behavior.
Signed-off-by: Stefano Garzarella
---
v2:
- used %zd %zx to print size_t and ssize_t variables in dev_err()
- removed unnecessary new line [Jason]
- moved VIRTIO_BLK_T_GET_ID in another patch [Jason]
- used push/pull instead of write/read terminology
- added vdpasim_blk_check_range() to avoid overflows [Stefan]
- use vdpasim*_to_cpu instead of le*_to_cpu
- used vringh_kiov_length() helper [Jason]
Acked-by: Jason Wang
---
drivers/vdpa/vdpa_sim/vdpa_sim_blk.c | 164 ---
1 file changed, 146 insertions(+), 18 deletions(-)
diff --git a/drivers/vdpa/vdpa_sim/vdpa_sim_blk.c
b/drivers/vdpa/vdpa_sim/vdpa_sim_blk.c
index 999f9ca0b628..fc47e8320358 100644
--- a/drivers/vdpa/vdpa_sim/vdpa_sim_blk.c
+++ b/drivers/vdpa/vdpa_sim/vdpa_sim_blk.c
@@ -3,6 +3,7 @@
* VDPA simulator for block device.
*
* Copyright (c) 2020, Mellanox Technologies. All rights reserved.
+ * Copyright (c) 2021, Red Hat Inc. All rights reserved.
*
*/
@@ -13,6 +14,7 @@
#include
#include
#include
+#include
#include
#include "vdpa_sim.h"
@@ -36,10 +38,151 @@
static struct vdpasim *vdpasim_blk_dev;
+static bool vdpasim_blk_check_range(u64 start_sector, size_t range_size)
+{
+ u64 range_sectors = range_size >> SECTOR_SHIFT;
+
+ if (range_size > VDPASIM_BLK_SIZE_MAX * VDPASIM_BLK_SEG_MAX)
+ return false;
+
+ if (start_sector > VDPASIM_BLK_CAPACITY)
+ return false;
+
+ if (range_sectors > VDPASIM_BLK_CAPACITY - start_sector)
+ return false;
+
+ return true;
+}
+
+/* Returns 'true' if the request is handled (with or without an I/O error)
+ * and the status is correctly written in the last byte of the 'in iov',
+ * 'false' otherwise.
+ */
+static bool vdpasim_blk_handle_req(struct vdpasim *vdpasim,
+ struct vdpasim_virtqueue *vq)
+{
+ size_t pushed = 0, to_pull, to_push;
+ struct virtio_blk_outhdr hdr;
+ ssize_t bytes;
+ loff_t offset;
+ u64 sector;
+ u8 status;
+ u32 type;
+ int ret;
+
+ ret = vringh_getdesc_iotlb(>vring, >out_iov, >in_iov,
+ >head, GFP_ATOMIC);
+ if (ret != 1)
+ return false;
+
+ if (vq->out_iov.used < 1 || vq->in_iov.used < 1) {
+ dev_err(>vdpa.dev, "missing headers - out_iov: %u in_iov
%u\n",
+ vq->out_iov.used, vq->in_iov.used);
+ return false;
+ }
+
+ if (vq->in_iov.iov[vq->in_iov.used - 1].iov_len < 1) {
+ dev_err(>vdpa.dev, "request in header too short\n");
+ return false;
+ }
+
+ /* The last byte is the status and we checked if the last iov has
+* enough room for it.
+*/
+ to_push = vringh_kiov_length(>in_iov) - 1;
+
+ to_pull = vringh_kiov_length(>out_iov);
+
+ bytes = vringh_iov_pull_iotlb(>vring, >out_iov, ,
+ sizeof(hdr));
+ if (bytes != sizeof(hdr)) {
+ dev_err(>vdpa.dev, "request out header too short\n");
+ return false;
+ }
+
+ to_pull -= bytes;
+
+ type = vdpasim32_to_cpu(vdpasim, hdr.type);
+ sector = vdpasim64_to_cpu(vdpasim, hdr.sector);
+ offset = sector << SECTOR_SHIFT;
+ status = VIRTIO_BLK_S_OK;
+
+ switch (type) {
+ case VIRTIO_BLK_T_IN:
+ if (!vdpasim_blk_check_range(sector, to_push)) {
+ dev_err(>vdpa.dev,
+ "reading over the capacity - offset: 0x%llx len:
0x%zx\n",
+ offset, to_push);
+ status = VIRTIO_BLK_S_IOERR;
+ break;
+ }
+
+ bytes = vringh_iov_push_iotlb(>vring, >in_iov,
+ vdpasim->buffer + offset,
+ to_push);
+ if (bytes < 0) {
+ dev_err(>vdpa.dev,
+ "vringh_iov_push_iotlb() error: %zd offset: 0x%llx
len: 0x%zx\n",
+ bytes, offset, to_push);
+ status = VIRTIO_BLK_S_IOERR;
+ break;
+ }
+
+ pushed += bytes;
+ break;
+
+ case VIRTIO_BLK_T_OUT:
+ if (!vdpasim_blk_check_range(sector, to_pull)) {
+ dev_err(>vdpa.dev,
+ "writing over the capacity - offset: 0x%llx len:
0x%zx\n",
+ offset, to_pull);
+ status = VIRTIO_BLK_S_IOERR;
+ break;
+ }
+
+ bytes
[PATCH v14 10/11] KVM: vmx/pmu: Expose LBR_FMT in the MSR_IA32_PERF_CAPABILITIES
Userspace could enable guest LBR feature when the exactly supported
LBR format value is initialized to the MSR_IA32_PERF_CAPABILITIES
and the LBR is also compatible with vPMU version and host cpu model.
The LBR could be enabled on the guest if host perf supports LBR
(checked via x86_perf_get_lbr()) and the vcpu model is compatible
with the host one.
Signed-off-by: Like Xu
---
arch/x86/kvm/vmx/capabilities.h | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kvm/vmx/capabilities.h b/arch/x86/kvm/vmx/capabilities.h
index 57b940c613ab..c49f3ee8eca8 100644
--- a/arch/x86/kvm/vmx/capabilities.h
+++ b/arch/x86/kvm/vmx/capabilities.h
@@ -374,11 +374,18 @@ static inline bool vmx_pt_mode_is_host_guest(void)
static inline u64 vmx_get_perf_capabilities(void)
{
+ u64 perf_cap;
+
+ if (boot_cpu_has(X86_FEATURE_PDCM))
+ rdmsrl(MSR_IA32_PERF_CAPABILITIES, perf_cap);
+
+ perf_cap &= PMU_CAP_LBR_FMT;
+
/*
* Since counters are virtualized, KVM would support full
* width counting unconditionally, even if the host lacks it.
*/
- return PMU_CAP_FW_WRITES;
+ return PMU_CAP_FW_WRITES | perf_cap;
}
static inline u64 vmx_supported_debugctl(void)
--
2.29.2
[PATCH v14 09/11] KVM: vmx/pmu: Release guest LBR event via lazy release mechanism
The vPMU uses GUEST_LBR_IN_USE_IDX (bit 58) in 'pmu->pmc_in_use' to
indicate whether a guest LBR event is still needed by the vcpu. If the
vcpu no longer accesses LBR related registers within a scheduling time
slice, and the enable bit of LBR has been unset, vPMU will treat the
guest LBR event as a bland event of a vPMC counter and release it
as usual. Also, the pass-through state of LBR records msrs is cancelled.
Signed-off-by: Like Xu
---
arch/x86/kvm/pmu.c | 3 +++
arch/x86/kvm/pmu.h | 1 +
arch/x86/kvm/vmx/pmu_intel.c | 21 -
3 files changed, 24 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kvm/pmu.c b/arch/x86/kvm/pmu.c
index 405890c723a1..136dc2f3c5d3 100644
--- a/arch/x86/kvm/pmu.c
+++ b/arch/x86/kvm/pmu.c
@@ -476,6 +476,9 @@ void kvm_pmu_cleanup(struct kvm_vcpu *vcpu)
pmc_stop_counter(pmc);
}
+ if (kvm_x86_ops.pmu_ops->cleanup)
+ kvm_x86_ops.pmu_ops->cleanup(vcpu);
+
bitmap_zero(pmu->pmc_in_use, X86_PMC_IDX_MAX);
}
diff --git a/arch/x86/kvm/pmu.h b/arch/x86/kvm/pmu.h
index 742a4e98df8c..7b30bc967af3 100644
--- a/arch/x86/kvm/pmu.h
+++ b/arch/x86/kvm/pmu.h
@@ -40,6 +40,7 @@ struct kvm_pmu_ops {
void (*init)(struct kvm_vcpu *vcpu);
void (*reset)(struct kvm_vcpu *vcpu);
void (*deliver_pmi)(struct kvm_vcpu *vcpu);
+ void (*cleanup)(struct kvm_vcpu *vcpu);
};
static inline u64 pmc_bitmask(struct kvm_pmc *pmc)
diff --git a/arch/x86/kvm/vmx/pmu_intel.c b/arch/x86/kvm/vmx/pmu_intel.c
index 51edd9c1adfa..23cd31b849f4 100644
--- a/arch/x86/kvm/vmx/pmu_intel.c
+++ b/arch/x86/kvm/vmx/pmu_intel.c
@@ -288,8 +288,10 @@ int intel_pmu_create_guest_lbr_event(struct kvm_vcpu *vcpu)
PERF_SAMPLE_BRANCH_USER,
};
- if (unlikely(lbr_desc->event))
+ if (unlikely(lbr_desc->event)) {
+ __set_bit(INTEL_PMC_IDX_FIXED_VLBR, pmu->pmc_in_use);
return 0;
+ }
event = perf_event_create_kernel_counter(, -1,
current, NULL, NULL);
@@ -300,6 +302,7 @@ int intel_pmu_create_guest_lbr_event(struct kvm_vcpu *vcpu)
}
lbr_desc->event = event;
pmu->event_count++;
+ __set_bit(INTEL_PMC_IDX_FIXED_VLBR, pmu->pmc_in_use);
return 0;
}
@@ -332,9 +335,11 @@ static bool intel_pmu_handle_lbr_msrs_access(struct
kvm_vcpu *vcpu,
rdmsrl(index, msr_info->data);
else
wrmsrl(index, msr_info->data);
+ __set_bit(INTEL_PMC_IDX_FIXED_VLBR,
vcpu_to_pmu(vcpu)->pmc_in_use);
local_irq_enable();
return true;
}
+ clear_bit(INTEL_PMC_IDX_FIXED_VLBR, vcpu_to_pmu(vcpu)->pmc_in_use);
local_irq_enable();
dummy:
@@ -463,6 +468,7 @@ static void intel_pmu_refresh(struct kvm_vcpu *vcpu)
struct kvm_cpuid_entry2 *entry;
union cpuid10_eax eax;
union cpuid10_edx edx;
+ struct lbr_desc *lbr_desc = vcpu_to_lbr_desc(vcpu);
pmu->nr_arch_gp_counters = 0;
pmu->nr_arch_fixed_counters = 0;
@@ -482,6 +488,8 @@ static void intel_pmu_refresh(struct kvm_vcpu *vcpu)
return;
perf_get_x86_pmu_capability(_pmu);
+ if (lbr_desc->records.nr)
+ bitmap_set(pmu->all_valid_pmc_idx, INTEL_PMC_IDX_FIXED_VLBR, 1);
pmu->nr_arch_gp_counters = min_t(int, eax.split.num_counters,
x86_pmu.num_counters_gp);
@@ -658,17 +666,21 @@ static inline void vmx_enable_lbr_msrs_passthrough(struct
kvm_vcpu *vcpu)
*/
void vmx_passthrough_lbr_msrs(struct kvm_vcpu *vcpu)
{
+ struct kvm_pmu *pmu = vcpu_to_pmu(vcpu);
struct lbr_desc *lbr_desc = vcpu_to_lbr_desc(vcpu);
if (!lbr_desc->event) {
vmx_disable_lbr_msrs_passthrough(vcpu);
if (vmcs_read64(GUEST_IA32_DEBUGCTL) & DEBUGCTLMSR_LBR)
goto warn;
+ if (test_bit(INTEL_PMC_IDX_FIXED_VLBR, pmu->pmc_in_use))
+ goto warn;
return;
}
if (lbr_desc->event->state < PERF_EVENT_STATE_ACTIVE) {
vmx_disable_lbr_msrs_passthrough(vcpu);
+ __clear_bit(INTEL_PMC_IDX_FIXED_VLBR, pmu->pmc_in_use);
goto warn;
} else
vmx_enable_lbr_msrs_passthrough(vcpu);
@@ -680,6 +692,12 @@ void vmx_passthrough_lbr_msrs(struct kvm_vcpu *vcpu)
vcpu->vcpu_id);
}
+static void intel_pmu_cleanup(struct kvm_vcpu *vcpu)
+{
+ if (!(vmcs_read64(GUEST_IA32_DEBUGCTL) & DEBUGCTLMSR_LBR))
+ intel_pmu_release_guest_lbr_event(vcpu);
+}
+
struct kvm_pmu_ops intel_pmu_ops = {
.find_arch_event = intel_find_arch_event,
.find_fixed_event = intel_find_fixed_event,
@@ -695,4 +713,5 @@ struct kvm_pmu_ops intel_pmu_ops = {
.init =
[PATCH v14 07/11] KVM: vmx/pmu: Reduce the overhead of LBR pass-through or cancellation
When the LBR records msrs has already been pass-through, there is no
need to call vmx_update_intercept_for_lbr_msrs() again and again, and
vice versa.
Signed-off-by: Like Xu
Reviewed-by: Andi Kleen
---
arch/x86/kvm/vmx/pmu_intel.c | 13 +
arch/x86/kvm/vmx/vmx.h | 3 +++
2 files changed, 16 insertions(+)
diff --git a/arch/x86/kvm/vmx/pmu_intel.c b/arch/x86/kvm/vmx/pmu_intel.c
index 287fc14f0445..60f395e18446 100644
--- a/arch/x86/kvm/vmx/pmu_intel.c
+++ b/arch/x86/kvm/vmx/pmu_intel.c
@@ -550,6 +550,7 @@ static void intel_pmu_init(struct kvm_vcpu *vcpu)
vcpu->arch.perf_capabilities = 0;
lbr_desc->records.nr = 0;
lbr_desc->event = NULL;
+ lbr_desc->msr_passthrough = false;
}
static void intel_pmu_reset(struct kvm_vcpu *vcpu)
@@ -596,12 +597,24 @@ static void vmx_update_intercept_for_lbr_msrs(struct
kvm_vcpu *vcpu, bool set)
static inline void vmx_disable_lbr_msrs_passthrough(struct kvm_vcpu *vcpu)
{
+ struct lbr_desc *lbr_desc = vcpu_to_lbr_desc(vcpu);
+
+ if (!lbr_desc->msr_passthrough)
+ return;
+
vmx_update_intercept_for_lbr_msrs(vcpu, true);
+ lbr_desc->msr_passthrough = false;
}
static inline void vmx_enable_lbr_msrs_passthrough(struct kvm_vcpu *vcpu)
{
+ struct lbr_desc *lbr_desc = vcpu_to_lbr_desc(vcpu);
+
+ if (lbr_desc->msr_passthrough)
+ return;
+
vmx_update_intercept_for_lbr_msrs(vcpu, false);
+ lbr_desc->msr_passthrough = true;
}
/*
diff --git a/arch/x86/kvm/vmx/vmx.h b/arch/x86/kvm/vmx/vmx.h
index 863bb3fe73d4..4d6a2624a204 100644
--- a/arch/x86/kvm/vmx/vmx.h
+++ b/arch/x86/kvm/vmx/vmx.h
@@ -90,6 +90,9 @@ struct lbr_desc {
* The records may be inaccurate if the host reclaims the LBR.
*/
struct perf_event *event;
+
+ /* True if LBRs are marked as not intercepted in the MSR bitmap */
+ bool msr_passthrough;
};
/*
--
2.29.2
Re: [PATCH RFC v2 10/10] vdpa_sim_blk: handle VIRTIO_BLK_T_GET_ID
On 2021/1/28 下午10:41, Stefano Garzarella wrote:
Handle VIRTIO_BLK_T_GET_ID request, always answering the
"vdpa_blk_sim" string.
Signed-off-by: Stefano Garzarella
---
v2:
- made 'vdpasim_blk_id' static [Jason]
Acked-by: Jason Wang
---
drivers/vdpa/vdpa_sim/vdpa_sim_blk.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/vdpa/vdpa_sim/vdpa_sim_blk.c
b/drivers/vdpa/vdpa_sim/vdpa_sim_blk.c
index fc47e8320358..a3f8afad8d14 100644
--- a/drivers/vdpa/vdpa_sim/vdpa_sim_blk.c
+++ b/drivers/vdpa/vdpa_sim/vdpa_sim_blk.c
@@ -37,6 +37,7 @@
#define VDPASIM_BLK_VQ_NUM1
static struct vdpasim *vdpasim_blk_dev;
+static char vdpasim_blk_id[VIRTIO_BLK_ID_BYTES] = "vdpa_blk_sim";
static bool vdpasim_blk_check_range(u64 start_sector, size_t range_size)
{
@@ -152,6 +153,20 @@ static bool vdpasim_blk_handle_req(struct vdpasim *vdpasim,
}
break;
+ case VIRTIO_BLK_T_GET_ID:
+ bytes = vringh_iov_push_iotlb(>vring, >in_iov,
+ vdpasim_blk_id,
+ VIRTIO_BLK_ID_BYTES);
+ if (bytes < 0) {
+ dev_err(>vdpa.dev,
+ "vringh_iov_push_iotlb() error: %zd\n", bytes);
+ status = VIRTIO_BLK_S_IOERR;
+ break;
+ }
+
+ pushed += bytes;
+ break;
+
default:
dev_warn(>vdpa.dev,
"Unsupported request type %d\n", type);
Re: [PATCH] dmaengine: qcom: bam_dma: Add LOCK and UNLOCK flag bit support
On 27-01-21, 23:56, mda...@codeaurora.org wrote: > On 2021-01-19 22:15, Vinod Koul wrote: > > On 18-01-21, 09:21, mda...@codeaurora.org wrote: > > > On 2021-01-15 11:28, Vinod Koul wrote: > > > > On 14-01-21, 01:20, mda...@codeaurora.org wrote: > > > > > On 2021-01-12 15:40, Vinod Koul wrote: > > > > > > On 12-01-21, 15:01, mda...@codeaurora.org wrote: > > > > > > > On 2020-12-21 23:03, mda...@codeaurora.org wrote: > > > > > > > > On 2020-12-21 14:53, Vinod Koul wrote: > > > > > > > > > Hello, > > > > > > > > > > > > > > > > > > On 17-12-20, 20:07, Md Sadre Alam wrote: > > > > > > > > > > This change will add support for LOCK & UNLOCK flag bit > > > > > > > > > > support > > > > > > > > > > on CMD descriptor. > > > > > > > > > > > > > > > > > > > > If DMA_PREP_LOCK flag passed in prep_slave_sg then > > > > > > > > > > requester of this > > > > > > > > > > transaction wanted to lock the DMA controller for this > > > > > > > > > > transaction so > > > > > > > > > > BAM driver should set LOCK bit for the HW descriptor. > > > > > > > > > > > > > > > > > > > > If DMA_PREP_UNLOCK flag passed in prep_slave_sg then > > > > > > > > > > requester > > > > > > > > > > of this > > > > > > > > > > transaction wanted to unlock the DMA controller.so BAM > > > > > > > > > > driver > > > > > > > > > > should set > > > > > > > > > > UNLOCK bit for the HW descriptor. > > > > > > > > > > > > > > > > > > Can you explain why would we need to first lock and then > > > > > > > > > unlock..? How > > > > > > > > > would this be used in real world. > > > > > > > > > > > > > > > > > > I have read a bit of documentation but is unclear to me. Also > > > > > > > > > should > > > > > > > > > this be exposed as an API to users, sounds like internal to > > > > > > > > > driver..? > > > > > > > > > > > > > > > > > > > > > > > > > IPQ5018 SoC having only one Crypto Hardware Engine. This Crypto > > > > > > > > Hardware > > > > > > > > Engine > > > > > > > > will be shared between A53 core & ubi32 core. There is two > > > > > > > > separate > > > > > > > > driver dedicated > > > > > > > > to A53 core and ubi32 core. So to use Crypto Hardware Engine > > > > > > > > parallelly for encryption/description > > > > > > > > we need bam locking mechanism. if one driver will submit the > > > > > > > > request > > > > > > > > for encryption/description > > > > > > > > to Crypto then first it has to set LOCK flag bit on command > > > > > > > > descriptor > > > > > > > > so that other pipes will > > > > > > > > get locked. > > > > > > > > > > > > > > > > The Pipe Locking/Unlocking will be only on command-descriptor. > > > > > > > > Upon > > > > > > > > encountering a command descriptor > > > > > > > > > > > > Can you explain what is a cmd descriptor? > > > > > > > > > > In BAM pipe descriptor structure there is a field called CMD > > > > > (Command > > > > > descriptor). > > > > > CMD allows the SW to create descriptors of type Command which does > > > > > not > > > > > generate any data transmissions > > > > > but configures registers in the Peripheral (write operations, and > > > > > read > > > > > registers operations ). > > > > > Using command descriptor enables the SW to queue new configurations > > > > > between data transfers in advance. > > > > > > > > What and when is the CMD descriptor used for..? > > > > > > CMD descriptor is mainly used for configuring controller register. > > > We can read/write controller register via BAM using CMD descriptor > > > only. > > > CMD descriptor use command pipe for the transaction. > > > > In which use cases would you need to issue cmd descriptors..? > > In IPQ5018 there is only one Crypto engine and it will get shared > between UBI32 core & A53 core. So here we need to use command > descriptor in-order to perform LOCKING/UNLOCKING mechanism. Since > LOCK/ULOCK flag we can set only on CMD descriptor. So when will lock/unlock be performed? Can you please explain that.. > > > > > > > > > > > > > > > > > > > > with LOCK bit set, The BAM will lock all other pipes not > > > > > > > > related to > > > > > > > > the current pipe group, and keep > > > > > > > > handling the current pipe only until it sees the UNLOCK set > > > > > > > > then it > > > > > > > > will release all locked pipes. > > > > > > > > locked pipe will not fetch new descriptors even if it got > > > > > > > > event/events > > > > > > > > adding more descriptors for > > > > > > > > this pipe (locked pipe). > > > > > > > > > > > > > > > > No need to expose as an API to user because its internal to > > > > > > > > driver, so > > > > > > > > while preparing command descriptor > > > > > > > > just we have to update the LOCK/UNLOCK flag. > > > > > > > > > > > > So IIUC, no api right? it would be internal to driver..? > > > > > > > > > > Yes its totally internal to deriver. > > > > > > > > So no need for this patch then, right? > > > > > > This patch is needed , because if some hardware will shared between >
Re: [PATCH 2/2] soc: mediatek: pm-domains: Add domain_supply cap for mfg_async PD
On Mon, Feb 1, 2021 at 1:45 PM Bilal Wasim wrote:
>
> The mfg_async power domain in mt8173 is used to power up imgtec
> gpu. This domain requires the da9211 regulator to be enabled before
> the power domain can be enabled successfully.
>
> Signed-off-by: Bilal Wasim
Reviewed-by: Hsin-Yi Wang
> ---
> drivers/soc/mediatek/mt8173-pm-domains.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/soc/mediatek/mt8173-pm-domains.h
> b/drivers/soc/mediatek/mt8173-pm-domains.h
> index 3e8ee5dabb43..065b8195e7d6 100644
> --- a/drivers/soc/mediatek/mt8173-pm-domains.h
> +++ b/drivers/soc/mediatek/mt8173-pm-domains.h
> @@ -63,6 +63,7 @@ static const struct scpsys_domain_data
> scpsys_domain_data_mt8173[] = {
> .ctl_offs = SPM_MFG_ASYNC_PWR_CON,
> .sram_pdn_bits = GENMASK(11, 8),
> .sram_pdn_ack_bits = 0,
> + .caps = MTK_SCPD_DOMAIN_SUPPLY,
> },
> [MT8173_POWER_DOMAIN_MFG_2D] = {
> .sta_mask = PWR_STATUS_MFG_2D,
> --
> 2.25.1
>
Re: [PATCH 1/2] soc: mediatek: pm-domains: Use correct mask for bus_prot_clr
On Mon, Feb 1, 2021 at 1:45 PM Bilal Wasim wrote:
>
> When "bus_prot_reg_update" is false, the driver should use
> INFRA_TOPAXI_PROTECTEN for both setting and clearing the bus
> protection. However, the driver does not use this mask for
> clearing bus protection which causes failure when booting
> the imgtec gpu.
>
> Corrected and tested with mt8173 chromebook.
>
> Signed-off-by: Bilal Wasim
Reviewed-by: Hsin-Yi Wang
> ---
> drivers/soc/mediatek/mtk-pm-domains.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/soc/mediatek/mtk-pm-domains.h
> b/drivers/soc/mediatek/mtk-pm-domains.h
> index 141dc76054e6..7454c0b4f768 100644
> --- a/drivers/soc/mediatek/mtk-pm-domains.h
> +++ b/drivers/soc/mediatek/mtk-pm-domains.h
> @@ -60,7 +60,7 @@
> #define BUS_PROT_UPDATE_TOPAXI(_mask) \
> BUS_PROT_UPDATE(_mask, \
> INFRA_TOPAXI_PROTECTEN, \
> - INFRA_TOPAXI_PROTECTEN_CLR, \
> + INFRA_TOPAXI_PROTECTEN, \
> INFRA_TOPAXI_PROTECTSTA1)
>
> struct scpsys_bus_prot_data {
> --
> 2.25.1
>
Re: [PATCH 2/2] vdpa/mlx5: Restore the hardware used index after change map
On 2021/2/1 下午1:52, Eli Cohen wrote:
On Mon, Feb 01, 2021 at 11:36:23AM +0800, Jason Wang wrote:
On 2021/2/1 上午2:55, Eli Cohen wrote:
On Fri, Jan 29, 2021 at 11:49:45AM +0800, Jason Wang wrote:
On 2021/1/28 下午9:41, Eli Cohen wrote:
When a change of memory map occurs, the hardware resources are destroyed
and then re-created again with the new memory map. In such case, we need
to restore the hardware available and used indices. The driver failed to
restore the used index which is added here.
Fixes 1a86b377aa21 ("vdpa/mlx5: Add VDPA driver for supported mlx5 devices")
Signed-off-by: Eli Cohen
A question. Does this mean after a vq is suspended, the hw used index is not
equal to vq used index?
Surely there is just one "Used index" for a VQ. What I was trying to say
is that after the VQ is suspended, I read the used index by querying the
hardware. The read result is the used index that the hardware wrote to
memory.
Just to make sure I understand here. So it looks to me we had two index. The
first is the used index which is stored in the memory/virtqueue, the second
is the one that is stored by the device.
It is the structures defined in the virtio spec in 2.6.6 for the
available ring and 2.6.8 for the used ring. As you know these the
available ring is written to by the driver and read by the device. The
opposite happens for the used index.
Right, so for used index it was wrote by device. And the device should
have an internal used index value that is used to write to the used
ring. And the code is used to sync the device internal used index if I
understand this correctly.
The reason I need to restore the last known indices is for the new
hardware objects to sync on the last state and take over from there.
Right, after the vq suspending, the questions are:
1) is hardware internal used index might not be the same with the used
index in the virtqueue?
or
2) can we simply sync the virtqueue's used index to the hardware's used
index?
Thanks
After the I create the new hardware object, I need to tell it
what is the used index (and the available index) as a way to sync it
with the existing VQ.
For avail index I understand that the hardware index is not synced with the
avail index stored in the memory/virtqueue. The question is used index, if
the hardware one is not synced with the one in the virtqueue. It means after
vq is suspended, some requests is not completed by the hardware (e.g the
buffer were not put to used ring).
This may have implications to live migration, it means those unaccomplished
requests needs to be migrated to the destination and resubmitted to the
device. This looks not easy.
Thanks
This sync is especially important when a change of map occurs while the
VQ was already used (hence the indices are likely to be non zero). This
can be triggered by hot adding memory after the VQs have been used.
Thanks
---
drivers/vdpa/mlx5/net/mlx5_vnet.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/vdpa/mlx5/net/mlx5_vnet.c
b/drivers/vdpa/mlx5/net/mlx5_vnet.c
index 549ded074ff3..3fc8588cecae 100644
--- a/drivers/vdpa/mlx5/net/mlx5_vnet.c
+++ b/drivers/vdpa/mlx5/net/mlx5_vnet.c
@@ -87,6 +87,7 @@ struct mlx5_vq_restore_info {
u64 device_addr;
u64 driver_addr;
u16 avail_index;
+ u16 used_index;
bool ready;
struct vdpa_callback cb;
bool restore;
@@ -121,6 +122,7 @@ struct mlx5_vdpa_virtqueue {
u32 virtq_id;
struct mlx5_vdpa_net *ndev;
u16 avail_idx;
+ u16 used_idx;
int fw_state;
/* keep last in the struct */
@@ -804,6 +806,7 @@ static int create_virtqueue(struct mlx5_vdpa_net *ndev,
struct mlx5_vdpa_virtque
obj_context = MLX5_ADDR_OF(create_virtio_net_q_in, in, obj_context);
MLX5_SET(virtio_net_q_object, obj_context, hw_available_index,
mvq->avail_idx);
+ MLX5_SET(virtio_net_q_object, obj_context, hw_used_index,
mvq->used_idx);
MLX5_SET(virtio_net_q_object, obj_context, queue_feature_bit_mask_12_3,
get_features_12_3(ndev->mvdev.actual_features));
vq_ctx = MLX5_ADDR_OF(virtio_net_q_object, obj_context,
virtio_q_context);
@@ -1022,6 +1025,7 @@ static int connect_qps(struct mlx5_vdpa_net *ndev, struct
mlx5_vdpa_virtqueue *m
struct mlx5_virtq_attr {
u8 state;
u16 available_index;
+ u16 used_index;
};
static int query_virtqueue(struct mlx5_vdpa_net *ndev, struct
mlx5_vdpa_virtqueue *mvq,
@@ -1052,6 +1056,7 @@ static int query_virtqueue(struct mlx5_vdpa_net *ndev,
struct mlx5_vdpa_virtqueu
memset(attr, 0, sizeof(*attr));
attr->state = MLX5_GET(virtio_net_q_object, obj_context, state);
attr->available_index = MLX5_GET(virtio_net_q_object, obj_context,
hw_available_index);
+ attr->used_index = MLX5_GET(virtio_net_q_object, obj_context,
hw_used_index);
kfree(out);
return 0;
@@ -1602,6 +1607,7 @@ static
Re: [PATCH v2 1/3] usb: typec: Determine common SVDM Versions
On Mon, Feb 1, 2021 at 12:21 AM Guenter Roeck wrote:
>
> On 1/31/21 7:18 AM, Kyle Tso wrote:
> > Changes since v1:
> > - removed the "local" variables (svdm_version) in tcpm.c and
> > (altmodes/ucsi)/displayport.c
> > - added a member "svdm_version" in struct typec_capabilities indicating
> > the default SVDM version of the port
> > - added a member "common_svdm_ver" in struct typec_port indicating the
> > common SVDM version between the port and the partner
>
> I personally find the "common" in the variable and function names unnecessary.
> I would prefer using something like svdm_version instead of common_svdm_ver.
>
The reason for the common_ prefix is just for the readability.
That's totally fine with me to remove the prefix.
Will fix this in the next version.
> > diff --git a/drivers/usb/typec/tcpm/tcpm.c b/drivers/usb/typec/tcpm/tcpm.c
> > index 0afd8ef692e8..403a483645dd 100644
> > --- a/drivers/usb/typec/tcpm/tcpm.c
> > +++ b/drivers/usb/typec/tcpm/tcpm.c
> > @@ -1470,11 +1470,13 @@ static void tcpm_register_partner_altmodes(struct
> > tcpm_port *port)
> > }
> >
> > #define supports_modal(port)
> > PD_IDH_MODAL_SUPP((port)->partner_ident.id_header)
> > +#define common_svdm_ver(typec) (typec_get_common_svdm_version(typec))
>
> I think that is unnecessary and confusing. We now have
> typec_get_common_svdm_version()
> as well as common_svdm_ver() and COMMON_SVDM_VER() macros. I would suggest to
> just use
> the function name (and maybe drop the 'common_' prefix from it).
>
will fix this in the next version.
> > diff --git a/drivers/usb/typec/ucsi/ucsi.c b/drivers/usb/typec/ucsi/ucsi.c
> > index ca3f4194ad90..b8d693cc7b77 100644
> > --- a/drivers/usb/typec/ucsi/ucsi.c
> > +++ b/drivers/usb/typec/ucsi/ucsi.c
> > @@ -764,6 +764,7 @@ static void ucsi_handle_connector_change(struct
> > work_struct *work)
> >
> > if (con->status.change & UCSI_CONSTAT_CONNECT_CHANGE) {
> > typec_set_pwr_role(con->port, role);
> > + typec_set_common_svdm_version(con->port,
> > con->typec_cap.svdm_version);
> >
>
> I am a bit concerned that svdm_version is added to typec_capabilities but not
> consistently used by all drivers registering with typec. I am not sure I
> understand if and how the value in typec_capabilities is used by the typec
> core.
>
I am not sure about it as well :p
>From my POV, that is just the same nature as the "pd_revision" is in
typec_capabilities which means the capabilities the port has
regardless of the port partners.
The port needs to reset the operating mode to it's designed SVDM
version upon detach. I think typec_capabilities is a good place to
store this information.
What do you think?
BTW, the reset value of the variable "negotiated_rev" in tcpm/tcpm.c
looks weird to me.
It is reset to "PD_MAX_REV" in SNK_STARTUP and SRC_STARTUP.
However, the tcpm.c might not always support the max revision of PD.
IMO, the pd_revision in typec_capabilities is a better choice compared
to PD_MAX_REV.
> > diff --git a/include/linux/usb/typec.h b/include/linux/usb/typec.h
> > index 54475323f83b..df0cb1e595a1 100644
> > --- a/include/linux/usb/typec.h
> > +++ b/include/linux/usb/typec.h
> > @@ -206,12 +206,19 @@ struct typec_operations {
> >enum typec_port_type type);
> > };
> >
> > +enum usb_pd_svdm_ver {
> > + SVDM_VER_1_0 = 0,
> > + SVDM_VER_2_0 = 1,
> > + SVDM_VER_MAX = SVDM_VER_2_0,
> > +};
> > +
> > /*
> > * struct typec_capability - USB Type-C Port Capabilities
> > * @type: Supported power role of the port
> > * @data: Supported data role of the port
> > * @revision: USB Type-C Specification release. Binary coded decimal
> > * @pd_revision: USB Power Delivery Specification revision if supported
> > + * @svdm_version: USB PD Structured VDM version if supported
> > * @prefer_role: Initial role preference (DRP ports).
> > * @accessory: Supported Accessory Modes
> > * @fwnode: Optional fwnode of the port
> > @@ -225,6 +232,7 @@ struct typec_capability {
> > enum typec_port_datadata;
> > u16 revision; /* 0120H = "1.2" */
> > u16 pd_revision; /* 0300H = "3.0" */
> > + enum usb_pd_svdm_versvdm_version;
> > int prefer_role;
> > enum typec_accessoryaccessory[TYPEC_MAX_ACCESSORY];
> > unsigned intorientation_aware:1;
> > @@ -275,4 +283,6 @@ int typec_find_orientation(const char *name);
> > int typec_find_port_power_role(const char *name);
> > int typec_find_power_role(const char *name);
> > int typec_find_port_data_role(const char *name);
> > +void typec_set_common_svdm_version(struct typec_port *port, enum
> > usb_pd_svdm_ver);
> > +enum usb_pd_svdm_ver typec_get_common_svdm_version(struct typec_port
> > *port);
> > #endif /* __LINUX_USB_TYPEC_H */
> >
>
Thanks,
Kyle
Re: [PATCH] dmaengine: INTEL_LDMA should depend on X86
On 29-01-21, 14:17, Geert Uytterhoeven wrote: > The Intel Lightning Mountain (LGM) DMA controller is only present on > Intel Lightning Mountain SoCs. Hence add a dependency on X86, to > prevent asking the user about this driver when configuring a kernel > without Intel Lightning Mountain platform support. > > While at it, fix a misspelling of "Intel". :D Applied, thanks -- ~Vinod
[next PATCH] usb: xhci-mtk: skip dropping bandwidth of unchecked endpoints
For those unchecked endpoints, we don't allocate bandwidth for
them, so no need free the bandwidth, otherwise will decrease
the allocated bandwidth.
Meanwhile use xhci_dbg() instead of dev_dbg() to print logs and
rename bw_ep_list_new as bw_ep_chk_list.
Fixes: 1d69f9d901ef ("usb: xhci-mtk: fix unreleased bandwidth data")
Cc: stable
Signed-off-by: Chunfeng Yun
---
drivers/usb/host/xhci-mtk-sch.c | 61 ++---
drivers/usb/host/xhci-mtk.h | 4 ++-
2 files changed, 36 insertions(+), 29 deletions(-)
diff --git a/drivers/usb/host/xhci-mtk-sch.c b/drivers/usb/host/xhci-mtk-sch.c
index a313e75ff1c6..dee8a329076d 100644
--- a/drivers/usb/host/xhci-mtk-sch.c
+++ b/drivers/usb/host/xhci-mtk-sch.c
@@ -200,6 +200,7 @@ static struct mu3h_sch_ep_info *create_sch_ep(struct
usb_device *udev,
sch_ep->sch_tt = tt;
sch_ep->ep = ep;
+ INIT_LIST_HEAD(_ep->endpoint);
INIT_LIST_HEAD(_ep->tt_endpoint);
return sch_ep;
@@ -374,6 +375,7 @@ static void update_bus_bw(struct mu3h_sch_bw_info *sch_bw,
sch_ep->bw_budget_table[j];
}
}
+ sch_ep->allocated = used;
}
static int check_sch_tt(struct usb_device *udev,
@@ -542,6 +544,22 @@ static int check_sch_bw(struct usb_device *udev,
return 0;
}
+static void destroy_sch_ep(struct usb_device *udev,
+ struct mu3h_sch_bw_info *sch_bw, struct mu3h_sch_ep_info *sch_ep)
+{
+ /* only release ep bw check passed by check_sch_bw() */
+ if (sch_ep->allocated)
+ update_bus_bw(sch_bw, sch_ep, 0);
+
+ list_del(_ep->endpoint);
+
+ if (sch_ep->sch_tt) {
+ list_del(_ep->tt_endpoint);
+ drop_tt(udev);
+ }
+ kfree(sch_ep);
+}
+
static bool need_bw_sch(struct usb_host_endpoint *ep,
enum usb_device_speed speed, int has_tt)
{
@@ -584,7 +602,7 @@ int xhci_mtk_sch_init(struct xhci_hcd_mtk *mtk)
mtk->sch_array = sch_array;
- INIT_LIST_HEAD(>bw_ep_list_new);
+ INIT_LIST_HEAD(>bw_ep_chk_list);
return 0;
}
@@ -636,29 +654,12 @@ int xhci_mtk_add_ep_quirk(struct usb_hcd *hcd, struct
usb_device *udev,
setup_sch_info(udev, ep_ctx, sch_ep);
- list_add_tail(_ep->endpoint, >bw_ep_list_new);
+ list_add_tail(_ep->endpoint, >bw_ep_chk_list);
return 0;
}
EXPORT_SYMBOL_GPL(xhci_mtk_add_ep_quirk);
-static void xhci_mtk_drop_ep(struct xhci_hcd_mtk *mtk, struct usb_device *udev,
-struct mu3h_sch_ep_info *sch_ep)
-{
- struct xhci_hcd *xhci = hcd_to_xhci(mtk->hcd);
- int bw_index = get_bw_index(xhci, udev, sch_ep->ep);
- struct mu3h_sch_bw_info *sch_bw = >sch_array[bw_index];
-
- update_bus_bw(sch_bw, sch_ep, 0);
- list_del(_ep->endpoint);
-
- if (sch_ep->sch_tt) {
- list_del(_ep->tt_endpoint);
- drop_tt(udev);
- }
- kfree(sch_ep);
-}
-
void xhci_mtk_drop_ep_quirk(struct usb_hcd *hcd, struct usb_device *udev,
struct usb_host_endpoint *ep)
{
@@ -688,9 +689,8 @@ void xhci_mtk_drop_ep_quirk(struct usb_hcd *hcd, struct
usb_device *udev,
sch_bw = _array[bw_index];
list_for_each_entry_safe(sch_ep, tmp, _bw->bw_ep_list, endpoint) {
- if (sch_ep->ep == ep) {
- xhci_mtk_drop_ep(mtk, udev, sch_ep);
- }
+ if (sch_ep->ep == ep)
+ destroy_sch_ep(udev, sch_bw, sch_ep);
}
}
EXPORT_SYMBOL_GPL(xhci_mtk_drop_ep_quirk);
@@ -704,9 +704,9 @@ int xhci_mtk_check_bandwidth(struct usb_hcd *hcd, struct
usb_device *udev)
struct mu3h_sch_ep_info *sch_ep, *tmp;
int bw_index, ret;
- dev_dbg(>dev, "%s\n", __func__);
+ xhci_dbg(xhci, "%s() udev %s\n", __func__, dev_name(>dev));
- list_for_each_entry(sch_ep, >bw_ep_list_new, endpoint) {
+ list_for_each_entry(sch_ep, >bw_ep_chk_list, endpoint) {
bw_index = get_bw_index(xhci, udev, sch_ep->ep);
sch_bw = >sch_array[bw_index];
@@ -717,7 +717,7 @@ int xhci_mtk_check_bandwidth(struct usb_hcd *hcd, struct
usb_device *udev)
}
}
- list_for_each_entry_safe(sch_ep, tmp, >bw_ep_list_new, endpoint) {
+ list_for_each_entry_safe(sch_ep, tmp, >bw_ep_chk_list, endpoint) {
struct xhci_ep_ctx *ep_ctx;
struct usb_host_endpoint *ep = sch_ep->ep;
unsigned int ep_index = xhci_get_endpoint_index(>desc);
@@ -746,12 +746,17 @@ EXPORT_SYMBOL_GPL(xhci_mtk_check_bandwidth);
void xhci_mtk_reset_bandwidth(struct usb_hcd *hcd, struct usb_device *udev)
{
struct xhci_hcd_mtk *mtk = hcd_to_mtk(hcd);
+ struct xhci_hcd *xhci = hcd_to_xhci(hcd);
+ struct mu3h_sch_bw_info *sch_bw;
struct mu3h_sch_ep_info *sch_ep, *tmp;
+ int bw_index;
- dev_dbg(>dev, "%s\n", __func__);
+ xhci_dbg(xhci,
Re: [PATCH] dmaengine: ti: k3-psil: optimize struct psil_endpoint_config for size
On 29-01-21, 21:31, Grygorii Strashko wrote: > Optimize struct psil_endpoint_config for size by > - reordering fields > - grouping bitfields > - change mapped_channel_id type to s16 (32K channel is enough) > - default_flow_id type to s16 as it's assigned to -1 > > before: > textdata bssdec hex filename > 12654100 5211472 666904 1853247611ac87c vmlinux > > after: > 12654100 5208528 666904 1852953211abcfc vmlinux > > diff: 2944 bytes Applied, thanks -- ~Vinod
[PATCH net] net: lapb: Copy the skb before sending a packet
When sending a packet, we will prepend it with an LAPB header.
This modifies the shared parts of a cloned skb, so we should copy the
skb rather than just clone it, before we prepend the header.
In "Documentation/networking/driver.rst" (the 2nd point), it states
that drivers shouldn't modify the shared parts of a cloned skb when
transmitting.
The "dev_queue_xmit_nit" function in "net/core/dev.c", which is called
when an skb is being sent, clones the skb and sents the clone to
AF_PACKET sockets. Because the LAPB drivers first remove a 1-byte
pseudo-header before handing over the skb to us, if we don't copy the
skb before prepending the LAPB header, the first byte of the packets
received on AF_PACKET sockets can be corrupted.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: Martin Schiller
Signed-off-by: Xie He
---
net/lapb/lapb_out.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/lapb/lapb_out.c b/net/lapb/lapb_out.c
index 7a4d0715d1c3..a966d29c772d 100644
--- a/net/lapb/lapb_out.c
+++ b/net/lapb/lapb_out.c
@@ -82,7 +82,8 @@ void lapb_kick(struct lapb_cb *lapb)
skb = skb_dequeue(>write_queue);
do {
- if ((skbn = skb_clone(skb, GFP_ATOMIC)) == NULL) {
+ skbn = skb_copy(skb, GFP_ATOMIC);
+ if (!skbn) {
skb_queue_head(>write_queue, skb);
break;
}
--
2.27.0
Re: [PATCH v3 0/4] dmaengine: rcar-dmac: Add support for R-Car V3U
On 28-01-21, 09:44, Geert Uytterhoeven wrote: > Hi Vinod, > > This patch series adds support for the Direct Memory Access Controller > variant in the Renesas R-Car V3U (R8A779A0) SoC, to both DT bindings and > driver. Applied all, thanks -- ~Vinod
[PATCH] mmc: core: Use host instead of card argument to mmc_spi_send_csd()
From: Yue Hu
Since mmc_send_cxd_data() does not care card if opcode is MMC_SEND_CSD.
Signed-off-by: Yue Hu
---
drivers/mmc/core/mmc_ops.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/mmc/core/mmc_ops.c b/drivers/mmc/core/mmc_ops.c
index baa6314..265d95e 100644
--- a/drivers/mmc/core/mmc_ops.c
+++ b/drivers/mmc/core/mmc_ops.c
@@ -296,7 +296,7 @@ int mmc_set_relative_addr(struct mmc_card *card)
return 0;
}
-static int mmc_spi_send_csd(struct mmc_card *card, u32 *csd)
+static int mmc_spi_send_csd(struct mmc_host *host, u32 *csd)
{
int ret, i;
__be32 *csd_tmp;
@@ -305,7 +305,7 @@ static int mmc_spi_send_csd(struct mmc_card *card, u32 *csd)
if (!csd_tmp)
return -ENOMEM;
- ret = mmc_send_cxd_data(card, card->host, MMC_SEND_CSD, csd_tmp, 16);
+ ret = mmc_send_cxd_data(NULL, host, MMC_SEND_CSD, csd_tmp, 16);
if (ret)
goto err;
@@ -320,7 +320,7 @@ static int mmc_spi_send_csd(struct mmc_card *card, u32 *csd)
int mmc_send_csd(struct mmc_card *card, u32 *csd)
{
if (mmc_host_is_spi(card->host))
- return mmc_spi_send_csd(card, csd);
+ return mmc_spi_send_csd(card->host, csd);
return mmc_send_cxd_native(card->host, card->rca << 16, csd,
MMC_SEND_CSD);
--
1.9.1
Re: [PATCH] watchdog: qcom: Remove incorrect usage of QCOM_WDT_ENABLE_IRQ
On 2021-01-31 22:33, Jorge Ramirez-Ortiz, Foundries wrote:
On 28/01/21, Sai Prakash Ranjan wrote:
On 2021-01-28 13:49, Jorge Ramirez-Ortiz, Foundries wrote:
> On 26/01/21, Sai Prakash Ranjan wrote:
> > As per register documentation, QCOM_WDT_ENABLE_IRQ which is BIT(1)
> > of watchdog control register is wakeup interrupt enable bit and
> > not related to bark interrupt at all, BIT(0) is used for that.
> > So remove incorrect usage of this bit when supporting bark irq for
> > pre-timeout notification. Currently with this bit set and bark
> > interrupt specified, pre-timeout notification and/or watchdog
> > reset/bite does not occur.
> >
> > Fixes: 36375491a439 ("watchdog: qcom: support pre-timeout when the
> > bark irq is available")
> > Cc: sta...@vger.kernel.org
> > Signed-off-by: Sai Prakash Ranjan
> > ---
> >
> > Reading the conversations from when qcom pre-timeout support was
> > added [1], Bjorn already had mentioned it was not right to touch this
> > bit, not sure which SoC the pre-timeout was tested on at that time,
> > but I have tested this on SDM845, SM8150, SC7180 and watchdog bark
> > and bite does not occur with enabling this bit with the bark irq
> > specified in DT.
>
> this was tested on QCS404. have you validated there? unfortunately I
> no longer have access to that hardware or the documentation
>
I didn't validate on qcs404 yet since I didn't have access to it.
But now that you mention it, let me arrange for a setup and test it
there as well. Note: I did not see bark irq entry in upstream qcs404
dtsi, so you must have had some local change when you tested?
TBH I dont quite remember. I suppose that if those with access to the
documents and hardware are OK with this change then it shouldnt cause
regressions (I just cant check from my end)
No worries, I got the documentation access now and it is the same as
other SoCs which I have tested above, meaning the BIT(1) is not related
to bark irq. I am arranging a setup as well now, it took some time as
I don't work on QCS* chipsets but I can confirm by this week.
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 2/2] vdpa/mlx5: Restore the hardware used index after change map
On Mon, Feb 01, 2021 at 11:36:23AM +0800, Jason Wang wrote:
>
> On 2021/2/1 上午2:55, Eli Cohen wrote:
> > On Fri, Jan 29, 2021 at 11:49:45AM +0800, Jason Wang wrote:
> > > On 2021/1/28 下午9:41, Eli Cohen wrote:
> > > > When a change of memory map occurs, the hardware resources are destroyed
> > > > and then re-created again with the new memory map. In such case, we need
> > > > to restore the hardware available and used indices. The driver failed to
> > > > restore the used index which is added here.
> > > >
> > > > Fixes 1a86b377aa21 ("vdpa/mlx5: Add VDPA driver for supported mlx5
> > > > devices")
> > > > Signed-off-by: Eli Cohen
> > >
> > > A question. Does this mean after a vq is suspended, the hw used index is
> > > not
> > > equal to vq used index?
> > Surely there is just one "Used index" for a VQ. What I was trying to say
> > is that after the VQ is suspended, I read the used index by querying the
> > hardware. The read result is the used index that the hardware wrote to
> > memory.
>
>
> Just to make sure I understand here. So it looks to me we had two index. The
> first is the used index which is stored in the memory/virtqueue, the second
> is the one that is stored by the device.
>
It is the structures defined in the virtio spec in 2.6.6 for the
available ring and 2.6.8 for the used ring. As you know these the
available ring is written to by the driver and read by the device. The
opposite happens for the used index.
The reason I need to restore the last known indices is for the new
hardware objects to sync on the last state and take over from there.
>
> > After the I create the new hardware object, I need to tell it
> > what is the used index (and the available index) as a way to sync it
> > with the existing VQ.
>
>
> For avail index I understand that the hardware index is not synced with the
> avail index stored in the memory/virtqueue. The question is used index, if
> the hardware one is not synced with the one in the virtqueue. It means after
> vq is suspended, some requests is not completed by the hardware (e.g the
> buffer were not put to used ring).
>
> This may have implications to live migration, it means those unaccomplished
> requests needs to be migrated to the destination and resubmitted to the
> device. This looks not easy.
>
> Thanks
>
>
> >
> > This sync is especially important when a change of map occurs while the
> > VQ was already used (hence the indices are likely to be non zero). This
> > can be triggered by hot adding memory after the VQs have been used.
> >
> > > Thanks
> > >
> > >
> > > > ---
> > > >drivers/vdpa/mlx5/net/mlx5_vnet.c | 7 +++
> > > >1 file changed, 7 insertions(+)
> > > >
> > > > diff --git a/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > > > b/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > > > index 549ded074ff3..3fc8588cecae 100644
> > > > --- a/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > > > +++ b/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > > > @@ -87,6 +87,7 @@ struct mlx5_vq_restore_info {
> > > > u64 device_addr;
> > > > u64 driver_addr;
> > > > u16 avail_index;
> > > > + u16 used_index;
> > > > bool ready;
> > > > struct vdpa_callback cb;
> > > > bool restore;
> > > > @@ -121,6 +122,7 @@ struct mlx5_vdpa_virtqueue {
> > > > u32 virtq_id;
> > > > struct mlx5_vdpa_net *ndev;
> > > > u16 avail_idx;
> > > > + u16 used_idx;
> > > > int fw_state;
> > > > /* keep last in the struct */
> > > > @@ -804,6 +806,7 @@ static int create_virtqueue(struct mlx5_vdpa_net
> > > > *ndev, struct mlx5_vdpa_virtque
> > > > obj_context = MLX5_ADDR_OF(create_virtio_net_q_in, in,
> > > > obj_context);
> > > > MLX5_SET(virtio_net_q_object, obj_context, hw_available_index,
> > > > mvq->avail_idx);
> > > > + MLX5_SET(virtio_net_q_object, obj_context, hw_used_index,
> > > > mvq->used_idx);
> > > > MLX5_SET(virtio_net_q_object, obj_context,
> > > > queue_feature_bit_mask_12_3,
> > > > get_features_12_3(ndev->mvdev.actual_features));
> > > > vq_ctx = MLX5_ADDR_OF(virtio_net_q_object, obj_context,
> > > > virtio_q_context);
> > > > @@ -1022,6 +1025,7 @@ static int connect_qps(struct mlx5_vdpa_net
> > > > *ndev, struct mlx5_vdpa_virtqueue *m
> > > >struct mlx5_virtq_attr {
> > > > u8 state;
> > > > u16 available_index;
> > > > + u16 used_index;
> > > >};
> > > >static int query_virtqueue(struct mlx5_vdpa_net *ndev, struct
> > > > mlx5_vdpa_virtqueue *mvq,
> > > > @@ -1052,6 +1056,7 @@ static int query_virtqueue(struct mlx5_vdpa_net
> > > > *ndev, struct mlx5_vdpa_virtqueu
> > > > memset(attr, 0, sizeof(*attr));
> > > > attr->state = MLX5_GET(virtio_net_q_object, obj_context, state);
> > > > attr->available_index = MLX5_GET(virtio_net_q_object,
> > > > obj_context, hw_available_index);
> > > > + attr->used_index = MLX5_GET(virtio_net_q_object,
Re: [PATCH RFC v2 08/10] vdpa: add vdpa simulator for block device
On 2021/1/28 下午10:41, Stefano Garzarella wrote:
From: Max Gurtovoy
This will allow running vDPA for virtio block protocol.
Signed-off-by: Max Gurtovoy
[sgarzare: various cleanups/fixes]
Signed-off-by: Stefano Garzarella
Acked-by: Jason Wang
---
v2:
- rebased on top of other changes (dev_attr, get_config(), notify(), etc.)
- memset to 0 the config structure in vdpasim_blk_get_config()
- used vdpasim pointer in vdpasim_blk_get_config()
v1:
- Removed unused headers
- Used cpu_to_vdpasim*() to store config fields
- Replaced 'select VDPA_SIM' with 'depends on VDPA_SIM' since selected
option can not depend on other [Jason]
- Start with a single queue for now [Jason]
- Add comments to memory barriers
---
drivers/vdpa/vdpa_sim/vdpa_sim_blk.c | 145 +++
drivers/vdpa/Kconfig | 7 ++
drivers/vdpa/vdpa_sim/Makefile | 1 +
3 files changed, 153 insertions(+)
create mode 100644 drivers/vdpa/vdpa_sim/vdpa_sim_blk.c
diff --git a/drivers/vdpa/vdpa_sim/vdpa_sim_blk.c
b/drivers/vdpa/vdpa_sim/vdpa_sim_blk.c
new file mode 100644
index ..999f9ca0b628
--- /dev/null
+++ b/drivers/vdpa/vdpa_sim/vdpa_sim_blk.c
@@ -0,0 +1,145 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * VDPA simulator for block device.
+ *
+ * Copyright (c) 2020, Mellanox Technologies. All rights reserved.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "vdpa_sim.h"
+
+#define DRV_VERSION "0.1"
+#define DRV_AUTHOR "Max Gurtovoy "
+#define DRV_DESC "vDPA Device Simulator for block device"
+#define DRV_LICENSE "GPL v2"
+
+#define VDPASIM_BLK_FEATURES (VDPASIM_FEATURES | \
+(1ULL << VIRTIO_BLK_F_SIZE_MAX) | \
+(1ULL << VIRTIO_BLK_F_SEG_MAX) | \
+(1ULL << VIRTIO_BLK_F_BLK_SIZE) | \
+(1ULL << VIRTIO_BLK_F_TOPOLOGY) | \
+(1ULL << VIRTIO_BLK_F_MQ))
+
+#define VDPASIM_BLK_CAPACITY 0x4
+#define VDPASIM_BLK_SIZE_MAX 0x1000
+#define VDPASIM_BLK_SEG_MAX32
+#define VDPASIM_BLK_VQ_NUM 1
+
+static struct vdpasim *vdpasim_blk_dev;
+
+static void vdpasim_blk_work(struct work_struct *work)
+{
+ struct vdpasim *vdpasim = container_of(work, struct vdpasim, work);
+ u8 status = VIRTIO_BLK_S_OK;
+ int i;
+
+ spin_lock(>lock);
+
+ if (!(vdpasim->status & VIRTIO_CONFIG_S_DRIVER_OK))
+ goto out;
+
+ for (i = 0; i < VDPASIM_BLK_VQ_NUM; i++) {
+ struct vdpasim_virtqueue *vq = >vqs[i];
+
+ if (!vq->ready)
+ continue;
+
+ while (vringh_getdesc_iotlb(>vring, >out_iov,
+ >in_iov, >head,
+ GFP_ATOMIC) > 0) {
+ int write;
+
+ vq->in_iov.i = vq->in_iov.used - 1;
+ write = vringh_iov_push_iotlb(>vring, >in_iov,
+ , 1);
+ if (write <= 0)
+ break;
+
+ /* Make sure data is wrote before advancing index */
+ smp_wmb();
+
+ vringh_complete_iotlb(>vring, vq->head, write);
+
+ /* Make sure used is visible before rasing the
interrupt. */
+ smp_wmb();
+
+ local_bh_disable();
+ if (vringh_need_notify_iotlb(>vring) > 0)
+ vringh_notify(>vring);
+ local_bh_enable();
+ }
+ }
+out:
+ spin_unlock(>lock);
+}
+
+static void vdpasim_blk_get_config(struct vdpasim *vdpasim, void *config)
+{
+ struct virtio_blk_config *blk_config =
+ (struct virtio_blk_config *)config;
+
+ memset(config, 0, sizeof(struct virtio_blk_config));
+
+ blk_config->capacity = cpu_to_vdpasim64(vdpasim, VDPASIM_BLK_CAPACITY);
+ blk_config->size_max = cpu_to_vdpasim32(vdpasim, VDPASIM_BLK_SIZE_MAX);
+ blk_config->seg_max = cpu_to_vdpasim32(vdpasim, VDPASIM_BLK_SEG_MAX);
+ blk_config->num_queues = cpu_to_vdpasim16(vdpasim, VDPASIM_BLK_VQ_NUM);
+ blk_config->min_io_size = cpu_to_vdpasim16(vdpasim, 1);
+ blk_config->opt_io_size = cpu_to_vdpasim32(vdpasim, 1);
+ blk_config->blk_size = cpu_to_vdpasim32(vdpasim, SECTOR_SIZE);
+}
+
+static int __init vdpasim_blk_init(void)
+{
+ struct vdpasim_dev_attr dev_attr = {};
+ int ret;
+
+ dev_attr.id = VIRTIO_ID_BLOCK;
+ dev_attr.supported_features = VDPASIM_BLK_FEATURES;
+ dev_attr.nvqs = VDPASIM_BLK_VQ_NUM;
+ dev_attr.config_size = sizeof(struct virtio_blk_config);
+ dev_attr.get_config = vdpasim_blk_get_config;
+ dev_attr.work_fn = vdpasim_blk_work;
+
[PATCH v2 0/2] resolve read hystersis return invalid argument issue for hid sensors
This patch series move get sensitivity attribute to common layer and resolve read hystersis return invalid argument issue for hid sensors als, incli-3d, rotation, and press on intel ISH Platform. --- v2: - separate the add relative sensitivity patch to the next patch series. Ye Xiang (2): iio: hid-sensors: Move get sensitivity attribute to hid-sensor-common hid-sensors: Add more data fields for sensitivity checking drivers/iio/accel/hid-sensor-accel-3d.c | 23 ++--- .../hid-sensors/hid-sensor-attributes.c | 17 +- drivers/iio/gyro/hid-sensor-gyro-3d.c | 19 --- drivers/iio/humidity/hid-sensor-humidity.c| 16 -- drivers/iio/light/hid-sensor-als.c| 20 +--- drivers/iio/light/hid-sensor-prox.c | 27 +--- drivers/iio/magnetometer/hid-sensor-magn-3d.c | 32 ++- drivers/iio/orientation/hid-sensor-incl-3d.c | 20 +--- drivers/iio/orientation/hid-sensor-rotation.c | 24 ++ .../position/hid-sensor-custom-intel-hinge.c | 20 drivers/iio/pressure/hid-sensor-press.c | 20 +--- .../iio/temperature/hid-sensor-temperature.c | 16 -- drivers/rtc/rtc-hid-sensor-time.c | 4 ++- include/linux/hid-sensor-hub.h| 4 ++- 14 files changed, 111 insertions(+), 151 deletions(-) -- 2.17.1
