[RFC 7/9] platform/x86: huawei-wmi: Add fn-lock support
Huawei Matebook laptops uses Fn key and toggle to access F1-F12 keys.
Along with that, there is this feature called fn-lock that inverts the
behavior of this Fn key.
Implement the basic functionality of this feature to be used later by
sysfs interface support introduced in this series.
Signed-off-by: Ayman Bagabas
---
drivers/platform/x86/huawei-wmi.c | 30 ++
1 file changed, 30 insertions(+)
diff --git a/drivers/platform/x86/huawei-wmi.c
b/drivers/platform/x86/huawei-wmi.c
index da3986cd0428..4159e10bda26 100644
--- a/drivers/platform/x86/huawei-wmi.c
+++ b/drivers/platform/x86/huawei-wmi.c
@@ -351,6 +351,36 @@ static int huawei_wmi_battery_set(struct device *dev, int
low, int high)
return err;
}
+/* Fn lock */
+
+static int huawei_wmi_fn_lock_get(struct device *dev, int *on)
+{
+ u8 ret[0x100] = { 0 };
+ int err, i;
+
+ err = huawei_wmi_cmd(dev, FN_LOCK_GET, ret, 0x100);
+ if (err)
+ return err;
+
+ /* Find the first non-zero value. Return status is ignored. */
+ i = 1;
+ do {
+ *on = ret[i] - 1; // -1 undefined, 0 off, 1 on.
+ } while (i < 0x100 && !ret[i++]);
+
+ return 0;
+}
+
+static int huawei_wmi_fn_lock_set(struct device *dev, int on)
+{
+ u8 arg[8];
+
+ *(u64 *)arg = FN_LOCK_SET;
+ arg[2] = on + 1; // 0 undefined, 1 off, 2 on.
+
+ return huawei_wmi_cmd(dev, *(u64 *)arg, NULL, NULL);
+}
+
/* Input */
static void huawei_wmi_process_key(struct input_dev *idev, int code)
--
2.20.1
[RFC 8/9] platform/x86: huawei-wmi: Add sysfs interface support
Add sysfs interface to enable the use of battery charging thresholds and
fn-lock support introduced in this series.
Signed-off-by: Ayman Bagabas
---
drivers/platform/x86/huawei-wmi.c | 82 +++
1 file changed, 82 insertions(+)
diff --git a/drivers/platform/x86/huawei-wmi.c
b/drivers/platform/x86/huawei-wmi.c
index 4159e10bda26..f7041fb71026 100644
--- a/drivers/platform/x86/huawei-wmi.c
+++ b/drivers/platform/x86/huawei-wmi.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
/*
@@ -381,6 +382,80 @@ static int huawei_wmi_fn_lock_set(struct device *dev, int
on)
return huawei_wmi_cmd(dev, *(u64 *)arg, NULL, NULL);
}
+/* sysfs */
+
+static ssize_t charge_thresholds_show(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+ int err, low, high;
+
+ err = huawei_wmi_battery_get(dev, , );
+ if (err)
+ return err;
+
+ return sprintf(buf, "%d %d\n", low, high);
+}
+
+static ssize_t charge_thresholds_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t size)
+{
+ int low, high, err;
+
+ if (sscanf(buf, "%d %d", , ) != 2 ||
+ low < 0 || high > 100 ||
+ low > high)
+ return -EINVAL;
+
+ err = huawei_wmi_battery_set(dev, low, high);
+ if (err)
+ return err;
+
+ return size;
+}
+
+static ssize_t fn_lock_state_show(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+ int err, on;
+
+ err = huawei_wmi_fn_lock_get(dev, );
+ if (err)
+ return err;
+
+ return sprintf(buf, "%d\n", on);
+}
+
+static ssize_t fn_lock_state_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t size)
+{
+ int on, err;
+
+ if (kstrtoint(buf, 10, ) ||
+ on < 0 || on > 1)
+ return -EINVAL;
+
+ err = huawei_wmi_fn_lock_set(dev, on);
+ if (err)
+ return err;
+
+ return size;
+}
+
+static DEVICE_ATTR_RW(charge_thresholds);
+static DEVICE_ATTR_RW(fn_lock_state);
+
+static struct attribute *huawei_wmi_attrs[] = {
+ _attr_charge_thresholds.attr,
+ _attr_fn_lock_state.attr,
+ NULL
+};
+
+ATTRIBUTE_GROUPS(huawei_wmi);
+
/* Input */
static void huawei_wmi_process_key(struct input_dev *idev, int code)
@@ -508,6 +583,12 @@ static int huawei_wmi_probe(struct platform_device *pdev)
dev_err(>dev, "Failed to setup leds\n");
return err;
}
+
+ err = sysfs_create_groups(>dev.kobj, huawei_wmi_groups);
+ if (err) {
+ dev_err(>dev, "Failed to create sysfs
interface\n");
+ return err;
+ }
}
return 0;
@@ -522,6 +603,7 @@ static int huawei_wmi_remove(struct platform_device *pdev)
wmi_remove_notify_handler(HWMI_EVENT_GUID);
if (wmi_has_guid(HWMI_METHOD_GUID)) {
+ sysfs_remove_groups(>dev.kobj, huawei_wmi_groups);
}
return 0;
--
2.20.1
[RFC 9/9] platform/x86: huawei-wmi: Add debugfs support
Add a debugfs interface that can be used to call the WMI management
interface function.
The WMI interface takes a 64 bit integer and returns 256-260 bytes
buffer. This debugfs interface creates two files, one stores a 64 bit
int and the other calls the WMI interface and dumps out the returned
buffer.
Signed-off-by: Ayman Bagabas
---
drivers/platform/x86/huawei-wmi.c | 98 +++
1 file changed, 98 insertions(+)
diff --git a/drivers/platform/x86/huawei-wmi.c
b/drivers/platform/x86/huawei-wmi.c
index f7041fb71026..bdca8bd76c8c 100644
--- a/drivers/platform/x86/huawei-wmi.c
+++ b/drivers/platform/x86/huawei-wmi.c
@@ -6,6 +6,7 @@
*/
#include
+#include
#include
#include
#include
@@ -45,7 +46,13 @@ struct quirk_entry {
static struct quirk_entry *quirks;
+struct huawei_wmi_debug {
+ struct dentry *root;
+ u64 arg;
+};
+
struct huawei_wmi_priv {
+ struct huawei_wmi_debug debug;
struct input_dev *idev[2];
struct led_classdev cdev;
struct mutex battery_lock;
@@ -456,6 +463,94 @@ static struct attribute *huawei_wmi_attrs[] = {
ATTRIBUTE_GROUPS(huawei_wmi);
+/* debugfs */
+
+static void huawei_wmi_debugfs_call_dump(struct seq_file *m, void *data,
+ union acpi_object *obj)
+{
+ struct huawei_wmi_priv *priv = m->private;
+ int i;
+
+ switch (obj->type) {
+ case ACPI_TYPE_INTEGER:
+ seq_printf(m, "0x%llx", obj->integer.value);
+ break;
+ case ACPI_TYPE_STRING:
+ seq_printf(m, "\"%*s\"", obj->string.length,
obj->string.pointer);
+ break;
+ case ACPI_TYPE_BUFFER:
+ seq_puts(m, "{");
+ for (i = 0; i < obj->buffer.length; i++) {
+ seq_printf(m, "0x%02x", obj->buffer.pointer[i]);
+ if (i < obj->buffer.length - 1)
+ seq_puts(m, ",");
+ }
+ seq_puts(m, "}");
+ break;
+ case ACPI_TYPE_PACKAGE:
+ seq_puts(m, "[");
+ for (i = 0; i < obj->package.count; i++) {
+ huawei_wmi_debugfs_call_dump(m, priv,
>package.elements[i]);
+ if (i < obj->package.count - 1)
+ seq_puts(m, ",");
+ }
+ seq_puts(m, "]");
+ break;
+ default:
+ dev_err(>pdev->dev, "Unexpected obj type, got %d\n",
obj->type);
+ return;
+ }
+}
+
+static int huawei_wmi_debugfs_call_show(struct seq_file *m, void *data)
+{
+ struct huawei_wmi_priv *priv = m->private;
+ struct acpi_buffer out = { ACPI_ALLOCATE_BUFFER, NULL };
+ struct acpi_buffer in;
+ union acpi_object *obj;
+ int err;
+
+ in.length = sizeof(u64);
+ in.pointer = >debug.arg;
+
+ err = huawei_wmi_call(>pdev->dev, , );
+ if (err)
+ return err;
+
+ obj = out.pointer;
+ if (!obj) {
+ err = -EIO;
+ goto fail_debugfs_call;
+ }
+
+ huawei_wmi_debugfs_call_dump(m, priv, obj);
+
+fail_debugfs_call:
+ kfree(out.pointer);
+ return err;
+}
+
+DEFINE_SHOW_ATTRIBUTE(huawei_wmi_debugfs_call);
+
+static void huawei_wmi_debugfs_exit(struct device *dev)
+{
+ struct huawei_wmi_priv *priv = dev_get_drvdata(dev);
+
+ debugfs_remove_recursive(priv->debug.root);
+}
+
+static void huawei_wmi_debugfs_setup(struct device *dev)
+{
+ struct huawei_wmi_priv *priv = dev_get_drvdata(dev);
+
+ priv->debug.root = debugfs_create_dir("huawei-wmi", NULL);
+
+ debugfs_create_x64("arg", 0644, priv->debug.root,
+ >debug.arg);
+ debugfs_create_file("call", 0400,
+ priv->debug.root, priv, _wmi_debugfs_call_fops);
+}
+
/* Input */
static void huawei_wmi_process_key(struct input_dev *idev, int code)
@@ -589,6 +684,8 @@ static int huawei_wmi_probe(struct platform_device *pdev)
dev_err(>dev, "Failed to create sysfs
interface\n");
return err;
}
+
+ huawei_wmi_debugfs_setup(>dev);
}
return 0;
@@ -603,6 +700,7 @@ static int huawei_wmi_remove(struct platform_device *pdev)
wmi_remove_notify_handler(HWMI_EVENT_GUID);
if (wmi_has_guid(HWMI_METHOD_GUID)) {
+ huawei_wmi_debugfs_exit(>dev);
sysfs_remove_groups(>dev.kobj, huawei_wmi_groups);
}
--
2.20.1
[RFC 6/9] platform/x86: huawei-wmi: Add battery charging thresholds
Implement battery charging thresholds functionality to be used with
sysfs interface support that is implemented in this series.
Setting battery charging thresholds can introduce a race condition where
two are trying to read/write values from/to EC memory. Even though a
mutex is used, this doesn't guarantee that these values will make it to
EC so a blocking sleep is necessary.
This sleep is enforced on the MACH-WX9 model since turning off battery
protection using (0,100) doesn't change the values in the EC memory,
instead it only disables the protection. So a workaround is to set the
thresholds to (0,0) before setting it to (0,100). This will ensure
that we update these values in EC memory and then turning it off with
(0,100). Thus, the msleep(1000).
Signed-off-by: Ayman Bagabas
---
In huawei_wmi_battery_get and later in huawei_wmi_fn_lock_get, 256 bytes
buffer is allocated dynamically on the stack. Now I know this is
discouraged, should it be changed to use kmalloc?
drivers/platform/x86/huawei-wmi.c | 54 +++
1 file changed, 54 insertions(+)
diff --git a/drivers/platform/x86/huawei-wmi.c
b/drivers/platform/x86/huawei-wmi.c
index 9013a05d2832..da3986cd0428 100644
--- a/drivers/platform/x86/huawei-wmi.c
+++ b/drivers/platform/x86/huawei-wmi.c
@@ -6,6 +6,7 @@
*/
#include
+#include
#include
#include
#include
@@ -46,6 +47,7 @@ static struct quirk_entry *quirks;
struct huawei_wmi_priv {
struct input_dev *idev[2];
struct led_classdev cdev;
+ struct mutex battery_lock;
struct mutex wmi_lock;
struct platform_device *pdev;
};
@@ -298,6 +300,57 @@ static int huawei_wmi_leds_setup(struct device *dev)
return devm_led_classdev_register(dev, >cdev);
}
+/* Battery protection */
+
+static int huawei_wmi_battery_get(struct device *dev, int *low, int *high)
+{
+ struct huawei_wmi_priv *priv = dev_get_drvdata(dev);
+ u8 ret[0x100];
+ int err, i;
+
+ mutex_lock(>battery_lock);
+ err = huawei_wmi_cmd(dev, BATTERY_THRESH_GET, ret, 0x100);
+ mutex_unlock(>battery_lock);
+ if (err)
+ return err;
+
+ /* Find the last two non-zero values. Return status is ignored. */
+ i = 0x100;
+ do {
+ *low = ret[i-1];
+ *high = ret[i];
+ } while (i > 2 && !ret[i--]);
+
+ return 0;
+}
+
+static int huawei_wmi_battery_set(struct device *dev, int low, int high)
+{
+ struct huawei_wmi_priv *priv = dev_get_drvdata(dev);
+ u8 arg[8];
+ int err;
+
+ *(u64 *)arg = BATTERY_THRESH_SET;
+ arg[2] = low;
+ arg[3] = high;
+
+ /* This is an edge case were some models turn battery protection
+* off without changing their thresholds values. We clear the
+* values before turning off protection. Sometimes we need a sleep
delay to
+* make sure these values make their way to EC memory.
+*/
+ if (low == 0 && high == 100)
+ huawei_wmi_battery_set(dev, 0, 0);
+
+ mutex_lock(>battery_lock);
+ err = huawei_wmi_cmd(dev, *(u64 *)arg, NULL, NULL);
+ if (quirks && quirks->battery_sleep)
+ msleep(1000);
+ mutex_unlock(>battery_lock);
+
+ return err;
+}
+
/* Input */
static void huawei_wmi_process_key(struct input_dev *idev, int code)
@@ -418,6 +471,7 @@ static int huawei_wmi_probe(struct platform_device *pdev)
if (wmi_has_guid(HWMI_METHOD_GUID)) {
mutex_init(>wmi_lock);
+ mutex_init(>battery_lock);
err = huawei_wmi_leds_setup(>dev);
if (err) {
--
2.20.1
[RFC 5/9] platform/x86: huawei-wmi: Control micmute led through wmi interface
Now that huawei WMI management interface is implemented, micmute LED can
be controlled easily through this interface. Exception is the Matebook X
(2017) which continue to uses ACPI EC method to control the LED. This
model can control the LED through the legacy WMI interface which is not
implemented ATM.
Signed-off-by: Ayman Bagabas
---
drivers/platform/x86/huawei-wmi.c | 86 ++-
1 file changed, 49 insertions(+), 37 deletions(-)
diff --git a/drivers/platform/x86/huawei-wmi.c
b/drivers/platform/x86/huawei-wmi.c
index 8f918138053a..9013a05d2832 100644
--- a/drivers/platform/x86/huawei-wmi.c
+++ b/drivers/platform/x86/huawei-wmi.c
@@ -46,8 +46,6 @@ static struct quirk_entry *quirks;
struct huawei_wmi_priv {
struct input_dev *idev[2];
struct led_classdev cdev;
- acpi_handle handle;
- char *acpi_method;
struct mutex wmi_lock;
struct platform_device *pdev;
};
@@ -238,49 +236,57 @@ static int huawei_wmi_cmd(struct device *dev, u64 arg, u8
*buf, size_t buflen)
static int huawei_wmi_micmute_led_set(struct led_classdev *led_cdev,
enum led_brightness brightness)
{
- struct huawei_wmi_priv *priv = dev_get_drvdata(led_cdev->dev->parent);
- acpi_status status;
- union acpi_object args[3];
- struct acpi_object_list arg_list = {
- .pointer = args,
- .count = ARRAY_SIZE(args),
- };
-
- args[0].type = args[1].type = args[2].type = ACPI_TYPE_INTEGER;
- args[1].integer.value = 0x04;
-
- if (strcmp(priv->acpi_method, "SPIN") == 0) {
- args[0].integer.value = 0;
- args[2].integer.value = brightness ? 1 : 0;
- } else if (strcmp(priv->acpi_method, "WPIN") == 0) {
- args[0].integer.value = 1;
- args[2].integer.value = brightness ? 0 : 1;
+ /* This is a workaround until the "legacy" interface is implemented. */
+ if (quirks && quirks->ec_micmute) {
+ char *acpi_method;
+ acpi_handle handle;
+ acpi_status status;
+ union acpi_object args[3];
+ struct acpi_object_list arg_list = {
+ .pointer = args,
+ .count = ARRAY_SIZE(args),
+ };
+
+ handle = ec_get_handle();
+ if (!handle) {
+ dev_err(led_cdev->dev->parent, "Failed to get EC
handle\n");
+ return -ENODEV;
+ }
+
+ args[0].type = args[1].type = args[2].type = ACPI_TYPE_INTEGER;
+ args[1].integer.value = 0x04;
+
+ if (acpi_has_method(handle, "SPIN")) {
+ acpi_method = "SPIN";
+ args[0].integer.value = 0;
+ args[2].integer.value = brightness ? 1 : 0;
+ } else if (acpi_has_method(handle, "WPIN")) {
+ acpi_method = "WPIN";
+ args[0].integer.value = 1;
+ args[2].integer.value = brightness ? 0 : 1;
+ } else {
+ return -ENODEV;
+ }
+
+ status = acpi_evaluate_object(handle, acpi_method, _list,
NULL);
+ if (ACPI_FAILURE(status))
+ return -ENODEV;
+
+ return 0;
} else {
- return -EINVAL;
- }
+ u8 arg[8];
- status = acpi_evaluate_object(priv->handle, priv->acpi_method,
_list, NULL);
- if (ACPI_FAILURE(status))
- return -ENXIO;
+ *(u64 *)arg = MICMUTE_LED_SET;
+ arg[2] = brightness;
- return 0;
+ return huawei_wmi_cmd(led_cdev->dev->parent, *(u64 *)arg, NULL,
NULL);
+ }
}
static int huawei_wmi_leds_setup(struct device *dev)
{
struct huawei_wmi_priv *priv = dev_get_drvdata(dev);
- priv->handle = ec_get_handle();
- if (!priv->handle)
- return 0;
-
- if (acpi_has_method(priv->handle, "SPIN"))
- priv->acpi_method = "SPIN";
- else if (acpi_has_method(priv->handle, "WPIN"))
- priv->acpi_method = "WPIN";
- else
- return 0;
-
priv->cdev.name = "platform::micmute";
priv->cdev.max_brightness = 1;
priv->cdev.brightness_set_blocking = huawei_wmi_micmute_led_set;
@@ -412,9 +418,15 @@ static int huawei_wmi_probe(struct platform_device *pdev)
if (wmi_has_guid(HWMI_METHOD_GUID)) {
mutex_init(>wmi_lock);
+
+ err = huawei_wmi_leds_setup(>dev);
+ if (err) {
+ dev_err(>dev, "Failed to setup leds\n");
+ return err;
+ }
}
- return huawei_wmi_leds_setup(>dev);
+ return 0;
}
static int huawei_wmi_remove(struct platform_device *pdev)
--
2.20.1
[RFC 0/9] platform/x86: Huawei WMI laptop extras driver
This patch series introduce changes to huawei-wmi driver that includes: * Move to platform driver * Implement WMI management interface * Add micmute LED support through WMI * Add battery charging protection support through WMI * Add fn-lock support through WMI * Implement driver quirks and parameters * Add a debugfs interface to WMI # Move to platform driver The current driver offers hotkeys and micmute led support only. With these changes, a platform driver makes more sense since it handles these changes pretty nicely. # Implement WMI management interface Huawei Matebook laptops come with two WMI interfaces. The first being WMI0 which is considered "legacy" and AFAIK only found on the Matebook X released in 2017. The second has a UID of "HWMI" and is found in pretty much all models with a slight difference in implementation except for the Matebook X (2017). Since this model has two interfaces, some aspects are controlled through the legacy interface and some through the other interface. Currently, the legacy interface is not fully implemented and is only used for hotkeys and further debugging has to be done. The WMI interface takes a 64 bit integer, although uses 32 bits most of the time, and returns a 256-260 bytes buffer consists of either one ACPI buffer of 260 bytes, in the case of Matebook X (2017), or one ACPI package of two buffers, one with 4 bytes, and the other with 256 bytes. We only care about the latter 256 buffer in both cases since the 4 bytes always return zeros. The first byte of this 256 buffer always has the return status where 1 indicated error. Some models require calling the WMI interface twice to execute a command. # Add micmute LED support through WMI After implementing the WMI interface, micmute LED can be controlled easily. Models with the legacy interface fall back to ACPI EC method control since the legacy interface is not implemented. # Add battery charging protection support through WMI Most models, that has the WMI interface, are capable of battery protection where it can control battery charging thresholds and limits charging the battery to certain values. # Add fn-lock support through WMI The behavior of hotkeys is not the same among all models. Some models require fn-lock to do things like `Ctrl-Ins` or `Alt-PrtSc`. By default, hotkeys behave as special keys (media keys, Ins, etc), but if a modifier is used (ctrl, alt, shift) these keys behave as F1-F12 keys. If the Fn key is toggled on, the hotkeys with or without a modifier, behave as F1-F12 keys. This makes it impossible to use a modifier and `PrtSc` or `Ins`. Now, some models fix this by excluding `PrtSc` and `Ins` keys from being treated as F11 and F12 keys with the use of a modifier. However, some models do not, and fixes this by the so called fn-lock. Fn-lock inverts the behavior of the top row from special keys to F1-F12 keys. So a modifier and a special key would be possible which make things like `Alt-Ins` possible. Now, with fn-lock we would have 4 modes: * Fn-key off & fn-lock off - hotkeys treated as special keys using a modifier gives F1-F12 keys. * Fn-key on & fn-lock off - hotkeys treated as F1-F12 keys and using a modifier gives F1-F12. * Fn-key off & fn-lock on - hotkeys are treated as F1-F12 keys and using a modifier gives special keys. * Fn-key on & fn-lock on - hotkeys are treated as special keys and using a modifier gives special keys. # Implement driver quirks and parameters The driver introduces 3 quirks and 2 parameters that can change the driver's behavior. These quirks being as: 1. Fixes reporting brightness keys twice since it's already handled by acpi-video. 2. Some models need a short delay when setting battery thresholds to prevent a race condition when two processes read/write. 3. Matebook X (2017) handles micmute led through the "legacy" interface which is not currently implemented. Use ACPI EC method to control this led. and the 2 parameters can enforce the behavior of quirk 1 & 2. # Add a debugfs interface to WMI An interface to the WMI management interface that allows easier debugging. Ayman Bagabas (9): platform/x86: huawei-wmi: rename guid and driver name platform/x86: huawei-wmi: move to platform driver platform/x86: huawei-wmi: implement huawei wmi management interface platform/x86: huawei-wmi: add quirks and module parameters platform/x86: huawei-wmi: control micmute led through wmi interface platform/x86: huawei-wmi: add battery charging thresholds platform/x86: huawei-wmi: add fn-lock support platform/x86: huawei-wmi: add sysfs interface support platform/x86: huawei-wmi: add debugfs support drivers/platform/x86/huawei-wmi.c | 710 ++ 1 file changed, 629 insertions(+), 81 deletions(-) -- 2.20.1
Re: WARNING in kernfs_create_dir_ns
syzbot has found a reproducer for the following crash on: HEAD commit:72825454 Merge branch 'x86-urgent-for-linus' of git://git... git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=104d6755a0 kernel config: https://syzkaller.appspot.com/x/.config?x=9a31528e58cc12e2 dashboard link: https://syzkaller.appspot.com/bug?extid=38f5d5cf7ae88c46b11a compiler: clang version 9.0.0 (/home/glider/llvm/clang 80fee25776c2fb61e74c1ecb1a523375c2500b69) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=12a6c439a0 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1353c323a0 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+38f5d5cf7ae88c46b...@syzkaller.appspotmail.com WARNING: CPU: 0 PID: 8613 at fs/kernfs/dir.c:493 kernfs_get fs/kernfs/dir.c:493 [inline] WARNING: CPU: 0 PID: 8613 at fs/kernfs/dir.c:493 kernfs_new_node fs/kernfs/dir.c:700 [inline] WARNING: CPU: 0 PID: 8613 at fs/kernfs/dir.c:493 kernfs_create_dir_ns+0x205/0x230 fs/kernfs/dir.c:1022 Kernel panic - not syncing: panic_on_warn set ... CPU: 0 PID: 8613 Comm: syz-executor696 Not tainted 5.2.0-rc6+ #11 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x1d8/0x2f8 lib/dump_stack.c:113 panic+0x28a/0x7c9 kernel/panic.c:219 __warn+0x216/0x220 kernel/panic.c:576 report_bug+0x190/0x290 lib/bug.c:186 fixup_bug arch/x86/kernel/traps.c:179 [inline] do_error_trap+0xd7/0x450 arch/x86/kernel/traps.c:272 do_invalid_op+0x36/0x40 arch/x86/kernel/traps.c:291 invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:986 RIP: 0010:kernfs_get fs/kernfs/dir.c:493 [inline] RIP: 0010:kernfs_new_node fs/kernfs/dir.c:700 [inline] RIP: 0010:kernfs_create_dir_ns+0x205/0x230 fs/kernfs/dir.c:1022 Code: ff 4c 89 ff e8 7c cd ff ff 4c 63 fb eb 05 e8 22 27 9a ff 4c 89 f8 48 83 c4 10 5b 41 5c 41 5d 41 5e 41 5f 5d c3 e8 0b 27 9a ff <0f> 0b e9 e9 fe ff ff 89 d9 80 e1 07 80 c1 03 38 c1 0f 8c be fe ff RSP: 0018:88808d26f730 EFLAGS: 00010293 RAX: 81db8a95 RBX: 88809e5252a0 RCX: 88808a4aa000 RDX: RSI: RDI: RBP: 88808d26f768 R08: 81db8977 R09: ed1013ca4a55 R10: ed1013ca4a55 R11: 111013ca4a54 R12: 888098a8a200 R13: dc00 R14: R15: 8880a339e620 sysfs_create_dir_ns+0x161/0x300 fs/sysfs/dir.c:59 create_dir lib/kobject.c:89 [inline] kobject_add_internal+0x459/0xd50 lib/kobject.c:255 kobject_add_varg lib/kobject.c:390 [inline] kobject_add+0x138/0x200 lib/kobject.c:442 device_add+0x508/0x1570 drivers/base/core.c:2062 hci_register_dev+0x331/0x6c0 net/bluetooth/hci_core.c:3305 __vhci_create_device drivers/bluetooth/hci_vhci.c:124 [inline] vhci_create_device+0x2d1/0x510 drivers/bluetooth/hci_vhci.c:148 vhci_get_user drivers/bluetooth/hci_vhci.c:204 [inline] vhci_write+0x3ac/0x440 drivers/bluetooth/hci_vhci.c:284 call_write_iter include/linux/fs.h:1872 [inline] new_sync_write fs/read_write.c:483 [inline] __vfs_write+0x617/0x7d0 fs/read_write.c:496 vfs_write+0x227/0x510 fs/read_write.c:558 ksys_write+0x16b/0x2a0 fs/read_write.c:611 __do_sys_write fs/read_write.c:623 [inline] __se_sys_write fs/read_write.c:620 [inline] __x64_sys_write+0x7b/0x90 fs/read_write.c:620 do_syscall_64+0xfe/0x140 arch/x86/entry/common.c:301 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x441279 Code: e8 ac e8 ff ff 48 83 c4 18 c3 0f 1f 80 00 00 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 0f 83 eb 08 fc ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:7fffa3738588 EFLAGS: 0246 ORIG_RAX: 0001 RAX: ffda RBX: RCX: 00441279 RDX: 0002 RSI: 2000 RDI: 0003 RBP: ef5c R08: 004002c8 R09: 004002c8 R10: 0004 R11: 0246 R12: 00401ff0 R13: 00402080 R14: R15: Kernel Offset: disabled Rebooting in 86400 seconds..
[RFC 2/9] platform/x86: huawei-wmi: Move to platform driver
Move from WMI driver to platform driver. This move is necessary since
the driver is no longer a hotkeys driver only. Platform driver makes it
easier for users to access sysfs attributes under (i.e.
/sys/devices/platform/huawei-wmi) compared to wmi driver.
Signed-off-by: Ayman Bagabas
---
Do you think we should stick to wmi driver especially after
"platform/x86: wmi: add context pointer field to struct wmi_device_id"
https://patchwork.kernel.org/patch/10963421/ which is basically was my
issue with wmi driver where there wasn't a way to distinguish what wmi
device is associated with which guid.
I believe that platform driver is more suitable for this since it has
grown from just a hotkeys driver and users can access sysfs of this
easily with platform driver. What do you think?
drivers/platform/x86/huawei-wmi.c | 152 +-
1 file changed, 110 insertions(+), 42 deletions(-)
diff --git a/drivers/platform/x86/huawei-wmi.c
b/drivers/platform/x86/huawei-wmi.c
index a1159850a16c..12cae450fc1f 100644
--- a/drivers/platform/x86/huawei-wmi.c
+++ b/drivers/platform/x86/huawei-wmi.c
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
#include
/*
@@ -23,12 +24,15 @@
struct huawei_wmi_priv {
- struct input_dev *idev;
+ struct input_dev *idev[2];
struct led_classdev cdev;
acpi_handle handle;
char *acpi_method;
+ struct platform_device *pdev;
};
+struct platform_device *huawei_wmi_pdev;
+
static const struct key_entry huawei_wmi_keymap[] = {
{ KE_KEY,0x281, { KEY_BRIGHTNESSDOWN } },
{ KE_KEY,0x282, { KEY_BRIGHTNESSUP } },
@@ -46,6 +50,8 @@ static const struct key_entry huawei_wmi_keymap[] = {
{ KE_END,0 }
};
+/* LEDs */
+
static int huawei_wmi_micmute_led_set(struct led_classdev *led_cdev,
enum led_brightness brightness)
{
@@ -77,9 +83,9 @@ static int huawei_wmi_micmute_led_set(struct led_classdev
*led_cdev,
return 0;
}
-static int huawei_wmi_leds_setup(struct wmi_device *wdev)
+static int huawei_wmi_leds_setup(struct device *dev)
{
- struct huawei_wmi_priv *priv = dev_get_drvdata(>dev);
+ struct huawei_wmi_priv *priv = dev_get_drvdata(dev);
priv->handle = ec_get_handle();
if (!priv->handle)
@@ -97,15 +103,16 @@ static int huawei_wmi_leds_setup(struct wmi_device *wdev)
priv->cdev.brightness_set_blocking = huawei_wmi_micmute_led_set;
priv->cdev.default_trigger = "audio-micmute";
priv->cdev.brightness = ledtrig_audio_get(LED_AUDIO_MICMUTE);
- priv->cdev.dev = >dev;
+ priv->cdev.dev = dev;
priv->cdev.flags = LED_CORE_SUSPENDRESUME;
- return devm_led_classdev_register(>dev, >cdev);
+ return devm_led_classdev_register(dev, >cdev);
}
-static void huawei_wmi_process_key(struct wmi_device *wdev, int code)
+/* Input */
+
+static void huawei_wmi_process_key(struct input_dev *idev, int code)
{
- struct huawei_wmi_priv *priv = dev_get_drvdata(>dev);
const struct key_entry *key;
/*
@@ -129,81 +136,142 @@ static void huawei_wmi_process_key(struct wmi_device
*wdev, int code)
kfree(response.pointer);
}
- key = sparse_keymap_entry_from_scancode(priv->idev, code);
+ key = sparse_keymap_entry_from_scancode(idev, code);
if (!key) {
- dev_info(>dev, "Unknown key pressed, code: 0x%04x\n",
code);
+ dev_info(>dev, "Unknown key pressed, code: 0x%04x\n",
code);
return;
}
- sparse_keymap_report_entry(priv->idev, key, 1, true);
+ sparse_keymap_report_entry(idev, key, 1, true);
}
-static void huawei_wmi_notify(struct wmi_device *wdev,
- union acpi_object *obj)
+static void huawei_wmi_input_notify(u32 value, void *context)
{
- if (obj->type == ACPI_TYPE_INTEGER)
- huawei_wmi_process_key(wdev, obj->integer.value);
+ struct input_dev *idev = (struct input_dev *)context;
+ struct acpi_buffer response = { ACPI_ALLOCATE_BUFFER, NULL };
+ union acpi_object *obj;
+ acpi_status status;
+
+ status = wmi_get_event_data(value, );
+ if (ACPI_FAILURE(status)) {
+ dev_err(>dev, "Unable to get event data\n");
+ return;
+ }
+
+ obj = (union acpi_object *)response.pointer;
+ if (obj && obj->type == ACPI_TYPE_INTEGER)
+ huawei_wmi_process_key(idev, obj->integer.value);
else
- dev_info(>dev, "Bad response type %d\n", obj->type);
+ dev_err(>dev, "Bad response type\n");
+
+ kfree(response.pointer);
}
-static int huawei_wmi_input_setup(struct wmi_device *wdev)
+static int huawei_wmi_input_setup(struct device *dev,
+ struct input_dev **idev)
{
- struct huawei_wmi_priv *priv = dev_get_drvdata(>dev);
int err;
- priv->idev = devm_input_allocate_device(>dev);
- if
[RFC 3/9] platform/x86: huawei-wmi: Implement huawei wmi management interface
Huawei Matebook laptops come with a WMI management interface that can
control various aspects of the device. This interface is also found on
the old Matebook X released in 2017.
Implement basic functionality of this interface along with supported
command IDs that are implemented in this series.
Signed-off-by: Ayman Bagabas
---
drivers/platform/x86/huawei-wmi.c | 130 ++
1 file changed, 130 insertions(+)
diff --git a/drivers/platform/x86/huawei-wmi.c
b/drivers/platform/x86/huawei-wmi.c
index 12cae450fc1f..27520b0f8956 100644
--- a/drivers/platform/x86/huawei-wmi.c
+++ b/drivers/platform/x86/huawei-wmi.c
@@ -10,24 +10,36 @@
#include
#include
#include
+#include
#include
#include
/*
* Huawei WMI GUIDs
*/
+#define HWMI_METHOD_GUID "ABBC0F5B-8EA1-11D1-A000-C9062910"
#define HWMI_EVENT_GUID "ABBC0F5C-8EA1-11D1-A000-C9062910"
/* Legacy GUIDs */
#define WMI0_EXPENSIVE_GUID "39142400-C6A3-40fa-BADB-8A2652834100"
#define WMI0_EVENT_GUID "59142400-C6A3-40fa-BADB-8A2652834100"
+/* HWMI commands */
+
+enum {
+ BATTERY_THRESH_GET = 0x1103, /* \GBTT */
+ BATTERY_THRESH_SET = 0x1003, /* \SBTT */
+ FN_LOCK_GET = 0x0604, /* \GFRS */
+ FN_LOCK_SET = 0x0704, /* \SFRS */
+ MICMUTE_LED_SET = 0x0b04, /* \SMLS */
+};
struct huawei_wmi_priv {
struct input_dev *idev[2];
struct led_classdev cdev;
acpi_handle handle;
char *acpi_method;
+ struct mutex wmi_lock;
struct platform_device *pdev;
};
@@ -50,6 +62,116 @@ static const struct key_entry huawei_wmi_keymap[] = {
{ KE_END,0 }
};
+/* Utils */
+
+static int huawei_wmi_call(struct device *dev, struct acpi_buffer *in,
+ struct acpi_buffer *out)
+{
+ struct huawei_wmi_priv *priv = dev_get_drvdata(dev);
+ acpi_status status;
+
+ mutex_lock(>wmi_lock);
+ status = wmi_evaluate_method(HWMI_METHOD_GUID, 0, 1, in, out);
+ mutex_unlock(>wmi_lock);
+ if (ACPI_FAILURE(status)) {
+ dev_err(dev, "Failed to evaluate wmi method\n");
+ return -ENODEV;
+ }
+
+ return 0;
+}
+
+/* HWMI takes a 64 bit input and returns either a package with 2 buffers, one
of
+ * 4 bytes and the other of 256 bytes, or one buffer of size 0x104 (260) bytes.
+ * The first 4 bytes are ignored, we ignore the first 4 bytes buffer if we got
a
+ * package, or skip the first 4 if a buffer of 0x104 is used. The first byte of
+ * the remaining 0x100 sized buffer has the return status of every call. In
case
+ * the return status is non-zero, we return -ENODEV but still copy the returned
+ * buffer to the given buffer parameter (buf).
+ */
+static int huawei_wmi_cmd(struct device *dev, u64 arg, u8 *buf, size_t buflen)
+{
+ struct acpi_buffer out = { ACPI_ALLOCATE_BUFFER, NULL };
+ struct acpi_buffer in;
+ union acpi_object *obj;
+ size_t len;
+ int err, i;
+
+ in.length = sizeof(arg);
+ in.pointer =
+
+ /* Some models require calling HWMI twice to execute a command. We
evaluate
+* HWMI and if we get a non-zero return status we evaluate it again.
+*/
+ for (i = 0; i < 2; i++) {
+ err = huawei_wmi_call(dev, , );
+ if (err)
+ goto fail_cmd;
+
+ obj = out.pointer;
+ if (!obj) {
+ err = -EIO;
+ goto fail_cmd;
+ }
+
+ switch (obj->type) {
+ /* Models that implement both "legacy" and HWMI tend to return
a 0x104
+* sized buffer instead of a package of 0x4 and 0x100 buffers.
+*/
+ case ACPI_TYPE_BUFFER:
+ if (obj->buffer.length == 0x104) {
+ // Skip the first 4 bytes.
+ obj->buffer.pointer += 4;
+ len = 0x100;
+ } else {
+ dev_err(dev, "Bad buffer length, got %d\n",
obj->buffer.length);
+ err = -EIO;
+ goto fail_cmd;
+ }
+
+ break;
+ /* HWMI returns a package with 2 buffer elements, one of 4
bytes and the
+* other is 256 bytes.
+*/
+ case ACPI_TYPE_PACKAGE:
+ if (obj->package.count != 2) {
+ dev_err(dev, "Bad package count, got %d\n",
obj->package.count);
+ err = -EIO;
+ goto fail_cmd;
+ }
+
+ obj = >package.elements[1];
+ if (obj->type != ACPI_TYPE_BUFFER) {
+ dev_err(dev, "Bad
[RFC 4/9] platform/x86: huawei-wmi: Add quirks and module parameters
Introduce quirks and module parameters. 3 quirks are added:
1. Fixes reporting brightness keys twice since it's already handled by
acpi-video.
2. Some models need a short delay when setting battery thresholds to
prevent a race condition when two processes read/write.
3. Matebook X (2017) handles micmute led through the "legacy" interface
which is not currently implemented. Use ACPI EC method to control
this led.
2 module parameters are added to enable this short delay and/or report
brightness keys through this driver.
Signed-off-by: Ayman Bagabas
---
drivers/platform/x86/huawei-wmi.c | 71 +++
1 file changed, 71 insertions(+)
diff --git a/drivers/platform/x86/huawei-wmi.c
b/drivers/platform/x86/huawei-wmi.c
index 27520b0f8956..8f918138053a 100644
--- a/drivers/platform/x86/huawei-wmi.c
+++ b/drivers/platform/x86/huawei-wmi.c
@@ -6,6 +6,7 @@
*/
#include
+#include
#include
#include
#include
@@ -34,6 +35,14 @@ enum {
MICMUTE_LED_SET = 0x0b04, /* \SMLS */
};
+struct quirk_entry {
+ bool battery_sleep;
+ bool ec_micmute;
+ bool report_brightness;
+};
+
+static struct quirk_entry *quirks;
+
struct huawei_wmi_priv {
struct input_dev *idev[2];
struct led_classdev cdev;
@@ -62,6 +71,58 @@ static const struct key_entry huawei_wmi_keymap[] = {
{ KE_END,0 }
};
+static bool battery_sleep;
+static bool report_brightness;
+
+module_param(battery_sleep, bool, 0444);
+MODULE_PARM_DESC(battery_sleep,
+ "Delay after setting battery charging thresholds.");
+module_param(report_brightness, bool, 0444);
+MODULE_PARM_DESC(report_brightness,
+ "Report brightness keys.");
+
+/* Quirks */
+
+static int __init dmi_matched(const struct dmi_system_id *dmi)
+{
+ quirks = dmi->driver_data;
+ return 1;
+}
+
+static struct quirk_entry quirk_unknown = {
+};
+
+static struct quirk_entry quirk_battery_sleep = {
+ .battery_sleep = true,
+};
+
+static struct quirk_entry quirk_matebook_x = {
+ .ec_micmute = true,
+ .report_brightness = true,
+};
+
+static const struct dmi_system_id huawei_quirks[] = {
+ {
+ .callback = dmi_matched,
+ .ident = "Huawei MACH-WX9",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "HUAWEI"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "MACH-WX9"),
+ },
+ .driver_data = _battery_sleep
+ },
+ {
+ .callback = dmi_matched,
+ .ident = "Huawei MateBook X",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "HUAWEI"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "HUAWEI MateBook X")
+ },
+ .driver_data = _matebook_x
+ },
+ { }
+};
+
/* Utils */
static int huawei_wmi_call(struct device *dev, struct acpi_buffer *in,
@@ -264,6 +325,11 @@ static void huawei_wmi_process_key(struct input_dev *idev,
int code)
return;
}
+ if (quirks && !quirks->report_brightness &&
+ (key->sw.code == KEY_BRIGHTNESSDOWN ||
+ key->sw.code == KEY_BRIGHTNESSUP))
+ return;
+
sparse_keymap_report_entry(idev, key, 1, true);
}
@@ -377,6 +443,11 @@ static __init int huawei_wmi_init(void)
{
int err;
+ quirks = _unknown;
+ dmi_check_system(huawei_quirks);
+ quirks->battery_sleep |= battery_sleep;
+ quirks->report_brightness |= report_brightness;
+
err = platform_driver_register(_wmi_driver);
if (err)
return err;
--
2.20.1
[RFC 1/9] platform/x86: huawei-wmi: Rename guid and driver name
Use WMI device UID, AMW0 has a UID of HWMI. WMI0 is the device name
and doesn't have a UID so keep it as it is.
Change module description to reflect the upcoming changes.
Signed-off-by: Ayman Bagabas
---
drivers/platform/x86/huawei-wmi.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/platform/x86/huawei-wmi.c
b/drivers/platform/x86/huawei-wmi.c
index 52fcac5b393a..a1159850a16c 100644
--- a/drivers/platform/x86/huawei-wmi.c
+++ b/drivers/platform/x86/huawei-wmi.c
@@ -1,6 +1,6 @@
// SPDX-License-Identifier: GPL-2.0
/*
- * Huawei WMI hotkeys
+ * Huawei WMI laptop extras driver
*
* Copyright (C) 2018 Ayman Bagabas
*/
@@ -15,10 +15,12 @@
/*
* Huawei WMI GUIDs
*/
-#define WMI0_EVENT_GUID "59142400-C6A3-40fa-BADB-8A2652834100"
-#define AMW0_EVENT_GUID "ABBC0F5C-8EA1-11D1-A000-C9062910"
+#define HWMI_EVENT_GUID "ABBC0F5C-8EA1-11D1-A000-C9062910"
+/* Legacy GUIDs */
#define WMI0_EXPENSIVE_GUID "39142400-C6A3-40fa-BADB-8A2652834100"
+#define WMI0_EVENT_GUID "59142400-C6A3-40fa-BADB-8A2652834100"
+
struct huawei_wmi_priv {
struct input_dev *idev;
@@ -37,7 +39,7 @@ static const struct key_entry huawei_wmi_keymap[] = {
{ KE_KEY,0x289, { KEY_WLAN } },
// Huawei |M| key
{ KE_KEY,0x28a, { KEY_CONFIG } },
- // Keyboard backlight
+ // Keyboard backlit
{ KE_IGNORE, 0x293, { KEY_KBDILLUMTOGGLE } },
{ KE_IGNORE, 0x294, { KEY_KBDILLUMUP } },
{ KE_IGNORE, 0x295, { KEY_KBDILLUMUP } },
@@ -186,7 +188,7 @@ static int huawei_wmi_probe(struct wmi_device *wdev)
static const struct wmi_device_id huawei_wmi_id_table[] = {
{ .guid_string = WMI0_EVENT_GUID },
- { .guid_string = AMW0_EVENT_GUID },
+ { .guid_string = HWMI_EVENT_GUID },
{ }
};
@@ -203,5 +205,5 @@ module_wmi_driver(huawei_wmi_driver);
MODULE_DEVICE_TABLE(wmi, huawei_wmi_id_table);
MODULE_AUTHOR("Ayman Bagabas ");
-MODULE_DESCRIPTION("Huawei WMI hotkeys");
+MODULE_DESCRIPTION("Huawei WMI laptop extras driver");
MODULE_LICENSE("GPL v2");
--
2.20.1
Re: [PATCH] mm: Generalize and rename notify_page_fault() as kprobe_page_fault()
Hello Guenter,
On 06/29/2019 08:20 PM, Guenter Roeck wrote:
> Hi,
>
> On Thu, Jun 13, 2019 at 03:37:24PM +0530, Anshuman Khandual wrote:
>> Architectures which support kprobes have very similar boilerplate around
>> calling kprobe_fault_handler(). Use a helper function in kprobes.h to unify
>> them, based on the x86 code.
>>
>> This changes the behaviour for other architectures when preemption is
>> enabled. Previously, they would have disabled preemption while calling the
>> kprobe handler. However, preemption would be disabled if this fault was
>> due to a kprobe, so we know the fault was not due to a kprobe handler and
>> can simply return failure.
>>
>> This behaviour was introduced in the commit a980c0ef9f6d ("x86/kprobes:
>> Refactor kprobes_fault() like kprobe_exceptions_notify()")
>>
>
> With this patch applied, parisc:allmodconfig images no longer build.
>
> In file included from arch/parisc/mm/fixmap.c:8:
> include/linux/kprobes.h: In function 'kprobe_page_fault':
> include/linux/kprobes.h:477:9: error:
> implicit declaration of function 'kprobe_fault_handler'; did you mean
> 'kprobe_page_fault'?
Yikes.. Arch parisc does not even define (unlike mips which did but never
exported)
now required function kprobe_fault_handler() when CONFIG_KPROBES is enabled.
I believe rather than defining one stub version only for parsic it would be
better
to have an weak symbol generic stub definition for kprobe_fault_handler() in
file
include/linux/kprobes.h when CONFIG_KPROBES is enabled along side the other stub
definition when !CONFIG_KPROBES. But arch which wants to use kprobe_page_fault()
cannot use stub kprobe_fault_handler() definition and will have to provide one.
I will probably add a comment regarding this.
>
> Reverting the patch fixes the problem.
>
> Guenter
>
Thanks for reporting the problem.
Re: [PATCH] hwspinlock: stm32: implement the relax() ops
On Thu 07 Mar 07:42 PST 2019, Fabien Dessenne wrote:
> Implement this optional ops, called by hwspinlock core while spinning on
> a lock, between two successive invocations of trylock().
>
> Signed-off-by: Fabien Dessenne
Applied
Thanks,
Bjorn
> ---
> drivers/hwspinlock/stm32_hwspinlock.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/hwspinlock/stm32_hwspinlock.c
> b/drivers/hwspinlock/stm32_hwspinlock.c
> index 4418392..c8eacf4 100644
> --- a/drivers/hwspinlock/stm32_hwspinlock.c
> +++ b/drivers/hwspinlock/stm32_hwspinlock.c
> @@ -5,6 +5,7 @@
> */
>
> #include
> +#include
> #include
> #include
> #include
> @@ -42,9 +43,15 @@ static void stm32_hwspinlock_unlock(struct hwspinlock
> *lock)
> writel(STM32_MUTEX_COREID, lock_addr);
> }
>
> +static void stm32_hwspinlock_relax(struct hwspinlock *lock)
> +{
> + ndelay(50);
> +}
> +
> static const struct hwspinlock_ops stm32_hwspinlock_ops = {
> .trylock= stm32_hwspinlock_trylock,
> .unlock = stm32_hwspinlock_unlock,
> + .relax = stm32_hwspinlock_relax,
> };
>
> static int stm32_hwspinlock_probe(struct platform_device *pdev)
> --
> 2.7.4
>
Re: [PATCH v4 0/8] stm32 m4 remoteproc on STM32MP157c
On Tue 14 May 01:26 PDT 2019, Fabien Dessenne wrote: > STMicrolectronics STM32MP157 MPU are based on a Dual Arm Cortex-A7 core and a > Cortex-M4. > This patchset adds the support of the stm32_rproc driver allowing to control > the M4 remote processor. > Applied patches 1 through 3, with a few fixes of compile warnings on data types in dev_dbg, in patch 3. Thanks, Bjorn > Changes since v3: > -Replaced "st,auto_boot" with "st,auto-boot" > -Update m4 reg values and align with unit-address > > Changes since v2: > - Clarified "reg" description > - Change m4 unit adress to 3800 > - Renamed "auto_boot" in "st,auto-boot" > > Changes since v1: > - Gave details about the memory mapping (in bindings). > - Used 'dma-ranges' instead of 'ranges'. > - Updated the 'compatible' property. > - Remove the 'recovery', 'reset-names' and 'interrupt-names' properties. > - Clarified why / when mailboxes are optional. > > Fabien Dessenne (8): > dt-bindings: stm32: add bindings for ML-AHB interconnect > dt-bindings: remoteproc: add bindings for stm32 remote processor > driver > remoteproc: stm32: add an ST stm32_rproc driver > ARM: dts: stm32: add m4 remoteproc support on STM32MP157c > ARM: dts: stm32: declare copro reserved memories on STM32MP157c-ed1 > ARM: dts: stm32: enable m4 coprocessor support on STM32MP157c-ed1 > ARM: dts: stm32: declare copro reserved memories on STM32MP157a-dk1 > ARM: dts: stm32: enable m4 coprocessor support on STM32MP157a-dk1 > > .../devicetree/bindings/arm/stm32/mlahb.txt| 37 ++ > .../devicetree/bindings/remoteproc/stm32-rproc.txt | 63 +++ > arch/arm/boot/dts/stm32mp157a-dk1.dts | 52 ++ > arch/arm/boot/dts/stm32mp157c-ed1.dts | 52 ++ > arch/arm/boot/dts/stm32mp157c.dtsi | 20 + > drivers/remoteproc/Kconfig | 15 + > drivers/remoteproc/Makefile| 1 + > drivers/remoteproc/stm32_rproc.c | 628 > + > 8 files changed, 868 insertions(+) > create mode 100644 Documentation/devicetree/bindings/arm/stm32/mlahb.txt > create mode 100644 > Documentation/devicetree/bindings/remoteproc/stm32-rproc.txt > create mode 100644 drivers/remoteproc/stm32_rproc.c > > -- > 2.7.4 >
[PATCH] media: imx7-media-csi: Remove unneeded break after return
This patch fixes the checkpatch.pl warning: WARNING: break is not useful after a goto or return Signed-off-by: Chinmaya Krishnan Mahesh --- drivers/staging/media/imx/imx7-media-csi.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/staging/media/imx/imx7-media-csi.c b/drivers/staging/media/imx/imx7-media-csi.c index a708a0340eb1..c15acca1dc0d 100644 --- a/drivers/staging/media/imx/imx7-media-csi.c +++ b/drivers/staging/media/imx/imx7-media-csi.c @@ -1021,7 +1021,6 @@ static int imx7_csi_try_fmt(struct imx7_csi *csi, break; default: return -EINVAL; - break; } return 0; } -- 2.22.0
Linux 5.2-rc7
It's Sunday afternoon _somewhere_ in the world right now. In particular, in the middle of nowhere on a boat. I didn't expect to have any internet this week, and honestly, I haven't had much, and not fast. But enough to keep up with critical pull requests, and enough to push out an rc. But credit for the internet goes to Disk Hohndel and vmware, because I'm mooching off his phone hotspot WiFi to do this. Anyway, It's been _fairly_ calm. Would I have hoped for even calmer with my crappy internet? Sure. But hey, it's a lot smaller than rc6 was and I'm not really complaining. All small and fairly uninteresting. Arch updates, networking, core kernel, filesystems, misc drivers. Nothing stands out - just read the appended shortlog. It's small enough to be easy to just scroll through. Linus --- Al Viro (1): copy_process(): don't use ksys_close() on cleanups Alejandro Jimenez (1): x86/speculation: Allow guests to use SSBD even if host does not Alexandre Belloni (2): pinctrl: ocelot: fix gpio direction for pins after 31 pinctrl: ocelot: fix pinmuxing for pins after 31 Alexey Brodkin (1): ARC: build: Try to guess CROSS_COMPILE with cc-cross-prefix Andrea Arcangeli (1): fork,memcg: alloc_thread_stack_node needs to set tsk->stack Anshuman Khandual (1): mm/dev_pfn: exclude MEMORY_DEVICE_PRIVATE while computing virtual address Antoine Tenart (1): net: macb: do not copy the mac address if NULL Ard Biesheuvel (1): efi/memreserve: deal with memreserve entries in unmapped memory Arnd Bergmann (2): ARM: omap2: remove incorrect __init annotation mm/vmalloc.c: avoid bogus -Wmaybe-uninitialized warning Atish Patra (1): RISC-V: defconfig: enable MMC & SPI for RISC-V Bjørn Mork (1): qmi_wwan: Fix out-of-bounds read Christian Brauner (1): proc: remove useless d_is_dir() check Colin Ian King (2): x86/apic: Fix integer overflow on 10 bit left shift of cpu_khz mm/page_idle.c: fix oops because end_pfn is larger than max_pfn Dan Carpenter (3): mfd: stmfx: Uninitialized variable in stmfx_irq_handler() mfd: stmfx: Fix an endian bug in stmfx_irq_handler() HID: intel-ish-hid: Fix a use after free in load_fw_from_host() David Howells (4): afs: Fix over zealous "vnode modified" warnings afs: Fix vlserver record corruption afs: Fix uninitialised spinlock afs_volume::cb_break_lock afs: Fix setting of i_blocks Dinh Nguyen (1): clk: socfpga: stratix10: fix divider entry for the emac clocks Dirk van der Merwe (1): net/tls: fix page double free on TX cleanup Dmitry Bogdanov (1): net: aquantia: fix vlans not working over bridged network Dmitry V. Levin (2): fork: don't check parent_tidptr with CLONE_PIDFD samples: make pidfd-metadata fail gracefully on older kernels Eiichi Tsukata (2): net/ipv6: Fix misuse of proc_dointvec "skip_notify_on_dev_down" cpu/hotplug: Fix out-of-bounds read when setting fail state Eric Dumazet (1): net/packet: fix memory leak in packet_set_ring() Eugeniy Paltsev (1): ARC: [plat-hsdk]: unify memory apertures configuration Florian Fainelli (2): MAINTAINERS: BCM2835: Add internal Broadcom mailing list MAINTAINERS: BCM53573: Add internal Broadcom mailing list Geert Uytterhoeven (2): cpu/speculation: Warn on unsupported mitigations= parameter initramfs: fix populate_initrd_image() section mismatch Gen Zhang (1): dm init: fix incorrect uses of kstrndup() Guo Ren (2): irqchip/irq-csky-mpintc: Support auto irq deliver to all cpus csky: Fixup libgcc unwind error Hans de Goede (2): efi/bgrt: Drop BGRT status field reserved bits check HID: logitech-dj: Fix forwarding of very long HID++ reports Helge Deller (1): parisc: Fix module loading error with JUMP_LABEL feature Heyi Guo (1): irqchip/gic-v3-its: Fix command queue pointer comparison bug Huang Ying (1): mm, swap: fix THP swap out Huaping Zhou (1): net/smc: hold conns_lock before calling smc_lgr_register_conn() Hyungwoo Yang (1): HID: intel-ish-hid: fix wrong driver_data usage Jan Kara (1): scsi: vmw_pscsi: Fix use-after-free in pvscsi_queue_lck() Jann Horn (1): fs/binfmt_flat.c: make load_flat_shared_library() work Jeff Layton (1): ceph: fix ceph_mdsc_build_path to not stop on first component Jens Axboe (1): io_uring: ensure req->file is cleared on allocation Jerome Brunet (1): clk: meson: fix MPLL 50M binding id typo Jerome Marchand (1): dm table: don't copy from a NULL pointer in realloc_argv() Johannes Weiner (1): mm: fix page cache convergence regression John Ogness (1): fs/proc/array.c: allow reporting eip/esp for all coredumping threads Jon Hunter (1): clk: tegra210: Fix default rates for HDA clocks Josh Poimboeuf (1): x86/unwind/orc: Fall back to using frame pointers for generated
Re: [GIT pull] smp fixes for 5.2
The pull request you sent on Sat, 29 Jun 2019 17:13:04 +0200 (CEST): > git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git smp-urgent-for-linus has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/7c15f41e8743df676f6cb0615e74e8ba30994d6a Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] Please pull powerpc/linux.git powerpc-5.2-7 tag
The pull request you sent on Sat, 29 Jun 2019 22:26:26 +1000: > https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git > tags/powerpc-5.2-7 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/39132f746eceed6beecb16c7b79600fb54eb8b2b Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [RFC PATCH v2 1/2] printk-rb: add a new printk ringbuffer implementation
On 2019-06-29, Andrea Parri wrote:
>> /**
>> * add_descr_list() - Add a descriptor to the descriptor list.
>> *
>> * @e: An entry that has already reserved data.
>> *
>> * The provided entry contains a pointer to a descriptor that has already
>> * been reserved for this entry. However, the reserved descriptor is not
>> * yet on the list. Add this descriptor as the newest item.
>> *
>> * A descriptor is added in two steps. The first step is to make this
>> * descriptor the newest. The second step is to update @next of the former
>> * newest descriptor to point to this one (or set @oldest to this one if
>> * this will be the first descriptor on the list).
>> */
>> static void add_descr_list(struct prb_reserved_entry *e)
>> {
>> struct printk_ringbuffer *rb = e->rb;
>> struct prb_list *l = >descr_list;
>> struct prb_descr *d = e->descr;
>> struct prb_descr *newest_d;
>> unsigned long newest_id;
>>
>> WRITE_ONCE(d->next, EOL);
>
> /* C */
>
>
>>
>> do {
>> newest_id = READ_ONCE(l->newest);
>
> /* A */
>
>
>> newest_d = TO_DESC(rb, newest_id);
>>
>> if (newest_id == EOL) {
>> WRITE_ONCE(d->seq, 1);
>> } else {
>> /*
>> * MB5-read: synchronize setting newest descr
>> *
>> * context-pair: 2 writers adding a descriptor via
>> * add_descr_list().
>> *
>> * @newest will load before @seq due to a data
>> * dependency, therefore, the stores of @seq
>> * and @next from the pairing MB5-write context
>> * will be visible.
>> *
>> * Although @next is not loaded by this context,
>> * this context must overwrite the stored @next
>> * value of the pairing MB5-write context.
>> */
>> WRITE_ONCE(d->seq, READ_ONCE(newest_d->seq) + 1);
>
> /* B: this READ_ONCE() */
>
> Hence you're claiming a data dependency from A to B. (FWIW, the LKMM
> would call "A ->dep B" an "address dependency.)
>
> This comment also claims that the "pairing MB5-write" orders "stores
> of @seq and @next" (which are to different memory locations w.r.t. A
> and B): I do not get why this access to @next (C above?, that's also
> "unordered" w.r.t. A) can be relevant; can you elaborate?
I will add some more labels to complete the picture. All these events
are within this function:
D: the WRITE_ONCE() to @seq
E: the STORE of a successful cmpxchg() for @newest (the MB5-write
cmpxchg())
F: the STORE of a new @next (the last smp_store_release() of this
function, note that the _release() is not relevant for this pair)
The significant events for 2 contexts that are accessing the same
addresses of a descriptor are:
P0(struct desc *d0)
{
// adding a new descriptor d0
WRITE_ONCE(d0->next, EOL); // C
WRITE_ONCE(d0->seq, X); // D
cmpxchg_release(newest, Y, indexof(d0)); // E
}
P1(struct desc *d1)
{
// adding a new descriptor d1 that comes after d0
struct desc *d0;
int r0, r1;
r0 = READ_ONCE(newest); // A
d0 = [r0];
r1 = READ_ONCE(d0->seq);// B
WRITE_ONCE(d0->next, Z);// F
}
d0 is the same address for P0 and P1. (The values of EOL, X, Y, Z are
unrelated and irrelevant.)
I am claiming that:
- B comes after D
- F comes after C
>> }
>>
>> /*
>> * MB5-write: synchronize setting newest descr
>> *
>> * context-pair: 2 writers adding a descriptor via
>> * add_descr_list().
>> *
>> * Ensure that @next and @seq are stored before @d is
>> * visible via @newest. The pairing MB5-read context
>> * must load this @seq value and must overwrite this
>> * @next value.
>> */
>> } while (cmpxchg_release(>newest, newest_id, e->id) != newest_id);
>>
>> if (unlikely(newest_id == EOL)) {
>> /*
>> * MB0-write: synchronize adding first descr
>> *
>> * context-pair: 1 writer adding the first descriptor via
>> * add_descr_list(), 1 reader getting the beginning of
>> * the list via iter_peek_next_id().
>> *
>> * This context recently assigned new values for @id,
>> * @next, @seq. Ensure these are stored before the first
>> * store to @oldest so that the new values are visible
>> * to the reader in the pairing MB0-read context.
>> *
>> * Note: Before this store, the value of @oldest is EOL.
>>
Re: [PATCH v3 1/4] kbuild: compile-test UAPI headers to ensure they are self-contained
On Fri, Jun 28, 2019 at 1:40 AM Masahiro Yamada wrote: > > Multiple people have suggested compile-testing UAPI headers to ensure > they can be really included from user-space. "make headers_check" is > obviously not enough to catch bugs, and we often leak references to > kernel-space definition to user-space. > > Use the new header-test-y syntax to implement it. Please note exported > headers are compile-tested with a completely different set of compiler > flags. The header search path is set to $(objtree)/usr/include since > exported headers should not include unexported ones. > > We use -std=gnu89 for the kernel space since the kernel code highly > depends on GNU extensions. On the other hand, UAPI headers should be > written in more standardized C, so they are compiled with -std=c90. > This will emit errors if C++ style comments, the keyword 'inline', etc. > are used. Please use C style comments (/* ... */), '__inline__', etc. > in UAPI headers. > > There is additional compiler requirement to enable this test because > many of UAPI headers include , , , > etc. directly or indirectly. You cannot use kernel.org pre-built > toolchains [1] since they lack . > > I added scripts/cc-system-headers.sh to check the system header > availability, which CONFIG_UAPI_HEADER_TEST depends on. Perhaps, we could use scripts/cc-can-link.sh for this purpose. The intention is slightly different, but a compiler to link user-space programs must provide necessary standard headers. -- Best Regards Masahiro Yamada
Re: [PATCH 10/10] staging/rtl8723bs/hal: fix comparison to true/false is error prone
On Sat, Jun 29, 2019 at 04:07:51PM +0530, Hariprasad Kelam wrote:
Hello Hari Prasad,
Please add the recommended reviewers mentioned in the TODO file of
rtl8723bs directory.
I see the following emails in the TODO file.
Greg Kroah-Hartman ,
Hans de Goede and Larry Finger
> fix below issues reported by checkpatch
>
> CHECK: Using comparison to false is error prone
> CHECK: Using comparison to true is error prone
>
> Signed-off-by: Hariprasad Kelam
> ---
> drivers/staging/rtl8723bs/hal/hal_btcoex.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/staging/rtl8723bs/hal/hal_btcoex.c
> b/drivers/staging/rtl8723bs/hal/hal_btcoex.c
> index 66caf34..99e0b91 100644
> --- a/drivers/staging/rtl8723bs/hal/hal_btcoex.c
> +++ b/drivers/staging/rtl8723bs/hal/hal_btcoex.c
> @@ -290,7 +290,7 @@ static u8 halbtcoutsrc_IsWifiBusy(struct adapter
> *padapter)
> if (check_fwstate(pmlmepriv, WIFI_ASOC_STATE) == true) {
> if (check_fwstate(pmlmepriv, WIFI_AP_STATE) == true)
> return true;
> - if (true == pmlmepriv->LinkDetectInfo.bBusyTraffic)
> + if (pmlmepriv->LinkDetectInfo.bBusyTraffic)
> return true;
> }
>
> @@ -310,12 +310,12 @@ static u32 _halbtcoutsrc_GetWifiLinkStatus(struct
> adapter *padapter)
>
> if (check_fwstate(pmlmepriv, WIFI_ASOC_STATE) == true) {
> if (check_fwstate(pmlmepriv, WIFI_AP_STATE) == true) {
> - if (true == bp2p)
> + if (bp2p)
> portConnectedStatus |= WIFI_P2P_GO_CONNECTED;
> else
> portConnectedStatus |= WIFI_AP_CONNECTED;
> } else {
> - if (true == bp2p)
> + if (bp2p)
> portConnectedStatus |= WIFI_P2P_GC_CONNECTED;
> else
> portConnectedStatus |= WIFI_STA_CONNECTED;
> @@ -372,7 +372,7 @@ static u8 halbtcoutsrc_GetWifiScanAPNum(struct adapter
> *padapter)
>
> pmlmeext = >mlmeextpriv;
>
> - if (GLBtcWiFiInScanState == false) {
> + if (!GLBtcWiFiInScanState) {
> if (pmlmeext->sitesurvey_res.bss_cnt > 0xFF)
> scan_AP_num = 0xFF;
> else
> @@ -1444,7 +1444,7 @@ void hal_btcoex_IQKNotify(struct adapter *padapter, u8
> state)
>
> void hal_btcoex_BtInfoNotify(struct adapter *padapter, u8 length, u8 *tmpBuf)
> {
> - if (GLBtcWiFiInIQKState == true)
> + if (GLBtcWiFiInIQKState)
> return;
>
> EXhalbtcoutsrc_BtInfoNotify(, tmpBuf, length);
> --
> 2.7.4
>
Re: [PATCH v3 1/4] kbuild: compile-test UAPI headers to ensure they are self-contained
Hi Sam,
On Sat, Jun 29, 2019 at 12:44 AM Sam Ravnborg wrote:
>
> Hi Masahiro.
>
> On Fri, Jun 28, 2019 at 01:38:59AM +0900, Masahiro Yamada wrote:
> > Multiple people have suggested compile-testing UAPI headers to ensure
> > they can be really included from user-space. "make headers_check" is
> > obviously not enough to catch bugs, and we often leak references to
> > kernel-space definition to user-space.
> >
> > Use the new header-test-y syntax to implement it. Please note exported
> > headers are compile-tested with a completely different set of compiler
> > flags. The header search path is set to $(objtree)/usr/include since
> > exported headers should not include unexported ones.
>
> This patchset introduce a new set of tests for uapi headers.
> Can we somehow consolidate so we have only one way to verify the uapi
> headers?
> It can be confusing for users that they see errors from testing the
> uapi headers during normal build and a new class or error if they
> run a "make headers_check" sometimes later.
Good point. I had also noticed some over-wrap
between this feature and scripts/headers_check.pl
For example, check_include will be unneeded.
I expect "make headers_check" will be deprecated
sooner or later.
> This can be a next step to consolidate this.
> With the suggestions below considered you can add my:
> Reviewed-by: Sam Ravnborg
>
> >
> > We use -std=gnu89 for the kernel space since the kernel code highly
> > depends on GNU extensions. On the other hand, UAPI headers should be
> > written in more standardized C, so they are compiled with -std=c90.
> > This will emit errors if C++ style comments, the keyword 'inline', etc.
> > are used. Please use C style comments (/* ... */), '__inline__', etc.
> > in UAPI headers.
> >
> > There is additional compiler requirement to enable this test because
> > many of UAPI headers include , , ,
> > etc. directly or indirectly. You cannot use kernel.org pre-built
> > toolchains [1] since they lack .
> >
> > I added scripts/cc-system-headers.sh to check the system header
> > availability, which CONFIG_UAPI_HEADER_TEST depends on.
> >
> > For now, a lot of headers need to be excluded because they cannot
> > be compiled standalone, but this is a good start point.
> >
> > [1] https://mirrors.edge.kernel.org/pub/tools/crosstool/index.html
> >
> > Signed-off-by: Masahiro Yamada
> > ---
> >
> > Changes in v3: None
> > Changes in v2:
> > - Add CONFIG_CPU_{BIG,LITTLE}_ENDIAN guard to avoid build error
> > - Use 'header-test-' instead of 'no-header-test'
> > - Avoid weird 'find' warning when cleaning
> >
> > Makefile | 2 +-
> > init/Kconfig | 11 +++
> > scripts/cc-system-headers.sh | 8 +++
> > usr/.gitignore | 1 -
> > usr/Makefile | 2 +
> > usr/include/.gitignore | 3 +
> > usr/include/Makefile | 134 +++
> > 7 files changed, 159 insertions(+), 2 deletions(-)
> > create mode 100755 scripts/cc-system-headers.sh
> > create mode 100644 usr/include/.gitignore
> > create mode 100644 usr/include/Makefile
> >
> > diff --git a/Makefile b/Makefile
> > index 1f35aca4fe05..f23516980796 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -1363,7 +1363,7 @@ CLEAN_DIRS += $(MODVERDIR) include/ksym
> > CLEAN_FILES += modules.builtin.modinfo
> >
> > # Directories & files removed with 'make mrproper'
> > -MRPROPER_DIRS += include/config usr/include include/generated \
> > +MRPROPER_DIRS += include/config include/generated \
> > arch/$(SRCARCH)/include/generated .tmp_objdiff
> > MRPROPER_FILES += .config .config.old .version \
> > Module.symvers tags TAGS cscope* GPATH GTAGS GRTAGS GSYMS \
> > diff --git a/init/Kconfig b/init/Kconfig
> > index df5bba27e3fe..667d68e1cdf4 100644
> > --- a/init/Kconfig
> > +++ b/init/Kconfig
> > @@ -105,6 +105,17 @@ config HEADER_TEST
> > If you are a developer or tester and want to ensure the requested
> > headers are self-contained, say Y here. Otherwise, choose N.
> >
> > +config UAPI_HEADER_TEST
> > + bool "Compile test UAPI headers"
> > + depends on HEADER_TEST && HEADERS_INSTALL
> > + depends on $(success,$(srctree)/scripts/cc-system-headers.sh $(CC))
> > + help
> > + Compile test headers exported to user-space to ensure they are
> > + self-contained, i.e. compilable as standalone units.
> > +
> > + If you are a developer or tester and want to ensure the exported
> > + headers are self-contained, say Y here. Otherwise, choose N.
> > +
> > config LOCALVERSION
> > string "Local version - append to kernel release"
> > help
> > diff --git a/scripts/cc-system-headers.sh b/scripts/cc-system-headers.sh
> > new file mode 100755
> > index ..1b3db369828c
> > --- /dev/null
> > +++ b/scripts/cc-system-headers.sh
> > @@ -0,0 +1,8 @@
> > +#!/bin/sh
> > +# SPDX-License-Identifier:
Re: [PATCH] Staging: most: fix coding style issues
On Sat, 2019-06-29 at 16:44 -0700, Gabriel Beauchamp wrote:
> This is a patch for the core.[ch] files that fixes up warnings
> found with the checkpatch.pl tool.
[]
> diff --git a/drivers/staging/most/core.c b/drivers/staging/most/core.c
[]
> @@ -303,7 +303,8 @@ static ssize_t set_datatype_show(struct device *dev,
>
> for (i = 0; i < ARRAY_SIZE(ch_data_type); i++) {
> if (c->cfg.data_type & ch_data_type[i].most_ch_data_type)
> - return snprintf(buf, PAGE_SIZE, "%s",
> ch_data_type[i].name);
> + return snprintf(buf, PAGE_SIZE,
> + "%s", ch_data_type[i].name);
> }
> return snprintf(buf, PAGE_SIZE, "unconfigured\n");
> }
Assuming the newline difference is unintentional,
(if not change "unconfigured" to "unconfigured\n")
How about using a single sprintf and reducing object code size too?
char *type = "unconfigured";
for (...)
if (c-> etc...) {
type = ch_data_type[i].name;
break;
}
}
return snprintf(buf, PAGE_SIZE, "%s", type);
Re: [PATCH V33 24/30] bpf: Restrict bpf when kernel lockdown is in confidentiality mode
On Fri, Jun 28, 2019 at 11:47 AM Matthew Garrett wrote: > > On Thu, Jun 27, 2019 at 4:27 PM Andy Lutomirski wrote: > > They're really quite similar in my mind. Certainly some things in the > > "integrity" category give absolutely trivial control over the kernel > > (e.g. modules) while others make it quite challenging (ioperm), but > > the end result is very similar. And quite a few "confidentiality" > > things genuinely do allow all kernel memory to be read. > > > > I agree that finer-grained distinctions could be useful. My concern is > > that it's a tradeoff, and the other end of the tradeoff is an ABI > > stability issue. If someone decides down the road that some feature > > that is currently "integrity" can be split into a narrow "integrity" > > feature and a "confidentiality" feature then, if the user policy knows > > about the individual features, there's a risk of breaking people's > > systems. If we keep the fine-grained control, do we have a clear > > compatibility story? > > My preference right now is to retain the fine-grained aspect of things > in the internal API, simply because it'll be more annoying to add it > back later if we want to. I don't want to expose it via the Lockdown > user facing API for the reasons you've described, but it's not > impossible that another LSM would find a way to do this reasonably. > Does it seem reasonable to punt this discussion out to the point where > another LSM tries to do something with this information, based on the > implementation they're attempting? I think I can get behind this, as long as it's clear to LSM authors that this list is only a little bit stable. I can certainly see the use for the fine-grained info being available for auditing.
[PATCH] Staging: most: fix coding style issues
This is a patch for the core.[ch] files that fixes up warnings
found with the checkpatch.pl tool.
Signed-off-by: Gabriel Beauchamp
---
drivers/staging/most/core.c | 4 +++-
drivers/staging/most/core.h | 2 +-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/most/core.c b/drivers/staging/most/core.c
index 86a8545c8d97..f49c550ed48e 100644
--- a/drivers/staging/most/core.c
+++ b/drivers/staging/most/core.c
@@ -303,7 +303,8 @@ static ssize_t set_datatype_show(struct device *dev,
for (i = 0; i < ARRAY_SIZE(ch_data_type); i++) {
if (c->cfg.data_type & ch_data_type[i].most_ch_data_type)
- return snprintf(buf, PAGE_SIZE, "%s",
ch_data_type[i].name);
+ return snprintf(buf, PAGE_SIZE,
+ "%s", ch_data_type[i].name);
}
return snprintf(buf, PAGE_SIZE, "unconfigured\n");
}
@@ -728,6 +729,7 @@ int most_add_link(char *mdev, char *mdev_ch, char
*comp_name, char *link_name,
return link_channel_to_component(c, comp, link_name, comp_param);
}
+
/**
* remove_link_store - store function for remove_link attribute
* @drv: device driver
diff --git a/drivers/staging/most/core.h b/drivers/staging/most/core.h
index 652aaa771029..6ba7c2b34c1c 100644
--- a/drivers/staging/most/core.h
+++ b/drivers/staging/most/core.h
@@ -1,4 +1,4 @@
-// SPDX-License-Identifier: GPL-2.0
+/* SPDX-License-Identifier: GPL-2.0 */
/*
* most.h - API for component and adapter drivers
*
--
2.21.0
Re: [RFC PATCH 3/3] Prevent user from writing to IBT bitmap.
On Fri, Jun 28, 2019 at 12:50 PM Yu-cheng Yu wrote:
>
> The IBT bitmap is visiable from user-mode, but not writable.
>
> Signed-off-by: Yu-cheng Yu
>
> ---
> arch/x86/mm/fault.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
> index 59f4f66e4f2e..231196abb62e 100644
> --- a/arch/x86/mm/fault.c
> +++ b/arch/x86/mm/fault.c
> @@ -1454,6 +1454,13 @@ void do_user_addr_fault(struct pt_regs *regs,
> * we can handle it..
> */
> good_area:
> +#define USER_MODE_WRITE (FAULT_FLAG_WRITE | FAULT_FLAG_USER)
> + if (((flags & USER_MODE_WRITE) == USER_MODE_WRITE) &&
> + (vma->vm_flags & VM_IBT)) {
> + bad_area_access_error(regs, hw_error_code, address, vma);
> + return;
> + }
> +
Just make the VMA have VM_WRITE and VM_MAYWRITE clear. No new code
like this should be required.
Re: d_lookup: Unable to handle kernel paging request
On Tuesday, June 25, 2019 12:48:17 PM CEST, Vicente Bergas wrote: On Tuesday, June 25, 2019 11:46:02 AM CEST, Will Deacon wrote: [+Marc] Hi again, Vicente, On Mon, Jun 24, 2019 at 12:47:41PM +0100, Will Deacon wrote: ... Hi Will, the memtest test is still pending... Hi Will, i've just ran that memtest and no issues have been found. See below. I've also noticed that this is running very early, hence the 'earlycon'. Because of this i wondered if it was run with interrupts disabled, and indeed this is the case, am i wrong? If the kernel before kexec is corrupting memory for the currently running kernel, which entry point does it have, besides interrupts? Or can the corruption come through DMA from a peripheral? Has kexec ever worked reliably on this board? Yes, more or less. I have experienced some issues that could be caused because of this, like sometimes on-screen flickering or failing to boot once every 20 or 30 tries. But recently this d_lookup issue appeared and it is a show-stopper. This way of booting is used on both the sapphire board and on kevin. The bootloader is https://gitlab.com/vicencb/kevinboot (not up to date) and a similar one for the sapphire board. Regards, Vicenç. Booting Linux on physical CPU 0x00 [0x410fd034] Linux version 5.2.0-rc6 (local@host) (gcc version 8.3.0 (GCC)) #1 SMP @0 Machine model: Sapphire-RK3399 Board earlycon: uart0 at MMIO32 0xff1a (options '150n8') printk: bootconsole [uart0] enabled early_memtest: # of tests: 17 0x0020 - 0x0028 pattern 4c494e5558726c7a 0x00b62000 - 0x00b65000 pattern 4c494e5558726c7a 0x00b7665f - 0xf77e8a58 pattern 4c494e5558726c7a 0xf77e8a87 - 0xf77e8a88 pattern 4c494e5558726c7a 0xf77e8ab7 - 0xf77e8ab8 pattern 4c494e5558726c7a 0xf77e8ae7 - 0xf77e8ae8 pattern 4c494e5558726c7a 0xf77e8b17 - 0xf77e8b18 pattern 4c494e5558726c7a 0xf77e8b47 - 0xf77e8b48 pattern 4c494e5558726c7a 0xf77e8b74 - 0xf77e8b78 pattern 4c494e5558726c7a 0xf77e8ba4 - 0xf77e8ba8 pattern 4c494e5558726c7a 0xf77e8bd4 - 0xf77e8bd8 pattern 4c494e5558726c7a 0xf77e8c04 - 0xf77e8c08 pattern 4c494e5558726c7a 0xf77e8c34 - 0xf77e8c38 pattern 4c494e5558726c7a 0xf77e8c64 - 0xf77e8c68 pattern 4c494e5558726c7a 0xf77e8c94 - 0xf77e8c98 pattern 4c494e5558726c7a 0xf77e8cc4 - 0xf77e8cc8 pattern 4c494e5558726c7a 0xf77e8cf4 - 0xf77e8cf8 pattern 4c494e5558726c7a 0xf77e8d29 - 0xf77e8d30 pattern 4c494e5558726c7a 0x0020 - 0x0028 pattern 0x00b62000 - 0x00b65000 pattern 0x00b7665f - 0xf77e8a58 pattern 0xf77e8a87 - 0xf77e8a88 pattern 0xf77e8ab7 - 0xf77e8ab8 pattern 0xf77e8ae7 - 0xf77e8ae8 pattern 0xf77e8b17 - 0xf77e8b18 pattern 0xf77e8b47 - 0xf77e8b48 pattern 0xf77e8b74 - 0xf77e8b78 pattern 0xf77e8ba4 - 0xf77e8ba8 pattern 0xf77e8bd4 - 0xf77e8bd8 pattern 0xf77e8c04 - 0xf77e8c08 pattern 0xf77e8c34 - 0xf77e8c38 pattern 0xf77e8c64 - 0xf77e8c68 pattern 0xf77e8c94 - 0xf77e8c98 pattern 0xf77e8cc4 - 0xf77e8cc8 pattern 0xf77e8cf4 - 0xf77e8cf8 pattern 0xf77e8d29 - 0xf77e8d30 pattern 0x0020 - 0x0028 pattern 0x00b62000 - 0x00b65000 pattern 0x00b7665f - 0xf77e8a58 pattern 0xf77e8a87 - 0xf77e8a88 pattern 0xf77e8ab7 - 0xf77e8ab8 pattern 0xf77e8ae7 - 0xf77e8ae8 pattern 0xf77e8b17 - 0xf77e8b18 pattern 0xf77e8b47 - 0xf77e8b48 pattern 0xf77e8b74 - 0xf77e8b78 pattern 0xf77e8ba4 - 0xf77e8ba8 pattern 0xf77e8bd4 - 0xf77e8bd8 pattern 0xf77e8c04 - 0xf77e8c08 pattern 0xf77e8c34 - 0xf77e8c38 pattern 0xf77e8c64 - 0xf77e8c68 pattern 0xf77e8c94 - 0xf77e8c98 pattern 0xf77e8cc4 - 0xf77e8cc8 pattern 0xf77e8cf4 - 0xf77e8cf8 pattern
Re: shrink_dentry_list() logics change (was Re: [RFC PATCH v3 14/15] dcache: Implement partial shrink via Slab Movable Objects)
On Sat, Jun 29, 2019 at 11:29:45PM +0100, Al Viro wrote:
> Like this (again, only build-tested):
... and with obvious braino fixed,
Teach shrink_dcache_parent() to cope with mixed-filesystem shrink lists
Currently, running into a shrink list that contains dentries from different
filesystems can cause several unpleasant things for shrink_dcache_parent()
and for umount(2).
The first problem is that there's a window during shrink_dentry_list() between
__dentry_kill() takes a victim out and dropping reference to its parent. During
that window the parent looks like a genuine busy dentry. shrink_dcache_parent()
(or, worse yet, shrink_dcache_for_umount()) coming at that time will see no
eviction candidates and no indication that it needs to wait for some
shrink_dentry_list() to proceed further.
That applies for any shrink list that might intersect with the subtree we are
trying to shrink; the only reason it does not blow on umount(2) in the mainline
is that we unregister the memory shrinker before hitting
shrink_dcache_for_umount().
Another problem happens if something in a mixed-filesystem shrink list gets
be stuck in e.g. iput(), getting umount of unrelated fs to spin waiting for
the stuck shrinker to get around to our dentries.
Solution:
1) have shrink_dentry_list() decrement the parent's refcount and
make sure it's on a shrink list (ours unless it already had been on some
other) before calling __dentry_kill(). That eliminates the window when
shrink_dcache_parent() would've blown past the entire subtree without
noticing anything with zero refcount not on shrink lists.
2) when shrink_dcache_parent() has found no eviction candidates,
but some dentries are still sitting on shrink lists, rather than
repeating the scan in hope that shrinkers have progressed, scan looking
for something on shrink lists with zero refcount. If such a thing is
found, grab rcu_read_lock() and stop the scan, with caller locking
it for eviction, dropping out of RCU and doing __dentry_kill(), with
the same treatment for parent as shrink_dentry_list() would do.
Note that right now mixed-filesystem shrink lists do not occur, so this
is not a mainline bug. Howevere, there's a bunch of uses for such
beasts (e.g. the "try and evict everything we can out of given page"
patches; there are potential uses in mount-related code, considerably
simplifying the life in fs/namespace.c, etc.)
Signed-off-by: Al Viro
---
diff --git a/fs/dcache.c b/fs/dcache.c
index 8136bda27a1f..4b50e09ee950 100644
--- a/fs/dcache.c
+++ b/fs/dcache.c
@@ -860,6 +860,32 @@ void dput(struct dentry *dentry)
}
EXPORT_SYMBOL(dput);
+static void __dput_to_list(struct dentry *dentry, struct list_head *list)
+__must_hold(>d_lock)
+{
+ if (dentry->d_flags & DCACHE_SHRINK_LIST) {
+ /* let the owner of the list it's on deal with it */
+ --dentry->d_lockref.count;
+ } else {
+ if (dentry->d_flags & DCACHE_LRU_LIST)
+ d_lru_del(dentry);
+ if (!--dentry->d_lockref.count)
+ d_shrink_add(dentry, list);
+ }
+}
+
+void dput_to_list(struct dentry *dentry, struct list_head *list)
+{
+ rcu_read_lock();
+ if (likely(fast_dput(dentry))) {
+ rcu_read_unlock();
+ return;
+ }
+ rcu_read_unlock();
+ if (!retain_dentry(dentry))
+ __dput_to_list(dentry, list);
+ spin_unlock(>d_lock);
+}
/* This must be called with d_lock held */
static inline void __dget_dlock(struct dentry *dentry)
@@ -1088,18 +1114,9 @@ static void shrink_dentry_list(struct list_head *list)
rcu_read_unlock();
d_shrink_del(dentry);
parent = dentry->d_parent;
+ if (parent != dentry)
+ __dput_to_list(parent, list);
__dentry_kill(dentry);
- if (parent == dentry)
- continue;
- /*
-* We need to prune ancestors too. This is necessary to prevent
-* quadratic behavior of shrink_dcache_parent(), but is also
-* expected to be beneficial in reducing dentry cache
-* fragmentation.
-*/
- dentry = parent;
- while (dentry && !lockref_put_or_lock(>d_lockref))
- dentry = dentry_kill(dentry);
}
}
@@ -1444,8 +1461,11 @@ int d_set_mounted(struct dentry *dentry)
struct select_data {
struct dentry *start;
+ union {
+ long found;
+ struct dentry *victim;
+ };
struct list_head dispose;
- int found;
};
static enum d_walk_ret select_collect(void *_data, struct dentry *dentry)
@@ -1477,6 +1497,37 @@ static enum d_walk_ret select_collect(void *_data,
struct dentry *dentry)
return ret;
}
+static enum d_walk_ret select_collect2(void *_data, struct dentry *dentry)
+{
+
Re: shrink_dentry_list() logics change (was Re: [RFC PATCH v3 14/15] dcache: Implement partial shrink via Slab Movable Objects)
On Sat, Jun 29, 2019 at 08:06:24PM +0100, Al Viro wrote:
> I wonder if after the "no evictable candidates, but something
> on other's shrink lists" we ought to do something along the
> lines of
> rcu_read_lock
> walk it, doing
> if dentry has zero refcount
> if it's not on a shrink list,
> move it to ours
> else
> store its address in 'victim'
> end the walk
> if no victim found
> rcu_read_unlock
> else
> lock victim for __dentry_kill
> rcu_read_unlock
> if it's still alive
> if it's not IS_ROOT
> if parent is not on shrink list
> decrement parent's refcount
> put it on our list
> else
> decrement parent's refcount
> __dentry_kill(victim)
> else
> unlock
> if our list is non-empty
> shrink_dentry_list on it
> in there...
Like this (again, only build-tested):
Teach shrink_dcache_parent() to cope with mixed-filesystem shrink lists
Currently, running into a shrink list that contains dentries from different
filesystems can cause several unpleasant things for shrink_dcache_parent()
and for umount(2).
The first problem is that there's a window during shrink_dentry_list() between
__dentry_kill() takes a victim out and dropping reference to its parent. During
that window the parent looks like a genuine busy dentry. shrink_dcache_parent()
(or, worse yet, shrink_dcache_for_umount()) coming at that time will see no
eviction candidates and no indication that it needs to wait for some
shrink_dentry_list() to proceed further.
That applies for any shrink list that might intersect with the subtree we are
trying to shrink; the only reason it does not blow on umount(2) in the mainline
is that we unregister the memory shrinker before hitting
shrink_dcache_for_umount().
Another problem happens if something in a mixed-filesystem shrink list gets
be stuck in e.g. iput(), getting umount of unrelated fs to spin waiting for
the stuck shrinker to get around to our dentries.
Solution:
1) have shrink_dentry_list() decrement the parent's refcount and
make sure it's on a shrink list (ours unless it already had been on some
other) before calling __dentry_kill(). That eliminates the window when
shrink_dcache_parent() would've blown past the entire subtree without
noticing anything with zero refcount not on shrink lists.
2) when shrink_dcache_parent() has found no eviction candidates,
but some dentries are still sitting on shrink lists, rather than
repeating the scan in hope that shrinkers have progressed, scan looking
for something on shrink lists with zero refcount. If such a thing is
found, grab rcu_read_lock() and stop the scan, with caller locking
it for eviction, dropping out of RCU and doing __dentry_kill(), with
the same treatment for parent as shrink_dentry_list() would do.
Note that right now mixed-filesystem shrink lists do not occur, so this
is not a mainline bug. Howevere, there's a bunch of uses for such
beasts (e.g. the "try and evict everything we can out of given page"
patches; there are potential uses in mount-related code, considerably
simplifying the life in fs/namespace.c, etc.)
Signed-off-by: Al Viro
---
diff --git a/fs/dcache.c b/fs/dcache.c
index 8136bda27a1f..43480f516329 100644
--- a/fs/dcache.c
+++ b/fs/dcache.c
@@ -860,6 +860,32 @@ void dput(struct dentry *dentry)
}
EXPORT_SYMBOL(dput);
+static void __dput_to_list(struct dentry *dentry, struct list_head *list)
+__must_hold(>d_lock)
+{
+ if (dentry->d_flags & DCACHE_SHRINK_LIST) {
+ /* let the owner of the list it's on deal with it */
+ --dentry->d_lockref.count;
+ } else {
+ if (dentry->d_flags & DCACHE_LRU_LIST)
+ d_lru_del(dentry);
+ if (!--dentry->d_lockref.count)
+ d_shrink_add(dentry, list);
+ }
+}
+
+void dput_to_list(struct dentry *dentry, struct list_head *list)
+{
+ rcu_read_lock();
+ if (likely(fast_dput(dentry))) {
+ rcu_read_unlock();
+ return;
+ }
+ rcu_read_unlock();
+ if (!retain_dentry(dentry))
+ __dput_to_list(dentry, list);
+ spin_unlock(>d_lock);
+}
/* This must be called with d_lock held */
static inline void __dget_dlock(struct dentry *dentry)
@@ -1088,18 +1114,9 @@ static void shrink_dentry_list(struct list_head *list)
rcu_read_unlock();
d_shrink_del(dentry);
parent = dentry->d_parent;
+ if (parent != dentry)
+
Re: [PATCH 4/6] ACPI: LPSS: Fix ->suspend_late callbacks handling
On Sat, Jun 29, 2019 at 1:34 PM Hans de Goede wrote:
>
> Hi Rafael,
>
> On 29-06-19 11:50, Rafael J. Wysocki wrote:
> > From: Rafael J. Wysocki
> >
> > If the resume_from_noirq flag is set in dev_desc, the ->suspend_late
> > callback provided by the device driver will be invoked at the "noirq"
> > stage of system suspend, via acpi_lpss_do_suspend_late(), which is
> > incorrect.
> >
> > To fix that, drop acpi_lpss_do_suspend_late() and rearrange
> > acpi_lpss_suspend_late() to call pm_generic_suspend_late()
> > directly, before calling acpi_lpss_suspend(), in analogy with
> > acpi_subsys_suspend_late().
>
> Ah now I see the logic in your previous test-patch.
>
> I'm afraid that this is going to break things though, the calling
> of the device-driver's suspend-late method at noirq time is
> *intentional* !
But it is a bug too.
> The resume_from_noirq flag is only set for i2c controllers which
> use: drivers/i2c/busses/i2c-designware-platdrv.c as driver.
>
> This driver's suspend late method looks like this:
>
> static int dw_i2c_plat_suspend(struct device *dev)
> {
> struct dw_i2c_dev *i_dev = dev_get_drvdata(dev);
>
> i_dev->suspended = true;
>
> if (i_dev->shared_with_punit)
> return 0;
>
> i_dev->disable(i_dev);
> i2c_dw_prepare_clk(i_dev, false);
>
> return 0;
> }
>
> The i_dev->disable(i_dev) and i2c_dw_prepare_clk(i_dev, false) calls here
> will make the i2c controller non functional. But (some of) these i2c
> controllers are used by code in the _PS0 / _PS3 methods of some PCI
> devices and the PCI core calls _PS0 / _PS3 at *noirq* time, so as explained
> in the commit message which introduced acpi_lpss_do_suspend_late():
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=48402cee6889fb3fce58e95fea1471626286dc63
>
> We must not only make sure that the suspending of the i2c controller is
> ordered so that it happens after these PCI devices are suspended, we must
> also make sure that the i2c controller stays functional until the
> i2c-controller is put in the suspend-noirq state.
>
> If you really want to go this route, we must duplicate the resume_from_noirq
> flag inside drivers/i2c/busses/i2c-designware-platdrv.c, setting it
> only for acpi_lpss enumerated devices (the driver handles a whole lot more
> devices) ans then make the driver's suspend_late method a no-op and instead
> to the suspend from its suspend_noirq callback.
>
> Since pm_generic_suspend_late() is just a wrapper to call
> dev->driver->pm->suspend_late
> duplicating the resume_from_noirq flag inside i2c-designware-platdrv.c seems
> unproductive.
>
> Note that we have the same thing going on in acpi_lpss.c with resume_early vs
> resume_noirq, we call the resume_early callback from acpi_lpss_resume_noirq
> if the resume_from_noirq flag is set.
>
> TL;DR: the behavior you are trying to fix here is intentional and
> IMHO this patch should be dropped.
I can drop the patch, but the current code is simply incorrect.
If the driver provided a ->suspend_late callback, it wanted that
callback to be invoked during the "late" stage of suspend. Calling it
later simply papers over a driver bug. If invoking that callback
during the "late" stage doesn't work, the driver should have provided
a "noirq" callback instead.
> I guess we could / should do a patch adding a comment that the calling
> the drivers' suspend_late / resume_early callback at noirq time is intentional
> to avoid this confusing people in the future.
No. We need to fix drivers doing wrong things.
Thanks!
Re: [PATCH V5 08/18] clk: tegra: Add suspend resume support for DFLL
29.06.2019 16:28, Dmitry Osipenko пишет:
> 28.06.2019 5:12, Sowjanya Komatineni пишет:
>> This patch creates APIs for supporting Tegra210 clock driver to
>> perform DFLL suspend and resume operation.
>>
>> During suspend, DFLL mode is saved and on resume Tegra210 clock driver
>> invokes DFLL resume API to re-initialize DFLL to enable target device
>> clock in open loop mode or closed loop mode.
>>
>> Acked-by: Thierry Reding
>> Signed-off-by: Sowjanya Komatineni
>> ---
>> drivers/clk/tegra/clk-dfll.c | 78
>>
>> drivers/clk/tegra/clk-dfll.h | 2 ++
>> 2 files changed, 80 insertions(+)
>>
>> diff --git a/drivers/clk/tegra/clk-dfll.c b/drivers/clk/tegra/clk-dfll.c
>> index f8688c2ddf1a..a1f37cf99b00 100644
>> --- a/drivers/clk/tegra/clk-dfll.c
>> +++ b/drivers/clk/tegra/clk-dfll.c
>> @@ -277,6 +277,7 @@ struct tegra_dfll {
>> unsigned long dvco_rate_min;
>>
>> enum dfll_ctrl_mode mode;
>> +enum dfll_ctrl_mode resume_mode;
>> enum dfll_tune_rangetune_range;
>> struct dentry *debugfs_dir;
>> struct clk_hw dfll_clk_hw;
>> @@ -1864,6 +1865,83 @@ static int dfll_fetch_common_params(struct tegra_dfll
>> *td)
>> }
>>
>> /*
>> + * tegra_dfll_suspend
>> + * @pdev: DFLL instance
>> + *
>> + * dfll controls clock/voltage to other devices, including CPU. Therefore,
>> + * dfll driver pm suspend callback does not stop cl-dvfs operations.
>> + */
>> +void tegra_dfll_suspend(struct platform_device *pdev)
>> +{
>> +struct tegra_dfll *td = dev_get_drvdata(>dev);
>> +
>> +if (!td)
>> +return;
>> +
>> +if (td->mode <= DFLL_DISABLED)
>> +return;
>> +
>> +td->resume_mode = td->mode;
>> +switch (td->mode) {
>> +case DFLL_CLOSED_LOOP:
>> +dfll_set_mode(td, DFLL_CLOSED_LOOP);
>> +dfll_set_frequency_request(td, >last_req);
>> +
>> +dfll_unlock(td);
>> +break;
>> +default:
>> +break;
>> +}
>> +}
>> +
>> +/**
>> + * tegra_dfll_resume - reprogram the DFLL after context-loss
>> + * @pdev: DFLL instance
>> + *
>> + * Re-initialize and enable target device clock in open loop mode. Called
>> + * directly from SoC clock resume syscore operation. Closed loop will be
>> + * re-entered in platform syscore ops as well after CPU clock source is
>> + * switched to DFLL in open loop.
>> + */
>> +void tegra_dfll_resume(struct platform_device *pdev, bool on_dfll)
>> +{
>> +struct tegra_dfll *td = dev_get_drvdata(>dev);
>> +
>> +if (!td)
>> +return;
>> +
>> +if (on_dfll) {
>> +if (td->resume_mode == DFLL_CLOSED_LOOP)
>> +dfll_lock(td);
>> +td->resume_mode = DFLL_DISABLED;
>> +return;
>> +}
>> +
>> +reset_control_deassert(td->dvco_rst);
>> +
>> +pm_runtime_get(td->dev);
>
> pm_runtime_get_sync()?
>
> Otherwise looks like you're risking a lot here because pm_runtime_get() is an
> asynchronous request.
It looks like DFLL driver should be masked as IRQ-safe using
pm_runtime_irq_safe()
and then the synchronous resume could be used..
[PATCH] ftrace/x86: anotate text_mutex split between ftrace_arch_code_modify_post_process() and ftrace_arch_code_modify_prepare()
From: Jiri Kosina
ftrace_arch_code_modify_prepare() is acquiring text_mutex, while the
corresponding release is happening in ftrace_arch_code_modify_post_process().
This has already been documented in the code, but let's also make the fact
that this is intentional clear to the semantic analysis tools such as sparse.
Fixes: 39611265edc1a ("ftrace/x86: Add a comment to why we take text_mutex in
ftrace_arch_code_modify_prepare()")
Fixes: d5b844a2cf507 ("ftrace/x86: Remove possible deadlock between
register_kprobe() and ftrace_run_update_code()")
Signed-off-by: Jiri Kosina
---
arch/x86/kernel/ftrace.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/x86/kernel/ftrace.c b/arch/x86/kernel/ftrace.c
index d7e93b2783fd..76228525acd0 100644
--- a/arch/x86/kernel/ftrace.c
+++ b/arch/x86/kernel/ftrace.c
@@ -35,6 +35,7 @@
#ifdef CONFIG_DYNAMIC_FTRACE
int ftrace_arch_code_modify_prepare(void)
+__acquires(_mutex)
{
/*
* Need to grab text_mutex to prevent a race from module loading
@@ -48,6 +49,7 @@ int ftrace_arch_code_modify_prepare(void)
}
int ftrace_arch_code_modify_post_process(void)
+__releases(_mutex)
{
set_all_modules_text_ro();
set_kernel_text_ro();
--
Jiri Kosina
SUSE Labs
Re: [PATCH] ftrace: Remove possible deadlock between register_kprobe() and ftrace_run_update_code()
On Sat, 29 Jun 2019 22:56:47 +0200 (CEST) Jiri Kosina wrote: > > Care to send a patch? :-) > > From: Jiri Kosina > Subject: [PATCH] ftrace/x86: anotate text_mutex split between > ftrace_arch_code_modify_post_process() and ftrace_arch_code_modify_prepare() Care to send a proper patch ;-) As in, a separate email. Makes it much easier to apply directly with my scripts. -- Steve
[PATCH] tools/memory-model: Update the informal documentation
The formal memory consistency model has added support for plain accesses (and data races). While updating the informal documentation to describe this addition to the model is highly desirable and important future work, update the informal documentation to at least acknowledge such addition. Signed-off-by: Andrea Parri Cc: Alan Stern Cc: Will Deacon Cc: Peter Zijlstra Cc: Boqun Feng Cc: Nicholas Piggin Cc: David Howells Cc: Jade Alglave Cc: Luc Maranget Cc: "Paul E. McKenney" Cc: Akira Yokosawa Cc: Daniel Lustig --- tools/memory-model/Documentation/explanation.txt | 47 +++- tools/memory-model/README| 18 - 2 files changed, 30 insertions(+), 35 deletions(-) diff --git a/tools/memory-model/Documentation/explanation.txt b/tools/memory-model/Documentation/explanation.txt index 68caa9a976d0c..b42f7cd718242 100644 --- a/tools/memory-model/Documentation/explanation.txt +++ b/tools/memory-model/Documentation/explanation.txt @@ -42,7 +42,8 @@ linux-kernel.bell and linux-kernel.cat files that make up the formal version of the model; they are extremely terse and their meanings are far from clear. -This document describes the ideas underlying the LKMM. It is meant +This document describes the ideas underlying the LKMM, but excluding +the modeling of bare C (or plain) shared memory accesses. It is meant for people who want to understand how the model was designed. It does not go into the details of the code in the .bell and .cat files; rather, it explains in English what the code expresses symbolically. @@ -354,31 +355,25 @@ be extremely complex. Optimizing compilers have great freedom in the way they translate source code to object code. They are allowed to apply transformations that add memory accesses, eliminate accesses, combine them, split them -into pieces, or move them around. Faced with all these possibilities, -the LKMM basically gives up. It insists that the code it analyzes -must contain no ordinary accesses to shared memory; all accesses must -be performed using READ_ONCE(), WRITE_ONCE(), or one of the other -atomic or synchronization primitives. These primitives prevent a -large number of compiler optimizations. In particular, it is -guaranteed that the compiler will not remove such accesses from the -generated code (unless it can prove the accesses will never be -executed), it will not change the order in which they occur in the -code (within limits imposed by the C standard), and it will not -introduce extraneous accesses. - -This explains why the MP and SB examples above used READ_ONCE() and -WRITE_ONCE() rather than ordinary memory accesses. Thanks to this -usage, we can be certain that in the MP example, P0's write event to -buf really is po-before its write event to flag, and similarly for the -other shared memory accesses in the examples. - -Private variables are not subject to this restriction. Since they are -not shared between CPUs, they can be accessed normally without -READ_ONCE() or WRITE_ONCE(), and there will be no ill effects. In -fact, they need not even be stored in normal memory at all -- in -principle a private variable could be stored in a CPU register (hence -the convention that these variables have names starting with the -letter 'r'). +into pieces, or move them around. The use of READ_ONCE(), WRITE_ONCE(), +or one of the other atomic or synchronization primitives prevents a +large number of compiler optimizations. In particular, it is guaranteed +that the compiler will not remove such accesses from the generated code +(unless it can prove the accesses will never be executed), it will not +change the order in which they occur in the code (within limits imposed +by the C standard), and it will not introduce extraneous accesses. + +The MP and SB examples above used READ_ONCE() and WRITE_ONCE() rather +than ordinary memory accesses. Thanks to this usage, we can be certain +that in the MP example, the compiler won't reorder P0's write event to +buf and P0's write event to flag, and similarly for the other shared +memory accesses in the examples. + +Since private variables are not shared between CPUs, they can be +accessed normally without READ_ONCE() or WRITE_ONCE(). In fact, they +need not even be stored in normal memory at all -- in principle a +private variable could be stored in a CPU register (hence the convention +that these variables have names starting with the letter 'r'). A WARNING diff --git a/tools/memory-model/README b/tools/memory-model/README index 2b87f3971548c..fc07b52f20286 100644 --- a/tools/memory-model/README +++ b/tools/memory-model/README @@ -167,15 +167,15 @@ scripts Various scripts, see scripts/README. LIMITATIONS === -The Linux-kernel memory model has the following limitations: - -1. Compiler optimizations are not modeled. Of course, the use - of READ_ONCE() and WRITE_ONCE() limits the compiler's ability - to optimize, but there is
Re: KASAN: use-after-free Write in xfrm_hash_rebuild
syzbot has bisected this bug to:
commit 1548bc4e0512700cf757192c106b3a20ab639223
Author: Florian Westphal
Date: Fri Jan 4 13:17:02 2019 +
xfrm: policy: delete inexact policies from inexact list on hash rebuild
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=1734cba9a0
start commit: 249155c2 Merge branch 'parisc-5.2-4' of git://git.kernel.o..
git tree: upstream
final crash:https://syzkaller.appspot.com/x/report.txt?x=14b4cba9a0
console output: https://syzkaller.appspot.com/x/log.txt?x=10b4cba9a0
kernel config: https://syzkaller.appspot.com/x/.config?x=9a31528e58cc12e2
dashboard link: https://syzkaller.appspot.com/bug?extid=0165480d4ef07360eeda
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=16cf37c3a0
Reported-by: syzbot+0165480d4ef07360e...@syzkaller.appspotmail.com
Fixes: 1548bc4e0512 ("xfrm: policy: delete inexact policies from inexact
list on hash rebuild")
For information about bisection process see: https://goo.gl/tpsmEJ#bisection
Re: [RFC PATCH v2 1/2] printk-rb: add a new printk ringbuffer implementation
> /**
> * add_descr_list() - Add a descriptor to the descriptor list.
> *
> * @e: An entry that has already reserved data.
> *
> * The provided entry contains a pointer to a descriptor that has already
> * been reserved for this entry. However, the reserved descriptor is not
> * yet on the list. Add this descriptor as the newest item.
> *
> * A descriptor is added in two steps. The first step is to make this
> * descriptor the newest. The second step is to update @next of the former
> * newest descriptor to point to this one (or set @oldest to this one if
> * this will be the first descriptor on the list).
> */
> static void add_descr_list(struct prb_reserved_entry *e)
> {
> struct printk_ringbuffer *rb = e->rb;
> struct prb_list *l = >descr_list;
> struct prb_descr *d = e->descr;
> struct prb_descr *newest_d;
> unsigned long newest_id;
>
> WRITE_ONCE(d->next, EOL);
/* C */
>
> do {
> newest_id = READ_ONCE(l->newest);
/* A */
> newest_d = TO_DESC(rb, newest_id);
>
> if (newest_id == EOL) {
> WRITE_ONCE(d->seq, 1);
> } else {
> /*
>* MB5-read: synchronize setting newest descr
>*
>* context-pair: 2 writers adding a descriptor via
>* add_descr_list().
>*
>* @newest will load before @seq due to a data
>* dependency, therefore, the stores of @seq
>* and @next from the pairing MB5-write context
>* will be visible.
>*
>* Although @next is not loaded by this context,
>* this context must overwrite the stored @next
>* value of the pairing MB5-write context.
>*/
> WRITE_ONCE(d->seq, READ_ONCE(newest_d->seq) + 1);
/* B: this READ_ONCE() */
Hence you're claiming a data dependency from A to B. (FWIW, the LKMM
would call "A ->dep B" an "address dependency.)
This comment also claims that the "pairing MB5-write" orders "stores
of @seq and @next" (which are to different memory locations w.r.t. A
and B): I do not get why this access to @next (C above?, that's also
"unordered" w.r.t. A) can be relevant; can you elaborate?
> }
>
> /*
>* MB5-write: synchronize setting newest descr
>*
>* context-pair: 2 writers adding a descriptor via
>* add_descr_list().
>*
>* Ensure that @next and @seq are stored before @d is
>* visible via @newest. The pairing MB5-read context
>* must load this @seq value and must overwrite this
>* @next value.
>*/
> } while (cmpxchg_release(>newest, newest_id, e->id) != newest_id);
>
> if (unlikely(newest_id == EOL)) {
> /*
>* MB0-write: synchronize adding first descr
>*
>* context-pair: 1 writer adding the first descriptor via
>* add_descr_list(), 1 reader getting the beginning of
>* the list via iter_peek_next_id().
>*
>* This context recently assigned new values for @id,
>* @next, @seq. Ensure these are stored before the first
>* store to @oldest so that the new values are visible
>* to the reader in the pairing MB0-read context.
>*
>* Note: Before this store, the value of @oldest is EOL.
>*/
My gmail-search foo is unable to locate MB0-read: what am I missing?
Also, can you maybe annotate the memory accesses to @id, @next, @seq
and @oldest (as I did above)? I find myself guessing their location.
> smp_store_release(>oldest, e->id);
> } else {
> /*
>* MB6-write: synchronize linking new descr
>*
>* context-pair-1: 1 writer adding a descriptor via
>* add_descr_list(), 1 writer removing a descriptor via
>* remove_oldest_descr().
>*
>* If this is a recycled descriptor, this context
>* recently stored a new @oldest value. Ensure that
>* @oldest is stored before storing @next so that
>* if the pairing MB6-read context sees a non-EOL
>* @next value, it is ensured that it will also see
>* an updated @oldest value.
>*
>* context-pair-2: 1 writer adding a descriptor via
>* add_descr_list(), 1 reader iterating the list via
>* prb_iter_next_valid_entry().
>*
>*
Re: [PATCH] ftrace: Remove possible deadlock between register_kprobe() and ftrace_run_update_code()
On Fri, 28 Jun 2019, Steven Rostedt wrote:
> > > > How is that supposed to work?
> > > >
> > > > ftrace
> > > > prepare()
> > > > setrw()
> > > > setro()
> > > > patch <- FAIL
> > >
> > > /me dodges frozen shark
> > >
> > > You are right of course. My brain has apparently already shut off for
> > > the day.
> > >
> > > Maybe a comment or two would help though.
> >
> > I'd actually prefer (perhaps in parallel to the comment) using the
> > __acquires() and __releases() anotations, so that sparse and friends don't
> > get confused by that either.
> >
>
> Care to send a patch? :-)
From: Jiri Kosina
Subject: [PATCH] ftrace/x86: anotate text_mutex split between
ftrace_arch_code_modify_post_process() and ftrace_arch_code_modify_prepare()
ftrace_arch_code_modify_prepare() is acquiring text_mutex, while the
corresponding release is happening in ftrace_arch_code_modify_post_process().
This has already been documented in the code, but let's also make the fact
that this is intentional clear to the semantic analysis tools such as
sparse.
Fixes: 39611265edc1a ("ftrace/x86: Add a comment to why we take text_mutex in
ftrace_arch_code_modify_prepare()")
Fixes: d5b844a2cf507 ("ftrace/x86: Remove possible deadlock between
register_kprobe() and ftrace_run_update_code()")
Signed-off-by: Jiri Kosina
---
arch/x86/kernel/ftrace.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/x86/kernel/ftrace.c b/arch/x86/kernel/ftrace.c
index d7e93b2783fd..76228525acd0 100644
--- a/arch/x86/kernel/ftrace.c
+++ b/arch/x86/kernel/ftrace.c
@@ -35,6 +35,7 @@
#ifdef CONFIG_DYNAMIC_FTRACE
int ftrace_arch_code_modify_prepare(void)
+__acquires(_mutex)
{
/*
* Need to grab text_mutex to prevent a race from module loading
@@ -48,6 +49,7 @@ int ftrace_arch_code_modify_prepare(void)
}
int ftrace_arch_code_modify_post_process(void)
+__releases(_mutex)
{
set_all_modules_text_ro();
set_kernel_text_ro();
--
Jiri Kosina
SUSE Labs
Re: [PATCH] vfs: move_mount: reject moving kernel internal mounts
On Sat, Jun 29, 2019 at 01:27:44PM -0700, Eric Biggers wrote: > @@ -2600,7 +2600,7 @@ static int do_move_mount(struct path *old_path, struct > path *new_path) > if (attached && !check_mnt(old)) > goto out; > > - if (!attached && !(ns && is_anon_ns(ns))) > + if (!attached && !(ns && ns != MNT_NS_INTERNAL && is_anon_ns(ns))) > goto out; > > if (old->mnt.mnt_flags & MNT_LOCKED) *UGH* Applied, but that code is getting really ugly ;-/
Re: general protection fault in do_move_mount (2)
On Mon, Jun 24, 2019 at 11:28:18AM +0200, 'Dmitry Vyukov' via syzkaller-bugs
wrote:
> On Tue, Jun 18, 2019 at 4:03 PM Al Viro wrote:
> >
> > On Tue, Jun 18, 2019 at 03:47:10AM -0700, syzbot wrote:
> > > Hello,
> > >
> > > syzbot found the following crash on:
> > >
> > > HEAD commit:9e0babf2 Linux 5.2-rc5
> > > git tree: upstream
> > > console output: https://syzkaller.appspot.com/x/log.txt?x=138b310aa0
> > > kernel config: https://syzkaller.appspot.com/x/.config?x=d16883d6c7f0d717
> > > dashboard link:
> > > https://syzkaller.appspot.com/bug?extid=6004acbaa1893ad013f0
> > > compiler: gcc (GCC) 9.0.0 20181231 (experimental)
> > > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=154e8c2aa0
> >
> > IDGI...
> >
> > mkdir(&(0x7f632000)='./file0\x00', 0x0)
> > mount(0x0, 0x0, 0x0, 0x0, 0x0)
> > syz_open_procfs(0x0, 0x0)
> > r0 = open(&(0x7f032ff8)='./file0\x00', 0x0, 0x0)
> > r1 = memfd_create(&(0x7f0001c0)='\xb3', 0x0)
> > write$FUSE_DIRENT(r1, &(0x7f80)=ANY=[], 0x29)
> > move_mount(r0, &(0x7f40)='./file0\x00', 0xff9c,
> > &(0x7f000100)='./file0\x00', 0x66)
> >
> > reads as if we'd done mkdir ./file0, opened it and then tried
> > to feed move_mount(2) "./file0" relative to that descriptor.
> > How the hell has that avoided an instant -ENOENT? On the first
> > pair, that is - the second one (AT_FDCWD, "./file0") is fine...
> >
> > Confused... Incidentally, what the hell is
> > mount(0x0, 0x0, 0x0, 0x0, 0x0)
> > about? *IF* that really refers to mount(2) with
> > such arguments, all you'll get is -EFAULT. Way before
> > it gets to actually doing anything - it won't get past
> > /* ... and get the mountpoint */
> > retval = user_path(dir_name, );
> > if (retval)
> > return retval;
> > in do_mount(2)...
>
> Yes, mount(0x0, 0x0, 0x0, 0x0, 0x0) is mount with 0 arguments. Most
> likely it returns EFAULT.
> Since the reproducer have "threaded":true,"collide":true and no C
> repro, most likely this is a subtle race. So it attempted to remove
> mount(0x0, 0x0, 0x0, 0x0, 0x0) but it did not crash, so the conclusion
> was that it's somehow needed. You can actually see that other
> reproducers for this bug do not have this mount, but are otherwise
> similar.
>
> With "threaded":true,"collide":true the execution mode is not just
> "execute each syscall once one after another".
> The syscalls are executed in separate threads and actually twice. You
> can see the approximate execution mode in this C program:
> https://gist.githubusercontent.com/dvyukov/c3a52f012e7cff9bdebf3935d35245cf/raw/b5587824111a1d982c985b00137ae8609572335b/gistfile1.txt
> Yet using the C program did not trigger the crash somehow (maybe just
> slightly different timings).
>
> Since syzkaller was able to reproduce it multiple times, it looks like
> a real bug rather than an induced memory corruption or something.
>
I sent a patch to fix this bug
(https://lore.kernel.org/linux-fsdevel/20190629202744.12396-1-ebigg...@kernel.org/T/#u)
Dmitry, any idea why syzbot found such a bizarre reproducer for this?
This is actually reproducible by a simple single threaded program:
#include
#define __NR_move_mount 429
#define MOVE_MOUNT_F_EMPTY_PATH 0x0004
int main()
{
int fds[2];
pipe(fds);
syscall(__NR_move_mount, fds[0], "", -1, "/", MOVE_MOUNT_F_EMPTY_PATH);
}
FYI, it also isn't really appropriate for syzbot to bisect all bugs in new
syscalls to wiring them up to x86, and then blame all the x86 maintainers.
Normally such bugs will be in the syscall itself, regardless of architecture.
- Eric
Re: slub: don't panic for memcg kmem cache creation failure
On Sat, Jun 29, 2019 at 7:05 AM Alexey Dobriyan wrote:
>
> > - if (flags & SLAB_PANIC)
> > - panic("Cannot create slab %s size=%u realsize=%u order=%u
> > offset=%u flags=%lx\n",
> > - s->name, s->size, s->size,
> > - oo_order(s->oo), s->offset, (unsigned long)flags);
>
> This is wrong. Without SLAB_PANIC people will start to implement error
> checking out of habit and add all slightly different error messages.
> This simply increases text and rodata size.
>
> If memcg kmem caches creation failure is OK, then SLAB_PANIC should not
> be passed.
>
> The fact that SLAB doesn't implement SLAB_PANIC is SLAB bug.
I do not agree with you. IMHO the kmem_cache_create_usercopy() is the
right place to handle SLAB_PANIC which is handling it. If you want
extra info here, you can add pr_warn for SLAB_PANIC here and the
caller will still and rightfully do the panic().
thanks,
Shakeel
[PATCH] vfs: move_mount: reject moving kernel internal mounts
From: Eric Biggers
sys_move_mount() crashes by dereferencing the pointer MNT_NS_INTERNAL,
a.k.a. ERR_PTR(-EINVAL), if the old mount is specified by fd for a
kernel object with an internal mount, such as a pipe or memfd.
Fix it by checking for this case and returning -EINVAL.
Reproducer:
#include
#define __NR_move_mount 429
#define MOVE_MOUNT_F_EMPTY_PATH 0x0004
int main()
{
int fds[2];
pipe(fds);
syscall(__NR_move_mount, fds[0], "", -1, "/", MOVE_MOUNT_F_EMPTY_PATH);
}
Reported-by: syzbot+6004acbaa1893ad01...@syzkaller.appspotmail.com
Fixes: 2db154b3ea8e ("vfs: syscall: Add move_mount(2) to move mounts around")
Signed-off-by: Eric Biggers
---
fs/namespace.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/namespace.c b/fs/namespace.c
index 7660c2749c96..a7e5a44770a7 100644
--- a/fs/namespace.c
+++ b/fs/namespace.c
@@ -2600,7 +2600,7 @@ static int do_move_mount(struct path *old_path, struct
path *new_path)
if (attached && !check_mnt(old))
goto out;
- if (!attached && !(ns && is_anon_ns(ns)))
+ if (!attached && !(ns && ns != MNT_NS_INTERNAL && is_anon_ns(ns)))
goto out;
if (old->mnt.mnt_flags & MNT_LOCKED)
--
2.22.0
Re: [GIT PULL] smp/urgent fixes
* Ingo Molnar wrote: > Linus, > > Please pull the latest smp-urgent-for-linus git tree from: > >git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git > smp-urgent-for-linus > ># HEAD: 33d4a5a7a5b4d02915d765064b2319e90a11cbde cpu/hotplug: Fix > out-of-bounds read when setting fail state > > Two fixes: > > - Fix an out of bounds access when writing nonsensical values to >/sys/devices/system/cpu/cpuX/hotplug/fail > > - Warn about unsupported mitigations= parameters. Linus, please ignore this duplicate pull request. I thought Thomas didn't send this one yet, but he has a few hours ago but the Cc: to me was buggy so I didn't notice it at first. :-/ Thanks, Ingo
[GIT PULL] smp/urgent fixes
Linus,
Please pull the latest smp-urgent-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
smp-urgent-for-linus
# HEAD: 33d4a5a7a5b4d02915d765064b2319e90a11cbde cpu/hotplug: Fix
out-of-bounds read when setting fail state
Two fixes:
- Fix an out of bounds access when writing nonsensical values to
/sys/devices/system/cpu/cpuX/hotplug/fail
- Warn about unsupported mitigations= parameters.
Thanks,
Ingo
-->
Eiichi Tsukata (1):
cpu/hotplug: Fix out-of-bounds read when setting fail state
Geert Uytterhoeven (1):
cpu/speculation: Warn on unsupported mitigations= parameter
kernel/cpu.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/kernel/cpu.c b/kernel/cpu.c
index 077fde6fb953..ef1c565edc5d 100644
--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -1964,6 +1964,9 @@ static ssize_t write_cpuhp_fail(struct device *dev,
if (ret)
return ret;
+ if (fail < CPUHP_OFFLINE || fail > CPUHP_ONLINE)
+ return -EINVAL;
+
/*
* Cannot fail STARTING/DYING callbacks.
*/
@@ -2339,6 +2342,9 @@ static int __init mitigations_parse_cmdline(char *arg)
cpu_mitigations = CPU_MITIGATIONS_AUTO;
else if (!strcmp(arg, "auto,nosmt"))
cpu_mitigations = CPU_MITIGATIONS_AUTO_NOSMT;
+ else
+ pr_crit("Unsupported mitigations=%s, system may still be
vulnerable\n",
+ arg);
return 0;
}
Re: net: check before dereferencing netdev_ops during busy poll
On Sat, Jun 29, 2019 at 9:45 AM Greg Kroah-Hartman
wrote:
>
> On Fri, Jun 28, 2019 at 07:03:01PM -0700, Josh Elsasser wrote:
> > On Jun 28, 2019, at 3:55 PM, Sasha Levin wrote:
> >
> > > What's the upstream commit id?
> >
> > The commit wasn't needed upstream, as I only sent the original patch after
> > 79e7fff47b7b ("net: remove support for per driver ndo_busy_poll()") had
> > made the fix unnecessary in Linus' tree.
> >
> > May've gotten lost in the shuffle due to my poor Fixes tags. The patch in
> > question applied only on top of the 4.9 stable release at the time, but the
> > actual NPE had been around in some form since 3.11 / 0602129286705 ("net:
> > add
> > low latency socket poll").
>
> Ok, can people then resend this and be very explicit as to why this is
> needed only in a stable kernel tree and get reviews from people agreeing
> that this really is the correct fix?
>
> thanks,
>
> greg k-h
Hi Greg,
I think that David alredy reviewed the patch here:
https://lore.kernel.org/netdev/20180313.105115.682846171057663636.da...@davemloft.net/
Anyway, I tested the patch and it fixes the panic, at least on my
iwlwifi card, so:
Tested-by: Matteo Croce
Regards,
--
Matteo Croce
per aspera ad upstream
Re: [RFC] Deadlock via recursive wakeup via RCU with threadirqs
On Sat, Jun 29, 2019 at 12:15:15PM -0700, Paul E. McKenney wrote: > On Sat, Jun 29, 2019 at 08:09:10PM +0200, Andrea Parri wrote: > > On Sat, Jun 29, 2019 at 09:55:33AM -0700, Paul E. McKenney wrote: > > > On Sat, Jun 29, 2019 at 05:12:36PM +0200, Andrea Parri wrote: > > > > Hi Steve, > > > > > > > > > As Paul stated, interrupts are synchronization points. Archs can only > > > > > play games with ordering when dealing with entities outside the CPU > > > > > (devices and other CPUs). But if you have assembly that has two > > > > > stores, > > > > > and an interrupt comes in, the arch must guarantee that the stores are > > > > > done in that order as the interrupt sees it. > > > > > > > > Hopefully I'm not derailing the conversation too much with my questions > > > > ... but I was wondering if we had any documentation (or inline comments) > > > > elaborating on this "interrupts are synchronization points"? > > > > > > I don't know of any, but I would suggest instead looking at something > > > like the Hennessey and Patterson computer-architecture textbook. > > > > > > Please keep in mind that the rather detailed documentation on RCU is a > > > bit of an outlier due to the fact that there are not so many textbooks > > > that cover RCU. If we tried to replicate all of the relevant textbooks > > > in the Documentation directory, it would be quite a large mess. ;-) > > > > You know some developers considered it worth to develop formal specs in > > order to better understand concepts such as "synchronization" and "IRQs > > (processing)"! ... ;-) I still think that adding a few paragraphs (if > > only in informal prose) to explain that "interrupts are synchronization > > points" wouln't hurt. And you're right, I guess we may well start from > > a reference to H > > > > Remark: we do have code which (while acknowledging that "interrupts are > > synchronization points") doesn't quite seem to "believe it", c.f., e.g., > > kernel/sched/membarrier.c:ipi_mb(). So, I guess the follow-up question > > would be "Would we better be (more) paranoid? ..." > > As Steve said that I said, they are synchronization points from the > viewpoint of code within the interrupted CPU. Unless the architecture > code does as smp_mb() on interrupt entry and exit (which perhaps some > do, for all I know, maybe all of them do by now), memory accesses could > still be reordered across the interrupt from the perspective of other > CPUs and devices on the system. Yes, I got it. See: https://lkml.kernel.org/r/20190629182132.GA5666@andrea Still... Andrea
[PATCH] staging/media/davinci_vpfe: Add null check post kmalloc
Add NULL check post memory operations
Signed-off-by: Hariprasad Kelam
---
drivers/staging/media/davinci_vpfe/dm365_ipipe.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/staging/media/davinci_vpfe/dm365_ipipe.c
b/drivers/staging/media/davinci_vpfe/dm365_ipipe.c
index 52397ad..5d8ba35 100644
--- a/drivers/staging/media/davinci_vpfe/dm365_ipipe.c
+++ b/drivers/staging/media/davinci_vpfe/dm365_ipipe.c
@@ -1311,6 +1311,11 @@ static int ipipe_g_config(struct v4l2_subdev *sd, struct
vpfe_ipipe_config *cfg)
to = *(void **)((void *)cfg + module_if->config_offset);
params = kmalloc(sizeof(*params), GFP_KERNEL);
+ if (!params) {
+ rval = -ENOMEM;
+ goto error;
+ }
+
from = (void *)params + module_if->param_offset;
size = module_if->param_size;
--
2.7.4
Re: [RFC] Deadlock via recursive wakeup via RCU with threadirqs
On Sat, Jun 29, 2019 at 08:09:10PM +0200, Andrea Parri wrote: > On Sat, Jun 29, 2019 at 09:55:33AM -0700, Paul E. McKenney wrote: > > On Sat, Jun 29, 2019 at 05:12:36PM +0200, Andrea Parri wrote: > > > Hi Steve, > > > > > > > As Paul stated, interrupts are synchronization points. Archs can only > > > > play games with ordering when dealing with entities outside the CPU > > > > (devices and other CPUs). But if you have assembly that has two stores, > > > > and an interrupt comes in, the arch must guarantee that the stores are > > > > done in that order as the interrupt sees it. > > > > > > Hopefully I'm not derailing the conversation too much with my questions > > > ... but I was wondering if we had any documentation (or inline comments) > > > elaborating on this "interrupts are synchronization points"? > > > > I don't know of any, but I would suggest instead looking at something > > like the Hennessey and Patterson computer-architecture textbook. > > > > Please keep in mind that the rather detailed documentation on RCU is a > > bit of an outlier due to the fact that there are not so many textbooks > > that cover RCU. If we tried to replicate all of the relevant textbooks > > in the Documentation directory, it would be quite a large mess. ;-) > > You know some developers considered it worth to develop formal specs in > order to better understand concepts such as "synchronization" and "IRQs > (processing)"! ... ;-) I still think that adding a few paragraphs (if > only in informal prose) to explain that "interrupts are synchronization > points" wouln't hurt. And you're right, I guess we may well start from > a reference to H > > Remark: we do have code which (while acknowledging that "interrupts are > synchronization points") doesn't quite seem to "believe it", c.f., e.g., > kernel/sched/membarrier.c:ipi_mb(). So, I guess the follow-up question > would be "Would we better be (more) paranoid? ..." As Steve said that I said, they are synchronization points from the viewpoint of code within the interrupted CPU. Unless the architecture code does as smp_mb() on interrupt entry and exit (which perhaps some do, for all I know, maybe all of them do by now), memory accesses could still be reordered across the interrupt from the perspective of other CPUs and devices on the system. Thanx, Paul
[PATCH] staging: netlogic: Change GFP_ATOMIC to GFP_KERNEL
Below is data path of xlr_config_spill xlr_net_probe -->xlr_config_fifo_spill_area --->xlr_config_spill We can use GFP_KERNEL as this function is getting called from xlr_net_probe and there are no locks. Signed-off-by: Hariprasad Kelam --- drivers/staging/netlogic/xlr_net.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/netlogic/xlr_net.c b/drivers/staging/netlogic/xlr_net.c index 07a06c5..05079f7 100644 --- a/drivers/staging/netlogic/xlr_net.c +++ b/drivers/staging/netlogic/xlr_net.c @@ -385,7 +385,7 @@ static void *xlr_config_spill(struct xlr_net_priv *priv, int reg_start_0, base = priv->base_addr; spill_size = size; - spill = kmalloc(spill_size + SMP_CACHE_BYTES, GFP_ATOMIC); + spill = kmalloc(spill_size + SMP_CACHE_BYTES, GFP_KERNEL); if (!spill) return ZERO_SIZE_PTR; -- 2.7.4
Re: shrink_dentry_list() logics change (was Re: [RFC PATCH v3 14/15] dcache: Implement partial shrink via Slab Movable Objects)
On Sat, Jun 29, 2019 at 05:38:03AM +0100, Al Viro wrote: > PS: the problem is not gone in the next iteration of the patchset in > question. The patch I'm proposing (including dput_to_list() and _ONLY_ > compile-tested) follows. Comments? FWIW, there's another unpleasantness in the whole thing. Suppose we have picked a page full of dentries, all with refcount 0. We decide to evict all of them. As it turns out, they are from two filesystems. Filesystem 1 is NFS on a server, with currently downed hub on the way to it. Filesystem 2 is local. We attempt to evict an NFS dentry and get stuck - tons of dirty data with no way to flush them on server. In the meanwhile, admin tries to unmount the local filesystem. And gets stuck as well, since umount can't do anything to its dentries that happen to sit in our shrink list. I wonder if the root of problem here isn't in shrink_dcache_for_umount(); all it really needs is to have everything on that fs with refcount 0 dragged through __dentry_kill(). If something had been on a shrink list, __dentry_kill() will just leave behind a struct dentry completely devoid of any connection to superblock, other dentries, filesystem type, etc. - it's just a piece of memory that won't be freed until the owner of shrink list finally gets around to it. Which can happen at any point - all they'll do to it is dentry_free(), and that doesn't need any fs-related data structures. The logics in shrink_dcache_parent() is collect everything evictable into a shrink list if anything found - kick it out and repeat the scan otherwise, if something had been on other's shrink list repeat the scan I wonder if after the "no evictable candidates, but something on other's shrink lists" we ought to do something along the lines of rcu_read_lock walk it, doing if dentry has zero refcount if it's not on a shrink list, move it to ours else store its address in 'victim' end the walk if no victim found rcu_read_unlock else lock victim for __dentry_kill rcu_read_unlock if it's still alive if it's not IS_ROOT if parent is not on shrink list decrement parent's refcount put it on our list else decrement parent's refcount __dentry_kill(victim) else unlock if our list is non-empty shrink_dentry_list on it in there...
Re: [PATCH v2] hwspinlock: ignore disabled device
On Fri 08 Mar 08:53 PST 2019, Fabien Dessenne wrote:
> Do not wait for hwspinlock device registration if it is not available
> for use.
>
> Signed-off-by: Fabien Dessenne
Applied with Suman's ack
Thanks,
Bjorn
> ---
> V2: use 'goto out' instead of 'return'
>
> drivers/hwspinlock/hwspinlock_core.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/hwspinlock/hwspinlock_core.c
> b/drivers/hwspinlock/hwspinlock_core.c
> index 2bad40d..d806307 100644
> --- a/drivers/hwspinlock/hwspinlock_core.c
> +++ b/drivers/hwspinlock/hwspinlock_core.c
> @@ -333,6 +333,11 @@ int of_hwspin_lock_get_id(struct device_node *np, int
> index)
> if (ret)
> return ret;
>
> + if (!of_device_is_available(args.np)) {
> + ret = -ENOENT;
> + goto out;
> + }
> +
> /* Find the hwspinlock device: we need its base_id */
> ret = -EPROBE_DEFER;
> rcu_read_lock();
> --
> 2.7.4
>
Re: [PATCH] remoteproc: Use struct_size() helper
On Fri 07 Jun 11:53 PDT 2019, Gustavo A. R. Silva wrote:
> One of the more common cases of allocation size calculations is finding
> the size of a structure that has a zero-sized array at the end, along
> with memory for some number of elements for that array. For example:
>
> struct resource_table {
> ...
> u32 offset[0];
> } __packed;
>
> Make use of the struct_size() helper instead of an open-coded version
> in order to avoid any potential type mistakes.
>
> So, replace the following form:
>
> table->num * sizeof(table->offset[0]) + sizeof(struct resource_table)
>
> with:
>
> struct_size(table, offset, table->num)
>
> This code was detected with the help of Coccinelle.
>
> Signed-off-by: Gustavo A. R. Silva
Looks good, applied
Thanks,
Bjorn
> ---
> drivers/remoteproc/remoteproc_elf_loader.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/remoteproc/remoteproc_elf_loader.c
> b/drivers/remoteproc/remoteproc_elf_loader.c
> index 215a4400f21e..606aae166eba 100644
> --- a/drivers/remoteproc/remoteproc_elf_loader.c
> +++ b/drivers/remoteproc/remoteproc_elf_loader.c
> @@ -247,8 +247,7 @@ find_table(struct device *dev, struct elf32_hdr *ehdr,
> size_t fw_size)
> }
>
> /* make sure the offsets array isn't truncated */
> - if (table->num * sizeof(table->offset[0]) +
> - sizeof(struct resource_table) > size) {
> + if (struct_size(table, offset, table->num) > size) {
> dev_err(dev, "resource table incomplete\n");
> return NULL;
> }
> --
> 2.21.0
>
Re: [PATCH] remoteproc: add vendor resources handling
On Mon 17 Jun 05:57 PDT 2019, Clement Leger wrote:
> In order to allow rproc backend to handle vendor resources such as in
> OpenAMP, add a handle_rsc hook. This hook allow the rproc backends to
> handle vendor resources as they like. The hook will be called only for
> vendor resources and should return RSC_HANDLED on successful resource
> handling, RSC_IGNORED if resource was ignored, or a negative value on
> error.
>
> Signed-off-by: Clement Leger
Applied
Thanks,
Bjorn
> ---
> Documentation/remoteproc.txt | 14 +-
> drivers/remoteproc/remoteproc_core.c | 14 ++
> drivers/remoteproc/remoteproc_internal.h | 11 +++
> include/linux/remoteproc.h | 32
> ++--
> 4 files changed, 60 insertions(+), 11 deletions(-)
>
> diff --git a/Documentation/remoteproc.txt b/Documentation/remoteproc.txt
> index 77fb03acdbb4..03c3d2e568b0 100644
> --- a/Documentation/remoteproc.txt
> +++ b/Documentation/remoteproc.txt
> @@ -314,6 +314,8 @@ Here are the various resource types that are currently
> supported::
> * @RSC_VDEV: declare support for a virtio device, and serve as its
> * virtio header.
> * @RSC_LAST: just keep this one at the end
> + * @RSC_VENDOR_START: start of the vendor specific resource types
> range
> + * @RSC_VENDOR_END:end of the vendor specific resource types range
> *
> * Please note that these values are used as indices to the
> rproc_handle_rsc
> * lookup table, so please keep them sane. Moreover, @RSC_LAST is used to
> @@ -321,11 +323,13 @@ Here are the various resource types that are currently
> supported::
> * please update it as needed.
> */
>enum fw_resource_type {
> - RSC_CARVEOUT= 0,
> - RSC_DEVMEM = 1,
> - RSC_TRACE = 2,
> - RSC_VDEV= 3,
> - RSC_LAST= 4,
> + RSC_CARVEOUT= 0,
> + RSC_DEVMEM = 1,
> + RSC_TRACE = 2,
> + RSC_VDEV= 3,
> + RSC_LAST= 4,
> + RSC_VENDOR_START= 128,
> + RSC_VENDOR_END = 512,
>};
>
> For more details regarding a specific resource type, please see its
> diff --git a/drivers/remoteproc/remoteproc_core.c
> b/drivers/remoteproc/remoteproc_core.c
> index 48feebd6d0a2..263e9c9614a8 100644
> --- a/drivers/remoteproc/remoteproc_core.c
> +++ b/drivers/remoteproc/remoteproc_core.c
> @@ -1066,6 +1066,20 @@ static int rproc_handle_resources(struct rproc *rproc,
>
> dev_dbg(dev, "rsc: type %d\n", hdr->type);
>
> + if (hdr->type >= RSC_VENDOR_START &&
> + hdr->type <= RSC_VENDOR_END) {
> + ret = rproc_handle_rsc(rproc, hdr->type, rsc,
> +offset + sizeof(*hdr), avail);
> + if (ret == RSC_HANDLED)
> + continue;
> + else if (ret < 0)
> + break;
> +
> + dev_warn(dev, "unsupported vendor resource %d\n",
> + hdr->type);
> + continue;
> + }
> +
> if (hdr->type >= RSC_LAST) {
> dev_warn(dev, "unsupported resource %d\n", hdr->type);
> continue;
> diff --git a/drivers/remoteproc/remoteproc_internal.h
> b/drivers/remoteproc/remoteproc_internal.h
> index 45ff76a06c72..4c77bdd517b9 100644
> --- a/drivers/remoteproc/remoteproc_internal.h
> +++ b/drivers/remoteproc/remoteproc_internal.h
> @@ -106,6 +106,17 @@ static inline int rproc_parse_fw(struct rproc *rproc,
> const struct firmware *fw)
> return 0;
> }
>
> +static inline
> +int rproc_handle_rsc(struct rproc *rproc, u32 rsc_type, void *rsc, int
> offset,
> + int avail)
> +{
> + if (rproc->ops->handle_rsc)
> + return rproc->ops->handle_rsc(rproc, rsc_type, rsc, offset,
> + avail);
> +
> + return RSC_IGNORED;
> +}
> +
> static inline
> struct resource_table *rproc_find_loaded_rsc_table(struct rproc *rproc,
> const struct firmware *fw)
> diff --git a/include/linux/remoteproc.h b/include/linux/remoteproc.h
> index 04d04709f2bd..16ad66683ad0 100644
> --- a/include/linux/remoteproc.h
> +++ b/include/linux/remoteproc.h
> @@ -100,7 +100,9 @@ struct fw_rsc_hdr {
> * the remote processor will be writing logs.
> * @RSC_VDEV: declare support for a virtio device, and serve as its
> * virtio header.
> - * @RSC_LAST: just keep this one at the end
> + * @RSC_LAST: just keep this one at the end of standard resources
> + * @RSC_VENDOR_START:start of the vendor specific resource types
> range
> + * @RSC_VENDOR_END: end of the vendor specific resource types range
> *
> * For more
[PATCH] staging/rtl8188eu/os_dep: Remove unneeded variable ret
Below list of functions returns 0 in success and -EINVAL in failure. So
directly return 0 on Success.
Signed-off-by: Hariprasad Kelam
---
drivers/staging/rtl8188eu/os_dep/ioctl_linux.c | 18 ++
1 file changed, 6 insertions(+), 12 deletions(-)
diff --git a/drivers/staging/rtl8188eu/os_dep/ioctl_linux.c
b/drivers/staging/rtl8188eu/os_dep/ioctl_linux.c
index eaa4adb..d9d0462 100644
--- a/drivers/staging/rtl8188eu/os_dep/ioctl_linux.c
+++ b/drivers/staging/rtl8188eu/os_dep/ioctl_linux.c
@@ -2508,7 +2508,6 @@ static int rtw_add_sta(struct net_device *dev, struct
ieee_param *param)
static int rtw_del_sta(struct net_device *dev, struct ieee_param *param)
{
- int ret = 0;
struct sta_info *psta = NULL;
struct adapter *padapter = (struct adapter *)rtw_netdev_priv(dev);
struct mlme_priv *pmlmepriv = &(padapter->mlmepriv);
@@ -2538,7 +2537,7 @@ static int rtw_del_sta(struct net_device *dev, struct
ieee_param *param)
DBG_88E("rtw_del_sta(), sta has already been removed or never
been added\n");
}
- return ret;
+ return 0;
}
static int rtw_ioctl_get_sta_data(struct net_device *dev, struct ieee_param
*param, int len)
@@ -2636,7 +2635,6 @@ static int rtw_get_sta_wpaie(struct net_device *dev,
struct ieee_param *param)
static int rtw_set_wps_beacon(struct net_device *dev, struct ieee_param
*param, int len)
{
- int ret = 0;
unsigned char wps_oui[4] = {0x0, 0x50, 0xf2, 0x04};
struct adapter *padapter = (struct adapter *)rtw_netdev_priv(dev);
struct mlme_priv *pmlmepriv = &(padapter->mlmepriv);
@@ -2668,12 +2666,11 @@ static int rtw_set_wps_beacon(struct net_device *dev,
struct ieee_param *param,
pmlmeext->bstart_bss = true;
}
- return ret;
+ return 0;
}
static int rtw_set_wps_probe_resp(struct net_device *dev, struct ieee_param
*param, int len)
{
- int ret = 0;
struct adapter *padapter = (struct adapter *)rtw_netdev_priv(dev);
struct mlme_priv *pmlmepriv = &(padapter->mlmepriv);
int ie_len;
@@ -2698,12 +2695,11 @@ static int rtw_set_wps_probe_resp(struct net_device
*dev, struct ieee_param *par
memcpy(pmlmepriv->wps_probe_resp_ie, param->u.bcn_ie.buf,
ie_len);
}
- return ret;
+ return 0;
}
static int rtw_set_wps_assoc_resp(struct net_device *dev, struct ieee_param
*param, int len)
{
- int ret = 0;
struct adapter *padapter = (struct adapter *)rtw_netdev_priv(dev);
struct mlme_priv *pmlmepriv = &(padapter->mlmepriv);
int ie_len;
@@ -2729,12 +2725,11 @@ static int rtw_set_wps_assoc_resp(struct net_device
*dev, struct ieee_param *par
memcpy(pmlmepriv->wps_assoc_resp_ie, param->u.bcn_ie.buf,
ie_len);
}
- return ret;
+ return 0;
}
static int rtw_set_hidden_ssid(struct net_device *dev, struct ieee_param
*param, int len)
{
- int ret = 0;
struct adapter *padapter = (struct adapter *)rtw_netdev_priv(dev);
struct mlme_priv *pmlmepriv = &(padapter->mlmepriv);
struct mlme_ext_priv*pmlmeext = &(padapter->mlmeextpriv);
@@ -2754,7 +2749,7 @@ static int rtw_set_hidden_ssid(struct net_device *dev,
struct ieee_param *param,
value = 0;
DBG_88E("%s value(%u)\n", __func__, value);
pmlmeinfo->hidden_ssid_mode = value;
- return ret;
+ return 0;
}
static int rtw_ioctl_acl_remove_sta(struct net_device *dev, struct ieee_param
*param, int len)
@@ -2787,7 +2782,6 @@ static int rtw_ioctl_acl_add_sta(struct net_device *dev,
struct ieee_param *para
static int rtw_ioctl_set_macaddr_acl(struct net_device *dev, struct ieee_param
*param, int len)
{
- int ret = 0;
struct adapter *padapter = (struct adapter *)rtw_netdev_priv(dev);
struct mlme_priv *pmlmepriv = &(padapter->mlmepriv);
@@ -2796,7 +2790,7 @@ static int rtw_ioctl_set_macaddr_acl(struct net_device
*dev, struct ieee_param *
rtw_set_macaddr_acl(padapter, param->u.mlme.command);
- return ret;
+ return 0;
}
static int rtw_hostapd_ioctl(struct net_device *dev, struct iw_point *p)
--
2.7.4
Re: [RFC] Deadlock via recursive wakeup via RCU with threadirqs
> Remark: we do have code which (while acknowledging that "interrupts are > synchronization points") doesn't quite seem to "believe it", c.f., e.g., > kernel/sched/membarrier.c:ipi_mb(). So, I guess the follow-up question > would be "Would we better be (more) paranoid? ..." should have been "IPIs are serializing" (so all a different "order"...) Andrea
Re: [PATCH 0/2] Sub ns increment fixes in Macb PTP
From: Harini Katakam Date: Thu, 27 Jun 2019 11:50:58 +0530 > The subns increment register fields are not captured correctly in the > driver. Fix the same and also increase the subns incr resolution. > > Sub ns resolution was increased to 24 bits in r1p06f2 version. To my > knowledge, this PTP driver, with its current BD time stamp > implementation, is only useful to that version or above. So, I have > increased the resolution unconditionally. Please let me know if there > is any IP versions incompatible with this - there is no register to > obtain this information from. > > Changes from RFC: > None Series applied, thanks.
Re: [RFC] Deadlock via recursive wakeup via RCU with threadirqs
On Sat, Jun 29, 2019 at 09:55:33AM -0700, Paul E. McKenney wrote: > On Sat, Jun 29, 2019 at 05:12:36PM +0200, Andrea Parri wrote: > > Hi Steve, > > > > > As Paul stated, interrupts are synchronization points. Archs can only > > > play games with ordering when dealing with entities outside the CPU > > > (devices and other CPUs). But if you have assembly that has two stores, > > > and an interrupt comes in, the arch must guarantee that the stores are > > > done in that order as the interrupt sees it. > > > > Hopefully I'm not derailing the conversation too much with my questions > > ... but I was wondering if we had any documentation (or inline comments) > > elaborating on this "interrupts are synchronization points"? > > I don't know of any, but I would suggest instead looking at something > like the Hennessey and Patterson computer-architecture textbook. > > Please keep in mind that the rather detailed documentation on RCU is a > bit of an outlier due to the fact that there are not so many textbooks > that cover RCU. If we tried to replicate all of the relevant textbooks > in the Documentation directory, it would be quite a large mess. ;-) You know some developers considered it worth to develop formal specs in order to better understand concepts such as "synchronization" and "IRQs (processing)"! ... ;-) I still think that adding a few paragraphs (if only in informal prose) to explain that "interrupts are synchronization points" wouln't hurt. And you're right, I guess we may well start from a reference to H Remark: we do have code which (while acknowledging that "interrupts are synchronization points") doesn't quite seem to "believe it", c.f., e.g., kernel/sched/membarrier.c:ipi_mb(). So, I guess the follow-up question would be "Would we better be (more) paranoid? ..." Thanks, Andrea
Re: [Linux-kernel-mentees][PATCH v2] packet: Fix undefined behavior in bit shift
From: Jiunn Chang Date: Wed, 26 Jun 2019 22:25:30 -0500 > Shifting signed 32-bit value by 31 bits is undefined. Changing most > significant bit to unsigned. > > Changes included in v2: > - use subsystem specific subject lines > - CC required mailing lists > > Signed-off-by: Jiunn Chang Applied.
Re: [PATCH net-next] xdp: xdp_umem: fix umem pages mapping for 32bits systems
From: Björn Töpel Date: Wed, 26 Jun 2019 22:50:23 +0200 > On Wed, 26 Jun 2019 at 17:59, Ivan Khoronzhuk > wrote: >> >> Use kmap instead of page_address as it's not always in low memory. >> > > Ah, some 32-bit love. :-) Thanks for working on this! > > For future patches, please base AF_XDP patches on the bpf/bpf-next > tree instead of net/net-next. > > Acked-by: Björn Töpel Alexei and Daniel, I'll let you guys take this one. Thanks.
Re: [PATCH net-next] hinic: add vlan offload support
From: Xue Chaojing Date: Sat, 29 Jun 2019 02:26:27 + > This patch adds vlan offload support for the HINIC driver. > > Signed-off-by: Xue Chaojing Applied, thank you.
Re: bcachefs status update (it's done cooking; let's get this sucker merged)
hey linus, you made news again, all blown up and pointless again. you're doing great: you're being honest. remember the offer i made to put you in touch with my friend. anecdotal story: andrew tridgell worked on the fujitsu sparc supercomputer a couple decades ago: it had a really weird DMA ring bus. * memory-to-memory copy (in the same core) was 10mbytes/sec * DMA memory-to-memory copy (in the same core) was 20mbytes/sec * memory-memory copy (across the ring bus i.e. to another machine) was 100mbytes/sec * DMA memory-memory copy (across the ring bus) was *200* mbytes/sec. when andrew tried asking people, "hey everyone, we need a filesystem that can work really well on this fast parallel system", he had to continuously fend off "i got a great idea for in-core memory-to-memory cacheing" suggestions, because they *just would never work*. the point being: caches aren't always "fast". /salutes. l.
Re: [RFC] Deadlock via recursive wakeup via RCU with threadirqs
On Sat, Jun 29, 2019 at 05:12:36PM +0200, Andrea Parri wrote: > Hi Steve, > > > As Paul stated, interrupts are synchronization points. Archs can only > > play games with ordering when dealing with entities outside the CPU > > (devices and other CPUs). But if you have assembly that has two stores, > > and an interrupt comes in, the arch must guarantee that the stores are > > done in that order as the interrupt sees it. > > Hopefully I'm not derailing the conversation too much with my questions > ... but I was wondering if we had any documentation (or inline comments) > elaborating on this "interrupts are synchronization points"? I don't know of any, but I would suggest instead looking at something like the Hennessey and Patterson computer-architecture textbook. Please keep in mind that the rather detailed documentation on RCU is a bit of an outlier due to the fact that there are not so many textbooks that cover RCU. If we tried to replicate all of the relevant textbooks in the Documentation directory, it would be quite a large mess. ;-) Thanx, Paul
Re: [PATCH V5 02/18] pinctrl: tegra: Add suspend and resume support
29.06.2019 18:58, Dmitry Osipenko пишет:
> 29.06.2019 18:46, Dmitry Osipenko пишет:
>> 28.06.2019 5:12, Sowjanya Komatineni пишет:
>>> This patch adds support for Tegra pinctrl driver suspend and resume.
>>>
>>> During suspend, context of all pinctrl registers are stored and
>>> on resume they are all restored to have all the pinmux and pad
>>> configuration for normal operation.
>>>
>>> Acked-by: Thierry Reding
>>> Signed-off-by: Sowjanya Komatineni
>>> ---
>>> drivers/pinctrl/tegra/pinctrl-tegra.c| 52
>>>
>>> drivers/pinctrl/tegra/pinctrl-tegra.h| 3 ++
>>> drivers/pinctrl/tegra/pinctrl-tegra210.c | 1 +
>>> 3 files changed, 56 insertions(+)
>>>
>>> diff --git a/drivers/pinctrl/tegra/pinctrl-tegra.c
>>> b/drivers/pinctrl/tegra/pinctrl-tegra.c
>>> index 34596b246578..e7c0a1011cba 100644
>>> --- a/drivers/pinctrl/tegra/pinctrl-tegra.c
>>> +++ b/drivers/pinctrl/tegra/pinctrl-tegra.c
>>> @@ -621,6 +621,43 @@ static void tegra_pinctrl_clear_parked_bits(struct
>>> tegra_pmx *pmx)
>>> }
>>> }
>>>
>>> +static int tegra_pinctrl_suspend(struct device *dev)
>>> +{
>>> + struct tegra_pmx *pmx = dev_get_drvdata(dev);
>>> + u32 *backup_regs = pmx->backup_regs;
>>> + u32 *regs;
>>> + unsigned int i, j;
>>> +
>>> + for (i = 0; i < pmx->nbanks; i++) {
>>> + regs = pmx->regs[i];
>>> + for (j = 0; j < pmx->reg_bank_size[i] / 4; j++)
>>> + *backup_regs++ = readl(regs++);
>>> + }
>>> +
>>> + return pinctrl_force_sleep(pmx->pctl);
>>> +}
>>> +
>>> +static int tegra_pinctrl_resume(struct device *dev)
>>> +{
>>> + struct tegra_pmx *pmx = dev_get_drvdata(dev);
>>> + u32 *backup_regs = pmx->backup_regs;
>>> + u32 *regs;
>>> + unsigned int i, j;
>>> +
>>> + for (i = 0; i < pmx->nbanks; i++) {
>>> + regs = pmx->regs[i];
>>> + for (j = 0; j < pmx->reg_bank_size[i] / 4; j++)
>>> + writel(*backup_regs++, regs++);
>>> + }
>>> +
>>> + return 0;
>>> +}
>>> +
>>> +const struct dev_pm_ops tegra_pinctrl_pm = {
>>> + .suspend = _pinctrl_suspend,
>>> + .resume = _pinctrl_resume
>>> +};
>>
>> Hm, so this are the generic platform-driver suspend-resume OPS here, which
>> is very
>> nice! But.. shouldn't pinctrl be resumed before the CLK driver (which is
>> syscore_ops
>> in this version of the series)? .. Given that "clock" function may need to be
>> selected for some of the pins.
>>
>
> Oh, also what about GPIO-pinctrl suspend resume ordering .. is it okay that
> pinctrl
> will be resumed after GPIO? Shouldn't a proper pin-muxing be selected at
> first?
>
> This also looks to me very unsafe in a context of older Tegras which are
> initializing
> the static muxing very early during of the boot, otherwise things won't work
> well for
> the drivers.
>
Although, scratch what I wrote about older Tegras. We are probing pinctl driver
very
early, hence it should suspend last and resume first. Should be okay.
Re: [PATCH] filesystem-dax: Disable PMD support
On Thu, Jun 27, 2019 at 07:39:37PM -0700, Dan Williams wrote:
> On Thu, Jun 27, 2019 at 12:59 PM Matthew Wilcox wrote:
> >
> > On Thu, Jun 27, 2019 at 12:09:29PM -0700, Dan Williams wrote:
> > > > This bug feels like we failed to unlock, or unlocked the wrong entry
> > > > and this hunk in the bisected commit looks suspect to me. Why do we
> > > > still need to drop the lock now that the radix_tree_preload() calls
> > > > are gone?
> > >
> > > Nevermind, unmapp_mapping_pages() takes a sleeping lock, but then I
> > > wonder why we don't restart the lookup like the old implementation.
> >
> > We have the entry locked:
> >
> > /*
> > * Make sure 'entry' remains valid while we drop
> > * the i_pages lock.
> > */
> > dax_lock_entry(xas, entry);
> >
> > /*
> > * Besides huge zero pages the only other thing that gets
> > * downgraded are empty entries which don't need to be
> > * unmapped.
> > */
> > if (dax_is_zero_entry(entry)) {
> > xas_unlock_irq(xas);
> > unmap_mapping_pages(mapping,
> > xas->xa_index & ~PG_PMD_COLOUR,
> > PG_PMD_NR, false);
> > xas_reset(xas);
> > xas_lock_irq(xas);
> > }
> >
> > If something can remove a locked entry, then that would seem like the
> > real bug. Might be worth inserting a lookup there to make sure that it
> > hasn't happened, I suppose?
>
> Nope, added a check, we do in fact get the same locked entry back
> after dropping the lock.
>
> The deadlock revolves around the mmap_sem. One thread holds it for
> read and then gets stuck indefinitely in get_unlocked_entry(). Once
> that happens another rocksdb thread tries to mmap and gets stuck
> trying to take the mmap_sem for write. Then all new readers, including
> ps and top that try to access a remote vma, then get queued behind
> that write.
>
> It could also be the case that we're missing a wake up.
OK, I have a Theory.
get_unlocked_entry() doesn't check the size of the entry being waited for.
So dax_iomap_pmd_fault() can end up sleeping waiting for a PTE entry,
which is (a) foolish, because we know it's going to fall back, and (b)
can lead to a missed wakeup because it's going to sleep waiting for
the PMD entry to come unlocked. Which it won't, unless there's a happy
accident that happens to map to the same hash bucket.
Let's see if I can steal some time this weekend to whip up a patch.
Re: [PATCH V5 02/18] pinctrl: tegra: Add suspend and resume support
29.06.2019 18:46, Dmitry Osipenko пишет:
> 28.06.2019 5:12, Sowjanya Komatineni пишет:
>> This patch adds support for Tegra pinctrl driver suspend and resume.
>>
>> During suspend, context of all pinctrl registers are stored and
>> on resume they are all restored to have all the pinmux and pad
>> configuration for normal operation.
>>
>> Acked-by: Thierry Reding
>> Signed-off-by: Sowjanya Komatineni
>> ---
>> drivers/pinctrl/tegra/pinctrl-tegra.c| 52
>>
>> drivers/pinctrl/tegra/pinctrl-tegra.h| 3 ++
>> drivers/pinctrl/tegra/pinctrl-tegra210.c | 1 +
>> 3 files changed, 56 insertions(+)
>>
>> diff --git a/drivers/pinctrl/tegra/pinctrl-tegra.c
>> b/drivers/pinctrl/tegra/pinctrl-tegra.c
>> index 34596b246578..e7c0a1011cba 100644
>> --- a/drivers/pinctrl/tegra/pinctrl-tegra.c
>> +++ b/drivers/pinctrl/tegra/pinctrl-tegra.c
>> @@ -621,6 +621,43 @@ static void tegra_pinctrl_clear_parked_bits(struct
>> tegra_pmx *pmx)
>> }
>> }
>>
>> +static int tegra_pinctrl_suspend(struct device *dev)
>> +{
>> +struct tegra_pmx *pmx = dev_get_drvdata(dev);
>> +u32 *backup_regs = pmx->backup_regs;
>> +u32 *regs;
>> +unsigned int i, j;
>> +
>> +for (i = 0; i < pmx->nbanks; i++) {
>> +regs = pmx->regs[i];
>> +for (j = 0; j < pmx->reg_bank_size[i] / 4; j++)
>> +*backup_regs++ = readl(regs++);
>> +}
>> +
>> +return pinctrl_force_sleep(pmx->pctl);
>> +}
>> +
>> +static int tegra_pinctrl_resume(struct device *dev)
>> +{
>> +struct tegra_pmx *pmx = dev_get_drvdata(dev);
>> +u32 *backup_regs = pmx->backup_regs;
>> +u32 *regs;
>> +unsigned int i, j;
>> +
>> +for (i = 0; i < pmx->nbanks; i++) {
>> +regs = pmx->regs[i];
>> +for (j = 0; j < pmx->reg_bank_size[i] / 4; j++)
>> +writel(*backup_regs++, regs++);
>> +}
>> +
>> +return 0;
>> +}
>> +
>> +const struct dev_pm_ops tegra_pinctrl_pm = {
>> +.suspend = _pinctrl_suspend,
>> +.resume = _pinctrl_resume
>> +};
>
> Hm, so this are the generic platform-driver suspend-resume OPS here, which is
> very
> nice! But.. shouldn't pinctrl be resumed before the CLK driver (which is
> syscore_ops
> in this version of the series)? .. Given that "clock" function may need to be
> selected for some of the pins.
>
Oh, also what about GPIO-pinctrl suspend resume ordering .. is it okay that
pinctrl
will be resumed after GPIO? Shouldn't a proper pin-muxing be selected at first?
This also looks to me very unsafe in a context of older Tegras which are
initializing
the static muxing very early during of the boot, otherwise things won't work
well for
the drivers.
Re: [PATCH v1] arm: dts: mediatek: add basic support for MT7629 SoC
On Fri, 2019-06-28 at 16:32 -0700, Kevin Hilman wrote: > writes: > > > From: Ryder Lee > > > > This adds basic support for MT7629 reference board. > > > > Signed-off-by: Ryder Lee > > Just noticing this is not upstream yet. > > I did a basic boot test to ramdisk on the mt7629-rfb board donated for > kernelCI (thanks MediaTek!) and it boots just fine. > > Tested-by: Kevin Hilman > > Kevin Thanks. I'll post v3 with some fixups soon. Ryder
BUG: using smp_processor_id() in preemptible [ADDR] code: syz-executor
Hello,
syzbot found the following crash on:
HEAD commit:ee7dd773 sis900: remove TxIDLE
git tree: net-next
console output: https://syzkaller.appspot.com/x/log.txt?x=17ceb9a9a0
kernel config: https://syzkaller.appspot.com/x/.config?x=7ac9edef4d37e5fb
dashboard link: https://syzkaller.appspot.com/bug?extid=1a68504d96cd17b33a05
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=119b2a13a0
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=13127bada0
The bug was bisected to:
commit 52dfae5c85a4c1078e9f1d5e8947d4a25f73dd81
Author: Jon Maloy
Date: Thu Mar 22 19:42:52 2018 +
tipc: obtain node identity from interface by default
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=160ad903a0
final crash:https://syzkaller.appspot.com/x/report.txt?x=150ad903a0
console output: https://syzkaller.appspot.com/x/log.txt?x=110ad903a0
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+1a68504d96cd17b33...@syzkaller.appspotmail.com
Fixes: 52dfae5c85a4 ("tipc: obtain node identity from interface by default")
Started in network mode
Own node identity 7f01, cluster identity 4711
New replicast peer: 172.20.20.22
check_preemption_disabled: 3 callbacks suppressed
BUG: using smp_processor_id() in preemptible [] code:
syz-executor834/8612
caller is dst_cache_get+0x3d/0xb0 net/core/dst_cache.c:68
CPU: 0 PID: 8612 Comm: syz-executor834 Not tainted 5.2.0-rc6+ #48
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x172/0x1f0 lib/dump_stack.c:113
check_preemption_disabled lib/smp_processor_id.c:47 [inline]
debug_smp_processor_id+0x251/0x280 lib/smp_processor_id.c:57
dst_cache_get+0x3d/0xb0 net/core/dst_cache.c:68
tipc_udp_xmit.isra.0+0xc4/0xb80 net/tipc/udp_media.c:164
tipc_udp_send_msg+0x29a/0x4b0 net/tipc/udp_media.c:254
tipc_bearer_xmit_skb+0x16c/0x360 net/tipc/bearer.c:503
tipc_enable_bearer+0xabe/0xd20 net/tipc/bearer.c:328
__tipc_nl_bearer_enable+0x2de/0x3a0 net/tipc/bearer.c:899
tipc_nl_bearer_enable+0x23/0x40 net/tipc/bearer.c:907
genl_family_rcv_msg+0x74b/0xf90 net/netlink/genetlink.c:629
genl_rcv_msg+0xca/0x16c net/netlink/genetlink.c:654
netlink_rcv_skb+0x177/0x450 net/netlink/af_netlink.c:2477
genl_rcv+0x29/0x40 net/netlink/genetlink.c:665
netlink_unicast_kernel net/netlink/af_netlink.c:1302 [inline]
netlink_unicast+0x531/0x710 net/netlink/af_netlink.c:1328
netlink_sendmsg+0x8ae/0xd70 net/netlink/af_netlink.c:1917
sock_sendmsg_nosec net/socket.c:646 [inline]
sock_sendmsg+0xd7/0x130 net/socket.c:665
___sys_sendmsg+0x803/0x920 net/socket.c:2286
__sys_sendmsg+0x105/0x1d0 net/socket.c:2324
__do_sys_sendmsg net/socket.c:2333 [inline]
__se_sys_sendmsg net/socket.c:2331 [inline]
__x64_sys_sendmsg+0x78/0xb0 net/socket.c:2331
do_syscall_64+0xfd/0x680 arch/x86/entry/common.c:301
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x444679
Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 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 0f 83 1b d8 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:7fff0201a8b8 EFLAGS: 0246 ORIG_RAX: 002e
RAX: ffda RBX: 004002e0 RCX: 00444679
RDX: RSI: 2580 RDI: 0003
RBP: 006cf018 R08: 0001 R09: 004002e0
R10: 0008 R11: 0246 R12: 00402320
R13: 004023b0 R14: R15: 00
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkal...@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
For information about bisection process see: https://goo.gl/tpsmEJ#bisection
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches
Re: [PATCH V5 02/18] pinctrl: tegra: Add suspend and resume support
28.06.2019 5:12, Sowjanya Komatineni пишет:
> This patch adds support for Tegra pinctrl driver suspend and resume.
>
> During suspend, context of all pinctrl registers are stored and
> on resume they are all restored to have all the pinmux and pad
> configuration for normal operation.
>
> Acked-by: Thierry Reding
> Signed-off-by: Sowjanya Komatineni
> ---
> drivers/pinctrl/tegra/pinctrl-tegra.c| 52
>
> drivers/pinctrl/tegra/pinctrl-tegra.h| 3 ++
> drivers/pinctrl/tegra/pinctrl-tegra210.c | 1 +
> 3 files changed, 56 insertions(+)
>
> diff --git a/drivers/pinctrl/tegra/pinctrl-tegra.c
> b/drivers/pinctrl/tegra/pinctrl-tegra.c
> index 34596b246578..e7c0a1011cba 100644
> --- a/drivers/pinctrl/tegra/pinctrl-tegra.c
> +++ b/drivers/pinctrl/tegra/pinctrl-tegra.c
> @@ -621,6 +621,43 @@ static void tegra_pinctrl_clear_parked_bits(struct
> tegra_pmx *pmx)
> }
> }
>
> +static int tegra_pinctrl_suspend(struct device *dev)
> +{
> + struct tegra_pmx *pmx = dev_get_drvdata(dev);
> + u32 *backup_regs = pmx->backup_regs;
> + u32 *regs;
> + unsigned int i, j;
> +
> + for (i = 0; i < pmx->nbanks; i++) {
> + regs = pmx->regs[i];
> + for (j = 0; j < pmx->reg_bank_size[i] / 4; j++)
> + *backup_regs++ = readl(regs++);
> + }
> +
> + return pinctrl_force_sleep(pmx->pctl);
> +}
> +
> +static int tegra_pinctrl_resume(struct device *dev)
> +{
> + struct tegra_pmx *pmx = dev_get_drvdata(dev);
> + u32 *backup_regs = pmx->backup_regs;
> + u32 *regs;
> + unsigned int i, j;
> +
> + for (i = 0; i < pmx->nbanks; i++) {
> + regs = pmx->regs[i];
> + for (j = 0; j < pmx->reg_bank_size[i] / 4; j++)
> + writel(*backup_regs++, regs++);
> + }
> +
> + return 0;
> +}
> +
> +const struct dev_pm_ops tegra_pinctrl_pm = {
> + .suspend = _pinctrl_suspend,
> + .resume = _pinctrl_resume
> +};
Hm, so this are the generic platform-driver suspend-resume OPS here, which is
very
nice! But.. shouldn't pinctrl be resumed before the CLK driver (which is
syscore_ops
in this version of the series)? .. Given that "clock" function may need to be
selected for some of the pins.
Re: [PATCH 02/87] ata: acard-ahci: Remove call to memset after dmam_alloc_coherent
On 6/27/19 11:33 AM, Fuqian Huang wrote:
> In commit af7ddd8a627c
> ("Merge tag 'dma-mapping-4.21' of
> git://git.infradead.org/users/hch/dma-mapping"),
> dmam_alloc_coherent has already zeroed the memory.
> So memset is not needed.
Applied this, and the rest of the ATA related patches, for 5.3. Thanks.
--
Jens Axboe
Re: [PATCH V5 02/18] pinctrl: tegra: Add suspend and resume support
29.06.2019 15:38, Dmitry Osipenko пишет:
> 29.06.2019 2:00, Sowjanya Komatineni пишет:
>>
>> On 6/28/19 5:05 AM, Dmitry Osipenko wrote:
>>> 28.06.2019 14:56, Dmitry Osipenko пишет:
28.06.2019 5:12, Sowjanya Komatineni пишет:
> This patch adds support for Tegra pinctrl driver suspend and resume.
>
> During suspend, context of all pinctrl registers are stored and
> on resume they are all restored to have all the pinmux and pad
> configuration for normal operation.
>
> Acked-by: Thierry Reding
> Signed-off-by: Sowjanya Komatineni
> ---
> int tegra_pinctrl_probe(struct platform_device *pdev,
> const struct tegra_pinctrl_soc_data *soc_data);
> #endif
> diff --git a/drivers/pinctrl/tegra/pinctrl-tegra210.c
> b/drivers/pinctrl/tegra/pinctrl-tegra210.c
> index 0b56ad5c9c1c..edd3f4606cdb 100644
> --- a/drivers/pinctrl/tegra/pinctrl-tegra210.c
> +++ b/drivers/pinctrl/tegra/pinctrl-tegra210.c
> @@ -1571,6 +1571,7 @@ static struct platform_driver
> tegra210_pinctrl_driver = {
> .driver = {
> .name = "tegra210-pinctrl",
> .of_match_table = tegra210_pinctrl_of_match,
> + .pm = _pinctrl_pm,
> },
> .probe = tegra210_pinctrl_probe,
> };
>
Could you please address my comments in the next revision if there will be
one?
>>> Also, what about adding ".pm' for other Tegras? I'm sure Jon could test
>>> them for you.
>>
>> This series is for Tegra210 SC7 entry/exit along with clocks and pinctrl
>> suspend
>> resume needed for Tegra210 basic sc7 entry and exit.
>>
>> This includes pinctrl, pmc changes, clock-tegra210 driver changes all w.r.t
>> Tegra210
>> platforms specific.
>>
>> Suspend/resume support for other Tegras will be in separate patch series.
>
> Okay, fair enough.
>
It may also make some sense to split this patch into two:
1) add generic tegra-pinctrl suspend-resume support
2) add suspend-resume OPS to the pinctrl-tegra210
For consistency.
Re: [PATCH V5 06/18] clk: tegra: Save and restore CPU and System clocks context
28.06.2019 5:12, Sowjanya Komatineni пишет:
> During system suspend state, core power goes off and looses all the
> CAR controller register settings.
>
> This patch creates APIs for saving and restoring the context of Tegra
> CPUG, CPULP and SCLK.
>
> CPU and System clock context includes
> - CPUG, CPULP, and SCLK burst policy settings for clock sourcea of all
> their normal states.
> - SCLK divisor and System clock rate for restoring SCLK, AHB and APB
> rates on resume.
> - OSC_DIV settings which are used as reference clock input to some PLLs.
> - SPARE_REG and CLK_MASK settings.
>
> These APIs are used in Tegra210 clock driver during suspend and resume
> operation.
>
> Acked-by: Thierry Reding
> Signed-off-by: Sowjanya Komatineni
> ---
> drivers/clk/tegra/clk-tegra-super-gen4.c | 4 --
> drivers/clk/tegra/clk.c | 80
>
> drivers/clk/tegra/clk.h | 14 ++
> 3 files changed, 94 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/clk/tegra/clk-tegra-super-gen4.c
> b/drivers/clk/tegra/clk-tegra-super-gen4.c
> index cdfe7c9697e1..ed69ec4d883e 100644
> --- a/drivers/clk/tegra/clk-tegra-super-gen4.c
> +++ b/drivers/clk/tegra/clk-tegra-super-gen4.c
> @@ -19,10 +19,6 @@
> #define PLLX_MISC2 0x514
> #define PLLX_MISC3 0x518
>
> -#define CCLKG_BURST_POLICY 0x368
> -#define CCLKLP_BURST_POLICY 0x370
> -#define SCLK_BURST_POLICY 0x028
> -#define SYSTEM_CLK_RATE 0x030
> #define SCLK_DIVIDER 0x2c
>
> static DEFINE_SPINLOCK(sysrate_lock);
> diff --git a/drivers/clk/tegra/clk.c b/drivers/clk/tegra/clk.c
> index 573e3c967ae1..9e863362d2bf 100644
> --- a/drivers/clk/tegra/clk.c
> +++ b/drivers/clk/tegra/clk.c
> @@ -70,6 +70,12 @@ static struct clk **clks;
> static int clk_num;
> static struct clk_onecell_data clk_data;
>
> +static u32 cclkg_burst_policy_ctx[2];
> +static u32 cclklp_burst_policy_ctx[2];
> +static u32 sclk_burst_policy_ctx[2];
> +static u32 sys_clk_divisor_ctx, system_rate_ctx;
> +static u32 spare_ctx, misc_clk_enb_ctx, clk_arm_ctx;
> +
> /* Handlers for SoC-specific reset lines */
> static int (*special_reset_assert)(unsigned long);
> static int (*special_reset_deassert)(unsigned long);
> @@ -199,6 +205,80 @@ const struct tegra_clk_periph_regs *get_reg_bank(int
> clkid)
> }
> }
>
> +void tegra_cclkg_burst_policy_save_context(void)
> +{
> + unsigned int i;
> +
> + for (i = 0; i < BURST_POLICY_REG_SIZE; i++)
> + cclkg_burst_policy_ctx[i] = readl_relaxed(clk_base +
> + CCLKG_BURST_POLICY +
> + (i * 4));
> +}
> +
> +void tegra_cclkg_burst_policy_restore_context(void)
> +{
> + unsigned int i;
> +
> + for (i = 0; i < BURST_POLICY_REG_SIZE; i++)
> + writel_relaxed(cclkg_burst_policy_ctx[i],
> +clk_base + CCLKG_BURST_POLICY + (i * 4));
> +
> + fence_udelay(2, clk_base);
> +}
> +
> +void tegra_sclk_cclklp_burst_policy_save_context(void)
> +{
> + unsigned int i;
> +
> + for (i = 0; i < BURST_POLICY_REG_SIZE; i++) {
> + cclklp_burst_policy_ctx[i] = readl_relaxed(clk_base +
> + CCLKLP_BURST_POLICY +
> + (i * 4));
> +
> + sclk_burst_policy_ctx[i] = readl_relaxed(clk_base +
> + SCLK_BURST_POLICY +
> + (i * 4));
> + }
> +
> + sys_clk_divisor_ctx = readl_relaxed(clk_base + SYS_CLK_DIV);
> + system_rate_ctx = readl_relaxed(clk_base + SYSTEM_CLK_RATE);
> + spare_ctx = readl_relaxed(clk_base + SPARE_REG0);
> + misc_clk_enb_ctx = readl_relaxed(clk_base + MISC_CLK_ENB);
> + clk_arm_ctx = readl_relaxed(clk_base + CLK_MASK_ARM);
> +}
> +
> +void tegra_sclk_cpulp_burst_policy_restore_context(void)
> +{
> + unsigned int i;
> + u32 val;
> +
> + /*
> + * resume SCLK and CPULP clocks
> + * for SCLk, set safe dividers values first and then restore source
> + * and dividers
> + */
> +
> + writel_relaxed(0x1, clk_base + SYSTEM_CLK_RATE);
> + val = readl_relaxed(clk_base + SYS_CLK_DIV);
> + if (val < sys_clk_divisor_ctx)
> + writel_relaxed(sys_clk_divisor_ctx, clk_base + SYS_CLK_DIV);
> +
> + fence_udelay(2, clk_base);
> +
> + for (i = 0; i < BURST_POLICY_REG_SIZE; i++) {
> + writel_relaxed(cclklp_burst_policy_ctx[i],
> +clk_base + CCLKLP_BURST_POLICY + (i * 4));
> + writel_relaxed(sclk_burst_policy_ctx[i],
> +clk_base + SCLK_BURST_POLICY + (i * 4));
> + }
> +
> + writel_relaxed(sys_clk_divisor_ctx, clk_base + SYS_CLK_DIV);
> + writel_relaxed(system_rate_ctx, clk_base + SYSTEM_CLK_RATE);
> + writel_relaxed(spare_ctx, clk_base
Re: [PATCH v8 4/5] x86/xsave: Make XSAVE check the base CPUID features before enabling
On 10/5/17 11:52 PM, Andi Kleen wrote:
From: Andi Kleen
Before enabling XSAVE, not only check the XSAVE specific CPUID bits,
but also the base CPUID features of the respective XSAVE feature.
This allows to disable individual XSAVE states using the existing
clearcpuid= option, which can be useful for performance testing
and debugging, and also in general avoids inconsistencies.
v2:
Add curly brackets (Thomas Gleixner)
Signed-off-by: Andi Kleen
---
arch/x86/kernel/fpu/xstate.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/arch/x86/kernel/fpu/xstate.c b/arch/x86/kernel/fpu/xstate.c
index f1d5476c9022..924bd895b5ee 100644
--- a/arch/x86/kernel/fpu/xstate.c
+++ b/arch/x86/kernel/fpu/xstate.c
@@ -15,6 +15,7 @@
#include
#include
+#include
/*
* Although we spell it out in here, the Processor Trace
@@ -36,6 +37,19 @@ static const char *xfeature_names[] =
"unknown xstate feature" ,
};
+static short xsave_cpuid_features[] = {
+ X86_FEATURE_FPU,
+ X86_FEATURE_XMM,
+ X86_FEATURE_AVX,
+ X86_FEATURE_MPX,
+ X86_FEATURE_MPX,
+ X86_FEATURE_AVX512F,
+ X86_FEATURE_AVX512F,
+ X86_FEATURE_AVX512F,
+ X86_FEATURE_INTEL_PT,
+ X86_FEATURE_PKU,
+};
+
/*
* Mask of xstate features supported by the CPU and the kernel:
*/
@@ -726,6 +740,7 @@ void __init fpu__init_system_xstate(void)
unsigned int eax, ebx, ecx, edx;
static int on_boot_cpu __initdata = 1;
int err;
+ int i;
WARN_ON_FPU(!on_boot_cpu);
on_boot_cpu = 0;
@@ -759,6 +774,14 @@ void __init fpu__init_system_xstate(void)
goto out_disable;
}
+ /*
+* Clear XSAVE features that are disabled in the normal CPUID.
+*/
+ for (i = 0; i < ARRAY_SIZE(xsave_cpuid_features); i++) {
+ if (!boot_cpu_has(xsave_cpuid_features[i]))
+ xfeatures_mask &= ~BIT(i);
+ }
+
xfeatures_mask &= fpu__get_supported_xfeatures_mask();
/* Enable xstate instructions to be able to continue with initialization: */
Hi,
The commit for this patch in mainline
(ccb18db2ab9d923df07e7495123fe5fb02329713) causes the kernel to hang on
boot when passing the "nofxsr" option:
$ kvm -cpu host -kernel arch/x86/boot/bzImage -append "console=ttyS0
nofxsr earlyprintk=ttyS0" -serial stdio -display none -smp 2
early console in extract_kernel
input_data: 0x01dea276
input_len: 0x00500704
output: 0x0100
output_len: 0x012c79b4
kernel_total_size: 0x00f24000
booted via startup_32()
Physical KASLR using RDRAND RDTSC...
Virtual KASLR using RDRAND RDTSC...
Decompressing Linux... Parsing ELF... Performing relocations... done.
Booting the kernel.
[..hang..]
If I revert it from Linus's tree (~5.2-rc6) then it boots again:
early console in extract_kernel
input_data: 0x024192e9
input_len: 0x005d8ea1
output: 0x0100
output_len: 0x019c7fa4
kernel_total_size: 0x0162c000
trampoline_32bit: 0x0009d000
booted via startup_32()
Physical KASLR using RDRAND RDTSC...
Virtual KASLR using RDRAND RDTSC...
Decompressing Linux... Parsing ELF... Performing relocations... done.
Booting the kernel.
Linux version 5.2.0-rc6+ (vegard@t460) (gcc version 5.5.0 20171010
(Ubuntu 5.5.0-12ubuntu1~16.04)) #98 SMP PREEMPT Sat Jun 29 17:13:31 CEST
2019
Command line: console=ttyS0 nofxsr earlyprintk=ttyS0
[..normal boot..]
/proc/cpuinfo inside the VM is:
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 78
model name : Intel(R) Core(TM) i5-6300U CPU @ 2.40GHz
stepping: 3
microcode : 0x1
cpu MHz : 2496.000
cache size : 4096 KB
physical id : 0
siblings: 1
core id : 0
cpu cores : 1
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 clflush mmx fxsr sse sse2 ss syscall nx pdpe1gb
rdtscp lm constant_tsc arch_perfmon rep_good nopl cpuid tsc_known_freq
pni pclmulqdq vmx ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt
tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm
3dnowprefetch cpuid_fault invpcid_single pti ssbd ibrs ibpb tpr_shadow
vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 hle avx2 smep
bmi2 erms invpcid rtm mpx rdseed adx smap clflushopt xsaveopt xsavec
xgetbv1 xsaves arat
bugs: cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass
l1tf mds
bogomips: 4992.00
clflush size: 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management:
Vegard
Re: [PATCH 06/16] sh: use the generic get_user_pages_fast code
On Tue, Jun 25, 2019 at 04:37:05PM +0200, Christoph Hellwig wrote: > The sh code is mostly equivalent to the generic one, minus various > bugfixes and two arch overrides that this patch adds to pgtable.h. > > Signed-off-by: Christoph Hellwig sh:defconfig no longer builds with this patch applied. mm/gup.c: In function 'gup_huge_pud': arch/sh/include/asm/pgtable-3level.h:40:36: error: implicit declaration of function 'pud_pfn'; did you mean 'pte_pfn'? Bisect log attached. Guenter --- # bad: [48568d8c7f479ec45b9c3d02b4b1895f3ef61a03] Add linux-next specific files for 20190628 # good: [4b972a01a7da614b4796475f933094751a295a2f] Linux 5.2-rc6 git bisect start 'HEAD' 'v5.2-rc6' # good: [89a77c9176fe88f68c3bf7bd255cfea6797258d4] Merge remote-tracking branch 'crypto/master' git bisect good 89a77c9176fe88f68c3bf7bd255cfea6797258d4 # good: [2cedca636ad73ed838bd636685b245404e490c73] Merge remote-tracking branch 'security/next-testing' git bisect good 2cedca636ad73ed838bd636685b245404e490c73 # good: [ea260819fdc2f8a64e6c87f3ad80ecc5e4015921] Merge remote-tracking branch 'char-misc/char-misc-next' git bisect good ea260819fdc2f8a64e6c87f3ad80ecc5e4015921 # good: [aca42ca2a32eacf804ac56a33526f049debc8ec0] Merge remote-tracking branch 'rpmsg/for-next' git bisect good aca42ca2a32eacf804ac56a33526f049debc8ec0 # good: [f4cd0c7f3c07876f7173b5306e974644c6eec141] Merge remote-tracking branch 'pidfd/for-next' git bisect good f4cd0c7f3c07876f7173b5306e974644c6eec141 # bad: [09c57a8ab1fc3474b4a620247a0f9e3ac61c4cfe] mm/sparsemem: support sub-section hotplug git bisect bad 09c57a8ab1fc3474b4a620247a0f9e3ac61c4cfe # good: [aaffcf10880c363870413c5cdee5dfb6a923e9ae] mm: memcontrol: dump memory.stat during cgroup OOM git bisect good aaffcf10880c363870413c5cdee5dfb6a923e9ae # bad: [81d90bb2d2784258ed7c0762ecf34d4665198bad] um: switch to generic version of pte allocation git bisect bad 81d90bb2d2784258ed7c0762ecf34d4665198bad # bad: [dadae650472841f004882a2409aa844e37809c60] sparc64-add-the-missing-pgd_page-definition-fix git bisect bad dadae650472841f004882a2409aa844e37809c60 # good: [d1edd06c6ac8c8c49345ff34de1c72ee571f3f7b] mm: memcg/slab: stop setting page->mem_cgroup pointer for slab pages git bisect good d1edd06c6ac8c8c49345ff34de1c72ee571f3f7b # good: [b1ceaacca9e63794bd3f574c928e7e6aca01bce7] mm: simplify gup_fast_permitted git bisect good b1ceaacca9e63794bd3f574c928e7e6aca01bce7 # good: [59f238b3353caf43b118e1bb44010aa1abd56d7f] sh: add the missing pud_page definition git bisect good 59f238b3353caf43b118e1bb44010aa1abd56d7f # bad: [51bbf54b3f26a85217db720f4e5b01a6c4d3f010] sparc64: add the missing pgd_page definition git bisect bad 51bbf54b3f26a85217db720f4e5b01a6c4d3f010 # bad: [be748d6e72113580af7e37ad68a0047659e60189] sh: use the generic get_user_pages_fast code git bisect bad be748d6e72113580af7e37ad68a0047659e60189 # first bad commit: [be748d6e72113580af7e37ad68a0047659e60189] sh: use the generic get_user_pages_fast code
Re: [PATCH V5 11/18] clk: tegra210: Add support for Tegra210 clocks
28.06.2019 5:12, Sowjanya Komatineni пишет: > This patch adds system suspend and resume support for Tegra210 > clocks. > > All the CAR controller settings are lost on suspend when core power > goes off. > > This patch has implementation for saving and restoring all the PLLs > and clocks context during system suspend and resume to have the > clocks back to same state for normal operation. > > Acked-by: Thierry Reding > Signed-off-by: Sowjanya Komatineni > --- I'd also change the commit's title to something more brief and explicit, like "clk: tegra210: Support suspend-resume".
[GIT pull] smp fixes for 5.2
Linus,
please pull the latest smp-urgent-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
smp-urgent-for-linus
up to: 33d4a5a7a5b4: cpu/hotplug: Fix out-of-bounds read when setting fail
state
Two small changes for the cpu hotplug code:
- Prevent out of bounds access which actually might crash the machine
caused by a missing bounds check in the fail injection code
- Warn about unsupported migitation mode command line arguments to make
people aware that they typoed the paramater. Not necessarily a fix
but quite some people tripped over that.
Thanks,
tglx
-->
Eiichi Tsukata (1):
cpu/hotplug: Fix out-of-bounds read when setting fail state
Geert Uytterhoeven (1):
cpu/speculation: Warn on unsupported mitigations= parameter
kernel/cpu.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/kernel/cpu.c b/kernel/cpu.c
index 077fde6fb953..ef1c565edc5d 100644
--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -1964,6 +1964,9 @@ static ssize_t write_cpuhp_fail(struct device *dev,
if (ret)
return ret;
+ if (fail < CPUHP_OFFLINE || fail > CPUHP_ONLINE)
+ return -EINVAL;
+
/*
* Cannot fail STARTING/DYING callbacks.
*/
@@ -2339,6 +2342,9 @@ static int __init mitigations_parse_cmdline(char *arg)
cpu_mitigations = CPU_MITIGATIONS_AUTO;
else if (!strcmp(arg, "auto,nosmt"))
cpu_mitigations = CPU_MITIGATIONS_AUTO_NOSMT;
+ else
+ pr_crit("Unsupported mitigations=%s, system may still be
vulnerable\n",
+ arg);
return 0;
}
Re: [RFC] Deadlock via recursive wakeup via RCU with threadirqs
Hi Steve, > As Paul stated, interrupts are synchronization points. Archs can only > play games with ordering when dealing with entities outside the CPU > (devices and other CPUs). But if you have assembly that has two stores, > and an interrupt comes in, the arch must guarantee that the stores are > done in that order as the interrupt sees it. Hopefully I'm not derailing the conversation too much with my questions ... but I was wondering if we had any documentation (or inline comments) elaborating on this "interrupts are synchronization points"? Thanks, Andrea
Re: [PATCH V5 11/18] clk: tegra210: Add support for Tegra210 clocks
28.06.2019 5:12, Sowjanya Komatineni пишет:
> This patch adds system suspend and resume support for Tegra210
> clocks.
>
> All the CAR controller settings are lost on suspend when core power
> goes off.
>
> This patch has implementation for saving and restoring all the PLLs
> and clocks context during system suspend and resume to have the
> clocks back to same state for normal operation.
>
> Acked-by: Thierry Reding
> Signed-off-by: Sowjanya Komatineni
> ---
> drivers/clk/tegra/clk-tegra210.c | 115
> ++-
> drivers/clk/tegra/clk.c | 14 +
> drivers/clk/tegra/clk.h | 1 +
> 3 files changed, 127 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/clk/tegra/clk-tegra210.c
> b/drivers/clk/tegra/clk-tegra210.c
> index 1c08c53482a5..1b839544e086 100644
> --- a/drivers/clk/tegra/clk-tegra210.c
> +++ b/drivers/clk/tegra/clk-tegra210.c
> @@ -9,10 +9,12 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -20,6 +22,7 @@
> #include
>
> #include "clk.h"
> +#include "clk-dfll.h"
> #include "clk-id.h"
>
> /*
> @@ -225,6 +228,7 @@
>
> #define CLK_RST_CONTROLLER_RST_DEV_Y_SET 0x2a8
> #define CLK_RST_CONTROLLER_RST_DEV_Y_CLR 0x2ac
> +#define CPU_SOFTRST_CTRL 0x380
>
> #define LVL2_CLK_GATE_OVRA 0xf8
> #define LVL2_CLK_GATE_OVRC 0x3a0
> @@ -2820,6 +2824,7 @@ static int tegra210_enable_pllu(void)
> struct tegra_clk_pll_freq_table *fentry;
> struct tegra_clk_pll pllu;
> u32 reg;
> + int ret;
>
> for (fentry = pll_u_freq_table; fentry->input_rate; fentry++) {
> if (fentry->input_rate == pll_ref_freq)
> @@ -2847,10 +2852,10 @@ static int tegra210_enable_pllu(void)
> fence_udelay(1, clk_base);
> reg |= PLL_ENABLE;
> writel(reg, clk_base + PLLU_BASE);
> + fence_udelay(1, clk_base);
>
> - readl_relaxed_poll_timeout_atomic(clk_base + PLLU_BASE, reg,
> - reg & PLL_BASE_LOCK, 2, 1000);
> - if (!(reg & PLL_BASE_LOCK)) {
> + ret = tegra210_wait_for_mask(, PLLU_BASE, PLL_BASE_LOCK);
> + if (ret) {
> pr_err("Timed out waiting for PLL_U to lock\n");
> return -ETIMEDOUT;
> }
> @@ -3283,6 +3288,103 @@ static void tegra210_disable_cpu_clock(u32 cpu)
> }
>
> #ifdef CONFIG_PM_SLEEP
> +static u32 cpu_softrst_ctx[3];
> +static struct platform_device *dfll_pdev;
> +#define car_readl(_base, _off) readl_relaxed(clk_base + (_base) + ((_off) *
> 4))
> +#define car_writel(_val, _base, _off) \
> + writel_relaxed(_val, clk_base + (_base) + ((_off) * 4))
> +
> +static int tegra210_clk_suspend(void)
> +{
> + unsigned int i;
> + struct device_node *node;
> +
> + tegra_cclkg_burst_policy_save_context();
> +
> + if (!dfll_pdev) {
> + node = of_find_compatible_node(NULL, NULL,
> +"nvidia,tegra210-dfll");
> + if (node)
> + dfll_pdev = of_find_device_by_node(node);
> +
> + of_node_put(node);
> + if (!dfll_pdev)
> + pr_err("dfll node not found. no suspend for dfll\n");
> + }
> +
> + if (dfll_pdev)
> + tegra_dfll_suspend(dfll_pdev);
> +
> + /* Enable PLLP_OUT_CPU after dfll suspend */
> + tegra_clk_set_pllp_out_cpu(true);
> +
> + tegra_sclk_cclklp_burst_policy_save_context();
> +
> + clk_save_context();
> +
> + for (i = 0; i < ARRAY_SIZE(cpu_softrst_ctx); i++)
> + cpu_softrst_ctx[i] = car_readl(CPU_SOFTRST_CTRL, i);
> +
> + return 0;
> +}
> +
> +static void tegra210_clk_resume(void)
> +{
> + unsigned int i;
> + struct clk_hw *parent;
> + struct clk *clk;
> +
> + /*
> + * clk_restore_context restores clocks as per the clock tree.
> + *
> + * dfllCPU_out is first in the clock tree to get restored and it
> + * involves programming DFLL controller along with restoring CPUG
> + * clock burst policy.
> + *
> + * DFLL programming needs dfll_ref and dfll_soc peripheral clocks
> + * to be restores which are part ofthe peripheral clocks.
> + * So, peripheral clocks restore should happen prior to dfll clock
> + * restore.
> + */
> +
> + tegra_clk_osc_resume(clk_base);
> + for (i = 0; i < ARRAY_SIZE(cpu_softrst_ctx); i++)
> + car_writel(cpu_softrst_ctx[i], CPU_SOFTRST_CTRL, i);
> +
> + /* restore all plls and peripheral clocks */
> + tegra210_init_pllu();
> + clk_restore_context();
> +
> + fence_udelay(5, clk_base);
> +
> + /* resume SCLK and CPULP clocks */
> + tegra_sclk_cpulp_burst_policy_restore_context();
> +
> + /*
> + * restore CPUG clocks:
> + * - enable DFLL in open loop mode
> + * - switch CPUG to DFLL clock source
> + * - close DFLL loop
> + * - sync PLLX
Re: [PATCH v4] Documentation:sh:convert register-banks.txt and new-machine.txt to rst format.
Em Sat, 29 Jun 2019 20:02:45 +0530
Vandana BN escreveu:
> This patch converts new-machine.txt and register-banks.txt
> to ReST format, No content change.
> Added interfaces.rst to contain kernel-doc markups from index.rst
> Added interfaces.rst,new-machine.rst and register-banks.rst to sh/index.rst
> Added SPDX tag in index.rst
>
> Signed-off-by: Vandana BN
Looks good to me. Just a final thing to do.
Be sure to run:
./scripts/documentation-file-ref-check
in order to check that you're not breaking any references to the file.
If it breaks, please adjust the reference to reflect the file
rename.
After fixing the broken reference, feel free do add:
Reviewed-by: Mauro Carvalho Chehab
> ---
> Documentation/sh/index.rst| 65 +--
> Documentation/sh/interface.rst| 59 ++
> .../sh/{new-machine.txt => new-machine.rst} | 171 +-
> ...{register-banks.txt => register-banks.rst} | 8 +-
> 4 files changed, 163 insertions(+), 140 deletions(-)
> create mode 100644 Documentation/sh/interface.rst
> rename Documentation/sh/{new-machine.txt => new-machine.rst} (79%)
> rename Documentation/sh/{register-banks.txt => register-banks.rst} (90%)
>
> diff --git a/Documentation/sh/index.rst b/Documentation/sh/index.rst
> index bc8db7ba894a..fec3c405b6b9 100644
> --- a/Documentation/sh/index.rst
> +++ b/Documentation/sh/index.rst
> @@ -1,59 +1,14 @@
> -===
> -SuperH Interfaces Guide
> -===
> +.. SPDX-License-Identifier: GPL-2.0
>
> -:Author: Paul Mundt
> -
> -Memory Management
> -=
> -
> -SH-4
> -
> -
> -Store Queue API
> -~~~
> -
> -.. kernel-doc:: arch/sh/kernel/cpu/sh4/sq.c
> - :export:
> -
> -SH-5
> -
> -
> -TLB Interfaces
> -~~
> -
> -.. kernel-doc:: arch/sh/mm/tlb-sh5.c
> - :internal:
> -
> -.. kernel-doc:: arch/sh/include/asm/tlb_64.h
> - :internal:
> +
> +SuperH Documentation
> +
>
> -Machine Specific Interfaces
> -===
> -
> -mach-dreamcast
> ---
> -
> -.. kernel-doc:: arch/sh/boards/mach-dreamcast/rtc.c
> - :internal:
> -
> -mach-x3proto
> -
> -
> -.. kernel-doc:: arch/sh/boards/mach-x3proto/ilsel.c
> - :export:
> -
> -Busses
> -==
> -
> -SuperHyway
> ---
> -
> -.. kernel-doc:: drivers/sh/superhyway/superhyway.c
> - :export:
> +:Author: Paul Mundt
>
> -Maple
> --
> +.. toctree::
> + :maxdepth: 2
>
> -.. kernel-doc:: drivers/sh/maple/maple.c
> - :export:
> + interface
> + new-machine
> + register-banks
> diff --git a/Documentation/sh/interface.rst b/Documentation/sh/interface.rst
> new file mode 100644
> index ..bc8db7ba894a
> --- /dev/null
> +++ b/Documentation/sh/interface.rst
> @@ -0,0 +1,59 @@
> +===
> +SuperH Interfaces Guide
> +===
> +
> +:Author: Paul Mundt
> +
> +Memory Management
> +=
> +
> +SH-4
> +
> +
> +Store Queue API
> +~~~
> +
> +.. kernel-doc:: arch/sh/kernel/cpu/sh4/sq.c
> + :export:
> +
> +SH-5
> +
> +
> +TLB Interfaces
> +~~
> +
> +.. kernel-doc:: arch/sh/mm/tlb-sh5.c
> + :internal:
> +
> +.. kernel-doc:: arch/sh/include/asm/tlb_64.h
> + :internal:
> +
> +Machine Specific Interfaces
> +===
> +
> +mach-dreamcast
> +--
> +
> +.. kernel-doc:: arch/sh/boards/mach-dreamcast/rtc.c
> + :internal:
> +
> +mach-x3proto
> +
> +
> +.. kernel-doc:: arch/sh/boards/mach-x3proto/ilsel.c
> + :export:
> +
> +Busses
> +==
> +
> +SuperHyway
> +--
> +
> +.. kernel-doc:: drivers/sh/superhyway/superhyway.c
> + :export:
> +
> +Maple
> +-
> +
> +.. kernel-doc:: drivers/sh/maple/maple.c
> + :export:
> diff --git a/Documentation/sh/new-machine.txt
> b/Documentation/sh/new-machine.rst
> similarity index 79%
> rename from Documentation/sh/new-machine.txt
> rename to Documentation/sh/new-machine.rst
> index e0961a66130b..b16c33342642 100644
> --- a/Documentation/sh/new-machine.txt
> +++ b/Documentation/sh/new-machine.rst
> @@ -1,8 +1,8 @@
> +
> +Adding a new board to LinuxSH
> +
>
> -Adding a new board to LinuxSH
> -
> -
> - Paul Mundt
> +Paul Mundt
>
> This document attempts to outline what steps are necessary to add support
> for new boards to the LinuxSH port under the new 2.5 and 2.6 kernels. This
> @@ -19,65 +19,67 @@ include/asm-sh/. For the new kernel, things are broken
> out by board type,
> companion chip type, and CPU type. Looking at a tree view of this directory
> hierarchy looks like the following:
>
> -Board-specific code:
> -
> -.
> -|-- arch
> -| `-- sh
> -| `-- boards
> -| |-- adx
> -| | `-- board-specific files
> -| |-- bigsur
> -| | `--
Re: [PATCH] i2c: remove casting dma_alloc
Hi Jochen, (could you send text emails, please?) > yes, I'm still here. However, I don't have the hardware anymore to test the > patch. Thanks for answering! And besides (not) testing, are you still open to review patches to the best of your knowledge (I neither have most of the HW). Or do you prefer to orphan the driver? Kind regards, Wolfram signature.asc Description: PGP signature
Re: [PATCH] mm: Generalize and rename notify_page_fault() as kprobe_page_fault()
Hi,
On Thu, Jun 13, 2019 at 03:37:24PM +0530, Anshuman Khandual wrote:
> Architectures which support kprobes have very similar boilerplate around
> calling kprobe_fault_handler(). Use a helper function in kprobes.h to unify
> them, based on the x86 code.
>
> This changes the behaviour for other architectures when preemption is
> enabled. Previously, they would have disabled preemption while calling the
> kprobe handler. However, preemption would be disabled if this fault was
> due to a kprobe, so we know the fault was not due to a kprobe handler and
> can simply return failure.
>
> This behaviour was introduced in the commit a980c0ef9f6d ("x86/kprobes:
> Refactor kprobes_fault() like kprobe_exceptions_notify()")
>
With this patch applied, parisc:allmodconfig images no longer build.
In file included from arch/parisc/mm/fixmap.c:8:
include/linux/kprobes.h: In function 'kprobe_page_fault':
include/linux/kprobes.h:477:9: error:
implicit declaration of function 'kprobe_fault_handler'; did you mean
'kprobe_page_fault'?
Reverting the patch fixes the problem.
Guenter
Re: [PATCH 04/16] MIPS: use the generic get_user_pages_fast code
Hi, On Tue, Jun 25, 2019 at 04:37:03PM +0200, Christoph Hellwig wrote: > The mips code is mostly equivalent to the generic one, minus various > bugfixes and an arch override for gup_fast_permitted. > > Note that this defines ARCH_HAS_PTE_SPECIAL for mips as mips has > pte_special and pte_mkspecial implemented and used in the existing > gup code. They are no-op stubs, though which makes me a little unsure > if this is really right thing to do. > > Note that this also adds back a missing cpu_has_dc_aliases check for > __get_user_pages_fast, which the old code was only doing for > get_user_pages_fast. This clearly looks like an oversight, as any > condition that makes get_user_pages_fast unsafe also applies to > __get_user_pages_fast. > > Signed-off-by: Christoph Hellwig > Reviewed-by: Jason Gunthorpe This patch causes all mips images (mips, mips64, mipsel, mipsel64) to crash when booting in qemu. Unfortunately the patch can not be reverted easily since there are context changes, causing build failures after the revert, so I can not verify if this is the only problem. Crash log (same for all variants): ... Run /sbin/init as init process BUG: Bad page map in process mount pte:00b70401 pmd:8e5dc000 page:80c24880 refcount:1 mapcount:-1 mapping: index:0x0 flags: 0x1000(reserved) raw: 1000 80c24884 80c24884 fffe 0001 page dumped because: bad pte addr:(ptrval) vm_flags:04044411 anon_vma:(ptrval) mapping:(ptrval) index:0 qemu-system-mips: terminating on signal 15 from pid 13034 (/bin/bash) Guenter --- bisect log: # bad: [48568d8c7f479ec45b9c3d02b4b1895f3ef61a03] Add linux-next specific files for 20190628 # good: [4b972a01a7da614b4796475f933094751a295a2f] Linux 5.2-rc6 git bisect start 'HEAD' 'v5.2-rc6' # good: [89a77c9176fe88f68c3bf7bd255cfea6797258d4] Merge remote-tracking branch 'crypto/master' git bisect good 89a77c9176fe88f68c3bf7bd255cfea6797258d4 # good: [2cedca636ad73ed838bd636685b245404e490c73] Merge remote-tracking branch 'security/next-testing' git bisect good 2cedca636ad73ed838bd636685b245404e490c73 # good: [ea260819fdc2f8a64e6c87f3ad80ecc5e4015921] Merge remote-tracking branch 'char-misc/char-misc-next' git bisect good ea260819fdc2f8a64e6c87f3ad80ecc5e4015921 # good: [aca42ca2a32eacf804ac56a33526f049debc8ec0] Merge remote-tracking branch 'rpmsg/for-next' git bisect good aca42ca2a32eacf804ac56a33526f049debc8ec0 # good: [f4cd0c7f3c07876f7173b5306e974644c6eec141] Merge remote-tracking branch 'pidfd/for-next' git bisect good f4cd0c7f3c07876f7173b5306e974644c6eec141 # bad: [09c57a8ab1fc3474b4a620247a0f9e3ac61c4cfe] mm/sparsemem: support sub-section hotplug git bisect bad 09c57a8ab1fc3474b4a620247a0f9e3ac61c4cfe # good: [aaffcf10880c363870413c5cdee5dfb6a923e9ae] mm: memcontrol: dump memory.stat during cgroup OOM git bisect good aaffcf10880c363870413c5cdee5dfb6a923e9ae # bad: [81d90bb2d2784258ed7c0762ecf34d4665198bad] um: switch to generic version of pte allocation git bisect bad 81d90bb2d2784258ed7c0762ecf34d4665198bad # bad: [dadae650472841f004882a2409aa844e37809c60] sparc64-add-the-missing-pgd_page-definition-fix git bisect bad dadae650472841f004882a2409aa844e37809c60 # good: [d1edd06c6ac8c8c49345ff34de1c72ee571f3f7b] mm: memcg/slab: stop setting page->mem_cgroup pointer for slab pages git bisect good d1edd06c6ac8c8c49345ff34de1c72ee571f3f7b # good: [b1ceaacca9e63794bd3f574c928e7e6aca01bce7] mm: simplify gup_fast_permitted git bisect good b1ceaacca9e63794bd3f574c928e7e6aca01bce7 # bad: [59f238b3353caf43b118e1bb44010aa1abd56d7f] sh: add the missing pud_page definition git bisect bad 59f238b3353caf43b118e1bb44010aa1abd56d7f # bad: [93a184240a74cb0242b9b970f0bc018c4fdf24fd] MIPS: use the generic get_user_pages_fast code git bisect bad 93a184240a74cb0242b9b970f0bc018c4fdf24fd # good: [7c6a77cff73127e9495e345a0903d55b1b0fb323] mm: lift the x86_32 PAE version of gup_get_pte to common code git bisect good 7c6a77cff73127e9495e345a0903d55b1b0fb323 # first bad commit: [93a184240a74cb0242b9b970f0bc018c4fdf24fd] MIPS: use the generic get_user_pages_fast code
Re: [PATCH RFC v2] Convert struct pid count to refcount_t
On Mon, Jun 24, 2019 at 02:45:34PM -0400, Joel Fernandes (Google) wrote:
> struct pid's count is an atomic_t field used as a refcount. Use
> refcount_t for it which is basically atomic_t but does additional
> checking to prevent use-after-free bugs.
>
> For memory ordering, the only change is with the following:
> -if ((atomic_read(>count) == 1) ||
> - atomic_dec_and_test(>count)) {
> +if (refcount_dec_and_test(>count)) {
> kmem_cache_free(ns->pid_cachep, pid);
>
> Here the change is from:
> Fully ordered --> RELEASE + ACQUIRE (as per refcount-vs-atomic.rst)
> This ACQUIRE should take care of making sure the free happens after the
> refcount_dec_and_test().
>
> The above hunk also removes atomic_read() since it is not needed for the
> code to work and it is unclear how beneficial it is. The removal lets
> refcount_dec_and_test() check for cases where get_pid() happened before
> the object was freed.
>
> Cc: ja...@google.com
> Cc: o...@redhat.com
> Cc: mathieu.desnoy...@efficios.com
> Cc: wi...@infradead.org
> Cc: pet...@infradead.org
> Cc: will.dea...@arm.com
> Cc: paul...@linux.vnet.ibm.com
> Cc: elena.reshet...@intel.com
> Cc: keesc...@chromium.org
> Cc: kernel-t...@android.com
> Cc: kernel-harden...@lists.openwall.com
> Signed-off-by: Joel Fernandes (Google)
As always with these matters, it's quite possible that I'm missing
something subtle here; said this, ;-) the patch does look good to
me: FWIW,
Reviewed-by: Andrea Parri
Thanks,
Andrea
>
> ---
> Changed to RFC to get any feedback on the memory ordering.
>
>
> include/linux/pid.h | 5 +++--
> kernel/pid.c| 7 +++
> 2 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/include/linux/pid.h b/include/linux/pid.h
> index 14a9a39da9c7..8cb86d377ff5 100644
> --- a/include/linux/pid.h
> +++ b/include/linux/pid.h
> @@ -3,6 +3,7 @@
> #define _LINUX_PID_H
>
> #include
> +#include
>
> enum pid_type
> {
> @@ -56,7 +57,7 @@ struct upid {
>
> struct pid
> {
> - atomic_t count;
> + refcount_t count;
> unsigned int level;
> /* lists of tasks that use this pid */
> struct hlist_head tasks[PIDTYPE_MAX];
> @@ -69,7 +70,7 @@ extern struct pid init_struct_pid;
> static inline struct pid *get_pid(struct pid *pid)
> {
> if (pid)
> - atomic_inc(>count);
> + refcount_inc(>count);
> return pid;
> }
>
> diff --git a/kernel/pid.c b/kernel/pid.c
> index 20881598bdfa..89c4849fab5d 100644
> --- a/kernel/pid.c
> +++ b/kernel/pid.c
> @@ -37,7 +37,7 @@
> #include
> #include
> #include
> -#include
> +#include
> #include
> #include
>
> @@ -106,8 +106,7 @@ void put_pid(struct pid *pid)
> return;
>
> ns = pid->numbers[pid->level].ns;
> - if ((atomic_read(>count) == 1) ||
> - atomic_dec_and_test(>count)) {
> + if (refcount_dec_and_test(>count)) {
> kmem_cache_free(ns->pid_cachep, pid);
> put_pid_ns(ns);
> }
> @@ -210,7 +209,7 @@ struct pid *alloc_pid(struct pid_namespace *ns)
> }
>
> get_pid_ns(ns);
> - atomic_set(>count, 1);
> + refcount_set(>count, 1);
> for (type = 0; type < PIDTYPE_MAX; ++type)
> INIT_HLIST_HEAD(>tasks[type]);
>
> --
> 2.22.0.410.gd8fdbe21b5-goog
Re: [PATCH v2 0/8] platform/x86: Huawei WMI laptop extras driver
On Thu, Jun 13, 2019 at 6:04 AM Ayman Bagabas wrote:
>
> Changes from v1:
> * introducing debugfs
> * code reformatting
>
> This patch series introduce new features to the driver and also moves the
> driver from wmi_driver to platform_driver. This move is necessary because the
> driver is no longer only a hotkeys driver and platform_driver offers easier
> future extensibility.
>
> The patch series introduces a WMI BIOS interface that brings on new features
> and enables controlling micmute LED through this interface on supported
> models.
> It also enables controlling battery charging thresholds and fn-lock state.
> These features are controlled through the HWMI WMI device present in most of
> these laptops.
>
> Currently, micmute LED is controlled through an ACPI method under EC.
> This method ("SPIN", "WPIN") is specific to some models and wouldn't
> work on all Huawei laptops. Controlling this LED through the interface
> provides
> a better unified method to control the LED on models that implements this
> feature.
>
> The behavior of hotkeys is not the same among all models. Some models
> require fn-lock to do things like `Ctrl-Ins` or `Alt-PrtSc`. Fn-lock inverts
> the
> behavior of the top row from special keys to F1-F12 keys.
>
> A debugfs interface is also implemented to support unrepresented features and
> to
> provide debugging feedback from users.
You have sent few series regarding Huawei devices.
And from the patch 1 this is not applicable.
So, I dropped all your patches from patchwork queue and will wait for
new versions in order they are applicable.
>
> Ayman Bagabas (8):
> platform/x86: huawei-wmi: move to platform driver
> platform/x86: huawei-wmi: implement WMI management interface
> platform/x86: huawei-wmi: use quirks and module parameters
> platform/x86: huawei-wmi: control micmute LED through WMI interface
> platform/x86: huawei-wmi: add battery charging protection support
> platform/x86: huawei-wmi: add fn-lock support
> platform/x86: huawei-wmi: add sysfs interface support
> platform/x86: huawei-wmi: add debugfs files support
>
> drivers/platform/x86/huawei-wmi.c | 754 ++
> 1 file changed, 665 insertions(+), 89 deletions(-)
>
> --
> 2.20.1
>
--
With Best Regards,
Andy Shevchenko
Re: [PATCH 2/2] input: soc_button_array for newer surface devices
On Thu, Jun 20, 2019 at 2:51 PM Maximilian Luz wrote:
>
> Power and volume button support for 5th and 6th genration Microsoft
> Surface devices via soc_button_array.
>
> Note that these devices use the same MSHW0040 device as on the Surface
> Pro 4, however the implementation is different (GPIOs vs. ACPI
> notifications). Thus some checking is required to ensure we only load
> this driver on the correct devices.
>
Either I need an Ack from Dmitry, or it should go via his tree.
> Signed-off-by: Maximilian Luz
> ---
> drivers/input/misc/soc_button_array.c | 134 +++---
> 1 file changed, 122 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/input/misc/soc_button_array.c
> b/drivers/input/misc/soc_button_array.c
> index 5e59f8e57f8e..157f53a2bd51 100644
> --- a/drivers/input/misc/soc_button_array.c
> +++ b/drivers/input/misc/soc_button_array.c
> @@ -25,6 +25,17 @@ struct soc_button_info {
> bool wakeup;
> };
>
> +/**
> + * struct soc_device_data - driver data for different device types
> + * @button_info: specifications of buttons, if NULL specification is assumed
> to
> + * be present in _DSD
> + * @check: device-specific check (NULL means all will be accepted)
> + */
> +struct soc_device_data {
> + struct soc_button_info *button_info;
> + int (*check)(struct device *dev);
> +};
> +
> /*
> * Some of the buttons like volume up/down are auto repeat, while others
> * are not. To support both, we register two platform devices, and put
> @@ -310,6 +321,7 @@ static int soc_button_probe(struct platform_device *pdev)
> {
> struct device *dev = >dev;
> const struct acpi_device_id *id;
> + struct soc_device_data *device_data;
> struct soc_button_info *button_info;
> struct soc_button_data *priv;
> struct platform_device *pd;
> @@ -320,18 +332,20 @@ static int soc_button_probe(struct platform_device
> *pdev)
> if (!id)
> return -ENODEV;
>
> - if (!id->driver_data) {
> + device_data = (struct soc_device_data *)id->driver_data;
> + if (device_data && device_data->check) {
> + error = device_data->check(dev);
> + if (error)
> + return error;
> + }
> +
> + if (device_data && device_data->button_info) {
> + button_info = (struct soc_button_info *)
> + device_data->button_info;
> + } else {
> button_info = soc_button_get_button_info(dev);
> if (IS_ERR(button_info))
> return PTR_ERR(button_info);
> - } else {
> - button_info = (struct soc_button_info *)id->driver_data;
> - }
> -
> - error = gpiod_count(dev, NULL);
> - if (error < 0) {
> - dev_dbg(dev, "no GPIO attached, ignoring...\n");
> - return -ENODEV;
> }
>
> priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
> @@ -357,12 +371,32 @@ static int soc_button_probe(struct platform_device
> *pdev)
> if (!priv->children[0] && !priv->children[1])
> return -ENODEV;
>
> - if (!id->driver_data)
> + if (!device_data || !device_data->button_info)
> devm_kfree(dev, button_info);
>
> return 0;
> }
>
> +
> +static int soc_device_check_generic(struct device *dev)
> +{
> + int gpios;
> +
> + gpios = gpiod_count(dev, NULL);
> + if (gpios < 0) {
> + dev_dbg(dev, "no GPIO attached, ignoring...\n");
> + return -ENODEV;
> + }
> +
> + return 0;
> +}
> +
> +static struct soc_device_data soc_device_ACPI0011 = {
> + .button_info = NULL,
> + .check = soc_device_check_generic,
> +};
> +
> +
> /*
> * Definition of buttons on the tablet. The ACPI index of each button
> * is defined in section 2.8.7.2 of "Windows ACPI Design Guide for SoC
> @@ -377,9 +411,85 @@ static struct soc_button_info soc_button_PNP0C40[] = {
> { }
> };
>
> +static struct soc_device_data soc_device_PNP0C40 = {
> + .button_info = soc_button_PNP0C40,
> + .check = soc_device_check_generic,
> +};
> +
> +
> +/*
> + * Special device check for Surface Book 2 and Surface Pro (2017).
> + * Both, the Surface Pro 4 (surfacepro3_button.c) and the above mentioned
> + * devices use MSHW0040 for power and volume buttons, however the way they
> + * have to be addressed differs. Make sure that we only load this drivers
> + * for the correct devices by checking the OEM Platform Revision provided by
> + * the _DSM method.
> + */
> +#define MSHW0040_DSM_REVISION 0x01
> +#define MSHW0040_DSM_GET_OMPR 0x02// get OEM Platform Revision
> +static const guid_t MSHW0040_DSM_UUID =
> + GUID_INIT(0x6fd05c69, 0xcde3, 0x49f4, 0x95, 0xed, 0xab, 0x16, 0x65,
> + 0x49, 0x80, 0x35);
> +
> +static int soc_device_check_MSHW0040(struct device *dev)
> +{
> +
Re: [PATCH] platform/x86: pmc_atom: Add CB4063 Beckhoff Automation board to critclk_systems DMI table
On Tue, Jun 18, 2019 at 4:34 PM wrote:
>
> From: Steffen Dirkwinkel
>
> The CB4063 board uses pmc_plt_clk* clocks for ethernet controllers. This
> adds it to the critclk_systems DMI table so the clocks are marked as
> CLK_CRITICAL and not turned off.
>
Pushed to my review and testing queue, thanks!
> Fixes: 648e921888ad ("clk: x86: Stop marking clocks as CLK_IS_CRITICAL")
> Signed-off-by: Steffen Dirkwinkel
> ---
> drivers/platform/x86/pmc_atom.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/platform/x86/pmc_atom.c b/drivers/platform/x86/pmc_atom.c
> index be802fd2182d..551ed44dd361 100644
> --- a/drivers/platform/x86/pmc_atom.c
> +++ b/drivers/platform/x86/pmc_atom.c
> @@ -412,6 +412,14 @@ static const struct dmi_system_id critclk_systems[] = {
> DMI_MATCH(DMI_BOARD_NAME, "CB3163"),
> },
> },
> + {
> + /* pmc_plt_clk* - are used for ethernet controllers */
> + .ident = "Beckhoff CB4063",
> + .matches = {
> + DMI_MATCH(DMI_SYS_VENDOR, "Beckhoff Automation"),
> + DMI_MATCH(DMI_BOARD_NAME, "CB4063"),
> + },
> + },
> {
> /* pmc_plt_clk* - are used for ethernet controllers */
> .ident = "Beckhoff CB6263",
> --
> 2.22.0
--
With Best Regards,
Andy Shevchenko
Re: [PATCH 0/2] Support for buttons on newer MS Surface devices
On Thu, Jun 20, 2019 at 2:51 PM Maximilian Luz wrote: > > This series adds suport for power and volume buttons on 5th and 6th > generation Microsoft Surface devices. Specifically, it adds support for > the power-button on the Surface Laptop 1 and Laptop 2, as well as > support for power- and (on-device) volume-buttons on the Surface Pro 5 > (2017), Pro 6, and Book 2. > > These devices use the same MSHW0040 device as on the Surface Pro 4, > however, whereas the Pro 4 uses an ACPI notify handler, the newer > devices use GPIO interrupts to signal these events. > > The first patch of this series ensures that the surfacepro3_button > driver, used for MSHW0040 on the Pro 4, does not probe for the newer > devices. The second patch adapts soc_button_array to implement the > actual button support. > > I think the changes to soc_button_array in the second patch warrant a > thorough review. I've tried to make things a bit more generic to be able > to integrate arbitrary ACPI GPIO power-/volume-button devices more > easily, I'm not sure if there may be reasons against this. > > These patches have also been tested on various Surface devices via the > github.com/jakeday/linux-surface patchset. > Pushed to my review and testing queue, thanks! > Maximilian Luz (2): > platform: Fix device check for surfacepro3_button > input: soc_button_array for newer surface devices > > drivers/input/misc/soc_button_array.c | 134 -- > drivers/platform/x86/surfacepro3_button.c | 38 ++ > 2 files changed, 160 insertions(+), 12 deletions(-) > > -- > 2.22.0 > -- With Best Regards, Andy Shevchenko
答复: [PATCH v4] net: netfilter: Fix rpfilter dropping vrf packets by mistake
On 6/29/19 20:20 PM, David Ahern wrote:
> On 6/28/19 8:13 PM, linmiaohe wrote:
> > You're right. Fib rules code would set FLOWI_FLAG_SKIP_NH_OIF flag.
> > But I set it here for distinguish with the flags & XT_RPFILTER_LOOSE
> > branch. Without this, they do the same work and maybe should be
> > combined. I don't want to do that as that makes code confusing.
> > Is this code snipet below ok ? If so, I would delete this flag setting.
> >
> >} else if (netif_is_l3_master(dev) || netif_is_l3_slave(dev)) {
> >fl6.flowi6_oif = dev->ifindex;
> > } else if ((flags & XT_RPFILTER_LOOSE) == 0)
> > fl6.flowi6_oif = dev->ifindex;
> that looks fine to me, but it is up to Pablo.
@David Ahern Many thanks for your valuable advice.
@ Pablo Hi, could you please tell me if this code snipet is ok?
If not, which code would you prefer? It's very nice of you to
figure it out for me. Thanks a lot.
Have a nice day.
Best wishes.
Re: slub: don't panic for memcg kmem cache creation failure
> - if (flags & SLAB_PANIC)
> - panic("Cannot create slab %s size=%u realsize=%u order=%u
> offset=%u flags=%lx\n",
> - s->name, s->size, s->size,
> - oo_order(s->oo), s->offset, (unsigned long)flags);
This is wrong. Without SLAB_PANIC people will start to implement error
checking out of habit and add all slightly different error messages.
This simply increases text and rodata size.
If memcg kmem caches creation failure is OK, then SLAB_PANIC should not
be passed.
The fact that SLAB doesn't implement SLAB_PANIC is SLAB bug.
Re: [PATCH V5 06/18] clk: tegra: Save and restore CPU and System clocks context
28.06.2019 5:12, Sowjanya Komatineni пишет:
> During system suspend state, core power goes off and looses all the
> CAR controller register settings.
>
> This patch creates APIs for saving and restoring the context of Tegra
> CPUG, CPULP and SCLK.
>
> CPU and System clock context includes
> - CPUG, CPULP, and SCLK burst policy settings for clock sourcea of all
> their normal states.
> - SCLK divisor and System clock rate for restoring SCLK, AHB and APB
> rates on resume.
> - OSC_DIV settings which are used as reference clock input to some PLLs.
> - SPARE_REG and CLK_MASK settings.
>
> These APIs are used in Tegra210 clock driver during suspend and resume
> operation.
>
> Acked-by: Thierry Reding
> Signed-off-by: Sowjanya Komatineni
> ---
> drivers/clk/tegra/clk-tegra-super-gen4.c | 4 --
> drivers/clk/tegra/clk.c | 80
>
> drivers/clk/tegra/clk.h | 14 ++
> 3 files changed, 94 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/clk/tegra/clk-tegra-super-gen4.c
> b/drivers/clk/tegra/clk-tegra-super-gen4.c
> index cdfe7c9697e1..ed69ec4d883e 100644
> --- a/drivers/clk/tegra/clk-tegra-super-gen4.c
> +++ b/drivers/clk/tegra/clk-tegra-super-gen4.c
> @@ -19,10 +19,6 @@
> #define PLLX_MISC2 0x514
> #define PLLX_MISC3 0x518
>
> -#define CCLKG_BURST_POLICY 0x368
> -#define CCLKLP_BURST_POLICY 0x370
> -#define SCLK_BURST_POLICY 0x028
> -#define SYSTEM_CLK_RATE 0x030
> #define SCLK_DIVIDER 0x2c
>
> static DEFINE_SPINLOCK(sysrate_lock);
> diff --git a/drivers/clk/tegra/clk.c b/drivers/clk/tegra/clk.c
> index 573e3c967ae1..9e863362d2bf 100644
> --- a/drivers/clk/tegra/clk.c
> +++ b/drivers/clk/tegra/clk.c
> @@ -70,6 +70,12 @@ static struct clk **clks;
> static int clk_num;
> static struct clk_onecell_data clk_data;
>
> +static u32 cclkg_burst_policy_ctx[2];
> +static u32 cclklp_burst_policy_ctx[2];
> +static u32 sclk_burst_policy_ctx[2];
> +static u32 sys_clk_divisor_ctx, system_rate_ctx;
> +static u32 spare_ctx, misc_clk_enb_ctx, clk_arm_ctx;
> +
> /* Handlers for SoC-specific reset lines */
> static int (*special_reset_assert)(unsigned long);
> static int (*special_reset_deassert)(unsigned long);
> @@ -199,6 +205,80 @@ const struct tegra_clk_periph_regs *get_reg_bank(int
> clkid)
> }
> }
>
> +void tegra_cclkg_burst_policy_save_context(void)
> +{
> + unsigned int i;
> +
> + for (i = 0; i < BURST_POLICY_REG_SIZE; i++)
> + cclkg_burst_policy_ctx[i] = readl_relaxed(clk_base +
> + CCLKG_BURST_POLICY +
> + (i * 4));
> +}
> +
> +void tegra_cclkg_burst_policy_restore_context(void)
> +{
> + unsigned int i;
> +
> + for (i = 0; i < BURST_POLICY_REG_SIZE; i++)
> + writel_relaxed(cclkg_burst_policy_ctx[i],
> +clk_base + CCLKG_BURST_POLICY + (i * 4));
> +
> + fence_udelay(2, clk_base);
> +}
> +
> +void tegra_sclk_cclklp_burst_policy_save_context(void)
> +{
> + unsigned int i;
> +
> + for (i = 0; i < BURST_POLICY_REG_SIZE; i++) {
> + cclklp_burst_policy_ctx[i] = readl_relaxed(clk_base +
> + CCLKLP_BURST_POLICY +
> + (i * 4));
> +
> + sclk_burst_policy_ctx[i] = readl_relaxed(clk_base +
> + SCLK_BURST_POLICY +
> + (i * 4));
> + }
> +
> + sys_clk_divisor_ctx = readl_relaxed(clk_base + SYS_CLK_DIV);
> + system_rate_ctx = readl_relaxed(clk_base + SYSTEM_CLK_RATE);
> + spare_ctx = readl_relaxed(clk_base + SPARE_REG0);
> + misc_clk_enb_ctx = readl_relaxed(clk_base + MISC_CLK_ENB);
> + clk_arm_ctx = readl_relaxed(clk_base + CLK_MASK_ARM);
> +}
> +
> +void tegra_sclk_cpulp_burst_policy_restore_context(void)
> +{
> + unsigned int i;
> + u32 val;
> +
> + /*
> + * resume SCLK and CPULP clocks
> + * for SCLk, set safe dividers values first and then restore source
> + * and dividers
> + */
> +
> + writel_relaxed(0x1, clk_base + SYSTEM_CLK_RATE);
> + val = readl_relaxed(clk_base + SYS_CLK_DIV);
> + if (val < sys_clk_divisor_ctx)
> + writel_relaxed(sys_clk_divisor_ctx, clk_base + SYS_CLK_DIV);
> +
> + fence_udelay(2, clk_base);
> +
> + for (i = 0; i < BURST_POLICY_REG_SIZE; i++) {
> + writel_relaxed(cclklp_burst_policy_ctx[i],
> +clk_base + CCLKLP_BURST_POLICY + (i * 4));
> + writel_relaxed(sclk_burst_policy_ctx[i],
> +clk_base + SCLK_BURST_POLICY + (i * 4));
> + }
> +
> + writel_relaxed(sys_clk_divisor_ctx, clk_base + SYS_CLK_DIV);
> + writel_relaxed(system_rate_ctx, clk_base + SYSTEM_CLK_RATE);
> + writel_relaxed(spare_ctx, clk_base
Re: [PATCH] let proc net directory inodes reflect to active net namespace
On Tue, Jun 25, 2019 at 10:36:06AM +, Hallsmark, Per wrote:
> +struct proc_dir_entry *proc_net_mkdir(struct net *net, const char *name,
> + struct proc_dir_entry *parent)
> +{
> + struct proc_dir_entry *pde;
> +
> + pde = proc_mkdir_data(name, 0, parent, net);
> + pde->proc_dops = _net_dentry_ops;
> +
> + return pde;
> +}
This requires NULL check at least.
Re: [PATCH V5 08/18] clk: tegra: Add suspend resume support for DFLL
28.06.2019 5:12, Sowjanya Komatineni пишет:
> This patch creates APIs for supporting Tegra210 clock driver to
> perform DFLL suspend and resume operation.
>
> During suspend, DFLL mode is saved and on resume Tegra210 clock driver
> invokes DFLL resume API to re-initialize DFLL to enable target device
> clock in open loop mode or closed loop mode.
>
> Acked-by: Thierry Reding
> Signed-off-by: Sowjanya Komatineni
> ---
> drivers/clk/tegra/clk-dfll.c | 78
>
> drivers/clk/tegra/clk-dfll.h | 2 ++
> 2 files changed, 80 insertions(+)
>
> diff --git a/drivers/clk/tegra/clk-dfll.c b/drivers/clk/tegra/clk-dfll.c
> index f8688c2ddf1a..a1f37cf99b00 100644
> --- a/drivers/clk/tegra/clk-dfll.c
> +++ b/drivers/clk/tegra/clk-dfll.c
> @@ -277,6 +277,7 @@ struct tegra_dfll {
> unsigned long dvco_rate_min;
>
> enum dfll_ctrl_mode mode;
> + enum dfll_ctrl_mode resume_mode;
> enum dfll_tune_rangetune_range;
> struct dentry *debugfs_dir;
> struct clk_hw dfll_clk_hw;
> @@ -1864,6 +1865,83 @@ static int dfll_fetch_common_params(struct tegra_dfll
> *td)
> }
>
> /*
> + * tegra_dfll_suspend
> + * @pdev: DFLL instance
> + *
> + * dfll controls clock/voltage to other devices, including CPU. Therefore,
> + * dfll driver pm suspend callback does not stop cl-dvfs operations.
> + */
> +void tegra_dfll_suspend(struct platform_device *pdev)
> +{
> + struct tegra_dfll *td = dev_get_drvdata(>dev);
> +
> + if (!td)
> + return;
> +
> + if (td->mode <= DFLL_DISABLED)
> + return;
> +
> + td->resume_mode = td->mode;
> + switch (td->mode) {
> + case DFLL_CLOSED_LOOP:
> + dfll_set_mode(td, DFLL_CLOSED_LOOP);
> + dfll_set_frequency_request(td, >last_req);
> +
> + dfll_unlock(td);
> + break;
> + default:
> + break;
> + }
> +}
> +
> +/**
> + * tegra_dfll_resume - reprogram the DFLL after context-loss
> + * @pdev: DFLL instance
> + *
> + * Re-initialize and enable target device clock in open loop mode. Called
> + * directly from SoC clock resume syscore operation. Closed loop will be
> + * re-entered in platform syscore ops as well after CPU clock source is
> + * switched to DFLL in open loop.
> + */
> +void tegra_dfll_resume(struct platform_device *pdev, bool on_dfll)
> +{
> + struct tegra_dfll *td = dev_get_drvdata(>dev);
> +
> + if (!td)
> + return;
> +
> + if (on_dfll) {
> + if (td->resume_mode == DFLL_CLOSED_LOOP)
> + dfll_lock(td);
> + td->resume_mode = DFLL_DISABLED;
> + return;
> + }
> +
> + reset_control_deassert(td->dvco_rst);
> +
> + pm_runtime_get(td->dev);
pm_runtime_get_sync()?
Otherwise looks like you're risking a lot here because pm_runtime_get() is an
asynchronous request.
> + /* Re-init DFLL */
> + dfll_init_out_if(td);
> + dfll_set_default_params(td);
> + dfll_set_open_loop_config(td);
> +
> + pm_runtime_put(td->dev);
> +
> + /* Restore last request and mode up to open loop */
> + switch (td->resume_mode) {
> + case DFLL_CLOSED_LOOP:
> + case DFLL_OPEN_LOOP:
> + dfll_set_mode(td, DFLL_OPEN_LOOP);
> + if (td->pmu_if == TEGRA_DFLL_PMU_I2C)
> + dfll_i2c_set_output_enabled(td, false);
> + break;
> + default:
> + break;
> + }
> +}
Re: [PATCH v3] platform/x86: intel_pmc_core: transform Pkg C-state residency from TSC ticks into microseconds
On Wed, Jun 19, 2019 at 11:29 AM Harry Pan wrote: > > Refer to the Intel SDM Vol.4, the package C-state residency counters > of modern IA micro-architecture are all ticking in TSC frequency, > hence we can apply simple math to transform the ticks into microseconds. > i.e., > residency (ms) = count / tsc_khz > residency (us) = count / tsc_khz * 1000 > > This also aligns to other sysfs debug entries of residency counter in > the same metric in microseconds, benefits reading and scripting. > > v2: restore the accidentally deleted newline, no function change. > v3: apply kernel do_div() macro to calculate division > > Signed-off-by: Harry Pan > Pushed to my review and testing queue, thanks! > --- > > drivers/platform/x86/intel_pmc_core.c | 5 - > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/drivers/platform/x86/intel_pmc_core.c > b/drivers/platform/x86/intel_pmc_core.c > index f2c621b55f49..ab798efacc85 100644 > --- a/drivers/platform/x86/intel_pmc_core.c > +++ b/drivers/platform/x86/intel_pmc_core.c > @@ -24,6 +24,7 @@ > #include > #include > #include > +#include > > #include "intel_pmc_core.h" > > @@ -738,7 +739,9 @@ static int pmc_core_pkgc_show(struct seq_file *s, void > *unused) > if (rdmsrl_safe(map[index].bit_mask, _count)) > continue; > > - seq_printf(s, "%-8s : 0x%llx\n", map[index].name, > + pcstate_count *= 1000; > + do_div(pcstate_count, tsc_khz); > + seq_printf(s, "%-8s : %llu\n", map[index].name, >pcstate_count); > } > > -- > 2.20.1 > -- With Best Regards, Andy Shevchenko
Re: [PATCH] platform/x86: touchscreen_dmi: Update Hi10 Air filter
On Wed, Jun 12, 2019 at 3:55 PM Hans de Goede wrote:
>
> Hi,
>
> On 12-06-19 14:40, Christian Oder wrote:
> > Turns out the Hi10 Air is built by multiple companies so using Hampoo
> > as a filter is not enough to cover all variants.
> >
> > This has been verified as working on the Hampoo and Morshow version.
> >
> > Signed-off-by: Christian Oder
>
> Patch looks good to me:
>
> Reviewed-by: Hans de Goede
>
I have pushed it, though I forget about this issue, it went without
this tag, sorry.
> Regards,
>
> Hans
>
>
> > ---
> > drivers/platform/x86/touchscreen_dmi.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/platform/x86/touchscreen_dmi.c
> > b/drivers/platform/x86/touchscreen_dmi.c
> > index b662cb2d7cd5..61e7c4987d0d 100644
> > --- a/drivers/platform/x86/touchscreen_dmi.c
> > +++ b/drivers/platform/x86/touchscreen_dmi.c
> > @@ -597,7 +597,8 @@ static const struct dmi_system_id
> > touchscreen_dmi_table[] = {
> > /* Chuwi Hi10 Air */
> > .driver_data = (void *)_hi10_air_data,
> > .matches = {
> > - DMI_MATCH(DMI_BOARD_VENDOR, "Hampoo"),
> > + DMI_MATCH(DMI_SYS_VENDOR, "CHUWI INNOVATION AND
> > TECHNOLOGY(SHENZHEN)CO.LTD"),
> > + DMI_MATCH(DMI_BOARD_NAME, "Cherry Trail CR"),
> > DMI_MATCH(DMI_PRODUCT_SKU, "P1W6_C109D_B"),
> > },
> > },
> >
--
With Best Regards,
Andy Shevchenko
Re: [PATCH] platform/x86: intel_pmc_core: Add ICL-NNPI support to PMC Core
On Fri, Jun 14, 2019 at 11:14 AM Rajneesh Bhardwaj
wrote:
>
> Ice Lake Neural Network Processor for deep learning inference a.k.a.
> ICL-NNPI can re-use Ice Lake Mobile regmap to enable Intel PMC Core
> driver on it.
>
This will be postponed till next cycle since the CPU model will not
appear before merge window.
So, please, resend than (I guess somewhat in a month).
> Cc: Darren Hart
> Cc: Andy Shevchenko
> Cc: platform-driver-...@vger.kernel.org
> Link: https://lkml.org/lkml/2019/6/5/1034
> Signed-off-by: Rajneesh Bhardwaj
> ---
> drivers/platform/x86/intel_pmc_core.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/platform/x86/intel_pmc_core.c
> b/drivers/platform/x86/intel_pmc_core.c
> index 1d902230ba61..be6cda89dcf5 100644
> --- a/drivers/platform/x86/intel_pmc_core.c
> +++ b/drivers/platform/x86/intel_pmc_core.c
> @@ -815,6 +815,7 @@ static const struct x86_cpu_id intel_pmc_core_ids[] = {
> INTEL_CPU_FAM6(KABYLAKE_DESKTOP, spt_reg_map),
> INTEL_CPU_FAM6(CANNONLAKE_MOBILE, cnp_reg_map),
> INTEL_CPU_FAM6(ICELAKE_MOBILE, icl_reg_map),
> + INTEL_CPU_FAM6(ICELAKE_NNPI, icl_reg_map),
> {}
> };
>
> --
> 2.17.1
>
--
With Best Regards,
Andy Shevchenko
Re: [PATCH V5 09/18] clk: tegra: Add save and restore context support for peripheral clocks
28.06.2019 5:12, Sowjanya Komatineni пишет:
> This patch implements save and restore context for peripheral fixed
> clock ops, peripheral gate clock ops, sdmmc mux clock ops, and
> peripheral clock ops.
>
> During system suspend, core power goes off and looses the settings
> of the Tegra CAR controller registers.
>
> So during suspend entry clock and reset state of peripherals is saved
> and on resume they are restored to have clocks back to same rate and
> state as before suspend.
>
> Acked-by: Thierry Reding
> Signed-off-by: Sowjanya Komatineni
> ---
> drivers/clk/tegra/clk-periph-fixed.c | 31 ++
> drivers/clk/tegra/clk-periph-gate.c | 34
> drivers/clk/tegra/clk-periph.c | 43
>
> drivers/clk/tegra/clk-sdmmc-mux.c| 30 +
> drivers/clk/tegra/clk.h | 8 +++
> 5 files changed, 146 insertions(+)
>
> diff --git a/drivers/clk/tegra/clk-periph-fixed.c
> b/drivers/clk/tegra/clk-periph-fixed.c
> index c088e7a280df..981f68b0a937 100644
> --- a/drivers/clk/tegra/clk-periph-fixed.c
> +++ b/drivers/clk/tegra/clk-periph-fixed.c
> @@ -60,11 +60,42 @@ tegra_clk_periph_fixed_recalc_rate(struct clk_hw *hw,
> return (unsigned long)rate;
> }
>
> +static int tegra_clk_periph_fixed_save_context(struct clk_hw *hw)
> +{
> + struct tegra_clk_periph_fixed *fixed = to_tegra_clk_periph_fixed(hw);
> + u32 mask = 1 << (fixed->num % 32);
> +
> + fixed->enb_ctx = readl(fixed->base + fixed->regs->enb_reg) & mask;
> + fixed->rst_ctx = readl(fixed->base + fixed->regs->rst_reg) & mask;
> +
readl_relaxed() ?
Re: [PATCH] intel_menlow: avoid null pointer deference error
On Wed, May 29, 2019 at 4:55 AM Young Xiao <92siuy...@gmail.com> wrote:
>
> Fix a null pointer deference by acpi_driver_data() if device is
> null (dereference before check). We should only set cdev and check
> this is OK after we are sure device is not null.
>
Pushed to my review and testing queue, thanks!
> Signed-off-by: Young Xiao <92siuy...@gmail.com>
> ---
> drivers/platform/x86/intel_menlow.c | 8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/platform/x86/intel_menlow.c
> b/drivers/platform/x86/intel_menlow.c
> index 77eb870..28feb5c 100644
> --- a/drivers/platform/x86/intel_menlow.c
> +++ b/drivers/platform/x86/intel_menlow.c
> @@ -180,9 +180,13 @@ static int intel_menlow_memory_add(struct acpi_device
> *device)
>
> static int intel_menlow_memory_remove(struct acpi_device *device)
> {
> - struct thermal_cooling_device *cdev = acpi_driver_data(device);
> + struct thermal_cooling_device *cdev;
> +
> + if (!device)
> + return -EINVAL;
>
> - if (!device || !cdev)
> + cdev = acpi_driver_data(device);
> + if (!cdev)
> return -EINVAL;
>
> sysfs_remove_link(>dev.kobj, "thermal_cooling");
> --
> 2.7.4
>
--
With Best Regards,
Andy Shevchenko
Re: [PATCH 3/3] platform/x86: wmi: add Xiaomi WMI key driver
On Mon, May 27, 2019 at 7:22 PM Mattias Jacobsson <2...@mok.nu> wrote:
>
> Some function keys on the built in keyboard on Xiaomi's notebooks does
> not produce any key events when pressed in combination with the function
> key. Some of these keys do report that they are being pressed via WMI
> events.
>
> This driver reports key events for Fn+F7 and double tap on Fn.
>
> Other WMI events that are reported by the hardware but not utilized by
> this driver are Caps Lock(which already work) and Fn lock/unlock.
>
Pushed to my review and testing queue, thanks!
> Signed-off-by: Mattias Jacobsson <2...@mok.nu>
> ---
> drivers/platform/x86/Kconfig | 10
> drivers/platform/x86/Makefile | 1 +
> drivers/platform/x86/xiaomi-wmi.c | 94 +++
> 3 files changed, 105 insertions(+)
> create mode 100644 drivers/platform/x86/xiaomi-wmi.c
>
> diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
> index 5d5cc6111081..257a99134b64 100644
> --- a/drivers/platform/x86/Kconfig
> +++ b/drivers/platform/x86/Kconfig
> @@ -781,6 +781,16 @@ config INTEL_WMI_THUNDERBOLT
> To compile this driver as a module, choose M here: the module will
> be called intel-wmi-thunderbolt.
>
> +config XIAOMI_WMI
> + tristate "Xiaomi WMI key driver"
> + depends on ACPI_WMI
> + depends on INPUT
> + help
> + Say Y here if you want to support WMI-based keys on Xiaomi
> notebooks.
> +
> + To compile this driver as a module, choose M here: the module will
> + be called xiaomi-wmi.
> +
> config MSI_WMI
> tristate "MSI WMI extras"
> depends on ACPI_WMI
> diff --git a/drivers/platform/x86/Makefile b/drivers/platform/x86/Makefile
> index 87b0069bd781..f64445d69f99 100644
> --- a/drivers/platform/x86/Makefile
> +++ b/drivers/platform/x86/Makefile
> @@ -51,6 +51,7 @@ obj-$(CONFIG_SURFACE3_WMI)+= surface3-wmi.o
> obj-$(CONFIG_TOPSTAR_LAPTOP) += topstar-laptop.o
> obj-$(CONFIG_WMI_BMOF) += wmi-bmof.o
> obj-$(CONFIG_INTEL_WMI_THUNDERBOLT)+= intel-wmi-thunderbolt.o
> +obj-$(CONFIG_XIAOMI_WMI) += xiaomi-wmi.o
>
> # toshiba_acpi must link after wmi to ensure that wmi devices are found
> # before toshiba_acpi initializes
> diff --git a/drivers/platform/x86/xiaomi-wmi.c
> b/drivers/platform/x86/xiaomi-wmi.c
> new file mode 100644
> index ..4ff9df5eb88f
> --- /dev/null
> +++ b/drivers/platform/x86/xiaomi-wmi.c
> @@ -0,0 +1,94 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * WMI driver for Xiaomi Laptops
> + *
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define XIAOMI_KEY_FN_ESC_0"A2095CCE-0491-44E7-BA27-F8ED8F88AA86"
> +#define XIAOMI_KEY_FN_ESC_1"7BBE8E39-B486-473D-BA13-66F75C5805CD"
> +#define XIAOMI_KEY_FN_FN "409B028D-F06B-4C7C-8BBB-EE133A6BD87E"
> +#define XIAOMI_KEY_CAPSLOCK"83FE7607-053A-4644-822A-21532C621FC7"
> +#define XIAOMI_KEY_FN_F7 "76E9027C-95D0-4180-8692-DA6747DD1C2D"
> +
> +#define XIAOMI_DEVICE(guid, key) \
> + .guid_string = (guid), \
> + .context = &(const unsigned int){key}
> +
> +struct xiaomi_wmi {
> + struct input_dev *input_dev;
> + unsigned int key_code;
> +};
> +
> +int xiaomi_wmi_probe(struct wmi_device *wdev, const void *context)
> +{
> + struct xiaomi_wmi *data;
> +
> + if (wdev == NULL || context == NULL)
> + return -EINVAL;
> +
> + data = devm_kzalloc(>dev, sizeof(struct xiaomi_wmi),
> GFP_KERNEL);
> + if (data == NULL)
> + return -ENOMEM;
> + dev_set_drvdata(>dev, data);
> +
> + data->input_dev = devm_input_allocate_device(>dev);
> + if (data->input_dev == NULL)
> + return -ENOMEM;
> + data->input_dev->name = "Xiaomi WMI keys";
> + data->input_dev->phys = "wmi/input0";
> +
> + data->key_code = *((const unsigned int *)context);
> + set_bit(EV_KEY, data->input_dev->evbit);
> + set_bit(data->key_code, data->input_dev->keybit);
> +
> + return input_register_device(data->input_dev);
> +}
> +
> +void xiaomi_wmi_notify(struct wmi_device *wdev, union acpi_object *_)
> +{
> + struct xiaomi_wmi *data;
> +
> + if (wdev == NULL)
> + return;
> +
> + data = dev_get_drvdata(>dev);
> + if (data == NULL)
> + return;
> +
> + input_report_key(data->input_dev, data->key_code, 1);
> + input_sync(data->input_dev);
> + input_report_key(data->input_dev, data->key_code, 0);
> + input_sync(data->input_dev);
> +}
> +
> +static const struct wmi_device_id xiaomi_wmi_id_table[] = {
> + // { XIAOMI_DEVICE(XIAOMI_KEY_FN_ESC_0, KEY_FN_ESC) },
> + // { XIAOMI_DEVICE(XIAOMI_KEY_FN_ESC_1, KEY_FN_ESC) },
> + { XIAOMI_DEVICE(XIAOMI_KEY_FN_FN, KEY_PROG1) },
> + // { XIAOMI_DEVICE(XIAOMI_KEY_CAPSLOCK, KEY_CAPSLOCK) },
> + {
Re: [PATCH V5 11/18] clk: tegra210: Add support for Tegra210 clocks
28.06.2019 5:12, Sowjanya Komatineni пишет:
> This patch adds system suspend and resume support for Tegra210
> clocks.
>
> All the CAR controller settings are lost on suspend when core power
> goes off.
>
> This patch has implementation for saving and restoring all the PLLs
> and clocks context during system suspend and resume to have the
> clocks back to same state for normal operation.
>
> Acked-by: Thierry Reding
> Signed-off-by: Sowjanya Komatineni
> ---
> drivers/clk/tegra/clk-tegra210.c | 115
> ++-
> drivers/clk/tegra/clk.c | 14 +
> drivers/clk/tegra/clk.h | 1 +
> 3 files changed, 127 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/clk/tegra/clk-tegra210.c
> b/drivers/clk/tegra/clk-tegra210.c
> index 1c08c53482a5..1b839544e086 100644
> --- a/drivers/clk/tegra/clk-tegra210.c
> +++ b/drivers/clk/tegra/clk-tegra210.c
> @@ -9,10 +9,12 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -20,6 +22,7 @@
> #include
>
> #include "clk.h"
> +#include "clk-dfll.h"
> #include "clk-id.h"
>
> /*
> @@ -225,6 +228,7 @@
>
> #define CLK_RST_CONTROLLER_RST_DEV_Y_SET 0x2a8
> #define CLK_RST_CONTROLLER_RST_DEV_Y_CLR 0x2ac
> +#define CPU_SOFTRST_CTRL 0x380
>
> #define LVL2_CLK_GATE_OVRA 0xf8
> #define LVL2_CLK_GATE_OVRC 0x3a0
> @@ -2820,6 +2824,7 @@ static int tegra210_enable_pllu(void)
> struct tegra_clk_pll_freq_table *fentry;
> struct tegra_clk_pll pllu;
> u32 reg;
> + int ret;
>
> for (fentry = pll_u_freq_table; fentry->input_rate; fentry++) {
> if (fentry->input_rate == pll_ref_freq)
> @@ -2847,10 +2852,10 @@ static int tegra210_enable_pllu(void)
> fence_udelay(1, clk_base);
> reg |= PLL_ENABLE;
> writel(reg, clk_base + PLLU_BASE);
> + fence_udelay(1, clk_base);
>
> - readl_relaxed_poll_timeout_atomic(clk_base + PLLU_BASE, reg,
> - reg & PLL_BASE_LOCK, 2, 1000);
> - if (!(reg & PLL_BASE_LOCK)) {
> + ret = tegra210_wait_for_mask(, PLLU_BASE, PLL_BASE_LOCK);
> + if (ret) {
> pr_err("Timed out waiting for PLL_U to lock\n");
> return -ETIMEDOUT;
> }
> @@ -3283,6 +3288,103 @@ static void tegra210_disable_cpu_clock(u32 cpu)
> }
>
> #ifdef CONFIG_PM_SLEEP
> +static u32 cpu_softrst_ctx[3];
> +static struct platform_device *dfll_pdev;
> +#define car_readl(_base, _off) readl_relaxed(clk_base + (_base) + ((_off) *
> 4))
> +#define car_writel(_val, _base, _off) \
> + writel_relaxed(_val, clk_base + (_base) + ((_off) * 4))
> +
> +static int tegra210_clk_suspend(void)
> +{
> + unsigned int i;
> + struct device_node *node;
> +
> + tegra_cclkg_burst_policy_save_context();
> +
> + if (!dfll_pdev) {
> + node = of_find_compatible_node(NULL, NULL,
> +"nvidia,tegra210-dfll");
> + if (node)
> + dfll_pdev = of_find_device_by_node(node);
> +
> + of_node_put(node);
> + if (!dfll_pdev)
> + pr_err("dfll node not found. no suspend for dfll\n");
> + }
> +
> + if (dfll_pdev)
> + tegra_dfll_suspend(dfll_pdev);
> +
> + /* Enable PLLP_OUT_CPU after dfll suspend */
> + tegra_clk_set_pllp_out_cpu(true);
> +
> + tegra_sclk_cclklp_burst_policy_save_context();
> +
> + clk_save_context();
> +
> + for (i = 0; i < ARRAY_SIZE(cpu_softrst_ctx); i++)
> + cpu_softrst_ctx[i] = car_readl(CPU_SOFTRST_CTRL, i);
> +
> + return 0;
> +}
> +
> +static void tegra210_clk_resume(void)
> +{
> + unsigned int i;
> + struct clk_hw *parent;
> + struct clk *clk;
> +
> + /*
> + * clk_restore_context restores clocks as per the clock tree.
> + *
> + * dfllCPU_out is first in the clock tree to get restored and it
> + * involves programming DFLL controller along with restoring CPUG
> + * clock burst policy.
> + *
> + * DFLL programming needs dfll_ref and dfll_soc peripheral clocks
> + * to be restores which are part ofthe peripheral clocks.
> + * So, peripheral clocks restore should happen prior to dfll clock
> + * restore.
> + */
> +
> + tegra_clk_osc_resume(clk_base);
> + for (i = 0; i < ARRAY_SIZE(cpu_softrst_ctx); i++)
> + car_writel(cpu_softrst_ctx[i], CPU_SOFTRST_CTRL, i);
> +
> + /* restore all plls and peripheral clocks */
> + tegra210_init_pllu();
> + clk_restore_context();
> +
> + fence_udelay(5, clk_base);
> +
> + /* resume SCLK and CPULP clocks */
> + tegra_sclk_cpulp_burst_policy_restore_context();
> +
> + /*
> + * restore CPUG clocks:
> + * - enable DFLL in open loop mode
> + * - switch CPUG to DFLL clock source
> + * - close DFLL loop
> + * - sync PLLX
Re: [PATCH v4 00/13] Support of ASUS TUF Gaming series laptops
On Tue, May 14, 2019 at 9:47 PM Yurii Pavlovskyi wrote: > > Hi, > > this is the fourth version of the patch series. > Pushed to my review and testing queue, thanks! > Changelog: > v4: > * Rebase on for-next branch > * Extract local variable in patch 01 > * Rename new method to "..._method3" and keep comma in struct declaration > in patch 03 (NOTE: the arg2 does not fit on same line by 1 character) > * Patch "Improve DSTS WMI method ID detection": > - sort local variables > - use dev_info > - separate changes to wmi module in an own patch > - rename method ID constants and fix comment capitalization > * "Support WMI event queue": split into separate refactoring and new > functionality patches, use dev_info as well > * "Organize code into sections": split out error handling refactoring > * "Enhance detection of thermal data": remove unreasonable refactoring > and just change the currently used condition > * "Control RGB keyboard backlight": removed, will be posted afterwards. > I will follow on the status of the multicolor framework, it does look > promising for this. > * Mark URL references with "Link:" > * Minor corrections to commit messages > v3: > * Use devm_* function in patch 01 > * Detect DSTS/DCTS using _UID in patch 04 > * Detect event queue by _UID as well in patch 05 > * Rename poll function in patch 05 > * Fix terminology in patches 09 and 10 > * Correct commit messages > v2: > * Fix logging > > INTRODUCTION > The support for this laptop series is currently non-existent, as the > asus-nb-wmi driver (which is essentially configuration for asus-wmi) fails > to load and multiple ACPI errors are logged in dmesg. This patch series > adds pretty comprehensive support for these relatively new laptops, adds > some code organization, and fixes a couple of bugs in the asus-wmi module. > > Thread for V1/V2: https://lkml.org/lkml/2019/4/10/973 > Thread for V3: https://lkml.org/lkml/2019/4/19/178 > > Yurii Pavlovskyi (13): > platform/x86: asus-wmi: Fix hwmon device cleanup > platform/x86: asus-wmi: Fix preserving keyboard backlight intensity on > load > platform/x86: asus-wmi: Increase input buffer size of WMI methods > platform/x86: wmi: Add function to get _UID of WMI device > platform/x86: asus-wmi: Improve DSTS WMI method ID detection > platform/x86: asus-wmi: Refactor WMI event handling > platform/x86: asus-wmi: Support WMI event queue > platform/x86: asus-nb-wmi: Add microphone mute key code > platform/x86: asus-wmi: Refactor error handling > platform/x86: asus-wmi: Organize code into sections > platform/x86: asus-wmi: Enhance detection of thermal data > platform/x86: asus-wmi: Switch fan boost mode > platform/x86: asus-wmi: Do not disable keyboard backlight on unloading > > .../ABI/testing/sysfs-platform-asus-wmi | 10 + > drivers/hid/hid-asus.c| 2 +- > drivers/platform/x86/asus-nb-wmi.c| 3 +- > drivers/platform/x86/asus-wmi.c | 427 ++ > drivers/platform/x86/wmi.c| 19 + > include/linux/acpi.h | 1 + > include/linux/platform_data/x86/asus-wmi.h| 5 +- > 7 files changed, 374 insertions(+), 93 deletions(-) > > -- > 2.17.1 > -- With Best Regards, Andy Shevchenko
Re: [PATCH] platform/x86: acer-wmi: Mark expected switch fall-throughs
On Thu, May 9, 2019 at 4:48 AM Gustavo A. R. Silva wrote: > Commit 5c742b45dd5fbbb6cf74d3378341704f4b23c5e8 mentions that "This was fixed > in acer_acpi some time ago, but I forgot to port the patch over to acer-wmi > when it was merged." Notice that this driver (acer-wmi) is based on the > no-longer existing acer_acpi driver. But after googling for a while I could > found the fix the original author talks about: > > https://repo.or.cz/acer_acpi.git/commitdiff/74c08a38875ffa9989c3100947650ac8a388c189 > > So, the fix is indeed similar and contains the same fall-throughs from case > ACER_AMW0_V2 to case ACER_WMID in both functions get_u32() and set_u32(). Pushed to my review and testing queue, thanks! -- With Best Regards, Andy Shevchenko
WARNING in kernfs_create_dir_ns
Hello, syzbot found the following crash on: HEAD commit:4b972a01 Linux 5.2-rc6 git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=14910879a0 kernel config: https://syzkaller.appspot.com/x/.config?x=9a31528e58cc12e2 dashboard link: https://syzkaller.appspot.com/bug?extid=38f5d5cf7ae88c46b11a compiler: clang version 9.0.0 (/home/glider/llvm/clang 80fee25776c2fb61e74c1ecb1a523375c2500b69) Unfortunately, I don't have any reproducer for this crash yet. IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+38f5d5cf7ae88c46b...@syzkaller.appspotmail.com WARNING: CPU: 0 PID: 9071 at fs/kernfs/dir.c:493 kernfs_get fs/kernfs/dir.c:493 [inline] WARNING: CPU: 0 PID: 9071 at fs/kernfs/dir.c:493 kernfs_new_node fs/kernfs/dir.c:700 [inline] WARNING: CPU: 0 PID: 9071 at fs/kernfs/dir.c:493 kernfs_create_dir_ns+0x205/0x230 fs/kernfs/dir.c:1022 Kernel panic - not syncing: panic_on_warn set ... CPU: 0 PID: 9071 Comm: syz-executor.1 Not tainted 5.2.0-rc6 #6 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x1d8/0x2f8 lib/dump_stack.c:113 panic+0x28a/0x7c9 kernel/panic.c:219 __warn+0x216/0x220 kernel/panic.c:576 report_bug+0x190/0x290 lib/bug.c:186 fixup_bug arch/x86/kernel/traps.c:179 [inline] do_error_trap+0xd7/0x450 arch/x86/kernel/traps.c:272 do_invalid_op+0x36/0x40 arch/x86/kernel/traps.c:291 invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:986 RIP: 0010:kernfs_get fs/kernfs/dir.c:493 [inline] RIP: 0010:kernfs_new_node fs/kernfs/dir.c:700 [inline] RIP: 0010:kernfs_create_dir_ns+0x205/0x230 fs/kernfs/dir.c:1022 Code: ff 4c 89 ff e8 7c cd ff ff 4c 63 fb eb 05 e8 e2 27 9a ff 4c 89 f8 48 83 c4 10 5b 41 5c 41 5d 41 5e 41 5f 5d c3 e8 cb 27 9a ff <0f> 0b e9 e9 fe ff ff 89 d9 80 e1 07 80 c1 03 38 c1 0f 8c be fe ff RSP: 0018:88805a66f590 EFLAGS: 00010287 RAX: 81db8a25 RBX: 88808fad88c0 RCX: 0004 RDX: c90007ff6000 RSI: 0001e1a2 RDI: 0001e1a3 RBP: 88805a66f5c8 R08: 81db8907 R09: ed1011f5b119 R10: ed1011f5b119 R11: 111011f5b118 R12: 888098366600 R13: dc00 R14: R15: 8880a8f66620 sysfs_create_dir_ns+0x161/0x300 fs/sysfs/dir.c:59 create_dir lib/kobject.c:89 [inline] kobject_add_internal+0x459/0xd50 lib/kobject.c:255 kobject_add_varg lib/kobject.c:390 [inline] kobject_add+0x138/0x200 lib/kobject.c:442 device_add+0x508/0x1570 drivers/base/core.c:2062 hci_register_dev+0x331/0x6c0 net/bluetooth/hci_core.c:3305 hci_uart_register_dev drivers/bluetooth/hci_ldisc.c:661 [inline] hci_uart_set_proto drivers/bluetooth/hci_ldisc.c:685 [inline] hci_uart_tty_ioctl+0x815/0x970 drivers/bluetooth/hci_ldisc.c:739 tty_ioctl+0xf66/0x15d0 drivers/tty/tty_io.c:2664 do_vfs_ioctl+0x7d4/0x1890 fs/ioctl.c:46 ksys_ioctl fs/ioctl.c:713 [inline] __do_sys_ioctl fs/ioctl.c:720 [inline] __se_sys_ioctl fs/ioctl.c:718 [inline] __x64_sys_ioctl+0xe3/0x120 fs/ioctl.c:718 do_syscall_64+0xfe/0x140 arch/x86/entry/common.c:301 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x459519 Code: fd b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 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 0f 83 cb b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:7fb578425c78 EFLAGS: 0246 ORIG_RAX: 0010 RAX: ffda RBX: 0003 RCX: 00459519 RDX: 0009 RSI: 400455c8 RDI: 0003 RBP: 0075bf20 R08: R09: R10: R11: 0246 R12: 7fb5784266d4 R13: 004c21a5 R14: 004d5330 R15: Kernel Offset: disabled Rebooting in 86400 seconds.. --- This bug is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this bug report. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
