[PATCH 1/2] HID: input: make sure the wheel high resolution multiplier is set
Some old mice have a tendency to not accept the high resolution multiplier.
They reply with a -EPIPE which was previously ignored.
Force the call to resolution multiplier to be synchronous and actually
check for the answer. If this fails, consider the mouse like a normal one.
Fixes: 2dc702c991e377 ("HID: input: use the Resolution Multiplier for
high-resolution scrolling")
Link: https://bugzilla.redhat.com/show_bug.cgi?id=1700071
Reported-and-tested-by: James Feeney
Cc: sta...@vger.kernel.org # v5.0+
Signed-off-by: Benjamin Tissoires
---
drivers/hid/hid-core.c | 7 +++-
drivers/hid/hid-input.c | 81 +
include/linux/hid.h | 2 +-
3 files changed, 56 insertions(+), 34 deletions(-)
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index 76464aabd20c..92387fc0bf18 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -1637,7 +1637,7 @@ static struct hid_report *hid_get_report(struct
hid_report_enum *report_enum,
* Implement a generic .request() callback, using .raw_request()
* DO NOT USE in hid drivers directly, but through hid_hw_request instead.
*/
-void __hid_request(struct hid_device *hid, struct hid_report *report,
+int __hid_request(struct hid_device *hid, struct hid_report *report,
int reqtype)
{
char *buf;
@@ -1646,7 +1646,7 @@ void __hid_request(struct hid_device *hid, struct
hid_report *report,
buf = hid_alloc_report_buf(report, GFP_KERNEL);
if (!buf)
- return;
+ return -ENOMEM;
len = hid_report_len(report);
@@ -1663,8 +1663,11 @@ void __hid_request(struct hid_device *hid, struct
hid_report *report,
if (reqtype == HID_REQ_GET_REPORT)
hid_input_report(hid, report->type, buf, ret, 0);
+ ret = 0;
+
out:
kfree(buf);
+ return ret;
}
EXPORT_SYMBOL_GPL(__hid_request);
diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c
index 1fce0076e7dc..fadf76f0a386 100644
--- a/drivers/hid/hid-input.c
+++ b/drivers/hid/hid-input.c
@@ -1542,52 +1542,71 @@ static void hidinput_close(struct input_dev *dev)
hid_hw_close(hid);
}
-static void hidinput_change_resolution_multipliers(struct hid_device *hid)
+static bool __hidinput_change_resolution_multipliers(struct hid_device *hid,
+ struct hid_report *report, bool use_logical_max)
{
- struct hid_report_enum *rep_enum;
- struct hid_report *rep;
struct hid_usage *usage;
+ bool update_needed = false;
int i, j;
- rep_enum = >report_enum[HID_FEATURE_REPORT];
- list_for_each_entry(rep, _enum->report_list, list) {
- bool update_needed = false;
+ if (report->maxfield == 0)
+ return false;
- if (rep->maxfield == 0)
- continue;
+ /*
+* If we have more than one feature within this report we
+* need to fill in the bits from the others before we can
+* overwrite the ones for the Resolution Multiplier.
+*/
+ if (report->maxfield > 1) {
+ hid_hw_request(hid, report, HID_REQ_GET_REPORT);
+ hid_hw_wait(hid);
+ }
- /*
-* If we have more than one feature within this report we
-* need to fill in the bits from the others before we can
-* overwrite the ones for the Resolution Multiplier.
+ for (i = 0; i < report->maxfield; i++) {
+ __s32 value = use_logical_max ?
+ report->field[i]->logical_maximum :
+ report->field[i]->logical_minimum;
+
+ /* There is no good reason for a Resolution
+* Multiplier to have a count other than 1.
+* Ignore that case.
*/
- if (rep->maxfield > 1) {
- hid_hw_request(hid, rep, HID_REQ_GET_REPORT);
- hid_hw_wait(hid);
- }
+ if (report->field[i]->report_count != 1)
+ continue;
- for (i = 0; i < rep->maxfield; i++) {
- __s32 logical_max = rep->field[i]->logical_maximum;
+ for (j = 0; j < report->field[i]->maxusage; j++) {
+ usage = >field[i]->usage[j];
- /* There is no good reason for a Resolution
-* Multiplier to have a count other than 1.
-* Ignore that case.
-*/
- if (rep->field[i]->report_count != 1)
+ if (usage->hid != HID_GD_RESOLUTION_MULTIPLIER)
continue;
- for (j = 0; j < rep->field[i]->maxusage; j++) {
- usage = >field[i]->usage[j];
+ *report->field[i]->value = value;
+
Re: mmotm 2019-04-19-14-53 uploaded (objtool)
On 4/23/19 1:24 AM, Peter Zijlstra wrote:
> On Fri, Apr 19, 2019 at 09:36:46PM -0700, Randy Dunlap wrote:
>> On 4/19/19 2:53 PM, a...@linux-foundation.org wrote:
>>> The mm-of-the-moment snapshot 2019-04-19-14-53 has been uploaded to
>>>
>>>http://www.ozlabs.org/~akpm/mmotm/
>>>
>>> mmotm-readme.txt says
>>>
>>> README for mm-of-the-moment:
>>>
>>> http://www.ozlabs.org/~akpm/mmotm/
>>>
>>> This is a snapshot of my -mm patch queue. Uploaded at random hopefully
>>> more than once a week.
>>
>> on x86_64:
>>
>> CC lib/strncpy_from_user.o
>> lib/strncpy_from_user.o: warning: objtool: strncpy_from_user()+0x315: call
>> to __ubsan_handle_add_overflow() with UACCESS enabled
>> CC lib/strnlen_user.o
>> lib/strnlen_user.o: warning: objtool: strnlen_user()+0x337: call to
>> __ubsan_handle_sub_overflow() with UACCESS enabled
>
> Lemme guess, you're using GCC < 8 ? That had a bug where UBSAN
> considered signed overflow UB when using -fno-strict-overflow or
> -fwrapv.
Correct. 7.4.0.
Patch works for me. Thanks.
Acked-by: Randy Dunlap # build-tested
> Now, we could of course allow this symbol, but I found only the below
> was required to make allyesconfig build without issue.
>
> Andy, Linus?
>
> (note: the __put_user thing is from this one:
>
> drivers/gpu/drm/i915/i915_gem_execbuffer.c: if (unlikely(__put_user(offset,
> [r-stack].presumed_offset))) {
>
> where (ptr) ends up non-trivial due to UBSAN)
>
> ---
>
> diff --git a/arch/x86/include/asm/uaccess.h b/arch/x86/include/asm/uaccess.h
> index 22ba683afdc2..c82abd6e4ca3 100644
> --- a/arch/x86/include/asm/uaccess.h
> +++ b/arch/x86/include/asm/uaccess.h
> @@ -427,10 +427,11 @@ do {
> \
> ({ \
> __label__ __pu_label; \
> int __pu_err = -EFAULT; \
> - __typeof__(*(ptr)) __pu_val;\
> - __pu_val = x; \
> + __typeof__(*(ptr)) __pu_val = (x); \
> + __typeof__(ptr) __pu_ptr = (ptr); \
> + __typeof__(size) __pu_size = (size);\
> __uaccess_begin(); \
> - __put_user_size(__pu_val, (ptr), (size), __pu_label); \
> + __put_user_size(__pu_val, __pu_ptr, __pu_size, __pu_label); \
> __pu_err = 0; \
> __pu_label: \
> __uaccess_end();\
> diff --git a/lib/strncpy_from_user.c b/lib/strncpy_from_user.c
> index 58eacd41526c..07045bc4872e 100644
> --- a/lib/strncpy_from_user.c
> +++ b/lib/strncpy_from_user.c
> @@ -26,7 +26,7 @@
> static inline long do_strncpy_from_user(char *dst, const char __user *src,
> long count, unsigned long max)
> {
> const struct word_at_a_time constants = WORD_AT_A_TIME_CONSTANTS;
> - long res = 0;
> + unsigned long res = 0;
>
> /*
>* Truncate 'max' to the user-specified limit, so that
> diff --git a/lib/strnlen_user.c b/lib/strnlen_user.c
> index 1c1a1b0e38a5..0729378ad3e9 100644
> --- a/lib/strnlen_user.c
> +++ b/lib/strnlen_user.c
> @@ -28,7 +28,7 @@
> static inline long do_strnlen_user(const char __user *src, unsigned long
> count, unsigned long max)
> {
> const struct word_at_a_time constants = WORD_AT_A_TIME_CONSTANTS;
> - long align, res = 0;
> + unsigned long align, res = 0;
> unsigned long c;
>
> /*
>
--
~Randy
Re: [PATCH v2 12/12] thermal: tegra: enable OC hw throttle
On Thu, Feb 21, 2019 at 06:18:47PM +0800, Wei Ni wrote:
> Parse Over Current settings from DT and program them to
> generate interrupts. Also enable hw throttling whenever
> there are OC events. Log the OC events as debug messages.
>
> Signed-off-by: Wei Ni
I applied this series except for this specific patch which:
a. does not apply clean
b. does not compile.
Please rebase on top of my -linus branch and resend this. remember to
checkpatch and compile and boot test before sending.
> ---
> drivers/thermal/tegra/soctherm.c | 130
> ---
> 1 file changed, 120 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/thermal/tegra/soctherm.c
> b/drivers/thermal/tegra/soctherm.c
> index b8c66368e54e..6e3f329d1ac4 100644
> --- a/drivers/thermal/tegra/soctherm.c
> +++ b/drivers/thermal/tegra/soctherm.c
> @@ -106,9 +106,26 @@
> #define STATS_CTL_CLR_UP 0x2
> #define STATS_CTL_EN_UP 0x1
>
> +#define OC1_CFG 0x310
> +#define OC1_CFG_LONG_LATENCY_MASKBIT(6)
> +#define OC1_CFG_HW_RESTORE_MASK BIT(5)
> +#define OC1_CFG_PWR_GOOD_MASK_MASK BIT(4)
> +#define OC1_CFG_THROTTLE_MODE_MASK (0x3 << 2)
> +#define OC1_CFG_ALARM_POLARITY_MASK BIT(1)
> +#define OC1_CFG_EN_THROTTLE_MASK BIT(0)
> +
> +#define OC1_CNT_THRESHOLD0x314
> +#define OC1_THROTTLE_PERIOD 0x318
> +#define OC1_ALARM_COUNT 0x31c
> +#define OC1_FILTER 0x320
> +#define OC1_STATS0x3a8
> +
> #define OC_INTR_STATUS 0x39c
> #define OC_INTR_ENABLE 0x3a0
> #define OC_INTR_DISABLE 0x3a4
> +#define OC_STATS_CTL 0x3c4
> +#define OC_STATS_CTL_CLR_ALL 0x2
> +#define OC_STATS_CTL_EN_ALL 0x1
>
> #define OC_INTR_OC1_MASK BIT(0)
> #define OC_INTR_OC2_MASK BIT(1)
> @@ -207,6 +224,25 @@
> #define THROT_DELAY_CTRL(throt) (THROT_DELAY_LITE + \
> (THROT_OFFSET * throt))
>
> +#define ALARM_OFFSET 0x14
> +#define ALARM_CFG(throt) (OC1_CFG + \
> + (ALARM_OFFSET * (throt - THROTTLE_OC1)))
> +
> +#define ALARM_CNT_THRESHOLD(throt) (OC1_CNT_THRESHOLD + \
> + (ALARM_OFFSET * (throt - THROTTLE_OC1)))
> +
> +#define ALARM_THROTTLE_PERIOD(throt) (OC1_THROTTLE_PERIOD + \
> + (ALARM_OFFSET * (throt - THROTTLE_OC1)))
> +
> +#define ALARM_ALARM_COUNT(throt) (OC1_ALARM_COUNT + \
> + (ALARM_OFFSET * (throt - THROTTLE_OC1)))
> +
> +#define ALARM_FILTER(throt) (OC1_FILTER + \
> + (ALARM_OFFSET * (throt - THROTTLE_OC1)))
> +
> +#define ALARM_STATS(throt) (OC1_STATS + \
> + (4 * (throt - THROTTLE_OC1)))
> +
> /* get CCROC_THROT_PSKIP_xxx offset per HIGH/MED/LOW vect*/
> #define CCROC_THROT_OFFSET 0x0c
> #define CCROC_THROT_PSKIP_CTRL_CPU_REG(vect)(CCROC_THROT_PSKIP_CTRL_CPU
> + \
> @@ -218,6 +254,9 @@
> #define THERMCTL_LVL_REGS_SIZE 0x20
> #define THERMCTL_LVL_REG(rg, lv) ((rg) + ((lv) * THERMCTL_LVL_REGS_SIZE))
>
> +#define OC_THROTTLE_MODE_DISABLED0
> +#define OC_THROTTLE_MODE_BRIEF 2
> +
> static const int min_low_temp = -127000;
> static const int max_high_temp = 127000;
>
> @@ -266,6 +305,15 @@ struct tegra_thermctl_zone {
> const struct tegra_tsensor_group *sg;
> };
>
> +struct soctherm_oc_cfg {
> + u32 active_low;
> + u32 throt_period;
> + u32 alarm_cnt_thresh;
> + u32 alarm_filter;
> + u32 mode;
> + bool intr_en;
> +};
> +
> struct soctherm_throt_cfg {
> const char *name;
> unsigned int id;
> @@ -273,6 +321,7 @@ struct soctherm_throt_cfg {
> u8 cpu_throt_level;
> u32 cpu_throt_depth;
> u32 gpu_throt_level;
> + struct soctherm_oc_cfg oc_cfg;
> struct thermal_cooling_device *cdev;
> bool init;
> };
> @@ -715,7 +764,7 @@ static int tegra_soctherm_set_hwtrips(struct device *dev,
> return 0;
> }
>
> - for (i = 0; i < THROTTLE_SIZE; i++) {
> + for (i = 0; i < THROTTLE_OC1; i++) {
> struct thermal_cooling_device *cdev;
>
> if (!ts->throt_cfgs[i].init)
> @@ -1537,6 +1586,32 @@ static int soctherm_thermtrips_parse(struct
> platform_device *pdev)
> return 0;
> }
>
> +static void soctherm_oc_cfg_parse(struct device *dev,
> + struct device_node *np_oc,
> + struct soctherm_throt_cfg *stc)
> +{
> + u32
Re: [PATCH 3/6] y2038: linux: Provide __clock_settime64 implementation
Hi Arnd and Stepan, > On Mon, Apr 22, 2019 at 11:07 AM Stepan Golosunov > wrote: > > 20.04.2019 в 13:21:12 +0200 Lukasz Majewski написал: > > Is it? The kernel (5.1-rc6) code looks to me like > > > > /* Zero out the padding for 32 bit systems or in compat > > mode */ if (false && false) > > kts.tv_nsec &= 0xUL; > > > > in 32-bit kernels. And like > > > > if (false && true) > > kts.tv_nsec &= 0xUL; > > > > for COMPAT syscalls in 64-bit kernels. > > > > It should probably be changed into > > > > if (!IS_ENABLED(CONFIG_64BIT) || in_compat_syscall()) > > kts.tv_nsec &= 0xUL; > > > > (Or into something like > > > > if (!IS_ENABLED(CONFIG_64BIT) || in_compat_syscall() > > && !COMPAT_USE_64BIT_TIME) kts.tv_nsec &= 0xUL; > > > > if x32 should retain 64-bit tv_nsec.) > > I think the problem is that at some point CONFIG_64BIT_TIME was > meant to be enabled on both 32-bit and 64-bit kernels, but the > definition got changed along the way. > > We probably just want > > if (in_compat_syscall() ) >kts.tv_nsec &= 0xUL; > > here, which would then truncate the nanoseconds for all compat > mode including x32. For native mode, we don't need to truncate > it, since timespec64 has a 32-bit 'tv_nsec' field in the kernel. > > > > However, I would prefer not to pass random data > > > to the kernel, and hence I do clear it up explicitly in glibc. > > > > If the kernel does not ignore padding on its own, then zeroing it > > out is required everywhere timespec is passed to kernel, including > > via code not known to glibc. (Does anyone promise that there won't > > be any ioctls that accept timespec, for example?) That seems to be > > error-prone (and might requre copying larger structes). > > > > On the other hand, if kernel 5.1+ ignores padding as intended there > > is no need to create additional copy of structs in glibc code that > > calls into clock_settime64 (or into timer_settime64 that accepts > > larger struct, for example). Ok, I think I see your point: - As kernel is ignoring padding, there is no need to copy the structure and set the padding to 0. However, in patch: [PATCH 1/6] y2038: Introduce internal for glibc struct __timespec64 The internal (for glibc) structure has been introduced - it has 32 bit tv_nsec and 32 bit padding. As it is passed to the kernel - the padding can have random values and hence shall be zeroed before passing to the kernel. The rationale for 32 bit tv_nsec is to be as close as possible to what is exported by glibc (64 bit tv_sec and 32 bit tv_nsec) for Y2038. I'm now wondering if it would be better to have glibc internal struct __timespec64 having both fields 64 bit (as it would be easier to pass it to Linux). > > The intention is that the kernel ignores the padding. If you find > another place in the kernel that forget that, we should fix it. > Thanks Arnd for clarification. > > > > And, hmm, is CONFIG_64BIT_TIME enabled anywhere? > > > > I guess that the remaining CONFIG_64BIT_TIME in kernel should be > > replaced with CONFIG_COMPAT_32BIT_TIME or removed. > > We should remove CONFIG_64BIT_TIME. CONFIG_COMPAT_32BIT_TIME > is still needed to identify architectures that don't have it, in > particular riscv32. > >Arnd Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de pgp5dnCMQ6Hqp.pgp Description: OpenPGP digital signature
Re: [PATCH] thermal/drivers/of: Add a get_temp_id callback function
Hello,
On Tue, Apr 16, 2019 at 07:22:03PM +0200, Daniel Lezcano wrote:
> Currently when we register a sensor, we specify the sensor id and a data
> pointer to be passed when the get_temp function is called. However the
> sensor_id is not passed to the get_temp callback forcing the driver to
> do extra allocation and adding back pointer to find out from the sensor
> information the driver data and then back to the sensor id.
>
> Add a new callback get_temp_id() which will be called if set. It will
> call the get_temp_id() with the sensor id.
>
> That will be more consistent with the registering function.
I still do not understand why we need to have a get_id callback.
The use cases I have seen so far, which I have been intentionally rejecting, are
mainly solvable by creating other compatible entries. And really, if you
have, say a bandgap, chip that supports multiple sensors, but on
SoC version A it has 5 sensors, and on SoC version B it has only 4,
or on SoC version C, it has 5 but they are either logially located
in different places (gpu vs iva regions), these are all cases in which
you want a different compatible!
Do you mind sharing why you need a get sensor id callback?
>
> Signed-off-by: Daniel Lezcano
> Tested-by: Andrey Smirnov
> ---
> drivers/thermal/of-thermal.c | 19 +--
> include/linux/thermal.h | 1 +
> 2 files changed, 14 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/thermal/of-thermal.c b/drivers/thermal/of-thermal.c
> index 2df059cc07e2..787d1cbe13f3 100644
> --- a/drivers/thermal/of-thermal.c
> +++ b/drivers/thermal/of-thermal.c
> @@ -78,6 +78,8 @@ struct __thermal_zone {
>
> /* sensor interface */
> void *sensor_data;
> + int sensor_id;
> +
> const struct thermal_zone_of_device_ops *ops;
> };
>
> @@ -88,10 +90,14 @@ static int of_thermal_get_temp(struct thermal_zone_device
> *tz,
> {
> struct __thermal_zone *data = tz->devdata;
>
> - if (!data->ops->get_temp)
> - return -EINVAL;
> + if (data->ops->get_temp)
> + return data->ops->get_temp(data->sensor_data, temp);
>
> - return data->ops->get_temp(data->sensor_data, temp);
> + if (data->ops->get_temp_id)
> + return data->ops->get_temp_id(data->sensor_id,
> + data->sensor_data, temp);
> +
> + return -EINVAL;
> }
>
> static int of_thermal_set_trips(struct thermal_zone_device *tz,
> @@ -407,8 +413,8 @@ static struct thermal_zone_device_ops of_thermal_ops = {
> /*** sensor API ***/
>
> static struct thermal_zone_device *
> -thermal_zone_of_add_sensor(struct device_node *zone,
> -struct device_node *sensor, void *data,
> +thermal_zone_of_add_sensor(struct device_node *zone, struct device_node
> *sensor,
> +int sensor_id, void *data,
> const struct thermal_zone_of_device_ops *ops)
> {
> struct thermal_zone_device *tzd;
> @@ -426,6 +432,7 @@ thermal_zone_of_add_sensor(struct device_node *zone,
> mutex_lock(>lock);
> tz->ops = ops;
> tz->sensor_data = data;
> + tz->sensor_id = sensor_id;
>
> tzd->ops->get_temp = of_thermal_get_temp;
> tzd->ops->get_trend = of_thermal_get_trend;
> @@ -516,7 +523,7 @@ thermal_zone_of_sensor_register(struct device *dev, int
> sensor_id, void *data,
> }
>
> if (sensor_specs.np == sensor_np && id == sensor_id) {
> - tzd = thermal_zone_of_add_sensor(child, sensor_np,
> + tzd = thermal_zone_of_add_sensor(child, sensor_np,
> sensor_id,
>data, ops);
> if (!IS_ERR(tzd))
> tzd->ops->set_mode(tzd, THERMAL_DEVICE_ENABLED);
> diff --git a/include/linux/thermal.h b/include/linux/thermal.h
> index 5f4705f46c2f..2762d7e6dd86 100644
> --- a/include/linux/thermal.h
> +++ b/include/linux/thermal.h
> @@ -351,6 +351,7 @@ struct thermal_genl_event {
> * hardware.
> */
> struct thermal_zone_of_device_ops {
> + int (*get_temp_id)(int, void *, int *);
> int (*get_temp)(void *, int *);
> int (*get_trend)(void *, int, enum thermal_trend *);
> int (*set_trips)(void *, int, int);
> --
> 2.17.1
>
[PATCH v2] memcg: refill_stock for kmem uncharging too
The commit 475d0487a2ad ("mm: memcontrol: use per-cpu stocks for socket
memory uncharging") added refill_stock() for skmem uncharging path to
optimize workloads having high network traffic. Do the same for the kmem
uncharging as well. Though we can bypass the refill for the offlined
memcgs but it may impact the performance of network traffic for the
sockets used by other cgroups.
Signed-off-by: Shakeel Butt
Cc: Roman Gushchin
Cc: Johannes Weiner
Cc: Michal Hocko
Cc: Vladimir Davydov
Cc: Andrew Morton
---
Changelog since v1:
- No need to bypass offline memcgs in the refill.
mm/memcontrol.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 2535e54e7989..2713b45ec3f0 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -2768,17 +2768,13 @@ void __memcg_kmem_uncharge(struct page *page, int order)
if (!cgroup_subsys_on_dfl(memory_cgrp_subsys))
page_counter_uncharge(>kmem, nr_pages);
- page_counter_uncharge(>memory, nr_pages);
- if (do_memsw_account())
- page_counter_uncharge(>memsw, nr_pages);
-
page->mem_cgroup = NULL;
/* slab pages do not have PageKmemcg flag set */
if (PageKmemcg(page))
__ClearPageKmemcg(page);
- css_put_many(>css, nr_pages);
+ refill_stock(memcg, nr_pages);
}
#endif /* CONFIG_MEMCG_KMEM */
--
2.21.0.593.g511ec345e18-goog
Re: [PATCH] soc: add aspeed folder and misc drivers
On Tue, Apr 23, 2019 at 8:33 AM Arnd Bergmann wrote: > > On Tue, Apr 23, 2019 at 4:24 PM Patrick Venture wrote: > > > > On Tue, Apr 23, 2019 at 1:08 AM Arnd Bergmann wrote: > > > > > > On Mon, Apr 22, 2019 at 7:38 PM Patrick Venture > > > wrote: > > > > > > > > Create a SoC folder for the ASPEED parts and place the misc drivers > > > > currently present into this folder. These drivers are not generic part > > > > drivers, but rather only apply to the ASPEED SoCs. > > > > > > > > Signed-off-by: Patrick Venture > > > > > > Looks ok, but please resend to a...@kernel.org or s...@kernel.org > > > so we can track the submission and make sure it gets applied if > > > you want this to go through the arm-soc tree. > > > > Thanks, I didn't see those come up in the get_maintainers output. > > > > I had a longer question related to this patch progression -- if I am > > moving the aspeed gpio driver to the soc folder, the soc tree may have > > the soc/aspeed folder in their next, but the gpio tree wouldn't > > necessarily. I know the branches sync up when things are merged at > > the top, but I wasn't sure if there was another mechanism for this? > > We can generally deal with merge conflicts like this, or you can ask > the respective maintainers about it and let us figure something out. Thanks for explaining that. > > In this particular case, why would you move the gpio driver into > the soc folder? If there is a proper subsystem for a driver, it should > not be in drivers/misc or drivers/soc. Ok, that makes sense. I was trying to get a sense of what belonged in soc versus the subsystem folders. My thinking from the limited reading was the purpose of a SoC folder was to contain the drivers that were only associated with a system-on-a-chip and not a part you could buy and place on any board. A tmp421 sensor is just a generic part, versus the pwm controller, which is only for the specific SoCs. That said, there are quite a few misc drivers associated with the Aspeed parts -- and there are two under review now, so there's a strong motivation to move those at least into the soc/aspeed folder. Thanks for these clarifying remarks. > >Arnd
Re: [PATCH v3 14/28] userfaultfd: wp: handle COW properly for uffd-wp
On Tue, Apr 23, 2019 at 11:00:30AM +0800, Peter Xu wrote:
> On Mon, Apr 22, 2019 at 10:54:02AM -0400, Jerome Glisse wrote:
> > On Mon, Apr 22, 2019 at 08:20:10PM +0800, Peter Xu wrote:
> > > On Fri, Apr 19, 2019 at 11:02:53AM -0400, Jerome Glisse wrote:
> > >
> > > [...]
> > >
> > > > > > > + if (uffd_wp_resolve) {
> > > > > > > + /* If the fault is resolved already,
> > > > > > > skip */
> > > > > > > + if (!pte_uffd_wp(*pte))
> > > > > > > + continue;
> > > > > > > + page = vm_normal_page(vma, addr,
> > > > > > > oldpte);
> > > > > > > + if (!page || page_mapcount(page) > 1) {
> > > > > > > + struct vm_fault vmf = {
> > > > > > > + .vma = vma,
> > > > > > > + .address = addr &
> > > > > > > PAGE_MASK,
> > > > > > > + .page = page,
> > > > > > > + .orig_pte = oldpte,
> > > > > > > + .pmd = pmd,
> > > > > > > + /* pte and ptl not
> > > > > > > needed */
> > > > > > > + };
> > > > > > > + vm_fault_t ret;
> > > > > > > +
> > > > > > > + if (page)
> > > > > > > + get_page(page);
> > > > > > > + arch_leave_lazy_mmu_mode();
> > > > > > > + pte_unmap_unlock(pte, ptl);
> > > > > > > + ret = wp_page_copy();
> > > > > > > + /* PTE is changed, or OOM */
> > > > > > > + if (ret == 0)
> > > > > > > + /* It's done by others
> > > > > > > */
> > > > > > > + continue;
> > > > > >
> > > > > > This is wrong if ret == 0 you still need to remap the pte before
> > > > > > continuing as otherwise you will go to next pte without the page
> > > > > > table lock for the directory. So 0 case must be handled after
> > > > > > arch_enter_lazy_mmu_mode() below.
> > > > > >
> > > > > > Sorry i should have catch that in previous review.
> > > > >
> > > > > My fault to not have noticed it since the very beginning... thanks for
> > > > > spotting that.
> > > > >
> > > > > I'm squashing below changes into the patch:
> > > >
> > > >
> > > > Well thinking of this some more i think you should use do_wp_page() and
> > > > not wp_page_copy() it would avoid bunch of code above and also you are
> > > > not properly handling KSM page or page in the swap cache. Instead of
> > > > duplicating same code that is in do_wp_page() it would be better to call
> > > > it here.
> > >
> > > Yeah it makes sense to me. Then here's my plan:
> > >
> > > - I'll need to drop previous patch "export wp_page_copy" since then
> > > it'll be not needed
> > >
> > > - I'll introduce another patch to split current do_wp_page() and
> > > introduce function "wp_page_copy_cont" (better suggestion on the
> > > naming would be welcomed) which contains most of the wp handling
> > > that'll be needed for change_pte_range() in this patch and isolate
> > > the uffd handling:
> > >
> > > static vm_fault_t do_wp_page(struct vm_fault *vmf)
> > > __releases(vmf->ptl)
> > > {
> > > struct vm_area_struct *vma = vmf->vma;
> > >
> > > if (userfaultfd_pte_wp(vma, *vmf->pte)) {
> > > pte_unmap_unlock(vmf->pte, vmf->ptl);
> > > return handle_userfault(vmf, VM_UFFD_WP);
> > > }
> > >
> > > return do_wp_page_cont(vmf);
> > > }
> > >
> > > Then I can probably use do_wp_page_cont() in this patch.
> >
> > Instead i would keep the do_wp_page name and do:
> > static vm_fault_t do_userfaultfd_wp_page(struct vm_fault *vmf) {
> > ... // what you have above
> > return do_wp_page(vmf);
> > }
> >
> > Naming wise i think it would be better to keep do_wp_page() as
> > is.
>
> In case I misunderstood... what I've proposed will be simply:
>
> diff --git a/mm/memory.c b/mm/memory.c
> index 64bd8075f054..ab98a1eb4702 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -2497,6 +2497,14 @@ static vm_fault_t do_wp_page(struct vm_fault *vmf)
> return handle_userfault(vmf, VM_UFFD_WP);
> }
>
> + return do_wp_page_cont(vmf);
> +}
> +
> +vm_fault_t do_wp_page_cont(struct vm_fault *vmf)
> + __releases(vmf->ptl)
> +{
> + struct vm_area_struct *vma = vmf->vma;
> +
> vmf->page = vm_normal_page(vma, vmf->address, vmf->orig_pte);
> if (!vmf->page) {
> /*
>
> And the other proposal is:
>
> diff --git a/mm/memory.c b/mm/memory.c
> index 64bd8075f054..a73792127553 100644
> ---
Re: [PATCH] PCI/LINK: Account for BW notification in vector calculation
On Tue, 23 Apr 2019 09:33:53 -0500 Alex G wrote: > On 4/22/19 7:33 PM, Alex Williamson wrote: > > On Mon, 22 Apr 2019 19:05:57 -0500 > > Alex G wrote: > >> echo :07:00.0:pcie010 | > >> sudo tee /sys/bus/pci_express/drivers/pcie_bw_notification/unbind > > > > That's a bad solution for users, this is meaningless tracking of a > > device whose driver is actively managing the link bandwidth for power > > purposes. > > 0.5W savings on a 100+W GPU? I agree it's meaningless. Evidence? Regardless, I don't have control of the driver that's making these changes, but the claim seems unfounded and irrelevant. > > There is nothing wrong happening here that needs to fill > > logs. I thought maybe if I enabled notification of autonomous > > bandwidth changes that it might categorize these as something we could > > ignore, but it doesn't. > > How can we identify only cases where this is > > an erroneous/noteworthy situation? Thanks, > > You don't. Ethernet doesn't. USB doesn't. This logging behavior is > consistent with every other subsystem that deals with multi-speed links. > I realize some people are very resistant to change (and use very ancient > kernels). I do not, however, agree that this is a sufficient argument to > dis-unify behavior. Sorry, I don't see how any of this is relevant either. Clearly I'm using a recent kernel or I wouldn't be seeing this new bandwidth notification driver. I'm assigning a device to a VM whose driver is power managing the device via link speed changes. The result is that we now see irrelevant spam in the host dmesg for every inconsequential link downgrade directed by the device. I can see why we might want to be notified of degraded links due to signal issues, but what I'm reporting is that there are also entirely normal and benign reasons that a link might be reduced, we can't seem to tell the difference between a fault and this normal dynamic scaling, and the assumption of a fault is spamming dmesg. So, I don't think what we have here is well cooked. Do drivers have a mechanism to opt-out of this error reporting? Can drivers register an anticipated link change to avoid the spam? What instructions can we *reasonably* give to users as to when these messages mean something, when they don't, any how they can be turned off? Thanks, Alex
Re: [PATCH] soc: add aspeed folder and misc drivers
On Tue, Apr 23, 2019 at 4:24 PM Patrick Venture wrote: > > On Tue, Apr 23, 2019 at 1:08 AM Arnd Bergmann wrote: > > > > On Mon, Apr 22, 2019 at 7:38 PM Patrick Venture wrote: > > > > > > Create a SoC folder for the ASPEED parts and place the misc drivers > > > currently present into this folder. These drivers are not generic part > > > drivers, but rather only apply to the ASPEED SoCs. > > > > > > Signed-off-by: Patrick Venture > > > > Looks ok, but please resend to a...@kernel.org or s...@kernel.org > > so we can track the submission and make sure it gets applied if > > you want this to go through the arm-soc tree. > > Thanks, I didn't see those come up in the get_maintainers output. > > I had a longer question related to this patch progression -- if I am > moving the aspeed gpio driver to the soc folder, the soc tree may have > the soc/aspeed folder in their next, but the gpio tree wouldn't > necessarily. I know the branches sync up when things are merged at > the top, but I wasn't sure if there was another mechanism for this? We can generally deal with merge conflicts like this, or you can ask the respective maintainers about it and let us figure something out. In this particular case, why would you move the gpio driver into the soc folder? If there is a proper subsystem for a driver, it should not be in drivers/misc or drivers/soc. Arnd
Re: [PATCH v2] soc: add aspeed folder and misc drivers
On Tue, Apr 23, 2019 at 8:22 AM Patrick Venture wrote:
>
> On Tue, Apr 23, 2019 at 7:26 AM Patrick Venture wrote:
> >
> > Create a SoC folder for the ASPEED parts and place the misc drivers
> > currently present into this folder. These drivers are not generic part
> > drivers, but rather only apply to the ASPEED SoCs.
> >
> > Signed-off-by: Patrick Venture
>
> Accidentally lost the Acked-by when re-sending this patchset as I
> didn't see it on v1 before re-sending v2 to the larger audience.
Since there was a change between v1 and v2, Arnd, I'd appreciate you
Ack this version of the patchset since it changes when the soc/aspeed
Makefile is followed.
>
> > ---
> > v2:
> > Added configuration option for ASPEED to soc/Makefile
> > ---
> > drivers/misc/Kconfig | 16
> > drivers/misc/Makefile | 2 --
> > drivers/soc/Kconfig | 1 +
> > drivers/soc/Makefile | 1 +
> > drivers/soc/aspeed/Kconfig| 19 +++
> > drivers/soc/aspeed/Makefile | 2 ++
> > .../{misc => soc/aspeed}/aspeed-lpc-ctrl.c| 0
> > .../{misc => soc/aspeed}/aspeed-lpc-snoop.c | 0
> > 8 files changed, 23 insertions(+), 18 deletions(-)
> > create mode 100644 drivers/soc/aspeed/Kconfig
> > create mode 100644 drivers/soc/aspeed/Makefile
> > rename drivers/{misc => soc/aspeed}/aspeed-lpc-ctrl.c (100%)
> > rename drivers/{misc => soc/aspeed}/aspeed-lpc-snoop.c (100%)
> >
> > diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
> > index 42ab8ec92a04..b80cb6af0cb4 100644
> > --- a/drivers/misc/Kconfig
> > +++ b/drivers/misc/Kconfig
> > @@ -496,22 +496,6 @@ config VEXPRESS_SYSCFG
> > bus. System Configuration interface is one of the possible means
> > of generating transactions on this bus.
> >
> > -config ASPEED_LPC_CTRL
> > - depends on (ARCH_ASPEED || COMPILE_TEST) && REGMAP && MFD_SYSCON
> > - tristate "Aspeed ast2400/2500 HOST LPC to BMC bridge control"
> > - ---help---
> > - Control Aspeed ast2400/2500 HOST LPC to BMC mappings through
> > - ioctl()s, the driver also provides a read/write interface to a
> > BMC ram
> > - region where the host LPC read/write region can be buffered.
> > -
> > -config ASPEED_LPC_SNOOP
> > - tristate "Aspeed ast2500 HOST LPC snoop support"
> > - depends on (ARCH_ASPEED || COMPILE_TEST) && REGMAP && MFD_SYSCON
> > - help
> > - Provides a driver to control the LPC snoop interface which
> > - allows the BMC to listen on and save the data written by
> > - the host to an arbitrary LPC I/O port.
> > -
> > config PCI_ENDPOINT_TEST
> > depends on PCI
> > select CRC32
> > diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
> > index d5b7d3404dc7..b9affcdaa3d6 100644
> > --- a/drivers/misc/Makefile
> > +++ b/drivers/misc/Makefile
> > @@ -54,8 +54,6 @@ obj-$(CONFIG_GENWQE) += genwqe/
> > obj-$(CONFIG_ECHO) += echo/
> > obj-$(CONFIG_VEXPRESS_SYSCFG) += vexpress-syscfg.o
> > obj-$(CONFIG_CXL_BASE) += cxl/
> > -obj-$(CONFIG_ASPEED_LPC_CTRL) += aspeed-lpc-ctrl.o
> > -obj-$(CONFIG_ASPEED_LPC_SNOOP) += aspeed-lpc-snoop.o
> > obj-$(CONFIG_PCI_ENDPOINT_TEST)+= pci_endpoint_test.o
> > obj-$(CONFIG_OCXL) += ocxl/
> > obj-y += cardreader/
> > diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
> > index c07b4a85253f..b750a88547c7 100644
> > --- a/drivers/soc/Kconfig
> > +++ b/drivers/soc/Kconfig
> > @@ -2,6 +2,7 @@ menu "SOC (System On Chip) specific Drivers"
> >
> > source "drivers/soc/actions/Kconfig"
> > source "drivers/soc/amlogic/Kconfig"
> > +source "drivers/soc/aspeed/Kconfig"
> > source "drivers/soc/atmel/Kconfig"
> > source "drivers/soc/bcm/Kconfig"
> > source "drivers/soc/fsl/Kconfig"
> > diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile
> > index 90b686e586c6..814128fe479f 100644
> > --- a/drivers/soc/Makefile
> > +++ b/drivers/soc/Makefile
> > @@ -4,6 +4,7 @@
> > #
> >
> > obj-$(CONFIG_ARCH_ACTIONS) += actions/
> > +obj-$(CONFIG_ARCH_ASPEED) += aspeed/
> > obj-$(CONFIG_ARCH_AT91)+= atmel/
> > obj-y += bcm/
> > obj-$(CONFIG_ARCH_DOVE)+= dove/
> > diff --git a/drivers/soc/aspeed/Kconfig b/drivers/soc/aspeed/Kconfig
> > new file mode 100644
> > index ..457282cd1da5
> > --- /dev/null
> > +++ b/drivers/soc/aspeed/Kconfig
> > @@ -0,0 +1,19 @@
> > +menu "Aspeed SoC drivers"
> > +
> > +config ASPEED_LPC_CTRL
> > + depends on (ARCH_ASPEED || COMPILE_TEST) && REGMAP && MFD_SYSCON
> > + tristate "Aspeed ast2400/2500 HOST LPC to BMC bridge control"
> > + ---help---
> > + Control Aspeed ast2400/2500 HOST LPC to BMC mappings through
> > + ioctl()s, the driver also provides a read/write interface to a
> > BMC ram
Re: [PATCH v2 7/8] s390: vfio-ap: handle bind and unbind of AP queue device
On 4/23/19 9:54 AM, Halil Pasic wrote:
On Sat, 20 Apr 2019 17:49:39 -0400
Tony Krowiak wrote:
+void vfio_ap_mdev_probe_queue(unsigned long apid, unsigned long apqi)
+{
+ struct ap_matrix_mdev *matrix_mdev;
+
+ matrix_mdev = vfio_ap_mdev_find_matrix_mdev(apid, apqi);
+
+ /*
+* If the queue is assigned to the mdev device and the mdev device
+* is in use by a guest
+*/
+ if (matrix_mdev && matrix_mdev->kvm) {
+ /* Plug the adapter into the guest */
+ set_bit_inv(apid, matrix_mdev->shadow_crycb->apm);
+
+ /* Make sure the queue is also plugged in to the guest */
+ if (!test_bit_inv(apqi, matrix_mdev->shadow_crycb->aqm))
+ set_bit_inv(apqi, matrix_mdev->shadow_crycb->aqm);
+
+ vfio_ap_mdev_update_crycb(matrix_mdev);
With this you effectively grant access to all the assigned domains on
the AP identified by the apid, not only to the domain identified by
apqi! But some of these queues may still not be bound to the vfio_ap
driver.
I have been doing some more testing since I last visited and discovered
that there needs to be additional checking here.
IMHO you should only set the apid-th bit in apm if all queues (apid, q)
such that q-th bit is set in aqm are bound to the vfio_ap driver.
This is partially correct. It is not necessary to verify that the
affected queues are bound to the vfio_ap driver. It is only necessary
to verify they are not reserved for use by a zcrypt driver since we
are allowing assignment of APQNs for queues that are not available (see
patch 3/8).
BTW a 'shadow' (or effective) apm would perfectly suffice. I don't think
you fiddle with shadow_crycb->a[qd]m, and if you do, I don't think that's
a good idea.
I do not think it is accurate to refer to the APM in the shadow CRYCB as
an effective mask. Effective masking is a firmware construct. The CRYCB
of the guest may be configured with APQNs that are not available.
The shadow CRYCB is in fact a copy of the guest CRYCB. Whenever the
masks in the guest CRYCB are set, they are set from the masks in the
shadow CRYCB. The lifespan of the shadow CRYCB is synonymous with the
lifespan of the guest.
Each of the mdev device sysfs assignment/unassignment interfaces does
fiddle with the masks in the shadow CRYCB if a guest is using the mdev
device. This allows us to hot plug/unplug AP resources for the guest.
Recall that an adapter or domain can not be assigned unless each
new APQN created is NOT reserved for use by the zcrypt drivers via
the AP bus's apmask/aqmask sysfs interfaces, and the APQN is not
assigned to any other mdev device. That is how protection is
provided against inadvertently sharing AP queues between guests or
the guest and the host. I do have to add that verification to
the vfio_ap_mdev_probe_queue function though.
Regards,
Halil
+ }
+}
Re: [PATCH] memstick: mark expected switch fall-throughs
On 4/23/19 10:15 AM, Kees Cook wrote: > On Tue, Feb 12, 2019 at 6:57 PM Gustavo A. R. Silva > wrote: >> >> In preparation to enabling -Wimplicit-fallthrough, mark switch >> cases where we are expecting to fall through. >> >> This patch fixes the following warnings: >> >> drivers/memstick/host/jmb38x_ms.c: In function ‘jmb38x_ms_write_data’: >> drivers/memstick/host/jmb38x_ms.c:261:15: warning: this statement may fall >> through [-Wimplicit-fallthrough=] >>host->io_pos++; >>^~ >> drivers/memstick/host/jmb38x_ms.c:262:2: note: here >> case 2: >> ^~~~ >> drivers/memstick/host/jmb38x_ms.c:264:15: warning: this statement may fall >> through [-Wimplicit-fallthrough=] >>host->io_pos++; >>^~ >> drivers/memstick/host/jmb38x_ms.c:265:2: note: here >> case 1: >> ^~~~ >> drivers/memstick/host/tifm_ms.c: In function ‘tifm_ms_write_data’: >> drivers/memstick/host/tifm_ms.c:168:15: warning: this statement may fall >> through [-Wimplicit-fallthrough=] >>host->io_pos++; >>^~ >> drivers/memstick/host/tifm_ms.c:169:2: note: here >> case 2: >> ^~~~ >> drivers/memstick/host/tifm_ms.c:171:15: warning: this statement may fall >> through [-Wimplicit-fallthrough=] >>host->io_pos++; >>^~ >> drivers/memstick/host/tifm_ms.c:172:2: note: here >> case 1: >> ^~~~ >> >> Warning level 3 was used: -Wimplicit-fallthrough=3 >> >> This patch is part of the ongoing efforts to enable >> -Wimplicit-fallthrough. >> >> Signed-off-by: Gustavo A. R. Silva > > Reviewed-by: Kees Cook > Thanks, Kees! -- Gustavo
Re: [PATCH 1/3] perf, tools: Add support for recording and printing XMM registers
Hi Arnaldo and Jirka,
Have you got a chance to review this patch series?
This series is user space tool support for Icelake and Tremont.
Thanks,
Kan
On 4/16/2019 11:24 AM, kan.li...@linux.intel.com wrote:
From: Andi Kleen
Icelake and later platforms support collecting XMM registers with PEBS
event.
Add support for perf script to dump them, and support
for the register parser in perf record -I ... to configure them.
For now they are just printed in hex, could potentially add
other formats too.
Signed-off-by: Andi Kleen
Signed-off-by: Kan Liang
---
tools/arch/x86/include/uapi/asm/perf_regs.h | 23 ++-
tools/perf/arch/x86/include/perf_regs.h | 25 +++--
tools/perf/arch/x86/util/perf_regs.c| 16 +
tools/perf/util/perf_regs.h | 1 +
4 files changed, 62 insertions(+), 3 deletions(-)
diff --git a/tools/arch/x86/include/uapi/asm/perf_regs.h
b/tools/arch/x86/include/uapi/asm/perf_regs.h
index f3329cabce5c..ac67bbea10ca 100644
--- a/tools/arch/x86/include/uapi/asm/perf_regs.h
+++ b/tools/arch/x86/include/uapi/asm/perf_regs.h
@@ -27,8 +27,29 @@ enum perf_event_x86_regs {
PERF_REG_X86_R13,
PERF_REG_X86_R14,
PERF_REG_X86_R15,
-
+ /* These are the limits for the GPRs. */
PERF_REG_X86_32_MAX = PERF_REG_X86_GS + 1,
PERF_REG_X86_64_MAX = PERF_REG_X86_R15 + 1,
+
+ /* These all need two bits set because they are 128bit */
+ PERF_REG_X86_XMM0 = 32,
+ PERF_REG_X86_XMM1 = 34,
+ PERF_REG_X86_XMM2 = 36,
+ PERF_REG_X86_XMM3 = 38,
+ PERF_REG_X86_XMM4 = 40,
+ PERF_REG_X86_XMM5 = 42,
+ PERF_REG_X86_XMM6 = 44,
+ PERF_REG_X86_XMM7 = 46,
+ PERF_REG_X86_XMM8 = 48,
+ PERF_REG_X86_XMM9 = 50,
+ PERF_REG_X86_XMM10 = 52,
+ PERF_REG_X86_XMM11 = 54,
+ PERF_REG_X86_XMM12 = 56,
+ PERF_REG_X86_XMM13 = 58,
+ PERF_REG_X86_XMM14 = 60,
+ PERF_REG_X86_XMM15 = 62,
+
+ /* These include both GPRs and XMMX registers */
+ PERF_REG_X86_XMM_MAX = PERF_REG_X86_XMM15 + 2,
};
#endif /* _ASM_X86_PERF_REGS_H */
diff --git a/tools/perf/arch/x86/include/perf_regs.h
b/tools/perf/arch/x86/include/perf_regs.h
index 7f6d538f8a89..b7321337d100 100644
--- a/tools/perf/arch/x86/include/perf_regs.h
+++ b/tools/perf/arch/x86/include/perf_regs.h
@@ -8,9 +8,9 @@
void perf_regs_load(u64 *regs);
+#define PERF_REGS_MAX PERF_REG_X86_XMM_MAX
#ifndef HAVE_ARCH_X86_64_SUPPORT
#define PERF_REGS_MASK ((1ULL << PERF_REG_X86_32_MAX) - 1)
-#define PERF_REGS_MAX PERF_REG_X86_32_MAX
#define PERF_SAMPLE_REGS_ABI PERF_SAMPLE_REGS_ABI_32
#else
#define REG_NOSUPPORT ((1ULL << PERF_REG_X86_DS) | \
@@ -18,7 +18,6 @@ void perf_regs_load(u64 *regs);
(1ULL << PERF_REG_X86_FS) | \
(1ULL << PERF_REG_X86_GS))
#define PERF_REGS_MASK (((1ULL << PERF_REG_X86_64_MAX) - 1) & ~REG_NOSUPPORT)
-#define PERF_REGS_MAX PERF_REG_X86_64_MAX
#define PERF_SAMPLE_REGS_ABI PERF_SAMPLE_REGS_ABI_64
#endif
#define PERF_REG_IP PERF_REG_X86_IP
@@ -77,6 +76,28 @@ static inline const char *perf_reg_name(int id)
case PERF_REG_X86_R15:
return "R15";
#endif /* HAVE_ARCH_X86_64_SUPPORT */
+
+#define XMM(x) \
+ case PERF_REG_X86_XMM ## x: \
+ case PERF_REG_X86_XMM ## x + 1: \
+ return "XMM" #x;
+ XMM(0)
+ XMM(1)
+ XMM(2)
+ XMM(3)
+ XMM(4)
+ XMM(5)
+ XMM(6)
+ XMM(7)
+ XMM(8)
+ XMM(9)
+ XMM(10)
+ XMM(11)
+ XMM(12)
+ XMM(13)
+ XMM(14)
+ XMM(15)
+#undef XMM
default:
return NULL;
}
diff --git a/tools/perf/arch/x86/util/perf_regs.c
b/tools/perf/arch/x86/util/perf_regs.c
index fead6b3b4206..71d7604dbf0b 100644
--- a/tools/perf/arch/x86/util/perf_regs.c
+++ b/tools/perf/arch/x86/util/perf_regs.c
@@ -31,6 +31,22 @@ const struct sample_reg sample_reg_masks[] = {
SMPL_REG(R14, PERF_REG_X86_R14),
SMPL_REG(R15, PERF_REG_X86_R15),
#endif
+ SMPL_REG2(XMM0, PERF_REG_X86_XMM0),
+ SMPL_REG2(XMM1, PERF_REG_X86_XMM1),
+ SMPL_REG2(XMM2, PERF_REG_X86_XMM2),
+ SMPL_REG2(XMM3, PERF_REG_X86_XMM3),
+ SMPL_REG2(XMM4, PERF_REG_X86_XMM4),
+ SMPL_REG2(XMM5, PERF_REG_X86_XMM5),
+ SMPL_REG2(XMM6, PERF_REG_X86_XMM6),
+ SMPL_REG2(XMM7, PERF_REG_X86_XMM7),
+ SMPL_REG2(XMM8, PERF_REG_X86_XMM8),
+ SMPL_REG2(XMM9, PERF_REG_X86_XMM9),
+ SMPL_REG2(XMM10, PERF_REG_X86_XMM10),
+ SMPL_REG2(XMM11, PERF_REG_X86_XMM11),
+ SMPL_REG2(XMM12, PERF_REG_X86_XMM12),
+ SMPL_REG2(XMM13, PERF_REG_X86_XMM13),
+ SMPL_REG2(XMM14, PERF_REG_X86_XMM14),
+ SMPL_REG2(XMM15, PERF_REG_X86_XMM15),
SMPL_REG_END
};
diff --git a/tools/perf/util/perf_regs.h b/tools/perf/util/perf_regs.h
index c9319f8d17a6..1a15a4bfc28d 100644
--- a/tools/perf/util/perf_regs.h
Re: Alleged fix for writer stall on -rcu branch dev
On 2019-04-15 13:04:03 [+0200], To Paul E. McKenney wrote: > > good so nothing important so far. I hope the box gets to TREE08 soon. test completed. Nothing new. > > > > Thanx, Paul > Sebastian
Re: [PATCH v4 09/12] soc: mediatek: cmdq: add polling function
Hi Bibby,
On Mon, 2019-04-15 at 20:58 +0800, Bibby Hsieh wrote:
> add polling function in cmdq helper functions
>
> Signed-off-by: Bibby Hsieh
> ---
> drivers/soc/mediatek/mtk-cmdq-helper.c | 30
> include/linux/mailbox/mtk-cmdq-mailbox.h | 1 +
> include/linux/soc/mediatek/mtk-cmdq.h| 15
> 3 files changed, 46 insertions(+)
>
> diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c
> b/drivers/soc/mediatek/mtk-cmdq-helper.c
> index d3873ab21db3..80856b8c2385 100644
> --- a/drivers/soc/mediatek/mtk-cmdq-helper.c
> +++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
> @@ -231,6 +231,36 @@ int cmdq_pkt_clear_event(struct cmdq_pkt *pkt, u16 event)
> }
> EXPORT_SYMBOL(cmdq_pkt_clear_event);
>
> +int cmdq_pkt_poll(struct cmdq_pkt *pkt, u8 subsys,
> + u16 offset, u32 value, u32 mask)
> +{
> + int err;
> +
> + if (mask != 0x) {
> + err = cmdq_pkt_append_command(pkt, CMDQ_GET_ARG_C(~mask),
> + CMDQ_GET_ARG_B(~mask),
> + CMDQ_IMMEDIATE_VALUE,
> + CMDQ_IMMEDIATE_VALUE,
> + CMDQ_IMMEDIATE_VALUE,
> + CMDQ_IMMEDIATE_VALUE,
> + CMDQ_IMMEDIATE_VALUE,
> + CMDQ_CODE_MASK);
> +
> + if (err != 0)
> + return err;
> + }
> + offset = offset | 0x1;
Does this "or" operation make gce use mask? If it does, maybe it should
move into brace?
Regards,
Dennis
> +
> + return cmdq_pkt_append_command(pkt, CMDQ_GET_ARG_C(value),
> +CMDQ_GET_ARG_B(value),
> +offset, subsys,
> +CMDQ_IMMEDIATE_VALUE,
> +CMDQ_IMMEDIATE_VALUE,
> +CMDQ_IMMEDIATE_VALUE,
> +CMDQ_CODE_POLL);
> +}
> +EXPORT_SYMBOL(cmdq_pkt_poll);
> +
> static int cmdq_pkt_finalize(struct cmdq_pkt *pkt)
> {
> int err;
> diff --git a/include/linux/mailbox/mtk-cmdq-mailbox.h
> b/include/linux/mailbox/mtk-cmdq-mailbox.h
> index f21801d32a3a..1dfd5ed5c8c5 100644
> --- a/include/linux/mailbox/mtk-cmdq-mailbox.h
> +++ b/include/linux/mailbox/mtk-cmdq-mailbox.h
> @@ -46,6 +46,7 @@
> enum cmdq_code {
> CMDQ_CODE_MASK = 0x02,
> CMDQ_CODE_WRITE = 0x04,
> + CMDQ_CODE_POLL = 0x08,
> CMDQ_CODE_JUMP = 0x10,
> CMDQ_CODE_WFE = 0x20,
> CMDQ_CODE_EOC = 0x40,
> diff --git a/include/linux/soc/mediatek/mtk-cmdq.h
> b/include/linux/soc/mediatek/mtk-cmdq.h
> index 52f69c8db8de..0651a0bffa54 100644
> --- a/include/linux/soc/mediatek/mtk-cmdq.h
> +++ b/include/linux/soc/mediatek/mtk-cmdq.h
> @@ -99,6 +99,21 @@ int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u16 event);
> */
> int cmdq_pkt_clear_event(struct cmdq_pkt *pkt, u16 event);
>
> +/**
> + * cmdq_pkt_poll() - Append polling command to the CMDQ packet, ask GCE to
> + *execute an instruction that wait for a specified hardware
> + *register to check for the value. All GCE hardware
> + *threads will be blocked by this instruction.
> + * @pkt: the CMDQ packet
> + * @subsys: the CMDQ sub system code
> + * @offset: register offset from CMDQ sub system
> + * @value: the specified target register value
> + * @mask:the specified target register mask
> + *
> + * Return: 0 for success; else the error code is returned
> + */
> +int cmdq_pkt_poll(struct cmdq_pkt *pkt, u8 subsys,
> + u16 offset, u32 value, u32 mask);
> /**
> * cmdq_pkt_flush_async() - trigger CMDQ to asynchronously execute the CMDQ
> * packet and call back at the end of done packet
Re: [PATCH v2] soc: add aspeed folder and misc drivers
On Tue, Apr 23, 2019 at 7:26 AM Patrick Venture wrote:
>
> Create a SoC folder for the ASPEED parts and place the misc drivers
> currently present into this folder. These drivers are not generic part
> drivers, but rather only apply to the ASPEED SoCs.
>
> Signed-off-by: Patrick Venture
Accidentally lost the Acked-by when re-sending this patchset as I
didn't see it on v1 before re-sending v2 to the larger audience.
> ---
> v2:
> Added configuration option for ASPEED to soc/Makefile
> ---
> drivers/misc/Kconfig | 16
> drivers/misc/Makefile | 2 --
> drivers/soc/Kconfig | 1 +
> drivers/soc/Makefile | 1 +
> drivers/soc/aspeed/Kconfig| 19 +++
> drivers/soc/aspeed/Makefile | 2 ++
> .../{misc => soc/aspeed}/aspeed-lpc-ctrl.c| 0
> .../{misc => soc/aspeed}/aspeed-lpc-snoop.c | 0
> 8 files changed, 23 insertions(+), 18 deletions(-)
> create mode 100644 drivers/soc/aspeed/Kconfig
> create mode 100644 drivers/soc/aspeed/Makefile
> rename drivers/{misc => soc/aspeed}/aspeed-lpc-ctrl.c (100%)
> rename drivers/{misc => soc/aspeed}/aspeed-lpc-snoop.c (100%)
>
> diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
> index 42ab8ec92a04..b80cb6af0cb4 100644
> --- a/drivers/misc/Kconfig
> +++ b/drivers/misc/Kconfig
> @@ -496,22 +496,6 @@ config VEXPRESS_SYSCFG
> bus. System Configuration interface is one of the possible means
> of generating transactions on this bus.
>
> -config ASPEED_LPC_CTRL
> - depends on (ARCH_ASPEED || COMPILE_TEST) && REGMAP && MFD_SYSCON
> - tristate "Aspeed ast2400/2500 HOST LPC to BMC bridge control"
> - ---help---
> - Control Aspeed ast2400/2500 HOST LPC to BMC mappings through
> - ioctl()s, the driver also provides a read/write interface to a BMC
> ram
> - region where the host LPC read/write region can be buffered.
> -
> -config ASPEED_LPC_SNOOP
> - tristate "Aspeed ast2500 HOST LPC snoop support"
> - depends on (ARCH_ASPEED || COMPILE_TEST) && REGMAP && MFD_SYSCON
> - help
> - Provides a driver to control the LPC snoop interface which
> - allows the BMC to listen on and save the data written by
> - the host to an arbitrary LPC I/O port.
> -
> config PCI_ENDPOINT_TEST
> depends on PCI
> select CRC32
> diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
> index d5b7d3404dc7..b9affcdaa3d6 100644
> --- a/drivers/misc/Makefile
> +++ b/drivers/misc/Makefile
> @@ -54,8 +54,6 @@ obj-$(CONFIG_GENWQE) += genwqe/
> obj-$(CONFIG_ECHO) += echo/
> obj-$(CONFIG_VEXPRESS_SYSCFG) += vexpress-syscfg.o
> obj-$(CONFIG_CXL_BASE) += cxl/
> -obj-$(CONFIG_ASPEED_LPC_CTRL) += aspeed-lpc-ctrl.o
> -obj-$(CONFIG_ASPEED_LPC_SNOOP) += aspeed-lpc-snoop.o
> obj-$(CONFIG_PCI_ENDPOINT_TEST)+= pci_endpoint_test.o
> obj-$(CONFIG_OCXL) += ocxl/
> obj-y += cardreader/
> diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
> index c07b4a85253f..b750a88547c7 100644
> --- a/drivers/soc/Kconfig
> +++ b/drivers/soc/Kconfig
> @@ -2,6 +2,7 @@ menu "SOC (System On Chip) specific Drivers"
>
> source "drivers/soc/actions/Kconfig"
> source "drivers/soc/amlogic/Kconfig"
> +source "drivers/soc/aspeed/Kconfig"
> source "drivers/soc/atmel/Kconfig"
> source "drivers/soc/bcm/Kconfig"
> source "drivers/soc/fsl/Kconfig"
> diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile
> index 90b686e586c6..814128fe479f 100644
> --- a/drivers/soc/Makefile
> +++ b/drivers/soc/Makefile
> @@ -4,6 +4,7 @@
> #
>
> obj-$(CONFIG_ARCH_ACTIONS) += actions/
> +obj-$(CONFIG_ARCH_ASPEED) += aspeed/
> obj-$(CONFIG_ARCH_AT91)+= atmel/
> obj-y += bcm/
> obj-$(CONFIG_ARCH_DOVE)+= dove/
> diff --git a/drivers/soc/aspeed/Kconfig b/drivers/soc/aspeed/Kconfig
> new file mode 100644
> index ..457282cd1da5
> --- /dev/null
> +++ b/drivers/soc/aspeed/Kconfig
> @@ -0,0 +1,19 @@
> +menu "Aspeed SoC drivers"
> +
> +config ASPEED_LPC_CTRL
> + depends on (ARCH_ASPEED || COMPILE_TEST) && REGMAP && MFD_SYSCON
> + tristate "Aspeed ast2400/2500 HOST LPC to BMC bridge control"
> + ---help---
> + Control Aspeed ast2400/2500 HOST LPC to BMC mappings through
> + ioctl()s, the driver also provides a read/write interface to a BMC
> ram
> + region where the host LPC read/write region can be buffered.
> +
> +config ASPEED_LPC_SNOOP
> + tristate "Aspeed ast2500 HOST LPC snoop support"
> + depends on (ARCH_ASPEED || COMPILE_TEST) && REGMAP && MFD_SYSCON
> + help
> + Provides a driver to control the LPC snoop interface which
> + allows the BMC to listen on and save the data written by
> + the host to an arbitrary LPC I/O
[PATCH] uprobes: use DEFINE_STATIC_PERCPU_RWSEM() to initialize dup_mmap_sem
Use DEFINE_STATIC_PERCPU_RWSEM() to initialize dup_mmap_sem. Signed-off-by: Oleg Nesterov --- kernel/events/uprobes.c | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c index c5cde87..76c7380 100644 --- a/kernel/events/uprobes.c +++ b/kernel/events/uprobes.c @@ -46,7 +46,7 @@ static DEFINE_SPINLOCK(uprobes_treelock); /* serialize rbtree access */ static struct mutex uprobes_mmap_mutex[UPROBES_HASH_SZ]; #define uprobes_mmap_hash(v) (_mmap_mutex[((unsigned long)(v)) % UPROBES_HASH_SZ]) -static struct percpu_rw_semaphore dup_mmap_sem; +DEFINE_STATIC_PERCPU_RWSEM(dup_mmap_sem); /* Have a copy of original instruction */ #define UPROBE_COPY_INSN 0 @@ -2301,9 +2301,6 @@ static int __init init_uprobes(void) for (i = 0; i < UPROBES_HASH_SZ; i++) mutex_init(_mmap_mutex[i]); - if (percpu_init_rwsem(_mmap_sem)) - return -ENOMEM; - return register_die_notifier(_exception_nb); } __initcall(init_uprobes); -- 2.5.0
Re: [PATCH] dmaengine: stm32-dma: fix residue calculation in stm32-dma
Hello Vinod,
Just a gentle reminder, if you could take a moment to review this patch.
FYI, the patch has already been internally reviewed by Pierre Yves
mordret...
His sign-off is in the commit message.
Thanks,
Arnaud
On 3/27/19 1:21 PM, Arnaud Pouliquen wrote:
> During residue calculation. the DMA can switch to the next sg. When
> this race condition occurs, the residue returned value is not valid.
> Indeed the position in the sg returned by the hardware is the position
> of the next sg, not the current sg.
> Solution is to check the sg after the calculation to verify it.
> If a transition is detected we consider that the DMA has switched to
> the beginning of next sg.
>
> Signed-off-by: Arnaud Pouliquen
> Signed-off-by: Pierre-Yves MORDRET
> ---
> drivers/dma/stm32-dma.c | 70
> -
> 1 file changed, 57 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/dma/stm32-dma.c b/drivers/dma/stm32-dma.c
> index 4903a40..30309d2 100644
> --- a/drivers/dma/stm32-dma.c
> +++ b/drivers/dma/stm32-dma.c
> @@ -1038,33 +1038,77 @@ static u32 stm32_dma_get_remaining_bytes(struct
> stm32_dma_chan *chan)
> return ndtr << width;
> }
>
> +static bool stm32_dma_is_current_sg(struct stm32_dma_chan *chan)
> +{
> + struct stm32_dma_device *dmadev = stm32_dma_get_dev(chan);
> + struct stm32_dma_sg_req *sg_req;
> + u32 dma_scr, dma_smar, id;
> +
> + id = chan->id;
> + dma_scr = stm32_dma_read(dmadev, STM32_DMA_SCR(id));
> +
> + if (!(dma_scr & STM32_DMA_SCR_DBM))
> + return true;
> +
> + sg_req = >desc->sg_req[chan->next_sg];
> +
> + if (dma_scr & STM32_DMA_SCR_CT) {
> + dma_smar = stm32_dma_read(dmadev, STM32_DMA_SM0AR(id));
> + return (dma_smar == sg_req->chan_reg.dma_sm0ar);
> + }
> +
> + dma_smar = stm32_dma_read(dmadev, STM32_DMA_SM1AR(id));
> +
> + return (dma_smar == sg_req->chan_reg.dma_sm1ar);
> +}
> +
> static size_t stm32_dma_desc_residue(struct stm32_dma_chan *chan,
>struct stm32_dma_desc *desc,
>u32 next_sg)
> {
> u32 modulo, burst_size;
> - u32 residue = 0;
> + u32 residue;
> + u32 n_sg = next_sg;
> + struct stm32_dma_sg_req *sg_req = >desc->sg_req[chan->next_sg];
> int i;
>
> + residue = stm32_dma_get_remaining_bytes(chan);
> +
> /*
> - * In cyclic mode, for the last period, residue = remaining bytes from
> - * NDTR
> + * Calculate the residue means compute the descriptors
> + * information:
> + * - the sg currently transferred
> + * - the remaining position in this sg (NDTR).
> + *
> + * The issue is that a race condition can occur if DMA is
> + * running. DMA can have started to transfer the next sg before
> + * the position in sg is read. In this case the remaing position
> + * can correspond to the new sg position.
> + * The strategy implemented in the stm32 driver is to check the
> + * sg transition. If detected we can not trust the SxNDTR register
> + * value, this register can not be up to date during the transition.
> + * In this case we can assume that the dma is at the beginning of next
> + * sg so we calculate the residue in consequence.
>*/
> - if (chan->desc->cyclic && next_sg == 0) {
> - residue = stm32_dma_get_remaining_bytes(chan);
> - goto end;
> +
> + if (!stm32_dma_is_current_sg(chan)) {
> + n_sg++;
> + if (n_sg == chan->desc->num_sgs)
> + n_sg = 0;
> + residue = sg_req->len;
> }
>
> /*
> - * For all other periods in cyclic mode, and in sg mode,
> - * residue = remaining bytes from NDTR + remaining periods/sg to be
> - * transferred
> + * In cyclic mode, for the last period, residue = remaining bytes
> + * from NDTR,
> + * else for all other periods in cyclic mode, and in sg mode,
> + * residue = remaining bytes from NDTR + remaining
> + * periods/sg to be transferred
>*/
> - for (i = next_sg; i < desc->num_sgs; i++)
> - residue += desc->sg_req[i].len;
> - residue += stm32_dma_get_remaining_bytes(chan);
> + if (!chan->desc->cyclic || n_sg != 0)
> + for (i = n_sg; i < desc->num_sgs; i++)
> + residue += desc->sg_req[i].len;
>
> -end:
> if (!chan->mem_burst)
> return residue;
>
>
Re: [PATCH] x86/mm/mem_encrypt: fix a crash with kmemleak_scan
On Tue, Apr 23, 2019 at 10:16:46AM -0400, Qian Cai wrote: > In reality, this is only the second place that needs this kmemleak_free_part() > call for all those years since kmemleak was born. And? Which place warrants doing it right? The third? Fourth? -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply.
Re: [PATCH] x86/mm/mem_encrypt: fix a crash with kmemleak_scan
On Tue, Apr 23, 2019 at 03:02:56PM +0100, Catalin Marinas wrote:
> The .bss/.data used to be root until recently when commit 298a32b13208
> ("kmemleak: powerpc: skip scanning holes in the .bss section") changed
> this to accommodate a similar problem on powerpc. With this commit,
> .bss/.data are traced objects but painted "grey" by default so that they
> will be always scanned, pretty much like the root (and they can't
> "leak").
I see.
> In Qian's splat, the unmapped area was actually in the .bss which is now
> a traced object (no longer a root one).
Right, makes sense.
> Object freeing is tracked in general via the corresponding kfree(),
> vfree() etc. and don't need special handling. The .bss doesn't have this
> alloc/free symmetry and not freeing it all either, hence this
> workaround to register it as a traced object and allow partial freeing.
>
> Anyway, I agree with you. As I mentioned in the previous email,
> kmemleak_free_part() is tolerant to unknown objects (not tracked by
> kmemleak), so I'm fine with calling it from free_init_pages() even if
> not all address ranges passed to this function are known to kmemleak.
Cool.
> I took a note to improve this when I get some time.
Thanks. That would be helpful, I think, for people like me who'd like to
get a short intro on kmemleak in order to understand what is being fixed
when a patch lands in their mbox. :)
> There are probably some academic papers published somewhere ;). But
> wikipedia makes things much easier (and free).
Yap :-)
Thanks.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
Re: [PATCH] memstick: mark expected switch fall-throughs
On Tue, Feb 12, 2019 at 6:57 PM Gustavo A. R. Silva wrote: > > In preparation to enabling -Wimplicit-fallthrough, mark switch > cases where we are expecting to fall through. > > This patch fixes the following warnings: > > drivers/memstick/host/jmb38x_ms.c: In function ‘jmb38x_ms_write_data’: > drivers/memstick/host/jmb38x_ms.c:261:15: warning: this statement may fall > through [-Wimplicit-fallthrough=] >host->io_pos++; >^~ > drivers/memstick/host/jmb38x_ms.c:262:2: note: here > case 2: > ^~~~ > drivers/memstick/host/jmb38x_ms.c:264:15: warning: this statement may fall > through [-Wimplicit-fallthrough=] >host->io_pos++; >^~ > drivers/memstick/host/jmb38x_ms.c:265:2: note: here > case 1: > ^~~~ > drivers/memstick/host/tifm_ms.c: In function ‘tifm_ms_write_data’: > drivers/memstick/host/tifm_ms.c:168:15: warning: this statement may fall > through [-Wimplicit-fallthrough=] >host->io_pos++; >^~ > drivers/memstick/host/tifm_ms.c:169:2: note: here > case 2: > ^~~~ > drivers/memstick/host/tifm_ms.c:171:15: warning: this statement may fall > through [-Wimplicit-fallthrough=] >host->io_pos++; >^~ > drivers/memstick/host/tifm_ms.c:172:2: note: here > case 1: > ^~~~ > > Warning level 3 was used: -Wimplicit-fallthrough=3 > > This patch is part of the ongoing efforts to enable > -Wimplicit-fallthrough. > > Signed-off-by: Gustavo A. R. Silva Reviewed-by: Kees Cook -Kees > --- > drivers/memstick/host/jmb38x_ms.c | 2 ++ > drivers/memstick/host/tifm_ms.c | 2 ++ > 2 files changed, 4 insertions(+) > > diff --git a/drivers/memstick/host/jmb38x_ms.c > b/drivers/memstick/host/jmb38x_ms.c > index bcdca9fbef51..49c71f55489f 100644 > --- a/drivers/memstick/host/jmb38x_ms.c > +++ b/drivers/memstick/host/jmb38x_ms.c > @@ -259,9 +259,11 @@ static unsigned int jmb38x_ms_write_data(struct > jmb38x_ms_host *host, > case 3: > host->io_word[0] |= buf[off + 2] << 16; > host->io_pos++; > + /* fall through */ > case 2: > host->io_word[0] |= buf[off + 1] << 8; > host->io_pos++; > + /* fall through */ > case 1: > host->io_word[0] |= buf[off]; > host->io_pos++; > diff --git a/drivers/memstick/host/tifm_ms.c b/drivers/memstick/host/tifm_ms.c > index bed205849d02..1bbb2ead9556 100644 > --- a/drivers/memstick/host/tifm_ms.c > +++ b/drivers/memstick/host/tifm_ms.c > @@ -166,9 +166,11 @@ static unsigned int tifm_ms_write_data(struct tifm_ms > *host, > case 3: > host->io_word |= buf[off + 2] << 16; > host->io_pos++; > + /* fall through */ > case 2: > host->io_word |= buf[off + 1] << 8; > host->io_pos++; > + /* fall through */ > case 1: > host->io_word |= buf[off]; > host->io_pos++; > -- > 2.20.1 > -- Kees Cook
Re: [PATCH] reiserfs: Force type conversion in xattr_hash
On Tue, Apr 23, 2019 at 08:22:37PM +0530, Bharath Vedartham wrote: > > ISTR some discussions of reiserfs layout endianness problems, but > > that had been many years ago and I could be wrong; I _think_ > > the conclusion had been "it sucks, but we can't do anything > > without breaking existing filesystem images". Not sure if that > > was the same bug or something different, though. > > Hi Al, > > Thanks for your detailed explanation. I learnt quite a bit from it. > I agree we should not "supress" this bug. > > I have noticed in the reiserfs code that, a checksum mismatch only > causes a warning? Even if there is a checksum mismatch, data still is > copied to the buffer? > > What is the point of the checksum over here? reiserfs_warning(inode->i_sb, "jdm-20002", "Invalid hash for xattr (%s) associated " "with %k", name, INODE_PKEY(inode)); err = -EIO; IOW, reiserfs_xattr_get() fails on mismatch, not just whines into log.
Reply to this e-mail:mr.mikemo...@post.com
-- Did you authorize her? Did you ask Lynn hardy to claim your $3.215,995 on your behalf? Reply to this e-mail:mr.mikemo...@post.com --
Re: [PATCH] fuse: Add ioctl flag for compat ioctl with 64-bit time_t
On 23/04/2019 13:55, Miklos Szeredi wrote:
On Fri, Mar 1, 2019 at 6:08 PM Ian Abbott wrote:
Currently, a CUSE server running on a 64-bit kernel can tell when an
ioctl request comes from a process running a 32-bit ABI, but cannot tell
whether the requesting process is using legacy IA32 emulation or x32
ABI, for example. In particular, the server does not know the size of
the client process's `time_t` type.
For 64-bit kernels, the `FUSE_IOCTL_COMPAT` and `FUSE_IOCTL_32BIT` flags
are currently set in the ioctl input request (`struct fuse_ioctl_in`
member `flags`) for a 32-bit requesting process. This patch defines a
new flag `FUSE_IOCTL_COMPAT_64TIME` and sets it if the 32-bit requesting
process (running on a 64-bit kernel) uses a 64-bit `time_t` type.
Hi,
Thanks for the patch.
I think it should rather use in_x32_syscall() helper and follow that
naming because there's apparently at least one example in xfs of a
non-time_t related ioctl that varies between the x32 vs ia32.
Hi Miklos,
It is conceivable that COMPAT_USE_64BIT_TIME could be true for some
other arch/ABI (although currently it is only ever set for x86/x32).
Should it have separate flags for "compat 64-bit time" and "compat x32"
(even though that is currently redundant)?
Kind regards,
Ian.
Thanks,
Miklos
Signed-off-by: Ian Abbott
---
fs/fuse/file.c| 5 -
include/uapi/linux/fuse.h | 2 ++
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/fs/fuse/file.c b/fs/fuse/file.c
index 06096b60f1df..9777e7a19889 100644
--- a/fs/fuse/file.c
+++ b/fs/fuse/file.c
@@ -2576,8 +2576,11 @@ long fuse_do_ioctl(struct file *file, unsigned int cmd,
unsigned long arg,
#if BITS_PER_LONG == 32
inarg.flags |= FUSE_IOCTL_32BIT;
#else
- if (flags & FUSE_IOCTL_COMPAT)
+ if (flags & FUSE_IOCTL_COMPAT) {
inarg.flags |= FUSE_IOCTL_32BIT;
+ if (COMPAT_USE_64BIT_TIME)
+ inarg.flags |= FUSE_IOCTL_COMPAT_64TIME;
+ }
#endif
/* assume all the iovs returned by client always fits in a page */
diff --git a/include/uapi/linux/fuse.h b/include/uapi/linux/fuse.h
index 2ac598614a8f..1f4a71486601 100644
--- a/include/uapi/linux/fuse.h
+++ b/include/uapi/linux/fuse.h
@@ -335,6 +335,7 @@ struct fuse_file_lock {
* FUSE_IOCTL_RETRY: retry with new iovecs
* FUSE_IOCTL_32BIT: 32bit ioctl
* FUSE_IOCTL_DIR: is a directory
+ * FUSE_IOCTL_COMPAT_64TIME: 32bit compat ioctl with 64bit time_t
*
* FUSE_IOCTL_MAX_IOV: maximum of in_iovecs + out_iovecs
*/
@@ -343,6 +344,7 @@ struct fuse_file_lock {
#define FUSE_IOCTL_RETRY (1 << 2)
#define FUSE_IOCTL_32BIT (1 << 3)
#define FUSE_IOCTL_DIR (1 << 4)
+#define FUSE_IOCTL_COMPAT_64TIME (1 << 5)
#define FUSE_IOCTL_MAX_IOV 256
--
2.20.1
--
-=( Ian Abbott || Web: www.mev.co.uk )=-
-=( MEV Ltd. is a company registered in England & Wales. )=-
-=( Registered number: 02862268. Registered address:)=-
-=( 15 West Park Road, Bramhall, STOCKPORT, SK7 3JZ, UK. )=-
Re: [PATCH 1/3] remap: Add I3C bus support
On Tue, 23 Apr 2019 14:58:06 + Vitor Soares wrote: > Hi Mark, > > From: Mark Brown > Date: Tue, Apr 16, 2019 at 16:39:48 > > > On Mon, Apr 15, 2019 at 09:19:39PM +0200, Vitor Soares wrote: > > > > > +++ b/drivers/base/regmap/regmap-i3c.c > > > @@ -0,0 +1,62 @@ > > > +// SPDX-License-Identifier: GPL-2.0 > > > +/* > > > + * Copyright (c) 2018 Synopsys, Inc. and/or its affiliates. > > > > Please make the entire header C++ style so it looks more consistent. > > Otherwise this looks good modulo > > I will change it next drop. > > > Boris' comment; I'm fine with leaving > > extra modes for later so long as they can be introduced without > > disrupting existing users so the only question there would be if we > > should name the init function in some way that's specific to the I/O > > mode being used here. > > My concern is that booth modes (SDR/HDR) might be needed on the device. > e.g. use SDR to configure the device and use HDR to send/receive large > data. I'd say that we shouldn't use the regmap abstraction in this case or have a driver-specific backend implementation for it. I guess the common case is "regs are accessed in SDR mode", so let's keep the name as it is now and we'll define devm_regmap_init_i3c_hdr() if we ever need it. Please make it explicit in the kernel-doc that we're using SDR transfers here.
Re: [PATCH] memstick: mark expected switch fall-throughs
Hi all, If no one cares, I'll add this to my tree for 5.2. Thanks -- Gustavo On 3/20/19 12:40 PM, Gustavo A. R. Silva wrote: > Hi, > > Friendly ping: > > Who can take this? > > Thanks > -- > Gustavo > > On 2/12/19 8:57 PM, Gustavo A. R. Silva wrote: >> In preparation to enabling -Wimplicit-fallthrough, mark switch >> cases where we are expecting to fall through. >> >> This patch fixes the following warnings: >> >> drivers/memstick/host/jmb38x_ms.c: In function ‘jmb38x_ms_write_data’: >> drivers/memstick/host/jmb38x_ms.c:261:15: warning: this statement may fall >> through [-Wimplicit-fallthrough=] >>host->io_pos++; >>^~ >> drivers/memstick/host/jmb38x_ms.c:262:2: note: here >> case 2: >> ^~~~ >> drivers/memstick/host/jmb38x_ms.c:264:15: warning: this statement may fall >> through [-Wimplicit-fallthrough=] >>host->io_pos++; >>^~ >> drivers/memstick/host/jmb38x_ms.c:265:2: note: here >> case 1: >> ^~~~ >> drivers/memstick/host/tifm_ms.c: In function ‘tifm_ms_write_data’: >> drivers/memstick/host/tifm_ms.c:168:15: warning: this statement may fall >> through [-Wimplicit-fallthrough=] >>host->io_pos++; >>^~ >> drivers/memstick/host/tifm_ms.c:169:2: note: here >> case 2: >> ^~~~ >> drivers/memstick/host/tifm_ms.c:171:15: warning: this statement may fall >> through [-Wimplicit-fallthrough=] >>host->io_pos++; >>^~ >> drivers/memstick/host/tifm_ms.c:172:2: note: here >> case 1: >> ^~~~ >> >> Warning level 3 was used: -Wimplicit-fallthrough=3 >> >> This patch is part of the ongoing efforts to enable >> -Wimplicit-fallthrough. >> >> Signed-off-by: Gustavo A. R. Silva >> --- >> drivers/memstick/host/jmb38x_ms.c | 2 ++ >> drivers/memstick/host/tifm_ms.c | 2 ++ >> 2 files changed, 4 insertions(+) >> >> diff --git a/drivers/memstick/host/jmb38x_ms.c >> b/drivers/memstick/host/jmb38x_ms.c >> index bcdca9fbef51..49c71f55489f 100644 >> --- a/drivers/memstick/host/jmb38x_ms.c >> +++ b/drivers/memstick/host/jmb38x_ms.c >> @@ -259,9 +259,11 @@ static unsigned int jmb38x_ms_write_data(struct >> jmb38x_ms_host *host, >> case 3: >> host->io_word[0] |= buf[off + 2] << 16; >> host->io_pos++; >> +/* fall through */ >> case 2: >> host->io_word[0] |= buf[off + 1] << 8; >> host->io_pos++; >> +/* fall through */ >> case 1: >> host->io_word[0] |= buf[off]; >> host->io_pos++; >> diff --git a/drivers/memstick/host/tifm_ms.c >> b/drivers/memstick/host/tifm_ms.c >> index bed205849d02..1bbb2ead9556 100644 >> --- a/drivers/memstick/host/tifm_ms.c >> +++ b/drivers/memstick/host/tifm_ms.c >> @@ -166,9 +166,11 @@ static unsigned int tifm_ms_write_data(struct tifm_ms >> *host, >> case 3: >> host->io_word |= buf[off + 2] << 16; >> host->io_pos++; >> +/* fall through */ >> case 2: >> host->io_word |= buf[off + 1] << 8; >> host->io_pos++; >> +/* fall through */ >> case 1: >> host->io_word |= buf[off]; >> host->io_pos++; >>
Re: PING: Re: [PATCH] perf annotate: Fix build on 32 bit for BPF annotation
Em Tue, Apr 23, 2019 at 11:58:48AM -0300, Thadeu Lima de Souza Cascardo
escreveu:
> On Wed, Apr 03, 2019 at 09:34:02PM +, Song Liu wrote:
> >
> >
> > > On Apr 3, 2019, at 12:44 PM, Thadeu Lima de Souza Cascardo
> > > wrote:
> > >
> > > Commit 6987561c9e86 ("perf annotate: Enable annotation of BPF programs")
> > > adds
> > > support for BPF programs annotations but the new code does not build on
> > > 32-bit.
> > >
> > > Fixes: 6987561c9e86 ("perf annotate: Enable annotation of BPF programs")
> > > Signed-off-by: Thadeu Lima de Souza Cascardo
> >
> > Acked-by: Song Liu
> >
> > Thanks for the fix!
> > Song
> >
>
> Thanks for the ack.
>
> Pinging for getting this applied, as this is a build failure on i386.
Thanks, applied to perf/urgent.
- Arnaldo
Re: [rcu:dev.2019.04.16a 38/72] kernel/rcu/tree.c:2408:36: sparse: sparse: incorrect type in initializer (different address spaces)
On 2019-04-23 05:46:19 [-0700], Paul E. McKenney wrote:
> On Tue, Apr 23, 2019 at 06:33:33PM +0800, kbuild test robot wrote:
> > tree:
> > https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git
> > dev.2019.04.16a
> > head: ca8714f549be5a186d086a223184095759eb7094
> > commit: 9a1a31194644dfc6b8f19755ea44ecf84f37cf40 [38/72] rcu: Enable
> > elimination of Tree-RCU softirq processing
> > reproduce:
> > # apt-get install sparse
> > git checkout 9a1a31194644dfc6b8f19755ea44ecf84f37cf40
> > make ARCH=x86_64 allmodconfig
> > make C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__'
> >
> > If you fix the issue, kindly add following tag
> > Reported-by: kbuild test robot
> >
> >
> >
> > sparse warnings: (new ones prefixed by >>)
> >
> > >> kernel/rcu/tree.c:2408:36: sparse: sparse: incorrect type in initializer
> > >> (different address spaces) @@expected struct task_struct [noderef]
> > >> **store @@got struct task_struct [noderef] **store @@
>
> Line 2408 of kernel/rcu/tree.c for commit 9a1a31194644 ("rcu: Enable
> elimination of Tree-RCU softirq processing") is this:
>
> .store = _data.rcu_cpu_kthread_task,
>
> So I am having some difficulty understanding this sparse diagnostic.
>
> Help?
this helps
diff --git a/include/linux/smpboot.h b/include/linux/smpboot.h
index d0884b5250010..c2678e29807c1 100644
--- a/include/linux/smpboot.h
+++ b/include/linux/smpboot.h
@@ -29,7 +29,7 @@ struct smpboot_thread_data;
* @thread_comm: The base name of the thread
*/
struct smp_hotplug_thread {
- struct task_struct __percpu **store;
+ struct task_struct *__percpu *store;
struct list_headlist;
int (*thread_should_run)(unsigned int cpu);
void(*thread_fn)(unsigned int cpu);
I just need to find the correct words for it.
And yes, it is not RCU related…
> Thanx, Paul
Sebastian
Re: [PATCH] ext4: bad mount opts in no journal mode
ping?
On 4/11/19, 5:49 PM, "Debabrata Banerjee" wrote:
Fixes:
commit 1e381f60dad9 ("ext4: do not allow journal_opts for fs w/o journal")
Instead of removing EXT4_MOUNT_JOURNAL_CHECKSUM from s_def_mount_opt as
I assume was intended, all other options were blown away leading to
_ext4_show_options() output being incorrect. I don't see why this or
other journal related flags should be removed from s_def_mount_opt
regardless, it is only used for comparison to display opts, and we
already made sure they couldn't be set.
Signed-off-by: Debabrata Banerjee
---
fs/ext4/super.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/fs/ext4/super.c b/fs/ext4/super.c
index 6ed4eb81e674..63eef29666e0 100644
--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@ -4238,7 +4238,6 @@ static int ext4_fill_super(struct super_block *sb,
void *data, int silent)
"data=, fs mounted w/o journal");
goto failed_mount_wq;
}
- sbi->s_def_mount_opt &= EXT4_MOUNT_JOURNAL_CHECKSUM;
clear_opt(sb, JOURNAL_CHECKSUM);
clear_opt(sb, DATA_FLAGS);
sbi->s_journal = NULL;
--
2.21.0
Re: [PATCH v7 2/2] power_supply: platform/chrome: wilco_ec: Add charging config driver
Sebastian, On 22/4/19 20:07, Nick Crews wrote: > Add control of the charging algorithm used on Wilco devices. > See Documentation/ABI/testing/sysfs-class-power-wilco for the > userspace interface and other info. > > Signed-off-by: Nick Crews Reviewed-by: Enric Balletbo i Serra > --- > v6 changes: > -Remove CHARGE_MODE_ILLEGAL from enum charge_mode. It's not a > public type, and error checking could be performed in other ways. > -Split up the commit so properties are added in a first commit > -Move CONFIG_CHARGER_WILCO to the power/supply Kconfig > -Use PTR_ERR_OR_ZERO() macro in probe() > v5 changes: > -Remove OP_SYNC, it has no immediate use case. > -Merge properties.h into wilco-ec.h > -Remove enum get_set_sync_op from the public interface, > since without OP_SYNC they are irrelevant. > -Fix Kconfigs and Makefiles so they actually work > with the v4 changes > -Tweak some formatting, spacing, and comments > -Fix validation of charge_type so illegal values > can't be set. Before negative error codes were > accidentally getting casted to positive numbers > -Remove more unneeded parentheses. > v4 changes: > -Use put_unaligned_le32() to store PID in request. > -Move implementation from > drivers/platform/chrome/wilco_ec/charge_config.c to > drivers/power/supply/wilco_charger.c > -Move drivers/platform/chrome/wilco_ec/properties.h to > include/linux/platform_data/wilco-ec-properties.h > -Remove parentheses in switch statement in psp_val_to_charge_mode() > -Check for any negatvie return code from psp_val_to_charge_mode() > instead of just -EINVAL so its less brittle > -Tweak comments in wilco-ec-properties.h > v3 changes: > -Add this changelog > -Fix commit message tags > v2 changes: > -Update Documentation to say KernelVersion 5.2 > -Update Documentation to explain Trickle mode better. > -rename things from using *PCC* to *CHARGE* > -Split up conversions between POWER_SUPPLY_PROP_CHARGE_TYPE values > and Wilco EC codes > -Use devm_ flavor of power_supply_register(), which simplifies things > -Add extra error checking on property messages received from the EC > -Fix bug in memcpy() calls in properties.c > -Refactor fill_property_id() > -Add valid input checks to charge_type > -Properly convert charge_type when get()ting > > .../ABI/testing/sysfs-class-power-wilco | 30 +++ > drivers/platform/chrome/wilco_ec/core.c | 13 ++ > drivers/power/supply/Kconfig | 9 + > drivers/power/supply/Makefile | 1 + > drivers/power/supply/wilco-charger.c | 187 ++ > include/linux/platform_data/wilco-ec.h| 2 + This touches two subsystems. Sebastian, what is your preference to handle this? Go all through power/supply? or chrome-platform tree? Or do you prefer have this split between subsystems (I think is possible in this case). All this after you're fine with it, of course. > 6 files changed, 242 insertions(+) > create mode 100644 Documentation/ABI/testing/sysfs-class-power-wilco > create mode 100644 drivers/power/supply/wilco-charger.c > > diff --git a/Documentation/ABI/testing/sysfs-class-power-wilco > b/Documentation/ABI/testing/sysfs-class-power-wilco > new file mode 100644 > index ..7f3b01310476 > --- /dev/null > +++ b/Documentation/ABI/testing/sysfs-class-power-wilco > @@ -0,0 +1,30 @@ > +What:/sys/class/power_supply/wilco_charger/charge_type > +Date:April 2019 > +KernelVersion: 5.2 > +Description: > + What charging algorithm to use: > + > + Standard: Fully charges battery at a standard rate. > + Adaptive: Battery settings adaptively optimized based on > + typical battery usage pattern. > + Fast: Battery charges over a shorter period. > + Trickle: Extends battery lifespan, intended for users who > + primarily use their Chromebook while connected to AC. > + Custom: A low and high threshold percentage is specified. > + Charging begins when level drops below > + charge_control_start_threshold, and ceases when > + level is above charge_control_end_threshold. > + > +What: > /sys/class/power_supply/wilco_charger/charge_control_start_threshold > +Date:April 2019 > +KernelVersion: 5.2 > +Description: > + Used when charge_type="Custom", as described above. Measured in > + percentages. The valid range is [50, 95]. > + > +What: > /sys/class/power_supply/wilco_charger/charge_control_end_threshold > +Date:April 2019 > +KernelVersion: 5.2 > +Description: > + Used when charge_type="Custom", as described above. Measured in > + percentages. The valid range is [55, 100]. > diff --git a/drivers/platform/chrome/wilco_ec/core.c > b/drivers/platform/chrome/wilco_ec/core.c > index
RE: [PATCH 1/3] remap: Add I3C bus support
Hi Mark, From: Mark Brown Date: Tue, Apr 16, 2019 at 16:39:48 > On Mon, Apr 15, 2019 at 09:19:39PM +0200, Vitor Soares wrote: > > > +++ b/drivers/base/regmap/regmap-i3c.c > > @@ -0,0 +1,62 @@ > > +// SPDX-License-Identifier: GPL-2.0 > > +/* > > + * Copyright (c) 2018 Synopsys, Inc. and/or its affiliates. > > Please make the entire header C++ style so it looks more consistent. > Otherwise this looks good modulo I will change it next drop. > Boris' comment; I'm fine with leaving > extra modes for later so long as they can be introduced without > disrupting existing users so the only question there would be if we > should name the init function in some way that's specific to the I/O > mode being used here. My concern is that booth modes (SDR/HDR) might be needed on the device. e.g. use SDR to configure the device and use HDR to send/receive large data. Best regards, Vitor Soares
PING: Re: [PATCH] perf annotate: Fix build on 32 bit for BPF annotation
On Wed, Apr 03, 2019 at 09:34:02PM +, Song Liu wrote:
>
>
> > On Apr 3, 2019, at 12:44 PM, Thadeu Lima de Souza Cascardo
> > wrote:
> >
> > Commit 6987561c9e86 ("perf annotate: Enable annotation of BPF programs")
> > adds
> > support for BPF programs annotations but the new code does not build on
> > 32-bit.
> >
> > Fixes: 6987561c9e86 ("perf annotate: Enable annotation of BPF programs")
> > Signed-off-by: Thadeu Lima de Souza Cascardo
>
> Acked-by: Song Liu
>
> Thanks for the fix!
> Song
>
Thanks for the ack.
Pinging for getting this applied, as this is a build failure on i386.
Thanks.
Cascardo.
> > ---
> > tools/perf/util/annotate.c | 8
> > 1 file changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/tools/perf/util/annotate.c b/tools/perf/util/annotate.c
> > index c8b01176c9e1..09762985c713 100644
> > --- a/tools/perf/util/annotate.c
> > +++ b/tools/perf/util/annotate.c
> > @@ -1714,8 +1714,8 @@ static int symbol__disassemble_bpf(struct symbol *sym,
> > if (dso->binary_type != DSO_BINARY_TYPE__BPF_PROG_INFO)
> > return -1;
> >
> > - pr_debug("%s: handling sym %s addr %lx len %lx\n", __func__,
> > -sym->name, sym->start, sym->end - sym->start);
> > + pr_debug("%s: handling sym %s addr %" PRIx64 " len %" PRIx64 "\n",
> > __func__,
> > + sym->name, sym->start, sym->end - sym->start);
> >
> > memset(tpath, 0, sizeof(tpath));
> > perf_exe(tpath, sizeof(tpath));
> > @@ -1740,7 +1740,7 @@ static int symbol__disassemble_bpf(struct symbol *sym,
> > info_linear = info_node->info_linear;
> > sub_id = dso->bpf_prog.sub_id;
> >
> > - info.buffer = (void *)(info_linear->info.jited_prog_insns);
> > + info.buffer = (void *)(uintptr_t)(info_linear->info.jited_prog_insns);
> > info.buffer_length = info_linear->info.jited_prog_len;
> >
> > if (info_linear->info.nr_line_info)
> > @@ -1776,7 +1776,7 @@ static int symbol__disassemble_bpf(struct symbol *sym,
> > const char *srcline;
> > u64 addr;
> >
> > - addr = pc + ((u64 *)(info_linear->info.jited_ksyms))[sub_id];
> > + addr = pc + ((u64
> > *)(uintptr_t)(info_linear->info.jited_ksyms))[sub_id];
> > count = disassemble(pc, );
> >
> > if (prog_linfo)
> > --
> > 2.20.1
> >
>
Re: [RESEND1, PATCH 1/2] fuse: convert printk -> pr_*
On Wed, Mar 27, 2019 at 10:15 AM Kirill Smelkov wrote: > > Functions, like pr_err, are a more modern variant of printing compared to > printk. They could be used to denoise sources by using needed level in > the print function name, and by automatically inserting per-driver / > function / ... print prefix as defined by pr_fmt macro. pr_* are also > said to be used in Documentation/process/coding-style.rst and more > recent code - for example overlayfs - uses them instead of printk. > > Convert CUSE and FUSE to use the new pr_* functions. > > CUSE output stays completely unchanged, while FUSE output is amended a > bit for "trying to steal weird page" warning - the second line now comes > also with "fuse:" prefix. I hope it is ok. Yep. Applied, thanks. Miklos
[PATCH] Input: walkera0701 - Fix possible NULL pointer dereference in walkera0701_detach
From: YueHaibing
KASAN report this:
walkera0701: failed to allocate input device
kasan: CONFIG_KASAN_INLINE enabled
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault: [#1] SMP KASAN PTI
CPU: 1 PID: 5324 Comm: syz-executor.0 Tainted: G C5.1.0-rc3+ #8
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1
04/01/2014
RIP: 0010:input_unregister_device+0x21/0xe0 drivers/input/input.c:2192
Code: 2e 0f 1f 84 00 00 00 00 00 53 48 89 fb e8 07 41 f6 fe 48 8d bb 20 07 00
00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 08
84 c0 0f 8e 92 00 00 00 80 bb 20 07 00 00
RSP: 0018:8881f58dfd30 EFLAGS: 00010206
RAX: dc00 RBX: RCX: 82460ca9
RDX: 00e4 RSI: c900013d3000 RDI: 0720
RBP: R08: ed103d30caf7 R09:
R10: R11: R12: dc00
R13: c1633000 R14: c086b320 R15: 11103eb1bfaf
FS: 7fa407200700() GS:8881f730() knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: 001b33924000 CR3: 0001e270c006 CR4: 007606e0
DR0: DR1: DR2:
DR3: DR6: fffe0ff0 DR7: 0400
PKRU: 5554
Call Trace:
walkera0701_detach+0x8e/0xba [walkera0701]
port_detach+0x73/0x90 [parport]
bus_for_each_dev+0x154/0x1e0 drivers/base/bus.c:304
parport_unregister_driver+0x1f8/0x270 [parport]
__do_sys_delete_module kernel/module.c:1018 [inline]
__se_sys_delete_module kernel/module.c:961 [inline]
__x64_sys_delete_module+0x30c/0x480 kernel/module.c:961
do_syscall_64+0x9f/0x450 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x462e99
Code: f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 48 89 f8 48 89 f7 48
89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01
c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48
RSP: 002b:7fa4071ffc58 EFLAGS: 0246 ORIG_RAX: 00b0
RAX: ffda RBX: 0073bf00 RCX: 00462e99
RDX: RSI: RDI: 21c0
RBP: 0002 R08: R09:
R10: R11: 0246 R12: 7fa4072006bc
R13: 004bcca9 R14: 006f6b48 R15:
Modules linked in: walkera0701(-) tps65090_regulator intel_th mptbase adm1031
snd_soc_wm8753 snd_soc_core snd_pcm_dmaengine snd_pcm ac97_bus snd_compress
rtc_ds1286 snd_seq_dummy snd_seq snd_timer snd_seq_device snd soundcore
comedi(C) i2c_mux_ltc4306 i2c_mux max14577_regulator max14577 usbcore hid cmac
mc13783_regulator mc13xxx_regulator_core mc13xxx_core of_mdio fixed_phy libphy
iptable_security iptable_raw iptable_mangle iptable_nat nf_nat nf_conntrack
nf_defrag_ipv6 nf_defrag_ipv4 iptable_filter bpfilter ip6_vti ip_vti ip_gre
ipip sit tunnel4 ip_tunnel hsr veth netdevsim vxcan batman_adv cfg80211 rfkill
chnl_net caif nlmon dummy team bonding vcan bridge stp llc ip6_gre gre
ip6_tunnel tunnel6 tun joydev mousedev ppdev tpm kvm_intel kvm irqbypass
crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel ide_pci_generic
aesni_intel aes_x86_64 piix crypto_simd cryptd input_leds ide_core psmouse
glue_helper intel_agp serio_raw intel_gtt ata_generic agpgart i2c_piix4
pata_acpi parport_pc parport floppy rtc_cmos sch_fq_codel ip_tables x_tables
sha1_ssse3 sha1_generic ipv6 [last unloaded: walkera0701]
Dumping ftrace buffer:
(ftrace buffer empty)
---[ end trace 17f6dd401f34af3e ]---
In walkera0701_attach(), if input_allocate_device failed,
w->input_dev is set to NULL. But in walkera0701_detach it
is not checked while passing to input_unregister_device(),
this will trigger a NULL pointer dereference issue.
There is also another possible use-after-free issue, when
input_register_device() fails, input_free_device be
called to free input dev, then in walkera0701_detach()
calling input_unregister_device will trigger use-after-free
while accessing input dev
This patch set w->parport to NULL on walkera0701_attach failed,
and only do detach in case attach success.
Reported-by: Hulk Robot
Fixes: 221bcb24c653 ("Input: walkera0701 - use parallel port device model")
Signed-off-by: YueHaibing
---
drivers/input/joystick/walkera0701.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/input/joystick/walkera0701.c
b/drivers/input/joystick/walkera0701.c
index dce313d..852b8c5 100644
--- a/drivers/input/joystick/walkera0701.c
+++ b/drivers/input/joystick/walkera0701.c
@@ -207,13 +207,13 @@ static void walkera0701_attach(struct parport *pp)
if (pp->number != walkera0701_pp_no) {
pr_debug("Not using parport%d.\n", pp->number);
- return;
+ goto err_out;
}
if (pp->irq == -1) {
Re: [PATCH v3 1/2] thermal: rcar_gen3_thermal: fix interrupt type
Hi Jiada,
On Tue, Apr 23, 2019 at 11:14:13PM +0900, Jiada Wang wrote:
> Currently IRQF_SHARED type interrupt line is allocated, but it
> is not appropriate, as the interrupt line isn't shared between
> different devices, instead IRQF_ONESHOT is the proper type.
>
> By changing interrupt type to IRQF_ONESHOT, now irq handler is
> no longer needed, as clear of interrupt status can be done in
> threaded interrupt context.
>
> Because IRQF_ONESHOT type interrupt line is kept disabled until
> the threaded handler has been run, so there is no need to protect
> read/write of REG_GEN3_IRQSTR with lock.
>
> Signed-off-by: Jiada Wang
> ---
> drivers/thermal/rcar_gen3_thermal.c | 34 +
> 1 file changed, 6 insertions(+), 28 deletions(-)
>
> diff --git a/drivers/thermal/rcar_gen3_thermal.c
> b/drivers/thermal/rcar_gen3_thermal.c
> index 88fa41cf16e8..ebbaef5a3cf1 100644
> --- a/drivers/thermal/rcar_gen3_thermal.c
> +++ b/drivers/thermal/rcar_gen3_thermal.c
> @@ -231,39 +231,17 @@ static void rcar_thermal_irq_set(struct
> rcar_gen3_thermal_priv *priv, bool on)
> static irqreturn_t rcar_gen3_thermal_irq(int irq, void *data)
> {
> struct rcar_gen3_thermal_priv *priv = data;
> + int i;
> u32 status;
> - int i, ret = IRQ_HANDLED;
nit: why not keeping 'int i' on the same line?
>
> - spin_lock(>lock);
[..]
> - spin_unlock(>lock);
[..]
> - spin_lock_irqsave(>lock, flags);
[..]
> - spin_unlock_irqrestore(>lock, flags);
[..]
FWIW, after applying the patch, the 'spinlock_t lock' member of
'struct rcar_gen3_thermal_priv' is no longer used in the driver, except
to initialize it in probe. Is there any usage expected in future or
should it be zapped?
--
Best regards,
Eugeniu.
Re: [PATCH] reiserfs: Force type conversion in xattr_hash
On Mon, Apr 22, 2019 at 12:27:05PM -0700, Andrew Morton wrote: > On Sun, 21 Apr 2019 18:02:35 +0100 Al Viro wrote: > > > IOW, what sparse has caught here is a genuine endianness bug; images > > created on little-endian host and mounted on big-endian (or vice > > versa) will see csum mismatches when trying to fetch xattrs. > > OK, thanks. I'll drop the patch - we shouldn't hide that reminder of a > bug. > > Perhaps someone could prepare a patch which adds a comment explaining > these issues, so someone else doesn't try to "fix" the sparse warning. > Hi Andrew, I will send a patch CCing Al to add a comment explaining these issues. Thanks Bharath
Re: [PATCH 06/12] perf tools: Do not erase uncovered maps by kcore
On Tue, Apr 23, 2019 at 12:32:12PM +0300, Adrian Hunter wrote:
> On 16/04/19 7:01 PM, Jiri Olsa wrote:
> > Maps in kcore do not cover bpf maps, so we can't just
> > remove everything. Keeping all kernel maps, which are
> > not covered by kcore maps.
>
> Memory for jited-bpf is allocated from the same area that is used for
> modules. In the case of /proc/kcore, that entire area is mapped, so there
> won't be any bpf-maps that are not covered. For copies of kcore made by
> 'perf buildid-cache' the same would be true for any bpf that got allocated
> in between modules.
>
> But shouldn't the bpf map supersede the kcore map for the address range that
> it maps? I guess that would mean splitting the kcore map, truncating the
> first piece and inserting the bpf map in between.
I haven't considered it could get in between modules,
I think you're right and we need to cut kcore maps
in case bpf is mapped within.. I'll submit new version
thanks,
jirka
>
> >
> > Link: http://lkml.kernel.org/n/tip-9eytka8wofp0a047ul6lm...@git.kernel.org
> > Signed-off-by: Jiri Olsa
> > ---
> > tools/perf/util/symbol.c | 14 +-
> > 1 file changed, 13 insertions(+), 1 deletion(-)
> >
> > diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
> > index 5cbad55cd99d..96738a7a8c14 100644
> > --- a/tools/perf/util/symbol.c
> > +++ b/tools/perf/util/symbol.c
> > @@ -1166,6 +1166,18 @@ static int kcore_mapfn(u64 start, u64 len, u64
> > pgoff, void *data)
> > return 0;
> > }
> >
> > +static bool in_kcore(struct kcore_mapfn_data *md, struct map *map)
> > +{
> > + struct map *iter;
> > +
> > + list_for_each_entry(iter, >maps, node) {
> > + if ((map->start >= iter->start) && (map->start < iter->end))
> > + return true;
> > + }
> > +
> > + return false;
> > +}
> > +
> > static int dso__load_kcore(struct dso *dso, struct map *map,
> >const char *kallsyms_filename)
> > {
> > @@ -1222,7 +1234,7 @@ static int dso__load_kcore(struct dso *dso, struct
> > map *map,
> > while (old_map) {
> > struct map *next = map_groups__next(old_map);
> >
> > - if (old_map != map)
> > + if (old_map != map && !in_kcore(, old_map))
> > map_groups__remove(kmaps, old_map);
> > old_map = next;
> > }
> >
>
Re: [PATCH v2 7/8] s390: vfio-ap: handle bind and unbind of AP queue device
On 4/23/19 9:38 AM, Pierre Morel wrote:
On 20/04/2019 23:49, Tony Krowiak wrote:
There is an implied guarantee that when an AP queue device is bound to a
device driver, that driver will have exclusive control over the device.
When an AP queue device is unbound from the vfio_ap driver while the
queue is in use by a guest and subsquently bound to a zcrypt driver, the
guarantee that the zcrypt driver has exclusive control of the queue
device will be violated. Likewise, when an AP queue device is bound to
the vfio_ap device driver and its APQN is assigned to an mdev device in
use by a guest, the expectation is that the guest will have access to
the queue.
The purpose of this patch is to ensure three things:
1. When an AP queue device in use by a guest is unbound, the guest shall
no longer access the queue. Due to the limitations of the
architecture, access to a single queue can not be denied to a guest,
so access to the AP card to which the queue is connected will be
denied to the guest.
2. When an AP queue device with an APQN assigned to an mdev device is
bound to the vfio_ap driver while the mdev device is in use by a
guest,
the guest shall be granted access to the queue.
3. When a guest is started, each APQN assigned to the guest's mdev device
must be owned by the vfio_ap driver.
Signed-off-by: Tony Krowiak
---
drivers/s390/crypto/vfio_ap_drv.c | 16 ++-
drivers/s390/crypto/vfio_ap_ops.c | 82
++-
drivers/s390/crypto/vfio_ap_private.h | 2 +
3 files changed, 97 insertions(+), 3 deletions(-)
diff --git a/drivers/s390/crypto/vfio_ap_drv.c
b/drivers/s390/crypto/vfio_ap_drv.c
index e9824c35c34f..0f5dafddf5b1 100644
--- a/drivers/s390/crypto/vfio_ap_drv.c
+++ b/drivers/s390/crypto/vfio_ap_drv.c
@@ -42,12 +42,26 @@ MODULE_DEVICE_TABLE(vfio_ap, ap_queue_ids);
static int vfio_ap_queue_dev_probe(struct ap_device *apdev)
{
+ struct ap_queue *apq = to_ap_queue(>device);
+ unsigned long apid = AP_QID_CARD(apq->qid);
+ unsigned long apqi = AP_QID_QUEUE(apq->qid);
+
+ mutex_lock(_dev->lock);
+ vfio_ap_mdev_probe_queue(apid, apqi);
+ mutex_unlock(_dev->lock);
+
return 0;
}
static void vfio_ap_queue_dev_remove(struct ap_device *apdev)
{
- /* Nothing to do yet */
+ struct ap_queue *apq = to_ap_queue(>device);
+ unsigned long apid = AP_QID_CARD(apq->qid);
+ unsigned long apqi = AP_QID_QUEUE(apq->qid);
+
+ mutex_lock(_dev->lock);
+ vfio_ap_mdev_remove_queue(apid, apqi);
+ mutex_unlock(_dev->lock);
}
static void vfio_ap_matrix_dev_release(struct device *dev)
diff --git a/drivers/s390/crypto/vfio_ap_ops.c
b/drivers/s390/crypto/vfio_ap_ops.c
index 31ce30ee784d..3f9506516545 100644
--- a/drivers/s390/crypto/vfio_ap_ops.c
+++ b/drivers/s390/crypto/vfio_ap_ops.c
@@ -763,8 +763,8 @@ static void vfio_ap_mdev_wait_for_qempty(unsigned
long apid, unsigned long apqi)
msleep(20);
break;
default:
- pr_warn("%s: tapq err %02x: 0x%04x may not be empty\n",
- __func__, status.response_code, q->apqn);
+ pr_warn("%s: tapq err %02x: %02lx%04lx may not be empty\n",
+ __func__, status.response_code, apid, apqi);
return;
}
} while (--retry);
@@ -823,6 +823,14 @@ static int vfio_ap_mdev_reset_queues(struct
mdev_device *mdev)
static int vfio_ap_mdev_create_shadow_crycb(struct ap_matrix_mdev
*matrix_mdev)
{
+ /*
+ * If an AP resource is not owned by the vfio_ap driver - e.g.,
it was
+ * unbound from the driver while still assigned to the mdev device
+ */
+ if (ap_apqn_in_matrix_owned_by_def_drv(matrix_mdev->matrix.apm,
+ matrix_mdev->matrix.aqm))
+ return -EADDRNOTAVAIL;
+
matrix_mdev->shadow_crycb =
kzalloc(sizeof(*matrix_mdev->shadow_crycb),
GFP_KERNEL);
if (!matrix_mdev->shadow_crycb)
@@ -847,6 +855,18 @@ static int vfio_ap_mdev_open(struct mdev_device
*mdev)
if (!try_module_get(THIS_MODULE))
return -ENODEV;
+ ret = ap_apqn_in_matrix_owned_by_def_drv(matrix_mdev->matrix.apm,
+ matrix_mdev->matrix.aqm);
+
+ /*
+ * If any APQN is owned by a default driver, it can not be used
by the
+ * guest. This can happen if a queue is unbound from the vfio_ap
+ * driver but not unassigned from the mdev device.
+ */
+ ret = (ret == 1) ? -EADDRNOTAVAIL : ret;
+ if (ret)
+ return ret;
+
matrix_mdev->group_notifier.notifier_call =
vfio_ap_mdev_group_notifier;
events = VFIO_GROUP_NOTIFY_SET_KVM;
@@ -938,3 +958,61 @@ void vfio_ap_mdev_unregister(void)
{
mdev_unregister_device(_dev->device);
}
+
+static struct ap_matrix_mdev *vfio_ap_mdev_find_matrix_mdev(unsigned
long apid,
+ unsigned long apqi)
+{
+ struct ap_matrix_mdev *matrix_mdev;
+
+
Re: [PATCH] reiserfs: Force type conversion in xattr_hash
On Sun, Apr 21, 2019 at 06:02:35PM +0100, Al Viro wrote:
> On Thu, Apr 18, 2019 at 03:50:19PM -0700, Andrew Morton wrote:
> > On Wed, 17 Apr 2019 17:22:00 +0530 Bharath Vedartham
> > wrote:
> >
> > > This patch fixes the sparse warning:
> > >
> > > fs/reiserfs//xattr.c:453:28: warning: incorrect type in return
> > > expression (different base types)
> > > fs/reiserfs//xattr.c:453:28:expected unsigned int
> > > fs/reiserfs//xattr.c:453:28:got restricted __wsum
> > > fs/reiserfs//xattr.c:453:28: warning: incorrect type in return
> > > expression (different base types)
> > > fs/reiserfs//xattr.c:453:28:expected unsigned int
> > > fs/reiserfs//xattr.c:453:28:got restricted __wsum
> > >
> > > csum_partial returns restricted integer __wsum whereas xattr_hash
> > > expects a return type of __u32.
> > >
> > > ...
> > >
> > > --- a/fs/reiserfs/xattr.c
> > > +++ b/fs/reiserfs/xattr.c
> > > @@ -450,7 +450,7 @@ static struct page *reiserfs_get_page(struct inode
> > > *dir, size_t n)
> > >
> > > static inline __u32 xattr_hash(const char *msg, int len)
> > > {
> > > - return csum_partial(msg, len, 0);
> > > + return (__force __u32)csum_partial(msg, len, 0);
> > > }
> > >
> > > int reiserfs_commit_write(struct file *f, struct page *page,
> >
> > hm. Conversion from int to __u32 should be OK - why is sparse being so
> > picky here?
>
> Because csum_partial() returns __wsum_t, not int.
>
> > Why is the __force needed, btw?
>
> So that accidental mixing of those csums (both 16bit and 32bit) with
> host- or net-endian would be caught.
>
> And I'm not at all sure reiserfs xattr_hash() doesn't bugger it up, actually.
>
> Recall that 16bit inet csum is the sum of 16bit words (treated as host-endian)
> modulo 0x, i.e. the entire buffer interpreted as host-endian integer
> taken modulo 0x. That has a lovely property - memory representation
> of that value is the same whether we'd done calculations on b-e or l-e
> host; the reason is that modulo 65535 byteswap is the same as multiplying
> by 256, so the sum of byteswapped 16bit values modulo 65535 is byteswapped
> sum of original values.
>
> csum_partial() is sum of 32bit words (treated as host-endian) modulo
> 0x,
> i.e. the entire buffer treated as host-endian number modulo 0x.
> It is convenient when we want to calculate the 16bit csum - 0x is
> a multiple of 0x, so residue modulo 0x determines the residue
> modulo 0x; that's what csum_fold() is.
>
> However, result of csum_partial() on big- and little-endian hosts
> does *not* have the same property. Consider e.g. an array {0, 0, 0, 128,
> 0, 0, 0, 128}. csum_partial of that on l-e will be (2^31 + 2^31)mod(2^32 -
> 1),
> i.e. 1, with {1, 0, 0, 0} as memory representation. 16bit csum will
> again be 1, with {1, 0} as memory representation. On big-endian we
> get (128 + 128)mod(2^32 - 1), i.e. 256, with {0, 0, 1, 0} as memory
> representation. 16bit csum is again 256, stored as {1, 0}, i.e.
> the same as if we'd done everything on l-e; however, raw csum_partial()
> values have different memory representations. They certainly are
> different as host-endian (and so are 16bit csums).
>
> Reiserfs takes csum_partial() on buffer, interprets it as host-endian
> and stores it little-endian on disk. When fetching those it does
> the same calculation and fails on mismatch. However, if the
> store had been done on little-endian host and load - on big-endian
> one we *will* get mismatch almost all the time. Treating ->rx_hash
> as __wsum_t (and not doing that cpu_to_le32()) would lower the
> frequency of mismatches, but still would be broken. Storing
> a 16bit csum (declared as __sum16_t, again, without cpu_to_le...())
> would be endian-safe, but that's not what reiserfs folks wanted
> (16 bits of csum instead of 32, for starters).
>
> IOW, what sparse has caught here is a genuine endianness bug; images
> created on little-endian host and mounted on big-endian (or vice
> versa) will see csum mismatches when trying to fetch xattrs.
> Broken since
> commit 0b1a6a8ca8a78c2e068b04acf97479ee89a024ac
> Author: Andrew Morton
> Date: Sun May 9 23:59:13 2004 -0700
>
> [PATCH] reiserfs: xattr support
>
> From: Chris Mason
>
> From: je...@suse.com
>
> reiserfs support for xattrs
>
> ISTR some discussions of reiserfs layout endianness problems, but
> that had been many years ago and I could be wrong; I _think_
> the conclusion had been "it sucks, but we can't do anything
> without breaking existing filesystem images". Not sure if that
> was the same bug or something different, though.
Hi Al,
Thanks for your detailed explanation. I learnt quite a bit from it.
I agree we should not "supress" this bug.
I have noticed in the reiserfs code that, a checksum mismatch only
causes a warning? Even if there is a checksum mismatch, data still is
copied to the buffer?
What is the point of the checksum over here?
[PATCH] Bluetooth: hci_h5: fix spelling mistake "sliped" -> "slipped"
From: Colin Ian King
There is a spelling mistake in a BT_DBG debug message. Fix it.
Signed-off-by: Colin Ian King
---
drivers/bluetooth/hci_h5.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/bluetooth/hci_h5.c b/drivers/bluetooth/hci_h5.c
index 069d1c8fde73..3f02ae560120 100644
--- a/drivers/bluetooth/hci_h5.c
+++ b/drivers/bluetooth/hci_h5.c
@@ -536,7 +536,7 @@ static void h5_unslip_one_byte(struct h5 *h5, unsigned char
c)
skb_put_data(h5->rx_skb, byte, 1);
h5->rx_pending--;
- BT_DBG("unsliped 0x%02hhx, rx_pending %zu", *byte, h5->rx_pending);
+ BT_DBG("unslipped 0x%02hhx, rx_pending %zu", *byte, h5->rx_pending);
}
static void h5_reset_rx(struct h5 *h5)
--
2.20.1
[PATCH v3] Staging: vc04_services: Cleanup in ctrl_set_bitrate()
Remove unnecessary variable from the function and make a corresponding
change w.r.t the variable. In addition to that align the parameters in
the parentheses to maintain Linux kernel coding style
Issue suggested by Coccinelle.
Signed-off-by: Madhumitha Prabakaran
---
Changes in v2 -
1) Fix my own error of removing function call from the variable.
2) Align the function parameters with parentheses.
Changes in v3 -
1) Since there was no real purpose of returning true value, replace it with
return value of the function vchiq_mmal_port_parameter_set().
---
drivers/staging/vc04_services/bcm2835-camera/controls.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/vc04_services/bcm2835-camera/controls.c
b/drivers/staging/vc04_services/bcm2835-camera/controls.c
index e39ab5fae724..2e0a422cdf3e 100644
--- a/drivers/staging/vc04_services/bcm2835-camera/controls.c
+++ b/drivers/staging/vc04_services/bcm2835-camera/controls.c
@@ -607,18 +607,15 @@ static int ctrl_set_bitrate(struct bm2835_mmal_dev *dev,
struct v4l2_ctrl *ctrl,
const struct bm2835_mmal_v4l2_ctrl *mmal_ctrl)
{
- int ret;
struct vchiq_mmal_port *encoder_out;
dev->capture.encode_bitrate = ctrl->val;
encoder_out = >component[MMAL_COMPONENT_VIDEO_ENCODE]->output[0];
- ret = vchiq_mmal_port_parameter_set(dev->instance, encoder_out,
- mmal_ctrl->mmal_id,
- >val, sizeof(ctrl->val));
- ret = 0;
- return ret;
+ return vchiq_mmal_port_parameter_set(dev->instance, encoder_out,
+mmal_ctrl->mmal_id, >val,
+sizeof(ctrl->val));
}
static int ctrl_set_bitrate_mode(struct bm2835_mmal_dev *dev,
--
2.17.1
Re: [PATCH v3 2/2] thermal: rcar_gen3_thermal: disable interrupt in .remove
On 04/23/2019 05:14 PM, Jiada Wang wrote: > Currently IRQ is remain enabled after .remove, later if device is probed, IRQ remains enabled. > IRQ is requested before .thermal_init, this may cause IRQ function be > called before device is initialized. > > this patch by disable interrupt in .remove, to ensure irq function s/by disable/disables/. > only be called after device is fully initialized. > > Signed-off-by: Jiada Wang [...] MBR, Sergei
Re: [PATCH v7 1/2] platform/chrome: wilco_ec: Add property helper library
On 22/4/19 20:07, Nick Crews wrote:
> A Property is typically a data item that is stored to NVRAM
> by the EC. Each of these data items has an index associated
> with it, known as the Property ID (PID). Properties may have
> variable lengths, up to a max of WILCO_EC_PROPERTY_MAX_SIZE
> bytes. Properties can be simple integers, or they may be more
> complex binary data.
>
> This patch adds support for getting and setting properties.
> This will be useful for setting the charge algorithm and charge
> schedules, which all use properties.
>
> Signed-off-by: Nick Crews
For my own reference:
Acked-for-chrome-by: Enric Balletbo i Serra
That means that this patch is pushed out as testing in for-next branch to let
the autobuilders play with it. If all goes well your patches would be in the
chrome-platform-5.2 or chrome-platform-5.3 (as we're already at rc6) branch
'soonish'.
Sebastian, note that this patch should be picked before you apply
[PATCH v7 2/2] power_supply: platform/chrome: wilco_ec: Add charging config
driver
So let me know if you plan to pick that for 5.2 or is more suitable for 5.3
Thanks,
Enric
> ---
> v7 changes:
> -Remove bogus gerrit FROMLIST tag in commit title
> v6 changes:
> -Add EC_* prefix to enum property_ops so they are more unique.
> -Split up the commit so properties are added in a first commit
> v5 changes:
> -Remove OP_SYNC, it has no immediate use case.
> -Merge properties.h into wilco-ec.h
> -Remove enum get_set_sync_op from the public interface,
> since without OP_SYNC they are irrelevant.
> -Fix Kconfigs and Makefiles so they actually work
> with the v4 changes
> -Tweak some formatting, spacing, and comments
> -Fix validation of charge_type so illegal values
> can't be set. Before negative error codes were
> accidentally getting casted to positive numbers
> -Remove more unneeded parentheses.
> v4 changes:
> -Use put_unaligned_le32() to store PID in request.
> -Move implementation from
> drivers/platform/chrome/wilco_ec/charge_config.c to
> drivers/power/supply/wilco_charger.c
> -Move drivers/platform/chrome/wilco_ec/properties.h to
> include/linux/platform_data/wilco-ec-properties.h
> -Remove parentheses in switch statement in psp_val_to_charge_mode()
> -Check for any negatvie return code from psp_val_to_charge_mode()
> instead of just -EINVAL so its less brittle
> -Tweak comments in wilco-ec-properties.h
> v3 changes:
> -Add this changelog
> -Fix commit message tags
> v2 changes:
> -Update Documentation to say KernelVersion 5.2
> -Update Documentation to explain Trickle mode better.
> -rename things from using *PCC* to *CHARGE*
> -Split up conversions between POWER_SUPPLY_PROP_CHARGE_TYPE values
> and Wilco EC codes
> -Use devm_ flavor of power_supply_register(), which simplifies things
> -Add extra error checking on property messages received from the EC
> -Fix bug in memcpy() calls in properties.c
> -Refactor fill_property_id()
> -Add valid input checks to charge_type
> -Properly convert charge_type when get()ting
>
> drivers/platform/chrome/wilco_ec/Makefile | 2 +-
> drivers/platform/chrome/wilco_ec/properties.c | 132 ++
> include/linux/platform_data/wilco-ec.h| 71 ++
> 3 files changed, 204 insertions(+), 1 deletion(-)
> create mode 100644 drivers/platform/chrome/wilco_ec/properties.c
>
> diff --git a/drivers/platform/chrome/wilco_ec/Makefile
> b/drivers/platform/chrome/wilco_ec/Makefile
> index 063e7fb4ea17..29b734137786 100644
> --- a/drivers/platform/chrome/wilco_ec/Makefile
> +++ b/drivers/platform/chrome/wilco_ec/Makefile
> @@ -1,6 +1,6 @@
> # SPDX-License-Identifier: GPL-2.0
>
> -wilco_ec-objs:= core.o mailbox.o
> +wilco_ec-objs:= core.o mailbox.o properties.o
> obj-$(CONFIG_WILCO_EC) += wilco_ec.o
> wilco_ec_debugfs-objs:= debugfs.o
> obj-$(CONFIG_WILCO_EC_DEBUGFS) += wilco_ec_debugfs.o
> diff --git a/drivers/platform/chrome/wilco_ec/properties.c
> b/drivers/platform/chrome/wilco_ec/properties.c
> new file mode 100644
> index ..e69682c95ea2
> --- /dev/null
> +++ b/drivers/platform/chrome/wilco_ec/properties.c
> @@ -0,0 +1,132 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright 2019 Google LLC
> + */
> +
> +#include
> +#include
> +#include
> +
> +/* Operation code; what the EC should do with the property */
> +enum ec_property_op {
> + EC_OP_GET = 0,
> + EC_OP_SET = 1,
> +};
> +
> +struct ec_property_request {
> + u8 op; /* One of enum ec_property_op */
> + u8 property_id[4]; /* The 32 bit PID is stored Little Endian */
> + u8 length;
> + u8 data[WILCO_EC_PROPERTY_MAX_SIZE];
> +} __packed;
> +
> +struct ec_property_response {
> + u8 reserved[2];
> + u8 op; /* One of enum ec_property_op */
> + u8 property_id[4]; /* The 32 bit PID is stored Little Endian */
> + u8 length;
> + u8
Re: clk/clk-next boot bisection: v5.1-rc1-142-ga55b079c961b on panda
* Stephen Boyd [691231 23:00]:
> Quoting kernelci.org bot (2019-04-22 17:16:44)
> > * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
> > * This automated bisection report was sent to you on the basis *
> > * that you may be involved with the breaking commit it has *
> > * found. No manual investigation has been done to verify it, *
> > * and the root cause of the problem may be somewhere else. *
> > * Hope this helps! *
> > * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
> >
> > clk/clk-next boot bisection: v5.1-rc1-142-ga55b079c961b on panda
> >
> > Summary:
> > Start: a55b079c961b Merge branch 'clk-hisi' into clk-next
> > Details:https://kernelci.org/boot/id/5cbe3cdb59b514fd22fe6025
> > Plain log:
> > https://storage.kernelci.org//clk/clk-next/v5.1-rc1-142-ga55b079c961b/arm/omap2plus_defconfig/gcc-7/lab-baylibre/boot-omap4-panda.txt
> > HTML log:
> > https://storage.kernelci.org//clk/clk-next/v5.1-rc1-142-ga55b079c961b/arm/omap2plus_defconfig/gcc-7/lab-baylibre/boot-omap4-panda.html
> > Result: ecbf3f1795fd clk: fixed-factor: Let clk framework find parent
> >
> > Checks:
> > revert: PASS
> > verify: PASS
> >
> > Parameters:
> > Tree: clk
> > URL:https://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git
> > Branch: clk-next
> > Target: panda
> > CPU arch: arm
> > Lab:lab-baylibre
> > Compiler: gcc-7
> > Config: omap2plus_defconfig
> > Test suite: boot
> >
> > Breaking commit found:
>
> Awesome! I LOVE IT!!!
This is great, thanks a lot!
Hmm do you guys have some index page of all the found "boot bisection"
issues that I can check every morning while drinking coffee? :)
> > diff --git a/drivers/clk/clk-fixed-factor.c b/drivers/clk/clk-fixed-factor.c
> > index 241b3f8c61a9..5b09f2cdb7de 100644
> > --- a/drivers/clk/clk-fixed-factor.c
> > +++ b/drivers/clk/clk-fixed-factor.c
> > @@ -64,12 +64,14 @@ const struct clk_ops clk_fixed_factor_ops = {
> > };
> > EXPORT_SYMBOL_GPL(clk_fixed_factor_ops);
> >
> > -struct clk_hw *clk_hw_register_fixed_factor(struct device *dev,
> > - const char *name, const char *parent_name, unsigned long
> > flags,
> > - unsigned int mult, unsigned int div)
> > +static struct clk_hw *
> > +__clk_hw_register_fixed_factor(struct device *dev, struct device_node *np,
> > + const char *name, const char *parent_name, int index,
> > + unsigned long flags, unsigned int mult, unsigned int div)
> > {
> > struct clk_fixed_factor *fix;
> > struct clk_init_data init;
> > + struct clk_parent_data pdata = { .index = index };
> > struct clk_hw *hw;
> > int ret;
> >
> > @@ -85,11 +87,17 @@ struct clk_hw *clk_hw_register_fixed_factor(struct
> > device *dev,
> > init.name = name;
> > init.ops = _fixed_factor_ops;
> > init.flags = flags | CLK_IS_BASIC;
> > - init.parent_names = _name;
> > + if (parent_name)
> > + init.parent_names = _name;
> > + else
> > + init.parent_data =
>
> Ick. I realized that 'init.parent_names' here can be full of junk! Let's
> initialize it properly. Maybe that makes this all better?
Tested-by: Tony Lindgren
> 8<
> diff --git a/drivers/clk/clk-fixed-factor.c b/drivers/clk/clk-fixed-factor.c
> index 5b09f2cdb7de..2d988a7585d5 100644
> --- a/drivers/clk/clk-fixed-factor.c
> +++ b/drivers/clk/clk-fixed-factor.c
> @@ -70,7 +70,7 @@ __clk_hw_register_fixed_factor(struct device *dev, struct
> device_node *np,
> unsigned long flags, unsigned int mult, unsigned int div)
> {
> struct clk_fixed_factor *fix;
> - struct clk_init_data init;
> + struct clk_init_data init = { };
> struct clk_parent_data pdata = { .index = index };
> struct clk_hw *hw;
> int ret;
Re: [PATCH v4 05/12] soc: mediatek: cmdq: move the CMDQ_IRQ_MASK into cmdq driver data
Subject should be:
mailbox: mediatek: cmdq: move the CMDQ_IRQ_MASK into cmdq driver data
Regards,
Matthias
On 15/04/2019 14:58, Bibby Hsieh wrote:
> The interrupt mask and thread number has positive correlation,
> so we move the CMDQ_IRQ_MASK into cmdq driver data and calculate
> it by thread number.
>
> Signed-off-by: Bibby Hsieh
> ---
> drivers/mailbox/mtk-cmdq-mailbox.c | 12 +++-
> 1 file changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/mailbox/mtk-cmdq-mailbox.c
> b/drivers/mailbox/mtk-cmdq-mailbox.c
> index 22811784dc7d..87617dc7504d 100644
> --- a/drivers/mailbox/mtk-cmdq-mailbox.c
> +++ b/drivers/mailbox/mtk-cmdq-mailbox.c
> @@ -17,7 +17,6 @@
> #include
>
> #define CMDQ_OP_CODE_MASK(0xff << CMDQ_OP_CODE_SHIFT)
> -#define CMDQ_IRQ_MASK0x
> #define CMDQ_NUM_CMD(t) (t->cmd_buf_size /
> CMDQ_INST_SIZE)
>
> #define CMDQ_CURR_IRQ_STATUS 0x10
> @@ -71,6 +70,7 @@ struct cmdq {
> void __iomem*base;
> u32 irq;
> u32 thread_nr;
> + u32 irq_mask;
> struct cmdq_thread *thread;
> struct clk *clock;
> boolsuspended;
> @@ -284,11 +284,11 @@ static irqreturn_t cmdq_irq_handler(int irq, void *dev)
> unsigned long irq_status, flags = 0L;
> int bit;
>
> - irq_status = readl(cmdq->base + CMDQ_CURR_IRQ_STATUS) & CMDQ_IRQ_MASK;
> - if (!(irq_status ^ CMDQ_IRQ_MASK))
> + irq_status = readl(cmdq->base + CMDQ_CURR_IRQ_STATUS) & cmdq->irq_mask;
> + if (!(irq_status ^ cmdq->irq_mask))
> return IRQ_NONE;
>
> - for_each_clear_bit(bit, _status, fls(CMDQ_IRQ_MASK)) {
> + for_each_clear_bit(bit, _status, cmdq->thread_nr) {
> struct cmdq_thread *thread = >thread[bit];
>
> spin_lock_irqsave(>chan->lock, flags);
> @@ -472,6 +472,9 @@ static int cmdq_probe(struct platform_device *pdev)
> dev_err(dev, "failed to get irq\n");
> return -EINVAL;
> }
> +
> + cmdq->thread_nr = (u32)(unsigned long)of_device_get_match_data(dev);
> + cmdq->irq_mask = GENMASK(cmdq->thread_nr - 1, 0);
> err = devm_request_irq(dev, cmdq->irq, cmdq_irq_handler, IRQF_SHARED,
> "mtk_cmdq", cmdq);
> if (err < 0) {
> @@ -488,7 +491,6 @@ static int cmdq_probe(struct platform_device *pdev)
> return PTR_ERR(cmdq->clock);
> }
>
> - cmdq->thread_nr = (u32)(unsigned long)of_device_get_match_data(dev);
> cmdq->mbox.dev = dev;
> cmdq->mbox.chans = devm_kcalloc(dev, cmdq->thread_nr,
> sizeof(*cmdq->mbox.chans), GFP_KERNEL);
>
[PATCH -next] agp/uninorth: remove set but not used variable 'size'
From: YueHaibing
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/char/agp/uninorth-agp.c: In function 'uninorth_create_gatt_tablei':
drivers/char/agp/uninorth-agp.c:371:6: warning: variable 'size' set but not
used [-Wunused-but-set-variable]
drivers/char/agp/frontend.c: In function 'agp_find_seg_in_client':
drivers/char/agp/frontend.c:105:6: warning: variable 'num_segments' set but not
used [-Wunused-but-set-variable]
It's never used since introduction.
Signed-off-by: YueHaibing
---
drivers/char/agp/frontend.c | 3 +--
drivers/char/agp/uninorth-agp.c | 4 +---
2 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/char/agp/frontend.c b/drivers/char/agp/frontend.c
index f695588..4709864 100644
--- a/drivers/char/agp/frontend.c
+++ b/drivers/char/agp/frontend.c
@@ -102,14 +102,13 @@ agp_segment_priv *agp_find_seg_in_client(const struct
agp_client *client,
int size, pgprot_t page_prot)
{
struct agp_segment_priv *seg;
- int num_segments, i;
+ int i;
off_t pg_start;
size_t pg_count;
pg_start = offset / 4096;
pg_count = size / 4096;
seg = *(client->segments);
- num_segments = client->num_segments;
for (i = 0; i < client->num_segments; i++) {
if ((seg[i].pg_start == pg_start) &&
diff --git a/drivers/char/agp/uninorth-agp.c b/drivers/char/agp/uninorth-agp.c
index 31fcd043..91ead0ea 100644
--- a/drivers/char/agp/uninorth-agp.c
+++ b/drivers/char/agp/uninorth-agp.c
@@ -368,7 +368,6 @@ static int uninorth_create_gatt_table(struct
agp_bridge_data *bridge)
{
char *table;
char *table_end;
- int size;
int page_order;
int num_entries;
int i;
@@ -382,10 +381,9 @@ static int uninorth_create_gatt_table(struct
agp_bridge_data *bridge)
table = NULL;
i = bridge->aperture_size_idx;
temp = bridge->current_size;
- size = page_order = num_entries = 0;
+ page_order = num_entries = 0;
do {
- size = A_SIZE_32(temp)->size;
page_order = A_SIZE_32(temp)->page_order;
num_entries = A_SIZE_32(temp)->num_entries;
--
2.7.0
Re: [PATCH 2/2] ARM: errata: add support for A12/A17 errata CR711784
Hi, On Tue, Apr 23, 2019 at 3:19 AM Robin Murphy wrote: > > Hi Doug, > > On 19/04/2019 23:18, Douglas Anderson wrote: > > This adds a code for turning on chicken bit 11, which appears to avoid > > a potential CPU deadlock that could occur. The exact set of > > instruction needed to trigger this errata is not totaly known but we > > have a high level of confidence that the problem is fixed by setting > > chicken bit 11. > > > > All details are in http://crbug.com/711784 > > > > This erratum has no known number and thus I have tagged it CR711784 > > (after the Chrome OS bug number). I have created separate A12 / A17 > > configs to match how the rest of the A12 / A17 errata is handled. > > The written-up workarounds for 85727[12] do actually say to set both > bits 10 and 11 of the diagnostic register, so you could probably just > fold this into the first patch and not have to worry about what to call it. > > Robin. Thanks! I was unable to find any official docs here and my past contacts with ARM about this matter have been silent. All I had was a preliminary errata description and it only included bit 10. I'll spin a v2 with them both together then. -Doug
Re: [PATCH 1/2] dt-bindings: mt8183: Add watchdog dt-binding
On 22/04/2019 08:08, Yong Liang wrote: > From: "yong.liang" > > This patch add watchdog binding documentation for > watchdog on MTK Socs. > > Signed-off-by: yong.liang Reviewed-by: Matthias Brugger > --- > .../devicetree/bindings/watchdog/mtk-wdt.txt |1 + > 1 file changed, 1 insertion(+) > > diff --git a/Documentation/devicetree/bindings/watchdog/mtk-wdt.txt > b/Documentation/devicetree/bindings/watchdog/mtk-wdt.txt > index 8682d6a..f0824aa 100644 > --- a/Documentation/devicetree/bindings/watchdog/mtk-wdt.txt > +++ b/Documentation/devicetree/bindings/watchdog/mtk-wdt.txt > @@ -9,6 +9,7 @@ Required properties: > "mediatek,mt7622-wdt", "mediatek,mt6589-wdt": for MT7622 > "mediatek,mt7623-wdt", "mediatek,mt6589-wdt": for MT7623 > "mediatek,mt7629-wdt", "mediatek,mt6589-wdt": for MT7629 > + "mediatek,mt8183-wdt", "mediatek,mt6589-wdt": for MT8183 > > - reg : Specifies base physical address and size of the registers. > >
Re: [PATCH 1/2] dt-bindings: adc: mt8183: add binding document
On 22/04/2019 13:54, Zhiyong Tao wrote: > The commit adds mt8183 compatible node in binding document. > > Signed-off-by: Zhiyong Tao > --- > Documentation/devicetree/bindings/iio/adc/mt6577_auxadc.txt | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/Documentation/devicetree/bindings/iio/adc/mt6577_auxadc.txt > b/Documentation/devicetree/bindings/iio/adc/mt6577_auxadc.txt > index 0df9befdaecc..05bc79d8483c 100644 > --- a/Documentation/devicetree/bindings/iio/adc/mt6577_auxadc.txt > +++ b/Documentation/devicetree/bindings/iio/adc/mt6577_auxadc.txt > @@ -15,6 +15,7 @@ Required properties: > - "mediatek,mt2712-auxadc": For MT2712 family of SoCs > - "mediatek,mt7622-auxadc": For MT7622 family of SoCs > - "mediatek,mt8173-auxadc": For MT8173 family of SoCs > +- "mediatek,mt8183-auxadc": For MT8183 family of SoCs >- reg: Address range of the AUXADC unit. >- clocks: Should contain a clock specifier for each entry in clock-names >- clock-names: Should contain "main". > You are missing the logic in the driver to bind against this compatible. If there is nothing different from other SoCs then you could add a compatible with a fallback, like: "mediatek,mt8183-auxadc", "mediatek,mt7622-auxadc": For MT8183 family of SoCs Regards, Matthias
Re: [PATCH 1/2] mm/page_alloc: avoid potential NULL pointer dereference
On Tue, Apr 23, 2019 at 03:08:05PM +0300, Andrey Ryabinin wrote:
> ac.preferred_zoneref->zone passed to alloc_flags_nofragment() can be NULL.
> 'zone' pointer unconditionally derefernced in alloc_flags_nofragment().
> Bail out on NULL zone to avoid potential crash.
> Currently we don't see any crashes only because alloc_flags_nofragment()
> has another bug which allows compiler to optimize away all accesses to
> 'zone'.
>
> Fixes: 6bb154504f8b ("mm, page_alloc: spread allocations across zones before
> introducing fragmentation")
> Signed-off-by: Andrey Ryabinin
Acked-by: Mel Gorman
--
Mel Gorman
SUSE Labs
Re: [PATCH 2/2] mm/page_alloc: fix never set ALLOC_NOFRAGMENT flag
On Tue, Apr 23, 2019 at 03:08:06PM +0300, Andrey Ryabinin wrote:
> Commit 0a79cdad5eb2 ("mm: use alloc_flags to record if kswapd can wake")
> removed setting of the ALLOC_NOFRAGMENT flag. Bring it back.
>
> Fixes: 0a79cdad5eb2 ("mm: use alloc_flags to record if kswapd can wake")
> Signed-off-by: Andrey Ryabinin
Acked-by: Mel Gorman
--
Mel Gorman
SUSE Labs
Re: [PATCH] PCI/LINK: Account for BW notification in vector calculation
On 4/22/19 7:33 PM, Alex Williamson wrote: On Mon, 22 Apr 2019 19:05:57 -0500 Alex G wrote: echo :07:00.0:pcie010 | sudo tee /sys/bus/pci_express/drivers/pcie_bw_notification/unbind That's a bad solution for users, this is meaningless tracking of a device whose driver is actively managing the link bandwidth for power purposes. 0.5W savings on a 100+W GPU? I agree it's meaningless. There is nothing wrong happening here that needs to fill logs. I thought maybe if I enabled notification of autonomous bandwidth changes that it might categorize these as something we could ignore, but it doesn't. How can we identify only cases where this is an erroneous/noteworthy situation? Thanks, You don't. Ethernet doesn't. USB doesn't. This logging behavior is consistent with every other subsystem that deals with multi-speed links. I realize some people are very resistant to change (and use very ancient kernels). I do not, however, agree that this is a sufficient argument to dis-unify behavior. Alex
[PATCH 3/4] EDAC, altera: Add Stratix10 SDMMC support
From: Thor Thayer
Addition of SDMMC EDAC for Stratix10 which has IRQ
differences from Arria10. Update comment accordingly.
Signed-off-by: Thor Thayer
---
drivers/edac/altera_edac.c | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/drivers/edac/altera_edac.c b/drivers/edac/altera_edac.c
index b7bc8f020df8..c2e693e34d43 100644
--- a/drivers/edac/altera_edac.c
+++ b/drivers/edac/altera_edac.c
@@ -1583,8 +1583,12 @@ static int altr_portb_setup(struct altr_edac_device_dev
*device)
dci->mod_name = ecc_name;
dci->dev_name = ecc_name;
- /* Update the IRQs for PortB */
+ /* Update the PortB IRQs - A10 has 4, S10 has 2, Index accordingly */
+#ifdef CONFIG_ARCH_STRATIX10
+ altdev->sb_irq = irq_of_parse_and_map(np, 1);
+#else
altdev->sb_irq = irq_of_parse_and_map(np, 2);
+#endif
if (!altdev->sb_irq) {
edac_printk(KERN_ERR, EDAC_DEVICE, "Error PortB SBIRQ alloc\n");
rc = -ENODEV;
@@ -1599,6 +1603,15 @@ static int altr_portb_setup(struct altr_edac_device_dev
*device)
goto err_release_group_1;
}
+#ifdef CONFIG_ARCH_STRATIX10
+ /* Use IRQ to determine SError origin instead of assigning IRQ */
+ rc = of_property_read_u32_index(np, "interrupts", 1, >db_irq);
+ if (rc) {
+ edac_printk(KERN_ERR, EDAC_DEVICE,
+ "Error PortB DBIRQ alloc\n");
+ goto err_release_group_1;
+ }
+#else
altdev->db_irq = irq_of_parse_and_map(np, 3);
if (!altdev->db_irq) {
edac_printk(KERN_ERR, EDAC_DEVICE, "Error PortB DBIRQ alloc\n");
@@ -1613,6 +1626,7 @@ static int altr_portb_setup(struct altr_edac_device_dev
*device)
edac_printk(KERN_ERR, EDAC_DEVICE, "PortB DBERR IRQ error\n");
goto err_release_group_1;
}
+#endif
rc = edac_device_add_device(dci);
if (rc) {
--
2.7.4
[PATCH 4/4] arm64: dts: stratix10: Add SDMMC EDAC node
From: Thor Thayer
Add the Stratix10 SDMMC EDAC node.
Signed-off-by: Thor Thayer
---
arch/arm64/boot/dts/altera/socfpga_stratix10_socdk.dts | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm64/boot/dts/altera/socfpga_stratix10_socdk.dts
b/arch/arm64/boot/dts/altera/socfpga_stratix10_socdk.dts
index 2e3863ee12b3..91fed85cf8e5 100644
--- a/arch/arm64/boot/dts/altera/socfpga_stratix10_socdk.dts
+++ b/arch/arm64/boot/dts/altera/socfpga_stratix10_socdk.dts
@@ -67,6 +67,17 @@
clock-frequency = <2500>;
};
};
+
+ eccmgr {
+ sdmmca-ecc@ff8c8c00 {
+ compatible = "altr,socfpga-s10-sdmmc-ecc",
+"altr,socfpga-sdmmc-ecc";
+ reg = <0xff8c8c00 0x100>;
+ altr,ecc-parent = <>;
+ interrupts = <14 4>,
+<15 4>;
+ };
+ };
};
};
--
2.7.4
[PATCH 0/4] Add Stratix10 OCRAM & SDMMC EDAC Support
From: Thor Thayer This patch series adds EDAC support for the Stratix10 OCRAM and SDMMC peripherals. Thor Thayer (4): EDAC, altera: Add Stratix10 OCRAM ECC support arm64: dts: stratix10: Add OCRAM EDAC node EDAC, altera: Add Stratix10 SDMMC support arm64: dts: stratix10: Add SDMMC EDAC node arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi | 8 .../boot/dts/altera/socfpga_stratix10_socdk.dts| 11 ++ drivers/edac/altera_edac.c | 43 -- 3 files changed, 59 insertions(+), 3 deletions(-) -- 2.7.4
[PATCH 2/4] arm64: dts: stratix10: Add OCRAM EDAC node
From: Thor Thayer
Add the OCRAM ECC node with Stratix10 compatible string.
Signed-off-by: Thor Thayer
---
arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi
b/arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi
index 41109995563c..c28310ff70a0 100644
--- a/arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi
+++ b/arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi
@@ -547,6 +547,14 @@
interrupts = <16 4>;
};
+ ocram-ecc@ff8cc000 {
+ compatible = "altr,socfpga-s10-ocram-ecc",
+"altr,socfpga-a10-ocram-ecc";
+ reg = <0xff8cc000 0x100>;
+ altr,ecc-parent = <>;
+ interrupts = <1 4>;
+ };
+
usb0-ecc@ff8c4000 {
compatible = "altr,socfpga-s10-usb-ecc",
"altr,socfpga-usb-ecc";
--
2.7.4
[PATCH 1/4] EDAC, altera: Add Stratix10 OCRAM ECC support
From: Thor Thayer
Use the newer ECC error injection method for Arria10 and
Stratix10 OCRAM.
If OCRAM has already been initialized during the boot and
OCRAM ECC is enabled, ensure the Single Bit Error IRQ is
enabled.
Signed-off-by: Thor Thayer
---
drivers/edac/altera_edac.c | 27 +--
1 file changed, 25 insertions(+), 2 deletions(-)
diff --git a/drivers/edac/altera_edac.c b/drivers/edac/altera_edac.c
index 8816f74a22b4..b7bc8f020df8 100644
--- a/drivers/edac/altera_edac.c
+++ b/drivers/edac/altera_edac.c
@@ -1223,8 +1223,31 @@ static const struct edac_device_prv_data ocramecc_data =
{
.inject_fops = _edac_device_inject_fops,
};
+static int __maybe_unused
+altr_check_ocram_deps_init(struct altr_edac_device_dev *device)
+{
+ void __iomem *base = device->base;
+ int ret;
+
+ ret = altr_check_ecc_deps(device);
+ if (ret)
+ return ret;
+
+ /* Verify OCRAM has been initialized */
+ if (!ecc_test_bits(ALTR_A10_ECC_INITCOMPLETEA,
+ (base + ALTR_A10_ECC_INITSTAT_OFST)))
+ return -ENODEV;
+
+ /* Enable IRQ on Single Bit Error */
+ writel(ALTR_A10_ECC_SERRINTEN, (base + ALTR_A10_ECC_ERRINTENS_OFST));
+ /* Ensure all writes complete */
+ wmb();
+
+ return 0;
+}
+
static const struct edac_device_prv_data a10_ocramecc_data = {
- .setup = altr_check_ecc_deps,
+ .setup = altr_check_ocram_deps_init,
.ce_clear_mask = ALTR_A10_ECC_SERRPENA,
.ue_clear_mask = ALTR_A10_ECC_DERRPENA,
.irq_status_mask = A10_SYSMGR_ECC_INTSTAT_OCRAM,
@@ -1234,7 +1257,7 @@ static const struct edac_device_prv_data
a10_ocramecc_data = {
.ue_set_mask = ALTR_A10_ECC_TDERRA,
.set_err_ofst = ALTR_A10_ECC_INTTEST_OFST,
.ecc_irq_handler = altr_edac_a10_ecc_irq,
- .inject_fops = _edac_a10_device_inject_fops,
+ .inject_fops = _edac_a10_device_inject2_fops,
/*
* OCRAM panic on uncorrectable error because sleep/resume
* functions and FPGA contents are stored in OCRAM. Prefer
--
2.7.4
Re: [PATCH v20 16/28] x86/sgx: Add provisioning
On Fri, Apr 19, 2019 at 03:06:48AM +, Huang, Kai wrote:
> On Wed, 2019-04-17 at 13:39 +0300, Jarkko Sakkinen wrote:
> > In order to provide a mechanism for devilering provisoning rights:
> >
> > 1. Add a new device file /dev/sgx/provision that works as a token for
> >allowing an enclave to have the provisioning privileges.
> > 2. Add a new ioctl called SGX_IOC_ENCLAVE_SET_ATTRIBUTE that accepts the
> >following data structure:
> >
> >struct sgx_enclave_set_attribute {
> >__u64 addr;
> >__u64 attribute_fd;
> >};
> >
> > A daemon could sit on top of /dev/sgx/provision and send a file
> > descriptor of this file to a process that needs to be able to provision
> > enclaves.
> >
> > The way this API is used is straight-forward. Lets assume that dev_fd is
> > a handle to /dev/sgx/enclave and prov_fd is a handle to
> > /dev/sgx/provision. You would allow SGX_IOC_ENCLAVE_CREATE to
> > initialize an enclave with the PROVISIONKEY attribute by
> >
> > params.addr = ;
> > params.token_fd = prov_fd;
> >
> Should be params.attribute_fd = prov_fd;
>
> Thanks,
> -Kai
Thanks.
/Jarkko
[PATCH] driver core: Fix use-after-free and double free on glue directory
There is a race condition between removing glue directory and adding a new
device under the glue directory. It can be reproduced in following test:
path 1: Add the child device under glue dir
device_add()
get_device_parent()
mutex_lock(_mutex);
/*find parent from glue_dirs.list*/
list_for_each_entry(k, >class->p->glue_dirs.list, entry)
if (k->parent == parent_kobj) {
kobj = kobject_get(k);
break;
}
mutex_unlock(_mutex);
kobject_add()
kobject_add_internal()
create_dir()
sysfs_create_dir_ns()
if (kobj->parent)
parent = kobj->parent->sd;
kernfs_create_dir_ns(parent)
kernfs_new_node()
kernfs_get(parent)
/* link in */
rc = kernfs_add_one(kn);
if (!rc)
return kn;
kernfs_put(kn)
repeat:
kmem_cache_free(kn)
kn = parent;
if (kn) {
if (atomic_dec_and_test(>count))
goto repeat;
}
path2: Remove last child device under glue dir
device_del()
cleanup_device_parent()
cleanup_glue_dir()
mutex_lock(_mutex);
if (!kobject_has_children(glue_dir))
kobject_del(glue_dir);
kobject_put(glue_dir);
mutex_unlock(_mutex);
Before path2 remove last child device under glue dir, If path1 add a new
device under glue dir, the glue_dir kobject reference count will be
increase to 2 via kobject_get(k) in get_device_parent(). And path1 has
been called kernfs_new_node(), but not call kernfs_get(parent).
Meanwhile, path2 call kobject_del(glue_dir) beacause 0 is returned by
kobject_has_children(). This result in glue_dir->sd is freed and it's
reference count will be 0. Then path1 call kernfs_get(parent) will trigger
a warning in kernfs_get()(WARN_ON(!atomic_read(>count))) and increase
it's reference count to 1. Because glue_dir->sd is freed by path2, the next
call kernfs_add_one() by path1 will fail(This is also use-after-free)
and call atomic_dec_and_test() to decrease reference count. Because the
reference count is decremented to 0, it will also call kmem_cache_free()
to free glue_dir->sd again. This will result in double free.
In order to avoid this happening, we we should not call kobject_del() on
path2 when the reference count of glue_dir is greater than 1. So we add a
conditional statement to fix it.
The following calltrace is captured in kernel 4.14 with the following patch
applied:
commit 726e41097920 ("drivers: core: Remove glue dirs from sysfs earlier")
--
[3.633703] WARNING: CPU: 4 PID: 513 at .../fs/kernfs/dir.c:494
Here is WARN_ON(!atomic_read(>count) in kernfs_get().
[3.633986] Call trace:
[3.633991] kernfs_create_dir_ns+0xa8/0xb0
[3.633994] sysfs_create_dir_ns+0x54/0xe8
[3.634001] kobject_add_internal+0x22c/0x3f0
[3.634005] kobject_add+0xe4/0x118
[3.634011] device_add+0x200/0x870
[3.634017] _request_firmware+0x958/0xc38
[3.634020] request_firmware_into_buf+0x4c/0x70
[3.634064] kernel BUG at .../mm/slub.c:294!
Hrer is BUG_ON(object == fp) in set_freepointer().
[3.634346] Call trace:
[3.634351] kmem_cache_free+0x504/0x6b8
[3.634355] kernfs_put+0x14c/0x1d8
[3.634359] kernfs_create_dir_ns+0x88/0xb0
[3.634362] sysfs_create_dir_ns+0x54/0xe8
[3.634366] kobject_add_internal+0x22c/0x3f0
[3.634370] kobject_add+0xe4/0x118
[3.634374] device_add+0x200/0x870
[3.634378] _request_firmware+0x958/0xc38
[3.634381] request_firmware_into_buf+0x4c/0x70
--
Fixes: 726e41097920 ("drivers: core: Remove glue dirs from sysfs earlier")
Signed-off-by: Muchun Song
---
drivers/base/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/base/core.c b/drivers/base/core.c
index 4aeaa0c92bda..5ac5376ae9af 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -1825,7 +1825,7 @@ static void cleanup_glue_dir(struct device *dev, struct
kobject *glue_dir)
return;
mutex_lock(_mutex);
- if (!kobject_has_children(glue_dir))
+ if (!kobject_has_children(glue_dir) && kref_read(_dir->kref) == 1)
kobject_del(glue_dir);
kobject_put(glue_dir);
mutex_unlock(_mutex);
--
2.17.1
Re: [PATCH v4 14/16] locking/rwsem: Guard against making count negative
On 4/23/19 10:17 AM, Peter Zijlstra wrote:
> On Sun, Apr 21, 2019 at 05:07:56PM -0400, Waiman Long wrote:
>
>> How about the following chunks to disable preemption temporarily for the
>> increment-check-decrement sequence?
>>
>> diff --git a/include/linux/preempt.h b/include/linux/preempt.h
>> index dd92b1a93919..4cc03ac66e13 100644
>> --- a/include/linux/preempt.h
>> +++ b/include/linux/preempt.h
>> @@ -250,6 +250,8 @@ do { \
>> #define preempt_enable_notrace() barrier()
>> #define preemptible() 0
>>
>> +#define __preempt_disable_nop /* preempt_disable() is nop */
>> +
>> #endif /* CONFIG_PREEMPT_COUNT */
>>
>> #ifdef MODULE
>> diff --git a/kernel/locking/rwsem.c b/kernel/locking/rwsem.c
>> index 043fd29b7534..54029e6af17b 100644
>> --- a/kernel/locking/rwsem.c
>> +++ b/kernel/locking/rwsem.c
>> @@ -256,11 +256,64 @@ static inline struct task_struct
>> *rwsem_get_owner(struct r
>> return (struct task_struct *) (cowner
>> ? cowner | (sowner & RWSEM_NONSPINNABLE) : sowner);
>> }
>> +
>> +/*
>> + * If __preempt_disable_nop is defined, calling preempt_disable() and
>> + * preempt_enable() directly is the most efficient way. Otherwise, it may
>> + * be more efficient to disable and enable interrupt instead for disabling
>> + * preemption tempoarily.
>> + */
>> +#ifdef __preempt_disable_nop
>> +#define disable_preemption() preempt_disable()
>> +#define enable_preemption() preempt_enable()
>> +#else
>> +#define disable_preemption() local_irq_disable()
>> +#define enable_preemption() local_irq_enable()
>> +#endif
> I'm not aware of an architecture where disabling interrupts is faster
> than disabling preemption.
I have actually done some performance test measuring the effects of
disabling interrupt and preemption on readers (on x86-64 system).
Threads Before patch Disable irq Disable preemption
--- --- --
1 9,088 8,766 9,172
2 9,296 9,169 8,707
4 11,192 11,205 10,712
8 11,329 11,332 11,213
For uncontended case, disable interrupt is slower. The slowdown is gone
once the rwsem becomes contended. So it may not be a good idea to
disable interrupt as a proxy of disabling preemption.
BTW, preemption count is not enabled in typical distro production
kernels like RHEL. So preempt_disable() is just a barrier. It is turned
on in the debug kernel, though.
>> +/*
>> + * When the owner task structure pointer is merged into couunt, less bits
>> + * will be available for readers. Therefore, there is a very slight chance
>> + * that the reader count may overflow. We try to prevent that from
>> happening
>> + * by checking for the MS bit of the count and failing the trylock attempt
>> + * if this bit is set.
>> + *
>> + * With preemption enabled, there is a remote possibility that preemption
>> + * can happen in the narrow timing window between incrementing and
>> + * decrementing the reader count and the task is put to sleep for a
>> + * considerable amount of time. If sufficient number of such unfortunate
>> + * sequence of events happen, we may still overflow the reader count.
>> + * To avoid such possibility, we have to disable preemption for the
>> + * whole increment-check-decrement sequence.
>> + *
>> + * The function returns true if there are too many readers and the count
>> + * has already been properly decremented so the reader must go directly
>> + * into the wait list.
>> + */
>> +static inline bool rwsem_read_trylock(struct rw_semaphore *sem, long *cnt)
>> +{
>> + bool wait = false; /* Wait now flag */
>> +
>> + disable_preemption();
>> + *cnt = atomic_long_fetch_add_acquire(RWSEM_READER_BIAS,
>> >count);
>> + if (unlikely(*cnt < 0)) {
>> + atomic_long_add(-RWSEM_READER_BIAS, >count);
>> + wait = true;
>> + }
>> + enable_preemption();
>> + return wait;
>> +}
>> #else /* !CONFIG_RWSEM_OWNER_COUNT */
> This also means you have to ensure CONFIG_NR_CPUS < 32K for
> RWSEM_OWNER_COUNT.
Yes, that can be done.
>
>> static inline struct task_struct *rwsem_get_owner(struct rw_semaphore *sem)
>> {
>> return READ_ONCE(sem->owner);
>> }
>> +
>> +static inline bool rwsem_read_trylock(struct rw_semaphore *sem, long *cnt)
>> +{
>> + *cnt = atomic_long_fetch_add_acquire(RWSEM_READER_BIAS,
>> >count);
>> + return false;
>> +}
>> #endif /* CONFIG_RWSEM_OWNER_COUNT */
>>
>> /*
>> @@ -981,32 +1034,18 @@ static inline void clear_wr_nonspinnable(struct
>> rw_semaph
>> * Wait for the read lock to be granted
>> */
>> static struct rw_semaphore __sched *
>> -rwsem_down_read_slowpath(struct rw_semaphore *sem, int state, long count)
>> +rwsem_down_read_slowpath(struct rw_semaphore *sem, int state, const
>> bool wait)
>> {
>> - long adjustment =
Re: [PATCH v2] ARM: dts: aspeed: Adding Lenovo Hr630 BMC
On Tue, Apr 23, 2019 at 4:55 AM Andrew Peng wrote:
>
> Initial introduction of Lenovo Hr630 family equipped with
> Aspeed 2500 BMC SoC. Hr630 is a x86 server development kit
> with a ASPEED ast2500 BMC manufactured by Lenovo.
> Specifically, This adds the Hr630 platform device tree file
> used by the Hr630 BMC machines.
>
> This also adds an entry of Hr630 device tree file in Makefile
>
> Signed-off-by: Andrew Peng
> Signed-off-by: Yonghui Liu
> Signed-off-by: Lisa Liu
In the future, or in the next version, please add a section here
explaining what changed. You can look at other v2 or v3, etc, to see
how it should appear.
> ---
> arch/arm/boot/dts/Makefile| 3 +-
> arch/arm/boot/dts/aspeed-bmc-lenovo-hr630.dts | 886
> ++
> 2 files changed, 888 insertions(+), 1 deletion(-)
> create mode 100644 arch/arm/boot/dts/aspeed-bmc-lenovo-hr630.dts
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index f4f5aea..375e53b 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -1261,4 +1261,5 @@ dtb-$(CONFIG_ARCH_ASPEED) += \
> aspeed-bmc-opp-witherspoon.dtb \
> aspeed-bmc-opp-zaius.dtb \
> aspeed-bmc-portwell-neptune.dtb \
> - aspeed-bmc-quanta-q71l.dtb
> + aspeed-bmc-quanta-q71l.dtb \
> + aspeed-bmc-lenovo-hr630.dtb
> diff --git a/arch/arm/boot/dts/aspeed-bmc-lenovo-hr630.dts
> b/arch/arm/boot/dts/aspeed-bmc-lenovo-hr630.dts
> new file mode 100644
> index 000..3322f83
> --- /dev/null
> +++ b/arch/arm/boot/dts/aspeed-bmc-lenovo-hr630.dts
> @@ -0,0 +1,886 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Device Tree file for Lenovo Hr630 platform
> + *
> + * Copyright (C) 2019-present Lenovo
> + */
> +
> +/dts-v1/;
> +
> +#include "aspeed-g5.dtsi"
> +#include
> +
> +/ {
> + model = "HR630 BMC";
> + compatible = "lenovo,hr630-bmc", "aspeed,ast2500";
> +
> + aliases {
> + i2c_rbp = _rbp;
> + i2c_fbp1 = _fbp1;
> + i2c_fbp2 = _fbp2;
> + i2c_fbp3 = _fbp3;
> + };
These aliases don't do anything that I can see - they are assigning
themselves to themselves. I was referring to the i2c bus numbers.
For instance:
i2c14 = _rbp;
That will insure that i2c_rbp will be slotted as i2c14.
> +
> + chosen {
> + stdout-path =
> + bootargs = "console=tty0 console=ttyS4,115200 earlyprintk";
> + };
> +
> + memory@8000 {
> + device_type = "memory";
> + reg = <0x8000 0x2000>;
> + };
> +
> + reserved-memory {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + flash_memory: region@9800 {
> + no-map;
> + reg = <0x9800 0x0010>; /* 1M */
> + };
> +
> + gfx_memory: framebuffer {
> + size = <0x0100>;
> + alignment = <0x0100>;
> + compatible = "shared-dma-pool";
> + reusable;
> + };
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> +
> + heartbeat {
> + gpios = < ASPEED_GPIO(J, 1) GPIO_ACTIVE_LOW>;
> + };
> +
> + fault {
> + gpios = < ASPEED_GPIO(J, 0) GPIO_ACTIVE_LOW>;
> + };
> + };
> +
> + iio-hwmon {
> + compatible = "iio-hwmon";
> + io-channels = < 0>, < 1>, < 2>, < 3>,
> + < 4>, < 5>, < 6>, < 7>,
> + < 8>, < 9>, < 10>,
> + < 12>, < 13>, < 14>;
> + };
> +
> +};
> +
> + {
> + status = "okay";
> + flash@0 {
> + status = "okay";
> + m25p,fast-read;
> + label = "bmc";
> + spi-max-frequency = <5000>;
> +#include "openbmc-flash-layout.dtsi"
> + };
> +};
> +
> +_ctrl {
> + status = "okay";
> + memory-region = <_memory>;
> + flash = <>;
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +
> + pinctrl-names = "default";
> + pinctrl-0 = <_rmii1_default>;
> + use-ncsi;
> +};
> +
> + {
> + status = "okay";
> +
> + pinctrl-names = "default";
> + pinctrl-0 = <_rgmii2_default _mdio2_default>;
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> + /* temp1 inlet */
> + tmp75@4e {
> + compatible = "national,lm75";
> + reg = <0x4e>;
> + };
> +};
> +
> + {
> + status = "okay";
> + /*
Re: [PATCH] fs: Fix ovl_i_mutex_dir_key/p->lock/cred cred_guard_mutex deadlock
Cc: linux-unionfs
On Thu, Apr 11, 2019 at 6:48 PM Mina Almasry wrote:
>
> These 3 locks are acquired simultaneously in different order causing
> deadlock:
>
> https://syzkaller.appspot.com/bug?id=00f119b8bb35a3acbcfafb9d36a2752b364e8d66
>
> ==
> WARNING: possible circular locking dependency detected
> 4.19.0-rc5+ #253 Not tainted
> --
> syz-executor1/545 is trying to acquire lock:
> b04209e4 (_i_mutex_dir_key[depth]){}, at: inode_lock_shared
> include/linux/fs.h:748 [inline]
> b04209e4 (_i_mutex_dir_key[depth]){}, at: do_last
> fs/namei.c:3323 [inline]
> b04209e4 (_i_mutex_dir_key[depth]){}, at:
> path_openat+0x250d/0x5160 fs/namei.c:3534
>
> but task is already holding lock:
> 44500cca (>cred_guard_mutex){+.+.}, at:
> prepare_bprm_creds+0x53/0x120 fs/exec.c:1404
>
> which lock already depends on the new lock.
>
> the existing dependency chain (in reverse order) is:
>
> -> #3 (>cred_guard_mutex){+.+.}:
>__mutex_lock_common kernel/locking/mutex.c:925 [inline]
>__mutex_lock+0x166/0x1700 kernel/locking/mutex.c:1072
>mutex_lock_killable_nested+0x16/0x20 kernel/locking/mutex.c:1102
>lock_trace+0x4c/0xe0 fs/proc/base.c:384
>proc_pid_stack+0x196/0x3b0 fs/proc/base.c:420
>proc_single_show+0x101/0x190 fs/proc/base.c:723
>seq_read+0x4af/0x1150 fs/seq_file.c:229
>do_loop_readv_writev fs/read_write.c:700 [inline]
>do_iter_read+0x4a3/0x650 fs/read_write.c:924
>vfs_readv+0x175/0x1c0 fs/read_write.c:986
>do_preadv+0x1cc/0x280 fs/read_write.c:1070
>__do_sys_preadv fs/read_write.c:1120 [inline]
>__se_sys_preadv fs/read_write.c:1115 [inline]
>__x64_sys_preadv+0x9a/0xf0 fs/read_write.c:1115
>do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
>entry_SYSCALL_64_after_hwframe+0x49/0xbe
>
> -> #2 (>lock){+.+.}:
>__mutex_lock_common kernel/locking/mutex.c:925 [inline]
>__mutex_lock+0x166/0x1700 kernel/locking/mutex.c:1072
>mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:1087
>seq_read+0x71/0x1150 fs/seq_file.c:161
>do_loop_readv_writev fs/read_write.c:700 [inline]
>do_iter_read+0x4a3/0x650 fs/read_write.c:924
>vfs_readv+0x175/0x1c0 fs/read_write.c:986
>kernel_readv fs/splice.c:362 [inline]
>default_file_splice_read+0x53c/0xb20 fs/splice.c:417
>do_splice_to+0x12e/0x190 fs/splice.c:881
>splice_direct_to_actor+0x270/0x8f0 fs/splice.c:953
>do_splice_direct+0x2d4/0x420 fs/splice.c:1062
>do_sendfile+0x62a/0xe20 fs/read_write.c:1440
>__do_sys_sendfile64 fs/read_write.c:1495 [inline]
>__se_sys_sendfile64 fs/read_write.c:1487 [inline]
>__x64_sys_sendfile64+0x15d/0x250 fs/read_write.c:1487
>do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
>entry_SYSCALL_64_after_hwframe+0x49/0xbe
>
> -> #1 (sb_writers#5){.+.+}:
>percpu_down_read_preempt_disable include/linux/percpu-rwsem.h:36
> [inline]
>percpu_down_read include/linux/percpu-rwsem.h:59 [inline]
>__sb_start_write+0x214/0x370 fs/super.c:1387
>sb_start_write include/linux/fs.h:1566 [inline]
>mnt_want_write+0x3f/0xc0 fs/namespace.c:360
>ovl_want_write+0x76/0xa0 fs/overlayfs/util.c:24
>ovl_create_object+0x142/0x3a0 fs/overlayfs/dir.c:596
>ovl_create+0x2b/0x30 fs/overlayfs/dir.c:627
>lookup_open+0x1319/0x1b90 fs/namei.c:3234
>do_last fs/namei.c:3324 [inline]
>path_openat+0x15e7/0x5160 fs/namei.c:3534
>do_filp_open+0x255/0x380 fs/namei.c:3564
>do_sys_open+0x568/0x700 fs/open.c:1063
>ksys_open include/linux/syscalls.h:1276 [inline]
>__do_sys_creat fs/open.c:1121 [inline]
>__se_sys_creat fs/open.c:1119 [inline]
>__x64_sys_creat+0x61/0x80 fs/open.c:1119
>do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
>entry_SYSCALL_64_after_hwframe+0x49/0xbe
>
> -> #0 (_i_mutex_dir_key[depth]){}:
>lock_acquire+0x1ed/0x520 kernel/locking/lockdep.c:3900
>down_read+0xb0/0x1d0 kernel/locking/rwsem.c:24
>inode_lock_shared include/linux/fs.h:748 [inline]
>do_last fs/namei.c:3323 [inline]
>path_openat+0x250d/0x5160 fs/namei.c:3534
>do_filp_open+0x255/0x380 fs/namei.c:3564
>do_open_execat+0x221/0x8e0 fs/exec.c:853
>__do_execve_file.isra.33+0x173f/0x2540 fs/exec.c:1755
>do_execveat_common fs/exec.c:1866 [inline]
>do_execve fs/exec.c:1883 [inline]
>__do_sys_execve fs/exec.c:1964 [inline]
>__se_sys_execve fs/exec.c:1959 [inline]
>__x64_sys_execve+0x8f/0xc0 fs/exec.c:1959
>do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
>entry_SYSCALL_64_after_hwframe+0x49/0xbe
>
> other info that might help us debug this:
>
>
Re: [PATCH 00/20] drm: Split out the formats API and move it to a common place
Le mardi 23 avril 2019 à 14:33 +0200, Paul Kocialkowski a écrit : > Hi, > > On Tue, 2019-04-23 at 09:30 +0200, Daniel Vetter wrote: > > On Sun, Apr 21, 2019 at 01:40:45AM +0300, Laurent Pinchart wrote: > > > Hi Paul, > > > > > > On Thu, Apr 18, 2019 at 01:49:54PM +0200, Paul Kocialkowski wrote: > > > > On Thu, 2019-04-18 at 11:02 +0200, Maxime Ripard wrote: > > > > > On Thu, Apr 18, 2019 at 09:52:10AM +0200, Daniel Vetter wrote: > > > > > > And a lot of people pushed for the "fourcc is a standard", when > > > > > > really it's totally not. > > > > > > > > > > Even if it's not a standard, having consistency would be a good thing. > > > > > > > > > > And you said yourself that DRM fourcc is now pretty much an authority > > > > > for the fourcc, so it definitely looks like a standard to me. > > > > > > > > I think trying to make the V4L2 and DRM fourccs converge is a lost > > > > cause, as it has already significantly diverged. Even if we coordinate > > > > an effort to introduce new formats with the same fourcc on both sides, > > > > I don't see what good that would be since the formats we have now are > > > > still plagued by the inconsistency. > > > > > > > > I think we always need an explicit translation step from either v4l2 or > > > > drm to the internal representation and back, without ever assuming that > > > > formats might be compatible because they share the same fourcc. > > > > > > I don't agree. APIs evolve, and while we can't switch from one set of > > > 4CCs to another in existing APIs, we could in new APIs. Boris is working > > > on new ioctls to handle formats in V4L2, and while 4CC unification could > > > be impopular from a userspace developers point of view there, I don't > > > think we have ruled it out completely. The move to the request API is > > > also an area where a common set of 4CCs could be used, as it will depart > > > from the existing V4L2 ioctls. To summarize my opinion, we're not there > > > yet, but I wouldn't rule it out completely for the future. > > > > > > > It looks like so far, V4L2 pixel formats describe a DRM pixel format + > > > > modifier. > > > > > > DRM modifiers are mostly about tiling and compression, and we hardly > > > support these in V4L2. What are the modifiers you think are hardcoded in > > > 4CCs in V4L2 ? > > > > Hm maybe it was a drm one that didn't come from v4l or anywhere else > > really, but the NV12MT one is nv12 + some tiling. I think we managed to > > uapi-bend that one into shape in at least drm. > > The one I had in mind is V4L2_PIX_FMT_SUNXI_TILED_NV12 which translates > to DRM_FORMAT_NV12 + DRM_FORMAT_MOD_ALLWINNER_TILED. Seems to be a > pretty similar case to the Mediatek one indeed. > > In our cause, that's because the video decoding engine produces its > destination buffers in a specific tiled format, that the display engine > can take in directly. We also have the Samsung tiling (Z pattern) as mentioned here, but also linear 16x16 tile placement (also from Samsung ?) and I believe Amlogic CODEC patches is bringing another tiling (unavoidable on older Meson8, with 64bytes swaps). All these should be expressed as NV12 + mod in DRM space. What is very often not enabled, but affect the performance on mainline media drivers is the ARM frame buffer compression. I know that RK chips have support for this, and that you can't achieve the maximum throughput without that. This one is not documented anywhere, but I understand that there is multiple variants that HW vendor licence. Though, in general, each SoC are likely running a single variant, so a single mod would make sense. So all this to say that V4L2 equally needs supports for these. What I understood through DRM API is that a buffer allocated for let's say NV12 + mod, is compatible with linear NV12. That could be used to simplify some code, but at the same time, a common API that deals with the padding and alignment of each format + mod independently would do that same as long as this is not variable depending on which target HW uses that same format. I think DRM + mod reduce the amount of dedicated formats that needs to be added, and simplify the documentation of each formats. I was looking at the Amlogic Axi configurations on Amlogic S905x recently, and for each well known format, there is a bitmask that let you do arbitrary swapping of bits, so effectively if we start exposing all these with V4L2 style, the list would become very long and hard to maintained. > > Cheers, > > Paul > > > -Daniel > > > > > > I think Boris (CCed) is working to change that by allowing to > > > > pass a DRM modifier through V4L2. With that, we'd be in a situation > > > > where some formats are described by the v4l2 pixfmt alone and some > > > > formats are also described a modifier (but I looked at it from a > > > > distance so might have misunderstod). That feels better since it avoids > > > > the combinatory explosion from describing each format + modifier > > > > individually. > > > >
[PATCH] sched: Provide a pointer to the valid CPU mask
In commit 4b53a3412d66 ("sched/core: Remove the tsk_nr_cpus_allowed()
wrapper") the tsk_nr_cpus_allowed() wrapper was removed. There was not
much difference in !RT but in RT we used this to implement
migrate_disable(). Within a migrate_disable() section the CPU mask is
restricted to single CPU while the "normal" CPU mask remains untouched.
As an alternative implementation Ingo suggested to use
struct task_struct {
const cpumask_t *cpus_ptr;
cpumask_t cpus_mask;
};
with
t->cpus_allowed_ptr = >cpus_allowed;
In -RT we then can switch the cpus_ptr to
t->cpus_allowed_ptr = _of(task_cpu(p));
in a migration disabled region. The rules are simple:
- Code that 'uses' ->cpus_allowed would use the pointer.
- Code that 'modifies' ->cpus_allowed would use the direct mask.
I proposed this patch as a series earlier and it was shutdown due to the
migrate_disable() bits. It has been said that migrate_disable() should
only be used with RT and thus not introduced without it.
I hereby propose only the mask CPU-bits.
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: Ingo Molnar
Signed-off-by: Sebastian Andrzej Siewior
---
arch/ia64/kernel/mca.c | 2 +-
arch/mips/include/asm/switch_to.h | 4 +--
arch/mips/kernel/mips-mt-fpaff.c | 2 +-
arch/mips/kernel/traps.c | 6 ++--
arch/powerpc/platforms/cell/spufs/sched.c | 2 +-
arch/x86/kernel/cpu/resctrl/pseudo_lock.c | 2 +-
drivers/infiniband/hw/hfi1/affinity.c | 6 ++--
drivers/infiniband/hw/hfi1/sdma.c | 3 +-
drivers/infiniband/hw/qib/qib_file_ops.c | 7 ++--
fs/proc/array.c| 4 +--
include/linux/sched.h | 5 +--
init/init_task.c | 3 +-
kernel/cgroup/cpuset.c | 2 +-
kernel/fork.c | 2 ++
kernel/sched/core.c| 40 +++---
kernel/sched/cpudeadline.c | 4 +--
kernel/sched/cpupri.c | 4 +--
kernel/sched/deadline.c| 6 ++--
kernel/sched/fair.c| 34 +-
kernel/sched/rt.c | 4 +--
kernel/trace/trace_hwlat.c | 2 +-
lib/smp_processor_id.c | 2 +-
samples/trace_events/trace-events-sample.c | 2 +-
23 files changed, 75 insertions(+), 73 deletions(-)
diff --git a/arch/ia64/kernel/mca.c b/arch/ia64/kernel/mca.c
index 5cabb3fd159ff..7b4b58c168d59 100644
--- a/arch/ia64/kernel/mca.c
+++ b/arch/ia64/kernel/mca.c
@@ -1830,7 +1830,7 @@ format_mca_init_stack(void *mca_data, unsigned long
offset,
ti->cpu = cpu;
p->stack = ti;
p->state = TASK_UNINTERRUPTIBLE;
- cpumask_set_cpu(cpu, >cpus_allowed);
+ cpumask_set_cpu(cpu, >cpus_mask);
INIT_LIST_HEAD(>tasks);
p->parent = p->real_parent = p->group_leader = p;
INIT_LIST_HEAD(>children);
diff --git a/arch/mips/include/asm/switch_to.h
b/arch/mips/include/asm/switch_to.h
index 0f813bb753c63..09cbe9042828f 100644
--- a/arch/mips/include/asm/switch_to.h
+++ b/arch/mips/include/asm/switch_to.h
@@ -42,7 +42,7 @@ extern struct task_struct *ll_task;
* inline to try to keep the overhead down. If we have been forced to run on
* a "CPU" with an FPU because of a previous high level of FP computation,
* but did not actually use the FPU during the most recent time-slice (CU1
- * isn't set), we undo the restriction on cpus_allowed.
+ * isn't set), we undo the restriction on cpus_mask.
*
* We're not calling set_cpus_allowed() here, because we have no need to
* force prompt migration - we're already switching the current CPU to a
@@ -57,7 +57,7 @@ do {
\
test_ti_thread_flag(__prev_ti, TIF_FPUBOUND) && \
(!(KSTK_STATUS(prev) & ST0_CU1))) { \
clear_ti_thread_flag(__prev_ti, TIF_FPUBOUND); \
- prev->cpus_allowed = prev->thread.user_cpus_allowed;\
+ prev->cpus_mask = prev->thread.user_cpus_allowed; \
} \
next->thread.emulated_fp = 0; \
} while(0)
diff --git a/arch/mips/kernel/mips-mt-fpaff.c b/arch/mips/kernel/mips-mt-fpaff.c
index a7c0f97e4b0d6..1a08428eedcf1 100644
--- a/arch/mips/kernel/mips-mt-fpaff.c
+++ b/arch/mips/kernel/mips-mt-fpaff.c
@@ -177,7 +177,7 @@ asmlinkage long mipsmt_sys_sched_getaffinity(pid_t pid,
unsigned int len,
if (retval)
goto out_unlock;
- cpumask_or(, >thread.user_cpus_allowed, >cpus_allowed);
+ cpumask_or(, >thread.user_cpus_allowed, p->cpus_ptr);
cpumask_and(, , cpu_active_mask);
out_unlock:
diff --git a/arch/mips/kernel/traps.c
[PATCH v2] soc: add aspeed folder and misc drivers
Create a SoC folder for the ASPEED parts and place the misc drivers
currently present into this folder. These drivers are not generic part
drivers, but rather only apply to the ASPEED SoCs.
Signed-off-by: Patrick Venture
---
v2:
Added configuration option for ASPEED to soc/Makefile
---
drivers/misc/Kconfig | 16
drivers/misc/Makefile | 2 --
drivers/soc/Kconfig | 1 +
drivers/soc/Makefile | 1 +
drivers/soc/aspeed/Kconfig| 19 +++
drivers/soc/aspeed/Makefile | 2 ++
.../{misc => soc/aspeed}/aspeed-lpc-ctrl.c| 0
.../{misc => soc/aspeed}/aspeed-lpc-snoop.c | 0
8 files changed, 23 insertions(+), 18 deletions(-)
create mode 100644 drivers/soc/aspeed/Kconfig
create mode 100644 drivers/soc/aspeed/Makefile
rename drivers/{misc => soc/aspeed}/aspeed-lpc-ctrl.c (100%)
rename drivers/{misc => soc/aspeed}/aspeed-lpc-snoop.c (100%)
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index 42ab8ec92a04..b80cb6af0cb4 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -496,22 +496,6 @@ config VEXPRESS_SYSCFG
bus. System Configuration interface is one of the possible means
of generating transactions on this bus.
-config ASPEED_LPC_CTRL
- depends on (ARCH_ASPEED || COMPILE_TEST) && REGMAP && MFD_SYSCON
- tristate "Aspeed ast2400/2500 HOST LPC to BMC bridge control"
- ---help---
- Control Aspeed ast2400/2500 HOST LPC to BMC mappings through
- ioctl()s, the driver also provides a read/write interface to a BMC ram
- region where the host LPC read/write region can be buffered.
-
-config ASPEED_LPC_SNOOP
- tristate "Aspeed ast2500 HOST LPC snoop support"
- depends on (ARCH_ASPEED || COMPILE_TEST) && REGMAP && MFD_SYSCON
- help
- Provides a driver to control the LPC snoop interface which
- allows the BMC to listen on and save the data written by
- the host to an arbitrary LPC I/O port.
-
config PCI_ENDPOINT_TEST
depends on PCI
select CRC32
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index d5b7d3404dc7..b9affcdaa3d6 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -54,8 +54,6 @@ obj-$(CONFIG_GENWQE) += genwqe/
obj-$(CONFIG_ECHO) += echo/
obj-$(CONFIG_VEXPRESS_SYSCFG) += vexpress-syscfg.o
obj-$(CONFIG_CXL_BASE) += cxl/
-obj-$(CONFIG_ASPEED_LPC_CTRL) += aspeed-lpc-ctrl.o
-obj-$(CONFIG_ASPEED_LPC_SNOOP) += aspeed-lpc-snoop.o
obj-$(CONFIG_PCI_ENDPOINT_TEST)+= pci_endpoint_test.o
obj-$(CONFIG_OCXL) += ocxl/
obj-y += cardreader/
diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
index c07b4a85253f..b750a88547c7 100644
--- a/drivers/soc/Kconfig
+++ b/drivers/soc/Kconfig
@@ -2,6 +2,7 @@ menu "SOC (System On Chip) specific Drivers"
source "drivers/soc/actions/Kconfig"
source "drivers/soc/amlogic/Kconfig"
+source "drivers/soc/aspeed/Kconfig"
source "drivers/soc/atmel/Kconfig"
source "drivers/soc/bcm/Kconfig"
source "drivers/soc/fsl/Kconfig"
diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile
index 90b686e586c6..814128fe479f 100644
--- a/drivers/soc/Makefile
+++ b/drivers/soc/Makefile
@@ -4,6 +4,7 @@
#
obj-$(CONFIG_ARCH_ACTIONS) += actions/
+obj-$(CONFIG_ARCH_ASPEED) += aspeed/
obj-$(CONFIG_ARCH_AT91)+= atmel/
obj-y += bcm/
obj-$(CONFIG_ARCH_DOVE)+= dove/
diff --git a/drivers/soc/aspeed/Kconfig b/drivers/soc/aspeed/Kconfig
new file mode 100644
index ..457282cd1da5
--- /dev/null
+++ b/drivers/soc/aspeed/Kconfig
@@ -0,0 +1,19 @@
+menu "Aspeed SoC drivers"
+
+config ASPEED_LPC_CTRL
+ depends on (ARCH_ASPEED || COMPILE_TEST) && REGMAP && MFD_SYSCON
+ tristate "Aspeed ast2400/2500 HOST LPC to BMC bridge control"
+ ---help---
+ Control Aspeed ast2400/2500 HOST LPC to BMC mappings through
+ ioctl()s, the driver also provides a read/write interface to a BMC ram
+ region where the host LPC read/write region can be buffered.
+
+config ASPEED_LPC_SNOOP
+ tristate "Aspeed ast2500 HOST LPC snoop support"
+ depends on (ARCH_ASPEED || COMPILE_TEST) && REGMAP && MFD_SYSCON
+ help
+ Provides a driver to control the LPC snoop interface which
+ allows the BMC to listen on and save the data written by
+ the host to an arbitrary LPC I/O port.
+
+
diff --git a/drivers/soc/aspeed/Makefile b/drivers/soc/aspeed/Makefile
new file mode 100644
index ..cfaa9adc67b5
--- /dev/null
+++ b/drivers/soc/aspeed/Makefile
@@ -0,0 +1,2 @@
+obj-$(CONFIG_ASPEED_LPC_CTRL) += aspeed-lpc-ctrl.o
+obj-$(CONFIG_ASPEED_LPC_SNOOP) += aspeed-lpc-snoop.o
diff --git a/drivers/misc/aspeed-lpc-ctrl.c
b/drivers/soc/aspeed/aspeed-lpc-ctrl.c
similarity index
Re: [PATCH v3] signal: trace_signal_deliver when signal_group_exit
On 04/23, Greg KH wrote:
>On Mon, Apr 22, 2019 at 10:59:50PM +0800, Zhenliang Wei wrote:
>> In the fixes commit, removing SIGKILL from each thread signal mask and
>> executing "goto fatal" directly will skip the call to
>> "trace_signal_deliver". At this point, the delivery tracking of the
>> SIGKILL signal will be inaccurate.
>>
>> Therefore, we need to add trace_signal_deliver before "goto fatal"
>> after executing sigdelset.
>>
>> Note: The action[SIGKILL] must be SIG_DFL, and SEND_SIG_NOINFO matches
>> the fact that SIGKILL doesn't have any info.
>>
>> Acked-by: Christian Brauner
>> Fixes: cf43a757fd4944 ("signal: Restore the stop PTRACE_EVENT_EXIT")
>> Signed-off-by: Zhenliang Wei
>> ---
>> kernel/signal.c | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/kernel/signal.c b/kernel/signal.c index
>> 227ba170298e..0f69ada376ef 100644
>> --- a/kernel/signal.c
>> +++ b/kernel/signal.c
>> @@ -2441,6 +2441,7 @@ bool get_signal(struct ksignal *ksig)
>> if (signal_group_exit(signal)) {
>> ksig->info.si_signo = signr = SIGKILL;
>> sigdelset(>pending.signal, SIGKILL);
>> +trace_signal_deliver(SIGKILL, SEND_SIG_NOINFO, SIG_DFL);
>> recalc_sigpending();
>> goto fatal;
>> }
>> --
>> 2.14.1.windows.1
>>
>>
>
>
>
>This is not the correct way to submit patches for inclusion in the stable
>kernel tree. Please read:
>https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
>for how to do this properly.
>
>
Thans for your reply, is that mean I still need to add tags
Cc: sta...@vger.kernel.org
if I want to submit this patch to the stable kernel tree?
Is my understanding correct or missing?
Wei
Re: [PATCH 15/24] dt-bindings: pinctrl: pinctrl-mt65xx: add support for MT8516
On 23/04/2019 13:01, Linus Walleij wrote: > On Tue, Apr 16, 2019 at 11:12 AM Matthias Brugger > wrote: > >> Hi Linus, >> >> On 08/04/2019 22:44, Linus Walleij wrote: >>> On Sat, Mar 23, 2019 at 10:17 PM Fabien Parent wrote: >>> Add binding documentation of pinctrl-mt65xx for MT8516 SoC. Signed-off-by: Fabien Parent >>> >>> Patch applied with Rob's ACK. >>> >> >> I don't see this in your for-next branch. Did the patch got lost? > > I usually push the devel branch to be tested by the build robots > and then mix down the for-next branch. > > Recent week(s) the build robot was not responding so it got delayed. > I don't see it in the devel branch [1]. Can you please double check? [1] https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git/log/?h=devel
Re: [PATCH] soc: add aspeed folder and misc drivers
On Tue, Apr 23, 2019 at 1:08 AM Arnd Bergmann wrote:
>
> On Mon, Apr 22, 2019 at 7:38 PM Patrick Venture wrote:
> >
> > Create a SoC folder for the ASPEED parts and place the misc drivers
> > currently present into this folder. These drivers are not generic part
> > drivers, but rather only apply to the ASPEED SoCs.
> >
> > Signed-off-by: Patrick Venture
>
> Looks ok, but please resend to a...@kernel.org or s...@kernel.org
> so we can track the submission and make sure it gets applied if
> you want this to go through the arm-soc tree.
Thanks, I didn't see those come up in the get_maintainers output.
I had a longer question related to this patch progression -- if I am
moving the aspeed gpio driver to the soc folder, the soc tree may have
the soc/aspeed folder in their next, but the gpio tree wouldn't
necessarily. I know the branches sync up when things are merged at
the top, but I wasn't sure if there was another mechanism for this?
>
> If Greg wants to pick it up, that's fine too.
>
> Either way,
>
> Acked-by: Arnd Bergmann
>
> > ---
> > drivers/misc/Kconfig | 16
> > drivers/misc/Makefile | 2 --
> > drivers/soc/Kconfig | 1 +
> > drivers/soc/Makefile | 1 +
> > drivers/soc/aspeed/Kconfig| 19 +++
> > drivers/soc/aspeed/Makefile | 2 ++
> > .../{misc => soc/aspeed}/aspeed-lpc-ctrl.c| 0
> > .../{misc => soc/aspeed}/aspeed-lpc-snoop.c | 0
> > 8 files changed, 23 insertions(+), 18 deletions(-)
> > create mode 100644 drivers/soc/aspeed/Kconfig
> > create mode 100644 drivers/soc/aspeed/Makefile
> > rename drivers/{misc => soc/aspeed}/aspeed-lpc-ctrl.c (100%)
> > rename drivers/{misc => soc/aspeed}/aspeed-lpc-snoop.c (100%)
> >
> > diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
> > index 42ab8ec92a04..b80cb6af0cb4 100644
> > --- a/drivers/misc/Kconfig
> > +++ b/drivers/misc/Kconfig
> > @@ -496,22 +496,6 @@ config VEXPRESS_SYSCFG
> > bus. System Configuration interface is one of the possible means
> > of generating transactions on this bus.
> >
> > -config ASPEED_LPC_CTRL
> > - depends on (ARCH_ASPEED || COMPILE_TEST) && REGMAP && MFD_SYSCON
> > - tristate "Aspeed ast2400/2500 HOST LPC to BMC bridge control"
> > - ---help---
> > - Control Aspeed ast2400/2500 HOST LPC to BMC mappings through
> > - ioctl()s, the driver also provides a read/write interface to a
> > BMC ram
> > - region where the host LPC read/write region can be buffered.
> > -
> > -config ASPEED_LPC_SNOOP
> > - tristate "Aspeed ast2500 HOST LPC snoop support"
> > - depends on (ARCH_ASPEED || COMPILE_TEST) && REGMAP && MFD_SYSCON
> > - help
> > - Provides a driver to control the LPC snoop interface which
> > - allows the BMC to listen on and save the data written by
> > - the host to an arbitrary LPC I/O port.
> > -
> > config PCI_ENDPOINT_TEST
> > depends on PCI
> > select CRC32
> > diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
> > index d5b7d3404dc7..b9affcdaa3d6 100644
> > --- a/drivers/misc/Makefile
> > +++ b/drivers/misc/Makefile
> > @@ -54,8 +54,6 @@ obj-$(CONFIG_GENWQE) += genwqe/
> > obj-$(CONFIG_ECHO) += echo/
> > obj-$(CONFIG_VEXPRESS_SYSCFG) += vexpress-syscfg.o
> > obj-$(CONFIG_CXL_BASE) += cxl/
> > -obj-$(CONFIG_ASPEED_LPC_CTRL) += aspeed-lpc-ctrl.o
> > -obj-$(CONFIG_ASPEED_LPC_SNOOP) += aspeed-lpc-snoop.o
> > obj-$(CONFIG_PCI_ENDPOINT_TEST)+= pci_endpoint_test.o
> > obj-$(CONFIG_OCXL) += ocxl/
> > obj-y += cardreader/
> > diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
> > index c07b4a85253f..b750a88547c7 100644
> > --- a/drivers/soc/Kconfig
> > +++ b/drivers/soc/Kconfig
> > @@ -2,6 +2,7 @@ menu "SOC (System On Chip) specific Drivers"
> >
> > source "drivers/soc/actions/Kconfig"
> > source "drivers/soc/amlogic/Kconfig"
> > +source "drivers/soc/aspeed/Kconfig"
> > source "drivers/soc/atmel/Kconfig"
> > source "drivers/soc/bcm/Kconfig"
> > source "drivers/soc/fsl/Kconfig"
> > diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile
> > index 90b686e586c6..83a032db3e44 100644
> > --- a/drivers/soc/Makefile
> > +++ b/drivers/soc/Makefile
> > @@ -4,6 +4,7 @@
> > #
> >
> > obj-$(CONFIG_ARCH_ACTIONS) += actions/
> > +obj-y += aspeed/
> > obj-$(CONFIG_ARCH_AT91)+= atmel/
> > obj-y += bcm/
> > obj-$(CONFIG_ARCH_DOVE)+= dove/
> > diff --git a/drivers/soc/aspeed/Kconfig b/drivers/soc/aspeed/Kconfig
> > new file mode 100644
> > index ..457282cd1da5
> > --- /dev/null
> > +++ b/drivers/soc/aspeed/Kconfig
> > @@ -0,0 +1,19 @@
> > +menu "Aspeed SoC drivers"
> > +
> > +config ASPEED_LPC_CTRL
> > + depends on
Re: [PATCH v2 06/06] sound: isa: gus: fix misuse of %x
On Sun, 21 Apr 2019 13:48:44 +0200,
Fuqian Huang wrote:
>
> Pointers should be printed with %p or %px rather than
> cast to long type and printed with %lx.
> Change %lx to %p to print the pointer.
>
> Signed-off-by: Fuqian Huang
IMO, it's better to drop the address printing itself.
We don't want to expose the kernel address any longer.
Care to rewrite the patch?
thanks,
Takashi
> ---
> sound/isa/gus/gus_mem.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/sound/isa/gus/gus_mem.c b/sound/isa/gus/gus_mem.c
> index 4ac76f4..63e790f 100644
> --- a/sound/isa/gus/gus_mem.c
> +++ b/sound/isa/gus/gus_mem.c
> @@ -306,7 +306,7 @@ static void snd_gf1_mem_info_read(struct snd_info_entry
> *entry,
> used = 0;
> for (block = alloc->first, i = 0; block; block = block->next, i++) {
> used += block->size;
> - snd_iprintf(buffer, "Block %i at 0x%lx onboard 0x%x size %i
> (0x%x):\n", i, (long) block, block->ptr, block->size, block->size);
> + snd_iprintf(buffer, "Block %i at 0x%p onboard 0x%x size %i
> (0x%x):\n", i, block, block->ptr, block->size, block->size);
> if (block->share ||
> block->share_id[0] || block->share_id[1] ||
> block->share_id[2] || block->share_id[3])
> --
> 2.11.0
>
>
Re: [RESEND PATCH 0/7] Introduce bus domains controller framework
On 4/23/19 3:55 PM, Sudeep Holla wrote: > On Tue, Apr 23, 2019 at 01:33:19PM +, Benjamin GAIGNARD wrote: >> On 4/23/19 3:21 PM, Sudeep Holla wrote: >>> On Mon, Mar 18, 2019 at 12:05:54PM +0100, Benjamin Gaignard wrote: Le lun. 18 mars 2019 à 11:43, Sudeep Holla a écrit : > On Mon, Mar 18, 2019 at 11:05:58AM +0100, Benjamin Gaignard wrote: >> Bus domains controllers allow to divided system on chip into multiple >> domains >> that can be used to select by who hardware blocks could be accessed. >> A domain could be a cluster of CPUs (or coprocessors), a range of >> addresses or >> a group of hardware blocks. >> >> Framework architecture is inspirated by pinctrl framework: >> - a default configuration could be applied before bind the driver >> - configurations could be apllied dynamically by drivers >> - device node provides the bus domains configurations >> >> An example of bus domains controller is STM32 ETZPC hardware block >> which got 3 domains: >> - secure: hardware blocks are only accessible by software running on >> trust >> zone. >> - non-secure: hardware blocks are accessible by non-secure software (i.e. >> linux kernel). >> - coprocessor: hardware blocks are only accessible by the corpocessor. >> Up to 94 hardware blocks of the soc could be managed by ETZPC and >> assigned to one of the three domains. >> > You fail to explain why do we need this in non-secure Linux ? > You need to have solid reasons as why this can't be done in secure > firmware. And yes I mean even on arm32. On platforms with such hardware > capabilities you will need some secure firmware to be running and these > things can be done there. I don't want this enabled for ARM64 at all, > firmware *has to deal* with this. We use ETZPC to define if hardware blocks can be used by Cortex A7 or Cortex M4 (both non-secure) on STM32MP1 SoC, this new framework allow to change hardware block split at runtime. This could be done even on non-secure world because their is nothing critical to change hardware blocks users. >>> OK, that's interesting, assuming Cortex M4 execution as non-secure. I would >>> expect otherwise. Even if it's configurable, I would see that happen in >>> secure entity via OPTEE or something similar from non-secure side. >> Your assumption is correct Cortex M4 execution is non-secure. > Sorry if I was not clear. I told Cortex M4 non-secure execution is interesting > as I expected it to be secure. > >>> Do you have any documents that I can refer to get the overall security >>> design for such platforms ? >> SoC datasheet is here: >> >> https://www.st.com/resource/en/datasheet/stm32mp157a.pdf >> >> with just few words about ETZPC: >> >> 3.14 TrustZone protection controller (ETZPC) >> ETZPC is used to configure TrustZone security of bus masters and slaves with >> programmable-security attributes (securable resources) such as: >> • On-chip SYSRAM with programmable secure region size >> • AHB and APB peripherals to be made secure >> Notice that by default, SYSRAM and peripheral are set to secure access >> only, so, not accessible by non-secure masters such as Cortex-M4 or >> DMA1/DMA2. >> ETZPC can also allocate peripherals and SRAM to be accessible only by >> the Cortex-M4 and/or DMA1/DMA2. This ensures the safe execution of the >> Cortex-M4 firmware, protected from other masters (e.g. Cortex-A7) unwanted >> accesses. >> > The above statement makes me wonder if Cortex-M4 firmware is really > non-secure, if so why does it need such an isolation from other masters > like Cortex-A7. For me Cortex-M4 is secure and Cortex-A7 can execute > in non-secure hence Cortex-M4 needs to be isolated from Cortex-A7 as > mentioned in the above excerpts from the datasheet. Cortex-M4 firmware is non-secure, it could be a free RTOS. ETZPC doesn't isolate Cortex M4 or A7 but control which of them have access to hardware blocks. For example ETZPC controls if M4 or A7 can have access to I2C hardware blocks. The goal is to make sure firmware running on each side don't use the hardware blocks of the other side. Benjamin > > -- > Regards, > Sudeep
Re: [PATCH v4 14/16] locking/rwsem: Guard against making count negative
On Sun, Apr 21, 2019 at 05:07:56PM -0400, Waiman Long wrote:
> How about the following chunks to disable preemption temporarily for the
> increment-check-decrement sequence?
>
> diff --git a/include/linux/preempt.h b/include/linux/preempt.h
> index dd92b1a93919..4cc03ac66e13 100644
> --- a/include/linux/preempt.h
> +++ b/include/linux/preempt.h
> @@ -250,6 +250,8 @@ do { \
> #define preempt_enable_notrace() barrier()
> #define preemptible() 0
>
> +#define __preempt_disable_nop /* preempt_disable() is nop */
> +
> #endif /* CONFIG_PREEMPT_COUNT */
>
> #ifdef MODULE
> diff --git a/kernel/locking/rwsem.c b/kernel/locking/rwsem.c
> index 043fd29b7534..54029e6af17b 100644
> --- a/kernel/locking/rwsem.c
> +++ b/kernel/locking/rwsem.c
> @@ -256,11 +256,64 @@ static inline struct task_struct
> *rwsem_get_owner(struct r
> return (struct task_struct *) (cowner
> ? cowner | (sowner & RWSEM_NONSPINNABLE) : sowner);
> }
> +
> +/*
> + * If __preempt_disable_nop is defined, calling preempt_disable() and
> + * preempt_enable() directly is the most efficient way. Otherwise, it may
> + * be more efficient to disable and enable interrupt instead for disabling
> + * preemption tempoarily.
> + */
> +#ifdef __preempt_disable_nop
> +#define disable_preemption() preempt_disable()
> +#define enable_preemption() preempt_enable()
> +#else
> +#define disable_preemption() local_irq_disable()
> +#define enable_preemption() local_irq_enable()
> +#endif
I'm not aware of an architecture where disabling interrupts is faster
than disabling preemption.
> +/*
> + * When the owner task structure pointer is merged into couunt, less bits
> + * will be available for readers. Therefore, there is a very slight chance
> + * that the reader count may overflow. We try to prevent that from
> happening
> + * by checking for the MS bit of the count and failing the trylock attempt
> + * if this bit is set.
> + *
> + * With preemption enabled, there is a remote possibility that preemption
> + * can happen in the narrow timing window between incrementing and
> + * decrementing the reader count and the task is put to sleep for a
> + * considerable amount of time. If sufficient number of such unfortunate
> + * sequence of events happen, we may still overflow the reader count.
> + * To avoid such possibility, we have to disable preemption for the
> + * whole increment-check-decrement sequence.
> + *
> + * The function returns true if there are too many readers and the count
> + * has already been properly decremented so the reader must go directly
> + * into the wait list.
> + */
> +static inline bool rwsem_read_trylock(struct rw_semaphore *sem, long *cnt)
> +{
> + bool wait = false; /* Wait now flag */
> +
> + disable_preemption();
> + *cnt = atomic_long_fetch_add_acquire(RWSEM_READER_BIAS,
> >count);
> + if (unlikely(*cnt < 0)) {
> + atomic_long_add(-RWSEM_READER_BIAS, >count);
> + wait = true;
> + }
> + enable_preemption();
> + return wait;
> +}
> #else /* !CONFIG_RWSEM_OWNER_COUNT */
This also means you have to ensure CONFIG_NR_CPUS < 32K for
RWSEM_OWNER_COUNT.
> static inline struct task_struct *rwsem_get_owner(struct rw_semaphore *sem)
> {
> return READ_ONCE(sem->owner);
> }
> +
> +static inline bool rwsem_read_trylock(struct rw_semaphore *sem, long *cnt)
> +{
> + *cnt = atomic_long_fetch_add_acquire(RWSEM_READER_BIAS,
> >count);
> + return false;
> +}
> #endif /* CONFIG_RWSEM_OWNER_COUNT */
>
> /*
> @@ -981,32 +1034,18 @@ static inline void clear_wr_nonspinnable(struct
> rw_semaph
> * Wait for the read lock to be granted
> */
> static struct rw_semaphore __sched *
> -rwsem_down_read_slowpath(struct rw_semaphore *sem, int state, long count)
> +rwsem_down_read_slowpath(struct rw_semaphore *sem, int state, const
> bool wait)
> {
> - long adjustment = -RWSEM_READER_BIAS;
> + long count, adjustment = -RWSEM_READER_BIAS;
> bool wake = false;
> struct rwsem_waiter waiter;
> DEFINE_WAKE_Q(wake_q);
>
> - if (unlikely(count < 0)) {
> + if (unlikely(wait)) {
> /*
> - * The sign bit has been set meaning that too many active
> - * readers are present. We need to decrement reader count &
> - * enter wait queue immediately to avoid overflowing the
> - * reader count.
> - *
> - * As preemption is not disabled, there is a remote
> - * possibility that preemption can happen in the narrow
> - * timing window between incrementing and decrementing
> - * the reader count and the task is put to sleep for a
> - * considerable amount of time. If sufficient number
> - * of such unfortunate sequence of events happen, we
> - * may still
Re: [PATCH] x86/mm/mem_encrypt: fix a crash with kmemleak_scan
On Tue, 2019-04-23 at 15:25 +0200, Borislav Petkov wrote: > So I guess free_init_pages() should be somehow telling kmemleak, "hey, > just freed that object, pls adjust your tracking lists" no? > > Because, otherwise, if we start sprinkling those kmemleak_free_part() > calls everywhere, that'll quickly turn into a game of whack-a-mole. And > we don't need that especially if kmemleak can easily be taught to handle > such cases. In reality, this is only the second place that needs this kmemleak_free_part() call for all those years since kmemleak was born.
[PATCH v3 1/2] thermal: rcar_gen3_thermal: fix interrupt type
Currently IRQF_SHARED type interrupt line is allocated, but it
is not appropriate, as the interrupt line isn't shared between
different devices, instead IRQF_ONESHOT is the proper type.
By changing interrupt type to IRQF_ONESHOT, now irq handler is
no longer needed, as clear of interrupt status can be done in
threaded interrupt context.
Because IRQF_ONESHOT type interrupt line is kept disabled until
the threaded handler has been run, so there is no need to protect
read/write of REG_GEN3_IRQSTR with lock.
Signed-off-by: Jiada Wang
---
drivers/thermal/rcar_gen3_thermal.c | 34 +
1 file changed, 6 insertions(+), 28 deletions(-)
diff --git a/drivers/thermal/rcar_gen3_thermal.c
b/drivers/thermal/rcar_gen3_thermal.c
index 88fa41cf16e8..ebbaef5a3cf1 100644
--- a/drivers/thermal/rcar_gen3_thermal.c
+++ b/drivers/thermal/rcar_gen3_thermal.c
@@ -231,39 +231,17 @@ static void rcar_thermal_irq_set(struct
rcar_gen3_thermal_priv *priv, bool on)
static irqreturn_t rcar_gen3_thermal_irq(int irq, void *data)
{
struct rcar_gen3_thermal_priv *priv = data;
+ int i;
u32 status;
- int i, ret = IRQ_HANDLED;
- spin_lock(>lock);
for (i = 0; i < priv->num_tscs; i++) {
status = rcar_gen3_thermal_read(priv->tscs[i], REG_GEN3_IRQSTR);
rcar_gen3_thermal_write(priv->tscs[i], REG_GEN3_IRQSTR, 0);
if (status)
- ret = IRQ_WAKE_THREAD;
+ thermal_zone_device_update(priv->tscs[i]->zone,
+ THERMAL_EVENT_UNSPECIFIED);
}
- if (ret == IRQ_WAKE_THREAD)
- rcar_thermal_irq_set(priv, false);
-
- spin_unlock(>lock);
-
- return ret;
-}
-
-static irqreturn_t rcar_gen3_thermal_irq_thread(int irq, void *data)
-{
- struct rcar_gen3_thermal_priv *priv = data;
- unsigned long flags;
- int i;
-
- for (i = 0; i < priv->num_tscs; i++)
- thermal_zone_device_update(priv->tscs[i]->zone,
- THERMAL_EVENT_UNSPECIFIED);
-
- spin_lock_irqsave(>lock, flags);
- rcar_thermal_irq_set(priv, true);
- spin_unlock_irqrestore(>lock, flags);
-
return IRQ_HANDLED;
}
@@ -390,9 +368,9 @@ static int rcar_gen3_thermal_probe(struct platform_device
*pdev)
if (!irqname)
return -ENOMEM;
- ret = devm_request_threaded_irq(dev, irq, rcar_gen3_thermal_irq,
- rcar_gen3_thermal_irq_thread,
- IRQF_SHARED, irqname, priv);
+ ret = devm_request_threaded_irq(dev, irq, NULL,
+ rcar_gen3_thermal_irq,
+ IRQF_ONESHOT, irqname, priv);
if (ret)
return ret;
}
--
2.19.2
[PATCH v3 2/2] thermal: rcar_gen3_thermal: disable interrupt in .remove
Currently IRQ is remain enabled after .remove, later if device is probed,
IRQ is requested before .thermal_init, this may cause IRQ function be
called before device is initialized.
this patch by disable interrupt in .remove, to ensure irq function
only be called after device is fully initialized.
Signed-off-by: Jiada Wang
---
drivers/thermal/rcar_gen3_thermal.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/thermal/rcar_gen3_thermal.c
b/drivers/thermal/rcar_gen3_thermal.c
index ebbaef5a3cf1..c63a86d3dac6 100644
--- a/drivers/thermal/rcar_gen3_thermal.c
+++ b/drivers/thermal/rcar_gen3_thermal.c
@@ -309,6 +309,9 @@ MODULE_DEVICE_TABLE(of, rcar_gen3_thermal_dt_ids);
static int rcar_gen3_thermal_remove(struct platform_device *pdev)
{
struct device *dev = >dev;
+ struct rcar_gen3_thermal_priv *priv = dev_get_drvdata(dev);
+
+ rcar_thermal_irq_set(priv, false);
pm_runtime_put(dev);
pm_runtime_disable(dev);
--
2.19.2
[PATCH v3 0/2] thermal: rcar_gen3_thermal: fix IRQ issues
There are issues with interrupt handling in rcar_gen3_thermal driver. Currently IRQ is remain enabled after .remove, later if device is probed, IRQ is requested before .thermal_init, this may cause IRQ function be triggered but not able to clear IRQ status, thus cause system to hang. Since the irq line isn't shared between different devices, so the proper interrupt type flag should be IRQF_ONESHOT. This patch-set fix these interrupt handling retated issues. --- v3: fix to use correct code base remove unused "flag" variable in rcar_gen3_thermal_irq v2: use irq type IRQF_ONESHOT instead of IRQF_SHARED disable interrupt in .remove v1: initial version Jiada Wang (2): thermal: rcar_gen3_thermal: fix interrupt type thermal: rcar_gen3_thermal: disable interrupt in .remove Jiada Wang (2): thermal: rcar_gen3_thermal: fix interrupt type thermal: rcar_gen3_thermal: disable interrupt in .remove drivers/thermal/rcar_gen3_thermal.c | 37 +++-- 1 file changed, 9 insertions(+), 28 deletions(-) -- 2.19.2
Re: [PATCH v3] signal: trace_signal_deliver when signal_group_exit
On 04/23, Oleg wrote: >On 04/23, weizhenliang wrote: >> >> Last time Oleg suggested using SIG_DFL as the third parameter, but its type >> is 'void (*)(int)', but not expected 'struct k_sigaction *'. > >Yes I misread the signature of TRACE_EVENT(signal_deliver), and I thought you >at least compiled the kernel with your patch applied ;) > >> How about >> trace_signal_deliver(SIGKILL, SEND_SIG_NOINFO, >action[signr >> - 1]); ? > >sure, this should fix the problem. Sorry about that, I will pay more attention to it in the future. And thanks for your reply, I will re-adjust the patch later. Wei.
Re: [PATCH v3] arm64: sysreg: make mrs_s and msr_s macros work with Clang and LTO
On Mon, Apr 22, 2019 at 10:44:10AM -0700, Nick Desaulniers wrote:
> On Tue, Apr 16, 2019 at 9:03 PM Kees Cook wrote:
> >
> > On Tue, Apr 16, 2019 at 12:08 PM Mark Rutland wrote:
> > >
> > > On Mon, Apr 15, 2019 at 10:22:27AM -0700, Nick Desaulniers wrote:
> > > > On Mon, Apr 15, 2019 at 10:06 AM Mark Rutland
> > > > wrote:
> > > > > It would be nice if we could simply rely on a more recent binutils
> > > > > these
> > > > > days, which supports the generic S sysreg
> > > > > definition. That would mean we could get rid of the whole msr_s/mrs_s
> > > > > hack by turning that into a CPP macro which built that name.
>
> Mark, can you give me a test case for this? I'd like to check if
> clang's integrated assembler supports this or not, so we can file an
> issue and fix it if not.
The below is a smoke test. The entire op0:op1:cn:cm:op2 space is 14
bits, so it should be feasible to generate and run an exhautive test for
all encodings.
I've included SYS and SYSL here too, since I strongly suspect we'll need
those going forward.
Thanks
Mark.
>8
/*
* ${CC} -c test.c
*
* OLD_* encodings already exist, NEW_* encodings haven't yet be
* allocated (per ARM DDI 0487D.a), but should assemble. All encodings
* chosen arbitrarily.
*/
// OSDTRRX_EL1
#define OLD_DBG_REG "s2_0_c0_c0_2"
#define NEW_DBG_REG "s2_7_c0_c15_0"
// MIDR_EL1
#define OLD_SYS_REG "s3_0_c0_c0_0"
#define NEW_SYS_REG "s3_6_c1_c0_7"
#define REG(r) \
asm volatile("msr " r ", xzr\n"); \
asm volatile("mrs xzr, " r "\n")
// DC IVAC, XZR
#define OLD_SYS "#0, c7, c6, #1"
#define NEW_SYS "#7, c15, c15, #7"
#define NEW_SYSL_MIN"#0, c0, c0, #0"
#define NEW_SYSL_MAX"#7, c15, c15, #7"
#define SYS(s) asm volatile("sys " s ", xzr\n")
#define SYSL(s) asm volatile("sysl xzr, " s "\n")
void test(void)
{
REG(OLD_DBG_REG);
REG(NEW_DBG_REG);
REG(OLD_SYS_REG);
REG(NEW_SYS_REG);
SYS(OLD_SYS);
SYS(NEW_SYS);
SYSL(NEW_SYSL_MIN);
SYSL(NEW_SYSL_MAX);
}
Re: [PATCH v1 09/15] dmaengine: imx-sdma: remove ERR009165 on i.mx6ul
On Tue, Apr 23, 2019 at 10:51 AM Robin Gong wrote:
>
> ECSPI issue fixed from i.mx6ul at hardware level, no need
> ERR009165 anymore on those chips such as i.mx8mq. Add i.mx6sx
> from where i.mx6ul source.
>
> Signed-off-by: Robin Gong
> ---
> drivers/dma/imx-sdma.c | 43 ++-
> 1 file changed, 42 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
> index 1e20470..99c44a5 100644
> --- a/drivers/dma/imx-sdma.c
> +++ b/drivers/dma/imx-sdma.c
> @@ -419,6 +419,7 @@ struct sdma_driver_data {
> int num_events;
> struct sdma_script_start_addrs *script_addrs;
> bool check_ratio;
> + bool ecspi_fixed;
Please state the erratum number in the variable name, such as
has_err009165_fixed
Re: next-20190408..0418: Suspend/resume problems on Thinkpad X60
On 4/23/19 3:22 AM, Pavel Machek wrote: >>> It boots ok (unlike mainline -- I'm debugging that), and I can suspend >>> and resume... but then cursor in X is moving and I can talk to >>> applications cached in memory, but any access to disk hangs. >> >> Mainline problem was identified. >> >> But resume is still broken. I took advantage of fact that I can still >> do cached commands, and got complete dmesg. I'm attaching it. > > Still broken in 0418. Ideas would be welcome at this point. Have you already tried the debugging steps explained in Documentation/power to obtain more information about the nature of the suspend/resume problem? Bart.
Re: [PATCH RESEND v3 4/4] pinctrl: add drive for I2C related pins on MT8183
On 23/04/2019 12:59, Linus Walleij wrote: > On Tue, Apr 16, 2019 at 10:08 AM Matthias Brugger > wrote: >> On 25/03/2019 13:41, Zhiyong Tao wrote: >>> This patch provides the advanced drive for I2C used pins on MT8183. >>> The detail strength specification description of the I2C pin: >>> When E1=0/E0=0, the strength is 0.125mA. >>> When E1=0/E0=1, the strength is 0.25mA. >>> When E1=1/E0=0, the strength is 0.5mA. >>> When E1=1/E0=1, the strength is 1mA. >>> For I2C pins, there are existing generic driving setup and the above >>> specific driving setup. I2C pins can only support 2/4/6/8/10/12/14/16mA >>> driving adjustment in generic driving setup. But in specific driving >>> setup, they can support 0.125/0.25/0.5/1mA adjustment. >>> If we enable specific driving setup for I2C pins, >>> the existing generic driving setup will be disabled. >>> For some special features, we need the I2C pins specific driving setup. >>> The specific driving setup is controlled by E1E0EN. >>> So we need add extra vendor driving preperty instead of the generic >>> driving property. We can add "mediatek,drive-strength-adv = ;" >>> to describe the specific driving setup property. >>> "XXX" means the value of E1E0EN. So the valid arguments of >>> "mediatek,drive-strength-adv" are from 0 to 7. >>> >>> Signed-off-by: Zhiyong Tao >>> --- >>> drivers/pinctrl/mediatek/pinctrl-mt8183.c| 50 >>> >>> drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c | 47 >>> ++ >>> drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h | 11 ++ >>> drivers/pinctrl/mediatek/pinctrl-paris.c | 12 ++ >>> 4 files changed, 120 insertions(+) >>> >> >> Linus, did that fall through the cracks? Do you have any comments on this >> driver? > > It's applied AFAICT. Maybe I forgot to push the branch, but its there. > > Please confirm so I didn't miss anything! > I can see now both of them 1/4 and 4/4. Thanks! Matthias
Re: [PATCH v2 3/3] iio: Add PAT9125 optical tracker sensor
Hi Peter, On 4/23/19 13:33, Peter Meerwald-Stadler wrote: how is this thing different from a mouse device? I developed this driver to detect the board movement which can't be detected by accelerometer (very slow motion). I admit this use case can be handled by an input, and I'm agree with you, PAT9125 driver could be an input. But this chip is able to track different kind of motion (flat and rotation), and additionally have an interrupt GPIO, so using it like input limit the driver potential. This chip is designed to work in industrial measurement or embedded systems, and the IIO API match with these environments, so IIO is the best way to exploit the entire potential of this chip. As I understand (from https://www.kernel.org/doc/html/v4.12/input/event-codes.html#mice ), mouse driver must report values when the device move. This feature souldn't be mandatory for an optical tracker driver, specially for cases where user prefers to use buffer or poll only when he need data. All other comments will be fixed in V3. Regards, Alexandre
Re: [PATCH v1 02/15] Revert "ARM: dts: imx6: Use correct SDMA script for SPI cores"
On Tue, Apr 23, 2019 at 10:50 AM Robin Gong wrote: > > This reverts commit dd4b487b32a3571fdcc66062e661e3a3e360e35b. Same here.
Re: [PATCH v1 01/15] Revert "ARM: dts: imx6q: Use correct SDMA script for SPI5 core"
Hi Robin, On Tue, Apr 23, 2019 at 10:50 AM Robin Gong wrote: > > This reverts commit df07101e1c4a29e820df02f9989a066988b160e6. You need to provide a detailed explanation in the commit log as to why the revert is needed.
Re: [PATCH] x86/mm/mem_encrypt: fix a crash with kmemleak_scan
Hi Boris,
On Tue, Apr 23, 2019 at 03:25:18PM +0200, Borislav Petkov wrote:
> On Thu, Apr 18, 2019 at 10:50:15AM +0100, Catalin Marinas wrote:
> > Kmemleak is basically a tri-colour marking tracing garbage collector [1]
>
> Thanks for that - interesting read.
>
> > but without automatic freeing. It relies on a graph of references
> > (pointers) between various objects and the root of such graph is the
> > .bss/.data.
Sorry for the misleading information here, the root of the graph was
changed recently (see below).
> > free_init_pages() is called on memory regions outside .bss/.data like
> > smp_locks, initrd, kernel init text which kmemleak does not track
> > anyway. That said, kmemleak_free_part() is tolerant to unknown pointers,
> > so we could call it directly from free_init_pages().
>
> Ok, lemme think out loud for a bit here: kmemleak_scan() goes over
> an object list and I guess in our particular case, the memory which
> got freed in mem_encrypt_free_decrypted_mem() *was* in that list too,
> leading to the crash.
Yes.
> Looking at the splat, it is in scan_gray_list() which would mean that
> the object we freed was reachable from the root(s) in .bss.
The .bss/.data used to be root until recently when commit 298a32b13208
("kmemleak: powerpc: skip scanning holes in the .bss section") changed
this to accommodate a similar problem on powerpc. With this commit,
.bss/.data are traced objects but painted "grey" by default so that they
will be always scanned, pretty much like the root (and they can't
"leak").
In Qian's splat, the unmapped area was actually in the .bss which is now
a traced object (no longer a root one). In his previous report on
powerpc [1], the splat was in scan_large_block().
> Now, the docs say:
>
> "The memory allocations via :c:func:`kmalloc`, :c:func:`vmalloc`,
> :c:func:`kmem_cache_alloc` and
> friends are traced and the pointers, together with additional
> information like size and stack trace, are stored in a rbtree."
>
> So I guess free_init_pages() should be somehow telling kmemleak, "hey,
> just freed that object, pls adjust your tracking lists" no?
>
> Because, otherwise, if we start sprinkling those kmemleak_free_part()
> calls everywhere, that'll quickly turn into a game of whack-a-mole. And
> we don't need that especially if kmemleak can easily be taught to handle
> such cases.
Object freeing is tracked in general via the corresponding kfree(),
vfree() etc. and don't need special handling. The .bss doesn't have this
alloc/free symmetry and not freeing it all either, hence this
workaround to register it as a traced object and allow partial freeing.
Anyway, I agree with you. As I mentioned in the previous email,
kmemleak_free_part() is tolerant to unknown objects (not tracked by
kmemleak), so I'm fine with calling it from free_init_pages() even if
not all address ranges passed to this function are known to kmemleak.
> > There is Documentation/dev-tools/kmemleak.rst briefly mentioning the
> > tracing garbage collector (although the Wikipedia link is no longer
> > valid, it should be replaced with [1]). It doesn't, however, state why
> > .bss/.data are special.
>
> The fact that they're special is important info, I'd say.
I took a note to improve this when I get some time.
> > [1]
> > https://en.wikipedia.org/wiki/Tracing_garbage_collection#Tri-color_marking
>
> is nice. While reading, it made me think how our discussion would go if
> we didn't have wikipedia. You'd probably say, go to the library and read
> this and that section in this and that book on tri-color marking. :-)
There are probably some academic papers published somewhere ;). But
wikipedia makes things much easier (and free).
--
Catalin
[1] http://lkml.kernel.org/r/20190312191412.28656-1-...@lca.pw
Re: [PATCH v3] signal: trace_signal_deliver when signal_group_exit
On Tue, Apr 23, 2019 at 09:41 PM Christian wrote:
>On Tue, Apr 23, 2019 at 01:10:52PM +, weizhenliang wrote:
>> On Mon, Apr 22, 2019 at 11:25 PM Oleg Nesterov wrote:
>> >On 04/22, Zhenliang Wei wrote:
>> >>
>> >> --- a/kernel/signal.c
>> >> +++ b/kernel/signal.c
>> >> @@ -2441,6 +2441,7 @@ bool get_signal(struct ksignal *ksig)
>> >> if (signal_group_exit(signal)) {
>> >> ksig->info.si_signo = signr = SIGKILL;
>> >> sigdelset(>pending.signal, SIGKILL);
>> >> + trace_signal_deliver(SIGKILL, SEND_SIG_NOINFO, SIG_DFL);
>> >> recalc_sigpending();
>> >> goto fatal;
>> >> }
>> >
>> >Reviewed-by: Oleg Nesterov
>>
>> Last time Oleg suggested using SIG_DFL as the third parameter, but its type
>> is 'void (*)(int)', but not expected 'struct k_sigaction *'.
>
>Sigh, I should've caught that in the first commit.
>Although it suggests you didn't even compile your patch...
>
>>
>> How about
>> trace_signal_deliver(SIGKILL, SEND_SIG_NOINFO, >action[signr
>> - 1]); ?
>
>That should work, yes.
Sorry about that, I was too focused on the functionality and didn't notice the
compile warning.
And thanks for your reply, I will pay more attention to it in the future.
Zhenliang Wei
Re: [PATCH v2] x86: kvm: hyper-v: deal with buggy TLB flush requests from WS2012
On Tue, Apr 23, 2019 at 03:15:37PM +0200, Vitaly Kuznetsov wrote: > It was reported that with some special Multi Processor Group configuration, > e.g: > bcdedit.exe /set groupsize 1 > bcdedit.exe /set maxgroup on > bcdedit.exe /set groupaware on > for a 16-vCPU guest WS2012 shows BSOD on boot when PV TLB flush mechanism > is in use. > > Tracing kvm_hv_flush_tlb immediately reveals the issue: > > kvm_hv_flush_tlb: processor_mask 0x0 address_space 0x0 flags 0x2 > > The only flag set in this request is HV_FLUSH_ALL_VIRTUAL_ADDRESS_SPACES, > however, processor_mask is 0x0 and no HV_FLUSH_ALL_PROCESSORS is specified. > We don't flush anything and apparently it's not what Windows expects. > > TLFS doesn't say anything about such requests and newer Windows versions > seem to be unaffected. This all feels like a WS2012 bug, which is, however, > easy to workaround in KVM: let's flush everything when we see an empty > flush request, over-flushing doesn't hurt. > > Signed-off-by: Vitaly Kuznetsov > --- Reviewed-by: Sean Christopherson
[PATCH v3 1/3] arm64/fpsimd: Remove the prototype for sve_flush_cpu_state()
The function sve_flush_cpu_state() has been removed in commit 21cdd7fd76e3
("KVM: arm64: Remove eager host SVE state saving").
So remove the associated prototype in asm/fpsimd.h.
Signed-off-by: Julien Grall
Reviewed-by: Dave Martin
---
Changes in v3:
- Add Dave's reviewed-by
- Fix checkpatch style error when mentioning a commit
Changes in v2:
- Patch added
---
arch/arm64/include/asm/fpsimd.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm64/include/asm/fpsimd.h b/arch/arm64/include/asm/fpsimd.h
index df62bbd33a9a..b73d12fcc7f9 100644
--- a/arch/arm64/include/asm/fpsimd.h
+++ b/arch/arm64/include/asm/fpsimd.h
@@ -64,7 +64,6 @@ extern void fpsimd_bind_state_to_cpu(struct user_fpsimd_state
*state,
extern void fpsimd_flush_task_state(struct task_struct *target);
extern void fpsimd_flush_cpu_state(void);
-extern void sve_flush_cpu_state(void);
/* Maximum VL that SVE VL-agnostic software can transparently support */
#define SVE_VL_ARCH_MAX 0x100
--
2.11.0
[PATCH v3 2/3] arch/arm64: fpsimd: Introduce fpsimd_save_and_flush_cpu_state() and use it
The only external user of fpsimd_save() and fpsimd_flush_cpu_state() is
the KVM FPSIMD code.
A following patch will introduce a mechanism to acquire owernship of the
FPSIMD/SVE context for performing context management operations. Rather
than having to export the new helpers to get/put the context, we can just
introduce a new function to combine fpsimd_save() and
fpsimd_flush_cpu_state().
This has also the advantage to remove any external call of fpsimd_save()
and fpsimd_flush_cpu_state(), so they can be turned static.
Lastly, the new function can also be used in the PM notifier.
Signed-off-by: Julien Grall
---
kernel_neon_begin() does not use fpsimd_save_and_flush_cpu_state()
because the next patch will modify the function to also grab the
FPSIMD/SVE context.
Changes in v3:
- Rework the commit message
- Move the prototype of fpsimd_save_and_flush_cpu_state()
further down in the header
- Remove comment in kvm_arch_vcpu_put_fp()
Changes in v2:
- Patch added
---
arch/arm64/include/asm/fpsimd.h | 5 ++---
arch/arm64/kernel/fpsimd.c | 17 +
arch/arm64/kvm/fpsimd.c | 4 +---
3 files changed, 16 insertions(+), 10 deletions(-)
diff --git a/arch/arm64/include/asm/fpsimd.h b/arch/arm64/include/asm/fpsimd.h
index b73d12fcc7f9..c311d36ecffe 100644
--- a/arch/arm64/include/asm/fpsimd.h
+++ b/arch/arm64/include/asm/fpsimd.h
@@ -48,8 +48,6 @@ struct task_struct;
extern void fpsimd_save_state(struct user_fpsimd_state *state);
extern void fpsimd_load_state(struct user_fpsimd_state *state);
-extern void fpsimd_save(void);
-
extern void fpsimd_thread_switch(struct task_struct *next);
extern void fpsimd_flush_thread(void);
@@ -63,7 +61,8 @@ extern void fpsimd_bind_state_to_cpu(struct user_fpsimd_state
*state,
void *sve_state, unsigned int sve_vl);
extern void fpsimd_flush_task_state(struct task_struct *target);
-extern void fpsimd_flush_cpu_state(void);
+
+extern void fpsimd_save_and_flush_cpu_state(void);
/* Maximum VL that SVE VL-agnostic software can transparently support */
#define SVE_VL_ARCH_MAX 0x100
diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
index 56afa40263d9..5313aa257be6 100644
--- a/arch/arm64/kernel/fpsimd.c
+++ b/arch/arm64/kernel/fpsimd.c
@@ -246,7 +246,7 @@ static void task_fpsimd_load(void)
*
* Softirqs (and preemption) must be disabled.
*/
-void fpsimd_save(void)
+static void fpsimd_save(void)
{
struct fpsimd_last_state_struct const *last =
this_cpu_ptr(_last_state);
@@ -1122,12 +1122,22 @@ void fpsimd_flush_task_state(struct task_struct *t)
* Invalidate any task's FPSIMD state that is present on this cpu.
* This function must be called with softirqs disabled.
*/
-void fpsimd_flush_cpu_state(void)
+static void fpsimd_flush_cpu_state(void)
{
__this_cpu_write(fpsimd_last_state.st, NULL);
set_thread_flag(TIF_FOREIGN_FPSTATE);
}
+/*
+ * Save the FPSIMD state to memory and invalidate cpu view.
+ * This function must be called with softirqs (and preemption) disabled.
+ */
+void fpsimd_save_and_flush_cpu_state(void)
+{
+ fpsimd_save();
+ fpsimd_flush_cpu_state();
+}
+
#ifdef CONFIG_KERNEL_MODE_NEON
DEFINE_PER_CPU(bool, kernel_neon_busy);
@@ -1284,8 +1294,7 @@ static int fpsimd_cpu_pm_notifier(struct notifier_block
*self,
{
switch (cmd) {
case CPU_PM_ENTER:
- fpsimd_save();
- fpsimd_flush_cpu_state();
+ fpsimd_save_and_flush_cpu_state();
break;
case CPU_PM_EXIT:
break;
diff --git a/arch/arm64/kvm/fpsimd.c b/arch/arm64/kvm/fpsimd.c
index 6e3c9c8b2df9..525010504f9d 100644
--- a/arch/arm64/kvm/fpsimd.c
+++ b/arch/arm64/kvm/fpsimd.c
@@ -112,9 +112,7 @@ void kvm_arch_vcpu_put_fp(struct kvm_vcpu *vcpu)
if (vcpu->arch.flags & KVM_ARM64_FP_ENABLED) {
u64 *guest_zcr = >arch.ctxt.sys_regs[ZCR_EL1];
- /* Clean guest FP state to memory and invalidate cpu view */
- fpsimd_save();
- fpsimd_flush_cpu_state();
+ fpsimd_save_and_flush_cpu_state();
if (guest_has_sve)
*guest_zcr = read_sysreg_s(SYS_ZCR_EL12);
--
2.11.0
[PATCH v3 0/3] arm64/fpsimd: Don't disable softirq when touching FPSIMD/SVE state
Hi all, This patch series keeps softirqs enabled while touching FPSIMD/SVE state. For more details on the impact see patch #3. This patch series has been benchmarked on Linux 5.1-rc4 with defconfig. On Juno2: * hackbench 100 process 1000 (10 times) * .7% quicker On ThunderX 2: * hackbench 1000 process 1000 (20 times) * 3.4% quicker Note that while the benchmark has been done on 5.1-rc4, the patch series is based on kvm-arm/next as it has few conflicts with the SVE KVM series. Cheers, Julien Grall (3): arm64/fpsimd: Remove the prototype for sve_flush_cpu_state() arch/arm64: fpsimd: Introduce fpsimd_save_and_flush_cpu_state() and use it arm64/fpsimd: Don't disable softirq when touching FPSIMD/SVE state arch/arm64/include/asm/fpsimd.h | 6 +- arch/arm64/include/asm/simd.h | 10 +-- arch/arm64/kernel/fpsimd.c | 135 +++- arch/arm64/kvm/fpsimd.c | 4 +- 4 files changed, 100 insertions(+), 55 deletions(-) -- 2.11.0
[PATCH v3 3/3] arm64/fpsimd: Don't disable softirq when touching FPSIMD/SVE state
When the kernel is compiled with CONFIG_KERNEL_MODE_NEON, some part of
the kernel may be able to use FPSIMD/SVE. This is for instance the case
for crypto code.
Any use of FPSIMD/SVE in the kernel are clearly marked by using the
function kernel_neon_{begin, end}. Furthermore, this can only be used
when may_use_simd() returns true.
The current implementation of may_use_simd() allows softirq to use
FPSIMD/SVE unless it is currently in use (i.e kernel_neon_busy is true).
When in use, softirqs usually fall back to a software method.
At the moment, as a softirq may use FPSIMD/SVE, softirqs are disabled
when touching the FPSIMD/SVE context. This has the drawback to disable
all softirqs even if they are not using FPSIMD/SVE.
Since a softirq is supposed to check may_use_simd() anyway before
attempting to use FPSIMD/SVE, there is limited reason to keep softirq
disabled when touching the FPSIMD/SVE context. Instead, we can simply
disable preemption and mark the FPSIMD/SVE context as in use by setting
CPU's kernel_neon_busy flag.
Two new helpers {get, put}_cpu_fpsimd_context is introduced to mark the
area using FPSIMD/SVE context and uses them in replacement of
local_bh_{disable, enable}. The functions kernel_neon_{begin, end} are
also re-implemented to use the new helpers.
For use in fpsimd_thread_switch(), which is a critical path where
preemption is already disabled, doule-underscored versions of the
helpers are provided to avoid disabling preemption again.
The change has been benchmarked on Linux 5.1-rc4 with defconfig.
On Juno2:
* hackbench 100 process 1000 (10 times)
* .7% quicker
On ThunderX 2:
* hackbench 1000 process 1000 (20 times)
* 3.4% quicker
Signed-off-by: Julien Grall
---
Changes in v3:
- Fix typoes in the commit message
- Rework a bit the commit message
- Use imperative mood
- Rename kernel_neon_busy to fpsimd_context_busy
- Remove debug code
- Update comments
- Don't require preemption when calling
fpsimd_save_and_flush_cpu_state()
Changes in v2:
- Remove spurious call to kernel_neon_enable in kernel_neon_begin.
- Rename kernel_neon_{enable, disable} to {get, put}_cpu_fpsimd_context
- Introduce a double-underscore version of the helpers for case
where preemption is already disabled
- Introduce have_cpu_fpsimd_context() and use it in WARN_ON(...)
- Surround more places in the code with the new helpers
- Rework the comments
- Update the commit message with the benchmark result
---
arch/arm64/include/asm/simd.h | 10 ++--
arch/arm64/kernel/fpsimd.c| 126 --
2 files changed, 88 insertions(+), 48 deletions(-)
diff --git a/arch/arm64/include/asm/simd.h b/arch/arm64/include/asm/simd.h
index 6495cc51246f..a6307e43b8c2 100644
--- a/arch/arm64/include/asm/simd.h
+++ b/arch/arm64/include/asm/simd.h
@@ -15,9 +15,9 @@
#include
#include
-#ifdef CONFIG_KERNEL_MODE_NEON
+DECLARE_PER_CPU(bool, fpsimd_context_busy);
-DECLARE_PER_CPU(bool, kernel_neon_busy);
+#ifdef CONFIG_KERNEL_MODE_NEON
/*
* may_use_simd - whether it is allowable at this time to issue SIMD
@@ -29,15 +29,15 @@ DECLARE_PER_CPU(bool, kernel_neon_busy);
static __must_check inline bool may_use_simd(void)
{
/*
-* kernel_neon_busy is only set while preemption is disabled,
+* fpsimd_context_busy is only set while preemption is disabled,
* and is clear whenever preemption is enabled. Since
-* this_cpu_read() is atomic w.r.t. preemption, kernel_neon_busy
+* this_cpu_read() is atomic w.r.t. preemption, fpsimd_context_busy
* cannot change under our feet -- if it's set we cannot be
* migrated, and if it's clear we cannot be migrated to a CPU
* where it is set.
*/
return !in_irq() && !irqs_disabled() && !in_nmi() &&
- !this_cpu_read(kernel_neon_busy);
+ !this_cpu_read(fpsimd_context_busy);
}
#else /* ! CONFIG_KERNEL_MODE_NEON */
diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
index 5313aa257be6..6168d06bbd20 100644
--- a/arch/arm64/kernel/fpsimd.c
+++ b/arch/arm64/kernel/fpsimd.c
@@ -92,7 +92,8 @@
* To prevent this from racing with the manipulation of the task's FPSIMD state
* from task context and thereby corrupting the state, it is necessary to
* protect any manipulation of a task's fpsimd_state or TIF_FOREIGN_FPSTATE
- * flag with local_bh_disable() unless softirqs are already masked.
+ * flag with {, __}get_cpu_fpsimd_context(). This will still allow softirqs to
+ * run but prevent them to use FPSIMD.
*
* For a certain task, the sequence may look something like this:
* - the task gets scheduled in; if both the task's fpsimd_cpu field
@@ -155,6 +156,56 @@ extern void __percpu *efi_sve_state;
#endif /* ! CONFIG_ARM64_SVE */
+DEFINE_PER_CPU(bool, fpsimd_context_busy);
Re: [PATCH v5 3/3] power_supply: Add missing documentation for CHARGE_CONTROL_* properties
On 18/4/19 18:43, Nick Crews wrote: > The existing POWER_SUPPLY_PROP_CHARGE_CONTROL_LIMIT and > POWER_SUPPLY_PROP_CHARGE_CONTROL_LIMIT_MAX properties > don't have documentation. I add that documentation here. > > v5 changes: > - Split this commit out from the previous two commits. > > Signed-off-by: Nick Crews Reviewed-by: Enric Balletbo i Serra > --- > Documentation/ABI/testing/sysfs-class-power | 19 +++ > 1 file changed, 19 insertions(+) > > diff --git a/Documentation/ABI/testing/sysfs-class-power > b/Documentation/ABI/testing/sysfs-class-power > index a5b144f61de8..b77e30b9014e 100644 > --- a/Documentation/ABI/testing/sysfs-class-power > +++ b/Documentation/ABI/testing/sysfs-class-power > @@ -114,6 +114,25 @@ Description: > Access: Read > Valid values: Represented in microamps > > +What: > /sys/class/power_supply//charge_control_limit > +Date:Oct 2012 > +Contact: linux...@vger.kernel.org > +Description: > + Maximum allowable charging current. Used for charge rate > + throttling for thermal cooling or improving battery health. > + > + Access: Read, Write > + Valid values: Represented in microamps > + > +What: > /sys/class/power_supply//charge_control_limit_max > +Date:Oct 2012 > +Contact: linux...@vger.kernel.org > +Description: > + Maximum legal value for the charge_control_limit property. > + > + Access: Read > + Valid values: Represented in microamps > + > What: > /sys/class/power_supply//charge_control_start_threshold > Date:April 2019 > Contact: linux...@vger.kernel.org >
Re: [PATCH v5 2/3] power_supply: Add CHARGE_CONTROL_{START_THRESHOLD,END_THRESHOLD} properties
On 18/4/19 18:43, Nick Crews wrote:
> Add POWER_SUPPLY_PROP_CHARGE_CONTROL_START_THRESHOLD
> and POWER_SUPPLY_PROP_CHARGE_CONTROL_END_THRESHOLD properties, to expand
> the existing CHARGE_CONTROL_* properties. I am adding them in order
> to support a new Chrome OS device, but these properties should be
> general enough that they can be used on other devices.
>
> When the charge_type is "Custom", the charge controller uses the
> POWER_SUPPLY_PROP_CHARGE_CONTROL_* properties as configuration for some
> other algorithm. For example, in the use case that I am supporting,
> this means the battery begins charging when the percentage
> level drops below POWER_SUPPLY_PROP_CHARGE_CONTROL_START_THRESHOLD and
> charging ceases when the percentage level goes above
> POWER_SUPPLY_PROP_CHARGE_CONTROL_END_THRESHOLD.
>
> v5 changes:
> - Add the other missing CHARGE_CONTROL_* properties documentation in
> a separate commit
> - Split up adding the charge types and adding the
> POWER_SUPPLY_PROP_CHARGE_CONTROL_START_THRESHOLD and
> POWER_SUPPLY_PROP_CHARGE_CONTROL_END_THRESHOLD properties into
> two different commits.
> v4 changes:
> - Add documentation for the new properties, and add documentation for
> the the previously missing charge_control_limit and
> charge_control_limit_max properties.
>
> Signed-off-by: Nick Crews
Reviewed-by: Enric Balletbo i Serra
> ---
> Documentation/ABI/testing/sysfs-class-power | 20
> drivers/power/supply/power_supply_sysfs.c | 2 ++
> include/linux/power_supply.h| 2 ++
> 3 files changed, 24 insertions(+)
>
> diff --git a/Documentation/ABI/testing/sysfs-class-power
> b/Documentation/ABI/testing/sysfs-class-power
> index 544c4e0ef8b6..a5b144f61de8 100644
> --- a/Documentation/ABI/testing/sysfs-class-power
> +++ b/Documentation/ABI/testing/sysfs-class-power
> @@ -114,6 +114,26 @@ Description:
> Access: Read
> Valid values: Represented in microamps
>
> +What:
> /sys/class/power_supply//charge_control_start_threshold
> +Date:April 2019
> +Contact: linux...@vger.kernel.org
> +Description:
> + Represents a battery percentage level, below which charging will
> + begin.
> +
> + Access: Read, Write
> + Valid values: 0 - 100 (percent)
> +
> +What:
> /sys/class/power_supply//charge_control_end_threshold
> +Date:April 2019
> +Contact: linux...@vger.kernel.org
> +Description:
> + Represents a battery percentage level, above which charging will
> + stop.
> +
> + Access: Read, Write
> + Valid values: 0 - 100 (percent)
> +
> What:/sys/class/power_supply//charge_type
> Date:July 2009
> Contact: linux...@vger.kernel.org
> diff --git a/drivers/power/supply/power_supply_sysfs.c
> b/drivers/power/supply/power_supply_sysfs.c
> index 64dff5cfecc3..6104a3f03d46 100644
> --- a/drivers/power/supply/power_supply_sysfs.c
> +++ b/drivers/power/supply/power_supply_sysfs.c
> @@ -274,6 +274,8 @@ static struct device_attribute power_supply_attrs[] = {
> POWER_SUPPLY_ATTR(constant_charge_voltage_max),
> POWER_SUPPLY_ATTR(charge_control_limit),
> POWER_SUPPLY_ATTR(charge_control_limit_max),
> + POWER_SUPPLY_ATTR(charge_control_start_threshold),
> + POWER_SUPPLY_ATTR(charge_control_end_threshold),
> POWER_SUPPLY_ATTR(input_current_limit),
> POWER_SUPPLY_ATTR(energy_full_design),
> POWER_SUPPLY_ATTR(energy_empty_design),
> diff --git a/include/linux/power_supply.h b/include/linux/power_supply.h
> index e86e05d8134d..d59205170232 100644
> --- a/include/linux/power_supply.h
> +++ b/include/linux/power_supply.h
> @@ -125,6 +125,8 @@ enum power_supply_property {
> POWER_SUPPLY_PROP_CONSTANT_CHARGE_VOLTAGE_MAX,
> POWER_SUPPLY_PROP_CHARGE_CONTROL_LIMIT,
> POWER_SUPPLY_PROP_CHARGE_CONTROL_LIMIT_MAX,
> + POWER_SUPPLY_PROP_CHARGE_CONTROL_START_THRESHOLD, /* in percents! */
> + POWER_SUPPLY_PROP_CHARGE_CONTROL_END_THRESHOLD, /* in percents! */
> POWER_SUPPLY_PROP_INPUT_CURRENT_LIMIT,
> POWER_SUPPLY_PROP_ENERGY_FULL_DESIGN,
> POWER_SUPPLY_PROP_ENERGY_EMPTY_DESIGN,
>
Re: [PATCH v5 1/3] power_supply: Add Standard, Adaptive, and Custom charge types
On 18/4/19 18:43, Nick Crews wrote:
> Add "Standard", "Adaptive", and "Custom" modes to the charge_type
> property, to expand the existing "Trickle" and "Fast" modes.
> I am adding them in order to support a new Chrome OS device,
> but these properties should be general enough that they can be
> used on other devices.
>
> The meaning of "Standard" is obvious, but "Adaptive" and "Custom" are
> more tricky: "Adaptive" means that the charge controller uses some
> custom algorithm to change the charge type automatically, with no
> configuration needed. "Custom" means that the charge controller uses the
> POWER_SUPPLY_PROP_CHARGE_CONTROL_* properties as configuration for some
> other algorithm.
>
> v5 changes:
> - Split up adding the charge types and adding the
> POWER_SUPPLY_PROP_CHARGE_CONTROL_START_THRESHOLD and
> POWER_SUPPLY_PROP_CHARGE_CONTROL_END_THRESHOLD properties into
> two different commits.
> v4 changes:
> - Add documentation for the new properties, and add documentation for
> the the previously missing charge_control_limit and
> charge_control_limit_max properties.
>
> Signed-off-by: Nick Crews
Reviewed-by: Enric Balletbo i Serra
> ---
> Documentation/ABI/testing/sysfs-class-power | 12 +---
> drivers/power/supply/power_supply_sysfs.c | 2 +-
> include/linux/power_supply.h| 8 ++--
> 3 files changed, 16 insertions(+), 6 deletions(-)
>
> diff --git a/Documentation/ABI/testing/sysfs-class-power
> b/Documentation/ABI/testing/sysfs-class-power
> index 5e23e22dce1b..544c4e0ef8b6 100644
> --- a/Documentation/ABI/testing/sysfs-class-power
> +++ b/Documentation/ABI/testing/sysfs-class-power
> @@ -119,10 +119,16 @@ Date: July 2009
> Contact: linux...@vger.kernel.org
> Description:
> Represents the type of charging currently being applied to the
> - battery.
> + battery. "Trickle", "Fast", and "Standard" all mean different
> + charging speeds. "Adaptive" means that the charger uses some
> + algorithm to adjust the charge rate dynamically, without
> + any user configuration required. "Custom" means that the charger
> + uses the charge_control_* properties as configuration for some
> + different algorithm.
>
> - Access: Read
> - Valid values: "Unknown", "N/A", "Trickle", "Fast"
> + Access: Read, Write
> + Valid values: "Unknown", "N/A", "Trickle", "Fast", "Standard",
> + "Adaptive", "Custom"
>
> What:
> /sys/class/power_supply//charge_term_current
> Date:July 2014
> diff --git a/drivers/power/supply/power_supply_sysfs.c
> b/drivers/power/supply/power_supply_sysfs.c
> index dce24f596160..64dff5cfecc3 100644
> --- a/drivers/power/supply/power_supply_sysfs.c
> +++ b/drivers/power/supply/power_supply_sysfs.c
> @@ -56,7 +56,7 @@ static const char * const power_supply_status_text[] = {
> };
>
> static const char * const power_supply_charge_type_text[] = {
> - "Unknown", "N/A", "Trickle", "Fast"
> + "Unknown", "N/A", "Trickle", "Fast", "Standard", "Adaptive", "Custom"
> };
>
> static const char * const power_supply_health_text[] = {
> diff --git a/include/linux/power_supply.h b/include/linux/power_supply.h
> index 2f9c201a54d1..e86e05d8134d 100644
> --- a/include/linux/power_supply.h
> +++ b/include/linux/power_supply.h
> @@ -40,11 +40,15 @@ enum {
> POWER_SUPPLY_STATUS_FULL,
> };
>
> +/* What algorithm is the charger using? */
> enum {
> POWER_SUPPLY_CHARGE_TYPE_UNKNOWN = 0,
> POWER_SUPPLY_CHARGE_TYPE_NONE,
> - POWER_SUPPLY_CHARGE_TYPE_TRICKLE,
> - POWER_SUPPLY_CHARGE_TYPE_FAST,
> + POWER_SUPPLY_CHARGE_TYPE_TRICKLE, /* slow speed */
> + POWER_SUPPLY_CHARGE_TYPE_FAST, /* fast speed */
> + POWER_SUPPLY_CHARGE_TYPE_STANDARD, /* normal speed */
> + POWER_SUPPLY_CHARGE_TYPE_ADAPTIVE, /* dynamically adjusted speed */
> + POWER_SUPPLY_CHARGE_TYPE_CUSTOM,/* use CHARGE_CONTROL_* props */
> };
>
> enum {
>
Re: [RESEND PATCH 0/7] Introduce bus domains controller framework
On Tue, Apr 23, 2019 at 01:33:19PM +, Benjamin GAIGNARD wrote: > > On 4/23/19 3:21 PM, Sudeep Holla wrote: > > On Mon, Mar 18, 2019 at 12:05:54PM +0100, Benjamin Gaignard wrote: > >> Le lun. 18 mars 2019 à 11:43, Sudeep Holla a écrit : > >>> On Mon, Mar 18, 2019 at 11:05:58AM +0100, Benjamin Gaignard wrote: > Bus domains controllers allow to divided system on chip into multiple > domains > that can be used to select by who hardware blocks could be accessed. > A domain could be a cluster of CPUs (or coprocessors), a range of > addresses or > a group of hardware blocks. > > Framework architecture is inspirated by pinctrl framework: > - a default configuration could be applied before bind the driver > - configurations could be apllied dynamically by drivers > - device node provides the bus domains configurations > > An example of bus domains controller is STM32 ETZPC hardware block > which got 3 domains: > - secure: hardware blocks are only accessible by software running on > trust > zone. > - non-secure: hardware blocks are accessible by non-secure software (i.e. > linux kernel). > - coprocessor: hardware blocks are only accessible by the corpocessor. > Up to 94 hardware blocks of the soc could be managed by ETZPC and > assigned to one of the three domains. > > >>> You fail to explain why do we need this in non-secure Linux ? > >>> You need to have solid reasons as why this can't be done in secure > >>> firmware. And yes I mean even on arm32. On platforms with such hardware > >>> capabilities you will need some secure firmware to be running and these > >>> things can be done there. I don't want this enabled for ARM64 at all, > >>> firmware *has to deal* with this. > >> We use ETZPC to define if hardware blocks can be used by Cortex A7 or > >> Cortex > >> M4 (both non-secure) on STM32MP1 SoC, this new framework allow to change > >> hardware block split at runtime. This could be done even on non-secure > >> world > >> because their is nothing critical to change hardware blocks users. > > OK, that's interesting, assuming Cortex M4 execution as non-secure. I would > > expect otherwise. Even if it's configurable, I would see that happen in > > secure entity via OPTEE or something similar from non-secure side. > Your assumption is correct Cortex M4 execution is non-secure. Sorry if I was not clear. I told Cortex M4 non-secure execution is interesting as I expected it to be secure. > > > > Do you have any documents that I can refer to get the overall security > > design for such platforms ? > > SoC datasheet is here: > > https://www.st.com/resource/en/datasheet/stm32mp157a.pdf > > with just few words about ETZPC: > > 3.14 TrustZone protection controller (ETZPC) > ETZPC is used to configure TrustZone security of bus masters and slaves with > programmable-security attributes (securable resources) such as: > • On-chip SYSRAM with programmable secure region size > • AHB and APB peripherals to be made secure > Notice that by default, SYSRAM and peripheral are set to secure access > only, so, not accessible by non-secure masters such as Cortex-M4 or DMA1/DMA2. > ETZPC can also allocate peripherals and SRAM to be accessible only by > the Cortex-M4 and/or DMA1/DMA2. This ensures the safe execution of the > Cortex-M4 firmware, protected from other masters (e.g. Cortex-A7) unwanted > accesses. > The above statement makes me wonder if Cortex-M4 firmware is really non-secure, if so why does it need such an isolation from other masters like Cortex-A7. For me Cortex-M4 is secure and Cortex-A7 can execute in non-secure hence Cortex-M4 needs to be isolated from Cortex-A7 as mentioned in the above excerpts from the datasheet. -- Regards, Sudeep
Re: [PATCH v2 7/8] s390: vfio-ap: handle bind and unbind of AP queue device
On Sat, 20 Apr 2019 17:49:39 -0400
Tony Krowiak wrote:
> +void vfio_ap_mdev_probe_queue(unsigned long apid, unsigned long apqi)
> +{
> + struct ap_matrix_mdev *matrix_mdev;
> +
> + matrix_mdev = vfio_ap_mdev_find_matrix_mdev(apid, apqi);
> +
> + /*
> + * If the queue is assigned to the mdev device and the mdev device
> + * is in use by a guest
> + */
> + if (matrix_mdev && matrix_mdev->kvm) {
> + /* Plug the adapter into the guest */
> + set_bit_inv(apid, matrix_mdev->shadow_crycb->apm);
> +
> + /* Make sure the queue is also plugged in to the guest */
> + if (!test_bit_inv(apqi, matrix_mdev->shadow_crycb->aqm))
> + set_bit_inv(apqi, matrix_mdev->shadow_crycb->aqm);
> +
> + vfio_ap_mdev_update_crycb(matrix_mdev);
With this you effectively grant access to all the assigned domains on
the AP identified by the apid, not only to the domain identified by
apqi! But some of these queues may still not be bound to the vfio_ap
driver.
IMHO you should only set the apid-th bit in apm if all queues (apid, q)
such that q-th bit is set in aqm are bound to the vfio_ap driver.
BTW a 'shadow' (or effective) apm would perfectly suffice. I don't think
you fiddle with shadow_crycb->a[qd]m, and if you do, I don't think that's
a good idea.
Regards,
Halil
> + }
> +}
Re: next-20190408..0418: Suspend/resume problems on Thinkpad X60
On 4/23/19 4:22 AM, Pavel Machek wrote: > Hi! > >>> It boots ok (unlike mainline -- I'm debugging that), and I can suspend >>> and resume... but then cursor in X is moving and I can talk to >>> applications cached in memory, but any access to disk hangs. >> >> Mainline problem was identified. >> >> But resume is still broken. I took advantage of fact that I can still >> do cached commands, and got complete dmesg. I'm attaching it. > > Still broken in 0418. Ideas would be welcome at this point. Bisect it? -- Jens Axboe
[PATCH v1 15/15] arm64: defconfig: Enable SDMA on i.mx8mq/8mm
Enable SDMA support on i.mx8mq/8mm chips, including enabling CONFIG_FW_LOADER_USER_HELPER/CONFIG_FW_LOADER_USER_HELPER_FALLBACK for firmware loaded by udev. Signed-off-by: Robin Gong --- arch/arm64/configs/defconfig | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index 17daa97..7081817 100644 --- a/arch/arm64/configs/defconfig +++ b/arch/arm64/configs/defconfig @@ -203,6 +203,8 @@ CONFIG_NET_9P_VIRTIO=y CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug" CONFIG_DEVTMPFS=y CONFIG_DEVTMPFS_MOUNT=y +CONFIG_FW_LOADER_USER_HELPER=y +CONFIG_FW_LOADER_USER_HELPER_FALLBACK=y CONFIG_DMA_CMA=y CONFIG_CMA_SIZE_MBYTES=32 CONFIG_HISILICON_LPC=y @@ -635,6 +637,7 @@ CONFIG_RTC_DRV_IMX_SC=m CONFIG_RTC_DRV_XGENE=y CONFIG_DMADEVICES=y CONFIG_DMA_BCM2835=m +CONFIG_IMX_SDMA=y CONFIG_K3_DMA=y CONFIG_MV_XOR_V2=y CONFIG_PL330_DMA=y -- 2.7.4
[PATCH v1 13/15] ARM: dts: imx6ul: add dma support on ecspi
Add dma support on ecspi. Signed-off-by: Robin Gong --- arch/arm/boot/dts/imx6ul.dtsi | 8 1 file changed, 8 insertions(+) diff --git a/arch/arm/boot/dts/imx6ul.dtsi b/arch/arm/boot/dts/imx6ul.dtsi index bbf010c..880b9ee 100644 --- a/arch/arm/boot/dts/imx6ul.dtsi +++ b/arch/arm/boot/dts/imx6ul.dtsi @@ -226,6 +226,8 @@ clocks = < IMX6UL_CLK_ECSPI1>, < IMX6UL_CLK_ECSPI1>; clock-names = "ipg", "per"; + dmas = < 3 7 1>, < 4 7 2>; + dma-names = "rx", "tx"; status = "disabled"; }; @@ -238,6 +240,8 @@ clocks = < IMX6UL_CLK_ECSPI2>, < IMX6UL_CLK_ECSPI2>; clock-names = "ipg", "per"; + dmas = < 5 7 1>, < 6 7 2>; + dma-names = "rx", "tx"; status = "disabled"; }; @@ -250,6 +254,8 @@ clocks = < IMX6UL_CLK_ECSPI3>, < IMX6UL_CLK_ECSPI3>; clock-names = "ipg", "per"; + dmas = < 7 7 1>, < 8 7 2>; + dma-names = "rx", "tx"; status = "disabled"; }; @@ -262,6 +268,8 @@ clocks = < IMX6UL_CLK_ECSPI4>, < IMX6UL_CLK_ECSPI4>; clock-names = "ipg", "per"; + dmas = < 9 7 1>, < 10 7 2>; + dma-names = "rx", "tx"; status = "disabled"; }; -- 2.7.4
[PATCH v1 14/15] ARM: dts: imx6sll: correct ecspi/sdma compatible
Correct ecspi/sdma compatible since ecspi errata ERR009165
not fixed on i.mx6sll chip.
Signed-off-by: Robin Gong
---
arch/arm/boot/dts/imx6sll.dtsi | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm/boot/dts/imx6sll.dtsi b/arch/arm/boot/dts/imx6sll.dtsi
index 1b4899f..03f2103 100644
--- a/arch/arm/boot/dts/imx6sll.dtsi
+++ b/arch/arm/boot/dts/imx6sll.dtsi
@@ -183,7 +183,7 @@
};
ecspi1: spi@2008000 {
- compatible = "fsl,imx6ul-ecspi",
"fsl,imx51-ecspi";
+ compatible ="fsl,imx51-ecspi";
reg = <0x02008000 0x4000>;
interrupts = ;
dmas = < 3 7 1>, < 4 7 2>;
@@ -195,7 +195,7 @@
};
ecspi2: spi@200c000 {
- compatible = "fsl,imx6ul-ecspi",
"fsl,imx51-ecspi";
+ compatible = "fsl,imx51-ecspi";
reg = <0x0200c000 0x4000>;
interrupts = ;
dmas = < 5 7 1>, < 6 7 2>;
@@ -207,7 +207,7 @@
};
ecspi3: spi@201 {
- compatible = "fsl,imx6ul-ecspi",
"fsl,imx51-ecspi";
+ compatible = "fsl,imx51-ecspi";
reg = <0x0201 0x4000>;
interrupts = ;
dmas = < 7 7 1>, < 8 7 2>;
@@ -219,7 +219,7 @@
};
ecspi4: spi@2014000 {
- compatible = "fsl,imx6ul-ecspi",
"fsl,imx51-ecspi";
+ compatible = "fsl,imx51-ecspi";
reg = <0x02014000 0x4000>;
interrupts = ;
dmas = < 9 7 1>, < 10 7 2>;
@@ -619,7 +619,7 @@
};
sdma: dma-controller@20ec000 {
- compatible = "fsl,imx6sll-sdma",
"fsl,imx35-sdma";
+ compatible = "fsl,imx6q-sdma", "fsl,imx35-sdma";
reg = <0x020ec000 0x4000>;
interrupts = ;
clocks = < IMX6SLL_CLK_IPG>,
--
2.7.4
